--- Comment #4 from matz at gcc dot gnu dot org 2010-09-20 11:07 ---
Whoops. Yeah, I only added x86_64-*-* to the vect_perm targets. Obviously,
as sse2 is active by default for the vectorizer testsuite I also need to
add the i?86-*-* targets. H.J., can you try with this patch
--- Comment #4 from matz at gcc dot gnu dot org 2010-09-20 13:17 ---
Yeah, probably some fold_convert is missing in reverse_vec_elements() in case
the type of the args or the return type of the chosen builtin decl don't
exactly match.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #6 from matz at gcc dot gnu dot org 2010-09-20 14:12 ---
Subject: Bug 45706
Author: matz
Date: Mon Sep 20 14:12:04 2010
New Revision: 164433
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164433
Log:
PR testsuite/45706
* lib/target-supports.exp
--- Comment #7 from matz at gcc dot gnu dot org 2010-09-20 14:14 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #8 from matz at gcc dot gnu dot org 2010-09-20 14:45 ---
Subject: Bug 45706
Author: matz
Date: Mon Sep 20 14:45:30 2010
New Revision: 164435
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164435
Log:
PR testsuite/45706
* gcc.dg/vect/pr43432.c: Don't
--- Comment #3 from matz at gcc dot gnu dot org 2010-09-17 13:26 ---
Subject: Bug 43432
Author: matz
Date: Fri Sep 17 13:26:43 2010
New Revision: 164367
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164367
Log:
PR tree-optimization/43432
* tree-vect-data-refs.c
--- Comment #7 from matz at gcc dot gnu dot org 2010-09-17 13:45 ---
It might have been exposed by that revision, but that merely points out
a deficiency in RTL if conversion. The final gimple code doesn't have
explicit jumps in the inner loop, but uses cond_expr:
bb 3:
# s_22 = PHI
--- Comment #1 from matz at gcc dot gnu dot org 2010-09-17 16:12 ---
This passes for me, even in -m32 mode (if -msse is added, like vect.exp
does):
% ./cc1 -ftree-vectorize -fno-vect-cost-model -msse2 -O2 \
vect-114.c -ftree-vectorizer-verbose=2 21 | grep note:
vect-114.c:13: note
--- Comment #2 from matz at gcc dot gnu dot org 2010-09-13 14:21 ---
Uh, I just disabled tree-sinking in some cases. This can't be directly
the reason for the problem, rather it must have uncovered a latent problem.
Will try to investigate.
--
http://gcc.gnu.org/bugzilla
--- Comment #3 from matz at gcc dot gnu dot org 2010-09-08 12:35 ---
Subject: Bug 33244
Author: matz
Date: Wed Sep 8 12:34:52 2010
New Revision: 163998
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163998
Log:
PR tree-optimization/33244
* tree-ssa-sink.c
--- Comment #8 from matz at gcc dot gnu dot org 2010-09-08 12:40 ---
Subject: Bug 43430
Author: matz
Date: Wed Sep 8 12:40:24 2010
New Revision: 163999
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163999
Log:
PR tree-optimization/43430
* tree-vect-stmts.c
--- Comment #7 from matz at gcc dot gnu dot org 2010-09-07 13:24 ---
The remaining problem is the support for ncopies 1 in
vectorizable_condition. http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00550.html
implements this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43430
--- Comment #2 from matz at gcc dot gnu dot org 2010-09-07 13:27 ---
The patch at http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00548.html
implements support for consecutive loads with negative step. It will
vectorize the first testcase. But not the second one because it only
handled
--- Comment #5 from matz at gcc dot gnu dot org 2010-09-07 13:42 ---
Since Ira implemented unaligned support in SLP mode we get somewhat further,
but not much. If complete unrolling is active that we can't disambiguate
between *s and *(s+stride). That is correct because stride
--- Comment #2 from matz at gcc dot gnu dot org 2010-09-07 14:41 ---
Since the fix for PR44710 we can if-convert the conditions in the inner loop.
With http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00542.html we also
make sure that the latch block isn't filled, which in turn
--- Comment #4 from matz at gcc dot gnu dot org 2010-09-03 14:43 ---
Subject: Bug 45415
Author: matz
Date: Fri Sep 3 14:42:46 2010
New Revision: 163822
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163822
Log:
PR middle-end/45415
* tree-sra.c (sra_modify_assign
--- Comment #5 from matz at gcc dot gnu dot org 2010-09-03 14:46 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from matz at gcc dot gnu dot org 2010-09-02 12:58 ---
Mine. I'm adding some checking code too.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at gcc dot gnu dot org
GCC host triplet: x86_64-linux
http://gcc.gnu.org
--- Comment #5 from matz at gcc dot gnu dot org 2010-08-15 21:07 ---
First, yes, the work-around from the official POSIX man-pages is alias-unsafe.
They added this example because ISO C doesn't allow conversion of void*
pointers to function pointer, but dlsym returns a void* pointer
--- Comment #8 from matz at gcc dot gnu dot org 2010-08-16 00:55 ---
Well, okay, (3) indeed is valid ISO C (no warning) and works on POSIX 2008.
I'd find it very awkward to write such work-around for (1) just so the
warning in strict ISO C mode is silenced. I find this case different
--- Comment #35 from matz at gcc dot gnu dot org 2010-08-13 13:00 ---
char* p1=(char*)0x3000; // address not pointing to any C-object in the C99
sense
char* p2=(char*)0x4000; // address not pointing to any C-object in the C99
sense
Can GCC users trust that p2-p1 will always
--- Comment #36 from matz at gcc dot gnu dot org 2010-08-13 13:14 ---
If you include real segmentation
like on 80286, where there's no linear relationship between effective
address and segment+offset, subtraction would have been prohibitively
expensive to implement anyway
--- Comment #41 from matz at gcc dot gnu dot org 2010-08-13 15:18 ---
You should really adjust your glasses if you want to continue trolling with
the high standards we're used to meanwhile:
What in the words real segmentation like on 286, where there's no linear
relationship
--- Comment #42 from matz at gcc dot gnu dot org 2010-08-13 15:25 ---
[ ] Yes
[x] No
Thanks. The comunity will be alerted to this. I'll get back to you when
your name is in some famous place associated with this claim.
That's very good. Though I'm a bit confused because you
--- Comment #51 from matz at gcc dot gnu dot org 2010-08-14 01:26 ---
There you go, you are now famous.
http://en.wikipedia.org/wiki/GNU_Compiler_Collection#Criticism
Thank you, that's encouraging, I just hope the language of that article won't
be changed too much to also mention
--- Comment #10 from matz at gcc dot gnu dot org 2010-08-12 16:00 ---
Ahh, it's just so entertaining.
C99 is a language, cdecl a calling convention. There is no 'cdecl compiler',
it makes no sense to speak about such a thing. cdecl is a calling convention
for function written in all
--- Comment #27 from matz at gcc dot gnu dot org 2010-08-12 18:05 ---
Oh, this fun. Enjoyable, really! ;-)
So, you admit that MSVC does in fact miscompile your perfectly fine cdecl
code, if you request optimization from it? How bad is that of them?
Terrible! I would consider
--- Comment #33 from matz at gcc dot gnu dot org 2010-08-12 18:56 ---
Don't talk about what you don't know, you clearly know much less about the
old days than me.
Well, I'll grant you that you know many wondrous and astounding facts,
indeed. Let me just answer one random sentence
--- Comment #20 from matz at gcc dot gnu dot org 2010-08-11 16:10 ---
A conforming variant of what you probably are trying to code is:
#include stdio.h
#include stdarg.h
void format_indirect(char* dst_buffer, size_t
--- Comment #9 from matz at gcc dot gnu dot org 2010-07-26 15:06 ---
Here's a testcase (nicer in the sense of not requiring inlining) that shows
the current compiler botching the nrv - retslot optimizations:
struct S {int x, y, makemelarge[5];};
S __attribute__((noinline)) f (S s
--- Comment #25 from matz at gcc dot gnu dot org 2010-07-07 11:15 ---
Due to SSA form the alias information reflects dependencies only between
accesses as if it ignores back edges. Hence any transformation that
transforms a back edge into a forward edge, or moves code over back edges
--- Comment #29 from matz at gcc dot gnu dot org 2010-07-07 12:10 ---
[just for completeness to not lose the thought:]
Thinking about this some more (triggered by the problem of not having nice
back edges in irreducible loops), it's not really the back edges that are
interesting
--- Comment #16 from matz at gcc dot gnu dot org 2010-06-30 16:34 ---
Subject: Bug 44699
Author: matz
Date: Wed Jun 30 16:34:22 2010
New Revision: 161614
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161614
Log:
PR bootstrap/44699
* tree-vrp.c (vrp_finalize
--- Comment #17 from matz at gcc dot gnu dot org 2010-06-30 16:54 ---
Testcases are fixed. And according to
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg03137.html
we can probably also assume the bootstrap fail is fixed.
--
matz at gcc dot gnu dot org changed:
What
--- Comment #3 from matz at gcc dot gnu dot org 2010-06-29 11:31 ---
Can you perhaps run the testsuite without bootstrapping
(configure --disable-bootstrap; make; make check) to see if there occurs some
more obvious bug than a miscompilation of genmodes? Debugging bootstrap
--- Comment #7 from matz at gcc dot gnu dot org 2010-06-29 13:47 ---
Is /opt/gcc/gcc4.6bw/bin/gcc a bootstrapped compiler or one created without
bootstrapping?
The initial comment didn't reveal it, so maybe my assumption that it's a
miscompiled cc1 is wrong. So, just to be crystal
--- Comment #9 from matz at gcc dot gnu dot org 2010-06-29 14:48 ---
Yes, but I'm asking if it was a bootstrapped compiler (in difference to one
built with configuring with --disable-bootstrap) or not.
If it was a bootstrapped compiler, are you saying that bootstrap fails with
r161501
--- Comment #11 from matz at gcc dot gnu dot org 2010-06-29 15:15 ---
I can reproduce now. It's also the non-bootstrapped compiler failing with
the testcase, thanks for that. I'm on it.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from matz at gcc dot gnu dot org 2010-06-28 15:14 ---
Subject: Bug 44592
Author: matz
Date: Mon Jun 28 15:14:31 2010
New Revision: 161496
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161496
Log:
PR middle-end/44592
* gimple-fold.c
--- Comment #6 from matz at gcc dot gnu dot org 2010-06-28 15:16 ---
Fixed for 4.6, waiting a bit for 4.5.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from matz at gcc dot gnu dot org 2010-06-25 15:34 ---
Indeed. Mine.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #2 from matz at gcc dot gnu dot org 2010-06-18 15:58 ---
It's not SSA expand (might be exposed by it, don't know), but the
bug is pre-existing already in 4.3:
long unsigned int D.2219;
struct S116 va_arg_tmp.3;
...
addr.0 = va_arg_tmp.3;
addr.4 = (long unsigned int
--- Comment #1 from matz at gcc dot gnu dot org 2010-06-15 11:19 ---
We have a slightly problematic ordering issue here. Here's what I
think should be made the case:
DECL_ALIGN should not matter after expansion, we have MEM_ALIGN for that.
(and for calculating offsets from stack
--- Comment #4 from matz at gcc dot gnu dot org 2010-06-15 13:40 ---
Can you try to instead do the stack-estimation only when really_expand is
false? The issue is, we see all variables (or we _should_ see) exactly twice,
once for estimation, once for generating the DECL_RTL. The code
--- Comment #5 from matz at gcc dot gnu dot org 2010-06-15 13:50 ---
Oh, and yes, I agree that in expand_one_stack_var_at (only called when
really_expand == true) we should limit align to $something. I'm just not
sure what $something is. crtl-stack_alignment_estimated is not really
--- Comment #7 from matz at gcc dot gnu dot org 2010-06-15 14:56 ---
Jakub was not talking about crtl-stack_alignment_estimated becoming 256,
but rather DECL_ALIGN of certain decls in expand_one_stack_var_at.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542
--- Comment #12 from matz at gcc dot gnu dot org 2010-06-10 12:26 ---
I don't think it ever was intended that 'm' includes operands with embedded
side-effects. I don't think so because making this work reliably is
relatively difficult. In particular the tests that Jakub mentions would
--- Comment #17 from matz at gcc dot gnu dot org 2010-06-10 13:34 ---
m is defined to be the most general memory constraint, and a pre/post
modified memory operand is still a memory operand.
I know that this is the case, which is why I said: If that means to slightly
change
--- Comment #9 from matz at gcc dot gnu dot org 2010-05-06 13:55 ---
Subject: Bug 43984
Author: matz
Date: Thu May 6 13:54:32 2010
New Revision: 159106
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159106
Log:
PR tree-optimization/43984
* tree-ssa-pre.c
--- Comment #4 from matz at gcc dot gnu dot org 2010-05-05 12:35 ---
Ah, another case of a patch I held back for 4.6 to open, and then forgetting
about it :-/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43984
--- Comment #6 from matz at gcc dot gnu dot org 2010-05-05 13:32 ---
PRE seems to have done this since forever. All edge inserts are delayed if
the _immediate forms aren't used.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43984
: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at gcc dot gnu dot org
GCC host triplet: i686
--- Comment #1 from matz at gcc dot gnu dot org 2010-04-21 15:08 ---
Created an attachment (id=20454)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20454action=view)
testcase
# gcc -O2 sra-nonnull.c ./a.out
Segmentation fault
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #6 from matz at gcc dot gnu dot org 2010-04-14 14:51 ---
Subject: Bug 42963
Author: matz
Date: Wed Apr 14 14:50:33 2010
New Revision: 158345
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158345
Log:
PR tree-optimization/42963
* tree-cfg.c
--- Comment #7 from matz at gcc dot gnu dot org 2010-04-14 14:53 ---
Fixed for 4.6. I propose to WONTFIX this for 4.5.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from matz at gcc dot gnu dot org 2010-04-13 11:59 ---
No, we shouldn't unconditionally create REGs if the target isn't one, but
rather only if it doesn't match the predicate. Like so, which I'm testing
right now:
Index: builtins.c
--- Comment #5 from matz at gcc dot gnu dot org 2010-04-13 13:35 ---
Subject: Bug 43730
Author: matz
Date: Tue Apr 13 13:35:30 2010
New Revision: 158268
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158268
Log:
PR middle-end/43730
* builtins.c
--- Comment #6 from matz at gcc dot gnu dot org 2010-04-13 13:47 ---
Subject: Bug 43730
Author: matz
Date: Tue Apr 13 13:47:11 2010
New Revision: 158270
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158270
Log:
PR middle-end/43730
* builtins.c
--- Comment #7 from matz at gcc dot gnu dot org 2010-04-13 13:54 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from matz at gcc dot gnu dot org 2010-04-08 13:40 ---
Um, how can r138953 be the reason when (as the original report says) it's
still okay with r153685? In any case, my patch just shuffled around the
activation/non-activation of the scheduler, so if at all it exposed
--- Comment #19 from matz at gcc dot gnu dot org 2010-04-08 14:50 ---
This seems rather like a hack for our not-so-capable loop unroller. The
estimator already correctly knows that much of it will be optimized away,
hence it would make more sense for the code emitter to also not emit
--- Comment #28 from matz at gcc dot gnu dot org 2010-04-06 10:34 ---
I don't think we should fix the double-accounting bug for the 4.5 series,
when we tried it on SPEC it caused several regression, meaning we would need
much more fine-tuning. We have time for that for 4.6
--- Comment #33 from matz at gcc dot gnu dot org 2010-04-06 11:09 ---
Steven, please note that this PR was proposed WONTFIX for 4.5 already in
comment #15. The discussion after that was about something that is only
slightly related to this bug, something that wouldn't actually affect
--- Comment #14 from matz at gcc dot gnu dot org 2010-03-23 16:16 ---
Simply replace the recursive call to expand_expr_real_1 with a call to
expand_expr_real. That's the wrapper setting locations.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19192
--- Comment #18 from matz at gcc dot gnu dot org 2010-03-23 16:46 ---
It should mostly not matter anymore as expand_expr_real_[12] and friends use
an explicit location parameter, stored away before expanding operands.
But to be safe, yes, expand_expr_real() should instead also restore
--- Comment #2 from matz at gcc dot gnu dot org 2010-03-22 11:57 ---
optimize_reg_copy_3 misses to replace in notes. Mine.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from matz at gcc dot gnu dot org 2010-03-22 16:01 ---
For sched-deps.c there are two calls to cselib_lookup:
1) in sched_analize_1 (for writing to MEM)
2) in sched_analize_2 (for reading a MEM)
Regarding (2): cselib_lookup is called on a copy of X (made into T) which
--- Comment #3 from matz at gcc dot gnu dot org 2010-03-22 16:29 ---
Subject: Bug 43475
Author: matz
Date: Mon Mar 22 16:28:51 2010
New Revision: 157640
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157640
Log:
PR middle-end/43475
* recog.c
--- Comment #4 from matz at gcc dot gnu dot org 2010-03-22 16:30 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from matz at gcc dot gnu dot org 2010-03-22 16:34 ---
Re comment #6: well, then we still need to fix the c++98 case.
Re comment #7: note carefully how I have avoided is_pod in the testcase,
but instead used the internal mean to implement the former. That's the
regression
--- Comment #10 from matz at gcc dot gnu dot org 2010-03-22 16:54 ---
Hmm, well, but there's code out there that expects the old TR1 semantic,
namely blocxx, and if the definition is indeed muddled than IMNSHO we should
retain the behaviour as it was in older GCC versions, instead
--- Comment #4 from matz at gcc dot gnu dot org 2010-03-20 17:00 ---
But Simons patch was accepted. Simon: can you simply combine the two
testcases into one? No need to artificially lengthen the time for make check.
--
matz at gcc dot gnu dot org changed:
What
--- Comment #7 from matz at gcc dot gnu dot org 2010-03-19 12:37 ---
Subject: Bug 43305
Author: matz
Date: Fri Mar 19 12:37:28 2010
New Revision: 157567
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157567
Log:
PR 43305
* builtins.c
--- Comment #8 from matz at gcc dot gnu dot org 2010-03-19 12:38 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from matz at gcc dot gnu dot org 2010-03-19 15:33 ---
I have a patch: http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00893.html
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from matz at gcc dot gnu dot org 2010-03-19 16:18 ---
I have a patch: http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00899.html
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from matz at gcc dot gnu dot org 2010-03-19 16:23 ---
I'm not sure what you're asking. When the unpatched compiler the testcase
(with the printf or the x!=6-abort) will ICE with a checking compiler,
and produce wrong output (0 or an abort) with a nonchecking compiler
--- Comment #4 from matz at gcc dot gnu dot org 2010-03-19 16:37 ---
Subject: Bug 43116
Author: matz
Date: Fri Mar 19 16:37:27 2010
New Revision: 157578
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157578
Log:
PR c++/43116
* attribs.c (decl_attributes): When
--- Comment #5 from matz at gcc dot gnu dot org 2010-03-19 16:40 ---
Fixed for 4.5. Unassigning myself.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from matz at gcc dot gnu dot org 2010-03-19 16:55 ---
Actually I have a patch for this, need to polish it somewhat.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from matz at gcc dot gnu dot org 2010-03-19 16:59 ---
How about not calling cselib_process_insn on DEBUG_INSNs (or better make
cselib_process_insn ignore them).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42977
--- Comment #10 from matz at gcc dot gnu dot org 2010-03-18 12:21 ---
Subject: Bug 43402
Author: matz
Date: Thu Mar 18 12:20:50 2010
New Revision: 157538
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157538
Log:
PR tree-optimization/43402
* tree-cfgcleanup.c
--- Comment #11 from matz at gcc dot gnu dot org 2010-03-18 12:46 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from matz at gcc dot gnu dot org 2010-03-18 14:35 ---
Mine.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #4 from matz at gcc dot gnu dot org 2010-03-18 14:48 ---
I checked, and these and similar transformations are always guarded by
flag_unsafe_math_optimizations, so we should be fine, unless I missed a case
of course. If you notice one, please create a bug report
--- Comment #6 from matz at gcc dot gnu dot org 2010-03-18 16:08 ---
Subject: Bug 43419
Author: matz
Date: Thu Mar 18 16:07:53 2010
New Revision: 157543
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157543
Log:
PR middle-end/43419
* builtins.c (expand_builtin_pow
--- Comment #6 from matz at gcc dot gnu dot org 2010-03-18 16:47 ---
Mine.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #7 from matz at gcc dot gnu dot org 2010-03-18 16:47 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from matz at gcc dot gnu dot org 2010-03-18 16:53 ---
That would indeed be my preferred approach. The alternative would be to
add much if (x == error_mark_node) sillyness all over the middle-end, like
the front-ends do. The middle-end should be able to rightfully expect
Version: 4.5.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at gcc dot gnu dot org
GCC host triplet: x86_64-linux
http://gcc.gnu.org/bugzilla
--- Comment #1 from matz at gcc dot gnu dot org 2010-03-17 14:02 ---
Created an attachment (id=20127)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20127action=view)
testcase
Testcase reduced from ucnv_bld.c of libicu
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43402
--- Comment #3 from matz at gcc dot gnu dot org 2010-03-17 15:31 ---
It seems the jump threading somehow confuses cfgcleanup. Right after the
jumps are threaded (in tree_ssa_dominator_optimize after the call to
thread_through_all_blocks) the function looks like so:
bb 2:
goto bb 9
--- Comment #4 from matz at gcc dot gnu dot org 2010-03-17 15:36 ---
Um, we cleanup the CFG before updating SSA form, hence no wonder that
the missing PHI nodes confuse it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43402
--- Comment #5 from matz at gcc dot gnu dot org 2010-03-17 15:49 ---
Hmm, create_edge_and_update_destination_phis is supposed to add new PHI
arguments for the ultimate threading destination. But it only does so if
there are already PHI nodes in that BB. We need to create new ones
--- Comment #7 from matz at gcc dot gnu dot org 2010-03-17 16:05 ---
Hmm, I wonder how that could cause the bug. Probably because we can't rely
on SSA form being uptodate during cfgcleanup, and hence looking up PHI
arguments is wrong, at least for those SSA names that are registered
--- Comment #9 from matz at gcc dot gnu dot org 2010-03-17 17:03 ---
http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00774.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43402
--- Comment #5 from matz at gcc dot gnu dot org 2010-03-15 16:13 ---
Subject: Bug 43300
Author: matz
Date: Mon Mar 15 16:13:28 2010
New Revision: 157461
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157461
Log:
PR middle-end/43300
* tree-outof-ssa.c
--- Comment #6 from matz at gcc dot gnu dot org 2010-03-15 16:15 ---
Fixed. I put in a testcase that doesn't need graphite.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at gcc dot gnu dot org
GCC host triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
1 - 100 of 406 matches
Mail list logo
