Bug 24828 - Z and negative integers
Summary: Z and negative integers
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.1.0
: P3 minor
Target Milestone: ---
Assignee: Not yet assigned to anyone
Keywords: accepts-invalid
: 29814 (view as bug list)
Depends on:
Blocks: 19292
  Show dependency treegraph
Reported: 2005-11-12 23:49 UTC by Thomas Koenig
Modified: 2006-11-13 13:59 UTC (History)
3 users (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed: 2005-11-14 17:29:06


Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Koenig 2005-11-12 23:49:50 UTC
$ cat z.f
      program z
      i = Z'80203040'
      if (i .ne. Z'80203040') call abort
$ gfortran z.f
$ ./a.out
$ g77 z.f
$ ./a.out

This is a signedness/cast issue.  .t02.original shows:

  int4 i;

  i = 080203040;
  if ((int8) i != 080203040)
      _gfortran_abort ();
      (void) 0;

(And why is hexadecimal shown as 0 in the dump?)
Comment 1 Andrew Pinski 2005-11-12 23:53:06 UTC
(In reply to comment #0)
> (And why is hexadecimal shown as 0 in the dump?)

Because that means TREE_OVERFLOW is set for some reason.

Comment 2 kargl 2005-11-14 17:25:15 UTC
Gfortran is doing the right thing with respect to
a BOZ-literal-constant (other than a BOZ can only
be used in a DATA statement per the F95 standard,
so the code is invalid).

If you look at the definition of BOZ in the standard,
you'll find that a BOZ is converted to an integer of
the largest available kind.  In this case, it appears
that integer(8) is the largest kind, so it's converted
to that type and kind.  The program assigns this 
integer(8) value to an integer(4), which explains the
(int8) cast in the if statement.
Comment 3 kargl 2005-11-14 17:29:06 UTC
Remove "wrong-code" keyword because gfortran is doing
the correct thing with a BOZ-literal-constant with the
exception of permitting BOZ-literal-constant in non-DATA
Comment 4 kargl 2006-09-29 20:52:43 UTC
Can this PR be closed?  How BOZ constants are interpreted is in accordance with the F95 standard's DATA statement.  The extension of BOZs in assignments does change the intrepretation.  With a slightly modified program, I see

troutmask:sgk[455] cat k.f90
program z
   integer(4) i
   integer(8) j
   i = Z'80203040'
   j = Z'80203040'
   print *, i, j
   if (i .ne. Z'80203040') call abort
troutmask:sgk[456] gfc -o z k.f90
 In file k.f90:4

   i = Z'80203040'
Error: Arithmetic overflow converting INTEGER(16) to INTEGER(4) at (1)
troutmask:sgk[457] gfc -o z -fno-range-check k.f90
troutmask:sgk[458] ./z
 -2145374144           2149593152
Abort (core dumped)
Comment 5 Francois-Xavier Coudert 2006-10-23 19:05:08 UTC
(In reply to comment #4)
> Can this PR be closed?

I'd say yes.
Comment 6 Andrew Pinski 2006-11-13 13:59:42 UTC
*** Bug 29814 has been marked as a duplicate of this bug. ***