[Bug fortran/34933] no .XOR. operator

2008-01-23 Thread fxcoudert at gcc dot gnu dot org
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2008-01-23 10:56 --- We chose not to implement it (I remember discussing it with Jerry and someone else on IRC, and I think I asked for opinions on the mailing-list before closing the bugreport as WONTFIX), because of the potential

[Bug fortran/34933] no .XOR. operator

2008-01-22 Thread bdavis at gcc dot gnu dot org
--- Comment #1 from bdavis at gcc dot gnu dot org 2008-01-23 02:51 --- metcalf and reid, page 40 says that .neqv. is logically the same as XOR. so, an easy work around is available. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34933

[Bug fortran/34933] no .XOR. operator

2008-01-22 Thread kargl at gcc dot gnu dot org
--- Comment #2 from kargl at gcc dot gnu dot org 2008-01-23 02:58 --- Roger Sayle implemented .xor., but it was not committed to the tree. You can probably find discussion in the mailing list archive if you care to do some spelunking. I recall the patch wasn't committed because of

[Bug fortran/34933] no .XOR. operator

2008-01-22 Thread jvdelisle at gcc dot gnu dot org
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-01-23 03:25 --- Thats right Steve and we encourage everyone to use .neqv. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34933

[Bug fortran/34933] no .XOR. operator

2008-01-22 Thread burnus at gcc dot gnu dot org
--- Comment #4 from burnus at gcc dot gnu dot org 2008-01-23 07:03 --- For the mentioed patch see PR 33432 I'm not sure whether it makes sense to implement it, but if one could hide it behind a -fxor / -fno-xor. Ifort 10.1 has for instance: -assume noold_xor Prevents the