system.h: rename vec_step to workaround powerpc/clang bug [PR114369]
Checks
Context |
Check |
Description |
linaro-tcwg-bot/tcwg_gcc_build--master-arm |
success
|
Testing passed
|
linaro-tcwg-bot/tcwg_gcc_build--master-aarch64 |
success
|
Testing passed
|
linaro-tcwg-bot/tcwg_gcc_check--master-aarch64 |
success
|
Testing passed
|
linaro-tcwg-bot/tcwg_gcc_check--master-arm |
success
|
Testing passed
|
Commit Message
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-19 Jakub Jelinek <jakub@redhat.com>
PR bootstrap/114369
* system.h (vec_step): Define to vec_step_ when compiling
with clang on PowerPC.
Jakub
Comments
On Tue, 19 Mar 2024, Jakub Jelinek wrote:
> 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?
Works for me, but would
#undef vec_step
work or is it really a keyword in the clang side?
Thanks,
Richard.
> 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-19 Jakub Jelinek <jakub@redhat.com>
>
> PR bootstrap/114369
> * system.h (vec_step): Define to vec_step_ when compiling
> with clang on PowerPC.
>
> --- gcc/system.h.jj 2024-03-08 09:07:29.484624793 +0100
> +++ gcc/system.h 2024-03-19 11:39:18.122700551 +0100
> @@ -1302,6 +1302,12 @@ void gcc_stablesort_r (void *, size_t, s
> #define NULL nullptr
> #endif
>
> +/* Workaround clang on PowerPC which has vec_step as reserved keyword
> + rather than function-like macro defined in <altivec.h>. See PR114369. */
> +#if defined(__clang__) && defined(__powerpc__)
> +#define vec_step vec_step_
> +#endif
> +
> /* Return true if STR string starts with PREFIX. */
>
> inline bool
>
>
> Jakub
>
>
On Tue, Mar 19, 2024 at 12:54:47PM +0100, Richard Biener wrote:
> Works for me, but would
>
> #undef vec_step
>
> work or is it really a keyword in the clang side?
No, it is really keyword.
#undef vec_step
int
main ()
{
int vec_step = 0;
return vec_step;
}
clang --target=powerpc64le-linux -o /tmp/vecstep{,.c}
/tmp/vecstep.c:5:7: error: expected identifier or '('
int vec_step = 0;
^
/tmp/vecstep.c:6:18: error: expected expression
return vec_step;
^
2 errors generated.
Jakub
On Tue, 19 Mar 2024, Jakub Jelinek wrote:
> On Tue, Mar 19, 2024 at 12:54:47PM +0100, Richard Biener wrote:
> > Works for me, but would
> >
> > #undef vec_step
> >
> > work or is it really a keyword in the clang side?
>
> No, it is really keyword.
> #undef vec_step
> int
> main ()
> {
> int vec_step = 0;
> return vec_step;
> }
> clang --target=powerpc64le-linux -o /tmp/vecstep{,.c}
> /tmp/vecstep.c:5:7: error: expected identifier or '('
> int vec_step = 0;
> ^
> /tmp/vecstep.c:6:18: error: expected expression
> return vec_step;
> ^
> 2 errors generated.
Ah, OK - thanks for clarifying.
Richard.
@@ -1302,6 +1302,12 @@ void gcc_stablesort_r (void *, size_t, s
#define NULL nullptr
#endif
+/* Workaround clang on PowerPC which has vec_step as reserved keyword
+ rather than function-like macro defined in <altivec.h>. See PR114369. */
+#if defined(__clang__) && defined(__powerpc__)
+#define vec_step vec_step_
+#endif
+
/* Return true if STR string starts with PREFIX. */
inline bool