public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/33002]  New: 64-bit hexadecimal DATA incorrect
@ 2007-08-06 11:14 sliwa at cft dot edu dot pl
  2007-08-06 11:15 ` [Bug fortran/33002] " sliwa at cft dot edu dot pl
                   ` (4 more replies)
  0 siblings, 5 replies; 6+ messages in thread
From: sliwa at cft dot edu dot pl @ 2007-08-06 11:14 UTC (permalink / raw)
  To: gcc-bugs

Statements like:

      DATA DMACH(1) / Z'0010000000000000' /
      DATA DMACH(2) / Z'7FEFFFFFFFFFFFFF' /
      DATA DMACH(3) / Z'3CA0000000000000' /
      DATA DMACH(4) / Z'3CB0000000000000' /
      DATA DMACH(5) / Z'3FD34413509F79FF' /

generate incorrect data.


-- 
           Summary: 64-bit hexadecimal DATA incorrect
           Product: gcc
           Version: 4.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: sliwa at cft dot edu dot pl
 GCC build triplet: x86_64-redhat-linu
  GCC host triplet: x86_64-redhat-linu
GCC target triplet: x86_64-redhat-linu


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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug fortran/33002] 64-bit hexadecimal DATA incorrect
  2007-08-06 11:14 [Bug fortran/33002] New: 64-bit hexadecimal DATA incorrect sliwa at cft dot edu dot pl
@ 2007-08-06 11:15 ` sliwa at cft dot edu dot pl
  2007-08-06 11:18 ` sliwa at cft dot edu dot pl
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: sliwa at cft dot edu dot pl @ 2007-08-06 11:15 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #1 from sliwa at cft dot edu dot pl  2007-08-06 11:15 -------
Created an attachment (id=14029)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14029&action=view)
sample source that demonstrates the problem

This is a SLATEC machine file


-- 


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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug fortran/33002] 64-bit hexadecimal DATA incorrect
  2007-08-06 11:14 [Bug fortran/33002] New: 64-bit hexadecimal DATA incorrect sliwa at cft dot edu dot pl
  2007-08-06 11:15 ` [Bug fortran/33002] " sliwa at cft dot edu dot pl
@ 2007-08-06 11:18 ` sliwa at cft dot edu dot pl
  2007-08-06 11:21 ` sliwa at cft dot edu dot pl
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: sliwa at cft dot edu dot pl @ 2007-08-06 11:18 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #2 from sliwa at cft dot edu dot pl  2007-08-06 11:18 -------
There is also bug #33001. Both the bugs together make life difficult.


-- 


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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug fortran/33002] 64-bit hexadecimal DATA incorrect
  2007-08-06 11:14 [Bug fortran/33002] New: 64-bit hexadecimal DATA incorrect sliwa at cft dot edu dot pl
  2007-08-06 11:15 ` [Bug fortran/33002] " sliwa at cft dot edu dot pl
  2007-08-06 11:18 ` sliwa at cft dot edu dot pl
@ 2007-08-06 11:21 ` sliwa at cft dot edu dot pl
  2007-08-06 12:49 ` [Bug fortran/33002] Hexadecimal " burnus at gcc dot gnu dot org
  2007-08-06 17:33 ` kargl at gcc dot gnu dot org
  4 siblings, 0 replies; 6+ messages in thread
From: sliwa at cft dot edu dot pl @ 2007-08-06 11:21 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #3 from sliwa at cft dot edu dot pl  2007-08-06 11:21 -------
Now I see that 32-bit data is incorrect also.

      DATA RMACH(1) / Z'00800000' /
      DATA RMACH(2) / Z'7F7FFFFF' /
      DATA RMACH(3) / Z'33800000' /
      DATA RMACH(4) / Z'34000000' /
      DATA RMACH(5) / Z'3E9A209B' /


-- 


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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug fortran/33002] Hexadecimal DATA incorrect
  2007-08-06 11:14 [Bug fortran/33002] New: 64-bit hexadecimal DATA incorrect sliwa at cft dot edu dot pl
                   ` (2 preceding siblings ...)
  2007-08-06 11:21 ` sliwa at cft dot edu dot pl
@ 2007-08-06 12:49 ` burnus at gcc dot gnu dot org
  2007-08-06 17:33 ` kargl at gcc dot gnu dot org
  4 siblings, 0 replies; 6+ messages in thread
From: burnus at gcc dot gnu dot org @ 2007-08-06 12:49 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #4 from burnus at gcc dot gnu dot org  2007-08-06 12:49 -------
Using
      REAL RMACH(5)
      DATA RMACH(1) / Z'00800000' /

is invalid Fortran 77/90/95/2003 as Fortran only allows:

"If a data-stmt-constant is a boz-literal-constant, the corresponding variable
shall be of type integer. The boz-literal-constant is treated as if it were an
int-literal-constant with a kind-param that specifies the representation method
with the largest decimal exponent range supported by the processor."

Gfortran interprets
      DATA RMACH(1) / Z'00800000' /
as
  rmach(1) = real(int(Z'00800000', maximallyNeededKind))
which is ok as the program is invalid and thus undfefined. Other compilers
interpret it as bit pattern. The result is are
8388608. respectively 1.1754944E-38.

Solution for Fortran 90/95/2003: Replace
  DATA RMACH(1) / Z'00800000' /
by
  RMACH(1) = transfer( Z'00800000', rmach)


I think nonetheless that gfortran misbehaves.
Expected:
- With -std=f95 etc. give a warning or an error
- With -std=gnu allow it (maybe with warning?) and tread as
  transfer(Z'...', 0.0) to be compatible with the other compilers.

NAG f95 gives always the error:
Error: Data-stmt-value incompatible with data-stmt-object

whereas, e.g., g95 and ifort give a warning for -std=f95 and have the same
result as with TRANSFER.

Warning (160): BOZ constant conversion at (1) is nonstandard
Warning: Fortran 95 does not allow boz constant in this context.


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu dot
                   |                            |org
  GCC build triplet|x86_64-redhat-linu          |
   GCC host triplet|x86_64-redhat-linu          |
 GCC target triplet|x86_64-redhat-linu          |
           Keywords|                            |diagnostic
            Summary|64-bit hexadecimal DATA     |Hexadecimal DATA incorrect
                   |incorrect                   |


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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug fortran/33002] Hexadecimal DATA incorrect
  2007-08-06 11:14 [Bug fortran/33002] New: 64-bit hexadecimal DATA incorrect sliwa at cft dot edu dot pl
                   ` (3 preceding siblings ...)
  2007-08-06 12:49 ` [Bug fortran/33002] Hexadecimal " burnus at gcc dot gnu dot org
@ 2007-08-06 17:33 ` kargl at gcc dot gnu dot org
  4 siblings, 0 replies; 6+ messages in thread
From: kargl at gcc dot gnu dot org @ 2007-08-06 17:33 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #5 from kargl at gcc dot gnu dot org  2007-08-06 17:32 -------


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


-- 

kargl at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE


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


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2007-08-06 17:33 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-08-06 11:14 [Bug fortran/33002] New: 64-bit hexadecimal DATA incorrect sliwa at cft dot edu dot pl
2007-08-06 11:15 ` [Bug fortran/33002] " sliwa at cft dot edu dot pl
2007-08-06 11:18 ` sliwa at cft dot edu dot pl
2007-08-06 11:21 ` sliwa at cft dot edu dot pl
2007-08-06 12:49 ` [Bug fortran/33002] Hexadecimal " burnus at gcc dot gnu dot org
2007-08-06 17:33 ` kargl at gcc dot gnu dot org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).