| Summary: | Z and negative integers | ||
|---|---|---|---|
| Product: | gcc | Reporter: | Thomas Koenig <tkoenig> |
| Component: | fortran | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED INVALID | ||
| Severity: | minor | CC: | gcc-bugs, kargls, vahtras |
| Priority: | P3 | Keywords: | accepts-invalid |
| Version: | 4.1.0 | ||
| Target Milestone: | --- | ||
| Host: | Target: | ||
| Build: | Known to work: | ||
| Known to fail: | Last reconfirmed: | 2005-11-14 17:29:06 | |
| Bug Depends on: | |||
| Bug Blocks: | 19292 | ||
(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. Confirmed. 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. 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 statements. 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
end
troutmask:sgk[456] gfc -o z k.f90
In file k.f90:4
i = Z'80203040'
1
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)
(In reply to comment #4) > Can this PR be closed? I'd say yes. |
$ cat z.f program z i = Z'80203040' if (i .ne. Z'80203040') call abort end $ gfortran z.f $ ./a.out Aborted $ g77 z.f $ ./a.out $ This is a signedness/cast issue. .t02.original shows: int4 i; i = 080203040; if ((int8) i != 080203040) { _gfortran_abort (); } else { (void) 0; } (And why is hexadecimal shown as 0 in the dump?)