headers
Arjen Markus | 1 May 13:04
Picon

Strange results with -mfpmath=sse

Hello,

with the following program I get rather weird results using gfortran 4.3.0
and the options -mfpmath=sse -march=pentium3:

! chkassoc.f90 --
!     Check associativity
!
program chkassoc
    implicit none
    integer, parameter :: wp = kind(1.0d0)
  ! integer, parameter :: wp = kind(1.0)
    real(wp) :: x
    real(wp) :: y
    real(wp) :: z
    integer  :: i
    do i = 1,50
        x = 10.0 ** i
        y = - 10.0 ** i
        z = (x + 1.0_wp) + y
        write(*,*) i, z
    enddo
end program

The result is:

           1   1.00000000000000
           2   1.00000000000000
           3   1.00000000000000
           4   1.00000000000000
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dominique Dhumieres | 1 May 13:26
Picon
Picon
Favicon

Re: Strange results with -mfpmath=sse

Arjen,

I am not an expert with *86 architecture, but your problem seems
related to the "extended floats" in the legacy *87. You may have a look to

http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/4bca729841ee871a#

and the pointer therein.

Another point is that the lines

x = 10.0 ** i
y = - 10.0 ** i

should be changed to use 10.0_wp, otherwise you are using real(4) for the rhs.

Cheers

Dominique
Permalink | Reply | 501 comments |
headers
Arjen Markus | 1 May 13:39
Picon

Re: Strange results with -mfpmath=sse

Hello Dominque,

it was exactly this thread that inspired me to have a look again at this program
(or a variant thereof - an example I have been using for in-house
courses for the
past couple of years). I replied to it with the test results - some
combinations
of flags give exactly the sort of things I would expect (not
necessarily the ones
I regard as correct), but this particular combination was way off!

(I realised there is a bug in 10.0**i when I saw NaNs for double-precision with
-ffloat-store, but the numbers reported here are, uh, weird)

Regards,

Arjen

2009/5/1 Dominique Dhumieres <dominiq <at> lps.ens.fr>:
> Arjen,
>
> I am not an expert with *86 architecture, but your problem seems
> related to the "extended floats" in the legacy *87. You may have a look to
>
> http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/4bca729841ee871a#
>
> and the pointer therein.
>
> Another point is that the lines
>
(Continue reading)

Permalink | Reply | 502 comments |
headers
Arjen Markus | 1 May 13:42
Picon

Re: Strange results with -mfpmath=sse

2009/5/1 Arjen Markus <arjen.markus895 <at> gmail.com>:
> Hello Dominque,
>
> it was exactly this thread that inspired me to have a look again at this program
> (or a variant thereof - an example I have been using for in-house
> courses for the
> past couple of years). I replied to it with the test results - some
> combinations
> of flags give exactly the sort of things I would expect (not
> necessarily the ones
> I regard as correct), but this particular combination was way off!
>
> (I realised there is a bug in 10.0**i when I saw NaNs for double-precision with
> -ffloat-store, but the numbers reported here are, uh, weird)
>

Some more information: the Intel compiler with -msse -march=pentium3 does give
results in the expected range.

Regards,

Arjen
Permalink | Reply | 2 comments |
headers
Arjen Markus | 1 May 14:24
Picon

Re: Strange results with -mfpmath=sse

2009/5/1 Arjen Markus <arjen.markus895 <at> gmail.com>:
>
> Some more information: the Intel compiler with -msse -march=pentium3 does give
> results in the expected range.
>

It seems the flag -msse2 solves the issue. With:

gfortran -mfpmath=sse -msse2 program.f90 -o program

I get a version that does the job properly.

Regards,

Arjen
Permalink | Reply | 0 comments |
headers
Paul Richard Thomas | 1 May 15:49
Picon

[Patch, fortran] PR38863 - WHERE with multiple elemental defined assignments gives wrong answer

Dear All,

The above title has become a misnomer because the original bug was
fixed.  Instead, this is the patch to fix the bug reported in comment
#1 of the PR.

Here, defined assignments within WHERE blocks of the kind

derived_type = intrinsic type expression

were not giving the correct result when there were dependences and not
all the fields of the derived type were set.  The temporary used in
the assignment was not being primed with the original value.

In addition, ordinary assignments were suffering from the same malady.
 On top of these problems, the WHERE assignment was not working
correctly in the case where the derived type has a default
initializer; ie. the original value should be overwritten by the
default.

The attached patch fixes these problems and adds appropriate tests.
Note gfortran now behaves in the same way as ifort and g95.

The patch converts gfc_trans_call to handle WHERE assignments and
gfc_conv_elemental_dependencies is corrected to initialize the
temporary for INTENT_OUT derived types.

Bootstrapped and regtested on FC9/x86_64 - OK for trunk?

Cheers
(Continue reading)

Permalink | Reply | 1 comment |
headers
Steve Kargl | 1 May 17:28
Picon

Re: [Patch, fortran] PR38863 - WHERE with multiple elemental defined assignments gives wrong answer

On Fri, May 01, 2009 at 03:49:42PM +0200, Paul Richard Thomas wrote:
> 
> 2009-05-01  Paul Thomas  <pault <at> gcc.gnu.org>
> 
> 	PR fortran/38863
> 	* trans-expr.c (gfc_conv_operator_assign): Remove function.
> 	* trans.h : Remove prototype for gfc_conv_operator_assign.
> 	* trans-stmt.c (gfc_conv_elemental_dependencies): Initialize
> 	derivde types with intent(out).
> 	(gfc_trans_call): Add mask, count1 and invert arguments. Add
> 	code to use mask for WHERE assignments.
> 	(gfc_trans_forall_1): Use new arguments for gfc_trans_call.
> 	(gfc_trans_where_assign): The gfc_symbol argument is replaced
> 	by the corresponding code. If this has a resolved_sym, then
> 	gfc_trans_call is called. The call to gfc_conv_operator_assign
> 	is removed.
> 	(gfc_trans_where_2): Change the last argument in the call to
> 	gfc_trans_where_assign.
> 	* trans-stmt.h : Modify prototype for gfc_trans_call.
> 	* trans.c (gfc_trans_code): Use new args for gfc_trans_call.
> 
> 2009-05-01  Paul Thomas  <pault <at> gcc.gnu.org>
> 
> 	PR fortran/38863
> 	* gfortran.dg/dependency_24.f90: New test.
> 	* gfortran.dg/dependency_23.f90: Clean up module files.

OK.

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Richard Thomas | 2 May 08:56
Picon

Re: Fortran whole file patch

Hi Jan,

As it happens, I just picked it up again yesterday.  My time is very
limited right now so I do not know how quickly I will find and deal
with each of the ICEs/segfaults that have been reported.

Cheers

Paul

On Fri, May 1, 2009 at 5:52 PM, Jan Hubicka <hubicka <at> ucw.cz> wrote:
>> Hi Paul,
>>
>> Your whole file patch to avoid the multiple decls per function problem
>> in gfortran came up on IRC again. Honza would like to see it and help
>> fix/verify the patch to make sure gfortran produces a good call graph
>> after your patch.
>
> Hi,
> are there any news on the patch?  This is very important problem, so it
> would be real shame to miss chance to fix it in this stage1.
>
> Honza
>>
>> Could you post (or merge to trunk) the most recent version of your patch?
>>
>> Many thanks,
>>
>> Ciao!
>> Steven
(Continue reading)

Permalink | Reply | 6 comments |
headers
Richard Guenther | 2 May 11:21
Picon

Re: Fortran whole file patch

On Sat, May 2, 2009 at 8:56 AM, Paul Richard Thomas
<paul.richard.thomas <at> gmail.com> wrote:
> Hi Jan,
>
> As it happens, I just picked it up again yesterday.  My time is very
> limited right now so I do not know how quickly I will find and deal
> with each of the ICEs/segfaults that have been reported.

It is available on trunk via -fwhole-file, correct?

Richard.

> Cheers
>
> Paul
>
> On Fri, May 1, 2009 at 5:52 PM, Jan Hubicka <hubicka <at> ucw.cz> wrote:
>>> Hi Paul,
>>>
>>> Your whole file patch to avoid the multiple decls per function problem
>>> in gfortran came up on IRC again. Honza would like to see it and help
>>> fix/verify the patch to make sure gfortran produces a good call graph
>>> after your patch.
>>
>> Hi,
>> are there any news on the patch?  This is very important problem, so it
>> would be real shame to miss chance to fix it in this stage1.
>>
>> Honza
>>>
(Continue reading)

Permalink | Reply | 5 comments |
headers
Daniel Franke | 2 May 11:48
Picon

Re: Fortran whole file patch

On Saturday 02 May 2009 11:21:01 Richard Guenther wrote:
> On Sat, May 2, 2009 at 8:56 AM, Paul Richard Thomas
>
> <paul.richard.thomas <at> gmail.com> wrote:
> > Hi Jan,
> >
> > As it happens, I just picked it up again yesterday.  My time is very
> > limited right now so I do not know how quickly I will find and deal
> > with each of the ICEs/segfaults that have been reported.
>
> It is available on trunk via -fwhole-file, correct?

Yes.
Permalink | Reply | 4 comments |

Gmane