From: David Edelsohn <dje.gcc@gmail.com>
To: Michael Matz <matz@suse.de>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [RFA] expand from SSA form (1/2)
Date: Wed, 29 Apr 2009 05:50:00 -0000 [thread overview]
Message-ID: <303e1d290904281815q5cbbdedet74260a6437d1942c@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0904290138430.29566@wotan.suse.de>
[-- 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 --]
next prev parent reply other threads:[~2009-04-29 1:15 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-27 14:15 David Edelsohn
2009-04-27 14:43 ` H.J. Lu
2009-04-27 15:08 ` Michael Matz
2009-04-27 15:11 ` David Edelsohn
2009-04-27 15:51 ` Michael Matz
2009-04-27 17:03 ` David Edelsohn
2009-04-27 17:27 ` David Edelsohn
2009-04-27 19:15 ` David Edelsohn
2009-04-28 0:48 ` Michael Matz
2009-04-28 0:54 ` Luis Machado
2009-04-28 1:22 ` Michael Matz
2009-04-28 13:24 ` Luis Machado
2009-04-30 17:55 ` Luis Machado
2009-05-01 19:33 ` Richard Guenther
2009-05-04 13:38 ` Luis Machado
2009-04-28 16:05 ` David Edelsohn
2009-04-28 16:19 ` Michael Matz
2009-04-28 23:49 ` Michael Matz
2009-04-29 5:50 ` David Edelsohn [this message]
2009-04-29 12:48 ` Michael Matz
2009-04-29 13:21 ` David Edelsohn
2009-04-29 13:35 ` Michael Matz
2009-04-29 14:38 ` David Edelsohn
2009-04-29 14:50 ` Richard Guenther
2009-04-29 15:03 ` Andreas Krebbel
2009-04-29 15:11 ` Michael Matz
2009-04-29 15:40 ` Andreas Krebbel
2009-04-29 17:33 ` Michael Matz
2009-04-29 17:41 ` Michael Matz
-- strict thread matches above, loose matches on Subject: below --
2009-04-13 20:50 RFC: " Michael Matz
2009-04-21 18:23 ` Andrew MacLeod
2009-04-22 10:54 ` Michael Matz
2009-04-22 16:45 ` [RFA] " Michael Matz
2009-04-23 15:10 ` Andrew MacLeod
2009-04-24 9:42 ` Richard Guenther
2009-04-26 20:27 ` Michael Matz
2010-01-19 15:48 ` H.J. Lu
2009-04-24 14:32 ` Richard Guenther
2009-04-24 14:46 ` Richard Guenther
2009-04-26 20:21 ` Michael Matz
2009-04-26 20:34 ` Richard Guenther
2009-04-26 20:53 ` Michael Matz
2009-04-26 21:14 ` Richard Guenther
2009-04-26 21:15 ` Michael Matz
2009-04-26 21:17 ` Richard Guenther
2009-04-26 22:21 ` Michael Matz
2009-04-26 21:42 ` Michael Matz
2009-04-26 22:15 ` Michael Matz
2009-04-27 12:34 ` Michael Matz
2009-04-27 5:47 ` H.J. Lu
2009-04-28 23:49 ` H.J. Lu
2009-04-29 0:21 ` Andrew Pinski
2009-04-30 13:47 ` H.J. Lu
2009-05-29 3:47 ` H.J. Lu
2010-10-20 18:02 ` H.J. Lu
2011-02-14 18:02 ` H.J. Lu
2009-04-27 7:22 ` Hans-Peter Nilsson
2009-04-30 18:18 ` Steve Ellcey
2009-05-01 17:40 ` Michael Matz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=303e1d290904281815q5cbbdedet74260a6437d1942c@mail.gmail.com \
--to=dje.gcc@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=matz@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).