[Bug c++/109172] [10/11/12/13 Regression] g++ calls a private destructor with the keyword throw after the try-block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109172
--- Comment #6 from Mike Smith ---
(In reply to CVS Commits from comment #4)
> The trunk branch has been updated by Jason Merrill :
>
> https://gcc.gnu.org/g:890043314a7f405081990ea9d0cb577dd44f883f
>
> commit r13-6742-g890043314a7f405081990ea9d0cb577dd44f883f
> Author: Jason Merrill
> Date: Fri Mar 17 15:27:10 2023 -0400
>
> c++: throw and private destructor [PR109172]
>
> Since we aren't going through the normal call machinery, we need to check
> the dtor access specifically.
>
> PR c++/109172
>
> gcc/cp/ChangeLog:
>
> * except.cc (build_throw): Check dtor access.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/eh/dtor4.C: New test.
Thank you for addressing this quickly, I don't know if backporting will be
necessary,
About the test written in dtor4.C,
I don't know how testing is supposed to work, but if the goal is to confirm
that this fails to compile and link, linking will fail due to a missing
implementation, and since now, compiling will fail due to the private
destructor, so no matter what this will fail to build, shouldn't the body of
the destructor here be defined like
~Demo()
{
}
this?
[Bug c++/69818] warn for C++ functional cast expression on pointer or reference (i.e. add -Wfunctional-cast)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69818 --- Comment #9 from Eric Gallager --- I've learned that there's another name for function-style casts that people sometimes use: constructor-style casts. So, there might be some bikeshedding to do about the name of the option...
[Bug c++/109169] Feature request: Allow omitted template prompts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109169 --- Comment #14 from steve02081504 --- (In reply to Andrew Pinski from comment #13) > See http://womble.decadent.org.uk/c++/template-faq.html#disambiguation also > to better understand the reason why GCC implements it this way and why it is > hard to implement this "extension" in all cases. But I guess type_info.some_class_name a; is not allowed, right? Only in the case of decltype(type_info)::name do we need to consider whether this is a typename or a template, and in the case of type_info.name this should always be a template?
[Bug c++/109169] Feature request: Allow omitted template prompts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109169 --- Comment #13 from Andrew Pinski --- See http://womble.decadent.org.uk/c++/template-faq.html#disambiguation also to better understand the reason why GCC implements it this way and why it is hard to implement this "extension" in all cases.
[Bug c++/109169] Feature request: Allow omitted template prompts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109169 --- Comment #12 from Andrew Pinski --- Right and I am saying it is hard to support in a parser. That is exactly why the language requires the template keyword here is to distinguish and help out the parser. Basically I am saying the whole point of template here is to help the parser out to figure out what it should be next otherwise it cannot figure out. How msvc implements without it, I don't know and really don't care.
[Bug c++/109169] Feature request: Allow omitted template prompts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109169 --- Comment #11 from steve02081504 --- (In reply to Andrew Pinski from comment #10) > Take: > type_info.can_convert_to > > The first part is dependent so when it goes to parse the next identifier, > the parser does not know that can_convert_to is a template or not. > So it thinks < is the less than operator rather than the start of a template > argument. > > So the fix for the code is: > type_info.template can_convert_to > > Which is the portable fix and even required by the standard to sign to the > compiler the next identifier will start naming of a template. I am not sure if I am making myself clear but msvc can compile such code and that is the reason for my feature request?
[Bug fortran/109105] Error-prone format string building in resolve.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109105
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Comment #1 from Jerry DeLisle ---
Can you give an example of what this one should look like?
snprintf (msg, sizeof (msg),
_("Inconsistent ranks for operator at %%L and %%L"));
goto bad_op;
[Bug c++/109169] Feature request: Allow omitted template prompts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109169 --- Comment #10 from Andrew Pinski --- Take: type_info.can_convert_to The first part is dependent so when it goes to parse the next identifier, the parser does not know that can_convert_to is a template or not. So it thinks < is the less than operator rather than the start of a template argument. So the fix for the code is: type_info.template can_convert_to Which is the portable fix and even required by the standard to sign to the compiler the next identifier will start naming of a template.
[Bug c++/109169] Feature request: Allow omitted template prompts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109169 --- Comment #9 from steve02081504 --- I don't quite understand why this is correct, can you elaborate on why and how to change the code to bypass the error reporting? Thanks.
[Bug testsuite/105959] new test case c-c++-common/diagnostic-format-sarif-file-4.c from r13-967-g6cf276ddf22066 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105959 --- Comment #14 from Hans-Peter Nilsson --- (In reply to David Malcolm from comment #13) > Created attachment 54698 [details] > Patch that I'm about to put through full testing (and of course there was an additional hurdle to DTRT for the new argument, heh) Yes, like that, LGTM, thanks! (not an approver)
[Bug rtl-optimization/109179] [13 Regression] addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179 Peter Bergner changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #23 from Peter Bergner --- (In reply to Vladimir Makarov from comment #21) > (In reply to Jakub Jelinek from comment #20) > > That LGTM, but Vlad is the maintainer here... > > It looks ok for me too. Ok, the above patch bootstrapped with no errors and the testsuite run showed no regressions compared to the commit before Vlad's patch, so I pushed the fix as approved. Thanks for everyone's help!
[Bug rtl-optimization/109179] [13 Regression] addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179 --- Comment #22 from CVS Commits --- The master branch has been updated by Peter Bergner : https://gcc.gnu.org/g:44a13125a0d56dbabb9bc61de7ff8bf94fb57928 commit r13-6745-g44a13125a0d56dbabb9bc61de7ff8bf94fb57928 Author: Peter Bergner Date: Fri Mar 17 19:01:45 2023 -0500 lra: Ignore debug insns and notes in combine_reload_insn [PR109179] We ICE in combine_reload_insn if we've deleted the TO insn operand during processing, because lra_get_insn_recog_data doesn't expect to see the note that replaces the deleted insn. The solution here is to exit early if TO is a debug insn or note. 2023-03-17 Peter Bergner gcc/ PR rtl-optimization/109179 * lra-constraints.cc (combine_reload_insn): Enforce TO is not a debug insn or note. Move the tests earlier to guard lra_get_insn_recog_data.
[Bug c++/108975] [10/11/12/13 Regression] ICE on constexpr variable used as nontype template since r9-5473-ge32fc4499f863f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975 --- Comment #13 from CVS Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:6f90de97634d6f1617a054429f28b85fbfbd8b6f commit r13-6743-g6f90de97634d6f1617a054429f28b85fbfbd8b6f Author: Jason Merrill Date: Fri Mar 17 17:26:40 2023 -0400 c++: constant, array, lambda, template [PR108975] When a lambda refers to a constant local variable in the enclosing scope, we tentatively capture it, but if we end up pulling out its constant value, we go back at the end of the lambda and prune any unneeded captures. Here while parsing the template we decided that the dim capture was unneeded, because we folded it away, but then we brought back the use in the template trees that try to preserve the source representation with added type info. So then when we tried to instantiate that use, we couldn't find what it was trying to use, and crashed. Fixed by not trying to prune when parsing a template; we'll prune at instantiation time. PR c++/108975 gcc/cp/ChangeLog: * lambda.cc (prune_lambda_captures): Don't bother in a template. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/lambda/lambda-const11.C: New test.
[Bug c++/106890] [10/11/12/13 Regression] virtual inheritance triggers compiler error when instatiating derived class with in-class initialization since r8-2709-g12659e10c7820071
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106890 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug analyzer/109094] [13 Regression] ICE in -fanalyzer seen in qemu's target/i386/tcg/translate.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109094 --- Comment #8 from David Malcolm --- Created attachment 54700 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54700=edit Patch that I'm about to put through full testing
[Bug c++/109180] New: Explicit template instantiation doesn't work for constexpr destructors on arm32 when optimizations are enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109180
Bug ID: 109180
Summary: Explicit template instantiation doesn't work for
constexpr destructors on arm32 when optimizations are
enabled
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: idhameed at protonmail dot com
Target Milestone: ---
Example (compile with "g++ -std=c++20 -O -c"):
===
template
struct record {
constexpr ~record() { }
};
inline record
return_record() { return {}; }
template record::~record();
===
Compiler Explorer: https://godbolt.org/z/j37rvr961
GCC 10+ targeting 32-bit ARM won't emit any symbols for record::~record
when using most -O levels (-O, -O2, -O3, -Ofast, -Og). Using -fno-inline--or
placing the explicit instantiation of record::~record above the
definition of return_record--works around this bug and causes a symbol for
record::~record to be emitted, as I'd expect. x86-64 GCC doesn't have
this problem.
The original, non-minimized problem I encountered: GCC 12.2.0 as a
cross-compiler on an x86-64 host targeting arm-linux-gnueabihf can't be used to
compile and link LLVM 15's libc++, because libc++'s implementation of
std::basic_string has code that fits the aformentioned pattern--there's an
overload of `std::__1::literals::string_literals::operator "" s` that returns a
basic_string. I tried the release/15.x branch of llvm-project at commit
92e7ef99303f8f367f279ccfa2393e4b96db915a.
[Bug fortran/109171] initialization using %re causes segfault, as an assignment does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109171 --- Comment #4 from urbanjost at comcast dot net --- Try that again. 101047. Not sure what happened to the paste buffer to get that other number. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101047
[Bug fortran/109171] initialization using %re causes segfault, as an assignment does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109171 --- Comment #3 from urbanjost at comcast dot net --- When you said you thought it was a duplicate I spent some time rechecking, and I think this is covered by 50991? Very different keywords and example, but if no pointer allocation is working at all, this is just a case of that more generic issue?
[Bug analyzer/109094] [13 Regression] ICE in -fanalyzer seen in qemu's target/i386/tcg/translate.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109094 --- Comment #7 from David Malcolm --- Trunk: https://godbolt.org/z/MKh4h1ccP 12.2: https://godbolt.org/z/73EY4TMcx (no ICE, but assertions likely disabled)
[Bug rtl-optimization/109179] [13 Regression] addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179 --- Comment #21 from Vladimir Makarov --- (In reply to Jakub Jelinek from comment #20) > That LGTM, but Vlad is the maintainer here... It looks ok for me too.
[Bug analyzer/109094] [13 Regression] ICE in -fanalyzer seen in qemu's target/i386/tcg/translate.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109094 David Malcolm changed: What|Removed |Added Attachment #54637|0 |1 is obsolete|| --- Comment #6 from David Malcolm --- Created attachment 54699 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54699=edit Reduced reproducer
[Bug rtl-optimization/109179] [13 Regression] addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179 --- Comment #20 from Jakub Jelinek --- That LGTM, but Vlad is the maintainer here...
[Bug rtl-optimization/109179] [13 Regression] addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179 --- Comment #19 from Peter Bergner --- (In reply to Peter Bergner from comment #18) > (In reply to Jakub Jelinek from comment #16) > > Can't you move all the tests that don't need id or static_id (all but one) > > before the > > lra_insn_recog_data_t id = lra_get_insn_recog_data (to); > > struct lra_static_insn_data *static_id = id->insn_static_data; > > instead? > > Ok, single_set is also a call, so maybe keep that one too? > > > > I know, microoptimizations... > > Looking at lra_get_insn_recog_data() versus the common case for > single_set(), I think moving the single_set() call earlier is fine too, and > it simplifies the final code with just the one early out tests rather than > splitting them up. Ah, nevermind, we have the "|| id->used_insn_alternative == LRA_UNKNOWN_ALT" which we can't move. Then I'll keep the single_set() close to it's use of the result just after. How about this? --- a/gcc/lra-constraints.cc +++ b/gcc/lra-constraints.cc @@ -5014,14 +5014,19 @@ combine_reload_insn (rtx_insn *from, rtx_insn *to) enum reg_class to_class, from_class; int n, nop; signed char changed_nops[MAX_RECOG_OPERANDS + 1]; - lra_insn_recog_data_t id = lra_get_insn_recog_data (to); - struct lra_static_insn_data *static_id = id->insn_static_data; /* Check conditions for second memory reload and original insn: */ if ((targetm.secondary_memory_needed == hook_bool_mode_reg_class_t_reg_class_t_false) - || NEXT_INSN (from) != to || CALL_P (to) - || id->used_insn_alternative == LRA_UNKNOWN_ALT + || NEXT_INSN (from) != to + || !NONDEBUG_INSN_P (to) + || CALL_P (to)) +return false; + + lra_insn_recog_data_t id = lra_get_insn_recog_data (to); + struct lra_static_insn_data *static_id = id->insn_static_data; + + if (id->used_insn_alternative == LRA_UNKNOWN_ALT || (set = single_set (from)) == NULL_RTX) return false; from_reg = SET_DEST (set);
[Bug rtl-optimization/109179] [13 Regression] addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179 --- Comment #18 from Peter Bergner --- (In reply to Jakub Jelinek from comment #16) > Can't you move all the tests that don't need id or static_id (all but one) > before the > lra_insn_recog_data_t id = lra_get_insn_recog_data (to); > struct lra_static_insn_data *static_id = id->insn_static_data; > instead? > Ok, single_set is also a call, so maybe keep that one too? > > I know, microoptimizations... Looking at lra_get_insn_recog_data() versus the common case for single_set(), I think moving the single_set() call earlier is fine too, and it simplifies the final code with just the one early out tests rather than splitting them up.
[Bug fortran/85877] [10/11/12/13 Regression] ICE in fold_convert_loc, at fold-const.c:2449
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85877 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #11 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2023-March/059085.html
[Bug c++/109172] [10/11/12/13 Regression] g++ calls a private destructor with the keyword throw after the try-block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109172 Jason Merrill changed: What|Removed |Added Target Milestone|10.5|13.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Jason Merrill --- Fixed for GCC 13. In general I'm not inclined to backport accepts-invalid fixes, but am open to discussion.
[Bug rtl-optimization/109179] [13 Regression] addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179 --- Comment #17 from Peter Bergner --- (In reply to Jakub Jelinek from comment #16) > Can't you move all the tests that don't need id or static_id (all but one) > before the > lra_insn_recog_data_t id = lra_get_insn_recog_data (to); > struct lra_static_insn_data *static_id = id->insn_static_data; > instead? > Ok, single_set is also a call, so maybe keep that one too? > > I know, microoptimizations... I can do that after my current run is done. I just wanted to verify the one test was enough to fix the ICE and wasn't looking closely at what all could be moved earlier.
[Bug c++/109172] [10/11/12/13 Regression] g++ calls a private destructor with the keyword throw after the try-block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109172 --- Comment #4 from CVS Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:890043314a7f405081990ea9d0cb577dd44f883f commit r13-6742-g890043314a7f405081990ea9d0cb577dd44f883f Author: Jason Merrill Date: Fri Mar 17 15:27:10 2023 -0400 c++: throw and private destructor [PR109172] Since we aren't going through the normal call machinery, we need to check the dtor access specifically. PR c++/109172 gcc/cp/ChangeLog: * except.cc (build_throw): Check dtor access. gcc/testsuite/ChangeLog: * g++.dg/eh/dtor4.C: New test.
[Bug rtl-optimization/109179] [13 Regression] addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179 --- Comment #16 from Jakub Jelinek --- Can't you move all the tests that don't need id or static_id (all but one) before the lra_insn_recog_data_t id = lra_get_insn_recog_data (to); struct lra_static_insn_data *static_id = id->insn_static_data; instead? Ok, single_set is also a call, so maybe keep that one too? I know, microoptimizations...
[Bug c++/108975] [10/11/12/13 Regression] ICE on constexpr variable used as nontype template since r9-5473-ge32fc4499f863f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug rtl-optimization/109179] [13 Regression] addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179 --- Comment #15 from Peter Bergner --- (In reply to Vladimir Makarov from comment #14) > Peter, sorry for troubles and thank you for working on it. The patch is ok > for me. Could you commit the patch if the bootstrap is ok. Will do and no problem. I'll also compare the testsuite results to the testsuite results from the commit before yours, just to be sure no other non-ICE errors crept in.
[Bug c++/109159] [10/11/12/13 Regression] explicit constructor is used in copy-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109159 --- Comment #3 from Marek Polacek --- This hunk broke it: @@ -3251,6 +3251,12 @@ add_template_candidate_real (struct z_candidate **candidates, tree tmpl, goto fail; } + /* Now the explicit specifier might have been deduced; check if this + declaration is explicit. If it is and we're ignoring non-converting + constructors, don't add this function to the set of candidates. */ + if ((flags & LOOKUP_ONLYCONVERTING) && DECL_NONCONVERTING_P (fn)) +return NULL; It doesn't check for BRACE_ENCLOSED_INITIALIZER_P (or some similar flag meaning we're initializing from an initializer_list) and that's the bug.
[Bug rtl-optimization/109179] [13 Regression] addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179 --- Comment #14 from Vladimir Makarov --- (In reply to Peter Bergner from comment #13) > (In reply to Peter Bergner from comment #12) > > I'll try moving the test up earlier and testing with that. > > So this fixes the ICEs on the two test cases above. I'll try a full > bootstrap with it. > > --- a/gcc/lra-constraints.cc > +++ b/gcc/lra-constraints.cc > @@ -5014,6 +5014,10 @@ combine_reload_insn (rtx_insn *from, rtx_insn *to) >enum reg_class to_class, from_class; >int n, nop; >signed char changed_nops[MAX_RECOG_OPERANDS + 1]; > + > + if (!NONDEBUG_INSN_P (to)) > +return false; > + >lra_insn_recog_data_t id = lra_get_insn_recog_data (to); >struct lra_static_insn_data *static_id = id->insn_static_data; Peter, sorry for troubles and thank you for working on it. The patch is ok for me. Could you commit the patch if the bootstrap is ok.
[Bug rtl-optimization/109179] [13 Regression] addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179 --- Comment #13 from Peter Bergner --- (In reply to Peter Bergner from comment #12) > I'll try moving the test up earlier and testing with that. So this fixes the ICEs on the two test cases above. I'll try a full bootstrap with it. --- a/gcc/lra-constraints.cc +++ b/gcc/lra-constraints.cc @@ -5014,6 +5014,10 @@ combine_reload_insn (rtx_insn *from, rtx_insn *to) enum reg_class to_class, from_class; int n, nop; signed char changed_nops[MAX_RECOG_OPERANDS + 1]; + + if (!NONDEBUG_INSN_P (to)) +return false; + lra_insn_recog_data_t id = lra_get_insn_recog_data (to); struct lra_static_insn_data *static_id = id->insn_static_data;
[Bug rtl-optimization/109179] [13 Regression] addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179 --- Comment #12 from Peter Bergner --- (In reply to Jakub Jelinek from comment #7) > So perhaps: > --- gcc/lra-constraints.cc.jj 2023-03-17 16:09:09.162136438 +0100 > +++ gcc/lra-constraints.cc2023-03-17 21:37:04.799285670 +0100 > @@ -5020,7 +5020,9 @@ combine_reload_insn (rtx_insn *from, rtx >/* Check conditions for second memory reload and original insn: */ >if ((targetm.secondary_memory_needed > == hook_bool_mode_reg_class_t_reg_class_t_false) > - || NEXT_INSN (from) != to || CALL_P (to) > + || NEXT_INSN (from) != to > + || !NONDEBUG_INSN_P (to) > + || CALL_P (to) >|| id->used_insn_alternative == LRA_UNKNOWN_ALT >|| (set = single_set (from)) == NULL_RTX) > return false; > ? This doesn't work as is, since the ICE is occurring on code before we get here in the function. Specifically here: lra_insn_recog_data_t id = lra_get_insn_recog_data (to); I'll try moving the test up earlier and testing with that.
[Bug other/109163] SARIF (and other JSON) output files are non-deterministic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109163 David Malcolm changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-March/6 ||14165.html Keywords||patch Status|ASSIGNED|WAITING --- Comment #3 from David Malcolm --- Patch posted for review: [PATCH] json: preserve key-insertion order [PR109163] https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614165.html
[Bug rtl-optimization/109179] [13 Regression] addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #11 from Jakub Jelinek --- But in this case it has been removed in between: #0 set_insn_deleted (insn=0x7fffea13a340) at ../../gcc/emit-rtl.cc:4257 #1 0x00ac7d3e in lra_set_insn_deleted (insn=0x7fffea13a340) at ../../gcc/lra.cc:263 #2 0x00ad8de8 in check_and_process_move (change_p=0x7fffd26f, sec_mem_p=0x7fffd26e) at ../../gcc/lra-constraints.cc:1400 #3 0x00ae0034 in curr_insn_transform (check_only_p=false) at ../../gcc/lra-constraints.cc:4130 #4 0x00ae41d3 in lra_constraints (first_p=true) at ../../gcc/lra-constraints.cc:5314
[Bug rtl-optimization/109179] [13 Regression] addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179 --- Comment #10 from Peter Bergner --- (In reply to Jakub Jelinek from comment #7) > So perhaps: > --- gcc/lra-constraints.cc.jj 2023-03-17 16:09:09.162136438 +0100 > +++ gcc/lra-constraints.cc2023-03-17 21:37:04.799285670 +0100 > @@ -5020,7 +5020,9 @@ combine_reload_insn (rtx_insn *from, rtx >/* Check conditions for second memory reload and original insn: */ >if ((targetm.secondary_memory_needed > == hook_bool_mode_reg_class_t_reg_class_t_false) > - || NEXT_INSN (from) != to || CALL_P (to) > + || NEXT_INSN (from) != to > + || !NONDEBUG_INSN_P (to) > + || CALL_P (to) >|| id->used_insn_alternative == LRA_UNKNOWN_ALT >|| (set = single_set (from)) == NULL_RTX) > return false; > ? I can give this try. Although it would be good to know from Vlad whether it's invalid to ever pass a debug insn to combine_reload_insn() or not.
[Bug rtl-optimization/109179] [13 Regression] addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179 --- Comment #9 from Vladimir Makarov --- (In reply to Jakub Jelinek from comment #7) > So perhaps: > --- gcc/lra-constraints.cc.jj 2023-03-17 16:09:09.162136438 +0100 > +++ gcc/lra-constraints.cc2023-03-17 21:37:04.799285670 +0100 > @@ -5020,7 +5020,9 @@ combine_reload_insn (rtx_insn *from, rtx >/* Check conditions for second memory reload and original insn: */ >if ((targetm.secondary_memory_needed > == hook_bool_mode_reg_class_t_reg_class_t_false) > - || NEXT_INSN (from) != to || CALL_P (to) > + || NEXT_INSN (from) != to > + || !NONDEBUG_INSN_P (to) > + || CALL_P (to) >|| id->used_insn_alternative == LRA_UNKNOWN_ALT >|| (set = single_set (from)) == NULL_RTX) > return false; > ? Yes, that is what I am trying to do. For me only question why is LRA works there on notes. LRA pushes only real insns to work stack.
[Bug rtl-optimization/109179] [13 Regression] addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179
--- Comment #8 from Peter Bergner ---
Here's another creduced test case, this one with -O2 optimization:
bergner@ltcden2-lp1:PR109179$ cat bug2.i
union u
{
_Float128 flt;
long sign;
};
_Float128
foo (long src)
{
union u var;
var.sign = src;
return var.flt;
}
bergner@ltcden2-lp1:PR109179$ gcc -S -O2 -mcpu=power8 bug2.i
during RTL pass: reload
bug2.i: In function ‘foo’:
bug2.i:13:1: internal compiler error: RTL check: expected elt 3 type 'e' or
'u', have '0' (rtx note) in PATTERN, at rtl.h:1509
13 | }
| ^
0x1148c663 rtl_check_failed_type2(rtx_def const*, int, int, int, char const*,
int, char const*)
/home/bergner/gcc/gcc-fsf-mainline-chip-ice/gcc/rtl.cc:907
0x10a0a207 PATTERN(rtx_def*)
/home/bergner/gcc/gcc-fsf-mainline-chip-ice/gcc/rtl.h:1509
0x1278c123 insn_extract(rtx_insn*)
/home/bergner/gcc/build/gcc-fsf-mainline-chip-ice-regtest/gcc/insn-extract.cc:23
0x1118c9e7 lra_set_insn_recog_data(rtx_insn*)
/home/bergner/gcc/gcc-fsf-mainline-chip-ice/gcc/lra.cc:1059
0x11194f23 lra_get_insn_recog_data(rtx_insn*)
/home/bergner/gcc/gcc-fsf-mainline-chip-ice/gcc/lra-int.h:493
0x111b8de7 combine_reload_insn
/home/bergner/gcc/gcc-fsf-mainline-chip-ice/gcc/lra-constraints.cc:5017
[Bug fortran/106945] [10/11/12/13 Regression] ICE: 'verify_gimple' failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106945 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from anlauf at gcc dot gnu.org --- Fixed on all open branches. Closing. Thanks for the report!
[Bug fortran/104332] [10/11/12/13 Regression] ICE in resolve_symbol, at fortran/resolve.cc:15815
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104332 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #13 from anlauf at gcc dot gnu.org --- Fixed on all open branches. Closing. Thanks for the report!
[Bug fortran/106945] [10/11/12/13 Regression] ICE: 'verify_gimple' failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106945 --- Comment #9 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:3cca6b5fa51fd271644082761de85e89fd56d69c commit r10-11256-g3cca6b5fa51fd271644082761de85e89fd56d69c Author: Harald Anlauf Date: Sat Mar 11 15:37:37 2023 +0100 Fortran: fix bounds check for copying of class expressions [PR106945] In the bounds check for copying of class expressions, the number of elements determined from a descriptor, returned as type gfc_array_index_type (i.e. a signed type), should be converted to the type of the passed element count, which is of type size_type_node (i.e. unsigned), for use in comparisons. gcc/fortran/ChangeLog: PR fortran/106945 * trans-expr.c (gfc_copy_class_to_class): Convert element counts in bounds check to common type for comparison. gcc/testsuite/ChangeLog: PR fortran/106945 * gfortran.dg/pr106945.f90: New test. (cherry picked from commit 2cf5f485e0351bb1faf46196a99e524688f3966e)
[Bug fortran/106945] [10/11/12/13 Regression] ICE: 'verify_gimple' failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106945 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:f68f0e69d988ca999c09953811f3cc722f114677 commit r11-10584-gf68f0e69d988ca999c09953811f3cc722f114677 Author: Harald Anlauf Date: Sat Mar 11 15:37:37 2023 +0100 Fortran: fix bounds check for copying of class expressions [PR106945] In the bounds check for copying of class expressions, the number of elements determined from a descriptor, returned as type gfc_array_index_type (i.e. a signed type), should be converted to the type of the passed element count, which is of type size_type_node (i.e. unsigned), for use in comparisons. gcc/fortran/ChangeLog: PR fortran/106945 * trans-expr.c (gfc_copy_class_to_class): Convert element counts in bounds check to common type for comparison. gcc/testsuite/ChangeLog: PR fortran/106945 * gfortran.dg/pr106945.f90: New test. (cherry picked from commit 2cf5f485e0351bb1faf46196a99e524688f3966e)
[Bug fortran/104332] [10/11/12/13 Regression] ICE in resolve_symbol, at fortran/resolve.cc:15815
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104332 --- Comment #12 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:c5cb9d8819eb9551d23f77e63cb3399115f0aab8 commit r10-11255-gc5cb9d8819eb9551d23f77e63cb3399115f0aab8 Author: Harald Anlauf Date: Thu Mar 9 18:59:08 2023 +0100 Fortran: fix ICE with bind(c) in block data [PR104332] gcc/fortran/ChangeLog: PR fortran/104332 * resolve.c (resolve_symbol): Avoid NULL pointer dereference while checking a symbol with the BIND(C) attribute. gcc/testsuite/ChangeLog: PR fortran/104332 * gfortran.dg/bind_c_usage_34.f90: New test. (cherry picked from commit e20e5d9dc11b64e8eabce6803c91cb5768207083)
[Bug fortran/104332] [10/11/12/13 Regression] ICE in resolve_symbol, at fortran/resolve.cc:15815
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104332 --- Comment #11 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:7ce83edf8ebbbc21b20aeed3a3ab06bb2e9e02cb commit r11-10583-g7ce83edf8ebbbc21b20aeed3a3ab06bb2e9e02cb Author: Harald Anlauf Date: Thu Mar 9 18:59:08 2023 +0100 Fortran: fix ICE with bind(c) in block data [PR104332] gcc/fortran/ChangeLog: PR fortran/104332 * resolve.c (resolve_symbol): Avoid NULL pointer dereference while checking a symbol with the BIND(C) attribute. gcc/testsuite/ChangeLog: PR fortran/104332 * gfortran.dg/bind_c_usage_34.f90: New test. (cherry picked from commit e20e5d9dc11b64e8eabce6803c91cb5768207083)
[Bug fortran/109171] initialization using %re causes segfault, as an assignment does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109171 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2023-03-17 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Keywords||wrong-code --- Comment #2 from anlauf at gcc dot gnu.org --- Confirmed. I also have the gut feeling that there is a duplicate. It appears that we do not initialize the pointer. Consider: program boom use, intrinsic :: iso_c_binding, only: c_loc implicit none complex, save, target :: a(4) = [(1.,0.), (2.,0.), (3.,0.), (4.,0.)] real, pointer :: p(:) => a(1:3:2)%re real, pointer :: q(:) q => a(1:3:2)%re print *, "size (p) =", size (p) print *, "size (q) =", size (q) print *, "c_loc(p(1)), c_loc(p(2)) =", c_loc(p(1)), c_loc(p(2)) print *, "c_loc(q(1)), c_loc(q(2)) =", c_loc(q(1)), c_loc(q(2)) ! print *, p ! this segfaults print *, q end program boom This prints e.g. size (p) = 1 size (q) = 2 c_loc(p(1)), c_loc(p(2)) =00 c_loc(q(1)), c_loc(q(2)) = 4202592 4202608 1. 3. Crayftn 14.0 (the only compiler that I found to work here): size (p) = 2 size (q) = 2 c_loc(p(1)), c_loc(p(2)) = 4210816, 4210832 c_loc(q(1)), c_loc(q(2)) = 4210816, 4210832 1., 3.
[Bug rtl-optimization/109179] [13 Regression] addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179 --- Comment #7 from Jakub Jelinek --- So perhaps: --- gcc/lra-constraints.cc.jj 2023-03-17 16:09:09.162136438 +0100 +++ gcc/lra-constraints.cc 2023-03-17 21:37:04.799285670 +0100 @@ -5020,7 +5020,9 @@ combine_reload_insn (rtx_insn *from, rtx /* Check conditions for second memory reload and original insn: */ if ((targetm.secondary_memory_needed == hook_bool_mode_reg_class_t_reg_class_t_false) - || NEXT_INSN (from) != to || CALL_P (to) + || NEXT_INSN (from) != to + || !NONDEBUG_INSN_P (to) + || CALL_P (to) || id->used_insn_alternative == LRA_UNKNOWN_ALT || (set = single_set (from)) == NULL_RTX) return false; ?
[Bug libstdc++/109165] std::hash>::operator() should be const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109165 --- Comment #2 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:c48be8298c27143c1a684c0cb9689c88d16f4b49 commit r13-6741-gc48be8298c27143c1a684c0cb9689c88d16f4b49 Author: Jonathan Wakely Date: Fri Mar 17 11:39:55 2023 + libstdc++: Add const to hash>::operator() [PR109165] libstdc++-v3/ChangeLog: PR libstdc++/109165 * include/std/coroutine (hash<>::operator()): Add const. * testsuite/18_support/coroutines/hash.cc: New test.
[Bug rtl-optimization/109179] [13 Regression] addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179 Andrew Pinski changed: What|Removed |Added Severity|normal |blocker Keywords||build, ice-on-valid-code Summary|addkf3-sw.c:51:1: internal |[13 Regression] |compiler error: RTL check: |addkf3-sw.c:51:1: internal |expected elt 3 type 'e' or |compiler error: RTL check: |'u', have '0' |expected elt 3 type 'e' or ||'u', have '0'
[Bug rtl-optimization/109179] addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179 --- Comment #6 from Vladimir Makarov --- Peter, thank you for reporting. I'll try to fix it today or revert it.
[Bug rtl-optimization/109179] addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179
--- Comment #5 from Peter Bergner ---
The "from" and "to" arguments to combine_reload_insn() are:
(gdb) pr from
(insn 19 17 9 2 (parallel [
(set (reg:TI 118 [ ])
(unspec:TI [
(reg:TI 117 [ _2 ])
] UNSPEC_P8V_RELOAD_FROM_VSX))
(clobber (reg:TI 123))
]) "bug.i":5:10 discrim 1 669 {reload_gpr_from_vsxti}
(nil))
(gdb) pr to
(note 9 19 13 2 NOTE_INSN_DELETED)
[Bug target/109179] addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179
--- Comment #4 from Peter Bergner ---
...on the following minimal test case:
bergner@ltcden2-lp1:PR109179$ cat bug.i
__int128 var;
__int128
foo (void)
{
return var;
}
bergner@ltcden2-lp1:PR109179$
/home/bergner/gcc/build/gcc-fsf-mainline-chip-ice-debug/./gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-mainline-chip-ice-debug/./gcc/ -S -O0
-mcpu=power8 bug.i
during RTL pass: reload
bug.i: In function ‘foo’:
bug.i:6:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u',
have '0' (rtx note) in PATTERN, at rtl.h:1509
6 | }
| ^
0x114dbcd3 rtl_check_failed_type2(rtx_def const*, int, int, int, char const*,
int, char const*)
/home/bergner/gcc/gcc-fsf-mainline-chip-ice/gcc/rtl.cc:907
0x10a18f6f PATTERN(rtx_def*)
/home/bergner/gcc/gcc-fsf-mainline-chip-ice/gcc/rtl.h:1509
0x12853b2b insn_extract(rtx_insn*)
/home/bergner/gcc/build/gcc-fsf-mainline-chip-ice-debug/gcc/insn-extract.cc:23
0x111c54c3 lra_set_insn_recog_data(rtx_insn*)
/home/bergner/gcc/gcc-fsf-mainline-chip-ice/gcc/lra.cc:1059
0x111ce06f lra_get_insn_recog_data(rtx_insn*)
/home/bergner/gcc/gcc-fsf-mainline-chip-ice/gcc/lra-int.h:493
0x111f2e63 combine_reload_insn
/home/bergner/gcc/gcc-fsf-mainline-chip-ice/gcc/lra-constraints.cc:5017
[Bug target/109179] addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179 --- Comment #3 from Peter Bergner --- The ICE is occurring with: Breakpoint 2, internal_error (gmsgid=0x1351b738 "RTL check: expected elt %d type '%c' or '%c', have '%c' (rtx %s) in %s, at %s:%d") at /home/bergner/gcc/gcc-fsf-mainline-chip-ice/gcc/diagnostic.cc:2152 2152 auto_diagnostic_group d; (gdb) bt #0 internal_error (gmsgid=0x1351b738 "RTL check: expected elt %d type '%c' or '%c', have '%c' (rtx %s) in %s, at %s:%d") at /home/bergner/gcc/gcc-fsf-mainline-chip-ice/gcc/diagnostic.cc:2152 #1 0x114dbcd4 in rtl_check_failed_type2 (r=0x75770340, n=3, c1=101, c2=117, file=0x134813c0 "/home/bergner/gcc/gcc-fsf-mainline-chip-ice/gcc/rtl.h", line=1509, func=0x13481f80 "PATTERN") at /home/bergner/gcc/gcc-fsf-mainline-chip-ice/gcc/rtl.cc:907 #2 0x10a18f70 in PATTERN (insn=0x75770340) at /home/bergner/gcc/gcc-fsf-mainline-chip-ice/gcc/rtl.h:1509 #3 0x12853b2c in insn_extract (insn=0x75770340) at insn-extract.cc:23 #4 0x111c54c4 in lra_set_insn_recog_data (insn=0x75770340) at /home/bergner/gcc/gcc-fsf-mainline-chip-ice/gcc/lra.cc:1059 #5 0x111ce070 in lra_get_insn_recog_data (insn=0x75770340) at /home/bergner/gcc/gcc-fsf-mainline-chip-ice/gcc/lra-int.h:493 #6 0x111f2e64 in combine_reload_insn (from=0x75770500, to=0x75770340) at /home/bergner/gcc/gcc-fsf-mainline-chip-ice/gcc/lra-constraints.cc:5017 ... (gdb) frame 3 #3 0x12853b2c in insn_extract (insn=0x75770340) at insn-extract.cc:23 23rtx pat = PATTERN (insn); (gdb) pr insn (note 9 19 13 2 NOTE_INSN_DELETED)
[Bug target/109179] addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179 --- Comment #2 from Peter Bergner --- (In reply to Peter Bergner from comment #1) > Vlad's recent commit looks like a promising candidate though: [snip] > I'm building with the commit before this to see whether we succeed or not. Bootstrap is into stage3 and we died in stage1 before, so I'm confident it is Vlad's commit.
[Bug rtl-optimization/109052] Unnecessary reload with -mfpmath=both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109052 Peter Bergner changed: What|Removed |Added CC||bergner at gcc dot gnu.org --- Comment #7 from Peter Bergner --- (In reply to Vladimir Makarov from comment #6) > I'd like to watch what the effect of the current patch would be first. > Although I tested the patch on many targets as usually for LRA the patch > might result in some troubles on some targets. But I hope nothing bad will > happen. I hit a bootstrap issue on powerpc64le-linux and it looks (still confirming) that this is probably the patch that caused it, since we're ICEing in your new combine_reload_insn() function. I opened PR109179 for the ICE. during RTL pass: reload addkf3-sw.c: In function ‘__addkf3_sw’: addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0' (rtx note) in PATTERN, at rtl.h:1509 51 | } | ^ 0x1148c663 rtl_check_failed_type2(rtx_def const*, int, int, int, char const*, int, char const*) /home/bergner/gcc/gcc-fsf-mainline-chip-ice-base/gcc/rtl.cc:907 0x10a0a207 PATTERN(rtx_def*) /home/bergner/gcc/gcc-fsf-mainline-chip-ice-base/gcc/rtl.h:1509 0x1278c12b insn_extract(rtx_insn*) /home/bergner/gcc/build/gcc-fsf-mainline-chip-ice-base-regtest/gcc/insn-extract.cc:23 0x1118c9e7 lra_set_insn_recog_data(rtx_insn*) /home/bergner/gcc/gcc-fsf-mainline-chip-ice-base/gcc/lra.cc:1059 0x11194f23 lra_get_insn_recog_data(rtx_insn*) /home/bergner/gcc/gcc-fsf-mainline-chip-ice-base/gcc/lra-int.h:493 0x111b8de7 combine_reload_insn /home/bergner/gcc/gcc-fsf-mainline-chip-ice-base/gcc/lra-constraints.cc:5017 0x111b9e4b lra_constraints(bool) /home/bergner/gcc/gcc-fsf-mainline-chip-ice-base/gcc/lra-constraints.cc:5231 0x111942a3 lra(_IO_FILE*) /home/bergner/gcc/gcc-fsf-mainline-chip-ice-base/gcc/lra.cc:2375 0x110fdd77 do_reload /home/bergner/gcc/gcc-fsf-mainline-chip-ice-base/gcc/ira.cc:5963 0x110fe5df execute /home/bergner/gcc/gcc-fsf-mainline-chip-ice-base/gcc/ira.cc:6149
[Bug target/109179] addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179 --- Comment #1 from Peter Bergner --- Vlad's recent commit looks like a promising candidate though: commit 57688950b9328cbb4a9c21eb3199f9132b5119d3 Author: Vladimir N. Makarov AuthorDate: Fri Mar 17 08:58:58 2023 -0400 Commit: Vladimir N. Makarov CommitDate: Fri Mar 17 09:07:20 2023 -0400 LRA: Implement combining secondary memory reload and original insn LRA creates secondary memory reload insns but do not try to combine it with the original insn. This patch implements a simple insn combining for such cases in LRA. PR rtl-optimization/109052 gcc/ChangeLog: * lra-constraints.cc: Include hooks.h. (combine_reload_insn): New function. (lra_constraints): Call it. gcc/testsuite/ChangeLog: * gcc.target/i386/pr109052.c: New. I'm building with the commit before this to see whether we succeed or not.
[Bug target/109179] addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179 Peter Bergner changed: What|Removed |Added Last reconfirmed||2023-03-17 Keywords||ice-checking Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Target||powerpc64le-linux Target Milestone|--- |13.0
[Bug target/109179] New: addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179 Bug ID: 109179 Summary: addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0' Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: bergner at gcc dot gnu.org Target Milestone: --- A new bootstrap ICE on trunk. Setting component to target until I narrow down the change that caused it. during RTL pass: reload addkf3-sw.c: In function ‘__addkf3_sw’: addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0' (rtx note) in PATTERN, at rtl.h:1509 51 | } | ^ 0x1148c663 rtl_check_failed_type2(rtx_def const*, int, int, int, char const*, int, char const*) /home/bergner/gcc/gcc-fsf-mainline-chip-ice-base/gcc/rtl.cc:907 0x10a0a207 PATTERN(rtx_def*) /home/bergner/gcc/gcc-fsf-mainline-chip-ice-base/gcc/rtl.h:1509 0x1278c12b insn_extract(rtx_insn*) /home/bergner/gcc/build/gcc-fsf-mainline-chip-ice-base-regtest/gcc/insn-extract.cc:23 0x1118c9e7 lra_set_insn_recog_data(rtx_insn*) /home/bergner/gcc/gcc-fsf-mainline-chip-ice-base/gcc/lra.cc:1059 0x11194f23 lra_get_insn_recog_data(rtx_insn*) /home/bergner/gcc/gcc-fsf-mainline-chip-ice-base/gcc/lra-int.h:493 0x111b8de7 combine_reload_insn /home/bergner/gcc/gcc-fsf-mainline-chip-ice-base/gcc/lra-constraints.cc:5017 0x111b9e4b lra_constraints(bool) /home/bergner/gcc/gcc-fsf-mainline-chip-ice-base/gcc/lra-constraints.cc:5231 0x111942a3 lra(_IO_FILE*) /home/bergner/gcc/gcc-fsf-mainline-chip-ice-base/gcc/lra.cc:2375 0x110fdd77 do_reload /home/bergner/gcc/gcc-fsf-mainline-chip-ice-base/gcc/ira.cc:5963 0x110fe5df execute /home/bergner/gcc/gcc-fsf-mainline-chip-ice-base/gcc/ira.cc:6149
[Bug c++/109172] [10/11/12/13 Regression] g++ calls a private destructor with the keyword throw after the try-block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109172 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/69410] [10/11/12 Regression] friend declarations in local classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69410 --- Comment #12 from Jason Merrill --- (In reply to Zopolis0 from comment #8) Thanks for your work on this bug!
[Bug c++/69410] [10/11/12/13 Regression] friend declarations in local classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69410 --- Comment #11 from CVS Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:ae7190e345a8d80310835cb83b3b41ef2aeb0d37 commit r13-6740-gae7190e345a8d80310835cb83b3b41ef2aeb0d37 Author: Jason Merrill Date: Fri Mar 17 09:43:48 2023 -0400 c++: namespace-scoped friend in local class [PR69410] do_friend was only considering class-qualified identifiers for the qualified-id case, but we also need to skip local scope when there's an explicit namespace scope. PR c++/69410 gcc/cp/ChangeLog: * friend.cc (do_friend): Handle namespace as scope argument. * decl.cc (grokdeclarator): Pass down in_namespace. gcc/testsuite/ChangeLog: * g++.dg/lookup/friend24.C: New test.
[Bug target/109178] ICE using __builtin_vec_xst_trunc built-in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109178 Peter Bergner changed: What|Removed |Added Known to work|10.0, 11.0 | --- Comment #2 from Peter Bergner --- (In reply to Peter Bergner from comment #0) > This ICEs on trunk and GCC 12 and works on GCC 11 and earlier. My bad. The built-in is new in GCC 12, so not a regression.
[Bug testsuite/105959] new test case c-c++-common/diagnostic-format-sarif-file-4.c from r13-967-g6cf276ddf22066 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105959 --- Comment #13 from David Malcolm --- Created attachment 54698 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54698=edit Patch that I'm about to put through full testing
[Bug target/109178] ICE using __builtin_vec_xst_trunc built-in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109178 Peter Bergner changed: What|Removed |Added CC||chip.kerchner at ibm dot com, ||segher at gcc dot gnu.org Target Milestone|--- |13.0 Last reconfirmed||2023-03-17 Keywords||ice-on-valid-code Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Target||powerpc*-*-* Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot gnu.org --- Comment #1 from Peter Bergner --- Mine.
[Bug target/109178] New: ICE using __builtin_vec_xst_trunc built-in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109178
Bug ID: 109178
Summary: ICE using __builtin_vec_xst_trunc built-in
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
We ICE on the following simple test case. This ICEs on trunk and GCC 12 and
works on GCC 11 and earlier.
bergner@ltcden2-lp1:~$ cat bug.c
#include
void
foo (signed int *dst, vector signed __int128 src)
{
__builtin_vec_xst_trunc(src, 0, dst);
}
bergner@ltcden2-lp1:~$ gcc -S -O2 -mcpu=power10 bug.c
bug.c: In function ‘foo’:
bug.c:7:1: error: unrecognizable insn:
7 | }
| ^
(insn 9 8 0 2 (set (mem:DI (reg:DI 119) [0 S8 A8])
(truncate:SI (reg:TI 120))) "bug4.c":6:3 -1
(nil))
during RTL pass: vregs
bug.c:7:1: internal compiler error: in extract_insn, at recog.cc:2791
The above should be mem:SI and is caused by a typo in the rs6000 built-in
rewrite in GCC 12. I have a patch I'm testing.
[Bug tree-optimization/108419] [13 Regression] Dead Code Elimination Regression at -O2 since r13-440-g98e475a8f58
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108419 --- Comment #4 from Andrew Macleod --- Not easily. I have started working on a phi analyzer for ranger to assist with various issues like this. It will analyze phi patterns to weed out the ssa-names that are just copies, and then allow the few remaining ssa-names that actually change the values in the phi seqeuence to be looked at more easily. It will help develop better initial ranges. So cases where the non-phi names are starting value and an increment or decrement can start with something better than VARYING. This will help with cases like https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107986 It can help identify cases where values will have restricted smallish ranges, such as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107822. Cases like this one with the second IV are trickier as there isnt a relation to dicover between the two IVs... at leats not easily. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107639 is a case like that too I think. When there are 2 IVs I dont suppose there is any way to indicate there is a connection? then if we can end up counting one, we might be able to do something with the other.
[Bug target/105554] [10/11/12 Regression] ICE: in emit_block_move_hints, at expr.cc:1829 since r9-5509-g5928bc2ec06dd4e7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105554 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED Summary|[10/11/12/13 Regression]|[10/11/12 Regression] ICE: |ICE: in |in emit_block_move_hints, |emit_block_move_hints, at |at expr.cc:1829 since |expr.cc:1829 since |r9-5509-g5928bc2ec06dd4e7 |r9-5509-g5928bc2ec06dd4e7 | --- Comment #22 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug target/105554] [10/11/12/13 Regression] ICE: in emit_block_move_hints, at expr.cc:1829 since r9-5509-g5928bc2ec06dd4e7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105554
--- Comment #21 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:24c06560a7fa39049911eeb8777325d112e0deb9
commit r13-6739-g24c06560a7fa39049911eeb8777325d112e0deb9
Author: Jakub Jelinek
Date: Fri Mar 17 18:59:56 2023 +0100
tree-inline: Fix up multiversioning with vector arguments [PR105554]
The following testcase ICEs, because we call tree_function_versioning from
old_decl which has target attributes not supporting V4DImode and so
DECL_MODE of DECL_ARGUMENTS is BLKmode, while new_decl supports those.
tree_function_versioning initially copies DECL_RESULT and DECL_ARGUMENTS
from old_decl to new_decl, then calls initialize_cfun to create cfun
and only when the cfun is created it can later actually remap_decl
DECL_RESULT and DECL_ARGUMENTS etc.
The problem is that initialize_cfun -> push_struct_function ->
allocate_struct_function calls relayout_decl on DECL_RESULT and
DECL_ARGUMENTS, which clobbers DECL_MODE of old_decl and we then ICE
because
of it.
In particular, allocate_struct_function does:
if (!abstract_p)
{
/* Now that we have activated any function-specific attributes
that might affect layout, particularly vector modes, relayout
each of the parameters and the result. */
relayout_decl (result);
for (tree parm = DECL_ARGUMENTS (fndecl); parm;
parm = DECL_CHAIN (parm))
relayout_decl (parm);
/* Similarly relayout the function decl. */
targetm.target_option.relayout_function (fndecl);
}
if (!abstract_p && aggregate_value_p (result, fndecl))
{
#ifdef PCC_STATIC_STRUCT_RETURN
cfun->returns_pcc_struct = 1;
#endif
cfun->returns_struct = 1;
}
Now, in the case of tree_function_versioning, I believe all that we need
from these is possibly the
targetm.target_option.relayout_function (fndecl);
call (arm only), we will remap DECL_RESULT and DECL_ARGUMENTS later on
and copy_decl_for_dup_finish in that case will handle all we need:
/* For vector typed decls make sure to update DECL_MODE according
to the new function context. */
if (VECTOR_TYPE_P (TREE_TYPE (copy)))
SET_DECL_MODE (copy, TYPE_MODE (TREE_TYPE (copy)));
We don't need the cfun->returns_*struct either, because we override it
in initialize_cfun a few lines later:
/* Copy items we preserve during cloning. */
...
cfun->returns_struct = src_cfun->returns_struct;
cfun->returns_pcc_struct = src_cfun->returns_pcc_struct;
So, to avoid the clobbering of DECL_RESULT/DECL_ARGUMENTS of old_decl,
the following patch arranges allocate_struct_function to be called with
abstract_p true and calls targetm.target_option.relayout_function (fndecl);
by hand.
The removal of DECL_RESULT/DECL_ARGUMENTS copying at the start of
initialize_cfun is removed because the only caller -
tree_function_versioning, does that unconditionally before.
2023-03-17 Jakub Jelinek
PR target/105554
* function.h (push_struct_function): Add ABSTRACT_P argument
defaulted
to false.
* function.cc (push_struct_function): Add ABSTRACT_P argument, pass
it
to allocate_struct_function instead of false.
* tree-inline.cc (initialize_cfun): Don't copy DECL_ARGUMENTS
nor DECL_RESULT here. Pass true as ABSTRACT_P to
push_struct_function. Call targetm.target_option.relayout_function
after it.
(tree_function_versioning): Formatting fix.
* gcc.target/i386/pr105554.c: New test.
[Bug c++/97700] Bogus error when a class containing a function pointer is used as a non-type template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97700 Andrew Pinski changed: What|Removed |Added CC||waffl3x at protonmail dot com --- Comment #4 from Andrew Pinski --- *** Bug 109168 has been marked as a duplicate of this bug. ***
[Bug c++/109168] bogus error: 'X' is not a valid template argument of type 'Y' because 'X' is not a variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109168 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from Andrew Pinski --- Dup of bug 97700. *** This bug has been marked as a duplicate of bug 97700 ***
[Bug tree-optimization/109176] internal compiler error: in to_constant, at poly-int.h:504
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109176 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||ktkachov at gcc dot gnu.org Target Milestone|--- |13.0 Ever confirmed|0 |1 Last reconfirmed||2023-03-17 --- Comment #2 from ktkachov at gcc dot gnu.org --- Confirmed. Running reduction
[Bug tree-optimization/108419] [13 Regression] Dead Code Elimination Regression at -O2 since r13-440-g98e475a8f58
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108419
Jakub Jelinek changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Slightly cleaned up testcase:
static int b = 6, c;
long d;
short h, i, j;
signed char k;
void foo (void);
short baz (int, int, int, int, int, int, int);
short qux (unsigned short, int, char, long);
short
bar (short l, short m)
{
return l + m;
}
static signed char
corge (void)
{
unsigned n;
for (n = -10U; n >= 14; n = bar (n, 8))
{
i = qux (b, 0, c, b);
j = baz (i, b, d < j, 5, 7, 9, 5);
k = 200 + n;
h = k % 5;
if (!h)
foo ();
}
return n;
}
int
main ()
{
b || corge ();
b = 1;
}
The loop iterates twice, with n -10U and -2U, in third iteration 6U fails the
6U >= 14 condition.
In GCC 12 as well as in r13-439 and r13-440 the loop IV is
# ivtmp.30_42 = PHI
and loop condition is
ivtmp.30_34 = ivtmp.30_42 + 8;
if (ivtmp.30_34 != 206)
while trunk has 2 IVs:
# RANGE [irange] unsigned int [38, 32767][4294934528, +INF] NONZERO
0xfffe
# n_32 = PHI
# RANGE [irange] unsigned int [1, +INF]
# ivtmp_2 = PHI
and
# RANGE [irange] unsigned short [30, +INF] NONZERO 0xfffe
l.0_27 = (unsigned short) n_32;
# RANGE [irange] unsigned short [0, 7][38, +INF] NONZERO 0xfffe
_28 = l.0_27 + 8;
# RANGE [irange] short int [-INF, 7][38, +INF] NONZERO 0xfffe
_29 = (short int) _28;
# RANGE [irange] unsigned int [0, 7][38, 32767][4294934528, +INF] NONZERO
0xfffe
n_30 = (unsigned int) _29;
ivtmp_43 = ivtmp_2 - 1;
if (ivtmp_43 != 0)
The r13-440 regression is in vrp2, previously we were able to determine that
because ivtmp.30_42 is [190, 190][198, 198]
then (signed char) of that is [-66, -66][-58, -58] and that % 5 is [-3, -3][-1,
-1].
Folding statement: _24 = (signed char) ivtmp.30_42;
- Loops range found for ivtmp.30_42: unsigned char [190, 198] and calculated
range :unsigned char [190, 190][198, 205]
-Global Exported: _24 = signed char [-66, -58] ... irange was : signed char
[-66, -66][-58, -58]
+Global Exported: _24 = signed char [-66, -58]
Not folded
Folding statement: k = _24;
Not folded
Folding statement: _25 = _24 % 5;
-Global Exported: _25 = signed char [-3, -1] ... irange was : signed char [-3,
-3][-1, -1]
+Global Exported: _25 = signed char [-4, 0]
is the first difference in the vrp2 dump between r13-439 and r13-440.
The other major change is starting with r13-3486-g4c5b1160776382772 when ivopts
uses the 2 IVs rather than one
and the convoluted increment by 8. It is actually only a normal increment by 8
if n_32 is in [0, 32759][-32777U, -1U]
but that is actually the case here.
I think the ranger doesn't iterate, right? So is there any way that it would
figure out the exact range for the IV?
[Bug c++/109176] internal compiler error: in to_constant, at poly-int.h:504
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109176 --- Comment #1 from Mathieu Malaterre --- Created attachment 54697 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54697=edit Preprocessed source gcc-13 % /usr/lib/gcc-snapshot/bin/g++ -freport-bug -DHWY_STATIC_DEFINE -I/home/malat/h/highway -O2 -g -DNDEBUG -fPIE -fvisibility=hidden -fvisibility-inlines-hidden -Wno-builtin-macro-redefined -D__DATE__=\"redacted\" -D__TIMESTAMP__=\"redacted\" -D__TIME__=\"redacted\" -fmerge-all-constants -Wall -Wextra -Wconversion -Wsign-conversion -Wvla -Wnon-virtual-dtor -fmath-errno -fno-exceptions -DHWY_IS_TEST=1 -DGTEST_HAS_PTHREAD=1 -MD -MT CMakeFiles/mask_test.dir/hwy/tests/mask_test.cc.o -MF CMakeFiles/mask_test.dir/hwy/tests/mask_test.cc.o.d -o CMakeFiles/mask_test.dir/hwy/tests/mask_test.cc.o -c /home/malat/h/highway/hwy/tests/mask_test.cc
[Bug c++/109177] New: Call to C++ function marked unavailable gets diagnosed twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109177
Bug ID: 109177
Summary: Call to C++ function marked unavailable gets diagnosed
twice
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
Reproducer:
$ cat t.cc
void f() __attribute__((unavailable));
void g() { f(); }
$ gcc/xgcc -B gcc -c t.cc
t.cc: In function ‘void g()’:
t.cc:2:13: error: ‘void f()’ is unavailable
2 | void g() { f(); }
|~^~
t.cc:1:6: note: declared here
1 | void f() __attribute__((unavailable));
| ^
t.cc:2:13: error: ‘void f()’ is unavailable
2 | void g() { f(); }
|~^~
t.cc:1:6: note: declared here
1 | void f() __attribute__((unavailable));
| ^
This only seems to happen in C++ mode, C diagnoses this once as expected.
[Bug c++/109169] Feature request: Allow omitted template prompts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109169 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #8 from Andrew Pinski --- Yes we are not going to add a feature where template keyword can be omitted. The reason is type_info.can_convert_to; Cis being parsed thinking < here is less than which is correct.
[Bug c++/109176] New: internal compiler error: in to_constant, at poly-int.h:504
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109176
Bug ID: 109176
Summary: internal compiler error: in to_constant, at
poly-int.h:504
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: malat at debian dot org
Target Milestone: ---
I cannot compile highway on arm64 with gcc-13 anymore.
Compilation fais with:
/home/malat/h/highway/hwy/tests/mask_test.cc:230:21: internal compiler error:
in to_constant, at poly-int.h:504
230 | HWY_NOINLINE void operator()(T /*unused*/, D d) {
| ^~~~
0x6a06eb poly_int_pod<2u, unsigned long>::to_constant() const [clone .part.0]
[clone .lto_priv.0]
../../src/gcc/poly-int.h:504
0xf5057b poly_int_pod<2u, unsigned long>::to_constant() const
../../src/gcc/poly-int.h:502
0x9451c3 nunits_for_known_piecewise_op
../../src/gcc/tree-vect-generic.cc:92
0x1e1b803 expand_vector_condition
../../src/gcc/tree-vect-generic.cc:1120
0x1a4b67b expand_vector_operations_1
../../src/gcc/tree-vect-generic.cc:2122
0x1a4b67b expand_vector_operations
../../src/gcc/tree-vect-generic.cc:2382
0x1a4b67b execute
../../src/gcc/tree-vect-generic.cc:2479
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
ref:
*
https://buildd.debian.org/status/fetch.php?pkg=highway=arm64=1.0.4%7Egit20230317.8681eb8-1=1679067803=0
[Bug testsuite/105959] new test case c-c++-common/diagnostic-format-sarif-file-4.c from r13-967-g6cf276ddf22066 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105959
--- Comment #12 from David Malcolm ---
Thanks for the ideas. If I hack in the following into dg-scan (to force the
scanned file to be treated as UTF-8 as it is read), then the existing case
works with both:
LC_ALL=C
LC_ALL=en_US.UTF-8
so perhaps I can do this just for scan-sarif-file
diff --git a/gcc/testsuite/lib/scanasm.exp b/gcc/testsuite/lib/scanasm.exp
index 4b018abcf3d..828002bf6e1 100644
--- a/gcc/testsuite/lib/scanasm.exp
+++ b/gcc/testsuite/lib/scanasm.exp
@@ -59,6 +59,7 @@ proc dg-scan { name positive testcase output_file orig_args }
{
return
}
set fd [open $output_file r]
+fconfigure $fd -encoding utf-8
set text [read $fd]
close $fd
[Bug c++/109169] Feature request: Allow omitted template prompts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109169 steve02081504 changed: What|Removed |Added Version|unknown |12.2.0 --- Comment #7 from steve02081504 --- (error info) ```text C:\Users\steve02081504\Documents\workstation\ELC_workdirs\ELC>x86_64-w64-mingw32-g++ -v Using built-in specs. COLLECT_GCC=E:\msys\mingw64\bin\x86_64-w64-mingw32-g++.exe COLLECT_LTO_WRAPPER=E:/msys/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../gcc-12.2.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/include --libexecdir=/mingw64/lib --enable-bootstrap --enable-checking=release --with-arch=nocona --with-tune=generic --enable-languages=c,lto,c++,fortran,ada,objc,obj-c++,jit --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-filesystem-ts --enable-libstdcxx-time --disable-libstdcxx-pch --enable-lto --enable-libgomp --disable-multilib --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev10, Built by MSYS2 project' --with-bugurl=https://github.com/msys2/MINGW-packages/issues --with-gnu-as --with-gnu-ld --disable-libstdcxx-debug --with-boot-ldflags=-static-libstdc++ --with-stage1-ldflags=-static-libstdc++ Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.2.0 (Rev10, Built by MSYS2 project) C:\Users\steve02081504\Documents\workstation\ELC_workdirs\ELC>x86_64-w64-mingw32-g++ -x c++ -std=c++23 temp.cpp In file included from .\parts\header_file\files\elc\_files/base_defs/base_defs/_body.hpp:54, from .\parts\header_file\files\elc\_files/base_defs/_body.hpp:53, from .\parts\header_file\files\elc\base_defs:50, from .\parts\header_file\files\elc\random:33: .\parts\header_file\files\elc\_files/base_defs/base_defs/hash.hpp:47:91: error: expected primary-expression before '>' token 47 | concept is_unstable_hash = type_info.can_convert_to; | ^ .\parts\header_file\files\elc\_files/base_defs/base_defs/hash.hpp:47:92: error: expected primary-expression before ';' token 47 | concept is_unstable_hash = type_info.can_convert_to; | ^ In file included from .\parts\header_file\files\elc\_files/base_defs/base_defs/_body.hpp:55: .\parts\header_file\files\elc\_files/base_defs/base_defs/range.hpp:50:74: error: expected primary-expression before '>' token 50 | template requires(type_info.can_convert_to) | ```
[Bug c++/109169] Feature request: Allow omitted template prompts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109169
--- Comment #6 from steve02081504 ---
Created attachment 54696
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54696=edit
temp.cpp
(In reply to Andrew Pinski from comment #4)
> You provide a full example of what you want?
> Because right now your example your provided does not even compile with msvc.
Strangely enough, when I tried to reproduce this requirement, I found that the
sample code I had written would compile.
```c++
#include
template
struct A {
template
static constexpr bool a = ::std::is_base_of_v;
};
template
A a{};
int main() {
return a.a;
}
```
I had no choice but to attach the files I couldn't get to compile and pass in
the attachment.
I didn't understand whether gcc could compile such things or not..
[Bug c/109151] UBsan misses a divide-by-zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109151 --- Comment #4 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:103d423f6ce72ccb03d55b7b1dfa2dabd5854371 commit r13-6738-g103d423f6ce72ccb03d55b7b1dfa2dabd5854371 Author: Jakub Jelinek Date: Fri Mar 17 16:10:14 2023 +0100 c, ubsan: Instrument even shortened divisions [PR109151] On the following testcase, the C FE decides to shorten the division because it has a guarantee that INT_MIN / -1 division won't be encountered, the first operand is widened from narrower unsigned and/or the second operand is a constant other than all ones (in this case both are true). The problem is that the narrower type in this case is _Bool and ubsan_instrument_division only instruments it if op0's type is INTEGER_TYPE or REAL_TYPE. Strangely this doesn't happen in C++ FE. Anyway, we only shorten divisions if the INT_MIN / -1 case is impossible, so I think we should be fine even with -fstrict-enums in C++ in case it shortened to ENUMERAL_TYPEs. The following patch just instruments those on the ubsan_instrument_division side. Perhaps only the first hunk and testcase might be needed because we shouldn't shorten if the other case could be triggered. 2023-03-17 Jakub Jelinek PR c/109151 * c-ubsan.cc (ubsan_instrument_division): Handle all scalar integral types rather than just INTEGER_TYPE. * c-c++-common/ubsan/div-by-zero-8.c: New test.
[Bug c++/109168] bogus error: 'X' is not a valid template argument of type 'Y' because 'X' is not a variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109168 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Last reconfirmed||2023-03-17 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Marek Polacek --- Not a regression.
[Bug c++/109172] [10/11/12/13 Regression] g++ calls a private destructor with the keyword throw after the try-block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109172 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Given that the class is empty, my bet from those two would be on r156842. Anyway, if I add int d; before private: in #c1, it started to be accepted only in r159428 aka DR475 I think (r159421 still rejects, r159430 accepts).
[Bug c++/109175] error: 'void* __builtin_memset(void*, int, long unsigned int)' writing 4 or more bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109175 --- Comment #3 from Mathieu Malaterre --- Compiling the preprocessed source: % /usr/lib/gcc-snapshot/bin/g++ --verbose -g -fstack-protector-strong -Wformat -Werror=format-security -DHWY_BROKEN_EMU128=0 -Wdate-time -D_FORTIFY_SOURCE=2 -fPIE -fvisibility=hidden -fvisibility-inlines-hid den -Wno-builtin-macro-redefined -fmerge-all-constants -Wall -Wextra -Wconversion -Wsign-conversion -Wvla -Wnon-virtual-dtor -fmath-errno -fno-exceptions -Werror -DHWY_IS_TEST=1 -O2 -c 13/convert_test.cc.ii Using built-in specs. COLLECT_GCC=/usr/lib/gcc-snapshot/bin/g++ Target: aarch64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 20230315-1' --with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2,rust --prefix=/usr/lib/gcc-snapshot --with-gcc-major-version-only --program-prefix= --enable-shared --enable-linker-build-id --disable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libquadmath --disable-libquadmath-support --enable-plugin --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --enable-fix-cortex-a53-843419 --disable-werror --enable-checking=yes,extra,rtl --build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-serialization=2 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.0.1 20230315 (experimental) [master r13-6680-ga9ae16db8cb] (Debian 20230315-1) COLLECT_GCC_OPTIONS='-v' '-g' '-fstack-protector-strong' '-Wformat=1' '-Werror=format-security' '-D' 'HWY_BROKEN_EMU128=0' '-Wdate-time' '-D' '_FORTIFY_SOURCE=2' '-fPIE' '-fvisibility=hidden' '-fvisibility-inlines-hidden' '-Wno-builtin-macro-redefined' '-fmerge-all-constants' '-Wall' '-Wextra' '-Wconversion' '-Wsign-conversion' '-Wvla' '-Wnon-virtual-dtor' '-fmath-errno' '-fno-exceptions' '-Werror' '-D' 'HWY_IS_TEST=1' '-O2' '-c' '-shared-libgcc' '-mlittle-endian' '-mabi=lp64' /usr/lib/gcc-snapshot/libexec/gcc/aarch64-linux-gnu/13/cc1plus -fpreprocessed 13/convert_test.cc.ii -quiet -dumpbase convert_test.cc.ii -dumpbase-ext .ii -mlittle-endian -mabi=lp64 -g -O2 -Wformat=1 -Werror=format-security -Wdate-time -Wno-builtin-macro-redefined -Wall -Wextra -Wconversion -Wsign-conversion -Wvla -Wnon-virtual-dtor -Werror -version -fstack-protector-strong -fPIE -fvisibility=hidden -fvisibility-inlines-hidden -fmerge-all-constants -fmath-errno -fno-exceptions -o /tmp/ccjFMyE5.s GNU C++17 (Debian 20230315-1) version 13.0.1 20230315 (experimental) [master r13-6680-ga9ae16db8cb] (aarch64-linux-gnu) compiled by GNU C version 13.0.1 20230315 (experimental) [master r13-6680-ga9ae16db8cb], GMP version 6.2.1, MPFR version 4.2.0, MPC version 1.3.1, isl version isl-0.25-GMP GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 4bc54a683351612d262139a66d85dce2 In file included from /home/malat/highway-1.0.4~git20230308.a1d7764/hwy/foreach_target.h:114, from /home/malat/highway-1.0.4~git20230308.a1d7764/hwy/tests/convert_test.cc:26: In function 'hwy::AlignedFreeUniquePtr hwy::N_SVE2::F16TestCases(D, size_t&) [with D = Simd]', inlined from 'void hwy::N_SVE2::TestF16::operator()(TF32, DF32) [with TF32 = float; DF32 = hwy::N_SVE2::Simd]' at /home/malat/highway-1.0.4~git20230308.a1d7764/hwy/tests/convert_test.cc:300:10: /home/malat/highway-1.0.4~git20230308.a1d7764/hwy/tests/convert_test.cc:288:11: error: 'void* __builtin_memset(void*, int, long unsigned int)' writing 4 or more bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=] 288 | in[i] = 0.0f; In function 'void hwy::N_SVE2::TestF16::operator()(TF32, DF32) [with TF32 = float; DF32 = hwy::N_SVE2::Simd]': cc1plus: note: destination object is likely at address zero In file included from /home/malat/highway-1.0.4~git20230308.a1d7764/hwy/foreach_target.h:103: In function 'hwy::AlignedFreeUniquePtr hwy::N_SVE::F16TestCases(D, size_t&) [with D = Simd]', inlined from 'void hwy::N_SVE::TestF16::operator()(TF32, DF32) [with TF32 = float; DF32 = hwy::N_SVE::Simd]' at /home/malat/highway-1.0.4~git20230308.a1d7764/hwy/tests/convert_test.cc:300:10: /home/malat/highway-1.0.4~git20230308.a1d7764/hwy/tests/convert_test.cc:288:11: error: 'void* __builtin_memset(void*, int, long unsigned int)' writing 4 or more bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=] 288 | in[i] = 0.0f; In function 'void hwy::N_SVE::TestF16::operator()(TF32, DF32) [with TF32 = float; DF32 = hwy::N_SVE::Simd]': cc1plus: note: destination object is likely at address zero
[Bug c++/109175] error: 'void* __builtin_memset(void*, int, long unsigned int)' writing 4 or more bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109175 --- Comment #2 from Mathieu Malaterre --- Created attachment 54695 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54695=edit Preprocessed source gcc-12 g++ -save-temps=obj -DHWY_SHARED_DEFINE -I"/home/malat/highway-1.0.4~git20230308.a1d7764" -g -O2 -ffile-prefix-map=/home/malat/highway-1.0.4~git20230308.a1d7764=. -fstack-protector-strong -Wformat -Werror=format-security -DHWY_BROKEN_EMU128=0 -Wdate-time -D_FORTIFY_SOURCE=2 -fPIE -fvisibility=hidden -fvisibility-inlines-hidden -Wno-builtin-macro-redefined -D__DATE__=\"redacted\" -D__TIMESTAMP__=\"redacted\" -D__TIME__=\"redacted\" -fmerge-all-constants -Wall -Wextra -Wconversion -Wsign-conversion -Wvla -Wnon-virtual-dtor -fmath-errno -fno-exceptions -Werror -DHWY_IS_TEST=1 -DGTEST_HAS_PTHREAD=1 -MD -MT CMakeFiles/convert_test.dir/hwy/tests/convert_test.cc.o -MF CMakeFiles/convert_test.dir/hwy/tests/convert_test.cc.o.d -o CMakeFiles/convert_test.dir/hwy/tests/convert_test.cc.o -c '/home/malat/highway-1.0.4~git20230308.a1d7764/hwy/tests/convert_test.cc'
[Bug c++/109175] error: 'void* __builtin_memset(void*, int, long unsigned int)' writing 4 or more bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109175 --- Comment #1 from Mathieu Malaterre --- Created attachment 54694 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54694=edit Preprocessed source gcc-13 % /usr/lib/gcc-snapshot/bin/g++ -save-temps=obj -DHWY_SHARED_DEFINE -I"/home/malat/highway-1.0.4~git20230308.a1d7764" -g -O2 -ffile-prefix-map=/home/malat/highway-1.0.4~git20230308.a1d7764=. -fstack-protector-strong -Wformat -Werror=format-security -DHWY_BROKEN_EMU128=0 -Wdate-time -D_FORTIFY_SOURCE=2 -fPIE -fvisibility=hidden -fvisibility-inlines-hidden -Wno-builtin-macro-redefined -D__DATE__=\"redacted\" -D__TIMESTAMP__=\"redacted\" -D__TIME__=\"redacted\" -fmerge-all-constants -Wall -Wextra -Wconversion -Wsign-conversion -Wvla -Wnon-virtual-dtor -fmath-errno -fno-exceptions -Werror -DHWY_IS_TEST=1 -DGTEST_HAS_PTHREAD=1 -MD -MT CMakeFiles/convert_test.dir/hwy/tests/convert_test.cc.o -MF CMakeFiles/convert_test.dir/hwy/tests/convert_test.cc.o.d -o CMakeFiles/convert_test.dir/hwy/tests/convert_test.cc.o -c '/home/malat/highway-1.0.4~git20230308.a1d7764/hwy/tests/convert_test.cc'
[Bug c++/109175] New: error: 'void* __builtin_memset(void*, int, long unsigned int)' writing 4 or more bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109175 Bug ID: 109175 Summary: error: 'void* __builtin_memset(void*, int, long unsigned int)' writing 4 or more bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=] Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: malat at debian dot org Target Milestone: --- A new warning is appearing in the highway compilation logs on aarch64: [...] FAILED: CMakeFiles/convert_test.dir/hwy/tests/convert_test.cc.o /usr/lib/gcc-snapshot/bin/g++ -DHWY_SHARED_DEFINE -I"/<>" -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -DHWY_BROKEN_EMU128=0 -Wdate-time -D_FORTIFY_SOURCE=2 -fPIE -fvisibility=hidden -fvisibility-inlines-hidden -Wno-builtin-macro-redefined -D__DATE__=\"redacted\" -D__TIMESTAMP__=\"redacted\" -D__TIME__=\"redacted\" -fmerge-all-constants -Wall -Wextra -Wconversion -Wsign-conversion -Wvla -Wnon-virtual-dtor -fmath-errno -fno-exceptions -Werror -DHWY_IS_TEST=1 -DGTEST_HAS_PTHREAD=1 -MD -MT CMakeFiles/convert_test.dir/hwy/tests/convert_test.cc.o -MF CMakeFiles/convert_test.dir/hwy/tests/convert_test.cc.o.d -o CMakeFiles/convert_test.dir/hwy/tests/convert_test.cc.o -c '/<>/hwy/tests/convert_test.cc' In file included from /<>/hwy/foreach_target.h:114, from /<>/hwy/tests/convert_test.cc:26: In function 'hwy::AlignedFreeUniquePtr hwy::N_SVE2::F16TestCases(D, size_t&) [with D = Simd]', inlined from 'void hwy::N_SVE2::TestF16::operator()(TF32, DF32) [with TF32 = float; DF32 = hwy::N_SVE2::Simd]' at /<>/hwy/tests/convert_test.cc:300:10: /<>/hwy/tests/convert_test.cc:288:11: error: 'void* __builtin_memset(void*, int, long unsigned int)' writing 4 or more bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=] 288 | in[i] = 0.0f; In function 'void hwy::N_SVE2::TestF16::operator()(TF32, DF32) [with TF32 = float; DF32 = hwy::N_SVE2::Simd]': cc1plus: note: destination object is likely at address zero In file included from /<>/hwy/foreach_target.h:103: In function 'hwy::AlignedFreeUniquePtr hwy::N_SVE::F16TestCases(D, size_t&) [with D = Simd]', inlined from 'void hwy::N_SVE::TestF16::operator()(TF32, DF32) [with TF32 = float; DF32 = hwy::N_SVE::Simd]' at /<>/hwy/tests/convert_test.cc:300:10: /<>/hwy/tests/convert_test.cc:288:11: error: 'void* __builtin_memset(void*, int, long unsigned int)' writing 4 or more bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=] 288 | in[i] = 0.0f; In function 'void hwy::N_SVE::TestF16::operator()(TF32, DF32) [with TF32 = float; DF32 = hwy::N_SVE::Simd]': cc1plus: note: destination object is likely at address zero cc1plus: all warnings being treated as errors [...] ref: * https://buildd.debian.org/status/fetch.php?pkg=highway=arm64=1.0.4%7Egit20230308.a1d7764-1=1679052435=0
[Bug rtl-optimization/109052] Unnecessary reload with -mfpmath=both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109052 --- Comment #6 from Vladimir Makarov --- (In reply to Uroš Bizjak from comment #5) > (In reply to Vladimir Makarov from comment #4) > > > So I think the current patch is probably an adequate solution. > > Perhaps the compiler should also try to swap input operands to fit the > combined insn when commutative operands are allowed. This would solve the > testcase from Comment #2: > Yes. I am agree. The base code can be improved further. Another improvement could be combining secondary memory reload for output. I'd like to watch what the effect of the current patch would be first. Although I tested the patch on many targets as usually for LRA the patch might result in some troubles on some targets. But I hope nothing bad will happen.
[Bug modula2/109032] message 'compiler checks to force' is too complicated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109032 Gaius Mulley changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Gaius Mulley --- Thanks for reporting - now closing as the patch has been applied.
[Bug modula2/109032] message 'compiler checks to force' is too complicated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109032 --- Comment #7 from CVS Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:6bfb5eae96b65894da1301e966568fdf32bf64d0 commit r13-6737-g6bfb5eae96b65894da1301e966568fdf32bf64d0 Author: Gaius Mulley Date: Fri Mar 17 14:32:22 2023 + PR modula2/109032 - message 'compiler checks to force' is too complicated Correct typos and improve the descriptions of command line options. Improve comments in gm2-gcc/m2expr.cc. gcc/m2/ChangeLog: PR modula2/109032 * gm2-gcc/m2expr.cc: Correct ? : order in comments. (m2expr_BuildDivM2): Improve comment. * lang.opt: Improve option descriptions. Signed-off-by: Gaius Mulley
[Bug target/109173] incorrect intrinsic signature for _mm_srai_epi64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109173 --- Comment #5 from Jan Wassenberg --- Thanks, Mathieu, for raising this. Note that clang has changed their intrinsic to require an unsigned arg: https://github.com/google/highway/commit/45b1fac0b1c404e6573c2f182b36c245af6503e0 I understand that some implementations may be using a macro, and that's fine, but certain GCC and clang have non-macro intrinsics that are mutually incompatible, and users including us are forced to use #if to compile without warnings. My understanding is that icc is being replaced with clang. Wouldn't it be better then to follow the Intel intrinsics documentation?
[Bug testsuite/105959] new test case c-c++-common/diagnostic-format-sarif-file-4.c from r13-967-g6cf276ddf22066 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105959 --- Comment #11 from David Malcolm --- (In reply to Hans-Peter Nilsson from comment #10) > (I see an identifier using ideographs? > Wouldn't want to review that code... Might as well use Linear A -which you > indeed can in UTF-8- - it's all greek to me!) FWIW the identifier "文字化け" is the word "mojibake", which is the Japanese word for snafu with character encodings: https://en.wikipedia.org/wiki/Mojibake
[Bug c++/109160] [Valid code] Constraint on deduced NTTP from method call causes ICE/Segfault.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109160 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2023-03-17 Blocks||67491 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org --- Comment #1 from Patrick Palka --- Confirmed, this never worked properly. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 [Bug 67491] [meta-bug] concepts issues
[Bug rtl-optimization/109052] Unnecessary reload with -mfpmath=both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109052
--- Comment #5 from Uroš Bizjak ---
(In reply to Vladimir Makarov from comment #4)
> So I think the current patch is probably an adequate solution.
Perhaps the compiler should also try to swap input operands to fit the combined
insn when commutative operands are allowed. This would solve the testcase from
Comment #2:
double foo (double a, double b)
{
double z = __builtin_fmod (a, 3.14);
return z * b;
}
gcc -O2 -mfpmath=both -mavx:
Failed combined insn:
24: r90:DF=r96:DF*r85:DF
REG_DEAD r85:DF
REG_DEAD r82:DF
Restoring insn after failed combining:
(^^^ shouldn't there be a memory operand mentioned in the above RTX dump?)
...
(insn 42 41 24 6 (set (reg/v:DF 23 xmm3 [orig:82 z ] [82])
(mem/c:DF (plus:DI (reg/f:DI 7 sp)
(const_int 8 [0x8])) [1 %sfp+-24 S8 A64])) "fmod.c":4:12 145
{*movdf_internal}
(nil))
(insn 24 42 30 6 (set (reg:DF 20 xmm0 [90])
(mult:DF (reg/v:DF 23 xmm3 [orig:82 z ] [82])
(reg/v:DF 22 xmm2 [orig:85 b ] [85]))) "fmod.c":4:12 1189
{*fop_df_comm}
(nil))
...
As can be seen in the above dump, swapped input operands would fit alternative
(v,v,vm) in the insn pattern:
[(set (match_operand:MODEF 0 "register_operand" "=f,x,v")
(match_operator:MODEF 3 "binary_fp_operator"
[(match_operand:MODEF 1 "nonimmediate_operand" "%0,0,v")
(match_operand:MODEF 2 "nonimmediate_operand" "fm,xm,vm")]))]
[Bug c++/69410] [10/11/12/13 Regression] friend declarations in local classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69410 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug rtl-optimization/109052] Unnecessary reload with -mfpmath=both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109052 --- Comment #4 from Vladimir Makarov --- The complete solution would be running combine pass also after LRA. I am not sure how frequently the 2nd pass will improve the code. Also probably it might create some troubles the fix of which will require another LRA pass. The most generalized solution would be an approach of combined optimizations (integrated insn scheduling, RA, and code selection) but in practice it makes the integrated optimization too complicated. Less complicated solution could be implementation of combining secondary memory reload insns in postreload pass but implementing this in LRA is better because we increase possibility to assign hard regs to other pseudos as we don't need to allocate hard register to a pseudo which goes away. So I think the current patch is probably an adequate solution.
[Bug rtl-optimization/109052] Unnecessary reload with -mfpmath=both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109052 --- Comment #3 from CVS Commits --- The master branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:57688950b9328cbb4a9c21eb3199f9132b5119d3 commit r13-6736-g57688950b9328cbb4a9c21eb3199f9132b5119d3 Author: Vladimir N. Makarov Date: Fri Mar 17 08:58:58 2023 -0400 LRA: Implement combining secondary memory reload and original insn LRA creates secondary memory reload insns but do not try to combine it with the original insn. This patch implements a simple insn combining for such cases in LRA. PR rtl-optimization/109052 gcc/ChangeLog: * lra-constraints.cc: Include hooks.h. (combine_reload_insn): New function. (lra_constraints): Call it. gcc/testsuite/ChangeLog: * gcc.target/i386/pr109052.c: New.
[Bug modula2/109102] Wrong quotes in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109102 Gaius Mulley changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Gaius Mulley --- Closing as the patch has been applied.
[Bug modula2/109102] Wrong quotes in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109102 Gaius Mulley changed: What|Removed |Added Last reconfirmed||2023-03-17 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #2 from Gaius Mulley --- Many thanks for reporting the bug.
[Bug modula2/109102] Wrong quotes in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109102 --- Comment #1 from CVS Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:daf20b4b83615d61bf1793e8edcd64681275e598 commit r13-6735-gdaf20b4b83615d61bf1793e8edcd64681275e598 Author: Gaius Mulley Date: Fri Mar 17 12:47:06 2023 + PR modula2/109102 Wrong quotes in diagnostic The backtick and single quote should be replaced with %< and %> or %qs. gcc/m2/ChangeLog: PR modula2/109102 * gm2-gcc/m2builtins.cc (ASSERT): Change format specifier to use %qs rather than quotes. Signed-off-by: Gaius Mulley
