Bug 50177 - libcpp reallocator a C or C++ function?
libcpp reallocator a C or C++ function?
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: bootstrap
4.7.0
: P3 normal
: ---
Assigned To: Not yet assigned to anyone
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-08-24 15:09 UTC by Marc Glisse
Modified: 2013-01-03 20:13 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marc Glisse 2011-08-24 15:09:02 UTC
Hello,

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;
       set->maps
        = (struct line_map *) (*reallocator) (set->maps,
Comment 1 Marc Glisse 2013-01-03 20:06:57 UTC
Author: glisse
Date: Thu Jan  3 20:06:49 2013
New Revision: 194868

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=194868
Log:
2013-01-03  Marc Glisse  <marc.glisse@inria.fr>

	PR bootstrap/50167
gcc/
	* graphite-interchange.c (pdr_stride_in_loop): Use gmp_fprintf.
	* graphite-poly.c (debug_gmp_value): Likewise.

	PR bootstrap/50177
libcpp/
	* line-map.c (get_combined_adhoc_loc): Cast from extern "C" type.
	(new_linemap): Likewise.
	(linemap_enter_macro): Likewise.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/graphite-interchange.c
    trunk/gcc/graphite-poly.c
    trunk/libcpp/ChangeLog
    trunk/libcpp/line-map.c
Comment 2 Marc Glisse 2013-01-03 20:13:50 UTC
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.