[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 *)] = _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*)_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*)_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*)_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*)_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*)_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 --- >>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 `[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 >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 >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 `>v[key] != 0`; but when contained in a
larger expression like ```(key < 0 ? 0 : >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,
`>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 `>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=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 >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 >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=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 : >v[key];
}
/* a comma expression can suppress it */
_Bool chk2(struct m *m, int key) {
return (m->t = key, m->t < 0 ? 0 : >v[key]);
}
/* however, this does NOT warn */
_Bool chk3(struct m *m, int key) {
return (m->t = key) < 0 ? >v[key] : >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 : >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;
|^~~
