Bug 69866 - lto1: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:158
Summary: lto1: internal compiler error: in add_symbol_to_partition_1, at lto/lto-parti...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: lto (show other bugs)
Version: 7.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: lto
: 88550 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-02-18 19:19 UTC by acrsofter
Modified: 2021-12-07 07:31 UTC (History)
1 user (show)

See Also:
Host:
Target: arm-none-eabi
Build:
Known to work: 8.1.0
Known to fail: 5.4.1, 6.1.1, 7.0
Last reconfirmed: 2016-07-20 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description acrsofter 2016-02-18 19:19:37 UTC
lto1: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:158
0x58b14d add_symbol_to_partition_1
	../../gcc-5.3.0/gcc/lto/lto-partition.c:157
0x58aeb2 add_symbol_to_partition_1
	../../gcc-5.3.0/gcc/lto/lto-partition.c:202
0x58c10c lto_balanced_map(int)
	../../gcc-5.3.0/gcc/lto/lto-partition.c:550
0x58640d do_whole_program_analysis
	../../gcc-5.3.0/gcc/lto/lto.c:3324
0x58640d lto_main()
	../../gcc-5.3.0/gcc/lto/lto.c:3485
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
lto-wrapper: fatal error: arm-none-eabi-gcc returned 1 exit status
compilation terminated.
/files/work/acr/wip_elibos/elibos_toolchains/gcc-arm/gcc-arm-none-eabi-5.3.0-a/bin/../lib/gcc/arm-none-eabi/5.3.0/../../../../arm-none-eabi/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
../../../os/common/ports/ARMCMx/compilers/GCC/rules.mk:238: recipe for target 'build/ch.elf' failed
make: *** [build/ch.elf] Error 1



buildind ChibiOS_16.1.3/demos/STM32/RT-STM32F401RE-NUCLEO

https://sourceforge.net/projects/chibios/files/


./arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=./arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/files/work/acr/wip_elibos/elibos_toolchains/gcc-arm/gcc-arm-none-eabi-5.3.0-a/bin/../libexec/gcc/arm-none-eabi/5.3.0/lto-wrapper
Target: arm-none-eabi
Configured with: ../gcc-5.3.0/configure --prefix=/opt/arm_cross --target=arm-none-eabi --enable-languages=c,c++ --disable-multilib --with-newlib
Thread model: single
gcc version 5.3.0 (GCC)
Comment 1 Richard Biener 2016-02-19 08:51:55 UTC
Can you try a recent snapshot and provide a testcase please?
Comment 2 Martin Liška 2016-02-19 10:35:18 UTC
Issue with ChibiOS was already discussed a bit in:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65380#c17

Where a reproducer script uses a base metal compiler.

Martin
Comment 3 acrsofter 2016-02-20 03:25:13 UTC
reproduce steps:

[foo.c]

int _umh(int i)
{
  return i+1;
}

int weaks(int i) __attribute__((weak, alias("_umh")));

int main()
{
 return weaks(10);
}


[bar.c]

int weaks(int i)
{
  return i+1;
}


now compile:

gcc -c bar.c

gcc -flto -c foo.c

gcc -flto -o elf bar.o foo.o


note:

bar compiled without flt
but rest with flt


now at linking stage booms
at line

 gcc_assert (c != SYMBOL_EXTERNAL
      && (c == SYMBOL_DUPLICATE || !symbol_partitioned_p (node)));

in lto/lto-partition.c

===============================================================

same code compiled without lto ok

gcc 4.9.3 not affected
but 5.3.0 affected and latest (gcc-6-20160214) affected
Comment 4 acrsofter 2016-02-23 08:24:56 UTC
someone here can deal with it?
Comment 5 Thomas Preud'homme 2016-07-20 13:05:20 UTC
I can indeed reproduce that bug with latest gcc-5-branch either by compiling the below testcase, or by building ChibiOS 3.0.4 as described in https://answers.launchpad.net/gcc-arm-embedded/+question/280242

Best regards.

(In reply to acrsofter from comment #3)
> reproduce steps:
> 
> [foo.c]
> 
> int _umh(int i)
> {
>   return i+1;
> }
> 
> int weaks(int i) __attribute__((weak, alias("_umh")));
> 
> int main()
> {
>  return weaks(10);
> }
> 
> 
> [bar.c]
> 
> int weaks(int i)
> {
>   return i+1;
> }
> 
> 
> now compile:
> 
> gcc -c bar.c
> 
> gcc -flto -c foo.c
> 
> gcc -flto -o elf bar.o foo.o
> 
> 
> note:
> 
> bar compiled without flt
> but rest with flt
> 
> 
> now at linking stage booms
> at line
> 
>  gcc_assert (c != SYMBOL_EXTERNAL
>       && (c == SYMBOL_DUPLICATE || !symbol_partitioned_p (node)));
> 
> in lto/lto-partition.c
> 
> ===============================================================
> 
> same code compiled without lto ok
> 
> gcc 4.9.3 not affected
> but 5.3.0 affected and latest (gcc-6-20160214) affected
Comment 6 Thomas Preud'homme 2016-07-20 14:16:02 UTC
I can also reproduce both bugs with trunk GCC.
Comment 7 Thomas Preud'homme 2016-07-20 15:44:08 UTC
Update version accordingly.
Comment 8 Martin Liška 2017-02-01 14:17:10 UTC
Is affected just the arm-none-eabi target, or are any others?
Comment 9 Thomas Preud'homme 2017-02-28 11:15:24 UTC
Got a patch that works for this testcase and building ChibiOS 3.0.4. Will run more testing.
Comment 10 Thomas Preud'homme 2017-03-02 14:54:17 UTC
Patch has been submitted for review: https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00110.html
Comment 11 Jan Hubicka 2017-06-15 18:42:42 UTC
Author: hubicka
Date: Thu Jun 15 18:42:10 2017
New Revision: 249224

URL: https://gcc.gnu.org/viewcvs?rev=249224&root=gcc&view=rev
Log:

	PR lto/69866
	* lto-symtab.c (lto_symtab_merge_symbols): Drop useless definitions
	that resolved externally.

	* gcc.dg/lto/pr69866_0.c: New test.
	* gcc.dg/lto/pr69866_1.c: Likewise.

Added:
    trunk/gcc/testsuite/gcc.dg/lto/pr69866_0.c
    trunk/gcc/testsuite/gcc.dg/lto/pr69866_1.c
Modified:
    trunk/gcc/lto/ChangeLog
    trunk/gcc/lto/lto-partition.c
    trunk/gcc/lto/lto-symtab.c
    trunk/gcc/testsuite/ChangeLog
Comment 12 Thomas Preud'homme 2017-06-20 11:20:08 UTC
Author: thopre01
Date: Tue Jun 20 11:19:36 2017
New Revision: 249406

URL: https://gcc.gnu.org/viewcvs?rev=249406&root=gcc&view=rev
Log:
Fix PR69866

2017-06-20  Thomas Preud'homme  <thomas.preudhomme@arm.com>

	Backport from mainline
	2017-06-15  Jan Hubicka  <hubicka@ucw.cz>
		    Thomas Preud'homme  <thomas.preudhomme@arm.com>

	gcc/
	PR lto/69866
	* lto-symtab.c (lto_symtab_merge_symbols): Drop useless definitions
	that resolved externally.
	2017-06-15  Thomas Preud'homme  <thomas.preudhomme@arm.com>

	gcc/testsuite/
	PR lto/69866
	* gcc.dg/lto/pr69866_0.c: New test.
	* gcc.dg/lto/pr69866_1.c: Likewise.

	Backport from mainline
	2017-06-18  Jan Hubicka  <hubicka@ucw.cz>

	gcc/testsuite/
	* gcc.dg/lto/pr69866_0.c: This test needs alias.

Added:
    branches/ARM/embedded-6-branch/gcc/lto/ChangeLog.arm
    branches/ARM/embedded-6-branch/gcc/testsuite/gcc.dg/lto/pr69866_0.c
    branches/ARM/embedded-6-branch/gcc/testsuite/gcc.dg/lto/pr69866_1.c
Modified:
    branches/ARM/embedded-6-branch/gcc/lto/lto-symtab.c
    branches/ARM/embedded-6-branch/gcc/testsuite/ChangeLog.arm
Comment 13 Thomas Preud'homme 2017-06-21 08:18:28 UTC
Author: thopre01
Date: Wed Jun 21 08:17:56 2017
New Revision: 249437

URL: https://gcc.gnu.org/viewcvs?rev=249437&root=gcc&view=rev
Log:
2017-06-21  Thomas Preud'homme  <thomas.preudhomme@arm.com>

	Revert:

	Backport from mainline
	2017-06-15  Thomas Preud'homme  <thomas.preudhomme@arm.com>

	PR lto/69866
	* gcc.dg/lto/pr69866_0.c: New test.
	* gcc.dg/lto/pr69866_1.c: Likewise.

	Backport from mainline
	2017-06-18  Jan Hubicka  <hubicka@ucw.cz>

	* gcc.dg/lto/pr69866_0.c: This test needs alias.


Removed:
    branches/ARM/embedded-6-branch/gcc/lto/ChangeLog.arm
    branches/ARM/embedded-6-branch/gcc/testsuite/gcc.dg/lto/pr69866_0.c
    branches/ARM/embedded-6-branch/gcc/testsuite/gcc.dg/lto/pr69866_1.c
Modified:
    branches/ARM/embedded-6-branch/gcc/lto/lto-symtab.c
    branches/ARM/embedded-6-branch/gcc/testsuite/ChangeLog.arm
Comment 14 Thomas Preud'homme 2017-11-28 15:19:45 UTC
Author: thopre01
Date: Tue Nov 28 15:19:14 2017
New Revision: 255203

URL: https://gcc.gnu.org/viewcvs?rev=255203&root=gcc&view=rev
Log:
Fix ICE in add_symbol_to_partition_1

2017-11-28  Thomas Preud'homme  <thomas.preudhomme@arm.com>

	Backport from mainline
	2017-06-15  Jan Hubicka  <hubicka@ucw.cz>
		    Thomas Preud'homme  <thomas.preudhomme@arm.com>

	gcc/lto/
	PR lto/69866
	* lto-symtab.c (lto_symtab_merge_symbols): Drop useless definitions
	that resolved externally.

	Backport from mainline
	2017-06-15  Thomas Preud'homme  <thomas.preudhomme@arm.com>

	gcc/testsuite/
	PR lto/69866
	* gcc.dg/lto/pr69866_0.c: New test.
	* gcc.dg/lto/pr69866_1.c: Likewise.


Added:
    branches/ARM/embedded-7-branch/gcc/lto/ChangeLog.arm
    branches/ARM/embedded-7-branch/gcc/testsuite/gcc.dg/lto/pr69866_0.c
    branches/ARM/embedded-7-branch/gcc/testsuite/gcc.dg/lto/pr69866_1.c
Modified:
    branches/ARM/embedded-7-branch/gcc/lto/lto-partition.c
    branches/ARM/embedded-7-branch/gcc/lto/lto-symtab.c
    branches/ARM/embedded-7-branch/gcc/testsuite/ChangeLog.arm
Comment 15 Thomas Preud'homme 2018-05-05 10:03:51 UTC
Fixed in r249224 and thus fixed on 8.1
Comment 16 Thomas Preud'homme 2018-07-13 12:11:50 UTC
@honza: would you mind backporting to GCC 7? IIRW GCC 6 backport is more tricky.

Thanks!
Comment 17 GCC Commits 2020-12-05 18:30:17 UTC
The master branch has been updated by Maciej W. Rozycki <macro@gcc.gnu.org>:

https://gcc.gnu.org/g:76a553587f3181605c57801c37b0d3e94ce3aca5

commit r11-5795-g76a553587f3181605c57801c37b0d3e94ce3aca5
Author: Maciej W. Rozycki <macro@linux-mips.org>
Date:   Sat Dec 5 18:26:27 2020 +0000

    VAX: Fix the LTO compiler downgrading code to non-PIC model
    
    Fix a testsuite failure:
    
    /tmp/ccL65Mmt.s: Assembler messages:
    /tmp/ccL65Mmt.s:36: Warning: Symbol n used as immediate operand in PIC mode.
    FAIL: gcc.dg/lto/pr55660 c_lto_pr55660_0.o-c_lto_pr55660_1.o link, -O0 -flto -flto-partition=none -fuse-linker-plugin
    
    where non-PIC code is substituted by the LTO compiler at the link stage
    for what used to be PIC code in the original compilation.  This happens
    because in the de-facto VAX ELF psABI we rely on code being PIC for GOT
    support in dynamic executables and arrange that by having `-fPIC' passed
    to the compiler by default by means of a specs recipe.
    
    That is however canceled where the LTO wrapper is used, by an internal
    arrangement in the LTO compiler that clears the PIC flag whenever the
    `-flinker-output=exec' option has been used.  This has been deliberately
    introduced with commit 1ff9ed6fb282 ("re PR lto/67548 (LTO drops weak
    binding with "ld -r")")[1]:
    
    "In the log of PR67548 HJ actually pointed out that we do have API at
    linker plugin side which says what type of output is done.  This is cool
    because we can also use it to drop -fpic when building static binary.
    This is common in Firefox, where some objects are built with -fpic and
    linked to both binaries and libraries."
    
    with this code:
    
        case LTO_LINKER_OUTPUT_EXEC: /* Normal executable */
          flag_pic = 0;
          flag_pie = 0;
          flag_shlib = 0;
          break;
    
    Consequently code like:
    
    .L6:
            addl3 -8(%fp),$n,%r0
            pushl %r0
            calls $1,foo
            addl2 %r0,-12(%fp)
            incl -8(%fp)
    .L5:
    
    is produced by the LTO compiler, where a reference to `n' is used that
    is invalid in PIC code, because it uses the immediate addressing mode,
    denoted by the `$' prefix.
    
    For that not to happen we must never pass `-flinker-output=exec' to the
    LTO compiler unless non-PIC code has been explicitly requested.  Using
    `-flinker-output=dyn' except for relocatable output would seem the
    simplest approach, as it does not fiddle with any of the internal code
    model settings beyond what the command-line options have arranged and
    therefore lets them remain the same as with the original compilation,
    but it breaks as well causing PR lto/69866 to retrigger, as that code
    seems sensitive to `flag_shlib':
    
    lto1: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:152
    0x105be1cb add_symbol_to_partition_1
            .../gcc/lto/lto-partition.c:152
    0x105be443 add_symbol_to_partition_1
            .../gcc/lto/lto-partition.c:194
    0x105be80f add_symbol_to_partition
            .../gcc/lto/lto-partition.c:270
    0x105bee6f add_sorted_nodes
            .../gcc/lto/lto-partition.c:395
    0x105c0903 lto_balanced_map(int, int)
            .../gcc/lto/lto-partition.c:815
    0x105aa91f do_whole_program_analysis
            .../gcc/lto/lto.c:499
    0x105aac97 lto_main()
            .../gcc/lto/lto.c:637
    Please submit a full bug report,
    with preprocessed source if appropriate.
    Please include the complete backtrace with any bug report.
    See <https://gcc.gnu.org/bugs/> for instructions.
    lto-wrapper: fatal error: .../gcc/xgcc returned 1 exit status
    compilation terminated.
    .../usr/bin/vax-netbsdelf-ld: error: lto-wrapper failed
    collect2: error: ld returned 1 exit status
    compiler exited with status 1
    FAIL: gcc.dg/lto/pr69866 c_lto_pr69866_0.o-c_lto_pr69866_1.o link, -O0 -flto -fuse-linker-plugin -fno-fat-lto-objects  (internal compiler error)
    
    Substitute `-flinker-output=pie' for `-flinker-output=exec' in the specs
    then unless `-no-pie' has also been used, preserving the original intent
    of emitting PIC code by default for executables while keeping the linker
    arrangement unchanged.  The LTO compiler uses the `cc1' spec, so keep
    `cc1plus' unmodified.
    
    This makes code like:
    
    .L6:
            movab n,%r0
            addl2 -8(%fp),%r0
            pushl %r0
            calls $1,foo
            addl2 %r0,-12(%fp)
            incl -8(%fp)
    .L5:
    
    be produced instead corresponding to the fragment quoted above, which is
    valid PIC code as it uses the PC-relative addressing mode denoted by the
    absence of a prefix to `n' (which can be redirected to GOT as required,
    by changing the addressing mode to PC-relative indirect in the operand
    specifier).
    
    Ideally we would instead default to the PIE model for executables, but
    that triggers a BFD bug where for a change the LTO wrapper is not used:
    
    .../usr/bin/vax-netbsdelf-ld: /tmp/ccV2sWQt.ltrans0.ltrans.o: warning: GOT addend of 3 to `n' does not match previous GOT addend of 0
    FAIL: gcc.dg/lto/pr55660 c_lto_pr55660_0.o-c_lto_pr55660_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin
    
    which is due to assembly code like:
    
    main:
            .word 0
            subl2 $4,%sp
            movab n,%r0
            movab n+3,%r2
            clrl %r3
            movb $98,%r1
    .L4:
    
    and consequently object code like:
    
    00000000 <main>:
       0:   00 00           .word 0x0000 # Entry mask: < >
       2:   c2 04 5e        subl2 $0x4,sp
       5:   9e ef 00 00     movab b <main+0xb>,r0
       9:   00 00 50
                            7: R_VAX_GOT32  n
       c:   9e ef 00 00     movab 12 <main+0x12>,r2
      10:   00 00 52
                            e: R_VAX_GOT32  n+0x3
      13:   d4 53           clrf r3
      15:   90 8f 62 51     movb $0x62,r1
    
    being produced.  This would be problematic for external `n', because we
    do not support multiple GOT entries for the same symbol referred to with
    different offsets in a single link unit.  In this case however the LTO
    compiler correctly observes that `n' is defined by the executable and
    not preemptible and therefore no GOT entry will be made for it.
    
    Indeed a valid executable is produced:
    
    00010548 <main>:
       10548:       00 00           .word 0x0000 # Entry mask: < >
       1054a:       c2 04 5e        subl2 $0x4,sp
       1054d:       9e ef dd 14     movab 11a30 <n>,r0
       10551:       00 00 50
       10554:       9e ef d9 14     movab 11a33 <__bss_start>,r2
       10558:       00 00 52
       1055b:       d4 53           clrf r3
       1055d:       90 8f 62 51     movb $0x62,r1
    
    despite the warning, but it would be rather bad to have users annoyed
    with this message from BFD, however harmless, especially as it triggers
    outside LTO compilations as well.
    
    Therefore this change is the best we can do until binutils have been
    fixed.
    
    References:
    
    [1] Jan Hubicka, "Getting LTO incremental linking work",
        <https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02986.html>
    
            gcc/
            * config/vax/elf.h (VAX_CC1_SPEC, VAX_CC1PLUS_SPEC): New macros.
            * config/vax/netbsd-elf.h (CC1_SPEC): Use VAX_CC1_SPEC rather
            than VAX_CC1_AND_CC1PLUS_SPEC.
            (CC1PLUS_SPEC): Use VAX_CC1PLUS_SPEC rather than
            VAX_CC1_AND_CC1PLUS_SPEC.
Comment 18 Richard Biener 2021-12-07 07:26:57 UTC
Fixed.
Comment 19 Richard Biener 2021-12-07 07:31:07 UTC
*** Bug 88550 has been marked as a duplicate of this bug. ***