headers
Gerald Pfeifer | 1 Aug 2005 01:00

Re: [docs] Add link to gfortran wiki for binaries

On Sun, 31 Jul 2005, Daniel Berlin wrote:
> So, uh, fix it.
> It probably took your 3x longer to write this message than it would have
> to double click on the page and edit it.

You fail to see the educational value of (patch) reviews.

Gerald
Permalink | Reply | 2 comments |
headers
Michael Matz | 1 Aug 2005 01:10
Picon

genattrtab speedup 4/4

Hi,

this last patch concludes the series (mostly), and gives back even more 
performance by reviving on old idea of mine.  Instead of accessing the 
individual attributes by calling get_attr_* functions each time, they are 
cached at function start, and accessed from there.

I.e. this:
   if (get_attr_length (insn) == 1 || get_attr_type (insn) == TYPE_BLA)
     ...
   else if (get_attr_type (insn) == TYPE_OTHER)
     ...

this is done:
  // function start
  attr_length = get_attr_length (insn);
  attr_type = get_attr_type (insn);
  ...
  switch ...
    ...
    if (attr_length == 1 || attr_type == TYPE_BLA)
      ...
    else if (attr_type == TYPE_OTHER)
      ...

this again reduces the size of insn-attrtab.o and the speed of compiling 
it.  It also reduces run time.  There might be the concern that now 
attributes are looked up, which might not be necessary for the insn at 
hand.  I haven't found this to be an issue at all.  (If this would lead to 
compiler errors or so, then the .md file is written incorrectly anyway).
(Continue reading)

Permalink | Reply | 5 comments |
headers
Paul Brook | 1 Aug 2005 01:11
Gravatar

Re: [docs] Add link to gfortran wiki for binaries

On Sunday 31 July 2005 23:44, Gerald Pfeifer wrote:
> On Wed, 27 Jul 2005, Paul Brook wrote:
> > The attached patch adds a link from the "GCC Binaries" page to the
> > gfortran binaries wiki page.
>
> Do we really need a separate page to track gfortran binaries?  I'd hope
> that we can get most (if not all) of those building GCC binary packages
> to include gfortran.

If and when that happens the wiki page will be obsolete, and we can remove the 
link. The existence of these binaries is IMHO proof that they are useful to 
someone.

> And I'll note that the current Wiki page is relatively weak. For example:
> 
>  . Please change the Wiki page to read GNU/Linux instead of Linux to 
>    follow the rules mandated by the FSF.
> 
>  . "detailed installation instructions" point to an empty page.
> 
>  . The basic web usability rule of not naming links "here" or "see here"
>    are violated.

Maybe so. That's one of the reasons I didn't suggest adding the content of 
that page to install.texi :-)

Paul
Permalink | Reply | 0 comments |
headers
Gerald Pfeifer | 1 Aug 2005 01:16

Re: [docs] Add link to gfortran wiki for binaries

On Mon, 1 Aug 2005, Paul Brook wrote:
>> Do we really need a separate page to track gfortran binaries?  I'd hope
>> that we can get most (if not all) of those building GCC binary packages
>> to include gfortran.
> If and when that happens the wiki page will be obsolete, and we can 
> remove the link. The existence of these binaries is IMHO proof that
> they are useful to someone.

Fair enough.  I'm just hoping gfortran will become very widely used and
commonly built rather sooner than later (at which point we can revert the 
patch). :-)

Gerald
Permalink | Reply | 0 comments |
headers
Daniel Berlin | 1 Aug 2005 01:18

Re: [docs] Add link to gfortran wiki for binaries

On Mon, 2005-08-01 at 01:00 +0200, Gerald Pfeifer wrote:
> On Sun, 31 Jul 2005, Daniel Berlin wrote:
> > So, uh, fix it.
> > It probably took your 3x longer to write this message than it would have
> > to double click on the page and edit it.
> 
> You fail to see the educational value of (patch) reviews.

For most documentation?
Yes. 
All having patch review for most documentation does is make it so we
don't have up-to-date or useful docs.

Repeat after me:  Documentation is not code.

You fail to see the value of collaborative development for
documentation, while strangely, other projects have embraced it and have
*much* better documentation than we do.

> 
> Gerald
Permalink | Reply | 0 comments |
headers
Gerald Pfeifer | 1 Aug 2005 01:19

Re: [patch, wwwdocs] Include "documentation" section on gfortran index.html

On Mon, 18 Jul 2005, Brooks Moses wrote:
>> As per a recent conversation with Steve Kargl on the fortran list, I'm
>> submitting this patch, which adds a small "Documentation" section to
>> the gfortran "home page", right below the "Binaries" section.
> Oh, bother.  I just noticed that I failed to update the link when I cut-
> and-pasted from the Binaries section!
> 
> A corrected patch follows.

I was waiting for a gfortran maintainer to comment -- if it's fine
with them, it surely is fine with me.

That said, what do you think about omething along the lines of
http://gcc.gnu.org/java/ which a navigation bar on the left? Might
that be preferrable?

Gerald
Permalink | Reply | 0 comments |
headers
Steve Kargl | 1 Aug 2005 01:22
Picon

Re: [docs] Add link to gfortran wiki for binaries

On Mon, Aug 01, 2005 at 01:16:19AM +0200, Gerald Pfeifer wrote:
> On Mon, 1 Aug 2005, Paul Brook wrote:
> >> Do we really need a separate page to track gfortran binaries?  I'd hope
> >> that we can get most (if not all) of those building GCC binary packages
> >> to include gfortran.
> > If and when that happens the wiki page will be obsolete, and we can 
> > remove the link. The existence of these binaries is IMHO proof that
> > they are useful to someone.
> 
> Fair enough.  I'm just hoping gfortran will become very widely used and
> commonly built rather sooner than later (at which point we can revert the 
> patch). :-)
> 

When the Cray pointer patch is committed to gfortran,
I suspect we'll see a minor (major?) increase in
gfortran usage over g77.  This has been a long requested
feature for g77, and AFAIK no other OSS fortran compiler
will have this capability. 

--

-- 
Steve
Permalink | Reply | 0 comments |
headers
Daniel Berlin | 1 Aug 2005 01:25

Re: [docs] Add link to gfortran wiki for binaries

On Mon, 2005-08-01 at 01:00 +0200, Gerald Pfeifer wrote:
> On Sun, 31 Jul 2005, Daniel Berlin wrote:
> > So, uh, fix it.
> > It probably took your 3x longer to write this message than it would have
> > to double click on the page and edit it.
> 
> You fail to see the educational value of (patch) reviews.

You just don't get it.
The idea is not to force the developers to work inside the box you want
them to work on, it is to collaborate and use tools that enable
developers to work inside the box *they* want to work in, while still
producing something *everyone* can use.

We are supposed to be encouraging developers and contributors.
Constantly putting roadblocks in their way does *not* do this. 
Do you really think the reason our docs aren't good is because we don't
have enough process?
Or that we don't mandate enough contribution to them?

If you can't see this isn't the real root cause of the problem, there is
simply no point in continuing this discussion, and i'll go my way and
stop contributing to docs except as i'm required to as part of patches,
and happily stop maintaining tools like the wiki that everyone but you
seems to find useful.
Permalink | Reply | 0 comments |
headers
Steve Kargl | 1 Aug 2005 01:36
Picon

Re: [patch, wwwdocs] Include "documentation" section on gfortran index.html

On Mon, Aug 01, 2005 at 01:19:01AM +0200, Gerald Pfeifer wrote:
> On Mon, 18 Jul 2005, Brooks Moses wrote:
> >> As per a recent conversation with Steve Kargl on the fortran list, I'm
> >> submitting this patch, which adds a small "Documentation" section to
> >> the gfortran "home page", right below the "Binaries" section.
> > Oh, bother.  I just noticed that I failed to update the link when I cut-
> > and-pasted from the Binaries section!
> > 
> > A corrected patch follows.
> 
> I was waiting for a gfortran maintainer to comment -- if it's fine
> with them, it surely is fine with me.

The patch is fine.  I was going to commit it, but real life
has taken over and gfortran is way down the list of important
things to do.

--

-- 
Steve
Permalink | Reply | 0 comments |
headers
Michael Matz | 1 Aug 2005 01:37
Picon

[c++ patch] fix for mi-thunk emission

Hi,

this patch is required at least on sparc for the genattrtab speedup 
patches, to generate the same code with and without them for kdecore.cc.  
But the bug is lurking anyway.  The problem is how some backends 
(alpha,ia64,mips,rs6000 on OSF,sh and sparc) emit mi-thunks by not going 
through the proper channels and instead calling final() themself.

The code in the arch.c usually looks similar to this:
  insn = get_insns ();
  insn_locators_initialize ();
  shorten_branches (insn);
  final_start_function (insn, file, 1);
  final (insn, file, 1);
  final_end_function ();

with the C++ frontend side (in method.c) being (partly):

      current_function_decl = thunk_fndecl;
      init_function_start (thunk_fndecl);
      current_function_is_thunk = 1;
      assemble_start_function (thunk_fndecl, fnname);
      targetm.asm_out.output_mi_thunk (asm_out_file, thunk_fndecl,
      assemble_end_function (thunk_fndecl, fnname);
      current_function_decl = 0;
      cfun = 0;

Now the problem is, that this together creates a new function calling 
passes from the backend on it, and generally doing stuff.  But it misses 
to call the pass_clean_state, which is done normally right after
(Continue reading)

Permalink | Reply | 3 comments |

Gmane