[Bug fortran/27715] [4.1 only] Extented ASCII characters lead to wrong CASE selection
--- Comment #14 from fxcoudert at gcc dot gnu dot org 2006-06-13 06:26 --- Thomas, could you backport your patch to 4.1? (when you have some time, of course) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27715
[Bug libgcj/28009] New: libjava cannot be cross-built; X_CFLAGS includes /usr/include
libjava fails to cross-build because the Makefile includes an -I/usr/include. Removing that makes it work. I've seen this a number of times now, i386 to alpha-linux, i386 to m68-linux, etc. The problem is this in the Makefile: X_CFLAGS = -I/usr/include and X_CFLAGS is part of AM_CXXFLAGS which is where it causes the problem. I configured gcc with: /home/tbm/scratch/gcc/configure --disable-bootstrap \ --enable-languages=c,c++,java --target=alpha-linux-gnu -- Summary: libjava cannot be cross-built; X_CFLAGS includes /usr/include Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28009
[Bug libgcj/28009] libjava cannot be cross-built; X_CFLAGS includes /usr/include
--- Comment #1 from tbm at cyrius dot com 2006-06-13 07:13 --- Created an attachment (id=11658) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11658action=view) alpha-linux-gnu/libjava/config.log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28009
[Bug libgcj/28009] libjava cannot be cross-built; X_CFLAGS includes /usr/include
--- Comment #2 from tbm at cyrius dot com 2006-06-13 07:17 --- Created an attachment (id=11659) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11659action=view) command line causing problem Here's a sample command line showing the problem. Removing the -I/usr/include makes it work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28009
[Bug tree-optimization/27830] [4.1/4.2 regression] ICE: verify_stmts failed (invalid operand to unary operator)
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-06-13 07:22 --- Subject: Bug 27830 Author: rguenth Date: Tue Jun 13 07:22:04 2006 New Revision: 114600 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114600 Log: 2006-06-13 Richard Guenther [EMAIL PROTECTED] PR tree-optimization/27830 * tree-inline.c (copy_body_r): For copying the operand of an ADDR_EXPR make sure to fold * afterwards. * g++.dg/tree-ssa/pr27830.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr27830.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-inline.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27830
[Bug middle-end/27536] [4.2 Regression] -fsection-anchors breaks Ada
--- Comment #14 from rguenth at gcc dot gnu dot org 2006-06-13 07:24 --- Subject: Bug 27536 Author: rguenth Date: Tue Jun 13 07:23:59 2006 New Revision: 114601 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114601 Log: 2006-06-13 Richard Guenther [EMAIL PROTECTED] PR middle-end/27536 * except.c (output_ttype): Expand type with EXPAND_INITIALIZER. Modified: trunk/gcc/ChangeLog trunk/gcc/except.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27536
[Bug middle-end/27536] [4.2 Regression] -fsection-anchors breaks Ada
--- Comment #15 from rguenth at gcc dot gnu dot org 2006-06-13 07:24 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27536
[Bug target/28007] sse autovectorizer emits wrong code involving shifts
--- Comment #5 from uros at kss-loka dot si 2006-06-13 07:44 --- Similar problem was solved for gcc-4.1 in PR target/22480. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28007
[Bug target/27863] [4.2 Regression] ICE in check_cfg, at haifa-sched.c:4615
--- Comment #6 from mkuvyrkov at gcc dot gnu dot org 2006-06-13 08:51 --- Subject: Bug 27863 Author: mkuvyrkov Date: Tue Jun 13 08:50:53 2006 New Revision: 114604 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114604 Log: 2006-06-13 Maxim Kuvyrkov [EMAIL PROTECTED] * haifa-sched.c (unlink_other_notes, unlink_line_notes): Fix the patch for PR target/27863. 2006-06-13 Maxim Kuvyrkov [EMAIL PROTECTED] * gcc.c-torture/compile/20060609-1.c: New test. PR target/27863 * gcc.c-torture/compile/pr27863.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/20060609-1.c trunk/gcc/testsuite/gcc.c-torture/compile/pr27863.c Modified: trunk/gcc/ChangeLog trunk/gcc/haifa-sched.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27863
[Bug debug/26754] [4.0/4.1/4.2 Regression] Wrong debug info for variable accessed non-locally
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2006-06-13 08:55 --- Subject: Bug 26754 Author: ebotcazou Date: Tue Jun 13 08:55:40 2006 New Revision: 114605 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114605 Log: PR debug/26754 * gimplify.c (declare_tmp_vars): Rename into declare_vars. Add debug_info parameter. Chain the vars to the BLOCK instead of the BIND_EXPR if debug info are requested for them. (pop_gimplify_context): Adjust for above change. (gimple_add_tmp_var): Likewise. * tree-gimple.h (declare_tmp_vars): Rename into declare_vars. Add bool parameter. * tree-nested.c (convert_nonlocal_reference): Adjust for above change. (convert_local_reference): Likewise. (get_local_debug_decl): Set DECL_IGNORED_P on the original variable. (finalize_nesting_tree_1): Request that debug info be emitted for debug_var_chain. Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/tree-gimple.h trunk/gcc/tree-nested.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26754
[Bug debug/26754] [4.0/4.1 Regression] Wrong debug info for variable accessed non-locally
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2006-06-13 08:56 --- Fixed on mainline. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|[4.0/4.1/4.2 Regression]|[4.0/4.1 Regression] Wrong |Wrong debug info for|debug info for variable |variable accessed non- |accessed non-locally |locally | Target Milestone|4.0.4 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26754
[Bug middle-end/26807] [4.2 Regression] FAIL: gcc.dg/torture/pr24626-1.c -O2 (test for excess errors)
--- Comment #16 from mkuvyrkov at gcc dot gnu dot org 2006-06-13 09:01 --- Subject: Bug 26807 Author: mkuvyrkov Date: Tue Jun 13 09:00:52 2006 New Revision: 114606 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114606 Log: 2006-06-13 Maxim Kuvyrkov [EMAIL PROTECTED] PR middle-end/26807 * haifa-sched.c (check_cfg): Handle special case. Modified: trunk/gcc/ChangeLog trunk/gcc/haifa-sched.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26807
[Bug middle-end/26807] [4.2 Regression] FAIL: gcc.dg/torture/pr24626-1.c -O2 (test for excess errors)
--- Comment #17 from mkuvyrkov at gcc dot gnu dot org 2006-06-13 09:03 --- I tested this fix on a cross from i386-pc-linux-gnu and it did well on those three tests. Can, please, someone check if the regressions gone on hppa? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26807
[Bug middle-end/27793] [4.1 Regression] num_ssa_names inconsistent or immediate use iterator wrong
--- Comment #20 from jakub at gcc dot gnu dot org 2006-06-13 09:21 --- Subject: Bug 27793 Author: jakub Date: Tue Jun 13 09:21:30 2006 New Revision: 114607 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114607 Log: PR middle-end/27793 * cp-tree.h (cxx_int_tree_map): New struct. (struct language_function): Add extern_decl_map field. * name-lookup.c (pushdecl_maybe_friend): Add x - t mapping to cp_function_chain-extern_decl_map hash table instead of copying over DECL_UID. * cp-gimplify.c (cxx_int_tree_map_eq, cxx_int_tree_map_hash): New functions. (cp_genericize_r): Remap DECL_EXTERN local decls using cp_function_chain-extern_decl_map hash table. * decl.c (finish_function): Clear extern_decl_map. PR c++/26757 PR c++/27894 * g++.dg/tree-ssa/pr26757.C: New test. * g++.dg/tree-ssa/pr27894.C: New test. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr26757.C trunk/gcc/testsuite/g++.dg/tree-ssa/pr27894.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-gimplify.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/name-lookup.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27793
[Bug c++/26757] C++ front-end producing two DECLs with the same UID
--- Comment #28 from jakub at gcc dot gnu dot org 2006-06-13 09:21 --- Subject: Bug 26757 Author: jakub Date: Tue Jun 13 09:21:30 2006 New Revision: 114607 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114607 Log: PR middle-end/27793 * cp-tree.h (cxx_int_tree_map): New struct. (struct language_function): Add extern_decl_map field. * name-lookup.c (pushdecl_maybe_friend): Add x - t mapping to cp_function_chain-extern_decl_map hash table instead of copying over DECL_UID. * cp-gimplify.c (cxx_int_tree_map_eq, cxx_int_tree_map_hash): New functions. (cp_genericize_r): Remap DECL_EXTERN local decls using cp_function_chain-extern_decl_map hash table. * decl.c (finish_function): Clear extern_decl_map. PR c++/26757 PR c++/27894 * g++.dg/tree-ssa/pr26757.C: New test. * g++.dg/tree-ssa/pr27894.C: New test. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr26757.C trunk/gcc/testsuite/g++.dg/tree-ssa/pr27894.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-gimplify.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/name-lookup.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26757
[Bug c++/27894] [4.1/4.2 Regression] internal compiler error: Segmentation fault with -O
--- Comment #7 from jakub at gcc dot gnu dot org 2006-06-13 09:21 --- Subject: Bug 27894 Author: jakub Date: Tue Jun 13 09:21:30 2006 New Revision: 114607 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114607 Log: PR middle-end/27793 * cp-tree.h (cxx_int_tree_map): New struct. (struct language_function): Add extern_decl_map field. * name-lookup.c (pushdecl_maybe_friend): Add x - t mapping to cp_function_chain-extern_decl_map hash table instead of copying over DECL_UID. * cp-gimplify.c (cxx_int_tree_map_eq, cxx_int_tree_map_hash): New functions. (cp_genericize_r): Remap DECL_EXTERN local decls using cp_function_chain-extern_decl_map hash table. * decl.c (finish_function): Clear extern_decl_map. PR c++/26757 PR c++/27894 * g++.dg/tree-ssa/pr26757.C: New test. * g++.dg/tree-ssa/pr27894.C: New test. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr26757.C trunk/gcc/testsuite/g++.dg/tree-ssa/pr27894.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-gimplify.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/name-lookup.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27894
[Bug middle-end/28010] New: [4.1/4.2 regression] ICE because of fold_rtx endless recursion
typedef struct
{
unsigned int addr;
unsigned int next;
unsigned int prev;
} list;
static inline list *
shift (list * l, unsigned na)
{
return (list *) ((char *) l + na);
}
static inline int
is_valid (list * l)
{
return shift (l, l-prev)-next == (l-addr);
}
static inline int
not_empty (list * l)
{
return shift (l, l-next) != l;
}
void aaa (void);
void
func (list * l)
{
unsigned int a = l-addr;
while (1)
{
while (not_empty (l))
aaa ();
if (is_valid (l))
aaa ();
}
}
ICEs with -O1 -m32 and above. Might be related to PR27616, but without
debugging/fixing one of these that's hard to say.
--
Summary: [4.1/4.2 regression] ICE because of fold_rtx endless
recursion
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: i?86-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28010
[Bug target/28011] New: [SH] g++ generates wrong code, if '-fno-exceptions' and '-O' options are specified
g++ generates wrong code, if '-fno-exceptions' and '-O' options are specified. I did following tests. In the case of 1, wrong code was generated. 1. sh4-linux-g++ -S -O -fno-exceptions testcase.cc 2. sh4-linux-g++ -S -O2 -fno-exceptions testcase.cc Source code is as follows but I will attach the testcase. PRBool dummy; asm(POST:); return target-DispatchEvent(event, aDefaultAction ? aDefaultAction : dummy); The result of case 1. #APP POST: #NO_APP mov.w .L76,r0 mov.w .L79,r3 add r14,r3 mov.l @(r0,r3),r4 mov.l @r4,r1 mov.l @(20,r1),r2 mov.l @r8,r5 mov.l @(44,r3),r1 tst r1,r1 bf .L27 mov.w .L66,r1# .L66: .short -188 mov.w .L79,r3# .L79: .short 188 add r14,r3 add r1,r3 mov.l r3,@(44,r3) # this code is wrong because 44 is not right value .L27:# the value should be 232 - (188 - 188) but not 232 - 188 mov.w .L68,r0# .L68: .short 232 mov.l @(r0,r14),r6 jsr @r2 nop The result of case 2. It seems that this case is right. #APP POST: #NO_APP mov.w .L62,r3 mov.l @r13,r5 add r14,r3 mov.l @(0,r3),r4 mov.l @(44,r3),r2 mov.l @r4,r1 tst r2,r2 mov.l @(20,r1),r1 bt .L34 .L27: mov.w .L58,r0 mov.l @(r0,r14),r6 jsr @r1 nop mov r0,r9 .L24: mov.l .L63,r1 jsr @r1 mov r8,r4 ... .L34: mov.w .L67,r2 mov.w .L68,r0 add r14,r2 mov.l r2,@(r0,r14) bra .L27 nop -- Summary: [SH] g++ generates wrong code, if '-fno-exceptions' and '-O' options are specified Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: saito at densan dot co dot jp GCC build triplet: sh4-linux GCC host triplet: sh4-linux GCC target triplet: sh4-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28011
[Bug target/28011] [SH] g++ generates wrong code, if '-fno-exceptions' and '-O' options are specified
--- Comment #1 from saito at densan dot co dot jp 2006-06-13 10:43 --- Created an attachment (id=11660) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11660action=view) testcase This testcase is very large because this file already includes header files and this came from firefox's build. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28011
[Bug middle-end/28010] [4.1/4.2 regression] ICE because of fold_rtx endless recursion
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-06-13 11:53
---
Confirmed.
Shorter testcase (crashes with or without -m32):
struct A
{
char c;
__SIZE_TYPE__ i, j;
};
int foo(struct A* p)
{
if ((char*)p != (char*)p + p-i)
return 2;
if (p-j)
return 1;
return 2;
}
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Severity|normal |major
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||ice-on-valid-code, monitored
Last reconfirmed|-00-00 00:00:00 |2006-06-13 11:53:06
date||
Target Milestone|--- |4.1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28010
[Bug tree-optimization/27798] gimplifying return CONSTANT creates unneeded temporaties
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-06-13 11:53 ---
The inliner needs this temporary appearantly. Otherwise you'll get
bar ()
{
int D.1524;
bb 2:
if (D.1524 != 0) goto L0; else goto L1;
L0:;
abort ();
L1:;
return;
}
out of
inline int foo () { return 0; }
void bar()
{
if (foo())
abort ();
}
i.e. it misses to initialize the temporary with the result. Otherwise you
can play with variants of the following patch:
Index: gimplify.c
===
*** gimplify.c (revision 114599)
--- gimplify.c (working copy)
*** gimplify_return_expr (tree stmt, tree *p
*** ,1116
--- ,1124
if (!result_decl
|| aggregate_value_p (result_decl, TREE_TYPE (current_function_decl)))
result = result_decl;
+ else if (/*is_gimple_formal_tmp_reg (TREE_OPERAND (ret_expr, 1))
+||*/ is_gimple_min_invariant (TREE_OPERAND (ret_expr, 1))
+ /*is_gimple_val (TREE_OPERAND (ret_expr, 1))*/)
+ {
+ TREE_OPERAND (stmt, 0) = TREE_OPERAND (ret_expr, 1);
+
+ return GS_ALL_DONE;
+ }
else if (gimplify_ctxp-return_temp)
result = gimplify_ctxp-return_temp;
else
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27798
[Bug java/1305] [JSR133] GCJ ignores volatile modifier
--- Comment #7 from aph at gcc dot gnu dot org 2006-06-13 12:44 --- Subject: Bug 1305 Author: aph Date: Tue Jun 13 12:43:56 2006 New Revision: 114609 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114609 Log: 2006-06-09 Andrew Haley [EMAIL PROTECTED] PR java/1305 PR java/27908 * builtins.c (initialize_builtins): Add __sync_synchronize(). * class.c (add_field): Mark volatile fields. * java-gimplify.c (java_gimplify_expr): Call new functions to handle self-modifying exprs and COMPONENT_REFs. (java_gimplify_component_ref): New. (java_gimplify_modify_expr): Add handling for volatiles. Modified: trunk/gcc/java/ChangeLog trunk/gcc/java/builtins.c trunk/gcc/java/class.c trunk/gcc/java/java-gimplify.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1305
[Bug java/27908] VMSecureRandom generateSeed infinite loop? (Regression)
--- Comment #14 from aph at gcc dot gnu dot org 2006-06-13 12:44 --- Subject: Bug 27908 Author: aph Date: Tue Jun 13 12:43:56 2006 New Revision: 114609 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114609 Log: 2006-06-09 Andrew Haley [EMAIL PROTECTED] PR java/1305 PR java/27908 * builtins.c (initialize_builtins): Add __sync_synchronize(). * class.c (add_field): Mark volatile fields. * java-gimplify.c (java_gimplify_expr): Call new functions to handle self-modifying exprs and COMPONENT_REFs. (java_gimplify_component_ref): New. (java_gimplify_modify_expr): Add handling for volatiles. Modified: trunk/gcc/java/ChangeLog trunk/gcc/java/builtins.c trunk/gcc/java/class.c trunk/gcc/java/java-gimplify.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27908
[Bug java/1305] [JSR133] GCJ ignores volatile modifier
--- Comment #8 from aph at gcc dot gnu dot org 2006-06-13 12:52 --- Note that this patch has some problems. In particular, it doesn't work with BC-compiled code. Also, on x86 it doesn't insert memory barrier instructions, but this is arguably a bug in __sync_synchronize() rather than a problem with this patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1305
[Bug middle-end/27733] [4.1 Regression] Large compile time regression
--- Comment #18 from bonzini at gnu dot org 2006-06-13 13:05 --- Subject: Bug 27733 Author: bonzini Date: Tue Jun 13 13:05:39 2006 New Revision: 114610 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114610 Log: 2006-06-13 Paolo Bonzini [EMAIL PROTECTED] PR middle-end/27733 * expmed.c (struct alg_hash_entry): Fix type of field T to match synth_mult argument. (NUM_ALG_HASH_ENTRIES): Make it bigger for 64-bit HOST_WIDE_INT. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/expmed.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733
[Bug middle-end/27733] [4.1 Regression] Large compile time regression
--- Comment #19 from bonzini at gnu dot org 2006-06-13 13:06 --- Fixed, but we may want the patch on 4.0 too. -- bonzini at gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.1.0 |4.1.1 Known to work|4.0.4 4.2.0 |4.0.4 4.1.2 4.2.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733
[Bug tree-optimization/28003] [4.2 Regression] optimizer bug
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-06-13 13:11
---
Confirmed.
Shorter testcase (should return 0, but returns 1):
struct A
{
int i, j[9];
A() : i(1) { j[0]=j[1]=j[2]=j[3]=j[4]=j[5]=j[6]=j[7]=j[8]=0; }
};
struct B
{
A a;
};
B b[] =
{
{}, {}, {}, {}, {}, {}, {}, {}, {}, {},
{}, {}, {}, {}, {}, {}, {}, {}, {}, {},
{}, {}, {}, {}, {}
};
int main()
{
return 1 - b[sizeof(b)/sizeof(B) - 1].a.i;
}
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
CC||reichelt at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||monitored
Last reconfirmed|-00-00 00:00:00 |2006-06-13 13:11:58
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28003
Re: [Bug tree-optimization/28003] [4.2 Regression] optimizer bug
pinskia at gcc dot gnu dot org wrote:
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-13 04:41
---
Hmm, we get after dce, just:
reduced_cell_two_folds[26] = {};
And DCE removes:
this_616 = reduced_cell_two_folds[26].u;
# SMT.68_1055 = V_MAY_DEF SMT.68_1054;
this_616-elems[0] = 1;
# SMT.68_1056 = V_MAY_DEF SMT.68_1055;
this_616-elems[1] = 0;
# SMT.68_1057 = V_MAY_DEF SMT.68_1056;
this_616-elems[2] = 0;
...
this_621 = reduced_cell_two_folds[26].h;
...
# SMT.68_1058 = V_MAY_DEF SMT.68_1057;
this_621-elems[0] = 2;
# SMT.68_1059 = V_MAY_DEF SMT.68_1058;
this_621-elems[1] = 1;
# SMT.68_1060 = V_MAY_DEF SMT.68_1059;
this_621-elems[2] = 1;
Which does not make sense. Nothing is special in alias shows what is going
wrong.
The only thing i can think of is that SMT.68 is not marked global.
Is it?
[Bug tree-optimization/28003] [4.2 Regression] optimizer bug
--- Comment #4 from dberlin at gcc dot gnu dot org 2006-06-13 13:29 ---
Subject: Re: [4.2 Regression] optimizer bug
pinskia at gcc dot gnu dot org wrote:
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-13 04:41
---
Hmm, we get after dce, just:
reduced_cell_two_folds[26] = {};
And DCE removes:
this_616 = reduced_cell_two_folds[26].u;
# SMT.68_1055 = V_MAY_DEF SMT.68_1054;
this_616-elems[0] = 1;
# SMT.68_1056 = V_MAY_DEF SMT.68_1055;
this_616-elems[1] = 0;
# SMT.68_1057 = V_MAY_DEF SMT.68_1056;
this_616-elems[2] = 0;
...
this_621 = reduced_cell_two_folds[26].h;
...
# SMT.68_1058 = V_MAY_DEF SMT.68_1057;
this_621-elems[0] = 2;
# SMT.68_1059 = V_MAY_DEF SMT.68_1058;
this_621-elems[1] = 1;
# SMT.68_1060 = V_MAY_DEF SMT.68_1059;
this_621-elems[2] = 1;
Which does not make sense. Nothing is special in alias shows what is going
wrong.
The only thing i can think of is that SMT.68 is not marked global.
Is it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28003
[Bug target/27767] Problem: gcc 4.0.3 on Unix_SV
--- Comment #6 from mirko dot bruzzone at primeur dot com 2006-06-13 13:59
---
(In reply to comment #5)
Subject: Re: Problem: gcc 4.0.3 on Unix_SV
mirko dot bruzzone at primeur dot com wrote:
gt-c-pragma.h:46: parse error before `__attribute__'
gt-c-pragma.h uses attribute unused in a parameter list, before the
parameter type. Like so:
void sub (__attribute__ ((unused)) int i) { }
This is a syntax that gcc-2.7.2 doesn't support. It was added later.
You could try hacking this out, but it might be simpler to try baby
steps. Use 2.7.2 to compile gcc-2.95.3, use 2.95.3 to compile
gcc-3.3.4, use 3.3.4 to compile gcc-4.x.
I see that 2.95.3 supports this syntax, so it might be able to compile
gcc-4.x, but there may also be other problems, so going from 2.95.e to a
3.x release, and then to a 4.x release is more likely to work.
We could probably fix this with some ifdefs, but gcc-2.7.2 is so old
that it doesn't seem worth the hassle. Plus there are probably other
issues that haven't been noticed yet.
Thank you very much for your reply.
I tried with success to compile gcc 2.95, but when I try to compile gcc 3.3.4
with gcc 2.95, I see this error:
gcc -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long -DHAVE_CONFIG_H
-DGENERATOR_FILE -o gengenrtl \
gengenrtl.o ../libiberty/libiberty.a
./gengenrtl -h tmp-genrtl.h
Segmentation Fault - core dumped
make[1]: *** [s-genrtl] Error 139
make[1]: Leaving directory `/usr1/bruzzonem/obj334/gcc'
make: *** [all-gcc] Error 2
So, could you help me again?
all the best.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27767
[Bug tree-optimization/27809] inefficient gimplification of globals
--- Comment #2 from rakdver at gcc dot gnu dot org 2006-06-13 14:09 --- (In reply to comment #1) Hmm, it should have produced G.3, G.n, at least I would have thought. No, we intentionally use the same variable for the lexically identical expressions, see internal_get_tmp_var/lookup_tmp_var. Original intention was to make PRE and other redundancy elimination optimization passes more efficient (this was essential especially for the old SSAPRE pass that used lexical equality of expressions to check for redundancies). These reasons are no longer relevant, but keeping the code saves a significant amount of memory and compile time (I tried removing the code a few months ago, but since it slows down compilation by some 1-2%, I never bothered with posting the patch). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27809
[Bug middle-end/28010] [4.1/4.2 regression] ICE because of fold_rtx endless recursion
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-13 14:14 --- Looking at the reduced testcase here, it looks even more the same as PR 27616. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||27616 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28010
[Bug middle-end/27896] inefficient lowering for return
--- Comment #2 from dann at godzilla dot ics dot uci dot edu 2006-06-13 14:18 --- Add Diego to the CC list as per his request. -- dann at godzilla dot ics dot uci dot edu changed: What|Removed |Added CC||dnovillo at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27896
[Bug tree-optimization/27809] inefficient gimplification of globals
--- Comment #3 from dann at godzilla dot ics dot uci dot edu 2006-06-13 14:22 --- (In reply to comment #2) (In reply to comment #1) Hmm, it should have produced G.3, G.n, at least I would have thought. No, we intentionally use the same variable for the lexically identical expressions, see internal_get_tmp_var/lookup_tmp_var. Original intention was to make PRE and other redundancy elimination optimization passes more efficient (this was essential especially for the old SSAPRE pass that used lexical equality of expressions to check for redundancies). These reasons are no longer relevant, but keeping the code saves a significant amount of memory and compile time (I tried removing the code a few months ago, but since it slows down compilation by some 1-2%, I never bothered with posting the patch). Using the same variable is surely good, wouldn't it be even better to not create the redundant G.2 = G assignments in this PR? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27809
[Bug tree-optimization/28003] [4.2 Regression] optimizer bug
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-06-13 14:26 --- (In reply to comment #4) The only thing i can think of is that SMT.68 is not marked global. Is it? Some how I missed that before: SMT.68, UID 2839, struct reduced_cell_two_fold_info, is aliased, is addressable -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28003
[Bug tree-optimization/27809] inefficient gimplification of globals
--- Comment #4 from dberlin at gcc dot gnu dot org 2006-06-13 14:26 --- gimplification is almost certainly the wrong place to be doing the kind of dataflow we'd need to determine where we could insert load/save pairs of globals. Really. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27809
[Bug bootstrap/22541] Building into empty PREFIX causes broken limits.h to be installed
--- Comment #4 from bernds at gcc dot gnu dot org 2006-06-13 14:39 --- Subject: Bug 22541 Author: bernds Date: Tue Jun 13 14:39:42 2006 New Revision: 114611 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114611 Log: PR bootstrap/22541 From Dan Kegel [EMAIL PROTECTED]: * Makefile.in: Strip dir/../ combinations from SYSTEM_INCLUDE_DIR. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22541
[Bug tree-optimization/27798] gimplifying return CONSTANT creates unneeded temporaties
--- Comment #3 from dann at godzilla dot ics dot uci dot edu 2006-06-13 14:42 --- One of the issues with this PR and also 27800, 27809 and 27810 is that this extra work/memory allocation done for a number of functions that are never used: like all the inline functions present in the glibc headers. These functions are thrown out after gimplification... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27798
[Bug tree-optimization/27798] gimplifying return CONSTANT creates unneeded temporaties
--- Comment #4 from dnovillo at redhat dot com 2006-06-13 14:49 --- Subject: Re: gimplifying return CONSTANT creates unneeded temporaties dann at godzilla dot ics dot uci dot edu wrote on 06/13/06 10:42: --- Comment #3 from dann at godzilla dot ics dot uci dot edu 2006-06-13 14:42 --- One of the issues with this PR and also 27800, 27809 and 27810 is that this extra work/memory allocation done for a number of functions that are never used: like all the inline functions present in the glibc headers. These functions are thrown out after gimplification... We need to strike a balance between the potential memory savings due to a more streamlined GIMPLE and the effort needed to get it. We should avoid anything that requires the gimplifier to build complex dataflow and/or duplicate existing optimizations. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27798
[Bug bootstrap/22541] Building into empty PREFIX causes broken limits.h to be installed
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-06-13 14:54 --- Fixed in 4.1.2 and the mainline. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22541
[Bug target/28014] New: space-optimized divide used inconsistently
sh-elf has space optimized division functions for -m4 / -m4-single, which are provided in a separate library, which is used when statically linking with -Os . However, libgcc itself constains some references to the divide functions. If these functions have not been used by something else earlier, the references are satisifed from within libgcc. This is a missed space optimization, but worse, libgcc.a has a module which defines both signed and unsigned divide, while libgcc-Os-4-200.a provides them in two separate modules. If one of the symbols is pulled in early from libgcc-Os-4-200.a, and the other satisfied later from within libgcc.a, the first symbol ends up being defined twice. I propose to fix this by putting a copy of the unwinder code into libgcc-Os-4-200.a, which will make the only reference to signed divide from libgcc.a irrelevant, and by providing an sh udiv_qrnnd definition in longlong.h and optimizing 1U/0 away in sh.md, which will get rid of the references to unsigned divide in libgcc.a -- Summary: space-optimized divide used inconsistently Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: missed-optimization, link-failure Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org GCC target triplet: sh-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28014
[Bug tree-optimization/27830] [4.1 regression] ICE: verify_stmts failed (invalid operand to unary operator)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.1.2 4.2.0 |4.1.2 Known to work|4.1.0 |4.1.0 4.2.0 3.4.0 Summary|[4.1/4.2 regression] ICE: |[4.1 regression] ICE: |verify_stmts failed (invalid|verify_stmts failed (invalid |operand to unary operator) |operand to unary operator) Target Milestone|4.2.0 |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27830
[Bug target/28014] space-optimized divide used inconsistently
--- Comment #1 from amylaar at gcc dot gnu dot org 2006-06-13 15:21 --- Created an attachment (id=11661) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11661action=view) test case This testcase goes in testsuite/g++.dg/eh . -- amylaar at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |amylaar at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28014
[Bug tree-optimization/5035] Incorrectly produces '`var' might be used uninitialized in this function'
--- Comment #13 from dberlin at gcc dot gnu dot org 2006-06-13 15:22 --- Some year we'll have to use the control dependence graph to see if all the conditions are the same :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5035
[Bug middle-end/27733] [4.1 Regression] Large compile time regression
--- Comment #20 from soete dot joel at tiscali dot be 2006-06-13 15:43 --- (In reply to comment #19) Fixed, but we may want the patch on 4.0 too. Curious I didn't notice this pb gcc-4.0? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733
[Bug c++/28015] New: Nonspecific error messages
Greetings: I am trying to compile an application and I am getting error massages like the following one. Obviously the previous definition doesn't point to the first definition of struct timespec but to the redundant definition. This is therefore pretty useless: /usr/include/time.h:119: error: redefinition of `struct timespec' /usr/include/time.h:119: error: previous definition of `struct timespec' Phil -- Summary: Nonspecific error messages Product: gcc Version: 3.4.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: philippe at fornux dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28015
[Bug c++/28015] Nonspecific error messages
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-13 16:37 ---
I cannot reproduce this with a simple:
struct timespec {};
#include time.h
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28015
[Bug target/26792] [4.2 Regression] C++ is broken on *-*-darwin*
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2006-06-13 16:44 --- Geoff, Does any other os, that uses gcc, version libgcc_s in the manner that Apple does? Simply not setting MACOSX_DEPLOYMENT_TARGET during the build of gcc 4.2 doesn't make the problem go away. The resulting libstdc++.6.dylib and libgcc_s.1.dylib libraries have _Unwind_GetIPInfo symbols whereas libgcc_s.10.4.dylib and libgcc_s.10.5.dylib don't. This precludes safely using MACOSX_DEPLOYMENT_TARGET at all with gcc 4.2. I know you said you won't assign this to yourself until it happens to you. However it isn't happening to you because you don't want it to. Apple really needs to deal with the breakage caused by their decision to version libgcc_s. Jack (In reply to comment #2) Clearly, we cannot add any symbols to the 10.4 libgcc_s. 10.4 has already shipped, and we do not have a time travel device. By default, gcc compiles for the earliest OS version it knows about. For C++, that means 10.3.9/10.4. This is best for users. Thus, by default, you cannot use any new symbols in libgcc_s. The problem occurs because libstdc++ wants to use the new symbol by default. I can think of a bunch of solutions to the problem: 1. Have libstdc++ use autoconf to detect the presence of the new symbol and use it only if it exists. 2. Decide that the purpose of libstdc++ is to be installed only on new (not yet existing) system versions, and pass appropriate flags to the compiler to make this happen. Of course, this might make testing hard for people still using 10.4. 3. Decide that libstdc++ and libgcc go together, and hack libstdc++'s link to use libgcc_s.1.dylib directly. Apple doesn't do this internally, we're shipping 4.0.0 libstdc++ and 4.0.1 libgcc. Apple's libstdc++ is binary incompatible with FSF libstdc++ (in small but important ways) and so the effect of this might be that no-one can use FSF libstdc++ or FSF libgcc on Darwin at all. 4. Declare that we don't care. The problem right now affects only people with the MACOSX_DEPLOYMENT_TARGET environment variable set which they probably shoudn't have set while building FSF GCC. I think we should go for (1), although (4) has certain advantages... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26792
[Bug c++/27748] [4.2 Regression] rejects _Pragma with macros
--- Comment #6 from sje at cup dot hp dot com 2006-06-13 16:54 --- The new _Pragma1.C and _Pragma6.c tests are failing on ia64-hp-hpux11.23 because that platform does not define HANDLE_PRAGMA_PACK_PUSH_POP. Presumably there are other platforms that also do not define this and will also fail these tests. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27748
[Bug tree-optimization/28003] [4.2 Regression] optimizer bug
--- Comment #6 from dberlin at gcc dot gnu dot org 2006-06-13 17:15 --- So it should have been marked global, and should alias the global var, but apparently the global var doesn't pop into it's alias set -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28003
[Bug fortran/27996] Compile time warn for: character(2) :: str = 'ABC' (expression truncated)
-- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-13 17:24:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27996
[Bug fortran/27998] character arrays: warn if erray constructor values have different lengths
-- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-13 17:25:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27998
[Bug target/28014] space-optimized divide used inconsistently
--- Comment #2 from amylaar at gcc dot gnu dot org 2006-06-13 17:45 --- Subject: Bug 28014 Author: amylaar Date: Tue Jun 13 17:44:56 2006 New Revision: 114616 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114616 Log: PR target/28014: gcc: * config/sh/t-sh (LIB1ASMFUNCS): Add _udiv_qrnnd16 * config/sh/sh.c (print_operand): Add !SHMEDIA functionality to 'M'. * config/sh/lib1funcs.h (SL, SL1): Define. * config/sh/lib1funcs.asm (__udiv_qrnnd16): New hidden function. * longlong.h (__sh__): Define umul_ppmm, udiv_qrnnd and sub_ddmmss. * config/sh/t-sh ($(T)unwind-dw2-Os-4-200.o): New rule. (OBJS_Os_4_200): New variable. ($(T)libgcc-Os-4-200.a): Use it. * sh.md (udivsi3): For TARGET_DIVIDE_CALL_TABLE, avoid function call when dividing 1 and/or by 0. gcc/testsuite: * g++.dg/eh/div.C: New test. Added: trunk/gcc/testsuite/g++.dg/eh/div.C Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/lib1funcs.asm trunk/gcc/config/sh/lib1funcs.h trunk/gcc/config/sh/sh.c trunk/gcc/config/sh/sh.md trunk/gcc/config/sh/t-sh trunk/gcc/longlong.h trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28014
[Bug target/28014] space-optimized divide used inconsistently
--- Comment #3 from amylaar at gcc dot gnu dot org 2006-06-13 18:05 --- Fixed. -- amylaar at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28014
[Bug c++/21210] [4.0/4.1 Regression] Trouble with __complex__ types default construction
--- Comment #10 from sayle at gcc dot gnu dot org 2006-06-13 18:06 --- Subject: Bug 21210 Author: sayle Date: Tue Jun 13 18:06:00 2006 New Revision: 114618 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114618 Log: PR c++/21210 * typeck2.c (build_functional_cast): Use cp_convert to construct non-aggregate initializers instead of the user-level build_c_cast. * g++.dg/init/complex1.C: New test case. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/init/complex1.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/typeck2.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21210
[Bug c++/28016] New: GCC 4.2 emitting static template constants as global symbols?
I have some software that uses the BOOST matrix library UBLAS (1.33.1). This
software compiles and links with GCC 4.1.1 (Debian Linux system - GNU ld) but
gives linking errors with GCC 4.2:
substitution.o:(.data+0x0): multiple definition of
`_ZN5boost7numeric5ublas21scalar_divides_assignIT_T0_E8computedE'
alignment.o:(.data+0x0): first defined here
Here is from the definition of the static const member of a template class in
boost/numeric/ublas/functional.hpp:
templateclass T1, class T2
struct scalar_divides_assign:
public scalar_binary_assign_functorT1, T2 {
... stuff ...
};
templateclass T1, class T2
const bool scalar_divides_assignT1,T2::computed = true;
GCC 4.2, but not 4.1 actually emits this constant in the global data section.
With 4.2:
$ nm alignment.o | grep divides
0180 t
_GLOBAL__I__ZN5boost7numeric5ublas21scalar_divides_assignIT_T0_E8computedE
D
_ZN5boost7numeric5ublas21scalar_divides_assignIT_T0_E8computedE
With 4.1 neither of these two symbols (or is it one symbol, mentioned twice?)
is emitted.
--
Summary: GCC 4.2 emitting static template constants as global
symbols?
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bredelin at ucla dot edu
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28016
[Bug c++/28016] GCC 4.2 emitting static template constants as global symbols?
--- Comment #1 from bredelin at ucla dot edu 2006-06-13 18:30 ---
Here is some source code that exhibits the problem:
begin a.C -
templateclass T1, class T2
struct scalar_divides_assign {
static const bool computed ;
};
templateclass T1, class T2
const bool scalar_divides_assignT1,T2::computed = true;
- end --
To see the problem do
$ g++-4.2 -c a.C
$ nm a.o | grep computed
D _ZN21scalar_divides_assignIT_T0_E8computedE
This symbol shouldn't be emitted, or at least not in this way.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28016
[Bug c++/28016] [4.2 Regression] GCC 4.2 emitting static template constants as global symbols?
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-13 18:49 --- Confirmed. (In reply to comment #1) templateclass T1, class T2 const bool scalar_divides_assignT1,T2::computed = true; For this case above, nothing should be emitted. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|x86_64-unknown-linux-gnu| GCC host triplet|x86_64-unknown-linux-gnu| GCC target triplet|x86_64-unknown-linux-gnu| Keywords||link-failure, wrong-code Known to work||4.1.0 Last reconfirmed|-00-00 00:00:00 |2006-06-13 18:49:08 date|| Summary|GCC 4.2 emitting static |[4.2 Regression] GCC 4.2 |template constants as global|emitting static template |symbols?|constants as global symbols? Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28016
[Bug c++/28016] [4.2 Regression] emitting template constant
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-13 18:52 --- It is only static const variables which are miss handled. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28016
[Bug fortran/22210] gfc_conv_array_initializer weirdness
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-06-13 18:55 --- (In reply to comment #7) Where did this one go to? Can we close it? It is still funny looking code. I might take a look this weekend or on June 27 when I am traveling to the GCC summit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22210
[Bug c++/28017] New: lack of guard variables for explicitly instantiated template static data
I was passed a test case consisting of two translation units:
// test.h
#include iostream
class A
{
public:
A()
{
mString = new char[2];
std::cout new: mString has value (void*) mString std::endl;
}
~A()
{
std::cout delete: mString has value (void*) mString
std::endl;
delete [] mString;
}
void f()
{
}
private:
char* mString;
};
templatetypename T
class Test
{
public:
Test()
{
sA.f();
}
private:
static A sA;
};
templatetypename T
A TestT::sA;
// test.cpp
#include test.h
template class Testint;
int foo()
{
return 0;
}
// main.cpp
#include test.h
int foo();
int main()
{
Testint theTest;
foo();
return 0;
}
When compiled with something like:
g++ -o test test.cpp main.cpp
the test shows evidence of the static Testint::sA being
constructed/destructed twice:
new: mString has value 0x5002d0
new: mString has value 0x500300
delete: mString has value 0x500300
delete: mString has value 0x500300
The desired output should be more like:
new: mString has value 0x5002d0
delete: mString has value 0x5002d0
Further inspection reveals that the guard variable for this static is not being
generated in test.cpp because of the explicit instantiation there (tested on
Apple's gcc 4.0.1).
I am wondering if an appropriate fix might be in:
gcc/cp/decl2.c, in function start_static_initialization_or_destruction
Change the if statement that looks like:
if (TREE_PUBLIC (decl) (DECL_COMMON (decl)
|| DECL_ONE_ONLY (decl)
|| DECL_WEAK (decl)))
{
tree guard_cond;
to:
if (TREE_PUBLIC (decl) (DECL_COMMON (decl)
|| DECL_ONE_ONLY (decl)
|| DECL_WEAK (decl)
|| DECL_EXPLICIT_INSTANTIATION (decl)))
{
tree guard_cond;
I looked in the mainline decl2.c and found the same logic in the macro
NEEDS_GUARD_P. Here I'm suggesting changing:
#define NEEDS_GUARD_P(decl) (TREE_PUBLIC (decl) (DECL_COMMON (decl) \
|| DECL_ONE_ONLY (decl) \
|| DECL_WEAK (decl)))
to:
#define NEEDS_GUARD_P(decl) (TREE_PUBLIC (decl) (DECL_COMMON (decl) \
|| DECL_ONE_ONLY (decl) \
|| DECL_WEAK (decl) \
||
DECL_EXPLICIT_INSTANTIATION (decl)))
--
Summary: lack of guard variables for explicitly instantiated
template static data
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hhinnant at apple dot com
GCC host triplet: darwin ppc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28017
[Bug c++/28018] New: [4.2 regression] g++.dg/ext/complit1.C fails: in emit_move_insn, at expr.c:3275
I get the following error in the test suite: FAIL: g++.dg/ext/complit1.C (internal compiler error) FAIL: g++.dg/ext/complit1.C (test for excess errors) This is fairly new. 20060530 worked. The error is: /home/tbm/x.c: In constructor 'Foo::Foo(int, int)': /home/tbm/x.c:14: error: ISO C++ forbids assignment of arrays /home/tbm/x.c: In constructor 'Foo::Foo(int, int)': /home/tbm/x.c:14: internal compiler error: in emit_move_insn, at expr.c:3275 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. How odd. 20060530 seems to fail as well but I cannot remember seeing the test failure when I built 20060530. -- Summary: [4.2 regression] g++.dg/ext/complit1.C fails: in emit_move_insn, at expr.c:3275 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com GCC build triplet: i486-linux-gnu GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28018
[Bug c++/28017] lack of guard variables for explicitly instantiated template static data
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-13 19:14 --- This works on x86-linux-gnu on the mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28017
[Bug fortran/27980] Wrong allocation for zero-sized function result
--- Comment #3 from patchapp at dberlin dot org 2006-06-13 19:15 --- Subject: Bug number PR 27980 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00708.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27980
[Bug c++/28017] lack of guard variables for explicitly instantiated template static data
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-13 19:15 --- (In reply to comment #1) This works on x86-linux-gnu on the mainline. Oh and in 3.3.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28017
[Bug c++/28017] lack of guard variables for explicitly instantiated template static data
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-13 19:18 --- || DECL_ONE_ONLY (decl) || DECL_WEAK (decl) \ Actually those looks should include what is defined for Darwin. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC host triplet|darwin ppc | GCC target triplet||*-darwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28017
[Bug c++/28018] [4.2 regression] g++.dg/ext/complit1.C fails: in emit_move_insn, at expr.c:3275
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-13 19:19 --- Confirmed, I reported this in the bug report which changed this testcase. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-13 19:19:49 date|| Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28018
[Bug c++/28018] [4.2 regression] g++.dg/ext/complit1.C fails: in emit_move_insn, at expr.c:3275
--- Comment #2 from tbm at cyrius dot com 2006-06-13 19:25 --- (In reply to comment #1) Confirmed, I reported this in the bug report which changed this testcase. Which PR is that? I searched and couldn't find anything, and neither did 'svn log' show a recent change to the test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28018
[Bug c++/28018] [4.2 regression] g++.dg/ext/complit1.C fails: in emit_move_insn, at expr.c:3275
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-06-13 19:28 --- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20103#c56 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28018
[Bug fortran/28005] gfortran: mathmul produces wrong result
--- Comment #1 from pault at gcc dot gnu dot org 2006-06-13 19:33 --- Tobias, Thanks for the recent batch of reports; this one, in particular, which is not at all good! I am heavily committed with a few other bugs; I'll see if FX or Thomas have the time. Otherwise I'll drop everything for this one. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-13 19:33:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28005
[Bug c++/28017] lack of guard variables for explicitly instantiated template static data
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-06-13 19:37 --- For Darwin we do not want explicit instantiations to be linkonce. */ This is why this testcase fails on darwin. We should instead of just adding DECL_EXPLICIT_INSTANTIATION, check TARGET_WEAK_NOT_IN_ARCHIVE_TOC. (!TARGET_WEAK_NOT_IN_ARCHIVE_TOC || (! DECL_EXPLICIT_INSTANTIATION (decl) ! DECL_TEMPLATE_SPECIALIZATION (decl))) This is a darwin only issue. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-13 19:37:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28017
[Bug rtl-optimization/28019] New: ICE: x86 scheduler upsets local reg alloc
Scheduler hoists an x86 IMUL (clobbers %eax) ahead of the first reference to a
parameter passed in %eax.
% /Volumes/sandbox/stuart/gcc.fsf.pure.debug.obj/gcc/cc1 reduce.c -quiet
-mtune=generic -O2 -fschedule-insns
reduce.c: In function '_perfInitPerfTable':
reduce.c:43: error: unable to find a register to spill in class 'AREG'
reduce.c:43: error: this is the insn:
(insn:HI 21 83 9 2 (parallel [
(set (reg/v:SI 5 di [orig:66 maxNvClk ] [66])
(truncate:SI (lshiftrt:DI (mult:DI (zero_extend:DI (mem/s:SI
(plus:SI (reg/v/f:SI 1 dx [orig:71 thisPerf ] [71])
(const_int 80 [0x50])) [7
variable.MaxNvclkAllowed+0 S4 A32]))
(zero_extend:DI (reg:SI 3 bx [78])))
(const_int 32 [0x20]
(clobber (scratch:SI))
(clobber (reg:CC 17 flags))
]) 189 {*umulsi3_highpart_insn} (nil)
(expr_list:REG_DEAD (reg/v/f:SI 1 dx [orig:71 thisPerf ] [71])
(expr_list:REG_DEAD (reg:SI 3 bx [78])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_UNUSED (scratch:SI)
(nil))
reduce.c:43: internal compiler error: in spill_failure, at reload1.c:1911
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
Here is the testcase:
typedef unsigned long U32;
typedef U32 U032;
typedef struct RMTIMEOUT {
}
NODE, *PNODE;
typedef struct OBJP OBJP, *POBJP;
typedef struct OBJPERF *POBJPERF;
typedef struct _def_ext_y_gen_params {
U032 G;
}
YFREQ, *PYFREQ;
typedef void PerfInitPerfTables (POBJP, POBJPERF);
typedef struct _perf_level {
YFREQ Y;
}
PERF_LEVEL, *PPERF_LEVEL;
typedef struct _perf_table {
PERF_LEVEL Levels[10];
}
PERF_TABLE, *PPERF_TABLE;
struct OBJPERF {
PERF_TABLE lowPower;
PERF_TABLE fullPower;
U032 MaxyAllowed;
PerfInitPerfTables *perfInitPerfTables;
};
static PerfInitPerfTables perfInitPerfTables;
void constructObjPerf(POBJPERF thisPerf, U032 thisPublicHalID) {
thisPerf-perfInitPerfTables = perfInitPerfTables;
}
static U032 _perfInitPerfTable(POBJP pP, POBJPERF thisPerf, PPERF_TABLE
pPerfTable, U032 startEntry, U032 flagMask, U032 flagVal) {
U032 i, matchingLevels = 0;
U032 maxY, maxMY;
maxY = thisPerf-MaxyAllowed / (10 * 1000);
for (i = 0;
i 10;
i++) {
if (DevinitGetPerfLevelEntry(pP, startEntry + i, pPerfTable-Levels[i]) !=
0x) break;
if (maxY) {
if (pPerfTable-Levels[i].Y.G maxY)
pPerfTable-Levels[i].Y.G = maxY;
}
}
}
static void perfInitPerfTables(POBJP pP, POBJPERF thisPerf) {
U032 i, data, levelsFound;
levelsFound = _perfInitPerfTable(pP, thisPerf, thisPerf-lowPower, 0,
(1(0)), 0);
levelsFound = _perfInitPerfTable(pP, thisPerf, thisPerf-fullPower,
levelsFound, (1(0)), 1);
}
--
Summary: ICE: x86 scheduler upsets local reg alloc
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stuart at apple dot com
GCC build triplet: i386-apple-darwin8.7.2
GCC host triplet: i386-apple-darwin8.7.2
GCC target triplet: i386-apple-darwin8.7.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28019
[Bug rtl-optimization/28019] ICE: x86 scheduler upsets local reg alloc
--- Comment #1 from stuart at apple dot com 2006-06-13 19:44 --- Created an attachment (id=11663) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11663action=view) Testcase Attaching (same) testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28019
[Bug rtl-optimization/28019] register allocator does not reschedule for x86 imull
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-13 19:45 --- Yes, yes we know, this is the nth bug about this issue. This looks like PR 9085. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||9085 GCC build triplet|i386-apple-darwin8.7.2 | GCC host triplet|i386-apple-darwin8.7.2 | GCC target triplet|i386-apple-darwin8.7.2 |i?86-* Summary|ICE: x86 scheduler upsets |register allocator does not |local reg alloc |reschedule for x86 imull http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28019
[Bug fortran/28004] Warn if intent(out) dummy variable is not set
--- Comment #1 from pault at gcc dot gnu dot org 2006-06-13 19:45 --- Tobias, I presented a patch for this problem and for detected unassigned r-values that was rejected. I don't know what to say; I think that it's a bug, in principle, but the standard does not require it. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28004
[Bug rtl-optimization/28019] register allocator does not reschedule for x86 imull
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code, ra Last reconfirmed|-00-00 00:00:00 |2006-06-13 19:48:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28019
[Bug c++/28015] Nonspecific error messages
--- Comment #2 from philippe at fornux dot com 2006-06-13 20:17 --- I was compiling a big project and I ended up with this error message. I just tried to compile the same file by preprocessing it first (-E) and I don't have the error anymore. Actually I think some dependent file got included twice. That will explain the error messages refering to the same locations; therefore it not a compiler problem but some improper #ifndef preprocessor handling in the header files on my Redhat system. I will investigate and let you know if I come up with something. Bests, Phil -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28015
[Bug objc++/28020] New: [4.2 regression] expected class 'type', have 'exceptional' (error_mark) in setup_one_parameter, at tree-inline.c:1067
A number of obj-c++ test cases fail with an ICE now (this didn't happen with 20060530): FAIL: obj-c++.dg/comp-types-10.mm (internal compiler error) ... FAIL: obj-c++.dg/try-catch-9.mm (internal compiler error) (sid)955:[EMAIL PROTECTED]: ..atch/gcc-snapshot-20060613] ./build/gcc/g++ -c -O2 src/gcc/testsuite/obj-c++.dg/comp-types-10.mm src/gcc/testsuite/obj-c++.dg/comp-types-10.mm: In function '(static initializers for src/gcc/testsuite/obj-c++.dg/comp-types-10.mm)': src/gcc/testsuite/obj-c++.dg/comp-types-10.mm:19: internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in setup_one_parameter, at tree-inline.c:1067 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: [4.2 regression] expected class 'type', have 'exceptional' (error_mark) in setup_one_parameter, at tree-inline.c:1067 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: objc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28020
[Bug rtl-optimization/28019] register allocator does not reschedule for x86 imull
--- Comment #3 from steven at gcc dot gnu dot org 2006-06-13 20:26 --- The solution is don't do -fschedule-insns on x86. Unless you first add heuristics in the scheduler to keep a better eye on register pressure, and fix the many known bugs in scheduling for x86. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28019
[Bug objc++/28020] [4.2 regression] expected class 'type', have 'exceptional' (error_mark) in setup_one_parameter, at tree-inline.c:1067
--- Comment #1 from tbm at cyrius dot com 2006-06-13 20:30 --- Actually, this shows up with 20060530. It was introduced some time between 20060218 and 20051124. Unfortunately I don't have any compiler version inbetween these dates around so I cannot narrow it down further. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28020
[Bug c++/28017] lack of guard variables for explicitly instantiated template static data
--- Comment #5 from hhinnant at apple dot com 2006-06-13 21:23 --- (In reply to comment #4) For Darwin we do not want explicit instantiations to be linkonce. */ This is why this testcase fails on darwin. We should instead of just adding DECL_EXPLICIT_INSTANTIATION, check TARGET_WEAK_NOT_IN_ARCHIVE_TOC. (!TARGET_WEAK_NOT_IN_ARCHIVE_TOC || (! DECL_EXPLICIT_INSTANTIATION (decl) ! DECL_TEMPLATE_SPECIALIZATION (decl))) This is a darwin only issue. I'm having trouble deciding exactly what you mean. Is this what you mean: #define NEEDS_GUARD_P(decl) (!TARGET_WEAK_NOT_IN_ARCHIVE_TOC \ || (! DECL_EXPLICIT_INSTANTIATION (decl) \ ! DECL_TEMPLATE_SPECIALIZATION (decl))) Or do you mean: #define NEEDS_GUARD_P(decl) (TREE_PUBLIC (decl) (DECL_COMMON (decl) \ || DECL_ONE_ONLY (decl) \ || DECL_WEAK (decl) \ || (!TARGET_WEAK_NOT_IN_ARCHIVE_TOC \ || (! DECL_EXPLICIT_INSTANTIATION (decl) \ ! DECL_TEMPLATE_SPECIALIZATION (decl) ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28017
Re: [Bug c++/28017] lack of guard variables for explicitly instantiated template static data
#define NEEDS_GUARD_P(decl) (TREE_PUBLIC (decl) (DECL_COMMON (decl) \ || DECL_ONE_ONLY (decl) \ || DECL_WEAK (decl) \ || (!TARGET_WEAK_NOT_IN_ARCHIVE_TOC \ || (! DECL_EXPLICIT_INSTANTIATION (decl) \ ! DECL_TEMPLATE_SPECIALIZATION (decl) ? The latter. -- Pinski
[Bug c++/28017] lack of guard variables for explicitly instantiated template static data
--- Comment #6 from pinskia at physics dot uc dot edu 2006-06-13 21:24 --- Subject: Re: lack of guard variables for explicitly instantiated template static data #define NEEDS_GUARD_P(decl) (TREE_PUBLIC (decl) (DECL_COMMON (decl) \ || DECL_ONE_ONLY (decl) \ || DECL_WEAK (decl) \ || (!TARGET_WEAK_NOT_IN_ARCHIVE_TOC \ || (! DECL_EXPLICIT_INSTANTIATION (decl) \ ! DECL_TEMPLATE_SPECIALIZATION (decl) ? The latter. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28017
[Bug c++/28017] lack of guard variables for explicitly instantiated template static data
--- Comment #7 from hhinnant at apple dot com 2006-06-13 21:41 --- (In reply to comment #6) Subject: Re: lack of guard variables for explicitly instantiated template static data #define NEEDS_GUARD_P(decl) (TREE_PUBLIC (decl) (DECL_COMMON (decl) \ || DECL_ONE_ONLY (decl) \ || DECL_WEAK (decl) \ || (!TARGET_WEAK_NOT_IN_ARCHIVE_TOC \ || (! DECL_EXPLICIT_INSTANTIATION (decl) \ ! DECL_TEMPLATE_SPECIALIZATION (decl) ? The latter. Thanks. But this doesn't pass the test case on darwin. I'm not familiar enough with the C++ FE to understand TARGET_WEAK_NOT_IN_ARCHIVE_TOC. Could you double check the above. The ! in front of DECL_EXPLICIT_INSTANTIATION looks especially suspicious to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28017
Re: [Bug c++/28017] lack of guard variables for explicitly instantiated template static data
--- Comment #7 from hhinnant at apple dot com 2006-06-13 21:41 --- (In reply to comment #6) Subject: Re: lack of guard variables for explicitly instantiated template static data #define NEEDS_GUARD_P(decl) (TREE_PUBLIC (decl) (DECL_COMMON (decl) \ || DECL_ONE_ONLY (decl) \ || DECL_WEAK (decl) \ || (!TARGET_WEAK_NOT_IN_ARCHIVE_TOC \ || (! DECL_EXPLICIT_INSTANTIATION (decl) \ ! DECL_TEMPLATE_SPECIALIZATION (decl) ? The latter. Thanks. But this doesn't pass the test case on darwin. I'm not familiar enough with the C++ FE to understand TARGET_WEAK_NOT_IN_ARCHIVE_TOC. Could you double check the above. The ! in front of DECL_EXPLICIT_INSTANTIATION looks especially suspicious to me. You want the opposite of that like: (TARGET_WEAK_NOT_IN_ARCHIVE_TOC (DECL_EXPLICIT_INSTANTIATION (decl) || DECL_TEMPLATE_SPECIALIZATION (decl))) I was quoting the case when DECL_WEAK would be set on the decl. TARGET_WEAK_NOT_IN_ARCHIVE_TOC is only defined to 1 for darwin. -- Pinski
[Bug c++/28017] lack of guard variables for explicitly instantiated template static data
--- Comment #8 from pinskia at physics dot uc dot edu 2006-06-13 21:47 --- Subject: Re: lack of guard variables for explicitly instantiated template static data --- Comment #7 from hhinnant at apple dot com 2006-06-13 21:41 --- (In reply to comment #6) Subject: Re: lack of guard variables for explicitly instantiated template static data #define NEEDS_GUARD_P(decl) (TREE_PUBLIC (decl) (DECL_COMMON (decl) \ || DECL_ONE_ONLY (decl) \ || DECL_WEAK (decl) \ || (!TARGET_WEAK_NOT_IN_ARCHIVE_TOC \ || (! DECL_EXPLICIT_INSTANTIATION (decl) \ ! DECL_TEMPLATE_SPECIALIZATION (decl) ? The latter. Thanks. But this doesn't pass the test case on darwin. I'm not familiar enough with the C++ FE to understand TARGET_WEAK_NOT_IN_ARCHIVE_TOC. Could you double check the above. The ! in front of DECL_EXPLICIT_INSTANTIATION looks especially suspicious to me. You want the opposite of that like: (TARGET_WEAK_NOT_IN_ARCHIVE_TOC (DECL_EXPLICIT_INSTANTIATION (decl) || DECL_TEMPLATE_SPECIALIZATION (decl))) I was quoting the case when DECL_WEAK would be set on the decl. TARGET_WEAK_NOT_IN_ARCHIVE_TOC is only defined to 1 for darwin. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28017
[Bug c++/28017] lack of guard variables for explicitly instantiated template static data
--- Comment #9 from hhinnant at apple dot com 2006-06-13 22:02 --- (In reply to comment #8) Thanks. That not only makes sense to me now, but it passes the test. :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28017
[Bug c++/22592] -fvisibility-inlines-hidden broken differently
--- Comment #8 from jason at gcc dot gnu dot org 2006-06-13 23:28 --- Either 20218 is a bug or this is. It seems to me that 20218 is the bug. If you declare a function to be hidden, you are asserting that it will be defined in the current DSO. From the GCC documentation: Two declarations of an object with hidden linkage refer to the same object if they are in the same shared object. Calling this function directly is a correct optimization, the bug is that you fail to define it (by defining the key method) in the same DSO. If this class is imported from a library, it shouldn't have hidden linkage; the library's namespace should have explicit default linkage. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22592
[Bug libfortran/27964] Wrong line ends on windows (XP)
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-06-14 00:32 --- My XP box died. I can't do much with this now. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|jvdelisle at gcc dot gnu dot|unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27964
[Bug libgomp/27254] FAIL: libgomp.fortran/reduction6.f90
--- Comment #2 from danglin at gcc dot gnu dot org 2006-06-14 00:59 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00717.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27254
[Bug c++/26559] [4.0/4.1/4.2 Regression] ICE with __builtin_constant_p in template argument
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26559
[Bug c++/26577] [4.0/4.1/4.2 regression] ICE in cp_expr_size with volatile and call to static
--- Comment #8 from mmitchel at gcc dot gnu dot org 2006-06-14 02:16 --- Diego -- Your last comment was cut off. However, no, COMPLETE_TYPE_P does not imply that we know the size of the type, and it can't ever imply that, in C++. For a type with virtual bases, we don't know what the size of the object will be; in fact, we don't know wehther the object will be located in a contiguous block of memory. So, no front end change will avoid this problem. -- Mark -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added CC||mark at codesourcery dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26577
[Bug target/27827] gcc 4 produces worse x87 code on all platforms than gcc 3
--- Comment #14 from whaley at cs dot utsa dot edu 2006-06-14 02:40 --- OK, I got access to some older machines, and it appears that Core is the only architecture that likes gcc 4's code. More precisely, I have confirmed that the following architectures run significantly slower using gcc4 than gcc 3: Pentium-D, P4e, Pentium III, PentiumPRO, Athlon-64 X2, Opteron. Any help appreciated, Clint -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27827
[Bug c++/27227] [4.0/4.1/4.2 Regression] rejects valid code with some extern C
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27227
[Bug objc++/28020] [4.2 regression] expected class 'type', have 'exceptional' (error_mark) in setup_one_parameter, at tree-inline.c:1067
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-14 04:19 --- Actually this has been failing since the testcase was added and Objective-C++ was added. This is a dup of bug 23716. *** This bug has been marked as a duplicate of 23716 *** -- 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=28020
[Bug objc++/23716] obj-c++.dg/comp-types-10.mm ICE with the GNU runtime
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-06-14 04:19 --- *** Bug 28020 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23716
[Bug c++/21210] [4.0 Regression] Trouble with __complex__ types default construction
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to work|3.4.0 4.2.0 |3.4.0 4.2.0 4.1.2 Summary|[4.0/4.1 Regression] Trouble|[4.0 Regression] Trouble |with __complex__ types |with __complex__ types |default construction|default construction Target Milestone|4.1.2 |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21210
[Bug c++/21210] [4.0 Regression] Trouble with __complex__ types default construction
--- Comment #11 from sayle at gcc dot gnu dot org 2006-06-14 04:35 --- Subject: Bug 21210 Author: sayle Date: Wed Jun 14 04:35:29 2006 New Revision: 114634 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114634 Log: PR c++/21210 * typeck2.c (build_functional_cast): Use cp_convert to construct non-aggregate initializers instead of the user-level build_c_cast. * g++.dg/init/complex1.C: New test case. Added: branches/gcc-4_0-branch/gcc/testsuite/g++.dg/init/complex1.C Modified: branches/gcc-4_0-branch/gcc/cp/ChangeLog branches/gcc-4_0-branch/gcc/cp/typeck2.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21210
[Bug c++/21210] [4.0 Regression] Trouble with __complex__ types default construction
--- Comment #12 from steven at gcc dot gnu dot org 2006-06-14 05:28 --- . -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21210
