[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

[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

[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

[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