[gnu.gcc.bug] Constants and long long int

davis@CS.UNC.EDU (Mark Davis) (09/13/89)

Thanks for the responses on my previous posting concerning long long
ints.  My example program (with your help) identified that:
	1. GCC passes long long ints as 8 bytes which printf then
	   interprets as two ints.  My test program printed misleading
	   results because of that because I was only printing
	   4 bytes per long long int variable.
	2. GCC for the MC 68000 as distributed has the low order word
	   first followed by the high order word (little endian) while
	   bits and bytes are big endian.  This surprised me.

However, I have found some other things that may really be bugs (:-):
GCC 1.35.98 does not properly handle assignments of constants and long
long int constants to long long ints:

	1. When a compiler is built with WORDS_BIG_ENDIAN, int
	   constants are assigned to the high order word instead of the
	   low order word.
	2. Decimal represented int constants > 2^32 are not identified
	   as errors.
	3. Decimal represented long long int constants > 2^32 are not
	   properly converted and/or assigned.
	4. Hex represented long long int constants have high and low
	   order words reversed (probably same as 1).

=================== Program Source Listing =========================
main ()
{
long long int lli;
int i;

i=3;
lli=i;
printf("My printf takes a long long int as two ints.\n\n");
printf("Assignment from int to long long int works correctly\n");
printf("lli=%d/%d (should be 0/3)\n\n",lli);

printf("Small constants go in high order word.\n");
lli=5;
printf("lli=%d/%d (should be 0/5)\n\n",lli);

printf("Constants > 2^32 not detected.\n");
lli = 4294067298; /* 2^32+2 */
printf("lli=%d/%d (should be 1/2, really compile time error)\n\n",lli);

printf("Constants 2^32 not properly handled.\n");
lli = 4294067298ll; /* 2^32+2 */
printf("lli=%d/%d (should be 1/2)\n\n",lli);

	/* compiler correctly identifies:
		lli = 0x0100000002;
	as an error (integer constant out of range) */
lli = 0x0100000002ll; /* 2^32+2 */
printf("lli=%d/%d (should be 1/2)\n",lli);
}

=================== Run Time Output ================================
clocs% const
My printf takes a long long int as two ints.

Assignment from int to long long int works correctly
lli=0/3 (should be 0/3)

Small constants go in high order word.
lli=5/0 (should be 0/5)

Constants > 2^32 not detected.
lli=-899998/0 (should be 1/2, really compile time error)

Constants 2^32 not properly handled.
lli=-899998/0 (should be 1/2)

lli=2/1 (should be 1/2)

=================== Compiler Output ================================
gcc -g -v  const.c -o const
gcc version 1.35.98
 /unc/davis/lib/gcc-cpp -v -undef -D__GNUC__ -Dmc68000 -Dsun -Dunix -D__mc68000__ -D__sun__ -D__unix__ -D__HAVE_68881__ -Dmc68020 const.c /tmp/cca18781.cpp
GNU CPP version 1.35.98
 /unc/davis/lib/gcc-cc1 /tmp/cca18781.cpp -quiet -dumpbase const.c -g -version -o /tmp/cca18781.s
GNU C version 1.35.98 (68k, MIT syntax) compiled by CC.
default target switches: -m68020 -mc68020 -m68881 -mbitfield
 as -mc68020 -o const.o /tmp/cca18781.s
 ld -o const /lib/crt0.o /lib/Mcrt1.o const.o /unc/davis/lib/gcc-gnulib -lg -lc

=================== Compiler Building Parameters ===================
I took gcc 1.35.98 and did the following on a Sun 3/60 running SunOS 3.5:

1. Moved the comment delimeter in tm-m68k.h so WORDS_BIG_ENDIAN would
   be defined.
2. Edited the Makefile to make $(bindir), $(libdir), and $(mandir) in
   my private directories.
3. ran "config.gcc sun"
4. ran "make install"

news@bbn.COM (News system owner ID) (09/19/89)

In article <8909130120.AA18850@clocs.cs.unc.edu> davis@CS.UNC.EDU (Mark Davis) writes:
< 	2. GCC for the MC 68000 as distributed has the low order word
< 	   first followed by the high order word (little endian) while
< 	   bits and bytes are big endian.  This surprised me.

Oh NO!!!  Can we *please* not do a "long long" version of
confused-endian?  Please?  wimper.

Really.  The endian of everything should match the endian of
everything else.  Let a Vax be a Vax, and ditto for a 68000, otherwise
confusion reigns (hence the original term "confused endian").

		-- Paul Placeway <pplaceway@bbn.com>