[Bug middle-end/113264] ICE with attribute copy and attribute no_sanitize_address on the original decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113264 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2024-01-08 Ever confirmed|0 |1 Summary|ICE：tree check: expected|ICE with attribute copy and |tree that contains 'common' |attribute |structure, have |no_sanitize_address on the |'integer_cst' in copy_list, |original decl |at tree.cc:1427 | --- Comment #1 from Andrew Pinski --- Reduced testcase: ``` __attribute__((no_sanitize_address)) void h(); __typeof(h) tanhf64 __attribute__((__copy__(h))); ``` Confirmed.
[Bug c++/113263] ICE for invalid code for compound literal and type definition in return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113263
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Keywords||ice-checking,
||ice-on-invalid-code
Last reconfirmed||2024-01-08
--- Comment #2 from Andrew Pinski ---
It has nothing to do with the return type.
Rather it is just an initialization that is causing the issue with the type
defined there and an anonymous union.
Reduced testcase:
```
void
maybe_make_thing(void)
{
(struct { union { bool _err; }; })
{ ._err = 1, } ;
}
```
Confirmed, looks like it is only and ICE with checking too.
```
: In function 'void maybe_make_thing()':
:5:20: error: 'maybe_make_thing()_err' is not a
direct member of 'maybe_make_thing()::'
5 | { ._err = 1, } ;
|^
```
[Bug c++/113263] ICE for invalid code for compound literal and type definition in return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113263 --- Comment #1 from Andrew Pinski --- Created attachment 57004 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57004=edit Preprocessed source
[Bug middle-end/113264] New: ICE：tree check: expected tree that contains 'common' structure, have 'integer_cst' in copy_list, at tree.cc:1427
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113264
Bug ID: 113264
Summary: ICE：tree check: expected tree that contains 'common'
structure, have 'integer_cst' in copy_list, at
tree.cc:1427
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: iamanonymous.cs at gmail dot com
Target Milestone: ---
Compiler Explorer: https://godbolt.org/z/1bev4r9a4
***
OS and Platform:
$ uname -a:
Linux ubuntu 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC 2023
x86_64 x86_64 x86_64 GNU/Linux
***
gcc version:
$ gcc -v
Using built-in specs.
COLLECT_GCC=/root/gcc_set/202311291030/bin/gcc
COLLECT_LTO_WRAPPER=/root/gcc_set/202311291030/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/root/gcc_set/202311291030
--with-gmp=/root/build_essential --with-mpfr=/root/build_essential
--with-mpc=/root/build_essential --enable-languages=c,c++ --disable-multilib
--with-sanitizer=address,undefined,thread,leak
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20231129 (experimental) (GCC)
git version: 99fa0bfd63d97825c4221dcd3123940f1d0e6291
***
Program:
$ cat mutant.c
__attribute__((no_sanitize_address))
__attribute__((target_clones("arch=haswell", "default"))) int __tanh() {}
__typeof(__tanh) tanhf64 __attribute__((alias("__tanh")))
__attribute__((__copy__(__tanh)));
***
Command Lines:
$ gcc mutant.c
mutant.c:4:1: internal compiler error: tree check: expected tree that contains
‘common’ structure, have ‘integer_cst’ in copy_list, at tree.cc:1427
4 | __attribute__((__copy__(__tanh)));
| ^
0x859d06 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
../../gcc/gcc/tree.cc:9126
0x860f78 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/gcc/tree.h:3748
0x860f78 copy_list(tree_node*)
../../gcc/gcc/tree.cc:1427
0xa755a5 handle_copy_attribute
../../gcc/gcc/c-family/c-attribs.cc:3077
0x94ad5b decl_attributes(tree_node**, tree_node*, int, tree_node*)
../../gcc/gcc/attribs.cc:886
0x95139d c_decl_attributes
../../gcc/gcc/c/c-decl.cc:5425
0x9689f7 start_decl(c_declarator*, c_declspecs*, bool, tree_node*, bool,
unsigned int*)
../../gcc/gcc/c/c-decl.cc:5571
0x9d5757 c_parser_declaration_or_fndef
../../gcc/gcc/c/c-parser.cc:2766
0x9e168b c_parser_external_declaration
../../gcc/gcc/c/c-parser.cc:2046
0x9e2075 c_parser_translation_unit
../../gcc/gcc/c/c-parser.cc:1900
0x9e2075 c_parse_file()
../../gcc/gcc/c/c-parser.cc:26713
0xa564e1 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.cc:1296
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug c++/113263] New: ICE for invalid code for compound literal and type definition in return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113263
Bug ID: 113263
Summary: ICE for invalid code for compound literal and type
definition in return type
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: muecker at gwdg dot de
Target Milestone: ---
The following example ICEs after invalid code (it is valid C but not C++)
https://godbolt.org/z/7zrbxPraM
(partially minimized from: C example https://godbolt.org/z/M7n7o1r8h)
#define TOKEN_CONCAT_EX(x, y) x##y
#define TOKEN_CONCAT(x, y)TOKEN_CONCAT_EX(x, y)
#define UNIQUIFY(x) TOKEN_CONCAT(x, __LINE__)
#define ResultBody(T, E) { bool _is_ok; union { T _ok; E _err; }; }
#define ResultName(T, E) result_##T##_##E
#define ResultEx(T, E, T_N, E_N) struct ResultName(T_N, E_N) ResultBody(T, E)
#define Result(T, E) ResultEx(T, E, T, E)
#define Err(R, V) ((R) { ._is_ok = false, ._err = V, })
typedef struct
{
int val;
} thing_t;
Result(thing_t, bool) maybe_make_thing(int v)
{
return Err(Result(thing_t, bool), v == 200);
}
[Bug libstdc++/113258] Pre-C++17 code that supplies operator new/delete crashes when mixed with post-C+17 code that uses the align_val_t variants of new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258 --- Comment #16 from Andrew Pinski --- Note multiple copies of the libstdc++ will not fix the issue here since libtcmalloc provides a free which does not work with aligned_alloc. In fact it would just fall over the same way. As I mentioned libtcmalloc is not even compatible with C11. aligned_alloc was around for a few years even.
[Bug libstdc++/113258] Pre-C++17 code that supplies operator new/delete crashes when mixed with post-C+17 code that uses the align_val_t variants of new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #15 from Andrew Pinski --- The problem is libtcmalloc_minimal.so displaced free and this has nothing to do with operator new/delete really. It just happens that the aligned operator new calls aligned_alloc and then calls free on that pointer and the free fails here because libtcmalloc is not forwards compatible with c11's aligned_alloc. This is also an issue with some c11 code that would call aligned_alloc and then call free. The bug is again in libtcmalloc and not forwards compatible.
[Bug libstdc++/113260] missing from_chars/to_chars for __float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113260 --- Comment #7 from g.peterh...@t-online.de --- Thank you. That was my question whether these two functions could be added. At the moment I'm using boost.charconv https://github.com/cppalliance/charconv https://develop.charconv.cpp.al (not official yet) - but it's still completely buggy.
[Bug libstdc++/113258] Pre-C++17 code that supplies operator new/delete crashes when mixed with post-C+17 code that uses the align_val_t variants of new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258 Nicholas Miell changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED|NEW --- Comment #14 from Nicholas Miell --- Again, this version of tcmalloc predates aligned_alloc and the align_val_t versions of operator new and delete. Again, the C++ standard does not require the application to displace aligned_malloc when it displaces operator new or delete. Again, it is libstdc++ that is calling aligned_alloc, not the application. Again, the application displaced all the versions of operator new and delete that were present in the version of the C++ standard that it targeted, in addition to all the C malloc functions in the C standard it targeted. Again, libstdc++ broke the ABI when it introduced the align_val_t versions of operator new and delete because existing correctly functioning applications stopped working in the presence of the new version of libstdc++. Again, libstdc++ has elected to provide only one version of the C++ runtime implementation that supports multiple versions of the C++ standard simultaneously, instead of forking the library for every new revision of the language standard. Again, you could probably fix this issue by implementing all of the newly introduced versions of operator new and delete solely using the versions of operator new and delete that were present when libstdc++.so.6 was first introduced. Attempting to stick the blame on something other than libstdc++ doesn't even solve the problem of the application crashing at startup, ultimately it will have to be libstdc++ that works around this issue regardless. The application certainly isn't getting updated, nor should it require updating; that's the whole point of having ABIs in the first place. The C++23 standard says that whether the default versions of operator new "involves a call to the C standard library functions malloc or aligned_alloc is unspecified." I assert that a C++ runtime that purports to simultaneously implement both C++14 and previous (which do not have aligned_alloc) and C++17 and later (which do have aligned_alloc) must not call aligned_alloc in the default behavior of any version of operator new as a basic quality of implementation detail, given that C++14 and previous applications (which the C++ runtime explicitly supports) are allowed to displace operator new and delete without any knowledge of aligned_alloc.
[Bug c/113262] [11/12/13/14 Regression] ICE when using [[gnu::copy("")]] attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113262
Andrew Pinski changed:
What|Removed |Added
Known to fail||11.1.0
Last reconfirmed||2024-01-08
Target Milestone|--- |11.5
Ever confirmed|0 |1
Known to work||10.5.0
Status|UNCONFIRMED |NEW
Summary|ICE when using |[11/12/13/14 Regression]
|[[gnu::copy("")]] attribute |ICE when using
||[[gnu::copy("")]] attribute
--- Comment #1 from Andrew Pinski ---
Confirmed, GCC 10 and before errored out correctly though with a bogus
location:
:376772:107: error: 'copy' attribute argument cannot be a string
[Bug libstdc++/113260] missing from_chars/to_chars for __float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113260 --- Comment #6 from Andrew Pinski --- (In reply to g.peterhoff from comment #5) > ??? I asked for std::from_chars/std::to_chars - which of course doesn't work: > https://godbolt.org/z/n34dTajoc std::from_chars/std::to_chars for extended floating point types is only available with C++23 though. I really doubt they will be added for __float128 . Maybe they could be enabled for pre-C++23 for the extended FP types too .. But a libstdc++ maintainer should answer that question since that would be an extension. Even having them for __float128 will be an extension too.
[Bug libstdc++/113260] missing from_chars/to_chars for __float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113260 --- Comment #5 from g.peterh...@t-online.de --- ??? I asked for std::from_chars/std::to_chars - which of course doesn't work: https://godbolt.org/z/n34dTajoc
[Bug c/113262] New: ICE when using [[gnu::copy("")]] attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113262
Bug ID: 113262
Summary: ICE when using [[gnu::copy("")]] attribute
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
int[[gnu::copy("")]]a;
This crashes trunk GCC with the following error:
:1:1: internal compiler error: tree check: expected tree that contains
'decl minimal' structure, have 'integer_type' in handle_copy_attribute, at
c-family/c-attribs.cc:3150
1 | int[[gnu::copy("")]]a;
| ^~~
0x232d4fc internal_error(char const*, ...)
???:0
0x87efb9 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
???:0
0x983af3 decl_attributes(tree_node**, tree_node*, int, tree_node*)
???:0
0x996328 finish_declspecs(c_declspecs*)
???:0
0xa1c31b c_parse_file()
???:0
0xa93da9 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug testsuite/111480] new test case g++.target/powerpc/altivec-19.C fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111480 Kewen Lin changed: What|Removed |Added Last reconfirmed||2024-01-08 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-January ||/642093.html Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org CC||linkw at gcc dot gnu.org
[Bug target/112606] [14 Regression] powerpc64le-linux-gnu: 'FAIL: gcc.target/powerpc/p8vector-fp.c scan-assembler xsnabsdp'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112606 Kewen Lin changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org Last reconfirmed||2024-01-08 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #5 from Kewen Lin --- (In reply to seurer from comment #3) > These tests also fail starting with > g:9e9279fadbd1c673c875b9d20261d2de0473f63f, r14-5542-g9e9279fadbd1c6 > > FAIL: gcc.target/powerpc/float128-hw5.c scan-assembler-not \\mxscpsgnqp\\M > FAIL: gcc.target/powerpc/float128-hw5.c scan-assembler-times \\mxsnabsqp\\M 1 > FAIL: gcc.target/powerpc/float128-hw7.c scan-assembler-not \\mxscpsgnqp\\M > FAIL: gcc.target/powerpc/float128-hw7.c scan-assembler-times \\mxsnabsqp\\M 1 These failures are related to ieee128, the #c4 only handles float/double, a similar patch was posted for ieee128: https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642092.html
[Bug testsuite/112751] [14 regression] gcc.target/powerpc/pcrel-sibcall-1.c fails after r14-5628-g53ba8d669550d3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112751 Kewen Lin changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-January ||/642091.html Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug tree-optimization/113261] missing vectorization for dot_prod chain.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113261 --- Comment #1 from Hongtao Liu --- For foo1, _99 = .REDUC_PLUS (vect_patt_79.51_97); _90 = .REDUC_PLUS (vect_patt_28.43_88); _19 = _90 + _99; can be optimized to _tmp = vect_patt_79.51_97 + vect_patt_28.43_88; _19 = .REDUC_PLUS (_tmp);
[Bug tree-optimization/113261] New: missing vectorization for dot_prod chain.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113261
Bug ID: 113261
Summary: missing vectorization for dot_prod chain.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: liuhongt at gcc dot gnu.org
Blocks: 53947
Target Milestone: ---
int
foo (char* a, char* b, char* c, char* d)
{
int sum = 0;
for (int i = 0; i != 32; i++)
{
sum += (a[i] * b[i] + c[i] * d[i]);
}
return sum;
}
int
foo1 (char* a, char* b, char* c, char* d)
{
int sum = 0;
int sum1 = 0;
for (int i = 0; i != 32; i++)
{
sum += a[i] * b[i]
sum1 += c[i] * d[i];
}
return sum + sum1;
}
foo should be same as foo1, but it failed to be optimized to dot_prod_expr
since current vect_recog_dot_prod_pattern only recognize sum += a[i] * b[i];
I think it can be extend to recog dot_prod_expr chain, as long as they're only
used by the final sum reduction.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug middle-end/113100] [14 regression] many strub tests fail after r14-6737-g4e0a467302fea5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113100 Kewen Lin changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-January ||/642090.html Status|NEW |ASSIGNED
[Bug libquadmath/113259] quadmath::nanq not support payload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113259 --- Comment #2 from g.peterh...@t-online.de --- I'm currently fiddling around with a library for/with boost. I don't need this kind of incompatibility.
[Bug libstdc++/113260] missing from_chars/to_chars for __float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113260 --- Comment #4 from Andrew Pinski --- _Float128 is supported in older c++ standards for gcc. That is it does not error out for -std=gnu++11 even.
[Bug libstdc++/113260] missing from_chars/to_chars for __float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113260 --- Comment #3 from g.peterh...@t-online.de --- My problem is that I need from_chars/to_chars for __float128 also for older C++ standards that do not yet support _Float128/std::float128_t.
[Bug libstdc++/113258] Pre-C++17 code that supplies operator new/delete crashes when mixed with post-C+17 code that uses the align_val_t variants of new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING |RESOLVED --- Comment #13 from Andrew Pinski --- (In reply to Nicholas Miell from comment #12) > That's not relevant, the language of the C++ standard doesn't require the > application to also displace aligned_free when displacing the aligned > versions of operator new or delete. The language of the standard also > doesn't require the application to displace versions of operator new and > delete that didn't yet exist in the version of the standard that the > application targets. There is no aligned_free; only free, that is part of the issue here; the C and c++17 standard requires that memory that was allocated with aligned_alloc be free'able with free. If you displace free, and don't displace aligned_alloc then things will go wrong. that is not an backwards compatiable ABI issue since you are overriding free here and such. > This version of tcmalloc predates aligned_alloc just as much as it predates > the align_val_t variants of operator new and delete, and the whole > point of an ABI is that existing binaries continue to work. The ABI is backwards compatiable but in this case, it is not forwards compatiable. That is an issue. Also aligned_alloc is from C11 (and C++17), just not many people used it until recently (in this case via operator new). Basically glibc ABI might be backwards compatiable but replacing things means the ABI of tcmalloc needs to match the ABI that is being used for glibc. Again you mention it is aligned_alloc and free that is being called in the end. That is exactly not a libstdc++ issue at all, rather it is a glibc ABI issue.
[Bug libquadmath/113259] quadmath::nanq not support payload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113259 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2024-01-08 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- libquadmath is not used on many targets any more since glibc provides the support for them. What target is this for?
[Bug libstdc++/113260] missing from_chars/to_chars for __float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113260 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-01-08 Status|UNCONFIRMED |WAITING --- Comment #2 from Andrew Pinski --- Actually it was added in GCC 13 by r13-3754-ge5bcbcd04cfcb2 . Can you provide more information here what you need? Using _Float128 is better than using __float128 since _Float128 is the C/C++ standard style of extended floating point types.
[Bug libstdc++/113260] missing from_chars/to_chars for __float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113260 --- Comment #1 from Andrew Pinski --- There is support for _Float128 for from_chars/to_chars in GCC 14 already ..
[Bug libstdc++/113258] Pre-C++17 code that supplies operator new/delete crashes when mixed with post-C+17 code that uses the align_val_t variants of new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258 --- Comment #12 from Nicholas Miell --- (In reply to Andrew Pinski from comment #9) > (In reply to Nicholas Miell from comment #8) > > What appears to actually be happening is that the libstdc++ operator > > new(std::size_t size, std::align_val_t alignment) is calling glibc's > > aligned_alloc, and then the libstdc++ operator delete(void* ptr, > > std::align_val_t alignment) is calling std::free(), which is supplied by > > tcmalloc. > > > aligned_alloc is part of C11 and C++17 and is required to be free'd by > std::free (or free in the C11 case). > > So this seems like a bug in tcmalloc not supplying an override of the C11 > function aligned_alloc. > > You would run into the same issue with a C11 application that does the same > too. That's not relevant, the language of the C++ standard doesn't require the application to also displace aligned_free when displacing the aligned versions of operator new or delete. The language of the standard also doesn't require the application to displace versions of operator new and delete that didn't yet exist in the version of the standard that the application targets. This version of tcmalloc predates aligned_alloc just as much as it predates the align_val_t variants of operator new and delete, and the whole point of an ABI is that existing binaries continue to work. libstdc++ has elected to provide one implementation of the C++ runtime that is ostensibly compatible with multiple revisions of the C++ language standard, the C++23 version of libstdc++.so.6 is required to continue to support all existing C++ executables dating back to at least 2004 (I'm not sure when version 6 was introduced). It is also required to simultaneously support multiple versions of the same C++ standard in a single process image, because that's how you chose to implement it.
[Bug libquadmath/113260] missing from_chars/to_chars for __float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113260 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug libquadmath/113260] New: missing from_chars/to_chars for __float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113260 Bug ID: 113260 Summary: missing from_chars/to_chars for __float128 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libquadmath Assignee: unassigned at gcc dot gnu.org Reporter: g.peterh...@t-online.de Target Milestone: --- Hello, can you add this? thx Gero
[Bug libquadmath/113259] New: quadmath::nanq not support payload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113259 Bug ID: 113259 Summary: quadmath::nanq not support payload Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libquadmath Assignee: unassigned at gcc dot gnu.org Reporter: g.peterh...@t-online.de Target Milestone: --- Hello, in https://github.com/gcc-mirror/gcc/blob/master/libquadmath/math/nanq.c there is only a comment that payloads are not supported. So it is incompatible with the standard. Will this be fixed? thx Gero
[Bug libstdc++/113258] Pre-C++17 code that supplies operator new/delete crashes when mixed with post-C+17 code that uses the align_val_t variants of new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258 --- Comment #11 from Andrew Pinski --- https://github.com/gperftools/gperftools/commit/d406f2285390c402e824dd28e6992f7f890dcdf9 was the commit which fixed tcmalloc .
[Bug libfortran/110966] should matmul_c8_avx512f be updated with matmul_c8_x86-64-v4.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110966 Hongtao Liu changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING |RESOLVED CC||liuhongt at gcc dot gnu.org
[Bug libstdc++/113258] Pre-C++17 code that supplies operator new/delete crashes when mixed with post-C+17 code that uses the align_val_t variants of new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2024-01-08 --- Comment #10 from Andrew Pinski --- (In reply to Andrew Pinski from comment #9) > (In reply to Nicholas Miell from comment #8) > > What appears to actually be happening is that the libstdc++ operator > > new(std::size_t size, std::align_val_t alignment) is calling glibc's > > aligned_alloc, and then the libstdc++ operator delete(void* ptr, > > std::align_val_t alignment) is calling std::free(), which is supplied by > > tcmalloc. > > > aligned_alloc is part of C11 and C++17 and is required to be free'd by > std::free (or free in the C11 case). > > So this seems like a bug in tcmalloc not supplying an override of the C11 > function aligned_alloc. > > You would run into the same issue with a C11 application that does the same > too. From https://github.com/gperftools/gperftools/blob/365060c4213a48adb27f63d5dfad41b3dfbdd62e/NEWS#L514 : > == 30 Nov 2017 == > gperftools 2.6.2 is out! > Most notable change is recently added support for C++17 over-aligned So this is depedent on the version of tcmalloc that you are using. What version are you using?
[Bug libstdc++/113258] Pre-C++17 code that supplies operator new/delete crashes when mixed with post-C+17 code that uses the align_val_t variants of new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258 --- Comment #9 from Andrew Pinski --- (In reply to Nicholas Miell from comment #8) > What appears to actually be happening is that the libstdc++ operator > new(std::size_t size, std::align_val_t alignment) is calling glibc's > aligned_alloc, and then the libstdc++ operator delete(void* ptr, > std::align_val_t alignment) is calling std::free(), which is supplied by > tcmalloc. aligned_alloc is part of C11 and C++17 and is required to be free'd by std::free (or free in the C11 case). So this seems like a bug in tcmalloc not supplying an override of the C11 function aligned_alloc. You would run into the same issue with a C11 application that does the same too.
[Bug libstdc++/113258] Pre-C++17 code that supplies operator new/delete crashes when mixed with post-C+17 code that uses the align_val_t variants of new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258 --- Comment #8 from Nicholas Miell --- (In reply to Jonathan Wakely from comment #7) > (In reply to Nicholas Miell from comment #0) > > This is typically the result of the libstdc++ version of operator > > delete(void* ptr, std::align_val_t alignment) calling the > > application-supplied version of operator delete(void* ptr), > > But it doesn't do that. > > The libstdc++ version of operator delete(void*, size_t, align_val_t) calls > std::free directly, because that's the correct way to free memory obtained > by the libstdc++ version of the operator new(size_t, align_val_t). > Oh, I'm sorry, I did the initial investigation a couple weeks ago and only wrote this up (from memory) when I started clearing out stale browser tabs today. I guess I falsely assumed I had a better understanding of the issue than I actually did, and I looked at the wrong operator delete when I was checking my flawed assumptions. What appears to actually be happening is that the libstdc++ operator new(std::size_t size, std::align_val_t alignment) is calling glibc's aligned_alloc, and then the libstdc++ operator delete(void* ptr, std::align_val_t alignment) is calling std::free(), which is supplied by tcmalloc.
[Bug libstdc++/113258] Pre-C++17 code that supplies operator new/delete crashes when mixed with post-C+17 code that uses the align_val_t variants of new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258 --- Comment #7 from Jonathan Wakely --- (In reply to Nicholas Miell from comment #0) > This is typically the result of the libstdc++ version of operator > delete(void* ptr, std::align_val_t alignment) calling the > application-supplied version of operator delete(void* ptr), But it doesn't do that. The libstdc++ version of operator delete(void*, size_t, align_val_t) calls std::free directly, because that's the correct way to free memory obtained by the libstdc++ version of the operator new(size_t, align_val_t). If you are allocating memory with operator new(size_t, std::align_val_t) and then seeing a crash when it's deallocated with operator delete(void*) that is a bug in the application. Memory allocated by aligned-new must be deallocated by aligned-delete, see [new.delete.single] p11: If the alignment parameter is not present, ptr was returned by an allocation function without an alignment parameter. If present, the alignment argument is equal to the alignment argument passed to the allocation function that returned ptr. If present, the size argument is equal to the size argument passed to the allocation function that returned ptr.
[Bug libstdc++/113258] Pre-C++17 code that supplies operator new/delete crashes when mixed with post-C+17 code that uses the align_val_t variants of new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258 --- Comment #6 from Andrew Pinski --- (In reply to Nicholas Miell from comment #4) > No, the problem is that a pre-C++17 application is using a post-C++17 GPU > driver (well, the GPU driver is using a post-C++17 libLLVM), and the > post-C++17 version of libstdc++ is incompatible with pre-C++17 users of > libstdc++. The issue is the ABI of libLLVM changed which requires c++17 support in the application if the application overrides `operator new`. That is a change in libLLVM ABI and not in libstdc++ ABI. libstdc++ ABI didn't change here but rather the compiled code ABI changed. So in theory this is an ABI change in GCC but this is I suspect is an expected change. There is no way to support align_val_t `operator new` without overriding C++17 version too. This means either libLLVM needs to change back to making sure it does not call the aligned version (and use C++11) or the applications (and drivers) which use C++ and override `operator new` will need to also override the align_val_t version too. >Windows and macOS (and Solaris) have sensible dynamic linker semantics where >the pre-C++17 code and the post-C++17 code uses two different C++ runtimes and >furthermore the application can use tcmalloc while the GPU driver uses >whatever allocator it feels like. How do they handle it, by having an `operator new` which is named different depdent on the C++ version? Seems a little off and that itself would change the ABI too and will cause pointers passed to each way to crash when deleting too. I really doubt they handle this case that well either.
[Bug libstdc++/113258] Pre-C++17 code that supplies operator new/delete crashes when mixed with post-C+17 code that uses the align_val_t variants of new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258 --- Comment #5 from Andrew Pinski --- (In reply to Nicholas Miell from comment #3) > GCC has dealt with similar issues before, cf. bug 68210. That was a defect to the C++11 standard unlike this one.
[Bug libstdc++/113258] Pre-C++17 code that supplies operator new/delete crashes when mixed with post-C+17 code that uses the align_val_t variants of new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258 --- Comment #4 from Nicholas Miell --- (In reply to Andrew Pinski from comment #2) > So the situtation here is you have a pre-C++17 application using a C++17 > library. > > If the application was C++17 and using a C++11 library, it would just work. > > So the ABI is broken in the C++17 library rather than in libstdc++ as far as > I can tell. That is this is NOT a libstdc++ issue but the C++17 library > making sure it does not call the new `operator new`. Which means this is a > bug in LLVM No, the problem is that a pre-C++17 application is using a post-C++17 GPU driver (well, the GPU driver is using a post-C++17 libLLVM), and the post-C++17 version of libstdc++ is incompatible with pre-C++17 users of libstdc++. If GCC supplied a pre-C++17 version of libstdc++ and a post-C++17 version of libstdc++ and allowed both of them to be used simultaneously in a single application, there wouldn't be a problem. But instead GCC only supplies a post-C++17 version of libstdc++ that is supposed to be ABI compatible with all previous versions of libstdc++, yet in this case it isn't.
[Bug libstdc++/113258] Pre-C++17 code that supplies operator new/delete crashes when mixed with post-C+17 code that uses the align_val_t variants of new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258 --- Comment #3 from Nicholas Miell --- Windows and macOS (and Solaris) have sensible dynamic linker semantics where the pre-C++17 code and the post-C++17 code uses two different C++ runtimes and furthermore the application can use tcmalloc while the GPU driver uses whatever allocator it feels like. GCC has dealt with similar issues before, cf. bug 68210. One way to fix this issue would probably be to cause the libstdc++ supplied std::align_val_t variants to always invoke the pre-C++17 operators, since that is the implicit ABI contract.
[Bug libstdc++/113258] Pre-C++17 code that supplies operator new/delete crashes when mixed with post-C+17 code that uses the align_val_t variants of new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258 --- Comment #2 from Andrew Pinski --- So the situtation here is you have a pre-C++17 application using a C++17 library. If the application was C++17 and using a C++11 library, it would just work. So the ABI is broken in the C++17 library rather than in libstdc++ as far as I can tell. That is this is NOT a libstdc++ issue but the C++17 library making sure it does not call the new `operator new`. Which means this is a bug in LLVM
[Bug libstdc++/113258] Pre-C++17 code that supplies operator new/delete crashes when mixed with post-C+17 code that uses the align_val_t variants of new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258 --- Comment #1 from Andrew Pinski --- This is a C++ standard issue I suspect which cannot be fixed just in libstdc++. I suspect libc++ and MSVC's C++ library all have a similar issue too.
[Bug libstdc++/113258] New: Pre-C++17 code that supplies operator new/delete crashes when mixed with post-C+17 code that uses the align_val_t variants of new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258 Bug ID: 113258 Summary: Pre-C++17 code that supplies operator new/delete crashes when mixed with post-C+17 code that uses the align_val_t variants of new/delete Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: nmiell at gmail dot com Target Milestone: --- Correctly functioning pre-C++17 applications that supply their own versions of operator new and delete as allowed by the standard crash when mixed with correctly functioning post-C++17 shared libraries that used the std::align_val_t variants of operator new/delete. This is typically the result of the libstdc++ version of operator delete(void* ptr, std::align_val_t alignment) calling the application-supplied version of operator delete(void* ptr), and the application-supplied allocator asserting or crashing because the original pointer was produced by the libstdc++ version of operator new(std::size_t size, std::align_val_t alignment) and not the application-supplied operator new(std::size_t size). This is both a regression and an ABI breakage. A typical stack trace looks like the following: thread #1, name = 'bms_linux', stop reason = signal SIGABRT * frame #0: 0xf7f69589 [vdso]`__kernel_vsyscall + 9 frame #1: 0xf7d5a2c7 libc.so.6`__pthread_kill_implementation + 279 frame #2: 0xf7d05fc5 libc.so.6`raise + 37 frame #3: 0xf7ced370 libc.so.6`abort + 242 frame #4: 0xf7ed7e8a libtcmalloc_minimal.so.4`tcmalloc::Log(mode=kCrash, filename="", line=278, a=LogItem @ 0xff92cd0c, b=LogItem @ 0xff92cd18, c=LogItem @ 0xff92cd24, d=LogItem @ 0xff92cd30) at internal_logging.cc:120 frame #5: 0xf7ed335d libtcmalloc_minimal.so.4`(anonymous namespace)::InvalidFree(ptr=0x0a5c7d00) at tcmalloc.cc:278 frame #6: 0xf7ee4762 libtcmalloc_minimal.so.4`::tc_free(void *) [inlined] free_null_or_invalid(ptr=0x0a5c7d00, invalid_free_fn=0xb2b0) at tcmalloc.cc:1141 frame #7: 0xf7ee4751 libtcmalloc_minimal.so.4`::tc_free(void *) at tcmalloc.cc:1185 frame #8: 0xf7ee4720 libtcmalloc_minimal.so.4`::tc_free(void *) at tcmalloc.cc:1225 frame #9: 0xf7ee4720 libtcmalloc_minimal.so.4`::tc_free(void *) [inlined] do_free(ptr=0x0a5c7d00) at tcmalloc.cc:1234 frame #10: 0xf7ee4720 libtcmalloc_minimal.so.4`tc_free(ptr=0x0a5c7d00) at tcmalloc.cc:1585 frame #11: 0xf7899f4c libstdc++.so.6`operator delete(void*, std::align_val_t) + 28 frame #12: 0xeaaac2c8 libLLVM-17.so`llvm::deallocate_buffer(void*, unsigned int, unsigned int) + 40 frame #13: 0xeacd0ef6 libLLVM-17.so`llvm::DenseMap, llvm::detail::DenseMapPair>::grow(unsigned int) + 662 frame #14: 0xead0db09 libLLVM-17.so`llvm::detail::DenseMapPair* llvm::DenseMapBase, llvm::detail::DenseMapPair>, void const*, llvm::PassInfo const*, llvm::DenseMapInfo, llvm::detail::DenseMapPair>::InsertIntoBucket(llvm::detail::DenseMapPair*, void const*&&, llvm::PassInfo const*&&) + 121 frame #15: 0xead0d1fb libLLVM-17.so`llvm::PassRegistry::registerPass(llvm::PassInfo const&, bool) + 283 frame #16: 0xed0e209a libLLVM-17.so`initializeSIFoldOperandsPassOnce(llvm::PassRegistry&) + 138 frame #17: 0xeac6f832 libLLVM-17.so`std::once_flag::_Prepare_execution::_Prepare_execution>(std::once_flag&, void* (&)(llvm::PassRegistry&), std::reference_wrapper&&)::'lambda'()>(void* (&)(llvm::PassRegistry&))::'lambda'()::__invoke() + 50 frame #18: 0xf7d5d4da libc.so.6`__pthread_once_slow + 250 frame #19: 0xed0e1fd2 libLLVM-17.so`llvm::initializeSIFoldOperandsPass(llvm::PassRegistry&) + 130 frame #20: 0xed042916 libLLVM-17.so`LLVMInitializeAMDGPUTarget + 166 frame #21: 0xf238c8c7 radeonsi_dri.so`ac_init_llvm_target + 71 frame #22: 0xf7d5d4da libc.so.6`__pthread_once_slow + 250 frame #23: 0xf1ae26c0 radeonsi_dri.so`call_once + 32 frame #24: 0xf238c946 radeonsi_dri.so`ac_init_shared_llvm_once + 38 frame #25: 0xf238c968 radeonsi_dri.so`ac_init_llvm_once + 24 etc.
[Bug fortran/113245] SIZE with optional DIM argument that has the OPTIONAL+VALUE attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113245 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2024-01-07 Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #2 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2024-January/060096.html
[Bug fortran/113245] SIZE with optional DIM argument that has the OPTIONAL+VALUE attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113245 --- Comment #1 from anlauf at gcc dot gnu.org --- The following probably rather obvious patch fixes the issue: diff --git a/gcc/fortran/trans-intrinsic.cc b/gcc/fortran/trans-intrinsic.cc index d973c49380c..748cc74de89 100644 --- a/gcc/fortran/trans-intrinsic.cc +++ b/gcc/fortran/trans-intrinsic.cc @@ -8025,9 +8092,7 @@ gfc_conv_intrinsic_size (gfc_se * se, gfc_expr * expr) argse.data_not_needed = 1; gfc_conv_expr (, actual->expr); gfc_add_block_to_block (>pre, ); - cond = fold_build2_loc (input_location, NE_EXPR, logical_type_node, - argse.expr, null_pointer_node); - cond = gfc_evaluate_now (cond, >pre); + cond = gfc_conv_expr_present (actual->expr->symtree->n.sym); /* 'block2' contains the arg2 absent case, 'block' the arg2 present case; size_var can be used in both blocks. */ tree size_var = gfc_create_var (TREE_TYPE (size), "size");
[Bug target/113255] [11/12/13/14 Regression] wrong code with -O2 -mtune=k8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113255
--- Comment #3 from Uroš Bizjak ---
_.dse1 pass is removing the store for some reason, -fno-dse "fixes" the
testcase.
Before _.dse1 pass, we have:
(insn 41 40 46 4 (set (mem/c:SI (plus:DI (reg/f:DI 19 frame)
(const_int -36 [0xffdc])) [2 e[1].y+0 S4 A32])
(reg:SI 98 [ e$1$y ])) "pr113255.c":21:9 85 {*movsi_internal}
(expr_list:REG_DEAD (reg:SI 98 [ e$1$y ])
(nil)))
But _.dse1 pass decides that:
**scanning insn=41
mem: (plus:DI (reg/f:DI 19 frame)
(const_int -36 [0xffdc]))
after canon_rtx address: (plus:DI (reg/f:DI 19 frame)
(const_int -36 [0xffdc]))
gid=1 offset=-36
processing const base store gid=1[-36..-32)
mems_found = 1, cannot_delete = false
...
Locally deleting insn 41
deferring deletion of insn with uid = 41.
[Bug libfortran/113223] NAMELIST internal write missing leading blank character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113223 --- Comment #5 from GCC Commits --- The master branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:add995ec117d756e61d207041cd32f937c1a1cd9 commit r14-6986-gadd995ec117d756e61d207041cd32f937c1a1cd9 Author: Jerry DeLisle Date: Sun Jan 7 10:22:19 2024 -0800 libgfortran: Emit a space at beginning of internal unit NML. PR libgfortran/113223 libgfortran/ChangeLog: * io/write.c (namelist_write): If internal_unit precede with space. gcc/testsuite/ChangeLog: * gfortran.dg/dtio_25.f90: Update. * gfortran.dg/namelist_57.f90: Update. * gfortran.dg/namelist_65.f90: Update.
[Bug target/113231] x86_64 uses SSE instructions for `*mem <<= const` at -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113231 --- Comment #5 from GCC Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:0a8aba760f62e9d66cc5610ecc276c1f0befc651 commit r14-6985-g0a8aba760f62e9d66cc5610ecc276c1f0befc651 Author: Roger Sayle Date: Sun Jan 7 17:42:00 2024 + i386: PR target/113231: Improved costs in Scalar-To-Vector (STV) pass. This patch improves the cost/gain calculation used during the i386 backend's SImode/DImode scalar-to-vector (STV) conversion pass. The current code handles loads and stores, but doesn't consider that converting other scalar operations with a memory destination, requires an explicit load before and an explicit store after the vector equivalent. To ease the review, the significant change looks like: /* For operations on memory operands, include the overhead of explicit load and store instructions. */ if (MEM_P (dst)) igain += !optimize_insn_for_size_p () ? -COSTS_N_BYTES (8); : (m * (ix86_cost->int_load[2] + ix86_cost->int_store[2]) - (ix86_cost->sse_load[sse_cost_idx] + ix86_cost->sse_store[sse_cost_idx])); however the patch itself is complicated by a change in indentation which leads to a number of lines with only whitespace changes. For architectures where integer load/store costs are the same as vector load/store costs, there should be no change without -Os/-Oz. 2024-01-07 Roger Sayle Uros Bizjak gcc/ChangeLog PR target/113231 * config/i386/i386-features.cc (compute_convert_gain): Include the overhead of explicit load and store (movd) instructions when converting non-store scalar operations with memory destinations. Various indentation whitespace fixes. gcc/testsuite/ChangeLog PR target/113231 * gcc.target/i386/pr113231.c: New test case.
[Bug tree-optimization/113237] [14 Regression] ICE verify_ssa failed when building 500.perlbench_r since r14-6822-g01f4251b8775c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113237 --- Comment #4 from Tamar Christina --- Created attachment 57003 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57003=edit perlbench.patch submitted patch
[Bug target/113257] -march=native or -mcpu=native are ineffective, but -march=native -mcpu=native works on arm64 M2 Ultra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113257
--- Comment #1 from Sam James ---
FWIW, I did try a patch per
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110901#c4 as a quick hack in case
it's the same issue, but it didn't help:
```
--- a/gcc/config/aarch64/aarch64.h
+++ b/gcc/config/aarch64/aarch64.h
@@ -1421,7 +1421,7 @@ extern const char *host_detect_local_cpu (int argc, const
char **argv);
CONFIG_TUNE_SPEC
#define MCPU_TO_MARCH_SPEC \
- " %{mcpu=*:-march=%:rewrite_mcpu(%{mcpu=*:%*})}"
+ " %{!march=*:%{mcpu=*:-march=%:rewrite_mcpu(%{mcpu=*:%*})}}"
extern const char *aarch64_rewrite_mcpu (int argc, const char **argv);
#define MCPU_TO_MARCH_SPEC_FUNCTIONS \
```
[Bug target/113257] New: -march=native or -mcpu=native are ineffective, but -march=native -mcpu=native works on arm64 M2 Ultra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113257 Bug ID: 113257 Summary: -march=native or -mcpu=native are ineffective, but -march=native -mcpu=native works on arm64 M2 Ultra Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sjames at gcc dot gnu.org Target Milestone: --- Created attachment 57002 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57002=edit /proc/cpuinfo On arm64 M2 Ultra (Apple Mac Studio (M2 Ultra, 2023)), -march=native or -mcpu=native are ineffective, but -march=native -mcpu=native together works: ``` # gcc -v -E -x c /dev/null -o /dev/null -march=native 2>&1 | grep /cc1 /usr/libexec/gcc/aarch64-unknown-linux-gnu/13/cc1 -E -quiet -v /dev/null -o /dev/null -mlittle-endian -mabi=lp64 -dumpbase null # gcc -v -E -x c /dev/null -o /dev/null -mcpu=native 2>&1 | grep /cc1 /usr/libexec/gcc/aarch64-unknown-linux-gnu/13/cc1 -E -quiet -v /dev/null -o /dev/null -mlittle-endian -mabi=lp64 -dumpbase null # gcc -v -E -x c /dev/null -o /dev/null -march=native -mcpu=native 2>&1 | grep /cc1 /usr/libexec/gcc/aarch64-unknown-linux-gnu/13/cc1 -E -quiet -v /dev/null -o /dev/null -mlittle-endian -mabi=lp64 -march=armv8-a+crc+lse+rcpc+rdma+dotprod+aes+sha3+fp16fml+sb+ssbs+i8mm+bf16+flagm+pauth -dumpbase null ``` ``` $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/aarch64-unknown-linux-gnu/13/lto-wrapper Target: aarch64-unknown-linux-gnu Configured with: /tmp/portage/sys-devel/gcc-13.2.1_p20231216/work/gcc-13-20231216/configure --host=aarch64-unknown-linux-gnu --build=aarch64-unknown-linux-gnu --prefix=/usr --bindir=/usr/aarch64-unknown-linux-gnu/gcc-bin/13 --includedir=/usr/lib/gcc/aarch64-unknown-linux-gnu/13/include --datadir=/usr/share/gcc-data/aarch64-unknown-linux-gnu/13 --mandir=/usr/share/gcc-data/aarch64-unknown-linux-gnu/13/man --infodir=/usr/share/gcc-data/aarch64-unknown-linux-gnu/13/info --with-gxx-include-dir=/usr/lib/gcc/aarch64-unknown-linux-gnu/13/include/g++-v13 --disable-silent-rules --disable-dependency-tracking --with-python-dir=/share/gcc-data/aarch64-unknown-linux-gnu/13/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --disable-libunwind-exceptions --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 13.2.1_p20231216 p11' --with-gcc-major-version-only --enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --disable-fixed-point --enable-libgomp --disable-libssp --disable-libada --disable-cet --disable-systemtap --disable-valgrind-annotations --disable-vtable-verify --disable-libvtv --without-zstd --without-isl --enable-default-pie --enable-default-ssp --disable-bootstrap --with-build-config=bootstrap-O3 Thread model: posix Supported LTO compression algorithms: zlib gcc version 13.2.1 20231216 (Gentoo 13.2.1_p20231216 p11) ``` This came up first downstream at https://bugs.gentoo.org/830165#c11.
[Bug testsuite/52641] Test cases fail for 16-bit int targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52641 --- Comment #24 from GCC Commits --- The master branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:1c765016557eb8d4c576bfe22c10abf0b398fbab commit r14-6982-g1c765016557eb8d4c576bfe22c10abf0b398fbab Author: Georg-Johann Lay Date: Sun Jan 7 16:53:21 2024 +0100 testsuite/52641: Fix fallout from sloppy tests. gcc/testsuite/ PR testsuite/52641 * gcc.dg/torture/pr110838.c: Use proper shift offset to get MSB or int. * gcc.dg/torture/pr112282.c: Use at least 32 bits for :20 bit-fields. * gcc.dg/tree-ssa/bitcmp-5.c: Use integral type with 32 bits or more. * gcc.dg/tree-ssa/bitcmp-6.c: Same. * gcc.dg/tree-ssa/cltz-complement-max.c: Same. * gcc.dg/tree-ssa/cltz-max.c: Same. * gcc.dg/tree-ssa/if-to-switch-8.c: Use literals that fit int. * gcc.dg/tree-ssa/if-to-switch-9.c [avr]: Set case-values-threshold=3. * gcc.dg/tree-ssa/negneg-3.c: Discriminate [not] large_double. * gcc.dg/tree-ssa/phi-opt-25b.c: Use types of correct widths for __builtin_bswapN. * gcc.dg/tree-ssa/pr55177-1.c: Same. * gcc.dg/tree-ssa/popcount-max.c: Use int32_t where required. * gcc.dg/tree-ssa/pr111583-1.c: Use intptr_t as needed. * gcc.dg/tree-ssa/pr111583-2.c: Same.
[Bug tree-optimization/90693] Missing popcount simplifications
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90693
--- Comment #11 from Piotr Siupa ---
Thanks! Now the generated assembly is one instruction shorter.
It works for:
bool foo(unsigned x)
{
[[assume(x != 0)]];
return std::has_single_bit(x);
}
and for:
bool foo(unsigned x)
{
if (x == 0)
std::unreachable();
else
return std::has_single_bit(x);
}
However, I've noticed that:
bool foo(unsigned x)
{
if (x == 0)
return true;
else
return std::has_single_bit(x);
}
still uses (X ^ (X - 1)) > (X - 1).
[Bug testsuite/52641] Test cases fail for 16-bit int targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52641 --- Comment #23 from GCC Commits --- The master branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:7d60b1b78538c5606e8d35cdba8f565e7785d9c6 commit r14-6981-g7d60b1b78538c5606e8d35cdba8f565e7785d9c6 Author: Georg-Johann Lay Date: Sun Jan 7 13:17:19 2024 +0100 testsuite/52641: Fix fallout from sloppy tests. gcc/testsuite/ PR testsuite/52641 * gcc.dg/memchr-3.c [avr]: Anticipate -Wbuiltin-declaration-mismatch. * gcc.dg/pr103207.c: Use __INT32_TYPE__ instead of int. * gcc.dg/pr103451.c [void* != long]: Anticipate -Wpointer-to-int-cast. * gcc.dg/pr110496.c [void* != long]: Anticipate -Wint-to-pointer-cast. * gcc.dg/pr109977.c: Use __SIZEOF_DOUBLE__ instead of 8. * gcc.dg/pr110506-2.c: Use __UINT32_TYPE__ for uint32_t. * gcc.dg/pr110582.c: Require int32plus. * gcc.dg/pr111039.c: [sizeof(int) < 4]: Use __INT32_TYPE__. * gcc.dg/pr111599.c: Same. * gcc.dg/builtin-dynamic-object-size-0.c: Require size20plus. * gcc.dg/builtin-object-size-1.c [avr]: Skip tests with strndup. * gcc.dg/builtin-object-size-2.c: Same. * gcc.dg/builtin-object-size-3.c: Same. * gcc.dg/builtin-object-size-4.c: Same. * gcc.dg/pr111070.c: Use __UINTPTR_TYPE__ instead of unsigned long. * gcc.dg/debug/btf/btf-pr106773.c: Same. * gcc.dg/debug/btf/btf-bitfields-2.c: [sizeof(int) < 4]: Use __UINT32_TYPE__.
[Bug testsuite/52641] Test cases fail for 16-bit int targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52641 --- Comment #22 from GCC Commits --- The master branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:c2e66755b6b6336dd5d93da3f4effb81d236397e commit r14-6980-gc2e66755b6b6336dd5d93da3f4effb81d236397e Author: Georg-Johann Lay Date: Sat Jan 6 19:37:27 2024 +0100 testsuite/52641: Fix sloppy tests that did not care for sizeof(int)=2 etc. gcc/testsuite/ PR testsuite/52641 * gcc.c-torture/compile/attr-complex-method-2.c [target=avr]: Check for "divsc3" as double = float per default. * gcc.c-torture/compile/pr106537-1.c: Use __INTPTR_TYPE__ instead of hard-coded "long". * gcc.c-torture/compile/pr106537-2.c: Same. * gcc.c-torture/compile/pr106537-3.c: Same. * gcc.c-torture/execute/20230630-3.c: Use __INT32_TYPE__ for bit-field wider than 16 bits. * gcc.c-torture/execute/20230630-4.c: Same. * gcc.c-torture/execute/pr109938.c: Require int32plus. * gcc.c-torture/execute/pr109986.c: Same. * gcc.dg/fold-ior-4.c: Same. * gcc.dg/fold-ior-5.c: Same * gcc.dg/fold-parity-5.c: Same. * gcc.dg/fold-popcount-5.c: Same. * gcc.dg/builtin-bswap-13.c [sizeof(int) < 4]: Use __INT32_TYPE__ instead of int. * gcc.dg/builtin-bswap-14.c: Use __INT32_TYPE__ instead of int where required by code. * gcc.dg/c23-constexpr-9.c: Require large_double. * gcc.dg/c23-nullptr-1.c [target=avr]: xfail. * gcc.dg/loop-unswitch-10.c: Require size32plus. * gcc.dg/loop-unswitch-14.c: Same. * gcc.dg/loop-unswitch-11.c: Require int32. * gcc.dg/pr101836.c: Use __SIZEOF_INT instead of hard-coded 4. * gcc.dg/pr101836_1.c: Same. * gcc.dg/pr101836_2.c: Same. * gcc.dg/pr101836_3.c: Same.
[Bug target/108849] __declspec(code_seg("segname")) does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108849 --- Comment #2 from Pali Rohár --- `section` is the best option. MS says about it: https://learn.microsoft.com/en-us/cpp/cpp/code-seg-declspec > The code_seg declaration attribute names an executable text segment in the > .obj file in which the object code for the function or class member functions > is stored. > A segment is a named block of data in an .obj file that is loaded into memory > as a unit. A text segment is a segment that contains executable code. The > term section is often used interchangeably with segment. > By default, when no code_seg is specified, object code is put in a segment > named .text.
[Bug target/113255] [11/12/13/14 Regression] wrong code with -O2 -mtune=k8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113255 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2 Keywords|needs-bisection | CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Started with r11-963-g80d6f89e78fc3b772701988cc73aa8e8006283be
[Bug fortran/111938] Missing OpenACC/Fortran handling in 'gcc/fortran/frontend-passes.c'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111938 Thomas Koenig changed: What|Removed |Added Keywords||missed-optimization Severity|normal |enhancement Ever confirmed|0 |1 CC||tkoenig at gcc dot gnu.org Last reconfirmed||2024-01-07 Status|UNCONFIRMED |NEW --- Comment #2 from Thomas Koenig --- I know next to nothing about OpenACC, so I cannot really do this (but I know frontend-passes.cc). Could you maybe provide a patch, or a list of what should go where? Confirmed.
[Bug c++/112899] odr-using constexpr static data member of class exported from module results in linker error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112899 --- Comment #2 from GCC Commits --- The master branch has been updated by Nathaniel Shead : https://gcc.gnu.org/g:a71c3977d24722ac8ee28d8844c4f96a151f75ab commit r14-6979-ga71c3977d24722ac8ee28d8844c4f96a151f75ab Author: Nathaniel Shead Date: Wed Jan 3 09:28:43 2024 +1100 c++: Fix ICE when writing nontrivial variable initializers The attached testcase Patrick found in PR c++/112899 ICEs because it is attempting to write a variable initializer that is no longer in the static_aggregates map. The issue is that, for non-header modules, the loop in c_parse_final_cleanups prunes the static_aggregates list, which means that by the time we get to emitting module information those initialisers have been lost. However, we don't actually need to write non-trivial initialisers for non-header modules, because they've already been emitted as part of the module TU itself. Instead let's just only write the initializers from header modules (which skipped writing them in c_parse_final_cleanups). gcc/cp/ChangeLog: * module.cc (trees_out::write_var_def): Only write initializers in header modules. gcc/testsuite/ChangeLog: * g++.dg/modules/init-5_a.C: New test. * g++.dg/modules/init-5_b.C: New test. Signed-off-by: Nathaniel Shead
[Bug c++/109679] export using for functions does not work as specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109679 --- Comment #4 from GCC Commits --- The master branch has been updated by Nathaniel Shead : https://gcc.gnu.org/g:63b531e6f8783e8624502d890dc422379de47a9a commit r14-6978-g63b531e6f8783e8624502d890dc422379de47a9a Author: Nathaniel Shead Date: Wed Jan 3 15:29:51 2024 +1100 c++: Export usings referring to global module fragment [PR109679] This patch stops 'add_binding_entity' from ignoring all names in the global module fragment, since they should still be exported if named in an exported using-declaration. PR c++/109679 gcc/cp/ChangeLog: * module.cc (depset::hash::add_binding_entity): Don't skip names in the GMF if they've been exported with a using declaration. gcc/testsuite/ChangeLog: * g++.dg/modules/using-11.h: New test. * g++.dg/modules/using-11_a.C: New test. * g++.dg/modules/using-11_b.C: New test. Signed-off-by: Nathaniel Shead
[Bug c++/110808] [modules] Internal Compiler Error in check_mergeable_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110808 --- Comment #2 from GCC Commits --- The master branch has been updated by Nathaniel Shead : https://gcc.gnu.org/g:7f24446a3cf67d1346c78b4667fba74b73a23302 commit r14-6977-g7f24446a3cf67d1346c78b4667fba74b73a23302 Author: Nathaniel Shead Date: Fri Nov 24 16:26:43 2023 +1100 c++: Follow module grammar more closely [PR110808] This patch cleans up the parsing of module-declarations and import-declarations to more closely follow the grammar defined by the standard. For instance, currently we allow declarations like 'import A:B', even from an unrelated source file (not part of module A), which causes errors in merging declarations. However, the syntax in [module.import] doesn't even allow this form of import, so this patch prevents this from parsing at all and avoids the error that way. Additionally, we sometimes allow statements like 'import :X' or 'module :X' even when not in a named module, and this causes segfaults, so we disallow this too. PR c++/110808 gcc/cp/ChangeLog: * parser.cc (cp_parser_module_name): Rewrite to handle module-names and module-partitions independently. (cp_parser_module_partition): New function. (cp_parser_module_declaration): Parse module partitions explicitly. Don't change state if parsing module decl failed. (cp_parser_import_declaration): Handle different kinds of import-declarations locally. gcc/testsuite/ChangeLog: * g++.dg/modules/part-hdr-1_c.C: Fix syntax. * g++.dg/modules/part-mac-1_c.C: Likewise. * g++.dg/modules/mod-invalid-1.C: New test. * g++.dg/modules/part-8_a.C: New test. * g++.dg/modules/part-8_b.C: New test. * g++.dg/modules/part-8_c.C: New test. Signed-off-by: Nathaniel Shead
[Bug target/108849] __declspec(code_seg("segname")) does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108849
Arsen Arsenović changed:
What|Removed |Added
CC||arsen at gcc dot gnu.org
--- Comment #1 from Arsen Arsenović ---
I think that declspec is currently simply an alias to attribute, IIUC (though,
I've not used or written code for w32 in many years):
/* Support the __declspec keyword by turning them into attributes.
Note that the current way we do this may result in a collision
with predefined attributes later on. This can be solved by using
one attribute, say __declspec__, and passing args to it. The
problem with that approach is that args are not accumulated: each
new appearance would clobber any existing args. */
if (TARGET_DECLSPEC)
builtin_define ("__declspec(x)=__attribute__((x))");
GCC currently does not assign code_seg to any attribute, so perhaps it could be
aliased on TARGET_DECLSPEC platforms to `section'? I'm not sure if that is
correct, I've never looked at the PE spec either.
