[Bug tree-optimization/115337] wrong code with _BitInt() __builtin_stdc_first_leading_one/__builtin_clzg (with -1 as second arg) at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115337 --- Comment #2 from Andrew Pinski --- Looks like the code in `cfn_clz::fold_range` in gimple-range-op.cc assume that the return value for defining of 0 should only be positive. `cfn_ctz::fold_range` has a similar issue too. As a seperate note I notice: ``` // Implement range operator for CFN_BUILT_IN_POPCOUNT. class cfn_popcount : public cfn_ffs ``` That seems wrong, popcount is not related to ffs (ffs is more related to clz/ctz).
[Bug tree-optimization/115337] wrong code with _BitInt() __builtin_stdc_first_leading_one() at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115337
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC||aldyh at gcc dot gnu.org,
||pinskia at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed||2024-06-04
--- Comment #1 from Andrew Pinski ---
Confirmed.
# RANGE [irange] int [0, +INF]
_1 = .CLZ (_2, -1);
Is WRONG in evrp. The range is [-1, +INF].
Reduced testcase:
```
[[gnu::noinline]]
int
foo (unsigned _BitInt (129) z)
{
int t = __builtin_stdc_first_leading_one (z);
return t == 0;
}
int main()
{
if (! foo(0))
__builtin_abort();
}
```
[Bug tree-optimization/115337] New: wrong code with _BitInt() __builtin_stdc_first_leading_one() at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115337 Bug ID: 115337 Summary: wrong code with _BitInt() __builtin_stdc_first_leading_one() at -O2 Product: gcc Version: 15.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz CC: jakub at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 58338 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58338=edit reduced testcase Output: $ x86_64-pc-linux-gnu-gcc -O2 testcase.c $ ./a.out Aborted $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r15-929-20240530161758-g46d931b3dd3-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --enable-libsanitizer --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r15-929-20240530161758-g46d931b3dd3-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 15.0.0 20240530 (experimental) (GCC)
[Bug other/115334] new test case gcc.dg/vect/pr112325.c from r15-919-gef27b91b62c3aa fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115334
--- Comment #2 from Hongtao Liu ---
diff --git a/gcc/testsuite/gcc.dg/vect/pr112325.c
b/gcc/testsuite/gcc.dg/vect/pr112325.c
index dea6cca3b86..143903beab2 100644
--- a/gcc/testsuite/gcc.dg/vect/pr112325.c
+++ b/gcc/testsuite/gcc.dg/vect/pr112325.c
@@ -3,6 +3,7 @@
/* { dg-require-effective-target vect_int } */
/* { dg-require-effective-target vect_shift } */
/* { dg-additional-options "-mavx2" { target x86_64-*-* i?86-*-* } } */
+/* { dg-additional-options "--param max-completely-peeled-insns=200" { target
powerpc64*-*-* } } */
typedef unsigned short ggml_fp16_t;
static float table_f32_f16[1 << 16];
Does this patch work for you?
[Bug target/115299] [14/15 regression] pr86722.c failed to eliminate branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115299 --- Comment #5 from GCC Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:4d207044195b97ecb27c72a7dc987eb8b86644a0 commit r15-1003-g4d207044195b97ecb27c72a7dc987eb8b86644a0 Author: liuhongt Date: Tue Jun 4 10:13:09 2024 +0800 Adjust testcase for -march=cascadelake gcc/testsuite/ChangeLog: PR target/115299 * gcc.target/i386/pr86722.c: Also scan for blendvpd.
[Bug middle-end/114532] gcc -fno-common option causes performance degradation on certain architectures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114532 Sam James changed: What|Removed |Added CC||kristerw at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=85678 --- Comment #3 from Sam James --- As David said at https://inbox.sourceware.org/gcc/d92b8262-5835-a7b1-363d-709724a8d...@hesbynett.no/, I'd expect it to improve performance in that we're no longer pessimising by forcing them to be common, but AFAIK there's no specific optimisation otherwise. http://kristerw.blogspot.com/2016/11/tentative-variable-definitions-and-fno.html is a nice writeup about it.
[Bug middle-end/114532] gcc -fno-common option causes performance degradation on certain architectures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114532 Zhaohaifeng changed: What|Removed |Added CC||zhaohaifeng4 at huawei dot com --- Comment #2 from Zhaohaifeng --- (In reply to Andrew Pinski from comment #1) > ``` > Rec_Pointer Ptr_Glob, > Next_Ptr_Glob; > int Int_Glob; > Boolean Bool_Glob; > charCh_1_Glob, > Ch_2_Glob; > int Arr_1_Glob [50]; > int Arr_2_Glob [50] [50]; > ``` > > Maybe the order of these changed in the layout of the final executable. > In the case of -fcommon, the layout of these are handled by the linker while > with -fno-common, they are handled by compiler into the assembly into the > specific section (and then the sections are combined/laid out by the linker). > > So maybe look at the linker map and compare it to what GCC does with > -fno-common in the .s file. Some test results: 1. Using gcc 10.3 the variables are arranged from the last Dhrystone_Per_Second to the first Ptr_Glob, both in .s file and the final binary. If we change the sequence of the variables in the source code, the sequence in assembly and binary is also changed as in source code. 2. Using gcc 8.5 the variables are arranged specially both in assembly and final binary,If the variable sequence is changed in the source code, the sequence in assembly and binary is NOT changed. Do we expect the fcommon option do some performance optimizatin? How does fcommon arrange the variables?
[Bug other/115334] new test case gcc.dg/vect/pr112325.c from r15-919-gef27b91b62c3aa fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115334 Hongtao Liu changed: What|Removed |Added CC||liuhongt at gcc dot gnu.org --- Comment #1 from Hongtao Liu --- power backend set param_max_completely_peeled_insns to 400, so the inner loop is still completed unrolled. So the testcase needs extra option for power backend --param max-completely-peeled-insns=200.
[Bug target/115336] [15] rv64gcv_zvl256b miscompile at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115336 Patrick O'Neill changed: What|Removed |Added Keywords||wrong-code Target||riscv*-*-* CC||ewlu at rivosinc dot com, ||juzhe.zhong at rivai dot ai, ||kito.cheng at gmail dot com, ||rdapp at gcc dot gnu.org, ||vineetg at gcc dot gnu.org --- Comment #1 from Patrick O'Neill --- Misread the assignment statement. All values should be 0 or 1.
[Bug target/115336] New: [15] rv64gcv_zvl256b miscompile at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115336
Bug ID: 115336
Summary: [15] rv64gcv_zvl256b miscompile at -O3
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick at rivosinc dot com
Target Milestone: ---
Testcase:
short d[19];
_Bool e[100][19][19];
_Bool f[1];
int main()
{
for (long g = 0; g < 19; ++g)
d[g] = 3;
_Bool(*h)[19][19] = e;
for (short g = 0; g < 9; g++)
for (int i = 4; i < 16; i += 3)
f[i * 9 + g] = d[i] ?: h[g][i][2];
for (long i = 120; i < 126; ++i)
__builtin_printf("%d\n", f[i]);
}
Commands:
> /scratch/tc-testing/tc-may-28/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc
> -march=rv64gcv_zvl256b -O3 red.c -o red.out
> QEMU_CPU=rv64,vlen=256,v=true,vext_spec=v1.0,zve32f=true,zve64f=true
> /scratch/tc-testing/tc-may-28/build-rv64gcv/bin/qemu-riscv64 red.out
1
165
5
1
1
73
> /scratch/tc-testing/tc-may-28/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc
> red.c -o red.out
> /scratch/tc-testing/tc-may-28/build-rv64gcv/bin/qemu-riscv64 red.out
1
1
1
1
1
1
All values should be 0 or 1 or _maybe_ 3.
Found via fuzzer
[Bug libgomp/109452] omp_init_lock_with_hint() and omp_init_nest_lock_with_hint() are undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109452 Rajesh Shashi Kumar changed: What|Removed |Added CC||reachrajesh747 at gmail dot com --- Comment #2 from Rajesh Shashi Kumar --- I encountered the same issue. I would like to note that this also breaks the OpenMP benchmark suites such as https://github.com/EPCCed/epcc-openmp-microbenchmarks from https://www.openmp.org/resources/openmp-benchmarks/. These benchmarks compile fine with LLVM+libomp so I believe this needs to be fixed to be in accordance with the OpenMP 5.0 specification.
[Bug c++/115335] New: std::span at method is missing feature test macro __cpp_lib_span >= 202311L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115335 Bug ID: 115335 Summary: std::span at method is missing feature test macro __cpp_lib_span >= 202311L Product: gcc Version: 14.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: gcc at ebasoft dot com.pl Target Milestone: --- gcc (Gentoo 14.1.1_p20240518 p1) 14.1.1 20240516 In gcc stdlibc++ 14 there is method span<>::at added that should be visible only to standard c++26. https://en.cppreference.com/w/cpp/container/span/at But implementation is missing feature test macro __cpp_lib_span >= 202311L and this method is visible for all standards backward in c++20 and c++23. availability in backward standards makes difficult to refactor code for example from vector to span that will be still portable with older gcc like 13 when it is being done on platform with gcc libstdc++ 14 as there is no compiler error when method at is being used after refactoring vector to span.
[Bug target/115324] [12/13/14/15 Regression] PCH of rs6000 builtins broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115324
--- Comment #3 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:4cf2de9b5268224816a3d53fdd2c3d799ebfd9c8
commit r15-1001-g4cf2de9b5268224816a3d53fdd2c3d799ebfd9c8
Author: Jakub Jelinek
Date: Mon Jun 3 23:11:06 2024 +0200
rs6000: Fix up PCH in --enable-host-pie builds [PR115324]
PCH doesn't work properly in --enable-host-pie configurations on
powerpc*-linux*.
The problem is that the rs6000_builtin_info and rs6000_instance_info
arrays mix pointers to .rodata/.data (bifname and attr_string point
to string literals in .rodata section, and the next member is either NULL
or _instance_info[XXX]) and GC member (tree fntype).
Now, for normal GC this works just fine, we emit
{
_instance_info[0].fntype,
1 * (RS6000_INST_MAX),
sizeof (rs6000_instance_info[0]),
_ggc_mx_tree_node,
_pch_nx_tree_node
},
{
_builtin_info[0].fntype,
1 * (RS6000_BIF_MAX),
sizeof (rs6000_builtin_info[0]),
_ggc_mx_tree_node,
_pch_nx_tree_node
},
GC roots which are strided and thus cover only the fntype members of all
the elements of the two arrays.
For PCH though it actually results in saving those huge arrays (one is
130832 bytes, another 81568 bytes) into the .gch files and loading them
back
in full. While the bifname and attr_string and next pointers are marked as
GTY((skip)), they are actually saved to point to the .rodata and .data
sections of the process which writes the PCH, but because cc1/cc1plus etc.
are position independent executables with --enable-host-pie, when it is
loaded from the PCH file, it can point in a completely different addresses
where nothing is mapped at all or some random different thing appears at.
While gengtype supports the callback option, that one is meant for
relocatable function pointers and doesn't work in the case of GTY arrays
inside of .data section anyway.
So, either we'd need to add some further GTY extensions, or the following
patch instead reworks it such that the fntype members which were the only
reason for PCH in those arrays are moved to separate arrays.
Size-wise in .data sections it is (in bytes):
vanillapatched
rs6000_builtin_info 130832 110704
rs6000_instance_info 81568 40784
rs6000_overload_info 7392 7392
rs6000_builtin_info_fntype0 10064
rs6000_instance_info_fntype 0 20392
sum 219792 189336
where previously we saved/restored for PCH those 130832+81568 bytes, now we
save/restore just 10064+20392 bytes, so this change is beneficial for the
data section size.
Unfortunately, it grows the size of the rs6000_init_generated_builtins
function, vanilla had 218328 bytes, patched has 228668.
When I applied
void
rs6000_init_generated_builtins ()
{
+ bifdata *rs6000_builtin_info_p;
+ tree *rs6000_builtin_info_fntype_p;
+ ovlddata *rs6000_instance_info_p;
+ tree *rs6000_instance_info_fntype_p;
+ ovldrecord *rs6000_overload_info_p;
+ __asm ("" : "=r" (rs6000_builtin_info_p) : "0" (rs6000_builtin_info));
+ __asm ("" : "=r" (rs6000_builtin_info_fntype_p) : "0"
(rs6000_builtin_info_fntype));
+ __asm ("" : "=r" (rs6000_instance_info_p) : "0" (rs6000_instance_info));
+ __asm ("" : "=r" (rs6000_instance_info_fntype_p) : "0"
(rs6000_instance_info_fntype));
+ __asm ("" : "=r" (rs6000_overload_info_p) : "0" (rs6000_overload_info));
+ #define rs6000_builtin_info rs6000_builtin_info_p
+ #define rs6000_builtin_info_fntype rs6000_builtin_info_fntype_p
+ #define rs6000_instance_info rs6000_instance_info_p
+ #define rs6000_instance_info_fntype rs6000_instance_info_fntype_p
+ #define rs6000_overload_info rs6000_overload_info_p
+
hack by hand, the size of the function is 209700 though, so if really
wanted, we could add __attribute__((__noipa__)) to the function when
building with recent enough GCC and pass pointers to the first elements
of the 5 arrays to the function as arguments. If you want such a change,
could that be done incrementally?
2024-06-03 Jakub Jelinek
PR target/115324
* config/rs6000/rs6000-gen-builtins.cc (write_decls): Remove
GTY markup from struct bifdata and struct ovlddata and remove their
fntype members. Change next member in struct ovlddata and
first_instance member of struct ovldrecord to have int type rather
than struct ovlddata *. Remove GTY markup from rs6000_builtin_info
and rs6000_instance_info arrays, declare new
rs6000_builtin_info_fntype and rs6000_instance_info_fntype arrays,
[Bug c++/115012] noptr-abstract-pack-declarator parsing bug with T... [N]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115012 --- Comment #3 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:48c3e5a4f935d6b8cd9ef7c51995e3b29ceb8be7 commit r15-1000-g48c3e5a4f935d6b8cd9ef7c51995e3b29ceb8be7 Author: Jakub Jelinek Date: Mon Jun 3 23:07:08 2024 +0200 c++: Fix parsing of abstract-declarator starting with ... followed by opening paren [PR115012] The C++26 P2662R3 Pack indexing paper mentions that both GCC and MSVC don't handle T...[10] parameter declaration when T is a pack. And apparently neither T...(args). While the former will change meaning in C++26, T...(args) is still valid even in C++26. The following patch handles just the T...(args) case in cp_parser_direct_declarator. 2024-06-03 Jakub Jelinek PR c++/115012 * parser.cc (cp_parser_direct_declarator): Handle abstract declarator starting with ... followed by opening paren. * g++.dg/cpp0x/variadic185.C: New test.
[Bug c++/115319] ICE when mutating a captured parameter in an explicit-this lambda if a capture is not trivially copyable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115319 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Last reconfirmed||2024-06-03 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Marek Polacek --- Confirmed. > Said friend claims to encounter like billions of ICEs every day Highly unlikely. But good bug reports are always welcome.
[Bug libstdc++/100667] [11/12 Regression] std::tuple cannot be constructed from A&&, if A not defined (only forward declared)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100667 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #17 from Jonathan Wakely --- I think this is fixed now then.
[Bug libstdc++/105258] std::get_temporary_buffer() does not respect alignment (affects std::stable_sort())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105258 --- Comment #9 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:b0efdcbf58a76af3b8fff75f1d53d334fb5b46ee commit r15-997-gb0efdcbf58a76af3b8fff75f1d53d334fb5b46ee Author: Jonathan Wakely Date: Wed Apr 13 13:03:44 2022 +0100 libstdc++: Handle extended alignment in std::get_temporary_buffer [PR105258] This adds extended alignment support to std::get_temporary_buffer etc. so that when std::stable_sort uses a temporary buffer it works for overaligned types. Also simplify the _Temporary_buffer type by using RAII for the allocation, via a new data member. This simplifies the _Temporary_buffer constructor and destructor by makingthem only responsible for constructing and destroying the elements, not managing the memory. libstdc++-v3/ChangeLog: PR libstdc++/105258 * include/bits/stl_tempbuf.h (__detail::__get_temporary_buffer): New function to do allocation for get_temporary_buffer, with extended alignment support. (__detail::__return_temporary_buffer): Support extended alignment. (get_temporary_buffer): Use __get_temporary_buffer. (return_temporary_buffer): Support extended alignment. Add deprecated attribute. (_Temporary_buffer): Move allocation and deallocation into a subobject and remove try-catch block in constructor. (__uninitialized_construct_buf): Use argument deduction for value type. * testsuite/20_util/temporary_buffer.cc: Add dg-warning for new deprecated warning. * testsuite/25_algorithms/stable_sort/overaligned.cc: New test.
[Bug fortran/83865] ICE in wide_int_to_tree_1, at tree.c:1567
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83865 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #6 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2024-June/060544.html
[Bug middle-end/109849] suboptimal code for vector walking loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849 --- Comment #37 from GCC Commits --- The releases/gcc-14 branch has been updated by Francois Dumont : https://gcc.gnu.org/g:955202eb2cdbe2bc74c626bce90ee1eac410ad4f commit r14-10272-g955202eb2cdbe2bc74c626bce90ee1eac410ad4f Author: François Dumont Date: Sat Jun 1 22:17:19 2024 +0200 libstdc++: Fix -Wstringop-overflow warning coming from std::vector [PR109849] libstdc++-v3/ChangeLog: PR libstdc++/109849 * include/bits/vector.tcc (std::vector<>::_M_range_insert(iterator, _FwdIt, _FwdIt, forward_iterator_tag))[__cplusplus < 201103L]: Add __builtin_unreachable expression to tell the compiler that the allocated buffer is large enough to receive current elements plus the elements of the range to insert. (cherry picked from commit 0426be454448f8cfb9db21f4f669426afb7b57c8)
[Bug middle-end/109849] suboptimal code for vector walking loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849 --- Comment #36 from GCC Commits --- The master branch has been updated by Francois Dumont : https://gcc.gnu.org/g:0426be454448f8cfb9db21f4f669426afb7b57c8 commit r15-996-g0426be454448f8cfb9db21f4f669426afb7b57c8 Author: François Dumont Date: Sat Jun 1 22:17:19 2024 +0200 libstdc++: Fix -Wstringop-overflow warning coming from std::vector [PR109849] libstdc++-v3/ChangeLog: PR libstdc++/109849 * include/bits/vector.tcc (std::vector<>::_M_range_insert(iterator, _FwdIt, _FwdIt, forward_iterator_tag))[__cplusplus < 201103L]: Add __builtin_unreachable expression to tell the compiler that the allocated buffer is large enough to receive current elements plus the elements of the range to insert.
[Bug libstdc++/88545] std::find compile to memchr in trivial random access cases (patch)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88545 --- Comment #7 from AK --- Is there a plan to push a patch for this?
[Bug tree-optimization/107986] [12/13/14/15 Regression] Bogus -Warray-bounds diagnostic with std::sort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107986 teodor_spaeren at riseup dot net changed: What|Removed |Added CC||teodor_spaeren at riseup dot net --- Comment #12 from teodor_spaeren at riseup dot net --- This just hit me on gcc 14.1: https://godbolt.org/z/31G5dxz55
[Bug tree-optimization/104165] [12 Regression] -Warray-bounds for unreachable code inlined from std::sort()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104165 --- Comment #13 from Xi Ruoyao --- For anyone attempting to claim this not fixed for 13 or later please see PR107986 first.
[Bug tree-optimization/104165] [12 Regression] -Warray-bounds for unreachable code inlined from std::sort()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104165 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #12 from Xi Ruoyao --- (In reply to teodor_spaeren from comment #11) > This just hit me on gcc 14.1: > > https://godbolt.org/z/31G5dxz55 It's PR107986 and not this one. The underlying reason is different.
[Bug c/114493] [11/12/13/14/15 Regression] internal compiler error: in fld_incomplete_type_of with may_alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114493 --- Comment #10 from Jakub Jelinek --- Created attachment 58337 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58337=edit gcc15-pr114493.patch Untested fix.
[Bug c/114493] [11/12/13/14/15 Regression] internal compiler error: in fld_incomplete_type_of with may_alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114493 --- Comment #9 from Jakub Jelinek --- That was added for C++ in PR70512.
[Bug target/115333] -march=native sets --param "l2-cache-size=1024" on Ryzen 7 7800X3D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115333 --- Comment #3 from Xi Ruoyao --- Maybe we should make it the L3 size like Intel but I'm not sure. See the reasoning in PR87444 comments.
[Bug c/114493] [11/12/13/14/15 Regression] internal compiler error: in fld_incomplete_type_of with may_alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114493
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8 from Jakub Jelinek ---
This doesn't ICE in C++, because the C++ FE forcibly updates the corresponding
pointer types in:
#0 fixup_may_alias (klass=) at
../../gcc/cp/class.cc:2328
#1 0x00456835 in fixup_attribute_variants (t=) at ../../gcc/cp/class.cc:2354
#2 0x006f3024 in cp_parser_class_head (parser=0x7fffea2dea80,
nested_name_specifier_p=0x7fffd5ff) at ../../gcc/cp/parser.cc:27831
/* KLASS is a class that we're applying may_alias to after the body is
parsed. Fixup any POINTER_TO and REFERENCE_TO types. The
canonical type(s) will be implicitly updated. */
static void
fixup_may_alias (tree klass)
{
tree t, v;
for (t = TYPE_POINTER_TO (klass); t; t = TYPE_NEXT_PTR_TO (t))
for (v = TYPE_MAIN_VARIANT (t); v; v = TYPE_NEXT_VARIANT (v))
TYPE_REF_CAN_ALIAS_ALL (v) = true;
for (t = TYPE_REFERENCE_TO (klass); t; t = TYPE_NEXT_REF_TO (t))
for (v = TYPE_MAIN_VARIANT (t); v; v = TYPE_NEXT_VARIANT (v))
TYPE_REF_CAN_ALIAS_ALL (v) = true;
}
Now, fixup_attribute_variants also does:
for (variants = TYPE_NEXT_VARIANT (t);
variants;
variants = TYPE_NEXT_VARIANT (variants))
{
/* These are the two fields that check_qualified_type looks at and
are affected by attributes. */
TYPE_ATTRIBUTES (variants) = attrs;
unsigned valign = align;
if (TYPE_USER_ALIGN (variants))
valign = MAX (valign, TYPE_ALIGN (variants));
else
TYPE_USER_ALIGN (variants) = user_align;
SET_TYPE_ALIGN (variants, valign);
TYPE_PACKED (variants) = packed;
if (may_alias)
fixup_may_alias (variants);
}
I think the TYPE_ATTRIBUTES update isn't needed, because
decl_attributes (, attributes, (int) ATTR_FLAG_TYPE_IN_PLACE);
should update the variants already:
984 TYPE_ATTRIBUTES (*anode) = r;
985 /* If this is the main variant, also push the
attributes
986 out to the other variants. */
987 if (*anode == TYPE_MAIN_VARIANT (*anode))
988 {
989 for (tree variant = *anode; variant;
990variant = TYPE_NEXT_VARIANT (variant))
991 {
992 if (TYPE_ATTRIBUTES (variant) == old_attrs)
993 TYPE_ATTRIBUTES (variant)
994 = TYPE_ATTRIBUTES (*anode);
995 else if (!find_same_attribute
996(attr, TYPE_ATTRIBUTES (variant)))
997 TYPE_ATTRIBUTES (variant) = tree_cons
998 (name, args, TYPE_ATTRIBUTES (variant));
999 }
1000}
Seems finish_struct doesn't actually call layout_type on the type variants,
wonder what does that, but I'd think that stuff like TYPE_USER_ALIGN,
TYPE_ALIGN would be finalized when layout_type is performed for those.
TYPE_PACKED is apparently done in
finish_record_layout even for the variants (called from layout_type).
[Bug other/115334] New: new test case gcc.dg/vect/pr112325.c from r15-919-gef27b91b62c3aa fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115334 Bug ID: 115334 Summary: new test case gcc.dg/vect/pr112325.c from r15-919-gef27b91b62c3aa fails Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:ef27b91b62c3aa8841c02665dffa8914c742fd37, r15-919-gef27b91b62c3aa This fails on both BE and LE on powerpc64. make -k check-gcc RUNTESTFLAGS="vect.exp=gcc.dg/vect/pr112325.c" FAIL: gcc.dg/vect/pr112325.c scan-tree-dump-times vect "vectorized 1 loops" 1 FAIL: gcc.dg/vect/pr112325.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 1 commit ef27b91b62c3aa8841c02665dffa8914c742fd37 (HEAD) Author: liuhongt Date: Tue Feb 27 15:34:57 2024 +0800 Don't reduce estimated unrolled size for innermost loop. Note that r15-987 does not fix this.
[Bug tree-optimization/104165] [12 Regression] -Warray-bounds for unreachable code inlined from std::sort()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104165 teodor_spaeren at riseup dot net changed: What|Removed |Added CC||teodor_spaeren at riseup dot net --- Comment #11 from teodor_spaeren at riseup dot net --- This just hit me on gcc 14.1: https://godbolt.org/z/31G5dxz55
[Bug target/115333] -march=native sets --param "l2-cache-size=1024" on Ryzen 7 7800X3D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115333 --- Comment #2 from Kostadin Shishmanov --- I suppose we can close this then?
[Bug tree-optimization/115307] [avr] Don't expand isinf() like a built-in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115307 --- Comment #7 from Joseph S. Myers --- Note the difference between __builtin_isinf (C standard semantics, returns unspecified nonzero value for an infinity) and __builtin_isinf_sign (stricter semantics returning 1 for +Inf and -1 for -Inf).
[Bug target/115333] -march=native sets --param "l2-cache-size=1024" on Ryzen 7 7800X3D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115333 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #1 from Alexander Monakov --- --param l2-cache-size gives the L2 size on all AMD parts, not just Zen.
[Bug c++/44298] code addressed only by label with it's address taken is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44298 Jakub Jelinek changed: What|Removed |Added CC||mr.bossman075 at gmail dot com --- Comment #13 from Jakub Jelinek --- *** Bug 115332 has been marked as a duplicate of this bug. ***
[Bug c/115332] Using label-as-value in asm statement removes label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115332 --- Comment #3 from Jakub Jelinek --- Oops. *** This bug has been marked as a duplicate of bug 44298 ***
[Bug c/115332] Using label-as-value in asm statement removes label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115332 Jakub Jelinek changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Jakub Jelinek --- . *** This bug has been marked as a duplicate of bug 44268 ***
[Bug libstdc++/44268] abi docs say that hppa-linux defaults to libgcc_s.so.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44268 Jakub Jelinek changed: What|Removed |Added CC||mr.bossman075 at gmail dot com --- Comment #11 from Jakub Jelinek --- *** Bug 115332 has been marked as a duplicate of this bug. ***
[Bug c/115332] Using label-as-value in asm statement removes label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115332 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- It behaves exactly as designed. There needs to be an edge in the control flow graph to the label, if there isn't, even when the label is referenced in some & computed value, it can't be validly called and thus the label becomes a "deleted label" and can move anywhere in the function.
[Bug target/115333] New: -march=native sets --param "l2-cache-size=1024" on Ryzen 7 7800X3D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115333 Bug ID: 115333 Summary: -march=native sets --param "l2-cache-size=1024" on Ryzen 7 7800X3D Product: gcc Version: 14.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: kocelfc at tutanota dot com Target Milestone: --- For some reason on my Ryzen 7 7800X3D -march=native sets --param "l2-cache-size=1024" as opposed to it showing the last level cache (L3) which is 96MB. Is this a bug or is this intentional on 3D V-Cache cpus and maybe other Zen parts? `gcc -### -march=native /usr/include/stdlib.h` Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/14/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-14.1.1_p20240601/work/gcc-14-20240601/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/14 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/14/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14 --disable-silent-rules --disable-dependency-tracking --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/14/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 Hardened 14.1.1_p20240601 p1' --with-gcc-major-version-only --enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point --enable-targets=all --enable-libgomp --disable-libssp --disable-libada --disable-cet --disable-systemtap --disable-valgrind-annotations --disable-vtable-verify --disable-libvtv --with-zstd --without-isl --enable-default-pie --enable-host-pie --enable-host-bind-now --enable-default-ssp --disable-fixincludes Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.1.1 20240601 (Gentoo Hardened 14.1.1_p20240601 p1) COLLECT_GCC_OPTIONS='-march=native' '-dumpdir' 'a-' /usr/libexec/gcc/x86_64-pc-linux-gnu/14/cc1 -quiet /usr/include/stdlib.h "-march=znver4" -mmmx -mpopcnt -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -mavx -mavx2 -msse4a -mno-fma4 -mno-xop -mfma -mavx512f -mbmi -mbmi2 -maes -mpclmul -mavx512vl -mavx512bw -mavx512dq -mavx512cd -mavx512vbmi -mavx512ifma -mavx512vpopcntdq -mavx512vbmi2 -mgfni -mvpclmulqdq -mavx512vnni -mavx512bitalg -mavx512bf16 -mno-avx512vp2intersect -mno-3dnow -madx -mabm -mno-cldemote -mclflushopt -mclwb -mclzero -mcx16 -mno-enqcmd -mf16c -mfsgsbase -mfxsr -mno-hle -msahf -mno-lwp -mlzcnt -mmovbe -mno-movdir64b -mno-movdiri -mmwaitx -mno-pconfig -mpku -mprfchw -mno-ptwrite -mrdpid -mrdrnd -mrdseed -mno-rtm -mno-serialize -mno-sgx -msha -mshstk -mno-tbm -mno-tsxldtrk -mvaes -mno-waitpkg -mwbnoinvd -mxsave -mxsavec -mxsaveopt -mxsaves -mno-amx-tile -mno-amx-int8 -mno-amx-bf16 -mno-uintr -mno-hreset -mno-kl -mno-widekl -mno-avxvnni -mno-avx512fp16 -mno-avxifma -mno-avxvnniint8 -mno-avxneconvert -mno-cmpccxadd -mno-amx-fp16 -mno-prefetchi -mno-raoint -mno-amx-complex -mno-avxvnniint16 -mno-sm3 -mno-sha512 -mno-sm4 -mno-apxf -mno-usermsr --param "l1-cache-size=32" --param "l1-cache-line-size=64" --param "l2-cache-size=1024" "-mtune=znver4" -quiet -dumpdir a- -dumpbase stdlib.h -dumpbase-ext .h -o /tmp/ccpnj3TA.s --output-pch /usr/include/stdlib.h.gch `lscpu | grep cache` L1d cache:256 KiB (8 instances) L1i cache:256 KiB (8 instances) L2 cache: 8 MiB (8 instances) L3 cache: 96 MiB (1 instance)
[Bug c/115332] New: Using label-as-value in asm statement removes label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115332
Bug ID: 115332
Summary: Using label-as-value in asm statement removes label
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mr.bossman075 at gmail dot com
Target Milestone: ---
$ riscv64-unknown-elf-gcc -v
Using built-in specs.
COLLECT_GCC=riscv64-unknown-elf-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/riscv64-unknown-elf/13.2.0/lto-wrapper
Target: riscv64-unknown-elf
Configured with: ../gcc-13.2.0/configure --build=x86_64-linux-gnu --prefix=/usr
--includedir='/usr/lib/include' --mandir='/usr/lib/share/man'
--infodir='/usr/lib/share/info' --sysconfdir=/etc --localstatedir=/var
--disable-option-checking --disable-silent-rules
--libdir='/usr/lib/lib/x86_64-linux-gnu'
--libexecdir='/usr/lib/lib/x86_64-linux-gnu' --disable-maintainer-mode
--disable-dependency-tracking --enable-languages=c,c++ --prefix=/usr/lib
--infodir=/usr/share/doc/gcc-riscv64-unknown-elf/info --mandir=/usr/share/man
--htmldir=/usr/share/doc/gcc-riscv64-unknown-elf/html
--pdfdir=/usr/share/doc/gcc-riscv64-unknown-elf/pdf --bindir=/usr/bin
--libexecdir=/usr/lib --libdir=/usr/lib --with-system-zlib --enable-multilib
--disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap
--disable-libquadmath --disable-libssp --disable-libstdcxx-pch
--disable-libstdc++-v3 --disable-nls --disable-shared --disable-threads
--with-arch=rv64imafdc --enable-tls --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=riscv64-unknown-elf --with-gnu-as
--with-gnu-ld --with-headers=no --without-newlib --with-pkgversion=13.2.0-10+12
--without-included-gettext SED=/bin/sed SHELL=/bin/sh BASH=/bin/bash
CONFIG_SHELL=/bin/bash AR_FOR_TARGET=riscv64-unknown-elf-ar
AS_FOR_TARGET=riscv64-unknown-elf-as LD_FOR_TARGET=riscv64-unknown-elf-ld
NM_FOR_TARGET=riscv64-unknown-elf-nm
OBJDUMP_FOR_TARGET=riscv64-unknown-elf-objdump
RANLIB_FOR_TARGET=riscv64-unknown-elf-ranlib
READELF_FOR_TARGET=riscv64-unknown-elf-readelf
STRIP_FOR_TARGET=riscv64-unknown-elf-strip ASFLAGS= ASFLAGS_FOR_BUILD=
CFLAGS='-g -O2
-ffile-prefix-map=/build/reproducible-path/gcc-riscv64-unknown-elf-12=.
-fstack-protector-strong -fstack-clash-protection -fcf-protection'
'CFLAGS_FOR_BUILD=-g -O2' CPPFLAGS='-Wdate-time -D_FORTIFY_SOURCE=2'
CPPFLAGS_FOR_BUILD= CXXFLAGS='-g -O2
-ffile-prefix-map=/build/reproducible-path/gcc-riscv64-unknown-elf-12=.
-fstack-protector-strong -fstack-clash-protection -fcf-protection'
'CXXFLAGS_FOR_BUILD=-g -O2' DFLAGS=-frelease DFLAGS_FOR_BUILD=-frelease
FCFLAGS='-g -O2
-ffile-prefix-map=/build/reproducible-path/gcc-riscv64-unknown-elf-12=.
-fstack-protector-strong -fstack-clash-protection -fcf-protection'
'FCFLAGS_FOR_BUILD=-g -O2' FFLAGS='-g -O2
-ffile-prefix-map=/build/reproducible-path/gcc-riscv64-unknown-elf-12=.
-fstack-protector-strong -fstack-clash-protection -fcf-protection'
'FFLAGS_FOR_BUILD=-g -O2' LDFLAGS='-Wl,-z,relro -Wl,-z,now' LDFLAGS_FOR_BUILD=
OBJCFLAGS='-g -O2
-ffile-prefix-map=/build/reproducible-path/gcc-riscv64-unknown-elf-12=.
-fstack-protector-strong -fstack-clash-protection -fcf-protection'
'OBJCFLAGS_FOR_BUILD=-g -O2' OBJCXXFLAGS='-g -O2
-ffile-prefix-map=/build/reproducible-path/gcc-riscv64-unknown-elf-12=.
-fstack-protector-strong -fstack-clash-protection -fcf-protection'
'OBJCXXFLAGS_FOR_BUILD=-g -O2' INHIBIT_LIBC_CFLAGS=-DUSE_TM_CLONE_REGISTRY=0
'CFLAGS_FOR_TARGET=-Os -mcmodel=medany' 'CXXFLAGS_FOR_TARGET=-Os
-mcmodel=medany'
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 13.2.0 (13.2.0-10+12)
int test_labels()
{
void *label = &
long val;
asm volatile("mv %0, %1"
: "=r" (val) : "r" (label)
: "memory");
return 1;
l:
return 0;
}
int test_labels2()
{
void *label = &
long val;
asm volatile goto("mv %0, %1"
: "=r" (val) : "r" (label)
: "memory": l);
return 1;
l:
return 0;
}
In the above code in `test_labels` the label `l` will be removed even though we
are using the "label as value" in the asm statement. The second test uses asm
goto to tell the compiler that the label is used. The compilation output is
what would be expected of the first. The above code was compiled with the
command below. This doesn't appear to be architecture-dependent, but was
originally found on riscv.
riscv64-unknown-elf-gcc -S -c -O1 -Wall -Wextra -fno-strict-aliasing -fwrapv
test.c -o-
The output of the above command is:
.file "test.c"
.option nopic
.attribute arch, "rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_zicsr2p0"
.attribute unaligned_access, 0
.attribute stack_align, 16
.text
.align 1
.globl test_labels
.type test_labels, @function
test_labels:
.L2:
lui
[Bug c++/95349] Using std::launder(p) produces unexpected behavior where (p) produces expected behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #52 from Jonathan Wakely ---
(In reply to Christopher Nerz from comment #45)
> This is a critical bug which renders gcc unusable for safety relevant
> systems using expected/variant or simple ipc.
I don't think your example demonstrates that.
> alignas(8) std::byte buffer[8]; // some buffer
> new (buffer) double{1}; // some completely trivial data
> // reuse memory -> double ends lifetime, uint64 starts lifetime
> std::uint64_t * res = new (buffer) std::uint64_t;
This starts the lifetime of a new object, but it has indeterminate value.
> // *res is allowed to be used as it is the correct pointer returned by
> new
The pointer does point to the new object, but derefencing it causes a read of
an indeterminate value, which is undefined behaviour.
> // *res == 0x3ff0 // and gives correct value
> // The very definition of std::launder says that it is suppose to be
> used as:
> return (*res == *std::launder(reinterpret_cast(buffer)));
It looks like what you're actually trying to do is:
alignas(8) std::byte buffer[8];
new (buffer) double{1};
std::uint64_t* res = std::start_lifetime_as(buffer);
return *res == 0x3ff0;
This is not what std::launder is for.
[Bug c++/95349] Using std::launder(p) produces unexpected behavior where (p) produces expected behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349 --- Comment #51 from Jonathan Wakely --- (In reply to Richard Biener from comment #48) > (In reply to Christopher Nerz from comment #47) > > But shouldn't both give the same value? > > I'm not sure what the standard says to this. Does std::launder(...) > sanitize earlier "undefined behavior"? For example failing to initialize > an object? No. The example appears to be trying to use std::launder as std::start_lifetime_as, but they're not the same.
[Bug middle-end/108789] __builtin_(add|mul|sub)_overflow methods generate duplicate operations if both operands are const which in turn causes wrong code due to overlapping arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108789 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Created attachment 58336 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58336=edit gcc15-pr108789.patch Untested fix.
[Bug c++/115331] [13/14/15 Regression] ICE-on-invalid passing a typoed lambda to a list-initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115331 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-06-03 Summary|ICE-on-invalid passing a|[13/14/15 Regression] |typoed lambda to a |ICE-on-invalid passing a |list-initializer|typoed lambda to a ||list-initializer Target Milestone|--- |13.4 Status|UNCONFIRMED |NEW Keywords||error-recovery, ||ice-checking Ever confirmed|0 |1 Version|unknown |15.0 --- Comment #2 from Andrew Pinski --- I suspect it was r13-3527-gf7d1dbb86a . + if (parm == error_mark_node) + continue; + parm = TREE_VALUE (parm); + + if (DECL_VIRTUAL_P (parm)) + // A synthetic parm, we're done. + break; The check for parm being error_mark_node should also happen on TREE_VALUE (param).
[Bug c++/115331] ICE-on-invalid passing a typoed lambda to a list-initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115331 Andrew Pinski changed: What|Removed |Added Summary|[15 regression] |ICE-on-invalid passing a |ICE-on-invalid passing a|typoed lambda to a |typoed lambda to a |list-initializer |list-initializer| --- Comment #1 from Andrew Pinski --- >The ICE does not reproduce on 14.1, it's trunk only That is most likely because the trunk has checking turned on by default. So removing the regression marker until proven otherwise.
[Bug c++/115331] New: [15 regression] ICE-on-invalid passing a typoed lambda to a list-initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115331
Bug ID: 115331
Summary: [15 regression] ICE-on-invalid passing a typoed lambda
to a list-initializer
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
struct has_ctor
{
has_ctor(auto arg) {}
};
void aaa()
{
has_ctor{[]<(){}}; // typo intentional
}
-std=c++20
: In function 'void aaa()':
:8:17: error: expected identifier before '(' token
8 | has_ctor{[]<(){}};
| ^
:8:19: error: expected '>' before '{' token
8 | has_ctor{[]<(){}};
| ^
: In instantiation of 'has_ctor::has_ctor(auto:1) [with auto:1 =
aaa()::]':
:3:5: required from here
3 | has_ctor(auto arg) {}
| ^~~~
:3:5: internal compiler error: tree check: expected tree that contains
'decl common' structure, have 'error_mark' in decl_template_parm_check, at
cp/cp-tree.h:5138
0x269996c internal_error(char const*, ...)
???:0
0x96eb0f tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
???:0
0xba20c6 mangle_decl(tree_node*)
???:0
0x16c5fc5 decl_assembler_name(tree_node*)
???:0
0x16eea01 assign_assembler_name_if_needed(tree_node*)
???:0
0xe8c11d cgraph_node::analyze()
???:0
0xe8f6d1 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
Online reproducer: https://godbolt.org/z/K1hjEsaf5
The ICE does not reproduce on 14.1, it's trunk only (tested on
Compiler-Explorer-Build-gcc-cbf2ed4b309d54039d74be5d730299012e7681b3-binutils-2.42,
15.0.0 20240603).
[Bug target/113357] [14/15 regression] m68k-linux bootstrap failure in stage2 due to segfault compiling unwind-dw2.c since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357 --- Comment #9 from Mikael Pettersson --- (In reply to Manolis Tsamis from comment #8) > Created attachment 58335 [details] > Do not modify live_out registers > > After looking again at the dumps from PR112415, which I believe is closely > related to the issue here, I saw that while f-m-o was checking the uses of > the folded registers, it was still modifying registers that were at the BB's > live_out set. > > I have attached a patch that I'm testing for addressing this. Could you > please check if this fixes this issue? I'm starting a bootstrap on m68k-linux-gnu with this now, should know by Friday if it resolves the issue or not. (It's running in full-system emulation mode on Aranym, so it's slow.)
[Bug modula2/115330] New: Incorrect definition module name used in the error message when reporting on an opaque type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115330 Bug ID: 115330 Summary: Incorrect definition module name used in the error message when reporting on an opaque type Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: gaius at gcc dot gnu.org Target Milestone: --- The error message reporting on an opaque type not being a pointer generates an module name in the error. For example: $ cat Num.def DEFINITION MODULE Num ; TYPE NumType ; PROCEDURE add (left, right: NumType) : NumType ; END Num. $ cat Num.mod IMPLEMENTATION MODULE Num ; TYPE NumType = CARDINAL ; PROCEDURE add (left, right: NumType) : NumType ; BEGIN RETURN left+right END add ; END Num. $ gm2 Num.mod Num.mod:4:14: error: In definition module ‘wrapc’: opaque type (NumType) should be equivalent to a POINTER or an ADDRESS 4 |NumType = CARDINAL ; | ^~~~ Num.mod:4:14: error: if you really need a non POINTER type use the -fextended-opaque switch wrapc is incorrect - it should be Num.
[Bug rtl-optimization/115297] [14/15 regression] alpha: ICE in simplify_subreg, at simplify-rtx.cc:7554 with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115297 Uroš Bizjak changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com Status|UNCONFIRMED |RESOLVED Target Milestone|14.2|11.5 Resolution|--- |FIXED --- Comment #7 from Uroš Bizjak --- Fixed everywhere.
[Bug rtl-optimization/115297] [14/15 regression] alpha: ICE in simplify_subreg, at simplify-rtx.cc:7554 with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115297
--- Comment #6 from GCC Commits ---
The releases/gcc-11 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:835b913aff1b1a813df3b9d2bbef170ae7d8856d
commit r11-11463-g835b913aff1b1a813df3b9d2bbef170ae7d8856d
Author: Uros Bizjak
Date: Fri May 31 15:52:03 2024 +0200
alpha: Fix invalid RTX in divmodsi insn patterns [PR115297]
any_divmod instructions are modelled with invalid RTX:
[(set (match_operand:DI 0 "register_operand" "=c")
(sign_extend:DI (match_operator:SI 3 "divmod_operator"
[(match_operand:DI 1 "register_operand" "a")
(match_operand:DI 2 "register_operand" "b")])))
(clobber (reg:DI 23))
(clobber (reg:DI 28))]
where SImode divmod_operator (div,mod,udiv,umod) has DImode operands.
Wrap input operand with truncate:SI to make machine modes consistent.
PR target/115297
gcc/ChangeLog:
* config/alpha/alpha.md (si3): Wrap DImode
operands 3 and 4 with truncate:SI RTX.
(*divmodsi_internal_er): Ditto for operands 1 and 2.
(*divmodsi_internal_er_1): Ditto.
(*divmodsi_internal): Ditto.
* config/alpha/constraints.md ("b"): Correct register
number in the description.
gcc/testsuite/ChangeLog:
* gcc.target/alpha/pr115297.c: New test.
(cherry picked from commit 0ac802064c2a018cf166c37841697e867de65a95)
[Bug libstdc++/111641] FAIL: 19_diagnostics/stacktrace/current.cc -std=gnu++23 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111641 --- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #14 from dave.anglin at bell dot net --- > On 2024-05-29 8:17 a.m., ro at CeBiTec dot Uni-Bielefeld.DE wrote: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111641 >> >> --- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE > dot Uni-Bielefeld.DE> --- >>> --- Comment #12 from dave.anglin at bell dot net --- >>> It will be a few days before I can test. I've had three hard drives >>> fail on my >>> main hppa >>> system in the past few weeks. >> I guess it's best to postpone committing to the gcc-14 branch until you >> can report hppa results then. Btw., when you're ready, could you also >> check the libbacktrace test results (no .sum file, unfortunately, just >> buried deeply in make check output) for comparison? Thanks. > Change fixes the following libstdc++ tests on hppa-linux: > FAIL: 19_diagnostics/stacktrace/current.cc -std=gnu++23 execution test > FAIL: 19_diagnostics/stacktrace/current.cc -std=gnu++26 execution test > FAIL: 19_diagnostics/stacktrace/entry.cc -std=gnu++23 execution test > FAIL: 19_diagnostics/stacktrace/entry.cc -std=gnu++26 execution test > FAIL: 19_diagnostics/stacktrace/output.cc -std=gnu++23 execution test > FAIL: 19_diagnostics/stacktrace/output.cc -std=gnu++26 execution test > FAIL: 19_diagnostics/stacktrace/stacktrace.cc -std=gnu++23 execution test > FAIL: 19_diagnostics/stacktrace/stacktrace.cc -std=gnu++26 execution test > > The libbacktrace tests all pass on hppa-linux. Hi Dave, thanks for checking. I guess it's reasonably safe to backport the patch to the gcc-14 branch then.
[Bug rtl-optimization/115297] [14/15 regression] alpha: ICE in simplify_subreg, at simplify-rtx.cc:7554 with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115297
--- Comment #5 from GCC Commits ---
The releases/gcc-12 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:c6c2a6cebabc5f78cef3d81cedb4b3b578478b9f
commit r12-10486-gc6c2a6cebabc5f78cef3d81cedb4b3b578478b9f
Author: Uros Bizjak
Date: Fri May 31 15:52:03 2024 +0200
alpha: Fix invalid RTX in divmodsi insn patterns [PR115297]
any_divmod instructions are modelled with invalid RTX:
[(set (match_operand:DI 0 "register_operand" "=c")
(sign_extend:DI (match_operator:SI 3 "divmod_operator"
[(match_operand:DI 1 "register_operand" "a")
(match_operand:DI 2 "register_operand" "b")])))
(clobber (reg:DI 23))
(clobber (reg:DI 28))]
where SImode divmod_operator (div,mod,udiv,umod) has DImode operands.
Wrap input operand with truncate:SI to make machine modes consistent.
PR target/115297
gcc/ChangeLog:
* config/alpha/alpha.md (si3): Wrap DImode
operands 3 and 4 with truncate:SI RTX.
(*divmodsi_internal_er): Ditto for operands 1 and 2.
(*divmodsi_internal_er_1): Ditto.
(*divmodsi_internal): Ditto.
* config/alpha/constraints.md ("b"): Correct register
number in the description.
gcc/testsuite/ChangeLog:
* gcc.target/alpha/pr115297.c: New test.
(cherry picked from commit 0ac802064c2a018cf166c37841697e867de65a95)
[Bug tree-optimization/115304] gcc.dg/vect/slp-gap-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115304
--- Comment #11 from Andrew Stubbs ---
(In reply to rguent...@suse.de from comment #10)
> On Mon, 3 Jun 2024, ams at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115304
> >
> > --- Comment #9 from Andrew Stubbs ---
> > (In reply to Richard Biener from comment #6)
> > > The best strathegy for GCN would be to gather V4QImode aka SImode into the
> > > V64QImode (or V16SImode) vector. For pix2 we have a gap of 28 elements,
> > > doing consecutive loads isn't a good strategy here.
> >
> > I don't fully understand what you're trying to say here, so apologies if you
> > knew all this already and I missed the point.
> >
> > In general, on GCN V4QImode is not in any way equivalent to SImode (when the
> > values are in registers). The vector registers are not one single string of
> > re-interpretable bits.
> >
> > For the same reason, you can't load a value as V64QImode and then try to
> > interpret it as V16SImode. GCN vector registers just don't work like
> > SSE/Neon/etc.
> >
> > When you load a V64QImode vector, each lane is extended to 32 bits, so what
> > you
> > actually get in hardware is a V64SImode vector.
> >
> > Likewise, when you load a V4QImode vector the hardware representation is
> > actually V4SImode (which in itself is just V64SImode with undefined values
> > in
> > the unused lanes).
>
> I see. I wonder if there's not one or two latent wrong-code because of
> this and the vectorizers assumptions ;) I suppose modes_tieable_p
> will tell us whether a VIEW_CONVERT_EXPR will do the right thing?
> Is GET_MODE_SIZE (V64QImode) == GET_MODE_SIZE (V64SImode) btw?
> And V64QImode really V64PSImode?
The mode size says how big it will be when written to memory, so no they're not
the same. I believe this matches the scalar QImode behaviour.
We don't use any PSI modes. There are (some) machine instructions for V64QImode
(and V64HImode) so we don't want to lose that information.
There may well be some bugs, but we have handling for conversions in a number
of places. There are truncate and extend patterns that operate lane-wise, and
vec_extract can take a subset of a vector, IIRC.
> Still for a V64QImode load on { c[0], c[1], c[2], c[3], c[32], c[33],
> c[34], c[35], ... } it's probably best to use a single V64QImode gather
> with GCN then rather than four "consecutive" V64QImode loads and then
> element swizzling.
Fewer loads are always better, and permutations are expensive operations (and
don't work with 64-lane vectors on RDNA devices because they're actually two
32-lane vectors stuck together) so it can certainly make sense to use gather
with a vector of permuted offsets (although it can be expensive to generate
that vector in the first place).
[Bug target/115321] [15 regression] ICE when building grub (extract_insn, at recog.cc:2812) since r15-930
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115321 Andrew Pinski changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #7 from Andrew Pinski --- *** Bug 115329 has been marked as a duplicate of this bug. ***
[Bug target/115329] [15 Regression] ICE in extract_insn, at recog.cc:2812 since r15-930-ge715204f203d31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115329 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- A few minutes too slow, it was just fixed in the last hour. Anyways it is a dup of bug 115321. *** This bug has been marked as a duplicate of bug 115321 ***
[Bug target/115329] New: [15 Regression] ICE in extract_insn, at recog.cc:2812 since r15-930-ge715204f203d31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115329
Bug ID: 115329
Summary: [15 Regression] ICE in extract_insn, at recog.cc:2812
since r15-930-ge715204f203d31
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jamborm at gcc dot gnu.org
CC: ubizjak at gmail dot com
Target Milestone: ---
Compiling the testcase (minimized from grub2):
int grub_swap_bytes32_x, grub_load_public_key___trans_tmp_1;
void grub_load_public_key() {
grub_load_public_key___trans_tmp_1 = __builtin_bswap32(grub_swap_bytes32_x);
}
with options:
-Os -m32 -S -fno-common -std=gnu99 -march=i386 test.c
leads to the following ICE since revision r15-930-ge715204f203d31
(Uros Bizjak: i386: Rewrite bswaphi2 handling [PR115102]):
test.c: In function ‘grub_load_public_key’:
test.c:4:1: error: unrecognizable insn:
4 | }
| ^
(insn 5 2 6 2 (set (reg:SI 102)
(ior:SI (and:SI (mem/c:SI (symbol_ref:SI ("grub_swap_bytes32_x") [flags
0x2] ) [1 grub_swap_bytes32_x+0 S4
A32])
(const_int -65536 [0x]))
(lshiftrt:SI (bswap:SI (mem/c:SI (symbol_ref:SI
("grub_swap_bytes32_x") [flags 0x2] ) [1 grub_swap_bytes32_x+0 S4 A32]))
(const_int 16 [0x10] "test.c":3:40 -1
(nil))
during RTL pass: vregs
test.c:4:1: internal compiler error: in extract_insn, at recog.cc:2812
0x807d4c _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/mjambor/gcc/mine/src/gcc/rtl-error.cc:108
0x807d68 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/mjambor/gcc/mine/src/gcc/rtl-error.cc:116
0x806289 extract_insn(rtx_insn*)
/home/mjambor/gcc/mine/src/gcc/recog.cc:2812
0xca0b90 instantiate_virtual_regs_in_insn
/home/mjambor/gcc/mine/src/gcc/function.cc:1612
0xca0b90 instantiate_virtual_regs
/home/mjambor/gcc/mine/src/gcc/function.cc:1995
0xca0b90 execute
/home/mjambor/gcc/mine/src/gcc/function.cc:2042
[Bug c/115326] __builtin_sub_overflow reports incorrect overflow value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115326 --- Comment #4 from Jakub Jelinek --- Note, fold_builtin_arith_overflow just does tree call = build_call_expr_internal_loc (loc, ifn, ctype, 2, arg0, arg1); tree tgt = save_expr (call); and then uses tgt twice, so it is save_expr decision whether it can be evaluated twice or needs to be done once. And save_expr adds SAVE_EXPR only to the second case when it sees non-const VAR_DECLs, in the first case the arguments are TREE_READONLY and so the ifn call is as well and so causes tree_invariant_p_1 to return true.
[Bug middle-end/108789] __builtin_(add|mul|sub)_overflow methods generate duplicate operations if both operands are const which in turn causes wrong code due to overlapping arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108789 --- Comment #4 from Andrew Pinski --- Note the missing SAVE_EXPR issue is similar to PR 52339 (which has a patch attached to it that would fix the issue here too I think).
[Bug middle-end/108789] __builtin_(add|mul)_overflow methods generate duplicate operations if both operands are const which in turn causes wrong code due to overlapping arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108789 Andrew Pinski changed: What|Removed |Added CC||cody at tapscott dot me --- Comment #3 from Andrew Pinski --- *** Bug 115326 has been marked as a duplicate of this bug. ***
[Bug c/115326] __builtin_sub_overflow reports incorrect overflow value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115326 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #2) > I think this is just invalid testcase. > The compiler is told that *a is const, but it is changed through a different > lvalue. No the testcase is valid, it is just a dup of bug 108789. *** This bug has been marked as a duplicate of bug 108789 ***
[Bug rtl-optimization/115297] [14/15 regression] alpha: ICE in simplify_subreg, at simplify-rtx.cc:7554 with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115297
--- Comment #4 from GCC Commits ---
The releases/gcc-13 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:ed06ca80bae174f1179222ff8e6b93464006e86a
commit r13-8820-ged06ca80bae174f1179222ff8e6b93464006e86a
Author: Uros Bizjak
Date: Fri May 31 15:52:03 2024 +0200
alpha: Fix invalid RTX in divmodsi insn patterns [PR115297]
any_divmod instructions are modelled with invalid RTX:
[(set (match_operand:DI 0 "register_operand" "=c")
(sign_extend:DI (match_operator:SI 3 "divmod_operator"
[(match_operand:DI 1 "register_operand" "a")
(match_operand:DI 2 "register_operand" "b")])))
(clobber (reg:DI 23))
(clobber (reg:DI 28))]
where SImode divmod_operator (div,mod,udiv,umod) has DImode operands.
Wrap input operand with truncate:SI to make machine modes consistent.
PR target/115297
gcc/ChangeLog:
* config/alpha/alpha.md (si3): Wrap DImode
operands 3 and 4 with truncate:SI RTX.
(*divmodsi_internal_er): Ditto for operands 1 and 2.
(*divmodsi_internal_er_1): Ditto.
(*divmodsi_internal): Ditto.
* config/alpha/constraints.md ("b"): Correct register
number in the description.
gcc/testsuite/ChangeLog:
* gcc.target/alpha/pr115297.c: New test.
(cherry picked from commit 0ac802064c2a018cf166c37841697e867de65a95)
[Bug target/115321] [15 regression] ICE when building grub (extract_insn, at recog.cc:2812) since r15-930
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115321 Uroš Bizjak changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Uroš Bizjak --- Fixed.
[Bug tree-optimization/115304] gcc.dg/vect/slp-gap-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115304
--- Comment #10 from rguenther at suse dot de ---
On Mon, 3 Jun 2024, ams at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115304
>
> --- Comment #9 from Andrew Stubbs ---
> (In reply to Richard Biener from comment #6)
> > The best strathegy for GCN would be to gather V4QImode aka SImode into the
> > V64QImode (or V16SImode) vector. For pix2 we have a gap of 28 elements,
> > doing consecutive loads isn't a good strategy here.
>
> I don't fully understand what you're trying to say here, so apologies if you
> knew all this already and I missed the point.
>
> In general, on GCN V4QImode is not in any way equivalent to SImode (when the
> values are in registers). The vector registers are not one single string of
> re-interpretable bits.
>
> For the same reason, you can't load a value as V64QImode and then try to
> interpret it as V16SImode. GCN vector registers just don't work like
> SSE/Neon/etc.
>
> When you load a V64QImode vector, each lane is extended to 32 bits, so what
> you
> actually get in hardware is a V64SImode vector.
>
> Likewise, when you load a V4QImode vector the hardware representation is
> actually V4SImode (which in itself is just V64SImode with undefined values in
> the unused lanes).
I see. I wonder if there's not one or two latent wrong-code because of
this and the vectorizers assumptions ;) I suppose modes_tieable_p
will tell us whether a VIEW_CONVERT_EXPR will do the right thing?
Is GET_MODE_SIZE (V64QImode) == GET_MODE_SIZE (V64SImode) btw?
And V64QImode really V64PSImode?
Still for a V64QImode load on { c[0], c[1], c[2], c[3], c[32], c[33],
c[34], c[35], ... } it's probably best to use a single V64QImode gather
with GCN then rather than four "consecutive" V64QImode loads and then
element swizzling.
[Bug bootstrap/115284] [15 regression] SEGV in check_format_arg on Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115284 --- Comment #14 from Hans-Peter Nilsson --- (In reply to r...@cebitec.uni-bielefeld.de from comment #13) > I've completed the sparc64-linux comparison now: no regressions with a > non-bootstrap build and your patches either, thus the same situation as > on Solaris. Thank you for doing this! I was a bit worried you'd find something, so I'd lose the incentive to get a sparc64 -or general- bootstrap environment working, one way or the other. (j/k :)
[Bug c/115326] __builtin_sub_overflow reports incorrect overflow value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115326 --- Comment #2 from Jakub Jelinek --- I think this is just invalid testcase. The compiler is told that *a is const, but it is changed through a different lvalue.
[Bug target/115321] [15 regression] ICE when building grub (extract_insn, at recog.cc:2812) since r15-930
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115321 --- Comment #5 from GCC Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:6ab5145825ca7e96fcbe3aa505d42e4ae8f81009 commit r15-993-g6ab5145825ca7e96fcbe3aa505d42e4ae8f81009 Author: Uros Bizjak Date: Mon Jun 3 15:48:18 2024 +0200 i386: Force operand 1 of bswapsi2 to a register for !TARGET_BSWAP [PR115321] PR target/115321 gcc/ChangeLog: * config/i386/i386.md (bswapsi2): Force operand 1 to a register also for !TARGET_BSWAP. gcc/testsuite/ChangeLog: * gcc.target/i386/pr115321.c: New test.
[Bug c/115326] __builtin_sub_overflow reports incorrect overflow value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115326 Richard Biener changed: What|Removed |Added Keywords||wrong-code CC||jakub at gcc dot gnu.org --- Comment #1 from Richard Biener --- We lower it as int overflow1 = r->as_u64[0] = REALPART_EXPR <.SUB_OVERFLOW ((uint64_t) a->as_u64[0], (uint64_t) b->as_u64[0])>, (int) (_Bool) IMAGPART_EXPR <.SUB_OVERFLOW ((uint64_t) a->as_u64[0], (uint64_t) b->as_u64[0])>; where the assignment to r->as_u64[0] is done before the re-evaluation for the overflow bit. A SAVE_EXPR is missing here? Jakub?
[Bug modula2/115328] The FORWARD keyword is not implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115328 Gaius Mulley changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2024-06-03 --- Comment #1 from Gaius Mulley --- Confirmed. Although the keyword is not needed with gm2, nevertheless the ISO standard specifies the presence of FORWARD (and for compatibility and ISO conformance reasons it should be implemented).
[Bug lto/115327] [ld] [lto] using ld and lto, crash while dynamic compile executable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115327 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID Target||arm --- Comment #1 from Richard Biener --- This bugzilla is for GCC but you are using clang. If you want to report a bug in binutils BFD ld their bugzilla is sourceware.org/bugzilla
[Bug modula2/115328] New: The FORWARD keyword is not implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115328 Bug ID: 115328 Summary: The FORWARD keyword is not implemented Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: gaius at gcc dot gnu.org Target Milestone: --- >From the gm2 mailing list: > ... FORWARD is specified in > Sect. 6.2.11.1 Proper Procedure Declarations of ISO/IEC 10514-1: > > A proper procedure declaration consists of a proper procedure heading, > which declares the procedure identifier and the formal parameters, > followed by the keyword FORWARDin the case of a forward procedure > declaration, or followed by a proper procedure block in the case of a > full procedure declaration. > [...] but it is not handled in gm2.
[Bug tree-optimization/115304] gcc.dg/vect/slp-gap-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115304 --- Comment #9 from Andrew Stubbs --- (In reply to Richard Biener from comment #6) > The best strathegy for GCN would be to gather V4QImode aka SImode into the > V64QImode (or V16SImode) vector. For pix2 we have a gap of 28 elements, > doing consecutive loads isn't a good strategy here. I don't fully understand what you're trying to say here, so apologies if you knew all this already and I missed the point. In general, on GCN V4QImode is not in any way equivalent to SImode (when the values are in registers). The vector registers are not one single string of re-interpretable bits. For the same reason, you can't load a value as V64QImode and then try to interpret it as V16SImode. GCN vector registers just don't work like SSE/Neon/etc. When you load a V64QImode vector, each lane is extended to 32 bits, so what you actually get in hardware is a V64SImode vector. Likewise, when you load a V4QImode vector the hardware representation is actually V4SImode (which in itself is just V64SImode with undefined values in the unused lanes).
[Bug lto/115327] New: [ld] [lto] using ld and lto, crash while dynamic compile executable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115327
Bug ID: 115327
Summary: [ld] [lto] using ld and lto, crash while dynamic
compile executable
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: hanwei62 at huawei dot com
Target Milestone: ---
using lto and ld in arm, crash finally dynamic compile executable.
code:
20081204-2_1.C
```
namespace {
class c
{
public:
c () {}
virtual ~c() {}
};
};
void
foo (void)
{
c x;
}
```
clang++ -fuse-ld=ld -Wno-unused-command-line-argument -Wno-deprecated
-fno-caret-diagnostics -fdiagnostics-color=never -fmessage-length=0 -flto -c
-o cp_lto_20081204-2_1.o 20081204-2_1.C
20081204-2_0.C
```
extern void foo (void);
int
main ()
{
foo ();
return 0;
}
```
clang++ -fuse-ld=ld -Wno-unused-command-line-argument -Wno-deprecated
-fno-caret-diagnostics -fdiagnostics-color=never -fmessage-length=0 -flto -c
-o cp_lto_20081204-2_0.o 20081204-2_0.C
finally:
```
clang++ cp_lto_20081204-2_0.o cp_lto_20081204-2_1.o -fuse-ld=ld
-Wno-unused-command-line-argument -Wno-deprecated -fno-caret-diagnostics
-fdiagnostics-color=never -fmessage-length=0 -flto -o
g++-dg-lto-20081204-2-01.exe
clang-15: error: unable to execute command: Segmentation fault (core dumped)
clang-15: error: linker command failed due to signal (use -v to see invocation)
```
```
ld -v
GNU ld 2.42
```
But if I compile static, it passed.
[Bug gcov-profile/114751] .gcda:stamp mismatch with notes file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114751 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID CC||aoliva at gcc dot gnu.org --- Comment #10 from Richard Biener --- GCC 11 indeed had a big revamp of how auxiliary files (like .gcno) are named. In case of a single source file as in gcc -c src-file.c -o src-file.refo the auxiliary files are now named after the output file name with stripped extension. So for the above it should be src-file.gcno, the same as with -o src-file.o with GCC 10 or earlier you'd get src-file.refo-src-file.gcno The https://gcc.gnu.org/onlinedocs/gcc-11.4.0/gcc/Overall-Options.html#index-dumpbase documentation explains this in detail. It was previously inconsistent but notably it's now different that it was before. Thanks for tracking the issue down, I consider this not a bug now but CCed Alex who implemented this change in case he has anything to add to the observed auxiliary file conflict of gcc -c src-file.c -o src-file.refo and gcc -c src-file.c [-o src-file.o]
[Bug gcov-profile/114751] .gcda:stamp mismatch with notes file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114751 --- Comment #9 from Gejoe --- Hi team, I'm here to say that the issue is sorted out now for me. The gcda stamp mismatch would be seen when there is a recompilation of the source file for any reason. In my project, there was a particular compilation to create a reference object (say refo) as part of some thread safe related code. Consider a C file by name src-file.c , I found out that there was a specific compilation (part of the thread safe related code) after the initial compilation of the file. The specific latter compilation line would look like : gcc -c src-file.c -o src-file.refo This was not done for all source files but only for some components. Now this refo file was generated all these years and with gcc versions including 10.3.0. There was not any stamp mismatch issue for src-file.gcno and src-file.gcda till 10.3.0. However with gcc 11.4.0, we could see the stamp mismatch issue started appearing and it was narrowed down (using inotifywait tool) to gcno file modification during the build process. I found that there is nothing wrong with __gcov_dump() API usage or behaviour. While running make (compilation of the source files and also the refo object related compilation) the following script was used for run in parallel: #!/bin/sh inotifywait -mr --format '%e %w%f' | while read event file ; do if [[ "$file" == *.gcno ]] ; then echo "$file $event" gcov-dump $file | grep stamp fi done - The above shell script was run in another tab when make was running for the component. The script run after sometime had to be killed as it was using while loop and gcov-dump of the src-file.gcno would be leading access of the file and thereby leading to recursion (of intoifywait). In the output of the script run, I could see the stamp value was getting altered after a particular point and then I narrowed that down to refo object related compilation line present in the makefile. Next question was why was that not happening so far(until gcc 11.4.0 was used). It was found that with gcc 10.3.0 the refo object line compilarion as shown above (ie. gcc -c src-file.c -o src-file.refo) resulted in creation of src-file.refo.gcno file and src-file.gcno was not getting modified. With gcc 11.4.0, it was found that after the compilation, src-file.refo.gcno is not getting created but src-file.gcno is getting modified/regenerated thereby resulting in new gcno timestamp. The gcda time stamp will be the one corresponding to the original src-file compilation and not to the one generated after refo file generation. Is this difference due to the changes in gcc11 series ? I could see -dumpbase option coming in gcc11 which was not there earlier. https://gcc.gnu.org/onlinedocs/gcc-11.4.0/gcc/Overall-Options.html#index-dumpbase https://gcc.gnu.org/gcc-11/changes.html Awaiting some reply from GCC/GCOV experts here. Thanks to all for whatever support was given.
[Bug tree-optimization/115304] gcc.dg/vect/slp-gap-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115304 Richard Biener changed: What|Removed |Added Target|sparc*-sun-solaris2.11 GCN |GCN --- Comment #8 from Richard Biener --- Should be fixed on sparc.
[Bug tree-optimization/115304] gcc.dg/vect/slp-gap-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115304 --- Comment #7 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:ed8ba88074f3663f810ef2f07d79c3fcde5d9697 commit r15-991-ged8ba88074f3663f810ef2f07d79c3fcde5d9697 Author: Richard Biener Date: Mon Jun 3 14:43:42 2024 +0200 testsuite/115304 - properly guard gcc.dg/vect/slp-gap-1.c Testing on sparc shows we need vect_unpack and vect_perm. This isn't enough to resolve the GCN fail which ends up using interleaving. PR testsuite/115304 * gcc.dg/vect/slp-gap-1.c: Require vect_unpack and vect_perm.
[Bug target/113357] [14/15 regression] m68k-linux bootstrap failure in stage2 due to segfault compiling unwind-dw2.c since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357 --- Comment #8 from Manolis Tsamis --- Created attachment 58335 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58335=edit Do not modify live_out registers After looking again at the dumps from PR112415, which I believe is closely related to the issue here, I saw that while f-m-o was checking the uses of the folded registers, it was still modifying registers that were at the BB's live_out set. I have attached a patch that I'm testing for addressing this. Could you please check if this fixes this issue?
[Bug tree-optimization/115304] gcc.dg/vect/slp-gap-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115304
--- Comment #6 from Richard Biener ---
For GCN the issue is that with vector(64) unsigned short we fail the permute
(but we have { target vect64 } for this reason), but we then re-try with
the same mode but with SLP disabled and that succeeds.
The best strathegy for GCN would be to gather V4QImode aka SImode into the
V64QImode (or V16SImode) vector. For pix2 we have a gap of 28 elements,
doing consecutive loads isn't a good strategy here.
On x86 we can use a small vector and use half of it (gathers would be slow).
On sparc we start with V8QImode which is great but then sparc doesn't seem
able to build a V8QImode vector from two V4QImode vectors or have
V2SImode and build from two SImode values (and load SImode from pix1/pix2,
that possibly due to alignment). I do see a vec_initv2sisi though. Ah,
so we verify we can do the load using a permutation, permute two V8QImode
'a' and 'b' to get you a { a_low, b_low } V8QImode vector. The other
part is eliding of the gap that will end up loading half of the vector
but then pad it out as { a_low, 0 } but then still invoke this unsupported
permutation to get { a_low, b_low }. So in this case requiring vect_perm
would fix this though there is sparc_vectorize_vec_perm_const and vec_perm<>
guarded with VIS2, with -mvis2 we get past this failure point and run into
missed: not vectorized: relevant stmt not supported: _35 = (unsigned short)
_34;
So there's no vec_upack_{hi,lo}_v4hi. vect_unpack guards this.
Maybe I should move the test to be x86 specific.
I'll add the two dg-effective targets to fix the solaris fallout for now.
[Bug c/115326] New: __builtin_sub_overflow reports incorrect overflow value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115326 Bug ID: 115326 Summary: __builtin_sub_overflow reports incorrect overflow value Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: cody at tapscott dot me Target Milestone: --- Created attachment 58334 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58334=edit reduced test case The `__builtin_sub_overflow` intrinsic appears to report an incorrect overflow value, in a specific case when it is used with pointers to the field of a union. I would expect the two evaluations in the attached test program to be identical, but instead on my machine the abort() is triggered: $ gcc test2.c -O0 -fno-strict-aliasing $ ./a.out [1]1099972 IOT instruction ./a.out $ gcc -v: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/opt/gcc-latest/libexec/gcc/x86_64-pc-linux-gnu/13.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../configure --prefix=/opt/gcc-latest --enable-languages=c,c++ --enable-libstdcxx-debug --enable-libstdcxx-backtrace --disable-bootstrap --disable-multilib --disable-libvtv --with-system-zlib --without-isl --enable-multiarch Thread model: posix Supported LTO compression algorithms: zlib gcc version 13.0.1 20230416 (experimental) (GCC)
[Bug libstdc++/110572] ld.lld: error: duplicate symbol: std::type_info::operator==(std::type_info const&) const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110572 --- Comment #12 from Martin Storsjö --- (In reply to Jonathan Wakely from comment #11) > CC Martin Storsjo to see if changing Clang would be possible, or if he has a > better idea for the preprocessor check suggested in comment 9. > > It might be that Clang can't pre-define this macro because it has different > values for different mingw/mingw-w64/w64devkit toolchains, and clang > wouldn't know which one to be compatible with a priori. Thanks for looping me in! In this case, as this seems to be a fixed configuration for libstdc++ (as gcc/config/i386/cygming.h hardcodes __GXX_TYPEINFO_EQUALITY_INLINE=0), I don't see a problem with adding this define to Clang. Clang does have a couple of __GXX_* defines from before, but none that are target specific like this. Next to this one, in gcc/config/i386/cygming.h, I also see __GXX_MERGED_TYPEINFO_NAMES=0, I presume we should add that too, if we add __GXX_TYPEINFO_EQUALITY_INLINE. For Clang/libstdc++ interop on mingw in general, there are a couple of other longstanding issues, where Clang defaults to -fno-emulated-tls, while GCC defaults to -femulated-tls, and libstdc++ exposes a couple of TLS symbols directly in the library ABI surface, e.g. in __once_callable - see e.g. https://github.com/msys2/MINGW-packages/issues/8706. If those TLS symbols were to be moved out of headers, accessed only through accessor functions, this wouldn't be an issue (at the cost of a little bit of extra performance/indirection - although cross-translation unit access of TLS variables is more complex than for TLS variables marked static). For that particular issue, I've raised the question whether Clang should switch to emulated TLS by default, but the general opinion I've gathered (among e.g. msys2 users) is that we shouldn't. There's also been talks about getting native TLS implemented in GCC. Msys2 works around this issue by patching LLVM, for the environments that operate with libstdc++: https://github.com/msys2/MINGW-packages/blob/f6e5319a54f9657ee190f9e0ea1c8d59b7d77a62/mingw-w64-llvm/0004-enable-emutls-for-mingw.patch https://github.com/msys2/MINGW-packages/blob/f6e5319a54f9657ee190f9e0ea1c8d59b7d77a62/mingw-w64-llvm/PKGBUILD#L140-L144 Similarly, there's also an issue around whether pthreads is a default-linked library or not. As GCC can be built either with win32 or posix thread model, both scenarios are common, so msys2 also carries such an optional patch for making pthreads automatically linked in, in the relevant msys2 environments. But back to the topic of __GXX_TYPEINFO_EQUALITY_INLINE - as this seems to not vary across known configurations, I think it should be doable to add the definition to Clang.
[Bug bootstrap/115284] [15 regression] SEGV in check_format_arg on Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115284 --- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #12 from Hans-Peter Nilsson --- > (In reply to r...@cebitec.uni-bielefeld.de from comment #11) [...] >> * sparc64-unknown-linux-gnu (again, c and c++ only): there are testsuite >> failures all over the place, but I'd have to perform another bootstrap >> with your patches removed to make an exact comparison. > > Hm, the part where you compare results against a baseline is pretty central. > > One the one hand, when it doesn't manifest for sparc64-solaris just through > the > testsuite, the odds are against it manifesting that simple for sparc64-linux. > On the other hand, an existing reproducer is so much easier to handle. Thank > you and thanks in advance for the last step! I've completed the sparc64-linux comparison now: no regressions with a non-bootstrap build and your patches either, thus the same situation as on Solaris.
[Bug c++/95349] Using std::launder(p) produces unexpected behavior where (p) produces expected behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #50 from rguenther at suse dot de ---
On Mon, 3 Jun 2024, Christopher.Nerz at de dot bosch.com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
>
> --- Comment #49 from Christopher Nerz
> ---
> Ah, misunderstood and therefore forgot optimization to a constant.
>
> In the current code example, we have the problem that the (second)
> initialization does not initialize with a value (ergo undefined behaviour due
> to uninitialized variable although it is created in an initialized memory).
> In the more complex code - which I am trying to simplify, but so far get the
> behaviour only in quite special situations which are hard to reduce to an
> example - we have that the buffer is explicitly initialized via `new T{}`
> (calling an inline initialization, i.e. not a trivial default constructor, but
> T is trivially copy & move constructible), then the buffer is copied (as
> std::byte-array) and then std::launder is applied to the resulting byte-array.
> To my understanding [basic.types.general].$3
>
> > For two distinct objects obj1 and obj2 of trivially copyable type T, where
> > neither obj1 nor obj2 is a potentially-overlapping subobject, if the
> > underlying bytes (6.7.1) making up obj1 are copied into obj2, obj2 shall
> > subsequently hold the same value as obj1.
>
> guarantees that the copied buffer can be used as `T` via
> `*std::launder(second_buffer)`. Clang, MSVC agree, gcc does not.
>
> Again: Still trying to construct the minimal example for that behavior :-/
Hmm, copying as std::byte-array should make the store use alias-set zero
so a followup load as T should be OK. Unless "then the buffer is copied
(as std::byte-array)" is really doing something more advanced with regard
to type-based aliasing rules (thus not a plain memcpy).
[Bug tree-optimization/115157] incorrect TBAA for derived types involving enum types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115157 --- Comment #4 from Richard Earnshaw --- The tests in the last patch fail on arm-eabi. The tests assume that sizeof(enum) == sizeof(int), which is not true if -fshort-enum is the default. + Changes for ./gcc/testsuite/gcc/gcc.sum.sent + New tests that FAIL (6 tests): arm-qemu/-mthumb: gcc: gcc.dg/enum-alias-1.c (test for excess errors) arm-qemu/-mthumb: gcc: gcc.dg/enum-alias-2.c execution test arm-qemu/-mthumb: gcc: gcc.dg/enum-alias-3.c execution test
[Bug c++/95349] Using std::launder(p) produces unexpected behavior where (p) produces expected behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #49 from Christopher Nerz ---
Ah, misunderstood and therefore forgot optimization to a constant.
In the current code example, we have the problem that the (second)
initialization does not initialize with a value (ergo undefined behaviour due
to uninitialized variable although it is created in an initialized memory).
In the more complex code - which I am trying to simplify, but so far get the
behaviour only in quite special situations which are hard to reduce to an
example - we have that the buffer is explicitly initialized via `new T{}`
(calling an inline initialization, i.e. not a trivial default constructor, but
T is trivially copy & move constructible), then the buffer is copied (as
std::byte-array) and then std::launder is applied to the resulting byte-array.
To my understanding [basic.types.general].$3
> For two distinct objects obj1 and obj2 of trivially copyable type T, where
> neither obj1 nor obj2 is a potentially-overlapping subobject, if the
> underlying bytes (6.7.1) making up obj1 are copied into obj2, obj2 shall
> subsequently hold the same value as obj1.
guarantees that the copied buffer can be used as `T` via
`*std::launder(second_buffer)`. Clang, MSVC agree, gcc does not.
Again: Still trying to construct the minimal example for that behavior :-/
[Bug tree-optimization/115304] gcc.dg/vect/slp-gap-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115304
--- Comment #5 from Thomas Schwinge ---
Created attachment 58333
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58333=edit
'c2' GCN target ('-march=gfx908') 'slp-gap-1.c.179t.vect'
(In reply to r...@cebitec.uni-bielefeld.de from comment #3)
> > --- Comment #2 from Richard Biener ---
> > It should only need vect32 - basically I assumed the target can compose the
> > 64bit vector from two 32bit elements. But it might be that for this to work
> > the loads would need to be aligned.
> >
> > What is needed is char-to-short unpacking and vector composition. Either
> > composing V2SImode or V8QImode from two V4QImode vectors.
> >
> > Does the following help?
>
> Unfortunately not: makes no difference AFAICS.
Also doesn't resolve the issue for GCN target (tested '-march=gfx908'); see
attached 'c2' GCN target ('-march=gfx908') 'slp-gap-1.c.179t.vect'.
[Bug tree-optimization/115304] gcc.dg/vect/slp-gap-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115304
--- Comment #4 from Thomas Schwinge ---
Created attachment 58332
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58332=edit
GCN target ('-march=gfx908') 'slp-gap-1.c.179t.vect'
Similar (I suppose?) for GCN target (tested '-march=gfx908'):
+PASS: gcc.dg/vect/slp-gap-1.c (test for excess errors)
+FAIL: gcc.dg/vect/slp-gap-1.c scan-tree-dump-times vect "{_[0-9]+, 0" 6
[Bug tree-optimization/115304] gcc.dg/vect/slp-gap-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115304 Thomas Schwinge changed: What|Removed |Added Target|sparc*-sun-solaris2.11 |sparc*-sun-solaris2.11 GCN Status|UNCONFIRMED |NEW Last reconfirmed||2024-06-03 Ever confirmed|0 |1 CC||ams at gcc dot gnu.org, ||tschwinge at gcc dot gnu.org
[Bug target/115325] RVV vmulh and vmulhu unknown without -march, but vmul is known
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115325 --- Comment #1 from Andrew Pinski --- The correct way of doing this is to use `pragma GCC target` but that is not supported on riscv yet ...
[Bug c++/115325] New: RVV vmulh and vmulhu unknown without -march, but vmul is known
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115325 Bug ID: 115325 Summary: RVV vmulh and vmulhu unknown without -march, but vmul is known Product: gcc Version: 14.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jan.wassenberg at gmail dot com Target Milestone: --- To allow runtime dispatch (detecting at runtime whether V is available), we would like to compile without -march=. In GCC 13 for RVV this raised an #error. Looks like there has been progress in GCC 14, no more #error in riscv_vector.h, but there is a strange difference between vmulh and vmulh. Repro: https://gcc.godbolt.org/z/9PjEajq7r When compiling without -march, vmul is at least known, though we get "return type 'vint64m1_t' requires the V ISA extension". We are almost but not entirely able to get rid of this by using vectors only within the function: https://gcc.godbolt.org/z/W74j7nzvs (This is also blocking runtime dispatch.) When compiling without -march, the situation worsens: changing vmul to vmulh results in "error: '__riscv_vmulh_vv_i64m1' was not declared in this scope; did you mean '__riscv_vmul_vv_i64m1'?".
[Bug c++/95349] Using std::launder(p) produces unexpected behavior where (p) produces expected behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349 --- Comment #48 from Richard Biener --- (In reply to Christopher Nerz from comment #47) > But shouldn't both give the same value? I'm not sure what the standard says to this. Does std::launder(...) sanitize earlier "undefined behavior"? For example failing to initialize an object? > The return of the new and the std::launder(...) point to the same object and > are both equal read-operations! It is imho not predictable that they behave > differently. One load we can optimize to a constant, the other not (because of .LAUNDER).
[Bug tree-optimization/115304] gcc.dg/vect/slp-gap-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115304 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #2 from Richard Biener --- > It should only need vect32 - basically I assumed the target can compose the > 64bit vector from two 32bit elements. But it might be that for this to work > the loads would need to be aligned. > > What is needed is char-to-short unpacking and vector composition. Either > composing V2SImode or V8QImode from two V4QImode vectors. > > Does the following help? Unfortunately not: makes no difference AFAICS.
[Bug target/115324] [12/13/14/15 Regression] PCH of rs6000 builtins broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115324 --- Comment #2 from Jakub Jelinek --- Created attachment 58331 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58331=edit gcc15-pr115324.patch Untested fix.
[Bug c++/95349] Using std::launder(p) produces unexpected behavior where (p) produces expected behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #47 from Christopher Nerz ---
But shouldn't both give the same value?
The return of the new and the std::launder(...) point to the same object and
are both equal read-operations! It is imho not predictable that they behave
differently.
Note that I could construct the same behavior when creating a std::byte array
(within a complex structure) in which a (trivially copy, move, default
constructible (and destructable)) object is created via new, then the
surrounding complex structure is copied and then the copied byte array read as
this kind of object. So rougly
```
struct data { std::byte mem[8]; }
data d1;
new (d1.mem) long{5};
data d2 = std::move(d1);
*std::launder(reinterpret_cast(d2.mem));
```
not literally that code (that one is working), but conceptionally the same
thing.
I have to check whether NRVO in our code removes the move...
[Bug sanitizer/115323] [10/11/12 Regression] signed integer overflow check missing at -O0, -O2, -O3, -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115323 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- This is not a regression as it has always been a bug, it was only fixed in GCC 13+. Dup of bug 108256. *** This bug has been marked as a duplicate of bug 108256 ***
[Bug sanitizer/108256] Missing integer overflow instrumentation when assignment LHS is narrow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108256 --- Comment #7 from Andrew Pinski --- *** Bug 115323 has been marked as a duplicate of this bug. ***
[Bug target/115324] [12/13/14/15 Regression] PCH of rs6000 builtins broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115324
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Target Milestone|--- |12.4
Summary|[12/13/14/15 Regression]|[12/13/14/15 Regression]
|PCH (and maybe GC) of |PCH of rs6000 builtins
|rs6000 builtins broken |broken
Ever confirmed|0 |1
Last reconfirmed||2024-06-03
--- Comment #1 from Jakub Jelinek ---
While for GC everything looks ok, in particular we have
{
_instance_info[0].fntype,
1 * (RS6000_INST_MAX),
sizeof (rs6000_instance_info[0]),
_ggc_mx_tree_node,
_pch_nx_tree_node
},
{
_builtin_info[0].fntype,
1 * (RS6000_BIF_MAX),
sizeof (rs6000_builtin_info[0]),
_ggc_mx_tree_node,
_pch_nx_tree_node
},
GC roots which are strided so that they cover just the fntype fields in
rs6000_instance_info and rs6000_builtin_info, it causes problems for PCH,
because
PCH saves/restores the whole rs6000_instance_info/rs6000_builtin_info arrays,
which are huge and worse the contain quite a lot of pointers to .rodata/.data
sections besides the tree fntype members.
In struct bifdata it is
const char *GTY((skip(""))) bifname;
...
const char *GTY((skip(""))) attr_string;
and in struct ovlddata
const char *GTY((skip(""))) bifname;
...
ovlddata *GTY((skip(""))) next;
fields. bifname and attr_string members point to string literals, so .rodata
section,
and next is either NULL or _instance_info[RS6000_INST_XXX]
Now, the problem is when cc1/cc1plus etc. are PIEs, the saving is done when
.rodata/.data sections are loaded at one address, but the restoring can be done
when they are loaded at different address, so the pointers are garbage after
PCH restore.
We could extend GTY, to have a similar flag to callback where we'd somehow fix
up those pointers in global GTY roots.
Or I think we can just move the fntype members from those structures to
separate arrays, making the original arrays non-GTY and only GTY the new
*_fntype arrays.
I've implemented the latter, will attach it momentarily.
It seems to decrease the size of .data arrays.
vanillapatched
rs6000_builtin_info 130832 110704
rs6000_instance_info 81568 40784
rs6000_overload_info 7392 7392
rs6000_builtin_info_fntype0 10064
rs6000_instance_info_fntype 0 20392
sum 219792 189336
On a cross from x86_64 -> powerpc64le it increases .text size in the
_Z30rs6000_init_generated_builtinsv function, but will need to find out if that
is also the case on powerpc64le native where section anchors are used, the
changes in the source are like:
rs6000_overload_info[RS6000_OVLD_VEC_VSUBFP - base].first_instance
-= _instance_info[RS6000_INST_VSUBFP_DEPR1];
+= RS6000_INST_VSUBFP_DEPR1;
- rs6000_instance_info[RS6000_INST_VSUBSBS_DEPR1].fntype
+ rs6000_instance_info_fntype[RS6000_INST_VSUBSBS_DEPR1]
= v16qi_ftype_v16qi_v16qi;
and
- rs6000_builtin_info[RS6000_BIF_CFSTRING].fntype
+ rs6000_builtin_info_fntype[RS6000_BIF_CFSTRING]
= v_ftype_v;
so there is IMO nothing inherently larger.
[Bug c++/95349] Using std::launder(p) produces unexpected behavior where (p) produces expected behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
Richard Biener changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=101641
--- Comment #46 from Richard Biener ---
(In reply to Christopher Nerz from comment #45)
> This is a critical bug which renders gcc unusable for safety relevant
> systems using expected/variant or simple ipc.
>
> You can get the same buggy behavior with far simpler code:
> https://godbolt.org/z/1WTnnYceM
>
>
> #include
> #include
>
> bool check()
> {
> // Just to prove that it is not a problem with alignment etc.
> static_assert(alignof(double) == alignof(std::uint64_t));
> static_assert(sizeof(double) == sizeof(std::uint64_t));
>
> alignas(8) std::byte buffer[8]; // some buffer
> new (buffer) double{1}; // some completely trivial data
> // reuse memory -> double ends lifetime, uint64 starts lifetime
> std::uint64_t * res = new (buffer) std::uint64_t;
> // *res is allowed to be used as it is the correct pointer returned by
> new
> // *res == 0x3ff0 // and gives correct value
> // The very definition of std::launder says that it is suppose to be
> used as:
> return (*res == *std::launder(reinterpret_cast(buffer)));
> }
>
> int main(int argc, char **argv) {
> return check(); // gives false with activatred O2 (true with O0)
> }
>
>
> We get the same behavior when initialisating the memory at our version of
> "std::uint64_t * res = new (buffer) std::uint64_t;", but were unable to give
> a minimal example for that behavior.
For this case we end up with an indetermined value for 'buffer' read as
uint64_t but that indetermined value is different from the one read after
.LAUNDER. A somewhat early IL is
MEM[(double *)] = 1.0e+0;
_1 = MEM[(uint64_t *)];
_12 = .LAUNDER ();
_3 = *_12;
_13 = _1 == _3;
we then re-interpret 1.0e+0 as uint64_t and then remove the store as dead
because there's no valid use - the *_12 load is done as uint64_t.
The effect is that the later load reads from uninitialized stack.
Note that .LAUNDER only constitutes a data dependence between the
and _12 pointer _values_ but there's no dependence of the memory contents
pointed to - .LAUNDER is ECF_NOVOPS. That makes the compiler forget
what _12 points to but it doesn't make later uint64 loads valid from
*_12 from an earlier store to double.
[Bug target/115324] New: [12/13/14/15 Regression] PCH (and maybe GC) of rs6000 builtins broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115324
Bug ID: 115324
Summary: [12/13/14/15 Regression] PCH (and maybe GC) of rs6000
builtins broken
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: belegdol at gmail dot com, dan at danny dot cz
Depends on: 104323
Target Milestone: ---
+++ This bug was initially created as a clone of Bug #104323 +++
The PR104323 fix doesn't seem to work with --enable-host-pie.
cat pr104323.h
#include
cat pr104323.c
/* { dg-require-effective-target powerpc_altivec_ok } */
/* { dg-options "-maltivec" } */
#include "pr104323.h"
__vector int a1 = { 100, 200, 300, 400 };
__vector int a2 = { 500, 600, 700, 800 };
__vector int r;
int
main ()
{
r = vec_add (a1, a2);
return 0;
}
./xgcc -B ./ -c pr104323.h -o pr104323.h.gch
./xgcc -B ./ -S pr104323.c
pr104323.c: In function ‘main’:
pr104323.c:13:3: internal compiler error: Segmentation fault
13 | r = vec_add (a1, a2);
| ^
0x5625e2834b83 crash_signal
../../gcc/toplev.cc:319
0x5625e228c56d altivec_resolve_overloaded_builtin(unsigned int, tree_node*,
void*)
../../gcc/config/rs6000/rs6000-c.cc:1997
0x5625e2190392 c_build_function_call_vec(unsigned int, vec const&, tree_node*, vec*,
vec*)
../../gcc/c/c-typeck.cc:3440
0x5625e21c4536 c_parser_postfix_expression_after_primary
../../gcc/c/c-parser.cc:12682
0x5625e21a99a5 c_parser_postfix_expression
../../gcc/c/c-parser.cc:12234
0x5625e21ae60a c_parser_unary_expression
../../gcc/c/c-parser.cc:9894
0x5625e21b01df c_parser_cast_expression
../../gcc/c/c-parser.cc:9735
0x5625e21b04db c_parser_binary_expression
../../gcc/c/c-parser.cc:9503
0x5625e21b1a93 c_parser_conditional_expression
../../gcc/c/c-parser.cc:9198
0x5625e21b2324 c_parser_expr_no_commas
../../gcc/c/c-parser.cc:9111
0x5625e21b23ea c_parser_expr_no_commas
../../gcc/c/c-parser.cc:9154
0x5625e21b2773 c_parser_expression
../../gcc/c/c-parser.cc:12822
0x5625e21b2c57 c_parser_expression_conv
../../gcc/c/c-parser.cc:12862
0x5625e21d5b57 c_parser_statement_after_labels
../../gcc/c/c-parser.cc:7800
0x5625e21a942b c_parser_compound_statement_nostart
../../gcc/c/c-parser.cc:7287
0x5625e21d2136 c_parser_compound_statement
../../gcc/c/c-parser.cc:6564
0x5625e21d45af c_parser_declaration_or_fndef
../../gcc/c/c-parser.cc:3019
0x5625e21deb73 c_parser_external_declaration
../../gcc/c/c-parser.cc:2048
0x5625e21df5cb c_parser_translation_unit
../../gcc/c/c-parser.cc:1902
0x5625e21df5cb c_parse_file()
../../gcc/c/c-parser.cc:27269
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/115303] gcc.dg/vect/pr112325.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115303 Rainer Orth changed: What|Removed |Added Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |ro at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-June/65 ||3422.html --- Comment #4 from Rainer Orth --- Fixed for GCC 15.0.
[Bug tree-optimization/115303] gcc.dg/vect/pr112325.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115303 --- Comment #3 from GCC Commits --- The master branch has been updated by Rainer Orth : https://gcc.gnu.org/g:2a616df8260aeabe00a28ea3870dba5577dbbe66 commit r15-987-g2a616df8260aeabe00a28ea3870dba5577dbbe66 Author: Rainer Orth Date: Mon Jun 3 10:39:34 2024 +0200 testsuite: Require vect_shift in gcc.dg/vect/pr112325.c [PR115303] The new gcc.dg/vect/pr112325.c test FAILs on Solaris/SPARC: FAIL: gcc.dg/vect/pr112325.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 1 FAIL: gcc.dg/vect/pr112325.c scan-tree-dump-times vect "vectorized 1 loops" 1 As analyzed in the PR, the test requires vect_shift, so this patch adds that requirement. Tested on i386-pc-solaris2.11 and sparc-sun-solaris2.11. 2024-06-03 Rainer Orth gcc/testsuite: PR tree-optimization/115303 * gcc.dg/vect/pr112325.c: Require vect_shift.
