From beebe@math.utah.edu  Sat Feb 17 01:47:00 2001
From: beebe@math.utah.edu (beebe@math.utah.edu)
Date: Sat, 17 Feb 2001 02:47:00 +0100 (MET)
Subject: [Rd] More comments on R-1.2.1 builds (PR#852)
Message-ID: <200102170147.CAA19365@pubhealth.ku.dk>

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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._


[Rd] More comments on R-1.2.1 builds (PR#852)
beebe@math.utah.edu