[Bug middle-end/57393] [4.9 Regression] error: definition in block 4 follows the use / internal compiler error: verify_ssa failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57393 --- Comment #31 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Easwaran Raman from comment #30) Created attachment 30727 [details] New patch fixes all previously observed issues and further light testing.
[Bug tree-optimization/58277] [4.7/4.8/4.9 Regression] wrong code at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58277 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |4.7.4 Summary|wrong code at -O3 |[4.7/4.8/4.9 Regression] |(affecting 4.7, 4.8, and|wrong code at -O3 |trunk) | --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Both testcases started to fail with r181172.
[Bug tree-optimization/58010] [4.8/4.9 Regression] ICE in vect_create_epilog_for_reduction, at tree-vect-loop.c:4378
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58010 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Fri Aug 30 07:47:54 2013 New Revision: 202095 URL: http://gcc.gnu.org/viewcvs?rev=202095root=gccview=rev Log: 2013-08-30 Richard Biener rguent...@suse.de PR tree-optimization/58010 * tree-vect-loop.c (vect_create_epilog_for_reduction): Remove assert that we have a loop-closed PHI. * gcc.dg/pr58010.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr58010.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug tree-optimization/58223] [4.8/4.9 Regression] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58223 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Fri Aug 30 07:48:53 2013 New Revision: 202096 URL: http://gcc.gnu.org/viewcvs?rev=202096root=gccview=rev Log: 2013-08-30 Richard Biener rguent...@suse.de PR tree-optimization/58223 * tree-loop-distribution.c (has_anti_dependence): Rename to ... (has_anti_or_output_dependence): ... this and adjust to also look for output dependences. (mark_nodes_having_upstream_mem_writes): Adjust. (rdg_flag_uses): Likewise. * gcc.dg/torture/pr58223.c: New testcase. * gcc.dg/tree-ssa/ldist-16.c: Flip expected behavior. Added: trunk/gcc/testsuite/gcc.dg/torture/pr58223.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/ldist-16.c trunk/gcc/tree-loop-distribution.c
[Bug tree-optimization/58228] [4.7/4.8/4.9 Regression] wrong code (with vectorization?) at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58228 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Fri Aug 30 07:49:54 2013 New Revision: 202097 URL: http://gcc.gnu.org/viewcvs?rev=202097root=gccview=rev Log: 2013-08-30 Richard Biener rguent...@suse.de PR tree-optimization/58228 * tree-vect-data-refs.c (vect_analyze_data_ref_access): Do not allow invariant loads in nested loop vectorization. * gcc.dg/torture/pr58228.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr58228.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-data-refs.c
[Bug tree-optimization/58223] [4.8 Regression] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58223 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.9.0 Target Milestone|4.8.3 |4.8.2 Summary|[4.8/4.9 Regression] wrong |[4.8 Regression] wrong code |code at -O3 on |at -O3 on x86_64-linux-gnu |x86_64-linux-gnu| Known to fail|4.9.0 | --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Fixed on trunk sofar.
[Bug tree-optimization/58010] [4.8 Regression] ICE in vect_create_epilog_for_reduction, at tree-vect-loop.c:4378
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58010 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.9.0 Summary|[4.8/4.9 Regression] ICE in |[4.8 Regression] ICE in |vect_create_epilog_for_redu |vect_create_epilog_for_redu |ction, at |ction, at |tree-vect-loop.c:4378 |tree-vect-loop.c:4378 Known to fail|4.9.0 | --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- Fixed on trunk sofar.
[Bug tree-optimization/58228] [4.7/4.8 Regression] wrong code (with vectorization?) at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58228 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Known to work||4.9.0 Summary|[4.7/4.8/4.9 Regression]|[4.7/4.8 Regression] wrong |wrong code (with|code (with vectorization?) |vectorization?) at -O3 on |at -O3 on x86_64-linux-gnu |x86_64-linux-gnu| Known to fail|4.9.0 | --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Fixed on trunk sofar.
[Bug tree-optimization/58246] [4.7/4.8 Regression] wrong code at -O1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58246 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.9.0 Summary|[4.7/4.8/4.9 Regression]|[4.7/4.8 Regression] wrong |wrong code at -O1 and above |code at -O1 and above --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Fixed on trunk sofar.
[Bug tree-optimization/58247] [4.9 Regression] ICE in tree_unroll_loops_completely at -O3 (both 32-bit and 64-bit modes)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58247 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- I see t.c: In function 'foo': t.c:14:6: error: definition in block 5 follows the use void foo () ^ for SSA_NAME: _35 in statement: a.2_88 = _32 _35; t.c:14:6: internal compiler error: verify_ssa failed after reassoc. *** This bug has been marked as a duplicate of bug 57393 ***
[Bug middle-end/57393] [4.9 Regression] error: definition in block 4 follows the use / internal compiler error: verify_ssa failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57393 --- Comment #32 from Richard Biener rguenth at gcc dot gnu.org --- *** Bug 58247 has been marked as a duplicate of this bug. ***
[Bug middle-end/57393] [4.9 Regression] error: definition in block 4 follows the use / internal compiler error: verify_ssa failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57393 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||dhazeghi at yahoo dot com --- Comment #33 from Richard Biener rguenth at gcc dot gnu.org --- *** Bug 57592 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/57592] [4.9 Regression] ICE in tree_unroll_loops_completely at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57592 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- t.c: In function 'f': t.c:4:1: error: definition in block 3 follows the use f () ^ for SSA_NAME: _27 in statement: d_55 = _27 | _30; t.c:4:1: internal compiler error: verify_ssa failed after reassoc *** This bug has been marked as a duplicate of bug 57393 ***
[Bug tree-optimization/58277] [4.7/4.8/4.9 Regression] wrong code at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58277 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-08-30 CC||matz at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- Thus confirmed.
[Bug tree-optimization/58277] [4.7/4.8/4.9 Regression] wrong code at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58277 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- But, skimming through the dumps, it looks like it is the strlen pass that removes the important n = 0; store.
[Bug tree-optimization/58277] [4.7/4.8/4.9 Regression] wrong code at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58277 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 30728 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30728action=edit gcc49-pr58277.patch Untested fix.
[Bug ada/58239] [4.9 regression] pretty-print.c:789: undefined reference to `operator delete(void*)'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58239
Iain Sandoe iains at gcc dot gnu.org changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #8 from Iain Sandoe iains at gcc dot gnu.org ---
note that the patch at:
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01460.html
is not quite enough to fix this on Darwin - since we use :
%{static|static-libgcc|static-libstdc++:%:replace-outfile(-lstdc++
libstdc++.a%s)}
to implement -static-libstadc++.
The relevant dir needs to be added as -B for this to work - unfortunately,
I'm not able to look at this right now..
[Bug target/58278] New: visibility bug from #26905 still happens with the sparc64 backend
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58278 Bug ID: 58278 Summary: visibility bug from #26905 still happens with the sparc64 backend Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: martin at netbsd dot org Created attachment 30729 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30729action=edit test for bug 26905 Compiling the test from #26905 with -fPIC -shared -S... on sparc64 creates this output: --8-- .file conftest.cc .section.text .align 4 .global _Z8TestFuncv .type _Z8TestFuncv, #function .proc 020 _Z8TestFuncv: .LLFB0: .cfi_startproc save%sp, -176, %sp .cfi_window_save .cfi_register 15, 31 .cfi_def_cfa_register 30 call_ZN10TestStruct4InitEv, 0 nop return %i7+8 nop .cfi_endproc .LLFE0: .size _Z8TestFuncv, .-_Z8TestFuncv .ident GCC: (GNU) 4.8.1 --8-- note the missing PLT call.
[Bug ipa/58279] New: Interanl compiler error while pgo compilation at ipa-inline.c:902
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58279 Bug ID: 58279 Summary: Interanl compiler error while pgo compilation at ipa-inline.c:902 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: evstupac at gmail dot com CoreMark (www.coremark.org) build with: make PORT_DIR=linux64 XCFLAGS=-fprofile-generate -DTOTAL_DATA_SIZE=1200 -DPROFILE_RUN=1 -DMULTITHREAD=1 -DMEM_METHOD=MEM_STATIC REBUILD=1 run3.log; make PORT_DIR=linux64 XCFLAGS=-fprofile-use -DMULTITHREAD=1 -DMEM_METHOD=MEM_STATIC REBUILD=1 run1.log Generates ICE on 4.8 and 4.9 GCC: internal compiler error: in edge_badness, at ipa-inline.c:902 } ^ 0xd76dbb edge_badness gcc/ipa-inline.c:902 0x4f428d add_new_edges_to_heap gcc/ipa-inline.c:1391 0xd7a34d inline_small_functions gcc/ipa-inline.c:1743 0xd7a34d ipa_inline gcc/ipa-inline.c:1924 0xd7a34d execute gcc/ipa-inline.c:2320 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.
[Bug ipa/58279] Interanl compiler error while pgo compilation at ipa-inline.c:902
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58279 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-08-30 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Please submit a full bug report, with preprocessed source if appropriate.
[Bug c/58231] Using post-decrement as a boolean expression in if statement leads to crash
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58231 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Feedback not coming.
[Bug ipa/58279] Interanl compiler error while pgo compilation at ipa-inline.c:902
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58279 --- Comment #2 from Stupachenko Evgeny evstupac at gmail dot com --- I can't share CoreMark sources. However, you can get them at www.coremark.org when accept the license. The error caused by edge-count of new edges which is grater than max_count: (line 902) gcc_assert (max_count = edge-count); The new edge is generated in case of indirect inline: (line 1517) if (flag_indirect_inlining) new_indirect_edges.create (8); and does not participate in max_count calculation, but refers to it when adding to a heap: (lines 1724 and 1761) if (flag_indirect_inlining) add_new_edges_to_heap (edge_heap, new_indirect_edges); Updating max_count with new_edges counts resolves the ICE.
[Bug ipa/58279] Interanl compiler error while pgo compilation at ipa-inline.c:902
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58279 --- Comment #3 from pinskia at gmail dot com pinskia at gmail dot com --- I have a fix which I hope to share in the next few weeks. Sent from my iPad On Aug 30, 2013, at 3:31 AM, evstupac at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58279 --- Comment #2 from Stupachenko Evgeny evstupac at gmail dot com --- I can't share CoreMark sources. However, you can get them at www.coremark.org when accept the license. The error caused by edge-count of new edges which is grater than max_count: (line 902) gcc_assert (max_count = edge-count); The new edge is generated in case of indirect inline: (line 1517) if (flag_indirect_inlining) new_indirect_edges.create (8); and does not participate in max_count calculation, but refers to it when adding to a heap: (lines 1724 and 1761) if (flag_indirect_inlining) add_new_edges_to_heap (edge_heap, new_indirect_edges); Updating max_count with new_edges counts resolves the ICE.
Re: [Bug ipa/58279] Interanl compiler error while pgo compilation at ipa-inline.c:902
I have a fix which I hope to share in the next few weeks. Sent from my iPad On Aug 30, 2013, at 3:31 AM, evstupac at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58279 --- Comment #2 from Stupachenko Evgeny evstupac at gmail dot com --- I can't share CoreMark sources. However, you can get them at www.coremark.org when accept the license. The error caused by edge-count of new edges which is grater than max_count: (line 902) gcc_assert (max_count = edge-count); The new edge is generated in case of indirect inline: (line 1517) if (flag_indirect_inlining) new_indirect_edges.create (8); and does not participate in max_count calculation, but refers to it when adding to a heap: (lines 1724 and 1761) if (flag_indirect_inlining) add_new_edges_to_heap (edge_heap, new_indirect_edges); Updating max_count with new_edges counts resolves the ICE.
[Bug c++/14932] [3.4/4.0 Regression] cannot use offsetof to get offsets of array elements in g++ 3.4.0 prerelease
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14932
zhangjingwang at gmail dot com changed:
What|Removed |Added
CC||zhangjingwang at gmail dot com
--- Comment #14 from zhangjingwang at gmail dot com ---
#include stdio.h
#include stddef.h
struct TestStruct {
int array[13];
};
struct TempStruct {
int index;
};
int array_offset(struct TempStruct *index)
{
return offsetof(struct TestStruct, array[index-index]);
}
int main(int argc, char **argv)
{
struct TempStruct tmp = {3};
printf(Offset of array[3] is %d.\n, array_offset(tmp));
}
test.c: In function 'int array_offset(TempStruct*)':
test.c:14: error: 'index' cannot appear in a constant-expression
test.c:14: error: '-' cannot appear in a constant-expression
This can't be compiled by the following versions of g++ (while it is accepted
by gcc of the same version and clang++ 3.4):
g++ (Debian 4.4.5-8) 4.4.5
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
:AND:
g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-3)
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
So I don't think this bug is fixed for those versions.
[Bug tree-optimization/58280] New: Missed Opportunity for Aligned Vectorized Load
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58280
Bug ID: 58280
Summary: Missed Opportunity for Aligned Vectorized Load
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: freddie at witherden dot org
Consider
void foo(int nr, int nc, int ldim,
double *__restrict a, double *__restrict b)
{
a = __builtin_assume_aligned(a, 32);
b = __builtin_assume_aligned(b, 32);
ldim = (ldim 5) 5;
for (int i = 0; i nr; i++)
for (int j = 0; j nc; j++)
a[i*ldim + j] += b[i*ldim + j];
}
Both GCC 4.7 and 4.8 on an AVX capable system with -march=native and -O3
vectorize the inner loop but utilise unaligned loads and stores. It should be
possible to reason that as a and b are aligned and ldim is a multiple of 32
bytes that a + i*ldim and b + i*ldim are also 32-byte aligned. This would
permit the inner loop to be vectorized with aligned loads.
[Bug tree-optimization/58280] Missed Opportunity for Aligned Vectorized Load
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58280 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 --- We still don't preserve VRP info (patches exist) and furthermore, don't record non-zero bits bitmask there either. Only after we do that we could perhaps handle it IMHO.
[Bug tree-optimization/58280] Missed Opportunity for Aligned Vectorized Load
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58280 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #1) We still don't preserve VRP info (patches exist) and furthermore, don't record non-zero bits bitmask there either. Only after we do that we could perhaps handle it IMHO. CCP computes bitmasks but remembers them only for pointers in the form of alignment/misalignment info.
[Bug tree-optimization/58277] [4.7/4.8/4.9 Regression] wrong code at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58277 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Fri Aug 30 12:41:17 2013 New Revision: 202104 URL: http://gcc.gnu.org/viewcvs?rev=202104root=gccview=rev Log: PR tree-optimization/58277 * tree-ssa-strlen.c (strlen_enter_block): If do_invalidate gave up after seeing too many stmts with vdef in between dombb and current bb, invalidate everything. * gcc.c-torture/execute/pr58277-1.c: New test. * gcc.c-torture/execute/pr58277-2.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr58277-1.c trunk/gcc/testsuite/gcc.c-torture/execute/pr58277-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-strlen.c
[Bug tree-optimization/58280] Missed Opportunity for Aligned Vectorized Load
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58280 --- Comment #3 from Freddie Witherden freddie at witherden dot org --- Would it be any easier --- from an implementation standpoint --- to adopt something similar to the __assume(predicate) directive in ICC? This would allow one to state explicitly: __assume(ldim % 32 == 0); (Although in the case of 256-bit AVX ldim % 4 == 0 would sufficient at double precision.) It is also worth noting that the current version of ICC doesn't spot the alignment either with the bit-shifting trick or an explicit assumption.
[Bug tree-optimization/58280] Missed Opportunity for Aligned Vectorized Load
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58280 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- We have a way to say assume something, if (ldim % 32 != 0) __builtin_unreachable (), and you can define a __assume macro using it. But, as we don't record the non-zero bitmasks from it anywhere, it can't be used by later optimization passes yet.
[Bug tree-optimization/58277] [4.7/4.8/4.9 Regression] wrong code at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58277 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Fri Aug 30 12:53:47 2013 New Revision: 202105 URL: http://gcc.gnu.org/viewcvs?rev=202105root=gccview=rev Log: PR tree-optimization/58277 * tree-ssa-strlen.c (strlen_enter_block): If do_invalidate gave up after seeing too many stmts with vdef in between dombb and current bb, invalidate everything. * gcc.c-torture/execute/pr58277-1.c: New test. * gcc.c-torture/execute/pr58277-2.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/execute/pr58277-1.c branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/execute/pr58277-2.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/tree-ssa-strlen.c
[Bug tree-optimization/58277] [4.7 Regression] wrong code at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58277 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Summary|[4.7/4.8/4.9 Regression]|[4.7 Regression] wrong code |wrong code at -O3 |at -O3 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed for 4.8+ so far, thanks for reporting it.
[Bug tree-optimization/47679] [4.7/4.8/4.9 Regression] Strange uninitialized warning after SRA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47679 --- Comment #12 from André Wöbbeking Woebbeking at web dot de --- Does anyone look into this? The warnings are really annoying. FYI, Clang 3.3 doesn't warn about this.
[Bug c++/58281] New: Problem with explicit constexpr template functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58281
Bug ID: 58281
Summary: Problem with explicit constexpr template functions
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bmerry at gmail dot com
Created attachment 30730
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30730action=edit
Minimal broken test case
It seems that in some cases explicit instantiation of a function template fails
to actually instantiate anything. A minimal example (also attached) is
templatetypename T constexpr bool f(T a)
{
return a == 3;
}
extern template bool fint(int);
bool g(int x) { return f(x); }
template bool fint(int);
int main() { return g(4); }
for which compilation gives
$ g++-4.8 -std=c++11 -o instantiate instantiate.cpp
/tmp/ccPWHA9d.o: In function `g(int)':
instantiate.cpp:(.text+0x11): undefined reference to `bool fint(int)'
collect2: error: ld returned 1 exit status
Obviously in real usage the explicit instantiation declaration would be in a
header and the explicit instantiation definition would be in a .cpp file, but
it's all one translation unit either way.
Some experimentation shows that any of following will compile:
- moving function g to after the explicit instantiation definition
- removing the constexpr qualifier from f
- removing g and main entirely (nm shows the symbol for fint in the resulting
.o file)
The only relevant constraints I found in a quick search of the C++11 [draft]
spec were in 14.7.2.11:
If an entity is the subject of both an explicit instantiation declaration and
an explicit instantiation definition in the same translation unit, the
definition shall follow the declaration. An entity that is the subject of an
explicit instantiation declaration and that is also used in a way that would
otherwise cause an implicit instantiation (14.7.1) in the translation unit
shall be the subject of an explicit instantiation definition somewhere in the
program; otherwise the program is ill-formed, no diagnostic required.
which all seem to be satisfied by the example.
System information: Ubuntu 12.04 on x86_64, running with GCC 4.8.1:
Using built-in specs.
COLLECT_GCC=g++-4.8
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.8.1-2ubuntu1~12.04' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.1 (Ubuntu 4.8.1-2ubuntu1~12.04)
[Bug tree-optimization/58280] Missed Opportunity for Aligned Vectorized Load
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58280 --- Comment #5 from Freddie Witherden freddie at witherden dot org --- Thank you for this information. As an alternative would it be worth considering a pragma along the lines of: #pragma gcc aligned(32) which would confer that in the first iteration of the loop which follows all relevant variables can be taken as having 32-byte alignment. This would provide quite a nice way of allowing loops like the above to be fully vectorized and further avoid the need for explicit calls to __builtin_assume_aligned. ICC has a similar directive but it only applies to the base pointers. So it would assume that a is aligned but not a + i*ldim.
[Bug ada/58239] [4.9 regression] pretty-print.c:789: undefined reference to `operator delete(void*)'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58239
--- Comment #9 from Gabriel Dos Reis gdr at gcc dot gnu.org ---
(In reply to Iain Sandoe from comment #8)
note that the patch at:
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01460.html
is not quite enough to fix this on Darwin - since we use :
%{static|static-libgcc|static-libstdc++:%:replace-outfile(-lstdc++
libstdc++.a%s)}
to implement -static-libstadc++.
The relevant dir needs to be added as -B for this to work - unfortunately,
I'm not able to look at this right now..
-static-libstdc++ was already being used before this patch. So, the -B
directories where already there.
[Bug ada/58264] Incorrect 'First when assigning function-call.all (of access String;) to an indefinite String object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58264 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-08-30 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Thanks for reporting the problem.
[Bug ada/58239] [4.9 regression] pretty-print.c:789: undefined reference to `operator delete(void*)'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58239 --- Comment #12 from Gabriel Dos Reis gdr at gcc dot gnu.org --- (In reply to Iain Sandoe from comment #10) also the gcc driver silently ignores -static-libstdc++. Isn't this the problem? certainly, the -B options are passed when other gcc components are built (or it would fail to bootstrap on Darwin). The Makefiles in gcc/ pass down those options in variables.
[Bug c/58283] New: Incorrect debug info when precompilation is on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58283
Bug ID: 58283
Summary: Incorrect debug info when precompilation is on
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jengelh at inai dot de
Created attachment 30731
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30731action=edit
testcase
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.7/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.7
--enable-ssp --disable-libssp --disable-libitm --disable-plugin
--with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib
--enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --enable-linker-build-id
--program-suffix=-4.7 --enable-linux-futex --without-system-libunwind
--with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux
Thread model: posix
gcc version 4.7.2 20130108 [gcc-4_7-branch revision 195012] (SUSE Linux)
GNU ld (GNU Binutils; openSUSE 12.3) 2.23.1
Testcase is appended. What I observe with it:
$ make
gcc-4.8 -gdwarf-2 -g3 -O0 -DPRECOMP -o pc1.h.gch -c pc1.h
gcc-4.8 -gdwarf-2 -g3 -O0 -DPRECOMP -o x m.c
nm -C x | grep main
U __libc_start_main
00400560 T main
addr2line -e x $(nm -C x | grep ' main$' | awk '{print $1}')
/usr/include/stdio.h:947
What I would have expected:
Have addr2line return m.c:3.
Additional information:
I do get addr2line to output m.c:3 if I include pc1.h instead of pc.h
from m.c. So this problem seems to be related with headers including
(precompiled) headers. In fact, gcc-4.7.2 even ignored pc1.h.gch (itself a bug,
or a non-implemented feature) if m.c includes pc.h, which means I don't get
wrong line numbers on gcc-4.7.
The outputting of wrong line numbers also occurs if compiled as C++ code.
[Bug tree-optimization/58282] g++.dg/tm/noexcept-1.C -fno-exceptions SIGSEGV in gimple_build_eh_must_not_throw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58282 --- Comment #2 from vries at gcc dot gnu.org --- It seems terminate_node is NULL ... Program received signal SIGSEGV, Segmentation fault. 0x08707b50 in gimple_build_eh_must_not_throw (decl=0x0) at /home/vries/local/fsf_gcc_mainline_arm_none_linux_gnueabi/src/gcc-mainline/gcc/gimple.c:730 730 gcc_assert (TREE_CODE (decl) == FUNCTION_DECL); (gdb) up #1 0x08448b8b in gimplify_must_not_throw_expr (expr_p=0xf7dd8030, pre_p=0xc73c) at /home/vries/local/fsf_gcc_mainline_arm_none_linux_gnueabi/src/gcc-mainline/gcc/cp/cp-gimplify.c:503 503 mnt = gimple_build_eh_must_not_throw (terminate_node); ...
[Bug java/58284] New: Compiling jvgenmain failes with lots of undefined reference errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58284 Bug ID: 58284 Summary: Compiling jvgenmain failes with lots of undefined reference errors Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java Assignee: unassigned at gcc dot gnu.org Reporter: smith_winston_6079 at hotmail dot com I am compiling gcc-4.7.2 with the following configuration: $ /root/tmp/gcc-4.7.2/configure --prefix=/usr/ --with-local-prefix=/usr/local/ --with-native-system-header-dir=/usr/include/ --enable-libada --enable-libssp --enable-libquadmath --enable-libgcj --enable-nls --with-included-gettext --enable-fixed-point --enable-shared --enable-threads --enable-bootstrap --enable-languages=all,ada,go,obj-c++ --enable-stage1-languages=all --enable-werror --enable-checking=all --enable-stage1-checking=all --enable-gather-detailed-mem-stats --enable-libgcj-debug I am getting the following error when compiling jvgenmain: make[3]: Entering directory `/home/_/gcc-4.7.2-build/gcc' rm -f jvgenmain gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -o jvgenmain java/jvgenmain.o java/mangle_name.o \ libcommon.a ../libcpp/libcpp.a ./../intl/libintl.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a java/jvgenmain.o: In function `VEC_tree_base_last': /root/tmp/gcc-4.7.2/gcc/vecir.h:28: undefined reference to `vec_assert_fail' java/jvgenmain.o: In function `VEC_tree_base_index': /root/tmp/gcc-4.7.2/gcc/vecir.h:28: undefined reference to `vec_assert_fail' java/jvgenmain.o: In function `VEC_tree_base_space': /root/tmp/gcc-4.7.2/gcc/vecir.h:28: undefined reference to `vec_assert_fail' java/jvgenmain.o: In function `VEC_tree_base_splice': /root/tmp/gcc-4.7.2/gcc/vecir.h:28: undefined reference to `vec_assert_fail' java/jvgenmain.o: In function `VEC_tree_base_quick_push': /root/tmp/gcc-4.7.2/gcc/vecir.h:28: undefined reference to `vec_assert_fail' java/jvgenmain.o:/root/tmp/gcc-4.7.2/gcc/vecir.h:28: more undefined references to `vec_assert_fail' follow java/jvgenmain.o: In function `VEC_tree_gc_alloc': /root/tmp/gcc-4.7.2/gcc/vecir.h:29: undefined reference to `vec_gc_p_reserve_exact' ... lots of such errors, omitted for brevity java/mangle_name.o: In function `VEC_method_entry_gc_safe_grow': /root/tmp/gcc-4.7.2/gcc/java/java-tree.h:873: undefined reference to `vec_assert_fail' collect2: ld returned 1 exit status make[3]: *** [jvgenmain] Error 1 make[3]: Leaving directory `/home/_/gcc-4.7.2-build/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/home/_/gcc-4.7.2-build' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/_/gcc-4.7.2-build' make: *** [all] Error 2 Is there anything wrong with the configure arguments that could cause this (I have scanned through the INSTALL directory html pages and could not find anything)? Googling does not seem to help either. One thing to mention: I am building in a directory in /root/tmp/gcc-4.7.2-build which lives on /, but there wasn't enough free space in that partition, so I symlinked it to /home/_/gcc-4.7.2-build/ (which lives on a different partition). Could this cause the issue? Thanks.
[Bug tree-optimization/58282] g++.dg/tm/noexcept-1.C -fno-exceptions SIGSEGV in gimple_build_eh_must_not_throw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58282 --- Comment #3 from vries at gcc dot gnu.org --- also reproduces with x86_64
[Bug middle-end/57748] [4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748 --- Comment #22 from Martin Jambor jamborm at gcc dot gnu.org --- Created attachment 30732 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30732action=edit Another attempt at a fix I simply moved the decision whether to go the misalignp path or not a bit down in the function, below the address adjustments done for non-NULL offset, strict volatile bit fields etc. and ran the testsuite, expecting some fallout. But there was none the patch even survives a bootstrap on x86_64-linux. I'm hesitant to call it the fix, I'd like to have a second look at it after the weekend but if someone wants to test meanwhile, such input would be highly welcome.
[Bug tree-optimization/58277] [4.7 Regression] wrong code at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58277 --- Comment #11 from Zhendong Su su at cs dot ucdavis.edu --- (In reply to Jakub Jelinek from comment #10) Fixed for 4.8+ so far, thanks for reporting it. Thanks Jakub. Wow, that's quick! You folks are wonderful.
[Bug c++/51424] [C++11] G++ should diagnose self-delegating constructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51424 --- Comment #3 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Fri Aug 30 15:39:01 2013 New Revision: 202110 URL: http://gcc.gnu.org/viewcvs?rev=202110root=gccview=rev Log: /cp 2013-08-30 Paolo Carlini paolo.carl...@oracle.com PR c++/51424 * cp-tree.h (LOOKUP_DELEGATING_CONS): Add. * init.c (perform_target_ctor): Use it. * call.c (build_special_member_call): Diagnose self-delegating constructors. /testsuite 2013-08-30 Paolo Carlini paolo.carl...@oracle.com PR c++/51424 * g++.dg/cpp0x/dc8.C: New. * g++.dg/template/meminit1.C: Adjust. Added: trunk/gcc/testsuite/g++.dg/cpp0x/dc8.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/init.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/template/meminit1.C
[Bug c++/58178] variant function name was used for user defined constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58178 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #10 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Confirmed, maybe related to the missing COMDAT support.
[Bug tree-optimization/58282] New: g++.dg/tm/noexcept-1.C -fno-exceptions SIGSEGV in gimple_build_eh_must_not_throw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58282 Bug ID: 58282 Summary: g++.dg/tm/noexcept-1.C -fno-exceptions SIGSEGV in gimple_build_eh_must_not_throw Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org $ arm-none-linux-gnueabi-g++ gcc/testsuite/g++.dg/tm/noexcept-1.C -fno-diagnostics-show-caret -fdiagnostics-color=never -fno-exceptions -fmessage-length=0 -fgnu-tm -O -std=c++0x -fdump-tree-tmmark -fdump-tree-tmlower -S -o noexcept-1.s gcc/testsuite/g++.dg/tm/noexcept-1.C: In function 'int foo() [with T = TrueFalse]':^M gcc/testsuite/g++.dg/tm/noexcept-1.C:13:43: internal compiler error: Segmentation fault^M 0x8951d05 crash_signal^M gcc/toplev.c:335^M 0x8707b50 gimple_build_eh_must_not_throw(tree_node*)^M gcc/gimple.c:730^M 0x8448b8a gimplify_must_not_throw_expr^M gcc/cp/cp-gimplify.c:503^M 0x844917a cp_gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**)^M gcc/cp/cp-gimplify.c:571^M 0x874de93 gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**, bool (*)(tree_node*), int)^M gcc/gimplify.c:7241^M 0x87470ba gimplify_stmt(tree_node**, gimple_statement_d**)^M gcc/gimplify.c:5699^M 0x87351b9 gimplify_bind_expr^M gcc/gimplify.c:1213^M 0x874eb0e gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**, bool (*)(tree_node*), int)^M gcc/gimplify.c:7493^M 0x87470ba gimplify_stmt(tree_node**, gimple_statement_d**)^M gcc/gimplify.c:5699^M 0x8732bfe gimplify_and_add(tree_node*, gimple_statement_d**)^M gcc/gimplify.c:329^M 0x8732c2d gimplify_and_return_first^M gcc/gimplify.c:341^M 0x874d8cf gimplify_transaction^M gcc/gimplify.c:7042^M 0x874fcb6 gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**, bool (*)(tree_node*), int)^M gcc/gimplify.c:7803^M 0x87470ba gimplify_stmt(tree_node**, gimple_statement_d**)^M gcc/gimplify.c:5699^M 0x87363fe gimplify_statement_list^M gcc/gimplify.c:1525^M 0x874f95d gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**, bool (*)(tree_node*), int)^M gcc/gimplify.c:7711^M 0x87470ba gimplify_stmt(tree_node**, gimple_statement_d**)^M gcc/gimplify.c:5699^M 0x8751d46 gimplify_body(tree_node*, bool)^M gcc/gimplify.c:8356^M 0x87524b2 gimplify_function_tree(tree_node*)^M gcc/gimplify.c:8488^M 0x8572c9a analyze_function^M gcc/cgraphunit.c:630^M Please submit a full bug report,^M with preprocessed source if appropriate.^M Please include the complete backtrace with any bug report.^M See http://gcc.gnu.org/bugs.html for instructions.^M compiler exited with status 1
[Bug ada/58239] [4.9 regression] pretty-print.c:789: undefined reference to `operator delete(void*)'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58239 --- Comment #11 from Eric Botcazou ebotcazou at gcc dot gnu.org --- grep -R -static-libstdc++ gcc/ada suggests that -static-libstdc++ only appears in a Changelog entry. also the gcc driver silently ignores -static-libstdc++. certainly, the -B options are passed when other gcc components are built (or it would fail to bootstrap on Darwin). -static-libstdc++ comes from the compiler via a Makefile variable, not from the gnattools. We probably miss another variable to get the -B options.
[Bug tree-optimization/58282] g++.dg/tm/noexcept-1.C -fno-exceptions SIGSEGV in gimple_build_eh_must_not_throw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58282 --- Comment #1 from vries at gcc dot gnu.org --- svn revision 202105 Configured with: src/gcc-mainline/configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-none-linux-gnueabi --enable-threads --disable-libmudflap --disable-libssp --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --enable-languages=c,c++,fortran --enable-shared --enable-lto --enable-symvers=gnu --enable-__cxa_atexit --disable-nls --prefix=install --with-sysroot=install/arm-none-linux-gnueabi/libc --with-gmp=obj/pkg-mainline-0-arm-none-linux-gnueabi/fsf-mainline-0-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr --with-mpfr=obj/pkg-mainline-0-arm-none-linux-gnueabi/fsf-mainline-0-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr --with-mpc=obj/pkg-mainline-0-arm-none-linux-gnueabi/fsf-mainline-0-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-isl=obj/pkg-mainline-0-arm-none-linux-gnueabi/fsf-mainline-0-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr --with-cloog=obj/pkg-mainline-0-arm-none-linux-gnueabi/fsf-mainline-0-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr --with-libelf=obj/pkg-mainline-0-arm-none-linux-gnueabi/fsf-mainline-0-arm-none-linux-gnueabi.extras/host-libs-i686-pc-linux-gnu/usr --disable-libgomp --disable-libitm --enable-poison-system-directories --with-build-time-tools=install/arm-none-linux-gnueabi/bin --with-build-time-tools=install/arm-none-linux-gnueabi/bin SED=sed
[Bug target/58278] visibility bug from #26905 still happens with the sparc64 backend
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58278 --- Comment #2 from Martin Husemann martin at netbsd dot org --- Compare with this on amd64: c++ -o plain.s -S conftest.cc c++ -o shared.s -fPIC -shared -S conftest.cc diff -u plain.s shared.s --- plain.s 2013-08-30 21:46:18.0 +0200 +++ shared.s2013-08-30 21:46:25.0 +0200 @@ -10,7 +10,7 @@ movq%rsp, %rbp .cfi_offset 6, -16 .cfi_def_cfa_register 6 - call_ZN10TestStruct4InitEv + call_ZN10TestStruct4InitEv@PLT popq%rbp .cfi_def_cfa 7, 8 ret while on sparc (and sparc64) there is no difference. See bug 26905 for details.
[Bug libstdc++/58191] Can't use boost transform_iterator with _GLIBCXX_DEBUG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58191 --- Comment #9 from François Dumont fdumont at gcc dot gnu.org --- Author: fdumont Date: Fri Aug 30 20:16:03 2013 New Revision: 202119 URL: http://gcc.gnu.org/viewcvs?rev=202119root=gccview=rev Log: 2013-08-30 François Dumont fdum...@gcc.gnu.org PR libstdc++/58191 * include/debug/macros.h (__glibcxx_check_partitioned_lower): Add __gnu_debug::__base calls on iterators passed to internal debug check. (__glibcxx_check_partitioned_lower_pred): Likewise. (__glibcxx_check_partitioned_upper): Likewise. (__glibcxx_check_partitioned_upper_pred): Likewise. (__glibcxx_check_sorted): Likewise. (__glibcxx_check_sorted_pred): Likewise. (__glibcxx_check_sorted_set): Likewise. (__glibcxx_check_sorted_set_pred): Likewise. * include/debug/functions.h (__check_partitioned_lower): Remove code to detect safe iterators. (__check_partitioned_upper): Likewise. (__check_sorted): Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/debug/functions.h trunk/libstdc++-v3/include/debug/macros.h
[Bug c++/58091] Non-ambiguous member lookup rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58091
Thomas Braun thomas.br...@virtuell-zuhause.de changed:
What|Removed |Added
CC||thomas.braun@virtuell-zuhau
||se.de
--- Comment #4 from Thomas Braun thomas.br...@virtuell-zuhause.de ---
The example can be even more simplified:
namespace NS
{
template typename T
struct NS {};
}
int main()
{
using namespace NS;
NSint a;
}
And the same error message:
test.cpp: In function ‘int main()’:
test.cpp:11:3: error: reference to ‘NS’ is ambiguous
test.cpp:3:1: error: candidates are: namespace NS { }
test.cpp:5:10: error: templateclass T struct NS::NS
test.cpp:11:6: error: expected primary-expression before ‘int’
test.cpp:11:6: error: expected ‘;’ before ‘int’
I tried g++ 4.4, 4.6 and 4.7.
[Bug target/58278] visibility bug from #26905 still happens with the sparc64 backend
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58278 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-08-30 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org --- What do you mean exactly? What's the difference with the default visibility?
[Bug libstdc++/58148] [4.9 Regression] Fails to insert iterator range into sequence container with -D_GLIBCXX_DEBUG when conversion is needed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58148 --- Comment #3 from François Dumont fdumont at gcc dot gnu.org --- Author: fdumont Date: Fri Aug 30 20:55:37 2013 New Revision: 202121 URL: http://gcc.gnu.org/viewcvs?rev=202121root=gccview=rev Log: 2013-08-30 François Dumont fdum...@gcc.gnu.org PR libstdc++/58148 * include/debug/functions.h (__foreign_iterator_aux4): Use sequence const_pointer as common type to compare pointers. Add a fallback overload in case pointers cannot be cast to sequence const_pointer. * testsuite/23_containers/vector/modifiers/insert/58148.cc: New. Added: trunk/libstdc++-v3/testsuite/23_containers/vector/modifiers/insert/58148.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/debug/functions.h
[Bug target/58278] visibility bug from #26905 still happens with the sparc64 backend
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58278 --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Compare with this on amd64: c++ -o plain.s -S conftest.cc c++ -o shared.s -fPIC -shared -S conftest.cc diff -u plain.s shared.s --- plain.s 2013-08-30 21:46:18.0 +0200 +++ shared.s2013-08-30 21:46:25.0 +0200 @@ -10,7 +10,7 @@ movq%rsp, %rbp .cfi_offset 6, -16 .cfi_def_cfa_register 6 - call_ZN10TestStruct4InitEv + call_ZN10TestStruct4InitEv@PLT popq%rbp .cfi_def_cfa 7, 8 ret while on sparc (and sparc64) there is no difference. So what? What happens if conftest.cc doesn't fiddle with visibility at all?
[Bug libstdc++/58191] Can't use boost transform_iterator with _GLIBCXX_DEBUG
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58191 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2013-08-30 Resolution|INVALID |--- Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com --- Let's have this open as enhancement, already implemented for 4.9.0.
[Bug libstdc++/58148] [4.9 Regression] Fails to insert iterator range into sequence container with -D_GLIBCXX_DEBUG when conversion is needed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58148 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed.
[Bug lto/58285] ICE in lto_output_tree, at lto-streamer-out.c:1318
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58285
Jan Hubicka hubicka at gcc dot gnu.org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #1 from Jan Hubicka hubicka at gcc dot gnu.org ---
It is because following condition:
if (CODE_CONTAINS_STRUCT (code, TS_DECL_MINIMAL))
{
/* Drop names that were created for anonymous entities. */
if (DECL_NAME (expr)
TREE_CODE (DECL_NAME (expr)) == IDENTIFIER_NODE
ANON_AGGRNAME_P (DECL_NAME (expr)))
;
else
DFS_follow_tree_edge (DECL_NAME (expr));
DFS_follow_tree_edge (DECL_CONTEXT (expr));
}
disaggree with:
static void
write_ts_decl_minimal_tree_pointers (struct output_block *ob, tree expr,
bool ref_p)
{
/* Drop names that were created for anonymous entities. */
if (DECL_NAME (expr)
TREE_CODE (DECL_NAME (expr)) == IDENTIFIER_NODE
ANON_AGGRNAME_P (DECL_NAME (expr)))
stream_write_tree (ob, NULL_TREE, ref_p);
else
stream_write_tree (ob, DECL_NAME (expr), ref_p);
stream_write_tree (ob, DECL_CONTEXT (expr), ref_p);
}
the name is $_1 that is anon, but once we miss the fact. I ust be blind, but
do not see how.
[Bug debug/58286] New: Need option to make incompatible pointer types into compiler errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58286 Bug ID: 58286 Summary: Need option to make incompatible pointer types into compiler errors Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: ryao at gentoo dot org Created attachment 30733 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30733action=edit Sample program that illustrates warning that cannot be selectively converted into an error Commandline options to change certain warnings into error messages are useful when designing autotools checks. -Werror can be used for this, but warnings like warning: SSE instruction set disabled, using 387 arithmetics [enabled by default] will cause -Werror to make autotools checks that should succeed fail. That broke an autotools check against the Linux kernel API in the ZFSOnLinux SPL. I have attached a sample program that demonstrates the warning that needs to be made into an error for the autotools check to succeed. Clang supports -Werror=incompatible-pointer-types, which selectively converts the warning into an error. GCC does not appear to support that option under that name or any other.
[Bug lto/58285] New: ICE in lto_output_tree, at lto-streamer-out.c:1318
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58285
Bug ID: 58285
Summary: ICE in lto_output_tree, at lto-streamer-out.c:1318
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.sm...@alcatel-lucent.com
Compile with -flto , must use mips triplet.
extern C {
extern C {
typedef int BOOL;
typedef int STATUS;
typedef struct slnode
{
} SL_LIST;
extern C {
typedef struct
{
} MEM_HANDLE;
}
}
typedef struct hashtbl
{
} H_NODE_INT;
typedef struct
{
} MODULE;
typedef MODULE *MODULE_ID;
extern C {
}
typedef struct symtab
{
} SYMTAB;
typedef SYMTAB *SYMTAB_ID;
extern C {
extern C {
extern C {
extern C {
typedef struct BOOT_PARAMS
{
int (*ioctl)
(
);
};
}
}
}
}
typedef struct wdb_info
{
} SPL;
}
BOOL findXtors
(
)
{
}
extern C STATUS cplusLoadFixup
(
MODULE_ID module,
SYMTAB_ID symTab
)
{
{
}
}
[Bug ada/58239] [4.9 regression] pretty-print.c:789: undefined reference to `operator delete(void*)'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58239
--- Comment #10 from Iain Sandoe iains at gcc dot gnu.org ---
(In reply to Gabriel Dos Reis from comment #9)
(In reply to Iain Sandoe from comment #8)
note that the patch at:
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01460.html
is not quite enough to fix this on Darwin - since we use :
%{static|static-libgcc|static-libstdc++:%:replace-outfile(-lstdc++
libstdc++.a%s)}
to implement -static-libstadc++.
The relevant dir needs to be added as -B for this to work - unfortunately,
I'm not able to look at this right now..
-static-libstdc++ was already being used before this patch. So, the -B
directories where already there.
grep -R -static-libstdc++ gcc/ada suggests that -static-libstdc++ only
appears in a Changelog entry.
also the gcc driver silently ignores -static-libstdc++.
certainly, the -B options are passed when other gcc components are built (or it
would fail to bootstrap on Darwin).
However, your current patch fails with:
ld: file not found: libstdc++.a
[Bug c++/54080] [C++11] g++ crashes when compiling the following file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54080 nightstrike nightstrike at gmail dot com changed: What|Removed |Added CC||nightstrike at gmail dot com --- Comment #3 from nightstrike nightstrike at gmail dot com --- I found this thread: http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00564.html But it seems to have died. Any way to get the fix in? Seems like it fixes a few bugs.
