headers
Thomas Koenig | 1 Nov 11:33
Picon
Favicon

Re: [Patch, fortran] PR37159

On Thu, 2008-10-30 at 11:54 +0100, Dennis Wassel wrote:
> Hi list,
> 
> the FSF guys have just sent me the countersigned copyright assignment,
> so: *ping*
> The patch has been accepted by Thomas Koenig on 2008-09-18. Good to go?

Hello Dennis,

I have committed your patch as rev. 141511.  Thanks a lot!

I didn't close the PR yet, because of the check for GET
that Tobias mentioned in
http://gcc.gnu.org/ml/fortran/2008-10/msg00281.html

For your question about Bugzilla and commit privileges:  See
http://gcc.gnu.org/svnwrite.html .  Once you have a gcc.gnu.org
account, you can also manipulate Bugzilla.  It may be a good
idea to wait with that until you have gained a bit more of experience.

Again, congratulations, welcome aboard and happy hacking!

	Thomas
Permalink | Reply | 0 comments |
headers
Paul Thomas | 1 Nov 12:25
Picon

Re: [Patch, Fortran] PR 36322/36463

Steve,
> Most of the test cases that I wrote have no attribution.  Others
> simply point to the PR.  In your case, for codes derived from
> James' code, you can do
>
> ! Original code provided by James van Buskirk.
> ! Reduced testcase contributed by Tobias Burnus.
>
> or some such attribution if you can determine the lineage.
>
>   
Indeed - my main point was to give some credit to reporters since it 
helps us so much.

I have to confess to a more than faint irritation at folk that cannot be 
troubled to make a Bugzilla report and do wonder about crediting them.  
That said, clf is the source for many of the more fundamental PRs and we 
get some return in respect of help on standards issues.  All in all I 
tend to the side of encouragement.

One thing that cannot be an incentive to reporters is the huge number of 
UNCOs; 84 against fortran and libgfortran.  Whilst 377 PRs in total is a 
heck of a lot, that we *apparently* have not looked at a lot of them is 
something to put right when stage-3 is over.

Cheers

Paul
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Thomas | 1 Nov 13:28
Picon

GCC 4.4.0 Status Report (2008-11-01)

For those that do not follow the gcc list.
Note exceptions described in the second paragraph below - let's continue 
the campaign :-)
Cheers
Paul

Status
======

The two months of Stage 3 have ended and the trunk is now in regression
and documentation fixes only mode.

At this point bugfixing should concentrate on getting the list of serious
regressions down to a level that makes GCC 4.4 ready to release.
As an exception to this we will still have the old register allocator
removed before we branch for the GCC 4.4.0 release. As usual
maintainers may consider fixing serious bugs such as rejection of
valid code or wrong-code bugs appropriate even if they are not regressions.

The two quality metrics you know from the past still apply. We will
consider releasing GCC 4.4.0 once the number of serious regressions
is below 100 and no more P1 regressions remain. Only after releasing
GCC 4.4.0 we will branch and open Stage 1 for GCC 4.5 development.
Past experience tells us that we can expect this to happen not before
another two months pass, which would be early next year.

Quality Data
============

Priority # Change from Last Report
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Thomas | 1 Nov 13:48
Picon

Re: [Patch, Fortran] PR fortran/35681: First part, fix ELEMENTAL dependency handling for MVBITS

Daniel,

Regtests fine on FC9/x86_i64.  This is OK for trunk.

Have you had any thoughts on parentheses expressions yet?

Thanks for the patch

Paul
> Hi,
>
> I've updated the patch described below to trunk of now (including the 
> trivial conflicts merge with Mikael's recent check-in) and run a new 
> regtest, no regressions on GNU/Linux-x86-32.
>
> Cheers,
> Daniel
>
> Daniel Kraft wrote:
>> working on PR fortran/35681, I've got some rather big patch now 
>> handling part of the problem.  What it exactly does:
>>
>> 1) Some tab-indentation formatting fixes as I came along, sorry for 
>> those.  I hope it is ok so.
>>
>> 2) When resolving a MVBITS intrinsic call, the code->resolved_sym 
>> gets a dummy formal argument list with the correct INTENTs specified; 
>> this is needed later for gfc_conv_elemental_dependencies.
>>
>> 3) gfc_code got a new member "resolved_isym" that tracks calls to
(Continue reading)

Permalink | Reply | 2 comments |
headers
Janus Weil | 1 Nov 14:27

Re: [Patch, Fortran] PR 36322/36463

> This looks OK for trunk, subject a remark being resolved according
> unto conscience:

Committed as r141515, including a mention of James van Buskirk as the
original author in proc_decl_17.f90.

Cheers,
Janus
Permalink | Reply | 0 comments |
headers
Daniel Kraft | 1 Nov 14:35
Picon

Re: [Patch, Fortran] PR fortran/35681: First part, fix ELEMENTAL dependency handling for MVBITS

Paul Thomas wrote:
> Daniel,
> 
> Regtests fine on FC9/x86_i64.  This is OK for trunk.

Committed as rev 141516.  Seems Janus did commit exactly the same time 
:D  Thanks for the review Paul!

> Have you had any thoughts on parentheses expressions yet?

Only very little...  I'll comment on this from my point of view soon in 
a new post.

Cheers,
Daniel

> Thanks for the patch
> 
> Paul
>> Hi,
>>
>> I've updated the patch described below to trunk of now (including the 
>> trivial conflicts merge with Mikael's recent check-in) and run a new 
>> regtest, no regressions on GNU/Linux-x86-32.
>>
>> Cheers,
>> Daniel
>>
>> Daniel Kraft wrote:
>>> working on PR fortran/35681, I've got some rather big patch now
(Continue reading)

Permalink | Reply | 0 comments |
headers
Janus Weil | 1 Nov 20:54

[Patch, Fortran] PR 36426

Hi all,

here is a small patch which fixes PR36426. I know that Stage 3
officially ended today, but I hope that this patch can still go in.
It's really small and more like an addition/correction to the patch
for PR 36322/36463 that I just committed today. Testing for
regressions right now.

About comment #0 in the PR: I'm assuming that a statement like

   character(len=len(x)) :: x

is invalid, since the symbol x is used in it's own declaration. Can
someone confirm that? This line gives the somewhat strange error
message:

   character(len=len(x)) :: x
                            1
Error: Symbol 'x' at (1) already has basic type of REAL

Using "implicit none" the error transforms into

   character(len=len(x)) :: x
                    1
Error: Symbol 'x' is used before it is typed at (1)

which is much clearer.

Cheers,
Janus
(Continue reading)

Permalink | Reply | 2 comments |
headers
Daniel Kraft | 1 Nov 21:15
Picon

Re: [Patch, Fortran] PR 36426

Hi Janus,

Janus Weil wrote:
> About comment #0 in the PR: I'm assuming that a statement like
> 
>    character(len=len(x)) :: x
> 
> is invalid, since the symbol x is used in it's own declaration. Can
> someone confirm that? This line gives the somewhat strange error
> message:
> 
>    character(len=len(x)) :: x
>                             1
> Error: Symbol 'x' at (1) already has basic type of REAL
> 
> Using "implicit none" the error transforms into
> 
>    character(len=len(x)) :: x
>                     1
> Error: Symbol 'x' is used before it is typed at (1)
>
> which is much clearer.

this is a fix I did some months ago.  The basic type REAL stems from the 
fact that x is implicitelly typed (and thus REAL) once it is used in the 
LEN call.

I hope the error is at least somewhat clear and ok this way, but I don't 
know how to make it better for implicit typing.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Franke | 1 Nov 21:13
Picon

Re: [Patch, Fortran] PR 36426

On Saturday 01 November 2008 20:54:29 Janus Weil wrote:
> About comment #0 in the PR: I'm assuming that a statement like
>
>    character(len=len(x)) :: x
>
> is invalid, since the symbol x is used in it's own declaration. Can
> someone confirm that? 

See also: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35040
Permalink | Reply | 0 comments |
headers
Tobias Burnus | 1 Nov 21:58
Picon

Re: [Patch, Fortran] PR 36426

Hi Janus,

> here is a small patch which fixes PR36426.

> About comment #0 in the PR: I'm assuming that a statement like
>   character(len=len(x)) :: x
> is invalid, 

Yes, as Daniel has already mentioned; see:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32095

> Testing for regressions right now.
OK - when the testing suceeds.

By the way, since a week or so one can use
  "make -j2 check-gfortran"
(or -j<n>) which speeds up regtesting if one has a
multi-core/multi-cpu sytem.

Tobias
Permalink | Reply | 4 comments |

Gmane