[Bug modula2/120497] An error is generated when returning a var variable which is a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120497 Gaius Mulley changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Gaius Mulley --- Closing as patch has been applied.
[Bug modula2/120497] An error is generated when returning a var variable which is a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120497 --- Comment #3 from GCC Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:170717fa243ef466a99498113167627539af4553 commit r16-1029-g170717fa243ef466a99498113167627539af4553 Author: Gaius Mulley Date: Sun Jun 1 01:05:55 2025 +0100 PR modula2/120497: error is generated for good code when returning a pointer var variable The return type checking needs to skip over the Lvalue part of the VAR parameter or variable. gcc/m2/ChangeLog: PR modula2/120497 * gm2-compiler/M2Range.mod (IsAssignmentCompatible): Remove from import list. (FoldTypeReturnFunc): Rewrite to skip the Lvalue of a var variable. (CodeTypeReturnFunc): Ditto. (CodeTypeIndrX): Call AssignmentTypeCompatible rather than IsAssignmentCompatible. (FoldTypeIndrX): Ditto. gcc/testsuite/ChangeLog: PR modula2/120497 * gm2/pim/pass/ReturnType.mod: New test. * gm2/pim/pass/ReturnType2.mod: New test. Signed-off-by: Gaius Mulley
[Bug ada/120496] adaint.h:324:8: error: unknown type name 'cpu_set_t'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120496 --- Comment #4 from Sam James --- (In reply to Dennis Clarke from comment #2) > May be trivial to fix given that the error only ever happens in the final > stage of the bootstrap. No, there's a lot more. If it were just this, I would give you a patch now.
[Bug ada/120496] adaint.h:324:8: error: unknown type name 'cpu_set_t'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120496 --- Comment #2 from Dennis Clarke --- (In reply to Sam James from comment #1) > There's a bunch of porting required to get GNAT working on musl. I may work > on it this stage1. This was one of my primary concerns. I know that MUSL is a whole other world away from GlibC. So perhaps this is not really a bug with GCC but merely a porting issue. I have a bootstrap running now wherein I removed "ada" from the language options. Lets see what we get for testsuite results... however ... I can not fix the ada issue off the top of my head. May be trivial to fix given that the error only ever happens in the final stage of the bootstrap.
[Bug c/119950] __builtin_constant_p warning with -Wdeprecated-non-prototype inconsistent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119950 Simon Marchi changed: What|Removed |Added CC||simon.marchi at polymtl dot ca --- Comment #4 from Simon Marchi --- Should this fix get backported to the GCC 15 branch (for 15.2)?
[Bug libfortran/116400] [15/16 Regression] Regenerated files are no longer written to the source directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116400 --- Comment #16 from kargls at comcast dot net --- (In reply to kargls from comment #15) > (In reply to Francois-Xavier Coudert from comment #12) > > Created attachment 61532 [details] > > Regeneration script > > > > Attached is a shell script, to be placed in libgfortran/, that can be run in > > that directory to regenerated all files. > > Thanks! I won't have a chance to look at this until the weekend. > Definitely need to find the right m4 processor. On FreeBSD m4 is not GNU m4 and the script fails. Here's an example output, diff --git a/libgfortran/generated/_abs_c10.F90 b/libgfortran/generated/_abs_c10.F90 index 9b6f1280be8..6694a1e596d 100644 --- a/libgfortran/generated/_abs_c10.F90 +++ b/libgfortran/generated/_abs_c10.F90 @@ -32,14 +32,14 @@ #include "kinds.inc" #include "c99_protos.inc" -#if defined (HAVE_GFC_COMPLEX_10) -#ifdef HAVE_CABSL +#if defined (HAVE_GFC_UNKNOW_) +#ifdef HAVE__ -elemental function _gfortran_specific__abs_c10 (parm) - complex (kind=10), intent (in) :: parm - real (kind=10) :: _gfortran_specific__abs_c10 +elemental function _gfortran_specific___ (parm) + unknown (kind=), intent (in) :: parm + unknown (kind=) :: _gfortran_specific___ - _gfortran_specific__abs_c10 = abs (parm) + _gfortran_specific___ = (parm) end function #endif If I modify the scrip to use 'm4 -g', then it produces what appears to be the correct result. On FreeBSD, -g tells m4 to use GNU extensions. I suspect this is the same on other *BSD operating system. I also change m4 to gm4, which is the named used by FreeBSB's port system for GNU m4. This also seems to give the correct processing.
[Bug c++/120123] [12/13/14/15/16 Regression] Implicit this is not used in a requires clause in nested lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120123 --- Comment #7 from GCC Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:a0364f41a8a5c9f785da8681c78d22c430ac4d70 commit r16-1035-ga0364f41a8a5c9f785da8681c78d22c430ac4d70 Author: Jason Merrill Date: Sat May 31 23:10:44 2025 -0400 c++: rename PR120123 test As Patrick points out (and I had realized after pushing it), this testcase has nothing to do with explicit object parameters. PR c++/120123 gcc/testsuite/ChangeLog: * g++.dg/cpp23/explicit-obj-lambda18.C: Move to... * g++.dg/cpp2a/concepts-lambda24.C: ...here.
[Bug fortran/120483] [15/16 Regression] character(len=:), allocatable, save variable returns incorrect substring since r15-2131
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120483
--- Comment #4 from Thomas Koenig ---
Looking at
$ cat save.f90
program memain
implicit none
character(len=:), allocatable, save :: s1
s1 = 'ABC'
if (s1(3:3) /= 'C') stop 1
end program memain
$ cat nosave.f90
program memain
implicit none
character(len=:), allocatable :: s1
s1 = 'ABC'
if (s1(3:3) /= 'C') stop 1
end program memain
the diff of the .original dumps is
--- save.f90.006t.original 2025-05-31 18:03:56.345527407 +0200
+++ nosave.f90.006t.original2025-05-31 18:04:01.699589312 +0200
@@ -1,9 +1,10 @@
__attribute__((fn spec (". ")))
void memain ()
{
- static integer(kind=8) _F.s1;
- static character(kind=1) * s1 = 0B;
+ integer(kind=8) .s1;
+ character(kind=1)[1:.s1] * s1;
+ s1 = 0B;
{
integer(kind=8) D.4669;
void * D.4670;
@@ -11,14 +12,14 @@
integer(kind=8) D.4672;
if (s1 != 0B) goto L.1;
-s1 = (character(kind=1) *) __builtin_malloc (3);
+s1 = (character(kind=1)[1:.s1] *) __builtin_malloc (3);
goto L.2;
L.1:;
-if (_F.s1 == 3) goto L.2;
-s1 = (character(kind=1) *) __builtin_realloc ((void *) s1, 3);
+if (.s1 == 3) goto L.2;
+s1 = (character(kind=1)[1:.s1] *) __builtin_realloc ((void *) s1, 3);
L.2:;
-_F.s1 = 3;
-D.4669 = _F.s1;
+.s1 = 3;
+D.4669 = .s1;
D.4670 = (void *) s1;
D.4671 = (void *) &"ABC"[1]{lb: 1 sz: 1};
D.4672 = NON_LVALUE_EXPR + -3;
@@ -35,7 +36,7 @@
}
}
}
- if (*s1 != 67)
+ if ((*s1)[3]{lb: 1 sz: 1} != 67)
{
_gfortran_stop_numeric (1, 0);
}
it seems an uninitialized length is still used for the nosave variant
(which also looks suspicious) and the save case lacks the addition of
the offset of the string.
[Bug c++/118074] [coroutine] Initialize return value before destruction of coroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118074 --- Comment #10 from Iain Sandoe --- (In reply to Weibo He from comment #9) > Thank you for your work. I noticed the heap-use-after-free issue might still > be present? > > https://godbolt.org/z/79bvTfWe5 I think this is because the design of that coroutine is such that the body has completed before it returns to the ramp (and therefore the original caller). This means that the promise has been destroyed (along with argument copies and the coroutine state frame). Recognised to be an unfortunate "gotcha" since there is no reliable way to determine that this has happened. There is an additional provision in the reworded CWG2563 that extends the lifetime of the promise until the return to the ramp - which we will implement (hopefully soon).
[Bug fortran/120355] [15 Regression] Type mismatch for passed external function, if external function appears in the same source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120355 Thomas Koenig changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Thomas Koenig --- Fixed on all affected branches. Thanks a lot for the bug report!
[Bug fortran/119948] Source allocation of pure function result rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119948 --- Comment #21 from Jerry DeLisle --- (In reply to Damian Rouson from comment #20) > Should this issue be marked as resolved? If so, can the fix be back ported > to the 15 branch? I think it is resolved. It could be backported. Paul if you are short on time I can do it.
[Bug rtl-optimization/81501] mulitple calls to __tls_get_addr() with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81501 Sam James changed: What|Removed |Added Keywords||patch --- Comment #12 from Sam James --- https://inbox.sourceware.org/gcc-patches/CAMe9rOqp-_2DFXbmAnWhxOA=KEpFme6o3APLcuj5M=tyz-s...@mail.gmail.com/
[Bug tree-optimization/120357] [14/15/16 Regression] ICE in vect "error: definition in block 9 does not dominate use in block 3" with early break
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120357 --- Comment #10 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:dce4da51ab66c3abb84448326910cd42f6fe2499 commit r16-1027-gdce4da51ab66c3abb84448326910cd42f6fe2499 Author: Richard Biener Date: Fri May 30 14:11:47 2025 +0200 tree-optimization/120357 - ICE with early break vectorization When doing early break vectorization of a loop with a conditional reduction the epilog creation code is confused as to before which exit to insert the conditional reduction induction IV update. The following make sure this is done before the main IV exit. PR tree-optimization/120357 * tree-vect-loop.cc (vect_create_epilog_for_reduction): Create the conditional reduction induction IV increment before the main IV exit. * gcc.dg/vect/vect-early-break_136-pr120357.c: New testcase.
[Bug fortran/120483] [15/16 Regression] character(len=:), allocatable, save variable returns incorrect substring since r15-2131
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120483 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug other/120493] 2 different functions to get call RTX from CALL_INSN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120493 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Keywords||internal-improvement Last reconfirmed||2025-05-31 --- Comment #1 from Richard Biener --- At least the more specific one receiving a rtx_call_insn could be called from the other.
[Bug ada/120496] adaint.h:324:8: error: unknown type name 'cpu_set_t'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120496 --- Comment #3 from Dennis Clarke --- I will create an AMD64 machine with the same ( or similar ) software config and begin testing there. I think more data is required cross platform.
[Bug modula2/120497] An error is generated when returning a var variable which is a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120497 Gaius Mulley changed: What|Removed |Added Last reconfirmed||2025-05-31 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from Gaius Mulley --- Confirmed.
[Bug modula2/120497] New: An error is generated when returning a var variable which is a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120497 Bug ID: 120497 Summary: An error is generated when returning a var variable which is a pointer Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: gaius at gcc dot gnu.org Target Milestone: --- The following code causes fails to compile: $ gm2 -c ReturnType2.mod ReturnType2.mod:9:11: error: the return type 'bar' used in procedure 'foo' 9 | PROCEDURE foo (VAR value: bar) : bar ; | ^~~ ReturnType2.mod:11:4: error: is incompatible with the returned expression 'foo' 11 |RETURN value |^~~~ $ cat ReturnType2.mod MODULE ReturnType2 ; TYPE bar = POINTER TO RECORD field: CARDINAL ; END ; PROCEDURE foo (VAR value: bar) : bar ; BEGIN RETURN value END foo ; VAR b: bar ; BEGIN b := NIL ; b := foo (b) END ReturnType2.
[Bug c++/120498] New: error: either all initializer clauses should be designated or none of them should be when designated-initialising nested union members(?) (same code accepted as C)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120498
Bug ID: 120498
Summary: error: either all initializer clauses should be
designated or none of them should be when
designated-initialising nested union members(?) (same
code accepted as C)
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nabijaczleweli at nabijaczleweli dot xyz
Target Milestone: ---
Real code:
static jmp_buf sigbussy;
struct sigaction sa{.sa_flags = static_cast(SA_RESETHAND), .sa_handler =
[](int) { longjmp(sigbussy, true); }};
Extracted:
#include
struct sigaction sa = {.sa_flags = SA_RESETHAND, .sa_handler = 0};
Reduced:
struct sa {
int sa_flags;
union {
int sa_handler, b;
} u;
};
struct sa sa = {.sa_flags = 0, .u.sa_handler = 0};
g++ -std=c++20 fails to compile this with
:7:32: error: either all initializer clauses should be designated or
none of them should be
7 | struct sa sa = {.sa_flags = 0, .u.sa_handler = 0};
|^
:7:32: error: expected primary-expression before '.' token
Compiler returned: 1
gcc accepts this directly. Repro on 12.2.0, 14.2.0,
Compiler-Explorer-Build-gcc-c7df2b7d4380ade4caf8af4de8d3407d7d523a2f-binutils-2.42)
16.0.0 20250531 (experimental). Probably earlier ones too.
(You can drop the .sa_flags initialiser to get a slightly different error.)
Clang accepts this always. Somehow I feel like GCC-in-C++ mode is wrong to
reject it here.
[Bug c++/120498] error: either all initializer clauses should be designated or none of them should be when designated-initialising nested union members(?) (same code accepted as C)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120498
--- Comment #1 from Andrew Pinski ---
clang does throw a -pedantic-error though:
:8:34: error: nested designators are a C99 extension
[-Werror,-Wc99-designator]
8 | struct sa sa = {.sa_flags = 0, .u.sa_handler = 0};
| ^
[Bug ada/120463] Pb Doubled linked List
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120463
--- Comment #3 from Dubois ---
Hello,
in fact all the files are in *.zip file but it seems it cannot be
seen from the site..
Anyway, the answer is below.
-I wrote the bug was linked to doubly_linked_lists.
But now, it seems me that the root cause is more on bounded_string
with the same problem on unbounded.
Goog luck to track the bug.
BR
=
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-linux-gnu/13/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
13.3.0-6ubuntu2~24.04'
--with-bugurl=file:///usr/share/doc/gcc-13/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-13
--program-prefix=x86_64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/libexec
--without-included-gettext --enable-threads=posix --libdir=/usr/lib
--enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-libstdcxx-backtrace
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-13-fG75Ri/gcc-13-13.3.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-13-fG75Ri/gcc-13-13.3.0/debian/tmp-gcn/usr
--enable-offload-defaulted --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.3.0 (Ubuntu 13.3.0-6ubuntu2~24.04)
dubois@PC:~$
"the command line passed to the compiler (pass -v to GPRbuild)"
$ cat compile.sh
$ cat checkpres.gpr
# - Compilation de checkpres 24.03.2025
#
echo ---
echo Compilation de checkpres
echo ---
#
gprbuild -P checkpres.gpr
#
-- Checkpres 24.05.2025
with
"/media/4To/Donnees/Courrier/020-Ada/X-Bibliotheque/gtkada_25.0.1_d3787772/src/gtkada.gpr";
Project Checkpres is -- pas de "-" dans le nom de projet.
for Languages use ("Ada");
for Main use ("checkpres.adb"); -- Préciser [adb, ads].
Build_Switches := ();
-- Variable "Chemin"
Chemin :=
"/media/4To/Donnees/Courrier/020-Ada/M-Sources/110-Utilitaires/130-Bureautique/015-HTML/G1R8/G1R8_1/";
--'/' à la fin.
-- SOURCES, bibliotheques / ObjAli / Exec
Chemin_src := Chemin & "A-src/**"; --avec ss-répert.
Chemin_release := Chemin & "B-objali/";
Chemin_exec := Chemin & "Z-exec/";
for Source_Dirs use (Chemin_src);
for Object_Dir use Chemin_release;
for Exec_Dir use Chemin_exec;
-- Paramètres du BUILDER
Build_Switches := ("-O2");
-- Options de COMPILATIONS
package Compiler is
for Default_Switches ("Ada")
use ("-g", "-O0", "-gnata", "-gnatwa", "-gnatiw",
"-gnatW8", "-gnat2022", "-fPIE") & Build_Switches;
--COMPILER_SWITCHES_PLACEHOLDER--
end Compiler;
package Builder is
for Default_Switches ("Ada") use ("-g");
for Executable ("checkpres.adb") use "checkpres"; --pas d'extension
sur fichier cible.
end Builder;
end Checkpres;
Le 31/05/2025 à 18:41, ebotcazou at gcc dot gnu.org a écrit :
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120463
>
> Eric Botcazou changed:
>
> What|Removed |Added
>
> Last reconfirmed||2025-05-31
> Ever confirmed|0 |1
> Status|UNCONFIRMED |WAITING
> CC||ebotcazou at gcc dot gnu.org
>
> --- Comment #2 from Eric Botcazou ---
>> No more comment.. You've [Gnat, GCC] version & original files.., you should
>> be able to reproduce this strange bug.
> Nope, please post the configure line of the compiler (as shown by `gcc -v`)
> and
> the command line passed to the compiler (pass -v to GPRbuild).
>
[Bug modula2/120497] An error is generated when returning a var variable which is a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120497 --- Comment #2 from Gaius Mulley --- Created attachment 61557 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61557&action=edit Proposed fix for return type checking. Proposed fix which skips over the lvalue for a VAR variable when being type checked against a return type.
[Bug c++/120498] error: either all initializer clauses should be designated or none of them should be when designated-initialising nested union members(?) (same code accepted as C)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120498 --- Comment #2 from Andrew Pinski --- >Somehow I feel like GCC-in-C++ mode is wrong to reject it here It is not since C++ designated-initialising is not the same as C's.
[Bug c++/120498] error: either all initializer clauses should be designated or none of them should be when designated-initialising nested union members(?) (same code accepted as C)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120498 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #4 from Andrew Pinski --- (In reply to наб from comment #3) > Sure, I build with -Wno-c99-extensions so I didn't really clock it. > > Even if you consider GCC erroring on this instead of warning to be correct > (which I don't think is useful to anyone), the error is meaningless > as-issued. In the original It is correct because GCC's C++ front-end does not support this as an extension. > this indicates that GCC wants... all members of sa? to be initialised? when > this isn't a requirement anywhere else? Actually that is a requirement of C++ designated initializers. C++20 designated initializers is not the same as C99 designated initializers at all and should not be treated the same either. Yes they have a similar syntax but they are not the same. Yes most (I think all) C++20 designated initializers are valid C99 designated initializers yes but not the other way around.
[Bug c++/120498] error: either all initializer clauses should be designated or none of them should be when designated-initialising nested union members(?) (same code accepted as C)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120498
--- Comment #3 from наб ---
Sure, I build with -Wno-c99-extensions so I didn't really clock it.
Even if you consider GCC erroring on this instead of warning to be correct
(which I don't think is useful to anyone), the error is meaningless as-issued.
In the original
a.cpp:5:69: error: either all initializer clauses should be designated or none
of them should be
5 | struct sigaction sa{.sa_flags = static_cast(SA_RESETHAND),
.sa_handler = [](int) { longjmp(sigbussy, true); }};
| ^
a.cpp:5:69: error: expected primary-expression before ‘.’ token
this indicates that GCC wants... all members of sa? to be initialised? when
this isn't a requirement anywhere else?
[Bug c++/120498] error: either all initializer clauses should be designated or none of them should be when designated-initialising nested union members(?) (same code accepted as C)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120498 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=88158 --- Comment #5 from Andrew Pinski --- What I am trying to say GCC's C++ front-end does not implement the extensions that clang implements and I doubt it will ever.
[Bug c++/120498] error: either all initializer clauses should be designated or none of them should be when designated-initialising nested union members(?) (same code accepted as C)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120498 --- Comment #6 from наб --- It already issues `-Wmissing-field-initializers` with `-Wall -Wextra` for sa, the issue at hand, if you decide that this is an error, is that the errors you get aren't helpful.
[Bug rtl-optimization/111901] Apparently bogus CSE of inline asm with memory clobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111901 Uroš Bizjak changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|ubizjak at gmail dot com |unassigned at gcc dot gnu.org --- Comment #17 from Uroš Bizjak --- (In reply to Richard Sandiford from comment #14) > ISTM that the problem is that cselib doesn't consider: I will leave this cselib PR to Richard.
[Bug c/47409] volatile struct member bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47409 uecker at gcc dot gnu.org changed: What|Removed |Added CC||uecker at gcc dot gnu.org --- Comment #28 from uecker at gcc dot gnu.org --- >From a C standard side I think this is not clear. Usually for qualifiers what matters is the qualifier of the lvalue used for the access, and the access does not use the qualifier. But then accessing an object declared volatile (or const) using an access without the qualifier is UB, and one can reasonably assume that this rule also applies to fields. It seems for atomic we do not have such a rule. For const we forbid structure assignments of structures with const members. This would correspond to the idea that a structure assignment is basically composed of member assignments. For volatile and atomic we do not do this though. I am also not entirely sure what would be the most useful behavior.
[Bug fortran/120483] [15/16 Regression] character(len=:), allocatable, save variable returns incorrect substring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120483 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org Keywords||wrong-code Target Milestone|--- |15.2 Ever confirmed|0 |1 Summary|character(len=:), |[15/16 Regression] |allocatable, save variable |character(len=:), |returns incorrect substring |allocatable, save variable ||returns incorrect substring Known to work||14.3.0 Last reconfirmed||2025-05-31 Known to fail||15.1.0, 16.0 Status|UNCONFIRMED |NEW --- Comment #1 from Thomas Koenig --- Confirmed, also with recent trunk. gfortran 14.3 also works.
[Bug c++/120123] [12/13/14/15/16 Regression] Implicit this is not used in a requires clause in nested lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120123 --- Comment #6 from Patrick Palka --- N.B. the testcase here is a C++20 one, not related to xobj lambdas.
[Bug fortran/120483] [15/16 Regression] character(len=:), allocatable, save variable returns incorrect substring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120483 Thomas Koenig changed: What|Removed |Added CC||vehre at gcc dot gnu.org --- Comment #2 from Thomas Koenig --- Running a bisection gives 0231b076dc98eb02e3289b21ace1757782e3917b is the first bad commit commit 0231b076dc98eb02e3289b21ace1757782e3917b Author: Andre Vehreschild Date: Wed Jul 10 14:37:37 2024 +0200 Andre, could you take a look?
[Bug ada/120463] Pb Doubled linked List
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120463 Eric Botcazou changed: What|Removed |Added Last reconfirmed||2025-05-31 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING CC||ebotcazou at gcc dot gnu.org --- Comment #2 from Eric Botcazou --- > No more comment.. You've [Gnat, GCC] version & original files.., you should > be able to reproduce this strange bug. Nope, please post the configure line of the compiler (as shown by `gcc -v`) and the command line passed to the compiler (pass -v to GPRbuild).
[Bug ada/120496] libada does not build with non-canonical libc on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120496 Eric Botcazou changed: What|Removed |Added Summary|adaint.h:324:8: error: |libada does not build with |unknown type name |non-canonical libc on Linux |'cpu_set_t' | Ever confirmed|0 |1 Last reconfirmed||2025-05-31 Status|UNCONFIRMED |NEW CC||ebotcazou at gcc dot gnu.org Severity|normal |enhancement --- Comment #5 from Eric Botcazou --- As shown in the log, that's not the compiler build itself but the library build, so it very likely needs to be ported to the non-canonical libc.
[Bug ada/120496] adaint.h:324:8: error: unknown type name 'cpu_set_t'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120496 --- Comment #1 from Sam James --- There's a bunch of porting required to get GNAT working on musl. I may work on it this stage1.
[Bug fortran/120483] [15/16 Regression] character(len=:), allocatable, save variable returns incorrect substring since r15-2131
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120483 Thomas Koenig changed: What|Removed |Added Summary|[15/16 Regression] |[15/16 Regression] |character(len=:), |character(len=:), |allocatable, save variable |allocatable, save variable |returns incorrect substring |returns incorrect substring ||since r15-2131 --- Comment #3 from Thomas Koenig --- r15-2131-g0231b076dc98eb02e3289b21ace1757782e3917b (to make it easier to find).
[Bug fortran/120049] ICE when using IS_C_ASSOCIATED ()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120049 --- Comment #39 from GCC Commits --- The releases/gcc-15 branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:41dee7da08873721a719849d19ef07c027e76dfb commit r15-9749-g41dee7da08873721a719849d19ef07c027e76dfb Author: Jerry DeLisle Date: Mon May 19 19:41:16 2025 -0700 Fortran: Fix c_associated argument checks. PR fortran/120049 gcc/fortran/ChangeLog: * check.cc (gfc_check_c_associated): Use new helper functions. Only call check_c_ptr_1 if optional c_ptr_2 tests succeed. (check_c_ptr_1): Handle only c_ptr_1 checks. (check_c_ptr_2): Expand checks for c_ptr_2 and handle cases where there is no derived pointer in the gfc_expr and check the inmod_sym_id only if it exists. Rephrase error message. * misc.cc (gfc_typename): Handle the case for BT_VOID rather than throw an internal error. gcc/testsuite/ChangeLog: * gfortran.dg/pr120049_a.f90: Update test directives. * gfortran.dg/pr120049_b.f90: Update test directives * gfortran.dg/pr120049_2.f90: New test. * gfortran.dg/c_f_pointer_tests_6.f90: Adjust dg-error directive. Co-Authored-By: Steve Kargl (cherry picked from commit 42983ffde6612b7f8a4e7ab3e76fa8b0d136e854)
[Bug fortran/120049] ICE when using IS_C_ASSOCIATED ()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120049 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #40 from Jerry DeLisle --- Fixed on 16 and 15 for now. Closing
[Bug c++/120495] New: error: non-template type 'coroutine_handle' used as a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120495
Bug ID: 120495
Summary: error: non-template type 'coroutine_handle' used as a
template
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
This code fails to compile:
(https://godbolt.org/z/jc3cnvacz)
```
#include
#include
struct fire_and_forget {};
template
struct std::coroutine_traits
{
struct promise_type
{
fire_and_forget get_return_object() const noexcept
{
return{};
}
void return_void() const noexcept
{
}
suspend_never initial_suspend() const noexcept
{
return{};
}
suspend_never final_suspend() const noexcept
{
return{};
}
void unhandled_exception() const noexcept
{
std::terminate();
}
};
};
struct foo
{
fire_and_forget bar()
{
co_await std::suspend_always{ };
}
private:
// comment out line below to fix error
using coroutine_handle = std::coroutine_handle<>;
};
int main()
{
foo{}.bar();
}
```
```
: In member function 'fire_and_forget foo::bar()':
:41:39: error: non-template type 'coroutine_handle' used as a template
41 | co_await std::suspend_always{ };
| ^
:41:9: error: cannot instantiate a 'coroutine handle' for promise type
'void'
41 | co_await std::suspend_always{ };
| ^~~~
:42:5: error: non-template type 'coroutine_handle' used as a template
42 | }
| ^
:39:21: error: cannot instantiate a 'coroutine handle' for promise type
'void'
39 | fire_and_forget bar()
| ^~~
```
Downstream reports:
[1] https://github.com/msys2/MINGW-packages/issues/24209
[2] https://github.com/microsoft/cppwinrt/issues/1490
[Bug c++/115908] [coroutines] Wrong behavior of using get_return_object() when creating coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115908 Iain Sandoe changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Status|WAITING |ASSIGNED URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2025-May/685 ||247.html --- Comment #11 from Iain Sandoe --- patch posted - that extends the lifetime of the promise so that it can be used to initialise the ramp return.
[Bug c++/115908] [coroutines] Wrong behavior of using get_return_object() when creating coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115908 --- Comment #12 from Iain Sandoe --- (In reply to Iain Sandoe from comment #10) > my understanding is that the conclusion of CWG2563 is that this behaviour > was not the intended design - and the resolution to this is in PR119916. > > (so that, unless there's new information, this bug would be closed as > INVALID). since I made this comment - there has been another small adjustment to the resolution for CWG2563 that allows the promise to be used to initialise the ramp return.
[Bug ada/120496] New: adaint.h:324:8: error: unknown type name 'cpu_set_t'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120496 Bug ID: 120496 Summary: adaint.h:324:8: error: unknown type name 'cpu_set_t' Product: gcc Version: 15.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: dclarke at blastwave dot org CC: dkm at gcc dot gnu.org Target Milestone: --- This is fairly consistent and repeatable. With Alpine Linux and MUSL LibC on a Raspberry Pi5 we may configure just fine thus : admsys@hermes$ uname -a Linux hermes.bw.genunix.com 6.12.13-0-rpi #1-Alpine SMP PREEMPT Thu Feb 13 22:15:47 UTC 2025 aarch64 Linux admsys@hermes$ which ldd /usr/bin/ldd admsys@hermes$ ldd --version musl libc (aarch64) Version 1.2.5 Dynamic Program Loader Usage: /lib/ld-musl-aarch64.so.1 [options] [--] pathname admsys@hermes$ admsys@hermes$ which gcc /usr/bin/gcc admsys@hermes$ gcc --version gcc (Alpine 14.2.0) 14.2.0 Copyright (C) 2024 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. admsys@hermes$ hermes$ ../gcc-15.1.0/configure --prefix=/opt/bw/imed/gcc15 \ > --mandir=/opt/bw/imed/gcc15/share/man \ > --infodir=/opt/bw/imed/gcc15/share/info \ > --build=aarch64-alpine-linux-musl \ > --host=aarch64-alpine-linux-musl \ > --target=aarch64-alpine-linux-musl \ > --with-gnu-as --with-as=/opt/bw/imed/bin/as \ > --with-gnu-ld --with-ld=/opt/bw/imed/bin/ld \ > --disable-cet --disable-fixed-point --disable-libstdcxx-pch \ > --disable-multilib --disable-nls --disable-werror \ > --disable-symvers --enable-__cxa_atexit --enable-default-pie \ > --enable-default-ssp \ > --enable-languages=ada,c,c++,fortran,go,lto,objc,obj-c++ \ > --enable-stage1-languages=c,c++ \ > --enable-link-serialization=2 --enable-linker-build-id \ > --with-arch=armv8-a --with-tune=cortex-a76 \ > --with-abi=lp64 --disable-libquadmath --disable-libssp \ > --disable-libsanitizer --enable-shared \ > --enable-threads=posix --enable-tls --with-system-zlib \ > --with-linker-hash-style=gnu \ > --with-build-time-tools=/opt/bw/imed/bin \ > --enable-bootstrap \ > --with-default-libstdcxx-abi=new \ > --enable-compressed-debug-sections=none \ > --enable-libada --enable-lto \ > --disable-isl-version-check \ > --enable-host-pie --enable-gnu-unique-object \ > --enable-default-pie \ > --enable-stage1-checking=misc \ > --enable-checking=misc \ > --with-pkgversion='GENUNIX Fri May 30 20:08:20 UTC 2025' checking build system type... aarch64-alpine-linux-musl checking host system type... aarch64-alpine-linux-musl checking target system type... aarch64-alpine-linux-musl checking for a BSD-compatible install... /usr/bin/install -c checking whether ln works... yes checking whether ln -s works... yes checking for a sed that does not truncate output... /bin/sed checking for gawk... gawk checking for libatomic support... yes checking for libitm support... yes checking for libvtv support... yes checking for libphobos support... yes checking for libgcobol support... yes checking for aarch64-alpine-linux-musl-gcc... /usr/bin/gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /usr/bin/gcc accepts -g... yes checking for /usr/bin/gcc option to accept ISO C89... none needed checking for /usr/bin/gcc option to accept ISO C99... none needed checking whether we are using the GNU C++ compiler... yes checking whether /usr/bin/g++ accepts -g... yes checking whether g++ accepts -static-libstdc++ -static-libgcc... yes checking for aarch64-alpine-linux-musl-gnatbind... no checking for gnatbind... gnatbind checking for aarch64-alpine-linux-musl-gnatmake... no checking for gnatmake... gnatmake checking whether compiler driver understands Ada and is recent enough... yes checking for aarch64-alpine-linux-musl-gdc... no checking for gdc... no checking whether the D compiler works... no checking for cargo... no checking how to compare bootstrapped objects... cmp $$f1 $$f2 16 16 checking for objdir... .libs configure: WARNING: using in-tree isl, disabling version check checking whether to enable libgdiagnostics... no checking for library containing dlopen... none required checking for library containing pthread_create... none required The following languages will be built: c,ada,c++,fortran,go,lto,objc,obj-c++ *** This configuration is not supported in the following subdirectories: zlib target-libquadmath libgrust target-libgcobol target-libphobos target-zlib target-libgm2 target-libgrust target-libsanitizer target-libssp (Any other directories should still work fine.) checking for default BUILD_CONFIG...
[Bug libstdc++/104928] std::counting_semaphore on Linux can sleep forever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104928
--- Comment #17 from Jonathan Wakely ---
Using _S_do_try_acquire as the predicate for __atomic_wait_address is wrong,
because it can fail for two reasons: __old == 0, meaning we can't acquire the
semaphore and need to do an atomic wait, or because the compare_exchange fails
because another thread changed the counter concurrently. In the latter case we
just want to retry the compare_exchange, *not* wait for it to change (because
it might never change).
We should only wait when the counter is zero.
--- a/libstdc++-v3/include/bits/semaphore_base.h
+++ b/libstdc++-v3/include/bits/semaphore_base.h
@@ -71,7 +71,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
static _GLIBCXX_ALWAYS_INLINE bool
-_S_do_try_acquire(__count_type* __counter, __count_type __old) noexcept
+_S_do_try_acquire(__count_type* __counter, __count_type& __old) noexcept
{
if (__old == 0)
return false;
@@ -82,14 +82,24 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
memory_order::relaxed);
}
-_GLIBCXX_ALWAYS_INLINE void
+void
_M_acquire() noexcept
{
auto const __vfn = [this]{ return _S_get_current(&this->_M_counter); };
- auto const __pred = [this](__count_type __cur) {
- return _S_do_try_acquire(&this->_M_counter, __cur);
+ auto __val = __vfn();
+ auto const __pred = [&__val](__count_type __cur) {
+ if (__cur > 0)
+ {
+ __val = __cur;
+ return true;
+ }
+ return false;
};
- std::__atomic_wait_address(&_M_counter, __pred, __vfn, true);
+ while (!_S_do_try_acquire(&_M_counter, __val))
+ {
+ if (__val == 0)
+ std::__atomic_wait_address(&_M_counter, __pred, __vfn, true);
+ }
}
bool
This changes __semaphore_base::_M_acquire to try the compare_exchange in a
loop, only waiting when the value is zero. The predicate for the atomic wait is
now that the value is positive, so that we don't wait after a compare_exchange
that fails due to contention (the predicate and _S_do_try_acquire also update
the local variable so that we don't need to load it again).
Similar changes are needed to _M_try_acquire, _M_try_acquire_until, and
_M_try_acquire_for, but I'll do that on Monday.
It can also be simplified to use __atomic_wait_address_v for the case where
__count_type is__platform_wait_t, but that can be done separately.
[Bug fortran/119948] Source allocation of pure function result rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119948 --- Comment #20 from Damian Rouson --- Should this issue be marked as resolved? If so, can the fix be back ported to the 15 branch?
[Bug c++/118074] [coroutine] Initialize return value before destruction of coroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118074 Iain Sandoe changed: What|Removed |Added Status|WAITING |ASSIGNED Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2025-May/685 ||247.html --- Comment #11 from Iain Sandoe --- patch posted
[Bug c++/120499] New: import std: indirect use of an exported class using a vector yields undefined symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120499
Bug ID: 120499
Summary: import std: indirect use of an exported class using a
vector yields undefined symbol
Product: gcc
Version: 15.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nico at josuttis dot de
Target Milestone: ---
* Module file:
export module Coll;
import std;
export class Coll {
std::vector vals;
};
export Coll createColl() {
return Coll{};
}
* main file:
import std;
import Coll;
int main()
{
auto coll = createColl();
}
Yields into:
/cygdrive/p/gcc/gcc151/bin/g++151 --std=c++23 -O2 -Wall -Wextra -fmodules
-fsearch-include-path -fmodules -fsearch-include-path bits/std.cc -xc++
collmod.cppm testcoll.cpp -o collmodraw.exe
/bin/ld:
/cygdrive/c/Users/nico2/AppData/Local/Temp/ccSwGTq6.o:testcoll.cpp:(.text.startup+0x31):
undefined reference to `_ZNSt12_Vector_baseIiSaIiEE12_Vector_implD1Ev'
collect2: error: ld returned 1 exit status
Module std built with:
/cygdrive/p/gcc/gcc151/bin/g++151 --std=c++23 -O2 -Wall -Wextra -fmodules
-fsearch-include-path -fmodule-only -c bits/std.cc
