[Bug tree-optimization/101466] Optimizers should fold bounds checking for -D_GLIBCXX_ASSERTIONS=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101466
--- Comment #12 from Richard Biener ---
(In reply to Richard Biener from comment #11)
> With some hand-waving we could generate
>
> void square(unsigned t, int *tt)
> {
> if (t<=4) __builtin_abort();
> tt[0] = 0;
> tt[1] = 0;
> tt[2] = 0;
> tt[3] = 0;
> tt[4] = 0;
> }
>
> but I don't see how it fits any existing transform? The "hand-waving"
> would be that __builtin_abort () since it's a known function cannot
> observe the dropped side-effects like tt[0] = 0 when t > 0.
That is, we'd sink the stores across the abort ()s because they are
not uses of them, then we arrive at
if (t<=0) __builtin_abort();
if (t<=1) __builtin_abort();
if (t<=2) __builtin_abort();
if (t<=3) __builtin_abort();
if (t<=4) __builtin_abort();
tt[0] = 0;
tt[1] = 0;
tt[2] = 0;
tt[3] = 0;
tt[4] = 0;
where we'd somehow "thread" to a single condition (PRE tail merging
merges the abort () blocks and reassoc way after it manages to merge
the controlling conditions).
[Bug middle-end/95681] False positive uninitialized variable usage in decNumberCompareTotalMag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95681 --- Comment #3 from Stefan Schulze Frielinghaus --- Created attachment 51160 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51160&action=edit Reduced program
[Bug middle-end/95681] False positive uninitialized variable usage in decNumberCompareTotalMag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95681 --- Comment #4 from Stefan Schulze Frielinghaus --- Running todays mainline (d97d71a1989) using options -O3 -Wall against the reduced program on x86 as well as s390x results in t.c: In function 'decNumberCompareTotalMag': t.c:55:14: warning: '*allocbufa.bits' may be used uninitialized [-Wmaybe-uninitialized] 55 | a->bits&=~0x80; | ^~ t.c:70:14: warning: '*allocbufb.bits' may be used uninitialized [-Wmaybe-uninitialized] 70 | b->bits&=~0x80; | ^~
[Bug c++/101355] compiling coroutines with ubsan emits bogus -Wmaybe-uninitialized warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101355
--- Comment #2 from Dan Klishch ---
GCC incorrectly gimplifies the program. The code that is causing the warning is
in the coroutine's actor function:
try
{
D.9829 = &frame_ptr->__p;
.UBSAN_NULL (D.9829, 4B, 0);
coro::promise_type::return_void (D.9829);
goto final.suspend;
}
finally
{
.UBSAN_NULL (D.9828, 4B, 0); // here
a::~a (D.9828);
}
Obviously, an assignment to D.9828 is missing. However, a little bit earlier a
similar destruction of `struct a' is handled correctly:
try
{
b::~b (&D.9562);
}
catch
{
D.9828 = &frame_ptr->__obj.2.3;
.UBSAN_NULL (D.9828, 4B, 0);
a::~a (D.9828);
}
I guess one of this destructor calls is a copy of another and this might be the
root of the problem. After ubsan instrumentation the call to the destructor
looks like this:
a::~a (.UBSAN_NULL (SAVE_EXPR <&frame_ptr->__obj.2.3>, 4B, 0);,
SAVE_EXPR <&frame_ptr->__obj.2.3>;);
I believe the same SAVE_EXPR is copied to the second invocation of the
destructor but the enclosed expression evaluation is placed only before the
first use of SAVE_EXPR and the control flow does not reach it before a call to
the actual (second) destructor.
I guess this can be fixed by instrumenting the calls to the destructors using
temporary variable and not SAVE_EXPR, like this:
void *ptr = &frame_ptr->__obj.2.3;
.UBSAN_NULL (ptr, 4B, 0);
a::~a (ptr);
But I don't have a solid understanding of GCC internals, so I'm not sure if it
is right.
[Bug libstdc++/101307] Variable templates for type traits—corrections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101307 --- Comment #3 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:da89dfc2a0cb29d3d8a4f2394eee90d150cf6185 commit r12-2344-gda89dfc2a0cb29d3d8a4f2394eee90d150cf6185 Author: Jonathan Wakely Date: Thu Jul 15 21:13:34 2021 +0100 libstdc++: Adjust doxygen markup for variable templates group [PR101307] libstdc++-v3/ChangeLog: PR libstdc++/101307 * include/std/type_traits: Adjust doxygen markup.
[Bug libstdc++/101307] Variable templates for type traits—corrections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101307 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |12.0 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely --- Fixed
[Bug c++/15684] Pointer to member function called on incomplete type should diag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15684 Jonathan Wakely changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #17 from Jonathan Wakely --- This is Core DR 1340 which was moved as a DR in 2012, making the standard match what all compilers already did. http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1340
[Bug target/91602] GCC fails to build for riscv in a combined tree due to misconfigured leb128 support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91602 Serge Belyshev changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |belyshev at depni dot sinp.msu.ru --- Comment #12 from Serge Belyshev --- Testing a patch that removes in-tree gas version checks along with resulting dead code.
[Bug target/91602] GCC fails to build for riscv in a combined tree due to misconfigured leb128 support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91602 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #13 from Jakub Jelinek --- Note, on the DWARF side it has been agreed to get rid of the requirement that uleb128/sleb128 has to be minimum possible length and I think all consumers known to me will not mind non-minimal leb128 as long as it isn't padded too much (i.e. fits within 10 bytes or so). So, even heavy relaxations in the assembler and the linker shouldn't prevent leb128 support, all one needs for linker relaxations is ULEB128 and SLEB128 relocation that allows subtraction of two symbols. But what do you do for non-LEB128 symbol subtractions? Do you have relocations for lab1 - lab2 if one has .quad lab1 - lab2 + 15 ?
[Bug tree-optimization/101467] New: [r12 regression] ICE on aarch64 after r12-2324
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101467 Bug ID: 101467 Summary: [r12 regression] ICE on aarch64 after r12-2324 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- I have noticed ICEs on aarch64 between r12-2322 and r12-2329, likely caused by r12-2324 FAIL: gcc.target/aarch64/sve/peel_ind_1.c (internal compiler error) FAIL: gcc.target/aarch64/sve/peel_ind_1.c (test for excess errors) Excess errors: during GIMPLE pass: vect /gcc/testsuite/gcc.target/aarch64/sve/peel_ind_1.c:13:1: internal compiler error: Segmentation fault 0xe060ff crash_signal /gcc/toplev.c:328 0xdffae8 get_identifier(char const*) /gcc/stringpool.c:97 0x10ddcc9 make_temp_ssa_name /gcc/tree-ssanames.h:148 0x10ddcc9 vect_gen_while(gimple**, tree_node*, tree_node*, tree_node*, char const*) /gcc/tree-vect-stmts.c:12002 0x10ddda3 vect_gen_while_not(gimple**, tree_node*, tree_node*, tree_node*) /gcc/tree-vect-stmts.c:12015 0x112d138 vect_set_loop_controls_directly /gcc/tree-vect-loop-manip.c:632 0x112d138 vect_set_loop_condition_partial_vectors /gcc/tree-vect-loop-manip.c:749 0x112d138 vect_set_loop_condition(loop*, _loop_vec_info*, tree_node*, tree_node*, tree_node*, bool) /gcc/tree-vect-loop-manip.c:950 0x1120225 vect_transform_loop(_loop_vec_info*, gimple*) /gcc/tree-vect-loop.c:9800 0x115c4d9 try_vectorize_loop_1 /gcc/tree-vectorizer.c:1104 0x115cf41 vectorize_loops() /gcc/tree-vectorizer.c:1243 The full list of ICEs: gcc.target/aarch64/sve/peel_ind_1.c (internal compiler error) gcc.target/aarch64/sve/peel_ind_2.c (internal compiler error) gcc.target/aarch64/sve/peel_ind_3.c (internal compiler error) gcc.target/aarch64/sve/peel_ind_4.c (internal compiler error) gcc.target/aarch64/sve/pr98119.c (internal compiler error) When using -mabi=ilp32, there is only one ICE: FAIL: gcc.dg/vect/pr95570.c (internal compiler error)
[Bug middle-end/101468] New: [r12 regression] new Wstringop-overflow tests failures since r12-2338
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101468
Bug ID: 101468
Summary: [r12 regression] new Wstringop-overflow tests failures
since r12-2338
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Since r12-2338, I've noticed that some of the new tests fail on arm/aarch64.
On aarch64:
FAIL:
gcc.dg/Wstringop-overflow-71.c (test for warnings, line 103)
gcc.dg/Wstringop-overflow-71.c (test for warnings, line 104)
gcc.dg/Wstringop-overflow-71.c (test for warnings, line 32)
gcc.dg/Wstringop-overflow-71.c (test for warnings, line 43)
gcc.dg/Wstringop-overflow-71.c (test for warnings, line 66)
gcc.dg/Wstringop-overflow-71.c (test for warnings, line 77)
gcc.dg/Wstringop-overflow-71.c (test for warnings, line 90)
gcc.dg/Wstringop-overflow-71.c (test for warnings, line 91)
gcc.dg/Wstringop-overflow-71.c (test for excess errors)
UNRESOLVED:
gcc.dg/strlenopt-95.c scan-tree-dump-not strlen1 "abort \\("
gcc.dg/strlenopt-95.c scan-tree-dump-not strlen1 "strlen \\("
on aarch64_be, we have two XPASS in addition to the FAIL above:
gcc.dg/Wstringop-overflow-47.c pr97027 (test for warnings, line 77)
gcc.dg/Wstringop-overflow-47.c pr97027 note (test for warnings, line 68)
on arm-eabi, with default configuration flags, we have:
XPASS:
gcc.dg/Wstringop-overflow-68.c pr?? (test for warnings, line 61)
gcc.dg/Wstringop-overflow-68.c pr?? (test for warnings, line 62)
gcc.dg/Wstringop-overflow-68.c pr?? (test for warnings, line 63)
gcc.dg/Wstringop-overflow-68.c pr?? (test for warnings, line 64)
gcc.dg/Wstringop-overflow-68.c pr?? (test for warnings, line 65)
FAIL:
gcc.dg/Wstringop-overflow-70.c (test for warnings, line 19)
gcc.dg/Wstringop-overflow-70.c (test for excess errors)
gcc.dg/Wstringop-overflow-71.c (test for warnings, line 103)
gcc.dg/Wstringop-overflow-71.c (test for warnings, line 104)
gcc.dg/Wstringop-overflow-71.c (test for warnings, line 32)
gcc.dg/Wstringop-overflow-71.c (test for warnings, line 43)
gcc.dg/Wstringop-overflow-71.c (test for warnings, line 66)
gcc.dg/Wstringop-overflow-71.c (test for warnings, line 77)
gcc.dg/Wstringop-overflow-71.c (test for warnings, line 90)
gcc.dg/Wstringop-overflow-71.c (test for warnings, line 91)
gcc.dg/Wstringop-overflow-71.c (test for excess errors)
UNRESOLVED:
gcc.dg/strlenopt-95.c scan-tree-dump-not strlen1 "abort \\("
gcc.dg/strlenopt-95.c scan-tree-dump-not strlen1 "strlen \\("
When forcing RUNTESTFLAGS to
-mcpu=cortex-a7/-mfloat-abi=hard/-march=armv7ve+simd, in addition to the above
we have:
XPASS:
gcc.dg/Wstringop-overflow-47.c pr97027 (test for warnings, line 77)
gcc.dg/Wstringop-overflow-47.c pr97027 note (test for warnings, line 68)
and gcc.dg/Wstringop-overflow-70.c no longer fails
[Bug tree-optimization/101462] [12 regression] ICE on aarch64 after r12-2292
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101462 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Richard Biener --- Fixed with commit d6aa28bb93c6fc9042ee87ff7addac60647dbddb (HEAD -> trunk, origin/trunk, origin/master, origin/HEAD) Author: Richard Biener Date: Fri Jul 16 08:50:40 2021 +0200 tree-optimization/101462 - fix signedness of reused reduction vector This fixes the partial reduction of the reused reduction vector to carried out in the correct sign and the correctly signed vector recorded for the skip edge use. 2021-07-16 Richard Biener * tree-vect-loop.c (vect_transform_cycle_phi): Correct sign conversion issues with the partial reduction of the reused vector accumulator.
[Bug middle-end/101468] [12 regression] new Wstringop-overflow tests failures since r12-2338
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101468 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0 Summary|[r12 regression] new|[12 regression] new |Wstringop-overflow tests|Wstringop-overflow tests |failures since r12-2338 |failures since r12-2338
[Bug tree-optimization/101467] [r12 regression] ICE on aarch64 after r12-2324
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101467 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||2021-07-16 --- Comment #1 from Richard Biener --- Mine.
[Bug tree-optimization/101467] [12 regression] ICE on aarch64 after r12-2324
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101467 Richard Biener changed: What|Removed |Added Summary|[r12 regression] ICE on |[12 regression] ICE on |aarch64 after r12-2324 |aarch64 after r12-2324 Target Milestone|--- |12.0
[Bug c/101469] New: wrong code with "-O2 -fPIE" for SH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101469
Bug ID: 101469
Summary: wrong code with "-O2 -fPIE" for SH
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rin at NetBSD dot org
CC: rin at NetBSD dot org
Target Milestone: ---
Target: shle--netbsdelf
This Bug is for GCC 10.3 for shle:
$ shle--netbsdelf-gcc -v
Using built-in specs.
COLLECT_GCC=/build/gcc10/tools/bin/shle--netbsdelf-gcc
COLLECT_LTO_WRAPPER=/build/gcc10/tools/libexec/gcc/shle--netbsdelf/10.3.0/lto-wrapper
Target: shle--netbsdelf
Configured with: /usr/src/tools/gcc/../../external/gpl3/gcc/dist/configure
--target=shle--netbsdelf --enable-long-long --enable-threads
--with-bugurl=http://www.NetBSD.org/support/send-pr.html
--with-pkgversion='NetBSD nb1 20210411' --with-system-zlib --without-isl
--enable-__cxa_atexit --enable-libstdcxx-time=rt --enable-libstdcxx-threads
--with-diagnostics-color=auto-if-env --with-default-libstdcxx-abi=new
--with-sysroot=/build/gcc10/dest/landisk --with-mpc=/build/gcc10/tools
--with-mpfr=/build/gcc10/tools --with-gmp=/build/gcc10/tools --disable-nls
--disable-multilib --program-transform-name='s,^,shle--netbsdelf-,'
--enable-languages='c c++ objc' --prefix=/build/gcc10/tools
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.3.0 (NetBSD nb1 20210411)
GCC miscompile this code with "-O2 -fPIE":
typedef struct {
int pad[16];
int i;
int *p;
} struct_t;
struct_t *sp;
void *ptr(void);
void func(void) {
sp = ptr();
sp->p = &sp->i;
}
The following is objdump with comments:
:
0: mov.l r12,@-r15
2: mova24 ,r0
4: mov.l 24 ,r12
6: sts.l pr,@-r15
8: add r0,r12 ! r12 = .got
a: mov.l 28 ,r1
c: bsrfr1 ! r0 = ptr()
e: nop
10: mov.l 2c ,r1
12: mov r0,r2 ! r2 = r0
14: mov r12,r0
16: mov.l r2,@(r0,r1) ! @(.got, 2c) = sp = r2
18: add #64,r2 ! r2 = &sp->i
1a: mov.l r2,@(4,r12) ! XXX
1c: lds.l @r15+,pr
1e: rts
20: mov.l @r15+,r12
22: nop
24: .word 0x
26: .word 0x
28: sett
2a: .word 0x
2c: .word 0x
The problem is marked by XXX in comment; if this line were
1a: mov.l r2,@(4,r2)
it would make sense, i.e.,
@(4, &sp->i) = sp->p = r2 = &sp->i
However, unfortunately, GCC somehow mistakes r12 (= .got) with r2.
As a result, sp->p is not correctly set, and .got gets corrupted.
Note that generated code is almost same for "-Os -fPIE". And the
problem occurs also for GCC 9.3.
[Bug tree-optimization/101467] [12 regression] ICE on aarch64 after r12-2324
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101467 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:df0d7486ec9bca8a77ca106d9fbb60f819dd9cec commit r12-2350-gdf0d7486ec9bca8a77ca106d9fbb60f819dd9cec Author: Richard Biener Date: Fri Jul 16 11:17:37 2021 +0200 tree-optimization/101467 - fix make_temp_ssa_name usage My previous change to vect_gen_while introduced paths which call make_temp_ssa_name with a NULL name which isn't supported. The following fixes that. 2021-07-16 Richard Biener PR tree-optimization/101467 * tree-vect-stmts.c (vect_gen_while): Properly guard make_temp_ssa_name usage.
[Bug tree-optimization/101467] [12 regression] ICE on aarch64 after r12-2324
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101467 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed.
[Bug target/86681] ICE in extract_insn, at recog.c:2304 on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86681 --- Comment #6 from Andreas Krebbel --- Do you have the command line for the tattr-1.c test? The verbose options line appears to contain the options for a different test. I could not reproduce the problem with these options.
[Bug target/101448] Use GCC 9.3.0 to build Ceph crimson-osd on Arm64, linker failed for relocation truncated to fit: R_AARCH64_CALL26 against symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101448 Richard Earnshaw changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #8 from Richard Earnshaw --- Closing as this is not a compiler bug. If there's a problem anywhere it is that the linker needs to implement mitigation strategies for very large code bases, but even that is an enhancement rather than a strict bug.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #244 from John Buddery --- I tried a gcc 11 build with patched 2.30 binutils and it worked. I also tried building binutils 2.36 with just /opt/aCC/bin and no gcc. I didn't get any gnu99 errors, but it did fail because plugin-api.h couldn't work out the endianism. Configuring with: CFLAGS="-O -D__BIG_ENDIAN__=1" ./configure --prefix=/u sr/local/binutils-test --enable-obsolete allowed gas to build, but the build then failed later on in libctf. It looks like libtool is inserting +Maked into the command line for some reason, which breaks things. I don't know if this gas build would work for gcc, probably it would have the same issues as a 32 bit gcc build. +DD64 might fix this. Probably not worth updating though just for gcc if you have a working 2.30 build, since that works OK.
[Bug sanitizer/101380] Segmentation fault in address sanitizer initialization, caused by mmap-ing into the running code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101380 puspmvqyfzxrbytwsu at niwghx dot com changed: What|Removed |Added Summary|Segmentation fault in |Segmentation fault in |__asan_init |address sanitizer ||initialization, caused by ||mmap-ing into the running ||code --- Comment #2 from puspmvqyfzxrbytwsu at niwghx dot com --- The crash seems to only occur with ASLR enabled. When disabling ASLR via setarch or gdb, I could not reproduce the issue. I was not able to get a useful stack trace using gdb (when looking at the segmentation fault, the stack trace printed by gdb looked like corrupted data, with only a single stack frame printed). So, I did some debugging with ptrace to get a stack trace before the program crashes. From this, it looks like the allocator initialization code of the address sanitizer library causes the crash by performing an mmap-syscall, mapping something into the address range of the code which is being executed: system call 9 is mmap -> argument 0, here 0x6000, is the starting address (in the process address space) -> argument 1, here 0x0400, is the length to be mapped => The address range from 0x6000 to 0x6400 will be mapped. -> The instruction pointer, here 0x63C62D125104, is within this address range. /* system call entry information (acquired with ptrace) */ entering system call 0x09: argument 0: 0x6000 argument 1: 0x04003000 argument 2: 0x argument 3: 0x4032 argument 4: 0x argument 5: 0x /* stack trace (acquired with libunwind-ptrace) */ [RIP: 0x63C62D125104, RSP: 0x79E7984D2D50] _ZN11__sanitizer13internal_mmapEPvmiiiy+0x8 [RIP: 0x63C62D129430, RSP: 0x79E7984D2D70] _ZN11__sanitizer9MmapNamedEPvmiiPKc+0x8 [RIP: 0x63C62D12A049, RSP: 0x79E7984D2DA0] _ZN11__sanitizer20ReservedAddressRange4InitEmPKcm+0x8 [RIP: 0x63C62D07931B, RSP: 0x79E7984D2DC0] _ZN6__asan19InitializeAllocatorERKNS_16AllocatorOptionsE+0xA7 [RIP: 0x63C62D1174DF, RSP: 0x79E7984D2DF0] _ZN6__asanL16AsanInitInternalEv.part.0+0xA7 [RIP: 0x63C62DA63F6E, RSP: 0x79E7984D2E40] _dl_init+0x1 /* */ Upon exit from the system call, I got the following information from ptrace (indicating success of mmap): system call exiting: return value: 0x6000, is error: 0 At this point, I could no longer obtain a useful stack trace via libunwind-ptrace. (Only a single stack-frame, not able to get a procedure name corresponding to it, similar to what I got with gdb). Then the segmentation fault occurs.
[Bug debug/101470] New: Support -gline-tables-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101470 Bug ID: 101470 Summary: Support -gline-tables-only Product: gcc Version: 11.1.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- In a gdb discussion here ( https://sourceware.org/bugzilla/show_bug.cgi?id=28094 ) (starting from the fact that the dwarf 5 standard mentions that there's a "common practice of stripping all but the line number sections") it was observed that there's: - a gold option -Wl,--strip-debug-non-line (not working with gdwarf-5, see https://sourceware.org/bugzilla/show_bug.cgi?id=28095) - a 2018 patch proposing to add -Wl,--strip-debug-non-line to ldd - clang -gline-tables-only but that there's no gcc equivalent. After realizing that clangs -gline-tables-only is an alias for -g1, I looked at gcc's -g1 and found it does have line table info (since gcc 4.9), but emits a bit more than clangs -g1. I compared output for a hello world and found that gcc: - emits a DIE for main, while clang does not - emits a .debug_aranges section, while clang does not
[Bug debug/101470] Support -gline-tables-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101470 --- Comment #1 from Tom de Vries --- Created attachment 51161 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51161&action=edit Demonstrator patch I wrote a demonstrator patch that makes the two mentioned differences disappear. It also drops the CU DIE low_pc/high_pc attributes as a side-effect (while that's still emitted by clang). I don't know enough yet about the intended use case to say whether that's problematic or not.
[Bug target/101464] Replace zveroupper with vpxor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101464 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from H.J. Lu --- (In reply to Richard Biener from comment #3) > But in the long discussion involving vzeroupper and HTM aborts in glibc > memory functions it came up that vpxor is _not_ properly clearing the upper > state and thus does _not_ remove the penalty that following non-VEX SSE > instructions get? From https://sourceware.org/bugzilla/show_bug.cgi?id=27457 we can't use VPXOR to replace VZEROUPPER.
[Bug target/101471] New: AVX512 incorrect writemask generated for _mm512_fpclass_ps_mask in O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101471
Bug ID: 101471
Summary: AVX512 incorrect writemask generated for
_mm512_fpclass_ps_mask in O0
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: kastianoza at gmail dot com
Target Milestone: ---
It seems that in debug mode gcc generates an 8-bit write opmask, which causes
half of the result to be skipped when calling '_mm512_fpclass_ps_mask' (which
takes 16 floats and produces 16 bit result).
It doesn't happen in O1, when gcc generates instruction that doesn't take
writemask.
GCC info:
Using built-in specs.
COLLECT_GCC=g++-11
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
11.1.0-1ubuntu1~18.04.1' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --disable-cet --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-11-YRKbe7/gcc-11-11.1.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-YRKbe7/gcc-11-11.1.0/debian/tmp-gcn/usr
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.1.0 (Ubuntu 11.1.0-1ubuntu1~18.04.1)
Compilation command:
g++-11 fpclass_instruction.cpp -mavx512f -mavx512vl -mavx512bw -mavx512dq -ggdb
-O0
minimal example:
#include
#include
int main() {
__m512 x {
1, 1, 1, 1,
1, 1, 1, 1,
0, 0, 0, 0,
0, 0, 0, 0, };
auto ret = _mm512_fpclass_ps_mask(x, 0x26);
std::cout << ret << std::endl;
}
relevant part of preprocessed code: (notice incorrect mask type : __mmask8)
# 7 "fpclass_instruction.cpp"
int main() {
__m512 x {
1, 1, 1, 1,
1, 1, 1, 1,
0, 0, 0, 0,
0, 0, 0, 0, };
auto ret =
# 13 "fpclass_instruction.cpp" 3 4
((__mmask16) __builtin_ia32_fpclassps512_mask ((__v16sf) (__m512) (
# 13 "fpclass_instruction.cpp"
x
# 13 "fpclass_instruction.cpp" 3 4
), (int) (
# 13 "fpclass_instruction.cpp"
0x26
# 13 "fpclass_instruction.cpp" 3 4
),(__mmask8)-1))
# 13 "fpclass_instruction.cpp"
;
std::cout << ret << std::endl;
}
[Bug target/101471] AVX512 incorrect writemask generated for _mm512_fpclass_ps_mask in O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101471 --- Comment #1 from Kastax --- Attachment size limit is too strict for me to include "the preprocessed file (*.i*) that triggers the bug"
[Bug target/101472] New: AVX-512 wrong code for consecutive masked scatters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101472
Bug ID: 101472
Summary: AVX-512 wrong code for consecutive masked scatters
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dlustig at nvidia dot com
Target Milestone: ---
Created attachment 51162
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51162&action=edit
Test case
$ cat two_scatters.c
#include
void two_scatters(void* base_addr, __mmask8 k1, __mmask8 k2, __m512i vindex,
__m256i a) {
_mm512_mask_i64scatter_epi32(base_addr, k1, vindex, a, 1);
_mm512_mask_i64scatter_epi32(base_addr, k2, vindex, a, 1);
}
$ g++-11 -S -O3 -march=skylake-avx512 -Wall -Wextra -fno-strict-aliasing
-fwrapv -fno-aggressive-loop-optimizations two_scatters.c -o -
...
_Z12two_scattersPvhhDv8_xDv4_x:
kmovb %edx, %k2
vpscatterqd %ymm1, (%rdi,%zmm0,1){%k2}
ret
...
Only one vpscatterqd instruction is generated, even though I would expect two.
The optimizer seems to think the first store is redundant with the second due
to matching addresses, and hence optimizes it away. However, since two
different masks are being used, the scatters are not actually redundant.
Perturbing the example by passing two different base addresses, or inserting an
asm("nop"); in between, etc., will cause both scatters to get emitted:
https://godbolt.org/z/3b8v86on4
Stand-alone executable test case attached as well.
GCC version info:
$ gcc-11 -v
Using built-in specs.
COLLECT_GCC=gcc-11
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
11.1.0-1ubuntu1~18.04.1' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --disable-cet --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-11-YRKbe7/gcc-11-11.1.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-YRKbe7/gcc-11-11.1.0/debian/tmp-gcn/usr
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.1.0 (Ubuntu 11.1.0-1ubuntu1~18.04.1)
[Bug target/101456] Unnecessary vzeroupper when upper bits of YMM registers already zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101456 --- Comment #5 from H.J. Lu --- We need to verify that LOADING the zero YMM register won't trigger SSE<->AVX transition penalty.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #245 from The Written Word --- (In reply to John Buddery from comment #238) > Was your 11.1 build successful ? Our rebuild of 11.1.0 completed successfully. I haven't tested it though. I am going to try earlier GCC releases and build on 11.23/IA as well.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #246 from The Written Word --- Created attachment 51163 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51163&action=edit Build script and patches Build script for zlib, gmp, mpfr, mpc, binutils 2.25.1, 2.30, 2.32, and GCC 4.4.6, 4.6.4, 4.7.4, 4.8.5, 4.9.5, and 11.1.0. Build instructions for GCC 9.4.0 and 10.3.0 included but not tested yet. Patches for all of the above included as well. Work-in-progress.
[Bug tree-optimization/101110] [12 regression] gcc.c-torture/execute/950704-1.c fails after r12-1546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101110 Andrew Macleod changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Andrew Macleod --- fixed.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #247 from John Buddery --- Looks good, that's a lot of gcc versions! For clarification, I assume this is using the HP aCC compiler for binutils etc., rather than the bundled /usr/ccs/bin cc ?
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #248 from The Written Word --- (In reply to John Buddery from comment #247) > For clarification, I assume this is using the HP aCC compiler for binutils > etc., rather than the bundled /usr/ccs/bin cc ? Correct.
[Bug libstdc++/101214] ranges::split_view::sentinel lacks default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101214 --- Comment #3 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:73464a472aa4e86359f1a5dc529394fe5152fec0 commit r12-2356-g73464a472aa4e86359f1a5dc529394fe5152fec0 Author: Patrick Palka Date: Fri Jul 16 09:44:32 2021 -0400 libstdc++: Give split_view::_Sentinel a default ctor [PR101214] This gives the new split_view's sentinel type a defaulted default constructor, something which was overlooked in r12-1665. This patch also fixes a couple of other issues with the new split_view as reported in the PR. PR libstdc++/101214 libstdc++-v3/ChangeLog: * include/std/ranges (split_view::split_view): Use std::move. (split_view::_Iterator::_Iterator): Remove redundant default_initializable constraint. (split_view::_Sentinel::_Sentinel): Declare. * testsuite/std/ranges/adaptors/split.cc (test02): New test.
[Bug libstdc++/101231] _CachedPosition::_M_get() should not return {} when range adapter does not model forward_range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101231
--- Comment #1 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:1af937eb6246ad7f63ebff03590e9eede33aca81
commit r12-2357-g1af937eb6246ad7f63ebff03590e9eede33aca81
Author: Patrick Palka
Date: Fri Jul 16 09:44:42 2021 -0400
libstdc++: invalid default init in _CachedPosition [PR101231]
The primary template for _CachedPosition is a dummy implementation for
non-forward ranges, the iterators for which generally can't be cached.
Because this implementation doesn't actually cache anything, _M_has_value
is defined to be false and so calls to _M_get (which are always guarded
by _M_has_value) are unreachable.
Still, to suppress a "control reaches end of non-void function" warning
I made _M_get return {}, but after P2325 input iterators are no longer
necessarily default constructible so this workaround now breaks valid
programs.
This patch fixes this by instead using __builtin_unreachable to squelch
the warning.
PR libstdc++/101231
libstdc++-v3/ChangeLog:
* include/std/ranges (_CachedPosition::_M_get): For non-forward
ranges, just call __builtin_unreachable.
* testsuite/std/ranges/istream_view.cc (test05): New test.
[Bug libstdc++/101214] ranges::split_view::sentinel lacks default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101214 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |12.0 Resolution|--- |FIXED --- Comment #4 from Patrick Palka --- Fixed for GCC 12.
[Bug libstdc++/101231] _CachedPosition::_M_get() should not return {} when range adapter does not model forward_range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101231 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |12.0 Resolution|--- |FIXED --- Comment #2 from Patrick Palka --- Fixed for GCC 12.
[Bug c++/100895] gcc accepts invalid template argument in partial template specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100895 Patrick Palka changed: What|Removed |Added Last reconfirmed||2021-07-16 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=100779 CC||ppalka at gcc dot gnu.org --- Comment #1 from Patrick Palka --- Confirmed, not a regression.
[Bug tree-optimization/100349] [11 Regression] ICE Segmentation fault during GIMPLE pass: evrp (under -O2 to -Os)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100349 Andrew Macleod changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Andrew Macleod --- fixed
[Bug lto/101473] New: LTO makes debug info depend on toolchain path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101473 Bug ID: 101473 Summary: LTO makes debug info depend on toolchain path Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: tonyb at cybernetics dot com CC: marxin at gcc dot gnu.org Target Milestone: --- When compiling with -flto -g, the resulting debug info varies depending on the install path of the compiler toolchain. This is a problem for reproducible builds (https://reproducible-builds.org/) when the compiler toolchain is installed in the user home directory. For example, when compiling a file lto_test.c with the same toolchain copied into two different paths, readelf -a shows the following: toolchain path 1: 23: 05f5 0 NOTYPE WEAK HIDDEN28 lto_test.c.79b8ff9a toolchain path 2: 42: 05f5 0 NOTYPE WEAK HIDDEN28 lto_test.c.bba5e59b The -frandom-seed flag does not help in this case. The output is deterministic (same output across multiple runs). With -flto disabled, the problem goes away. Non-LTO binaries are identical regardless of the compiler toolchain path. Stripping the debug info from the LTO binaries makes them identical, but using "objcopy --add-gnu-debuglink" makes them different again because the embedded checksum for the debug info is different. I encountered this problem trying to make reproducible builds with -flto under Yocto. Here is the Yocto bug report, including test code for Yocto: https://bugzilla.yoctoproject.org/show_bug.cgi?id=14481 Regarding the "LTO reproducible build test" attachment in the Yocto bug report: Yocto sets up the compiler toolchain in a "recipe-sysroot-native" directory and the system lib/, include/, and such in a "recipe-sysroot" directory, which are prepared by running "bitbake lto-test". Then the run-lto-test script makes two copies of the compiler toolchain under two differnet names using "cp -rl", compiles the simple test program using both toolchains, and compares them. Comment 6 on this bug may be related: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66305#c6
[Bug target/101393] PowerPC32 inline assembly broken by commit 2d94f7dea9c73ef3c116a0ddc722724578a860fe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393 --- Comment #3 from Franz Sirl --- (In reply to Segher Boessenkool from comment #1) > The -many is problematic, that is the whole point of this. As in this > example: on different subtargets there are different machine code > translations for the same mnemonic! But the way gas works there are never 2 active translations for the same mnemonic, or? For example, for "-m403 -many" or "-many -m403" first the 403 mnemonics are added to the hash. Then, for -many, all the mnemonics are added but duplicates are simply skipped. Actually, since -many is sticky and always (except when CHECKING_P?? or AIX) part of ASM_CPU_SPEC, the ".machine ppc" doesn't really help since -many is also active for the .machine pseudo-op. Maybe you meant to also remove -many from ASM_CPU_SPEC? In that case we would have seen at least an assembler error, since there is no dcread for -mppc.
[Bug c++/43253] improve diagnostics for invalid pseudo destructor call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43253 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-07-16 --- Comment #3 from Jonathan Wakely --- Now we say: 43253.C: In function 'int main()': 43253.C:4:13: error: expected identifier before 'int' 4 | x->~int(); | ^~~ I suppose we could add a more specific diagnostic saying you can't do this. It's not a high priority, because the code is nonsense anyway. Why would you want to destroy an int explicitly? A pseudo-destructor call is only useful in generic code where you don't know what the type is.
[Bug c++/84895] Smarter suggestions for "private" accessor hints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84895 Jonathan Wakely changed: What|Removed |Added Target Milestone|9.5 |---
[Bug c++/53863] misleading error message for redefinitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53863
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-07-16
--- Comment #2 from Jonathan Wakely ---
Current trunk says this:
53863.C:2:12: error: 'a' conflicts with a previous declaration
2 | enum { a = 1 };
|^
53863.C:1:8: note: previous declaration ' a'
1 | enum { a = 1 };
|^
The caret on the error seems wrong, as it points to the initializer not the
enumerator. The note is correct.
[Bug c++/55664] Missing diagnostic "dependent using declaration resolved to type without 'typename'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55664
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2021-07-16
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #3 from Jonathan Wakely ---
THe testcase is invalid, there are access errors. This fixes them, and
instantiates the template:
namespace std
{
namespace thrust
{
template < typename Derived >
struct iterator_adaptor { typedef Derived base_type; };
template < typename Derived >
struct pointer_base_base {
typedef thrust::iterator_adaptor < Derived > type;
};
template < typename Derived >
struct pointer_base : public pointer_base_base :: type
{
typedef typename pointer_base_base < Derived > :: type super_t;
using super_t::base_type;
};
template < unsigned int DummyParameterToAvoidInstantiation >
void mymalloc (thrust::pointer_base< void >) { };
}
}
int main()
{
std::thrust::pointer_base p;
std::thrust::mymalloc<1>(p);
}
GCC still accepts this without an error. I'm not sure if the "down with
typename" changes in C++23 make it valid now anyway.
[Bug target/101393] PowerPC32 inline assembly broken by commit 2d94f7dea9c73ef3c116a0ddc722724578a860fe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393
--- Comment #4 from Franz Sirl ---
Created attachment 51164
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51164&action=edit
Half-baken trial patch
How about something along this patch? It's not fully done (no good idea about
SPEC stuff like "mcpu=7400: -mppc %{!mvsx:%{!maltivec:-maltivec}};" yet), but
you should get the idea.
In the the end most of ASM_CPU_SPEC could be removed and also the duplication
between ASM_CPU_SPEC and driver-rs6000.c could go away.
[Bug middle-end/101457] [12 regression] new test cases in r12-2300 fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101457 --- Comment #4 from CVS Commits --- The master branch has been updated by Tamar Christina : https://gcc.gnu.org/g:3bf6e1f89dbd2c67c419d3d4e94085208611262f commit r12-2362-g3bf6e1f89dbd2c67c419d3d4e94085208611262f Author: Tamar Christina Date: Fri Jul 16 15:56:35 2021 +0100 testsuite: fix IL32 issues with usdot tests. Fix tests when int == long by using long long instead. gcc/testsuite/ChangeLog: PR middle-end/101457 * gcc.dg/vect/vect-reduc-dot-19.c: Use long long. * gcc.dg/vect/vect-reduc-dot-20.c: Likewise. * gcc.dg/vect/vect-reduc-dot-21.c: Likewise. * gcc.dg/vect/vect-reduc-dot-22.c: Likewise.
[Bug libstdc++/100795] ranges::sample should not use std::sample directly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100795
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #6 from Patrick Palka ---
(In reply to 康桓瑋 from comment #2)
> ranges::inplace_merge has the same issue:
>
>
> #include
> #include
> #include
>
> int main() {
> std::array a{42, 42, 42};
> auto r = std::views::iota(0, 3) |
>std::views::transform([&a](int i) -> int& { return a[i]; });
> std::ranges::inplace_merge(r, r.begin());
> }
>
> https://godbolt.org/z/q6jbxGMjd
Hmm, this one seems more like a problem in the specification of
transform_view::iterator_category. Shouldn't r's iterator_category be
random_access_iterator here? AFAICT it satisfies all the requirements of
__LegacyRandomAccessIterator.
[Bug ipa/101257] [11/12 Regression] Maybe wrong code since IPA mod ref was introduced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101257 Gregory Tucker changed: What|Removed |Added CC||greg.b.tucker at intel dot com --- Comment #2 from Gregory Tucker --- Created attachment 51165 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51165&action=edit Hash reference function test case Fails on gcc11 with -O2, passes with -O2. # gcc -O2 -o tst md5_reference.c && ./tst
[Bug ipa/101257] [11/12 Regression] Maybe wrong code since IPA mod ref was introduced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101257 --- Comment #3 from Gregory Tucker --- Comment on attachment 51165 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51165 Hash reference function test case edit: Fails test case on -O2, passes on -O1
[Bug ipa/101257] [11/12 Regression] Maybe wrong code since IPA mod ref was introduced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101257 --- Comment #4 from Andrew Pinski --- (In reply to Gregory Tucker from comment #2) > Created attachment 51165 [details] I think there are some aliasing violations here. We store to buf (which is unsigned char array) as a mixture of unsigned char and uint64_t in md5_ref BUT then do loads in the uint32_t type in md5_single. I think: uint32_t *w = (uint32_t *) data; Should need the may_alias attribute added to it.
[Bug libstdc++/100795] ranges::sample should not use std::sample directly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100795
--- Comment #7 from 康桓瑋 ---
(In reply to Patrick Palka from comment #6)
> (In reply to 康桓瑋 from comment #2)
> > ranges::inplace_merge has the same issue:
> >
> >
> > #include
> > #include
> > #include
> >
> > int main() {
> > std::array a{42, 42, 42};
> > auto r = std::views::iota(0, 3) |
> >std::views::transform([&a](int i) -> int& { return a[i]; });
> > std::ranges::inplace_merge(r, r.begin());
> > }
> >
> > https://godbolt.org/z/q6jbxGMjd
>
> Hmm, this one seems more like a problem in the specification of
> transform_view::iterator_category. Shouldn't r's iterator_category be
> random_access_iterator here? AFAICT it satisfies all the requirements of
> __LegacyRandomAccessIterator.
Damn, I think you are right. According to [range.transform.iterator#2.1], even
if is_lvalue_reference_v>> is true,
transform_view::iterator_category is still determined by the
iota_view::iterator_category.
[Bug bootstrap/101374] [12 Regression] bootstrap failure varpool.c:490:19: error: array subscript 'varpool_node[0]' is partly outside array bounds of 'varpool_node [0]' [-Werror=array-bounds]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101374 Hafiz Abid qadeer changed: What|Removed |Added CC||abidh at gcc dot gnu.org --- Comment #16 from Hafiz Abid qadeer --- Similar problem in libgomp and it is still broken. I was building for x86_64 with amdgcn offloading. /scratch/cfi/x86_64-linux-gnu-amdgcn/obj/accel-gcc-mainline/./gcc/xgcc -B/scratch/cfi/x86_64-linux-gnu-amdgcn/obj/accel-gcc-mainline/./gcc/ -B/scratch/cfi/x86_64-linux-gnu-amdgcn/install/amdgcn-amdhsa/bin/ -B/scratch/cfi/x86_64-linux-gnu-amdgcn/install/amdgcn-amdhsa/lib/ -isystem /scratch/cfi/x86_64-linux-gnu-amdgcn/install/amdgcn-amdhsa/include -isystem /scratch/cfi/x86_64-linux-gnu-amdgcn/install/amdgcn-amdhsa/sys-include -DHAVE_CONFIG_H -I. -I/scratch/cfi/x86_64-linux-gnu-amdgcn/src/gcc-mainline/libgomp -I/scratch/cfi/x86_64-linux-gnu-amdgcn/src/gcc-mainline/libgomp/config/gcn -I/scratch/cfi/x86_64-linux-gnu-amdgcn/src/gcc-mainline/libgomp/config/accel -I/scratch/cfi/x86_64-linux-gnu-amdgcn/src/gcc-mainline/libgomp -I/scratch/cfi/x86_64-linux-gnu-amdgcn/src/gcc-mainline/libgomp/../include -Wall -Werror -g -O2 -MT barrier.lo -MD -MP -MF .deps/barrier.Tpo -c -o barrier.lo /scratch/cfi/x86_64-linux-gnu-amdgcn/src/gcc-mainline/libgomp/barrier.c In file included from /scratch/cfi/x86_64-linux-gnu-amdgcn/src/gcc-mainline/libgomp/barrier.c:28: In function 'gcn_thrs', inlined from 'gomp_thread' at /scratch/cfi/x86_64-linux-gnu-amdgcn/src/gcc-mainline/libgomp/libgomp.h:803:10, inlined from 'GOMP_barrier' at /scratch/cfi/x86_64-linux-gnu-amdgcn/src/gcc-mainline/libgomp/barrier.c:34:29: /scratch/cfi/x86_64-linux-gnu-amdgcn/src/gcc-mainline/libgomp/libgomp.h:792:10: error: array subscript 0 is outside array bounds of '__lds struct gomp_thread * __lds[0]' [-Werror=array-bounds] 792 | return *thrs; | ^ In function 'gcn_thrs', inlined from 'gomp_thread' at /scratch/cfi/x86_64-linux-gnu-amdgcn/src/gcc-mainline/libgomp/libgomp.h:803:10, inlined from 'GOMP_barrier_cancel' at /scratch/cfi/x86_64-linux-gnu-amdgcn/src/gcc-mainline/libgomp/barrier.c:47:29: /scratch/cfi/x86_64-linux-gnu-amdgcn/src/gcc-mainline/libgomp/libgomp.h:792:10: error: array subscript 0 is outside array bounds of '__lds struct gomp_thread * __lds[0]' [-Werror=array-bounds] 792 | return *thrs; | ^
[Bug c/101474] New: -fipa-icf generates worse code for identical function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101474 Bug ID: 101474 Summary: -fipa-icf generates worse code for identical function Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: vegard.nossum at oracle dot com Target Milestone: --- Created attachment 51166 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51166&action=edit Test case I've come across a weird behaviour when using -fipa-icf, could maybe be related to bug 80277. Build with -O1 -fipa-icf and the second version of the identical function actually has worse codegen than if you have just one of them there or than if you hadn't passed -fipa-icf at all. See example: https://godbolt.org/z/n8zz947aK
[Bug tree-optimization/101474] SRA sometimes produces worse code with inline functions (seen with -fipa-icf sometimes)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101474
Andrew Pinski changed:
What|Removed |Added
Summary|-fipa-icf generates worse |SRA sometimes produces
|code for identical function |worse code with inline
||functions (seen with
||-fipa-icf sometimes)
Ever confirmed|0 |1
Last reconfirmed||2021-07-16
Status|UNCONFIRMED |NEW
--- Comment #1 from Andrew Pinski ---
This worse code generation has nothing to do with -fipa-icf really as shown by:
struct t {
char x;
int y;
};
void fn1(struct t *p, struct t v)
{
*p = v;
}
void fn3(struct t *p, struct t v)
{
fn1(p, v);
}
-- CUT
What is happening is SRA decides it is best to do a full scalar replacement for
the v that is inlined into fn3 (from fn1).
[Bug debug/101470] Support -gline-tables-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101470 --- Comment #2 from Andrew Pinski --- (In reply to Tom de Vries from comment #0) > After realizing that clangs -gline-tables-only is an alias for -g1, I looked > at gcc's -g1 and found it does have line table info (since gcc 4.9), but > emits a bit more than clangs -g1. The discussion around line tables being added to -g1 can be found in these two threads: https://gcc.gnu.org/legacy-ml/gcc-patches/2013-02/msg00260.html https://gcc.gnu.org/legacy-ml/gcc-patches/2011-04/msg02075.html I think it was decided not to add a new option for line tables only back then.
[Bug middle-end/101475] New: missing -Wstringop-overflow storing a compound literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101475
Bug ID: 101475
Summary: missing -Wstringop-overflow storing a compound literal
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
Even with pr97027 resolved -Wstringop-overflow is not issued consistently (on
all targets) for buffer overflow when storing a larger compound literal into a
smaller buffer. The test case below is diagnosed by -Warray-bounds which is
only enabled with -Wall and at -O2, but not by -Wstringop-overflow (which is
enabled by default). Ideally the bug should be diagnosed even at -O0.
$ cat a.c && gcc -O2 -S -fdump-tree-strlen=/dev/stdout a.c
typedef struct A { char a[4]; } A;
extern char a[2];
void f (void)
{
*(A*)a = (A){ 1, 2, 3, 4 }; // missing warning
}
typedef struct B { int a[2]; } B;
void g (void)
{
*(B*)a = (B){ 1, 2 }; // missing warning
}
;; Function f (f, funcdef_no=0, decl_uid=3910, cgraph_uid=1, symbol_order=0)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2
;; 2 succs { 1 }
void f ()
{
[local count: 1073741824]:
MEM[(struct A *)&a].a[0] = 1;
MEM[(struct A *)&a].a[1] = 2;
MEM[(struct A *)&a].a[2] = 3;
MEM[(struct A *)&a].a[3] = 4;
return;
}
;; Function g (g, funcdef_no=1, decl_uid=3917, cgraph_uid=2, symbol_order=1)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2
;; 2 succs { 1 }
void g ()
{
[local count: 1073741824]:
MEM[(struct B *)&a].a[0] = 1;
MEM[(struct B *)&a].a[1] = 2;
return;
}
[Bug ipa/101257] [11/12 Regression] Maybe wrong code since IPA mod ref was introduced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101257 --- Comment #5 from Gregory Tucker --- (In reply to Andrew Pinski from comment #4) > (In reply to Gregory Tucker from comment #2) > > Created attachment 51165 [details] > > I think: > uint32_t *w = (uint32_t *) data; > > Should need the may_alias attribute added to it. Thanks for looking at the test case. Indeed adding may_alias to w will fix.
[Bug middle-end/101468] [12 regression] new Wstringop-overflow tests failures since r12-2338
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101468 --- Comment #1 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:94ba897be8b59ef5926eed4c77fd53812fb20add commit r12-2372-g94ba897be8b59ef5926eed4c77fd53812fb20add Author: Martin Sebor Date: Fri Jul 16 11:08:58 2021 -0600 PR testsuite/101468 - Wstringop-overflow tests failures gcc/testsuite/ChangeLog: PR testsuite/101468 * gcc.dg/Wstringop-overflow-41.c: Adjust to avoid target-specific failures. * gcc.dg/Wstringop-overflow-42.c: Same. * gcc.dg/Wstringop-overflow-68.c: Same. * gcc.dg/Wstringop-overflow-70.c: Same. * gcc.dg/Wstringop-overflow-71.c: Same. * gcc.dg/strlenopt-95.c: Fix typos.
[Bug testsuite/101468] [12 regression] new Wstringop-overflow tests failures since r12-2338
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101468 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Component|middle-end |testsuite --- Comment #2 from Martin Sebor --- The failures should all be fixed by r12-2372. The xfails remain until I either fix the underlying problem or find some way other than hardwiring target names to distinguish the targets where the assertions fails from those where they don't.
[Bug c/101453] ICE on compilable code: *** buffer overflow detected ***: terminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101453 Andrew Pinski changed: What|Removed |Added URL|https://gcc.gnu.org/piperma |https://gcc.gnu.org/piperma |il/gcc-patches/2021-July/57 |il/gcc-patches/2021-July/57 |5387.html |5484.html --- Comment #3 from Andrew Pinski --- Updated patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575484.html
[Bug c/101453] ICE on compilable code: *** buffer overflow detected ***: terminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101453 --- Comment #4 from CVS Commits --- The master branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:e06b1c5ac00b1bd0339739d3d9377c90852a83c9 commit r12-2373-ge06b1c5ac00b1bd0339739d3d9377c90852a83c9 Author: Andrew Pinski Date: Thu Jul 15 18:07:09 2021 -0700 Fix PR 101453: ICE with optimize and large integer constant The problem is the buffer is too small to hold "-O" and the interger. This fixes the problem by use the correct size instead. Changes since v1: * v2: Use HOST_BITS_PER_LONG and just divide by 3 instead of 3.32. OK? Bootstrapped and tested on x86_64-linux with no regressions. gcc/c-family/ChangeLog: PR c/101453 * c-common.c (parse_optimize_options): Use the correct size for buffer.
[Bug c/101453] ICE on compilable code: *** buffer overflow detected ***: terminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101453 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Andrew Pinski --- Fixed on the trunk.
[Bug fortran/100949] [9/10/11/12 Regression] ICE in gfc_conv_expr_present, at fortran/trans-expr.c:1975
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100949 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:4669f3830fc80921b0e8a0a8d45451820283cc46 commit r10-9985-g4669f3830fc80921b0e8a0a8d45451820283cc46 Author: Harald Anlauf Date: Wed Jul 14 17:25:29 2021 +0200 Fortran - ICE in gfc_conv_expr_present initializing non-dummy class variable gcc/fortran/ChangeLog: PR fortran/100949 * trans-expr.c (gfc_trans_class_init_assign): Call gfc_conv_expr_present only for dummy variables. gcc/testsuite/ChangeLog: PR fortran/100949 * gfortran.dg/pr100949.f90: New test. (cherry picked from commit 269ca408e2839d7f3554a91515d73d4d95352f68)
[Bug sanitizer/101476] New: AddressSanitizer check failed, points out a (potentially) non-existing stack error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101476 Bug ID: 101476 Summary: AddressSanitizer check failed, points out a (potentially) non-existing stack error Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: franek.balcerak at o2 dot pl CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Created attachment 51167 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51167&action=edit the preprocessed file Is an issue with GCC 10.3 and GCC 11.1 C language x86_64-linux-gnu Ubuntu 11.1.0-1ubuntu1~21.04 Configured with: ../src/configure -v --with-pkgversion='Ubuntu 11.1.0-1ubuntu1~21.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-11 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-11-RPS7jb/gcc-11-11.1.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-RPS7jb/gcc-11-11.1.0/debian/tmp-gcn/usr --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-serialization=2 Command: gcc bug.i -o bug -fsanitize=address -pthread && ./bug Output: ==164550==AddressSanitizer CHECK failed: ../../../../src/libsanitizer/asan/asan_thread.cpp:367 "((ptr[0] == kCurrentStackFrameMagic)) != (0)" (0x0, 0x0) #0 0x7f649a4fdd68 in AsanCheckFailed ../../../../src/libsanitizer/asan/asan_rtl.cpp:74 #1 0x7f649a51e69e in __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) ../../../../src/libsanitizer/sanitizer_common/sanitizer_termination.cpp:78 #2 0x7f649a5034ec in __asan::AsanThread::GetStackFrameAccessByAddr(unsigned long, __asan::AsanThread::StackFrameAccess*) ../../../../src/libsanitizer/asan/asan_thread.cpp:367 #3 0x7f649a46deab in __asan::GetStackAddressInformation(unsigned long, unsigned long, __asan::StackAddressDescription*) ../../../../src/libsanitizer/asan/asan_descriptions.cpp:203 #4 0x7f649a46f2e8 in __asan::AddressDescription::AddressDescription(unsigned long, unsigned long, bool) ../../../../src/libsanitizer/asan/asan_descriptions.cpp:455 #5 0x7f649a46f2e8 in __asan::AddressDescription::AddressDescription(unsigned long, unsigned long, bool) ../../../../src/libsanitizer/asan/asan_descriptions.cpp:439 #6 0x7f649a471a94 in __asan::ErrorGeneric::ErrorGeneric(unsigned int, unsigned long, unsigned long, unsigned long, unsigned long, bool, unsigned long) ../../../../src/libsanitizer/asan/asan_errors.cpp:389 #7 0x7f649a4fd385 in __asan::ReportGenericError(unsigned long, unsigned long, unsigned long, unsigned long, bool, unsigned long, unsigned int, bool) ../../../../src/libsanitizer/asan/asan_report.cpp:476 #8 0x7f649a494038 in __interceptor_sigaltstack ../../../../src/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:9996 #9 0x7f649a512bfd in __sanitizer::UnsetAlternateSignalStack() ../../../../src/libsanitizer/sanitizer_common/sanitizer_posix_libcdep.cpp:194 #10 0x7f649a5029ec in __asan::AsanThread::Destroy() ../../../../src/libsanitizer/asan/asan_thread.cpp:104 #11 0x7f649a426430 in __nptl_deallocate_tsd nptl/pthread_create.c:303 #12 0x7f649a427470 in __nptl_deallocate_tsd nptl/pthread_create.c:258 #13 0x7f649a427470 in start_thread nptl/pthread_create.c:484 #14 0x7f649a349d52 in clone (/lib/x86_64-linux-gnu/libc.so.6+0x117d52) .i file attached. Additional notes: does not trigger a segfault when not using a sanitizer. Removing the sanitizer and then adding the -fstack-protector-all flag does not crash the program. That makes me think it might not be a problem with the code.
[Bug fortran/100949] [9/10/11/12 Regression] ICE in gfc_conv_expr_present, at fortran/trans-expr.c:1975
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100949 --- Comment #7 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:1847a11f4ad8960a57384ed1ef2d0292c65166ed commit r9-9627-g1847a11f4ad8960a57384ed1ef2d0292c65166ed Author: Harald Anlauf Date: Wed Jul 14 17:25:29 2021 +0200 Fortran - ICE in gfc_conv_expr_present initializing non-dummy class variable gcc/fortran/ChangeLog: PR fortran/100949 * trans-expr.c (gfc_trans_class_init_assign): Call gfc_conv_expr_present only for dummy variables. gcc/testsuite/ChangeLog: PR fortran/100949 * gfortran.dg/pr100949.f90: New test. (cherry picked from commit 269ca408e2839d7f3554a91515d73d4d95352f68)
[Bug fortran/100949] [9/10/11/12 Regression] ICE in gfc_conv_expr_present, at fortran/trans-expr.c:1975
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100949 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from anlauf at gcc dot gnu.org --- Fixed on all open branches. Closing. Thanks for the report!
[Bug c++/99664] Overriding virtual function with different return type (and not covariant) is allowed to compile, when it shouldn’t be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99664 --- Comment #4 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:d04b0c75794545f1f7a942764285e21eaf2915a1 commit r12-2377-gd04b0c75794545f1f7a942764285e21eaf2915a1 Author: Patrick Palka Date: Fri Jul 16 16:21:10 2021 -0400 c++: covariant reference return types [PR99664] This implements the wording changes of CWG 960 which clarifies that two reference types are covariant only if they're both lvalue references or both rvalue references. DR 960 PR c++/99664 gcc/cp/ChangeLog: * search.c (check_final_overrider): Compare TYPE_REF_IS_RVALUE when the return types are references. gcc/testsuite/ChangeLog: * g++.dg/inherit/covariant23.C: New test.
[Bug c++/101233] ICE when using ::ranges::v3::to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101233 --- Comment #7 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:a8b3861496bffae8b813ea196c1c5b27f79fbe69 commit r12-2378-ga8b3861496bffae8b813ea196c1c5b27f79fbe69 Author: Patrick Palka Date: Fri Jul 16 16:21:13 2021 -0400 c++: alias CTAD in unevaluated context [PR101233] This is the alias CTAD version of the CTAD bug PR93248, and the fix is the same: clear cp_unevaluated_operand so that the entire chain of DECL_ARGUMENTS gets substituted. PR c++/101233 gcc/cp/ChangeLog: * pt.c (alias_ctad_tweaks): Clear cp_unevaluated_operand for substituting DECL_ARGUMENTS. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/class-deduction-alias10.C: New test.
[Bug c++/99664] Overriding virtual function with different return type (and not covariant) is allowed to compile, when it shouldn’t be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99664 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |12.0 Resolution|--- |FIXED --- Comment #5 from Patrick Palka --- Fixed for GCC 12.
[Bug c++/66968] Incorrect template argument shown in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66968
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2017-08-21 00:00:00 |2021-7-16
--- Comment #5 from Jonathan Wakely ---
Seen with std::tuple and std::get too:
t2.C:38:16: error: use of deleted function 'typename enable_if<(i >= sizeof...
(Elements))>::type get(const tuple&) [with long unsigned int i =
1; Elements = {int}; typename enable_if<(i >= sizeof... (Elements))>::type =
void]'
It should be _Elements, but it shows _Types.
[Bug c++/101477] New: Wrong location for unexpanded parameter pack in function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101477
Bug ID: 101477
Summary: Wrong location for unexpanded parameter pack in
function template
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
template
class tuple
{ };
template
tuple
get(const tuple& t)
{
return t;
}
The error shows the wrong location:
t2.C:7:30: error: parameter packs not expanded with '...':
7 | get(const tuple&)
| ^
t2.C:7:30: note: 'Elements'
This case is especially confusing because the caret *almost* points to a
location where the pack *is* expanded, making it harder to spot the real
problem on the line above.
It should be:
t2.C:7:30: error: parameter packs not expanded with '...':
6 | tuple
| ^~~~
t2.C:7:30: note: 'Elements'
Even better would be to give a fix-it hint suggesting to add the ... after
Element, although that might be counterproductive sometimes. For example, in
this case the compiler probably won't guess where to put the ...
template
std::conjunction>
get(const tuple& t)
{
return t;
}
The user probably wants std::conjunction...> not
std::conjunction>.
[Bug c++/101477] Wrong location for unexpanded parameter pack in function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101477 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-07-16 See Also||https://bugs.llvm.org/show_ ||bug.cgi?id=51118 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug c/101478] New: ICE on invalid code: recompute_tree_invariant_for_addr_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101478
Bug ID: 101478
Summary: ICE on invalid code:
recompute_tree_invariant_for_addr_expr
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: cnsun at uwaterloo dot ca
Target Milestone: ---
This might be a duplicate of PR 84244. But that issue has a fortran test
program.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.K5cVOXlrxH-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210716 (experimental) [master revision
:2c298de71:d97d71a1989e9ee8e1b8563b351c42b7732da108] (GCC)
$ cat mutant.c
struct obj {
int n;
list l;
} main() {
obj o = (struct obj *)((char *)({ 1; }) - (char *)&((struct obj *)0)->l);
}
$ gcc-trunk mutant.c
mutant.c:3:3: error: unknown type name ‘list’
3 | list l;
| ^~~~
mutant.c: In function ‘main’:
mutant.c:5:3: error: unknown type name ‘obj’; use ‘struct’ keyword to refer to
the type
5 | obj o = (struct obj *)((char *)({ 1; }) - (char *)&((struct obj
*)0)->l);
| ^~~
| struct
mutant.c:5:26: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
5 | obj o = (struct obj *)((char *)({ 1; }) - (char *)&((struct obj
*)0)->l);
| ^
mutant.c:5:11: warning: initialization of ‘int’ from ‘struct obj *’ makes
integer from pointer without a cast [-Wint-conversion]
5 | obj o = (struct obj *)((char *)({ 1; }) - (char *)&((struct obj
*)0)->l);
| ^
mutant.c:5:11: internal compiler error: in
recompute_tree_invariant_for_addr_expr, at tree.c:4795
5 | obj o = (struct obj *)((char *)({ 1; }) - (char *)&((struct obj
*)0)->l);
|
^~~~
0x7d4928 recompute_tree_invariant_for_addr_expr(tree_node*)
/tmp/tmp.K5cVOXlrxH-gcc-builder/gcc/gcc/tree.c:4795
0xc58424 gimplify_addr_expr
/tmp/tmp.K5cVOXlrxH-gcc-builder/gcc/gcc/gimplify.c:6239
0xc4ae1f gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.K5cVOXlrxH-gcc-builder/gcc/gcc/gimplify.c:14257
0xc4a55b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.K5cVOXlrxH-gcc-builder/gcc/gcc/gimplify.c:14515
0xc4a55b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.K5cVOXlrxH-gcc-builder/gcc/gcc/gimplify.c:14515
0xc56f4f gimplify_modify_expr
/tmp/tmp.K5cVOXlrxH-gcc-builder/gcc/gcc/gimplify.c:5807
0xc4a2e0 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.K5cVOXlrxH-gcc-builder/gcc/gcc/gimplify.c:14210
0xc4dcca gimplify_stmt(tree_node**, gimple**)
/tmp/tmp.K5cVOXlrxH-gcc-builder/gcc/gcc/gimplify.c:6869
0xc51057 gimplify_and_add(tree_node*, gimple**)
/tmp/tmp.K5cVOXlrxH-gcc-builder/gcc/gcc/gimplify.c:494
0xc51057 gimplify_decl_expr
/tmp/tmp.K5cVOXlrxH-gcc-builder/gcc/gcc/gimplify.c:1831
0xc4ae06 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.K5cVOXlrxH-gcc-builder/gcc/gcc/gimplify.c:14407
0xc4dcca gimplify_stmt(tree_node**, gimple**)
/tmp/tmp.K5cVOXlrxH-gcc-builder/gcc/gcc/gimplify.c:6869
0xc4e4fe gimplify_bind_expr
/tmp/tmp.K5cVOXlrxH-gcc-builder/gcc/gcc/gimplify.c:1426
0xc4b4dc gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/tmp/tmp.K5cVOXlrxH-gcc-builder/gcc/gcc/gimplify.c:14411
0xc4dcca gimplify_stmt(tree_node**, gimple**)
/tmp/tmp.K5cVOXlrxH-gcc-builder/gcc/gcc/gimplify.c:6869
0xc4f2f3 gimplify_body(tree_node*, bool)
/tmp/tmp.K5cVOXlrxH-gcc-builder/gcc/gcc/gimplify.c:15443
0xc4f741 gimplify_function_tree(tree_node*)
/tmp/tmp.K5cVOXlrxH-gcc-builder/gcc/gcc/gimplify.c:15597
0xaa2467 cgraph_node::analyze()
/tmp/tmp.K5cVOXlrxH-gcc-builder/gcc/gcc/cgraphunit.c:670
0xaa5341 analyze_functions
/tmp/tmp.K5cVOXlrxH-gcc-builder/gcc/gcc/cgraphunit.c:1234
0xaa5e21 symbol_table::finalize_compilation_unit()
/tmp/tmp.K5cVOXlrxH-gcc-builder/gcc/gcc/cgraphunit.c:2508
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.
[Bug c/101479] New: vectorized impossible conditional floating point operations still cause traps (-ffast-math, -O3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101479
Bug ID: 101479
Summary: vectorized impossible conditional floating point
operations still cause traps (-ffast-math, -O3)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: Simon.Thornington at tssecurities dot com
Target Milestone: ---
On all versions of gcc I could test, a vectorized operation of the form
y = could_be_zero ? 1.0 : (1.0 / x);
in a loop will still cause an FE_DIVBYZERO, even if x_not_zero is correctly set
to true whenever x could be 0.
This is with -ffast-math and -O3. With -fno-tree-vectorize it does not occur.
If I make could_be_zero volatile, it does not occur. If I insert a "compiler
fence" in the loop it also does not occur. At -O2 it doesn't happen either.
Reproduction:
#include
#include
#include
#include
#include
#define FPCHECK_FORMAT(fmt, ...) \
do { \
int flags = fetestexcept(FE_INVALID | FE_DIVBYZERO | FE_OVERFLOW); \
if (flags) { \
printf("Floating point exception(s) detected:%s%s%s: %s (%s:%d) " fmt,
\
(flags & FE_INVALID) ? " FE_INVALID" : "", \
(flags & FE_DIVBYZERO) ? " FE_DIVBYZERO" : "", \
(flags & FE_OVERFLOW) ? " FE_OVERFLOW" : "", \
__func__, \
__FILE__, \
__LINE__, ## __VA_ARGS__); \
abort(); \
} \
} while(false) \
#define FPCHECK() FPCHECK_FORMAT("")
#define fpcheck(where) FPCHECK_FORMAT("%s", where)
#define compiler_fence() __asm__ __volatile__ ("" : : : "memory")
static bool close_to_zero(double x) {
return fabs(x) < 0.5;
}
void f(double *x, double *y, int n) {
fpcheck("before");
for (int i=0; i
[Bug c/101479] vectorized impossible conditional floating point operations still cause traps (-ffast-math, -O3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101479 --- Comment #1 from Simon Thornington --- x_not_zero -> could_be_zero sorry
[Bug tree-optimization/101479] vectorized impossible conditional floating point operations still cause traps (-ffast-math, -O3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101479 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- -ffast-math enables -fno-trapping-math which means floating point will not introduce any traps and assumes fetestexcept will not matter.
[Bug tree-optimization/101479] vectorized impossible conditional floating point operations still cause traps (-ffast-math, -O3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101479 --- Comment #3 from Andrew Pinski --- If you want -ffast-math and fetestexcept still, add -ftrapping-math to the end of the command line.
[Bug debug/101470] Support -gline-tables-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101470 Eric Botcazou changed: What|Removed |Added Ever confirmed|0 |1 CC||ebotcazou at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2021-07-16 --- Comment #3 from Eric Botcazou --- > I compared output for a hello world and found that gcc: > - emits a DIE for main, while clang does not > - emits a .debug_aranges section, while clang does not The Ada compiler currently needs both to compute backtraces at -g1.
[Bug ipa/101362] can_change_signature does not consider 'used' attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101362 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-07-16 --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug middle-end/96348] The same "C" program runtime is 50 times longer on Win10 than on Linux.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96348 --- Comment #3 from Andrew Pinski --- So one thing is Windows is LLP64IL32 target while x86_64 Linux is LP64 target. So if you are comparing windows to Linux and use long type, you might be getting the major difference there. There might be other things difference between the two too.
[Bug c++/66968] Incorrect template argument shown in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66968
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:3dbc7b809a62167b36f217ab5f43207be19e5908
commit r12-2379-g3dbc7b809a62167b36f217ab5f43207be19e5908
Author: Jonathan Wakely
Date: Fri Jul 16 20:59:43 2021 +0100
libstdc++: Improve diagnostics for std::get with invalid tuple index
This adds a deleted overload of std::get(const tuple&).
Invalid calls with an out of range index will match the deleted overload
and give a single, clear error about calling a deleted function, instead
of overload resolution errors for every std::get overload in the
library.
This changes the current output of 15+ errors (plus notes and associated
header context) into just two errors (plus context):
error: static assertion failed: tuple index must be in range
error: use of deleted function 'constexpr std::__enable_if_t<(__i >=
sizeof... (_Types))> std::get(const std::tuple<_Types ...>&) [with long
unsigned int __i = 1; _Elements = {int}; std::__enable_if_t<(__i >= sizeof...
(_Types))> = void]'
This seems like a nice improvement, although PR c++/66968 means that
"_Types" is printed in the signature rather than "_Elements".
Signed-off-by: Jonathan Wakely
libstdc++-v3/ChangeLog:
* include/std/tuple (get): Add deleted overload for bad
index.
* testsuite/20_util/tuple/element_access/get_neg.cc: Adjust
expected errors.
[Bug c++/66968] Incorrect template argument shown in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66968 --- Comment #7 from Jonathan Wakely --- To reproduce the std::tuple error above, use this code at r12-2379 #include std::tuple t; auto a = std::get<1>(t);
[Bug target/101393] PowerPC32 inline assembly broken by commit 2d94f7dea9c73ef3c116a0ddc722724578a860fe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393 --- Comment #5 from Segher Boessenkool --- (In reply to Franz Sirl from comment #3) > (In reply to Segher Boessenkool from comment #1) > > The -many is problematic, that is the whole point of this. As in this > > example: on different subtargets there are different machine code > > translations for the same mnemonic! > > But the way gas works there are never 2 active translations for the same > mnemonic, or? Of course. But it means that the meaning of the assembler code depends on the command line flags, unless a .machine statement is given (or equivalent command line flags). Since the compiler always depends on one particular meaning, this won't fly. > Actually, since -many is sticky and always (except when CHECKING_P?? or AIX) > part of ASM_CPU_SPEC, the ".machine ppc" doesn't really help since -many is > also active for the .machine pseudo-op. We want to get rid of -many if at all possible. This isn't possible currently mostly because of inline asm, but at least we can try too not depend on its (very problematic) effects. > Maybe you meant to also remove -many from ASM_CPU_SPEC? In that case we > would have seen at least an assembler error, since there is no dcread for > -mppc. Yeah, we would like to, but then people who *want* to use an insn not supported by the currently selected cpu have to adjust their inline asm code. It isn't clear to me where to warn for this (to nudge such users).
[Bug target/101393] PowerPC32 inline assembly broken by commit 2d94f7dea9c73ef3c116a0ddc722724578a860fe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393
--- Comment #6 from Segher Boessenkool ---
(In reply to Franz Sirl from comment #4)
> How about something along this patch? It's not fully done (no good idea
> about SPEC stuff like "mcpu=7400: -mppc %{!mvsx:%{!maltivec:-maltivec}};"
> yet), but you should get the idea.
What does it mean if you have NULL for the new field? Does that work, even?
If it means there is code in a .c too handle it there, we should use that
*always*, not just for a few entries, since it simplifies things.
> In the the end most of ASM_CPU_SPEC could be removed and also the
> duplication between ASM_CPU_SPEC and driver-rs6000.c could go away.
Maybe? I'd like to see a design for it. Historically, tweaking this stuff
has been very error-prone.
[Bug c++/100138] ICE with constructor constrained (C++20 Concepts) by parameter pack length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100138 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:2e63d08cb9bc001232734eed32e4bc3814a279a9 commit r11-8761-g2e63d08cb9bc001232734eed32e4bc3814a279a9 Author: Patrick Palka Date: Mon May 10 22:33:04 2021 -0400 c++: fn parm pack expansion inside constraint [PR100138] This PR is about CTAD but the underlying problems are more general; CTAD is a good trigger for them because of the necessary substitution into constraints that deduction guide generation entails. In the testcase below, when generating the implicit deduction guide for the constrained constructor template for A, we substitute the generic flattening map 'tsubst_args' into the constructor's constraints. During this substitution, tsubst_pack_expansion returns a rebuilt pack expansion for sizeof...(xs), but doesn't carry over the PACK_EXPANSION_LOCAL_P (and PACK_EXPANSION_SIZEOF_P) flag from the original tree to the rebuilt one. The flag is otherwise unset on the original tree but gets set for the rebuilt tree from make_pack_expansion since at_function_scope_p() is true (we're inside main). This leads to a crash during satisfaction when substituting into the pack expansion because we don't have local_specializations set up (and it'd be set up for us if PACK_EXPANSION_LOCAL_P is unset) Similarly, tsubst_constraint needs to set cp_unevaluated so that the substitution performed therein doesn't rely on local_specializations. This avoids a crash during CTAD for C below. gcc/cp/ChangeLog: PR c++/100138 * constraint.cc (tsubst_constraint): Set up cp_unevaluated. (satisfy_atom): Set up iloc_sentinel before calling cxx_constant_value. * pt.c (tsubst_pack_expansion): When returning a rebuilt pack expansion, carry over PACK_EXPANSION_LOCAL_P and PACK_EXPANSION_SIZEOF_P from the original pack expansion. gcc/testsuite/ChangeLog: PR c++/100138 * g++.dg/cpp2a/concepts-ctad4.C: New test. (cherry picked from commit e7a9f085ffd34b0d7bc4b803c182b41494f609aa)
[Bug c++/101233] ICE when using ::ranges::v3::to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101233 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:9107b139f4492d504df37e943882405e6aefdb7e commit r11-8762-g9107b139f4492d504df37e943882405e6aefdb7e Author: Patrick Palka Date: Fri Jul 16 16:21:13 2021 -0400 c++: alias CTAD in unevaluated context [PR101233] This is the alias CTAD version of the CTAD bug PR93248, and the fix is the same: clear cp_unevaluated_operand so that the entire chain of DECL_ARGUMENTS gets substituted. PR c++/101233 gcc/cp/ChangeLog: * pt.c (alias_ctad_tweaks): Clear cp_unevaluated_operand for substituting DECL_ARGUMENTS. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/class-deduction-alias10.C: New test. (cherry picked from commit a8b3861496bffae8b813ea196c1c5b27f79fbe69)
[Bug tree-optimization/101226] Suboptimal codegen for >>/>>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101226
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Component|d |tree-optimization
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2021-07-16
Keywords||missed-optimization
CC||pinskia at gcc dot gnu.org
Assignee|ibuclaw at gdcproject dot org |unassigned at gcc dot
gnu.org
--- Comment #1 from Andrew Pinski ---
_2 = (uint) value.1_1;
_3 = _2 >> 5;
_4 = (ubyte) _3;
Right this could be optimized at the tree level to be :
_4 = value.1_1 >> 5;
Something like this for match.pd (note this is not fully correct just close
enough for someone else to start):
(simplify
(convert (shift (convert@0 @1) INTEGER_CST@2))
(if (type == TREE_TYPE (@0) && TYPE_SIGN (TREE_TYPE(@0) == TYPE_SIGN (type))
(if (@2 >= bitsintype(type))
({build_zero_cst (type);})
(shift @1 @2
[Bug c++/100138] ICE with constructor constrained (C++20 Concepts) by parameter pack length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100138 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |11.2 --- Comment #4 from Patrick Palka --- Fixed for GCC 11.2 and 12.
[Bug c++/101233] ICE when using ::ranges::v3::to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101233 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |11.2 Resolution|--- |FIXED --- Comment #9 from Patrick Palka --- Fixed for GCC 11.2 and 12.
[Bug c++/101480] New: Miscompiled code involving operator new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101480
Bug ID: 101480
Summary: Miscompiled code involving operator new
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Target Milestone: ---
The following test case works correctly with gcc 10.3 (with any of -O0, -O1, or
-O3) and works with gcc 11.1 with -O0, but the assertion at #2 fires with gcc
11.1 with -O1 (and above).
The problem is that setting the flag at #1 (inlined into "f" just before
calling "new") is not performed in the generated machine code, and the
assertion in "operator new" then fails.
#include
#include
static bool flag = false;
class C
{
bool prev;
public:
C() : prev(flag)
{
flag = true; // #1
}
~C() {
flag = prev;
}
};
void* operator new(unsigned long size)
{
assert(flag); // #2
return malloc(size);
}
void operator delete(void *p)
{
free(p);
}
void g(int* p)
{
delete p;
}
void f()
{
int* p;
{
C c;
p = new int;
}
g(p);
}
int main(int, char**)
{
f();
}
[Bug tree-optimization/98956] Failure to optimize out boolean left shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98956 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement --- Comment #2 from Andrew Pinski --- (for cmp (eq ne) (simplify (cmp (lshift truth_value@0 INTEGER_CST@1) zero_p@2) (cmp @0 @2))) Something like the above, might apply to rotate too.
[Bug target/101205] csinv does not have an zero_extend version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101205 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-07-16 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #1 from Andrew Pinski --- Mine.
[Bug c++/96227] Comma operation sequencing issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96227 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-07-16 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed, Note this was partly fixed with the fix for PR 82959. That is not invoked as a function case has been fixed for GCC 8.5. On the trunk we produce as of today: first second SECOND FIRST
[Bug c++/96227] Comma operation sequencing issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96227 Andrew Pinski changed: What|Removed |Added Status|NEW |WAITING --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > Confirmed, Note this was partly fixed with the fix for PR 82959. > That is not invoked as a function case has been fixed for GCC 8.5. > > On the trunk we produce as of today: > first > second > SECOND > FIRST I actually think this is still correct output as the function call version is not mentioned in "If an operator function is invoked using operator notation" here. Am I reading this correctly?
[Bug tree-optimization/101479] vectorized impossible conditional floating point operations still cause traps (-ffast-math, -O3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101479 --- Comment #4 from Simon Thornington --- I'll add that changing close_to_zero from fabs(x) < 0.5 to x == 0.0 || fabs(x) < 0.5 everything starts to work as I'd expect again...
[Bug libfortran/101317] Bind(C): improve error checking in CFI_* functions declared in ISO_Fortran_binding.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101317 --- Comment #1 from sandra at gcc dot gnu.org --- Patch posted: https://gcc.gnu.org/pipermail/fortran/2021-July/056249.html
[Bug tree-optimization/96542] Failure to optimize simple code to a constant when storing part of the operation in a variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96542 --- Comment #7 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:704e8a825c78b9a8424c291509413bbb48e602c7 commit r12-2381-g704e8a825c78b9a8424c291509413bbb48e602c7 Author: Andrew MacLeod Date: Fri Jul 16 11:42:14 2021 -0400 Add wi_fold_in_parts. range-ops uses wi_fold to individually fold subranges one at a time and then combined them. This patch first calls wi_fold_in_parts which checks if one of the subranges is small, and if so, further splits that subrange into constants. gcc/ PR tree-optimization/96542 * range-op.cc (range_operator::wi_fold_in_parts): New. (range_operator::fold_range): Call wi_fold_in_parts. (operator_lshift::wi_fold): Fix broken lshift by [0,0]. * range-op.h (wi_fold_in_parts): Add prototype. gcc/testsuite * gcc.dg/pr96542.c: New.
[Bug tree-optimization/96542] Failure to optimize simple code to a constant when storing part of the operation in a variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96542 Andrew Macleod changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Andrew Macleod --- Range-ops uses wi_fold (implemented by each opcode) to individually fold subranges one at a time and then combines them. This patch first calls wi_fold_in_parts which checks if one of the subranges is small, and if so, further splits that subrange into constants. Currently, if a subrange is 4 or less values, then we call it individually for each of the 4 values. 4 was chosen as a reasonable tradeoff between excess work vs benefit. this gets all 3 cases now. fixed
