headers
Brooks Moses | 1 Jul 05:51

Re: Fortran regressions

I'm cc'ing this to the fortran@ list, as many of the Fortran developers 
don't read the main GCC lists.

Thanks for mentioning this!
- Brooks

Daniel Berlin wrote:
> Apparently there are some fortran regressions caused by my patch.
> 
> The last time I modified the patch (which was before the freeze), I
> did a test of C, C++, Fortran, objc.
> 
> After the freeze ended, I did an svn update in that tree, bootstrapped
> and regtested c/c++, and committed it.
> 
> Other than the long span of time between the two, this is, AFAIK,
> normal for most developers.
> 
> I am working on finding and fixing the fortran regressions.
> Hopefully it will be obvious what is wrong.
> If it is not, I will happily revert the PRE changes until they are
> fixed, so life can continue.
>
Permalink | Reply | 10 comments |
headers
Steve Kargl | 1 Jul 06:12
Picon

Re: Fortran regressions

On Sat, Jun 30, 2007 at 08:51:33PM -0700, Brooks Moses wrote:
> I'm cc'ing this to the fortran@ list, as many of the Fortran developers 
> don't read the main GCC lists.
> 
> Thanks for mentioning this!
> - Brooks
> 
> Daniel Berlin wrote:
> >Apparently there are some fortran regressions caused by my patch.
> >
> >The last time I modified the patch (which was before the freeze), I
> >did a test of C, C++, Fortran, objc.
> >
> >After the freeze ended, I did an svn update in that tree, bootstrapped
> >and regtested c/c++, and committed it.
> >
> >Other than the long span of time between the two, this is, AFAIK,
> >normal for most developers.
> >
> >I am working on finding and fixing the fortran regressions.
> >Hopefully it will be obvious what is wrong.
> >If it is not, I will happily revert the PRE changes until they are
> >fixed, so life can continue.
> >

Brooks, this well known to at least jerryd and myself.  There
was a spirited exchange on IRC.  I, for one, was extremely
frustrated.

PS: How's the thesis going?  (I was in your position once).
(Continue reading)

Permalink | Reply | 9 comments |
headers
Paul Thomas | 1 Jul 11:18
Picon

Re: Fortran regressions

Steve,

If it's any help to those searching, I tried to do a commit from my 
hotel on Thursday evening.  I updated my tree and this version was 
perfectly viable.  By yesterday lunchtime, I was in a position to update 
again, by which time the regressions had appeared.

I am sorry that I am not in a position to help - I am on the road again 
in an hour and still have a pile of shirts to iron :-(

Paul
Permalink | Reply | 1 comment |
headers
Janne Blomqvist | 1 Jul 14:09
Picon

Re: [Patch, fortran/libgfortran] ABI cleanup for ALLOCATE

Jerry DeLisle wrote:
> Jerry DeLisle wrote:
>> Janne Blomqvist wrote:
>>> :ADDPATCH fortran:
>>>
>>> Hi,
>>>
>>> the attached patch does some ABI cleanup for the parts of libgfortran 
>>> that support the ALLOCATE statement. Currently we have separate 
>>> functions for 32 and 64-bit sizes. However, on 64-bit targets we 
>>> always use the 64-bit variants and on 32-bit targets we always use 
>>> the 32-bit variant. So it's a bit pointless (?) to keep both in the 
>>> library. The patch changes the frontend and library to use the 
>>> correct index_integer_type for sizes (the same type that array 
>>> descriptors use), and removes the 64-bit specific symbols.
>>>
>>> As to why do something like this instead of fixing real bugs, now 
>>> that we have symbol versioning we have until the 4.3 release to do 
>>> whatever ABI fixing we want, after that we are stuck with supporting 
>>> the ABI for a while.
>>>
>>> Regtested on i686-pc-linux-gnu. It would be nice if someone with a 
>>> 64-bit system could test this, and also checking that generating 
>>> 32-bit code using the 64-bit compiler works correctly. After that, Ok 
>>> for trunk?
>>>
>> Janne,
>>
>> I am testing now.  Patch went in clean so no bitrot. :)
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Janne Blomqvist | 1 Jul 14:53
Picon

Re: [patch, libgfortran][4.3 regression] PR32554 Bug in P formatting

Jerry DeLisle wrote:
> :ADDPATCH fortran:
> 
> Hi all,
> 
> The initial problem here is that gfortran was truncating by one with 
> snprintf and overflowing the buffer by one with sprintf.  Surprising we 
> were not getting an error before enabling snprintf.  Using snprintf 
> uncovered this latent bug.
> 
> Investigating further I found that the problem could be avoided by 
> adjusting the calculation of the the number of digits, ndigits.  I 
> simply reduced this by one.  However, examining the buffer after the 
> calls to snprintf showed that the width was varying because the number 
> of exponent digits, edigits, varied.
> 
> Exploring this, I tried fixing the size of edigits to see what happens.  
> I discovered that edigits does not need to be calculated at all.  If it 
> is set to the largest expected size (4) snprintf (and sprintf) 
> conveniently pads blanks at the end anyway.  (The exponent is read back 
> in downstream by atoi)
> 
> The result is seriously simplified code which should yield better 
> performance.
> 
> Regression tested on x86-64-pc-Gnu/Linux.
> 
> Also NIST tested.
> 
> NOTE: I tested with sprintf and snprintf on my system by commenting out
(Continue reading)

Permalink | Reply | 2 comments |
headers
Daniel Franke | 1 Jul 15:32
Picon

Re: [fortran, patch] PR17711 - wrong operator name in error message

On Saturday 30 June 2007 17:49:23 Daniel Franke wrote:
> gcc/testsuite:
> 2007-06-30  Daniel Franke  <franke.daniel <at> gmail.com>
>
> 	PR fortran/17711
> 	* gfortran.dg/operator_4.f90: New test.
> 	* gfortran.dg/operator_5.f90: New test.
> 	* gfortran.dg/module_md5_1.f90: Adjusted MD5 sum due to
> 	increased number of operators in module files.

Forgot to attach the testsuite changes.
Here they are.
Attachment (pr17711-testsuite.patch): text/x-diff, 5141 bytes
Permalink | Reply | 0 comments |
headers
Jerry DeLisle | 1 Jul 17:02
Picon

Re: Fortran regressions

Paul Thomas wrote:
> Steve,
> 
> If it's any help to those searching, I tried to do a commit from my 
> hotel on Thursday evening.  I updated my tree and this version was 
> perfectly viable.  By yesterday lunchtime, I was in a position to update 
> again, by which time the regressions had appeared.
> 
> I am sorry that I am not in a position to help - I am on the road again 
> in an hour and still have a pile of shirts to iron :-(
> 
> Paul
> 
> 
The problem has been found and a fix sent to Steve and myself.  It works. 
DannyB said he would commit soon after he got some rest.  It was very late in 
his time zone.

Jerry
Permalink | Reply | 0 comments |
headers
Jerry DeLisle | 1 Jul 17:06
Picon

Re: [patch, libgfortran][4.3 regression] PR32554 Bug in P formatting

Janne Blomqvist wrote:
> Jerry DeLisle wrote:
>> :ADDPATCH fortran:
>>
>> Hi all,
>>
>> The initial problem here is that gfortran was truncating by one with 
>> snprintf and overflowing the buffer by one with sprintf.  Surprising 
>> we were not getting an error before enabling snprintf.  Using snprintf 
>> uncovered this latent bug.
>>
>> Investigating further I found that the problem could be avoided by 
>> adjusting the calculation of the the number of digits, ndigits.  I 
>> simply reduced this by one.  However, examining the buffer after the 
>> calls to snprintf showed that the width was varying because the number 
>> of exponent digits, edigits, varied.
>>
>> Exploring this, I tried fixing the size of edigits to see what 
>> happens.  I discovered that edigits does not need to be calculated at 
>> all.  If it is set to the largest expected size (4) snprintf (and 
>> sprintf) conveniently pads blanks at the end anyway.  (The exponent is 
>> read back in downstream by atoi)
>>
>> The result is seriously simplified code which should yield better 
>> performance.
>>
>> Regression tested on x86-64-pc-Gnu/Linux.
>>
>> Also NIST tested.
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jerry DeLisle | 1 Jul 18:00
Picon

Simple benchmark results

Here are timings for before an after the patch to PR32554: Average of five runs 
in seconds

	g77	gfc42	gfc	ifort

	1.086	2.350	2.197	2.995	
	1.202	2.367	2.199	2.936	
	1.081	2.350	2.304	2.921	
	1.097	2.372	2.205	2.956	
	1.081	2.363	2.215	3.008

Avg>>>	1.109	2.360	2.224	2.963	

Simple test:

       program main
       open(10)
       a = 0.3858204
       do i=1,500000
          a = a + 0.4761748164
          write(10, '(G12.5)') a
       end do
       end
Permalink | Reply | 0 comments |
headers
Paul Thomas | 1 Jul 12:40
Picon

Re: Fortran regressions

Steve and Brooks,

 From my notes about my failed commit (connection problems), my 
successful commit yesterday and a regressing update about an hour later, 
I deduced the following:

There are two regressions:

(i) The earlier one:

/svn/trunk/gcc/testsuite/gfortran.fortran-torture/compile/pr32417.f90:5: 
internal compiler error: in build2_stat, at tree.c:3074

although this goes away without optimisation, it predates whatever 
happened after my commit;

(ii) after r126147 (my last commit), the other regressions creep in.  
These are run time failures at any level of optimization; eg 
equiv_7.f90, hollerith.f90, hollerith_4.f90.  I have checked this by 
reverting to r126147.

All this is on Cygwin_NT/amd64

Got to rush

Paul
Permalink | Reply | 6 comments |

Gmane