public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug lto/64685] New: wrong code by LTO on x86_64-linux-gnu
@ 2015-01-20  8:23 su at cs dot ucdavis.edu
  2015-01-20  9:51 ` [Bug lto/64685] [5 Regression] " rguenth at gcc dot gnu.org
  2015-01-20 10:47 ` rguenth at gcc dot gnu.org
  0 siblings, 2 replies; 3+ messages in thread
From: su at cs dot ucdavis.edu @ 2015-01-20  8:23 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64685

            Bug ID: 64685
           Summary: wrong code by LTO on x86_64-linux-gnu
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: su at cs dot ucdavis.edu

The current gcc trunk miscompiles the following code when using LTO on
x86_64-linux-gnu in both 32-bit and 64-bit modes. 

This is a regression from 4.9.x. 

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 5.0.0 20150119 (experimental) [trunk revision 219832] (GCC) 

$ 
$ gcc-trunk -O0 -c fn1.c
$ gcc-trunk -O1 -c main.c
$ gcc-trunk -O1 fn1.o main.o
$ ./a.out
$ 
$ gcc-4.9 -flto -O0 -c fn1.c
$ gcc-4.9 -flto -O1 -c main.c
$ gcc-4.9 -flto -O1 fn1.o main.o
$ ./a.out
$ 
$ 
$ gcc-trunk -flto -O0 -c fn1.c
$ gcc-trunk -flto -O1 -c main.c
$ gcc-trunk -flto -O1 fn1.o main.o
$ ./a.out
Aborted (core dumped)
$ 
$ cat fn1.c
extern int b;

void
fn1 (void)
{
  b = 0;
}
$ cat main.c
extern void fn1 (void); 

int a[2], b;

static void
foo (int p)
{
  b = 1 ^ a[(b ^ 1) & 1];
  b = 1 ^ a[b & 1];
  if (p)
    __builtin_abort ();
}

int
main ()
{
  foo (0);
  b = 0;
  foo (0);

  if (b != 1)
    __builtin_abort ();

  return 0;
}
$


^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug lto/64685] [5 Regression] wrong code by LTO on x86_64-linux-gnu
  2015-01-20  8:23 [Bug lto/64685] New: wrong code by LTO on x86_64-linux-gnu su at cs dot ucdavis.edu
@ 2015-01-20  9:51 ` rguenth at gcc dot gnu.org
  2015-01-20 10:47 ` rguenth at gcc dot gnu.org
  1 sibling, 0 replies; 3+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-01-20  9:51 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64685

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |lto, wrong-code
           Priority|P3                          |P1
                 CC|                            |hubicka at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org
   Target Milestone|---                         |5.0
            Summary|wrong code by LTO on        |[5 Regression] wrong code
                   |x86_64-linux-gnu            |by LTO on x86_64-linux-gnu

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Esp. mixing -O0 and -O1+ will have interesting effects for sure.  Also mixing
IL changing options like -fwrapv, -fstrict-overflow, etc.  We just check

  /* Don't inline a function with a higher optimization level than the
     caller.  FIXME: this is really just tip of iceberg of handling
     optimization attribute.  */
  else if (caller_tree != callee_tree)
    {
      if (((opt_for_fn (e->caller->decl, optimize)
            > opt_for_fn (callee->decl, optimize))
            || (opt_for_fn (e->caller->decl, optimize_size)
                != opt_for_fn (callee->decl, optimize_size)))
          /* gcc.dg/pr43564.c.  Look at forced inline even in -O0.  */
          && !DECL_DISREGARD_INLINE_LIMITS (callee->decl))
        {
          e->inline_failed = CIF_OPTIMIZATION_MISMATCH;
          inlinable = false;
        }
    }

but that's definitely not enough (unless I miss checks somewhere else but in
can_inline_edge_p).  Also it's not possible to inline -O1+ into a -O0
function (SSA coalescing).

And the !DECL_DISREGARD_INLINE_LIMITS is definitely bogus as well.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug lto/64685] [5 Regression] wrong code by LTO on x86_64-linux-gnu
  2015-01-20  8:23 [Bug lto/64685] New: wrong code by LTO on x86_64-linux-gnu su at cs dot ucdavis.edu
  2015-01-20  9:51 ` [Bug lto/64685] [5 Regression] " rguenth at gcc dot gnu.org
@ 2015-01-20 10:47 ` rguenth at gcc dot gnu.org
  1 sibling, 0 replies; 3+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-01-20 10:47 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64685

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Duplicate.

*** This bug has been marked as a duplicate of bug 64684 ***


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2015-01-20 10:47 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-01-20  8:23 [Bug lto/64685] New: wrong code by LTO on x86_64-linux-gnu su at cs dot ucdavis.edu
2015-01-20  9:51 ` [Bug lto/64685] [5 Regression] " rguenth at gcc dot gnu.org
2015-01-20 10:47 ` rguenth at gcc dot gnu.org

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).