[Bug tree-optimization/118430] tail call vs IPA-VRP return value range with constant value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118430
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Component|middle-end |tree-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed||2025-01-12
Keywords||missed-optimization,
||rejects-valid
Severity|normal |enhancement
Summary|musttail false positive on |tail call vs IPA-VRP return
|how locals are used |value range with constant
||value
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #4)
> Oh for -O2, this is IPA VRP coming into play.
>
> It is turning:
> [[gnu::musttail]]
> return tail_call2(opcode);
>
> into
>
> tail_call2(opcode);
> return 2;
s/2/1/ .
The error message is definitely wrong.
```
/* We may proceed if there either is no return value, or the return value
is identical to the call's return or if the return decl is an empty type
variable and the call's return was not assigned. */
if (ret_var
&& (ret_var != ass_var
&& !(is_empty_type (TREE_TYPE (ret_var)) && !ass_var)))
{
maybe_error_musttail (call, _("call uses return slot"));
return;
}
```
>From EVRP:
Using return value range of tail_call2: [irange] int [1, 1]
tail call should be able to check the call's return value range to see if it
same as the value here.
The -O0 case is due to -O0 does do any optimizations and I highly doubt it can
handle musttail at all.
[Bug tree-optimization/118430] [14/15 Regression] tail call vs IPA-VRP return value range with constant value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118430 --- Comment #8 from Ken Jin --- Thanks a lot for your help on this! I think I've narrowed down what's happening with CPython. It seems what's happening in CPython is not a bug, but should be a feature request. I will file a separate feature request for that. Thanks again for your time.
[Bug middle-end/118430] musttail false positive on how locals are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118430 --- Comment #4 from Andrew Pinski --- Oh for -O2, this is IPA VRP coming into play. It is turning: [[gnu::musttail]] return tail_call2(opcode); into tail_call2(opcode); return 2; Which needs to go in the opposite direction and such. Note if you use noipa instead of noinline, this testcase will work. I also highly doubt this is representative of the CPython code either.
[Bug tree-optimization/118430] [14/15 Regression] tail call vs IPA-VRP return value range with constant value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118430 --- Comment #6 from Andrew Pinski --- Created attachment 60120 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60120&action=edit testcase that shows this is a regression for -O2+ In GCC 13, GCC would produce: jmp tail_call2 Now it does do a tail call due to proping the 1.
[Bug tree-optimization/118430] [14/15 Regression] tail call vs IPA-VRP return value range with constant value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118430 Andrew Pinski changed: What|Removed |Added Summary|tail call vs IPA-VRP return |[14/15 Regression] tail |value range with constant |call vs IPA-VRP return |value |value range with constant ||value Target Milestone|--- |14.3
[Bug libstdc++/112808] Consider enabling _GLIBCXX_ASSERTIONS checks by default for debug builds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112808 --- Comment #7 from Sam James --- By the way, Helge, I also got Meson defaulting to this whenever NDEBUG isn't enabled last year and we had very few complaints.
[Bug tree-optimization/118430] [14/15 Regression] tail call vs IPA-VRP return value range with constant value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118430 --- Comment #7 from Andrew Pinski --- >fails to compile on GCC after applying patches to make it detect GCC: >https://github.com/python/cpython/pull/128718 Maybe the best thing is to file a bug report with a non-reduce testcase since -O2+ here is a specific issue with IPA VRP return values causing the tail call to be missed and I am 99% sure it is unrelated to what is going wrong with cpython.
[Bug c/118431] New: [Feature request]: warn about escaped local variables in musttail instead of error-ing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118431 Bug ID: 118431 Summary: [Feature request]: warn about escaped local variables in musttail instead of error-ing Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: kenjin4096 at gmail dot com Target Milestone: --- Dear GCC maintainers, Currently, GCC 15.0 on commit c1729df6ec1eff4815a9cdd71392691ce21da028 blocks functions with `musttail` from compiling if it determines a local variable escapes: https://github.com/gcc-mirror/gcc/blob/master/gcc/tree-tailcall.cc#L706 This leads to many false positives on real-world code when interprocedural analysis wrongly determines something escapes, for example, a common pattern is to pass local variables as pointers to simulate multiple return values in C. This triggers the check above. This is one example (from a PR I am working on): https://github.com/python/cpython/blob/d26ef11ad0259e450b53be33b87011635d4b3dce/Python/generated_tail_call_handlers.c.h#L76 May I propose to either: 1. Relax the check to a warning or if not possible, 2. Allow passing a flag to ignore that check, because a human has determined that the value does not escape. please? Locally, I commented out that check in GCC and rebuilt my PR https://github.com/python/cpython/pull/128718 (with some local patches applied) with GCC trunk -Og, and it passes the entire CPython test suite, except for some gdb failures which are expected. Branched-off from previous issue at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118430 Thank you for your time. Regards, Ken Jin
[Bug c/118431] [Feature request]: warn about escaped local variables in musttail instead of error-ing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118431 --- Comment #1 from Sam James --- Can you include preprocessed source for a TU which hits this please? (Give us a standalone reproducer, even if large.)
[Bug tree-optimization/118431] [Feature request]: warn about escaped local variables in musttail instead of error-ing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118431 --- Comment #2 from Andrew Pinski --- I rather keep the error since it might allow someone to use musttail incorrectly. Where the variable actually does escape.
[Bug tree-optimization/118431] [Feature request]: warn about escaped local variables in musttail instead of error-ing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118431 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement --- Comment #3 from Andrew Pinski --- > 2. Allow passing a flag to ignore that check, because a human has determined > that the value does not escape. > please? This is a very very bad idea. It is one of the reasons why I say having musttail was a bad idea in the first place.
[Bug tree-optimization/118431] [Feature request]: warn about escaped local variables in musttail instead of error-ing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118431 Andrew Pinski changed: What|Removed |Added Depends on||21093 --- Comment #4 from Andrew Pinski --- Now GCC should be able to do better at tail calls in general, see PR 21093 for an example. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21093 [Bug 21093] missed tail call optimization when local address could escape
[Bug tree-optimization/84824] DCE fails to remove dead code of std::function constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84824 Andrew Pinski changed: What|Removed |Added Depends on||23384 --- Comment #19 from Andrew Pinski --- So this is basically PR 23384. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23384 [Bug 23384] escaped set should be flow sensitive
[Bug tree-optimization/118431] [Feature request]: warn about escaped local variables in musttail instead of error-ing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118431 Ken Jin changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #5 from Ken Jin --- Hmm, on further consideration, I don't think I should put the burden on GCC to allow this. I can shape the code so that it works both on Clang and GCC according to the comment by Andrew at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118430#c1 Sorry for the noise!
[Bug target/118429] [15 regression] ICE when building poppler-24.11.0 on arm64 (in process_uses_of_deleted_def, at rtl-ssa/changes.cc:276)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118429 --- Comment #3 from Sam James --- Created attachment 60121 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60121&action=edit Annot.cc.ii.xz checkpoint
[Bug fortran/118432] New: Test cases failing when gfc_code.ext is turned into a struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118432
Bug ID: 118432
Summary: Test cases failing when gfc_code.ext is turned into a
struct
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
Turning gfc_code.ext into a struct is wasteful of memory, but it
can be used to find problems where the compiler depends on
accidental initialization.
With the patch
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index aa495b5487e..554ad5da16d 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -3125,7 +3125,7 @@ typedef struct gfc_code
gfc_symbol *resolved_sym;
gfc_intrinsic_sym *resolved_isym;
- union
+ struct
{
gfc_actual_arglist *actual;
gfc_iterator *iterator;
quite a few test cases fail, all of them with segmentation
violations in the compiler:
gfortran.dg/dec_io_1.f90
gfortran.dg/dec_io_2.f90
gfortran.dg/dec_io_6.f90
gfortran.dg/dec_io_7.f90
gfortran.dg/do_check_9.f90
gfortran.dg/dtio_15.f90
gfortran.dg/f2003_inquire_1.f03
gfortran.dg/filename_null.f90
gfortran.dg/g77/19990419-0.f
gfortran.dg/inquire_10.f90
gfortran.dg/inquire_11.f90
gfortran.dg/inquire_12.f90
gfortran.dg/inquire_13.f90
gfortran.dg/inquire_15.f90
gfortran.dg/inquire_16.f90
gfortran.dg/inquire_17.f90
gfortran.dg/inquire_18.f90
gfortran.dg/inquire_19.f90
gfortran.dg/inquire_5.f90
gfortran.dg/inquire_6.f90
gfortran.dg/inquire_7.f90
gfortran.dg/inquire_9.f90
gfortran.dg/inquire.f90
gfortran.dg/inquire_internal.f90
gfortran.dg/inquire_pre.f90
gfortran.dg/inquire_recl_f2018.f90
gfortran.dg/inquire_size.f90
gfortran.dg/io_constraints_10.f90
gfortran.dg/io_constraints_11.f90
gfortran.dg/io_constraints_12.f90
gfortran.dg/io_constraints_13.f90
gfortran.dg/io_constraints_7.f03
gfortran.dg/io_constraints_8.f90
gfortran.dg/io_tags_5.f90
gfortran.dg/large_recl.f90
gfortran.dg/large_unit_1.f90
gfortran.dg/large_unit_2.f90
gfortran.dg/make_unit.f90
gfortran.dg/negative_unit.f
gfortran.dg/negative_unit_int8.f
gfortran.dg/open_errors.f90
gfortran.dg/open_negative_unit_1.f90
gfortran.dg/pr20950.f
gfortran.dg/pr88248.f90
gfortran.dg/streamio_10.f90
gfortran.dg/streamio_15.f90
gfortran.dg/streamio_16.f90
gfortran.dg/streamio_18.f90
gfortran.dg/streamio_3.f90
gfortran.dg/streamio_8.f90
gfortran.dg/unf_io_convert_4.f90
gfortran.fortran-torture/execute/inquire_1.f90
gfortran.fortran-torture/execute/inquire_2.f90
gfortran.fortran-torture/execute/inquire_3.f90
gfortran.fortran-torture/execute/inquire_4.f90
gfortran.fortran-torture/execute/inquire_5.f90
libgomp.fortran/async_io_1.f90
libgomp.fortran/rwlock_1.f90
This could be something working (under normal conditions) by accident
by aliasing
gfc_open *open;
gfc_close *close;
gfc_filepos *filepos;
gfc_inquire *inquire;
gfc_wait *wait;
because all of these appear to be I/O related.
[Bug c++/118433] Local scope deletion of a function is wrongly accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118433 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 96207 ***
[Bug c++/96207] GCC accepts "delete" function definition inside a class member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96207 Andrew Pinski changed: What|Removed |Added CC||fchelnokov at gmail dot com --- Comment #2 from Andrew Pinski --- *** Bug 118433 has been marked as a duplicate of this bug. ***
[Bug c++/118433] New: Local scope deletion of a function is wrongly accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118433
Bug ID: 118433
Summary: Local scope deletion of a function is wrongly accepted
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fchelnokov at gmail dot com
Target Milestone: ---
This program is accepted in GCC:
int main() {
void bar() = delete;
}
with the warning
> warning: declaration of 'void bar()' has 'extern' and is initialized
but it shall be an error, since '= delete' is a function definition and must
occur in a standalone declaration.
Online demo: https://gcc.godbolt.org/z/46dMz8n8K
[Bug c++/96207] GCC accepts "delete" function definition inside a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96207 --- Comment #3 from Andrew Pinski --- Does not need to be a member function/method. Just a function is enough.
[Bug c++/111079] Failing to reject a defaulted/deleted local function definition if it is a friend of a local class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111079 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 96207 ***
[Bug c++/96207] GCC accepts "delete" function definition inside a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96207 Andrew Pinski changed: What|Removed |Added CC||janschultke at googlemail dot com --- Comment #4 from Andrew Pinski --- *** Bug 111079 has been marked as a duplicate of this bug. ***
[Bug fortran/118432] Test cases failing when gfc_code.ext is turned into a struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118432 Thomas Koenig changed: What|Removed |Added Last reconfirmed||2025-01-12 Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Thomas Koenig --- Mine.
[Bug fortran/118432] Test cases failing when gfc_code.ext is turned into a struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118432 --- Comment #2 from Thomas Koenig --- Simple and obvious fix: diff --git a/gcc/fortran/frontend-passes.cc b/gcc/fortran/frontend-passes.cc index 3a3328d4450..6ee6ce4c3ff 100644 --- a/gcc/fortran/frontend-passes.cc +++ b/gcc/fortran/frontend-passes.cc @@ -2552,7 +2552,7 @@ doloop_code (gfc_code **c, int *walk_subtrees ATTRIBUTE_UNUSED, break; case EXEC_INQUIRE: - if (co->ext.filepos->err) + if (co->ext.inquire->err) seen_goto = true; break;
[Bug fortran/118432] Test cases failing when gfc_code.ext is turned into a struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118432 Thomas Koenig changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Thomas Koenig --- Fixed with r15-6831-g40754a3b9bef83bf4da0675fcb378e8cd1675602 . Closing.
[Bug sanitizer/118436] New: Bogus Warning in Tuple with empty constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118436 Bug ID: 118436 Summary: Bogus Warning in Tuple with empty constructor Product: gcc Version: 14.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: disservin.social at gmail dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Target Milestone: --- Created attachment 60123 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60123&action=edit reproduction The following code generates a bogus warning coming from the stdlib https://godbolt.org/z/orn98Gdqd Compiled with: -O1 -fsanitize=address -Wall -Wextra
[Bug target/116447] g++.dg/cpp23/ext-floating13.C fails on Cortex-M55 due to undefined reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116447 --- Comment #7 from Torbjorn SVENSSON --- Indeed, it looks like this could be related. @Christophe, did you take a look at issue in ticket 117814 or is that still on your todo list? If you did, do you think these tickets are related?
[Bug target/118439] [15 Regression] comparison failure on powerpc64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118439 Sam James changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Sam James --- Almost certainly the same as PR118409. Try https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118417#c1 to confirm *** This bug has been marked as a duplicate of bug 118409 ***
[Bug tree-optimization/118409] [15 regression] gas miscompiled by ifcombine ("Unsupported broadcast" assemble failure) since r15-6774-g740c84975ceb74
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118409 Sam James changed: What|Removed |Added CC||doko at gcc dot gnu.org --- Comment #22 from Sam James --- *** Bug 118439 has been marked as a duplicate of this bug. ***
[Bug target/118439] New: [15 Regression] comparison failure on powerpc64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118439 Bug ID: 118439 Summary: [15 Regression] comparison failure on powerpc64-linux-gnu Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Target Milestone: --- seen with trunk 20250112 on powerpc64-linux-gnu, last successful build on 20250101: [...] Comparing stages 2 and 3 Bootstrap comparison failure! gcc/diagnostic-path.o differs gcc/range-op.o differs make[4]: *** [Makefile:31603: compare] Error 1 Configured with: -v --with-pkgversion='Debian 15-20250112-1' --with-bugurl='file:///usr/share/doc/gcc-15/README.Bugs' --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,rust --prefix=/usr --with-gcc-major-version-only --program-suffix=-15 --program-prefix=powerpc64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/libexec --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-libstdcxx-backtrace --enable-gnu-unique-object --disable-libquadmath --disable-libquadmath-support --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --with-libphobos-druntime-only=yes --enable-objc-gc=auto --enable-secureplt --disable-softfloat --enable-targets=powerpc64-linux,powerpc-linux --enable-multiarch --disable-werror --with-long-double-128 --enable-multilib --enable-checking=yes,extra,rtl --build=powerpc64-linux-gnu --host=powerpc64-linux-gnu --target=powerpc64-linux-gnu
[Bug d/118438] [15 Regression] libgphobos fails to build on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118438 Matthias Klose changed: What|Removed |Added Target|s390x-linux-gnu |s390x-linux-gnu ||loongarch64-linux-gnu --- Comment #1 from Matthias Klose --- same on loongarch64-linux-gnu
[Bug middle-end/118417] [15 Regression] Bootstrap comparison failure! gcc/range-op.o differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118417 --- Comment #4 from John David Anglin --- We have the following new fails on hppa64-hp-hpux11.11: +FAIL: gcc.c-torture/execute/20040709-1.c -O1 execution test +FAIL: gcc.c-torture/execute/20040709-1.c -O2 execution test +FAIL: gcc.c-torture/execute/20040709-1.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test +FAIL: gcc.c-torture/execute/20040709-1.c -O3 -g execution test +FAIL: gcc.c-torture/execute/20040709-1.c -Os execution test +FAIL: gcc.c-torture/execute/20040709-2.c -O1 execution test +FAIL: gcc.c-torture/execute/20040709-2.c -O2 execution test +FAIL: gcc.c-torture/execute/20040709-2.c -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test +FAIL: gcc.c-torture/execute/20040709-2.c -O3 -g execution test +FAIL: gcc.c-torture/execute/20040709-2.c -Os execution test +FAIL: gcc.c-torture/execute/20040709-3.c -O1 execution test +FAIL: gcc.c-torture/execute/20040709-3.c -O2 execution test +FAIL: gcc.c-torture/execute/20040709-3.c -O3 -g execution test +FAIL: gcc.c-torture/execute/20040709-3.c -Os execution test Jeff noted the same tests fail on m32r, h8300 and iq2000 and they bisect back to the change as for PR 118409. So, likely this is same problem.
[Bug target/118429] [15 regression] ICE when building poppler-24.11.0 on arm64 (in process_uses_of_deleted_def, at rtl-ssa/changes.cc:276)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118429 Sam James changed: What|Removed |Added Attachment #60121|0 |1 is obsolete|| Attachment #60122|0 |1 is obsolete|| --- Comment #5 from Sam James --- Created attachment 60124 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60124&action=edit reduced.ii
[Bug target/118437] New: Unable to include arm_fp16.h on a MVE capable Cortex-M target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118437 Bug ID: 118437 Summary: Unable to include arm_fp16.h on a MVE capable Cortex-M target Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: azoff at gcc dot gnu.org Target Milestone: --- The arm_fp16.h header file contains NEON intrinsics. Including the header file on a MVE capable Cortex-M target should work, but now generates about 4000 lines for errors. See https://gcc.gnu.org/pipermail/gcc-patches/2024-November/669426.html for deatils
[Bug ipa/118400] memory leak of irange at evaluate_properties_for_edge (ipa-fnsummary.cc:690)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118400 --- Comment #1 from Richard Biener --- Created attachment 60125 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60125&action=edit preprocessed source The following is sligtly reduced from preprocessed gv.c valgrind --leak-check=full ./gcc/cc1 -fpreprocessed gv.i -quiet -O2 -std=c99 shows the leaks.
[Bug c++/118440] New: Wrong zero initialization with tuple usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118440 Bug ID: 118440 Summary: Wrong zero initialization with tuple usage Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: disservin.social at gmail dot com Target Milestone: --- Created attachment 60126 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60126&action=edit reproduction The following code zero initializes the members of the structure S which should instead be in an uninitialized state, since a user defined constructor is defined. clang does no such initialization. https://godbolt.org/z/zzxq6xnWx, compiled with: -O3 -Wall -Wextra Please let me know if there's maybe something I am missing here?
[Bug ipa/118400] [14/15 Regression] memory leak of irange at evaluate_properties_for_edge (ipa-fnsummary.cc:690)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118400 Richard Biener changed: What|Removed |Added Summary|memory leak of irange at|[14/15 Regression] memory |evaluate_properties_for_edg |leak of irange at |e (ipa-fnsummary.cc:690)|evaluate_properties_for_edg ||e (ipa-fnsummary.cc:690) Target Milestone|--- |14.3 Known to work||14.2.1, 15.0 Known to fail||13.3.1 Last reconfirmed||2025-01-12 Priority|P3 |P2 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- I'm a bit lost in the woods of range classes, not to say in the object lifetime of IPA stuff so leaving this to others. I do remember similar leaks during GCC 14 development, this particular leak also shows on the GCC 14 branch, same preprocessed source. The GCC 13 branch also has various irange leaks on the reduced testcase but not this specific one, so marking as regression.
[Bug target/113934] Switch avr to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113934 Bug 113934 depends on bug 117910, which changed state. Bug 117910 Summary: [avr][lra] Wrong code with -mlra in cmpdi-1.c https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117910 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug rtl-optimization/117910] [avr][lra] Wrong code with -mlra in cmpdi-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117910 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Georg-Johann Lay --- Dup *** This bug has been marked as a duplicate of bug 117868 ***
[Bug rtl-optimization/117868] [avr][lra] Wrong code with -mlra in simd-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117868 --- Comment #5 from Georg-Johann Lay --- *** Bug 117910 has been marked as a duplicate of this bug. ***
[Bug middle-end/118417] [15 Regression] Bootstrap comparison failure! gcc/range-op.o differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118417 --- Comment #2 from John David Anglin --- The ifcombine change fixed build.
[Bug middle-end/56183] [meta-bug][avr] Problems with register allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56183 Bug 56183 depends on bug 117910, which changed state. Bug 117910 Summary: [avr][lra] Wrong code with -mlra in cmpdi-1.c https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117910 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug tree-optimization/118409] [15 regression] gas miscompiled by ifcombine ("Unsupported broadcast" assemble failure)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118409 Sam James changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #21 from Sam James --- *** Bug 118417 has been marked as a duplicate of this bug. ***
[Bug middle-end/118417] [15 Regression] Bootstrap comparison failure! gcc/range-op.o differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118417 Sam James changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #3 from Sam James --- Thanks. *** This bug has been marked as a duplicate of bug 118409 ***
[Bug libstdc++/118434] New: std::visit should be updated to handle immediate functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118434
Bug ID: 118434
Summary: std::visit should be updated to handle immediate
functions
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: de34 at live dot cn
Target Milestone: ---
It seems that the following example should be valid since C++20 (patched by
P2564R3).
```
#include
consteval auto func(const std::variant& v1, const std::variant& v2) {
return std::visit([](auto x, auto y) consteval { return x + y; }, v1, v2);
}
static_assert(func(std::variant{42}, std::variant{1729}) == 1771);
```
But libstdc++ currently rejects it (https://godbolt.org/z/h59hWK9G3), because
the there's a hand-made vtable which will contain pointers to immediate
(immediate-escalated) functions while being constexpr.
I guess we can make the vtable a non-constexpr variable of automatic storage
duration when the vtable can't be constexpr. It seems that we can determine
this by testing that
`__some_alias_template<__gen_vtable_impl<...>::_S_apply>()>` is not a valid
type.
[Bug libstdc++/118434] std::visit should be updated to handle immediate functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118434 --- Comment #1 from Jiang An --- Corresponding libc++ issue: https://github.com/llvm/llvm-project/issues/118560
[Bug c++/118435] New: __builtin_va_arg does not check for POD type argument when it is passed by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118435
Bug ID: 118435
Summary: __builtin_va_arg does not check for POD type argument
when it is passed by value
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wangbopku15 at gmail dot com
Target Milestone: ---
Consider the following code:
$g++ -Wall -Wextra
#include
struct S {
private:
virtual void foo();
};
struct S arg;
void
foo (int z, ...)
{
va_list ap;
va_start (ap, z);
arg = va_arg (ap, struct S);
va_end (ap);
}
Clang rejects it and the diagnostic reveals that the argument of 'va_arg' must
be a POD type when it is passed by value:
:14:21: error: second argument to 'va_arg' is of non-POD type 'struct
S' [-Wnon-pod-varargs]
14 | arg = va_arg (ap, struct S);
| ^~~~
/opt/compiler-explorer/clang-trunk-20250112/lib/clang/20/include/__stdarg_va_arg.h:20:47:
note: expanded from macro 'va_arg'
20 | #define va_arg(ap, type) __builtin_va_arg(ap, type)
| ^~~~
1 error generated.
It seems that GCC does not have the corresponding restriction as the compiler
always accepts the code despite under options like '-Wall -Wextra':
https://godbolt.org/z/nKhMK54rW
[Bug target/118429] [15 regression] ICE when building poppler-24.11.0 on arm64 (in process_uses_of_deleted_def, at rtl-ssa/changes.cc:276)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118429 --- Comment #4 from Sam James --- Created attachment 60122 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60122&action=edit reduced.ii
[Bug tree-optimization/118409] [15 regression] gas miscompiled by ifcombine ("Unsupported broadcast" assemble failure) since r15-6774-g740c84975ceb74
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118409 Sam James changed: What|Removed |Added Severity|normal |blocker
[Bug d/118438] New: [15 Regression] libgphobos fails to build on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118438 Bug ID: 118438 Summary: [15 Regression] libgphobos fails to build on s390x-linux-gnu Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: doko at gcc dot gnu.org Target Milestone: --- seen with trunk 20250112 on s390x-linux-gnu. works with 20250101 trunk: /bin/bash ../libtool --tag=D --mode=compile /<>/build/./gcc/gdc -B/<>/build/./gcc/ -B/usr/s390x-linux-gnu/bin/ -B/usr/s390x-linux-gnu/lib/ -isystem /usr/s390x-linux-gnu/include -isystem /usr/s390x-linux-gnu/sys-include -isystem /<>/build/sys-include -fchecking=1 -prefer-pic -fversion=Shared -Wall -frelease -ffunction-sections -fdata-sections -O2 -g -fpreview=dip1000 -fpreview=dtorfields -fpreview=fieldwise -nostdinc -I ../../../../src/libphobos/src -I ../../../../src/libphobos/libdruntime -I ../libdruntime -I . -c -o std/package.lo ../../../../src/libphobos/src/std/package.d libtool: compile: /<>/build/./gcc/gdc -B/<>/build/./gcc/ -B/usr/s390x-linux-gnu/bin/ -B/usr/s390x-linux-gnu/lib/ -isystem /usr/s390x-linux-gnu/include -isystem /usr/s390x-linux-gnu/sys-include -isystem /<>/build/sys-include -fchecking=1 -fversion=Shared -Wall -frelease -ffunction-sections -fdata-sections -O2 -g -fpreview=dip1000 -fpreview=dtorfields -fpreview=fieldwise -nostdinc -I ../../../../src/libphobos/src -I ../../../../src/libphobos/libdruntime -I ../libdruntime -I . -c ../../../../src/libphobos/src/std/package.d -fPIC -fversion=Shared -o std/.libs/package.o /<>/src/libphobos/src/std/socket.d:2613:28: error: undefined identifier 'SO_REUSEPORT' 2613 | REUSEPORT =SO_REUSEPORT, |^ config.status: creating src/c++20/Makefile make[7]: *** [Makefile:1289: std/package.lo] Error 1
[Bug c++/118440] Wrong zero initialization with tuple usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118440 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- So the zeroing at -O1 and above come from a pass which "initializes" uninitialized registers. *** This bug has been marked as a duplicate of bug 61810 ***
[Bug target/61810] init-regs.c papers over issues elsewhere
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61810 Andrew Pinski changed: What|Removed |Added CC||disservin.social at gmail dot com --- Comment #11 from Andrew Pinski --- *** Bug 118440 has been marked as a duplicate of this bug. ***
[Bug c++/118435] __builtin_va_arg does not check for POD type argument when it is passed by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118435 --- Comment #1 from Andrew Pinski --- Non pod is a conditionally supported according to the standard.
[Bug c++/64867] split warning for passing non-POD to varargs function from -Wconditionally-supported into new warning flag, -Wnon-pod-varargs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867 Andrew Pinski changed: What|Removed |Added CC||wangbopku15 at gmail dot com --- Comment #33 from Andrew Pinski --- *** Bug 118435 has been marked as a duplicate of this bug. ***
[Bug c++/118435] __builtin_va_arg does not check for POD type argument when it is passed by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118435 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Read pr 64867 *** This bug has been marked as a duplicate of bug 64867 ***
[Bug tree-optimization/118409] [15 regression] gas miscompiled by ifcombine ("Unsupported broadcast" assemble failure) since r15-6774-g740c84975ceb74
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118409 --- Comment #23 from Hans-Peter Nilsson --- (In reply to Jeffrey A. Law from comment #18) > m32r, h8300 and iq2000 are all failing execute/20040709-?.c ...aaand MMIX joins the crowd with results at https://gcc.gnu.org/pipermail/gcc-testresults/2025-January/835093.html
[Bug middle-end/64242] Longjmp expansion incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64242
--- Comment #48 from GCC Commits ---
The master branch has been updated by Maciej W. Rozycki :
https://gcc.gnu.org/g:3cf0e6ab2aa9e7cb9a406079ff19856a6461d9f0
commit r15-6833-g3cf0e6ab2aa9e7cb9a406079ff19856a6461d9f0
Author: Maciej W. Rozycki
Date: Sun Jan 12 16:48:53 2025 +
Alpha: Restore frame pointer last in `builtin_longjmp' [PR64242]
Add similar arrangements to `builtin_longjmp' for Alpha as with commit
71b144289c1c ("re PR middle-end/64242 (Longjmp expansion incorrect)")
and commit 511ed59d0b04 ("Fix PR64242 - Longjmp expansion incorrect"),
so as to restore the frame pointer last, so that accesses to a local
buffer supplied can still be fulfilled with memory accesses via the
original frame pointer, fixing:
FAIL: gcc.c-torture/execute/pr64242.c -O0 execution test
FAIL: gcc.c-torture/execute/pr64242.c -O1 execution test
FAIL: gcc.c-torture/execute/pr64242.c -O2 execution test
FAIL: gcc.c-torture/execute/pr64242.c -O3 -g execution test
FAIL: gcc.c-torture/execute/pr64242.c -Os execution test
FAIL: gcc.c-torture/execute/pr64242.c -O2 -flto -fno-use-linker-plugin
-flto-partition=none execution test
FAIL: gcc.c-torture/execute/pr64242.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects execution test
and adding no regressions in `alpha-linux-gnu' testing.
gcc/
PR middle-end/64242
* config/alpha/alpha.md (`builtin_longjmp'): Restore frame
pointer last. Add frame clobber and schedule blockage.
[Bug tree-optimization/118436] Bogus ".. is used uninitialized" Warning in Tuple with Empty Constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118436
Andrew Pinski changed:
What|Removed |Added
Summary|Bogus ".. is used |Bogus ".. is used
|uninitialized" Warning in |uninitialized" Warning in
|Tuple with Empty|Tuple with Empty
|Constructor and |Constructor
|fsanitize=address |
Blocks||24639
--- Comment #1 from Andrew Pinski ---
I am not sure the warning is totally bogus.
This gives a warning about a being uninitialized:
```
#include
struct TTData {
int bound;
bool is_pv;
TTData() {};
};
std::tuple probe() {
TTData a;
return {a};
}
```
at `-O1 -W -Wall -fno-tree-sra`. Which is correct no fields of a are
initialized.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues
[Bug fortran/115788] [F2018] Implement OUT_OF_RANGE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115788 --- Comment #4 from GCC Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:f8eda60e12dabaf5e9501104781ef5eba334cff7 commit r15-6837-gf8eda60e12dabaf5e9501104781ef5eba334cff7 Author: Harald Anlauf Date: Sun Jan 12 19:26:35 2025 +0100 Fortran: implement F2018 intrinsic OUT_OF_RANGE [PR115788] Implementation of the Fortran 2018 standard intrinsic OUT_OF_RANGE, with the GNU Fortran extension to unsigned integers. Runtime code is fully inline expanded. PR fortran/115788 gcc/fortran/ChangeLog: * check.cc (gfc_check_out_of_range): Check arguments to intrinsic. * expr.cc (free_expr0): Fix a memleak with unsigned literals. * gfortran.h (enum gfc_isym_id): Define GFC_ISYM_OUT_OF_RANGE. * gfortran.texi: Add OUT_OF_RANGE to list of intrinsics supporting UNSIGNED. * intrinsic.cc (add_functions): Add Fortran prototype. Break some nearby lines with excessive length. * intrinsic.h (gfc_check_out_of_range): Add prototypes. * intrinsic.texi: Fortran documentation of OUT_OF_RANGE. * simplify.cc (gfc_simplify_out_of_range): Compile-time simplification of OUT_OF_RANGE. * trans-intrinsic.cc (gfc_conv_intrinsic_out_of_range): Generate inline expansion of runtime code for OUT_OF_RANGE. (gfc_conv_intrinsic_function): Use it. gcc/testsuite/ChangeLog: * gfortran.dg/ieee/out_of_range.f90: New test. * gfortran.dg/out_of_range_1.f90: New test. * gfortran.dg/out_of_range_2.f90: New test. * gfortran.dg/out_of_range_3.f90: New test.
[Bug c/118112] Unhelpful "too many arguments to function" error message (especially w/ C23)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118112
--- Comment #13 from GCC Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:a236f70617213343f3075ee43e8d9f5882dca400
commit r15-6838-ga236f70617213343f3075ee43e8d9f5882dca400
Author: David Malcolm
Date: Sun Jan 12 13:46:31 2025 -0500
c: UX improvements to 'too {few,many} arguments' errors (v5) [PR118112]
Consider this case of a bad call to a callback function (perhaps
due to C23 changing the meaning of () in function decls):
struct p {
int (*bar)();
};
void baz() {
struct p q;
q.bar(1);
}
Before this patch the C frontend emits:
t.c: In function 'baz':
t.c:7:5: error: too many arguments to function 'q.bar'
7 | q.bar(1);
| ^
which doesn't give the user much help in terms of knowing what
was expected, and where the relevant declaration is.
With this patch the C frontend emits:
t.c: In function 'baz':
t.c:7:5: error: too many arguments to function 'q.bar'; expected 0, have 1
7 | q.bar(1);
| ^ ~
t.c:2:15: note: declared here
2 | int (*bar)();
| ^~~
(showing the expected vs actual counts, the pertinent field decl, and
underlining the first extraneous argument at the callsite)
Similarly, the patch also updates the "too few arguments" case to also
show expected vs actual counts. Doing so requires a tweak to the
wording to say "at least" for the case of variadic fns where
previously the C FE emitted e.g.:
s.c: In function 'test':
s.c:5:3: error: too few arguments to function 'callee'
5 | callee ();
| ^~
s.c:1:6: note: declared here
1 | void callee (const char *, ...);
| ^~
with this patch it emits:
s.c: In function 'test':
s.c:5:3: error: too few arguments to function 'callee'; expected at least
1, have 0
5 | callee ();
| ^~
s.c:1:6: note: declared here
1 | void callee (const char *, ...);
| ^~
gcc/c/ChangeLog:
PR c/118112
* c-typeck.cc (inform_declaration): Add "function_expr" param and
use it for cases where we couldn't show the function decl to show
field decls for callbacks.
(build_function_call_vec): Add missing auto_diagnostic_group.
Update for new param of inform_declaration.
(convert_arguments): Likewise. For the "too many arguments" case
add the expected vs actual counts to the message, and if we have
it, add the location_t of the first surplus param as a secondary
location within the diagnostic. For the "too few arguments" case,
determine the minimum number of arguments required and add the
expected vs actual counts to the message, tweaking it to "at least"
for variadic functions.
gcc/testsuite/ChangeLog:
PR c/118112
* gcc.dg/too-few-arguments.c: New test.
* gcc.dg/too-many-arguments.c: New test.
Signed-off-by: David Malcolm
[Bug target/118429] [15 regression] ICE when building poppler-24.11.0 on arm64 (in process_uses_of_deleted_def, at rtl-ssa/changes.cc:276)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118429 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2025-01-12 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #7 from Andrew Pinski --- Confirmed.
https://orthodoxkorea.org/clergy_en/
https://www.lcms.org/partner-church-bodies/lutheran-church-in-korea https://www.methodist.org.uk/for-churches/global-relationships/partner-churches-and-organisations/global-partners/asia-pacific/korea/ https://www.localchurches.org/churches/ https://www.basel.int/countries/countrycontacts/tabid/1342/default.aspx Muan, Jeollanam-Do – Diakonia-Sisterhood in Korea http://www.aim-korea.org/churches.html https://www.scbaptist.org/wp-content/uploads/2021/11/Greenville-Association-Ethnic-Churches.pdf http://nac-korea.org/en/contact-us/ https://weekdaymasses.org.uk/en/area/south-korea/churches https://nolacatholic.org/hanmaum-korean-catholic-chapel https://nckpcusa.org/nckpcusa/files/pdf/newsletter/2020/03/2020%20Korean%20Directory.pdf https://kaiserswerther-generalkonferenz.org/en/members/16-muan-jeollanam-do-%E2-diakonia-sisterhood-in-korea Korean Catholic Chapel USA Clergy Directory World Clergy Directory https://ipc.church/churches/ https://www.localchurches.org/churches/chungju-chungcheongbukdo-south-korea/ https://korea.fas.harvard.edu/people https://arlyb.org.uk/community/society-of-the-holy-cross-shc/ https://www.cca.org.hk/content/presbyterian-church-republic-korea-prok https://www.neumc.org/files/fileslibrary/ClergyDirectorySep15.pdf
[Bug rtl-optimization/118444] [Meta bug] musttail bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118444 Andrew Pinski changed: What|Removed |Added Resolution|--- |MOVED Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Added tail-call keyword instead.
[Bug middle-end/65374] [SH] Tail call optimization not done for libcalls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65374 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 60919 ***
[Bug middle-end/60919] [arm] gcc fails to tail call __builtin_ffsll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60919 Andrew Pinski changed: What|Removed |Added CC||olegendo at gcc dot gnu.org --- Comment #4 from Andrew Pinski --- *** Bug 65374 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/91459] Tail-Call Optimization is not performed when return value is assumed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91459 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=118430 --- Comment #5 from Andrew Pinski --- Related to PR 118430 but not exactly since in this case the problem here is that the value can only be 1 in this one specific function and not known otherwise.
[Bug c++/118398] Resolving lambda expression decltype prioritized over the option to consider failed required concept using that type as argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118398 --- Comment #8 from mauro russo --- I see, it makes sense. However, I hope not to be too tedious to ask explicit references for the rules you stated: a) ignore requirements on parameters not used in the evaluation of a concept. b) ignore errors in non-immediate context during a clause if previous clauses already determined (in terms of boolean combination among constraints) the acceptance or rejection. I am unable to find both of them. In the current standard draft, I could find other topics we discussed: §7.5.8.1 [expr.prim.req.general] - p5: 1) "... can result in the formation of invalid types or expressions in the immediate context of its requirements ... In such cases, the requires-expression evaluates to false; it does not cause the program to be ill-formed." Indeed, this confirms your statement that, for the erros in a lambda, the 'savage' does not apply and the program is ill-formed. 2) "... The substitution and semantic constraint checking proceeds in lexical order and stops when a condition that determines the result of the requires-expression is encountered." This part is a kind of what I was looking for, about point b) above, but it applies only to multiple requirements inside a single requires expression, that is, not to multiple combined constraints. About multiple combined constraints, I cannot find evidences of (b) from sections as §13.5.3 [temp.constr.decl], §13.5.4 [temp.constr.normal], §13.5.5 [temp.constr.order] Similary, I cannot find evidences of (a) from sections as §13.3 [temp.names], where p9 reads: "A concept-id is a simple-template-id where the template-name is a concept-name. A concept-id is a prvalue of type bool, and does not name a template specialization. A concept-id evaluates to true if the concept’s normalized constraint-expression (13.5.3) is satisfied (13.5.2) by the specified template arguments and false otherwise."
[Bug tree-optimization/118409] [15 regression] gas miscompiled by ifcombine ("Unsupported broadcast" assemble failure) since r15-6774-g740c84975ceb74
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118409 --- Comment #25 from Alexandre Oliva --- Created attachment 60132 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60132&action=edit candidate patch Here's what I'm testing.
[Bug tree-optimization/118409] [15 regression] gas miscompiled by ifcombine ("Unsupported broadcast" assemble failure) since r15-6774-g740c84975ceb74
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118409 --- Comment #26 from Sam James --- Thanks Alexandre. I'll chuck it in over here as well.
[Bug target/118418] [15 Regression][gcn] Compiler selftest ICE in assert_rtx_eq_at, at selftest-rtl.cc:57 / FAIL: ASSERT_RTX_EQ (val, folded) since r15-6777-g06c4cf398947b5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118418 Richard Biener changed: What|Removed |Added Target Milestone|--- |15.0
[Bug lto/118181] gcc/lto-ltrans-cache.cc:312: Avoid call by value for large objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118181 --- Comment #1 from GCC Commits --- The master branch has been updated by Michal Jires : https://gcc.gnu.org/g:9100be5741329dfe7bd49d6cf60be1771b9bb3ea commit r15-6846-g9100be5741329dfe7bd49d6cf60be1771b9bb3ea Author: Michal Jires Date: Mon Jan 13 02:49:58 2025 +0100 lto: Pass cache checksum by reference [PR118181] Bootstrapped/regtested on x86_64-linux. Committed as obvious. PR lto/118181 gcc/ChangeLog: * lto-ltrans-cache.cc (ltrans_file_cache::create_item): Pass checksum by reference. * lto-ltrans-cache.h: Likewise.
[Bug tree-optimization/118405] [15 regression] RISC-V: ICE in verify_gimple during GIMPLE pass vect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118405 Richard Biener changed: What|Removed |Added Target Milestone|--- |15.0 Target||riscv32 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed||2025-01-13 --- Comment #2 from Richard Biener --- I will try to have a look, but never looked at rv32 - I hope rv64 can use -m32 here.
[Bug libstdc++/118408] regex does not work under dual ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118408 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Version|unknown |14.2.0 --- Comment #1 from Richard Biener --- Do you have a testcase that shows how it does "not work"? I assume it will work with the default selected ABI and only fails when users override that?
[Bug tree-optimization/115825] [12/13/14 Regression] Loop unrolling increases code size with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115825 --- Comment #17 from rguenther at suse dot de --- On Sat, 11 Jan 2025, segher at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115825 > > --- Comment #16 from Segher Boessenkool --- > Trivial stuff is no longer unrolled at all after this change. It does not > matter > *at all* whether an insn has a side effect or not, for whether code with such > an > insn should be unrolled or not. Any heuristic like that is totally broken, > totally > nonsensical. There's limits on how much code growth we allow and we estimate the final code size, reducing that by 1/3 "optimistically" (followup transforms might optimize), the fix was to make that reduction not apply to statements that obviously never are valid to optimize. If you now no longer get "trivial" stuff unrolled then you run into the size limit. The previous code, assessing that 1/3rd of all insns with side-effects are going to be optimized away indeed made no sense.
[Bug lto/118181] gcc/lto-ltrans-cache.cc:312: Avoid call by value for large objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118181 Michal Jireš changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Michal Jireš --- Fixed.
[Bug tree-optimization/98138] BB vect fail to SLP one case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98138 --- Comment #20 from rguenther at suse dot de --- On Mon, 13 Jan 2025, linkw at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98138 > > --- Comment #19 from Kewen Lin --- > (In reply to rguent...@suse.de from comment #18) > > I think this misses a :s on the negate_expr_p, but I'm not sure this > > "works", so eventually && single_use (@1), given the original expression > > doesn't go away. > > Thanks for the hints! I verified that :s isn't supported there, it seems > still > a good thing to make this matching if there are multiple uses but all are > under > the same form (rhs_code and operand index are the same) since the original > expression are able to be eliminated? Should we introduce a stricter check for > this like below? You are not allowed to look at immediate uses during folding, so no. But yes, this is basically the old issue that we have no folding pass that works "globally" when avoiding to create new semi-redundant sub-expressions. As you say, when we can create the same sub-expression for all uses we can CSE it again. So the current way to handle this is to give up conservatively. Basically we hope to catch all cases in the first forwprop pass, before FRE runs. On GENERIC there are no "CSE"d sub-expressions visible (OK, SAVE_EXPR, but we never handle that).
[Bug rtl-optimization/117611] [15 Regression] internal compiler error: in as_a, at machmode.h:381
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117611 Richard Biener changed: What|Removed |Added Target Milestone|--- |15.0
[Bug tree-optimization/117119] [12/13/14/15 Regression] ICE in int_cst_value, at tree.cc:11115 since r0-87460-g5b78fc3ed4960c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117119 Richard Biener changed: What|Removed |Added Last reconfirmed||2025-01-13 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Target Milestone|--- |12.5 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org
[Bug c/105612] [meta-bug] bogus/missing -Wtautological-compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105612 Sam James changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2025-01-13 Status|UNCONFIRMED |NEW --- Comment #1 from Sam James --- .
[Bug tree-optimization/98138] BB vect fail to SLP one case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98138
--- Comment #19 from Kewen Lin ---
(In reply to rguent...@suse.de from comment #18)
> I think this misses a :s on the negate_expr_p, but I'm not sure this
> "works", so eventually && single_use (@1), given the original expression
> doesn't go away.
Thanks for the hints! I verified that :s isn't supported there, it seems still
a good thing to make this matching if there are multiple uses but all are under
the same form (rhs_code and operand index are the same) since the original
expression are able to be eliminated? Should we introduce a stricter check for
this like below?
+static inline bool
+all_same_assign_form_uses (const_tree t)
+{
+ if (TREE_CODE (t) != SSA_NAME)
+return true;
+
+ /* Inline return has_zero_uses (t) || has_single_use (t); */
+ const ssa_use_operand_t *const head = &(SSA_NAME_IMM_USE_NODE (t));
+ const ssa_use_operand_t *ptr;
+ bool seen = false;
+ unsigned int op_index = 0;
+ tree_code rhs_code = ERROR_MARK;
+
+ for (ptr = head->next; ptr != head; ptr = ptr->next)
+{
+ gimple *use_stmt = USE_STMT (ptr);
+ if (use_stmt)
+{
+ if (is_gimple_debug (use_stmt))
+continue;
+ if (!is_gimple_assign (use_stmt))
+return false;
+ if (seen)
+{
+ if (gimple_assign_rhs_code (use_stmt) != rhs_code)
+return false;
+ if ((ptr->use - gimple_ops (use_stmt)) != op_index)
+return false;
+}
+ else
+{
+ seen = true;
+ rhs_code = gimple_assign_rhs_code (use_stmt);
+ op_index = ptr->use - gimple_ops (use_stmt);
+}
+}
+}
+ return true;
+}
[Bug ipa/90151] [12/13/14/15 regression] 554.roms_r regression on x86_64 at -O2 and generic march/mtune since r8-4715-g35cd23ebb6d05e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90151 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.5
[Bug middle-end/118012] [avr][13/14/15 Regression] Expensive code (bit extract + extend + neg + and) instead of bit test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118012 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.4
[Bug target/80813] [12/13/14/15 Regression] x86: std::vector::operator[] could be somewhat faster using BT instead of SHL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80813 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.5
[Bug rtl-optimization/110393] [13 regression] ICE at -O3 with "-fselective-scheduling2 -fPIC": in move_op_ascend, at sel-sched.cc:6150
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110393 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.4
[Bug c++/106057] [12 Regression] Missed stmt_can_throw_external check in stmt_kills_ref_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106057 Richard Biener changed: What|Removed |Added Summary|[12/13/14/15 regression]|[12 Regression] Missed |Missed |stmt_can_throw_external |stmt_can_throw_external |check in stmt_kills_ref_p |check in stmt_kills_ref_p | Target Milestone|--- |12.5 --- Comment #9 from Richard Biener --- r13-1241-g7fd34782b95bbe1b4dc9936b8923f86d4aaee379 seems to be missing from 12 though.
[Bug tree-optimization/108629] [13/14/15 regression] 549.fotonik3d_r regresses 15-24% at -O2 -flto -march=x86-64-v3 since r13-1203-g038b077689bb53
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108629 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.4 Keywords||missed-optimization
[Bug libstdc++/116440] [14/15 Regression] [C++20] std::tuple> does not compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116440 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.3
[Bug debug/107110] [12 regression] failure (length) with -fcompare-debug at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107110 Richard Biener changed: What|Removed |Added Version|unknown |12.1.0 Target Milestone|--- |12.5
[Bug target/106438] [13/14/15 regression] powerpc: ICE when building libgfortran with -flto: in insert_value_copy_on_edge, at tree-outof-ssa.cc:334 since r13-1324-g133d0d422ebd18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106438 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.4
[Bug tree-optimization/118107] [14 Regression] false warning: "${inactive union member} may be used uninitialized" with -fsanitize=undefined -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118107 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.3
[Bug fortran/115788] [F2018] Implement OUT_OF_RANGE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115788 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |15.0
[Bug tree-optimization/118442] New: -fprofile-generate wrongly adds instrumentation after musttail call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118442 Bug ID: 118442 Summary: -fprofile-generate wrongly adds instrumentation after musttail call Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: kenjin4096 at gmail dot com Target Milestone: --- Please see: https://godbolt.org/z/5sfcxqhdb Removing `-fprofile-generate` causes GCC 15 to compile successfully. With `-fprofile-generate` compilation fails. If my understanding is correct (and thanks to Andrew), instrumentation is being added after the tail call, which triggers the tail call compilation error message. [local count: 1073741824]: # DEBUG BEGIN_STMT buffer_2(D)->test[0] = 4; # DEBUG BEGIN_STMT resolveToBufferSlow (buffer_2(D)); [must tail call] PROF_edge_counter_7 = __gcov0._Z15resolveToBufferP4Span[1]; PROF_edge_counter_8 = PROF_edge_counter_7 + 1; __gcov0._Z15resolveToBufferP4Span[1] = PROF_edge_counter_8; Thank you.
[Bug gcov-profile/118442] -fprofile-generate wrongly adds instrumentation after musttail call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118442 --- Comment #1 from Andrew Pinski --- Created attachment 60131 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60131&action=edit testcase
[Bug target/111949] combine split points are not so good with targets that have (and (not x) y)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111949 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #2 from Andrew Pinski --- Mine for GCC 16. I am going to work on this.
[Bug target/106240] [13/14/15 Regression] missed vectorization opportunity (cond move) on mips since r13-707-g68e0063397ba82
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106240 Jeffrey A. Law changed: What|Removed |Added Priority|P2 |P4
[Bug target/118429] [15 regression] ICE when building poppler-24.11.0 on arm64 (in process_uses_of_deleted_def, at rtl-ssa/changes.cc:276)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118429 Andrew Pinski changed: What|Removed |Added Attachment #60127|0 |1 is obsolete|| --- Comment #8 from Andrew Pinski --- Created attachment 60128 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60128&action=edit Slightly more reduced without pointers Note f needs that many arguments to hit the bug.
[Bug target/118429] [15 regression] ICE when building poppler-24.11.0 on arm64 (in process_uses_of_deleted_def, at rtl-ssa/changes.cc:276)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118429 Andrew Pinski changed: What|Removed |Added Attachment #60128|0 |1 is obsolete|| --- Comment #9 from Andrew Pinski --- Created attachment 60129 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60129&action=edit Slight more reduced
[Bug fortran/71884] ICE in gfc_trans_allocate, at fortran/trans-stmt.c:5582 and :5698
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71884 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code --- Comment #5 from anlauf at gcc dot gnu.org --- (In reply to Jerry DeLisle from comment #4) > (In reply to kargls from comment #3) > > (In reply to Gerhard Steinmetz from comment #1) > --- snip --- > > > > This now gives > > > > % gfcx -c pr71884.f90 > > pr71884.f90:4:25-31: > > > > 4 |allocate (character(*) :: z) > > | 2 1 > > I am still getting the ICE here. Steve, do you have a patch in there? Jerry, I am getting the following since gcc-8: pr71884-za.f90:3:25-30: allocate (character(*) :: z) 21 Error: Incompatible allocate-object at (1) for CHARACTER type-spec at (2) But all other variations, like in comment#0, ICE here.
[Bug c++/118392] "-w" fails to fully inhibit "'void a::b()' has not been declared within a" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118392 --- Comment #5 from Simon Martin --- Patch submitted in https://gcc.gnu.org/pipermail/gcc-patches/2025-January/673394.html
[Bug fortran/71884] ICE in gfc_trans_allocate, at fortran/trans-stmt.c:5582 and :5698
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71884
--- Comment #6 from kargls at comcast dot net ---
(In reply to Jerry DeLisle from comment #4)
> (In reply to kargls from comment #3)
> > (In reply to Gerhard Steinmetz from comment #1)
> --- snip ---
> >
> > This now gives
> >
> > % gfcx -c pr71884.f90
> > pr71884.f90:4:25-31:
> >
> > 4 |allocate (character(*) :: z)
> > | 2 1
>
> I am still getting the ICE here. Steve, do you have a patch in there?
No patches. But, I do override GCC default build options and use
"-g -O" for all stages. I also have
% valgrind --leak-check=full -s ${PATH}/f951 a.f90
...
==10873==
==10873== HEAP SUMMARY:
==10873== in use at exit: 543,236 bytes in 2,904 blocks
==10873== total heap usage: 4,568 allocs, 1,664 frees, 1,667,111 bytes
allocated
==10873==
==10873== LEAK SUMMARY:
==10873==definitely lost: 0 bytes in 0 blocks
==10873==indirectly lost: 0 bytes in 0 blocks
==10873== possibly lost: 0 bytes in 0 blocks
==10873==still reachable: 541,508 bytes in 2,902 blocks
==10873== suppressed: 1,728 bytes in 2 blocks
==10873== Reachable blocks (those to which a pointer was found) are not shown.
==10873== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==10873==
==10873== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
--10873--
--10873-- used_suppression: 2 MEMCHECK-LIBTHR-REACHABLE-1
/usr/local/libexec/valgrind/default.supp:665 suppressed: 1,728 bytes in 2
blocks
==10873==
==10873== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
This is on FreeBSD, which does not use glibc. So, perhaps, an issue with
something coming out of libc (e.g., malloc).
Note, this bug report conflates issues with source-expr (i.e., those in
comment #0) and an invalid character type-spec (i.e., code in coment #1).
The patch in
https://gcc.gnu.org/pipermail/fortran/2025-January/061559.html
fixes the former. The latter seems to be fixed.
