[Top][All Lists]
[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,