)漂/2019年05月27日
代開各行业【普通、增值税】 电、微：139-2552-3045唐经理；gcc-bugs
[Bug middle-end/85598] [7/8 Regression] Incorrect -Wformat-truncation in a loop only at -O2 and -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85598 --- Comment #25 from rguenther at suse dot de --- On Fri, 24 May 2019, msebor at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85598 > > Martin Sebor changed: > >What|Removed |Added > > Known to work||9.0 > Summary|[7/8 Regression] Incorrect |[7/8 Regression] Incorrect >|warning only at -O2 and -O3 |-Wformat-truncation in a >||loop only at -O2 and -O3 > Known to fail||6.3.0, 7.3.0, 8.2.0 > > --- Comment #24 from Martin Sebor --- > I'm guessing this is not going to be backported, correct? I don't see a reason why it could not be.
[Bug debug/90441] [9/10 Regression] corrupt debug info with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90441
--- Comment #25 from rguenther at suse dot de ---
On Sun, 26 May 2019, hoganmeier at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90441
>
> --- Comment #22 from krux ---
> I can also reproduce it without any linker script, simplified code:
>
> int serial3_available() {}
> struct HardwareSerial3 {
> int available() { serial3_available(); }
> };
> HardwareSerial3 Serial3;
>
> void yield() { serial3_available(); }
> int main()
> {
> yield();
> }
>
> $ g++-9 -c -fno-exceptions -fno-rtti -flto -g -O2 main.cpp
> $ g++-9 -o firmware.elf -g -O2 main.o
> $ nm -ClS --radix=d --size-sort firmware.elf
> 4496 0001 T __libc_csu_fininm: DWARF error: could not
> find abbrev number 8
I fear this is the libbfd dwarf reader simply not coping with
DW_AT_abstract_origin in other CUs, being confused as to which
abbrev section it needs to look into (probably using that of
the refering CU instead of the referred to one).
We have
Compilation Unit @ offset 0xce:
Length:0x7a (32-bit)
Version: 4
Abbrev Offset: 0x64
Pointer Size: 8
<0>: Abbrev Number: 1 (DW_TAG_compile_unit)
DW_AT_producer: (indirect string, offset: 0x1ac): GNU
GIMPLE 9.1.
0 -mtune=generic -march=x86-64 -g -O2 -O2 -fno-openmp -fno-openacc
-fno-pie -flt
rans
with 5 abbrev entries refering to the DIE:
Compilation Unit @ offset 0x14c:
Length:0x83 (32-bit)
Version: 4
Abbrev Offset: 0xb9
Pointer Size: 8
<0><157>: Abbrev Number: 1 (DW_TAG_compile_unit)
<158> DW_AT_producer: (indirect string, offset: 0x26f): GNU
C++14 9.1.
0 -mtune=generic -march=x86-64 -g -O2 -fno-exceptions -fno-rtti -flto
...
<1><1aa>: Abbrev Number: 8 (DW_TAG_subprogram)
<1ab> DW_AT_external: 1
<1ab> DW_AT_name: (indirect string, offset: 0x2cc): main
<1af> DW_AT_decl_file : 1
<1b0> DW_AT_decl_line : 8
<1b1> DW_AT_decl_column : 5
<1b2> DW_AT_type: <0x191>
so I think this is a BFD bug and to be filed in sourceware bugzilla
(probably enough to have an actual binary with this kind of DWARF
as testcase).
Disclaimer: I didn't actually see whether my guess above is true
(but it looks so obvious ;))
[Bug middle-end/88784] Middle end is missing some optimizations about unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88784
--- Comment #19 from rguenther at suse dot de ---
On Mon, 27 May 2019, ffengqi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88784
>
> --- Comment #18 from Qi Feng ---
> I only learned gcc for about 2 months, and I have to say that I don't fully
> understand what you guys were saying. Is match.pd the right place to fix this
> issue? Am I in the wrong direction?
Yes, match.pd is the correct place to add this kind of simplifications.
No, please don't use *_{and,or}if codes there if possible. Yes, as
I said upthread it might be necessary to rewrite some of GCCs
infrastructure to get the pattern applied in all situations.
[Bug testsuite/90615] [10 regression] several vector test cases fail starting with r271553
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90615 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |10.0 --- Comment #1 from Richard Biener --- Fixed.
[Bug testsuite/90615] [10 regression] several vector test cases fail starting with r271553
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90615 --- Comment #2 from Richard Biener --- Author: rguenth Date: Mon May 27 07:39:14 2019 New Revision: 271645 URL: https://gcc.gnu.org/viewcvs?rev=271645&root=gcc&view=rev Log: 2019-05-27 Richard Biener PR testsuite/90615 * gcc.dg/vect/costmodel/ppc/costmodel-vect-31b.c: Add -fno-tree-loop-distribute-patterns. * gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c: Likewise. * gcc.dg/vect/costmodel/ppc/costmodel-vect-76a.c: Likewise. * gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c: Likewise. * gcc.dg/vect/costmodel/ppc/costmodel-vect-76c.c: Likewise. * gcc.target/powerpc/vsx-vectorize-1.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-31b.c trunk/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c trunk/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-76a.c trunk/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c trunk/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-vect-76c.c trunk/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-1.c
[Bug target/90616] Suboptimal code generated for accessing an aligned array.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90616 --- Comment #1 from Richard Biener --- Note GCC 5 is no longer maintained. Eventually the target could make use of nonzero_bits knowledge here.
[Bug c++/90617] GCC 9 miscompiles Qt4 "foreach" macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90617 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Richard Biener --- There's a duplicate (closed as INVALID) and upstream is aware of this and fixes are out in the wild.
[Bug target/90619] [10 regression] spec 2017 tests 527.cam4_r and 521.wrf_r segfault while running after r271386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90619 Richard Biener changed: What|Removed |Added Keywords||wrong-code Blocks||26163 Target Milestone|--- |10.0 --- Comment #2 from Richard Biener --- I think there's a duplicate and some Fortran rev. was identified as the cause. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug target/90619] [10 regression] spec 2017 tests 527.cam4_r and 521.wrf_r segfault while running after r271386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90619 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||marxin at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #3 from Martin Liška --- Yes, it's dup of PR90539. Thomas now has a test-case and he's working on a patch. *** This bug has been marked as a duplicate of bug 90539 ***
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 90619, which changed state. Bug 90619 Summary: [10 regression] spec 2017 tests 527.cam4_r and 521.wrf_r segfault while running after r271386 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90619 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539 Martin Liška changed: What|Removed |Added CC||seurer at gcc dot gnu.org --- Comment #27 from Martin Liška --- *** Bug 90619 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/90625] fold strcmp(a, b) == 0 to zero for strings of unequal but non-const lengths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90625 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-27 CC||aph at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Hmm. So I guess the strlen pass would need to track relations of string lengths as it operates down the dominator tree. For example strstr(a, b) is known to return NULL in case strlen(b) > strlen(a) and could be folded to strcmp if strlen(a) == strlen(b)? So not only [in]equalities are interesting. Confirmed. As separately noted in several places GCC misses infrastructure for representing and simplifying relations. I'd build these ontop of tree-affine so we can represent / simplify relations of affine expressions so we can handle a + 5 < b. It would also allow to handle 2*a + b + 3 < c of course, not sure if useful (well, we already have ISL as a build requirement so ...). Extending tree-affine to specify an optional maximum number of sub-expressions might be useful in this context. Consider as other obvious user of such infrastructure the late uninit pass which needs to combine predicates on conditional initialization to see whether it's true (always initialized).
[Bug c++/90640] New: -Wpointer-arith appears to be enabled by default, but is not reported by --help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90640
Bug ID: 90640
Summary: -Wpointer-arith appears to be enabled by default, but
is not reported by --help
Product: gcc
Version: 7.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gennaro.prota+gccbugzilla at gmail dot com
Target Milestone: ---
The following program:
# 1 "pointer_arith_by_default.cpp"
# 1 ""
# 1 ""
# 1 "pointer_arith_by_default.cpp"
int
main()
{
int a = 0 ;
void * p = &a ;
static_cast< void >( p + 1 ) ;
}
compiled, under Cygwin, with the command line below, gives (note the warning):
$ g++ -v -save-temps "pointer_arith_by_default.cpp"
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/7.4.0/lto-wrapper.exe
Target: x86_64-pc-cygwin
Configured with:
/cygdrive/i/szsz/tmpp/gcc/gcc-7.4.0-1.x86_64/src/gcc-7.4.0/configure
--srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-7.4.0-1.x86_64/src/gcc-7.4.0
--prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc
--docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C
--build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin
--without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib
--enable-shared --enable-shared-libgcc --enable-static
--enable-version-specific-runtime-libs --enable-bootstrap --enable-__cxa_atexit
--with-dwarf2 --with-tune=generic
--enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-graphite
--enable-threads=posix --enable-libatomic --enable-libcilkrts --enable-libgomp
--enable-libitm --enable-libquadmath --enable-libquadmath-support
--disable-libssp --enable-libada --disable-symvers --with-gnu-ld --with-gnu-as
--with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix
--without-libintl-prefix --with-system-zlib --enable-linker-build-id
--with-default-libstdcxx-abi=gcc4-compatible --enable-libstdcxx-filesystem-ts
Thread model: posix
gcc version 7.4.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
/usr/lib/gcc/x86_64-pc-cygwin/7.4.0/cc1plus.exe -E -quiet -v -idirafter
/usr/lib/gcc/x86_64-pc-cygwin/7.4.0/../../../../lib/../include/w32api
-idirafter
/usr/lib/gcc/x86_64-pc-cygwin/7.4.0/../../../../x86_64-pc-cygwin/lib/../lib/../../include/w32api
pointer_arith_by_default.cpp -mtune=generic -march=x86-64 -fpch-preprocess -o
pointer_arith_by_default.ii
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-cygwin/7.4.0/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-cygwin/7.4.0/../../../../x86_64-pc-cygwin/include"
ignoring duplicate directory
"/usr/lib/gcc/x86_64-pc-cygwin/7.4.0/../../../../x86_64-pc-cygwin/lib/../lib/../../include/w32api"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-pc-cygwin/7.4.0/include/c++
/usr/lib/gcc/x86_64-pc-cygwin/7.4.0/include/c++/x86_64-pc-cygwin
/usr/lib/gcc/x86_64-pc-cygwin/7.4.0/include/c++/backward
/usr/lib/gcc/x86_64-pc-cygwin/7.4.0/include
/usr/include
/usr/lib/gcc/x86_64-pc-cygwin/7.4.0/../../../../lib/../include/w32api
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
/usr/lib/gcc/x86_64-pc-cygwin/7.4.0/cc1plus.exe -fpreprocessed
pointer_arith_by_default.ii -quiet -dumpbase pointer_arith_by_default.cpp
-mtune=generic -march=x86-64 -auxbase pointer_arith_by_default -version -o
pointer_arith_by_default.s
GNU C++14 (GCC) version 7.4.0 (x86_64-pc-cygwin)
compiled by GNU C version 7.4.0, GMP version 6.1.2, MPFR version
4.0.1-p11, MPC version 1.1.0, isl version isl-0.16.1-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (GCC) version 7.4.0 (x86_64-pc-cygwin)
compiled by GNU C version 7.4.0, GMP version 6.1.2, MPFR version
4.0.1-p11, MPC version 1.1.0, isl version isl-0.16.1-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: fad625746d9e5a9fde6f0a54da0c00b5
pointer_arith_by_default.cpp: In function ‘int main()’:
pointer_arith_by_default.cpp:6:28: warning: pointer of type ‘void *’ used in
arithmetic [-Wpointer-arith]
static_cast< void >( p + 1 ) ;
~~^~~
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
/usr/lib/gcc/x86_64-pc-cygwin/7.4.0/../../../../x86_64-pc-cygwin/bin/as.exe -v
-o pointer_arith_by_default.o pointer_arith_by_default.s
GNU assembler version 2.29.1 (x86_64-pc-cygwin) using BFD version (GNU
Binutils) 2.29.1.20171006
COMPILER_PATH=/usr/lib/gcc/x86_64-pc-cygwin/7.4.0/:/usr/lib/gcc/x86_64-pc-cygwin/7.4.0/:/usr/lib/gcc/x86_64-pc-cygwin/:/usr/lib/gcc/x86_64-pc-cygwin/7.4.0/:/usr/lib/gcc/x86_64-pc-cygwin/:/usr/lib/gcc/x86_64-pc-cygwin/
[Bug tree-optimization/90637] [10 Regression] ICE in vect_loop_versioning, at tree-vect-loop-manip.c:3055
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90637 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-27 CC||jakub at gcc dot gnu.org, ||marxin at gcc dot gnu.org Known to work||9.1.0 Target Milestone|--- |10.0 Ever confirmed|0 |1 Known to fail||10.0 --- Comment #1 from Martin Liška --- Confirmed, started with r271298.
[Bug target/90627] : internal compiler error when compiling cython-generated python3 modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90627 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-05-27 Component|c |target Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- The place of the ICE suggests a problem in target code. Please provide preprocessed source, the attached has #include directives.
[Bug c++/90631] this statement may fall through
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90631 Richard Biener changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-27 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug libgomp/90641] New: libgomp.c-c++-common/lastprivate-conditional-1.c etc FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90641 Bug ID: 90641 Summary: libgomp.c-c++-common/lastprivate-conditional-1.c etc FAIL Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- Target: sparc*-*-solaris2.11 The new libgomp.c-c++-common/lastprivate-conditional-[12].c tests FAIL on 32-bit SPARC: +FAIL: libgomp.c/../libgomp.c-c++-common/lastprivate-conditional-1.c execution test +FAIL: libgomp.c/../libgomp.c-c++-common/lastprivate-conditional-2.c execution test +FAIL: libgomp.c++/../libgomp.c-c++-common/lastprivate-conditional-1.c execution test +FAIL: libgomp.c++/../libgomp.c-c++-common/lastprivate-conditional-2.c execution test Thread 98 received signal SIGSEGV, Segmentation fault. [Switching to Thread 11 (LWP 11)] 0x000132b0 in foo () (gdb) where #0 0x000132b0 in foo () #1 0xff04f22c in gomp_thread_start (xdata=0xffbfcd34) at /vol/gcc/src/hg/trunk/local/libgomp/team.c:123 #2 0xfec54828 in _lwp_start () from /lib/libc.so.1 Backtrace stopped: previous frame identical to this frame (corrupt stack?) SIGSEGV above is due a gdb bug, this is really SIGBUS according to truss 0x000132b0 in foo () 1: x/i $pc => 0x132b0 : sttw %o0, [ %l0 ] (gdb) p/x $o0 $1 = 0x0 (gdb) p/x $l0 $2 = 0x2515c sttw requires 8-byte alignment, so this might be an issue on other strict-alignment targets, too.
[Bug libgomp/90641] libgomp.c-c++-common/lastprivate-conditional-1.c etc FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90641 Rainer Orth changed: What|Removed |Added Target Milestone|--- |10.0
[Bug c++/90640] -Wpointer-arith appears to be enabled by default, but is not reported as enabled by --help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90640 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||marxin at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Martin Liška --- Fixed on trunk in r270788.
[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539 Thomas Koenig changed: What|Removed |Added Status|WAITING |ASSIGNED Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org --- Comment #28 from Thomas Koenig --- https://gcc.gnu.org/ml/fortran/2019-05/msg00173.html reports the same symptoms for netcdf-fortran-4.4.5, presumably due to the same issue. I'll try to fix that one and then see if the SPEC failure disappears along with it. Martin, one additional question: When you step up from the segfault in the executable, is an array constructor passed as an argument somewhere up the call chain? This is what appears to cause the trouble int netcdf.
[Bug libstdc++/90638] Wrong results of pow(complex , T1) function when the T1 type differs from T and from int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90638 --- Comment #3 from Richard Biener --- GCC 7, 8 and 9 for me output (1,1.46292e-09) 2147483647 2147483648 (-1,7.77156e-16) (-1,-1.46292e-09) (1.55377,0.643594) (1.55377,0.643594) (1.55377,0.643594) (1.55377,0.643594) (1.55377,0.643594) (1.55377,0.643594) (1.55377,0.643594) (1.55377,0.643594) (1.55377,0.643594) (1.55377,0.643594) (1.55377,0.643594) (1.55377,0.643594) if this is the correct result this is FIXED. I can confirm your reported result with GCC 4.8 but as said that's out of maintainance. The change in output occurs with GCC 6 so that might be the version this was fixed.
[Bug tree-optimization/90610] [10 Regression] 526.blender_r miscompared on znver1 with -Ofast -march=native since r271463
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90610 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #6 from Richard Biener --- Looking.
[Bug target/90627] : internal compiler error when compiling cython-generated python3 modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90627 --- Comment #2 from bogi788 at hotmail dot com --- Created attachment 46414 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46414&action=edit gcc 8.3.0 preprocessed source The .i file was generated using gcc 8.3.0, since (as mentioned in the bugreport) gcc 9.1.0 writes an almost empty file.
[Bug target/90627] : internal compiler error when compiling cython-generated python3 modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90627 --- Comment #3 from bogi788 at hotmail dot com --- Created attachment 46415 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46415&action=edit gcc 9.1.0 preprocessed source the same file preprocessed with gcc 9.1.0, though i doubt it'll be much help.
[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539 --- Comment #29 from Martin Liška --- (In reply to Thomas Koenig from comment #28) > https://gcc.gnu.org/ml/fortran/2019-05/msg00173.html reports > the same symptoms for netcdf-fortran-4.4.5, presumably due > to the same issue. > > I'll try to fix that one and then see if the SPEC failure disappears > along with it. > > Martin, one additional question: When you step up from the segfault > in the executable, is an array constructor passed as an argument > somewhere up the call chain? This is what appears to cause the trouble > int netcdf. How can I investigate that? Backtrace: #0 0x008f706c in netcdf::nf90_put_var_1d_eightbytereal (ncid=7, varid=23, values=..., start=, count=, stride=, map=...) at netcdf_expanded.f90:1471 #1 0x00453a94 in pionfput_mod::put_var_1d_double (file=..., varid=23, ival=...) at pionfput_mod.fppized.f90:1476 #2 0x00453b06 in pionfput_mod::put_var_vdesc_1d_double (file=..., vardesc=..., ival=...) at pionfput_mod.fppized.f90:2468 #3 0x005be633 in cam_history::h_define (restart=4294949912, t=-17380) at cam_history.fppized.f90:3822 #4 cam_history::wshist (rgnht_in=) at cam_history.fppized.f90:4461 #5 0x007811dc in cam_comp::cam_run4 (cam_out=..., cam_in=..., rstwr=.FALSE., nlend=.FALSE., yr_spec=0, mon_spec=1, day_spec=1, sec_spec=1800) at cam_comp.fppized.f90:325 #6 0x0079d809 in atm_comp_mct::atm_run_mct (eclock=..., cdata_a=..., x2a_a=..., a2x_a=...) at atm_comp_mct.fppized.f90:513 #7 0x007deb03 in ccsm_comp_mod::ccsm_run () at ccsm_comp_mod.fppized.f90:2408 #8 0x00403772 in ccsm_driver () at ccsm_driver.fppized.f90:58 #9 main (argc=argc@entry=1, argv=0x7fffdffe) at ccsm_driver.fppized.f90:25 #10 0x779b6b7b in __libc_start_main (main=0x403740 , argc=1, argv=0x7fffdb98, init=, fini=, rtld_fini=, stack_end=0x7fffdb88) at ../csu/libc-start.c:308 #11 0x004037ba in _start () at ../sysdeps/x86_64/start.S:120 #2 0x00453b06 in pionfput_mod::put_var_vdesc_1d_double (file=..., vardesc=..., ival=...) at pionfput_mod.fppized.f90:2468 2468ierr = put_var_1d_double (File, vardesc%varid, ival) (gdb) info locals ierr =
[Bug target/90627] : internal compiler error when compiling cython-generated python3 modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90627 --- Comment #4 from Martin Liška --- (In reply to bogi788 from comment #2) > Created attachment 46414 [details] > gcc 8.3.0 preprocessed source > > The .i file was generated using gcc 8.3.0, since (as mentioned in the > bugreport) gcc 9.1.0 writes an almost empty file. Do you see the ICE if you use 8.3.0 generated file? Can you please provide output of --verbose?
[Bug c/90628] __builtin_mul_overflow writes to const qualified integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90628 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 46416 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46416&action=edit gcc10-pr90628.patch Untested fix. I think we should apply this to GCC10+ only.
[Bug tree-optimization/90610] [10 Regression] 526.blender_r miscompared on znver1 with -Ofast -march=native since r271463
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90610 --- Comment #7 from Richard Biener --- It's actually cunroll that exposes the issue in zbufclip. Ah, oops.
[Bug c/90628] __builtin_mul_overflow writes to const qualified integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90628 --- Comment #4 from Marc Glisse --- I wonder if in C it should be controlled by -Wdiscarded-qualifiers. I am happy with the unconditional error, just asking.
[Bug c/90628] __builtin_mul_overflow writes to const qualified integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90628
--- Comment #5 from Jakub Jelinek ---
-Wdiscarded-qualifiers is for when the prototype requires pointer to non-const
and pointer to const is passed, which is the case for the clang style builtins,
but not for __builtin_{add,sub,mul}_overflow, where the function is
type-generic.
So I think the error is better.
[Bug target/90627] : internal compiler error when compiling cython-generated python3 modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90627 --- Comment #5 from bogi788 at hotmail dot com --- (In reply to Martin Liška from comment #4) > (In reply to bogi788 from comment #2) > > Created attachment 46414 [details] > > gcc 8.3.0 preprocessed source > > > > The .i file was generated using gcc 8.3.0, since (as mentioned in the > > bugreport) gcc 9.1.0 writes an almost empty file. > > Do you see the ICE if you use 8.3.0 generated file? Can you please provide > output of --verbose? gcc 8.3.0 compiles the source file without error, but gcc 9.1.0 still results in the internal compiler error using gcc 8.3.0's .i file with following output: Using built-in specs. COLLECT_GCC=gcc Target: x86_64-pc-linux-gnu Configured with: /opt/src/gcc-9.1.0/configure --prefix=/opt --disable-multilib --enable-languages=c,c++,lto --with-arch=native --with-system-zlib Thread model: posix gcc version 9.1.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-pthread' '-Wno-unused-result' '-Wsign-compare' '-D' 'NDEBUG' '-g' '-fwrapv' '-O3' '-Wall' '-fdata-sections' '-flto' '-march=native' '-s' '-fPIC' '-c' '-o' 'build/temp.linux-x86_64-3.7/ti/cache/_time.o' '-g0' /opt/libexec/gcc/x86_64-pc-linux-gnu/9.1.0/cc1 -fpreprocessed _time.i -march=x86-64 -mmmx -mno-3dnow -msse -msse2 -msse3 -mno-ssse3 -mno-sse4a -mcx16 -msahf -mno-movbe -mno-aes -mno-sha -mno-pclmul -mno-popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-sgx -mno-bmi2 -mno-pconfig -mno-wbnoinvd -mno-tbm -mno-avx -mno-avx2 -mno-sse4.2 -mno-sse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mno-xsave -mno-xsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mno-clflushopt -mno-xsavec -mno-xsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma -mno-avx512vbmi -mno-avx5124fmaps -mno-avx5124vnniw -mno-clwb -mno-mwaitx -mno-clzero -mno-pku -mno-rdpid -mno-gfni -mno-shstk -mno-avx512vbmi2 -mno-avx512vnni -mno-vaes -mno-vpclmulqdq -mno-avx512bitalg -mno-movdiri -mno-movdir64b -mno-waitpkg -mno-cldemote -mno-ptwrite --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=4096 -mtune=generic -quiet -dumpbase _time.i -auxbase-strip build/temp.linux-x86_64-3.7/ti/cache/_time.o -g -g0 -O3 -Wno-unused-result -Wsign-compare -Wall -version -fwrapv -fdata-sections -flto -fPIC -o /tmp/cchXskmr.s GNU C17 (GCC) version 9.1.0 (x86_64-pc-linux-gnu) compiled by GNU C version 9.1.0, GMP version 6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.21-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C17 (GCC) version 9.1.0 (x86_64-pc-linux-gnu) compiled by GNU C version 9.1.0, GMP version 6.1.2, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.21-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 : internal compiler error: in build_common_tree_nodes, at tree.c:10521
[Bug libgomp/90641] libgomp.c-c++-common/lastprivate-conditional-1.c etc FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90641 --- Comment #1 from Jakub Jelinek --- Does malloc guarantee sufficient alignment for long long? What is offsetof (struct gomp_work_share, inline_ordered_team_ids) on the target?
[Bug c++/90642] New: g++ fails to resolve template function overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90642
Bug ID: 90642
Summary: g++ fails to resolve template function overload
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: oknenavin at outlook dot com
Target Milestone: ---
the following code fails to compile:
template
inline void func(const T&, R...) {}
template
struct S {};
template
inline void func(const S&, R...) {}
int main() {
func(42);
func(S()); // OK
func(S(), 1); // NOK
func(S(), 1); // NOK
}
with:
: In function 'int main()':
:13:21: error: call of overloaded 'func(S, int)' is ambiguous
func(S(), 1); // NOK
^
:13:21: note: candidates are:
:2:17: note: void func(const T&, R ...) [with X = int; T = S;
R = {int}]
inline void func(const T&, R...) {}
^
:8:17: note: void func(const S&, R ...) [with X = int; T = int;
R = {int}]
inline void func(const S&, R...) {}
^
:14:26: error: call of overloaded 'func(S, int)' is ambiguous
func(S(), 1); // NOK
^
...
Reproducible with 4.8.1 and 9.1. Compiles with clang (v3.0.0 and v8.0.0), icc
(v13.0.1 and v19.0.1), msvc (v19.14 and v19.20).
[Bug tree-optimization/90610] [10 Regression] 526.blender_r miscompared on znver1 with -Ofast -march=native since r271463
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90610
--- Comment #8 from Richard Biener ---
Testing
Index: gcc/match.pd
===
--- gcc/match.pd(revision 271644)
+++ gcc/match.pd(working copy)
@@ -5453,8 +5453,8 @@ (define_operator_list COND_TERNARY
first vector we only can insert the first elt from
the first vector. */
at = 0;
- ins = fold_read_from_vector (cop0, 0);
- op0 = op1;
+ if ((ins = fold_read_from_vector (cop0, 0)))
+ op0 = op1;
}
else
{
[Bug tree-optimization/90637] [10 Regression] ICE in vect_loop_versioning, at tree-vect-loop-manip.c:3055
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90637
--- Comment #2 from Jakub Jelinek ---
Cleaned up testcase.
/* PR tree-optimization/90637 */
/* { dg-do compile } */
/* { dg-options "-fopenmp -O1 --param sink-frequency-threshold=90" } */
int v;
void
foo (int c)
{
int i;
#pragma omp for simd if (c) lastprivate (v) schedule (static, 16)
for (i = 0; i < 64; ++i)
v = i;
}
This is something where I had initially punting rather than assert.
I must say what the sinking pass is doing looks very bad, mainly the sinking of
the omp_get_num_threads () from before the outer loop to inside of the outer
loop (but not inner loop), how that can ever be an advantage, instead of
calling it just once, call it several times?
For the reason of the ICE, sinking of the _1 = c_22(D) != 0, perhaps we could
add a hack/workaround to the sink pass not to sink with flag_openmp{,_simd} if
an immediate use is the .GOMP_SIMD_LANE call, or we could try to hoist it out
of the loop again (which wouldn't work if sinking sinks more than one statement
dependent on each other into the loop).
[Bug libstdc++/90634] filesystem::path insane memory allocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90634 --- Comment #7 from baltic <1000hz.radiowave at gmail dot com> --- (In reply to Jonathan Wakely from comment #5) > So don't store them as filesystem::path objects then, store them as strings > and create a path as needed. Type system is here for a reason. And it has advantages to type something, which is naturally a path, as such, not as an arbitrary string. > GCC's implementation creates the path components eagerly, so that > path::iterator meets the requirements of a forward iterator, whereas the > libc++ implementation creates them lazily during iteration, and so is not a > valid forward iterator. It doesn't have to be. See standard 30.11.7.5: A path::iterator is a constant iterator satisfying all the requirements of a bidirectional iterator (27.2.6) except that, for dereferenceable iterators a and b of type path::iterator with a == b, there is no requirement that *a and *b are bound to the same object. Its value_type is path. > The implementations have different trade-offs. That is not a bug. Poorly considered trade-offs are called "bad design" ;) Besides, your implementation breaks the fundamental C++ design principle "you don't pay for what you don't use". now everyone has to pay x10 memory overhead even if they are not ever going to iterate over a path object. I agree, that is not a bug, in C++ world, its a pure crime ;)
[Bug libstdc++/90638] Wrong results of pow(complex , T1) function when the T1 type differs from T and from int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90638
--- Comment #4 from Igor Smirnov ---
Richard, thanks for checks.
Yes this is correct result.
I am wondering, do they correct this problem for complex<> and for inbuilt
types only?
Is there a possibility for you to run the following program on these new
versions and to show the results:
#include
template< class T>
double fun(const T& x, int i)
{
std::cout<<"fun(const T&, int) is working.\n";
return x * i;
}
template< class T>
double fun(const T& x, const T& d)
{
std::cout<<"fun(const T&, const T&) is working.\n";
return x * d;
}
int main(void)
{
std::cout<<"fun(1.1, 1)="<<'\n';
std::cout<
[Bug target/90627] : internal compiler error when compiling cython-generated python3 modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90627 --- Comment #6 from Martin Liška --- Sorry, I can't reproduce that. Maybe you could test a vanilla GCC built from source files?
[Bug target/90627] : internal compiler error when compiling cython-generated python3 modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90627 --- Comment #7 from Martin Liška --- Or you can provide a docker image that will show that?
[Bug tree-optimization/90637] [10 Regression] ICE in vect_loop_versioning, at tree-vect-loop-manip.c:3055
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90637 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- OK, so sinking computes the correct block to sink to in sinkbb = gimple_bb (use); sinkbb = select_best_block (frombb, gimple_bb (use), stmt); if (sinkbb == frombb) return false; *togsi = gsi_for_stmt (use); but then picks 'use' for togsi even though that is in a different block... The following fixes it: Index: gcc/tree-ssa-sink.c === --- gcc/tree-ssa-sink.c (revision 271644) +++ gcc/tree-ssa-sink.c (working copy) @@ -439,7 +439,10 @@ statement_sink_location (gimple *stmt, b if (sinkbb == frombb) return false; - *togsi = gsi_for_stmt (use); + if (sinkbb == gimple_bb (use)) + *togsi = gsi_for_stmt (use); + else + *togsi = gsi_after_labels (sinkbb); return true; }
[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539 --- Comment #30 from Thomas Koenig --- Hi, what I mean is if you use "up" several times and list the source of the calling routines, do you encounter something like call foo([1.0, 2.0, 3.0, 4.0]) or call foo((/1.0, 2.0, 3.0, 4.0/)) ? This is what I see for netcdf, and then I can also understand what goes wrong. Such an array constructor would be in read-only memory, and the current version would try to write back to it on exit - ouch :-)
[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539 --- Comment #31 from Martin Liška --- I see this: (gdb) frame #2 0x00453b06 in pionfput_mod::put_var_vdesc_1d_double (file=..., vardesc=..., ival=...) at pionfput_mod.fppized.f90:2468 2468ierr = put_var_1d_double (File, vardesc%varid, ival) (gdb) up #3 0x005be633 in cam_history::h_define (restart=4294949912, t=-17380) at cam_history.fppized.f90:3822 3822 ierr = pio_put_var (tape(t)%File, ps0var, (/ps0/)) (gdb) up #4 cam_history::wshist (rgnht_in=) at cam_history.fppized.f90:4461 4461 call h_define (t, restart) (gdb) up #5 0x007811dc in cam_comp::cam_run4 (cam_out=..., cam_in=..., rstwr=.FALSE., nlend=.FALSE., yr_spec=0, mon_spec=1, day_spec=1, sec_spec=1800) at cam_comp.fppized.f90:325 325call wshist () (gdb) up #6 0x0079d809 in atm_comp_mct::atm_run_mct (eclock=..., cdata_a=..., x2a_a=..., a2x_a=...) at atm_comp_mct.fppized.f90:513 513 yr_spec=yr_sync, mon_spec=mon_sync, day_spec=day_sync, sec_spec=tod_sync) (gdb) up #7 0x007deb03 in ccsm_comp_mod::ccsm_run () at ccsm_comp_mod.fppized.f90:2408 2408 call atm_run_mct( EClock_a, cdata_aa, x2a_aa, a2x_aa) (gdb) up #8 0x00403772 in ccsm_driver () at ccsm_driver.fppized.f90:58 58 call ccsm_run() (gdb) up #9 main (argc=argc@entry=1, argv=0x7fffdffe) at ccsm_driver.fppized.f90:25 25 use shr_sys_mod, only: shr_sys_abort (gdb) up #10 0x779b6b7b in __libc_start_main (main=0x403740 , argc=1, argv=0x7fffdb98, init=, fini=, rtld_fini=, stack_end=0x7fffdb88) at ../csu/libc-start.c:308 308 result = main (argc, argv, __environ MAIN_AUXVEC_PARAM); (gdb) up #11 0x004037ba in _start () at ../sysdeps/x86_64/start.S:120 120 ../sysdeps/x86_64/start.S: No such file or directory.
[Bug libstdc++/90638] Wrong results of pow(complex , T1) function when the T1 type differs from T and from int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90638 --- Comment #5 from Marc Glisse --- Igor, there are free websites that let you check it for yourself very easily, for instance https://wandbox.org/ , you can test many versions of the compiler online there.
[Bug tree-optimization/90610] [10 Regression] 526.blender_r miscompared on znver1 with -Ofast -march=native since r271463
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90610 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Richard Biener --- Fixed.
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 90610, which changed state. Bug 90610 Summary: [10 Regression] 526.blender_r miscompared on znver1 with -Ofast -march=native since r271463 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90610 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/90610] [10 Regression] 526.blender_r miscompared on znver1 with -Ofast -march=native since r271463
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90610 --- Comment #10 from Richard Biener --- Author: rguenth Date: Mon May 27 10:52:14 2019 New Revision: 271652 URL: https://gcc.gnu.org/viewcvs?rev=271652&root=gcc&view=rev Log: 2019-05-27 Richard Biener PR middle-end/90610 * match.pd (vec_perm): Avoid clobbering op0 when not generating a bit-insert. Modified: trunk/gcc/ChangeLog trunk/gcc/match.pd
[Bug libgomp/90641] libgomp.c-c++-common/lastprivate-conditional-1.c etc FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90641 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Jakub Jelinek --- > Does malloc guarantee sufficient alignment for long long? It does: 8 bytes for 32-bit, 16 bytes for 64-bit with the libc malloc. > What is offsetof (struct gomp_work_share, inline_ordered_team_ids) on the > target? ptype/o shows /* 140 | 0 */unsigned int inline_ordered_team_ids[0]; /* XXX 52-byte padding */
[Bug target/90627] : internal compiler error when compiling cython-generated python3 modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90627 --- Comment #8 from bogi788 at hotmail dot com --- (In reply to Martin Liška from comment #6) > Sorry, I can't reproduce that. Maybe you could test a vanilla GCC built from > source files? This was on gcc 9.1 compiled from source on rhel7. I can't provide a docker image, but I can try compiling gcc on an Arch Linux box.
[Bug target/90627] : internal compiler error when compiling cython-generated python3 modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90627 Martin Liška changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #9 from Martin Liška --- (In reply to bogi788 from comment #8) > (In reply to Martin Liška from comment #6) > > Sorry, I can't reproduce that. Maybe you could test a vanilla GCC built from > > source files? > > This was on gcc 9.1 compiled from source on rhel7. I can't provide a docker > image, but I can try compiling gcc on an Arch Linux box. @Jakub: Can you please reproduce that?
[Bug c++/90643] New: Code works with differences on ICC and GNU++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90643 Bug ID: 90643 Summary: Code works with differences on ICC and GNU++ Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: karaul0v at yandex dot ru Target Milestone: --- Users complain that in GNU ++ very strange incredible errors appear in the game. Which are not in the ICC compilers. How to find code that can work in ICC with other result than in GNU ++? (undefined behaviour?) Any static analyzer can found this problems?
[Bug c++/90643] Code works with differences on ICC and GNU++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90643 Monster changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Monster --- Users complain that in GNU ++ very strange incredible errors appear in the game. Which are not in the ICC compilers. How to find code that can work in ICC with other result than in GNU ++? (undefined behaviour?) Any static analyzer can found this problems?
[Bug libstdc++/90638] Wrong results of pow(complex , T1) function when the T1 type differs from T and from int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90638
--- Comment #6 from Igor Smirnov ---
Mark, thank you for useful advice.
So, my conclusion is that the rules for resolution in the presence of
function templates are not changed in gcc. For all versions of C++
the result generated by this site was the same. The program is compiled without
"call ... is ambiguous" complaints, and calls the variant of the function
for "int" argument when called with long double:
fun(1.1, 1)=
fun(T, int) is working.
1.1
fun(1.1, 1/2.0)=
fun(T, const T&) is working.
0.55
fun(1.1, (long double)1/2.0)=
fun(T, int) is working.
0
This behaviour is counter to logic because an identical program with
with almost identical ordinary functions is NOT compiled with complaint
"prog.cc:21:28: error: call of overloaded 'fun(double, double)' is ambiguous",
see an example below.
Since the user may not even know that the functions are template
(an ordinary function can depend on agruments having a fully specified
template type), he may not notice this error.
#include
double fun(double x, int i)
{
std::cout<<"fun(double, int) is working.\n";
return x * i;
}
double fun(double x, const long double& d)
{
std::cout<<"fun(double, const long double&) is working.\n";
return x * d;
}
int main(void)
{
std::cout<<"fun(1.1, 1)="<<'\n';
std::cout<
[Bug target/90644] New: Call to __builtin_memcmp not folded for identical vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90644
Bug ID: 90644
Summary: Call to __builtin_memcmp not folded for identical
vectors
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: prathamesh3492 at gcc dot gnu.org
Target Milestone: ---
Hi,
For following test-case:
#include
typedef int32_t vnx4si __attribute__((vector_size (32)));
void foo(int a, int b)
{
vnx4si v = (vnx4si) { a, b, 1, 2 };
vnx4si expected = (vnx4si) { a, b, 1, 2 };
if (__builtin_memcmp (&v, &expected, sizeof (vnx4si)) != 0)
__builtin_abort ();
}
-O2 -ftree-vectorize -march=armv8.2-a+sve folds call to __builtin_memcmp
correctly, since both vectors are identical.
But with -msve-vector-bits=256, it fails to fold the call to
__builtin_memcmp().
The issue can also be reproduced with AdvSIMD: Fails to fold the call to
__builtin_memcmp with vector_size == 16 but folds with vector_size == 32.
Thanks,
Prathamesh
[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539 --- Comment #32 from Thomas Koenig --- Hi Martin, this 3822 ierr = pio_put_var (tape(t)%File, ps0var, (/ps0/)) looks like the culprit (or rather, where gfortran currently generates wrong code). This is consistent with the problem seen in netcdf, so I feel pretty confident that this is indeed the problem. To double-check, could you maybe do the following? Assume ps0 is a real(kind=8) variable, do ... real(kind=8) :: ps0_array(1) ! Use the type as ps0 and then ps0_array(1) = ps0 ierr = pio_put_var (tape(t)%File, ps0var, ps0_array) and see if the segfault goes away, or at least if this one has been removed, and there is a different one now :-)
[Bug tree-optimization/90594] [9/10 regression] Spurious popcount emitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90594 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org
[Bug tree-optimization/90594] [9/10 regression] Spurious popcount emitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90594 --- Comment #3 from Richard Biener --- Created attachment 46417 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46417&action=edit prerequesite This is the prerequesite for getting rid of the seprate pass doing final value replacement. It makes DCE elide LC PHI nodes if there's a DEF to eliminate. Note the patch isn't 100% finished because it doesn't yet deal with the undefined overflow issue (easy to add) and I've left out cost considerations (also to incerase coverage for testing). The factoring is also not actually factoring (well, if the pass vanishes...). As followup we'd remove the SCEV cprop pass. There are still other passes that could consider doing final value replacement more aggressively of course (unvectorizable/parallelizable reductions, IVOPTs, etc.). So the chance is that with the DCE approach mainly aiming at pattern detection and loop removal we'd regress elsewhere. I've looked at mitigating the bad decision done for the testcase in this bug in the final value replacement pass itself but doing so doesn't look possible w/o replicating DCE.
[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539 --- Comment #33 from Martin Liška --- (In reply to Thomas Koenig from comment #32) > Hi Martin, > > this > > 3822 ierr = pio_put_var (tape(t)%File, ps0var, (/ps0/)) > > looks like the culprit (or rather, where gfortran currently > generates wrong code). This is consistent with the problem seen > in netcdf, so I feel pretty confident that this is indeed the problem. > > To double-check, could you maybe do the following? Assume ps0 is a > real(kind=8) variable, do > > ... > >real(kind=8) :: ps0_array(1) ! Use the type as ps0 > > and then > > ps0_array(1) = ps0 > ierr = pio_put_var (tape(t)%File, ps0var, ps0_array) > > and see if the segfault goes away, or at least if this one has > been removed, and there is a different one now :-) Yes, I can confirm it helps. I see a segfault later then. Thank you.
[Bug tree-optimization/90644] Call to __builtin_memcmp not folded for identical vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90644 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-27 Component|target |tree-optimization Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- I think we simply miss folding __builtin_memcmp_eq (&x, &y, CST) to x != y for compatible register types x/y and CST equal to the registers size. Of course only for integral typed registers (we might be able to use VIEW_CONVERT_EXPR to convert to an integer [vector] we can compare though). I think there's a related bug to "inline" memcmp_eq if it can be performed with a single register compare (similar to how we inline memcpy). I thought we already do this (but IIRC only for size == 1). Might be we only do this during RTL expansion.
[Bug tree-optimization/90644] Call to __builtin_memcmp not folded for identical vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90644 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug libstdc++/90638] Wrong results of pow(complex , T1) function when the T1 type differs from T and from int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90638
--- Comment #7 from Igor Smirnov ---
There can be still problems with big integer powers of complex numbers in the
latest versions.
I just don't see a single correct answer.
As above the expected correct responses are marked by "should be" and the
received by "actually".
Notations of version started from "C++" are from the above mentioned site:
---
#include
#include
#include
int main(void)
{
double phi = M_PI / LONG_MAX;
std::cout< var0 = std::polar(1.0, phi);
std::cout< vard0 = std::polar((long double)1.0, phid);
std::cout< var1 = std::polar(1.0, phi1);
std::cout<
[Bug target/90627] : internal compiler error when compiling cython-generated python3 modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90627 --- Comment #10 from bogi788 at hotmail dot com --- (In reply to bogi788 from comment #8) > (In reply to Martin Liška from comment #6) > > Sorry, I can't reproduce that. Maybe you could test a vanilla GCC built from > > source files? > > This was on gcc 9.1 compiled from source on rhel7. I can't provide a docker > image, but I can try compiling gcc on an Arch Linux box. gcc 9.1.0 built from the same sources (using the same flags) on arch linux instead of rhel7 compiles the .c file without internal compiler error.
[Bug tree-optimization/90637] [10 Regression] ICE in vect_loop_versioning, at tree-vect-loop-manip.c:3055
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90637 --- Comment #5 from Richard Biener --- Author: rguenth Date: Mon May 27 13:18:12 2019 New Revision: 271661 URL: https://gcc.gnu.org/viewcvs?rev=271661&root=gcc&view=rev Log: 2019-05-27 Richard Biener PR tree-optimization/90637 * tree-ssa-sink.c (statement_sink_location): Honor the computed sink location for single-uses. * gcc.dg/gomp/pr90637.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/gomp/pr90637.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-sink.c
[Bug tree-optimization/90637] [10 Regression] ICE in vect_loop_versioning, at tree-vect-loop-manip.c:3055
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90637 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug libgomp/90641] libgomp.c-c++-common/lastprivate-conditional-1.c etc FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90641 --- Comment #3 from Jakub Jelinek --- Created attachment 46418 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46418&action=edit gcc10-pr90641.patch Untested fix.
[Bug libstdc++/90638] Wrong results of pow(complex , T1) function when the T1 type differs from T and from int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90638 --- Comment #8 from Igor Smirnov --- Let me add corrections to my previous post. 1. It needs to add (long double) before M_PI / LONG_MAX in the line long double phid = M_PI / LONG_MAX; in the above example. But the result is not changed significantly. 2. Two results for the very last expression for C++ and C++17 are correct. 3. In the other expressions only the versions 4.8.5, C++03 and C++03(GNU) give completely wrong results. Do you support "C++03"? The other versions give the correct real component and the imaginary component with wrong sign, but since this component is anyway extremely small, this can be explained by precision problems.
[Bug tree-optimization/88440] size optimization of memcpy-like code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88440 --- Comment #26 from Christophe Lyon --- Author: clyon Date: Mon May 27 13:37:57 2019 New Revision: 271662 URL: https://gcc.gnu.org/viewcvs?rev=271662&root=gcc&view=rev Log: [testsuite,aarch64,arm] PR88440: Fix testcases 2019-05-27 Christophe Lyon PR tree-optimization/88440 gcc/testsuite/ * gcc.target/aarch64/sve/index_offset_1.c: Add -fno-tree-loop-distribute-patterns. * gcc.target/aarch64/sve/single_1.c: Likewise. * gcc.target/aarch64/sve/single_2.c: Likewise. * gcc.target/aarch64/sve/single_3.c: Likewise. * gcc.target/aarch64/sve/single_4.c: Likewise. * gcc.target/aarch64/sve/vec_init_1.c: Likewise. * gcc.target/aarch64/vect-fmovd-zero.c: Likewise. * gcc.target/aarch64/vect-fmovf-zero.c: Likewise. * gcc.target/arm/ivopts.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/aarch64/sve/index_offset_1.c trunk/gcc/testsuite/gcc.target/aarch64/sve/single_1.c trunk/gcc/testsuite/gcc.target/aarch64/sve/single_2.c trunk/gcc/testsuite/gcc.target/aarch64/sve/single_3.c trunk/gcc/testsuite/gcc.target/aarch64/sve/single_4.c trunk/gcc/testsuite/gcc.target/aarch64/sve/vec_init_1.c trunk/gcc/testsuite/gcc.target/aarch64/vect-fmovd-zero.c trunk/gcc/testsuite/gcc.target/aarch64/vect-fmovf-zero.c trunk/gcc/testsuite/gcc.target/arm/ivopts.c
[Bug libgomp/90641] libgomp.c-c++-common/lastprivate-conditional-1.c etc FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90641 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #3 from Jakub Jelinek --- > Created attachment 46418 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46418&action=edit > gcc10-pr90641.patch > > Untested fix. Worked for me: I've rebuilt libgomp with the patch and ran the two affected tests (as C and C++) for 32 and 64-bit. All PASS now. Thanks. Rainer
[Bug go/90614] gcc-9.1.0/libgo/go/syscall/wait.c:54:22: error: unused parameter ‘w’ [-Werror=unused-parameter] Continued (uint32_t *w)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90614 --- Comment #7 from martin --- (In reply to Ian Lance Taylor from comment #6) > Fixed on trunk and GCC 9 branch. Many thanks!
[Bug go/90645] New: sparc-unknown-linux-gnu/libgo/.libs/libgo.so: undefined reference to `fdopendir'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90645 Bug ID: 90645 Summary: sparc-unknown-linux-gnu/libgo/.libs/libgo.so: undefined reference to `fdopendir' Product: gcc Version: 9.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: mfe at live dot de CC: cmang at google dot com Target Milestone: --- the exact version of GCC: gcc-9.1.0 the system type: NetgearReadyNAS Duo (http://wiki.dietpc.org/index.php/DIET-PC_on_SPARC_ReadyNAS) the options given when GCC was configured/built: ../gcc-9.1.0/configure CC=/opt/gcc-7.1/bin/gcc CXX=/opt/gcc-7.1/bin/g++ --enable-languages=c,c++,go --prefix=/opt/gcc-9.1 --with-cpu=v7 --with-mpc=/usr/local --with-mpfr=/usr/local --with-gmp=/usr/local --with-isl=/usr/local/ --disable-libstdcxx-pch --disable-linux-futex --disable-libsanitizer --enable-__cxa_atexit --enable-nls --enable-clocale=gnu --enable-debug --disable-doc --disable-libcilkrts --disable-libitm the complete command line that triggers the bug; /usr/local/bin/make the compiler output (error messages, warnings, etc.); [...] make[2]: Entering directory '/c/backup/fes-readynasduo/gcc-9.1.0-compiled/gotools' /backup/fes-readynasduo/gcc-9.1.0-compiled/./gcc/gccgo -B/backup/fes-readynasduo/gcc-9.1.0-compiled/./gcc/ -B/opt/gcc-9.1/sparc-unknown-linux-gnu/bin/ -B/opt/gcc-9.1/sparc-unknown-linux-gnu/lib/ -isystem /opt/gcc-9.1/sparc-unknown-linux-gnu/include -isystem /opt/gcc-9.1/sparc-unknown-linux-gnu/sys-include -g -O2 -I ../sparc-unknown-linux-gnu/libgo -static-libstdc++ -static-libgcc -L ../sparc-unknown-linux-gnu/libgo -L ../sparc-unknown-linux-gnu/libgo/.libs -o go ../../gcc-9.1.0/gotools/../libgo/go/cmd/go/alldocs.go ../../gcc-9.1.0/gotools/../libgo/go/cmd/go/go11.go ../../gcc-9.1.0/gotools/../libgo/go/cmd/go/main.go ../sparc-unknown-linux-gnu/libgo/libgotool.a ../sparc-unknown-linux-gnu/libgo/.libs/libgo.so: undefined reference to `fdopendir' ../sparc-unknown-linux-gnu/libgo/.libs/libgo.so: undefined reference to `__sync_bool_compare_and_swap_4' ../sparc-unknown-linux-gnu/libgo/.libs/libgo.so: undefined reference to `__tls_get_addr' ../sparc-unknown-linux-gnu/libgo/.libs/libgo.so: undefined reference to `__go_openat' ../sparc-unknown-linux-gnu/libgo/.libs/libgo.so: undefined reference to `fstatat64' collect2: error: ld returned 1 exit status make[2]: *** [Makefile:821: go] Error 1 make[2]: Leaving directory '/c/backup/fes-readynasduo/gcc-9.1.0-compiled/gotools' make[1]: *** [Makefile:15520: all-gotools] Error 2 make[1]: Leaving directory '/c/backup/fes-readynasduo/gcc-9.1.0-compiled' make: *** [Makefile:993: all] Error 2 ldd -r /backup/fes-readynasduo/gcc-9.1.0-compiled/gcc/gccgo libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x2002c000) libm.so.6 => /lib/libm.so.6 (0x20124000) libc.so.6 => /lib/libc.so.6 (0x201b8000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2000) /backup/fes-readynasduo/gcc-9.1.0-compiled/gcc/gccgo --version gccgo (GCC) 9.1.0 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. Not sure which information is important for this bug.
[Bug go/90645] sparc-unknown-linux-gnu/libgo/.libs/libgo.so: undefined reference to `fdopendir'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90645 --- Comment #1 from Andrew Pinski --- >fdopendir() is available in glibc since version 2.4. What glibc version are you using?
[Bug go/90645] sparc-unknown-linux-gnu/libgo/.libs/libgo.so: undefined reference to `fdopendir'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90645 --- Comment #2 from martin --- Created attachment 46419 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46419&action=edit usr\include\bits ldd --version ldd (GNU libc) 2.3.2 Copyright (C) 2003 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. Written by Roland McGrath and Ulrich Drepper.
[Bug target/90627] : internal compiler error when compiling cython-generated python3 modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90627 --- Comment #11 from bogi788 at hotmail dot com --- (In reply to Martin Liška from comment #6) > Sorry, I can't reproduce that. Maybe you could test a vanilla GCC built from > source files? I tried again in a new rhel7 vm, going straight from distibution gcc (4.8.5) to 9.1 rather than upgrading from gcc 8.3. That resulted in a gcc 9.1 that didn't cause an internal compiler error, but since I used the 3 stage build in both cases I'm not sure how that might have caused the problem.
[Bug c++/90646] New: std::filesystem::absolute( "yourpathhere" ) segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90646
Bug ID: 90646
Summary: std::filesystem::absolute( "yourpathhere" ) segfaults
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: myLC at gmx dot net
Target Milestone: ---
This used to work with g++-8.1.0, but segfaults with g++-9.1.0:
std::optional< std::string > Config::read( const std::filesystem::path &path,
const std::string &filename ) {
std::string s;
if( !filename.empty() ) {
std::filesystem::path file( path );
file /= filename;
if( std::filesystem::exists( file ) ) {
std::ifstream input( std::filesystem::absolute( file )
);
std::stringstream buffer;
buffer << input.rdbuf();
if( input.bad() )
goto errout;
s = buffer.str();
}
} else {
errout: return {};
}
return s;
}
Now it crashes at calling "std::filesystem::absolute( file )":
Thread 1 "config_module" received signal SIGSEGV, Segmentation fault.
0x00462b2f in std::unique_ptr::~unique_ptr (
this=0xb, __in_chrg=) at
/usr/include/c++/9/bits/unique_ptr.h:288
288 if (__ptr != nullptr)
(gdb) p __ptr
$1 = (std::filesystem::path::_List::_Impl *&) @0x7fffd1d8: 0x0
(gdb)
[Bug c++/90646] std::filesystem::absolute( "yourpathhere" ) segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90646 --- Comment #1 from myLC at gmx dot net --- Forgot to mention that it's C++20 (-std=c++2a).
[Bug libstdc++/90646] std::filesystem::absolute( "yourpathhere" ) segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90646 Andrew Pinski changed: What|Removed |Added Component|c++ |libstdc++ --- Comment #2 from Andrew Pinski --- Can you provide a compilable example?
[Bug libstdc++/90646] std::filesystem::absolute( "yourpathhere" ) segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90646
--- Comment #3 from myLC at gmx dot net ---
(In reply to Andrew Pinski from comment #2)
> Can you provide a compilable example?
Good point. The example works, hence the problem seems to be somewhere else:
#include
#include
#include
#include
std::optional< std::string > read( const std::filesystem::path &path, const
std::string &filename ) {
std::string s;
if( !filename.empty() ) {
std::filesystem::path file( path );
file /= filename;
if( std::filesystem::exists( file ) ) {
std::ifstream input( std::filesystem::absolute( file )
);
std::stringstream buffer;
buffer << input.rdbuf();
if( input.bad() )
goto errout;
s = buffer.str();
}
} else {
errout: return {};
}
return s;
}
int main( int argc, char **argv ) {
std::string read_write_test;
if( auto rwt = read( "./", argv[ 0 ] ) )
read_write_test = *rwt;
if( !read_write_test.empty() )
std::cout << "fine" << std::endl;
return 0;
}
I need to investigate this further...
[Bug libstdc++/90646] std::filesystem::absolute( "yourpathhere" ) segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90646 myLC at gmx dot net changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #4 from myLC at gmx dot net --- The example works with the same path. The real code is correct, though. I'm guessing this might have something to do with a 3rd-party library corrupting memory, The library needs to be built with the same compiler and options (Nana C++). I need to rebuild that thing and see, if this fixes it. I apologize. I should have created an example first.
[Bug c++/90617] GCC 9 miscompiles Qt4 "foreach" macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90617 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- See PR44715 and https://github.com/qt/qtbase/commit/c35a3f519007af44c3b364b9af86f6a336f6411b
[Bug c++/90647] New: Warn on returning a lambda with captured local variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90647
Bug ID: 90647
Summary: Warn on returning a lambda with captured local
variables
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
Consider the example:
auto test(int s) {
return [&s] { return s; };
}
`s` is a local variable, so we return a lambda that has a dangling reference.
It would be nice to have a warning for such cases.
[Bug c/44715] Break in increment expression of "for" statement inconsistent with g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44715 Andrew Pinski changed: What|Removed |Added CC||bastian.beischer@rwth-aache ||n.de --- Comment #8 from Andrew Pinski --- *** Bug 90617 has been marked as a duplicate of this bug. ***
[Bug c++/90617] GCC 9 miscompiles Qt4 "foreach" macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90617 Andrew Pinski changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #5 from Andrew Pinski --- So mark as a dup of bug 44715. *** This bug has been marked as a duplicate of bug 44715 ***
[Bug c/90648] New: [8/9/10 Regression] ICE tree check: accessed operand 4 of call_expr with 3 operands in generic_simplify_MULT_EXPR, at generic-match.c:27222
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90648
Bug ID: 90648
Summary: [8/9/10 Regression] ICE tree check: accessed operand 4
of call_expr with 3 operands in
generic_simplify_MULT_EXPR, at generic-match.c:27222
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started with gcc-8, compiles with gcc-7 :
$ cat z1.c
extern _Float128 copysignf128 ();
_Float128 foo (_Float128 x)
{
return x * copysignf128 ();
}
$ cat z2.c
extern _Float128 copysignf128 (x);
double foo (double x)
{
return x * copysignf128 ();
}
$ gcc-7 -c z1.c
$
$ gcc-10-20190526 -c z1.c
z1.c: In function 'foo':
z1.c:4:14: warning: too few arguments to built-in function 'copysignf128'
expecting 2 [-Wbuiltin-declaration-mismatch]
4 | return x * copysignf128 ();
| ^~~~
z1.c:1:18: note: declared here
1 | extern _Float128 copysignf128 ();
| ^~~~
z1.c:4:3: internal compiler error: tree check: accessed operand 4 of call_expr
with 3 operands in generic_simplify_MULT_EXPR, at generic-match.c:27222
4 | return x * copysignf128 ();
| ^~
0x5bd990 tree_operand_check_failed(int, tree_node const*, char const*, int,
char const*)
../../gcc/tree.c:10116
0x64cbb1 tree_operand_check(tree_node*, int, char const*, int, char const*)
../../gcc/tree.h:3685
0x116a717 generic_simplify_MULT_EXPR
.../gcc/generic-match.c:27222
0x11da8fd generic_simplify(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
.../gcc/generic-match.c:53387
0x8d49dd fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/fold-const.c:9387
0x8ddeba fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/fold-const.c:12327
0x8d4c1d fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/fold-const.c:9379
0x8f6ef4 fold(tree_node*)
../../gcc/fold-const.c:11949
0x683cca c_fully_fold_internal
../../gcc/c/c-fold.c:373
0x6850a7 c_fully_fold(tree_node*, bool, bool*, bool)
../../gcc/c/c-fold.c:125
0x629175 c_finish_return(unsigned int, tree_node*, tree_node*)
../../gcc/c/c-typeck.c:10523
0x673c3a c_parser_statement_after_labels
../../gcc/c/c-parser.c:5524
0x6757ce c_parser_compound_statement_nostart
../../gcc/c/c-parser.c:5149
0x675f56 c_parser_compound_statement
../../gcc/c/c-parser.c:4983
0x677873 c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2355
0x67fea3 c_parser_external_declaration
../../gcc/c/c-parser.c:1653
0x680969 c_parser_translation_unit
../../gcc/c/c-parser.c:1534
0x680969 c_parse_file()
../../gcc/c/c-parser.c:19884
0x6e26d0 c_common_parse_file()
../../gcc/c-family/c-opts.c:1156
[Bug c/90649] New: ICE tree check: accessed operand 4 of call_expr with 3 operands in generic_simplify_EQ_EXPR, at generic-match.c:42857
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90649
Bug ID: 90649
Summary: ICE tree check: accessed operand 4 of call_expr with 3
operands in generic_simplify_EQ_EXPR, at
generic-match.c:42857
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Affects versions down to at least gcc-5 :
(release versions need -Ofast)
$ cat z1.c
double sqrt ();
void f ()
{
!sqrt ();
}
$ gcc-10-20190526 -c z1.c -Ofast
z1.c: In function 'f':
z1.c:4:4: warning: too few arguments to built-in function 'sqrt' expecting 1
[-Wbuiltin-declaration-mismatch]
4 | !sqrt ();
|^~~~
z1.c:1:8: note: declared here
1 | double sqrt ();
|^~~~
z1.c:4:3: internal compiler error: tree check: accessed operand 4 of call_expr
with 3 operands in generic_simplify_EQ_EXPR, at generic-match.c:42857
4 | !sqrt ();
| ^
0x5bd990 tree_operand_check_failed(int, tree_node const*, char const*, int,
char const*)
../../gcc/tree.c:10116
0x64cbb1 tree_operand_check(tree_node*, int, char const*, int, char const*)
../../gcc/tree.h:3685
0x118c201 generic_simplify_EQ_EXPR
.../gcc/generic-match.c:42857
0x11da03d generic_simplify(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
.../gcc/generic-match.c:53417
0x8d49dd fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/fold-const.c:9387
0x8ddeba fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/fold-const.c:12327
0x6833a9 c_fully_fold_internal
../../gcc/c/c-fold.c:370
0x6850a7 c_fully_fold(tree_node*, bool, bool*, bool)
../../gcc/c/c-fold.c:125
0x61f6d1 c_process_expr_stmt(unsigned int, tree_node*)
../../gcc/c/c-typeck.c:11058
0x61fabd c_finish_expr_stmt(unsigned int, tree_node*)
../../gcc/c/c-typeck.c:11103
0x673898 c_parser_statement_after_labels
../../gcc/c/c-parser.c:5611
0x6757ce c_parser_compound_statement_nostart
../../gcc/c/c-parser.c:5149
0x675f56 c_parser_compound_statement
../../gcc/c/c-parser.c:4983
0x677873 c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2355
0x67fea3 c_parser_external_declaration
../../gcc/c/c-parser.c:1653
0x680969 c_parser_translation_unit
../../gcc/c/c-parser.c:1534
0x680969 c_parse_file()
../../gcc/c/c-parser.c:19884
0x6e26d0 c_common_parse_file()
../../gcc/c-family/c-opts.c:1156
[Bug d/90650] New: ICE in fold_convert_loc, at fold-const.c:2552
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90650
Bug ID: 90650
Summary: ICE in fold_convert_loc, at fold-const.c:2552
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: gs...@t-online.de
Target Milestone: ---
With snapshot from 20190526 :
$ cat z1.d
class c
{
static f ()
{
return 0;
}
}
void g ()
{
if (0 & [0] & c.f()) {}
}
$ gdc-10-20190526 -c z1.d
z1.d: In function 'g':
z1.d:10:15: internal compiler error: in fold_convert_loc, at fold-const.c:2552
10 | if (0 & [0] & c.f()) {}
| ^
0x8f27b3 fold_convert_loc(unsigned int, tree_node*, tree_node*)
../../gcc/fold-const.c:2552
0x8ebaf8 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/fold-const.c:9437
0x8f06ca fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/fold-const.c:12327
0x76d7fb ExprVisitor::binary_op(tree_code, tree_node*, tree_node*, tree_node*)
../../gcc/d/expr.cc:165
0x76d7fb ExprVisitor::visit(BinExp*)
../../gcc/d/expr.cc:674
0x76ce3e build_expr(Expression*, bool)
../../gcc/d/expr.cc:3076
0x76ced9 build_expr_dtor(Expression*)
../../gcc/d/expr.cc:3099
0x77949f IRVisitor::visit(IfStatement*)
../../gcc/d/toir.cc:554
0x778a22 IRVisitor::build_stmt(Statement*)
../../gcc/d/toir.cc:258
0x778a22 IRVisitor::visit(CompoundStatement*)
../../gcc/d/toir.cc:1042
0x778561 IRVisitor::build_stmt(Statement*)
../../gcc/d/toir.cc:258
0x778561 build_function_body(FuncDeclaration*)
../../gcc/d/toir.cc:1447
0x76c0e4 DeclVisitor::visit(FuncDeclaration*)
../../gcc/d/decl.cc:1006
0x769026 build_decl_tree(Dsymbol*)
../../gcc/d/decl.cc:1047
0x7768b0 build_module_tree(Module*)
../../gcc/d/modules.cc:726
0x76b4ab DeclVisitor::visit(Module*)
../../gcc/d/decl.cc:147
0x769026 build_decl_tree(Dsymbol*)
../../gcc/d/decl.cc:1047
0x767214 d_parse_file()
../../gcc/d/d-lang.cc:1310
[Bug d/90650] ICE in fold_convert_loc, at fold-const.c:2552
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90650
G. Steinmetz changed:
What|Removed |Added
Keywords||ice-on-invalid-code
Target||x86_64-pc-linux-gnu
--- Comment #1 from G. Steinmetz ---
And nearby testcase ...
$ cat z2.d
class c
{
static f ()
{
return 0;
}
}
void g ()
{
if ([0] & c.f()) {}
}
$ gdc-10-20190526 -c z2.d
z2.d: In function 'g':
z2.d:10:7: internal compiler error: tree check: expected none of record_type or
union_type or qual_union_type or array_type, have record_type in
fold_binary_loc, at fold-const.c:9782
10 | if ([0] & c.f()) {}
| ^
0x608666 tree_not_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:9939
0x9a4f4e tree_not_check4(tree_node*, char const*, int, char const*, tree_code,
tree_code, tree_code, tree_code)
../../gcc/tree.h:3262
0x982c4e fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/fold-const.c:9782
0x98bbaa fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
../../gcc/fold-const.c:12327
0x79c7f7 ExprVisitor::binary_op(tree_code, tree_node*, tree_node*, tree_node*)
../../gcc/d/expr.cc:165
0x79c7f7 ExprVisitor::visit(BinExp*)
../../gcc/d/expr.cc:674
0x79bc7f build_expr(Expression*, bool)
../../gcc/d/expr.cc:3076
0x79bd59 build_expr_dtor(Expression*)
../../gcc/d/expr.cc:3099
0x7acacf IRVisitor::visit(IfStatement*)
../../gcc/d/toir.cc:554
0x7abe92 IRVisitor::build_stmt(Statement*)
../../gcc/d/toir.cc:258
0x7abe92 IRVisitor::visit(CompoundStatement*)
../../gcc/d/toir.cc:1042
0x7ab821 IRVisitor::build_stmt(Statement*)
../../gcc/d/toir.cc:258
0x7ab821 build_function_body(FuncDeclaration*)
../../gcc/d/toir.cc:1447
0x79a844 DeclVisitor::visit(FuncDeclaration*)
../../gcc/d/decl.cc:1006
0x794a16 build_decl_tree(Dsymbol*)
../../gcc/d/decl.cc:1047
0x7a9640 build_module_tree(Module*)
../../gcc/d/modules.cc:726
0x799a3b DeclVisitor::visit(Module*)
../../gcc/d/decl.cc:147
0x794a16 build_decl_tree(Dsymbol*)
../../gcc/d/decl.cc:1047
0x792c57 d_parse_file()
../../gcc/d/d-lang.cc:1310
[Bug d/90651] New: ICE in FuncDeclaration::semantic3, at d/dmd/func.c:1524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90651
Bug ID: 90651
Summary: ICE in FuncDeclaration::semantic3, at
d/dmd/func.c:1524
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: gs...@t-online.de
Target Milestone: ---
$ cat z1.d
struct object {}
void f (...) {}
int g (object a);
$ gdc-10-20190526 -c z1.d
d21: internal compiler error: Segmentation fault
0xb7057f crash_signal
../../gcc/toplev.c:326
0x6cb025 FuncDeclaration::semantic3(Scope*)
../../gcc/d/dmd/func.c:1524
0x66c57f Module::semantic3(Scope*)
../../gcc/d/dmd/dmodule.c:814
0x766905 d_parse_file()
../../gcc/d/d-lang.cc:1201
[Bug middle-end/90648] [8/9/10 Regression] ICE tree check: accessed operand 4 of call_expr with 3 operands in generic_simplify_MULT_EXPR, at generic-match.c:27222
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90648 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-05-27 CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Target Milestone|--- |8.4 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Both started with r256026. I'll have a look.
[Bug c++/90652] New: Recursive concept leads to segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90652
Bug ID: 90652
Summary: Recursive concept leads to segfault
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tobias.bruell at gmail dot com
Target Milestone: ---
The following program leads to a seg-fault in gcc. Compile with
-Wall -Wextra -std=gnu++2a "-fconcepts"
It works when using "operator << (os, x)" instead of "os << x" in line 4.
---
#include
void to_json (std::ostream& os, char c) { os << '"' << c << '"'; }
template concept bool Serializable = requires (T x, std::ostream&
os) { { os << x }; };
template concept bool ToJson = requires (T x, std::ostream& os) { {
to_json (os, x) }; };
template
requires ToJson && !Serializable
std::ostream& operator << (std::ostream& os, T const& x)
{
to_json (os, x);
return os;
}
int main ()
{
static_assert (Serializable);
static_assert (ToJson);
std::cout << 'c';
}
[Bug middle-end/90648] [8/9/10 Regression] ICE tree check: accessed operand 4 of call_expr with 3 operands in generic_simplify_MULT_EXPR, at generic-match.c:27222
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90648
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|jakub at gcc dot gnu.org |unassigned at gcc dot
gnu.org
--- Comment #2 from Jakub Jelinek ---
extern double copysign ();
double foo (double x)
{
return x * copysign ();
}
ICEs similarly as well, it isn't specific to the _FloatN types (though
copysignf and float instead of copysign and double doesn't, because float isn't
self-promoting and the C FE handles it differently during builtin handling.
That said, I'd say this is a genmatch bug, in that it doesn't do any argument
verification of the builtins, neither in generic nor gimple, and happily uses
CALL_EXPR_ARG (op0, 0) and CALL_EXPR_ARG (op0, 1) or similarly in gimple, when
it didn't even verify the builtin has that many arguments.
[Bug target/90639] [10 Regression] Boostrap failure with recent trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90639 --- Comment #2 from Segher Boessenkool --- Author: segher Date: Mon May 27 19:12:19 2019 New Revision: 271668 URL: https://gcc.gnu.org/viewcvs?rev=271668&root=gcc&view=rev Log: rs6000: Fix sanitizer build (PR90639) The assembler code needs to say it uses AltiVec instructions. libsanitizer/ PR target/90639 * tsan/tsan_rtl_ppc64.S: Add ".machine altivec". Modified: trunk/libsanitizer/ChangeLog trunk/libsanitizer/tsan/tsan_rtl_ppc64.S
[Bug go/90645] sparc-unknown-linux-gnu/libgo/.libs/libgo.so: undefined reference to `fdopendir'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90645 --- Comment #3 from Ian Lance Taylor --- Did libgo ever work on this system? I can't remember. I don't see how we can work around a missing __tls_get_addr symbol. That suggests that the system does not support Thread Local Storage.
[Bug target/68485] ICE while building gpsd package on microblaze
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68485 --- Comment #7 from Giulio Benetti --- This Bug still exists on Gcc 9.1. I have tested it with 4.9/5/6/7/8/9
[Bug target/68485] ICE while building gpsd package on microblaze
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68485 --- Comment #8 from Giulio Benetti --- This is the build failure log: http://autobuild.buildroot.net/results/d86/d86251974a0a348a64d9a1d1fd7d02dd4aff0792/build-end.log
[Bug libgomp/90641] libgomp.c-c++-common/lastprivate-conditional-1.c etc FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90641 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Mon May 27 21:27:00 2019 New Revision: 271671 URL: https://gcc.gnu.org/viewcvs?rev=271671&root=gcc&view=rev Log: PR libgomp/90641 * work.c (gomp_init_work_share): Instead of aligning final ordered value to multiples of long long alignment, align to that the first part (ordered team ids) and if inline_ordered_team_ids is not on a long long alignment boundary within the structure, use __alignof__ (long long) - 1 pad size always. * loop.c (GOMP_loop_start): Fix *mem computation if inline_ordered_team_ids is not aligned on long long alignment boundary within the structure. * loop-ull.c (GOMP_loop_ull_start): Likewise. * sections.c (GOMP_sections2_start): Likewise. Modified: trunk/libgomp/ChangeLog trunk/libgomp/loop.c trunk/libgomp/loop_ull.c trunk/libgomp/sections.c trunk/libgomp/work.c
[Bug tree-optimization/34940] contained subroutines called only once are not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34940 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #17 from Eric Gallager --- (In reply to Jan Hubicka from comment #14) > > Note that the IO block escapes and thus cannot be coalesced with others in > > the same function. I had a frontend patch to re-use the same IO struct > > across multiple calls but that was rejected on the grounds of future > > implementation of async IO. > > I think inline heuristics ignore this fact and just assume overlap across > sibling calls > that gets inlined. Not terribly realistic but not terribly bad either. Are you still working on this?
[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539 --- Comment #34 from Thomas Koenig --- Created attachment 46420 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46420&action=edit Patch which includes a check for being contiguous This patch looks like it could do the job. I'll have to work a bit more on test cases and ChangeLog before I can submit this, but at least it survives regression testing.
[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539 --- Comment #35 from Thomas Koenig --- (In reply to Thomas Koenig from comment #34) > Created attachment 46420 [details] > Patch which includes a check for being contiguous > > This patch looks like it could do the job. I'll have to work a bit > more on test cases and ChangeLog before I can submit this, but > at least it survives regression testing. ... except for a tree dump scan. I will look at this later.
[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90539
--- Comment #36 from Thomas Koenig ---
... which should be
Index: testsuite/gfortran.dg/internal_pack_21.f90
===
--- testsuite/gfortran.dg/internal_pack_21.f90 (Revision 271629)
+++ testsuite/gfortran.dg/internal_pack_21.f90 (Arbeitskopie)
@@ -20,5 +20,5 @@
USE M1
CALL S2()
END
-! { dg-final { scan-tree-dump-times "optional" 4 "original" } }
+! { dg-final { scan-tree-dump-times "arg_ptr" 5 "original" } }
! { dg-final { scan-tree-dump-not "_gfortran_internal_unpack" "original" } }
ig25@linux-p51k:~/Gcc/trunk/gcc>
[Bug libstdc++/90646] std::filesystem::absolute( "yourpathhere" ) segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90646 --- Comment #5 from Jonathan Wakely --- Is it possible you're mixing code compiled with GCC 8 and GCC 9? In general that works, but not for the new C++17 components that were still experimental in GCC 8, such as filesystem::path. Valgrind might give you more information about the crash, to help debug the problem.
