[Bug target/56865] New: [4.9 regression] FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times vect "Vectorizing an unaligned access" 4

[Bug target/56865] New: [4.9 regression] FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times vect "Vectorizing an unaligned access" 4

[schwab@linux-m68k.org]

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

             Bug #: 56865
           Summary: [4.9 regression] FAIL: gcc.dg/vect/vect-42.c
                    scan-tree-dump-times vect "Vectorizing an unaligned
                    access" 4
    Classification: Unclassified
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: schwab@linux-m68k.org
            Target: powerpc*-*-*


Created attachment 29819
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29819
vect-42.c.111t.vect

spawn /daten/gcc/gcc-20130406/Build/gcc/xgcc
-B/daten/gcc/gcc-20130406/Build/gcc/
/daten/gcc/gcc-20130406/gcc/testsuite/gcc.dg/vect/vect-42.c
-fno-diagnostics-show-caret -maltivec -ftree-vectorize -fno-vect-cost-model
-fno-common -O2 -fdump-tree-vect-details -lm -m32 -o ./vect-42.exe
PASS: gcc.dg/vect/vect-42.c (test for excess errors)
Setting LD_LIBRARY_PATH to
:/daten/gcc/gcc-20130406/Build/gcc:/daten/gcc/gcc-20130406/Build/gcc/64::/daten/gcc/gcc-20130406/Build/gcc:/daten/gcc/gcc-20130406/Build/gcc/64:/daten/gcc/gcc-20130406/Build/powerpc64-linux/libstdc++-v3/src/.libs:/daten/gcc/gcc-20130406/Build/powerpc64-linux/libmudflap/.libs:/daten/gcc/gcc-20130406/Build/powerpc64-linux/libsanitizer/.libs:/daten/gcc/gcc-20130406/Build/powerpc64-linux/libssp/.libs:/daten/gcc/gcc-20130406/Build/powerpc64-linux/libgomp/.libs:/daten/gcc/gcc-20130406/Build/powerpc64-linux/libitm/.libs:/daten/gcc/gcc-20130406/Build/powerpc64-linux/libatomic/.libs:/daten/gcc/gcc-20130406/Build/./gcc:/daten/gcc/gcc-20130406/Build/./prev-gcc
spawn [open ...]
PASS: gcc.dg/vect/vect-42.c execution test
PASS: gcc.dg/vect/vect-42.c scan-tree-dump-times vect "vectorized 2 loops" 1
FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times vect "Vectorizing an unaligned
access" 4
FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times vect "Alignment of access
forced using peeling" 1

Fails for both -m32 and -m64.

Configured with: ../configure --prefix=/usr --build=powerpc64-linux
--enable-checking=release --enable-shared --with-system-zlib
--with-cpu=default32 --with-cpu-64=power4 --enable-secureplt
--with-long-double-128

[Bug target/56865] [4.9 regression] FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times vect "Vectorizing an unaligned access" 4

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-04-07
     Ever Confirmed|0                           |1

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2013-04-07 15:08:53 UTC ---
Confirmed on powerpc-apple-darwin9 for -m32. For -m64 I get

PASS: gcc.dg/vect/vect-42.c execution test
PASS: gcc.dg/vect/vect-42.c scan-tree-dump-times vect "vectorized 2 loops" 1
PASS: gcc.dg/vect/vect-42.c scan-tree-dump-times vect "Alignment of access
forced using versioning" 1
XFAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times vect "Vectorizing an
unaligned access" 4
XFAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times vect "Alignment of access
forced using peeling" 1

One of the following conditions 

{ vect_no_align || { { !  vector_alignment_reachable } || vect_element_align  }
}

must be true on a G5 under powerpc-apple-darwin9.

[Bug target/56865] [4.9 regression] FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times vect "Vectorizing an unaligned access" 4

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.9.0

[Bug target/56865] [4.9 regression] FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times vect "Vectorizing an unaligned access" 4

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt <wschmidt at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org,
                   |                            |wschmidt at gcc dot gnu.org

--- Comment #2 from Bill Schmidt <wschmidt at gcc dot gnu.org> 2013-05-01 21:58:09 UTC ---
I've reproduced this as well.  Additionally, gcc.dg/vect/vect-96.c fails
similarly.  Both tests began failing at r196872:

2013-03-21  Richard Biener  <rguenther@suse.de>

    * tree-vect-data-refs.c (vect_update_interleaving_chain): Remove.
    (vect_insert_into_interleaving_chain): Likewise.
    (vect_drs_dependent_in_basic_block): Inline ...
    (vect_slp_analyze_data_ref_dependence): ... here.  New function,
    split out from ...
    (vect_analyze_data_ref_dependence): ... here.  Simplify.
    (vect_check_interleaving): Simplify.
    (vect_analyze_data_ref_dependences): Likewise.  Split out ...
    (vect_slp_analyze_data_ref_dependences): ... this new function.
    (dr_group_sort_cmp): New function.
    (vect_analyze_data_ref_accesses): Compute data-reference groups
    here instead of in vect_analyze_data_ref_dependence.  Use
    a more efficient algorithm.
    * tree-vect-slp.c (vect_slp_analyze_bb_1): Use
    vect_slp_analyze_data_ref_dependences.  Call
    vect_analyze_data_ref_accesses earlier.
    * tree-vect-loop.c (vect_analyze_loop_2): Likewise.
    * tree-vectorizer.h (vect_analyze_data_ref_dependences): Adjust.
    (vect_slp_analyze_data_ref_dependences): New prototype.

Richi, I think this commit was not intended to have any functional effect -- is
that correct?

[Bug target/56865] [4.9 regression] FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times vect "Vectorizing an unaligned access" 4

[rguenther at suse dot de]

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

--- Comment #3 from rguenther at suse dot de <rguenther at suse dot de> 2013-05-02 07:37:55 UTC ---
On Wed, 1 May 2013, wschmidt at gcc dot gnu.org wrote:

> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56865
> 
> Bill Schmidt <wschmidt at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |rguenth at gcc dot gnu.org,
>                    |                            |wschmidt at gcc dot gnu.org
> 
> --- Comment #2 from Bill Schmidt <wschmidt at gcc dot gnu.org> 2013-05-01 21:58:09 UTC ---
> I've reproduced this as well.  Additionally, gcc.dg/vect/vect-96.c fails
> similarly.  Both tests began failing at r196872:
> 
> 2013-03-21  Richard Biener  <rguenther@suse.de>
> 
>     * tree-vect-data-refs.c (vect_update_interleaving_chain): Remove.
>     (vect_insert_into_interleaving_chain): Likewise.
>     (vect_drs_dependent_in_basic_block): Inline ...
>     (vect_slp_analyze_data_ref_dependence): ... here.  New function,
>     split out from ...
>     (vect_analyze_data_ref_dependence): ... here.  Simplify.
>     (vect_check_interleaving): Simplify.
>     (vect_analyze_data_ref_dependences): Likewise.  Split out ...
>     (vect_slp_analyze_data_ref_dependences): ... this new function.
>     (dr_group_sort_cmp): New function.
>     (vect_analyze_data_ref_accesses): Compute data-reference groups
>     here instead of in vect_analyze_data_ref_dependence.  Use
>     a more efficient algorithm.
>     * tree-vect-slp.c (vect_slp_analyze_bb_1): Use
>     vect_slp_analyze_data_ref_dependences.  Call
>     vect_analyze_data_ref_accesses earlier.
>     * tree-vect-loop.c (vect_analyze_loop_2): Likewise.
>     * tree-vectorizer.h (vect_analyze_data_ref_dependences): Adjust.
>     (vect_slp_analyze_data_ref_dependences): New prototype.
> 
> Richi, I think this commit was not intended to have any functional effect -- is
> that correct?

Correct.  Dumping order is affected by the patch though, thus if
we previously disabled vectorization at some point the dumping
before that can be affected due to the re-ordering.

[Bug target/56865] [4.9 regression] FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times vect "Vectorizing an unaligned access" 4

[wschmidt at gcc dot gnu.org]

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

--- Comment #4 from Bill Schmidt <wschmidt at gcc dot gnu.org> 2013-05-02 15:27:08 UTC ---
(In reply to comment #3)
> 
> Correct.  Dumping order is affected by the patch though, thus if
> we previously disabled vectorization at some point the dumping
> before that can be affected due to the re-ordering.

It appears that we are vectorizing the same loops, but we are now vectorizing
one loop differently.  In r196871, the loop is peeled for alignment.  In
r196872, the loop is versioned for alignment.  

I will attach the vectorization detail dumps for the two revisions.

[Bug target/56865] [4.9 regression] FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times vect "Vectorizing an unaligned access" 4

[wschmidt at gcc dot gnu.org]

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

--- Comment #5 from Bill Schmidt <wschmidt at gcc dot gnu.org> 2013-05-02 15:29:10 UTC ---
Created attachment 30001
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30001
Vectorization details dump for r196871

[Bug target/56865] [4.9 regression] FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times vect "Vectorizing an unaligned access" 4

[wschmidt at gcc dot gnu.org]

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

--- Comment #6 from Bill Schmidt <wschmidt at gcc dot gnu.org> 2013-05-02 15:29:51 UTC ---
Created attachment 30002
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30002
Vectorization details dump for r196872

[Bug target/56865] [4.9 regression] FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times vect "Vectorizing an unaligned access" 4

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org

[Bug target/56865] [4.9 regression] FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times vect "Vectorizing an unaligned access" 4

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
Doesn't fail anymore according to

http://gcc.gnu.org/ml/gcc-testresults/2013-10/msg01946.html

[Bug target/56865] [4.9 regression] FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times vect "Vectorizing an unaligned access" 4

[wschmidt at gcc dot gnu.org]

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

--- Comment #8 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
vect-96.c is still broken per
http://gcc.gnu.org/ml/gcc-testresults/2013-10/msg02115.html.

FAIL: gcc.dg/vect/vect-96.c scan-tree-dump-times vect "Vectorizing an unaligned
access" 1
FAIL: gcc.dg/vect/vect-96.c scan-tree-dump-times vect "Alignment of access
forced using peeling" 1

[Bug target/56865] [4.9 regression] FAIL: gcc.dg/vect/vect-96.c scan-tree-dump-times vect "Alignment of access forced using peeling" 1

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |---
            Summary|[4.9 regression] FAIL:      |[4.9 regression] FAIL:
                   |gcc.dg/vect/vect-42.c       |gcc.dg/vect/vect-96.c
                   |scan-tree-dump-times vect   |scan-tree-dump-times vect
                   |"Vectorizing an unaligned   |"Alignment of access forced
                   |access" 4                   |using peeling" 1

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
Ok, hijacking this report for that case.

We get instead of peeling

/space/rguenther/src/svn/trunk/gcc/testsuite/gcc.dg/vect/vect-96.c:22:3: note:
Alignment of access forced using versioning.

We disable peeling because:

  if (do_peeling && !dr0)
    {
      /* Peeling is possible, but there is no data access that is not supported
         unless aligned. So we try to choose the best possible peeling.  */

      /* We should get here only if there are drs with known misalignment.  */
      gcc_assert (!all_misalignments_unknown);

      /* Choose the best peeling from the hash table.  */
      dr0 = vect_peeling_hash_choose_best_peeling (loop_vinfo, &npeel,
                                                   &body_cost_vec);
      if (!dr0 || !npeel)
        do_peeling = false;

npeel == 0 as best peeling for

#(Data Ref: 
#  bb: 4 
#  stmt: _6 = ib[i_17];
#  ref: ib[i_17];
#  base_object: ib;
#  Access function 0: {0, +, 1}_1
#)

where ib is stack-local and thus aligned.

I can see how this makes sense.  Note the testcase contains undefined
behavior (reads from uninitialized memory).

What happens here is that the processing order of DRs in

  FOR_EACH_VEC_ELT (datarefs, i, dr)
    {
...
    }

changed and the resulting dr0 is different.

I'll try to fix the ordering issue but the new result makes sense (and it
won't be changed by the fix).  For

  for (i = 0; i < N; i++)
      pp->ia[i] = ib[i];

it seems misaligning the store is not supported at all on PPC?  The code
doesn't seem to be setup to handle that case properly.  But that's hardly
a regression.

To catch that the code should loop over all DRs, look for
!vect_supportable_dr_alignment () and see whether they all share the
same known misalignment.  If, then peel to align them all at the same
time, if not, then there is no point in peeling (we discover that
later anyway).

[Bug target/56865] [4.9 regression] FAIL: gcc.dg/vect/vect-96.c scan-tree-dump-times vect "Alignment of access forced using peeling" 1

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 31103
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31103&action=edit
untested patch

Patch I am testing on x86_64-linux - can you give ppc/ppc64 a try?  This should
make behavior independent on the order of DRs (modulo hash table walking
and same-count/npeel DRs), especially always force to peel a
dr_unaligned_unsupported ref.

[Bug target/56865] [4.9 regression] FAIL: gcc.dg/vect/vect-96.c scan-tree-dump-times vect "Alignment of access forced using peeling" 1

[wschmidt at gcc dot gnu.org]

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

--- Comment #11 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
Thanks, Richi -- yes, I'll give this a try later today (lots of meetings in the
way but I'll get to it sooner or later).

Bill

[Bug target/56865] [4.9 regression] FAIL: gcc.dg/vect/vect-96.c scan-tree-dump-times vect "Alignment of access forced using peeling" 1

[rguenther at suse dot de]

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

--- Comment #12 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 29 Oct 2013, wschmidt at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56865
> 
> --- Comment #11 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
> Thanks, Richi -- yes, I'll give this a try later today (lots of meetings in the
> way but I'll get to it sooner or later).

Seems to have a bug - let me fix that first.

[Bug target/56865] [4.9 regression] FAIL: gcc.dg/vect/vect-96.c scan-tree-dump-times vect "Alignment of access forced using peeling" 1

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #31103|0                           |1
        is obsolete|                            |

--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 31104
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31104&action=edit
fixed patch

Passed bootstrap on x86_64-unknown-linux-gnu, testing in progress.

[Bug target/56865] [4.9 regression] FAIL: gcc.dg/vect/vect-96.c scan-tree-dump-times vect "Alignment of access forced using peeling" 1

[wschmidt at gcc dot gnu.org]

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

--- Comment #14 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
Hi Richi,

Passes bootstrap on powerpc64-unknown-linux-gnu and fixes this test, but breaks
two others:

57,60c57,68
< FAIL: gcc.dg/vect/vect-96.c scan-tree-dump-times vect "Vectorizing an
unaligned access" 1
< FAIL: gcc.dg/vect/vect-96.c scan-tree-dump-times vect "Alignment of access
forced using peeling" 1
< FAIL: gcc.dg/vect/vect-96.c -flto  scan-tree-dump-times vect "Vectorizing an
unaligned access" 1
< FAIL: gcc.dg/vect/vect-96.c -flto  scan-tree-dump-times vect "Alignment of
access forced using peeling" 1
---
> FAIL: gcc.dg/vect/vect-multitypes-1.c scan-tree-dump-times vect "vectorized 1 loops" 2
> FAIL: gcc.dg/vect/vect-multitypes-1.c scan-tree-dump-times vect "Alignment of access forced using peeling" 2
> FAIL: gcc.dg/vect/vect-multitypes-1.c scan-tree-dump-times vect "Vectorizing an unaligned access" 4
> FAIL: gcc.dg/vect/vect-multitypes-4.c scan-tree-dump-times vect "vectorized 1 loops" 2
> FAIL: gcc.dg/vect/vect-multitypes-4.c scan-tree-dump-times vect "Alignment of access forced using peeling" 2
> FAIL: gcc.dg/vect/vect-multitypes-4.c scan-tree-dump-times vect "Vectorizing an unaligned access" 8
> FAIL: gcc.dg/vect/vect-multitypes-1.c -flto  scan-tree-dump-times vect "vectorized 1 loops" 2
> FAIL: gcc.dg/vect/vect-multitypes-1.c -flto  scan-tree-dump-times vect "Alignment of access forced using peeling" 2
> FAIL: gcc.dg/vect/vect-multitypes-1.c -flto  scan-tree-dump-times vect "Vectorizing an unaligned access" 4
> FAIL: gcc.dg/vect/vect-multitypes-4.c -flto  scan-tree-dump-times vect "vectorized 1 loops" 2
> FAIL: gcc.dg/vect/vect-multitypes-4.c -flto  scan-tree-dump-times vect "Alignment of access forced using peeling" 2
> FAIL: gcc.dg/vect/vect-multitypes-4.c -flto  scan-tree-dump-times vect "Vectorizing an unaligned access" 8
67,68c75,76
< # of expected passes        94200
< # of unexpected failures    56
---
> # of expected passes		94192
> # of unexpected failures	64
>From gcc-bugs-return-432929-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Oct 29 17:46:06 2013
Return-Path: <gcc-bugs-return-432929-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 5877 invoked by alias); 29 Oct 2013 17:46:06 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 5841 invoked by uid 48); 29 Oct 2013 17:46:03 -0000
From: "rrodrigues at poli dot ufrj.br" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/58913] New: Segmentation fault on real128 array
Date: Tue, 29 Oct 2013 17:46:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.8.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: major
X-Bugzilla-Who: rrodrigues at poli dot ufrj.br
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-58913-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-10/txt/msg02073.txt.bz2
Content-length: 1844

http://gcc.gnu.org/bugzilla/show_bug.cgi?idX913

            Bug ID: 58913
           Summary: Segmentation fault on real128 array
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rrodrigues at poli dot ufrj.br

I cannot "write" a variable which contains an array of real(kind=real128).
Scalars seem to work right.
I got this behavior when running this simple program:

01  program main
02    use iso_fortran_env
03    real(real128), dimension(2) :: a
04    a = (/0., 1./)
05    write(*,*) a
06  end program

>gfortran main.txt -o main    #successfully compiles!
>main                         #runtime error!

Program received signal SIGSEGV: Segmentation Fault - invalid memory reference.

Backtrace for this error:
#0 ffffffff

Same error is obtained if I:
I)   change real(real128) to real(16) in line 03
II)  change line 04 to a = (/0._real128, 1._real128)
III) change line 04 to a = real((/0., 1./), kind=real128)
IV)  declare a variable "b", assign b = a and try to write "b"
V)   try to write the value of a pointer pointing to a
VI)  make variable "a" PARAMETER, SAVE, TARGET or ALLOCATABLE

More weird is that the program successfully run if I:
a)   change line 05 to write(*,*) a(1)
b)   change line 05 to write(*,*) (/0., 1./)
b)   change line 05 to write(*,*) 2*a or any other expression whose result IS
NOT a direct reference to "a" or any other variable with real128 array.
c)   put a write statement with a value or scalar variable of kind=real128
anywhere in the program's body, no matter if before, after or even inside the
write statement of line 05
d)   change real(real128) to any other real kind in line 03
e)   make "a" scalar

Any ideas?

[Bug target/56865] [4.9 regression] FAIL: gcc.dg/vect/vect-96.c scan-tree-dump-times vect "Alignment of access forced using peeling" 1

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 31110
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31110&action=edit
revised patch

Hmm, try this one.

[Bug target/56865] [4.9 regression] FAIL: gcc.dg/vect/vect-96.c scan-tree-dump-times vect "Alignment of access forced using peeling" 1

[wschmidt at gcc dot gnu.org]

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

--- Comment #16 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
Thanks, testing in progress.

[Bug target/56865] [4.9 regression] FAIL: gcc.dg/vect/vect-96.c scan-tree-dump-times vect "Alignment of access forced using peeling" 1

[wschmidt at gcc dot gnu.org]

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

--- Comment #17 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
Initial news is not good -- I am seeing a lot of ICEs go by as the testing
proceeds, including in vect-96.c and vect-42.c.

[Bug target/56865] [4.9 regression] FAIL: gcc.dg/vect/vect-96.c scan-tree-dump-times vect "Alignment of access forced using peeling" 1

[wschmidt at gcc dot gnu.org]

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

--- Comment #18 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
spawn /home/wschmidt/gcc/build/gcc-mainline-test2/gcc/xgcc -B/home/wschmidt/gcc
/build/gcc-mainline-test2/gcc/ /home/wschmidt/gcc/gcc-mainline-test2/gcc/testsu
ite/gcc.dg/vect/vect-96.c -fno-diagnostics-show-caret -fdiagnostics-color=never
 -maltivec -mvsx -mno-allow-movmisalign -ftree-vectorize -fno-vect-cost-model -
fno-common -O2 -fdump-tree-vect-details -lm -m32 -o ./vect-96.exe
/home/wschmidt/gcc/gcc-mainline-test2/gcc/testsuite/gcc.dg/vect/vect-96.c: In f
unction 'main1':
/home/wschmidt/gcc/gcc-mainline-test2/gcc/testsuite/gcc.dg/vect/vect-96.c:16:5:
 internal compiler error: Segmentation fault
0x1068325b crash_signal
        /home/wschmidt/gcc/gcc-mainline-test2/gcc/toplev.c:334
0x10c74f90 hash_table<peel_info_hasher, xcallocator>::elements()
        /home/wschmidt/gcc/gcc-mainline-test2/gcc/hash-table.h:538
0x10c74f90 traverse<_vect_peel_extended_info*, vect_peeling_hash_get_most_frequ
ent>
        /home/wschmidt/gcc/gcc-mainline-test2/gcc/hash-table.h:947
0x10c74f90 vect_peeling_hash_choose_best_peeling
        /home/wschmidt/gcc/gcc-mainline-test2/gcc/tree-vect-data-refs.c:1248
0x10c74f90 vect_enhance_data_refs_alignment(_loop_vec_info*)
        /home/wschmidt/gcc/gcc-mainline-test2/gcc/tree-vect-data-refs.c:1662
0x108cbc53 vect_analyze_loop_2
        /home/wschmidt/gcc/gcc-mainline-test2/gcc/tree-vect-loop.c:1732
0x108cbc53 vect_analyze_loop(loop*)
        /home/wschmidt/gcc/gcc-mainline-test2/gcc/tree-vect-loop.c:1810
0x108e750b vectorize_loops()
        /home/wschmidt/gcc/gcc-mainline-test2/gcc/tree-vectorizer.c:360
0x107f866f tree_loop_vectorize
        /home/wschmidt/gcc/gcc-mainline-test2/gcc/tree-ssa-loop.c:149
0x107f866f execute
        /home/wschmidt/gcc/gcc-mainline-test2/gcc/tree-ssa-loop.c:184
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug target/56865] [4.9 regression] FAIL: gcc.dg/vect/vect-96.c scan-tree-dump-times vect "Alignment of access forced using peeling" 1

[rguenth at gcc dot gnu.org]

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

--- Comment #19 from Richard Biener <rguenth at gcc dot gnu.org> ---
This may be now fixed ...

[Bug target/56865] [4.9 regression] FAIL: gcc.dg/vect/vect-96.c scan-tree-dump-times vect "Alignment of access forced using peeling" 1

[wschmidt at gcc dot gnu.org]

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

--- Comment #20 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #19)
> This may be now fixed ...

I believe it is!  Nice work.  I don't see vect-96.c failing anymore on r207423
of trunk.  The last spectester result we have is from 1/28 on r207160.  Was the
intended fix committed between those two revisions?

If the next spectester result confirms what I'm seeing, we should be able to
close this.  Thanks for getting this working.

Bill

[Bug target/56865] [4.9 regression] FAIL: gcc.dg/vect/vect-96.c scan-tree-dump-times vect "Alignment of access forced using peeling" 1

[rguenther at suse dot de]

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

--- Comment #21 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 3 Feb 2014, wschmidt at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56865
> 
> --- Comment #20 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
> (In reply to Richard Biener from comment #19)
> > This may be now fixed ...
> 
> I believe it is!  Nice work.  I don't see vect-96.c failing anymore on r207423
> of trunk.  The last spectester result we have is from 1/28 on r207160.  Was the
> intended fix committed between those two revisions?
> 
> If the next spectester result confirms what I'm seeing, we should be able to
> close this.  Thanks for getting this working.

Should be fixed as part of the side-effect of no longer adjusting
DR order

[Bug target/56865] [4.9 regression] FAIL: gcc.dg/vect/vect-96.c scan-tree-dump-times vect "Alignment of access forced using peeling" 1

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #22 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
That would be r207225 then.

[Bug target/56865] [4.9 regression] FAIL: gcc.dg/vect/vect-96.c scan-tree-dump-times vect "Alignment of access forced using peeling" 1

[wschmidt at gcc dot gnu.org]

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

--- Comment #23 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
(In reply to Bill Schmidt from comment #20)
> (In reply to Richard Biener from comment #19)
> > This may be now fixed ...
> 
> I believe it is!  Nice work.  I don't see vect-96.c failing anymore on
> r207423 of trunk.  The last spectester result we have is from 1/28 on
> r207160.  Was the intended fix committed between those two revisions?
> 
> If the next spectester result confirms what I'm seeing, we should be able to
> close this.  Thanks for getting this working.
> 
> Bill

I meant gcc-testresults, not spectester, sorry...

[Bug target/56865] [4.9 regression] FAIL: gcc.dg/vect/vect-96.c scan-tree-dump-times vect "Alignment of access forced using peeling" 1

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt <wschmidt at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #24 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
I found some helpful gcc-testresults on a similar platform.  This test used to
fail on powerpc-ibm-aix.7.1.0.0 as well, and no longer does.  So I am happy
with this being issue being closed.

Thanks again for resolving this!

Bill