This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: specs: *predefine oddity


 > Actually, I was wondering about issues related to RTEMS's CPP_PREDEFINES:
 > 
 > 1. The correct and minimal way to identify an OS by CPP_PREDEFINES.
 > 
 > RTEMS uses this throughout its gcc/config/rtems*.h's:
 > #define CPP_PREDEFINES  "-Drtems -D__rtems__  -Asystem(rtems)"
 > 
 > Based on your comments I tend to think that this might be redundant and "-Drtems
 > -Asystem(rtems)" should be equivalent, but would reduce the amount of -D...s this
 > would get expanded to.

Yes.

Further I would encourage maintainers not to define "rtems" (or any
other non-reserved name) unless its actually needed, either because
there are known libraries out there that depend on it being defined,
or because removing it might break alot of code.  I suspect "rtems"
is actually needed, I'm just saying that we shouldn't create
non-reserved names just because CPP_PREDEFINES makes it easy to do 
so.  If a non-reserved name (like "rtems") isn't needed, you don't need
to use CPP_PREDEFINES; just put the reserved names in CPP_SPECS.



 > 2. Some  -D.. in CPP_PREDEFINES seem to get expanded and others not
 > 
 > Example: mips64orion-rtems cross compiler on a linux host:
 > 
 > # mips64orion-rtems-gcc -ansi -mips3 -v -o hello hello.c
 > Reading specs from /opt/rtems/lib/gcc-lib/mips64orion-rtems/2.95.2/specs
 > gcc version 2.95.2 19991019 (prerelease)
 >  /opt/rtems/lib/gcc-lib/mips64orion-rtems/2.95.2/cpp \
 > -lang-c -std=c89 -v -D__GNUC__=2 -D__GNUC_MINOR__=95 \
 > -trigraphs -D__STRICT_ANSI__ \
 > -D__mips__ -D__MIPSEB__ -D__R4000__ \
 > -D___mips__ -D_MIPSEB -D_R4000 -D__rtems__ -D__rtems__ \
 > -D__mips -D__MIPSEB -D__R4000 -D___mips\
 > -D__rtems -Asystem(rtems) \
 > -D__LANGUAGE_C -D_LANGUAGE_C \
 > -D__SIZE_TYPE__=unsigned int -D__PTRDIFF_TYPE__=int \
 > -U__mips -D__mips=3 -D__mips64 -U__mips -D__mips=3 \
 > -D__mips64 hello.c /tmp/cclNwq0b.i
 > 
 > The related config/rtems64.h contains this:
 > #define CPP_PREDEFINES "-Dmips -DMIPSEB -DR4000 \
 >   -D_mips -D_MIPSEB -D_R4000 \
 >    -Drtems -D__rtems__ -Asystem(rtems)"
 > 
 > I see -D_mips being expanded into -D___mips__ and -D___mips (tripple underscore
 > prefix), but I don't see an analogous expansion for -D_MIPSEB and -D_R4000.

Don't know for sure (this is part of what I think needs more documenting),
but I suspect it has to do with the ANSI/ISO C89 rules about reserved names.
C89's reserved name rules define a set of names that an implementation is
allowed to use.  The primary purpose of CPP_PREDEFINES is to create reserved
names for non-reserved names so that the non-reserved names can be
"turned-off" if -ansi is set.  For macro names, C89 reserves "all
identifiers that begin with an underscore and either an uppercase letter
or another underscore."  Since "_MIPSEB" is already reserved, so no
need to create a reserved name for it.  "_mips" is not reserved, and
thus a reserved name is needed for it.



 > 3. Why apparent redundancies in options being passed from gcc to cpp don't get
 > eliminated.

Don't know.  I suspect because no one has writen the code to eliminate
them.  Or perhaps its more trouble to remove them than it's worth.

                                               -gavin...


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]