[Bug 561] asm.h/preprocessor macros vs. ANSI
rtems-bugs at rtems.org
rtems-bugs at rtems.org
Mon Jan 15 09:18:43 UTC 2007
http://www.rtems.org/bugzilla/show_bug.cgi?id=561
joel.sherrill at oarcorp.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |WAITING
ralf.corsepius at rtems.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |SUSPENDED
Status|SUSPENDED |ASSIGNED
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Platform| |All
Target Milestone|--- |4.8
It seems to me that most (all?) standard RTEMS ASM macros in
cpukit/score/<cpu>/asm.h are not ANSI compliant:
For example cpukit/score/m68k/asm.h contains this:
..
/* ANSI concatenation macros. */
#define CONCAT1(a, b) CONCAT2(a, b)
#define CONCAT2(a, b) a ## b
/* Use the right prefix for global labels. */
#define SYM(x) CONCAT1 (__USER_LABEL_PREFIX__, x)
/* Use the right prefix for registers. */
#define REG(x) CONCAT1 (__REGISTER_PREFIX__, x)
..
Release:
RTEMS-4.7
Environment:
gcc-3.3.x
How-To-Repeat:
D/L the file from the attachment and try to compile it for the m68k.
# m68k-rtems4.7-gcc -o gaga.i -P gaga.c
gaga.c:22:8: pasting "%" and "foo" does not give a valid preprocessing token
gaga.c:22: error: parse error before '%' token
This kind of errors occur when compiling *.S files from BSPs that have been
converted to using automake compilation rules. "non-automade" BSPs use custom
compliation rules/flags and get away without this problem showing up.
------- Comment #1 from ralf.corsepius at rtems.org 2004-01-27 07:02 -------
Fix:
Digging the gcc.gnu.org archives seems to indicate that the REG and SYM #defines in RTEMS asm.h violate the ANSI-standards.
Adding
#define EXPAND(x) x
and redefining REG and SYM to
#define REG(x) EXPAND(__REGISTER_PREFIX__)x
seems to help.
Furthermore, the "ansi concatenation macros" are reimplemented in all cpukit/score/<cpu>/asm.h files. Therefore, I'd propose to put them into a single header file and to let the asm.h headers include this to-be-implemented file.
------- Comment #2 from joel.sherrill at oarcorp.com 2004-01-27 12:48 -------
State-Changed-From-To: open->feedback
State-Changed-Why: I am ok with your proposal to put a macro in a common include file, use that and fix the uses.
------- Comment #3 from ralf.corsepius at rtems.org 2004-01-28 08:02 -------
State-Changed-From-To: feedback->suspended
State-Changed-Why: I suspend this proposal. Fixing this issue for the m68k breaks all other CPUs, using what works for _all_ other CPUs, doesn't work for the m68k.
I think, I've tripped a severe bug in m68k-gcc.
------- Comment #4 from ralf.corsepius at rtems.org 2004-01-29 09:39 -------
State-Changed-From-To: suspended->working
State-Changed-Why: I am trying a solution based on Michael's reply to my query to gcc at gcc.gnu.org
cf. http://gcc.gnu.org/ml/gcc/2004-01/msg02184.html
--
Configure bugmail: http://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
More information about the bugs
mailing list