* [PATCH] Fix up maybe_cleanup_end_of_block (PR middle-end/46499)
@ 2010-11-22 23:18 Jakub Jelinek
2010-11-23 13:27 ` Richard Guenther
` (2 more replies)
0 siblings, 3 replies; 12+ messages in thread
From: Jakub Jelinek @ 2010-11-22 23:18 UTC (permalink / raw)
To: gcc-patches
Hi!
On the attached testcases jumpif* emits:
(jump_insn 8 7 9 (set (pc)
(label_ref 0)) pr46499-1.c:26 -1
(nil))
(barrier 9 8 10)
(jump_insn 10 9 11 (set (pc)
(label_ref 0)) pr46499-1.c:26 -1
(nil))
(barrier 11 10 0)
where the label_ref in both cases is the non-fallthru label. This is
because ssa_name & ssa_name is the condition and both ssa_name's
are found using TER to be 0 (and the -fno-* options ensure it is not
optimized earlier).
maybe_cleanup_end_of_block is called to find out when the sequence ends
with an unconditional jump to the non-fallthru label, with no fallthru
code_label afterwards, which means all the sequence does (assuming no
side-effects in it but GIMPLE should ensure that) is that unconditional
jump and attempts to remove any other jumps from the sequence.
Apparently it was expecting just conditional jumps to the non-fallthru
label, for unconditional ones as in this example the following
barrier needs to be removed too, otherwise we end up with a barrier
in a middle of a bb and we either ICE on it, or miscompile it.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2010-11-22 Jakub Jelinek <jakub@redhat.com>
PR middle-end/46499
* cfgexpand.c (maybe_cleanup_end_of_block): Remove also BARRIERs
following unconditional jumps.
* gcc.dg/pr46499-1.c: New test.
* gcc.dg/pr46499-2.c: New test.
--- gcc/cfgexpand.c.jj 2010-11-10 13:14:53.000000000 +0100
+++ gcc/cfgexpand.c 2010-11-22 14:45:49.000000000 +0100
@@ -1694,7 +1694,14 @@ maybe_cleanup_end_of_block (edge e, rtx
{
insn = PREV_INSN (insn);
if (JUMP_P (NEXT_INSN (insn)))
- delete_insn (NEXT_INSN (insn));
+ {
+ if (!any_condjump_p (insn))
+ {
+ gcc_assert (BARRIER_P (NEXT_INSN (NEXT_INSN (insn))));
+ delete_insn (NEXT_INSN (NEXT_INSN (insn)));
+ }
+ delete_insn (NEXT_INSN (insn));
+ }
}
}
}
--- gcc/testsuite/gcc.dg/pr46499-1.c.jj 2010-11-22 14:59:48.000000000 +0100
+++ gcc/testsuite/gcc.dg/pr46499-1.c 2010-11-22 14:59:11.000000000 +0100
@@ -0,0 +1,31 @@
+/* PR middle-end/46499 */
+/* { dg-do run } */
+/* { dg-options "-O -fno-omit-frame-pointer -fno-tree-ccp -fno-tree-dominator-opts -finline-small-functions" } */
+
+extern void abort (void);
+
+int count = 0;
+
+int
+foo (void)
+{
+ count++;
+ return 0;
+}
+
+int
+bar (void)
+{
+ count++;
+ return 0;
+}
+
+int
+main ()
+{
+ if ((foo () == 1) & (bar () == 1))
+ abort ();
+ if (count != 2)
+ abort ();
+ return 0;
+}
--- gcc/testsuite/gcc.dg/pr46499-2.c.jj 2010-11-22 14:59:53.000000000 +0100
+++ gcc/testsuite/gcc.dg/pr46499-2.c 2010-11-22 14:55:37.000000000 +0100
@@ -0,0 +1,19 @@
+/* PR middle-end/46499 */
+/* { dg-do compile } */
+/* { dg-options "-O -fno-tree-ccp -fno-tree-dominator-opts" } */
+
+extern void abort (void);
+
+static inline int
+foo (void)
+{
+ return 0;
+}
+
+int
+main ()
+{
+ if ((foo () == 1) & (foo () == 1))
+ abort ();
+ return 0;
+}
Jakub
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] Fix up maybe_cleanup_end_of_block (PR middle-end/46499)
2010-11-22 23:18 [PATCH] Fix up maybe_cleanup_end_of_block (PR middle-end/46499) Jakub Jelinek
@ 2010-11-23 13:27 ` Richard Guenther
2010-11-23 22:51 ` H.J. Lu
2010-11-24 1:51 ` H.J. Lu
2 siblings, 0 replies; 12+ messages in thread
From: Richard Guenther @ 2010-11-23 13:27 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: gcc-patches
On Mon, Nov 22, 2010 at 11:00 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> Hi!
>
> On the attached testcases jumpif* emits:
> (jump_insn 8 7 9 (set (pc)
> (label_ref 0)) pr46499-1.c:26 -1
> (nil))
>
> (barrier 9 8 10)
>
> (jump_insn 10 9 11 (set (pc)
> (label_ref 0)) pr46499-1.c:26 -1
> (nil))
>
> (barrier 11 10 0)
> where the label_ref in both cases is the non-fallthru label. This is
> because ssa_name & ssa_name is the condition and both ssa_name's
> are found using TER to be 0 (and the -fno-* options ensure it is not
> optimized earlier).
> maybe_cleanup_end_of_block is called to find out when the sequence ends
> with an unconditional jump to the non-fallthru label, with no fallthru
> code_label afterwards, which means all the sequence does (assuming no
> side-effects in it but GIMPLE should ensure that) is that unconditional
> jump and attempts to remove any other jumps from the sequence.
> Apparently it was expecting just conditional jumps to the non-fallthru
> label, for unconditional ones as in this example the following
> barrier needs to be removed too, otherwise we end up with a barrier
> in a middle of a bb and we either ICE on it, or miscompile it.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Ok.
Thanks,
Richard.
> 2010-11-22 Jakub Jelinek <jakub@redhat.com>
>
> PR middle-end/46499
> * cfgexpand.c (maybe_cleanup_end_of_block): Remove also BARRIERs
> following unconditional jumps.
>
> * gcc.dg/pr46499-1.c: New test.
> * gcc.dg/pr46499-2.c: New test.
>
> --- gcc/cfgexpand.c.jj 2010-11-10 13:14:53.000000000 +0100
> +++ gcc/cfgexpand.c 2010-11-22 14:45:49.000000000 +0100
> @@ -1694,7 +1694,14 @@ maybe_cleanup_end_of_block (edge e, rtx
> {
> insn = PREV_INSN (insn);
> if (JUMP_P (NEXT_INSN (insn)))
> - delete_insn (NEXT_INSN (insn));
> + {
> + if (!any_condjump_p (insn))
> + {
> + gcc_assert (BARRIER_P (NEXT_INSN (NEXT_INSN (insn))));
> + delete_insn (NEXT_INSN (NEXT_INSN (insn)));
> + }
> + delete_insn (NEXT_INSN (insn));
> + }
> }
> }
> }
> --- gcc/testsuite/gcc.dg/pr46499-1.c.jj 2010-11-22 14:59:48.000000000 +0100
> +++ gcc/testsuite/gcc.dg/pr46499-1.c 2010-11-22 14:59:11.000000000 +0100
> @@ -0,0 +1,31 @@
> +/* PR middle-end/46499 */
> +/* { dg-do run } */
> +/* { dg-options "-O -fno-omit-frame-pointer -fno-tree-ccp -fno-tree-dominator-opts -finline-small-functions" } */
> +
> +extern void abort (void);
> +
> +int count = 0;
> +
> +int
> +foo (void)
> +{
> + count++;
> + return 0;
> +}
> +
> +int
> +bar (void)
> +{
> + count++;
> + return 0;
> +}
> +
> +int
> +main ()
> +{
> + if ((foo () == 1) & (bar () == 1))
> + abort ();
> + if (count != 2)
> + abort ();
> + return 0;
> +}
> --- gcc/testsuite/gcc.dg/pr46499-2.c.jj 2010-11-22 14:59:53.000000000 +0100
> +++ gcc/testsuite/gcc.dg/pr46499-2.c 2010-11-22 14:55:37.000000000 +0100
> @@ -0,0 +1,19 @@
> +/* PR middle-end/46499 */
> +/* { dg-do compile } */
> +/* { dg-options "-O -fno-tree-ccp -fno-tree-dominator-opts" } */
> +
> +extern void abort (void);
> +
> +static inline int
> +foo (void)
> +{
> + return 0;
> +}
> +
> +int
> +main ()
> +{
> + if ((foo () == 1) & (foo () == 1))
> + abort ();
> + return 0;
> +}
>
> Jakub
>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] Fix up maybe_cleanup_end_of_block (PR middle-end/46499)
2010-11-22 23:18 [PATCH] Fix up maybe_cleanup_end_of_block (PR middle-end/46499) Jakub Jelinek
2010-11-23 13:27 ` Richard Guenther
@ 2010-11-23 22:51 ` H.J. Lu
2010-11-23 22:54 ` H.J. Lu
2010-11-24 1:51 ` H.J. Lu
2 siblings, 1 reply; 12+ messages in thread
From: H.J. Lu @ 2010-11-23 22:51 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: gcc-patches
On Mon, Nov 22, 2010 at 2:00 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> Hi!
>
> On the attached testcases jumpif* emits:
> (jump_insn 8 7 9 (set (pc)
> (label_ref 0)) pr46499-1.c:26 -1
> (nil))
>
> (barrier 9 8 10)
>
> (jump_insn 10 9 11 (set (pc)
> (label_ref 0)) pr46499-1.c:26 -1
> (nil))
>
> (barrier 11 10 0)
> where the label_ref in both cases is the non-fallthru label. This is
> because ssa_name & ssa_name is the condition and both ssa_name's
> are found using TER to be 0 (and the -fno-* options ensure it is not
> optimized earlier).
> maybe_cleanup_end_of_block is called to find out when the sequence ends
> with an unconditional jump to the non-fallthru label, with no fallthru
> code_label afterwards, which means all the sequence does (assuming no
> side-effects in it but GIMPLE should ensure that) is that unconditional
> jump and attempts to remove any other jumps from the sequence.
> Apparently it was expecting just conditional jumps to the non-fallthru
> label, for unconditional ones as in this example the following
> barrier needs to be removed too, otherwise we end up with a barrier
> in a middle of a bb and we either ICE on it, or miscompile it.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2010-11-22 Jakub Jelinek <jakub@redhat.com>
>
> PR middle-end/46499
> * cfgexpand.c (maybe_cleanup_end_of_block): Remove also BARRIERs
> following unconditional jumps.
>
This caused:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46629
--
H.J.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] Fix up maybe_cleanup_end_of_block (PR middle-end/46499)
2010-11-23 22:51 ` H.J. Lu
@ 2010-11-23 22:54 ` H.J. Lu
2010-11-23 22:55 ` Andrew Pinski
0 siblings, 1 reply; 12+ messages in thread
From: H.J. Lu @ 2010-11-23 22:54 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: gcc-patches
On Tue, Nov 23, 2010 at 1:59 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Mon, Nov 22, 2010 at 2:00 PM, Jakub Jelinek <jakub@redhat.com> wrote:
>> Hi!
>>
>> On the attached testcases jumpif* emits:
>> (jump_insn 8 7 9 (set (pc)
>> (label_ref 0)) pr46499-1.c:26 -1
>> (nil))
>>
>> (barrier 9 8 10)
>>
>> (jump_insn 10 9 11 (set (pc)
>> (label_ref 0)) pr46499-1.c:26 -1
>> (nil))
>>
>> (barrier 11 10 0)
>> where the label_ref in both cases is the non-fallthru label. This is
>> because ssa_name & ssa_name is the condition and both ssa_name's
>> are found using TER to be 0 (and the -fno-* options ensure it is not
>> optimized earlier).
>> maybe_cleanup_end_of_block is called to find out when the sequence ends
>> with an unconditional jump to the non-fallthru label, with no fallthru
>> code_label afterwards, which means all the sequence does (assuming no
>> side-effects in it but GIMPLE should ensure that) is that unconditional
>> jump and attempts to remove any other jumps from the sequence.
>> Apparently it was expecting just conditional jumps to the non-fallthru
>> label, for unconditional ones as in this example the following
>> barrier needs to be removed too, otherwise we end up with a barrier
>> in a middle of a bb and we either ICE on it, or miscompile it.
>>
>> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>>
>> 2010-11-22 Jakub Jelinek <jakub@redhat.com>
>>
>> PR middle-end/46499
>> * cfgexpand.c (maybe_cleanup_end_of_block): Remove also BARRIERs
>> following unconditional jumps.
>>
>
> This caused:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46629
>
LTO seems to generate unconditional jumps without barrier.
Is this an LTO bug?
--
H.J.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] Fix up maybe_cleanup_end_of_block (PR middle-end/46499)
2010-11-23 22:54 ` H.J. Lu
@ 2010-11-23 22:55 ` Andrew Pinski
0 siblings, 0 replies; 12+ messages in thread
From: Andrew Pinski @ 2010-11-23 22:55 UTC (permalink / raw)
To: H.J. Lu; +Cc: Jakub Jelinek, gcc-patches
On Tue, Nov 23, 2010 at 2:01 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> LTO seems to generate unconditional jumps without barrier.
> Is this an LTO bug?
Considering LTO does not work on the RTL level at all. I suspect you
could get a C testcase that produces the same ICE.
-- Pinski
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] Fix up maybe_cleanup_end_of_block (PR middle-end/46499)
2010-11-22 23:18 [PATCH] Fix up maybe_cleanup_end_of_block (PR middle-end/46499) Jakub Jelinek
2010-11-23 13:27 ` Richard Guenther
2010-11-23 22:51 ` H.J. Lu
@ 2010-11-24 1:51 ` H.J. Lu
2010-11-24 2:37 ` Jakub Jelinek
2010-11-24 10:04 ` [PATCH] Fix up maybe_cleanup_end_of_block (PR middle-end/46629) Jakub Jelinek
2 siblings, 2 replies; 12+ messages in thread
From: H.J. Lu @ 2010-11-24 1:51 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: gcc-patches
On Mon, Nov 22, 2010 at 2:00 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> Hi!
>
> On the attached testcases jumpif* emits:
> (jump_insn 8 7 9 (set (pc)
> (label_ref 0)) pr46499-1.c:26 -1
> (nil))
>
> (barrier 9 8 10)
>
> (jump_insn 10 9 11 (set (pc)
> (label_ref 0)) pr46499-1.c:26 -1
> (nil))
>
> (barrier 11 10 0)
> where the label_ref in both cases is the non-fallthru label. This is
> because ssa_name & ssa_name is the condition and both ssa_name's
> are found using TER to be 0 (and the -fno-* options ensure it is not
> optimized earlier).
> maybe_cleanup_end_of_block is called to find out when the sequence ends
> with an unconditional jump to the non-fallthru label, with no fallthru
> code_label afterwards, which means all the sequence does (assuming no
> side-effects in it but GIMPLE should ensure that) is that unconditional
> jump and attempts to remove any other jumps from the sequence.
> Apparently it was expecting just conditional jumps to the non-fallthru
> label, for unconditional ones as in this example the following
> barrier needs to be removed too, otherwise we end up with a barrier
> in a middle of a bb and we either ICE on it, or miscompile it.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2010-11-22 Jakub Jelinek <jakub@redhat.com>
>
> PR middle-end/46499
> * cfgexpand.c (maybe_cleanup_end_of_block): Remove also BARRIERs
> following unconditional jumps.
>
> * gcc.dg/pr46499-1.c: New test.
> * gcc.dg/pr46499-2.c: New test.
>
> --- gcc/cfgexpand.c.jj 2010-11-10 13:14:53.000000000 +0100
> +++ gcc/cfgexpand.c 2010-11-22 14:45:49.000000000 +0100
> @@ -1694,7 +1694,14 @@ maybe_cleanup_end_of_block (edge e, rtx
> {
> insn = PREV_INSN (insn);
> if (JUMP_P (NEXT_INSN (insn)))
> - delete_insn (NEXT_INSN (insn));
> + {
> + if (!any_condjump_p (insn))
^^^^^^ Shouldn't it
be any_condjump_p (NEXT_INSN (insn))
> + {
> + gcc_assert (BARRIER_P (NEXT_INSN (NEXT_INSN (insn))));
> + delete_insn (NEXT_INSN (NEXT_INSN (insn)));
> + }
> + delete_insn (NEXT_INSN (insn));
> + }
> }
> }
> }
--
H.J.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] Fix up maybe_cleanup_end_of_block (PR middle-end/46499)
2010-11-24 1:51 ` H.J. Lu
@ 2010-11-24 2:37 ` Jakub Jelinek
2010-11-24 2:44 ` H.J. Lu
2010-11-24 10:04 ` [PATCH] Fix up maybe_cleanup_end_of_block (PR middle-end/46629) Jakub Jelinek
1 sibling, 1 reply; 12+ messages in thread
From: Jakub Jelinek @ 2010-11-24 2:37 UTC (permalink / raw)
To: H.J. Lu; +Cc: gcc-patches
On Tue, Nov 23, 2010 at 04:51:35PM -0800, H.J. Lu wrote:
> > --- gcc/cfgexpand.c.jj  2010-11-10 13:14:53.000000000 +0100
> > +++ gcc/cfgexpand.c   2010-11-22 14:45:49.000000000 +0100
> > @@ -1694,7 +1694,14 @@ maybe_cleanup_end_of_block (edge e, rtx
> > Â Â Â Â {
> > Â Â Â Â Â insn = PREV_INSN (insn);
> > Â Â Â Â Â if (JUMP_P (NEXT_INSN (insn)))
> > - Â Â Â Â Â delete_insn (NEXT_INSN (insn));
> > + Â Â Â Â Â {
> > + Â Â Â Â Â Â if (!any_condjump_p (insn))
> ^^^^^^ Shouldn't it
> be any_condjump_p (NEXT_INSN (insn))
Oops.
No, but either if (!any_condjump_p (NEXT_INSN (insn)))
or if (any_uncondjump_p (NEXT_INSN (insn)))
I'll bootstrap/regtest the former now.
Jakub
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH] Fix up maybe_cleanup_end_of_block (PR middle-end/46499)
2010-11-24 2:37 ` Jakub Jelinek
@ 2010-11-24 2:44 ` H.J. Lu
0 siblings, 0 replies; 12+ messages in thread
From: H.J. Lu @ 2010-11-24 2:44 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: gcc-patches
On Tue, Nov 23, 2010 at 5:00 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Tue, Nov 23, 2010 at 04:51:35PM -0800, H.J. Lu wrote:
>> > --- gcc/cfgexpand.c.jj 2010-11-10 13:14:53.000000000 +0100
>> > +++ gcc/cfgexpand.c 2010-11-22 14:45:49.000000000 +0100
>> > @@ -1694,7 +1694,14 @@ maybe_cleanup_end_of_block (edge e, rtx
>> > {
>> > insn = PREV_INSN (insn);
>> > if (JUMP_P (NEXT_INSN (insn)))
>> > - delete_insn (NEXT_INSN (insn));
>> > + {
>> > + if (!any_condjump_p (insn))
>> ^^^^^^ Shouldn't it
>> be any_condjump_p (NEXT_INSN (insn))
>
> Oops.
> No, but either if (!any_condjump_p (NEXT_INSN (insn)))
> or if (any_uncondjump_p (NEXT_INSN (insn)))
>
> I'll bootstrap/regtest the former now.
Please add the testcase in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46629
Thanks.
--
H.J.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH] Fix up maybe_cleanup_end_of_block (PR middle-end/46629)
2010-11-24 1:51 ` H.J. Lu
2010-11-24 2:37 ` Jakub Jelinek
@ 2010-11-24 10:04 ` Jakub Jelinek
2010-11-24 11:13 ` [testcase] " Jakub Jelinek
1 sibling, 1 reply; 12+ messages in thread
From: Jakub Jelinek @ 2010-11-24 10:04 UTC (permalink / raw)
To: H.J. Lu; +Cc: gcc-patches
On Tue, Nov 23, 2010 at 04:51:35PM -0800, H.J. Lu wrote:
Committed as obvious, will deal with the testcase later.
2010-11-24 Jakub Jelinek <jakub@redhat.com>
PR middle-end/46629
* cfgexpand.c (maybe_cleanup_end_of_block): Test NEXT_INSN (insn)
instead of insn with any_condjump_p.
--- gcc/cfgexpand.c.jj 2010-11-23 16:14:44.000000000 +0100
+++ gcc/cfgexpand.c 2010-11-24 02:03:52.225261091 +0100
@@ -1695,7 +1695,7 @@ maybe_cleanup_end_of_block (edge e, rtx
insn = PREV_INSN (insn);
if (JUMP_P (NEXT_INSN (insn)))
{
- if (!any_condjump_p (insn))
+ if (!any_condjump_p (NEXT_INSN (insn)))
{
gcc_assert (BARRIER_P (NEXT_INSN (NEXT_INSN (insn))));
delete_insn (NEXT_INSN (NEXT_INSN (insn)));
Jakub
^ permalink raw reply [flat|nested] 12+ messages in thread
* [testcase] Fix up maybe_cleanup_end_of_block (PR middle-end/46629)
2010-11-24 10:04 ` [PATCH] Fix up maybe_cleanup_end_of_block (PR middle-end/46629) Jakub Jelinek
@ 2010-11-24 11:13 ` Jakub Jelinek
2010-11-24 11:30 ` Richard Guenther
0 siblings, 1 reply; 12+ messages in thread
From: Jakub Jelinek @ 2010-11-24 11:13 UTC (permalink / raw)
To: Richard Guenther; +Cc: H.J. Lu, gcc-patches
On Wed, Nov 24, 2010 at 09:59:34AM +0100, Jakub Jelinek wrote:
> On Tue, Nov 23, 2010 at 04:51:35PM -0800, H.J. Lu wrote:
> Committed as obvious, will deal with the testcase later.
And here is a testcase for that, not 100% sure if I got the dg-lto* stuff
right, but it works (and fails with unfixed gcc). Ok for trunk?
2010-11-24 Jakub Jelinek <jakub@redhat.com>
PR middle-end/46629
* gfortran.dg/lto/pr46629_0.f90: New test.
--- gcc/testsuite/gfortran.dg/lto/pr46629_0.f90.jj 2010-11-24 10:42:09.285372916 +0100
+++ gcc/testsuite/gfortran.dg/lto/pr46629_0.f90 2010-11-24 10:57:53.225261153 +0100
@@ -0,0 +1,15 @@
+! PR middle-end/64429
+! { dg-lto-do assemble }
+! { dg-lto-options {{ -O2 -flto -ftree-vectorize }} }
+! { dg-lto-options {{ -O2 -flto -ftree-vectorize -march=x86-64 }} { target i?86-*-* x86_64-*-* } }
+
+subroutine foo
+ character(len=6), save :: c
+ real, save :: d(0:100)
+ integer, save :: x, n, i
+ n = x
+ print *, c
+ do i = 2, n
+ d(i) = -d(i-1)
+ end do
+end
Jakub
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [testcase] Fix up maybe_cleanup_end_of_block (PR middle-end/46629)
2010-11-24 11:13 ` [testcase] " Jakub Jelinek
@ 2010-11-24 11:30 ` Richard Guenther
2010-11-24 11:48 ` Jakub Jelinek
0 siblings, 1 reply; 12+ messages in thread
From: Richard Guenther @ 2010-11-24 11:30 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: H.J. Lu, gcc-patches
On Wed, 24 Nov 2010, Jakub Jelinek wrote:
> On Wed, Nov 24, 2010 at 09:59:34AM +0100, Jakub Jelinek wrote:
> > On Tue, Nov 23, 2010 at 04:51:35PM -0800, H.J. Lu wrote:
> > Committed as obvious, will deal with the testcase later.
>
> And here is a testcase for that, not 100% sure if I got the dg-lto* stuff
> right, but it works (and fails with unfixed gcc). Ok for trunk?
dg-lto-do assemble will only produce lto bytecode but not do the
link step, if the ICE happened from f951 and not lto1 then this
is ok.
Richard.
> 2010-11-24 Jakub Jelinek <jakub@redhat.com>
>
> PR middle-end/46629
> * gfortran.dg/lto/pr46629_0.f90: New test.
>
> --- gcc/testsuite/gfortran.dg/lto/pr46629_0.f90.jj 2010-11-24 10:42:09.285372916 +0100
> +++ gcc/testsuite/gfortran.dg/lto/pr46629_0.f90 2010-11-24 10:57:53.225261153 +0100
> @@ -0,0 +1,15 @@
> +! PR middle-end/64429
> +! { dg-lto-do assemble }
> +! { dg-lto-options {{ -O2 -flto -ftree-vectorize }} }
> +! { dg-lto-options {{ -O2 -flto -ftree-vectorize -march=x86-64 }} { target i?86-*-* x86_64-*-* } }
> +
> +subroutine foo
> + character(len=6), save :: c
> + real, save :: d(0:100)
> + integer, save :: x, n, i
> + n = x
> + print *, c
> + do i = 2, n
> + d(i) = -d(i-1)
> + end do
> +end
>
>
> Jakub
>
>
--
Richard Guenther <rguenther@suse.de>
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [testcase] Fix up maybe_cleanup_end_of_block (PR middle-end/46629)
2010-11-24 11:30 ` Richard Guenther
@ 2010-11-24 11:48 ` Jakub Jelinek
0 siblings, 0 replies; 12+ messages in thread
From: Jakub Jelinek @ 2010-11-24 11:48 UTC (permalink / raw)
To: Richard Guenther; +Cc: H.J. Lu, gcc-patches
On Wed, Nov 24, 2010 at 11:08:55AM +0100, Richard Guenther wrote:
> On Wed, 24 Nov 2010, Jakub Jelinek wrote:
>
> > On Wed, Nov 24, 2010 at 09:59:34AM +0100, Jakub Jelinek wrote:
> > > On Tue, Nov 23, 2010 at 04:51:35PM -0800, H.J. Lu wrote:
> > > Committed as obvious, will deal with the testcase later.
> >
> > And here is a testcase for that, not 100% sure if I got the dg-lto* stuff
> > right, but it works (and fails with unfixed gcc). Ok for trunk?
>
> dg-lto-do assemble will only produce lto bytecode but not do the
> link step, if the ICE happened from f951 and not lto1 then this
> is ok.
It did. I haven't understood what is the difference between -flto and
normal compilation, before *.vect the difference was just the function name
in the dump, but somehow with -flto vectorization happened while without it
it didn't.
Jakub
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2010-11-24 10:17 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-11-22 23:18 [PATCH] Fix up maybe_cleanup_end_of_block (PR middle-end/46499) Jakub Jelinek
2010-11-23 13:27 ` Richard Guenther
2010-11-23 22:51 ` H.J. Lu
2010-11-23 22:54 ` H.J. Lu
2010-11-23 22:55 ` Andrew Pinski
2010-11-24 1:51 ` H.J. Lu
2010-11-24 2:37 ` Jakub Jelinek
2010-11-24 2:44 ` H.J. Lu
2010-11-24 10:04 ` [PATCH] Fix up maybe_cleanup_end_of_block (PR middle-end/46629) Jakub Jelinek
2010-11-24 11:13 ` [testcase] " Jakub Jelinek
2010-11-24 11:30 ` Richard Guenther
2010-11-24 11:48 ` Jakub Jelinek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).