[Bug libstdc++/120029] Dangling iterator usage in std::filesystem::path::operator+=(const std::filesystem::path &p) when this == p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120029 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2025-04-30 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |12.5
[Bug c/120009] RFE: idea: void (dummy) objects (really...)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120009 --- Comment #6 from H. Peter Anvin --- I would say it would either take up 1 bit or be an error. Bitfields actually was one of the biggest design mistakes in C: the width should always have been part of the type (like intX_t or now, finally, _BitInt ... eventually we'll have all of PL/1 reimplemented.)
[Bug c++/117783] [C++26] P1061R10 - Structured bindings can introduce a pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117783 Jakub Jelinek changed: What|Removed |Added Attachment #61241|0 |1 is obsolete|| --- Comment #4 from Jakub Jelinek --- Created attachment 61257 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61257&action=edit gcc16-pr117783-wip.patch Further progress.
[Bug c++/119981] [14/15/16 Regression] rejects lambda used a template argument with inner template as a template param since r15-123
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119981
--- Comment #3 from GCC Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:05ea8baf6ff96c77a9a2467d5c45b1ed575fca92
commit r16-309-g05ea8baf6ff96c77a9a2467d5c45b1ed575fca92
Author: Patrick Palka
Date: Wed Apr 30 10:54:23 2025 -0400
c++: UNBOUND_CLASS_TEMPLATE context substitution [PR119981]
In r15-123 and r14-11434 we unconditionally set processing_template_decl
when substituting the context of an UNBOUND_CLASS_TEMPLATE, in order to
handle instantiation of the dependently scoped friend declaration
template
template
friend class A::B;
where the scope A remains dependent after instantiation. But this
turns out to misbehave for the UNBOUND_CLASS_TEMPLATE in the below
testcase representing
g<[]{}>::template fn
since with the flag set substituting the args of test3 into the lambda
causes us to defer the substitution and yield a lambda that still looks
dependent, which in turn makes g<[]{}> still dependent and not suitable
for qualified name lookup.
This patch restricts setting processing_template_decl during
UNBOUND_CLASS_TEMPLATE substitution to the case where there are multiple
levels of introduced template parameters, as in the friend declaration.
(This means we need to substitute the template parameter list(s) first,
which makes sense since they lexically appear first.)
PR c++/119981
PR c++/119378
gcc/cp/ChangeLog:
* pt.cc (tsubst) : Substitute
into template parameter list first. When substituting the
context, only set processing_template_decl if there's more
than one level of introduced template parameters.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/lambda-targ15.C: New test.
Reviewed-by: Jason Merrill
[Bug c++/119378] [12/13 Regression] Nested template class friend of template class produces "internal compiler error: unexpected expression ‘T’ of kind template_parm_index"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119378
--- Comment #6 from GCC Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:05ea8baf6ff96c77a9a2467d5c45b1ed575fca92
commit r16-309-g05ea8baf6ff96c77a9a2467d5c45b1ed575fca92
Author: Patrick Palka
Date: Wed Apr 30 10:54:23 2025 -0400
c++: UNBOUND_CLASS_TEMPLATE context substitution [PR119981]
In r15-123 and r14-11434 we unconditionally set processing_template_decl
when substituting the context of an UNBOUND_CLASS_TEMPLATE, in order to
handle instantiation of the dependently scoped friend declaration
template
template
friend class A::B;
where the scope A remains dependent after instantiation. But this
turns out to misbehave for the UNBOUND_CLASS_TEMPLATE in the below
testcase representing
g<[]{}>::template fn
since with the flag set substituting the args of test3 into the lambda
causes us to defer the substitution and yield a lambda that still looks
dependent, which in turn makes g<[]{}> still dependent and not suitable
for qualified name lookup.
This patch restricts setting processing_template_decl during
UNBOUND_CLASS_TEMPLATE substitution to the case where there are multiple
levels of introduced template parameters, as in the friend declaration.
(This means we need to substitute the template parameter list(s) first,
which makes sense since they lexically appear first.)
PR c++/119981
PR c++/119378
gcc/cp/ChangeLog:
* pt.cc (tsubst) : Substitute
into template parameter list first. When substituting the
context, only set processing_template_decl if there's more
than one level of introduced template parameters.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/lambda-targ15.C: New test.
Reviewed-by: Jason Merrill
[Bug c++/119981] [14/15/16 Regression] rejects lambda used a template argument with inner template as a template param since r15-123
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119981
--- Comment #4 from GCC Commits ---
The releases/gcc-15 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:670250c904dd5c8a1e0a0d241c42d5657400cdc8
commit r15-9605-g670250c904dd5c8a1e0a0d241c42d5657400cdc8
Author: Patrick Palka
Date: Wed Apr 30 10:54:23 2025 -0400
c++: UNBOUND_CLASS_TEMPLATE context substitution [PR119981]
In r15-123 and r14-11434 we unconditionally set processing_template_decl
when substituting the context of an UNBOUND_CLASS_TEMPLATE, in order to
handle instantiation of the dependently scoped friend declaration
template
template
friend class A::B;
where the scope A remains dependent after instantiation. But this
turns out to misbehave for the UNBOUND_CLASS_TEMPLATE in the below
testcase representing
g<[]{}>::template fn
since with the flag set substituting the args of test3 into the lambda
causes us to defer the substitution and yield a lambda that still looks
dependent, which in turn makes g<[]{}> still dependent and not suitable
for qualified name lookup.
This patch restricts setting processing_template_decl during
UNBOUND_CLASS_TEMPLATE substitution to the case where there are multiple
levels of introduced template parameters, as in the friend declaration.
(This means we need to substitute the template parameter list(s) first,
which makes sense since they lexically appear first.)
PR c++/119981
PR c++/119378
gcc/cp/ChangeLog:
* pt.cc (tsubst) : Substitute
into template parameter list first. When substituting the
context, only set processing_template_decl if there's more
than one level of introduced template parameters.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/lambda-targ15.C: New test.
Reviewed-by: Jason Merrill
(cherry picked from commit 05ea8baf6ff96c77a9a2467d5c45b1ed575fca92)
[Bug c++/119378] [12/13 Regression] Nested template class friend of template class produces "internal compiler error: unexpected expression ‘T’ of kind template_parm_index"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119378
--- Comment #7 from GCC Commits ---
The releases/gcc-15 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:670250c904dd5c8a1e0a0d241c42d5657400cdc8
commit r15-9605-g670250c904dd5c8a1e0a0d241c42d5657400cdc8
Author: Patrick Palka
Date: Wed Apr 30 10:54:23 2025 -0400
c++: UNBOUND_CLASS_TEMPLATE context substitution [PR119981]
In r15-123 and r14-11434 we unconditionally set processing_template_decl
when substituting the context of an UNBOUND_CLASS_TEMPLATE, in order to
handle instantiation of the dependently scoped friend declaration
template
template
friend class A::B;
where the scope A remains dependent after instantiation. But this
turns out to misbehave for the UNBOUND_CLASS_TEMPLATE in the below
testcase representing
g<[]{}>::template fn
since with the flag set substituting the args of test3 into the lambda
causes us to defer the substitution and yield a lambda that still looks
dependent, which in turn makes g<[]{}> still dependent and not suitable
for qualified name lookup.
This patch restricts setting processing_template_decl during
UNBOUND_CLASS_TEMPLATE substitution to the case where there are multiple
levels of introduced template parameters, as in the friend declaration.
(This means we need to substitute the template parameter list(s) first,
which makes sense since they lexically appear first.)
PR c++/119981
PR c++/119378
gcc/cp/ChangeLog:
* pt.cc (tsubst) : Substitute
into template parameter list first. When substituting the
context, only set processing_template_decl if there's more
than one level of introduced template parameters.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/lambda-targ15.C: New test.
Reviewed-by: Jason Merrill
(cherry picked from commit 05ea8baf6ff96c77a9a2467d5c45b1ed575fca92)
[Bug libstdc++/120029] Dangling iterator usage in std::filesystem::path::operator+=(const std::filesystem::path &p) when this == p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120029 --- Comment #3 from Jonathan Wakely --- The simplest fix is just: --- a/libstdc++-v3/src/c++17/fs_path.cc +++ b/libstdc++-v3/src/c++17/fs_path.cc @@ -880,6 +880,9 @@ path::operator+=(const path& p) return *this; } + if (&p == this) [[unlikely]] +return *this += p.native(); + #if _GLIBCXX_FILESYSTEM_IS_WINDOWS if (_M_type() == _Type::_Root_name || (_M_type() == _Type::_Filename && _M_pathname.size() == 1))
[Bug libstdc++/120029] Dangling iterator usage in std::filesystem::path::operator+=(const std::filesystem::path &p) when this == p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120029 --- Comment #4 from Haoxiang Yu --- (In reply to Jonathan Wakely from comment #3) > The simplest fix is just: > > --- a/libstdc++-v3/src/c++17/fs_path.cc > +++ b/libstdc++-v3/src/c++17/fs_path.cc > @@ -880,6 +880,9 @@ path::operator+=(const path& p) >return *this; > } > > + if (&p == this) [[unlikely]] > +return *this += p.native(); > + > #if _GLIBCXX_FILESYSTEM_IS_WINDOWS >if (_M_type() == _Type::_Root_name >|| (_M_type() == _Type::_Filename && _M_pathname.size() == 1)) Yes it is indeed the simplest way to resolve. The main question is that is it worthy to handle these case in a non-copy way.
[Bug c++/120037] New: Structured binding ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120037
Bug ID: 120037
Summary: Structured binding ICE
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
namespace std {
template struct tuple_size;
template struct tuple_element;
}
struct T { int a[3]; };
namespace std {
template <>
struct tuple_size { static constexpr int value = 3; };
template
struct tuple_element { typedef int type; };
}
template
void
baz ()
{
T t = { { 1, 2, 3 } };
auto [ta, tb, tc] = t;
}
ICEs since r7-4511-g70f40fea6a317d when structured bindings have been
implemented.
/opt/notnfs/gcc-bisect/obj/gcc/cc1plus.r16-304 -quiet decomp18.C -fpermissive
decomp18.C: In function ‘void baz()’:
decomp18.C:18:9: warning: there are no arguments to ‘get’ that depend on a
template parameter, so a declaration of ‘get’ must be available [-fpermissive]
18 | auto [ta, tb, tc] = t;
| ^~
decomp18.C:18:23: internal compiler error: Segmentation fault
18 | auto [ta, tb, tc] = t;
| ^
0x3079199 internal_error(char const*, ...)
../../gcc/diagnostic-global-context.cc:517
0x11d0296 crash_signal
../../gcc/toplev.cc:321
0x8611db lvalue_kind(tree_node const*)
../../gcc/cp/tree.cc:304
0x86157d real_lvalue_p(tree_node const*)
../../gcc/cp/tree.cc:364
0x8615ae lvalue_p(tree_node const*)
../../gcc/cp/tree.cc:376
0x5504e8 cp_finish_decomp(tree_node*, cp_decomp*, bool)
../../gcc/cp/decl.cc:10063
[Bug target/119989] [AVR] Incorrect code generation with __memx pointers when optimization is enabled (-O1 and above) on AVR (ATmega328P)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119989 --- Comment #4 from GCC Commits --- The master branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:4dc40eddbe69566869f7aafb78c31c4850b8aeb7 commit r16-301-g4dc40eddbe69566869f7aafb78c31c4850b8aeb7 Author: Georg-Johann Lay Date: Wed Apr 30 08:43:51 2025 +0200 AVR: target/119989 - Add missing clobbers to xload__libgcc. libgcc's __xload_1...4 is clobbering Z (and also R21 is some cases), but avr.md had clobbers of respective GPRs only up to reload. Outcome was that code reading from the same __memx address twice could be wrong. This patch adds respective clobbers. Forward-port from 2025-04-30 r14-11703 PR target/119989 gcc/ * config/avr/avr.md (xload__libgcc): Clobber R21, Z. gcc/testsuite/ * gcc.target/avr/torture/pr119989.h: New file. * gcc.target/avr/torture/pr119989-memx-1.c: New test. * gcc.target/avr/torture/pr119989-memx-2.c: New test. * gcc.target/avr/torture/pr119989-memx-3.c: New test. * gcc.target/avr/torture/pr119989-memx-4.c: New test. * gcc.target/avr/torture/pr119989-flashx-1.c: New test. * gcc.target/avr/torture/pr119989-flashx-2.c: New test. * gcc.target/avr/torture/pr119989-flashx-3.c: New test. * gcc.target/avr/torture/pr119989-flashx-4.c: New test. (cherry picked from commit 1ca1c1fc3b58ae5e1d3db4f5a2014132fe69f82a)
[Bug target/119989] [AVR] Incorrect code generation with __memx pointers when optimization is enabled (-O1 and above) on AVR (ATmega328P)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119989 Georg-Johann Lay changed: What|Removed |Added Resolution|--- |FIXED Target|Avr |avr Status|UNCONFIRMED |RESOLVED Target Milestone|--- |15.2 --- Comment #5 from Georg-Johann Lay --- Thank you for the report. The issue has been fixed in v12.5, v13.4, v14.3 and v15.2+ The v14 commit is here: r14-11703
[Bug ada/112958] [12/13/14/15/16 regression] s-exnllf.ads etc. don't compile on 32-bit FreeBSD/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112958 --- Comment #15 from Konstantin Belousov --- (In reply to Eric Botcazou from comment #14) > Created attachment 61250 [details] > Tentative fix > > Please give it a try on FreeBSD. I can confirm that the checkout of master at 4a02f3a1f96e9b339a203fc4647a76413a51440e together with the attached patch make bootstrap with gnat enabled to success. Thank you.
[Bug target/120019] [16 regression] PR 111657 change broke Solaris/x86 bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120019 --- Comment #3 from Uroš Bizjak --- (In reply to Uroš Bizjak from comment #2) > Please detect support during configure time and create an operand modifier > that will output "gs " or "fs " for non-default address spaces. Then output > e.g. "%^%x1rep movsq" for "gs rep movsq" when assembler doesn't support new > form. 'v' is still free for the modifier, you can use this letter to return e.g.: "%^%v1rep movsq" where %v1 is substituted with either "gs " or "fs " for the memory operand in the non-default address space (ADDR_SPACE_SEG_GS or ADDR_SPACE_SEG_FS).
[Bug ada/112958] [12/13/14/15/16 regression] s-exnllf.ads etc. don't compile on 32-bit FreeBSD/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112958 --- Comment #16 from Konstantin Belousov --- (In reply to Konstantin Belousov from comment #15) > (In reply to Eric Botcazou from comment #14) > > Created attachment 61250 [details] > > Tentative fix > > > > Please give it a try on FreeBSD. > > I can confirm that the checkout of master at > 4a02f3a1f96e9b339a203fc4647a76413a51440e > together with the attached patch make bootstrap with gnat enabled to success. > > Thank you. On stable/14 amd64.
[Bug tree-optimization/120003] [12/13/14/15/16 Regression] missed optimization around a loop with a checker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120003 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #7 from Richard Biener --- (In reply to Richard Biener from comment #6) > (In reply to Andrew Macleod from comment #4) > > This seems to be the issue? > > > >[local count: 350791453]: > > _1 = g (i_3); > > if (_1 != 0) > > goto ; [50.00%] > > else > > goto ; [50.00%] > > > >[local count: 175395727]: > > > >[local count: 1063004408]: > > # iftmp.0_4 = PHI <1(3), 0(4), 1(5)> > > > > That 3 way PHI isn't used in any threads, so we don't get a threaded path > > to the eventual return of 1. > > The irreducible check is at least badly named - as written it does not > make the containing loop irreducible, instead it partly unrolls things. > > But with that fixed we still reject the path in > jt_path_registry::cancel_invalid_paths by > > 2840 cancel_thread (&path, "Path crosses loop header but does not > exit it"); > > which is true again. We can allow another subset of threads, but this > then enables the > > path: 9->6->7->3->6 > > path which just duplicates one iteration which does not help. > > We need to create a subloop or sibling loop w/o the call. I don't see > offhand why this doesn't work - but then isolating a path will never > create a new loop(?) > > I've played with the following. > > diff --git a/gcc/tree-ssa-threadbackward.cc b/gcc/tree-ssa-threadbackward.cc > index 23bfc14c8f0..2603d27f1f3 100644 > --- a/gcc/tree-ssa-threadbackward.cc > +++ b/gcc/tree-ssa-threadbackward.cc > @@ -789,6 +789,7 @@ back_threader_profitability::profitable_path_p (const > vec &m_path, >*creates_irreducible_loop = false; >if (m_threaded_through_latch >&& loop == taken_edge->dest->loop_father > + && taken_edge->dest != m_path[m_path.length () - 2] >&& (determine_bb_domination_status (loop, taken_edge->dest) > == DOMST_NONDOMINATING)) > *creates_irreducible_loop = true; > diff --git a/gcc/tree-ssa-threadupdate.cc b/gcc/tree-ssa-threadupdate.cc > index 4e5c7566857..d91c0c7bf20 100644 > --- a/gcc/tree-ssa-threadupdate.cc > +++ b/gcc/tree-ssa-threadupdate.cc > @@ -2811,6 +2811,10 @@ jt_path_registry::cancel_invalid_paths > (vec &path) >&& flow_loop_nested_p (exit->dest->loop_father, > exit->src->loop_father)) > return false; > > + // If we thread a whole loop round-trip, we are just creating a subloop > + if (entry->dest == exit->dest) > +return false; > + >if (cfun->curr_properties & PROP_loop_opts_done) > return false; Note this patch ends up restoring the optimization, just the threading itself isn't it. Instead thread2 forms the inner loop and threadfull2 then makes it a sibling loop which cddce3 can elide. So a quite complicated dance, threadfull, thread, threadfull. The question is why we need to iterate here and whether we can do better here. After loop opts we only have one threadfull instance. In particular disabling thread2 makes threadfull2 form the inner loop and we lose. Disabling threadfull1 (with the above patch) makes neither pass do any threading (not even the one I got threadfull1 to do), possibly because the loop was rotated by header copying to the following and there we don't seem to try the cross-iteration invariance of (retval_15 != 0) == true, or rather it's possibly the lack of a forwarder for the 3->5 edge and that we're basic-block based, we only consider '3' once. [local count: 1063004408]: # retval_15 = PHI # i_17 = PHI if (retval_15 != 0) goto ; [67.00%] else goto ; [33.00%] [local count: 350791453]: _1 = g (i_17); [local count: 1063004408]: # prephitmp_16 = PHI <1(3), _1(4)> i_11 = i_17 + 1; if (i_11 != 100) goto ; [98.99%] else goto ; [1.01%] [local count: 1052266995]: goto ; [100.00%] [local count: 10737416]: return prephitmp_16; In fact fixing that fixes the regression with the help of threadfull2 + vrp2.
[Bug target/120011] [15/16 Regression] Impossible asm constraints in 32 bit libgcc when compiling with -march=x86-64-v4 -Os since r15-9176-g564e4e08190229
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120011 --- Comment #13 from Stefan Kneifel --- Correct, -R'ing this patch against 15.1.1 sources reverses the regression.
[Bug ipa/120006] [15/16 Regression] wrong code with -O2 -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120006 --- Comment #13 from Richard Biener --- Created attachment 61252 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61252&action=edit patch I'm testing this, it fixes the small.c testcase.
[Bug target/120034] Fails to recognize bzhi consistently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120034 --- Comment #2 from Richard Biener --- We get (-O2 -mbmi2): bzhi_emulation1: .LFB1: .cfi_startproc movq$-1, %rax shlx%rsi, %rax, %rax notl%eax andl%edi, %eax ret that has single uses only. The issue is likely that 1ULL << index is well-defined for value >= 32 and we likely fail to "saturate" this case when it's demoted to SImode for the AND.
[Bug target/120034] Fails to recognize bzhi consistently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120034
--- Comment #3 from Richard Biener ---
As expected it works for
uint32_t bzhi_emulation1(uint32_t value, uint32_t index) {
return value & ((1 << index) - 1);
}
but we can generate DImode bzhi just fine for this case?
[Bug tree-optimization/120035] New: Loops are not optimized when "unsigned i" is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120035
Bug ID: 120035
Summary: Loops are not optimized when "unsigned i" is used
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: mcccs at gmx dot com
Target Milestone: ---
This code:
__attribute__((noipa)) bool g(int i) {
return true;
}
__attribute__((noipa)) bool f(){
bool retval = false;
for(long unsigned int i=0; i< (1ul << 60); ++i)
retval = retval || g(i);
return retval;
}
int main() {
return (int) !f();
}
With Richard's fix today for pr120003 is optimized, but only when "unsigned" is
removed and "ul" is replaced with "l".
It's also optimized when I add "signed" to i
There should be no difference between a signed i and an unsigned i
[Bug tree-optimization/120035] Loops are not optimized when "unsigned i" is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120035
--- Comment #2 from Richard Biener ---
It works with
_Bool f(){
_Bool retval = 0;
for(unsigned int i=0; i< (1u << 30); ++i)
retval = retval || g(i);
return retval;
}
it also works when g() takes an [unsigned] long. So a bit weird.
[Bug c++/119305] [14 Regression] ICE in add_to_same_comdat_group with constexpr virtual and constexpr instance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119305 --- Comment #4 from Jason Merrill --- (In reply to Patrick Palka from comment #3) > Jakub/Jason, shall we backport r15-521 to the 14 branch in order to fix this > PR for 14.3? That would make sense to me, but let's see what Jakub thinks.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 116671, which changed state. Bug 116671 Summary: Compiling iostream and string as modules fails if string is compiled first https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116671 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/115206] ICE: segfault in code involving C++ modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115206 Nathaniel Shead changed: What|Removed |Added CC||nshead at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2025-04-30 Status|UNCONFIRMED |WAITING --- Comment #1 from Nathaniel Shead --- Hi, thanks for the report. I'm not currently able to reproduce with your report; could you confirm if you still get the same issue on GCC 15? Thanks!
[Bug c/115027] Missing warning: unused struct's with self-referential initialisers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115027 --- Comment #3 from Dr. David Alan Gilbert --- (For my own keeping track, Jakub replied to that patch with a suggestion: https://inbox.sourceware.org/gcc-patches/Zwlg8VYJXQmEC65C@tucnak/ )
[Bug c++/116671] Compiling iostream and string as modules fails if string is compiled first
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116671 Nathaniel Shead changed: What|Removed |Added Target Milestone|--- |15.0 CC||nshead at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Nathaniel Shead --- This works on GCC 15; I don't currently intend on backporting any needed fixes for this to GCC 14.
[Bug c++/115692] C++ module ice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115692 Nathaniel Shead changed: What|Removed |Added CC||nshead at gcc dot gnu.org --- Comment #7 from Nathaniel Shead --- Hi, unfortunately I cannot reproduce using the attached files, as they depend on a module 'fast_io.core' that doesn't seem to be provided. Can you confirm whether you still get the segfault on 15 or trunk? If so, if you could provide preprocessed sources for all modules involved that would be very helpful; thanks!
[Bug c++/119305] [14 Regression] ICE in add_to_same_comdat_group with constexpr virtual and constexpr instance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119305 --- Comment #5 from Jakub Jelinek --- r15-521 was meant for 15 only: On Thu, Apr 25, 2024 at 11:30:48AM -0400, Jason Merrill wrote: > Hmm, maybe maybe_clone_body shouldn't clear DECL_SAVED_TREE for aliases, but > > > rather set it to some stub like void_node? > > > > > > Though with all these changes, it's probably better to go with your first > > > patch for GCC 14 and delay this approach to 15. Your v1 patch is OK for 14. > > Though, at this point guess it has been well tested on the trunk, so I'm not against the backport. Looking through bugzilla, r15-521 is also mentioned in PR117813 and in PR109464. So, if we backport r15-521, maybe we should backport also r15-2154.
[Bug target/119971] [15/16 Regression] RISC-V: Wrong code with bitmanip extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119971 --- Comment #2 from Jeffrey A. Law --- The pattern Andrew quoted I think is OK. It "eats" the & 31 because that's implicitly done by the hardware for the "w" forms of the shift instructions. The real problem is when we use that shift count in this pattern: ;; The logical-and against 0x1 implicitly extends the result. So we can treat ;; an SImode bext as-if it's DImode without any explicit extension. (define_insn "*bextdisi" [(set (match_operand:DI 0 "register_operand" "=r") (and:DI (subreg:DI (lshiftrt:SI (match_operand:SI 1 "register_operand" "r") (match_operand:QI 2 "register_operand" "r")) 0) (const_int 1)))] "TARGET_64BIT && TARGET_ZBS" "bext\t%0,%1,%2" [(set_attr "type" "bitmanip")]) It might seem like that pattern is safe, particularly since a shift count outside 0..31 would be undefined behavior. But the hw is going to use an & 63 mask rather than a & 31 mask for rv64. So when the splitter corerctly eliminates the & 31 and we match the bextdisi pattern we can get incorrect results. I need to ponder this a bit more. But that's my take right now.
[Bug target/120036] New: [16 Regression] ICE on highway-1.2.0: during RTL pass: rrvl: in gen_rtx_SUBREG, at emit-rtl.cc:1032
-disable-libsanitizer --disable-libstdcxx-pch --enable-languages=c,c++ --disable-libgomp --disable-libquadmath --disable-libvtv CFLAGS='-O1 -g0' CXXFLAGS='-O1 -g0' LDFLAGS='-O1 -g0' Thread model: posix Supported LTO compression algorithms: zlib gcc version 16.0.0 20250430 (experimental) (GCC)
[Bug c++/117035] ICE in unify, at cp/pt.cc:25410, when specifying lambda expression template argument in partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117035 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #3 from Patrick Palka --- I think this is effectively IFNDR like the PR101670 testcase, since the partial specialization of Foo is unusable.
[Bug ipa/120006] [15 Regression] wrong code with -O2 -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120006 Avraham Hollander changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #16 from Avraham Hollander --- (In reply to Richard Biener from comment #15) > Fixed on trunk (please double-check the original unreduced issue is fixed as > well). Original issue is fixed as well. Thanks for the quick turnaround.
[Bug c++/120023] When using c++ modules, put deduction guide in a separate module unit file, the deduction will be ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120023 Nathaniel Shead changed: What|Removed |Added Last reconfirmed||2025-04-30 Ever confirmed|0 |1 CC||nshead at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |nshead at gcc dot gnu.org --- Comment #1 from Nathaniel Shead --- Confirmed. The issue is that because myclass is only an imported dependency in 'pm.deduction', we never walk it and so never build bindings for the deduction guides, causing name lookup to fail. There's not really a great workaround here that I could find, unfortunately, apart from perhaps turning your modules into partitions instead. The following patch I'm testing should solve the issue: diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc index a2e0d6d2571..ae731906ca0 100644 --- a/gcc/cp/module.cc +++ b/gcc/cp/module.cc @@ -14825,6 +14825,9 @@ depset::hash::find_dependencies (module_state *module) if (!is_key_order () && DECL_CLASS_TEMPLATE_P (decl)) add_deduction_guides (decl); + if (!is_key_order () + && deduction_guide_p (decl)) +add_deduction_guides (TYPE_NAME (TREE_TYPE (TREE_TYPE (decl; if (!is_key_order () && TREE_CODE (decl) == TEMPLATE_DECL
[Bug tree-optimization/120035] Loops are not optimized when "unsigned i" is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120035 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=120003 Last reconfirmed||2025-04-30 Ever confirmed|0 |1 CC||rguenth at gcc dot gnu.org --- Comment #1 from Richard Biener --- Unlike the other testcase this one doesn't seem to be a regression. The incoming IL is slightly different, more similar with -fdisable-tree-thread2, we do some threading but the magic does not happen. Not further analyzed.
[Bug ipa/68331] [meta-bug] fipa-pta issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68331 Bug 68331 depends on bug 120006, which changed state. Bug 120006 Summary: [15 Regression] wrong code with -O2 -fipa-pta https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120006 What|Removed |Added Status|RESOLVED|ASSIGNED Resolution|FIXED |---
[Bug c++/120016] SIGSEGV ICE with modules related to instantiation of templates across partition units (case 3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120016 Nathaniel Shead changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE CC||nshead at gcc dot gnu.org --- Comment #1 from Nathaniel Shead --- Dup. *** This bug has been marked as a duplicate of bug 120013 ***
[Bug c++/120013] SIGSEGV ICE with modules related to instantiation of templates across partition units
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120013 --- Comment #9 from Nathaniel Shead --- *** Bug 120016 has been marked as a duplicate of this bug. ***
[Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07 --- Comment #32 from LIU Hao --- Created attachment 61251 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61251&action=edit another non-working patch Unfortunately, decreasing the incoming stack alignment to 4 but also keeping preferred stack alignment as 16 doesn't seem to work: In file included from ../../../gcc/libgcc/unwind-dw2.c:1483: ../../../gcc/libgcc/unwind.inc: In function '_Unwind_RaiseException': ../../../gcc/libgcc/unwind.inc:141:1: sorry, unimplemented: Stack realignment not supported with '__builtin_eh_return' 141 | } | ^ make[3]: *** [../../../gcc/libgcc/shared-object.mk:14: unwind-dw2.o] Error 1
[Bug target/120011] [15/16 Regression] Impossible asm constraints in 32 bit libgcc when compiling with -march=x86-64-v4 -Os since r15-9176-g564e4e08190229
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120011 Richard Biener changed: What|Removed |Added Keywords||build Target|i?86|i?86-*-* Priority|P3 |P2
[Bug c++/120012] [12/13/14/15/16 Regression] P1008R1 causes tail padding reuse in C++20 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120012 Richard Biener changed: What|Removed |Added Priority|P3 |P2 CC||rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- going to be interesting to decide what to do on branches ... does it affect the ABI of any part of libstdc++, in the shared object or instantiated templates in libraries using libstdc++?
[Bug tree-optimization/120020] New: [Optimization opportunity] Optimize repeated inline assembly operations when semantically equivalent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120020
Bug ID: 120020
Summary: [Optimization opportunity] Optimize repeated inline
assembly operations when semantically equivalent
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: a1343922569 at outlook dot com
Target Milestone: ---
I would like to propose an optimization enhancement regarding inline assembly
operations in C++, specifically for cases where multiple non-volatile asm
statements perform similar or nearly identical operations.
Description:
Currently, when a function calls multiple other functions containing similar
inline assembly operations (e.g., one retrieving the quotient and another
retrieving the remainder from a division operation), GCC generates code that
repeats the same assembly instruction multiple times, even though a single
execution could provide all needed results.
Environment Information:
GCC version: GCC 16.0.0
System type: x86_64-linux-gnu
Complete Command Line:
g++ -O2 -S test.cpp
Reproduction C++ code (64-bit variable):
#include
using U = uint64_t;
struct A { U quo; U rem; };
U myDiv(U const& a, U const& b)
{
U result, dummyDividendHigh;
asm (
"xor %[dividendHigh], %[dividendHigh] \n\t"
"divq %[divisor] \n\t"
: [quotient] "=a"(result), [dividendHigh] "=d" (dummyDividendHigh)
: [dividendLow] "a"(a), [divisor] "rm"(b)
);
return result;
}
U myMod(U const& a, U const& b)
{
U result;
asm (
"xor %[dividendHigh], %[dividendHigh] \n\t"
"divq %[divisor] \n\t"
: [dividendHigh] "=d" (result)
: [dividendLow] "a"(a), [divisor] "rm"(b)
);
return result;
}
A myDivMod1(U const& a, U const& b)
{
A result;
result.quo = myDiv(a, b);
result.rem = myMod(a, b);
return result;
}
A myDivMod2(U const& a, U const& b)
{
A result;
asm (
"xor %[dividendHighOrRemainder], %[dividendHighOrRemainder] \n\t"
"divq %[divisor] \n\t"
: [quotient] "=a"(result.quo), [dividendHighOrRemainder] "=d" (result.rem)
: [dividendLow] "a"(a), [divisor] "rm"(b)
);
return result;
}
Current generated assembly (64-bit variable):
myDiv(unsigned long const&, unsigned long const&):
mov rax, qword ptr [rdi]
mov rcx, qword ptr [rsi]
mov qword ptr [rsp - 8], rcx
xor rdx, rdx
div qword ptr [rsp - 8]
ret
myMod(unsigned long const&, unsigned long const&):
mov rax, qword ptr [rdi]
mov rcx, qword ptr [rsi]
mov qword ptr [rsp - 8], rcx
xor rdx, rdx
div qword ptr [rsp - 8]
mov rax, rdx
ret
myDivMod1(unsigned long const&, unsigned long const&):
mov rcx, qword ptr [rdi]
mov rdi, qword ptr [rsi]
mov qword ptr [rsp - 8], rdi
mov rax, rcx
xor rdx, rdx
div qword ptr [rsp - 8]
mov rsi, rax
mov qword ptr [rsp - 16], rdi
mov rax, rcx
xor rdx, rdx
div qword ptr [rsp - 16]
mov rax, rsi
ret
myDivMod2(unsigned long const&, unsigned long const&):
mov rax, qword ptr [rdi]
mov rcx, qword ptr [rsi]
mov qword ptr [rsp - 8], rcx
xor rdx, rdx
div qword ptr [rsp - 8]
ret
Godbolt link (GCC, generate suboptimal assembly code for myDivMod1, which is
not the same as myDivMod2)
64-bit variable: https://gcc.godbolt.org/z/7j9MsKsMr
32-bit variable: https://gcc.godbolt.org/z/EEKzWWx14
16-bit variable: https://gcc.godbolt.org/z/5j9zoxrro
8-bit variable: https://gcc.godbolt.org/z/3sWh9K6r5
Godbolt link (Clang, generate optimal assembly code for myDivMod1, which is the
same as myDivMod2)
64-bit variable: https://gcc.godbolt.org/z/cneMq3eYT
32-bit variable: https://gcc.godbolt.org/z/E1e9x65hj
16-bit variable: https://gcc.godbolt.org/z/3aq9dsa3M
8-bit variable: https://gcc.godbolt.org/z/8EG8TEzGq
Optimization suggestion
I suggest enhancing GCC to recognize situations where multiple non-volatile
inline assembly blocks across function calls share identical or highly similar
operations, and optimize them by merging the operations when semantically safe.
For the example above, the assembly code generated for myDivMod1 should be no
more complex than that of myDivMod2 and contain no more than one div
instruction.
Theoretical basis
According to GCC's inline assembly documentation, non-volatile asm statements
can be reordered and optimized by the compiler. In this case, both myDiv and
myMod are essentially performing the same div operation but extracting
different outputs (quotient vs. remainder). Since the x86 div instruction
naturally produces both results simultaneously, executing it twice is
redundant.
Another strong reason to support this optimization suggestion is that, Clang
generates identical code for both myDivM
[Bug ipa/120006] [15/16 Regression] wrong code with -O2 -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120006 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2025-04-30 --- Comment #12 from Richard Biener --- So here I think the issue is that there's a mismatch between alias and clobber/use constraint building where the former handles __builtin_strdup, not making its argument escape, but the latter does not, assuming it's good enough to use what escapes: c_4 = &HEAP(35) doubledereftmp(36) = *xstrdup.arg0 + UNKNOWN *c_4 + UNKNOWN = doubledereftmp(36) xstrdup.clobber = ESCAPED xstrdup.use = ESCAPED
[Bug tree-optimization/120020] [Optimization opportunity] Optimize repeated inline assembly operations when semantically equivalent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120020 --- Comment #4 from Andrew Pinski --- Oh the inline-asm in myDivMod2 also is missing an early clobber for b too.
[Bug tree-optimization/120020] [Optimization opportunity] Optimize repeated inline assembly operations when semantically equivalent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120020 --- Comment #5 from Andrew Pinski --- (In reply to Andrew Pinski from comment #4) > Oh the inline-asm in myDivMod2 also is missing an early clobber for b too. s/b/dividendRemainder/.
[Bug tree-optimization/120020] [Optimization opportunity] Optimize repeated inline assembly operations when semantically equivalent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120020 --- Comment #6 from Jin Haobo --- Sorry, the code in my reproduction is wrong. I will re-show the C++ code. This code is right, and Clang generate the right optimal assembly indeed.
[Bug tree-optimization/120022] [Optimization opportunity] Related with Bug 119917 and 120020
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120022 Jin Haobo changed: What|Removed |Added Resolution|WONTFIX |--- Status|RESOLVED|UNCONFIRMED --- Comment #4 from Jin Haobo --- (In reply to Andrew Pinski from comment #1) > Note your inline-asm is still broken. > > asm ( > "xor %[remainder], %[remainder] \n\t" > "div %[divisor] \n\t" > : [quotient] "=a"(result), [remainder] "=&d" (dummyRemainder) > : [dividendLow] "a"(a), [divisor] "rm"(b) > ); > > Is the corrected version. The reason you need an early clobber on remainder > output is because you clobber it before use the input of divisor and divisor > still can be assigned to rdx. Thank you, but the "correct" code still generate suboptimal assembly code for myDivMod1, while Clang is optimal. GCC: https://gcc.godbolt.org/z/cvadddsz3 Clang: https://gcc.godbolt.org/z/fdvaWzGo5 Is this actually a suboptimal assembly, or I miss some subtle detail?
[Bug tree-optimization/120022] [Optimization opportunity] Related with Bug 119917 and 120020
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120022 --- Comment #5 from Jin Haobo --- Bug 119917 is another Bug which is submit by myself! But this issue has still not been resolved so far, and with no more reply.
[Bug tree-optimization/120022] [Optimization opportunity] Related with Bug 119917 and 120020
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120022 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #6 from Andrew Pinski --- >The similar issue has mentionedin Bug 117529 about five months ago, but this >issue has still not been resolved so far, and with no more reply. 5 months is a short time for GCC missed optimizations for being opened really. GCC has 80 missed optimization issues opened for over 20 years.
[Bug target/120019] [16 regression] PR 111657 change broke Solaris/x86 bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120019 --- Comment #2 from Uroš Bizjak --- (In reply to Rainer Orth from comment #0) > Between 20250428 and 20250429, Solaris/x86 bootstrap with the native as got > broken compiling libgcc: > > /var/gcc/regression/master/11.4-gcc/build/./gcc/xgcc > -B/var/gcc/regression/master/11.4-gcc/build/./gcc/ > -B/vol/gcc/i386-pc-solaris2.11/bin/ > -B/vol/gcc/i386-pc-solaris2.11/lib/amd64/ -isystem > /vol/gcc/i386-pc-solaris2.11/include -isystem > /vol/gcc/i386-pc-solaris2.11/sys-include -fno-checking -g -O2 -m64 -O2 -g > -O2 -DIN_GCC -W -Wall -Wno-error=narrowing -Wwrite-strings -Wcast-qual > -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition > -isystem ./include -fpic -g -DIN_LIBGCC2 -fbuilding-libgcc > -fno-stack-protector -fpic -I. -I. -I../../.././gcc > -I/vol/gcc/src/hg/master/local/libgcc > -I/vol/gcc/src/hg/master/local/libgcc/. > -I/vol/gcc/src/hg/master/local/libgcc/../gcc > -I/vol/gcc/src/hg/master/local/libgcc/../include -DHAVE_CC_TLS -o > unwind-dw2.o -MT unwind-dw2.o -MD -MP -MF unwind-dw2.dep -fexceptions -c > /vol/gcc/src/hg/master/local/libgcc/unwind-dw2.c -fvisibility=hidden > -DHIDE_EXPORTS > > Assembler: unwind-dw2.c > "/var/tmp//ccaYKMya.s", line 210 : Invalid instruction argument > Near line: "rep movsq (%rsi), (%rdi)" > "/var/tmp//ccaYKMya.s", line 11414 : Invalid instruction argument > Near line: "rep movsl (%rsi), (%rdi)" > > and similarly for the 32-bit libgcc. > > While as can deal with the previous syntax (rep movsl), it apparently doesn't > grok the new form. > > Bootstrap is fine when using gas, though. Please detect support during configure time and create an operand modifier that will output "gs " or "fs " for non-default address spaces. Then output e.g. "%^%x1rep movsq" for "gs rep movsq" when assembler doesn't support new form.
[Bug ada/112958] [12/13/14/15/16 regression] s-exnllf.ads etc. don't compile on 32-bit FreeBSD/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112958 --- Comment #19 from GCC Commits --- The releases/gcc-14 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:51d76593947a2dba90f52b394fdf70602fa8ff6a commit r14-11704-g51d76593947a2dba90f52b394fdf70602fa8ff6a Author: Eric Botcazou Date: Wed Apr 30 12:41:36 2025 +0200 Fix GNAT build failure for x86/FreeBSD gcc/ada/ PR ada/112958 * Makefile.rtl (LIBGNAT_TARGET_PAIRS) [x86 FreeBSD]: Add specific version of s-dorepr.adb. * libgnat/s-dorepr__freebsd.adb: New file.
[Bug middle-end/120021] Offloading vs. C++ 'std::initializer_list'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120021
Alex changed:
What|Removed |Added
Summary|Offloading vs. C++ |Offloading vs. C++
|'std::valarray' |'std::initializer_list'
CC||waffl3x at gcc dot gnu.org
--- Comment #3 from Alex ---
This appears to be related to std::initializer_list
```
#include
bool initializer_list()
{
int sum;
#pragma omp target map(from: sum)
{
auto il = {0, 1, 2, 3, 4, 5};
int n = 0;
auto end = il.end();
for (auto it = il.begin(); it != end; ++it)
n += *it;
sum = n;
}
return sum == 15;
}
int main()
{
return initializer_list() ? 0 : 1;
}
```
I'm sure a better reduced case exists, seems specifically be reading the
elements of the list as the following passes.
```
/* std::initializer_list in target region. */
#include
bool initializer_list()
{
bool ok;
#pragma omp target map(from: ok)
{
auto il = {0, 1, 2, 3, 4, 5};
ok = il.begin() != il.end();
}
return ok;
}
int main()
{
return initializer_list() ? 0 : 1;
}
```
[Bug ada/112958] [12/13/14/15/16 regression] s-exnllf.ads etc. don't compile on 32-bit FreeBSD/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112958 --- Comment #20 from GCC Commits --- The releases/gcc-13 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:2317297a745a5b73015074621df9290569fb67d3 commit r13-9626-g2317297a745a5b73015074621df9290569fb67d3 Author: Eric Botcazou Date: Wed Apr 30 12:41:36 2025 +0200 Fix GNAT build failure for x86/FreeBSD gcc/ada/ PR ada/112958 * Makefile.rtl (LIBGNAT_TARGET_PAIRS) [x86 FreeBSD]: Add specific version of s-dorepr.adb. * libgnat/s-dorepr__freebsd.adb: New file.
[Bug ada/112958] [12/13/14/15/16 regression] s-exnllf.ads etc. don't compile on 32-bit FreeBSD/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112958 --- Comment #17 from GCC Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:85e4f21f9e90fc70b8c7c75ec8e4d0766008ac6e commit r16-302-g85e4f21f9e90fc70b8c7c75ec8e4d0766008ac6e Author: Eric Botcazou Date: Wed Apr 30 12:41:36 2025 +0200 Fix GNAT build failure for x86/FreeBSD gcc/ada/ PR ada/112958 * Makefile.rtl (LIBGNAT_TARGET_PAIRS) [x86 FreeBSD]: Add specific version of s-dorepr.adb. * libgnat/s-dorepr__freebsd.adb: New file.
[Bug ada/112958] [12/13/14/15/16 regression] s-exnllf.ads etc. don't compile on 32-bit FreeBSD/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112958 --- Comment #18 from GCC Commits --- The releases/gcc-15 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:01ebce59db2039c6d63b565295095fd6e3b02d57 commit r15-9604-g01ebce59db2039c6d63b565295095fd6e3b02d57 Author: Eric Botcazou Date: Wed Apr 30 12:41:36 2025 +0200 Fix GNAT build failure for x86/FreeBSD gcc/ada/ PR ada/112958 * Makefile.rtl (LIBGNAT_TARGET_PAIRS) [x86 FreeBSD]: Add specific version of s-dorepr.adb. * libgnat/s-dorepr__freebsd.adb: New file.
[Bug c++/119983] Member function in unnamed type causes internal compiler error in module.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119983
--- Comment #5 from Nathaniel Shead ---
(In reply to gap mman from comment #4)
> (In reply to Nathaniel Shead from comment #2)
> > Thanks for the report! As Andrew noted, the ICE is fixed for 14.3 by
> > r14-10825-g01d3a974fe3474c37cd52b595c29dddafad954dc.
> >
> > The code is ill-formed, however:
> >
> > export module M;
> > struct {} instance;
> >
> > is not legal in a module interface, because of
> > https://eel.is/c++draft/basic.link#15.2 (the type of the unnamed struct is
> > TU-local), https://eel.is/c++draft/basic.link#14 (the declaration of the
> > variable exposes the TU-local type), and
> > https://eel.is/c++draft/basic.link#17 (the variable is not TU-local, so this
> > is ill-formed).
> >
> > We don't check this in GCC 14 (so 14.3 will accept this code), but for GCC
> > 15 we properly implement https://wg21.link/p1815 and so error in this case:
> >
> > :2:11: error: 'instance' exposes TU-local entity 'struct'
> > 2 | struct {} instance;
> > | ^~~~
> > :2:8: note: '' has no name and is not defined within
> > a class, function, or initializer
> > 2 | struct {} instance;
> > |^
>
> Thank you for answering. I'm only using this variable within the TU.
>
> Am I correct in understanding the problem as the following: The instance,
> even though not visible outside of the module,
This is the issue: 'instance' *would* be visible outside of this TU, such as in
e.g. a module implementation unit, but the unnamed struct would not be, which
would cause issues.
> doesn't have internal linkage
> but names a TU local entity (the unnamed type), which causes exposure and is
> therefore ill formed. To fix, either name the type to make it not TU local
> or make the variable have internal linkage (adding `static` as in the
> example).
And yes, by adding 'static', or wrapping in an unnamed namespace, 'instance'
would no longer be accessible in other TUs, so there's no reason to complain
anymore.
>
> As for a fix in current GCC14.2 I'm using, my only bet is naming this type?
Naming the type is probably the most straight-forward workaround, yes.
> I'm actually declaring it `constexpr`(which, unfortunately, is explicitly
> defined as exposure)
> ```
> constexpr struct
> {
> void aRandomFunc()
> {
>
> }
> } variableWithNamelessType{};
> ```
>
> I also noticed something I didn't quite understand in GCC14.2. If I declare
> this as `static constexpr` and use it in an exported function, then I'm
> fine; but if the function is templatized, then I get "references internal
> linkage entity". https://godbolt.org/z/3rKn3v7rq In GCC 15 both works, which
> I believe should be the correct behavior?
Within a non-inline templated function it's actually still problematic, but
only if an importer attempts to instantiate it; this is the behaviour mandated
by the standard. You can experiment with '-Wtemplate-names-tu-local' (also
enabled by '-Wextra') to see more.
For a non-inline non-template function it's OK because we don't emit the bodies
of such functions, so the entity is not exposed.
[Bug ada/112958] [12/13/14/15/16 regression] s-exnllf.ads etc. don't compile on 32-bit FreeBSD/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112958 --- Comment #21 from GCC Commits --- The releases/gcc-12 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:d30dfa8586b5d12e341a7965ef7970a2b8402519 commit r12-11078-gd30dfa8586b5d12e341a7965ef7970a2b8402519 Author: Eric Botcazou Date: Wed Apr 30 12:41:36 2025 +0200 Fix GNAT build failure for x86/FreeBSD gcc/ada/ PR ada/112958 * Makefile.rtl (LIBGNAT_TARGET_PAIRS) [x86 FreeBSD]: Add specific version of s-dorepr.adb. * libgnat/s-dorepr__freebsd.adb: New file.
[Bug ada/112958] [12/13/14/15/16 regression] s-exnllf.ads etc. don't compile on 32-bit FreeBSD/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112958 Eric Botcazou changed: What|Removed |Added Target Milestone|14.3|12.5 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #22 from Eric Botcazou --- Thanks for the testing, this will be fixed in all releases from now on.
[Bug c++/120025] rfe: split assignable temporaries from -fpermissive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120025 --- Comment #4 from Andrew Pinski --- >I've got on clang forum I tried looking for that but I don't see it on discourse.llvm.org at all nor on as an issue at https://github.com/llvm/llvm-project/issues .
[Bug libstdc++/113327] std::sleep_for(std::chrono::hours::max()) returns immediately
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113327 --- Comment #4 from Jonathan Wakely --- I have a patch that fixes the problem for this_thread::sleep_for, timed_mutex::try_until, condition_variable::wait_until and a few other places, but it's not sufficient. There are other overflows in e.g. sleep_until: time_point end_of_time(minutes::max()); std::this_thread::sleep_until(end_of_time); This function internally compares now < end_of_time and that triggers a conversion that overflows. I'm starting to lean towards a much larger change of making chrono conversions use saturation arithmetic, so that we implicitly truncate instead of overflowing. The problem with that is that UBsan won't be able to diagnose the overflows any longer, they'll just cause silent truncation.
[Bug libstdc++/113327] std::sleep_for(std::chrono::hours::max()) returns immediately
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113327 --- Comment #5 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #4) > There are other overflows in e.g. sleep_until: > > time_point end_of_time(minutes::max()); > std::this_thread::sleep_until(end_of_time); > > This function internally compares now < end_of_time and that triggers a > conversion that overflows. Libc++ fails for this case, even though it handles sleep_for(minutes::max()).
[Bug target/120036] [16 Regression] ICE on highway-1.2.0: during RTL pass: rrvl: in gen_rtx_SUBREG, at emit-rtl.cc:1032
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120036 Sergei Trofimovich changed: What|Removed |Added Version|15.0|16.0 CC||hjl.tools at gmail dot com --- Comment #1 from Sergei Trofimovich --- Bisect says r16-271-gd1cada7481420a exposed this failure commit d1cada7481420a23fbec525548ef5bdf64839a34 (HEAD) Author: H.J. Lu Date: Fri Nov 29 18:22:14 2024 +0800 x86: Add a pass to remove redundant all 0s/1s vector load
[Bug c++/119305] [14 Regression] ICE in add_to_same_comdat_group with constexpr virtual and constexpr instance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119305 Patrick Palka changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #3 from Patrick Palka --- Jakub/Jason, shall we backport r15-521 to the 14 branch in order to fix this PR for 14.3?
[Bug ipa/120006] [15 Regression] wrong code with -O2 -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120006 Richard Biener changed: What|Removed |Added Status|RESOLVED|ASSIGNED Resolution|FIXED |--- --- Comment #17 from Richard Biener --- I'll backport this, so keep the bug open.
[Bug ipa/68331] [meta-bug] fipa-pta issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68331 Bug 68331 depends on bug 120006, which changed state. Bug 120006 Summary: [15 Regression] wrong code with -O2 -fipa-pta https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120006 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/120013] SIGSEGV ICE with modules related to instantiation of templates across partition units
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120013
Nathaniel Shead changed:
What|Removed |Added
CC||nshead at gcc dot gnu.org
Status|WAITING |NEW
Keywords||ice-on-valid-code
Blocks||103524
--- Comment #7 from Nathaniel Shead ---
Confirmed. All three test cases do indeed seem to be the same underlying cause
(I'll close the others as duplicates); here's a reduction:
// array.hpp
template struct tuple_element;
template struct tuple;
template
tuple_element<__i, tuple<_Elements>> get();
// a.cpp
module;
#include "array.hpp"
template
struct tuple_element<__i, tuple<_Types>>;
module m:a;
template void a(T t) { ::get(t); }
// b.cpp
module;
#include "array.hpp"
module m:b;
template void b(T t) { ::get(t); }
// c.cpp
export module m;
import :a;
import :b;
$ g++-15 -S -fmodules -Wno-global-module *.cpp
c.cpp:3:11: internal compiler error: Segmentation fault
3 | import :b;
| ^
0x22a2ef6 internal_error(char const*, ...)
../../gcc-15/gcc/diagnostic-global-context.cc:517
0xfe2de3 crash_signal
../../gcc-15/gcc/toplev.cc:322
0x7fa720c6d32f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x78c87a install_entity
../../gcc-15/gcc/cp/module.cc:8109
0x78c87a decl_value
../../gcc-15/gcc/cp/module.cc:8657
0x8fa81f tree_node
../../gcc-15/gcc/cp/module.cc:10062
0x8ff363 module_state::read_cluster(unsigned int)
../../gcc-15/gcc/cp/module.cc:16673
0x8ffe0d module_state::load_section(unsigned int, binding_slot*)
../../gcc-15/gcc/cp/module.cc:20217
0x903cb3 module_state::read_language(bool)
../../gcc-15/gcc/cp/module.cc:20146
0x903e07 module_state::read_language(bool)
../../gcc-15/gcc/cp/module.cc:21206
0x903e07 direct_import
../../gcc-15/gcc/cp/module.cc:21208
0x981a3a cp_parser_translation_unit
../../gcc-15/gcc/cp/parser.cc:5434
0x981a3a c_parse_file()
../../gcc-15/gcc/cp/parser.cc:53961
0xa8a8d9 c_common_parse_file()
../../gcc-15/gcc/c-family/c-opts.cc:1379
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug c++/120014] SIGSEGV ICE with modules related to instantiation of templates across partition units (case 2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120014 Nathaniel Shead changed: What|Removed |Added CC||nshead at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Nathaniel Shead --- Dup. *** This bug has been marked as a duplicate of bug 120013 ***
[Bug c++/120013] SIGSEGV ICE with modules related to instantiation of templates across partition units
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120013 --- Comment #8 from Nathaniel Shead --- *** Bug 120014 has been marked as a duplicate of this bug. ***
[Bug c++/98641] Feature request: implement pointer alignment builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98641 Sam James changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2025-04-30 --- Comment #9 from Sam James --- IMO confirmed via above even if semantics aren't thrashed out yet.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 115706, which changed state. Bug 115706 Summary: Compiling headers as header units fails depending on order. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115706 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/115706] Compiling headers as header units fails depending on order.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115706 --- Comment #9 from Nathaniel Shead --- Created attachment 61256 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61256&action=edit test_module_headers.py Attached is a script I've used for testing random orders of building standard library header modules; so far on GCC 15 I haven't found any further errors using this script.
[Bug c++/115706] Compiling headers as header units fails depending on order.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115706 Nathaniel Shead changed: What|Removed |Added Target Milestone|--- |15.0 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #10 from Nathaniel Shead --- So unless any more specific errors are found I'll resolve this PR as fixed.
[Bug target/120036] [16 Regression] ICE on highway-1.2.0: during RTL pass: rrvl: in gen_rtx_SUBREG, at emit-rtl.cc:1032 since r16-271-gd1cada7481420a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120036 Sam James changed: What|Removed |Added Summary|[16 Regression] ICE on |[16 Regression] ICE on |highway-1.2.0: during RTL |highway-1.2.0: during RTL |pass: rrvl: in |pass: rrvl: in |gen_rtx_SUBREG, at |gen_rtx_SUBREG, at |emit-rtl.cc:1032|emit-rtl.cc:1032 since ||r16-271-gd1cada7481420a Keywords||ice-on-valid-code Target Milestone|--- |16.0
[Bug tree-optimization/120038] New: Missed combining shr and shrx in collatz_f1()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120038 Bug ID: 120038 Summary: Missed combining shr and shrx in collatz_f1() Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: kaelfandrew at gmail dot com Target Milestone: --- Created attachment 61258 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61258&action=edit C code collatz_f1() uses shr then tzcnt then shrx. collatz_f0() uses only tzcnt then shrx. collatz_f0() speeds up by 10% when I tested it. Flags are -O3 -march=icelake-client gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/16/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-16.0./work/gcc-16.0./configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/16 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/16/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/16 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/16/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/16/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/16/include/g++-v16 --disable-silent-rules --disable-dependency-tracking --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/16/python --enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --disable-libunwind-exceptions --enable-checking=yes,extra --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 16.0. p, commit 05d9c70131be267bfe5b36e663acda8729da6456' --with-gcc-major-version-only --enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point --enable-targets=all --enable-offload-defaulted --enable-offload-targets=nvptx-none --enable-libgomp --disable-libssp --disable-libada --enable-cet --disable-systemtap --disable-valgrind-annotations --disable-vtable-verify --disable-libvtv --with-zstd --with-isl --disable-isl-version-check --enable-default-pie --enable-host-pie --enable-host-bind-now --enable-default-ssp --disable-fixincludes --with-gxx-libcxx-include-dir=/usr/include/c++/v1 --with-build-config='bootstrap-lto bootstrap-cet' Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 16.0.0 20250423 (experimental) e9a81addd5b7d018e173fa8d59aafc2f84e41d8b (Gentoo 16.0. p, commit 05d9c70131be267bfe5b36e663acda8729da6456) =
[Bug c++/120037] Structured binding ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120037
--- Comment #1 from Jakub Jelinek ---
Slightly tweaked with the specializations outside of namespace std (though this
one doesn't compile in 7.x).
namespace std {
template struct tuple_size;
template struct tuple_element;
}
struct T { int a[3]; };
template <>
struct std::tuple_size { static constexpr int value = 3; };
template
struct std::tuple_element { typedef int type; };
template
void
baz ()
{
T t = { { 1, 2, 3 } };
auto [ta, tb, tc] = t;
}
[Bug libstdc++/120029] Dangling iterator usage in std::filesystem::path::operator+=(const std::filesystem::path &p) when this == p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120029 --- Comment #5 from Jonathan Wakely --- No, I don't think we need to care about the performance of this case. It's not a realistic operation that is commonly needed for paths.
[Bug c++/120037] Structured binding ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120037 Jakub Jelinek changed: What|Removed |Added CC||jason at gcc dot gnu.org Keywords||ice-on-invalid-code --- Comment #2 from Jakub Jelinek --- get_tuple_decomp_init calls perform_koenig_lookup, that reports an error in 3265 if (complain & tf_error) 3266fn = unqualified_fn_lookup_error (cp_expr (identifier, loc)); and sets fn to the get IDENTIFIER. 3272 if (fn && template_id && fn != error_mark_node) 3273fn = build2 (TEMPLATE_ID_EXPR, unknown_type_node, fn, tmpl_args); later on returns the TEMPLATE_ID_EXPR rather than say error_mark_node, get_tuple_decomp_init then calls finish_call_expr on it which returns CALL_EXPR with NULL TREE_TYPE and we then call 10212 eltype = cp_build_reference_type (eltype, !lvalue_p (init)); on it and lvalue_p is what ICEs because it doesn't expect NULL TREE_TYPE. Shall we somehow test whether the returned init is say type dependent and if so, avoid doing that 10210 /* Save the decltype away before reference collapse. */ 10211 hash_map_safe_put (decomp_type_table, v[i], eltype); 10212 eltype = cp_build_reference_type (eltype, !lvalue_p (init)); 10213 TREE_TYPE (v[i]) = eltype; 10214 layout_decl (v[i], 0); ?
[Bug c++/120039] New: [15/16 Regression] Structured binding in condition ICE since r15-1793
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120039
Bug ID: 120039
Summary: [15/16 Regression] Structured binding in condition ICE
since r15-1793
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
struct S {
int a; long long b; short c;
explicit operator bool () const noexcept { return true; }
};
template
void
foo ()
{
S s = S { 1, 2, 3 };
if (auto [sx, sy, sz] : s)
;
}
int
main ()
{
foo <0> ();
}
ICEs starting with r15-1793-gf30bdb1f2d79fd787 :
/opt/notnfs/gcc-bisect/obj/gcc/cc1plus.r16-304 -quiet decomp14.C -std=c++26
decomp14.C: In function ‘void foo()’:
decomp14.C:11:25: error: expected initializer before ‘:’ token
[-Wtemplate-body]
11 | if (auto [sx, sy, sz] : s)
| ^
decomp14.C:11:24: error: expected ‘)’ before ‘:’ token [-Wtemplate-body]
11 | if (auto [sx, sy, sz] : s)
| ~ ^~
|)
decomp14.C: In instantiation of ‘void foo() [with int N = 0]’:
decomp14.C:18:11: required from here
18 | foo <0> ();
| ^~
decomp14.C:11:3: internal compiler error: Segmentation fault
11 | if (auto [sx, sy, sz] : s)
| ^~
0x3079199 internal_error(char const*, ...)
../../gcc/diagnostic-global-context.cc:517
0x11d0296 crash_signal
../../gcc/toplev.cc:321
0x402ebd tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc/tree.h:3691
0x43e5b2 get_identifier_kind(tree_node*)
../../gcc/cp/cp-tree.h:1315
0x6b2829 lookup_name(tree_node*, LOOK_where, LOOK_want)
../../gcc/cp/name-lookup.cc:8058
0x6b2c71 lookup_name(tree_node*)
../../gcc/cp/name-lookup.cc:8143
0x7cc03e tsubst_expr(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.cc:21987
0x7c0fd1 tsubst_stmt
../../gcc/cp/pt.cc:20024
[Bug c++/120039] [15/16 Regression] Structured binding in condition ICE since r15-1793
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120039 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |15.2
[Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07 --- Comment #33 from Gabriel Ivăncescu --- (In reply to LIU Hao from comment #31) > (In reply to Gabriel Ivăncescu from comment #30) > > Why would it not be safe? For MinGW specifically, what's not safe about it? > > The entire Windows stack assumes only 4-byte alignment for i386, because > > that's what MSVC provides. So interoperability with MSVC code (including > > Windows DLLs or 3rd party libraries) means that anything that requires > > stricter alignment *MUST* realign the stack, or else it would break. > > > > Therefore it should be completely safe for Windows i386 target. > > There's code that expects `__attribute__((__force_align_arg_pointer__))` to > align the stack to 16-byte boundaries. > > https://gcc.gnu.org/pipermail/gcc-patches/2025-April/682180.html Shouldn't using SSE automatically re-align it to 16, seeing as the alignment requirement is stricter? I don't see how __force_align_arg_pointer__ is useful at all for Windows i386 target, nor why it should have any effect. The documented usage of it is "This supports mixing legacy codes that run with a 4-byte aligned stack with modern codes that keep a 16-byte stack for SSE compatibility." but there's no such thing as "modern codes that keep a 16-byte stack" for Windows i386 target. It used to be needed in old Wine versions, before we built builtins as PE, because they were unix shared objects, and obviously the target then uses 16-byte aligned stack, so it was necessary. But this patch shouldn't touch that target, so even building an old Wine version shouldn't break as it's not Windows i386 in the first place.
[Bug driver/91406] gcc -Q -v --help=optimizers lies about what flags are enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91406 Manuel López-Ibáñez changed: What|Removed |Added Summary|gcc -Q -v lies about what |gcc -Q -v --help=optimizers |flags are enabled |lies about what flags are ||enabled CC||manu at gcc dot gnu.org --- Comment #2 from Manuel López-Ibáñez --- (In reply to Richard Biener from comment #1) > -Q -v is only a wild guess given whether options are enabled or disabled may > depend on the function context. There's really no way to implement it > accurately > (this -1 trick for "auto-detection" could eventually be handled in some > generic way, saying not enabled/disabled but "" or "") The output of "-Q --help=optimizers" should at least match the documentation. That is, g++ -Q -O0 --help=optimizers | grep prefetch -fprefetch-loop-arrays[enabled] g++ -Q -Os --help=optimizers | grep prefetch -fprefetch-loop-arrays[enabled] is wrong. I would expect that the option is NEVER enabled with -O0 or -Os independently of any function context.
[Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07 --- Comment #34 from LIU Hao --- (In reply to Gabriel Ivăncescu from comment #33) > Shouldn't using SSE automatically re-align it to 16, seeing as the alignment > requirement is stricter? I don't see how __force_align_arg_pointer__ is > useful at all for Windows i386 target, nor why it should have any effect. That's right in general. > The documented usage of it is "This supports mixing legacy codes that run > with a 4-byte aligned stack with modern codes that keep a 16-byte stack for > SSE compatibility." but there's no such thing as "modern codes that keep a > 16-byte stack" for Windows i386 target. My experience is that _sometimes_ (how often?) GCC assumes the stack is aligned. Yes, in theory it shouldn't, but in practice that's not the case. Maybe we can do that on master, but it will require a lot of testing. See also https://bugs.winehq.org/show_bug.cgi?id=55007
[Bug driver/119823] -Q --help=optimizers output is misleading for -O0 + inconsistent docs in the manual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119823 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #1 from Manuel López-Ibáñez --- (In reply to sandra from comment #0) > At optimization levels below -O1 or -Og, the pass manager completely skips > most optimization passes regardless of whether the corresponding option for > that pass is set. In common.opt many of the corresponding optimization > options are specified with Init(1), e.g. -fivopts (PR71094), and the -Q > option duly reports that they are enabled at -O0, which they are not. We > should fix this. Probably it involves adding some additional flag to > common.opt and making the -Q printer do something with it. > > We've also got a problem that it's hard to sync the manual's lists of > options enabled at different levels with reality. It would be great if we > could get -Q to produce a list that could be cross-checked with the manual, > or for the options processing during GCC build to emit some text that could > be inserted directly in the manual. Yes please. The options machinery should be able to detect whether an option has a default value or a value explicitly set by the user. It currently uses the trick of setting the default value to -1, which is a waste. An example from common.opt is ``` fprefetch-loop-arrays Common Var(flag_prefetch_loop_arrays) Init(-1) Optimization Generate prefetch instructions, if available, for arrays in loops. ``` But this should be something like: ``` fprefetch-loop-arrays Common Var(flag_prefetch_loop_arrays) Init(O2 | O3) Optimization Generate prefetch instructions, if available, for arrays in loops. ```
[Bug ada/112958] [12/13/14/15/16 regression] s-exnllf.ads etc. don't compile on 32-bit FreeBSD/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112958 --- Comment #12 from GCC Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:4a02f3a1f96e9b339a203fc4647a76413a51440e commit r16-295-g4a02f3a1f96e9b339a203fc4647a76413a51440e Author: Eric Botcazou Date: Wed Apr 30 08:57:46 2025 +0200 Fix compilation failure on FreeBSD [changelog] PR ada/112958 * init.c (__gnat_error_handler) [__FreeBSD__]: Fix typo.
[Bug target/120019] New: [16 regression] PR 111657 change broke Solaris/x86 bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120019 Bug ID: 120019 Summary: [16 regression] PR 111657 change broke Solaris/x86 bootstrap Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: ubizjak at gmail dot com Target Milestone: --- Target: i386-pc-solaris2.11 Between 20250428 and 20250429, Solaris/x86 bootstrap with the native as got broken compiling libgcc: /var/gcc/regression/master/11.4-gcc/build/./gcc/xgcc -B/var/gcc/regression/master/11.4-gcc/build/./gcc/ -B/vol/gcc/i386-pc-solaris2.11/bin/ -B/vol/gcc/i386-pc-solaris2.11/lib/amd64/ -isystem /vol/gcc/i386-pc-solaris2.11/include -isystem /vol/gcc/i386-pc-solaris2.11/sys-include -fno-checking -g -O2 -m64 -O2 -g -O2 -DIN_GCC -W -Wall -Wno-error=narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fpic -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fpic -I. -I. -I../../.././gcc -I/vol/gcc/src/hg/master/local/libgcc -I/vol/gcc/src/hg/master/local/libgcc/. -I/vol/gcc/src/hg/master/local/libgcc/../gcc -I/vol/gcc/src/hg/master/local/libgcc/../include -DHAVE_CC_TLS -o unwind-dw2.o -MT unwind-dw2.o -MD -MP -MF unwind-dw2.dep -fexceptions -c /vol/gcc/src/hg/master/local/libgcc/unwind-dw2.c -fvisibility=hidden -DHIDE_EXPORTS Assembler: unwind-dw2.c "/var/tmp//ccaYKMya.s", line 210 : Invalid instruction argument Near line: "rep movsq (%rsi), (%rdi)" "/var/tmp//ccaYKMya.s", line 11414 : Invalid instruction argument Near line: "rep movsl (%rsi), (%rdi)" and similarly for the 32-bit libgcc. While as can deal with the previous syntax (rep movsl), it apparently doesn't grok the new form. Bootstrap is fine when using gas, though.
[Bug rust/120018] internal compiler error: in redirect_to_unreachable, at ipa-fnsummary.cc:258 for 32-bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120018 --- Comment #3 from Marc Poulhiès --- Ok, thanks Andrew, we'll take care of fixing this.
[Bug rtl-optimization/120004] __builtin_unreachable/noreturn should not fall through to another function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120004 --- Comment #5 from Richard Biener --- unreachable() is in some cases added to make the CFG valid - in the past we had a return in such places but unreachable seemed to be a better fit. For asm() we'd need "[[noreturn]]" (or rather [[return]]?).
[Bug ada/112958] [12/13/14/15/16 regression] s-exnllf.ads etc. don't compile on 32-bit FreeBSD/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112958 --- Comment #13 from GCC Commits --- The releases/gcc-15 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:17695fe9ca15046f32833c345ab2406b7c080416 commit r15-9601-g17695fe9ca15046f32833c345ab2406b7c080416 Author: Eric Botcazou Date: Wed Apr 30 08:57:46 2025 +0200 Fix compilation failure on FreeBSD [changelog] PR ada/112958 * init.c (__gnat_error_handler) [__FreeBSD__]: Fix typo.
[Bug rtl-optimization/120004] __builtin_unreachable/noreturn should not fall through to another function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120004 --- Comment #6 from Andrew Pinski --- (In reply to Richard Biener from comment #5) > unreachable() is in some cases added to make the CFG valid - in the past we > had a return in such places but unreachable seemed to be a better fit. > > For asm() we'd need "[[noreturn]]" (or rather [[return]]?). That would be something like the old patch: https://gcc.gnu.org/legacy-ml/gcc-patches/2000-01/msg00190.html .
[Bug target/119989] [AVR] Incorrect code generation with __memx pointers when optimization is enabled (-O1 and above) on AVR (ATmega328P)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119989 --- Comment #2 from GCC Commits --- The releases/gcc-12 branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:21aa0abcf1aba3a5f410b01628e8fc7f55ee8786 commit r12-11077-g21aa0abcf1aba3a5f410b01628e8fc7f55ee8786 Author: Georg-Johann Lay Date: Wed Apr 30 08:43:51 2025 +0200 AVR: target/119989 - Add missing clobbers to xload__libgcc. libgcc's __xload_1...4 is clobbering Z (and also R21 is some cases), but avr.md had clobbers of respective GPRs only up to reload. Outcome was that code reading from the same __memx address twice could be wrong. This patch adds respective clobbers. Backport from 2025-04-30 r14-11703 PR target/119989 gcc/ * config/avr/avr.md (xload__libgcc): Clobber R21, Z. gcc/testsuite/ * gcc.target/avr/torture/pr119989.h: New file. * gcc.target/avr/torture/pr119989-memx-1.c: New test. * gcc.target/avr/torture/pr119989-memx-2.c: New test. * gcc.target/avr/torture/pr119989-memx-3.c: New test. * gcc.target/avr/torture/pr119989-memx-4.c: New test. (cherry picked from commit 1ca1c1fc3b58ae5e1d3db4f5a2014132fe69f82a)
[Bug libstdc++/120029] Dangling iterator usage in std::filesystem::path::operator+=(const std::filesystem::path &p) when this == p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120029
--- Comment #6 from Jonathan Wakely ---
Actually it looks like we can make it optimally efficient without any
difficulty:
--- a/libstdc++-v3/src/c++17/fs_path.cc
+++ b/libstdc++-v3/src/c++17/fs_path.cc
@@ -914,6 +914,10 @@ path::operator+=(const path& p)
_Cmpt* last = nullptr;
if (p._M_type() == _Type::_Multi)
{
+ // For p += p we reallocate now, to avoid dangling pointers later.
+ if (&p == this) [[unlikely]]
+ _M_cmpts.reserve(2 * _M_cmpts.size());
+
it = p._M_cmpts._M_impl->begin();
last = p._M_cmpts._M_impl->end();
}
[Bug c++/119378] [12/13 Regression] Nested template class friend of template class produces "internal compiler error: unexpected expression ‘T’ of kind template_parm_index"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119378
--- Comment #8 from GCC Commits ---
The releases/gcc-14 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:30432ffd9220cc949ef470c47455c6a64f2cdb69
commit r14-11706-g30432ffd9220cc949ef470c47455c6a64f2cdb69
Author: Patrick Palka
Date: Wed Apr 30 10:54:23 2025 -0400
c++: UNBOUND_CLASS_TEMPLATE context substitution [PR119981]
In r15-123 and r14-11434 we unconditionally set processing_template_decl
when substituting the context of an UNBOUND_CLASS_TEMPLATE, in order to
handle instantiation of the dependently scoped friend declaration
template
template
friend class A::B;
where the scope A remains dependent after instantiation. But this
turns out to misbehave for the UNBOUND_CLASS_TEMPLATE in the below
testcase representing
g<[]{}>::template fn
since with the flag set substituting the args of test3 into the lambda
causes us to defer the substitution and yield a lambda that still looks
dependent, which in turn makes g<[]{}> still dependent and not suitable
for qualified name lookup.
This patch restricts setting processing_template_decl during
UNBOUND_CLASS_TEMPLATE substitution to the case where there are multiple
levels of introduced template parameters, as in the friend declaration.
(This means we need to substitute the template parameter list(s) first,
which makes sense since they lexically appear first.)
PR c++/119981
PR c++/119378
gcc/cp/ChangeLog:
* pt.cc (tsubst) : Substitute
into template parameter list first. When substituting the
context, only set processing_template_decl if there's more
than one level of introduced template parameters.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/lambda-targ15.C: New test.
Reviewed-by: Jason Merrill
(cherry picked from commit 05ea8baf6ff96c77a9a2467d5c45b1ed575fca92)
[Bug c++/119981] [14/15/16 Regression] rejects lambda used a template argument with inner template as a template param since r15-123
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119981
--- Comment #5 from GCC Commits ---
The releases/gcc-14 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:30432ffd9220cc949ef470c47455c6a64f2cdb69
commit r14-11706-g30432ffd9220cc949ef470c47455c6a64f2cdb69
Author: Patrick Palka
Date: Wed Apr 30 10:54:23 2025 -0400
c++: UNBOUND_CLASS_TEMPLATE context substitution [PR119981]
In r15-123 and r14-11434 we unconditionally set processing_template_decl
when substituting the context of an UNBOUND_CLASS_TEMPLATE, in order to
handle instantiation of the dependently scoped friend declaration
template
template
friend class A::B;
where the scope A remains dependent after instantiation. But this
turns out to misbehave for the UNBOUND_CLASS_TEMPLATE in the below
testcase representing
g<[]{}>::template fn
since with the flag set substituting the args of test3 into the lambda
causes us to defer the substitution and yield a lambda that still looks
dependent, which in turn makes g<[]{}> still dependent and not suitable
for qualified name lookup.
This patch restricts setting processing_template_decl during
UNBOUND_CLASS_TEMPLATE substitution to the case where there are multiple
levels of introduced template parameters, as in the friend declaration.
(This means we need to substitute the template parameter list(s) first,
which makes sense since they lexically appear first.)
PR c++/119981
PR c++/119378
gcc/cp/ChangeLog:
* pt.cc (tsubst) : Substitute
into template parameter list first. When substituting the
context, only set processing_template_decl if there's more
than one level of introduced template parameters.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/lambda-targ15.C: New test.
Reviewed-by: Jason Merrill
(cherry picked from commit 05ea8baf6ff96c77a9a2467d5c45b1ed575fca92)
[Bug c++/119981] [14/15/16 Regression] rejects lambda used a template argument with inner template as a template param since r15-123
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119981 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Patrick Palka --- Fixed for GCC 14.3 and 15.2, thanks for the bug report.
[Bug target/120042] New: [16] RISC-V: stage1 fails to build with error: ‘dominated_by_p’ was not declared in this scope in tree-vectorizer.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120042 Bug ID: 120042 Summary: [16] RISC-V: stage1 fails to build with error: ‘dominated_by_p’ was not declared in this scope in tree-vectorizer.h Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ewlu at rivosinc dot com Target Milestone: --- Postcommit is failing to build stage1 with error In file included from ../../../gcc/gcc/config/riscv/riscv-vector-costs.cc:38: ../../../gcc/gcc/tree-vectorizer.h: In function ‘_stmt_vec_info* get_later_stmt(stmt_vec_info, stmt_vec_info)’: ../../../gcc/gcc/tree-vectorizer.h:1885:28: error: ‘CDI_DOMINATORS’ was not declared in this scope 1885 | else if (dominated_by_p (CDI_DOMINATORS, | ^~ https://github.com/patrick-rivos/gcc-postcommit-ci/issues/3053 Ran on r15-9863-g3584aab37f5 and problem persists Believe it's caused by r15-9859-ga6cfde60d8c config command: $ /scratch/ewlu/ci/triage/baseline/build/../gcc/configure --target=riscv64-unknown-linux-gnu --prefix=/scratch/ewlu/ci/triage/baseline/build --with-sysroot=/scratch/ewlu/ci/triage/baseline/build/sysroot --with-newlib --without-headers --disable-shared --disable-threads --with-system-zlib --enable-tls --enable-languages=c --disable-libatomic --disable-libmudflap --disable-libssp --disable-libquadmath --disable-libgomp --disable-nls --disable-bootstrap --src=../../gcc --enable-multilib --with-abi=lp64d --with-arch=rv64imafdc --with-tune=rocket --with-isa-spec=20191213 CFLAGS_FOR_TARGET=-O2-mcmodel=medlow CXXFLAGS_FOR_TARGET=-O2 -mcmodel=medlow
[Bug fortran/119994] Valid specification expression in block rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119994 --- Comment #6 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #5) > The thread on the J3 ML starts here: > > https://mailman.j3-fortran.org/pipermail/j3/2025-April/015230.html While John Reid thinks the code is valid F2018, Robert Corbett points to clarifications in F2023 19.3.1 regarding scope: The example in comment#0 is invalid, as "this" is a local identifier, and using it in a BLOCK construct does not make it host-associated. The example in comment#1 is valid, as the use of "this" in the internal subroutine makes it host-associated. I hope I summarized this properly. Now after looking at how we treat host-association, I stumbled over the following snippet in resolve_variable: /* If a symbol has been host_associated mark it. This is used latter, to identify if aliasing is possible via host association. */ if (sym->attr.flavor == FL_VARIABLE && (!sym->ns->code || sym->ns->code->op != EXEC_BLOCK || !sym->ns->code->ext.block.assoc) && gfc_current_ns->parent && (gfc_current_ns->parent == sym->ns || (gfc_current_ns->parent->parent && gfc_current_ns->parent->parent == sym->ns))) sym->attr.host_assoc = 1; This part sets sym->attr.host_assoc for both testcases, but according to the discussion it should not for the case in comment#0.
[Bug libstdc++/120029] Dangling iterator usage in std::filesystem::path::operator+=(const std::filesystem::path &p) when this == p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120029 --- Comment #7 from Jonathan Wakely --- ASan pointed out somewhere this isn't quite right yet, but I can fix it.
[Bug tree-optimization/120043] [15/16 Regression] wrong code at -O{s,2,3} with -fallow-store-data-races on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120043 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|pinskia at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #3 from Andrew Pinski --- Actually I am going to let someone else fix this.
[Bug tree-optimization/120043] [15/16 Regression] wrong code at -O{s,2,3} with -fallow-store-data-races on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120043 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Keywords|needs-bisection | --- Comment #2 from Andrew Pinski --- r15-1391-g4b75ed33fa5fd6 introduced it. /* If LHS is an access to a local variable without address-taken (or when we allow data races) and known not to trap, we could always safely move down the store. */ if (ref_can_have_store_data_races (lhs) || tree_could_trap_p (lhs)) return false; The problem is we don't consider if lhs is a const global variable, it will fault when a store happens to it. tree_could_trap_p only consider loads I think.
[Bug ipa/120044] [12/13/14/15/16 Regression] wrong code at -O1 and above with "-fno-early-inlining -fno-tree-fre -fno-tree-pre -fno-code-hoisting" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120044 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2025-04-30 Summary|wrong code at -O1 and above |[12/13/14/15/16 Regression] |with "-fno-early-inlining |wrong code at -O1 and above |-fno-tree-fre -fno-tree-pre |with "-fno-early-inlining |-fno-code-hoisting" on |-fno-tree-fre -fno-tree-pre |x86_64-linux-gnu|-fno-code-hoisting" on ||x86_64-linux-gnu Component|tree-optimization |ipa Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Target Milestone|--- |12.5 --- Comment #1 from Andrew Pinski --- c.b = 0;
