[Bug libgcc/97543] New: powerpc64le: libgcc has unexpected long double in .gnu_attribute

2020-10-23 Thread tuliom at ascii dot art.br via Gcc-bugs
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

[Bug libgcc/98952] New: powerpc*: __trampoline_setup inverted test for trampoline size

2021-02-03 Thread tuliom at ascii dot art.br via Gcc-bugs
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

[Bug c++/101168] New: gnu++14 complains about altivec types defined with using keyword in the same file with preprocessor macros

2021-06-22 Thread tuliom at ascii dot art.br via Gcc-bugs
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

[Bug c/100605] -Wimplicit-fallthrough=5 still recognizes comments

2021-05-14 Thread tuliom at ascii dot art.br via Gcc-bugs
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:

[Bug c/100605] New: -Wimplicit-fallthrough=5 still recognizes comments

2021-05-14 Thread tuliom at ascii dot art.br via Gcc-bugs
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

[Bug c/100909] New: powerpc64le: Regression causing unexpected error with IBM long double

2021-06-04 Thread tuliom at ascii dot art.br via Gcc-bugs
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

[Bug target/101324] powerpc64le: hashst appears before mflr at -O1 or higher

2021-07-06 Thread tuliom at ascii dot art.br via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101324 Tulio Magno Quites Machado Filho changed: What|Removed |Added Attachment #51105|0 |1 is

[Bug target/101324] New: powerpc64le: hashst appears before mflr at -O1 or higher

2021-07-05 Thread tuliom at ascii dot art.br via Gcc-bugs
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

[Bug target/101865] _ARCH_PWR8 is not defined when using -mcpu=power8

2021-08-25 Thread tuliom at ascii dot art.br via Gcc-bugs
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

[Bug target/101865] _ARCH_PWR8 is not defined when using -mcpu=power8

2021-08-26 Thread tuliom at ascii dot art.br via Gcc-bugs
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

[Bug target/101865] _ARCH_PWR8 is not defined when using -mcpu=power8

2021-08-26 Thread tuliom at ascii dot art.br via Gcc-bugs
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.

[Bug target/101865] New: _ARCH_PWR8 is not defined when using -mcpu=power8

2021-08-11 Thread tuliom at ascii dot art.br via Gcc-bugs
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

[Bug libstdc++/103387] powerpc64le: segmentation fault on std::cout with ieee128 long double variable

2021-11-24 Thread tuliom at ascii dot art.br via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103387 Tulio Magno Quites Machado Filho changed: What|Removed |Added CC||tuliom at ascii dot

[Bug libstdc++/109889] [13/14 Regression] Segfault in __run_exit_handlers since r13-5309-gc3c6c307792026

2023-05-17 Thread tuliom at ascii dot art.br via Gcc-bugs
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

[Bug libstdc++/109889] [13/14 Regression] Segfault in __run_exit_handlers since r13-5309-gc3c6c307792026

2023-05-17 Thread tuliom at ascii dot art.br via Gcc-bugs
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