[Bug target/110776] New: [14 Regression] powerpc-darwin bootstrap broken after r14-2490 with ICE rs6000.cc:5069 building libgfortran

[Bug target/110776] New: [14 Regression] powerpc-darwin bootstrap broken after r14-2490 with ICE rs6000.cc:5069 building libgfortran

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110776

            Bug ID: 110776
           Summary: [14 Regression] powerpc-darwin bootstrap broken after
                    r14-2490 with ICE rs6000.cc:5069 building libgfortran
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: iains at gcc dot gnu.org
  Target Milestone: ---

The ICE seems to be because rs6000_builtin_vectorization_cost () is called with
a request for a misaligned load (which we do not support), It reproduces on a
cross from x86_64.

This is in compiling libgfortran generated code (so nothing Darwin-specific,
other than being an Altivec platform).

A philosophical question; if a request is made for the cost of doing something
unsupported - should we not return "infinity" rather than ICEing?  

Presumably, the alternative is that the middle end needs to know that some
kinds of operation are not supported and therefore not to try and cost them
(speculation here; I have no knowledge of the relevant code).

=====

..../gcc/cc1 -fpreprocessed .libs/reshape_i4.i -feliminate-unused-debug-symbols
-fPIC -quiet -dumpdir .libs/ -dumpbase reshape_i4.c -dumpbase-ext .c -m64
-mmacosx-version-min=10.5 -g -O2 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wextra -Wwrite-strings
-Werror=implicit-function-declaration -Werror=vla -Wunknown-pragmas -std=gnu11
-std=gnu11 -version -fcx-fortran-rules -ffunction-sections -fdata-sections
-fno-common -o .libs/reshape_i4.s

backtrace:
  * frame #0: 0x0000000101d840cd cc1`internal_error(gmsgid="in %s, at %s:%d")
at diagnostic.cc:2166:25
    frame #1: 0x0000000101d845b3
cc1`fancy_abort(file="/src-local/gcc-master/gcc/config/rs6000/rs6000.cc",
line=5069, function="rs6000_builtin_vectorization_cost") at
diagnostic.cc:2296:18
    frame #2: 0x0000000101accf54
cc1`::rs6000_builtin_vectorization_cost(type_of_cost=unaligned_load,
vectype=0x0000000115045a80, misalign=-1) at rs6000.cc:5069:4
    frame #3: 0x00000001019bb55c
cc1`builtin_vectorization_cost(type_of_cost=unaligned_load,
vectype=0x0000000115045a80, misalign=-1) at tree-vectorizer.h:1789:55
    frame #4: 0x0000000101903b4f
cc1`::record_stmt_cost(body_cost_vec=0x0000000308b11a00, count=1,
kind=unaligned_load, stmt_info=0x0000000111a0e210, node=0x0000000000000000,
vectype=0x0000000115045a80, misalign=-1, where=vect_body) at
tree-vect-stmts.cc:113:35
    frame #5: 0x0000000101903b9e
cc1`record_stmt_cost(body_cost_vec=0x0000000308b11a00, count=1,
kind=unaligned_load, stmt_info=0x0000000111a0e210, vectype=0x0000000115045a80,
misalign=-1, where=vect_body) at tree-vect-stmts.cc:122:27
    frame #6: 0x000000010197ea64
cc1`record_stmt_cost(body_cost_vec=0x0000000308b11a00, count=1,
kind=unaligned_load, stmt_info=0x0000000111a0e210, misalign=-1,
where=vect_body) at tree-vectorizer.h:2210:27
    frame #7: 0x00000001019073f6
cc1`vect_get_load_cost((null)=0x0000000111a0d110, stmt_info=0x0000000111a0e210,
ncopies=1, alignment_support_scheme=dr_unaligned_supported, misalignment=-1,
add_realign_cost=false, inside_cost=0x0000000308b10ac4,
prologue_cost=0x0000000000000000, prologue_cost_vec=0x0000000308b11a00,
body_cost_vec=0x0000000308b11a00, record_prologue_costs=true) at
tree-vect-stmts.cc:1307:35
    frame #8: 0x000000010192b199
cc1`::vectorizable_load(vinfo=0x0000000111a0d110, stmt_info=0x0000000111a0e210,
gsi=0x0000000000000000, vec_stmt=0x0000000000000000,
slp_node=0x0000000000000000, cost_vec=0x0000000308b11a00) at
tree-vect-stmts.cc:9989:26
    frame #9: 0x00000001019329be
cc1`vect_analyze_stmt(vinfo=0x0000000111a0d110, stmt_info=0x0000000111a0e210,
need_to_vectorize=0x0000000308b11a0f, node=0x0000000000000000,
node_instance=0x0000000000000000, cost_vec=0x0000000308b11a00) at
tree-vect-stmts.cc:12124:25
    frame #10: 0x000000010194622e
cc1`::vect_analyze_loop_operations(loop_vinfo=0x0000000111a0d110) at
tree-vect-loop.cc:2083:23
    frame #11: 0x0000000101948c6e
cc1`::vect_analyze_loop_2(loop_vinfo=0x0000000111a0d110,
fatal=0x0000000308b1292f, suggested_unroll_factor=0x0000000308b1276c,
slp_done_for_suggested_uf=0x0000000308b1276b) at tree-vect-loop.cc:2880:37
    frame #12: 0x000000010194a49b
cc1`::vect_analyze_loop_1(loop=0x0000000115007200, shared=0x0000000308b12ce0,
loop_form_info=0x0000000308b129f0, main_loop_vinfo=0x0000000000000000,
vector_modes=0x0000000308b129b0, mode_i=0x0000000308b1299c,
autodetected_vector_mode=0x0000000308b129ac, fatal=0x0000000308b1292f) at
tree-vect-loop.cc:3316:40
    frame #13: 0x000000010194b036
cc1`vect_analyze_loop(loop=0x0000000115007200, shared=0x0000000308b12ce0) at
tree-vect-loop.cc:3470:24
    frame #14: 0x00000001019be5c5
cc1`::try_vectorize_loop_1(simduid_to_vf_htab=0x0000000308b12f30,
num_vectorized_loops=0x0000000308b12f3c, loop=0x0000000115007200,
loop_vectorized_call=0x00000001150e61b0,
loop_dist_alias_call=0x0000000000000000, fun=0x000000011500d000) at
tree-vectorizer.cc:1064:52
    frame #15: 0x00000001019beb2c
cc1`::try_vectorize_loop(simduid_to_vf_htab=0x0000000308b12f30,
num_vectorized_loops=0x0000000308b12f3c, loop=0x0000000115007200,
fun=0x000000011500d000) at tree-vectorizer.cc:1180:31
    frame #16: 0x00000001019bedd0
cc1`pass_vectorize::execute(this=0x0000600002604300, fun=0x000000011500d000)
const at tree-vectorizer.cc:1296:33
    frame #17: 0x0000000101382584 cc1`execute_one_pass(pass=0x0000600002604300)
at passes.cc:2651:30
    frame #18: 0x00000001013829c3
cc1`::execute_pass_list_1(pass=0x0000600002604300) at passes.cc:2760:28
    frame #19: 0x00000001013829f4
cc1`::execute_pass_list_1(pass=0x000060000260f480) at passes.cc:2761:22
    frame #20: 0x00000001013829f4
cc1`::execute_pass_list_1(pass=0x000060000260e1c0) at passes.cc:2761:22
    frame #21: 0x0000000101382a5a cc1`execute_pass_list(fn=0x000000011500d000,
pass=0x000060000260dec0) at passes.cc:2771:23
    frame #22: 0x0000000100bb0866
cc1`cgraph_node::expand(this=0x0000000113d06220) at cgraphunit.cc:1841:21
    frame #23: 0x0000000100bb1107 cc1`::expand_all_functions() at
cgraphunit.cc:2024:21
    frame #24: 0x0000000100bb1fb2
cc1`symbol_table::compile(this=0x0000000113806000) at cgraphunit.cc:2398:24
    frame #25: 0x0000000100bb24b4
cc1`symbol_table::finalize_compilation_unit(this=0x0000000113806000) at
cgraphunit.cc:2583:11
    frame #26: 0x0000000101552e17 cc1`::compile_file() at toplev.cc:471:41
    frame #27: 0x0000000101556832 cc1`::do_compile(no_backend=false) at
toplev.cc:2126:24
    frame #28: 0x0000000101556d76 cc1`toplev::main(this=0x0000000308b1333a,
argc=34, argv=0x0000000308b13490) at toplev.cc:2282:18
    frame #29: 0x0000000101d53d18 cc1`main(argc=34, argv=0x0000000308b13490) at
main.cc:39:23

[Bug target/110776] [14 Regression] powerpc-darwin bootstrap broken after r14-2490 with ICE rs6000.cc:5069 building libgfortran

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110776

--- Comment #1 from Iain Sandoe <iains at gcc dot gnu.org> ---
Created attachment 55613
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55613&action=edit
preprocessed (not reduced, but the function is not large)

[Bug target/110776] [14 Regression] powerpc-darwin bootstrap broken after r14-2490 with ICE rs6000.cc:5069 building libgfortran

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110776

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |build
   Target Milestone|---                         |14.0

[Bug target/110776] [14 Regression] powerpc-darwin bootstrap broken after r14-2490 with ICE rs6000.cc:5069 building libgfortran

[linkw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110776

Kewen Lin <linkw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |linkw at gcc dot gnu.org
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2023-07-24

--- Comment #2 from Kewen Lin <linkw at gcc dot gnu.org> ---
Thanks for reporting and sorry for the breakage. I'll have a look first.

(In reply to Iain Sandoe from comment #0)
> The ICE seems to be because rs6000_builtin_vectorization_cost () is called
> with a request for a misaligned load (which we do not support), It
> reproduces on a cross from x86_64.
> 
> This is in compiling libgfortran generated code (so nothing Darwin-specific,
> other than being an Altivec platform).

Thanks for the information.

> 
> A philosophical question; if a request is made for the cost of doing
> something unsupported - should we not return "infinity" rather than ICEing?  
> 
> Presumably, the alternative is that the middle end needs to know that some
> kinds of operation are not supported and therefore not to try and cost them
> (speculation here; I have no knowledge of the relevant code).

I think that's what's being adopted now, if the target doesn't support
unaligned load, the middle-end should take it as dr_unaligned_unsupported
(dr_alignment_support) and use VECT_MAX_COST, it's expected that there is no
chance to query it with unaligned_load. Maybe some path was changed by the
culprit commit.

[Bug target/110776] [14 Regression] powerpc-darwin bootstrap broken after r14-2490 with ICE rs6000.cc:5069 building libgfortran

[linkw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110776

Kewen Lin <linkw at gcc dot gnu.org> changed:

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

--- Comment #3 from Kewen Lin <linkw at gcc dot gnu.org> ---
The failure exposed one special case: there is one stmt 

# VUSE <.MEM_404>
_15 = *_14;

its STMT_VINFO_STRIDED_P (stmt_info) is set, memory_access_type is
VMAT_ELEMENTWISE and alignment_support_scheme is dr_unaligned_supported, its
vector type is "vector(1) long int", so in the handling it's taken as:

      /* Load vector(1) scalar_type if it's 1 element-wise vectype.  */
      else if (nloads == 1)
        ltype = vectype;

as its ltype is vector type, we cost it with 

                  if (VECTOR_TYPE_P (ltype))
                    vect_get_load_cost (vinfo, stmt_info, 1,
                                        alignment_support_scheme, misalignment,
                                        false, &inside_cost, nullptr, cost_vec,
                                        cost_vec, true);

as it's dr_unaligned_supported, it's costed as unaligned_load then causes the
ICE. One idea is to teach rs6000_builtin_vectorization_cost about one single
lane vector unaligned load as scalar_load. But I think it's simple to treat
single lane vector load as scalar_load, as I expect veclower will lower it
later.

diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index 4622d6a04ef..bdf4c12cd03 100644
--- a/gcc/tree-vect-stmts.cc
+++ b/gcc/tree-vect-stmts.cc
@@ -9985,7 +9985,9 @@ vectorizable_load (vec_info *vinfo,
             {
               if (costing_p)
                 {
-                  if (VECTOR_TYPE_P (ltype))
+                  /* For a single lane vector type, we should cost it as
+                     scalar_load to avoid ICE, see PR110776.  */
+                  if (VECTOR_TYPE_P (ltype) && lnel > 1)
                     vect_get_load_cost (vinfo, stmt_info, 1,
                                         alignment_support_scheme,
misalignment,
                                         false, &inside_cost, nullptr,
cost_vec,

Hi Richi, what do you think of this?

[Bug target/110776] [14 Regression] powerpc-darwin bootstrap broken after r14-2490 with ICE rs6000.cc:5069 building libgfortran

[linkw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110776

Kewen Lin <linkw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|powerpc-darwin              |powerpc-darwin,
                   |                            |powerpc64-linux

--- Comment #4 from Kewen Lin <linkw at gcc dot gnu.org> ---
When cooking a patch, I reduced the preprocessed file into:

int a;
long *b;
int c() {
  long e;
  int d = 0;
  for (long f; f; f++) {
    e = b[f * a];
    if (e)
      d = 1;
  }
  if (d)
    for (;;)
      ;
}

and found the ICE can be reproduced on powerpc64 with -O2 -mcpu=power6
-maltivec.

[Bug target/110776] [14 Regression] powerpc-darwin bootstrap broken after r14-2490 with ICE rs6000.cc:5069 building libgfortran

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110776

--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 25 Jul 2023, linkw at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110776
> 
> Kewen Lin <linkw at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |rguenth at gcc dot gnu.org
> 
> --- Comment #3 from Kewen Lin <linkw at gcc dot gnu.org> ---
> The failure exposed one special case: there is one stmt 
> 
> # VUSE <.MEM_404>
> _15 = *_14;
> 
> its STMT_VINFO_STRIDED_P (stmt_info) is set, memory_access_type is
> VMAT_ELEMENTWISE and alignment_support_scheme is dr_unaligned_supported, its
> vector type is "vector(1) long int", so in the handling it's taken as:
> 
>       /* Load vector(1) scalar_type if it's 1 element-wise vectype.  */
>       else if (nloads == 1)
>         ltype = vectype;
> 
> as its ltype is vector type, we cost it with 
> 
>                   if (VECTOR_TYPE_P (ltype))
>                     vect_get_load_cost (vinfo, stmt_info, 1,
>                                         alignment_support_scheme, misalignment,
>                                         false, &inside_cost, nullptr, cost_vec,
>                                         cost_vec, true);
> 
> as it's dr_unaligned_supported, it's costed as unaligned_load then causes the
> ICE. One idea is to teach rs6000_builtin_vectorization_cost about one single
> lane vector unaligned load as scalar_load. But I think it's simple to treat
> single lane vector load as scalar_load, as I expect veclower will lower it
> later.
> 
> diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
> index 4622d6a04ef..bdf4c12cd03 100644
> --- a/gcc/tree-vect-stmts.cc
> +++ b/gcc/tree-vect-stmts.cc
> @@ -9985,7 +9985,9 @@ vectorizable_load (vec_info *vinfo,
>              {
>                if (costing_p)
>                  {
> -                  if (VECTOR_TYPE_P (ltype))
> +                  /* For a single lane vector type, we should cost it as
> +                     scalar_load to avoid ICE, see PR110776.  */
> +                  if (VECTOR_TYPE_P (ltype) && lnel > 1)
>                      vect_get_load_cost (vinfo, stmt_info, 1,
>                                          alignment_support_scheme,
> misalignment,
>                                          false, &inside_cost, nullptr,
> cost_vec,
> 
> Hi Richi, what do you think of this?

I think apart from the consideration what a single element vector
is compared to a scalar, a more to-the-point fix is

  if (VECTOR_TYPE_P (ltype)
      && memory_access_type != VMAT_ELEMENTWISE)

[Bug target/110776] [14 Regression] powerpc-darwin bootstrap broken after r14-2490 with ICE rs6000.cc:5069 building libgfortran

[linkw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110776

--- Comment #6 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #5)
> On Tue, 25 Jul 2023, linkw at gcc dot gnu.org wrote:
> 
> I think apart from the consideration what a single element vector
> is compared to a scalar, a more to-the-point fix is
> 
>   if (VECTOR_TYPE_P (ltype)
>       && memory_access_type != VMAT_ELEMENTWISE)

Thanks for the suggestion! I thought checking lnel can also cover
VMAT_STRIDED_SLP's special case having const_nunits 1, but it seems impossible
to have?  Then it's more clear with explicit VMAT_ELEMENTWISE checking.

[Bug target/110776] [14 Regression] powerpc-darwin bootstrap broken after r14-2490 with ICE rs6000.cc:5069 building libgfortran

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110776

--- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 25 Jul 2023, linkw at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110776
> 
> --- Comment #6 from Kewen Lin <linkw at gcc dot gnu.org> ---
> (In reply to rguenther@suse.de from comment #5)
> > On Tue, 25 Jul 2023, linkw at gcc dot gnu.org wrote:
> > 
> > I think apart from the consideration what a single element vector
> > is compared to a scalar, a more to-the-point fix is
> > 
> >   if (VECTOR_TYPE_P (ltype)
> >       && memory_access_type != VMAT_ELEMENTWISE)
> 
> Thanks for the suggestion! I thought checking lnel can also cover
> VMAT_STRIDED_SLP's special case having const_nunits 1, but it seems impossible
> to have?

I think so, unless I'm convinced with a testcase ;)

[Bug target/110776] [14 Regression] powerpc-darwin bootstrap broken after r14-2490 with ICE rs6000.cc:5069 building libgfortran

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110776

--- Comment #8 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #7)
> On Tue, 25 Jul 2023, linkw at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110776
> > 
> > --- Comment #6 from Kewen Lin <linkw at gcc dot gnu.org> ---
> > (In reply to rguenther@suse.de from comment #5)
> > > On Tue, 25 Jul 2023, linkw at gcc dot gnu.org wrote:
> > > 
> > > I think apart from the consideration what a single element vector
> > > is compared to a scalar, a more to-the-point fix is
> > > 
> > >   if (VECTOR_TYPE_P (ltype)
> > >       && memory_access_type != VMAT_ELEMENTWISE)
> > 
> > Thanks for the suggestion! I thought checking lnel can also cover
> > VMAT_STRIDED_SLP's special case having const_nunits 1, but it seems impossible
> > to have?
> 
> I think so, unless I'm convinced with a testcase ;)

(sorry for being a bit slow - we had a power outage that wasted most of the
day)

Richi's suggested patch fixes build of a cross-build for powerpc-darwin and the
test results look OK too.  A non-expert look at the code suggests that
VMAT_ELEMENTWISE is already accounted for on the write side, so that we should
not see a call to the costing code for the equivalent write-side.

[Bug target/110776] [14 Regression] powerpc-darwin bootstrap broken after r14-2490 with ICE rs6000.cc:5069 building libgfortran

[linkw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110776

--- Comment #9 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #8)
> (In reply to rguenther@suse.de from comment #7)
> > On Tue, 25 Jul 2023, linkw at gcc dot gnu.org wrote:
> > 
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110776
> > > 
> > > --- Comment #6 from Kewen Lin <linkw at gcc dot gnu.org> ---
> > > (In reply to rguenther@suse.de from comment #5)
> > > > On Tue, 25 Jul 2023, linkw at gcc dot gnu.org wrote:
> > > > 
> > > > I think apart from the consideration what a single element vector
> > > > is compared to a scalar, a more to-the-point fix is
> > > > 
> > > >   if (VECTOR_TYPE_P (ltype)
> > > >       && memory_access_type != VMAT_ELEMENTWISE)
> > > 
> > > Thanks for the suggestion! I thought checking lnel can also cover
> > > VMAT_STRIDED_SLP's special case having const_nunits 1, but it seems impossible
> > > to have?
> > 
> > I think so, unless I'm convinced with a testcase ;)

I guess there is no such test case. ;)

> 
> (sorry for being a bit slow - we had a power outage that wasted most of the
> day)
> 
> Richi's suggested patch fixes build of a cross-build for powerpc-darwin and
> the test results look OK too.  A non-expert look at the code suggests that
> VMAT_ELEMENTWISE is already accounted for on the write side, so that we
> should not see a call to the costing code for the equivalent write-side.

Thanks Iain, I also bootstrapped and regtested the suggested fix on x86 and
powerpc64{,le}, just posted it for review at
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625484.html.

[Bug target/110776] [14 Regression] powerpc-darwin bootstrap broken after r14-2490 with ICE rs6000.cc:5069 building libgfortran

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110776

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Kewen Lin <linkw@gcc.gnu.org>:

https://gcc.gnu.org/g:9890d4e8bcda1f34b8eefb481935ef0e4cd8069e

commit r14-2813-g9890d4e8bcda1f34b8eefb481935ef0e4cd8069e
Author: Kewen Lin <linkw@linux.ibm.com>
Date:   Wed Jul 26 21:43:09 2023 -0500

    vect: Treat VMAT_ELEMENTWISE as scalar load in costing [PR110776]

    PR110776 exposes one issue that we could query unaligned
    load for vector type but actually no unaligned vector load
    is supported there.  The reason is that the costed load is
    with single-lane vector type and its memory access type is
    VMAT_ELEMENTWISE, we actually take it as scalar load and
    set its alignment_support_scheme as dr_unaligned_supported.

    To avoid the ICE as exposed, following Rich's suggestion,
    this patch is to make VMAT_ELEMENTWISE be costed as scalar
    load.

    Co-authored-by: Richard Biener <rguenther@suse.de>

            PR tree-optimization/110776

    gcc/ChangeLog:

            * tree-vect-stmts.cc (vectorizable_load): Always cost
VMAT_ELEMENTWISE
            as scalar load.

    gcc/testsuite/ChangeLog:

            * gcc.target/powerpc/pr110776.c: New test.

[Bug target/110776] [14 Regression] powerpc-darwin bootstrap broken after r14-2490 with ICE rs6000.cc:5069 building libgfortran

[linkw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110776

Kewen Lin <linkw at gcc dot gnu.org> changed:

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

--- Comment #11 from Kewen Lin <linkw at gcc dot gnu.org> ---
Should be fixed on trunk.