[Bug tree-optimization/114369] New: tree-vect-loop.cc uses vec_step which is also an altivec intrinsics

[Bug tree-optimization/114369] New: tree-vect-loop.cc uses vec_step which is also an altivec intrinsics

[pinskia at gcc dot gnu.org]

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

            Bug ID: 114369
           Summary: tree-vect-loop.cc uses vec_step which is also an
                    altivec intrinsics
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Keywords: build
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Forwarded from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494 and
https://lists.tetaneutral.net/pipermail/cfarm-users/2024-March/001074.html
vec_step  is used as a variable name in tree-vect-loop.cc a few times though it
is an altivec intrinsics which causes building GCC with clang (libc++).
We should work around this in the GCC sources.

[Bug tree-optimization/114369] tree-vect-loop.cc uses vec_step which is also an altivec intrinsics breaks build when building with clang

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The gcc altivec.h defines it as a function-like macro, so not a problem.
So perhaps a clang bug for not defining it as a function-like macro only?

[Bug tree-optimization/114369] tree-vect-loop.cc uses vec_step which is also an altivec intrinsics breaks build when building with clang

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://github.com/llvm/llv
                   |                            |m-project/issues/85579

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #1)
> The gcc altivec.h defines it as a function-like macro, so not a problem.
> So perhaps a clang bug for not defining it as a function-like macro only?

I filed it as https://github.com/llvm/llvm-project/issues/85579 also . Let's
see what is mentioned htere.

[Bug tree-optimization/114369] tree-vect-loop.cc uses vec_step which is also an altivec intrinsics breaks build when building with clang

[gerald at pfeifer dot com]

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

Gerald Pfeifer <gerald at pfeifer dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
                 CC|                            |gerald at pfeifer dot com
   Last reconfirmed|                            |2024-03-17

--- Comment #3 from Gerald Pfeifer <gerald at pfeifer dot com> ---
I first reported this in July 2019; see

  https://gcc.gnu.org/pipermail/gcc/2019-July/229869.html

and in particular the three responses

  https://gcc.gnu.org/pipermail/gcc/2019-July/229870.html
  https://gcc.gnu.org/pipermail/gcc/2019-July/229871.html
  https://gcc.gnu.org/pipermail/gcc/2019-July/229872.html

for some more context.

[Bug tree-optimization/114369] tree-vect-loop.cc uses vec_step which is also an altivec intrinsics breaks build when building with clang

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
I'm inclined to close this as INVALID, but I'd accept working around the
clang bug by, in system.h, guarded on __clang and powerpc, doing an #undef
vec_step.

[Bug tree-optimization/114369] tree-vect-loop.cc uses vec_step which is also an altivec intrinsics breaks build when building with clang

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #4)
> I'm inclined to close this as INVALID, but I'd accept working around the
> clang bug by, in system.h, guarded on __clang and powerpc, doing an #undef
> vec_step.

From what I can see on godbolt, that doesn't help, vec_step is likely a keyword
or something like that, at least #undef vec_step doesn't do anything with it:
https://godbolt.org/z/4cc9q65r6
That is why the workarounds use
#define vec_step vec_step_
so that tree-vect-loop.cc then actually doesn't use the keyword or whatever it
is, but some other name.

[Bug bootstrap/114369] tree-vect-loop.cc uses vec_step which is also an altivec intrinsics breaks build when building with clang

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:5e64228fe1f7ec536da314246eec968aea0d704d

commit r14-9567-g5e64228fe1f7ec536da314246eec968aea0d704d
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Mar 20 10:34:51 2024 +0100

    system.h: rename vec_step to workaround powerpc/clang bug [PR114369]

    On Sat, Jul 20, 2019 at 05:26:57PM +0100, Richard Sandiford wrote:
    > Gerald Pfeifer <gerald@pfeifer.com> writes:
    > > I have seen an increasing number of reports of GCC failing to
    > > build with clang on powerpc (on FreeBSD, though that's probably
    > > immaterial).
    > >
    > > Turns out that clang has vec_step as a reserved word on powerpc
    > > with AltiVec.
    > >
    > > We OTOH use vec_step s as a variable name in gcc/tree-vect-loop.c.
    > >
    > >
    > > The best approach I can see is to rename vec_step.  Before I prepare
    > > a patch: what alternate name/spelling would you prefer?
    >
    > Would it work to #define vec_step to vec_step_ or something on affected
    > hosts, say in system.h?
    >
    > I'd prefer that to renmaing since "vec_step" does seem the most natural
    > name for the variable.  The equivalent scalar variable is "step" and
    > other vector values in the surrounding code also use the "vec_" prefix.

    So like this?

    If/when clang finally fixes
https://github.com/llvm/llvm-project/issues/85579
    on their side, we can then limit it to clang versions which still have the
    bug.

    I've git grepped for vec_set and appart from altivec.h it is just used in
    tree-vect-loop.cc, some Ada files which aren't preprocessed, ChangeLogs,
    rs6000-vecdefines.h (but that header is only included from altivec.h and
    vec_step is then redefined to the function-like macro) and in
rs6000-overload.def
    but that file is processed with a generator, not included in C/C++ sources.

    2024-03-20  Jakub Jelinek  <jakub@redhat.com>

            PR bootstrap/114369
            * system.h (vec_step): Define to vec_step_ when compiling
            with clang on PowerPC.

[Bug bootstrap/114369] tree-vect-loop.cc uses vec_step which is also an altivec intrinsics breaks build when building with clang

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:8046a7e2aeeae80c15d99d55ae04755aedf46a2f

commit r13-8512-g8046a7e2aeeae80c15d99d55ae04755aedf46a2f
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Mar 20 10:34:51 2024 +0100

    system.h: rename vec_step to workaround powerpc/clang bug [PR114369]

    On Sat, Jul 20, 2019 at 05:26:57PM +0100, Richard Sandiford wrote:
    > Gerald Pfeifer <gerald@pfeifer.com> writes:
    > > I have seen an increasing number of reports of GCC failing to
    > > build with clang on powerpc (on FreeBSD, though that's probably
    > > immaterial).
    > >
    > > Turns out that clang has vec_step as a reserved word on powerpc
    > > with AltiVec.
    > >
    > > We OTOH use vec_step s as a variable name in gcc/tree-vect-loop.c.
    > >
    > >
    > > The best approach I can see is to rename vec_step.  Before I prepare
    > > a patch: what alternate name/spelling would you prefer?
    >
    > Would it work to #define vec_step to vec_step_ or something on affected
    > hosts, say in system.h?
    >
    > I'd prefer that to renmaing since "vec_step" does seem the most natural
    > name for the variable.  The equivalent scalar variable is "step" and
    > other vector values in the surrounding code also use the "vec_" prefix.

    So like this?

    If/when clang finally fixes
https://github.com/llvm/llvm-project/issues/85579
    on their side, we can then limit it to clang versions which still have the
    bug.

    I've git grepped for vec_set and appart from altivec.h it is just used in
    tree-vect-loop.cc, some Ada files which aren't preprocessed, ChangeLogs,
    rs6000-vecdefines.h (but that header is only included from altivec.h and
    vec_step is then redefined to the function-like macro) and in
rs6000-overload.def
    but that file is processed with a generator, not included in C/C++ sources.

    2024-03-20  Jakub Jelinek  <jakub@redhat.com>

            PR bootstrap/114369
            * system.h (vec_step): Define to vec_step_ when compiling
            with clang on PowerPC.

    (cherry picked from commit 5e64228fe1f7ec536da314246eec968aea0d704d)