http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45472
--- Comment #14 from Andrey Belevantsev abel at gcc dot gnu.org 2011-01-13
10:04:18 UTC ---
Do we want at least the patch properly merging the volatile bits in the
scheduler for 4.6? Or is this better be s plain ICE instead of a silent
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45472
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|4.5.2 |4.5.3
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45472
--- Comment #6 from Andrey Belevantsev abel at gcc dot gnu.org 2010-10-18
10:57:23 UTC ---
Anybody familiar with the expand/tree level can take a look on this? I can
spare some time later this week if folks are busy.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45472
Michael Matz matz at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45472
--- Comment #8 from Paolo Bonzini bonzini at gnu dot org 2010-10-18 12:20:39
UTC ---
Would it make sense to make the statement volatile even if only some
subcomponents (or all subcomponents) are volatile?
I like (2); if I understand it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45472
--- Comment #9 from Richard Guenther rguenth at gcc dot gnu.org 2010-10-18
15:42:44 UTC ---
(In reply to comment #8)
Would it make sense to make the statement volatile even if only some
subcomponents (or all subcomponents) are volatile?
I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45472
--- Comment #10 from Michael Matz matz at gcc dot gnu.org 2010-10-18 15:58:26
UTC ---
One idea we had was that this is all frontends business anyway, and hence
it should (if it so desires) simply create volatile MEM_REFs for references
to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45472
--- Comment #11 from joseph at codesourcery dot com joseph at codesourcery dot
com 2010-10-18 16:41:03 UTC ---
On Mon, 18 Oct 2010, rguenth at gcc dot gnu.org wrote:
Also consider memcpy (vv1, vv2) and eventually the compiler optimizing
that
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45472
--- Comment #12 from Paolo Bonzini bonzini at gnu dot org 2010-10-18 17:12:59
UTC ---
It would be nice if for
struct a {
char a,b,c,d;
volatile int e;
};
struct a v1, v2;
...
v1 = v2;
the compiler emitted
--- Comment #3 from abel at gcc dot gnu dot org 2010-09-20 13:05 ---
We have the code like this:
if (...)
{
17 cx:DI=[`s2'] //comes from s2.vl += s1.vl;
...
}
27 dx:DI=[`s2'] //comes from s1 = s2;
When the scheduler tries to move insn 27 before if (...), it also unifies its
--- Comment #4 from amonakov at gcc dot gnu dot org 2010-09-20 14:49
---
A small testcase to illustrate the problem with volatile fields.
//---8---
struct vv {volatile long a, b;} vv1, vv2;
int foo()
{
vv1 = vv2;
}
//---8---
gcc/cc1 -O2 -frename-registers -fschedule-insns2 vol.c
--- Comment #5 from bonzini at gnu dot org 2010-09-20 16:01 ---
Looks like a problem in expand. CCing Matz.
--
bonzini at gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45472
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45472
--- Comment #1 from zsojka at seznam dot cz 2010-08-31 23:58 ---
Created an attachment (id=21630)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21630action=view)
reduced testcase
$ gcc -O1 -fschedule-insns2 -fselective-scheduling2 pr45472.c
--
--- Comment #2 from hjl dot tools at gmail dot com 2010-09-01 03:03 ---
It is caused by revision 147282:
http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00256.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
16 matches
Mail list logo
