[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


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.

More information about the bugs mailing list