[Bug testsuite/65940] New: g++.dg/other/anon5.C requires dwarf4 support in ld
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65940 Bug ID: 65940 Summary: g++.dg/other/anon5.C requires dwarf4 support in ld Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- g++.log: ... build/gcc/testsuite/g++2/../../xg++ -Bbuild/gcc/testsuite/g++2/../../ src/gcc/testsuite/g++.dg/other/anon5.C -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -Inobootstrap/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -Inobootstrap/build/x86_64-unknown-linux-gnu/libstdc++-v3/include -Isrc/libstdc++-v3/libsupc++ -Isrc/libstdc++-v3/include/backward -Isrc/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++98 -g -Lbuild/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs -Bbuild/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs -Lbuild/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs -lm -o anon5.exe /usr/bin/ld: Dwarf Error: found dwarf version '4', this reader only handles version 2 and 3 information. /tmp/ccgoCWLN.o: In function `f()': anon5.C:(.text+0x5): undefined reference to `(anonymous namespace)::c::t' collect2: error: ld returned 1 exit status compiler exited with status 1 PASS: g++.dg/other/anon5.C -std=gnu++98 undefined (test for warnings, line ) FAIL: g++.dg/other/anon5.C -std=gnu++98 (test for excess errors) ... ld version is: ... GNU ld (GNU Binutils for Ubuntu) 2.20.1-system.20100303 ... Fail in same testcase also observed at: https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg02807.html .
[Bug testsuite/65940] g++.dg/other/anon5.C requires dwarf4 support in ld
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65940 --- Comment #1 from vries at gcc dot gnu.org --- unix/: FAIL: g++.dg/other/anon5.C -std=gnu++11 (test for excess errors) FAIL: g++.dg/other/anon5.C -std=gnu++14 (test for excess errors) FAIL: g++.dg/other/anon5.C -std=gnu++98 (test for excess errors) unix/-m32: FAIL: g++.dg/other/anon5.C -std=gnu++11 (test for excess errors) FAIL: g++.dg/other/anon5.C -std=gnu++14 (test for excess errors) FAIL: g++.dg/other/anon5.C -std=gnu++98 (test for excess errors)
[Bug testsuite/65785] libgo TestIPv4MulticastListener test fails on machine with no network connection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65785 --- Comment #1 from vries at gcc dot gnu.org --- ran into this again with new build and test
[Bug tree-optimization/65935] [6 Regression] 433.milc in SPEC CPU 2006 is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65935 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- What exact revision do you mean? r62283 is quite a bit old...
[Bug c++/65936] [6 Regression] ICE building libboost_log.so.1.58.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65936 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |6.0
[Bug c/47043] allow deprecating enum values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47043 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |6.0
[Bug lto/65559] [5/6 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559 Matt Breedlove breedlove.matt at gmail dot com changed: What|Removed |Added CC||breedlove.matt at gmail dot com --- Comment #19 from Matt Breedlove breedlove.matt at gmail dot com --- Kai, This corrects issue #2 from my ML post (https://gcc.gnu.org/ml/gcc/2015-04/msg00355.html) but should this not be something like the following instead? fd = open (filename, O_RDONLY|O_BINARY); With how things are currently written in the code, archive libraries will always fail to be opened properly since the code used to parse their file names and offsets will always chuck out the work that is being done. Toward the top of the loop, we're setting char *filename = argv[i]; and then overriding it when we hit a filename with an offset but then using the original un-parsed command-line parameter when trying to open the file to see if it exists. Ex: Parameter: libarchive.a@0x42e20 Parsed as: filename = libarchive.a offset = 0x42e20 File opened: libarchive.a@0x42e20 (instead of libarchive.a) From looking at the code, this has been this way for quite awhile. I tested the change after modifying it to use the filename variable instead and it works successfully rather than simply failing to open any archive passed in with an offset.
[Bug libstdc++/65942] [5/6 Regression] [C++14] cannot use std::function as comparator in algorithms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65942
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-04-30
Summary|cannot use std::function as |[5/6 Regression] [C++14]
|comparator in algorithms|cannot use std::function as
||comparator in algorithms
Ever confirmed|0 |1
Severity|critical|normal
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
The experimental/optional header is not relevant to the bug.
The error only happens in C++14 mode.
#include algorithm
#include functional
bool cmp1(const int a, const int b) { return a b; }
std::functionbool (const int, const int) cmp2 = cmp1;
int main() {
int v[1];
std::sort(v, v, cmp1); // works
std::sort(v, v, cmp2); // fails
}
[Bug libstdc++/65942] [5/6 Regression] [C++14] cannot use std::function as comparator in algorithms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65942 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- It's due to the addition of C++14 constexpr throughout the library, the program works if preceded by #include bits/c++config.h #undef _GLIBCXX14_CONSTEXPR #define _GLIBCXX14_CONSTEXPR so that the newly-constexpr functions are not constexpr.
[Bug c++/65942] [5/6 Regression] [C++14] cannot use std::function as comparator in algorithms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65942
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Component|libstdc++ |c++
--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org ---
This seems to be a compiler bug not a library bug:
#include functional
bool cmp1(const int a, const int b) { return a b; }
std::functionbool (const int, const int) cmp2 = cmp1;
templatetypename _Compare
struct _Iter_comp_iter
{
_Compare _M_comp;
_Iter_comp_iter(_Compare __comp)
: _M_comp(__comp)
{ }
templatetypename _Iterator1, typename _Iterator2
#if __cplusplus = 201402L
constexpr
#endif
bool
operator()(_Iterator1 __it1, _Iterator2 __it2)
{ return bool(_M_comp(*__it1, *__it2)); }
};
templatetypename _Compare
inline _Iter_comp_iter_Compare
__iter_comp_iter(_Compare __comp)
{ return _Iter_comp_iter_Compare(__comp); }
int main() {
int v[1];
int* iter = v;
auto cmp = __iter_comp_iter(cmp2);
cmp(iter, iter);
}
[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697 --- Comment #48 from mwahab at gcc dot gnu.org --- (In reply to Andrew Macleod from comment #47) Created attachment 35425 [details] potential patch to add MEMMODEL_SYNC I don't know where we've finally settled on this, but I did prototype out what involved in adding a new MEMMODEL_SYNC which can be identified and made stronger than MEMMODEL_SEQ_CST if so desired. Normally it will behave exactly like MEMMODEL_SEQ_CST. This bootstraps on x86-64 with no testsuite regressions. I've been working on patches for this. Adding a new MEMMODEL type was my first approach because it means that gcc has one representation for all the memory models it supports. I decided not to submit the patch because Aarch64 also needs an tag for the __sync acquire used in __sync_lock_test_and_set. Adding that touches more backends than the MEMMODEL_SYNC and some of those changes are not obvious (for the mips backend in particular). The reasons why Aarch64 needs a new acquire barrier are rather tenuous (they're in the earlier comments) and don't seem to justify the possibly invasive changes that would be needed. The approach I'm working on now is to add a target hook to allow a backend to supply its own expansion of calls to the __sync builtins. That makes for smaller changes in the target-independent code and lets the Aarch64 backend add the new barriers as target-specific memory models. The actual code generation goes through the infrastructure for the atomics. Adding the __sync barriers to coretypes.h is the better approach if more than one backend has this problem. Since it seems that only Aarch64 is affected, I think its better to go with the target hook. If a new architecture gets added with the same problem, it will be easy enough to switch to the coretypes.h approach.
[Bug testsuite/65941] FAIL: g++.dg/other/pr59492.C: no such instruction: rdrand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65941 --- Comment #1 from vries at gcc dot gnu.org --- Fail in same testcase also observed at: https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg02807.html .
[Bug libstdc++/65942] New: cannot use std::function as comparator in algorithms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65942
Bug ID: 65942
Summary: cannot use std::function as comparator in algorithms
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
Target Milestone: ---
Too much template magic causes gcc 5.1 to reject the following valid code:
#include experimental/optional
#include algorithm
#include functional
using T1 = int;
using T2 = std::vectorT1;
bool cmp1(const T1 a, const T1 b) { return a b; }
std::functionbool (const T1, const T1) cmp2 = cmp1;
int main(int ac, char** av) {
T2 v;
std::sort(v.begin(), v.end(), cmp1); // works
std::sort(v.begin(), v.end(), cmp2); // fails
}
Even though the two calls to sort() should be identical, the second one does
not compile.
This is a regression from 4.9
[Bug c++/65943] New: template keyword required for base-specifier that names member of the current instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65943
Bug ID: 65943
Summary: template keyword required for base-specifier that
names member of the current instantiation
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
templateclass A struct X
{
templateclass B struct Base;
templateclass B struct Data;
};
templateclass A
templateclass B
struct XA::Data : XA::BaseB
{ };
This fails to compile:
f.cc:9:33: error: ‘typename XA::Base’ names ‘templateclass A templateclass
B struct XA::Base’, which is not a type
struct XA::Data : XA::BaseB
^
f.cc:9:27: error: ‘typename XA::Base’ names ‘templateclass A templateclass
B struct XA::Base’, which is not a type
struct XA::Data : XA::BaseB
^
f.cc:10:1: error: expected class-name before ‘{’ token
{ };
^
Clang and EDG accept it.
It compiles if the base-specifier is changed to XA::template BaseB, but I
think the addition of but the name is not a member of the current
instantiation to C++11 14.2 [temp.names] p4 should make it valid.
In any case, http://open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1710 will
definitely make it valid. See also
http://open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1812 and
http://open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#314
[Bug c++/59955] Segmentation fault on (re?)defining a struct template as function template, when inside a struct tempate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59955 --- Comment #6 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Thu Apr 30 09:04:04 2015 New Revision: 222612 URL: https://gcc.gnu.org/viewcvs?rev=222612root=gccview=rev Log: 2015-04-30 Paolo Carlini paolo.carl...@oracle.com PR c++/59955 * g++.dg/template/crash121.C: New. Added: trunk/gcc/testsuite/g++.dg/template/crash121.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/65935] [6 Regression] 433.milc in SPEC CPU 2006 is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65935 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- I suppose r222514.
[Bug testsuite/65939] New: gcc.dg/torture/tls/run-ld.c execution failures with -pie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65939 Bug ID: 65939 Summary: gcc.dg/torture/tls/run-ld.c execution failures with -pie Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- I observe these failures when testing on ubuntu 10.04.4, with unix/-m32: ... FAIL: gcc.dg/torture/tls/run-ld.c -O1 -pie -fPIE execution test FAIL: gcc.dg/torture/tls/run-ld.c -O1 -pie -fpie execution test FAIL: gcc.dg/torture/tls/run-ld.c -O2 -pie -fPIE execution test FAIL: gcc.dg/torture/tls/run-ld.c -O2 -pie -fpie execution test FAIL: gcc.dg/torture/tls/run-ld.c -O3 -fomit-frame-pointer -pie -fPIE execution test FAIL: gcc.dg/torture/tls/run-ld.c -O3 -fomit-frame-pointer -pie -fpie execution test FAIL: gcc.dg/torture/tls/run-ld.c -O3 -g -pie -fPIE execution test FAIL: gcc.dg/torture/tls/run-ld.c -O3 -g -pie -fpie execution test FAIL: gcc.dg/torture/tls/run-ld.c -Os -pie -fPIE execution test FAIL: gcc.dg/torture/tls/run-ld.c -Os -pie -fpie execution test ... Same set of failures can be seen at https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg02807.html . The tests pass without problem on ubuntu 14.04.2.
[Bug testsuite/65941] New: FAIL: g++.dg/other/pr59492.C: no such instruction: rdrand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65941 Bug ID: 65941 Summary: FAIL: g++.dg/other/pr59492.C: no such instruction: rdrand Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- gcc.sum (unix/-m32): ... FAIL: g++.dg/other/pr59492.C -std=gnu++11 (test for excess errors) FAIL: g++.dg/other/pr59492.C -std=gnu++14 (test for excess errors) FAIL: g++.dg/other/pr59492.C -std=gnu++98 (test for excess errors) ... g++.log: ... build/gcc/testsuite/g++1/../../xg++ -Bbuild/gcc/testsuite/g++1/../../ -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -Ibuild/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/x86_64-unknown-linux-gnu -Ibuild/x86_64-unknown-linux-gnu/32/libstdc++-v3/include -Isrc/libstdc++-v3/libsupc++ -Isrc/libstdc++-v3/include/backward -Isrc/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++98 -mx32 -fPIC -c -m32 -o pr59492.o src/gcc/testsuite/g++.dg/other/pr59492.C /tmp/ccSwV0hl.s: Assembler messages: /tmp/ccSwV0hl.s:24: Error: no such instruction: `rdrand %edx' compiler exited with status 1 FAIL: g++.dg/other/pr59492.C -std=gnu++98 (test for excess errors) ... as version: ... GNU assembler (GNU Binutils for Ubuntu) 2.20.1-system.20100303 ...
[Bug testsuite/65944] New: FAIL: g++.dg/lto/pr65276: undefined reference to std2::exception::~exception()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65944 Bug ID: 65944 Summary: FAIL: g++.dg/lto/pr65276: undefined reference to std2::exception::~exception() Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- g++.sum (unix/): ... FAIL: g++.dg/lto/pr65276 cp_lto_pr65276_0.o-cp_lto_pr65276_1.o link, -flto -O0 -std=c++11 ... g++.sum (unix/-m32): ... FAIL: g++.dg/lto/pr65276 cp_lto_pr65276_0.o-cp_lto_pr65276_1.o link, -flto -O0 -std=c++11 ... g++.log: ... build/gcc/testsuite/g++1/../../xg++ -Bbuild/gcc/testsuite/g++1/../../ cp_lto_pr65276_0.o cp_lto_pr65276_1.o -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -Ibuild/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -Ibuild/x86_64-unknown-linux-gnu/libstdc++-v3/include -Isrc/libstdc++-v3/libsupc++ -Isrc/libstdc++-v3/include/backward -Isrc/libstdc++-v3/testsuite/util -fmessage-length=0 -flto -O0 -std=c++11 -Lbuild/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs -Bbuild/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs -Lbuild/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs -o g++-dg-lto-pr65276-01.exe cp_lto_pr65276_1.o: In function `std2::runtime_error::~runtime_error()': pr65276_1.C:(.text._ZN4std213runtime_errorD2Ev[_ZN4std213runtime_errorD5Ev]+0x8): undefined reference to `std2::exception::~exception()' cp_lto_pr65276_1.o: In function `std2::runtime_error::~runtime_error()': pr65276_1.C:(.text._ZN4std213runtime_errorD0Ev[_ZN4std213runtime_errorD5Ev]+0xc): undefined reference to `std2::exception::~exception()' cp_lto_pr65276_1.o:(.rodata._ZTVN4std29exceptionE[_ZTVN4std29exceptionE]+0x10): undefined reference to `std2::exception::~exception()' cp_lto_pr65276_1.o:(.rodata._ZTVN4std29exceptionE[_ZTVN4std29exceptionE]+0x18): undefined reference to `std2::exception::~exception()' collect2: error: ld returned 1 exit status compiler exited with status 1 FAIL: g++.dg/lto/pr65276 cp_lto_pr65276_0.o-cp_lto_pr65276_1.o link, -flto -O0 -std=c++11 ... Fail in same testcase also observed at: https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg02807.html . as version: ... GNU assembler (GNU Binutils for Ubuntu) 2.20.1-system.20100303 ... ld version: ... GNU ld (GNU Binutils for Ubuntu) 2.20.1-system.20100303 ...
[Bug c++/59955] Segmentation fault on (re?)defining a struct template as function template, when inside a struct tempate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59955 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com --- Done.
[Bug testsuite/65938] New: FAIL: gcc.target/i386/pr56114.c: ambiguous operand size or operands invalid for movabs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65938 Bug ID: 65938 Summary: FAIL: gcc.target/i386/pr56114.c: ambiguous operand size or operands invalid for movabs Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- gcc.log: ... build/gcc/xgcc -Bbuild/gcc/ -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -masm=intel -c -o pr56114.o src/gcc/testsuite/gcc.target/i386/pr56114.c /tmp/ccAeR35Y.s: Assembler messages: /tmp/ccAeR35Y.s:13: Error: ambiguous operand size or operands invalid for `movabs' compiler exited with status 1 FAIL: gcc.target/i386/pr56114.c (test for excess errors) ... pr56114.s: ... .file pr56114.c .intel_syntax noprefix .section.text.unlikely,ax,@progbits .LCOLDB0: .text .LHOTB0: .p2align 4,,15 .globl foo2 .type foo2, @function foo2: .LFB0: .cfi_startproc movabs eax, [4276092928] cdqe ret .cfi_endproc .LFE0: .size foo2, .-foo2 .section.text.unlikely .LCOLDE0: .text .LHOTE0: .ident GCC: (GNU) 6.0.0 20150429 (experimental) .section.note.GNU-stack,,@progbits ... This test fails for me on ubuntu 10.04.4 with as: ... GNU assembler (GNU Binutils for Ubuntu) 2.20.1-system.20100303 ... It passes for me on ubuntu 14.04.2 with as: ... GNU assembler (GNU Binutils for Ubuntu) 2.24 ... The generated .s file is the same for both systems. Fail for same test-case mentioned in https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg02807.html .
[Bug c++/59955] Segmentation fault on (re?)defining a struct template as function template, when inside a struct tempate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59955 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- This is already fixed in mainline, I'm adding the testcase and closing the bug.
[Bug target/65937] New: FAIL: gcc.target/arm/pr26702.c scan-assembler \\.size[\\t ]+static_foo, 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65937 Bug ID: 65937 Summary: FAIL: gcc.target/arm/pr26702.c scan-assembler \\.size[\\t ]+static_foo, 4 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: amker at gcc dot gnu.org Target Milestone: --- Newly introduced test case failed on arm-none-linux-gnueabi/arm-none-linux-gnueabihf arm-none-linux-gnueabi GCC was configured with gcc/configure --target=arm-none-linux-gnueabi --prefix= --with-sysroot=/home/... --enable-shared --disable-libsanitizer --disable-libssp --disable-libmudflap --with-plugin-ld=arm-none-linux-gnueabi-ld --enable-checking=yes --enable-languages=c,c++,fortran --with-gmp=... --with-mpfr=... --with-mpc=... --with-isl=... --with-cloog=... --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=softfp --with-arch=armv7-a Thanks, bin
[Bug target/65408] powerpc64 function argument passing may access invalid memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65408 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- We've had some 15 days without any fallout noticed. Backporting this for GCC 5.2 now (or whenever it suits you) is pre-approved (even if it's not a regression).
[Bug target/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Target||arm-arm926ejs-linux-gnueabi Target Milestone|--- |5.2 Summary|[5.1 Regression]|[5 Regression] |Linux-3.10.75 on arm926ej-s |Linux-3.10.75 on arm926ej-s |does not boot due to wrong |does not boot due to wrong |code generation |code generation
[Bug target/58744] Illegal Memory Access on 3-byte packed struct ARCH: x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58744 Bug 58744 depends on bug 36043, which changed state. Bug 36043 Summary: gcc reads 8 bytes for a struct of size 6 which leads to sigsegv https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36043 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/65945] C++ alignment of nullptr_t is 1 and might cause unaligned stores to the frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65945 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-30 Ever confirmed|0 |1 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- The C++ ABI group are currently discussing alignof(nullptr) and have suggested it should be the same as alignof(void*) which should fix this issue.
[Bug c++/57610] Reference initialized with temporary instead of sub-object of conversion result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57610 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|paolo.carlini at oracle dot com| --- Comment #12 from Paolo Carlini paolo.carlini at oracle dot com --- This is fixed in 5.1. I'm adding a testcase and closing the bug.
[Bug c++/65942] [5/6 Regression] [C++14] cannot use std::function as comparator in algorithms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65942 --- Comment #6 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Avi Kivity from comment #5) That's clang + libstdc++-5.1, so if the problem is in libstdc++, it's the same bug. Yes. clang++ -stdlib=libc++ -std=gnu++14 original_testcase.cpp is also fine.
[Bug target/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-30 Ever confirmed|0 |1 --- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org --- The type of field_width is a signed short. On that basis, the use of LSR rather than ASR looks highly suspicious.
[Bug target/65408] powerpc64 function argument passing may access invalid memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65408 Bug 65408 depends on bug 36043, which changed state. Bug 36043 Summary: gcc reads 8 bytes for a struct of size 6 which leads to sigsegv https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36043 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/36043] gcc reads 8 bytes for a struct of size 6 which leads to sigsegv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36043 Alan Modra amodra at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.2 --- Comment #26 from Alan Modra amodra at gmail dot com --- Fixed for 5.2
[Bug target/58744] Illegal Memory Access on 3-byte packed struct ARCH: x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58744 Alan Modra amodra at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.2 --- Comment #6 from Alan Modra amodra at gmail dot com --- Fixed for 5.2
[Bug target/65408] powerpc64 function argument passing may access invalid memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65408 Alan Modra amodra at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.2 --- Comment #10 from Alan Modra amodra at gmail dot com --- Fixed for 5.2
[Bug target/37954] odd sized packed structures passed by value, under ARM, cause lockup of application
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37954 Bug 37954 depends on bug 36043, which changed state. Bug 36043 Summary: gcc reads 8 bytes for a struct of size 6 which leads to sigsegv https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36043 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/35226] Induction with multiplication are not vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35226
alalaw01 at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-04-30
CC||alalaw01 at gcc dot gnu.org
Version|4.3.0 |6.0
Summary|Reduction and induction |Induction with
|with multiplication are not |multiplication are not
|vectorized |vectorized
Ever confirmed|0 |1
--- Comment #1 from alalaw01 at gcc dot gnu.org ---
Multiplication reductions are supported, certainly in gcc 4.9, I think longer.
However, the following induction does not vectorize on gcc 6 development branch
(x86_64, -O3, with or without -mavx or -msse2):
int a[24];
int
main (int argc, char **argv)
{
int p = 1;
for (int i = 0; i 24; i++, p*=2)
a[i] *= p;
}
-fdump-tree-vect-details suggests the multiplication is recognized as a
reduction but not as an induction:
test_induc.c:7:3: note: Analyze phi: p_13 = PHI p_9(4), 1(2)
test_induc.c:7:3: note: reduction used in loop.
test_induc.c:7:3: note: Unknown def-use cycle pattern.
test_induc.c:7:3: note: === vect_pattern_recog ===
test_induc.c:7:3: note: vect_is_simple_use: operand _5
test_induc.c:7:3: note: def_stmt: _5 = a[i_14];
test_induc.c:7:3: note: type of def: 3.
test_induc.c:7:3: note: vect_is_simple_use: operand p_13
test_induc.c:7:3: note: def_stmt: p_13 = PHI p_9(4), 1(2)
test_induc.c:7:3: note: Unsupported pattern.
...
test_induc.c:7:3: note: def_stmt: p_13 = PHI p_9(4), 1(2)
test_induc.c:7:3: note: Unsupported pattern.
test_induc.c:7:3: note: not vectorized: unsupported use in stmt.
test_induc.c:7:3: note: unexpected pattern.
test_induc.c:4:1: note: vectorized 0 loops in function.
...
bb 3:
# p_13 = PHI p_9(4), 1(2)
...
p_9 = p_13 * 2;
[Bug c++/57610] Reference initialized with temporary instead of sub-object of conversion result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57610 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #14 from Paolo Carlini paolo.carlini at oracle dot com --- Done.
[Bug c++/57610] Reference initialized with temporary instead of sub-object of conversion result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57610 --- Comment #13 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Thu Apr 30 09:43:39 2015 New Revision: 222615 URL: https://gcc.gnu.org/viewcvs?rev=222615root=gccview=rev Log: 2015-04-30 Paolo Carlini paolo.carl...@oracle.com PR c++/57610 * g++.dg/init/ref22.C: New. Added: trunk/gcc/testsuite/g++.dg/init/ref22.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/65945] C++ alignment of nullptr_t is 1 and might cause unaligned stores to the frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65945 --- Comment #3 from npl at chello dot at --- I just checked the alignment of nullptr, and here seems to be the issue: the size of 4, while the alignment is 1. This will result in unaligned access should a nullptr be stored (storing a nullptr probably is a really useless thing, but it seems to happen) static_assert(std::alignment_ofdecltype(nullptr)::value == 4, oops);
[Bug target/59884] Unexpected warning pragma GCC target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59884 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Target||arm Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-30 CC||ramana at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01977.html are the seeds of fixing this. A lot more will be needed than this basic set of patches to support more of this. Christian Bruel is looking into this.
[Bug c++/65942] [5/6 Regression] [C++14] cannot use std::function as comparator in algorithms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65942 --- Comment #5 from Avi Kivity a...@cloudius-systems.com --- That's clang + libstdc++-5.1, so if the problem is in libstdc++, it's the same bug.
[Bug c++/65945] ARM: unaligned access when stroing nullptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65945 --- Comment #1 from npl at chello dot at --- Created attachment 35430 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35430action=edit disassembly showing the issue The issue is the line dc: e50b3019str r3, [fp, #-25] ; 0xffe7
[Bug c++/59873] The value of char32_t U'\u0000' and char16_t u'\u0000' is 1, instead of 0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59873 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #12 from Paolo Carlini paolo.carlini at oracle dot com --- Thanks Richard. *** This bug has been marked as a duplicate of bug 53690 ***
[Bug c++/65942] [5/6 Regression] [C++14] cannot use std::function as comparator in algorithms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65942
--- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org ---
Yes, and so do 4.8 and 4.9 for this reduced form with no library dependencies.
This fails with -std=c++11 but compiles OK with -std=c++11 -DOK.
EDG accepts it without -DOK
templatetypename _Tp
_Tp declval() noexcept;
templatetypename struct function;
templatetypename _Res, typename... _ArgTypes
struct function_Res(_ArgTypes...)
{
templatetypename _Functor,
typename = decltype( declval_Functor()(declval_ArgTypes()...)
)
function(_Functor) { }
function() { }
_Res operator()(_ArgTypes...) const;
};
templatetypename _Compare
struct _Iter_comp_iter
{
_Compare _M_comp;
_Iter_comp_iter(_Compare __comp)
: _M_comp(__comp)
{ }
templatetypename _Iterator1, typename _Iterator2
#ifndef OK
constexpr
#endif
bool
operator()(_Iterator1 __it1, _Iterator2 __it2)
{ return bool(_M_comp(*__it1, *__it2)); }
};
using F = functionbool (int, int);
F f;
_Iter_comp_iterF c{ f };
auto c2 = c;
f.cc: In instantiation of ‘constexpr bool
_Iter_comp_iter_Compare::operator()(_Iterator1, _Iterator2) const [with
_Iterator1 = int; _Iterator2 = int; _Compare = functionbool(int, int)]’:
f.cc:10:54: required by substitution of ‘templateclass _Functor, class
function_Res(_ArgTypes ...)::function(_Functor) [with _Functor =
_Iter_comp_iterfunctionbool(int, int) ; template-parameter-1-2 =
missing]’
f.cc:40:11: required from here
f.cc:34:31: error: invalid type argument of unary ‘*’ (have ‘int’)
{ return bool(_M_comp(*__it1, *__it2)); }
^
f.cc:34:39: error: invalid type argument of unary ‘*’ (have ‘int’)
{ return bool(_M_comp(*__it1, *__it2)); }
^
So the regression is in the library adding 'constexpr' to _Iter_comp_iter, not
a regression in the compiler, although the problem may be inherent to the
SFINAE constraints in std::function.
It seems that defining the implicit copy constructor of _Iter_comp_iter
performs overload resolution on the function(_Functor) constructor, which
checks the SFINAE constraint, which instantiates
_Iter_comp_iter::operator()int, int and that fails if it's constexpr, but
compiles OK otherwise.
[Bug c++/65942] [5/6 Regression] [C++14] cannot use std::function as comparator in algorithms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65942 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Jonathan Wakely from comment #7) Yes, and so do 4.8 and 4.9 That was in response to clang rejects your testcase, too.
[Bug c++/65945] New: ARM: unaligned access when stroing nullptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65945
Bug ID: 65945
Summary: ARM: unaligned access when stroing nullptr
Product: gcc
Version: 4.8.4
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: npl at chello dot at
Target Milestone: ---
Created attachment 35429
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35429action=edit
code causing the issue
Hello,
the attachedcode produces an unaligned access for arm, on the production code I
ran into this issue with versions 5.1, 4.9.2, 4.8.4. This reduced testcase
doesnt produce the issue with 5.1, but for 4.9.2 and 4.8.4.
The issue seems to be the line
constexpr inline_type bool operator ==(bitmask X, decltype(nullptr)) \
{ return X == bitmask(); }
aparrently gcc converts stores the given parameter on the frame without caring
for alignment (str r3, [fp, #-25]). changing the type to unsigned seems
to fix this
Commandline to reproduce:
arm-none-eabi-g++ -std=c++11 -O0 -c unalignedgcc.cpp
[Bug preprocessor/53690] [C++11] \u0000 and \U00000000 are wrongly encoded as U+0001.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53690 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||wjl at icecavern dot net --- Comment #7 from Paolo Carlini paolo.carlini at oracle dot com --- *** Bug 59873 has been marked as a duplicate of this bug. ***
[Bug middle-end/36043] gcc reads 8 bytes for a struct of size 6 which leads to sigsegv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36043 --- Comment #27 from John Dallman john.dallman at siemens dot com --- Thanks!
[Bug testsuite/65944] FAIL: g++.dg/lto/pr65276: undefined reference to std2::exception::~exception()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65944 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- The testcase is about not ICEing - eventually adding -nostdlib -r will still reproduce the original issue. Otherwise the fix is to properly complete the header parts of std::exception, maybe simply by including the appropriate headers.
[Bug c++/65945] ARM: unaligned access when stroing nullptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65945 --- Comment #2 from npl at chello dot at --- Well, gcc 5.1 seems to reproduceable aswell, I just looked at the wrong line. There are 3 stores of the implicitely converted nullptr, gcc 4.8.4, gcc 4.9.2 and gcc 5.1 all produce one unaligned store - just in different places
[Bug libstdc++/65942] [5/6 Regression] [C++14] cannot use std::function as comparator in algorithms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65942
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Component|c++ |libstdc++
--- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org ---
Further reduced:
templatetypename _Tp
_Tp declval() noexcept;
templatetypename Arg
struct function
{
templatetypename Functor,
typename = decltype( declvalFunctor()(declvalArg()) )
function(Functor) { }
function() { }
bool operator()(Arg) const;
};
templatetypename Compare
struct Iter_comp
{
Compare m_comp;
Iter_comp(Compare comp)
: m_comp(comp)
{ }
templatetypename Iterator
#ifndef OK
constexpr
#endif
bool
operator()(Iterator it) const
{ return m_comp(*it); }
};
using F = functionint;
F f;
Iter_compF c{ f };
auto c2 = c;
GCC says:
f.cc: In instantiation of ‘constexpr bool
Iter_compCompare::operator()(Iterator) const [with Iterator = int; Compare =
functionint]’:
f.cc:8:52: required by substitution of ‘templateclass Functor, class
functionArg::function(Functor) [with Functor = Iter_compfunctionint ;
template-parameter-1-2 = missing]’
f.cc:38:11: required from here
f.cc:32:23: error: invalid type argument of unary ‘*’ (have ‘int’)
{ return m_comp(*it); }
^
and Clang says:
f.cc:32:23: error: indirection requires pointer operand ('int' invalid)
{ return m_comp(*it); }
^~~
f.cc:8:35: note: in instantiation of function template specialization
'Iter_compfunctionint ::operator()int' requested here
typename = decltype( declvalFunctor()(declvalArg()) )
^
f.cc:9:7: note: in instantiation of default argument for
'functionIter_compfunctionint ' required here
function(Functor) { }
^~~~
f.cc:38:11: note: while substituting deduced template arguments into function
template 'function' [with Functor = Iter_compfunctionint , $1 = (no value)]
auto c2 = c;
^
1 error generated.
What I don't understand is why functionint::functionComp_iterfunctionint
ever gets considered for overload resolution. Where does that come from and
why?
Anyway, it seems we can fix the library by constraining
_Iter_comp_iter::operator()
templatetypename Iterator, typename =
decltype(declvalCompare()(*declvalIterator()))
#ifndef OK
constexpr
#endif
bool
operator()(Iterator it) const
{ return m_comp(*it); }
That prevents it being instantiated as a possible argument to std::function.
Changing component back to libstdc++
[Bug middle-end/36043] gcc reads 8 bytes for a struct of size 6 which leads to sigsegv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36043 --- Comment #25 from Alan Modra amodra at gcc dot gnu.org --- Author: amodra Date: Thu Apr 30 11:11:34 2015 New Revision: 222616 URL: https://gcc.gnu.org/viewcvs?rev=222616root=gccview=rev Log: gcc/ PR target/65408 PR target/58744 PR middle-end/36043 * calls.c (load_register_parameters): Don't load past end of mem unless suitably aligned. gcc/testsuite/ * gcc.dg/pr65408.c: New. Added: branches/gcc-5-branch/gcc/testsuite/gcc.dg/pr65408.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/calls.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug target/65408] powerpc64 function argument passing may access invalid memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65408 --- Comment #9 from Alan Modra amodra at gcc dot gnu.org --- Author: amodra Date: Thu Apr 30 11:11:34 2015 New Revision: 222616 URL: https://gcc.gnu.org/viewcvs?rev=222616root=gccview=rev Log: gcc/ PR target/65408 PR target/58744 PR middle-end/36043 * calls.c (load_register_parameters): Don't load past end of mem unless suitably aligned. gcc/testsuite/ * gcc.dg/pr65408.c: New. Added: branches/gcc-5-branch/gcc/testsuite/gcc.dg/pr65408.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/calls.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug target/58744] Illegal Memory Access on 3-byte packed struct ARCH: x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58744 --- Comment #5 from Alan Modra amodra at gcc dot gnu.org --- Author: amodra Date: Thu Apr 30 11:11:34 2015 New Revision: 222616 URL: https://gcc.gnu.org/viewcvs?rev=222616root=gccview=rev Log: gcc/ PR target/65408 PR target/58744 PR middle-end/36043 * calls.c (load_register_parameters): Don't load past end of mem unless suitably aligned. gcc/testsuite/ * gcc.dg/pr65408.c: New. Added: branches/gcc-5-branch/gcc/testsuite/gcc.dg/pr65408.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/calls.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/65935] [6 Regression] 433.milc in SPEC CPU 2006 is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65935 --- Comment #4 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Richard Biener from comment #3) I suppose r222514. Yes, it is.
[Bug tree-optimization/65948] New: [6 Regression] FAIL: g++.dg/lto/20101010-4 cp_lto_20101010-4_0.o-cp_lto_20101010-4_0.o link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65948 Bug ID: 65948 Summary: [6 Regression] FAIL: g++.dg/lto/20101010-4 cp_lto_20101010-4_0.o-cp_lto_20101010-4_0.o link Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: hubicka at ucw dot cz Target Milestone: --- On Linux/x86, r222609 caused: FAIL: g++.dg/lto/20101010-4 cp_lto_20101010-4_0.o-cp_lto_20101010-4_0.o link, -std=c++0x -flto -g -r -nostdlib (internal compiler error) FAIL: g++.dg/lto/20101010-4 cp_lto_20101010-4_0.o-cp_lto_20101010-4_0.o link, -std=c++0x -flto -r -nostdlib (internal compiler error)
[Bug tree-optimization/65935] [6 Regression] 433.milc in SPEC CPU 2006 is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65935 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Also reproduces with -Ofast -march=bdver2 -m32 so I suppose -O3 -ffast-math -m32 -msse2 should also reproduce it. I wont get to look into this before Monday, any help in bisecting (-fno-tree-vectorize for which file(s) fix it? for which function?) appreciated until then. At least milc is C and not too big ;)
[Bug tree-optimization/65935] [6 Regression] 433.milc in SPEC CPU 2006 is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65935 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org
[Bug lto/65559] [5/6 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559
--- Comment #20 from Rainer Emrich rai...@emrich-ebersheim.de ---
Kai,
(In reply to Kai Tietz from comment #18)
Does the following patch fixes your problem?
Index: lto-wrapper.c
===
--- lto-wrapper.c (Revision 69)
+++ lto-wrapper.c (Arbeitskopie)
@@ -934,7 +934,7 @@ run_gcc (unsigned argc, char *argv[])
filename[p - argv[i]] = '\0';
file_offset = (off_t) loffset;
}
- fd = open (argv[i], O_RDONLY);
+ fd = open (argv[i], O_RDONLY|O_BINARY);
if (fd == -1)
{
lto_argv[lto_argc++] = argv[i];
the following as Matt suggested
Index: lto-wrapper.c
===
--- lto-wrapper.c (Revision 222611)
+++ lto-wrapper.c (Arbeitskopie)
@@ -934,7 +934,7 @@ run_gcc (unsigned argc, char *argv[])
filename[p - argv[i]] = '\0';
file_offset = (off_t) loffset;
}
- fd = open (argv[i], O_RDONLY);
+ fd = open (filename, O_RDONLY|O_BINARY);
if (fd == -1)
{
lto_argv[lto_argc++] = argv[i];
fixes the issue and not only this.
I did a full native x86_64-w64-mingw32 bootstrap for c,c++ and ran the
testsuite. A quick inspection shows that most lto failures are gone.
gcc-5.1.0
=== gcc Summary ===
# of expected passes106113
# of unexpected failures1809
# of unexpected successes 20
# of expected failures 282
# of unresolved testcases 1242
# of unsupported tests 1940
gcc-5.1.1 revision 222611 patch applied
=== gcc Summary ===
# of expected passes108435
# of unexpected failures839
# of unexpected successes 21
# of expected failures 283
# of unresolved testcases 21
# of unsupported tests 1907
I have to look at the related PRs still.
I can't test on Linux at the moment. Has somebody the time to do a regression
test for the patch on Linux? Kai?
[Bug middle-end/65946] New: Simple loop with if-statement not vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65946
Bug ID: 65946
Summary: Simple loop with if-statement not vectorized
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: alalaw01 at gcc dot gnu.org
Target Milestone: ---
Target: x86_64
This testcase:
#define N 32
int a[N], b[N];
int
foo ()
{
for (int i = 0; i N ; i++)
{
int m = (a[i] i) ? 5 : 4;
b[i] = a[i] * m;
}
}
does not vectorize at -O3 on x86_64 or other platforms. Following dom1, jump
threading partially peels the loop to give:
bb 2:
goto bb 8;
bb 3:
# i_11 = PHI i_9(6)
_5 = a[i_11];
_6 = i_11 _5;
if (_6 != 0)
goto bb 4;
else
goto bb 5;
bb 4:
bb 5:
# m_14 = PHI 5(4), 4(3)
bb 6:
# m_2 = PHI m_14(5), 4(8)
# _15 = PHI _5(5), _10(8)
# i_16 = PHI i_11(5), i_1(8)
_7 = m_2 * _15;
b[i_16] = _7;
i_9 = i_16 + 1;
if (i_9 != 32)
goto bb 3;
else
goto bb 7;
bb 7:
return;
bb 8:
# i_1 = PHI 0(2)
_10 = a[i_1];
_3 = i_1 _10;
goto bb 6;
which form cannot be if-converted (tree-if-conv.c):
/* If one of the loop header's edge is an exit edge then do not
apply if-conversion. */
FOR_EACH_EDGE (e, ei, loop-header-succs)
if (loop_exit_edge_p (loop, e))
return false;
and even if it were, the PHI nodes at loop entry cannot be handled by the
vectorizer.
[Bug testsuite/65205] Wrong dg-shouldfail usage in OpenACC libgomp tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65205 --- Comment #2 from Thomas Schwinge tschwinge at gcc dot gnu.org --- Author: tschwinge Date: Thu Apr 30 12:44:39 2015 New Revision: 222620 URL: https://gcc.gnu.org/viewcvs?rev=222620root=gccview=rev Log: [PR testsuite/65205] Fix dg-shouldfail usage in OpenACC libgomp tests PR testsuite/65205 libgomp/ * testsuite/lib/libgomp.exp (check_effective_target_openacc_host_selected) (check_effective_target_openacc_host_nonshm_selected): New procedures. * testsuite/libgomp.oacc-c-c++-common/clauses-2.c: Fix misuse of dg-shouldfail. * testsuite/libgomp.oacc-c-c++-common/lib-1.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-11.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-16.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-17.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-18.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-2.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-20.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-21.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-22.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-23.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-25.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-26.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-27.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-28.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-29.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-3.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-30.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-34.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-35.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-36.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-39.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-4.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-40.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-42.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-43.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-44.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-47.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-48.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-52.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-53.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-54.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-57.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-58.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-62.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-63.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-64.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-65.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-67.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-68.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-71.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-77.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/lib-80.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/present-1.c: Likewise. Modified: trunk/libgomp/ChangeLog trunk/libgomp/testsuite/lib/libgomp.exp trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/clauses-2.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-1.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-11.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-16.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-17.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-18.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-2.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-20.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-21.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-22.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-23.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-25.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-26.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-27.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-28.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-29.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-3.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-30.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-34.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-35.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-36.c trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-39.c
[Bug testsuite/65205] Wrong dg-shouldfail usage in OpenACC libgomp tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65205 Thomas Schwinge tschwinge at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|jnorris at gcc dot gnu.org |tschwinge at gcc dot gnu.org --- Comment #3 from Thomas Schwinge tschwinge at gcc dot gnu.org --- Applied Jim's patch in r222620.
[Bug middle-end/65946] Simple loop with if-statement not vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65946 alalaw01 at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-04-30 Assignee|unassigned at gcc dot gnu.org |alalaw01 at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from alalaw01 at gcc dot gnu.org --- Discussion here: https://gcc.gnu.org/ml/gcc/2015-04/msg00351.html Suggestion is to use loop-header-copying to rotate the loop to a form that both if-conversion and the vectorizer can handle.
[Bug middle-end/65947] New: Vectorizer misses conditional assignment of constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65947
Bug ID: 65947
Summary: Vectorizer misses conditional assignment of constant
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: alalaw01 at gcc dot gnu.org
Target Milestone: ---
This testcase:
int a[32];
int main(int argc, char **argv)
{
int res = 3;
for (int i = 0; i 32; i++)
if (a[i]) res = 7;
return res;
}
does not vectorize at -O3 on x86_64 or aarch64. tree-if-conversion succeeds,
giving a loop of form:
bb 3:
# res_10 = PHI res_1(4), 3(2)
# i_11 = PHI i_6(4), 0(2)
# ivtmp_9 = PHI ivtmp_2(4), 32(2)
_5 = a[i_11];
res_1 = _5 != 0 ? 7 : res_10;
i_6 = i_11 + 1;
ivtmp_2 = ivtmp_9 - 1;
if (ivtmp_2 != 0)
goto bb 4;
else
goto bb 5;
bb 4:
goto bb 3;
but -fdump-tree-vect-details shows:
test.c:9:3: note: Analyze phi: res_10 = PHI res_1(4), 3(2)
test.c:9:3: note: reduction: not commutative/associative: res_1 = _5 != 0 ? 7 :
res_10;
test.c:9:3: note: Unknown def-use cycle pattern.
...
test.c:9:3: note: vect_is_simple_use: operand res_10
test.c:9:3: note: def_stmt: res_10 = PHI res_1(4), 3(2)
test.c:9:3: note: Unsupported pattern.
test.c:9:3: note: not vectorized: unsupported use in stmt.
test.c:9:3: note: unexpected pattern.
[Bug tree-optimization/65948] [6 Regression] FAIL: g++.dg/lto/20101010-4 cp_lto_20101010-4_0.o-cp_lto_20101010-4_0.o link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65948 --- Comment #1 from Jan Hubicka hubicka at gcc dot gnu.org --- Author: hubicka Date: Thu Apr 30 13:18:22 2015 New Revision: 222621 URL: https://gcc.gnu.org/viewcvs?rev=222621root=gccview=rev Log: PR lto/65948 * ipa-devirt.c (odr_types_equivalent_p): NULLPTR_TYPE is equivalent to itself. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-devirt.c
[Bug middle-end/65874] [5 Regression] bootstrap comparison failure (gcc/ira.o) on ia64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65874 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Do you get a -fcompare-debug failure if you compile ira.c with the stage3 options and -fcompare-debug? Similarly if compiled with stage1 compiler? If so, can you attach preprocessed source for ira.c, perhaps it can be reproduced even with a cross-compiler?
[Bug middle-end/65947] Vectorizer misses conditional assignment of constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65947 alalaw01 at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-04-30 Assignee|unassigned at gcc dot gnu.org |alalaw01 at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from alalaw01 at gcc dot gnu.org --- Of course, the conditional assignment _is_ commutative and associative (wrt reordering iterations).
[Bug tree-optimization/65948] [6 Regression] FAIL: g++.dg/lto/20101010-4 cp_lto_20101010-4_0.o-cp_lto_20101010-4_0.o link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65948 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC|hubicka at ucw dot cz |hubicka at gcc dot gnu.org Target Milestone|--- |6.0
[Bug c++/65942] [5/6 Regression] [C++14] cannot use std::function as comparator in algorithms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65942
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
--- Comment #4 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
Well, clang rejects your testcase, too.
test2.cpp:20:31: error: indirection requires pointer operand ('int' invalid)
{ return bool(_M_comp(*__it1, *__it2)); }
^~
/usr/lib64/gcc/x86_64-pc-linux-gnu/5.1.1/include/g++-v5/functional:1981:27:
note: in instantiation of function template specialization
'_Iter_comp_iterstd::functionbool
(const int , const int ) ::operator()int, int' requested here
using _Invoke = decltype(__callable_functor(std::declval_Functor())
^
/usr/lib64/gcc/x86_64-pc-linux-gnu/5.1.1/include/g++-v5/functional:1990:2:
note: in instantiation of template type alias '_Invoke' requested here
using _Callable
^
/usr/lib64/gcc/x86_64-pc-linux-gnu/5.1.1/include/g++-v5/functional:2057:30:
note: in instantiation of template type alias '_Callable' requested here
typename = _Requires_Callable_Functor, void
^
/usr/lib64/gcc/x86_64-pc-linux-gnu/5.1.1/include/g++-v5/functional:2058:2:
note: in instantiation of default argument for
'function_Iter_comp_iterstd::functionbool
(const int , const int ) ' required here
function(_Functor);
^~~~
test2.cpp:31:14: note: while substituting deduced template arguments into
function template 'function' [with _Functor =
_Iter_comp_iterstd::functionbool
(const int , const int ) , $1 = (no value)]
auto cmp = __iter_comp_iter(cmp2);
^
1 error generated.
[Bug middle-end/64729] gcc.dg/stackprotectexplicit1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64729 --- Comment #2 from Rainer Orth ro at gcc dot gnu.org --- Author: ro Date: Thu Apr 30 14:50:26 2015 New Revision: 222631 URL: https://gcc.gnu.org/viewcvs?rev=222631root=gccview=rev Log: Add missing PR middle-end/64729 reference. Modified: trunk/gcc/ChangeLog
[Bug ada/65476] Long_Float array does not byte-swap correctly with reverse Scalar_Storage_Order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65476 --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Author: ebotcazou Date: Thu Apr 30 15:01:49 2015 New Revision: 222633 URL: https://gcc.gnu.org/viewcvs?rev=222633root=gccview=rev Log: PR ada/65476 * fold-const.c (native_encode_int): Revert all changes. (native_encode_real): Likewise. (native_encode_fixed): Likewise. (native_encode_complex): Likewise. (native_encode_vector): Likewise. (native_encode_expr): Likewise. (fold_flip_storage_order): Delete. (fold_view_convert_expr): Adjust call to native_encode_expr. (fold_ternary_loc): Adjust call to native_encode_expr. * fold-const.h (native_encode_expr): Adjust back prototype. (fold_flip_storage_order): Delete. * dwarf2out.c (native_encode_initializer): Adjust. * output.h (assemble_real): Adjust prototype. * varasm.c (assemble_real): Add REVERSE parameter. Flip the storage order of the value if REVERSE is true. (output_constant_pool_2): Adjust call to assemble_real. (output_constant) INTEGER_TYPE: Adjust. REAL_TYPE: Adjust call to assemble_real. * config/arm/arm.md (consttable_4): Adjust call to assemble_real. (consttable_8): Likewise. (consttable_16): Likewise. * config/mips/mips.md (consttable_float): Likewise. * config/s390/s390.c (s390_output_pool_entry): Likewise. * config/sh/sh.md (consttable_sf): Likewise. (consttable_df): Likewise. testsuite/ * c-c++-common/sso/init9.h: New. * c-c++-common/sso/p9.c: Likewise. * c-c++-common/sso/q9.c: Likewise. * c-c++-common/sso/t9.c: Likewise. * gnat.dg/sso: Adjust. Added: branches/scalar-storage-order/gcc/testsuite/c-c++-common/sso/init9.h branches/scalar-storage-order/gcc/testsuite/c-c++-common/sso/p9.c branches/scalar-storage-order/gcc/testsuite/c-c++-common/sso/q9.c branches/scalar-storage-order/gcc/testsuite/c-c++-common/sso/t9.c branches/scalar-storage-order/gcc/testsuite/gnat.dg/sso/init11.ads branches/scalar-storage-order/gcc/testsuite/gnat.dg/sso/p11.adb branches/scalar-storage-order/gcc/testsuite/gnat.dg/sso/q11.adb branches/scalar-storage-order/gcc/testsuite/gnat.dg/sso/r11.adb branches/scalar-storage-order/gcc/testsuite/gnat.dg/sso/s11.adb branches/scalar-storage-order/gcc/testsuite/gnat.dg/sso/t11.adb branches/scalar-storage-order/gcc/testsuite/gnat.dg/sso/u11.adb Removed: branches/scalar-storage-order/gcc/testsuite/gnat.dg/sso/r10.adb branches/scalar-storage-order/gcc/testsuite/gnat.dg/sso/s10.adb branches/scalar-storage-order/gcc/testsuite/gnat.dg/sso/u10.adb Modified: branches/scalar-storage-order/gcc/config/arm/arm.md branches/scalar-storage-order/gcc/config/mips/mips.md branches/scalar-storage-order/gcc/config/s390/s390.c branches/scalar-storage-order/gcc/config/sh/sh.md branches/scalar-storage-order/gcc/dwarf2out.c branches/scalar-storage-order/gcc/fold-const.c branches/scalar-storage-order/gcc/fold-const.h branches/scalar-storage-order/gcc/output.h branches/scalar-storage-order/gcc/testsuite/gnat.dg/sso/init10.ads branches/scalar-storage-order/gcc/testsuite/gnat.dg/sso/init9.ads branches/scalar-storage-order/gcc/testsuite/gnat.dg/sso/p10.adb branches/scalar-storage-order/gcc/testsuite/gnat.dg/sso/p9.adb branches/scalar-storage-order/gcc/testsuite/gnat.dg/sso/q1.adb branches/scalar-storage-order/gcc/testsuite/gnat.dg/sso/q10.adb branches/scalar-storage-order/gcc/testsuite/gnat.dg/sso/q2.adb branches/scalar-storage-order/gcc/testsuite/gnat.dg/sso/q3.adb branches/scalar-storage-order/gcc/testsuite/gnat.dg/sso/q4.adb branches/scalar-storage-order/gcc/testsuite/gnat.dg/sso/q5.adb branches/scalar-storage-order/gcc/testsuite/gnat.dg/sso/q6.adb branches/scalar-storage-order/gcc/testsuite/gnat.dg/sso/q7.adb branches/scalar-storage-order/gcc/testsuite/gnat.dg/sso/q8.adb branches/scalar-storage-order/gcc/testsuite/gnat.dg/sso/q9.adb branches/scalar-storage-order/gcc/testsuite/gnat.dg/sso/t10.adb branches/scalar-storage-order/gcc/testsuite/gnat.dg/sso/t9.adb branches/scalar-storage-order/gcc/varasm.c
[Bug ada/65476] Long_Float array does not byte-swap correctly with reverse Scalar_Storage_Order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65476 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Fixed on the branch.
[Bug c++/65949] New: Compiler can not deduce auto type in lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65949
Bug ID: 65949
Summary: Compiler can not deduce auto type in lambda
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: c.coque at hotmail dot fr
Target Milestone: ---
Created attachment 35431
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35431action=edit
The attachment contains the code which produce the erorrs described on the
comment
#Environment
http://gcc.godbolt.org/ with x86 gcc 5.1.0
#Result of gcc -v
gcc version 5.1.0 (GCC-Explorer)
Target: x86_64-linux-gnu
GNU C++14 (GCC-Explorer) version 5.1.0 (x86_64-linux-gnu)
compiled by GNU C version 5.1.0,
GMP version 4.3.2,
MPFR version 2.4.2, MPC version 0.8.1
#Compiled with option
-std=c++14
#The output :
error: unable to deduce 'std::initializer_listauto'
from 'brace-enclosed initializer list()'
at line :
auto list = {args...};
error: unable to deduce 'auto' from 'list'
for(auto a : list)
The code compiled fine with clang 3.7.
The aim of the code is to provide a way to overload lambda.
[Bug lto/65559] [5/6 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559
--- Comment #25 from Rainer Emrich rai...@emrich-ebersheim.de ---
(In reply to Richard Biener from comment #24)
Note that the issue should only cause option merging to be skipped for files
in archives (and that, too, on x86_64-linux). Though compared to the 4.9
branch
we do
fd = open (argv[i], O_RDONLY);
if (fd == -1)
{
lto_argv[lto_argc++] = argv[i];
continue;
}
vs.
fd = open (argv[i], O_RDONLY);
if (fd == -1)
continue;
so we add the file to later processing even if we failed to open it. Thus,
does removing _that_ also fix the issue?
Native bootstrap for c,c++ started on x86_64-w64-mingw32. I will run the
testsuite afterwards. Results expected in about 4 hours.
[Bug lto/65559] [5/6 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559 --- Comment #23 from Richard Biener rguenth at gcc dot gnu.org --- The patch looks pretty obvious to me - though I wonder if archives still work on x86_64-linux after it (or rather I wonder how they worked before...). I'm not aware of @ doing any magic for filenames - do they? So - please test this with boostrap-lto on x86_64-linux as well.
[Bug target/65582] [5/6 Regression] testsuite lto issue: xgcc.exe: warning: '-x lto' after last input file has no effect, fatal error: no input files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65582 Rainer Emrich rai...@emrich-ebersheim.de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #8 from Rainer Emrich rai...@emrich-ebersheim.de --- The patch proposed in PR65559 solves this issue too. *** This bug has been marked as a duplicate of bug 65559 ***
[Bug web/64968] Upgrade GCC Bugzilla to 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968 --- Comment #27 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Path: news.gmane.org!not-for-mail From: rai...@emrich-ebersheim.de gcc-bugzi...@gcc.gnu.org Newsgroups: gmane.comp.gcc.bugs Subject: [Bug lto/65559] [5/6 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947 Date: Thu, 30 Apr 2015 08:15:19 + Lines: 5 Approved: n...@gmane.org Message-ID: bug-65559-4-j1ukby4...@http.gcc.gnu.org/bugzilla/ References: bug-6555...@http.gcc.gnu.org/bugzilla/ NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1430401548 13250 80.91.229.3 (30 Apr 2015 13:45:48 GMT) X-Complaints-To: use...@ger.gmane.org NNTP-Posting-Date: Thu, 30 Apr 2015 13:45:48 + (UTC) To: gcc-bugs@gcc.gnu.org Original-X-From: gcc-bugs-return-485090-gcgb-bugs-2=m.gmane@gcc.gnu.org Thu Apr 30 15:45:36 2015 Return-path: gcc-bugs-return-485090-gcgb-bugs-2=m.gmane@gcc.gnu.org Envelope-to: gcgb-bug...@plane.gmane.org Original-Received: from server1.sourceware.org ([209.132.180.131] helo=sourceware.org) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from gcc-bugs-return-485090-gcgb-bugs-2=m.gmane@gcc.gnu.org) id 1YnomS-0003mR-Bh for gcgb-bug...@plane.gmane.org; Thu, 30 Apr 2015 15:45:32 +0200 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:subject:date:message-id:in-reply-to:references:content-type :content-transfer-encoding:mime-version; q=dns; s=default; b=nwh sN0PU7kTVYuR/f2t2lwRUUHnk7oxYgHMabZP3BkhDNkgbp57w4v8ushqSu24R/zO /oyUAJ6bDzcydlZJXNSf07CpMFrSZx+Y+HERUHtgrvtag9JOnBnMEIL6fmjLBpcX hB7WrLxwQxpyVIeq3jI9X/0CRms5sy3U2+YapPfA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:subject:date:message-id:in-reply-to:references:content-type :content-transfer-encoding:mime-version; s=default; bh=IQ0EMBz10 AKx1Kp1vnG6OLkLCuk=; b=S1iT7TV03c/1TA7o1PCMMX4pfYprYla5bfJ1hPPH7 IWH3c57//j9D7bKEaJzvl9CcYcosCkFoR+sRsOKdxq1+KjQSSOpIEefIcosn1cen WAqelyk+laOX72lRNHpr1i3CP7g9bgpCU9dlBJsJJ8QJEo89jWqjfBVOYPZwAUI4 5w= Original-Received: (qmail 103939 invoked by alias); 30 Apr 2015 13:45:24 - Mailing-List: contact gcc-bugs-h...@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: gcc-bugs.gcc.gnu.org List-Unsubscribe: mailto:gcc-bugs-unsubscribe-gcgb-bugs-2=m.gmane@gcc.gnu.org List-Archive: http://gcc.gnu.org/ml/gcc-bugs/ List-Post: mailto:gcc-bugs@gcc.gnu.org List-Help: mailto:gcc-bugs-h...@gcc.gnu.org Original-Sender: gcc-bugs-ow...@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Original-Received: (qmail 103859 invoked by uid 48); 30 Apr 2015 13:45:21 - X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: lto
[Bug c++/65945] C++ alignment of nullptr_t is 1 and might cause unaligned stores to the frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65945 --- Comment #5 from npl at chello dot at --- making nullptr_t similar to void* would sound very reasonable to me. I tested clang and it seems to behave that way. Whatever the C++ ABI group comes up with, the unaligned accesses have to be fixed. This was really annoying to track down, as the stores will only be generated without optimizations - in other words I was searching for a completely different bug. I searched the bug database and supposedly throwing and catching nullptr`s is something legal. So you will have to correctly align it anyway, even if its arguable if nullptrs should ever be explicitly stored.
[Bug lto/65559] [5/6 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559
--- Comment #22 from Kai Tietz ktietz at gcc dot gnu.org ---
I will be able to test this tomorrow (or this evening) for a linux bootstrap.
Patch tested is:
Index: lto-wrapper.c
===
--- lto-wrapper.c (Revision 69)
+++ lto-wrapper.c (Arbeitskopie)
@@ -934,7 +934,7 @@ run_gcc (unsigned argc, char *argv[])
filename[p - argv[i]] = '\0';
file_offset = (off_t) loffset;
}
- fd = open (argv[i], O_RDONLY);
+ fd = open (filename, O_RDONLY | O_BINARY);
if (fd == -1)
{
lto_argv[lto_argc++] = argv[i];
Honza, Jakub, when regression-test passes is it ok to apply?
The O_BINARY change is pretty obvious, but the filename vs argv[i] change
should indeed affect other targets using the @n decoration, too.
[Bug c++/65876] [5/6 Regression] [C++11] ICE in cxx_eval_call_expression, at cp/constexpr.c:1358
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65876 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Thu Apr 30 14:19:24 2015 New Revision: 222628 URL: https://gcc.gnu.org/viewcvs?rev=222628root=gccview=rev Log: PR c++/65876 * constexpr.c (cxx_eval_call_expression): Fail gracefully if cgraph threw away DECL_SAVED_TREE. Added: branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-array12.C Modified: branches/gcc-5-branch/gcc/cp/ChangeLog branches/gcc-5-branch/gcc/cp/constexpr.c
[Bug lto/65559] [5/6 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559
--- Comment #24 from Richard Biener rguenth at gcc dot gnu.org ---
Note that the issue should only cause option merging to be skipped for files in
archives (and that, too, on x86_64-linux). Though compared to the 4.9 branch
we do
fd = open (argv[i], O_RDONLY);
if (fd == -1)
{
lto_argv[lto_argc++] = argv[i];
continue;
}
vs.
fd = open (argv[i], O_RDONLY);
if (fd == -1)
continue;
so we add the file to later processing even if we failed to open it. Thus,
does removing _that_ also fix the issue?
[Bug target/64835] -fno-ipa-cp is inconsitently supported when attributes optimize or target are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64835
--- Comment #5 from chrbr at gcc dot gnu.org ---
(In reply to Martin Jambor from comment #1)
The problem is that in the testcase iinline-1.c as it is in the
testsuite, we use -fno-ipa-cp on the command line so that the
interprocedural phase of IPA-CP is not run so that it does not
interfere with the interprocedural stage of inlining, which however
uses information gathered by the function body analysis of ipa-prop
(which is invoked by both IPA-CP and inlining). However, when we
inspect the function specific optimizations in ipa-prop at this stage,
we bail out if we see -fno-ipa-cp.
So yes, there is a clear inconsistency, but at the same time, having
the ability to switch off only the interprocedural part of IPA-CP is
extremely convenient for testing how the inliner uses jump functions
and other stuff gathered by ipa-prop. I'll try to come up with some
fix.
Hi Martin,
back to fixing this problem, after the initial set of patch I think the
function
static bool
ipa_func_spec_opts_forbid_analysis_p (struct cgraph_node *node)
{
tree fs_opts = DECL_FUNCTION_SPECIFIC_OPTIMIZATION (node-decl);
if (!fs_opts)
return false;
return !opt_for_fn (node-decl, optimize) || !opt_for_fn (node-decl,
flag_ipa_cp);
}
should always return false, and have a coherent analysis between global
optimizations and function specific optimizations, now that the ipa-inline
checks are fixed.
so testing this. seems to fix the testcase at first sight.
[Bug c++/65945] C++ alignment of nullptr_t is 1 and might cause unaligned stores to the frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65945 --- Comment #7 from Andrew Pinski pinskia at gcc dot gnu.org --- How did you configure your gcc? If it is configured for armv7 or above, gcc defaults to assuming unaligned accesses can be done. This is a faq.
[Bug lto/65559] [5/6 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559 --- Comment #21 from Rainer Emrich rai...@emrich-ebersheim.de --- *** Bug 65582 has been marked as a duplicate of this bug. ***
[Bug target/64835] -fno-ipa-cp is inconsitently supported when attributes optimize or target are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64835 --- Comment #4 from chrbr at gcc dot gnu.org --- yes, I thought that this test was target independent. tested on x86, arm, sh4. I'll checking what happens with aarch64
[Bug c++/65945] C++ alignment of nullptr_t is 1 and might cause unaligned stores to the frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65945 --- Comment #6 from npl at chello dot at --- btw... there seems to be a logical fallacy in the way gcc produces stores anyway. if a type has size 4 and alignment 1 (like a struct with 4 chars), shouldn`t the compiler generate byte-writes? Just curious if there could be a more generic bug hidden, which is triggered by my testcase (which can be fixed whit a bigger alignof(nullptr)) but might be triggered in other circumstances aswell.
[Bug c++/65876] [6 Regression] [C++11] ICE in cxx_eval_call_expression, at cp/constexpr.c:1358
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65876 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Summary|[5/6 Regression] [C++11]|[6 Regression] [C++11] ICE |ICE in |in |cxx_eval_call_expression, |cxx_eval_call_expression, |at cp/constexpr.c:1358 |at cp/constexpr.c:1358 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Fixed for 5.2.
[Bug target/65931] [5/6 regression] dsymutil assertion failure building libgnat-5.dylib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65931 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-04-30 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- I have already filed Bug ID# 20510039 and I am using dsymutil from Xcode 6.2.
[Bug web/64968] Upgrade GCC Bugzilla to 5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64968 --- Comment #28 from Frédéric Buclin LpSolit at netscape dot net --- Maybe is this a coincidence, but all bugmails I found which have a wrong timestamp have something in common. First of all, the offset is *always* the same: -05:30. Then, it seems the problem only happens when the clock is close to :15, :30, :45 or :00, as shown below: Markus Trippelsdorf 2015-04-28 16:14:58 UTC H.J. Lu 2015-04-28 16:19:15 UTC Andreas Schwab 2015-04-28 20:20:10 UTC Christian Eggers2015-04-29 15:59:49 UTC Jonathan Wakely 2015-04-30 09:14:14 UTC Rainer Emrich 2015-04-30 13:45:19 UTC @Markus: no need to paste the full email header anymore as I'm getting all bugmails myself since last night. Just indicate the bug ID and comment ID (or real timestamp if it's not a new comment), and I will find it. :) @overseers: to be honest, I don't think this is a bug in Bugzilla itself. I would tend to a bug or a bad interaction with the MTA, qmail or sendmail. Is sourceware running some cron job every 15 minutes, which could interact with Bugzilla sending emails at the same time? And depending on which job is run, maybe sendmail/qmail is confused and uses the wrong timezone. No idea why the offset is always -05:30, but this may give sourceware admins some clue.
[Bug target/65952] New: [AArch64] Will not vectorize copying pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65952
Bug ID: 65952
Summary: [AArch64] Will not vectorize copying pointers
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: alalaw01 at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
typedef struct {
int a, b, c, d;
} my_struct;
my_struct *array;
my_struct *ptrs[4];
void
loop ()
{
for (int i = 0; i 4; i++)
ptrs[i] = array[i];
}
Vectorizes on x86, but not on AArch64. From -fdump-tree-vect-details:
test.c:13:3: note: vectorization factor = 4
...
test.c:13:3: note: not vectorized: relevant stmt not supported: _6 = _5 * 16;
test.c:13:3: note: bad operation or unsupported loop bound.
test.c:13:3: note: * Re-trying analysis with vector size 8
...
test.c:13:3: note: not vectorized: no vectype for stmt: ptrs[i_12] = _7;
scalar_type: struct my_struct *
test.c:13:3: note: bad data references.
test.c:11:1: note: vectorized 0 loops in function.
[Bug tree-optimization/63551] [4.9/5 Regression] wrong code (segfaults) at -Os on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63551 --- Comment #14 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Thu Apr 30 18:01:07 2015 New Revision: 222650 URL: https://gcc.gnu.org/viewcvs?rev=222650root=gccview=rev Log: PR tree-optimization/63551 * g++.dg/ipa/pr63551.C: New test. Added: trunk/gcc/testsuite/g++.dg/ipa/pr63551.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/65185] avr-gcc mcus.def missing rfr2 devices
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65185 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Target||avr Priority|P3 |P4 Status|UNCONFIRMED |RESOLVED CC||gjl at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |5.0 Severity|normal |enhancement --- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org --- The devices have been added as SVN trunk r212692 (5.0 experimental at that time). http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=212692
[Bug tree-optimization/63551] [4.9/5 Regression] wrong code (segfaults) at -Os on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63551 --- Comment #15 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Thu Apr 30 18:03:53 2015 New Revision: 222651 URL: https://gcc.gnu.org/viewcvs?rev=222651root=gccview=rev Log: PR tree-optimization/63551 * g++.dg/ipa/pr63551.C: New test. Added: branches/gcc-5-branch/gcc/testsuite/g++.dg/ipa/pr63551.C Modified: branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug c++/65954] New: gcc segfaults on the following input with a syntax error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65954
Bug ID: 65954
Summary: gcc segfaults on the following input with a syntax
error
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: federl at gmail dot com
Target Milestone: ---
g++ 4.8.2 on Ubuntu 14.04.2 LTS, 64bit throws a segmentation fault on the input
below (it contains a small typo Cicle instead of Circle). BTW, fixing the typo
also fixes the segfault...
$ cat test.cpp
namespace carta {
namespace lib {
class Shape {
public:
enum class Type { Circle, Square };
};
}
}
int main( int, char **)
{
auto x = carta::lib::Shape::Type::Circle;
carta::lib::Shape shape;
carta::lib::Shape::Type y;
y = shape.Type::Cicle;
return 0;
}
$ g++ -std=c++11 test.cpp
test.cpp: In function ‘int main(int, char**)’:
test.cpp:15:21: internal compiler error: Segmentation fault
y = shape.Type::Cicle;
^
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.8/README.Bugs for instructions.
Preprocessed source stored into /tmp/cc94vBRp.out file, please attach this to
your bugreport.
$ cat /tmp/cc94vBRp.out
// /usr/lib/gcc/x86_64-linux-gnu/4.8/cc1plus -quiet -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE test.cpp -quiet -dumpbase test.cpp
-mtune=generic -march=x86-64 -auxbase test -std=c++11 -fstack-protector
-Wformat -Wformat-security -o - -frandom-seed=0
# 1 test.cpp
# 1 command-line
# 1 /usr/include/stdc-predef.h 1 3 4
# 1 command-line 2
# 1 test.cpp
namespace carta {
namespace lib {
class Shape {
public:
enum class Type { Circle, Square };
};
}
}
int main( int, char **)
{
auto x = carta::lib::Shape::Type::Circle;
carta::lib::Shape shape;
carta::lib::Shape::Type y;
y = shape.Type::Cicle;
return 0;
}
[Bug lto/65950] Loop is not vectorized with lto.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65950 --- Comment #1 from Yuri Rumyantsev ysrumyan at gmail dot com --- Created attachment 35432 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35432action=edit test-case to reproduce Must be compiled with -Ofast and -fopenmp options.
[Bug rtl-optimization/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65932 Christian Eggers ceggers at gmx dot de changed: What|Removed |Added CC||ceggers at gmx dot de --- Comment #3 from Christian Eggers ceggers at gmx dot de --- (In reply to Richard Earnshaw from comment #2) code built with -fno-ipa-sra appears to be ok on a visual inspection. Unfortunately I'll be on vacation until Tuesday, 7th. Then I can try to build to whole kernel with this flag.
[Bug tree-optimization/63551] [4.9/5 Regression] wrong code (segfaults) at -Os on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63551 --- Comment #16 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Thu Apr 30 18:05:34 2015 New Revision: 222652 URL: https://gcc.gnu.org/viewcvs?rev=222652root=gccview=rev Log: PR tree-optimization/63551 * g++.dg/ipa/pr63551.C: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/ipa/pr63551.C Modified: branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/65953] [5/6 Regression] undefined reference to static __thread variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65953 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Looks like a Mono bug to me. mono_jit_tls isn't __attribute__((used)), and the compiler determines it is a write-only variable (doesn't know the asm uses it). Wonder why they use asm at all for this...
[Bug c++/65801] [5/6 Regression] Allow -Wno-narrowing to silence stricter C++11 narrowing rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65801 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.2 --- Comment #22 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 5.2 too.
[Bug lto/65559] [5/6 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559
--- Comment #26 from Rainer Emrich rai...@emrich-ebersheim.de ---
(In reply to Rainer Emrich from comment #25)
(In reply to Richard Biener from comment #24)
Note that the issue should only cause option merging to be skipped for files
in archives (and that, too, on x86_64-linux). Though compared to the 4.9
branch
we do
fd = open (argv[i], O_RDONLY);
if (fd == -1)
{
lto_argv[lto_argc++] = argv[i];
continue;
}
vs.
fd = open (argv[i], O_RDONLY);
if (fd == -1)
continue;
so we add the file to later processing even if we failed to open it. Thus,
does removing _that_ also fix the issue?
Native bootstrap for c,c++ started on x86_64-w64-mingw32. I will run the
testsuite afterwards. Results expected in about 4 hours.
Tested patch:
Index: gcc/lto-wrapper.c
===
--- gcc/lto-wrapper.c (Revision 222611)
+++ gcc/lto-wrapper.c (Arbeitskopie)
@@ -936,10 +936,7 @@ run_gcc (unsigned argc, char *argv[])
}
fd = open (argv[i], O_RDONLY);
if (fd == -1)
- {
- lto_argv[lto_argc++] = argv[i];
- continue;
- }
+ continue;
if (find_and_merge_options (fd, file_offset, LTO_SECTION_NAME_PREFIX,
fdecoded_options, fdecoded_options_count,
Doesn't help, lto failures back again!
