[Bug ipa/61659] [4.9/4.10 Regression] Extra undefined symbol because of devirtualization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61659
bin.cheng amker.cheng at gmail dot com changed:
What|Removed |Added
CC||amker.cheng at gmail dot com
--- Comment #21 from bin.cheng amker.cheng at gmail dot com ---
(In reply to Jason Merrill from comment #18)
Author: jason
Date: Wed Jul 30 17:27:14 2014
New Revision: 213307
URL: https://gcc.gnu.org/viewcvs?rev=213307root=gccview=rev
Log:
PR lto/53808
PR c++/61659
* pt.c (push_template_decl_real): Set DECL_COMDAT on templates.
(check_explicit_specialization): Clear it on specializations.
* decl.c (duplicate_decls, start_decl): Likewise.
(grokmethod, grokfndecl): Set DECL_COMDAT on inlines.
* method.c (implicitly_declare_fn): Set DECL_COMDAT. Determine
linkage after setting the appropriate flags.
* tree.c (decl_linkage): Don't check DECL_COMDAT.
* decl2.c (mark_needed): Mark clones.
(import_export_decl): Not here.
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/cp/decl2.c
trunk/gcc/cp/method.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/g++.dg/opt/devirt4.C
Hi Jason,
After setting DECL_COMDAT, testcase g++.dg/ext/arm-fp16/fp16-mangle-1.C as
below no longer works.
/* { dg-do compile { target arm*-*-* } } */
/* { dg-options -mfp16-format=ieee } */
/* Test mangling */
/* { dg-final { scan-assembler \t.global\t_Z1fPDh } } */
void f (__fp16 *x) { }
/* { dg-final { scan-assembler \t.global\t_Z1gPDhS_ } } */
void g (__fp16 *x, __fp16 *y) { }
/* { dg-final { scan-assembler \t.global\t_ZN1SIDhDhE1iE } } */
template typename T, typename U struct S { static int i; };
template int S__fp16, __fp16::i = 3;
Since g++ now outputs:
.weak_ZN1SIDhDhE1iE
.section.data._ZN1SIDhDhE1iE,awG,%progbits,_ZN1SIDhDhE1iE,comdat
.align2
.type_ZN1SIDhDhE1iE, %object
.size_ZN1SIDhDhE1iE, 4
_ZN1SIDhDhE1iE:
.word3
.identGCC: (GNU) 4.10.0 20140811 (experimental)
rather than .global\t_ZN1SIDhDhE1iE.
I assume we should refine the testcase?
Thanks.
[Bug target/62025] [4.9/4.10 Regression] Miscompilation of openssl sha512.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025 --- Comment #6 from Jeffrey A. Law law at redhat dot com --- It's late and I need to catch some zzzs. But as I hinted in my prior update, I think we may chasing something latent. I would recommend looking very closely at r204497, which my bisecting implicated as the failing commit for a severely hacked up test. Reverting r204497 by hand on the trunk results in the original testcase working properly. I'm too tired to really analyze, but I think it's worth a looksie.
[Bug target/62025] [4.9/4.10 Regression] Miscompilation of openssl sha512.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025 amker at gcc dot gnu.org changed: What|Removed |Added CC||amker at gcc dot gnu.org --- Comment #7 from amker at gcc dot gnu.org --- Oh, it's my commit, I will have a look if you are ok with that.
[Bug target/62025] [4.9/4.10 Regression] Miscompilation of openssl sha512.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025 --- Comment #8 from Jeffrey A. Law law at redhat dot com --- More eyes never hurt :-) This pair is going to bed.
[Bug preprocessor/58844] [4.8 Regression] ICE with invalid use of ##
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58844 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org --- Please see https://gcc.gnu.org/ml/gcc-patches/2009-04/msg01490.html for reasoning why gcc considers it valid.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 --- Comment #6 from Sven C. Dack sven.c.dack at virginmedia dot com --- It seems the problem is caused by the use of the jobserver. Changing bootstrap-lto.mk from: ... STAGE2_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects STAGE3_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects ... to: ... STAGE2_CFLAGS += -flto=1 -flto-partition=none -frandom-seed=1 -ffat-lto-objects STAGE3_CFLAGS += -flto=1 -flto-partition=none -frandom-seed=1 -ffat-lto-objects ... Results in a success without using an additional compare script: ... Comparing stages 2 and 3 warning: gcc/cc1obj-checksum.o differs warning: gcc/cc1-checksum.o differs warning: gcc/cc1plus-checksum.o differs Comparison successful. ...
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 Sven C. Dack sven.c.dack at virginmedia dot com changed: What|Removed |Added Attachment #33285|0 |1 is obsolete|| --- Comment #7 from Sven C. Dack sven.c.dack at virginmedia dot com --- Created attachment 33299 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33299action=edit Removes the use of the jobserver from bootstrap-lto.mk The patch changes bootstrap-lto.mk to use a single, unpartitioned stream instead of the jobserver.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 --- Comment #8 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Sven C. Dack from comment #7) Created attachment 33299 [details] Removes the use of the jobserver from bootstrap-lto.mk The patch changes bootstrap-lto.mk to use a single, unpartitioned stream instead of the jobserver. This patch makes sense from a reproducibility point of view too.
[Bug preprocessor/58844] [4.8 Regression] ICE with invalid use of ##
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58844 --- Comment #11 from David Krauss potswa at mac dot com --- On 2014–08–12, at 3:10 PM, jakub at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: Please see https://gcc.gnu.org/ml/gcc-patches/2009-04/msg01490.html for reasoning why gcc considers it valid. That reasoning goes awry at “ISO C is silent about this possibility.” C and C++ both say, each instance of a ## preprocessing token in the replacement list (not from an argument) is deleted and the preceding preprocessing token is concatenated with the following preprocessing token. This is unambiguous in that consecutive ## tokens get pasted; they can’t all be operators. The spec also says, “The order of evaluation of ## operators is unspecified,” which doesn’t seem like much of a constraint but it does suggest that they are evaluated one-by-one. The standard also says “If the result is not a valid preprocessing token, the behavior is undefined,” so no diagnosis is required. However, there have been a couple proposals to make it required, so it’s a very good idea. Even if the user really meant them to be operators, it won’t be portable.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #9 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #8) (In reply to Sven C. Dack from comment #7) Created attachment 33299 [details] Removes the use of the jobserver from bootstrap-lto.mk The patch changes bootstrap-lto.mk to use a single, unpartitioned stream instead of the jobserver. This patch makes sense from a reproducibility point of view too. But it will increase the build-time enormously.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 --- Comment #10 from rguenther at suse dot de rguenther at suse dot de --- On Tue, 12 Aug 2014, trippels at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #9 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #8) (In reply to Sven C. Dack from comment #7) Created attachment 33299 [details] Removes the use of the jobserver from bootstrap-lto.mk The patch changes bootstrap-lto.mk to use a single, unpartitioned stream instead of the jobserver. This patch makes sense from a reproducibility point of view too. But it will increase the build-time enormously. Yeah, and that it triggers a comparison error sounds bogus. It just triggers the use of a makefile for building the _LTRANS_ objects. Thus it shouldn't have an effect on the object files we compare (especially if the actual final cc1 object does _not_ miscompare and thus we don't see a stage2/3 miscompile). Richard.
[Bug target/62025] [4.9/4.10 Regression] Miscompilation of openssl sha512.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
--- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Jeffrey A. Law from comment #6)
It's late and I need to catch some zzzs. But as I hinted in my prior update,
I think we may chasing something latent. I would recommend looking very
closely at r204497, which my bisecting implicated as the failing commit for
a severely hacked up test.
Reverting r204497 by hand on the trunk results in the original testcase
working properly. I'm too tired to really analyze, but I think it's worth a
looksie.
I never said r207605 was the buggy change, after all, as only the EPILOGUE_USES
definition itself makes the code misbehave, it is clear it only triggers a
latent issue. For any case we need to find out what is actually miscompiled in
the testcase and from that why.
I've tried this morning following hack on top of r207605:
--- sched-deps.c.xx2014-08-11 12:05:39.0 +0200
+++ sched-deps.c2014-08-12 09:51:48.540485357 +0200
@@ -3034,6 +3034,14 @@ sched_analyze_insn (struct deps_desc *de
|| (NONJUMP_INSN_P (insn) control_flow_insn_p (insn)))
reg_pending_barrier = MOVE_BARRIER;
+ if (!DEBUG_INSN_P (insn) reload_completed getenv (SKIPB) getenv
(SKIPE))
+{
+ static int cntskip;
+ ++cntskip;
+ if (cntskip atoi (getenv (SKIPB)) cntskip atoi (getenv
(SKIPE)))
+reg_pending_barrier = TRUE_BARRIER;
+}
+
if (sched_pressure != SCHED_PRESSURE_NONE)
{
setup_insn_reg_uses (deps, insn);
and it seems that with:
./cc1 -m31 -O2 -march=z196 -mtune=z10 sha.c -o sha1.s -quiet -nostdinc;
SKIPB=6261 SKIPE=6263 ./cc1 -m31 -O2 -march=z196 -mtune=z10 sha.c -o sha2.s
-quiet -nostdinc
sha1.s is expectedly miscompiled, while sha2.s gives the correct result and
differs just in a single true barrier during sched2, i.e. no changes in split2
dump, and just small amount of changes in the sched2 dump.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 --- Comment #11 from Venkataramanan venkataramanan.kumar at amd dot com --- I am also trying to fix LTO bootstrap compare failure in Aarch64. Bootstrap compare failure is not occurring in GCC FSF trunk (tested on aarch64 as well as x86_64 machine). Now I am doing one more round of bisecting to see which revision fixes this (or) first time compare not seen. Also I tried to recompile gimple.o which was miscomparing and also dump the gimple and IPA IR. I found that in GCC trunk there are no differences between stage2 and stage3 dumps. But with GCC 4.9 there are some differences, Stage2 (prev-gcc) vs stage3 (gcc) Very first dump file is gimple.c.001t.tu The number of @numbers are more in stage2 @103184 identifier_node strg: debug_ready_dispatchlngt: 20 Stage3 @103169 identifier_node strg: debug_ready_dispatchlngt: 20 Also gimple.c.048i.inline showed differences in Min size. (--Snip--) min size: 6 --- min size: 0 6590c6590 min size: 14 --- min size: 0 6607c6607 min size: 28 (--Snip--) In gimple-fold.c.000i.cgraph (--Snip--) _Z25gimple_build_omp_continueP9tree_nodeS0_/761 (gimple_build_omp_continue(tree_node*, tree_node*)) @0x3ff7ebda548 --- _Z25gimple_build_omp_continueP9tree_nodeS0_/761 (gimple_build_omp_continue(tree_node*, tree_node*)) @0x3ff92b5a548 28865c28865 (--Snip--) why do these dumps show differences? The other tree optimization dumps don't show any difference.
[Bug target/62011] False Data Dependency in popcnt instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62011 --- Comment #7 from Yuri Rumyantsev ysrumyan at gmail dot com --- Please ignore my previous comment - if we insert nullifying of destination register before each popcnt (and lzcnt) performance will restore: original test results: unsigned8388663 0.848533 sec24.715 GB/s uint64_t8388663 1.37436 sec 15.2592 GB/s fixed popcnt: unsigned9044037 0.853753 sec24.5639 GB/s uint64_t8388663 0.694458 sec30.1984 GB/s Here is assembly for 2nd loop: .L16: xorq%rax, %rax popcntq-8(%rdx), %rax xorq%rcx, %rcx popcntq(%rdx), %rcx addq%rax, %rcx xorq%rax, %rax popcntq8(%rdx), %rax addq%rcx, %rax addq$32, %rdx xorq%rcx, %rcx popcntq-16(%rdx), %rcx addq%rax, %rcx addq%rcx, %r13 cmpq%rsi, %rdx jne.L16
[Bug target/62025] [4.9/4.10 Regression] Miscompilation of openssl sha512.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
--- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org ---
And with:
--- sched-deps.c(revision 207605)
+++ sched-deps.c(working copy)
@@ -3034,6 +3034,21 @@ sched_analyze_insn (struct deps_desc *de
|| (NONJUMP_INSN_P (insn) control_flow_insn_p (insn)))
reg_pending_barrier = MOVE_BARRIER;
+ if (!DEBUG_INSN_P (insn) reload_completed getenv (SKIPB) getenv
(SKIPE))
+{
+ static int cntskip;
+ ++cntskip;
+ if (cntskip atoi (getenv (SKIPB)) cntskip atoi (getenv
(SKIPE)))
+reg_pending_barrier = TRUE_BARRIER;
+}
+ if (!DEBUG_INSN_P (insn) reload_completed getenv (FLUSHB) getenv
(FLUSHE))
+{
+ static int cntskip;
+ ++cntskip;
+ if (cntskip atoi (getenv (FLUSHB)) cntskip atoi (getenv
(FLUSHE)))
+flush_pending_lists (deps, insn, true, true);
+}
+
if (sched_pressure != SCHED_PRESSURE_NONE)
{
setup_insn_reg_uses (deps, insn);
again, on top of r207605, and -O2 -m31 -march=z196 -mtune=z10, I get no
miscompilation with
FLUSHB=6261 FLUSHE=6263 ./cc1 -m31 -O2 -march=z196 -mtune=z10 sha.c -o sha3.s
-quiet -nostdinc
diff -up -U8 sha1.s sha3.s
--- sha1.s2014-08-12 10:40:14.813740998 +0200
+++ sha3.s2014-08-12 10:46:58.425686712 +0200
@@ -6246,38 +6246,38 @@ sha512_block_data_order:
lm%r2,%r3,312(%r15)
x%r11,152(%r15)
or%r5,%r8
l%r8,276(%r15)
n%r9,216(%r15)
srl%r4,7
n%r11,184(%r15)
al%r3,252(%r8)
-ahi%r8,128
-alc%r2,120(%r8)
+alc%r2,248(%r8)
+x%r0,1104(%r15)
xr%r11,%r9
st%r11,1072(%r15)
-xr%r1,%r5
n%r7,188(%r15)
-x%r0,1104(%r15)
-st%r8,276(%r15)
+xr%r1,%r5
stm%r2,%r3,120(%r15)
st%r0,1084(%r15)
l%r3,116(%r15)
sll%r3,25
lr%r6,%r3
l%r3,224(%r15)
xr%r3,%r10
st%r3,1068(%r15)
l%r3,156(%r15)
l%r2,232(%r15)
xr%r2,%r12
st%r2,1088(%r15)
-lm%r10,%r11,120(%r15)
n%r3,220(%r15)
+ahi%r8,128
+lm%r10,%r11,120(%r15)
+st%r8,276(%r15)
al%r11,164(%r15)
alc%r10,160(%r15)
xr%r7,%r3
st%r7,1076(%r15)
lr%r3,%r11
or%r6,%r4
lm%r4,%r5,304(%r15)
al%r3,1068(%r15)
[Bug ipa/62104] New: [4.10 Regression] ICE: in update_visibility_by_resolution_info, at ipa-visibility.c:403
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62104 Bug ID: 62104 Summary: [4.10 Regression] ICE: in update_visibility_by_resolution_info, at ipa-visibility.c:403 Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org CC: hubicka at gcc dot gnu.org Fixefox PGO/LTO build fails on final libxul link (-fprofile-use phase): lto1: internal compiler error: in update_visibility_by_resolution_info, at ipa-visibility.c:403 0xe4cf20 update_visibility_by_resolution_info ../../gcc/gcc/ipa-visibility.c:400 0xe4d932 function_and_variable_visibility ../../gcc/gcc/ipa-visibility.c:557 0xe4ea56 whole_program_function_and_variable_visibility ../../gcc/gcc/ipa-visibility.c:745 0xe4ea56 execute ../../gcc/gcc/ipa-visibility.c:793 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: fatal error: /var/tmp/gcc_test/usr/local/bin/g++ returned 1 exit status compilation terminated. /usr/bin/ld: fatal error: lto-wrapper failed collect2: error: ld returned 1 exit status /var/tmp/mozilla-central/config/rules.mk:829: recipe for target 'libxul.so' failed
[Bug driver/62105] New: sanitizer libraries in wrong command line position in link spec file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62105 Bug ID: 62105 Summary: sanitizer libraries in wrong command line position in link spec file Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: jtaylor.debian at googlemail dot com when linking a file with -fsanitize=* the sanatizer library (e.g. -ltsan is placed before the object on the command line: gcc-4.10 test.c -fsanitize=thread -v -fPIC -shared 21 | grep --color tsan [...] -ltsan /tmp/cc6ovqw5.o -lgcc --as-needed -lgcc_s [...] this is problematic on distributions like Ubuntu which add the --as-needed flag to the beginning of the the gcc link spec. This causes the linker to drop the -ltsan because when it has parsed the -ltsan option it determines it as not needed and drops it. The object needing it only comes later. The fix would be to move the library after the object needing it (like -lgcc). In principle this is Ubuntus issue as they add the non standard as-needed flag, but as the other libraries like -lgcc and -lc are placed correctly maybe the -l*san can be moved too? I used a gcc built from recent SVN head on Ubuntu 14.04 amd64. /tmp/jtaylor $ gcc-4.10 --version gcc (GCC) 4.10.0 20140812 (experimental)
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #12 from Richard Biener rguenth at gcc dot gnu.org ---
Ok, so there is one thing that changed (but only very recently) on trunk which
is improved hashing of SCCs and thus more consistent ordering.
Especially I'm talking about the fact that at compile-time (!) we sort
via
static int
scc_entry_compare (const void *p1_, const void *p2_)
{
const scc_entry *p1 = (const scc_entry *) p1_;
const scc_entry *p2 = (const scc_entry *) p2_;
if (p1-hash p2-hash)
return -1;
else if (p1-hash p2-hash)
return 1;
return 0;
}
static hashval_t
hash_scc (struct streamer_tree_cache_d *cache, unsigned first, unsigned size)
{
/* Compute hash values for the SCC members. */
for (unsigned i = 0; i size; ++i)
sccstack[first+i].hash = hash_tree (cache, sccstack[first+i].t);
if (size == 1)
return sccstack[first].hash;
/* Sort the SCC of type, hash pairs so that when we mix in
all members of the SCC the hash value becomes independent on
the order we visited the SCC. Disregard hashes equal to
the hash of the tree we mix into because we cannot guarantee
a stable sort for those across different TUs. */
qsort (sccstack[first], size, sizeof (scc_entry), scc_entry_compare);
which means returning 0 from the qsort compare function for hash
collisions. In theory the qsort implementation can randomly permute
stuff here leading to comparison fails.
I'm checking if breaking the tie via the DFS number fixes the miscompare
I saw.
Note that I assumed that sane implementations would behave consistently
here, but of course with address-space randomization and friends and an
implementation that breaks tie itself via addresses would break.
(I'd choose a simpler tie breaker - first argument to compare is less
than second arg to compare).
Well. Not sure what glibc msort does here.
That said, the smallest object I observe differences is build/genconfig.o
which has differences in the size(!) of the LTO_section_decls section
and differences already in the decl-state refs part.
[Bug fortran/62106] New: Adding a scalar variable to an array constructor gives wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62106 Bug ID: 62106 Summary: Adding a scalar variable to an array constructor gives wrong result Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: m.a.hulsen at tue dot nl The following code program t integer :: ndim=2, ndfp=4, i print *, (/ ( i, i = 1, ndfp ) /) + ndim end program t gives 1 2 3 4 whereas it should be 3 4 5 6 Note, that both ndfp and ndim need to be variables not constants, in order to generate the wrong result.
[Bug fortran/62106] Adding a scalar variable to an array constructor gives wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62106 --- Comment #1 from Martien Hulsen m.a.hulsen at tue dot nl --- It only shows up using optimisation, i.e. -On, with n=1.
[Bug target/62025] [4.9/4.10 Regression] Miscompilation of openssl sha512.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-08-12
Ever confirmed|0 |1
--- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org ---
And the bug in that is that in sha1.s (the miscompiled one) sched2 wrongly
scheduled ahi %r8,128 which clobbers %cc in between a %cc producer and %cc
consumer. If I manually fix that up as follows:
--- sha1.s2014-08-12 08:39:50.694224146 -0400
+++ sha4.s2014-08-12 09:38:58.914224146 -0400
@@ -6251,8 +6251,8 @@ sha512_block_data_order:
srl%r4,7
n%r11,184(%r15)
al%r3,252(%r8)
+alc%r2,248(%r8)
ahi%r8,128
-alc%r2,120(%r8)
xr%r11,%r9
st%r11,1072(%r15)
xr%r1,%r5
then the testcase succeeds.
In *.split2 we have:
(insn 11376 7193 11377 5 (parallel [
(set (reg:CCL1 33 %cc)
(compare:CCL1 (plus:SI (reg:SI 3 %r3 [orig:2900 D.1817+4 ]
[2900])
(mem:SI (plus:SI (reg:SI 8 %r8 [orig:65 ivtmp.30 ]
[65])
(const_int 252 [0xfc])) [2 MEM[base: _25,
offset: 248B]+4 S4 A32]))
(reg:SI 3 %r3 [orig:2900 D.1817+4 ] [2900])))
(set (reg:SI 3 %r3 [orig:2900 D.1817+4 ] [2900])
(plus:SI (reg:SI 3 %r3 [orig:2900 D.1817+4 ] [2900])
(mem:SI (plus:SI (reg:SI 8 %r8 [orig:65 ivtmp.30 ] [65])
(const_int 252 [0xfc])) [2 MEM[base: _25, offset:
248B]+4 S4 A32])))
]) 329 {*addsi3_carry1_cc}
(nil))
(insn 11377 11376 7194 5 (parallel [
(set (reg:SI 2 %r2 [ D.1817 ])
(plus:SI (plus:SI (ltu:SI (reg:CCL1 33 %cc)
(const_int 0 [0]))
(reg:SI 2 %r2 [ D.1817 ]))
(mem:SI (plus:SI (reg:SI 8 %r8 [orig:65 ivtmp.30 ] [65])
(const_int 248 [0xf8])) [2 MEM[base: _25, offset:
248B]+0 S4 A64])))
(clobber (reg:CC 33 %cc))
]) 407 {*addsi3_alc}
(expr_list:REG_DEAD (reg:CCL1 33 %cc)
(expr_list:REG_UNUSED (reg:CC 33 %cc)
(nil
...
(insn 2799 7206 7208 5 (parallel [
(set (reg:SI 8 %r8 [orig:65 ivtmp.30 ] [65])
(plus:SI (reg:SI 8 %r8 [orig:65 ivtmp.30 ] [65])
(const_int 128 [0x80])))
(clobber (reg:CC 33 %cc))
]) 327 {*addsi3}
(expr_list:REG_UNUSED (reg:CC 33 %cc)
(nil)))
In *.sched2 dump this is (+ is from normal r207605 compilation, - from
FLUSHB=6261 FLUSHE=6263 (i.e. - is working one, + is miscompiled one):
+(insn:TI 11376 2759 2799 5 (parallel [
(set (reg:CCL1 33 %cc)
(compare:CCL1 (plus:SI (reg:SI 3 %r3 [orig:2900 D.1817+4 ]
[2900])
(mem:SI (plus:SI (reg:SI 8 %r8 [orig:65 ivtmp.30 ]
[65])
(const_int 252 [0xfc])) [2 MEM[base: _25,
offset: 248B]+4 S4 A32]))
(reg:SI 3 %r3 [orig:2900 D.1817+4 ] [2900])))
(set (reg:SI 3 %r3 [orig:2900 D.1817+4 ] [2900])
(plus:SI (reg:SI 3 %r3 [orig:2900 D.1817+4 ] [2900])
(mem:SI (plus:SI (reg:SI 8 %r8 [orig:65 ivtmp.30 ] [65])
(const_int 252 [0xfc])) [2 MEM[base: _25, offset:
248B]+4 S4 A32])))
]) 329 {*addsi3_carry1_cc}
(nil))
-(insn:TI 11377 11376 2773 5 (parallel [
+(insn:TI 2799 11376 11377 5 (parallel [
+(set (reg:SI 8 %r8 [orig:65 ivtmp.30 ] [65])
+(plus:SI (reg:SI 8 %r8 [orig:65 ivtmp.30 ] [65])
+(const_int 128 [0x80])))
+(clobber (reg:CC 33 %cc))
+]) 327 {*addsi3}
+ (expr_list:REG_UNUSED (reg:CC 33 %cc)
+(nil)))
+(insn:TI 11377 2799 2763 5 (parallel [
(set (reg:SI 2 %r2 [ D.1817 ])
(plus:SI (plus:SI (ltu:SI (reg:CCL1 33 %cc)
(const_int 0 [0]))
(reg:SI 2 %r2 [ D.1817 ]))
(mem:SI (plus:SI (reg:SI 8 %r8 [orig:65 ivtmp.30 ] [65])
-(const_int 248 [0xf8])) [2 MEM[base: _25, offset:
248B]+0 S4 A64])))
+(const_int 120 [0x78])) [2 MEM[base: _25, offset:
248B]+0 S4 A64])))
(clobber (reg:CC 33 %cc))
]) 407 {*addsi3_alc}
(expr_list:REG_DEAD (reg:CCL1 33 %cc)
(expr_list:REG_UNUSED (reg:CC 33 %cc)
(nil
[Bug target/62100] c++11 threads invoke pure virtual function on arm embedded system
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62100 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-08-12 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Those macros are only meant to be defined by the compiler, never by users. If defining them fixes the problem it implies you are not compiling with the same ABI as your libstdc++ was built with. I can't guess more than that because you haven't provided any information on your target or how it was configured. https://gcc.gnu.org/bugs/
[Bug ipa/62104] [4.10 Regression] ICE: in update_visibility_by_resolution_info, at ipa-visibility.c:403
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62104 --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- markus@x4 /tmp % wget trippelsdorf.de/testcase.tar.bz2 --2014-08-12 12:07:24-- http://trippelsdorf.de/testcase.tar.bz2 Resolving trippelsdorf.de... 194.117.254.50 Connecting to trippelsdorf.de|194.117.254.50|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 3066810 (2.9M) [application/x-bzip2] Saving to: ‘testcase.tar.bz2’ 2014-08-12 12:07:25 (3.05 MB/s) - ‘testcase.tar.bz2’ saved [3066810/3066810] markus@x4 /tmp % tar -xjf testcase.tar.bz2 markus@x4 /tmp % g++ XPCComponents.o Unified_cpp_js_xpconnect_src1.o jsarray.o lto1: internal compiler error: in update_visibility_by_resolution_info, at ipa-visibility.c:403 0xe4cf20 update_visibility_by_resolution_info ../../gcc/gcc/ipa-visibility.c:400 0xe4d932 function_and_variable_visibility ../../gcc/gcc/ipa-visibility.c:557 0xe4ea56 whole_program_function_and_variable_visibility ../../gcc/gcc/ipa-visibility.c:745 0xe4ea56 execute ../../gcc/gcc/ipa-visibility.c:793 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: fatal error: /var/tmp/gcc_test/usr/local/bin/g++ returned 1 exit status compilation terminated. /usr/bin/ld: fatal error: lto-wrapper failed collect2: error: ld returned 1 exit status
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #13 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Richard Biener from comment #12)
Ok, so there is one thing that changed (but only very recently) on trunk
which
is improved hashing of SCCs and thus more consistent ordering.
Especially I'm talking about the fact that at compile-time (!) we sort
via
static int
scc_entry_compare (const void *p1_, const void *p2_)
{
const scc_entry *p1 = (const scc_entry *) p1_;
const scc_entry *p2 = (const scc_entry *) p2_;
if (p1-hash p2-hash)
return -1;
else if (p1-hash p2-hash)
return 1;
return 0;
}
static hashval_t
hash_scc (struct streamer_tree_cache_d *cache, unsigned first, unsigned size)
{
/* Compute hash values for the SCC members. */
for (unsigned i = 0; i size; ++i)
sccstack[first+i].hash = hash_tree (cache, sccstack[first+i].t);
if (size == 1)
return sccstack[first].hash;
/* Sort the SCC of type, hash pairs so that when we mix in
all members of the SCC the hash value becomes independent on
the order we visited the SCC. Disregard hashes equal to
the hash of the tree we mix into because we cannot guarantee
a stable sort for those across different TUs. */
qsort (sccstack[first], size, sizeof (scc_entry), scc_entry_compare);
which means returning 0 from the qsort compare function for hash
collisions. In theory the qsort implementation can randomly permute
stuff here leading to comparison fails.
I'm checking if breaking the tie via the DFS number fixes the miscompare
I saw.
Note that I assumed that sane implementations would behave consistently
here, but of course with address-space randomization and friends and an
implementation that breaks tie itself via addresses would break.
(I'd choose a simpler tie breaker - first argument to compare is less
than second arg to compare).
Well. Not sure what glibc msort does here.
That said, the smallest object I observe differences is build/genconfig.o
which has differences in the size(!) of the LTO_section_decls section
and differences already in the decl-state refs part.
Doesn't help. The list of miscompared files seems to be reproducible at least,
but the actual file contents are different for two compiles.
[Bug target/62025] [4.9/4.10 Regression] Miscompilation of openssl sha512.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
--- Comment #12 from amker at gcc dot gnu.org ---
Hi,
I can reproduce the exact mis-scheduled instruction issue as in Jakub's comment
with/without the ivopt patch (204497). Turns out gcc chooses candidate like
{K512, 128}_loop with the patch while candidate {K512[16], 128}_loop without
the patch. This is caused by candidate cost change. As far as I can see, both
candidate are good for the iv use and shouldn't generate wrong code either.
The interesting thing is, mis-scheduled instruction is the only code difference
(apart from some offset difference as base of candidates are different) caused
by ivopt patch. Normally middle-end patch should have larger impact on
generated code if there is. I will have a look why different iv candidate can
result in one instruction mis-scheduled. Maybe it's useful for investigation.
Anyway, I think 204497 is generally fine in this case.
Thanks,
bin
[Bug target/62011] False Data Dependency in popcnt instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62011 --- Comment #8 from finis at in dot tum.de --- @Yuri: Note however, that the result of your fixed u32 version seems to be wrong.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 --- Comment #14 from Venkataramanan venkataramanan.kumar at amd dot com --- (In reply to Sven C. Dack from comment #6) It seems the problem is caused by the use of the jobserver. Changing bootstrap-lto.mk from: ... STAGE2_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects STAGE3_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects ... to: ... STAGE2_CFLAGS += -flto=1 -flto-partition=none -frandom-seed=1 -ffat-lto-objects STAGE3_CFLAGS += -flto=1 -flto-partition=none -frandom-seed=1 -ffat-lto-objects ... Results in a success without using an additional compare script: ... Comparing stages 2 and 3 warning: gcc/cc1obj-checksum.o differs warning: gcc/cc1-checksum.o differs warning: gcc/cc1plus-checksum.o differs Comparison successful. ... I tried addding to stage2/3 the flags -flto=1 -flto-partition=none instead of jobserver in bootstrap-lto.mk and spawned bootstrap LTO build in one amd64 machine. But still getting compare errors with GCC 4.9 branch. The HEAD is at revision 213070.
[Bug target/62025] [4.9/4.10 Regression] Miscompilation of openssl sha512.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025 --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org --- Just verified the trunk and it is the same thing there, also sched2 generating: al %r3,252(%r8) ahi %r8,128 alc %r2,120(%r8) where the first insn is cc setter, second cc clobber and third cc user and clobber, so the r8=r8+128 insn should not have been scheduled in between those two. It seems scheduler has some code to adjust the address (248 - 120) based on the r8 adjustment, otherwise it would be wrong to move it even because of r8 register, perhaps if we take that path we don't fully check other side effects (cc clobber in this case). s390 AFAIK doesn't have addition which doesn't clobber flags, unlike many other architectures.
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 --- Comment #15 from Sven C. Dack sven.c.dack at virginmedia dot com --- (In reply to Venkataramanan from comment #14) ... I tried addding to stage2/3 the flags -flto=1 -flto-partition=none instead of jobserver in bootstrap-lto.mk and spawned bootstrap LTO build in one amd64 machine. But still getting compare errors with GCC 4.9 branch. The HEAD is at revision 213070. I have noticed a typo in one of my build scripts later this morning and am now trying to verify the result. It is still not done yet. If it is indeed wrong then I am going to take out the second patch. I am also trying to use a 1to1 partition together with -flto=jobserver and want to see if this makes a difference. This, too, is not done yet. On a different note, I have managed to build a working compiler yesterday using my compare-disassembly script with: --with-build-config=bootstrap-lto --with-boot-ldflags=-fuse-linker-plugin I am still in the process of verifying it and running tests to see if I run into any problems with it, but so far am I excited to have gotten this far. gmp, mpfr and mpc have all been compiled with LTO enabled and have run their testsuits without an error. I have tried pushing it further with -fipa-pta -fuse-liner-plugin, but ran out of memory (16GB).
[Bug target/62011] False Data Dependency in popcnt instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62011 --- Comment #9 from Yuri Rumyantsev ysrumyan at gmail dot com --- This is not u32 version but u64. The first loop (u32) version looks like: .L23: leal1(%rdx), %ecx xorq%rax, %rax popcntq(%rbx,%rax,8), %rax leal2(%rdx), %r8d xorq%rcx, %rcx popcntq(%rbx,%rcx,8), %rcx addq%rax, %rcx leal3(%rdx), %esi xorq%rax, %rax popcntq(%rbx,%r8,8), %rax addq%rax, %rcx xorq%rax, %rax popcntq(%rbx,%rsi,8), %rax addq%rax, %rcx leal4(%rdx), %eax addq%rcx, %r14 movq%rax, %rdx cmpq%rax, %r12 ja.L23
[Bug target/62100] c++11 threads invoke pure virtual function on arm embedded system
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62100 --- Comment #2 from Peter A. Bigot pab at pabigot dot com --- Thanks. The compiler and libstdc++ are built using Yocto's standard recipe for the beaglebone. Obviously there's something wrong with it; what that would be is not obvious and probably isn't a gcc problem. I'll be back when I know more.
[Bug target/61373] neon registers restored incorrectly with -mapcs-frame -O -fno-omit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61373 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #1 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Missing attachment. Ramana
[Bug libgomp/62107] New: libgomp.fortran/target2.f90 FAIL while compiling for OpenMP 4.0 offload target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62107
Bug ID: 62107
Summary: libgomp.fortran/target2.f90 FAIL while compiling for
OpenMP 4.0 offload target
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: andrey.turetskiy at gmail dot com
CC: jakub at gcc dot gnu.org
To reproduce with trunk GCC:
gfortran -fopenmp libgomp/testsuite/libgomp.fortran/target2.f90
Reduced testcase:
module target2
contains
subroutine foo (a)
integer, pointer :: a
logical :: r
!$omp target map (to: a) map (from: r)
r = a /= 1
!$omp end target
if (r) call abort
end subroutine foo
end module target2
use target2, only : foo
integer, pointer :: a
allocate (a)
a = 1
call foo (a)
end
GIMPLE for reduced testcase:
foo (integer(kind=4) * a)
{
integer(kind=4) * a.1;
logical(kind=4) r.4;
logical(kind=4) r;
try
{
a.1 = a;
// Looks like the map clause for data pointed by 'a' is missed
#pragma omp target map(to:*a.1 [len: 8]) map(alloc:a [pointer assign,
bias: 0]) map(from:r [len: 4])
{
{
integer(kind=4) * a.2;
integer(kind=4) * D.2342;
integer(kind=4) D.2343;
logical(kind=4) r.3;
a.2 = a;
D.2342 = *a.2;
D.2343 = *D.2342;
r.3 = D.2343 != 1;
r = r.3;
}
}
r.4 = r;
if (r.4 != 0) goto D.2346; else goto D.2347;
D.2346:
_gfortran_abort ();
D.2347:
L.1:
}
finally
{
r = {CLOBBER};
}
}
[Bug target/62025] [4.9/4.10 Regression] Miscompilation of openssl sha512.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||bernds at gcc dot gnu.org --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org --- Seems that is the http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00155.html minipass, supposedly when it sees that it could break a reg dependency (on r8 in this case), it just ignores the fact that it can have other side effects. parse_add_or_inc uses single_set which will return the increment SET even if there are extra clobbers. Giving up would make the minipass useless on many architectures, so I think we just need to make sure that we ignore the reg dependency only on the address register (r8 here), but not for the clobbered regs.
[Bug target/62100] c++11 threads invoke pure virtual function on arm embedded system
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62100 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- It might be obvious in the output of 'gcc -v'.
[Bug middle-end/60281] Address Sanitizer triggers alignment fault in ARM machines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60281 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ramana at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |4.9.1 --- Comment #4 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- From code generated currently - looks fixed for 4.9.1 since GCC 4.9.0 was actually released on 22nd April !
[Bug target/62025] [4.9/4.10 Regression] Miscompilation of openssl sha512.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
--- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org ---
So, what about this completely untested fix? Unfortunately the scheduler
change has been committed with no testcases. I guess I'll do a
bootstrap/regtest with some printout where this patch changes things and where
we consider it at all.
--- gcc/sched-deps.c.jj2014-08-06 10:34:13.0 +0200
+++ gcc/sched-deps.c2014-08-12 14:12:06.625193731 +0200
@@ -4751,6 +4751,24 @@ find_inc (struct mem_inc_info *mii, bool
inc conflicts with store failure.\n);
goto next;
}
+
+ /* The inc instruction could have clobbers, make sure those
+ registers are not used in mem insn. */
+ FOR_EACH_INSN_DEF (def, mii-inc_insn)
+if (!reg_overlap_mentioned_p (DF_REF_REG (def), mii-mem_reg0))
+ {
+df_ref use;
+FOR_EACH_INSN_USE (use, mii-mem_insn)
+ if (reg_overlap_mentioned_p (DF_REF_REG (def),
+ DF_REF_REG (use)))
+{
+ if (sched_verbose = 5)
+fprintf (sched_dump,
+ inc clobber used in store failure.\n);
+ goto next;
+}
+ }
+
newaddr = mii-inc_input;
if (mii-mem_index != NULL_RTX)
newaddr = gen_rtx_PLUS (GET_MODE (newaddr), newaddr,
[Bug target/62098] [4.9 regression] incorrect code generated by arm gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62098 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-12 Target Milestone|--- |4.9.2 Summary|[4.9 regressionincorrect|[4.9 regression] incorrect |code generated by arm gcc |code generated by arm gcc Ever confirmed|0 |1 --- Comment #1 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Bummer, uggh the vcvtf2i pattern is wrong.
[Bug other/61962] GCC seems to enter an infinite loop when compiling the above cilk+ code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61962 --- Comment #1 from Kirill Yukhin kyukhin at gcc dot gnu.org --- Author: kyukhin Date: Tue Aug 12 12:27:41 2014 New Revision: 213858 URL: https://gcc.gnu.org/viewcvs?rev=213858root=gccview=rev Log: PR other/61962 gcc/c-family/ * array-notation-common.c (find_rank): Added handling for other types of references. testsuite/ * c-c++-common/cilk-plus/AN/pr61962.c: New test. Added: trunk/gcc/testsuite/c-c++-common/cilk-plus/AN/pr61962.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/array-notation-common.c trunk/gcc/testsuite/ChangeLog
[Bug other/61962] GCC seems to enter an infinite loop when compiling the above cilk+ code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61962 --- Comment #2 from Kirill Yukhin kyukhin at gcc dot gnu.org --- Author: kyukhin Date: Tue Aug 12 12:33:06 2014 New Revision: 213859 URL: https://gcc.gnu.org/viewcvs?rev=213859root=gccview=rev Log: PR other/61962 gcc/c-family/ * array-notation-common.c (find_rank): Added handling for other types of references. gcc/testsuite/ * c-c++-common/cilk-plus/AN/pr61962.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/c-c++-common/cilk-plus/AN/pr61962.c Modified: branches/gcc-4_9-branch/gcc/c-family/ChangeLog branches/gcc-4_9-branch/gcc/c-family/array-notation-common.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug target/62100] c++11 threads invoke pure virtual function on arm embedded system
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62100 --- Comment #4 from Peter A. Bigot pab at pabigot dot com --- It's not obvious to me: beaglebone[98]$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/gcc/arm-poky-linux-gnueabi/4.9.1/lto-wrapper Target: arm-poky-linux-gnueabi Configured with: /prj/oe/omap/build-beaglebone-master/tmp/work-shared/gcc-4.9.1-r0/gcc-4.9.1/configure --build=x86_64-linux --host=arm-poky-linux-gnueabi --target=arm-poky-linux-gnueabi --prefix=/usr --exec_prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/lib/gcc --datadir=/usr/share --sysconfdir=/etc --sharedstatedir=/com --localstatedir=/var --libdir=/usr/lib --includedir=/usr/include --oldincludedir=/usr/include --infodir=/usr/share/info --mandir=/usr/share/man --disable-silent-rules --disable-dependency-tracking --with-libtool-sysroot=/prj/oe/omap/build-beaglebone-master/tmp/sysroots/beaglebone --with-gnu-ld --enable-shared --enable-languages=c,c++ --enable-threads=posix --enable-multilib --enable-c99 --enable-long-long --enable-symvers=gnu --enable-libstdcxx-pch --program-prefix=arm-poky-linux-gnueabi- --without-local-prefix --enable-target-optspace --enable-lto --enable-libssp --disable-bootstrap --disable-libmudflap --with-system-zlib --with-linker-hash-style=gnu --enable-linker-build-id --with-ppl=no --with-cloog=no --enable-checking=release --enable-cheaders=c_global --with-float=hard --with-sysroot=/ --with-build-sysroot=/prj/oe/omap/build-beaglebone-master/tmp/sysroots/beaglebone --with-native-system-header-dir=/prj/oe/omap/build-beaglebone-master/tmp/sysroots/beaglebone/usr/include --with-gxx-include-dir=/usr/include/c++/4.9.1 --enable-nls Thread model: posix gcc version 4.9.1 (GCC) Yocto builds libssp libstdc++-v3 libgomp libatomic separately from gcc for packaging/cross-compile/other reasons that aren't entirely clear to me, so I suspect the issue arises there. But one difference is that I'm using -std=c++1y (and sometimes -std=c++11). Would that be enough to be an ABI change? I haven't encountered issues on x86-64.
[Bug target/62098] [4.9/4.10 regression] incorrect code generated by arm gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62098 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ramana at gcc dot gnu.org
[Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077 --- Comment #16 from Richard Biener rguenth at gcc dot gnu.org --- Ok, so what happens is that for build/genconfig.o we in one case write a STRING_CST with a const char[7] with itself as main-variant and in the other case with char[7] as main-variant. The STRING_CST is written from ipa_write_jump_function 4237case IPA_JF_CONST: 4238 gcc_assert ( 4239 EXPR_LOCATION (jump_func-value.constant.value) == UNKNOWN_LOCATION); 4240 stream_write_tree (ob, jump_func-value.constant.value, true); 4241 break; as #endif[0] Its type main variant is built in c-family/c-common.c:1021 and the literal itself in builtins.c:13383. And we indeed get differences in inline_param2 (min size), otherwise no visible differences anywhere in dumps. Not sure how that can explain the type difference for the jump function though... Again, this is build/genconfig.o as compiled by stage1 cc1plus vs. stage2 cc1plus (so faster to reproduce / bisect).
[Bug fortran/62106] [4.9/4.10 Regression] Adding a scalar variable to an array constructor gives wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62106 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-12 CC||tkoenig at gcc dot gnu.org Summary|Adding a scalar variable to |[4.9/4.10 Regression] |an array constructor gives |Adding a scalar variable to |wrong result|an array constructor gives ||wrong result Ever confirmed|0 |1 Known to fail||4.10.0, 4.9.1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- This is regression from 4.8.3, revision r197010 (2013-03-23) is OK, r197238 (2013-03-29) is not, likely r197216. Workaround: compile with -fno-frontend-optimize.
[Bug target/62098] [4.9/4.10 regression] incorrect code generated by arm gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62098 --- Comment #2 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Created attachment 33300 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33300action=edit Patch under testing. Embarassing patch to fix the issue. Currently being tested .
[Bug ipa/62104] [4.10 Regression] ICE: in update_visibility_by_resolution_info, at ipa-visibility.c:403
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62104 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org --- My PGO/LTO Firefox build script contained an error that caused jsarray.o to be erroneously build with -fprofile-generate during the -fprofile-use phase. The .gcov symbols in that file caused the ICE. Closing as invalid, because this will not normally happen in practice.
[Bug target/61373] neon registers restored incorrectly with -mapcs-frame -O -fno-omit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61373 --- Comment #2 from John Breitenbach breiten at lexmark dot com --- Created attachment 33301 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33301action=edit siphash24.i sorry for forgetting this attachment in the original report.
[Bug preprocessor/61613] ,##__VA_ARGS__ fails to expand the first variadic argument if it is a macro-name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61613 --- Comment #8 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to David Krauss from comment #6) I'd like to take it 100% but the testsuite isn't working on my system. The patch is small enough and unobscure enough that it's easier for someone else to take responsibility than for me to dedicate another day to GCC build configuration. If you are a sporadic contributor, the easiest and cheapest way to work on GCC is to get an account in the compile farm: https://gcc.gnu.org/wiki/CompileFarm and use one of the many scripts in contrib/ (or my own gccfarming script: https://gcc.gnu.org/wiki/ManuelL%C3%B3pezIb%C3%A1%C3%B1ez?action=AttachFiledo=viewtarget=gccfarming) to bootstrap and regression test patches.
[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465 --- Comment #9 from Mike Frysinger vapier at gentoo dot org --- i've verified that 4.8.0 4.9.1 fail as well :/ binutils 2.24 doesn't help
[Bug target/62025] [4.9/4.10 Regression] Miscompilation of openssl sha512.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025 --- Comment #16 from Jeffrey A. Law law at redhat dot com --- In reference to c#12. I think the ivopts changes are just setting up the situation that is mis-handled later. I'd gotten as far as seeing the +128 increment moving in the scheduler, but hadn't looked to see if it was valid. Anyway, so yes I think the ivopts stuff is fine. I should have realized I was chasing something of that nature when the bisection settled on the ivopts code as the trigger.
[Bug preprocessor/58844] [4.8 Regression] ICE with invalid use of ##
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58844 --- Comment #12 from joseph at codesourcery dot com joseph at codesourcery dot com --- On Tue, 12 Aug 2014, potswa at mac dot com wrote: each instance of a ## preprocessing token in the replacement list (not from an argument) is deleted and the preceding preprocessing token is concatenated with the following preprocessing token. This is unambiguous in that consecutive ## tokens get pasted; they can't all be operators. I think my reading was: they are all operators, all get deleted, and then, after the deletion, the (preceding, following) pairs of remaining tokens get concatenated (the concatenations happening in an unspecified order, with it being OK if they do all happen simultaneously). I see nothing to rule out that sequence of events, or any other sequence of deletions and concatenations of tokens (where if the sequence results in ## being concatenated with a non-placemarker, you have undefined behavior). I wouldn't object to a future standard revision tightening up what's allowed here - though if you do the obvious tightening of adding a new Constraint Two consecutive ## preprocessing tokens shall not occur in the replacement list for either form of macro definition. (to C11 6.10.3.3), implementation of that would need to be conditional on the standard version selected (it's clear that macro definitions with consecutive ## are valid at present and only their expansion may result in undefined behavior).
[Bug target/62098] [4.9/4.10 regression] incorrect code generated by arm gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62098 --- Comment #3 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Author: ramana Date: Tue Aug 12 14:32:07 2014 New Revision: 213861 URL: https://gcc.gnu.org/viewcvs?rev=213861root=gccview=rev Log: Fix PR target/62098 2014-08-12 Ramana Radhakrishnan ramana.radhakrish...@arm.com PR target/62098 * config/arm/vfp.md (*combine_vcvtf2i): Fix constraint. Remove unnecessary attributes. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/vfp.md
[Bug preprocessor/58844] [4.8 Regression] ICE with invalid use of ##
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58844 --- Comment #13 from joseph at codesourcery dot com joseph at codesourcery dot com --- Also, in the case of just two consecutive ##, with a placemarker either side, I think however you read it the concatenations are currently valid and you end up with no preprocessing tokens in the expansion. #define m(a,b) ab m(,)
[Bug target/62100] c++11 threads invoke pure virtual function on arm embedded system
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62100 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |UNCONFIRMED Ever confirmed|1 |0 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Peter A. Bigot from comment #4) But one difference is that I'm using -std=c++1y (and sometimes -std=c++11). Would that be enough to be an ABI change? No, it shouldn't be (if it is then it's a bug that needs to be fixed). I agree nothing looks suspicious in that output. If the separately-built libstdc++ uses different configuration that would be a problem, but it's not possible to tell from that output.
[Bug target/61413] __ARM_SIZEOF_WCHAR_T is constant 32 -- should be 4 or 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61413 --- Comment #2 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Author: ramana Date: Tue Aug 12 14:59:23 2014 New Revision: 213864 URL: https://gcc.gnu.org/viewcvs?rev=213864root=gccview=rev Log: Fix PR target/61413 2014-08-12 Ramana Radhakrishnan ramana.radhakrish...@arm.com PR target/61413 * config/arm/arm.h (TARGET_CPU_CPP_BUILTINS): Fix definition of __ARM_SIZEOF_WCHAR_T. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.h
[Bug fortran/60357] [F08] structure constructor with unspecified values for allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60357 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- Note that while program testerprog use testmod Type(A) :: Me Me%y=2 print *, Me%x, Me%y end program gives at run time 1 2 program testerprog use testmod Type(A) :: Me allocate(Me%y) Me = A(X=1, y=2) print *, Me%y end program gives Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
[Bug fortran/62087] A Piece of code compiling with ifort but giving error by gfortran 4.8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62087 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-08-12 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- There insufficient and clear code to reproduce the issue. Please attach a complete self-contained example. I was considering the same question.
[Bug libfortran/62094] Program crash when executing DEALLOCATE with addresses that have 0 in bits 26 and higher (little-endian)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62094 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-08-12 Ever confirmed|0 |1 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- Looks like a bug in glibc exposed by gfortran. So this PR could be closed as invalid (the attached test works on x86_64-apple-darwin13).
[Bug ipa/62108] New: Resolution of mismatched __attribute__ ((__section__ ())) changes between 4.9 and 4.10.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62108
Bug ID: 62108
Summary: Resolution of mismatched __attribute__ ((__section__
())) changes between 4.9 and 4.10.
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: jgreenhalgh at gcc dot gnu.org
In this testcase:
void func(void);
void __attribute__((__section__(bar)))
func (void)
{
}
There is a mismatch between the section attribute given to the prototype (none,
so .text) and the definition (bar) of func.
Compiling this testcase with a 4.9 and a 4.10 compiler using
gcc test.c -c
and dumping with
objdump -x
Gives different results between 4.9.1 (4.9.1 release) and 4.10.0 (20140803
(experimental)):
$ objdump -x 4.9.o | grep func
g F bar0006 func
$ objdump -x 4.10.o | grep func
g F .text0007 func
This trips up an ARM kernel build.
We should either error on the mismatch, provide a consistent behaviour, or
document the change if this is expected.
[Bug libfortran/62094] Program crash when executing DEALLOCATE with addresses that have 0 in bits 26 and higher (little-endian)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62094 --- Comment #5 from Steve Kargl sgk at troutmask dot apl.washington.edu --- On Tue, Aug 12, 2014 at 03:40:06PM +, dominiq at lps dot ens.fr wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62094 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-08-12 Ever confirmed|0 |1 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- Looks like a bug in glibc exposed by gfortran. So this PR could be closed as invalid (the attached test works on x86_64-apple-darwin13). It also works on x86_64-*-freebsd. Hopefully, OP reports to glibc and tells us.
[Bug ipa/62108] Resolution of mismatched __attribute__ ((__section__ ())) changes between 4.9 and 4.10.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62108 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Exact dup of my bug which I filed and even contains a patch which I need to submit. *** This bug has been marked as a duplicate of bug 61848 ***
[Bug middle-end/61848] [4.10 Regression] a previous declaration causes the section attribute to be lost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61848 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||jgreenhalgh at gcc dot gnu.org --- Comment #7 from Andrew Pinski pinskia at gcc dot gnu.org --- *** Bug 62108 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/61441] ARM aarch64 fails to quiet signaling NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61441 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||ramana at gcc dot gnu.org Component|target |tree-optimization --- Comment #1 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- I see the same behaviour on x86_64-linux-gnu , there is nothing specific about this behaviour with respect to the AArch64 port. I can see this is ccp that causes the propagation in the brief time I looked at it. What I haven't yet done is audit the options bits to work out what the issues here.
[Bug lto/54078] Bytemark 46% bigger binary with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54078 --- Comment #10 from wbrana wbrana at gmail dot com --- there is difference also with O2 and branch 4.9 size in bytes 57199 -O2 55222 -O2 -flto 60681 -O2 -finline-functions 75301 -O2 -flto -finline-functions 67083 -O2 -flto -finline-functions --param large-unit-insns=1000
[Bug driver/61274] excessive code size with large-unit-insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61274 --- Comment #2 from wbrana wbrana at gmail dot com --- gcc should probably support new level -O4 which will optimize for benchmarks, which will equal to current -O3 -O3 and bellow will optimize for applications with saner --param values
[Bug target/62109] New: __gthr_i486_lock_cmp_xchg missing clobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109 Bug ID: 62109 Summary: __gthr_i486_lock_cmp_xchg missing clobber Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: gccbugzilla at limegreensocks dot com Created attachment 33302 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33302action=edit Update __gthr_i486_lock_cmp_xchg to add memory clobber InterlockedCompareExchange is an implicit memory barrier. Such being the case, the asm needs to use the memory clobber.
[Bug c++/60336] empty struct value is passed differently in C and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Component|target |c++ Version|4.8.1 |4.10.0 --- Comment #22 from H.J. Lu hjl.tools at gmail dot com --- This is a target independent issue. Clang++ skips empty struct argument and g++ passes it. Skip empty struct argument requires middle-end changes.
[Bug c++/62110] New: Attempting to use template conversion operator in a contextual conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62110
Bug ID: 62110
Summary: Attempting to use template conversion operator in a
contextual conversion
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: yaghmour.shafik at gmail dot com
Given the following code:
class Var
{
public:
operator int () const
{ return 0; }
template typename T
operator T () const
{ return T(); }
};
int main()
{
Var v;
switch (v)
{ }
}
gcc 4.9 produces the following error:
main.cpp: In function 'int main()':
main.cpp:17:14: error: default type conversion can't deduce template argument
for 'templateclass T Var::operator T() const'
switch (v)
^
using the following command line options:
-std=c++11 -Wall -Wextra -Wconversion -pedantic
Using -std=c++1y also produces the same error.
while clang 3.4 does not produce any errors. As far as I can tell clang is
correct here for C++1y and is probably correct for C++11 although that may
depend on whether you consider N3323: A Proposal to Tweak Certain C++
Contextual Conversions to be a fix for C++11 or part of C++1y.
N3323 is incorporated in N3485 which I consider to be C++11 with fixes but
perhaps that is an incorrect interpretation. Based on this assumption then if
we look at section 6.4.2 it says:
The condition shall be of integral type, enumeration type, or class type. If of
class type, the condition is contextually implicitly converted (Clause 4) to an
integral or enumeration type.
and this would force us to use section 4 paragraph 5 which does not allow or
overload resolution making int conversion the only one available for this
context.
If N3323 is not part of C++11 then it seems unclear to me whether the template
conversion function should be considered or not.
This bug report comes the following Stackoverflow question:
http://stackoverflow.com/questions/25047109/classes-with-both-template-and-non-template-conversion-operators-in-the-conditio
[Bug target/62111] New: ICE when building Linux kernel for sh64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62111
Bug ID: 62111
Summary: ICE when building Linux kernel for sh64
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dhowells at redhat dot com
Created attachment 33303
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33303action=edit
Reduced preprocessed source
When trying to build the kernel with an sh64 cross-compiler, I get the
following error:
sh64-linux-gnu-gcc -Wp,-MD,arch/sh/kernel/.setup.o.d -nostdinc -isystem
/usr/lib/gcc/sh64-linux-elf/4.9.1/include -I../arch/sh/include
-Iarch/sh/include/generated -I../include -Iinclude -I../arch/sh/include/uapi
-Iarch/sh/include/generated/uapi -I../include/uapi -Iinclude/generated/uapi
-include ../include/linux/kconfig.h -I../arch/sh/kernel -Iarch/sh/kernel
-D__KERNEL__ -m5-64media-nofpu -ml -Wa,-isa=shmedia -ffreestanding
-I../arch/sh/include/cpu-sh5 -Iarch/sh/include/cpu-sh5
-I../arch/sh/include/cpu-common -Iarch/sh/include/cpu-common
-I../arch/sh/include/mach-common -Iarch/sh/include/mach-common -Wall -Wundef
-Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common
-Werror-implicit-function-declaration -Wno-format-security -pipe
-m5-64media-nofpu -ml -Wa,-isa=shmedia -ffreestanding
-I../arch/sh/include/cpu-sh5 -Iarch/sh/include/cpu-sh5
-I../arch/sh/include/cpu-common -Iarch/sh/include/cpu-common
-I../arch/sh/include/mach-common -Iarch/sh/include/mach-common
-fno-delete-null-pointer-checks -O2 --param=allow-store-data-races=0
-Wframe-larger-than=1024 -fno-stack-protector -Wno-unused-but-set-variable
-fno-omit-frame-pointer -fno-optimize-sibling-calls
-fno-var-tracking-assignments -Wdeclaration-after-statement -Wno-pointer-sign
-fno-strict-overflow -fconserve-stack -Werror=implicit-int
-Werror=strict-prototypes -Werror=date-time -DCC_HAVE_ASM_GOTO -Werror
-DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(setup)
-DKBUILD_MODNAME=KBUILD_STR(setup) -c -o arch/sh/kernel/setup.o
../arch/sh/kernel/setup.c
../arch/sh/kernel/setup.c: In function 'setup_arch':
../arch/sh/kernel/setup.c:312:1: internal compiler error: in sh_print_operand,
at config/sh/sh.c:1359
}
^
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugzilla.redhat.com/bugzilla/ for instructions.
{standard input}: Assembler messages:
{standard input}:365: Warning: partial line at end of file ignored
Preprocessed source stored into /tmp/ccQ2JuUO.out file, please attach this to
your bugreport.
A reduced version of the preprocessed source is attached
[Bug target/62111] ICE when building Linux kernel for sh64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62111 --- Comment #1 from dhowells at redhat dot com dhowells at redhat dot com --- The following command line is sufficient to reproduce the error: sh64-linux-gnu-gcc -m5-64media-nofpu -ml -O2 -S -o testcase.o testcase.i Adding -v to the command line: Using built-in specs. COLLECT_GCC=/usr/bin/sh64-linux-gnu-gcc Target: sh64-linux-elf Configured with: ../gcc-4.9.1-20140717/configure --bindir=/usr/bin --build=x86_64-redhat-linux-gnu --datadir=/usr/share --disable-decimal-float --disable-dependency-tracking --disable-gold --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-nls --disable-plugin --disable-shared --disable-silent-rules --disable-sjlj-exceptions --disable-threads --enable-checking= --enable-gnu-unique-object --enable-initfini-array --enable-languages=c,c++ --enable-linker-build-id --enable-nls --enable-obsolete --enable-targets=all --exec-prefix=/usr --host=x86_64-redhat-linux-gnu --includedir=/usr/include --infodir=/usr/share/info --libexecdir=/usr/libexec --localstatedir=/var --mandir=/usr/share/man --prefix=/usr --program-prefix=sh64-linux-gnu- --sbindir=/usr/sbin --sharedstatedir=/var/lib --sysconfdir=/etc --target=sh64-linux-elf --with-bugurl=http://bugzilla.redhat.com/bugzilla/ --with-linker-hash-style=gnu --with-newlib --with-sysroot=/usr/sh64-linux-gnu/sys-root --with-system-libunwind --with-system-zlib --without-headers --with-isl=/data/fedora/cross-gcc/gcc-4.9.1-20140717/isl-install --with-cloog=/data/fedora/cross-gcc/gcc-4.9.1-20140717/cloog-install --with-multilib-list=m5-32media,m5-32media-nofpu,m5-compact,m5-compact-nofpu,m5-64media,m5-64media-nofpu Thread model: single gcc version 4.9.1 20140717 (Red Hat Cross 4.9.1-2) (GCC) COLLECT_GCC_OPTIONS='-m5-64media-nofpu' '-ml' '-O2' '-S' '-o' 'setup.o' '-v' /usr/libexec/gcc/sh64-linux-elf/4.9.1/cc1 -fpreprocessed testcase-min.i -quiet -dumpbase testcase-min.i -m5-64media-nofpu -ml -auxbase-strip setup.o -O2 -version -o setup.o GNU C (GCC) version 4.9.1 20140717 (Red Hat Cross 4.9.1-2) (sh64-linux-elf) compiled by GNU C version 4.8.3 20140624 (Red Hat 4.8.3-1), GMP version 5.1.2, MPFR version 3.1.2, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C (GCC) version 4.9.1 20140717 (Red Hat Cross 4.9.1-2) (sh64-linux-elf) compiled by GNU C version 4.8.3 20140624 (Red Hat 4.8.3-1), GMP version 5.1.2, MPFR version 3.1.2, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: fb8656871dc1cbba0b3d802cd873a004 testcase-min.i: In function ‘setup_arch’: testcase-min.i:20:1: internal compiler error: in sh_print_operand, at config/sh/sh.c:1359 } ^ Please submit a full bug report, with preprocessed source if appropriate. See http://bugzilla.redhat.com/bugzilla/ for instructions. Preprocessed source stored into /tmp/cctH44XH.out file, please attach this to your bugreport.
[Bug target/62111] ICE when building Linux kernel for sh64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62111 --- Comment #2 from dhowells at redhat dot com dhowells at redhat dot com --- The binutils is based on the 2.24 branch, git commit cab6c3ee9785f072a373afe31253df0451db93cf and was built targeting sh64-linux-elf.
[Bug tree-optimization/62112] New: Optimize out malloc when block is unused or write-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62112
Bug ID: 62112
Summary: Optimize out malloc when block is unused or write-only
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zackw at panix dot com
This program
#include string.h
#include stdlib.h
int
main(void)
{
size_t n = 1000;
float *x = calloc(n,sizeof(float));
float *y = malloc(n*sizeof(float));
if (x y)
memcpy(y,x,sizeof(float)*n);
return 0;
}
can be optimized (in the absence of `-fno-builtin-(memcpy|malloc|calloc)`) to
int main(void) { return 0; }
because: the memory block pointed to by `y` is write-only, so the `memcpy` and
`malloc` can be discarded; after that is done, the memory block pointed to by
`x` is unused, so that allocation can be discarded as well.
`calloc` is used here to avoid any question of UB due to reading uninitialized
memory even within `memcpy`. The optimization should apply to all
heap-allocation functions, including especially C++ operator new (as long as
the constructor has no side effects outside the just-allocated object).
Clang 3.5 does perform this optimization.
[Bug c/62113] New: [graphite] ICE using -floop-parallelize-all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62113 Bug ID: 62113 Summary: [graphite] ICE using -floop-parallelize-all Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: drfiemost at email dot it Created attachment 33304 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33304action=edit Preprocessed source gcc -O2 -floop-parallelize-all -c rdft.i ends up eating all memory (8Gb) and then dies: gcc: internal compiler error: Killed (program cc1) Reproduced with both 4.8 and 4.9: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.8.4/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.8-20140807/configure --prefix=/usr --enable-shared --disable-static --disable-dependency-tracking --enable-languages=c,c++ --disable-multilib --with-system-zlib --disable-bootstrap Thread model: posix gcc version 4.8.4 20140807 (prerelease) (GCC) Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.9.1/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.9.1/configure --prefix=/usr --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++ --disable-multilib --disable-bootstrap --with-system-zlib --disable-static --disable-dependency-tracking Thread model: posix gcc version 4.9.1 (GCC)
[Bug c/62114] New: [graphite] ICE using -floop-parallelize-all and -ffast-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62114 Bug ID: 62114 Summary: [graphite] ICE using -floop-parallelize-all and -ffast-math Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: drfiemost at email dot it Created attachment 33305 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33305action=edit Preprocessed source gcc -O2 -floop-parallelize-all -ffast-math -c cvt.i cvt.c: In function ‘Pobsopen’: cvt.c:62:12: internal compiler error: Segmentation fault Reproduced with both 4.8 and 4.9: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.8.4/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.8-20140807/configure --prefix=/usr --enable-shared --disable-static --disable-dependency-tracking --enable-languages=c,c++ --disable-multilib --with-system-zlib --disable-bootstrap Thread model: posix gcc version 4.8.4 20140807 (prerelease) (GCC) Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.9.1/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.9.1/configure --prefix=/usr --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++ --disable-multilib --disable-bootstrap --with-system-zlib --disable-static --disable-dependency-tracking Thread model: posix gcc version 4.9.1 (GCC)
[Bug target/62111] ICE when building Linux kernel for sh64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62111 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Target||sh*-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-12 CC||olegendo at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Oleg Endo olegendo at gcc dot gnu.org --- I'll see what I can do.
[Bug target/62111] ICE when building Linux kernel for sh64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62111 --- Comment #4 from dhowells at redhat dot com dhowells at redhat dot com --- The compiler is gcc-4.9.1, dated 20140717, svnrev 212747. One patch is applied - see bug 61844.
[Bug c++/62110] Attempting to use template conversion operator in a contextual conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62110 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- N3323 is not addressing a DR, so is not part of C++11.
[Bug tree-optimization/62112] Optimize out malloc when block is unused or write-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62112 --- Comment #1 from Marc Glisse glisse at gcc dot gnu.org --- Main issue here is that DSE only applies to assignments and not function calls like memcpy (there must be a few dups somewhere), so we never remove memcpy, even if we call free(x);free(y); afterwards. With a for loop instead we optimize it just fine.
[Bug tree-optimization/62112] Optimize out malloc when block is unused or write-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62112 --- Comment #2 from Zack Weinberg zackw at panix dot com --- I observe that the `memcpy` does get lowered to inline code. Is it just a phase-ordering problem that we then don't detect the stores as dead?
[Bug target/62025] [4.9/4.10 Regression] Miscompilation of openssl sha512.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025 --- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Tue Aug 12 21:24:40 2014 New Revision: 213887 URL: https://gcc.gnu.org/viewcvs?rev=213887root=gccview=rev Log: PR target/62025 * sched-deps.c (find_inc): Check if inc_insn doesn't clobber any registers that are used in mem_insn. Modified: trunk/gcc/ChangeLog trunk/gcc/sched-deps.c
[Bug target/62025] [4.9/4.10 Regression] Miscompilation of openssl sha512.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025 --- Comment #18 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Tue Aug 12 22:03:37 2014 New Revision: 213888 URL: https://gcc.gnu.org/viewcvs?rev=213888root=gccview=rev Log: PR target/62025 * sched-deps.c (find_inc): Check if inc_insn doesn't clobber any registers that are used in mem_insn. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/sched-deps.c
[Bug tree-optimization/54742] Switch elimination in FSM loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54742 --- Comment #38 from Steve Ellcey sje at gcc dot gnu.org --- FYI: I am testing a new patch for this that adds a new pass to do this optimization. See https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01228.html
[Bug c++/60336] empty struct value is passed differently in C and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336 --- Comment #23 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to H.J. Lu from comment #22) This is a target independent issue. Clang++ skips empty struct argument and g++ passes it. Skip empty struct argument requires middle-end changes. Except in c++, the struct is non zero in size.
[Bug c++/62085] SFINAE where specialization parameter class member returns an abstract type fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62085
--- Comment #3 from James Lyon jameslyon0 at gmail dot com ---
Thanks for looking! Unfortunately I don't have access to EDG. I have dug
through the standard and it seems my understanding of SFINAE was (is) a
bit lacking and GCC is indeed correct. It seems there's a bug in clang
here instead.
On 11/08/14 11:12, redi at gcc dot gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62085
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org ---
For a short piece of code with no external dependencies it's simpler to just
paste it into a comment than attach it:
templatetypename T
struct A {
T f();
};
templatetypename T, typename Enable=void struct B {};
templatetypename T struct BT, typename AT::type {};
struct C {
virtual ~C() = 0;
};
int main() {
BC();
}
EDG rejects it for the same reason as GCC.
[Bug c++/62115] New: [4.10 Regression] ICE with invalid default argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62115
Bug ID: 62115
Summary: [4.10 Regression] ICE with invalid default argument
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
CC: jason at gcc dot gnu.org, paolo at gcc dot gnu.org
The following invalid code snippet triggers an ICE on trunk:
struct A {};
struct B : A {};
struct C
{
C(A a = B()) {}
};
C c;
bug.cc:6:14: internal compiler error: in convert_like_real, at cp/call.c:6382
C(A a = B()) {}
^
0x5720b8 convert_like_real
../../gcc/gcc/cp/call.c:6382
0x57240f perform_implicit_conversion_flags(tree_node*, tree_node*, int, int)
../../gcc/gcc/cp/call.c:9289
0x58fb4d check_default_argument(tree_node*, tree_node*, int)
../../gcc/gcc/cp/decl.c:11092
0x682547 cp_parser_late_parse_one_default_arg
../../gcc/gcc/cp/parser.c:23926
0x671b8b cp_parser_late_parsing_default_args
../../gcc/gcc/cp/parser.c:24016
0x671b8b cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:19700
0x6741d0 cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:19771
0x6741d0 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:14522
0x68c994 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:11763
0x692639 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:11353
0x676403 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:11302
0x69cd25 cp_parser_declaration
../../gcc/gcc/cp/parser.c:11199
0x69b9d8 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:11085
0x69d273 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4061
0x69d273 c_parse_file()
../../gcc/gcc/cp/parser.c:31951
0x7c1442 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1115
Please submit a full bug report, [etc.]
The regression was introduced between 2014-05-13 and 2014-05-20.
Paolo, Jason, this might be fallout from your patches on 2014-05-14.
[Bug c++/62115] [4.10 Regression] ICE with invalid default argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62115 Volker Reichelt reichelt at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.10.0
[Bug c++/62110] Attempting to use template conversion operator in a contextual conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62110 TC rs2740 at gmail dot com changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #2 from TC rs2740 at gmail dot com --- According to https://gcc.gnu.org/projects/cxx1y.html, N3323 should have been implemented in GCC 4.9 with -std=c++1y.
[Bug debug/54773] no debug info generated for rvalue reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54773 --- Comment #2 from chihin ko chihin.ko at oracle dot com --- g++ 4.8.1 on Linux fixed the problem, but problem still exists in g++ 4.8.1 on solaris.
[Bug c++/62116] New: Allowing redeclaration of global variable x using ::x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62116
Bug ID: 62116
Summary: Allowing redeclaration of global variable x using ::x
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: yaghmour.shafik at gmail dot com
Given the following code:
int x;
int main() {
int(::x); //does not compile
int(::x + 2); //compiles
}
gcc 4.9 will compile it without an error while gcc 4.8.x and clang 3.4 will
generate an error. For gcc 4.8.x the error is:
error: invalid use of qualified-name '::x'
int(::x); //does not compile
^
and clang gives the following error:
error: definition or redeclaration of 'x' cannot name the global scope
int(::x); //does not compile
~~^
as far as I can tell both gcc 4.8.x and clang are correct here based on my
reading of section 8.3 paragraph 6:
int(::x) ;
is equivalent to:
int ::x ;
which is not valid.
The problem originally cam up in the following Stackoverflow question:
http://stackoverflow.com/questions/24623071/is-typex-valid
[Bug target/62025] [4.9/4.10 Regression] Miscompilation of openssl sha512.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62025
bin.cheng amker.cheng at gmail dot com changed:
What|Removed |Added
CC||amker.cheng at gmail dot com
--- Comment #19 from bin.cheng amker.cheng at gmail dot com ---
(In reply to Jeffrey A. Law from comment #16)
In reference to c#12. I think the ivopts changes are just setting up the
situation that is mis-handled later. I'd gotten as far as seeing the +128
increment moving in the scheduler, but hadn't looked to see if it was valid.
Anyway, so yes I think the ivopts stuff is fine.
I should have realized I was chasing something of that nature when the
bisection settled on the ivopts code as the trigger.
Yes, The scheduling behavior is triggered by specific offset in this case. It
changes below insn sequence:
11405: ..
11406: {%r2:SI=ltu(%cc:CCL1,0)+%r2:SI+[%r8:SI+0xf8];clobber %cc:CC;}
..
2803: {%r8:SI=%r8:SI+0x80;clobber %cc:CC;}
REG_UNUSED %cc:CC
into:
11405: ..
2803: {%r8:SI=%r8:SI+0x80;clobber %cc:CC;}
REG_UNUSED %cc:CC
11406: {%r2:SI=ltu(%cc:CCL1,0)+%r2:SI+[%r8:SI+0x78];clobber %cc:CC;}
by changing the offset in insn 11406.
The problem is why minipass in
http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00155.html would do this
transformation. According to the description, it is to change
rn++
rm=[rn]
into
rm=[rn+4]
rn++
Here it is exactly the opposite tranformation and introducing more dependency.
Thanks.
[Bug c++/60336] empty struct value is passed differently in C and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336
--- Comment #24 from vagran vagran.ast at gmail dot com ---
Just to be on a safe side, please, also do not forget that empty struct (or
class) is really zero in the case when another structure (or class) is derived
from it. For example, such test would be useful after fix:
struct A {};
struct B: A {
int i;
};
assert(sizeof(B) == sizeof(int));
And something like this:
struct A {};
struct B: A {};
struct C: B {};
struct D: C {};
assert(sizeof(D) == 1);
[Bug c/62024] __atomic_always_lock_free is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62024 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-13 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |4.10.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed even for C++. The issue is the same: fold folds __atomic_always_lock_free to 1, but that 1 is wrapped in NOP_EXPR - and static assert code is unhappy. I think we can just STRIP_TYPE_NOPS - we don't expect an lvalue in the static assert code. I'm testing a patch for that. Not a regression.
[Bug c/62024] __atomic_always_lock_free is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62024 --- Comment #2 from Amanieu d'Antras amanieu at gmail dot com --- A similar error happens when trying to use the result of __atomic_always_lock_free as the size of an array: int array[__atomic_always_lock_free(sizeof(int), 0)]; test.c:1:5: error: variably modified ‘array’ at file scope
