On IBM RS/6000 AIX 4.2, I built R-1.2.1 with
% env CC=xlc CXX=xlC F77=f77 FC=f77 ./configure
R is now configured for powerpc-ibm-aix4.2.1.0
Source directory: .
Installation directory: /usr/local
C compiler: c89 -g
C++ compiler: xlC -g
FORTRAN compiler: f77 -g
X11 support: yes
Gnome support: no
Tcl/Tk support: yes
R profiling support: yes
R as a shared library: no
However, the R-1.2.1 build fails in a number of places:
c89 -I. -I../../src/include -I../../src/include -I/usr/local/include
-DHAVE_CONFIG_H -g -c fortran.c -o fortran.o
"../../src/include/Fortran.h", line 43.9: 1506-213 (S) Macro name abs
cannot
be redefined.
"../../src/include/Fortran.h", line 43.9: 1506-358 (I) "abs"
is defined on
line 362 of /usr/include/stdlib.h.
I found that putting "#undef abs" before line 43 of Fortran.h solves
that problem.
It then dies later in compilation of several routines, of which this
is typical:
c89 -I. -I../../src/include -I../../src/include -I/usr/local/include
-DHAVE_CONFIG_H -g -c devices.c -o devices.o
"../../src/include/Startup.h", line 48.14: 1506-009 (S) Bit-field
R_Quiet
must be of type signed int, unsigned int or int.
...
The complaint is from the use of a bitfield modifier on an enum;
gcc will compile this code, but IBM's cc and c89 will not.
This appears to be a violation of 1989 Standard C: in ANSI
X3.159-1989, on p. 61, section 3.5.2.1, I find at line 30:
>> ...
>> A bit-field shall have a type that is a qualified or unqualified
>> version of one of {\bf int}, {\bf unsigned int}, or {\bf signed int}.
...
>> ...
On the p. 62 in section 3.5.2.2, line 60:
>> ...
>> Each enumerated type shall be compatible with an integer type; the
>> choice of type is implementation-defined.
>> ...
In particular, if an enum is treated as char, short, long, or long
long, then it does not match the requirement of section 3.5.2.1.
To test this further, I made an experiment:
% cat boo.c
#if 1
typedef enum { apple = 0, pear } Fruit;
#else
typedef int Fruit;
#endif
typedef struct boo {
Fruit x : 1;
} S_Fruit;
S_Fruit y;
On Sun Solaris 2.7:
% c89 -Xa -c boo.c
% c89 -Xt -c boo.c
% c89 -Xc -c boo.c
"boo.c", line 9: warning: nonportable bit-field type
% cc -c boo.c
% gcc -c boo.c
% lcc -A -A -c boo.c
boo.c:9: `Fruit' is an illegal bit-field type
% CC -c boo.c
% g++ -c boo.c
On SGI IRIX 6:
% c89 -c boo.c
% gcc -c boo.c
% lcc -A -A -c boo.c
boo.c:9: `Fruit' is an illegal bit-field type
% CC -c boo.c
% g++ -c boo.c
On Compaq/DEC Alpha OSF/1 4.0:
% c89 -c boo.c
cc: Info: boo.c, line 9: In the declaration of "x", the bitfield type
is not an int, signed int or unsigned int. (bitnotint)
Fruit x : 1;
----------^
% gcc -c boo.c
% lcc -A -A -c boo.c
boo.c:9: `Fruit' is an illegal bit-field type
% cxx -c boo.c
% g++ -c boo.c
On GNU/Linux (Redhat 6.2) on Intel x86:
% cc -c boo.c
% gcc -c boo.c
% lcc -A -A -c boo.c
boo.c:9: `Fruit' is an illegal bit-field type
% g++ -c boo.c
% pgcc -c boo.c
% pgCC -c boo.c
On IBM RS/6000 AIX 4.3:
% cc -c boo.c
"boo.c", line 9.11: 1506-159 (E) Bit-field type specified for x is
not valid. Type unsigned assumed.
% gcc -c boo.c
CC -c boo.c
% CC -c boo.c
% g++ -c boo.c
% c89 -c boo.c
"boo.c", line 9.11: 1506-009 (S) Bit-field x must be of type signed
int, unsigned int or int.
% xlC -c boo.c
"boo.c", line 9.11: 1506-009 (S) Bit-field x must be of type signed
int, unsigned int or int.
% xlc -c boo.c
"boo.c", line 9.11: 1506-009 (S) Bit-field x must be of type signed
int, unsigned int or int.
Thus, the stricter 1989 Standard C compilers reject the use of the enum in
a bitfield.
C++ (ISO/IEC 14882-1998) says in section 9.5:
>> ...
>> 4 If the value true or false is stored into a bit-field of type bool
>> of any size (including a one bit bit-field), the original bool value
>> and the value of the bit-field shall compare equal. If the value of
>> an enu-merator is stored into a bit-field of the same enumeration type
>> and the number of bits in the bit-field is large enough to hold all
>> the values of that enumeration type, the original enumerator value and
>> the value of thebit-field shall compare equal.
>> ...
This suggests that Standard C++ permits enums to have bitfield
modifiers. However, as far as I know, there are not yet any Standard
C++ compilers available on any platform.
I could not find definitive language in ISO/IEC 9899-1999, the 1999 C
Standard on this point.
In summary, it seems best to eliminate the bitfield modifiers on enum
data. Even if this involves a small memory penalty, it will probably
make the code faster, since bitmasking and shifting is no longer
needed to access the fields.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- Center for Scientific Computing FAX: +1 801 585 1640, +1 801 581 4148 -
- University of Utah Internet e-mail: beebe@math.utah.edu -
- Department of Mathematics, 322 INSCC beebe@acm.org beebe@computer.org -
- 155 S 1400 E RM 233 beebe@ieee.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe -
-------------------------------------------------------------------------------
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !) To:
r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._