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

Re: 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: Richard Henderson <rth@redhat.com>, rth@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
   gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org,
   tneumann@pi3.informatik.uni-mannheim.de, gcc-gnats@gcc.gnu.org
Cc:  
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 10:25:04 +0100

 --AqsLC8rIMeq19msA
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Mon, Mar 17, 2003 at 01:05:55AM -0800, Richard Henderson wrote:
 > On Mon, Mar 17, 2003 at 06:08:21AM +0100, Robert Schiele wrote:
 > > *(&c + 1) is also well defined.
 >=20
 > How's that?
 
 It's pointer arithmetic:
 
 Assume you have the following memory layout...
 
 |   |
 +---+
 |   | <=3D=3D ... then the contents of that address is *(&c + 1)
 +---+
 | c |
 +---+
 |   |
 
 It is:
 
 c: The contents of the variable c on the stack.
 
 &c: The address where c is located on the stack.
 
 &c + 1: That address plus 4 byte. (sizeof(int) =3D=3D 4 on sparc)
 
 *(&c + 1): The contents of the above address.
 
 > > 1. My rewritten example is legal code with no doubt and produces an
 > >    ICE whit optimization.
 >=20
 > Nyet.
 
 Well, I still don't see why this is illegal. Can you give me the
 paragraph of the C standard that prohibits this sort of pointer
 arithmetic?
 
 Robert
 
 --=20
 Robert Schiele			Tel.: +49-621-181-2517
 Dipl.-Wirtsch.informatiker	mailto:rschiele@uni-mannheim.de
 
 --AqsLC8rIMeq19msA
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.0.7 (GNU/Linux)
 
 iQEVAwUBPnWUcMQAnns5HcHpAQGdKggAlK9ZV4OgrAY+7UCvuoO7BbUg6PgbHhXQ
 02LxCX3fN5FXsyvj5nVfD8ZbwK42rh6w95hb0XloKZwQMM7+izJala5SEOgghyUN
 l3Wlr7f30yJOudPHFanqBtyfOuQJP9gWBfFIssIDtdAOx+ZpBxb8XGbpex5EAPWG
 T5/DBchE6zrM46R7XCBdRurZ2PFTh6E9k7dJwfjOh+h5O0R6Npvv3NLHuvdfHfJk
 vCfyZgRM8K96KmOzmetAytCsU01aD/6UsGOPhntnlqpOfysC87aPAJ9Zam6wCmMr
 pq8hzQa7hdaVVUjnZbltLMQ/XY1/mHft6S1C95eekY5EPtFVEzCO1w==
 =0Vp8
 -----END PGP SIGNATURE-----
 
 --AqsLC8rIMeq19msA--
 

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

[rth]

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

Responsible-Changed-From-To: ebotcazou->rth
Responsible-Changed-By: rth
Responsible-Changed-When: Thu Apr 24 04:23:20 2003
Responsible-Changed-Why:
    .
State-Changed-From-To: analyzed->closed
State-Changed-By: rth
State-Changed-When: Thu Apr 24 04:23:20 2003
State-Changed-Why:
    http://gcc.gnu.org/ml/gcc-patches/2003-04/msg01848.html

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8300

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

[ebotcazou]

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

Responsible-Changed-From-To: unassigned->ebotcazou
Responsible-Changed-By: ebotcazou
Responsible-Changed-When: Tue Mar 18 20:29:14 2003
Responsible-Changed-Why:
    The testcase may be illegal but there is nonetheless a real
    problem behind the ICE (see PR target/10113). Investigating.
    

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8300

Re: 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 18:09:29 +0100

 --2oS5YaxWCcQjTEyO
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Mon, Mar 17, 2003 at 05:59:25PM +0100, Falk Hueffner wrote:
 > Robert Schiele <rschiele@uni-mannheim.de> writes:
 >=20
 > > On Mon, Mar 17, 2003 at 04:24:34PM +0100, Falk Hueffner wrote:
 > > > Robert Schiele <rschiele@uni-mannheim.de> writes:
 > > >=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 we=
 ll
 > > > > 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.
 > >=20
 > > 6.5.7?  This one is about bitwise shift operators
 >=20
 > Sorry, I meant 6.5, paragraph 7.
 
 Thanks again.  Got it now.  I am convinced that this is illegal code.
 
 Robert
 
 --=20
 Robert Schiele			Tel.: +49-621-181-2517
 Dipl.-Wirtsch.informatiker	mailto:rschiele@uni-mannheim.de
 
 --2oS5YaxWCcQjTEyO
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.0.7 (GNU/Linux)
 
 iQEVAwUBPnYBSMQAnns5HcHpAQH2xgf/eQ1jP0Gd+FTLKrueFBqvDvdVCInCy3sr
 qox+kHuMy75637MQ/eTeYiUK7rvzZ3Cn2Oj5JJu3Rln+4ioe8zi/XgmONMQy9Ab5
 Udgre7OYEVTS2YPK8S9KbgiCOkxJmvNAA2lwED3bzTbEncHxhYX7cOgJLxGhFqgp
 9kjuHhf9CVXj8FmLoOOinbUcx623oV1cgMBJ9XiL7PpiqYgXG1gSpOZFz2FJJ2Em
 nSuBLNeuA9uPDetJOTz0E/uscWXPsavoPMzZj9pj9ycLYNvMDK0DSGAsuRiMcgii
 fBFRF8Ow5xafER28j/5KwoOxVYnTlt0Zv8D08Jo1EznCRx/0PkAYig==
 =W5D3
 -----END PGP SIGNATURE-----
 
 --2oS5YaxWCcQjTEyO--
 

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

[Falk Hueffner]

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

From: Falk Hueffner <falk.hueffner@student.uni-tuebingen.de>
To: Robert Schiele <rschiele@uni-mannheim.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: 17 Mar 2003 17:59:25 +0100

 Robert Schiele <rschiele@uni-mannheim.de> writes:
 
 > On Mon, Mar 17, 2003 at 04:24:34PM +0100, Falk Hueffner wrote:
 > > Robert Schiele <rschiele@uni-mannheim.de> writes:
 > > 
 > > > void a() {
 > > >     double b;
 > > >     int c[2];
 > > >     *((int*)&b) && (c[1] = 0);
 > > > }
 > > > 
 > > > Exactly same problem.  And this time there is no pointer outside well
 > > > defined data area.  You agree that this sample is legal code?
 > > 
 > > 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
 
 Sorry, I meant 6.5, paragraph 7.
 
 > lvalue?  b is not used as an lvalue here, is it?
 
 No, but you're accessing its value.
  
 > Is it generally illegal to do a cast of this type?
 
 No, only accessing the resulting object.
 
 -- 
 	Falk

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

[Joseph S. Myers]

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

From: "Joseph S. Myers" <jsm28@cam.ac.uk>
To: Robert Schiele <rschiele@uni-mannheim.de>
Cc: Andreas Schwab <schwab@suse.de>, 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:53:31 +0000 (GMT)

 On Mon, 17 Mar 2003, Robert Schiele wrote:
 
 > My point, as far as I understand this situation, is that the compiler
 > should generate a binary out of it.  The resulting code is completely
 > braindead --- I know that --- and may even SIGBUS or whatever he likes
 > to do at _runtime_, but I don't see, why this should be seen as
 > illegal at _compile_ time.
 
 Yes.  There is existing precedent (va_arg with bad types) for generating
 an abort for code that provably generates undefined behaviour if ever
 executed, but is OK if never executed.
 
 -- 
 Joseph S. Myers
 jsm28@cam.ac.uk
 

Re: 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: Andreas Schwab <schwab@suse.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 17:21:09 +0100

 --zYM0uCDKw75PZbzx
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Mon, Mar 17, 2003 at 04:34:38PM +0100, Andreas Schwab wrote:
 > Ignoring the missing initialisation of b this is undefined under the
 > aliasing rules.
 
 Ok, behaviour is undefined.  As this is only a sample to produce an
 ICE, this is no problem for me.
 
 But do you think this code is illegal in the sense that the compiler
 cannot generate valid code out of it?  In that case I would be happy
 about a pointer to the specs that tell me that this is not allowed.
 
 Does any spec _force_ me to initialize b?  When I do so, the error is
 vanished.  Again, I don't care about undefined behaviour here.  This
 is also the reason, why I omitted the initialization.
 
 My point, as far as I understand this situation, is that the compiler
 should generate a binary out of it.  The resulting code is completely
 braindead --- I know that --- and may even SIGBUS or whatever he likes
 to do at _runtime_, but I don't see, why this should be seen as
 illegal at _compile_ time.
 
 Robert
 
 --=20
 Robert Schiele			Tel.: +49-621-181-2517
 Dipl.-Wirtsch.informatiker	mailto:rschiele@uni-mannheim.de
 
 --zYM0uCDKw75PZbzx
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.0.7 (GNU/Linux)
 
 iQEVAwUBPnX19cQAnns5HcHpAQE0eQf+OwHgQFADbOzdB+JUVaoaEijwNmsBWOQJ
 anM6xWORACaUSerUBJCb+Ox3jCnU1Yq8r9+a4uvZtZGkkMMVocazUsjzia929FJE
 Y1tO43j1/eEnP5H90w2zIN1XoA14WdG+4PtohkFd1xJ0BorbpcYBQrTMG1rdkZ7n
 xkYwaKtIGLxXYrjuG1MVafR44OyryOqbBkhLGwkqpBmVMUeoYAAmXLCY574dwR3d
 Y6Gblg4ztu7958XNdUqPMhlFL/6Ik6jih1foG80OcEX3gM/VuAdGVOBrT11i4oIw
 jhPAWXqBjjRYCiRpp0FuznB5jIoxKdvm5etjMo0sHmpTMQGaI2jRhg==
 =tUq4
 -----END PGP SIGNATURE-----
 
 --zYM0uCDKw75PZbzx--
 

Re: 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--
 

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

[Andreas Schwab]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1420 bytes --]

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

From: Andreas Schwab <schwab@suse.de>
To: Robert Schiele <rschiele@uni-mannheim.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:34:38 +0100

 Robert Schiele <rschiele@uni-mannheim.de> writes:
 
 |> On Mon, Mar 17, 2003 at 09:29:37AM -0500, Daniel Jacobowitz wrote:
 |> > If you have a copy of the standard, it's 6.5.6#8.  Once a pointer is
 |> > adjusted to point outside of the original object it must not be
 |> > dereferenced.  Accessing memory in this way produces undefined
 |> > behavior.
 |> 
 |> Ok thanks, found it there.
 |> 
 |> How about this:
 |> 
 |> void a() {
 |>     double b;
 |>     int c[2];
 |>     *((int*)&b) && (c[1] = 0);
 |> }
 |> 
 |> Exactly same problem.  And this time there is no pointer outside well
 |> defined data area.  You agree that this sample is legal code?
 
 Ignoring the missing initialisation of b this is undefined under the
 aliasing rules.
 
 Andreas.
 
 -- 
 Andreas Schwab, SuSE Labs, schwab@suse.de
 SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
 Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
 "And now for something completely different."

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

[Falk Hueffner]

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

From: Falk Hueffner <falk.hueffner@student.uni-tuebingen.de>
To: Robert Schiele <rschiele@uni-mannheim.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: 17 Mar 2003 16:24:34 +0100

 Robert Schiele <rschiele@uni-mannheim.de> writes:
 
 > How about this:
 > 
 > void a() {
 >     double b;
 >     int c[2];
 >     *((int*)&b) && (c[1] = 0);
 > }
 > 
 > Exactly same problem.  And this time there is no pointer outside well
 > defined data area.  You agree that this sample is legal code?
 
 No, you're violating the rule in 6.5.7 by accessing an object of type
 double with an lvalue of type int.
 
 -- 
 	Falk

Re: 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: Richard Henderson <rth@redhat.com>, gcc-bugs@gcc.gnu.org,
   tneumann@pi3.informatik.uni-mannheim.de, gcc-gnats@gcc.gnu.org
Cc:  
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:17:18 +0100

 --liOOAslEiF7prFVr
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Mon, Mar 17, 2003 at 09:29:37AM -0500, Daniel Jacobowitz wrote:
 > If you have a copy of the standard, it's 6.5.6#8.  Once a pointer is
 > adjusted to point outside of the original object it must not be
 > dereferenced.  Accessing memory in this way produces undefined
 > behavior.
 
 Ok thanks, found it there.
 
 How about this:
 
 void a() {
     double b;
     int c[2];
     *((int*)&b) && (c[1] =3D 0);
 }
 
 Exactly same problem.  And this time there is no pointer outside well
 defined data area.  You agree that this sample is legal code?
 
 Robert
 
 --=20
 Robert Schiele			Tel.: +49-621-181-2517
 Dipl.-Wirtsch.informatiker	mailto:rschiele@uni-mannheim.de
 
 --liOOAslEiF7prFVr
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.0.7 (GNU/Linux)
 
 iQEVAwUBPnXm/cQAnns5HcHpAQGZywf/Vy/TU4q8OI4qlxXhgLogQ8aGaUakYJJM
 jnMQxupTWJjpR5E9l99eIXr+ejp5y9A2gwShblL48GacJq1TB8nAm2XcoUMA/Qec
 crdkpUQ4NnVEE/zlJX4MCDwWRlp67JAyr9+FE6KfXZPWnID+/cO72gfW305hIJii
 G96Cb8bZ/9hQ5mei3+LByfKA4yOmsSU5vy5eZF9+fdx+lbIVGghGGw1XApM+kKoV
 lUFUrXR7CZNoT+Urcq/NpRU6e515WichCbG1E/KRTwgUzJkGXWjUFULcUBTiHoBN
 0PEzggEupJBGFruk88APt2telHYka8mczsy2tcwFFTSowxVNwp9XJw==
 =3Elq
 -----END PGP SIGNATURE-----
 
 --liOOAslEiF7prFVr--
 

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

[Daniel Jacobowitz]

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

From: Daniel Jacobowitz <drow@mvista.com>
To: Robert Schiele <rschiele@uni-mannheim.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 09:29:37 -0500

 On Mon, Mar 17, 2003 at 10:25:04AM +0100, Robert Schiele wrote:
 > On Mon, Mar 17, 2003 at 01:05:55AM -0800, Richard Henderson wrote:
 > > On Mon, Mar 17, 2003 at 06:08:21AM +0100, Robert Schiele wrote:
 > > > *(&c + 1) is also well defined.
 > > 
 > > How's that?
 > 
 > It's pointer arithmetic:
 > 
 > Assume you have the following memory layout...
 > 
 > |   |
 > +---+
 > |   | <== ... then the contents of that address is *(&c + 1)
 > +---+
 > | c |
 > +---+
 > |   |
 > 
 > It is:
 > 
 > c: The contents of the variable c on the stack.
 > 
 > &c: The address where c is located on the stack.
 > 
 > &c + 1: That address plus 4 byte. (sizeof(int) == 4 on sparc)
 > 
 > *(&c + 1): The contents of the above address.
 > 
 > > > 1. My rewritten example is legal code with no doubt and produces an
 > > >    ICE whit optimization.
 > > 
 > > Nyet.
 > 
 > Well, I still don't see why this is illegal. Can you give me the
 > paragraph of the C standard that prohibits this sort of pointer
 > arithmetic?
 
 If you have a copy of the standard, it's 6.5.6#8.  Once a pointer is
 adjusted to point outside of the original object it must not be
 dereferenced.  Accessing memory in this way produces undefined
 behavior.
 
 -- 
 Daniel Jacobowitz
 MontaVista Software                         Debian GNU/Linux Developer

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

[Richard Henderson]

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

From: Richard Henderson <rth@redhat.com>
To: Robert Schiele <rschiele@uni-mannheim.de>
Cc: rth@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
   nobody@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 01:05:55 -0800

 On Mon, Mar 17, 2003 at 06:08:21AM +0100, Robert Schiele wrote:
 > *(&c + 1) is also well defined.
 
 How's that?
 
 > 1. My rewritten example is legal code with no doubt and produces an
 >    ICE whit optimization.
 
 Nyet.
 
 
 r~

Re: 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: rth@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
   nobody@gcc.gnu.org, tneumann@pi3.informatik.uni-mannheim.de,
   gcc-gnats@gcc.gnu.org
Cc:  
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 06:08:21 +0100

 --/04w6evG8XlLl3ft
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Sun, Mar 16, 2003 at 11:26:37PM -0000, rth@gcc.gnu.org wrote:
 > Synopsis: [3.2/3.3/3.4 regression] [sparc] ICE in gen_reg_rtx, at emit-rt=
 l.c:662
 >=20
 > State-Changed-From-To: analyzed->open
 > State-Changed-By: rth
 > State-Changed-When: Sun Mar 16 23:26:37 2003
 > State-Changed-Why:
 >     The code is illegal because *(&c+1) is not an object.
 
 Well, I can show that this is not the problem:
 
 Rewriting the code as
 
 void a() {
     double b;
     int c;
     c =3D *((int*)&b) && (*(&c + 1) =3D 0);
 }
 
 shows the same problem and as c is explicitly defined here _before_,
 *(&c + 1) is also well defined.
 
 And then we have two bugs here:
 
 1. My rewritten example is legal code with no doubt and produces an
    ICE whit optimization.
 
 2. The original sample is accepted is accepted without optimization,
    although you say, it is illegal.
 
 Robert
 
 --=20
 Robert Schiele			Tel.: +49-621-181-2517
 Dipl.-Wirtsch.informatiker	mailto:rschiele@uni-mannheim.de
 
 --/04w6evG8XlLl3ft
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.0.7 (GNU/Linux)
 
 iQEVAwUBPnVYRcQAnns5HcHpAQE18AgAiDhqYRS/sUWexdcCwHXNE5QZKiVm7KjS
 u5LcL0t87k0kBf6X+EUpIre4T/rWPopJXOpiquH3jkl/9ikeI18aWQ9gwRWkcAx6
 CVtCYfzCgmmBUwvkfUL7ckFu0UTL3wzixc7Fsu34qAgcyKfOGrruuyE/JHdfcsD4
 5YU2S6mQKJvTt3aeXD5rn5Zpn3/QIGvCdZAiJm4GI51h4bX7Mgw9iXGnUYXzgGzp
 bZbFjMpcVSlZWSn24ToMheNMpMRmgkYCGEQ1nH7XXms1Fwd+O6gk1isFI61JuyZq
 YPJ43pZfyuUth2YUhOcVnmhlimoCgWmyz5RJ2klpPAB2MgUDJJP/SA==
 =lc5E
 -----END PGP SIGNATURE-----
 
 --/04w6evG8XlLl3ft--
 

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

[rth]

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

State-Changed-From-To: open->analyzed
State-Changed-By: rth
State-Changed-When: Sun Mar 16 23:27:13 2003
State-Changed-Why:
    analyzed->analyzed

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8300

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

[rth]

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

State-Changed-From-To: analyzed->open
State-Changed-By: rth
State-Changed-When: Sun Mar 16 23:26:37 2003
State-Changed-Why:
    The code is illegal because *(&c+1) is not an object.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8300