[Bug demangler/114830] c++filt stack overflows in rust demangler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114830 --- Comment #2 from Alan Modra --- Created attachment 58021 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58021=edit c++filt crash binaries
[Bug demangler/114830] c++filt stack overflows in rust demangler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114830 --- Comment #1 from Alan Modra --- Created attachment 58020 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58020=edit asan report summary
[Bug demangler/114830] New: c++filt stack overflows in rust demangler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114830 Bug ID: 114830 Summary: c++filt stack overflows in rust demangler Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: demangler Assignee: unassigned at gcc dot gnu.org Reporter: amodra at gmail dot com Target Milestone: --- >From zhoug...@mail.zgclab.edu.cn and wan...@mail.zgclab.edu.cn: Hi, we found several crashes in c++filt(Binutils 2.42), which is the latest version. In detail, it contains 12 stack-buffer-overflow triggering methods. To assist in diagnosing and resolving these issues, we have attached the POC files along with the gdb/asan logs. Environment: Linux 4f6b99b5cf37 6.2.0-35-generic #35~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Fri Oct 6 10:23:26 UTC 2 x86_64 x86_64 x86_64 GNU/Linux Credit by: Wang Dawei and Zhou Geng, from Zhongguancun Laboratory. Thanks for your time and attention to these matters. Best regards, Zhou Geng
[Bug target/113652] [14 regression] Failed bootstrap on ppc unrecognized opcode: `lfiwzx' with -mcpu=7450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #14 from Alan Modra --- (In reply to Kewen Lin from comment #11) > I wonder if assembler can enable POWER7 when PPCVSX gets enabled like what > gcc adopts now? That wouldn't be a solution, because gcc needs to deal with older assemblers that won't have such a change. I don't have a strong opinion on whether newer versions of gas ought to enable all power7 instructions when given -mvsx, but I can say that -mvsx followed the precedent of other similar options, eg. -maltivec, -mlsp, where the option adds instructions for some function unit to the current cpu supported.
[Bug target/93176] PPC: inefficient 64-bit constant consecutive ones
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93176 Alan Modra changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|amodra at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #8 from Alan Modra --- Nothing happened. The patch wasn't reviewed. I didn't ping the patch. I'm not working on gcc any more, so should remove myself as assignee for this bug.
[Bug sanitizer/109308] False positive store to address 0x62600000016c with insufficient space for an object of type 'int' since r12-6030-g422f9eb7011b76c1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109308 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #4 from Alan Modra --- I agree the code is undefined, but "store to address 0x004172b0 with insufficient space for an object of type 'long int'" is a lie. There plainly *is* sufficient space at that address. It would be nice to diagnose the actual undefined behaviour. As a compiler developer you might have the mindset of "it's undefined code so the compiler can do anything", but that argument strikes me as disingenuous when we are talking about -fsanitize=undefined!
[Bug libgcc/108727] gcc.dg/split-5.c fails on power 9 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108727 --- Comment #3 from Alan Modra --- Yes, looks good to me.
[Bug target/108315] -mcpu=power10 changes ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #5 from Alan Modra --- Any caller of bar should be fine. The localentry value of 1 means it is advertised as having no requirement on r2 or r12 and r2 is *not* preserved. A call that uses R_PPC64_REL24 to bar ought to have an r2 saving stub inserted by the linker and the nop after the call changed to restore r2. GNU ld will do exactly that. 1540 <0047.long_branch.bar>: 1540: 18 00 41 f8 std r2,24(r1) 1544: 4c 02 00 48 b 1790 ... 15a0 : 15a0: 02 10 40 3c lis r2,4098 15a4: 00 7f 42 38 addir2,r2,32512 15a8: a6 02 08 7c mflrr0 15ac: 00 00 00 60 nop 15b0: 20 80 62 e8 ld r3,-32736(r2) 15b4: 10 00 01 f8 std r0,16(r1) 15b8: e1 ff 21 f8 stdur1,-32(r1) 15bc: 85 ff ff 4b bl 1540 <0047.long_branch.bar> 15c0: 18 00 41 e8 ld r2,24(r1) There isn't a problem if bar is passed the address of a non-pcrel function in a shared library as it is in your example. The call in bar will go to the global entry point of foo, which will set up r2. The same thing happens when linking against foo.o, the function pointer address is that of the global entry of foo. [amodra@gcc135 p10-interop]$ ./smain Hello from foo Hello, World! (My dynamic main won't run on gcc135 due to my build machine having a more recent glibc, but I'm confident it would run if I fixed that.) I don't see any problem here other than (presumably) missing linker support.
[Bug modula2/108147] Bootstrap failure on powerpc64le-linux with m2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108147
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #14 from Alan Modra ---
In C it would also be OK to simply not prototype the problem functions. No
prototype is better than a lying prototype..
eg.
void f1 (int, int);
void f2 (int, ...);
void f3 ();
int g1 (void) { f1 (1, 2); return 0; }
int g2 (void) { f2 (1, 2); return 0; }
int g3 (void) { f3 (1, 2); return 0; }
shows g1 with a frame of 32 bytes, g2 and g3 with 96.
We hit this sort of problem on ELFv2 because the ABI allows omitting the
64-byte paramater save area when the callee is known not to use it. The idea
of course is to minimize stack frames. (ELFv2 minimum frame is 32 bytes, ELFv1
which always allocates param save has a minimum of 112 byes.) Variadic
functions on both ABIs make use of the parameter save area because PowerPC64
uses a simple va_list type, a pointer to memory, requiring variadic functions
to save incoming arguments in registers to the parameter save area.
[Bug target/97361] power10 unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97361 Alan Modra changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Alan Modra --- The bug report is nearly two years old, against gcc-11.0. I'd forgotten about it. Retesting just now shows current mainline does not hit the ICE, nor does current tip of gcc-11 branch.
[Bug target/99888] Add powerpc ELFv2 support for -fpatchable-function-entry*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99888 --- Comment #8 from Alan Modra --- (In reply to Segher Boessenkool from comment #7) > '-fpatchable-function-entry=N[,M]' > Generate N NOPs right at the beginning of each function, with the > function entry point before the Mth NOP. Bad doco. Should be "after the Mth NOP" I think. Or better written to avoid the concept of a 0th nop. Default for M is zero, placing all nops after the function entry and before normal function prologue code. > The nops have to be consecutive. I hope you are making this statement based on an analysis of the purpose of having M nops before the entry point and N-M after the entry point, because the documentation you are quoting doesn't take into account the fact that ELFv2 functions have two entry points. We don't have "the" entry point. I admit I didn't analyse -fpatchable-function-entry usage in any depth before writing the patches in PR98125. All I did was look at the linux kernel to the point of deciding that we want a patchable area after the local entry point to catch all calls to the function. That would be what -fpatchable-function-entry=n does for ELFv2, and I think we all agree on that. Why would someone want nops before a function entry? Perhaps as space for a pointer. Or perhaps as the main patch area branched to from patched code after the entry, to limit number of nops executed in an unpatched function. Or perhaps so that the function can be called by a trampoline or via function pointer, to select either some extra code replacing those nops or the normal function entry. I think that means M nops go before the global entry point. (Note that the patch area before a function could well duplicate the normal global entry code.) I agree with comment #5. nops *inside* the global entry code are a daft idea.
[Bug target/104894] [11/12 Regression] ICE with -fno-plt -mcpu=power10 on PowerPC64 LE Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104894 --- Comment #7 from Alan Modra --- So, similar code to what we have in rs6000_call_aix to handle if ((INTVAL (cookie) & CALL_LONG) != 0 && GET_CODE (func_desc) == SYMBOL_REF) should be added to rs6000_sibcall_aix, I think.
[Bug target/104894] [11/12 Regression] ICE with -fno-plt -mcpu=power10 on PowerPC64 LE Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104894
--- Comment #6 from Alan Modra ---
I'm sorry, I forgot exactly what was happening when I talked about this on the
call. What I should have said is that -mlongcall code is correct but is
missing a sibcall optimisation. -fno-plt code (after removing the assert or
using your patch) is incorrect. A direct call is wrong, because it may require
a plt call stub. gcc ought to be producing an inline plt call. Change the
testcase to
void foo();
void bar() {
foo();
foo();
}
to see what I mean. The asm output is
mflr 0
std 0,16(1)
stdu 1,-96(1)
.cfi_def_cfa_offset 96
.cfi_offset 65, 16
pld 12,0(0),1
.reloc .-8,R_PPC64_PLT_PCREL34_NOTOC,foo
mtctr 12
.reloc .-4,R_PPC64_PLTSEQ,foo
.reloc .,R_PPC64_PLTCALL_NOTOC,foo
bctrl
addi 1,1,96
.cfi_def_cfa_offset 0
ld 0,16(1)
mtlr 0
.cfi_restore 65
b foo@notoc
That "b foo@notoc" ought to be
pld 12,0(0),1
.reloc .-8,R_PPC64_PLT_PCREL34_NOTOC,foo
mtctr 12
.reloc .-4,R_PPC64_PLTSEQ,foo
.reloc .,R_PPC64_PLTCALL_NOTOC,foo
bctr
[Bug demangler/105039] New: rust demangler stack overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105039 Bug ID: 105039 Summary: rust demangler stack overflow Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: demangler Assignee: unassigned at gcc dot gnu.org Reporter: amodra at gmail dot com Target Milestone: --- >From https://sourceware.org/bugzilla/show_bug.cgi?id=28995 c++filt _RYAaca_NRYAaBa_a AddressSanitizer:DEADLYSIGNAL = ==4145846==ERROR: AddressSanitizer: stack-overflow on address 0x7ffd205e8ff8 (pc 0x021dfea9 bp 0x005f sp 0x7ffd205e9000 T0) #0 0x21dfea9 in peek /home/alan/src/binutils-gdb/libiberty/rust-demangle.c:90 #1 0x21dfd8c in eat /home/alan/src/binutils-gdb/libiberty/rust-demangle.c:99:7 #2 0x21e1bb4 in parse_integer_62 /home/alan/src/binutils-gdb/libiberty/rust-demangle.c:125:7 #3 0x21e2019 in demangle_const /home/alan/src/binutils-gdb/libiberty/rust-demangle.c:1153:17 #4 0x21e20a7 in demangle_const /home/alan/src/binutils-gdb/libiberty/rust-demangle.c:1158:11 and lots more at 1158:11. This is with libiberty sources from gcc commit 4cebae0924248b.
[Bug target/104894] [11/12 Regression] ICE with -fno-plt -mcpu=power10 on PowerPC64 LE Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104894 --- Comment #4 from Alan Modra --- Do check that the result is not a direct call. I think I was wrong to say the assert could be removed (or modified as you have done).
[Bug target/104894] [11/12 Regression] ICE with -fno-plt -mcpu=power10 on PowerPC64 LE Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104894 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com Last reconfirmed||2022-03-15 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Alan Modra --- Regressed with 95f17e26112d8a0 "rs6000: Enable more sibcalls when TOC is not preserved". Likely "gcc_assert (INTVAL (cookie) == 0);" in rs6000_sibcall_aix can just be deleted.
[Bug target/104671] -Wa,-m no longer has any effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104671
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #3 from Alan Modra ---
(In reply to Nicholas Piggin from comment #0)
> Commit e154242724b084380e3221df7c08fcdbd8460674 ("Don't pass -many to the
> assembler") also added a workaround emitting a ".machine" directive to the
> top of each generated .s file
Nope, wrong commit. The added .machine there is one in response to an
attribute or pragma selecting a different cpu. ie. it's in response to user
source code saying "compile this function for this particular cpu, not
necessarily the one given on the gcc command line".
Commit b9f12a01bedb5 is the first commit that added .machine to the top of
assembly files. The early .machine was not always emitted by that particular
commit. Always emitting the early .machine came later.
[Bug target/102485] -Wa,-many no longer has any effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102485 --- Comment #10 from Alan Modra --- I have spent some time over the last few days digging into history relevant to this bug as part of looking into a binutils report that an ARCH=powerpc CROSS_COMPILE=powerpc-linux- pmac32_defconfig linux kernel no longer builds with binutils-2.38. As a result I've partly reverted the effect of binutils commit "ignore sticky options for .machine", on both mainline binutils and the 2.38 branch. Given the way gcc operates, that commit was a mistake on my part. The initial .machine passed by gcc will again keep -many, -maltivec, -mvsx, -mvle, -mspe or -mspe2 in effect. A .machine later in an assembly file, after some output to any section (even .align counts), will be more strictly enforced. That's the best I can do to solve this mess. It does not completely fix this bug, which I believe is a valid complaint. For instance a user who has power10 asm() but does not want gcc generated power10 code, perhaps due to a gcc code gen bug, might like to use -mcpu=power9 -Wa,-mpower10 on the gcc command line. Instead they would be forced to write ".machine power10" in their asm. (Ideally, .machine push; .machine power10; user asm; .machine pop, on each use of power10 instructions.) At least, that is the case for current mainline gcc and binutils-2.38 where even "-mcpu=power9 -Wa,-many" won't work. We simply cannot dictate to users that their assembly needs rewriting. A lot of this came about by accident. On the gas side, it was by accident that any of the gas command line cpu options were sticky for .machine. The intent behind the sticky options was to support people writing gas command lines like "-maltivec -mppc" as well as the canonical "-mppc -maltivec". When you consider that gas also needs to support multiple cpu options on a command line, with the last overriding any previous selection, it is more obvious why options that add functional units like -maltivec are special. On the gcc side, we have pr59828 and commit b9f12a01bedb5 which is where gcc started to emit .machine rather than passing correct arguments to gas. Current mainline gcc continues to pass the wrong cpu to gas on the command line when multiple -mcpu options are given to gcc, as can be seen by examining -v output from the kernel compile mentioned above. There have been multiple gcc bug reports about that .machine directive, pr71216, pr91050, pr101393 to point out some. This means there are versions of gcc in widespread use that pass an incorrect .machine to gas, which is why I say my gas change to make .machine more strict was a mistake. We can't expect the kernel and other users of the toolchain to cope with gas using wrong cpu info if -many is disabled by .machine. Of course, the bugs in .machine might have been found earlier if -many hadn't been covering them. Similarly for bugs in the linux kernel makefiles; mfsrin and mtsrin are not ppc64 instructions. Overall, I think using .machine as a workaround for pr59828 was a mistake, especially since digging into this bug reminded me that I'd submitted a conceptually simple patch to fix pr59828 by passing on all the cpu args to gas. Which went unreviewed for a whole year before being dismissed.
[Bug middle-end/95126] [9/10/11/12 Regression] Missed opportunity to turn static variables into immediates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95126 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #5 from Alan Modra --- The gcc-5.1.0 code is incorrect. It loads past the end of s, which is only 2-byte aligned.
[Bug demangler/103893] New: ada demangler heap overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103893 Bug ID: 103893 Summary: ada demangler heap overflow Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: demangler Assignee: unassigned at gcc dot gnu.org Reporter: amodra at gmail dot com Target Milestone: --- >From https://sourceware.org/bugzilla/show_bug.cgi?id=28736 valgrind c++filt -s gnat vfSO__fffSO ==1573233== Invalid write of size 1 ==1573233==at 0x4848DCC: strcpy (vg_replace_strmem.c:523) ==1573233==by 0x72688C: ada_demangle (cplus-dem.c:338) ==1573233==by 0x726ABA: cplus_demangle (cplus-dem.c:187) ==1573233==by 0x4038E8: demangle_it (cxxfilt.c:66) ==1573233==by 0x403AEC: main (cxxfilt.c:203) ==1573233== Address 0x4a60057 is 0 bytes after a block of size 23 alloc'd ==1573233==at 0x4842839: malloc (vg_replace_malloc.c:380) ==1573233==by 0x737A6B: xmalloc (xmalloc.c:147) ==1573233==by 0x726617: ada_demangle (cplus-dem.c:223) ==1573233==by 0x726ABA: cplus_demangle (cplus-dem.c:187) ==1573233==by 0x4038E8: demangle_it (cxxfilt.c:66) ==1573233==by 0x403AEC: main (cxxfilt.c:203) The following comment in cplus-dem.c:ada_demangle is false for fuzzed input, specifically the part that says "they occur only once". /* Most of the demangling will trivially remove chars. Operator names may add one char but because they are always preceeded by '__' which is replaced by '.', they eventually never expand the size. A few special names such as '___elabs' add a few chars (at most 7), but they occur only once. */ len0 = strlen (mangled) + 7 + 1; demangled = XNEWVEC (char, len0);
[Bug rtl-optimization/63281] powerpc64le creates 64 bit constants from scratch instead of loading them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63281 --- Comment #15 from Alan Modra --- (In reply to Jiu Fu Guo from comment #14) > It would be a way to keep the data in memory(.rodata) through adjusting the > cost of constant. Yes, I posted a series of patches that fix this problem and other rtx costs. Look for patches with "rs6000_rtx_costs" in the subject. Some of the patches were even approved, but not all in the series. I am disillusioned enough with gcc that I won't be pushing those patches or attempting any future gcc work. You or anyone else are welcome to pick up the pieces.
[Bug target/103197] ppc inline expansion of memcpy/memmove should not use lxsibzx/stxsibx for a single byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103197 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #7 from Alan Modra --- (In reply to acsawdey from comment #2) > From the reload dump: No, that's too late. In the ira dump gcc has already chosen a vsx reg. See r120. Disposition: 0:r117 l0 33:r118 l0 42:r119 l0 91:r120 l032 4:r121 l0 35:r122 l0 4
[Bug c/102867] [12 Regression] Waddress complaint in readelf.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102867 --- Comment #3 from Alan Modra --- Not that I'm really complaining about this, note also that the error message referencing "filedata->section_headers + (sizetype)((long unsigned int)i * 80)" is a little bit too much of compiler internal representation leaking out. Nowhere in the source is such an expression used. It's simply "filedata->section_headers + i". BTW, the warnings can be avoided by converting the readelf.c macros to inline functions.
[Bug c/102867] Waddress complaint in readelf.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102867 --- Comment #1 from Alan Modra --- Created attachment 51641 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51641=edit preprocessed source
[Bug c/102867] New: Waddress complaint in readelf.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102867
Bug ID: 102867
Summary: Waddress complaint in readelf.c
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: amodra at gmail dot com
Target Milestone: ---
Compiling the attached readelf.i with -Wall -Werror -O2 using today's gcc
mainline on x86_64-linux results in complaints like
/home/alan/src/binutils-gdb/binutils/readelf.c: In function ‘find_section’:
/home/alan/src/binutils-gdb/binutils/readelf.c:762:42: error: the comparison
will always evaluate as ‘true’ for the pointer operand in
‘filedata->section_headers + (sizetype)((long unsigned int)i * 80)’ must not be
NULL [-Werror=address]
762 | if (SECTION_NAME_VALID (filedata->section_headers + i)
The warning is true, but annoying when coming from a macro expansion
#define SECTION_NAME_VALID(X) \
((X) != NULL \
&& filedata->string_table != NULL\
&& (X)->sh_name < filedata->string_table_length)
In current readelf.c it looks like it may be possible to remove "(X) != NULL"
from this macro, but that doesn't seem like a good solution. Another macro
with similar complaints
#define SECTION_NAME_PRINT(X) \
((X) == NULL ? _("")\
: filedata->string_table == NULL ? _("") \
: (X)->sh_name >= filedata->string_table_length ? _("") \
: filedata->string_table + (X)->sh_name)
can be called with X NULL.
[Bug demangler/102132] [nm] Stack overflow in demangler_path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102132 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||amodra at gmail dot com Ever confirmed|0 |1 Version|unknown |12.0 Last reconfirmed||2021-09-05 --- Comment #4 from Alan Modra --- Yes, gcc's libiberty is still considered upstream of binutils' copy.
[Bug demangler/102130] [c++filt] Stack overflow in demangle_path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102130 Alan Modra changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2021-09-05 Resolution|MOVED |--- Ever confirmed|0 |1 Version|7.5.0 |12.0 CC||amodra at gmail dot com --- Comment #3 from Alan Modra --- Even though c++filt is binutils, the problem occurs in a libiberty file and in rust-demangle.c as of 2021-08-30 in gcc master. Moved back here.
[Bug bootstrap/46981] multilib LD_LIBRARY_PATH prevents configuration of target libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46981 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #3 from Alan Modra --- This is more than just an AIX problem. Use of LD_LIBRARY_PATH prevents bootstrapping with any tools that happen to use libstdc++.so, for example, ld.gold on Linux. If the new libstdc++.so is incompatible with the version ld.gold was linked against the result is typically a segfault on ld.gold startup, when attempting to build gcc stage3 target libraries. A workaround is to install a statically compiled ld.gold.
[Bug tree-optimization/101977] [12 Regression] array subscript 0 is outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101977 --- Comment #6 from Alan Modra --- (In reply to Martin Sebor from comment #5) > The -Warray-bounds for section.c is gone Thanks for fixing that. > but last night's build still shows > a large number of -Warray-bounds instances as well as other warnings for > Binutils & GDB. I built gcc and binutils+gdb just now and see that these are all in sim/ with the exception of -Wconflicts-sr and -Wconflicts-rr bison warnings, and this libstdc++ warning: home/alan/build/gcc-virgin/prev-x86_64-linux/libstdc++-v3/include/bits/stl_algo.h:1869:32: error: array subscript 19 is outside array bounds of ‘void [136]’ [-Werror=array-bounds]
[Bug tree-optimization/101977] New: array subscript 0 is outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101977
Bug ID: 101977
Summary: array subscript 0 is outside array bounds
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amodra at gmail dot com
Target Milestone: ---
Seen on attempting to build binutils for x86_64-linux with current mainline gcc
/home/alan/build/gcc-virgin/gcc/xgcc -B/home/alan/build/gcc-virgin/gcc/
-DHAVE_CONFIG_H -I. -I/home/alan/src/binutils-gdb/bfd
-DBINDIR=\"/usr/local/bin\" -DLIBDIR=\"/usr/local/lib\" -I.
-I/home/alan/src/binutils-gdb/bfd -I/home/alan/src/binutils-gdb/bfd/../include
-DHAVE_all_vecs -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow
-Wstack-usage=262144 -Werror -I/home/alan/src/binutils-gdb/bfd/../zlib -g -O2
-MT section.lo -MD -MP -MF .deps/section.Tpo -c
/home/alan/src/binutils-gdb/bfd/section.c -o section.o
In function ‘bfd_get_next_section_by_name’,
inlined from ‘bfd_get_linker_section’ at
/home/alan/src/binutils-gdb/bfd/section.c:976:11:
/home/alan/src/binutils-gdb/bfd/section.c:936:8: error: array subscript 0 is
outside array bounds of ‘asection[31160040665049918]’ {aka ‘struct
bfd_section[31160040665049918]’} [-Werror=array-bounds]
936 | hash = sh->root.hash;
| ~^~~
[Bug plugins/101810] libiberty/simple-object-xcoff.c segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101810 --- Comment #3 from Alan Modra --- Making SYMESZ a size_t as the patch does, is a complete fix if the code is only compiled for 64-bit hosts where unsigned int is smaller than size_t. If compiled for 32-bit then the expression calculating buffer size can overflow leading to similar segfaults on fuzzed object files. As explained by the comment.
[Bug libgcc/99759] morestack.S should support .init_array.0 besides .ctors.65535
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99759 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com Status|WAITING |NEW --- Comment #2 from Alan Modra --- > this means the ctors.65535 will come last. Nope, it will come first. And since DT_INIT_ARRAY pointers are executed in the order they appear in the array, it will be one of the first to run. .init_array and .ctors sorting is complicated. ld.bfd will sort .init_array.0 (highest priority .init_array section) and .ctors.65535 (highest priority .ctors section) together. I assume this comment: > The input section description is quite close but does not sort .init_array.* > and .ctors.* with the same priority together. is referring to lld. > I don't see any issue here really in the end because GCC will produce > init_array most of the time. So the issue really is that lld doesn't support mixing of .ctors.* and .init_array.*. It might be nice for libgcc to use .init_array.0 here instead of .ctors.65536 whenever gcc will use .init_array in compiled code.
[Bug plugins/101810] libiberty/simple-object-xcoff.c segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101810 --- Comment #1 from Alan Modra --- Created attachment 51272 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51272=edit Proposed fix
[Bug plugins/101810] New: libiberty/simple-object-xcoff.c segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101810 Bug ID: 101810 Summary: libiberty/simple-object-xcoff.c segmentation fault Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: plugins Assignee: unassigned at gcc dot gnu.org Reporter: amodra at gmail dot com Target Milestone: --- >From https://sourceware.org/bugzilla/show_bug.cgi?id=28179 binutils/nm-new --plugin ~/build/gcc-virgin/lto-plugin/.libs/liblto_plugin.so -a pr28179 AddressSanitizer:DEADLYSIGNAL = ==3630013==ERROR: AddressSanitizer: SEGV on unknown address 0x6021000a (pc 0x7fc28ca928ea bp 0x sp 0x7ffd425c36d0 T0) ==3630013==The signal is caused by a READ memory access. #0 0x7fc28ca928ea in simple_object_xcoff_find_sections /home/alan/src/gcc-virgin/libiberty/simple-object-xcoff.c:529:26 #1 0x7fc28ca874f7 in claim_file_handler /home/alan/src/gcc-virgin/lto-plugin/lto-plugin.c:1189:16 #2 0x9ad923 in try_claim /home/alan/src/binutils-gdb/bfd/plugin.c:323:7 [snip] A little analysis of the binutils testcase reveals the xcoff file header has nsyms of 0x8000. The file contains a number of places where ocr->nsyms * SYMESZ is calculated. Since ocr->nsyms is an unsigned int and SYMESZ a plain number (18), the expression overflows to zero. That results in a zero length buffer being allocated and read from file, but 0x8000 syms processed from the buffer.
[Bug target/101393] PowerPC32 inline assembly broken by commit 2d94f7dea9c73ef3c116a0ddc722724578a860fe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393 --- Comment #11 from Alan Modra --- Preserving certain -m gas options goes back to this patch: https://sourceware.org/pipermail/binutils/2008-January/054935.html Given the number of ppc micros around with differing functional units, it is quite reasonable that we have assembly options to say "this base cpu" plus "this extra functionality". Whether you think it was wise to allow those "extra functionality" options to be specified before the "base cpu" option is another matter, but it has been that way for a long time. I'm not inclined to change that since it would very likely break some projects, and I happen to think that it is entirely reasonable to expect that "-maltivec -mppc64" for example is the same as "-mppc64 -maltivec". In any case sticky options are a side issue here. The real issue is that emitted .machine is wrong. Note that I'm not vetoing assembler changes. It might be a good idea to reset all sticky options on processing any .machine directive for example, and I'm happy with the idea of -mno-vsx etc. options for the assembler.
[Bug target/61032] rs6000 code gen suffers from lack of address_cost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61032 Alan Modra changed: What|Removed |Added Assignee|amodra at gmail dot com|unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #2 from Alan Modra --- Deassigning myself, since it is clear that the rtx_costs patches are going nowhere.
[Bug target/94393] Powerpc suboptimal 64-bit constant comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94393 Alan Modra changed: What|Removed |Added Status|ASSIGNED|NEW URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2020-October ||/555760.html Assignee|amodra at gmail dot com|unassigned at gcc dot gnu.org --- Comment #8 from Alan Modra --- Patch posted at given URL above. I'm taking myself off as assignee because it is clear to me the patch is going nowhere. Someone more capable than me will need to take up the task, sorry.
[Bug testsuite/100407] New test cases attr-retain-*.c fail after their introduction in r11-7284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100407 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #13 from Alan Modra --- All of the following result in the tests passing. make check-gcc RUNTESTFLAGS="--target_board=unix/-m32/-mno-readonly-in-sdata compile.exp=attr-retain-1.c" make check-gcc RUNTESTFLAGS="--target_board=unix/-m32/-mno-sdata compile.exp=attr-retain-1.c" make check-gcc RUNTESTFLAGS="--target_board=unix/-m32/-G0 compile.exp=attr-retain-1.c" The tests just need tweaking for ppc32 using any of the above, I'd choose -G0.
[Bug target/100799] Stackoverflow in optimized code on PPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799 Alan Modra changed: What|Removed |Added Target|powerpc |powerpc64le CC||amodra at gmail dot com --- Comment #4 from Alan Modra --- The disassembly says this is powerpc64le. Possibly interesting fact: the offsets used above the stack frame are 400, 432, 440, which all correspond to the parameter save area. I don't see any reason that DGEBAL should have a parameter save area though since all parameters can be passed in regs.
[Bug testsuite/98125] [11 Regression] New test case g++.dg/pr93195a.C in r11-5656 has excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125 --- Comment #14 from Alan Modra --- -fpatchable-function-entry isn't used by the powerpc linux kernel.
[Bug testsuite/98125] [11 Regression] New test case g++.dg/pr93195a.C in r11-5656 has excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125 --- Comment #12 from Alan Modra --- Created attachment 50039 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50039=edit ELFv1 support Revised patches. I wasn't happy with the use of a ".text" symbol in the previous patch since some targets don't call their text section ".text". These are really stage1 material. Usable -fpatchable-funtion-entry on powerpc64 is a new feature. I'm inclined to think the new test should just be skipped on powerpc64*-*. Bill, could you handle the testsuite fixes please?
[Bug testsuite/98125] [11 Regression] New test case g++.dg/pr93195a.C in r11-5656 has excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125 Alan Modra changed: What|Removed |Added Attachment #49701|0 |1 is obsolete|| --- Comment #11 from Alan Modra --- Created attachment 50038 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50038=edit ELFv2 support
[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #18 from Alan Modra --- Isn't this a bug in the assembly? We've changed the ABI, there is no way anyone can expect all old asm to work with power10 pcrel. To support pcrel you need new asm. #ifdef __PCREL__ __asm__ (pcrel version); #else __asm__ (non-pcrel version); #endif No need for special constraints, I think. (And not sufficient if we had them.)
[Bug target/98210] [11 Regression] SHF_GNU_RETAIN breaks gold linker generated binaries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98210 Alan Modra changed: What|Removed |Added Resolution|MOVED |--- Status|RESOLVED|REOPENED Last reconfirmed||2020-12-09 Ever confirmed|0 |1 --- Comment #2 from Alan Modra --- When the gold patch goes in, gcc should have a configure test such that the combination of gold being the default linker and SHF_GNU_RETAIN support should not be allowed unless gold has the patch. And even if gold is not the default linker it is required for split-stack go support, so go being compiled also ought to trigger a dependence on gold being recent enough.
[Bug target/98210] New: SHF_GNU_RETAIN breaks gold linker generated binaries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98210 Bug ID: 98210 Summary: SHF_GNU_RETAIN breaks gold linker generated binaries Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: amodra at gmail dot com Target Milestone: --- gcc.dg/split-1.exe and other split-stack executables broke recently on powerpc64le-linux, most likely due to git commit 6fbec038f7a7. I see [22] .init_array INIT_ARRAY 1001fda8 00fda8 08 08 WAo 0 0 8 [23] .init_array INIT_ARRAY 1001fdb0 00fdb0 10 00 WA 0 0 8 and in dynamic tags 0x0019 (INIT_ARRAY) 0x1001fda8 0x001b (INIT_ARRAYSZ) 8 (bytes) 0x0019 (INIT_ARRAY) 0x1001fdb0 0x001b (INIT_ARRAYSZ) 16 (bytes) ld.so won't handle multiple tags like this, and symbols __init_array_start and __init_array_end are defined to cover just the first .init_array section. The same thing happens on x86_64 when using gold, objects like crtbegin.o that have .init_array with "WAR" flags create separate .init_array output sections if being linked with glibc files containing .init_array without the "R" flag.
[Bug testsuite/98125] [11 Regression] New test case g++.dg/pr93195a.C in r11-5656 has excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125 --- Comment #8 from Alan Modra --- Created attachment 49701 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49701=edit fix powerpc64 -fpatchable-function-entry This makes -fpatchable-function-entry do something sensible on powerpc64 ELFv1 and ELFv2. The ELFv2 fix is all rs6000 backend trickery, ELFv1 needs a change to generic code to use the function code section symbol rather than the function symbol as the "o" argument for the __patchable_function_entries .section directive. Regression testing only done powerpc64le-linux so far.
[Bug testsuite/98125] [11 Regression] New test case g++.dg/pr93195a.C in r11-5656 has excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125 --- Comment #7 from Alan Modra --- (In reply to Alan Modra from comment #5) > So the "o" flag symbol is one in the .opd section, rather than what would be > correct here, .L._Z3foov. Actually, that breakage happened recently with commit 694d4a6d0c4. ie. it looks like powerpc64 ELFv1 was broken by HJ's patch. I tend to care more about powerpc64 ELFv2, ie powerpc64le, which was broken prior to that patch.
[Bug testsuite/98125] New test case g++.dg/pr93195a.C in r11-5656 has excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125 Alan Modra changed: What|Removed |Added Status|WAITING |NEW --- Comment #5 from Alan Modra --- The default implementation of -fpatchable-function-entry is broken and useless on powerpc64 ELFv1 and ELFv2. For ELFv1 we get .section".opd","aw" .align 3 _Z3foov: .quad .L._Z3foov,.TOC.@tocbase,0 .previous .type _Z3foov, @function .L._Z3foov: .section__patchable_function_entries,"awo",@progbits,_Z3foov .align 3 .8byte .LPFE1 .section.text._Z3foov,"axG",@progbits,_Z3foov,comdat .LPFE1: nop So the "o" flag symbol is one in the .opd section, rather than what would be correct here, .L._Z3foov. The implementation is even more useless for ELFv2, with the nop appearing in the global entry code (so providing patch space for only some calls of the function), which results in assembler complaints about ".localentry expression is not a power of 2". I don't think there is anything wrong with the new testcase, just a lack of xfail powerpc64*-*-*.
[Bug target/93176] PPC: inefficient 64-bit constant consecutive ones
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93176 Alan Modra changed: What|Removed |Added URL|https://gcc.gnu.org/piperma |https://gcc.gnu.org/piperma |il/gcc-patches/2020-Septemb |il/gcc-patches/2020-October |er/553661.html |/555760.html --- Comment #6 from Alan Modra --- No, the patch hasn't yet been reviewed.
[Bug middle-end/97267] Missed tail calls on ppc64 ELFv2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97267 Alan Modra changed: What|Removed |Added URL|https://gcc.gnu.org/piperma |https://gcc.gnu.org/piperma |il/gcc-patches/2020-October |il/gcc-patches/2020-Novembe |/555309.html|r/557719.html Status|ASSIGNED|RESOLVED Target Milestone|--- |11.0 Resolution|--- |FIXED --- Comment #2 from Alan Modra --- Fixed
[Bug libgcc/97543] powerpc64le: libgcc has unexpected long double in .gnu_attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97543 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #6 from Alan Modra --- (In reply to Peter Bergner from comment #4) > Something like the attached patch? No. -mlong-double-128 overrides the configured --without-long-double-128. --without-long-double-128 doesn't *disable* 128-bit long doubles, it just sets the default to 64-bit long double. (In reply to Michael Meissner from comment #5) Yes, -mno-gnu-attribute makes sense, however it should only apply to files linked into the shared libgcc, not IMO to files in libgcc.a.
[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
--- Comment #10 from Alan Modra ---
Here's elf32-arc.i creduced.
a;
b();
c() {
void *d;
if (d == b && e())
d = a;
return d;
}
[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360 Alan Modra changed: What|Removed |Added Target||powerpc64le-linux, ||x86_64-linux Status|WAITING |NEW --- Comment #8 from Alan Modra --- Note that the error reported in comment #1 is on x86_64-linux.
[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360 Alan Modra changed: What|Removed |Added CC||bergner at gcc dot gnu.org, ||meissner at gcc dot gnu.org --- Comment #7 from Alan Modra --- (In reply to Aldy Hernandez from comment #6) > How can the end points of a type be (a) of a different type than the type > itself (b) incompatible with the type itself. > > Is this a peculiarity of these quad types, or is this a target bug? These are PXI and XI mode 512-bit integers. See comment #0. PXI is a partial integer mode, which is likely why they aren't types_compatible_p. I have no idea whether this is a target bug or something that should be handled by the target-independent code.
[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360 --- Comment #4 from Alan Modra --- Created attachment 49347 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49347=edit original .i
[Bug tree-optimization/97360] [11 Regression] ICE in range_on_exit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360 --- Comment #3 from Alan Modra --- Created attachment 49346 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49346=edit reduced testcase -mcpu=power10 -O2 -S
[Bug target/97361] New: power10 unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97361 Bug ID: 97361 Summary: power10 unrecognizable insn Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: amodra at gmail dot com Target Milestone: --- -mcpu=power10 -O2 -mno-isel /home/alan/src/gcc/gcc/testsuite/gcc.target/powerpc/ppc-ne0-1.c: In function 'ne0': /home/alan/src/gcc/gcc/testsuite/gcc.target/powerpc/ppc-ne0-1.c:12:1: error: unrecognizable insn: 12 | } | ^ (insn 8 7 9 2 (set (reg:DI 122) (if_then_else:DI (eq (reg:CC 123) (const_int 0 [0])) (const_int 0 [0]) (reg:DI 124))) "/home/alan/src/gcc/gcc/testsuite/gcc.target/powerpc/ppc-ne0-1.c":11:12 -1 (nil)) during RTL pass: vregs
[Bug tree-optimization/97360] New: ICE in range_on_exit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360 Bug ID: 97360 Summary: ICE in range_on_exit Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: amodra at gmail dot com Target Milestone: --- during GIMPLE pass: evrp /home/alan/src/gcc/gcc/testsuite/gcc.target/powerpc/mma-double-test.c: In function 'MMA': /home/alan/src/gcc/gcc/testsuite/gcc.target/powerpc/mma-double-test.c:186:1: internal compiler error: in range_on_exit, at gimple-range.cc:931 The types involved are: constant 512> unit-size constant 64> align:512 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x76622bd0 precision:512 min max pointer_to_this > and: constant 512> unit-size constant 64> align:512 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x76622b28 precision:512 min max > So this may well be a powerpc target bug.
[Bug go/92564] libgo regression in runtime test resulting in SIGSEGV on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92564 Alan Modra changed: What|Removed |Added CC|amodra at gcc dot gnu.org | --- Comment #2 from Alan Modra --- Did you try Ian's suggestion of -Wl,--split-stack-adjust-size=0x8000 or even larger?
[Bug middle-end/97267] Missed tail calls on ppc64 ELFv2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97267 Alan Modra changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-10-02 Ever confirmed|0 |1
[Bug middle-end/97267] New: Missed tail calls on ppc64 ELFv2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97267
Bug ID: 97267
Summary: Missed tail calls on ppc64 ELFv2
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: amodra at gmail dot com
Target Milestone: ---
static int __attribute__ ((__noclone__, __noinline__))
reg_args (int j1, int j2, int j3, int j4, int j5, int j6, int j7, int j8)
{
return j1 + j2 + j3 + j4 + j5 + j6 + j7 + j8;
}
int __attribute__ ((__noclone__, __noinline__))
stack_args (int j1, int j2, int j3, int j4, int j5, int j6, int j7, int j8,
int j9)
{
if (j9 == 0)
return 0;
return reg_args (j1, j2, j3, j4, j5, j6, j7, j8);
}
This ought to result on a tail call from stack_args to reg_args on ELFv2 like
it does on ELFv1, ppc32, x86_64 and so on. Failure to do so is the result of
an overly restrictive test in calls.c:can_implement_as_sibling_call_p.
[Bug libffi/97166] libffi build issue when compiling with -mcpu=power10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97166 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.3 --- Comment #5 from Alan Modra --- Fixed everywhere we support power10
[Bug target/97107] libgo fails to build for power10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97107 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target|powerpc*|powerpc64*-* Target Milestone|--- |11.0 Resolution|--- |FIXED --- Comment #3 from Alan Modra --- This one isn't needed on gcc-10 for powerpc64 since the patch enabling tail calls isn't on the branch (yet). It isn't needed for ppc32 either, since -fsplit-stack isn't supported on ppc32.
[Bug libffi/97166] libffi build issue when compiling with -mcpu=power10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97166 Alan Modra changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com Last reconfirmed||2020-09-24 CC||amodra at gmail dot com Status|UNCONFIRMED |ASSIGNED --- Comment #2 from Alan Modra --- Oops didn't put the PR number in the commit. Fixed on master with commit 08cd8d5929 and followup commit fff56af642. These two will give a working power10 libffi even without commit 677b9150f5, the patch adding a built-in __PCREL__ define but you'll get some linker stubs to call between pc-rel and toc code.
[Bug target/97107] libgo fails to build for power10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97107 --- Comment #1 from Alan Modra --- Created attachment 49241 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49241=edit fix under test
[Bug target/97107] libgo fails to build for power10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97107 Alan Modra changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-09-18
[Bug target/97107] New: libgo fails to build for power10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97107 Bug ID: 97107 Summary: libgo fails to build for power10 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: amodra at gmail dot com Target Milestone: --- ld.gold: error: runtime/.libs/go-cdiv.o: failed to match split-stack sequence at section 1 offset 0 ld.gold: error: runtime/.libs/go-cdiv.o: failed to match split-stack sequence at section 1 offset 70 ld.gold: error: runtime/.libs/runtime_c.o: failed to match split-stack sequence at section 1 offset 310 ld.gold: error: reflect/.libs/makefunc_ffi_c.o: failed to match split-stack sequence at section 1 offset 1a0 Recently added rs6000 backend code allows sibcalls when pcrel. In the go-cdiv.o cases we have tail calls to __divsc3 and __divdc3 both of which are non-split-stack functions. The functions making those calls don't have a stack frame, and therefore don't have the magic split-stack instruction sequence that gold patches to allocate a larger stack. Now those __div libgcc functions don't have large stack frames that might blow the very limited stack provided, but in general you can't tail call non-split-stack functions from split-stack code. It isn't actually the sibcall that is the problem, but that rs6000_expand_split_stack_prologue didn't emit the magic code gold patches and a __morestack call. ie. a sibcall to non-split-stack code from split-stack is fine if there is sufficient stack memory mapped. __morestack is quite a surprising function on powerpc in that it calls back to its caller - and a tail call will continue running in the context of extra stack mapped until it returns.
[Bug target/97042] powerpc64 UINT_MAX constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042 --- Comment #9 from Alan Modra --- I think that splitter should disappear and rs6000_emit_set_long_const handle all special cases where you might want combinations of two logical instructions before handling the li;rldicl, li;rldicr or any other expansions with rotates.
[Bug target/97042] powerpc64 UINT_MAX constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042 --- Comment #7 from Alan Modra --- and of course, li 0x is li -1 which sets all bits.
[Bug target/97042] powerpc64 UINT_MAX constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042 --- Comment #6 from Alan Modra --- That's easy. rs6000_emit_set_long_const doesn't generate that sequence. Incidentally, a patch I had to generate more constants from li;rldicl also fixes this pr.
[Bug target/97042] powerpc64 UINT_MAX constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042 --- Comment #1 from Alan Modra --- Yes, reverting 5d3ae76af13 cures this PR.
[Bug target/97042] New: powerpc64 UINT_MAX constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97042
Bug ID: 97042
Summary: powerpc64 UINT_MAX constant
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: amodra at gmail dot com
Target Milestone: ---
/* -O2 -S */
long foo (long x) { return ~0u - x; }
for gcc-8 to current master
lis 9,0x
ori 9,9,0x
rldicl 9,9,0,32
subf 3,3,9
blr
a regression from gcc-7
li 9,-1
rldicl 9,9,0,32
subf 3,3,9
blr
Both sequences give the same result, this is just a code quality regression.
I haven't properly debugged this but I suspect commit 5d3ae76af13
[Bug target/96493] powerpc local call linkage failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96493 Alan Modra changed: What|Removed |Added Host||gcc Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Alan Modra --- Patches applied to master and gcc-10
[Bug testsuite/96525] new test gcc.target/powerpc/pr96493.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96525 Alan Modra changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Alan Modra --- Fixed
[Bug testsuite/96525] new test gcc.target/powerpc/pr96493.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96525
Alan Modra changed:
What|Removed |Added
Last reconfirmed||2020-08-10
Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
CC|amodra at gcc dot gnu.org |
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
--- Comment #4 from Alan Modra ---
Yes, the test needs power10_ok, but *not* power10_hw. Despite being a "run"
test with one function cpu=power10, no power10 insns are generated. So the
executable could in fact be run (even on a power3).
If you make the test power10_hw, then it won't be linked unless of course you
have power10 hardware or a simulator. Most people don't. We really do want
to at least link the compiler output as it is the link stage that shows up the
pr96493 problem.
I could make the test { do-do link } but running the test is just that little
bit better test of the linker output, and as far as I know there isn't a way of
saying "link this but only run on power10".
[Bug target/96493] powerpc local call linkage failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96493 --- Comment #2 from Alan Modra --- Yes, it is a bug present in any gcc version supporting pcrel.
[Bug target/96493] powerpc local call linkage failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96493 Alan Modra changed: What|Removed |Added Last reconfirmed||2020-08-06 Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1
[Bug target/96493] New: powerpc local call linkage failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96493
Bug ID: 96493
Summary: powerpc local call linkage failure
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: amodra at gmail dot com
Target Milestone: ---
/* -O2 -mcpu=power8 */
static int __attribute__ ((target("cpu=power10"),noclone,noinline))
local_func (int x)
{
return x;
}
int main()
{
return local_func (0);
}
results in a linker complaint "call to `local_func' lacks nop, can't restore
toc; (toc save/adjust stub)".
rs6000.md call_local et al patterns can't be allowed to match when
caller/callee disagree about r2 usage.
[Bug lto/96385] [8/9/10/11 Regression] GCC generates separate debug info with undefined symbols without relocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96385 --- Comment #16 from Alan Modra --- It looks fine to me, assuming you don't need to keep any of these undefined symbols.
[Bug target/94393] Powerpc suboptimal 64-bit constant comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94393 --- Comment #7 from Alan Modra --- (In reply to Peter Bergner from comment #5) > Alan, I think you pushed some changes to help with 1) above, correct? > Is there more to do for 1)? Possibly, I haven't looked at what needs to be done (if anything) for pli. > As for 2), we're in stage1 now. Do you have ideas about what must be done > there? Do we still want to do something for 2)? I wrote a series of patches in early April.
[Bug tree-optimization/95353] [10/11 Regression] GCC can't build binutils
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95353 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #6 from Alan Modra --- binutils code was written originally in K C, with quite a lot of the code base still having K flavour. We no doubt could move to C99 to use flexible array members and other nice features. For now, binutils is a useful "old" code base to test new gcc warnings..
[Bug target/94145] Longcalls mis-optimize loading the function address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94145 Alan Modra changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #13 from Alan Modra --- Fixed for gcc-10 and next gcc-9 release.
[Bug target/94504] On powerpc, -ffunction-sections -fdata-sections is not as effective as expected for PIE and PIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94504 Alan Modra changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX Summary|On powerpc, |On powerpc, |-ffunction-sections |-ffunction-sections |-fdata-sections is not as |-fdata-sections is not as |effective as expected for |effective as expected for |non-PIE executables.|PIE and PIC --- Comment #6 from Alan Modra --- For -fPIC or -fPIE on ppc32 gcc uses a per-object file compiler managed GOT (.got2). Fixed position code doesn't use a GOT. -fpic/-fpie uses a linker managed GOT but with limited size. So, correcting the summary. The problem reported here is due to the per-object file nature of .got2. (.got2 is similar to the per-object file ppc64 .toc, where compiling the testcase with -mcmodel=large gives the same link failure.) To handle -gc-sections properly, ld needs to treat .got2 specially so that a relocation reference to .got2 does not mark .got2 but rather the section referenced by the relevant .got2 entry, and then remove unneeded .got2 entries. No one has cared enough to write such linker support for ppc32 or for large code model ppc64 .toc. Alternatively gcc code generated for -fPIC/-fPIE could be changed, but again no one has cared enough to do that. Since it is very unlikely that a bugzilla entry for gcc or binutils will prompt anyone to write the necessary linker support or change gcc, I'm closing this as won't fix.
[Bug target/94393] Powerpc suboptimal 64-bit constant comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94393 --- Comment #3 from Alan Modra --- There are two parts to fixing this PR. 1) We can do better in the sequences generated for some constants. 2) rs6000_rtx_costs needs to be accurate, so that expensive constants are put in memory and stay there with optimisation. Having looked at part 2 a little, I'd say fixes for that are definitely not stage 4 material.
[Bug target/57836] large constants evaluated inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57836 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|5.5 |11.0 Resolution|--- |DUPLICATE --- Comment #7 from Alan Modra --- Some issues related to large constants have already been fixed, thus closing this bug as a dup of pr94393 *** This bug has been marked as a duplicate of bug 94393 ***
[Bug target/94393] Powerpc suboptimal 64-bit constant comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94393 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #2 from Alan Modra --- *** Bug 57836 has been marked as a duplicate of this bug. ***
[Bug target/94393] Powerpc suboptimal 64-bit constant comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94393 --- Comment #1 from Alan Modra --- Created attachment 48146 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48146=edit teach gcc more two insn sequences for constants
[Bug target/94393] Powerpc suboptimal 64-bit constant comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94393 Alan Modra changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com Last reconfirmed||2020-03-30 CC|amodra at gmail dot com| Status|UNCONFIRMED |ASSIGNED
[Bug target/94145] Longcalls mis-optimize loading the function address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94145 --- Comment #8 from Alan Modra --- (In reply to Richard Biener from comment #7) > OTOH CSEing the load from the PLT once it is resolved _would_ be an > optimization. Possibly. Sometimes making the call sequence seem more efficient runs into stalls particularly when the called function is short. > Asks for loop peeling I guess? Yeah, that might be one way to get the first call of a function inside a loop over and done with. And so you'd know the PLT entry was resolved and thus no longer volatile.
[Bug target/94145] Longcalls mis-optimize loading the function address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94145 --- Comment #6 from Alan Modra --- Transformations to indirect calls and hoisting function addresses out of loops is fine. That sort of thing has nothing to do with this problem. The problem is that the PLT really is volatile, and the inline PLT code for powerpc exposes those PLT loads without letting gcc know they are in fact volatile. If gcc decides to cache a PLT load in a register and then use it for multiple calls to the same function you might end up going via the ld.so symbol resolver for every one of those calls rather than only on the first call. That is very definitely not an optimisation.
[Bug target/94145] Longcalls mis-optimize loading the function address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94145 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #4 from Alan Modra --- Created attachment 48022 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48022=edit gcc fix to make plt loads volatile This patch has some commentary explaining what is going on. Strictly speaking what is in the PLT is *not* the "address of a function". I haven't bootstrapped it yet, but Mike has used it to build spec with -mlongcalls which probably is better testing for this patch than a bootstrap anyway.
[Bug target/94145] Longcalls mis-optimize loading the function address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94145 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com Last reconfirmed||2020-03-11 Ever confirmed|0 |1
[Bug target/91052] [10 Regression] ICE in fix_reg_equiv_init, at ira.c:2705
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91052 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #14 from Alan Modra --- I agree with your analysis, and that combine_and_move_insns has a bug. (That doesn't mean I should be viewed as any sort of expert on ira.c. The fact that my name appears on git blame for much of combine_and_move_insns is just due to me splitting out existing code into that function!) "!multiple_sets (def_insn)" seems the correct solution too, but I'd be inclined to move that test earlier, either before or after can_throw_internal on the grounds that asm insns might have the same problem with multiple sets. Perhaps comment that instructions with multiple sets can only be moved if DF analysis is performed for all of the registers set.
[Bug sanitizer/92634] [8/9/10 regression] -fsanitize=undefined erroneous null pointer check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92634 --- Comment #13 from Alan Modra --- Yes, I came to the conclusion myself that this is really nothing to do with dereferencing. So my original claim and Andrew's replies about dereferencing are not relevant. The standard says of unary & "The operand of the unary & operator shall be either a function designator, the result of a [] or unary * operator, or an lvalue that designates an object that is not a bit-field and is not declared with the register storage-class specifier." We don't have a function designator, the result of a [] or unary *, so the & operand must be an lvalue. Of lvalues, the standard says (in part): "if an lvalue does not designate an object when it is evaluated, the behavior is undefined" And that along with lack of a special case for >f is the language reason why the binutils code was UB.
[Bug lto/93384] [10 Regression] Python 3.9.0a3 fails to build on ppc64le with GCC 10.0.1: redefined symbol cannot be used on reloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93384 --- Comment #16 from Alan Modra --- It is possible to fix this in the assembler too, but I'm reluctant to do so. If we make some sort of promise that .set x,y .set x,y gives the same results as when only the first .set is present, then gas needs to correctly calculate "no change in y". That is complicated in the general case of an arbitrary expression for y. It's even surprisingly complicated if y is just a single symbol.
[Bug sanitizer/92634] [8/9/10 regression] -fsanitize=undefined erroneous null pointer check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92634 --- Comment #11 from Alan Modra --- Oh wow, so the line of reasoning relies on what the C standard *doesn't* say in 6.5.3.2. I also think the deductions are somewhat suspect. You say >f is the same as &((*p).f), which is from p->f being the same as (*p).f. While I agree that is generally true, it's relying on note 79 in the spec isn't it? 79) If is a valid pointer expression (where & is the ‘‘address-of’’ operator, which generates a pointer to its operand), the expression ()->MOS is the same as E.MOS. But if we don't have , which we don't when p is the null pointer (by 6.3.2.3/3), then how can you use note 79 to say p->f is the same as (*p).f when p is the null pointer? Quite likely I'm missing something. However, the fact that there is old C code around from many years ago that uses the offsetof macro as I wrote it, and the fact that no compiler on earth actually dereferences p in >f lends credence to the idea that there is no dereference here.
[Bug sanitizer/92634] [8/9/10 regression] -fsanitize=undefined erroneous null pointer check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92634 --- Comment #7 from Alan Modra --- Here's another example, a typical offsetof. #define offsetof(TYPE, MEMBER) ((unsigned long) &((TYPE *)0)->MEMBER)
[Bug sanitizer/92634] [8/9/10 regression] -fsanitize=undefined erroneous null pointer check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92634
Alan Modra changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed||2019-11-23
Resolution|DUPLICATE |---
Ever confirmed|0 |1
--- Comment #5 from Alan Modra ---
How is it that "clang does this" overrides the C standard?
And yes, I quite realise that the C standard does not explicitly say >field
does not dereference p, but the analogy with [i] is strong and the fact is
that >field does not cause a dereference. So it ought to be good when p is
null.
I'll note that we are talking C here, not C++.
If you're going to close this bug again then do so with an explanation from a
language viewpoint as to why
void
lang_for_each_input_file (void (*func) (lang_input_statement_type *))
{
lang_input_statement_type *f;
for (f = _file_chain.head->input_statement;
f != NULL;
f = f->next_real_file)
if (f->flags.real)
func (f);
}
is wrong. I'm genuinely interested, not just pissed off that you've closed my
bug..
[Bug sanitizer/92634] [8/9/10 regression] -fsanitize=undefined erroneous null pointer check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92634 --- Comment #2 from Alan Modra --- (In reply to Andrew Pinski from comment #1) > No those are still officially considered a referencing. > > In fact all three cases: > >field does not dereference p, just as &*p and [i] do not. > > Should be considered a deference even though the deference does not happen. The ISO C standard ISO/IEC 9899:1999 appears to disagree with you. From 6.5.3.2 "3 The unary & operator returns the address of its operand. If the operand has type ‘‘type’’, the result has type ‘‘pointer to type’’. If the operand is the result of a unary * operator, neither that operator nor the & operator is evaluated and the result is as if both were omitted, except that the constraints on the operators still apply and the result is not an lvalue. Similarly, if the operand is the result of a [] operator" [snip rest] I do not see anything under "constraints on the operators" that precludes &*p on a null p, in fact there is a note that says "83) Thus, &*E is equivalent to E (even if E is a null pointer)" [snip rest] So what is more official than the C standard that makes you say "those are still officially considered a referencing"?
[Bug sanitizer/92634] New: [gcc-8 regression] -fsanitize=undefined erroneous null pointer check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92634 Bug ID: 92634 Summary: [gcc-8 regression] -fsanitize=undefined erroneous null pointer check Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: amodra at gmail dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Created attachment 47337 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47337=edit testcase -fsanitize=undefined inserts bogus pointer checks on expressions that effectively cast a pointer to a union to a pointer to one of the elements of that union. >field does not dereference p, just as &*p and [i] do not. This bites in binutils sources (eg. see ldlang.c lang_for_each_input_file), where >field is used in preference to (type_of_field *) p, since the cast loses some type checking.
