Order Inquiry
Dear Sir/Ma Please wants to place an order, kindly send your product list or catalogue to the below email (sa...@fuliejiatrading.com) -- Best Regards, Fernando Leite _Sales Import mailto:fernando-yvyra...@dagee.tw M +34 627 204 609 · Portable français +33 767 998 653 T +34 935 086 580 BARCELONA · Spain https://www.yvyra.es | https://www.exterpark.com -- Best Regards, Fernando Leite Sales Export
[Bug web/115183] New: GCCGO appears twice at https://gcc.gnu.org/onlinedocs/14.1.0/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115183 Bug ID: 115183 Summary: GCCGO appears twice at https://gcc.gnu.org/onlinedocs/14.1.0/ Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- https://gcc.gnu.org/onlinedocs/14.1.0/ spells twice “GCCGO 14.1 Manual (also in PDF or PostScript or an HTML tarball)”. Likewise at https://gcc.gnu.org/onlinedocs/13.1.0/, https://gcc.gnu.org/onlinedocs/13.2.0/ and https://gcc.gnu.org/onlinedocs/13.3.0/. https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Modules.html contains “they provideS a modular compilation system”.
[Bug target/115069] [14/15 regression] 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115069 Hongtao Liu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #23 from Hongtao Liu --- Fixed in GCC15 and GCC14.2
[Bug c++/104678] pointer to member cannot be passed as template argument after derived/base cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104678 Saurav Yadav <3y3p4tch at protonmail dot com> changed: What|Removed |Added CC||3y3p4tch at protonmail dot com --- Comment #2 from Saurav Yadav <3y3p4tch at protonmail dot com> --- Hi, I've been hitting this case as well. It's still present on trunk. Can someone take a look?
[Bug target/115069] [14/15 regression] 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115069 --- Comment #22 from Haochen Jiang --- Fixed in GCC14 and GCC15
[Bug target/115069] [14/15 regression] 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115069 --- Comment #21 from GCC Commits --- The releases/gcc-14 branch has been updated by Haochen Jiang : https://gcc.gnu.org/g:1ad5c9d524d8fa99773045e75da04ae958012085 commit r14-10229-g1ad5c9d524d8fa99773045e75da04ae958012085 Author: Haochen Jiang Date: Tue May 21 14:10:43 2024 +0800 i386: Disable ix86_expand_vecop_qihi2 when !TARGET_AVX512BW Since vpermq is really slow, we should avoid using it for permutation when vpmovwb is not available (needs AVX512BW) for ix86_expand_vecop_qihi2 and fall back to ix86_expand_vecop_qihi. gcc/ChangeLog: PR target/115069 * config/i386/i386-expand.cc (ix86_expand_vecop_qihi2): Do not enable the optimization when AVX512BW is not enabled. gcc/testsuite/ChangeLog: PR target/115069 * gcc.target/i386/pr115069.c: New.
[Bug target/115069] [14/15 regression] 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115069 --- Comment #20 from GCC Commits --- The master branch has been updated by Haochen Jiang : https://gcc.gnu.org/g:73a167cfa225d5ee7092d41596b9fea1719898ff commit r15-764-g73a167cfa225d5ee7092d41596b9fea1719898ff Author: Haochen Jiang Date: Tue May 21 14:10:43 2024 +0800 i386: Disable ix86_expand_vecop_qihi2 when !TARGET_AVX512BW Since vpermq is really slow, we should avoid using it for permutation when vpmovwb is not available (needs AVX512BW) for ix86_expand_vecop_qihi2 and fall back to ix86_expand_vecop_qihi. gcc/ChangeLog: PR target/115069 * config/i386/i386-expand.cc (ix86_expand_vecop_qihi2): Do not enable the optimization when AVX512BW is not enabled. gcc/testsuite/ChangeLog: PR target/115069 * gcc.target/i386/pr115069.c: New.
[Bug rtl-optimization/115182] New: [15 Regression] gcc.target/cris/pr93372-47.c at r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115182 Bug ID: 115182 Summary: [15 Regression] gcc.target/cris/pr93372-47.c at r15-518-g99b1daae18c095 Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: missed-optimization, testsuite-fail Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hp at gcc dot gnu.org CC: law at gcc dot gnu.org, pinskia at gcc dot gnu.org, rguenth at gcc dot gnu.org, unassigned at gcc dot gnu.org Depends on: 115144 Target Milestone: --- Target: cris-elf +++ This bug was initially created as a clone of Bug #115144 +++ This bug is only about the unfilled delay-slot that caused gcc.target/cris/pr93372-47.c to fail starting at r15-518-g99b1daae18c095; not about the incidental (possibly generic but at least unrelated to delay-slot-filling) performance regression I noticed. The bug seems to be due to a bug in reorg.cc or actually, in resource.cc. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115144 [Bug 115144] [15 Regression] 2% performance regression for some codes with r15-518-g99b1daae18c095
[Bug tree-optimization/115144] [15 Regression] 2% performance regression for some codes with r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115144
--- Comment #7 from Hans-Peter Nilsson ---
(In reply to Richard Biener from comment #6)
> For gcc.c-torture/execute/arith-rand-ll.c, does it help to replace the exit
> (0) call with a return 0 statement?
No. FWIW, it also doesn't help renaming and wrapping main to xmain
__attribute__ noipa.
> Looking at gcc.target/cris/pr93372-47.c what we do here is sink tot_bits +=
> n_bits into the else { of the in-loop conditional, in particular we sink
> it right before the exit conditional in the loop. That's exactly what
> we are supposed to do[...]
Yes; see previous comments. I'd say the changes in random_bitstring are no
longer "interesting". I've also analyzed the unfilled delay-slot signalled by
gcc.target/cris/pr93372-47.c to be because of a bug in that pass. (Not the
same, but events are amusingly parallel to the bug that made me add that
test-case.)
> Note that the sinking doesn't increase register lifetime (one of the reasons
> of the previous heuristic), esp. if we'd go one step further and sink
> to the start of the else { block rather than right before the exit
> conditional. But I'd guess that wouldn't help the delay-slot filling here?
Sorry, I don't follow here, but I'm going to let that be, as random_bitstring
isn't interesting (except regarding the bug).
> I've noticed CRIS doesn't support scheduling at all, so delay slot filling
> (where's that done?) relies purely on our "random" scheduling we do at
> RTL expansion time (via TER) and during GIMPLE optimization?
Delay-slot-filling is unrelated to scheduling. It's in reorg.cc with its own
horribly outdated dataflow analysis in resource.cc (but used to be shared).
> That said, I think sinking now works as expected.
In random_bitstring I agree, but there's fallout in main.
> I do want to play with
> sinking to the start of the else {, but without doing any lifetime analysis
> I fear that's going to be worse in the average as the current location
> at least ensures we're close to the first use of the DEF we sink.
Thank you in advance and for the look this far! I haven't looked closer at
what happens with later passes in main, but looking at the generated assembly
code, the "sinking" of a division has the eventual effect of increasing
register pressure; see the previously attached dumps.
[Bug target/115161] [15 Regression] highway-1.0.7 miscompilation of some SSE2 intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=11666 --- Comment #12 from Andrew Pinski --- So GCC behavior changed in 2003 to match more of what Java requires ...
[Bug target/115176] rbit pattern should use bitreverse rtl now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115176
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #2 from Xi Ruoyao ---
LoongArch currently has:
(define_insn "bitrev_4b"
[(set (match_operand:SI 0 "register_operand" "=r")
(unspec:SI [(match_operand:SI 1 "register_operand" "r")]
UNSPEC_BITREV_4B))]
""
"bitrev.4b\t%0,%1"
[(set_attr "type" "unknown")
(set_attr "mode" "SI")])
(define_insn "bitrev_8b"
[(set (match_operand:DI 0 "register_operand" "=r")
(unspec:DI [(match_operand:DI 1 "register_operand" "r")]
UNSPEC_BITREV_8B))]
""
"bitrev.8b\t%0,%1"
[(set_attr "type" "unknown")
(set_attr "mode" "DI")])
Maybe we can make them something like (subreg:DI (bitreverse:V8QI (subreg:QI
(match...) 0)) 0) instead. And LoongArch also has bitrev.{w/d} instructions
but GCC doesn't know them yet. I plan to add them after PR50481 is
implemented.
[Bug target/115161] [15 Regression] highway-1.0.7 miscompilation of some SSE2 intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161
--- Comment #11 from Hongtao Liu ---
(In reply to Jakub Jelinek from comment #10)
> Any of the floating point to integer intrinsics if they have out of range
> value (haven't checked whether floating point to unsigned intrinsic is a
> problem too or not).
> No matter if it is float or double (dunno if _Float16 too, or __bf16), and
> no matter if it is scalar intrinsic (ss/sd etc.) or vector and how many
> vector elements.
> But, this isn't really a regression, GCC has always behaved that way, the
> only thing that actually changed is that perhaps we can constant fold more
> than we used to do in the past.
> When not using intrinsics, IMNSHO we should keep doing what we did before.
Can we restrict them under flag_trapping_math?
.i.e
diff --git a/gcc/simplify-rtx.cc b/gcc/simplify-rtx.cc
index 53f54d1d392..b7a770dad60 100644
--- a/gcc/simplify-rtx.cc
+++ b/gcc/simplify-rtx.cc
@@ -2256,14 +2256,25 @@ simplify_const_unary_operation (enum rtx_code code,
machine_mode mode,
switch (code)
{
case FIX:
+ /* According to IEEE standard, for conversions from floating point to
+integer. When a NaN or infinite operand cannot be represented in
+the destination format and this cannot otherwise be indicated, the
+invalid operation exception shall be signaled. When a numeric
+operand would convert to an integer outside the range of the
+destination format, the invalid operation exception shall be
+signaled if this situation cannot otherwise be indicated. */
if (REAL_VALUE_ISNAN (*x))
- return const0_rtx;
+ return flag_trapping_math ? NULL_RTX : const0_rtx;
+
+ if (REAL_VALUE_ISINF (*x) && flag_trapping_math)
+ return NULL_RTX;
/* Test against the signed upper bound. */
wmax = wi::max_value (width, SIGNED);
real_from_integer (, VOIDmode, wmax, SIGNED);
if (real_less (, x))
- return immed_wide_int_const (wmax, mode);
+ return (flag_trapping_math
+ ? NULL_RTX : immed_wide_int_const (wmax, mode));
/* Test against the signed lower bound. */
wmin = wi::min_value (width, SIGNED);
@@ -2276,13 +2287,17 @@ simplify_const_unary_operation (enum rtx_code code,
machine_mode mode,
case UNSIGNED_FIX:
if (REAL_VALUE_ISNAN (*x) || REAL_VALUE_NEGATIVE (*x))
- return const0_rtx;
+ return flag_trapping_math ? NULL_RTX : const0_rtx;
+
+ if (REAL_VALUE_ISINF (*x) && flag_trapping_math)
+ return NULL_RTX;
/* Test against the unsigned upper bound. */
wmax = wi::max_value (width, UNSIGNED);
real_from_integer (, VOIDmode, wmax, UNSIGNED);
if (real_less (, x))
- return immed_wide_int_const (wmax, mode);
+ return (flag_trapping_math
+ ? NULL_RTX : immed_wide_int_const (wmax, mode));
return immed_wide_int_const (real_to_integer (x, , width),
[Bug c++/115181] [ICE] internal compiler error in invalid_tparm_referent_p, at cp/pt.cc:7274
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115181 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-05-22 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Confirmed. Not a regression, the ICE only happens with checking turned on.
[Bug target/99531] [11 Regression] Performance regression since gcc 9 (argument passing / register allocation)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99531 --- Comment #12 from Oleg Endo --- (In reply to Oleg Endo from comment #11) > > This caused PR 115148 I absolutely lack the imagination to see the connection of the change in #c6 and PR 115148. This is the change in the output code that results in the problem on SH: .LVL108: bt/s.L178 ! mov #-1,r0 !, @@ -1832,36 +1830,39 @@ .byte .L215-.L190 .byte .L181-.L190 .LVL109: - .align 1 -.L192: .LBE111: .LBE110: .loc 1 234 9 .loc 1 234 14 + .align 1 +.L287: + .align 1 +.L288: Any ideas or suggestions are appreciated.
[Bug libstdc++/79384] Clang doesn't like variant's std::visit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79384 Jonathan Wakely changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED --- Comment #1 from Jonathan Wakely --- I can't reproduce this now. It might have been the same as Bug 90397 which was fixed for 9.2, or it might have been related to https://bugs.llvm.org/show_bug.cgi?id=31852 The test case compiles fine with clang 17 and libstdc++ headers from GCC 7.5, 8.x, 9.2, or later.
[Bug c++/107800] confusing message with to_address in C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107800 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #12 from Jonathan Wakely --- Fixed for 13.4 and 14.2
[Bug libstdc++/108976] codecvt for Unicode allows surrogate code points
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108976 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #15 from Jonathan Wakely --- Fixed for 13.4 and 14.1
[Bug libstdc++/108976] codecvt for Unicode allows surrogate code points
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108976 --- Comment #14 from GCC Commits --- The releases/gcc-13 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:bd5e672303f5f777e8927a746d3ee42db21d871b commit r13-8788-gbd5e672303f5f777e8927a746d3ee42db21d871b Author: Dimitrij Mijoski Date: Thu Sep 28 21:38:11 2023 +0200 libstdc++: Fix handling of surrogate CP in codecvt [PR108976] This patch fixes the handling of surrogate code points in all standard facets for transcoding Unicode that are based on std::codecvt. Surrogate code points should always be treated as error. On the other hand surrogate code units can only appear in UTF-16 and only when they come in a proper pair. Additionally, it fixes a bug in std::codecvt_utf16::in() when odd number of bytes were given in the range [from, from_end), error was returned always. The last byte in such range does not form a full UTF-16 code unit and we can not make any decisions for error, instead partial should be returned. The testsuite for testing these facets was updated in the following order: 1. All functions that test codecvts that work with UTF-8 were refactored and made more generic so they accept codecvt that works with the char type char8_t. 2. The same functions were updated with new test cases for transcoding errors and now additionally test for surrogates, overlong UTF-8 sequences, code points out of the Unicode range, and more tests for missing leading and trailing code units. 3. New tests were added to test codecvt_utf16 in both of its variants, UTF-16 <-> UTF-32/UCS-4 and UTF-16 <-> UCS-2. libstdc++-v3/ChangeLog: PR libstdc++/108976 * src/c++11/codecvt.cc (read_utf8_code_point): Fix handing of surrogates in UTF-8. (ucs4_out): Fix handling of surrogates in UCS-4 -> UTF-8. (ucs4_in): Fix handling of range with odd number of bytes. (ucs4_out): Fix handling of surrogates in UCS-4 -> UTF-16. (ucs2_out): Fix handling of surrogates in UCS-2 -> UTF-16. (ucs2_in): Fix handling of range with odd number of bytes. (__codecvt_utf16_base::do_in): Likewise. (__codecvt_utf16_base::do_in): Likewise. (__codecvt_utf16_base::do_in): Likewise. * testsuite/22_locale/codecvt/codecvt_unicode.cc: Renames, add tests for codecvt_utf16 and codecvt_utf16. * testsuite/22_locale/codecvt/codecvt_unicode.h: Refactor UTF-8 testing functions for char8_t, add more test cases for errors, add testing functions for codecvt_utf16. * testsuite/22_locale/codecvt/codecvt_unicode_wchar_t.cc: Renames, add tests for codecvt_utf16. * testsuite/22_locale/codecvt/codecvt_utf16/79980.cc (test06): Fix test. * testsuite/22_locale/codecvt/codecvt_unicode_char8_t.cc: New test. (cherry picked from commit a8b9c32da787ea0bfbfc9118ac816fa7be4b1bc8)
[Bug c++/107800] confusing message with to_address in C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107800 --- Comment #11 from GCC Commits --- The releases/gcc-13 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:0a9df2c711f40e067cd57707d8e623136ae4efbe commit r13-8787-g0a9df2c711f40e067cd57707d8e623136ae4efbe Author: Jonathan Wakely Date: Tue May 21 13:16:33 2024 +0100 c++: Fix std dialect hint for std::to_address [PR107800] The correct dialect for std::to_address is cxx20 not cxx11. gcc/cp/ChangeLog: PR libstdc++/107800 * cxxapi-data.csv : Change dialect to cxx20. * std-name-hint.gperf: Regenerate. * std-name-hint.h: Regenerate. (cherry picked from commit 826a7d3d19d3ebf04e21d6f1c89eb341a36fb5d1)
[Bug c++/107800] confusing message with to_address in C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107800 --- Comment #10 from GCC Commits --- The releases/gcc-14 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:5b96d547ce71b8f03ddbc2318c64618110839e20 commit r14-10227-g5b96d547ce71b8f03ddbc2318c64618110839e20 Author: Jonathan Wakely Date: Tue May 21 13:16:33 2024 +0100 c++: Fix std dialect hint for std::to_address [PR107800] The correct dialect for std::to_address is cxx20 not cxx11. gcc/cp/ChangeLog: PR libstdc++/107800 * cxxapi-data.csv : Change dialect to cxx20. * std-name-hint.gperf: Regenerate. * std-name-hint.h: Regenerate. (cherry picked from commit 826a7d3d19d3ebf04e21d6f1c89eb341a36fb5d1)
[Bug sanitizer/115172] Invalid -fsanitize=bool sanitization of variable from named address space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115172 --- Comment #7 from Jakub Jelinek --- (In reply to Fedor Pchelkin from comment #6) > (In reply to Uroš Bizjak from comment #5) > > (In reply to Jakub Jelinek from comment #4) > > > Created attachment 58261 [details] > > > gcc15-pr115172.patch > > > > > > Full untested patch. > > > > I can confirm that this patch fixes boot for the kernel config from > > PR115172#43. > > Yep. I may confirm, too. Thanks for the prompt fix! > > If all goes well, is it expected to land in 14.2 and 13.4? If it is approved yes. 14.2 is expected likely in July this year, but 13.4 roughly in a year from now, as it just missed 13.3 (released today).
[Bug c++/107800] confusing message with to_address in C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107800 --- Comment #9 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:826a7d3d19d3ebf04e21d6f1c89eb341a36fb5d1 commit r15-760-g826a7d3d19d3ebf04e21d6f1c89eb341a36fb5d1 Author: Jonathan Wakely Date: Tue May 21 13:16:33 2024 +0100 c++: Fix std dialect hint for std::to_address [PR107800] The correct dialect for std::to_address is cxx20 not cxx11. gcc/cp/ChangeLog: PR libstdc++/107800 * cxxapi-data.csv : Change dialect to cxx20. * std-name-hint.gperf: Regenerate. * std-name-hint.h: Regenerate.
[Bug c++/115139] [14 Regression] Enum inside variadic template class can't define one of self with usage another value from this enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115139 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Patrick Palka --- Fixed for GCC 14.2, thanks for the bug report.
[Bug c++/115139] [14 Regression] Enum inside variadic template class can't define one of self with usage another value from this enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115139 --- Comment #3 from GCC Commits --- The releases/gcc-14 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:caf43cc9e5c0b3265b55e5a0dc77fc55e9618c77 commit r14-10226-gcaf43cc9e5c0b3265b55e5a0dc77fc55e9618c77 Author: Patrick Palka Date: Tue May 21 15:54:10 2024 -0400 c++: folding non-dep enumerator from current inst [PR115139] After the tsubst_copy removal r14-4796-g3e3d73ed5e85e7 GCC 14 ICEs during fold_non_dependent_expr for 'e1 | e2' below ultimately because we no longer exit early when substituting the CONST_DECLs for e1 and e2 with args=NULL_TREE and instead proceed to substitute the class context A (also with args=NULL_TREE) which ends up ICEing from tsubst_pack_expansion (due to processing_template_decl being cleared). Incidentally, the ICE went away on trunk ever since the tsubst_aggr_type removal r15-123-gf04dc89a991ddc since it changed the CONST_DECL case of tsubst_expr to use tsubst to substitute the context, which short circuits for empty args and so avoids the ICE. This patch fixes this ICE for GCC 14 by narrowly restoring the early exit for empty args that would've happened in tsubst_copy when substituting an enumerator CONST_DECL. We might as well apply this to trunk too, as a small optimization. PR c++/115139 gcc/cp/ChangeLog: * pt.cc (tsubst_expr) : Exit early if args is empty. gcc/testsuite/ChangeLog: * g++.dg/template/non-dependent33.C: New test. Reviewed-by: Marek Polacek Reviewed-by: Jason Merrill (cherry picked from commit f0c0bced62b9c728ed1e672747aa234d918da22c)
[Bug c++/115181] [ICE] internal compiler error in invalid_tparm_referent_p, at cp/pt.cc:7274
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115181 Andrew Pinski changed: What|Removed |Added Keywords||ice-checking --- Comment #1 from Andrew Pinski --- gcc_checking_assert (DECL_TINFO_P (decl) || DECL_FNAME_P (decl));
[Bug c++/115181] New: [ICE] internal compiler error in invalid_tparm_referent_p, at cp/pt.cc:7274
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115181
Bug ID: 115181
Summary: [ICE] internal compiler error in
invalid_tparm_referent_p, at cp/pt.cc:7274
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
Attempting to use an array literal as an NTTP.
```
template struct foo{};
foo<(int[]){1}> x;
```
[Bug c++/115139] [14 Regression] Enum inside variadic template class can't define one of self with usage another value from this enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115139 --- Comment #2 from GCC Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:f0c0bced62b9c728ed1e672747aa234d918da22c commit r15-759-gf0c0bced62b9c728ed1e672747aa234d918da22c Author: Patrick Palka Date: Tue May 21 15:54:10 2024 -0400 c++: folding non-dep enumerator from current inst [PR115139] After the tsubst_copy removal r14-4796-g3e3d73ed5e85e7 GCC 14 ICEs during fold_non_dependent_expr for 'e1 | e2' below ultimately because we no longer exit early when substituting the CONST_DECLs for e1 and e2 with args=NULL_TREE and instead proceed to substitute the class context A (also with args=NULL_TREE) which ends up ICEing from tsubst_pack_expansion (due to processing_template_decl being cleared). Incidentally, the ICE went away on trunk ever since the tsubst_aggr_type removal r15-123-gf04dc89a991ddc since it changed the CONST_DECL case of tsubst_expr to use tsubst to substitute the context, which short circuits for empty args and so avoids the ICE. This patch fixes this ICE for GCC 14 by narrowly restoring the early exit for empty args that would've happened in tsubst_copy when substituting an enumerator CONST_DECL. We might as well apply this to trunk too, as a small optimization. PR c++/115139 gcc/cp/ChangeLog: * pt.cc (tsubst_expr) : Exit early if args is empty. gcc/testsuite/ChangeLog: * g++.dg/template/non-dependent33.C: New test. Reviewed-by: Marek Polacek Reviewed-by: Jason Merrill
[Bug fortran/114827] Valgrind reports errors with class(*) assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827 --- Comment #14 from anlauf at gcc dot gnu.org --- Backporting to 13-branch requires backporting of r14-5931-gb247e917ff1332, see pr110415.
[Bug fortran/110415] (Re)allocation on assignment to allocatable polymorphic variable from allocatable polymorphic function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110415 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #6 from anlauf at gcc dot gnu.org --- (In reply to Andrew Jenner from comment #5) > Fixed on mainline and OG13. I will apply the commit to GCC 13 after the > grace period. This never happened... Are you still planning to do it?
[Bug fortran/115039] Statement function with inquiry refs rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115039 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |13.4 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from anlauf at gcc dot gnu.org --- Fixed in gcc-15, and backported to 14.2 and 13.4.
[Bug fortran/115039] Statement function with inquiry refs rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115039 --- Comment #4 from GCC Commits --- The releases/gcc-13 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:5ed32d00a7b408baa48d85e841740e73c8504d7a commit r13-8786-g5ed32d00a7b408baa48d85e841740e73c8504d7a Author: Harald Anlauf Date: Fri May 10 21:18:03 2024 +0200 Fortran: fix dependency checks for inquiry refs [PR115039] gcc/fortran/ChangeLog: PR fortran/115039 * expr.cc (gfc_traverse_expr): An inquiry ref does not constitute a dependency and cannot collide with a symbol. gcc/testsuite/ChangeLog: PR fortran/115039 * gfortran.dg/statement_function_5.f90: New test. (cherry picked from commit d4974fd22730014e337fd7ec2471945ba8afb00e)
[Bug fortran/115039] Statement function with inquiry refs rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115039 --- Comment #3 from GCC Commits --- The releases/gcc-14 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:edde60a53c7d4ee5a58c9835c8e1e1758ba636f7 commit r14-10225-gedde60a53c7d4ee5a58c9835c8e1e1758ba636f7 Author: Harald Anlauf Date: Fri May 10 21:18:03 2024 +0200 Fortran: fix dependency checks for inquiry refs [PR115039] gcc/fortran/ChangeLog: PR fortran/115039 * expr.cc (gfc_traverse_expr): An inquiry ref does not constitute a dependency and cannot collide with a symbol. gcc/testsuite/ChangeLog: PR fortran/115039 * gfortran.dg/statement_function_5.f90: New test. (cherry picked from commit d4974fd22730014e337fd7ec2471945ba8afb00e)
[Bug tree-optimization/115016] False positive -Wfree-nonheap-object using std::vector with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115016 gene at staubsaal dot de changed: What|Removed |Added CC||gene at staubsaal dot de --- Comment #1 from gene at staubsaal dot de --- *** Bug 115180 has been marked as a duplicate of this bug. ***
[Bug c++/115180] [regression] free-nonheap-object on std::vector usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115180 gene at staubsaal dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from gene at staubsaal dot de --- Duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115016 *** This bug has been marked as a duplicate of bug 115016 ***
[Bug c++/115180] New: [regression] free-nonheap-object on std::vector usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115180
Bug ID: 115180
Summary: [regression] free-nonheap-object on std::vector usage
Product: gcc
Version: 14.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gene at staubsaal dot de
Target Milestone: ---
Compiler: gcc (GCC) 14.1.1
Compile flags: -std=c++20 -O3 -Wfree-nonheap-object
The following code produces an "-Wfree-nonheap-object" warning, which doesn't
happen with '-O2' or using an older version of gcc.
This seems to be a false warning. (Or maybe even some false optimization going
on?)
```
#include
#include
// Since K+1 the returned vector has size() >= 1
inline auto f(size_t N, size_t K) {
return std::vector>(K+1, std::vector(N, 0));
}
// create another vector, but derive size from the previous vector
inline auto g(std::vector> const& v1) {
size_t const K = v1.size() - 1;
size_t const N = v1[0].size();
return std::vector>(K+1, std::vector(N, 0));
}
struct S {
std::vector v1;
std::vector v2;
// v1, v2always have the same length
};
auto h(size_t N, size_t K) {
assert(N>0);
assert(N >= K);
auto v1 = f(N, K);
auto v2 = g(v1);
auto ss = std::vector{};
for (size_t i{0}; i < v1.size(); ++i) {
ss.emplace_back(S{v1[i], {}});
}
for (auto& s : ss) {
s.v1.back() += 1;
}
return ss;
}
auto all = h(4, 3);
```
For convenience a link to godbolt: https://godbolt.org/z/dPj1YYf7x
[Bug target/105733] riscv: Poor codegen for large stack frames
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105733 --- Comment #5 from GCC Commits --- The master branch has been updated by Vineet Gupta : https://gcc.gnu.org/g:f9cfc192ed0127edb7e79818917dd2859fce4d44 commit r15-757-gf9cfc192ed0127edb7e79818917dd2859fce4d44 Author: Vineet Gupta Date: Mon May 13 11:46:03 2024 -0700 RISC-V: avoid LUI based const mat in prologue/epilogue expansion [PR/105733] If the constant used for stack offset can be expressed as sum of two S12 values, the constant need not be materialized (in a reg) and instead the two S12 bits can be added to instructions involved with frame pointer. This avoids burning a register and more importantly can often get down to be 2 insn vs. 3. The prev patches to generally avoid LUI based const materialization didn't fix this PR and need this directed fix in funcion prologue/epilogue expansion. This fix doesn't move the neddle for SPEC, at all, but it is still a win considering gcc generates one insn fewer than llvm for the test ;-) gcc-13.1 release | gcc 230823 | | |g6619b3d4c15c| This patch | clang/llvm - li t0,-4096 | lit0,-4096 | addi sp,sp,-2048 | addi sp,sp,-2048 addit0,t0,2016 | addi t0,t0,2032| add sp,sp,-16 | addi sp,sp,-32 li a4,4096 | add sp,sp,t0 | add a5,sp,a0| add a1,sp,16 add sp,sp,t0 | addi a5,sp,-2032 | sbzero,0(a5) | add a0,a0,a1 li a5,-4096 | add a0,a5,a0 | addi sp,sp,2032 | sb zero,0(a0) addia4,a4,-2032 | lit0, 4096 | addi sp,sp,32| addi sp,sp,2032 add a4,a4,a5 | sbzero,2032(a0) | ret | addi sp,sp,48 addia5,sp,16 | addi t0,t0,-2032 | | ret add a5,a4,a5 | add sp,sp,t0 | add a0,a5,a0 | ret | li t0,4096 | sd a5,8(sp) | sb zero,2032(a0)| addit0,t0,-2016 | add sp,sp,t0 | ret | gcc/ChangeLog: PR target/105733 * config/riscv/riscv.h: New macros for with aligned offsets. * config/riscv/riscv.cc (riscv_split_sum_of_two_s12): New function to split a sum of two s12 values into constituents. (riscv_expand_prologue): Handle offset being sum of two S12. (riscv_expand_epilogue): Ditto. * config/riscv/riscv-protos.h (riscv_split_sum_of_two_s12): New. gcc/testsuite/ChangeLog: * gcc.target/riscv/pr105733.c: New Test. * gcc.target/riscv/rvv/autovec/vls/spill-1.c: Adjust to not expect LUI 4096. * gcc.target/riscv/rvv/autovec/vls/spill-2.c: Ditto. * gcc.target/riscv/rvv/autovec/vls/spill-3.c: Ditto. * gcc.target/riscv/rvv/autovec/vls/spill-4.c: Ditto. * gcc.target/riscv/rvv/autovec/vls/spill-5.c: Ditto. * gcc.target/riscv/rvv/autovec/vls/spill-6.c: Ditto. * gcc.target/riscv/rvv/autovec/vls/spill-7.c: Ditto. Tested-by: Edwin Lu # pre-commit-CI #1568 Signed-off-by: Vineet Gupta
[Bug target/115118] [15 Regression] 5-13% slowdown of 470.lbm on zen4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115118 --- Comment #2 from Hans-Peter Nilsson --- (In reply to Hans-Peter Nilsson from comment #1) > Not-so-wild guess: r15-518, for similar-but-unrelated reasons to PR115144. Ah, dyscalculia strikes again. :) Please ignore.
[Bug target/115118] [15 Regression] 5-13% slowdown of 470.lbm on zen4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115118 Hans-Peter Nilsson changed: What|Removed |Added CC||hp at gcc dot gnu.org --- Comment #1 from Hans-Peter Nilsson --- Not-so-wild guess: r15-518, for similar-but-unrelated reasons to PR115144.
[Bug sanitizer/115172] Invalid -fsanitize=bool sanitization of variable from named address space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115172 --- Comment #6 from Fedor Pchelkin --- (In reply to Uroš Bizjak from comment #5) > (In reply to Jakub Jelinek from comment #4) > > Created attachment 58261 [details] > > gcc15-pr115172.patch > > > > Full untested patch. > > I can confirm that this patch fixes boot for the kernel config from > PR115172#43. Yep. I may confirm, too. Thanks for the prompt fix! If all goes well, is it expected to land in 14.2 and 13.4?
[Bug tree-optimization/115177] incorrect TBAA for derived types involving hardbool types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115177 Martin Uecker changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=115157 --- Comment #2 from Martin Uecker --- They are internally implemented as enums, so the issue is basically the same as PR115157. The types can alias via the langhook but TYPE_CANONICAL is different and so derived types can not alias. It needs to be fixed somewhere else though.
[Bug c++/115178] false positive computed goto jump warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115178 --- Comment #2 from foldy at rmki dot kfki.hu --- OK, thanks. I have millions of this warning in a huge generated file. How can I silence this check? -Wno-jump-misses-init works for C only.
[Bug c++/115179] Capture method address with inline asm in PIC mode?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115179 --- Comment #3 from Paul Robinson --- (In reply to Andrew Pinski from comment #2) > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105576#c10 gives an example of > how to use the new feature which was added for GCC 14. Thanks!
[Bug c++/115179] Capture method address with inline asm in PIC mode?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115179 --- Comment #2 from Andrew Pinski --- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105576#c10 gives an example of how to use the new feature which was added for GCC 14.
[Bug tree-optimization/115177] incorrect TBAA for derived types involving hardbool types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115177 Richard Biener changed: What|Removed |Added Version|unknown |15.0 CC||aoliva at gcc dot gnu.org --- Comment #1 from Richard Biener --- hardbool is an extension, so how it should behave is up to us? It probably makes sense to inter-operate with its base type though? You are testing for inter-operability between Base * and Hardbool * though. Alex, what was the idea here?
[Bug target/105576] x86: Support a machine constraint to get raw symbol name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105576 Andrew Pinski changed: What|Removed |Added CC||paul_robinson at playstation dot s ||ony.com --- Comment #13 from Andrew Pinski --- *** Bug 115179 has been marked as a duplicate of this bug. ***
[Bug c++/115179] Capture method address with inline asm in PIC mode?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115179 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup, already added. *** This bug has been marked as a duplicate of bug 105576 ***
[Bug c++/115179] New: Capture method address with inline asm in PIC mode?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115179 Bug ID: 115179 Summary: Capture method address with inline asm in PIC mode? Product: gcc Version: 11.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: paul_robinson at playstation dot sony.com Target Milestone: --- Is there a way to capture a method address in inline asm that works in -fPIC mode? Specifically I want to capture the address of a static method that's in a class that's local to a function. I'm able to do it in non-PIC mode but not PIC mode. ``` __asm__( ".pushsection .init_array" "\n" ".quad %c0" "\n" ".popsection" "\n" : : "p"(Helper::myfunc)); ``` I've run through all the combinations of %0, %a0, %c0 as the operand, and constraints i, m, o, p. %c0 with either i or p works in non-PIC mode, but nothing works in PIC mode. %0 with "p" compiles without error but prefixes the mangled name with $ which then can't be resolved at link time. Other combinations error out with "impossible constraint" or "invalid constraint", or suffix the mangled name with (%rip) which isn't much use in a .quad directive. I can't use __attribute__((constructor)) because it's not allowed on methods of local classes. (FTR, the documentation doesn't say that.) I can't allocate the pointer directly in a custom section because that doesn't always work (see bug 41091 and friends). (If that worked, I wouldn't need the .init_array hack.) Generating asm and editing it to remove the $ or (%rip) isn't practical. I'm hoping there's some combination of asm operands/constraints that isn't obvious from the docs that will work here.
[Bug c++/115178] false positive computed goto jump warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115178 --- Comment #1 from Andrew Pinski --- So for this warning GCC does not keep track of what the possible values can be done for the computed gotos. GCC thinks all labels which have their address can be taken are targets for a computed goto as a simple way to implement this warning (it is also done that way for the CFG later on too).
[Bug c++/41091] Using section attribute in c and c++ function causes section type conflict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41091 Paul Robinson changed: What|Removed |Added CC||paul_robinson at playstation dot s ||ony.com, ppalka at gcc dot gnu.org --- Comment #11 from Paul Robinson --- Given that the fix for bug 94342 by @ppalka should have addressed this for templates, is it the case that the only remaining issue is for inline functions? (See comment 6 for the test case.) Naively the comdat-related section naming issues would be the same.
[Bug target/115161] [15 Regression] highway-1.0.7 miscompilation of some SSE2 intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161 --- Comment #10 from Jakub Jelinek --- Any of the floating point to integer intrinsics if they have out of range value (haven't checked whether floating point to unsigned intrinsic is a problem too or not). No matter if it is float or double (dunno if _Float16 too, or __bf16), and no matter if it is scalar intrinsic (ss/sd etc.) or vector and how many vector elements. But, this isn't really a regression, GCC has always behaved that way, the only thing that actually changed is that perhaps we can constant fold more than we used to do in the past. When not using intrinsics, IMNSHO we should keep doing what we did before.
[Bug c++/115178] New: false positive computed goto jump warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115178
Bug ID: 115178
Summary: false positive computed goto jump warning
Product: gcc
Version: 14.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: foldy at rmki dot kfki.hu
Target Milestone: ---
> cat test.cc
int test(int i)
{
int res=0;
{ const void* labels1[2]={&, &};
goto *labels1[i&1];
l1: res=1;
l2: res=2;
}
{ const void* labels2[2]={&, &};
goto *labels2[i&1];
l3: res=3;
l4: res=4;
}
return res;
}
> g++-14 -c test.cc
test.cc: In function ‘int test(int)’:
test.cc:6:5: warning: jump to label ‘l1’
6 | l1: res=1;
| ^~
test.cc:10:22: note: as a possible target of computed goto
10 | goto *labels2[i&1];
| ^
test.cc:4:17: note: skips initialization of ‘const void* labels1 [2]’
4 | { const void* labels1[2]={&, &};
| ^~~
test.cc:7:5: warning: jump to label ‘l2’
7 | l2: res=2;
| ^~
test.cc:10:22: note: as a possible target of computed goto
10 | goto *labels2[i&1];
| ^
test.cc:4:17: note: skips initialization of ‘const void* labels1 [2]’
4 | { const void* labels1[2]={&, &};
| ^~~
l1/l2 are not possible targets from labels2
[Bug middle-end/115170] __cxa_atexit@plt even if -fno-plt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115170 Andrew Pinski changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |INVALID --- Comment #7 from Andrew Pinski --- (In reply to Cristian Rodríguez from comment #6) > I found it in executable made with current GCC HEAD on x86_64.. > > It is sufficient to demonstrate with the example code here > > https://en.cppreference.com/w/c/program/atexit > > ggcc-15 -march=native -Wall -Wextra -O2 -g -fPIE (or -fPIC) -fhardened > -fno-plt example.c > > > 1172: call 1040 <__cxa_finalize@plt> > 11fd: jmp1050 <__cxa_atexit@plt> That is coming from already compiled code in crt*.o. __cxa_finalize is from __do_global_dtors_aux in crtstuff.c from libgcc. This is not from newly compiled code that you used -fno-plt with.
[Bug target/115161] [15 Regression] highway-1.0.7 miscompilation of some SSE2 intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161 --- Comment #9 from Jakub Jelinek --- In that case we should separate *.md patterns which are used for C conversions from the patterns used by the intrinsics, keep using what we are right now for the former and either use UNSPEC (the quickest but not best code generating variant) or something more complex. If UNSPEC is used, we could get some constant folding back by adding gimple_fold handling for those and the like of __builtin_ia32_psubusb128 or __builtin_ia32_pminub128. For __builtin_ia32_cvttps2dq etc. obviously the folding should either punt folding if some argument is out of range or fold those to what the hw does.
[Bug target/115161] [15 Regression] highway-1.0.7 miscompilation of some SSE2 intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161
--- Comment #8 from Sergei Trofimovich ---
Thank you, Jakub!
> The reason the testcase FAILs is the same as in the other PRs, it is trying
> to convert {0x0.8p+33f, 0x0.8p+33f, 0x0.8p+33f, 0x0.8p+33f} V4SFmode vector
> to V4SImode, and because the backend sees the constant operand of the fix, it
> folds it to the unspecified value as with scalar conversion.
To be super-clear: the problem is the out-of-range value, not just any
V4SFmode->V4SImode, right?
Specifically, float32{INT32_MAX} -> int32_t should be fine, right?
I was trying to extract the following example (and likely failed):
It tries very hard not to pass anything outside float32{INT32_MAX} to
(a different) `PromoteTo()` at the end of the function from
https://github.com/google/highway/blob/2270e77d0d0ccc1d6bc7393f0ebb0b6352ddfd00/hwy/ops/x86_128-inl.h#L10275
HWY_API VFromD PromoteTo(D di64, VFromD> v) {
const Rebind di32;
const RebindToFloat df32;
const RebindToUnsigned du32;
const Repartition du32_as_du8;
const auto exponent_adj = BitCast(
du32,
Min(SaturatedSub(BitCast(du32_as_du8, ShiftRight<23>(BitCast(du32, v))),
BitCast(du32_as_du8, Set(du32, uint32_t{157}))),
BitCast(du32_as_du8, Set(du32, uint32_t{32};
const auto adj_v =
BitCast(df32, BitCast(du32, v) - ShiftLeft<23>(exponent_adj));
const auto f32_to_i32_result = ConvertTo(di32, adj_v);
const auto lo64_or_mask = PromoteTo(
di64,
BitCast(du32, VecFromMask(di32, Eq(f32_to_i32_result,
Set(di32, LimitsMax());
return Or(PromoteTo(di64, BitCast(di32, f32_to_i32_result))
<< PromoteTo(di64, exponent_adj),
lo64_or_mask);
}
Specifically `const auto f32_to_i32_result = ConvertTo(di32, adj_v);` hits
overflow
and the masking below should account for that (I tried to preserve masking in
the original sample):
https://github.com/google/highway/blob/2270e77d0d0ccc1d6bc7393f0ebb0b6352ddfd00/hwy/ops/x86_128-inl.h#L10870
template
HWY_API VFromD ConvertTo(D di, VFromD> v) {
const RebindToFloat df;
// See comment at the first occurrence of "IfThenElse(overflow,".
const MFromD overflow = RebindMask(di, Ge(v, Set(df, 2147483648.0f)));
return IfThenElse(overflow, Set(di, LimitsMax()),
ConvertInRangeTo(di, v));
}
Is it obvious from the minimized C code where I got it into overflow condition?
Or constant folding propagates through masks here?
I'll try to re-minimize it again.
[Bug other/115174] New test case gcc.dg/lto/pr113359-2 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115174 Martin Jambor changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from Martin Jambor --- Should be fixed with r13-8785-gc827f46d8652d7 Sorry for forgetting to backport the testcase fix.
[Bug testsuite/114662] [14 regression] new test case c_lto_pr113359-2 from r14-9841-g1e3312a25a7b34 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114662 --- Comment #6 from GCC Commits --- The releases/gcc-13 branch has been updated by Martin Jambor : https://gcc.gnu.org/g:c827f46d8652d7a089e614302a4cffb6b192284d commit r13-8785-gc827f46d8652d7a089e614302a4cffb6b192284d Author: Kewen Lin Date: Wed Apr 10 02:59:43 2024 -0500 testsuite: Adjust pr113359-2_*.c with unsigned long long [PR114662] pr113359-2_*.c define a struct having unsigned long type members ay and az which have 4 bytes size at -m32, while the related constants CL1 and CL2 used for equality check are always 8 bytes, it makes compiler consider the below 69 if (a.ay != CL1) 70 __builtin_abort (); always to abort and optimize away the following call to getb, which leads to the expected wpa dumping on "Semantic equality" missing. This patch is to modify the types with unsigned long long accordingly. PR testsuite/114662 gcc/testsuite/ChangeLog: * gcc.dg/lto/pr113359-2_0.c: Use unsigned long long instead of unsigned long. * gcc.dg/lto/pr113359-2_1.c: Likewise. (cherry picked from commit 4923ed49b93352bcf9e43cafac38345e4a54c3f8)
[Bug middle-end/115170] __cxa_atexit@plt even if -fno-plt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115170 Cristian Rodríguez changed: What|Removed |Added Resolution|MOVED |--- Status|RESOLVED|REOPENED --- Comment #6 from Cristian Rodríguez --- I found it in executable made with current GCC HEAD on x86_64.. It is sufficient to demonstrate with the example code here https://en.cppreference.com/w/c/program/atexit ggcc-15 -march=native -Wall -Wextra -O2 -g -fPIE (or -fPIC) -fhardened -fno-plt example.c 1172: call 1040 <__cxa_finalize@plt> 11fd: jmp1050 <__cxa_atexit@plt>
[Bug target/115161] [15 Regression] highway-1.0.7 miscompilation of some SSE2 intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #7 from Alexander Monakov --- > the question is if the intrinsic must behave the same or if those invalid > conversions are still unspecified. I'd say it must match, the whole point of intrinsics is offering portable interface to specific instructions. If I wanted a conversion with C semantics I wouldn't need an intrinsic in the first place, it's more clearly expressed in plain C.
[Bug middle-end/50481] builtin to reverse the bit order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50481 --- Comment #12 from Andrew Pinski --- Also will add an internal function which will be used for vectorization.
[Bug middle-end/50481] builtin to reverse the bit order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50481
--- Comment #11 from Andrew Pinski ---
The builtins I am going to implement to be similar to clang:
__builtin_bitreverse{8,16,32,64,g}
The g one is not part of clang but will be used for _BitInt types.
[Bug fortran/115150] [12/13/14 Regression] SHAPE of zero-sized array yields a negative value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115150 Paul Thomas changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Summary|[12/13/14/15 Regression]|[12/13/14 Regression] SHAPE |SHAPE of zero-sized array |of zero-sized array yields |yields a negative value |a negative value CC||burnus at gcc dot gnu.org, ||pault at gcc dot gnu.org Last reconfirmed||2024-05-21 --- Comment #3 from Paul Thomas --- (In reply to GCC Commits from comment #2) > The master branch has been updated by Tobias Burnus : > > https://gcc.gnu.org/g:b701306a9b38bd74cdc26c7ece5add22f2203b56 > > commit r15-658-gb701306a9b38bd74cdc26c7ece5add22f2203b56 > Author: Tobias Burnus > Date: Mon May 20 08:34:48 2024 +0200 > > Fortran: Fix SHAPE for zero-size arrays > > PR fortran/115150 > > gcc/fortran/ChangeLog: > > * trans-intrinsic.cc (gfc_conv_intrinsic_bound): Fix SHAPE > for zero-size arrays > > gcc/testsuite/ChangeLog: > > * gfortran.dg/shape_12.f90: New test. Hi Tobias, Good call! I take it that you will backport? Thanks Paul
[Bug middle-end/50481] builtin to reverse the bit order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50481 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Keywords||missed-optimization Status|NEW |ASSIGNED --- Comment #10 from Andrew Pinski --- I am going to implement this. and add an optab too.
[Bug tree-optimization/115177] New: incorrect TBAA for derived types involving hardbool types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115177
Bug ID: 115177
Summary: incorrect TBAA for derived types involving hardbool
types
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: muecker at gwdg dot de
Target Milestone: ---
This is another example where type compatibility in the C FE disagrees with
TBAA. Not sure whether those types should be made incompatible instead.
https://godbolt.org/z/e6nYzWMzx
typedef int A;
typedef int __attribute__ (( hardbool(0, 1) )) B;
_Static_assert(_Generic((A*){ 0 }, B*: 1), "");
void* foo(void* a, void *b, A *c, B *d)
{
*(A**)a = c;
*(B**)b = d;
return *(A**)a;
}
int main()
{
A *a, b, c;
if ( != (A*)foo(, , , ))
__builtin_abort();
}
[Bug target/115176] rbit pattern should use bitreverse rtl now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115176 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2024-05-21 --- Comment #1 from Andrew Pinski --- that is from aarch64-simd.md: ``` (define_insn "aarch64_rbit" [(set (match_operand:VB 0 "register_operand" "=w") (unspec:VB [(match_operand:VB 1 "register_operand" "w")] UNSPEC_RBIT))] "TARGET_SIMD" "rbit\\t%0., %1." [(set_attr "type" "neon_rbit")] ) ``` >From aarch64.md: ``` (define_insn "@aarch64_rbit" [(set (match_operand:GPI 0 "register_operand" "=r") (unspec:GPI [(match_operand:GPI 1 "register_operand" "r")] UNSPEC_RBIT))] "" "rbit\\t%0, %1" [(set_attr "type" "rbit")] ) ```
[Bug target/115176] New: rbit pattern should use bitreverse rtl now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115176 Bug ID: 115176 Summary: rbit pattern should use bitreverse rtl now Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: internal-improvement Severity: enhancement Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- While looking at some code I noticed that it uses clang's __builtin_bitreverse8 builtin and looking at the aarch64 backend, I noticed the rbit patterns don't use bitreverse but still an UNSPEC. We should be able to change the pattern to use the rtl now.
[Bug target/115161] [15 Regression] highway-1.0.7 miscompilation of some SSE2 intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161 --- Comment #6 from Jakub Jelinek --- The standard GCC behavior is that out of range floating conversions to integers result in signed integer maximum if the floating point value sign is clear and signed integer minimum otherwise (including infinities/nans).
[Bug debug/111409] Invalid .debug_macro.dwo macro information for split DWARF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111409 Tom de Vries changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #6 from Tom de Vries --- *** Bug 87472 has been marked as a duplicate of this bug. ***
[Bug debug/87472] Unknown macro opcode with -gsplit-dwarf -g3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87472 Tom de Vries changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||vries at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #4 from Tom de Vries --- Duplicate. *** This bug has been marked as a duplicate of bug 111409 ***
[Bug debug/111409] Invalid .debug_macro.dwo macro information for split DWARF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111409 Tom de Vries changed: What|Removed |Added CC||vries at gcc dot gnu.org Target Milestone|--- |14.0 --- Comment #5 from Tom de Vries --- Fixed in 14.1 release. Corresponding target milestone not available, so using 14.0.
[Bug target/115161] [15 Regression] highway-1.0.7 miscompilation of some SSE2 intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161
--- Comment #5 from Jakub Jelinek ---
Trying
#include
int
main ()
{
float f = 0x0.8p+33f;
float __attribute__((vector_size (16))) vf = { 0x0.8p+33f, 0x0.8p+33f,
0x0.8p+33f, 0x0.8p+33f };
int a = f;
int __attribute__((vector_size (16))) vi = __builtin_convertvector (vf, int
__attribute__((vector_size (16;
int __attribute__((vector_size (16))) vi2 = (int __attribute__((vector_size
(16 _mm_cvttps_epi32 ((__m128) vf);
__builtin_printf ("%d\n", a);
__builtin_printf ("{%d, %d, %d, %d}\n", vi[0], vi[1], vi[2], vi[3]);
__builtin_printf ("{%d, %d, %d, %d}\n", vi2[0], vi2[1], vi2[2], vi2[3]);
}
with gcc and clang both with -O0 and -O2, this prints
-2147483648
{-2147483648, -2147483648, -2147483648, -2147483648}
{-2147483648, -2147483648, -2147483648, -2147483648}
with both compilers at -O0, clang at -O2 prints
-1720305736
{8524448, 0, 1, 135169}
{-2147483648, -2147483648, -2147483648, -2147483648}
i.e. complete garbage for the non-intrinsic cases, but what the HW does for the
intrinsic cases, while gcc at -O2 prints
2147483647
{2147483647, 2147483647, 2147483647, 2147483647}
{2147483647, 2147483647, 2147483647, 2147483647}
i.e. treats intrinsics and non-intrinsics the same.
GCC behaves this way consistently since GCC 9 (before __builtin_convertvector
hasn't been supported), but if the vi related lines are commented out, even GCC
4.7 works that way.
[Bug c++/109958] [11/12/13/14/15 Regression] ICE: in build_ptrmem_type, at cp/decl.cc:11066 taking the address of bound static member function brought into derived class by using-declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109958 Simon Martin changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |simartin at gcc dot gnu.org --- Comment #5 from Simon Martin --- Working on it
[Bug target/115161] [15 Regression] highway-1.0.7 miscompilation of some SSE2 intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
(In reply to Sergei Trofimovich from comment #3)
> Looking at -O2's bug.cc.265t.optimized tree optimizations come up with
> unfolded saturated sub8:
>
> _12 = __builtin_ia32_psubusb128 ({ -65, 0, 0, 0, -65, 0, 0, 0, -65, 0, 0,
> 0, -65, 0, 0, 0 }, { -99, 0, 0, 0, -99, 0, 0, 0, -99, 0, 0, 0, -99, 0, 0, 0
> });
> _13 = __builtin_ia32_pminub128 (_12, { 32, 0, 0, 0, 32, 0, 0, 0, 32, 0, 0,
> 0, 32, 0, 0, 0 });
> ...
>
>
> bug.cc.272r.cse1 still has that subtraction:
>
> 5: r119:V16QI=[`*.LC0']
> REG_EQUAL const_vector
> 6: r120:V16QI=[`*.LC1']
> REG_EQUAL const_vector
> 7: r118:V16QI=us_minus(r119:V16QI,r120:V16QI)
>
> bug.cc.273r.fwprop1 does not anymore:
>
> 3: NOTE_INSN_BASIC_BLOCK 2
> 2: NOTE_INSN_FUNCTION_BEG
> 9: r122:V16QI=[`*.LC2']
> REG_EQUAL const_vector
>13: r123:V4SI=r122:V16QI#0<<0x17
> REG_EQUAL const_vector
>16: r128:SI=0x5f80
>15: r127:V4SI=vec_duplicate(r128:SI)
>
> Could it be that constant folder "forgot" to generate anything for
> unsupported saturated-sub instead of leaving it as is?
No. It is normal constant folding on RTL (not done on GIMPLE because
the i386 backend doesn't try to gimple fold __builtin_ia32_psubusb128
or __builtin_ia32_psubusb128). 0xbf - 0x9d is 0x22, so the us_minus works
actually in this case exactly like minus and because 0x20 is smaller than that,
the minimum is a vector with 0x20 elements (plus min (0 - 0, 0) = 0 elements).
The reason the testcase FAILs is the same as in the other PRs, it is trying to
convert
{0x0.8p+33f, 0x0.8p+33f, 0x0.8p+33f, 0x0.8p+33f}
V4SFmode vector to V4SImode, and because the backend sees the constant operand
of the
fix, it folds it to the unspecified value as with scalar conversion.
Consider:
int
main ()
{
volatile float f = 0x0.8p+33f;
volatile float __attribute__((vector_size (16))) vf = { 0x0.8p+33f,
0x0.8p+33f, 0x0.8p+33f, 0x0.8p+33f };
int a = f;
int __attribute__((vector_size (16))) vi = __builtin_convertvector (vf, int
__attribute__((vector_size (16;
__builtin_printf ("%d\n", a);
__builtin_printf ("{%d, %d, %d, %d}\n", vi[0], vi[1], vi[2], vi[3]);
}
This prints
-2147483648
{-2147483648, -2147483648, -2147483648, -2147483648}
at -O0 or -O2, but with -O2 -Dvolatile= prints
2147483647
{2147483647, 2147483647, 2147483647, 2147483647}
instead.
Either is IMHO fine, the C standard doesn't specify what should be the result
of the conversion.
Now, whether for _mm_cvttps_epi32 etc. such cases are also unspecified or not
is debatable. The Intel spec obviously specifies what the CPU instructions do
even in those otherwise unspecified cases, the question is if the intrinsic
must behave the same or if those invalid conversions are still unspecified.
If they'd be well defined when using the intrinsics, arguably the backend
shouldn't use FIX RTL but some UNSPEC, or should use the FIX RTL conditionally
(if_then_else:SI (argument_is_in_bounds) (fix arg) (const_int 0x800)).
[Bug c++/115159] internal compiler error: in nothrow_spec_p, at cp/except.cc:1206 when using modules and QCoreApplication
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115159
Patrick Palka changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|2024-05-19 00:00:00 |2024-05-21
Status|UNCONFIRMED |NEW
CC||ppalka at gcc dot gnu.org
--- Comment #3 from Patrick Palka ---
Confirmed, thanks for the reproducer.
Reduced:
$ cat 115159_a.H
struct QDebug;
template void f(T);
template struct QList {
QDebug operator<(QList ) noexcept(noexcept(f(other)));
QDebug operator>(QList ) noexcept(noexcept(f(other)));
};
struct QObjectData {
QList children;
};
struct QIODevice {
QObjectData d_ptr;
};
struct QDebug {
QDebug(QIODevice);
};
$ cat 115159_b.C
import "115159_a.H";
$ g++ -fno-module-lazy -fmodules-ts -std=c++20 115159_{a.H,b.C}
115159_b.C:1:22: internal compiler error: in nothrow_spec_p, at
cp/except.cc:1202
[Bug tree-optimization/115175] [15 Regression] GCC fails to bootstrap with --with-build-config='bootstrap-O3 bootstrap-lto' at r15-698-g38d1761c0c94b7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115175
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-checking,
||ice-on-valid-code
--- Comment #1 from Andrew Pinski ---
// We sometimes get compatible types copied from operands, make sure
// the correct type is being returned.
if (name && TREE_TYPE (name) != r.type ())
{
gcc_checking_assert (range_compatible_p (r.type (), TREE_TYPE (name)));
range_cast (r, TREE_TYPE (name));
}
[Bug tree-optimization/115175] [15 Regression] GCC fails to bootstrap with --with-build-config='bootstrap-O3 bootstrap-lto' at r15-698-g38d1761c0c94b7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115175 Andrew Pinski changed: What|Removed |Added Keywords||build Target Milestone|--- |15.0 Summary|GCC fails to bootstrap with |[15 Regression] GCC fails |--with-build-config='bootst |to bootstrap with |rap-O3 bootstrap-lto' at|--with-build-config='bootst |r15-698-g38d1761c0c94b7 |rap-O3 bootstrap-lto' at ||r15-698-g38d1761c0c94b7
[Bug tree-optimization/115175] New: GCC fails to bootstrap with --with-build-config='bootstrap-O3 bootstrap-lto' at r15-698-g38d1761c0c94b7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115175 Bug ID: 115175 Summary: GCC fails to bootstrap with --with-build-config='bootstrap-O3 bootstrap-lto' at r15-698-g38d1761c0c94b7 Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: arsen at gcc dot gnu.org Target Milestone: --- Created attachment 58264 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58264=edit 'make' output, after a make -k GCC trunk currently (r15-698-g38d1761c0c94b7) fails to build with O3 and LTO due to an ICE in gimple-range-fold.cc. configure line: ../gcc/configure --enable-languages=ada --enable-bootstrap '--with-build-config=bootstrap-O3 bootstrap-lto' currently trying without bootstrap-O3
[Bug tree-optimization/115143] [11/12 Regression] tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115143 Andrew Pinski changed: What|Removed |Added Known to fail||13.3.0 Summary|[11/12/13 Regression] tree |[11/12 Regression] tree |check: expected class |check: expected class |'type', have 'exceptional' |'type', have 'exceptional' |(error_mark) in |(error_mark) in |useless_type_conversion_p, |useless_type_conversion_p, |at gimple-expr.cc:85|at gimple-expr.cc:85 Target Milestone|13.4|11.5 Known to work||13.3.1 --- Comment #16 from Andrew Pinski --- Fixed on the GCC 13 branch too. Backporting further requires removing the hunk that handles diamond bbs as that was not in 12 or 11. I will handle that tomorrow.
[Bug tree-optimization/115143] [11/12/13 Regression] tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115143 --- Comment #15 from GCC Commits --- The releases/gcc-13 branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:3f6a42510a1bd4b004ed70ac44cdad2770b732a8 commit r13-8784-g3f6a42510a1bd4b004ed70ac44cdad2770b732a8 Author: Andrew Pinski Date: Sat May 18 11:55:58 2024 -0700 PHIOPT: Don't transform minmax if middle bb contains a phi [PR115143] The problem here is even if last_and_only_stmt returns a statement, the bb might still contain a phi node which defines a ssa name which is used in that statement so we need to add a check to make sure that the phi nodes are empty for the middle bbs in both the `CMP?MINMAX:MINMAX` case and the `CMP?MINMAX:B` cases. Bootstrapped and tested on x86_64_linux-gnu with no regressions. PR tree-optimization/115143 gcc/ChangeLog: * tree-ssa-phiopt.cc (minmax_replacement): Check for empty phi nodes for middle bbs for the case where middle bb is not empty. gcc/testsuite/ChangeLog: * gcc.c-torture/compile/pr115143-1.c: New test. * gcc.c-torture/compile/pr115143-2.c: New test. * gcc.c-torture/compile/pr115143-3.c: New test. Signed-off-by: Andrew Pinski (cherry picked from commit 9ff8f041331ef8b56007fb3c4d41d76f9850010d)
[Bug tree-optimization/115154] [13/14/15 Regression] wrong code at optimization levels -O2, -O3, -Os since r13-7434-g682bbd364708fe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115154 Andrew Pinski changed: What|Removed |Added Known to fail||14.1.0 Known to work||13.3.1, 14.1.1, 15.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #19 from Andrew Pinski --- Fixed on all branches, sadly it barely didn't make it for the just released GCC 13.3.0.
[Bug tree-optimization/115154] [13/14/15 Regression] wrong code at optimization levels -O2, -O3, -Os since r13-7434-g682bbd364708fe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115154 --- Comment #18 from GCC Commits --- The releases/gcc-13 branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:d6cf49eaf5ac237c57785dce42c89deac911affa commit r13-8783-gd6cf49eaf5ac237c57785dce42c89deac911affa Author: Andrew Pinski Date: Mon May 20 00:16:40 2024 -0700 match: Disable `(type)zero_one_valuep*CST` for 1bit signed types [PR115154] The problem here is the pattern added in r13-1162-g9991d84d2a8435 assumes that it is well defined to multiply zero_one_valuep by the truncated converted integer constant. It is well defined for all types except for signed 1bit types. Where `a * -1` is produced which is undefined/ So disable this pattern for 1bit signed types. Note the pattern added in r14-3432-gddd64a6ec3b38e is able to workaround the undefinedness except when `-fsanitize=undefined` is turned on, this is why I added a testcase for that. Bootstrapped and tested on x86_64-linux-gnu with no regressions. PR tree-optimization/115154 gcc/ChangeLog: * match.pd (convert (mult zero_one_valued_p@1 INTEGER_CST@2)): Disable for 1bit signed types. gcc/testsuite/ChangeLog: * c-c++-common/ubsan/signed1bitfield-1.c: New test. * gcc.c-torture/execute/signed1bitfield-1.c: New test. Signed-off-by: Andrew Pinski (cherry picked from commit 49c87d22535ac4f8aacf088b3f462861c26cacb4)
[Bug tree-optimization/110279] [14 Regression] Regressions on aarch64 cause by handing FMA in reassoc (510.parest_r, 508.namd_r)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110279 Rainer Orth changed: What|Removed |Added Resolution|FIXED |--- CC||ro at gcc dot gnu.org Last reconfirmed||2024-05-21 Status|RESOLVED|REOPENED Ever confirmed|0 |1 --- Comment #9 from Rainer Orth --- Not at all, the test still FAILs on sparc-sun-solaris2.11, arm-unknown-linux-gnueabihf, pru-unknown-elf, m68k-unknown-linux-gnu.
[Bug tree-optimization/115154] [13/14/15 Regression] wrong code at optimization levels -O2, -O3, -Os since r13-7434-g682bbd364708fe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115154 --- Comment #17 from GCC Commits --- The releases/gcc-14 branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:b2bb49d6a77e4568c0b91db17b2599f5929fb85b commit r14-10224-gb2bb49d6a77e4568c0b91db17b2599f5929fb85b Author: Andrew Pinski Date: Mon May 20 00:16:40 2024 -0700 match: Disable `(type)zero_one_valuep*CST` for 1bit signed types [PR115154] The problem here is the pattern added in r13-1162-g9991d84d2a8435 assumes that it is well defined to multiply zero_one_valuep by the truncated converted integer constant. It is well defined for all types except for signed 1bit types. Where `a * -1` is produced which is undefined/ So disable this pattern for 1bit signed types. Note the pattern added in r14-3432-gddd64a6ec3b38e is able to workaround the undefinedness except when `-fsanitize=undefined` is turned on, this is why I added a testcase for that. Bootstrapped and tested on x86_64-linux-gnu with no regressions. PR tree-optimization/115154 gcc/ChangeLog: * match.pd (convert (mult zero_one_valued_p@1 INTEGER_CST@2)): Disable for 1bit signed types. gcc/testsuite/ChangeLog: * c-c++-common/ubsan/signed1bitfield-1.c: New test. * gcc.c-torture/execute/signed1bitfield-1.c: New test. Signed-off-by: Andrew Pinski (cherry picked from commit 49c87d22535ac4f8aacf088b3f462861c26cacb4)
[Bug tree-optimization/115154] [13/14/15 Regression] wrong code at optimization levels -O2, -O3, -Os since r13-7434-g682bbd364708fe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115154 --- Comment #16 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:49c87d22535ac4f8aacf088b3f462861c26cacb4 commit r15-755-g49c87d22535ac4f8aacf088b3f462861c26cacb4 Author: Andrew Pinski Date: Mon May 20 00:16:40 2024 -0700 match: Disable `(type)zero_one_valuep*CST` for 1bit signed types [PR115154] The problem here is the pattern added in r13-1162-g9991d84d2a8435 assumes that it is well defined to multiply zero_one_valuep by the truncated converted integer constant. It is well defined for all types except for signed 1bit types. Where `a * -1` is produced which is undefined/ So disable this pattern for 1bit signed types. Note the pattern added in r14-3432-gddd64a6ec3b38e is able to workaround the undefinedness except when `-fsanitize=undefined` is turned on, this is why I added a testcase for that. Bootstrapped and tested on x86_64-linux-gnu with no regressions. PR tree-optimization/115154 gcc/ChangeLog: * match.pd (convert (mult zero_one_valued_p@1 INTEGER_CST@2)): Disable for 1bit signed types. gcc/testsuite/ChangeLog: * c-c++-common/ubsan/signed1bitfield-1.c: New test. * gcc.c-torture/execute/signed1bitfield-1.c: New test. Signed-off-by: Andrew Pinski
[Bug sanitizer/115172] Invalid -fsanitize=bool sanitization of variable from named address space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115172 --- Comment #5 from Uroš Bizjak --- (In reply to Jakub Jelinek from comment #4) > Created attachment 58261 [details] > gcc15-pr115172.patch > > Full untested patch. I can confirm that this patch fixes boot for the kernel config from PR115172#43.
[Bug other/115174] New: New test case gcc.dg/lto/pr113359-2 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115174
Bug ID: 115174
Summary: New test case gcc.dg/lto/pr113359-2 fails
Product: gcc
Version: 13.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: seurer at gcc dot gnu.org
Target Milestone: ---
g:10bf53a80eefa46500bffb442719777e2640e7d7, r13-8773-g10bf53a80eefa4
I am seeing this on BE machines.
make -k check-c RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'
lto.exp=pr113359-2**"
FAIL: gcc.dg/lto/pr113359-2 c_lto_pr113359-2_0.o assemble, -O2 -flto
-fno-strict-aliasing -fno-ipa-cp --disable-tree-esra -fdump-ipa-icf-details
FAIL: gcc.dg/lto/pr113359-2 c_lto_pr113359-2_0.o-c_lto_pr113359-2_1.o execute
-O2 -flto -fno-strict-aliasing -fno-ipa-cp --disable-tree-esra
-fdump-ipa-icf-details
FAIL: gcc-dg-lto-pr113359-2-01.exe scan-wpa-ipa-dump icf "Semantic equality
hit:geta/.*getb/"
commit 10bf53a80eefa46500bffb442719777e2640e7d7 (HEAD)
Author: Martin Jambor
Date: Mon Apr 8 18:53:23 2024 +0200
ICF: Make ICF and SRA agree on padding
[Bug c++/102774] Stop showing "error: variable or field ‘f’ declared void" after an earlier error in a declarator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102774
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2022-05-18 00:00:00 |2024-5-21
--- Comment #5 from Jonathan Wakely ---
Another one:
template void func(T) { }
f.cc:1:48: error: variable or field ‘func’ declared void
1 | template void func(T) { }
|^~~~
f.cc:1:53: error: ‘T’ was not declared in this scope
1 | template void func(T) { }
| ^
[Bug analyzer/107856] [13/14/15 Regression] gcc.dg/plugin/infoleak-vfio_iommu_type1.c XPASSes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107856 --- Comment #4 from Rainer Orth --- Something is very weird with this test: * For 32-bit x86 (both with 32-bit default and 64-bit default compilers), gcc emits not output at all and the bogus warning on l.42 XPASSes. * For 64-bit x86, the bogus message is emitted and XFAILed. * For 32 and 64-bit sparc (with with 32-bit default and 64-bit default compilers), we always get the bogus message, XFAILed as expected. Doesn't seem particularly reliable to me ;-)
[Bug ipa/115135] [12/13/14/15 regression] [C++] GCC produces wrong code at certain inlining levels on Aarch64 with -fno-exceptions, related to lambdas and variants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115135 --- Comment #9 from Carlos Alberto Lopez Perez --- (In reply to Sam James from comment #8) > (godbolt is great for this, btw) good idea. I tried it but for target ARM64 it doesn't allow to execute the code, only see the generated assembly. And I'm not versed enough on reading assembly to easily spot the issue there.
[Bug modula2/114529] profiledbootstrap fails to build and m2 causes odr violations during build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114529
--- Comment #3 from Gaius Mulley ---
As an aid memoir the configure flags are:
../configure --prefix=$HOME/opt --enable-bootstrap
--with-build-config="bootstrap-O3 bootstrap-lto"
--enable-languages=c,c++,m2,lto
which provoke the odr violation.
m2/gm2-compiler-boot/M2Error.c:421:8: warning: type ‘struct
DynamicStrings_Contents_r’ violates the C++ One Definition Rule [-Wodr]
421 | struct DynamicStrings_Contents_r {
|^
m2/gm2-compiler-boot/M2GCCDeclare.c:708:8: note: a different type is defined in
another translation unit
708 | struct DynamicStrings_Contents_r {
|^
m2/gm2-compiler-boot/M2Error.c:422:55: note: the first difference of
corresponding definitions is field ‘buf’
422 |DynamicStrings__T5 buf;
[Bug ipa/115135] [C++] GCC produces wrong code at certain inlining levels on Aarch64 with -fno-exceptions, related to lambdas and variants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115135 --- Comment #8 from Sam James --- (godbolt is great for this, btw)
[Bug bootstrap/115167] [15 Regression] CFG edge visualization to path-printing bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115167 David Malcolm changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #4 from David Malcolm --- > Also, gcc119 would be a much better choice than gcc111. Thanks; am trying on that. FWIW r15-636-g770657d02c986c added a new vfunc to libcpp: range_label::get_effects and it's *defined* in the header, so my immediately suspicion is that's the issue. Investigating...
[Bug ipa/115135] [C++] GCC produces wrong code at certain inlining levels on Aarch64 with -fno-exceptions, related to lambdas and variants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115135 --- Comment #7 from Carlos Alberto Lopez Perez --- Well, I just tested with gcc-11 now and that one works. So the failure was introduced between 11 and 12. $ g++-11 --version g++-11 (Debian 11.3.0-12) 11.3.0 Copyright (C) 2021 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. $ g++-11 -std=c++20 -O3 -fno-exceptions test.cpp && ./a.out [DEBUG] aPtr at 0xe610 points to 0xe4a7e2c0 which has value 10 [At initTest()] [DEBUG] bObj at 0xe61eeed0 has value 11 [At initTest()] [DEBUG] aPtr at 0xe61eeef0 points to 0xe4a7e2c0 which has value 10 [At doTest():aTest] [DEBUG] bObj at 0xe61eeed8 has value 11 [At doTest():aTest] [DEBUG] mObj at 0xe61eef68 [At doTest():aTest] [DEBUG] mObj at 0xe61eef68 has value 33 [At main()] [OK] Everything went as expected. Program compiled correctly :) $ g++-12 --version g++-12 (Debian 12.2.0-14) 12.2.0 Copyright (C) 2022 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. $ g++-12 -std=c++20 -O3 -fno-exceptions test.cpp && ./a.out [DEBUG] aPtr at 0xd052ba00 points to 0xe95d02c0 which has value 10 [At initTest()] [DEBUG] bObj at 0xd052b9f0 has value 11 [At initTest()] [DEBUG] aPtr at 0xd052ba10 points to 0xd052bbc8 which has value -799881990 [At doTest():aTest] [DEBUG] bObj at 0xd052b9f8 has value -1136642444 [At doTest():aTest] [DEBUG] mObj at 0xd052ba48 [At doTest():aTest] [DEBUG] mObj at 0xd052ba48 has value -1936524422 [At main()] [ERROR] Something went wrong compiling the program!: mObj.m_data should be 33 but is -1936524422
[Bug ipa/115135] [C++] GCC produces wrong code at certain inlining levels on Aarch64 with -fno-exceptions, related to lambdas and variants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115135 --- Comment #6 from Carlos Alberto Lopez Perez --- (In reply to Sam James from comment #5) > (In reply to Carlos Alberto Lopez Perez from comment #2) > > -fno-ipa-modref helps! passing this flag makes the compiled program is > > correct :) > > -> calling it an IPA issue. > > Carlos, if you can find a version which worked before, could you bisect? Unfortunately all versions of GCC that I tested fail. I even tested with a nightly build of GCC (built yesterday at version 15.0.0 20240520 from GCC commit e14c673ea9ab2eca5de4db91b478f0b5297ef321). It also fails.
[Bug ipa/115135] [C++] GCC produces wrong code at certain inlining levels on Aarch64 with -fno-exceptions, related to lambdas and variants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115135 Sam James changed: What|Removed |Added Component|middle-end |ipa --- Comment #5 from Sam James --- (In reply to Carlos Alberto Lopez Perez from comment #2) > -fno-ipa-modref helps! passing this flag makes the compiled program is > correct :) -> calling it an IPA issue. Carlos, if you can find a version which worked before, could you bisect?
[Bug target/115142] [14 Regression] Unrecognizable insn in extract_insn, at recog.cc:2812 with -ftree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115142 --- Comment #5 from Jeffrey A. Law --- Yes, sorry. I should have removed the 15 tag.
[Bug c++/115173] GCC hang and memory exhaustion issue with complex nested initializer lists in C++ std::string construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115173
--- Comment #2 from Jonathan Wakely ---
Further reduced:
struct string { string(int) { } };
void j() {
string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(>)
{ } };
Still garbage though.
[Bug c++/115173] GCC hang and memory exhaustion issue with complex nested initializer lists in C++ std::string construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115173
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-05-21
Keywords||diagnostic,
||ice-on-invalid-code,
||memory-hog
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
I'm marking this as ice-on-invalid-code, even though it gets killed rather than
ICE-ing. But it is invalid.
The summary seems misleading, there are no nested initializer lists here. It's
just syntactically ill-formed code with mismatched braces and parentheses.
And most of the functions are irrelevant to the exponential code.
Reduced:
#include
struct string { string(std::initializer_list) { } };
void j() {
string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(>)
{ } };
}
This seems like auto-generated garbage, not something anybody would ever write
by accident, so should be very low priority.
[Bug target/114978] [14/15 regression] 548.exchange2_r 14%-28% regressions on Loongarch64 after gcc 14 snapshot 20240317
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114978 --- Comment #22 from chenglulu --- (In reply to Xi Ruoyao from comment #21) > (In reply to chenglulu from comment #19) > > diff --git a/gcc/config/loongarch/loongarch.cc > > b/gcc/config/loongarch/loongarch.cc > > index e7835ae34ae..6a808cb0a5c 100644 > > --- a/gcc/config/loongarch/loongarch.cc > > +++ b/gcc/config/loongarch/loongarch.cc > > @@ -2383,7 +2383,7 @@ loongarch_address_insns (rtx x, machine_mode mode, > > bool might_split_p) > > return factor; > > > >case ADDRESS_REG_REG: > > - return factor; > > + return factor * 3; > > > >case ADDRESS_CONST_INT: > > return lsx_p ? 0 : factor; > > > > With this patch, -march=la464 has a score of 11.9. > > However, the specific revision plan has not yet been decided. > > Hmm are ldx and stx really so slow? I think it's more like it's because LDX/STX uses an extra register.
[Bug target/114978] [14/15 regression] 548.exchange2_r 14%-28% regressions on Loongarch64 after gcc 14 snapshot 20240317
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114978 --- Comment #21 from Xi Ruoyao --- (In reply to chenglulu from comment #19) > diff --git a/gcc/config/loongarch/loongarch.cc > b/gcc/config/loongarch/loongarch.cc > index e7835ae34ae..6a808cb0a5c 100644 > --- a/gcc/config/loongarch/loongarch.cc > +++ b/gcc/config/loongarch/loongarch.cc > @@ -2383,7 +2383,7 @@ loongarch_address_insns (rtx x, machine_mode mode, > bool might_split_p) > return factor; > >case ADDRESS_REG_REG: > - return factor; > + return factor * 3; > >case ADDRESS_CONST_INT: > return lsx_p ? 0 : factor; > > With this patch, -march=la464 has a score of 11.9. > However, the specific revision plan has not yet been decided. Hmm are ldx and stx really so slow?
[Bug c++/115173] New: GCC hang and memory exhaustion issue with complex nested initializer lists in C++ std::string construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115173
Bug ID: 115173
Summary: GCC hang and memory exhaustion issue with complex
nested initializer lists in C++ std::string
construction
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: iamanonymous.cs at gmail dot com
Target Milestone: ---
The following code snippet triggers a hang issue:
$ cat bug.cpp
#include
struct string { string(std::initializer_list) { } };
void f() {
string({});
}
void g() {
string(string({});
}
void h() {
string(string({}));
}
void i() {
string(string(string({}));
}
void j() {
string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(string(>)
{ } };
void f() {
auto y =
{
string(Equation())
};
}
I observed that when attempting to compile this code using GCC, the compilation
process hangs indefinitely. Additionally, the RAM usage continuously increases,
leading to excessive consumption of system resources.
However, it is worth noting that when using LLVM as the compiler, the code
compiles quickly and produces the expected compilation output.
We have found that this issue still persists in the latest version of GCC(see
https://godbolt.org/z/oKKe5WK9v)
The command we used is(no error output):
g++ bug.cpp
The GCC version:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-linux-gnu/13/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
13.1.0-8ubuntu1~20.04.2' --with-bugurl=file:///usr/share/doc/gcc-13/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2,rust --prefix=/usr
--with-gcc-major-version-only --program-suffix=-13
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/libexec --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.1.0 (Ubuntu 13.1.0-8ubuntu1~20.04.2)
