[Bug rtl-optimization/105753] [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105753 --- Comment #19 from CVS Commits --- The master branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:80348e6aec44966e20ca1ca823247ce1381071eb commit r14-1016-g80348e6aec44966e20ca1ca823247ce1381071eb Author: Triffid Hunter Date: Sat May 20 07:50:00 2023 +0200 target/105753: Fix ICE in add_clobbers due to extra PARALLEL in insn. This patch removes the superfluous parallel in [u]divmod patterns in the AVR backend. Effect of extra parallel is that add_clobbers reaches gcc_unreachable() because the clobbers for [u]divmod are missing. If an insn has multiple parts like clobbers, the parallel around the parts of the insn pattern is implicit. gcc/ PR target/105753 * config/avr/avr.md (divmodpsi, udivmodpsi, divmodsi, udivmodsi): Remove superfluous "parallel" in insn pattern. ([u]divmod4): Tidy code. Use gcc_unreachable() instead of printing error text to assembly. gcc/testsuite/ PR target/105753 * gcc.target/avr/torture/pr105753.c: New test.
[Bug middle-end/109907] Missed optimization for bit extraction (uses shift instead of single bit-test)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109907 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|pinskia at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #10 from Andrew Pinski --- I applied the patches now after approval, r14-1014-gc5df248509b48 is the one that makes the difference here. I am not working on improving the ^1 part though so leaving it open for that.
[Bug target/55181] [10/11/12/13/14 Regression] Expensive shift loop where a bit-testing instruction could be used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55181 --- Comment #28 from Andrew Pinski --- I forgot to mention this was fixed by r14-1014-gc5df248509b48 .
[Bug target/55181] [10/11/12/13/14 Regression] Expensive shift loop where a bit-testing instruction could be used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55181 Andrew Pinski changed: What|Removed |Added Target||avr Target Milestone|10.5|14.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #27 from Andrew Pinski --- This is now fixed on the trunk for GCC 14. I have no plans on backporting the patches.
[Bug c/60090] For expression without ~, gcc -O1 emits "comparison of promoted ~unsigned with unsigned"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60090 --- Comment #7 from Andrew Pinski --- This one still happens on the trunk even with PR 107465 fixed. The reason is because even though a warning here is correct, it is not wanted due to requiring constant folding. Note you can get also the incorrect warning wording at -O0 with constexpr in GCC 13+ (and -std=c2x).
[Bug c/107465] [10 Regression] Bogus warning: promoted bitwise complement of an unsigned value is always nonzero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107465 Andrew Pinski changed: What|Removed |Added CC||jmattsson at dius dot com.au --- Comment #22 from Andrew Pinski --- *** Bug 59098 has been marked as a duplicate of this bug. ***
[Bug c/59098] Unwarranted warning: promoted ~unsigned is always non-zero [-Wsign-compare]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59098 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #5 from Andrew Pinski --- Marking as a dup of bug 107465 as that is what fixed the issue here. *** This bug has been marked as a duplicate of bug 107465 ***
[Bug c/107465] [10 Regression] Bogus warning: promoted bitwise complement of an unsigned value is always nonzero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107465 Andrew Pinski changed: What|Removed |Added CC||fredrik.hederstierna@securi ||tas-direct.com --- Comment #21 from Andrew Pinski --- *** Bug 38341 has been marked as a duplicate of this bug. ***
[Bug c/38341] Wrong warning comparison of promoted ~unsigned with unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38341 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #13 from Andrew Pinski --- So this has been fixed on all of the active branches. Since PR 107465 was the one recorded in the changelog, closing as a dup of that one. *** This bug has been marked as a duplicate of bug 107465 ***
[Bug c/52050] Want an option to warn about a declaration inside a for/while/if statements.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52050 Andrew Pinski changed: What|Removed |Added Blocks||87403 --- Comment #7 from Andrew Pinski --- This is now warning with -Wc90-c99-compat (since GCC 9). Though it does not have its own option. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 [Bug 87403] [Meta-bug] Issues that suggest a new warning
[Bug c++/66555] Fails to warn for if (j == 0 && i == i)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66555 Andrew Pinski changed: What|Removed |Added CC||trt at alumni dot duke.edu --- Comment #4 from Andrew Pinski --- *** Bug 17534 has been marked as a duplicate of this bug. ***
[Bug c/17534] gcc fails to diagnose suspect expressions that have incompatible bit masks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17534 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |6.0 Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #10 from Andrew Pinski --- Fixed for GCC 6 by r6-2453-g05b28fd6f91016 (aka PR 66555) so just marking as a dup of that bug. *** This bug has been marked as a duplicate of bug 66555 ***
[Bug middle-end/49617] gcc misses uninititialized variables in contained functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49617 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2011-07-04 09:48:32 |2023-5-19 Component|c |middle-end --- Comment #2 from Andrew Pinski --- Hmm, for the C testcase with GCC 5, we do get a warning: : In function 'main': :11:6: warning: 'FRAME.0.y' is used uninitialized in this function [-Wuninitialized] x = y; ^ There is no warning in GCC 6+ though. Plus the diagnostic mentions FRAME.0. which is not in the original source.
[Bug c/20110] format checking and non-ASCII character sets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20110 Andrew Pinski changed: What|Removed |Added CC||bonzini at gnu dot org --- Comment #4 from Andrew Pinski --- *** Bug 33748 has been marked as a duplicate of this bug. ***
[Bug c/33748] format warnings don't take input charset into account
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33748 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup of bug 20110. *** This bug has been marked as a duplicate of bug 20110 ***
[Bug middle-end/55279] New pseudo registers aren't supported in CSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55279 --- Comment #10 from Andrew Pinski --- (In reply to Andrew Pinski from comment #3) > I think combine was changed for the similar reason to support psedudos but I > cannot find the patch right now. Note combine was only fully fixed recently in GCC 12 with r12-8030-g61bee6aed26eb3.
[Bug tree-optimization/106888] [RISCV] Negative optimization that excess andi instructions are generated in gcc.dg/pr90838.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106888 Jeffrey A. Law changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #12 from Jeffrey A. Law --- Should be fixed with Raphael's patch on the trunk.
[Bug tree-optimization/106888] [RISCV] Negative optimization that excess andi instructions are generated in gcc.dg/pr90838.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106888 --- Comment #11 from CVS Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:9000da00dd70988f30d43806bae33b22ee6b9904 commit r14-1006-g9000da00dd70988f30d43806bae33b22ee6b9904 Author: Raphael Moreira Zinsly Date: Fri May 19 20:54:34 2023 -0600 RISC-V: Fix CTZ unnecessary sign extension [PR #106888] Changes since v1: - Remove subreg from operand 1. -- >8 -- We were not able to match the CTZ sign extend pattern on RISC-V because it gets optimized to zero extend and/or to ANDI patterns. For the ANDI case, combine scrambles the RTL and generates the extension by using subregs. gcc/ChangeLog: PR target/106888 * config/riscv/bitmanip.md (disi2): Match with any_extend. (disi2_sext): New pattern to match with sign extend using an ANDI instruction. gcc/testsuite/ChangeLog: PR target/106888 * gcc.target/riscv/pr106888.c: New test. * gcc.target/riscv/zbbw.c: Check for ANDI.
[Bug middle-end/31271] Missing simple optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31271 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |4.7.0 --- Comment #3 from Andrew Pinski --- (In reply to Andrew Pinski from comment #2) > > I think we could do slightly better > ((~in_2(D)) & 224) == 0 > > But only at exand time. > This gives: > notl%edi > xorl%eax, %eax > testb $-32, %dil > setne %al x86_64 produces that in GCC 13 with r13-792-g29ae455901ac71 . > > Or for aarch64: > mov w8, #224 > bicswzr, w8, w0 > csetw0, ne > ret For aarch64, it could define an instruction to catch: (set (reg:CC_NZV 66 cc) (compare:CC_NZV (and:SI (not:SI (reg:SI 100)) (const_int 224 [0xe0])) (const_int 0 [0]))) Anyways the original issue was fixed in GCC 4.7.0 and the small improvement for x86_64 is in GCC 13. The aarch64 code generation is currently: and w0, w0, 224 cmp w0, 224 csetw0, ne ret Which is only slightly worse than what I proposed too.
[Bug middle-end/31631] Folding of A & (1 << B) pessimizes FRE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31631 --- Comment #2 from Andrew Pinski --- We do a LIM before PRE now which allows PRE to handle it.
[Bug middle-end/100798] a?~t:t and (-(!!a))^t don't produce the same assembly code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100798 --- Comment #1 from Andrew Pinski --- To produce the same code we could do a match pattern: (simplify (cond @0 (bit_not @1) @1) (bit_xor (neg (convert @0)) @1))
[Bug middle-end/64334] Common .opt handling: Support flags which take a list of values (-fopt=a,b,c ...)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64334 Andrew Pinski changed: What|Removed |Added Keywords||internal-improvement Target Milestone|--- |12.0 --- Comment #2 from Andrew Pinski --- EnumBitSet was added with r12-6842-g0ebb09f5e49c8c . EnumSet/Set was added with r12-6839-g385196adb52d85 . So fixed with GCC 12. Note fsanitize= is still not using those for other reasons.
[Bug rtl-optimization/46943] Unnecessary ZERO_EXTEND
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46943 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2018-04-22 00:00:00 |2023-5-19 Severity|normal |enhancement
[Bug middle-end/98961] Failure to optimize successive comparisons with 0 into clz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98961 --- Comment #5 from Andrew Pinski --- or could be a cost thing ...
[Bug middle-end/98961] Failure to optimize successive comparisons with 0 into clz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98961 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Component|rtl-optimization|middle-end Last reconfirmed||2023-05-20 --- Comment #4 from Andrew Pinski --- Confirmed, I think this should happen at expand time and only if the target does not have conditional compares (e.g. like aarch64).
[Bug rtl-optimization/89680] Redundant moves with -march=skylake for long long shift on 32bit x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89680 Andrew Pinski changed: What|Removed |Added Known to work||10.1.0 --- Comment #2 from Andrew Pinski --- Looks like this was fixed in GCC 10.
[Bug tree-optimization/109287] Optimizing sal shr pairs when inlining function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109287
--- Comment #2 from Andrew Pinski ---
Actually it is closer to:
unsigned f(unsigned t, unsigned b, unsigned *tt)
{
if (b >= 16) __builtin_unreachable();
t *= 16;
t+= b;
*tt = t%16;
unsigned ttt = t/16;
return ttt;
}
As we know the range of b will be [0,15] due to the loop
[Bug tree-optimization/109287] Optimizing sal shr pairs when inlining function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109287
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2023-05-20
Component|middle-end |tree-optimization
Severity|normal |enhancement
--- Comment #1 from Andrew Pinski ---
Reduced down to:
unsigned f(unsigned t, unsigned b, unsigned *tt)
{
t *= 16;
t+= b;
unsigned ttt = t/16;
*tt = t%16;
return ttt;
}
Confirmed.
[Bug middle-end/108847] unnecessary bitwise AND on boolean types and shifting of the "sign" bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108847 Andrew Pinski changed: What|Removed |Added Target|x86_64-*-* |x86_64-*-* aarch64-*-* Status|NEW |ASSIGNED --- Comment #2 from Andrew Pinski --- I am messing around in this area
[Bug c/109912] #pragma GCC diagnostic ignored "-Wall" is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109912
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-05-20
--- Comment #1 from Andrew Pinski ---
So it is all of the "meta"-options which have this issue as shown by:
```
#pragma GCC diagnostic warning "-Wunused"
#pragma GCC diagnostic ignored "-Wunused"
static int f() {return 0;}
```
Confirmed.
[Bug middle-end/109907] Missed optimization for bit extraction (uses shift instead of single bit-test)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109907 --- Comment #9 from Andrew Pinski --- (In reply to Georg-Johann Lay from comment #6) > Quite impressive improvement. Maybe the last step can be achieved with a > combiner pattern that combines extzv with a bit flip. > > One problem is usually that there is no canonical form (sometimes > zero_extract, sometimes shift+and, sometimes with subregs for extraction or > paradoxical subregs for wider types, different behaviour for MSB, etc.). Right, In this case combine tries: (set (reg/i:QI 24 r24) (zero_extract:QI (xor:QI (reg:QI 54) (const_int 64 [0x40])) (const_int 1 [0x1]) (const_int 6 [0x6]))) Which puts the xor inside the zero_extract even but I think you could handle that once my patch set goes in.
[Bug tree-optimization/109038] Miss optimization to simplify bit_and + rotate to shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109038
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-05-19
Ever confirmed|0 |1
Component|middle-end |tree-optimization
--- Comment #2 from Andrew Pinski ---
Confirmed.
(simplify
(rrotate (bit_and @0 INTEGER_CST@1) INTEGER_CST@2)
(if (@1 == (type)(~0) >> (typebits-@2))
(lshift @0 { typebits - @2; }))
(simplify
(lrotate (bit_and @0 INTEGER_CST@1) INTEGER_CST@2)
(if (@1 == (type)(~0) >> (@2))
(lshift @0 { @2; }))
There could be more dealing with the result being logical shift right.
[Bug target/55181] [10/11/12/13/14 Regression] Expensive shift loop where a bit-testing instruction could be used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55181 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #26 from Andrew Pinski --- So I guess this is mine too. With my patches I created to improve PR 109907 (attached there), the initial RTL now looks like: ;; _9 = (unsigned char) _8; (insn 6 5 0 (set (reg/v:QI 46 [ ]) (zero_extract:QI (subreg:QI (reg/v:SI 47 [ number ]) 3) (const_int 1 [0x1]) (const_int 5 [0x5]))) "t2.c":4:6 -1 (nil)) Where it was before: ;; _9 = (unsigned char) _8; (insn 6 5 7 (set (reg:SI 48) (lshiftrt:SI (reg/v:SI 47 [ number ]) (const_int 29 [0x1d]))) "t2.c":4:6 -1 (nil)) (insn 7 6 0 (set (reg/v:QI 46 [ ]) (and:QI (subreg:QI (reg:SI 48) 0) (const_int 1 [0x1]))) "t2.c":4:6 -1 (nil))
[Bug objc/109913] [14 regression] r14-976-g9907413a3a6aa3 causes more than 300 objc/objc++ failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109913 --- Comment #3 from Andrew Pinski --- Note for powerpc-darwin, VECTOR_TYPE_P might need to be defined too.
[Bug c++/99451] [plugin] cannot enable specific dump for plugin passes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99451 --- Comment #2 from CVS Commits --- The trunk branch has been updated by Nathan Sidwell : https://gcc.gnu.org/g:97a36b466ba1420210294f0a1dd7002054ba3b7e commit r14-1004-g97a36b466ba1420210294f0a1dd7002054ba3b7e Author: Nathan Sidwell Date: Wed May 17 19:27:13 2023 -0400 Allow plugin dumps Defer dump option parsing until plugins are initialized. This allows one to use plugin names for dumps. PR other/99451 gcc/ * opts.h (handle_deferred_dump_options): Declare. * opts-global.cc (handle_common_deferred_options): Do not handle dump options here. (handle_deferred_dump_options): New. * toplev.cc (toplev::main): Call it after plugin init.
[Bug objc/109913] [14 regression] r14-976-g9907413a3a6aa3 causes more than 300 objc/objc++ failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109913 --- Comment #2 from Andrew Pinski --- Created attachment 55123 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55123=edit Patch to test Does this patch work? If so assign it to me and I will apply it.
[Bug objc/109913] [14 regression] r14-976-g9907413a3a6aa3 causes more than 300 objc/objc++ failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109913 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0
[Bug objc/109913] [14 regression] r14-976-g9907413a3a6aa3 causes more than 300 objc/objc++ failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109913 --- Comment #1 from Andrew Pinski --- The problem is ROUND_TYPE_ALIGN is used in libobjc and then RECORD_OR_UNION_TYPE_P is not defined there ...
[Bug middle-end/21161] [10/11/12/13/14 Regression] "clobbered by longjmp" warning ignores the data flow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21161 Paul Eggert changed: What|Removed |Added CC||eggert at cs dot ucla.edu --- Comment #26 from Paul Eggert --- Created attachment 55122 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55122=edit GCC bug 21161 as triggered by GNU diffutils I ran into a similar problem when compiling GNU diffutils with gcc (GCC) 13.1.1 20230511 (Red Hat 13.1.1-2) on x86.64. Here is a stripped-down illustrating of the diffutils problem. Compile the attached program with: gcc -O2 -W -S pr21161.i The output, which is a false positive, is: pr21161.i: In function ‘find_dir_file_pathname’: pr21161.i:22:15: warning: variable ‘match’ might be clobbered by ‘longjmp’ or ‘vfork’ [-Wclobbered] 22 | char const *match = file; | ^
[Bug c/91093] Error on implicit int by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91093 Martin Uecker changed: What|Removed |Added CC||muecker at gwdg dot de --- Comment #3 from Martin Uecker --- *** Bug 106425 has been marked as a duplicate of this bug. ***
[Bug c/106425] implicit-int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106425 Martin Uecker changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from Martin Uecker --- Duplicate. *** This bug has been marked as a duplicate of bug 91093 ***
[Bug tree-optimization/101770] -Wmaybe-uninitialized false alarm with only locals in GNU diffutils
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101770 --- Comment #5 from Paul Eggert --- I can no longer reproduce the bug in bleeding-edge GNU diffutils, so this bug is not so important in its own right - that is, it's merely that GCC 13.1.1 still mishandles w.i.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 101770, which changed state. Bug 101770 Summary: -Wmaybe-uninitialized false alarm with only locals in GNU diffutils https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101770 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[Bug tree-optimization/101770] -Wmaybe-uninitialized false alarm with only locals in GNU diffutils
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101770 Paul Eggert changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED Version|11.2.1 |13.1.1 --- Comment #4 from Paul Eggert --- I seeing the bug with gcc (GCC) 13.1.1 20230511 (Red Hat 13.1.1-2) on x86-64 when compiling GNU diffutils, so although the bug was reported fixed on the trunk last year, it appears that the fix hasn't propagated GCC 13 despite the Target Milestone being 13.0. The symptoms are: $ gcc -O2 -Wmaybe-uninitialized -S w.i w.i: In function ‘edit’: w.i:50:18: warning: ‘cmd1’ may be used uninitialized [-Wmaybe-uninitialized] 50 | return !cmd1; | ^ w.i:7:11: note: ‘cmd1’ was declared here 7 | int cmd1; | ^~~~ This appears to be the same bug as before so I am taking the liberty of reopening the bug report.
[Bug objc/109913] New: [14 regression] r14-976-g9907413a3a6aa3 causes more than 300 objc/objc++ failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109913 Bug ID: 109913 Summary: [14 regression] r14-976-g9907413a3a6aa3 causes more than 300 objc/objc++ failures Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: objc Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:9907413a3a6aa30a4a6db4756c445b40f04597f3, r14-976-g9907413a3a6aa3 commit 9907413a3a6aa30a4a6db4756c445b40f04597f3 (HEAD) Author: Bernhard Reutner-Fischer Date: Sun May 14 00:38:33 2023 +0200 gcc/config/*: use _P() defines from tree.h FAIL: obj-c++.dg/basic.mm -fgnu-runtime (test for excess errors) FAIL: obj-c++.dg/bitfield-1.mm -fgnu-runtime (test for excess errors) FAIL: obj-c++.dg/bitfield-2.mm -fgnu-runtime (test for excess errors) FAIL: obj-c++.dg/bitfield-4.mm -fgnu-runtime (test for excess errors) FAIL: obj-c++.dg/cxx-ivars-1.mm -fgnu-runtime (test for excess errors) FAIL: obj-c++.dg/cxx-scope-1.mm -fgnu-runtime (test for excess errors) FAIL: obj-c++.dg/defs.mm -fgnu-runtime (test for excess errors) FAIL: obj-c++.dg/demangle-1.mm -fgnu-runtime (test for excess errors) FAIL: obj-c++.dg/demangle-2.mm -fgnu-runtime (test for excess errors) FAIL: obj-c++.dg/encode-10.mm -fgnu-runtime (test for excess errors) FAIL: obj-c++.dg/encode-3.mm -fgnu-runtime (test for excess errors) FAIL: obj-c++.dg/encode-4.mm -fgnu-runtime (test for excess errors) FAIL: obj-c++.dg/encode-5.mm -fgnu-runtime (test for excess errors) FAIL: obj-c++.dg/encode-6.mm -fgnu-runtime (test for excess errors) FAIL: obj-c++.dg/encode-9.mm -fgnu-runtime (test for excess errors) FAIL: obj-c++.dg/except-1.mm -fgnu-runtime (test for excess errors) FAIL: obj-c++.dg/gnu-api-2-class-meta.mm -fgnu-runtime (test for excess errors) FAIL: obj-c++.dg/gnu-api-2-class.mm -fgnu-runtime (test for excess errors) FAIL: obj-c++.dg/gnu-api-2-ivar.mm -fgnu-runtime (test for excess errors) FAIL: obj-c++.dg/gnu-api-2-method.mm -fgnu-runtime (test for excess errors) FAIL: obj-c++.dg/gnu-api-2-objc.mm -fgnu-runtime (test for excess errors) FAIL: obj-c++.dg/gnu-api-2-objc_msg_lookup.mm -fgnu-runtime (test for excess errors) FAIL: obj-c++.dg/gnu-api-2-object.mm -fgnu-runtime (test for excess errors) FAIL: obj-c++.dg/gnu-api-2-property.mm -fgnu-runtime (test for excess errors) FAIL: obj-c++.dg/gnu-api-2-protocol.mm -fgnu-runtime (test for excess errors) FAIL: obj-c++.dg/gnu-api-2-resolve-method.mm -fgnu-runtime (test for excess errors) FAIL: obj-c++.dg/gnu-api-2-sel.mm -fgnu-runtime (test for excess errors) FAIL: obj-c++.dg/gnu-runtime-3.mm -fgnu-runtime (test for excess errors) FAIL: obj-c++.dg/lookup-2.mm -fgnu-runtime (test for excess errors) FAIL: obj-c++.dg/lto/trivial-1 obj_cpp_lto_trivial-1_0.o-obj_cpp_lto_trivial-1_0.o link, -O0 -flto -fgnu-runtime -Wno-objc-root-class FAIL: obj-c++.dg/lto/trivial-1 obj_cpp_lto_trivial-1_0.o-obj_cpp_lto_trivial-1_0.o link, -O0 -flto -flto-partition=none -fgnu-runtime -Wno-objc-root-class FAIL: obj-c++.dg/lto/trivial-1 obj_cpp_lto_trivial-1_0.o-obj_cpp_lto_trivial-1_0.o link, -O2 -flto -fgnu-runtime -Wno-objc-root-class FAIL: obj-c++.dg/lto/trivial-1 obj_cpp_lto_trivial-1_0.o-obj_cpp_lto_trivial-1_0.o link, -O2 -flto -flto-partition=none -fgnu-runtime -Wno-objc-root-class FAIL: obj-c++.dg/method-10.mm -fgnu-runtime (test for excess errors) FAIL: obj-c++.dg/method-17.mm -fgnu-runtime (test for excess errors) FAIL: obj-c++.dg/method-19.mm -fgnu-runtime (test for excess errors) FAIL: obj-c++.dg/method-22.mm -fgnu-runtime (test for excess errors) FAIL: obj-c++.dg/method-23.mm -fgnu-runtime (test for excess errors) FAIL: obj-c++.dg/property/at-property-10.mm -fgnu-runtime -Wno-objc-root-class (test for excess errors) FAIL: obj-c++.dg/property/at-property-11.mm -fgnu-runtime -Wno-objc-root-class (test for excess errors) FAIL: obj-c++.dg/property/at-property-12.mm -fgnu-runtime -Wno-objc-root-class (test for excess errors) FAIL: obj-c++.dg/property/at-property-13.mm -fgnu-runtime -Wno-objc-root-class (test for excess errors) FAIL: obj-c++.dg/property/at-property-19.mm -fgnu-runtime -Wno-objc-root-class (test for excess errors) FAIL: obj-c++.dg/property/at-property-22.mm -fgnu-runtime -Wno-objc-root-class (test for excess errors) FAIL: obj-c++.dg/property/at-property-24.mm -fgnu-runtime -Wno-objc-root-class (test for excess errors) FAIL: obj-c++.dg/property/at-property-26.mm -fgnu-runtime -Wno-objc-root-class (test for excess errors) FAIL: obj-c++.dg/property/at-property-27.mm -fgnu-runtime -Wno-objc-root-class (test for excess errors) FAIL: obj-c++.dg/property/at-property-6.mm -fgnu-runtime -Wno-objc-root-class (test for excess errors) FAIL: obj-c++.dg/property/at-property-7.mm -fgnu-runtime -Wno-objc-root-class (test for excess errors) FAIL: obj-c++.dg/property/at-property-8.mm -fgnu-runtime -Wno-objc-root-class (test for excess errors) FAIL:
[Bug testsuite/101528] [11 regression] gcc.target/powerpc/int_128bit-runnable.c fails after r11-8743
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101528 Carl Love changed: What|Removed |Added CC||cel at us dot ibm.com --- Comment #6 from Carl Love --- I will look into this and see if the instruction counts have changed for some reason.
[Bug c++/109876] [10/11/12/13/14 Regression] initializer_list not usable in constant expressions in a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109876
--- Comment #7 from Marek Polacek ---
// PR c++/109876
using size_t = decltype(sizeof 0);
namespace std {
template struct initializer_list {
const int *_M_array;
size_t _M_len;
constexpr size_t size() const { return _M_len; }
};
} // namespace std
template struct Array {};
template void g()
{
static constexpr std::initializer_list num{2};
Array ctx;
}
[Bug middle-end/109907] Missed optimization for bit extraction (uses shift instead of single bit-test)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109907 --- Comment #8 from Georg-Johann Lay --- avr.md has this: > ;; ??? do_store_flag emits a hard-coded right shift to extract a bit without > ;; even considering rtx_costs, extzv, or a bit-test. See PR55181 for an > example. And I already tried to work around it in that PR, but forgot about it...
[Bug middle-end/109907] Missed optimization for bit extraction (uses shift instead of single bit-test)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109907 --- Comment #7 from Andrew Pinski --- (In reply to Georg-Johann Lay from comment #6) > (define_expand "extzv" > [(set (match_operand:QI 0 "register_operand") > (zero_extract:QI (match_operand:QI 1 "register_operand") > (match_operand:QI 2 "const1_operand") > (match_operand:QI 3 "const_0_to_7_operand")))]) > > Maybe QI for op1 is not optimal, but it's not possible to use mode iterator > because there's only one gen_extzv. Dunno if VOIDmode would help or is sane. Note extzv pattern has been deprecate since 4.8 with r0-120368-gd2eeb2d179a435 which added extzv and co as being supported. So maybe moving over to using that instead on avr backend might help here ...
[Bug c/70418] VM structure type specifier in list of parameter declarations within nested function definition ices.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70418 --- Comment #8 from Martin Uecker --- https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618911.html
[Bug c/70418] VM structure type specifier in list of parameter declarations within nested function definition ices.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70418 Martin Uecker changed: What|Removed |Added CC||muecker at gwdg dot de --- Comment #7 from Martin Uecker --- *** Bug 106465 has been marked as a duplicate of this bug. ***
[Bug c/106465] ICE for VLA in struct in parameter of nested function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106465 Martin Uecker changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Martin Uecker --- Was filed previously as PR70418 *** This bug has been marked as a duplicate of bug 70418 ***
[Bug middle-end/109907] Missed optimization for bit extraction (uses shift instead of single bit-test)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109907 --- Comment #6 from Georg-Johann Lay --- (In reply to Andrew Pinski from comment #4) > For cset_32bit30_not with some patches which I will be posting, I get: > bst r25,6; 23 [c=4 l=3] *extzv/4 > clr r24 > bld r24,0 > ldi r25,lo8(1) ; 24 [c=4 l=1] movqi_insn/1 > eor r24,r25 ; 25 [c=4 l=1] *xorqi3 > /* epilogue start */ > ret ; 28 [c=0 l=1] return > > Which is better than what was there before. Quite impressive improvement. Maybe the last step can be achieved with a combiner pattern that combines extzv with a bit flip. One problem is usually that there is no canonical form (sometimes zero_extract, sometimes shift+and, sometimes with subregs for extraction or paradoxical subregs for wider types, different behaviour for MSB, etc.). avr's extzv currently reads (define_expand "extzv" [(set (match_operand:QI 0 "register_operand") (zero_extract:QI (match_operand:QI 1 "register_operand") (match_operand:QI 2 "const1_operand") (match_operand:QI 3 "const_0_to_7_operand")))]) Maybe QI for op1 is not optimal, but it's not possible to use mode iterator because there's only one gen_extzv. Dunno if VOIDmode would help or is sane. > The first one I suspect load_extend_op for SImode returning SIGN_EXTEND for > avr. It's not implemented for avr, thus UNKNOWN as of defaults.h.
[Bug middle-end/109907] Missed optimization for bit extraction (uses shift instead of single bit-test)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109907 --- Comment #5 from Andrew Pinski --- Created attachment 55121 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55121=edit patch set here is the patch set that improves cset_32bit30_not . I am still looking into improving the other one.
[Bug middle-end/109907] Missed optimization for bit extraction (uses shift instead of single bit-test)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109907 --- Comment #4 from Andrew Pinski --- For cset_32bit30_not with some patches which I will be posting, I get: bst r25,6; 23 [c=4 l=3] *extzv/4 clr r24 bld r24,0 ldi r25,lo8(1) ; 24 [c=4 l=1] movqi_insn/1 eor r24,r25 ; 25 [c=4 l=1] *xorqi3 /* epilogue start */ ret ; 28 [c=0 l=1] return Which is better than what was there before. The way I get this is to use BIT_FIELD_REF inside fold_single_bit_test . The first one I suspect load_extend_op for SImode returning SIGN_EXTEND for avr.
[Bug other/109910] GCC prologue/epilogue saves/restores callee-saved registers that are never changed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109910 --- Comment #1 from Georg-Johann Lay --- Note that df_regs_ever_live_p may be used before reload_completed, for example in INITIAL_ELIMINATION_OFFSET. Hence, scanning the insns by hand using, say, note_stores, does not work because reload might still be in progress.
[Bug c++/108788] Lookup of injected class name should be type-dependent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108788
Patrick Palka changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
||ppalka at gcc dot gnu.org
--- Comment #2 from Patrick Palka ---
Partially fixed by r12-3643-g18b57c1d4a8777. Reduced version of what we still
reject:
template
struct templ_base { };
template
int get_templ_base(T&& v)
{
return v.templ_base::a; // fails in all gcc versions
}
: In function ‘int get_templ_base(T&&)’:
:7:14: error: ‘template struct templ_base’ used without
template arguments
[Bug preprocessor/109912] New: #pragma GCC diagnostic ignored "-Wall" is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109912 Bug ID: 109912 Summary: #pragma GCC diagnostic ignored "-Wall" is ignored Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: ed at catmur dot uk Target Milestone: --- #pragma GCC diagnostic warning "-Wall" #pragma GCC diagnostic ignored "-Wall" int i = 0 | 1 & 2; warning: suggest parentheses around arithmetic in operand of '|' [-Wparentheses] 3 | int i = 0 | 1 & 2; | ~~^~~ The expected behavior would be for `diagnostic ignored "-Wall"` to suppress all the warnings that were enabled by `diagnostic warning "-Wall"`. If this isn't possible, it would be good to emit a diagnostic that `diagnostic ignored "-Wall"` has no effect. Clang does support this and appears to have always done so.
[Bug target/109279] RISC-V: complex constants synthesized should be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109279
--- Comment #16 from Vineet Gupta ---
> Which is what this produces:
> ```
> long long f(void)
> {
> unsigned t = 16843009;
> long long t1 = t;
> long long t2 = ((unsigned long long )t) << 32;
> asm("":"+r"(t1));
> return t1 | t2;
> }
> ```
> I suspect: 0x0080402010080400ULL should be done as two 32bit with a shift/or
> added too. Will definitely improve complex constants forming too.
>
> Right now the backend does (const<<16+const)<<16+const... which is just so
> bad.
Umm this testcase is a different problem. It used to generate the same output
but no longer after g2e886eef7f2b5a and the other related updates:
g0530254413f8 and gc104ef4b5eb1.
For the test above, the low and high words are created independently and then
stitched.
260r.dfinit
# lower word
(insn 6 2 7 2 (set (reg:DI 138)
(const_int [0x101])) {*movdi_64bit}
(insn 7 6 8 2 (set (reg:DI 137)
(plus:DI (reg:DI 138)
(const_int [0x101]))) {adddi3}
(expr_list:REG_EQUAL (const_int [0x1010101]) )
(insn 5 8 9 2 (set (reg/v:DI 134 [ t1 ])
(reg:DI 136 [ t1 ])) {*movdi_64bit}
# upper word created independently, no reuse from prior values)
(insn 9 5 10 2 (set (reg:DI 141)
(const_int [0x101])) {*movdi_64bit}
(insn 10 9 11 2 (set (reg:DI 142)
(plus:DI (reg:DI 141)
(const_int [0x101]))) {adddi3}
(insn 11 10 12 2 (set (reg:DI 140)
(ashift:DI (reg:DI 142)
(const_int 32 [0x20]))) {ashldi3}
(expr_list:REG_EQUAL (const_int [0x1010101]))
# stitch them
(insn 12 11 13 2 (set (reg:DI 139)
(ior:DI (reg/v:DI 134 [ t1 ])
(reg:DI 140))) "const2.c":7:13 99 {iordi3}
cse1 matches the new "*mvconst_internal" pattern independently on each of them
(insn 7 6 8 2 (set (reg:DI 137)
(const_int [0x1010101])) {*mvconst_internal}
(expr_list:REG_EQUAL (const_int [0x1010101])))
(insn 11 10 12 2 (set (reg:DI 140)
(const_int [0x1010101_])) {*mvconst_internal}
(expr_list:REG_EQUAL (const_int
[0x1010101_]) ))
This ultimately gets in the way, as otherwise it would find the equivalent reg
across the 2 snippets and reuse reg.
It is interesting that due to same pattern, split1 undoes what cse1 did so in
theory cse2 ? could redo it it. Anyhow needs to be investigated. But ATM we
have the following codegen for the aforementioned test which clearly needs more
work.
li a0,16842752
addia0,a0,257
li a5,16842752
sllia0,a0,32
addia5,a5,257
or a0,a5,a0
ret
[Bug driver/33980] Precompiled header file not removed on error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33980 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |14.0 Status|ASSIGNED|RESOLVED --- Comment #8 from Andrew Pinski --- Fixed finally.
[Bug driver/33980] Precompiled header file not removed on error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33980
--- Comment #7 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:cddb6dd6668843db351807ab8d2ff7440109f39a
commit r14-1000-gcddb6dd6668843db351807ab8d2ff7440109f39a
Author: Andrew Pinski
Date: Fri May 19 06:12:49 2023 +
Fix driver/33980: Precompiled header file not removed on error
So the problem here is that in the spec files, we were not marking the pch
output file to be removed on error.
The way to fix this is to mark the --output-pch argument as the output
file argument.
For the C++ specs file, we had to move around where the %V was located
such that it would be after the %w marker as %V marker clears the
outputfiles.
OK? Bootstrapped and tested on x86_64-linux-gnu.
gcc/cp/ChangeLog:
PR driver/33980
* lang-specs.h ("@c++-header"): Add %w after
the --output-pch.
("@c++-system-header"): Likewise.
("@c++-user-header"): Likewise.
gcc/ChangeLog:
PR driver/33980
* gcc.cc (default_compilers["@c-header"]): Add %w
after the --output-pch.
[Bug target/109279] RISC-V: complex constants synthesized should be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109279
Vineet Gupta changed:
What|Removed |Added
CC||vineetg at gcc dot gnu.org
Status|NEW |ASSIGNED
--- Comment #15 from Vineet Gupta ---
(In reply to Andrew Pinski from comment #6)
> Take:
> long long f(void)
> {
> return 0x0101010101010101ull;
> }
>
> CUT
> This should be done as:
> li a0,16842752
> addia0,a0,257
> sllia1,a0,32
> or a0,a0,a1
I committed a fix today which gets us to exactly that [1]
[1] https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618948.html
[Bug fortran/109911] New: [OpenMP] 'declare reduction' not USE associated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109911 Bug ID: 109911 Summary: [OpenMP] 'declare reduction' not USE associated Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: openmp, rejects-valid Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Target Milestone: --- Found via OpenMP Spec Pull Request #3629 for Issue #3595. The following program fails with: Error: !$OMP DECLARE REDUCTION add not found at (1) But it works when moving or copying the declare line into the main program. [Side remark: It is unclear (see PR above) whether the code is supposed to work with 'private'.] Note that the spec states: "If a _directive_ appears in the specification part of a module then the behavior is as if that _directive_ appears in the specification part of any _compilation-unit_ that references the module with a *USE* statement unless otherwise specified." module m ! private !$omp declare reduction (Add : integer : myadd(omp_in, omp_out)) contains subroutine myadd(in, out) integer :: in, out end end module use m implicit none (type,external) integer :: x !$omp parallel reduction(Add: x) ! ... !$omp end parallel end
[Bug other/109910] New: GCC prologue/epilogue saves/restores callee-saved registers that are never changed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109910
Bug ID: 109910
Summary: GCC prologue/epilogue saves/restores callee-saved
registers that are never changed
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
Created attachment 55120
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55120=edit
args.c: C test case.
There are targets like AVR that can pass values in callee-saved registers.
There is no need to save / restore them if a caller never changes them.
Example:
$ avr-gcc args.c -dp -mmcu=atmega128 -S -Os
typedef __UINT64_TYPE__ uint64_t;
void callee_ld (long double, long double);
void callee_ull (uint64_t, uint64_t);
void noop_ld (long double x, long double y)
{
callee_ld (x, y);
}
void noop_ull (uint64_t x, uint64_t y)
{
callee_ull (x, y);
}
y is passed in R10...R17 which are callee-saved:
noop_ld:
push r10 ; 73 [c=4 l=1] pushqi1/0
push r11 ; 74 [c=4 l=1] pushqi1/0
push r12 ; 75 [c=4 l=1] pushqi1/0
push r13 ; 76 [c=4 l=1] pushqi1/0
push r14 ; 77 [c=4 l=1] pushqi1/0
push r15 ; 78 [c=4 l=1] pushqi1/0
push r16 ; 79 [c=4 l=1] pushqi1/0
push r17 ; 80 [c=4 l=1] pushqi1/0
call callee_ld ; 39 [c=0 l=2] call_insn/1
pop r17 ; 83 [c=4 l=1] popqi
pop r16 ; 84 [c=4 l=1] popqi
pop r15 ; 85 [c=4 l=1] popqi
pop r14 ; 86 [c=4 l=1] popqi
pop r13 ; 87 [c=4 l=1] popqi
pop r12 ; 88 [c=4 l=1] popqi
pop r11 ; 89 [c=4 l=1] popqi
pop r10 ; 90 [c=4 l=1] popqi
ret ; 91 [c=0 l=1] return_from_epilogue
There is no need to save R10..R17 because they are never changed. If any of
these regs is changed by callee_ld, that function will take care of it because
these regs are callee-saved.
No need to mention that this adds considerably to code size, compute and stack
usage.
The AVR backend uses df_regs_ever_live_p to determine whether a register must
be saved / restored in lack of a better alternative like non-existing
df_regs_ever_changed_p.
Configured with: ../../source/gcc-master/configure --target=avr --disable-nls
--with-dwarf2 --with-gnu-as --with-gnu-ld --disable-shared
--enable-languages=c,c++
gcc version 14.0.0 20230518 (experimental) (GCC)
[Bug middle-end/109907] Missed optimization for bit extraction (uses shift instead of single bit-test)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109907 --- Comment #3 from Andrew Pinski --- Note this code has been in expr.cc since before 1992 even :).
[Bug middle-end/109907] Missed optimization for bit extraction (uses shift instead of single bit-test)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109907 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-05-19 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #2 from Andrew Pinski --- Confirmed. I am going to try to fix this. The code which does this is in expr.cc and starts with the following comment: /* If this is an equality or inequality test of a single bit, we can do this by shifting the bit being tested to the low-order bit and masking the result with the constant 1. If the condition was EQ, we xor it with 1. This does not require an scc insn and is faster than an scc insn even if we have it. Which makes it sound like it is always true but it is not as shown by the avr generated code.
[Bug c++/105760] [11/12/13/14 Regression] ICE: in build_function_type, at tree.cc:7365
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105760 Andrew Pinski changed: What|Removed |Added Summary|ICE: in |[11/12/13/14 Regression] |build_function_type, at |ICE: in |tree.cc:7365|build_function_type, at ||tree.cc:7365 Known to work||10.4.0 Known to fail||11.1.0 Target Milestone|--- |11.4 Keywords||error-recovery, ||ice-checking
[Bug c++/109871] error: call of overloaded ... is ambiguous (std::vector vs designated initializers)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109871 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Patrick Palka --- Fixed for GCC 13.2, thanks for the bug report.
[Bug c++/109871] error: call of overloaded ... is ambiguous (std::vector vs designated initializers)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109871 --- Comment #4 from CVS Commits --- The releases/gcc-13 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:efdcb731bbd6e20552fe878d54e59dc06af02334 commit r13-7357-gefdcb731bbd6e20552fe878d54e59dc06af02334 Author: Patrick Palka Date: Tue May 16 12:39:16 2023 -0400 c++: desig init in presence of list ctor [PR109871] add_list_candidates has logic to reject designated initialization of a non-aggregate type, but this is inadvertently being suppressed if the type has a list constructor due to the order of case analysis, which in the below testcase leads to us incorrectly treating the initializer list as if it's non-designated. This patch fixes this by making us check for invalid designated initialization sooner. PR c++/109871 gcc/cp/ChangeLog: * call.cc (add_list_candidates): Check for invalid designated initialization sooner and even for types that have a list constructor. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/desig27.C: New test. (cherry picked from commit d5e5007c4b534391c0a97be56f6024fde1a88682)
[Bug middle-end/109907] [avr] Missed optimization for bit extraction (uses shift instead of single bit-test)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109907 --- Comment #1 from Andrew Pinski --- I was just touching that area in the middle end and had noticed it didn't do any cost analysis
[Bug c++/97340] Spurious rejection of member variable template of reference type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97340 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |14.0 Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |RESOLVED --- Comment #5 from Patrick Palka --- Fixed for GCC 14.
[Bug c++/97340] Spurious rejection of member variable template of reference type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97340 --- Comment #4 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:ef8926d23a458560b8e9be1a76cf29ddcb87ec2a commit r14-997-gef8926d23a458560b8e9be1a76cf29ddcb87ec2a Author: Patrick Palka Date: Fri May 19 09:40:16 2023 -0400 c++: scoped variable template-id of reference type [PR97340] lookup_and_finish_template_variable calls convert_from_reference, which means for a variable template-id of reference type the function wraps the corresponding VAR_DECL in an INDIRECT_REF. But the downstream logic of two callers, tsubst_qualified_id and finish_class_member_access_expr, expect a DECL_P result and this unexpected INDIRECT_REF leads to an ICE resolving such a (dependently scoped) template-id as in the first testcase. (Note these two callers eventually call convert_from_reference on the result anyway, so calling it earlier seems redundant in this case.) This patch fixes this by pulling out the convert_from_reference call from lookup_and_finish_template_variable and into the callers that actually need it, which turns out to only be tsubst_copy_and_build (if we got rid of the call there we'd mishandle the second testcase). PR c++/97340 gcc/cp/ChangeLog: * pt.cc (lookup_and_finish_template_variable): Don't call convert_from_reference. (tsubst_copy_and_build) : Call convert_from_reference on the result of lookup_and_finish_template_variable. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/var-templ80.C: New test. * g++.dg/cpp1y/var-templ81.C: New test.
[Bug c++/109909] New: vector: Writing 8 bytes into 1 allocated byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109909
Bug ID: 109909
Summary: vector: Writing 8 bytes into 1 allocated byte
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Target Milestone: ---
Created attachment 55119
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55119=edit
Preprocessed source code
The following piece of code, when compiled, shows a warning about writing 8
bytes into an address for which 1 byte was allocated.
Tentatively blaming the compiler although it might just as well be a library
issue.
Severity could be anything from fairly trivial ("just a bogus warning") to
really bad ("overwriting memory it should not").
Both "-std=gnu++20" and "-O3" seem to be required to trigger the warning.
$ cat ttt.C
#include
struct Oink {
using utype = unsigned char;// in gcc13 this triggers
//
/usr/local/products/gcc/13.1.0/include/c++/13.1.0/bits/stl_construct.h:97:14:
warning: writing 8 bytes into a region of size 1 [-Wstringop-overflow=]
// using the next line does not.
// using utype = long long;
utype mValue = 0;
};
std::vector mSty;
void foo() {
mSty.resize(1);
}
$ /usr/local/products/gcc/13.1.0/bin/g++ -std=gnu++20 -c -v -O3 ttt.C
Using built-in specs.
COLLECT_GCC=/usr/local/products/gcc/13.1.0/bin/g++
Target: x86_64-suse-linux
Configured with: ../../gcc-13.1.0/configure --enable-languages=c,c++,fortran
--enable-targets=x86_64-suse-linux,i686-suse-linux
--prefix=/usr/local/products/gcc/13.1.0 --with-gnu-as
--with-as=/usr/local/products/gcc/binutils-2.40/bin/as
--with-ld=/usr/local/products/gcc/binutils-2.40/bin/ld.gold --enable-link-mutex
--enable-gnu-indirect-functions --enable-linux-futex --enable-threads=posix
--enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=new
x86_64-suse-linux
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.1.0 (GCC)
COLLECT_GCC_OPTIONS='-std=gnu++20' '-c' '-v' '-O3' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
/usr/local/products/gcc/13.1.0/lib/gcc/x86_64-suse-linux/13.1.0/cc1plus -quiet
-v -D_GNU_SOURCE ttt.C -quiet -dumpbase ttt.C -dumpbase-ext .C -mtune=generic
-march=x86-64 -O3 -std=gnu++20 -version -o /tmp/ccxuQqee.s
GNU C++20 (GCC) version 13.1.0 (x86_64-suse-linux)
compiled by GNU C version 13.1.0, GMP version 6.2.1, MPFR version
4.2.0, MPC version 1.3.1, isl version isl-0.18-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/usr/local/products/gcc/13.1.0/lib64/gcc/x86_64-suse-linux/13.1.0/../../../../x86_64-suse-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/products/gcc/13.1.0/lib64/gcc/x86_64-suse-linux/13.1.0/../../../../include/c++/13.1.0
/usr/local/products/gcc/13.1.0/lib64/gcc/x86_64-suse-linux/13.1.0/../../../../include/c++/13.1.0/x86_64-suse-linux
/usr/local/products/gcc/13.1.0/lib64/gcc/x86_64-suse-linux/13.1.0/../../../../include/c++/13.1.0/backward
/usr/local/products/gcc/13.1.0/lib64/gcc/x86_64-suse-linux/13.1.0/include
/usr/local/include
/usr/local/products/gcc/13.1.0/include
/usr/local/products/gcc/13.1.0/lib64/gcc/x86_64-suse-linux/13.1.0/include-fixed
/usr/include
End of search list.
Compiler executable checksum: 759d8432ee23c1bd4b520a57099ed580
In file included from
/usr/local/products/gcc/13.1.0/include/c++/13.1.0/bits/stl_iterator.h:85,
from
/usr/local/products/gcc/13.1.0/include/c++/13.1.0/bits/stl_algobase.h:67,
from
/usr/local/products/gcc/13.1.0/include/c++/13.1.0/vector:62,
from ttt.C:1:
In function ‘constexpr decltype (::new(void*(0)) _Tp) std::construct_at(_Tp*,
_Args&& ...) [with _Tp = Oink; _Args = {Oink}]’,
inlined from ‘static constexpr void
std::allocator_traits >::construct(allocator_type&, _Up*,
_Args&& ...) [with _Up = Oink; _Args = {Oink}; _Tp = Oink]’ at
/usr/local/products/gcc/13.1.0/include/c++/13.1.0/bits/alloc_traits.h:539:21,
inlined from ‘constexpr void std::__relocate_object_a(_Tp*, _Up*,
_Allocator&) [with _Tp = Oink; _Up = Oink; _Allocator = allocator]’ at
/usr/local/products/gcc/13.1.0/include/c++/13.1.0/bits/stl_uninitialized.h:1072:26,
inlined from ‘constexpr _ForwardIterator
std::__relocate_a_1(_InputIterator, _InputIterator, _ForwardIterator,
_Allocator&) [with _InputIterator = Oink*; _ForwardIterator = Oink*; _Allocator
= allocator]’ at
/usr/local/products/gcc/13.1.0/include/c++/13.1.0/bits/stl_uninitialized.h:1100:26,
inlined from ‘constexpr _ForwardIterator std::__relocate_a(_InputIterator,
_InputIterator, _ForwardIterator, _Allocator&) [with _InputIterator = Oink*;
_ForwardIterator = Oink*; _Allocator = allocator]’ at
/usr/local/products/gcc/13.1.0/include/c++/13.1.0/bits/stl_uninitialized.h:1142:33,
[Bug libstdc++/109889] [13/14 Regression] Segfault in __run_exit_handlers since r13-5309-gc3c6c307792026
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109889
--- Comment #11 from Jonathan Wakely ---
The test looks like this:
#include
#include
int main()
{
typedef int value_type;
typedef __gnu_cxx::throw_allocator_random allocator_type;
try { __gnu_test::check_deallocate_null(); }
catch (std::logic_error&)
{
// Should throw logic_error to catch null erase.
}
return 0;
}
Where check_deallocate_null does:
template
bool
check_deallocate_null()
{
// Let's not core here...
Alloc a;
a.deallocate(0, 1);
a.deallocate(0, 10);
return true;
}
The first call to deallocate results in a call to:
// See if a particular address and allocation size has been saved.
inline map_alloc_type::iterator
check_allocated(void* p, size_t size)
{
map_alloc_type::iterator found = map_alloc().find(p);
if (found == map_alloc().end())
{
std::string error("annotate_base::check_allocated by value "
"null erase!\n");
log_to_string(error, make_entry(p, size));
std::__throw_logic_error(error.c_str());
}
This creates a debug mode iterator (found) and attaches it to the list of
iterators for the static map created here:
static map_alloc_type&
map_alloc()
{
static map_alloc_type _S_map;
return _S_map;
}
The call to map_alloc().end() then creates a second iterator, which is attached
to the list, and then detached when it goes out of scope.
Then we throw an exception, which is caught in main() and we return from
main().
The first iterator, found, was not destroyed, and so was not detached from the
list of active iterators. When the map gets destroyed it detaches the iterator
and calls its _M_reset() member to note that the iterator is now invalid
(because the map it refers to no logner exists). But that iterator only existed
on the stack of check_allocated, and calling _M_reset() on that stack address
corrupts the stack.
The found iterator should have been destroyed when the exception was thrown and
the stack was unwound.
[Bug modula2/109908] Delete from m2iso Strings is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109908 Gaius Mulley changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Gaius Mulley --- Closing now that the patch has been applied.
[Bug modula2/109908] Delete from m2iso Strings is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109908 --- Comment #3 from CVS Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:0a78bc26dadcb6f4c8b59b41858d70bb5432fadd commit r14-994-g0a78bc26dadcb6f4c8b59b41858d70bb5432fadd Author: Gaius Mulley Date: Fri May 19 12:18:53 2023 +0100 PR modula2/109908 Delete from m2iso Strings is broken This patch re-implements Strings.Delete and also supplies some runtime test code. gcc/m2/ChangeLog: PR modula2/109908 * gm2-libs-iso/Strings.mod (Delete): Re-implement. gcc/testsuite/ChangeLog: PR modula2/109908 * gm2/isolib/run/pass/testdelete.mod: New test. Signed-off-by: Gaius Mulley
[Bug modula2/109908] Delete from m2iso Strings is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109908 Gaius Mulley changed: What|Removed |Added CC||gaius at gcc dot gnu.org --- Comment #2 from Gaius Mulley --- Created attachment 55118 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55118=edit Proposed fix Here is a proposed fix for a re-implementation of Delete in Strings.mod (m2iso).
[Bug modula2/109908] Delete from m2iso Strings is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109908 Gaius Mulley changed: What|Removed |Added Last reconfirmed||2023-05-19 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Gaius Mulley --- Confirmed on gcc master.
[Bug modula2/109908] New: Delete from m2iso Strings is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109908 Bug ID: 109908 Summary: Delete from m2iso Strings is broken Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: gaius at gcc dot gnu.org Target Milestone: --- Created attachment 55117 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55117=edit test code for m2iso Strings.Delete As reported on the gm2 mailing list the m2iso Strings.Delete is broken for example the following test code fails: $ gm2 --version gm2 (GCC) 14.0.0 20230511 (experimental) Copyright (C) 2023 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ gm2 -g -fiso testdelete.mod $ ./a.out after Delete string one = '1' error: string one should be empty after delete error: string one have length 0 after delete after Delete string two = '221' error: string two should be '2' after delete error: string two have length 1 after delete after Delete string three = '233221' error: string three should be '23' after delete error: string three should have length 2 after delete after Delete string four = '' after Delete string large = '01234567890123456789' after Delete string large = '01234567890123456789' after Delete string three = '133221' error: string three should be '13' after delete error: string three should have length 2 after delete after Delete string four = '13'
[Bug tree-optimization/105776] Failure to recognize __builtin_mul_overflow pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105776 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Should be fixed now.
[Bug tree-optimization/101856] match_arith_overflow checks only mulv4_optab/umulv4_optab tables when smul_highpart_optab/umul_highpart_optab can produce decent code too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101856 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Jakub Jelinek --- Should be fixed now.
[Bug tree-optimization/101856] match_arith_overflow checks only mulv4_optab/umulv4_optab tables when smul_highpart_optab/umul_highpart_optab can produce decent code too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101856 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:62d08a67c83b4a089866c6d19e82d70ee5b8aed1 commit r14-992-g62d08a67c83b4a089866c6d19e82d70ee5b8aed1 Author: Jakub Jelinek Date: Fri May 19 12:57:31 2023 +0200 tree-ssa-math-opts: Pattern recognize hand written __builtin_mul_overflow_p with same unsigned types even when target just has highpart umul [PR101856] As can be seen on the following testcase, we pattern recognize it on i?86/x86_64 as return __builtin_mul_overflow_p (x, y, 0UL) and avoid that way the extra division, but don't do it e.g. on aarch64 or ppc64le, even when return __builtin_mul_overflow_p (x, y, 0UL); actually produces there better code. The reason for testing the presence of the optab handler is to make sure the generated code for it is short to ensure we don't actually pessimize code instead of optimizing it. But, we have one case that the internal-fn.cc .MUL_OVERFLOW expansion handles nicely, and that is when arguments/result is the same mode TYPE_UNSIGNED type, we only use IMAGPART_EXPR of it (i.e. __builtin_mul_overflow_p rather than __builtin_mul_overflow) and umul_highpart_optab supports the particular mode, in that case we emit comparison of the highpart umul result against zero. So, the following patch matches what we do in internal-fn.cc and also pattern matches __builtin_mul_overflow_p if 1) we only need the flag whether it overflowed (i.e. !use_seen) 2) it is unsigned (i.e. !cast_stmt) 3) umul_highpart is supported for the mode 2023-05-19 Jakub Jelinek PR tree-optimization/101856 * tree-ssa-math-opts.cc (match_arith_overflow): Pattern detect unsigned __builtin_mul_overflow_p even when umulv4_optab doesn't support it but umul_highpart_optab does. * gcc.dg/tree-ssa/pr101856.c: New test.
[Bug tree-optimization/105776] Failure to recognize __builtin_mul_overflow pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105776
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:bd0f2828432918a16e93d9e9021a5927143b8dde
commit r14-993-gbd0f2828432918a16e93d9e9021a5927143b8dde
Author: Jakub Jelinek
Date: Fri May 19 12:58:32 2023 +0200
tree-ssa-math-opts: Pattern recognize some further hand written forms of
signed __builtin_mul_overflow{,_p} [PR105776]
In the pattern recognition of signed __builtin_mul_overflow{,_p} we
check for result of unsigned division (which follows unsigned
multiplication) being equality compared against one of the multiplication's
argument (the one not used in the division) and check for the comparison
to be done against same precision cast of the argument (because
division's result is unsigned and the argument is signed).
But as shown in this PR, one can write it equally as comparison done in
the signed type, i.e. compare division's result cast to corresponding
signed type against the argument.
The following patch handles even those cases.
2023-05-19 Jakub Jelinek
PR tree-optimization/105776
* tree-ssa-math-opts.cc (arith_overflow_check_p): If cast_stmt is
non-NULL, allow division statement to have a cast as single imm use
rather than comparison/condition.
(match_arith_overflow): In that case remove the cast stmt in
addition
to the division statement.
* gcc.target/i386/pr105776.c: New test.
[Bug middle-end/109907] New: [avr] Missed optimization for bit extraction (uses shift instead of single bit-test)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109907
Bug ID: 109907
Summary: [avr] Missed optimization for bit extraction (uses
shift instead of single bit-test)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: gjl at gcc dot gnu.org
Target Milestone: ---
Created attachment 55116
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55116=edit
C test case.
The following missed optimization occurs with current v14 master and also with
older versions of the compiler:
$ avr-gcc ext.c -dumpbase "" -save-temps -dp -mmcu=atmega128 -c -Os
Functons like
uint8_t cset_32bit31 (uint32_t x)
{
return (x & (1ul << 31)) ? 1 : 0; // bloat
}
that extract a single bit might generate very expensive code like:
cset_32bit31:
movw r26,r24 ; 18 [c=4 l=1] *movhi/0
movw r24,r22 ; 19 [c=4 l=1] *movhi/0
lsl r27 ; 24 [c=16 l=4] *ashrsi3_const/3
sbc r24,r24
mov r25,r24
movw r26,r24
andi r24,lo8(1) ; 12 [c=4 l=1] andqi3/1
ret ; 22 [c=0 l=1] return
where the following 3 instructions would suffice. This is smaller, faster and
imposes no additioal register pressure:
bst r25,7; 16 [c=4 l=3] *extzv/4
clr r24
bld r24,0
What also would work is loading 0 or 1 depending on a single bit like:
LDI r24, 0 # R24 = 0
SBRC r25, 7 # Skip next instruction if R25.7 == 0.
LDI r24, 1 # R24 = 1
The bloat also occurs when the complement of the bit is extracted like in
uint8_t cset_32bit30_not (uint32_t x)
{
return (x & (1ul << 30)) ? 0 : 1; // bloat
}
cset_32bit30_not:
movw r26,r24 ; 19 [c=4 l=1] *movhi/0
movw r24,r22 ; 20 [c=4 l=1] *movhi/0
ldi r18,30 ; 25 [c=44 l=7] *lshrsi3_const/3
1:
lsr r27
ror r26
ror r25
ror r24
dec r18
brne 1b
ldi r18,1; 7 [c=32 l=2] xorsi3/2
eor r24,r18
andi r24,lo8(1) ; 13 [c=4 l=1] andqi3/1
ret ; 23 [c=0 l=1] return
This case is even worse because it's a loop of 30 single bit-shifts to extract
the bit. Again, skipping one instrauction depending on a bit was possible:
LDI r24, 1 # R24 = 1
SBRC r25, 6 # Skip next instruction if R25.7 == 0.
LDI r24, 0 # R24 = 0
or
LDI r24, 0 # R24 = 0
SBRS r25, 6 # Skip next instruction if R25.7 == 1.
LDI r24, 1 # R24 = 1
or extract one bit using the T-flag:
BST r25, 6 # SREG.T = R25.6
LDI r24, 0xff # R24 = 0xff
BLD r24, 0 # R24.0 = SREG.T
COM r24# R24 = R24 ^ 0xff
---
Configured with: --target=avr --disable-nls --with-dwarf2 --with-gnu-as
--with-gnu-ld --disable-shared --enable-languages=c,c++
gcc version 14.0.0 20230518 (experimental) (GCC)
[Bug libgomp/100160] MinGW-w64 g++ with libgomp and nvptx looks for libgomp-plugin-nvptx.so.1 instead of libgomp-plugin-nvptx-1.dll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100160 Thomas Schwinge changed: What|Removed |Added Last reconfirmed||2023-05-19 Keywords||openacc, openmp CC||tschwinge at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #3 from Thomas Schwinge --- (In reply to Brecht Sanders from comment #0) > Several issues when using GCC built against MinGW-w64 for Windows to compile > gomp test code (see attached minimal source code). > > Code compiles fine with: > g++ -c -o test.o test.cpp -fopenmp -foffload=nvptx-none > > Linking fails when done like this: > g++ -o test.exe test.o -lgomp > mkoffload: fatal error: either '-fopenacc' or '-fopenmp' must be set > compilation terminated. > lto-wrapper.exe: fatal error: > d:/prog/winlibs64-10.3.0/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/10.3. > 0//accel/nvptx-none/mkoffload.exe returned 1 exit status > compilation terminated. > d:/prog/winlibs64-10.3.0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../ > ../../../x86_64-w64-mingw32/bin/ld.exe: error: lto-wrapper failed > collect2.exe: error: ld returned 1 exit status Link with '-fopenacc' or '-fopenmp' instead of '-lgomp'. > Avoiding LTO seems to work around this and the following links fine: > g++ -o test.exe test.o -fno-lto -lgomp That's because "-fno-lto effectively disables offloading" (PR109819). > When executing test.exe the output starts with: > libgomp: while loading libgomp-plugin-nvptx.so.1: > "libgomp-plugin-nvptx.so.1": The specified module could not be found. > > The correct file on Windows is libgomp-plugin-nvptx-1.dll, not > libgomp-plugin-nvptx.so.1 ACK. GCC's OpenACC/OpenMP code offloading has only been implemented for/tested on GNU/Linux systems. Windows support can certainly be added, but it needs someone to do it.
[Bug other/109898] 'make install -j' sometimes corrupts 'dir' file for .info files due to parallel 'install-info' calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109898 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- But perhaps make install could $(MAKE) NOT_PARALLEL=1 non-parallel-install and the makefile could have ifeq ($(NOT_PARALLEL),1) .NOTPARALLEL: endif ?
[Bug other/109898] 'make install -j' sometimes corrupts 'dir' file for .info files due to parallel 'install-info' calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109898 --- Comment #4 from Jonathan Wakely --- That seems to be new in Make 4.4, because the manual for Make 4.3 says: '.NOTPARALLEL' If '.NOTPARALLEL' is mentioned as a target, then this invocation of 'make' will be run serially, even if the '-j' option is given. Any recursively invoked 'make' command will still run recipes in parallel (unless its makefile also contains this target). Any prerequisites on this target are ignored.
[Bug target/109650] avr-gcc incorrect code with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109650 --- Comment #9 from Georg-Johann Lay --- (In reply to Georg-Johann Lay from comment #8) > Created attachment 55115 [details] > Proposed patch. > > This is a proposed patch to fix this PR. Under review at Here actually: https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618976.html
[Bug target/109650] avr-gcc incorrect code with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109650 --- Comment #8 from Georg-Johann Lay --- Created attachment 55115 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55115=edit Proposed patch. This is a proposed patch to fix this PR. Under review at https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618973.html
[Bug libgomp/109904] linking with -static flag generates undefined references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109904 --- Comment #11 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:9abc830247e547186a48caadca43f5372eae1195 commit r14-991-g9abc830247e547186a48caadca43f5372eae1195 Author: Jakub Jelinek Date: Fri May 19 10:13:14 2023 +0200 libgomp: Fix up -static -fopenmp linking [PR109904] When an OpenMP program with target regions is linked statically, it fails to link on various arches (doesn't when using recent glibc because it has libdl stuff in libc), because libgomp.a(target.o) uses dlopen/dlsym/dlclose, but we aren't linking against -ldl (unless user asked for that). We already have libgomp.spec so that we can supply extra libraries to link against in the -static case, this patch adds -ldl to that if plugins are supported. 2023-05-19 Jakub Jelinek PR libgomp/109904 * configure.ac (link_gomp): Include also $DL_LIBS. * configure: Regenerated.
[Bug tree-optimization/109906] New: a rrotate (32-b) -> a lrotate b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109906
Bug ID: 109906
Summary: a rrotate (32-b) -> a lrotate b
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:
```
static inline
unsigned rotateright(unsigned x, int t)
{
if (t >= 32) __builtin_unreachable();
unsigned tl = x >> (t);
unsigned th = x << (32-t);
return tl | th;
}
unsigned rotateleft(unsigned t, int x)
{
return rotate (t, 32-x);
}
```
I would have assumed GCC would produce a rotate left for rotateleft but does
not currently.
[Bug rtl-optimization/91838] [8/9 Regression] incorrect use of shr and shrx to shift by 64, missed optimization of vector shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91838
Uroš Bizjak changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED|REOPENED
--- Comment #15 from Uroš Bizjak ---
This test returns different results, depending on whether V8QImode shift
pattern is present in target *.md files. For x86, if the following expander is
added:
+(define_expand "v8qi3"
+ [(set (match_operand:V8QI 0 "register_operand")
+ (any_shift:V8QI (match_operand:V8QI 1 "register_operand")
+ (match_operand:DI 2 "nonmemory_operand")))]
+ "TARGET_MMX_WITH_SSE"
+{
+ ix86_expand_vecop_qihi_partial (, operands[0],
+ operands[1], operands[2]);
+ DONE;
+})
then the tree optimizers produce:
V f (V x)
{
V _2;
[local count: 1073741824]:
_2 = x_1(D) >> 8;
return _2;
}
otherwise, without the named expander:
V f (V x)
{
[local count: 1073741824]:
return { 0, 0, 0, 0, 0, 0, 0, 0 };
}
[Bug tree-optimization/49695] conditional moves for stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49695 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Target Milestone|--- |12.0 Known to work||12.1.0 --- Comment #4 from Andrew Pinski --- On x86_64 with AVX2, and masked stores, GCC 12 is able to vectorize this loop just fine. On aarch64 with SVE2, GCC 12 is also able to vectorize the loop just fine too. I am just going to close as fixed.
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 49695, which changed state. Bug 49695 Summary: conditional moves for stores https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49695 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/70479] FMA is not reassociated causing x2 slowdown vs. ICC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70479 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Andrew Pinski --- This is a dup of bug 98350 which has a patch submitted against it recently. *** This bug has been marked as a duplicate of bug 98350 ***
[Bug tree-optimization/98350] Reassociation breaks FMA chains
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98350 Andrew Pinski changed: What|Removed |Added CC||kyukhin at gcc dot gnu.org --- Comment #5 from Andrew Pinski --- *** Bug 70479 has been marked as a duplicate of this bug. ***
[Bug driver/54163] Ignore -l[lib] option on PCH generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54163 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=45536 Component|pch |driver --- Comment #1 from Andrew Pinski --- This is basically the same issue as PR 45536 I think.
[Bug tree-optimization/106381] DCE depends on used programming language (C vs C++)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106381 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #2 from Xi Ruoyao --- Even if we change "unsigned" to "bool", it still does not get optimized with GCC 13. So generally should we try to solve 2-SAT if a boolean expression is a 2-SAT form?
[Bug driver/45536] PCH uses "-o file" even when there are other arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45536 Andrew Pinski changed: What|Removed |Added Keywords||accepts-invalid Component|pch |driver --- Comment #5 from Andrew Pinski --- This is a driver issue. The driver should reject the case where you have a .h file and a source file on the command line.
[Bug driver/33980] Precompiled header file not removed on error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33980 --- Comment #6 from Andrew Pinski --- Created attachment 55114 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55114=edit Patch which I am testing
