[Bug tree-optimization/40436] [4.5/4.6 regression] 0.5% code size regression caused by r147852
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #46 from Jan Hubicka hubicka at gcc dot gnu.org 2010-11-19 08:18:11 UTC --- I think CCP is not folding one way or another as it might lead to inconsistent control flows (i.e. one place assuming that the given undefined value is 0, other that 1). Initializing them to 0 is one consistent way to get stuff optimized out. I am not biggest friend of that (I think they should stay undefined and liveness should handle it well) but givent hat RTL land does it anyway there is no point to bother. Anyway I looked at the date for jump in CSiBE sizes in our tester. It is May 30 2009 It coincide with Richard's EH unwind reorg 2009-05-29 Richard Henderson r...@redhat.com * cfgcleanup.c (try_crossjump_to_edge): Only skip past NOTE_INSN_BASIC_BLOCK. * cfglayout.c (duplicate_insn_chain): Copy epilogue insn marks. Duplicate NOTE_INSN_EPILOGUE_BEG notes. * cfgrtl.c (can_delete_note_p): Allow NOTE_INSN_EPILOGUE_BEG to be deleted. * dwarf2out.c (struct cfa_loc): Change indirect field to bitfield, add in_use field. (add_cfi): Disable check redefining cfa away from drap. (lookup_cfa_1): Add remember argument; handle remember/restore. (lookup_cfa): Pass remember argument. (cfa_remember): New. given that it makes tables asynchronous and it is thus correcntess issue and given that it is misaccounted as code size by size command and thus also CSiBE and given that I analyzed quite few testcases and found no inliner bugs, I think the bug no longer exists (-Os inliner was improved a lot). It would be nice if someone tested it using the cross, for now I am putting it into waiting stage and will open new PRs for the few new issues I noticed.
[Bug middle-end/46554] New: Less inlining leads to CSiBE regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46554
Summary: Less inlining leads to CSiBE regression
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hubi...@gcc.gnu.org
Created attachment 22451
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22451
testcase flex-2.5.31/regex.c
The loss here is not inlining regmatch_len. The catch is that the test if (m ==
((void *)0) || m-rm_so 0) is tested before all uses of regmatch_len and thus
optimized out. So it simplifies into m-rm_so 0 test and arithmetic that
ends up being cheaper than call.
int regmatch_len (regmatch_t * m)
{
if (m == ((void *)0) || m-rm_so 0) {
return 0;
}
return m-rm_eo - m-rm_so;
}
It is used as:
if (m == ((void *)0) || m-rm_so 0)
return 0;
if (regmatch_len (m) 20)
s = regmatch_cpy (m, buf, src);
else
s = regmatch_dup (m, src);
Tricky. Inliner sees it as:
Analyzing function body size: regmatch_len
freq: 1000 size: 2 time: 2 if (m_2(D) == 0B)
freq: 898 size: 1 time: 1 D.7268_3 = m_2(D)-rm_so;
50% will be eliminated by inlining
freq: 898 size: 2 time: 2 if (D.7268_3 0)
freq: 726 size: 1 time: 1 D.7270_4 = m_2(D)-rm_eo;
50% will be eliminated by inlining
freq: 726 size: 1 time: 1 D.7268_5 = m_2(D)-rm_so;
50% will be eliminated by inlining
freq: 726 size: 1 time: 1 D.7269_6 = D.7270_4 - D.7268_5;
freq: 1000 size: 1 time: 2 return D.7269_1;
will eliminated by inlining
Overall function body time: 9-3 size: 11-5
With function call overhead time: 9-15 size: 11-8
I can imagine we can try to get summary based on value ranges, instead of known
constants, do early VRP and work out first test well.
Even optimizing the first conditoinal away won't make it inlined, it will be
still considered to have size 9, so code will be expected to grow by 1 byte.
Optimizing second conditoinal is even trickier.
The code can be optimized away by IP-value range propagation that would
be interesting optimization to have...
[Bug middle-end/46555] New: PHI RTL expansion leads to CSiBE regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46555 Summary: PHI RTL expansion leads to CSiBE regression Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: hubi...@gcc.gnu.org Created attachment 22452 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22452 testcase (OpenTCP-1.0.4/icmp.c) Hi, the problem here seems to be worse regalloc and also # D.4060_6 = PHI -1(2), -1(9), -1(11), -1(14), 0(15), -1(10) used to be optimized into since set of var to -1 (4 bytes), while now we produce 3 different copies. Crossjumping would unify it, but very late in the game. The problem is that ifcvt actually moves the set before conditoinal guarding the BB in question, so the individual sets are drifted earlier to different places in the program. Doing so might also complicate the regalloc. Michael, perhaps we can tell out-of-ssa to unify such cases? They are not that infrequent (and I think old tree based out-of-ssa did that?)
[Bug c/46547] [4.5/4.6 Regression] internal compiler error when converting a complex to a bool
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46547 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-19 08:38:53 UTC --- The problem is that c_fully_fold_internal doesn't recurse on the RHS of a MODIFY_EXPR: /* The RHS of a MODIFY_EXPR was fully folded when building that expression for the sake of conversion warnings. */ While this is true, here RHS was INDIRECT_REF of a POSTINCREMENT_EXPR of PARM_DECL, all with COMPLEX_TYPE or pointers to that and it was fully folded. But afterwards when this RHS is convert()ed to the LHS type, c_common_truthvalue_conversion is called and introduces new C_MAYBE_CONST_EXPRs into it. I wonder if we couldn't swap the order of c_fully_fold and convert_for_assignment in build_modify_expr: newrhs = c_fully_fold (newrhs, false, NULL); if (rhs_semantic_type) newrhs = build1 (EXCESS_PRECISION_EXPR, rhs_semantic_type, newrhs); newrhs = convert_for_assignment (location, lhstype, newrhs, rhs_origtype, ic_assign, npc, NULL_TREE, NULL_TREE, 0); so that it would be fully folding also whatever was added by convert_for_assignment. Joseph?
[Bug c/46547] [4.5/4.6 Regression] internal compiler error when converting a complex to a bool
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46547 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-19 08:46:46 UTC --- Actually, reading that comment again it, the conversion warnings are probably emitted during convert_for_assignment and thus the earlier c_fully_fold is needed. Perhaps we need another c_fully_fold if convert_for_assignment returned something different from the passed argument, or remove the if (code != MODIFY_EXPR) guard for c_fully_fold_internal on the RHS of a MODIFY_EXPR.
[Bug c++/46526] [4.6 Regression] VTable Problem?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46526
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-19
08:56:05 UTC ---
Looks to me like a tree sharing problem in the FE, will debug it.
int
main ()
{
B b;
A a;
}
is in *.original as:
struct B b;
cleanup_point Unknown tree: expr_stmt
(void) (b = TARGET_EXPR D.1439, {.D.1372={._vptr.Base=_ZTV1A + 16}})
;
struct A a;
cleanup_point Unknown tree: expr_stmt
(void) (a = TARGET_EXPR D.1468, {.D.1363={._vptr.Base=_ZTV1A + 16}})
;
while
int
main ()
{
A a;
B b;
}
as:
struct A a;
cleanup_point Unknown tree: expr_stmt
(void) (a = TARGET_EXPR D.1439, {.D.1363={._vptr.Base=_ZTV1B + 16}})
;
struct B b;
cleanup_point Unknown tree: expr_stmt
(void) (b = TARGET_EXPR D.1468, {.D.1372={._vptr.Base=_ZTV1B + 16}})
;
One would expect a being initialized with _ZTV1A + 16 and b with _ZTV1B + 16 in
both cases...
[Bug rtl-optimization/46556] New: Code size regression in struct access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46556
Summary: Code size regression in struct access
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amo...@gmail.com
/* -Os -mcpu=405 -msoft-float */
struct x
{
unsigned int a[16];
unsigned int b[16];
unsigned int c[16];
};
void
f (struct x *p, unsigned int n)
{
extern void foo (int, int, int);
int a = p-a[n];
int c = p-c[n];
int b = p-b[n];
foo (a, c, b);
}
results in
f:
stwu 1,-16(1)
mflr 0
addi 11,4,32
stw 0,20(1)
addi 0,4,16
mr 9,3
slwi 10,4,2
slwi 0,0,2
slwi 11,11,2
lwzx 5,9,0
lwzx 3,3,10
lwzx 4,9,11
bl foo
lwz 0,20(1)
addi 1,1,16
mtlr 0
blr
a four instruction code size regression against gcc-4.2, which produces
f:
stwu 1,-16(1)
mflr 0
slwi 4,4,2
stw 0,20(1)
add 9,4,3
lwz 5,64(9)
lwzx 3,4,3
lwz 4,128(9)
bl foo
lwz 0,20(1)
addi 1,1,16
mtlr 0
blr
gcc regressed on this testcase at 4.3.0
[Bug c++/46526] [4.6 Regression] VTable Problem?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46526 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-19 09:04:14 UTC --- Indeed, a tree sharing issue in C++ FE. arg 1 target_expr 0x718cac60 type record_type 0x718d17e0 A side-effects constant arg 0 var_decl 0x719f1e60 D.1439 type record_type 0x718d17e0 A ignored BLK file PQ.C line 19 col 5 size integer_cst 0x719cf7a8 64 unit size integer_cst 0x719cf7d0 8 align 64 context function_decl 0x718d0700 main arg 1 constructor 0x718dcaa0 type record_type 0x718d17e0 A constant lngt 1 idx field_decl 0x718d7390 D.1363 val constructor 0x718dca20 type record_type 0x718d10a8 Base constant lngt 1 idx field_decl 0x718d71c8 _vptr.Base val pointer_plus_expr 0x77ffc3f0 type pointer_type 0x718c8000 readonly constant arg 0 addr_expr 0x718e6c00 type pointer_type 0x718c8000 readonly constant arg 0 var_decl 0x719f13c0 _ZTV1A arg 1 integer_cst 0x719cf960 constant 16 and arg 1 target_expr 0x718cae10 type record_type 0x718d1f18 B side-effects constant arg 0 var_decl 0x718f1140 D.1468 type record_type 0x718d1f18 B ignored BLK file PQ.C line 20 col 5 size integer_cst 0x719cf7a8 64 unit size integer_cst 0x719cf7d0 8 align 64 context function_decl 0x718d0700 main arg 1 constructor 0x718dcc20 type record_type 0x718d1f18 B constant lngt 1 idx field_decl 0x718d75f0 D.1372 val constructor 0x718dca20 type record_type 0x718d10a8 Base constant lngt 1 idx field_decl 0x718d71c8 _vptr.Base val pointer_plus_expr 0x77ffc578 type pointer_type 0x718c8000 readonly constant arg 0 addr_expr 0x718ed870 type pointer_type 0x718c8000 readonly constant arg 0 var_decl 0x719f15a0 _ZTV1B arg 1 integer_cst 0x719cf960 constant 16 CONSTRUCTOR 0x718dca20 is shared in between those two expressions.
[Bug tree-optimization/46523] [4.6 Regression] ICE: error: inlined_to pointer set for noninline callers, multiple inline callers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46523 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-19 09:47:19 UTC --- Created attachment 22453 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22453 reduced testcase autoreduced testcase.
[Bug c++/46526] [4.6 Regression] VTable Problem?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46526
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-19
09:55:10 UTC ---
Created attachment 22454
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22454
gcc46-pr46526.patch
Possible fix. Not sure how often C++ FE tries to modify something within
expressions returned by cxx_eval_constant_expression. This patch is
conservative, perhaps might create too much garbage. On the other side,
looking at what is done in other parts of cxx_eval_constant_expression, it
usually just creates new trees and thus has the unsharing semantics in it.
If cxx_eval_bare_aggregate's:
/* Push our vtable pointer down into the base where it belongs. */
tree vptr_base = DECL_CONTEXT (ce-index);
tree base_ctor;
gcc_assert (ce-index == TYPE_VFIELD (type));
for (base_ctor = VEC_index (constructor_elt, n, 0)-value; ;
base_ctor = CONSTRUCTOR_ELT (base_ctor, 0)-value)
if (TREE_TYPE (base_ctor) == vptr_base)
{
constructor_elt *p = CONSTRUCTOR_ELT (base_ctor, 0);
gcc_assert (p-index == ce-index);
p-value = elt;
break;
}
is the only spot that actually tries to modify cxx_eval_constant_expression in
place, one could instead unshare it before starting to dive into the arguments,
but that could very well unshare twice e.g. all CONSTRUCTORS that went through
cxx_eval_bare_aggregate which created a new tree.
So this patch looks preferrable to me, but of course this is Jason's call what
to do.
[Bug c++/46526] [4.6 Regression] VTable Problem?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46526 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug middle-end/46297] [4.6 Regression] gfortran.dg/g77/980701-0.f FAILs with -Os -fno-asynchronous-unwind-tables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46297 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-19 10:01:46 UTC --- Fixed.
[Bug tree-optimization/46535] [4.6 Regression] Endless loop during inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46535
--- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-19
10:17:03 UTC ---
Created attachment 22455
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22455
reduced testcase
Reduced with
Index: gcc/ipa-inline.c
===
--- gcc/ipa-inline.c(revision 166907)
+++ gcc/ipa-inline.c(working copy)
@@ -1175,6 +1175,7 @@ cgraph_decide_inlining_of_small_function
{
if (where-decl == edge-callee-decl)
break;
+ gcc_assert (where != where-callers-caller);
where = where-callers-caller;
}
if (where-global.inlined_to)
[Bug tree-optimization/46535] [4.6 Regression] Endless loop during inlining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46535 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-19 10:18:02 UTC --- It looks like we are inlining a recursive virtual call and get confused in that process.
[Bug tree-optimization/46557] New: [4.6 Regression] ICE in cgraph_will_be_removed_from_program_if_no_direct_calls, at cgraph.c:2820
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46557
Summary: [4.6 Regression] ICE in
cgraph_will_be_removed_from_program_if_no_direct_calls
, at cgraph.c:2820
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
CC: hubi...@gcc.gnu.org
./cc1plus -quiet cppduchain.3.1.3.3.ii -O2 -std=c++0x
cppduchain.3.1.3.3.ii:39:9: internal compiler error: in
cgraph_will_be_removed_from_program_if_no_direct_calls, at cgraph.c:2820
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
reduced testcase:
template class T class TypePtr {
public:
T* operator-();
templateclass U
TypePtrU cast(U * = 0) const;
};
class AbstractType {
public:
typedef TypePtrAbstractType Ptr;
};
class TypeExchanger {
public:
virtual ~TypeExchanger() { }
};
class TypeAliasType {
public:
typedef TypePtrTypeAliasType Ptr;
AbstractType::Ptr type() const;
};
AbstractType::Ptr
shortenTypeForViewing(AbstractType::Ptr type)
{
struct ShortenAliasExchanger : public TypeExchanger
{
virtual AbstractType::Ptr exchange(const AbstractType::Ptr type)
{
TypeAliasType::Ptr alias = type.castTypeAliasType();
AbstractType::Ptr shortenedTarget = exchange(alias-type());
}
};
ShortenAliasExchanger exchanger;
type = exchanger.exchange(type);
}
probably related to both PR46535 and PR46523 (all from the same original
testcase)
[Bug tree-optimization/46557] [4.6 Regression] ICE in cgraph_will_be_removed_from_program_if_no_direct_calls, at cgraph.c:2820
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46557 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug lto/45789] [4.6 Regression] ICE: tree code 'lang_type' is not supported in gimple streams with -flto when using __builtin_printf()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45789 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.11.19 10:32:23 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.6.0 Ever Confirmed|0 |1 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-19 10:32:23 UTC --- In TYPE_ATTRIBUTES we have identifier_node 0x77ef97e8 format type lang_type 0x75d47150 global type VOID align 1 symtab 0 alias set -1 canonical type 0x75d47150 bindings 0x75d42910 local bindings (nil) an identifier with a type - we clean that in free-lang-data but probably fail to walk TYPE_ATTRIBUTES. Mine.
[Bug c++/46552] [4.6 Regression] [C++0x] Internal compiler error on pointer to member variable with template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46552 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.11.19 10:50:45 Target Milestone|--- |4.6.0 Summary|Internal compiler error on |[4.6 Regression] [C++0x] |pointer to member variable |Internal compiler error on |with template |pointer to member variable ||with template Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-19 10:50:45 UTC --- Confirmed. Works without -std=c++0x and with 4.5.
[Bug middle-end/46554] Less inlining leads to CSiBE regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46554 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.11.19 10:52:53 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-19 10:52:53 UTC --- I thought partial inlining would maybe fix this? Otherwise it's really a case that needs IP analysis.
[Bug middle-end/46555] PHI RTL expansion leads to CSiBE regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46555 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.11.19 10:55:11 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-19 10:55:11 UTC --- Yep. That's one optimization that was removed (out-of-SSA did that) and we thought of doing this reverse mergephi optimization as a separate pass before expansion.
Re: [Bug middle-end/46554] Less inlining leads to CSiBE regression
I thought partial inlining would maybe fix this? Otherwise it's really a case that needs IP analysis. Not with -Os, we really know that it will optimize away. Honza
[Bug middle-end/46554] Less inlining leads to CSiBE regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46554 --- Comment #2 from Jan Hubicka hubicka at ucw dot cz 2010-11-19 10:57:57 UTC --- I thought partial inlining would maybe fix this? Otherwise it's really a case that needs IP analysis. Not with -Os, we really know that it will optimize away. Honza
[Bug libstdc++/46544] std::map::at() defined even if __GXX_EXPERIMENTAL_CXX0X__ is not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46544 --- Comment #2 from Sebastian Mach phresnel at gmail dot com 2010-11-19 11:13:49 UTC --- (In reply to comment #1) Thanks for clarifiying. As you can clearly see It wasn't that clear to me. As a user of g++ and C++, and as a programmer, I am not into every DR, as I am already laden with getting codework done, and looking into the standards can already be hard enough if you relate it to release-pressure. Additionally grokking every single DR on top of that is not always managable.
[Bug libstdc++/46544] std::map::at() defined even if __GXX_EXPERIMENTAL_CXX0X__ is not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46544 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2010-11-19 11:20:17 UTC --- I understand ;) As a general rule, if you see in the code mentioned a DR XXX. YYY, with _GLIBCXX_RESOLVE_LIB_DEFECTS before, it means we are implementing a change beyond the letter of C++98/03, per the resolution of a successive ISO DR. For some time, many years ago, that _GLIBCXX_RESOLVE_LIB_DEFECTS was an actual macro and we tried to deliver both a vanilla C++98 and an amended version, depending on that macro, but it became quickly unmanageable, for various reasons (what to do with exported symbols, ODR, etc). Besides, according to the ISO rules, resolved DRs *are* part of the Standard in law, even if a completely new document does not exist yet.
[Bug lto/45789] [4.6 Regression] ICE: tree code 'lang_type' is not supported in gimple streams with -flto when using __builtin_printf()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45789 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-19 11:57:26 UTC --- Author: rguenth Date: Fri Nov 19 11:57:21 2010 New Revision: 166936 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166936 Log: 2010-11-19 Richard Guenther rguent...@suse.de PR lto/45789 * lto-streamer-out.c (lto_output_ts_common_tree_pointers): For IDENTIFIERs do not stream TREE_TYPE. * lto-streamer-in.c (lto_input_ts_common_tree_pointers): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/lto-streamer-in.c trunk/gcc/lto-streamer-out.c
[Bug lto/45789] [4.6 Regression] ICE: tree code 'lang_type' is not supported in gimple streams with -flto when using __builtin_printf()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45789 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-19 11:57:40 UTC --- Fixed.
[Bug debug/46558] New: dbgcnt.c messages not marked for translation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46558 Summary: dbgcnt.c messages not marked for translation Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: js...@gcc.gnu.org Blocks: 40883 dbgcnt.c contains code printf ( %-30s %-5s %-5s\n, counter name, limit, value); with untranslated English phrases counter name, limit, value. These should be marked for translation. As the width of column names in this table may need to vary depending on the length of the translations, the code should probably do something involving gcc_gettext_width to compute widths (that's better than marking the format strings for translation and having translators adjust widths manually).
[Bug middle-end/46559] New: libstdc++ link FAILs with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46559 Summary: libstdc++ link FAILs with -flto Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: lto Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: rgue...@gcc.gnu.org make -k check-target-libstdc++-v3 RUNTESTFLAGS=--target_board=unix/-flto yields FAIL: 27_io/basic_filebuf/close/12790-1.cc (test for excess errors) WARNING: 27_io/basic_filebuf/close/12790-1.cc compilation failed to produce exec utable FAIL: 27_io/basic_filebuf/cons/2020.cc (test for excess errors) WARNING: 27_io/basic_filebuf/cons/2020.cc compilation failed to produce executab le FAIL: 27_io/basic_filebuf/open/12790-1.cc (test for excess errors) WARNING: 27_io/basic_filebuf/open/12790-1.cc compilation failed to produce execu table FAIL: 27_io/basic_filebuf/seekoff/10132-2.cc (test for excess errors) WARNING: 27_io/basic_filebuf/seekoff/10132-2.cc compilation failed to produce ex ecutable FAIL: 27_io/basic_filebuf/seekoff/12790-1.cc (test for excess errors) WARNING: 27_io/basic_filebuf/seekoff/12790-1.cc compilation failed to produce ex ecutable FAIL: 27_io/basic_filebuf/seekoff/12790-2.cc (test for excess errors) WARNING: 27_io/basic_filebuf/seekoff/12790-2.cc compilation failed to produce ex ecutable FAIL: 27_io/basic_filebuf/seekoff/12790-3.cc (test for excess errors) WARNING: 27_io/basic_filebuf/seekpos/10132-3.cc compilation failed to produce ex ecutable FAIL: 27_io/basic_filebuf/seekpos/12790-2.cc (test for excess errors) WARNING: 27_io/basic_filebuf/seekpos/12790-2.cc compilation failed to produce ex ecutable FAIL: 27_io/basic_fstream/cons/1.cc (test for excess errors) WARNING: 27_io/basic_fstream/cons/1.cc compilation failed to produce executable FAIL: 27_io/basic_ifstream/cons/2020.cc (test for excess errors) WARNING: 27_io/basic_ifstream/cons/2020.cc compilation failed to produce executa ble FAIL: 27_io/basic_ofstream/cons/2020.cc (test for excess errors) WARNING: 27_io/basic_ofstream/cons/2020.cc compilation failed to produce executa ble FAIL: ext/enc_filebuf/char/13189.cc (test for excess errors) WARNING: ext/enc_filebuf/char/13189.cc compilation failed to produce executable FAIL: ext/enc_filebuf/char/13598.cc (test for excess errors) WARNING: ext/enc_filebuf/char/13598.cc compilation failed to produce executable FAIL: ext/enc_filebuf/wchar_t/13189.cc (test for excess errors) WARNING: ext/enc_filebuf/wchar_t/13189.cc compilation failed to produce executab le all with excess errors of the form FAIL: 27_io/basic_filebuf/seekoff/12790-1.cc (test for excess errors) Excess errors: /tmp/ccXujZVx.ltrans0.ltrans.o:(.debug_info+0x1153): undefined reference to `.LLST0' /tmp/ccXujZVx.ltrans0.ltrans.o:(.debug_info+0x1169): undefined reference to `.LLST1' /tmp/ccXujZVx.ltrans0.ltrans.o:(.debug_info+0x126b): undefined reference to `.LLST2' /tmp/ccXujZVx.ltrans0.ltrans.o:(.debug_info+0x127c): undefined reference to `.LLST3' /tmp/ccXujZVx.ltrans0.ltrans.o:(.debug_info+0x129d): undefined reference to `.LLST4' ...
[Bug c/46547] [4.5/4.6 Regression] internal compiler error when converting a complex to a bool
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46547 --- Comment #6 from joseph at codesourcery dot com joseph at codesourcery dot com 2010-11-19 13:01:35 UTC --- My inclination is that the problem is a missing check of in_late_binary_op. Specifically, that c_common_truthvalue_conversion should call save_expr instead of c_save_expr if in_late_binary_op (which in turn requires that in_late_binary_op move from c-tree.h/c-typeck.c to being defined/declared in c-family code).
[Bug tree-optimization/46560] New: libstdc++ execute FAILs with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46560 Summary: libstdc++ execute FAILs with -flto Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: lto, wrong-code Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: rgue...@gcc.gnu.org make -k check-target-libstdc++-v3 RUNTESTFLAGS=--target_board=unix/-flto yields Running target unix/-flto FAIL: 21_strings/basic_string/insert/char/1.cc execution test FAIL: 21_strings/basic_string/insert/wchar_t/1.cc execution test FAIL: 23_containers/deque/capacity/29134-2.cc execution test FAIL: 23_containers/deque/cons/2.cc execution test FAIL: 23_containers/forward_list/requirements/exception/basic.cc execution test FAIL: 23_containers/list/modifiers/3.cc execution test FAIL: 23_containers/list/modifiers/insert/25288.cc execution test FAIL: 23_containers/list/operations/5.cc execution test FAIL: 23_containers/list/requirements/exception/basic.cc execution test FAIL: 23_containers/multimap/requirements/exception/basic.cc execution test FAIL: 23_containers/multiset/requirements/exception/basic.cc execution test FAIL: 23_containers/unordered_map/dr761.cc execution test FAIL: 23_containers/unordered_map/requirements/exception/basic.cc execution test FAIL: 23_containers/unordered_multimap/requirements/exception/basic.cc execution test FAIL: 23_containers/unordered_multiset/requirements/exception/basic.cc execution test FAIL: 23_containers/unordered_set/requirements/exception/basic.cc execution test FAIL: 23_containers/vector/bool/modifiers/insert/31370.cc execution test FAIL: 23_containers/vector/capacity/2.cc execution test FAIL: 23_containers/vector/ext_pointer/modifiers/insert.cc execution test FAIL: 30_threads/promise/members/set_exception2.cc execution test FAIL: 30_threads/promise/members/set_value2.cc execution test FAIL: ext/bitmap_allocator/check_allocate_max_size.cc execution test FAIL: ext/pb_ds/regression/hash_data_map_rand.cc execution test FAIL: ext/pb_ds/regression/hash_no_data_map_rand.cc execution test FAIL: ext/pb_ds/regression/list_update_data_map_rand.cc execution test FAIL: ext/pb_ds/regression/list_update_no_data_map_rand.cc execution test FAIL: ext/pb_ds/regression/priority_queue_rand.cc execution test FAIL: ext/pb_ds/regression/tree_data_map_rand.cc execution test FAIL: ext/pb_ds/regression/tree_no_data_map_rand.cc execution test FAIL: ext/pb_ds/regression/trie_data_map_rand.cc execution test FAIL: ext/pb_ds/regression/trie_no_data_map_rand.cc execution test FAIL: ext/throw_allocator/check_deallocate_null.cc execution test
[Bug tree-optimization/46561] New: [4.6 Regression] -fcompare-debug failure (length) with -O2 -ftree-vectorize -ftree-parallelize-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46561 Summary: [4.6 Regression] -fcompare-debug failure (length) with -O2 -ftree-vectorize -ftree-parallelize-loops Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: zso...@seznam.cz CC: aol...@gcc.gnu.org Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 22456 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22456 reduced testcase Compiler output: $ gcc -O2 -ftree-vectorize -ftree-parallelize-loops=2 -fcompare-debug pr46561.c gcc: error: pr46561.c: -fcompare-debug failure (length) The dumps are very different, it seems the loop is not parallelized in the -g case. Tested revisions: r166899 - fail r163636 - fail r161659 - OK 4.5 r166509 - OK
[Bug libstdc++/46544] std::map::at() defined even if __GXX_EXPERIMENTAL_CXX0X__ is not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46544 --- Comment #4 from Sebastian Mach phresnel at gmail dot com 2010-11-19 13:12:10 UTC --- (In reply to comment #3) As a general rule, if you see in the code mentioned a DR XXX. YYY, with _GLIBCXX_RESOLVE_LIB_DEFECTS before, it means we are implementing a change beyond the letter of C++98/03, per the resolution of a successive ISO DR. Allright. I never stumbled over DR code, and that's prolly the reason why I did not recognize it (or possibly I thought that DRs are to be under -std=c++0x). Carved into synapses for the future. For some time, many years ago, that _GLIBCXX_RESOLVE_LIB_DEFECTS was an actual macro and we tried to deliver both a vanilla C++98 and an amended version, depending on that macro, but it became quickly unmanageable, for various reasons (what to do with exported symbols, ODR, etc). I already wanted to ask about a switch and it's non-presence, but seeing the number of DRs I already guessed it would be unmaintanable. Besides, according to the ISO rules, resolved DRs *are* part of the Standard in law, even if a completely new document does not exist yet. That's both interesting and valuable knowledge, as I am nitpicky myself at times :D Thanks for sharing your time :)
[Bug debug/46558] dbgcnt.c messages not marked for translation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46558 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-19 13:16:04 UTC --- Hm. debug counters are for debugging only thus I don't think we need to translate strings there (much as we don't translate comments in GCC code or stuff we dump with -ftime-report or -fmem-report).
[Bug tree-optimization/46561] [4.6 Regression] -fcompare-debug failure (length) with -O2 -ftree-vectorize -ftree-parallelize-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46561 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.11.19 13:16:33 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-19 13:16:33 UTC --- tree-parloop.c is indeed a mess stmt matching-wise.
[Bug c/46547] [4.5/4.6 Regression] internal compiler error when converting a complex to a bool
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46547 --- Comment #7 from H.J. Lu hjl.tools at gmail dot com 2010-11-19 13:18:21 UTC --- It is caused by revision 46547: http://gcc.gnu.org/ml/gcc-cvs/2009-03/msg00761.html
[Bug c/46547] [4.5/4.6 Regression] internal compiler error when converting a complex to a bool
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46547 --- Comment #8 from H.J. Lu hjl.tools at gmail dot com 2010-11-19 13:18:55 UTC --- It is caused by revision 145254: http://gcc.gnu.org/ml/gcc-cvs/2009-03/msg00761.html
[Bug debug/46558] dbgcnt.c messages not marked for translation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46558 --- Comment #2 from joseph at codesourcery dot com joseph at codesourcery dot com 2010-11-19 13:22:23 UTC --- On Fri, 19 Nov 2010, rguenth at gcc dot gnu.org wrote: Hm. debug counters are for debugging only thus I don't think we need to translate strings there (much as we don't translate comments in GCC code or stuff we dump with -ftime-report or -fmem-report). This is help text from -fdbg-cnt-list which I think is much like --help. It's only the table headings I think should be translated, not the rest of the content.
[Bug testsuite/43925] Plugin tests unresolved on IRIX 6.5: libintl.h: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43925 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target|mips-sgi-irix6.5|mips-sgi-irix6.5, ||mips-sgi-irix5.3 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.11.19 13:40:20 Host|mips-sgi-irix6.5|mips-sgi-irix6.5, ||mips-sgi-irix5.3 AssignedTo|unassigned at gcc dot |ro at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 Build|mips-sgi-irix6.5|mips-sgi-irix6.5, ||mips-sgi-irix5.3 --- Comment #1 from Rainer Orth ro at gcc dot gnu.org 2010-11-19 13:40:20 UTC --- Mine.
[Bug middle-end/46510] [4.6 Regression] r166812 breaks bootstrap on x86_64-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46510 --- Comment #16 from Jack Howarth howarth at nitro dot med.uc.edu 2010-11-19 13:48:45 UTC --- I can confirm that removing the gcc_assert (!DECL_EXTERNAL (decl)) as suggested in comment 8 does eliminate the bootstrap failures without regressions on x86_64-apple-darwin10... http://gcc.gnu.org/ml/gcc-testresults/2010-11/msg01621.html
[Bug tree-optimization/46561] [4.6 Regression] -fcompare-debug failure (length) with -O2 -ftree-vectorize -ftree-parallelize-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46561 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||irar at il dot ibm.com Target Milestone|--- |4.6.0 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com 2010-11-19 14:59:05 UTC --- It is caused by revision 161797: http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00151.html
[Bug tree-optimization/46557] [4.6 Regression] ICE in cgraph_will_be_removed_from_program_if_no_direct_calls, at cgraph.c:2820
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46557 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.11.19 15:30:39 CC||jason at redhat dot com Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2010-11-19 15:30:39 UTC --- This is caused by revision 166167: http://gcc.gnu.org/ml/gcc-cvs/2010-11/msg00053.html
[Bug tree-optimization/46562] New: CCP currently needs iteration for a[i]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46562
Summary: CCP currently needs iteration for a[i]
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: rgue...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
static int a[4];
int foo(void)
{
int i = 1;
int *p = a[i];
return *p;
}
compiled with the C++ FE (to yield an ARRAY_REF) shows that CCP needs
to iterate to figure out that p is a constant (and thus fold the read
from a[1]).
[Bug tree-optimization/46562] CCP currently needs iteration for a[i]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46562 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.11.19 15:45:11 Ever Confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-19 15:45:11 UTC --- Mine.
[Bug bootstrap/46549] MinGW bootstrap failure regarding texi GFPL license
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46549 Ralf Wildenhues rwild at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||rwild at gcc dot gnu.org Resolution||DUPLICATE --- Comment #1 from Ralf Wildenhues rwild at gcc dot gnu.org 2010-11-19 15:50:33 UTC --- . *** This bug has been marked as a duplicate of bug 45888 ***
[Bug bootstrap/45888] tm.texi generation is not portable, rule is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888 Ralf Wildenhues rwild at gcc dot gnu.org changed: What|Removed |Added CC||anhvofrcaus at gmail dot ||com --- Comment #9 from Ralf Wildenhues rwild at gcc dot gnu.org 2010-11-19 15:50:33 UTC --- *** Bug 46549 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/46562] CCP currently needs iteration for a[i]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46562 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-19 15:57:32 UTC --- SCCVN also fails to recognize a[i_1] as constant. I'll add a get_addr_base_and_unit_offset variant with a callback to valueize SSA names. That should cover both.
[Bug driver/46563] New: link with -lgcc when creating a shared lib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46563
Summary: link with -lgcc when creating a shared lib
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: christophe.l...@st.com
Created attachment 22457
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22457
main prog C++ source
As discussed in http://gcc.gnu.org/ml/gcc-help/2010-11/msg00198.html, the G++
driver does not link with -lgcc when creating a shared lib.
This is a problem when the shared lib references some symbols which are only
present in libgcc.a (such as __sync_fetch_and_add and all __sync*). This is the
case for instance on ARM.
I have attached atomic.cxx (shared lib) and atomain.cxx (main prog) to be
compiled with:
$ arm-linux-g++ atomic.cxx -fPIC -shared -o libatomic.so
$ arm-linux-g++ atomain.cxx -o atomain -L. -latomic
.../ld: atomain: hidden symbol `__sync_fetch_and_add_4' in
/.../libgcc.a(linux-atomic.o) is referenced by DSO
As a fix I can suggest to patch gcc.c:init_gcc_specs() and to add static_name
next to shared_name when expanding the specs.
diff -up gcc.c gcc.c.patch
--- gcc.c 2010-02-25 17:20:51.83115 +0100
+++ gcc.c.patch 2010-11-19 17:02:37.141674000 +0100
@@ -1722,7 +1722,7 @@ init_gcc_specs (struct obstack *obstack,
static_name, --as-needed , shared_name, --no-as-needed
}
%{shared-libgcc:,
- shared_name, %{!shared: , static_name, }
+ shared_name, , static_name, %{!shared: , static_name, }
}
#else
%{!shared:
@@ -1731,11 +1731,11 @@ init_gcc_specs (struct obstack *obstack,
}
#ifdef LINK_EH_SPEC
%{shared:
- %{shared-libgcc:, shared_name, }
+ %{shared-libgcc:, shared_name, , static_name}
%{!shared-libgcc:, static_name, }
}
#else
- %{shared:, shared_name, }
+ %{shared:, shared_name, , static_name}
#endif
#endif
}}, NULL);
[Bug driver/46563] link with -lgcc when creating a shared lib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46563 --- Comment #1 from christophe.lyon at st dot com 2010-11-19 16:05:16 UTC --- Created attachment 22458 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22458 shared lib C++ source
[Bug driver/46563] link with -lgcc when creating a shared lib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46563 --- Comment #2 from Andrew Haley aph at gcc dot gnu.org 2010-11-19 16:09:00 UTC --- If you try linking with -lgcc_s -lgcc, does everything then work?
[Bug c++/46564] New: [4.6 Regression] ICE: in decl_constant_var_p, at cp/decl2.c:3562 on invalid recursive initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46564
Summary: [4.6 Regression] ICE: in decl_constant_var_p, at
cp/decl2.c:3562 on invalid recursive initialization
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
--- testcase.C
template int N struct X {
static const int value = XN::value;
};
template struct X1000;
---
Compiler output:
$ gcc testcase.C
testcase.C:2:34: error: template instantiation depth exceeds maximum of 1024
(use -ftemplate-depth= to increase the maximum) instantiating 'X1000::value'
testcase.C:2:34: recursively instantiated from 'const int X1000::value'
testcase.C:2:34: instantiated from 'const int X1000::value'
testcase.C:4:17: instantiated from here
testcase.C:2:34: error: template instantiation depth exceeds maximum of 1024
(use -ftemplate-depth= to increase the maximum) instantiating 'X1000::value'
testcase.C:2:34: recursively instantiated from 'const int X1000::value'
testcase.C:2:34: instantiated from 'const int X1000::value'
testcase.C:4:17: instantiated from here
testcase.C:2:34: internal compiler error: in decl_constant_var_p, at
cp/decl2.c:3562
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
Tested revisions:
r166936 - crash
r165699 - OK
4.5 r166509 - OK
[Bug driver/46563] link with -lgcc when creating a shared lib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46563 --- Comment #3 from christophe.lyon at st dot com 2010-11-19 16:12:11 UTC --- Yes. I did find this workaround myself, but I was very surprised I had to do it manually. (As I said, the problem arised when building QT, and I guess I'm not the first one to build QT for ARM, so probably every other person have applied that workaround in the QT sources without contributing back ;-)
[Bug tree-optimization/45830] [4.4/4.5/4.6 Regression] Code+rodata increase with -ftree-switch-conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45830 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-19 16:17:06 UTC --- Created attachment 22459 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22459 gcc46-pr45830.patch Untested fix that should cure both reported issues, i.e. don't optimize and let switch being expanded as bit test if beneficial, and use smaller integral types when possible for the CSWTCH arrays.
[Bug c++/46565] New: [4.5/4.6 Regression] ICE: SIGSEGV in pop_tinst_level (pt.c:7513) with -gstabs -g on invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46565
Summary: [4.5/4.6 Regression] ICE: SIGSEGV in pop_tinst_level
(pt.c:7513) with -gstabs -g on invalid code
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zso...@seznam.cz
--- testcase.C
template int N struct X {
static const int value = X N - 1 ::value;
};
template struct X 1000;
---
(g++.dg/template/recurse2.C)
Compiler output:
$ gcc -gstabs -g testcase.C
testcase.C:1:27: error: template instantiation depth exceeds maximum of 1024
(use -ftemplate-depth= to increase the maximum) instantiating
'X-0x00017::value'
testcase.C:2:41: recursively instantiated from 'const int X999::value'
testcase.C:2:41: instantiated from 'const int X1000::value'
testcase.C:4:17: instantiated from here
testcase.C:2:41: error: template instantiation depth exceeds maximum of 1024
(use -ftemplate-depth= to increase the maximum) instantiating 'struct
X-0x00019'
testcase.C:2:41: recursively instantiated from 'const int X999::value'
testcase.C:2:41: instantiated from 'const int X1000::value'
testcase.C:4:17: instantiated from here
testcase.C:2:41: error: incomplete type 'X-0x00019' used in
nested name specifier
==3448== Invalid read of size 4
==3448==at 0x518875: pop_tinst_level (pt.c:7513)
==3448==by 0x54EAF2: instantiate_decl (pt.c:17402)
==3448==by 0x550681: do_type_instantiation (pt.c:16682)
==3448==by 0x5BAB68: cp_parser_explicit_instantiation (parser.c:12269)
==3448==by 0x5BDD89: cp_parser_declaration (parser.c:9415)
==3448==by 0x5BC569: cp_parser_declaration_seq_opt (parser.c:9328)
==3448==by 0x5BE234: c_parse_file (parser.c:3445)
==3448==by 0x6922F4: c_common_parse_file (c-opts.c:1070)
==3448==by 0x9F7423: toplev_main (toplev.c:870)
==3448==by 0x6376BBC: (below main) (in /lib64/libc-2.11.2.so)
==3448== Address 0x10 is not stack'd, malloc'd or (recently) free'd
==3448==
testcase.C:4:17: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
Tested revisions:
r166936 - crash
4.5 r166509 - crash
4.4 r166509 - OK
[Bug c++/46565] [4.5/4.6 Regression] ICE: SIGSEGV in pop_tinst_level (pt.c:7513) with -gstabs -g on invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46565 Zdenek Sojka zsojka at seznam dot cz changed: What|Removed |Added Keywords||ice-on-invalid-code Known to work||4.4.6 Known to fail||4.5.2, 4.6.0 Severity|normal |minor
[Bug driver/46563] link with -lgcc when creating a shared lib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46563 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #4 from Mikael Pettersson mikpe at it dot uu.se 2010-11-19 16:45:51 UTC --- (In reply to comment #0) Created attachment 22457 [details] main prog C++ source As discussed in http://gcc.gnu.org/ml/gcc-help/2010-11/msg00198.html, the G++ driver does not link with -lgcc when creating a shared lib. The example in the link above works for me with my native arm-linux-gnueabi toolchain. Did you forget to install the libgcc_s.so linker script? The very purpose of that script is to make -lgcc_s suck in both the dynamic and the static libgcc, since (as you've noticed) some symbols are only defined in the static libgcc.
[Bug driver/46563] link with -lgcc when creating a shared lib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46563 --- Comment #5 from christophe.lyon at st dot com 2010-11-19 16:49:05 UTC --- I am not sure what you mean about libgcc_s.so linker script. But I think the difference is that I am cross-compiling.
[Bug c/46547] [4.5/4.6 Regression] internal compiler error when converting a complex to a bool
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46547 Joseph S. Myers jsm28 at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jsm28 at gcc dot gnu.org |gnu.org | --- Comment #9 from Joseph S. Myers jsm28 at gcc dot gnu.org 2010-11-19 17:20:15 UTC --- Testing a patch.
[Bug driver/46563] link with -lgcc when creating a shared lib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46563 --- Comment #6 from Andrew Haley aph at gcc dot gnu.org 2010-11-19 17:30:35 UTC --- I am cross-compiling too. Try this: $ cat /home/aph/x-arm/install/arm-linux-gnueabi/lib/libgcc_s.so /* GNU ld script Use the shared library, but some functions are only in the static library. */ GROUP ( libgcc_s.so.1 libgcc.a )
[Bug driver/46563] link with -lgcc when creating a shared lib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46563 --- Comment #7 from Mikael Pettersson mikpe at it dot uu.se 2010-11-19 17:38:35 UTC --- The example works for me also with a cross built from gcc-4.5.1 with --enable-shared --enable-languages=c,c++. armv5tel-unknown-linux-gnueabi-g++ atomic.cxx -fPIC -shared -o libatomic.so armv5tel-unknown-linux-gnueabi-g++ atomain.cxx -o atomain -L. -latomic 'make install' automatically installed the linker script in $PREFIX/armv5tel-unknown-linux-gnueabi/lib/libgcc_s.so I don't see -gnueabi in your compile command. Is it an OABI toolchain?
[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46339 --- Comment #19 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2010-11-19 17:42:12 UTC --- Another test case to think about. Ifort compiles but gives: ptr = myA%i%j = 1 2 3 4 gfortran compiles and gives: $ ./a.out Segmentation fault (core dumped) $ gfc -fbounds-check test3.f90 $ ./a.out At line 19 of file test3.f90 Fortran runtime error: Array bound mismatch for dimension 1 of array 'ptr' (140251380424698/4) Is there something invalid here? module test implicit none type b integer :: j character :: c end type b type a type(b), dimension(4) :: i end type a end module test program main use test implicit none type(a), target :: myA integer, dimension(:), pointer :: ptr myA%i(1:4)%j = (/ 1, 2, 3, 4 /) myA%i(1:4)%c = (/ 'a', 'b', 'c', 'd' /) ptr = myA%i%j print *,ptr =, ptr print *,myA%i%j =, myA%i%j end program main
[Bug c++/46270] [trans-mem] internal compiler error: verify_stmts failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46270 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #1 from Aldy Hernandez aldyh at gcc dot gnu.org 2010-11-19 18:02:29 UTC --- Fixed http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02025.html
[Bug other/46026] [trans-mem] Unable to build libitm on Solaris/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46026 --- Comment #2 from Aldy Hernandez aldyh at gcc dot gnu.org 2010-11-19 18:06:01 UTC --- BTW, a workaround while Alex gets his patch committed is to run make again on the partially built tree. The second time around, the build will succeed.
[Bug other/46567] New: ipa_tm_decrement_clone_counts ICE at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46567 Summary: ipa_tm_decrement_clone_counts ICE at -O2 Product: gcc Version: trans-mem Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: al...@gcc.gnu.org $ ./cc1plus c.cc -O -fgnu-tm -fdump-tree-all -fdump-ipa-all -quiet -O2 c.cc: In function 'void* buildProjectSyncStepConcurrently(int, int)': c.cc:2674:1: internal compiler error: in ipa_tm_decrement_clone_counts, at trans-mem.c:3687 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions.
[Bug other/46567] ipa_tm_decrement_clone_counts ICE at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46567 --- Comment #1 from Aldy Hernandez aldyh at gcc dot gnu.org 2010-11-19 18:11:23 UTC --- Created attachment 22460 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22460 boom
[Bug other/46567] ipa_tm_decrement_clone_counts ICE at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46567 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Keywords||trans-mem Status|UNCONFIRMED |NEW Last reconfirmed||2010.11.19 18:11:58 Ever Confirmed|0 |1
[Bug other/46566] New: ipa_tm_decrement_clone_counts ICE at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46566 Summary: ipa_tm_decrement_clone_counts ICE at -O2 Product: gcc Version: trans-mem Status: RESOLVED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: al...@gcc.gnu.org Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE $ ./cc1plus c.cc -O -fgnu-tm -fdump-tree-all -fdump-ipa-all -quiet -O2 c.cc: In function 'void* buildProjectSyncStepConcurrently(int, int)': c.cc:2674:1: internal compiler error: in ipa_tm_decrement_clone_counts, at trans-mem.c:3687 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. --- Comment #1 from Aldy Hernandez aldyh at gcc dot gnu.org 2010-11-19 18:14:07 UTC --- whoops, hit send twice *** This bug has been marked as a duplicate of bug 46567 ***
[Bug other/46567] ipa_tm_decrement_clone_counts ICE at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46567 --- Comment #2 from Aldy Hernandez aldyh at gcc dot gnu.org 2010-11-19 18:14:07 UTC --- *** Bug 46566 has been marked as a duplicate of this bug. ***
[Bug c++/45940] [trans-mem] Error of unsafe function even if annotated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45940 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.11.19 18:17:31 AssignedTo|unassigned at gcc dot |aldyh at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Aldy Hernandez aldyh at gcc dot gnu.org 2010-11-19 18:17:31 UTC --- Mine
[Bug c/46547] [4.5/4.6 Regression] internal compiler error when converting a complex to a bool
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46547 --- Comment #10 from Joseph S. Myers jsm28 at gcc dot gnu.org 2010-11-19 18:33:02 UTC --- Author: jsm28 Date: Fri Nov 19 18:32:57 2010 New Revision: 166951 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166951 Log: PR c/46547 * c-tree.h (in_late_binary_op): Move to c-family/c-common.h. * c-typeck.c (in_late_binary_op): Move to c-family/c-common.c. c-family: * c-common.c (in_late_binary_op): Define. (c_common_truthvalue_conversion): Check in_late_binary_op before calling c_save_expr. * c-common.h (in_late_binary_op): Declare. testsuite: * gcc.c-torture/compile/pr46547-1.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr46547-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/c-family/c-common.h trunk/gcc/c-tree.h trunk/gcc/c-typeck.c trunk/gcc/testsuite/ChangeLog
[Bug target/46436] m68hc11-elf --enable-werror-always build fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46436 --- Comment #2 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org 2010-11-19 18:40:31 UTC --- Author: amylaar Date: Fri Nov 19 18:40:24 2010 New Revision: 166952 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166952 Log: PR target/46436 * config/m68hc11/m68hc11.c (m68hc11_gen_highpart): Split shift count to accomodate 32 bit HOST_WIDE_INT. (m68hc11_emit_logical): Remove unused variable insn. (m68hc11_check_z_replacement) CLOBBER: Set this_insn_uses_ix and this_insn_uses_iy before use. Modified: trunk/gcc/ChangeLog trunk/gcc/config/m68hc11/m68hc11.c
[Bug target/46434] crx-elf --enable-werror-always build fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46434
--- Comment #2 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org
2010-11-19 19:22:31 UTC ---
Author: amylaar
Date: Fri Nov 19 19:22:27 2010
New Revision: 166954
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166954
Log:
PR target/46434
* config/crx/crx.c (crx_expand_epilogue): Remove unused variable.
Index: config/crx/crx.c
===
--- config/crx/crx.c(revision 166609)
+++ config/crx/crx.c(working copy)
@@ -613,6 +613,8 @@ static int crx_addr_reg_p (rtx addr_reg)
return FALSE;
}
+ gcc_assert (REGNO (reg) != CC_REGNUM);
+
return TRUE;
}
@@ -1439,17 +1441,12 @@ crx_expand_prologue (void)
void
crx_expand_epilogue (void)
{
- rtx return_reg;
-
/* Nonzero if we need to return and pop only RA. This will generate a
* different insn. This differentiate is for the peepholes for call as last
* statement in function. */
int only_popret_RA = (save_regs[RETURN_ADDRESS_REGNUM]
(sum_regs == UNITS_PER_WORD));
- /* Return register. */
- return_reg = gen_rtx_REG (Pmode, RETURN_ADDRESS_REGNUM);
-
if (frame_pointer_needed)
/* Restore the stack pointer with the frame pointers value */
emit_move_insn (stack_pointer_rtx, frame_pointer_rtx);
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/crx/crx.c
[Bug target/46436] m68hc11-elf --enable-werror-always build fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46436 Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org 2010-11-19 19:26:11 UTC --- Patch has been applied to trunk.
[Bug c++/46564] [4.6 Regression] ICE: in decl_constant_var_p, at cp/decl2.c:3562 on invalid recursive initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46564 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Keywords||error-recovery Priority|P3 |P4 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.6.0
[Bug c++/46565] [4.5/4.6 Regression] ICE: SIGSEGV in pop_tinst_level (pt.c:7513) with -gstabs -g on invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46565 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Keywords||error-recovery Priority|P3 |P4 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.5.2
[Bug tree-optimization/46561] [4.6 Regression] -fcompare-debug failure (length) with -O2 -ftree-vectorize -ftree-parallelize-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46561 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jakub at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-19 20:04:14 UTC --- Mine.
[Bug debug/46561] [4.6 Regression] -fcompare-debug failure (length) with -O2 -ftree-vectorize -ftree-parallelize-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46561 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-19 20:19:44 UTC --- Created attachment 22461 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22461 gcc46-pr46561.patch Untested fix.
[Bug c++/46568] New: special symbol a caret shows up for errors and warnings when running g++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46568 Summary: special symbol a caret shows up for errors and warnings when running g++ Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: jared.ru...@saic.com Created attachment 22462 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22462 look at the highlighted section If my c++ code has any errors or warnings, the special symbol a caret shows up instead of the function name or symbol that is the problem. I built gcc 4.4.3 on RedHat linux 5.5 instead of using the default gcc compiler that comes with the o/s thanks
[Bug c/46547] [4.5 Regression] internal compiler error when converting a complex to a bool
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46547 --- Comment #11 from Joseph S. Myers jsm28 at gcc dot gnu.org 2010-11-19 20:45:07 UTC --- Author: jsm28 Date: Fri Nov 19 20:45:00 2010 New Revision: 166957 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166957 Log: PR c/46547 * c-common.c (in_late_binary_op): Define. (c_common_truthvalue_conversion): Check in_late_binary_op before calling c_save_expr. * c-common.h (in_late_binary_op): Declare. * c-tree.h (in_late_binary_op): Move to c-common.h. * c-typeck.c (in_late_binary_op): Move to c-common.c. testsuite: * gcc.c-torture/compile/pr46547-1.c: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.c-torture/compile/pr46547-1.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/c-common.c branches/gcc-4_5-branch/gcc/c-common.h branches/gcc-4_5-branch/gcc/c-tree.h branches/gcc-4_5-branch/gcc/c-typeck.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46339 --- Comment #20 from david.sagan at gmail dot com 2010-11-19 20:46:36 UTC --- (In reply to comment #19) Is there something invalid here? ptr = myA%i%j Yes this is not correct. This line should be: ptr = myA%i%j If you use gfortran -fcheck=all test.f90 then what you get when you run the program is: At line 19 of file test.f90 Fortran runtime error: Array bound mismatch for dimension 1 of array 'ptr' (140736642904848/4)
[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46339 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #21 from kargl at gcc dot gnu.org 2010-11-19 20:49:31 UTC --- (In reply to comment #19) Is there something invalid here? Yes. You need to allocate ptr unless you have pault's [re-]allocate on assignment patch. module test implicit none type b integer :: j character :: c end type b type a type(b), dimension(4) :: i end type a end module test program main use test implicit none type(a), target :: myA integer, dimension(:), pointer :: ptr myA%i(1:4)%j = (/ 1, 2, 3, 4 /) myA%i(1:4)%c = (/ 'a', 'b', 'c', 'd' /) allocate(ptr(size(myA%i))) ptr = myA%i%j print *,ptr =, ptr print *,myA%i%j =, myA%i%j end program main
[Bug c/46547] [4.5 Regression] internal compiler error when converting a complex to a bool
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46547 Joseph S. Myers jsm28 at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.5.2 Resolution||FIXED --- Comment #12 from Joseph S. Myers jsm28 at gcc dot gnu.org 2010-11-19 20:54:28 UTC --- Fixed for 4.5.2 and 4.6.
[Bug tree-optimization/46077] [4.6 regression] ICE in tree vectorization when compiling towns_audio.cpp from scummvm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46077 --- Comment #6 from Michael Matz matz at gcc dot gnu.org 2010-11-19 20:56:33 UTC --- Author: matz Date: Fri Nov 19 20:56:27 2010 New Revision: 166958 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166958 Log: PR tree-optimization/46077 * tree-chrec.c (eq_evolutions_p): Accept some expressions. testsuite/ PR tree-optimization/46077 * gcc.dg/vect/O3-pr46077.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/vect/O3-pr46077.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-chrec.c
[Bug c/46547] [4.5 Regression] internal compiler error when converting a complex to a bool
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46547 --- Comment #13 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-11-19 21:01:04 UTC --- Revision 166951 breaks bootstrap with obj-c++ enabled: ld: duplicate symbol _in_late_binary_op in c-family/c-common.o and objcp/objcp-act.o
[Bug tree-optimization/46077] [4.6 regression] ICE in tree vectorization when compiling towns_audio.cpp from scummvm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46077 Michael Matz matz at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||matz at gcc dot gnu.org Resolution||FIXED --- Comment #7 from Michael Matz matz at gcc dot gnu.org 2010-11-19 21:03:34 UTC --- Fixed.
[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46339 --- Comment #22 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-11-19 21:04:22 UTC --- Is there something invalid here? Yes. You need to allocate ptr unless you have pault's [re-]allocate on assignment patch. Even with Paul's patch it does not work.
[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46339 --- Comment #23 from david.sagan at gmail dot com 2010-11-19 21:24:01 UTC --- (In reply to comment #22) Is there something invalid here? Yes. You need to allocate ptr unless you have pault's [re-]allocate on assignment patch. Even with Paul's patch it does not work. It works for me. The following two variants give the correct result (and this is without any patching): program main use test implicit none type(a), target :: myA integer, dimension(:), pointer :: ptr myA%i(1:4)%j = (/ 1, 2, 3, 4 /) myA%i(1:4)%c = (/ 'a', 'b', 'c', 'd' /) allocate (ptr(4)) ptr = myA%i%j print *,ptr =, ptr print *,myA%i%j =, myA%i%j end program main program main use test implicit none type(a), target :: myA integer, dimension(:), pointer :: ptr myA%i(1:4)%j = (/ 1, 2, 3, 4 /) myA%i(1:4)%c = (/ 'a', 'b', 'c', 'd' /) ptr = myA%i%j print *,ptr =, ptr print *,myA%i%j =, myA%i%j end program main Both give: ptr = 1 2 3 4 myA%i%j = 1 2 3 4
[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46339 --- Comment #24 from Steve Kargl sgk at troutmask dot apl.washington.edu 2010-11-19 21:32:38 UTC --- On Fri, Nov 19, 2010 at 09:04:42PM +, dominiq at lps dot ens.fr wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46339 --- Comment #22 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-11-19 21:04:22 UTC --- Is there something invalid here? Yes. You need to allocate ptr unless you have pault's [re-]allocate on assignment patch. Even with Paul's patch it does not work. Well, in theory, I believe it should work with Paul's patch. Of course, theory and experience are two different beast. :)
[Bug c++/46568] special symbol a caret shows up for errors and warnings when running g++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46568 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2010-11-19 21:32:49 UTC --- This is a bug in how you have LANG and LC_* env variables set up. They currently say your terminal supports UTF-8 but obviously it does not. Just set LANG to C and that will fix your issue.
[Bug c++/46564] [4.6 Regression] ICE: in decl_constant_var_p, at cp/decl2.c:3562 on invalid recursive initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46564 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2010.11.19 21:36:45 CC||jason at redhat dot com Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2010-11-19 21:36:45 UTC --- It is caused by revision 166164: http://gcc.gnu.org/ml/gcc-cvs/2010-11/msg00050.html
[Bug fortran/46339] [4.3/4.4/4.5/4.6 Regression] ICE (segfault) in gfc_trans_pointer_assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46339 --- Comment #25 from Dominique d'Humieres dominiq at lps dot ens.fr 2010-11-19 21:46:56 UTC --- Well, in theory, I believe it should work with Paul's patch. Of course, theory and experience are two different beast. :) When Paul will have commit his final patch, it will be time to open a PR if the agreement is that this should work and if it does not;-)
[Bug rtl-optimization/46571] New: bootsrap comparison failure in fortran/trans-openmp.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46571 Summary: bootsrap comparison failure in fortran/trans-openmp.c Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org Stage2/3 differ on this file on ia64-linux. This is a real code generation difference observable with/without -g. Command line: ./xgcc -B./ -O2 -g z.i
[Bug rtl-optimization/46571] bootsrap comparison failure in fortran/trans-openmp.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46571 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.11.19 22:11:13 AssignedTo|unassigned at gcc dot |rth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Richard Henderson rth at gcc dot gnu.org 2010-11-19 22:11:13 UTC --- Created attachment 22463 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22463 Minimized test case
[Bug rtl-optimization/46571] bootsrap comparison failure in fortran/trans-openmp.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46571 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Target||ia64-linux Priority|P3 |P2 Target Milestone|--- |4.6.0 --- Comment #2 from Richard Henderson rth at gcc dot gnu.org 2010-11-19 22:15:40 UTC --- The first real code generation difference appears during the 173r.cprop3 pass, where the important difference is: -GLOBAL COPY-PROP: Replacing reg 424 in insn 90 with reg 427 the replacement does not happen with -g. Now to figure out why...
[Bug libstdc++/46572] New: forward_list nodes are not packed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46572 Summary: forward_list nodes are not packed Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: kyle.kloep...@riverbed.com I was playing around with forward_list and realized that all the list nodes took up a minimum of 16 bytes (with larger sizes in multiples of 8--I am using a 64-bit machine). This conflicts with what the standard notes in 23.3.3 paragraph 1: Note: It is intended that forward_list have zero space or time overhead relative to a hand-written C-style singly linked list. If I was implementing a memory space critical linked list I would decorate the list node struct with packed. This is not possible to do with the internal list node. I will upload an example program shortly.
[Bug libstdc++/46572] forward_list nodes are not packed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46572 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2010-11-19 22:25:32 UTC --- zero space or time overhead We have a zero time overhead here. packed would increase the time overhead here really.
[Bug libstdc++/46572] forward_list nodes are not packed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46572 --- Comment #2 from Kyle Kloepper kyle.kloepper at riverbed dot com 2010-11-19 22:47:47 UTC --- Created attachment 22464 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22464 Program to print out the size used by forward_list node allocation
[Bug libstdc++/46572] forward_list nodes are not packed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46572 --- Comment #3 from Kyle Kloepper kyle.kloepper at riverbed dot com 2010-11-19 23:01:07 UTC --- I would read the standard as in inclusive or. But even if you read it as one or the other, I do not think that in all cases speed would be prefered over space. Is there any way to implement something like this: std::forward_listint __attribute((packed)); Such that the packed attribute would propogate to the list nodes?
[Bug rtl-optimization/46571] [4.6 Regression] bootsrap comparison failure in fortran/trans-openmp.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46571 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||build Priority|P2 |P1 Summary|bootsrap comparison failure |[4.6 Regression] bootsrap |in fortran/trans-openmp.c |comparison failure in ||fortran/trans-openmp.c
[Bug c/46547] [4.5 Regression] internal compiler error when converting a complex to a bool
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46547 --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-19 23:44:51 UTC --- Author: jakub Date: Fri Nov 19 23:44:47 2010 New Revision: 166964 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166964 Log: PR c/46547 * objc-act.c (in_late_binary_op): Remove. Modified: trunk/gcc/objc/ChangeLog trunk/gcc/objc/objc-act.c
[Bug c/46547] [4.5 Regression] internal compiler error when converting a complex to a bool
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46547 --- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-19 23:47:01 UTC --- Author: jakub Date: Fri Nov 19 23:46:57 2010 New Revision: 166965 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166965 Log: PR c/46547 * objc-act.c (in_late_binary_op): Remove. Modified: branches/gcc-4_5-branch/gcc/objc/ChangeLog branches/gcc-4_5-branch/gcc/objc/objc-act.c
