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: yuanbin
Subject: Re: [Tinycc-devel] Please support coo.h
Date: Sun, 13 Jun 2010 02:47:33 +0800

i'm sorry!
i have pushed the new patch on "mob"
tccgen: skip fields from same union


2010/6/12 shinichiro.h <address@hidden>:
> 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]