headers
Brooks Moses | 1 May 01:03

Re: secnds.f still at it.

Steve Ellcey wrote:
> FYI:  As of last night I still get some secnds.f / secnds-1.f failures.
> I think we do need the _8 on the constants (at least on the 0.001
> constant).

I'll have a regression test going for another patch momentarily, so I'll 
do up a fix to add that, and toss it into the mix.

Thanks,
- Brooks
Permalink | Reply | 1 comment |
headers
Steve Kargl | 1 May 01:31
Picon

Re: ISO C Binding merge status

On Mon, Apr 23, 2007 at 04:21:25PM -0600, Christopher D. Rickett wrote:
> 
> i have one (very small) patch pending.  all it does is mangles the names 
> of the generated C_PTR/C_FUNPTR symbols.  i haven't updated in a while, 
> so perhaps i should wait to submit the patch until the unexpected failures 
> are handled.  thoughts?
> 

Chris,

Tobias and I have completed a merge upto this weekends
trunk.  There are 2 regression that neither one of us
has been able to resolve.  Can you update your source,
test your patch, and send it to me?  Help on resolving
these 2 problem would also be appreciated.

--

-- 
Steve
Permalink | Reply | 3 comments |
headers
Steve Kargl | 1 May 05:34
Picon

[fortran-experiments] Patch applied.

If anyone cares, I've committed the attached patch.

2207-04-30  Steven G. Kargl  <kargl <at> gcc.gnu.org>

    * symbol.c:  Whitespace.  Fix comment punctuation and gammar.
    * decl.c:  Ditto.
    * trans-common.c: Ditto.
    * expr.c: Ditto.

--

-- 
Steve
Attachment (white.diff): text/x-diff, 90 KiB
Permalink | Reply | 0 comments |
headers
Jerry DeLisle | 1 May 05:38
Picon

Re: secnds.f still at it.

Brooks Moses wrote:
> Steve Ellcey wrote:
>> FYI:  As of last night I still get some secnds.f / secnds-1.f failures.
>> I think we do need the _8 on the constants (at least on the 0.001
>> constant).
> 
> I'll have a regression test going for another patch momentarily, so I'll 
> do up a fix to add that, and toss it into the mix.
> 
> Thanks,
> - Brooks
> 
> 
I have been experimenting.  I see on my system that (t1a-t1) always comes out 
zero.  Also, (dat1-t1) comes in a range of +-.005 seconds.  Changing all 
variables and constants to kind=8 makes this fail more often.  I think the test 
needs some sort of tolerance or may need to be redesigned.

Add an outer loop that runs through the program about 100 times and it becomes 
very clear that it fails a lot.  When you have your patch ready, I will test it 
here too.

Jerry
Permalink | Reply | 0 comments |
headers
Tobias Schlüter | 1 May 05:58
Picon
Favicon

Re: Fix for PR fortran/31732

Thomas Koenig wrote:
>      {
> +      /*
> +	If we hange a single element in the reference, we need to check that
> +	the array has a single element and that we actually reference the
> +	correct element.
> +       */

<nitpicking>should be
  /* If we have a single element in the reference, we need to check that
     the array has a single element and that we actually reference the
     correct element.  */
</nitpicking>

Thanks,
- Tobi
Permalink | Reply | 0 comments |
headers
Daniel Franke | 1 May 11:53
Picon

[patch, fortran] PR22539 implement FSEEK intrinsic


Follow-up to: http://gcc.gnu.org/ml/fortran/2007-04/msg00560.html

Although the patch was already more or less approved ("Do as you want"), 
here's an updated version that follows the suggestions made.

When resolving the subroutine, the offset is now converted to gfc_intio_kind, 
thus, only one library function is necessary (instead of four). Also added a 
testcase.

Thanks to everyone commenting on this!

gcc/fortran:
2007-05-01  Daniel Franke  <franke.daniel <at> gmail.com>

	PR fortran/22539
        * intrinsic.c (add_subroutines): Added FSEEK.
        * intrinsic.h (gfc_resolve_fseek_sub, gfc_check_fseek_sub): New.
        * iresolve.c (gfc_resolve_fseek_sub): New.
        * check.c (gfc_check_fseek_sub): New.
        * intrinsic.texi (FSEEK): Updated.

libgfortran:
2007-05-01  Daniel Franke  <franke.daniel <at> gmail.com>

	PR fortran/22539
        * io/intrinsics.c (fseek_sub): New.
        * gfortran.map (fseek_sub): New.

gcc/testsuite:
(Continue reading)

Permalink | Reply | 30 comments |
headers
Tim Prince | 1 May 15:02
Picon

vectorization stride -1

Do we have any way to persuade gfortran to vectorize stride -1 ?  e.g.

a(n:2:-1)= a(n-1:1:-1)+b(n-1:1:-1)

(from netlib vector Levine-Callahan-Dongarra benchmark), which has to be 
vectorized at stride -1 to deal with the operand overlap.  Ideally,
a(2:n)= a(:n-1) + b(:n-1)
would generate the same code.  ifort vectorizes it with a temporary, and 
doesn't perform as well on Core 2 Duo as gfortran does with the first 
version.
Permalink | Reply | 1 comment |
headers
Thomas Koenig | 1 May 15:15

Re: Fix for PR fortran/31732

On Mon, 2007-04-30 at 15:25 -0700, Steve Kargl wrote:

> OK after you change the comment.  "hange" should be "have".

Committed as revision 124326 after fixing the comment and the typo.

Thanks!

	Thomas
Permalink | Reply | 0 comments |
headers
Paul Thomas | 1 May 15:20
Picon

Re: vectorization stride -1

Tim,

I'll clean the dust of my loop reverser for the scalarizer:)

Paul
Permalink | Reply | 0 comments |
headers
kokorelis | 1 May 16:15
Picon

trojean horse on yours

Dear Sir/madam,

I have jusr download your installer for windows at
http://gcc.gnu.org/wiki/GFortranBinariesWindows
and my avast software regognize the .exe file as trojean horse.
I will be grateful if you can consider this message.
sincerely,
Dr.Christos Kokorelis
Institute of Nuclear Physics, N.C.S.R. Demokritos,
Athens, Greece

--

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Permalink | Reply | 1 comment |

Gmane