http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56168



--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> 2013-02-01 
12:34:53 UTC ---

Created attachment 29328

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29328

patch



We do stream things properly as / not as builtin.  Only we end up replacing

the non-builtin with the prevailing builtin.  It seems to me builtins should

never "prevail" (we do not touch their cgraph nodes either) but we also

should not replace any builtin decl with whatever prevailed (unless maybe

there is a visible definition ...?)



I have a patch but that causes PR55848 to re-appear (also in this testcase):



lto1: error: edge points to wrong declaration:^M

 <function_decl 0x7fb56f8d2a00 pow^M

    type <function_type 0x7fb56f8d1e70^M

...

 Instead of: <function_decl 0x7fb56f7e6f00 __builtin_pow^M

    type <function_type 0x7fb56f7b60a8^M



doesn't happen with -flto-partition=none though.  At LTRANs we again see



  d2_5 = __builtin_pow (d1_3,

3.33333333333333314829616256247390992939472198486328125e-1);

  d3_6 = __builtin_pow (d1_3, 2.0e+0);



which is of course wrong.  Something assumes there is only a single

prevailing cgraph node per symbol?  The callgraph at LTRANS time

looks ok to me:



pow/2 (pow) @0x7f5806f3ca68

  Type: function

  Visibility: undef external public

  previous sharing asm name: 3

  References:

  Referring:

  Read from file: /tmp/ccp4tasf.ltrans0.o

  Function flags:

  Called by: main/1 (1.00 per call)

  Calls:

pow/3 (__builtin_pow) @0x7f5806f3c940

  Type: function

  Visibility: external public

  next sharing asm name: 2

  References:

  Referring:

  Read from file: /tmp/ccp4tasf.ltrans0.o

  Function flags:

  Called by: main/1 (1.00 per call)

main/1 (main) @0x7f5806f3c6f0

  Type: function

  Visibility: prevailing_def public

  References: x.2385/0 (read)

  Referring:

  Read from file: /tmp/ccp4tasf.ltrans0.o

  Function flags: analyzed finalized only_called_at_startup

  Called by:

  Calls: abort/4 (0.39 per call) pow/3 (1.00 per call) pow/2 (1.00 per call)



but then somehow it's all wrong when reading the call op of the call stmt.

The ltrans object fn decl state stream of main has both a builtin and

a non-builtin.  That's because LTRANS thinks the builtin prevailed.  Bah.

That's because it happens to come "first" and we skip lto_symtab_merge_decls

for LTRANS.  Probably ok, but then we also should skip lto_fixup_decls.

Reply via email to