Re: [RFA] expand from SSA form (1/2)

[David Edelsohn <dje.gcc@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4191 bytes --]

On Tue, Apr 28, 2009 at 7:48 PM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Tue, 28 Apr 2009, David Edelsohn wrote:
>
>> I tried Andreas Krebbel's patch, but that, unfortunately, did not fix
>> the AIX libobjc build.
>>
>> I am able to bootstrap C, C++, and Fortran, and run the testsuite.
>> Objective C is not required on AIX, but the build problem is exposing a
>> miscompilation of GCC on PowerPC after the expand SSA merge.
>
> I tried to reproduce this on powerpc64-linux (default languages,
> multilibs) but failed.  It just bootstraps, and testresults look mostly
> sane, the only additional FAIL that I didn't find in older gcc-testresults
> posts were execute/va-arg-22.c and dfp/pr3903[45].c :-(
>
> That is with Andreas' patch (the approved one).
>
> I'm at a loss now without a testcase.  You said you found the
> miscompilation in cgraphunit.c:build_cdtor(), so it possibly helps if you
> provide the preprocessed version of that and the command line for
> compilation (perhaps also giving a snippet of asm where the wrong
> instructions are).


The command to compile libobjc/linking.m is in libobjc.sh.
The pre-processed linking.m is attached as linking.i.
The command to compile cgraphunit.c is in cgraphunit.sh
The pre-processed cgraphunit.c is attached as cgraphunit.i
The pre-processed tree.c is attached as tree.i

I have not had an opportunity to investigate which function is
miscompiled.  cgraphunit.c compiled with -O1 or -O2 produces incorrect
assembly language.  The inlining and additional jumps introduced by
optimization makes pinpointing the exact wrong code sequence
difficult.  GDB shows the priority returned by
decl_init_priority_lookup() as 65535 but the value in the register is
-1, which is the value that cgraph_build_static_cdtor() receives:
priority = -1:

(gdb) n
220           cgraph_build_static_cdtor (ctor_p ? 'I' : 'D', body, priority);
(gdb) step
200           body = NULL_TREE;
(gdb)
decl_init_priority_lookup (decl=0x300e2980)
   at /farm/dje/src/src/gcc/tree.c:4347
4347      gcc_assert (VAR_OR_FUNCTION_DECL_P (decl));
(gdb) finish
Run till exit from #0  decl_init_priority_lookup (decl=0x300e2980)
   at /farm/dje/src/src/gcc/tree.c:4347
0x10609ce8 in build_cdtor (ctor_p=255 'ÿ', cdtors=0x30097b78, len=1)
   at /farm/dje/src/src/gcc/cgraphunit.c:200
200           body = NULL_TREE;
Value returned is $5 = 65535
(gdb) finish
Run till exit from #0  0x10609ce8 in build_cdtor (ctor_p=255 'ÿ',
   cdtors=0x30097b78, len=1) at /farm/dje/src/src/gcc/cgraphunit.c:200

Breakpoint 6, cgraph_build_static_cdtor (which=73 'I', body=0x3009e820,
   priority=-1) at /farm/dje/src/src/gcc/cgraphunit.c:1374
1374      sprintf (which_buf, "%c_%.5d_%d", which, priority, counter++);

It may be that cgraphunit.c is not miscompiled, but massages the value
in extra ways that maintains the unsigned short and that somehow is
lost with optimization enabled, assuming the value returned is
properly zero-extended.

decl_init_priority_lookup() appears to be setting the wrong value:

/* An initialization priority.  */
typedef unsigned short priority_type;

/* The initialization priority for entities for which no explicit
  initialization priority has been specified.  */
#define DEFAULT_INIT_PRIORITY 65535

4349      h = (struct tree_priority_map *) htab_find
(init_priority_for_decl, &in);
4350      return h ? h->init : DEFAULT_INIT_PRIORITY;

0x1002af5c <decl_init_priority_lookup+48>:      bl      0x100494cc <htab_find>
0x1002af60 <decl_init_priority_lookup+52>:      nop
0x1002af64 <decl_init_priority_lookup+56>:      li      r0,-1 <------------
0x1002af68 <decl_init_priority_lookup+60>:      cmpwi   r3,0
0x1002af6c <decl_init_priority_lookup+64>:
   beq-        0x1002af74 <decl_init_priority_lookup+72>
0x1002af70 <decl_init_priority_lookup+68>:      lhz     r0,4(r3)
0x1002af74 <decl_init_priority_lookup+72>:      addi    r1,r1,80
0x1002af78 <decl_init_priority_lookup+76>:      mr      r3,r0 <-------------

When compiling libobjc/linking.m, the default priority is used, which
should be 65535, but it is being sign-extended to -1.

David

[-- Attachment #2: libobjc.sh --]
[-- Type: application/x-sh, Size: 760 bytes --]

[-- Attachment #3: linking.i.bz2 --]
[-- Type: application/x-bzip2, Size: 5450 bytes --]

[-- Attachment #4: cgraphunit.sh --]
[-- Type: application/x-sh, Size: 787 bytes --]

[-- Attachment #5: cgraphunit.i.bz2 --]
[-- Type: application/x-bzip2, Size: 132479 bytes --]

[-- Attachment #6: tree.i.bz2 --]
[-- Type: application/x-bzip2, Size: 146244 bytes --]