[Bug middle-end/45472] [4.5/4.6/4.7 Regression] [Middle-end volatile semantics] ICE: in move_op_ascend, at sel-sched.c:6124 with -fselective-scheduling2

2012-02-27 Thread ebotcazou at gcc dot gnu.org 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45472

--- Comment #22 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-02-27 
08:45:52 UTC ---
 If the C or C++ standards say that vv1 = vv2 should behave as if the copy was
 elementwise then the frontends need changing.  Certainly not the gimplifier -
 that's not the kitchen-sink for things you don't want to properly describe in 
 GENERIC to the middle-end ;)

Yes, I think that we wouldn't want this in Ada for example.

[Bug middle-end/45472] [4.5/4.6/4.7 Regression] [Middle-end volatile semantics] ICE: in move_op_ascend, at sel-sched.c:6124 with -fselective-scheduling2

2012-02-20 Thread rguenth at gcc dot gnu.org 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45472

--- Comment #21 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-20 
11:43:01 UTC ---
(In reply to comment #19)
 It seems to me that volatile reads/writes should get their own gimple
 statements, not be part of a larger block move.  So instead of
 
   vv1 = vv2;
 
 we should have
 
   vv1.a ={v} vv2.a;
   vv1.b ={v} vv2.b;
 
 I agree with Paolo's comment in #12 that we want to copy the non-volatile 
 parts
 as a block when possible.  It seems like breaking a simple struct assignment
 into these separate statements would be best done in the gimplifier so that
 front ends don't need to get this right independently.
 
 Out of curiousity, what is the use case for a non-volatile struct object with
 volatile members?

There is no valid use-case for this.  So I think we should just declare this
issue a non-issue (middle-end wise).  If the C or C++ standards say that
vv1 = vv2 should behave as if the copy was elementwise then the frontends
need changing.  Certainly not the gimplifier - that's not the kitchen-sink
for things you don't want to properly describe in GENERIC to the middle-end ;)

[Bug middle-end/45472] [4.5/4.6/4.7 Regression] [Middle-end volatile semantics] ICE: in move_op_ascend, at sel-sched.c:6124 with -fselective-scheduling2

2012-02-16 Thread jason at gcc dot gnu.org 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45472

--- Comment #19 from Jason Merrill jason at gcc dot gnu.org 2012-02-16 
19:41:29 UTC ---
It seems to me that volatile reads/writes should get their own gimple
statements, not be part of a larger block move.  So instead of

  vv1 = vv2;

we should have

  vv1.a ={v} vv2.a;
  vv1.b ={v} vv2.b;

I agree with Paolo's comment in #12 that we want to copy the non-volatile parts
as a block when possible.  It seems like breaking a simple struct assignment
into these separate statements would be best done in the gimplifier so that
front ends don't need to get this right independently.

Out of curiousity, what is the use case for a non-volatile struct object with
volatile members?

[Bug middle-end/45472] [4.5/4.6/4.7 Regression] [Middle-end volatile semantics] ICE: in move_op_ascend, at sel-sched.c:6124 with -fselective-scheduling2

2012-02-16 Thread zsojka at seznam dot cz 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45472

--- Comment #20 from Zdenek Sojka zsojka at seznam dot cz 2012-02-16 20:14:54 
UTC ---
I can think of two use-cases from threaded environment:
- using the volatile member as a semaphore for the structure
- when one needs to assure some data will be written in certain order (eg.
first write data, then the 'data valid' flag), while other members of the
structure don't need to be volatile (data used by only one thread, or data that
are only read; marking the whole struct volatile would prevent some
optimisations)

Other cases:
- when debugging and you want to prevent optimisations of certain variable
- when the structure is allocated on a memory-mapped IO address, and only some
parts of that IO need to be marked as volatile
- in OOP, where the variable is a member, and would otherwise be a global
volatile variable