[Bug libstdc++/109889] [13/14 Regression] Segfault in __run_exit_handlers since r13-5309-gc3c6c307792026
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109889 --- Comment #6 from Tulio Magno Quites Machado Filho --- Let me elaborate my previous comment... When initializing the object at 0x100414c8, one of its members points to an address in the stack (0x7fffe8f8). All these functions return and when __run_exit_handlers() is called, the address 0x7fffe8f8 is used to save the TOC pointer (r2) before calling the destructors of the library. The destructors manipulate the object at 0x100414c8, zeroing all its members, including the address where the TOC pointer was saved.
[Bug libstdc++/109889] [13/14 Regression] Segfault in __run_exit_handlers since r13-5309-gc3c6c307792026
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109889 --- Comment #5 from Tulio Magno Quites Machado Filho --- (In reply to Jonathan Wakely from comment #3) > I wonder if we have a static destructor ordering problem. I'm afraid the issue is happening earlier, when these iterators are being initialized. Look at this backtrace taken during initialization: #0 0x77b536e4 in __gnu_debug::_Safe_sequence_base::_M_attach_single (this=0x100414c8 <__gnu_cxx::annotate_base::map_alloc()::_S_map>, __it=0x7fffe8f8, __constant=false) at /home/test/src/gcc/libstdc++-v3/src/c++11/debug.cc:396 #1 0x77b5376c in __gnu_debug::_Safe_sequence_base::_M_attach (this=0x100414c8 <__gnu_cxx::annotate_base::map_alloc()::_S_map>, __it=0x7fffe8f8, __constant=false) at /home/test/src/gcc/libstdc++-v3/src/c++11/debug.cc:383 #2 0x77b53cd8 in __gnu_debug::_Safe_iterator_base::_M_attach (this=0x7fffe8f8, __seq=0x100414c8 <__gnu_cxx::annotate_base::map_alloc()::_S_map>, __constant=false) at /home/test/src/gcc/libstdc++-v3/src/c++11/debug.cc:430 #3 0x10012244 in __gnu_debug::_Safe_iterator_base::_Safe_iterator_base (__constant=false, __seq=0x100414c8 <__gnu_cxx::annotate_base::map_alloc()::_S_map>, this=) at /home/test/gcc-14/include/c++/14.0.0/debug/safe_base.h:91 #4 __gnu_debug::_Safe_iterator > >, std::__debug::map, std::less, std::allocator > > >, std::forward_iterator_tag>::_Safe_iterator (__seq=0x100414c8 <__gnu_cxx::annotate_base::map_alloc()::_S_map>, __i=..., this=0x7fffe8f0) at /home/test/gcc-14/include/c++/14.0.0/debug/safe_iterator.h:162 #5 __gnu_debug::_Safe_iterator > >, std::__debug::map, std::less, std::allocator > > >, std::bidirectional_iterator_tag>::_Safe_iterator (__seq=0x100414c8 <__gnu_cxx::annotate_base::map_alloc()::_S_map>, __i=..., this=0x7fffe8f0) at /home/test/gcc-14/include/c++/14.0.0/debug/safe_iterator.h:539 #6 std::__debug::map, std::less, std::allocator > > >::find (__x=: 0x0, this=0x100414c8 <__gnu_cxx::annotate_base::map_alloc()::_S_map>) at /home/test/gcc-14/include/c++/14.0.0/debug/map.h:583 #7 __gnu_cxx::annotate_base::check_allocated (this=, size=4, p=0x0) at /home/test/gcc-14/include/c++/14.0.0/ext/throw_allocator.h:177 #8 __gnu_cxx::annotate_base::erase (p=p@entry=0x0, size=size@entry=4, this=) at /home/test/gcc-14/include/c++/14.0.0/ext/throw_allocator.h:146 #9 0x10010474 in __gnu_cxx::throw_allocator_base::deallocate (this=, __n=1, __p=0x0) at /home/test/gcc-14/include/c++/14.0.0/ext/throw_allocator.h:888 #10 __gnu_test::check_deallocate_null<__gnu_cxx::throw_allocator_random > () at /home/test/src/gcc/libstdc++-v3/testsuite/util/testsuite_allocator.h:255 #11 main () at /home/test/src/gcc/libstdc++-v3/testsuite/ext/throw_allocator/check_deallocate_null.cc:30 Frame #2 references 0x7fffe8f8, which is part of the stack. Frame #5 is also referencing an object in the stack. After these functions return, these objects shouldn't be used anymore.
[Bug libstdc++/103387] powerpc64le: segmentation fault on std::cout with ieee128 long double variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103387 Tulio Magno Quites Machado Filho changed: What|Removed |Added CC||tuliom at ascii dot art.br --- Comment #2 from Tulio Magno Quites Machado Filho --- (In reply to Michael Meissner from comment #1) > I tried it on a current trunk compiler (from November 23, 2021) using glibc > 2.34 (IBM AT 14.0), and it does fail. It works fine if I build a toolchain > where the default long double is IEEE 128-bit. So, it sounds like this is happening because libstdc++ is not distributing cout implementations for all the supported long double types, but just for the default type as explained in bug #100912.
[Bug target/101865] _ARCH_PWR8 is not defined when using -mcpu=power8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865 --- Comment #12 from Tulio Magno Quites Machado Filho --- There is a chance, that my previous comment is wrong with regards the generation of VSX instructions for Power8. I don't know what the second command means: $ gcc-11 -mcpu=power10 -dM -E - < /dev/null | grep -E 'VECTOR|VSX|ALTIVEC' #define __VSX__ 1 #define __ALTIVEC__ 1 #define __POWER9_VECTOR__ 1 #define __APPLE_ALTIVEC__ 1 #define __POWER8_VECTOR__ 1 $ gcc-11 -mcpu=power10 -mno-power8-vector -dM -E - < /dev/null | grep -E 'VECTOR|VSX|ALTIVEC' #define __VSX__ 1 #define __ALTIVEC__ 1 #define __APPLE_ALTIVEC__ 1
[Bug target/101865] _ARCH_PWR8 is not defined when using -mcpu=power8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865 --- Comment #10 from Tulio Magno Quites Machado Filho --- (In reply to HaoChen Gui from comment #9) > For this example, let's suppose that we set mcpu=power8 and mno-vsx in the > command line. Thus, _ARCH_PWR8 should be defined as mcpu=power8. But if the > Power8-specific codes contain VSX codes, could the asm be executed? These macros should only be used to indicate if a code should be generated. In my opinion, in order to generate a VSX instruction available on POWER8, it would be required to test for both _ARCH_PWR8 and __VSX__. For tests at execution time, it's required to validate what the kernel supports, e.g. using __builtin_cpu_supports().
[Bug target/101865] _ARCH_PWR8 is not defined when using -mcpu=power8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865 --- Comment #7 from Tulio Magno Quites Machado Filho --- (In reply to HaoChen Gui from comment #6) > Does _ARCH_PWR8 impact anything during the compiling? I can answer this question from an user point of view. It's used in many projects to indicate if the target processor supports certain features, e.g. #ifdef _ARCH_PWR8 asm (...); /* Power8-specific code. */ #else /* Generic implementation. */ ... #endif
[Bug target/101865] New: _ARCH_PWR8 is not defined when using -mcpu=power8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865 Bug ID: 101865 Summary: _ARCH_PWR8 is not defined when using -mcpu=power8 Product: gcc Version: 11.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: tuliom at ascii dot art.br Target Milestone: --- When using -mcpu=power8, I expected that _ARCH_PWR8 would be defined, however it isn't defined when used together with -mno-altivec -mno-vsx, e.g. $ gcc-11 -mcpu=power8 -mno-altivec -mno-vsx -dM -E - < /dev/null | grep PWR #define _ARCH_PWR5 1 #define _ARCH_PWR6 1 #define _ARCH_PWR7 1 #define _ARCH_PWR5X 1 #define _ARCH_PWR4 1
[Bug target/101324] powerpc64le: hashst appears before mflr at -O1 or higher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101324 Tulio Magno Quites Machado Filho changed: What|Removed |Added Attachment #51105|0 |1 is obsolete|| --- Comment #4 from Tulio Magno Quites Machado Filho --- Created attachment 51109 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51109=edit __memmove_ppc extracted from glibc (without -g3) I removed -g3 from the command that generated memmove-ppc64.i. I think this won't generate warnings now.
[Bug target/101324] New: powerpc64le: hashst appears before mflr at -O1 or higher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101324 Bug ID: 101324 Summary: powerpc64le: hashst appears before mflr at -O1 or higher Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: tuliom at ascii dot art.br Target Milestone: --- Created attachment 51105 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51105=edit __memmove_ppc extracted from glibc When using ROP (-mrop-protect), it's expected that generated code reads the value from LR (mflr) and hash it later (hashst). This works well at -O0. However, at -O1 and higher, we're seeing cases where hashst appears before mflr. I'm attaching an example extracted from glibc. You can reproduce the issue with command: gcc -S -O1 -mrop-protect -mcpu=power10 memmove-ppc64.i -o - The generated asm contains the following: __memmove_ppc: .LFB6: .cfi_startproc .localentry __memmove_ppc,1 hashst 0,-40(1) std 28,-32(1) stdu 1,-80(1) .cfi_def_cfa_offset 80 .cfi_offset 28, -32 mr 28,3 subf 9,4,3 cmpld 0,9,5 bge 0,.L17 std 31,72(1) .cfi_offset 31, -8 add 4,4,5 add 31,3,5 cmpldi 0,5,15 ble 0,.L4 mflr 0 ...
[Bug c++/101168] New: gnu++14 complains about altivec types defined with using keyword in the same file with preprocessor macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101168 Bug ID: 101168 Summary: gnu++14 complains about altivec types defined with using keyword in the same file with preprocessor macros Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tuliom at ascii dot art.br Target Milestone: --- Step to reproduce the error: $ cat issue.cc #include using vdbl = __vector double; #define BREAK 1 $ g++ -std=gnu++14 -c issue.cc issue.cc:4:15: error: expected type-specifier before numeric constant 4 | #define BREAK 1 | ^ issue.cc:4:9: note: in expansion of macro ‘BREAK’ 4 | #define BREAK 1 | ^ The error does not reproduce when using -std=c++14.
[Bug c/100909] New: powerpc64le: Regression causing unexpected error with IBM long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100909 Bug ID: 100909 Summary: powerpc64le: Regression causing unexpected error with IBM long double Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tuliom at ascii dot art.br Target Milestone: --- Created attachment 50934 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50934=edit Pre-processed s_modff128-ifunc.c file from glibc I've recently started seeing this regression while building glibc on powerpc64le: gcc -m64 test.i -c -mlong-double-128 -mabi=ibmlongdouble /home/tuliom/tmp/at-build-tray/at15.0-0-alpha.suse-15_ppc64le_ppc64le/builds/glibc_1-64/math/s_modff128-ifunc.c:8:1: error: ‘-mabi=ibmlongdouble’ requires ‘-mlong-double-128’ 8 | DECL_ALIAS_s_modf (modf); | ^~ Notice that both parameters are being passed to GCC. I've bisected this issue to: commit ebd5e86c0f41dc1d692f9b2b68a510b1f6835a3e Author: Martin Liska Date: Wed Mar 10 15:12:31 2021 +0100 Improve global state for options. gcc/c-family/ChangeLog: PR tree-optimization/92860 PR target/99592 * c-attribs.c (handle_optimize_attribute): Save target node before calling parse_optimize_options and save it in case it changes. * c-pragma.c (handle_pragma_target): Similarly for pragma. (handle_pragma_pop_options): Likewise here. gcc/ChangeLog: PR tree-optimization/92860 PR target/99592 * optc-save-gen.awk: Remove exceptions. I can still reproduce it with commit ee9548b36a7f.
[Bug c/100605] -Wimplicit-fallthrough=5 still recognizes comments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100605 --- Comment #1 from Tulio Magno Quites Machado Filho --- Interestingly, all the 3 warnings are reported when using -save-temps: $ gcc -c -save-temps -Wimplicit-fallthrough=5 -Werror=implicit-fallthrough t.c t.c: In function ‘foo’: t.c:12:9: error: this statement may fall through [-Werror=implicit-fallthrough=] 12 | k = 3; | ~~^~~ t.c:14:5: note: here 14 | case 2: | ^~~~ t.c:15:9: error: this statement may fall through [-Werror=implicit-fallthrough=] 15 | k = 8; | ~~^~~ t.c:16:5: note: here 16 | case 1: | ^~~~ t.c:17:9: error: this statement may fall through [-Werror=implicit-fallthrough=] 17 | k = 16; | ~~^~~~ t.c:18:5: note: here 18 | case 0: | ^~~~ cc1: some warnings being treated as errors
[Bug c/100605] New: -Wimplicit-fallthrough=5 still recognizes comments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100605
Bug ID: 100605
Summary: -Wimplicit-fallthrough=5 still recognizes comments
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tuliom at ascii dot art.br
Target Milestone: ---
According to the GCC manual:
"-Wimplicit-fallthrough=5 doesn’t recognize any comments as fallthrough
comments, only attributes disable the warning."
However, comments are still being recognized and are disabling the warning.
In the following example, there are 3 fall-throughs:
$ cat t.c
#include
#include
uint32_t foo(size_t in)
{
uint32_t out = 0;
uint32_t k = 0;
switch (in & 3)
{
case 3:
k = 3;
// FALLTHROUGH
case 2:
k = 8;
case 1:
k = 16;
case 0:
default:
out = k;
break;
}
return out;
}
However, GCC 11 reports only 2 when using -Wimplicit-fallthrough=5:
$ gcc-11 -c -Wimplicit-fallthrough=5 -Werror=implicit-fallthrough t.c
t.c: In function ‘foo’:
t.c:15:9: error: this statement may fall through
[-Werror=implicit-fallthrough=]
15 | k = 8;
| ~~^~~
t.c:16:5: note: here
16 | case 1:
| ^~~~
t.c:17:9: error: this statement may fall through
[-Werror=implicit-fallthrough=]
17 | k = 16;
| ~~^~~~
t.c:18:5: note: here
18 | case 0:
| ^~~~
cc1: some warnings being treated as errors
[Bug libgcc/98952] New: powerpc*: __trampoline_setup inverted test for trampoline size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98952 Bug ID: 98952 Summary: powerpc*: __trampoline_setup inverted test for trampoline size Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: tuliom at ascii dot art.br Target Milestone: --- In tramp.S, we have the following: /* R3 = stack address to store trampoline */ /* R4 = length of trampoline area */ /* R5 = function address */ /* R6 = static chain */ FUNC_START(__trampoline_setup) ... li r8,trampoline_size /* verify that the trampoline is big enough */ cmpwcr1,r8,r4 ... blt cr1,.Labort It's aborting if r8 < r4. However, I expected it to abort if r4 < r8, which means the allocated trampoline area is not enough to fit the trampoline. One could replace li + cmpw with just: cmpwicr1,r4,trampoline_size I can't reproduce this issue on GCC because the allocated length (r4) is always equals to the required length (r8). However, this happens when mixing other compilers, e.g. https://github.com/JuliaLang/julia/issues/32154#issuecomment-766536590
[Bug libgcc/97543] New: powerpc64le: libgcc has unexpected long double in .gnu_attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97543
Bug ID: 97543
Summary: powerpc64le: libgcc has unexpected long double in
.gnu_attribute
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: tuliom at ascii dot art.br
Target Milestone: ---
Alpine Linux uses musl as C Library.
musl only supports long double as IEEE binary64.
It does not support IBM long double.
In this scenario, building gcc with --disable-multilib --with-long-double-64
still creates a libgcc with a .gnu_attribute pointing to IBM long double,
causing unnecessary link time warnings.
Reproduced as:
$ cat test.c
#include
#include
int
main()
{
long double a = 2.0;
__int128 b = 8;
printf("sizeof(long double) = %ld\n", sizeof(long double));
printf("a * b = %Lf\n", a * (long double) b);
return 0;
}
$ gcc test.c && ./a.out
/usr/lib/gcc/powerpc64le-alpine-linux-musl/10.2.0/../../../../powerpc64le-alpine-linux-musl/bin/ld:
/tmp/ccmCAapA.o uses 64-bit long double,
/usr/lib/gcc/powerpc64le-alpine-linux-musl/10.2.0/../../../../lib/libgcc_s.so.1
uses 128-bit long double
/usr/lib/gcc/powerpc64le-alpine-linux-musl/10.2.0/../../../../powerpc64le-alpine-linux-musl/bin/ld:
/tmp/ccmCAapA.o uses 64-bit long double,
/usr/lib/gcc/powerpc64le-alpine-linux-musl/10.2.0/../../../../lib/libgcc_s.so.1
uses 128-bit long double
sizeof(long double) = 8
a * b = 16.00
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/powerpc64le-alpine-linux-musl/10.2.0/lto-wrapper
Target: powerpc64le-alpine-linux-musl
Configured with: /home/devel/aports/main/gcc/src/gcc-10.2.0/configure
--prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
--build=powerpc64le-alpine-linux-musl --host=powerpc64le-alpine-linux-musl
--target=powerpc64le-alpine-linux-musl --with-pkgversion='Alpine 10.2.0'
--enable-checking=release --disable-fixed-point --disable-libstdcxx-pch
--disable-multilib --disable-nls --disable-werror --disable-symvers
--enable-__cxa_atexit --enable-default-pie --enable-default-ssp
--enable-cloog-backend --enable-languages=c,c++,objc,go,fortran,ada
--with-abi=elfv2 --enable-secureplt --enable-decimal-float=no
--enable-targets=powerpcle-linux --with-long-double-64 --disable-libquadmath
--disable-libssp --disable-libmpx --disable-libmudflap --disable-libsanitizer
--enable-shared --enable-threads --enable-tls --with-system-zlib
--with-linker-hash-style=gnu
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (Alpine 10.2.0)
