public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug tree-optimization/114369] New: tree-vect-loop.cc uses vec_step which is also an altivec intrinsics
@ 2024-03-17 18:59 pinskia at gcc dot gnu.org
2024-03-17 19:12 ` [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
` (6 more replies)
0 siblings, 7 replies; 8+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-03-17 18:59 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug tree-optimization/114369] tree-vect-loop.cc uses vec_step which is also an altivec intrinsics breaks build when building with clang
2024-03-17 18:59 [Bug tree-optimization/114369] New: tree-vect-loop.cc uses vec_step which is also an altivec intrinsics pinskia at gcc dot gnu.org
@ 2024-03-17 19:12 ` jakub at gcc dot gnu.org
2024-03-17 19:16 ` pinskia at gcc dot gnu.org
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-03-17 19:12 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug tree-optimization/114369] tree-vect-loop.cc uses vec_step which is also an altivec intrinsics breaks build when building with clang
2024-03-17 18:59 [Bug tree-optimization/114369] New: tree-vect-loop.cc uses vec_step which is also an altivec intrinsics pinskia at gcc dot gnu.org
2024-03-17 19:12 ` [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
@ 2024-03-17 19:16 ` pinskia at gcc dot gnu.org
2024-03-17 19:53 ` gerald at pfeifer dot com
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-03-17 19:16 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug tree-optimization/114369] tree-vect-loop.cc uses vec_step which is also an altivec intrinsics breaks build when building with clang
2024-03-17 18:59 [Bug tree-optimization/114369] New: tree-vect-loop.cc uses vec_step which is also an altivec intrinsics pinskia at gcc dot gnu.org
2024-03-17 19:12 ` [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
2024-03-17 19:16 ` pinskia at gcc dot gnu.org
@ 2024-03-17 19:53 ` gerald at pfeifer dot com
2024-03-18 8:47 ` rguenth at gcc dot gnu.org
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: gerald at pfeifer dot com @ 2024-03-17 19:53 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug tree-optimization/114369] tree-vect-loop.cc uses vec_step which is also an altivec intrinsics breaks build when building with clang
2024-03-17 18:59 [Bug tree-optimization/114369] New: tree-vect-loop.cc uses vec_step which is also an altivec intrinsics pinskia at gcc dot gnu.org
` (2 preceding siblings ...)
2024-03-17 19:53 ` gerald at pfeifer dot com
@ 2024-03-18 8:47 ` rguenth at gcc dot gnu.org
2024-03-19 9:24 ` jakub at gcc dot gnu.org
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-03-18 8:47 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug tree-optimization/114369] tree-vect-loop.cc uses vec_step which is also an altivec intrinsics breaks build when building with clang
2024-03-17 18:59 [Bug tree-optimization/114369] New: tree-vect-loop.cc uses vec_step which is also an altivec intrinsics pinskia at gcc dot gnu.org
` (3 preceding siblings ...)
2024-03-18 8:47 ` rguenth at gcc dot gnu.org
@ 2024-03-19 9:24 ` jakub at gcc dot gnu.org
2024-03-20 9:37 ` [Bug bootstrap/114369] " cvs-commit at gcc dot gnu.org
2024-03-30 3:54 ` cvs-commit at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-03-19 9:24 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug bootstrap/114369] tree-vect-loop.cc uses vec_step which is also an altivec intrinsics breaks build when building with clang
2024-03-17 18:59 [Bug tree-optimization/114369] New: tree-vect-loop.cc uses vec_step which is also an altivec intrinsics pinskia at gcc dot gnu.org
` (4 preceding siblings ...)
2024-03-19 9:24 ` jakub at gcc dot gnu.org
@ 2024-03-20 9:37 ` cvs-commit at gcc dot gnu.org
2024-03-30 3:54 ` cvs-commit at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-03-20 9:37 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug bootstrap/114369] tree-vect-loop.cc uses vec_step which is also an altivec intrinsics breaks build when building with clang
2024-03-17 18:59 [Bug tree-optimization/114369] New: tree-vect-loop.cc uses vec_step which is also an altivec intrinsics pinskia at gcc dot gnu.org
` (5 preceding siblings ...)
2024-03-20 9:37 ` [Bug bootstrap/114369] " cvs-commit at gcc dot gnu.org
@ 2024-03-30 3:54 ` cvs-commit at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-03-30 3:54 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2024-03-30 3:54 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-03-17 18:59 [Bug tree-optimization/114369] New: tree-vect-loop.cc uses vec_step which is also an altivec intrinsics pinskia at gcc dot gnu.org
2024-03-17 19:12 ` [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
2024-03-17 19:16 ` pinskia at gcc dot gnu.org
2024-03-17 19:53 ` gerald at pfeifer dot com
2024-03-18 8:47 ` rguenth at gcc dot gnu.org
2024-03-19 9:24 ` jakub at gcc dot gnu.org
2024-03-20 9:37 ` [Bug bootstrap/114369] " cvs-commit at gcc dot gnu.org
2024-03-30 3:54 ` cvs-commit at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).