Re: Loki's tricky templates

Re: Loki's tricky templates

[Kriang Lerdsuwanakij]

Paolo Carlini wrote:

>Yes, I agree that most probably it is valid. But Gcc don't like the 
>association
>of template-templates *and* the VisitorBinder pattern.
>It is amazing how many weird template tricks Andrei has developed!
>
>If someone else, more into template-template parameters will agree with us, I
>may file a GNATS PR and then begin investigating a couple of other problems in
>the Loki headers.

Hi

Your code relies on a template template parameter feature (template
template argument which scope is template parameter dependent) that
has not been implemented in gcc yet.  It was missing from the C++
standard as the language grammar doesn't allow it.  This now appears
as an issue in the C++ standard committee.  The correct version
of problematic code is shown below.

template <typename R, class TList>
class CyclicVisitor
     : public GenScatterHierarchy<TList, VisitorBinder<R>::template Result>
                                                                             ^^^^^^^
                                                                         keyword 
required

--Kriang

Re: Loki's tricky templates

[Paolo Carlini]

Hi,

thanks for the very technical feedback!

So, please, let me recapitulate what you say:
1- That syntax, used in Loki, is not strictly ISO C++, but it is an issue in the
committee.
2- The correct syntax is presently that which you kindly explained, involving the
template keyword. In fact, a (commonly believed) very compliant compiler which rejected
the original code do compile fine a version modified according to your suggestion!
3- In any case, the current and past Gcc compilers are not able to deal with either the
current or the future syntax :(
Indeed, the segmention fault becomes just a plain error (I locally name the code
reduced.cpp):

--------
reduced.cpp:24: parse error before `>' token
reduced.cpp:33: syntax error before `(' token
reduced.cpp:33: missing ';' before right brace
reduced.cpp:31: ISO C++ forbids declaration of `DocElement' with no type
reduced.cpp:31: ISO C++ forbids declaration of `DocElement' with no type
--------

P.


Kriang Lerdsuwanakij wrote:

> Your code relies on a template template parameter feature (template
> template argument which scope is template parameter dependent) that
> has not been implemented in gcc yet.  It was missing from the C++
> standard as the language grammar doesn't allow it.  This now appears
> as an issue in the C++ standard committee.  The correct version
> of problematic code is shown below.
>
> template <typename R, class TList>
> class CyclicVisitor
>      : public GenScatterHierarchy<TList, VisitorBinder<R>::template Result>
>                                                                              ^^^^^^^
>                                                                          keyword
> required
>
> --Kriang

Re: Loki's tricky templates

[Kriang Lerdsuwanakij]

At 17:48 21/4/01 +0200, Paolo Carlini wrote:
>Hi,
>
>thanks for the very technical feedback!
>
>So, please, let me recapitulate what you say:
>1- That syntax, used in Loki, is not strictly ISO C++, but it is an issue 
>in the
>committee.

I take it back about the part that it's still a language issue.  (I was 
confused
with some other issues with the usage of 'template' keyword.)  The Loki's
syntax is not ISO C++ but the correct one is.  The 'template' keyword 
requirement
is mentioned in section 14.2 paragraph 4 and 5 of the standard.

>2- The correct syntax is presently that which you kindly explained, 
>involving the
>template keyword. In fact, a (commonly believed) very compliant compiler 
>which rejected
>the original code do compile fine a version modified according to your 
>suggestion!

A standard-compliant compiler should reject the original version and accept
the modified one.

>3- In any case, the current and past Gcc compilers are not able to deal 
>with either the
>current or the future syntax :(
>Indeed, the segmention fault becomes just a plain error (I locally name 
>the code
>reduced.cpp):

Right.  It's an unimplement feature right now.  It should present in gcc 3.1.
I'll work on an implementation of this in a couple months.

--Kriang


>--------
>reduced.cpp:24: parse error before `>' token
>reduced.cpp:33: syntax error before `(' token
>reduced.cpp:33: missing ';' before right brace
>reduced.cpp:31: ISO C++ forbids declaration of `DocElement' with no type
>reduced.cpp:31: ISO C++ forbids declaration of `DocElement' with no type
>--------
>
>P.
>
>
>Kriang Lerdsuwanakij wrote:
>
> > Your code relies on a template template parameter feature (template
> > template argument which scope is template parameter dependent) that
> > has not been implemented in gcc yet.  It was missing from the C++
> > standard as the language grammar doesn't allow it.  This now appears
> > as an issue in the C++ standard committee.  The correct version
> > of problematic code is shown below.
> >
> > template <typename R, class TList>
> > class CyclicVisitor
> >      : public GenScatterHierarchy<TList, VisitorBinder<R>::template Result>
> > 
 >      ^^^^^^^
> > 
 >  keyword
> > required
> >
> > --Kriang

Re: Loki's tricky templates

[Paolo Carlini]

Hi,

Kriang Lerdsuwanakij wrote:

> I take it back about the part that it's still a language issue.  (I was
> confused
> with some other issues with the usage of 'template' keyword.)  The Loki's
> syntax is not ISO C++ but the correct one is.  The 'template' keyword
> requirement
> is mentioned in section 14.2 paragraph 4 and 5 of the standard.

Many thanks for the pointer: I'll have a look at it.

> Right.  It's an unimplement feature right now.  It should present in gcc 3.1.
> I'll work on an implementation of this in a couple months.

That's good news!
It seems that templates are very hot today and Gcc must become even more
irreprehensible in this field!

A courtesy: would you please mind having a quick look at (thereafter I will move
to other non-compile spots in Loki):

    http://gcc.gnu.org/ml/gcc/2001-04/msg01019.html


Thanks,
Paolo.

Re: Loki's tricky templates

[Kriang Lerdsuwanakij]

At 22:47 22/4/01 +0200, Paolo Carlini wrote:

>A courtesy: would you please mind having a quick look at (thereafter I 
>will move
>to other non-compile spots in Loki):
>
>     http://gcc.gnu.org/ml/gcc/2001-04/msg01019.html

Sure, the code is illegal.  According to the standard, in section 14.3.1 
paragraph 2:
     A local type, a type with no linkage, an unnamed type or a type compounded
     from any of these types shall not be used as a template-argument for a 
template
     type-parameter.
So template argument deduction for SetLongevity function call fails.

--Kriang

Re: Loki's tricky templates

[Paolo Carlini]

Thanks!

you are so kind in providing me with detailed citations from the standard: with
"Gaby" Dos Reis we seriously doubted that real errors were present in the Loki
code, perhaps because there are in it so many cool but nonetheless exotic and/or
frequently unimplemented template patterns (and quite a few typos ;)
(also, in many cases a diagnostic message pointing to the real issue in the
standard clearly emerges only after a good amount of distillation...)

In these days I'm just trying to disentagle the whole and your help has been very
useful!

P.


Kriang Lerdsuwanakij wrote:

> >     http://gcc.gnu.org/ml/gcc/2001-04/msg01019.html
>
> Sure, the code is illegal.  According to the standard, in section 14.3.1
> paragraph 2:
>      A local type, a type with no linkage, an unnamed type or a type compounded
>      from any of these types shall not be used as a template-argument for a
> template
>      type-parameter.
> So template argument deduction for SetLongevity function call fails.
>
> --Kriang

Re: Loki's tricky templates

[Gabriel Dos Reis]

Paolo Carlini <pcarlini@unitus.it> writes:

| Thanks!
| 
| you are so kind in providing me with detailed citations from the standard: with
| "Gaby" Dos Reis we seriously doubted that real errors were present in the Loki
| code, perhaps because there are in it so many cool but nonetheless exotic and/or
| frequently unimplemented template patterns (and quite a few typos ;)

As I said earlier, I didn't have the time to look closely at Loki --
I'm just short of time.

But certainly Kriang has a correct analysis for the template template
parameter syntax and the local type issue (this one iswell known
and has been subject of extensive discussion on comp.std.c++).

Thank you for pointing out g++ weaknesses in compiling Loki -- that is
very helpful.  Thanks to Kriang for his analysis.

-- Gaby

Long long & templates (was: Re: Loki's tricky templates)

[Paolo Carlini]

Hi Gaby,

nice to hear from you!

regarding that other library which we both care about, Boost, I have just discovered
that Peter Schmid had already discovered, independently from me, the present
limitation in the size of numbers which Gcc can presently mangle (PR2364, PR2195,
PR2196, and my PR2559).
Now I have a curiosity about which I'd like to ask your opinion (I don't know if this
is a classified topic): why the choice was made to limit for Gcc3.0 that size, at risk
of an *apparent* (I know that long long are not standard but nonetheless...)
regression from Gcc2.95.2 (i.e., those 3 Boost testsuite failures)???

Thanks,
Paolo.


Gabriel Dos Reis wrote:

> Thank you for pointing out g++ weaknesses in compiling Loki -- that is
> very helpful.  Thanks to Kriang for his analysis.

Re: Long long & templates (was: Re: Loki's tricky templates)

[Gabriel Dos Reis]

Paolo Carlini <pcarlini@unitus.it> writes:

| Hi Gaby,
| 
| nice to hear from you!
| 
| regarding that other library which we both care about, Boost, I have just discovered
| that Peter Schmid had already discovered, independently from me, the present
| limitation in the size of numbers which Gcc can presently mangle (PR2364, PR2195,
| PR2196, and my PR2559).
| Now I have a curiosity about which I'd like to ask your opinion (I don't know if this
| is a classified topic): why the choice was made to limit for Gcc3.0 that size, at risk
| of an *apparent* (I know that long long are not standard but nonetheless...)

I don't think that was designed on purpose since the compiler do have
flags to accept long long.  It is more about bugs than purposely
decisions. 

-- Gaby

Re: Long long & templates (was: Re: Loki's tricky templates)

[Paolo Carlini]

Hi all (hi Gaby, hi Benjamin),

thanks for your feedback.

As you have probably understood by now :) I'm always eager to understand more about the Gcc
project, and recently I'm following both the 3.x branches and libstdc++ with particular
attention.

Let me say that I'm particularly happy that you all appreciate any detailed bug report and
in general consider them as a mean to an end: improve the compiler, the library and make
them better than ever (and better than the tough competition ;)

As for long long in templates: for the moment being, let's catch in the front end those
negative big numbers and emit a proper diagnostic (that should be easy for you) !!

P.

Re: Long long & templates (was: Re: Loki's tricky templates)

[Phil Edwards]

On Mon, Apr 23, 2001 at 07:06:56PM +0200, Paolo Carlini wrote:
> Now I have a curiosity about which I'd like to ask your opinion (I don't know if this
> is a classified topic): why the choice was made to limit for Gcc3.0 that size, at risk
> of an *apparent* (I know that long long are not standard but nonetheless...)
> regression from Gcc2.95.2 (i.e., those 3 Boost testsuite failures)???

I happened on this code yesterday while reading over some mangling documents.
It doesn't seem to be a design decision (e.g., "let's not implement this at
all"), rather it seems that the author had to delay the issue while solving
other problems (e.g., "this probably won't happen anytime soon, I hope").

    /* Write out an integeral CST in decimal.  */
    static inline void
    write_integer_cst (cst)
         tree cst;
    {
      if (tree_int_cst_sgn (cst) >= 0)
        {
          if (TREE_INT_CST_HIGH (cst) != 0)
            sorry ("mangling very large integers");
          write_unsigned_number (TREE_INT_CST_LOW (cst));
        }
      else
        write_signed_number (tree_low_cst (cst, 0));
    }

I'm not familiar with the mangling code, so I don't know how feasible it
would be to "simply" extend write_number to handle full INTEGER_CST's; right
now it takes a single HOST_WIDE_INT instead of the (I think) needed two.

Phil

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.

Re: Long long & templates (was: Re: Loki's tricky templates)

[Paolo Carlini]

Hi all, hi Phil (I'm back to you after a good amount of sleep)

Phil Edwards wrote:

[snip]

>     /* Write out an integeral CST in decimal.  */
>     static inline void
>     write_integer_cst (cst)
>          tree cst;
>     {
>       if (tree_int_cst_sgn (cst) >= 0)
>         {
>           if (TREE_INT_CST_HIGH (cst) != 0)
>             sorry ("mangling very large integers");
>           write_unsigned_number (TREE_INT_CST_LOW (cst));
>         }
>       else
>         write_signed_number (tree_low_cst (cst, 0));
>     }
>
> I'm not familiar with the mangling code, so I don't know how feasible it
> would be to "simply" extend write_number to handle full INTEGER_CST's; right
> now it takes a single HOST_WIDE_INT instead of the (I think) needed two.

Indeed, when I wrote something along the lines "for you developers, should be easy to fix
the front-end to emit a proper diagnostic", I had had a look at *exactly* this part of the
code in mangle.c !!! (basically, I arrived at it by simply grepping the sources for
"mangling very large integers")

I'm definitely *not* familiar with the mangling code but something is *very* suspect with
that section: if cst is negative, no check at all is performed on it's size!

Anyway, that portion of code, overall, is quite easy to follow!?!
Perhaps we could even venture to prepare a patch, my stronger concern being that at the
moment I don't know if there are any macro and functions which could be easily exploited to
this end. Perhaps a TREE_INT_CST_HIGH which is able to check numbers large in modulus, both
positive and negative???

A couple of puntualizations on my part about the issue at large: yesterday I did *really*
believe that restricting the size of mangl-able numbers had been probably an (obscure)
design choice (my question was not a rethoric one!): I had reasoned that perhaps in this way
the mangler is faster, or something else. Also, whereas Gcc is moving to support C99 (thanks
Benjamin for the explanations) on the other hand, *templates* are definitely not C89 neither
C99. So, perhaps, it would be consistent not to allow long long in templates... On the other
hand it my seems strange, to say the least, that long long numbers are supported everywhere
else *except* in templates...


P.

Re: Long long & templates (was: Re: Loki's tricky templates)

[Benjamin Kosnik]

Paolo, these are all good bugs, and good bug reports. Thanks.

There was/is no thought to constrict g++ WRT integer type sizes that
I'm aware of: these are straightforward bugs in g++ C99 support, and
should be fixed. Perhaps part of the problem was that libstdc++ had
turned off long long support by default, which meant that long long
support didn't get as much testing as it should have. That's now
fixed, and I suspect that these compiler bits will be soon be taken
care of as well. 

-benjamin