[Bug fortran/88420] New: Fortran OpenACC "Clause SEQ conflicts with INDEPENDENT"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88420 Bug ID: 88420 Summary: Fortran OpenACC "Clause SEQ conflicts with INDEPENDENT" Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: openacc, patch Severity: normal Priority: P3 Component: fortran Assignee: tschwinge at gcc dot gnu.org Reporter: tschwinge at gcc dot gnu.org Target Milestone: --- The Fortran front end declares that the OpenACC "Clause SEQ conflicts with INDEPENDENT". While that combination doesn't make too much sense indeed, it's still valid; these are orthogonal concepts.
[Bug fortran/88420] Fortran OpenACC "Clause SEQ conflicts with INDEPENDENT"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88420 --- Comment #1 from Thomas Schwinge --- Author: tschwinge Date: Sun Dec 9 12:47:35 2018 New Revision: 266920 URL: https://gcc.gnu.org/viewcvs?rev=266920&root=gcc&view=rev Log: [PR88420] Fortran OpenACC "Clause SEQ conflicts with INDEPENDENT" The Fortran front end declares that the OpenACC "Clause SEQ conflicts with INDEPENDENT". While that combination doesn't make too much sense indeed, it's still valid; these are orthogonal concepts. gcc/fortran/ PR fortran/88420 * openmp.c (resolve_oacc_loop_blocks): Remove "Clause SEQ conflicts with INDEPENDENT" diagnostic. gcc/testsuite/ PR fortran/88420 * gfortran.dg/goacc/loop-1-2.f95: Update. * gfortran.dg/goacc/loop-1.f95: Likewise. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/openmp.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/goacc/loop-1-2.f95 trunk/gcc/testsuite/gfortran.dg/goacc/loop-1.f95
[Bug inline-asm/52813] %rsp in clobber list is silently ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52813 Dimitar Dimitrov changed: What|Removed |Added CC||dinuxbg at gmail dot com --- Comment #7 from Dimitar Dimitrov --- Suggested fix has been posted for review: https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00532.html
[Bug libfortran/88411] [9 Regression] Random crashes for ASYNCHRONOUS writes (bad locking?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88411 --- Comment #6 from Thomas Koenig --- Something glaringly obvious just struck me: The test case has synchronous writes for a file which is opened asynchronously. This may or may not have been intended. It is certainly a bug not to get this right, but at least there is a workaround: Rewrite the test case as program gfcbug153 implicit none integer :: iu, irecl real:: a(100,20), b(1,3000) iu = 10 a = 0. b = 0. inquire (iolength = irecl) a open (iu, file="file1.dat", access='direct', & asynchronous='yes', & recl=irecl) write(iu, rec=1,asynchronous="yes") a(:,:) write(iu, rec=2,asynchronous="yes") a(:,:) write(iu, rec=3,asynchronous="yes") a(:,:) close (iu) inquire (iolength = irecl) b open (iu, file="file2.dat", access='direct', & asynchronous='yes', & recl=irecl) write(iu, rec=1,asynchronous="yes") b(:,:) write(iu, rec=2,asynchronous="yes") b(:,:) write(iu, rec=3,asynchronous="yes") b(:,:) close (iu) end program That appears to work, at least according to the testing that I did.
[Bug libfortran/88411] [9 Regression] Random crashes for ASYNCHRONOUS writes (bad locking?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88411
--- Comment #7 from Thomas Koenig ---
This looks like it could do the trick:
Index: io/transfer.c
===
--- io/transfer.c (Revision 266250)
+++ io/transfer.c (Arbeitskopie)
@@ -3189,7 +3189,7 @@ data_transfer_init (st_parameter_dt *dtp, int read
}
}
- if (au)
+ if (au && dtp->u.p.async)
{
NOTE ("enqueue_data_transfer");
enqueue_data_transfer_init (au, dtp, read_flag);
@@ -4401,7 +4401,7 @@ st_write_done (st_parameter_dt *dtp)
{
if (dtp->u.p.current_unit)
{
- if (dtp->u.p.current_unit->au)
+ if (dtp->u.p.current_unit->au && dtp->u.p.async)
{
if (dtp->common.flags & IOPARM_DT_HAS_ID)
*dtp->id = enqueue_done_id (dtp->u.p.current_unit->au,
[Bug libstdc++/88421] New: compat C headers break building GCC with GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88421 Bug ID: 88421 Summary: compat C headers break building GCC with GCC Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: coypu at sdf dot org Target Milestone: --- I built GCC #1 (x86_64->sh3) Now I'm trying to build GCC #2 (sh3->sh3) using GCC #1 during the build process, libtool: compile: shle--netbsdelf-c++ --sysroot=/home/fly/sh3/destdir.evbsh3/ -I/current/gcc/libstdc++-v3/../libgcc -I/tmp/build/shle--netbsdelf/libstdc++-v3/include/shle--netbsdelf -I/tmp/build/shle--netbsdelf/libstdc++-v3/include -I/current/gcc/libstdc++-v3/libsupc++ -std=gnu++98 -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=c++locale.lo -g -O2 -fimplicit-templates -c c++locale.cc -fPIC -DPIC -D_GLIBCXX_SHARED -o c++locale.o mv -f .deps/list_read.Tpo .deps/list_read.Plo In file included from /home/fly/sh3/destdir.evbsh3/usr/include/evbsh3/ieeefp.h:3, from /home/fly/sh3/destdir.evbsh3/usr/include/ieeefp.h:12, from c++locale.cc:40: /home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h: In function 'fp_except __FPE(int)': /home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:62:13: error: 'FE_DIVBYZERO' was not declared in this scope 62 | if (__fe & FE_DIVBYZERO) | ^~~~ /home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:64:13: error: 'FE_INEXACT' was not declared in this scope 64 | if (__fe & FE_INEXACT) | ^~ /home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:66:13: error: 'FE_INVALID' was not declared in this scope; did you mean 'EINVAL'? 66 | if (__fe & FE_INVALID) | ^~ | EINVAL /home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:68:13: error: 'FE_OVERFLOW' was not declared in this scope; did you mean 'EOVERFLOW'? 68 | if (__fe & FE_OVERFLOW) | ^~~ | EOVERFLOW /home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:70:13: error: 'FE_UNDERFLOW' was not declared in this scope; did you mean 'UNDERFLOW'? 70 | if (__fe & FE_UNDERFLOW) | ^~~~ | UNDERFLOW /home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h: In function 'int __FEE(fp_except)': /home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:81:11: error: 'FE_DIVBYZERO' was not declared in this scope 81 | __fe |= FE_DIVBYZERO; | ^~~~ /home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:83:11: error: 'FE_INEXACT' was not declared in this scope 83 | __fe |= FE_INEXACT; | ^~ /home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:85:11: error: 'FE_INVALID' was not declared in this scope; did you mean 'EINVAL'? 85 | __fe |= FE_INVALID; | ^~ | EINVAL /home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:87:11: error: 'FE_OVERFLOW' was not declared in this scope; did you mean 'EOVERFLOW'? 87 | __fe |= FE_OVERFLOW; | ^~~ | EOVERFLOW /home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:89:11: error: 'FE_UNDERFLOW' was not declared in this scope; did you mean 'UNDERFLOW'? 89 | __fe |= FE_UNDERFLOW; | ^~~~ | UNDERFLOW /home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h: In function 'fp_rnd __FPR(int)': /home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:98:7: error: 'FE_TONEAREST' was not declared in this scope 98 | case FE_TONEAREST: | ^~~~ /home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:100:7: error: 'FE_DOWNWARD' was not declared in this scope 100 | case FE_DOWNWARD: | ^~~ /home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:102:7: error: 'FE_UPWARD' was not declared in this scope 102 | case FE_UPWARD: | ^ /home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:104:7: error: 'FE_TOWARDZERO' was not declared in this scope 104 | case FE_TOWARDZERO: | ^ /home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h: In function 'int __FER(fp_rnd)': /home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:117:10: error: 'FE_TONEAREST' was not declared in this scope 117 | return FE_TONEAREST; | ^~~~ /home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:119:10: error: 'FE_DOWNWARD' was not declared in this scope 119 | return FE_DOWNWARD; | ^~~ /home/fly/sh3/destdir.evbsh3/usr/include/sh3/ieeefp.h:121:10: error: 'FE_UPWARD' was not declared in this scope 121 | return FE_UPWARD; | ^ /home/fly/sh3/destdir.evbsh3/usr/includ
[Bug libstdc++/88421] compat C headers break building GCC with GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88421 --- Comment #1 from coypu --- suggested change: put #include_next outside of include guards?
[Bug debug/26475] tree-ssa loses line numbers for initializations (constants for PHIs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26475 Eric Gallager changed: What|Removed |Added CC||amacleod at redhat dot com, ||rguenth at gcc dot gnu.org --- Comment #7 from Eric Gallager --- (In reply to Eric Gallager from comment #6) > (In reply to Andrew Macleod from comment #5) > > I just checked in the code to track locations through PHI arguments. > > > > Comments and patch is located: > > http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01729.html > > Thread said it was checked it as r150267 apparently? Andrew, can this be closed?
[Bug c/88422] New: collect2.exe: fatal error: lto-wrapper returned 1 exit status: file not recognized: file truncated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88422 Bug ID: 88422 Summary: collect2.exe: fatal error: lto-wrapper returned 1 exit status: file not recognized: file truncated Product: gcc Version: lto Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: nidal.faour at wdc dot com Target Milestone: --- Created attachment 45192 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45192&action=edit test case to reproduce the the failure When attempt to build a simple code including one assembly file and one c code file while calling a c function from the assembly code and using the lto in linkage stage I encountered an error in the lto-wrapper where ld returned 1 exit status, with file not recognized: file truncated. the build has been done in windows machine. the toolchain used: gcc-arm-8.2-2018.08-i686-mingw32-arm-eabi download link: https://developer.arm.com/-/media/Files/downloads/gnu-a/8.2-2018.08/gcc-arm-8.2-2018.08-i686-mingw32-arm-eabi.tar.xz?revision=37b1357c-06a5-4721-8fde-533b0028c083&la=en gcc build info: Using built-in specs. COLLECT_GCC=..\gcc-arm-8.2\bin\arm-eabi-gcc.exe COLLECT_LTO_WRAPPER=c:/tmp/gcc-arm-8.2/bin/../libexec/gcc/arm-eabi/8.2.1/lto-wrapper.exe Target: arm-eabi Configured with: /tmp/dgboter/bbs/dsggnu-vm-1-x86_64--mingw32-i686/buildbot/mingw32-i686--arm-eabi/build/src/gcc/configure --target=arm-eabi --prefix=/tmp/dgboter/bbs/dsggnu-vm-1-x86_64--mingw32-i686/buildbot/mingw32-i686--arm-eabi/build/build-mingw-arm-eabi/install// --with-gmp=/tmp/dgboter/bbs/dsggnu-vm-1-x86_64--mingw32-i686/buildbot/mingw32-i686--arm-eabi/build/build-mingw-arm-eabi/host-tools --with-mpfr=/tmp/dgboter/bbs/dsggnu-vm-1-x86_64--mingw32-i686/buildbot/mingw32-i686--arm-eabi/build/build-mingw-arm-eabi/host-tools --with-mpc=/tmp/dgboter/bbs/dsggnu-vm-1-x86_64--mingw32-i686/buildbot/mingw32-i686--arm-eabi/build/build-mingw-arm-eabi/host-tools --with-isl=/tmp/dgboter/bbs/dsggnu-vm-1-x86_64--mingw32-i686/buildbot/mingw32-i686--arm-eabi/build/build-mingw-arm-eabi/host-tools --with-pkgversion='GNU Toolchain for the A-profile Architecture 8.2-2018-08 (arm-rel-8.23)' --disable-shared --disable-nls --disable-threads --disable-tls --enable-checking=release --enable-languages=c,c++,fortran --with-newlib --with-multilib-list=aprofile --with-libiconv-prefix=/tmp/dgboter/bbs/dsggnu-vm-1-x86_64--mingw32-i686/buildbot/mingw32-i686--arm-eabi/build/build-mingw-arm-eabi/host-tools --host=i686-w64-mingw32 Thread model: single gcc version 8.2.1 20180802 (GNU Toolchain for the A-profile Architecture 8.2-2018-08 (arm-rel-8.23)) Attached a simple test case [lto_test_arm.zip] that reproduce the failure.
[Bug rtl-optimization/88423] New: [9 Regression] ICE in begin_move_insn, at sched-ebb.c:175
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88423 Bug ID: 88423 Summary: [9 Regression] ICE in begin_move_insn, at sched-ebb.c:175 Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: ice-checking, ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- Target: x86_64-unknown-linux-gnu gcc-9.0.0-alpha20181202 snapshot (r266729) ICEs when compiling gcc/testsuite/gcc.dg/20030309-1.c w/ -march=skylake -Os -fPIC -fsched2-use-superblocks -fno-if-conversion: % x86_64-unknown-linux-gnu-gcc-9.0.0-alpha20181202 -march=skylake -Os -fPIC -fsched2-use-superblocks -fno-if-conversion -c gcc/testsuite/gcc.dg/20030309-1.c during RTL pass: sched2 gcc/testsuite/gcc.dg/20030309-1.c: In function 'main': gcc/testsuite/gcc.dg/20030309-1.c:42:1: internal compiler error: in begin_move_insn, at sched-ebb.c:175 42 | } | ^ 0x777edb begin_move_insn /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/sched-ebb.c:175 0x777edb begin_move_insn /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/sched-ebb.c:145 0x1538e1c commit_schedule /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/haifa-sched.c:6228 0x1544015 schedule_block(basic_block_def**, void*) /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/haifa-sched.c:7065 0x15c94ff schedule_ebb(rtx_insn*, rtx_insn*, bool) /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/sched-ebb.c:537 0x15c9b1f schedule_ebbs() /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/sched-ebb.c:657 0xcb2ab4 rest_of_handle_sched2 /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/sched-rgn.c:3738 0xcb2ab4 execute /var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/sched-rgn.c:3876
[Bug target/87370] [7/8/9 Regression] Inefficient return code of struct values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87370 --- Comment #10 from trashyankes at wp dot pl --- (In reply to H.J. Lu from comment #9) > Fixed for GCC 9, GCC 8.3 and GCC 7.4. One question, I look on test case and see: ``` f1(): xor eax, eax xor edx, edx ret f2(): pushrbp xor eax, eax xor edx, edx mov rbp, rsp and rsp, -64 sub rsp, 8 leave ret f3(): xor eax, eax xor edx, edx ret ``` Why `f2` have `push` there? Isn't this co kind of stack alignment? but for what point is it there? Clang do not have that.
[Bug target/87370] [7/8/9 Regression] Inefficient return code of struct values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87370 --- Comment #11 from H.J. Lu --- (In reply to trashyankes from comment #10) > (In reply to H.J. Lu from comment #9) > > Fixed for GCC 9, GCC 8.3 and GCC 7.4. > > One question, I look on test case and see: > > ``` > f1(): > xor eax, eax > xor edx, edx > ret > f2(): > pushrbp > xor eax, eax > xor edx, edx > mov rbp, rsp > and rsp, -64 > sub rsp, 8 > leave > ret > f3(): > xor eax, eax > xor edx, edx > ret > ``` > > Why `f2` have `push` there? Isn't this co kind of stack alignment? but for > what point is it there? Clang do not have that. Which GCC are you using? GCC 8.2 generates: .file "pr87370.c" .text .p2align 4,,15 .globl f1 .type f1, @function f1: .LFB0: .cfi_startproc xorl%eax, %eax xorl%edx, %edx ret .cfi_endproc .LFE0: .size f1, .-f1 .p2align 4,,15 .globl f2 .type f2, @function f2: .LFB1: .cfi_startproc xorl%eax, %eax xorl%edx, %edx ret .cfi_endproc .LFE1: .size f2, .-f2 .p2align 4,,15 .globl f3 .type f3, @function f3: .LFB2: .cfi_startproc xorl%eax, %eax xorl%edx, %edx ret .cfi_endproc .LFE2: .size f3, .-f3
[Bug lto/88422] collect2.exe: fatal error: lto-wrapper returned 1 exit status: file not recognized: file truncated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88422 Andrew Pinski changed: What|Removed |Added CC||marxin at gcc dot gnu.org Component|c |lto --- Comment #1 from Andrew Pinski --- I bet someone forgot to open a file as binary. I also suspect this has been fixed already.
[Bug fortran/88228] ICE in check_null, at fortran/expr.c:2691
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88228 --- Comment #4 from kargl at gcc dot gnu.org --- Author: kargl Date: Sun Dec 9 16:32:48 2018 New Revision: 266926 URL: https://gcc.gnu.org/viewcvs?rev=266926&root=gcc&view=rev Log: 2018-12-09 Fritz Reese PR fortran/88228 * resolve.c (resolve_operator): Do not call resolve_function. Break like other cases. 2018-12-09 Steven G. Kargl PR fortran/88228 * gfortran.dg/pr88228.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr88228.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug d/88366] ubsan build of d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88366 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Iain Buclaw --- Fixed in upstream, and committed in r266925.
[Bug c/67729] -Wformat should warn for %Ns where the buffer size is known to be less than N in size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67729 --- Comment #2 from David Binderman --- Three years later, enhancement not implemented. See https://sourceware.org/bugzilla/show_bug.cgi?id=23490 for an example where glibc would have benefited from this enhancement. If someone can give me a clue which source code file / function to look at, then I'd be happy to have a look myself.
[Bug fortran/88228] ICE in check_null, at fortran/expr.c:2691
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88228 --- Comment #5 from kargl at gcc dot gnu.org --- Author: kargl Date: Sun Dec 9 17:09:15 2018 New Revision: 266927 URL: https://gcc.gnu.org/viewcvs?rev=266927&root=gcc&view=rev Log: 2018-12-09 Fritz Reese PR fortran/88228 * resolve.c (resolve_operator): Do not call resolve_function. Break like other cases. 2018-12-09 Steven G. Kargl PR fortran/88228 * gfortran.dg/pr88228.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr88228.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/resolve.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug c++/88419] [9 Regression] [ICE] "Same canonical type node for different types" for CTAD in noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88419 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-09 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Likely started with r241944.
[Bug c++/88419] [9 Regression] [ICE] "Same canonical type node for different types" for CTAD in noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88419
--- Comment #2 from Marek Polacek ---
But not sure if it's a regression: 7/8/9 ICEs whereas
$ xg++-6 -c 88419.C -std=c++17
88419.C:5:48: error: expected constructor, destructor, or type conversion
before ‘;’ token
template ref_view(R&) -> ref_view;
^
88419.C:9:33: error: missing template arguments before ‘{’ token
noexcept(noexcept(ref_view{r}));
^
88419.C:9:33: error: expected ‘)’ before ‘{’ token
88419.C:9:33: error: expected ‘)’ before ‘{’ token
88419.C:9:36: error: expected unqualified-id before ‘)’ token
noexcept(noexcept(ref_view{r}));
^
88419.C: In member function ‘auto ref_fn::operator()(R) const’:
88419.C:9:35: error: expected ‘;’ before ‘}’ token
noexcept(noexcept(ref_view{r}));
^
88419.C: At global scope:
88419.C:18:38: error: missing template arguments before ‘{’ token
noexcept(noexcept(indirect_view{r}));
^
88419.C:18:38: error: expected ‘)’ before ‘{’ token
88419.C:18:38: error: expected ‘)’ before ‘{’ token
88419.C:18:41: error: expected unqualified-id before ‘)’ token
noexcept(noexcept(indirect_view{r}));
^
88419.C: In member function ‘auto indirect_fn::operator()(R) const’:
88419.C:18:40: error: expected ‘;’ before ‘}’ token
noexcept(noexcept(indirect_view{r}));
^
[Bug target/88359] internal compiler error: in push_reload, at reload.c:1360
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88359 --- Comment #8 from Geert linders --- (In reply to Andrew Pinski from comment #2) > 4.9.x is no longer supported, can you try a newer version of GCC? What is the oldest version of GCC that I can try?
[Bug c/88424] New: Inserts newlines when preserving comments for a file using Windows newlines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88424
Bug ID: 88424
Summary: Inserts newlines when preserving comments for a file
using Windows newlines
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: reiter.christoph at gmail dot com
Target Milestone: ---
gcc --version
gcc (Debian 8.2.0-11) 8.2.0
When preprocessing a file which uses Windows newlines without discarding
comments (The -C option) then gcc inserts an extra newline after each line in
comments:
* Write the following to test.c and make sure it uses Windows newlines
/**
* Foo-
* bar-
* quux
*/
int main() {
return 0;
}
* Execute "gcc -C -E test.c"
3) Expected (this is what clang produces):
[...]
/**
* Foo-
* bar-
* quux
*/
int main() {
return 0;
}
* Actual:
/**
* Foo-
* bar-
* quux
*/
# 6 "test.c"
int main() {
return 0;
}
[Bug preprocessor/88424] Inserts newlines when preserving comments for a file using Windows newlines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88424 Andrew Pinski changed: What|Removed |Added Component|c |preprocessor --- Comment #1 from Andrew Pinski --- Most likely \r is being treated as a new line just like \n. Remember \r by itself is the new line endings on the classic mac os.
[Bug preprocessor/88424] Inserts newlines when preserving comments for a file using Windows newlines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88424 --- Comment #2 from Christoph Reiter --- For context, we use gcc in gobject-introspection where we parse metadata from the C comments and this breaks things when users on Windows have git set up to auto convert line endings: https://gitlab.gnome.org/GNOME/gobject-introspection/issues/243
[Bug fortran/88228] ICE in check_null, at fortran/expr.c:2691
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88228 --- Comment #6 from kargl at gcc dot gnu.org --- Author: kargl Date: Sun Dec 9 18:32:01 2018 New Revision: 266928 URL: https://gcc.gnu.org/viewcvs?rev=266928&root=gcc&view=rev Log: 2018-12-09 Fritz Reese PR fortran/88228 * resolve.c (resolve_operator): Do not call resolve_function. Break like other cases. 2018-12-09 Steven G. Kargl PR fortran/88228 * gfortran.dg/pr88228.f90: New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr88228.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/resolve.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug fortran/88228] ICE in check_null, at fortran/expr.c:2691
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88228 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.5 --- Comment #7 from kargl at gcc dot gnu.org --- Fixed on trunk, branch-8, and branch-7.
[Bug libfortran/88411] [9 Regression] Random crashes for ASYNCHRONOUS writes (bad locking?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88411 --- Comment #8 from Thomas Koenig --- Author: tkoenig Date: Sun Dec 9 18:54:47 2018 New Revision: 266929 URL: https://gcc.gnu.org/viewcvs?rev=266929&root=gcc&view=rev Log: 2018-12-09 Thomas Koenig PR fortran/88411 * io/transfer.c (dta_transfer_init): Do not treat as an asynchronous statement unless the statement has ASYNCHRONOUS="YES". (st_write_done): Likewise. (st_read_done): Do not perform async_wait for synchronous I/O on an async unit. (st_read_done): Likewise. 2018-12-09 Thomas Koenig PR fortran/88411 * testsuite/libgomp.fortran/async_io_8.f90: New test. Added: trunk/libgomp/testsuite/libgomp.fortran/async_io_8.f90 Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/transfer.c trunk/libgomp/ChangeLog
[Bug libfortran/88411] [9 Regression] Random crashes for ASYNCHRONOUS writes (bad locking?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88411 Thomas Koenig changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Thomas Koenig --- Fixed on trunk, closing. Thank you very much for the bug report - for this, finding a use case that actually exposes a bug is really valuable.
[Bug fortran/88206] [7/8/9 Regression] ICE in gfc_match_type_spec, at fortran/match.c:2229
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88206 --- Comment #4 from kargl at gcc dot gnu.org --- Author: kargl Date: Sun Dec 9 19:10:57 2018 New Revision: 266930 URL: https://gcc.gnu.org/viewcvs?rev=266930&root=gcc&view=rev Log: 2018-12-09 Steven G. Kargl PR fortran/88206 * match.c (gfc_match_type_spec): REAL can be an intrinsic function. 2018-12-09 Steven G. Kargl PR fortran/88206 * gfortran.dg/pr88206.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr88206.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/match.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/88364] [9 Regression] Wrong-code due to CLOBBER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88364
--- Comment #4 from Thomas Koenig ---
A simple fix is not to do the clobbers if there is a reference:
Index: trans-expr.c
===
--- trans-expr.c(Revision 266250)
+++ trans-expr.c(Arbeitskopie)
@@ -8152,7 +8152,7 @@ gfc_conv_expr_reference (gfc_se * se, gfc_expr * e
gfc_add_block_to_block (&se->pre, &se->post);
se->expr = var;
}
- else if (add_clobber)
+ else if (add_clobber && expr->ref == NULL)
{
tree clobber;
tree var;
A bit more sophisticated would be to actually build the correct
clobber in this case.
I'm inclined to commit the patch above and open a new PR for
the missed optimization, but I won't have time for either in
the next few days.
So, if anybody wants to do anything about this, be my guest :-)
[Bug rtl-optimization/88425] New: suboptimal code for a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88425 Bug ID: 88425 Summary: suboptimal code for a
[Bug target/88402] inefficient code generation for mask from CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88402
--- Comment #4 from Alexander Monakov ---
(In reply to Alexander Monakov from comment #3)
> But unfortunately today we don't manage to use the cmp-sbb trick for
> unsigned comparison against an immediate, i.e. for
>
> unsigned long baz (unsigned int a)
> {
> return a < 123 ? -1ul : 0;
> }
It's probably more appropriate to discuss this aspect separately: PR 88425.
[Bug fortran/88206] [7/8/9 Regression] ICE in gfc_match_type_spec, at fortran/match.c:2229
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88206 --- Comment #5 from kargl at gcc dot gnu.org --- Author: kargl Date: Sun Dec 9 19:51:59 2018 New Revision: 266932 URL: https://gcc.gnu.org/viewcvs?rev=266932&root=gcc&view=rev Log: 2018-12-09 Steven G. Kargl PR fortran/88206 * match.c (gfc_match_type_spec): REAL can be an intrinsic function. 2018-12-09 Steven G. Kargl PR fortran/88206 * gfortran.dg/pr88206.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr88206.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/match.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug d/88039] gdc.test/compilable/ddoc12.d FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88039 --- Comment #8 from ibuclaw at gcc dot gnu.org --- Author: ibuclaw Date: Sun Dec 9 19:55:54 2018 New Revision: 266933 URL: https://gcc.gnu.org/viewcvs?rev=266933&root=gcc&view=rev Log: Generate and scan documentation output in Ddoc tests. The tests in gdc.test/compilable/ddoc*.d don't require the module to be compiled all the way down to object code. Instead, only compile the test sources with -fdoc, and scan the generated html content. gcc/testsuite/ChangeLog: PR d/88039 * gdc.test/gdc-test.exp (gdc-convert-args): Handle -D. (dmd2dg): Check generated html in ddoc tests. (gdc-do-test): Set dg-do-what-default to compile for ddoc tests. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gdc.test/gdc-test.exp
[Bug fortran/88206] [7/8/9 Regression] ICE in gfc_match_type_spec, at fortran/match.c:2229
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88206 --- Comment #6 from kargl at gcc dot gnu.org --- Author: kargl Date: Sun Dec 9 20:23:06 2018 New Revision: 266934 URL: https://gcc.gnu.org/viewcvs?rev=266934&root=gcc&view=rev Log: 2018-12-09 Steven G. Kargl PR fortran/88206 * match.c (gfc_match_type_spec): REAL can be an intrinsic function. 2018-12-09 Steven G. Kargl PR fortran/88206 * gfortran.dg/pr88206.f90: New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr88206.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/match.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug fortran/88206] [7/8/9 Regression] ICE in gfc_match_type_spec, at fortran/match.c:2229
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88206 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||kargl at gcc dot gnu.org Resolution|--- |FIXED --- Comment #7 from kargl at gcc dot gnu.org --- Fixed on trunk, branch-8, and branch-7.
[Bug c++/88419] [9 Regression] [ICE] "Same canonical type node for different types" for CTAD in noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88419 --- Comment #3 from Casey Carter --- 8.2 and 7.4 don't ICE: https://godbolt.org/z/VznOao. I was assuming that r266224 (the fix for #52869) likely caused the regression, although I haven't investigated.
[Bug fortran/88364] [9 Regression] Wrong-code due to CLOBBER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88364 --- Comment #5 from Harald Anlauf --- (In reply to Thomas Koenig from comment #4) > A simple fix is not to do the clobbers if there is a reference: The fix in c#4 fixes the testcase in c#2 for me. I'll give it a try.
[Bug sanitizer/88426] New: Compiler crash if use special code with command line switch -fsanitize=float-cast-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88426 Bug ID: 88426 Summary: Compiler crash if use special code with command line switch -fsanitize=float-cast-overflow Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: akaras at inbox dot ru CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Created attachment 45193 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45193&action=edit code sample GCC crashing if try to compile attached code with command: gcc -S -fsanitize=float-cast-overflow crash.c Issue can be reproduced on gcc (GCC) 8.2.1 20181209 and debian unstable gcc-8 package.
[Bug sanitizer/88426] Compiler crash if use special code with command line switch -fsanitize=float-cast-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88426 --- Comment #1 from Andrei Karas --- Created attachment 45194 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45194&action=edit crash log
[Bug fortran/88393] [7/8/9 Regression] [OOP] Segfault with type-bound assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88393 Dominique d'Humieres changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-09 Ever confirmed|0 |1 Known to fail||7.3.0, 8.2.0, 9.0 --- Comment #1 from Dominique d'Humieres --- The test compiled with r241883 + patches (2016-11-06) gives the expected result, compiled with r241924 + patches (2016-11-07) gives a segfault at run time.
[Bug target/88418] [7/8/9 Regression] ICE in extract_insn, at recog.c:2305 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88418 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-12-09 Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com Ever confirmed|0 |1 --- Comment #1 from Uroš Bizjak --- Created attachment 45195 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45195&action=edit Proposed patch Patch in testing.
[Bug target/88418] [7/8/9 Regression] ICE in extract_insn, at recog.c:2305 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88418 Uroš Bizjak changed: What|Removed |Added Target|x86_64-unknown-linux-gnu|x86 Target Milestone|--- |7.5
[Bug lto/88422] collect2.exe: fatal error: lto-wrapper returned 1 exit status: file not recognized: file truncated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88422 Jim Wilson changed: What|Removed |Added CC||wilson at gcc dot gnu.org --- Comment #2 from Jim Wilson --- I've reproduced this problem with a RISC-V gcc-8.x compiler, and tracked it down to the first patch for bug 81968, in comment #60. With the patch reverted, the testcase works. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968#c60 The RISC-V testcase works with Linux hosted and Cygwin hosted toolchains, and only fails for mingw32 hosted toolchains. Maybe an LLP64 problem with the patch? I didn't see any obvious type error in the patch though. I had to borrow a windows machine from our IT group to look at this, and they have since taken the loaner back, so I don't have a machine at work I can use to debug this at present.
[Bug fortran/88205] ICE in gfc_wide_strncasecmp, at fortran/scanner.c:249
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88205 --- Comment #3 from kargl at gcc dot gnu.org --- Author: kargl Date: Sun Dec 9 23:49:14 2018 New Revision: 266936 URL: https://gcc.gnu.org/viewcvs?rev=266936&root=gcc&view=rev Log: 2018-12-09 Steven G. Kargl PR fortran/88205 * io.c (gfc_match_open): Move NEWUNIT checks to after STATUS checks. 2018-12-09 Steven G. Kargl PR fortran/88205 * gfortran.dg/pr88205.f90: New unit. Added: trunk/gcc/testsuite/gfortran.dg/pr88205.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c trunk/gcc/testsuite/ChangeLog
[Bug c/67729] -Wformat should warn for %Ns where the buffer size is known to be less than N in size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67729 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org, ||msebor at gcc dot gnu.org --- Comment #3 from Eric Gallager --- Martin should probably know.
[Bug c/67729] -Wformat should warn for %Ns where the buffer size is known to be less than N in size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67729 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=72783 --- Comment #4 from Martin Sebor --- This looks like a near dupe of bug 72783 (or vice versa), though not exactly the same. That one asks for hardening which will be harder. Warning should be a lot easier. The file where -Wformat-overflow is implemented for sprintf et al. is gimple-ssa-sprintf.c. -Wformat alone is handled in c-family/c-format.c but that's not a good place to do buffer overflow checking (it runs too early to have knowledge of object sizes in all but the most trivial cases).
[Bug middle-end/87118] ICE in expand_expr_addr_expr_1, at expr.c:7862
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87118 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- This bug came up on the mailing lists here: https://gcc.gnu.org/ml/gcc/2018-12/msg00057.html
[Bug other/65794] Building crossback fails: No rule to make target `auto-build.h', needed by `build/genmddeps.o'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65794 Eric Gallager changed: What|Removed |Added Keywords||patch Status|UNCONFIRMED |NEW URL||https://gcc.gnu.org/ml/gcc- ||patches/2018-12/msg00525.ht ||ml Last reconfirmed||2018-12-10 CC||coypu at sdf dot org, ||egallager at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Eric Gallager --- There's a patch for this (or at least something similar) on the gcc-patches mailing list; taking it as confirmation: https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00525.html
[Bug other/65794] Building crossback fails: No rule to make target `auto-build.h', needed by `build/genmddeps.o'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65794 --- Comment #4 from coypu --- Hi, It's probably a setup/configuration issue for everyone reporting this issue. It's hard to debug, my patch helps with figuring out the problem - but doesn't fix it. I didn't ping this bug report because I don't understand what the other patch described here does.
[Bug fortran/88205] ICE in gfc_wide_strncasecmp, at fortran/scanner.c:249
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88205 --- Comment #4 from kargl at gcc dot gnu.org --- Author: kargl Date: Mon Dec 10 01:01:01 2018 New Revision: 266940 URL: https://gcc.gnu.org/viewcvs?rev=266940&root=gcc&view=rev Log: 2018-12-09 Steven G. Kargl PR fortran/88205 * io.c (gfc_match_open): Move NEWUNIT checks to after STATUS checks. 2018-12-09 Steven G. Kargl PR fortran/88205 * gfortran.dg/pr88205.f90: New unit. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr88205.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/io.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug fortran/88205] ICE in gfc_wide_strncasecmp, at fortran/scanner.c:249
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88205 --- Comment #5 from kargl at gcc dot gnu.org --- Author: kargl Date: Mon Dec 10 01:25:47 2018 New Revision: 266941 URL: https://gcc.gnu.org/viewcvs?rev=266941&root=gcc&view=rev Log: 2018-12-09 Steven G. Kargl PR fortran/88205 * io.c (gfc_match_open): Move NEWUNIT checks to after STATUS checks. 2018-12-09 Steven G. Kargl PR fortran/88205 * gfortran.dg/pr88205.f90: New unit. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr88205.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/io.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug fortran/88205] ICE in gfc_wide_strncasecmp, at fortran/scanner.c:249
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88205 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|NEW |RESOLVED CC||kargl at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org Target Milestone|--- |7.5 --- Comment #6 from kargl at gcc dot gnu.org --- Fixed on trunk, branch-8, and branch-7. clsoing.
[Bug rtl-optimization/56069] [7 Regression] RA pessimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56069 Jeffrey A. Law changed: What|Removed |Added Summary|[7/8/9 Regression] RA |[7 Regression] RA |pessimization |pessimization --- Comment #19 from Jeffrey A. Law --- This was fixed way back in 2017: commit a6e6a4df68e9e2cfbf4680b7f794254bc533d27c Author: uros Date: Mon Aug 14 16:42:15 2017 + PR target/46091 * config/i386/i386.md (*anddi_1_btr): New insn_and_split pattern. (*iordi_1_bts): Ditto. (*xordi_1_btc): Ditto. testsuite/ChangeLog: PR target/46091 * gcc.target/i386/pr46091-1.c: New test. * gcc.target/i386/pr46091-2.c: Ditto. * gcc.target/i386/pr46091-3.c: Ditto. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@251095 138bc75d-0d04-0410-961f-82ee72b054a4 :04 04 05739aaeccb137e9725a14cd94782096013169fa 53297b094d658372050f33eb62877dd228569169 M gcc
[Bug c++/88419] [9 Regression] [ICE] "Same canonical type node for different types" for CTAD in noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88419 --- Comment #4 from Marek Polacek --- They do with checking enabled: try -fchecking=1.
[Bug tree-optimization/88427] New: [9 Regression] ICE: tree check: expected integer_cst, have plus_expr in get_len, at tree.h:5617
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88427
Bug ID: 88427
Summary: [9 Regression] ICE: tree check: expected integer_cst,
have plus_expr in get_len, at tree.h:5617
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-9.0.0-alpha20181202 snapshot (r266729) ICEs when compiling the following
snippet w/ -O2 (-O3, -Ofast, -Os) -fno-tree-dce -fno-tree-fre:
void
uj (int eq, int s4)
{
short int tm = 0;
for (;;)
if (eq == s4)
{
tm += !!s4;
if (tm == s4)
{
eq += tm;
for (;;)
eq /= 0;
}
}
}
% gcc-9.0.0-alpha20181202 -O2 -fno-tree-dce -fno-tree-fre -w -c dr2mx6y0.c
during GIMPLE pass: vrp
dr2mx6y0.c: In function 'uj':
dr2mx6y0.c:2:1: internal compiler error: tree check: expected integer_cst, have
plus_expr in get_len, at tree.h:5617
2 | uj (int eq, int s4)
| ^~
0x6dd3f7 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/tree.c:9757
0x7db2b9 tree_check(tree_node const*, char const*, int, char const*, tree_code)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/tree.h:3410
0x7db2b9 wi::extended_tree<192>::get_len() const
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/tree.h:5617
0x7db2b9 wi::int_traits >
>::decompose(long*, unsigned int, generic_wide_int >
const&)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/wide-int.h:964
0x7db2b9 wide_int_ref_storage::wide_int_ref_storage >
>(generic_wide_int > const&, unsigned int)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/wide-int.h:1013
0x7db2b9 generic_wide_int
>::generic_wide_int >
>(generic_wide_int > const&, unsigned int)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/wide-int.h:788
0x7db2b9 bool wi::lts_p >,
generic_wide_int >
>(generic_wide_int > const&,
generic_wide_int > const&)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/wide-int.h:1879
0x7db2b9 wi::binary_traits >,
generic_wide_int >,
wi::int_traits > >::precision_type,
wi::int_traits >
>::precision_type>::signed_predicate_result operator<
>,
generic_wide_int >
>(generic_wide_int > const&,
generic_wide_int > const&)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/wide-int.h:3227
0x7db2b9 tree_int_cst_lt(tree_node const*, tree_node const*)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/tree.h:5773
0xffcd56 vr_values::extract_range_from_phi_node(gphi*, value_range*)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/vr-values.c:2870
0xf7e23b vrp_prop::extract_range_from_phi_node(gphi*, value_range*)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/tree-vrp.c:4303
0xf7e23b vrp_prop::visit_phi(gphi*)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/tree-vrp.c:6186
0xe92548 ssa_propagation_engine::simulate_stmt(gimple*)
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/tree-ssa-propagate.c:226
0xe93b1d ssa_propagation_engine::ssa_propagate()
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/tree-ssa-propagate.c:813
0xf8f58a execute_vrp
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181202/work/gcc-9-20181202/gcc/tree-vrp.c:6718
[Bug tree-optimization/88427] [9 Regression] ICE: tree check: expected integer_cst, have plus_expr in get_len, at tree.h:5617
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88427 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-10 CC||jakub at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r266557.
[Bug tree-optimization/88427] [9 Regression] ICE: tree check: expected integer_cst, have plus_expr in get_len, at tree.h:5617
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88427 --- Comment #2 from Jakub Jelinek --- We have: (gdb) p debug (lhs_vr) int [s4_11(D), s4_11(D) + 2]$3 = void (gdb) p debug (vr_result) int [s4_11(D), s4_11(D) + 32767]$4 = void (gdb) p cmp_min $5 = 0 (gdb) p cmp_max $6 = -1 and the /* If the new minimum is larger than the previous one retain the old value. If the new minimum value is smaller than the previous one and not -INF go all the way to -INF + 1. In the first case, to avoid infinite bouncing between different minimums, and in the other case to avoid iterating millions of times to reach -INF. Going to -INF + 1 also lets the following iteration compute whether there will be any overflow, at the expense of one additional iteration. */ code isn't prepared for cmp_min > 0 or cmp_max < 0 to have vr_result->min () or vr_result->max () of the form [-]sym + cst.
