[Bug lto/57703] New: Assembler function definition moved to a different ltrans then call

[Bug lto/57703] New: Assembler function definition moved to a different ltrans then call

[marxin.liska at gmail dot com]

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

            Bug ID: 57703
           Summary: Assembler function definition moved to a different
                    ltrans then call
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: marxin.liska at gmail dot com

SandboxSyscall calls SyscallAsm that is an assembler function defined in the
same file: syscall.cc.

dump grep:
grep SyscallAsm *:
out/Release/nacl_helper.ltrans1.047i.inline:call SyscallAsm
out/Release/nacl_helper.ltrans1.047i.inline:call SyscallAsm
out/Release/nacl_helper.ltrans0.s:.type SyscallAsm, @function
out/Release/nacl_helper.ltrans0.s:SyscallAsm:.cfi_startproc
out/Release/nacl_helper.ltrans0.s:9:.size SyscallAsm, 9b-SyscallAsm
out/Release/nacl_helper.ltrans1.s:call SyscallAsm
out/Release/nacl_helper.ltrans1.045i.cp:call SyscallAsm

Linker error:
nacl_helper.ltrans1.ltrans.o: In function `playground2::SandboxSyscall(int,
long, long, long, long, long, long)':
nacl_helper.ltrans1.o:(.text+0x4503): undefined reference to `SyscallAsm'
/home/marxin/gcc-mirror/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/ld:
nacl_helper.ltrans1.ltrans.o: relocation R_X86_64_PC32 against undefined symbol
`SyscallAsm' can not be used when making a shared object; recompile with -fPIC
/home/marxin/gcc-mirror/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/ld: final
link failed: Bad value
collect2: error: ld returned 1 exit status

Dumps link:
https://docs.google.com/file/d/0B0pisUJ80pO1eFltWU9NUUZkaGM/edit?usp=sharing

When compiled with --param lto-partitions=1 no problem is encountered.

[Bug lto/57703] Assembler function definition moved to a different ltrans then call

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2013-06-25
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #0)
> SandboxSyscall calls SyscallAsm that is an assembler function defined in the
> same file: syscall.cc.

If it is in a toplevel asm() then this is a know missed feature of
toplevel asm()s - you cannot specify what symbols they declare.

Can you attach preprocessed source of syscall.cc?
>From gcc-bugs-return-425051-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jun 25 08:03:06 2013
Return-Path: <gcc-bugs-return-425051-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 19985 invoked by alias); 25 Jun 2013 08:03:06 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 19937 invoked by uid 48); 25 Jun 2013 08:03:03 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/57702] Reassoc missed optimizations
Date: Tue, 25 Jun 2013 08:03:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on everconfirmed
Message-ID: <bug-57702-4-jjtT5y8x6B@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57702-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57702-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg01430.txt.bz2
Content-length: 755

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW702

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-06-25
     Ever confirmed|0                           |1

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Yeah, well.  reassoc needs an audit on places where we may not associate
blindly for TYPE_OVERFLOW_UNDEFINED/TRAPS.  Its general machinery is just
not prepared for such limitation (for example ops list sorting cannot
be done in general, linearization cannot be done in general, etc.)

[Bug lto/57703] Assembler function definition moved to a different ltrans then call

[marxin.liska at gmail dot com]

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

--- Comment #2 from Martin Liška <marxin.liska at gmail dot com> ---
Created attachment 30374
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30374&action=edit
syscall.cc
>From gcc-bugs-return-425201-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 26 12:48:36 2013
Return-Path: <gcc-bugs-return-425201-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 22913 invoked by alias); 26 Jun 2013 12:48:36 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 22894 invoked by uid 48); 26 Jun 2013 12:48:33 -0000
From: "marxin.liska at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug lto/57703] Assembler function definition moved to a different ltrans then call
Date: Wed, 26 Jun 2013 12:48:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: lto
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: marxin.liska at gmail dot com
X-Bugzilla-Status: WAITING
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-57703-4-N4Os2H0b1S@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57703-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57703-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg01580.txt.bz2
Content-length: 250

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

--- Comment #3 from Martin Liška <marxin.liska at gmail dot com> ---
Created attachment 30375
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30375&action=edit
Preprocessed syscall.cc
>From gcc-bugs-return-425202-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 26 13:14:43 2013
Return-Path: <gcc-bugs-return-425202-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 14591 invoked by alias); 26 Jun 2013 13:14:43 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 14520 invoked by uid 48); 26 Jun 2013 13:14:39 -0000
From: "burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/29800] -fbounds-check: For derived types, write not also compound name
Date: Wed, 26 Jun 2013 13:14:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.3.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: burnus at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-29800-4-1tKo3gzwSm@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-29800-4@http.gcc.gnu.org/bugzilla/>
References: <bug-29800-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg01581.txt.bz2
Content-length: 177

http://gcc.gnu.org/bugzilla/show_bug.cgi?id)800

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Patch: http://gcc.gnu.org/ml/fortran/2013-06/msg00135.html

[Bug lto/57703] Assembler function definition moved to a different ltrans then call

[marxin.liska at gmail dot com]

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

--- Comment #4 from Martin Liška <marxin.liska at gmail dot com> ---
Hm, it looks that there's an usage of top-level function chromium binary:

/tmp/cckAZyDK.ltrans26.ltrans.o:cckAZyDK.ltrans26.o:function
sandbox::Die::ExitGroup(): error: undefined reference to 'SyscallAsm'
/tmp/cckAZyDK.ltrans26.ltrans.o:cckAZyDK.ltrans26.o:function
sandbox::Die::ExitGroup(): error: undefined reference to 'SyscallAsm'
/tmp/cckAZyDK.ltrans26.ltrans.o:cckAZyDK.ltrans26.o:function
sandbox::Die::SandboxDie(char const*, char const*, int): error: undefined
reference to 'SyscallAsm'
/tmp/cckAZyDK.ltrans26.ltrans.o:cckAZyDK.ltrans26.o:function
sandbox::Trap::SigSys(int, siginfo_t*, void*): error: undefined reference to
'SyscallAsm'


SyscallAsm:
namespace playground2 {

  asm volatile(
# 76 "../../sandbox/linux/seccomp-bpf/syscall.cc"
            ".text\n"
            ".align 16, 0x90\n"
            ".type SyscallAsm, @function\n"
 "SyscallAsm:.cfi_startproc\n"




            "test %rax, %rax\n"
            "jge  1f\n"


            "call 0f;   .cfi_adjust_cfa_offset  8\n"
          "0:pop  %rax; .cfi_adjust_cfa_offset -8\n"
            "addq $2f-0b, %rax\n"
            "ret\n"




          "1:movq  0(%r12), %rdi\n"
            "movq  8(%r12), %rsi\n"
            "movq 16(%r12), %rdx\n"
            "movq 24(%r12), %r10\n"
            "movq 32(%r12), %r8\n"
            "movq 40(%r12), %r9\n"

            "syscall\n"

          "2:ret\n"
            ".cfi_endproc\n"
          "9:.size SyscallAsm, 9b-SyscallAsm\n"
# 172 "../../sandbox/linux/seccomp-bpf/syscall.cc"
  );

If it's not supported feature, how could we handle such situation in LTO?
Assembler functions are commong in all kind video/audio codecs which are often
added to firefox/chromium.

Martin
>From gcc-bugs-return-446734-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Mar 18 16:22:19 2014
Return-Path: <gcc-bugs-return-446734-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 32488 invoked by alias); 18 Mar 2014 16:22:19 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 32457 invoked by uid 48); 18 Mar 2014 16:22:15 -0000
From: "trippels at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/60566] New: [4.9 Regression] r208573 miscompiles kdelibs
Date: Tue, 18 Mar 2014 16:22:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: trippels at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc
Message-ID: <bug-60566-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-03/txt/msg01603.txt.bz2
Content-length: 704

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`566

            Bug ID: 60566
           Summary: [4.9 Regression] r208573 miscompiles kdelibs
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: trippels at gcc dot gnu.org
                CC: jason at gcc dot gnu.org

kdelibs gets miscompiled with current trunk.
Bisection points to r208573.

Symptoms of the miscompilation are startup failures of various KDE application,
e.g. okular will show a pop-up "Cannot connect to okular component" and
hang.
Will look deeper tomorrow.

[Bug lto/57703] Assembler function definition moved to a different ltrans then call

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
This is just totally broken and not supportable with LTO.  We'd need to amend
toplevel asm syntax to list defined and used symbols, but that doesn't fix
existing uses.

The proper fix is to excempt these files from LTO or move those assembler
functions to separate TUs (preferably assembler TUs...).

Honza also had the idea of trying to parse the assembler string for
"obvious" symbol definitions / uses.

[Bug lto/57703] Assembler function definition moved to a different ltrans then call

[jamborm at gcc dot gnu.org]

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

Martin Jambor <jamborm at gcc dot gnu.org> changed:

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

--- Comment #6 from Martin Jambor <jamborm at gcc dot gnu.org> ---
I believe this could be dealt with by forcing all inline assembly from
one compilation unit (including those which were inlined) to end up in
one partition.  If any of them defines a hidden symbol, the assembler
will see it.

This would of course probably be quite ugly hack to the partitioner.
But perhaps we could only enable it by a switch and/or proceed only if
there is a top level assembler in any particular compilation unit.
I suppose definitions of symbols in non-top-level inline assembly is
already fragile because functions can be inlined/cloned etc.

[Bug lto/57703] Assembler function definition moved to a different ltrans then call

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

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

--- Comment #7 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
*** Bug 60690 has been marked as a duplicate of this bug. ***

[Bug lto/57703] Assembler function definition moved to a different ltrans then call

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gmarkhor at gmail dot com

--- Comment #8 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
*** Bug 48947 has been marked as a duplicate of this bug. ***

[Bug lto/57703] Assembler function definition moved to a different ltrans then call

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

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

--- Comment #9 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
*** Bug 64420 has been marked as a duplicate of this bug. ***

[Bug lto/57703] Assembler function definition moved to a different ltrans then call

[amonakov at gcc dot gnu.org]

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

--- Comment #10 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
Bug 64420, which was marked as a duplicate, presents an example where there's
no diagnostics at build time (linking succeeds), but the resulting code is
wrong and will fail at runtime.

I believe the correct fix would be to disable LTO partitioning in a TU that
contains top-level asms (but in that TU only).  Is there something wrong with
such approach?

[Bug lto/57703] Assembler function definition moved to a different ltrans then call

[egallager at gcc dot gnu.org]

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

Eric Gallager <egallager at gcc dot gnu.org> changed:

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

--- Comment #12 from Eric Gallager <egallager at gcc dot gnu.org> ---
Any reason to keep this in WAITING?

[Bug lto/57703] Assembler function definition moved to a different ltrans then call

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marxin at gcc dot gnu.org
             Status|WAITING                     |NEW

--- Comment #13 from Martin Liška <marxin at gcc dot gnu.org> ---
No, it's a known and confirmed problem.

[Bug lto/57703] Assembler function definition moved to a different ltrans then call

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

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

--- Comment #14 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Dup of bug 46820.

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