--- Comment #11 from joseph at codesourcery dot com 2010-03-20 23:46
---
Subject: Re: gcc -O code generation error
I advise referring to
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1252.htm
which is what has been integrated in C1X.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #10 from pinskia at gcc dot gnu dot org 2010-03-20 23:19
---
Oh yes the partial vs full order issue.
There is a nice paper about this:
http://www.open-std.org/JTC1/SC22/wg14/www/docs/n926.htm
12.3 is the part which I think explains it all.
--
http://gcc.gnu.org/bugzilla
--- Comment #9 from gccbug at dworkin dot nl 2010-03-20 23:14 ---
Subject: Re: gcc -O code generation error
> No, we have a | b. There is an order inside a and b but no order between a
> and
> b.
That's depressing. C99 says in 5.1.2.3:
Evaluation of an expression may produce
--- Comment #8 from pinskia at gcc dot gnu dot org 2010-03-20 21:54 ---
(In reply to comment #7)
> Subject: Re: gcc -O code generation error
>
> To clarify even further, we have
>
> (..., (f->sp++)->u.number [SEQUENCE POINT] ? 1 : 0) |
> (..., (f->sp++)->u.number [SEQUENCE POINT] ? 4
--- Comment #7 from gccbug at dworkin dot nl 2010-03-20 21:51 ---
Subject: Re: gcc -O code generation error
To clarify even further, we have
(..., (f->sp++)->u.number [SEQUENCE POINT] ? 1 : 0) |
(..., (f->sp++)->u.number [SEQUENCE POINT] ? 4 : 0)
So the modifications of f->sp are bef
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-03-20 21:18 ---
Just to clarify we have:
((i_push_value(f, (f->fp - 1)),
(--f->sp)->type = 0x01, f->sp->u.number = ((Int) 0x1L), i_index(f),
(--f->sp)->type = 0x01, f->sp->u.number = ((Int) 0x8L), kf_and(f),
(f->sp++)->u.number) ?
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-03-20 21:16 ---
I cannot follow the () correctly. There is no sequence point here because it
is a | separating the modifications of f->sp. So this is not a bug in GCC but
a bug in your code.
--
pinskia at gcc dot gnu dot org c
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-03-20 21:01 ---
Seems to be the simple-minded CSE that gimplification performs, of f->sp.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-03-20 20:59 ---
>There's a sequence point after evaluating the first operand.
With -W -Wall, I get:
t.c:79:58: warning: operation on âf->spâ may be undefined
Looks like that is the issue.
So there might be still an missing seq
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-03-20 20:53 ---
(In reply to comment #1)
> (f->sp++)->u.number) ? ((Int) 0x1L) : ((Int) 0x0L)) | (((--f->sp)->type =
> 0x01,
> f->sp->u.number = ivar10,
> (f->argp + 3)->u.number = ivar3,
> i_funcall(f, (object *) ((void *)0), (arr
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-03-20 20:40 ---
(f->sp++)->u.number) ? ((Int) 0x1L) : ((Int) 0x0L)) | (((--f->sp)->type = 0x01,
f->sp->u.number = ivar10,
(f->argp + 3)->u.number = ivar3,
i_funcall(f, (object *) ((void *)0), (array *) ((void *)0), 0, 5 , 1),
(f->sp
11 matches
Mail list logo
