[C++ dayly bug report] const_cast to rvalue of class type

[C++ dayly bug report] const_cast to rvalue of class type

[Gabriel Dos_Reis]

EGCS/g++ happily accepts to const_cast to rvalues of class type.

// --- cut here ---
#include <iostream>

struct A {
  A() {}
  A(const A&) { std::cout << "A::A(const A&)\n"; }
};

int main()
{
  A a;
  const_cast<const A>(a);	// ERROR
}
// --- cut here ---


The program is ill-formed according to 5.2.11.

-- Gaby

Re: [C++ dayly bug report] const_cast to rvalue of class type

[Martin v. Loewis]

> Hmmm... 5.2.11 part 1 does not appear to disallow this cast and part 4
> says that an lvalue of type T1 can be const_cast to an lvalue of type T2
> as long as a pointer to T1 can be converted to a pointer to T2. That
> would allow this conversion the way I read it. This lvalue rvalue stuff
> always gets me screwed up but that's how I read it. Now the limitation
> you're talking about is certainly true and explicitly stated for dynamic
> casts. If I'm wrong I'd really like to know why.

Because 5.2.11/4 says "using the cast const_cast<T2&>". The cast in
question was not to a reference type.

Regards,
Martin
>From martin@mira.isdn.cs.tu-berlin.de Fri Apr 30 00:37:00 1999
From: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>
To: ckern@cad.fla.fujitsu.com
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: internal compiler error (egcs-2.91.66)
Date: Fri, 30 Apr 1999 00:37:00 -0000
Message-id: <199904300729.JAA00668@mira.isdn.cs.tu-berlin.de>
References: <3728F714.92E2F6EF@fla.fujitsu.com> <3728F714.92E2F6EF@fla.fujitsu.com>
X-SW-Source: 1999-04/msg00883.html
Content-length: 318

> Just hit another internal compiler error.  The input is sufficiently
> different from the one that I posted about just before to suggest that the
> problem might be somewhere else.

I just tried to compile this with egcs-2.93.19 19990425, and it
compiled fine. Likely, the bug will be fixed in 1.2.

Regards,
Martin
>From martin@mira.isdn.cs.tu-berlin.de Fri Apr 30 00:38:00 1999
From: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>
To: ckern@cad.fla.fujitsu.com
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: bogus error message? (egcs-2.91.66)
Date: Fri, 30 Apr 1999 00:38:00 -0000
Message-id: <199904300731.JAA00682@mira.isdn.cs.tu-berlin.de>
References: <3728F74F.B0831C0B@fla.fujitsu.com> <3728F74F.B0831C0B@fla.fujitsu.com>
X-SW-Source: 1999-04/msg00884.html
Content-length: 371

> To me, this one looks like it's related to the internal compiler error I
> posted just now, but then again it might not be. 
> 
> Anyway, g++ complains that I'm supplying 57 template arguments, which
> doesn't seem right...

I could reproduce this with egcs 1.1.2; egcs-2.93.19 19990425 compiles
it just fine. So the bug will probably be fixed in 1.2.

Regards,
Martin
>From martin@mira.isdn.cs.tu-berlin.de Fri Apr 30 00:41:00 1999
From: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>
To: ckern@cad.fla.fujitsu.com
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: Internal compiler error
Date: Fri, 30 Apr 1999 00:41:00 -0000
Message-id: <199904300736.JAA00695@mira.isdn.cs.tu-berlin.de>
References: <3728DEA4.AF2663EC@fla.fujitsu.com> <3728DEA4.AF2663EC@fla.fujitsu.com>
X-SW-Source: 1999-04/msg00885.html
Content-length: 955

> ok, after posting a spurious bug report yesterday, I chanced upon a genuine
> one today (Internal compiler error).  Note though that the input that
> triggers the error is non-sensical (in particular, involves the phrase
>    template <>
>    namespace tralala {
> which I happened to compile while further toying with templates). 
> Nevertheless, I figure you might like to know about internal errors no
> matter what.

Thanks for your report.  egcs-2.93.19 reports

bug-E.cc:9818: parse error before `namespace'
bug-E.cc:9874: confused by earlier errors, bailing out

So this appears to be fixed.

Regards,
Martin

P.S. Maybe you wonder when egcs 1.2 will be actually appear; please
have a look at http://egcs.cygnus.com/egcs-1.2/schedule.html . After
the branch is made, snapshots will be 'release candidates', to use the
terminology of a large software company :-) I'd encourage you to test
these snapshots, to make sure they don't break your code.
>From adam@dusk.org Fri Apr 30 03:01:00 1999
From: Adam Wiggins <adam@dusk.org>
To: oliva@dcc.unicamp.br (Alexandre Oliva)
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: internal compiler error on Mesa
Date: Fri, 30 Apr 1999 03:01:00 -0000
Message-id: <199904301003.DAA24292@dusk.org>
References: <oriuafpqh4.fsf@lua.lbi.dcc.unicamp.br>
X-SW-Source: 1999-04/msg00886.html
Content-length: 2331

Sorry, here are the .i and .c files.  I also included the .h since
that's where the code that's actually causing the problem resides.

To recap: egcs 1.1.2 on Red Hat Linux 5.2 reports:

csh:~/MesaCVS/src> gcc -v --save-temps -fPIC -ffast-math -D_SVID_SOURCE -D_BSD_SOURCE -DUSE_X86_ASM -DSHM -DFX -I/usr/X-DSHM -DFX -I/usr/X11R6HM -DFX -I/usr/X11R6/M -DFX -I/usr/X111/i -DFX -I/usr/X11R6/in-DFX -I/usr/X11R6/incDFX -I/usr/X11R6/inclFX -I/usr/X11R6/inclu11RReading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.91.66/specsde -I/us/X11gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)1R6/include -I/usr/include/glide -I/ /usr/local/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.91.66/cpp -lang-c89 -v -I. -I../include -I/usr/X11R6/include -I/usr/include/glide -I/usr/local/glide/include -undef -D__GNUC__=2 -D__GNUC_MINOR__=91 -trigraphs -D__STRICT_ANSI__ -D__ELF__ -D__unix__ -D__i386__ -D__i386__ -D__linux__ -D__unix -D__i386 -D__linux -Asystem(posix) -D__OPTIMIZE__ -pedantic -Asystem(unix) -Acpu(i386) -Amachine(i386) -D__i386 -D__i386__ -D__i686 -D__i686__ -D__pentiumpro -D__pentiumpro__ -D__PIC__ -D__pic__ -D_SVID_SOURCE -D_BSD_SOURCE -DUSE_X86_ASM -DSHM -DFX fog.c fog.i
GNU CPP version egcs-2.91.66 19990314 (egcs-1.1.2 release) (i386 Linux/ELF)
#include "..." search starts here:
#include <...> search starts here:
 .
 ../include
 /usr/X11R6/include
 /usr/local/include
 /usr/local/i686-pc-linux-gnu/include
 /usr/local/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.91.66/include
 /usr/include
End of search list.
 /usr/local/lib/gcc-lib/i686-pc-linux-gnu/egcs-2.91.66/cc1 fog.i -quiet -dumpbase fog.c -ansi -O3 -pedantic -ansi -version -fPIC -ffast-math -o fog.s
GNU C version egcs-2.91.66 19990314 (egcs-1.1.2 release) (i686-pc-linux-gnu) compiled by GNU C version egcs-2.91.66 19990314 (egcs-1.1.2 release).
fog_tmp.h: In function `fog_rgba_vertices_raw':
In file included from fog.c:129:
fog_tmp.h:151: Could not find a spill register
(insn:HI 1268 1266 1271 (set (subreg:SF (reg/v:QI 333) 0)
        (plus:SF (reg:SF 10 %st(2))
            (reg:SF 8 %st(0)))) 371 {strlensi-3} (insn_list 1262 (insn_list 1261 (nil)))
    (expr_list:REG_DEAD (reg:SF 10 %st(2))
        (expr_list:REG_DEAD (reg:SF 8 %st(0))
            (nil))))
toplev.c:1367: Internal compiler error in function fatal_insn

The files are attached.

Re: [C++ dayly bug report] const_cast to rvalue of class type

[Gabriel Dos_Reis]

Benjamin Scherrey <scherrey@switchco.com> writes:

| Please pardon my ignorance here but I'm not sure I understand what the
| issue is. For const_cast, the return type for a cast from anything other
| than a reference type is an rvalue.

No, you can use const_cast<T> if T is one of
	- pointer type
	- reference type
Any other type is forbidden.

| ...  In this case I would expect your
| code to execute the default constructor then call your copy constructor.
| Your cast doesn't have any effect that I can see. Is this not the
| behaviour you're getting or anticipate?

No. const_cast<T> (value) is ill-formed when T is a class
type. Please, check the appropriate part of the standard I quoted.

-- Gaby

Re: [C++ dayly bug report] const_cast to rvalue of class type

[Gabriel Dos_Reis]

Benjamin Scherrey <scherrey@switchco.com> writes:

| Hmmm... 5.2.11 part 1 does not appear to disallow this cast and part 4
| says that an lvalue of type T1 can be const_cast to an lvalue of type T2
| as long as a pointer to T1 can be converted to a pointer to T2. That
| would allow this conversion the way I read it. This lvalue rvalue stuff
| always gets me screwed up but that's how I read it. Now the limitation
| you're talking about is certainly true and explicitly stated for dynamic
| casts. If I'm wrong I'd really like to know why.

The last two sentences of 5.2.11/1 say:

---
  Conversions that can be performed explicitly using const_cast are
  listed below. No other conversion shall be performed explicitly
  using const_cast.
---

5.2.11/3 deals exclusively with pointers.

5.2.11/4 states exactly:

---
  An lvalue of type T1 can be explicitly converted to an lvalue of
  type T2 using the cast const_cast<T2&> (whete T1 and T2 are object
                                      ^
  types) if a pointer to T1 can be explicitly converted to the type
  pointer T2 using const_cast. The result of a reference const_cast
  refers to the original object.
---

Notice 'T2&' in the syntax.

the remaining of 5.2.11 doesn't mention any case where const_cast<T2>
is allowed when T2 is class type.


-- Gaby

Re: [C++ dayly bug report] const_cast to rvalue of class type

[Benjamin Scherrey]

Please pardon my ignorance here but I'm not sure I understand what the
issue is. For const_cast, the return type for a cast from anything other
than a reference type is an rvalue. In this case I would expect your
code to execute the default constructor then call your copy constructor.
Your cast doesn't have any effect that I can see. Is this not the
behaviour you're getting or anticipate?

	later,

		Ben Scherrey

Gabriel Dos_Reis wrote:
> 
> EGCS/g++ happily accepts to const_cast to rvalues of class type.
> 
> // --- cut here ---
> #include <iostream>
> 
> struct A {
>   A() {}
>   A(const A&) { std::cout << "A::A(const A&)\n"; }
> };
> 
> int main()
> {
>   A a;
>   const_cast<const A>(a);       // ERROR
> }
> // --- cut here ---
> 
> The program is ill-formed according to 5.2.11.
> 
> -- Gaby

Re: [C++ dayly bug report] const_cast to rvalue of class type

[Benjamin Scherrey]

	Yep, didn't notice the '&' there at first. I guess I can't disagree
with your interpretation of the text. It does seem vauge in this area. I
wonder why they didn't explicitly mention a limitation of only
const_cast'ing pointers and references like they did for dynamic_cast if
that was their intent. I still don't believe that it was their intent to
limit the const_cast as you say at all. Can you tell me why this
limitation would be meaningful? I don't see anything gained by it.

	thanx & later,

		Ben Scherrey

Gabriel Dos_Reis wrote:
> 5.2.11/4 states exactly:
> 
> ---
>   An lvalue of type T1 can be explicitly converted to an lvalue of
>   type T2 using the cast const_cast<T2&> (whete T1 and T2 are object
>                                       ^
>   types) if a pointer to T1 can be explicitly converted to the type
>   pointer T2 using const_cast. The result of a reference const_cast
>   refers to the original object.
> ---
> 
> Notice 'T2&' in the syntax.
> 
> the remaining of 5.2.11 doesn't mention any case where const_cast<T2>
> is allowed when T2 is class type.

Re: [C++ dayly bug report] const_cast to rvalue of class type

[Gabriel Dos_Reis]

Benjamin Scherrey <scherrey@switchco.com> writes:

| 	Yep, didn't notice the '&' there at first. I guess I can't disagree
| with your interpretation of the text. It does seem vauge in this area.

I find it quite clear. It unambiguously states what is permitted, how
the syntaxe should read and the semantics. Also that is not *my*
interpretation. This issue was raised up by Guillaume Laurent in
news:fr.comp.lang.c++ and diserved lengthy discussion involving James
Kanze. I should confess that at the fisrt place I thought the program
was well-formed until I read the relevant section of the Standard --
which is extremely clear. 

| ... I
| wonder why they didn't explicitly mention a limitation of only
| const_cast'ing pointers and references like they did for dynamic_cast if
| that was their intent.

They do by giving a detailled list of what is allowed and stating
explicitly:

---
  ... Conversions that can be performed explicitly using const_cast
  are listed below. No other conversion shall be performed explicitly
  using const_cast.
---

| ...  I still don't believe that it was their intent to
| limit the const_cast as you say at all. 

Can you give evidence to support your claims? Did you read 5.2.11/12?

| ... Can you tell me why this
| limitation would be meaningful? I don't see anything gained by it.

That is an interesting question. I wasn't yet on the committee when
the decision was made and can't report what were the pros. Anyway, you 
can still ask in comp.std.c++.

-- Gaby
>From craig@jcb-sc.com Mon May 03 06:50:00 1999
From: craig@jcb-sc.com
To: zack@rabi.columbia.edu
Cc: craig@jcb-sc.com
Subject: u77-test.f failures on some systems
Date: Mon, 03 May 1999 06:50:00 -0000
Message-id: <19990503134713.13294.qmail@deer>
References: <199905031305.JAA15550@blastula.phys.columbia.edu> <199905031305.JAA15550@blastula.phys.columbia.edu>
X-SW-Source: 1999-05/msg00028.html
Content-length: 901

>Running target unix
>FAIL: g77.f-torture/execute/u77-test.f execution,  -O0 
>FAIL: g77.f-torture/execute/u77-test.f execution,  -O1 
>FAIL: g77.f-torture/execute/u77-test.f execution,  -O2 
>FAIL: g77.f-torture/execute/u77-test.f execution,  -O2 -fomit-frame-pointer -finline-functions 
>FAIL: g77.f-torture/execute/u77-test.f execution,  -O2 -fomit-frame-pointer -finline-functions -funroll-loops 
>FAIL: g77.f-torture/execute/u77-test.f execution,  -O2 -fomit-frame-pointer -finline-functions -funroll-all-loops 
>FAIL: g77.f-torture/execute/u77-test.f execution,  -Os 

I probably bollixed something in my recent u77-test.f patches.  Could
someone debug the problem on this system, as well as on mips-sgi-irix6.5?
(Though, it might not be me; I added some new test code there, to test
some routines we'd left untested, so perhaps we're unearthing some
latent bugs here.)

        tq vm, (burley)
>From ronis@ronispc.chem.mcgill.ca Mon May 03 07:28:00 1999
From: David Ronis <ronis@ronispc.chem.mcgill.ca>
To: egcs-bugs@egcs.cygnus.com
Cc: craig@jcb-sc.com
Subject: testsuite results: egcs-2.93.21 19990502
Date: Mon, 03 May 1999 07:28:00 -0000
Message-id: <199905031428.KAA00512@ronispc.chem.mcgill.ca>
X-SW-Source: 1999-05/msg00029.html
Content-length: 8331

I built and ran the testsuite on my i586 (running linux-2.2.7).  Here
are the results (with the PASS, XFAIL, and UNSUPPORTED filtered out).
The last version had no fortran failures (now there is one) and all
the objc tests still fail to run.

David

--------------------------------------------------------------------------
Test Run By ronis on Sun May  2 15:15:48 1999
Native configuration is i586-pc-linux-gnulibc1

		=== g++ tests ===

Schedule of variations:
    unix

Running target unix
Running /home/ronis/project/egcs/gcc/testsuite/g++.dg/special/ecos.exp ...
FAIL: g++.dg/special/conpr-1.C execution test
FAIL: g++.dg/special/conpr-2.C execution test
FAIL: g++.dg/special/conpr-3.C execution test
FAIL: g++.dg/special/conpr-3.C execution test
Running /home/ronis/project/egcs/gcc/testsuite/g++.old-deja/old-deja.exp ...

FAIL: g++.brendan/eh1.C  Execution test
FAIL: g++.eh/cleanup1.C  Execution test
FAIL: g++.eh/flow1.C  Execution test
FAIL: g++.eh/new1.C  Execution test
FAIL: g++.eh/new2.C  Execution test
FAIL: g++.eh/pdel1.C  Execution test
FAIL: g++.eh/pdel2.C  Execution test
FAIL: g++.eh/ptr1.C  Execution test
FAIL: g++.eh/rethrow1.C  Execution test
FAIL: g++.eh/rethrow2.C  Execution test
FAIL: g++.eh/rethrow3.C  Execution test
FAIL: g++.eh/rethrow4.C  Execution test
FAIL: g++.eh/rethrow5.C  Execution test
FAIL: g++.eh/spec1.C  Execution test
FAIL: g++.eh/spec2.C  Execution test
FAIL: g++.eh/spec3.C  Execution test
FAIL: g++.eh/spec4.C  Execution test
FAIL: g++.eh/tmpl1.C  Execution test
FAIL: g++.eh/unwind1.C  Execution test
FAIL: g++.martin/new1.C  Execution test
FAIL: g++.mike/dyncast1.C  Execution test
FAIL: g++.mike/dyncast2.C  Execution test
FAIL: g++.mike/eh10.C  Execution test
FAIL: g++.mike/eh12.C  Execution test
FAIL: g++.mike/eh14.C  Execution test
FAIL: g++.mike/eh16.C  Execution test
FAIL: g++.mike/eh17.C  Execution test
FAIL: g++.mike/eh18.C  Execution test
FAIL: g++.mike/eh2.C  Execution test
FAIL: g++.mike/eh21.C  Execution test
FAIL: g++.mike/eh23.C  Execution test
FAIL: g++.mike/eh24.C  Execution test
FAIL: g++.mike/eh25.C  Execution test
FAIL: g++.mike/eh26.C  Execution test
FAIL: g++.mike/eh27.C  Execution test
FAIL: g++.mike/eh28.C  Execution test
FAIL: g++.mike/eh29.C  Execution test
FAIL: g++.mike/eh3.C  Execution test
FAIL: g++.mike/eh31.C  Execution test
FAIL: g++.mike/eh33.C  Execution test
FAIL: g++.mike/eh34.C  Execution test
FAIL: g++.mike/eh35.C  Execution test
FAIL: g++.mike/eh36.C  Execution test
FAIL: g++.mike/eh37.C  Execution test
FAIL: g++.mike/eh38.C  Execution test
FAIL: g++.mike/eh39.C  Execution test
FAIL: g++.mike/eh40.C  Execution test
FAIL: g++.mike/eh41.C  Execution test
FAIL: g++.mike/eh42.C  Execution test
FAIL: g++.mike/eh44.C  Execution test
FAIL: g++.mike/eh47.C  Execution test
FAIL: g++.mike/eh48.C  Execution test
FAIL: g++.mike/eh49.C  Execution test
FAIL: g++.mike/eh5.C  Execution test
FAIL: g++.mike/eh50.C  Execution test
FAIL: g++.mike/eh51.C  Execution test
FAIL: g++.mike/eh55.C  Execution test
FAIL: g++.mike/eh6.C  Execution test
FAIL: g++.mike/eh8.C  Execution test
FAIL: g++.mike/p7912.C  Execution test
FAIL: g++.mike/p9706.C  Execution test
FAIL: g++.other/array1.C  Execution test
FAIL: g++.other/init7.C  Execution test
FAIL: g++.other/singleton.C  Execution test
FAIL: g++.robertl/eb31.C  Execution test
FAIL: g++.robertl/eb50.C  Execution test
FAIL: g++.robertl/eb66.C  Execution test
FAIL: g++.robertl/eb88.C  Execution test

		=== g++ Summary ===

# of expected passes		5080
# of unexpected failures	72
# of expected failures		81
# of untested testcases		7
/home/ronis/project/objdir/gcc/testsuite/../xgcc version egcs-2.93.21 19990502 (gcc2 ss-980929 experimental)


Test Run By ronis on Sun May  2 15:42:09 1999
Native configuration is i586-pc-linux-gnulibc1

		=== g77 tests ===

Schedule of variations:
    unix

Running target unix
Running /home/ronis/project/egcs/gcc/testsuite/g77.f-torture/compile/compile.exp ...
FAIL: g77.f-torture/compile/19990502-0.f,  -O2  
Running /home/ronis/project/egcs/gcc/testsuite/g77.f-torture/execute/execute.exp ...
Running /home/ronis/project/egcs/gcc/testsuite/g77.f-torture/noncompile/noncompile.exp ...

		=== g77 Summary ===

# of expected passes		596
# of unexpected failures	1
/home/ronis/project/objdir/gcc/g77 g77 version egcs-2.93.21 19990502 (gcc2 ss-980929 experimental) (from FSF-g77 version 0.5.24-19990425)

Test Run By ronis on Sun May  2 14:37:50 1999
Native configuration is i586-pc-linux-gnulibc1

		=== gcc tests ===

Schedule of variations:
    unix

Running target unix
Running /home/ronis/project/egcs/gcc/testsuite/gcc.c-torture/code_quality/code_quality.exp ...
Running /home/ronis/project/egcs/gcc/testsuite/gcc.c-torture/compile/compile.exp ...
Running /home/ronis/project/egcs/gcc/testsuite/gcc.c-torture/execute/execute.exp ...
Running /home/ronis/project/egcs/gcc/testsuite/gcc.c-torture/execute/ieee/ieee.exp ...
FAIL: gcc.c-torture/execute/ieee/980619-1.c execution,  -O1 
FAIL: gcc.c-torture/execute/ieee/980619-1.c execution,  -O2 
FAIL: gcc.c-torture/execute/ieee/980619-1.c execution,  -O3 -fomit-frame-pointer 
FAIL: gcc.c-torture/execute/ieee/980619-1.c execution,  -O3 -fomit-frame-pointer -funroll-loops 
FAIL: gcc.c-torture/execute/ieee/980619-1.c execution,  -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions 
FAIL: gcc.c-torture/execute/ieee/980619-1.c execution,  -O3 -g 
FAIL: gcc.c-torture/execute/ieee/980619-1.c execution,  -Os 
Running /home/ronis/project/egcs/gcc/testsuite/gcc.c-torture/execute/memcheck/memcheck.exp ...
Running /home/ronis/project/egcs/gcc/testsuite/gcc.c-torture/noncompile/noncompile.exp ...
Running /home/ronis/project/egcs/gcc/testsuite/gcc.c-torture/special/special.exp ...
Running /home/ronis/project/egcs/gcc/testsuite/gcc.c-torture/unsorted/unsorted.exp ...
Running /home/ronis/project/egcs/gcc/testsuite/gcc.dg/dg.exp ...
FAIL: gcc.dg/990119-1.c execution test
Running /home/ronis/project/egcs/gcc/testsuite/gcc.dg/special/ecos.exp ...
FAIL: gcc.dg/special/weak-1.c execution test
Running /home/ronis/project/egcs/gcc/testsuite/gcc.failure/failure.exp ...
Running /home/ronis/project/egcs/gcc/testsuite/gcc.misc-tests/acker1.exp ...
Running /home/ronis/project/egcs/gcc/testsuite/gcc.misc-tests/dg-test.exp ...
Running /home/ronis/project/egcs/gcc/testsuite/gcc.misc-tests/dhry.exp ...
Running /home/ronis/project/egcs/gcc/testsuite/gcc.misc-tests/gcov.exp ...
Running /home/ronis/project/egcs/gcc/testsuite/gcc.misc-tests/matrix1.exp ...
Running /home/ronis/project/egcs/gcc/testsuite/gcc.misc-tests/mg.exp ...
Running /home/ronis/project/egcs/gcc/testsuite/gcc.misc-tests/msgs.exp ...
Running /home/ronis/project/egcs/gcc/testsuite/gcc.misc-tests/optbench.exp ...
Running /home/ronis/project/egcs/gcc/testsuite/gcc.misc-tests/sieve.exp ...
Running /home/ronis/project/egcs/gcc/testsuite/gcc.misc-tests/sort2.exp ...

		=== gcc Summary ===

# of expected passes		8092
# of unexpected failures	9
# of expected failures		31
# of unsupported tests		13
/home/ronis/project/objdir/gcc/xgcc version egcs-2.93.21 19990502 (gcc2 ss-980929 experimental)


Test Run By ronis on Sun May  2 15:47:31 1999
Native configuration is i586-pc-linux-gnulibc1

		=== objc tests ===

Schedule of variations:
    unix

Running target unix
Running /home/ronis/project/egcs/gcc/testsuite/objc/execute/execute.exp ...
FAIL: objc/execute/bf-1.m execution,  -O 
FAIL: objc/execute/bf-10.m execution,  -O 
FAIL: objc/execute/bf-11.m execution,  -O 
FAIL: objc/execute/bf-12.m execution,  -O 
FAIL: objc/execute/bf-13.m execution,  -O 
FAIL: objc/execute/bf-14.m execution,  -O 
FAIL: objc/execute/bf-15.m execution,  -O 
FAIL: objc/execute/bf-16.m execution,  -O 
FAIL: objc/execute/bf-17.m execution,  -O 
FAIL: objc/execute/bf-18.m execution,  -O 
FAIL: objc/execute/bf-19.m execution,  -O 
FAIL: objc/execute/bf-2.m execution,  -O 
FAIL: objc/execute/bf-3.m execution,  -O 
FAIL: objc/execute/bf-4.m execution,  -O 
FAIL: objc/execute/bf-5.m execution,  -O 
FAIL: objc/execute/bf-6.m execution,  -O 
FAIL: objc/execute/bf-7.m execution,  -O 
FAIL: objc/execute/bf-8.m execution,  -O 
FAIL: objc/execute/bf-9.m execution,  -O 

		=== objc Summary ===

# of expected passes		19
# of unexpected failures	19
/home/ronis/project/objdir/gcc/xgcc version egcs-2.93.21 19990502 (gcc2 ss-980929 experimental)

Re: [C++ dayly bug report] const_cast to rvalue of class type

[Benjamin Scherrey]

Gabriel Dos_Reis wrote:
> 
> Benjamin Scherrey <scherrey@switchco.com> writes:
> | ...  I still don't believe that it was their intent to
> | limit the const_cast as you say at all.
> 
> Can you give evidence to support your claims? Did you read 5.2.11/12?

	Huh? My evidence is that you made a claim and I expressed my opinion
that it was not their intent. I made an opinion, not a claim. Obviously
I read the relevant sections because I quoted parts of them to you.
 
> | ... Can you tell me why this
> | limitation would be meaningful? I don't see anything gained by it.
> 
> That is an interesting question. I wasn't yet on the committee when
> the decision was made and can't report what were the pros. Anyway, you
> can still ask in comp.std.c++.

	I'm getting the impression here that your interest is more in language
lawyering than in producing a usable and correct language standard. My
experience, thus far, is that when you find an issue in the written
standard that seems unusual, you can usually figure out why they came to
that position (either because of previously stated and remarkable well
met overriding language goals or they come out and tell you) or else it
is simply a mistake. Believe it or not, we've run across a couple.

	Now the issue we're dealing with here is one that seems rather obvious
at first glance. These are exactly the ones that get us in trouble! In
this case I'm trying to think of a reason for the limitation the text
seems to present and I am at a loss to uncover one other than there
isn't a lot of point in doing it because most uses will simply generate
a copy constructor call in which case its const'ness becomes irrelevant.
Given that, and the fact that the related language feature, dynamic_cast
(which has these expressed limitations) goes out of its way to state
this limitation (and justifiably so), I live under the impression (quite
possibly incorrectly) that the text is in error or just so really
unclear as to be indecipherable.

	Now you've come on this mailing list and made an apparently justified
assertion. You've also made a request that this "mistake" be corrected
in the compiler. In response, at least one other person as well as
myself (of which I doubt either of us will be involved coding the "fix")
have provided practical answers to your issue with the desire (which we
assume you share) to learn from and clarify this enormous document. As a
response you seen only willing to provide theoretical arguments and no
practical justification for your request.

	I suggest to you that this mailing list has a priority for practical
issues. There is a very long list of practical and large impact items
that the egcs developers must address before consideration is given to
minute standards compliance with no defined benefit. Therefore I
recommend that you take your question to comp.std.c++ yourself and see
if a practical justification can't be identified or, barring this
eventuality, that you submit the text as an error for the standards
committee to clarify. If a practical justification is found, please let
us know so it can be listed as an issue and put in its proper priority
on the things-to-do list.

	regards & later,

		Ben Scherrey

... who, after considering, debating, and berating this issue,
anticipates some compiler genius to provide the "but of course" reason
for said const_cast limitation! :-)
>From Prince_Tim_C@solarturbines.com Mon May 03 09:37:00 1999
From: Tim C Prince <Prince_Tim_C@solarturbines.com>
To: egcs-bugs@egcs.cygnus.com (IPM Return requested) (Receipt notification requested)
Subject: egcs-19990502 u77-test.f failure on Irix6.5
Date: Mon, 03 May 1999 09:37:00 -0000
Message-id: <372DD042.6E8C.2891.000*/c=US/admd=> </prmd=Cat/o=GWise/s=Prince/g=Tim/i=C/"@MHS>
X-SW-Source: 1999-05/msg00035.html
Content-length: 560

The libf2c function ctime_() is returning a date string of Dec.
31 1969 when called as a subroutine, and a null (or blank?)
string when called as a character function.  Attached is the result
of 'gcc -E ctime_.c'.  I was unable to persuade g77 to compile a
call to the Irix version of ctime() (available only as a function) for
comparison.

The remainder of the tests performed by g77 testsuite, including
the rest of u77-test, are passing.
Dr. Timothy C. Prince
Consulting Engineer
Solar Turbines, a Caterpillar Company
alternate e-mail: tprince@computer.org
>From drow@false.org Mon May 03 09:49:00 1999
From: Daniel Jacobowitz <drow@false.org>
To: egcs-bugs@egcs.cygnus.com
Subject: Re: Results for haifa-enabled egcs-2.93.21 19990502 (gcc2 ss-980929 experimental) testsuite on sparc-redhat-linux-gnu
Date: Mon, 03 May 1999 09:49:00 -0000
Message-id: <19990503124932.A25141@drow.res.cmu.edu>
References: <199905030309.XAA07828@pincoya.inf.utfsm.cl> <199905030309.XAA07828@pincoya.inf.utfsm.cl> <19990503032033.11734.qmail@deer> <4.2.0.37.19990503130054.009b0040@mail.lauterbach.com> <4.2.0.37.19990503130054.009b0040@mail.lauterbach.com>
X-SW-Source: 1999-05/msg00036.html
Content-length: 2214

On Mon, May 03, 1999 at 01:17:07PM +0200, Franz Sirl wrote:
> At 05:20 03.05.99 , craig@jcb-sc.com wrote:
> > >Running target unix
> > >FAIL: g77.f-torture/execute/u77-test.f execution,  -O0
> > >FAIL: g77.f-torture/execute/u77-test.f execution,  -O1
> > >FAIL: g77.f-torture/execute/u77-test.f execution,  -O2
> > >FAIL: g77.f-torture/execute/u77-test.f execution,  -O2 
> > -fomit-frame-pointer -finline-functions
> > >FAIL: g77.f-torture/execute/u77-test.f execution,  -O2 
> > -fomit-frame-pointer -finline-functions -funroll-loops
> > >FAIL: g77.f-torture/execute/u77-test.f execution,  -O2 
> > -fomit-frame-pointer -finline-functions -funroll-all-loops
> > >FAIL: g77.f-torture/execute/u77-test.f execution,  -Os
> >
> >Could someone debug these?  So far, people have been able to quickly
> >find the problem debugging u77-test.f on their systems (as it's
> >mainly about testing the interface to g77's portable libU77 library)....
> 
> Hmm, I think these might be something strange going on, cause ~2 weeks ago 
> Daniel Jacobowitz checked the mainline on a Debian based PPC system with 
> nearly the same CVS checkout as I did on a Redhat based PPC system. Our 
> systems should be fairly similar, that means a recent binutils 
> (gas-990418), kernel (2.2.x) and glibc (2.1.1pre1).
> At that time I thought this was due to Daniel configuring with 
> --enable-c-cpplib as he did before, but the testsuite output at 
> http://egcs.cygnus.com/ml/egcs-testresults/1999-04/msg00078.html doesn't 
> show any hint of --enable-c-cpplib. My results are in 
> http://egcs.cygnus.com/ml/egcs-testresults/1999-04/msg00082.html .
> 
> Daniel, could you rerun your tests with a fresh CVS checkout from today?

Well, my suspicion here would be binutils.  I believe I'm still using
2.9.1.0.19a; I had nowhere near the number of problems with it that you
did.


Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|     CMU, CS class of 2002      |
|   Debian GNU/Linux Developer    __   Part-Time Systems Programmer  |
|         dan@debian.org         |  |        drow@cs.cmu.edu         |
\--------------------------------/  \--------------------------------/
>From Gabriel.Dos_Reis@sophia.inria.fr Mon May 03 10:08:00 1999
From: Gabriel Dos_Reis <Gabriel.Dos_Reis@sophia.inria.fr>
To: scherrey@proteus-tech.com
Cc: Gabriel Dos_Reis <Gabriel.Dos_Reis@sophia.inria.fr>, egcs-bugs@egcs.cygnus.com, egcs@egcs.cygnus.com, Guillaume Laurent <glaurent@worldnet.fr>
Subject: Re: [C++ dayly bug report] const_cast to rvalue of class type
Date: Mon, 03 May 1999 10:08:00 -0000
Message-id: <xajd80i5bf1.fsf@korrigan.inria.fr>
References: <xajyajbkl30.fsf@korrigan.inria.fr> <37291A17.754FEA25@switchco.com> <xajpv4mltfn.fsf@korrigan.inria.fr> <37292D46.1D891CB7@switchco.com> <xajd80mlqti.fsf@korrigan.inria.fr> <372AA7F0.84F4BDFA@switchco.com> <xajlnf65uqf.fsf@korrigan.inria.fr> <372DDC5D.2C6B1221@switchco.com>
X-SW-Source: 1999-05/msg00037.html
Content-length: 3950

Benjamin Scherrey <scherrey@switchco.com> writes:


[...]

| > | ... Can you tell me why this
| > | limitation would be meaningful? I don't see anything gained by it.
| > 
| > That is an interesting question. I wasn't yet on the committee when
| > the decision was made and can't report what were the pros. Anyway, you
| > can still ask in comp.std.c++.
| 
| 	I'm getting the impression here that your interest is more in language
| lawyering than in producing a usable and correct language standard.

Actually your impression is wrong. 

| ...  My
| experience, thus far, is that when you find an issue in the written
| standard that seems unusual, you can usually figure out why they came to
| that position (either because of previously stated and remarkable well
| met overriding language goals or they come out and tell you) or else it
| is simply a mistake. Believe it or not, we've run across a couple.

Well, I've suggested that your ask your ask about the 'rationale'
behind const_cast ono comp.std.c++, because at the first place that
newsgroup is the right place to ask such a question. I do beleive that 
this list is about practical questions related to implementations of
the various standards EGCS attempts to implement, including C++; I
don't beleive this is the right place to discuss rationale behing
allowinf or fordiding something in C++. Nor do I beleive this is the
right place to start flames.

| 
| 	Now the issue we're dealing with here is one that seems rather obvious
| at first glance. These are exactly the ones that get us in trouble! In
| this case I'm trying to think of a reason for the limitation the text
| seems to present and I am at a loss to uncover one other than there
| isn't a lot of point in doing it because most uses will simply generate
| a copy constructor call in which case its const'ness becomes irrelevant.
| Given that, and the fact that the related language feature, dynamic_cast
| (which has these expressed limitations) goes out of its way to state
| this limitation (and justifiably so), I live under the impression (quite
| possibly incorrectly) that the text is in error or just so really
| unclear as to be indecipherable.
| 
| 	Now you've come on this mailing list and made an apparently justified
| assertion. You've also made a request that this "mistake" be corrected
| in the compiler. In response, at least one other person as well as
| myself (of which I doubt either of us will be involved coding the "fix")
| have provided practical answers to your issue with the desire (which we
| assume you share) to learn from and clarify this enormous document. As a
| response you seen only willing to provide theoretical arguments and no
| practical justification for your request.

The answers I provided weren't theorical. Beleive it or not. On this
list my primarily goal is to contribbute to a usable compiler,
reasonably conformant. The bug I reported was already reported a while 
ago and wasn't fixed. It just happened several people --pratical
programmers for that matter--  who are annoyed by that bug asked me
for a fix. Martin and Mark recognized the bug and Mark provided a
fix.

| 	I suggest to you that this mailing list has a priority for practical
| issues. There is a very long list of practical and large impact items
| that the egcs developers must address before consideration is given to
| minute standards compliance with no defined benefit. Therefore I
| recommend that you take your question to comp.std.c++ yourself and see
| if a practical justification can't be identified or, barring this
| eventuality, that you submit the text as an error for the standards
| committee to clarify. If a practical justification is found, please let
| us know so it can be listed as an issue and put in its proper priority
| on the things-to-do list.

I will ignore this gratituous flame and direct you to libstdc++ in
case you doubt my *pratical* involvement on EGCS. 

-- Gaby
>From zack@rabi.columbia.edu Mon May 03 10:13:00 1999
From: Zack Weinberg <zack@rabi.columbia.edu>
To: Tim C Prince <Prince_Tim_C@solarturbines.com>
Cc: craig@jcb-sc.com, egcs-bugs@egcs.cygnus.com
Subject: Re: egcs-19990502 u77-test.f failure on Irix6.5 
Date: Mon, 03 May 1999 10:13:00 -0000
Message-id: <199905031712.NAA13324@blastula.phys.columbia.edu>
References: <372DD042.6E8C.2891.000*/c=US/admd=> </prmd=Cat/o=GWise/s=Prince/g=Tim/i=C/"@MHS>
X-SW-Source: 1999-05/msg00038.html
Content-length: 1996

On 03 May 1999 09:34:00 Z, Tim C Prince wrote:
>
>The libf2c function ctime_() is returning a date string of Dec.
>31 1969 when called as a subroutine, and a null (or blank?)
>string when called as a character function.  Attached is the result
>of 'gcc -E ctime_.c'.  I was unable to persuade g77 to compile a
>call to the Irix version of ctime() (available only as a function) for
>comparison.

The test failures on Solaris are very similar but not the same: when
called as a subroutine ctime_() returns Dec 31 1969; when called as a
character function ctime_() returns the correct result.  All the other
tests pass.  This is a very old bug - I can reproduce it with g77
1.1.0 and the corresponding libf2c.

Small test case:

      implicit none
      intrinsic time, ctime
      integer i
      character ctim*25, ctim2*25

      i = time ()
      ctim = ctime (i)
      call ctime (ctim2, i)

      print *, 'CTIME()    = ', ctim
      print *, 'CALL CTIME = ', ctim2
      if (ctim .ne. ctim2) then
         print *, 'CTIME() disagrees with CALL CTIME'
      end if

      end

and an assembly dump (-O2):

MAIN__:
        !#PROLOGUE# 0
        save %sp,-216,%sp
        !#PROLOGUE# 1
        call G77_time_0,0
        nop
        mov %o0,%l0
        mov %o1,%l1
        mov %l1,%o3
        sra %l1,31,%o2
        add %fp,-104,%l2
        std %o2,[%fp-112]
        add %fp,-48,%l3
        mov %l2,%o0
        mov 24,%o1
        call G77_ctime_0,0
        add %fp,-112,%o2
        mov %l2,%o1
        mov %l3,%o0
        mov 25,%o2
        call s_copy,0
        mov 24,%o3
        add %fp,-80,%l2
        st %l1,[%fp-116]
        mov %l2,%o0
        mov 25,%o1
        call G77_ctime_0,0

I am not a Sparc assembly expert, but the pointer arithmetic looks
very suspicious to me.  If it does what I think it does, we are
handing G77_ctime_0 zero for its `xstime' parameter when invoked as a
subroutine.

It also looks like we missed an optimization; that s_copy call should
be unnecessary.

zw
>From craig@jcb-sc.com Mon May 03 10:52:00 1999
From: craig@jcb-sc.com
To: zack@rabi.columbia.edu
Cc: craig@jcb-sc.com
Subject: Re: egcs-19990502 u77-test.f failure on Irix6.5
Date: Mon, 03 May 1999 10:52:00 -0000
Message-id: <19990503174817.22271.qmail@deer>
References: <199905031712.NAA13324@blastula.phys.columbia.edu> <199905031712.NAA13324@blastula.phys.columbia.edu>
X-SW-Source: 1999-05/msg00040.html
Content-length: 250

Thanks for the info on ctime_ -- I can't look into it right now,
but am pretty sure y'all have sent me enough info to find and fix
the bug myself!  Though, any further info you come across, please
feel free to send it along.

        tq vm, (burley)
>From craig@jcb-sc.com Mon May 03 10:52:00 1999
From: craig@jcb-sc.com
To: zack@rabi.columbia.edu
Cc: craig@jcb-sc.com
Subject: Re: egcs-19990502 u77-test.f failure on Irix6.5
Date: Mon, 03 May 1999 10:52:00 -0000
Message-id: <19990503174921.22285.qmail@deer>
References: <199905031712.NAA13324@blastula.phys.columbia.edu> <199905031712.NAA13324@blastula.phys.columbia.edu>
X-SW-Source: 1999-05/msg00039.html
Content-length: 330

>It also looks like we missed an optimization; that s_copy call should
>be unnecessary.

BTW, eliminating these copies is on the list of optimizations to add
to g77 someday.  Though, not very high -- I get the impression nobody
really cares a lot about the performance of CHARACTER operations in
Fortran.

        tq vm, (burley)
>From Prince_Tim_C@solarturbines.com Mon May 03 10:54:00 1999
From: Tim C Prince <Prince_Tim_C@solarturbines.com>
To: Prince_Tim_C@solarturbines.com (IPM Return requested) (Receipt notification requested), zack@rabi.columbia.edu (IPM Return requested) (Receipt notification requested)
Cc: craig@jcb-sc.com (IPM Return requested) (Receipt notification requested), egcs-bugs@egcs.cygnus.com (IPM Return requested) (Receipt notification requested)
Subject: Re: egcs-19990502 u77-test.f failure on Irix6.5  -Reply
Date: Mon, 03 May 1999 10:54:00 -0000
Message-id: <372DE213.6E8C.29A1.000*/c=US/admd=> </prmd=Cat/o=GWise/s=Prince/g=Tim/i=C/"@MHS>
X-SW-Source: 1999-05/msg00041.html
Content-length: 1096

Your test program produces the correct result on Irix6.5 when
called as a character function, and a date of May 10 1978 when
called as a subroutine.

I have attached the corresponding fragment of .s file, but won't
display ignorance by commenting on it.

>>
The test failures on Solaris are very similar but not the same:
when
called as a subroutine ctime_() returns Dec 31 1969; when
called as a
character function ctime_() returns the correct result.  All the
other
tests pass.  This is a very old bug - I can reproduce it with g77
1.1.0 and the corresponding libf2c.

Small test case:

      implicit none
      intrinsic time, ctime
      integer i
      character ctim*25, ctim2*25

      i = time ()
      ctim = ctime (i)
      call ctime (ctim2, i)

      print *, 'CTIME()    = ', ctim
      print *, 'CALL CTIME = ', ctim2
      if (ctim .ne. ctim2) then
         print *, 'CTIME() disagrees with CALL CTIME'
      end if

      end

and an assembly dump (-O2):


zw
Dr. Timothy C. Prince
Consulting Engineer
Solar Turbines, a Caterpillar Company
alternate e-mail: tprince@computer.org
>From mjacob@feral.com Mon May 03 11:52:00 1999
From: Matthew Jacob <mjacob@feral.com>
To: egcs-bugs@cygnus.com
Subject: Re: bin/11464: union copies likely broken for alpha egcs-2.91.6619990314 (fwd)
Date: Mon, 03 May 1999 11:52:00 -0000
Message-id: <Pine.LNX.4.04.9905031151480.7852-100000@feral.com>
X-SW-Source: 1999-05/msg00042.html
Content-length: 625

FreeBSD egcs bug that I worked around- maybe of interest to you.


---------- Forwarded message ----------
Date: Mon, 3 May 1999 06:50:01 -0700 (PDT)
From: gnats-admin@FreeBSD.org
To: mjacob@FreeBSD.org
Subject: Re: bin/11464: union copies likely broken for alpha egcs-2.91.66
    19990314

Thank you very much for your problem report.
It has the internal identification `bin/11464'.
The individual assigned to look at your
report is: freebsd-bugs. 

>Category:       bin
>Responsible:    freebsd-bugs
>Synopsis:       union copies likely broken for alpha egcs-2.91.66 19990314
>Arrival-Date:   Mon May  3 06:50:00 PDT 1999

Re: [C++ dayly bug report] const_cast to rvalue of class type

[Gabriel Dos_Reis]

Benjamin Scherrey <scherrey@switchco.com> writes:


[...]

| > | ... Can you tell me why this
| > | limitation would be meaningful? I don't see anything gained by it.
| > 
| > That is an interesting question. I wasn't yet on the committee when
| > the decision was made and can't report what were the pros. Anyway, you
| > can still ask in comp.std.c++.
| 
| 	I'm getting the impression here that your interest is more in language
| lawyering than in producing a usable and correct language standard.

Actually your impression is wrong. 

| ...  My
| experience, thus far, is that when you find an issue in the written
| standard that seems unusual, you can usually figure out why they came to
| that position (either because of previously stated and remarkable well
| met overriding language goals or they come out and tell you) or else it
| is simply a mistake. Believe it or not, we've run across a couple.

Well, I've suggested that your ask your ask about the 'rationale'
behind const_cast ono comp.std.c++, because at the first place that
newsgroup is the right place to ask such a question. I do beleive that 
this list is about practical questions related to implementations of
the various standards EGCS attempts to implement, including C++; I
don't beleive this is the right place to discuss rationale behing
allowinf or fordiding something in C++. Nor do I beleive this is the
right place to start flames.

| 
| 	Now the issue we're dealing with here is one that seems rather obvious
| at first glance. These are exactly the ones that get us in trouble! In
| this case I'm trying to think of a reason for the limitation the text
| seems to present and I am at a loss to uncover one other than there
| isn't a lot of point in doing it because most uses will simply generate
| a copy constructor call in which case its const'ness becomes irrelevant.
| Given that, and the fact that the related language feature, dynamic_cast
| (which has these expressed limitations) goes out of its way to state
| this limitation (and justifiably so), I live under the impression (quite
| possibly incorrectly) that the text is in error or just so really
| unclear as to be indecipherable.
| 
| 	Now you've come on this mailing list and made an apparently justified
| assertion. You've also made a request that this "mistake" be corrected
| in the compiler. In response, at least one other person as well as
| myself (of which I doubt either of us will be involved coding the "fix")
| have provided practical answers to your issue with the desire (which we
| assume you share) to learn from and clarify this enormous document. As a
| response you seen only willing to provide theoretical arguments and no
| practical justification for your request.

The answers I provided weren't theorical. Beleive it or not. On this
list my primarily goal is to contribbute to a usable compiler,
reasonably conformant. The bug I reported was already reported a while 
ago and wasn't fixed. It just happened several people --pratical
programmers for that matter--  who are annoyed by that bug asked me
for a fix. Martin and Mark recognized the bug and Mark provided a
fix.

| 	I suggest to you that this mailing list has a priority for practical
| issues. There is a very long list of practical and large impact items
| that the egcs developers must address before consideration is given to
| minute standards compliance with no defined benefit. Therefore I
| recommend that you take your question to comp.std.c++ yourself and see
| if a practical justification can't be identified or, barring this
| eventuality, that you submit the text as an error for the standards
| committee to clarify. If a practical justification is found, please let
| us know so it can be listed as an issue and put in its proper priority
| on the things-to-do list.

I will ignore this gratituous flame and direct you to libstdc++ in
case you doubt my *pratical* involvement on EGCS. 

-- Gaby

Re: [C++ dayly bug report] const_cast to rvalue of class type

[Gabriel Dos_Reis]

patrick <patrick@mail.boxsoft.com> writes:

| Sometime in the late 1900s it was said:
| 
| OK.  I may be in the dark here too.  But afaik const_cast<T>( t )
| will cast t to T exactly as  (T)t  would have iff T and the type
| of t are different either in 'const' and 'volatile'.  At least that
| is what Bjarne Stroustrup confirms (as I paraphrased from his book).

Exact citation please.

| Am I wrong?

Please check 5.2.11/*. Your assertion is valid only iff T is a reference
type or a pointer type, as I said earlier.

-- Gaby