[Bug target/115248] [15 regresion] aarch64/sve/pre_cond_share_1.c fails since r15-276-gbed6ec161be8c5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115248
--- Comment #4 from GCC Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:a68e32b8e4b4c03c81e3a4b7560d52fef2d16088
commit r15-8024-ga68e32b8e4b4c03c81e3a4b7560d52fef2d16088
Author: Richard Sandiford
Date: Thu Mar 13 12:03:04 2025 +
testsuite: Remove sve/pre_cond_share_1.c [PR115248]
gcc.target/aarch64/sve/pre_cond_share_1.c started failing after
r15-276-gbed6ec161be8c5ca. However, that was incidental.
The test's inner loop is duplicated by -fswitch-loops and
that patch happened to change the copy of the loop that was
not the original focus of the test.
The test was added as part of r14-4713-g4b39aeef594f311e (patch A).
Before patch A we had:
mask__109.48_201 = vect_distbb_170.43_191 < vect_cst__200;
_263 = .COND_MUL (mask__109.48_201, vect_iftmp.45_195, vect_cst__198, {
0.0, ... });
vect_prephitmp_153.50_205 = .VCOND (vect_distbb_170.43_191, { 0.0, ... },
_263, vect_cst__198, 112);
which, expanding the .VCOND, is equivalent to:
mask__102.46_197 = vect_distbb_170.43_191 >= { 0.0, ... };
mask__109.48_201 = vect_distbb_170.43_191 < vect_cst__200;
_263 = .COND_MUL (mask__109.48_201, vect_iftmp.45_195, vect_cst__198, {
0.0, ... });
vect_prephitmp_153.50_205 = mask__102.46_197 ? _263 : vect_cst__198
After patch A we had:
mask__102.46_197 = vect_distbb_170.43_191 >= { 0.0, ... };
mask__109.48_201 = vect_distbb_170.43_191 < vect_cst__200;
_70 = mask__102.46_197 & mask__109.48_201;
vect_prephitmp_153.50_205 = .COND_MUL (_70, vect_iftmp.45_195,
vect_cst__198, { 0.0, ... });
But this changes the behaviour when vect_distbb_170.43_191 < { 0.0, ... }.
In that case, the original code would pick an else value of vect_cst__198,
whereas the new code would pick an else value of { 0.0, ... }.
That was fixed in r14-8668-g8123f3ca3fd89103 (PR113607, patch B),
but fixing the bug (rightly) reverted the code to the previous output.
Patch B therefore XFAILed the thing that patch A was originally testing.
Since the test was added for patch A and since patch A seems to generate
incorrect code for the test, I think we should just remove it.
gcc/testsuite/
PR testsuite/115248
* gcc.target/aarch64/sve/pre_cond_share_1.c: Delete
[Bug cobol/119211] [15 Regression] Cobol GCC 15 release checklist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119211 Bug 119211 depends on bug 119257, which changed state. Bug 119257 Summary: Version of GCC COBOL on Compiler Explorer https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119257 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED
[Bug target/117092] [15/16 regression] gcc.target/aarch64/pr109072_1.c check-function-bodies s16x4_2 fail since r15-4235-gbcccc3221b838e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117092 Andrew Pinski changed: What|Removed |Added Keywords||deferred, xfail Summary|[15 regression] |[15/16 regression] |gcc.target/aarch64/pr109072 |gcc.target/aarch64/pr109072 |_1.c check-function-bodies |_1.c check-function-bodies |s16x4_2 fail since |s16x4_2 fail since |r15-4235-gb3221b838e|r15-4235-gb3221b838e Target Milestone|15.0|16.0
[Bug libstdc++/108053] std::visit_format_arg should hide __int128 and other extensions behind a handle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108053 Tomasz Kamiński changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Tomasz Kamiński --- Fixed in v15.
[Bug c++/119260] reinterpret_cast function pointer to integer and applying and incorrectly calculated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119260
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2025-03-13
Status|UNCONFIRMED |NEW
Known to fail||7.5.0
--- Comment #4 from Richard Biener ---
bool
get_object_alignment_2 (tree exp, unsigned int *alignp,
unsigned HOST_WIDE_INT *bitposp, bool addr_p)
{
unsigned int align = BITS_PER_UNIT;
...
/* Extract alignment information from the innermost object and
possibly adjust bitpos and offset. */
if (TREE_CODE (exp) == FUNCTION_DECL)
{
/* Function addresses can encode extra information besides their
alignment. However, if TARGET_PTRMEMFUNC_VBIT_LOCATION
allows the low bit to be used as a virtual bit, we know
that the address itself must be at least 2-byte aligned. */
if (TARGET_PTRMEMFUNC_VBIT_LOCATION == ptrmemfunc_vbit_in_pfn)
align = 2 * BITS_PER_UNIT;
}
we don't compute anything for functions, but the above can cause the
expression to "diverge" for the integer cast value, like if you want
to test that virtual bit.
Only x86 has it this way.
[Bug target/119267] RISC-V: gcc generates vsetivli with wrong LMUL with extended assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119267 --- Comment #2 from Matteo Perotti --- (In reply to Andrew Pinski from comment #1) > You can't use vsetivli this way. That is you can't set it via inline-asm. > > MAybe this should be documented. 1) Do you mean that it's not allowed to use vsetvl-like instructions in the inline assembly in general? Or am I just doing it the wrong way? 2) If it's not allowed, does it mean that the only way I can write RVV assembly is by writing a separate assembly file? 3) If this is the case, isn't there a way to target -march=rv64gcv without allowing the compiler to insert new RVV instructions other than the ones in inline assembly? This "hack" would allow easier porting of legacy code since older gcc versions did not insert any "alien" RVV instruction in addition to the ones already present as inline-asm. I agree though; documenting this would be great. Thanks a lot for the answer btw.
[Bug c/116545] Support old style statement attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116545 --- Comment #9 from Sam James --- (In reply to lucier from comment #8) patch -p0 < x.patch (or git apply -p0)
[Bug jit/119268] New: Exception thrown when host_detect_local_cpu returns NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119268 Bug ID: 119268 Summary: Exception thrown when host_detect_local_cpu returns NULL Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: antoyo at gcc dot gnu.org CC: antoyo at gcc dot gnu.org Target Milestone: --- host_detect_local_cpu is called in gcc/config/i386/i386-jit.cc and the result is sent directly to a std::string, so if the result is NULL, this will throw an exception. Since this code is automatically ran at startup, I suspect the priority to fix it should be higher. What do you think? Hopefully, the fix should be easy.
[Bug fortran/119272] New: Function misidentified as non-function in associate statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119272 Bug ID: 119272 Summary: Function misidentified as non-function in associate statement Product: gcc Version: 14.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: xingjingwei666 at gmail dot com Target Milestone: --- Test case: module test_module type, public :: test_type contains procedure :: test_function end type test_type contains function test_function(this) result(smth) class(test_type) :: this integer :: smth smth = 1 end function end module program test use test_module implicit none contains subroutine test_subroutine(a) class(test_type) :: a integer :: temp_int(3) associate(temp => temp_int(a%test_function())) ! 'test_function' at (1) should be a FUNCTION end associate end subroutine end program When compiling the code without flag, compiler incorrectly reports that the type-bounded procedure "test_function" is not a function, and gives the following error message: test.f90:22:39: 22 | associate(temp => temp_int(a%test_function())) | 1 Error: 'test_function' at (1) should be a FUNCTION If use "type(test_type)" instead of "class(test_type)" in the declaration of "test_subroutine", gfortran will compile successfully. If associate "a%test_function()" directly instead of indexing, it will also compile successfully. It occurs on gfortran 14.2.0 and 13.3.0, but not on 12.4.0. My platform is MacBook Pro(M4 pro). But I also test on WSL2(core i7 11700, Ubuntu 24.04.1) and result is the same. gfortran -v gives: Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/opt/homebrew/Cellar/gcc/14.2.0_1/bin/../libexec/gcc/aarch64-apple-darwin24/14/lto-wrapper Target: aarch64-apple-darwin24 Configured with: ../configure --prefix=/opt/homebrew/opt/gcc --libdir=/opt/homebrew/opt/gcc/lib/gcc/current --disable-nls --enable-checking=release --with-gcc-major-version-only --enable-languages=c,c++,objc,obj-c++,fortran,m2 --program-suffix=-14 --with-gmp=/opt/homebrew/opt/gmp --with-mpfr=/opt/homebrew/opt/mpfr --with-mpc=/opt/homebrew/opt/libmpc --with-isl=/opt/homebrew/opt/isl --with-zstd=/opt/homebrew/opt/zstd --with-pkgversion='Homebrew GCC 14.2.0_1' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues --with-system-zlib --build=aarch64-apple-darwin24 --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.2.0 (Homebrew GCC 14.2.0_1)
[Bug testsuite/113965] gcc.target/aarch64/sve/mask_struct_load_3_run.c still fails with qemu due to _Float16 rounding error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113965 Richard Sandiford changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Richard Sandiford --- Fixed.
[Bug libstdc++/119135] Typo in as_const range adaptor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119135 --- Comment #1 from GCC Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:50359c0a44381edb6dbd9359ef2ebdadbcc3ed42 commit r15-8030-g50359c0a44381edb6dbd9359ef2ebdadbcc3ed42 Author: Patrick Palka Date: Thu Mar 13 09:15:21 2025 -0400 libstdc++: Fix ref_view branch of views::as_const [PR119135] Unlike for span and empty_view, the range_reference_t of ref_view doesn't correspond to X. This patch fixes the ref_view branch of views::as_const to correctly query its underlying range type X. PR libstdc++/119135 libstdc++-v3/ChangeLog: * include/std/ranges: Include . (views::__detail::__is_ref_view): Replace with ... (views::__detail::__is_constable_ref_view): ... this. (views::_AsConst::operator()): Replace bogus use of element_type in the ref_view branch. * testsuite/std/ranges/adaptors/as_const/1.cc (test03): Extend test. Reviewed-by: Tomasz KamiÅski Reviewed-by: Jonathan Wakely
[Bug c/116545] Support old style statement attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116545 --- Comment #8 from lucier at math dot purdue.edu --- (In reply to Jakub Jelinek from comment #7) > Created attachment 60738 [details] > gcc15-pr116545.patch > > Full untested patch. I don't know how to apply this patch to the git checked-out sources in order to test it, sorry.
[Bug testsuite/113965] gcc.target/aarch64/sve/mask_struct_load_3_run.c still fails with qemu due to _Float16 rounding error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113965 Richard Sandiford changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org CC||rsandifo at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2025-03-13 --- Comment #4 from Richard Sandiford --- Mine. I'm also seeing this on native h/w.
[Bug target/119267] RISC-V: gcc generates vsetivli with wrong LMUL with extended assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119267 Andrew Pinski changed: What|Removed |Added Keywords||documentation, inline-asm Target||riscv --- Comment #1 from Andrew Pinski --- You can't use vsetivli this way. That is you can't set it via inline-asm. MAybe this should be documented.
[Bug target/117092] [15 regression] gcc.target/aarch64/pr109072_1.c check-function-bodies s16x4_2 fail since r15-4235-gbcccc3221b838e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117092 --- Comment #6 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:e5d54c33a257b3f7137f8408592df009dffb5711 commit r15-8029-ge5d54c33a257b3f7137f8408592df009dffb5711 Author: Andrew Pinski Date: Wed Mar 12 17:04:47 2025 -0700 aarch64: xfail pr109072_1.c's s16x4_2 [PR117092] The fix for this depends on much more infrastructure which won't be done for another few weeks. Pengxuan is working on the fix for GCC 16. So let's xfail the testcase since it is a minor code quality regression. we get: ``` moviv0.2s, 0 ins v0.h[0], w0 ``` vs what we should get: ``` and x0, x0, 65535 fmovd0, x0 ``` or ``` fmovh0, x0 ``` Tested for aarch64-linux-gnu. PR target/117092 gcc/testsuite/ChangeLog: * gcc.target/aarch64/pr109072_1.c: xfail s16x4_2. Signed-off-by: Andrew Pinski
[Bug c/119263] ICE: gimplify_expr (gimplify.cc:20209) triggered by __builtin_assoc_barrier with volatile struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119263 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- This should have been rejected in similar way as PR 118869 so a dup. *** This bug has been marked as a duplicate of bug 118869 ***
[Bug other/42270] manual's sections are ordered counter intuitively
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42270 --- Comment #2 from sandra at gcc dot gnu.org --- I've picked up this issue again (after almost 10 years!) because it continues to annoy me how hard it is to find information in this chapter unless you already know what to search for. A problem I've run into with adding sections for grouping is that Texinfo provides a fixed set of sectioning commands with the deepest being @subsubsection. And, we already have dozens of @subsubsections in the various target-specific attribute and builtin sections, so adding another level in the obvious way seems impossible. I could change the existing @subsubsections to @subsubheading, but that would remove them from the table of contents. For now I'll work around that problem by focusing on moving other sections around and leaving those things alone for now -- any incremental improvements to this chapter would be worthwhile even if they're not perfect, IMO.
[Bug libstdc++/111055] [C++23] Implement P1206R7, Conversions from ranges to containers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055 --- Comment #10 from GCC Commits --- The master branch has been updated by Tomasz Kaminski : https://gcc.gnu.org/g:20828a812822f3009c3fe8a15d3db9160819b7de commit r15-8039-g20828a812822f3009c3fe8a15d3db9160819b7de Author: Jonathan Wakely Date: Tue Oct 8 21:15:18 2024 +0100 libstdc++: Add P1206R7 from_range members to container adaptors [PR111055] This is another piece of P1206R7, adding new members to std::stack, std::queue, and std::priority_queue. PR libstdc++/111055 libstdc++-v3/ChangeLog: * include/bits/stl_queue.h (queue(from_range_t, _Rg&&)) (queue(from_range_t, _Rg&&, const _Alloc&), push_range): Define. (priority_queue(from_range_t, R&&, const Compare&)) (push_range): Define. * include/bits/stl_stack.h (stack(from_range_t, R&&)) (stack(from_range_t, R&&, const Alloc&), push_range): Define. * testsuite/util/testsuite_iterators.h (test_range_nocopy): Define. * testsuite/23_containers/priority_queue/cons_from_range.cc: New test. * testsuite/23_containers/priority_queue/members/push_range.cc: New test. * testsuite/23_containers/queue/cons_from_range.cc: New test. * testsuite/23_containers/queue/members/push_range.cc: New test. * testsuite/23_containers/stack/cons_from_range.cc: New test. * testsuite/23_containers/stack/members/push_range.cc: New test. Co-authored-by: Tomasz KamiÅski Signed-off-by: Tomasz KamiÅski
[Bug target/119270] New: [15 Regression] 5% slowdown of 507.cactuBSSN_r on Intel Ice Lake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119270 Bug ID: 119270 Summary: [15 Regression] 5% slowdown of 507.cactuBSSN_r on Intel Ice Lake Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: pheeck at gcc dot gnu.org Blocks: 26163 Target Milestone: --- Host: x86_64-linux Target: x86_64-linux As seen here https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=800.437.0 there was a 5% exec time slowdown of the 507.cactuBSSN_r SPEC 2017 benchmark between commits r15-7920-g62a6a53766ba46 r15-7936-gc6b277f1dc6d11 when run with -O2 -march=generic -flto on an Intel Ice Lake (3rd generation Xeon) machine. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug target/119270] [15 Regression] 5% slowdown of 507.cactuBSSN_r on Intel Ice Lake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119270 Filip Kastl changed: What|Removed |Added Target Milestone|--- |15.0
[Bug rtl-optimization/117645] [15 Regression] FAIL: gcc.dg/graphite/pr29581-2.c execution test with late-combine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117645 --- Comment #9 from John David Anglin --- (In reply to Andrew Pinski from comment #8) >> > The current implementation of addti3 on hppa only allows register > > operands. The problem is avoided if we improve addti3 to support > > the addition of small integers. The code needed to do this is > > similar to that used for adddi3 on 32-bit targets. Have a patch > > which I will install soon. > > I assume this works around the issue right? And reverting the backend patch > will expose the issue again, right? I might take a few minutes to debug > where inside LRA, the clobber is coming from. The patch was this commit: commit 22b13b1d4e3dce6bbc8792ffa08cefeb5e125a03 Author: John David Anglin Date: Mon Nov 25 16:40:29 2024 -0500 hppa: Revise TImode aritmetic patterns to support arith11_operands
[Bug jit/119268] Exception thrown when host_detect_local_cpu returns NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119268 --- Comment #4 from Antoni --- Oh sorry. I thought this was merged. I guess we can close this issue then.
[Bug c++/119259] compilation error: *constexpr* operator==(const T&) const = default` forces compilation of std::vector's operator== function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119259 --- Comment #11 from Patrick Palka --- I recommend your workaround of removing the 'constexpr' specifier when defaulting a function. A defaulted function is already implicitly constexpr if its definition qualifies, regardless of whether it's explicitly declared as 'constexpr'.
[Bug c++/94061] defaulted member operator <=> defined as deleted if a base has protected member operator <=>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94061
--- Comment #10 from Patrick Palka ---
Hmm, I'm not sure CWG 2568 makes this example well-formed? We already do
access checks in the context of the synthesized definition, the problem is that
the synthesized definition (as per comment #2) looks like
auto operator <=> (const B& b) const {
return static_cast(*this) <=> static_cast(b);
}
which is using A's operator<=> through an object of type A, not through an
object of type B, so the protected access don't apply. IIUC we'd need to
change the synthesis rules when considering a base subobject in order for the
synthesis to be valid.
The example in the CWG issue is also rejected if we go on to use the
synthesized ==, so the P/R seems mainly editorial?
[Bug tree-optimization/119253] RISC-V GCC auto-vectorizes unaligned memory access even if mvector-strict-align is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119253 Andrew Pinski changed: What|Removed |Added Resolution|FIXED |INVALID --- Comment #3 from Andrew Pinski --- Or you could use the runtime sanitizers which will find the issue even on x86.
[Bug target/115248] [15 regresion] aarch64/sve/pre_cond_share_1.c fails since r15-276-gbed6ec161be8c5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115248 Richard Sandiford changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Sandiford --- Fixed.
[Bug c/119264] [14/15 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in tree_nonzero_bits, at fold-const.cc:16688
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119264 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug cobol/119242] cobol Front end requires __int128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119242 --- Comment #3 from Jakub Jelinek --- Created attachment 60740 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60740&action=edit gcc15-pr119242-wip.patch So I've played briefly with this PR and tried to convert the __int128 uses in the COBOL FE to FIXED_WIDE_INT(128), i.e. wide_int variant which is exactly 128-bit. This doesn't completely compile mainly because of binary_initial_from_float128/digits_from_float128/initial_from_float128 functions, so I don't really see how this PR can be fixed without also addressing PR119241 at the same time. I'm sure my formatting is off, in some cases I just didn't understand what the formatting rules are in the FE. What the FE does currently is definitely wrong even if it was ok to use __int128 in the FE (which it is not), all the build_int_cst_type calls with __int128 argument just lose the upper 64-bits of the value, built_int_cst_type's argument is HOST_WIDE_INT (i.e. signed 64-bit integer) or poly_int from that. So, as can be seen in the patch, one needs to use wide_int_to_tree instead and use a wide_int as argument. The unsigned char *pvalue = (unsigned char *)&value; ... if( *(uint64_t*)(pvalue + 8) ) etc. stuff is host endianity dependent, will work on little endian hosts only. Even if COBOL support is restricted to little endian targets only, one can still use big endian hosts to cross-compile it (or should be able). I really don't understand the /* GCC-13 has no provision for an int128 constructor. So, we use a union for our necessary __int128. hunk. GCC of course handles 128-bit INTEGER_CST initalizers just fine, at least provided build_int_cst_type isn't used which throws away all the upper bits. What the code did was again host endianity dependent. I don't see what during parsing of integral literals would verify they aren't too large to fit into signed (or unsigned if COBOL has such types?) 128-bit type and complain otherwise. The uses of atoi/atol in binary_initial_from_float128 look problematic to me as well, atoi will accept random garbage after the digits and doesn't properly signalize errors. Better use strtol/strtoll. We've tried hard recently to get rid of atoi etc. calls in the compiler. Another thing is are the *(signed int *)retval = atoi(ach); etc. stores done with those, that seems that retval is malloced host memory one stores some host dependent endianity data in and I haven't searched how they are used later, if they are emitted as blob into binaries which can have different endianity from the host. Also, the assumption that host long is 64-bit is just wrong (I've changed that temporarily to long long and atoll). The normal GCC way would be return tree with INTEGER_CST or REAL_CST or something similar, something that can be handled later by the middle-end.
[Bug c++/119255] [15 Regression] Seg fault after errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119255 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug libgdiagnostics/119271] New: libgdiagnostics docs are missing build/installation instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119271 Bug ID: 119271 Summary: libgdiagnostics docs are missing build/installation instructions Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgdiagnostics Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Target Milestone: --- Quoting an email: > The part that should be included in the docs and is currently totally > missing: How do a user and a developer get libdiagnostics in the > first place? Filing this bug as a reminder to add this somewhere.
[Bug testsuite/113965] gcc.target/aarch64/sve/mask_struct_load_3_run.c still fails with qemu due to _Float16 rounding error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113965 --- Comment #5 from GCC Commits --- The trunk branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:df87b300bd13ed047b1159022c93445f130458e6 commit r15-8037-gdf87b300bd13ed047b1159022c93445f130458e6 Author: Richard Sandiford Date: Thu Mar 13 15:13:00 2025 + testsuite: Fix sve/mask_struct_load_3_run.c [PR113965] Among other things, this testcase tests an addition of the four values (n*4+[0:3])*9//2 for each n in [0:99]. The addition is done in multiple integer and floating-point types and the test is compiled with -ffast-math. One of the floating-point types is _Float16, and as Andrew says in the PR, _Float16's limited precision means that the order of the additions begins to matter for higher n. Specifically, some orders begin to give different results from others at n=38, and at many higher n as well. This patch uses 5/3 rather than 9/2. I tested locally that all addition orders give the same result over the test range. gcc/testsuite/ PR testsuite/113965 * gcc.target/aarch64/sve/mask_struct_load_3_run.c: Use an input range that is suitable for _Float16.
[Bug target/119269] [15 Regression] 6-22% slowdown of 433.milc on Aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119269 Filip Kastl changed: What|Removed |Added Last reconfirmed||2025-03-13 Ever confirmed|0 |1 Status|UNCONFIRMED |SUSPENDED --- Comment #1 from Filip Kastl --- I looked at this in more detail. Actually, only some of the slowdowns I listed look like regressions. Here they are (with a comparison to GCC 14): https://lnt.opensuse.org/db_default/v4/SPEC/graph?&plot.8=1069.70.0&plot.9=577.70.0&; https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.8=1042.70.0&plot.9=580.70.0&; https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.8=1066.70.0&plot.9=578.70.0 Sorry, I was a bit too hasty. Also, I am not even sure if these graphs show a recent regression. Notice the orange vertical lines in the graph. Those represent that we updated the system of the benchmarking machine at that time. They unfortunately coincide with r15-6661-gc5db3f50bdf34e (the commit r15-7871-gf870302515d5fc is fixing). This means that the graph is hard to read. There definitely is a regression of 433.milc between GCC 14 and GCC 15. However, I now don't feel confident saying that it must be between r15-7846-gda8aaa7784810e r15-7877-g888e70b3226225 I'll suspend this bug for now and think about this some more.
[Bug libstdc++/119266] libstdc++.modules.json has wrong path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119266 --- Comment #9 from Sam James --- (In reply to Jason Merrill from comment #7) > (In reply to Sam James from comment #0) > > $ A=/usr/lib/gcc/x86_64-pc-linux-gnu/15/ > > $ > > B=/usr/lib/gcc/x86_64-pc-linux-gnu/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15/bits/std.cc > > $ contrib/relpath.sh $A $B > > ../lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15/bits/std.cc > > That looks right to me given those A and B. > Or, rather, I get your point now (and what I was trying to make and got confused by): yes, this is how that path ends up in the JSON file, but clearly the B is wrong.
[Bug c/116545] Support old style statement attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116545 --- Comment #11 from lucier at math dot purdue.edu --- Created attachment 60745 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60745&action=edit Test summary
[Bug libstdc++/116440] [14/15 Regression] [C++20] std::tuple> does not compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116440 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug rtl-optimization/119276] New: ICE: in cfg_layout_redirect_edge_and_branch_force, at cfgrtl.cc:4747 with -O2 -fmodulo-sched -freorder-blocks-and-partition -fharden-conditional-branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119276 Bug ID: 119276 Summary: ICE: in cfg_layout_redirect_edge_and_branch_force, at cfgrtl.cc:4747 with -O2 -fmodulo-sched -freorder-blocks-and-partition -fharden-conditional-branches Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization 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 60746 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60746&action=edit reduced testcase Compiler output: $ riscv64-unknown-linux-gnu-gcc -O2 -fmodulo-sched -freorder-blocks-and-partition -fharden-conditional-branches testcase.c during RTL pass: sms testcase.c: In function 'foo': testcase.c:7:1: internal compiler error: in cfg_layout_redirect_edge_and_branch_force, at cfgrtl.cc:4747 7 | } | ^ 0x364e6c1 internal_error(char const*, ...) /repo/gcc-trunk/gcc/diagnostic-global-context.cc:517 0x10e4f17 fancy_abort(char const*, int, char const*) /repo/gcc-trunk/gcc/diagnostic.cc:1722 0xab174f cfg_layout_redirect_edge_and_branch_force /repo/gcc-trunk/gcc/cfgrtl.cc:4747 0xab174f cfg_layout_redirect_edge_and_branch_force /repo/gcc-trunk/gcc/cfgrtl.cc:4743 0x12db213 redirect_edge_and_branch_force(edge_def*, basic_block_def*) /repo/gcc-trunk/gcc/cfghooks.cc:508 0x12dbcde make_forwarder_block(basic_block_def*, bool (*)(edge_def*), void (*)(basic_block_def*)) /repo/gcc-trunk/gcc/cfghooks.cc:920 0x12e3a05 merge_latch_edges /repo/gcc-trunk/gcc/cfgloop.cc:772 0x12e3a05 disambiguate_multiple_latches /repo/gcc-trunk/gcc/cfgloop.cc:823 0x12e3a05 disambiguate_loops_with_multiple_latches() /repo/gcc-trunk/gcc/cfgloop.cc:834 0x165cdf4 apply_loop_flags /repo/gcc-trunk/gcc/loop-init.cc:56 0x165d922 loop_optimizer_init(unsigned int) /repo/gcc-trunk/gcc/loop-init.cc:125 0x34ebe43 sms_schedule /repo/gcc-trunk/gcc/modulo-sched.cc:1361 0x34ee1cf execute /repo/gcc-trunk/gcc/modulo-sched.cc:3359 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ 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-20250313184654-r15-8040-ga5d56278d145d4-checking-yes-rtl-df-extra-riscv64/bin/../libexec/gcc/riscv64-unknown-linux-gnu/15.0.1/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-20250313184654-r15-8040-ga5d56278d145d4-checking-yes-rtl-df-extra-riscv64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 15.0.1 20250313 (experimental) (GCC)
[Bug fortran/119273] [14/15 Regression] subclass can not correctly access to superclass in associate statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119273 --- Comment #3 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #2) > A simple > > print *,temp_int(:,a%test_function()) > > works fine, so it is likely a pure ASSOCIATE problem. gfortran-14.2.0 even crashes on the print above, while r14-11407 does not.
[Bug c++/118104] [12/13/14/15 Regression] checking ICE when substituting packs into type aliases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118104
--- Comment #2 from Marek Polacek ---
For "void(Ts, Us)..." in the test we end up in use_pack_expansion_extra_args_p
with a TYPE _PACK_EXPANSION with pattern=void(Ts, Us) and the list of param
packs={Us, Ts}; parm_packs is { Ts -> , Us -> }. We
compare int to A, both are non-expansion args so this is OK, and then int and
P... and we get a mismatch and run into that assert.
I still do not understand what that assert is meant to catch.
[Bug rtl-optimization/93264] [12/13/14/15 Regression] ICE in cfg_layout_redirect_edge_and_branch_force, at cfgrtl.c:4522
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93264 --- Comment #24 from Andrew Pinski --- *** Bug 119276 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/116436] ICE: in cfg_layout_redirect_edge_and_branch_force, at cfgrtl.cc:4748 with -O2 -fmodulo-sched -fprofile-arcs -fgraphite-identity -fvpt -freorder-blocks-and-partition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116436 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 93264 ***
[Bug rtl-optimization/90040] [meta-bug] modulo-scheduler and partitioning issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90040 Bug 90040 depends on bug 116436, which changed state. Bug 116436 Summary: ICE: in cfg_layout_redirect_edge_and_branch_force, at cfgrtl.cc:4748 with -O2 -fmodulo-sched -fprofile-arcs -fgraphite-identity -fvpt -freorder-blocks-and-partition https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116436 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug rtl-optimization/119276] ICE: in cfg_layout_redirect_edge_and_branch_force, at cfgrtl.cc:4747 with -O2 -fmodulo-sched -freorder-blocks-and-partition -fharden-conditional-branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119276 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 93264 ***
[Bug ada/119277] New: Building an arm-none-eabi GNAT cross-compiler on latest master fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119277 Bug ID: 119277 Summary: Building an arm-none-eabi GNAT cross-compiler on latest master fails Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: zsolt_vadasz at protonmail dot com CC: dkm at gcc dot gnu.org Target Milestone: --- Created attachment 60747 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60747&action=edit Relevant build log Trying to build a cross-compiler targeting arm-none-eabi using the following commands: $ /mnt/smb/projects/contrib/gcc/configure --target=arm-none-eabi --prefix=/home/zsolti/.local --enable-languages=ada --disable-libada --disable-nls --disable-shared --without-headers $ make -j12 all-gcc $ make -j12 all-target-libgcc $ make -C gcc cross-gnattools ada.all.cross fails in the last command in the cross-gnattools target, as shown in the attached log. The exact same build process succeeded with gcc-14.2.0. Bisecting yielded d143b9fa817759ddc041365d988dacdadafddc22 as the first bad commit. My system GCC version is $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --enable-languages=ada,c,c++,d,fortran,go,lto,m2,objc,obj-c++,rust --enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://gitea.artixlinux.org/packages/gcc/issues --with-build-config=bootstrap-lto --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-libstdcxx-backtrace --enable-link-serialization=1 --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-werror Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.2.1 20250207 (GCC)
[Bug rtl-optimization/93264] [12/13/14/15 Regression] ICE in cfg_layout_redirect_edge_and_branch_force, at cfgrtl.c:4522
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93264 Andrew Pinski changed: What|Removed |Added CC||kito at gcc dot gnu.org --- Comment #22 from Andrew Pinski --- *** Bug 100647 has been marked as a duplicate of this bug. ***
[Bug c++/118104] [12/13/14/15 Regression] checking ICE when substituting packs into type aliases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118104
--- Comment #3 from Marek Polacek ---
A little different test I've been using:
```
template struct Z { };
template struct X {
template using Y = Z;
};
template
using foo = X::Y;
```
[Bug fortran/119273] [14/15 Regression] subclass can not correctly access to superclass in associate statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119273 anlauf at gcc dot gnu.org changed: What|Removed |Added Blocks||87477 --- Comment #2 from anlauf at gcc dot gnu.org --- A simple print *,temp_int(:,a%test_function()) works fine, so it is likely a pure ASSOCIATE problem. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477 [Bug 87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement
[Bug testsuite/119220] [15 Regression] FAIL: gcc.dg/debug/dwarf2/inline2.c scan-assembler-times DW_AT_entry_pc 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119220 --- Comment #2 from John David Anglin --- Created attachment 60748 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60748&action=edit Patch Your suggestion works.
[Bug ada/119277] Building an arm-none-eabi GNAT cross-compiler on latest master fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119277 Andrew Pinski changed: What|Removed |Added Resolution|FIXED |INVALID --- Comment #3 from Andrew Pinski --- .
[Bug ada/119277] Building an arm-none-eabi GNAT cross-compiler on latest master fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119277 Zsolt Vadasz changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #2 from Zsolt Vadasz --- (In reply to Andrew Pinski from comment #1) > For Ada, you need to build a native compiler of the same version before you > can buld a cross compiler of that version. > > This is recommeneded way too: > https://gcc.gnu.org/install/prerequisites.html > > ``` > GNAT > ... > In order to build a cross compiler, it is strongly recommended to install > the new compiler as native first, and then use it to build the cross > compiler. Other native compiler versions may work but this is not guaranteed > and will typically fail with hard to understand compilation errors during > the build. > ``` Apologies, I missed that part.
[Bug jit/119268] Exception thrown when host_detect_local_cpu returns NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119268 --- Comment #1 from Sam James --- (In reply to Antoni from comment #0) > host_detect_local_cpu is called in gcc/config/i386/i386-jit.cc and the > result is sent directly to a std::string, so if the result is NULL, this > will throw an exception. Is this upstream? I don't see it in trunk.
[Bug target/119269] New: [15 Regression] 6-22% slowdown of 433.milc on Aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119269 Bug ID: 119269 Summary: [15 Regression] 6-22% slowdown of 433.milc on Aarch64 Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: pheeck at gcc dot gnu.org CC: wilco at gcc dot gnu.org Blocks: 26163 Target Milestone: --- Host: aarch64-gnu-linux Target: aarch64-gnu-linux As seen here https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=580.70.0 https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=575.70.0 https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=577.70.0 https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=588.70.0 https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=578.70.0 there were some slowdowns of the 433.milc SPEC 2006 benchmark between commits r15-7846-gda8aaa7784810e r15-7877-g888e70b3226225 The slowdowns range from 6% to 22%. They seem to be exclusive to Aarch64 (measured on an Ampere Altra Neoverse N1 machine). This is a regression against GCC 14. See a comparison here: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.8=1066.70.0&plot.9=578.70.0&; Maybe this could be caused by r15-7871-gf870302515d5fc? Cc-ing Wilco. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug jit/119268] Exception thrown when host_detect_local_cpu returns NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119268 --- Comment #2 from Sam James --- Ah, it's to do with your https://github.com/antoyo/libgccjit/pull/6.
[Bug c++/119259] compilation error: *constexpr* operator==(const T&) const = default` forces compilation of std::vector's operator== function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119259
--- Comment #10 from Anders Wind ---
More interesting behavior: https://godbolt.org/z/K8cjEqTaa
```
#include
template
struct equatable {
T val;
// this does not
constexpr bool operator==(const equatable& o)const noexcept
requires(std::equality_comparable){
return val == o.val;
}
};
template
struct default_equatable
{
T val;
// this fails at compiling
constexpr bool operator==(const default_equatable&)const noexcept
requires(std::equality_comparable) = default;
};
struct not_equatable
{
int v;
auto operator==(const not_equatable&) const = delete;
};
template
struct intermidiate
{
T t;
constexpr inline bool
operator==( const intermidiate& y) const
{ return t == y.t; }
};
int main() {
auto compiles =
equatable>{.val=intermidiate{{.v=42}}};
auto fails_compilation =
default_equatable>{.val=intermidiate{{.v=42}}};
}
```
So implementing operator== on your own, makes gcc lazy evaluate and wont fail
compilation on construction, but using = default will.
[Bug target/119269] [15 Regression] 6-22% slowdown of 433.milc on Aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119269 Filip Kastl changed: What|Removed |Added Target Milestone|--- |15.0
[Bug jit/119268] Exception thrown when host_detect_local_cpu returns NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119268 --- Comment #3 from Jonathan Wakely --- (In reply to Antoni from comment #0) > host_detect_local_cpu is called in gcc/config/i386/i386-jit.cc and the > result is sent directly to a std::string, so if the result is NULL, this > will throw an exception. N.B. this is a GCC extension. In standard C++ it's just undefined to construct a std::string with a null pointer.
[Bug cobol/119242] cobol Front end requires __int128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119242 Jakub Jelinek changed: What|Removed |Added CC||jklowden at schemamania dot org, ||rdubner at symas dot com --- Comment #4 from Jakub Jelinek --- Not working on this anymore, feel free to use parts of this patch and extend it further.
[Bug cobol/119257] Version of GCC COBOL on Compiler Explorer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119257 Richard Biener changed: What|Removed |Added Resolution|--- |MOVED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Richard Biener --- This isn't the appropriate place to track this.
[Bug c/119264] [14/15 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in tree_nonzero_bits, at fold-const.cc:16688
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119264 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2025-03-13 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||pinskia at gcc dot gnu.org --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c/119264] [14/15 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in tree_nonzero_bits, at fold-const.cc:16688
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119264 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.3
[Bug middle-end/118869] infinite recusion in gimplifier with __builtin_assoc_barrier and structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118869 --- Comment #7 from Andrew Pinski --- *** Bug 119263 has been marked as a duplicate of this bug. ***
[Bug libstdc++/119266] libstdc++.modules.json has wrong path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119266 --- Comment #7 from Jason Merrill --- (In reply to Sam James from comment #0) > $ A=/usr/lib/gcc/x86_64-pc-linux-gnu/15/ > $ > B=/usr/lib/gcc/x86_64-pc-linux-gnu/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15/bits/std.cc > $ contrib/relpath.sh $A $B > ../lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15/bits/std.cc That looks right to me given those A and B. (In reply to Sam James from comment #5) > Unfortunately, realpath isn't in POSIX shell, but: > ``` > $ realpath --relative-to=$A > /usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15/bits/std.cc > include/g++-v15/bits/std.cc That's a very different B from the one above; with these arguments relpath.sh gives the same answer. This doesn't seem like a relpath problem.
[Bug fortran/119273] New: subclass can not correctly access to superclass in associate statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119273 Bug ID: 119273 Summary: subclass can not correctly access to superclass in associate statement Product: gcc Version: 14.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: xingjingwei666 at gmail dot com Target Milestone: --- Test case: module test_module type :: test_type_father integer :: val end type test_type_father type, extends(test_type_father) :: test_type_child contains procedure :: test_function end type test_type_child contains function test_function(a) result(out) class(test_type_child), intent(in) :: a integer :: out out = a%val end function end module program test use test_module implicit none type(test_type_child) :: a integer :: temp_int(1,1) a%val = 1 associate(temp => temp_int(:,a%test_function())) end associate end program test compile flag: -fcheck=bounds If compile without checking bounds, it works fine. But if "-fcheck=bounds" is added into compile flag, it will crush at runtime at associate statement. Error message is "Index '-788478977' of dimension 2 of array 'temp_int' outside of expected range (1:1)", but val is set to 1 just before the associate statement. It seems that subclass can't correctly access component of superclass in subclass's type-bounded procedure. Because in my real program, I use gdb(gdb is running on WSL2) to check what happened, the result is segment fault. When I check the value of superclass, it is empty rather than non-initialized random number. It occurs only on gfortran 14.2.0, I found there is no such problem on 12.4.0 and 13.3.0. My platform is MacBook Pro(M4 pro), but I also test it on WSL2(core i7 11700) and the result is the same. gfortran -v: Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/opt/homebrew/Cellar/gcc/14.2.0_1/bin/../libexec/gcc/aarch64-apple-darwin24/14/lto-wrapper Target: aarch64-apple-darwin24 Configured with: ../configure --prefix=/opt/homebrew/opt/gcc --libdir=/opt/homebrew/opt/gcc/lib/gcc/current --disable-nls --enable-checking=release --with-gcc-major-version-only --enable-languages=c,c++,objc,obj-c++,fortran,m2 --program-suffix=-14 --with-gmp=/opt/homebrew/opt/gmp --with-mpfr=/opt/homebrew/opt/mpfr --with-mpc=/opt/homebrew/opt/libmpc --with-isl=/opt/homebrew/opt/isl --with-zstd=/opt/homebrew/opt/zstd --with-pkgversion='Homebrew GCC 14.2.0_1' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues --with-system-zlib --build=aarch64-apple-darwin24 --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX15.sdk Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.2.0 (Homebrew GCC 14.2.0_1)
[Bug libstdc++/119266] libstdc++.modules.json has wrong path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119266 --- Comment #8 from Sam James --- I may well be getting mixed up then, sorry. Are the paths meant to be relative to the .json file? The file for me is at /usr/lib/gcc/x86_64-pc-linux-gnu/15/libstdc++.modules.json, and std.cc is at /usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15/bits/std.cc, so for that: $ realpath --relative-to=/usr/lib/gcc/x86_64-pc-linux-gnu/15 /usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15/bits/std.cc include/g++-v15/bits/std.cc
[Bug c/116545] Support old style statement attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116545 --- Comment #10 from lucier at math dot purdue.edu --- (In reply to Jakub Jelinek from comment #7) > Created attachment 60738 [details] > gcc15-pr116545.patch > > Full untested patch. I built and minimally tested this patch, and will upload the test summary. It fixes the problem with Gambit, none of the "musttail" tests fail. Whether there are other unexpected test failures I don't know.
[Bug tree-optimization/119274] [15 Regression] False positive array-bounds warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119274
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2025-03-13 00:00:00 |
CC||pinskia at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
--- Comment #5 from Andrew Pinski ---
For:
```
#include
typedef std::vector v1;
static
void drop_inplace(v1 & c, size_t len)
{
if (len <= c.size())
c[len-1] = 0;
}
void func(){
v1 vec1{1,2,3,4,5,6};
drop_inplace(vec1, 10);
}
```
fre3 has:
```
Value numbering stmt = _27 = PHI <0B(4), _35(9)>
Setting value number of _27 to _35 (changed)
_35 is available for _35
...
Value numbering stmt = __result_28 = _27 + _17;
Setting value number of _6 to __result_28 (changed)
Making available beyond BB14 _6 for value __result_28
Setting value number of _4 to _35 (changed)
Making available beyond BB14 _4 for value _35
Value numbering stmt = _9 = _6 - _4;
Setting value number of _9 to _9 (changed)
```
_9 should have been matched-and-simplified to `_17` during fre3 but seemly we
miss that _35's value is the same as _27. I have not debugged further than that
yet.
[Bug ipa/119147] 525.x264_r is approx. 10% slower with LTO+PGO than without (at -Ofast -march-native)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119147 --- Comment #2 from GCC Commits --- The master branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:57dbbdd8e34b80926e06b352b6c442c555b303ed commit r15-8041-g57dbbdd8e34b80926e06b352b6c442c555b303ed Author: Jan Hubicka Date: Thu Mar 13 20:11:02 2025 +0100 Fix speculation_useful_p This patch fixes issue with speculation and x264. With profile feedback we first introduce speculative calls to mc_chroma which is called indirectly. Then we propagate constants acorss these calls (which is useful transform) but then speculation_useful_p decides that these speculations are not useful and we end up calling unspecialized version. This patch updates speculation_useful_p to consider edges redirected earlier to clones as useful, since we can expect that ipa-cp knows what it is doing (originally it only looked for inlined calls). I also noticed that we want to keep edges even if they are not hot. Finally I noticed a typo in computing target in code which intends to keep devirtualized calls to functions where we propagated pureness/constness. Newly we also track ipa-modref summaries as they also may be useful. gcc/ChangeLog: PR ipa/119147 * ipa-inline.cc: Include ipa-modref-tree.h and ipa-modref.h. (speculation_useful_p): If target is a clone, speculation is usef; fix mixup of caller and callee; speculate also calls not considered hot; consider modref summary also possibly useful for optimization. * ipa-profile.cc (ipa_profile): Keep non-hot speculations.
[Bug rtl-optimization/119275] New: ICE: in gen_lowpart_general, at rtlhooks.cc:57 with -O2 -march=rv64gv -mrvv-vector-bits=zvl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119275 Bug ID: 119275 Summary: ICE: in gen_lowpart_general, at rtlhooks.cc:57 with -O2 -march=rv64gv -mrvv-vector-bits=zvl Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization 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 60744 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60744&action=edit reduced testcase Compiler output: $ riscv64-unknown-linux-gnu-gcc -O2 -march=rv64gv -mrvv-vector-bits=zvl testcase.c during RTL pass: reload testcase.c: In function 'foo': testcase.c:23:1: internal compiler error: in gen_lowpart_general, at rtlhooks.cc:57 23 | } | ^ 0x364e6c1 internal_error(char const*, ...) /repo/gcc-trunk/gcc/diagnostic-global-context.cc:517 0x10e4f17 fancy_abort(char const*, int, char const*) /repo/gcc-trunk/gcc/diagnostic.cc:1722 0xb8e9ab gen_lowpart_general(machine_mode, rtx_def*) /repo/gcc-trunk/gcc/rtlhooks.cc:57 0x1cef4d8 riscv_legitimize_move(machine_mode, rtx_def*, rtx_def*) /repo/gcc-trunk/gcc/config/riscv/riscv.cc:3601 0x25e5800 gen_movdi(rtx_def*, rtx_def*) /repo/gcc-trunk/gcc/config/riscv/riscv.md:2492 0x141bb80 rtx_insn* insn_gen_fn::operator()(rtx_def*, rtx_def*) const /repo/gcc-trunk/gcc/recog.h:472 0x141bb80 emit_move_ccmode /repo/gcc-trunk/gcc/expr.cc:4455 0x141bb80 emit_move_insn_1(rtx_def*, rtx_def*) /repo/gcc-trunk/gcc/expr.cc:4600 0x141c009 emit_move_insn(rtx_def*, rtx_def*) /repo/gcc-trunk/gcc/expr.cc:4751 0x1672ffc lra_emit_move(rtx_def*, rtx_def*) /repo/gcc-trunk/gcc/lra.cc:509 0x168d0c3 curr_insn_transform /repo/gcc-trunk/gcc/lra-constraints.cc:4812 0x168ef53 lra_constraints(bool) /repo/gcc-trunk/gcc/lra-constraints.cc:5569 0x1676624 lra(_IO_FILE*, int) /repo/gcc-trunk/gcc/lra.cc:2449 0x161fcef do_reload /repo/gcc-trunk/gcc/ira.cc:5987 0x161fcef execute /repo/gcc-trunk/gcc/ira.cc:6175 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ 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-20250313133031-r15-8032-g6e47e6d48844ee-checking-yes-rtl-df-extra-riscv64/bin/../libexec/gcc/riscv64-unknown-linux-gnu/15.0.1/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-20250313133031-r15-8032-g6e47e6d48844ee-checking-yes-rtl-df-extra-riscv64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 15.0.1 20250313 (experimental) (GCC)
[Bug ada/119277] Building an arm-none-eabi GNAT cross-compiler on latest master fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119277 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- For Ada, you need to build a native compiler of the same version before you can buld a cross compiler of that version. This is recommeneded way too: https://gcc.gnu.org/install/prerequisites.html ``` GNAT ... In order to build a cross compiler, it is strongly recommended to install the new compiler as native first, and then use it to build the cross compiler. Other native compiler versions may work but this is not guaranteed and will typically fail with hard to understand compilation errors during the build. ```
[Bug ada/119265] unsigned __int128 not converted properly by -fdump-ada-spec unlike __int128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119265 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #2 from Eric Botcazou --- Fixing.
[Bug ada/119265] unsigned __int128 not converted properly by -fdump-ada-spec unlike __int128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119265 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org Summary|unsigned __int128 not |unsigned __int128 not |converted properly by |converted properly by |-fdump-ada-spec, while |-fdump-ada-spec unlike |__int128 is |__int128 Last reconfirmed||2025-03-13 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Eric Botcazou --- Small loophole indeed.
[Bug rtl-optimization/100647] ICE during sms pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100647 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 93264 ***
[Bug analyzer/119278] New: [15 Regression] ICE on gnutls-3.8.9: in cmp_csts_same_type, at analyzer/svalue.cc:466
c42f ana::svalue::cmp_ptr(ana::svalue const*, ana::svalue const*) ???:0 0x157c5ba ana::svalue::cmp_ptr_ptr(void const*, void const*) ???:0 0x266be13 long cmp1(char*, char*, sort_ctx*) ???:0 0x266bf10 void mergesort(char*, sort_ctx*, unsigned long, char*, char*) ???:0 0x266c9c3 gcc_qsort(void*, unsigned long, unsigned long, int (*)(void const*, void const*)) ???:0 0x14f0d70 ana::program_state::detect_leaks(ana::program_state const&, ana::program_state const&, ana::svalue const*, ana::extrinsic_state const&, ana::region_model_context*) ???:0 0x14d0918 ana::exploded_graph::process_node(ana::exploded_node*) ???:0 0x14d1819 ana::exploded_graph::process_worklist() ???:0 0x14d39e3 ana::impl_run_checkers(ana::logger*) ???:0 0x14d48cd ana::run_checkers() ???:0 0x14c5956 (anonymous namespace)::pass_analyzer::execute(function*) ???:0 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. Compiler version: $ gcc/xgcc -Bgcc -v Reading specs from gcc/specs COLLECT_GCC=gcc/xgcc COLLECT_LTO_WRAPPER=gcc/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /home/slyfox/dev/git/gcc/configure --disable-multilib --disable-bootstrap --disable-lto --disable-libsanitizer --enable-languages=c CFLAGS='-O1 -g0' CXXFLAGS='-O1 -g0' LDFLAGS='-O1 -g0' Thread model: posix Supported LTO compression algorithms: zlib gcc version 15.0.1 20250313 (experimental) (GCC)
[Bug analyzer/119278] [15 Regression] ICE on gnutls-3.8.9: in cmp_csts_same_type, at analyzer/svalue.cc:466
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119278 Andrew Pinski changed: What|Removed |Added Version|unknown |15.0 Target Milestone|--- |15.0
[Bug rtl-optimization/93264] [12/13/14/15 Regression] ICE in cfg_layout_redirect_edge_and_branch_force, at cfgrtl.c:4522
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93264 Andrew Pinski changed: What|Removed |Added CC||zsojka at seznam dot cz --- Comment #23 from Andrew Pinski --- *** Bug 116436 has been marked as a duplicate of this bug. ***
[Bug analyzer/119278] [15 Regression] ICE on gnutls-3.8.9: in cmp_csts_same_type, at analyzer/svalue.cc:466
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119278 --- Comment #1 from Andrew Pinski --- Most likely https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=8015a72ae496401e05942f4d33c94aa45174f841 was not a full fix for RAW_DATA_CST.
[Bug c++/119274] New: [15 Regression] False positive array-bounds warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119274
Bug ID: 119274
Summary: [15 Regression] False positive array-bounds warning
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: larsbj at gullik dot org
Target Milestone: ---
Created attachment 60741
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60741&action=edit
Unreduced test case
This test case compiles without warnings with GCC 14, but gives warnings with
GCC 15.
Compiled with:
g++ -Wfatal-errors -Werror=array-bounds -O2 -std=gnu++23 -c test.cpp
g++ (GCC) 15.0.1 20250313 (experimental)
g++ -Wfatal-errors -Werror=array-bounds -O2 -std=gnu++23 -c test.cpp
In file included from
/opt/gcc/gcc-15/include/c++/15.0.1/bits/hashtable_policy.h:36,
from /opt/gcc/gcc-15/include/c++/15.0.1/bits/hashtable.h:37,
from
/opt/gcc/gcc-15/include/c++/15.0.1/bits/unordered_map.h:33,
from /opt/gcc/gcc-15/include/c++/15.0.1/unordered_map:43,
from /opt/gcc/gcc-15/include/c++/15.0.1/functional:65,
from test.cpp:1:
In function ‘constexpr void std::__assign_one(_OutIter&, _InIter&) [with bool
_IsMove = true; _OutIter = int*; _InIter = int*]’,
inlined from ‘constexpr _OutIter std::__copy_move_a2(_InIter, _Sent,
_OutIter) [with bool _IsMove = true; _InIter = int*; _Sent = int*; _OutIter =
int*]’ at /opt/gcc/gcc-15/include/c++/15.0.1/bits/stl_algobase.h:433:34,
inlined from ‘constexpr _OI std::__copy_move_a1(_II, _II, _OI) [with bool
_IsMove = true; _II = int*; _OI = int*]’ at
/opt/gcc/gcc-15/include/c++/15.0.1/bits/stl_algobase.h:492:42,
inlined from ‘constexpr _OI std::__copy_move_a(_II, _II, _OI) [with bool
_IsMove = true; _II = __gnu_cxx::__normal_iterator >; _OI =
__gnu_cxx::__normal_iterator >]’ at
/opt/gcc/gcc-15/include/c++/15.0.1/bits/stl_algobase.h:500:31,
inlined from ‘constexpr _OI std::move(_II, _II, _OI) [with _II =
__gnu_cxx::__normal_iterator >; _OI =
__gnu_cxx::__normal_iterator >]’ at
/opt/gcc/gcc-15/include/c++/15.0.1/bits/stl_algobase.h:674:38,
inlined from ‘constexpr std::vector<_Tp, _Alloc>::iterator std::vector<_Tp,
_Alloc>::_M_erase(iterator, iterator) [with _Tp = int; _Alloc =
std::allocator]’ at
/opt/gcc/gcc-15/include/c++/15.0.1/bits/vector.tcc:201:6,
inlined from ‘constexpr std::vector<_Tp, _Alloc>::iterator std::vector<_Tp,
_Alloc>::erase(const_iterator, const_iterator) [with _Tp = int; _Alloc =
std::allocator]’ at
/opt/gcc/gcc-15/include/c++/15.0.1/bits/stl_vector.h:1735:17,
inlined from ‘void drop_inplace(std::vector&, size_t)’ at
test.cpp:9:16,
inlined from ‘test()::’ at test.cpp:17:25,
inlined from ‘constexpr _Res std::__invoke_impl(__invoke_other, _Fn&&,
_Args&& ...) [with _Res = void; _Fn = test()::&; _Args = {}]’ at
/opt/gcc/gcc-15/include/c++/15.0.1/bits/invoke.h:63:36,
inlined from ‘constexpr std::enable_if_t<((bool)is_invocable_r_v<_Res,
_Callable, _Args ...>), _Res> std::__invoke_r(_Callable&&, _Args&& ...) [with
_Res = void; _Callable = test()::&; _Args = {}]’ at
/opt/gcc/gcc-15/include/c++/15.0.1/bits/invoke.h:113:28,
inlined from ‘static _Res std::_Function_handler<_Res(_ArgTypes ...),
_Functor>::_M_invoke(const std::_Any_data&, _ArgTypes&& ...) [with _Res = void;
_Functor = test()::; _ArgTypes = {}]’ at
/opt/gcc/gcc-15/include/c++/15.0.1/bits/std_function.h:292:30:
/opt/gcc/gcc-15/include/c++/15.0.1/bits/stl_algobase.h:404:16: error: array
subscript 10 is outside array bounds of ‘int [6]’ [-Werror=array-bounds=]
404 | *__out = std::move(*__in);
| ~~~^~
[Bug libstdc++/119266] libstdc++.modules.json has wrong path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119266
--- Comment #11 from Sam James ---
(In reply to Sam James from comment #10)
> OK, avoiding speculation and getting back to facts:
> ```
> $ cat ./build/x86_64-pc-linux-gnu/libstdc++-v3/src/c++23/relpath.log
> called with '/usr/lib64' and
> '/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15/bits'
> -> called with '/usr/lib64' and
> '/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15/bits'
> ```
>
> so toolexeclibdir is /usr/lib64 for me, and includebitsdir is
> /usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15/bits.
```
# Calculate toolexeclibdir
# Also toolexecdir, though it's only used in toolexeclibdir
case ${version_specific_libs} in
yes)
# Need the gcc compiler version to know where to install libraries
# and header files if --enable-version-specific-runtime-libs option
# is selected.
toolexecdir='$(libdir)/gcc/$(target_noncanonical)'
toolexeclibdir='$(toolexecdir)/$(gcc_version)$(MULTISUBDIR)'
;;
no)
if test -n "$with_cross_host" &&
test x"$with_cross_host" != x"no"; then
# Install a library built with a cross compiler in tooldir, not libdir.
toolexecdir='$(exec_prefix)/$(target_noncanonical)'
case ${with_toolexeclibdir} in
no)
toolexeclibdir='$(toolexecdir)/lib'
;;
*)
toolexeclibdir=${with_toolexeclibdir}
;;
esac
else
toolexecdir='$(libdir)/gcc-lib/$(target_noncanonical)'
toolexeclibdir='$(libdir)'
fi
multi_os_directory=`$CC -print-multi-os-directory`
case $multi_os_directory in
.) ;; # Avoid trailing /.
*) toolexeclibdir=$toolexeclibdir/$multi_os_directory ;;
esac
;;
esac
AC_SUBST(toolexecdir)
AC_SUBST(toolexeclibdir)
```
We currently don't build with version-specific-libs (we probably should, but we
don't right now). Then we end up with toolexeclibdir=libdir.
[Bug fortran/119272] Function misidentified as non-function in associate statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119272 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Ever confirmed|0 |1 Last reconfirmed||2025-03-13 Status|UNCONFIRMED |NEW --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed also on 15-trunk.
[Bug fortran/119106] Crash with character array constructor + implicit loop + data from `parameter` variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119106 --- Comment #4 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #3) > Created attachment 60728 [details] > Draft patch > > This patch fixes the testcase, but needs further testing. Unfortunately this regresses on: gfortran.dg/reshape_9.f90 gfortran.dg/zero_sized_13.f90 and I do not see how to resolve this... :-(
[Bug fortran/119118] substring with negative start index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119118 --- Comment #10 from GCC Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:a5d56278d145d439092adf6f65c865c85623f881 commit r15-8040-ga5d56278d145d439092adf6f65c865c85623f881 Author: Harald Anlauf Date: Thu Mar 13 18:46:54 2025 +0100 Fortran: improve checking of substring bounds [PR119118] Commit r15-7873 copy-pasted erroneous code containing a non-terminating loop that did not progress its control variable, and a switch statement with an unhandled case leading to a gcc_unreachable () with suitable input. PR fortran/119118 gcc/fortran/ChangeLog: * dependency.cc (contains_forall_index_p): Let loop over elements of a constructor update its control variable. Handle REF_INQUIRY in switch statement. (gfc_contains_implied_index_p): Likewise. gcc/testsuite/ChangeLog: * gfortran.dg/bounds_check_26.f90: Update test.
[Bug ipa/119147] 525.x264_r is approx. 10% slower with LTO+PGO than without (at -Ofast -march-native)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119147 Jan Hubicka changed: What|Removed |Added Last reconfirmed||2025-03-13 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Jan Hubicka --- There is surprising group of issues with ipa-cp cost model and speculation I have WIP patches for. However there is also problem with vectorization of mc_chroma. We vectorized w/o profile feedback but give up with profile feedback since the expected number of iterations is lower then the min profitability. With cascade epilogue it seems that vectorization is a win, so cost model should consider vectorizatoin with smaller Vf...
[Bug fortran/119273] [14/15 Regression] subclass can not correctly access to superclass in associate statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119273
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2025-03-13
Priority|P3 |P4
Ever confirmed|0 |1
Keywords||wrong-code
Known to fail||14.2.1, 15.0
Target Milestone|--- |14.3
Summary|subclass can not correctly |[14/15 Regression] subclass
|access to superclass in |can not correctly access to
|associate statement |superclass in associate
||statement
--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.
gfortran-13 did not generate bounds-checking for the code in question.
The current version seems to invoke test_function twice with fcheck=bounds,
with the first call (for the bounds-checking) using a wrong argument where
the vptr is not set up:
struct __class_test_module_Test_type_child_t class.0;
integer(kind=8) D.4855;
struct __class_test_module_Test_type_child_t class.1;
integer(kind=8) D.4857;
a.test_type_father.val = 1;
D.4855 = (integer(kind=8)) test_function (&class.0);
if (D.4855 <= 0)
{
_gfortran_runtime_error_at (&"At line 29 of file pr119273.f90"[1]{lb: 1
sz: 1}, &"Index \'%ld\' of dimension 2 of array \'temp_int\' outside of
expected range (%ld:%ld)"[1]{lb: 1 sz: 1}, D.4855, 1, 1);
}
if (D.4855 > 1)
{
_gfortran_runtime_error_at (&"At line 29 of file pr119273.f90"[1]{lb: 1
sz: 1}, &"Index \'%ld\' of dimension 2 of array \'temp_int\' outside of
expected range (%ld:%ld)"[1]{lb: 1 sz: 1}, D.4855, 1, 1);
}
class.1._vptr = (struct __vtype_test_module_Test_type_child * {ref-all})
&__vtab_test_module_Test_type_child;
class.1._data = &a;
D.4857 = (integer(kind=8)) test_function (&class.1);
[Bug tree-optimization/119274] [15 Regression] False positive array-bounds warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119274 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2025-03-13 Ever confirmed|0 |1 --- Comment #4 from Andrew Pinski --- I am trying to produced a reduced testcae still.
[Bug libstdc++/119266] libstdc++.modules.json has wrong path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119266 --- Comment #10 from Sam James --- OK, avoiding speculation and getting back to facts: ``` $ cat ./build/x86_64-pc-linux-gnu/libstdc++-v3/src/c++23/relpath.log called with '/usr/lib64' and '/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15/bits' -> called with '/usr/lib64' and '/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15/bits' ``` so toolexeclibdir is /usr/lib64 for me, and includebitsdir is /usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15/bits.
[Bug tree-optimization/119274] [15 Regression] False positive array-bounds warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119274
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #1 from Andrew Pinski ---
```
__result_30 = _29 + 24;
vec.D.54336._M_impl.D.53591._M_finish = __result_30;
vec.D.54336._M_impl.D.53591._M_start = _29;
__guard._M_storage = 0B;
vec.D.54336._M_impl.D.53591._M_end_of_storage = __result_30;
__guard ={v} {CLOBBER(eob)};
__guard ={v} {CLOBBER(eos)};
__l ={v} {CLOBBER(eos)};
_12 = __result_30 - _29;
```
_12 should be just 24 but it is not optimized as such by the time bounds
warning happens.
[Bug tree-optimization/119274] [15 Regression] False positive array-bounds warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119274 --- Comment #2 from Andrew Pinski --- Created attachment 60742 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60742&action=edit Slightly reduced ABle to remove the std::function part. but still has more missing.
[Bug cobol/119241] cobol Front end uses host floating point (128b) support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119241 Iain Sandoe changed: What|Removed |Added CC||jklowden at schemamania dot org, ||rdubner at symas dot com --- Comment #2 from Iain Sandoe --- what would be useful in the short-term is an example cobol code that does relevant arithmetic so that we can see what the FE emits. What is needed in terms of conversions / arithmetic in the FE itself to create literals etc. would also be helpful.
[Bug tree-optimization/119274] [15 Regression] False positive array-bounds warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119274 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |15.0
[Bug tree-optimization/119274] [15 Regression] False positive array-bounds warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119274 Andrew Pinski changed: What|Removed |Added Attachment #60742|0 |1 is obsolete|| --- Comment #3 from Andrew Pinski --- Created attachment 60743 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60743&action=edit Slightly more reduced Stil have the need for std::vector but removed most other code. I am suspecting r15-5361-gaac5c57ee16723 which exposed this. Basically it takes slightly more passes to optimize away the if inside drop_inplace but it should not.
[Bug cobol/119244] cobol/libgcobol should allow libquadmath to provide 128b floating support.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119244 Iain Sandoe changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org --- Comment #8 from Iain Sandoe --- I'm taking an initial look at this.
[Bug middle-end/119279] Specifying frame pointer dependency in inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119279 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2025-03-13 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- I am not 100% sure doing a call inside an inline-asm will ever be valid. Why is the call needs to be done in the inline-asm?
[Bug ada/119265] unsigned __int128 not converted properly by -fdump-ada-spec unlike __int128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119265 --- Comment #4 from GCC Commits --- The releases/gcc-14 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:1016eea220ffb75a8b8c3031918e1834a8a544e8 commit r14-11408-g1016eea220ffb75a8b8c3031918e1834a8a544e8 Author: Eric Botcazou Date: Fri Mar 14 00:01:46 2025 +0100 Plug small loophole in the pattern matching done by -fdump-ada-spec gcc/c-family/ PR ada/119265 * c-ada-spec.cc (dump_ada_node) : Deal with typedefs of unsigned __int128.
[Bug ada/119265] unsigned __int128 not converted properly by -fdump-ada-spec unlike __int128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119265 --- Comment #3 from GCC Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:ab4e9fd943124f0630e560a56a5477d5d7ca2c1f commit r15-8043-gab4e9fd943124f0630e560a56a5477d5d7ca2c1f Author: Eric Botcazou Date: Fri Mar 14 00:01:46 2025 +0100 Plug small loophole in the pattern matching done by -fdump-ada-spec gcc/c-family/ PR ada/119265 * c-ada-spec.cc (dump_ada_node) : Deal with typedefs of unsigned __int128.
[Bug ada/119265] unsigned __int128 not converted properly by -fdump-ada-spec unlike __int128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119265 Eric Botcazou changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |13.4 Status|ASSIGNED|RESOLVED --- Comment #6 from Eric Botcazou --- This should be fixed in upcoming 13.x, 14.x and 15.x releases.
[Bug c/119279] New: Specifying frame pointer dependency in inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119279
Bug ID: 119279
Summary: Specifying frame pointer dependency in inline asm
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jpoimboe at redhat dot com
CC: ak at gcc dot gnu.org, hjl.tools at gmail dot com, hpa at
zytor dot com,
jakub at gcc dot gnu.org, peterz at infradead dot org,
pinskia at gcc dot gnu.org, rguenth at gcc dot gnu.org,
torva...@linux-foundation.org, ubizjak at gmail dot com
Target Milestone: ---
Target: x86_64-*-*
Created attachment 60749
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60749&action=edit
Reduced test case (gcc -O2 -fno-omit-frame-pointer -fno-optimize-sibling-calls
-c mmap.i -o mmap.o)
[ This was discussed previously in bug 117311, which was a documentation
request for existing (but unsupported) behavior. This bug here is not for
documenting existing behavior, but rather a request to define a supported
solution for specifying a frame pointer dependency in inline asm, whatever that
looks like. ]
In the Linux kernel on x86 it's common for inline asm to have a "call" to a
thunk which saves registers before calling out to another function. If the
inline asm is in a leaf function, or gets emitted before the function prologue,
the frame pointer doesn't get set up before the call.
The current unsupported workaround used throughout the kernel is to make the
stack pointer an in/out constraint:
register unsigned long current_stack_pointer asm("%rsp");
#define ASM_CALL_CONSTRAINT "+r" (current_stack_pointer)
We've also experimented with making __builtin_frame_address(0) an input
constraint, which also seems to work:
#define ASM_CALL_CONSTRAINT "r" (__builtin_frame_address(0))
Unfortunately these are unsupported hacks which just happen to work. It would
be much better to have a supported solution.
The attached test case results in the following:
:
0: e8 00 00 00 00 call 51:
R_X86_64_PLT32 __SCT__preempt_schedule-0x4
5: 48 83 3d 00 00 00 00 00 cmpq $0x0,0x0(%rip)# d
8: R_X86_64_PC32
pfn_modify_allowed_pfn-0x5
d: 75 01 jne10
f: c3 ret
10: 55 push %rbp
11: 31 c0 xor%eax,%eax
13: 48 89 e5mov%rsp,%rbp
16: e8 00 00 00 00 call 1b 17:
R_X86_64_PLT32 capable-0x4
1b: 5d pop%rbp
1c: c3 ret
[Bug libstdc++/116440] [14/15 Regression] [C++20] std::tuple> does not compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116440 --- Comment #7 from GCC Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:6570fa6f2612a4e4ddd2fcfc119369a1a48656e4 commit r15-8044-g6570fa6f2612a4e4ddd2fcfc119369a1a48656e4 Author: Patrick Palka Date: Thu Mar 13 19:55:00 2025 -0400 libstdc++: Work around C++20 tuple> constraint recursion [PR116440] The type tuple> is clearly copy/move constructible, but for reasons that are not yet completely understood checking this triggers constraint recursion with our C++20 tuple implementation (but not the C++17 implementation). It turns out this recursion stems from considering the non-template tuple(const _Elements&) constructor during the copy/move constructibility check. Considering this constructor is ultimately redundant, since the defaulted copy/move constructors are better matches. GCC has a non-standard "perfect candidate" optimization[1] that causes overload resolution to shortcut considering template candidates if we find a (non-template) perfect candidate. So to work around this issue (and as a general compile-time optimization) this patch turns the problematic constructor into a template so that GCC doesn't consider it when checking for copy/move constructibility of this tuple type. Changing the template-ness of a constructor can affect overload resolution (since template-ness is a tiebreaker) so there's a risk this change could e.g. introduce overload resolution ambiguities. But the original C++17 implementation has long defined this constructor as a template (in order to constrain it etc), so doing the same thing in the C++20 mode should naturally be quite safe. The testcase still fails with Clang (in C++20 mode) since it doesn't implement said optimization. [1]: See r11-7287-g187d0d5871b1fa and https://isocpp.org/files/papers/P3606R0.html PR libstdc++/116440 libstdc++-v3/ChangeLog: * include/std/tuple (tuple::tuple(const _Elements&...)) [C++20]: Turn into a template. * testsuite/20_util/tuple/116440.C: New test. Reviewed-by: Jonathan Wakely
[Bug cobol/119214] debug volatile asm breaks assembling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119214 Robert Dubner changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2025-03-14 Ever confirmed|0 |1 --- Comment #14 from Robert Dubner --- (In reply to Richard Biener from comment #13) > (In reply to Robert Dubner from comment #7) > > Yes. IMO the least invasive way is to instead use labels. > At the present time, I think I want to simply implement the if( !optimize ) solution. It won't be the final solution. But currently, the ASM_EXPR method, for all of its potential warts, works with the matching logic in GDB-COBOL. Currently the only way to get it is to use the .deb package on the cobolworx.com web site. But it is there, and it does work, and I'd like it to keep working even after we do what we decide to do here. It took me weeks to sort out the changes to the compiler and to gdb to get it working. My guess is that switching to something else like LABEL_DECL might take several weeks again to keep all of my test cases working. As an expedient and temporary means of getting rid of the "-O -ftracer" bug, and with your concurrence, I will propose a patch with the -if( !optimize ) code. And I am adding to my pile of index cards "USE LABEL_DECL instead of ASM_EXPR", and at some point I will do that research. But I don't think that right now is the right time to spend that time, and I want to get rid of the "-O ftracer" bug, and I want my nascent debugger to keep working. However: Rest assured I believe you are correct. I agree LABEL_DECL is the right way to go. It gives me all the pieces I need in ways I already understand, and thank you for those insights. But I have fifteen other bugs to look at here, and at the rate I am clearing them, it will take forever. Literally forever: it's been two days, and I have cleared exactly zero bugs. Incidentally: To make all that work, I need a NOP -- an instruction that gets a ".loc 1 xxx" location but doesn't do anything, and I couldn't figure out how to create a NOP. I am doing the equivalent of a NOP by creating an integer with global scope in libgcobol.so, and I generate gg_assign(var_decl_nop, build_int_cst_type(INT, 106)); at the points in the executable where I need a NOP. (Yes, I am solving a problem with a write-only variable. If you let me hang around, you'll likely see more goofy stuff like that. It's not my fault; that stuff comes and finds *me*.) Is there a proper way of generating a NOP? It would just be neater.
[Bug ada/119265] unsigned __int128 not converted properly by -fdump-ada-spec unlike __int128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119265 --- Comment #5 from GCC Commits --- The releases/gcc-13 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:cb735b2768410e1ab201899c65daeaaed2baff71 commit r13-9427-gcb735b2768410e1ab201899c65daeaaed2baff71 Author: Eric Botcazou Date: Fri Mar 14 00:01:46 2025 +0100 Plug small loophole in the pattern matching done by -fdump-ada-spec gcc/c-family/ PR ada/119265 * c-ada-spec.cc (dump_ada_node) : Deal with typedefs of unsigned __int128.
[Bug middle-end/119279] Specifying frame pointer dependency in inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119279 --- Comment #2 from Linus Torvalds --- (In reply to Andrew Pinski from comment #1) > > Why is the call needs to be done in the inline-asm? Typically it's the fallback alternative for when the primary inline asm doesn't work Ie the "real" asm may be something like a cmpxchg16b, but then it gets rewritten as a call if the CPU does not support that instruction. But sometimes it's an actual call, just with special calling conventions (eg firmware call to EFI or whatever).
[Bug libstdc++/119266] libstdc++.modules.json has wrong path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119266 --- Comment #5 from Sam James --- Unfortunately, realpath isn't in POSIX shell, but: ``` $ realpath --relative-to=$A /usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15/bits/std.cc include/g++-v15/bits/std.cc ``` and indeed using `"source-path": "include/g++-v15/bits/std.cc",` and so on works fine for CMake.
