[Bug tree-optimization/105740] missed optimization switch transformation for conditions with duplicate conditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105740 --- Comment #12 from Bernd Buschinski --- Hi, according to godbolt (gcc trunk) this is still present. is there anything I can do to help here?
[Bug ipa/110334] [13/14 Regresssion] unused functions not eliminated before LTO streaming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334 --- Comment #10 from rguenther at suse dot de --- On Fri, 23 Jun 2023, hubicka at ucw dot cz wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110334 > > --- Comment #8 from Jan Hubicka --- > > > I was playing with the idea of warning when at lto time when comdats have > > > different command line options, but this triggers way too often in > > > practice. > > > > Really? :/ > Yep, for example firefox consist of many extra libraries (skia, video > codecs, image format decoders...) each developed independently LTOed > into one libxul. Each of them has its own configure that tampers with > command line options. > These brings in libstdc++ comdats with different command line > sets (over 100 of different command lines for std::vector). > > Firefox is bit extreme, but it is common for other bigger projects, too. > > > > I think it would be desirable to diagnose these, maybe with an option to > > selectively disable this specific diagnostic. Because while it is not > > always a correctness issue it can be a performance issue as well. > > I can dig out the patch then. But it was simply printing something like > warning: merging comdat function with function of same name but > different flags > note: first difference is -f. > which was produced similar way we do diffs for optimization and target > attributes. > > Now those -f were usually quite misleading as they tended to be > internal flags implied by something else (such as -Ofast instead of > -O2). Often the picked -f flag was obviously harmless and false > positive, however other -f flag might have been important. > > So I concluded that it is not very easy information to interpret from user > perspective. > > But indeed I agree htat this is not very obvious source of interesting > correctness & performance issues. Hmm, maybe we should then really go the semantic alias route for QOI reasons? We can then still diagnose "preserving comdat symbol because of different flags in TU X vs. Y" and maybe we can also estimate a total unit growth because of doing that? > > > > Beware of new always-inline calls then appearing after greedy inlining > > (though that's exactly the case that we try to avoid here). I suppose > > you could disable inlining of a function which contains always-inline > > calls or simply functions that did not yet have the early inliner run > > on them (so keep the current behavior in cycles). Beware of indirect > > always-inline calls then. > > > > Btw, for Skia the issue is really that some auto-generated CTOR isn't > > marked always-inline but everything else is. Maybe they should use > > flatten instead of always-inline ... > > We disable inlining to always_inline during early inline, but not greedy > inline. Both of them can turn indirect calls to direct calls. So I was > thinking that as first cut we can inline only callees with no indirect > calls and no inlinable direct calls into always_inlines with no indirect > calls. > > Are you worried about possibility of early opt inventing new call into > builtin function that is defined as always_inline? No, just that we end up with a always-inline cycle (aka recursion) which we used to time/memory bomb on. That is, sth like the following has a "valid" inline solution (valid aka all always-inline calls are inlined), but only if we break the cycle at the 'forward' call. We used to mishandle this when unlucky with ordering (depending on which edge we enter the cycle when ordering for early opts). static void forward (void); static inline void __attribute__((always_inline)) always() { forward (); } static void forward (void) { always (); }; void entry1 () { forward1 (); } void entry2 () { always (); } now you can make this less obvious a cycle via indirect calls, maybe not without taking the address of always-inline functions which would be on the border of being a user error. Richard.
[Bug tree-optimization/110223] Missed optimization vectorizing booleans comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110223 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-06-26 Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug middle-end/85563] [10/11/12/13/14 regression] -Wmaybe-uninitialized false alarm regression with __builtin_unreachable and GCC 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85563 --- Comment #25 from Andrew Pinski --- (In reply to Richard Biener from comment #23) > > So somewhat of a pass ordering issue. The next CSE is DOM and then PRE. I was going to say this is related to PR 110405 but pointers don't record ranges (nor nonzerobits) but have a different kind of flow senative information.
[Bug target/110407] [12/13/14 Regression] Overaligned struct return depending on different versions of GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110407 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.4
[Bug target/110407] [12/13/14 Regression] Overaligned struct return depending on different versions of GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110407 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=102027 --- Comment #1 from Andrew Pinski --- This is similar to PR 102027 even.
[Bug target/110406] d: Wrong code-gen returning POD structs by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406 --- Comment #7 from Andrew Pinski --- (In reply to Andrew Pinski from comment #6) > Which itself is GCC 12+ regression too ... I filed that as PR 110407, let's see what the x86 backend folks say ...
[Bug target/110407] New: [12/13/14 Regression] Overaligned struct return depending on different versions of GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110407 Bug ID: 110407 Summary: [12/13/14 Regression] Overaligned struct return depending on different versions of GCC Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ABI Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Target: x86_64-linux-gnu Take: ``` typedef unsigned uint; struct cpuid_abcd_t { uint eax; uint ebx; uint ecx; uint edx; } __attribute__((aligned(8*4))); struct cpuid_abcd_t cpuid_insn(const uint in_eax) { struct cpuid_abcd_t ret={}; asm ( "cpuid" : "=a" ( ret.eax ), "=b" ( ret.ebx ), "=c" ( ret.ecx ), "=d" ( ret.edx ) : "a" ( in_eax ) ); return ret; } ``` GCC 12+ returns this in the vector register. While before it was returned via a pointer that was in rdi .
[Bug target/110406] d: Wrong code-gen returning POD structs by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406 Andrew Pinski changed: What|Removed |Added Keywords||ABI --- Comment #6 from Andrew Pinski --- (In reply to Andrew Pinski from comment #5) > (In reply to ibuclaw from comment #3) > > (In reply to Andrew Pinski from comment #2) > > > >structs have been set the wrong mode > > > > > > No, they don't have wrong mode, just the x86_64 backend is broken, see bug > > > 102027 comment #7 specifically. > > I think they do. > > > > On 64-bit, I expect the mode set by compute_record_mode to be TImode. > > However what I'm instead seeing is BLKmode. This tells me I might be calling > > it too early, and some fields yet to have their DECL_SIZE set. > > Unless the struct has the alignment of TImode, it should be BLKmode ... here is a C testcase to get it returned into vector register (incorrectly due to the alignment being set to 32): ``` typedef unsigned uint; struct cpuid_abcd_t { uint eax; uint ebx; uint ecx; uint edx; } __attribute__((aligned(8*4))); struct cpuid_abcd_t cpuid_insn(const uint in_eax) { struct cpuid_abcd_t ret={}; asm ( "cpuid" : "=a" ( ret.eax ), "=b" ( ret.ebx ), "=c" ( ret.ecx ), "=d" ( ret.edx ) : "a" ( in_eax ) : ); return ret; } ``` Which itself is GCC 12+ regression too ...
[Bug target/110406] d: Wrong code-gen returning POD structs by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406 --- Comment #5 from Andrew Pinski --- (In reply to ibuclaw from comment #3) > (In reply to Andrew Pinski from comment #2) > > >structs have been set the wrong mode > > > > No, they don't have wrong mode, just the x86_64 backend is broken, see bug > > 102027 comment #7 specifically. > I think they do. > > On 64-bit, I expect the mode set by compute_record_mode to be TImode. > However what I'm instead seeing is BLKmode. This tells me I might be calling > it too early, and some fields yet to have their DECL_SIZE set. Unless the struct has the alignment of TImode, it should be BLKmode ...
[Bug target/110406] d: Wrong code-gen returning POD structs by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406 --- Comment #4 from ibuclaw at gcc dot gnu.org --- It would be good if TYPE_MODE no longer had such a strong influence though. In the meantime, I ought to restore behaviour to how it was in 12.x
[Bug target/110406] d: Wrong code-gen returning POD structs by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406 --- Comment #3 from ibuclaw at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #2) > >structs have been set the wrong mode > > No, they don't have wrong mode, just the x86_64 backend is broken, see bug > 102027 comment #7 specifically. I think they do. On 64-bit, I expect the mode set by compute_record_mode to be TImode. However what I'm instead seeing is BLKmode. This tells me I might be calling it too early, and some fields yet to have their DECL_SIZE set.
[Bug target/110406] d: Wrong code-gen returning POD structs by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406 --- Comment #2 from Andrew Pinski --- >structs have been set the wrong mode No, they don't have wrong mode, just the x86_64 backend is broken, see bug 102027 comment #7 specifically.
[Bug d/110406] d: Wrong code-gen returning POD structs by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406 --- Comment #1 from Andrew Pinski --- Techincally the type mode should not be used by the backend to decide how a struct is returned or not.
[Bug d/110406] New: d: Wrong code-gen returning POD structs by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110406 Bug ID: 110406 Summary: d: Wrong code-gen returning POD structs by value Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ibuclaw at gcc dot gnu.org Target Milestone: --- Since 13.1 (r13-1104?), structs have been set the wrong mode, causing them to return differently to equivalent static arrays. --- struct cpuid_abcd_t { uint eax; uint ebx; uint ecx; uint edx; }; cpuid_abcd_t cpuid_insn(const uint in_eax) { cpuid_abcd_t ret = void; asm { "cpuid" : "=a" ( ret.eax ), "=b" ( ret.ebx ), "=c" ( ret.ecx ), "=d" ( ret.edx ) : "a" ( in_eax ) : ;} return ret; } uint[4] cpuid_insn2(const uint in_eax) { uint[4] ret = void; asm { "cpuid" : "=a" ( ret[0] ), "=b" ( ret[1] ), "=c" ( ret[2] ), "=d" ( ret[3] ) : "a" ( in_eax ) : ;} return ret; } --- The first function erroneously being returned in vector registers. _15 = {ret$eax_3, ret$ebx_4, ret$ecx_5, ret$edx_6}; MEM [(void *)&D.1894] = _15; return D.1894;
[Bug d/110359] d: Suboptimal codegen for __builtin_expect(cond, false) since PR96435
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110359 ibuclaw at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #6 from ibuclaw at gcc dot gnu.org --- Fix committed.
[Bug d/110359] d: Suboptimal codegen for __builtin_expect(cond, false) since PR96435
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110359 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:ab134ecb05c6cf1d7a0aee58e7649a93a87c9874 commit r10-11475-gab134ecb05c6cf1d7a0aee58e7649a93a87c9874 Author: Iain Buclaw Date: Mon Jun 26 03:24:27 2023 +0200 d: Suboptimal codegen for __builtin_expect(cond, false) Since PR96435, both boolean objects and expressions have been evaluated in the following way. (*(ubyte*)&obj_or_expr) & 1 It has been noted that sometimes this can cause the back-end to optimize in non-obvious ways - in particular with __builtin_expect. This @safe feature is now restricted to just when reading the value of a bool field that comes from a union. PR d/110359 gcc/d/ChangeLog: * d-convert.cc (convert_for_rvalue): Only apply the @safe boolean conversion to boolean fields of a union. (convert_for_condition): Call convert_for_rvalue in the default case. gcc/testsuite/ChangeLog: * gdc.dg/pr110359.d: New test. (cherry picked from commit ab98db1e8c1b997414539f41b7fb814019497d8d)
[Bug d/110359] d: Suboptimal codegen for __builtin_expect(cond, false) since PR96435
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110359 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:a0c4bd656e0fce16d62877e0eb53ac11b1924d0c commit r11-10875-ga0c4bd656e0fce16d62877e0eb53ac11b1924d0c Author: Iain Buclaw Date: Mon Jun 26 03:24:27 2023 +0200 d: Suboptimal codegen for __builtin_expect(cond, false) Since PR96435, both boolean objects and expressions have been evaluated in the following way. (*(ubyte*)&obj_or_expr) & 1 It has been noted that sometimes this can cause the back-end to optimize in non-obvious ways - in particular with __builtin_expect. This @safe feature is now restricted to just when reading the value of a bool field that comes from a union. PR d/110359 gcc/d/ChangeLog: * d-convert.cc (convert_for_rvalue): Only apply the @safe boolean conversion to boolean fields of a union. (convert_for_condition): Call convert_for_rvalue in the default case. gcc/testsuite/ChangeLog: * gdc.dg/pr110359.d: New test. (cherry picked from commit ab98db1e8c1b997414539f41b7fb814019497d8d)
[Bug d/110359] d: Suboptimal codegen for __builtin_expect(cond, false) since PR96435
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110359 --- Comment #3 from CVS Commits --- The releases/gcc-12 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:0f54a73b998b72f7c8452a63730ec3b16fc47854 commit r12-9730-g0f54a73b998b72f7c8452a63730ec3b16fc47854 Author: Iain Buclaw Date: Mon Jun 26 03:24:27 2023 +0200 d: Suboptimal codegen for __builtin_expect(cond, false) Since PR96435, both boolean objects and expressions have been evaluated in the following way. (*(ubyte*)&obj_or_expr) & 1 It has been noted that sometimes this can cause the back-end to optimize in non-obvious ways - in particular with __builtin_expect. This @safe feature is now restricted to just when reading the value of a bool field that comes from a union. PR d/110359 gcc/d/ChangeLog: * d-convert.cc (convert_for_rvalue): Only apply the @safe boolean conversion to boolean fields of a union. (convert_for_condition): Call convert_for_rvalue in the default case. gcc/testsuite/ChangeLog: * gdc.dg/pr110359.d: New test. (cherry picked from commit ab98db1e8c1b997414539f41b7fb814019497d8d)
[Bug d/110359] d: Suboptimal codegen for __builtin_expect(cond, false) since PR96435
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110359 --- Comment #2 from CVS Commits --- The releases/gcc-13 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:9599da719abe4e990fb9cb7ad9d1abc19a5f0429 commit r13-7479-g9599da719abe4e990fb9cb7ad9d1abc19a5f0429 Author: Iain Buclaw Date: Mon Jun 26 03:24:27 2023 +0200 d: Suboptimal codegen for __builtin_expect(cond, false) Since PR96435, both boolean objects and expressions have been evaluated in the following way. (*(ubyte*)&obj_or_expr) & 1 It has been noted that sometimes this can cause the back-end to optimize in non-obvious ways - in particular with __builtin_expect. This @safe feature is now restricted to just when reading the value of a bool field that comes from a union. PR d/110359 gcc/d/ChangeLog: * d-convert.cc (convert_for_rvalue): Only apply the @safe boolean conversion to boolean fields of a union. (convert_for_condition): Call convert_for_rvalue in the default case. gcc/testsuite/ChangeLog: * gdc.dg/pr110359.d: New test. (cherry picked from commit ab98db1e8c1b997414539f41b7fb814019497d8d)
[Bug d/110359] d: Suboptimal codegen for __builtin_expect(cond, false) since PR96435
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110359 --- Comment #1 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:ab98db1e8c1b997414539f41b7fb814019497d8d commit r14-2082-gab98db1e8c1b997414539f41b7fb814019497d8d Author: Iain Buclaw Date: Mon Jun 26 03:24:27 2023 +0200 d: Suboptimal codegen for __builtin_expect(cond, false) Since PR96435, both boolean objects and expressions have been evaluated in the following way. (*(ubyte*)&obj_or_expr) & 1 It has been noted that sometimes this can cause the back-end to optimize in non-obvious ways - in particular with __builtin_expect. This @safe feature is now restricted to just when reading the value of a bool field that comes from a union. PR d/110359 gcc/d/ChangeLog: * d-convert.cc (convert_for_rvalue): Only apply the @safe boolean conversion to boolean fields of a union. (convert_for_condition): Call convert_for_rvalue in the default case. gcc/testsuite/ChangeLog: * gdc.dg/pr110359.d: New test.
[Bug d/110113] gdc -fpreview=dip1021 crash in d/dmd/root/aav.d:127 dmd_aaGetRvalue from DsymbolTable::lookup(Identifier const*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110113 ibuclaw at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from ibuclaw at gcc dot gnu.org --- Fix committed to releases/gcc-13, and backported to gcc-12. It will hit mainline on the next merge with upstream dmd.
[Bug d/110113] gdc -fpreview=dip1021 crash in d/dmd/root/aav.d:127 dmd_aaGetRvalue from DsymbolTable::lookup(Identifier const*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110113 --- Comment #12 from CVS Commits --- The releases/gcc-12 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:016047f54713dc601c661ab57c78a26da3759608 commit r12-9729-g016047f54713dc601c661ab57c78a26da3759608 Author: Iain Buclaw Date: Mon Jun 26 02:29:46 2023 +0200 d: Fix crash in d/dmd/root/aav.d:127 dmd_aaGetRvalue from DsymbolTable::lookup Backports patch from upstream dmd mainline for fixing PR110113. The data being Mem.xrealloc'd contains many Array(T) fields, some of which have self references in their data.ptr field thanks to the smallarray optimization used by Array. Naturally then, the memcpy from old GC data to new retains those self referenced addresses, and the GC marks the old data as "free". Some time later GC.malloc will return a pointer to said "free" data. So now we have two GC references to the same memory. One that is treating the data as an Array(VarDeclaration) in dmd.escape.escapeByStorage, and the other as an AA in the symtab of a dmd.dsymbol.ScopeDsymbol. Fix this memory corruption by not storing the data in a global variable for reuse. If there are no more live references, the GC will free it. PR d/110113 gcc/d/ChangeLog: * dmd/escape.d (checkMutableArguments): Always allocate new buffer for computing escapeBy. gcc/testsuite/ChangeLog: * gdc.test/compilable/test23978.d: New test. Reviewed-on: https://github.com/dlang/dmd/pull/15302 (cherry picked from commit ae3a4cefd855512b10b833a56f275b701bacdb34)
[Bug d/110113] gdc -fpreview=dip1021 crash in d/dmd/root/aav.d:127 dmd_aaGetRvalue from DsymbolTable::lookup(Identifier const*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110113 --- Comment #11 from CVS Commits --- The releases/gcc-13 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:ae3a4cefd855512b10b833a56f275b701bacdb34 commit r13-7478-gae3a4cefd855512b10b833a56f275b701bacdb34 Author: Iain Buclaw Date: Mon Jun 26 02:29:46 2023 +0200 d: Fix crash in d/dmd/root/aav.d:127 dmd_aaGetRvalue from DsymbolTable::lookup Backports patch from upstream dmd mainline for fixing PR110113. The data being Mem.xrealloc'd contains many Array(T) fields, some of which have self references in their data.ptr field thanks to the smallarray optimization used by Array. Naturally then, the memcpy from old GC data to new retains those self referenced addresses, and the GC marks the old data as "free". Some time later GC.malloc will return a pointer to said "free" data. So now we have two GC references to the same memory. One that is treating the data as an Array(VarDeclaration) in dmd.escape.escapeByStorage, and the other as an AA in the symtab of a dmd.dsymbol.ScopeDsymbol. Fix this memory corruption by not storing the data in a global variable for reuse. If there are no more live references, the GC will free it. PR d/110113 gcc/d/ChangeLog: * dmd/escape.d (checkMutableArguments): Always allocate new buffer for computing escapeBy. gcc/testsuite/ChangeLog: * gdc.test/compilable/test23978.d: New test. Reviewed-on: https://github.com/dlang/dmd/pull/15302
[Bug c++/110403] dependent function constexpr inside vector_size __attribute__ does not compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110403 --- Comment #1 from Janez Zemva --- Here is a possible workaround: #define S__(x) ((x) | (x) >> 1 | (x) >> 2 | (x) >> 3 | (x) >> 4) #define BITCEIL(x) ((x) & (x) - 1 ? (S__(x) & ~(S__(x) >> 1)) << 1 : (x)) template using array_t __attribute__ ((vector_size(BITCEIL(N * sizeof(T) = T;
[Bug target/94617] Simple if condition not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94617 --- Comment #11 from Andrew Pinski --- Note funky_bandpass in GCC 13+ no longer produces an imull but rather does neg/and instead: movl%edx, %eax cmpl%edx, %edi setle %dl cmpl%esi, %eax setl%al andl%eax, %edx cmpb$1, %dl movzbl %dl, %edx sbbq%rax, %rax negq%rdx andq%rax, %rcx andq%rdx, %r8 leaq(%rcx,%r8), %rax
[Bug target/94617] Simple if condition not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94617 --- Comment #10 from Andrew Pinski --- For the first function (vanilla_bandpass), GCC 12+ produces now: movq%rcx, %rax cmpl%edx, %edi jg .L2 cmpl%esi, %edx cmovl %r8, %rax .L2: ret For the second the problem is: _3 = ~within_interval_11; # RANGE [irange] long unsigned int [0, 1] NONZERO 0x1 _4 = (long unsigned intD.16) _3; ... low_ptr_13 = _4 * low.0_5; # RANGE [irange] long unsigned int [0, 1] NONZERO 0x1 _6 = (long unsigned intD.16) within_interval_11; ... high_ptr_15 = _6 * high.1_7; ptr_sum_16 = low_ptr_13 + high_ptr_15; We should recongize that ptr_sum_16 is really just within_interval_11 ? high.1_7 : low.0_5; Match pattern for that: ``` (for op (plus bit_ior bit_xor) (simplify (op:c (mult:c (convert @0) @1) (mult:c (convert (bit_not @0)) @2)) (if (INTEGRAL_TYPE_P (TREE_TYPE (@0)) && TYPE_PRECISION (TREE_TYPE (@0)) == 1 && TYPE_UNSIGNED (TREE_TYPE (@0))) (cond @0 @1 @2)) ```
[Bug middle-end/89921] The jump threading increases the size a lot when having an huge inline-asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89921 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2019-04-03 00:00:00 |2023-6-25 --- Comment #4 from Andrew Pinski --- Note the inline-asm is removed in recent versions of GCC because the result is not used. To fix that do: s/return 0;/return o;/ The duplicate still happens on the trunk with the above change to the sources.
[Bug tree-optimization/84470] test for address of member being null not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84470 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |9.0 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Andrew Pinski --- The non-first element is fixed in GCC 9. The first element case is not optmized on purpose. So we can close this as fixed.
[Bug middle-end/21474] missed optimizations when comparing address to NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21474 Andrew Pinski changed: What|Removed |Added Known to work||10.1.0, 9.1.0 Status|NEW |RESOLVED Target Milestone|--- |9.0 Resolution|--- |FIXED Known to fail||8.5.0 --- Comment #4 from Andrew Pinski --- >&p->b[3] was fixed in GCC 9+ (by r9-4666 or something earlier than that) The other 2 were fixed before GCC 4.1.2.
[Bug middle-end/110148] [14 Regression] TSVC s242 regression between g:c0df96b3cda5738afbba3a65bb054183c5cd5530 and g:e4c986fde56a6248f8fbe6cf0704e1da34b055d8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110148 --- Comment #4 from Jan Hubicka --- zen3 fma requires all inputs to be ready to start execution, separate multiply+add can start multiplication earlier. Not sure if that explains the difference.
[Bug target/87104] missed &, == optimization makes Emacs ~0.4% slower on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87104 --- Comment #15 from Andrew Pinski --- Note in the original testcase, I noticed we don't do some "VRP/nonzero bits" optimization so I filed PR 110405 for that. It does not change the other transformation.
[Bug tree-optimization/110405] missing nonzerobits on branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110405 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=87104 --- Comment #1 from Andrew Pinski --- I forgot to mention I found this while looking into PR 87104 ...
[Bug tree-optimization/110405] New: missing nonzerobits on branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110405 Bug ID: 110405 Summary: missing nonzerobits on branch Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Take: ``` void h(unsigned long); void f (unsigned long i) { if ((i & 7) == 6) if(i & 1) h(0); } ``` The call to h should be optimized away as we know on the branch (a&1) == 0 as we know the nonzerobits of i is ~1 .
[Bug fortran/110360] ABI issue with character,value dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360 --- Comment #14 from anlauf at gcc dot gnu.org --- After r14-2064, gcc-testresults shows the following for big-endian Power platforms: Running target unix/-m32 FAIL: gfortran.dg/value_9.f90 -O0 execution test FAIL: gfortran.dg/value_9.f90 -O1 execution test FAIL: gfortran.dg/value_9.f90 -O2 execution test FAIL: gfortran.dg/value_9.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/value_9.f90 -O3 -g execution test FAIL: gfortran.dg/value_9.f90 -Os execution test No failure for Running target unix/-m64 Let's hope that somebody with access to such a system can run the testcase manually and append the output to this PR.
[Bug c++/110404] Feature request: add a new option which is like -ftrivial-auto-var-init=zero but zero-initialize instead of zero-fill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110404 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Summary|Feature request: make |Feature request: add a new |-ftrivial-auto-var-init=zer |option which is like |o zero-initialize, not |-ftrivial-auto-var-init=zer |zero-fill |o but zero-initialize ||instead of zero-fill
[Bug middle-end/110375] -ftrivial-auto-var-init=zero issues with pointers to data members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110375 --- Comment #5 from Giuseppe D'Angelo --- Done in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110404 .
[Bug c++/110404] New: Feature request: make -ftrivial-auto-var-init=zero zero-initialize, not zero-fill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110404 Bug ID: 110404 Summary: Feature request: make -ftrivial-auto-var-init=zero zero-initialize, not zero-fill Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dangelog at gmail dot com Target Milestone: --- Hello, This is the same report as bug 110375, however turned into a wishlist/feature request for the C++ front-end. Right now -ftrivial-auto-var-init=zero is a middle-end feature that zero-fills storage for automatic variables. 0x00 is a bit pattern that works _almost_ universally to set a "safe" default. However, pointers to data members are a problem: on Itanium, a null pointer to data member is represented by -1u, and not 0. https://itanium-cxx-abi.github.io/cxx-abi/abi.html#data-member-pointers This means that this snippet hits the assert under -ftrivial-auto-var-init=zero: #include struct S {}; int main() { int S::*ptr; assert(ptr == nullptr); } https://gcc.godbolt.org/z/7sb6GcbPE IMHO it would be more useful to have -ftrivial-auto-var-init=zero to mean "to _value-initialize_ automatic variables" (and zero-fill padding bits), including non-static data members of classes, recursively, before a constructor is eventually run. Such value-initialization for scalar types resolves into zero-initialization (and *not* zero-filling), as per https://eel.is/c++draft/dcl.init#general-9.3 , so the name "=zero" is still somehow appropriate. The difference is that zero-initialization will correctly sets *all* pointers types to null. -- Regarding whether one should change -ftrivial-auto-var-init=zero semantics or introduce a new command line option, I'd rather change the semantics. The fact that it's currently a middle-end feature is not interesting at all for the end-user. In their mind, what they want is zero-initialization, not zero-filling (aka any sort of pointer is nullptr, any arithmetic is 0, etc; irregardless of ABI). For the C front-end, this shouldn't mean any change (unless GCC runs on some C ABI where pointers or floating pointes aren't all 0-bits?). For the C++ front-end, this means fixing pointers to data members Itanium. -- References: * https://github.com/llvm/llvm-project/issues/63471 twin bug report * https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2723r1.html that aims to zero-initialize variables with automatic storage, but erronousely say that GCC and Clang already implement this feature.
[Bug rtl-optimization/110307] ICE in move_insn, at haifa-sched.cc:5473 when building Ruby on alpha with -fPIC -O2 (or -fpeephole2 -fschedule-insns2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110307 --- Comment #13 from Alexander Monakov --- Note to self: check how control_flow_insn_p relates.
[Bug rtl-optimization/110307] ICE in move_insn, at haifa-sched.cc:5473 when building Ruby on alpha with -fPIC -O2 (or -fpeephole2 -fschedule-insns2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110307 --- Comment #12 from matoro --- Just tested applying this patch on top of 13 and it worked! Thanks so much for the help!
[Bug tree-optimization/110396] Compile-time hog with -O2 and -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110396 --- Comment #3 from luydorarko at vusra dot com --- (In reply to Andrew Pinski from comment #2) > This is basically a dup of bug 102253. The problem is there is a known > scalability issues with large loop depth. > > How did you generate this testcase, is it from real code or just generated > to try to hit some compile bugs? > > *** This bug has been marked as a duplicate of bug 102253 *** This is to solve a combinatorics problem: count all 8x8 matrices whose rows and columns add up to 6. You can see the variable names refer to row and column indices. The tedious loops in the C++ code were all generated by a Python script. It is part of a bigger exploration for different orders and different row sums / column sums. A similar code for smaller row-sums and column-sums compiled and ran quickly, and all smaller orders run quickly. This was the smallest problem instance that exposed the time run.
[Bug c/110402] Bogus -Waddress warning that pointer comparison is always true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110402 --- Comment #4 from lsof at mailbox dot org --- I retract my previous comment about `&v[key] != 0` being possibly false, since in C it is undefined behavior to perform pointer arithmetic on the null pointer even with an addend of zero. But I still think that it shouldn't occur in the context of a subexpression like the one in the testcase.
[Bug c/110402] Bogus -Waddress warning that pointer comparison is always true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110402 --- Comment #3 from lsof at mailbox dot org --- (In reply to Andrew Pinski from comment #2) > We warn about: > ``` > struct m { float *v; int t; }; > > _Bool chk1(struct m *m, int key) { > return &m->v[key]; > } > ``` > ``` > : In function 'chk1': > :4:5: warning: the comparison will always evaluate as 'true' for the > pointer operand in 'm->v + (sizetype)((long unsigned int)key * 4)' must not > be NULL [-Waddress] > 4 | return &m->v[key]; > | ^~ > ``` > > The reason why the others in your testcase is not being warned about is more > about the shape of the ?: and/or the comma operator getting in the way of > moving the implict `!=0` into the `?:`. I understand why it warns about `&m->v[key] != 0`; but when contained in a larger expression like ```(key < 0 ? 0 : &m->v[key]) (!= 0)``` I don't think the warning is useful. (In reply to Andreas Schwab from comment #1) > The error message does not match anything from the test case. Now that I think about it, you're right; if `m->v` is null and `key` is 0, `&m->v[key] != 0` can definitely evaluate to false. So I don't know why GCC is emitting the warning here in the first place. Even the backend disagrees with the frontend, because if it were true that `&m->v[key] != 0` always evaluates as true as the diagnostic says, the optimizer would elide the check, but it does not.
[Bug ada/110314] Gnat failed assertion and Allocators with discriminant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110314 --- Comment #5 from Franck Behaghel --- Marc, Could you consider and review this patch ? Regards,
[Bug ada/110314] Gnat failed assertion and Allocators with discriminant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110314 --- Comment #4 from Franck Behaghel --- Created attachment 55399 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55399&action=edit patch
[Bug rtl-optimization/110400] Reuse vector register for both scalar and vector value.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110400 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-06-25 Ever confirmed|0 |1 Component|target |rtl-optimization Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- Confirmed. a "CSE" should happen ...
[Bug target/98453] aarch64: Missed opportunity for STP for vec_duplicate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98453 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Resolution|--- |FIXED Status|NEW |RESOLVED Known to fail||12.1.0 --- Comment #2 from Andrew Pinski --- Fixed for GCC 14 by r14-215-g85279b0bddc1c5a7d181e216 .
[Bug c++/110401] [10/11/12/13/14 Regression] Unhelpful "goto is not a constant expression" in ill-formed pre c++20 constexpr function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110401 Andrew Pinski changed: What|Removed |Added Summary|Unhelpful "goto is not a|[10/11/12/13/14 Regression] |constant expression" in |Unhelpful "goto is not a |ill-formed pre c++20|constant expression" in |constexpr function template |ill-formed pre c++20 ||constexpr function template Last reconfirmed||2023-06-25 Target Milestone|--- |10.5 Status|UNCONFIRMED |NEW Known to fail||7.3.0 Known to work||7.1.0, 7.2.0 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Compiling it with -std=c++11 is even worse as it does not show the reason: ``` :12:36: error: 'constexpr std::array get_sqr() [with int N = 1]' called in a constant expression 12 | constexpr auto sqr = get_sqr<1>(); | ~~^~ :4:30: note: 'constexpr std::array get_sqr() [with int N = 1]' is not usable as a 'constexpr' function because: 4 | constexpr std::array get_sqr() | ^~~ ``` GCC 7.1 and 7.2 used to have the correct explanation for C++11+: ``` : In instantiation of 'constexpr std::array get_sqr() [with int N = 1]': :12:37: required from here :6:24: error: uninitialized variable 'ret' in 'constexpr' function std::array ret; ^~~ In file included from :1:0: /opt/compiler-explorer/gcc-7.2.0/include/c++/7.2.0/array:94:12: note: 'struct std::array' has no user-provided default constructor struct array ^ /opt/compiler-explorer/gcc-7.2.0/include/c++/7.2.0/array:110:56: note: and the implicitly-defined constructor does not initialize 'int std::array::_M_elems [1]' typename _AT_Type::_Type _M_elems; ^~~~ :12:37: error: 'constexpr std::array get_sqr() [with int N = 1]' called in a constant expression constexpr auto sqr = get_sqr<1>(); ^ :4:30: note: 'constexpr std::array get_sqr() [with int N = 1]' is not usable as a constexpr function because: constexpr std::array get_sqr() ^~~ ``` GCC 7.3+ removed the "uninitialized variable 'ret' in 'constexpr' function". GCC 10+ then removed the 2 notes at the beginning. Note this is actually valid C++20 so maybe the change in GCC 10 is related to that ...
[Bug c/110402] Bogus -Waddress warning that pointer comparison is always true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110402 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic --- Comment #2 from Andrew Pinski --- We warn about: ``` struct m { float *v; int t; }; _Bool chk1(struct m *m, int key) { return &m->v[key]; } ``` ``` : In function 'chk1': :4:5: warning: the comparison will always evaluate as 'true' for the pointer operand in 'm->v + (sizetype)((long unsigned int)key * 4)' must not be NULL [-Waddress] 4 | return &m->v[key]; | ^~ ``` The reason why the others in your testcase is not being warned about is more about the shape of the ?: and/or the comma operator getting in the way of moving the implict `!=0` into the `?:`.
[Bug c++/110403] New: constant expression inside vector_size __attribute__ does not compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110403 Bug ID: 110403 Summary: constant expression inside vector_size __attribute__ does not compile Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: janezz55 at gmail dot com Target Milestone: --- trying to compile: template using array_t __attribute__ ((vector_size(std::bit_ceil(N * sizeof(T) = T; produces the following compile error: error: 'vector_size' attribute argument value 'std::bit_ceil((8 * sizeof (unsigned int)))' is not an integer constant but without bit_ceil(), the following error may result: error: number of vector components 3 not a power of two. IMO, this is a bug, since N * sizeof(T) compiles without issue, but a call to a constexpr function does not. I have prepared an example: https://wandbox.org/permlink/lGvFnhDCLJ05j1FM The idea is to use a SIMD register instead of an array on the stack for temporary storage.
[Bug middle-end/83172] -Wstack-size= doesn't detect the correct stack size with VLA or alloca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83172 Martin Uecker changed: What|Removed |Added CC||muecker at gwdg dot de --- Comment #5 from Martin Uecker --- I agree. It would nice to have a solution here, as it would make using VLAs safer. And the alternatives to VLAs people tend to use because they are scared are usually worse in terms of readability, performance, and bounds checking.
[Bug c/110402] Bogus -Waddress warning that pointer comparison is always true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110402 --- Comment #1 from Andreas Schwab --- The error message does not match anything from the test case.
[Bug c/110402] New: Bogus -Waddress warning that pointer comparison is always true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110402 Bug ID: 110402 Summary: Bogus -Waddress warning that pointer comparison is always true Product: gcc Version: 13.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: lsof at mailbox dot org Target Milestone: --- Created attachment 55398 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55398&action=edit testcase In the following testcase: struct m { float *v; int t; }; _Bool chk(struct m *m, int key) { return (m->t = key) < 0 ? 0 : &m->v[key]; } /* a comma expression can suppress it */ _Bool chk2(struct m *m, int key) { return (m->t = key, m->t < 0 ? 0 : &m->v[key]); } /* however, this does NOT warn */ _Bool chk3(struct m *m, int key) { return (m->t = key) < 0 ? &m->v[key] : &m->v[key]; } gcc -Waddress gives this warning: x.c: In function ‘chk’: x.c:4:5: warning: the comparison will always evaluate as ‘true’ for the pointer operand in ‘m->v + (sizetype)((long unsigned int)key * 4)’ must not be NULL [-Waddress] 4 | return key < 0 ? 0 : &m->v[key]; | ^~ In particular the second function does not produce the warning (correctly), but the third function for which the warning actually applies does not give a warning.
[Bug c++/110401] New: Unhelpful "goto is not a constant expression" in ill-formed constexpr function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110401 Bug ID: 110401 Summary: Unhelpful "goto is not a constant expression" in ill-formed constexpr function template Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: xry111 at gcc dot gnu.org Target Milestone: --- #include template constexpr std::array get_sqr() { std::array ret; for (int i = 0; i < N; i++) ret[i] = i * i; return ret; } constexpr auto sqr = get_sqr<1>(); GCC says "error: 'goto' is not a constant expression". This is puzzling because there is no "goto" in the function. Note that if it's not a template, GCC outputs the correct message: #include constexpr std::array get_sqr() { std::array ret; for (int i = 0; i < 1; i++) ret[i] = i * i; return ret; } constexpr auto sqr = get_sqr(); t.cc: In function 'constexpr std::array get_sqr()': t.cc:5:28: error: uninitialized variable 'ret' in 'constexpr' function 5 | std::array ret; |^~~