[Bug target/39558] Bad interaction of decls named 'vector' and -maltivec vector support
--- Comment #11 from jakub at gcc dot gnu dot org 2009-03-30 15:01 --- Subject: Bug 39558 Author: jakub Date: Mon Mar 30 15:00:52 2009 New Revision: 145297 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145297 Log: PR target/39558 * macro.c (cpp_get_token): If macro_to_expand returns NULL and used some tokens, add CPP_PADDING before next token. * gcc.target/powerpc/altivec-29.c: New test. Added: trunk/gcc/testsuite/gcc.target/powerpc/altivec-29.c Modified: trunk/gcc/testsuite/ChangeLog trunk/libcpp/ChangeLog trunk/libcpp/macro.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39558
[Bug target/39558] Bad interaction of decls named 'vector' and -maltivec vector support
--- Comment #12 from jakub at gcc dot gnu dot org 2009-03-30 15:06 --- Subject: Bug 39558 Author: jakub Date: Mon Mar 30 15:06:14 2009 New Revision: 145298 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145298 Log: PR target/39558 * macro.c (cpp_get_token): If macro_to_expand returns NULL and used some tokens, add CPP_PADDING before next token. * gcc.target/powerpc/altivec-29.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.target/powerpc/altivec-29.c - copied unchanged from r145297, trunk/gcc/testsuite/gcc.target/powerpc/altivec-29.c Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/libcpp/ChangeLog branches/gcc-4_4-branch/libcpp/macro.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39558
[Bug target/39558] Bad interaction of decls named 'vector' and -maltivec vector support
--- Comment #13 from jakub at gcc dot gnu dot org 2009-03-30 15:24 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39558
[Bug target/39558] Bad interaction of decls named 'vector' and -maltivec vector support
--- 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
[Bug target/39558] Bad interaction of decls named 'vector' and -maltivec vector support
--- 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 -, 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
[Bug target/39558] Bad interaction of decls named 'vector' and -maltivec vector support
--- Comment #7 from meissner at linux dot vnet dot ibm dot com 2009-03-27 15:59 --- Subject: Re: Bad interaction of decls named 'vector' and -maltivec vector support On Fri, Mar 27, 2009 at 11:18:52AM -0400, Michael Meissner wrote: 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: Just to be clear, I meant to say there is no problem with infinite recursion. Whoops. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39558
[Bug target/39558] Bad interaction of decls named 'vector' and -maltivec vector support
--- Comment #8 from jakub at gcc dot gnu dot org 2009-03-27 17:55 --- Created an attachment (id=17546) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17546action=view) gcc44-pr39558.patch Untested patch to fix this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39558
[Bug target/39558] Bad interaction of decls named 'vector' and -maltivec vector support
--- Comment #9 from meissner at linux dot vnet dot ibm dot com 2009-03-27 21:20 --- Subject: Re: Bad interaction of decls named 'vector' and -maltivec vector support On Fri, Mar 27, 2009 at 05:55:05PM -, jakub at gcc dot gnu dot org wrote: --- Comment #8 from jakub at gcc dot gnu dot org 2009-03-27 17:55 --- Created an attachment (id=17546) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17546action=view) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17546action=view) gcc44-pr39558.patch Untested patch to fix this. -- 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. This does fix the problem and has no extra testsuite failures. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39558
[Bug target/39558] Bad interaction of decls named 'vector' and -maltivec vector support
--- Comment #10 from tromey at gcc dot gnu dot org 2009-03-28 01:15 --- I think this patch looks ok, assuming it works. I'd like to reiterate that all this vector stuff would probably be much cleaner if it were implemented as context-sensitive keywords in the parser. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39558
[Bug target/39558] Bad interaction of decls named 'vector' and -maltivec vector support
--- Comment #2 from jakub at gcc dot gnu dot org 2009-03-26 14:00 ---
What exact problem do you see?
#define ATTRIBUTE_UNUSED __attribute__((unused))
vector int i;
int *foo (int *vector)
{
return vector;
}
int *bar (int *vector ATTRIBUTE_UNUSED)
{
return vector;
}
int *baz (int *vector __attribute__((unused)))
{
return vector;
}
compiles just fine for me with -maltivec -Wall (and correctly complains only in
foo about the unused argument).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39558
[Bug target/39558] Bad interaction of decls named 'vector' and -maltivec vector support
--- Comment #3 from meissner at linux dot vnet dot ibm dot com 2009-03-26
15:24 ---
Subject: Re: Bad interaction of decls named 'vector' and -maltivec vector
support
On Thu, Mar 26, 2009 at 02:00:49PM -, jakub at gcc dot gnu dot org wrote:
--- Comment #2 from jakub at gcc dot gnu dot org 2009-03-26 14:00 ---
What exact problem do you see?
#define ATTRIBUTE_UNUSED __attribute__((unused))
vector int i;
int *foo (int *vector)
{
return vector;
}
int *bar (int *vector ATTRIBUTE_UNUSED)
{
return vector;
}
int *baz (int *vector __attribute__((unused)))
{
return vector;
}
compiles just fine for me with -maltivec -Wall (and correctly complains only
in
foo about the unused argument).
I just looked at it, and the problem is if you use the -save-temps options
along with -maltivec. Because -save-temps invokes the preprocessor as a
separate stage, when it expands vector (to be vector) and ATTRIBUTE_UNUSED (to
be __attribute__((unused))), it glues the two tokens together. Since I'm
looking at power7 code generation right now, I was doing a full bootstrap with
-save-temps to see where the power7 instructions were being generated.
I suspect if we change the default definition of 'vector' to vector instead
of vector if vector isn't follwed by a type keyword, it will fix the problem
(ditto for bool, etc.).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39558
[Bug target/39558] Bad interaction of decls named 'vector' and -maltivec vector support
--- Comment #4 from meissner at linux dot vnet dot ibm dot com 2009-03-26 15:43 --- Further testing shows that this only happens if you use the -save-temps option. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39558
[Bug target/39558] Bad interaction of decls named 'vector' and -maltivec vector support
-- bje at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bje at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-03-25 23:51:35 |2009-03-26 05:06:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39558
