[Bug fortran/34933] New: no .XOR. operator

[Bug fortran/34933] New: no .XOR. operator

[bdavis at gcc dot gnu dot org]

$ cat a.f
      logical a,b,c
      a = .TRUE.
      b = .FALSE.
      c = a .xor.b
      print*,c
      end
$ gfortran --version
GNU Fortran (GCC) 4.3.0 20071217 (experimental)
Copyright (C) 2007 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING

$ gfortran -c a.f
a.f:4.17:

      c = a .xor.b                                                      
                1
Error: Unknown operator 'xor' at (1)
$ g77 a.f
$ ./a.out
 T


-- 
           Summary: no .XOR. operator
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: bdavis at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34933

[Bug fortran/34933] no .XOR. operator

[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

[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 possible conflicts with a user defined .xor. operator.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34933

[Bug fortran/34933] no .XOR. operator

[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

[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 compiler from defining .XOR. as an intrinsic operator. This
     lets  you specify  .XOR.  as  a  user-defined operator. The default is
     -assume old_xor, which tells the compiler to define .XOR. as an intrinsic
     operator.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34933

[Bug fortran/34933] no .XOR. operator

[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 problems and the
extra cost. Of course, if someone comes up with a patch (including an
-fxo-is-neqv or similarly named option), things are different :)

*** This bug has been marked as a duplicate of 33432 ***


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fxcoudert at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34933