[Bug lto/79042] LTO doesn't propagate node->dynamically_initialized bit for varpool nodes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79042 Maxim Ostapenko changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Maxim Ostapenko --- Fixed.
[Bug bootstrap/79068] New: [7 Regression] Bootstrap failure on powerpc64-linux and armv7hl-linux-gnueabi in libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79068 Bug ID: 79068 Summary: [7 Regression] Bootstrap failure on powerpc64-linux and armv7hl-linux-gnueabi in libgo Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org Target Milestone: --- My bootstrap on these two architectures fail with: go1: internal compiler error: in write_specific_type_functions, at go/gofrontend/types.cc:1993 0x102cd6e7 Type::write_specific_type_functions(Gogo*, Named_type*, long, std::__cxx11::basic_string, std::allocator > const&, Function_type*, std::__cxx11::basic_string, std::allocator > const&, Function_type*) ../../gcc/go/gofrontend/types.cc:1993 0x102cdbcf Type::specific_type_functions(Gogo*, Named_type*, long, Function_type*, Function_type*, Named_object**, Named_object**) ../../gcc/go/gofrontend/types.cc:1971 0x102cc0ff Type::type_functions(Gogo*, Named_type*, Function_type*, Function_type*, Named_object**, Named_object**) ../../gcc/go/gofrontend/types.cc:1753 0x102d0d67 Type::type_descriptor_constructor(Gogo*, int, Named_type*, Methods const*, bool) ../../gcc/go/gofrontend/types.cc:2308 0x102d2b37 Array_type::array_type_descriptor(Gogo*, Named_type*) ../../gcc/go/gofrontend/types.cc:6932 0x102c2a03 Type::make_type_descriptor_var(Gogo*) ../../gcc/go/gofrontend/types.cc:1237 0x102c2f4b Type::type_descriptor_pointer(Gogo*, Location) ../../gcc/go/gofrontend/types.cc:1172 0x1022353b Type_descriptor_expression::do_get_backend(Translate_context*) ../../gcc/go/gofrontend/expressions.cc:14344 0x101f3e27 Expression::get_backend(Translate_context*) ../../gcc/go/gofrontend/expressions.cc:402 0x1021a04b Struct_construction_expression::do_get_backend(Translate_context*) ../../gcc/go/gofrontend/expressions.cc:12572 0x101f3e27 Expression::get_backend(Translate_context*) ../../gcc/go/gofrontend/expressions.cc:402 0x1021b1fb Array_construction_expression::get_constructor(Translate_context*, Btype*) ../../gcc/go/gofrontend/expressions.cc:12795 0x101f3e27 Expression::get_backend(Translate_context*) ../../gcc/go/gofrontend/expressions.cc:402 0x102160c7 Unary_expression::do_get_backend(Translate_context*) ../../gcc/go/gofrontend/expressions.cc:4249 0x101f3e27 Expression::get_backend(Translate_context*) ../../gcc/go/gofrontend/expressions.cc:402 0x101f54d3 Slice_value_expression::do_get_backend(Translate_context*) ../../gcc/go/gofrontend/expressions.cc:14729 0x101f3e27 Expression::get_backend(Translate_context*) ../../gcc/go/gofrontend/expressions.cc:402 0x101f3e27 Expression::get_backend(Translate_context*) ../../gcc/go/gofrontend/expressions.cc:402 0x1021a04b Struct_construction_expression::do_get_backend(Translate_context*) ../../gcc/go/gofrontend/expressions.cc:12572 0x101f3e27 Expression::get_backend(Translate_context*) ../../gcc/go/gofrontend/expressions.cc:402 On powerpc64-linux this is while building 32-bit libgo multilib. The command line has been: /builddir/build/BUILD/gcc-7.0.0-20170111/obj-ppc64-redhat-linux/./gcc/gccgo -B/builddir/build/BUILD/gcc-7.0.0-20170111/obj-ppc64-redhat-linux/./gcc/ -B/usr/ppc64-redhat-linux/bin/ -B/usr/ppc64-redhat-linux/lib/ -isystem /usr/ppc64-redhat-linux/include -isystem /usr/ppc64-redhat-linux/sys-include -O2 -g -m32 -I . -c -fgo-pkgpath=debug/dwarf ../../../../libgo/go/debug/dwarf/buf.go ../../../../libgo/go/debug/dwarf/class_string.go ../../../../libgo/go/debug/dwarf/const.go ../../../../libgo/go/debug/dwarf/entry.go ../../../../libgo/go/debug/dwarf/line.go ../../../../libgo/go/debug/dwarf/open.go ../../../../libgo/go/debug/dwarf/type.go ../../../../libgo/go/debug/dwarf/typeunit.go ../../../../libgo/go/debug/dwarf/unit.go -fPIC -o debug/.libs/dwarf.o On armv7hl-linux the ICE is while building the same package, /builddir/build/BUILD/gcc-7.0.0-20170111/obj-armv7hl-redhat-linux-gnueabi/./gcc/gccgo -B/builddir/build/BUILD/gcc-7.0.0-20170111/obj-armv7hl-redhat-linux-gnueabi/./gcc/ -B/usr/armv7hl-redhat-linux-gnueabi/bin/ -B/usr/armv7hl-redhat-linux-gnueabi/lib/ -isystem /usr/armv7hl-redhat-linux-gnueabi/include -isystem /usr/armv7hl-redhat-linux-gnueabi/sys-include -O2 -g -I . -c -fgo-pkgpath=debug/dwarf ../../../libgo/go/debug/dwarf/buf.go ../../../libgo/go/debug/dwarf/class_string.go ../../../libgo/go/debug/dwarf/const.go ../../../libgo/go/debug/dwarf/entry.go ../../../libgo/go/debug/dwarf/line.go ../../../libgo/go/debug/dwarf/open.go ../../../libgo/go/debug/dwarf/type.go ../../../libgo/go/debug/dwarf/typeunit.go ../../../libgo/go/debug/dwarf/unit.go -fPIC -o debug/.libs/dwarf.o
[Bug bootstrap/79068] [7 Regression] Bootstrap failure on powerpc64-linux and armv7hl-linux-gnueabi in libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79068 Jakub Jelinek changed: What|Removed |Added CC||ian at gcc dot gnu.org Target Milestone|--- |7.0
[Bug bootstrap/79068] [7 Regression] Bootstrap failure on powerpc64-linux and armv7hl-linux-gnueabi in libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79068 --- Comment #1 from Jakub Jelinek --- It happens both with profiledbootstrap and bootstrap.
[Bug bootstrap/79069] New: [7 Regression] Bootstrap failure on s390x-linux while building libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79069
Bug ID: 79069
Summary: [7 Regression] Bootstrap failure on s390x-linux while
building libgo
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
The s390x-linux bootstrap fails for me (profiledbootstrap as well as bootstrap)
while building 31-bit libgo:
/builddir/build/BUILD/gcc-7.0.0-20170111/obj-s390x-redhat-linux/./gcc/gccgo
-B/builddir/build/BUILD/gcc-7.0.0-20170111/obj-s390x-redhat-linux/./gcc/
-B/usr/s390x-redhat-linux/bin/ -B/usr/s390x-redhat-linux/lib/ -isystem
/usr/s390x-redhat-linux/include -isystem /usr/s390x-redhat-linux/sys-include
-O2 -g -m31 -I . -c -fgo-pkgpath=runtime -fgo-c-header=runtime.inc.tmp
-fgo-compiling-runtime ../../../../libgo/go/runtime/alg.go
../../../../libgo/go/runtime/cgo_gccgo.go ../../../../libgo/go/runtime/chan.go
../../../../libgo/go/runtime/compiler.go
../../../../libgo/go/runtime/cpuprof.go
../../../../libgo/go/runtime/cputicks.go ../../../../libgo/go/runtime/debug.go
../../../../libgo/go/runtime/env_posix.go ../../../../libgo/go/runtime/error.go
../../../../libgo/go/runtime/extern.go ../../../../libgo/go/runtime/ffi.go
../../../../libgo/go/runtime/hash32.go ../../../../libgo/go/runtime/hashmap.go
../../../../libgo/go/runtime/hashmap_fast.go
../../../../libgo/go/runtime/iface.go ../../../../libgo/go/runtime/lfstack.go
../../../../libgo/go/runtime/lfstack_32bit.go
../../../../libgo/go/runtime/lock_futex.go
../../../../libgo/go/runtime/mcache.go ../../../../libgo/go/runtime/mprof.go
../../../../libgo/go/runtime/msan0.go ../../../../libgo/go/runtime/mstats.go
../../../../libgo/go/runtime/netpoll.go
../../../../libgo/go/runtime/netpoll_epoll.go
../../../../libgo/go/runtime/os_gccgo.go
../../../../libgo/go/runtime/os_linux.go ../../../../libgo/go/runtime/panic.go
../../../../libgo/go/runtime/print.go ../../../../libgo/go/runtime/proc.go
../../../../libgo/go/runtime/race0.go ../../../../libgo/go/runtime/rdebug.go
../../../../libgo/go/runtime/rune.go ../../../../libgo/go/runtime/runtime.go
../../../../libgo/go/runtime/runtime1.go
../../../../libgo/go/runtime/runtime2.go ../../../../libgo/go/runtime/select.go
../../../../libgo/go/runtime/sema.go
../../../../libgo/go/runtime/signal1_unix.go
../../../../libgo/go/runtime/signal2_unix.go
../../../../libgo/go/runtime/signal_gccgo.go
../../../../libgo/go/runtime/signal_sighandler.go
../../../../libgo/go/runtime/signal_sigtramp.go
../../../../libgo/go/runtime/signal_unix.go
../../../../libgo/go/runtime/sigpanic_unix.go
../../../../libgo/go/runtime/sigqueue.go ../../../../libgo/go/runtime/slice.go
../../../../libgo/go/runtime/string.go ../../../../libgo/go/runtime/stubs.go
../../../../libgo/go/runtime/stubs2.go ../../../../libgo/go/runtime/symtab.go
../../../../libgo/go/runtime/time.go ../../../../libgo/go/runtime/trace.go
../../../../libgo/go/runtime/traceback_gccgo.go
../../../../libgo/go/runtime/type.go ../../../../libgo/go/runtime/typekind.go
../../../../libgo/go/runtime/unaligned1.go
../../../../libgo/go/runtime/write_err.go runtime_sysinfo.go sigtab.go -fPIC
-o .libs/runtime.o
fails with:
../../../../libgo/go/runtime/trace.go: In function
'runtime.dump.pN23_runtime.traceStackTable':
../../../../libgo/go/runtime/trace.go:731:1: internal compiler error: in
fixup_reorder_chain, at cfgrtl.c:3840
func (tab *traceStackTable) dump() {
^
0x802f64e9 fixup_reorder_chain
../../gcc/cfgrtl.c:3840
0x802f64e9 cfg_layout_finalize()
../../gcc/cfgrtl.c:4306
0x80aebf23 execute
../../gcc/bb-reorder.c:2576
[Bug bootstrap/79069] [7 Regression] Bootstrap failure on s390x-linux while building libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79069 Jakub Jelinek changed: What|Removed |Added CC||ian at gcc dot gnu.org, ||krebbel at gcc dot gnu.org, ||vogt at linux dot vnet.ibm.com Target Milestone|--- |7.0
[Bug testsuite/79067] gcc.dg/tree-prof/cold_partition_label.c runs a million times longer than it used to and times out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79067 Richard Biener changed: What|Removed |Added CC||andi-gcc at firstfloor dot org --- Comment #1 from Richard Biener --- Maybe just _not_ run autofdo on all tree-prof testcases... (I see those randomly failing as well, very annoying).
[Bug target/79066] [7 Regression] non-PIC code generated for powerpc glibc with -fpic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79066 Richard Biener changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |7.0
[Bug target/79065] ARM generates ldm/stm on packed structs with aligned members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79065 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Richard Biener --- Yep, packed with aligned members doesn't work as you expect.
[Bug lto/79061] [7 Regression][LTO][ASAN] LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79061 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.0 --- Comment #2 from Richard Biener --- Is this after the fix for PR79042?
[Bug lto/79062] -Wformat-length warnings disabled by -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79062
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-01-12
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
Confirmed.
info.fmtstr = get_format_string (info.format, &info.fmtloc);
if (!info.fmtstr)
return;
fails for info.format == "%lx":
(gdb) p debug_tree (info.format)
SI
size
unit size
align 8 symtab 0 alias set -1 structural equality domain
pointer_to_this >
unsigned DI
size
unit size
align 64 symtab 0 alias set -1 structural equality>
readonly constant
arg 0
readonly constant static "%lx\000">
t2.c:7:25 start: t2.c:7:25 finish: t2.c:7:25>
it runs into
if (TYPE_MAIN_VARIANT (TREE_TYPE (TREE_TYPE (format))) != char_type_node)
{
/* Wide format string. */
return NULL;
}
other code (in fold-const.c) simply checks for
&& (GET_MODE_CLASS (TYPE_MODE (TREE_TYPE (TREE_TYPE (string
== MODE_INT)
&& (GET_MODE_SIZE (TYPE_MODE (TREE_TYPE (TREE_TYPE (string == 1)
char_type_node is _not_ "merged" with LTO as we allow combining
-f[un]singed-char units and have
for (i = 0; i < itk_none; i++)
/* Skip itk_char. char_type_node is dependent on -f[un]signed-char. */
if (i != itk_char)
record_common_node (cache, integer_types[i]);
you could also look at hwat tree-ssa-strlen.c does (TYPE_MODE (type) ==
TYPE_MODE (char_type_node), etc.)
[Bug lto/79061] [7 Regression][LTO][ASAN] LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79061 --- Comment #3 from Tobias Burnus --- (In reply to Richard Biener from comment #2) > Is this after the fix for PR79042? I am nearly certain that it was after that fix. Before, I got an UBSAN overflow but only when combining OpenMP, LTO, -fipa-cp-clone and UBSAN, which I had hoped PR78365 and PR78599 would fix. (It didn't.) Shortly after, I saw the commit for PR79042, tried whether it made a difference - and ended up with this bug. [Sorry for not narrowing the regression range in the initial report. (I somehow failed to realize that this ASAN message comes way before the UBSAN error can be triggered.)]
[Bug bootstrap/79068] [7 Regression] Bootstrap failure on powerpc64-linux and armv7hl-linux-gnueabi in libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79068 --- Comment #2 from Jakub Jelinek --- Reproduced on gcc110.fsffrance.org vanilla r244305 and ../configure --enable-bootstrap --enable-languages=c,c++,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --disable-libmpx --enable-gnu-indirect-function --enable-secureplt --with-long-double-128 make -j64 Will now retry with latest trunk.
[Bug other/71627] AVR error: unable to find a register to spill in class 'POINTER_X_REGS'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71627 --- Comment #6 from Khuong Nguyen Tan --- (In reply to Senthil Kumar Selvaraj from comment #5) > Fixed in trunk (7.0) Thanks Senthil Kumar Selvaraj. It was worked !!
[Bug libgcc/67336] Verify pointers during stack unwind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67336 Yuri Gribov changed: What|Removed |Added CC||tetra2005 at gmail dot com --- Comment #4 from Yuri Gribov --- Posted RFC in https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00793.html
[Bug tree-optimization/77283] [7 Regression] Revision 238005 disables loop unrolling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77283 --- Comment #11 from rdapp at linux dot vnet.ibm.com --- Any progress on this? The patch fixes the problem for s390x (no performance regressions), but without it we see the regression in SPEC2006's libquantum all the time, I guess the same is true for PowerPC? Any chance for it to go into 7.0? For s390x, disabling the path-splitting pass does not introduce performance regressions either and fixes libquantum but that would only be a very last resort.
[Bug c++/79070] New: Unhelpful error message for ambiguous type in template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79070
Bug ID: 79070
Summary: Unhelpful error message for ambiguous type in template
parameter
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gccbugbjorn at fahller dot se
Target Milestone: ---
Compiling the below program with g++-7 on gcc.godbolt.org and other self
builts, and also older releases of g++:
namespace A {
class Foo {};
}
namespace B {
class Foo{};
}
using namespace A;
using namespace B;
template using t = T;
using type = t;
//Foo* p = nullptr;
gives the unhelpful error message
maggot:/tmp>g++ -std=c++14 c.cpp
c.cpp:13:19: error: template argument 1 is invalid
using type = t;
Removing the comment for the Foo*, gives a considerably more helpful message:
maggot:/tmp>g++ -std=c++14 c.cpp
c.cpp:13:19: error: template argument 1 is invalid
using type = t;
^
c.cpp:15:1: error: reference to 'Foo' is ambiguous
Foo* p = nullptr;
^
c.cpp:6:11: note: candidates are: class B::Foo
class Foo{};
^
c.cpp:3:11: note: class A::Foo
class Foo {};
^
[Bug target/40411] -std=c99 does not enable c99 mode in Solaris C library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40411 --- Comment #30 from Rainer Orth --- Created attachment 40507 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40507&action=edit combined proposed patch
[Bug middle-end/78142] Commit r241590 is more registers to be used for on gcc.target/aarch64/vector_initialization_nostack.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78142 tnfchris at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from tnfchris at gcc dot gnu.org --- This seems to be passing now so closing.
[Bug c++/79070] Unhelpful error message for ambiguous type in template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79070
--- Comment #1 from Björn Fahller ---
More info: adding an alias for a function signature involving the ambiguous Foo
in the above program gives a directly misleading error message:
using type = void(Foo);
c.cpp:12:18: error: expected ';' before '(' token
using type = void(Foo);
^
[Bug target/40411] -std=c99 does not enable c99 mode in Solaris C library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40411
--- Comment #31 from ro at CeBiTec dot Uni-Bielefeld.DE ---
I've started looking at this again.
Norm's patch has a few problems:
* For one, it matches a couple of alias names for -std values, which
will never hit the specs machinery.
* Worse, though: since gcc 5 changed its default to -std=gnu11 it
doesn't work without an explicit -std=* option given. Instead, one
has to handle it the other way round: use values-xpg4.o only with an
explicit -std=c90 or -std=gnu90, and values-xpg6.o otherwise.
That default is also necessary because many runtime libraries
(libstdc++, libgfortran, libgo, probably others) depend on C99
semantics by default, and there's no way of determining in specs which
language is being linked for.
The attached patch does this, and includes a forward port of Jeff's
patch to escape special characters like `:' in %{S:X} expressions.
It also removes the xfail from the libstdc++ test that requires C99
semantics from libc to work.
There's still more investigation to be done on my part, like
* when exactly values-X[ac].o are appropriate,
* what Studio 15.c cc/c89/c99, CC, f77/f90/f95 do in this space
Also, there's the issue of copyright: I suspect Jeff's patch is large
enough to require an assignment (which may be hard to get after 8 years,
unless he has one in place already ;-). If this proves impossible, one
could omit the handling for -std=iso9899:199409 for now, which is only a
niche case (or introduce -std=c94 and make -std=iso9899:199409 an alias
for that, but that would be an ugly hack).
The same might be true for Norm's comment in his patch, though I suspect
Oracle has a corporate assignment on file.
Given how late in the GCC 7 cycle we are, I fear it's becoming too late
to get this in; however I still wanted to keep the ball rolling.
Rainer
[Bug bootstrap/79069] [7 Regression] Bootstrap failure on s390x-linux while building libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79069 --- Comment #1 from Dominik Vogt --- What are the revision and the configure flags that trigger this, please? r244350 bootstraps without problem here.
[Bug tree-optimization/77283] [7 Regression] Revision 238005 disables loop unrolling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77283 Richard Biener changed: What|Removed |Added Attachment #39469|0 |1 is obsolete|| --- Comment #12 from Richard Biener --- Created attachment 40508 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40508&action=edit updated patch Well, updated patch avoids to regress existing testcases (where they make sense). But it doesn't fix the s390 testcase (added as split-path-9.c) given we have [85.00%]: # i_15 = PHI # prephitmp_19 = PHI _2 = prephitmp_19 & 1; if (_2 != 0) goto ; [50.00%] else goto ; [50.00%] [42.50%]: _3 = prephitmp_19 ^ 1; *state_9(D) = _3; [85.00%]: # prephitmp_17 = PHI i_11 = i_15 + 1; if (i_11 != size_8(D)) goto ; [85.00%] else goto ; [15.00%] [72.25%]: goto ; [100.00%] where clearly threading is possible (and wanted). Unfortunately we do a pretty bad job as followup (for whatever reason). We fail to transform this to an early exit of the loop. Jump threading fails to thread away the & 1 check as well.
[Bug bootstrap/79069] [7 Regression] Bootstrap failure on s390x-linux while building libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79069 --- Comment #2 from Jakub Jelinek --- Vanilla r244305, and ../configure --disable-bootstrap --enable-languages=c,c++,go,lto \ --with-long-double-128 --with-arch=z9-109 --with-tune=z10 make -j4 on s390x. Let me retry with latest trunk.
[Bug tree-optimization/77283] [7 Regression] Revision 238005 disables loop unrolling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77283 --- Comment #13 from Richard Biener --- Btw, I'm somewhat fed up with the lack of maintainance shown by the pass submitter. He doesn't have write-after-approval nor a bugzilla account.
[Bug tree-optimization/77283] [7 Regression] Revision 238005 disables loop unrolling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77283
--- Comment #14 from Richard Biener ---
And maybe PR77366 is too simplified. The following testcase is "fixed":
void
foo(unsigned int size, unsigned int *state)
{
unsigned int i;
for(i = 0; i < size; i++)
{
if(state[i] & 1)
state[i] ^= 1;
}
}
[Bug target/79066] [7 Regression] non-PIC code generated for powerpc glibc with -fpic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79066 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-01-12 CC||jakub at gcc dot gnu.org, ||meissner at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- My bisection actually points to r242679 introducing this.
[Bug bootstrap/79069] [7 Regression] Bootstrap failure on s390x-linux while building libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79069 --- Comment #3 from Dominik Vogt --- > --disable-bootstrap ?
[Bug bootstrap/79069] [7 Regression] Bootstrap failure on s390x-linux while building libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79069
--- Comment #4 from Jakub Jelinek ---
And with r244350 ../configure --disable-bootstrap
--enable-languages=c,c++,go,lto --with-long-double-128 --with-arch=z9-109
--with-tune=z10
reproduced too.
Note that without --enable-checking=release, the error actually is:
../../../../libgo/go/runtime/trace.go: In function
‘runtime.dump.pN23_runtime.traceStackTable’:
../../../../libgo/go/runtime/trace.go:731:1: error: fallthru edge after
unconditional jump in bb 2
func (tab *traceStackTable) dump() {
^
../../../../libgo/go/runtime/trace.go:731:1: error: wrong number of branch
edges after unconditional jump in bb 2
../../../../libgo/go/runtime/trace.go:731:1: internal compiler error:
verify_flow_info failed
0x802b7925 verify_flow_info()
../../gcc/cfghooks.c:260
0x80d329ed checking_verify_flow_info
../../gcc/cfghooks.h:198
0x80d329ed try_optimize_cfg
../../gcc/cfgcleanup.c:2988
0x80d330bf cleanup_cfg(int)
../../gcc/cfgcleanup.c:3152
0x80d33309 execute
../../gcc/cfgcleanup.c:3281
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug bootstrap/79069] [7 Regression] Bootstrap failure on s390x-linux while building libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79069 --- Comment #5 from Jakub Jelinek --- (In reply to Dominik Vogt from comment #3) > > --disable-bootstrap > > ? Originally (the #c0 error) it has been of course --enable-bootstrap). But when trying to reproduce it, I didn't want to wait so long, so started with --disable-bootstrap to see if it can be reproduced even with that, and it can.
[Bug target/79066] [7 Regression] non-PIC code generated for powerpc glibc with -fpic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79066
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
--- Comment #2 from Jakub Jelinek ---
Reduced testcase:
/* { dg-do compile { target { fpic && ilp32 } } } */
/* { dg-options "-O2 -fpic" } */
/* { dg-final { dg-scan-assembler-not "@ha" } } */
/* { dg-final { dg-scan-assembler-not "@l" } } */
union U { double x; int i[2]; };
double
foo (double x)
{
union U u, v;
u.x = x;
v.i[0] = 0x7ff0;
v.i[1] = 0;
return u.x / v.x;
}
[Bug rtl-optimization/79071] New: Add test case for PR/65618
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79071 Bug ID: 79071 Summary: Add test case for PR/65618 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: james410 at cowgill dot org.uk Target Milestone: --- Created attachment 40509 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40509&action=edit a-except.adb Maciej asked me to file a PR to add the testcase I used to debug PR/65618 (ADA bootstrap failure on MIPS). https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00739.html It turns out that the testcase wasn't as large as I thought it was, although it is written in ADA (reduced from the original a-except). I've attached the adb and ads files. The commands I used to compile these were: ../build/gcc/gnat1 -I ../gcc/gcc/ada/ -I ../gcc/gcc/ada/gcc-interface -gnatwA -quiet -nostdinc -dumpbase a-except.adb -auxbase a-except -O1 -Wextra -Wall -g -gnatpg -g -fno-inline "-march=mips32r2" -mfpxx -mllsc -mips32r2 -mabi=32 -mel a-except.adb -o a-except.s.1 -gtoggle ../build/gcc/gnat1 -I ../gcc/gcc/ada/ -I ../gcc/gcc/ada/gcc-interface -gnatwA -quiet -nostdinc -dumpbase a-except.adb -auxbase a-except -O1 -Wextra -Wall -g -gnatpg -g -fno-inline "-march=mips32r2" -mfpxx -mllsc -mips32r2 -mabi=32 -mel a-except.adb -o a-except.s.2 (identical except for output file and -gtoggle) Where ../build = root gcc build directory ../gcc = root gcc source directory
[Bug rtl-optimization/79071] Add test case for PR/65618
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79071 --- Comment #1 from James Cowgill --- Created attachment 40510 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40510&action=edit a-except.ads
[Bug bootstrap/79069] [7 Regression] Bootstrap failure on s390x-linux while building libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79069 --- Comment #6 from Dominik Vogt --- Confirmed; bisecting now.
[Bug bootstrap/79069] [7 Regression] Bootstrap failure on s390x-linux while building libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79069
--- Comment #7 from Jakub Jelinek ---
The ICE is during the jump2 pass, there is EDGE_FALLTHRU in between
(note 21 1 942 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 942 21 943 2 (unspec_volatile [
(code_label 0 0 0 10311 (nil) [2 uses])
(code_label 946 944 960 3 10310 (nil) [2 uses])
(const_int 71344 [0x116b0])
(const_int 0 [0])
] UNSPECV_SPLIT_STACK_DATA) "../../../../libgo/go/runtime/trace.go":731
-1
(insn_list:REG_LABEL_OPERAND 0 (insn_list:REG_LABEL_OPERAND 946 (nil
(insn 943 942 944 2 (set (reg:SI 1 %r1)
(label_ref 0)) "../../../../libgo/go/runtime/trace.go":731 -1
(insn_list:REG_LABEL_OPERAND 0 (nil)))
(jump_insn 944 943 946 2 (parallel [
(set (pc)
(label_ref 946))
(set (reg:SI 1 %r1)
(unspec_volatile [
(symbol_ref:SI ("__morestack") [flags 0x3])
(reg:SI 1 %r1)
] UNSPECV_SPLIT_STACK_CALL))
]) "../../../../libgo/go/runtime/trace.go":731 -1
(expr_list:REG_UNUSED (reg:SI 1 %r1)
(nil))
-> 946)
basic block and
(code_label 946 944 960 3 10310 (nil) [2 uses])
(note 960 946 947 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(insn/f 947 960 948 3 (parallel [
(set/f (mem:SI (plus:SI (reg/f:SI 15 %r15)
(const_int 24 [0x18])) [332 S4 A8])
(reg:SI 6 %r6))
(set/f (mem:SI (plus:SI (reg/f:SI 15 %r15)
(const_int 28 [0x1c])) [332 S4 A8])
(reg:SI 7 %r7))
(set/f (mem:SI (plus:SI (reg/f:SI 15 %r15)
(const_int 32 [0x20])) [332 S4 A8])
(reg:SI 8 %r8))
(set/f (mem:SI (plus:SI (reg/f:SI 15 %r15)
(const_int 36 [0x24])) [332 S4 A8])
(reg:SI 9 %r9))
(set/f (mem:SI (plus:SI (reg/f:SI 15 %r15)
(const_int 40 [0x28])) [332 S4 A8])
(reg:SI 10 %r10))
(set/f (mem:SI (plus:SI (reg/f:SI 15 %r15)
(const_int 44 [0x2c])) [332 S4 A8])
(reg:SI 11 %r11))
(set/f (mem:SI (plus:SI (reg/f:SI 15 %r15)
(const_int 48 [0x30])) [332 S4 A8])
(reg:SI 12 %r12))
(set/f (mem:SI (plus:SI (reg/f:SI 15 %r15)
(const_int 52 [0x34])) [332 S4 A8])
(reg:SI 13 %r13))
(set/f (mem:SI (plus:SI (reg/f:SI 15 %r15)
(const_int 56 [0x38])) [332 S4 A8])
(reg:SI 14 %r14))
(set/f (mem:SI (plus:SI (reg/f:SI 15 %r15)
(const_int 60 [0x3c])) [332 S4 A8])
(reg/f:SI 15 %r15))
]) "../../../../libgo/go/runtime/trace.go":731 -1
(expr_list:REG_DEAD (reg:SI 14 %r14)
(expr_list:REG_DEAD (reg:SI 13 %r13)
(expr_list:REG_DEAD (reg:SI 12 %r12)
(expr_list:REG_DEAD (reg:SI 10 %r10)
(expr_list:REG_DEAD (reg:SI 9 %r9)
(expr_list:REG_DEAD (reg:SI 8 %r8)
(expr_list:REG_DEAD (reg:SI 7 %r7)
(expr_list:REG_DEAD (reg:SI 6 %r6)
(nil))
(insn 948 947 949 3 (set (reg:SI 13 %r13)
(unspec_volatile [
(const_int 0 [0])
] UNSPECV_MAIN_POOL)) "../../../../libgo/go/runtime/trace.go":731
-1
(nil))
(insn/f 949 948 950 3 (parallel [
(set (reg/f:SI 15 %r15)
(plus:SI (reg/f:SI 15 %r15)
(mem/u/c:SI (unspec:SI [
(symbol_ref/u:SI ("*.LC1035") [flags 0x2])
(reg:SI 13 %r13)
] UNSPEC_LTREF) [10 S4 A32])))
(clobber (reg:CC 33 %cc))
]) "../../../../libgo/go/runtime/trace.go":731 -1
(expr_list:REG_DEAD (reg:SI 13 %r13)
(expr_list:REG_UNUSED (reg:CC 33 %cc)
(expr_list:REG_FRAME_RELATED_EXPR (set (reg/f:SI 15 %r15)
(plus:SI (reg/f:SI 15 %r15)
(const_int -71344 [0xfffee950])))
(nil)
(insn 950 949 951 3 (set (reg:SI 12 %r12)
(symbol_ref:SI ("_GLOBAL_OFFSET_TABLE_") [flags 0x2]))
"../../../../libgo/go/runtime/trace.go":731 -1
(nil))
(note 951 950 941 3 NOTE_INSN_PROLOGUE_END)
(insn 941 951 3 3 (set (reg:SI 13 %r13)
(unspec_volatile [
(const_int 0 [0])
] UNSPECV_MAIN_POOL)) -1
(nil))
(note 3 941 26 3 NOTE_INSN_FUNCTION_BEG)
(note 26 3 2 3 NOTE_INSN_DELETED)
(insn 2 26 27 3 (set (mem/c:SI (plus:SI (reg/f:SI 15 %r15)
(const_int 220 [0xdc])) [331 %sfp+-71124 S4 A32])
(reg:SI 2 %r2 [ tab ])) "../../../../libgo/go/runtime/trace.go":731
1100 {*movsi_esa}
(expr_list:REG_DEAD (reg:SI 2 %r2 [ tab ])
[Bug bootstrap/79069] [7 Regression] Bootstrap failure on s390x-linux while building libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79069 --- Comment #8 from Jakub Jelinek --- Maybe the easiest fix would be to emit the __morestack magic call patterns as ASM_OPERANDS like one that is emitted for asm goto. The cfgrtl.c etc. code has already years of fixes to handle those calls and deal with degenerate calls etc.
[Bug bootstrap/79069] [7 Regression] Bootstrap failure on s390x-linux while building libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79069 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-01-12 Ever confirmed|0 |1 --- Comment #9 from Jakub Jelinek --- Or, just look where extract_asm_operands is used in cfgrtl.c and handle similarly conditional and unconditional jumps that have UNSPECs in their PATTERN similarly.
[Bug tree-optimization/77283] [7 Regression] Revision 238005 disables loop unrolling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77283 --- Comment #15 from rdapp at linux dot vnet.ibm.com --- The updated patch fixes libquantum on s390 so PR77366 might indeed be to simplified to check for that, but it was unrolled before r238005. Addressing libquantum is more important, of course.
[Bug target/79058] [7 Regression] ARM: internal compiler error: in extract_constrain_insn, at recog.c:2213
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79058 Arnd Bergmann changed: What|Removed |Added CC||vogt at linux dot vnet.ibm.com --- Comment #3 from Arnd Bergmann --- I bisected the problem down to trunk@243578, see https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=243578
[Bug target/79058] [7 Regression] ARM: internal compiler error: in extract_constrain_insn, at recog.c:2213
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79058 --- Comment #4 from Dominik Vogt --- Can you please add the combine dump (and the dump before combine)?
[Bug bootstrap/79069] [7 Regression] Bootstrap failure on s390x-linux while building libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79069 --- Comment #10 from Jakub Jelinek --- Seems the barrier after the unconditional __morestack call is removed by rtl_tidy_fallthru_edge. I think: --- gcc/cfgrtl.c.jj 2017-01-01 12:45:35.0 +0100 +++ gcc/cfgrtl.c2017-01-12 13:24:48.414579702 +0100 @@ -1794,6 +1794,10 @@ rtl_tidy_fallthru_edge (edge e) q = PREV_INSN (q); } + /* Unconditional jumps with side-effects (i.e. which we can't just delete + together with the barrier) should never have a fallthru edge. */ + else if (JUMP_P (q) && any_uncondjump_p (q)) +return; /* Selectively unlink the sequence. */ if (q != PREV_INSN (BB_HEAD (c))) should fix this. Let me try that.
[Bug lto/79061] [7 Regression][LTO][ASAN] LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79061 Maxim Ostapenko changed: What|Removed |Added CC||m.ostapenko at samsung dot com --- Comment #4 from Maxim Ostapenko --- (In reply to Tobias Burnus from comment #3) > (In reply to Richard Biener from comment #2) > > Is this after the fix for PR79042? > > I am nearly certain that it was after that fix. > > Before, I got an UBSAN overflow but only when combining OpenMP, LTO, > -fipa-cp-clone and UBSAN, which I had hoped PR78365 and PR78599 would fix. > (It didn't.) > > Shortly after, I saw the commit for PR79042, tried whether it made a > difference - and ended up with this bug. > > [Sorry for not narrowing the regression range in the initial report. (I > somehow failed to realize that this ASAN message comes way before the UBSAN > error can be triggered.)] You have ASAN_OPTIONS=check_initialization_order=true exported on your system, right? (because w/o this option initialization-order-fiasco checker is disabled) Here a more detailed ASan log: $ ASAN_OPTIONS=check_initialization_order=true:report_globals=3 ./a.out #0 0x41a29b in __asan_register_globals /home/max/workspace/downloads/gcc/libsanitizer/asan/asan_globals.cc:326 #1 0x4f608f in _GLOBAL__sub_I_00099_1_main.4474 (/tmp/test/a.out+0x4f608f) #2 0x4f60ec in __libc_csu_init (/tmp/test/a.out+0x4f60ec) #3 0x7f9f12efaed4 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21ed4) #4 0x405feb (/tmp/test/a.out+0x405feb) === ID 1140850689; 0x0072ce40 0x0072d000 ==29614==Added Global[0x0072ce40]: beg=0x0050bee0 size=1/64 name=piecewise_construct module=/tmp/ccdXK8GX.ltrans0.o dyn_init=0 ==29614== location (0x0072ce00): name=/home/max/install/master/include/c++/7.0.0/bits/stl_pair.h[0x0050c020], 79 35 ==29614==Added Global[0x0072ce80]: beg=0x01391e20 size=1/64 name=__ioinit module=/tmp/ccdXK8GX.ltrans0.o dyn_init=1 ==29614== location (0x0072ce10): name=/home/max/install/master/include/c++/7.0.0/iostream[0x0050c060], 74 25 ==29614==Added Global[0x0072cec0]: beg=0x01391ea0 size=2/64 name=xptimer_coordinit module=/tmp/ccdXK8GX.ltrans0.o dyn_init=1 ==29614== location (0x0072ce20): name=xptiming.cc[0x0050bf60], 5 9 ==29614==Added Global[0x0072cf00]: beg=0x01391e60 size=2/64 name=xptimer_tiling module=/tmp/ccdXK8GX.ltrans0.o dyn_init=1 ==29614== location (0x0072ce30): name=xptiming.cc[0x0050bf60], 4 9 ==29614==Added Global[0x0072cf40]: beg=0x0050bfe0 size=18/64 name=*.LC3 module=/tmp/ccdXK8GX.ltrans0.o dyn_init=0 ==29614==Added Global[0x0072cf80]: beg=0x0050bf60 size=12/64 name=*.LC1 module=/tmp/ccdXK8GX.ltrans0.o dyn_init=0 ==29614==Added Global[0x0072cfc0]: beg=0x0050bfa0 size=15/64 name=*.LC2 module=/tmp/ccdXK8GX.ltrans0.o dyn_init=0 ==29614==Added Global[0x0072d000]: beg=0x0050bf20 size=11/64 name=*.LC0 module=/tmp/ccdXK8GX.ltrans0.o dyn_init=0 DynInitPoison module: xptimer.cc DynInitPoison module: xptiming.cc = ==29614==Search Global[0x0072d000]: beg=0x0050bf20 size=11/64 name=*.LC0 module=/tmp/ccdXK8GX.ltrans0.o dyn_init=0 ==29614==Search Global[0x0072cfc0]: beg=0x0050bfa0 size=15/64 name=*.LC2 module=/tmp/ccdXK8GX.ltrans0.o dyn_init=0 ==29614==Search Global[0x0072cf80]: beg=0x0050bf60 size=12/64 name=*.LC1 module=/tmp/ccdXK8GX.ltrans0.o dyn_init=0 ==29614==Search Global[0x0072cf40]: beg=0x0050bfe0 size=18/64 name=*.LC3 module=/tmp/ccdXK8GX.ltrans0.o dyn_init=0 ==29614==Search Global[0x0072cf00]: beg=0x01391e60 size=2/64 name=xptimer_tiling module=/tmp/ccdXK8GX.ltrans0.o dyn_init=1 ==29614== location (0x0072ce30): name=xptiming.cc[0x0050bf60], 4 9 ==29614==Search Global[0x0072cec0]: beg=0x01391ea0 size=2/64 name=xptimer_coordinit module=/tmp/ccdXK8GX.ltrans0.o dyn_init=1 ==29614== location (0x0072ce20): name=xptiming.cc[0x0050bf60], 5 9 ==29614==Search Global[0x0072ce80]: beg=0x01391e20 size=1/64 name=__ioinit module=/tmp/ccdXK8GX.ltrans0.o dyn_init=1 ==29614== location (0x0072ce10): name=/home/max/install/master/include/c++/7.0.0/iostream[0x0050c060], 74 25 ==29614==Search Global[0x0072ce40]: beg=0x0050bee0 size=1/64 name=piecewise_construct module=/tmp/ccdXK8GX.ltrans0.o dyn_init=0 ==29614== location (0x0072ce00): name=/home/max/install/master/include/c++/7.0.0/bits/stl_pair.h[0x0050c020], 79 35 ==29614==ERROR: AddressSanitizer: initialization-order-fiasco on address 0x01391e60 at pc 0x004f5ea9 bp 0x7ffcf3920920 sp 0x7ffcf3920918 WRITE of size 1 at 0x01391e60 thread T0 #0 0x4f5ea8 in __base_ctor /tmp/test/xptimer.cc:9 #1 0x4f602d in __static_initialization_and_destruction_0 /tmp/test/xptiming.cc:4 #2 0x4f605b in _GLOBAL__sub_I_xp
[Bug c++/77812] [5/6/7 Regression] incorrectly rejects valid C++ code that uses enum in template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77812 --- Comment #6 from Nathan Sidwell --- Author: nathan Date: Thu Jan 12 12:40:28 2017 New Revision: 244351 URL: https://gcc.gnu.org/viewcvs?rev=244351&root=gcc&view=rev Log: cp/ PR c++/77812 * name-lookup.c (set_namespace_binding_1): An overload of 1 decl is a new overload. testsuite/ PR c++/77812 * g++.dg/pr77812.C: New. Added: branches/gcc-5-branch/gcc/testsuite/g++.dg/pr77812.C Modified: branches/gcc-5-branch/gcc/cp/ChangeLog branches/gcc-5-branch/gcc/cp/name-lookup.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug bootstrap/79068] [7 Regression] Bootstrap failure on powerpc64-linux and armv7hl-linux-gnueabi in libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79068 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- I can reproduce it also with r244326 on gcc110.fsffrance.org just with ../configure --enable-languages=c,c++,go --disable-bootstrap but r244327 as well as r244350 don't ICE that way and complete. I don't know the go FE at all, Ian, is r244327 is the fix for that bug, or just it made the bug latent? Looking at the https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00647.html and https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00746.html mails and the former mentioning the same ICE on the same file, I'm expecting this is the right fix and thus closing. Ian, please reopen if not.
[Bug c++/77812] [5/6/7 Regression] incorrectly rejects valid C++ code that uses enum in template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77812 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Nathan Sidwell --- Fixed on 5, 6 & trunk
[Bug rtl-optimization/59461] missed zero-extension elimination in the combiner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59461 Matthew Fortune changed: What|Removed |Added CC||matthew.fortune at imgtec dot com --- Comment #6 from Matthew Fortune --- (In reply to Eric Botcazou from comment #5) > Fixed in GCC 7. There is a reasonable chance that this patch broke mips64 n64 but I do not have confirmation yet. See PR target/78660. I can vaguely see how this patch may affect MIPS64 in terms of how 32-bit values are handled on a MIPS64 architecture with the sign bit replicated to the upper-32 bits. This presumably is somehow not accounted for in the nonzero_bits logic. I'm yet to get my head around what the issue is but if anyone has a pointer based on the potential impact on MIPS64 as described above then I'd be grateful.
[Bug target/79058] [7 Regression] ARM: internal compiler error: in extract_constrain_insn, at recog.c:2213
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79058 --- Comment #5 from Arnd Bergmann --- Created attachment 40511 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40511&action=edit rtl dump 256r.ed_dce and 257r.combine Here are four dumps, I hope this is what you are asking for: latest gcc (trunk@243588) building the minimized test case minimized.c.256r.ud_dce minimized.c.257r.combine same test after reverting trunk@243578, which fixes the problem for me: minimized.c.256r.ud_dce-revert minimized.c.257r.combine-revert
[Bug c/78768] -Walloca-larger-than and -Wformat-length warnings disabled by -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78768 Rainer Orth changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #7 from Rainer Orth --- The new gcc.dg/pr78768.c testcases XPASSes on Solaris, both sparc and x86, 32 and 64-bit: XPASS: gcc.dg/pr78768.c -Wformat-length (test for warnings, line 10)
[Bug tree-optimization/78775] [7 Regression] ICE in maybe_warn_alloc_args_overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78775 Rainer Orth changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #10 from Rainer Orth --- This patch introduced two issues on Solaris: * FAIL: gcc.dg/pr78973.c (test for warnings, line 12) seen on both Solaris/SPARC and x86, 32-bit only (and according to gcc-testresults on many other targets, too) * XPASS: gcc.dg/attr-alloc_size-11.c missing range info for signed char (test for warnings, line 49) XPASS: gcc.dg/attr-alloc_size-11.c missing range info for short (test for warnings, line 50) Only seen on Solaris/SPARC, 32 and 64-bit. Rainer
[Bug target/78633] [7 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78633 --- Comment #17 from Oleg Endo --- (In reply to Jakub Jelinek from comment #16) > When a fix exists, why hasn't it been posted to gcc-patches? Because, like I wrote in comment #13, I would like to check if there might be a better fix for the problem. If not, we will commit the patch in comment #11 for GCC 7.
[Bug fortran/70696] [Coarray] ICE on EVENT POST of host-associated EVENT_TYPE coarray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70696 --- Comment #8 from vehre at gcc dot gnu.org --- Patch available at: https://gcc.gnu.org/ml/fortran/2017-01/msg00031.html Waiting for review. Backport to gcc-6 available.
[Bug fortran/70697] [Coarray] ICE on EVENT WAIT with array element UNTIL_COUNT argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70697 vehre at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|NEW |WAITING CC||vehre at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |vehre at gcc dot gnu.org --- Comment #3 from vehre at gcc dot gnu.org --- Patch available at: https://gcc.gnu.org/ml/fortran/2017-01/msg00032.html waiting for review.
[Bug middle-end/78977] [7 Regression] g++7 snprintf() of double produces wrong code with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78977 --- Comment #14 from Hannes Hauswedell --- I can confirm that the behaviour is fixed. Thanks for your quick and detailed answers.
[Bug libstdc++/66284] std::reference_wrapper is transparent to std::function::target_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66284 --- Comment #6 from Jonathan Wakely --- Author: redi Date: Thu Jan 12 14:28:38 2017 New Revision: 244364 URL: https://gcc.gnu.org/viewcvs?rev=244364&root=gcc&view=rev Log: PR66284 remove std::function special case for reference_wrapper PR libstdc++/66284 * doc/xml/manual/intro.xml: Document LWG 2781 change. * doc/html/*: Regenerate. * include/std/functional (_Function_base::_Ref_manager): Remove. (_Function_handler): Remove partial specializations for reference_wrapper. (function::target): Remove special case for const qualification. * testsuite/20_util/function/6.cc: Adjust tests for target type. * testsuite/20_util/function/7.cc: Likewise. * testsuite/20_util/function/8.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/doc/html/manual/bugs.html trunk/libstdc++-v3/doc/html/manual/documentation_hacking.html trunk/libstdc++-v3/doc/xml/manual/intro.xml trunk/libstdc++-v3/include/bits/std_function.h trunk/libstdc++-v3/testsuite/20_util/function/6.cc trunk/libstdc++-v3/testsuite/20_util/function/7.cc trunk/libstdc++-v3/testsuite/20_util/function/8.cc
[Bug libstdc++/66284] std::reference_wrapper is transparent to std::function::target_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66284 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.0 --- Comment #7 from Jonathan Wakely --- Fixed for gcc 7.
[Bug middle-end/46555] [5/6/7 Regression] PHI RTL expansion leads to CSiBE regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46555 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug debug/68860] [6/7 regression] FAIL: gcc.dg/guality/pr36728-1.c -flto -O3 -g line 16/7 arg1 == 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68860 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/13979] Error message about no matching function for call with derived class arguments could be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13979 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |7.0 --- Comment #12 from Jonathan Wakely --- r239184 improved those diagnostics.
[Bug tree-optimization/78604] [7 regression] test case gcc.target/powerpc/p8vector-vectorize-1.c fails starting with r242750
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78604
--- Comment #3 from amker at gcc dot gnu.org ---
For function sign_lt and uns_lt, the change causes worse code generation
unfortunately. Take uns_lt as example, the difference in optimized dump is as
like:
529,530c529,530
< vect_cst__32 = {val1_8(D), val1_8(D)};
< vect_cst__33 = {val2_7(D), val2_7(D)};
---
> vect_cst__32 = {val2_7(D), val2_7(D)};
> vect_cst__33 = {val1_8(D), val1_8(D)};
536c536
< vect_iftmp.412_34 = VEC_COND_EXPR ;
---
> vect_iftmp.412_34 = VEC_COND_EXPR = vect__2.411_31,
> vect_cst__32, vect_cst__33>;
Condition "<" is transformed into ">=" with the change, which results in more
insns after expanding:
***
*** 1014,1024
REG_EQUAL `uc'
49: r199:V2DI=[r195:SI+r167:SI]
50: r200:V2DI=[r197:SI+r167:SI]
!51: r202:V2DI=gtu(r200:V2DI,r199:V2DI)
!52: r201:V2DI={(r202:V2DI!=const_vector)?r170:V2DI:r171:V2DI}
!53: [r193:SI+r167:SI]=r201:V2DI
!54: r167:SI=r167:SI+0x10
!56: r203:CCUNS=cmp(r167:SI,0x2000)
!57: pc={(r203:CCUNS!=0)?L55:pc}
REG_BR_PROB 9899
!58: NOTE_INSN_BASIC_BLOCK 5
--- 1016,1028
REG_EQUAL `uc'
49: r199:V2DI=[r195:SI+r167:SI]
50: r200:V2DI=[r197:SI+r167:SI]
!51: r202:V2DI=gtu(r199:V2DI,r200:V2DI)
!52: r203:V2DI=r199:V2DI==r200:V2DI
!53: r204:V2DI=r202:V2DI|r203:V2DI
!54: r201:V2DI={(r204:V2DI!=const_vector)?r170:V2DI:r171:V2DI}
!55: [r193:SI+r167:SI]=r201:V2DI
!56: r167:SI=r167:SI+0x10
!58: r205:CCUNS=cmp(r167:SI,0x2000)
!59: pc={(r205:CCUNS!=0)?L57:pc}
REG_BR_PROB 9899
!60: NOTE_INSN_BASIC_BLOCK 5
So "<" is expanded into instruction (51), but ">=" is expanded into
instructions (51~53).
So powerpc has to compute ">=" with "> || =="? Apart from this, the change
itself only introduces additional canonicalization during tree-ifcvt,
transforming "<" to "<=". If the former form is more efficient on powerpc,
shall we take this into consideration when canonicalization?
Thanks.
[Bug c/69602] [6/7 Regression] over-ambitious logical-op warning on EAGAIN vs EWOULDBLOCK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69602 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug target/70321] [6/7 Regression] STV generates less optimized code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70321 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/71169] [7 Regression] ICE on invalid C++ code in pop_nested_class (cp/class.c:7785)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71169 Richard Biener changed: What|Removed |Added Keywords||error-recovery Priority|P3 |P4
[Bug tree-optimization/71237] [7 regression] scev tests failing after pass reorganization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71237 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #9 from Richard Biener --- Ok, I'll look at it and possibly will make GIMPLE testcases out of them (looking at the GIMPLE at the point of testcase introduction).
[Bug target/71270] [7 Regression] fortran regression after fix SLP PR58135
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71270 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug c++/71285] [7 regression] spurious 'insufficient contextual information' for member access on fold expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71285 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Known to work||6.3.0
[Bug c++/71406] [7 Regression] ICE on valid C++ code on x86_64-linux-gnu: in finish_class_member_access_expr, at cp/typeck.c:2782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71406 Richard Biener changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P1
[Bug tree-optimization/71433] [7 Regression] -Warray-bounds false positive with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71433 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Status|NEW |ASSIGNED Assignee|law at redhat dot com |rguenth at gcc dot gnu.org --- Comment #8 from Richard Biener --- Mine.
[Bug c++/71710] [7 Regression] ICE on valid C++11 code with decltype and alias template: in lookup_member, at cp/search.c:1255
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71710 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/71437] [7 regression] Performance regression after r235817
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71437 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug ipa/71207] [5/6/7 Regression] gcc 5.3 and 6.1 generates wrong code with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71207 Martin Liška changed: What|Removed |Added CC||jamborm at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #5 from Martin Liška --- Problem is caused by fact that we a C++ diamond virtual inheritance and Class1 in included in Class4 just in once. However, contains_type_p is called with outer_type == Class4, otr_type == Class3 and offset == 192. As Class1 is part of Class3 it pops up Class3's size and the test wrongly return false. BINFO is aware of having Class1 included just once: Class Class4 size=32 align=8 base size=8 base align=8 Class4 (0x0x7fecbda894d0) 0 nearly-empty vptridx=0 vptr=((& Class4::_ZTV6Class4) + 32) Class2 (0x0x7fecbda78340) 0 nearly-empty primary-for Class4 (0x0x7fecbda894d0) subvttidx=8 Class1 (0x0x7fecbdbdfe40) 8 virtual vptridx=24 vbaseoffset=-24 vptr=((& Class4::_ZTV6Class4) + 80) Class3 (0x0x7fecbda783a8) 24 nearly-empty virtual subvttidx=40 vptridx=32 vbaseoffset=-32 vptr=((& Class4::_ZTV6Class4) + 136) Class1 (0x0x7fecbdbdfe40) alternative-path here --^ Before r229859, the condition in contains_type_p was always false as TREE_CODE (outer_type) == INTEGER_CST was always false. I'm sending patch candidate and reducing a test-case from Firefox, where the newly modified condition returns false. Martin
[Bug ipa/71207] [5/6/7 Regression] gcc 5.3 and 6.1 generates wrong code with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71207 --- Comment #6 from Martin Liška --- Created attachment 40512 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40512&action=edit Patch candidate Btw. I really believe this should be marked as P1 because it creates invalid builtin_unreachable calls.
[Bug c++/71966] [7 Regression] ICE on invalid C++11 code (undefined constructor used in a constant expression): in cp_build_addr_expr_1, at cp/typeck.c:5671
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71966 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug tree-optimization/65206] Vectorized version of loop is removed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65206 --- Comment #10 from Richard Biener --- *** Bug 72739 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/72739] [7 Regression] FAIL: gcc.dg/vect/vect-mask-store-move-1.c after r238301
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72739 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Richard Biener --- dup. *** This bug has been marked as a duplicate of bug 65206 ***
[Bug target/72749] [7 Regression] ICE: verify_flow_info failed (error: wrong amount of branch edges after conditional jump in bb 5) w/ -O2 -fsched2-use-superblocks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72749 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug testsuite/72850] [7 Regression] FAIL: gcc.dg/tree-ssa/pr69270-3.c scan-tree-dump-times uncprop1 ", 1" 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72850 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug c++/71965] [6/7 regression] [concepts] Substitution error *after* failure to satisfy an earlier constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71965
Richard Biener changed:
What|Removed |Added
Keywords||rejects-valid
Priority|P3 |P2
Known to work||6.1.0
Target Milestone|7.0 |6.4
Summary|[7 regression] [concepts] |[6/7 regression] [concepts]
|Substitution error *after* |Substitution error *after*
|failure to satisfy an |failure to satisfy an
|earlier constraint |earlier constraint
Known to fail||6.2.0
--- Comment #2 from Richard Biener ---
Hm?
> g++-6 -S t.C -std=c++1z -fconcepts
t.C: In function ‘int main()’:
t.C:9:10: sorry, unimplemented: cannot initialize multi-dimensional array with
initializer
new T{ (Args&&)args... };
^~~~
same sorry with GCC 6.2 for me.
[Bug tree-optimization/77283] [7 Regression] Revision 238005 disables loop unrolling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77283 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #16 from Richard Biener --- Patch posted.
[Bug target/77345] [7 Regression] Segmentation fault w/ -misel -O1 (and above)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77345 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug target/78633] [7 Regression] [SH] libgcc/fp-bit.c:944:1: error: invalid rtl sharing found in the insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78633 --- Comment #18 from Jakub Jelinek --- If the original insn that has the op.set_src rtx in it is not removed by the splitter (which it seems it is not), and it is just expected to be removed during DCE later, then doing copy_rtx is the right thing to do there, sharing non-shareable RTXes between multiple instructions, even when it is just for a couple of passes, is invalid.
[Bug rtl-optimization/77416] [7 Regression] LRA rematerializing use of CA reg across function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77416 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from Richard Biener --- Fixed then (the bug).
[Bug tree-optimization/77445] [7 Regression] Performance drop after r239219 on coremark test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77445 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/77498] [7 regression] Performance drop after r239414 on spec2000/172mgrid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77498 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug target/79044] ICE in insn_is_swappable_p, at config/rs6000/rs6000.c:41191
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79044 --- Comment #4 from Bill Schmidt --- Author: wschmidt Date: Thu Jan 12 16:01:13 2017 New Revision: 244368 URL: https://gcc.gnu.org/viewcvs?rev=244368&root=gcc&view=rev Log: [gcc] 2017-01-12 Bill Schmidt PR target/79044 * config/rs6000/rs6000.c (insn_is_swappable_p): Mark element-reversing loads and stores as not swappable. [gcc/testsuite] 2017-01-12 Bill Schmidt PR target/79044 * gcc.target/powerpc/swaps-p8-26.c: New. Added: trunk/gcc/testsuite/gcc.target/powerpc/swaps-p8-26.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c trunk/gcc/testsuite/ChangeLog
[Bug lto/79061] [7 Regression][LTO][ASAN] LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79061 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- So, shall we for (maybe just for in_lto_p) replace pp_string (&module_name_pp, main_input_filename); with something that grabs the module name from VAR_DECL's containing TRANSLATION_UNIT_DECL? Though not sure how well will that work if the variables are C++17 inline vars, or some other comdat vars that LTO merges together, then the TRANSLATION_UNIT_DECL in VAR_DECL's ultimate context still might be different.
[Bug c++/71821] [5/6/7 regression] ICE on invalid C++11 code (incorrect argument for alignas): unexpected expression ‘f’ of kind template_id_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71821 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek --- I'd love to know that, too, so that I could take a stab at this.
[Bug rtl-optimization/59461] missed zero-extension elimination in the combiner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59461 --- Comment #7 from Eric Botcazou --- > There is a reasonable chance that this patch broke mips64 n64 but I do not > have confirmation yet. See PR target/78660. The quoted hunk only reverted a recent pessimization (r205550), the current code is the correct approach as explained in the comment. > I can vaguely see how this patch may affect MIPS64 in terms of how 32-bit > values are handled on a MIPS64 architecture with the sign bit replicated to > the upper-32 bits. This presumably is somehow not accounted for in the > nonzero_bits logic. Probably yes, maybe in conjunction with WORD_REGISTER_OPERATIONS. > I'm yet to get my head around what the issue is but if anyone has a pointer > based on the potential impact on MIPS64 as described above then I'd be > grateful. Is WORD_REGISTER_OPERATIONS correct for MIPS64, i.e. do all instructions operate on the full 64-bit itneger registers?
[Bug c++/79050] [5/6/7 Regression] ICE: tree code 'template_type_parm' is not supported in LTO streams
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79050 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- auto is something that needs to match dwarf2out.c is_cxx_auto, so needs to survive in the IL at least until the FE is done with it and until early dwarf creates DIEs for it. I suppose afterwards we could throw it away (free_lang_data pass?).
[Bug fortran/79072] New: ICE with class(*) pointer function result and character value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79072 Bug ID: 79072 Summary: ICE with class(*) pointer function result and character value Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- This example gives an ICE with the current 7.0 trunk and all 6.x releases: function foo() class(*), pointer :: foo character(3), target :: string = 'foo' foo => string select type (foo) type is (character(*)) !print *, foo end select end function The ICE disappears if either: 1) type is (character(*)) is replaced with integer, for example; 2) the return variable is specified in a result(...) clause. In the original code that exhibited the compiler bug, the function returns correct values except for character values, so I expect the underlying problem involves the unlimited polymorphic pointer assignment statement and character dynamic types. I introduced the select type (which produced the ICE) when debugging. Here's the output from the compiler: $ gfortran -c code.f90 code.f90:1:0: function foo() internal compiler error: tree check: expected record_type or union_type or qual_union_type, have function_type in gfc_class_len_get, at fortran/trans-expr.c:226 0xe75f1c tree_check_failed(tree_node const*, char const*, int, char const*, ...) ../../gcc/tree.c:9814 0x6f03c5 tree_check3(tree_node*, char const*, int, char const*, tree_code, tree_code, tree_code) ../../gcc/tree.h:3100 0x6f03c5 gfc_class_len_get(tree_node*) ../../gcc/fortran/trans-expr.c:226 0x745cbc trans_associate_var ../../gcc/fortran/trans-stmt.c:1757 0x745cbc gfc_trans_block_construct(gfc_code*) ../../gcc/fortran/trans-stmt.c:1810 0x6ba467 trans_code ../../gcc/fortran/trans.c:1913 0x747c1e gfc_trans_select_type_cases ../../gcc/fortran/trans-stmt.c:2401 0x747c1e gfc_trans_select_type(gfc_code*) ../../gcc/fortran/trans-stmt.c:3112 0x6ba3d7 trans_code ../../gcc/fortran/trans.c:1933 0x745638 gfc_trans_block_construct(gfc_code*) ../../gcc/fortran/trans-stmt.c:1803 0x6ba467 trans_code ../../gcc/fortran/trans.c:1913 0x6eb598 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6292 0x672f76 translate_all_program_units ../../gcc/fortran/parse.c:6008 0x672f76 gfc_parse_file() ../../gcc/fortran/parse.c:6208 0x6b6512 gfc_be_parse_file ../../gcc/fortran/f95-lang.c:202 Please submit a full bug report,
[Bug target/76731] [AVX512] _mm512_i32gather_epi32 and other scatter/gather routines have incorrect signature
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76731 --- Comment #10 from Kirill Yukhin --- (In reply to Andrew Senkevich from comment #8) > I think we should follow here declarations from icc headers to be compatible > with it. Okay. Could you pls state which rules ICC follows for all gather/scatter intrinsics? Could we use void const * for base in all gather intrinsics? What about scatters?
[Bug rtl-optimization/59461] missed zero-extension elimination in the combiner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59461 --- Comment #8 from Matthew Fortune --- (In reply to Eric Botcazou from comment #7) > > I'm yet to get my head around what the issue is but if anyone has a pointer > > based on the potential impact on MIPS64 as described above then I'd be > > grateful. > > Is WORD_REGISTER_OPERATIONS correct for MIPS64, i.e. do all instructions > operate on the full 64-bit integer registers? This is a notoriously hard topic to address. All instructions affect the full 64-bit register including those that do 32-bit arithmetic i.e. they will set/clear the upper bits to replicate bit-31. However, according to the architecture they logically operate on 32-bits and require that all inputs are canonical (sign bit replicated) otherwise the operation is invalid. So it would not matter whether the register was 33 bits or 1000 bits wide as long as all bits from 32 upwards replicate bit-31. The upper bits only become relevant once a 32-bit value is cast to a 64-bit value where sign extension is free and zero extension is an operation. truncation from 64-bit to 32-bit is a sign extension from bit-31 regardless of whether it is truncating to signed or unsigned. In terms of instruction definition we therefore have instructions that operate on DImode and instructions that operate on SImode. The SImode instructions just don't need to worry about what is happening with the upper bits. I don't know if any of that subtlety affects this yet.
[Bug target/79058] [7 Regression] ARM: internal compiler error: in extract_constrain_insn, at recog.c:2213
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79058 --- Comment #6 from Dominik Vogt --- I'm trying to build an cross compiler but cannot figure out the --target configure option to use. Neither --target=arm nor --target=arm-linux nor --target=arm-gnu-linux work. gcc/configure spits out an error message like this one: *** Configuration arm-gnu-linux-gnu not supported
[Bug target/79058] [7 Regression] ARM: internal compiler error: in extract_constrain_insn, at recog.c:2213
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79058 --- Comment #7 from ktkachov at gcc dot gnu.org --- (In reply to Dominik Vogt from comment #6) > I'm trying to build an cross compiler but cannot figure out the --target > configure option to use. Neither --target=arm nor --target=arm-linux nor > --target=arm-gnu-linux work. gcc/configure spits out an error message like > this one: > *** Configuration arm-gnu-linux-gnu not supported Try arm-none-linux-gnueabihf, or arm-none-eabi
[Bug tree-optimization/78319] [7 Regression] PASS->FAIL: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 20)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78319 --- Comment #19 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Thu Jan 12 17:02:38 2017 New Revision: 244372 URL: https://gcc.gnu.org/viewcvs?rev=244372&root=gcc&view=rev Log: Add Cortex-A15 tuning to gcc.dg/uninit-pred-8_a.c PR tree-optimization/78319 * gcc.dg/uninit-pred-8_a.c: Add -mtune=cortex-a15 for arm. Remove xfail. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/uninit-pred-8_a.c
[Bug rtl-optimization/72488] [7 Regression] wrong code (SIGFPE) at -Os and above on x86_64-linux-gnu (in the 64-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72488 --- Comment #7 from Jeffrey A. Law --- I poked at this a bit yesterday (given the irreducible loops I've got some concerns that jump threading might be involved). Whatever is going on, it is highly sensitive to just about any codegen changes. I've identified 3 separate patches from August that can make the bug go latent. Arggh.
[Bug testsuite/79073] New: FAIL: gcc.dg/pr78973.c (test for warnings, line 12) in ILP32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79073
Bug ID: 79073
Summary: FAIL: gcc.dg/pr78973.c (test for warnings, line 12)
in ILP32
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
As noted in pr78775 comment 10, the pr78973.c test added in r244290 fails on
ILP32 targets:
Running /src/gcc/git/gcc/testsuite/gcc.dg/dg.exp ...
FAIL: gcc.dg/pr78973.c (test for warnings, line 12)
=== gcc Summary ===
# of expected passes1
# of unexpected failures1
/home/msebor/build/gcc-git/gcc/xgcc version 7.0.0 20170112 (experimental)
(GCC)
The failure seems to be due to the lack or range information for the last
memset argument in ILP32. The VRP details dump shows the range information is
computed:
SSA form after inserting ASSERT_EXPRs
...
n_11 = ASSERT_EXPR ;
__builtin_memset (d_5(D), 0, n_11);
...
but then somehow not preserved for the n_3(D) argument:
Value ranges after VRP:
n_3(D): VARYING
n_11: [2147483648, +INF] EQUIVALENCES: { n_3(D) } (1 elements)
...
__builtin_memset (d_5(D), 0, n_3(D));
This seems like a defect/limitation in GCC, not one in the test, so I'll open a
separate bug for it and xfail the test until the defect is fixed.
[Bug tree-optimization/78319] [7 Regression] PASS->FAIL: gcc.dg/uninit-pred-8_a.c bogus warning (test for bogus messages, line 20)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78319 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #20 from ktkachov at gcc dot gnu.org --- Closing as fixed then.
[Bug tree-optimization/78775] [7 Regression] ICE in maybe_warn_alloc_args_overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78775 --- Comment #11 from Martin Sebor --- I've raised bug 79073 for the gcc.dg/pr78973.c failure. AFAICT, it's due to a VRP defect or limitation.
[Bug rtl-optimization/78751] [7 Regression] ICE in extract_insn, at recog.c:2311 (error: unrecognizable insn) w/ -Os -misel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78751 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Or perhaps ifcvt.c should gen_cond_trap only if the arguments already satisfy ctrap4's predicates and punt if not. So perhaps avoid calling gen_cond_trap altogether, and instead do what it does except for the prepare_cmp_insn and do insn_operand_matches on all the operands? The #c3 patch isn't that ugly either.
[Bug target/79044] ICE in insn_is_swappable_p, at config/rs6000/rs6000.c:41191
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79044 --- Comment #5 from Bill Schmidt --- Author: wschmidt Date: Thu Jan 12 17:19:17 2017 New Revision: 244373 URL: https://gcc.gnu.org/viewcvs?rev=244373&root=gcc&view=rev Log: [gcc] 2017-01-12 Bill Schmidt PR target/79044 * config/rs6000/rs6000.c (insn_is_swappable_p): Mark element-reversing loads and stores as not swappable. [gcc/testsuite] 2017-01-12 Bill Schmidt PR target/79044 * gcc.target/powerpc/swaps-p8-26.c: New. Added: branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/swaps-p8-26.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/config/rs6000/rs6000.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
