--- Comment #23 from matz at gcc dot gnu dot org 2008-02-01 14:59 ---
I haven't removed it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35045
--- Comment #25 from matz at gcc dot gnu dot org 2008-02-02 15:01 ---
Subject: Bug 35045
Author: matz
Date: Sat Feb 2 15:00:57 2008
New Revision: 132071
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132071
Log:
PR target/35045
* postreloa
--- Comment #26 from matz at gcc dot gnu dot org 2008-02-02 15:06 ---
Fixed in trunk. Matthias: thanks for the hint with the bugnumber :-)
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from matz at gcc dot gnu dot org 2008-02-02 15:52 ---
Reduced by hand:
% cat x.cc
enum EBorderStyle { bla = 1 };
template
inline bool compareEqual(const T& t, const U& u)
{
return t == u;
}
struct S {
unsigned m_style : 4;
};
void call (S *s, EBorderStyle v
--- Comment #6 from matz at gcc dot gnu dot org 2008-02-02 16:08 ---
(written before richis comment, essentially the same info)
The compare routine doesn't need to be a template to show the bug. But it
needs to take reference parameters. The difference is in the call. E.g.
with
--- Comment #10 from matz at gcc dot gnu dot org 2008-02-02 17:47 ---
A TARGET_EXPR has the following semantics:
(1) If it's a RHS of a MODIFY_STMT (or similar), i.e.:
lhs = TARGET_EXPR
this is (for gimplifying) the same as
lhs = init
except when TREE_TYPE(ini
--- Comment #13 from matz at gcc dot gnu dot org 2008-02-04 11:48 ---
Yep, that's something the FE maintainers need to decide. From a robustness
p.o.v. I'd do it in build_target_expr, though perhaps that has speed
implications. FWIW the patch from comment #10 (with an added
--- Comment #8 from matz at gcc dot gnu dot org 2008-02-12 16:06 ---
Actually the code in var-tracking.c does handle the situation that a reg
contains multiple decls. Or better it tries to. If there weren't an
obvious bug in clobber_variable_part(). With that fixed the lo
--- Comment #7 from matz at gcc dot gnu dot org 2008-02-12 15:36 ---
The immediate problem is that the solution iterates between two orders.
On my machine (i686) it all happen around basic block 231. The even
iterations (after 128 iterations) the var-track info for bb 231 starts with
--- Comment #9 from matz at gcc dot gnu dot org 2008-02-13 14:54 ---
Subject: Bug 35065
Author: matz
Date: Wed Feb 13 14:53:59 2008
New Revision: 132286
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132286
Log:
PR debug/35065
* var-tr
--- Comment #10 from matz at gcc dot gnu dot org 2008-02-13 15:00 ---
This is fixed now.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #12 from matz at gcc dot gnu dot org 2008-02-13 16:18 ---
Whoops, sorry. I fixed the warnings in a different copy of the testcase
than the one I committed :-( Committed the right version now. (Yes, it still
tests what it should test, without the var-tracking patch it runs
--- Comment #10 from matz at gcc dot gnu dot org 2008-02-13 21:28 ---
Created an attachment (id=15145)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15145&action=view)
patch
Give this patch a test. The problem is that rs6000.c accepts all offsets
in addresses when they ar
--- Comment #14 from matz at gcc dot gnu dot org 2008-02-13 23:03 ---
Sigh. I've tested the changed testcase only on 32bit :-( Update to r132300.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35065
--- Comment #13 from matz at gcc dot gnu dot org 2008-02-14 12:55 ---
Subject: Bug 34930
Author: matz
Date: Thu Feb 14 12:54:30 2008
New Revision: 132317
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132317
Log:
PR target/34930
* fu
--- Comment #14 from matz at gcc dot gnu dot org 2008-02-14 12:55 ---
Fixed in r132317.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status
ONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at gcc dot gnu dot org
GCC target triplet: i386
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35264
--- Comment #5 from matz at gcc dot gnu dot org 2008-02-21 12:39 ---
Subject: Bug 35264
Author: matz
Date: Thu Feb 21 12:38:35 2008
New Revision: 132521
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132521
Log:
PR target/35264
* config/i38
--- Comment #6 from matz at gcc dot gnu dot org 2008-02-21 12:41 ---
Fixed in 4.3 and trunk.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from matz at gcc dot gnu dot org 2008-02-21 12:30 ---
Subject: Bug 35264
Author: matz
Date: Thu Feb 21 12:30:00 2008
New Revision: 132520
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132520
Log:
PR target/35264
* config/i38
--- Comment #8 from matz at gcc dot gnu dot org 2008-02-22 23:40 ---
I can confirm this, the code in foo is definitely wrong. When I compile
the (standard compliant, unlike the example from comment #4) with 4.2 or
4.3 on x86-64, with -O or -O2 it breaks:
% cat foo.c
long align;
int
--- Comment #9 from matz at gcc dot gnu dot org 2008-02-23 00:40 ---
Mine, have patch.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #11 from matz at gcc dot gnu dot org 2008-02-23 14:08 ---
FWIW, Torbjorn: I agree with Honza that it would be very good to see the
original testcase that segfaults on darwin. The testcases here are all of
the type where it's questionable if the behaviour is really
--- Comment #12 from matz at gcc dot gnu dot org 2008-02-23 16:15 ---
In fact I'm now convinced of the opposite, the testcases here don't show any
problem. The non-alignment of RSP at function entry in these cases is not a
bug. See the discussions at
http://gcc.gnu.
--- Comment #18 from matz at gcc dot gnu dot org 2008-02-24 19:52 ---
Umm sorry. I meant the __gmp_mt_recalc_buffer function is global in my last
comment.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35271
--- Comment #17 from matz at gcc dot gnu dot org 2008-02-24 19:50 ---
Honza: No recursion is involved here. I guess (Tege: correct me if I'm wrong)
that already the first call to __gmp_mt_recalc_buffer() from
__gmp_randget_mt() will segfault, as the first call obviously will end
--- Comment #4 from matz at gcc dot gnu dot org 2008-02-25 16:18 ---
For me it works with gcc42-4.2.1_20070724-17.1 (i686). With 4.3 it breaks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35368
--- Comment #10 from matz at gcc dot gnu dot org 2008-03-18 14:55 ---
The tree dumps already look wrong. from .130t.final_cleanup:
function_calling_listener (data)
{
:
data (data.a, data.c, data.d) [tail call];
return;
}
Note how the function pointer is replaced with the whole
--- Comment #12 from matz at gcc dot gnu dot org 2008-03-18 15:03 ---
Uros: the problem isn't cse. It's already expand which creates broken code
(it reads from and writes to (mem (plus (virtual-incoming-regs) (4)).
But it does that only because the input tree is completely
--- Comment #15 from matz at gcc dot gnu dot org 2008-03-18 15:37 ---
We can either force expanding the call address before the arguments (if
it overlaps with them) or simply validate the thing after the fact.
Validating seems a bit easier (and is in line with what is done already for
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |matz at gcc dot gnu dot org
|dot org
--- Comment #16 from matz at gcc dot gnu dot org 2008-03-19 19:15 ---
Subject: Bug 35616
Author: matz
Date: Wed Mar 19 19:15:03 2008
New Revision: 133348
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133348
Log:
PR middle-end/35616
* calls.c (exp
--- Comment #17 from matz at gcc dot gnu dot org 2008-03-19 19:38 ---
Subject: Bug 35616
Author: matz
Date: Wed Mar 19 19:37:48 2008
New Revision: 133350
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133350
Log:
Backport from mainline:
PR middle-e
--- Comment #18 from matz at gcc dot gnu dot org 2008-03-19 19:40 ---
trunk and 4.3 are fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from matz at gcc dot gnu dot org 2009-02-12 11:32 ---
I don't think it's __builtin_apply which is wrong. It's rather how it is
used in libobjc. In particular register parameters are handled wrongly.
libobjc objc_msg_sendv() simply tries to overwrit
ary: vectorizer confused by predictive commoning
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mat
--- Comment #1 from matz at gcc dot gnu dot org 2009-02-25 13:53 ---
For reference intel fortran (11.0) produces three loops, one where it uses
predictive commoning (that is used when there are only few iterations):
..B1.7: # Preds ..B1.6
movsd 8(%r8
--- Comment #21 from matz at gcc dot gnu dot org 2009-02-25 18:04 ---
The question if such transformation is or isn't worthwhile is independent from
the issue at hand (which is about the validity in the light of the new
memory model). If you find a clearly pessimizing but
--- Comment #6 from matz at gcc dot gnu dot org 2009-03-09 13:25 ---
It's also PRE that produces such patterns, so moving predcom behind
vectorization alone won't help this problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39300
--- Comment #10 from matz at gcc dot gnu dot org 2009-03-26 13:41 ---
I must be missing something, as I don't see the connection to SSA expansion
(or non-SSA expansion). AFAIU the issue is (and that often was indeed a
problem in the past with mplayer) that some transform
--- Comment #2 from matz at gcc dot gnu dot org 2009-04-01 11:45 ---
The old stack slot sharing problem. stack slot sharing really wants to
look at scopes to determine if stack variables can share the same space or
not (stack variables, not registers, those are all top-level). But
--- Comment #4 from matz at gcc dot gnu dot org 2009-04-01 14:05 ---
Yes, that's my thought too. Fixing the BLOCK_VARS when references to
variables show up in a block where they weren't before.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604
--- Comment #8 from matz at gcc dot gnu dot org 2009-04-01 14:47 ---
One other approach is to create new aliasing conflicts once we union
two stack partitions. That would inhibit any invalid (after sharing)
transformations by RTL transformations downstream (when they look at only such
--- Comment #12 from matz at gcc dot gnu dot org 2009-04-14 13:58 ---
That's only possible sometimes and hence can't be relied upon. The RHS
expression might not be available at the point of the use anymore (some
operands might have been clobbered meanwhile, remember we are
--- Comment #3 from matz at gcc dot gnu dot org 2009-04-27 11:55 ---
I have a patch.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #6 from matz at gcc dot gnu dot org 2009-04-27 13:45 ---
That's indeed the same bug as on cris. I'm working on a patch (it has to
do with promoted parameters).
--
matz at gcc dot gnu dot org changed:
What|Removed
--- Comment #8 from matz at gcc dot gnu dot org 2009-04-28 00:37 ---
> expand_phi_nodes can and will create RTL code so we need to register the RTL
> CFG hooks before calling it.
Nope, that won't fly (for the moment). expand_phi_nodes also split edges
and it's necess
--- Comment #10 from matz at gcc dot gnu dot org 2009-04-28 11:41 ---
I see. These are different base variables (a and b here), where my patch
doesn't help. Andreas Krebbels patch should fix that, except there's still
some confusion in there, see
http://gcc.gnu.org/ml/gcc-pa
--- Comment #4 from matz at gcc dot gnu dot org 2009-04-28 12:23 ---
Subject: Bug 39922
Author: matz
Date: Tue Apr 28 12:22:47 2009
New Revision: 146889
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146889
Log:
PR middle-end/39922
* tree-out
--- Comment #5 from matz at gcc dot gnu dot org 2009-04-28 12:38 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from matz at gcc dot gnu dot org 2009-04-29 00:17 ---
Andrew is right. There is no "known" alignment (or misalignment) as far
as the gimple code is concerned, only the natural alignment:
send_probe (struct outdata * outdata, struct timeval * tp)
{
struct t
--- Comment #1 from matz at gcc dot gnu dot org 2009-04-29 00:23 ---
I tested powerpc64-linux a few minutes ago (r146824) and it doesn't show
these errors. I have Andreas Krebbels patch applied, though, and it might
really make a difference. See
http://gcc.gnu.org/ml/gcc-patches
--- Comment #4 from matz at gcc dot gnu dot org 2009-04-29 09:22 ---
I didn't enable it explicitely, but Janis neither (according to the
testresults post), so it's probably default. But I did not use some
other options, in particular the --with-cpu=default32, so I'm
--- Comment #5 from matz at gcc dot gnu dot org 2009-04-29 11:07 ---
Pff, I still can't reproduce the testsuite failures, but I can reproduce the
ICE on the testcase from the initial comment. rs6000.c needs to handle
SSA_NAMEs now. I'm currently regstrapping this:
Ind
--- Comment #11 from matz at gcc dot gnu dot org 2009-04-29 11:38 ---
Thanks for the clarification. So there indeed is only one issue, that the
temporary has an aligned type.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39954
--- Comment #11 from matz at gcc dot gnu dot org 2009-04-29 17:37 ---
Subject: Bug 39927
Author: matz
Date: Wed Apr 29 17:36:21 2009
New Revision: 146982
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146982
Log:
PR middle-end/39927
PR bootstr
--- Comment #14 from matz at gcc dot gnu dot org 2009-04-29 17:37 ---
Subject: Bug 39929
Author: matz
Date: Wed Apr 29 17:36:21 2009
New Revision: 146982
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146982
Log:
PR middle-end/39927
PR bootstr
--- Comment #8 from matz at gcc dot gnu dot org 2009-04-29 17:57 ---
The patch from comment #1 had one peculiar bug, which could explain some
miscompilations. I just committed a corrected version as r146982 and
for me the struct-layout tests don't fail anymore. OTOH they we
--- Comment #11 from matz at gcc dot gnu dot org 2009-04-30 00:43 ---
The compiler I configured on a powerpc64 host with the options you use
doesn't exhibit the execute.exp fails from comment #7 for me. Neither with
unix/-m32 nor with unix/-m64 .
When I configure a compiler
--- Comment #4 from matz at gcc dot gnu dot org 2009-05-01 17:22 ---
That shouldn't happen yes. We are trying to expand
__fixunstfdi (D.1248_5)
As far as the gimple side is concerned this is a normal pass-by-value call
hence the SSA name therein is perfectly fine. But it seem
--- Comment #1 from matz at gcc dot gnu dot org 2009-05-02 02:34 ---
The assert triggers because of a real pre-existing bug. local variables
with DECL_HARD_REGISTER set must not be put into SSA form. is_gimple_reg
has to return false for them. It doesn't anymore since some chang
--- Comment #10 from matz at gcc dot gnu dot org 2009-08-20 13:48 ---
Mine.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #11 from matz at gcc dot gnu dot org 2009-08-20 15:35 ---
Fixed in r150964.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #7 from matz at gcc dot gnu dot org 2009-09-03 16:39 ---
Hmm, in a sense what forward prop is doing is at least fishy. It forwards
the casted ADDR_EXPR into some references of y_13, but not into all of them.
As y_13 is a restrict pointer this is always going to be a problem
--- Comment #9 from matz at gcc dot gnu dot org 2009-09-03 17:13 ---
Indeed. For fixing fwprop this:
--- tree-ssa-forwprop.c (Revision 151348)
+++ tree-ssa-forwprop.c (Arbeitskopie)
@@ -958,7 +958,7 @@ forward_propagate_addr_expr (tree name,
/* If the use is in a deeper loop
--- Comment #1 from matz at gcc dot gnu dot org 2009-09-07 21:23 ---
Hmm, so the ia64 backend relies on REG_POINTER for correctness, instead of
just for optimization (like e.g. ppc)? I'm not sure that's a good idea.
In any case with finding the testcase (thanks) I should
--- Comment #2 from matz at gcc dot gnu dot org 2009-09-09 00:44 ---
Subject: Bug 41268
Author: matz
Date: Wed Sep 9 00:43:36 2009
New Revision: 151544
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151544
Log:
PR middle-end/41268
* cfg
--- Comment #3 from matz at gcc dot gnu dot org 2009-09-09 00:45 ---
Testcase fixed. Steve says bootstrap is good too.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from matz at gcc dot gnu dot org 2009-09-09 15:41 ---
Even shorter:
struct ErrmsgWindow
{
virtual ~ErrmsgWindow()
{
extern int _switch_mode_errorstr;
_switch_mode_errorstr = 42;
}
};
void ShowErrorMessage(void)
{
ErrmsgWindow w;
}
The problem
--- Comment #5 from matz at gcc dot gnu dot org 2009-09-09 15:46 ---
Oh, maybe an explanation: what is expected is that such decls (externs) either
have no context set (global) or have the current function as context. For
inlining (cloning/versioning all the same) this needs to be done
--- Comment #7 from matz at gcc dot gnu dot org 2009-09-11 11:08 ---
Subject: Bug 41275
Author: matz
Date: Fri Sep 11 11:08:38 2009
New Revision: 151631
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151631
Log:
PR middle-end/41275
* tree-inline.c (rem
--- Comment #8 from matz at gcc dot gnu dot org 2009-09-11 12:13 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #13 from matz at gcc dot gnu dot org 2009-09-14 12:20 ---
Nah, not the full patch. Maybe the part that gives separate alias sets to
scalar variables. But there's plenty of time for reverting, let's try to
cobble up some other fixes first.
--
http://g
--- Comment #14 from matz at gcc dot gnu dot org 2009-09-15 15:21 ---
http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01001.html
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from matz at gcc dot gnu dot org 2009-09-15 15:53 ---
Problem is a barrier inside a basic block:
(gdb) debug_bb(bb)
...
(call_insn 7 6 8 3 builtin_unreachable-1.c:4 (call (mem:QI (symbol_ref:SI
("bar") [flags 0x41] ) [0 S1 A8])
(const_int 16 [0x10]
--- Comment #18 from matz at gcc dot gnu dot org 2009-09-16 16:12 ---
Subject: Bug 41212
Author: matz
Date: Wed Sep 16 16:12:18 2009
New Revision: 151761
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151761
Log:
PR fortran/41212
* tree.h
--- Comment #19 from matz at gcc dot gnu dot org 2009-09-16 16:13 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from matz at gcc dot gnu dot org 2009-09-16 17:03 ---
Mine. The inliner remaps types (when they are variably modified)
without caring for qualifiers or attributes, resulting in these mismatches.
I have a patch.
--
matz at gcc dot gnu dot org changed:
What
--- Comment #7 from matz at gcc dot gnu dot org 2009-09-17 11:12 ---
Subject: Bug 41347
Author: matz
Date: Thu Sep 17 11:11:58 2009
New Revision: 151799
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151799
Log:
PR middle-end/41347
--- Comment #8 from matz at gcc dot gnu dot org 2009-09-17 11:14 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from matz at gcc dot gnu dot org 2009-09-24 12:50 ---
dom forgets update_stmt at strategic places. Mine.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from matz at gcc dot gnu dot org 2009-09-25 23:57 ---
Subject: Bug 41454
Author: matz
Date: Fri Sep 25 23:57:01 2009
New Revision: 152189
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152189
Log:
PR tree-optimization/41454
* tree
--- Comment #4 from matz at gcc dot gnu dot org 2009-09-26 00:13 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from matz at gcc dot gnu dot org 2009-09-26 01:35 ---
Mine, have patch. http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01841.html
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from matz at gcc dot gnu dot org 2009-09-26 16:47 ---
Subject: Bug 40758
Author: matz
Date: Sat Sep 26 16:46:43 2009
New Revision: 152203
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152203
Log:
PR lto/40758
PR middle-end/41470
--- Comment #4 from matz at gcc dot gnu dot org 2009-09-26 16:50 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |matz at gcc dot gnu dot org
|dot org
--- Comment #3 from matz at gcc dot gnu dot org 2009-09-26 16:47 ---
Subject: Bug 41470
Author: matz
Date: Sat Sep 26 16:46:43 2009
New Revision: 152203
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152203
Log:
PR lto/40758
PR middle-end/41470
--- Comment #7 from matz at gcc dot gnu dot org 2009-09-27 21:19 ---
As per private communication, you can't do it this way. You'd loose the
effect of the inserted insn, as the jump jumps over it. You need to search
backward from the jump to the cc0 setter and insert it i
--- Comment #4 from matz at gcc dot gnu dot org 2009-09-28 12:08 ---
tree-ssa-sink doesn't sink anything with vuses in it, and if that weren't the
case then not any global store. And it isn't totally trivial to make it sink
that. It also doesn't move stuff into the
--- Comment #3 from matz at gcc dot gnu dot org 2009-10-03 22:49 ---
Found a nice testcase for exponential explosion. It's reduced from tree.c
(make_vector_type) when building with -fprofile-generate. The testcase needs
simply "-O2 -g" and takes a ridiculous amount of
--- Comment #4 from matz at gcc dot gnu dot org 2009-10-03 22:50 ---
Created an attachment (id=18699)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18699&action=view)
pr41264-test.c
Compile this with
% ./cc1 -O2 -g pr41264-test.c
and cry.
--
http://gcc.gnu.org/b
--- Comment #16 from matz at gcc dot gnu dot org 2009-10-03 23:18 ---
Created an attachment (id=18700)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18700&action=view)
pr41264-test.c
Hmm, seems I used the wrong bug report to assign a nicer testcase. Here
the comment and t
--- Comment #5 from matz at gcc dot gnu dot org 2009-10-03 23:22 ---
Hmpf, sorry, I think this bug report might be about something else. The
exponential explosion is actually tracked in PR41343. I've attached the
testcase there.
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #3 from matz at gcc dot gnu dot org 2009-10-04 22:04 ---
Gnah. remove_useless_stmts (notice how that function is called totally
unrelated to what it does) folds the statements. That's without having
referenced_vars already which is the reason for this segfault aft
--- Comment #4 from matz at gcc dot gnu dot org 2009-10-08 11:23 ---
We're (slowly) working on this.
--
matz at gcc dot gnu dot org changed:
What|Removed |
--- Comment #43 from matz at gcc dot gnu dot org 2009-10-08 11:24 ---
There already is PR31094 about this enhancement.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from matz at gcc dot gnu dot org 2009-10-08 11:26 ---
See also my mail http://gcc.gnu.org/ml/fortran/2009-08/msg00200.html
about this issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31094
--- Comment #4 from matz at gcc dot gnu dot org 2009-10-08 16:03 ---
Subject: Bug 41573
Author: matz
Date: Thu Oct 8 16:03:11 2009
New Revision: 152563
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152563
Log:
PR middle-end/41573
* bu
--- Comment #5 from matz at gcc dot gnu dot org 2009-10-09 16:04 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
101 - 200 of 411 matches
Mail list logo
