diff mbox series

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

Message ID ZflwFeCqirt/0xbV@tucnak
State New
Headers show
Series system.h: rename vec_step to workaround powerpc/clang bug [PR114369] | expand

Commit Message

Jakub Jelinek March 19, 2024, 10:59 a.m. UTC
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

Richard Biener March 19, 2024, 11:54 a.m. UTC | #1
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
> 
>
Jakub Jelinek March 19, 2024, 11:58 a.m. UTC | #2
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
Richard Biener March 19, 2024, 12:05 p.m. UTC | #3
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.
diff mbox series

Patch

--- 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