Re: Bug report gcc version 2.95.1 19990816 (release)

["Martin v. Loewis" <martin at mira dot isdn dot cs dot tu-berlin dot de>]

> I hope the information is enough to locate and fix the bug.

Thanks for your bug report. gcc-2.95.2 still has the same bug. The
mainline compiler produces a lot of error messages for that code,
starting with

In file included from /home/hiptmair/programming/C++/packages/blitz-19990818/blitz/vecexpr.h:285,
  from [...]vecpick.cc:37,
  from [...]vecpick.h:313,
  from [...]vector.h:489,
  from [...]tinyvec.h:442,
  from general.h:17,
  from grid.h:6,
  from grid.cc:4:
/home/hiptmair/programming/C++/packages/blitz-19990818/blitz/vecexpr.h: In instantiation of `blitz::promote_trait<int, int>':
[...]vecexpr.h:74:   instantiated from `blitz::_bz_VecExprOp<blitz::Range, blitz::Range, blitz::_bz_Add<int, int> >'
[...]vecbops.cc:618:   instantiated from `blitz::_bz_VecExpr<blitz::_bz_VecExprOp<blitz::Range, blitz::Range, blitz::_bz_Add<int, int> > >
[...]vecbops.cc:618:   instantiated from here
[...]vecexpr.h:74: conversion to incomplete type
[...]vecexpr.h:74: operands to ?: have different types
[...]vecexpr.h:74: enumerator value for `defaultPromotion' not integer constant

so the current gcc finds a number of problems with this code. Fixing
those might make 2.95 accept the code.

Apparently, the problem is with the fragment

    enum {
      ... some values ...
      knowT1butNotT2 =  (int) precision_trait<T1>::knowPrecisionRank  
        && !((int) precision_trait<T2>::knowPrecisionRank  ),    
      knowT2butNotT1 =  (int) precision_trait<T2>::knowPrecisionRank  
        && !((int) precision_trait<T1>::knowPrecisionRank  ),
      T1IsLarger = sizeof(T1) >= sizeof(T2),
      defaultPromotion = knowT1butNotT2 ? false  : 
         (knowT2butNotT1 ? true  : T1IsLarger)
    };

The compiler message looks right to me: the second 'arithmetic if' has
both boolean and enum arguments. 

It seems that the compiler tries to convert them into a common type,
which would be some integer type (5.16/6). When performing integral
promotions on T1IsLarger, conversion fails, as it needs to determine
the smallest type that can represent all values of the enum (see
4.5/2). Since the enum is not a complete type, yet, this conversion
fails.

Since it cannot determine the type which T1IsLarger is promoted to, it
reports different types. It then finds that the entire expression has
no good type, and complains about it not being an integer constant.

If you think this analysis is wrong, please refer to the relevant
sections in the standard.

Regards,
Martin