[Bug middle-end/90435] gcc generate infinite loop code when using -O2 or -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90435 --- Comment #4 from 庞庆源 --- (In reply to Marc Glisse from comment #3) > (In reply to 庞庆源 from comment #2) > > gcc pmalloc.c -O2 -o ppp -ldl -fno-tree-loop-distribute-patterns > > -fno-strict-aliasing > > Still not work. > > -fno-builtin (the malloc+memset -> calloc is not part of loop distribution) > > > Why I don't see stack overflow if this will trigger function loop calling > > tail call? -fno-builtin is the solution, thanks!
[Bug middle-end/90435] gcc generate infinite loop code when using -O2 or -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90435 庞庆源 changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from 庞庆源 --- Fixed
[Bug libstdc++/90436] Redundant size checking in vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90436 --- Comment #1 from Marc Glisse --- Adding if(size()>max_size())__builtin_unreachable()) sometimes helps, depending where you add it and in what exact form.
[Bug middle-end/90435] gcc generate infinite loop code when using -O2 or -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90435 Andreas Schwab changed: What|Removed |Added Resolution|FIXED |INVALID
[Bug tree-optimization/90437] New: Overflow detection too late for VRP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90437
Bug ID: 90437
Summary: Overflow detection too late for VRP
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
bool f(unsigned a, unsigned b, unsigned*c){
if(a>10)__builtin_unreachable();
if(b>10)__builtin_unreachable();
*c = a + b;
return *c < a;
}
In the .optimized dump, we still have
_9 = .ADD_OVERFLOW (a_2(D), b_3(D));
_1 = REALPART_EXPR <_9>;
_8 = IMAGPART_EXPR <_9>;
*c_5(D) = _1;
_7 = _8 != 0;
return _7;
We have code in VRP to simplify IFN_ADD_OVERFLOW when the arguments have
interesting ranges, but this call only appears in the widening_mul pass. In
this particular case, expand optimizes the code properly, but in general _8
would be used in a GIMPLE_COND and we would have a number of further
optimizations to make.
We could either have an earlier pass than widening_mul detect a+b
[Bug gcov-profile/90438] New: [GCOV] switch statement is not instrumented when "case" body is empty and only "default" body with statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90438
Bug ID: 90438
Summary: [GCOV] switch statement is not instrumented when
"case" body is empty and only "default" body with
statements
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
Target Milestone: ---
$ gcov -v
gcov (GCC) 9.0.1 20190414 (experimental)
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.
$ gcc -O0 -g --coverage small.c; ./a.out; gcov small.c; cat small.c.gcov
File 'small.c'
Lines executed:100.00% of 7
Creating 'small.c.gcov'
-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
1:1:int f(int i)
-:2:{
-:3: int res;
-:4:
-:5: switch (i)
-:6:{
-:7:case 5:
-:8: // res = i - i;
-:9: // break;
-: 10:default:
1: 11: res = i * 2;
1: 12: break;
-: 13:}
-: 14:
1: 15: return res;
-: 16:}
-: 17:
1: 18:int main(void)
-: 19:{
1: 20: f(2);
1: 21: return 0;
-: 22:}
I was wondering that Line #5 in this code should be an instrumentation site.
Thus, I think this line should be marked as executed.
When Line #8 and Line #9 are not removed, Line #5 is became an instrumentation
site as follows:
$ gcc -O0 -g --coverage small.c; ./a.out; gcov small.c; cat small.c.gcov
File 'small.c'
Lines executed:75.00% of 12
Creating 'small.c.gcov'
-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
1:1:int f(int i)
-:2:{
-:3: int res;
-:4:
1:5: switch (i)
-:6:{
#:7:case 5:
#:8: res = i - i;
#:9: break;
1: 10:default:
1: 11: res = i * 2;
1: 12: break;
-: 13:}
-: 14:
1: 15: return res;
-: 16:}
-: 17:
1: 18:int main(void)
-: 19:{
1: 20: f(2);
1: 21: return 0;
-: 22:}
[Bug gcov-profile/90439] New: [GCOV] multiple expression across different lines in if statement is inconsistent when the body is empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90439
Bug ID: 90439
Summary: [GCOV] multiple expression across different lines in
if statement is inconsistent when the body is empty
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: yangyibiao at nju dot edu.cn
CC: marxin at gcc dot gnu.org
Target Milestone: ---
$ gcov -v
gcov (GCC) 9.0.1 20190414 (experimental)
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.
$ cat small.c
void test1 (int x, unsigned u)
{
if ((1U << x) != 64
|| (2 << x) != u
|| (1 << x) == 14
|| (3 << 2) != 12)
; // __builtin_abort ();
}
int main (void)
{
test1 (6, 128U);
}
$ gcc -O0 -g --coverage small.c; ./a.out; gcov small.c; cat small.c.gcov
File 'small.c'
Lines executed:100.00% of 6
Creating 'small.c.gcov'
-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
1:1:void test1 (int x, unsigned u)
-:2:{
1:3: if ((1U << x) != 64
1:4: || (2 << x) != u
-:5: || (1 << x) == 14
-:6: || (3 << 2) != 12)
-:7:; // __builtin_abort ();
1:8:}
-:9:
1: 10:int main (void)
-: 11:{
1: 12: test1 (6, 128U);
-: 13:}
Line #6 is marked as "-" which means that it is not an instrumentation site.
When Line #7 is not removed, it is marked as executed as follows. In other
words, it is now an instrumentation site.
I know that when Line #7 is removed, empty body in if statement will lead to
compiler optimizations. But I am still confused by this inconsistency as Line
#4 and Line #3 are both marked as executed in both situations.
$ gcc -O0 -g --coverage small.c; ./a.out; gcov small.c; cat small.c.gcov
File 'small.c'
Lines executed:87.50% of 8
Creating 'small.c.gcov'
-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
1:1:void test1 (int x, unsigned u)
-:2:{
1:3: if ((1U << x) != 64
1:4: || (2 << x) != u
-:5: || (1 << x) == 14
1:6: || (3 << 2) != 12)
#:7:__builtin_abort ();
1:8:}
-:9:
1: 10:int main (void)
-: 11:{
1: 12: test1 (6, 128U);
-: 13:}
[Bug c/90440] New: Solaris 10 sparcs fails to find
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90440 Bug ID: 90440 Summary: Solaris 10 sparcs fails to find Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jullien at eligis dot com Target Milestone: --- Hi dear maintainers. For years now, I have been able to compile gcc from last working version. On my machine, I currently have a fully working gcc/g++ 8.2.0. Trying to build either 8.3.0 or 9.1.0 it now fails with: fatal error: ext/opt_random.h: No such file or directory ... mkdir -p ./sparc-sun-solaris2.10/bits/extc++.h.gch /export/home/jullien/gcc-8.3.0/obj/./gcc/xgcc -shared-libgcc -B/export/home/jullien/gcc-8.3.0/obj/./gcc -nostdinc++ -L/export/home/jullien/gcc-8.3.0/obj/sparc-sun-solaris2.10/libstdc++-v3/src -L/export/home/jullien/gcc-8.3.0/obj/sparc-sun-solaris2.10/libstdc++-v3/src/.libs -L/export/home/jullien/gcc-8.3.0/obj/sparc-sun-solaris2.10/libstdc++-v3/libsupc++/.libs -B/usr/local/sparc-sun-solaris2.10/bin/ -B/usr/local/sparc-sun-solaris2.10/lib/ -isystem /usr/local/sparc-sun-solaris2.10/include -isystem /usr/local/sparc-sun-solaris2.10/sys-include-x c++-header -nostdinc++ -g -O2 -I/export/home/jullien/gcc-8.3.0/obj/sparc-sun-solaris2.10/libstdc++-v3/include/sparc-sun-solaris2.10 -I/export/home/jullien/gcc-8.3.0/obj/sparc-sun-solaris2.10/libstdc++-v3/include -I/export/home/jullien/gcc-8.3.0/libstdc++-v3/libsupc++ -I/usr/local/include -O2 -g /export/home/jullien/gcc-8.3.0/libstdc++-v3/include/precompiled/extc++.h -o sparc-sun-solaris2.10/bits/extc++.h.gch/O2g.gch In file included from /export/home/jullien/gcc-8.3.0/libstdc++-v3/include/precompiled/extc++.h:62: /export/home/jullien/gcc-8.3.0/obj/sparc-sun-solaris2.10/libstdc++-v3/include/ext/random:3781:10: fatal error: ext/opt_random.h: No such file or directory #include ^~ I use this command: ../configure \ --with-gnu-as--with-as=/usr/local/bin/as \ --with-gnu-ld--with-ld=/usr/local/bin/ld \ --enable-shared \ --disable-lto\ --disable-nls\ --enable-obsolete\ --enable-languages=c,c++ \ --enable-checking=release time make bootstrap-lean a simple "make" also fails Several /ext/opt_random.h exist but none are found by xgcc. You help is welcome. Christian
[Bug debug/90441] New: [9 regression] corrupt debug info with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90441
Bug ID: 90441
Summary: [9 regression] corrupt debug info with LTO
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: needs-bisection
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: hoganmeier at gmail dot com
Target Milestone: ---
Originally occurred with arm-gcc 9.1
Reproduced it with Ubuntu 19.04 gcc 9.0, works with gcc 8.3.
Couldn't reduce it further.
mk20dx128.c:
__attribute__ ((section(".vectors"), used))
_VectorsFlash[100]=
{
};
main.cpp:
void yield();
int main()
{
yield();
}
yield.cpp:
int serial3_available() {}
struct HardwareSerial3 {
int available() { serial3_available(); }
};
HardwareSerial3 Serial3;
void yield()
{
serial3_available();
}
script.ld:
MEMORY
{
FLASH (rx) : ORIGIN = 0x, LENGTH = 4K
}
SECTIONS
{
.text : {
. = 0;
KEEP(*(.vectors))
*(.text*)
} > FLASH = 0xFF
}
gcc-9 -o mk20dx128.c.o -c -flto -g -ffunction-sections -fdata-sections
-nostdlib -O2 teensy3/mk20dx128.c
g++-9 -o main.cpp.o -c -fno-exceptions -fno-rtti -flto -g -ffunction-sections
-fdata-sections -nostdlib -O2 teensy3/main.cpp
g++-9 -o yield.cpp.o -c -fno-exceptions -fno-rtti -flto -g -ffunction-sections
-fdata-sections -nostdlib -O2 yield.cpp
g++-9 -o firmware.elf -g -T script.ld -Wl,--gc-sections,--relax -O2 main.cpp.o
mk20dx128.c.o yield.cpp.o
nm -ClS --radix=d --size-sort firmware.elf
0224 0400 T _VectorsFlashnm: DWARF error: could not
find abbrev number 8
If you remove the 'HardwareSerial3 Serial3;' line the error becomes
DWARF error: info pointer extends beyond end of attributes
[Bug debug/90441] [9 regression] corrupt debug info with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90441 --- Comment #1 from krux --- Created attachment 46343 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46343&action=edit llvm-dwarfdump --verify output FWIW llvm-dwarfdump --verify shows the same errors for both versions, but for gcc-9 it can't resolve the actual strings in the DW_AT_abstract_origin lines.
[Bug debug/90441] [9 regression] corrupt debug info with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90441 --- Comment #2 from krux --- By the way, with 8.3 there is no DWARF error, but nm -l does not show any file location for _VectorsFlash either.
[Bug libstdc++/90442] New: std::pmr::new_delete_resource->allocate results in UBSan error member call on address ... which does not point to an object of type 'memory_resource'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90442
Bug ID: 90442
Summary: std::pmr::new_delete_resource->allocate results in
UBSan error member call on address ... which does not
point to an object of type 'memory_resource'
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: laurynas.biveinis at gmail dot com
Target Milestone: ---
Created attachment 46344
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46344&action=edit
Preprocessed testcase
The following results in an UBSan error:
#include
int main(void) {
auto * const mem = std::pmr::new_delete_resource()->allocate(10);
}
compiled with g++-9 pmr_san.cpp -fsanitize=undefined -std=c++17 -o pmr_san
results in
../gcc-9/pmr_san2.cpp:4:63: runtime error: member call on address
0x00010752d440 which does not point to an object of type 'memory_resource'
0x00010752d440: note: object is of type '*NSt3pmr12_GLOBAL__N_112newdel_res_tE'
01 00 00 00 c8 7e 51 07 01 00 00 00 00 00 00 00 00 00 00 00 e0 ee 50 07 01
00 00 00 98 ee 50 07
^~~
vptr for '*NSt3pmr12_GLOBAL__N_112newdel_res_tE'
/usr/local/Cellar/gcc/9.1.0/include/c++/9.1.0/memory_resource:99:25: runtime
error: member call on address 0x00010752d440 which does not point to an object
of type 'memory_resource'
0x00010752d440: note: object is of type '*NSt3pmr12_GLOBAL__N_112newdel_res_tE'
01 00 00 00 c8 7e 51 07 01 00 00 00 00 00 00 00 00 00 00 00 e0 ee 50 07 01
00 00 00 98 ee 50 07
^~~
vptr for '*NSt3pmr12_GLOBAL__N_112newdel_res_tE'
I am not sure whether this is a libstdc++ or UBSan bug (or if I am doing
something wrong). I am attaching a preprocessed version too.
This looks similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80963,
triggered by Boost implementation of PMR.
[Bug driver/90443] New: -flto=n on Windows results in CreateProcess: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90443
Bug ID: 90443
Summary: -flto=n on Windows results in CreateProcess: No such
file or directory
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: hoganmeier at gmail dot com
Target Milestone: ---
Just using a dummy source:
extern "C"
void _start()
{}
$ arm-none-eabi-g++ -O3 -flto=2 main.cpp -nostdlib -o firmware.elf -v
lto-wrapper.exe: fatal error: CreateProcess: No such file or directory
Very unhelpful. -v lifts the curtain:
make -f Temp\ccwaSVX1.mk -j2 all
lto-wrapper.exe: fatal error: CreateProcess: No such file or directory
There is no make, esp. in arm-gcc distributions.
The error message should be improved.
[Bug d/90444] New: internal compiler error: in d_init_builtins, at d/d-builtins.cc:1121
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90444 Bug ID: 90444 Summary: internal compiler error: in d_init_builtins, at d/d-builtins.cc:1121 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ibuclaw at gdcproject dot org Target Milestone: --- Some back-ends declare va_list as a struct with no name, which is currently unhandled by build_frontend_type(). Configurations that have seen this on: - mips64vr-elf - mipsisa64r2el-elf - mipsisa64sr71k-elf - mipstx39-elf - pdp11-aout - visium-elf
[Bug target/82920] cet test failures on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82920 --- Comment #8 from Iain Sandoe --- Author: iains Date: Sun May 12 19:07:49 2019 New Revision: 271110 URL: https://gcc.gnu.org/viewcvs?rev=271110&root=gcc&view=rev Log: x86 - fix pr82920 The various thunks output codes have inconsisten output mechanisms. The patch factors out some common code that writes out the jumps and uses the regular output scheme that accounts for __USER_LABEL_PREFIX__. The testsuite changes are largely mechanical compensation for the revised output (and the fact that Darwin doesn't use non-PIC by default). gcc/ 2019-05-12 Iain Sandoe PR target/82920 * config/i386/i386.c (ix86_output_jmp_thunk_or_indirect): New. (ix86_output_indirect_branch_via_reg): Use output mechanism accounting for __USER_LABEL_PREFIX__. (ix86_output_indirect_branch_via_push): Likewise. (ix86_output_function_return): Likewise. (ix86_output_indirect_function_return): Likewise. gcc/testsuite/ 2019-05-12 Iain Sandoe Dominique d'Humieres PR target/82920 * gcc.target/i386/indirect-thunk-1.c: Adjust scan-asms for Darwin, do not use -fno-pic on Darwin. * gcc.target/i386/indirect-thunk-2.c: Likewise. * gcc.target/i386/indirect-thunk-3.c: Likewise. * gcc.target/i386/indirect-thunk-4.c: Likewise. * gcc.target/i386/indirect-thunk-7.c: Likewise. * gcc.target/i386/indirect-thunk-attr-1.c: Likewise. * gcc.target/i386/indirect-thunk-attr-2.c: Likewise. * gcc.target/i386/indirect-thunk-attr-3.c: Likewise. * gcc.target/i386/indirect-thunk-attr-4.c: Likewise. * gcc.target/i386/indirect-thunk-attr-5.c: Likewise. * gcc.target/i386/indirect-thunk-attr-6.c: Likewise. * gcc.target/i386/indirect-thunk-attr-7.c: Likewise. * gcc.target/i386/indirect-thunk-attr-8.c: Likewise. * gcc.target/i386/indirect-thunk-extern-1.c: Likewise. * gcc.target/i386/indirect-thunk-extern-2.c: Likewise. * gcc.target/i386/indirect-thunk-extern-3.c: Likewise. * gcc.target/i386/indirect-thunk-extern-4.c: Likewise. * gcc.target/i386/indirect-thunk-extern-7.c: Likewise. * gcc.target/i386/indirect-thunk-inline-1.c: Likewise. * gcc.target/i386/indirect-thunk-inline-2.c: Likewise. * gcc.target/i386/indirect-thunk-inline-3.c: Likewise. * gcc.target/i386/indirect-thunk-inline-4.c: Likewise. * gcc.target/i386/indirect-thunk-inline-7.c: Likewise. * gcc.target/i386/indirect-thunk-register-1.c: Likewise. * gcc.target/i386/indirect-thunk-register-2.c: Likewise. * gcc.target/i386/indirect-thunk-register-3.c: Likewise. * gcc.target/i386/indirect-thunk-register-4.c: Likewise. * gcc.target/i386/ret-thunk-1.c: Likewise. * gcc.target/i386/ret-thunk-10.c: Likewise. * gcc.target/i386/ret-thunk-11.c: Likewise. * gcc.target/i386/ret-thunk-12.c: Likewise. * gcc.target/i386/ret-thunk-13.c: Likewise. * gcc.target/i386/ret-thunk-14.c: Likewise. * gcc.target/i386/ret-thunk-15.c: Likewise. * gcc.target/i386/ret-thunk-16.c: Likewise. * gcc.target/i386/ret-thunk-2.c: Likewise. * gcc.target/i386/ret-thunk-22.c: Likewise. * gcc.target/i386/ret-thunk-23.c: Likewise. * gcc.target/i386/ret-thunk-24.c: Likewise. * gcc.target/i386/ret-thunk-3.c: Likewise. * gcc.target/i386/ret-thunk-4.c: Likewise. * gcc.target/i386/ret-thunk-5.c: Likewise. * gcc.target/i386/ret-thunk-6.c: Likewise. * gcc.target/i386/ret-thunk-7.c: Likewise. * gcc.target/i386/ret-thunk-8.c: Likewise. * gcc.target/i386/ret-thunk-9.c: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-1.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-2.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-3.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-4.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-7.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-1.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-2.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-3.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-4.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-5.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-6.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-7.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-attr-8.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-extern-1.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-extern-2.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-extern-3.c trunk/gcc/testsuite/gcc.target/i386/indirect-thunk-extern-4.c trunk/gcc/testsuite/g
[Bug bootstrap/90418] [10 Regression] powerpc-darwin9 bootstrap fails after r271013
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90418 --- Comment #11 from David Edelsohn --- Created attachment 46345 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46345&action=edit AIX EH sibcall patch This patch seems to fix the EH failures on AIX. Because of Darwin use of save_world, Darwin may need the more invasive change to disable sibcalls.
[Bug bootstrap/90418] [10 Regression] powerpc-darwin9 bootstrap fails after r271013
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90418 --- Comment #12 from Iain Sandoe --- (In reply to David Edelsohn from comment #11) > Created attachment 46345 [details] > AIX EH sibcall patch > > This patch seems to fix the EH failures on AIX. > > Because of Darwin use of save_world, Darwin may need the more invasive > change to disable sibcalls. yes, that's what I'm expecting (so long as Jakub's patch is applied to make calls_eh_return valid at the point of checking - the two-liner I posted will work)
[Bug pch/90306] ICE when using precompiled headers with -MD and -fpch-deps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90306 Andrew Pinski changed: What|Removed |Added Known to fail||7.3.0 --- Comment #3 from Andrew Pinski --- It fails also with GCC 7.3.0. Let me see if I can get a simple testcase.
[Bug d/90445] New: internal compiler error: in d_build_c_type_nodes, at d/d-builtins.cc:783
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90445
Bug ID: 90445
Summary: internal compiler error: in d_build_c_type_nodes, at
d/d-builtins.cc:783
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ibuclaw at gdcproject dot org
Target Milestone: ---
Only seen on pdp11-aout target, happens because SIZE_TYPE is not matched (it's
"short unsigned int" on pdp11).
Should instead set signed_size_type_node from signed_type_for (size_type_node),
matching UINTMAX_TYPE instead for setting {u}intmax_type_node.
[Bug c++/67371] Never executed "throw" in constexpr function fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67371 --- Comment #16 from Jonathan Wakely --- I'd guess it was fixed by the patch for PR 86678.
[Bug libstdc++/90442] std::pmr::new_delete_resource->allocate results in UBSan error member call on address ... which does not point to an object of type 'memory_resource'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90442 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- The type new_del_res_t is derived from memory_resource, so this is a false positive. UBsan can't see the truth, because src/c++17/memory_resource.o in libstdc++.so is not compiled with -fsanitize=undefined.
[Bug d/90446] New: ICE: Segmentation fault in build_function_type at gcc/tree.c:8539
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90446 Bug ID: 90446 Summary: ICE: Segmentation fault in build_function_type at gcc/tree.c:8539 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ibuclaw at gdcproject dot org Target Milestone: --- Only seen on msp430-elf, happens because LANG_HOOKS_TYPE_FOR_MODE is given a PSImode for the BT_UNWINDWORD type, returning NULL, and later segfaults when generating BT_FN_UNWINDWORD_PTR.
[Bug tree-optimization/90447] New: Missed opportunities to use adc (worse when -1 is involved)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90447
Bug ID: 90447
Summary: Missed opportunities to use adc (worse when -1 is
involved)
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: cassio.neri at gmail dot com
Target Milestone: ---
The following are three attempts to get gcc to generate adc instructions from
C++:
#include
unsigned constexpr X = 0;
unsigned f1(unsigned a, unsigned b) {
b += a;
auto c = b < a;
b += X + c;
return b;
}
unsigned f2(unsigned a, unsigned b) {
b += a;
b += X + (b < a);
return b;
}
unsigned f3(unsigned a, unsigned b) {
b += a;
unsigned char c = b < a;
_addcarry_u32(c, b, X, &b);
return b;
}
The 3 functions above (-O3 -std=c++17) generate:
addl%edi, %esi
movl%esi, %eax
adcl$0, %eax
ret
This is great and I would expect that changing X would only affect the
immediate value and nothing more. I was wrong. Changing X to 1, makes f1 and f3
change as I expected but f2 becomes:
f2(unsigned int, unsigned int):
xorl%eax, %eax
addl%edi, %esi
setc%al
addl$1, %eax
addl%esi, %eax
ret
I thought I could blame "b += X + (b < a);" for being undefined behaviour.
However, I believe that, at least in c++17 this is not the case given the
addition of this sentence:
"The right operand is sequenced before the left operand."
to [expr.ass]. As far as Standard C++ is concerned, I expect f1 to be
equivalent to f2.
Things got worse when X == -1:
f1(unsigned int, unsigned int):
xorl %eax, %eax
addl %edi, %esi
setc %al
leal -1(%rax,%rsi), %eax
ret
f2(unsigned int, unsigned int):
xorl %eax, %eax
addl %edi, %esi
setnc %al
subl %eax, %esi
movl %esi, %eax
ret
f3(unsigned int, unsigned int):
addl %esi, %edi
movl $-1, %eax
setc %dl
addb $-1, %dl
adcl %edi, %eax
ret
No adc whatsoever. I'm not an assembly guy but if I understand f3 correctly,
"setc %dl / addb $-1, dl" is simply storing the CF in dl and adding dl to 0xff
to force CF to get the same value it already had before instruction setc was
executed. Basically, this is a convoluted-register-wasteful nop.
I thought the problem could be related to issue [1] but this one has already
being resolved in trunk where this issue also happens and -fno-split-paths
doesn't seem to change anything.
The example in godbold is https://godbolt.org/z/3GUyLj but if you play with the
site's settings (particularly, lib.f) be aware of their issue [2].
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88797 but this
[2] https://github.com/mattgodbolt/compiler-explorer/issues/1377
[Bug c++/90448] New: [8/9/10 Regression] decltype-based lambda parameter pack is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90448
Bug ID: 90448
Summary: [8/9/10 Regression] decltype-based lambda parameter
pack is rejected
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
CC: jakub at gcc dot gnu.org, jason at gcc dot gnu.org,
webrown.cpp at gmail dot com
Target Milestone: ---
+++ This bug was initially created as a clone of Bug #90172 +++
g++ rejects the following testcase which is believed to be valid:
template int fooV(Ts ... ts) {
auto L = [](auto ... a) {
auto M = [](decltype(a) ... b) -> void {
};
return M;
};
decltype(L(L, ts...)) (*fp)(decltype(L), decltype(ts) ...) = L;
return 0;
}
int run2 = fooV("BC", 3, 2.77, 'A', float{}, short{}, unsigned{});
% g++-10.0.0-alpha20190512 -std=c++17 -c mziudrma.cpp
mziudrma.cpp: In instantiation of 'int fooV(Ts ...) [with Ts = {const char*,
int, double, char, float, short int, unsigned int}]':
mziudrma.cpp:13:65: required from here
mziudrma.cpp:3:14: error: expansion pattern 'decltype (#'nontype_argument_pack'
not supported by dump_expr#)' contains no parameter packs
3 | auto M = [](decltype(a) ... b) -> void {
| ^~~
4 | };
| ~
[Bug c++/90172] [8/9/10 Regression] ICE: Segmentation fault (in contains_struct_check)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90172 Arseny Solokha changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Arseny Solokha --- The ICE was likely fixed in PR90265. I've cloned this PR as PR90448 for the rejects-valid part. *** This bug has been marked as a duplicate of bug 90265 ***
[Bug c++/90265] [9/10 Regression] ICE in build_call_a at gcc/cp/call.c:396 since r268377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90265 Arseny Solokha changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #9 from Arseny Solokha --- *** Bug 90172 has been marked as a duplicate of this bug. ***
OGW提%%供%%税%%栗%rc
gcc-bugs@gcc.gnu.org + 快何 可 办 税 票，认 证 后 付 歀。 详 电：李 生，136—6075— 4190， 业 q：157— 533— 2698 ---
[Bug debug/90441] [9 regression] corrupt debug info with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90441 --- Comment #3 from krux --- Finally tried qemu+gdb on the original code: gdb-8.2.1/gdb/dwarf2read.c:9715: internal-error: void dw2_add_symbol_to_list(symbol*, pending**): Assertion `(*listhead) == NULL || (SYMBOL_LANGUAGE ((*listhead)->symbol[0]) == SYMBOL_LANGUAGE (symbol))' failed.
[Bug c++/90449] New: No way to turn off warning about inaccessible base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90449 Bug ID: 90449 Summary: No way to turn off warning about inaccessible base Product: gcc Version: 9.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: david at doublewise dot net Target Milestone: --- It is possible to pass `-w` to gcc to turn off all warnings, but as far as I can tell, there is no way to turn off just the warning "direct base ... inaccessible in ... due to ambiguity". It would be very helpful to me to disable just this one warning, because I really do not want to turn off the other on-by-default warnings. I have a valid use case for needing an ambiguous base class: https://godbolt.org/z/GG7aR9 In summary, it allows me to implement a tuple that is always empty when given no non-empty types. The general idea is that `std::get` would delegate to a member function that accepts an `integral_constant` argument, but each `tuple_value` class has an overload that accepts only the integral constants that matches its `index`. This implementation leads to ambiguous base classes if the user creates a `tuple>`. The base class is inaccessible, but that doesn't mean that all of its member functions are inaccessible because I hid the overload that would have conflicted. The alternative would be to use the more traditional method of implementing `get` by casting `tuple` to `tuple_value, Types...>` and thus having `tuple_value` have all of the types in the tuple as a trailing variadic parameter to ensure uniqueness in tuples of tuples. This allows emptiness in all possible cases at the cost of greatly increased symbol sizes (n^2 template instantiation). clang also warns on this by default, but has the flag `-Wno-inaccessible-base` to turn it off.
[Bug c++/90448] [8/9/10 Regression] decltype-based lambda parameter pack is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90448 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-13 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r251433.
[Bug debug/90441] [9/10 Regression] corrupt debug info with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90441 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||8.3.0 Keywords|needs-bisection | Last reconfirmed||2019-05-13 CC||iains at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 Summary|[9 regression] corrupt |[9/10 Regression] corrupt |debug info with LTO |debug info with LTO Target Milestone|--- |9.2 Known to fail||10.0, 9.1.0 --- Comment #4 from Martin Liška --- Confirmed on x86_64, started with r267373.
[Bug gcov-profile/90439] [GCOV] multiple expression across different lines in if statement is inconsistent when the body is empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90439 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-13 Ever confirmed|0 |1
[Bug gcov-profile/90438] [GCOV] switch statement is not instrumented when "case" body is empty and only "default" body with statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90438
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Martin Liška ---
It's again the same story. As I've already explained you multiple times,
compiler optimizes a dead code even without any optimization level. Thus we end
up with:
f (int i)
{
int res;
int D.1916;
int _3;
:
res_2 = i_1(D) * 2;
:
_3 = res_2;
:
:
return _3;
}
Please do not create such bugs.
[Bug lto/90434] [regression from 8.x] Incorrect code generation for __builtin_strcmp with LTO and freestanding binary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90434 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-05-13 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Hi. Can you please provide a self-contained test-case? Would it be possible to reproduce that on x86_64 with the -ffreestanding option?
[Bug sanitizer/90414] [Feature] Implementing HWASAN (and eventually MTE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90414 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-13 Ever confirmed|0 |1 --- Comment #3 from Martin Liška --- (In reply to Matthew Malcomson from comment #0) > Hello, > > I'm looking into how we can implement MTE in the compiler. > A productive first step could be implementing HWASAN for GCC, which does a > software implementation of MTE using the top-byte-ignore feature. Agree with that, HWASAN can be a first step. > > This has already been implemented in LLVM and the design can be found at the > link below. > https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html > > > Hopefully we can make this change in such a way that will enable the use of > MTE > in the future. > > > I don't know the best approach here, and would appreciate any feedback. > From inspection it looks like most of the work is already handled by ASAN -- > especially in finding all those places that need to be instrumented -- so I > was > looking into what modifications would need to be made from that starting > point. Yes, that is a very common base that be just leveraged a bit. > > > I believe that tagging stack allocated memory can be done in a similar way to > ASAN by expanding the equivalent of ASAN_MARK in a relevant manner. Take a look at asan.c (asan_emit_stack_protection). It's a place where a shadow memory is generated for a stack frame. With HWASAN you won't need to emit red zones, but only tags in shadow memory. > > However, checking memory accesses seems to need a different approach to the > current ASAN one with ASAN_CHECK. > > For both HWASAN and MTE we need to find the tag that a given memory access > should be done through. > In order to produce the best machine-code we would need to associate each > stack > variable with a tag internally. Yes. > In the LLVM implementation this is done by generating a random tag for the > current stack, and associating each stack variable with an increment from > this > tag. > > Also, for MTE the access itself needs to be made with a tagged pointer, which > means the current method of adding instructions before a memory access can't > be > used and instead we need to modify the memory access itself. > > > I have some very basic questions that I would appreciate any help in > answering. > > 1) Where should such passes be put? >I would guess that putting HWASAN and/or MTE passes in the same position > as >the ASAN passes and updating the SANOPT pass to handle any changes would > be >ok, but I don't have a good understanding of why they are in their current >position. Current asan pass is responsible for instrumentation of memory accesses checking (IFN_ASAN_CHECK) and IFN_ASAN_MARK (poisoning/unpoisoning). Sanopt is responsible for lowering of these internal fns and that would be the place where you'll need to tweak. General speaking, you would only need a different instrumentation for: case IFN_ASAN_CHECK: no_next = asan_expand_check_ifn (&gsi, use_calls); break; case IFN_ASAN_MARK: no_next = asan_expand_mark_ifn (&gsi); break; case IFN_ASAN_POISON: no_next = asan_expand_poison_ifn (&gsi, &need_commit_edge_insert, shadow_vars_mapping); > > 2) Can we always find the base object that's being referenced from the gimple >statement where memory is accessed or a pointer is created? >If not, when is it problematic? >Finding the base object is pretty fundamental to getting the tag for a >pointer. >It seems like this should be possible based on a reading of the > documentation >and looking at the TREE_CODEs that the current ASAN `instrument_derefs` >function works on. > >(ARRAY_REF -> first operand is the array > MEM_REF -> first operand is the base > COMPONENT_REF -> first operand is the object > INDIRECT_REF -> first operand is the pointer which should reference > object > VAR_DECL -> this is the object > BIT_FIELD_REF -> first operand is the object) There would be cases where a base is known and for these you could probably instrument checks with a constant known tag. For other situation, you'll probably need to extract the tag from the pointer. Right? > > 3) Would there be any obvious difficulties with a transformation of the form: > _4 = big_arrayD.3771[num_3(D)] > > TO > > _6 = &big_arrayD.3771[num_3(D)]; > _7 = HWASAN_CHECK(6, _6, 4, 4); > _4 = *_7; > >Instead of > _4 = big_ar
[Bug gcov-profile/90438] [GCOV] switch statement is not instrumented when "case" body is empty and only "default" body with statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90438 --- Comment #2 from Yibiao Yang --- (In reply to Martin Liška from comment #1) > It's again the same story. As I've already explained you multiple times, > compiler optimizes a dead code even without any optimization level. Thus we > > Please do not create such bugs. Very sorry for the same bug report. Will avoid in the future. Thank you very much for the detailed explaination.
