--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-02-19 01:40
---
I get:
./a.out
At line 15 of file foo.f90
Fortran runtime error: Corrupt unformatted sequential file
This points to a compatibility issue, but the fact that it did not fail on the
first read and did on the secon
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-02-19 01:40 ---
This program works on powerpc-darwin (and most likely other targets too):
program pr
INTEGER, PARAMETER :: MG=16
REAL,SAVE :: abscoefL1(5,13,MG),abscoefH1(5,13:59,MG), &
SELFREF1(10
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-02-19 01:41 ---
(In reply to comment #5)
> This points to a compatibility issue, but the fact that it did not fail on the
> first read and did on the second is suspicious.
Not really as there was enough data for the first one but n
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2006-02-19 01:59
---
#6 works on i686 as well. If SPEC 2006 is indeed using non-portable data then
we need to notify. HJ can you look into this for us?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26357
When I compile the following code with -O1 -ftree-vrp or -O2, it prints
-2147483647, instead of 1 as expected. (The intent of the code was to search
for integers which, when squared and truncated, give small positive values.)
#include
#include
#include
int main() {
int min = INT_MAX, i
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-19 02:08 ---
This is not a bug in GCC. This is undefined code because of signed overflow.
i * i will always be greater than zero if i is also greater than zero with
signed types unless you use -fwrapv which causes overflow to b
--- Comment #2 from tomfelker at gmail dot com 2006-02-19 02:20 ---
OK, -fwrapv fixes it. But what if I do this, shouldn't it work as I expect?
(It doesn't without -fwrapv.) Also, what is the safe way to do what I want?
int min = INT_MAX, i;
for(i = 1; i > 0; ++i) {
int candi
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-02-19 02:21 ---
(In reply to comment #2)
> OK, -fwrapv fixes it. But what if I do this, shouldn't it work as I expect?
> (It doesn't without -fwrapv.) Also, what is the safe way to do what I want?
Use -fwrapv since that defines
--- Comment #9 from hjl at lucon dot org 2006-02-19 02:23 ---
I didn't check how the data was generated. It is taken from a Linux/i686
machine.
I doubt it is invalid. At least, it should be valid on Linux/i686. Another
Fortran compiler has no problem with the testcase.
Jerry, does my O
Using a gcc build from today I tried one of the autovectorization test cases
and found it over optimized:
$ ~/toolchain/install/bin/gcc -v
Using built-in specs.
Target: powerpc-linux
Configured with: /home/anton/toolchain/gcc/gcc/configure --build=powerpc-linux
--host=powerpc-linux --target=power
--- Comment #10 from hjl at lucon dot org 2006-02-19 02:25 ---
FYI, there are only 2 different input files for this benchmark, little endian
and
big endian. My testcase should be valid for all little endian machines.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26357
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-19 02:26 ---
Confirmed, also fails on x86_64.
This is a regression from 4.1.0. It also looks like an aliasing issue too as
DCE is removing the statements.
--
pinskia at gcc dot gnu dot org changed:
What|Remo
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-02-19 02:31
---
This is invalid really as the problem is different size of record header.
There is a bug to fix this (PR 19303) but really this is just unportantable
data even with the little/big endian issue fixed.
Please report
--- Comment #13 from hjl at lucon dot org 2006-02-19 02:44 ---
Need more info.
--
hjl at lucon dot org changed:
What|Removed |Added
Status|RESOLVED
--- Comment #12 from hjl at lucon dot org 2006-02-19 02:43 ---
Please provide more details on this issue since this is a gcc only problem.
I need references to Fortran standard when I talk to our SPEC people.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26357
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-02-19 02:46
---
Read:
http://gcc.gnu.org/ml/fortran/2004-12/msg00139.html
Basicially unformatted input was never meant to be portable.
The way for them to fix their issue is to have a program that writes out the
unformatted data
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-02-19 02:56
---
>From Fortran 2003
9.1.2:
An unformatted record consists of a sequence of values in a processor-dependent
form and may contain data of any type or may contain no data.
processor-dependent in Fortan means compiler
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-02-19 02:57
---
(In reply to comment #15)
> processor-dependent in Fortan means compiler dependent
In the same way implemenation defined code is in C and C++.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26357
A gcc build from this morning:
$ /home/anton/toolchain/install/bin/gcc -v
Using built-in specs.
Target: powerpc-linux
Configured with: /home/anton/toolchain/gcc/gcc/configure --build=powerpc-linux
--host=powerpc-linux --target=powerpc-linux --enable-targets=powerpc64-linux
--enable-languages=c,c++
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-19 04:17 ---
Confirmed, a regression from 4.1.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-19 06:11 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
101 - 121 of 121 matches
Mail list logo
