[Bug c/63435] New: Bad code with weak vs localalias on AIX

[Bug c/63435] New: Bad code with weak vs localalias on AIX

[gcc at dixie dot net.nz]

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

            Bug ID: 63435
           Summary: Bad code with weak vs localalias on AIX
           Product: gcc
           Version: 4.9.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gcc at dixie dot net.nz
              Host: powerpc-ibm-aix7.1.0.0
            Target: powerpc-ibm-aix7.1.0.0
             Build: powerpc-ibm-aix7.1.0.0

Created attachment 33638
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33638&action=edit
testcase

Consider attached testcase.

The recvfrom function is generated as a weak symbol,
symtab_node::noninterposable_alias creates a localalias.
        .weak   recvfrom[DS]
        .weak   .recvfrom
        .csect recvfrom[DS]
recvfrom:
        .long .recvfrom, TOC[tc0], 0
        .csect .text[PR]
.recvfrom:

-------

gcc-4.9.1 generates local alias to the weak symbol:
        .lglobl .recvfrom.localalias.0
        .lglobl recvfrom.localalias.0
        .set    .recvfrom.localalias.0,.recvfrom
        .set recvfrom.localalias.0,recvfrom

-------

This local alias is called with local calling convention (missing nop):
        bl .recvfrom.localalias.0
        mr 9,3

-------

The linker discards the weak local recvfrom symbol, and chooses recvfrom from
libc.
The recvfrom in libc is remote and needs a nop instruction.

The linker correctly issues a diagnostic about this:
ld: 0711-768 WARNING: Object myrecvfrom.o, section 1, function .recvfrom:
        The branch at address 0xc8 is not followed by a recognized no-op
        or TOC-reload instruction. The unrecognized instruction is 0x7C691B78.

At runtime this results in corrupt TOC pointer (possibly requires larger
testcase to observe problems).

[Bug c/63435] Bad code with weak vs localalias on AIX

[gcc at dixie dot net.nz]

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

Andrew Dixie <gcc at dixie dot net.nz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dje at gcc dot gnu.org,
                   |                            |hubicka at gcc dot gnu.org

--- Comment #1 from Andrew Dixie <gcc at dixie dot net.nz> ---
This is a regression sometime between gcc-4.4 and gcc-4.9

Looks like it was fixed in gcc-5 by:
https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00500.html

[Bug target/63435] Bad code with weak vs localalias on AIX

[hubicka at ucw dot cz]

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

--- Comment #2 from Jan Hubicka <hubicka at ucw dot cz> ---
Yes,
good to remind me.  The aliases are quite broken on AIX pre 4.9
and becasue some of them are now auto generated, we probably ought
to fix it.  One solution would be to disable generation of aliases, other
would be to backport this patch.
David, I think we did not encounter any issues with the new code?

Honza

[Bug target/63435] Bad code with weak vs localalias on AIX

[gcc at dixie dot net.nz]

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

--- Comment #4 from Andrew Dixie <gcc at dixie dot net.nz> ---
I tried gcc-5-20140928 snapshot

This snapshot doesn't generate a localalias for the testcase, and it generates
very few localalias symbols in general.

There was only one localalias symbol produced in the entire gcc build tree:
[1228]  m   0x0000041c         1     1    0x6b         0x0000    
._ZNKSt14error_category23default_error_conditionEi.localalias.7
[1492]  m   0x00000b30         2     1    0x6b         0x0000    
_ZNKSt14error_category23default_error_conditionEi.localalias.7
[1578]  m   0x00000c6c         2     1    0x6b         0x0000    
_ZNKSt14error_category23default_error_conditionEi.localalias.7

Maybe there is something else wrong with gcc-4.9 that is causing it to generate
localalias symbols too aggressively?

We forced symtab_node::noninterposable_alias to return NULL on AIX.  This
resolved all the failures we were seeing in our application testsuite.

[Bug target/63435] Bad code with weak vs localalias on AIX

[hubicka at ucw dot cz]

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

--- Comment #5 from Jan Hubicka <hubicka at ucw dot cz> ---
There are three problems in 4.9 and earlier
  - the aliases are produced incorrectly because AIX's as alias keyword does
not do what is expected
    (it does kind of syntactic replacement combined with something else)
  - MAKE_ONE_ONLY is not defined making compiler to believe that linker does
    not perfrom garbage collection
  - Linker's garbage collection was disabled, so in particular all duplicated
comdats stays
    in the code.

Lack of MAKE_ONE_ONLY makes GCC to produce a lot more local aliases, because it
makes sense to refer to a function by local relocation instead of lgobal when
we know it is going to stay. Together with the as issue this leads to wrong
code.

You can work around by forcing local alias to return NULL for AIX to disable
some
of local aliases.  There are other two cases where GCC produce such symbols (in
addition of user declaring it by hand in source code via the alias attribute).
It
is the thunk generation (I suppose this one works as it is there for ages)
and the new comdat local code in C++ (that is used only by -Os codegen path at
4.9).

[Bug target/63435] Bad code with weak vs localalias on AIX

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |streibel.2003 at gmx dot net

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 67950 has been marked as a duplicate of this bug. ***