Altivec - declaring variables named vec_madd and vec_vmaddfp

[Zack Weinberg]

I've got a test case here that expects

#include <altivec.h>

/* variables with external-linkage */
extern int vec_madd;
extern short vec_vmaddfp;

to be rejected.  It is, but for the wrong reasons.  In C, the only
visible definitions of these symbols are

#define vec_vmaddfp vec_madd
#define vec_madd(...) /* very complicated expression */

vec_madd is a function-like macro, so it's not expanded on line four.
vec_vmaddfp is an object-like macro, so it is expanded, producing

extern int vec_madd;
extern short vec_madd;

as seen by the compiler - this gets us a conflicting-types error.  If
line five weren't there, the compiler wouldn't even blink at this --
nor the linker, since vec_madd is not a symbol in the standard library.

In C++, there's an inline function definition for vec_madd in scope
instead of a hairy macro, which means we get a more sensible sort of
error:

`int vec_madd' redeclared as different kind of symbol

My questions for you:

1) Do we care?  This test suite is pretty old, dating from the time
   when vec_madd and vec_vmaddfp were built in functions by those
   names, and you didn't even have to include altivec.h.

2) If we do care, what do we do about it?

zw