[Bug target/39558] Bad interaction of decls named 'vector' and -maltivec vector support

[meissner at linux dot vnet dot ibm dot com]

------- Comment #6 from meissner at linux dot vnet dot ibm dot com  2009-03-27 15:19 -------
Subject: Re:  Bad interaction of decls named 'vector' and -maltivec vector
support

On Fri, Mar 27, 2009 at 11:09:57AM -0000, jakub at gcc dot gnu dot org wrote:
> 
> 
> ------- Comment #5 from jakub at gcc dot gnu dot org  2009-03-27 11:09 -------
> Ah, I see.  The problem is that rs6000_macro_to_expand sometimes calls
> cpp_get_token (when seeing a macro after vector token), and removes optionally
> some CPP_PADDING tokens and a NT_MACRO token (with PREV_WHITE set on it).
> This only affects vector, not pixel nor bool.  Unfortunately, we can't
> expand vector to a macro defined as 'vector ' (without quotes), because that
> would mean infinite recursion.  We could perhaps if macro_to_expand hook
> returns NULL set PREV_WHITE on the next token (on the libcpp side, as
> rs6000_macro_to_expand sees tokens as const cpp_token), or insert a CPP_PADDING
> token.
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39558
> 
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.

Note, there is problem with infinite recursion, since a macro is temporarily
undefined when it is being expanded, as per the ISO C rules.  I tried the
following patch:

2009-03-26  Michael Meissner  <meissner@linux.vnet.ibm.com>

        PR target/39558
        * rs6000-c.c (rs6000_macro_to_expand): If the conditional macro is
        not to be expanded, return the default definition which is the
        macro defined as itself.  This insures that the proper spacing is
        put out if -save-temps or -E is used and the next token is an
        identifier or macro.

Index: gcc/config/rs6000/rs6000-c.c
===================================================================
--- gcc/config/rs6000/rs6000-c.c        (revision 145074)
+++ gcc/config/rs6000/rs6000-c.c        (working copy)
@@ -155,9 +155,6 @@ rs6000_macro_to_expand (cpp_reader *pfil

   ident = altivec_categorize_keyword (tok);

-  if (ident != expand_this)
-    expand_this = NULL;
-
   if (ident == C_CPP_HASHNODE (__vector_keyword))
     {
       int idx = 0;


And it works for the compiler, but then gcc.target/powerpc/altivec-27.c fails,
which is crafted to test various cpp pasting, etc.  I like your idea about
inserting a CPP_PADDING token.

The other way to do it is to add support for conditional keywords, like I did
for the named address space stuff for the cell, and not abuse the preprocessor.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39558