------- 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 <meiss...@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
