disabling C++ labeled initializers broke i386-linux's HUGE_VAL

[Mark Mitchell]

>>>>> "Alexandre" == Alexandre Oliva <oliva@dcc.unicamp.br> writes:

    Alexandre> Hi!

    Alexandre> The following patch:

    Alexandre> Mon Feb 9 22:23:31 1998 Mark Mitchell
    Alexandre> <mmitchell@usa.net>

    Alexandre>         * parse.y (initlist): Disable labeled
    Alexandre> initializers since they do not work as per the
    Alexandre> documentation, and since they do not use the same
    Alexandre> syntax as the C front end.
 
    Alexandre> has broken Linux's header files, such as huge_val.h,
    Alexandre> that defines HUGE_VAL as something that expands to:

Ack!

    Alexandre> (__extension__ ((union { unsigned char __c[8]; double
    Alexandre> __d; } ) { __c: { 0, 0, 0, 0, 0, 0, 0xf0, 0x7f }
    Alexandre> }).__d)

    Alexandre> Should we enable it back?  Or should this header file
    Alexandre> be fixed by some fixincludes script?  This header file
    Alexandre> is available like this at least on RedHat 4.0 and
    Alexandre> 5.0. :-(

The easiest thing to do is obviously to undo the change.  But, labeled
initializers really don't work at present in the C++ front-end.  I
understand what's happening in the header file; GLIBC is trying to
make things go faster by initializing the huge_val_t inline rather
than declaring it as a variable.  The non-gcc version is:

  static __huge_val_t __huge_val = { __HUGE_VAL_bytes };

The trick with the labeled initializers is only necessary because
there's no way to write HUGE_VAL as a double; instead the bits are
blasted in by using the union.

As far as I can tell, however, egcs generates the same code in either
case.  As long as __huge_val is not addressed, the compiler generates
the same code with -O4 for, e.g., 

  printf("%g", HUGE_VAL + 1.72)

whether HUGE_VAL is defined (in C) with labeled initializers or (in
C++) with the static variable __huge_val.  (Sadly, it does not do
any constant folding in either case.)  Yes, I know this is not
conforming code, but I didn't know what else to play with.

Therefore, I suggest that we do this:

  o Ask the GLIBC maintainers to remove the labeled initializers in
    GLIBC.
  o Use fixincludes to fix the affected headers in the meanwhile.

My second choice is that we:

  o Fix the C++ front-end to deal with labeled initializers correctly,
    but for PODS only.  (Labeled initializers make no sense at all
    for class types with data members with constructors; these just
    *must* be initialized in order.)

My third choice is that we:

  o Revert my earlier change, enabling (broken) labeled initializers
    in C++.

I'm willing to help out with whichever alternative we decide on.

    Alexandre> -- Alexandre Oliva mailto:oliva@dcc.unicamp.br
    Alexandre> mailto:aoliva@acm.org http://www.dcc.unicamp.br/~oliva
    Alexandre> Universidade Estadual de Campinas, SP, Brasil

-- 
Mark Mitchell		mmitchell@usa.net
Stanford University	http://www.stanford.edu