[Bug debug/44694] [4.5/4.6 Regression] Long var tracking compile time of GiNaC tests
--- Comment #5 from jakub at gcc dot gnu dot org 2010-06-29 06:28 --- The extremely long location lists are caused mainly by reverse_op created equivalences. Wonder whether we shouldn't on RHS replace sp and sp + const_int with framep and framep + const_int even outside of memory addresses and of course not do reverse_op if the register is framep - the framep is always computable, so it isn't useful to reverse it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44694
[Bug target/44707] New: operand requires impossible reload
extern struct { int a, b, c, d; } v;
extern int w;
void
foo (void)
{
int e1 = v.a;
int e2 = w;
int e3 = v.b;
int e4 = v.c;
int e5 = v.d;
__asm__ volatile (/* %0 %1 %2 %3 %4 */ : : nro (e1), nro (e2), nro
(e3), nro (e4), nro (e5));
}
with -O2 -m32 gives:
xlog.i: In function 'foo':
xlog.i:12:3: error: 'asm' operand requires impossible reload
xlog.i:12:3: error: 'asm' operand requires impossible reload
With nro is replaced with nrm, it compiles fine (but, GCC except for latest
trunk might put there side-effects into the unused operand). With nrm
(which is wrong in this case, the asm would actually need to do ld%U1 %0,%1 or
something similar, but then would be valid) it dies with similar error.
It seems that before reload only when nrm is used the asm has (mem (lo_sum
(reg) (symbol_ref))) or (mem (plus (reg) (const_int))) but with nro or
nrm it contains bare (mem (symbol_ref)) or (mem (plus (symbol_ref)
(const_int))) and apparently reload isn't able to deal with that. Not sure if
it is a target powerpc bug, or reload bug, or both. In any case, there
shouldn't be anything impossible here to reload.
I see the ICEs with GCC 4.1, 4.4 and 4.6, so perhaps it is not a regression.
--
Summary: operand requires impossible reload
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: powerpc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44707
[Bug libstdc++/44708] New: Enabling -std=c++0x results in ambiguous function overload in ext/algorithm header
The example program below will exhibit the problem when compiled with
-std=c++0x or gnu++0x flag. The fix appears to be trivial, but requires a
change to ext/algorithm header.
Example program:
#include iostream
#include ext/rope
using namespace std;
int main(int argc, char **argv)
{
__gnu_cxx::crope line(test-test-test);
cout line.c_str() endl;
return 0;
}
Compilation error message:
In file included from
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/include/g++-v4/ext/ropeimpl.h:48,
from
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/include/g++-v4/ext/rope:2956,
from testrope.cpp:2:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/include/g++-v4/ext/algorithm: In
function #8216;std::pair_InputIter, _ForwardIter
__gnu_cxx::copy_n(_InputIterator, _Size, _OutputIterator) [with _InputIterator
= char*, _Size = long unsigned int, _OutputIterator = char*]#8217;:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/include/g++-v4/ext/ropeimpl.h:1090:
instantiated from #8216;static _CharT* __gnu_cxx::rope_CharT,
_Alloc::_S_flatten(__gnu_cxx::_Rope_RopeRep_CharT, _Alloc*, _CharT*) [with
_CharT = char, _Alloc = std::allocatorchar]#8217;
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/include/g++-v4/ext/ropeimpl.h:1621:
instantiated from #8216;const _CharT* __gnu_cxx::rope_CharT, _Alloc::c_str()
const [with _CharT = char, _Alloc = std::allocatorchar]#8217;
testrope.cpp:10: instantiated from here
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/include/g++-v4/ext/algorithm:127: error:
call of overloaded #8216;__copy_n(char*, long unsigned int, char*,
std::random_access_iterator_tag)#8217; is ambiguous
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/include/g++-v4/ext/algorithm:78: note:
candidates are: std::pair_InputIter, _ForwardIter
__gnu_cxx::__copy_n(_InputIterator, _Size, _OutputIterator,
std::input_iterator_tag) [with _InputIterator = char*, _Size = long unsigned
int, _OutputIterator = char*]
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/include/g++-v4/ext/algorithm:93: note:
std::pair_InputIter, _ForwardIter
__gnu_cxx::__copy_n(_RAIterator, _Size, _OutputIterator,
std::random_access_iterator_tag) [with _RAIterator = char*, _Size = long
unsigned int, _OutputIterator = char*]
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/include/g++-v4/bits/stl_algo.h:1003:
note: _OutputIterator std::__copy_n(_RandomAccessIterator,
_Size, _OutputIterator, std::random_access_iterator_tag) [with
_RandomAccessIterator = char*, _Size = long unsigned int, _OutputIterator =
char*]
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/include/g++-v4/bits/stl_algo.h:988:
note: _OutputIterator std::__copy_n(_InputIterator, _Size,
_OutputIterator, std::input_iterator_tag) [with _InputIterator = char*, _Size =
long unsigned int, _OutputIterator = char*]
--
Summary: Enabling -std=c++0x results in ambiguous function
overload in ext/algorithm header
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oakad at yahoo dot com
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44708
[Bug c/44519] improve message for missing ; after struct
--- Comment #1 from pzhao at gcc dot gnu dot org 2010-06-29 08:34 --- Confirmed. -- pzhao at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-29 08:34:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44519
[Bug bootstrap/44699] [4.6 Regression] Bootstrap failure for x86_64-apple-darwin10: ICE while compiling genmodes.c
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||44592 nThis|| Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44699
[Bug target/44705] FAIL: gcc.dg/pr44674.c (internal compiler error)
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-29 08:45 --- More like a target issue. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|tree-optimization |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44705
[Bug fortran/44709] New: BLOCK and GOTO/EXIT/CYCLE
I think at least some of the following block-leaving statements are valid, probably all. Besides some issues of the type 'rejects valid' there is a big wrong-code question: The allocatable objects need to be freed and derived types finalized when one leaves the scope of the block. How to handle this? As the example shows, there are many jump targets. Maybe one has to do something like if (cond) savelabel = L.1 goto clean_up_and_jump goto end: clean_up_and_jump: cleanup goto target end: cleanup Or something similar... Example: outer: block doloop: do i = 1, 4 inner: block integer, allocatable :: a allocate(a) a = i if(i == 1) cycle ! (1) - wrong-code: no dealloc if(i == 2) exit! (2a)- wrong-code: no dealloc if(i == 2) exit doloop ! (2b)- rejects-valid: label not found if(i == 3) exit inner ! (3) - PR 44602 if(i == 4) exit outer ! (4) - PR 44602 if(i == 5) goto 111 ! (5) - wrong-code: no dealloc end block inner end do doloop end block outer 111 continue end (1) and (5) is accepted by gfortran, (2) is only accepted without the label (Name 'doloop' in EXIT statement at (1) is not a loop name). (3) and (4) are constructs not yet supported, cf. PR 44602. -- Summary: BLOCK and GOTO/EXIT/CYCLE Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: wrong-code, rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org OtherBugsDependingO 44602 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44709
[Bug debug/44694] [4.5/4.6 Regression] Long var tracking compile time of GiNaC tests
--- Comment #6 from jakub at gcc dot gnu dot org 2010-06-29 08:53 --- Created an attachment (id=21035) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21035action=view) gcc46-pr44694.patch With this patchlet the compile time on ginac.ii went down from more than 3 minutes to 16 seconds. The same number of DIEs as before have DW_AT_location, just .debug_loc got bigger, so need to investigate whether it is because the debug info is more completely, or if it is worse or just less compact. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44694
[Bug debug/44694] [4.5/4.6 Regression] Long var tracking compile time of GiNaC tests
--- Comment #7 from jakub at gcc dot gnu dot org 2010-06-29 09:09 --- readelf -wo ginac.o1 | grep 'End of' | wc -l; readelf -wo ginac.o2 | grep 'End of' | wc -l; readelf -wo ginac.o1 | wc -l; readelf -wo ginac.o2 | wc -l; readelf -wo ginac.o1 | grep fbreg | wc -l; readelf -wo ginac.o2 | grep fbreg | wc -l 11850 11796 351354 462546 8117 341790 As the number of DW_AT_location (and DW_AT_const_value) attributes in .debug_info is identical, the above means that with the patch 54 vars no longer use .debug_loc (which means they cover the whole function while before they didn't). For the tiny bit fewer location lists the patched version has more entries in many of them (which can still mean either that the coverage is better, or worse (there could be more holes)) and that DW_OP_fbreg is now used much more often than before (that is quite expected with this patch). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44694
[Bug tree-optimization/44710] New: If-conversion generates redundant statements
Starting from revision 160625
(http://gcc.gnu.org/ml/gcc-patches/2010-06/msg01155.html) if-conversion
generates redundant statements for
for (i = 0; i N; i++)
if (arr[i] limit)
{
pos = i + 1;
limit = arr[i];
}
# pos_22 = PHI pos_1(4), 1(2)
# i_23 = PHI prephitmp.8_2(4), 0(2)
# limit_24 = PHI limit_4(4), 1.28e+2(2)
# ivtmp.9_18 = PHI ivtmp.9_17(4), 64(2)
limit_9 = arr[i_23];
pos_10 = i_23 + 1;
D.4534_12 = limit_9 limit_24; -
pretmp.7_3 = i_23 + 1;
D.4535_20 = limit_9 = limit_24; -
pos_1 = [cond_expr] limit_9 = limit_24 ? pos_22 : pos_10;
limit_4 = [cond_expr] limit_9 = limit_24 ? limit_24 : limit_9;
prephitmp.8_2 = [cond_expr] limit_9 = limit_24 ? pretmp.7_3 : pos_10;
ivtmp.9_17 = ivtmp.9_18 - 1;
D.4536_19 = D.4534_12 || D.4535_20; -
if (ivtmp.9_17 != 0)
goto bb 4;
else
goto bb 5;
The statements are removed by later dce pass, but they interfere with my
attempts to vectorize this loop.
--
Summary: If-conversion generates redundant statements
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: irar at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44710
[Bug tree-optimization/44710] If-conversion generates redundant statements
--- Comment #1 from irar at il dot ibm dot com 2010-06-29 09:11 --- Created an attachment (id=21036) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21036action=view) Full testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44710
[Bug libstdc++/44708] Enabling -std=c++0x results in ambiguous function overload in ext/algorithm header
--- Comment #1 from paolo dot carlini at oracle dot com 2010-06-29 09:15 --- Fixing momentarily, thanks. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-29 09:15:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44708
[Bug libstdc++/44708] Enabling -std=c++0x results in ambiguous function overload in ext/algorithm header
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44708
[Bug rtl-optimization/44659] Combiner fails to match QI cmp patterns with upper 8bit register
-- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-29 09:24:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44659
[Bug rtl-optimization/44659] Combiner fails to match QI cmp patterns with upper 8bit register
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-06-29 09:24 --- Subject: Bug 44659 Author: ebotcazou Date: Tue Jun 29 09:24:34 2010 New Revision: 161523 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161523 Log: PR rtl-optimization/44659 * combine.c (make_compound_operation) SUBREG: Do not return the result of force_to_mode if it partially re-expanded the compound. Added: trunk/gcc/testsuite/gcc.target/i386/extract-1.c trunk/gcc/testsuite/gcc.target/i386/extract-2.c trunk/gcc/testsuite/gcc.target/i386/extract-3.c trunk/gcc/testsuite/gcc.target/i386/extract-4.c trunk/gcc/testsuite/gcc.target/i386/extract-5.c trunk/gcc/testsuite/gcc.target/i386/extract-6.c Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44659
[Bug middle-end/44706] [4.6 regression] Failed to build 483.xalancbmk in SPEC CPU 2006
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44706
[Bug testsuite/44701] [4.6 regression] PR44492 fix broke gcc.target/powerpc/asm-es-2.c
--- Comment #1 from jakub at gcc dot gnu dot org 2010-06-29 09:49 ---
Guess something like:
--- gcc/testsuite/gcc.target/powerpc/asm-es-2.c 2009-07-20 20:41:46.0
+0200
+++ gcc/testsuite/gcc.target/powerpc/asm-es-2.c 2010-06-29 11:37:05.482959217
+0200
@@ -11,7 +11,7 @@ f2 (int *p)
while (1)
{
p += 4;
- asm (asm2%U0 %0 : =m (*p));
+ asm (asm2%U0 %0 : =m (*p));
}
}
should fix this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44701
[Bug libstdc++/44708] Enabling -std=c++0x results in ambiguous function overload in ext/algorithm header
--- Comment #2 from paolo at gcc dot gnu dot org 2010-06-29 10:04 --- Subject: Bug 44708 Author: paolo Date: Tue Jun 29 10:03:36 2010 New Revision: 161524 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161524 Log: 2010-06-29 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/44708 * include/ext/algorithm (copy_n): Qualify __copy_n call with __gnu_cxx:: * testsuite/ext/rope/44708.cc: New. Added: trunk/libstdc++-v3/testsuite/ext/rope/44708.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/ext/algorithm -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44708
[Bug libstdc++/44708] Enabling -std=c++0x results in ambiguous function overload in ext/algorithm header
--- Comment #3 from paolo at gcc dot gnu dot org 2010-06-29 10:04 --- Subject: Bug 44708 Author: paolo Date: Tue Jun 29 10:04:01 2010 New Revision: 161525 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161525 Log: 2010-06-29 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/44708 * include/ext/algorithm (copy_n): Qualify __copy_n call with __gnu_cxx:: * testsuite/ext/rope/44708.cc: New. Added: branches/gcc-4_5-branch/libstdc++-v3/testsuite/ext/rope/44708.cc Modified: branches/gcc-4_5-branch/libstdc++-v3/ChangeLog branches/gcc-4_5-branch/libstdc++-v3/include/ext/algorithm -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44708
[Bug libstdc++/44708] Enabling -std=c++0x results in ambiguous function overload in ext/algorithm header
--- Comment #4 from paolo dot carlini at oracle dot com 2010-06-29 10:04 --- Fixed. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44708
[Bug tree-optimization/44710] [4.6 Regression] If-conversion generates redundant statements
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||missed-optimization Summary|If-conversion generates |[4.6 Regression] If- |redundant statements|conversion generates ||redundant statements Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44710
[Bug tree-optimization/44711] New: PRE doesn't remove equivalent computations of induction variables
For the following loop
for (i = 0; i N; i++)
if (arr[i] limit)
{
pos = i + 1;
limit = arr[i];
}
PRE fails to eliminate redundant i_24 + 1 computation.
Here is Richard's analysis from
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02982.html:
So the reason is our heuristic in PRE to not introduce new IVs:
Found partial redundancy for expression {plus_expr,i_24,1} (0005)
Skipping insertion of phi for partial redundancy: Looks like an
induction variable
Inserted pretmp.4_2 = i_13 + 1;
in predecessor 8
Found partial redundancy for expression {plus_expr,i_24,1} (0005)
Inserted pretmp.4_22 = i_24 + 1;
in predecessor 7
Created phi prephitmp.5_21 = PHI pretmp.4_22(7), pos_11(4)
in block 5
Found partial redundancy for expression {plus_expr,i_24,1} (0005)
Skipping insertion of phi for partial redundancy: Looks like an
induction variable
Replaced i_24 + 1 with prephitmp.5_21 in i_13 = i_24 + 1;
Removing unnecessary insertion:pretmp.4_2 = i_13 + 1;
we do not want to insert into block 3, so we are left with
bb 3:
# pos_23 = PHI pos_1(8), 1(2)
# i_24 = PHI i_13(8), 0(2)
# limit_25 = PHI limit_4(8), 1.28e+2(2)
limit_9 = arr[i_24];
D.3841_10 = limit_9 limit_25;
if (D.3841_10 != 0)
goto bb 4;
else
goto bb 7;
bb 7:
pretmp.4_22 = i_24 + 1;
goto bb 5;
bb 4:
pos_11 = i_24 + 1;
bb 5:
# pos_1 = PHI pos_23(7), pos_11(4)
# limit_4 = PHI limit_25(7), limit_9(4)
# prephitmp.5_21 = PHI pretmp.4_22(7), pos_11(4)
i_13 = prephitmp.5_21;
where there is no full redundancy for i_24 + 1 now (that is,
we did some useless half-way PRE because of that IV
heuristic ...).
--
Summary: PRE doesn't remove equivalent computations of induction
variables
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: irar at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44711
[Bug tree-optimization/44711] PRE doesn't remove equivalent computations of induction variables
--- Comment #1 from irar at il dot ibm dot com 2010-06-29 11:00 --- Created an attachment (id=21037) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21037action=view) Full testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44711
[Bug testsuite/44701] [4.6 regression] PR44492 fix broke gcc.target/powerpc/asm-es-2.c
--- Comment #2 from mikpe at it dot uu dot se 2010-06-29 11:00 --- (In reply to comment #1) - asm (asm2%U0 %0 : =m (*p)); + asm (asm2%U0 %0 : =m (*p)); That fixed the test case. Thanks. I didn't know about the PowerPC-specific %U thing, but now I see that the compiler did the right thing. Seems like the descriptions of m and es in the PowerPC-specific part of md.texi are now a bit stale: es should be equivalent to m, and m should be safe (free of side-effects) unless accompanied by or . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44701
[Bug bootstrap/44699] [4.6 Regression] Bootstrap failure for x86_64-apple-darwin10: ICE while compiling genmodes.c
--- Comment #3 from matz at gcc dot gnu dot org 2010-06-29 11:31 --- Can you perhaps run the testsuite without bootstrapping (configure --disable-bootstrap; make; make check) to see if there occurs some more obvious bug than a miscompilation of genmodes? Debugging bootstrap miscompilations via bugzilla is difficult. The miscompile might be in bitmap_clear, perhaps there's something obvious, but a breaking testcase is much easier. (I do wonder though why the miscompile happens on darwin but not linux, even though the architecture is the same) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44699
[Bug bootstrap/44699] [4.6 Regression] Bootstrap failure for x86_64-apple-darwin10: ICE while compiling genmodes.c
--- Comment #4 from dominiq at lps dot ens dot fr 2010-06-29 12:06 ---
On revision 161462 with the patch of revision 161496 I have located the problem
in:
static void
create_modes (void)
{
/* make_int_mode (BI, 1, 1, ../../work/gcc/machmode.def, 176); */
make_int_mode (QI, -1U, 1, ../../work/gcc/machmode.def, 181);
make_int_mode (HI, -1U, 2, ../../work/gcc/machmode.def, 182);
}
int
main (int argc, char **argv)
{
create_modes ();
}
with the ICE in
genmodes.c: In function 'new_mode.constprop.0':
genmodes.c:2214:1: internal compiler error: Segmentation fault
I'll continue to reduce the test later today.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44699
[Bug tree-optimization/44711] PRE doesn't remove equivalent computations of induction variables
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-29 12:07 --- Note that the issue is that PRE pessimizes code by transforming if (D.3841_10 != 0) goto bb 4; else goto bb 7; bb 7: goto bb 5; bb 4: pos_11 = i_24 + 1; bb 5: # pos_1 = PHI pos_23(7), pos_11(4) # limit_4 = PHI limit_25(7), limit_9(4) i_13 = i_24 + 1; to if (D.3841_10 != 0) goto bb 4; else goto bb 7; bb 7: pretmp.4_22 = i_24 + 1; goto bb 5; bb 4: pos_11 = i_24 + 1; bb 5: # pos_1 = PHI pos_23(7), pos_11(4) # limit_4 = PHI limit_25(7), limit_9(4) # prephitmp.5_21 = PHI pretmp.4_22(7), pos_11(4) i_13 = prephitmp.5_21; which exposes the fact that we do not do code-hoisting presently. Removing the IV restriction from PRE would create i_24 + 1 as new IV with an increment in the latch block. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-29 12:07:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44711
[Bug tree-optimization/44667] [4.5/4.6 Regression] ICE: verify_stmts failed: non-trivial conversion at assignment with -fprofile-generate
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-29 12:12 --- Subject: Bug 44667 Author: rguenth Date: Tue Jun 29 12:12:10 2010 New Revision: 161527 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161527 Log: 2010-06-29 Richard Guenther rguent...@suse.de PR middle-end/44667 * tree-inline.c (initialize_inlined_parameters): Make sure to remap the inlined parameter variable substitutions types. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-inline.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44667
[Bug tree-optimization/44667] [4.5 Regression] ICE: verify_stmts failed: non-trivial conversion at assignment with -fprofile-generate
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-06-29 12:24 --- Fixed on the trunk. Probably not worth to fix on the branch though as it is a checking-only ICE. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.6.0 Summary|[4.5/4.6 Regression] ICE: |[4.5 Regression] ICE: |verify_stmts failed: non- |verify_stmts failed: non- |trivial conversion at |trivial conversion at |assignment with -fprofile- |assignment with -fprofile- |generate|generate http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44667
[Bug debug/44712] New: Debug info for partially inlined functions
/* { dg-options -g -O2 } */
extern void abort (void);
extern void exit (int);
extern int printf (const char *, ...);
static int
foo (int x)
{
typedef int T;
T z = 2 * x;
if (x = 0)
{
printf (foo\n);
printf (foo\n);
printf (foo\n);
exit (0);
}
return 6;
}
__attribute__((noinline))
int bar (int x)
{
return foo (x) + foo (6) + foo (x);
}
int
main (void)
{
int l;
asm volatile ( : =r (l) : 0 (5));
if (bar (l) != 18)
abort ();
bar (l - 10);
abort ();
}
Debugging experience on this testcase isn't ideal, work will be needed both on
the gcc side and gdb side. Roland has some ideas what should be done,
certainly DW_AT_artificial should be set on the foo.part* function, and perhaps
it should have some DW_TAG_lexical_block from the abstract DW_TAG_subprogram as
DW_AT_abstract_origin instead of the whole DW_TAG_subroutine (or perhaps some
artificial DW_TAG_lexical_block created just for that purpose?).
I'll let Roland write the details here himself.
--
Summary: Debug info for partially inlined functions
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: wrong-debug
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44712
[Bug middle-end/44133] [4.5 Regression] Uninit warning regression with new SRA
--- Comment #6 from jamborm at gcc dot gnu dot org 2010-06-29 13:09 --- Subject: Bug 44133 Author: jamborm Date: Tue Jun 29 13:08:46 2010 New Revision: 161532 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161532 Log: 2010-06-29 Martin Jambor mjam...@suse.cz Backport from mainline 2010-05-17 Martin Jambor mjam...@suse.cz PR middle-end/44133 * tree-sra.c (create_access_replacement): New parameter rename, mark the replaement for renaming only when it is true. (get_access_replacement): Pass true in the rename parameter of create_access_replacement. (get_unrenamed_access_replacement): New function. (replace_uses_with_default_def_ssa_name): New parameter racc, get the replacement declaration from it. * testsuite/gcc.dg/tree-ssa/pr44133.c: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/tree-ssa/pr44133.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/tree-sra.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44133
[Bug middle-end/44133] [4.5 Regression] Uninit warning regression with new SRA
--- Comment #7 from jamborm at gcc dot gnu dot org 2010-06-29 13:10 --- This is now fixed on both the trunk and the 4.5 branch. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44133
[Bug tree-optimization/43905] [4.5 Regression] duplicate __PRETTY_FUNCTION__ symbol for functions differing in const-ness
--- Comment #9 from jamborm at gcc dot gnu dot org 2010-06-29 13:16 --- 4.5 patch submitted to the mailing list: http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02896.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43905
[Bug bootstrap/44699] [4.6 Regression] Bootstrap failure for x86_64-apple-darwin10: ICE while compiling genmodes.c
--- Comment #5 from dominiq at lps dot ens dot fr 2010-06-29 13:24 --- Created an attachment (id=21038) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21038action=view) reduced test The reduced test gives an ICE: [macbook] f90/bug% /opt/gcc/gcc4.6bw/bin/gcc -c -O2 genmodes.c genmodes.c: In function 'main': genmodes.c:152:1: internal compiler error: Segmentation fault -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44699
Re: [Bug debug/44712] New: Debug info for partially inlined functions
Thanks for opening PR on this. One thing I was planning to look into soon is to make progress at least reversible - i.e. find way to declare the fact that function is part of another in GCC and make inliner to produce the problem block tree after inlining them back together. I wonder what the representation should be? Honza
[Bug debug/44712] Debug info for partially inlined functions
--- Comment #1 from hubicka at ucw dot cz 2010-06-29 13:25 --- Subject: Re: New: Debug info for partially inlined functions Thanks for opening PR on this. One thing I was planning to look into soon is to make progress at least reversible - i.e. find way to declare the fact that function is part of another in GCC and make inliner to produce the problem block tree after inlining them back together. I wonder what the representation should be? Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44712
[Bug bootstrap/44699] [4.6 Regression] Bootstrap failure for x86_64-apple-darwin10: ICE while compiling genmodes.c
--- Comment #6 from dominiq at lps dot ens dot fr 2010-06-29 13:30 --- The backtrace for the reduced test of comment #5 is Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0022 0x0001007c320a in execute_vrp () (gdb) bt #0 0x0001007c320a in execute_vrp () #1 0x0001005794f4 in execute_one_pass () #2 0x0001005797cd in execute_pass_list () #3 0x0001005797df in execute_pass_list () #4 0x0001006a2e9c in tree_rest_of_compilation () #5 0x00010085e02d in cgraph_expand_function () #6 0x000100860e69 in cgraph_optimize () #7 0x0001008614fa in cgraph_finalize_compilation_unit () #8 0x00010001bc72 in c_write_global_declarations () #9 0x00010063d061 in toplev_main () #10 0x00011194 in start () -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44699
[Bug target/43902] suboptimal MIPS widening multiply accumulate
--- Comment #14 from bernds at gcc dot gnu dot org 2010-06-29 13:44 --- Subject: Bug 43902 Author: bernds Date: Tue Jun 29 13:43:57 2010 New Revision: 161533 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161533 Log: PR target/43902 * config/arm/arm.md (maddsidi4, umaddsidi4): New expanders. (maddhisi4): Renamed from mulhisi3addsi. Operands renumbered. (maddhidi4): Likewise. testsuite/ PR target/43902 * gcc.target/arm/wmul-1.c: Test for smlabb instead of smulbb. * gcc.target/arm/wmul-3.c: New test. * gcc.target/arm/wmul-4.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/wmul-3.c trunk/gcc/testsuite/gcc.target/arm/wmul-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.md trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/arm/wmul-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43902
[Bug bootstrap/44699] [4.6 Regression] Bootstrap failure for x86_64-apple-darwin10: ICE while compiling genmodes.c
--- Comment #7 from matz at gcc dot gnu dot org 2010-06-29 13:47 --- Is /opt/gcc/gcc4.6bw/bin/gcc a bootstrapped compiler or one created without bootstrapping? The initial comment didn't reveal it, so maybe my assumption that it's a miscompiled cc1 is wrong. So, just to be crystal clear in the initial comment, the segfaulting compiler, is that the stage1 or the stage2 compiler? (you can check for the existence of stage1-gcc directory in the build-dir when the segfault happens, if there's such a directory then prev-gcc/xgcc is the stage2 compiler). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44699
[Bug tree-optimization/44710] [4.6 Regression] If-conversion generates redundant statements
--- Comment #2 from spop at gcc dot gnu dot org 2010-06-29 13:56 --- Mine. Patch 0005 of http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02250.html fixes exactly this problem. I have not yet worked on correcting the patch as Richi asked. -- spop at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |spop at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-29 13:56:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44710
[Bug debug/44694] [4.5/4.6 Regression] Long var tracking compile time of GiNaC tests
--- Comment #8 from jakub at gcc dot gnu dot org 2010-06-29 14:11 --- Created an attachment (id=21039) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21039action=view) gcc46-pr44694.patch Updated patch that actually passed bootstrap/regtested on x86_64-linux and i686-linux. When (frame) is present outside of MEM addresses, some tweaks to cselib are needed, otherwise it ICEs quite often. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Attachment #21035|0 |1 is obsolete|| AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44694
[Bug bootstrap/44713] New: [4.6 regression] Revision 161530 failed bootstrap
On Linux/x86, revison 161530: http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg01448.html caused: ../../src-trunk/gcc/config/i386/i386.c: At top level: ../../src-trunk/gcc/config/i386/i386.c:30995:8: error: initialization from incompatible pointer type [-Werror] ../../src-trunk/gcc/config/i386/i386.c:30995:8: error: (near initialization for 'targetm.calls.function_arg_advance') [-Werror] ../../src-trunk/gcc/config/i386/i386.c:30995:8: error: initialization from incompatible pointer type [-Werror] ../../src-trunk/gcc/config/i386/i386.c:30995:8: error: (near initialization for 'targetm.calls.function_arg') [-Werror] ../../src-trunk/gcc/config/i386/i386.c:30995:8: error: initialization from incompatible pointer type [-Werror] -- Summary: [4.6 regression] Revision 161530 failed bootstrap Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44713
[Bug bootstrap/44713] [4.6 regression] Revision 161530 failed bootstrap
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44713
[Bug bootstrap/44713] [4.6 regression] Revision 161530 failed bootstrap
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-29 14:15 --- The patch also misses doc/tm.texi pieces. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-29 14:15:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44713
[Bug bootstrap/44713] [4.6 regression] Revision 161530 failed bootstrap
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-29 14:19 --- My build fails with (x86_64): libbackend.a(i386.o): In function `ix86_setup_incoming_varargs': /space/rguenther/src/svn/trunk/gcc/config/i386/i386.c:7050: undefined reference to `function_arg_advance' collect2: ld returned 1 exit status make: *** [cc1-dummy] Error 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44713
[Bug bootstrap/44714] New: libgcc configure: error: cannot compute suffix of object files
I am trying to install the new version of gcc and am getting an error in the process. Version of gcc: 4.5.0 System type: Ubuntu 10.04 I downloaded the package gcc-4.5.0.tar.gz from ftp://ftp.fu-berlin.de/unix/languages/gcc/releases/gcc-4.5.0/ and extracted the file to my Desktop directory and I tried ./configure sudo make Then I found out I needed GMP, MPFR, and MPC installed. I downloaded the packages to my desktop and built and installed them, several times since some of the latest versions did not seem to be compatible with each other. So after a few tries I found a combination of versions of these that would install correctly and still met the stated requirements for installing gcc 4.5.0 Then, finally I tried building gcc again with ./configure sudo make but then I get the error described in the summary above. Here is the last part of the make process: Checking multilib configuration for libgcc... Configuring stage 1 in i686-pc-linux-gnu/libgcc configure: loading cache ./config.cache checking for --enable-version-specific-runtime-libs... no checking for a BSD-compatible install... /usr/bin/install -c checking for gawk... gawk checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking for i686-pc-linux-gnu-ar... ar checking for i686-pc-linux-gnu-lipo... lipo checking for i686-pc-linux-gnu-nm... /home/justin/Desktop/gcc-4.5.0/host-i686-pc-linux-gnu/gcc/nm checking for i686-pc-linux-gnu-ranlib... ranlib checking for i686-pc-linux-gnu-strip... strip checking whether ln -s works... yes checking for i686-pc-linux-gnu-gcc... /home/justin/Desktop/gcc-4.5.0/host-i686-pc-linux-gnu/gcc/xgcc -B/home/justin/Desktop/gcc-4.5.0/host-i686-pc-linux-gnu/gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-gnu/sys-include checking for suffix of object files... configure: error: in `/home/justin/Desktop/gcc-4.5.0/i686-pc-linux-gnu/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. make[2]: *** [configure-stage1-target-libgcc] Error 1 make[2]: Leaving directory `/home/justin/Desktop/gcc-4.5.0' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/justin/Desktop/gcc-4.5.0' make: *** [all] Error 2 Thanks for the help! -- Summary: libgcc configure: error: cannot compute suffix of object files Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jbare7 at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44714
[Bug bootstrap/44713] [4.6 regression] Revision 161530 failed bootstrap
--- Comment #3 from hjl dot tools at gmail dot com 2010-06-29 14:31 --- More errors/warnings on i386.c: ../../src-trunk/gcc/config/i386/i386.c: In function 'ix86_function_arg_advance': ../../src-trunk/gcc/config/i386/i386.c:6086:5: error: passing argument 3 of 'function_arg_advance_64' discards 'const' qualifier from pointer target type [-Werror] ../../src-trunk/gcc/config/i386/i386.c:6027:1: note: expected 'tree' but argument is of type 'const_tree' ../../src-trunk/gcc/config/i386/i386.c:6088:5: error: passing argument 3 of 'function_arg_advance_32' discards 'const' qualifier from pointer target type [-Werror] ../../src-trunk/gcc/config/i386/i386.c:5939:1: note: expected 'tree' but argument is of type 'const_tree' ../../src-trunk/gcc/config/i386/i386.c: In function 'ix86_function_arg': ../../src-trunk/gcc/config/i386/i386.c:6331:5: error: passing argument 2 of 'type_natural_mode' discards 'const' qualifier from pointer target type [-Werror] ../../src-trunk/gcc/config/i386/i386.c:5183:1: note: expected 'struct CUMULATIVE_ARGS *' but argument is of type 'const struct CUMULATIVE_ARGS *' ../../src-trunk/gcc/config/i386/i386.c:6334:5: error: passing argument 1 of 'function_arg_ms_64' discards 'const' qualifier from pointer target type [-Werror] ../../src-trunk/gcc/config/i386/i386.c:6258:1: note: expected 'struct CUMULATIVE_ARGS *' but argument is of type 'const struct CUMULATIVE_ARGS *' ../../src-trunk/gcc/config/i386/i386.c:6336:5: error: passing argument 1 of 'function_arg_64' discards 'const' qualifier from pointer target type [-Werror] ../../src-trunk/gcc/config/i386/i386.c:6222:1: note: expected 'struct CUMULATIVE_ARGS *' but argument is of type 'const struct CUMULATIVE_ARGS *' ../../src-trunk/gcc/config/i386/i386.c:6336:5: error: passing argument 4 of 'function_arg_64' discards 'const' qualifier from pointer target type [-Werror] ../../src-trunk/gcc/config/i386/i386.c:6222:1: note: expected 'tree' but argument is of type 'const_tree' ../../src-trunk/gcc/config/i386/i386.c:6338:5: error: passing argument 1 of 'function_arg_32' discards 'const' qualifier from pointer target type [-Werror] ../../src-trunk/gcc/config/i386/i386.c:6105:1: note: expected 'struct CUMULATIVE_ARGS *' but argument is of type 'const struct CUMULATIVE_ARGS *' ../../src-trunk/gcc/config/i386/i386.c:6338:5: error: passing argument 4 of 'function_arg_32' discards 'const' qualifier from pointer target type [-Werror] ../../src-trunk/gcc/config/i386/i386.c:6105:1: note: expected 'tree' but argument is of type 'const_tree' ../../src-trunk/gcc/config/i386/i386.c: In function 'ix86_setup_incoming_varargs': ../../src-trunk/gcc/config/i386/i386.c:7050:5: error: implicit declaration of function 'function_arg_advance' [-Werror=implicit-function-declaration] ../../src-trunk/gcc/config/i386/i386.c: At top level: ../../src-trunk/gcc/config/i386/i386.c:30995:8: error: initialization from incompatible pointer type [-Werror] ../../src-trunk/gcc/config/i386/i386.c:30995:8: error: (near initialization for 'targetm.calls.function_arg_advance') [-Werror] ../../src-trunk/gcc/config/i386/i386.c:30995:8: error: initialization from incompatible pointer type [-Werror] ../../src-trunk/gcc/config/i386/i386.c:30995:8: error: (near initialization for 'targetm.calls.function_arg') [-Werror] ../../src-trunk/gcc/config/i386/i386.c:30995:8: error: initialization from incompatible pointer type [-Werror] ../../src-trunk/gcc/config/i386/i386.c:30995:8: error: (near initialization for 'targetm.calls.function_incoming_arg') [-Werror] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44713
[Bug bootstrap/44699] [4.6 Regression] Bootstrap failure for x86_64-apple-darwin10: ICE while compiling genmodes.c
--- Comment #8 from dominiq at lps dot ens dot fr 2010-06-29 14:36 --- Is /opt/gcc/gcc4.6bw/bin/gcc a bootstrapped compiler or one created without bootstrapping? Sorry for the confusion. /opt/gcc/gcc4.6bw/bin/gcc was built with revision 161462 and the patch of revision 161496 (see comment #4). The test case in comment #5 was extracted from the genmodes.i file generated by the prev-gcc/xgcc of the failed bootstrap. Using the corresponding cc1 with the reduced test, I get [macbook] f90/bug% /opt/gcc/mod_build_w_fail/prev-gcc/cc1 -O2 genmodes.c __inline_memcpy_chk find_mode new_mode make_int_mode create_modes main Analyzing compilation unit Performing interprocedural optimizations *free_lang_data visibility early_local_cleanups whole-program ipa-profile cp inline pure-const static-varAssembling functions: main genmodes.c: In function 'main': genmodes.c:152:1: internal compiler error: Segmentation fault -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44699
[Bug bootstrap/44699] [4.6 Regression] Bootstrap failure for x86_64-apple-darwin10: ICE while compiling genmodes.c
--- Comment #9 from matz at gcc dot gnu dot org 2010-06-29 14:48 --- Yes, but I'm asking if it was a bootstrapped compiler (in difference to one built with configuring with --disable-bootstrap) or not. If it was a bootstrapped compiler, are you saying that bootstrap fails with r161501 (initial comment), but works when using r161462 plus patch of 161496? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44699
[Bug bootstrap/44699] [4.6 Regression] Bootstrap failure for x86_64-apple-darwin10: ICE while compiling genmodes.c
--- Comment #10 from dominiq at lps dot ens dot fr 2010-06-29 14:57 --- Yes, but I'm asking if it was a bootstrapped compiler (in difference to one built with configuring with --disable-bootstrap) or not. If it was a bootstrapped compiler, are you saying that bootstrap fails with r161501 (initial comment), but works when using r161462 plus patch of 161496? The compiler was bootstrapped at revision 161436 then updated to 161443, 161455, 161459, and 161462, then updated with the patch leading to revision 161496 applied. What gives the reduced test case on a post r161496 gcc on linux? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44699
[Bug bootstrap/44714] libgcc configure: error: cannot compute suffix of object files
--- Comment #1 from redi at gcc dot gnu dot org 2010-06-29 15:09 --- (In reply to comment #0) sudo make There's no need to build as root. Then I found out I needed GMP, MPFR, and MPC installed. I downloaded the packages to my desktop and built and installed them, several times since some of the latest versions did not seem to be compatible with each other. So after a few tries I found a combination of versions of these that would install correctly and still met the stated requirements for installing gcc 4.5.0 You don't need to install them, you can just put them in the gcc-4.5.0 directory, that's sometimes easier. Or you can probably install them from your distro's package management system. See `config.log' for more details. Like it says, see config.log for more details -- redi at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44714
[Bug bootstrap/44699] [4.6 Regression] Bootstrap failure for x86_64-apple-darwin10: ICE while compiling genmodes.c
--- Comment #11 from matz at gcc dot gnu dot org 2010-06-29 15:15 --- I can reproduce now. It's also the non-bootstrapped compiler failing with the testcase, thanks for that. I'm on it. -- matz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |matz at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-29 15:15:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44699
[Bug bootstrap/44714] libgcc configure: error: cannot compute suffix of object files
--- Comment #2 from redi at gcc dot gnu dot org 2010-06-29 15:20 --- also, please check whether this is the same issue as Bug 43819 (did you search for existing bugs with cannot compute suffix before entering a bug?) It's likely you need to set LD_LIBRARY_PATH so that libgmp etc can be found That wouldn't be necessary if you installed your distro's packages, or if you put the gmp/mpfr/mpc sources in the gcc-4.5.0 directory instead of building and installing them manually -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44714
[Bug c++/44682] [4.6 Regression] warning: variable �x� set but not used
--- Comment #4 from jakub at gcc dot gnu dot org 2010-06-29 15:24 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44682
[Bug middle-end/44203] [4.6 regression] New prefetch test failures
--- Comment #7 from jakub at gcc dot gnu dot org 2010-06-29 15:43 --- Fixed then. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44203
[Bug bootstrap/44713] [4.6 regression] Revision 161530 failed bootstrap
--- Comment #4 from froydnj at gcc dot gnu dot org 2010-06-29 15:57 --- Subject: Bug 44713 Author: froydnj Date: Tue Jun 29 15:57:06 2010 New Revision: 161540 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161540 Log: PR bootstrap/44713 * config/i386/i386.c (type_natural_mode): Const-ify CUM parameter. (function_arg_advance_32): Const-ify TYPE parameter. (function_arg_advance_64): Likewise. Change type of NAMED to bool. (ix86_function_arg_advance): Change type of NAMED to bool. (function_arg_32): Const-ify CUM and TYPE parameters. (function_arg_64): Likewise. Change type of NAMED to bool. (function_arg_ms_64): Const-ify CUM parameter. Change type of NAMED to bool. (ix86_function_arg): Change type of NAMED to bool. (ix86_setup_incoming_varargs): Call ix86_function_arg_advance. Pass last argument as a bool. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44713
[Bug c/44715] New: Break in increment expression of for statement inconsistent with g++
The following program exhibits different behavior with gcc vs. g++:
dgregor$ cat t.c
#include stdio.h
int main()
{
int i;
for( i = 0; i 3; )
for( ; ; ({ i++; break; }) )
printf( %d\n, i );
}
With gcc, the break in the statement expression applies to the outer for
loop, so we get just 0 as output:
dgregor$ gcc t.c ./a.out
0
with g++, the break in the statement expression applies to the inner for
loop, so we get 0 1 and 2 as the output:
dgregor$ g++ t.c ./a.out
0
1
2
g++ seems to have the right behavior here, and in any case g++ can't really be
changed now: Qt's foreach macro depends on having break bind to the inner for
loop.
--
Summary: Break in increment expression of for statement
inconsistent with g++
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: doug dot gregor at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44715
[Bug tree-optimization/43801] [4.5/4.6 Regression] error: function causes a section type conflict with -fipa-cp -fipa-cp-clone
--- Comment #6 from jakub at gcc dot gnu dot org 2010-06-29 16:27 --- Created an attachment (id=21040) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21040action=view) gcc46-pr43801.patch Untested fix. I think for !DECL_ONE_ONLY decls we can put the virtual clone in the same section, but for comdat groups we obviously can't do that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43801
[Bug target/43636] [4.5/4.6 Regression] ICE in extract_insn, at recog.c:2103
--- Comment #8 from jakub at gcc dot gnu dot org 2010-06-29 16:28 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43636
[Bug target/43610] [4.5 Regression] ICE: in prepare_float_lib_cmp, at optabs.c:4392 with -fno-trapping-math and _Decimal64 comparison
--- Comment #13 from jakub at gcc dot gnu dot org 2010-06-29 16:30 --- Fixed on the trunk, unfixed on the branch. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.5/4.6 Regression] ICE: in|[4.5 Regression] ICE: in |prepare_float_lib_cmp, at |prepare_float_lib_cmp, at |optabs.c:4392 with -fno-|optabs.c:4392 with -fno- |trapping-math and _Decimal64|trapping-math and _Decimal64 |comparison |comparison http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43610
[Bug c/44715] Break in increment expression of for statement inconsistent with g++
--- Comment #1 from joseph at codesourcery dot com 2010-06-29 16:36 --- Subject: Re: New: Break in increment expression of for statement inconsistent with g++ On Tue, 29 Jun 2010, doug dot gregor at gmail dot com wrote: g++ seems to have the right behavior here, and in any case g++ can't really be changed now: Qt's foreach macro depends on having break bind to the inner for loop. Yes, the inconsistency should be fixed, but for both C and C++ I get error: break statement not within loop or switch if I only have one loop rather than nested loops, and break binding to the inner loop seems inconsistent with that error. The C standard specifically says that continue and break statements must appear in a loop body (or switch body, in the case of break); if you make break bind to the inner loop, you should also not have that error in the single loop case (the rule should change to allow additional positions in the loop outside its body). Whatever is done needs clearly defining and documenting (with testcases) for both break and continue, and including all relevant places in for, while, do-while and switch statements (I do not make a claim here as to exactly which places should allow break and so bind to the inner construct, and which should not and so bind to the outer construct if any). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44715
Re: [Bug c/44715] New: Break in increment expression of for statement inconsistent with g++
What does a break with a statement expression do for each frontend? Is
it even valid to have a break there(without a statement expression)?
If it is valid, what does each standard say about the break there? If
they say the same thing then I say both frontends should behave the
same but if the c standard says a break should apply to the outer one
then we should follow that for statement expressions also.
On Jun 29, 2010, at 9:20 AM, doug dot gregor at gmail dot com gcc-bugzi...@gcc.gnu.org
wrote:
The following program exhibits different behavior with gcc vs. g++:
dgregor$ cat t.c
#include stdio.h
int main()
{
int i;
for( i = 0; i 3; )
for( ; ; ({ i++; break; }) )
printf( %d\n, i );
}
With gcc, the break in the statement expression applies to the outer
for
loop, so we get just 0 as output:
dgregor$ gcc t.c ./a.out
0
with g++, the break in the statement expression applies to the inner
for
loop, so we get 0 1 and 2 as the output:
dgregor$ g++ t.c ./a.out
0
1
2
g++ seems to have the right behavior here, and in any case g++ can't
really be
changed now: Qt's foreach macro depends on having break bind to
the inner for
loop.
--
Summary: Break in increment expression of for statement
inconsistent with g++
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: doug dot gregor at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44715
[Bug c/44715] Break in increment expression of for statement inconsistent with g++
--- Comment #2 from pinskia at gmail dot com 2010-06-29 16:40 ---
Subject: Re: New: Break in increment expression of for statement
inconsistent with g++
What does a break with a statement expression do for each frontend? Is
it even valid to have a break there(without a statement expression)?
If it is valid, what does each standard say about the break there? If
they say the same thing then I say both frontends should behave the
same but if the c standard says a break should apply to the outer one
then we should follow that for statement expressions also.
On Jun 29, 2010, at 9:20 AM, doug dot gregor at gmail dot com
gcc-bugzi...@gcc.gnu.org
wrote:
The following program exhibits different behavior with gcc vs. g++:
dgregor$ cat t.c
#include stdio.h
int main()
{
int i;
for( i = 0; i 3; )
for( ; ; ({ i++; break; }) )
printf( %d\n, i );
}
With gcc, the break in the statement expression applies to the outer
for
loop, so we get just 0 as output:
dgregor$ gcc t.c ./a.out
0
with g++, the break in the statement expression applies to the inner
for
loop, so we get 0 1 and 2 as the output:
dgregor$ g++ t.c ./a.out
0
1
2
g++ seems to have the right behavior here, and in any case g++ can't
really be
changed now: Qt's foreach macro depends on having break bind to
the inner for
loop.
--
Summary: Break in increment expression of for statement
inconsistent with g++
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: doug dot gregor at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44715
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44715
[Bug c/44715] Break in increment expression of for statement inconsistent with g++
--- Comment #3 from joseph at codesourcery dot com 2010-06-29 16:46 --- Subject: Re: Break in increment expression of for statement inconsistent with g++ On Tue, 29 Jun 2010, pinskia at gmail dot com wrote: What does a break with a statement expression do for each frontend? Is it even valid to have a break there(without a statement expression)? The relevant contexts have expressions, so without statement expressions it's not possible to have break there. The C standard (I haven't checked C++) requires break (and continue, which probably has much the same issue) to be in a loop or switch body - but being elsewhere in the loop than its body isn't possible in standard C anyway. When I was fixing statement expression issues with jumps, and defining exactly what was permitted (bug 772), I didn't think of this particular issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44715
[Bug target/44707] operand requires impossible reload
--- Comment #1 from uweigand at gcc dot gnu dot org 2010-06-29 16:56
---
I agree, this looks like a longstanding bug in
rs6000_legitimize_reload_address.
What happens here is that find_reloads is called on this insn:
(insn 15 8 18 2 pr44707.c:13 (asm_operands/v (/* %0 %1 %2 %3 %4 */) () 0 [
(mem/s/c:SI (symbol_ref:SI (v) [flags 0xc0] var_decl 0xf6f90fc0
v) [3 v.a+0 S4 A32])
(mem/c/i:SI (symbol_ref:SI (w) [flags 0xc4] var_decl 0xf6f91020
w) [3 w+0 S4 A32])
(mem/s/c:SI (const:SI (plus:SI (symbol_ref:SI (v) [flags 0xc0]
var_decl 0xf6f90fc0 v)
(const_int 4 [0x4]))) [3 v.b+0 S4 A32])
(mem/s/c:SI (const:SI (plus:SI (symbol_ref:SI (v) [flags 0xc0]
var_decl 0xf6f90fc0 v)
(const_int 8 [0x8]))) [3 v.c+0 S4 A32])
(mem/s/c:SI (const:SI (plus:SI (symbol_ref:SI (v) [flags 0xc0]
var_decl 0xf6f90fc0 v)
(const_int 12 [0xc]))) [3 v.d+0 S4 A32])
]
[
(asm_input:SI (nro) (null):0)
(asm_input:SI (nro) (null):0)
(asm_input:SI (nro) (null):0)
(asm_input:SI (nro) (null):0)
(asm_input:SI (nro) (null):0)
]
[] pr44707.c:14) -1 (nil))
rs6000_find_reloads_address notices that it can rewrite
(symbol_ref:SI v)
to
(lo_sum:SI (high:SI (symbol_ref:SI v)) (symbol_ref:SI v))
(and place a reload on the (high:SI) subexpression) and does so. This change
remains in the insn, and when in the next iteration find_reloads is called
again, the insn now looks like:
(insn 15 8 18 2 pr44707.c:13 (asm_operands/v (/* %0 %1 %2 %3 %4 */) () 0 [
(mem/s/c:SI (lo_sum:SI (high:SI (symbol_ref:SI (v) [flags 0xc0]
var_decl 0xf6f90fc0 v))
(symbol_ref:SI (v) [flags 0xc0] var_decl 0xf6f90fc0 v))
[3 v.a+0 S4 A32])
(mem/c/i:SI (lo_sum:SI (high:SI (symbol_ref:SI (w) [flags 0xc4]
var_decl 0xf6f91020 w))
(symbol_ref:SI (w) [flags 0xc4] var_decl 0xf6f91020 w))
[3 w+0 S4 A32])
(mem/s/c:SI (const:SI (plus:SI (symbol_ref:SI (v) [flags 0xc0]
var_decl 0xf6f90fc0 v)
(const_int 4 [0x4]))) [3 v.b+0 S4 A32])
(mem/s/c:SI (const:SI (plus:SI (symbol_ref:SI (v) [flags 0xc0]
var_decl 0xf6f90fc0 v)
(const_int 8 [0x8]))) [3 v.c+0 S4 A32])
(mem/s/c:SI (const:SI (plus:SI (symbol_ref:SI (v) [flags 0xc0]
var_decl 0xf6f90fc0 v)
(const_int 12 [0xc]))) [3 v.d+0 S4 A32])
]
[
(asm_input:SI (nro) (null):0)
(asm_input:SI (nro) (null):0)
(asm_input:SI (nro) (null):0)
(asm_input:SI (nro) (null):0)
(asm_input:SI (nro) (null):0)
]
[] pr44707.c:14) -1 (nil))
However, this expression is now no longer recognized by
rs6000_legitimize_reload_address, and therefore no reload on (high:SI) is
pushed.
Thus, when the reload is finally processed, a reload insn like this is
generated:
(insn 26 8 27 2 pr44707.c:13 (set (reg:SI 10 10)
(lo_sum:SI (high:SI (symbol_ref:SI (v) [flags 0xc0] var_decl
0xf6f90fc0 v))
(symbol_ref:SI (v) [flags 0xc0] var_decl 0xf6f90fc0 v))) -1
(nil))
As this does not actually correspond to any valid pattern, an assertion is
triggered.
The underlying problem is that with the current reload setup, an implementation
of LEGITIMATE_RELOAD_ADDRESS must always recognize expressions it has itself
generated in an earlier call. And indeed, that's what a comment in
rs6000_legitimize_reload_address says:
static rtx
rs6000_legitimize_reload_address (rtx x, enum machine_mode mode,
int opnum, int type,
int ind_levels ATTRIBUTE_UNUSED, int *win)
{
bool reg_offset_p = reg_offset_addressing_ok_p (mode);
/* We must recognize output that we have already generated ourselves. */
if (GET_CODE (x) == PLUS
GET_CODE (XEXP (x, 0)) == PLUS
GET_CODE (XEXP (XEXP (x, 0), 0)) == REG
GET_CODE (XEXP (XEXP (x, 0), 1)) == CONST_INT
GET_CODE (XEXP (x, 1)) == CONST_INT)
However, this recognizes only certain types of such output, and in particular
not the one that shows up in this test case.
It seems to me that simply extending rs6000_legitimate_reload_address to handle
this case as well should fix the bug.
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-06-29 16:56:47
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44707
[Bug target/44707] operand requires impossible reload
--- Comment #2 from uweigand at gcc dot gnu dot org 2010-06-29 17:03 --- Created an attachment (id=21041) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21041action=view) Recognize (lo_sum (high ...) ...) in rs6000_legitimize_reload_address It seems to me that simply extending rs6000_legitimate_reload_address to handle this case as well should fix the bug. And indeed, this (otherwise untested) patch fixes the bug for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44707
[Bug c++/35167] Problem with non-type template parameter and name lookup in template.
--- Comment #4 from jason at gcc dot gnu dot org 2010-06-29 17:32 --- Reopening, this is a bug. The address of a static member function is a valid address constant expression: it's a pointer to a function, in this case created implicitly. -- jason at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35167
[Bug c++/35167] Problem with non-type template parameter and name lookup in template.
-- jason at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-29 17:32:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35167
[Bug c++/35167] problem with function address constant non-type template parameter in template
--- Comment #5 from jason at gcc dot gnu dot org 2010-06-29 17:34 --- tweaking summary a bit. -- jason at gcc dot gnu dot org changed: What|Removed |Added Summary|Problem with non-type |problem with function |template parameter and name |address constant non-type |lookup in template. |template parameter in ||template http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35167
[Bug c++/41544] unqualified member function reference is or not valid in constant expression depending on class being a template or not
--- Comment #3 from jason at gcc dot gnu dot org 2010-06-29 17:34 --- Dupe of 35167, which I have now reopened. *** This bug has been marked as a duplicate of 35167 *** -- jason at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41544
[Bug c++/35167] problem with function address constant non-type template parameter in template
--- Comment #6 from jason at gcc dot gnu dot org 2010-06-29 17:34 --- *** Bug 41544 has been marked as a duplicate of this bug. *** -- jason at gcc dot gnu dot org changed: What|Removed |Added CC||skandalfo at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35167
[Bug middle-end/44716] New: Bootstrap fails with partial inlining (r161382)
The ia64-hp-hpux11.23 platform fails when building the C++ library during a bootstrap build with r161382. r161381 works. r161521, which has some bug fixes, still fails. The failure only occurs with bootstrap, the compiler faults when building the libstdc++ library. /proj/opensrc_nobackup/sje/reg3/build-ia64-hp-hpux11.23-trunk/obj_gcc/ia64-hp-hpux11.23/libstdc++-v3/include/bits/postypes.h:123:12: internal compiler error: Illegal instruction Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[4]: *** [ia64-hp-hpux11.23/bits/stdc++.h.gch/O2ggnu++0x.gch] Error Running under gdb didn't give me a complete backtrace but did show: #0 0x42c88b0:2 in cplus_expand_constant (cst=0x6432d880) at /proj/opensrc_nobackup/sje/reg3/src/trunk/gcc/cp/expr.c:70 I will try turning off partial inlining and see if that fixes the problem using the r161382 sources. This bug doesn't appear to be the same as PR44671 (fixed in r161521) or PR44687 (an ICE error in tree_nrv). -- Summary: Bootstrap fails with partial inlining (r161382) Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sje at cup dot hp dot com GCC build triplet: ia64-hp-hpux11.23 GCC host triplet: ia64-hp-hpux11.23 GCC target triplet: ia64-hp-hpux11.23 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44716
[Bug c++/44717] New: [4.5 Regression] extern C static void test(); produces error
Compiling the following code:
extern C static void test();
with a 4.5.1 snapshot results in:
test.cpp:1:12: error: invalid use of ‘static’ in linkage specification
The supposedly equivalent
extern C {
static void test();
}
works fine.
This used to work before (not sure what version).
Real-world use: This issue breaks building the LZMA SDK 9.12
--
Summary: [4.5 Regression] extern C static void test(); produces
error
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bero at arklinux dot org
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44717
[Bug other/44034] target hooks are hard to maintain
--- Comment #6 from amylaar at gcc dot gnu dot org 2010-06-29 18:22 --- Subject: Bug 44034 Author: amylaar Date: Tue Jun 29 18:22:00 2010 New Revision: 161547 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161547 Log: gcc: PR other/44034 * target.def, doc/tm.texi.in, genhooks.c: New files. * target.h: Instead of defining individual hook members, define DEFHOOKPOD / DEFHOOK / DEFHOOK_UNDOC / HOOKSTRUCT and include target.def. * target-def.h: Instead of defining individual hook initializers, include target-hooks-def.h. * df-scan.c, haifa-sched.c, sel-sched.c: Rename targetm members: targetm.live_on_entry - targetm.extra_live_on_entry targetm.sched.md_finish -targetm.sched.finish targetm.sched.md_init - targetm.sched.init targetm.sched.md_init_global - targetm.sched.init_global targetm.asm_out.unwind_label - targetm.asm_out.emit_unwind_label targetm.asm_out.except_table_label - targetm.asm_out.emit_except_table_label targetm.asm_out.visibility - targetm.asm_out.assemble_visibility targetm.target_help - targetm.help targetm.vectorize.builtin_support_vector_misalignment - targetm.vectorize.support_vector_misalignment targetm.file_start_app_off - targetm.asm_file_start_app_off targetm.file_start_file_directive - targetm.asm_file_start_file_directive * dwarf2out.c, opts.c, tree-vect-data-refs.c, except.c: Likewise. * varasm.c, config/alpha/alpha.c, config/cris/cris.c: Likewise. * gcc/config/spu/spu.c, config/ia64/ia64.c: Rename target macros: TARGET_VECTOR_ALIGNMENT_REACHABLE - TARGET_VECTORIZE_VECTOR_ALIGNMENT_REACHABLE TARGET_SUPPORT_VECTOR_MISALIGNMENT - TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT TARGET_UNWIND_EMIT - TARGET_ASM_UNWIND_EMIT * config/rs6000/rs6000.c, config/arm/arm.c: Likewise. * Makefile.in (TARGET_H): Depend on target.def. (TARGET_DEF_H): Depend on target-hooks-def.h. (target-hooks-def.h, tm.texi, s-target-hooks-def-h): New rules. (s-tm-texi, build/genhooks.o, build/genhooks): Likewise. * doc/tm.texi: Regenerate. gcc/c-family: * c-common.c: Rename targetm member: targetm.enum_va_list - targetm.enum_va_list_p gcc/po: * EXCLUDES: Add genhooks.c. Index: gcc/doc/tm.texi Added: trunk/gcc/doc/tm.texi.in - copied, changed from r161540, trunk/gcc/doc/tm.texi trunk/gcc/genhooks.c trunk/gcc/target.def Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/config/alpha/alpha.c trunk/gcc/config/arm/arm.c trunk/gcc/config/cris/cris.c trunk/gcc/config/ia64/ia64.c trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/spu/spu.c trunk/gcc/df-scan.c trunk/gcc/doc/tm.texi trunk/gcc/dwarf2out.c trunk/gcc/except.c trunk/gcc/haifa-sched.c trunk/gcc/opts.c trunk/gcc/po/ChangeLog trunk/gcc/po/EXCLUDES trunk/gcc/sel-sched.c trunk/gcc/target-def.h trunk/gcc/target.h trunk/gcc/tree-vect-data-refs.c trunk/gcc/varasm.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44034
[Bug c++/44717] [4.5 Regression] extern C static void test(); produces error
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-29 18:23 --- There was only a few version of GCC which accepted this. They were incorrectly accepting it. See PR 26068 for the versions which accepted it (marked as known to fail). This is invalid code. *** This bug has been marked as a duplicate of 26068 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44717
[Bug c++/26068] [4.0 Regression] extern C static function should not be allowed
--- Comment #10 from pinskia at gcc dot gnu dot org 2010-06-29 18:23 --- *** Bug 44717 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||bero at arklinux dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26068
[Bug bootstrap/44714] libgcc configure: error: cannot compute suffix of object files
--- Comment #3 from jbare7 at gmail dot com 2010-06-29 18:23 --- sudo make There's no need to build as root. If I dont build as root I get errors with removing certain files due to lack of permissions for some reason. Then I found out I needed GMP, MPFR, and MPC installed. I downloaded the packages to my desktop and built and installed them, several times since some of the latest versions did not seem to be compatible with each other. So after a few tries I found a combination of versions of these that would install correctly and still met the stated requirements for installing gcc 4.5.0 You don't need to install them, you can just put them in the gcc-4.5.0 directory, that's sometimes easier. Or you can probably install them from your distro's package management system. I tried putting them in the gcc-4.5.0 directory and I tried installing them from my distro, but neither of these worked to fix the error. See `config.log' for more details. Like it says, see config.log for more details Sorry, but I am relatively new to Linux and am not experienced in reading this file. However, in looking through it I noticed several places where it printed an error and then a portion of C code where the error occurred. One of these seemed to be checking the version of MPFR. Others couldnt find certain .h files. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44714
[Bug bootstrap/44714] libgcc configure: error: cannot compute suffix of object files
--- Comment #4 from jbare7 at gmail dot com 2010-06-29 18:29 --- (In reply to comment #2) also, please check whether this is the same issue as Bug 43819 (did you search for existing bugs with cannot compute suffix before entering a bug?) It's likely you need to set LD_LIBRARY_PATH so that libgmp etc can be found That wouldn't be necessary if you installed your distro's packages, or if you put the gmp/mpfr/mpc sources in the gcc-4.5.0 directory instead of building and installing them manually Ah I did not find that bug report before. But as I said before, I'm fairly new to Linux and I'm not sure how to set LD_LIBRARY_PATH correctly. I tried setenv, but TAB completion did not recognize LD_LIBRARY_PATH as an option for this. And yea, putting the other package directories in the gcc-4.5.0 directory didn't fix the issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44714
[Bug fortran/44718] New: Procedure-pointer name is wrongly regarded as external procedure
Reported by John McFarland at http://gcc.gnu.org/ml/fortran/2010-06/msg00286.html If one uses procedure(interface), pointer :: f at multiple scopes of the same program, gfortran treats the proc-pointer name (f) as external name - and thus rejects using it once as function and once as subroutine name: Error: Global name 'f' at (1) is already being used as a SUBROUTINE at (2) Test case by John McFarland: MODULE m IMPLICIT NONE CONTAINS FUNCTION func(x) RESULT(y) INTEGER :: x,y y = x *2 END FUNCTION func SUBROUTINE sub(x) INTEGER :: x PRINT*, x END SUBROUTINE sub SUBROUTINE use_func() PROCEDURE(func), POINTER :: f INTEGER :: y f = func y = f(2) END SUBROUTINE use_func SUBROUTINE use_sub() PROCEDURE(sub), POINTER :: f f = sub CALL f(2) END SUBROUTINE use_sub END MODULE m -- Summary: Procedure-pointer name is wrongly regarded as external procedure Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44718
[Bug bootstrap/44714] libgcc configure: error: cannot compute suffix of object files
--- Comment #5 from redi at gcc dot gnu dot org 2010-06-29 18:43 --- (In reply to comment #3) sudo make There's no need to build as root. If I dont build as root I get errors with removing certain files due to lack of permissions for some reason. That's because you've tried to build as root already. Remove the whole build tree (as root) then as non-root create a new directory and make. You don't have to do this, but there's no reason to build as root. You do need to make install as root if you are trying to install to e.g. /usr/local Then I found out I needed GMP, MPFR, and MPC installed. I downloaded the packages to my desktop and built and installed them, several times since some of the latest versions did not seem to be compatible with each other. So after a few tries I found a combination of versions of these that would install correctly and still met the stated requirements for installing gcc 4.5.0 You don't need to install them, you can just put them in the gcc-4.5.0 directory, that's sometimes easier. Or you can probably install them from your distro's package management system. I tried putting them in the gcc-4.5.0 directory and I tried installing them from my distro, but neither of these worked to fix the error. You need to rename them to just gmp instead of gmp-4.3.2 etc. Or if you install from your distro you need the development packages, for gmp I think that's libgmp3-dev, libmpfr-dev and libmpc-dev See `config.log' for more details. Like it says, see config.log for more details Sorry, but I am relatively new to Linux and am not experienced in reading this file. However, in looking through it I noticed several places where it printed an error and then a portion of C code where the error occurred. One of these seemed to be checking the version of MPFR. Others couldnt find certain .h files. Most of the errors are not fatal, they are testing the features of your system, so it's normal to see errors. Near the end of the file will be one that causes the problem, search for the text cannot compute suffix. If you can't find it, attach libgcc/config.log to this bug report. (In reply to comment #4) Ah I did not find that bug report before. But as I said before, I'm fairly new to Linux and I'm not sure how to set LD_LIBRARY_PATH correctly. I tried setenv, but TAB completion did not recognize LD_LIBRARY_PATH as an option for this. And yea, putting the other package directories in the gcc-4.5.0 directory didn't fix the issue. Of course not, it's not an option. You could give absolutely any name to setenv, so how can it predict what you want to type? setenv is only the right command if you're using C shell, for sane shells you would use: export LD_LIBRARY_PATH=/path/to/your/libs For csh, if you insist on using it: setenv LD_LIBRARY_PATH /path/to/your/libs But I really suggest you figure out how to install the libraries from Ubuntu's packages, it will save you a lot of effort. You could also try the gcc-help mailing list, since I'm fairly sure this is user error, not a bug in gcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44714
[Bug bootstrap/44699] [4.6 Regression] Bootstrap failure for x86_64-apple-darwin10: ICE while compiling genmodes.c
--- Comment #12 from iains at gcc dot gnu dot org 2010-06-29 18:45 --- also fails when the bootstrap compiler is gcc-4.2 (apple 4.2.1). i688-apple-darwin9 is ok for the same trunk rev. -- iains at gcc dot gnu dot org changed: What|Removed |Added CC||iains at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44699
[Bug fortran/44582] gfortran generates wrong results due to wrong ABI in function with array return
--- Comment #18 from pault at gcc dot gnu dot org 2010-06-29 18:58 --- Subject: Bug 44582 Author: pault Date: Tue Jun 29 18:57:43 2010 New Revision: 161550 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161550 Log: 2010-06-29 Paul Thomas pa...@gcc.gnu.org PR fortran/44582 * trans-expr.c (arrayfunc_assign_needs_temporary): New function to determine if a function assignment can be made without a temporary. (gfc_trans_arrayfunc_assign): Move all the conditions that suppress the direct function call to the above new functon and call it. 2010-06-29 Paul Thomas pa...@gcc.gnu.org PR fortran/44582 * gfortran.dg/aliasing_array_result_1.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/aliasing_array_result_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44582
[Bug bootstrap/44719] New: [4.6 Regression] Make warning: overriding command
Revision 161547: http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg01465.html caused: Makefile:3712: warning: overriding commands for target `s-tm-texi' Makefile:3710: warning: ignoring old commands for target `s-tm-texi' The problem is the tab at # check if someone mistakenly only changed tm.texi. s-tm-texi: $(srcdir)/doc/tm.texi -- Tab in gcc/Makefile.in. -- Summary: [4.6 Regression] Make warning: overriding command Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44719
[Bug bootstrap/44714] libgcc configure: error: cannot compute suffix of object files
--- Comment #6 from redi at gcc dot gnu dot org 2010-06-29 19:00 --- (In reply to comment #5) Or if you install from your distro you need the development packages, for gmp ^ that should say for Ubuntu not for gmp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44714
[Bug fortran/44718] Procedure-pointer name is wrongly regarded as external procedure
-- janus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-29 19:02:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44718
[Bug fortran/44582] gfortran generates wrong results due to wrong ABI in function with array return
--- Comment #19 from pault at gcc dot gnu dot org 2010-06-29 19:03 --- Subject: Bug 44582 Author: pault Date: Tue Jun 29 19:03:41 2010 New Revision: 161551 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161551 Log: 2010-06-29 Paul Thomas pa...@gcc.gnu.org PR fortran/44582 * trans-expr.c (arrayfunc_assign_needs_temporary): New function to determine if a function assignment can be made without a temporary. (gfc_trans_arrayfunc_assign): Move all the conditions that suppress the direct function call to the above new functon and call it. 2010-06-29 Paul Thomas pa...@gcc.gnu.org PR fortran/44582 * gfortran.dg/aliasing_array_result_1.f90 : New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/aliasing_array_result_1.f90 Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/trans-expr.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44582
[Bug fortran/44696] [OOP] ASSOCIATED fails on polymorphic variables
--- Comment #5 from janus at gcc dot gnu dot org 2010-06-29 19:06 --- Subject: Bug 44696 Author: janus Date: Tue Jun 29 19:06:07 2010 New Revision: 161554 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161554 Log: 2010-06-29 Janus Weil ja...@gcc.gnu.org PR fortran/44696 * trans-intrinsic.c (gfc_conv_associated): Handle polymorphic variables passed as second argument of ASSOCIATED. 2010-06-29 Janus Weil ja...@gcc.gnu.org PR fortran/44696 * gfortran.dg/associated_target_4.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/associated_target_4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44696
[Bug fortran/44696] [OOP] ASSOCIATED fails on polymorphic variables
--- Comment #6 from janus at gcc dot gnu dot org 2010-06-29 19:08 --- Fixed with r161554. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44696
[Bug bootstrap/44719] [4.6 Regression] Make warning: overriding command
--- Comment #1 from amylaar at gcc dot gnu dot org 2010-06-29 19:13 --- Sorry, I certainly didn't mean to put a rule there; not sure if it was a typo or some smartass-autoindent running wild. I've removed the offending tab. -- amylaar at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44719
[Bug rtl-optimization/44695] [4.6 Regression] ice in simplify_subreg, at simplify-rtx.c:5117
--- Comment #4 from hjl dot tools at gmail dot com 2010-06-29 19:16 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2010-06/msg03033.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44695
[Bug bootstrap/44713] [4.6 regression] Revision 161530 failed bootstrap
--- Comment #5 from hjl dot tools at gmail dot com 2010-06-29 19:21 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44713
[Bug c++/44587] [4.4/4.5/4.6 Regression] ICE in instantiate_decl
--- Comment #3 from jason at gcc dot gnu dot org 2010-06-29 19:29 --- Subject: Bug 44587 Author: jason Date: Tue Jun 29 19:29:02 2010 New Revision: 161559 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161559 Log: PR c++/44587 * pt.c (has_value_dependent_address): New. (value_dependent_expression_p): Check it. (convert_nontype_argument): Likewise. Call decay_conversion before folding if we want a pointer. * semantics.c (finish_id_expression): Don't add SCOPE_REF if the scope is the current instantiation. Added: trunk/gcc/testsuite/g++.dg/template/qualified-id2.C trunk/gcc/testsuite/g++.dg/template/qualified-id3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44587
[Bug c++/44587] [4.4/4.5/4.6 Regression] ICE in instantiate_decl
--- Comment #4 from jason at gcc dot gnu dot org 2010-06-29 19:30 --- Subject: Bug 44587 Author: jason Date: Tue Jun 29 19:29:58 2010 New Revision: 161561 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161561 Log: PR c++/44587 * pt.c (has_value_dependent_address): New. (value_dependent_expression_p): Check it. (convert_nontype_argument): Likewise. Call decay_conversion before folding if we want a pointer. * semantics.c (finish_id_expression): Don't add SCOPE_REF if the scope is the current instantiation. Added: branches/gcc-4_5-branch/gcc/testsuite/g++.dg/template/qualified-id2.C branches/gcc-4_5-branch/gcc/testsuite/g++.dg/template/qualified-id3.C Modified: branches/gcc-4_5-branch/gcc/cp/ChangeLog branches/gcc-4_5-branch/gcc/cp/pt.c branches/gcc-4_5-branch/gcc/cp/semantics.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44587
[Bug c++/44587] [4.4/4.5/4.6 Regression] ICE in instantiate_decl
--- Comment #5 from jason at gcc dot gnu dot org 2010-06-29 19:30 --- Subject: Bug 44587 Author: jason Date: Tue Jun 29 19:30:29 2010 New Revision: 161562 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161562 Log: PR c++/44587 * pt.c (has_value_dependent_address): New. (value_dependent_expression_p): Check it. (convert_nontype_argument): Likewise. Call decay_conversion before folding if we want a pointer. * semantics.c (finish_id_expression): Don't add SCOPE_REF if the scope is the current instantiation. Added: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/qualified-id2.C branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/qualified-id3.C Modified: branches/gcc-4_4-branch/gcc/cp/ChangeLog branches/gcc-4_4-branch/gcc/cp/pt.c branches/gcc-4_4-branch/gcc/cp/semantics.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44587
[Bug fortran/44718] Procedure-pointer name is wrongly regarded as external procedure
--- Comment #1 from janus at gcc dot gnu dot org 2010-06-29 19:31 --- The following patch fixes it: Index: gcc/fortran/resolve.c === --- gcc/fortran/resolve.c (revision 161551) +++ gcc/fortran/resolve.c (working copy) @@ -2259,6 +2259,7 @@ is_external_proc (gfc_symbol *sym) !(sym-attr.intrinsic || gfc_is_intrinsic (sym, sym-attr.subroutine, sym-declared_at)) sym-attr.proc != PROC_ST_FUNCTION +!sym-attr.proc_pointer !sym-attr.use_assoc sym-name) return true; Regtesting now ... -- janus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-06-29 19:02:30 |2010-06-29 19:31:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44718
[Bug c++/44587] [4.4/4.5/4.6 Regression] ICE in instantiate_decl
--- Comment #6 from jason at gcc dot gnu dot org 2010-06-29 19:31 --- Fixed for 4.4.5. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44587
[Bug debug/44668] class-DW_TAG_typedef is missing DW_AT_accessibility
--- Comment #4 from jakub at gcc dot gnu dot org 2010-06-29 19:37 --- Subject: Bug 44668 Author: jakub Date: Tue Jun 29 19:37:46 2010 New Revision: 161563 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161563 Log: PR debug/44668 * dwarf2out.c (add_accessibility_attribute): New function. (gen_subprogram_die, gen_variable_die, gen_field_die): Use it instead of adding DW_AT_accessibility manually. (gen_enumeration_type_die, gen_struct_or_union_type_die, gen_typedef_die): Use it. * g++.dg/debug/dwarf2/accessibility1.C: New test. Added: trunk/gcc/testsuite/g++.dg/debug/dwarf2/accessibility1.C Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44668
[Bug tree-optimization/43801] [4.5/4.6 Regression] error: function causes a section type conflict with -fipa-cp -fipa-cp-clone
--- Comment #7 from jakub at gcc dot gnu dot org 2010-06-29 19:46 --- Subject: Bug 43801 Author: jakub Date: Tue Jun 29 19:46:05 2010 New Revision: 161564 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161564 Log: PR tree-optimization/43801 * cgraph.c (cgraph_create_virtual_clone): Clear DECL_SECTION_NAME if old_decl was DECL_ONE_ONLY. * g++.dg/torture/pr43801.C: New test. Added: trunk/gcc/testsuite/g++.dg/torture/pr43801.C Modified: trunk/gcc/ChangeLog trunk/gcc/cgraph.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43801
[Bug fortran/44709] BLOCK and GOTO/EXIT/CYCLE
--- Comment #1 from burnus at gcc dot gnu dot org 2010-06-29 20:03 ---
As pointed out by Andrew: One should follow C++ and generate try {} finally{}
blocks (TRY_FINALLY_EXPR).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44709
[Bug bootstrap/44720] New: [4.6 Regression] Yet another bootstrap failure on x86_64-apple-darwin10
Bootstrapping revision 161565 on x86_64-apple-darwin10 fails with ... gcc -c -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 -DHAVE_CONFIG_H -I. -I. -I../../p_work/gcc -I../../p_work/gcc/. -I../../p_work/gcc/../include -I../../p_work/gcc/../libcpp/include -I/opt/sw64/include -I/opt/sw64/include -I../../p_work/gcc/../libdecnumber -I../../p_work/gcc/../libdecnumber/dpd -I../libdecnumber -I/opt/sw64/include -I/opt/sw64/include -DCLOOG_PPL_BACKEND -I/opt/sw64/include -I. -I. -I../../p_work/gcc -I../../p_work/gcc/. -I../../p_work/gcc/../include -I../../p_work/gcc/../libcpp/include -I/opt/sw64/include -I/opt/sw64/include -I../../p_work/gcc/../libdecnumber -I../../p_work/gcc/../libdecnumber/dpd -I../libdecnumber -I/opt/sw64/include -I/opt/sw64/include -DCLOOG_PPL_BACKEND \ ../../p_work/gcc/config/darwin.c ../../p_work/gcc/config/darwin.c: In function 'darwin_override_options': ../../p_work/gcc/config/darwin.c:1867: error: 'struct asm_out' has no member named 'unwind_label' -- Summary: [4.6 Regression] Yet another bootstrap failure on x86_64-apple-darwin10 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: x86_64-apple-darwin10 GCC host triplet: x86_64-apple-darwin10 GCC target triplet: x86_64-apple-darwin10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44720
