User account creation filtered due to spam.
another issue (last one for now) with using a non-gcc C++ compiler for stage1:
in libcpp, struct line_maps has a member reallocator of type line_map_realloc (a typedef for a pointer to function). The various values it gets assigned in gcc are 0, xmalloc and realloc_for_line_map (from gcc/toplev.c). The second one is an extern "C" function and the last one a "C++" function, which in C++ are different types. g++ can't tell the difference (yet? see Bug 2316), but some other compilers can (sunpro). We should decide whether line_map_realloc is supposed to be a "C" or "C++" function and be consistent about it.
Note that if we only care about letting sunpro pass, the following only warns instead of producing an error (a cast of xrealloc to line_map_realloc might do the same):
--- libcpp/line-map.c (revision 176961)
+++ libcpp/line-map.c (working copy)
@@ -95,8 +95,9 @@
if (set->used == set->allocated)
- line_map_realloc reallocator
- = set->reallocator ? set->reallocator : xrealloc;
+ line_map_realloc reallocator;
+ if(set->reallocator) reallocator=set->reallocator;
+ else reallocator=xrealloc;
set->allocated = 2 * set->allocated + 256;
= (struct line_map *) (*reallocator) (set->maps,
Date: Thu Jan 3 20:06:49 2013
New Revision: 194868
2013-01-03 Marc Glisse <email@example.com>
* graphite-interchange.c (pdr_stride_in_loop): Use gmp_fprintf.
* graphite-poly.c (debug_gmp_value): Likewise.
* line-map.c (get_combined_adhoc_loc): Cast from extern "C" type.
Closing. It isn't properly fixed, just hacked around, but if we ever cleanup extern "C" versus extern "C++" function types in GCC, this will just be a small part of it.