[Bug 561] asm.h/preprocessor macros vs. ANSI

rtems-bugs at rtems.org rtems-bugs at rtems.org
Mon Jan 15 09:18:42 UTC 2007


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)



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 -------
Digging the gcc.gnu.org archives seems to indicate that the REG and SYM #defines in RTEMS asm.h violate the ANSI-standards.

#define EXPAND(x) x

and redefining REG and SYM to
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.
You reported the bug, or are watching the reporter.

More information about the bugs mailing list