[tree-ssa] Integrating g95

[tree-ssa] Integrating g95

[Paul Brook]

I there anything I still need to do before we can put g95 in the tree-ssa 
branch?

Technically speaking I don't think there are any problems. It's just a case 
of dropping into the source tree and a small patch to tell the build system 
about the target library.

The main purpose of this email is to chek for any non-technical 
(political/legal) issues which may prevent integration. All copyright has 
been assigned to the FSF under the "G95" project.

Assuming ot objections are raised, where should I send the changes?
Would you prefer a tarball and small patch, or just a huge patch?

The code comitted would be identical to that at 
http://gcc-g95.sourceforge.net
In the short-medium term we would probably still maintain the seperate 
external source tree for our convenience, with frequent resyncs between the 
two.

Paul Brook

Re: [tree-ssa] Integrating g95

[Joseph S. Myers]

On Sat, 31 May 2003, Paul Brook wrote:

> Technically speaking I don't think there are any problems. It's just a case 
> of dropping into the source tree and a small patch to tell the build system 
> about the target library.

Just remember that this will mean that the whole front end checklist
<http://gcc.gnu.org/onlinedocs/gccint/Front-End.html> will need to be
satisfied when tree-ssa is merged to mainline.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: [tree-ssa] Integrating g95

[Toon Moene]

Joseph S. Myers wrote:

> On Sat, 31 May 2003, Paul Brook wrote:

>>Technically speaking I don't think there are any problems. It's just a case 
>>of dropping into the source tree and a small patch to tell the build system 
>>about the target library.
> 
> Just remember that this will mean that the whole front end checklist
> <http://gcc.gnu.org/onlinedocs/gccint/Front-End.html> will need to be
> satisfied when tree-ssa is merged to mainline.

Hmmm, now that I'm reading it - this page excessively talks about "the 
GNATS database".  Gerald ?

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc-g95.sourceforge.net/ (under construction)

Re: [tree-ssa] Integrating g95

[Steven Bosscher]

Joseph S. Myers wrote:

>On Sat, 31 May 2003, Paul Brook wrote:
>
>  
>
>>Technically speaking I don't think there are any problems. It's just a case 
>>of dropping into the source tree and a small patch to tell the build system 
>>about the target library.
>>    
>>
>
>Just remember that this will mean that the whole front end checklist
><http://gcc.gnu.org/onlinedocs/gccint/Front-End.html> will need to be
>satisfied when tree-ssa is merged to mainline.
>
>  
>
We'll make sure we do so, then.  Thanks for the link.

Gr.
Steven

Re: [tree-ssa] Integrating g95

[Diego Novillo]

On Sat, 2003-05-31 at 17:48, Paul Brook wrote:

> Technically speaking I don't think there are any problems. It's just a case 
> of dropping into the source tree and a small patch to tell the build system 
> about the target library.
> 
Agreed.  It will be good having g95 in GCC at last.

> Assuming ot objections are raised, where should I send the changes?
> Would you prefer a tarball and small patch, or just a huge patch?
> 
The patch is probably going to be large for mail.  A link to it should
be enough.

> The code comitted would be identical to that at 
> http://gcc-g95.sourceforge.net
> In the short-medium term we would probably still maintain the seperate 
> external source tree for our convenience, with frequent resyncs between the 
> two.
> 
Hmm, I'm not sure about this.  If we are going to move it, I think it
might be best to make the switch at once.  Why do you think it would be
more convenient to keep the two repositories?


Diego.

Re: [tree-ssa] Integrating g95

[Steven Bosscher]

Joseph S. Myers wrote:

>On Sun, 1 Jun 2003, Steven Bosscher wrote:
>  
>
>>    * At least one GNATS category for bugs in that front end and runtime 
>>libraries. This category needs to be mentioned in gcc/gccbug.in, and in 
>>gnats.html on the GCC web site, as well as being added to the GNATS 
>>database.
>>
>>TODO -- what would be the appropriate name?  We should avoid confusion 
>>so that our bugs don't end up in the category for g77.
>>    
>>
>
>Only relevant at this point if you want tree-ssa bug reports against G95
>to go into GCC Bugzilla.
>

I'm not sure.  It's not like we're in bug fix mode yet, more like 
complete-features-mode, so we should probably not clutter the gcc-bugs 
mainling list and database.  I removed this point from the list.

>>    * Normally, one or more maintainers of that front end listed in 
>>MAINTAINERS.
>>
>>Paul, Toon and myself (when I finally contribute some patch again myself 
>>:))?
>>    
>>
>
>This could always be done on the mainline MAINTAINERS - no need to branch
>that file.
>
OK

>>    * The front end's manuals should be mentioned in 
>>maintainer-scripts/update_web_docs (see Texinfo Manuals) and the online 
>>manuals should be linked to from onlinedocs/index.html.
>>
>>TODO -- but we do not have much of a manual yet.  I was actually kinda 
>>hoping Steven Kargl and maybe Katherine would like to help with that 
>>(hint :)), being native speakers with American spelling.  I plan to work 
>>on this as long as I'm unable to build gcc's on my "new" computer.
>>    
>>
>
>You can always make the changes to update_web_docs on the branch, it just
>isn't much use (and the checked out directory on gcc.gnu.org would still
>need updating manually when tree-ssa goes to mainline).
>
Let's not do it then until the merge.

>>    * Any old releases or CVS repositories of the front end, before its 
>>inclusion in GCC, should be made available on the GCC FTP site 
>>ftp://gcc.gnu.org/pub/gcc/old-releases/.
>>
>>This is something I suggest we do not.  We have our own CVS repository 
>>at SF, and we never had any official release, so no point IMHO.
>>    
>>
>
>The repository copies are so that the early history stays available (if
>e.g. the repository - once dead and all development is in GCC mainline -
>is removed by Sourceforge, or Sourceforge disappears).
>

We'll have to try and get a copy of the SF repository then...  They're 
said to be very cooperative with such things.

>>Check!!! -- mostly.
>>The gcc_release part is done with the gcc_config patch.  The snapshot-* 
>>is TODO.  But do we really want to mention g95 in there?  tree-ssa is 
>>unreleased, so there will be no snapshots that contain g95 for many 
>>months to come.  I suggest we skip the snapshot part of this point and 
>>just keep the gcc_release like we have now.
>>    
>>
>
>That's something you can do on the files on the branch, so the changes
>become relevant when it merges to mainline.
>
OK

The list I compiled is now in our SF repository:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/gcc-g95/gcc-g95/TODO-for-GCC?rev=1.1&content-type=text/vnd.viewcvs-markup
Let's make that list shorter :-)

Thanks,
Steven

Re: [G95] Re: [tree-ssa] Integrating g95

[Steven G. Kargl]

Steven Bosscher wrote:

>
> TODO -- but we do not have much of a manual yet.  I was actually kinda
> hoping Steven Kargl and maybe Katherine would like to help with that
> (hint :)), being native speakers with American spelling.  I plan to work
> on this as long as I'm unable to build gcc's on my "new" computer.
>
I can help edit and write parts of a manual, but I have very
limited time so being the primary manual writer is not an
option.  I also have zero experience with texinfo.

There is one other item to consider.  g95 requires GMP.
AFAIK, GCC does not use GMP.  What are the options?

-- 
steve

Re: [tree-ssa] Integrating g95

[law]

In message <1054421594.21692.437.camel@frodo.toronto.redhat.com>, Diego Novillo
 writes:
 >Hmm, I'm not sure about this.  If we are going to move it, I think it
 >might be best to make the switch at once.  Why do you think it would be
 >more convenient to keep the two repositories?
I'd strongly favor only having the code in one repository.  

jeff

Re: [G95] Re: [tree-ssa] Integrating g95

[law]

In message <3ED94B9C.3080203@attbi.com>, "Steven G. Kargl" writes:
 >Steven Bosscher wrote:
 >
 >>
 >> TODO -- but we do not have much of a manual yet.  I was actually kinda
 >> hoping Steven Kargl and maybe Katherine would like to help with that
 >> (hint :)), being native speakers with American spelling.  I plan to work
 >> on this as long as I'm unable to build gcc's on my "new" computer.
 >>
 >I can help edit and write parts of a manual, but I have very
 >limited time so being the primary manual writer is not an
 >option.  I also have zero experience with texinfo.
 >
 >There is one other item to consider.  g95 requires GMP.
 >AFAIK, GCC does not use GMP.  What are the options?
I suspect we'll have to find a way to either include GMP or at the least
link against it.  One more dependency in the build process.  Sigh.

At least as a first cut, configuring  could test for a suitable
installed GMP library and avoid enabling g95 if no suitable GMP
library is found.  I believe we do similar things with GNAT since
it needs GNAT to build.

[ I suspect asking the g95 folks to rewrite their code to avoid GMP
  probably isn't going to be well received :-) ]

jeff

Re: [G95] Re: [tree-ssa] Integrating g95

[Joseph S. Myers]

On Sat, 31 May 2003, Steven G. Kargl wrote:

> There is one other item to consider.  g95 requires GMP.
> AFAIK, GCC does not use GMP.  What are the options?

Using GMP/mpfr in the rest of GCC as well, so we can get correctly rounded
results for folding all the standard <math.h> and <complex.h> functions
for constant arguments without error-prone reimplementation.  
(Performance requires that the basic constant folding of arithmetic
operations use the internal GCC functions, and that we only convert in/out
of GMP form for folding the various functions.)  But I think doing this
might require GMP to be included in the GCC source tree, as zlib is, with
a --with-system-gmp to use the installed library, so short-term on the
tree-ssa branch it may be more sensible (and less controversial) simply to
make building g95 dependent on installed GMP.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: [G95] Re: [tree-ssa] Integrating g95

[Michael S. Zick]

On Saturday 31 May 2003 09:08 pm, law@redhat.com wrote:
>
> [ I suspect asking the g95 folks to rewrite their code to avoid GMP
>   probably isn't going to be well received :-) ]
>
> jeff
Yea - right after C is rewritten not to depend on libc.
I hereby grant my trophy for unpopular suggestions to jeff.
Mike

Re: [G95] Re: [tree-ssa] Integrating g95

[Daniel Berlin]

On Sunday, June 1, 2003, at 02:38  PM, Michael S. Zick wrote:

> On Saturday 31 May 2003 09:08 pm, law@redhat.com wrote:
>>
>> [ I suspect asking the g95 folks to rewrite their code to avoid GMP
>>   probably isn't going to be well received :-) ]
>>
>> jeff
> Yea - right after C is rewritten not to depend on libc.
> I hereby grant my trophy for unpopular suggestions to jeff.

Wasn't there discussion a while back about wanting to use GMP (or a 
subset) for doing host math anyway?
But it wasn't done because we didn't want to add another library 
requirement?
If G95 is going to need it, maybe we should just use it and be done 
with it?
Or am i remembering all this wrong?

> Mike

Re: [G95] Re: [tree-ssa] Integrating g95

[Neil Booth]

Daniel Berlin wrote:-

> 
> On Sunday, June 1, 2003, at 02:38  PM, Michael S. Zick wrote:
> 
> >On Saturday 31 May 2003 09:08 pm, law@redhat.com wrote:
> >>
> >>[ I suspect asking the g95 folks to rewrite their code to avoid GMP
> >>  probably isn't going to be well received :-) ]
> >>
> >>jeff
> >Yea - right after C is rewritten not to depend on libc.
> >I hereby grant my trophy for unpopular suggestions to jeff.
> 
> Wasn't there discussion a while back about wanting to use GMP (or a 
> subset) for doing host math anyway?
> But it wasn't done because we didn't want to add another library 
> requirement?
> If G95 is going to need it, maybe we should just use it and be done 
> with it?
> Or am i remembering all this wrong?

We've wanted to do something better than the double-integer kludges
for a while, but not to penalize the normal cases where single or
double-integer math is sufficient, so yes.

But it's a long, hard job and no-one's stepped up to the plate.

Neil.

Re: [G95] Re: [tree-ssa] Integrating g95

[Laurent GUERBY]

On Sun, 2003-06-01 at 20:59, Neil Booth wrote:
> We've wanted to do something better than the double-integer kludges
> for a while, but not to penalize the normal cases where single or
> double-integer math is sufficient, so yes.

Talking about performance, do people think that target arithmetic, if
done without particular care for performance, will be on the profiler
radar? 

Do we have way to measure / count how many target arithmetic operations
we do when compiling "typical" program? (Even approximatively
with a quick hack to add a few counters.)

Laurent

Re: [G95] Re: [tree-ssa] Integrating g95

[Paul Brook]

On Sunday 01 June 2003 3:08 am, law@redhat.com wrote:
> [ I suspect asking the g95 folks to rewrite their code to avoid GMP
>   probably isn't going to be well received :-) ]

We (g95 developers) have had discussions about this previously, but noone 
was able to come up with a good alternative solution.

Even GMP isn't ideal. The main limitation from our point of view is that 
AFAIK it is unable to represent NaN's.

It's also possible that GMP could give different answers compared to the 
target representation due to differing rounding errors. I haven'd looked 
too closely, so I guess this could be avided if you're careful.

Paul Brook

Re: [G95] Re: [tree-ssa] Integrating g95

[Steven Bosscher]

Paul Brook wrote:

>On Sunday 01 June 2003 3:08 am, law@redhat.com wrote:
>  
>
>>[ I suspect asking the g95 folks to rewrite their code to avoid GMP
>>  probably isn't going to be well received :-) ]
>>    
>>
>
>We (g95 developers) have had discussions about this previously, but noone 
>was able to come up with a good alternative solution.
>
>Even GMP isn't ideal. The main limitation from our point of view is that 
>AFAIK it is unable to represent NaN's.
>
>It's also possible that GMP could give different answers compared to the 
>target representation due to differing rounding errors. I haven'd looked 
>too closely, so I guess this could be avided if you're careful.
>
>Paul Brook
>
>  
>
GMP does not support NaN, Inf, signals and IEEE 754 rounding modes.  How 
wonderful then, that there is a replacement that does:
http://swox.com/gmp/mpfr/Introduction-to-MPFR.html#Introduction%20to%20MPFR

I was looking into moving g95 from GMP to MPFR recently (before my compu 
mishap).  It looks very doable; in fact we could just try it because 
there is a GMP compatibility header available.

I am not sure if this is an official GNU project, but the copyright is 
with the FSF.

If depending on GMP is really such a big deal, then we could collect the 
bits and pieces we really need and make our own libary.  Using GMP 
really is overkill, it provides far more than what we use in g95.

Gr.
Steven

Re: [tree-ssa] Integrating g95

[Gerald Pfeifer]

On Sun, 1 Jun 2003, Toon Moene wrote:
>> <http://gcc.gnu.org/onlinedocs/gccint/Front-End.html> will need to be
> Hmmm, now that I'm reading it - this page excessively talks about "the
> GNATS database".  Gerald ?

Wolfgang beat me to it on the weekend. ;-)  There is still a reference
to gnats.html, but before removing that reference, we need to decide the
fate of that web page (or how to integreate it's contents elsewhere).

Gerald
-- 
Gerald "Jerry"   pfeifer@dbai.tuwien.ac.at   http://www.pfeifer.com/gerald/

Re: [G95] Re: [tree-ssa] Integrating g95

[Mike Stump]

On Sunday, June 1, 2003, at 12:15 PM, Laurent GUERBY wrote:
> Talking about performance, do people think that target arithmetic, if
> done without particular care for performance, will be on the profiler
> radar?

Nope.

> Do we have way to measure / count how many target arithmetic operations
> we do when compiling "typical" program? (Even approximatively
> with a quick hack to add a few counters.)

Yes.  I suspect < 0.1%.  Make the compile 10x faster, and maybe, we 
might have to worry about it, wake me when we've done that.

[ I speak from numbers collected from the Finder_FE C++ compilation 
time benchmark I have, obviously everyone's experience will differ from 
mine. :-) ]

Re: [G95] Re: [tree-ssa] Integrating g95

[Geert Bosch]

On Sunday, Jun 1, 2003, at 15:15 America/New_York, Laurent GUERBY wrote:

> Do we have way to measure / count how many target arithmetic operations
> we do when compiling "typical" program?

The typical program doesn't really use floating-point at all. The issue
is with those few programs/libraries with tons of computation in it.
For Ada, there are some test cases that spend most of the compile time
doing high-precision arithmetic to compute constants for polynomial
approximations to functions.

Now of course, this is mostly because Ada requires calculations of
"static" expressions (subset of compile-time known expressions) to be
performed exactly.

However, if you are doing a lot of inlining and compile numerical code,
I wouldn't be surprised if you'd do a lot of target arithmetic and find
that for some programs the time required is significant.

   -Geert

Re: [G95] Re: [tree-ssa] Integrating g95

[Michael S. Zick]

On Tuesday 03 June 2003 07:40 am, Geert Bosch wrote:
> On Sunday, Jun 1, 2003, at 15:15 America/New_York, Laurent GUERBY wrote:
> > Do we have way to measure / count how many target arithmetic operations
> > we do when compiling "typical" program?
>
> The typical program doesn't really use floating-point at all. The issue
> is with those few programs/libraries with tons of computation in it.
> For Ada, there are some test cases that spend most of the compile time
> doing high-precision arithmetic to compute constants for polynomial
> approximations to functions.
>
> Now of course, this is mostly because Ada requires calculations of
> "static" expressions (subset of compile-time known expressions) to be
> performed exactly.
>
Ouch.
>
> However, if you are doing a lot of inlining and compile numerical code,
> I wouldn't be surprised if you'd do a lot of target arithmetic and find
> that for some programs the time required is significant.
>
>    -Geert
Is the Ada compiler (at compile time) using an external (to Ada)
multi-precision library?
If not, could it?
Could one mp library be used (at compile time) for both g95 & Ada?
Might that also simplifing 'lifting' the Ada library(ies) upto the library
level in the build tree?

Mike

Re: front-end target arithmetic (was: [G95] Re: [tree-ssa] Integrating g95)

[Laurent GUERBY]

On Tue, 2003-06-03 at 17:34, Michael S.Zick wrote:
> On Tuesday 03 June 2003 07:40 am, Geert Bosch wrote:
> > Now of course, this is mostly because Ada requires calculations of
> > "static" expressions (subset of compile-time known expressions) to be
> > performed exactly.
> Ouch.

Well for a language designed in 1995, I don't believe it's that silly
to require this given the portability advantage it gives
for not that much work on implementors.

> > However, if you are doing a lot of inlining and compile numerical code,
> > I wouldn't be surprised if you'd do a lot of target arithmetic and find
> > that for some programs the time required is significant.

If inlining is on, then target arithmetic might be out
of the radar in proportion of the total compile time again :). 

> Is the Ada compiler (at compile time) using an external (to Ada)
> multi-precision library?

It's internal, see ada/uintp.ad[sb]  (infinite precision integer
arithmetic) and ada/urealp.ad[sb] (rational numbers arithmetic). That's
a bit less of 5 ksloc of documented code, no big deal.

> If not, could it?
> Could one mp library be used (at compile time) for both g95 & Ada?
> Might that also simplifing 'lifting' the Ada library(ies) upto the library
> level in the build tree?

Well, you're trading clean and simple code for configure/header/Makefile
headaches :).

If GCC decides to implement such a thing in C as a front-end service,
with care to special services required by the Ada front-end (I can think
of being able to dump/reload the number table from a file
like Table.Table does for GNAT), I'm inclined to think that Ada
maintainers wouldn't mind dropping the current Ada code
and just Import the C routines, probably low priority though.

Laurent

Re: front-end target arithmetic (was: [G95] Re: [tree-ssa] Integrating g95)

[Michael S. Zick]

On Tuesday 03 June 2003 01:45 pm, Laurent GUERBY wrote:
> On Tue, 2003-06-03 at 17:34, Michael S.Zick wrote:
> > On Tuesday 03 June 2003 07:40 am, Geert Bosch wrote:
> > > Now of course, this is mostly because Ada requires calculations of
> > > "static" expressions (subset of compile-time known expressions) to be
> > > performed exactly.
> >
> > Ouch.
>
> Well for a language designed in 1995, I don't believe it's that silly
> to require this given the portability advantage it gives
> for not that much work on implementors.
>
Agreed, it is a great feature; one more step towards having the same
program behaviour regardless of the ultimate platform it is executed on.
>
> Well, you're trading clean and simple code for configure/header/Makefile
> headaches :).
>
> If GCC decides to implement such a thing in C as a front-end service,
> with care to special services required by the Ada front-end (I can think
> of being able to dump/reload the number table from a file
> like Table.Table does for GNAT), I'm inclined to think that Ada
> maintainers wouldn't mind dropping the current Ada code
> and just Import the C routines, probably low priority though.
>
Thought I saw a place to tie several different discussion threads 
together, so I just had to ask.
If there is nothing here to win, just put the subject of a common math
library for all of the front-ends on the "probably never happen" list.

Mike
>
> Laurent

Re: front-end target arithmetic

[Kai Henningsen]

guerby@acm.org (Laurent GUERBY)  wrote on 03.06.03 in <1054665912.21951.96.camel@localhost.localdomain>:

> On Tue, 2003-06-03 at 17:34, Michael S.Zick wrote:

> > Is the Ada compiler (at compile time) using an external (to Ada)
> > multi-precision library?
>
> It's internal, see ada/uintp.ad[sb]  (infinite precision integer
> arithmetic) and ada/urealp.ad[sb] (rational numbers arithmetic). That's
> a bit less of 5 ksloc of documented code, no big deal.
>
> > If not, could it?
> > Could one mp library be used (at compile time) for both g95 & Ada?
> > Might that also simplifing 'lifting' the Ada library(ies) upto the library
> > level in the build tree?

The obvious (to me) question becomes then,

a. do the Ada arithmetic routines do all the stuff g95 and c++ need, and

b. would it be a reasonable effort to rewrite that thing to make it usable  
from these frontends?

MfG Kai

Re: front-end target arithmetic

[Geert Bosch]

On Friday, Jun 6, 2003, at 12:26 America/New_York, Kai Henningsen wrote:
> a. do the Ada arithmetic routines do all the stuff g95 and c++ need,

No, this infinite precision rational arithmetic is not what g95
and c++ need.

   -Geert

Re: [G95] Re: [tree-ssa] Integrating g95

[Robert Dewar]

> Is the Ada compiler (at compile time) using an external (to Ada)
> multi-precision library?

No, it has its own

> Could one mp library be used (at compile time) for both g95 & Ada?

probably not, unless it has all the functionality required, which seems unlikely