Code generated by gcc targeting `sh2eb-linux-musl` occasionally
contains duplicate symbols with optimization level `O2` or above
and produces the following errors during assembly:
$ gcc -c -mfdpic -O2 -Wno-int-conversion mintest.c
mintest.s: Assembler messages:
mintest.s:44: Error: symbol `.LPCS0' is already defined
This also occurs when the target is `sh2-linux-musl` but when it
specifically does not target `sh4` (even FDPIC). It does not
occur at optimization levels `O0` or `O1`.
I am using GCC with the following configuration, however, this
may also occur with 7.3.0 (unverified):
GCC : 8.2.0
binutils : 2.31.1
musl : git-39ef61 (2018-11-19)
a minimal test case:
/* mintest.c */
int a, b, c, d;
int *e = (void *)0;
void f ()
for (; d;)
if (b) c = a;
e = e = 1 << c;
the assembly contains:
I could not reproduce this under 6.4.0 or 7.3.0 with binutils of
2.30 (the .LPCS0 sections are not present in the assembly).
Binutils version should not be relevant; the bug here is before anything even gets to binutils. It looks like one of the RTL patterns used for calling libgcc bitshift functions from FDPIC was inteded to be non-duplicable but isn't. This bug goes undetected on J2 (-mj2) target because the J2 has the SH3 barrel shift instructions and does not need libgcc for variable shifts, but affects baseline SH2 ISA. I'll look back at the source and see if I can figure out what's happenning.
You can compile the code with the '-dp' option to see which insn patterns make up the asm code. The pattern names will be emitted as comments in the asm output.
Created attachment 45545 [details]
Tarball containing intermediate asm (with -dp) for each of 5 cases.
The error can be reproduced at `O1` optimization level with both
(strictly both) of the following options:
./cc -c mintest.c -O1 -freorder-blocks-algorithm=stc -ftree-pre
Changing to `-freorder-blocks-algorithm=simple` will not reveal
the issue at `O1`, `O2` or `O3`.
In summary, the only known ways to reproduce this issue are:
(0) `-O2` as described in original bug report;
(1) `-O1 -freorder-blocks-algorithm=stc -ftree-pre`, exclusively
not at any other optimization level;
and the only known ways ot mitigate this issue using either of
the above configurations are:
(2) `-O2 -freorder-blocks-algorithm=simple`;
(3) `-O1` without specifically both of the aforementioned flags.
The attached tarball contains 5 files named by letters 'A' - 'E'
containing the generated assembly, each with -dp` as suggested:
(A) FAIL: `-O2 -freorder-blocks-algorithm=stc`
(B) PASS: `-O2 -freorder-blocks-algorithm=simple`
(C) FAIL: `-O1 -freorder-blocks-algorithm=stc -ftree-pre`
(D) PASS: `-O1 -freorder-blocks-algorithm=simple -ftree-pre`
(E) PASS: `-O1 -freorder-blocks-algorithm=stc`
Created attachment 45546 [details]
All files produced by -O2 -da