[Bug ada/10670] 'section' Machine_Attribute directive ignored
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-31 08:16 --- 'section' is not a machine attribute, it's an attribute of C-like languages. The compiler is correct in rejecting it. Use pragma Linker_Section instead. -- What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|NEW |RESOLVED Keywords|wrong-code | Resolution||INVALID Summary|gcc ignors 'pragma |'section' Machine_Attribute |Machine_Attribute' directive|directive ignored http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10670
[Bug tree-optimization/20701] [tcb] VRP does not eliminate a redundant if statement.
--- Additional Comments From kazu at cs dot umass dot edu 2005-03-31 08:20 --- I've got a preliminary patch working. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kazu at cs dot umass dot edu |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20701
[Bug tree-optimization/20640] [4.0 Regression] ICE on NULL PHI_ARG_DEF
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-31
08:28 ---
Subject: Re: [PR tree-optimization/20640] add phi args to dests of
dce-redirected edges
On Mar 31, 2005, Alexandre Oliva [EMAIL PROTECTED] wrote:
I have a gut feeling that we'll always get a PHI arg from one of the
previous successors of the src of the redirected edge, but I can't
quite prove it. What do you think?
A few seconds after posting the patch, ssa-dce-3.c failed, showing my
gut feeling was wrong. Oh well...
On Mar 30, 2005, Jeffrey A Law [EMAIL PROTECTED] wrote:
This code is triggered rarely, I would expect it to be even rarer still
for POST_DOM_BB to have PHI nodes. You could probably just ignore dead
control statements where the post dominator has PHI nodes and I doubt
it would ever be noticed.
It is noticed if we take the same path as the no-post_dom_bb,
infinite-loop case, because then the instruction that remains may
still reference variables that were deleted.
This patch, however, arranges for us to turn the edge into a
fall-through edge to its original destination should the immediate
post dominator be found to have PHI nodes.
I've also tweaked the code so as to remove all dead phi nodes before
removing all other statements, thereby improving the odds of
redirecting a dead control stmt to the post dominator.
Interestingly, the resulting code was no different for some cases I
inspected (the testcase included in the patch and ssa-dce-3.c).
That's because the edge dest bb ends up becoming a simple forwarding
block that is later removed.
As for infinite loops, I'm wondering if we should somehow try to
remove the condition from the loop. If the conditional branch is
found to be dead, it's quite possible that the set of that variable is
dead as well, and so we'd be keeping a reference to a deleted
variable. I couldn't actually exercise such an error, and I'm not
convinced it's possible, but I thought I'd bring this up. Thoughts?
Anyway, how does this patch look?
Index: gcc/ChangeLog
from Alexandre Oliva [EMAIL PROTECTED]
PR tree-optimization/20640
* tree-ssa-dce.c (remove_dead_stmt): Don't redirect edge to
post-dominator if it has phi nodes.
(eliminate_unnecessary_stmts): Remove dead phis in all blocks
before dead statements.
Index: gcc/tree-ssa-dce.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-ssa-dce.c,v
retrieving revision 2.37
diff -u -p -r2.37 tree-ssa-dce.c
--- gcc/tree-ssa-dce.c 12 Mar 2005 20:53:18 - 2.37
+++ gcc/tree-ssa-dce.c 31 Mar 2005 07:56:42 -
@@ -637,7 +637,10 @@ eliminate_unnecessary_stmts (void)
{
/* Remove dead PHI nodes. */
remove_dead_phis (bb);
+}
+ FOR_EACH_BB (bb)
+{
/* Remove dead statements. */
for (i = bsi_start (bb); ! bsi_end_p (i) ; )
{
@@ -724,6 +727,7 @@ remove_dead_stmt (block_stmt_iterator *i
if (is_ctrl_stmt (t))
{
basic_block post_dom_bb;
+
/* The post dominance info has to be up-to-date. */
gcc_assert (dom_computed[CDI_POST_DOMINATORS] == DOM_OK);
/* Get the immediate post dominator of bb. */
@@ -737,6 +741,15 @@ remove_dead_stmt (block_stmt_iterator *i
return;
}
+ /* If the post dominator block has PHI nodes, we might be unable
+to compute the right PHI args for them. Since the control
+statement is unnecessary, all edges can be regarded as
+equivalent, but we have to get rid of the condition, since it
+might reference a variable that was determined to be
+unnecessary and thus removed. */
+ if (phi_nodes (post_dom_bb))
+ post_dom_bb = EDGE_SUCC (bb, 0)-dest;
+
/* Redirect the first edge out of BB to reach POST_DOM_BB. */
redirect_edge_and_branch (EDGE_SUCC (bb, 0), post_dom_bb);
PENDING_STMT (EDGE_SUCC (bb, 0)) = NULL;
Index: gcc/testsuite/ChangeLog
from Alexandre Oliva [EMAIL PROTECTED]
PR tree-optimization/20640
* gcc.dg/torture/tree-loop-1.c: New.
Index: gcc/testsuite/gcc.dg/torture/tree-loop-1.c
===
RCS file: gcc/testsuite/gcc.dg/torture/tree-loop-1.c
diff -N gcc/testsuite/gcc.dg/torture/tree-loop-1.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ gcc/testsuite/gcc.dg/torture/tree-loop-1.c 30 Mar 2005 05:28:22 -
@@ -0,0 +1,21 @@
+/* PR tree-optimization/20640 */
+
+/* After unrolling the loop, we'd turn some conditional branches into
+ unconditional ones, but branch redirection would fail to compute
+ the PHI args for the PHI nodes in the replacement edge
+ destination, so they'd remain NULL causing crashes later on. */
+
+/* { dg-do compile } */
+
+static int a = 0;
+extern int foo (void);
+extern int *bar (void) __attribute__ ((__const__));
+
+void
+test (int x)
+{
+ int b = 10;
+ while (foo () == -1 *bar () == 4 b 0)
+--b;
+ a = x;
+}
--
[Bug tree-optimization/20640] [4.0 Regression] ICE on NULL PHI_ARG_DEF
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-31
08:41 ---
Subject: Re: [PR tree-optimization/20640] add phi args to dests of
dce-redirected edges
On Mar 30, 2005, Jeffrey A Law [EMAIL PROTECTED] wrote:
- PENDING_STMT (EDGE_SUCC (bb, 0)) = NULL;
+ flush_pending_stmts (EDGE_SUCC (bb, 0));
I'm having trouble seeing how this can be correct.
After looking at what flush_pending_stmts() actually does, I must
confess I'm disappointed. I expected it to be far smarter than it
actually is.
Here's a newer version of the patch that survived bootstrap on
x86_64-linux-gnu, with default BOOT_CFLAGS in mainline, and with
BOOT_CFLAGS='-O3 -g -funroll-all-loops' in the 4.0 branch. I found
that the 4.0 branch would fail to bootstrap even with default
BOOT_CFLAGS if I added code to flush_pending_stmts() to verify that
the PHI args actually matched the corresponding PHI nodes.
My concern is that, if the code in this patch fails and we reach the
hopefully-unreachable point, we won't be able to obtain a PHI arg very
easily. I have a gut feeling that we'll always get a PHI arg from one
of the previous successors of the src of the redirected edge, but I
can't quite prove it. What do you think?
This code is triggered rarely, I would expect it to be even rarer still
for POST_DOM_BB to have PHI nodes. You could probably just ignore dead
control statements where the post dominator has PHI nodes and I doubt
it would ever be noticed.
Index: gcc/ChangeLog
from Alexandre Oliva [EMAIL PROTECTED]
PR tree-optimization/20640
* tree-ssa-dce.c (remove_dead_stmt): Add phi args to phi nodes
affected by an edge redirection.
Index: gcc/tree-ssa-dce.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-ssa-dce.c,v
retrieving revision 2.37
diff -u -p -r2.37 tree-ssa-dce.c
--- gcc/tree-ssa-dce.c 12 Mar 2005 20:53:18 - 2.37
+++ gcc/tree-ssa-dce.c 31 Mar 2005 06:39:48 -
@@ -724,6 +724,10 @@ remove_dead_stmt (block_stmt_iterator *i
if (is_ctrl_stmt (t))
{
basic_block post_dom_bb;
+ edge e;
+ tree phi;
+ tree pending_stmts;
+
/* The post dominance info has to be up-to-date. */
gcc_assert (dom_computed[CDI_POST_DOMINATORS] == DOM_OK);
/* Get the immediate post dominator of bb. */
@@ -739,7 +743,13 @@ remove_dead_stmt (block_stmt_iterator *i
/* Redirect the first edge out of BB to reach POST_DOM_BB. */
redirect_edge_and_branch (EDGE_SUCC (bb, 0), post_dom_bb);
+
+ e = EDGE_SUCC (bb, 0);
+
+ pending_stmts = PENDING_STMT (e);
+
PENDING_STMT (EDGE_SUCC (bb, 0)) = NULL;
+
EDGE_SUCC (bb, 0)-probability = REG_BR_PROB_BASE;
EDGE_SUCC (bb, 0)-count = bb-count;
@@ -755,6 +765,76 @@ remove_dead_stmt (block_stmt_iterator *i
else
EDGE_SUCC (bb, 0)-flags = ~EDGE_FALLTHRU;
+ /* Now adjust the PHI args for the new edge in the new dest. */
+ for (phi = phi_nodes (e-dest);
+ phi;
+ phi = PHI_CHAIN (phi))
+ {
+ tree arg = NULL;
+ tree *pendp = pending_stmts;
+ tree phi1;
+ edge e1;
+ edge_iterator ei;
+
+ /* If it's already set for a variable, we're done! */
+ if (PHI_ARG_DEF (phi, e-dest_idx))
+ continue;
+
+ /* Try to locate a value in the list of PHI args collected
+while removing the old edge. */
+ while (*pendp)
+ {
+ if (SSA_NAME_VAR (PHI_RESULT (phi))
+ == SSA_NAME_VAR (TREE_PURPOSE (*pendp)))
+ {
+ arg = TREE_VALUE (*pendp);
+ *pendp = TREE_CHAIN (*pendp);
+ break;
+ }
+ pendp = TREE_CHAIN (*pendp);
+ }
+
+ if (arg)
+ {
+ add_phi_arg (phi, arg, e);
+ continue;
+ }
+
+ /* As a last resort, we can try to find ssa args in the
+other outgoing edges of the src block. */
+ FOR_EACH_EDGE (e1, ei, bb-succs)
+ {
+ if (e1 == e)
+ continue;
+
+ for (phi1 = phi_nodes (e1-dest); phi1;
+ phi1 = PHI_CHAIN (phi1))
+ {
+ if (SSA_NAME_VAR (PHI_RESULT (phi1))
+ == SSA_NAME_VAR (PHI_RESULT (phi)))
+ {
+ arg = PHI_ARG_DEF (phi1, e1-dest_idx);
+ break;
+ }
+ }
+
+ if (arg)
+ break;
+ }
+
+ if (arg)
+ {
+ add_phi_arg (phi, arg, e);
+ continue;
+ }
+
+ /* There's a slight possibility that we won't have been able
+to find a PHI arg in any of the previously-existing
+outgoing edges. Should this ever happen, we'd have to
+scan the BB or its preds
[Bug bootstrap/20692] configuring libgfortan infinite loop
--- Additional Comments From pfelecan at acm dot org 2005-03-31 09:10 --- The version of libgmp is 4.1.4. I'll contact the maintainer of the package to know the build options, if he run the tests... and report back -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20692
[Bug tree-optimization/20701] [tcb] VRP does not eliminate a redundant if statement.
-- What|Removed |Added OtherBugsDependingO||20702 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20701
[Bug tree-optimization/20702] New: [tcb] ASSERT_EXPRs are not inserted when a certain if statement is present.
Consider:
typedef struct {
int code;
} *rtx;
extern void next_active_insn (rtx);
int
can_combine_p (rtx insn, rtx succ, rtx elt)
{
rtx set = 0;
if (succ)
next_active_insn (succ);
else
next_active_insn (insn);
if (insn-code == 3)
set = insn;
else if (insn-code == 5)
{
set = elt;
if (set == 0)
return 0;
}
else
return 0;
if (set == 0)
return 1;
return 0;
}
Here is the dump after inserting ASSERT_EXPRs.
can_combine_p (insn, succ, elt)
{
struct
{
int code;
} * set;
int D.1141;
int D.1140;
bb 0:
if (succ_4 != 0B) goto L0; else goto L1;
L0:;
succ_8 = ASSERT_EXPR succ_4, succ_4 != 0B;
next_active_insn (succ_8);
goto bb 3 (L2);
L1:;
succ_9 = 0B;
next_active_insn (insn_5);
L2:;
D.1140_6 = insn_5-code;
if (D.1140_6 == 3) goto L9; else goto L4;
L4:;
D.1140_10 = D.1140_6;
if (D.1140_10 == 5) goto L5; else goto L13;
L5:;
if (elt_12 == 0B) goto L13; else goto L9;
# set_1 = PHI insn_5(3), elt_12(5);
L9:;
if (set_1 == 0B) goto L11; else goto L13;
L11:;
# D.1141_2 = PHI 0(5), 0(4), 1(7), 0(6);
L13:;
return D.1141_2;
}
Note that we don't have ASSERT_EXPRs for if statements and memory access
that happen later in the function.
I've got a preliminary patch working.
--
Summary: [tcb] ASSERT_EXPRs are not inserted when a certain if
statement is present.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: dnovillo at redhat dot com,gcc-bugs at gcc dot gnu dot
org
BugsThisDependsOn: 20701
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20702
[Bug tree-optimization/20702] [tcb] ASSERT_EXPRs are not inserted when a certain if statement is present.
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kazu at cs dot umass dot edu |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20702
[Bug c/17855] [4.0/4.1 Regression] modification of function struct return not diagnosed
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-03-31 10:09 --- [resend of comment#6 which did not get emailed out] The reason I don't consider compiling into an abort to be suitable here is that the problem could in principle arise with more complicated code where the pointer in the array reference isn't immediately syntactically from a non-lvalue array but has been through other assignments, casts, etc., the optimizers then removing these so that at some point an assignment to such an array needs to be expanded. Ultimately I think these cases may most reliably be handled by having the front end create explicit addressable temporaries for every non-lvalue structure containing an array (mapping non-lvalue-struct to *(tmp = non-lvalue-struct, tmp)), but I think putting the special cases in the gimplifier makes more sense in the context of fixing now a regression we have now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17855
[Bug c/20689] strict aliasing with temporary variable never gives warnings
--- Additional Comments From varun0005 at gmail dot com 2005-03-31 10:18
---
please ignore previous code and consider this piece as example ... problem is
same .the exact programs are following and command line was gcc -Wall -O2
test1.c test2.cIn this why test1.c not giving warning but test2.c giving
violation of strict-aliasing warning.
//test1.c
#include stdio.h
#include stdlib.h
int main()
{ int *i;
float **q;
int **r;
i =(int *)malloc(sizeof(int));
r=i;
q=(float **)r;
return 0;
}
//test2.c
int main(){
int *i;
float **q;
i =(int *)malloc(sizeof(int));
q= (float **) i;
return 0;
}
--
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20689
[Bug ada/10671] improve error message for named notation used in pragma
--- Additional Comments From charlet at gcc dot gnu dot org 2005-03-31 10:28 --- There is no bug here: named notation is not supported for this pragma. Named notation is also not supported for any of the Ada defined pragmas, so there is no reason to expect this to work. We'll see if the error message can be improved in this case, but that's the only thing to be considered in this report. -- What|Removed |Added Severity|normal |enhancement Summary|gcc ignors named notation |improve error message for |for pragma arguments|named notation used in ||pragma http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10671
[Bug target/20611] duplicate label for inlined function referencing TLS
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-31 11:33 --- Subject: Bug 20611 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-31 11:33:18 Modified files: gcc: ChangeLog gcc/config/rs6000: rs6000.c gcc/testsuite : ChangeLog Log message: PR target/20611 * config/rs6000/rs6000.md (load_toc_v4_PIC_1b): Remove inline label operand. Remove (use (unspec..)). Don't emit a label on the offset word. * config/rs6000/rs6000.c (rs6000_legitimize_tls_address): Don't generate inline label for load_toc_v4_PIC_1b. (rs6000_emit_load_toc_table): Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.8049r2=2.8050 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000.c.diff?cvsroot=gccr1=1.800r2=1.801 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5242r2=1.5243 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20611
[Bug target/20611] duplicate label for inlined function referencing TLS
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-31 11:34 --- Subject: Bug 20611 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-31 11:34:20 Modified files: gcc/config/rs6000: rs6000.md Log message: PR target/20611 missed from last commit. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000.md.diff?cvsroot=gccr1=1.357r2=1.358 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20611
[Bug c++/19761] -Winit-self doesn't work anymore
--- Additional Comments From oliverst at online dot de 2005-03-31 11:35 --- I tried it again with this GCC: Using built-in specs. Target: i686-pc-mingw32 Configured with: /datal/gcc/gcc/configure --prefix=/datal/gcc/build/wingcc --build=i686-pc-linux-gnu --host=i686-pc-mingw32 --target=i686-pc-mingw32 --enable-languages=c,c++,java --with-gcc --with-gnu-as --with-gnu-ld --enable-threads=win32 --disable-nls --disable-win32-registry --disable-shared --disable-debug --without-newlib --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchronization --enable-sjlj-exceptions --enable-libgcj-multifile --enable-libgcj-mingw-osapi=ansi Thread model: win32 gcc version 4.0.0 20050324 (prerelease) And I still get the same results as mentioned in comment 3. I also tried it with -Wno-unitialized to see, if that warning somehow disables the -Winit-self, but I still don't get the expected warning. Sorry, but reopening this bug. Maybe we should get a third opinion (another guy with a 3.4.x or 4.0.x GCC) on this. Also attaching the preprocessed source. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WORKSFORME | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19761
[Bug c++/19761] -Winit-self doesn't work anymore
--- Additional Comments From oliverst at online dot de 2005-03-31 11:36 --- Created an attachment (id=8504) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8504action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19761
[Bug target/20611] duplicate label for inlined function referencing TLS
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-31 11:39 --- Subject: Bug 20611 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-03-31 11:39:34 Modified files: gcc: ChangeLog gcc/config/rs6000: rs6000.c rs6000.md Log message: PR target/20611 * config/rs6000/rs6000.md (load_toc_v4_PIC_1b): Remove inline label operand. Remove (use (unspec..)). Don't emit a label on the offset word. * config/rs6000/rs6000.c (rs6000_legitimize_tls_address): Don't generate inline label for load_toc_v4_PIC_1b. (rs6000_emit_load_toc_table): Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.7592.2.101r2=2.7592.2.102 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.788.2.3r2=1.788.2.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000.md.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.350.2.1r2=1.350.2.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20611
[Bug target/20611] duplicate label for inlined function referencing TLS
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-31 11:46 --- Subject: Bug 20611 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-03-31 11:45:51 Modified files: gcc: ChangeLog gcc/config/rs6000: rs6000.c rs6000.md Log message: PR target/20611 * config/rs6000/rs6000.md (load_toc_v4_PIC_1b): Remove inline label operand. Remove (use (unspec..)). Don't emit a label on the offset word. * config/rs6000/rs6000.c (rs6000_legitimize_tls_address): Don't generate inline label for load_toc_v4_PIC_1b. (rs6000_emit_load_toc_table): Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=2.2326.2.829r2=2.2326.2.830 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.576.2.42r2=1.576.2.43 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000.md.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.284.4.17r2=1.284.4.18 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20611
[Bug target/20611] duplicate label for inlined function referencing TLS
--- Additional Comments From amodra at bigpond dot net dot au 2005-03-31 11:48 --- Fixed on 3.4, 4.0 and mainline. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20611
[Bug c++/19761] -Winit-self doesn't work anymore
-- What|Removed |Added Attachment #8504|application/octet-stream|text/plain mime type|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19761
[Bug target/20611] duplicate label for inlined function referencing TLS
-- What|Removed |Added Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20611
[Bug tree-optimization/18403] FAILs to vectorize testcases on ppc64-linux
--- Additional Comments From dorit at il dot ibm dot com 2005-03-31 12:58
---
Another testcase that exhibits a similar problem: vect-5.f90
(patch: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02840.html)
On powerpc64-linux (lp64) the second loop is not vectorized because the data-
references analysis in the vectorizer can't extract the evolution from the
access_function returned by the evolution analyzer for the accesses to array b.
In lp32 mode the access function we get from the evolution analyzer is simpler,
and the loop gets vectorized.
== Access function for each case:
lp64: (int8) {i_3, +, 1}_3 + -1
lp32: {i_3 + -1, +, 1}_3
== Vectorizer dataref analysis report for each case:
vect-5.f90:3: note: Results of object analysis for: b
lp64: base_address: b
offset: (unnamed type) ((int8) {i_3, +, 1}_3 * 4 + -4)
step: 0
base aligned 1
lp32: base_address: b
offset: (unnamed type) (i_3 * 4 + -4)
step: 4
base aligned 1
== Tree dump for each case:
lp64:
# j_5 = PHI i_3(15), j_55(18);
L32:;
D.712_48 = (int8) j_5;
D.713_49 = D.712_48 + 7;
D.714_51 = D.712_48 + -1;
D.715_52 = b[D.714_51];
a[D.713_49] = D.715_52;
j_55 = j_5 + 1;
if (j_5 == D.688_44) goto L46; else goto L47;
lp32:
# j_6 = PHI i_4(21), j_40(25);
L34:;
D.518_35 = j_6 + 7;
D.523_36 = a[D.518_35];
D.519_37 = j_6 + -1;
D.520_38 = b[D.519_37];
if (D.523_36 != D.520_38) goto L19; else goto L52;
== Evolution analyzer dumps for each case:
lp64:
(analyze_array
(ref = b[D.714_51];
)
(analyze_scalar_evolution
(loop_nb = 3)
(scalar = D.714_51)
(get_scalar_evolution
(scalar = D.714_51)
(scalar_evolution = (int8) {i_3, +, 1}_3 + -1))
(set_scalar_evolution
(scalar = D.714_51)
(scalar_evolution = (int8) {i_3, +, 1}_3 + -1))
)
(instantiate_parameters
(loop_nb = 3)
(chrec = (int8) {i_3, +, 1}_3 + -1)
(analyze_scalar_evolution
(loop_nb = 2)
(scalar = i_3)
(get_scalar_evolution
(scalar = i_3)
(scalar_evolution = {1, +, 1}_2))
(set_scalar_evolution
(scalar = i_3)
(scalar_evolution = {1, +, 1}_2))
)
(res = (int8) {{1, +, 1}_2, +, 1}_3 + -1))
)
lp32:
(analyze_array
(ref = b[D.835_47];
)
(analyze_scalar_evolution
(loop_nb = 3)
(scalar = D.835_47)
(get_scalar_evolution
(scalar = D.835_47)
(scalar_evolution = {i_3 + -1, +, 1}_3))
(set_scalar_evolution
(scalar = D.835_47)
(scalar_evolution = {i_3 + -1, +, 1}_3))
)
(instantiate_parameters
(loop_nb = 3)
(chrec = {i_3 + -1, +, 1}_3)
(analyze_scalar_evolution
(loop_nb = 2)
(scalar = i_3)
(get_scalar_evolution
(scalar = i_3)
(scalar_evolution = {1, +, 1}_2))
(set_scalar_evolution
(scalar = i_3)
(scalar_evolution = {1, +, 1}_2))
)
(res = {{0, +, 1}_2, +, 1}_3))
)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18403
[Bug middle-end/15700] [4.0 Regression] [unit-at-a-time] Inlining problem leads to miscompilation of glibc
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-31 13:02 --- Subject: Bug 15700 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-31 13:02:37 Modified files: gcc/testsuite/gcc.c-torture/compile: 2009-1.c 2009-2.c Log message: Fix fallout from PR middle-end/15700: * gcc.c-torture/compile/2009-1.c: Take __USER_LABEL_PREFIX__ into account. * gcc.c-torture/compile/2009-2.c: Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/2009-1.c.diff?cvsroot=gccr1=1.2r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/2009-2.c.diff?cvsroot=gccr1=1.2r2=1.3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15700
[Bug c++/20700] x86_64 code bloat on templates
--- Additional Comments From giovannibajo at libero dot it 2005-03-31 13:19 --- Reopen the bug report if it happens again. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20700
[Bug c++/18644] [3.3/3.4/4.0/4.1 regression] -Wsynth warning in complex
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-31 14:21 --- Subject: Bug 18644 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-31 14:21:20 Modified files: gcc: ChangeLog gcc/cp : ChangeLog call.c gcc/doc: invoke.texi Log message: doc/ PR c++/18644 * doc/invoke.texi (-Wsynth): Don't document, as it now is void of semantics. cp/ PR c++/18644 * call.c (build_new_op): Remove check for -Wsynth. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.8050r2=2.8051 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4680r2=1.4681 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/call.c.diff?cvsroot=gccr1=1.531r2=1.532 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/invoke.texi.diff?cvsroot=gccr1=1.594r2=1.595 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18644
[Bug libfortran/20660] INQUIRE incorrectly reports the existence of UNITS
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-31 15:30 --- Subject: Bug 20660 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-31 15:30:06 Modified files: gcc/testsuite : ChangeLog libgfortran: ChangeLog libgfortran/io : inquire.c transfer.c Added files: gcc/testsuite/gfortran.dg: negative_unit.f Log message: PR libfortran/20660 * io/inquire.c (inquire_via_unit): Non-opened units should still be reported by an INQUIRE statement as existing. * io/transfer.c (data_transfer_init): Never accept negative units. PR libfortran/20660 * gfortran.dg/negative_unit.f: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5243r2=1.5244 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/negative_unit.f.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gccr1=1.179r2=1.180 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/inquire.c.diff?cvsroot=gccr1=1.9r2=1.10 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/transfer.c.diff?cvsroot=gccr1=1.33r2=1.34 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20660
[Bug libfortran/20660] INQUIRE incorrectly reports the existence of UNITS
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-31 15:36 --- Subject: Bug 20660 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-03-31 15:36:11 Modified files: gcc/testsuite : ChangeLog libgfortran: ChangeLog libgfortran/io : inquire.c transfer.c Added files: gcc/testsuite/gfortran.dg: negative_unit.f Log message: PR libfortran/20660 * io/inquire.c (inquire_via_unit): Non-opened units should still be reported by an INQUIRE statement as existing. * io/transfer.c (data_transfer_init): Never accept negative units. PR libfortran/20660 * gfortran.dg/negative_unit.f: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.82r2=1.5084.2.83 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/negative_unit.f.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.163.2.12r2=1.163.2.13 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/inquire.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.9r2=1.9.8.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/transfer.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.32.2.1r2=1.32.2.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20660
[Bug libfortran/20660] INQUIRE incorrectly reports the existence of UNITS
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-03-31 16:27 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20660
[Bug tree-optimization/20703] New: [tcb] FRE does not remove a fully redundant load.
Consider:
int
foo (int *array)
{
if (array[1] != 0)
return array[1];
return 0;
}
Here is the result after the first DCE, which is immediately after FRE.
foo (array)
{
int D.1134;
int D.1133;
int * D.1132;
bb 0:
D.1132_3 = array_2 + 4B;
D.1133_4 = *D.1132_3;
if (D.1133_4 != 0) goto L0; else goto L2;
L0:;
D.1132_7 = D.1132_3;
D.1134_8 = *D.1132_7;
# D.1134_1 = PHI D.1134_8(1), 0(0);
L2:;
return D.1134_1;
}
Note that the second load still stays there.
If I run copy-prop and FRE one more time immediately after running them
for the first time, then the second run of FRE can remove the redundant load.
By running the copy prop one more time, the second load becomes:
D.1134_8 = *D.1132_3;
Then then I guess it's easy for FRE to eliminate this load because
RHS looks exactly like the first load.
--
Summary: [tcb] FRE does not remove a fully redundant load.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: dnovillo at redhat dot com,gcc-bugs at gcc dot gnu dot
org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20703
[Bug libfortran/19155] blanks not treated as zeros in 'E' format read (NIST FM110.FOR)
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-03-31 16:38 --- Summary of what other compilers do: Portland, Sun and IBM accept it, while NEC and MIPSpro reject it. My position would be: we go with the Standard. Can we somehow have confirmation that Steve's interpretation is correct (not an official interp, but maybe a well-advised opinion on comp.lang.fortran)? -- What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19155
[Bug tree-optimization/20701] [tcb] VRP does not eliminate a redundant if statement.
-- What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20701
[Bug target/20045] gcc.dg/ia64-fptr-1.c fails on ia64-hpux
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-31 16:53 --- Subject: Bug 20045 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-31 16:53:19 Modified files: gcc/testsuite : ChangeLog gcc/testsuite/gcc.dg: ia64-fptr-1.c Log message: PR target/20045 * gcc.dg/ia64-fptr-1.c: Run only on linux. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5244r2=1.5245 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/ia64-fptr-1.c.diff?cvsroot=gccr1=1.1r2=1.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20045
[Bug target/20045] gcc.dg/ia64-fptr-1.c fails on ia64-hpux
--- Additional Comments From sje at cup dot hp dot com 2005-03-31 17:04 --- Fixed by not running the test suite on HP-UX. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20045
[Bug java/20704] New: CNI code is called/loaded without any security checks
Classes using native CNI methods are loaded without any extra security checks. When a class uses native JNI methods it needs to make sure the appropriate library containing the JNI functions are loaded. Which means that at a certain point the call chain must have had a RuntimePermission(loadLibrary) because Runtime.loadLibrary() has to be called. For classes using CNI native methods no such requirement is needed which means that CNI native code can be called through such classes without a security check for the RuntimePermission being done. A solution could be to have the static initializer of such classes using CNI native code make a security check themselves for RuntimePermission(loadLibrary). This does mean we need some way to simulate the trusted way of calling Runtime.loadLibrary() through a PrivilegedAction (which means the class itself needs to have the RuntimePermission, but the rest of the call chain doesn't). -- Summary: CNI code is called/loaded without any security checks Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mark at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20704
[Bug libgcj/20704] CNI code is called/loaded without any security checks
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-31 17:30 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Component|java|libgcj Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-31 17:30:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20704
[Bug c++/19203] [3.4/4.0/4.1 Regression] Partial ordering failure between function reference and generic const reference
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-31 17:36 --- Subject: Bug 19203 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-31 17:36:18 Modified files: gcc/cp : ChangeLog call.c cp-tree.h pt.c gcc/testsuite : ChangeLog gcc/testsuite/g++.dg/parse: ambig3.C Added files: gcc/testsuite/g++.dg/template: spec20.C spec21.C Log message: cp: PR c++/19203, implement DR 214 * call.c (joust): Use more_specialized_fn. * cp-tree.h (DEDUCE_ORDER): Remove. (more_specialized): Replace with ... (more_specialized_fn): ... this. * pt.c (maybe_adjust_types_for_deduction): Remove DEDUCE_ORDER case. (type_unification_real): Remove DEDUCE_ORDER case. (more_specialized): Replace with ... (more_specialized_fn): ... this. Implement DR 214. (most_specialized_instantiation): Use get_bindings_real directly. testsuite: PR c++/19203, DR 214 * g++.dg/parse/ambig3.C: Not ambiguous. * g++.dg/template/spec20.C: New. * g++.dg/template/spec21.C: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gccr1=1.4681r2=1.4682 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/call.c.diff?cvsroot=gccr1=1.532r2=1.533 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gccr1=1.1114r2=1.1115 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gccr1=1.986r2=1.987 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5245r2=1.5246 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/ambig3.C.diff?cvsroot=gccr1=1.1r2=1.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/spec20.C.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/spec21.C.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19203
[Bug c++/19203] [3.4/4.0/4.1 Regression] Partial ordering failure between function reference and generic const reference
--- Additional Comments From nathan at gcc dot gnu dot org 2005-03-31 17:47 --- 2005-03-31 Nathan Sidwell [EMAIL PROTECTED] PR c++/19203, implement DR 214 * call.c (joust): Use more_specialized_fn. * cp-tree.h (DEDUCE_ORDER): Remove. (more_specialized): Replace with ... (more_specialized_fn): ... this. * pt.c (maybe_adjust_types_for_deduction): Remove DEDUCE_ORDER case. (type_unification_real): Remove DEDUCE_ORDER case. (more_specialized): Replace with ... (more_specialized_fn): ... this. Implement DR 214. (most_specialized_instantiation): Use get_bindings_real directly. fixed on mainline. See http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02862.html for comments about 4.0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19203
[Bug tree-optimization/20640] [4.0 Regression] ICE on NULL PHI_ARG_DEF
--- Additional Comments From law at redhat dot com 2005-03-31 17:59 --- Subject: Re: [PR tree-optimization/20640] add phi args to dests of dce-redirected edges On Thu, 2005-03-31 at 05:26 -0300, Alexandre Oliva wrote: On Mar 31, 2005, Alexandre Oliva [EMAIL PROTECTED] wrote: I have a gut feeling that we'll always get a PHI arg from one of the previous successors of the src of the redirected edge, but I can't quite prove it. What do you think? A few seconds after posting the patch, ssa-dce-3.c failed, showing my gut feeling was wrong. Oh well... Worse yet, you can't depend on testing SSA_NAME_VAR to find your PHI node. It's rare, but possible to have two PHIs in the same block with the same underlying SSA_NAME_VAR. It's also possible to get a mis-match between the underlying var for PHI_RESULT and PHI_ARG_... At which point you're probably coming to realize that updating PHI nodes is a non-trivial problem in the general case. Fundamentally, this code is trying to optimize the case where selection of either arm of the conditional has no visible impact on the behavior of the program. So while the arms may contain code, we know that we could execute either arm or even bypass both completely and get correct code. From this you can derive that any assignments in the arms must be dead and any PHIs those assignments feed must also be dead, and so on. So we could proceed by first eliminating all the assignments and PHI nodes which are dead, then we proceed to eliminate the dead control statements. As you noted, this makes it less likely that there will be any PHIs in the post-dominator node. It also makes it easier to update any PHIs which remain in the post-dominator node. For each PHI in post_dominator_bb For each PHI argument if (dominated_by_p (arg-edge-src, control_statement_bb)) arg-value is the value we want to associate with the new edge from control_statement_bb to post_dominator_bb At least I think that or something similar should do the trick. I haven't finished my first coke for the day, but it feels right. Alternately, we could go with your second approach which is to remove all the dead phis first, then avoid redirecting to a post-dominator with phis (instead redirecting to the fall-thru edge). On Mar 30, 2005, Jeffrey A Law [EMAIL PROTECTED] wrote: This code is triggered rarely, I would expect it to be even rarer still for POST_DOM_BB to have PHI nodes. You could probably just ignore dead control statements where the post dominator has PHI nodes and I doubt it would ever be noticed. It is noticed if we take the same path as the no-post_dom_bb, infinite-loop case, because then the instruction that remains may still reference variables that were deleted. We can change the COND_EXPR_COND to be anything we want -- remember, the whole point is that we've determined that the branch itself is dead -- we can take either arm and nothing can tell the difference. So we could just change the condition to if (0) and we would be safe. Or we could just delete the condition and fall-thru as you've suggested. The only advantage of redirecting to the post-dominator block is that we have less cleanup work to do later. It's not clear to me if there is an advantage (compile-time wise) to redirecting to the post-dominator block or just redirecting to the fall-thru and letting cleanup_tree_cfg remove the forwarders. This patch, however, arranges for us to turn the edge into a fall-through edge to its original destination should the immediate post dominator be found to have PHI nodes. Which would be fine. I've also tweaked the code so as to remove all dead phi nodes before removing all other statements, thereby improving the odds of redirecting a dead control stmt to the post dominator. Right. That was a good piece of insight. I think this is really the key step for either solution (update the post-dominator phis, or just redirect to the fall-thru edge). Interestingly, the resulting code was no different for some cases I inspected (the testcase included in the patch and ssa-dce-3.c). That's because the edge dest bb ends up becoming a simple forwarding block that is later removed. Precisely. Again, redirecting to the post-dominator is just avoiding some of the later cleanup work. As for infinite loops, I'm wondering if we should somehow try to remove the condition from the loop. If the conditional branch is found to be dead, it's quite possible that the set of that variable is dead as well, and so we'd be keeping a reference to a deleted variable. I couldn't actually exercise such an error, and I'm not convinced it's possible, but I thought I'd bring this up. Thoughts? I'm not sure either. I haven't thought much about the infinite loop cases much. It would seem to me that we could/should remove the conditional as well. Presumably this code is meant to handle the case where the conditional will
[Bug tree-optimization/20640] [4.0 Regression] ICE on NULL PHI_ARG_DEF
--- Additional Comments From law at redhat dot com 2005-03-31 18:00 --- Subject: Re: [PR tree-optimization/20640] add phi args to dests of dce-redirected edges On Thu, 2005-03-31 at 05:26 -0300, Alexandre Oliva wrote: On Mar 31, 2005, Alexandre Oliva [EMAIL PROTECTED] wrote: [ ... ] Anyway, how does this patch look? Index: gcc/ChangeLog from Alexandre Oliva [EMAIL PROTECTED] PR tree-optimization/20640 * tree-ssa-dce.c (remove_dead_stmt): Don't redirect edge to post-dominator if it has phi nodes. (eliminate_unnecessary_stmts): Remove dead phis in all blocks before dead statements. BTW, if you want to go forward with this version, it looks OK to me assuming it passes bootstrapping and regression testing. Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20640
[Bug c++/19203] [3.4/4.0/4.1 Regression] Partial ordering failure between function reference and generic const reference
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-03-31 18:04 --- I've retargeted this patch for GCC 4.0.1. After it's aged on the mainline, we can apply it to the 4.0 branch. -- What|Removed |Added Target Milestone|3.4.4 |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19203
[Bug c/20705] New: -pthread should enable all options required to use pthreads on all platforms
The lack of a portable option to enable pthreads is a significant annoyance. It is mentioned in bug , and bug 18788 is also relevant, but those are separate bugs. See also the discussion in http://groups.google.co.uk/groups?threadm=8764z82jd8.fsf%40qrnik.zagroda. Workaround: use autoconf with http://ac-archive.sourceforge.net/Installed_Packages/acx_pthread.html. This is not suitable for all projects. -- Summary: -pthread should enable all options required to use pthreads on all platforms Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: david dot nospam dot hopwood at blueyonder dot co dot uk CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20705
[Bug libgcj/20704] CNI code is called/loaded without any security checks
--- Additional Comments From mckinlay at redhat dot com 2005-03-31 19:01 --- I'm not sure that this should really be considered a bug. loadLibrary() must obviously be a privileged function because arbritary code could be loaded by calling it (possibly from an insecure context), but having/calling a CNI method does not in itself cause anything to be loaded. A CNI method implementation must already be loaded by being explicitly linked into an application binary. To put it another way: is there a way that insecure bytecode can actually turn this into an exploit? Perhaps some kind of validity check is needed at link time to ensure that native method declarations in insecure code do not link against an inappropriate native method (for example, make sure that insecure classes cannot call themselves gnu.foo.Whatever and get linked to a private CNI method implementation in another class of the same name). In any case, checking the loadLibrary permission is the wrong approach because there is no library actually being loaded. The correct behaviour would be to simply not link the method if something isn't right, resulting in an UnsatisfiedLinkError. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20704
Re: Old times
This is a multi-part message in MIME format. Norman Virus Control a supprim le message original qui contenait le virus [EMAIL PROTECTED]
[Bug driver/20705] -pthread should enable all options required to use pthreads on all platforms
-- What|Removed |Added Component|c |driver http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20705
[Bug driver/20705] -pthread should enable all options required to use pthreads on all platforms
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-31 19:34 --- What I would like to see is that the targets just enable pthreads by default and forget about these flags. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20705
[Bug libstdc++/20706] New: string::reserve severe performance regression
I am experiencing severe performance degradation using string::reserve() under
libstdc++.so.6 (g++ 3.4.3) that was not present under libstdc++.so.5 (g++
3.2.2).
Here is a test program that exhibits the problem:
#include string
#include assert.h
int
main(int argc, char **argv)
{
unsigned long size = 1024 * 1024;
char *data = (char *) malloc(size);
for (unsigned long i = 0; i size; i++) {
data[i] = 32 + (i % 94);
}
std::string dest;
for (unsigned long i = 0; i size; i++) {
dest.reserve(dest.length() + 1);
dest.append(data[i],1);
}
assert(dest.length() == size);
assert(dest == std::string(data,size));
}
Running linked against libstdc++.so.5 returns:
$ time ./test_reserve
real0m0.128s
user0m0.109s
sys 0m0.010s
Running linked against libstdc++.so.6 returns:
$ time ./test_reserve
real13m34.776s
user5m44.582s
sys 7m50.130s
On a 3.20GHz Xeon!!
g++ -v on RH8.0 returns:
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--host=i386-redhat-linux
Thread model: posix
gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
g++ -v on RHEL4 returns:
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux
Thread model: posix
gcc version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)
--
Summary: string::reserve severe performance regression
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ftr at highstreetnetworks dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20706
[Bug debug/19345] [4.0/4.1 Regression] Segmentation fault with VLA and inlining and dwarf2
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-01-27 03:00:22 |2005-03-31 20:28:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19345
[Bug libfortran/20471] Segmentation fault on read after backspace and rewind
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-03-31 20:32 --- Same patch also fixes PR 20068 (that is, all backspace bugs), but it does introduce a regression (gfortran.fortran-torture/execute/backspace.f90). -- What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Last reconfirmed|2005-03-15 22:58:12 |2005-03-31 20:32:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20471
[Bug debug/19345] [4.0/4.1 Regression] Segmentation fault with VLA and inlining and dwarf2
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-31
20:47 ---
Subject: [PR debug/19345] remap TYPE_STUB_DECL during inlining
TYPE_STUB_DECL was NULL in the testcase given in the bug report
because tree inlining failed to remap TYPE_STUB_DECL. This patch
reverts the patch that hides the problem, that AFAICT was checked in
by accident, and installs a proper (IMHO :-) fix. Bootstrapping on
amd64-linux-gnu. Ok to install if it passes regtesting?
Index: gcc/ChangeLog
from Alexandre Oliva [EMAIL PROTECTED]
PR debug/19345
* dwarf2out.c (add_abstract_origin_attribute): Revert accidental?
check in from 2005-03-03 for debug/20253.
* tree-inline.c (remap_type): Remap TYPE_STUB_DECL.
(remap_decl): Insert type decl in map earlier.
Index: gcc/dwarf2out.c
===
RCS file: /cvs/gcc/gcc/gcc/dwarf2out.c,v
retrieving revision 1.576
diff -u -p -r1.576 dwarf2out.c
--- gcc/dwarf2out.c 30 Mar 2005 23:08:17 - 1.576
+++ gcc/dwarf2out.c 31 Mar 2005 20:43:20 -
@@ -10465,11 +10465,7 @@ add_abstract_origin_attribute (dw_die_re
if (TYPE_P (fn))
fn = TYPE_STUB_DECL (fn);
- /* TYPE_STUB_DECL may have given us a NULL, which decl_function_context
-won't like. */
- if (fn)
- fn = decl_function_context (fn);
-
+ fn = decl_function_context (fn);
if (fn)
dwarf2out_abstract_function (fn);
}
Index: gcc/tree-inline.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-inline.c,v
retrieving revision 1.175
diff -u -p -r1.175 tree-inline.c
--- gcc/tree-inline.c 30 Mar 2005 21:34:27 - 1.175
+++ gcc/tree-inline.c 31 Mar 2005 20:43:22 -
@@ -172,6 +172,11 @@ remap_decl (tree decl, inline_data *id)
/* Make a copy of the variable or label. */
tree t = copy_decl_for_inlining (decl, fn, VARRAY_TREE (id-fns, 0));
+ /* Remember it, so that if we encounter this local entity again
+we can reuse this copy. Do this early becuase remap_type may
+need this decl for TYPE_STUB_DECL. */
+ insert_decl_map (id, decl, t);
+
/* Remap types, if necessary. */
TREE_TYPE (t) = remap_type (TREE_TYPE (t), id);
if (TREE_CODE (t) == TYPE_DECL)
@@ -214,9 +219,6 @@ remap_decl (tree decl, inline_data *id)
}
#endif
- /* Remember it, so that if we encounter this local entity
-again we can reuse this copy. */
- insert_decl_map (id, decl, t);
return t;
}
@@ -285,6 +287,9 @@ remap_type (tree type, inline_data *id)
TYPE_NEXT_VARIANT (new) = NULL;
}
+ if (TYPE_STUB_DECL (type))
+TYPE_STUB_DECL (new) = remap_decl (TYPE_STUB_DECL (type), id);
+
/* Lazily create pointer and reference types. */
TYPE_POINTER_TO (new) = NULL;
TYPE_REFERENCE_TO (new) = NULL;
Index: gcc/testsuite/ChangeLog
from Daniel Berlin [EMAIL PROTECTED]
* gcc.dg/pr19345.c: New test.
Index: gcc/testsuite/gcc.dg/pr19345.c
===
RCS file: gcc/testsuite/gcc.dg/pr19345.c
diff -N gcc/testsuite/gcc.dg/pr19345.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ gcc/testsuite/gcc.dg/pr19345.c 31 Mar 2005 20:43:37 -
@@ -0,0 +1,12 @@
+/* We shouldn't crash trying to produce the inlined structure type die debug
info. */
+/* { dg-do compile } */
+/* { dg-options -O1 -g } */
+inline void bar(char a[], unsigned int l)
+{
+ asm volatile ( :: m ( *(struct {char x[l]; } *)a));
+}
+
+void foo(void)
+{
+ bar (0, 0);
+}
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist [EMAIL PROTECTED], gnu.org}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19345
[Bug libstdc++/20706] string::reserve severe performance regression
--- Additional Comments From pcarlini at suse dot de 2005-03-31 20:56 --- This is not a bug, it's the intended, standard conforming, behavior. This is happening because, when you call dest.reserve(dest.length() + 1) the string class is actually *shrinking* the capacity of the string, which at that point, is *larger* than dest.length + 1. This implies slow reallocations. In 3.4 (at variance with 3.3) we honor shrink requests, which happen when reserve is passed an argument which is smaller than the current capacity. This is very useful to spare memory, in some applications. In order to fix the problem, make sure to always pass to reserve an argument bigger than the current capacity. *** This bug has been marked as a duplicate of 20114 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20706
[Bug libstdc++/20114] Non-monotonic behavior of string::reserve
--- Additional Comments From pcarlini at suse dot de 2005-03-31 20:57 --- *** Bug 20706 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||ftr at highstreetnetworks ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20114
[Bug libstdc++/20706] string::reserve severe performance regression
--- Additional Comments From pcarlini at suse dot de 2005-03-31 21:14 --- I should also add, that, in general, your snippet could be simpler, without penalizing the performance: typically reserve is only called once, at the outset, if we can estimate in advance the final size of the string. Otherwise, internally, the implementation is *automatically* able to quickly grow the capacity to satisfy efficiently a series of consecutive append: in our implement the capacity automatically doubles every time is reached by the size of the growing string. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20706
[Bug libstdc++/20690] Bug in std::vector
--- Additional Comments From pcarlini at suse dot de 2005-03-31 21:15 --- So closing it. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20690
[Bug debug/19345] [4.0/4.1 Regression] Segmentation fault with VLA and inlining and dwarf2
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-03-31 21:26 --- Subject: Re: [PR debug/19345] remap TYPE_STUB_DECL during inlining On Thu, 31 Mar 2005, Alexandre Oliva wrote: TYPE_STUB_DECL was NULL in the testcase given in the bug report because tree inlining failed to remap TYPE_STUB_DECL. This patch reverts the patch that hides the problem, that AFAICT was checked in by accident, Did i check it in, or someone else? If i did it, it was definitely by accident. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19345
[Bug tree-optimization/15089] local register variable with a specified register is bad
--- Additional Comments From rth at gcc dot gnu dot org 2005-03-31 21:36 --- I've just re-read the Extended Asm section and find that the approprate docs have been present since revision 1.222 (hp 29-Sep-04). -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15089
[Bug target/19974] incorrect complex division on ia-64 with flag_complex_method = 2
--- Additional Comments From rth at gcc dot gnu dot org 2005-03-31 21:38 --- I'm going to assume there's no bug here. Re-open if you disagree. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19974
[Bug fortran/5900] [g77 gfortran] Lapack regressions since g77 2.95.2
-- Bug 5900 depends on bug 19974, which changed state. Bug 19974 Summary: incorrect complex division on ia-64 with flag_complex_method = 2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19974 What|Old Value |New Value Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900
[Bug middle-end/18902] Naive (default) complex division algorithm
-- Bug 18902 depends on bug 19974, which changed state. Bug 19974 Summary: incorrect complex division on ia-64 with flag_complex_method = 2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19974 What|Old Value |New Value Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18902
[Bug debug/19406] [4.0/4.1 Regression] ICE: in force_decl_die, at dwarf2out.c:12442
--- Additional Comments From rth at gcc dot gnu dot org 2005-03-31 21:41 --- Well, if we're already doing this, and the debugger handles it, then far be it from me to stand in the way of progress. Patch is ok everywhere. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19406
[Bug libfortran/19155] blanks not treated as zeros in 'E' format read (NIST FM110.FOR)
--- Additional Comments From kargl at gcc dot gnu dot org 2005-03-31 21:43 --- I posted a short question to c.l.f. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19155
[Bug rtl-optimization/20290] [4.0/4.1 Regression] Miscompilation on ppc/arm with -Os
--- Additional Comments From rth at gcc dot gnu dot org 2005-03-31 21:46 --- Subject: Re: [PR rtl-optimization/20290] loop body doesn't run in every iteration if exit test is the loop entry point On Sun, Mar 20, 2005 at 03:33:49PM -0300, Alexandre Oliva wrote: * loop.c (for_each_insn_in_loop): Don't assume the loop body runs in every iteration if the entry point is the exit test. Ok. r~ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20290
[Bug c++/15036] [3.4 regression] Performance and code size regression compared to 3.3
--- Additional Comments From rth at gcc dot gnu dot org 2005-03-31 21:53 --- The code generated by gcc 4.0 is significantly improved: .L2: fldl-8(%ebx,%ecx,8) incl%ecx fld %st(0) fmull (%edx) fxch%st(1) fmull 8(%edx) fxch%st(1) addl$16, %edx fstpl (%eax) fstpl 8(%eax) addl$16, %eax cmpl$1001, %ecx jne .L2 I have no plans to address this for the 3.4 branch. -- What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX Target Milestone|3.4.4 |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15036
[Bug driver/20705] -pthread should enable all options required to use pthreads on all platforms
--- Additional Comments From david dot nospam dot hopwood at blueyonder dot co dot uk 2005-03-31 22:04 --- pthreads isn't necessarily available, or needs to be optional, on embedded platforms. I agree that on some platforms it would make sense for pthreads to be enabled by default. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20705
[Bug middle-end/20491] [4.0/4.1 Regression] internal compiler error: in subreg_regno_offset, at rtlanal.c:3042
--- Additional Comments From rth at gcc dot gnu dot org 2005-03-31 22:09
---
Subject: Re: [PR middle-end/20491] combine generates bad subregs
On Wed, Mar 30, 2005 at 04:27:50PM -0300, Alexandre Oliva wrote:
- else
+ else if (REG_P (y))
{
/* Simplify_subreg can't handle some REG cases, but we have to. */
unsigned int regno = subreg_regno (x);
The next line is
gcc_assert (REG_P (y));
you should remove that. Ok with that change.
r~
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20491
[Bug c/17855] [4.0/4.1 Regression] modification of function struct return not diagnosed
--- Additional Comments From rth at gcc dot gnu dot org 2005-03-31 22:16 --- Patch is ok. I would prefer that this (eventually) be handled by the front end, but certainly this approach is appropriate for fixing the regression in 4.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17855
[Bug middle-end/20442] [3.3/3.4/4.0 Regression] problem mixing C++ exceptions and setjmp/longjmp with SJLJ exceptions
--- Additional Comments From rth at gcc dot gnu dot org 2005-03-31 22:18 --- Apparently fixed in the original source. -- What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20442
[Bug java/20526] gij -X reports no options are recognized, while -Xmx and -Xms seem to be
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-31 22:47:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20526
[Bug SWING/20707] New: JList not respecting LayoutOrientation
Test case:
import javax.swing.*;
import java.awt.*;
public class testlist
{
public static void main(String[] args)
{
JFrame f = new JFrame();
DefaultListModel v = new DefaultListModel();
v.addElement(alsdkfj);
v.addElement(lasdkfj);
v.addElement(owieur);
v.addElement(weoiru);
v.addElement(lskdfj);
v.addElement(zcxvn);
v.addElement(zxcvlkzvm);
JList a = new JList(v);
a.setVisibleRowCount(2);
JScrollPane p = new JScrollPane(a);
a.setLayoutOrientation(JList.HORIZONTAL_WRAP);
f.getContentPane().add(p);
f.pack();
f.show();
}
}
The items in the list should be wrapped vertically, not horizontally.
--
Summary: JList not respecting LayoutOrientation
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: SWING
AssignedTo: graydon at redhat dot com
ReportedBy: kho at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20707
[Bug middle-end/20524] [4.0/4.1 regression] Alias failures on ARM, CRIS, MMIX
--- Additional Comments From rth at gcc dot gnu dot org 2005-03-31 23:05 --- The 2009-1.c failure has been fixed by Joern by taking the USER_LABEL_PREFIX into account. I can't replicate the reported mmix double output failure with 20040323-1.c; I can only presume that it's been fixed by one of the followup patches to the aliasing code. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20524
[Bug rtl-optimization/20331] [3.4/4.0/4.1 Regression] Wrong code generation for the argument of the pure function in PIC
--- Additional Comments From rth at gcc dot gnu dot org 2005-03-31 23:21 --- Is this fixed now that a patch has been applied? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20331
[Bug target/20632] GCC should avoid generating F- and B-unit NOPs
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-31 23:26 --- Subject: Bug 20632 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-31 23:26:35 Modified files: gcc: ChangeLog genautomata.c gcc/doc: md.texi gcc/config/ia64: ia64.c Log message: 2005-03-31 Vladimir Makarov [EMAIL PROTECTED] PR target/20632 * genautomata.c (first_cycle_unit_presence): Check all alternative states for unit presence. * doc/md.texi: Remove remark about impossibility to query unit presence in non nondeterministic automaton state. * config/ia64/ia64.c (get_template): Change order of unit querying. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.8060r2=2.8061 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/genautomata.c.diff?cvsroot=gccr1=1.61r2=1.62 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/md.texi.diff?cvsroot=gccr1=1.126r2=1.127 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64.c.diff?cvsroot=gccr1=1.352r2=1.353 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20632
[Bug c/17855] [4.0/4.1 Regression] modification of function struct return not diagnosed
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-31 23:34 --- Subject: Bug 17855 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-03-31 23:34:45 Modified files: gcc: ChangeLog gimplify.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/compile: struct-non-lval-1.c struct-non-lval-2.c struct-non-lval-3.c Log message: PR c/17855 * gimplify.c (gimplify_expr): Create a temporary for lvalue COND_EXPR and CALL_EXPR. testsuite: * gcc.c-torture/compile/struct-non-lval-1.c, gcc.c-torture/compile/struct-non-lval-2.c, gcc.c-torture/compile/struct-non-lval-3.c: New tests. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.8061r2=2.8062 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gimplify.c.diff?cvsroot=gccr1=2.120r2=2.121 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5254r2=1.5255 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/struct-non-lval-1.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/struct-non-lval-2.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/struct-non-lval-3.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17855
[Bug c/17855] [4.0/4.1 Regression] modification of function struct return not diagnosed
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-03-31 23:37 --- Subject: Bug 17855 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-03-31 23:37:11 Modified files: gcc: ChangeLog gimplify.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/compile: struct-non-lval-1.c struct-non-lval-2.c struct-non-lval-3.c Log message: PR c/17855 * gimplify.c (gimplify_expr): Create a temporary for lvalue COND_EXPR and CALL_EXPR. testsuite: * gcc.c-torture/compile/struct-non-lval-1.c, gcc.c-torture/compile/struct-non-lval-2.c, gcc.c-torture/compile/struct-non-lval-3.c: New tests. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.7592.2.104r2=2.7592.2.105 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gimplify.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.113.2.2r2=2.113.2.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.83r2=1.5084.2.84 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/struct-non-lval-1.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/struct-non-lval-2.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/struct-non-lval-3.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17855
[Bug c/16989] [meta-bug] C99 conformance bugs
-- Bug 16989 depends on bug 17855, which changed state. Bug 17855 Summary: [4.0/4.1 Regression] modification of function struct return not diagnosed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17855 What|Old Value |New Value Status|NEW |ASSIGNED Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16989
[Bug c/17855] [4.0/4.1 Regression] modification of function struct return not diagnosed
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-03-31 23:42 --- Fixed on 4.0 branch and mainline. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17855
[Bug c/20368] [4.0/4.1 Regression] internal compiler error: tree check: expected function_type or method_type, have integer_type in start_function, at c-decl.c:5777
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-03-31 23:43 --- Fixed on 4.0 branch and mainline. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20368
[Bug rtl-optimization/20331] [3.4/4.0/4.1 Regression] Wrong code generation for the argument of the pure function in PIC
--- Additional Comments From kkojima at gcc dot gnu dot org 2005-03-31 23:57 --- On 4.1, yes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20331
[Bug target/20093] [4.0/4.1 Regression] 23_containers/deque/cons/2.cc execution test fails on ia64-hpux, -milp32
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-03-31 23:59 --- Created an attachment (id=8505) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8505action=view) Further cut-down testcase This test no longer depends on libv3test or the testsuite headers. It passes with -O, segfaults with -O2 or -O -fforce-mem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20093
[Bug rtl-optimization/20331] [3.4/4.0/4.1 Regression] Wrong code generation for the argument of the pure function in PIC
--- Additional Comments From rth at gcc dot gnu dot org 2005-04-01 00:00 --- It's marked as a 4.0 regression. Do you plan on applying the patch there? If not, we should simply close the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20331
[Bug c++/18644] [3.3/3.4/4.0 regression] -Wsynth warning in complex
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-01 00:28 --- Subject: Bug 18644 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-01 00:28:00 Modified files: gcc/testsuite : ChangeLog gcc/testsuite/g++.old-deja/g++.jason: warning9.C Log message: PR c++/18644 * g++.old-deja/g++.jason/warning9.C (struct A, main): Adjust Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5255r2=1.5256 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.old-deja/g++.jason/warning9.C.diff?cvsroot=gccr1=1.3r2=1.4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18644
[Bug target/20342] [4.0/4.1 regression] ICE in spill_failure, at reload1.c:1872
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-03-11 21:14:21 |2005-04-01 00:33:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20342
[Bug target/20447] ICE in output_operand: invalid expression as operand
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-01 00:33:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20447
[Bug debug/19345] [4.0/4.1 Regression] Segmentation fault with VLA and inlining and dwarf2
--- Additional Comments From aoliva at gcc dot gnu dot org 2005-04-01 00:37 --- Subject: Re: [PR debug/19345] remap TYPE_STUB_DECL during inlining On Mar 31, 2005, Daniel Berlin [EMAIL PROTECTED] wrote: Did i check it in, or someone else? You did, along with the patch mentioned in the ChangeLog. If i did it, it was definitely by accident. Thanks for the confirmation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19345
[Bug tree-optimization/20703] [tcb] FRE does not remove a fully redundant load.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-01 00:41 --- Confirmed. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-01 00:41:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20703
[Bug rtl-optimization/20331] [3.4/4.0/4.1 Regression] Wrong code generation for the argument of the pure function in PIC
--- Additional Comments From kkojima at gcc dot gnu dot org 2005-04-01 00:51 --- It causes the failure only for sh64 target and can be found only at 4.x java runtime for that target on which 4.0 jave doesn't work without many other patches. So there would be no reason to apply it to 4.0 and it'd be enough to close this PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20331
[Bug middle-end/20524] [4.0/4.1 regression] Alias failures on ARM, CRIS, MMIX
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2005-04-01 01:06 --- Subject: Re: [4.0/4.1 regression] Alias failures on ARM, CRIS, MMIX I can't replicate the reported mmix double output failure with 20040323-1.c; I can only presume that it's been fixed by one of the followup patches to the aliasing code. The failure noted in PR 20553 is now fixed on hppa64-hp-hpux11. However, we are still left with the followin minor regression on hppa2.0w-hp-hpux11: FAIL: gcc.c-torture/compile/2009-1.c -O0 (test for excess errors) FAIL: gcc.c-torture/compile/2009-1.c -O1 (test for excess errors) FAIL: gcc.c-torture/compile/2009-1.c -O2 (test for excess errors) FAIL: gcc.c-torture/compile/2009-1.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.c-torture/compile/2009-1.c -O3 -g (test for excess errors) FAIL: gcc.c-torture/compile/2009-1.c -Os (test for excess errors) FAIL: gcc.c-torture/compile/2009-2.c -O0 (test for excess errors) FAIL: gcc.c-torture/compile/2009-2.c -O1 (test for excess errors) FAIL: gcc.c-torture/compile/2009-2.c -O2 (test for excess errors) FAIL: gcc.c-torture/compile/2009-2.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.c-torture/compile/2009-2.c -O3 -g (test for excess errors) FAIL: gcc.c-torture/compile/2009-2.c -Os (test for excess errors) FAIL: gcc.c-torture/compile/981001-2.c -O0 (test for excess errors) FAIL: gcc.c-torture/compile/981001-2.c -O1 (test for excess errors) FAIL: gcc.c-torture/compile/981001-2.c -O2 (test for excess errors) FAIL: gcc.c-torture/compile/981001-2.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.c-torture/compile/981001-2.c -O3 -g (test for excess errors) FAIL: gcc.c-torture/compile/981001-2.c -Os (test for excess errors) These now fail because of the warning: Executing on host: /mnt/gnu/gcc-3.3/objdir/gcc/xgcc -B/mnt/gnu/gcc-3.3/objdir/gc c/ -O3 -g -w -c -o 981001-2.o /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.c-tortu re/compile/981001-2.c(timeout = 300) /mnt/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.c-torture/compile/981001-2.c:12: error: a lias definitions not supported in this configuration These used to pass because the alias was output together with the definition. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20524
[Bug rtl-optimization/20331] [3.4/4.0/4.1 Regression] Wrong code generation for the argument of the pure function in PIC
--- Additional Comments From rth at gcc dot gnu dot org 2005-04-01 01:17 --- Fine. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20331
[Bug target/20632] GCC should avoid generating F- and B-unit NOPs
--- Additional Comments From wilson at gcc dot gnu dot org 2005-04-01 01:35 --- IA-64. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |wilson at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-01 01:35:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20632
[Bug target/20632] GCC should avoid generating F- and B-unit NOPs
--- Additional Comments From wilson at gcc dot gnu dot org 2005-04-01 01:35 --- Fixed by Vlad's patch. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20632
[Bug c++/20505] [4.0/4.1 Regression] internal error when compiling with -ggdb2 and no error with -ggdb1
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-01 03:58 --- Subject: Bug 20505 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-01 03:58:44 Modified files: gcc: ChangeLog dwarf2out.c Log message: Handle static const initializers that contain arithmetic. PR c++/20505 * dwarf2out.c (rtl_for_decl_init): New function. (rtl_for_decl_location): Extracted from here. (tree_add_const_value_attribute): Call rtl_for_decl_init and add_const_value_attribute. Delete initializer_constant_valid_p call. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.8063r2=2.8064 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/dwarf2out.c.diff?cvsroot=gccr1=1.578r2=1.579 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20505
[Bug c++/20505] [4.0/4.1 Regression] internal error when compiling with -ggdb2 and no error with -ggdb1
--- Additional Comments From wilson at gcc dot gnu dot org 2005-04-01 04:04 --- Fixed on mainline. Still needs to be fixed on the gcc-4.0 branch, which I assume Nathan is doing. I had to back off a bit from my earlier plans. Aggregate types and constructor initializers pose complications that don't appear to be worth fixing, so I only handle integral types, scalar real types, and STRING_CST. I commonized the code in rtl_for_decl_location and tree_add_const_value_attribute so that they both work the same. The testcase by the way isn't portable. It requires that int and pointer be the same size. I had to do s/int/long to make it work on my ia64 and x86_64 systems. But still that assumes long and pointers are the same size which is not true for all ABIs supported by all targets. This is why I didn't already add the testcase to the testsuite on mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20505
[Bug middle-end/20442] [3.3/3.4/4.0 Regression] problem mixing C++ exceptions and setjmp/longjmp with SJLJ exceptions
--- Additional Comments From paulthomas2 at wanadoo dot fr 2005-04-01 04:52 --- Subject: Re: [3.3/3.4/4.0 Regression] problem mixing C++ exceptions and setjmp/longjmp with SJLJ exceptions Yes, indeed. John Eaton sends apologies. Paul T -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20442
[Bug c/20708] New: strict aliasing warning
since in case where you are doing float **q=(void *)i then
according to strict-aliasing rules we get warning: dereferencing type-punned
pointer will break strict-aliasing rules , but same thing if done using a
temporary variable then why strict-aliasing warning doesn't appear.. According
to my understanding of strict aliasing if some unqualified version of pointer is
pointing to the address space then it is violating strict aliasing rule. So in
second case also float ** pointer is pointing to the int address space then why
strict aliasing rules are not violated. If ther is some error in my
understanding of strict aliasing then please inform .
.the exact programs are following and command line was gcc -Wall -O2
test1.c test2.cIn this why test1.c not giving warning but test2.c giving
violation of strict-aliasing warning.
//test1.c
#include stdio.h
#include stdlib.h
int main()
{ int *i;
float **q;
int **r;
i =(int *)malloc(sizeof(int));
r=i;
q=(float **)r;
return 0;
}
//test2.c
int main(){
int *i;
float **q;
i =(int *)malloc(sizeof(int));
q= (float **) i;
return 0;
}
--
Summary: strict aliasing warning
Product: gcc
Version: 3.3.4
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: varun0005 at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20708
[Bug c/20708] strict aliasing warning
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-01 05:37 --- Casting to void* first, makes the aliasing warning go way. This is expected behavior. Realy the only undefinedness is when you access via two different types. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20708
[Bug c/20709] New: strict aliasing warning with float pointer pointing to int pointer
since in case where you are doing float **q=(float **)i then
according to strict-aliasing rules we get warning: dereferencing type-punned
pointer will break strict-aliasing rules , but same thing if done using a
temporary variable then why strict-aliasing warning doesn't appear.. According
to my understanding of strict aliasing if some unqualified version of pointer is
pointing to the address space then it is violating strict aliasing rule. So in
second case also float ** pointer is pointing to the int address space then why
strict aliasing rules are not violated. If ther is some error in my
understanding of strict aliasing then please inform .
.the exact programs are following and command line was gcc -Wall -O2
test1.c test2.cIn this why test1.c not giving warning but test2.c giving
violation of strict-aliasing warning.
//test1.c
#include stdio.h
#include stdlib.h
int main()
{ int *i;
float **q;
int **r;
i =(int *)malloc(sizeof(int));
r=i;
q=(float **)r;
return 0;
}
//test2.c
int main(){
int *i;
float **q;
i =(int *)malloc(sizeof(int));
q= (float **) i;
return 0;
}
--
Summary: strict aliasing warning with float pointer pointing to
int pointer
Product: gcc
Version: 3.3.4
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: varun0005 at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20709
[Bug c++/19159] [4.0/4.1 Regression] Undefined symbol: vtable for __cxxabiv1::__vmi_class_type_info
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-04-01 06:23 --- Dave -- I've finally got a new version of the patch. I've played with it some, and I feel like it ought to work, but maybe I'm still missing something. If it doesn't work, would you mind attached preprocessed source for tinfo.cc and tinfo2.cc from libsupc++? These are the files where the type info vtables ought to be defined. That would make it easier for me to experiment with things in an AIX cross compiler. Thanks! -- Mark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19159
[Bug middle-end/20524] [4.0/4.1 regression] Alias failures on ARM, CRIS, MMIX
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-01 07:06 --- Subject: Bug 20524 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-01 07:06:37 Modified files: gcc/testsuite : ChangeLog gcc/testsuite/gcc.dg: alias-7.c Log message: PR middle-end/20524 * gcc.dg/alias-7.c: Prefix asm-declared name with __USER_LABEL_PREFIX__. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5256r2=1.5257 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/alias-7.c.diff?cvsroot=gccr1=1.1r2=1.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20524
[Bug debug/19406] [4.0/4.1 Regression] ICE: in force_decl_die, at dwarf2out.c:12442
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-01 07:47 --- Subject: Bug 19406 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-04-01 07:47:27 Modified files: gcc: ChangeLog dwarf2out.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/debug: using1.C Log message: PR c++/19406 * dwarf2out.c (gen_type_die_for_member): Handle FIELD_DECL. (dwarf2out_imported_module_or_decl): Use gen_type_die_for_member for FIELD_DECLs. * g++.dg/debug/using1.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.8065r2=2.8066 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/dwarf2out.c.diff?cvsroot=gccr1=1.579r2=1.580 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5257r2=1.5258 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/debug/using1.C.diff?cvsroot=gccr1=1.1r2=1.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19406
[Bug debug/19406] [4.0/4.1 Regression] ICE: in force_decl_die, at dwarf2out.c:12442
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-04-01 07:51 --- Subject: Bug 19406 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-04-01 07:51:17 Modified files: gcc: ChangeLog dwarf2out.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/debug: using1.C Log message: PR c++/19406 * dwarf2out.c (gen_type_die_for_member): Handle FIELD_DECL. (dwarf2out_imported_module_or_decl): Use gen_type_die_for_member for FIELD_DECLs. * g++.dg/debug/using1.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.7592.2.106r2=2.7592.2.107 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/dwarf2out.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.570.2.4r2=1.570.2.5 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.84r2=1.5084.2.85 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/debug/using1.C.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.2.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19406
[Bug debug/19406] [4.0/4.1 Regression] ICE: in force_decl_die, at dwarf2out.c:12442
--- Additional Comments From jakub at gcc dot gnu dot org 2005-04-01 07:54 --- Fixed in CVS. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19406
