[Bug c/119649] New: internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in create_tmp_from_val, at gimplify.cc:621
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119649
Bug ID: 119649
Summary: internal compiler error: tree check: expected class
'type', have 'exceptional' (error_mark) in
create_tmp_from_val, at gimplify.cc:621
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: xieym3 at zohomail dot com
Target Milestone: ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=/data/xieym/work-f4/install/gcc-14.2.0/bin/gcc
COLLECT_LTO_WRAPPER=/data/xieym/work-f4/install/gcc-14.2.0/libexec/gcc/x86_64-pc-linux-gnu/14.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /data/xieym/work-f4/src/gcc-14.2.0/configure --enable-coverage
--enable-checking --disable-multilib --disable-shared --disable-bootstrap
--enable-languages=c,c++ --prefix=/data/xieym/work-f4/install/gcc-14.2.0
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.2.0 (GCC)
$ cat file.c
#include
/
#include
int main(int argc, char const *argv[])
{
int sum, i;
va_list args;
va_start(args, argc);
for (i = 0, sum = 0; i < argc; ++i) {
sum += atoi(va_arg(args, char const *));
}
return 0;
}
$ gcc file.c -o /dev/null
:2:1: error: expected identifier or '(' before '/' token
2 | /
| ^
In file included from :3:
/opt/compiler-explorer/gcc-trunk-20250406/lib/gcc/x86_64-linux-gnu/15.0.1/include/stdarg.h:103:9:
error: unknown type name '__gnuc_va_list'
103 | typedef __gnuc_va_list va_list;
| ^~
: In function 'main':
:8:24: warning: optional second parameter of 'va_start' not last named
argument [-Wvarargs]
8 | va_start(args, argc);
|^~~~
:8:18: error: passing argument 1 of '__builtin_va_start' makes pointer
from integer without a cast [-Wint-conversion]
8 | va_start(args, argc);
| ^~~~
| |
| va_list {aka int}
:8:18: note: expected '__va_list_tag *' but argument is of type
'va_list' {aka 'int'}
:10:42: error: first argument to 'va_arg' not of type 'va_list'
10 | sum += atoi(va_arg(args, char const *));
| ^~~~
:8:9: error: 'va_start' used in function with fixed arguments
8 | va_start(args, argc);
| ^~~~
:10:24: internal compiler error: tree check: expected class 'type',
have 'exceptional' (error_mark) in create_tmp_from_val, at gimplify.cc:621
10 | sum += atoi(va_arg(args, char const *));
|^~~~
0x2600f05 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x2617ed6 internal_error(char const*, ...)
???:0
0x8f3c89 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
???:0
0xdec770 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xdec176 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xdee8ba gimplify_stmt(tree_node**, gimple**)
???:0
0xdebc13 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xdee8ba gimplify_stmt(tree_node**, gimple**)
???:0
0xdebc13 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xdee8ba gimplify_stmt(tree_node**, gimple**)
???:0
0xdec3ba gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xdee8ba gimplify_stmt(tree_node**, gimple**)
???:0
0xdebc13 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xdf4c06 gimplify_body(tree_node*, bool)
???:0
0xdf50cc gimplify_function_tree(tree_node*)
???:0
0xc07bf7 cgraph_node::analyze()
???:0
0xc0af71 symbol_table::finalize_compilation_unit()
???: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 returned: 1
Godbolt Url: https://godbolt.org/z/s948EMjvs
[Bug c/119649] internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in create_tmp_from_val, at gimplify.cc:621
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119649
--- Comment #2 from Xieym ---
The following also has the same crash signature, is it the same reason?
$ cat file.c
void main(){
float x = 1.;
x *= sqrt(x);
char *x ="";
}
Url: https://godbolt.org/z/oradxqaxE
[Bug c/119651] [13/14/15 Regression] internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in tree_nonzero_bits, at fold-const.cc:16702
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119651
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.4
Ever confirmed|0 |1
Summary|internal compiler error:|[13/14/15 Regression]
|tree check: expected class |internal compiler error:
|'type', have 'exceptional' |tree check: expected class
|(error_mark) in |'type', have 'exceptional'
|tree_nonzero_bits, at |(error_mark) in
|fold-const.cc:16702 |tree_nonzero_bits, at
||fold-const.cc:16702
Known to fail||14.2.0
Last reconfirmed||2025-04-06
Status|UNCONFIRMED |NEW
--- Comment #1 from Andrew Pinski ---
Confirmed.
reduced testcase:
```
int f() {
int r;
while (r % 2 == 0) ;
double r;
}
```
[Bug c/119649] internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in create_tmp_from_val, at gimplify.cc:621
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119649 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2025-04-06
[Bug c/119649] internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in create_tmp_from_val, at gimplify.cc:621
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119649
--- Comment #1 from Andrew Pinski ---
Confirmed. Reduced dejagnuified testcase:
```
/* { dg-do compile } */
int f(const char*);
int g(int args, int sum) {
sum +=
f(__builtin_va_arg(args, char const *)); /* { dg-error "first argument to
" } */
}
```
[Bug c/119651] New: internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in tree_nonzero_bits, at fold-const.cc:16702
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119651
Bug ID: 119651
Summary: internal compiler error: tree check: expected class
'type', have 'exceptional' (error_mark) in
tree_nonzero_bits, at fold-const.cc:16702
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: xieym3 at zohomail dot com
Target Milestone: ---
$ cat file.c
int main() {
int r = 0;
while (r % 2 == 0) {
}
double r = (double) sizeof(int);
return 0;
}
$ gcc -v
Using built-in specs.
COLLECT_GCC=/data/xieym/work-f4/install/gcc-14.2.0/bin/gcc
COLLECT_LTO_WRAPPER=/data/xieym/work-f4/install/gcc-14.2.0/libexec/gcc/x86_64-pc-linux-gnu/14.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /data/xieym/work-f4/src/gcc-14.2.0/configure --enable-coverage
--enable-checking --disable-multilib --disable-shared --disable-bootstrap
--enable-languages=c,c++ --prefix=/data/xieym/work-f4/install/gcc-14.2.0
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.2.0 (GCC)
$ gcc -x c file.c -o /dev/null
:7:1: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in tree_nonzero_bits, at fold-const.cc:16702
7 | }
| ^
0x2600f05 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x2617ed6 internal_error(char const*, ...)
???:0
0x8f3c89 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
???:0
0xd2d00a tree_nonzero_bits(tree_node const*)
???:0
0x1a3a941 tree_zero_one_valued_p(tree_node*)
???:0
0x1b967d1 generic_simplify_COND_EXPR(unsigned long, tree_code, tree_node*,
tree_node*, tree_node*, tree_node*)
???:0
0xd4ec3f fold_ternary_loc(unsigned long, tree_code, tree_node*, tree_node*,
tree_node*, tree_node*)
???:0
0xd50fdb fold_build3_loc(unsigned long, tree_code, tree_node*, tree_node*,
tree_node*, tree_node*)
???:0
0xb173d2 c_genericize_control_stmt(tree_node**, int*, void*, tree_node*
(*)(tree_node**, int*, void*), tree_node* (*)(tree_node**, int*, tree_node*
(*)(tree_node**, int*, void*), void*, hash_set >*))
???:0
0x14e1f2c walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0xb17a94 c_genericize_control_stmt(tree_node**, int*, void*, tree_node*
(*)(tree_node**, int*, void*), tree_node* (*)(tree_node**, int*, tree_node*
(*)(tree_node**, int*, void*), void*, hash_set >*))
???:0
0x14e1f2c walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0xb17a94 c_genericize_control_stmt(tree_node**, int*, void*, tree_node*
(*)(tree_node**, int*, void*), tree_node* (*)(tree_node**, int*, tree_node*
(*)(tree_node**, int*, void*), void*, hash_set >*))
???:0
0x14e1f2c walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0xb15b82 c_genericize(tree_node*)
???:0
0xa16050 finish_function(unsigned long)
???:0
0xab19fe c_parse_file()
???:0
0xb308b9 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
GodBolt Url: https://godbolt.org/z/Gadr6rvY6
[Bug libitm/119648] Alpha cross-compile yields header issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119648 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2025-04-06 Status|UNCONFIRMED |WAITING --- Comment #2 from Andrew Pinski --- How did you configure gcc? How are you invoking make? What you have provided is not enough information to go on. It could also be a glibc issue too ... How did you build glibc?
[Bug c++/119652] New: constinit empty direct-list-initialization incorrectly rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119652
Bug ID: 119652
Summary: constinit empty direct-list-initialization incorrectly
rejected
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
struct __shared_count {
constexpr __shared_count() {}
~__shared_count();
int _M_pi = 0;
};
struct shared_ptr {
__shared_count _M_refcount;
};
struct A {
A() = default;
shared_ptr m;
};
constinit A a{};
:13:13: error: ‘constinit’ variable ‘a’ does not have a constant
initializer
:13:15: error: temporary of non-literal type ‘A’ in a constant
expression
:9:8: note: ‘A’ is not literal because:
:11:14: note: non-static data member ‘A::m’ has non-literal type
:6:8: note: ‘shared_ptr’ is not literal because:
:6:8: note: ‘shared_ptr’ does not have ‘constexpr’ destructor
[Bug c++/119652] [14/15 Regression] constinit empty direct-list-initialization incorrectly rejected since r14-660
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119652
Patrick Palka changed:
What|Removed |Added
Known to fail||14.2.0, 15.0
Keywords||rejects-valid
Known to work||13.3.0
Summary|constinit empty |[14/15 Regression]
|direct-list-initialization |constinit empty
|incorrectly rejected|direct-list-initialization
||incorrectly rejected since
||r14-660
Ever confirmed|0 |1
Last reconfirmed||2025-04-06
CC||jason at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Target Milestone|--- |14.3
--- Comment #1 from Patrick Palka ---
Started with r14-660 "c++: be stricter about constinit [CWG2543]"
Reduced from
#include
struct A {
A() = default;
std::shared_ptr m;
};
inline constinit A a{};
[Bug c++/118626] C++20 std::variant causes a segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118626 Patrick Palka changed: What|Removed |Added Target Milestone|16.0|15.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #13 from Patrick Palka --- Fixed for GCC 15, thanks for the report.
[Bug c/119653] New: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119653 Bug ID: 119653 Summary: internal compiler error: Segmentation fault Product: gcc Version: 14.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: xieym3 at zohomail dot com Target Milestone: --- $ cat file.c #define _VARGS_N_ARGS(first, second, third, __VA_ARGS__,...) $ gcc -v Using built-in specs. COLLECT_GCC=/data/xieym/work-f4/install/gcc-14.2.0/bin/gcc COLLECT_LTO_WRAPPER=/data/xieym/work-f4/install/gcc-14.2.0/libexec/gcc/x86_64-pc-linux-gnu/14.2.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /data/xieym/work-f4/src/gcc-14.2.0/configure --enable-coverage --enable-checking --disable-multilib --disable-shared --disable-bootstrap --enable-languages=c,c++ --prefix=/data/xieym/work-f4/install/gcc-14.2.0 Thread model: posix Supported LTO compression algorithms: zlib gcc version 14.2.0 (GCC) $ gcc file.c -o /dev/null :1: internal compiler error: Segmentation fault 1 | #define _VARGS_N_ARGS(first, second, third, __VA_ARGS__,...) 0x2600f05 diagnostic_context::diagnostic_impl(rich_location*, diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag (*) [1], diagnostic_t) ???:0 0x2617ed6 internal_error(char const*, ...) ???:0 0x26b358e _cpp_create_definition ???:0 0x2693398 _cpp_handle_directive ???:0 0x26aa1c8 _cpp_lex_token ???:0 0xb1bc5a c_lex_with_flags(tree_node**, unsigned long*, unsigned char*, int) ???:0 0xab1859 c_parse_file() ???:0 0xb308b9 c_common_parse_file() ???:0 Please submit a full bug report, with preprocessed source (by using -freport-bug). Godbold Url: https://godbolt.org/z/Wqdbfs5d6
[Bug cobol/119632] section segments (cobol85) not implemented, "ignored" -> raising compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119632 Iain Sandoe changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #1 from Iain Sandoe --- Created attachment 61021 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61021&action=edit Patch to diagnose missing SECTION support instead of "sorry-ing" This avoids the sorry and gives a diagnostic. It also tries to quote the missing or unsupported section name to make it clearer.
[Bug cobol/119632] section segments (cobol85) not implemented, "ignored" -> raising compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119632 Iain Sandoe changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Target Milestone|--- |15.0 Last reconfirmed||2025-04-06 Keywords||diagnostic
[Bug target/119626] On aarch64, use the bfcvt instruction to cast to __bf16 when target supports it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119626
--- Comment #6 from mcccs at gmx dot com ---
Lastly I would like to mention why this is such an important issue in the use
__bf16 and why __bf16 is otherwise very inefficient: bfcvt is not only used for
casts. Consider the following code:
__bf16 a[4];
void multiply() {
for (int i = 0; i < 4; i++)
a[i] *= 16;
}
It does involve the bfcvt instruction.
The function compiles to:
Clang O3 -bf16: 13 instructions
Clang O3 +bf16: 8 instructions
GCC O3 +bf16: 43 instructions
It seems there are two parts to solving the problem. By comparing with Clang,
first is to ensure
__bf16 convert(float x) {
return (__bf16) x;
}
uses bfcvt
the second is to ensure
void convert2(float * __restrict a, __bf16 * __restrict x) {
for (int i = 0; i < 4; i++)
x[i] = (__bf16)a[i];
}
can be vectorized even with march=...-bf16
[Bug modula2/119650] WriteString for String
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119650 Gaius Mulley changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2025-04-06 Version|15.0|unknown --- Comment #1 from Gaius Mulley --- Assigned. It is an enhancement and probably should go in during stage 1 of gcc-16.
[Bug cobol/119364] building a cobol cross compiler on i686-linux-gnu targeting x86_64-linux-gnu fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119364 --- Comment #8 from Matthias Klose --- the patch in comment 7 works for me, also building the libgcobol library successfully.
[Bug libitm/119648] New: Alpha cross-compile yields header issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119648 Bug ID: 119648 Summary: Alpha cross-compile yields header issues Product: gcc Version: 14.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libitm Assignee: unassigned at gcc dot gnu.org Reporter: chandleg at wizardsworks dot org Target Milestone: --- [INFO ] Installing core C gcc compiler: done in 112.67s (at 08:25) [INFO ] = [INFO ] Installing C library [INFO ]= [INFO ]Building for multilib 1/1: '' [EXTRA] Configuring C library [EXTRA] Building C library [EXTRA] Installing C library [INFO ]Building for multilib 1/1: '': done in 57.49s (at 09:23) [INFO ] Installing C library: done in 57.53s (at 09:23) [INFO ] = [INFO ] Installing final gcc compiler [EXTRA]Configuring final gcc compiler [EXTRA]Building final gcc compiler [ERROR] /opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm/aatree.h:66:43: error: 'free' was not declared in this scope [ERROR] /opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm/aatree.h:66:43: error: 'free' was not declared in this scope [ERROR] /opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm/aatree.h:66:43: error: 'free' was not declared in this scope [ERROR] /opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm/aatree.h:66:43: error: 'free' was not declared in this scope [ERROR] /opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm/aatree.h:66:43: error: 'free' was not declared in this scope [ERROR] /opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm/dispatch.h:324:42: error: 'free' was not declared in this scope [ERROR] /opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm/dispatch.h:324:42: error: 'free' was not declared in this scope [ERROR] /opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm/aatree.h:66:43: error: 'free' was not declared in this scope [ERROR] /opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm/aatree.h:66:43: error: 'free' was not declared in this scope [ERROR] /opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm/dispatch.h:324:42: error: 'free' was not declared in this scope [ERROR] /opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm/dispatch.h:324:42: error: 'free' was not declared in this scope [ERROR] /opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm/dispatch.h:324:42: error: 'free' was not declared in this scope [ERROR] /opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm/dispatch.h:324:42: error: 'free' was not declared in this scope [ERROR] /opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm/dispatch.h:324:42: error: 'free' was not declared in this scope [ERROR] /opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm/aatree.h:66:43: error: 'free' was not declared in this scope [ERROR] /opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm/alloc_c.cc:36:13: error: 'malloc' was not declared in this scope [ERROR] /opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm/alloc_c.cc:38:38: error: 'free' was not declared in this scope [ERROR] /opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm/alloc_c.cc:46:13: error: 'calloc' was not declared in this scope [ERROR] /opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm/alloc_c.cc:48:38: error: 'free' was not declared in this scope [ERROR] /opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm/alloc_c.cc:57:40: error: 'free' was not declared in this scope [ERROR] /opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm/dispatch.h:324:42: error: 'free' was not declared in this scope [ERROR] /opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm/aatree.h:66:43: error: 'free' was not declared in this scope [ERROR]make[5]: *** [Makefile:682: alloc_c.lo] Error 1 [ERROR]make[5]: *** Waiting for unfinished jobs [ERROR]make[5]: *** [Makefile:682: alloc_cpp.lo] Error 1 [ERROR] /opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm/dispatch.h:324:42: error: 'free' was not declared in this scope [ERROR] /opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm/aatree.h:66:43: error: 'free' was not declared in this scope [ERROR]make[5]: *** [Makefile:682: aatree.lo] Error 1 [ERROR]make[5]: *** [Makefile:682: eh_cpp.lo] Error 1 [ERROR] /opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm/aatree.h:66:43: error: 'free' was not declared in this scope [ERROR]make[5]: *** [Makefile:682: local.lo] Error 1 [ERROR] /opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm/dispatch.h:324:42: error: 'free' was not declared in this scope [ERROR] /opt/cross-build//alph
[Bug libitm/119648] Alpha cross-compile yields header issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119648
--- Comment #1 from Greg Chandler ---
[ALL ]libtool: compile:
/opt/cross-build/alphaev6-unknown-linux-gnu/build/build-cc-gcc-final/./gcc/xg++
-B/opt/cross-build/alphaev6-unknown-linux-gnu/build/build-cc-gcc-final/./gcc/
-nostdinc++ -nostdinc++ -I/opt/cross-build/alphaev6-unknown-linux-gnu/build/bu
ild-cc-gcc-final/alphaev6-unknown-linux-gnu/libstdc++-v3/include/alphaev6-unknown-linux-gnu
-I/opt/cross-build/alphaev6-unknown-linux-gnu/build/build-cc-gcc-final/alphaev6-unknown-linux-gnu/libstdc++-v3/include
-I/opt/cross-build/alphaev6-unknown-linux-gnu/src/gcc/l
ibstdc++-v3/libsupc++
-I/opt/cross-build/alphaev6-unknown-linux-gnu/src/gcc/libstdc++-v3/include/backward
-I/opt/cross-build/alphaev6-unknown-linux-gnu/src/gcc/libstdc++-v3/testsuite/util
-L/opt/cross-build/alphaev6-unknown-linux-gnu/build/build-cc-gcc-final/alphaev
6-unknown-linux-gnu/libstdc++-v3/src
-L/opt/cross-build/alphaev6-unknown-linux-gnu/build/build-cc-gcc-final/alphaev6-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/opt/cross-build/alphaev6-unknown-linux-gnu/build/build-cc-gcc-final/alphaev6-unknown-linux-gnu/libstdc++-
v3/libsupc++/.libs
-B/opt/cross-build/alphaev6-unknown-linux-gnu/build/build-cc-gcc-final/alphaev6-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/opt/cross-build/alphaev6-unknown-linux-gnu/build/build-cc-gcc-final/alphaev6-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/opt/cross-compile/alphaev6-unknown-linux-gnu/alphaev6-unknown-linux-gnu/bin/
-B/opt/cross-compile/alphaev6-unknown-linux-gnu/alphaev6-unknown-linux-gnu/lib/
-isystem
/opt/cross-compile/alphaev6-unknown-linux-gnu/alphaev6-unknown-linux-gnu/include
-isystem /opt/c
ross-compile/alphaev6-unknown-linux-gnu/alphaev6-unknown-linux-gnu/sys-include
-DHAVE_CONFIG_H -I.
-I/opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm
-I/opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm/config/linux/alpha
-I/opt/cross-build//alph
aev6-unknown-linux-gnu/src/gcc/libitm/config/linux
-I/opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm/config/alpha
-I/opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm/config/posix
-I/opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm/con
fig/generic -I/opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm
-ftls-model=initial-exec -Wall -pthread -Werror -std=gnu++0x -funwind-tables
-fno-exceptions -fno-rtti -fabi-version=4 -g -O2 -D_GNU_SOURCE -mieee -g -Os
-MT useraction.lo -MD -MP -MF .deps/us
eraction.Tpo -c
/opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm/useraction.cc
-fPIC -DPIC -o .libs/useraction.o
[ALL ]libtool: compile:
/opt/cross-build/alphaev6-unknown-linux-gnu/build/build-cc-gcc-final/./gcc/xgcc
-B/opt/cross-build/alphaev6-unknown-linux-gnu/build/build-cc-gcc-final/./gcc/
-B/opt/cross-compile/alphaev6-unknown-linux-gnu/alphaev6-unknown-linux-gnu/bin
/
-B/opt/cross-compile/alphaev6-unknown-linux-gnu/alphaev6-unknown-linux-gnu/lib/
-isystem
/opt/cross-compile/alphaev6-unknown-linux-gnu/alphaev6-unknown-linux-gnu/include
-isystem
/opt/cross-compile/alphaev6-unknown-linux-gnu/alphaev6-unknown-linux-gnu/sys-include
-DHAVE_CONFIG_H -I.
-I/opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm
-I/opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm/config/linux/alpha
-I/opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm/config/linux
-I/opt/cross-build//alphaev6
-unknown-linux-gnu/src/gcc/libitm/config/alpha
-I/opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm/config/posix
-I/opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm/config/generic
-I/opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm -ftls
-model=initial-exec -Wall -pthread -Werror -g -O2 -mieee -g -Os -MT sjlj.lo -MD
-MP -MF .deps/sjlj.Tpo -c
/opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm/config/alpha/sjlj.S
-o sjlj.o >/dev/null 2>&1
[ALL ]In file included from
/opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm/libitm_i.h:76,
[ALL ] from
/opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm/alloc_cpp.cc:25:
[ALL ]
/opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm/aatree.h: In static
member function 'static void GTM::aa_node_base::operator delete(void*)':
[ERROR]
/opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm/aatree.h:66:43:
error: 'free' was not declared in this scope
[ALL ] 66 | static void operator delete (void *p) { free (p); }
[ALL ] | ^~~~
[ALL ]
/opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm/aatree.h:1:1: note:
'free' is defined in header ''; this is probably fixable by adding
'#include '
[ALL ] +++ |+#include
[ALL ]1 | /* Copyright (C) 2009-2024 Free Software Foundation, Inc.
[ALL ]In file included from
/opt/cross-build//alphaev6-unknown-linux-gnu/src/gcc/libitm/libitm_i.h:76,
[ALL ] from
/opt/cross-build//alphaev6-u
[Bug target/119626] On aarch64, use the bfcvt instruction to cast to __bf16 when target supports it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119626
--- Comment #5 from mcccs at gmx dot com ---
Sorry for another ping. I did some more research and to make it easier for you
to confirm this issue, we can confirm the expected behavior with clang:
Clang behavior -march=armv9-a+bf16 -O3:
void convert1(int * __restrict a, __bf16 * __restrict x) {
for (int i = 0; i < 4; i++)
x[i] = (__bf16)a[i];
}
void convert2(float * __restrict a, __bf16 * __restrict x) {
for (int i = 0; i < 4; i++)
x[i] = (__bf16)a[i];
}
produces:
convert1(int*, __bf16*):
ldr q0, [x0]
scvtf v0.4s, v0.4s
bfcvtn v0.4h, v0.4s
str d0, [x1]
ret
convert2(float*, __bf16*):
ldr q0, [x0]
bfcvtn v0.4h, v0.4s
str d0, [x1]
ret
whereas with GCC the produced assembly is not only not using bfcvt, it is also
unvectorized. So Clang without `+bf16` can vectorize it but GCC can't. Maybe
this should be split into two separate bugs (one for vectorizing it with
`-bf16` and one for using the bfcvt instruction if `+bf16`).
[Bug cobol/119414] cobol driver unconditionally adds platform-specific command line options.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119414 --- Comment #5 from GCC Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:54932496a8b36a3991f7e533cc3a47ae41148b3e commit r15-9233-g54932496a8b36a3991f7e533cc3a47ae41148b3e Author: Iain Sandoe Date: Mon Mar 24 09:12:47 2025 + cobol, driver: Remove platform-specific options [PR119414]. As discussed in the PR, the options had been added during development to handle specific cases, they are no longer needed (and if they should become necessary, we will need to guard them such that individual platforms get the correct handling). PR cobol/119414 gcc/cobol/ChangeLog: * gcobolspec.cc (append_rdynamic, append_allow_multiple_definition, append_fpic): Remove. (lang_specific_driver): Remove platform-specific command line option handling. Signed-off-by: Iain Sandoe
[Bug cobol/119414] cobol driver unconditionally adds platform-specific command line options.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119414 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Iain Sandoe --- fixed on trunk
[Bug c++/119646] ICE on lix-2.92.0: internal compiler error: in flatten_await_stmt, at cp/coroutines.cc:3136
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119646 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- It is a dup of bug 102217. *** This bug has been marked as a duplicate of bug 102217 ***
[Bug c++/119646] ICE on lix-2.92.0: internal compiler error: in flatten_await_stmt, at cp/coroutines.cc:3136
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119646 --- Comment #2 from Andrew Pinski --- Created attachment 61019 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61019&action=edit Reduced testcase
[Bug c++/102217] co_awaiting a temporary produced by ternary operator crashes (double-free)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102217 Andrew Pinski changed: What|Removed |Added CC||slyfox at gcc dot gnu.org --- Comment #12 from Andrew Pinski --- *** Bug 119646 has been marked as a duplicate of this bug. ***
[Bug c++/102217] co_awaiting a temporary produced by ternary operator crashes (double-free)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102217 --- Comment #13 from Andrew Pinski --- Created attachment 61020 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61020&action=edit Reduced testcase This ICEs.
[Bug modula2/119650] New: WriteString for String
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119650 Bug ID: 119650 Summary: WriteString for String Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: gaius at gcc dot gnu.org Target Milestone: --- Forwarded from the mailing list. It would be useful to have WriteString (s: String) somewhere in the standard libraries. Ie: (* Like Terminal.WriteString, except that it takes a String, not an ARRAY OF CHAR. *) PROCEDURE WriteString (s: String); VAR l, i: CARDINAL; BEGIN l := Length(s); i := 0; WHILE i < l DO Write(char(s, i)); INC (i); END; END WriteString;
[Bug cobol/119595] Port libgcobol to 32-bit architectures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119595 --- Comment #5 from Iain Sandoe --- Very encouraging I put this patch (with obvious amendments) on top of my posted patches for libquadmath support - and then adjusted the sorry in cobol1 (so that it only required float128). x86_64-darwin17 with an m32 multilib: $ ./gcc/gcobol -Bgcc /source/test/hello.cob -o hco -m32 $ ./hco HELLO COBOL WORLD $ file hco hco: Mach-O executable i386 ... the testsuite needs some work ;) === cobol Summary for unix/-m32 === # of expected passes903 # of unexpected failures1728 # of expected failures 6 # of unresolved testcases 834 (nothing stands out as common right now - but probably there are common factors)
[Bug preprocessor/119653] [12/13/14/15 Regression] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119653 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2025-04-06 Keywords||needs-bisection Status|UNCONFIRMED |NEW Target Milestone|--- |12.5 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/119654] New: name lookup after `typename` incorrectly ignores non-type non-namespace names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119654
Bug ID: 119654
Summary: name lookup after `typename` incorrectly ignores
non-type non-namespace names
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
Testcase:
template struct X { typedef int type; };
struct Y { typedef int type; };
void f() {
int X, Y;
X::type x1;
typename X::type x2;
Y::type y;
}
struct Z : X, Y {
int X, Y;
};
void g() {
Z::X::type x1;
typename Z::X::type x2;
Z::Y::type y;
}
Here, every compiler agrees that in both f and g, x1 is ill-formed because `X`
names the int, and y is valid because name lookup for `Y` in `Y::` ignores
names other than types and namespaces.
However, only GCC accepts x2, because GCC appears to apply the "identifier
before ::" name lookup rule to names following `typename` too. Or perhaps it
forms a simple-template-id, then notices the following `::`, then applies the
"identifier before ::" name lookup rule despite a simple-template-id not being
an identifier. That behavior makes some sense, given that the name can only
name a type or namespace in valid code, but it's wrong -- the standard is quite
clear on this, and all other compilers reject.
See [temp.res.general]/3:
> A typename-specifier denotes the type or class template denoted by the
> simple-type-specifier ([dcl.type.simple]) formed by omitting the keyword
> typename.
> [Note 2: The usual qualified name lookup ([basic.lookup.qual]) applies even
> in the presence of typename. — end note]
GCC doesn't diagnose even under `-pedantic-errors`, so I assume this is a bug
rather than an intentional extension.
[Bug tree-optimization/119614] [15 regression] protobuf-29.4 fails to build with -O2 (error: cannot tail-call: call and return value are different)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614 Jakub Jelinek changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||jamborm at gcc dot gnu.org --- Comment #16 from Jakub Jelinek --- Error.constprop.isra body is then in a different partition than the caller with musttail call and for ipa_return_value_range then returns false because ipa_return_value_sum is NULL. So maybe the IPA-VRP workaround only works without LTO? Are any of the IPA properties streamed out so that ltrans has access to those? For tailc it would be great if at least the ipa_return_value_sum ranges (in whatever form) were streamed out and in at least for the callees whose caller is in the particular ltrans.
[Bug tree-optimization/119614] [15 regression] protobuf-29.4 fails to build with -O2 (error: cannot tail-call: call and return value are different)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614 --- Comment #15 from Sam James --- Created attachment 61025 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61025&action=edit generated_message_tctable_lite.cc.ii.xz (LTO) Reduction still going. ``` $ g++ -flto=auto -shared -O3 generated_message_tctable_lite.cc.ii [...] generated_message_tctable_lite.cc.ii: In function ‘MpRepeatedString’: generated_message_tctable_lite.cc.ii:5456:43: error: cannot tail-call: call and return value are different 5456 | [[clang::musttail]] return Error( | ^ generated_message_tctable_lite.cc.ii:5474:43: error: cannot tail-call: call and return value are different 5474 | [[clang::musttail]] return Error( | ^ ```
[Bug fortran/119460] gfortran.dg/reduce_1.f90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119460
--- Comment #20 from Paul Thomas ---
(In reply to anlauf from comment #19)
>
> ! { dg-require-effective-target fortran_real_16 }
>
> in order to prevent new issues popping up... ;-)
I decided to go for real_8 with twice the extent of the 'field' component so
that the scalar result is 32 bytes still.
Thanks for pointing out this option but I think that it might be better to have
issues emerge for systems on which real_16 is not available.
Tschuess
Paul
[Bug tree-optimization/119614] [15 regression] protobuf-29.4 fails to build with -O2 (error: cannot tail-call: call and return value are different)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614 --- Comment #17 from Jakub Jelinek --- Tried compiling the pr119614.C test from my last patch with -O2 -r -flto=2 -flto-partition=max but for some reason that still doesn't force each function to a separate partition.
[Bug tree-optimization/119614] [15 regression] protobuf-29.4 fails to build with -O2 (error: cannot tail-call: call and return value are different)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614 --- Comment #18 from Sam James --- (In reply to Jakub Jelinek from comment #17) > Tried compiling the pr119614.C test from my last patch with -O2 -r -flto=2 > -flto-partition=max but for some reason that still doesn't force each > function to a separate partition. Try g++ -flto -flto-partition=max -O2 -shared on that.
[Bug tree-optimization/119614] [15 regression] protobuf-29.4 fails to build with -O2 (error: cannot tail-call: call and return value are different)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614 --- Comment #19 from Jakub Jelinek --- (In reply to Sam James from comment #18) > (In reply to Jakub Jelinek from comment #17) > > Tried compiling the pr119614.C test from my last patch with -O2 -r -flto=2 > > -flto-partition=max but for some reason that still doesn't force each > > function to a separate partition. > > Try g++ -flto -flto-partition=max -O2 -shared on that. That indeed reproduces it: ./xg++ -B ./ -flto -flto-partition=max -O2 -shared -o pr119614.lo pr119614.C -fdump-tree-all -B ../x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/ lto-wrapper: warning: using serial compilation of 5 LTRANS jobs lto-wrapper: note: see the ‘-flto’ option documentation for more information In function ‘qux’, inlined from ‘qux’ at pr119614.C:19:1: pr119614.C:27:36: error: cannot tail-call: call and return value are different 27 | [[gnu::musttail]] return baz (); |^ lto-wrapper: fatal error: ./xg++ returned 1 exit status compilation terminated. /usr/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status Now, for tailc/musttail particularly, we don't need full return range, all we need is the TREE_CONSTANT retval if the IPA VRP return range is singleton. If I want to preserve it for LTO, would it go into cgraph node and some code in ipa-prop or ipa-vrp would set it, something else?
[Bug c/119660] New: builtin functions erroneously suggested as originating in system headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119660 Bug ID: 119660 Summary: builtin functions erroneously suggested as originating in system headers Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- While investigating an unrelated bug in gcc.dg/Wbuiltin-declaration-mismatch-16.c, I noticed that the output of the compiler included peculiar messages: Relevant line: void __builtin_abort (int[foo]); Output: gcc.dg/Wbuiltin-declaration-mismatch-16.c:5:27: error: 'foo' undeclared here (not in a function) gcc.dg/Wbuiltin-declaration-mismatch-16.c:5:6: warning: conflicting types for built-in function '__builtin_abort'; expected 'void(void)' [-Wbuiltin-declaration-mismatch] gcc.dg/Wbuiltin-declaration-mismatch-16.c:5:6: note: '__builtin_abort' is declared in header '' It seems that under certain conditions, GCC suggests to include a C header file to get the definition of a builtin function. That test tests 4 builtins in various ways. 2 of them exhibit this behavior, the other being __builtin_exit.
[Bug c++/119659] [OpenMP] append_args in iobj member function applies to the wrong paramater
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119659 Sam James changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2025-04-07 Status|UNCONFIRMED |ASSIGNED Keywords||openmp
[Bug ipa/119318] [15 Regression] wrong code with vector arithmetics at -O2 since r15-6294-g96fb71883d438b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119318 Sam James changed: What|Removed |Added Keywords||patch --- Comment #9 from Sam James --- (In reply to Martin Jambor from comment #5) > Created attachment 60939 [details] > Simple fix > > This patch is a simple fix. I'll submit one streaming the necessary type to > the mailing list though in order not to need to fiddle with > expr_type_first_operand_type_p. Thanks, using this one so far (rather than bits from https://inbox.sourceware.org/gcc-patches/cover.1743458148.git.jamb...@gcc.gnu.org/) has been fine with no issues popping up.
[Bug tree-optimization/119614] [15 regression] protobuf-29.4 fails to build with -O2 (error: cannot tail-call: call and return value are different)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614
--- Comment #20 from Jakub Jelinek ---
--- gcc/testsuite/g++.dg/lto/pr119614_0.C.jj2025-04-07 08:44:32.868051786
+0200
+++ gcc/testsuite/g++.dg/lto/pr119614_0.C 2025-04-07 08:44:27.810122315
+0200
@@ -0,0 +1,34 @@
+// PR tree-optimization/119614
+// { dg-lto-do link }
+// { dg-lto-options { { -O2 -fPIC -flto -flto-partition=max } } }
+// { dg-require-effective-target shared }
+// { dg-require-effective-target fpic }
+// { dg-require-effective-target musttail }
+// { dg-extra-ld-options "-shared" }
+
+struct S {} b;
+char *foo ();
+int e, g;
+void bar ();
+void corge (S);
+
+[[gnu::noinline]] static char *
+baz ()
+{
+ bar ();
+ return 0;
+}
+
+const char *
+qux ()
+{
+ if (e)
+{
+ S a = b;
+ corge (a);
+ if (g)
+return 0;
+ [[gnu::musttail]] return baz ();
+}
+ return foo ();
+}
[Bug c++/119659] New: [OpenMP] append_args in iobj member function applies to the wrong paramater
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119659
Bug ID: 119659
Summary: [OpenMP] append_args in iobj member function applies
to the wrong paramater
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: waffl3x at gcc dot gnu.org
Target Milestone: ---
Created attachment 61026
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61026&action=edit
Output with -ftree-dump-gimple
Another case that got found in the final stages of my current
patch, already fixed, this is just for records.
The issue is more obvious in the attached tree dump, despite
append_args being specified for parameter 'a', it is instead
adjusting the second parameter 'b' instead.
https://godbolt.org/z/4o4cc46eY
```
struct S {
template
void v(int *, int *) {}
#pragma omp declare variant(v) match(construct={dispatch}) \
adjust_args(need_device_ptr: a)
template
void b(int *a, int *b) {}
};
void f(int *p0, int *p1)
{
S s{};
#pragma omp dispatch
s.b(p0, p1);
}
```
[Bug c++/119387] [14 Regression] Regression in performance by a factor of 6 when building with debugging symbols since r14-5979
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119387 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Known to work||14.2.1 --- Comment #23 from Richard Biener --- Should be fixed now.
[Bug target/119617] ICE: in standard_sse_constant_opcode, at config/i386/i386.cc:5465 with -fzero-call-used-regs=all -mabi=ms -mavx512f -mno-evex512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119617 Hongtao Liu changed: What|Removed |Added CC||liuhongt at gcc dot gnu.org --- Comment #2 from Hongtao Liu --- (In reply to Richard Biener from comment #1) > I think we need to disable the effect of -mno-evex512, looks like there's > still traces of it left? Let's have a quick fix to avoid ICE, the major clean up work is planed for GCC16.
[Bug target/119617] ICE: in standard_sse_constant_opcode, at config/i386/i386.cc:5465 with -fzero-call-used-regs=all -mabi=ms -mavx512f -mno-evex512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119617 --- Comment #3 from Hongtao Liu --- (In reply to Hongtao Liu from comment #2) > (In reply to Richard Biener from comment #1) > > I think we need to disable the effect of -mno-evex512, looks like there's > > still traces of it left? > > Let's have a quick fix to avoid ICE, the major clean up work is planed for > GCC16. Reject mno-evex512 could be a solution.
[Bug target/119596] x86: too eager use of rep movsq/rep stosq for inlined ops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119596 Hongtao Liu changed: What|Removed |Added CC||liuhongt at gcc dot gnu.org --- Comment #20 from Hongtao Liu --- > > With -mtune=intel, I don't get `rep movsq` > Because with -mtune=znver2/3/4/5 I do. -mtune=intel is not updated for a long time, I suggest not use that.
[Bug c++/119657] New: GCC 15 fails with unknown pseudo-op .base64 error on std::println with special char as last letter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119657
Bug ID: 119657
Summary: GCC 15 fails with unknown pseudo-op .base64 error on
std::println with special char as last letter
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: igor.machado at gmail dot com
Target Milestone: ---
Hi all, I was trying g++-15 today on Ubuntu 24.04:
$ g++-15 --version
g++-15 (Ubuntu 15-20250329-1ubuntu1) 15.0.1 20250329 (experimental) [master
r15-9023-g8ad8f749729]
It fails when std::println adds special char as the last letter... I was trying
`std::println("{}", "Hello World")` and it's fine, as expected. When using
Portuguese text "Olá Mundo", it also works, but when only "Olá" is passed, then
it breaks with unknown pseudo-op .base64:
```
#include
int main() {
std::println("{}", "Olá");
return 0;
}
```
g++-15 --std=c++23 test.cpp
/tmp/ccnYLGG9.s: Assembler messages:
/tmp/ccnYLGG9.s:7245: Error: unknown pseudo-op: `.base64'
When using string Olá with a single space after, it also breaks:
`std::println("{}", "Olá ");`
But with two spaces after, it works fine:
`std::println("{}", "Olá ");`
If I quote it with TWO spaces, it works:
`std::println("'{}'", "Olá ");`
Output is: $ ./a.out
'Olá '
But with THREE to FOUR spaces, it still breaks... then, with FIVE spaces after,
it works again:
`std::println("'{}'", "Olá ");`
$ ./a.out
'Olá '
In short, something is strange with std::println on g++-15. Thanks in advance!
[Bug ipa/117432] [12/13 Regression] IPA ICF disregards types of variadic arguments since r10-4643-ga37f58f506e436
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117432 nightstrike changed: What|Removed |Added CC||nightstrike at gmail dot com --- Comment #16 from nightstrike --- On mingw-w64, the new testcase fails: Excess errors: /tmp/gcc/testsuite/gcc.c-torture/execute/pr117432.c:35:15: error: macro 'va_start' requires 2 arguments, but only 1 given /tmp/gcc/testsuite/gcc.c-torture/execute/pr117432.c:35:3: error: 'va_start' undeclared (first use in this function) The line in question is: va_start (ap); which as the error states, has only one argument instead of two. Tested on 15.
[Bug ipa/117432] [12/13 Regression] IPA ICF disregards types of variadic arguments since r10-4643-ga37f58f506e436
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117432 --- Comment #17 from Sam James --- (In reply to nightstrike from comment #16) I think you've either made an error and tested with the wrong GCC, or it needs its own bug. In C23, which is the default on trunk for some time, va_start can have one argument.
[Bug target/102294] memset expansion is sometimes slow for small sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102294 Hongtao Liu changed: What|Removed |Added CC||liuhongt at gcc dot gnu.org --- Comment #16 from Hongtao Liu --- (In reply to H.J. Lu from comment #12) > Please try > > https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577889.html > Maybe it's time to revisit this patch again as more issues reported in PR119596.
[Bug c++/119657] GCC 15 fails with unknown pseudo-op .base64 error on std::println with special char as last letter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119657 --- Comment #1 from Sam James --- What version of gas (the assembler) do you have? How did you get GCC 15? (If you built it yourself or got it from somewhere with a newer Binutils than your environment has, it would explain this.)
[Bug middle-end/104965] [12/13/14 Regression] Yet another -Warray-bounds false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104965 Sam James changed: What|Removed |Added Summary|[12/13/14/15 Regression]|[12/13/14 Regression] Yet |Yet another -Warray-bounds |another -Warray-bounds |false positive |false positive Known to work||15.0 --- Comment #12 from Sam James --- (In reply to Andrew Pinski from comment #11) > I think it was fixed by the operator new work that was done. -fno-assume-sane-operators-new-delete still works. Fixed on trunk by r15-5336-gcee7d080d5c2a5.
[Bug middle-end/104965] [12/13/14 Regression] Yet another -Warray-bounds false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104965 --- Comment #13 from Andrew Pinski --- (In reply to Sam James from comment #12) > (In reply to Andrew Pinski from comment #11) > > I think it was fixed by the operator new work that was done. > > -fno-assume-sane-operators-new-delete still works. Fixed on trunk by > r15-5336-gcee7d080d5c2a5. Hmm, that would mean we inline more. Let me double check that.
[Bug c++/119657] GCC 15 fails with unknown pseudo-op .base64 error on std::println with special char as last letter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119657 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #2 from Andrew Pinski --- This is not a gcc bug directly. The bug is Ubuntu built with a newer binutils that supports base64 but then didn't depend on the newer binutils for the package. Please report this to Ubuntu .
[Bug ipa/117432] [12/13 Regression] IPA ICF disregards types of variadic arguments since r10-4643-ga37f58f506e436
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117432 --- Comment #18 from Andrew Pinski --- (In reply to nightstrike from comment #16) > On mingw-w64, the new testcase fails: > > Excess errors: > /tmp/gcc/testsuite/gcc.c-torture/execute/pr117432.c:35:15: error: macro > 'va_start' requires 2 arguments, but only 1 given > /tmp/gcc/testsuite/gcc.c-torture/execute/pr117432.c:35:3: error: 'va_start' > undeclared (first use in this function) > > The line in question is: > va_start (ap); > > which as the error states, has only one argument instead of two. > > Tested on 15. I am suspect this is a bug in mingw's stdarg.h which does NOT support C23 va_start. IIRC there is a bug about mingw not using GCC's stdarg.h like it should be but I can't find that bug report.
[Bug libstdc++/119642] [15 regression] diagnostic push has no effect because of unmatched pop in bits/formatfwd.h since r15-9198
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119642 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2025-04-06 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- The pop there seems wrong so confirmed.
[Bug tree-optimization/79349] unused std::string is not optimized away in presense of a call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79349 Andrew Pinski changed: What|Removed |Added Depends on||23384 --- Comment #7 from Andrew Pinski --- I am 99% sure this is actually due to the escape analysis is not fully flow sensitive. We think s can be modified by the call by foo but s does not escape until after the call to foo (via the exception basic block). So we don't optimize: ``` MEM[(struct _Alloc_hider *)&s]._M_p = &s.D.25271._M_local_buf; __builtin_memcpy (&s.D.25271._M_local_buf, "abc", 3); s._M_string_length = 3; MEM[(char_type &)&s + 19] = 0; foo (); [local count: 1073741824]: _24 = s._M_dataplus._M_p; if (&s.D.25271._M_local_buf == _24) ``` Which means this depends on PR 23384. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23384 [Bug 23384] escaped set should be flow sensitive
[Bug tree-optimization/79349] unused std::string is not optimized away in presense of a call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79349 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=117279 --- Comment #8 from Andrew Pinski --- Well also see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117279#c4 .
[Bug tree-optimization/94293] [missed optimization] Useless statements populating local string not removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94293 --- Comment #9 from Andrew Pinski --- The trunk (GCC 15) can do it for C++20 but not for C++17 or earlier because std::__cxx11::basic_string::_M_create is not inlined. And GCC thinks: _20 = std::__cxx11::basic_string::_M_create (&p.second, &__dnew, 0); can modify p.first too. I wonder if there is a better way of doing _M_create here? (without changing the ABI).
[Bug modula2/119650] WriteString for String
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119650
--- Comment #2 from Gaius Mulley ---
Created attachment 61023
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61023&action=edit
Proposed fix which implements SStrIO.{def,mod}
Here is a proposed fix containing a new library module SStrIO.{def,mod}
implementing the functionality of StrIO but using the type String rather than
ARRAY OF CHAR.
[Bug ipa/94293] [missed optimization] Useless statements populating local string not removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94293 Andrew Pinski changed: What|Removed |Added Component|tree-optimization |ipa Depends on||86590 --- Comment #10 from Andrew Pinski --- So looking into _M_create's code, the only thing we need from this is _M_get_allocator() _M_get_allocator() could pass via argument. _S_allocate is already static. On the inlining side of things, that is PR 86590. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86590 [Bug 86590] Codegen is poor when passing std::string by value with _GLIBCXX_EXTERN_TEMPLATE undefined
[Bug ipa/94293] [missed optimization] Useless statements populating local string not removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94293 --- Comment #11 from Andrew Pinski --- In fact doing: ``` #include #undef _GLIBCXX_EXTERN_TEMPLATE ``` Fixes the code on the trunk so yes this is basically a dup of bug 86590 now.
[Bug tree-optimization/119655] Copy prop STRING_CST into memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119655 --- Comment #2 from Andrew Pinski --- Wait this might be a dup. I think Jan might have filed this bug ...
[Bug tree-optimization/97108] [12/13/14/15 Regression] -Wmaybe-uninitialized false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97108 --- Comment #12 from Sam James --- (In reply to Andrew Pinski from comment #10) > The real issue here is that fold during the building of generic > Converted `(separate_stderr && orig_err != STDERR_FILENO)` into > `(separate_stderr & orig_err != STDERR_FILENO)`. > > basically making a conditional uninitialized use into unconditional in some > cases. ifcombine was fixed in r14-2289-gb083203f053f16 to make sure that > does not happen. So basically we can't do this in generic any more either. r14-2296-g819285ef10a87d was also committed for PR110228.
[Bug target/115880] [13/14/15 regression] GCC 14+ fails to parse CoreFoundation header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115880
Sergey Fedorov changed:
What|Removed |Added
CC||vital.had at gmail dot com
--- Comment #6 from Sergey Fedorov ---
(In reply to Iain Sandoe from comment #2)
> I have posted patches (which need an update [on my shorter TODO] that
> implement the availability attribute). That makes a fix unnecessary - I
> would much rather pursue the implementation of the attribute than keep on
> applying band-aid fixincludes - the latter have been causing us some
> difficulties where SDKs change even within one OS rev.
>
> The availability patches are on my darwin branches, along with patches to
> remove the existing fixincludes which break on some SDK versions.
>
> So I agree that this bug is real - but I do not agree that the right
> resolution is more fixincludes.
This seems to be still broken in 14.2.0, at least MacPorts one (but it uses
your patches).
```
:info:build /bin/sh ../libtool --tag=CC --mode=compile
/opt/local/bin/gcc-mp-14 -DHAVE_CONFIG_H -I. -I.. -I.. -I../glib -I../glib
-I.. -DG_LOG_DOMAIN=\"GLib\" -DG_DISABLE_CAST_CHECKS -DGLIB_COMPILATION
-DPCRE_STATIC -I/opt/local/include
-isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk -D_REENTRANT
-Wall -Wstrict-prototypes -Werror=declaration-after-statement
-Werror=missing-prototypes -Werror=implicit-function-declaration
-Werror=pointer-arith -Werror=init-self -Werror=format=2
-Werror=missing-include-dirs -fvisibility=hidden -pipe -Os
-isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk -arch x86_64
-MT libglib_2_0_la-gvariant.lo -MD -MP -MF .deps/libglib_2_0_la-gvariant.Tpo -c
-o libglib_2_0_la-gvariant.lo `test -f 'gvariant.c' || echo './'`gvariant.c
:info:build libtool: compile: /opt/local/bin/gcc-mp-14 -DHAVE_CONFIG_H -I.
-I.. -I.. -I../glib -I../glib -I.. -DG_LOG_DOMAIN=\"GLib\"
-DG_DISABLE_CAST_CHECKS -DGLIB_COMPILATION -DPCRE_STATIC -I/opt/local/include
-isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk -D_REENTRANT
-Wall -Wstrict-prototypes -Werror=declaration-after-statement
-Werror=missing-prototypes -Werror=implicit-function-declaration
-Werror=pointer-arith -Werror=init-self -Werror=format=2
-Werror=missing-include-dirs -fvisibility=hidden -pipe -Os
-isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk -arch x86_64
-MT libglib_2_0_la-gutils.lo -MD -MP -MF .deps/libglib_2_0_la-gutils.Tpo -c
gutils.c -o libglib_2_0_la-gutils.o
:info:build libtool: compile: /opt/local/bin/gcc-mp-14 -DHAVE_CONFIG_H -I.
-I.. -I.. -I../glib -I../glib -I.. -DG_LOG_DOMAIN=\"GLib\"
-DG_DISABLE_CAST_CHECKS -DGLIB_COMPILATION -DPCRE_STATIC -I/opt/local/include
-isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk -D_REENTRANT
-Wall -Wstrict-prototypes -Werror=declaration-after-statement
-Werror=missing-prototypes -Werror=implicit-function-declaration
-Werror=pointer-arith -Werror=init-self -Werror=format=2
-Werror=missing-include-dirs -fvisibility=hidden -pipe -Os
-isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk -arch x86_64
-MT libglib_2_0_la-gurifuncs.lo -MD -MP -MF .deps/libglib_2_0_la-gurifuncs.Tpo
-c gurifuncs.c -o libglib_2_0_la-gurifuncs.o
:info:build In file included from
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:43,
:info:build from
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:19,
:info:build from gunicollate.c:30:
:info:build
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFUserNotification.h:126:1:
error: attributes should be specified before the declarator in a function
definition
:info:build 126 | CF_INLINE CFOptionFlags
CFUserNotificationCheckBoxChecked(CFIndex i) API_AVAILABLE(macos(10.0))
API_UNAVAILABLE(ios, watchos, tvos) {return ((CFOptionFlags)(1UL << (8 + i)));}
:info:build | ^
:info:build
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFUserNotification.h:127:1:
error: attributes should be specified before the declarator in a function
definition
:info:build 127 | CF_INLINE CFOptionFlags
CFUserNotificationSecureTextField(CFIndex i) API_AVAILABLE(macos(10.0))
API_UNAVAILABLE(ios, watchos, tvos) {return ((CFOptionFlags)(1UL << (16 +
i)));}
:info:build | ^
:info:build
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/CoreFoundation.framework/Headers/CFUserNotification.h:128:1:
error: attributes should be specified before the declarator in a function
definition
:info:build 128 | CF_INLINE CFOptionFlags
CFUserNotificationPopUpSelection(CFIndex n) API_AVAIL
[Bug tree-optimization/119655] Copy prop STRING_CST into memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119655 --- Comment #3 from Andrew Pinski --- (In reply to Andrew Pinski from comment #2) > Wait this might be a dup. I think Jan might have filed this bug ... Turns out this is not a dup bug related to PR 117793.
[Bug c/119658] New: Better support for freestanding env on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119658 Bug ID: 119658 Summary: Better support for freestanding env on Windows Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: nightstrike at gmail dot com Target Milestone: --- See the following for reference: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117432#c18 https://gcc.gnu.org/legacy-ml/gcc-patches/2010-01/msg01034.html https://sourceforge.net/p/mingw-w64/bugs/970/ Long ago, mingw-w64 imported the GCC version of several header files and modified them to support Windows. GCC was then modified to not install its own in preference to the ones from mingw-w64. These have not been kept in sync, and it's better to maintain this in one location. For example, the above mentioned PR117432 highlights a particular test case that failed due to lack of support of a C23 feature in stdarg.h. Andrew suggested on IRC to use __has_include_next and #include_next on the GCC side to detect if any mingw-w64 customizations are present, for instance in a stdarg.ext.h file. Then, on the mingw-w64 side, we can maintain just those aspects that need to be customized. This would require changes on both sides, but at least the GCC stdarg.h file would again be installed. This likely applies to any of the freestanding environment headers described here: https://en.cppreference.com/w/c/language/conformance Currently, that is the following: float.h iso646.h limits.h stdalign.h stdarg.h stdbool.h stddef.h stdint.h stdnoreturn.h stdbit.h
[Bug preprocessor/119653] [12/13/14/15 Regression] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119653 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup in the end. *** This bug has been marked as a duplicate of bug 118674 ***
[Bug preprocessor/118674] [12/13/14/15 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118674 Andrew Pinski changed: What|Removed |Added CC||xieym3 at zohomail dot com --- Comment #2 from Andrew Pinski --- *** Bug 119653 has been marked as a duplicate of this bug. ***
[Bug libstdc++/119645] GCN, nvptx: libstdc++ 'checking for atomic builtins [...]... no'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119645 Thomas Schwinge changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=70560 --- Comment #1 from Thomas Schwinge --- I shall soon post "GCN, nvptx libstdc++: Force use of '__atomic' builtins [PR119645]" -- which just hard-codes this, but doesn't resolve the (presumed) underlying issue. I've also re-discovered my own PR70560 "Review configure checks for _GLIBCXX_ATOMIC_BUILTINS and atomicity_dir" (for x86_64), from almost a decade ago. ;-)
[Bug fortran/112625] Segmentation fault in getter function of unlimited polymorphic object in nested container / wrapper object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112625 Michail Stamatakis changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #2 from Michail Stamatakis --- Thank you, I have just now verified that this works in r13-9434, r14-11414, as you noted, as well as in 15-trunk (7d561820525fd3b9d8f3876333c0584d75e7c053). I am happy to mark this as resolved.
[Bug libstdc++/93469] memory header fails to compile with _XOPEN_SOURCE macro defined and -std=c++2a option specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93469 --- Comment #12 from Sergey Fedorov --- (In reply to Jonathan Wakely from comment #10) The same error happens even without the macro in question being passed, at least explicitly. Getting it with gcc 14.2.0 and ICU 76.1 (on x86_64, but not on powerpc).
[Bug target/115880] [13/14/15 regression] GCC 14+ fails to parse CoreFoundation header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115880 --- Comment #7 from Iain Sandoe --- (In reply to Sergey Fedorov from comment #6) > (In reply to Iain Sandoe from comment #2) > > I have posted patches (which need an update [on my shorter TODO] that > > implement the availability attribute). That makes a fix unnecessary - I > > would much rather pursue the implementation of the attribute than keep on > > applying band-aid fixincludes - the latter have been causing us some > > difficulties where SDKs change even within one OS rev. > > > > The availability patches are on my darwin branches, along with patches to > > remove the existing fixincludes which break on some SDK versions. > > > > So I agree that this bug is real - but I do not agree that the right > > resolution is more fixincludes. The patches were not accepted upstream yet, so they are only on the GH branches. > This seems to be still broken in 14.2.0, at least MacPorts one (but it uses > your patches). I cannot speak for what any of the distributions have https://github.com/iains/gcc-14-branch/commits/gcc-14-2-darwin/ builds for me on darwin9 ... darwin24. If you have a problem with a specific SDK please file an issue on the GH development branch; it cannot be addressed upstream at the moment. I would need to know exactly which SDK on which OS version is failing - to be able to reproduce it - and to be sure to build exactly the branch that has been released.
[Bug target/115880] [13/14/15 regression] GCC 14+ fails to parse CoreFoundation header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115880 --- Comment #8 from Sergey Fedorov --- (In reply to Iain Sandoe from comment #7) If the fix was after gcc14-r1, then it is missing in the gcc14 port, since apparently r1 is used: https://github.com/macports/macports-ports/blob/936d189aa5bf8e792d6fede33df68b13b2316761/lang/gcc14/Portfile#L192-L211 I can update to gcc14-r2 locally though.
[Bug tree-optimization/97108] [12/13/14/15 Regression] -Wmaybe-uninitialized false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97108 Sam James changed: What|Removed |Added Keywords||wrong-code --- Comment #11 from Sam James --- With -O2 on trunk, it doesn't happen anymore after r15-518-g99b1daae18c095. I haven't succeeded yet in a runtime testcase for the issue mentioned in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97108#c10.
[Bug tree-optimization/119614] [15 regression] protobuf-29.4 fails to build with -O2 (error: cannot tail-call: call and return value are different)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614 --- Comment #14 from Sam James --- Created attachment 61024 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61024&action=edit protobuf-lto.tar.xz Here's a failure of protobuf w/ LTO with that patch, sadly. I'm reducing it but attaching it so I can conveniently retest it later.
[Bug c++/119652] [14/15 Regression] constinit empty direct-list-initialization incorrectly rejected since r14-660
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119652
--- Comment #2 from Patrick Palka ---
FWIW it works if A is initialized via default-init or copy-list-init:
constinit A a{};// error
constinit A a; // OK
constinit A a = {}; // OK
[Bug c/119649] internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in create_tmp_from_val, at gimplify.cc:621
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119649 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=115489 --- Comment #3 from Andrew Pinski --- (In reply to Xieym from comment #2) > The following also has the same crash signature, is it the same reason? That is most likely PR 115489.
[Bug libstdc++/93469] memory header fails to compile with _XOPEN_SOURCE macro defined and -std=c++2a option specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93469 --- Comment #13 from Iain Sandoe --- (In reply to Sergey Fedorov from comment #12) > (In reply to Jonathan Wakely from comment #10) > > The same error happens even without the macro in question being passed, at > least explicitly. Getting it with gcc 14.2.0 and ICU 76.1 (on x86_64, but > not on powerpc). 10.15 (Catalina) should have aligned_alloc() whereas 10.5 does not. Look at what the (libstdc++-v3) build tree values for _GLIBCXX_HAVE_ALIGNED_ALLOC and HAVE_ALIGNED_ALLOC are. Then take a look at what the project is adding - it is quite possible that some other macro (e.g. *POSIX*) is preventing the declarations from being visible.
[Bug libstdc++/93469] memory header fails to compile with _XOPEN_SOURCE macro defined and -std=c++2a option specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93469 --- Comment #15 from Sergey Fedorov --- And this also: ``` #if !defined _POSIX_C_SOURCE && \ defined(__APPLE__) && defined(__MACH__) && !defined(__clang__) // Needed to prevent EOWNERDEAD issues with GCC on Mac #define _POSIX_C_SOURCE 200809L #endif ``` https://github.com/unicode-org/icu/blob/89fe16ef3b77a6b98f7664f52338c8ff80e28096/icu4c/source/common/uposixdefs.h
[Bug libstdc++/93469] memory header fails to compile with _XOPEN_SOURCE macro defined and -std=c++2a option specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93469 --- Comment #16 from Sergey Fedorov --- So apparently what we need is `_DARWIN_C_SOURCE` defined. At least passing that as a cppflag fixed the error. Should be fixed on ICU side then.
[Bug libstdc++/93469] memory header fails to compile with _XOPEN_SOURCE macro defined and -std=c++2a option specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93469 --- Comment #14 from Sergey Fedorov --- (In reply to Iain Sandoe from comment #13) > (In reply to Sergey Fedorov from comment #12) > > (In reply to Jonathan Wakely from comment #10) > > > > The same error happens even without the macro in question being passed, at > > least explicitly. Getting it with gcc 14.2.0 and ICU 76.1 (on x86_64, but > > not on powerpc). > > 10.15 (Catalina) should have aligned_alloc() whereas 10.5 does not. Look at > what the (libstdc++-v3) build tree values for _GLIBCXX_HAVE_ALIGNED_ALLOC > and HAVE_ALIGNED_ALLOC are. > > Then take a look at what the project is adding - it is quite possible that > some other macro (e.g. *POSIX*) is preventing the declarations from being > visible. Ok, it is ICU bug, apparently: ``` #ifdef _XOPEN_SOURCE /* Use the predefined value. */ #else /* * Version 6.0: * The Open Group Base Specifications Issue 6 (IEEE Std 1003.1, 2004 Edition) * also known as * SUSv3 = Open Group Single UNIX Specification, Version 3 (UNIX03) * * Note: This definition used to be in C source code (e.g., putil.c) * and define _XOPEN_SOURCE to different values depending on __STDC_VERSION__. * In C++ source code (e.g., putil.cpp), __STDC_VERSION__ is not defined at all. */ # define _XOPEN_SOURCE 600 #endif ```
[Bug c++/119654] [12/13/14/15 Regression] name lookup after `typename` incorrectly ignores non-type non-namespace names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119654 Andrew Pinski changed: What|Removed |Added Keywords||accepts-invalid, ||needs-bisection Summary|name lookup after |[12/13/14/15 Regression] |`typename` incorrectly |name lookup after |ignores non-type|`typename` incorrectly |non-namespace names |ignores non-type ||non-namespace names Target Milestone|--- |12.5 Known to fail||4.8.0 Known to work||4.7.4 --- Comment #1 from Andrew Pinski --- GCC changed behavior between 4.7 and 4.8 for x2.
[Bug tree-optimization/119655] New: Copy prop STRING_CST into memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119655
Bug ID: 119655
Summary: Copy prop STRING_CST into memcpy
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: pinskia at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
void f256(char *a)
{
char t[] = "012345678901234567890123456789012345678901234567";
__builtin_memcpy(a, &t[0], sizeof(t));
}
void f256_0(char *a)
{
char t[] = "012345678901234567890123456789012345678901234567";
__builtin_memcpy(a, t, sizeof(t));
}
void f256_1(char *a)
{
const char *t = "012345678901234567890123456789012345678901234567";
__builtin_memcpy(a, &t[0], __builtin_strlen(t)+1);
}
```
These 2 should produce the same assembly code but currently does not because t
is stored to the stack and you get a stack increment.
Likewise of these:
```
void g256(char *a)
{
char t[49] = "";
__builtin_memcpy(a, &t[0], sizeof(t));
}
void g256_0(char *a)
{
char t[49] = "";
__builtin_memcpy(a, t, sizeof(t));
}
void g256_1(char *a)
{
__builtin_memset(a, 0, 49);
}
```
I have a patch which handles g256_0 (PR118947) which has been approved for GCC
16. g256/f256's memcpy is not transformed into
`MEM [(char * {ref-all})a_3(D)] = MEM
[(char * {ref-all})&t];`
Which it should be ... That would fix g256.
[Bug tree-optimization/119655] Copy prop STRING_CST into memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119655 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2025-04-06 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- .
[Bug fortran/119656] New: [12/13/14/15 Regression] Wrong code with impure elemental subroutine and interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119656
Bug ID: 119656
Summary: [12/13/14/15 Regression] Wrong code with impure
elemental subroutine and interface
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: anlauf at gcc dot gnu.org
Target Milestone: ---
The attached code is derived from:
https://fortran-lang.discourse.group/t/problem-with-impure-elemental-subroutine-in-interface-with-gfortran/9545
Compiled with gfortran 12+ I get:
in foo_df, len(xstr) = 2
in foo_df, len(xstr) = 0
while with version 7-11 I get the correct:
in foo_df, len(xstr) = 2
in foo_df, len(xstr) = 2
Remarks:
- as noted in the above discussion, commenting 'use m1_mod' avoids the issue
- impure AND elemental are needed to reproduce
- the dump tree shows that the failing translated calls has a wrong number of
arguments:
void MAIN__ ()
{
{
static integer(kind=4) C.4688 = 5;
foo_df (&C.4688, 0B, &"ab"[1]{lb: 1 sz: 1}, 2);
}
{
static integer(kind=4) C.4689 = 5;
foo_df (&C.4689, 0B, &"ab"[1]{lb: 1 sz: 1}, 0, 2);
}
}
The additional 0 in the argument list is taken as string length.
[Bug fortran/119656] [12/13/14/15 Regression] Wrong code with impure elemental subroutine and interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119656 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |12.5 Known to fail||12.4.1, 13.3.1, 14.2.1, ||15.0 Priority|P3 |P4 Known to work||11.5.0 Keywords||wrong-code
[Bug fortran/119656] [12/13/14/15 Regression] Wrong code with impure elemental subroutine and interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119656 --- Comment #1 from anlauf at gcc dot gnu.org --- Created attachment 61022 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61022&action=edit Testcase It actually helps to attach it...
[Bug cobol/119632] section segments (cobol85) not implemented, "ignored" -> raising compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119632 Iain Sandoe changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Status|NEW |ASSIGNED URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2025-April/6 ||80268.html --- Comment #2 from Iain Sandoe --- patch posted
[Bug target/93082] macOS Authorization.h needs fixinclude
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93082 Sergey Fedorov changed: What|Removed |Added CC||vital.had at gmail dot com --- Comment #15 from Sergey Fedorov --- This still does not work with gcc-14.2.0. ``` :info:build In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/Security.framework/Headers/AuthSession.h:32, :info:build from /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/Security.framework/Headers/Security.h:42, :info:build from /opt/local/var/macports/build/_opt_CatalinaPorts_devel_cmake-bootstrap/cmake-bootstrap/work/cmake-3.9.6/Utilities/cmcurl/lib/urldata.h:148, :info:build from /opt/local/var/macports/build/_opt_CatalinaPorts_devel_cmake-bootstrap/cmake-bootstrap/work/cmake-3.9.6/Utilities/cmcurl/lib/file.c:52: :info:build /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/Security.framework/Headers/Authorization.h:193:7: error: variably modified 'bytes' at file scope :info:build 193 | char bytes[kAuthorizationExternalFormLength]; :info:build | ^ :info:build make[2]: *** [Utilities/cmcurl/lib/CMakeFiles/cmcurl.dir/file.c.o] Error 1 :info:build make[2]: *** Waiting for unfinished jobs ```
