[Bug rtl-optimization/88001] ASMCONS cannot handle properly UNSPEC(CONST)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88001 --- Comment #3 from Segher Boessenkool --- Created attachment 45210 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45210=edit proposed patch
[Bug target/88425] suboptimal code for a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88425 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Tue Dec 11 14:50:22 2018 New Revision: 267023 URL: https://gcc.gnu.org/viewcvs?rev=267023=gcc=rev Log: PR target/88425 * config/i386/i386.md (*x86_movcc_0_m1_neg_leu): New define_insn_and_split. * gcc.target/i386/pr88425.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr88425.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog
[Bug c/87950] GCC warns about reaching end of non-void function when all switch cases are completely handled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87950 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #14 from Jason Merrill --- It would certainly be possible to recognize this situation (all enumerators handled) and suppress the -Wreturn-type warning even though we can't in general assume that we can't get other values of the enumeration. With the ability to explicitly request warnings in this situation with another flag. I don't know how much work that would be.
[Bug testsuite/88454] [9 regression] test case gcc.dg/tree-ssa/split-path-5.c fails after r266971
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88454 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- On i686-linux I get: FAIL: gcc.dg/tree-ssa/split-path-11.c scan-tree-dump-times split-paths "join point for if-convertable half-diamond" 1 on x86_64-linux it passes.
[Bug c++/86049] Array bindings are not const when initializer is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86049 Tomalak Geret'kal changed: What|Removed |Added CC||tom at kera dot name --- Comment #3 from Tomalak Geret'kal --- I disagree and think that Clang is wrong. The top-level qualifiers of T (the type of One) should be "cv", and cv is "the cv-qualifiers in the decl-specifier-seq". The decl-specifier-seq is "auto", not "const auto". That "auto" will infer "const int" doesn't seem to be relevant. Discussion on https://stackoverflow.com/q/53726135/560648.
[Bug ada/88429] Ada bootstrap fails with --disable-shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88429 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-11 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- > Unlike the default (--enable-shared) case, it seems that the rts directory > for the non-default multilib is created incorrectly: with --enable-shared, I > see > > make THREAD_KIND=native setup-rts > make[9]: Entering directory > '/var/scratch/gcc/regression/trunk/4.17.3-gcc-gas-gld/build/gcc/ada' > rm -rf rts_32 > mkdir -p rts_32 > chmod u+w rts_32 > > while with --disable-shared, I get the creation of rts twice. > > This may be related to libada/configure.ac referencing a gnatlib-plain > target for --disable-shared, which I couldn't find elsewhere. Yes, but I don't understand why this doesn't fail in the default case too...
[Bug ada/88429] Ada bootstrap fails with --disable-shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88429 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #2 from Eric Botcazou --- Fixing.
[Bug c++/86049] Array bindings are not const when initializer is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86049 --- Comment #4 from Jonathan Wakely --- Richard, do you know if there's an issue for this yet?
[Bug c++/87603] [C++17] noexcept isn't special cased for constant expressions anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87603 Jonathan Wakely changed: What|Removed |Added CC||ldionne.2 at gmail dot com --- Comment #4 from Jonathan Wakely --- *** Bug 88453 has been marked as a duplicate of this bug. ***
[Bug c++/88453] GCC pretends that constexpr default-constructible type is nothrow constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88453 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- I think this is another manifestation of PR 87603 *** This bug has been marked as a duplicate of bug 87603 ***
[Bug ipa/87957] [9 Regression] ICE tree check: expected tree that contains ‘decl minimal’ structure, have ‘identifier_node’ in warn_odr, at ipa-devirt.c:1051 since r265519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87957 --- Comment #19 from Jan Hubicka --- Yeap, the warnings was written at the time all C++ types had TYPE_NAMEs and other types used IDENTIFIER_NODE. I have chnaged it for memory use reaosns so only main variants have IDENTIFIER_NODE. Usually we want to just look for main variant and complain about that. I will look into it. Honza
[Bug testsuite/88454] New: [9 regression] test case gcc.dg/tree-ssa/split-path-5.c fails after r266971
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88454 Bug ID: 88454 Summary: [9 regression] test case gcc.dg/tree-ssa/split-path-5.c fails after r266971 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/build/gcc-test/gcc/ /home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/tree-ssa/split-path-5.c -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -O2 -fsplit-paths -fdump-tree-split-paths-details -w -S -o split-path-5.s PASS: gcc.dg/tree-ssa/split-path-5.c (test for excess errors) gcc.dg/tree-ssa/split-path-5.c: pattern found 0 times FAIL: gcc.dg/tree-ssa/split-path-5.c scan-tree-dump-times split-paths "join point for if-convertable half-diamond" 1 testcase /home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/tree-ssa/tree-ssa.exp completed in 0 seconds === gcc Summary === # of expected passes1 # of unexpected failures1 r266971 | law | 2018-12-10 22:56:54 -0600 (Mon, 10 Dec 2018) | 6 lines PR tree-optimization/80520 * gimple-ssa-split-paths.c (is_feasible_trace): Recognize half diamonds that are likely if convertable. * gcc.dg/tree-ssa/split-path-5.c: Update expected output. * gcc.dg/tree-ssa/split-path-11.c: New test.
[Bug tree-optimization/88444] [9 Regression] ICE: tree check: expected ssa_name, have integer_cst in live_on_edge, at tree-vrp.c:468; or ICE: tree check: expected ssa_name, have integer_cst in get_val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88444 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Tue Dec 11 17:16:48 2018 New Revision: 267026 URL: https://gcc.gnu.org/viewcvs?rev=267026=gcc=rev Log: PR tree-optimization/88444 * tree-vrp.c (register_edge_assert_for_2): Only register assertions for conversions if rhs1 is a SSA_NAME. * gcc.dg/pr88444.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr88444.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug fortran/88452] gfortran (Gentoo 8.2.0-r5 p1.6) 8.2.0 reports internal error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88452 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-11 CC||kargl at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from kargl at gcc dot gnu.org --- Reduced testcase. subroutine tccdenom(n1,n2) implicit none integer n1, n2 real tt1(n1,n2) complex ctt1(n1,n2) equivalence(tt1(1,1), ctt1(1,1)) end Workaround is to remove the dimension in the equivalence statement. This compiles subroutine tccdenom(n1,n2) implicit none integer n1, n2 real tt1(n1,n2) complex ctt1(n1,n2) equivalence(tt1, ctt1) end
[Bug c++/88375] Vague source location for bad initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88375 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-12-11 Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org Ever confirmed|0 |1
[Bug rtl-optimization/88416] [8/9 Regression] ICE in in df_uses_record, at df-scan.c:3013
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88416 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 45209 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45209=edit gcc9-pr88416.patch Untested fix. The problem are targets like x86 which are not AUTO_INC_DEC, but still have some patterns that use those expressions (pushes/pops). As for !AUTO_INC_DEC we just called copy_rtx which does pretty much the same copying/walking as cleanup_auto_inc_dec, except that the latter will handle those properly, I think the best fix is just to never use copy_rtx here.
[Bug c++/88453] New: GCC pretends that constexpr default-constructible type is nothrow constructible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88453
Bug ID: 88453
Summary: GCC pretends that constexpr default-constructible type
is nothrow constructible
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
Target Milestone: ---
The following code does not compile with GCC trunk:
#include
struct Throwing {
constexpr Throwing() {}
};
static_assert(!std::is_nothrow_default_constructible::value, "");
It seems like GCC assumes that the default constructor is noexcept since it is
constexpr. Clang does not have this behaviour, and I believe Clang to be
correct in this case.
Live example: https://wandbox.org/permlink/1z1qYQSUDWsYJda1
[Bug c++/88434] operator< should take precedence over template argument in basic.lookup.classref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88434 --- Comment #2 from Andrew Giese --- It appears there is a CWG issue for this: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1835
[Bug rtl-optimization/88001] ASMCONS cannot handle properly UNSPEC(CONST)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88001 --- Comment #4 from Segher Boessenkool --- Claudiu: could you test that patch please? (On the real thing, not just this testcase :-) )
[Bug fortran/88455] False positive for allocatable character array of deferred length, ALLOCATE using SOURCE/MOLD [-Wuninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88455
--- Comment #2 from Adam Hirst ---
Slightly reduced - the issue occurs even in the MAIN program:
program test
implicit none
integer :: a, b, c
character(:), allocatable :: line(:)
a = 1; b = 10; c = 30
allocate( line(a:b), source = repeat(" ",c) )
end program test
...and also if the integers are declared PARAMETER:
program test
implicit none
integer, parameter:: a=1, b=10, c=30
character(:), allocatable :: line(:)
allocate( line(a:b), source = repeat(" ",c) )
end program test
...and even if they're hard-coded into the ALLOCATE call:
program test
implicit none
character(:), allocatable :: line(:)
allocate( line(1:10), source = repeat(" ",30) )
end program test
Yet, as far as I understand the Fortran standard, the string `line` here should
be considered fully allocated by the ALLOCATE statement, therefore I think
the warning is spurious.
[Bug fortran/88249] ICE in gfc_resolve_filepos, at fortran/io.c:2853
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88249 --- Comment #5 from kargl at gcc dot gnu.org --- Author: kargl Date: Wed Dec 12 00:08:12 2018 New Revision: 267037 URL: https://gcc.gnu.org/viewcvs?rev=267037=gcc=rev Log: 2018-12-11 Steven G. Kargl PR fortran/88249 * gfortran.h: Update prototype for gfc_resolve_filepos(). * io.c (gfc_resolve_filepos): Check for UNIT number if ERR= is present. Use passed in locus for error message. * resolve.c (gfc_resolve_code): Pass locus in gfc_resolve_filepos() call. 2018-12-11 Steven G. Kargl PR fortran/88249 * gfortran.dg/pr88249.f90: New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr88249.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/gfortran.h branches/gcc-7-branch/gcc/fortran/io.c branches/gcc-7-branch/gcc/fortran/resolve.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug fortran/88249] ICE in gfc_resolve_filepos, at fortran/io.c:2853
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88249 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED 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. Closing.
[Bug bootstrap/65725] Bootstrap errors on Solaris 10 x86-64, including object diffs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65725 --- Comment #8 from Daniel Richard G. --- Hello Rainer, (In reply to r...@cebitec.uni-bielefeld.de from comment #7) > That bootstrap (amd64-pc-solaris2.10 with as/ld, --disable-shared > --with-pic) has now completed as well: in addition to libcc1 (PR > other/66955) and ada (cf. PR ada/88429), I also had to disable go > because it uses sendfile without explicitly linking with -lsendfile (in > the shared case, this works because libgo is linked with libsendfile). > > Anyway, the bootstrap has now finished successfully and make check is > running: no comparison failures at all. So unless there's additional > information how to reproduce this, I'll close the PR as WORKSFORME. I tested this again with GCC 8.2.0 on the same system, using as/ld, and am still seeing the object diffs. Would it help if I provided a copy of the objects at issue?
[Bug fortran/88155] ICE in gfc_format_decoder, at fortran/error.c:947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88155 --- Comment #3 from kargl at gcc dot gnu.org --- Author: kargl Date: Wed Dec 12 00:53:08 2018 New Revision: 267041 URL: https://gcc.gnu.org/viewcvs?rev=267041=gcc=rev Log: 2018-12-11 Steven G. Kargl PR fortran/88155 * primary.c (gfc_match_structure_constructor): Set the locus of an expression to avoid a NULL pointer dereference. 2018-12-11 Steven G. Kargl PR fortran/88155 * gfortran.dg/pr70870_1.f90: Update testcase to use -std=gnu. * gfortran.dg/pr88155.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr88155.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/primary.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/pr70870_1.f90
[Bug fortran/88455] False positive for allocatable character array of deferred length, ALLOCATE using SOURCE/MOLD [-Wuninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88455 --- Comment #1 from Adam Hirst --- I'm not sure whether they're related, but I found a handful of potentially-similar bugs, which might be worth collating here for quicker reference. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28660 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32035 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46979 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53714 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66459
[Bug middle-end/86979] [9 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2348 with -m32 on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86979
Jakub Jelinek changed:
What|Removed |Added
CC||abel at gcc dot gnu.org,
||amonakov at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek ---
Aha, I had to use -fpic additionally in my cross.
Seems like sel-sched bug to me.
In *.split4 we still have correct:
(insn/f 71 9 72 2 (parallel [
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int -12 [0xfff4])))
(clobber (reg:CC 17 flags))
(clobber (mem:BLK (scratch) [0 A8]))
]) "pr69102.c":8:1 954 {pro_epilogue_adjust_stack_si_add}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_CFA_ADJUST_CFA (set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int -12 [0xfff4])))
(nil
in prologue at the start of function, then body including a tablejump and
finally
(insn 48 47 49 5 (parallel [
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int -12 [0xfff4])))
(clobber (reg:CC 17 flags))
]) "pr69102.c":22:3 190 {*addsi_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_ARGS_SIZE (const_int 12 [0xc])
(nil
(insn 49 48 50 5 (set (mem:SI (pre_dec:SI (reg/f:SI 7 sp)) [1 S4 A32])
(reg/v:SI 0 ax [orig:84 ch ] [84])) "pr69102.c":22:3 43 {*pushsi2}
(expr_list:REG_DEAD (reg/v:SI 0 ax [orig:84 ch ] [84])
(expr_list:REG_ARGS_SIZE (const_int 16 [0x10])
(nil
(call_insn 50 49 73 5 (call (mem:QI (symbol_ref:SI ("bar") [flags 0x41]
) [0 bar S1 A8])
(const_int 16 [0x10])) "pr69102.c":22:3 663 {*call}
(nil)
(nil))
(note 73 50 74 5 NOTE_INSN_EPILOGUE_BEG)
(insn/f 74 73 75 5 (parallel [
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int 28 [0x1c])))
(clobber (reg:CC 17 flags))
(clobber (mem:BLK (scratch) [0 A8]))
]) "pr69102.c":23:1 954 {pro_epilogue_adjust_stack_si_add}
(expr_list:REG_ARGS_SIZE (const_int 0 [0])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_CFA_ADJUST_CFA (set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int 12 [0xc])))
(nil)
(jump_insn 75 74 78 5 (simple_return) "pr69102.c":23:1 686
{simple_return_internal}
(nil)
as the only stack-changing instructions. But sel-sched for some reason copies
the sp adjustment (insn 48) above to a different basic block before the
tablejump and due to that copy there is a basic block reachable from code with
different stack depths (i.e. different CFA offset), the initial one from right
after the prologue and the adjusted one due to this sel-sched bug.
[Bug middle-end/53714] false positive for -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53714 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dominique d'Humieres --- Fixed between revisions r232451 (2016-01-15, warning) and r233563 (2016-02-19, OK).
[Bug fortran/88249] ICE in gfc_resolve_filepos, at fortran/io.c:2853
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88249 --- Comment #4 from kargl at gcc dot gnu.org --- Author: kargl Date: Tue Dec 11 23:39:43 2018 New Revision: 267036 URL: https://gcc.gnu.org/viewcvs?rev=267036=gcc=rev Log: 2018-12-11 Steven G. Kargl PR fortran/88249 * gfortran.h: Update prototype for gfc_resolve_filepos(). * io.c (gfc_resolve_filepos): Check for UNIT number if ERR= is present. Use passed in locus for error message. * resolve.c (gfc_resolve_code): Pass locus in gfc_resolve_filepos() call. 2018-12-11 Steven G. Kargl PR fortran/88249 * gfortran.dg/pr88249.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr88249.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/gfortran.h branches/gcc-8-branch/gcc/fortran/io.c branches/gcc-8-branch/gcc/fortran/resolve.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/88440] size optimization of memcpy-like code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88440 --- Comment #3 from krux --- Adding -ftree-loop-distribute-patterns to -Os does not seem to make a difference though.
[Bug other/88456] New: __atomic_compare_exchange implementation inconsistently used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88456
Bug ID: 88456
Summary: __atomic_compare_exchange implementation
inconsistently used
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: patrick at motec dot com.au
Target Milestone: ---
While implementing atomic support for an embedded target I came across some
unexpected behaviour in gcc.
In the following example:
#include
#include
#include
bool
__atomic_compare_exchange_1(uint8_t *p, uint8_t *e, uint8_t d, bool w, int sm,
int fm)
{
asm volatile("nop");
return false;
}
int main()
{
uint8_t x, e, d;
atomic_compare_exchange_strong_explicit(, , d, 0, 0);
return 0;
}
The provided __atomic_compare_exchange_1 implementation is only used at -O2 or
greater:
% gcc -c -O0 test.c; objdump -d test.o |grep cmpxchg
60: f0 40 0f b0 31 lock cmpxchg %sil,(%rcx)
% gcc -c -O1 test.c; objdump -d test.o |grep cmpxchg
20: f0 0f b0 4c 24 07 lock cmpxchg %cl,0x7(%rsp)
% gcc -c -O2 test.c; objdump -d test.o |grep cmpxchg
% gcc -c -O3 test.c; objdump -d test.o |grep cmpxchg
This was observed with gcc 8.2.1:
% gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
--enable-cet=auto
Thread model: posix
gcc version 8.2.1 20181127 (GCC)
[Bug c++/88375] Vague source location for bad initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88375 David Malcolm changed: What|Removed |Added Keywords||patch --- Comment #1 from David Malcolm --- Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00746.html
[Bug ada/88429] Ada bootstrap fails with --disable-shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88429 --- Comment #3 from Eric Botcazou --- Author: ebotcazou Date: Tue Dec 11 23:04:39 2018 New Revision: 267034 URL: https://gcc.gnu.org/viewcvs?rev=267034=gcc=rev Log: libada/ PR ada/88429 * configure.ac (default_gnatlib_target): Set to gnatlib instead of gnatlib-plain if --disable-shared. * configure: Regenerate. * Makefile.in (all): Replace gnatlib prerequisite with libada. (ADA_RTS_SUBDIR): Delete. (libada): New target, renamed from... (gnatlib): ...this. Merge with other library targets. (gnatlib-plain): Delete. (install-gnatlib): Rename to... (install-libada): ...this. (install): Replace install-gnatlib prerequisite with install-libada. gcc/ada/ PR ada/88429 * gcc-interface/Makefile.in (./stamp-gnatlib1-$(RTSDIR)): Also pass MULTISUBDIR to sub-make and add quotes around $(THREAD_KIND). (gnatlib-shared-dual): Also pass PICFLAG_FOR_TARGET to sub-make. (gnatlib-sjlj): Also pass MULTISUBDIR to sub-make, but do not pass PICFLAG_FOR_TARGET. (gnatlib-zcx): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/Makefile.in trunk/libada/ChangeLog trunk/libada/Makefile.in trunk/libada/configure trunk/libada/configure.ac
[Bug c++/86608] [7/8 Regression] volatile variable is taken as a constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86608 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Summary|[7/8/9 Regression] volatile |[7/8 Regression] volatile |variable is taken as a |variable is taken as a |constexpr |constexpr --- Comment #7 from Marek Polacek --- Fixed for GCC 9.
[Bug fortran/88155] ICE in gfc_format_decoder, at fortran/error.c:947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88155 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED 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.
[Bug fortran/88155] ICE in gfc_format_decoder, at fortran/error.c:947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88155 --- Comment #5 from kargl at gcc dot gnu.org --- Author: kargl Date: Wed Dec 12 01:26:12 2018 New Revision: 267043 URL: https://gcc.gnu.org/viewcvs?rev=267043=gcc=rev Log: 2018-12-11 Steven G. Kargl PR fortran/88155 * primary.c (gfc_match_structure_constructor): Set the locus of an expression to avoid a NULL pointer dereference. 2018-12-11 Steven G. Kargl PR fortran/88155 * gfortran.dg/pr70870_1.f90: Update testcase to use -std=gnu. * gfortran.dg/pr88155.f90: New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr88155.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/primary.c branches/gcc-7-branch/gcc/testsuite/ChangeLog branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr70870_1.f90
[Bug target/83562] broken destructors of thread_local objects on i686 mingw targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83562 --- Comment #3 from Thiago Macieira --- This can easily be fixed by way of a trampoline that adjusts the parameter.
[Bug fortran/88455] False positive for allocatable character array of deferred length, ALLOCATE using SOURCE/MOLD [-Wuninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88455 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-11 Version|unknown |9.0 Blocks||24639 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres --- Confirmed from 5.5.0 up to trunk (9.0). Compiling the code with 4.8 or 4.9 gives an ICE. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 [Bug 24639] [meta-bug] bug to track all Wuninitialized issues
[Bug ada/88429] [9 regression] libada build fails with --disable-shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88429 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 Summary|Ada bootstrap fails with|[9 regression] libada build |--disable-shared|fails with --disable-shared --- Comment #4 from Eric Botcazou --- This should work again.
[Bug fortran/88249] ICE in gfc_resolve_filepos, at fortran/io.c:2853
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88249 --- Comment #3 from kargl at gcc dot gnu.org --- Author: kargl Date: Tue Dec 11 23:13:19 2018 New Revision: 267035 URL: https://gcc.gnu.org/viewcvs?rev=267035=gcc=rev Log: 2018-12-11 Steven G. Kargl PR fortran/88249 * gfortran.h: Update prototype for gfc_resolve_filepos(). * io.c (gfc_resolve_filepos): Check for UNIT number if ERR= is present. Use passed in locus for error message. * resolve.c (gfc_resolve_code): Pass locus in gfc_resolve_filepos() call. 2018-12-11 Steven G. Kargl PR fortran/88249 * gfortran.dg/pr88249.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr88249.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/io.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/88455] New: False positive for allocatable character array of deferred length, ALLOCATE using SOURCE/MOLD [-Wuninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88455
Bug ID: 88455
Summary: False positive for allocatable character array of
deferred length, ALLOCATE using SOURCE/MOLD
[-Wuninitialized]
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: adam at aphirst dot karoo.co.uk
Target Milestone: ---
program test
implicit none
call F(1, 10, 30)
contains
subroutine F(i,j,k)
integer, intent(in) :: i, j, k
character(:), allocatable :: line(:)
! with a hard-coded len, the warning goes away
! similarly if it's deferred-length but scalar
!character(k), allocatable :: line(:)
allocate( line(i:j), source = repeat(" ",k) )
print *, size(line) ! gives 10
print *, len(line) ! gives 30
end subroutine
end program test
---
Warning: ‘.line’ is used uninitialized in this function [-Wuninitialized]
---
Using a single ALLOCATE statement for an allocatable array of CHARACTER with
deferred length (using either SOURCE or MOLD) results in a false positive for
uninitialised variables.
The issue doesn't occur if the variable is ONLY an allocatable array, or
respectively if it's ONLY of deferred length. The issue occurs only when both
degrees of freedom are present.
System:
---
gcc (GCC) 8.2.1 20181127
Arch Linux x86_64
[Bug fortran/77385] "Unclassifiable statement" from gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77385 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Dominique d'Humieres --- AFAICT everything has been fixed, closing.
[Bug fortran/88155] ICE in gfc_format_decoder, at fortran/error.c:947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88155 --- Comment #4 from kargl at gcc dot gnu.org --- Author: kargl Date: Wed Dec 12 01:14:58 2018 New Revision: 267042 URL: https://gcc.gnu.org/viewcvs?rev=267042=gcc=rev Log: 2018-12-11 Steven G. Kargl PR fortran/88155 * primary.c (gfc_match_structure_constructor): Set the locus of an expression to avoid a NULL pointer dereference. 2018-12-11 Steven G. Kargl PR fortran/88155 * gfortran.dg/pr70870_1.f90: Update testcase to use -std=gnu. * gfortran.dg/pr88155.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr88155.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/primary.c branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr70870_1.f90
[Bug c++/86608] [7/8/9 Regression] volatile variable is taken as a constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86608 --- Comment #6 from Marek Polacek --- Author: mpolacek Date: Tue Dec 11 18:53:03 2018 New Revision: 267030 URL: https://gcc.gnu.org/viewcvs?rev=267030=gcc=rev Log: PR c++/86608 - reading constexpr volatile variable. * constexpr.c (potential_constant_expression_1): Check want_rval instead of checking if we have a decl. * decl2.c (decl_maybe_constant_var_p): Don't consider volatile constexpr variables as maybe constant. * g++.dg/cpp0x/constexpr-volatile2.C: New test. * g++.dg/cpp0x/pr65327.C: Add dg-error. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-volatile2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/cp/decl2.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/pr65327.C
[Bug c++/87951] GCC warns about reaching end of non-void function when all switch is completely handled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87951 --- Comment #17 from Vitali --- I was explicitly asked to open this as a separate bug in comment #7 of 87950. Would be helpful if the GCC devs could coordinate to figure out if they want separate bugs for C/C++ or 1 bug. Jonathan, on this forum your feedback comes off a bit like Skinner where he blames the children. There's clearly a gap between how compiler authors define switches as working & how developers wish to use those enums/wish those enums were actually defined. I appreciate there's a large amount of legacy code that complicates this issue but I don't think that condescending to people trying to communicate the issue in good faith moves the conversation along. I'd argue that clang strikes a much better balance here in terms of the practical implications of the warning even if it's not perfect. In my mind, warnings are most useful when they optimize for a low rate of false positives. The GCC warnings for enums do not in practice have a low rate of false positives and are clearly tuned to minimize false negatives (i.e. accidentally missing a switch statement that doesn't have all enums covered). At the very least it would be useful to give users the power to turn on a warning equivalent to Clang's that minimizes false negatives (or change -Wswitch to be equivalent to Clang & add a -Wpedantic-switch that's part of -pedantic for the current behaviour). You could even provide annotations that let users annotate enums/switches in an explicit fashion to indicate that they can be constructed with non-label values/aren't expected to be depending on which flag you choose to use to silence warnings/let the compiler optimize more fully. In practice, definitely in C++, enums ARE intended to be a closed set of all possible paths & the flags/random integer value cases are far less frequently used; even for bitmasks it's a lazy way to do it. In C++ I usually define strongly-typed types that represent the bitmask & overload the bit math operators for the enum to yield that secondary type. I think considering that's a technique used by Boost & Qt, it's reasonable to assume that having the enum double as the storage type for the bitmask is more of a hack technically allowed than one that is considered best practice by large C++ projects. In C it's more muddled because there's no operator overloading, but the number of enums that exist far outnumber the uses where it's used for bitwise math.
[Bug target/88435] Compiling with optimizations causes the compiler to fail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88435 Mattis Lind changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Mattis Lind --- I can confirm that latest 9.0 doesn't have this problem.
[Bug tree-optimization/80520] [7/8/9 Regression] Performance regression from missing if-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80520 --- Comment #13 from Jakub Jelinek --- Author: jakub Date: Tue Dec 11 20:28:35 2018 New Revision: 267031 URL: https://gcc.gnu.org/viewcvs?rev=267031=gcc=rev Log: PR tree-optimization/80520 * gcc.dg/tree-ssa/split-path-11.c (foo): Make the test ilp32 target clean. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/split-path-11.c
[Bug c++/86049] Array bindings are not const when initializer is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86049 --- Comment #5 from Richard Smith --- This was just reported as http://lists.isocpp.org/core/2018/12/5320.php; I don't believe it's on the core issues list yet. [@Tomalak, I think the standard is clear here: "If the assignment-expression in the initializer has array type A and no ref-qualifier is present, e has type cv A" Here, A is the array type 'const int[1]' and cv is empty, so e has type 'const int[1]'. But, as noted in comment#2, that seems like the wrong outcome. It also contradicts the non-normative note in [dcl.struct.bind]p3, which further suggests that this outcome was probably not the intent of the wording.]
[Bug c++/87861] [9 regression] ICE in output_constructor_regular_field, at varasm.c:5165
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87861 --- Comment #11 from Jakub Jelinek --- Author: jakub Date: Tue Dec 11 20:37:53 2018 New Revision: 267032 URL: https://gcc.gnu.org/viewcvs?rev=267032=gcc=rev Log: PR c++/87861 * class.c (build_vtbl_initializer): For TARGET_VTABLE_USES_DESCRIPTORS bump index for each added word. * constexpr.c (find_array_ctor_elt): Add forward declaration. (cxx_eval_call_expression): Handle TARGET_VTABLE_USES_DESCRIPTORS vtable calls. (cxx_eval_constant_expression) : Divide token by TARGET_VTABLE_USES_DESCRIPTORS if non-zero. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/constexpr.c
[Bug ipa/87957] [9 Regression] ICE tree check: expected tree that contains ‘decl minimal’ structure, have ‘identifier_node’ in warn_odr, at ipa-devirt.c:1051 since r265519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87957 --- Comment #20 from Eric Botcazou --- > I guess the middle-end relies on TYPE_NAME to have the TYPE_MAIN_VARIANT > type rather than be qualified. The question if just here and it is possible > to cope with that, or elsewhere too. Yes, but only here and only for a couple of weeks, i.e. it's a novelty.
[Bug c++/88434] [DR1835] operator< should take precedence over template argument in basic.lookup.classref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88434 Andrew Pinski changed: What|Removed |Added Status|NEW |SUSPENDED --- Comment #4 from Andrew Pinski --- Suspecting until the Defect report is resolved.
[Bug testsuite/37703] Ada testsuites lack multilib support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37703 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=37704 --- Comment #5 from Eric Gallager --- Related: bug 37704
[Bug rtl-optimization/88001] ASMCONS cannot handle properly UNSPEC(CONST)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88001 Vineet Gupta changed: What|Removed |Added CC||vgupta at synopsys dot com --- Comment #5 from Vineet Gupta --- Hi, I'm the ARC glibc maintainer (and desperate for this fix). The proposed (one liner) patch seems to fix the compiler assert for sue. I'm still running more tests to make sure it is functional but looks promising.
[Bug fortran/88116] [8/9 Regression] ICE in gfc_convert_constant(): Unexpected type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88116 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #5 from kargl at gcc dot gnu.org --- (In reply to G. Steinmetz from comment #0) > Silently accepted invalid code, produces a wrong result : > > > $ cat z2.f90 > program p >print *, [integer :: 1, [integer(8) :: 2, '3']] > end > > > $ gfortran-9-20181118 z2.f90 -static-libgfortran > $ a.out >1 2 0 Gerhard, I don't know if you like to keep track of issues that you submit or not. The above is quite strange if integer(8) is replaced with integer or integer(4), I get the expected error message. If it is integer(1), integer(2), or integer(8), it silently compiles. If I do, print *, [integer(8) :: 2, '3'] I et the expected error. Do you want to migrate this to its own PR? If not, I'll do it when I get around to committing the fix for the other issues.
[Bug target/51509] Inefficient neon intrinsic code sequence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51509 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=65375 --- Comment #7 from Eric Gallager --- (In reply to Maxim Kuvyrkov from comment #5) > Oh, sorry, I missed the fact that PR65375 is for aarch64 and this one is for > armv7. Charles, would you please look at this? Should Charles still remain the assignee for this?
[Bug rtl-optimization/88001] ASMCONS cannot handle properly UNSPEC(CONST)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88001 --- Comment #6 from Claudiu Zissulescu --- The dejagnu tests for ARC look alright. No extra failures.
[Bug c/26732] different argument type not rejected for K style function definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26732 --- Comment #7 from Eric Gallager --- (In reply to Andrew Pinski from comment #6) > Now we don't even error out at -O3. Why would the -O3 matter?
[Bug tree-optimization/81811] missing -Wreturn-local-addr returning strcpy result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81811 Eric Gallager changed: What|Removed |Added Keywords||missed-optimization --- Comment #4 from Eric Gallager --- (In reply to Martin Sebor from comment #3) > (In reply to Richard Biener from comment #2) > > Wonder whether the memcpy case is because we fold the memcpy away as both > > memcpy and strcpy are marked RET1 (returns arg1). > > The memcpy is eliminated in DSE and turned into a plain 'return a' statement > that the find_explicit_erroneous_behavior() in tree-ssa-isolate-paths.c > that implements the warning knows how to handle. > > DSE doesn't handle strcpy or strncpy so the calls are not eliminated and > because find_explicit_erroneous_behavior() doesn't handle calls, the 'return > strcpy(a, s)' statement isn't detected. > > This suggests an opportunity to improve not just the warning but also DSE. so, sounds like a missed-optimization too, then
[Bug c++/87951] GCC warns about reaching end of non-void function when all switch is completely handled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87951 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=81665 --- Comment #18 from Eric Gallager --- (In reply to Vitali from comment #17) > I was explicitly asked to open this as a separate bug in comment #7 of > 87950. Would be helpful if the GCC devs could coordinate to figure out if > they want separate bugs for C/C++ or 1 bug. > > Jonathan, on this forum your feedback comes off a bit like Skinner where he > blames the children. There's clearly a gap between how compiler authors > define switches as working & how developers wish to use those enums/wish > those enums were actually defined. I appreciate there's a large amount of > legacy code that complicates this issue but I don't think that condescending > to people trying to communicate the issue in good faith moves the > conversation along. > > I'd argue that clang strikes a much better balance here in terms of the > practical implications of the warning even if it's not perfect. In my mind, > warnings are most useful when they optimize for a low rate of false > positives. The GCC warnings for enums do not in practice have a low rate of > false positives and are clearly tuned to minimize false negatives (i.e. > accidentally missing a switch statement that doesn't have all enums > covered). > > At the very least it would be useful to give users the power to turn on a > warning equivalent to Clang's that minimizes false negatives (or change > -Wswitch to be equivalent to Clang & add a -Wpedantic-switch that's part of > -pedantic for the current behaviour). > > You could even provide annotations that let users annotate enums/switches in > an explicit fashion to indicate that they can be constructed with non-label > values/aren't expected to be depending on which flag you choose to use to > silence warnings/let the compiler optimize more fully. > > In practice, definitely in C++, enums ARE intended to be a closed set of all > possible paths & the flags/random integer value cases are far less > frequently used; even for bitmasks it's a lazy way to do it. In C++ I > usually define strongly-typed types that represent the bitmask & overload > the bit math operators for the enum to yield that secondary type. I think > considering that's a technique used by Boost & Qt, it's reasonable to assume > that having the enum double as the storage type for the bitmask is more of a > hack technically allowed than one that is considered best practice by large > C++ projects. In C it's more muddled because there's no operator > overloading, but the number of enums that exist far outnumber the uses where > it's used for bitwise math. This reminded me of bug 81665
[Bug bootstrap/59447] --with-dwarf2 should be documented as meaning "DWARF 2 or later" instead of just "DWARF 2"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59447 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #5 from sandra at gcc dot gnu.org --- Actually, this issue is already on my radar, but there are definitely more documentation bugs out there than I have time to fix this release cycle. Of course there's nothing stopping other people from fixing some of these things too. :-)
[Bug target/88457] New: ICE: Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88457 Bug ID: 88457 Summary: ICE: Max. number of generated reload insns per insn is achieved (90) Product: gcc Version: unknown Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- Target: powerpc-*-linux-gnu gcc-9.0.0-alpha20181209 snapshot (r266934) ICEs when compiling gcc/testsuite/gcc.target/powerpc/clone1.c w/ -mcpu=power7 -O1 -fexpensive-optimizations --param ira-max-conflict-table-size=0 --param max-cse-insns=3: % powerpc-e300c3-linux-gnu-gcc-9.0.0-alpha20181209 -mcpu=power7 -O1 -fexpensive-optimizations --param ira-max-conflict-table-size=0 --param max-cse-insns=3 -c gcc/testsuite/gcc.target/powerpc/clone1.c during RTL pass: reload gcc/testsuite/gcc.target/powerpc/clone1.c: In function 'mod_func_or': gcc/testsuite/gcc.target/powerpc/clone1.c:23:1: internal compiler error: Max. number of generated reload insns per insn is achieved (90) 23 | } | ^ 0xba14ee lra_constraints(bool) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181209/work/gcc-9-20181209/gcc/lra-constraints.c:4850 0xb882f8 lra(_IO_FILE*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181209/work/gcc-9-20181209/gcc/lra.c:2446 0xb3e2f4 do_reload /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181209/work/gcc-9-20181209/gcc/ira.c:5475 0xb3e2f4 execute /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181209/work/gcc-9-20181209/gcc/ira.c:5659
[Bug rtl-optimization/79593] [7/8/9 Regression] Poor/Worse code generation for FPU on versions after 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79593
--- Comment #21 from Jeffrey A. Law ---
We have this after IRA:
(insn 27 26 28 4 (set (reg:DI 101 [ pretmp_22 ])
(zero_extend:DI (subreg:SI (reg:SF 91 [ pretmp_22 ]) 0))) "j.C":20:35
114 {*zero_extendsidi2}
(expr_list:REG_DEAD (reg:SF 91 [ pretmp_22 ])
(nil)))
(insn 28 27 29 4 (set (reg:XF 100)
(float:XF (reg:DI 101 [ pretmp_22 ]))) "j.C":20:35 169 {floatdixf2}
(expr_list:REG_DEAD (reg:DI 101 [ pretmp_22 ])
(nil)))
Where 91 and 101 will get assigned to memory locations because of the 'm'
constraint for floatdixf2. r100 gets a hard register. We're going to need a
reload for insn 27. So after LRA we have:
(insn 100 26 27 4 (set (reg:SI 0 ax [110])
(mem/c:SI (reg/f:SI 7 sp) [6 %sfp+-8 S4 A64])) "j.C":20:35 67
{*movsi_internal}
(nil))
(insn 27 100 28 4 (set (mem/c:DI (reg/f:SI 7 sp) [6 %sfp+-8 S8 A64])
(zero_extend:DI (reg:SI 0 ax [110]))) "j.C":20:35 114
{*zero_extendsidi2}
(nil))
[ insn 28 doesn't really play a role here other than requiring the 'm'
operand]
The x86 backend has a splitter to optimize insn 27. So post LRA splitting
generates:
(insn 100 26 107 4 (set (reg:SI 0 ax [110])
(mem/c:SI (reg/f:SI 7 sp) [6 %sfp+-8 S4 A64])) "j.C":20:35 67
{*movsi_internal}
(nil))
(insn 107 100 108 4 (set (mem/c:SI (reg/f:SI 7 sp) [6 %sfp+-8 S4 A64])
(reg:SI 0 ax [110])) "j.C":20:35 67 {*movsi_internal}
(nil))
(insn 108 107 28 4 (set (mem/c:SI (plus:SI (reg/f:SI 7 sp)
(const_int 4 [0x4])) [6 %sfp+-4 S4 A32])
(const_int 0 [0])) "j.C":20:35 67 {*movsi_internal}
(nil))
Now we've finally exposed the redundancy.This can be addressed in DSE2
which runs after SPLIT2. But it's not all that generally effective. Figure
we're getting ~8 hits per stage during a bootstrap -- all in the runtime
system.
I looked at perhaps trying to detect the partial dead store in postreload-gcse.
THere's a lot of good memory tracking bits in here, but it's still not a good
fit.
It doesn't really feel like an IRA/LRA problem to me. Their decisions are sane
AFAICT.
We could try and catch it with a new peephole pattern, but that seems even less
desirable than detecting this in a generic way during DSE.
[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-11 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- .
[Bug c/88442] Misleading error message with duplicated struct definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88442 Richard Biener changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |RESOLVED Known to work||8.1.0 Resolution|--- |FIXED Known to fail||7.4.0 --- Comment #1 from Richard Biener --- This was fixed for GCC 8.
[Bug c++/87951] GCC warns about reaching end of non-void function when all switch is completely handled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87951 --- Comment #16 from Jonathan Wakely --- (In reply to Martin Sebor from comment #14) > This is a duplicate of bug 87950, with most of the same discussion. > > *** This bug has been marked as a duplicate of bug 87950 *** I think I need to add an "Enums 101" section to https://gcc.gnu.org/wiki/FAQ or https://gcc.gnu.org/wiki/VerboseDiagnostics
[Bug middle-end/88448] [9 regression] gnat.dg/opt66.adb etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88448 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-12-11 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Yeah, likely. I'll have a look.
[Bug fortran/88447] Non-contiguous array argument of some class not passed properly to subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88447 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-11 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Confirmed from 6.4 up to trunk (9.0). With 5.5.0 I get at run time At line 24 of file pr88447_1.f90 (unit = 6, file = 'stdout') Fortran runtime error: '*' requires at least one associated data descriptor (a,*(3f12.3," |")) ^
[Bug fortran/88438] [F08] A pointer function reference can denote a variable in any variable definition context.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88438 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-11 Summary|A pointer function |[F08] A pointer function |reference can denote a |reference can denote a |variable in any variable|variable in any variable |definition context. |definition context. Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- At https://gcc.gnu.org/wiki/Fortran2008Status I see Unimplemented features -- based on the list in the "Introduction" of the F2008 standard ... A pointer function reference can denote a variable in any variable definition context. ...
[Bug target/88134] ICE in create_component_ref_by_pieces_1, at tree-ssa-pre.c:2520
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134 --- Comment #10 from Arseny Solokha --- Could your r266973 fix a root cause of this issue?
[Bug c++/88445] noexcept(expr) should return true with -fno-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88445 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Richard Biener --- We certainly cannot break the ABI with -fno-exceptions.
[Bug lto/86004] [9 regression] Several lto test cases begin failing with r260963
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86004 --- Comment #13 from Jakub Jelinek --- Author: jakub Date: Tue Dec 11 10:28:39 2018 New Revision: 266974 URL: https://gcc.gnu.org/viewcvs?rev=266974=gcc=rev Log: PR lto/86004 * doc/sourcebuild.texi (lto_incremental): Document new effective target. * lib/target-supports.exp (check_effective_target_lto_incremental): New. * g++.dg/lto/pr69137_0.C: Require lto_incremental effective target. * g++.dg/lto/pr65316_0.C: Likewise. * g++.dg/lto/pr85176_0.C: Likewise. * g++.dg/lto/pr79000_0.C: Likewise. * g++.dg/lto/pr66180_0.C: Likewise. * g++.dg/lto/pr65193_0.C: Likewise. * g++.dg/lto/pr69077_0.C: Likewise. * g++.dg/lto/pr68057_0.C: Likewise. * g++.dg/lto/pr66705_0.C: Likewise. * g++.dg/lto/pr65302_0.C: Likewise. * g++.dg/lto/20091002-1_0.C: Likewise. * g++.dg/lto/pr81940_0.C: Likewise. * g++.dg/lto/pr64043_0.C: Likewise. * g++.dg/lto/pr65549_0.C: Likewise. * g++.dg/lto/pr69133_0.C: Likewise. * gfortran.dg/lto/pr79108_0.f90: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/sourcebuild.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/lto/20091002-1_0.C trunk/gcc/testsuite/g++.dg/lto/pr64043_0.C trunk/gcc/testsuite/g++.dg/lto/pr65193_0.C trunk/gcc/testsuite/g++.dg/lto/pr65302_0.C trunk/gcc/testsuite/g++.dg/lto/pr65316_0.C trunk/gcc/testsuite/g++.dg/lto/pr65549_0.C trunk/gcc/testsuite/g++.dg/lto/pr66180_0.C trunk/gcc/testsuite/g++.dg/lto/pr66705_0.C trunk/gcc/testsuite/g++.dg/lto/pr68057_0.C trunk/gcc/testsuite/g++.dg/lto/pr69077_0.C trunk/gcc/testsuite/g++.dg/lto/pr69133_0.C trunk/gcc/testsuite/g++.dg/lto/pr69137_0.C trunk/gcc/testsuite/g++.dg/lto/pr79000_0.C trunk/gcc/testsuite/g++.dg/lto/pr81940_0.C trunk/gcc/testsuite/g++.dg/lto/pr85176_0.C trunk/gcc/testsuite/gfortran.dg/lto/pr79108_0.f90 trunk/gcc/testsuite/lib/target-supports.exp
[Bug target/88134] ICE in create_component_ref_by_pieces_1, at tree-ssa-pre.c:2520
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134 --- Comment #9 from Segher Boessenkool --- I cannot get that to fail either, with a trunk compiler :-/
[Bug target/88134] ICE in create_component_ref_by_pieces_1, at tree-ssa-pre.c:2520
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134 --- Comment #11 from Segher Boessenkool --- AT12.0 however, like on godbolt, does in fact crash.
[Bug tree-optimization/88444] [9 Regression] ICE: tree check: expected ssa_name, have integer_cst in live_on_edge, at tree-vrp.c:468; or ICE: tree check: expected ssa_name, have integer_cst in get_val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88444 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- _22 = (long int) 0; IMHO this is a bug, when IPA-CP propagates things we should fold the stmt. This is probably done by the inliner remapping a SSA name to a constant? It might be difficult to avoid folding all stmts but maybe we can detect when we replace sth by a constant and mark the stmt for folding then. Having _22 = 0; is OK.
[Bug d/88431] link errors on build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88431 --- Comment #1 from David Binderman --- This config line works fine: ../trunk/configure --prefix=/home/dcb/gcc/results.266950 \ --disable-multilib \ --disable-werror \ --enable-checking=df,extra,fold,rtl,yes \ --enable-languages=d so it looks like using -O3 in the top level Makefile causes trouble.
[Bug middle-end/88448] [9 regression] gnat.dg/opt66.adb etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88448 Rainer Orth changed: What|Removed |Added Target Milestone|--- |9.0
[Bug middle-end/88448] New: [9 regression] gnat.dg/opt66.adb etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88448 Bug ID: 88448 Summary: [9 regression] gnat.dg/opt66.adb etc. FAIL Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Target Milestone: --- Target: sparc-sun-solaris2.11, i386-pc-solaris2.11 Between 20181209 (r266930) and 20181210 (r266959), three Ada tests regressed: +FAIL: cb4009a cb4009a.adb: In function 'CB4009A.P2': cb4009a.adb:114:5: error: BB 16 can not throw but has an EH edge +===GNAT BUG DETECTED==+ | 9.0.0 20181210 (experimental) [trunk revision 266959] (i386-pc-solaris2.11) GCC error:| | verify_flow_info failed | | Error detected around cb4009a.adb:114:5 [...] raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:407 gnatmake: "cb4009a.adb" compilation error +FAIL: gnat.dg/opt66.adb (test for excess errors) +FAIL: gnat.dg/opt66.adb 3 blank line(s) in output /vol/gcc/src/hg/trunk/local/gcc/testsuite/gnat.dg/opt66.adb: In function 'Opt66': /vol/gcc/src/hg/trunk/local/gcc/testsuite/gnat.dg/opt66.adb:13:4: error: BB 12 can not throw but has an EH edge +===GNAT BUG DETECTED==+ | 9.0.0 20181210 (experimental) [trunk revision 266959] (i386-pc-solaris2.11) GCC error:| | verify_flow_info failed | | Error detected around /vol/gcc/src/hg/trunk/local/gcc/testsuite/gnat.dg/opt66.adb:13:4| [...] raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:407 gnatmake: "/vol/gcc/src/hg/trunk/local/gcc/testsuite/gnat.dg/opt66.adb" compilation error This might be from 2018-12-10 Richard Biener PR middle-end/88415 * gimple.c (gimple_assign_set_rhs_with_ops): Transfer EH info to a newly allocated stmt. * gcc.dg/gomp/pr88415.c: New testcase.
[Bug rtl-optimization/83377] Missed optimization (x86): Bit operations should be converted to arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83377 --- Comment #3 from Vinay Kumar --- The below mentioned pattern match in match.pd generates the assembly code similar to subtraction. == diff --git a/gcc/match.pd b/gcc/match.pd index fbb4d6f..3cde6a6 100644 --- a/gcc/match.pd +++ b/gcc/match.pd @@ -925,6 +925,11 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) (bit_and @0 integer_all_onesp) (non_lvalue @0)) +/*Fold (x & ~CST) into (x - CST)*/ +(simplify(bit_and:c @0 INTEGER_CST@1) +(if ((INTEGRAL_TYPE_P (type) || VECTOR_INTEGER_TYPE_P (type))) + (minus @0 (negate @1 + /* x & x -> x, x | x -> x */ (for bitop (bit_and bit_ior) (simplify == Assembly generated is as follows: == test.o: file format elf64-x86-64 Disassembly of section .text: : 0: 48 83 ff fe cmp$0xfffe,%rdi 4: 74 04 je a 6: 48 8b 7f fd mov-0x3(%rdi),%rdi a: e9 00 00 00 00jmpq f f: 90nop 0010 : 10: 48 83 ff fe cmp$0xfffe,%rdi 14: 74 04 je 1a 16: 48 8b 7f fe mov-0x2(%rdi),%rdi 1a: e9 00 00 00 00jmpq 1f ==
[Bug target/88134] ICE in create_component_ref_by_pieces_1, at tree-ssa-pre.c:2520
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134 --- Comment #8 from Arseny Solokha --- Aha. Segher, you've helpfully reminded me about -msoft-float w/ your recent commit. So it's not (solely) my misconfiguration once again: https://gcc.godbolt.org/z/sshcIF (it's g++, because gcc for powerpc seems to be broken there; -O1 -ftree-pre instead of -O2, because it's the pass that actually fails; and 1.0 instead of __builtin_huge_val (), because value the second operand doesn't really seem to matter).
[Bug target/88134] ICE in create_component_ref_by_pieces_1, at tree-ssa-pre.c:2520
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134 --- Comment #12 from rguenther at suse dot de --- On Tue, 11 Dec 2018, asolokha at gmx dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134 > > --- Comment #10 from Arseny Solokha --- > Could your r266973 fix a root cause of this issue? Unlikely. I don't see how this assert can fire...
[Bug libstdc++/88204] New test case 26_numerics/complex/operators/more_constexpr.cc from r266416 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88204 Iain Sandoe changed: What|Removed |Added Target|powerpc64*-*-* |powerpc64*-*-*,powerpc-*-ai ||x,powerpc*-*-darwin9 Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-11 CC||iains at gcc dot gnu.org Depends on||27964, 19779 Ever confirmed|0 |1 --- Comment #1 from Iain Sandoe --- also on AIX and Darwin this looks to be the long-standing problem of no constant folding for IBM long doubles on powerpc platforms that use them. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19779 [Bug 19779] IBM 128bit long double format is not constant folded. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27964 [Bug 27964] Wrong line ends on windows (XP)
[Bug target/88134] ICE in create_component_ref_by_pieces_1, at tree-ssa-pre.c:2520
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134 --- Comment #13 from Arseny Solokha --- In decl_address_invariant_p() we hit this break: 3423 case VAR_DECL: 3424 if ((TREE_STATIC (op) || DECL_EXTERNAL (op)) 3425 || DECL_THREAD_LOCAL_P (op) 3426 || DECL_CONTEXT (op) == current_function_decl 3427 || decl_function_context (op) == current_function_decl) 3428 return true; 3429 break; and return false, which in the end becomes what is_gimple_min_invariant() returns. I can provide relevant dumps or gdb session printouts if so desired. At first glance I didn't notice anything glaringly wrong there, but admittedly I have no idea what to look at.
[Bug tree-optimization/88459] New: vectorization failure for a simple sum reduction loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88459
Bug ID: 88459
Summary: vectorization failure for a simple sum reduction loop
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jiangning.liu at amperecomputing dot com
Target Milestone: ---
For the simple loop below, gcc -O3 fails to vectorize it.
unsigned int tmp[1024];
unsigned int test_vec(int n)
{
int sum = 0;
for(int i = 0; i < 1024; i++)
{
sum += tmp[i];
}
return sum;
}
The kernel loop is,
.L2:
ldr w2, [x1], 4
add w0, w0, w2
cmp x3, x1
bne .L2
But if we change the data type of sum from "int" to "unsigned int" as below,
unsigned int tmp[1024];
unsigned int test_vec(int n)
{
unsigned int sum = 0;
for(int i = 0; i < 1024; i++)
{
sum += tmp[i];
}
return sum;
}
gcc can vectorize it, and the kernel loop is like,
.L2:
ldr q1, [x0], 16
add v0.4s, v0.4s, v1.4s
cmp x1, x0
bne .L2
[Bug bootstrap/88450] ICE in stage 2 compiler while configuring libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88450 --- Comment #1 from Bence Szabó --- Correction: 9-21081118 works after patching with "PR bootstrap/88106" (r266309)
[Bug middle-end/86979] [9 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2348 with -m32 on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86979 Andrey Belevantsev changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |abel at gcc dot gnu.org --- Comment #7 from Andrey Belevantsev --- Looks like mine.
[Bug c++/88458] New: Conditional expression where the second and third operand are int and nullptr treated as ill-formed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88458 Bug ID: 88458 Summary: Conditional expression where the second and third operand are int and nullptr treated as ill-formed Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: yaghmour.shafik at gmail dot com Target Milestone: --- Given the following code char* ch4 = true ? 0 : nullptr; and compiling with the following flags: -std=c++17 gcc produces the following diagnostic: error: operands to ?: have different types 'int' and 'std::nullptr_t' 4 | char* ch4 = true ? 0 : nullptr; | ~^ Both clang and MSVC accepts this code w/o diagnostic, see godbolt: https://godbolt.org/z/BraaEu I believe according to http://eel.is/c++draft/expr.cond#7.5 this is well-formed.
[Bug tree-optimization/88440] size optimization of memcpy-like code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88440 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-11 CC||mliska at suse dot cz, ||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- I think distributing patterns is reasonable for -O[2s]. I think we kept it at -O3 because of compile-time concerns (dependence analysis is quadratic). But then we still don't do basic vectorization at -O[2s] either... (same compile-time for not too much gain issue). So if somebody is willing to do some compile-time / effect numbers (bootstrap / SPEC?) then we can consider enabling loop-distribute-patterns for -O[2s] for GCC 10.
[Bug c++/88445] New: noexcept(expr) should return true with -fno-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88445
Bug ID: 88445
Summary: noexcept(expr) should return true with -fno-exceptions
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
Consider the following example:
#include
struct test {
test();
test(test&&);
test& operator=(test&&);
};
void test_func() {
static_assert(noexcept(test{test()}), "");
static_assert(std::is_nothrow_move_constructible::value, "");
static_assert(std::is_nothrow_move_assignable::value, "");
}
The static assertions fail with the -fno-exceptions flag however no exception
could happen because all the exceptions are disabled.
Please adjust the noexcept(expr) logic for the -fno-exceptions flag.
Such adjustment is essential because the standard library heavily relies on the
type traits and chooses the suboptimal algorithms in -fno-exceptions
environments.
[Bug tree-optimization/88444] [9 Regression] ICE: tree check: expected ssa_name, have integer_cst in live_on_edge, at tree-vrp.c:468; or ICE: tree check: expected ssa_name, have integer_cst in get_val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88444
--- Comment #2 from Jakub Jelinek ---
We end up with non-folded statement
_22 = (long int) 0;
because of all the disabled and enabled optimizations (IPA-VRP propagated
constant not cleaned up).
I think:
--- gcc/tree-vrp.c.jj 2018-12-07 00:27:25.419941079 +0100
+++ gcc/tree-vrp.c 2018-12-11 09:25:58.731750953 +0100
@@ -2894,6 +2894,7 @@ register_edge_assert_for_2 (tree name, e
{
name2 = gimple_assign_rhs1 (def_stmt);
if (CONVERT_EXPR_CODE_P (rhs_code)
+ && TREE_CODE (name2) == SSA_NAME
&& INTEGRAL_TYPE_P (TREE_TYPE (name2))
&& TYPE_UNSIGNED (TREE_TYPE (name2))
&& prec == TYPE_PRECISION (TREE_TYPE (name2))
@@ -2990,6 +2991,7 @@ register_edge_assert_for_2 (tree name, e
wide_int rmin, rmax;
tree rhs1 = gimple_assign_rhs1 (def_stmt);
if (INTEGRAL_TYPE_P (TREE_TYPE (rhs1))
+ && TREE_CODE (rhs1) == SSA_NAME
/* Make sure the relation preserves the upper/lower boundary of
the range conservatively. */
&& (comp_code == NE_EXPR
@@ -3054,6 +3056,7 @@ register_edge_assert_for_2 (tree name, e
{
names[1] = gimple_assign_rhs1 (def_stmt2);
if (!CONVERT_EXPR_CODE_P (gimple_assign_rhs_code (def_stmt2))
+ || TREE_CODE (names[1]) != SSA_NAME
|| !INTEGRAL_TYPE_P (TREE_TYPE (names[1]))
|| (TYPE_PRECISION (TREE_TYPE (name2))
!= TYPE_PRECISION (TREE_TYPE (names[1]
@@ -3323,6 +3326,7 @@ register_edge_assert_for_1 (tree op, enu
conversion or conversion from non-integral type. */
tree rhs = gimple_assign_rhs1 (op_def);
if (INTEGRAL_TYPE_P (TREE_TYPE (rhs))
+ && TREE_CODE (rhs) == SSA_NAME
&& (TYPE_PRECISION (TREE_TYPE (rhs))
<= TYPE_PRECISION (TREE_TYPE (op
register_edge_assert_for_1 (rhs, code, e, asserts);
should fix this.
[Bug target/88145] ICE: unrecognizable insn (mffs) targeting 32-bit BE FPU-less powerpc CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88145 --- Comment #1 from Segher Boessenkool --- Author: segher Date: Tue Dec 11 08:30:36 2018 New Revision: 266973 URL: https://gcc.gnu.org/viewcvs?rev=266973=gcc=rev Log: rs6000: Don't use rs6000_isa_flags_explicit for soft float tests (PR88145) ...specifically, those for builtins. Soft float can be enabled implicitly, too (for certain CPUs for example). We should use rs6000_isa_flags instead, to decide whether to expand a builtin or to bail out with an error instead. PR target/88145 * config/rs6000/rs6000.c (rs6000_expand_zeroop_builtin): Use rs6000_isa_flags instead of rs6000_isa_flags_explicit to decide whether soft float is enabled. (rs6000_expand_mtfsb_builtin): Ditto. (rs6000_expand_set_fpscr_rn_builtin): Ditto. (rs6000_expand_set_fpscr_drn_builtin): Ditto. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c
[Bug c++/88446] New: __builtin_is_constant_evaluated rejects some converted constant expressions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88446 Bug ID: 88446 Summary: __builtin_is_constant_evaluated rejects some converted constant expressions. Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: eric at efcs dot ca Target Milestone: --- __builtin_is_constant_evaluated() is not a constant expression when used in array bounds or new expressions. // g++ -fsyntax-only -std=c++2a char CA[__builtin_is_constant_evaluated()]; // rejects-valid auto CP = new char[3][__builtin_is_constant_evaluated()]; // rejects-valid
[Bug ipa/87957] [9 Regression] ICE tree check: expected tree that contains ‘decl minimal’ structure, have ‘identifier_node’ in warn_odr, at ipa-devirt.c:1051 since r265519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87957 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #16 from Eric Botcazou --- > (gdb) pt > warning: Expression is not an assignment (and might have no effect) > system__tasking__protected_objects__operations__communication_block > sizes-gimplified volatile visited type_2 BLK The problem is here ^^^ I think, i.e. we have a volatile variant. The problem may come from the Ada front-end, but it would be nice to have Jan's viewpoint.
[Bug ipa/87957] [9 Regression] ICE tree check: expected tree that contains ‘decl minimal’ structure, have ‘identifier_node’ in warn_odr, at ipa-devirt.c:1051 since r265519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87957 --- Comment #17 from Eric Botcazou --- > The problem is here ^^^ I think, i.e. we have a volatile variant. The > problem may come from the Ada front-end, but it would be nice to have Jan's > viewpoint. It comes from libgnarl/s-tpobop.ads: type Communication_Block is record Self : Task_Id; Enqueued : Boolean := True; Cancelled : Boolean := False; end record; pragma Volatile (Communication_Block); i.e. the declared type is volatile (but of course the main variant is not).
[Bug target/88134] ICE in create_component_ref_by_pieces_1, at tree-ssa-pre.c:2520
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88134 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #7 from Segher Boessenkool --- I cannot reproduce it either, not with any version of powerpc-linux-gcc.
[Bug rtl-optimization/88433] wrong code for printf after a pointer cast from a pointer to an adjacent object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88433
Richard Biener changed:
What|Removed |Added
Keywords||alias
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-12-11
Component|target |rtl-optimization
Depends on||49330
Ever confirmed|0 |1
--- Comment #2 from Richard Biener ---
I think this is a dup of the bug pointing to RTL alias analysis which cannot
properly distinguish between pointers and integers when following to base
terms.
We expand from
[local count: 1073741825]:
ix_5 = (long int)
ix_6 = ix_5 + 4;
ix.1_1 = (int *) ix_6;
p = ix.1_1;
q =
_14 = MEM[(char * {ref-all})];
_15 = MEM[(char * {ref-all})];
if (_14 == _15)
goto ; [33.00%]
else
goto ; [67.00%]
[local count: 354334802]:
*ix.1_1 = 11;
y.4_3 = y;
__builtin_printf ("%i", y.4_3); [tail call]
where RTL has plenty opportunity to track down ix.1_1 to + 4 which
makes it non-aliasing to y.
Note we are saved for f just beacuse of optimization propagating a
conditional equivalence p_5 ==
Dup of PR49330.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49330
[Bug 49330] Integer arithmetic on addresses optimised with pointer arithmetic
rules
[Bug fortran/88447] Non-contiguous array argument of some class not passed properly to subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88447 --- Comment #1 from martin --- Here is a smaller reproducer. The component "integer :: i" in type t is necessary to reproduce the bug. module mod implicit none private public qv type, public :: s real, dimension(1:3) :: vec end type s type, public :: t integer :: i type(s) :: v end type t contains subroutine qv(x) class(s), dimension(:), intent(in) :: x integer :: i write(*,'(a,*(3f12.3," |"))') 'x = ', (x(i)%vec, i=1,ubound(x,1)) end subroutine qv end module mod program noncontiguous use mod implicit none integer :: k type(t), dimension(1:2) :: a do k = 1,2 a(k)%i = k a(k)%v%vec = [real(k)+1.0, real(k)+2.0, real(k)+3.0] end do call qv(a%v) end program noncontiguous
[Bug c++/88445] noexcept(expr) should return true with -fno-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88445 --- Comment #1 from Antony Polukhin --- Hm... This was discussed in Clang and looks like such optimization could break ABI and cause ODR violations https://bugs.llvm.org/show_bug.cgi?id=27442#c4 If nothing changed since then, I'm OK with closin this issue as Invalid or Won't Fix.
[Bug testsuite/88436] [9 regression] r265421 causes gcc.target/powerpc/pr54240.c to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88436 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0 --- Comment #1 from Richard Biener --- Yeah, can you simply change to dump/scan phiopt2 please?
[Bug c++/88446] __builtin_is_constant_evaluated rejects some converted constant expressions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88446 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-12-11 CC||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- And as Eric mentioned, static_assert (__builtin_is_constant_evaluated ()); should not fail either. I guess the array bounds including new are because GCC as an extension supports VLAs (though sure, outside of function contexts we reject them anyway). Jason, do you think we should handle these bounds with pretend_const_required true to cxx_eval_outermost_constant_expr, like e.g. maybe_constant_init_1 with pretend_const_required does?
[Bug fortran/88447] New: Non-contiguous array argument of some class not passed properly to subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88447 Bug ID: 88447 Summary: Non-contiguous array argument of some class not passed properly to subroutine Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mscfd at gmx dot net Target Milestone: --- Using a non-contiguous argument to a subroutine whose declaration is "class(s), dimension(:)" gives wrong results. The output looks like that some internal offset in the array descriptor is computed wrongly. Using type(s) instead of class(s) fixes the problem. The bug also occurs with the class(*) variant. module mod implicit none private public p, qi, qr, qv type, public :: s real, dimension(1:3) :: vec end type s type, public :: t integer :: i type(s) :: v real :: r end type t contains subroutine p(x) class(*), dimension(:), intent(in) :: x integer :: i select type (x) type is (integer) write(*,'(a,*(i12))') 'x = ', x type is (real) write(*,'(a,*(f12.3))') 'x = ', x type is (s) write(*,'(a,*(3f12.3," |"))') 'x = ', (x(i)%vec, i=1,ubound(x,1)) end select end subroutine p subroutine qi(x) integer, dimension(:), intent(in) :: x write(*,'(a,*(i12))') 'x = ', x end subroutine qi subroutine qr(x) real, dimension(:), intent(in) :: x write(*,'(a,*(f12.3))') 'x = ', x end subroutine qr subroutine qv(x) ! with type(s) the bug does not occur !type(s), dimension(:), intent(in) :: x class(s), dimension(:), intent(in) :: x integer :: i write(*,'(a,*(3f12.3," |"))') 'x = ', (x(i)%vec, i=1,ubound(x,1)) end subroutine qv end module mod program noncontiguous use mod implicit none integer :: k type(t), dimension(1:4) :: a do k = 1,4 a(k)%i = k a(k)%r = 10.0 * 2.0*real(k) a(k)%v%vec = [real(k)-2.0, real(k)-3.0, real(k)-5.0] end do ! wrong output for all three calls call p(a%i) call p(a%r) call p(a%v) ! correct output for the first and second call, ! wrong output for third call (correct if type(s) instead of class(s) is used) call qi(a%i) call qr(a%r) call qv(a%v) end program noncontiguous
[Bug c++/88434] operator< should take precedence over template argument in basic.lookup.classref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88434 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- Since the CWG issue is still "drafting", should we be making any changes at this time?
