[Bug lto/47822] New: [4.6 Regression] Multiple test suite failures due to revision 170321

[Bug lto/47822] New: [4.6 Regression] Multiple test suite failures due to revision 170321

[dominiq at lps dot ens.fr]

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

           Summary: [4.6 Regression] Multiple test suite failures due to
                    revision 170321
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: dominiq@lps.ens.fr
                CC: hjl@gcc.gnu.org, rguenther@suse.de


Revision 170321 caused a lot of failures on the test suite on
x86_64-apple-darwin10 and moxie-unknown-elf (see
http://gcc.gnu.org/ml/gcc-testresults/2011-02/msg02205.html). They are all of
the form:

[macbook] f90/bug% gcc46
/opt/gcc/work/gcc/testsuite/gcc.c-torture/execute/builtins/20010124-1.c
/opt/gcc/work/gcc/testsuite/gcc.c-torture/execute/builtins/20010124-1-lib.c
/opt/gcc/work/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c -flto
lto1: fatal error: target specific builtin not available
compilation terminated.
lto-wrapper: gcc46 returned 1 exit status
collect2: lto-wrapper returned 1 exit status

Reverting the revision fixes the failures.

This is pr seems related to pr47820.

[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |*-darwin*
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.02.20 14:48:01
          Component|lto                         |target
   Target Milestone|---                         |4.6.0
     Ever Confirmed|0                           |1

--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-02-20 14:48:01 UTC ---
Hm.  The target builtins appear in BLOCK_VARs of DECL_INITIAL of the
TRANSLATION_UNIT_DECL.

There is appearantly a builtin for IX86_BUILTIN_MAX, which is obviously bogus.

Does darwin define additional target specific builtins that are not
covered by the builtin_decl target hook (that would be a bug anyway)?
It seems to do via

do {                                                            \
  darwin_init_cfstring_builtins ((unsigned) (IX86_BUILTIN_MAX));\
  darwin_rename_builtins ();                                    \
} while(0)

which will result in all programs using those builtins fail with LTO
in the same way (that all builtins are streamed in now via the
TU decl isn't optimal, but per-se not a bug).  The code doesn't even
save the builtin somewhere retrievable, so the following is obviously
not correct but solves the ICE:

Index: config/i386/i386.c
===================================================================
--- config/i386/i386.c    (revision 170336)
+++ config/i386/i386.c    (working copy)
@@ -25821,7 +25821,11 @@
 static tree
 ix86_builtin_decl (unsigned code, bool initialize_p ATTRIBUTE_UNUSED)
 {
+#ifdef TARGET_MACHO
   if (code >= IX86_BUILTIN_MAX)
+    return implicit_built_in_decls[BUILT_IN_MEMSET];
+#endif
+  if (code >= IX86_BUILTIN_MAX)
     return error_mark_node;

   return ix86_builtins[code];

I think the darwin machinery should simply arrange to append to the
existing array, reserving an enum value if TARGET_MACHO (or sth other
appropriate) and store the decl there.

I will look into stripping out builtins from the TU BLOCK_VARS
(that won't solve the ICE when someone really uses that darwin builtin).

[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-02-20 15:05:00 UTC ---
Huh.  WTF is this builtin used for at all??

int main()
{
  return __builtin___CFStringMakeConstantString ("Hello");
}

and at gimple stage we already have

main ()
{
  int D.2718;
  long int D.2719;

  D.2719 = (long int) &C.1605;
  D.2718 = (int) D.2719;
  return D.2718;
}

!?  It appearantly relies on folding, huh, another brokeness - there is
no way it would survive through expansion (well, it'll get a libcall ...).
I wonder where it is actually _used_ from!?  Not from any header I have
installed on x86_64-darwin, not from any GCC code either.

Feels like a darwin hack again ... don't feel like wasting my Sunday on this
one either.

[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-02-20 15:19:41 UTC ---
Well, the problem does not seem fully darwin specific. It also shows on
moxie-unknown-elf and may be to some extent on powerpc64-unknown-linux-gnu (see
http://gcc.gnu.org/ml/gcc-testresults/2011-02/msg02232.html the failures on
gcc.dg/vmx/*).

[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-02-20 15:33:56 UTC ---
It will show on all targets without a builtin_decl hook and target builtins.

x86 is no such target, it shows there because of the darwin builtin not
playing by the rules.

I will fix (hide) the issue again, but it will (re-)cause decls of builtins
not to appear in gdb.  Thus,

void *malloc(long);
int main() {}

and you'll not be able to (gdb) ptype malloc.

Thus, darwin people - if you continue to let this kind of hacks sneak in,
then, well, you will continuously get beaten by this kind of problems.
If it "works" it doesn't mean its right.

[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |iains at gcc dot gnu.org,
                   |                            |mikestump at comcast dot
                   |                            |net

--- Comment #5 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-02-20 16:03:22 UTC ---
> do {                                                            \
>   darwin_init_cfstring_builtins ((unsigned) (IX86_BUILTIN_MAX));\
>   darwin_rename_builtins ();                                    \
> } while(0)
>
> ...
> Huh.  WTF is this builtin used for at all??

My guess is that it is related to 

> Darwin/Mac OS X
>
> General
> Initial support for CFString types has been added.
> ...

in http://gcc.gnu.org/gcc-4.6/changes.html#objective-c. CCing Iain Sandoe and
Mike Stump.

[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-02-20 17:15:55 UTC ---
Author: rguenth
Date: Sun Feb 20 17:15:53 2011
New Revision: 170339

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170339
Log:
2011-02-20  Richard Guenther  <rguenther@suse.de>

    PR lto/47822
    * tree.c (free_lang_data_in_decl): Clean builtins from
    the TU decl BLOCK_VARS.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree.c

[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #7 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-02-20 17:19:04 UTC ---
"Fixed".

[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321

[mrs at gcc dot gnu.org]

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

--- Comment #8 from mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> 2011-02-20 18:10:06 UTC ---
Created attachment 23415
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23415
darwin patch (moxie is unrelated)

Here is a darwin patch.  Not my code, but if I understand the problem, this
should fix the darwin problems.  This doesn't fix the moxie problems, nor any
other non-darwin problems.

[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321

[mrs at gcc dot gnu.org]

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

mrs@gcc.gnu.org <mrs at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mrs at gcc dot gnu.org

--- Comment #9 from mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> 2011-02-20 18:57:24 UTC ---
The Objective and Objective-C++ testsuites look good to me on darwin10.

Dominique, can you try a build on ppc?  I did a build on my franken ppc (x86_64
running rosetta), and it looked fine.

I ran the RUNTESTFLAGS=builtins.exp=builtins/20010124-1.c testcase, and I saw
it go from not working to working.

[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-02-20 19:12:31 UTC ---
> Dominique, can you try a build on ppc?

Mike, could you be more precise: do you want me to test the patch in comment #8
before or after updating to revision 170339 (which fix this pr, at least on
x86_64-apple-darwin10)?

[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321

[mikestump at comcast dot net]

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

--- Comment #11 from Mike Stump <mikestump at comcast dot net> 2011-02-20 19:23:07 UTC ---
Could you try building with the patch on a ppc box if you have one, without the
"Fix" to tree.c in it, so that it will fail, if the problem isn't really fixed.
 If you don't, then a second set of hands testing would be nice, if we want to
put this into the tree before stage1.  Richard, should the darwin fix go in
now, or wait til stage1?

[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321

[dominiq at lps dot ens.fr]

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

--- Comment #12 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-02-20 19:40:18 UTC ---
> Could you try building with the patch on a ppc box if you have one, without the
> "Fix" to tree.c in it, so that it will fail, if the problem isn't really fixed.

I have applied the patch in comment #8 on top of revision 170338 on my ppc box.
This box is quite slow, so don't expect results before tomorrow morning (GMT).

[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321

[howarth at nitro dot med.uc.edu]

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

Jack Howarth <howarth at nitro dot med.uc.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |howarth at nitro dot
                   |                            |med.uc.edu

--- Comment #13 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-02-20 19:52:57 UTC ---
The patch from Comment 8 does resolve the bootstrap-lto failures on
x86_64-apple-darwin10 (PR47822) at r170338 (in absence of the r170339
workaround).

[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321

[mrs at gcc dot gnu.org]

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

--- Comment #14 from mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> 2011-02-21 04:09:52 UTC ---
*** Bug 47826 has been marked as a duplicate of this bug. ***

[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-02-21 09:44:34 UTC ---
(In reply to comment #11)
> Could you try building with the patch on a ppc box if you have one, without the
> "Fix" to tree.c in it, so that it will fail, if the problem isn't really fixed.
>  If you don't, then a second set of hands testing would be nice, if we want to
> put this into the tree before stage1.  Richard, should the darwin fix go in
> now, or wait til stage1?

The patch looks good to me and is fine for stage4.

[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321

[dominiq at lps dot ens.fr]

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

--- Comment #16 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-02-21 10:03:36 UTC ---
(In reply to comment #15)
> > Could you try building with the patch on a ppc box if you have one, without the
> > "Fix" to tree.c in it, so that it will fail, if the problem isn't really fixed.
> >  If you don't, then a second set of hands testing would be nice, if we want to
> > put this into the tree before stage1.  Richard, should the darwin fix go in
> > now, or wait til stage1?
> 
> The patch looks good to me and is fine for stage4.

Unfortunately it does not fix the problem on ppc.

[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321

[iains at gcc dot gnu.org]

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

--- Comment #17 from Iain Sandoe <iains at gcc dot gnu.org> 2011-02-21 10:08:51 UTC ---
there was no intention to create a hack (or any other form of expedient work);  

...  if it is wrong, then it is likely a mistake on my part when importing the
original implementation from the 4.3-era branch.

--

I have applied the patch @ comment #8 to r170338 on i686-darwin9 and
powerpc-darwin9. 

It works on i686 ... 
... but it does not work on powerpc.
(both as comment #8 is written and with RS6000_BUILTIN_CFSTRING as the argument
to darwin_init_cfstring_builtins)

--

checking in gdb for cc1obj and lto1 --  darwin_init_cfstring_builtins () is
being called for both (and with the same index value in each case).  The
routine appears be initializing the built-in correctly in both cases.

(the same reported error is also present for a simple CFString c program, so
not likely an objc problem).

the programs compile and execute correctly without lto.

.. any hints as to what additional steps are required for ppc would be
appreciated.

[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321

[rguenth at gcc dot gnu.org]

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

--- Comment #18 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-02-21 10:44:03 UTC ---
(In reply to comment #16)
> (In reply to comment #15)
> > > Could you try building with the patch on a ppc box if you have one, without the
> > > "Fix" to tree.c in it, so that it will fail, if the problem isn't really fixed.
> > >  If you don't, then a second set of hands testing would be nice, if we want to
> > > put this into the tree before stage1.  Richard, should the darwin fix go in
> > > now, or wait til stage1?
> > 
> > The patch looks good to me and is fine for stage4.
> 
> Unfortunately it does not fix the problem on ppc.

Of course, the patch doesn't touch rs6000 which has exactly the same problem.

[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321

[mikestump at comcast dot net]

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

--- Comment #19 from Mike Stump <mikestump at comcast dot net> 2011-02-21 20:58:35 UTC ---
?  The patch does touch rs6000 is the same way as we touch i386.  I think there
is an additional issue on ppc.  My previous patch is necessary, but not
sufficient.  So, if someone has a rs6000, I'll fix it, if you point out the
line that dies or the data structure that it was playing with.

[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321

[mikestump at comcast dot net]

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

--- Comment #20 from Mike Stump <mikestump at comcast dot net> 2011-02-21 21:02:16 UTC ---
Ah, never mind, we have another thread going where the problem was pointed out.
 Sorry for missing it.

[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321

[mrs at gcc dot gnu.org]

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

--- Comment #21 from mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> 2011-02-21 21:38:23 UTC ---
Author: mrs
Date: Mon Feb 21 21:38:21 2011
New Revision: 170376

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170376
Log:
    PR target/47822
    * config/darwin-protos.h (darwin_init_cfstring_builtins): Return a
    tree so we can get save the type.
    * config/i386/darwin.h (SUBTARGET_INIT_BUILTINS): Reserve builtin slot
    for CFString instead of trying to use past the end of the builtins.
    * config/i386/i386.c (IX86_BUILTIN_CFSTRING): Likewise.
    * config/rs6000/rs6000-builtin.def (RS6000_BUILTIN_CFSTRING): Likewise.
    * config/rs6000/darwin.h (SUBTARGET_INIT_BUILTINS): Likewise.
    * config/darwin.c (DARWIN_BUILTIN_CFSTRINGMAKECONSTANTSTRING):
    Rename to darwin_builtin_cfstring.
    (darwin_init_cfstring_builtins): Return the built type.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/darwin-protos.h
    trunk/gcc/config/darwin.c
    trunk/gcc/config/i386/darwin.h
    trunk/gcc/config/i386/i386.c
    trunk/gcc/config/rs6000/darwin.h
    trunk/gcc/config/rs6000/rs6000-builtin.def

[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321

[dominiq at lps dot ens.fr]

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

--- Comment #22 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-02-22 10:44:47 UTC ---
At revision 170376 (comment #21), the "fix" of revision 170339 (comment #6)
seems no longer needed on powerpc-apple-darwin9 and x86_64-apple-darwin10,
i.e., after reverting revision 170339 on r170376, the tests in
gcc.c-torture/execute/builtins/ and gfortran.dg/lto/ pass without failures.

Thanks for the fix.

[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321

[mikestump at comcast dot net]

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

--- Comment #23 from Mike Stump <mikestump at comcast dot net> 2011-02-22 11:53:56 UTC ---
I am confused, both Iain and myself still see failures on ppc even with my
patch.  Iain said they were dying on BUILT_IN_SQRTL.  I can't debug, as I'm
using rosetta, and apparently debugging no longer works.  :-(  Odd.

[ long pause ]

Truly, odd, I just updated and removed that hunk from comment #6, and presto,
the testcase that failed for me earlier, now works.  I did do a restrap this
time to try and avoid more uncleanliness.

[Bug target/47822] [4.6 Regression] Multiple test suite failures due to revision 170321

[mikestump at comcast dot net]

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

--- Comment #24 from Mike Stump <mikestump at comcast dot net> 2011-02-22 11:56:37 UTC ---
Iain reports it is fixed for him as well...  :-)