optimization/8300: [3.2/3.3/3.4 regression] [sparc] ICE in gen_reg_rtx, at emit-rtl.c:662

[Robert Schiele]

The following reply was made to PR optimization/8300; it has been noted by GNATS.

From: Robert Schiele <rschiele@uni-mannheim.de>
To: Falk Hueffner <falk.hueffner@student.uni-tuebingen.de>
Cc: Richard Henderson <rth@redhat.com>, gcc-bugs@gcc.gnu.org,
   tneumann@pi3.informatik.uni-mannheim.de, gcc-gnats@gcc.gnu.org
Subject: Re: optimization/8300: [3.2/3.3/3.4 regression] [sparc] ICE in gen_reg_rtx, at emit-rtl.c:662
Date: Mon, 17 Mar 2003 16:48:25 +0100

 --PEIAKu/WMn1b1Hv9
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Mon, Mar 17, 2003 at 04:24:34PM +0100, Falk Hueffner wrote:
 > Robert Schiele <rschiele@uni-mannheim.de> writes:
 >=20
 > > How about this:
 > >=20
 > > void a() {
 > >     double b;
 > >     int c[2];
 > >     *((int*)&b) && (c[1] =3D 0);
 > > }
 > >=20
 > > Exactly same problem.  And this time there is no pointer outside well
 > > defined data area.  You agree that this sample is legal code?
 >=20
 > No, you're violating the rule in 6.5.7 by accessing an object of type
 > double with an lvalue of type int.
 
 6.5.7?  This one is about bitwise shift operators in
 	ISO/IEC 9899:1999.  There is no bitwise shift operator in my
 	expression.
 
 lvalue?  b is not used as an lvalue here, is it?
 
 Is it generally illegal to do a cast of this type?
 
 Is it just illegal, because double has 8 bytes, where int has 4 on
 this platform?  In that case change double to float which has also 4
 byte. =3D=3D> Same problem.
 
 I can't find such a limitation in 6.5.4 Cast operators.  Is there such
 a limit somewhere?
 
 Additional note: The code compiles fine when the declaration of b has
 a volatile qualifier.
 
 Robert
 
 --=20
 Robert Schiele			Tel.: +49-621-181-2517
 Dipl.-Wirtsch.informatiker	mailto:rschiele@uni-mannheim.de
 
 --PEIAKu/WMn1b1Hv9
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.0.7 (GNU/Linux)
 
 iQEVAwUBPnXuScQAnns5HcHpAQEOlggAz3PNNvUN+upats7yokEexgC30Zbg26bi
 T/M1xyHh7PkJPVp/m5qfiq6nMeWKlnW+c9croP5cNWcogALL4cL0Rqcyzkm8M8rs
 rfAa07zh0+GNEDrtFOjefJgq/KkfX368nFeOb6aEeVm2WScm3C0q2O9B2ZAlJx5k
 K+/FyVabaFGwDJ460LxBIgJVE4YVIPLRNJWjYE+0nGgopUoQi/z1osU+i7EJ6Z1c
 RF/a1TyVt6FoUgzE3xdzvTLPWsQSrBAedWjVSHVKJoRvpvzhX5ELrDBdrnl3KquY
 ytxxHR30ESrFqW9sf+DXOE/4JEg8vlAswa5RB0ln0ScaidGEG3bo2A==
 =4Vju
 -----END PGP SIGNATURE-----
 
 --PEIAKu/WMn1b1Hv9--