headers
Thomas Koenig | 1 Dec 08:18
Picon
Favicon

Re: [patch, fortran] Fix PR 42131, improvement in do loops

On Mon, 2009-11-30 at 14:08 -0800, Richard Henderson wrote:
> On 11/30/2009 11:22 AM, Thomas Koenig wrote:
> > P.S: Richard, if you have a suggestion along the lines of what
> > you proposed in http://gcc.gnu.org/bugzilla/process_bug.cgi#c22 ,
> > please don't hesitate to say so.
> 
> Richi had meant
> 
>    step_sign = fold_build3 (COND_EXPR, type,
> 		fold_build2 (LT_EXPR, boolean_type_node, step,
> 			     build_int_cst (type, 0)),
>                  build_int_cst (type, -1), build_int_cst (type, 1));
> 
> I.e. "step_size = (step < 0 ? -1 : 1)".

That would have worked as well, also for folding, I see.  I am a bit
surprised because the version with the if didn't work.

If anybody shows that this version is better than what I committed, this
is a trivial enough change that can be done easily.

	Thomas
Permalink | Reply | 5 comments |
headers
Paul Richard Thomas | 1 Dec 09:04
Picon

Re: [Patch, Fortran] OOP: merging fortran-dev to trunk?

Dear Janus,

> Thanks everybody, but first and foremost: Thanks Paul, for
> constructing a great OOP implementation for gfortran! (He really was
> the one who did all the conceptual design and constructed the most
> important pieces, while I mostly just did the peasant work ;)

Even in the dictatorship of the proletariat, the peasants do all the
hard work :-)

> Looking forward to an OOP-complete gfortran 4.6,

Yes, me too.  It is my intention to find and fix that irritating bug
in generic procedures, to do some cleaning up and to document this
patch before moving on to more pressing things.  I will try to prevent
bit rot from setting in and to add the improvements that we have
learned about from this effort; most notably in the layout and
handling of vtables in gfortran.

BTW As of this morning fortran-dev appears to be completely broken.
I did not have time to investigate but let me just say that starting
with a clean tree the passes were in the low hundreds ***sigh***

Paul
Permalink | Reply | 1 comment |
headers
Paul Richard Thomas | 1 Dec 09:06
Picon

Re: [Patch, Fortran] PR 41177: Some corrections on base-object checks with type-bound procedures.

Daniel,

Since this improves the firewall between OOP and f95, I think that
this patch should be applied to trunk.  The fact that it fixes a bug
as well is a bonus!

Paul

On Mon, Nov 30, 2009 at 3:05 PM, Daniel Kraft <d <at> domob.eu> wrote:
> Daniel Kraft wrote:
>>
>> Hi all,
>>
>> this patch is some take in the direction of PR 41177.  It adds checks that
>> the passed-object dummy argument of a type-bound procedure must be scalar,
>> non-POINTER and non-ALLOCATABLE which is at the moment simply overlooked
>> (thus there's some accepts-invalid here which gets fixed).
>>
>> On the other hand, the actual base-objects in calls were checked to be
>> scalar which is wrong.  This is only required when calling NOPASS
>> procedures; I did correct this.  However, there turned unfortunatly an ICE
>> up when translating such calls for non-scalar base object, thus PR 41177 is
>> not fully fixed and I added an additional check with a "not implemented"
>> message to catch up in that case until the ICE gets fixed, too.
>>
>> Still I would like to commit this patch as it is right now and think this
>> will be already some step in the right direction.
>>
>> Unfortunatly, the POINTER attribute on CLASS dummies gets always set in
>> decl.c:encapsulate_class_symbol; I thus had to introduce a new flag storing
(Continue reading)

Permalink | Reply | 6 comments |
headers
Paul Richard Thomas | 1 Dec 09:18
Picon

Re: [Patch, Fortran] PR 41177: Some corrections on base-object checks with type-bound procedures.

Dear All,

> Since this improves the firewall between OOP and f95, I think that
> this patch should be applied to trunk.  The fact that it fixes a bug
> as well is a bonus!

Hmmm!  I have become so used to typebound procedures that I think of
them as f95 :-)

You know what I mean!

Paul
Permalink | Reply | 0 comments |
headers
Janus Weil | 1 Dec 09:34
Picon
Favicon
Gravatar

Re: [Patch, Fortran] OOP: merging fortran-dev to trunk?

Paul,

> BTW As of this morning fortran-dev appears to be completely broken.
> I did not have time to investigate but let me just say that starting
> with a clean tree the passes were in the low hundreds ***sigh***

that's funny. There should not have happened anything dramatic on the
branch (the last commit was Tobi's merge from trunk yesterday). My
merging *to* the trunk has not done anything to the branch itself ...

Cheers,
Janus
Permalink | Reply | 0 comments |
headers
Richard Guenther | 1 Dec 12:41
Picon

Re: [Patch, Fortran] PR 41177: Some corrections on base-object checks with type-bound procedures.

On Tue, Dec 1, 2009 at 12:40 PM, Paul Richard Thomas
<paul.richard.thomas <at> gmail.com> wrote:
> Daniel,
>
>> So is this an ok?
>
> It's an OK from me, I am just aware that at this stage, you should
> seek a "green" from the release manager(s).

Fortran is not release critical, so we defer to fortran maintainers.

Richard.
Permalink | Reply | 1 comment |
headers
Tobias Burnus | 1 Dec 14:04
Picon

[wwwdocs] Update Fortran entry at gcc-4.5/changes.html

Hi all,

I plan to commit the following patch in a day or so. It adds a link to
http://gcc.gnu.org/wiki/OOP and it removed the last two words from the
OOP item as those are working now.

Tobias

Index: changes.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.5/changes.html,v
retrieving revision 1.52
diff -u -r1.52 changes.html
--- changes.html        29 Nov 2009 10:46:18 -0000      1.52
+++ changes.html        1 Dec 2009 13:01:01 -0000
@@ -355,11 +355,11 @@
        pointer with <code>PASS</code> attribute now have to use
        <code>CLASS</code> in line with the Fortran 2003 standard; the
        workaround to use <code>TYPE</code> is no longer supported.</li>
-       <li>Experimental, incomplete support for polymorphism, including
-       <code>CLASS</code> (as allocatable or dummy), <code>SELECT
TYPE</code>
-       and dynamic dispatch of type-bound procedure calls. Some features do
-       not work yet such as unlimited polymorphism (<code>CODE(*)</code>),
-       <code>CLASS IS</code>, <code>EXTENDS_TYPE_OF</code>.</li>
+       <li><a href="http://gcc.gnu.org/wiki/OOP">Experimental, incomplete
+       support for polymorphism</a>, including <code>CLASS</code> (as
+       allocatable or dummy), <code>SELECT TYPE</code> and dynamic dispatch
+       of type-bound procedure calls. Some features do not work yet such as
+       unlimited polymorphism (<code>CODE(*)</code>).</li>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jerry DeLisle | 1 Dec 14:51
Picon

Re: [patch, fortran] Fix PR 42131, improvement in do loops

On 11/30/2009 11:18 PM, Thomas Koenig wrote:
> On Mon, 2009-11-30 at 14:08 -0800, Richard Henderson wrote:
>> On 11/30/2009 11:22 AM, Thomas Koenig wrote:
>>> P.S: Richard, if you have a suggestion along the lines of what
>>> you proposed in http://gcc.gnu.org/bugzilla/process_bug.cgi#c22 ,
>>> please don't hesitate to say so.
>>
>> Richi had meant
>>
>>     step_sign = fold_build3 (COND_EXPR, type,
>> 		fold_build2 (LT_EXPR, boolean_type_node, step,
>> 			     build_int_cst (type, 0)),
>>                   build_int_cst (type, -1), build_int_cst (type, 1));
>>
>> I.e. "step_size = (step<  0 ? -1 : 1)".
>
> That would have worked as well, also for folding, I see.  I am a bit
> surprised because the version with the if didn't work.
>
> If anybody shows that this version is better than what I committed, this
> is a trivial enough change that can be done easily.
>
> 	Thomas
>
>
Thomas, you are approved to change this on trunk.  It does seem cleaner, simpler.

Jerry
(Continue reading)

Permalink | Reply | 3 comments |
headers
Janne Blomqvist | 1 Dec 18:01
Picon

Re: [patch, fortran] Fix PR 42131, improvement in do loops

On Tue, Dec 1, 2009 at 15:51, Jerry DeLisle <jvdelisle <at> verizon.net> wrote:
> On 11/30/2009 11:18 PM, Thomas Koenig wrote:
>>
>> On Mon, 2009-11-30 at 14:08 -0800, Richard Henderson wrote:
>>>
>>> On 11/30/2009 11:22 AM, Thomas Koenig wrote:
>>>>
>>>> P.S: Richard, if you have a suggestion along the lines of what
>>>> you proposed in http://gcc.gnu.org/bugzilla/process_bug.cgi#c22 ,
>>>> please don't hesitate to say so.
>>>
>>> Richi had meant
>>>
>>>    step_sign = fold_build3 (COND_EXPR, type,
>>>                fold_build2 (LT_EXPR, boolean_type_node, step,
>>>                             build_int_cst (type, 0)),
>>>                  build_int_cst (type, -1), build_int_cst (type, 1));
>>>
>>> I.e. "step_size = (step<  0 ? -1 : 1)".
>>
>> That would have worked as well, also for folding, I see.  I am a bit
>> surprised because the version with the if didn't work.
>>
>> If anybody shows that this version is better than what I committed, this
>> is a trivial enough change that can be done easily.
>>
>>        Thomas
>>
>>
> Thomas, you are approved to change this on trunk.  It does seem cleaner,
(Continue reading)

Permalink | Reply | 2 comments |
headers
Janne Blomqvist | 1 Dec 19:38
Picon

Fwd: [Patch, libfortran] PR 40812 Large file support on MinGW

Hi,

this accidentally went to gcc@ instead of fortran@..

---------- Forwarded message ----------
From: Janne Blomqvist <blomqvist.janne <at> gmail.com>
Date: Tue, Dec 1, 2009 at 20:18
Subject: [Patch, libfortran] PR 40812 Large file support on MinGW
To: gcc mailing list <gcc <at> gcc.gnu.org>, GCC Patches <gcc-patches <at> gcc.gnu.org>

Hi,

the attached patch should make gfortran support > 2 GB files on MinGW.
I don't have a windows installation to test on, so I don't know if
this works or not. Though I regtested on x86_64-unknown-linux-gnu to
make sure that non-MinGW targets didn't change (it's all behind
#ifdefs, but just to be sure).

Another caveat is that it uses features from the Win32 API that
according to MSDN are available only as of w2k and newer, so with this
patch we effectively drop support for pre-w2k targets on MinGW. I
don't know if anybody cares about such platforms any longer, if so
maybe the interested party could step up to the plate and contribute
some configure checks or somesuch so that we could fall back to the
old ftruncate or chsize functions?

Ok for trunk?

2009-12-01  Janne Blomqvist  <jb <at> gcc.gnu.org>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane