Re: 3.1.52 fails to build in hppa/linux

[Jaroslav Hajek]

On Sun, Feb 22, 2009 at 9:34 PM, Marco Atzeri <address@hidden> wrote:
>
> --- Dom 22/2/09, Jaroslav Hajek ha scritto:
>
>> Da: Jaroslav Hajek
>> Oggetto: Re: 3.1.52 fails to build in hppa/linux
>
>> Data: Domenica 22 febbraio 2009, 21:27
>> On Sun, Feb 22, 2009 at 9:22 PM, Marco Atzeri
>>  wrote:
>> >
>> > --- Dom 22/2/09, Jaroslav Hajek  ha scritto:
>> >
>> >> Da: Jaroslav Hajek
>> >> Oggetto: Re: 3.1.52 fails to build in hppa/linux
>> >> Data: Domenica 22 febbraio 2009, 21:14
>> >> On Sun, Feb 22, 2009 at 8:32 PM, Marco Atzeri
>> >>  wrote:
>> >> >
>> >> > --- Dom 22/2/09, Jaroslav Hajek  ha scritto:
>> >> >
>> > [CUT]
>> >
>> >> >>
>> >> >> Rafael,
>> >> >>
>> >> >> can you try compiling (no need to link)
>> the
>> >> following test
>> >> >> code? It
>> >> >> should be a simple instance of the same
>> issue.
>> >> >>
>> >> >> class A {};
>> >> >>
>> >> >> template <class X, class T> void
>> method
>> >> (double u, T
>> >> >> v);
>> >> >>
>> >> >> template <class X> void method
>> (double u,
>> >> long v);
>> >> >>
>> >> >> int main ()
>> >> >> {
>> >> >>   double u; long v;
>> >> >>   method<A> (u, v);
>> >> >> }
>> >> >>
>> >> >> If you get a failure, then you have a
>> buggy gcc.
>> >> >>
>> >> >> --
>> >> >> RNDr. Jaroslav Hajek
>> >> >
>> >> > Hi Jaroslav,
>> >> > your test compile fine on cygwin with
>> gcc-4.4.3.
>> >> >
>> >> > I suspect it is more an issue around int64_t
>> and
>> >> uint64_t
>> >> > as all the errors go in couple:
>> >> >
>> >> >
>> ../../octave_local/liboctave/oct-inttypes.cc:514:
>> >> error: ambiguous template specialization
>> >> 'mop<octave_int_cmp_op::ge>' for
>> 'bool
>> >> octave_int_cmp_op::mop(int64_t, double)'
>> >> >
>> ../../octave_local/liboctave/oct-inttypes.cc:514:
>> >> error: ambiguous template specialization
>> >> 'mop<octave_int_cmp_op::ge>' for
>> 'bool
>> >> octave_int_cmp_op::mop(uint64_t, double)'
>> >> >
>> >> > Regards
>> >> > Marco
>> >> >
>> >>
>> >> I see; it's probably a different issue, then.
>> I suspect
>> >> it only
>> >> happens on those architectures where long double
>> is equal
>> >> to double,
>> >> right? I'll try to investigate this.
>> >>
>> >> --
>> >> RNDr. Jaroslav Hajek
>> >
>> > Hi Jaroslav
>> > on cygwin double and long double are not equal.
>> >
>> > sizeof(int) == 4
>> > sizeof(long) == 4
>> > sizeof(long long) == 8
>> > sizeof(long long int) == 8
>> > sizeof(unsigned long long int) == 8
>> > sizeof(double) == 8
>> > sizeof(long double) == 12
>> > sizeof(int8_t) == 1
>> > sizeof(int16_t) == 2
>> > sizeof(int32_t) == 4
>> > sizeof(int64_t) == 8
>> > sizeof(uint8_t) == 1
>> > sizeof(uint16_t) == 2
>> > sizeof(uint32_t) == 4
>> > sizeof(uint64_t) == 8
>> >
>> > Regards
>> > Marco
>> >
>> >
>> >
>>
>> And is OCTAVE_INT_USE_LONG_DOUBLE defined in config.h? Do
>> you get the
>> same error as Rafael? You see, lines 511 and 514 in
>> oct-inttypes.cc
>> are inside an #ifdef OCTAVE_INT_USE_LONG_DOUBLE block.
>>
>>
>>
>> --
>> RNDr. Jaroslav Hajek
>
> OCTAVE_INT_USE_LONG_DOUBLE is defined
>
> same errors from 511 to 516
>
> Regards
> Marco

Whoa, that's wicked. Those lines should not even be compiled, then (I
meant, of course, ifndef block in the previous message). Can you maybe
try posting just the preprocessor output?

The easiest way to get it is to cd to liboctave/, do
make pic/oct-inttypes.o

then copy the command shown to compile, but replace "-c" by "-E" and
redirect -o to a suitable file. It will be probably too large to post
it on the mailing list.

Anyway, I think I just found another bug in gcc. The following does not compile:

#include <iostream>
class A
{
public:
  class B {};
  template <class T, class X> void x(X a) { std::cout << a; }
  template <class T> void x(int a);
};

template <class T>
void A::x (int a)
{
  std::cout << 'x' << a;
}
template void A::x<A::B> (int a);

The second explicit instantiation is not accepted. (Can you
confirm?...) In fact, g++ does not even recognize it as an explicit
instantiation, but instead gripes about ambiguous specialization, just
like in the error messages you've shown.
I'll try to inspect the C++ standard whether this is really valid (but
it seems so), and then maybe file a bug for GCC.
The code is accepted by Intel C++ 11.0, as well as the online Comeau
C++ checker, hence I'm fairly convinced it is correct even without
inspecting the standard.

Sigh. While I was reluctant to provide workarounds for gcc 3.x, bug in
4.3 is a different beast - that is probably something worth the
trouble... isn't it? Opinions?

cheers

-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz