[Bug tree-optimization/107090] [aarch64] sequence logic should be combined with mul and umulh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107090 --- Comment #11 from vfdff --- Created attachment 53787 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53787=edit has different operand order base on different commit node hi @Andrew Pinski * Showed as the figure swap_order.jpg attaiched, we can introduce flags :c for the plus node m_13 to match commutated node according https://gcc.gnu.org/onlinedocs/gccint/The-Language.html. And for the plus node _24, does it also have some similar flag to simplify the matching ?
[Bug tree-optimization/107451] [11/12/13 Regression] Segmentation fault with vectorized code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107451 bartoldeman at users dot sourceforge.net changed: What|Removed |Added Attachment #53785|0 |1 is obsolete|| --- Comment #3 from bartoldeman at users dot sourceforge.net --- Created attachment 53786 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53786=edit Corrected test case In my eagerness to make it as short as possible I made it too short indeed!
[Bug tree-optimization/103035] [meta-bug] YARPGen bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103035 Bug 103035 depends on bug 98694, which changed state. Bug 98694 Summary: GCC produces incorrect code for loops with -O3 for skylake-avx512 and icelake-server https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98694 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/98694] GCC produces incorrect code for loops with -O3 for skylake-avx512 and icelake-server
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98694 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |10.4 Status|NEW |RESOLVED Known to work||10.4.0 --- Comment #14 from Vsevolod Livinskii --- Should this issue be marked as Resolved and Fixed? --- Comment #15 from Andrew Pinski --- Fixed.
[Bug c++/102786] [c++20] virtual pmf sometimes rejected as not a constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102786 Andrew Pinski changed: What|Removed |Added Known to work||10.4.0, 12.1.0, 9.5.0 Target Milestone|--- |9.5
[Bug c/101176] valgrind error for c-c++-common/builtin-has-attribute.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101176 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |9.5
[Bug rtl-optimization/101008] ICE: in native_encode_rtx, at simplify-rtx.c:6594 with -O -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101008 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.4
[Bug fortran/107397] [10/11/12/13 Regression] ICE in gfc_arith_plus, at fortran/arith.cc:654
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107397 --- Comment #6 from anlauf at gcc dot gnu.org --- (In reply to Steve Kargl from comment #5) > No. I have no idea how to add a testcase to git. > Every time I've tried, I end up deleting my git > repository and grabbing a new clone. Not a pleasant > developer experience. The workflow with git is really simple: git add path/to/file ... git commit (git gcc-commit-mklog is a tailored version for working with the gcc repo.) To create a patch for submitting, git format-patch -1 (if you don't need fancy stuff like a patch series...) With "git rebase" you can do really many useful things you would never dream of with svn. It's also easy to remove a commit from your local worktree or reorder commits (using rebase), or resetting your worktree, ... I really think you just need a good primer.
[Bug fortran/107397] [10/11/12/13 Regression] ICE in gfc_arith_plus, at fortran/arith.cc:654
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107397 --- Comment #5 from Steve Kargl --- On Fri, Oct 28, 2022 at 08:31:58PM +, anlauf at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107397 > > --- Comment #4 from anlauf at gcc dot gnu.org --- > (In reply to kargl from comment #3) > > This patch fixes the ICE and issues an error. It has passed > > regression testing. > > Great! > > Do you plan to submit your patch? (Hint: git gcc-commit-mklog). > No. I have no idea how to add a testcase to git. Every time I've tried, I end up deleting my git repository and grabbing a new clone. Not a pleasant developer experience.
[Bug target/107453] New stdarg tests in r13-3549-g4fe34cdcc80ac2 fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107453 --- Comment #1 from Andrew Pinski --- >From https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604152.html: It's possible further target-specific fixes will be needed; target maintainers should watch out for failures of c2x-stdarg-4.c, the execution test, which would indicate that this feature is not working correctly.
[Bug other/107453] New: New stdarg tests in r13-3549-g4fe34cdcc80ac2 fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107453 Bug ID: 107453 Summary: New stdarg tests in r13-3549-g4fe34cdcc80ac2 fail Product: gcc Version: 13.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:4fe34cdcc80ac225b80670eabc38ac5e31ce8a5a, r13-3549-g4fe34cdcc80ac2 FAIL: gcc.dg/c2x-stdarg-4.c execution test FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c -O0 execution test FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c -O1 execution test FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c -O2 execution test FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c -O3 -g execution test FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c -Os execution test One traceback (gdb) run Starting program: /home/seurer/gcc/git/build/gcc-test/c2x-stdarg-4.exe Program received signal SIGABRT, Aborted. 0x202192a8 in raise () from /lib64/glibc-hwcaps/power9/libc-2.28.so (gdb) where #0 0x202192a8 in raise () from /lib64/glibc-hwcaps/power9/libc-2.28.so #1 0x201f3eb4 in abort () from /lib64/glibc-hwcaps/power9/libc-2.28.so #2 0x1fa0 in main () at /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/c2x-stdarg-4.c:153 The abort is from here: if (f (1, 2.0, 3, 4.0) != 10.0) abort (); Author: Joseph Myers Date: Fri Oct 28 14:40:25 2022 + c: tree: target: C2x (...) function prototypes and va_start relaxation
[Bug fortran/103413] [10/11/12/13 Regression] ICE: Invalid expression in gfc_element_size since r10-2083-g8dc63166e0b85954
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103413 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #20 from anlauf at gcc dot gnu.org --- Fixed on an open branches. Closing. Thanks for the report!
[Bug fortran/103413] [10/11/12/13 Regression] ICE: Invalid expression in gfc_element_size since r10-2083-g8dc63166e0b85954
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103413 --- Comment #19 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:3b4c9e0658b13b8db6c7f38242ed270cdb8fc932 commit r10-11063-g3b4c9e0658b13b8db6c7f38242ed270cdb8fc932 Author: Harald Anlauf Date: Wed Oct 26 21:00:44 2022 +0200 Fortran: BOZ literal constants are not compatible to any type [PR103413] gcc/fortran/ChangeLog: PR fortran/103413 * symbol.c (gfc_type_compatible): A boz-literal-constant has no type and thus is not considered compatible to any type. gcc/testsuite/ChangeLog: PR fortran/103413 * gfortran.dg/illegal_boz_arg_4.f90: New test. (cherry picked from commit f7d28818179247685f3c101f9f2f16366f56309b)
[Bug target/93177] PPC: Missing many useful platform intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93177 --- Comment #22 from Sergey Fedorov --- (In reply to Iain Sandoe from comment #19) > Created attachment 53779 [details] > introduce ppc_intrinsics.h for powerpc*-darwin. > > This takes the header from the GCC-4.x apple debt branch (as present in SVN: > r113478) and > - updates the license. > - installs for powerpc*-darwin > > It needs the test cases forward porting too. > However, it would be good to know if this solves the problems folks have > encountered here (if other ports want to try it, why only need to amend > their entry in gcc/config.gcc) Thank you! I will try it.
[Bug fortran/103413] [10/11/12/13 Regression] ICE: Invalid expression in gfc_element_size since r10-2083-g8dc63166e0b85954
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103413 --- Comment #18 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:f2298bd50109e5460e8949290b5337ec28310e91 commit r11-10343-gf2298bd50109e5460e8949290b5337ec28310e91 Author: Harald Anlauf Date: Wed Oct 26 21:00:44 2022 +0200 Fortran: BOZ literal constants are not compatible to any type [PR103413] gcc/fortran/ChangeLog: PR fortran/103413 * symbol.c (gfc_type_compatible): A boz-literal-constant has no type and thus is not considered compatible to any type. gcc/testsuite/ChangeLog: PR fortran/103413 * gfortran.dg/illegal_boz_arg_4.f90: New test. (cherry picked from commit f7d28818179247685f3c101f9f2f16366f56309b)
[Bug c/102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 --- Comment #32 from joseph at codesourcery dot com --- On Fri, 28 Oct 2022, jakub at gcc dot gnu.org via Gcc-bugs wrote: > > That said, if C allows us to limit to 128bits then let's do that for now. > > 32bit targets will still see all the complication when we give that a stab. > > I'm afraid once we define BITINT_MAXWIDTH, it will become part of the ABI, so > we can't increase it afterwards. I don't think it's part of the ABI; I think it's always OK to increase BITINT_MAXWIDTH, as long as the wider types don't need more alignment than the previous choice of max_align_t. Thus, starting with a 128-bit limit (or indeed a 64-bit limit on 32-bit platforms, so that all the types fix within existing modes supported for arithmetic), and adding support for wider _BitInt later, would be a reasonable thing to do. (You still have ABI considerations even with such a limit: apart from the padding question, on x86_64 the ABI says _BitInt(128) is 64-bit aligned but __int128 is 128-bit aligned.) > Anyway, I'm afraid we probably don't have enough time to implement this > properly in stage1, so might need to target GCC 14 with it. Unless somebody > spends on it > the remaining 2 weeks full time. I think https://gcc.gnu.org/pipermail/gcc/2022-October/239704.html is still current as a list of C2x language features likely not to make it into GCC 13. (I hope to get auto and constexpr done in the next two weeks, and the other C2x language features not on that list are done.)
[Bug fortran/103413] [10/11/12/13 Regression] ICE: Invalid expression in gfc_element_size since r10-2083-g8dc63166e0b85954
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103413 --- Comment #17 from CVS Commits --- The releases/gcc-12 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:9831a5f4843b573bbdb2688bbf2de864b4e8be8b commit r12-8875-g9831a5f4843b573bbdb2688bbf2de864b4e8be8b Author: Harald Anlauf Date: Wed Oct 26 21:00:44 2022 +0200 Fortran: BOZ literal constants are not compatible to any type [PR103413] gcc/fortran/ChangeLog: PR fortran/103413 * symbol.cc (gfc_type_compatible): A boz-literal-constant has no type and thus is not considered compatible to any type. gcc/testsuite/ChangeLog: PR fortran/103413 * gfortran.dg/illegal_boz_arg_4.f90: New test. (cherry picked from commit f7d28818179247685f3c101f9f2f16366f56309b)
[Bug fortran/107397] [10/11/12/13 Regression] ICE in gfc_arith_plus, at fortran/arith.cc:654
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107397 --- Comment #4 from anlauf at gcc dot gnu.org --- (In reply to kargl from comment #3) > This patch fixes the ICE and issues an error. It has passed > regression testing. Great! Do you plan to submit your patch? (Hint: git gcc-commit-mklog).
[Bug c/102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #31 from joseph at codesourcery dot com ---
On Fri, 28 Oct 2022, rguenth at gcc dot gnu.org via Gcc-bugs wrote:
> I wouldn't go with a new tree code, given semantics are INTEGER_TYPE it should
> be an INTEGER_TYPE.
Implementation note in that case: bit-precise integer types aren't allowed
as underlying types for enums, so the code in
c-parser.cc:c_parser_enum_specifier checking underlying types:
else if (TREE_CODE (specs->type) != INTEGER_TYPE
&& TREE_CODE (specs->type) != BOOLEAN_TYPE)
{
error_at (enum_loc, "invalid % underlying type");
would then need to check that the type isn't a bit-precise type.
[Bug target/105549] aarch64: Wrong va_arg alignment handling with packed bitfields and alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105549 Andrew Pinski changed: What|Removed |Added Summary|aarch64: Wrong va_arg |aarch64: Wrong va_arg |alignment handling |alignment handling with ||packed bitfields and ||alignment Ever confirmed|0 |1 Last reconfirmed||2022-10-28 Status|UNCONFIRMED |ASSIGNED Keywords||ABI --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/105597] [13 Regression] ice in type, at value-range.h:223
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105597 Andrew Pinski changed: What|Removed |Added Component|c |tree-optimization Summary|ice in type, at |[13 Regression] ice in |value-range.h:223 |type, at value-range.h:223 Target Milestone|--- |13.0 Version|12.0|13.0 Keywords||ice-on-valid-code
[Bug fortran/107441] optional arguments are identified as "present" when missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107441 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #10 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2022-October/058398.html
[Bug c++/107452] Failed to catch C++ exception thrown from multiarch-function (x64 CPUs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107452 --- Comment #2 from Andrew Pinski --- >Is this a known GCC issue? If needed I could also try to write a minimal test >that reproduces this issue. Yes it is a known issue as shown by the duplicate bug report. The duplicate bug report has a nice minimal testcase already so you don't need to write one but thanks for the offer.
[Bug c++/107452] Failed to catch C++ exception thrown from multiarch-function (x64 CPUs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107452 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 106627. *** This bug has been marked as a duplicate of bug 106627 ***
[Bug ipa/106627] Exception from multiversion function cannot be caught
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106627 Andrew Pinski changed: What|Removed |Added CC||kim.walisch at gmail dot com --- Comment #5 from Andrew Pinski --- *** Bug 107452 has been marked as a duplicate of this bug. ***
[Bug c++/107452] New: Failed to catch C++ exception thrown from multiarch-function (x64 CPUs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107452 Bug ID: 107452 Summary: Failed to catch C++ exception thrown from multiarch-function (x64 CPUs) Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: kim.walisch at gmail dot com Target Milestone: --- Hi, Tested using: GCC 11.2.0, Ubuntu 22.10 x64 Tested using: GCC 9.4.0, Ubuntu 18.04 x64 I am using the GCC multiarch feature (also known as function multiversioning: https://gcc.gnu.org/onlinedocs/gcc/Function-Multiversioning.html) in my primesieve C++ project to take advantage of the latest supported CPU instruction set e.g. AVX, AVX2, AVX512 (on x64 CPUs). Today I found out that if I throw a C++ exception from a multiarch-function and I try to catch that exception outside of the originating multiarch-function but within the same translation unit, then catching the exception fails and my program simply aborts. My exception is thrown from here: https://github.com/kimwalisch/primesieve/blob/776c102f92905401613a83508d60744d41df7c73/src/PrimeGenerator.cpp#L332 It should be caught here: https://github.com/kimwalisch/primesieve/blob/776c102f92905401613a83508d60744d41df7c73/src/iterator-c.cpp#L151 My bug can be reproduced using these steps: git clone https://github.com/kimwalisch/primesieve.git cd primesieve && mkdir build && cd build git checkout 776c102f92905401613a83508d60744d41df7c73 CXXFLAGS="-O2 -Wall -Wextra -pedantic" cmake .. -DBUILD_TESTS=ON -DCMAKE_BUILD_TYPE=Debug -DWITH_MULTIARCH=ON && make -j8 test/next_prime2 The test/next_prime2 will fail with the following error message: terminate called after throwing an instance of 'primesieve::primesieve_error' what(): cannot generate primes > 2^64 Aborted If I recompile without function multiversioning (-DWITH_MULTIARCH=OFF) the same exception is caught successfully: rm -rf * CXXFLAGS="-O2 -Wall -Wextra -pedantic" cmake .. -DBUILD_TESTS=ON -DCMAKE_BUILD_TYPE=Debug -DWITH_MULTIARCH=OFF && make -j8 test/next_prime2 The test/next_prime2 completes successfully: ... primesieve_iterator: cannot generate primes > 2^64 next_prime(18446744073709551615) = PRIMESIEVE_ERROR: OK primesieve_iterator: cannot generate primes > 2^64 next_prime(18446744073709551615) = PRIMESIEVE_ERROR: OK All tests passed successfully! Clang also supports function multiversioning on Linux & x64 CPUs. And with Clang this issue is not present, with Clang catching C++ exceptions thrown from a multiarch-function works flawlessly (tested using Clang 14.0.0 on Ubuntu 22.10 x64): rm -rf * CXX=clang++ CC=clang CXXFLAGS="-O2 -Wall -Wextra -pedantic" cmake .. -DBUILD_TESTS=ON -DCMAKE_BUILD_TYPE=Debug -DWITH_MULTIARCH=ON && make -j8 test/next_prime2 The test/next_prime2 completes successfully: ... primesieve_iterator: cannot generate primes > 2^64 next_prime(18446744073709551615) = PRIMESIEVE_ERROR: OK primesieve_iterator: cannot generate primes > 2^64 next_prime(18446744073709551615) = PRIMESIEVE_ERROR: OK All tests passed successfully! Is this a known GCC issue? If needed I could also try to write a minimal test that reproduces this issue.
[Bug tree-optimization/107451] [11/12/13 Regression] Segmentation fault with vectorized code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107451
Andrew Pinski changed:
What|Removed |Added
Known to work||10.4.0
Status|RESOLVED|NEW
Target Milestone|--- |11.4
Last reconfirmed||2022-10-28
Summary|Segmentation fault with |[11/12/13 Regression]
|vectorized code.|Segmentation fault with
||vectorized code.
Resolution|INVALID |---
Ever confirmed|0 |1
Known to fail||11.1.0
--- Comment #2 from Andrew Pinski ---
I think this code is undefined as x/y are arrays of size 1 but you access one
past.
But here is the main which makes this well defined:
int main(void)
{
double x[2] = {0,0}, y[2] = {0,0};
return dot(1, [0], 4096*4096, [0]);
}
Still an issue on the trunk.
Confirmed.
[Bug tree-optimization/107451] Segmentation fault with vectorized code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107451
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Jakub Jelinek ---
The bug is in the testcase:
gcc -fsanitize=undefined,address -g -o /tmp/pr107451{,.c}; /tmp/pr107451
=
==2296364==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7ffca382d798 at pc 0x0040148c bp 0x7ffca382d680 sp 0x7ffca382d678
READ of size 8 at 0x7ffca382d798 thread T0
#0 0x40148b in dot /tmp/pr107451.c:9
#1 0x4019f8 in main /tmp/pr107451.c:21
#2 0x7f8c74de858f in __libc_start_call_main (/lib64/libc.so.6+0x2958f)
#3 0x7f8c74de8648 in __libc_start_main@GLIBC_2.2.5
(/lib64/libc.so.6+0x29648)
#4 0x4010f4 in _start (/tmp/pr107451+0x4010f4)
Address 0x7ffca382d798 is located in stack of thread T0 at offset 40 in frame
#0 0x401922 in main /tmp/pr107451.c:19
This frame has 2 object(s):
[32, 40) 'x' (line 20) <== Memory access at offset 40 overflows this
variable
[64, 72) 'y' (line 20)
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism, swapcontext or vfork
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow /tmp/pr107451.c:9 in dot
Shadow bytes around the buggy address:
0x1000146fdaa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1000146fdab0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1000146fdac0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1000146fdad0: 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00
0x1000146fdae0: 00 00 f3 f3 f3 f3 00 00 00 00 00 00 00 00 f1 f1
=>0x1000146fdaf0: f1 f1 00[f2]f2 f2 00 f3 f3 f3 00 00 00 00 00 00
0x1000146fdb00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1000146fdb10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1000146fdb20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1000146fdb30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1000146fdb40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user:f7
Container overflow: fc
Array cookie:ac
Intra object redzone:bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone:cb
==2296364==ABORTING
x[ix+1] or y[ix+1] when ix is 0 and x is in main or y in main
is an out of bounds access.
[Bug tree-optimization/107451] New: Segmentation fault with vectorized code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107451
Bug ID: 107451
Summary: Segmentation fault with vectorized code.
Product: gcc
Version: 11.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: bartoldeman at users dot sourceforge.net
Target Milestone: ---
Created attachment 53785
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53785=edit
Test case
The following code:
double dot(int n, const double *x, int inc_x, const double *y)
{
int i, ix;
double dot[4] = { 0.0, 0.0, 0.0, 0.0 } ;
ix=0;
for(i = 0; i < n; i++) {
dot[0] += x[ix] * y[ix] ;
dot[1] += x[ix+1] * y[ix+1] ;
dot[2] += x[ix] * y[ix+1] ;
dot[3] += x[ix+1] * y[ix] ;
ix += inc_x ;
}
return dot[0] + dot[1] + dot[2] + dot[3];
}
int main(void)
{
double x = 0, y = 0;
return dot(1, , 4096*4096, );
}
crashes with (on Linux x86-64)
$ gcc -O2 -ftree-vectorize -march=haswell crash.c -o crash
$ ./a.out
Segmentation fault
for GCC 11.3.0 and also the current prerelease (gcc version 11.3.1 20221021),
and also when patched with the patches from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107254 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107212.
The loop code assembly is as follows:
18: c5 f9 10 1e vmovupd (%rsi),%xmm3
1c: c5 f9 10 21 vmovupd (%rcx),%xmm4
20: ff c2 inc%edx
22: c4 e3 65 18 0c 06 01vinsertf128 $0x1,(%rsi,%rax,1),%ymm3,%ymm1
29: c4 e3 5d 18 04 01 01vinsertf128 $0x1,(%rcx,%rax,1),%ymm4,%ymm0
30: 48 01 c6add%rax,%rsi
33: 48 01 c1add%rax,%rcx
36: c4 e3 fd 01 c9 11 vpermpd $0x11,%ymm1,%ymm1
3c: c4 e3 fd 01 c0 14 vpermpd $0x14,%ymm0,%ymm0
42: c4 e2 f5 b8 d0 vfmadd231pd %ymm0,%ymm1,%ymm2
47: 39 fa cmp%edi,%edx
49: 75 cd jne18
what happens here is that the vinsertf128 instructions take the element from
one loop iteration later, and those get put in the high halves of ymm0 and
ymm1.
The vpermpd instructions then throw away those high halves again, so e.g. they
turn 1,2,3,4 into 2,1,2,1 and 1,2,2,1 respectively.
So the result is correct but the superfluous vinsertf128 instructions access
memory potentially past the end of x or y and thus a produce a segfault.
related issue (coming from OpenBLAS):
https://github.com/easybuilders/easybuild-easyconfigs/issues/16387
may also be related:
https://github.com/xianyi/OpenBLAS/issues/3740#issuecomment-1233899834
(the particular comment shows very similar code but it's for GCC 12 which
vectorizes by default, OpenBLAS worked around this by disabling the tree
vectorizer there but only on Mac OS and Windows).
[Bug c/102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 --- Comment #30 from Andrew Pinski --- I have an use case until 1k except I don't need division. It will in handy while translating P4 language (https://p4.org/p4-spec/docs/P4-16-v-1.2.3.html) to C. P4 supports any bit size you want and there are some uses for > 128 for crypto; usually just a storage area for the key at that point.
[Bug testsuite/106806] [13 regression] gcc.dg/tree-ssa/gen-vect-34.c fails after r13-2333-gca8f4e8af14869
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106806 seurer at gcc dot gnu.org changed: What|Removed |Added Target|powerpc64le-linux-gnu |powerpc64le-linux-gnu |hppa-linux-gnu |powerpc64-linux-gnuhppa-lin ||ux-gnu Build|powerpc64le-linux-gnu |powerpc64le-linux-gnu |hppa-linux-gnu |powerpc64-linux-gnu ||hppa-linux-gnu Host|powerpc64le-linux-gnu |powerpc64le-linux-gnu |hppa-linux-gnu |powerpc64-linux-gnu ||hppa-linux-gnu CC||bergner at gcc dot gnu.org, ||segher at gcc dot gnu.org --- Comment #2 from seurer at gcc dot gnu.org --- Also occurs on powerpc64 big endian.
[Bug testsuite/107073] New test case gcc.dg/tree-ssa/gen-vect-34.c from r13-2333-gca8f4e8af14869 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107073 seurer at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from seurer at gcc dot gnu.org --- This is a duplicate of one I tracked down on little endian. *** This bug has been marked as a duplicate of bug 106806 ***
[Bug testsuite/106806] [13 regression] gcc.dg/tree-ssa/gen-vect-34.c fails after r13-2333-gca8f4e8af14869
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106806 --- Comment #1 from seurer at gcc dot gnu.org --- *** Bug 107073 has been marked as a duplicate of this bug. ***
[Bug testsuite/107073] New test case gcc.dg/tree-ssa/gen-vect-34.c from r13-2333-gca8f4e8af14869 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107073 seurer at gcc dot gnu.org changed: What|Removed |Added CC||bergner at gcc dot gnu.org, ||segher at gcc dot gnu.org Build|powerpc64-linux-gnu |powerpc64-linux-gnu, ||powerpc64le-linux-gnu Host|powerpc64-linux-gnu |powerpc64-linux-gnu, ||powerpc64le-linux-gnu Summary|New test case |New test case |gcc.dg/tree-ssa/gen-vect-34 |gcc.dg/tree-ssa/gen-vect-34 |.c fails|.c from ||r13-2333-gca8f4e8af14869 ||fails Target|powerpc64-linux-gnu |powerpc64-linux-gnu, ||powerpc64le-linux-gnu --- Comment #1 from seurer at gcc dot gnu.org --- Correction: It also fails on powerpc64 LE in the same way.
[Bug analyzer/107345] - -Wanayzer-null-dereference false positive with giving weird path infomation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107345 --- Comment #5 from Geoffrey --- (In reply to David Malcolm from comment #3) > Fixed on trunk for GCC 13 by the above patch. > > Keeping open for backporting to GCC 12. That is really great! Thanks a lot!
[Bug analyzer/107345] - -Wanayzer-null-dereference false positive with giving weird path infomation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107345 --- Comment #4 from Geoffrey --- (In reply to David Malcolm from comment #3) > Fixed on trunk for GCC 13 by the above patch. > > Keeping open for backporting to GCC 12. That is really great! Thanks a lot!
[Bug target/107172] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172 --- Comment #48 from H.J. Lu --- (In reply to Roger Sayle from comment #47) > I really don't believe that using UNSPEC here is the correct way to go, but > it appears to be the (only?) approach that Segher is prepared to approve. > Hohum. I wish we could avoid UNSPEC.
[Bug c++/107450] GCC accepts invalid program involving multiple template parameter packs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107450 --- Comment #1 from Jason Liam --- Also if we remove one of the template parameter(say T3) then msvc starts compiling this code as well. Demo: https://godbolt.org/z/qacMzoT3q Additionally, this current bug is most probably a duplicate of: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69623
[Bug libstdc++/107376] regex executor requires allocator to be default constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107376 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |13.0 --- Comment #3 from Jonathan Wakely --- Fixed for GCC 13. Might be worth backporting too.
[Bug libstdc++/107376] regex executor requires allocator to be default constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107376 --- Comment #2 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:988dd22ec6665117e8587389ac85389f1c321c45 commit r13-3548-g988dd22ec6665117e8587389ac85389f1c321c45 Author: Jonathan Wakely Date: Tue Oct 25 13:03:12 2022 +0100 libstdc++: Fix allocator propagation in regex algorithms [PR107376] The PR points out that we assume the match_results allocator is default constuctible, which might not be true. We also have a related issue with unwanted propagation from an object that might have an unequal allocator. Ideally we use the same allocator type for _State_info::_M_match_queue but that would be an ABI change now. We should investigate if that can be done without breaking anything, which might be possible because the _Executor object is short-lived and never leaks out of the regex_match, regex_search, and regex_replace algorithms. If we change the mangled name for _Executor then there would be no ODR violations when mixing old and new definitions. This commit does not attempt that. libstdc++-v3/ChangeLog: PR libstdc++/107376 * include/bits/regex_executor.h (_Executor::_Executor): Use same allocator for _M_cur_results and _M_results. * include/bits/regex_executor.tcc (_Executor::_M_main_dispatch): Prevent possibly incorrect allocator propagating to _M_cur_results. * testsuite/28_regex/algorithms/regex_match/107376.cc: New test.
[Bug c++/107439] use of static member function in requires-expression depends on declaration order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107439
--- Comment #2 from Patrick Palka ---
So the question is if in C++20 mode we're allowed to reject ahead of time a
call to an unknown template-id with dependent template arguments and no
function arguments (as in the original testcase):
template
void f() {
g(); // OK? gcc rejects, clang/msvc accept
}
[Bug middle-end/107436] Is -fsignaling-nans still experimental?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107436 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- (In reply to Florian Schanda from comment #5) > Richard, if I may rephrase your statement (for clarity), you're saying: > > > Under your assumptions, -fsignaling-nans should work. There are no known > > bugs > > in this setup, but if you find something please report it. > > Is that accurate? No. See the See Also bugs referenced in this bug.
[Bug middle-end/107411] trivial-auto-var-init=zero invalid uninitialized variable warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411 qinzhao at gcc dot gnu.org changed: What|Removed |Added CC||qinzhao at gcc dot gnu.org --- Comment #3 from qinzhao at gcc dot gnu.org --- (In reply to Richard Biener from comment #2) > > The gimplifier instead of > > _1 = t (); > D.2389 = _1; > e = > _2 = *e; > f (_2); > > produces > > _1 = .DEFERRED_INIT (4, 2, &"D.2389"[0]); > D.2389 = _1; > e = .DEFERRED_INIT (8, 2, &"e"[0]); > _2 = t (); > D.2389 = _2; > e = > _3 = *e; > f (_3); > > which is odd and sub-optimal at least. Doing such things makes us rely > on DSE to elide the uninit "inits". Looks like that "_1 = t ()" was not treated as an initializer, therefore "_1" was identified as an uninitialized var. "e = " has the same issue. should "_1 = t ()" be treated as an initializer to _1?
[Bug tree-optimization/107346] [13 Regression] gnat.dg/loop_optimization23_pkg.ad failure afer r13-3413-ge10ca9544632db
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107346 --- Comment #10 from CVS Commits --- The master branch has been updated by Andre Simoes Dias Vieira : https://gcc.gnu.org/g:95decac3ce8c8c7c5302cd6fac005a10463de165 commit r13-3547-g95decac3ce8c8c7c5302cd6fac005a10463de165 Author: Andre Vieira Date: Fri Oct 28 15:05:11 2022 +0100 vect: Reject non-byte offsets for gather/scatters [PR107346] The ada failure reported in the PR was being caused by vect_check_gather_scatter failing to deal with bit offsets that weren't multiples of BITS_PER_UNIT. This patch makes vect_check_gather_scatter reject memory accesses with such offsets. gcc/ChangeLog: PR tree-optimization/107346 * tree-vect-data-refs.cc (vect_check_gather_scatter): Reject offsets that aren't multiples of BITS_PER_UNIT.
[Bug c++/107439] use of static member function in requires-expression depends on declaration order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107439
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #1 from Patrick Palka ---
> This seems inconsistent, as member functions are normally expected to be
> usable anywhere within the class definition.
IIUC associated constraints are part of the function signature and thus aren't
late parsed like the function body is, so later-declared members aren't
generally usable in a constraint.
Interestingly, if we add a dummy argument to 'check' then we accept the call
(and treat it as an ADL-enabled call to an unknown function template where
unqualified lookup found nothing):
struct A
{
template requires (check(0))
auto func(T) { }
template
static consteval bool check(0) { return true; }
};
But if we then try to actually use func, its constraint will always fail due to
'check' not being visible at the point of use (since associated constraints
aren't late-parsed):
int main() {
A a;
a.func(0); // error: ‘check’ was not declared in this scope, and no
declarations were found by argument-dependent lookup at the point of
instantiation
}
This behavior (for the modified testcase) is correct AFAICT (Clang behaves the
same).
[Bug tree-optimization/107407] [12 Regression] Wrong code at -Os on x86_64-linux-gnu since r12-383-g32955416d8040b1f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107407 Richard Biener changed: What|Removed |Added Known to fail||12.2.0 Summary|[12/13 Regression] Wrong|[12 Regression] Wrong code |code at -Os on |at -Os on x86_64-linux-gnu |x86_64-linux-gnu since |since |r12-383-g32955416d8040b1f |r12-383-g32955416d8040b1f Known to work||13.0 --- Comment #5 from Richard Biener --- Fixed on trunk sofar.
[Bug tree-optimization/107407] [12/13 Regression] Wrong code at -Os on x86_64-linux-gnu since r12-383-g32955416d8040b1f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107407
--- Comment #4 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:031a400e49d8db156c43f9ec0b21ab0c2aee8c6d
commit r13-3546-g031a400e49d8db156c43f9ec0b21ab0c2aee8c6d
Author: Richard Biener
Date: Fri Oct 28 15:03:49 2022 +0200
tree-optimization/107407 - wrong code with DSE
So what happens is that we elide processing of this check with
/* In addition to kills we can remove defs whose only use
is another def in defs. That can only ever be PHIs of which
we track two for simplicity reasons, the first and last in
{first,last}_phi_def (we fail for multiple PHIs anyways).
We can also ignore defs that feed only into
already visited PHIs. */
else if (single_imm_use (vdef, _p, _stmt)
&& (use_stmt == first_phi_def
|| use_stmt == last_phi_def
|| (gimple_code (use_stmt) == GIMPLE_PHI
&& bitmap_bit_p (visited,
SSA_NAME_VERSION
(PHI_RESULT (use_stmt))
where we have the last PHI being the outer loop virtual PHI and the first
PHI being the loop exit PHI of the outer loop and we've already processed
the single immediate use of the outer loop PHI, the inner loop PHI. But
we still have to perform the above check!
It's easiest to perform the check when we visit the PHI node instead of
delaying it to the actual processing loop.
PR tree-optimization/107407
* tree-ssa-dse.cc (dse_classify_store): Perform backedge
varying index check when collecting PHI uses rather than
after optimizing processing of the candidate defs.
* gcc.dg/torture/pr107407.c: New testcase.
[Bug c++/107450] New: GCC accepts invalid program involving multiple template parameter packs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107450
Bug ID: 107450
Summary: GCC accepts invalid program involving multiple
template parameter packs
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jlame646 at gmail dot com
Target Milestone: ---
The following invalid program is accepted by gcc and clang but rejected by
msvc:
Demo: https://godbolt.org/z/Esbq4qK94
```
template
void foo(T1&&...args1, T2&&... args2, T3&&... args3) {
std::cout << "args1:\n", ((std::cout << args1 << " "), ...);
std::cout << "args2:\n", ((std::cout << args2 << " "), ...);
std::cout << "args3:\n", ((std::cout << args3 << " "), ...);
}
int main(int argc, char** argv)
{
foo(1,2,3,4,5,6); //gcc and clang compiles this while msvc correctly
rejects this
}
```
[Bug tree-optimization/107435] [13 Regression] ice in build_vector_from_val, at tree.cc:2125
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107435 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Richard Biener --- Fixed.
[Bug tree-optimization/107449] New: CD-DCE fails to eliminate abnormal incoming edges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107449
Bug ID: 107449
Summary: CD-DCE fails to eliminate abnormal incoming edges
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-checking, ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
CC: asolokha at gmx dot com
Depends on: 107447
Target Milestone: ---
+++ This bug was initially created as a clone of Bug #107447 +++
int n;
void
bar (int, int);
__attribute__ ((noinline, returns_twice)) int
zero (void)
{
return 0;
}
void
foo (void)
{
(void) zero ();
n = 0;
for (;;)
bar (zero (), n);
}
With this testcase GCC fails to eliminate the abnormal edges into the
first zero () call which is elided by CD-DCE.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107447
[Bug 107447] [13 Regression] ICE: verify_flow_info failed (error: returns_twice
call is not first in basic block 2)
[Bug tree-optimization/107447] [13 Regression] ICE: verify_flow_info failed (error: returns_twice call is not first in basic block 2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107447 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug tree-optimization/107447] [13 Regression] ICE: verify_flow_info failed (error: returns_twice call is not first in basic block 2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107447 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:1add3635563b39e3c0e9bed4930d11b3f605fdd3 commit r13-3545-g1add3635563b39e3c0e9bed4930d11b3f605fdd3 Author: Richard Biener Date: Fri Oct 28 14:20:36 2022 +0200 tree-optimization/107447 - avoid hoisting returns-twice calls in LIM The following makes sure to not hoist returns-twice calls in LIM since we have no way to move the abnormal edge associated with it and we are prone having stray abnormal edges in the IL which will then cause IL verification failures even when the actual call does not return twice. PR tree-optimization/107447 * tree-ssa-loop-im.cc (determine_max_movement): Do not hoist returns-twice calls. * gcc.dg/torture/pr107447.c: New testcase.
[Bug tree-optimization/107435] [13 Regression] ice in build_vector_from_val, at tree.cc:2125
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107435 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:084128583212bd64308f50c2ab5f4c03be40e48c commit r13-3544-g084128583212bd64308f50c2ab5f4c03be40e48c Author: Richard Biener Date: Fri Oct 28 13:50:57 2022 +0200 tree-optimization/107435 - ICE with recurrence vectorization This implements the missed conversion from pointer to integer. PR tree-optimization/107435 * tree-vect-loop.cc (vectorizable_recurr): Convert initial value to vector component type. * gcc.dg/torture/pr107435.c: New testcase.
[Bug tree-optimization/107407] [12/13 Regression] Wrong code at -Os on x86_64-linux-gnu since r12-383-g32955416d8040b1f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107407
--- Comment #3 from Richard Biener ---
Deleted dead store: MEM [(int *)][_6] = 3;
Further reduced testcase, we mistreat SSA name indexes with must aliases.
We do have
/* If we visit this PHI by following a backedge then we have to
make sure ref->ref only refers to SSA names that are invariant
with respect to the loop represented by this PHI node. */
if (dominated_by_p (CDI_DOMINATORS, gimple_bb (stmt),
gimple_bb (temp))
&& !for_each_index (ref->ref ? >ref : >base,
check_name, gimple_bb (temp)))
return DSE_STORE_LIVE;
that is supposed to catch this but somehow it doesn't trigger here.
int *a;
int c[4];
int d;
static int
f(char k, int j)
{
for (; k <= 3; k++)
{
a = [k];
for (; d <= 1; d++)
*a = 3;
}
*a = 0;
}
int main()
{
int i;
f(0, 0);
if (c[0] != 3)
__builtin_abort ();
}
So what happens is that we elide processing of this check with
/* In addition to kills we can remove defs whose only use
is another def in defs. That can only ever be PHIs of which
we track two for simplicity reasons, the first and last in
{first,last}_phi_def (we fail for multiple PHIs anyways).
We can also ignore defs that feed only into
already visited PHIs. */
else if (single_imm_use (vdef, _p, _stmt)
&& (use_stmt == first_phi_def
|| use_stmt == last_phi_def
|| (gimple_code (use_stmt) == GIMPLE_PHI
&& bitmap_bit_p (visited,
SSA_NAME_VERSION
(PHI_RESULT (use_stmt))
where we have the last PHI being the outer loop virtual PHI and the first
PHI being the loop exit PHI of the outer loop and we've already processed
the single immediate use of the outer loop PHI, the inner loop PHI. But
we still have to perform the above check!
It's easiest to perform the check when we visit the PHI node instead of
delaying it to the actual processing loop.
[Bug tree-optimization/107447] [13 Regression] ICE: verify_flow_info failed (error: returns_twice call is not first in basic block 2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107447 --- Comment #2 from Richard Biener --- Btw, there's also a stray incoming abnormal edge into bb2 here (as seen in other bugs I've meanwhile fixed). We've elided a call to zero() there but failed to eliminate the incoming abnormal edge. CDDCE1 does this.
[Bug tree-optimization/107447] [13 Regression] ICE: verify_flow_info failed (error: returns_twice call is not first in basic block 2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107447 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Last reconfirmed||2022-10-28 Priority|P3 |P1 Status|UNCONFIRMED |ASSIGNED Keywords||ice-checking Ever confirmed|0 |1 Target Milestone|--- |13.0 --- Comment #1 from Richard Biener --- Confirmed. Let me fix this. Note we are moving an entry to an irreducible sub-region of the loop here, so doing this will create an outer loop and make the inner loop have multiple latches. All this is likely not worth handling (code-gen wise it's simple to fix, but I'll look for the fallout). The checking is new, thus a "regression"
[Bug middle-end/107443] [10/11/12/13 Regression] Removing switch with __builtin_unreachable causes missed optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107443 Richard Biener changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- I think we simply "optimize" the switch instead of, like for the if, preserving the range asserting side-effect until some point in the compilation. Ideally switch conversion would turn the switch side-effect into a single if. But I also think the testcase is somewhat artificial so I wonder if we should worry here at all ...
[Bug middle-end/107436] Is -fsignaling-nans still experimental?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107436 --- Comment #5 from Florian Schanda --- Richard, if I may rephrase your statement (for clarity), you're saying: > Under your assumptions, -fsignaling-nans should work. There are no known bugs > in this setup, but if you find something please report it. Is that accurate? If yes, then this is something we could live with :)
[Bug middle-end/107436] Is -fsignaling-nans still experimental?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107436 --- Comment #4 from Richard Biener --- The question is what the expectations are. I think that all issues would be considered bugs (see the list of referenced bugs). Can you evaluate it according to your needs and file bugreports for issues not covered?
[Bug tree-optimization/107435] [13 Regression] ice in build_vector_from_val, at tree.cc:2125
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107435 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-10-28 Priority|P3 |P1 --- Comment #2 from Richard Biener --- Mine. Missing a conversion of the scalar pointer to the vector component type.
[Bug target/107432] __builtin_convertvector generates inefficient code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107432
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org,
||rsandifo at gcc dot gnu.org
Target|X86_64 |x86_64-*-*
Last reconfirmed||2022-10-28
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Version|unknown |13.0
--- Comment #8 from Richard Biener ---
(In reply to Hongtao.liu from comment #6)
> > Guess expand_vector_conversion can be optimized.
>
> if (INTEGRAL_TYPE_P (TREE_TYPE (ret_type))
> && SCALAR_FLOAT_TYPE_P (TREE_TYPE (arg_type)))
> code = FIX_TRUNC_EXPR;
> else if (INTEGRAL_TYPE_P (TREE_TYPE (arg_type))
> && SCALAR_FLOAT_TYPE_P (TREE_TYPE (ret_type)))
> code = FLOAT_EXPR;
>
> It only supports floatmn2/fix_truncmn2 for float <-> integer.
>
> But we can also supports extendmn2/zero_extendmn2/truncmn2 for float <->
> float, integer <-> integer.
>
> Or are there any concerns and VEC_PACK_TRUNC_EXPR,
> VEC_PACK_FIX_TRUNC_EXPR,VEC_PACK_FLOAT_EXPR are used on purpose?
I think we do support FIX_TRUNC_EXPR or FLOAT_EXPR for float <-> int
conversion of vectors like we now support {CONVERT,NOP}_EXPR for
just widening/shortening. At least the GIMPLE verifier allows that.
The obtabs would be [us]fix and [us]float, not sure if aarch64 makes use
of those for vector modes or if Richard extended the vectorizer to
consider those (I only remember int <-> int conversions).
So I think if x86_64 can do float <-> int for vectors implementing
[us]fix/[us]float would be the way to go (and of course then make use
of those in lowering/vectorization).
[Bug fortran/107426] [12/13 Regression] ICE in gfc_compare_derived_types, at fortran/interface.cc:636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107426 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.3 Priority|P3 |P4
[Bug fortran/107425] [12/13 Regression] ICE in gimplify_var_or_parm_decl, at gimplify.cc:3060 since r12-6780-gd2ad748eeef0dd26
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107425 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |12.3
[Bug fortran/107424] [13 Regression] ICE in gfc_trans_omp_do, at fortran/trans-openmp.cc:5397
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107424 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |13.0
[Bug c++/107422] [12/13 Regression] ICE in lvalue_kind, at cp/tree.cc:293 since r12-298-g58a92b789a77cdad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107422 Richard Biener changed: What|Removed |Added Priority|P5 |P4 Target Milestone|--- |12.3 Keywords||error-recovery
[Bug middle-end/107411] trivial-auto-var-init=zero invalid uninitialized variable warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411
Richard Biener changed:
What|Removed |Added
Blocks||24639
CC||qing.zhao at oracle dot com,
||rguenth at gcc dot gnu.org
--- Comment #2 from Richard Biener ---
(In reply to Andrew Pinski from comment #1)
> Confirmed. reduced testcase:
> int t();
> void f(int);
>
> void j()
> {
> const int& e = t();
> f(e);
> }
>
> Someone who understands the uininit pass should look into this but the IR at
> that point we get is (with -fno-exceptions due to extra clobbers otherwise
> which don't make a difference):
> _1 = .DEFERRED_INIT (4, 2, &"D.2374"[0]);
> D.2374 = _1;
> e_6 = .DEFERRED_INIT (8, 2, &"e"[0]);
> _2 = t ();
> D.2374 = _2;
> e_9 =
> _3 = *e_9;
> f (_3);
> D.2374 ={v} {CLOBBER(eol)};
>
> There is no read from D.2374 in the call to t at all and then we do a full
> write after the call.
We diagnose the
D.2374 = _1;
store which uses uninitialized _1. The FE emits
<;
<;
note that without -ftrivial-auto-var-init=zero we see
:
_6 = t ();
:
_1 = _6;
D.2389 = _1;
e_8 =
_2 = *e_8;
f (_2);
:
D.2389 ={v} {CLOBBER(eol)};
return;
:
:
D.2389 ={v} {CLOBBER(eol)};
resx 1
while with the flag we have
:
_1 = .DEFERRED_INIT (4, 2, &"D.2389"[0]);
D.2389 = _1;
e_7 = .DEFERRED_INIT (8, 2, &"e"[0]);
_9 = t ();
:
_2 = _9;
D.2389 = _2;
e_11 =
_3 = *e_11;
f (_3);
:
D.2389 ={v} {CLOBBER(eol)};
return;
:
:
D.2389 ={v} {CLOBBER(eol)};
resx 1
The gimplifier instead of
_1 = t ();
D.2389 = _1;
e =
_2 = *e;
f (_2);
produces
_1 = .DEFERRED_INIT (4, 2, &"D.2389"[0]);
D.2389 = _1;
e = .DEFERRED_INIT (8, 2, &"e"[0]);
_2 = t ();
D.2389 = _2;
e =
_3 = *e;
f (_3);
which is odd and sub-optimal at least. Doing such things makes us rely
on DSE to elide the uninit "inits".
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues
[Bug c/107405] [13 Regression] enum change causing Linux kernel to fail to build due to Linux depending on old behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107405 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0
[Bug fortran/107397] [10/11/12/13 Regression] ICE in gfc_arith_plus, at fortran/arith.cc:654
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107397 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.5
[Bug analyzer/107396] [13 regression] new test case gcc.dg/analyzer/pipe-glibc.c in r13-3466-g792f039fc37faa fails with excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107396 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0
[Bug c/102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 --- Comment #29 from Alejandro Colomar --- Hi! On 10/28/22 12:51, rguenther at suse dot de wrote: > Quite likely yes (OTOH __BIGGEST_ALIGNMENT__ changed as well). That > also means BITINT_MAXWIDTH should eventually be decided by the ABI > groups? > > I also can hardly see any use for very big N other than "oh, cool". I > mean, we don't have _Float(N) either for N == 65000 even though what > would be cool as well. I do have a use. Okay, I don't need 8M bits, but 1k is something that would help me. Basically, it's a transparent bignum library, for which I can use most standard C features. BTW, it would also be nice if stdc_count_ones(3) would be implemented to support very wide _BitInt()s as an extension (C23 only guarantees support for _BitInt()s that match a standard or extended type). I have some program that works with matrices of 512x512, represented as arrays of 512 members of uint64_t[8], and it popcounts rows, which now means looping over an array of uint64_t[8] and using the builtin popcount. And I'm not sure if I could still optimize it a little bit more. If I could just call the type-generic stdc_count_ones(), and know that the implementation has written a quite optimal loop, that would be great (both for simplicity and performance). Cheers, Alex > >> Anyway, I'm afraid we probably don't have enough time to implement this >> properly in stage1, so might need to target GCC 14 with it. Unless somebody >> spends on it >> the remaining 2 weeks full time. > > It's absolutely a GCC 14 task given the ABI and library issue. >
[Bug c/102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 --- Comment #28 from rguenther at suse dot de --- On Fri, 28 Oct 2022, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 > > --- Comment #27 from Jakub Jelinek --- > (In reply to Richard Biener from comment #26) > > Does the C standard limit the number of bits? Does it allow > > implementation defined limits? > > The latter. limits.h defines BITINT_MAXWIDTH, which must be at least as large > as number of bits in unsigned long long. AFAIK LLVM plans 8388608 maximum > (but > due to the missing library support uses 128 as maximum right now). > > > Constants are tricky indeed but I suppose there's no way to write a > > 199 bit integer constant in source? We can always resort to constants > > of the intfast_t[n] representation (aka a CTOR). > > One can specify even very large constants in the source. > 123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789uwb > will be _BitInt with the minimum number of bits to store the above unsigned > constant. > > > That said, if C allows us to limit to 128bits then let's do that for now. > > 32bit targets will still see all the complication when we give that a stab. > > I'm afraid once we define BITINT_MAXWIDTH, it will become part of the ABI, so > we can't increase it afterwards. Quite likely yes (OTOH __BIGGEST_ALIGNMENT__ changed as well). That also means BITINT_MAXWIDTH should eventually be decided by the ABI groups? I also can hardly see any use for very big N other than "oh, cool". I mean, we don't have _Float(N) either for N == 65000 even though what would be cool as well. > Anyway, I'm afraid we probably don't have enough time to implement this > properly in stage1, so might need to target GCC 14 with it. Unless somebody > spends on it > the remaining 2 weeks full time. It's absolutely a GCC 14 task given the ABI and library issue.
[Bug tree-optimization/107413] Perf loss ~14% on 519.lbm_r SPEC cpu2017 benchmark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107413 --- Comment #6 from Rama Malladi --- The compilation options were: -Ofast -mcpu=native -flto
[Bug tree-optimization/107413] Perf loss ~14% on 519.lbm_r SPEC cpu2017 benchmark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107413 --- Comment #5 from Rama Malladi --- (In reply to Wilco from comment #2) > That's interesting - if the reassociation pass has become a bit smarter in > the last 5 years, we might no longer need this workaround. What is the > effect on the overall SPECFP score? Did you try other values like > fp_reassoc_width = 2 or 3? Here is SPEC cpu2017 fprate perf data for 1-copy rate run. The runs were run on a c7g.16xlarge AWS cloud instance. Benchmark w fix -- 503.bwaves_r0.98 507.cactuBSSN_r NA 508.namd_r 0.97 510.parest_rNA 511.povray_r1.01 519.lbm_r 1.16 521.wrf_r 1.00 526.blender_r NA 527.cam4_r 1.00 538.imagick_r 0.99 544.nab_r 1.00 549.fotonik3d_r NA 554.roms_r 1.00 geomean 1.01 The baseline was gcc version 12.2.0 (GCC) compiler. Fix was revert of code change in commit: b5b33e113434be909e8a6d7b93824196fb6925c0. So, looks like we aren't impacted much with this commit revert. I haven't yet tried fp_reassoc_width. Will try shortly.
[Bug c/102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 --- Comment #27 from Jakub Jelinek --- (In reply to Richard Biener from comment #26) > Does the C standard limit the number of bits? Does it allow > implementation defined limits? The latter. limits.h defines BITINT_MAXWIDTH, which must be at least as large as number of bits in unsigned long long. AFAIK LLVM plans 8388608 maximum (but due to the missing library support uses 128 as maximum right now). > Constants are tricky indeed but I suppose there's no way to write a > 199 bit integer constant in source? We can always resort to constants > of the intfast_t[n] representation (aka a CTOR). One can specify even very large constants in the source. 123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789uwb will be _BitInt with the minimum number of bits to store the above unsigned constant. > That said, if C allows us to limit to 128bits then let's do that for now. > 32bit targets will still see all the complication when we give that a stab. I'm afraid once we define BITINT_MAXWIDTH, it will become part of the ABI, so we can't increase it afterwards. Anyway, I'm afraid we probably don't have enough time to implement this properly in stage1, so might need to target GCC 14 with it. Unless somebody spends on it the remaining 2 weeks full time.
[Bug tree-optimization/107407] [12/13 Regression] Wrong code at -Os on x86_64-linux-gnu since r12-383-g32955416d8040b1f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107407 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Priority|P1 |P2 Status|NEW |ASSIGNED --- Comment #2 from Richard Biener --- I will have a look.
[Bug c/102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 --- Comment #26 from Richard Biener --- Some random comments. I wouldn't go with a new tree code, given semantics are INTEGER_TYPE it should be an INTEGER_TYPE. The TYPE_PRECISION issue is real - we have 16 spare bits in tree_type_common so we could possibly afford to make it 16 bits. Does the C standard limit the number of bits? Does it allow implementation defined limits? As of SSA representation and "lowering" this feels much like Middle-End Array Expressions in the end. I agree that first and foremost we should have the types as registers but then we can simply lower early to a representation supported by the target? AKA make _BitInt(199) intfast_t[n] with appropriate 'n' and lower all accesses, doing arithmetic either via builtins or internal functions on the whole object. Constants are tricky indeed but I suppose there's no way to write a 199 bit integer constant in source? We can always resort to constants of the intfast_t[n] representation (aka a CTOR). That said, if C allows us to limit to 128bits then let's do that for now. 32bit targets will still see all the complication when we give that a stab.
[Bug middle-end/107389] Always propagate __builtin_assume_aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107389 --- Comment #5 from Richard Biener --- Created attachment 53784 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53784=edit prototype This implements an -O0 fold-builtins pass. I've disabled some but not all "optimizations" and instead of just throwing away __builtin_assume_aligned I'm processing it at -O0 (the machinery from CCP relies on a lattice, with optimization we should at least merge with the alignment info on the LHS). On s390 I then see foo: .LFB0: .cfi_startproc stmg%r11,%r15,88(%r15) .cfi_offset 11, -72 .cfi_offset 12, -64 .cfi_offset 13, -56 .cfi_offset 14, -48 .cfi_offset 15, -40 aghi%r15,-176 .cfi_def_cfa_offset 336 lgr %r11,%r15 .cfi_def_cfa_register 11 stg %r2,168(%r11) stg %r3,160(%r11) lg %r1,160(%r11) lpq %r2,0(%r1) lg %r1,168(%r11) stmg%r2,%r3,0(%r1) lg %r2,168(%r11) lmg %r11,%r15,264(%r11) .cfi_restore 15 .cfi_restore 14 .cfi_restore 13 .cfi_restore 12 .cfi_restore 11 .cfi_def_cfa 15, 160 br %r14 .cfi_endproc specifically I did not disable __atomic_add_fetch_* optimizations to .ATOMIC_ADD_FETCH_CMP_0 and friends and also kept optimizing stack_save/restore.
[Bug middle-end/107436] Is -fsignaling-nans still experimental?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107436 --- Comment #3 from Florian Schanda --- Maybe some additional constraints under which we operate can help: - we never change our rounding mode away from RNE - we never disable support for subnormals in any way - we only ever use float32 and float64, we do not use the intel extended precision format Under those constraints, will -fsignaling-nans work?
[Bug middle-end/107389] Always propagate __builtin_assume_aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107389 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org
[Bug target/107172] [13 Regression] wrong code with "-O1 -ftree-vrp" on x86_64-linux-gnu since r13-1268-g8c99e307b20c502e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107172 --- Comment #47 from Roger Sayle --- I really don't believe that using UNSPEC here is the correct way to go, but it appears to be the (only?) approach that Segher is prepared to approve. Hohum.
[Bug rtl-optimization/107057] [10/11/12/13 Regression] ICE in extract_constrain_insn, at recog.cc:2692
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107057 --- Comment #9 from Uroš Bizjak --- (In reply to Hongtao.liu from comment #7) > And it looks like the pattern is wrongly defined since from [1]. > > --cut begin > Matching constraints are used in these circumstances. More precisely, the > two operands that match must include one input-only operand and one > output-only operand. Moreover, the digit must be a smaller number than the > number of the operand that uses it in the constraint. > cut end-- > > (define_insn "vec_concatv2df" > [(set (match_operand:V2DF 0 "register_operand" "=x,x,v,x,v,x,x, v,x,x") > (vec_concat:V2DF > (match_operand:DF 1 "nonimmediate_operand" " 0,x,v,m,m,0,x,vm,0,0") > (match_operand:DF 2 "nonimm_or_0_operand" " x,x,v,1,1,m,m, C,x,m")))] > > > For alternatvie 1, the two operands are both input only. > > [1] > https://gcc.gnu.org/onlinedocs/gccint/Simple-Constraints.html#Simple- > Constraints Perhaps an error should be emitted for this situation?
[Bug middle-end/90115] OpenACC: predetermined private levels for variables declared in blocks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90115 --- Comment #19 from CVS Commits --- The releases/gcc-12 branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:9b116c51a451995f1bae8fdac0748fcf3f06aafe commit r12-8874-g9b116c51a451995f1bae8fdac0748fcf3f06aafe Author: Julian Brown Date: Wed Oct 12 20:44:57 2022 + OpenACC: Don't gang-privatize artificial variables [PR90115] This patch prevents compiler-generated artificial variables from being treated as privatization candidates for OpenACC. The rationale is that e.g. "gang-private" variables actually must be shared by each worker and vector spawned within a particular gang, but that sharing is not necessary for any compiler-generated variable (at least at present, but no such need is anticipated either). Variables on the stack (and machine registers) are already private per-"thread" (gang, worker and/or vector), and that's fine for artificial variables. We're restricting this to blocks, as we still need to understand what it means for a 'DECL_ARTIFICIAL' to appear in a 'private' clause. Several tests need their scan output patterns adjusted to compensate. 2022-10-14 Julian Brown PR middle-end/90115 gcc/ * omp-low.cc (oacc_privatization_candidate_p): Artificial vars are not privatization candidates. libgomp/ * testsuite/libgomp.oacc-fortran/declare-1.f90: Adjust scan output. * testsuite/libgomp.oacc-fortran/host_data-5.F90: Likewise. * testsuite/libgomp.oacc-fortran/if-1.f90: Likewise. * testsuite/libgomp.oacc-fortran/print-1.f90: Likewise. * testsuite/libgomp.oacc-fortran/privatized-ref-2.f90: Likewise. Co-authored-by: Thomas Schwinge (cherry picked from commit 11e811d8e2f63667f60f73731bb934273f5882b8)
[Bug middle-end/90115] OpenACC: predetermined private levels for variables declared in blocks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90115 --- Comment #18 from CVS Commits --- The master branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:11e811d8e2f63667f60f73731bb934273f5882b8 commit r13-3541-g11e811d8e2f63667f60f73731bb934273f5882b8 Author: Julian Brown Date: Wed Oct 12 20:44:57 2022 + OpenACC: Don't gang-privatize artificial variables [PR90115] This patch prevents compiler-generated artificial variables from being treated as privatization candidates for OpenACC. The rationale is that e.g. "gang-private" variables actually must be shared by each worker and vector spawned within a particular gang, but that sharing is not necessary for any compiler-generated variable (at least at present, but no such need is anticipated either). Variables on the stack (and machine registers) are already private per-"thread" (gang, worker and/or vector), and that's fine for artificial variables. We're restricting this to blocks, as we still need to understand what it means for a 'DECL_ARTIFICIAL' to appear in a 'private' clause. Several tests need their scan output patterns adjusted to compensate. 2022-10-14 Julian Brown PR middle-end/90115 gcc/ * omp-low.cc (oacc_privatization_candidate_p): Artificial vars are not privatization candidates. libgomp/ * testsuite/libgomp.oacc-fortran/declare-1.f90: Adjust scan output. * testsuite/libgomp.oacc-fortran/host_data-5.F90: Likewise. * testsuite/libgomp.oacc-fortran/if-1.f90: Likewise. * testsuite/libgomp.oacc-fortran/print-1.f90: Likewise. * testsuite/libgomp.oacc-fortran/privatized-ref-2.f90: Likewise. Co-authored-by: Thomas Schwinge
[Bug middle-end/104069] -Werror=use-after-free false positive on elfutils-0.186
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069 --- Comment #26 from Sergei Trofimovich --- #c12 fixed elfutils case.
[Bug sanitizer/107298] Failure to compile code with std::optional and ASan/UBSan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107298 --- Comment #5 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:3f9c071324eff249b23a7531e447fc17d928 commit r13-3539-g3f9c071324eff249b23a7531e447fc17d928 Author: Martin Liska Date: Wed Oct 26 13:07:57 2022 +0200 docs: document sanitizers can trigger warnings PR sanitizer/107298 gcc/ChangeLog: * doc/invoke.texi: Document sanitizers can trigger warnings.
[Bug target/107432] __builtin_convertvector generates inefficient code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107432
--- Comment #7 from Hongtao.liu ---
(In reply to Hongtao.liu from comment #6)
> > Guess expand_vector_conversion can be optimized.
>
> if (INTEGRAL_TYPE_P (TREE_TYPE (ret_type))
> && SCALAR_FLOAT_TYPE_P (TREE_TYPE (arg_type)))
> code = FIX_TRUNC_EXPR;
> else if (INTEGRAL_TYPE_P (TREE_TYPE (arg_type))
> && SCALAR_FLOAT_TYPE_P (TREE_TYPE (ret_type)))
> code = FLOAT_EXPR;
>
> It only supports floatmn2/fix_truncmn2 for float <-> integer.
>
> But we can also supports extendmn2/zero_extendmn2/truncmn2 for float <->
> float, integer <-> integer.
>
> Or are there any concerns and VEC_PACK_TRUNC_EXPR,
> VEC_PACK_FIX_TRUNC_EXPR,VEC_PACK_FLOAT_EXPR are used on purpose?
May be we can add some gimple simplication in match.pd to hanlde
_4 = VEC_PACK_TRUNC_EXPR ;
_5 = BIT_FIELD_REF <_4, 128, 0>;
and
_4 = [vec_unpack_lo_expr] a_1(D);
_5 = [vec_unpack_hi_expr] a_1(D);
_2 = {_4, _5};
Since loop vectorizer may also create vec_unpack_lo_expr/vec_unpack_hi_expr.
[Bug c/107448] New: GCC no longer diagnoses missing input file with -MG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107448 Bug ID: 107448 Summary: GCC no longer diagnoses missing input file with -MG Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: boris at kolpackov dot net Target Milestone: --- With GCC 10 when trying to extract dependency information with -MG we get diagnostics if the input file does not exist: $ g++-10 -M -MG /tmp/no-such-file.cxx g++-10: error: /tmp/no-such-file.cxx: No such file or directory g++-10: fatal error: no input files compilation terminated. $ echo $? 1 In GCC 11 and 12 this diagnostics is gone: $ g++-11 -M -MG /tmp/no-such-file.cxx $ echo $? 1 $ g++-12 -M -MG /tmp/no-such-file.cxx $ echo $? 1
