[Bug c++/108361] New: Assembly code that is never called emitted on x86_64

[Bug c++/108361] New: Assembly code that is never called emitted on x86_64

[eric-bugs at omnifarious dot org]

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

            Bug ID: 108361
           Summary: Assembly code that is never called emitted on x86_64
           Product: gcc
           Version: 12.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: eric-bugs at omnifarious dot org
  Target Milestone: ---

Created attachment 54236
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54236&action=edit
Preprocessed C++ code that generates unneeded assembly

The nature of this bug makes a concise test case hard to whittle down to
something minimal...

The attached code generates a whole bunch of assembly that isn't needed. This
assembly references external symbols as well, which creates unnecessary linker
errors.

Clang handles it just fine. :-)

Attached is both the preprocessed C++ code, and the assembly it generates. The
only needed assembly is the code for main and the static data main needs.

_start is defined as a global in a separate file, which is also attached.

The compile command I'm using:

g++ -std=c++20 -march=znver2 -static -O3 -nostartfiles -nostdlib
-I/usr/include/c++/12 -I/home/hopper/src/posixpp/pubincludes -Wl,-e_start
preprocessed.s x86_64_start.s

[Bug c++/108361] Assembly code that is never called emitted on x86_64

[eric-bugs at omnifarious dot org]

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

--- Comment #1 from eric-bugs at omnifarious dot org ---
Created attachment 54237
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54237&action=edit
Assembly file containing _start

[Bug c++/108361] Assembly code that is never called emitted on x86_64

[eric-bugs at omnifarious dot org]

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

--- Comment #2 from eric-bugs at omnifarious dot org ---
Created attachment 54238
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54238&action=edit
Assembly output from compiler

[Bug c++/108361] Assembly code that is never called emitted on x86_64

[pinskia at gcc dot gnu.org]

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

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

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
std::system_error::system_error is definitely originally called in the source.

Just that after inlining and some optimizations, the call is removed from the
call from main.

The missed optimization is a dup of bug 99373.

But the linker errors is a bug in your code really.

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

[Bug c++/108361] Assembly code that is never called emitted on x86_64

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #3)
> But the linker errors is a bug in your code really.

Because the original code has references to both std::string and
std::system_error .

[Bug c++/108361] Assembly code that is never called emitted on x86_64

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Sorry PR 89139.

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

[Bug c++/108361] Assembly code that is never called emitted on x86_64

[eric-bugs at omnifarious dot org]

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

--- Comment #6 from eric-bugs at omnifarious dot org ---
Technically, I suppose it is. I do reference those things in the original code.
:-)

But it is sort of annoying to get the error when I can just edit the assembly
and clip out the offending code with no effect other than to remove the error.
At any rate, yes, it's a duplicate. And thank you.