[Bug middle-end/42588] unnecessary move through x87 stack/local frame for union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42588 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |4.9.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Andrew Pinski --- Fixed in 4.9.0+ Before: (insn 6 3 7 2 (set (subreg:DF (reg/v:DI 62 [ __u ]) 0) (reg/v:DF 64 [ __x ])) /app/example.c:15 -1 (nil)) After: (insn 6 3 7 2 (set (reg/v:DI 86 [ __u ]) (subreg:DI (reg/v:DF 88 [ __x ]) 0)) /app/example.c:15 -1 (nil)) Which means it was fixed by r0-126192.
[Bug rtl-optimization/34849] Missed autoincrement opportunities due to a different basic block structure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34849 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Known to fail|| Resolution|--- |FIXED Target Milestone|--- |11.0 --- Comment #13 from Andrew Pinski --- This was fixed on the gimple level by the following revisions: r7-1935 (pre of the res_11(D) + _7 part) r11-408 (common store sinking) Loop which we get now: .L4: ldr r0, [r1], #4 cmp r0, #0 ite eq moveq r3, r4 movne r3, lr cmp r1, ip str r3, [r2, #4]! bne .L4
[Bug target/9760] [arm] Combine cannot do its job because immediate operand is used instead of register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9760
--- Comment #10 from Andrew Pinski ---
Still happens on the trunk.
Note armv7-a produces reasonable code though as it uses ubfx which is new for
armv7-a:
push{r4, lr}
mov r4, r0
movsr0, #8
lsrsr1, r4, #24
bl func
ubfxr1, r4, #16, #8
movsr0, #8
bl func
ubfxr1, r4, #8, #8
movsr0, #8
pop {r4, lr}
b func
[Bug tree-optimization/43037] re-association doesn't handle multiple uses with constant operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43037 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |8.0 Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Fixed by r8-2178 .
[Bug middle-end/43182] GCC does not pull out a[0] from loop that changes a[i] for i:[1,n]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43182 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement --- Comment #7 from Andrew Pinski --- So even though we can vectorize this loop these days, the non-vectorized loop still has the load each iteration. at -O2: .L3: movl(%ecx), %edx addl$4, %eax movl%edx, -4(%eax) cmpl%ebx, %eax jne .L3
[Bug target/40783] inefficient code to accumulate function return values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40783 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=28481, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=27855 --- Comment #3 from Andrew Pinski --- 4.6 and above seems to be working.
[Bug rtl-optimization/43908] Redundant conditionals [4.5 only] - unnecessary mov of a constant after unrolling.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43908 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2010-04-28 10:10:19 |2021-7-26 Severity|normal |enhancement
[Bug middle-end/43233] x86 flags not combined across blocks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43233 Andrew Pinski changed: What|Removed |Added Host|x86_64-*-* |x86_64-*-*, aarch64 Component|target |middle-end --- Comment #2 from Andrew Pinski --- This also happens on aarch64 where we could use tbnz.
[Bug tree-optimization/44711] PRE doesn't remove equivalent computations of induction variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44711 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |7.0 Status|NEW |RESOLVED --- Comment #3 from Andrew Pinski --- Most likely fixed by r7-1935.
[Bug target/44278] Use ubfx to extract unsigned bit fields at the low end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44278 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |5.0 Status|NEW |RESOLVED --- Comment #1 from Andrew Pinski --- Fixed sometime between 4.6 and 5.0. The original support for ubfx was added with r0-86245 though which was in 2008 which means it was in 4.4 but I could not get either 4.5.4 or 4.6.4 to do the ubfx.
[Bug middle-end/35360] Static (base/offset/size rule) should be extended to handle array elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35360 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |4.9.0 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Andrew Pinski --- Both testcases are fixed in 4.9.0 by r0-122892 and there was a few testcases added that were similar to this bug report already.
[Bug middle-end/35358] Ansi aliasing info not fully utilized by tree SSA optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35358 Bug 35358 depends on bug 35360, which changed state. Bug 35360 Summary: Static (base/offset/size rule) should be extended to handle array elements https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35360 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/57] [DR 325] GCC can't parse a non-parenthesized comma in a template-id within a default argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57 --- Comment #48 from Jonathan Wakely --- No, as previously stated, it's suspended until the Core issue is resolved and the standard is changed. https://wg21.link/cwg325
[Bug c++/101622] Type erasure (upcasting) in constexpr/consteval context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101622 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-07-26 --- Comment #1 from Jonathan Wakely --- I think the code is valid.
[Bug target/46209] pmovmskb, useless sign extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46209 Andrew Pinski changed: What|Removed |Added Depends on||66369 Ever confirmed|0 |1 Last reconfirmed||2021-07-26 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- foo64: .LFB533: .cfi_startproc pmovmskb%xmm0, %eax movzbl %al, %eax ret The 128 one was fixed with PR 66369. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66369 [Bug 66369] gcc 4.8.3/5.1.0 miss optimisation with vpmovmskb
[Bug tree-optimization/46281] Inefficient unswitching (too many copies)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46281 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-07-26 --- Comment #1 from Andrew Pinski --- Note you need the uncommented part to hit the issue on the trunk So: if (j < k || j < l || j < m || j << 3 || k << 4)
[Bug middle-end/47673] Redundant NULL check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47673 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.0 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Andrew Pinski --- Fixed in GCC 11. I suspect r11-3685 but I am not 100%. It is definitely related to ranger improvements to VRP.
[Bug middle-end/78103] Failure to optimize with __builtin_clzl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78103
--- Comment #9 from Jakub Jelinek ---
Created attachment 51204
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51204&action=edit
gcc12-pr78103.patch
Untested partial fix.
The patch does 2 things, one is (shown on the first testcase) optimize sign or
zero extension of __builtin_clz{,l,ll} from 32-bits to 64-bit - no need to emit
sign extension instruction. The other change is to match 32-bit subtraction of
a constant and __builtin_clz, can be optimized into bsr and addition.
All this only with -mno-lzcnt, with -mlzcnt a very different insn is emitted
that handles it fine.
[Bug middle-end/78103] Failure to optimize with __builtin_clzl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78103
Jakub Jelinek changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comment #10 from Jakub Jelinek ---
Unfortunately, it doesn't work for the #c0 testcase, after the combiner
splitter kicks in, the combiner doesn't even try that 4 insn combination.
Haven't debugged it, but it looks like if LOG_LINKS isn't added between the 2
insns that replaced the 3 insns.
There is the successful:
Trying 9, 10 -> 12:
9: {flags:CCZ=cmp(r85:DI,0);r86:DI=0x3f-clz(r85:DI);}
REG_DEAD r85:DI
REG_UNUSED flags:CCZ
10: {r86:DI=r86:DI^0x3f;clobber flags:CC;}
REG_UNUSED flags:CC
12: r87:DI=sign_extend(r86:DI#0)
REG_DEAD r86:DI
Failed to match this instruction:
(set (reg:DI 87 [ _1 ])
(xor:DI (sign_extend:DI (minus:SI (const_int 63 [0x3f])
(subreg:SI (clz:DI (reg/v:DI 85 [ x ])) 0)))
(const_int 63 [0x3f])))
Splitting with gen_split_440 (i386.md:14804)
Successfully matched this instruction:
(set (reg:DI 93)
(minus:DI (const_int 63 [0x3f])
(clz:DI (reg/v:DI 85 [ x ]
Successfully matched this instruction:
(set (reg:DI 87 [ _1 ])
(zero_extend:DI (xor:SI (subreg:SI (reg:DI 93) 0)
(const_int 63 [0x3f]
allowing combination of insns 9, 10 and 12
original costs 8 + 4 + 4 = 16
replacement costs 8 + 5 = 13
deferring deletion of insn with uid = 9.
modifying insn i210: {r93:DI=0x3f-clz(r85:DI);clobber flags:CC;}
REG_UNUSED flags:CC
REG_DEAD r85:DI
deferring rescan insn with uid = 10.
modifying insn i312: {r87:DI=zero_extend(r93:DI#0^0x3f);clobber flags:CC;}
REG_UNUSED flags:CC
deferring rescan insn with uid = 12.
and I was hoping that the combiner would soon try 10, 12, 13 -> 14 combination
where 10 and 12 are the above 2 new insns, 13 is r88:DI=0x40
and 14 is {r85:DI=r88:DI-r87:DI;clobber flags:CC;}.
But all it tries is 12 -> 14, 13 -> 14, 13, 12 -> 14 and all those fail.
Segher, any ideas?
[Bug middle-end/78103] Failure to optimize with __builtin_clzl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78103 --- Comment #11 from Jakub Jelinek --- Or is it because of the new pseudo that is created for the temporary? Seems when the combiner is splitting the insns itself using find_split_point, it tries to reuse i2dest if possible for the middle temporary, but I guess the splitters in the md files can't do that, they don't have that information.
[Bug gcov-profile/101623] New: [GCOV] Wrong coverage of callee function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101623
Bug ID: 101623
Summary: [GCOV] Wrong coverage of callee function
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: njuwy at smail dot nju.edu.cn
CC: marxin at gcc dot gnu.org
Target Milestone: ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure -enable-checking=release -enable-languages=c,c++
-disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (GCC)
$ cat test.c
#include
char a[] = "12345";
char b[] = "12345";
void loop(char *pz, char *pzDta) {
for (;;) {
switch (*(pz++) = *(pzDta++)) {
case 0:
goto loopDone2;
case '"':
case '\\':
pz[-1] = '\\';
*(pz++) = pzDta[-1];
}
}
loopDone2:;
if (a - pz != b - pzDta)
abort();
}
int main() {
loop(a, b);
exit(0);
}
$ gcc -O0 --coverage test.c;./a.out;gcov test;cat test.c.gcov
libgcov profiling error:/home/wangyang/coverage/test/test.gcda:overwriting an
existing profile data with a different timestamp
File 'test.c'
Lines executed:71.43% of 14
Creating 'test.c.gcov'
-:0:Source:test.c
-:0:Graph:test.gcno
-:0:Data:test.gcda
-:0:Runs:1
-:1:#include
-:2:char a[] = "12345";
-:3:char b[] = "12345";
-:4:
6:5:void loop(char *pz, char *pzDta) {
-:6: for (;;) {
6:7:switch (*(pz++) = *(pzDta++)) {
1:8:case 0:
1:9: goto loopDone2;
-: 10:
#: 11:case '"':
-: 12:case '\\':
#: 13: pz[-1] = '\\';
#: 14: *(pz++) = pzDta[-1];
-: 15:}
-: 16: }
1: 17:loopDone2:;
-: 18:
1: 19: if (a - pz != b - pzDta)
#: 20:abort();
1: 21:}
-: 22:
1: 23:int main() {
1: 24: loop(a, b);
1: 25: exit(0);
-: 26:}
Line 5 was executed only once.
[Bug target/101544] [OpenMP][AMDGCN][nvptx] C++ offloading: unresolved _Znwm = "operator new(unsigned long)"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101544 Thomas Schwinge changed: What|Removed |Added CC||tschwinge at gcc dot gnu.org Last reconfirmed||2021-07-26 Depends on||92713 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92713 [Bug 92713] ICE in libsupc++ building an offload compiler targeting amdgcn-unknown-amdhsa
[Bug middle-end/78103] Failure to optimize with __builtin_clzl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78103
--- Comment #12 from Jakub Jelinek ---
If reusing i2dest for the find_split_case is fine (I must say I'm a little bit
worried about uses of the pseudo in debug insns, whether if we reuse it for
something else we properly adjust those insns (or reset them)), what the code
does in the:
rtx newdest = i2dest;
...
/* Get NEWDEST as a register in the proper mode. We have already
validated that we can do this. */
if (GET_MODE (i2dest) != split_mode && split_mode != VOIDmode)
{
if (REGNO (i2dest) < FIRST_PSEUDO_REGISTER)
newdest = gen_rtx_REG (split_mode, REGNO (i2dest));
else
{
SUBST_MODE (regno_reg_rtx[REGNO (i2dest)], split_mode);
newdest = regno_reg_rtx[REGNO (i2dest)];
}
}
code if the if condition is false, can't it also try to reuse i2dest in the
else if (m_split_insn && NEXT_INSN (NEXT_INSN (m_split_insn)) == NULL_RTX
&& (next_nonnote_nondebug_insn (i2) == i3
|| !modified_between_p (PATTERN (m_split_insn), i2, i3)))
case (if it verifies i2dest doesn't appear anywhere in i2set and i3set) by
rewriting the SET_DEST of the i2set and all uses of it in i3set with i2dest if
the mode matches?
On the other side the
Since nowadays we can create registers during combine just fine,
we should just create a new one here, not reuse i2dest. */
comment says we should prefer creating new regs. If so, fine, but then we
shouldn't just distribute the preexisting i3links, i2links etc., but should try
to create new ones. I see the code does:
LOG_LINKS (i3) = NULL;
REG_NOTES (i3) = 0;
LOG_LINKS (i2) = NULL;
REG_NOTES (i2) = 0;
and then somewhat later
distribute_links (i3links);
distribute_links (i2links);
distribute_links (i1links);
distribute_links (i0links);
so distributes preexisting log links, but I don't see anything that would
similarly handle newly added pseudos from the combine_split_insns, create new
log link for that, record_value_for_reg etc.
[Bug fortran/93308] bind(c) subroutine changes lower bound of array argument in caller
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93308 --- Comment #9 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:0cbf03689e3e7d9d6002b8e5d159ef3716d0404c commit r12-2511-g0cbf03689e3e7d9d6002b8e5d159ef3716d0404c Author: Tobias Burnus Date: Mon Jul 26 14:20:46 2021 +0200 PR fortran/93308/93963/94327/94331/97046 problems raised by descriptor handling Fortran: Fix attributes and bounds in ISO_Fortran_binding. 2021-07-26 José Rui Faustino de Sousa Tobias Burnus PR fortran/93308 PR fortran/93963 PR fortran/94327 PR fortran/94331 PR fortran/97046 gcc/fortran/ChangeLog: * trans-decl.c (convert_CFI_desc): Only copy out the descriptor if necessary. * trans-expr.c (gfc_conv_gfc_desc_to_cfi_desc): Updated attribute handling which reflect a previous intermediate version of the standard. Only copy out the descriptor if necessary. libgfortran/ChangeLog: * runtime/ISO_Fortran_binding.c (cfi_desc_to_gfc_desc): Add code to verify the descriptor. Correct bounds calculation. (gfc_desc_to_cfi_desc): Add code to verify the descriptor. gcc/testsuite/ChangeLog: * gfortran.dg/ISO_Fortran_binding_1.f90: Add pointer attribute, this test is still erroneous but now it compiles. * gfortran.dg/bind_c_array_params_2.f90: Update regex to match code changes. * gfortran.dg/PR93308.f90: New test. * gfortran.dg/PR93963.f90: New test. * gfortran.dg/PR94327.c: New test. * gfortran.dg/PR94327.f90: New test. * gfortran.dg/PR94331.c: New test. * gfortran.dg/PR94331.f90: New test. * gfortran.dg/PR97046.f90: New test.
[Bug fortran/93963] Select rank mishandling allocatable and pointer arguments with bind(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93963 --- Comment #8 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:0cbf03689e3e7d9d6002b8e5d159ef3716d0404c commit r12-2511-g0cbf03689e3e7d9d6002b8e5d159ef3716d0404c Author: Tobias Burnus Date: Mon Jul 26 14:20:46 2021 +0200 PR fortran/93308/93963/94327/94331/97046 problems raised by descriptor handling Fortran: Fix attributes and bounds in ISO_Fortran_binding. 2021-07-26 José Rui Faustino de Sousa Tobias Burnus PR fortran/93308 PR fortran/93963 PR fortran/94327 PR fortran/94331 PR fortran/97046 gcc/fortran/ChangeLog: * trans-decl.c (convert_CFI_desc): Only copy out the descriptor if necessary. * trans-expr.c (gfc_conv_gfc_desc_to_cfi_desc): Updated attribute handling which reflect a previous intermediate version of the standard. Only copy out the descriptor if necessary. libgfortran/ChangeLog: * runtime/ISO_Fortran_binding.c (cfi_desc_to_gfc_desc): Add code to verify the descriptor. Correct bounds calculation. (gfc_desc_to_cfi_desc): Add code to verify the descriptor. gcc/testsuite/ChangeLog: * gfortran.dg/ISO_Fortran_binding_1.f90: Add pointer attribute, this test is still erroneous but now it compiles. * gfortran.dg/bind_c_array_params_2.f90: Update regex to match code changes. * gfortran.dg/PR93308.f90: New test. * gfortran.dg/PR93963.f90: New test. * gfortran.dg/PR94327.c: New test. * gfortran.dg/PR94327.f90: New test. * gfortran.dg/PR94331.c: New test. * gfortran.dg/PR94331.f90: New test. * gfortran.dg/PR97046.f90: New test.
[Bug fortran/94327] Bind(c) argument attributes are incorrectly set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94327 --- Comment #7 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:0cbf03689e3e7d9d6002b8e5d159ef3716d0404c commit r12-2511-g0cbf03689e3e7d9d6002b8e5d159ef3716d0404c Author: Tobias Burnus Date: Mon Jul 26 14:20:46 2021 +0200 PR fortran/93308/93963/94327/94331/97046 problems raised by descriptor handling Fortran: Fix attributes and bounds in ISO_Fortran_binding. 2021-07-26 José Rui Faustino de Sousa Tobias Burnus PR fortran/93308 PR fortran/93963 PR fortran/94327 PR fortran/94331 PR fortran/97046 gcc/fortran/ChangeLog: * trans-decl.c (convert_CFI_desc): Only copy out the descriptor if necessary. * trans-expr.c (gfc_conv_gfc_desc_to_cfi_desc): Updated attribute handling which reflect a previous intermediate version of the standard. Only copy out the descriptor if necessary. libgfortran/ChangeLog: * runtime/ISO_Fortran_binding.c (cfi_desc_to_gfc_desc): Add code to verify the descriptor. Correct bounds calculation. (gfc_desc_to_cfi_desc): Add code to verify the descriptor. gcc/testsuite/ChangeLog: * gfortran.dg/ISO_Fortran_binding_1.f90: Add pointer attribute, this test is still erroneous but now it compiles. * gfortran.dg/bind_c_array_params_2.f90: Update regex to match code changes. * gfortran.dg/PR93308.f90: New test. * gfortran.dg/PR93963.f90: New test. * gfortran.dg/PR94327.c: New test. * gfortran.dg/PR94327.f90: New test. * gfortran.dg/PR94331.c: New test. * gfortran.dg/PR94331.f90: New test. * gfortran.dg/PR97046.f90: New test.
[Bug fortran/94331] Bind(C) corrupts array descriptors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94331 --- Comment #14 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:0cbf03689e3e7d9d6002b8e5d159ef3716d0404c commit r12-2511-g0cbf03689e3e7d9d6002b8e5d159ef3716d0404c Author: Tobias Burnus Date: Mon Jul 26 14:20:46 2021 +0200 PR fortran/93308/93963/94327/94331/97046 problems raised by descriptor handling Fortran: Fix attributes and bounds in ISO_Fortran_binding. 2021-07-26 José Rui Faustino de Sousa Tobias Burnus PR fortran/93308 PR fortran/93963 PR fortran/94327 PR fortran/94331 PR fortran/97046 gcc/fortran/ChangeLog: * trans-decl.c (convert_CFI_desc): Only copy out the descriptor if necessary. * trans-expr.c (gfc_conv_gfc_desc_to_cfi_desc): Updated attribute handling which reflect a previous intermediate version of the standard. Only copy out the descriptor if necessary. libgfortran/ChangeLog: * runtime/ISO_Fortran_binding.c (cfi_desc_to_gfc_desc): Add code to verify the descriptor. Correct bounds calculation. (gfc_desc_to_cfi_desc): Add code to verify the descriptor. gcc/testsuite/ChangeLog: * gfortran.dg/ISO_Fortran_binding_1.f90: Add pointer attribute, this test is still erroneous but now it compiles. * gfortran.dg/bind_c_array_params_2.f90: Update regex to match code changes. * gfortran.dg/PR93308.f90: New test. * gfortran.dg/PR93963.f90: New test. * gfortran.dg/PR94327.c: New test. * gfortran.dg/PR94327.f90: New test. * gfortran.dg/PR94331.c: New test. * gfortran.dg/PR94331.f90: New test. * gfortran.dg/PR97046.f90: New test.
[Bug fortran/97046] Bad interaction between lbound/ubound, allocatable arrays and bind(C) subroutine with dimension(..) parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97046 --- Comment #10 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:0cbf03689e3e7d9d6002b8e5d159ef3716d0404c commit r12-2511-g0cbf03689e3e7d9d6002b8e5d159ef3716d0404c Author: Tobias Burnus Date: Mon Jul 26 14:20:46 2021 +0200 PR fortran/93308/93963/94327/94331/97046 problems raised by descriptor handling Fortran: Fix attributes and bounds in ISO_Fortran_binding. 2021-07-26 José Rui Faustino de Sousa Tobias Burnus PR fortran/93308 PR fortran/93963 PR fortran/94327 PR fortran/94331 PR fortran/97046 gcc/fortran/ChangeLog: * trans-decl.c (convert_CFI_desc): Only copy out the descriptor if necessary. * trans-expr.c (gfc_conv_gfc_desc_to_cfi_desc): Updated attribute handling which reflect a previous intermediate version of the standard. Only copy out the descriptor if necessary. libgfortran/ChangeLog: * runtime/ISO_Fortran_binding.c (cfi_desc_to_gfc_desc): Add code to verify the descriptor. Correct bounds calculation. (gfc_desc_to_cfi_desc): Add code to verify the descriptor. gcc/testsuite/ChangeLog: * gfortran.dg/ISO_Fortran_binding_1.f90: Add pointer attribute, this test is still erroneous but now it compiles. * gfortran.dg/bind_c_array_params_2.f90: Update regex to match code changes. * gfortran.dg/PR93308.f90: New test. * gfortran.dg/PR93963.f90: New test. * gfortran.dg/PR94327.c: New test. * gfortran.dg/PR94327.f90: New test. * gfortran.dg/PR94331.c: New test. * gfortran.dg/PR94331.f90: New test. * gfortran.dg/PR97046.f90: New test.
[Bug fortran/100906] Bind(c): failure handling character with len/=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100906 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #4 from Tobias Burnus --- I have committed: r12-2431-gb3d4011ba10275fbd5d6ec5a16d5aaebbdfb5d3c https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575729.html which should fix most diagnostic issues with character len /= 1 – except for: * len=0 – in my understanding, that's valid when using a descriptor but not when passing the argument as address to the byte stream -> with current patch not rejected. * const-length > 1 module variables with BIND(C). Those should now be valid as well, but that was not touched by this patch. Regarding len=0 and other things, see also thread starting at https://mailman.j3-fortran.org/pipermail/j3/2021-July/013189.html * * * Other TODO with regards to things diagnostic in my patch: * See 'sorry' in the patch and in the testsuite. Namely: len=* and len=: require an array descriptor, but for scalars and (len=*, only) for assumed/explicit-size arrays no descriptor is used. (Hence, the code aborts with an error) -> Requires an update both for the call and for the function type and for the function interface declaration. * * * Attached/submitted patch by José: There is a minor overlap to my committed patch and some overlap to the issues listed above, but I have not sorted it out, yet.
[Bug target/101611] AVX2 vector arithmetic shift lowered to scalar unnecessarily
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101611 --- Comment #4 from Jakub Jelinek --- Created attachment 51205 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51205&action=edit gcc12-pr101611.patch Full untested fix.
[Bug target/101611] AVX2 vector arithmetic shift lowered to scalar unnecessarily
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101611 --- Comment #5 from Marc Glisse --- (In reply to Jakub Jelinek from comment #2) > for arithmetic V[24]DImode >> V[24]DImode > logical ((x >> y) ^ (0x8000ULL >> y)) - (0x8000ULL > >> y) > can be used. I guess it would be complicated to try and implement this fallback strategy in a generic way so other modes/targets could benefit.
[Bug target/101611] AVX2 vector arithmetic shift lowered to scalar unnecessarily
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101611 --- Comment #6 from Jakub Jelinek --- I think except for x86 it is very unusual to support logical but not arithmetic vector right shifts, are you aware of any other target that suffers from these? Even vector by vector shifts are rare, if my grep doesn't miss anything, only aarch64, arm, x86, mips, rs6000 and s390 has them. I've grepped tmp-mddump.md for each of them and except for x86 where we have the known issues I only see some weird vlshrti3 pattern that doesn't have vashrti3 counterpart, but the vlshr3 and vashr3 optabs AFAIK should be used solely for vector modes and nothing else.
[Bug target/101611] AVX2 vector arithmetic shift lowered to scalar unnecessarily
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101611 --- Comment #7 from Marc Glisse --- The same strategy to implement arithmetic shift in terms of logical shift works not just for vector>>vector but also vector>>scalar and scalar>>scalar. But it is probably not worth the trouble indeed, especially since your target patch is ready :-)
[Bug target/101611] AVX2 vector arithmetic shift lowered to scalar unnecessarily
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101611 --- Comment #8 from Jakub Jelinek --- That is true, but I think even for vector >> scalar and scalar >> scalar shifts it will be quite rare to support logical and not support arithmetic shifts. And on x86, as can be seen in the PR98856 changes, yes, this way of expressing it is possible, but not always the shortest.
[Bug driver/101447] Remove legacy external declarations in toplev.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101447 --- Comment #5 from CVS Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:bf6d414415e14e13be16abf23375160733567d20 commit r12-2512-gbf6d414415e14e13be16abf23375160733567d20 Author: Ashimida Date: Mon Jul 26 10:38:50 2021 -0400 Remove legacy external declarations in toplev.h [PR101447] gcc/ PR driver/101447 * toplev.h (min_align_loops_log): Remove declaration. (min_align_jumps_log, min_align_labels_log): Likewise. (min_align_functions_log): Likewise.
[Bug target/92713] ICE in libsupc++ building an offload compiler targeting amdgcn-unknown-amdhsa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92713 --- Comment #3 from Tobias Burnus --- "ICE in libsupc++ building an offload compiler targeting amdgcn-unknown-amdhsa" (Subject) I wonder whether that ICE is just because of the lack of exception support and whether it might work when using -fno-rtti -fno-exceptions as proposed in PR 101544 comment 4
[Bug fortran/101624] New: [9/10/11/12 Regression] ICE: tree check: expected tree that contains 'decl with RTL' structure, have 'const_decl' in maybe_optimize_ubsan_ptr_ifn, at sanopt.c:495
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101624 Bug ID: 101624 Summary: [9/10/11/12 Regression] ICE: tree check: expected tree that contains 'decl with RTL' structure, have 'const_decl' in maybe_optimize_ubsan_ptr_ifn, at sanopt.c:495 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started with r8 (gcc configured with --enable-checking=yes) : $ cat z1.f90 complex function f(x) complex, intent(in) :: x f = aimag(x) end program p complex, parameter :: a = (0.0, 1.0) complex :: b, f b = f(a) end $ gfortran-12-20210725 -c z1.f90 -O2 -fsanitize=undefined during GIMPLE pass: sanopt z1.f90:9:3: 9 | end | ^ internal compiler error: tree check: expected tree that contains 'decl with RTL' structure, have 'const_decl' in maybe_optimize_ubsan_ptr_ifn, at sanopt.c:495 0x65f003 tree_contains_struct_check_failed(tree_node const*, tree_node_structure_enum, char const*, int, char const*) ../../gcc/tree.c:8860 0xe6f6ba contains_struct_check(tree_node*, tree_node_structure_enum, char const*, int, char const*) ../../gcc/tree.h:3487 0xe6f6ba maybe_optimize_ubsan_ptr_ifn ../../gcc/sanopt.c:495 0xe6f6ba sanopt_optimize_walker ../../gcc/sanopt.c:837 0xe6d807 sanopt_optimize_walker ../../gcc/sanopt.c:885 0xe70e06 sanopt_optimize ../../gcc/sanopt.c:909 0xe70e06 execute ../../gcc/sanopt.c:1279
[Bug lto/101625] New: ICE in modref_tree::merge with LTO and -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101625 Bug ID: 101625 Summary: ICE in modref_tree::merge with LTO and -m32 Product: gcc Version: 11.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: tonyb at cybernetics dot com CC: marxin at gcc dot gnu.org Target Milestone: --- Created attachment 51206 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51206&action=edit Relevant *.i preprocessed source files from grub ICE when building grub with LTO. Builds correctly when LTO disabled. gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/tonyb/tmp/gcc/install/libexec/gcc/x86_64-pc-linux-gnu/11.1.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc/configure --prefix=/home/tonyb/tmp/gcc/install Thread model: posix Supported LTO compression algorithms: zlib gcc version 11.1.1 20210726 (GCC) gcc -std=gnu99 -Os -m32 -Wall -W -Wshadow -Wpointer-arith -Wundef -Wchar-subscripts -Wcomment -Wdeprecated-declarations -Wdisabled-optimization -Wdiv-by-zero -Wfloat-equal -Wformat-extra-args -Wformat-security -Wformat-y2k -Wimplicit -Wimplicit-function-declaration -Wimplicit-int -Wmain -Wmissing-braces -Wmissing-format-attribute -Wmultichar -Wparentheses -Wreturn-type -Wsequence-point -Wshadow -Wsign-compare -Wswitch -Wtrigraphs -Wunknown-pragmas -Wunused -Wunused-function -Wunused-label -Wunused-parameter -Wunused-value -Wunused-variable -Wwrite-strings -Wnested-externs -Wstrict-prototypes -g -Wredundant-decls -Wmissing-prototypes -Wmissing-declarations -Wextra -Wattributes -Wendif-labels -Winit-self -Wint-to-pointer-cast -Winvalid-pch -Wmissing-field-initializers -Wnonnull -Woverflow -Wvla -Wpointer-to-int-cast -Wstrict-aliasing -Wvariadic-macros -Wvolatile-register-var -Wpointer-sign -Wmissing-include-dirs -Wmissing-prototypes -Wmissing-declarations -Wformat=2 -march=i386 -mrtd -mregparm=3 -falign-jumps=1 -falign-loops=1 -falign-functions=1 -freg-struct-return -mno-mmx -mno-sse -mno-sse2 -mno-sse3 -mno-3dnow -msoft-float -fno-dwarf2-cfi-asm -mno-stack-arg-probe -fno-asynchronous-unwind-tables -fno-unwind-tables -fno-ident -fno-stack-protector -Wtrampolines -Werror -ffreestanding -fno-builtin -Wno-undef -flto -ffat-lto-objects -fuse-linker-plugin -save-temps -Wno-error=implicit-fallthrough= -m32 -Wl,-melf_i386 -Wl,--build-id=none -nostdlib -Wl,-N -Wl,-r,-d -flto -ffat-lto-objects -fuse-linker-plugin -o zstd.module lib/zstd/zstd_module-debug.o lib/zstd/zstd_module-entropy_common.o lib/zstd/zstd_module-error_private.o lib/zstd/zstd_module-fse_decompress.o lib/zstd/zstd_module-huf_decompress.o lib/zstd/zstd_module-module.o lib/zstd/zstd_module-xxhash.o lib/zstd/zstd_module-zstd_common.o lib/zstd/zstd_module-zstd_decompress.o during IPA pass: inline lto1: internal compiler error: Segmentation fault 0xadc82f crash_signal ../../gcc/gcc/toplev.c:327 0x90135a modref_tree::merge(modref_tree*, vec*) ../../gcc/gcc/ipa-modref-tree.h:420 0x8f916a ipa_merge_modref_summary_after_inlining(cgraph_edge*) ../../gcc/gcc/ipa-modref.c:3096 0x8ecd94 inline_call(cgraph_edge*, bool, vec*, int*, bool, bool*) ../../gcc/gcc/ipa-inline-transform.c:503 0x1438e56 inline_small_functions ../../gcc/gcc/ipa-inline.c:2242 0x1438e56 ipa_inline ../../gcc/gcc/ipa-inline.c:2723 0x1438e56 execute ../../gcc/gcc/ipa-inline.c:3122
[Bug fortran/100440] allocated() gives True for unallocated variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440 --- Comment #13 from David.Smith at lmu dot edu --- Thanks for working on the bug I reported in May. I am hoping you can give me some information that I can pass on to the users of my open-source software who use gfortran to run it. Can you estimate when the fix will appear in an official release of gfortran, and what version number to look for? Thanks, David Smith From: anlauf at gcc dot gnu.org Sent: Tuesday, May 11, 2021 1:23 PM To: Smith, David Subject: [Bug fortran/100440] allocated() gives True for unallocated variable https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440 --- Comment #12 from anlauf at gcc dot gnu.org --- A small variation of the testcase in comment#9 suggests that there are actually two underlying issues: lack of initialization and a missing temporary. program p implicit none type fm real, allocatable :: mp(:) integer :: dummy = 42 end type type(fm), allocatable :: a(:), b(:) integer :: n = 1 allocate (a(n)) print *, "main:", n, allocated (a(n)% mp), a(n)% dummy b = mm (a) a = mm (b) a = mm (a) a = mm (a) ! crashes here with -fsanitize=address contains function mm (ma) type(fm), intent(in) :: ma(:) type(fm) :: mm(size(ma)) integer :: i ! type(fm) :: z(size(ma)) ! mm = z ! Explicit initialization of function result do i = 1, size(ma) print *, "in mm:", i, allocated (mm(i)% mp), mm(i)% dummy end do end function mm end program p This gives: main: 1 F 42 in mm: 1 F 0 in mm: 1 F 42 in mm: 1 F 0 in mm: 1 T 0 while with -fsanitize=address,undefined : main: 1 F 42 in mm: 1 F -1094795586 in mm: 1 F 42 in mm: 1 T -1094795586 in mm: 1 T -1094795586 Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x14987da6f49f in ??? [...] #6 0x409669 in p at /home/anlauf/gcc-bugs/pr100440-red3.f90:14 #7 0x4097d9 in main at /home/anlauf/gcc-bugs/pr100440-red3.f90:14 -- You are receiving this mail because: You reported the bug.
[Bug c/101626] New: [12 Regression] ICE in verify_sra_access_forest, at tree-sra.c:2376
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101626
Bug ID: 101626
Summary: [12 Regression] ICE in verify_sra_access_forest, at
tree-sra.c:2376
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Changed between 20210502 and 20210509.
(gcc configured with --enable-checking=yes)
Affects a bunch of testsuite files at -O1+,
e.g. pr36373*.c, pr39120.c, pr50444.c :
$ cat pr39120.c
struct X { int *p; } x;
struct X __attribute__((noinline))
foo(int *p) { struct X x; x.p = p; return x; }
void __attribute((noinline))
bar() { *x.p = 1; }
extern void abort (void);
int main()
{
int i = 0;
x = foo(&i);
bar();
if (i != 1)
abort ();
return 0;
}
$ gcc-12-20210725 -c pr39120.c -O2 -fsso-struct=big-endian
during GIMPLE pass: esra
pr39120.c: In function 'foo':
pr39120.c:18:1: internal compiler error: in verify_sra_access_forest, at
tree-sra.c:2376
18 | }
| ^
0xee585c verify_sra_access_forest(access*)
../../gcc/tree-sra.c:2376
0xee5af1 verify_all_sra_access_forests()
../../gcc/tree-sra.c:2420
0xee9d45 analyze_all_variable_accesses
../../gcc/tree-sra.c:3480
0xeea7c6 perform_intra_sra
../../gcc/tree-sra.c:4564
[Bug fortran/101627] New: List-directed read with trailing characters after quotes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101627 Bug ID: 101627 Summary: List-directed read with trailing characters after quotes Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: hj8758558 at gmail dot com Target Milestone: --- When reading a string delimited by single quotes, but followed by a non-blank character, gfortran takes the "err" branch. This is in contrast to ifort, nagfor, and flang, which read the string within the quotes and ignore the trailing character(s). Is gfortran's behavior intended? $ cat test.f90 program test character(len=6) :: input_str = "'abc'a" character(len=6) :: output_str read (input_str, *, err=77) output_str stop 'No read error' 77 continue stop 'Read error' end program test $ gfortran test.f90 && ./a.out STOP Read error
[Bug preprocessor/101628] New: Preprocessor errors on extended characters in #if 0 code block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101628
Bug ID: 101628
Summary: Preprocessor errors on extended characters in #if 0
code block
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: david.post at ohyonghao dot com
Target Milestone: ---
In a #if 0 code block, the presence of characters outside the extended
character set being used as an identifier still gets passed to the C++ compiler
and errors out with the message:
error: extended character ∂ is not valid in an identifier
Sample code:
int main(int argc, char **argv){
#if 0
Q_∂(false)
#endif
return 0;
}
The code within the #if 0 block should never be compiled which is the behavior
of other compilers such as clang++ which gleefully ignores bad code within #if
0 block.
To clarify, with clang++ the code errors without the #if 0 block, which is
expected behavior, and compiles with the #if 0 block around the bad code. g++
errors in both cases.
[Bug c++/101629] New: ICE: in cp_finish_decl, at cp/decl.c:7826
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101629
Bug ID: 101629
Summary: ICE: in cp_finish_decl, at cp/decl.c:7826
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
auto f(auto... args) {
if constexpr (auto x = [args]{});
}
int main() {
f(0, 0.4);
}
https://godbolt.org/z/WWr9hsWqh
[Bug c++/101629] ICE: in cp_finish_decl, at cp/decl.c:7826
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101629 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||mpolacek at gcc dot gnu.org Last reconfirmed||2021-07-26 --- Comment #1 from Marek Polacek --- Confirmed, invalid.
[Bug tree-optimization/78888] toupper(x) can be assumed not to be in the range 'a' - 'z'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7 --- Comment #2 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:1ce0b26e6e1e6c348b1d54f1f462a44df6fe47f5 commit r12-2517-g1ce0b26e6e1e6c348b1d54f1f462a44df6fe47f5 Author: Andrew MacLeod Date: Mon Jul 26 09:40:32 2021 -0400 Adjust ranges for to_upper and to_lower. Exclude lower case chars from to_upper and upper case chars from to_lower. gcc/ PR tree-optimization/7 * gimple-range-fold.cc (fold_using_range::range_of_builtin_call): Add cases for CFN_BUILT_IN_TOUPPER and CFN_BUILT_IN_TOLOWER. gcc/testsuite/ * gcc.dg/pr7.c: New.
[Bug tree-optimization/78888] toupper(x) can be assumed not to be in the range 'a' - 'z'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7 Andrew Macleod changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||amacleod at redhat dot com --- Comment #3 from Andrew Macleod --- fixed
[Bug c/101630] New: ICE with -Wall: in get_constant, at c-family/c-format.c:325
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101630
Bug ID: 101630
Summary: ICE with -Wall: in get_constant, at
c-family/c-format.c:325
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: cnsun at uwaterloo dot ca
Target Milestone: ---
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.Tt2AkDfoq0-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210726 (experimental) [master revision
:c09cf6429:124bb55777c280a85d0c72ec13e293a32917a6b9] (GCC)
$ cat mutant.c
printf(char[][], ...) { printf(printf); }
$ gcc-trunk -Wall mutant.c
mutant.c:1:12: error: array type has incomplete element type ‘char[]’
1 | printf(char[][], ...) { printf(printf); }
|^
mutant.c:1:12: note: declaration of multidimensional array must have bounds for
all dimensions except the first
mutant.c:1:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
1 | printf(char[][], ...) { printf(printf); }
| ^~
mutant.c: In function ‘printf’:
mutant.c:1:32: error: type of formal parameter 1 is incomplete
1 | printf(char[][], ...) { printf(printf); }
|^~
mutant.c:1:1: internal compiler error: in get_constant, at
c-family/c-format.c:325
1 | printf(char[][], ...) { printf(printf); }
| ^~
0x675c97 get_constant
/tmp/tmp.Tt2AkDfoq0-gcc-builder/gcc/gcc/c-family/c-format.c:325
0x675c97 get_constant
/tmp/tmp.Tt2AkDfoq0-gcc-builder/gcc/gcc/c-family/c-format.c:313
0x9b061e decode_format_attr
/tmp/tmp.Tt2AkDfoq0-gcc-builder/gcc/gcc/c-family/c-format.c:377
0x9b2894 check_function_format(tree_node const*, tree_node*, int, tree_node**,
vec*)
/tmp/tmp.Tt2AkDfoq0-gcc-builder/gcc/gcc/c-family/c-format.c:1173
0x9a1c86 check_function_arguments(unsigned int, tree_node const*, tree_node
const*, int, tree_node**, vec*)
/tmp/tmp.Tt2AkDfoq0-gcc-builder/gcc/gcc/c-family/c-common.c:5981
0x92a0eb build_function_call_vec(unsigned int, vec, tree_node*, vec*, vec*, tree_node*)
/tmp/tmp.Tt2AkDfoq0-gcc-builder/gcc/gcc/c/c-typeck.c:3195
0x94b27a c_parser_postfix_expression_after_primary
/tmp/tmp.Tt2AkDfoq0-gcc-builder/gcc/gcc/c/c-parser.c:10505
0x93bc65 c_parser_postfix_expression
/tmp/tmp.Tt2AkDfoq0-gcc-builder/gcc/gcc/c/c-parser.c:10178
0x946141 c_parser_unary_expression
/tmp/tmp.Tt2AkDfoq0-gcc-builder/gcc/gcc/c/c-parser.c:8224
0x94780f c_parser_cast_expression
/tmp/tmp.Tt2AkDfoq0-gcc-builder/gcc/gcc/c/c-parser.c:8066
0x947abf c_parser_binary_expression
/tmp/tmp.Tt2AkDfoq0-gcc-builder/gcc/gcc/c/c-parser.c:7869
0x948da8 c_parser_conditional_expression
/tmp/tmp.Tt2AkDfoq0-gcc-builder/gcc/gcc/c/c-parser.c:7592
0x949420 c_parser_expr_no_commas
/tmp/tmp.Tt2AkDfoq0-gcc-builder/gcc/gcc/c/c-parser.c:7507
0x9496b1 c_parser_expression
/tmp/tmp.Tt2AkDfoq0-gcc-builder/gcc/gcc/c/c-parser.c:10641
0x949e87 c_parser_expression_conv
/tmp/tmp.Tt2AkDfoq0-gcc-builder/gcc/gcc/c/c-parser.c:10680
0x95d2f3 c_parser_statement_after_labels
/tmp/tmp.Tt2AkDfoq0-gcc-builder/gcc/gcc/c/c-parser.c:6249
0x95f594 c_parser_compound_statement_nostart
/tmp/tmp.Tt2AkDfoq0-gcc-builder/gcc/gcc/c/c-parser.c:5788
0x95fc84 c_parser_compound_statement
/tmp/tmp.Tt2AkDfoq0-gcc-builder/gcc/gcc/c/c-parser.c:5597
0x961672 c_parser_declaration_or_fndef
/tmp/tmp.Tt2AkDfoq0-gcc-builder/gcc/gcc/c/c-parser.c:2539
0x968ff3 c_parser_external_declaration
/tmp/tmp.Tt2AkDfoq0-gcc-builder/gcc/gcc/c/c-parser.c:1777
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
Note that with -Wall, gcc-trunk also crashes though with a different stack
trace.
mutant.c:1:12: error: array type has incomplete element type ‘char[]’
1 | printf(char[][], ...) { printf(printf); }
|^
mutant.c:1:12: note: declaration of multidimensional array must have bounds for
all dimensions except the first
mutant.c:1:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
1 | printf(char[][], ...) { printf(printf); }
| ^~
mutant.c: In function ‘printf’:
mutant.c:1:32: error: type of formal parameter 1 is incomplete
1 | printf(char[][], ...) { printf(printf); }
|^~
mutant.c:1:25: internal compiler error: tree check: expected class ‘type’
[Bug preprocessor/101628] Preprocessor errors on extended characters in #if 0 code block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101628 --- Comment #1 from Andrew Pinski --- Related to PR 62661 which was closed as invalid. Basically the C++ standard says the tokens inside the #if blocks need to be valid tokens still.
[Bug c++/101631] New: gcc permits object reference to object outside of its lifetime during constant evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101631 Bug ID: 101631 Summary: gcc permits object reference to object outside of its lifetime during constant evaluation Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: fsb4000 at yandex dot ru Target Milestone: --- Hi. The bug has come up during the implementation of SSO for constexpr std::string which can be found here: https://github.com/microsoft/STL/pull/1735#discussion_r674285711 The issue stems from an obscure rule(https://eel.is/c++draft/class.union.general#6) that allows switching the active member of a union by assigning to an element of the array member. (Obligatory godbolt: https://godbolt.org/z/6qG7v9eYx) While the usage on line 12 is indeed correct, for std::string we need to go through char_traits which is imitated by perform_assignment. However, the lifetime of the subobject buf[5] only starts right before the assignment inside of perform_assignment, so on line 25 we form an object reference to an object outside of its lifetime which is ill formed. gcc should emit an appropriate diagnostic. Found by: Michael Schellenberger Costa I hope it helps.
[Bug target/49127] -Os generates constant mov instead of instruction xor and mov when zeroing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49127 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- This is a dup of bug 11877 and is fixed on the trunk. *** This bug has been marked as a duplicate of bug 11877 ***
[Bug target/11877] gcc should use xor trick with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11877 Andrew Pinski changed: What|Removed |Added CC||msharov at users dot sourceforge.n ||et --- Comment #13 from Andrew Pinski --- *** Bug 49127 has been marked as a duplicate of this bug. ***
[Bug target/41505] GCC choosing poor code sequence for certain stores (x86)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41505 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #8 from Andrew Pinski --- This is a dup of bug 11877 which is now fixed on the trunk. *** This bug has been marked as a duplicate of bug 11877 ***
[Bug target/11877] gcc should use xor trick with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11877 Andrew Pinski changed: What|Removed |Added CC||jeffreyalaw at gmail dot com --- Comment #14 from Andrew Pinski --- *** Bug 41505 has been marked as a duplicate of this bug. ***
[Bug fortran/101632] New: NON_RECURSIVE procedure prefix is unsupported. F2018 defaults to recursive procedures.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101632 Bug ID: 101632 Summary: NON_RECURSIVE procedure prefix is unsupported. F2018 defaults to recursive procedures. Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: kargl at gcc dot gnu.org Target Milestone: ---
[Bug tree-optimization/50286] Missed optimization, fails to propagate bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50286
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2011-12-14 00:00:00 |2021-7-26
--- Comment #2 from Andrew Pinski ---
EVRP is able to convert the loop to:
:
# i_3 = PHI <0(2), 1(3)>
_2 = i_3 * i_3;
printf ("%d\n", _2);
i_10 = i_3 == 0 ? 1 : 2;
if (flag_6 >= i_10)
goto ; [INV]
else
goto ; [INV]
flag_6 range is [0,1] even
[Bug fortran/101632] NON_RECURSIVE procedure prefix is unsupported. F2018 defaults to recursive procedures.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101632 --- Comment #1 from kargl at gcc dot gnu.org --- F2018 introduced the NON_RECURSIVE prefix for procedures and also made procedures recursive by default. This code is conforming to F2018. module bah contains ! ! non_recursive is F2018. ! non_recursive function foo(i) result(k) integer k integer, intent(in) :: i k = i end function foo ! ! Recursive has been around for awhile, and still in F2018 ! recursive function fib1(i) result(k) integer k integer, intent(in) :: i if (i <= 1) then k = i else k = fib1(i-1) + fib1(i - 2) end if end function fib1 ! ! This is recursive by default. ! function fib2(i) result(k) integer k integer, intent(in) :: i if (i <= 1) then k = i else k = fib2(i-1) + fib2(i - 2) end if end function fib2 end module bah program bar use bah integer i i = 9 print *, fib1(i), fib2(i) end program bar
[Bug fortran/101632] NON_RECURSIVE procedure prefix is unsupported. F2018 defaults to recursive procedures.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101632 --- Comment #2 from kargl at gcc dot gnu.org --- Created attachment 51207 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51207&action=edit Diff that implements F2018 NON_RECURSIVE and makes things recursive by default.
[Bug target/26656] Optimization flaw on conditional set of a bit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26656 Andrew Pinski changed: What|Removed |Added Component|tree-optimization |target Target||x86_64 --- Comment #9 from Andrew Pinski --- flagQuestion: .L2: cmpb%bpl, (%r12,%rax) setb%cl addl%ecx, %ecx orb %cl, (%rbx,%rax) addq$1, %rax cmpq$1, %rax jne .L2 flagQuestionWorkaround: .L7: cmpb%bpl, (%r12,%rax) setb%cl addl%ecx, %ecx orb %cl, (%rbx,%rax) addq$1, %rax cmpq$1, %rax jne .L7 flagIf: .L12: cmpb%bl, (%r12,%rax) jnb .L11 orb $2, 0(%rbp,%rax) .L11: addq$1, %rax cmpq$1, %rax jne .L12 flagIfWorkaround: .L16: cmpb%bpl, (%r12,%rax) setb%cl addl%ecx, %ecx orb %cl, (%rbx,%rax) addq$1, %rax cmpq$1, %rax jne .L16 There is not much be done with flagIf really since it is a conditional load/store.
[Bug tree-optimization/24696] missing optimization in comparison of results of bit operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24696 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #2 from Andrew Pinski --- >From ifcombine: optimizing bits or bits test to _3 & T != 0 with temporary T = b_6(D) | a_4(D) Merging blocks 2 and 3 Fixed by r0-128808.
[Bug middle-end/14842] Another way of expanding a switch statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14842 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |9.0 Resolution|--- |FIXED --- Comment #5 from Andrew Pinski --- Fixed in GCC 9 and above. Most likely fixed by r9-395.
[Bug tree-optimization/51084] bounds checking not optimized to a single comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51084 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2012-01-07 00:00:00 |2021-7-26 --- Comment #2 from Andrew Pinski --- pure0: _5 = obj_2(D) < &pure[100]; _6 = obj_2(D) >= &pure; _7 = _5 & _6; pure1: _5 = obj_2(D) < &MEM [(void *)&pure + 100B]; _6 = obj_2(D) >= &pure; _7 = _5 & _6; pure2: obj.2_1 = (long unsigned int) obj_5(D); pure.3_2 = (long unsigned int) &pure; _3 = obj.2_1 - pure.3_2; _4 = _3 <= 100; pure3: _1 = obj_4(D) - &pure; _2 = (long unsigned int) _1; _3 = _2 <= 100; We should be able to convert pure0 and pure1 into pure3 really.
[Bug target/15533] Missed move to partial register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15533 --- Comment #4 from Andrew Pinski --- This looks improved in GCC 4.4.7 and above: fn(unsigned short): movzbl a, %edx xorb%al, %al orl %edx, %eax ret
[Bug tree-optimization/34011] Memory load is not eliminated from tight vectorized loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34011 --- Comment #9 from Andrew Pinski --- good function: .L3: movdqu (%rdi,%rax), %xmm0 pslld %xmm1, %xmm0 movups %xmm0, (%rsi,%rax) addq$16, %rax cmpq$1024, %rax jne .L3 bad function: .L11: movdqu (%rdi,%rax), %xmm0 movdqu (%rsi,%rax), %xmm2 pslld %xmm1, %xmm0 por %xmm2, %xmm0 movups %xmm0, (%rsi,%rax) addq$16, %rax cmpq$1024, %rax jne .L11 Looks good to me now.
[Bug middle-end/52070] missing integer comparison optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52070 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2012-02-01 00:00:00 |2021-7-26 Component|tree-optimization |middle-end --- Comment #2 from Andrew Pinski --- _6 = b.1_1 > a_4(D); _7 = b.1_1 == 0; _8 = _6 | _7; So this is an expansion issue I think.
[Bug middle-end/39744] component references with VIEW_CONVERT_EXPR should be canonicalized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39744 --- Comment #3 from Andrew Pinski --- Confirmed again: Before FRE: z = 1; _4 = MEM[(struct X *)&z].y.z; Note fre we are able to do the right thing but dom does not.
[Bug tree-optimization/38209] branch optimisation generates worse code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38209 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED Severity|normal |enhancement --- Comment #3 from Andrew Pinski --- Mine. if (val_2(D) != 0) goto ; [INV] else goto ; [INV] : val_4 = ~val_2(D); : # val_1 = PHI
[Bug tree-optimization/30101] missed value numbering optimization (cprop+valnum)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30101 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |9.0 Status|NEW |RESOLVED --- Comment #2 from Andrew Pinski --- ccp1 in GCC 6+ is able to remove the two if statements; maybe done by r6-147 . fre1 in GCC 9+ is able to remove the two if stamtenets too; I didn't look into which revision though. So closing as fixed.
[Bug c++/101631] gcc permits object reference to object outside of its lifetime during constant evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101631 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2021-07-26 --- Comment #1 from Jonathan Wakely --- (In reply to fsb4000 from comment #0) > (Obligatory godbolt: https://godbolt.org/z/6qG7v9eYx) Godbolt links are not obligatory, but a testcase is. See https://gcc.gnu.org/bugs
[Bug tree-optimization/34417] simplify '(x & A) % B' if 'B > A/2'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34417 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2007-12-10 13:40:29 |2021-7-26 --- Comment #3 from Andrew Pinski --- (In reply to Andrew Pinski from comment #2) > (In reply to comment #1) > > Confirmed. > > > > VRP could do this, though we generally avoid creating control flow and extra > > basic blocks here. > > We could create a COND_EXPR here, though I don't know if that would be a > good idea on some targets. Or we could just create the MIN_EXPR :) since that is what it is.
[Bug tree-optimization/50272] A case that PRE optimization hurts performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50272 --- Comment #6 from Andrew Pinski --- In GCC 5+ we can get rid of the loop fully (in the reduced testcase).
[Bug middle-end/78103] Failure to optimize with __builtin_clzl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78103
--- Comment #13 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #10)
> Unfortunately, it doesn't work for the #c0 testcase, after the combiner
> splitter kicks in, the combiner doesn't even try that 4 insn combination.
It does for me?
Trying 10, 13, 12 -> 14:
10: {r86:DI=r86:DI^0x3f;clobber flags:CC;}
REG_UNUSED flags:CC
13: r88:DI=0x40
12: r87:DI=sign_extend(r86:DI#0)
REG_DEAD r86:DI
14: {r85:DI=r88:DI-r87:DI;clobber flags:CC;}
REG_DEAD r88:DI
REG_DEAD r87:DI
REG_UNUSED flags:CC
REG_EQUAL 0x40-r87:DI
Failed to match this instruction:
(parallel [
(set (reg/v:DI 85 [ x ])
(minus:DI (const_int 64 [0x40])
(xor:DI (sign_extend:DI (subreg:SI (reg:DI 86) 0))
(const_int 63 [0x3f]
(clobber (reg:CC 17 flags))
])
Failed to match this instruction:
(set (reg/v:DI 85 [ x ])
(minus:DI (const_int 64 [0x40])
(xor:DI (sign_extend:DI (subreg:SI (reg:DI 86) 0))
(const_int 63 [0x3f]
Successfully matched this instruction:
(set (reg:DI 88)
(sign_extend:DI (subreg:SI (reg:DI 86) 0)))
Failed to match this instruction:
(set (reg/v:DI 85 [ x ])
(minus:DI (const_int 64 [0x40])
(xor:DI (reg:DI 88)
(const_int 63 [0x3f]
(Because 13 is a move from constant, 4-insn is allowed here).
[Bug middle-end/54802] Trivial code changes result in different assembly with respect to rotations and bswap.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54802 --- Comment #1 from Andrew Pinski --- In GCC 5+, we are able to figure out both do bswap.
[Bug middle-end/78103] Failure to optimize with __builtin_clzl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78103 --- Comment #14 from Jakub Jelinek --- (In reply to Segher Boessenkool from comment #13) > (In reply to Jakub Jelinek from comment #10) > > Unfortunately, it doesn't work for the #c0 testcase, after the combiner > > splitter kicks in, the combiner doesn't even try that 4 insn combination. > > It does for me? But only in the unpatched gcc, no? For #c0 findLastSet I actually need to combine 5 original instructions, and what I was hoping for is to first combine first 3 instructions into 2, 9, 10 -> 12 to get rid of the useless sign-extension, the value is known to be 0..63, so zero extension is fine, into 10 (bsr) and 12 (xor with zero extend), which is what the #c9 patch does. And then I was hoping 10, 12, 13 -> 14 would be attempted to be combined because 13 is mov of a constant. But that doesn't happen because the 9, 10 -> 12 combination with the #c9 patch throws away the 12 -> 10 LOG_LINKS and doesn't add a new one, even when 10 is a setter of a fresh new pseudo and 12 is the only use of that pseudo.
[Bug tree-optimization/56610] IPA(-CP) clone materialization fails to cleanup the CFG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56610 Andrew Pinski changed: What|Removed |Added Known to fail||12.0 Status|UNCONFIRMED |NEW Last reconfirmed||2021-07-26 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed. Though I noticed the inlining will come in and clean it up which is two passes after ipa-cp.
[Bug middle-end/78103] Failure to optimize with __builtin_clzl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78103 --- Comment #15 from Segher Boessenkool --- (In reply to Jakub Jelinek from comment #14) > (In reply to Segher Boessenkool from comment #13) > > (In reply to Jakub Jelinek from comment #10) > > > Unfortunately, it doesn't work for the #c0 testcase, after the combiner > > > splitter kicks in, the combiner doesn't even try that 4 insn combination. > > > > It does for me? > > But only in the unpatched gcc, no? Yes, of course. > For #c0 findLastSet I actually need to combine 5 original instructions, [...] That is not something we want to ever implement: 4 insns already is too expensive unless we try only the simplest, and/or only very specific combinations. > and > what I was hoping for is to first combine first 3 instructions into 2, > 9, 10 -> 12 to get rid of the useless sign-extension, You should be able to combine only 10 and 12 even, to a SImode xor followed by the sign extension (may not work out wrt costs, but it isn't even tried). Or, why is r86 DImode anyway? > the value is known to > be 0..63, so zero extension is fine, into 10 (bsr) and 12 (xor with zero > extend), which is what the #c9 patch does. > And then I was hoping 10, 12, 13 -> 14 would be attempted to be combined > because 13 is mov of a constant. But that doesn't happen because the 9, 10 > -> 12 combination with the #c9 patch throws away the 12 -> 10 LOG_LINKS and > doesn't add a new one, even when 10 is a setter of a fresh new pseudo and 12 > is the only use of that pseudo. This is only safe if it *is* a new pseudo, and even then, you need to prevent getting stuck somehow. insn 10 is the most problematic things here btw, having the same pseudo as input and as output (it is not the unique setter either). This happens in expand already, probably a machine pattern that forgets to create new registers where it should?
[Bug tree-optimization/56711] missed optimization for __uint128_t of (unsigned long long)x != x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56711 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #2 from Andrew Pinski --- I am going to look into implementing this. Shouldn't be hard: _5 = a_2(D) & 18446744069414584320; _1 = _5 != 0; Note for aarch64 we want to do the opposite on the RTL level though. Clang is able to produce the shift for x86_64 but for armv8, these two functions have different code gen :).
[Bug tree-optimization/56369] Missed opportunity to combine comparisons with zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56369 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |7.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from Andrew Pinski --- Fixed in GCC 7+ by r7-1411. Basically it does: status1 = old_status < 0 ? old_status : 0; status1 >= 0 And converts the condition into "old_status >= 0" and then the MIN_EXPR can be sinked.
[Bug target/60826] inefficient code for vector xor on SSE2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60826 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |6.0 Resolution|--- |FIXED --- Comment #3 from Andrew Pinski --- Fixed fully in GCC 6+ in there is no extra move or going through memory. In GCC 5, there is an extra move but no going through memory. the RTL changed in GCC 7+ to use vec_select which fixes the problem without a register allocation issue with tieing TI and DF modes.
[Bug tree-optimization/57186] implement load sinking in loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57186 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |5.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Andrew Pinski --- Fixed in GCC 5 by r5-1146 .
[Bug middle-end/56924] Folding of checks into a range check should check upper boundary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56924 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Andrew Pinski --- Mine, bitfield related.
[Bug rtl-optimization/32629] missing CSE for constant in registers / inefficient memset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32629 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #7 from Andrew Pinski --- On the trunk at -O2 we have: pxor%xmm0, %xmm0 movups %xmm0, (%rdi) movups %xmm0, 16(%rdi) movups %xmm0, 32(%rdi) pxor%xmm0, %xmm0 movups %xmm0, 48(%rdi) movups %xmm0, 64(%rdi) ret With -mno-sse we get: movq$0, (%rdi) movq$0, 8(%rdi) movq$0, 16(%rdi) movq$0, 24(%rdi) movq$0, 32(%rdi) movq$0, 40(%rdi) movq$0, 48(%rdi) movq$0, 56(%rdi) movq$0, 64(%rdi) movq$0, 72(%rdi) ret at -Os we get: xorl%eax, %eax leaq48(%rdi), %rdx movl$8, %ecx movq%rax, (%rdi) movq%rax, 8(%rdi) movq%rax, 16(%rdi) movq%rax, 24(%rdi) movq%rax, 32(%rdi) movq%rax, 40(%rdi) xorl%eax, %eax movq%rdx, %rdi Which was implemented by PR 11877. So I am going to close this as a dup of bug 11877. *** This bug has been marked as a duplicate of bug 11877 ***
[Bug target/11877] gcc should use xor trick with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11877 Andrew Pinski changed: What|Removed |Added CC||andi-gcc at firstfloor dot org --- Comment #15 from Andrew Pinski --- *** Bug 32629 has been marked as a duplicate of this bug. ***
[Bug target/63525] unnecessary reloads generated in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63525
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |FIXED
Target Milestone|--- |7.0
--- Comment #1 from Andrew Pinski ---
This was fixed on the gimple level in GCC 7+.
That is :
_mm_store_pd(tmp, v);
x = tmp[0];
y = tmp[1];
Produces now:
_7 = BIT_FIELD_REF ;
x = _7;
_11 = BIT_FIELD_REF ;
y = _11;
Where it would be this before:
MEM[(__m128d * {ref-all})&tmp] = v_21;
_10 = tmp[0];
x = _10;
_12 = tmp[1];
y = _12;
This was implemented by r7-987.
So closing as fixed.
[Bug target/48297] Suboptimal optimization of boolean expression addition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48297 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2011-03-28 09:34:02 |2021-7-26 --- Comment #2 from Andrew Pinski --- On the trunk we get: xorl%eax, %eax cmpl%ecx, %edi sete%al cmpl%esi, %ecx sete%sil movzbl %sil, %esi addl%esi, %eax cmpl%edx, %ecx sete%dl movzbl %dl, %edx addl%edx, %eax While clang gets: xorl%eax, %eax cmpl%ecx, %edi sete%al xorl%edi, %edi cmpl%ecx, %esi sete%dil addl%eax, %edi xorl%eax, %eax cmpl%ecx, %edx sete%al addl%edi, %eax retq Both are still not good. We should
[Bug tree-optimization/68136] missed tree-level optimization with redundant computations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68136
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2015-10-28 00:00:00 |2021-7-26
--- Comment #3 from Andrew Pinski ---
Improved for GCC 11 by r11-3207 . The testcase even was changed to show that it
is not fully fixed:
typedef long long s64;
int
foo (s64 a, s64 b, s64 c)
{
s64 d = a - b;
if (d == 0)
return a + c;
else
return b + c + d;
}
[Bug tree-optimization/78888] toupper(x) can be assumed not to be in the range 'a' - 'z'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7 --- Comment #4 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:d5a8c1382718ae084d46ff9b8a26d6b1d0cb684c commit r12-2519-gd5a8c1382718ae084d46ff9b8a26d6b1d0cb684c Author: Andrew MacLeod Date: Mon Jul 26 17:25:06 2021 -0400 Confirm and Handle only ASCII in toupper and tolower ranges. PR tree-optimization/7 * gimple-range-fold.cc (get_letter_range): New. (fold_using_range::range_of_builtin_call): Call get_letter_range.
[Bug rtl-optimization/70782] zero-initialized long returned by value generates useless stores/loads to the stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70782 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-07-26 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Confirmed. Note the non-union case started to work with GCC 11.
[Bug target/67510] x86: Faster code is possible for integer absolute value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67510 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=97873, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=92651 Target Milestone|--- |11.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Andrew Pinski --- Fixed by r10-5498 and r11-5429 .
[Bug tree-optimization/71461] missed optimization in conditional assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71461 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2016-06-09 00:00:00 |2021-7-26 Severity|normal |enhancement
[Bug middle-end/19466] [meta-bug] bit-fields are non optimal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19466 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #3 from Andrew Pinski --- Mine but I suspect this won't be until next year.
[Bug tree-optimization/24568] [meta-bug] Missed optimization: trivialization of silly code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24568 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2008-11-22 10:41:24 |2021-7-26 --- Comment #10 from Andrew Pinski --- Hmm, For ILP32 the only thing we have left is: milliDiff_6 = -milliDiff_5(D); minutesDiff_13 = milliDiff_6 / 6; minutesDiff_8 = -minutesDiff_13; For LP64: milliDiff_8 = -milliDiff_7(D); _3 = milliDiff_8 / 1000; _12 = (int) _3; minutesDiff_13 = _12 / 60; minutesDiff_10 = -minutesDiff_13; ... _17 = milliDiff_7(D) / 1000; _5 = (int) _17; minutesDiff_16 = _5 / 60;
[Bug target/66663] gcc misses optimization emits useless test of (a & 31) with 32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Target Milestone|--- |9.0 Resolution|--- |FIXED --- Comment #2 from Andrew Pinski --- GCC 9+ is able to produce: foo(unsigned long long, int): .LFB0: .cfi_startproc movl4(%esp), %eax movl12(%esp), %ecx movl8(%esp), %edx shldl %eax, %edx sall%cl, %eax ret
[Bug target/66663] gcc misses optimization emits useless test of (a & 31) with 32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3 Andrew Pinski changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #3 from Andrew Pinski --- It was fixed by r9-62 which means this is a dup of bug 84431. *** This bug has been marked as a duplicate of bug 84431 ***
[Bug target/84431] Suboptimal code for masked shifts (x86/x86-64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84431 Andrew Pinski changed: What|Removed |Added CC||fuz at fuz dot su --- Comment #9 from Andrew Pinski --- *** Bug 3 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/101626] [12 Regression] ICE in verify_sra_access_forest, at tree-sra.c:2376
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101626 Andrew Pinski changed: What|Removed |Added Component|c |tree-optimization CC||pinskia at gcc dot gnu.org Target Milestone|--- |12.0
[Bug c++/55436] g++ compiles invalid code with child class of nested class in template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55436 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |7.0 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=10200, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=69753 --- Comment #12 from Andrew Pinski --- Fixed in GCC 7 by r7-755.
[Bug c++/51716] access to private member possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51716 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |5.0 Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from Andrew Pinski --- Dup of bug 24926. *** This bug has been marked as a duplicate of bug 24926 ***
[Bug c++/24926] gcc ignores access level violation for anonymous structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24926 Andrew Pinski changed: What|Removed |Added CC||kuba at et dot pl --- Comment #7 from Andrew Pinski --- *** Bug 51716 has been marked as a duplicate of this bug. ***
[Bug c++/52618] Explicit template specialization ignores access rights
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52618 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |4.8.0 --- Comment #3 from Andrew Pinski --- Fixed in GCC 4.8+.
[Bug c++/52761] [C++11] Missing diagnostic for opaque unscoped enum declaration without base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52761
--- Comment #2 from Andrew Pinski ---
clang declared this as a GNU extention :)
:2:6: error: redeclaration of already-defined enum 'E' is a GNU
extension [-Werror,-Wgnu-redeclared-enum]
enum E; // illegal
^
:1:6: note: previous definition is here
enum E { X };
^
