headers
Feng Wang | 1 Mar 2005 01:52
Picon
Favicon

Re: [fortran, patch] Patch for PR18827

 --- Steve Kargl <sgk <at> troutmask.apl.washington.edu> 的正文：
> Feng,
> 
> I have been given commit and approval status and I still
> have several patches waiting for approval.  There was/is
> a fairly large backlog of patches and we are trying are 
> best to reduce the number.  The recent branching for 
> 4.0 shot my weekend, which is essentially the only time
> I have to work on gfortran issues.  If no one picks
> up your patch, I look it over this weekend.  Please, note
> that this is in an area of the compiler that I don't
> know too well, so there will be a small amount of 
> background reading.
> 
Thanks for your responding. This make me not feel too lonely. 

Best Regards,
Feng Wang

_________________________________________________________
Do You Yahoo!?
150万曲MP3疯狂搜，带您闯入音乐殿堂
http://music.yisou.com/
美女明星应有尽有，搜遍美图、艳图和酷图
http://image.yisou.com
1G就是1000兆，雅虎电邮自助扩容！
http://cn.rd.yahoo.com/mail_cn/tag/1g/*http://cn.mail.yahoo.com/event/mail_1g/
Permalink | Reply | 2 comments |
headers
Feng Wang | 1 Mar 2005 02:55
Picon
Favicon

Re: consequence of 4.0 release branch?

 --- Toon Moene <toon <at> moene.indiv.nluug.nl> ģ
> Franois-Xavier Coudert wrote:
> 
> >>> What does this mean for testing patches?  Does a fortran patch
> >>> require testing for both mainline and the release branch?  I'll
> >>
> >> Yes, this is how it's supposed to work for all patches.
> > 
> > I don't know how I feel about that. We're having trouble keeping a 
> > minimum speed in fixing gfortran bugs. Basically, double testing will 
> > mean greatly diminishing the number of bugs that will get fixed in a 
> > given amount of time.
> 
> Be careful.  You look at the problem from the point of view of someone 
> who recently joined the bug-fixing crowd.  In a month's time, the 4.0 
> branch will be *very* different from mainline.  It might be that patches

IMHO, we fortran gangs should also have different policies for the two
different branches. We all know gfortran is still far far away from being
release status (In fact, it seems that nobody considered how and when to reach
this status, we just do our best). Gfortran is still in development status, and
we should have more flexible policies ourselves rather than GCC 4.0 release
policies. 

I think we can first apply patches to mainline (the development branch) and
merge to GCC4.0 release branch once a month (or another period). This can
decrease much approval time of reviewers and speed up the development of
gfortran.

> to the front end still apply cleanly, but they might have different
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kamaraju Kusumanchi | 1 Mar 2005 03:59
Picon

Re: Fortran runtime error: End of record

> > Another nitpick. How did you test my code? With the 20050227 version, if I do
> >
> > $./a.out
> >
> > then it works fine.
> 
> Okay, this is the way I test it.
> 
> > But If I do
> >
> > $./a.out > temp
> > At line 11 of file explore.f90
> > Fortran runtime error: End of record
> >
> 
> I see this also.  So, when the output is redirected, we
> apparently aren't flushing the buffer or emitting an
> EOF.  Can you submit a bug report?
> 

Thanks for the confirmation steve. 

A bug repor thas been submitted for this problem. For details please see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20257

Hopefully someone will fix this soon.

raju

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Canqun Yang | 1 Mar 2005 04:18
Picon

Re: GIV optimizations

Hi, Gr.Steven

Very thanks for your replyment.

Induction variables are variables whose successive 
values form an arithmetic progression over a loop. 
Induction variables are often divided into bivs (basic 
induction variables), which are explicitly modified by 
the same constant amount during each iteration of a 
loop, and gives (general induction variables), which 
may be modified or computed by a linear-function of a 
basic induction variable. 

There are three important transformations that apply 
to them: strength reduction, induction-variable 
removal, and linear-function test replacement. For 
example, we can do strength reduction of address givs 
which are usually used for address calculation of 
array elements. On platforms with post-increment load 
and store instructions, this will make chance to 
combine a load/store with the following address 
calculation instruction.

Also the induction variable splitting is an effective 
optimization during loop unrolling.

The new loop optimizer only support a limited gives 
analysis (ref. loop-iv.c), and has not yet implemented 
giv splitting (ref. ¡®loop-unroll.c¡¯, 
¡®analyze_iv_to_split_insn¡¯, and comments in this
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Pinski | 1 Mar 2005 04:08
Picon

Re: GIV optimizations


On Feb 28, 2005, at 10:18 PM, Canqun Yang wrote:

> Giv optimizations are just features which not
> implemented yet in the new loop unroller, so I think
> put it in bugzilla is not appropriate.

Bugzilla should be used more than just normal bugs but
also enhancements.

> I test 171.swim on IA64 system with 1GHz itanium2 CPU.

Note you with -ftree-loop-linear you will most likely get
better performance out of swim than another other
optimization that is normally done as one of the loops in
swim is really reversed in transversing the array.

-- Pinski
Permalink | Reply | 0 comments |
headers
Steve Kargl | 1 Mar 2005 05:48
Picon

Re: [patch, gfortran] Implement some more g77 intrinsics

On Tue, Feb 01, 2005 at 12:22:15AM +0100, Fran?ois-Xavier Coudert wrote:
> Since this is my first patch, I hope I did it right. Attached is the 
> diff and the new files to be included.
> 
> As I did not yet receive the paperwork for copyright assignment, I 
> hereby donate this code to the Free Software Fundation, and I hope it is 
> enough.
> 
> 
> 2005-01-31  Fran?ois-Xavier Coudert <coudert <at> clipper.ens.fr>
> 
> 	Implement more g77 intrinsic functions and subroutines.
> 	* chdir.c, gerror.c, getlog.c, hostnm.c, ierrno.c, kill.c,
> 	link.c, perror.c, rename.c, sleep.c, symlnk.c, time.c: implement
> 	intrinsics themselves.
> 
> 	* gcc/fortran/check.c, gcc/fortran/gfortran.h,
> 	gcc/fortran/intrinsic.c, gcc/fortran/intrinsic.h,
> 	gcc/fortran/iresolve.c, gcc/fortran/trans-intrinsic.c,
> 	libgfortran/Makefile.am, libgfortran/configure.ac:
> 
> 	* gcc/fortran/invoke.texi: corrected typos.

FX,

I should have time this weekend to look this patch over.
I also know that your paperwork is somewhere between 
you and the FSF.  Do you have an up to date patch
and can you generate the patch with "diff -u"?  Oh, 
and please send me any test programs your wrote.  It
(Continue reading)

Permalink | Reply | 2 comments |
headers
Steve Kargl | 1 Mar 2005 06:20
Picon

notes on gfortran internals?

Does anyone have any notes on gfortran internals?
This includes understanding simple data structures
to the more arcane internals on modules and derives
types.  I can probably flesh out the how, what,
where and why of the expression node and adding a
new intrinsic procedure to gfortran, but modules,
derived types, and partically the entire backend
is opaque.  I'm willing to collate the info into
some form of document, but will probably need some
help with texinfo markup.

PS:  I'm starting to write up the intrinsic procedures
that we support in gfortran.  I have a complete list
of intrinsics up to this past weekend.  The document
will be in alphabetical order for all intrinsic names
and will be something along the lines:

ABS -- Absolute Value

  Class: F95

  Generic intrinsic function: ABS(X)
     where X is INTEGER(KIND=*), REAL(KIND=*), or COMPLEX(kind=*) and
     ABS(X) returns INTEGER(KIND=*) or REAL(KIND=*) depending on the
     type and kind of X.

  Specific intrinsic functions:
     ABS(X) -- yada yada
    DABS(X) -- yada yada
    IABS(X) -- yada yada
(Continue reading)

Permalink | Reply | 4 comments |
headers
FX Coudert | 1 Mar 2005 07:29
Picon
Picon

Re: [patch, gfortran] Implement some more g77 intrinsics

> I should have time this weekend to look this patch over.
> I also know that your paperwork is somewhere between 
> you and the FSF.

I will go out of town from Friday to next Sunday, and I planned to ping 
all previously posted patches before that. For each, I will correct 
beginner's errors (non-ASCII Changelog entries, wrong-format diffs, test 
programs).

Thanks for your help,
FX
Permalink | Reply | 0 comments |
headers
FX Coudert | 1 Mar 2005 07:32
Picon
Picon

Re: notes on gfortran internals?

> PS:  I'm starting to write up the intrinsic procedures
> that we support in gfortran.  I have a complete list
> of intrinsics up to this past weekend.  The document
> will be in alphabetical order for all intrinsic names
> and will be something along the lines:

That will be really cool!

> I will of course consult the Fortran 2003 standard (the only 
> doc I have) and M&R.

Do you want a copy of the F95 draft? (not difficult to find, however) I 
think F95 is much easier to read that F2003 (and it's about twice smaller!)

FX
Permalink | Reply | 3 comments |
headers
Steve Kargl | 1 Mar 2005 07:41
Picon

Re: notes on gfortran internals?

On Tue, Mar 01, 2005 at 07:32:31AM +0100, FX Coudert wrote:
> >PS:  I'm starting to write up the intrinsic procedures
> >that we support in gfortran.  I have a complete list
> >of intrinsics up to this past weekend.  The document
> >will be in alphabetical order for all intrinsic names
> >and will be something along the lines:
> 
> That will be really cool!
> 
> >I will of course consult the Fortran 2003 standard (the only 
> >doc I have) and M&R.
> 
> Do you want a copy of the F95 draft? (not difficult to find, however) I 
> think F95 is much easier to read that F2003 (and it's about twice smaller!)
> 

I have a copy of the Final Committee Draft of the Fortran
2003 standard.  From a c.l.f post by Richard Maine, the
editor of F2003, I infer that the Fortran 2003 standard
and the Final Committee Draft are almost identical.  I
also have the F66 and F77 standards.  I do not have, nor
will I pay for, the actuall f95 standard.

--

-- 
Steve
Permalink | Reply | 1 comment |

Gmane