public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: optimization/8300: [3.2/3.3/3.4 regression] [sparc] ICE in gen_reg_rtx, at emit-rtl.c:662
@ 2003-03-16 23:27 rth
0 siblings, 0 replies; 16+ messages in thread
From: rth @ 2003-03-16 23:27 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, nobody, rschiele, tneumann
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: optimization/8300: [3.2/3.3/3.4 regression] [sparc] ICE in gen_reg_rtx, at emit-rtl.c:662
@ 2003-04-24 4:23 rth
0 siblings, 0 replies; 16+ messages in thread
From: rth @ 2003-04-24 4:23 UTC (permalink / raw)
To: ebotcazou, gcc-bugs, gcc-prs, rschiele, rth, tneumann
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: optimization/8300: [3.2/3.3/3.4 regression] [sparc] ICE in gen_reg_rtx, at emit-rtl.c:662
@ 2003-03-18 20:29 ebotcazou
0 siblings, 0 replies; 16+ messages in thread
From: ebotcazou @ 2003-03-18 20:29 UTC (permalink / raw)
To: ebotcazou, gcc-bugs, gcc-prs, nobody, rschiele, tneumann
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: optimization/8300: [3.2/3.3/3.4 regression] [sparc] ICE in gen_reg_rtx, at emit-rtl.c:662
@ 2003-03-17 17:16 Robert Schiele
0 siblings, 0 replies; 16+ messages in thread
From: Robert Schiele @ 2003-03-17 17:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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--
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: optimization/8300: [3.2/3.3/3.4 regression] [sparc] ICE in gen_reg_rtx, at emit-rtl.c:662
@ 2003-03-17 17:06 Falk Hueffner
0 siblings, 0 replies; 16+ messages in thread
From: Falk Hueffner @ 2003-03-17 17:06 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: optimization/8300: [3.2/3.3/3.4 regression] [sparc] ICE in gen_reg_rtx, at emit-rtl.c:662
@ 2003-03-17 16:56 Joseph S. Myers
0 siblings, 0 replies; 16+ messages in thread
From: Joseph S. Myers @ 2003-03-17 16:56 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: optimization/8300: [3.2/3.3/3.4 regression] [sparc] ICE in gen_reg_rtx, at emit-rtl.c:662
@ 2003-03-17 16:26 Robert Schiele
0 siblings, 0 replies; 16+ messages in thread
From: Robert Schiele @ 2003-03-17 16:26 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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--
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: optimization/8300: [3.2/3.3/3.4 regression] [sparc] ICE in gen_reg_rtx, at emit-rtl.c:662
@ 2003-03-17 15:56 Robert Schiele
0 siblings, 0 replies; 16+ messages in thread
From: Robert Schiele @ 2003-03-17 15:56 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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--
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: optimization/8300: [3.2/3.3/3.4 regression] [sparc] ICE in gen_reg_rtx, at emit-rtl.c:662
@ 2003-03-17 15:36 Andreas Schwab
0 siblings, 0 replies; 16+ messages in thread
From: Andreas Schwab @ 2003-03-17 15:36 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
[-- 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."
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: optimization/8300: [3.2/3.3/3.4 regression] [sparc] ICE in gen_reg_rtx, at emit-rtl.c:662
@ 2003-03-17 15:26 Falk Hueffner
0 siblings, 0 replies; 16+ messages in thread
From: Falk Hueffner @ 2003-03-17 15:26 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: optimization/8300: [3.2/3.3/3.4 regression] [sparc] ICE in gen_reg_rtx, at emit-rtl.c:662
@ 2003-03-17 15:26 Robert Schiele
0 siblings, 0 replies; 16+ messages in thread
From: Robert Schiele @ 2003-03-17 15:26 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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--
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: optimization/8300: [3.2/3.3/3.4 regression] [sparc] ICE in gen_reg_rtx, at emit-rtl.c:662
@ 2003-03-17 14:36 Daniel Jacobowitz
0 siblings, 0 replies; 16+ messages in thread
From: Daniel Jacobowitz @ 2003-03-17 14:36 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: optimization/8300: [3.2/3.3/3.4 regression] [sparc] ICE in gen_reg_rtx, at emit-rtl.c:662
@ 2003-03-17 9:26 Robert Schiele
0 siblings, 0 replies; 16+ messages in thread
From: Robert Schiele @ 2003-03-17 9:26 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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--
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: optimization/8300: [3.2/3.3/3.4 regression] [sparc] ICE in gen_reg_rtx, at emit-rtl.c:662
@ 2003-03-17 9:16 Richard Henderson
0 siblings, 0 replies; 16+ messages in thread
From: Richard Henderson @ 2003-03-17 9:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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~
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: optimization/8300: [3.2/3.3/3.4 regression] [sparc] ICE in gen_reg_rtx, at emit-rtl.c:662
@ 2003-03-17 5:16 Robert Schiele
0 siblings, 0 replies; 16+ messages in thread
From: Robert Schiele @ 2003-03-17 5:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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--
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: optimization/8300: [3.2/3.3/3.4 regression] [sparc] ICE in gen_reg_rtx, at emit-rtl.c:662
@ 2003-03-16 23:26 rth
0 siblings, 0 replies; 16+ messages in thread
From: rth @ 2003-03-16 23:26 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, nobody, rschiele, tneumann
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
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2003-04-24 4:23 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-03-16 23:27 optimization/8300: [3.2/3.3/3.4 regression] [sparc] ICE in gen_reg_rtx, at emit-rtl.c:662 rth
-- strict thread matches above, loose matches on Subject: below --
2003-04-24 4:23 rth
2003-03-18 20:29 ebotcazou
2003-03-17 17:16 Robert Schiele
2003-03-17 17:06 Falk Hueffner
2003-03-17 16:56 Joseph S. Myers
2003-03-17 16:26 Robert Schiele
2003-03-17 15:56 Robert Schiele
2003-03-17 15:36 Andreas Schwab
2003-03-17 15:26 Falk Hueffner
2003-03-17 15:26 Robert Schiele
2003-03-17 14:36 Daniel Jacobowitz
2003-03-17 9:26 Robert Schiele
2003-03-17 9:16 Richard Henderson
2003-03-17 5:16 Robert Schiele
2003-03-16 23:26 rth
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).