[Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=07 Richard Biener changed: What|Removed |Added CC||10walls at gmail dot com --- Comment #5 from Richard Biener --- I'd say that config/i386/cygming.h:#define STACK_REALIGN_DEFAULT TARGET_SSE is a non-working "fix". The appropriate default would be -mincoming-stack-boundary=2. MIN_STACK_BOUNDARY should already be 4, so that leaves PREFERRED_STACK_BOUNDARY_DEFAULT is the way to go here. I also see /* It should be MIN_STACK_BOUNDARY. But we set it to 128 bits for both 32bit and 64bit, to support codes that need 128 bit stack alignment for SSE instructions, but can't realign the stack. */ #define PREFERRED_STACK_BOUNDARY_DEFAULT \ (TARGET_IAMCU ? MIN_STACK_BOUNDARY : 128) which suggests there might be problems with SSE anyway. So does the following work? diff --git a/gcc/config/i386/cygming.h b/gcc/config/i386/cygming.h index d539f8d0699..e8db548510b 100644 --- a/gcc/config/i386/cygming.h +++ b/gcc/config/i386/cygming.h @@ -31,10 +31,9 @@ along with GCC; see the file COPYING3. If not see #undef MAX_STACK_ALIGNMENT #define MAX_STACK_ALIGNMENT (TARGET_SEH ? 128 : MAX_OFILE_ALIGNMENT) -/* 32-bit Windows aligns the stack on a 4-byte boundary but SSE instructions - may require 16-byte alignment. */ -#undef STACK_REALIGN_DEFAULT -#define STACK_REALIGN_DEFAULT TARGET_SSE +/* 32-bit Windows aligns the stack on a 4-byte boundary. */ +#undef PREFERRED_STACK_BOUNDARY_DEFAULT +#define PREFERRED_STACK_BOUNDARY_DEFAULT (TARGET_64BIT ? 128 : 32) /* Support hooks for SEH. */ #undef TARGET_ASM_UNWIND_EMIT
[Bug tree-optimization/111108] (a|c) == (a|c) should be convert into (a&~c) == (a&~c) IFF ~c simplifies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=08 --- Comment #1 from Richard Biener --- Why not canonicalize to the form without ~ then? That also is simpler for non-constants? Thus (X | C) == (Y | C) is canonical.
[Bug bootstrap/111027] [11/12/13/14 Regression] `make install` touches the build directory; Install error "tmp-header-vars: Permission denied", build on NFS, improvement possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111027 --- Comment #5 from etienne_lorrain at yahoo dot fr --- Hello, full recompilation from source finished (your patch included), same setup with NFS without "no_root_squash" on /home/parallella/veg, installation goes further but stop at: $ echo parallella | sudo -S make install /bin/mkdir -p '/usr/local/lib/.' /bin/sh ./libtool --mode=install /usr/bin/install -c libcc1.la '/usr/local/lib/.' libtool: install: warning: relinking `libcc1.la' libtool: install: (cd /home/parallella/vega/gcc_build1/libcc1; /bin/sh /home/parallella/vega/gcc_build1/libcc1/libtool --tag CXX --mode=relink /home/parallella/vega/gcc_build1/./gcc/xg++ -B/home/parallella/vega/gcc_build1/./gcc/ -nostdinc++ -nostdinc++ -I/home/parallella/vega/gcc_build1/armv7l-unknown-linux-gnueabihf/libstdc++-v3/include/armv7l-unknown-linux-gnueabihf -I/home/parallella/vega/gcc_build1/armv7l-unknown-linux-gnueabihf/libstdc++-v3/include -I/home/parallella/vega/gcc-13.2.0/libstdc++-v3/libsupc++ -I/home/parallella/vega/gcc-13.2.0/libstdc++-v3/include/backward -I/home/parallella/vega/gcc-13.2.0/libstdc++-v3/testsuite/util -L/home/parallella/vega/gcc_build1/armv7l-unknown-linux-gnueabihf/libstdc++-v3/src -L/home/parallella/vega/gcc_build1/armv7l-unknown-linux-gnueabihf/libstdc++-v3/src/.libs -L/home/parallella/vega/gcc_build1/armv7l-unknown-linux-gnueabihf/libstdc++-v3/libsupc++/.libs -B/home/parallella/vega/gcc_build1/armv7l-unknown-linux-gnueabihf/libstdc++-v3/src/.libs -B/home/parallella/vega/gcc_build1/armv7l-unknown-linux-gnueabihf/libstdc++-v3/libsupc++/.libs -B/usr/local/armv7l-unknown-linux-gnueabihf/bin/ -B/usr/local/armv7l-unknown-linux-gnueabihf/lib/ -isystem /usr/local/armv7l-unknown-linux-gnueabihf/include -isystem /usr/local/armv7l-unknown-linux-gnueabihf/sys-include -W -Wall -fvisibility=hidden -g -O2 -D_GNU_SOURCE -module -export-symbols ../../gcc-13.2.0/libcc1/libcc1.sym -Xcompiler -static-libstdc++ -Xcompiler -static-libgcc -o libcc1.la -rpath /usr/local/lib/. findcomp.lo libcc1.lo libcp1.lo compiler.lo names.lo callbacks.lo connection.lo marshall.lo -Wc,../libiberty/pic/libiberty.a ) mv: cannot move 'libcc1.so.0.0.0' to 'libcc1.so.0.0.0U': Permission denied libtool: install: error: relink `libcc1.la' with the above command before installing it Makefile:497: recipe for target 'install-cc1libLTLIBRARIES' failed make[3]: *** [install-cc1libLTLIBRARIES] Error 1 make[3]: Leaving directory '/home/parallella/vega/gcc_build1/libcc1' Makefile:694: recipe for target 'install-am' failed make[2]: *** [install-am] Error 2 make[2]: Leaving directory '/home/parallella/vega/gcc_build1/libcc1' Makefile:20708: recipe for target 'install-libcc1' failed make[1]: *** [install-libcc1] Error 2 make[1]: Leaving directory '/home/parallella/vega/gcc_build1' Makefile:2632: recipe for target 'install' failed make: *** [install] Error 2 I am keeping the setup ready for more patch in case it is needed, if your have another change to try...
[Bug c++/111103] gcc accepts bad type syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=03 --- Comment #6 from Jonathan Wakely --- Let's move it to -fpermissive then kill it.
[Bug c++/80516] long, unsigned used with typedef names extension should either be removed or documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80516 Jonathan Wakely changed: What|Removed |Added Last reconfirmed|2017-04-25 00:00:00 |2023-8-23 --- Comment #8 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #3) > Maybe we can change it to an error by default, but allow it with > -fpermissive. I still think this is the right approach.
[Bug target/111112] New: RISC-V: Resulting more vsetvl instructions of vwadd + vadd but not vwadd + vwadd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12
Bug ID: 12
Summary: RISC-V: Resulting more vsetvl instructions of vwadd +
vadd but not vwadd + vwadd
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: lehua.ding at rivai dot ai
Target Milestone: ---
For GCC, first res = b[i] + c[i], than res += promoted_d
For Clang, first res = promoted_d + b[i], than res += c[i]
Resulting more vsetvl instructions when using GCC's method
since vwadd and vadd need different type.
https://godbolt.org/z/9vexWjccn
C Code:
void __attribute__ ((noipa))
f (SIGNEDNESS char *restrict a, SIGNEDNESS char *restrict b,
SIGNEDNESS char *restrict c, SIGNEDNESS char d)
{
int promoted_d = d;
for (int i = 0; i < 8; ++i)
/* Deliberate use of signed >>. */
a[i] = ( promoted_d + b[i] + c[i]) >> 2;
}
RISC-V GCC:
f:
vsetivlizero,8,e16,m1,ta,ma
vle8.v v4,0(a1)
vle8.v v3,0(a2)
vmv.v.x v2,a3
vsetvli zero,zero,e8,mf2,ta,ma
vwadd.vvv1,v4,v3
vsetvli zero,zero,e16,m1,ta,ma
vadd.vv v1,v1,v2
vsetvli zero,zero,e8,mf2,ta,ma
vnsra.wiv1,v1,2
vse8.v v1,0(a0)
ret
RISC-V Clang:
f: # @f
vsetivlizero, 8, e8, mf2, ta, ma
vle8.v v8, (a1)
vle8.v v9, (a2)
vwadd.vxv10, v8, a3
vwadd.wvv10, v10, v9
vnsrl.wiv8, v10, 2
vse8.v v8, (a0)
ret
[Bug tree-optimization/110940] [14 Regression] ICE at -O3 on x86_64-linux-gnu: in apply_scale, at profile-count.h:1180
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110940 --- Comment #2 from CVS Commits --- The master branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:7a2e232fa6e0ce2120dedcb340d683f6ac9b3f19 commit r14-3406-g7a2e232fa6e0ce2120dedcb340d683f6ac9b3f19 Author: Jan Hubicka Date: Wed Aug 23 11:14:53 2023 +0200 Add testcase for PR110940 gcc/testsuite/ChangeLog: PR middle-end/110940 * gcc.c-torture/compile/pr110940.c: New test.
[Bug c++/111113] New: Cannot define friend function of a local class in namespace scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13
Bug ID: 13
Summary: Cannot define friend function of a local class in
namespace scope
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fchelnokov at gmail dot com
Target Milestone: ---
This program defines friend function of a local class in namespace scope:
auto foo() {
struct A;
void bar(const A&);
struct A {
friend void bar(const A&);
};
bar(A{});
return A{};
}
using A = decltype(foo());
void bar(const A&) {}
Both Clang and MSVC permit it, but GCC prints weird errors:
:5:21: error: 'void bar(const foo()::A&)', declared using local type
'const foo()::A', is used but never defined [-fpermissive]
5 | friend void bar(const A&);
| ^~~
:5:21: error: 'void bar(const foo()::A&)' used but never defined
:12:6: warning: 'void bar(const A&)' defined but not used
Online demo: https://godbolt.org/z/Yqoeda94x
[Bug target/111114] New: RISC-V: False combine extend + vcond_mask when modify by vect_recog_over_widening_pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14
Bug ID: 14
Summary: RISC-V: False combine extend + vcond_mask when modify
by vect_recog_over_widening_pattern
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: lehua.ding at rivai dot ai
Target Milestone: ---
The vect_recog_over_widening_pattern in vect pass will change:
v2 = EXTEND (v1)
v3 = VEC_COND_EXPR (mask, v2, { 1, 1, ... })
to:
v2 = VEC_COND_EXPR (mask, v1, { 1, 1, ... })
v3 = EXTEND (v2)
when it is safe. This change looks like no gain for riscv and makes it
impossible to combine them into a MASK_EXTEND in combine pass.
https://godbolt.org/z/PWE4rzr7j
[Bug tree-optimization/111115] New: Failure to vectorize conditional grouped store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15
Bug ID: 15
Summary: Failure to vectorize conditional grouped store
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
void foo (float * __restrict x, int *flag)
{
for (int i = 0; i < 512; ++i)
{
if (flag[i])
{
float a = x[2*i+0] + 3.f;
float b = x[2*i+1] + 177.f;
x[2*i+0] = a;
x[2*i+1] = b;
}
}
}
fails to vectorize on x86_64 with -march=znver4 (it needs masked stores
enabled by tuning). This is because we do not support VMAT_CONTIGUOUS_PERMUTE
for either .MASK_LOAD nor .MASK_STORE. Simply enabling that shows we fail
to properly handle the mask part.
The proper solution is to handle them in SLP which they are not either.
[Bug target/111096] Frame pointer is not used even when -fomit-frame-pointer is specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111096 Richard Earnshaw changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #5 from Richard Earnshaw --- This was a deliberate design choice. Although the frame chain is not set up by code that omits the frame pointer, the chain of frames that are set up by other functions is still valid this way. This ensures that any code that does try to walk the frame chain will not crash. If we reused the frame pointer for other purposes, then any code trying to walk the frame chain (eg backtrace()) would encounter an invalid record and likely crash. With 31 main registers, the benefit from one additional one is not especially large.
[Bug libstdc++/110944] std::variant & optional GDB representation is too verbose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110944 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug target/94866] Failure to optimize pinsrq of 0 with index 1 into movq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94866 --- Comment #4 from Uroš Bizjak --- (In reply to Hongtao.liu from comment #3) > in x86 backend expand_vec_perm_1, we always tries vec_merge frist for > !one_operand_p, expand_vselect_vconcat is only tried when vec_merge failed > which means we'd better to use vec_merge instead of vec_select:vec_concat > when available in out backend pattern match. In fact, I tried to convert existing sse2_movq128 patterns to vec_merge, but the patch regressed: -FAIL: gcc.target/i386/sse2-pr94680-2.c scan-assembler movq -FAIL: gcc.target/i386/sse2-pr94680-2.c scan-assembler-not pxor -FAIL: gcc.target/i386/sse2-pr94680.c scan-assembler-not pxor -FAIL: gcc.target/i386/sse2-pr94680.c scan-assembler-times (?n)(?:mov|psrldq).*%xmm[0-9] 12 So, the compiler still expects vec_concat/vec_select patterns to be present.
[Bug target/94866] Failure to optimize pinsrq of 0 with index 1 into movq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94866 --- Comment #5 from Uroš Bizjak --- Created attachment 55778 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55778&action=edit Failing patch, for reference Patch that converts vec_concat/vec_select sse2_movq128 patterns to vec_merge.
[Bug fortran/111116] New: [OpenACC] Implicit mapping wrong for scalar Fortran pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16 Bug ID: 16 Summary: [OpenACC] Implicit mapping wrong for scalar Fortran pointers Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: openacc, wrong-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: cltang at gcc dot gnu.org, tschwinge at gcc dot gnu.org Target Milestone: --- Longer example: https://gcc.gnu.org/pipermail/fortran/2023-August/059705.html The problem in the following program is that 'ptr' is a Fortran POINTER, i.e. an aggregate variable per the glossary (all quotes are from OpenACC 3.2). But it is treated as if it were a scalar. "Aggregate variables – a variable of any non-scalar datatype, including array or composite variables. In Fortran, this includes any variable with allocatable or pointer attribute and character variables." However, as the dump shows, the variable is 'firstprivate' (serial, parallel) or 'copy' (kernels). Expected: 'present' for 'default(present)' and otherwise 'copy': #pragma omp target oacc_parallel firstprivate(ptr) #pragma omp target oacc_parallel default(present) firstprivate(ptr) #pragma omp target oacc_serial firstprivate(ptr) #pragma omp target oacc_serial default(present) firstprivate(ptr) #pragma omp target oacc_kernels map(force_tofrom:*ptr [len: 4]) map(alloc:ptr [pointer assign, bias: 0]) #pragma omp target oacc_kernels default(present) map(force_tofrom:*ptr [len: 4]) map(alloc:ptr [pointer assign, bias: 0]) subroutine sub integer, pointer :: ptr allocate(ptr) ptr = 5 !$acc parallel ptr = 8 !$acc end parallel !$acc parallel default(present) ptr = 8 !$acc end parallel !$acc serial ptr = 8 !$acc end serial !$acc serial default(present) ptr = 8 !$acc end serial !$acc kernels ptr = 7 !$acc end kernels !$acc kernels default(present) ptr = 7 !$acc end kernels deallocate(ptr) end "2.6.2 Variables with Implicitly Determined Data Attributes" states: ... An aggregate variable will be treated as if it appears either: • In a present clause if there is a default(present) clause visible at the compute construct. • In a copy clause otherwise. A scalar variable will be treated as if it appears either: • In a copy clause if the compute construct is a kernels construct. • In a firstprivate clause otherwise. Note: Any default(none) clause visible at the compute construct applies to both aggregate and scalar variables. However, any default(present) clause visible at the compute construct applies only to aggregate variables. * * * Vaguely related: PR 90247 which is about pointers in a C program.
[Bug c++/110342] [C++26] P2361R6 - Unevaluated strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110342 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Jakub Jelinek --- Created attachment 55779 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55779&action=edit gcc14-pr110342.patch Untested implementation.
[Bug c++/111117] New: Crash in vector code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17 Bug ID: 17 Summary: Crash in vector code Product: gcc Version: 8.5.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: --- Repro: https://gcc.godbolt.org/z/7GbsaxbYT Result: during RTL pass: final : In member function 'void hwy::N_AVX3::TestDemoteUI64ToFloat::operator()(T, D) [with T = long unsigned int; D = hwy::N_AVX3::Simd]': :28:3: internal compiler error: Segmentation fault
[Bug middle-end/111118] New: Bogus -Wstringop-overread with -std=gnu++20 -O2 and std::vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18
Bug ID: 18
Summary: Bogus -Wstringop-overread with -std=gnu++20 -O2 and
std::vector
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Keywords: alias, diagnostic, missed-optimization, patch
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: rogerio.souza at gmail dot com
Target Milestone: ---
The following C++ code compiled with "-c -O1 -std=gnu++20
-Werror=stringop-overread" emits a bogus warning/error with gcc trunk, while it
works without problem when using "-O1 -std=gnu++17" or "-O0 -std=gnu++20"
instead. Tested on compiler explorer on x64 Linux
"https://godbolt.org/z/491jTvj65":
#include
struct S {
std::vector p;
void foo();
};
#ifdef INLINE
inline
#endif
void S::foo() {
p.reserve(64);
}
===
The code above works fine when running on GCC 12.3.0, but GCC starts raising
the warning bellow sicne GCC v13.1.
In file included from
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/vector:62,
from :1:
In static member function 'static constexpr _Up* std::__copy_move<_IsMove,
true, std::random_access_iterator_tag>::__copy_m(_Tp*, _Tp*, _Up*) [with _Tp =
long unsigned int; _Up = long unsigned int; bool _IsMove = false]',
inlined from 'constexpr _OI std::__copy_move_a2(_II, _II, _OI) [with bool
_IsMove = false; _II = long unsigned int*; _OI = long unsigned int*]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/stl_algobase.h:506:30,
inlined from 'constexpr _OI std::__copy_move_a1(_II, _II, _OI) [with bool
_IsMove = false; _II = long unsigned int*; _OI = long unsigned int*]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/stl_algobase.h:533:42,
inlined from 'constexpr _OI std::__copy_move_a(_II, _II, _OI) [with bool
_IsMove = false; _II = long unsigned int*; _OI = long unsigned int*]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/stl_algobase.h:540:31,
inlined from 'constexpr _OI std::copy(_II, _II, _OI) [with _II = long
unsigned int*; _OI = long unsigned int*]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/stl_algobase.h:633:7,
inlined from 'constexpr std::vector::iterator
std::vector::_M_copy_aligned(const_iterator, const_iterator,
iterator) [with _Alloc = std::allocator]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/stl_bvector.h:1303:28,
inlined from 'constexpr void std::vector::_M_reallocate(size_type) [with _Alloc = std::allocator]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/vector.tcc:851:40,
inlined from 'constexpr void std::vector::reserve(size_type)
[with _Alloc = std::allocator]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/stl_bvector.h:1091:17,
inlined from 'void S::foo()' at :12:14:
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/stl_algobase.h:437:30:
warning: 'void* __builtin_memmove(void*, const void*, long unsigned int)'
writing between 9 and 9223372036854775807 bytes into a region of size 8
overflows the destination [-Wstringop-overflow=]
437 | __builtin_memmove(__result, __first, sizeof(_Tp) * _Num);
| ~^~~
In file included from
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/x86_64-linux-gnu/bits/c++allocator.h:33,
from
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/allocator.h:46,
from
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/vector:63:
In member function '_Tp* std::__new_allocator<_Tp>::allocate(size_type, const
void*) [with _Tp = long unsigned int]',
inlined from 'constexpr _Tp* std::allocator<
>::allocate(std::size_t) [with _Tp = long unsigned int]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/allocator.h:198:40,
inlined from 'static constexpr _Tp*
std::allocator_traits >::allocate(allocator_type&,
size_type) [with _Tp = long unsigned int]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/alloc_traits.h:482:28,
inlined from 'constexpr std::_Bvector_base<_Alloc>::_Bit_pointer
std::_Bvector_base<_Alloc>::_M_allocate(std::size_t) [with _Alloc =
std::allocator]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/stl_bvector.h:643:48,
inlined from 'constexpr void std::vector::_M_reallocate(size_type) [with _Alloc = std::allocator]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/vector.tcc:849:43,
inlined from 'constexpr void std::vector::reserve(size_type)
[with _Alloc = std::allocator]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/stl_bvector.h:1091:17,
inlined from 'void S::foo()' at :12:14:
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/new_allocator.h:147:55:
note: destination object of size 8 allocat
[Bug target/111119] New: maskload and maskstore for integer modes are oddly conditional on AVX2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19 Bug ID: 19 Summary: maskload and maskstore for integer modes are oddly conditional on AVX2 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- We have (define_expand "maskload" [(set (match_operand:V48_AVX2 0 "register_operand") (unspec:V48_AVX2 [(match_operand: 2 "register_operand") (match_operand:V48_AVX2 1 "memory_operand")] UNSPEC_MASKMOV))] "TARGET_AVX") and (define_mode_iterator V48_AVX2 [V4SF V2DF V8SF V4DF (V4SI "TARGET_AVX2") (V2DI "TARGET_AVX2") (V8SI "TARGET_AVX2") (V4DI "TARGET_AVX2")]) so for example maskloadv4siv4si is disabled with just -mavx while the actual instruction can operate just fine on SImode sized data by pretending its SFmode. check_effective_target_vect_masked_load is conditional on AVX, not AVX2. With just AVX we can still use SSE2 vectorization for integer operations using masked loads/stores from AVX.
[Bug ipa/111088] useless 'xor eax,eax' inserted when a value is not returned and icf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111088 Martin Jambor changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #5 from Martin Jambor --- (In reply to Jan Hubicka from comment #3) > > But adds a return with a value. And then the inliner inlines foo into foo2 > > but > > we still have the return with a value around ... > I guess ICF can special case unused return value, but why this is not > taken care of by ipa-sra? Probably because none of the functions is static.
[Bug tree-optimization/111115] Failure to vectorize conditional grouped store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Last reconfirmed||2023-08-23 --- Comment #1 from Richard Biener --- I have a patch.
[Bug c++/110343] [C++26] P2558R2 - Add @, $, and ` to the basic character set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110343 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- clang claims to implement this but that doesn't seem to be the case, I think e.g. const char *p = R"abc`@$(foobar)abc`@$"; should be accepted for -std=c++2c. I'm lost at what we need to do for This is currently rejected by GCC ‘error: universal character is not valid in an identifier’, although this seems to be a bug, and the code is accepted by clang and msvc. in the paper (3.1).
[Bug c++/111117] Crash in AVX-512 vector code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17 --- Comment #1 from Jonathan Wakely --- Please provide the code as requested by https://gcc.gnu.org/bugs (not just a URL)
[Bug c++/111117] Crash in AVX-512 vector code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17 Richard Biener changed: What|Removed |Added Known to work||9.1.0 Status|UNCONFIRMED |RESOLVED Target||x86_64-*-* Resolution|--- |FIXED --- Comment #2 from Richard Biener --- Works in 9.1.0 and up, GCC 8 is no longer supported.
[Bug target/94866] Failure to optimize pinsrq of 0 with index 1 into movq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94866
--- Comment #6 from Hongtao.liu ---
(In reply to Uroš Bizjak from comment #4)
> (In reply to Hongtao.liu from comment #3)
> > in x86 backend expand_vec_perm_1, we always tries vec_merge frist for
> > !one_operand_p, expand_vselect_vconcat is only tried when vec_merge failed
> > which means we'd better to use vec_merge instead of vec_select:vec_concat
> > when available in out backend pattern match.
>
> In fact, I tried to convert existing sse2_movq128 patterns to vec_merge, but
> the patch regressed:
>
> -FAIL: gcc.target/i386/sse2-pr94680-2.c scan-assembler movq
> -FAIL: gcc.target/i386/sse2-pr94680-2.c scan-assembler-not pxor
> -FAIL: gcc.target/i386/sse2-pr94680.c scan-assembler-not pxor
> -FAIL: gcc.target/i386/sse2-pr94680.c scan-assembler-times
> (?n)(?:mov|psrldq).*%xmm[0-9] 12
>
> So, the compiler still expects vec_concat/vec_select patterns to be present.
v2df foo_v2df (v2df x)
{
return __builtin_shuffle (x, (v2df) { 0, 0 }, (v2di) { 0, 2 });
}
The testcase is not a typical vec_merge case, for vec_merge, the shuffle index
should be {0, 3}. Here it happened to be a vec_merge because the second vector
is all zero. And yes for this case, we still need to vec_concat:vec_select
pattern.
[Bug libffi/108682] libffi needs to merge upstream to get LoongArch support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108682 Xi Ruoyao changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #12 from Xi Ruoyao --- Fixed. If we need a ticket for Go support open a new one.
[Bug web/111120] New: Rrrrr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20 Bug ID: 20 Summary: R Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: kodot34341 at vikinoko dot com Target Milestone: ---
[Bug target/111121] AArch64: MOPS memmove operand corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21 Wilco changed: What|Removed |Added Last reconfirmed||2023-08-23 Assignee|unassigned at gcc dot gnu.org |wilco at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||12.0, 13.0 Status|UNCONFIRMED |ASSIGNED
[Bug target/111121] New: AArch64: MOPS memmove operand corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21
Bug ID: 21
Summary: AArch64: MOPS memmove operand corruption
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wilco at gcc dot gnu.org
Target Milestone: ---
Since GCC 12.0 the following example corrupts x0 when built with -O2
-march=armv8.6-a+mops:
int *f (int *p, int *q, long n) { memmove (p, q, n); return p; }
f:
cpyp[x0]!, [x1]!, x2!
cpym[x0]!, [x1]!, x2!
cpye[x0]!, [x1]!, x2!
ret
The expansion for memcpy works differently and inserts a copy to a temporary.
-mstrict-align is ignored with small constant-sized memcpy if MOPS is enabled:
void g(int *p, int *q) { memcpy (p, q, 32); }
g:
ldp q0, q1, [x1]
stp q0, q1, [x0]
ret
[Bug target/111121] AArch64: MOPS memmove operand corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21 Wilco changed: What|Removed |Added Target Milestone|--- |14.0 Target||AArch64
[Bug web/111120] Rrrrr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20 ktkachov at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from ktkachov at gcc dot gnu.org --- .
[Bug target/111010] [13/14 regression] error: unable to find a register to spill compiling GCDAProfiling.c since r13-5092-g4e0b504f26f78f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111010 --- Comment #18 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:94a25d3dede035ce8318ae25388d658753c90a3b commit r14-3410-g94a25d3dede035ce8318ae25388d658753c90a3b Author: Uros Bizjak Date: Wed Aug 23 16:39:21 2023 +0200 i386: Fix register spill failure with concat RTX [PR111010] Disable (=&r,m,m) alternative for 32-bit targets. The combination of two memory operands (possibly with complex addressing mode), early clobbered output, frame pointer and PIC registers uses too much registers on a register constrained 32-bit target. Also merge two similar patterns using DWIH mode iterator. PR target/111010 gcc/ChangeLog: * config/i386/i386.md (*concat3_3): Merge pattern from *concatditi3_3 and *concatsidi3_3 using DWIH mode iterator. Disable (=&r,m,m) alternative for 32-bit targets. (*concat3_3): Disable (=&r,m,m) alternative for 32-bit targets.
[Bug target/111010] [13/14 regression] error: unable to find a register to spill compiling GCDAProfiling.c since r13-5092-g4e0b504f26f78f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111010 --- Comment #19 from CVS Commits --- The releases/gcc-13 branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:8e828c10249d895de5f55db58e1f10448498398f commit r13-7746-g8e828c10249d895de5f55db58e1f10448498398f Author: Uros Bizjak Date: Wed Aug 23 16:42:38 2023 +0200 i386: Fix register spill failure with concat RTX [PR111010] Disable (=&r,m,m) alternative for 32-bit targets. The combination of two memory operands (possibly with complex addressing mode), early clobbered output, frame pointer and PIC registers uses too much registers on a register constrained 32-bit target. PR target/111010 gcc/ChangeLog: * config/i386/i386.md (*concat3_3): Disable (=&r,m,m) alternative for 32-bit targets. (*concat3_4): Ditto.
[Bug target/111010] [13/14 regression] error: unable to find a register to spill compiling GCDAProfiling.c since r13-5092-g4e0b504f26f78f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111010 Uroš Bizjak changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #20 from Uroš Bizjak --- Fixed for gcc-13.3+
[Bug middle-end/111118] Bogus -Wstringop-overread with -std=gnu++20 -O2 and std::vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18 Andrew Pinski changed: What|Removed |Added Keywords|patch | --- Comment #1 from Andrew Pinski --- _5 = MEM[(const struct vector *)this_2(D)].D.36316._M_impl.D.35789._M_start.D.21297._M_p; _6 = MEM[(const struct _Bvector_impl *)this_2(D)].D.35789._M_end_of_storage; _7 = _6 - _5; _8 = _7 * 8; _9 = (long unsigned int) _8; if (_9 <= 63) goto ; [33.00%] else goto ; [67.00%] [local count: 354334800]: _42 = operator new (8); SR.127_14 = MEM <_Bit_type * const> [(struct vector *)this_2(D) + 16B]; SR.128_15 = MEM [(struct vector *)this_2(D) + 24B]; _16 = MEM[(struct vector *)this_2(D)].D.36316._M_impl.D.35789._M_start.D.21297._M_p; _51 = SR.127_14 - _16; _148 = (long unsigned int) _51; if (_51 > 8) There is a missing optimization here.
[Bug target/94866] Failure to optimize pinsrq of 0 with index 1 into movq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94866
--- Comment #7 from Uroš Bizjak ---
(In reply to Hongtao.liu from comment #6)
> > So, the compiler still expects vec_concat/vec_select patterns to be present.
>
> v2df foo_v2df (v2df x)
> {
>return __builtin_shuffle (x, (v2df) { 0, 0 }, (v2di) { 0, 2 });
> }
>
> The testcase is not a typical vec_merge case, for vec_merge, the shuffle
> index should be {0, 3}. Here it happened to be a vec_merge because the
> second vector is all zero. And yes for this case, we still need to
> vec_concat:vec_select pattern.
I guess the original patch is the way to go then.
[Bug target/111096] Frame pointer is not used even when -fomit-frame-pointer is specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111096 --- Comment #6 from Richard Earnshaw --- For completeness. The AArch64 ABI lists 4 alternatives with respect to having a frame chain. When -fomit-frame-pointer is used, GCC implements this one: - It may require the frame pointer to address a valid frame record at all times, except that any subroutine may elect not to create a frame record
[Bug middle-end/111118] Bogus -Wstringop-overread with -std=gnu++20 -O2 and std::vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18
--- Comment #2 from Jonathan Wakely ---
This seems to avoid the warning:
--- a/libstdc++-v3/include/bits/vector.tcc
+++ b/libstdc++-v3/include/bits/vector.tcc
@@ -926,9 +926,12 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
vector::
_M_reallocate(size_type __n)
{
+ const const_iterator __begin = begin(), __end = end();
+ if ((__end - __begin) > __n)
+ __builtin_unreachable();
_Bit_pointer __q = this->_M_allocate(__n);
iterator __start(std::__addressof(*__q), 0);
- iterator __finish(_M_copy_aligned(begin(), end(), __start));
+ iterator __finish(_M_copy_aligned(__begin, __end, __start));
this->_M_deallocate();
this->_M_impl._M_start = __start;
this->_M_impl._M_finish = __finish;
[Bug target/95958] [meta-bug] Inefficient arm_neon.h code for AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95958 Bug 95958 depends on bug 88212, which changed state. Bug 88212 Summary: IRA Register Coalescing not working for the testcase https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88212 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug rtl-optimization/88212] IRA Register Coalescing not working for the testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88212 Tamar Christina changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Target Milestone|--- |11.0 --- Comment #2 from Tamar Christina --- Fixed in GCC 12 with changes in how we pass structural types.
[Bug target/89967] Inefficient code generation for vld2q_lane_u8 under aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89967 Tamar Christina changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=106106 --- Comment #3 from Tamar Christina --- This is caused by SRA scalarizing the structural registers. i.e. it breaks apart the uint8x16x2_t into two uint8x16_t, for use with vld2 we need them as a whole, and so we recreate the type again. This causes a copy through scalarization and then constructing the type again in RTL. Reload is able to remove one copy but not the other. The fix for #106106 will also fix this.
[Bug c++/110348] [C++26] P2741R3 - User-generated static_assert messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110348 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 55780 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55780&action=edit gcc14-pr110348-wip.patch Untested WIP on this. Now need to figure out which usual cases I'm going to handle an easy way (I think STRIP_NOPS of ADDR_EXPR of STRING_CST, POINTER_PLUS of that plus INTEGER_CST, ADDR_EXPR of a VAR_DECL with STRING_CST DECL_INITIAL, ADDR_EXPR of ARRAY_REF of a VAR_DECL with STRING_CST DECL_INITIAL/STRING_CST for start, for others I'll need to build ARRAY_REF for each char and evaluate). Plus testcase coverage. It isn't clear what will or should happen if one uses some special execution character set, because then strings and literals will be translated into that execution character set and writing that as message might be weird.
[Bug tree-optimization/111109] [13/14 Regression] wrong code for some fp comparisons (after r13-4620-g4d9db4bdd458)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=09 --- Comment #2 from Andrew Pinski --- Created attachment 55781 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55781&action=edit Full testcase
[Bug target/111121] AArch64: MOPS memmove operand corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=103100 --- Comment #1 from Andrew Pinski --- (In reply to Wilco from comment #0) > -mstrict-align is ignored with small constant-sized memcpy if MOPS is > enabled: -mstrict-align is also broken for memset, see PR 103100.
[Bug target/111117] Crash in AVX-512 vector code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection --- Comment #3 from Andrew Pinski --- Would be useful to figure out what changed though. I noticed the crash was not there if -g was not used (or adding -g0).
[Bug target/97807] ICE in output_move_double, at config/arm/arm.c:19689
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97807 --- Comment #3 from Martin Jambor --- I believe our tester has hit this again recently: arm-linux-gnueabi-gcc /home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/gcc.c-torture/compile/packed-aligned-1.c -mcpu=cortex-r4f -fno-tree-coalesce-vars -O2 --param=hot-bb-frequency-fraction=0 results in an ICE in output_move_double, at config/arm/arm.cc:20091 The backtrace is similar: 0xdeadbeef output_move_double(rtx_def**, bool, int*) /home/worker/buildworker/tiber-gcc-trunk-arm/build/gcc/config/arm/arm.cc:20091 0xdeadbeef final_scan_insn_1 /home/worker/buildworker/tiber-gcc-trunk-arm/build/gcc/final.cc:2774 0xdeadbeef final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*) /home/worker/buildworker/tiber-gcc-trunk-arm/build/gcc/final.cc:2887 0xdeadbeef final_1 /home/worker/buildworker/tiber-gcc-trunk-arm/build/gcc/final.cc:1979 0xdeadbeef rest_of_handle_final /home/worker/buildworker/tiber-gcc-trunk-arm/build/gcc/final.cc:4240 0xdeadbeef execute /home/worker/buildworker/tiber-gcc-trunk-arm/build/gcc/final.cc:4318
[Bug tree-optimization/111114] RISC-V: Failed combine extend + vcond_mask when modify by vect_recog_over_widening_pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-08-23 Ever confirmed|0 |1 Component|target |tree-optimization CC||pinskia at gcc dot gnu.org --- Comment #1 from Andrew Pinski --- There is a match pattern which handles the case where the convert (cast) will fold both sides of the vec_cond now (since r14-3337-g70c50c87273d94). vect__5.14_56 = .MASK_LEN_LOAD (vectp_a.12_54, 8B, mask__24.11_52, _67, 0); Is there a way to simplify that with the convert? Or maybe we want to it if one or the other conversion simplifies Confirmed.
[Bug c++/111113] Cannot define friend function of a local class in namespace scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-08-23
--- Comment #1 from Andrew Pinski ---
Confirmed.
Another testcase which might show what is really going on:
```
auto foo() {
struct A;
void bar(const A&);
struct A {
friend void bar(const A&);
};
bar(A{});
return A{};
}
using A = decltype(foo());
void bar(const A&) {}
int main()
{
bar(foo());
}
```
We get the following error message:
```
: In function 'int main()':
:16:12: error: call of overloaded 'bar(foo()::A)' is ambiguous
16 | bar(foo());
| ~~~^~~
:12:6: note: candidate: 'void bar(const A&)'
12 | void bar(const A&) {}
| ^~~
:5:21: note: candidate: 'void bar(const foo()::A&)'
5 | friend void bar(const A&);
| ^~~
```
Which is not correct as bar in this case is the same bar.
[Bug c++/111113] Cannot define friend function of a local class in namespace scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=51757 Known to fail||4.8.1 --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > Confirmed. > > Another testcase which might show what is really going on: ... > Which is not correct as bar in this case is the same bar. The ambiguous error message was added in GCC 11.
[Bug c++/111113] Cannot define friend function of a local class in namespace scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=101356 --- Comment #3 from Andrew Pinski --- I think this is a dup of bug 101356.
[Bug c++/101356] The non-public member of a local class cannot be accessed by a friend of the class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101356 --- Comment #3 from Andrew Pinski --- (In reply to Andrew Pinski from comment #2) > And even this is rejected: This was fixed in GCC 10.5.0, 11.4.0, 12.3.0 and 13+. But the original example is still broken.
[Bug c++/111113] Cannot define friend function of a local class in namespace scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13 --- Comment #4 from Andrew Pinski --- (In reply to Andrew Pinski from comment #3) > I think this is a dup of bug 101356. Well at least it is a related issue; maybe not a dup.
[Bug tree-optimization/110918] [14 Regression] Dead Code Elimination Regression at -O3 since r14-2331-g018e7f16408
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110918 --- Comment #2 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:0cfc9c953d0221ec3971a25e6509ebe1041f142e commit r14-3414-g0cfc9c953d0221ec3971a25e6509ebe1041f142e Author: Andrew MacLeod Date: Thu Aug 17 12:34:59 2023 -0400 Phi analyzer - Initialize with range instead of a tree. Rangers PHI analyzer currently only allows a single initializer to a group. This patch changes that to use an inialization range, which is cumulative of all integer constants, plus a single symbolic value. There is no other change to group functionality. This patch also changes the way PHI groups are printed so they show up in the listing as they are encountered, rather than as a list at the end. It was more difficult to see what was going on previously. PR tree-optimization/110918 - Initialize with range instead of a tree. gcc/ * gimple-range-fold.cc (fold_using_range::range_of_phi): Tweak output. * gimple-range-phi.cc (phi_group::phi_group): Remove unused members. Initialize using a range instead of value and edge. (phi_group::calculate_using_modifier): Use initializer value and process for relations after trying for iteration convergence. (phi_group::refine_using_relation): Use initializer range. (phi_group::dump): Rework the dump output. (phi_analyzer::process_phi): Allow multiple constant initilizers. Dump groups immediately as created. (phi_analyzer::dump): Tweak output. * gimple-range-phi.h (phi_group::phi_group): Adjust prototype. (phi_group::initial_value): Delete. (phi_group::refine_using_relation): Adjust prototype. (phi_group::m_initial_value): Delete. (phi_group::m_initial_edge): Delete. (phi_group::m_vr): Use int_range_max. * tree-vrp.cc (execute_ranger_vrp): Don't dump phi groups. gcc/testsuite/ * gcc.dg/pr102983.c: Adjust output expectations. * gcc.dg/pr110918.c: New.
[Bug fortran/32986] Improve diagnostic message for COMMON with automatic object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32986 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #4 from anlauf at gcc dot gnu.org --- Created attachment 55782 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55782&action=edit Draft patch How about the attached patch? This gives for the code in comment#0: pr32986.f90:2:14: 2 | real :: x(n) | 1 3 | common /c/ x |2 Error: Automatic object 'x' at (1) cannot appear in COMMON at (2)
[Bug fortran/32986] Improve diagnostic message for COMMON with automatic object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32986 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #5 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2023-August/059707.html
[Bug fortran/32986] Improve diagnostic message for COMMON with automatic object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32986 --- Comment #6 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:829c0c06fe7ba2cf3e83508b95999b884b21236d commit r14-3415-g829c0c06fe7ba2cf3e83508b95999b884b21236d Author: Harald Anlauf Date: Wed Aug 23 21:08:01 2023 +0200 Fortran: improve diagnostic message for COMMON with automatic object [PR32986] gcc/fortran/ChangeLog: PR fortran/32986 * resolve.cc (is_non_constant_shape_array): Add forward declaration. (resolve_common_vars): Diagnose automatic array object in COMMON. (resolve_symbol): Prevent confusing follow-on error. gcc/testsuite/ChangeLog: PR fortran/32986 * gfortran.dg/common_28.f90: New test.
[Bug c++/111122] New: local temps from get_nsdmi -> break_out_target_exprs break constexpr evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22
Bug ID: 22
Summary: local temps from get_nsdmi -> break_out_target_exprs
break constexpr evaluation
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
struct T {
const char *d = new char[2] { 'o', 'k' };
constexpr int size () const { return 2; }
constexpr const char *data () const { return d; }
constexpr ~T () { delete[] d; }
};
constexpr int a = T{}.size ();
constexpr int b = T{}.data ()[0];
//constexpr const char *c = T{}.data ();
is rejected by g++ with
test42.C:7:29: error: the value of ‘’ is not usable in a constant
expression
7 | constexpr int a = T{}.size ();
| ^
test42.C:7:21: note: ‘’ was not declared ‘constexpr’
7 | constexpr int a = T{}.size ();
| ^
test42.C:8:32: error: the value of ‘’ is not usable in a constant
expression
8 | constexpr int b = T{}.data ()[0];
|^
test42.C:8:21: note: ‘’ was not declared ‘constexpr’
8 | constexpr int b = T{}.data ()[0];
| ^
during potential_constant_expression_1,
while clang++ accepts it.
[Bug fortran/32986] Improve diagnostic message for COMMON with automatic object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32986 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from anlauf at gcc dot gnu.org --- Fixed in gcc-14.
[Bug c++/111122] local temps from get_nsdmi -> break_out_target_exprs break constexpr evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22 --- Comment #1 from Andrew Pinski --- Try from inside a function instead. There is another bug about local Temps used from constexpr from a non-function scope causinbissues.
[Bug c++/111123] New: Warning about "used uninitialized" member shown or hidden randomly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23
Bug ID: 23
Summary: Warning about "used uninitialized" member shown or
hidden randomly
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: agriff at tin dot it
Target Milestone: ---
This code should warning (with -Wall) about the use of `border` that is
uninitialized
#include
#include
struct Camera {
struct P2d {
float x, y;
};
std::vector clip_area;
float border = 10.f;
int z = 3;
Camera() : clip_area({{border, border},
{1-border, border},
{1-border, 1-border},
{border, 1-border}})
{ }
};
int main() {
Camera c;
printf("%.18g\n", c.clip_area[0].x);
}
However does so only if member `z` is present; commenting out the line `int z =
3;` silences the warning.
This show/hide of the warning happens also pseudo-randomly in other cases
(while I was trying to get the minimum code showing the problem I found many
cases in which removing even an executable statement in the body of a method
triggered the behavior change).
[Bug c++/111122] local temps from get_nsdmi -> break_out_target_exprs break constexpr evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22
--- Comment #2 from Jakub Jelinek ---
Sure,
struct T {
const char *d = init ();
constexpr int size () const { return 2; }
constexpr const char *data () const { return d; }
constexpr const char *init () const { return new char[2] { 'o', 'k' }; }
constexpr ~T () { delete[] d; }
};
constexpr int a = T{}.size ();
constexpr int b = T{}.data ()[0];
works.
[Bug c++/111123] Warning about "used uninitialized" member shown or hidden randomly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23 --- Comment #1 from Andrea Griffini --- Forgot to say that -O3 is needed to see the warning (this is however expected)
[Bug c++/110348] [C++26] P2741R3 - User-generated static_assert messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110348
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
||redi at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
I wonder if the paper wording isn't incorrect, or at least comparing the
clang++
implementation vs. the paper gives some differences.
One (minor) is that they emit errors when the size () and/or data () members
aren't constexpr, while the paper as voted in only requires that
"- the expression M.size() is implicitly convertible to std::size_t, and
- the expression M.data() is implicitly convertible to ”pointer to const
char”."
unless the static assertion fails. The WIP patch doesn't do that, only
effectively diagnoses it during constant evaluation of those when the static
assertion fails.
More important, they have in the testcase something similar to what I filed in
PR22, but let's use what works also in GCC:
struct T {
const char *d = init ();
constexpr int size () const { return 2; }
constexpr const char *data () const { return d; }
constexpr const char *init () const { return new char[2] { 'o', 'k' }; }
constexpr ~T () { delete[] d; }
};
constexpr int a = T{}.size (); // Ok, a = 2
constexpr int b = T{}.data ()[0]; // Ok, b = 'o'
constexpr const char *c = T{}.data (); // Not constant expression, because it
returns
// address from new which is later in the dtor deleted.
static_assert (false, T{}); // Valid?
"- M.data(), implicitly converted to the type ”pointer to const char”, shall be
a core
constant expression and let D denote the converted expression,
– for each i where 0 ≤ i < N , D[i] shall be an integral constant expression,
and"
Now, I believe T{}.data () is not a core constant expression exactly because it
returns address of later deleted heap object, but sure, both T{}.data ()[0] and
T{}.data ()[1]
are integral constant expressions.
I don't know how std::format if constexpr (is it?) or string_view etc. work, do
they
need M.data () not be actual constant expression and only M.data ()[0] through
M.data ()[M.size () - 1] constant expressions? In the patch I can surely try
to constant expr evaluate M.data () quietly and if it isn't constant
expression, just use a slower way which will ask for each character
individually. More important question is what is the intention for the
standard...
[Bug analyzer/111099] -fanalyzer -Os segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111099 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-08-23 --- Comment #1 from David Malcolm --- Thanks for filing this bug report. Confirmed: trunk: https://godbolt.org/z/Kfo18Kern gcc 13.2: https://godbolt.org/z/4f31jhra6 Doesn't seem to affect: gcc 12.3: https://godbolt.org/z/rTjqahPfG gcc 12.2: https://godbolt.org/z/favPd1zfz gcc 11.4: https://godbolt.org/z/1xs1oMqTs
[Bug analyzer/111099] -fanalyzer -Os segmentation fault due to infinite recursion in ana::constraint_manager::eval_condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111099 --- Comment #2 from David Malcolm --- Infinite recursion within ana::constraint_manager::eval_condition; possible duplicate of bug 109027
[Bug analyzer/109027] [13/14 Regression] ICE: SIGSEGV (infinite recursion in ana::constraint_manager::eval_condition / ana::constraint_manager::impossible_derived_conditions_p) with -fanalyzer since r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109027 --- Comment #6 from David Malcolm --- Bug 111099 is possibly a duplicate of this.
[Bug target/111096] Frame pointer is not used even when -fomit-frame-pointer is specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111096 --- Comment #7 from Thomas Koenig --- (In reply to Richard Earnshaw from comment #5) > This was a deliberate design choice. Although the frame chain is not set up > by code that omits the frame pointer, the chain of frames that are set up by > other functions is still valid this way. This ensures that any code that > does try to walk the frame chain will not crash. If we reused the frame > pointer for other purposes, then any code trying to walk the frame chain (eg > backtrace()) would encounter an invalid record and likely crash. Would it make sense to document this somewhere? Or did I just miss it? :-)
[Bug tree-optimization/110918] [14 Regression] Dead Code Elimination Regression at -O3 since r14-2331-g018e7f16408
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110918 Andrew Macleod changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Andrew Macleod --- fixed.
[Bug tree-optimization/111109] [13/14 Regression] wrong code for some fp comparisons (after r13-4620-g4d9db4bdd458)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=09 Andrew Pinski changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-August/ ||628292.html Keywords||patch --- Comment #3 from Andrew Pinski --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628292.html
[Bug tree-optimization/111110] (A CMP B) != 0 and (A CMP B) == true patterns produce an extra (A CMP B) rather than reusing it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Andrew Pinski --- So this won't work even though it is the right thing to do because when we are folding `if (a != 1)` and a is defined by a comparison, we want to get back the comparison. Now you could say this is problem in how we fold GIMPLE_COND but it is what it is right now.
[Bug c++/111113] Cannot define friend function of a local class in namespace scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13 Language Lawyer changed: What|Removed |Added CC||language.lawyer at gmail dot com --- Comment #5 from Language Lawyer --- (In reply to Andrew Pinski from comment #3) > I think this is a dup of bug 101356. Looks dup to me too. Looks like GCC does not match friend function declaration with its namespace declaration.
[Bug rtl-optimization/111124] New: ICE on narrowing memory-constant comparison on loongarch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24
Bug ID: 24
Summary: ICE on narrowing memory-constant comparison on
loongarch
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: xen0n at gentoo dot org
CC: stefansf at linux dot ibm.com
Target Milestone: ---
Target: loongarch64-linux-gnu
Created attachment 55783
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55783&action=edit
Minimized reproducer
Bootstrap on loongarch64-linux-gnu has been failing since commit 7cdd0860949
("combine: Narrow comparison of memory and constant"), which is pinpointed by
bisection. A minimized reproducing example is attached:
$ /tmp/gcc-build/gcc/xgcc -B/tmp/gcc-build/gcc/ -O2 -S -o /dev/null
/tmp/loongarch-narrow-ice.i
during RTL pass: combine
/tmp/loongarch-narrow-ice.c: In function ‘ok_for_merging’:
/tmp/loongarch-narrow-ice.c:10:1: internal compiler error: in decompose, at
rtl.h:2297
10 | }
| ^
0x6b25af wi::int_traits >::decompose(long*,
unsigned int, std::pair const&)
/home/xenon/store/src/oss/own/loongson/gcc-la64/gcc/rtl.h:2297
0x6b25af wide_int_ref_storage::wide_int_ref_storage
>(std::pair const&)
/home/xenon/store/src/oss/own/loongson/gcc-la64/gcc/wide-int.h:1030
0x6b25af generic_wide_int
>::generic_wide_int >(std::pair const&)
/home/xenon/store/src/oss/own/loongson/gcc-la64/gcc/wide-int.h:788
0x6b25af simplify_const_unary_operation(rtx_code, machine_mode, rtx_def*,
machine_mode)
/home/xenon/store/src/oss/own/loongson/gcc-la64/gcc/simplify-rtx.cc:1991
0xe4d67d simplify_context::simplify_unary_operation(rtx_code, machine_mode,
rtx_def*, machine_mode)
/home/xenon/store/src/oss/own/loongson/gcc-la64/gcc/simplify-rtx.cc:889
0xe4d67d simplify_context::simplify_gen_unary(rtx_code, machine_mode, rtx_def*,
machine_mode)
/home/xenon/store/src/oss/own/loongson/gcc-la64/gcc/simplify-rtx.cc:360
0x168e8e9 simplify_gen_unary(rtx_code, machine_mode, rtx_def*, machine_mode)
/home/xenon/store/src/oss/own/loongson/gcc-la64/gcc/rtl.h:3520
0x168e8e9 simplify_comparison
/home/xenon/store/src/oss/own/loongson/gcc-la64/gcc/combine.cc:13136
0x169046f combine_simplify_rtx
/home/xenon/store/src/oss/own/loongson/gcc-la64/gcc/combine.cc:6176
0x1692a35 subst
/home/xenon/store/src/oss/own/loongson/gcc-la64/gcc/combine.cc:5609
0x169298d subst
/home/xenon/store/src/oss/own/loongson/gcc-la64/gcc/combine.cc:5536
0x1695c78 try_combine
/home/xenon/store/src/oss/own/loongson/gcc-la64/gcc/combine.cc:3339
0x169bd85 combine_instructions
/home/xenon/store/src/oss/own/loongson/gcc-la64/gcc/combine.cc:1300
0x169bd85 rest_of_handle_combine
/home/xenon/store/src/oss/own/loongson/gcc-la64/gcc/combine.cc:15063
0x169bd85 execute
/home/xenon/store/src/oss/own/loongson/gcc-la64/gcc/combine.cc:15107
[Bug rtl-optimization/111124] ICE on narrowing memory-constant comparison on loongarch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24 Xi Ruoyao changed: What|Removed |Added Resolution|--- |DUPLICATE CC||xry111 at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #1 from Xi Ruoyao --- Dup. *** This bug has been marked as a duplicate of bug 110939 ***
[Bug rtl-optimization/110939] [14 Regression] 14.0 ICE at rtl.h:2297 while bootstrapping on loongarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110939 Xi Ruoyao changed: What|Removed |Added CC||xen0n at gentoo dot org --- Comment #12 from Xi Ruoyao --- *** Bug 24 has been marked as a duplicate of this bug. ***
[Bug target/94866] Failure to optimize pinsrq of 0 with index 1 into movq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94866
--- Comment #8 from Hongtao.liu ---
(In reply to Uroš Bizjak from comment #7)
> (In reply to Hongtao.liu from comment #6)
> > > So, the compiler still expects vec_concat/vec_select patterns to be
> > > present.
> >
> > v2df foo_v2df (v2df x)
> > {
> >return __builtin_shuffle (x, (v2df) { 0, 0 }, (v2di) { 0, 2 });
> > }
> >
> > The testcase is not a typical vec_merge case, for vec_merge, the shuffle
> > index should be {0, 3}. Here it happened to be a vec_merge because the
> > second vector is all zero. And yes for this case, we still need to
> > vec_concat:vec_select pattern.
>
> I guess the original patch is the way to go then.
Yes.
[Bug tree-optimization/110628] [14 regression] gcc.dg/tree-ssa/update-threading.c fails after r14-2383-g768f00e3e84123
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110628 --- Comment #7 from Hans-Peter Nilsson --- (In reply to Hans-Peter Nilsson from comment #5) > Not seeing any action for this regression for three weeks, for tracking > purposes I'm considering xfailing this test-case for cris-* after another > week. Now xfailed for cris-*-* by r14-3418-g0c2633dd09f281; unfortunately without a working changelog annotation so it didn't automatically show up here.
[Bug target/110740] [14 regression] gcc.target/powerpc/p9-vec-length-epil-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110740 Kewen Lin changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Kewen Lin --- Should be fixed on trunk.
[Bug middle-end/111125] New: tree-ssa.exp and vect.exp failures after commit 99b5921bfc8f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25 Bug ID: 25 Summary: tree-ssa.exp and vect.exp failures after commit 99b5921bfc8f Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: thiago.bauermann at linaro dot org CC: rguenth at gcc dot gnu.org Target Milestone: --- Target: aarch64 Created attachment 55784 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55784&action=edit gcc.log from commit 829c0c06fe7b Our CI detected that commit 99b5921bfc8f "Handle TYPE_OVERFLOW_UNDEFINED vectorized BB reductions" introduced these testsuite failures on aarch64-linux: === gcc tests === Running gcc:gcc.dg/tree-ssa/tree-ssa.exp ... FAIL: gcc.dg/tree-ssa/slsr-11.c scan-tree-dump-times optimized " \\* " 1 Running gcc:gcc.dg/vect/vect.exp ... FAIL: gcc.dg/vect/bb-slp-29.c -flto -ffat-lto-objects scan-tree-dump-times slp1 "optimized: basic block" 1 FAIL: gcc.dg/vect/bb-slp-29.c scan-tree-dump-times slp1 "optimized: basic block" 1 FAIL: gcc.dg/vect/pr53773.c -flto -ffat-lto-objects scan-tree-dump-times optimized "\\* 10" 2 FAIL: gcc.dg/vect/pr53773.c scan-tree-dump-times optimized "\\* 10" 2 I confirmed that they are still present in trunk as of commit 829c0c06fe7b "Fortran: improve diagnostic message for COMMON with automatic object [PR32986]" from today. The tests above fail with these messages found in gcc.log: - gcc.dg/tree-ssa/slsr-11.c: pattern found 3 times - gcc.dg/vect/bb-slp-29.c: pattern found 2 times - gcc.dg/vect/pr53773.c: pattern found 0 times Tested on Ubuntu 22.04 with: $ ~/src/gcc/configure \ --disable-bootstrap \ --disable-multilib \ && make -j 60 \ && make -C gcc check-gcc RUNTESTFLAGS="gcc.dg/tree-ssa/tree-ssa.exp gcc.dg/vect/vect.exp" I'll attach gcc.log from trunk.
[Bug tree-optimization/95929] Failure to optimize tautological comparisons of comparisons to a single one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95929 Andrew Pinski changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-August/ ||628301.html Keywords||patch --- Comment #6 from Andrew Pinski --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628301.html
[Bug tree-optimization/111114] RISC-V: Failed combine extend + vcond_mask when modify by vect_recog_over_widening_pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14 --- Comment #2 from Lehua Ding --- (In reply to Andrew Pinski from comment #1) > There is a match pattern which handles the case where the convert (cast) > will fold both sides of the vec_cond now (since r14-3337-g70c50c87273d94). > > vect__5.14_56 = .MASK_LEN_LOAD (vectp_a.12_54, 8B, mask__24.11_52, _67, 0); > > Is there a way to simplify that with the convert? > > Or maybe we want to it if one or the other conversion simplifies > > Confirmed. Thanks for the comments. Can we relax this match by removing the modifier "!"?
[Bug tree-optimization/94893] Sign function not getting optimized to simple compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94893
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> Note we also don't optimize:
>
> inline int sign1(int x)
> {
> return (x < 0 ? -1 : 0) | (x > 0 ? 1 : 0);
> }
> bool f1(int x)
> {
> return sign1(x) < 1;
> }
>
> To be just `x <= 0`
That is because forwprop leaves assignments that are not used anywhere still.
after dce7:
```
if (x_2(D) < 0)
goto ; [41.00%]
else
goto ; [59.00%]
[local count: 633507680]:
_7 = x_2(D) != 0;
_8 = (int) _7;
_5 = _8 ^ 1;
_10 = (bool) _5;
[local count: 1073741824]:
# prephitmp_11 = PHI <1(2), _10(3)>
```
After frowprop4:
```
if (x_2(D) < 0)
goto ; [41.00%]
else
goto ; [59.00%]
[local count: 633507680]:
_7 = x_2(D) != 0;
_8 = (int) _7;
_3 = x_2(D) == 0;
_5 = (int) _3;
[local count: 1073741824]:
# prephitmp_11 = PHI <1(2), _3(3)>
```
If those statements were removed then phiopt4 would be able to optimize
prephitmp_11 to: `(x_2(D) < 0) | (x_2(D) == 0)` which simplifies to `x_2(D) <=
0` .
Let me look into the forwprop issue here.
As for the original issue:
x.0_5 = (unsigned int) x_2(D);
_6 = -x.0_5;
_7 = _6 >> 31;
_8 = (int) _7;
We have a pattern for basically this:
/* Fold (-x >> C) into -(x > 0) where C = precision(type) - 1. */
But only for !TYPE_UNSIGNED here. we can do it for unsigned where we just get x
> 0 instead.
[Bug tree-optimization/111114] RISC-V: Failed combine extend + vcond_mask when modify by vect_recog_over_widening_pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14 --- Comment #3 from Andrew Pinski --- (In reply to Lehua Ding from comment #2) > (In reply to Andrew Pinski from comment #1) > > There is a match pattern which handles the case where the convert (cast) > > will fold both sides of the vec_cond now (since r14-3337-g70c50c87273d94). > > > > vect__5.14_56 = .MASK_LEN_LOAD (vectp_a.12_54, 8B, mask__24.11_52, _67, > > 0); > > > > Is there a way to simplify that with the convert? > > > > Or maybe we want to it if one or the other conversion simplifies > > > > Confirmed. > > Thanks for the comments. Can we relax this match by removing the modifier > "!"? I don't think so as we want to make sure we don't replace one operation happening with 2. The check really should be if one side will fold. We can special case VECTOR_CST here knowing that the convert will fold the CST always. So something like: ``` (simplify (convert (vec_cond:s @0 @1 @2)) (if (VECTOR_TYPE_P (type) && types_match (TREE_TYPE (@0), truth_type_for (type))) (if (TREE_CODE (@1) == VECTOR_CST || TREE_CODE (@2) == VECTOR_CST) (vec_cond @0 (convert @1) (convert @2) (vec_cond @0 (convert! @1) (convert! @2) ``` We should do a similar trick to both the unary operator and view_convert too.
[Bug tree-optimization/111114] RISC-V: Failed combine extend + vcond_mask when modify by vect_recog_over_widening_pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14 --- Comment #4 from Lehua Ding --- (In reply to Andrew Pinski from comment #3) > (In reply to Lehua Ding from comment #2) > > (In reply to Andrew Pinski from comment #1) > > > There is a match pattern which handles the case where the convert (cast) > > > will fold both sides of the vec_cond now (since r14-3337-g70c50c87273d94). > > > > > > vect__5.14_56 = .MASK_LEN_LOAD (vectp_a.12_54, 8B, mask__24.11_52, _67, > > > 0); > > > > > > Is there a way to simplify that with the convert? > > > > > > Or maybe we want to it if one or the other conversion simplifies > > > > > > Confirmed. > > > > Thanks for the comments. Can we relax this match by removing the modifier > > "!"? > > I don't think so as we want to make sure we don't replace one operation > happening with 2. The check really should be if one side will fold. > > We can special case VECTOR_CST here knowing that the convert will fold the > CST always. > So something like: > ``` > (simplify > (convert (vec_cond:s @0 @1 @2)) > (if (VECTOR_TYPE_P (type) > && types_match (TREE_TYPE (@0), truth_type_for (type))) > (if (TREE_CODE (@1) == VECTOR_CST || TREE_CODE (@2) == VECTOR_CST) >(vec_cond @0 (convert @1) (convert @2) >(vec_cond @0 (convert! @1) (convert! @2) > ``` > We should do a similar trick to both the unary operator and view_convert too. Just to double check, are you saying something like the bellow? But I don't feel like the purpose is quite the same though. The match here was supposed to remove the CONVERT operation. Whereas I was hoping to reverse the order in order to combine them. ``` (simplify (convert (vec_cond:s @0 @1 @2)) (if (VECTOR_TYPE_P (type) && types_match (TREE_TYPE (@0), truth_type_for (type)) && (TREE_CODE (@1) == VECTOR_CST || TREE_CODE (@2) == VECTOR_CST)) (vec_cond @0 (convert @1) (convert @2 ```
[Bug tree-optimization/94893] Sign function not getting optimized to simple compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94893 --- Comment #5 from Andrew Pinski --- (In reply to Andrew Pinski from comment #4) > As for the original issue: > x.0_5 = (unsigned int) x_2(D); > _6 = -x.0_5; > _7 = _6 >> 31; > _8 = (int) _7; > > We have a pattern for basically this: > /* Fold (-x >> C) into -(x > 0) where C = precision(type) - 1. */ > > But only for !TYPE_UNSIGNED here. we can do it for unsigned where we just > get x > 0 instead. I have a patch which gets us to: # RANGE [irange] int [-1, 0] _3 = x_2(D) >> 31; _5 = x_2(D) > 0; # RANGE [irange] int [0, 1] MASK 0x1 VALUE 0x0 _6 = (intD.9) _5; # RANGE [irange] int [-1, 1] _7 = _3 | _6; _4 = _7 != 1; (_3 | _6) != 1 means !((_3 == 0) && (_6 == 1)) since _3 can't be 1 at all. (_3 == 0) is x >= 0 and _6 == 1 is `x > 0` and that combines to be just `x >= 0` . I think the above only works if the two ranges in the _3|_6 is [-1,0] and [1,0] . (_3 | _6) == -1 just means _3 == -1 even which we don't handle either (and would be simplier to handle than other cases).
[Bug tree-optimization/111114] RISC-V: Failed combine extend + vcond_mask when modify by vect_recog_over_widening_pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14 --- Comment #5 from Andrew Pinski --- (In reply to Lehua Ding from comment #4) > Just to double check, are you saying something like the bellow? But I don't > feel like the purpose is quite the same though. The match here was supposed > to remove the CONVERT operation. Whereas I was hoping to reverse the order > in order to combine them. > > ``` > (simplify > (convert (vec_cond:s @0 @1 @2)) > (if (VECTOR_TYPE_P (type) > && types_match (TREE_TYPE (@0), truth_type_for (type)) > && (TREE_CODE (@1) == VECTOR_CST || TREE_CODE (@2) == VECTOR_CST)) >(vec_cond @0 (convert @1) (convert @2 > ``` Before any changes, we currently get: vect__5.14_56 = .MASK_LEN_LOAD (vectp_a.12_54, 8B, mask__24.11_52, _67, 0); vect_patt_40.15_58 = VEC_COND_EXPR ; vect_patt_41.16_59 = (vector(8) short unsigned int) vect_patt_40.15_58; I assumed you want to push that convert to be before the VEC_COND_EXPR, correct? If so the above match pattern should do that. The check for VECTOR_CST here is mainly so we can the same # of convert expressions show up.
[Bug tree-optimization/111114] RISC-V: Failed combine extend + vcond_mask when modify by vect_recog_over_widening_pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14 --- Comment #6 from Lehua Ding --- (In reply to Andrew Pinski from comment #5) > (In reply to Lehua Ding from comment #4) > > Just to double check, are you saying something like the bellow? But I don't > > feel like the purpose is quite the same though. The match here was supposed > > to remove the CONVERT operation. Whereas I was hoping to reverse the order > > in order to combine them. > > > > ``` > > (simplify > > (convert (vec_cond:s @0 @1 @2)) > > (if (VECTOR_TYPE_P (type) > > && types_match (TREE_TYPE (@0), truth_type_for (type)) > > && (TREE_CODE (@1) == VECTOR_CST || TREE_CODE (@2) == VECTOR_CST)) > >(vec_cond @0 (convert @1) (convert @2 > > ``` > > Before any changes, we currently get: > vect__5.14_56 = .MASK_LEN_LOAD (vectp_a.12_54, 8B, mask__24.11_52, _67, 0); > vect_patt_40.15_58 = VEC_COND_EXPR 1, 1, 1, 1, 1, 1 }>; > vect_patt_41.16_59 = (vector(8) short unsigned int) vect_patt_40.15_58; > > I assumed you want to push that convert to be before the VEC_COND_EXPR, > correct? Yes, By this I mean that changing the order does not reduce the instructions, so it does not feel easy to assess whether it is reasonable or not. Because vect_recog_over_widening_pattern considers vcond_mask + convert to be more efficient than convert + vcond_mask. What do you think?
[Bug middle-end/111126] New: Not always using czero.eqz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26
Bug ID: 26
Summary: Not always using czero.eqz
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
Assignee: pinskia at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Target: riscv* (with zicond)
Take:
```
int f(bool a, int c)
{
return a * c;
}
int f0(bool a, int c)
{
return (-a) & c;
}
int f1(bool a, int c)
{
return a ? c : 0;
}
int f3(int a, int b, int c)
{
return (a == b) * c;
}
int g0(bool a, int c)
{
return a ? 0 : c;
}
int g1(bool a, int c)
{
a = !a;
return a * c;
}
```
Currently for f, f0 we emit:
```
neg a0,a0
and a0,a0,a1
```
Which is good for riscv without zicond but with we should just get the same as
f1.
f1 we do we:
```
czero.eqz a0,a1,a0
```
though without zicond we get:
```
sneza5,a0
neg a5,a5
and a0,a1,a5
```
Notice the extra snez (note the above is because that is ifcvt.cc doing the
emitting).
This is all about what is the canonical form of bool ? a : 0.
[Bug middle-end/111126] Not always using czero.eqz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2023-08-24 --- Comment #1 from Andrew Pinski --- Mine. requires both a gimple match.pd change and an expansion change.
[Bug preprocessor/89808] An option to disable warning "#pragma once in main file"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89808 Diego SC changed: What|Removed |Added CC||diego.santacruz at spinetix dot co ||m --- Comment #13 from Diego SC --- Another use case. We are using precompiled headers in our application, and that includes headers which have "#pragma once". When generating the precompiled header we get this warning: warning: #pragma once in main file In that context the warning is actually invalid, so it would be really nice to be able to turn this warning off, without turning off all warnings.
[Bug debug/111080] [11/12/13/14 Regression] restrict qualifier causes extra debug info to happen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111080 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:bd2c4d6d8fffd5a6dae5217d6076cc4190bab13d commit r14-3421-gbd2c4d6d8fffd5a6dae5217d6076cc4190bab13d Author: Richard Biener Date: Mon Aug 21 10:34:30 2023 +0200 debug/111080 - avoid outputting debug info for unused restrict qualified type The following applies some maintainance with respect to type qualifiers and kinds added by later DWARF standards to prune_unused_types_walk. The particular case in the bug is not handling (thus marking required) all restrict qualified type DIEs. I've found more DW_TAG_*_type that are unhandled, looked up the DWARF docs and added them as well based on common sense. PR debug/111080 * dwarf2out.cc (prune_unused_types_walk): Handle DW_TAG_restrict_type, DW_TAG_shared_type, DW_TAG_atomic_type, DW_TAG_immutable_type, DW_TAG_coarray_type, DW_TAG_unspecified_type and DW_TAG_dynamic_type as to only output them when referenced. * gcc.dg/debug/dwarf2/pr111080.c: New testcase.
[Bug preprocessor/89808] An option to disable warning "#pragma once in main file"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89808 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=47857 --- Comment #14 from Andrew Pinski --- (In reply to Diego SC from comment #13) > Another use case. > > We are using precompiled headers in our application, and that includes > headers which have "#pragma once". When generating the precompiled header we > get this warning: > > warning: #pragma once in main file > > In that context the warning is actually invalid, so it would be really nice > to be able to turn this warning off, without turning off all warnings. That is PR 47857 .
[Bug target/111127] New: Wrong code for avx512ne2ps2bf16_maskz intrinsics since gcc13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27
Bug ID: 27
Summary: Wrong code for avx512ne2ps2bf16_maskz intrinsics since
gcc13
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wwwhhhyyy333 at gmail dot com
Target Milestone: ---
cat test.c
#include
__m512bh cvttest(__mmask32 k, __m512 a, __m512 b)
{
return _mm512_maskz_cvtne2ps_pbh (k,a,b);
}
gcc -O2 -mavx512bf16
kmovd %edi, %k1
vcvtne2ps2bf16 %zmm0, %zmm1, %zmm0{%k1}{z}
ret
The code is wrong compared to clang, the input operand order was inverted.
See https://godbolt.org/z/b161deerY
[Bug target/111121] AArch64: MOPS memmove operand corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21 Richard Biener changed: What|Removed |Added Target Milestone|14.0|12.4
[Bug tree-optimization/110111] bool patterns that should produce a?b:c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110111 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=26 --- Comment #2 from Andrew Pinski --- Mine. I have a patch for f1 now.
[Bug c++/111123] Warning about "used uninitialized" member shown or hidden randomly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2023-08-24
Status|UNCONFIRMED |ASSIGNED
Keywords||diagnostic
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #2 from Richard Biener ---
There's a change in inlining when z is removed. We then have the separate CTOR
void Camera::Camera (struct Camera * const this)
{
...
[local count: 1073741824]:
_2 = *this_6(D).border;
_3 = 1.0e+0 - _2;
_68 = {_2, _2, _3, _2};
and fno CLOBBER of *this_6(D) at its start at the time we do late uninit
diagnostics. That's because we remove those indirect clobbers too early.
[Bug tree-optimization/95929] Failure to optimize tautological comparisons of comparisons to a single one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95929 --- Comment #7 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:ddd64a6ec3b38e18aefb9fcba50c0d9297e5e711 commit r14-3432-gddd64a6ec3b38e18aefb9fcba50c0d9297e5e711 Author: Andrew Pinski Date: Tue Aug 22 18:41:56 2023 -0700 MATCH: remove negate for 1bit types For 1bit types, negate is either undefined or don't change the value. In either cases we want to remove them. This patch adds a match pattern to do that. Also converting to a 1bit type we can remove the negate just like we already do for `&1` so this patch adds that too. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. Notes on the testcases: This patch is the last part to fix PR 95929; cond-bool-2.c testcase. bit1neg-1.c is a 1bit-field testcase where we could remove the assignment all the way in one case (which happened on the RTL level for some targets but not all). cond-bool-2.c is the reduced testcase of PR 95929. PR tree-optimization/95929 gcc/ChangeLog: * match.pd (convert?(-a)): New pattern for 1bit integer types. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/bit1neg-1.c: New test. * gcc.dg/tree-ssa/cond-bool-1.c: New test. * gcc.dg/tree-ssa/cond-bool-2.c: New test.
[Bug tree-optimization/95929] Failure to optimize tautological comparisons of comparisons to a single one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95929 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |14.0 Resolution|--- |FIXED --- Comment #8 from Andrew Pinski --- Fixed. cond-bool-2.c is the testcase.
[Bug middle-end/19987] [meta-bug] fold missing optimizations in general
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987 Bug 19987 depends on bug 95929, which changed state. Bug 95929 Summary: Failure to optimize tautological comparisons of comparisons to a single one https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95929 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug target/111127] [13/14 regression] Wrong code for avx512ne2ps2bf16_maskz intrinsics since gcc13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.3 Priority|P3 |P2
