[Bug c++/97452] [coroutines] incorrect sequencing of await_resume() when multiple co_await expressions occur in a single statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97452 --- Comment #3 from Iain Sandoe --- (In reply to David Ledger from comment #2) > I'm happy to use this thread for the issue, I can just repost my link to the > same issue here. > > My reporting of the issue is here, but Lewis Bakers example is seperate. > > https://stackoverflow.com/questions/64348125/c20-coroutines-unexpected- > reordering-of-await-resume-return-value-and-yield > > Is there anything I can do to help this issue get resolved? I've been > throwing things at the wall trying to get something to stick (for a work > around) but so far nothing helps with this particular case. I have reproduced the problem(s) - the next thing is to do some analysis of the generated code and try to figure out where the bug is.
[Bug tree-optimization/97467] New: ICE in verify_range, at value-range.cc:369 (-Os and above)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97467
Bug ID: 97467
Summary: ICE in verify_range, at value-range.cc:369 (-Os and
above)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
[594] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20201017 (experimental) [master revision
56e4eee935c:ba026021eaa:f476a9fe912132abf06c2832a1bb9abe6c1a1bb1] (GCC)
[595] %
[595] % gcctk -O1 small.c
[596] %
[596] % gcctk -Os small.c
during GIMPLE pass: evrp
small.c: In function ‘main’:
small.c:13:1: internal compiler error: in verify_range, at value-range.cc:369
13 | }
| ^
0x104b853 irange::verify_range()
../../gcc-trunk/gcc/value-range.cc:369
0x104e8b7 irange::irange_set(tree_node*, tree_node*)
../../gcc-trunk/gcc/value-range.cc:172
0x104e8b7 irange::set(tree_node*, tree_node*, value_range_kind)
../../gcc-trunk/gcc/value-range.cc:226
0x1851ec5 int_range<2u>::int_range(tree_node*,
generic_wide_int const&, generic_wide_int
const&, value_range_kind)
../../gcc-trunk/gcc/value-range.h:431
0x1851ec5 operator_lshift::op1_range(irange&, tree_node*, irange const&, irange
const&) const
../../gcc-trunk/gcc/range-op.cc:1611
0x18e9398 gori_compute::compute_operand1_range(irange&, gimple*, irange const&,
tree_node*)
../../gcc-trunk/gcc/gimple-range-gori.cc:878
0x18eb2d3 gori_compute_cache::compute_operand_range(irange&, gimple*, irange
const&, tree_node*)
../../gcc-trunk/gcc/gimple-range-gori.cc:1271
0x18e9457 gori_compute::compute_operand1_range(irange&, gimple*, irange const&,
tree_node*)
../../gcc-trunk/gcc/gimple-range-gori.cc:903
0x18eb2d3 gori_compute_cache::compute_operand_range(irange&, gimple*, irange
const&, tree_node*)
../../gcc-trunk/gcc/gimple-range-gori.cc:1271
0x18e9d9d gori_compute::outgoing_edge_range_p(irange&, edge_def*, tree_node*)
../../gcc-trunk/gcc/gimple-range-gori.cc:1002
0x18e4b00 ranger_cache::iterative_cache_update(tree_node*)
../../gcc-trunk/gcc/gimple-range-cache.cc:636
0x18e5783 ranger_cache::fill_block_cache(tree_node*, basic_block_def*,
basic_block_def*)
../../gcc-trunk/gcc/gimple-range-cache.cc:873
0x18e5b7e ranger_cache::block_range(irange&, basic_block_def*, tree_node*,
bool)
../../gcc-trunk/gcc/gimple-range-cache.cc:589
0x18d8a00 gimple_ranger::range_on_entry(irange&, basic_block_def*, tree_node*)
../../gcc-trunk/gcc/gimple-range.cc:909
0x18d9384 gimple_ranger::range_of_expr(irange&, tree_node*, gimple*)
../../gcc-trunk/gcc/gimple-range.cc:880
0x18dbb27 gimple_ranger::range_of_range_op(irange&, gimple*)
../../gcc-trunk/gcc/gimple-range.cc:418
0x18e0203 gimple_ranger::calc_stmt(irange&, gimple*, tree_node*)
../../gcc-trunk/gcc/gimple-range.cc:369
0x18e09a9 gimple_ranger::range_of_stmt(irange&, gimple*, tree_node*)
../../gcc-trunk/gcc/gimple-range.cc:986
0x18d9485 gimple_ranger::range_of_expr(irange&, tree_node*, gimple*)
../../gcc-trunk/gcc/gimple-range.cc:877
0x104a61e range_query::value_of_expr(tree_node*, gimple*)
../../gcc-trunk/gcc/value-query.cc:85
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[597] %
[597] % cat small.c
int a;
long b;
unsigned int c = 1;
int main () {
int e;
for (; c <= 0; c++) {
int f = 0;
b = e;
a = f || b << c;
}
return 0;
}
[Bug c++/97468] New: gcc crashes when using __may_alias__ attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97468
Bug ID: 97468
Summary: gcc crashes when using __may_alias__ attribute
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tangyixuan at mail dot dlut.edu.cn
Target Milestone: ---
Hi, the following code uses '__attribute__ ((__may_alias__))' to alias a struct
'S' to 'a'. However, gcc crashes at compilation time while clang successfully
compiles.
gcc doc:
https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gcc/Common-Type-Attributes.html#Common-Type-Attributes
'Accesses through pointers to types with this attribute are not subject to
type-based alias analysis, but are instead assumed to be able to alias any
other type of objects.'
$ cat s.cpp
template struct S{};
auto __attribute__ ((__may_alias__)) a=S{};
$ g++ -c s.cpp
s.cpp:2:38: internal compiler error: in layout_type, at stor-layout.c:2618
2 | auto __attribute__ ((__may_alias__)) a=S{};
| ^
0x62d384 layout_type(tree_node*)
../../gcc-11-20201011/gcc/stor-layout.c:2618
0xebaf34 type_hash_canon(unsigned int, tree_node*)
../../gcc-11-20201011/gcc/tree.c:7140
0x7e6beb build_type_attribute_qual_variant(tree_node*, tree_node*, int)
../../gcc-11-20201011/gcc/attribs.c:1166
0x7e8702 build_type_attribute_variant(tree_node*, tree_node*)
../../gcc-11-20201011/gcc/attribs.c:1377
0x7e8702 decl_attributes(tree_node**, tree_node*, int, tree_node*)
../../gcc-11-20201011/gcc/attribs.c:794
0x6d9e93 cplus_decl_attributes(tree_node**, tree_node*, int)
../../gcc-11-20201011/gcc/cp/decl2.c:1595
0x6cd1bf start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../gcc-11-20201011/gcc/cp/decl.c:5267
0x7590ce cp_parser_init_declarator
../../gcc-11-20201011/gcc/cp/parser.c:20936
0x73a65c cp_parser_simple_declaration
../../gcc-11-20201011/gcc/cp/parser.c:13878
0x7630a6 cp_parser_declaration
../../gcc-11-20201011/gcc/cp/parser.c:13577
0x7636dd cp_parser_translation_unit
../../gcc-11-20201011/gcc/cp/parser.c:4793
0x7636dd c_parse_file()
../../gcc-11-20201011/gcc/cp/parser.c:44172
0x82f13d c_common_parse_file()
../../gcc-11-20201011/gcc/c-family/c-opts.c:1188
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug lto/94156] Multiple definition of destructor and non-virtual thunk for classes that use multiple inheritance when building static library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94156 Павел Тюнин changed: What|Removed |Added CC||pavel51tunin at gmail dot com --- Comment #2 from Павел Тюнин --- Created attachment 49391 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49391&action=edit minimal sample to reproduce the bug This sample triggers this or similar bug on both mingw 9.2.0 and mingw-w64 10.2.1. Compilation log: D:\test>g++ -O2 -flto -c test1.cpp D:\test>g++ -O2 -flto -c test2.cpp D:\test>g++ -flto -o test.exe test1.o test2.o D:/mingw-w64/mingw/bin/../lib/gcc/i686-w64-mingw32/10.2.1/../../../../i686-w64-m ingw32/bin/ld.exe: test2.o (symbol from plugin):(.gnu.linkonce.t._ZN7Derived3foo Ev[__ZThn4_N7Derived3fooEv]+0x0): multiple definition of `Derived::foo()'; test1 .o (symbol from plugin):(.gnu.linkonce.t._ZN7Derived3fooEv[__ZThn8_N7Derived3foo Ev]+0x0): first defined here D:/mingw-w64/mingw/bin/../lib/gcc/i686-w64-mingw32/10.2.1/../../../../i686-w64-m ingw32/bin/ld.exe: test2.o (symbol from plugin):(.gnu.linkonce.t._ZN7Derived3foo Ev[__ZThn4_N7Derived3fooEv]+0x0): multiple definition of `non-virtual thunk to D erived::foo()'; test1.o (symbol from plugin):(.gnu.linkonce.t._ZN7Derived3fooEv[ __ZThn8_N7Derived3fooEv]+0x0): first defined here D:/mingw-w64/mingw/bin/../lib/gcc/i686-w64-mingw32/10.2.1/../../../../i686-w64-m ingw32/bin/ld.exe: test2.o (symbol from plugin):(.gnu.linkonce.t._ZN7Derived3foo Ev[__ZThn4_N7Derived3fooEv]+0x0): multiple definition of `non-virtual thunk to D erived::foo()'; test1.o (symbol from plugin):(.gnu.linkonce.t._ZN7Derived3fooEv[ __ZThn8_N7Derived3fooEv]+0x0): first defined here collect2.exe: error: ld returned 1 exit status
[Bug rtl-optimization/97459] __uint128_t remainder for division by 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97459
--- Comment #4 from Thomas Koenig ---
Here's a complete program for benchmarks on x86_64, using Jakub's
functions (so they are indeed correct):
#include
#include
#include
#include
#include
#include
unsigned r3_128u_v2 (__uint128_t n)
{
return (unsigned) (n%3);
}
unsigned r3_128u_v3 (__uint128_t n)
{
unsigned long a;
a = (n >> 88);
a += (n >> 44) & 0xfffULL;
a += (n & 0xfffULL);
return a % 3;
}
unsigned r3_128u_v4 (__uint128_t n)
{
unsigned long a;
a = (n >> 96);
a += (n >> 64) & 0xULL;
a += (n >> 32) & 0xULL;
a += (n & 0xULL);
return a % 3;
}
#define N 100
int main()
{
__uint128_t *a;
unsigned int s;
unsigned long t1, t2;
int fd;
int i;
a = malloc (sizeof (*a) * N);
fd = open ("/dev/random", O_RDONLY);
read (fd, a, sizeof (*a) * N);
s = 0;
t1 = __rdtsc();
for (i=0; i
[Bug driver/97469] New: __attribute__ ((__target__ ("..."))) resets -mcmodel= values, breaks grub compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97469
Bug ID: 97469
Summary: __attribute__ ((__target__ ("..."))) resets -mcmodel=
values, breaks grub compilation
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Bug initially observed as a build failure on grub-2.04. There 32-bit PLT
relocations get generated against external unresolved symbols when
zstd_decompress.c is compiled in -mcmode=large mode.
The trigger seems to be '__attribute__((__target__("bmi2")))' that throws away
'-mcmode=large' commandline flag.
Here is the minimal example extracted (gcc-10 generates correct 'movabs/call
%reg' code, gcc-11 generates incorrect 'call ' code):
$ bash -x ./mk.bash
+ args=(-O1 -fno-asynchronous-unwind-tables -fno-ident -mcmodel=large -fno-PIE)
+ cat a.c
// grub builds zstd_decompress.c (zstd.module) in -mcmodel=large
// (and -freestanding) mode. grub assumes there will be no dynamic
// PLT relocations. grub_memmove() is symbol external (dynamic)
// to zstd.module.
extern void grub_memmove(void);
__attribute__((__target__("bmi2"))) void a_bmi(void) {
// expect:
// movabsq $grub_memmove, %rbx
// call*%rbx
// actual (bug):
// callgrub_memmove
for (;;)
grub_memmove();
}
void a_nobmi(void) {
// expect/actual:
// movabsq $grub_memmove, %rbx
// call*%rbx
for (;;)
grub_memmove();
}
+ gcc-10.2.0 -O1 -fno-asynchronous-unwind-tables -fno-ident -mcmodel=large
-fno-PIE -S a.c
+ cat a.s
.file "a.c"
.text
.globl a_bmi
.type a_bmi, @function
a_bmi:
pushq %rbx
movabsq $grub_memmove, %rbx
.L2:
call*%rbx
jmp .L2
.size a_bmi, .-a_bmi
.globl a_nobmi
.type a_nobmi, @function
a_nobmi:
pushq %rbx
movabsq $grub_memmove, %rbx
.L5:
call*%rbx
jmp .L5
.size a_nobmi, .-a_nobmi
.section.note.GNU-stack,"",@progbits
+ gcc-11.0.0 -O1 -fno-asynchronous-unwind-tables -fno-ident -mcmodel=large
-fno-PIE -S a.c
+ cat a.s
.file "a.c"
.text
.globl a_bmi
.type a_bmi, @function
a_bmi:
subq$8, %rsp
.L2:
callgrub_memmove
jmp .L2
.size a_bmi, .-a_bmi
.globl a_nobmi
.type a_nobmi, @function
a_nobmi:
pushq %rbx
movabsq $grub_memmove, %rbx
.L5:
call*%rbx
jmp .L5
.size a_nobmi, .-a_nobmi
.section.note.GNU-stack,"",@progbits
[Bug driver/97469] __attribute__ ((__target__ ("..."))) resets -mcmodel= values, breaks grub compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97469
--- Comment #1 from Sergei Trofimovich ---
Reading
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes
it's not very clear if __attribute__((__target__("..."))) should throw away all
existing -m* command line options or should appends to existing ones.
[Bug go/68931] gccgo fails to build using MUSL libc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68931 Daniel Santos changed: What|Removed |Added CC||daniel.santos at pobox dot com --- Comment #4 from Daniel Santos --- Hello. This is still a problem in 10.2 and I'm definitely going to need to solve this. As near as I can tell, the underlying issue is libgo/config.h incorrectly being populated with HAVE_OFF64_T. configure:11206: checking for off64_t configure:11206: /home/daniel/proj/embedded/openwrt/head/build_dir/toolchain-mipsel_24kc_gcc-10.2.0_musl/gcc-10.2.0-final/./gcc/xgcc -B/home/daniel/proj/embedded/openwrt/head/build_dir/toolchain-mipsel_24kc_gcc-10.2.0_musl/gcc-10.2.0-final/./gcc/ -B/home/daniel/proj/embedded/openwrt/head/staging_dir/toolchain-mipsel_24kc_gcc-10.2.0_musl/mipsel-openwrt-linux-musl/bin/ -B/home/daniel/proj/embedded/openwrt/head/staging_dir/toolchain-mipsel_24kc_gcc-10.2.0_musl/mipsel-openwrt-linux-musl/lib/ -isystem /home/daniel/proj/embedded/openwrt/head/staging_dir/toolchain-mipsel_24kc_gcc-10.2.0_musl/mipsel-openwrt-linux-musl/include -isystem /home/daniel/proj/embedded/openwrt/head/staging_dir/toolchain-mipsel_24kc_gcc-10.2.0_musl/mipsel-openwrt-linux-musl/sys-include -c -Os -pipe -mno-branch-likely -mips32r2 -mtune=24kc -g3 -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -msoft-float -Wformat -Werror=format-security -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE conftest.c >&5 configure:11206: $? = 0 configure:11206: /home/daniel/proj/embedded/openwrt/head/build_dir/toolchain-mipsel_24kc_gcc-10.2.0_musl/gcc-10.2.0-final/./gcc/xgcc -B/home/daniel/proj/embedded/openwrt/head/build_dir/toolchain-mipsel_24kc_gcc-10.2.0_musl/gcc-10.2.0-final/./gcc/ -B/home/daniel/proj/embedded/openwrt/head/staging_dir/toolchain-mipsel_24kc_gcc-10.2.0_musl/mipsel-openwrt-linux-musl/bin/ -B/home/daniel/proj/embedded/openwrt/head/staging_dir/toolchain-mipsel_24kc_gcc-10.2.0_musl/mipsel-openwrt-linux-musl/lib/ -isystem /home/daniel/proj/embedded/openwrt/head/staging_dir/toolchain-mipsel_24kc_gcc-10.2.0_musl/mipsel-openwrt-linux-musl/include -isystem /home/daniel/proj/embedded/openwrt/head/staging_dir/toolchain-mipsel_24kc_gcc-10.2.0_musl/mipsel-openwrt-linux-musl/sys-include -c -Os -pipe -mno-branch-likely -mips32r2 -mtune=24kc -g3 -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -msoft-float -Wformat -Werror=format-security -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE conftest.c >&5 conftest.c: In function 'main': conftest.c:146:22: error: expected expression before ')' token 146 | if (sizeof ((off64_t))) | ^ configure:11206: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "package-unused" | #define PACKAGE_TARNAME "libgo" | #define PACKAGE_VERSION "version-unused" | #define PACKAGE_STRING "package-unused version-unused" | #define PACKAGE_BUGREPORT "" | #define PACKAGE_URL "" | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_DLFCN_H 1 | #define LT_OBJDIR ".libs/" | #define USE_LIBFFI 1 | #define HAVE_GETIPINFO 1 | #define HAVE_SCHED_H 1 | #define HAVE_SEMAPHORE_H 1 | #define HAVE_SYS_FILE_H 1 | #define HAVE_SYS_MMAN_H 1 | #define HAVE_SYSCALL_H 1 | #define HAVE_SYS_EPOLL_H 1 | #define HAVE_SYS_INOTIFY_H 1 | #define HAVE_SYS_PTRACE_H 1 | #define HAVE_SYS_SYSCALL_H 1 | #define HAVE_SYS_USER_H 1 | #define HAVE_SYS_UTSNAME_H 1 | #define HAVE_SYS_SELECT_H 1 | #define HAVE_SYS_SOCKET_H 1 | #define HAVE_NET_IF_H 1 | #define HAVE_NET_IF_ARP_H 1 | #define HAVE_NET_ROUTE_H 1 | #define HAVE_NETPACKET_PACKET_H 1 | #define HAVE_SYS_PRCTL_H 1 | #define HAVE_SYS_MOUNT_H 1 | #define HAVE_SYS_VFS_H 1 | #define HAVE_SYS_STATFS_H 1 | #define HAVE_SYS_TIMEX_H 1 | #define HAVE_SYS_SYSINFO_H 1 | #define HAVE_UTIME_H 1 | #define HAVE_LINUX_FS_H 1 | #define HAVE_LINUX_PTRACE_H 1 | #define HAVE_LINUX_REBOOT_H 1 | #define HAVE_NETINET_IP_H 1 | #define HAVE_NETINET_IF_ETHER_H 1 | #define HAVE_NETINET_ICMP6_H 1 | #define HAVE_LINUX_FILTER_H 1 | #define HAVE_LINUX_IF_ADDR_H 1 | #define HAVE_LINUX_IF_ETHER_H 1 | #define HAVE_LINUX_IF_TUN_H 1 | #define HAVE_LINUX_NETLINK_H 1 | #define HAVE_LINUX_RTNETLINK_H 1 | #define HAVE_STRERROR_R 1 | #define HAVE_STRSIGNAL 1 | #define HAVE_WAIT4 1 | #define HAVE_MINCORE 1 | #define HAVE_SETENV 1 | #define HAVE_UNSETENV 1 | #define HAVE_DL_ITERATE_PHDR 1 | #define HAVE_MEMMEM 1 | #define HAVE_ACCEPT4 1 | #define HAVE_DUP3 1 | #define HAVE_EPOLL_CREATE1 1 | #define HAVE_FACCESSAT 1 | #define HAVE_FALLOCATE 1 | #define HAVE_FCHMODAT 1 | #define HAVE_FCHOWNAT 1 | #define HAVE_FUTIMESAT 1 | #defi
[Bug fortran/97380] polymorphic array assignment for `PACK`: ICE and runtime segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97380 --- Comment #3 from federico --- Created attachment 49392 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49392&action=edit Other test program highlights issue in accessing polymorphic arrays with arrays
[Bug fortran/97380] polymorphic array assignment for `PACK`: ICE and runtime segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97380
--- Comment #4 from federico ---
I've attached another program that perhaps highlights the problem better.
Even just *accessing* a polymorphic array with an array causes wrong output
with gfortran 9.2.0:
The attached program sends elements [3,6,9] in a polymorphic array to a
subroutine, which should then print some info: their ID in the original array.
Instead of printing 3,6,9, it prints 3,4,5 when the input array was
polymorphic:
module m
implicit none
type, public :: t
integer :: i = 1
end type t
type, public, extends(t) :: tt
integer :: j
end type tt
contains
subroutine print_array(x,msg)
class(t), intent(in) :: x(:)
character(*), intent(in) :: msg
integer :: j
print *, msg//' :: size(x)=',size(x)
select type (xx=>x(:))
type is (t)
do j=1,size(xx)
print *, 'x(',j,')%i = ',xx(j)%i
end do
type is (tt)
do j=1,size(xx)
print *, 'x(',j,')%i = ',xx(j)%i,' %j=',xx(j)%j
end do
end select
end subroutine print_array
end module m
program test_poly_access_array
use m
implicit none
class(t), allocatable :: poly_t(:),poly_tt(:)
type (t), allocatable :: nonpoly_t (:)
type(tt), allocatable :: nonpoly_tt(:)
integer :: i
integer, dimension(3) :: chunk = [3,6,9]
allocate(t :: poly_t( 10))
allocate(tt :: poly_tt(10))
allocate( nonpoly_t(10),nonpoly_tt(10))
do i=1,10
poly_t(i)%i = i
poly_tt(i)%i = i
select type (ptt=>poly_tt(:))
type is (tt)
ptt(i)%j = i
end select
nonpoly_t(i)%i = i
nonpoly_tt(i)%i = i
nonpoly_tt(i)%j = i
end do
call print_array(nonpoly_t(chunk),'nonpoly_t')
call print_array(nonpoly_tt(chunk),'nonpoly_tt')
call print_array(poly_t(chunk),'poly_t')
call print_array(poly_tt(chunk),'poly_tt')
end program test_poly_access_array
Output is:
nonpoly_t :: size(x)= 3 ! Non-polymorphic, base type: OK
x( 1 )%i =3
x( 2 )%i =6
x( 3 )%i =9
nonpoly_tt :: size(x)= 3 ! Non-polymorphic, extended type: OK
x( 1 )%i =3 %j= 3
x( 2 )%i =6 %j= 6
x( 3 )%i =9 %j= 9
poly_t :: size(x)= 3 ! Polymorphic, base type: WRONG
x( 1 )%i =3
x( 2 )%i =4
x( 3 )%i =5
poly_tt :: size(x)= 3! Polymorphic, extended type: WRONG
x( 1 )%i =3 %j= 3
x( 2 )%i =4 %j= 4
x( 3 )%i =5 %j= 5
[Bug lto/94156] Multiple definition of destructor and non-virtual thunk for classes that use multiple inheritance when building static library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94156 --- Comment #3 from Michał Urbański --- I confirm that attached test files reproduce the bug for me - same error messages. Thanks Pavel, never expeced someone to manage to reproduce this problem.
[Bug c++/97470] New: ICE when using aggregate initialization of a particular layout with non trivial type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97470
Bug ID: 97470
Summary: ICE when using aggregate initialization of a
particular layout with non trivial type
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gufideg at gmail dot com
Target Milestone: ---
Here's a minimal case:
struct nontrivial {
nontrivial();
nontrivial(nontrivial const&);
long a;
};
struct foo {
nontrivial nt;
char b;
};
struct bar : foo {};
foo get_foo();
bar a{
get_foo()
};
Live ICE on compiler explorer: https://godbolt.org/z/WqnWY9
Changing `a` to something with a smaller size won't trigger the ICE.
Changing `b` to something with the same size of `a` won't trigger the ICE.
Changing `bar a{get_foo()}` to `bar a{foo{}}` won't trigger the ICE.
Swapping the members of foo will also make the ICE go away.
[Bug go/68931] gccgo fails to build using MUSL libc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68931 --- Comment #5 from Daniel Santos --- Created attachment 49393 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49393&action=edit Patch for musl compatibility The root problem is that musl defines off64_t and loff_t as preprocessor macros. These end up in gen-sysinfo.go as "// undefinedmacro" entries. Perhaps the real solution would be for -fdump-go-spec to attempt to determine when a macro is for a type? There is also a problem currently with struct sysinfo being defined multiple times due to musl defining it in sys/sysinfo.h instead of including linux/sysinfo.h -- I've just altered the musl header for now.
[Bug preprocessor/97471] New: ICE on using function-like macro as a non function-like macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97471 Bug ID: 97471 Summary: ICE on using function-like macro as a non function-like macro Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: gabravier at gmail dot com Target Milestone: --- #define a() b a This crashes GCC's preprocessor on current trunk (as of the 16th), with this message : :2:1: internal compiler error: Segmentation fault 2 | a | ^ 0x19720a9 internal_error(char const*, ...) ???:0 0x19b406f _cpp_lex_direct ???:0 0x19b5ab5 _cpp_lex_token ???:0 0x77c4c0 c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int) ???:0 0x6eb1ae c_parser_peek_2nd_token(c_parser*) ???:0 0x721b39 c_parse_file() ???:0 0x78bdf2 c_common_parse_file() ???:0 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. Compiler returned: 1 GCC -v output : Using built-in specs. COLLECT_GCC=/opt/compiler-explorer/gcc-snapshot/bin/gcc Target: x86_64-linux-gnu Configured with: ../gcc-trunk-20201017/configure --prefix=/opt/compiler-explorer/gcc-build/staging --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap --enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --enable-clocale=gnu --enable-languages=c,c++,fortran,ada,d --enable-ld=yes --enable-gold=yes --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-linker-build-id --enable-lto --enable-plugins --enable-threads=posix --with-pkgversion=Compiler-Explorer-Build Thread model: posix Supported LTO compression algorithms: zlib gcc version 11.0.0 20201016 (experimental) (Compiler-Explorer-Build) COLLECT_GCC_OPTIONS='-fdiagnostics-color=always' '-g' '-o' './output.s' '-masm=intel' '-S' '-v' '-mtune=generic' '-march=x86-64' '-dumpdir' './' /opt/compiler-explorer/gcc-trunk-20201017/bin/../libexec/gcc/x86_64-linux-gnu/11.0.0/cc1 -quiet -v -imultiarch x86_64-linux-gnu -iprefix /opt/compiler-explorer/gcc-trunk-20201017/bin/../lib/gcc/x86_64-linux-gnu/11.0.0/ -quiet -dumpdir ./ -dumpbase output.c -dumpbase-ext .c -masm=intel -mtune=generic -march=x86-64 -g -version -fdiagnostics-color=always -o ./output.s GNU C17 (Compiler-Explorer-Build) version 11.0.0 20201016 (experimental) (x86_64-linux-gnu) compiled by GNU C version 7.5.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 ignoring nonexistent directory "/opt/compiler-explorer/gcc-trunk-20201017/bin/../lib/gcc/x86_64-linux-gnu/11.0.0/../../../../x86_64-linux-gnu/include" ignoring duplicate directory "/opt/compiler-explorer/gcc-trunk-20201017/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/11.0.0/include" ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring duplicate directory "/opt/compiler-explorer/gcc-trunk-20201017/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/11.0.0/include-fixed" ignoring nonexistent directory "/opt/compiler-explorer/gcc-trunk-20201017/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/11.0.0/../../../../x86_64-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /opt/compiler-explorer/gcc-trunk-20201017/bin/../lib/gcc/x86_64-linux-gnu/11.0.0/include /opt/compiler-explorer/gcc-trunk-20201017/bin/../lib/gcc/x86_64-linux-gnu/11.0.0/include-fixed /usr/local/include /opt/compiler-explorer/gcc-trunk-20201017/bin/../lib/gcc/../../include /usr/include/x86_64-linux-gnu /usr/include End of search list. GNU C17 (Compiler-Explorer-Build) version 11.0.0 20201016 (experimental) (x86_64-linux-gnu) compiled by GNU C version 7.5.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 129d0909b5f5d2346755498e10395559
[Bug c/97445] Some fonctions marked static inline in Linux kernel are not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445 --- Comment #7 from Christophe Leroy --- With get_order(), that's even worse: there are instances of it that are never called: c000f94c : c005a7ac : c005a9c4: 4b ff fd e9 bl c005a7ac c005ab38: 4b ff fc 75 bl c005a7ac c005ac50: 4b ff fb 5d bl c005a7ac c005b540 : c005b588: 4b ff ff b9 bl c005b540 c0074fe4 : c00815c8 : c00b8690 : c00ba898: 4b ff dd f9 bl c00b8690 c00ba9d4: 4b ff dc bd bl c00b8690 c00bd650 : c00c3cbc: 4b ff 99 95 bl c00bd650 c00c3e90: 4b ff 97 c1 bl c00bd650 c00cfd08 : c00d02a8: 4b ff fa 61 bl c00cfd08 c00d0310: 4b ff f9 f9 bl c00cfd08 c00d0ac8: 4b ff f2 41 bl c00cfd08 c00d0c90: 4b ff f0 79 bl c00cfd08 c00d0d60: 4b ff ef a9 bl c00cfd08 c00d0dcc: 4b ff ef 3d bl c00cfd08 c00d0e10: 4b ff ee f9 bl c00cfd08 c00d10ac: 4b ff ec 5d bl c00cfd08 c00d19e4: 4b ff e3 25 bl c00cfd08 c00d4fa4: 4b ff ad 65 bl c00cfd08 c00d5cb4: 4b ff a0 55 bl c00cfd08 c00d5cc0: 4b ff a0 49 bl c00cfd08 c00d60fc: 4b ff 9c 0d bl c00cfd08 c00e9c70 : c0114b50 : c013643c : c013a520 : c013b3f4: 4b ff f1 2d bl c013a520 c013b40c: 4b ff f1 15 bl c013a520 c013b438: 4b ff f0 e9 bl c013a520 c013b454: 4b ff f0 cd bl c013a520 c014236c: 4b ff 81 b5 bl c013a520 c01423d4: 4b ff 81 4d bl c013a520 c0150ae8 : c015b968 : c0162040 : c016a710 : c0182aec : c01abe78 : c01cd598 : c01d2764 : c01ee3e0 : c01fea40 : c020bfd4 : c021cd80 : c021e510 : c02204b4 : c0225534 : c0228bec : c022c5a4 : c0231100 : c02314c0: 4b ff fc 41 bl c0231100 c02537a8 : c025a620 : c025d6bc: 4b ff cf 65 bl c025a620 c025d750: 4b ff ce d1 bl c025a620 c0270144 : c0287110 : c028717c: 4b ff ff 95 bl c0287110 c02871f0: 4b ff ff 21 bl c0287110 c028f3b8 : c029fa00 : c02a3ae0: 4b ff bf 21 bl c029fa00 c02a4c68: 4b ff ad 99 bl c029fa00 c02a5020: 4b ff a9 e1 bl c029fa00 c02a520c: 4b ff a7 f5 bl c029fa00 c02a5644: 4b ff a3 bd bl c029fa00 c02ad00c : c02ad0c0: 4b ff ff 4d bl c02ad00c c02b4ce0 : c02ba234 : c02bd758 : c02c292c : c02ccd00 : c0326dcc : c0327fc4: 4b ff ee 09 bl c0326dcc c032836c: 4b ff ea 61 bl c0326dcc c0328784: 4b ff e6 49 bl c0326dcc c0328810: 4b ff e5 bd bl c0326dcc c0328860: 4b ff e5 6d bl c0326dcc c032a754 : c03335d4 : c033c37c : c033e4ac: 4b ff de d1 bl c033c37c c033e4bc: 4b ff de c1 bl c033c37c c03447b4 : c0345cf8: 4b ff ea bd bl c03447b4 c035a3fc : c0362694 : c0375710 : c041ab78: 4b ca 2a d9 bl c00bd650 c0429068: 4b c9 45 e9 bl c00bd650
[Bug c/97445] Some fonctions marked static inline in Linux kernel are not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97445 --- Comment #8 from Christophe Leroy --- (In reply to Jakub Jelinek from comment #1) > See https://gcc.gnu.org/bugs.html, you haven't provided either preprocessed > source, nor gcc command line options. > inline keyword itself is not a guarantee that the function will be inlined, > it is inlined if it is possible and seems beneficial to the inlining > heuristics. > If you want to always inline, use __attribute__((always_inline)) in addition > to inline keyword. When adding -save-temps as explained in https://gcc.gnu.org/bugs.html I get an error: powerpc64-linux-gcc -Wp,-MMD,fs/.pipe.o.d -nostdinc -isystem /home/opt/gcc-10.1.0-nolibc/powerpc64-linux/bin/../lib/gcc/powerpc64-linux/10.1.0/include -I./arch/powerpc/include -I./arch/powerpc/include/generated -I./include -I./arch/powerpc/include/uapi -I./arch/powerpc/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -I ./arch/powerpc -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration -Werror=implicit-int -Wno-format-security -std=gnu89 -mcpu=powerpc -m32 -msoft-float -pipe -ffixed-r2 -mmultiple -mno-readonly-in-sdata -mcpu=860 -mno-altivec -mno-vsx -fno-asynchronous-unwind-tables -mno-string -mbig-endian -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-address-of-packed-member -O2 -fno-allow-store-data-races -Wframe-larger-than=1024 -fno-stack-protector -Wno-unused-but-set-variable -Wimplicit-fallthrough -Wno-unused-const-variable -fomit-frame-pointer -fno-var-tracking-assignments -g -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wno-stringop-truncation -Wno-zero-length-bounds -Wno-array-bounds -Wno-stringop-overflow -Wno-restrict -Wno-maybe-uninitialized -fno-strict-overflow -fno-merge-all-constants -fmerge-constants -fno-stack-check -fconserve-stack -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -fmacro-prefix-map=./= -Wno-packed-not-aligned-DKBUILD_MODFILE='"fs/pipe"' -DKBUILD_BASENAME='"pipe"' -DKBUILD_MODNAME='"pipe"' -c -o fs/pipe.o fs/pipe.c -save-temps powerpc64-linux-gcc.br_real: warning: -pipe ignored because -save-temps specified powerpc64-linux-gcc.br_real: error: unrecognized command line option ‘-fno-allow-store-data-races’
[Bug tree-optimization/97466] ICE in vect_get_and_check_slp_defs, at tree-vect-slp.c:538 (at -O3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97466 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #1 from David Binderman --- I also see this when I bootstrap gcc with -O3.
[Bug c++/97470] ICE when using aggregate initialization of a particular layout with non trivial type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97470 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Marek Polacek --- Already fixed by r11-2704.
[Bug target/95294] [vax] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95294 Maciej W. Rozycki changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED CC||ma...@linux-mips.org Target Milestone|--- |11.0 Assignee|unassigned at gcc dot gnu.org |ma...@linux-mips.org Ever confirmed|0 |1 Last reconfirmed||2020-10-17
[Bug c/97472] New: Another EVRP problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97472
Bug ID: 97472
Summary: Another EVRP problem
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C source code:
int a, b;
void c() {
short d = 0;
for (;;) {
d ?: c;
d |= b;
a = d ? d &= 0 : 0;
}
}
and compiler flag -O2, I get with recent gcc trunk:
$ /home/dcb/gcc/results/bin/gcc -c -O2 -w bug655.c
bug655.c: In function ‘c’:
bug655.c:9:1: error: invalid types in nop conversion
9 | }
| ^
long int
<<< error >>>
_1 = (long int) _4;
during GIMPLE pass: evrp
[Bug c++/94161] Implement DR 228: Use of template keyword with non-member templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94161 --- Comment #1 from Marek Polacek --- This compiles since r11-86.
[Bug other/97473] New: Spilled function parameters not aligned properly on multiple non-x86 targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97473
Bug ID: 97473
Summary: Spilled function parameters not aligned properly on
multiple non-x86 targets
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: nate at thatsmathematics dot com
Target Milestone: ---
Created attachment 49394
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49394&action=edit
Test case
Suppose we have a type V requiring alignment, such as with
__attribute__((aligned(N))). In current versions of gcc, both 10.2 and recent
trunk, it appears that local (auto) variables of this type are properly aligned
on the stack, at least on all the targets I tested. However, on many targets
other than x86, alignment is apparently not respected for function parameters
of this type when their address is taken.
The function parameter may actually be passed in a register, in which case when
its address is taken, it must be spilled to the stack. But on the failing
targets, the spilled copy is not sufficiently aligned, and so for instance,
other functions which receive a pointer to this variable will find it does not
have the alignment that it should.
I'm not sure if this is a bug or a limitation, but it's quite counterintuitive,
since function parameters generally can be treated like local variables for
most other purposes. I couldn't find any mention of this in the documentation
or past bug reports.
This can be reproduced by a very short C example like the following:
typedef int V __attribute__((aligned(64)));
void g(V *);
void f(V x) {
g(&x);
}
The function g can get a pointer that is not aligned to 64 bytes. A more
complete test case is attached, which I tested mainly on ARM and AArch64 with
gcc 10.2 and also trunk. It seems to happen with or without optimization, so
long as one prevents IPA of g. Inspection of the assembly shows gcc does not
generate any code to align the objects beyond the stack alignment guaranteed by
the ABI (8 bytes for ARM, 16 bytes for AArch64).
It fails on (complete gcc -v output below):
- aarch64-linux-gnu 10.2.0 and trunk from today
- arm-linux-gnueabihf 10.2.0 and trunk from last week
- alpha-linux-gnu 10.2.0
- sparc64-linux-gnu 10.2.0
- mips-linux-gnu 10.2.0
It succeeds on:
- x86_64-linux-gnu 10.2.0, also with -m32
On x86_64-linux-gnu, gcc generates instructions to align the stack and place
the spilled copy of x at an aligned address, and the testcase passes there.
(Perhaps this was implemented to support AVX?) With -m32 it copies x from its
original unaligned position on the stack into an aligned stack slot.
As noted, auto variables of the same type do get proper alignment on all the
platforms I tested, and so one can work around with `V tmp = x; g(&tmp);`.
For what it's worth, clang on ARM and AArch64 does align the spilled copies.
I was not sure which pass of the compiler is responsible for this so I just
chose component "other". I didn't think "target" was appropriate as this
affects many targets, though not all.
This issue was brought to my attention by StackOverflow user Alf (thanks!), see
https://stackoverflow.com/questions/64287587/memory-alignment-issues-with-gcc-vector-extension-and-arm-neon.
Alf's original program was in C++ for ARM32 with NEON and the hard-float ABI,
and involved mixing functions that passed vector types (like int32x4_t) either
by value or by by reference. In this setting they can be passed by value in
SIMD registers, but in memory they require 16-byte alignment. This was
violated, resulting in bus errors at runtime. So there is "real life" code
affected by this.
I tried including full `gcc -v` output from all versions tested, but it seems
to be triggering the bugzilla spam filter, so I'm omitting it. Hopefully it
isn't needed, but let me know if it is.
[Bug libstdc++/97449] [11 Regression] libstdc++ cannot be compiled with clang after 3427e31331677ca826c5588c87924214f7e5c54b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97449 --- Comment #3 from CVS Commits --- The master branch has been updated by Ville Voutilainen : https://gcc.gnu.org/g:1f65bf2aa65609c0cd88af1b83191d37d6729f46 commit r11-4024-g1f65bf2aa65609c0cd88af1b83191d37d6729f46 Author: Ville Voutilainen Date: Sat Oct 17 22:08:50 2020 +0300 libstdc++: Fix visitor return type diagnostics [PR97449] libstdc++-v3/ChangeLog: PR libstdc++/97449 * include/std/variant (__gen_vtable_impl<>::_S_apply_single_alt): Diagnose visitor return type mismatches here.. (__gen_vtable_impl::_S_apply): ..not here.
[Bug libstdc++/97449] [11 Regression] libstdc++ cannot be compiled with clang after 3427e31331677ca826c5588c87924214f7e5c54b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97449 Ville Voutilainen changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Ville Voutilainen --- Fixed.
[Bug c++/97474] New: Regression: optimization produces wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97474
Bug ID: 97474
Summary: Regression: optimization produces wrong code
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sfranzen85 at hotmail dot com
Target Milestone: ---
While searching for something different I found the following example code
demonstrating a possible gcc bug:
---
#include
using std::cout;
struct A {
int a;
int& b;
A(int x) : a(x), b(a) {}
A(const A& other) : a(other.a), b(a) {}
A() : a(0), b(a) {}
};
int foo(A a) {
a.a *= a.b;
return a.b;
}
int main() {
A a(3);
cout << foo(a) << '\n';
return 0;
}
---
(Source:
https://stackoverflow.com/questions/62853805/why-does-modifying-a-field-that-is-referenced-by-another-variable-lead-to-unexpe)
I was unable to find a related bug report, hence this one. Wrong output (3
instead of 9) is produced with -O1 or higher, since gcc version 6.4, as
mentioned in a comment. Indeed gcc trunk on godbolt still generates faulty
code: https://godbolt.org/z/TcedxE.
[Bug c++/97474] Regression: optimization produces wrong code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97474 --- Comment #1 from Andrew Pinski --- This feels like an use after something goes out of scope.
[Bug tree-optimization/97474] [8/9/10/11 Regression] produces wrong code with references to another field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97474
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2020-10-17
Ever confirmed|0 |1
Summary|Regression: optimization|[8/9/10/11 Regression]
|produces wrong code |produces wrong code with
||references to another field
Component|c++ |tree-optimization
Keywords||alias
Target Milestone|--- |8.5
Status|UNCONFIRMED |NEW
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> This feels like an use after something goes out of scope.
It is not, there is some weird aliasing issue.
The IR looks like:
int foo(A) (struct A & restrict a)
{
int _1;
int & _2;
int _3;
int _4;
int & _5;
int _9;
[0.00%]:
_1 = *a_7(D).a;
_2 = *a_7(D).b;
_3 = *_2;
_4 = _1 * _3;
*a_7(D).a = _4;
_5 = *a_7(D).b;
_9 = *_5;
return _9;
}
For some reason we think _5 cannot alias (*a_7(D)).a. Most likely due to the
restict in the IR. The restrict is there because a was passed by value rather
than reference but the way the ABI works, it is passed by a temp struct and we
expose this in the IR. All things go down hill from there.
[Bug tree-optimization/97474] [8/9/10/11 Regression] produces wrong code with references to another field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97474 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Started with r7-70-g8270b82dd6523937110a2488194d8692a09299f5
[Bug c++/97475] New: An unnamed class with a typedef name for linkage purposes having a method.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97475
Bug ID: 97475
Summary: An unnamed class with a typedef name for linkage
purposes having a method.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anders.granlund.0 at gmail dot com
Target Milestone: ---
Consider the following c++ program:
typedef struct {
void f();
} X;
int main()
{
}
It is not rejected by the compiler when compiling with "-std=c++20
-pedantic-errors".
The expected behaviour is that it should be rejected by section 9.2.3 paragraph
10 in the c++ 20 standard:
"
10 An unnamed class with a typedef name for linkage purposes shall not
(10.1) — declare any members other than non-static data members, member
enumerations, or member classes,
(10.2) — have any base classes or default member initializers, or
(10.3) — contain a lambda-expression,
and all member classes shall also satisfy these requirements (recursively).
"
Note that clang correctly does reject the program:
https://godbolt.org/z/rTerza
[Bug c++/93085] ICE in get_class_binding_direct and alias_ctad_tweaks, with C++20 NTTP + CTAD + alias template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93085 Johel Ernesto Guerrero Peña changed: What|Removed |Added CC||johelegp at gmail dot com --- Comment #2 from Johel Ernesto Guerrero Peña --- Invalid because it passes (a) type template argument(s) to a template template parameter.
[Bug c++/97476] New: Use of NTTP placeholder checked for CTAD before instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97476
Bug ID: 97476
Summary: Use of NTTP placeholder checked for CTAD before
instantiation
Product: gcc
Version: 11.0
URL: https://godbolt.org/z/ocWhn8
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: johelegp at gmail dot com
CC: johelegp at gmail dot com
Target Milestone: ---
See the URL.
```C++
template struct S { };
template class C { };
template using A = C;
```
[93083](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93083) may be a duplicate
of this.
[Bug c++/97477] New: g++ doesn't accept __restrict keyword inside array function parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97477
Bug ID: 97477
Summary: g++ doesn't accept __restrict keyword inside array
function parameter
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dwwork at gmail dot com
Target Milestone: ---
I was looking into how gcc treats the restrict keyword, when I discovered a
case that g++ does not accept using the __restrict gnu extension keyword.
The following function, compiled with gcc 10.2, and flags "-O3 -mavx", produces
vectorized assembly:
void func(const float a[restrict 3][8], const float b[restrict 3][8], float
c[restrict 3][8])
{
a = __builtin_assume_aligned(a,32);
b = __builtin_assume_aligned(b,32);
c = __builtin_assume_aligned(c,32);
for(int i=0; i<8; i++) {
c[0][i] = a[0][i] + b[0][i];
c[1][i] = a[1][i] + b[1][i];
c[2][i] = a[2][i] + b[2][i];
}
}
The restrict keyword inside the square brackets is legal according to
cppreference: https://en.cppreference.com/w/c/language/restrict
I then tested g++ 10.2, changing the restrict keyword to __restrict. This does
not compile:
void func(const float a[__restrict 3][8], const float b[__restrict 3][8], float
c[__restrict 3][8])
{
a = __builtin_assume_aligned(a,32);
b = __builtin_assume_aligned(b,32);
c = __builtin_assume_aligned(c,32);
for(int i=0; i<8; i++) {
c[0][i] = a[0][i] + b[0][i];
c[1][i] = a[1][i] + b[1][i];
c[2][i] = a[2][i] + b[2][i];
}
}
It gives me the following error (edited for brevity):
error: expected primary-expression before '__restrict'
error: expected ']' before '__restrict'
error: expected ')' before '__restrict'
error: expected initializer before numeric constant
I can get g++ to output vectorized code if I change the types to a pointer of
float[8]:
void func(const float (* __restrict a)[8], const float (* __restrict b)[8],
float (* __restrict c)[8])
{
a = static_cast( __builtin_assume_aligned(a,32) );
b = static_cast( __builtin_assume_aligned(b,32) );
c = static_cast< float (*)[8]>( __builtin_assume_aligned(c,32) );
for(int i=0; i<8; i++) {
c[0][i] = a[0][i] + b[0][i];
c[1][i] = a[1][i] + b[1][i];
c[2][i] = a[2][i] + b[2][i];
}
}
It's not a serious bug, but I do feel it is inconsistent.
I did browse the source code a bit to investigate, but I was way over my head.
[Bug c++/93085] ICE in get_class_binding_direct and alias_ctad_tweaks, with C++20 NTTP + CTAD + alias template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93085
--- Comment #3 from Arthur O'Dwyer ---
Re comment 2: My original test code was "invalid-code", but here's one I
believe to be "valid-code" in C++20.
// https://godbolt.org/z/dqcWeq
template class A>
struct G {
template using B = A;
template static int foo();
template static int foo();
int x = foo<42>(); // OK
};
test.cc:7:21: internal compiler error: in get_class_binding_direct, at
cp/name-lookup.c:1238
7 | int x = foo<42>(); // OK
| ^
If you change the `` to an ``, the ICE disappears, but GCC still gives a
bogus error at template-definition time:
// https://godbolt.org/z/Tjrnzv
template class A>
struct G {
template using B = A;
template static int foo();// #1
template static int foo(); // #2
int x = foo<42>(); // OK
};
test.cc:7:21: error: call of overloaded 'foo()' is ambiguous
7 | int x = foo<42>(); // OK
| ^
GCC shouldn't even be trying to resolve `foo<42>()` until `G` has been
instantiated; and once `G` has been instantiated with some specific `A`, this
call may or may not be ambiguous (depending on whether it's possible to deduce
the template arguments to foo #1 or not).
[Bug c++/93085] ICE in get_class_binding_direct and alias_ctad_tweaks, with C++20 NTTP + CTAD + alias template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93085 --- Comment #4 from Johel Ernesto Guerrero Peña --- > GCC shouldn't even be trying to resolve `foo<42>()` until `G` has been > instantiated. That's right. I came across this bug report when reporting such an issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97476.
