tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] Please support coo.h


From: shinichiro . h
Subject: Re: [Tinycc-devel] Please support coo.h
Date: Sat, 12 Jun 2010 18:28:37 +0900
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (Goj$(D+W(B) APEL/10.7 Emacs/23.2 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)

Hi,

> i have pushed the patch on "mob"
> Coo: initial last member of union
> Please change my name of patch: U-YUAN\Administrator -> yuanbin

This change broke #include <math.h> on my Debian Linux.

% ~/wrk/tinycc/tcc math.c
In file included from math.c:1:
In file included from /usr/include/math.h:34:
/usr/include/bits/huge_val.h:52: error: '}' expected (got ",")

Here is the code in question:

typedef union { unsigned char __c[8]; double __d; } __huge_val_t;

# if __BYTE_ORDER == __BIG_ENDIAN
#  define __HUGE_VAL_bytes      { 0x7f, 0xf0, 0, 0, 0, 0, 0, 0 }
# endif
# if __BYTE_ORDER == __LITTLE_ENDIAN
#  define __HUGE_VAL_bytes      { 0, 0, 0, 0, 0, 0, 0xf0, 0x7f }
# endif

static __huge_val_t __huge_val = { __HUGE_VAL_bytes };
# define HUGE_VAL       (__huge_val.__d)

Apparently, glibc expects compilers initialize the first element of
a union. Also, it seems 6.7.8.17 of C99 standard
(http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf)
says compilers should initialize the first element?

17 Each brace-enclosed initializer list has an associated current object. When 
no designations are present, subobjects of the current object are initialized 
in order according to the type of the current object: array elements in 
increasing subscript order, structure members in declaration order, and the 
first named member of a union.127) In contrast, a designation causes the 
following initializer to begin initialization of the subobject described by the 
designator. Initialization then continues forward in order, beginning with the 
next subobject after that described by the designator.128)

So, we may want to revert this change maybe? Otherwise, the mob branch
is quite unusable :(

see also: http://gcc.gnu.org/ml/gcc/2010-06/msg00434.html

Thanks,



reply via email to

[Prev in Thread] Current Thread [Next in Thread]