[Bug tree-optimization/116460] [14/15 Regression] LTO ICE with -g during GIMPLE pass: forwprop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116460 --- Comment #23 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:172637cf0d9b7b2798f83b9c5f9598b449675cb0 commit r15-3210-g172637cf0d9b7b2798f83b9c5f9598b449675cb0 Author: Richard Biener Date: Mon Aug 26 13:50:00 2024 +0200 tree-optimization/116460 - ICE with DCE in forwprop The following avoids removing stmts with defs that might still have uses in the IL before calling simple_dce_from_worklist which might remove those as that will wreck debug stmt generation. Instead first perform use-based DCE and then remove stmts which may have uses in code that CFG cleanup will remove. This requires tracking stmts in to_remove by their SSA def so we can check whether it was removed before without running into the issue that PHIs can be ggc_free()d upon removal. So this adds to_remove_defs in addition to to_remove which has to stay to track GIMPLE_NOPs we want to elide. PR tree-optimization/116460 * tree-ssa-forwprop.cc (pass_forwprop::execute): First do simple_dce_from_worklist and then remove stmts in to_remove. Track defs to be removed in to_remove_defs. * g++.dg/torture/pr116460.C: New testcase.
[Bug tree-optimization/116460] [14 Regression] LTO ICE with -g during GIMPLE pass: forwprop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116460 Richard Biener changed: What|Removed |Added Known to work||15.0 Summary|[14/15 Regression] LTO ICE |[14 Regression] LTO ICE |with -g during GIMPLE pass: |with -g during GIMPLE pass: |forwprop|forwprop Keywords|needs-reduction | --- Comment #24 from Richard Biener --- Fixed on trunk sofar.
[Bug c++/116490] ICE in build_contract_condition_function, at cp/contracts.cc:1463 for explicitly instantiated Function Contracts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116490 Richard Biener changed: What|Removed |Added Known to fail||14.2.1, 15.0 Keywords||ice-on-valid-code Summary|Crash in explicitly |ICE in |instantiated Function |build_contract_condition_fu |Contracts |nction, at ||cp/contracts.cc:1463 for ||explicitly instantiated ||Function Contracts --- Comment #1 from Richard Biener --- Confirmed, not sure if valid or invalid testcase.
[Bug ada/116498] gnat enters busy wait trying to compile for msp430-none-elf with -mlarge flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116498 Richard Biener changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #2 from Richard Biener --- Confirmed on trunk, while (!targetm.valid_pointer_mode (p_mode)) p_mode = GET_MODE_WIDER_MODE (p_mode).require (); is broken, but I think the code expects it will find a valid_pointer_mode and this expectation is wrong in this case. It seems odd that neither Pmode nor ptr_mode is in the set of integer modes though. Eventually because /* 20-bit address */ PARTIAL_INT_MODE (SI, 20, PSI); INT_N (PSI, 20); it seems PSImode is not found via the above iteration.
[Bug c++/116482] Bogus -Wunused-parameter with C++ coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116482 --- Comment #2 from GCC Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:8d6d6c864442a1cc987b3e6bcb1d903ceb975e4a commit r15-3211-g8d6d6c864442a1cc987b3e6bcb1d903ceb975e4a Author: Iain Sandoe Date: Mon Aug 26 14:09:40 2024 +0100 c++, coroutines: The frame pointer is used in the helpers [PR116482]. We have a bogus warning about the coroutine state frame pointers being apparently unused in the resume and destroy functions. Fixed by making the parameters DECL_ARTIFICIAL. PR c++/116482 gcc/cp/ChangeLog: * coroutines.cc (coro_build_actor_or_destroy_function): Make the parameter decls DECL_ARTIFICIAL. gcc/testsuite/ChangeLog: * g++.dg/coroutines/pr116482.C: New test. Signed-off-by: Iain Sandoe
[Bug target/116493] widening reduction add could be better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116493
--- Comment #2 from Richard Biener ---
Note WIDEN_SUM_EXPR is listed as lane-reducing when applied to
vectors (tree.def isn't clear and of course generic.texi doesn't document it).
So I don't think the proposed simplification works. It would work
for { 0, 0, 0, 0 } w+ vect__4.6_1, simplifying to vect__4.6_1 though
(the op isn't commutative either).
[Bug c++/116482] Bogus -Wunused-parameter with C++ coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116482 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Iain Sandoe --- fixed
[Bug c++/115908] [coroutines] Wrong behavior of using get_return_object() when creating coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115908 Iain Sandoe changed: What|Removed |Added Status|NEW |WAITING --- Comment #6 from Iain Sandoe --- fixed on trunk, waiting for possible back-port
[Bug c++/113773] coroutines: promise deconstructed twice if throwing from return object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113773 Iain Sandoe changed: What|Removed |Added Status|NEW |WAITING --- Comment #4 from Iain Sandoe --- fixed on trunk, waiting for possible back-port
[Bug c++/110872] coroutine postcondition is not evaluated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110872 Iain Sandoe changed: What|Removed |Added Status|NEW |WAITING
[Bug c++/110871] coroutine precondition should be evaluated before the initial suspend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110871 Iain Sandoe changed: What|Removed |Added Status|NEW |WAITING
[Bug c++/110635] Segmentation fault when the awaiter's await_resume in initial-suspend returns a class type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110635 Iain Sandoe changed: What|Removed |Added Status|NEW |WAITING CC||iains at gcc dot gnu.org --- Comment #3 from Iain Sandoe --- fixed on trunk, waiting for possible back-port
[Bug c++/109682] coroutines: ICE in morph_fn_to_coro on wrong return type for get_return_object_on_allocation_failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109682 Iain Sandoe changed: What|Removed |Added Status|NEW |WAITING Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org --- Comment #5 from Iain Sandoe --- fixed on trunk, waiting for possible back-port
[Bug c++/100476] coroutines: questionable handling of void get_return_object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100476 Iain Sandoe changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #10 from Iain Sandoe --- fixed on trunk, waiting for possible back-port
[Bug c++/102051] [coroutines] ICE in gimplify_var_or_parm_decl, at gimplify.c:2848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102051 Iain Sandoe changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Status|NEW |WAITING --- Comment #9 from Iain Sandoe --- fixed on trunk, waiting for possible back-port
[Bug target/116497] Need no_caller_saved_registers with SSE support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment #6 from Hongtao Liu ---
(In reply to Andi Kleen from comment #1)
> Disable check for no_caller_saved_registers enforcing non FP.
>
> diff --git a/gcc/config/i386/i386-options.cc
> b/gcc/config/i386/i386-options.cc
> index f79257cc764..cec652cc9e6 100644
> --- a/gcc/config/i386/i386-options.cc
> +++ b/gcc/config/i386/i386-options.cc
> @@ -3639,8 +3639,8 @@ ix86_set_current_function (tree fndecl)
> reinit_regs ();
>
>if (cfun->machine->func_type != TYPE_NORMAL
> - || (cfun->machine->call_saved_registers
> - == TYPE_NO_CALLER_SAVED_REGISTERS))
> + /* || (cfun->machine->call_saved_registers
> +== TYPE_NO_CALLER_SAVED_REGISTERS) */)
> {
>/* Don't allow SSE, MMX nor x87 instructions since they
> may change processor state. */
I think RA is smart enough to save and restore SSE,MMX or x87 registers, and we
can remove TYPE_NO_CALLER_SAVED_REGISTERS part from this.
Or are there any other concerns here regarding the comments? @hj
[Bug target/116497] Need no_caller_saved_registers with SSE support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497 --- Comment #7 from Richard Biener --- Hmm, why would a tail call need to save extra regs over what the callers caller already saved? We're returning to that after all.
[Bug target/116497] Need no_caller_saved_registers with SSE support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497
--- Comment #8 from andi at firstfloor dot org ---
On Tue, Aug 27, 2024 at 07:58:30AM +, liuhongt at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497
>
> Hongtao Liu changed:
>
>What|Removed |Added
>
> CC||liuhongt at gcc dot gnu.org
>
> --- Comment #6 from Hongtao Liu ---
> (In reply to Andi Kleen from comment #1)
> > Disable check for no_caller_saved_registers enforcing non FP.
> >
> > diff --git a/gcc/config/i386/i386-options.cc
> > b/gcc/config/i386/i386-options.cc
> > index f79257cc764..cec652cc9e6 100644
> > --- a/gcc/config/i386/i386-options.cc
> > +++ b/gcc/config/i386/i386-options.cc
> > @@ -3639,8 +3639,8 @@ ix86_set_current_function (tree fndecl)
> > reinit_regs ();
> >
> >if (cfun->machine->func_type != TYPE_NORMAL
> > - || (cfun->machine->call_saved_registers
> > - == TYPE_NO_CALLER_SAVED_REGISTERS))
> > + /* || (cfun->machine->call_saved_registers
> > +== TYPE_NO_CALLER_SAVED_REGISTERS) */)
> > {
> >/* Don't allow SSE, MMX nor x87 instructions since they
> > may change processor state. */
>
> I think RA is smart enough to save and restore SSE,MMX or x87 registers, and
> we
> can remove TYPE_NO_CALLER_SAVED_REGISTERS part from this.
> Or are there any other concerns here regarding the comments? @hj
While that would work, it would add unnecessary overhead
to the interpreter entry case which doesn't need to save these registers.
On the other hand maybe it is cheap enough.
[Bug target/116497] Need no_caller_saved_registers with SSE support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497 --- Comment #9 from andi at firstfloor dot org --- On Tue, Aug 27, 2024 at 08:02:53AM +, rguenth at gcc dot gnu.org wrote: > Hmm, why would a tail call need to save extra regs over what the callers > caller > already saved? We're returning to that after all. The tail call doesn't need to save anything extra, but the original function entering the tail call loop needs to, otherwise the tail calls clobbering stuff would violate assumptions of its caller. So the transformation is original_caller -> add no_caller_saved_registers tailcall loop functions -> add no_callee_saved_registers
[Bug gcov-profile/115047] Inconsistent MC/DC reported by GCC and LLVM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115047
--- Comment #4 from Jørgen Kvalsvik ---
> I guess it would be desirable to (1) let LLVM support masking MC/DC and (2)
> let
gcov support unique-cause MC/DC. The first seems easier and I might try
implementing a prototype.
There is room for both, e.g. -fcondition-coverage={masking,unique} or similar.
I don't think supporting unique cause MC/DC would be too hard in GCC either,
using a method similar to GCC's upcoming path coverage and LLVM's MC/DC, if it
is desirable.
[Bug target/116497] Need no_caller_saved_registers with SSE support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #10 from Xi Ruoyao ---
no_call{er,ee}_saved_registers are i386-specific so how do we handle other
ports? Are we going to require implementing them for all ports?
[Bug rtl-optimization/116321] [lra][avr] internal compiler error: in avr_out_lpm_no_lpmx, at config/avr/avr.cc:4572
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116321 --- Comment #6 from GCC Commits --- The trunk branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:9db997e5ac4a206b9428eb2447fcdc90e37725f4 commit r15-3212-g9db997e5ac4a206b9428eb2447fcdc90e37725f4 Author: Richard Sandiford Date: Tue Aug 27 09:48:28 2024 +0100 lra: Don't apply eliminations to allocated registers [PR116321] The sequence of events in this PR is that: - the function has many addresses in which only a single hard base register is acceptable. Let's call the hard register H. - IRA allocates that register to one of the pseudo base registers. Let's call the pseudo register P. - Some of the other addresses that require H occur when P is still live. - LRA therefore has to spill P. - When it reallocates P, LRA chooses to use FRAME_POINTER_REGNUM, which has been eliminated to the stack pointer. (This is ok, since the frame register is free.) - Spilling P causes LRA to reprocess the instruction that uses P. - When reprocessing the address that has P as its base, LRA first applies the new allocation, to get FRAME_POINTER_REGNUM, and then applies the elimination, to get the stack pointer. The last step seems wrong: the elimination should only apply to pre-existing uses of FRAME_POINTER_REGNUM, not to uses that result from allocating pseudos. Applying both means that we get the wrong register number, and therefore the wrong class. The PR is about an existing testcase that fails with LRA on m86k. gcc/ PR middle-end/116321 * lra-constraints.cc (get_hard_regno): Only apply eliminations to existing hard registers. (get_reg_class): Likewise.
[Bug target/116413] [LRA] [M68K] ICE: unrecognized insn in lra_set_insn_recog_data, at lra.cc:1036
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116413
--- Comment #19 from GCC Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:708ee71808ea61758e73d0e36274b4194b28576a
commit r15-3213-g708ee71808ea61758e73d0e36274b4194b28576a
Author: Richard Sandiford
Date: Tue Aug 27 09:48:28 2024 +0100
Handle arithmetic on eliminated address indices [PR116413]
This patch fixes gcc.c-torture/compile/opout.c for m68k with LRA
enabled. The test has:
...
z (a, b)
{
return (int) &a + (int) &b + (int) x + (int) z;
}
so it adds the address of two incoming arguments. This ends up
being treated as an LEA in which the "index" is the incoming
argument pointer, which the LEA multiplies by 2. The incoming
argument pointer is then eliminated, leading to:
(plus:SI (plus:SI (ashift:SI (plus:SI (reg/f:SI 24 %argptr)
(const_int -4 [0xfffc]))
(const_int 1 [0x1]))
(reg/f:SI 41 [ _6 ]))
(const_int 20 [0x14]))
In the address_info scheme, the innermost plus has to be treated
as the index "term", since that's the thing that's subject to
index_reg_class.
gcc/
PR middle-end/116413
* rtl.h (address_info): Update commentary.
* rtlanal.cc (valid_base_or_index_term_p): New function, split
out from...
(get_base_term, get_index_term): ...here. Handle elimination
PLUSes.
[Bug target/116103] [15 Regression] GCN vs. "Internal-fn: Only allow modes describe types for internal fn[PR115961]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116103 Thomas Schwinge changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #12 from Thomas Schwinge --- Fixed, thanks!
[Bug testsuite/116000] [15 Regression] gcc.dg/vect/vect-reduc-chain-dot-slp-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116000 Thomas Schwinge changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Assignee|unassigned at gcc dot gnu.org |fxue at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from Thomas Schwinge --- As far as I can tell per my own testing as well as posts, this is now resolved, thanks!
[Bug target/116021] Ada build on Darwin: gen_il-main: Symbol not found: ___builtin_nested_func_ptr_created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116021 --- Comment #11 from Eric Gallager --- Update: I finally managed to bootstrap using one of Simon Wright's releases: https://github.com/simonjwright/distributing-gcc/releases I still think there might be a bug in the build system somewhere leading to the wrong tools getting used, but since I've managed to build now, I'm not going to bother looking too much harder...
[Bug c++/115908] [coroutines] Wrong behavior of using get_return_object() when creating coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115908 --- Comment #7 from Artyom Kolpakov --- (In reply to Iain Sandoe from comment #6) > fixed on trunk, waiting for possible back-port I'm not sure if I should write this here, but now a warning has appeared in the original example: unused parameter 'frame_ptr'
[Bug c++/115908] [coroutines] Wrong behavior of using get_return_object() when creating coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115908 --- Comment #8 from Iain Sandoe --- (In reply to Artyom Kolpakov from comment #7) > (In reply to Iain Sandoe from comment #6) > > fixed on trunk, waiting for possible back-port > > I'm not sure if I should write this here, but now a warning has appeared in > the original example: unused parameter 'frame_ptr' that should be fixed after r15-3211-g8d6d6c864442.
[Bug c++/85973] [[nodiscard]] on class shall emit a warning for unused anonymous variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85973
--- Comment #6 from Leonid Satanovsky ---
As you are marking other bugs as duplicates of the current bug, please don't
forget to transfer the useful test cases not mentioned in current bug (e.g.
GccFailedNoDiscard2 case seen below):
struct [[nodiscard]] GccFailedNoDiscard1 {};
struct GccFailedNoDiscard2 { [[nodiscard]] GccFailedNoDiscard2() = default;};
template struct [[nodiscard]] GccFailedNoDiscard3 {};
struct GccOKNoDiscard1 { [[nodiscard]] GccOKNoDiscard1() {}};
template struct GccOKNoDiscard2 {
[[nodiscard]] GccOKNoDiscard2() {}};
int main() {
GccFailedNoDiscard1 {};
GccFailedNoDiscard2 {};
GccFailedNoDiscard3 {};
GccOKNoDiscard1 {};
GccOKNoDiscard2 {};
}
[Bug c++/116499] New: [modules] Replace CMI term with BMI in documentation, commit messages, etc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116499 Bug ID: 116499 Summary: [modules] Replace CMI term with BMI in documentation, commit messages, etc Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: boris at kolpackov dot net Target Milestone: --- During the early days of the C++ modules development two different terms were used to refer to the compiled module interface file: BMI (binary/built module interface) and CMI (compiled module interface). Lately, however, the BMI term appears to have won: WG21/SG15 settled on in in its discussions/terminology and Clang now uses it in its documentation: https://clang.llvm.org/docs/StandardCPlusPlusModules.html Perhaps it's time for GCC to switch as well to avoid confusion?
[Bug c++/116441] [[nodiscard]] attribute ignored in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116441 --- Comment #7 from Leonid Satanovsky --- (In reply to Andrew Pinski from comment #6) > This is a dup of bug 85973. > > I even make mention of moving the attribute to the constructor makes the > warning/error happen: > > Note if we move the attribute to the constructor, then GCC will error out. > > *** This bug has been marked as a duplicate of bug 85973 *** Andrew, I don't personally care via which bug this issue shall be fixed, however, the test cases present here and omitted in 85973 should be taken into account (e.g. the case with the attribute added to the default-ed constructor) Thanks.
[Bug c++/116490] ICE in build_contract_condition_function, at cp/contracts.cc:1463 for explicitly instantiated Function Contracts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116490 Nina Ranns changed: What|Removed |Added CC||dinka.ranns at gmail dot com --- Comment #2 from Nina Ranns --- The test case is valid - The explicit instantiation should have the same contracts even if they are not present on the explicit instantiation. The crash happens because we do not expect comdat group to be set when we build the pre and post check functions. However, in the case of explicit instantiation we do have it set before we generate the check functions. Picking this up.
[Bug tree-optimization/116500] New: gcc.dg/vect/vect-switch-ifcvt-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116500 Bug ID: 116500 Summary: gcc.dg/vect/vect-switch-ifcvt-1.c FAILs Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: andi-gcc at firstfloor dot org Target Milestone: --- Target: sparc*-sun-solaris2.11 The new gcc.dg/vect/vect-switch-ifcvt-1.c test FAILs on Solaris/SPARC (32 and 64-bit): +FAIL: gcc.dg/vect/vect-switch-ifcvt-1.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 4 +FAIL: gcc.dg/vect/vect-switch-ifcvt-1.c scan-tree-dump-times vect "vectorized 1 loops" 4 I'm attaching the dump.
[Bug tree-optimization/116500] gcc.dg/vect/vect-switch-ifcvt-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116500 --- Comment #1 from Rainer Orth --- Created attachment 59010 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59010&action=edit 32-bit sparc-sun-solaris2.11 vect-switch-ifcvt-1.c.180t.vect
[Bug tree-optimization/116500] gcc.dg/vect/vect-switch-ifcvt-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116500 Rainer Orth changed: What|Removed |Added Target Milestone|--- |15.0
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #203 from Kazumoto Kojima --- (In reply to John Paul Adrian Glaubitz from comment #201) > Created attachment 59006 [details] > Diff for bootstrap comparison failure of gcc/gimple-lower-bitint.c I tried to build the stage3 gcc on qemu with the stage2 gcc which was built with the cross comiler. Interestingly, stage2 gcc/gimple-lower-bitint.o and stage3 gcc/gimple-lower-bitint.o were exactly the same. Perhaps the problem cannot be reproduced because my qemu environment is not the real sh4-linux and my build process of the stage3 compiler was not the same with the true bootstrapping. FYI, your stage2 gcc/gimple-lower-bitint.o already seems to be slightly different from my stage2 gcc/gimple-lower-bitint.o. It may be due to the difference in codebase. I'm using gcc master commit 7f65c38ac1b18773d55c08d6ba920a798462b871 (origin/master, master).
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #204 from John Paul Adrian Glaubitz --- (In reply to Kazumoto Kojima from comment #203) > (In reply to John Paul Adrian Glaubitz from comment #201) > > Created attachment 59006 [details] > > Diff for bootstrap comparison failure of gcc/gimple-lower-bitint.c > > I tried to build the stage3 gcc on qemu with the stage2 gcc which was built > with the cross comiler. Interestingly, stage2 gcc/gimple-lower-bitint.o > and stage3 gcc/gimple-lower-bitint.o were exactly the same. Perhaps the > problem cannot be reproduced because my qemu environment is not the real > sh4-linux and my build process of the stage3 compiler was not the same with > the true bootstrapping. It actually seems that the bootstrap comparison failure that I have run into was a result of disabling late combine. I am retesting this now just to make sure. > FYI, your stage2 gcc/gimple-lower-bitint.o already seems to be slightly > different from my stage2 gcc/gimple-lower-bitint.o. It may be due to the > difference in codebase. I'm using gcc master commit > 7f65c38ac1b18773d55c08d6ba920a798462b871 (origin/master, master). Yeah, I'm pretty sure that's because I disabled late combine as one of the measures trying to mitigate the segfault. I am testing now with the following patches applied: - 58832 - 58833 - 58883 - 58905 - 59000 as well as LRA enabled by default and late combine enabled as well. Will report back as soon as the build finishes.
[Bug libstdc++/103934] std::atomic_flag: multiple C++20 functions missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103934 --- Comment #9 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:470a27859d8a47a99f389f1dc6edb82c08b16e21 commit r15-3217-g470a27859d8a47a99f389f1dc6edb82c08b16e21 Author: Jonathan Wakely Date: Tue Aug 27 12:19:47 2024 +0100 c++: Add most missing C++20 and C++23 names to cxxapi-data.csv This includes uncommenting the atomic_flag non-member functions, which were added by PR libstdc++/103934. Also generate a hint for std::ignore, which was recently tweaked to be more generally useful by P2968R2, which r15-2324 implemented. gcc/cp/ChangeLog: * cxxapi-data.csv: Add C++20 and C++23 names from , , , , , and . Set cxx11 dialect for std::ignore in . Uncomment atomic_flag functions from . * std-name-hint.gperf: Regenerate. * std-name-hint.h: Regenerate.
[Bug driver/110522] `-fdiagnostics-format=sarif-file`: file name conflicts / races
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110522 David Malcolm changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=115970 Ever confirmed|0 |1 Last reconfirmed||2024-08-27 Status|UNCONFIRMED |NEW --- Comment #3 from David Malcolm --- Thanks for filing this bug; you make some very useful points. I had thought that the .sarif filename was respecting the dumpfile options (e.g. -dumpdir, see https://gcc.gnu.org/onlinedocs/gcc/Overall-Options.html#index-dumpdir ) but it turns out that it doesn't even handle that. Bother. I like the idea of using the output file name/path as the basis on which to build the .sarif filename (e.g. outputdir/foo.o.sarif), but there may be projects that are using the existing behavior, so we'd probably need some way to ease transition. Some other possibly-awkward cases: what about e.g. -S, or gcc invocations that take multiple source files, and/or those that imply a.out as the output? It may make sense to support both text *and* sarif output of diagnostics, to avoid the "nothing on stderr" problem. See also bug 115970 for another approach to capturing sarif from a build.
[Bug driver/111527] COLLECT_GCC_OPTIONS option hits single-variable limits too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111527
--- Comment #17 from Sam James ---
See https://gcc.gnu.org/contribute.html#patches ("Pinging patches, Getting
patches applied"). You can ping patches on the ML by just saying "ping" or
similar in response to the original message, after 2 weeks or so.
Sometimes it can be helpful if it's a niche component to CC the relevant
maintainers of $COMPONENT, after looking at MAINTAINERS, but do so with care.
[Bug driver/110522] `-fdiagnostics-format=sarif-file`: file name conflicts / races
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110522 --- Comment #4 from David Malcolm --- I wonder if extending -fdiagnostics-format to support extra args would be a way out of this e.g. -fdiagnostics-format=sarif-file=path/to/foo.sarif But it would also be nice to support multiple output streams e.g. -fdiagnostics-format=text,sarif-file=path/to/foo.sarif Or a new param: -fdiagnostics-sarif-output-file=PATH/TO/foo.sarif or somesuch.
[Bug libstdc++/116494] std::string::replace uses memcpy incorrectly and warns about it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116494
--- Comment #1 from Jonathan Wakely ---
(In reply to Архипов Дмитрий from comment #0)
> When compiled with -std=c++20 -O3 -Wall -Werror this code:
>
> #include
>
> bool foo(std::string s1)
> {
> s1.replace(1, 1, s1.data(), s1.size());
> return s1.size();
> }
>
> fails with a warning about incorrect use of __builtin_memcpy. As far as I
> can see, inside _M_replace the call to _M_disjunct paradoxically determines
> that s1.data() is not contained in s1's buffer. Because of that _M_replace
> then uses the wrong branch and uses memcpy, when it shouldn't have.
No, it doesn't. It's just a warning during compilation. The branch is not taken
under those conditions.
[Bug libstdc++/115098] std::vector::iterator::reference is default-constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115098 --- Comment #8 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:75ef21665cb924265b818b08babbc7ec3108c876 commit r15-3218-g75ef21665cb924265b818b08babbc7ec3108c876 Author: Jonathan Wakely Date: Tue Aug 27 13:30:42 2024 +0100 libstdc++: Do not use std::vector::reference default ctor [PR115098] This default constructor was made private by r15-3124-gb25b101bc38000 so the pretty printer tests need a fix to stop using it. There's no conforming way to get a default-constructed 'reference' now, e.g. trying to access an element of a default-constructed std::vector will trigger an assertion. Remove the tests, but leave a comment in the printer code about handling it. libstdc++-v3/ChangeLog: PR libstdc++/115098 * python/libstdcxx/v6/printers.py (StdBitReferencePrinter): Add comment. * testsuite/libstdc++-prettyprinters/simple.cc: Do not default construct std::vector::reference. * testsuite/libstdc++-prettyprinters/simple11.cc: Likewise.
[Bug target/116497] Need no_caller_saved_registers with SSE support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497 H.J. Lu changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2024-08-27 --- Comment #11 from H.J. Lu --- Please provide a small testcase to show the issue.
[Bug libstdc++/116494] std::string::replace uses memcpy incorrectly and warns about it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116494 --- Comment #2 from Архипов Дмитрий --- Ah, so it warns that if that branch would have been taken, it would cause a problem, but it doesn't actually take the branch. So it's just a false positive warning?
[Bug target/116413] [LRA] [M68K] ICE: unrecognized insn in lra_set_insn_recog_data, at lra.cc:1036
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116413 --- Comment #20 from GCC Commits --- The master branch has been updated by Michael Matz : https://gcc.gnu.org/g:359209bdc7245f8768b5044acded8509545e4990 commit r15-3219-g359209bdc7245f8768b5044acded8509545e4990 Author: Michael Matz Date: Thu Aug 22 17:03:56 2024 +0200 final: go down ASHIFT in walk_alter_subreg when experimenting with m68k plus LRA one of the changes in the backend is to accept ASHIFTs (not only MULT) as scale code for address indices. When then not turning on LRA but using reload those addresses are presented to it which chokes on them. While reload is going away the change to make them work doesn't really hurt (and generally seems useful, as MULT and ASHIFT really are no different). So just add it. PR target/116413 * final.cc (walk_alter_subreg): Recurse on AHIFT.
[Bug target/116429] [LRA] [M86k] Wrong spill offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116429
--- Comment #2 from GCC Commits ---
The master branch has been updated by Michael Matz :
https://gcc.gnu.org/g:e223ac9c225352e3aeea7180a3b56a96ecdbe2fd
commit r15-3221-ge223ac9c225352e3aeea7180a3b56a96ecdbe2fd
Author: Michael Matz
Date: Thu Aug 22 17:21:42 2024 +0200
LRA: Fix setup_sp_offset
This is part of making m68k work with LRA. See PR116429.
In short: setup_sp_offset is internally inconsistent. It wants to
setup the sp_offset for newly generated instructions. sp_offset for
an instruction is always the state of the sp-offset right before that
instruction. For that it starts at the (assumed correct) sp_offset
of the instruction right after the given (new) sequence, and then
iterates that sequence forward simulating its effects on sp_offset.
That can't ever be right: either it needs to start at the front
and simulate forward, or start at the end and simulate backward.
The former seems to be the more natural way. Funnily the local
variable holding that instruction is also called 'before'.
This changes it to the first variant: start before the sequence,
do one simulation step to get the sp-offset state in front of the
sequence and then continue simulating.
More details: in the problematic testcase we start with this
situation (sp_off before 550 is 0):
550: [--sp] = 0 sp_off = 0 {pushexthisi_const}
551: [--sp] = 37sp_off = -4 {pushexthisi_const}
552: [--sp] = r37 sp_off = -8 {movsi_m68k2}
554: [--sp] = r116 - r37sp_off = -12 {subsi3}
556: call sp_off = -16
insn 554 doesn't match its constraints and needs some reloads:
Creating newreg=262, assigning class DATA_REGS to r262
554: r262:SI=r262:SI-r37:SI
REG_ARGS_SIZE 0x10
Inserting insn reload before:
996: r262:SI=r116:SI
Inserting insn reload after:
997: [--%sp:SI]=r262:SI
Considering alt=0 of insn 997: (0) =g (1) damSKT
1 Non pseudo reload: reject++
overall=1,losers=0,rld_nregs=0
Choosing alt 0 in insn 997: (0) =g (1) damSKT {*movsi_m68k2}
(sp_off=-16)
Note how insn 997 (the after-reload) now has sp_off=-16 already. It all
goes downhill from there. We end up with these insns:
552: [--sp] = r37 sp_off = -8 {movsi_m68k2}
996: r262 = r116sp_off = -12
554: r262 = r262 - r37 sp_off = -12
997: [--sp] = r262 sp_off = -16 (!!! should be -12)
556: call sp_off = -16
The call insn sp_off remains at the correct -16, but internally it's
already
inconsistent here. If the sp_off before an insn is -16, and that insn
pre_decs sp, then the after-insn sp_off should be -20.
PR target/116429
* lra.cc (setup_sp_offset): Start with sp_offset from
before the new sequence, not from after.
[Bug target/116374] [LRA] [M68K] Wrong %argptr elimination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116374 --- Comment #7 from GCC Commits --- The master branch has been updated by Michael Matz : https://gcc.gnu.org/g:542773888190ef67dca194f4861abab104fa9b5b commit r15-3220-g542773888190ef67dca194f4861abab104fa9b5b Author: Michael Matz Date: Thu Aug 22 17:09:11 2024 +0200 LRA: Don't use 0 as initialization for sp_offset this is part of making m68k work with LRA. See PR116374. m68k has the property that sometimes the elimation offset between %sp and %argptr is zero. During setting up elimination infrastructure it's changes between sp_offset and previous_offset that feed into insns_with_changed_offsets that ultimately will setup looking at the instructions so marked. But the initial values for sp_offset and previous_offset are also zero. So if the targets INITIAL_ELIMINATION_OFFSET (called in update_reg_eliminate) is zero then nothing changes, the instructions in question don't get into the list to consider and the sp_offset tracking goes wrong. Solve this by initializing those member with -1 instead of zero. An initial offset of that value seems very unlikely, as it's in word-sized increments. This then also reveals a problem in eliminate_regs_in_insn where it always uses sp_offset-previous_offset as offset adjustment, even in the first_p pass. That was harmless when previous_offset was uninitialized as zero. But all the other code uses a different idiom of checking for first_p (or rather update_p which is !replace_p&&!first_p), and using sp_offset directly. So use that as well in eliminate_regs_in_insn. PR target/116374 * lra-eliminations.cc (init_elim_table): Use -1 as initializer. (update_reg_eliminate): Accept -1 as not-yet-used marker. (eliminate_regs_in_insn): Use previous_sp_offset only when not first_p.
[Bug libstdc++/116494] std::string::replace uses memcpy incorrectly and warns about it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116494 --- Comment #3 from Jonathan Wakely --- Yes. It's a false positive warning about unreachable dead code. We have dozens of these warnings for -Wrestrict, -Wstringop-overflow, and related warnings.
[Bug target/116374] [LRA] [M68K] Wrong %argptr elimination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116374 Andreas Schwab changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #8 from Andreas Schwab --- Fixed for gcc 15.
[Bug target/116429] [LRA] [M86k] Wrong spill offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116429 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Andreas Schwab --- Fixed for gcc 15.
[Bug target/113939] Switch m68k to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113939 Bug 113939 depends on bug 116374, which changed state. Bug 116374 Summary: [LRA] [M68K] Wrong %argptr elimination https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116374 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/113939] Switch m68k to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113939 Bug 113939 depends on bug 116429, which changed state. Bug 116429 Summary: [LRA] [M86k] Wrong spill offset https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116429 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/116174] [14/15 regression] Alignment request is added before endbr with -fcf-protection=branch since r15-888-gb644126237a1aa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116174 --- Comment #13 from GCC Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:d6bb1e257fc414d21bc31faa7ddecbc93a197e3c commit r15-3222-gd6bb1e257fc414d21bc31faa7ddecbc93a197e3c Author: H.J. Lu Date: Tue Aug 27 07:03:22 2024 -0700 Extend check-function-bodies to allow label and directives As PR target/116174 shown, we may need to verify labels and the directive order. Extend check-function-bodies to support matched output lines to allow label and directives. gcc/ * doc/sourcebuild.texi (check-function-bodies): Add an optional argument for matched output lines. gcc/testsuite/ * gcc.target/i386/pr116174.c: Use check-function-bodies. * lib/scanasm.exp (parse_function_bodies): Append the line if $up_config(matched) matches the line. (check-function-bodies): Add an argument for matched. Set up_config(matched) to $matched. Append the expected line without $config(line_prefix) to function_regexp if it starts with ".L". Signed-off-by: H.J. Lu
[Bug target/116497] Need no_caller_saved_registers with SSE support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497
--- Comment #12 from andi at firstfloor dot org ---
> no_call{er,ee}_saved_registers are i386-specific so how do we handle other
> ports? Are we going to require implementing them for all ports?
It's an optimization, so nothing is required. But yes if the other
targets want the more efficient interpreters they would need an
equivalent. clang's preserve_none/most currently is supported on aarch64
and x86-64. Right now I'm just trying to get it to work for x86.
[Bug target/116497] Need no_caller_saved_registers with SSE support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497
--- Comment #13 from andi at firstfloor dot org ---
> --- Comment #11 from H.J. Lu ---
> Please provide a small testcase to show the issue.
You mean a test case for no_caller_saved_registers failing with SSE?
It's just
__attribute__((no_caller_saved_registers)) void foo(void) {}
(if you compile without any special options, or use the
target dance as seen in the PHP github link above)
Or a test case for the intended register allocation benefits?
That's more complicated and won't be small.
[Bug tree-optimization/116501] New: wrong code with __builtin_sub_overflow_p() and _BitInt() at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116501 Bug ID: 116501 Summary: wrong code with __builtin_sub_overflow_p() and _BitInt() at -O1 Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz CC: jakub at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 59011 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59011&action=edit reduced testcase Output: $ x86_64-pc-linux-gnu-gcc -O0 testcase.c $ ./a.out $ x86_64-pc-linux-gnu-gcc -O1 testcase.c $ ./a.out Aborted $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r15-3187-20240826023505-g53b86cac7e7-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --enable-libsanitizer --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r15-3187-20240826023505-g53b86cac7e7-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 15.0.0 20240826 (experimental) (GCC)
[Bug target/116497] Need no_caller_saved_registers with SSE support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497 --- Comment #14 from Andrew Pinski --- (In reply to andi from comment #13) > Or a test case for the intended register allocation benefits? > That's more complicated and won't be small. So what if it won't be small but it will be understanding the overall benefit that is if it is a good idea or not. Note you can fake high register pressure by using inline-asm and clobbers which should make the testcase small really :).
[Bug tree-optimization/116501] wrong code with __builtin_sub_overflow_p() and _BitInt() at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116501 Andrew Pinski changed: What|Removed |Added Target|x86_64-pc-linux-gnu |x86_64-pc-linux-gnu ||aarch64-linux-gnu Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Host|x86_64-pc-linux-gnu | Last reconfirmed||2024-08-27 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug libstdc++/69600] [5 Regression] Incorrect use of copy-assignment instead of move assignment from function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69600
--- Comment #7 from sshannin at gmail dot com ---
Comment on attachment 37541
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37541
preprocessed source
> #include
> #include
> #include
>typedef std::unique_ptr inner_value_t;
>typedef std::map inner_data_t;
>
>typedef std::map data_t;
>
>
>data_t foo() {
>return data_t{};
>}
>
>int main(int argc, char **argv)
>{
>
>data_t d;
>d = foo();
>return 0;
>}
[Bug target/116497] Need no_caller_saved_registers with SSE support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497 --- Comment #15 from H.J. Lu --- (In reply to andi from comment #13) > > --- Comment #11 from H.J. Lu --- > > Please provide a small testcase to show the issue. > > You mean a test case for no_caller_saved_registers failing with SSE? No. We need a testcase to show the missed optimization without no_caller_saved_registers.
[Bug c++/116499] [modules] Replace CMI term with BMI in documentation, commit messages, etc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116499 --- Comment #1 from Andrew Pinski --- Note BMI is used as a x86_64 target instruction set; Bit manipulation instruction set .
[Bug c++/116502] New: [15 Regression] -Wunused-result warning is not supressed if coroutine awaiter returns a reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116502
Bug ID: 116502
Summary: [15 Regression] -Wunused-result warning is not
supressed if coroutine awaiter returns a reference
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: c++-coroutines
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: daklishch at gmail dot com
CC: arsen at gcc dot gnu.org
Target Milestone: ---
After 2664c1bf83855b79d8c43772e71b87ed4f09c174 (cp+coroutines: teach
convert_to_void to diagnose discarded co_awaits), the following code produces
-Wunused-result warning, while the caller clearly wants to suppress it by
casting the co_await result to void.
```
$ cat ../test.cpp
#include
struct SuspendNever {
bool await_ready() noexcept;
void await_suspend(std::coroutine_handle<>) noexcept;
void await_resume() noexcept;
};
struct Coroutine;
struct PromiseType {
Coroutine get_return_object();
SuspendNever initial_suspend();
SuspendNever final_suspend() noexcept;
void return_void();
};
struct Coroutine {
using promise_type = PromiseType;
};
struct Awaiter {
bool await_ready();
void await_suspend(std::coroutine_handle<>);
[[nodiscard]] int& await_resume();
};
Coroutine foo()
{
(void)co_await Awaiter {};
}
$ ~/gcc-15-trunk/bin/g++ ../test.cpp -c -std=c++20 -fno-exceptions
-Wunused-result -o /dev/null
../test.cpp: In function ‘Coroutine foo()’:
../test.cpp:30:29: warning: ignoring return value of ‘int&
Awaiter::await_resume()’, declared with attribute ‘nodiscard’ [-Wunused-result]
30 | (void)co_await Awaiter {};
| ^
../test.cpp:25:24: note: declared here
25 | [[nodiscard]] int& await_resume();
|^~~~
```
The warning is correctly suppressed unless Awaiter::await_resume returns a
reference.
[Bug middle-end/116503] New: wrong code with -O -fnon-call-exceptions -finstrument-functions -floop-nest-optimize -fno-tree-scev-cprop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116503 Bug ID: 116503 Summary: wrong code with -O -fnon-call-exceptions -finstrument-functions -floop-nest-optimize -fno-tree-scev-cprop Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 59012 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59012&action=edit reduced testcase Output: $ x86_64-pc-linux-gnu-gcc -O -fnon-call-exceptions -finstrument-functions -floop-nest-optimize -fno-tree-scev-cprop testcase.c $ ./a.out Aborted $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r15-3223-20240827072848-gee986126807-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --enable-libsanitizer --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r15-3223-20240827072848-gee986126807-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 15.0.0 20240826 (experimental) (GCC)
[Bug target/116497] Need no_caller_saved_registers with SSE support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497 --- Comment #16 from Andi Kleen --- Created attachment 59013 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59013&action=edit test case This test case using Pinski's clobber trick shows the benefit. If you compile with -O2 -mgeneral-regs-only the inc/dec opcodes don't save any extra registers and generate nearly optimal code. If you make the SAVE_REGS/DONT_SAVE_REGS macros empty they have a lot of extra push/pop, which would ruin the interpreter loop. -mgeneral-regs-only works for this case, but breaks SSE.
[Bug libstdc++/87614] User related warnings are hidden in system headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87614 --- Comment #5 from Jonathan Wakely --- We have a concept of "inlining locations" in the compiler, and we only consider a warning location to be in a system header if all call sites along the inlining stack are in system headers. It seems that concept should be expanded to consider the template instantiation stack. It's not just whether any user code call site has been inlined into a system header location, but also whether user code call sites instantiate template code from system headers. It's probably not that simple though; not all warnings in templates instantiated by user code are due to the user code.
[Bug c++/116502] [15 Regression] -Wunused-result warning cannot be suppressed if coroutine awaiter returns a reference after r15-2318-g2664c1bf83855b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116502 Andrew Pinski changed: What|Removed |Added Summary|[15 Regression] |[15 Regression] |-Wunused-result warning |-Wunused-result warning |cannot be suppressed if |cannot be suppressed if |coroutine awaiter returns a |coroutine awaiter returns a |reference |reference after ||r15-2318-g2664c1bf83855b Target Milestone|--- |15.0
[Bug target/116504] New: wrong code with -mcpu=sifive-x280
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116504 Bug ID: 116504 Summary: wrong code with -mcpu=sifive-x280 Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: riscv64-unknown-linux-gnu Created attachment 59014 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59014&action=edit reduced testcase I am using qemu-riscv64 userspace emulation; this might be an issue in the emulator, or in the way how I am using it, and not in the gcc. I am unable to tell where the issue is. I am having problems with -mcpu=sifive-x280 often, so I welcome any feedback on this. $ riscv64-unknown-linux-gnu-gcc -mcpu=sifive-x280 testcase.c -static $ qemu-riscv64 -- ./a.out Aborted $ riscv64-unknown-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-riscv64/bin/riscv64-unknown-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r15-3209-20240827075350-g103127cd939-checking-yes-rtl-df-extra-riscv64/bin/../libexec/gcc/riscv64-unknown-linux-gnu/15.0.0/lto-wrapper Target: riscv64-unknown-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --with-isa-spec=2.2 --with-sysroot=/usr/riscv64-unknown-linux-gnu --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=riscv64-unknown-linux-gnu --with-ld=/usr/bin/riscv64-unknown-linux-gnu-ld --with-as=/usr/bin/riscv64-unknown-linux-gnu-as --disable-multilib --enable-libsanitizer --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r15-3209-20240827075350-g103127cd939-checking-yes-rtl-df-extra-riscv64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 15.0.0 20240826 (experimental) (GCC)
[Bug target/116504] wrong code with -mcpu=sifive-x280
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116504 --- Comment #1 from Zdenek Sojka --- Created attachment 59015 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59015&action=edit another reduced testcase
[Bug c++/116208] `__ct_base ` is used instead of the ctor name in warning's `inlined from` when using LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116208 Simon Martin changed: What|Removed |Added CC||simartin at gcc dot gnu.org --- Comment #8 from Simon Martin --- Thanks sjames@ for tagging me in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105483. My hunch is that we end up printing the internal name because of the if (!DECL_LANG_SPECIFIC (t)) in error.cc's dump_function_name (in which case I think the bug can't really be fixed...), but I don't know how to be sure. How do you reproduce this? Are you configuring with --with-build-config=bootstrap-lto?
[Bug libstdc++/58876] No non-virtual-dtor warning in std::unique_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58876
--- Comment #15 from Jonathan Wakely ---
This seems simpler and cleaner:
--- a/gcc/cp/init.cc
+++ b/gcc/cp/init.cc
@@ -5244,6 +5244,10 @@ build_delete (location_t loc, tree otype, tree addr,
tree dtor = CLASSTYPE_DESTRUCTOR (type);
if (!dtor || !DECL_VINDEX (dtor))
{
+ const bool prev = global_dc->m_warn_system_headers;
+ // Don't suppress this warning in system headers.
+ global_dc->m_warn_system_headers = true;
+
if (CLASSTYPE_PURE_VIRTUALS (type))
warning_at (loc, OPT_Wdelete_non_virtual_dtor,
"deleting object of abstract class type %qT"
@@ -5254,6 +5258,7 @@ build_delete (location_t loc, tree otype, tree addr,
"deleting object of polymorphic class type %qT"
" which has non-virtual destructor"
" might cause undefined behavior", type);
+ global_dc->m_warn_system_headers = prev;
}
}
}
This warning is always useful, even in system headers.
But Jason is working on an ever better solution, so that we can stop using the
system_header pragma in libstdc++ headers.
[Bug target/116497] Need no_caller_saved_registers with SSE support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497 --- Comment #17 from H.J. Lu --- (In reply to Andi Kleen from comment #16) > Created attachment 59013 [details] > test case > > This test case using Pinski's clobber trick shows the benefit. > > If you compile with -O2 -mgeneral-regs-only the inc/dec opcodes don't save > any extra registers and generate nearly optimal code. If you make the > SAVE_REGS/DONT_SAVE_REGS macros empty they have a lot of extra push/pop, > which would ruin the interpreter loop. > > -mgeneral-regs-only works for this case, but breaks SSE. Why is __attribute__((no_caller_saved_registers)) needed on start?
[Bug c++/110881] Feature request: an attribute for enum members that would skip the -Wswitch-enum warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110881 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org Target Milestone|--- |13.0 Known to work||13.0 Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jason Merrill --- This already works in GCC 13.1, you just need to put the attribute after the enumerator name, e.g. eMyEnum_Count __attribute__((__unused__)) or eMyEnum_Count [[maybe_unused]] *** This bug has been marked as a duplicate of bug 105497 ***
[Bug c++/105497] -Wswitch ignores [[maybe_unused]] for an enumerator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105497 Jason Merrill changed: What|Removed |Added CC||valentyn.pavliuchenko@gmail ||.com --- Comment #4 from Jason Merrill --- *** Bug 110881 has been marked as a duplicate of this bug. ***
[Bug driver/110522] `-fdiagnostics-format=sarif-file`: file name conflicts / races
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110522 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #5 from Eric Gallager --- (In reply to David Malcolm from comment #4) > But it would also be nice to support multiple output streams e.g. > > -fdiagnostics-format=text,sarif-file=path/to/foo.sarif Yeah, I was hoping for multiple output streams myself, to be able to bring things closer to how `clang --analyze` operates (outputs analysis results to both stdout and a plist file)
[Bug target/116505] New: ICE: in gen_reg_rtx, at emit-rtl.cc:1177 with -O -fprofile-arcs -fprofile-values -flate-combine-instructions on powerpc64le with basic code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116505
Bug ID: 116505
Summary: ICE: in gen_reg_rtx, at emit-rtl.cc:1177 with -O
-fprofile-arcs -fprofile-values
-flate-combine-instructions on powerpc64le with basic
code
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: powerpc64le-unknown-linux-gnu
Output:
$ cat testcase.c
void foo() {}
$ powerpc64le-unknown-linux-gnu-gcc -O -fprofile-arcs -fprofile-values
-flate-combine-instructions testcase.c
during RTL pass: split2
testcase.c: In function 'foo':
testcase.c:1:13: internal compiler error: in gen_reg_rtx, at emit-rtl.cc:1177
1 | void foo() {}
| ^
0x1fd5e2e internal_error(char const*, ...)
/repo/gcc-trunk/gcc/diagnostic-global-context.cc:491
0x9dffc5 fancy_abort(char const*, int, char const*)
/repo/gcc-trunk/gcc/diagnostic.cc:1772
0x6ba3fa gen_reg_rtx(machine_mode)
/repo/gcc-trunk/gcc/emit-rtl.cc:1177
0x1b83879 gen_split_394(rtx_insn*, rtx_def**)
/repo/gcc-trunk/gcc/config/rs6000/rs6000.md:10773
0x1cc43ea split_17
/repo/gcc-trunk/gcc/config/rs6000/rs6000.md:490
0xc86ddd try_split(rtx_def*, rtx_insn*, int)
/repo/gcc-trunk/gcc/emit-rtl.cc:3941
0x1056558 split_insn
/repo/gcc-trunk/gcc/recog.cc:3475
0x105d625 split_all_insns()
/repo/gcc-trunk/gcc/recog.cc:3579
0x105d748 execute
/repo/gcc-trunk/gcc/recog.cc:4503
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++/115905] [coroutines] Wrong behavior of await_suspend()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115905 Artyom Kolpakov changed: What|Removed |Added See Also||https://github.com/cplusplu ||s/CWG/issues/601 --- Comment #1 from Artyom Kolpakov --- If anyone on the gcc team sees this, please look at the attached links, check out the post history, and comment on this situation. Need to look into this and decide what to do.
[Bug target/115612] powerpc: define_insn_and_splits calling gen_reg_rtx unconditionally (-flate-combine disabled by default for powerpc port)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115612 Andrew Pinski changed: What|Removed |Added CC||zsojka at seznam dot cz --- Comment #4 from Andrew Pinski --- *** Bug 116505 has been marked as a duplicate of this bug. ***
[Bug target/116505] ICE: in gen_reg_rtx, at emit-rtl.cc:1177 with -O -fprofile-arcs -fprofile-values -flate-combine-instructions on powerpc64le with basic code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116505 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 115612 ***
[Bug target/115612] powerpc: define_insn_and_splits calling gen_reg_rtx unconditionally (-flate-combine disabled by default for powerpc port)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115612 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-08-27 Ever confirmed|0 |1 --- Comment #5 from Andrew Pinski --- .
[Bug c++/112456] Diagnostic for [[nodiscard]] on a constructor could be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112456 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org Severity|normal |enhancement
[Bug target/116497] Need no_caller_saved_registers with SSE support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497 --- Comment #18 from andi at firstfloor dot org --- > > -mgeneral-regs-only works for this case, but breaks SSE. > > Why is __attribute__((no_caller_saved_registers)) needed on start? To maintain the standard ABI to its caller. Otherwise the final return could clobber caller state. Basically the optimization is to move all the save/returns to only one wrapper function, not every interpreter op function.
[Bug target/116497] Need no_caller_saved_registers with SSE support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497 --- Comment #19 from H.J. Lu --- (In reply to andi from comment #18) > > > -mgeneral-regs-only works for this case, but breaks SSE. > > > > Why is __attribute__((no_caller_saved_registers)) needed on start? > > To maintain the standard ABI to its caller. Otherwise the final > return could clobber caller state. GCC should do the right thing without no_caller_saved_registers. If not, it is a GCC bug. Do you have a testcase to show such GCC bug?
[Bug ipa/116410] -ffat-lto-objects generates different and inefficient code compared with -fno-fat-lto-objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116410 --- Comment #5 from H.J. Lu --- Created attachment 59016 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59016&action=edit A patch Please try this.
[Bug rtl-optimization/116488] [15 Regression] wrong code at -O{s,2,3} with "-fno-forward-propagate" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116488 Jeffrey A. Law changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |law at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Jeffrey A. Law --- Mine, obviously. Interestingly enough this seems to closely relate to a comment I added a while back about the placement of a function call being in the wrong place.
[Bug ipa/116410] -ffat-lto-objects generates different and inefficient code compared with -fno-fat-lto-objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116410 H.J. Lu changed: What|Removed |Added Status|NEW |WAITING
[Bug c++/116502] [15 Regression] -Wunused-result warning cannot be suppressed if coroutine awaiter returns a reference after r15-2318-g2664c1bf83855b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116502
Arsen Arsenović changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2024-08-27
--- Comment #1 from Arsen Arsenović ---
thanks for the report!
candidate patchlet:
modified gcc/cp/coroutines.cc
@@ -3423,7 +3423,14 @@ maybe_promote_temps (tree *stmt, void *d)
to run the initializer.
If the initializer is a conditional expression, we need to collect
and declare any promoted variables nested within it. DTORs for such
-variables must be run conditionally too. */
+variables must be run conditionally too.
+
+Since here we're synthetically processing code here, we've already
+emitted any Wunused-result warnings. Below, however, we call
+finish_expr_stmt, which will convert its operand to void, and could
+result in such a diagnostic being emitted. To avoid that, convert to
+void ahead of time.
+ */
if (t->var)
{
tree var = t->var;
@@ -3433,7 +3440,7 @@ maybe_promote_temps (tree *stmt, void *d)
if (TREE_CODE (t->init) == COND_EXPR)
process_conditional (t, vlist);
else
- finish_expr_stmt (t->init);
+ finish_expr_stmt (build1 (CONVERT_EXPR, void_type_node, t->init));
if (tree cleanup = cxx_maybe_build_cleanup (var,
tf_warning_or_error))
{
tree cl = build_stmt (sloc, CLEANUP_STMT, expr_list, cleanup,
var);
@@ -3452,7 +3459,7 @@ maybe_promote_temps (tree *stmt, void *d)
if (TREE_CODE (t->init) == COND_EXPR)
process_conditional (t, vlist);
else
- finish_expr_stmt (t->init);
+ finish_expr_stmt (build1 (CONVERT_EXPR, void_type_node, t->init));
if (expr_list)
{
if (TREE_CODE (expr_list) != STATEMENT_LIST)
[Bug target/116497] Need no_caller_saved_registers with SSE support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497 --- Comment #20 from andi at firstfloor dot org --- On Tue, Aug 27, 2024 at 05:12:41PM +, hjl.tools at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497 > > --- Comment #19 from H.J. Lu --- > (In reply to andi from comment #18) > > > > -mgeneral-regs-only works for this case, but breaks SSE. > > > > > > Why is __attribute__((no_caller_saved_registers)) needed on start? > > > > To maintain the standard ABI to its caller. Otherwise the final > > return could clobber caller state. > > GCC should do the right thing without no_caller_saved_registers. If not, > it is a GCC bug. Do you have a testcase to show such GCC bug? The test case is the same, just commenting out SAVE_REGS. You're right. It seems gcc does the right thing based on the callee ABIs. I hadn't realized that. So yes the attribute and the change are not really needed. Good news.
[Bug target/116497] Need no_caller_saved_registers with SSE support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497 --- Comment #21 from Andi Kleen --- As HJ pointed out the change is not needed, the compiler DTRT with no_callee_saved_registers on the callees.
[Bug target/116497] Need no_caller_saved_registers with SSE support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116497 Andi Kleen changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING |RESOLVED
[Bug c++/116502] [15 Regression] -Wunused-result warning cannot be suppressed if coroutine awaiter returns a reference after r15-2318-g2664c1bf83855b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116502 --- Comment #2 from Dan Klishch --- Can confirm that the patch fixes both the minified reproducer from the bug report and also the original reproducer (TestAsyncTestStreams from SerenityOS).
[Bug tree-optimization/116500] gcc.dg/vect/vect-switch-ifcvt-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116500 --- Comment #2 from Andi Kleen --- Do you have the dump file from tree-vect? I guess it just doesn't vectorize something here. The right fix is probably to skip it for sparc, or adjust the vect_int target test.
[Bug fortran/113412] ATAN(Y,X) does not check arguments and generates wrong error message.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113412
--- Comment #12 from anlauf at gcc dot gnu.org ---
(In reply to kargls from comment #11)
I tried a simpler variation of your patch that aims at a more coherent
error message:
diff --git a/gcc/fortran/intrinsic.cc b/gcc/fortran/intrinsic.cc
index f7cbb4bb5e2..28b27874298 100644
--- a/gcc/fortran/intrinsic.cc
+++ b/gcc/fortran/intrinsic.cc
@@ -4377,10 +4377,22 @@ sort_actual (const char *name, gfc_actual_arglist **ap,
if (a == NULL)
goto do_sort;
+ /* The generic interface of the following intrinsics was extended in F2008.
+ A specific interface may not be available at a selected standard. */
+ if ((gfc_option.allow_std & GFC_STD_F2008) != 0
+ && (strcmp (name, "atan") == 0
+ || strcmp (name, "atand") == 0))
+goto no_specific;
+
whoops:
gfc_error ("Too many arguments in call to %qs at %L", name, where);
return false;
+no_specific:
+ gfc_error ("Generic function %qs at %L is not consistent with a "
+"specific intrinsic interface", name, where);
+ return false;
+
keywords:
/* Associate the remaining actual arguments, all of which have
to be keyword arguments. */
With this you get the message:
Error: Generic function 'atan' at (1) is not consistent with a specific
intrinsic interface
whether atan is explicitly declared as intrinsic or not.
> Now, to real cause so head scratching. keywords are not honored!
>
> subroutine s3
> real :: r = 1.
> print *, atan (y=-1.d0,x=r) ! Should give error similar to s1 case
> end
>
> % gfcx -c a.f90
> a.f90:3:10:
>
> 3 | print *, atan (y=-1.d0,x=r) ! Should give error similar to
> s1 case
> | 1
> Error: Cannot find keyword named ‘y’ in call to ‘atan’ at (1)
>
> I think we need to rethink the handling of the 2 argument case, where we
> make the second argument optional. Then, in gfc_check_atan, we need to
> swap expressions to align Y with arg1 and X with arg2.
Yes, this is because once a keyword is used, we never reach the check.
Which makes me think whether sort_actual is the right place for the check.
Is there any generic intrinsic where a keyword is needed for resolving?
Besides the weird ALLOCATED(), where there can be only one argument
(ARRAY or SCALAR), but then this is a fixed number.
[Bug tree-optimization/116500] gcc.dg/vect/vect-switch-ifcvt-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116500 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #2 from Andi Kleen --- > Do you have the dump file from tree-vect? Already attached. > I guess it just doesn't vectorize something here. > > The right fix is probably to skip it for sparc, or adjust the vect_int target > test. I'd strongly prefer to adjust the requirements as needed, rather than xfailing/skipping it for specific targets. The latter is hardly maintainable.
[Bug c++/105483] [12/13/14/15 Regression] injected-class-name and constructors diagnostic since r8-1739-g3b5c768c40c78618
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105483
--- Comment #6 from GCC Commits ---
The master branch has been updated by Simon Martin :
https://gcc.gnu.org/g:02dff52c60e5b89d290147f142f655c7817154c2
commit r15-3232-g02dff52c60e5b89d290147f142f655c7817154c2
Author: Simon Martin
Date: Mon Aug 26 14:09:46 2024 +0200
c++: Don't show constructor internal name in error message [PR105483]
We mention 'X::__ct' instead of 'X::X' in the "names the constructor,
not the type" error for this invalid code:
=== cut here ===
struct X {};
void g () {
X::X x;
}
=== cut here ===
The problem is that we use %<%T::%D%> to build the error message, while
%qE does exactly what we need since we have DECL_CONSTRUCTOR_P. This is
what this patch does.
It also skips until the end of the statement and returns error_mark_node
for this and the preceding if block, to avoid emitting extra (useless)
errors.
PR c++/105483
gcc/cp/ChangeLog:
* parser.cc (cp_parser_expression_statement): Use %qE instead of
incorrect %<%T::%D%>. Skip to end of statement and return
error_mark_node in case of error.
gcc/testsuite/ChangeLog:
* g++.dg/parse/error36.C: Adjust test expectation.
* g++.dg/tc1/dr147.C: Likewise.
* g++.old-deja/g++.other/typename1.C: Likewise.
* g++.dg/diagnostic/pr105483.C: New test.
[Bug c++/105483] [12/13/14/15 Regression] injected-class-name and constructors diagnostic since r8-1739-g3b5c768c40c78618
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105483 Simon Martin changed: What|Removed |Added Target Milestone|12.5|15.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Simon Martin --- Fixed on trunk.
[Bug ipa/116410] -ffat-lto-objects generates different and inefficient code compared with -fno-fat-lto-objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116410 H.J. Lu changed: What|Removed |Added Status|WAITING |NEW --- Comment #6 from H.J. Lu --- A patch is posted at https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661631.html
[Bug c++/106294] GCC accepts the undefined behavior operation in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106294 Carlos Galvez changed: What|Removed |Added CC||carlosgalvezp at gmail dot com --- Comment #2 from Carlos Galvez --- Please note: clang trunk now correctly detects this as a hard error. GCC might want to tag along: https://godbolt.org/z/54YvGPs6d
[Bug target/116413] [LRA] [M68K] ICE: unrecognized insn in lra_set_insn_recog_data, at lra.cc:1036
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116413 --- Comment #21 from GCC Commits --- The master branch has been updated by Andreas Schwab : https://gcc.gnu.org/g:a83e519ab2d4e7df2756411cd9d21c6f1b583429 commit r15-3233-ga83e519ab2d4e7df2756411cd9d21c6f1b583429 Author: Andreas Schwab Date: Tue Aug 27 21:01:00 2024 +0200 m68k: Accept ASHIFT like MULT in address operand When LRA pulls an address operand out of a MEM it caninoicalizes a containing MULT into ASHIFT. Adjust the address decomposer to recognize this form. PR target/116413 * config/m68k/m68k.cc (m68k_decompose_index): Accept ASHIFT like MULT. (m68k_rtx_costs) [PLUS]: Likewise. (m68k_legitimize_address): Likewise.
[Bug target/113939] Switch m68k to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113939 Bug 113939 depends on bug 116413, which changed state. Bug 116413 Summary: [LRA] [M68K] ICE: unrecognized insn in lra_set_insn_recog_data, at lra.cc:1036 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116413 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
