[Bug c/63495] struct __attribute__ ((aligned (8))) broken on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63495 --- Comment #8 from Jakub Jelinek --- No, works just fine. Perhaps you are compiling with C++ when this is C?
[Bug tree-optimization/109429] New: ivopts: Compute complexity for unsupported addressing modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109429 Bug ID: 109429 Summary: ivopts: Compute complexity for unsupported addressing modes Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jovan.dmitrovic at syrmia dot com Target Milestone: --- Greetings everyone, I have pinged the mailing list about this issue about a month ago (I am not the original poster), and heard no response since. For some addressing modes, it seems that the complexity is calculated in sub-optimal manner. More information and a patch are contained in the link below. https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608895.html
[Bug tree-optimization/109430] New: ivopts: Revert register pressure cost when there are enough registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109430 Bug ID: 109430 Summary: ivopts: Revert register pressure cost when there are enough registers Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jovan.dmitrovic at syrmia dot com Target Milestone: --- Greetings everyone, this issue has been reported in December 2022, and I have since pinged the community once, but had no responses. The issue lies in register pressure costs being calculating improperly. More information and a patch are submitted at the link below. https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608896.html
[Bug c++/109431] New: internal compiler error: in output_constructor_regular_field (varasm.c:5207)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109431 Bug ID: 109431 Summary: internal compiler error: in output_constructor_regular_field (varasm.c:5207) Product: gcc Version: 9.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: gh0s-t at yandex dot ru Target Milestone: --- Created attachment 54815 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54815&action=edit preprocessed file for short source example Problem occurs from 9.1 to newer gcc versions. But code compiles on older convenient gcc versions. godbolt.org used. As I can see, the problem is in function body static and constexpr keywords mixing at array aggregate initialization with empty initializer-list (at line #111 in preprocessed file). Using built-in specs. COLLECT_GCC=/opt/compiler-explorer/gcc-9.1.0/bin/g++ Target: x86_64-linux-gnu Configured with: ../gcc-9.1.0/configure --prefix=/opt/compiler-explorer/gcc-build/staging --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap --enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --enable-clocale=gnu --enable-languages=c,c++,fortran,ada --enable-ld=yes --enable-gold=yes --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-linker-build-id --enable-lto --enable-plugins --enable-threads=posix --with-pkgversion=Compiler-Explorer-Build Thread model: posix gcc version 9.1.0 (Compiler-Explorer-Build) COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-g' '-o' '/app/output.s' '-masm=intel' '-S' '-v' '-std=c++17' '-g' '-D' '_REENTRANT' '-fPIC' '-pipe' '-Wall' '-Wextra' '-fsanitize=undefined' '-fno-strict-aliasing' '-fwrapv' '-fno-aggressive-loop-optimizations' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /opt/compiler-explorer/gcc-9.1.0/bin/../libexec/gcc/x86_64-linux-gnu/9.1.0/cc1plus -quiet -v -imultiarch x86_64-linux-gnu -iprefix /opt/compiler-explorer/gcc-9.1.0/bin/../lib/gcc/x86_64-linux-gnu/9.1.0/ -D_GNU_SOURCE -D _REENTRANT -quiet -dumpbase example.cpp -masm=intel -mtune=generic -march=x86-64 -auxbase-strip /app/output.s -g -g -Wall -Wextra -std=c++17 -version -fdiagnostics-color=always -fPIC -fsanitize=undefined -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -o /app/output.s GNU C++17 (Compiler-Explorer-Build) version 9.1.0 (x86_64-linux-gnu) compiled by GNU C version 7.3.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/opt/compiler-explorer/gcc-9.1.0/bin/../lib/gcc/x86_64-linux-gnu/9.1.0/../../../../x86_64-linux-gnu/include" ignoring duplicate directory "/opt/compiler-explorer/gcc-9.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/9.1.0/../../../../include/c++/9.1.0" ignoring duplicate directory "/opt/compiler-explorer/gcc-9.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/9.1.0/../../../../include/c++/9.1.0/x86_64-linux-gnu" ignoring duplicate directory "/opt/compiler-explorer/gcc-9.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/9.1.0/../../../../include/c++/9.1.0/backward" ignoring duplicate directory "/opt/compiler-explorer/gcc-9.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/9.1.0/include" ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring duplicate directory "/opt/compiler-explorer/gcc-9.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/9.1.0/include-fixed" ignoring nonexistent directory "/opt/compiler-explorer/gcc-9.1.0/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/9.1.0/../../../../x86_64-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /opt/compiler-explorer/gcc-9.1.0/bin/../lib/gcc/x86_64-linux-gnu/9.1.0/../../../../include/c++/9.1.0 /opt/compiler-explorer/gcc-9.1.0/bin/../lib/gcc/x86_64-linux-gnu/9.1.0/../../../../include/c++/9.1.0/x86_64-linux-gnu /opt/compiler-explorer/gcc-9.1.0/bin/../lib/gcc/x86_64-linux-gnu/9.1.0/../../../../include/c++/9.1.0/backward /opt/compiler-explorer/gcc-9.1.0/bin/../lib/gcc/x86_64-linux-gnu/9.1.0/include /opt/compiler-explorer/gcc-9.1.0/bin/../lib/gcc/x86_64-linux-gnu/9.1.0/include-fixed /usr/local/include /opt/compiler-explorer/gcc-9.1.0/bin/../lib/gcc/../../include /usr/include/x86_64-linux-gnu /usr/include End of search list. GNU C++17 (Compiler-Explorer-Build) version 9.1.0 (x86_64-linux-gnu) compiled by GNU C version 7.3.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 2c5ce497dfd6253343a5b735244577eb : In function 'int main()': :105:16: warning: variable 's' set but not used [-Wunused-but-set-variable] 105 | auto const s = parameterLimits(ParamId::Id1);
[Bug analyzer/109432] New: tracker bug for issues with -Wanalyzer-out-of-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109432 Bug ID: 109432 Summary: tracker bug for issues with -Wanalyzer-out-of-bounds Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: meta-bug Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: priour.be at gmail dot com CC: priour.be at gmail dot com Target Milestone: ---
[Bug c/64480] List designated initializer triggers -Wmissing-field-initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64480 zhonghao at pku dot org.cn changed: What|Removed |Added CC||zhonghao at pku dot org.cn --- Comment #4 from zhonghao at pku dot org.cn --- Is this bug fixed? I tried the latest gcc, but it still rejects the sample code.
[Bug c/29129] [4.2/4.3/4.4 Regression] [DR#341] unnamed parameters using [*]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29129 zhonghao at pku dot org.cn changed: What|Removed |Added CC||zhonghao at pku dot org.cn --- Comment #13 from zhonghao at pku dot org.cn --- I tried the latest gcc, but it rejects the sample code: :1:23: error: expected primary-expression before ']' token 1 | void f(unsigned int [*]); | ^ Compiler returned: 1 Is this a regression? Or, the idea is changed, and this code shall be rejected?
[Bug tree-optimization/109429] ivopts: Compute complexity for unsupported addressing modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109429 --- Comment #1 from Jovan Dmitrović --- It seems that commit f9f69dd changed the way complexity is calculated, so now the complexity equals zero across the board, for each candidate. Here is one testcase: void daxpy(float *vector1, float *vector2, int n, float fp_const) { for (int i = 0; i < n; ++i) vector1[i] += fp_const * vector2[i]; } void dgefa(float *vector, int m, int n, int l) { for (int i = 0; i < n - 1; ++i) { for (int j = i + 1; j < n; ++j) { float t = vector[m * j + l]; daxpy(&vector[m * i + i + 1], &vector[m * j + i + 1], n - (i + 1), t); } } } Following tables compare IV candidates. = Before f9f69dd = Group 1: cand costcompl. inv.expr.inv.vars 1 13 1 3; NIL; 2 13 2 4; NIL; 4 9 1 5; NIL; 5 1 0 NIL; NIL; 7 9 1 3; NIL; = Before f9f69dd = = After f9f69dd = Group 1: cand costcompl. inv.expr.inv.vars 1 10 0 4; NIL; 2 10 0 5; NIL; 4 6 0 6; NIL; 5 1 0 NIL; NIL; 7 6 0 4; NIL; = After f9f69dd = This leads to different candidate being selected in our test case. = Before f9f69dd = Selected IV set for loop 3 at fp_foo.c:3, 10 avg niters, 2 IVs: Candidate 4: Var befor: ivtmp.17_52 Var after: ivtmp.17_103 Incr POS: before exit test IV struct: Type: unsigned long Base: (unsigned long) (vector_27(D) + _10) Step: 4 Object: (void *) vector_27(D) Biv:N Overflowness wrto loop niter: Overflow Candidate 5: Var befor: ivtmp.18_99 Var after: ivtmp.18_98 Incr POS: before exit test IV struct: Type: unsigned long Base: (unsigned long) (vector_27(D) + _14) Step: 4 Object: (void *) vector_27(D) Biv:N Overflowness wrto loop niter: Overflow = Before f9f69dd = = After f9f69dd = Selected IV set for loop 3 at fp_foo.c:3, 10 avg niters, 1 IVs: Candidate 4: Var befor: ivtmp.17_52 Var after: ivtmp.17_103 Incr POS: before exit test IV struct: Type: unsigned long Base: (unsigned long) (vector_27(D) + _10) Step: 4 Object: (void *) vector_27(D) Biv:N Overflowness wrto loop niter: Overflow = After f9f69dd = Finally, here is the difference in assembly: = Before f9f69dd = .L83: lwc1$f5,0($3) lwc1$f8,0($2) lwc1$f7,4($2) lwc1$f6,8($2) lwc1$f9,12($2) lwc1$f10,16($2) maddf.s $f8,$f0,$f5 lwc1$f11,20($2) lwc1$f12,24($2) lwc1$f13,28($2) ld $12,72($sp) swc1$f8,0($2) lwc1$f14,4($3) maddf.s $f7,$f0,$f14 swc1$f7,4($2) lwc1$f15,8($3) maddf.s $f6,$f0,$f15 swc1$f6,8($2) lwc1$f16,12($3) maddf.s $f9,$f0,$f16 swc1$f9,12($2) lwc1$f17,16($3) maddf.s $f10,$f0,$f17 swc1$f10,16($2) lwc1$f18,20($3) maddf.s $f11,$f0,$f18 swc1$f11,20($2) lwc1$f19,24($3) maddf.s $f12,$f0,$f19 swc1$f12,24($2) lwc1$f20,28($3) maddf.s $f13,$f0,$f20 swc1$f13,28($2) daddiu $2,$2,32 bne $2,$12,.L83 daddiu $3,$3,32 ... = Before f9f69dd = = After f9f69dd = .L93: dsubu $18,$2,$4 lwc1$f13,0($2) daddu $19,$18,$5 daddiu $16,$2,4 lwc1$f14,0($19) dsubu $17,$16,$4 daddu $25,$17,$5 lwc1$f15,4($2) daddiu $19,$2,12 daddiu $20,$2,8 maddf.s $f13,$f1,$f14 dsubu $16,$19,$4 daddiu $17,$2,16 dsubu $18,$20,$4 daddu $19,$16,$5 daddiu $16,$2,20 lwc1$f10,8($2) daddu $20,$18,$5 lwc1$f16,12($2) dsubu $18,$17,$4 lwc1$f17,16($2) dsubu $17,$16,$4 lwc1$f18,20($2) daddiu $16,$2,24 lwc1$f20,24($2) daddu $18,$18,$5 swc1$f13,0($2) daddu $17,$17,$5 lwc1$f19,0($25) daddiu $25,$2,28 lwc1$f11,28($2) daddiu $2,$2,32 dsubu $16,$16,$4 dsubu $25,$25,$4 maddf.s $f15,$f1,$f19 daddu $16,$16,$5 daddu $25,$25,$5 swc1$f15,-28($2) lwc1$f21,0($20) ld $20,48($sp) maddf.s $f10,$f1,$f21 swc1$f10,-
[Bug tree-optimization/109407] instruction cmpxchgl run error when using with g++ -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109407 --- Comment #2 from johgjc --- thank you very much. At 2023-04-04 23:55:25, "pinskia at gcc dot gnu.org" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109407 > >Andrew Pinski changed: > > What|Removed |Added > > Resolution|--- |INVALID > Status|UNCONFIRMED |RESOLVED > >--- Comment #1 from Andrew Pinski --- >The inline-asm is incorrect as the EAX/RAX register gets clobbered by cmpxchgl >So you need something like (which works now): > >int tmp; >__asm__ __volatile__( >"lock;" >"cmpxchgl %[NEW_VALUE], %[DST];" >"sete %[RET];" >: [RET] "=q"(dwRtnV),[DST] "+m"(dwOriV) >, "=a"(tmp) // newly added >:[NEW_VALUE] "r"(dwDstV), "a"(dwExpV) >: "memory", "cc" >); > >-- >You are receiving this mail because: >You reported the bug.
[Bug libstdc++/88508] std::bad_cast in std::basic_ostringstream.oss.fill()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88508 --- Comment #3 from Jonathan Wakely --- (In reply to Frank Heckenbach from comment #2) > And all that because the library > doesn't know what the space character is in UTF-8. That's a completely wrong description of the problem. The standard library does not come with support for using char8_t as the character type for streams. That's it. Period. The problem has nothing to do with the setw manipulator or the space character or even UTF-8, it's that char8_t type is not supported by streams out of the box. You would need to imbue the stream with the relevant facets such as ctype.
[Bug c/64480] List designated initializer triggers -Wmissing-field-initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64480 --- Comment #5 from Jonathan Wakely --- (In reply to zhonghao from comment #4) > Is this bug fixed? I tried the latest gcc, but it still rejects the sample > code. No, the latest gcc accepts this C code without errors. Please stop commenting on old bugs if you are not capable of understanding the difference between C and C++, or I will block your account.
[Bug c/29129] [4.2/4.3/4.4 Regression] [DR#341] unnamed parameters using [*]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29129 --- Comment #14 from Jonathan Wakely --- You need to change godbolt.org to compile C not C++. Please stop adding completely useless comments to bugzilla or I will block your account.
[Bug c/109426] Gcc runs into Infinite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109426 --- Comment #4 from Jonathan Wakely --- N.B. this code is just copied from PR 54402. It might have been helpful to say where you found the code. zhonghao, it's really not helpful to just copy&paste code that you don't understand into bug reports with stupid, incorrect claims like "while expanding templates". Maybe you're trying to be helpful, but you're just wasting our time.
[Bug tree-optimization/109429] ivopts: Compute complexity for unsupported addressing modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109429 --- Comment #2 from Jovan Dmitrović --- *** Bug 109430 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/109430] ivopts: Revert register pressure cost when there are enough registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109430 Jovan Dmitrović changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jovan Dmitrović --- Moved to 109429, as this doesn't warrant a thread of its own. *** This bug has been marked as a duplicate of bug 109429 ***
[Bug tree-optimization/109429] ivopts: Compute complexity for unsupported addressing modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109429 --- Comment #3 from Jovan Dmitrović --- Another thing that has come to attention is the register pressure costs being calculated improperly. More information and a patch are submitted at the link below. https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608896.html
[Bug c++/109431] internal compiler error: in output_constructor_regular_field (varasm.c:5207)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109431 --- Comment #1 from Andrew Pinski --- Reduced: ``` struct RangeLimits { int low = 0; int high = 1; constexpr RangeLimits() { } }; template int parameterLimits(void) { static RangeLimits constexpr param_limits[ 2 ] = {}; auto const &limits = param_limits[ 1 ]; return 0; } auto s = parameterLimits<1>(); ```
[Bug c++/109431] [10/11/12/13 Regression] internal compiler error: in output_constructor_regular_field with static constexpr array inside a template constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109431 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.5 Known to fail||9.1.0 Status|UNCONFIRMED |NEW Keywords||ice-on-valid-code, ||needs-bisection Known to work||8.5.0 Ever confirmed|0 |1 Summary|internal compiler error: in |[10/11/12/13 Regression] |output_constructor_regular_ |internal compiler error: in |field (varasm.c:5207) |output_constructor_regular_ ||field with static constexpr ||array inside a template ||constexpr function Last reconfirmed||2023-04-06 --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug c++/109433] New: [12/13 Regression] ICE with -std=c++11 and static constexpr array inside a template constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109433 Bug ID: 109433 Summary: [12/13 Regression] ICE with -std=c++11 and static constexpr array inside a template constexpr Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Note this is not exactly a dup of bug 109431 as it works in GCC 11.3.0. Note also it ICEs with -std=c++14 in GCC 11.3.0 (which looks to be the same as PR109431 ) but works with -std=c++11. testcase: ``` struct RangeLimits { int low = 1; }; template int parameterLimits(void) { static RangeLimits constexpr param_limits[ 2 ] = {}; auto const &limits = param_limits[ 1 ]; return 0; } auto s = parameterLimits<1>(); ``` Maybe they are the same issue but I am not 100% sure as they regressed at different times and produce different ICEs. The ICE on the trunk: :10:55: internal compiler error: unexpected expression 'const RangeLimits()' of kind cast_expr 10 | static RangeLimits constexpr param_limits[ 2 ] = {}; | ^
[Bug c++/109433] [12/13 Regression] ICE with -std=c++11 and static constexpr array inside a template constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109433 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.3 Keywords||needs-bisection
[Bug c/109426] Gcc runs into Infinite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109426 --- Comment #5 from Xi Ruoyao --- (In reply to Jonathan Wakely from comment #4) > N.B. this code is just copied from PR 54402. It might have been helpful to > say where you found the code. > > zhonghao, it's really not helpful to just copy&paste code that you don't > understand into bug reports with stupid, incorrect claims like "while > expanding templates". Maybe you're trying to be helpful, but you're just > wasting our time. I'm wondering if this is an attempt for some kind of "academic research" here like the notorious UMN incident in LKML.
[Bug target/103698] [12 regression] Code assigned to __attribute__((section(".data"))) generates invalid dwarf: leb128 operand is an undefined symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103698 Matthijs Kooijman changed: What|Removed |Added CC||matthijs at stdin dot nl --- Comment #4 from Matthijs Kooijman --- I also ran into this problem, with an STM32 codebase that uses libopencm3 (for peripheral code and the linker script) and uses section(".data") to put a bit of code in RAM (to prevent flash reads while programming flash). To fix this problem in my code, I switched from section(".data") to section(".ramtext"), which is second section that is also put into RAM and seems intended especially for this purpose. This works with the libopencm3 linker script, which defines this section, YMMV with other linker scripts. E.g. from https://github.com/libopencm3/libopencm3/blob/189017b25cebfc609a6c1a5a02047691ef845b1b/ld/linker.ld.S#L136: .data : { _data = .; *(.data*) /* Read-write initialized data */ *(.ramtext*)/* "text" functions to run in ram */ . = ALIGN(4); _edata = .; } >ram AT >rom >From looking at the linker script, it seems that .data and .ramtext are treated pretty much in the same way, so I suspect that there is something else (maybe some builtin rules in gcc/ld/as) that make the data section special in a way that it causes this problem to be triggered. Hopefully this is helpful for anyone else running into this same problem.
[Bug c/109426] Gcc runs into Infinite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109426 --- Comment #6 from Jonathan Wakely --- It's a pattern with this person: https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&cf_known_to_fail_type=allwords&cf_known_to_work_type=allwords&email1=zhonghao%40pku.org.cn&emailreporter1=1&emailtype1=substring&list_id=377697&product=gcc&query_format=advanced&resolution=INVALID See PR 86306 for discussion and their justification for these low quality reports. I think they're genuinely trying to be helpful, just not succeeding.
[Bug c++/109434] New: std::optional weird -Wmaybe-unitialized and behaviour with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109434 Bug ID: 109434 Summary: std::optional weird -Wmaybe-unitialized and behaviour with -O2 Product: gcc Version: 12.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tomas.pecka at cesnet dot cz Target Milestone: --- Created attachment 54816 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54816&action=edit reproducer Hello, I've seen a compile warning on a code (see attachment) that looks bogus. In file included from optional.cpp:2: In member function ‘constexpr bool std::_Optional_base_impl<_Tp, _Dp>::_M_is_engaged() const [with _Tp = int; _Dp = std::_Optional_base]’, inlined from ‘constexpr bool std::optional<_Tp>::has_value() const [with _Tp = int]’ at /usr/include/c++/12.2.1/optional:988:35, inlined from ‘int main()’ at optional.cpp:21:63: /usr/include/c++/12.2.1/optional:471:58: warning: ‘*(unsigned char*)((char*)&optInt + offsetof(std::optional,std::optional::.std::_Optional_base::_M_payload.std::_Optional_payload::.std::_Optional_payload_base::_M_engaged))’ may be used uninitialized [-Wmaybe-uninitialized] 471 | { return static_cast(this)->_M_payload._M_engaged; } | ^~ optional.cpp: In function ‘int main()’: optional.cpp:15:24: note: ‘*(unsigned char*)((char*)&optInt + offsetof(std::optional,std::optional::.std::_Optional_base::_M_payload.std::_Optional_payload::.std::_Optional_payload_base::_M_engaged))’ was declared here 15 | std::optional optInt; |^~ The warning is present only when compiling with -Wall -O2. When I run the executable, I see unexpected weird output, e.g. catch 56 val=72704.00 which look like some uninitialized variable is really there. When run under valgrind, I see reports about unitialized variables. Code seems to be working correctly when compiled with -O1 or lower and the executable seem to be behaving expectedly as well. Compiling and executing under clang++ works as well regardless of the optimization level. I don't have older versions of g++ (< 12) but compiling the attached code on godbolt with g++ 11 and lower does not trigger any warning. Interesting part is that declaring optDbl as std::optional makes the code behave correctly.
[Bug tree-optimization/109434] [12/13 Regression] std::optional weird -Wmaybe-unitialized and behaviour with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109434 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-04-06 Known to fail||12.1.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Keywords||needs-bisection, ||needs-reduction Summary|std::optional weird |[12/13 Regression] |-Wmaybe-unitialized and |std::optional weird |behaviour with -O2 |-Wmaybe-unitialized and ||behaviour with -O2 Target Milestone|--- |12.3 Known to work||10.1.0, 11.1.0 --- Comment #1 from Andrew Pinski --- DSE2 removes the original store: optInt = {}; optInt = foo (); Deleted dead store: optInt = {}; Even though foo can throw ... Confirmed.
[Bug target/82028] Windows x86_64 should not pass float aggregates in xmm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82028 --- Comment #6 from LIU Hao --- Looks like this has been fixed? https://gcc.godbolt.org/z/xP5E76aYz Despite that however, GCC generates suboptimal code that uses an XMM register to perform the bitwise AND operation.
[Bug tree-optimization/109417] [13 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault since r13-6945
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109417 --- Comment #3 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:7f056d5f4a0b9e29561d0375d5b4ad42c9f3f61e commit r13-7113-g7f056d5f4a0b9e29561d0375d5b4ad42c9f3f61e Author: Andrew MacLeod Date: Wed Apr 5 15:59:38 2023 -0400 Check if dependency is valid before using in may_recompute_p. When the IL is rewritten after a statement has been processed and dependencies cached, its possible that an ssa-name in the dependency cache is no longer in the IL. Check this before trying to recompute. PR tree-optimization/109417 gcc/ * gimple-range-gori.cc (gori_compute::may_recompute_p): Check if dependency is in SSA_NAME_FREE_LIST. gcc/testsuite/ * gcc.dg/pr109417.c: New.
[Bug tree-optimization/109417] [13 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: Segmentation fault since r13-6945
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109417 Andrew Macleod changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Andrew Macleod --- fixed.
[Bug lto/109428] GCC did not fix CVE-2022-37434, a heap overflow bug introduced by its dependency zlib code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109428 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #6 from Xi Ruoyao --- FWIW use --with-system-zlib when you configure GCC if you want to use zlib installed on the system instead of the shipped copy.
[Bug c++/109433] [12/13 Regression] ICE with -std=c++11 and static constexpr array inside a template constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109433 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Keywords|needs-bisection | Status|UNCONFIRMED |NEW Priority|P3 |P2 Ever confirmed|0 |1 Last reconfirmed||2023-04-06 --- Comment #1 from Jakub Jelinek --- With -std=c++11, started to ICE with r12-6326-ge948436eab818c527dd6. With -std=c++14, started to ICE with r9-1483-g307193b82cecb8ab79cf.
[Bug c++/109431] [10/11/12/13 Regression] internal compiler error: in output_constructor_regular_field with static constexpr array inside a template constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109431 Marek Polacek changed: What|Removed |Added Keywords|needs-bisection | CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- Started with r262173: commit 307193b82cecb8ab79cf8880d642e1a3acb9c9f6 Author: Jason Merrill Date: Tue Jun 26 22:59:44 2018 -0400 PR c++/86320 - memory-hog with std::array of pair
[Bug c++/109425] mismatched argument pack lengths while expanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109425 --- Comment #3 from Marek Polacek --- (In reply to Hannes Hauswedell from comment #2) > Thanks for the quick reply, and nice that it is already fixed for 13! > > I assume this will not be backported? It wouldn't be a huge problem, because > it is possible to workaround with non-friend operators. I think this is up to Patrick to decide.
[Bug c++/109425] mismatched argument pack lengths while expanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109425 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #4 from Patrick Palka --- (In reply to Hannes Hauswedell from comment #2) > Thanks for the quick reply, and nice that it is already fixed for 13! > > I assume this will not be backported? It wouldn't be a huge problem, because > it is possible to workaround with non-friend operators. It's already been backported to the 12 branch, so the upcoming GCC 12.3 (or a recent enough snapshot of the release branch) will also include the fix. No decision yet about backporting to the 11/10 branches. Having to work around this by defining these functions as non-friends is pretty inconvenient..
[Bug c++/107853] [10/11 Regression] variadic template with a variadic template friend with a requires of fold expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107853 Patrick Palka changed: What|Removed |Added Summary|[10/11/12 Regression] |[10/11 Regression] variadic |variadic template with a|template with a variadic |variadic template friend|template friend with a |with a requires of fold |requires of fold expression |expression | --- Comment #9 from Patrick Palka --- Fixed for GCC 13 and 12.3 so far
[Bug other/109435] New: [MIPS64R6] Typedef struct alignment returns incorrect results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109435 Bug ID: 109435 Summary: [MIPS64R6] Typedef struct alignment returns incorrect results Product: gcc Version: 10.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: jovan.dmitrovic at syrmia dot com Target Milestone: --- Consider the following testcase: #include typedef struct uint8 { unsigned v[8]; } uint8 __attribute__ ((aligned(128))); unsigned callee(int x, uint8 a) { return a.v[0]; } uint8 identity(uint8 in) { return in; } int main() { uint8 vec = {1, 2, 3, 4, 5, 6, 7, 8}; printf("res1: %d\n", callee(99, identity(vec))); uint8 temp = identity(vec); printf("res2: %d\n", callee(99, temp)); } When this code is compiled for MIPS64 R6, output is as follows: res1: 3 res2: 1 However, when aligned attribute is removed from the testcase, res1 and res2 become 1, which are values that were expected in the first place. Furthermore, this bug is reproducible only if there is a unused argument x in function callee. Adding more arguments or switching their places also produces expected values. Type of x doesn't seem to impact the result.
[Bug other/109435] [MIPS64R6] Typedef struct alignment returns incorrect results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109435 --- Comment #1 from Jovan Dmitrović --- This is compile command that I used: mipsisa64r6-linux-gnuabi64-gcc -march=mips64r6 -mabi=64 -O0 -o foo foo.c -static I used the MIPS gcc package from Ubuntu's package repository. Also, I used qemu-mips64 to run the executable file.
[Bug target/109416] Missed constant propagation cases after reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109416 --- Comment #3 from Sinan --- Hi Andrew, Thank you for taking the time to explain the issue. I appreciate it. I think the issue between init/init2 and init3 might be different. Regarding init3, any 32-bit backend attempting to split a complex constant will encounter such a suboptimal case. I tried with mip in gcc 12, and here are the ouputs for `init` and `init3` init: lui $2,%hi(Data) move$5,$0 move$4,$0 sw $5,%lo(Data+4)($2) jr $31 sw $4,%lo(Data)($2) init3: lui $2,%hi(Data) li $5,15 # 0xf li $4,15 # 0xf sw $5,%lo(Data+4)($2) jr $31 sw $4,%lo(Data)($2) register $4 or $5 could be eliminated.
[Bug target/82028] Windows x86_64 should not pass float aggregates in xmm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82028 --- Comment #7 from LIU Hao --- clang generates 14 bytes: ``` mov rax, 0x7FFF # 48 B8 FF FF FF FF FF FF FF 7F and rax, rcx # 48 23 C1 ret # C3 `` but in principle this function requires only 8 bytes: ``` lea rax, qword ptr [rcx + rcx]# 48 8D 04 09 shr rax, 1# 48 D1 E8 ret # C3 ``
[Bug target/107674] [11/12/13 Regressions] arm: MVE codegen regressions on VCTP and vector LDR/STR instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107674 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Earnshaw : https://gcc.gnu.org/g:ddc9b5ee13cd686c8674f92d46045563c06a23ea commit r13-7114-gddc9b5ee13cd686c8674f92d46045563c06a23ea Author: Richard Earnshaw Date: Thu Apr 6 14:44:30 2023 +0100 arm: mve: fix auto-inc generation [PR107674] My change r13-416-g485a0ae0982abe caused the compiler to stop generating auto-inc operations on mve loads and stores. The fix is to check whether there is a replacement register available when in strict mode and the register is still a pseudo. gcc: PR target/107674 * config/arm/arm.cc (arm_effective_regno): New function. (mve_vector_mem_operand): Use it.
[Bug target/109402] v850: non-v850e version of __muldi3() in /libgcc/config/v850/lib1funcs.S operates sp in reversed direction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109402 --- Comment #2 from Mikael Pettersson --- Please send patches to gcc-patches for review.
[Bug target/109436] New: AArch64: suboptimal codegen in 128 bit constant stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109436 Bug ID: 109436 Summary: AArch64: suboptimal codegen in 128 bit constant stores Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sinan.lin at linux dot alibaba.com Target Milestone: --- When splitting a 128-bit constant, there may be cases where the part that is cut out is a constant 0. And we could use a zero register to avoid the "mov reg, 0" instruction. e.g. ``` __int128 Data; void init() { Data = 0xf; } ``` gcc ``` init: adrpx0, .LANCHOR0 add x0, x0, :lo12:.LANCHOR0 mov x2, 1048575 mov x3, 0 stp x2, x3, [x0] ret ``` clang ``` init: mov w8, #1048575 adrpx9, Data add x9, x9, :lo12:Data stp x8, xzr, [x9] ret ```
[Bug c++/88061] section attributes of variable templates are ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88061 --- Comment #6 from Barry Revzin --- Any action on this one? A workaround right now is to change code that would ideally look like (which is pretty clean in my opinion): template void foo() { [[gnu::section(".meow")]] static int value = 0; } to code that looks like: template void foo() { static int PUT_IN_MEOW_value = 0; } and add a linker script that moves these variables over: .meow : { KEEP(*(SORT(.*PUT_IN_MEOW_*))) } But this is, to put it mildly, less than ideal.
[Bug analyzer/109437] New: -Wanalyzer-out-of-bounds is emitted at most once per frame.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109437 Bug ID: 109437 Summary: -Wanalyzer-out-of-bounds is emitted at most once per frame. Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: priour.be at gmail dot com CC: priour.be at gmail dot com Target Milestone: --- Build: 13.0.1 20230328 (experimental) OOB refers to Out-Of-Bounds. Curiously, it seems that if a frame was a cause for a OOB (either by containing the spurious code or by being a caller to such code), it will only emit one set of warning, rather than at each unique compromising statements. int consecutive_oob_in_frame () { int arr[] = {1,2,3,4,5,6,7}; int y1 = arr[9]; // only this one is diagnosed int y2 = arr[10]; // no OOB warning emitted here ... int y3 = arr[50]; // ... nor here. return (y1+y2+y3); } int main () { consecutive_oob_in_frame (); // OOB warning emitted int x [] = {1,2}; x[5]; /* silent, probably because another set of OOB warnings has already been issued with this frame being the source */ return 0; } As per David suggestion, it might be worth to implement pending_diagnostic::supercedes_p vfunc for the OOB checker.
[Bug analyzer/109438] New: Excessive Duplication of -Wanalyzer-out-of-bounds warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109438 Bug ID: 109438 Summary: Excessive Duplication of -Wanalyzer-out-of-bounds warnings Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: priour.be at gmail dot com CC: priour.be at gmail dot com Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Build: 13.0.1 20230328 (experimental) The reproducer below demonstrates an excessive duplication of the same warning -Wanalyzer-out-of-bounds. The warning appears duplicated thrice, at points (1), (2) and (3), yet none appear at (4) (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109437) See https://godbolt.org/z/Tcrv8h614 for live warnings on trunk, both gcc and g++. int consecutive_oob_in_frame () // one warning from analysis of initial EN { int arr[] = {1,2,3,4,5,6,7}; int y1 = arr[9]; // injurious line (1) return y1; } int goo () { int x = consecutive_oob_in_frame (); // causes another warning (2) return 2 * x; } int main () { goo (); // causes another warning (3) consecutive_oob_in_frame (); // silent (4) return 0; } Currently the expected behavior would be to see it appear whenever when consecutive_oob_in_frame is called directly. It means that the above should rather emits at points (2) and (4).
[Bug ipa/107769] [12/13 Regression] -flto with -Os/-O2/-O3 emitted code with gcc 12.x segfaults via mutated global in .rodata since r12-2887-ga6da2cddcf0e959d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107769 --- Comment #7 from Martin Jambor --- Created attachment 54817 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54817&action=edit potential patch I am testing the attached patch. I'd like to think about the whole situation a bit more next week, but this seems like a way to fix this and PR 109318.
[Bug ipa/109318] [12/13 Regression] csmith: -fipa-cp seems to cause trouble since r12-2523-g13586172d0b70c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109318 --- Comment #10 from Martin Jambor --- The problem is actually slightly different, I have just attached a possible fix to both to PR 107769.
[Bug analyzer/109439] New: RFE: Spurious -Wanalyzer-use-of-uninitialized-value tagging along -Wanalyzer-out-of-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109439 Bug ID: 109439 Summary: RFE: Spurious -Wanalyzer-use-of-uninitialized-value tagging along -Wanalyzer-out-of-bounds Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: priour.be at gmail dot com CC: priour.be at gmail dot com Target Milestone: --- Build: 13.0.1 20230328 (experimental) For every -Wanalyzer-out-of-bounds, a corresponding -Wanalyzer-use-of-initialized-value seemingly tags along. As most likely fixing the former would also fix the latter, it would make sense to only have a OOB diagnosed. Tested on trunk. int would_like_only_oob () { int arr[] = {1,2,3,4,5,6,7}; int y1 = arr[9]; // 2 warnings instead of only OOB warning are emitted here return y1; } In the mail list, David suggested that "Maybe we could fix this by having region_model::check_region_bounds return a bool that signifies if the access is valid, and propagating that value up through callers so that we can return a non- poisoned_svalue at the point where we'd normally return an "uninitialized" poisoned_svalue. Alternatively, we could simply terminate any analysis path in which an OOB access is detected (by implementing the pending_diagnostic::terminate_path_p virtual function for class out_of_bounds)."
[Bug target/108177] MVE predicated stores to same address get optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108177 --- Comment #5 from Stam Markianos-Wright --- With the fix to MVE auto_inc having gone in as ddc9b5ee13cd686c8674f92d46045563c06a23ea I have found that this fix keeps the auto-inc on these predicated stores broken. It seems to fail in auto_inc_dec at this condition: ``` /* Make sure this reg appears only once in this insn. */ if (count_occurrences (PATTERN (mem_insn.insn), mem_insn.reg0, 1) != 1) { if (dump_file) fprintf (dump_file, "mem count failure\n"); return false; } ``` (which makes sense with the pattern now having the MEM appear twice) I guess this is not urgent since this is only a performance impact on one instruction. Also if the change needs to be in the auto-inc pass instead of the backend, then likely something for GCC14, but I thought this would be a good place to record this ;) Does anyone have any ideas on this? Or I wonder what the AVX case does for this
[Bug tree-optimization/109440] New: Missed optimization of vector::at when a function is called inside the loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109440 Bug ID: 109440 Summary: Missed optimization of vector::at when a function is called inside the loop Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hiraditya at msn dot com Target Milestone: --- #include #include using namespace std; bool bar(); using T = int; T vat(std::vector v) { T s; for (auto i = 0; i < v.size(); ++i) { if (bar()) s += v.at(i); } return s; } $ gcc -O2 -fexceptions -fno-unroll-loops .LC0: .string "vector::_M_range_check: __n (which is %zu) >= this->size() (which is %zu)" vat(std::vector >): mov rax, QWORD PTR [rdi] cmp QWORD PTR [rdi+8], rax je .L9 pushr12 pushrbp mov rbp, rdi pushrbx xor ebx, ebx jmp .L6 .L14: mov rax, QWORD PTR [rbp+8] sub rax, QWORD PTR [rbp+0] add rbx, 1 sar rax, 2 cmp rbx, rax jnb .L13 .L6: callbar() testal, al je .L14 mov rcx, QWORD PTR [rbp+0] mov rdx, QWORD PTR [rbp+8] sub rdx, rcx sar rdx, 2 mov rax, rdx cmp rbx, rdx jnb .L15 add r12d, DWORD PTR [rcx+rbx*4] add rbx, 1 cmp rbx, rax jb .L6 .L13: mov eax, r12d pop rbx pop rbp pop r12 ret .L9: mov eax, r12d ret .L15: mov rsi, rbx mov edi, OFFSET FLAT:.LC0 xor eax, eax callstd::__throw_out_of_range_fmt(char const*, ...)
[Bug target/70243] PowerPC V4SFmode should not use Altivec instructions on VSX systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70243 Segher Boessenkool changed: What|Removed |Added Status|WAITING |NEW Priority|P3 |P1 --- Comment #6 from Segher Boessenkool --- We should not use any VMX insn unless explicitly asked for it, since those do not work as expected if VSCR[NJ]=1, which unfortunately is the default on Linux (but not on powerpc64le-linux; that is a separate (kernel) bug). Rounding mode does not matter too much, if we have some subset of fast-math anyway; the only rounding mode in VMX is round-to-nearest-ties-to-even, which is the default for most everything else). But NJ=1 makes arithmetic behave completely unexpectedly, and it isn't actually faster than NJ=0 on modern hardware anyway. We cannot change the default for setting NJ because some code might rely on it, unfortunately. Luckily disabling generating all VMX insns automatically (i.e. without it being explicitly asked for) isn't all that expensive, just ends up as a few more move instructions here and there. This isn't a regression, but we should have this in GCC 13.
[Bug tree-optimization/109441] New: missed optimization when all elements of vector are known
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109441 Bug ID: 109441 Summary: missed optimization when all elements of vector are known Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hiraditya at msn dot com Target Milestone: --- Reference: https://godbolt.org/z/af4x6zhz9 When all elements of vector are 0, then the compiler should be able to remove the loop and just return 0. Testcase: #include using namespace std; using T = int; T v() { T s; std::vector v; v.resize(1000, 0); for (auto i = 0; i < v.size(); ++i) { s += v[i]; } return s; } $ g++ -O3 -std=c++17 .LC0: .string "vector::_M_fill_insert" v(): push rbx pxor xmm0, xmm0 mov edx, 1000 xor esi, esi sub rsp, 48 lea rcx, [rsp+12] lea rdi, [rsp+16] mov QWORD PTR [rsp+32], 0 mov DWORD PTR [rsp+12], 0 movaps XMMWORD PTR [rsp+16], xmm0 call std::vector >::_M_fill_insert(__gnu_cxx::__normal_iterator > >, unsigned long, int const&) mov rdx, QWORD PTR [rsp+24] mov rdi, QWORD PTR [rsp+16] mov rax, rdx sub rax, rdi mov rsi, rax sar rsi, 2 cmp rdx, rdi je .L99 test rax, rax mov ecx, 1 cmovne rcx, rsi cmp rax, 12 jbe .L107 mov rdx, rcx pxor xmm0, xmm0 mov rax, rdi shr rdx, 2 sal rdx, 4 add rdx, rdi .L101: movdqu xmm2, XMMWORD PTR [rax] add rax, 16 paddd xmm0, xmm2 cmp rdx, rax jne .L101 movdqa xmm1, xmm0 psrldq xmm1, 8 paddd xmm0, xmm1 movdqa xmm1, xmm0 psrldq xmm1, 4 paddd xmm0, xmm1 movd ebx, xmm0 test cl, 3 je .L99 and rcx, -4 mov eax, ecx .L100: lea edx, [rax+1] add ebx, DWORD PTR [rdi+rcx*4] movsx rdx, edx cmp rdx, rsi jnb .L99 add eax, 2 lea rcx, [0+rdx*4] add ebx, DWORD PTR [rdi+rdx*4] cdqe cmp rax, rsi jnb .L99 add ebx, DWORD PTR [rdi+4+rcx] .L99: test rdi, rdi je .L98 mov rsi, QWORD PTR [rsp+32] sub rsi, rdi call operator delete(void*, unsigned long) .L98: add rsp, 48 mov eax, ebx pop rbx ret .L107: xor eax, eax xor ecx, ecx jmp .L100 mov rbx, rax jmp .L105 v() [clone .cold]:
[Bug tree-optimization/109440] Missed optimization of vector::at when a function is called inside the loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109440 Andrew Pinski changed: What|Removed |Added Keywords||alias --- Comment #1 from Andrew Pinski --- There are a few things, the most obvious thing is the middle-end thinks the content of v can change via the call to foo. If you make a local copy, then there is a missing VRP which can be fixed by changing the type of i to size_t.
[Bug tree-optimization/109441] missed optimization when all elements of vector are known
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109441 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Severity|normal |enhancement
[Bug tree-optimization/109441] missed optimization when all elements of vector are known
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109441 --- Comment #1 from AK --- I guess a better test case is this: #include using namespace std; using T = int; T v(std::vector v) { T s; std::fill(v.begin(), v.end(), T()); for (auto i = 0; i < v.size(); ++i) { s += v[i]; } return s; } which has similar effect. $ g++ -O3 -std=c++17 v(std::vector >): pushrbp pushrbx sub rsp, 8 mov rbp, QWORD PTR [rdi+8] mov rcx, QWORD PTR [rdi] cmp rcx, rbp je .L7 sub rbp, rcx mov rdi, rcx xor esi, esi mov rbx, rcx mov rdx, rbp callmemset mov rdi, rbp mov edx, 1 mov rcx, rbx sar rdi, 2 testrbp, rbp cmovne rdx, rdi cmp rbp, 12 jbe .L8 mov rax, rdx pxorxmm0, xmm0 shr rax, 2 sal rax, 4 add rax, rbx .L4: movdqu xmm2, XMMWORD PTR [rbx] add rbx, 16 paddd xmm0, xmm2 cmp rbx, rax jne .L4 movdqa xmm1, xmm0 psrldq xmm1, 8 paddd xmm0, xmm1 movdqa xmm1, xmm0 psrldq xmm1, 4 paddd xmm0, xmm1 movdeax, xmm0 testdl, 3 je .L1 and rdx, -4 mov esi, edx .L3: add eax, DWORD PTR [rcx+rdx*4] lea edx, [rsi+1] movsx rdx, edx cmp rdx, rdi jnb .L1 add esi, 2 lea r8, [0+rdx*4] add eax, DWORD PTR [rcx+rdx*4] movsx rsi, esi cmp rsi, rdi jnb .L1 add eax, DWORD PTR [rcx+4+r8] .L1: add rsp, 8 pop rbx pop rbp ret .L7: add rsp, 8 xor eax, eax pop rbx pop rbp ret .L8: xor eax, eax xor esi, esi xor edx, edx jmp .L3
[Bug c/86584] Incorrect -Wsequence-point warning on structure member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86584 oliver at futaura dot co.uk changed: What|Removed |Added CC||oliver at futaura dot co.uk --- Comment #1 from oliver at futaura dot co.uk --- Confirmed here. Still happens with gcc (adtools build 11.2.0) 11.2.0: test.c: In function 'main': test.c:13:24: warning: operation on 's.f' may be undefined [-Wsequence-point] 13 | func(&s.f, s.f = 1); |^~~ It really doesn't make much sense for gcc to think this a problem. Going to have to disable the warning here as I can't seem to figure a way around it with unnecessarily rewriting huge chunks of code.
[Bug c/86584] Incorrect -Wsequence-point warning on structure member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86584 --- Comment #2 from Andrew Pinski --- I think there is just a missing warning for the plain decl case and the structure member case is not a spurious warning.
[Bug tree-optimization/109442] New: Dead local copy of std::vector not removed from function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442 Bug ID: 109442 Summary: Dead local copy of std::vector not removed from function Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hiraditya at msn dot com Target Milestone: --- T vat1(std::vector v1) { auto v = v1; return 10; } g++ -O3 -std=c++20 -fno-exceptions vat1(std::vector >): mov rax, QWORD PTR [rdi+8] sub rax, QWORD PTR [rdi] je .L11 pushrbp mov rbp, rax movabs rax, 9223372036854775804 pushrbx sub rsp, 8 cmp rax, rbp jb .L15 mov rbx, rdi mov rdi, rbp calloperator new(unsigned long) mov rsi, QWORD PTR [rbx] mov rdx, QWORD PTR [rbx+8] mov rdi, rax sub rdx, rsi cmp rdx, 4 jle .L16 callmemmove mov rdi, rax .L6: mov rsi, rbp calloperator delete(void*, unsigned long) add rsp, 8 mov eax, 10 pop rbx pop rbp ret .L11: mov eax, 10 ret .L15: callstd::__throw_bad_array_new_length() .L16: jne .L6 mov eax, DWORD PTR [rsi] mov DWORD PTR [rdi], eax jmp .L6
[Bug target/109435] overaligned structs are not passed correctly for mips64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109435 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=88469 --- Comment #2 from Andrew Pinski --- The aarch64 and arm backends had a similar issue which was fixed too.
[Bug c++/109433] [12/13 Regression] ICE with -std=c++11 and static constexpr array inside a template constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109433 --- Comment #2 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #1) > With -std=c++11, started to ICE with r12-6326-ge948436eab818c527dd6. > With -std=c++14, started to ICE with r9-1483-g307193b82cecb8ab79cf. Yes that is exactly the same where PR 109431 started to ICE too.
[Bug tree-optimization/109443] New: missed optimization of std::vector access (Related to issue 35269)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443 Bug ID: 109443 Summary: missed optimization of std::vector access (Related to issue 35269) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hiraditya at msn dot com Target Milestone: --- here is slightly modified code example from issue #35269. Both accesses are similar bug different code is generated. the function `h` has better codegen than `g` for some reason. $ g++ -O3 -std=c++20 -fno-exceptions void f(int); void g(std::vector v) { for (std::vector::size_type i = 0; i < v.size(); i++) f( v[ i ] ); } void h(std::vector v) { for (std::vector::const_iterator i = v.begin(); i != v.end(); ++i) f( *i ); } g(std::vector >): mov rdx, QWORD PTR [rdi] cmp QWORD PTR [rdi+8], rdx je .L6 pushrbp mov rbp, rdi pushrbx xor ebx, ebx sub rsp, 8 .L3: mov edi, DWORD PTR [rdx+rbx*4] add rbx, 1 callf(int) mov rdx, QWORD PTR [rbp+0] mov rax, QWORD PTR [rbp+8] sub rax, rdx sar rax, 2 cmp rbx, rax jb .L3 add rsp, 8 pop rbx pop rbp ret .L6: ret h(std::vector >): pushrbp pushrbx sub rsp, 8 mov rbx, QWORD PTR [rdi] cmp rbx, QWORD PTR [rdi+8] je .L10 mov rbp, rdi .L12: mov edi, DWORD PTR [rbx] add rbx, 4 callf(int) cmp QWORD PTR [rbp+8], rbx jne .L12 .L10: add rsp, 8 pop rbx pop rbp ret
[Bug tree-optimization/109443] missed optimization of std::vector access (Related to issue 35269)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443 --- Comment #1 from AK --- Link to issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35269 where I derived the testcase from.
[Bug tree-optimization/35269] missed optimization of std::vector access.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35269 AK changed: What|Removed |Added CC||hiraditya at msn dot com --- Comment #2 from AK --- I posted a revised version of this bug here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443
[Bug c++/109356] Enhancement idea to provide clearer missing brace line number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109356 --- Comment #5 from Jonny Grant --- I see it is more complicated than I imagined. Thank you for looking into it.
[Bug sanitizer/109444] New: Possible array overflow without diagnosis in memcpy if called within a virtual method scenario
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109444 Bug ID: 109444 Summary: Possible array overflow without diagnosis in memcpy if called within a virtual method scenario Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: mohamed.selim at dxc 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: --- It's possible to overflow the destination array size in std::memcpy, this behavior doesn't trigger the expected sanitizer diagnosis when using memcpy in a virtual method scenario (scenario 1). While in (scenario 2) when the std::memcpy is called from a normal method, the overflow is diagnosed as expected. #include #include #include // zero terminated 8 characters string literal const char txt[] = "1234567"; class Bar { public: constexpr Bar() : dst{} { } std::int8_t dst[6]; }; void test(Bar& b) { std::cout << "staring memcpy.\n"; std::cout << "size of bytes to be copied: " << sizeof(txt) <<"\n"; std::cout << "dst array size: " << sizeof(b.dst) << "\n"; std::memcpy(b.dst, txt, sizeof(txt)); } class Base { public: virtual ~Base() = default; virtual void func() = 0; }; // 1 - Foo inherits Base, virtual method implementation class Foo: public Base { public: void func() override { test(b); } private: Bar b{}; }; // 2 - no inheritance class Foo2 { public: void func() { test(b); } private: Bar b{}; }; //-std=c++14 -fsanitize=address -fsanitize=undefined -static-libasan -static-libubsan int main() { Foo c{}; // scenario 1, no sanitizer diagnosis //Foo2 c{}; // scenario 2, triggers sanitizer diagnosis c.func(); return 0; }
[Bug sanitizer/109444] Possible array overflow without diagnosis in memcpy if called within a virtual method scenario
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109444 --- Comment #1 from Andrew Pinski --- There is padding bytes for Foo because the alignment of Foo needs to be the same alignment as a pointer.
[Bug libstdc++/109445] New: r13-6372-g822a11a1e642e0 regression due to noline with -Ofast -march=sapphirerapids -funroll-loops -flto, 541.leela_r performance decrease by 2-3%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109445 Bug ID: 109445 Summary: r13-6372-g822a11a1e642e0 regression due to noline with -Ofast -march=sapphirerapids -funroll-loops -flto, 541.leela_r performance decrease by 2-3% Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: zhangjungcc at gmail dot com Target Milestone: --- r13-6372-g822a11a1e642e0 regression due to noline with -Ofast -march=sapphirerapids -funroll-loops -flto, 541.leela_r performance decrease by 2-3% Follow is the inline dump, left dump is before the commit, right dump is after the commit. [local count: 210861628]:[local count: 210861628]: # DEBUG BEGIN_STMT # DEBUG BEGIN_STMT _466 = s_rng;_466 = s_rng; -- _607 = _466;<> _561 = _466; _118 = _607; _118 = _561; -- _35 = this_72(D)->board.D.5191.m_empty_cnt; =_35 = this_72(D)->board.D.5191.m_empty_cnt; _5 = _35 & 65535;_5 = _35 & 65535; # DEBUG this => _118 # DEBUG this => _118 max_458 = (const uint16) _5; max_458 = (const uint16) _5; # DEBUG max => max_458 # DEBUG max => max_458 # DEBUG BEGIN_STMT # DEBUG BEGIN_STMT -- # DEBUG this => _118<> # DEBUG BEGIN_STMT # DEBUG mask => 4294967295 # DEBUG BEGIN_STMT # DEBUG BEGIN_STMT _467 = _118->s1; _468 = _467 << 13; _469 = _467 ^ _468; b_470 = _469 >> 19; # DEBUG b => b_470 # DEBUG BEGIN_STMT _471 = _467 << 12; _472 = _471 & 4294959104; _473 = b_470 ^ _472; _118->s1 = _473; # DEBUG BEGIN_STMT _474 = _118->s2; _475 = _474 << 2; _476 = _474 ^ _475; b_477 = _476 >> 25; # DEBUG b => b_477 # DEBUG BEGIN_STMT _478 = _474 << 4; _479 = _478 & 4294967168; _480 = b_477 ^ _479; _118->s2 = _480; # DEBUG BEGIN_STMT _481 = _118->s3; _482 = _481 << 3; _483 = _481 ^ _482; b_484 = _483 >> 11; # DEBUG b => b_484 # DEBUG BEGIN_STMT _485 = _481 << 17; _486 = _485 & 4292870144; _487 = b_484 ^ _486; _118->s3 = _487; # DEBUG BEGIN_STMT _488 = _473 ^ _480; _489 = _487 ^ _488; _611 = _489; _459 = random (_118); # DEBUG this => NULL # DEBUG b => NULL _459 = _611; -- _460 = _459 >> 16; =_460 = _459 >> 16; _461 = (unsigned int) max_458; _461 = (unsigned int) max_458; _462 = _460 * _461; _462 = _460 * _461; _463 = _462 >> 16; _463 = _462 >> 16; -- _612 = _463;<> _563 = _463; -- # DEBUG this => NULL=# DEBUG this => NULL # DEBUG max => NULL # DEBUG max => NULL -- _120 = _612;<> _120 = _563; -- vidx_121 = (int) _120; =vidx_121 = (int) _120; # DEBUG vidx => vidx_121 # DEBUG vidx => vidx_121 # DEBUG BEGIN_STMT # DEBUG BEGIN_STMT _37 = this_72(D)->board.D.5191.m_tomove; _37 = this_72(D)->board.D.5191.m_tomove; -- # DEBUG D#1845 => 1 <> # DEBUG D#1824 => 1 -- # DEBUG this => this_72(D) =# DEBUG this => this_72(D) # DEBUG color => _37 # DEBUG color => _37 # DEBUG vidx => vidx_121 # DEBUG vidx => vidx_121 # DEBUG allow_sa => 1# DEBUG allow_sa => 1 # DEBUG BEGIN_STMT # DEBUG BEGIN_STMT -- _495
[Bug ipa/109445] r13-6372-g822a11a1e642e0 regression due to noline with -Ofast -march=sapphirerapids -funroll-loops -flto, 541.leela_r performance decrease by 2-3%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109445 Andrew Pinski changed: What|Removed |Added Component|libstdc++ |ipa CC||marxin at gcc dot gnu.org --- Comment #1 from Andrew Pinski --- This just seems like bad luck. Maybe look at the inline dumps see what the cost difference is.
[Bug tree-optimization/109443] missed optimization of std::vector access (Related to issue 35269)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Xi Ruoyao --- Does not Richard's response still apply here? > Sorry, but the vector v is potentially clobbered by the call to f, so the load > of the array pointer you index into with i is not loop invariant.
[Bug tree-optimization/109443] missed optimization of std::vector access (Related to issue 35269)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443 Xi Ruoyao changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #3 from Xi Ruoyao --- (In reply to Xi Ruoyao from comment #2) > Does not Richard's response still apply here? > > > Sorry, but the vector v is potentially clobbered by the call to f, so the > > load > > of the array pointer you index into with i is not loop invariant. Alright it does not apply. I was blind...
[Bug tree-optimization/109443] missed optimization of std::vector access (Related to issue 35269)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443 --- Comment #4 from Andrew Pinski --- (In reply to Xi Ruoyao from comment #2) > Does not Richard's response still apply here? > > > Sorry, but the vector v is potentially clobbered by the call to f, so the > > load > > of the array pointer you index into with i is not loop invariant. Yes and no the v here is local and is only represented as a reference in the ir.
[Bug tree-optimization/109443] missed optimization of std::vector access (Related to issue 35269)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443 Andrew Pinski changed: What|Removed |Added Keywords||alias, missed-optimization --- Comment #5 from Andrew Pinski --- Though I think there might be a few dups of this same aliasing issue now.