This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

bug 2914 & scope

I attach a stripped down 2914 test case, which ICE's at the definition
of DoubleSupport::toDouble. The reason for this is the definition of
DoubleSupport::s_positiveInfinity. You'll see that defines a union named
tag (in the test case that was anonymous). That definition is placed into
the scope of DoubleSupport and appended to its TYPE_FIELDs chain. However,
it is not put into the sorted table of fields (DoubleSupport has more
than seven members, so it gets sorted).

My question is, should that union be put into DoubleSupport's scope at all?
DoubleSupport is complete at that point, so why are new types being put into

Should there be an `initializer scope' akin to `prototype scope' [3.3.3]?


Dr Nathan Sidwell   ::   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?' : :

class DoubleSupport
  static void toDouble();
  static const double s_NaN;
  static const double s_positiveInfinity;
  static const double s_negativeInfinity;
  static const double s_positiveZero;
  static const double s_negativeZero;
  static const unsigned long* s_NaNFirstDWORD;
  static const unsigned long* s_NaNSecondDWORD;

const double DoubleSupport::s_positiveInfinity =
(__extension__ ((union tag { unsigned char __c[8]; double __d; })
  { __c: { 0, 0, 0, 0, 0, 0, 0xf0, 0x7f } }).__d);

struct other 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]