[Bug middle-end/41082] New: [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[Bug middle-end/41082] New: [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[dominiq at lps dot ens dot fr]

At revision 150792 the test gfortran.fortran-torture/execute/where_2.f90 fails
on powerpc-apple-darwin9 with -m64  -O3. The test passed at revision 150097.
The output is

100         100         100         210         210         210         310    
    310         310         310

instead of

100         100         100         210         210         210         310    
    310         337         337

i.e., the line

      WHERE (reduce > 6) temp = temp + sum(reduce)

seems to be skipped.


-- 
           Summary: [4.5 Regression] FAIL: gfortran.fortran-
                    torture/execute/where_2.f90 execution,  -O3 -g with -m64
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dominiq at lps dot ens dot fr
 GCC build triplet: powerpc-apple-darwin9
  GCC host triplet: powerpc-apple-darwin9
GCC target triplet: powerpc-apple-darwin9


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[dominiq at lps dot ens dot fr]

------- Comment #1 from dominiq at lps dot ens dot fr  2009-08-17 11:42 -------
> The test passed at revision 150097.

This was a mistake, test passed at r149758, but not at r150041.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[dominiq at lps dot ens dot fr]

------- Comment #2 from dominiq at lps dot ens dot fr  2009-08-18 20:03 -------
The manual says:

-O3
Optimize yet more. -O3 turns on all optimizations specified by -O2 and also
turns on the -finline-functions, -funswitch-loops, -fpredictive-commoning,
-fgcse-after-reload and -ftree-vectorize options. 

but I see:

[karma] f90/bug% gfc -m64 -O2 -ftree-vectorize -finline-functions
-funswitch-loops -fpredictive-commoning -fgcse-after-reload where_2.f90
[karma] f90/bug% a.out
         100         100         100         210         210         210       
 310         310         337         337
[karma] f90/bug% gfc -m64 -O3 where_2.f90
[karma] f90/bug% a.out
         100         100         100         210         210         210       
 310         310         310         310
Abort

What are the missing differences between -O2 and -O3?


-- 

dominiq at lps dot ens dot fr changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenther at suse dot de


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[rguenther at suse dot de]

------- Comment #3 from rguenther at suse dot de  2009-08-19 08:30 -------
Subject: Re:  [4.5 Regression] FAIL:
 gfortran.fortran-torture/execute/where_2.f90 execution,  -O3 -g with -m64

On Tue, 18 Aug 2009, dominiq at lps dot ens dot fr wrote:

> ------- Comment #2 from dominiq at lps dot ens dot fr  2009-08-18 20:03 -------
> The manual says:
> 
> -O3
> Optimize yet more. -O3 turns on all optimizations specified by -O2 and also
> turns on the -finline-functions, -funswitch-loops, -fpredictive-commoning,
> -fgcse-after-reload and -ftree-vectorize options. 
> 
> but I see:
> 
> [karma] f90/bug% gfc -m64 -O2 -ftree-vectorize -finline-functions
> -funswitch-loops -fpredictive-commoning -fgcse-after-reload where_2.f90
> [karma] f90/bug% a.out
>          100         100         100         210         210         210       
>  310         310         337         337
> [karma] f90/bug% gfc -m64 -O3 where_2.f90
> [karma] f90/bug% a.out
>          100         100         100         210         210         210       
>  310         310         310         310
> Abort
> 
> What are the missing differences between -O2 and -O3?

from opts.c:

  /* -O3 optimizations.  */
  opt3 = (optimize >= 3);
  flag_predictive_commoning = opt3;
  flag_inline_functions = opt3;
  flag_unswitch_loops = opt3;
  flag_gcse_after_reload = opt3;
  flag_tree_vectorize = opt3;
  flag_ipa_cp_clone = opt3;
  if (flag_ipa_cp_clone)
    flag_ipa_cp = 1;

and then random checks in passes:

> grep optimize\ \> *.c
tree-ssa-loop-niter.c:  if (optimize >= 3)
tree-ssa-loop.c:                                       || optimize >= 3, 
true);
tree-ssa-loop.c:      ret = tree_unroll_loops_completely (optimize >= 3, 
false);
tree-ssa-pre.c:  do_partial_partial = optimize > 2;

Thus, you can't compose -O3 from -O2 and extra flags.

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[jsm28 at gcc dot gnu dot org]

-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.5.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[dominiq at lps dot ens dot fr]

------- Comment #4 from dominiq at lps dot ens dot fr  2009-09-17 20:34 -------
Between revisions 151150 (-m64 only) and 151446 (both -m32 and -m64) the test
has started to fail also in 32 bit mode with a different wrong result:

karma] f90/bug% gfc -O3 where_2.f90
[karma] f90/bug% a.out 
         100         100         100         210         210         210       
 310         337         310         310
Abort

(see also http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg00830.html).

Now between revision 151644 (both for sure, but probably up to 151730 IIRC) and
151771 (-m32 only) the test now passes with -m64:

[karma] f90/bug% gfc -m64 -O3 where_2.f90
[karma] f90/bug% a.out
         100         100         100         210         210         210       
 310         310         337         337


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[dominiq at lps dot ens dot fr]

------- Comment #5 from dominiq at lps dot ens dot fr  2009-09-17 20:54 -------
At revision 151771 the test in the test suite still fails at -m64, but passes
with the addition of the print:

--- where_2.f90 2005-07-04 08:24:26.000000000 +0200
+++
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.fortran-torture/execute/where_2.f90 
    2007-11-21 20:23:35.000000000 +0100
@@ -17,7 +17,6 @@
       temp = 300 + temp
    END WHERE

-   print *, temp
    if (any (temp .ne. (/100, 100, 100, 210, 210, 210, 310, 310, 337, 337/))) &
       call abort
 end program


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
           Priority|P3                          |P2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[dominiq at lps dot ens dot fr]

------- Comment #6 from dominiq at lps dot ens dot fr  2009-12-14 21:10 -------
The test passes with '-O3 -fno-tree-vectorize' or '-O2 -ftree-vectorize', so
its seems that it is a vectorizer problem.


-- 

dominiq at lps dot ens dot fr changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |irar at il dot ibm dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[irar at il dot ibm dot com]

------- Comment #7 from irar at il dot ibm dot com  2009-12-15 08:25 -------
I can't reproduce it with current mainline on powerpc64-suse-linux. Could you
please attach vectorizer dump? Does the good old version gets vectorized? If
so, could you please attach it as well?

Thanks,
Ira


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[dominiq at lps dot ens dot fr]

------- Comment #8 from dominiq at lps dot ens dot fr  2009-12-15 09:58 -------
> I can't reproduce it with current mainline on powerpc64-suse-linux. 

I know;)

> Does the good old version gets vectorized?

I don't have any working 4.5 version, but 4.4.2 is working. The differences are

(4.4.2)

where_2.f90:5: note: LOOP VECTORIZED.
where_2.f90:2: note: vectorized 1 loops in function.

(4.5.0)

where_2.f90:11: note: LOOP VECTORIZED.
where_2.f90:11: note: not vectorized: relevant stmt not supported: cond.23_79 =
D.1255_78 > 6;

where_2.f90:11: note: not vectorized: relevant stmt not supported: cond.15_57 =
D.1238_56 == 0;

where_2.f90:11: note: not vectorized: relevant stmt not supported: cond.9_43 =
D.1227_42 < 0;

where_2.f90:5: note: LOOP VECTORIZED.
where_2.f90:2: note: vectorized 2 loops in function.


> Could you please attach vectorizer dump?  If so, could you please attach it as well?

I'll attach the files dumped with -fdump-tree-vect for 4.4 and 4.5.

Note that I make a mistake when looking to my log files: the last working
revision is 149758 and the first failing one is 150041.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[dominiq at lps dot ens dot fr]

------- Comment #9 from dominiq at lps dot ens dot fr  2009-12-15 09:59 -------
Created an attachment (id=19309)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19309&action=view)
dump file for gfortran 4.4.2


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[dominiq at lps dot ens dot fr]

------- Comment #10 from dominiq at lps dot ens dot fr  2009-12-15 10:00 -------
Created an attachment (id=19310)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19310&action=view)
dump file for gfortran 4.5.0 revision 155196


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[irar at il dot ibm dot com]

------- Comment #11 from irar at il dot ibm dot com  2009-12-15 10:59 -------
Looks that it has to be my patch that enables vectorization of conditions:

r149806 | irar | 2009-07-20 14:59:10 +0300 (Mon, 20 Jul 2009) | 19 lines


        * tree-vectorizer.h (vectorizable_condition): Add parameters.
        * tree-vect-loop.c (vect_is_simple_reduction): Support COND_EXPR.
        (get_initial_def_for_reduction): Likewise.
        (vectorizable_reduction): Skip the check of first operand in case
        of COND_EXPR. Add check that it is outer loop vectorization if
        nested cycle was detected. Call vectorizable_condition() for
        COND_EXPR. If reduction epilogue cannot be created do not fail for
        nested cycles (if it is not double reduction). Assert that there
        is only one type in the loop in case of COND_EXPR. Call
        vectorizable_condition() to vectorize COND_EXPR.
        * tree-vect-stmts.c (vectorizable_condition): Update comment.
        Add parameters. Allow nested cycles if called from
        vectorizable_reduction(). Use reduction vector variable if provided.
        (vect_analyze_stmt): Call vectorizable_reduction() before
        vectorizable_condition().
        (vect_transform_stmt): Update call to vectorizable_condition().

I'll try to find out what's wrong with it.

Thanks,
Ira


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[dominiq at lps dot ens dot fr]

------- Comment #12 from dominiq at lps dot ens dot fr  2009-12-15 13:05 -------
> Looks that it has to be my patch that enables vectorization of conditions:

I am doing a clean bootstrap of C and FORTRAN of revision 149805 to see if the
test works for it (allow for ~6h on my poor G5). Then I'll update to 149806.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[irar at il dot ibm dot com]

------- Comment #13 from irar at il dot ibm dot com  2009-12-15 13:07 -------
(In reply to comment #12)
> > Looks that it has to be my patch that enables vectorization of conditions:
> I am doing a clean bootstrap of C and FORTRAN of revision 149805 to see if the
> test works for it (allow for ~6h on my poor G5). Then I'll update to 149806.

1) Thanks. I got confused by the var names, but actually there is no COND_EXPR
there. But still, it can be this patch. So it worth checking. 

2) The vectorizer's code for powerpc64-suse-linux I got is identical to
darwin's except that the first has calls:

   _gfortran_set_args (argc_1(D), argv_2(D));                
    _gfortran_set_options (8, &options.36[0]);

in the begining

and the second one has this bb:

<bb 43>:
  dt_parm.33.common.filename = &"where_2.f90"[1]{lb: 1 sz: 1};
  dt_parm.33.common.line = 20;
  dt_parm.33.common.flags = 128;
  dt_parm.33.common.unit = 6;
  _gfortran_st_write (&dt_parm.33);
  parm.34.dtype = 265;
  parm.34.dim[0].lbound = 1;
  parm.34.dim[0].ubound = 10;
  parm.34.dim[0].stride = 1;
  parm.34.data = &temp[0];
  parm.34.offset = -1;
  _gfortran_transfer_array (&dt_parm.33, &parm.34, 4, 0);
  _gfortran_st_write_done (&dt_parm.33);

(I am attaching my dump).

3) The only difference between the targets I am aware of is natural alignment,
but we don't do peeling, so it shouldn't make any difference here.

4) We do force alignment. Between in the revisions range there is this patch
that may be somehow related:

r149853 | pbrook | 2009-07-21 15:35:38 +0300 (Tue, 21 Jul 2009) | 12 lines

2009-07-21  Paul Brook <paul@codesourcery.com>

        gcc/
        * tree-vectorizer.c (increase_alignment): Handle nested arrays.
        Terminate debug dump with newline.

        gcc/testsuite/
        * gcc.dg/vect/section-anchors-nest-1.c: New test.
        * lib/target-supports.exp (check_effective_target_section_anchors):
        Add arm*-*-*.

5) Also looking at the assembly may help. Could you please attach it as well?

Thanks,
Ira


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[irar at il dot ibm dot com]

------- Comment #14 from irar at il dot ibm dot com  2009-12-15 13:08 -------
Created an attachment (id=19311)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19311&action=view)
powerpc64-suse-linux vect dump


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[dominiq at lps dot ens dot fr]

------- Comment #15 from dominiq at lps dot ens dot fr  2009-12-15 13:29 -------
> and the second one has this bb:
>
> <bb 43>:
>   dt_parm.33.common.filename = &"where_2.f90"[1]{lb: 1 sz: 1};
> ...
>   _gfortran_st_write_done (&dt_parm.33);

This is probably due to a print I put in the code to look at the array temp:

...
   print *, temp
   if (any (temp .ne. (/100, 100, 100, 210, 210, 210, 310, 310, 337, 337/))) &
...

I forgot to mention it.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[irar at il dot ibm dot com]

------- Comment #16 from irar at il dot ibm dot com  2009-12-15 13:35 -------
But in comment #5 you wrote that it passes with the print, right? So, this dump
contains correct or incorrect code?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[dominiq at lps dot ens dot fr]

------- Comment #17 from dominiq at lps dot ens dot fr  2009-12-15 14:15 -------
> But in comment #5 you wrote that it passes with the print, right? So, this dump
> contains correct or incorrect code?

The dump for 4.5 is from the incorrect code. The behavior of this bug has
change over time, it started for -m64 only with/without print, then it failes
also with -m32, finally at revision 155239 it fails with the print:

...
   print *, temp
   if (any (temp .ne. (/100, 100, 100, 210, 210, 210, 310, 310, 337, 337/))) &
      call abort
end program
[karma] f90/bug% gfc -O3 where_2.f90
[karma] f90/bug% a.out 
         100         100         100         210         210         210       
 310         337         310         310
Abort
[karma] f90/bug% gfc -m64 -O3 where_2.f90
[karma] f90/bug% a.out
         100         100         100         210         210         210       
 310         337         310         337
Abort

Note that the content of temp change with the mode.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[dominiq at lps dot ens dot fr]

------- Comment #18 from dominiq at lps dot ens dot fr  2009-12-15 17:47 -------
The tests (with/without print) pass at revision 149806 (a clean bootstrap of
149805, followed by an update to 149806). I am currently bootstrapping 149852.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[dominiq at lps dot ens dot fr]

------- Comment #19 from dominiq at lps dot ens dot fr  2009-12-16 09:22 -------
Created an attachment (id=19320)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19320&action=view)
assembly and dump files for r149941 and r149942

Compressed archive with the assembly (with -m64 -O3) and the dump (with
-fdump-tree-vect) files of
gcc/testsuite/gfortran.fortran-torture/execute/where_2.f90. Files with 941 and
942 in their names correspond respectively to revisions 149941 and r149942.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[dominiq at lps dot ens dot fr]

------- Comment #20 from dominiq at lps dot ens dot fr  2009-12-16 09:27 -------
The regression reported in comment #0 is due to revision 149942:

Author: matz
Date:   Wed Jul 22 15:30:50 2009 UTC (4 months, 3 weeks ago)
Changed paths:  4
Log Message:    
        PR tree-optimization/35229
        PR tree-optimization/39300

        * tree-ssa-pre.c (includes): Include tree-scalar-evolution.h.
        (inhibit_phi_insertion): New function.
        (insert_into_preds_of_block): Call it for REFERENCEs.
        (init_pre): Initialize and finalize scalar evolutions.
        * Makefile.in (tree-ssa-pre.o): Depend on tree-scalar-evolution.h .

testsuite/
        * gcc.dg/vect/vect-pre-interact.c: New test.

At revision 149941 I get:

[karma] f90/bug% gfcp -m64 -O3
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.fortran-torture/execute/where_2.f90
-ftree-vectorizer-verbose=2

/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.fortran-torture/execute/where_2.f90:5:
note: LOOP VECTORIZED.
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.fortran-torture/execute/where_2.f90:22:
note: vectorized 1 loops in function.

at revision 149942:

[karma] f90/bug% gfcp -m64 -O3
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.fortran-torture/execute/where_2.f90
-ftree-vectorizer-verbose=2

/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.fortran-torture/execute/where_2.f90:11:
note: LOOP VECTORIZED.
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.fortran-torture/execute/where_2.f90:11:
note: not vectorized: relevant stmt not supported: cond.23_59 = D.1306_58 > 6;

/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.fortran-torture/execute/where_2.f90:11:
note: not vectorized: relevant stmt not supported: cond.15_39 = D.1316_38 == 0;

/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.fortran-torture/execute/where_2.f90:11:
note: not vectorized: relevant stmt not supported: cond.9_26 = D.1320_25 < 0;

/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.fortran-torture/execute/where_2.f90:5:
note: LOOP VECTORIZED.
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.fortran-torture/execute/where_2.f90:22:
note: vectorized 2 loops in function.

I just posted a compressed archive with the corresponding assembly and dump
files (for the testsuite case, i.e. without print).


-- 

dominiq at lps dot ens dot fr changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |matz at suse dot de


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[irar at il dot ibm dot com]

------- Comment #21 from irar at il dot ibm dot com  2009-12-16 12:01 -------
Thanks. 
I'll be able to look at this only on Sunday due to holidays.

Ira


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[matz at gcc dot gnu dot org]

------- Comment #22 from matz at gcc dot gnu dot org  2009-12-16 23:36 -------
My patch only enables more vectorization.  This seems to uncover a problem
in the vectorizer (which I haven't yet looked at).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[irar at il dot ibm dot com]

------- Comment #23 from irar at il dot ibm dot com  2009-12-20 12:18 -------
The code that now gets vectorized is the summation of array 'reduce':
sum(reduce). It looks like the problem is with adding the reduction result to
the correct index of 'temp' (scalar code), and not with the reduction itself.
Could you please verify that by printing the reduction result?

Thanks,
Ira


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[dominiq at lps dot ens dot fr]

------- Comment #24 from dominiq at lps dot ens dot fr  2009-12-20 12:46 -------
> The code that now gets vectorized is the summation of array 'reduce':
> sum(reduce). It looks like the problem is with adding the reduction result to
> the correct index of 'temp' (scalar code), and not with the reduction itself.
> Could you please verify that by printing the reduction result?

I have changed the code to:

program where_2
   integer temp(10), reduce(10), tmp(10)

   temp = 10
   reduce(1:3) = -1 
   reduce(4:6) = 0
   reduce(7:8) = 5 
   reduce(9:10) = 10
   tmp = 0

   WHERE (reduce < 0) 
      temp = 100 
   ELSE WHERE (reduce .EQ. 0)
      temp = 200 + temp
   ELSE WHERE 
      WHERE (reduce > 6) tmp = sum(reduce)
      temp = 300 + temp + tmp
   END WHERE

   print *, temp
   print *, tmp
   if (any (temp .ne. (/100, 100, 100, 210, 210, 210, 310, 310, 337, 337/))) &
      call abort
end program

And with r155350 I get

[karma] f90/bug% gfc -O3 where_2_db.f90
[karma] f90/bug% a.out
         100         100         100         210         210         210       
 310         337         310         310
           0           0           0           0           0           0       
   0          27           0           0
Abort
[karma] f90/bug% gfc -m64 -O3 where_2_db.f90
[karma] f90/bug% a.out
         100         100         100         210         210         210       
 310         310         337         337
           0           0           0           0           0           0       
   0           0          27          27
[karma] f90/bug%

while with r151300 I get:

[karma] f90/bug% gfcp -O3 where_2_db.f90
[karma] f90/bug% a.out
         100         100         100         210         210         210       
 310         310         337         337
           0           0           0           0           0           0       
   0           0          27          27
[karma] f90/bug% gfcp -m64 -O3 where_2_db.f90
[karma] f90/bug% a.out
         100         100         100         210         210         210       
 310         310         310         310
           0           0           0           0           0           0       
   0           0           0           0
Abort
[karma] f90/bug%

So sum(reduce) gives the right result, but apparently it is not stored in the
right place.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[rguenth at gcc dot gnu dot org]

------- Comment #25 from rguenth at gcc dot gnu dot org  2009-12-20 13:33 -------
Works on i?86-linux, the reduction is vectorized as well.  Does

program where_2
   integer reduce(10), tmp(10)

   tmp = 0
   reduce(1:3) = -1
   reduce(4:6) = 0
   reduce(7:8) = 5
   reduce(9:10) = 10

   WHERE (reduce > 6) tmp = sum(reduce)

   print *, tmp
end program

already fail for you?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[irar at il dot ibm dot com]

------- Comment #26 from irar at il dot ibm dot com  2009-12-20 13:46 -------
I think the problem is in alignment. We force alignment of temp.6 and temp.20 -
the arrays of relevant comaprison results - even though we don't vectorize
their loop. The decision whether we can force alignment is made in
vect_can_force_dr_alignment_p(), and it seems that the only target specific
query there is comparison with MAX_STACK_ALIGNMENT.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[rguenther at suse dot de]

------- Comment #27 from rguenther at suse dot de  2009-12-20 13:48 -------
Subject: Re:  [4.5 Regression] FAIL:
 gfortran.fortran-torture/execute/where_2.f90 execution,  -O3 -g with -m64

On Sun, 20 Dec 2009, irar at il dot ibm dot com wrote:

> ------- Comment #26 from irar at il dot ibm dot com  2009-12-20 13:46 -------
> I think the problem is in alignment. We force alignment of temp.6 and temp.20 -
> the arrays of relevant comaprison results - even though we don't vectorize
> their loop. The decision whether we can force alignment is made in
> vect_can_force_dr_alignment_p(), and it seems that the only target specific
> query there is comparison with MAX_STACK_ALIGNMENT.

That sounds odd.  If we don't make use of the extra alignment how
should it affect generated code or even correctness?

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[irar at il dot ibm dot com]

------- Comment #28 from irar at il dot ibm dot com  2009-12-20 13:59 -------
Hm, I don't know, but this is my best guess - we change something in the code
that goes wrong...

We also force alignment of reduce, but the reduction computation looks ok.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[dominiq at lps dot ens dot fr]

------- Comment #29 from dominiq at lps dot ens dot fr  2009-12-20 14:19 -------
> Works on i?86-linux, the reduction is vectorized as well. 

Yes I know, this is specific to ppc-darwin.

> Does
>
> ...
>    WHERE (reduce > 6) tmp = sum(reduce)
> ...
>
> already fail for you?

No, this test works fine in 32 and 64 bit modes with -O3.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[irar at il dot ibm dot com]

------- Comment #30 from irar at il dot ibm dot com  2009-12-22 11:42 -------
We can try to verify the alignment issue by applying the two hacks I am
attaching. 

The first one disables alignment forcing for all the data-refs (and marks the
alignment as unknown). The loops are still vectorizable using peeling -
hopefully, they are also vectorizable on darwin. So, if the results are correct
and the two loops are vectorized, then the problem is in alignment. If the
results are incorrect, the problem is in vectorization.

The second one still forces alignment of the vectorized arrays, but not of the
other arrays. With -fdump-tree-vect-details (or verbosity 9) it prints "force
alignment of <data-ref>", so we can verify that the correct arrays were aligned
(reduce line 11 and temp line 5). So, here, the loops should be vectorized as
before and only the alignment of not vectorized arrays will not be forced.

Dominique, could you please check this?

Thanks,
Ira


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[irar at il dot ibm dot com]

------- Comment #31 from irar at il dot ibm dot com  2009-12-22 11:43 -------
Created an attachment (id=19370)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19370&action=view)
disable alignment forcing


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[irar at il dot ibm dot com]

------- Comment #32 from irar at il dot ibm dot com  2009-12-22 11:44 -------
Created an attachment (id=19371)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19371&action=view)
force alignment of vectorized arrays only


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[dominiq at lps dot ens dot fr]

------- Comment #33 from dominiq at lps dot ens dot fr  2009-12-22 16:42 -------
> Dominique, could you please check this?

The patch in comment #31 fixes this pr:

[karma] f90/bug% gfc -O3 -ftree-vectorizer-verbose=2 where_2.f90

where_2.f90:11: note: LOOP VECTORIZED.
where_2.f90:11: note: not vectorized: relevant stmt not supported: cond.23_79 =
D.1255_78 > 6;

where_2.f90:11: note: not vectorized: relevant stmt not supported: cond.15_57 =
D.1238_56 == 0;

where_2.f90:11: note: not vectorized: relevant stmt not supported: cond.9_43 =
D.1227_42 < 0;

where_2.f90:5: note: LOOP VECTORIZED.
where_2.f90:2: note: vectorized 2 loops in function.
[karma] f90/bug% a.out 
         100         100         100         210         210         210       
 310         310         337         337
[karma] f90/bug% 

with the same result with -m64.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[dominiq at lps dot ens dot fr]

------- Comment #34 from dominiq at lps dot ens dot fr  2009-12-22 16:56 -------
The patch in comment #32 (without the one in comment #31) does fix the pr:

[karma] f90/bug% gfc -O3 -ftree-vectorizer-verbose=2 where_2.f90

where_2.f90:11: note: LOOP VECTORIZED.
where_2.f90:11: note: not vectorized: relevant stmt not supported: cond.23_79 =
D.1255_78 > 6;

where_2.f90:11: note: not vectorized: relevant stmt not supported: cond.15_57 =
D.1238_56 == 0;

where_2.f90:11: note: not vectorized: relevant stmt not supported: cond.9_43 =
D.1227_42 < 0;

where_2.f90:5: note: LOOP VECTORIZED.
where_2.f90:2: note: vectorized 2 loops in function.
[karma] f90/bug% a.out
         100         100         100         210         210         210       
 310         337         310         310
Abort
[karma] f90/bug% gfc -m64 -O3 -ftree-vectorizer-verbose=2 where_2.f90

where_2.f90:11: note: LOOP VECTORIZED.
where_2.f90:11: note: not vectorized: relevant stmt not supported: cond.23_79 =
D.1270_78 > 6;

where_2.f90:11: note: not vectorized: relevant stmt not supported: cond.15_57 =
D.1253_56 == 0;

where_2.f90:11: note: not vectorized: relevant stmt not supported: cond.9_43 =
D.1242_42 < 0;

where_2.f90:5: note: LOOP VECTORIZED.
where_2.f90:2: note: vectorized 2 loops in function.
[karma] f90/bug% a.out
         100         100         100         210         210         210       
 310         337         310         337
Abort

I'll attach the result of '-O3 -ftree-vectorizer-verbose=9'  for
gcc/testsuite/gfortran.fortran-torture/execute/where_2.f90.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[dominiq at lps dot ens dot fr]

------- Comment #35 from dominiq at lps dot ens dot fr  2009-12-22 16:59 -------
Created an attachment (id=19372)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19372&action=view)
result of "gfc -O3 -ftree-vectorizer-verbose=9
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.fortran-torture/execute/where_2.f90"


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[irar at il dot ibm dot com]

------- Comment #36 from irar at il dot ibm dot com  2009-12-23 07:54 -------
Thanks!
So, it is alignment of the vectorized arrays. I'd like to do two more checks:
1. Just force alignment of the two arrays (temp and reduce) and do not
vectorize.
2. Force alignment of reduce only (and vectorize both loops).
I am attaching the hacks. Could you please chesk this as well?

Thanks,
Ira


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[irar at il dot ibm dot com]

------- Comment #37 from irar at il dot ibm dot com  2009-12-23 07:54 -------
Created an attachment (id=19377)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19377&action=view)
Force alignment but don't vectorize


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[irar at il dot ibm dot com]

------- Comment #38 from irar at il dot ibm dot com  2009-12-23 07:55 -------
Created an attachment (id=19378)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19378&action=view)
Force alignment of reduce only


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[dominiq at lps dot ens dot fr]

------- Comment #39 from dominiq at lps dot ens dot fr  2009-12-23 14:09 -------
With the patch in comment #37, the tests pass, but are not vectorized. I did a
mistake after applying the patch in comment #38 and I am doing a "quick"
bootstrap (~5h).

I have regtested the patch in comment #31 and I have ~75 regressions on
x86_64-apple-darwin10 in the gcc vect test suite (~100 on
powerpc-apple-darwin9). Is this expected? and do you want the list?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[irar at il dot ibm dot com]

------- Comment #40 from irar at il dot ibm dot com  2009-12-23 14:49 -------
(In reply to comment #39)
> I have regtested the patch in comment #31 and I have ~75 regressions on
> x86_64-apple-darwin10 in the gcc vect test suite (~100 on
> powerpc-apple-darwin9). Is this expected? and do you want the list?

Yes, it is expected, it is not a bug fixing patch (as well as the rest of the
hacks I asked you to check), it disables a feature - alignment forcing, so some
tests are supposed to fail.

Thanks,
Ira


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[dominiq at lps dot ens dot fr]

------- Comment #41 from dominiq at lps dot ens dot fr  2009-12-23 23:34 -------
With the patch in comment #38, the tests fail:

[karma] f90/bug% gfcp -O3 where_2.f90 
[karma] f90/bug% a.out 
         100         100         100         210         210         210       
 310         337         310         310
Abort
[karma] f90/bug% gfcp -m64 -O3 where_2.f90
[karma] f90/bug% a.out
         100         100         100         210         210         210       
 310         310         337         310
Abort


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[irar at il dot ibm dot com]

------- Comment #42 from irar at il dot ibm dot com  2010-01-05 09:09 -------
So, it's enough to force alignment of reduce only (and to vectorize its loop)
to get wrong code. On the other hand, the result of the vectorized loop is
correct, and the problem is in choosing the correct index of temp.

The assembly looks fine to me. So, for me the only way to proceed is to debug.
Dominique, is it possible to access your machine?

Ira


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[irar at il dot ibm dot com]

------- Comment #43 from irar at il dot ibm dot com  2010-01-10 13:43 -------
Since -O2 -ftree-vectorize doesn't cause bad code, it has to be some other
optimization on top of vectorized code that causes the problem.

Bad code is generated when the alignment of 'reduce' is forced and the
reduction 'sum(reduce)' is vectorized. However, the result of the reduction is
correct, and the vector store element does not do any damage (as far as I can
see in debugger). So, the vector stores don't corrupt anything.

The part that goes wrong is in the scalar code that implements the decision on
whether to add the (correctly computed) reduction value to temp[9] and
temp[10]. The code that sets the condition, (which, by the way, is not using
any vectorized code) is not using the values of  reduce[9] and reduce[10], even
though the value of the condition depends on them:

reduce(1:3) = -1
reduce(4:6) = 0
reduce(7:8) = 5
reduce(9:10) = 10
...
WHERE (reduce > 6) temp = temp + sum(reduce) 


Here is the code for adding the result of the "sum(reduce)" to temp[9]:

L29:
        lbz r11,152(r1)  # **
        cmpwi cr7,r11,0  # reduce > 6 ?
        beq cr7,L30
        lwz r11,240(r1)  # load temp[9]
        add r11,r11,r9   # temp[9] + sum(reduce) 
        stw r11,240(r1)  # store temp[9]

** - The calculation of 152(r1) is based only on the value of reduce[8]! The
values of reduce[9] and reduce[10] are only used in the reduction calculation
and not compared to 6 at all.

In case we don't vectorize (but force the alignment), there is cmpwi cr7,r29,6
instruction, where r29 is reduce[9] (and the code is correct). The same happens
when the alignment of reduce is not forced and the reduction is vectorized
using peeling. 

I.e., as far as I can see, in the bad code, the comparison of reduce[9] and
reduce[10] with 6 do not exist. I wonder which optimization can be responsible
for that?


Also, some values of reduce are copied to a temporal array and are further
compared with 6. In  the version with peeling the values that are copied are
reduce[4:8]: there is no need to keep the first three and the last two are kept
in registers and compared to 6 (and also used in reduction epilogue). While in
the bad version the kept values are reduce[3:8] and reduce[8] is put before the
values of reduce[3:7] (reduce[3:7] are in 276(r1) to 292(r1), and reduce[8] is
in 272(r1)). (And in the bad code the last two values reduce[9] and reduce[10]
are only used in reduction epilogue).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[dominiq at lps dot ens dot fr]

------- Comment #44 from dominiq at lps dot ens dot fr  2010-01-10 14:21 -------
Created an attachment (id=19528)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19528&action=view)
s


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[dominiq at lps dot ens dot fr]

------- Comment #45 from dominiq at lps dot ens dot fr  2010-01-10 14:23 -------
The attachment in comment#44 is for the bad code.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[dominiq at lps dot ens dot fr]

------- Comment #46 from dominiq at lps dot ens dot fr  2010-01-10 14:25 -------
Created an attachment (id=19529)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19529&action=view)
assembly for the good code

the good code: alignment of 'reduce' is not forced and the loop is vectorized
using peeling.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[rguenth at gcc dot gnu dot org]

------- Comment #47 from rguenth at gcc dot gnu dot org  2010-04-06 11:20 -------
GCC 4.5.0 is being released.  Deferring to 4.5.1.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.5.0                       |4.5.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3 -g with -m64

[tkoenig at gcc dot gnu dot org]

------- Comment #48 from tkoenig at gcc dot gnu dot org  2010-05-13 18:04 -------
Any news on this?


-- 

tkoenig at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tkoenig at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3

[dominiq at lps dot ens dot fr]

------- Comment #49 from dominiq at lps dot ens dot fr  2010-05-14 09:28 -------
> Any news on this?

Still there at revision 159329. Ira Rosen has devoted a fair amount of time to
trace the problem, but nobody cared to pursue.

Presently this PR has nothing to do with -g nor -ma64, so I updated the
summary.

Note that bootstrapping gcc on powerpc-apple-darwin9 is broken since revision
159339!-(each time a fix is posted an other breakage follows).


-- 

dominiq at lps dot ens dot fr changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.5/4.6 Regression] FAIL:  |[4.5/4.6 Regression] FAIL:
                   |gfortran.fortran-           |gfortran.fortran-
                   |torture/execute/where_2.f90 |torture/execute/where_2.f90
                   |execution,  -O3 -g with -m64|execution,  -O3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3

[dominiq at lps dot ens dot fr]

------- Comment #50 from dominiq at lps dot ens dot fr  2010-07-25 10:20 -------
Between revisions 162269 and 162477 this pr has been fixed for -m64 (but not
for -m32).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3

[rguenth at gcc dot gnu dot org]

------- Comment #51 from rguenth at gcc dot gnu dot org  2010-07-31 09:29 -------
GCC 4.5.1 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.5.1                       |4.5.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082

[Bug middle-end/41082] [4.5/4.6 Regression] FAIL: gfortran.fortran-torture/execute/where_2.f90 execution, -O3

[dominiq at lps dot ens dot fr]

------- Comment #52 from dominiq at lps dot ens dot fr  2010-08-06 07:33 -------
The miscompilation with -m64 is back at revision 162879.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082