Re: Builtin functions?

[Paulo J. Matos]

On 4/16/07, Jan Hubicka <[EMAIL PROTECTED]> wrote:

>
> If you just want to scan every function you have around, the obvious
> way to do it is
>
> For each function
>  FOR_EACH_BB_FN (function).
>
> This is probably slightly slower than
>
> For each function
>  if cgraph_function_body_availability != NOT_AVAILABLE
>FOR_EACH_BB_FN (function)
>


Yes, it's working now, thank you!

--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: GCC 4.2.0 Status Report (2007-04-15)

[Richard Guenther]

On 4/17/07, Steven Bosscher <[EMAIL PROTECTED]> wrote:

On 4/17/07, Maxim Kuvyrkov <[EMAIL PROTECTED]> wrote:
> There is a patch for this PR29841 in
> http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01134.html .  The problem
> is that I don't really know which maintainer ask to review it :(

I think this patch needs re-testing (because of my cfglayout changes).
BARRIERs are never inside a basic block, so the patch looks obviously
correct to me. I think you should commit it as such if it passes
bootstrap/testing (preferably on two or three targets, and with
checking enabled of course).


Indeed.  The patch is ok after a re-bootstrap and re-test.

Thanks,
Richard.

GCC -On optimization passes: flag and doc issues

[Kenneth Hoste]

Hiya,

I'm doing research on which optimization passes to enable in the  
various -On flags, and I've stumbled onto a/some minor bug(s) and  
problems with the GCC documentation for the 4.1.2 version:


* When using -falign-loops or -fno-align-loops the corresponding  
internal variable 'align-loops' should be set to 0 (= use default  
setting) or 1 (= no aligning) resp. When parsing the various flags, a  
variable 'value' is used to set (value=1) or unset (value=0) the  
corresponding flag. Unfortunately, these values should be reversed  
for the -falign-X flags, which isn't done, and thus using -falign- 
loops causes no aligning, while -fno-align-loops causes aligning with  
the default setting for the arch you're compiling for. Same problem  
for -falign-jumps, -falign-labels and -falign-functions.


* On x86, -fschedule-insns is disabled, but -fschedule-insns2 (or the  
corresponding internal flag flag_schedule_insns_after_reload) is  
still being used... The reason for disabling fschedule-insns is  
increased register pressure (and x86 has few registers already). I'm  
not sure if this a bug, but why disable -fschedule-insns and leave - 
fschedule-insns2 active? Because , according to the docs, fschedule- 
insns2 = fschedule-insns + an additional pass. Any comments on this  
are welcome...


I've file a bug report for the first issue (http://gcc.gnu.org/ 
bugzilla/show_bug.cgi?id=31586), but since this is easy to fix, I'd  
like to fix it myself. The only thing holding me back is that I'm new  
at this: I've never contributed to an open source project before, and  
I'm only vaguely familiar with CVS and the likes. Is there a newbie- 
guide to contributing to GCC? How can I make sure this fix is done  
for 4.1, 4.2 _and_ 4.3?


Also, while trying to identify the flags enabled in the various -On  
flags, I've run into incomplete or even wrong documentation regarding  
the optimization passes. Some examples:


- the -fipa-X flags are not mentioned in the 4.1.2 documentation
- funit-at-a-time is still being reported as enabled in -O2 and  
above, while it is already active in -O1 (this seems to fixed in the  
4.3.0 docs though)
- the documentation for fmove-loop-invariants and ftree-loop-optimize  
mentions they are enabled at -O1 when they are not

- finline-functions is enabled at -Os, but isn't listed so

I can imagine few people care about the exact flags enabled at -On,  
but why list wrong information which will only confuse people (as it  
did for me).


Last but not least, I have some questions:

- Some flags are enabled by other flags (for example, fschedule-insns  
enables fsched-interblock and fsched-spec according to the docs). I  
was unable to find where in the source code this is done... And  
because I want to incorporate as much active On-flags as possible,  
I'd like to track down for which flags this is really true, and for  
which the docs are out-of-date.


- When new optimization passes are completed, how is decided where  
they go to (-O1, -O2, -O3, -Os, none)? For example, why did funit-at- 
a-time switch from -O2 to -O1 a while ago? And, as I noticed from the  
4.3.0 docs, why is fsplit-wide-types enabled at -O1, and not -O2? Is  
there some testing done, or is it just people saying "I think X  
belongs there"?


greetings,

Kenneth

--

Statistics are like a bikini. What they reveal is suggestive, but  
what they conceal is vital (Aaron Levenstein)


Kenneth Hoste
ELIS - Ghent University
[EMAIL PROTECTED]
http://www.elis.ugent.be/~kehoste

Re: GCC 4.2.0 Status Report (2007-04-15)

[Steven Bosscher]

On 4/17/07, Richard Guenther <[EMAIL PROTECTED]> wrote:

Indeed.  The patch is ok after a re-bootstrap and re-test.


Actually, please don't commit that patch.

Eric Botcazou has already proposed a fix that looks better:
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01065.html

Gr.
Steven

Re: GCC -On optimization passes: flag and doc issues

[Steven Bosscher]

On 4/17/07, Kenneth Hoste <[EMAIL PROTECTED]> wrote:

* On x86, -fschedule-insns is disabled, but -fschedule-insns2 (or the
corresponding internal flag flag_schedule_insns_after_reload) is
still being used... The reason for disabling fschedule-insns is
increased register pressure (and x86 has few registers already). I'm
not sure if this a bug, but why disable -fschedule-insns and leave -
fschedule-insns2 active? Because , according to the docs, fschedule-
insns2 = fschedule-insns + an additional pass. Any comments on this
are welcome...


-fschedule-insns2 is scheduling after register allocation.  Register
pressure is not a problem after register allocation ;-)  You just have
more constraints in your scheduling dependency graph.

Gr.
Steven

Re: EH references

[Paulo J. Matos]

Thank you for the references at Code Sourcery, regading SJLJ exception
handling I found the paper (which references it): "Exception Handling
in the Choices Operating System", is the reference for SJLJ EH?

Cheers,
--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: Duplicate assembler function names in cgraph

[Paulo J. Matos]

On 4/16/07, Jan Hubicka <[EMAIL PROTECTED]> wrote:

>
> Sure, however, I'm developing over 4.1.1, still you might still have
> the error on current head, (I know 4.1.1 is quite old). What do you
> mean by a test case? Do you want a short version of my IPA pass which
> shows up the issue?
Either that or of you can just minimize the testcase (perhaps with
delta) so it can be inspected by hand, it is probably easiest for me ;)

Honza



It is working now, I'm ignoring duplicated entries in cgraph_nodes. I
wonder, that if I am to use gcc head, how can I do that?
What I initially did was to import gcc 4.1.1 sources into my own
repository and have my pass there also. If I am to use the svn head
with my pass, how do people usually manage this, since svn head is on
one repository and your pass in another, still the pass lives inside
the gcc directory tree. Is there a way to handle this situation?

Cheers,

--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

RE: EH references

[Dave Korn]

On 17 April 2007 11:08, Paulo J. Matos wrote:

> Thank you for the references at Code Sourcery, regading SJLJ exception
> handling I found the paper (which references it): "Exception Handling
> in the Choices Operating System", is the reference for SJLJ EH?

  Dunno about that, but I found this link just recently; it contains a good
summary of the difference between sjlj and dwarf-style EH:

http://www.usenix.org/events/osdi2000/wiess2000/full_papers/dinechin/dinechin_
html/
"C++ Exception Handling for IA-64", Christophe de Dinechin

... and someone else posted this, quite a while ago:

http://gcc.gnu.org/ml/gcc/2004-03/msg01779.html


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

TREE_CODE: arrays and variables

[Andrea Callia D'Iddio]

Hi all,

I added a new gcc pass, in wich I've to elaborate GIMPLE code... for
every GIMPLE statement I use TREE_CODE macro to know if is an
assignment, an IF-THEN-ELSE, etc. and for every GIMPLE expression I
use also TREE_CODE macro to know if it's an integer constant, an
addition, etc.
I know that if expression 'e' is a variable or an array element, then
TREE_CODE(e)==VAR_DECL. But how can I know if 'e' is a variable, or an
array element? and, if it's an array element, how can I know which is
the index value? can I have other informations such as array's size
and array's name?

Thanks to all

Andrea

RE: GCC -On optimization passes: flag and doc issues

[Eric Weddington]

 

> -Original Message-
> From: Kenneth Hoste [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, April 17, 2007 3:23 AM
> To: gcc@gcc.gnu.org
> Subject: GCC -On optimization passes: flag and doc issues

> - finline-functions is enabled at -Os, but isn't listed so

And it seems to have some issues:

Comments #4 and #6.

Re: Splay Tree

[Brian Makin]

Got the documents signed and they are now on their
way.

--- Richard Guenther <[EMAIL PROTECTED]>
wrote:

> On 11/3/06, Ian Blanes <[EMAIL PROTECTED]> wrote:
> >
> > The original author of this patch said he sent his
> copyright assignment. I
> > only did minor modification to his work so I don't
> I think I should send
> > it too.
> >
>
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00833.html
> 
> There doesn't seem to be an assignment on file for
> him.
> 
> Richard.
> 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Duplicate assembler function names in cgraph

[Mike Stump]

On Apr 17, 2007, at 3:11 AM, Paulo J. Matos wrote:

I wonder, that if I am to use gcc head, how can I do that?


This isn't a trick question is it?  Anyway, it is answered by our web  
site.  Briefly, you check out trunk and then you edit it.  patch is  
one way to mass edit a source tree for example.



What I initially did was to import gcc 4.1.1 sources into my own
repository and have my pass there also. If I am to use the svn head
with my pass, how do people usually manage this, since svn head is on
one repository and your pass in another, still the pass lives inside
the gcc directory tree. Is there a way to handle this situation?


svn/svk questions should go to those lists.  Briefly, you merge in  
trunk into your branch:


svn merge base gcc/trunk .

Or, you can take svn diff mybranch-base mybranch and apply that as a  
patch to a checkout of trunk.  These are source code management 101  
style questions.  While we might be able to offer help if you get  
stuck, better would be to punt you to the svn/svk docs and users lists.

Re: GCC -On optimization passes: flag and doc issues

[Ian Lance Taylor]

Kenneth Hoste <[EMAIL PROTECTED]> writes:

> * When using -falign-loops or -fno-align-loops the corresponding
> internal variable 'align-loops' should be set to 0 (= use default
> setting) or 1 (= no aligning) resp. When parsing the various flags, a
> variable 'value' is used to set (value=1) or unset (value=0) the
> corresponding flag. Unfortunately, these values should be reversed
> for the -falign-X flags, which isn't done, and thus using -falign-
> loops causes no aligning, while -fno-align-loops causes aligning with
> the default setting for the arch you're compiling for. Same problem
> for -falign-jumps, -falign-labels and -falign-functions.

Ouch.  Thanks for noticing.

> * On x86, -fschedule-insns is disabled, but -fschedule-insns2 (or the
> corresponding internal flag flag_schedule_insns_after_reload) is
> still being used... The reason for disabling fschedule-insns is
> increased register pressure (and x86 has few registers already). I'm
> not sure if this a bug, but why disable -fschedule-insns and leave -
> fschedule-insns2 active? Because , according to the docs, fschedule-
> insns2 = fschedule-insns + an additional pass. Any comments on this
> are welcome...

As Steven mentioned, this is expected.  The docs are, perhaps,
slightly misleading.  -fschedule-insns2 does not imply
-fschedule-insns.  The two options are independent.  -fschedule-insns2
runs after register allocation and therefore does not increase
register pressure.

> I've file a bug report for the first issue (http://gcc.gnu.org/
> bugzilla/show_bug.cgi?id=31586), but since this is easy to fix, I'd
> like to fix it myself. The only thing holding me back is that I'm new
> at this: I've never contributed to an open source project before, and
> I'm only vaguely familiar with CVS and the likes. Is there a newbie-
> guide to contributing to GCC? How can I make sure this fix is done
> for 4.1, 4.2 _and_ 4.3?

Source code access is described at http://gcc.gnu.org/svn.html.  There
is some general, not very well organized, information on the gcc wiki
at http://gcc.gnu.org/wiki/.  You should first write the patch for
mainline (4.3).  When that is accepted, you can backport the patch to
the 4.1 and 4.2 branches.

> Also, while trying to identify the flags enabled in the various -On
> flags, I've run into incomplete or even wrong documentation regarding
> the optimization passes. Some examples:
> 
> - the -fipa-X flags are not mentioned in the 4.1.2 documentation

Looks like a bug.

> - funit-at-a-time is still being reported as enabled in -O2 and
> above, while it is already active in -O1 (this seems to fixed in the
> 4.3.0 docs though)

This would be a bug but it looks OK to me in 4.1.

> - the documentation for fmove-loop-invariants and ftree-loop-optimize
> mentions they are enabled at -O1 when they are not

Actually I think they are enabled at -O1.  This is done in a slightly
tricky way: they default to being on, but they have no effect unless
the other loop optimization passes are run.  I think it would be
appropriate to clean this up to make the code more obvious.

> - finline-functions is enabled at -Os, but isn't listed so

Yes, this should be documented better.  The general -finline-functions
is not enabled at -Os.  Only inlining of small functions is enabled.
This is done by setting parameters.

> - Some flags are enabled by other flags (for example, fschedule-insns
> enables fsched-interblock and fsched-spec according to the docs). I
> was unable to find where in the source code this is done... And
> because I want to incorporate as much active On-flags as possible,
> I'd like to track down for which flags this is really true, and for
> which the docs are out-of-date.

-fsched-interblock and -fsched-spec default to 1 in common.opt.  But
they have no effect unless you enable a scheduling pass.

> - When new optimization passes are completed, how is decided where
> they go to (-O1, -O2, -O3, -Os, none)? For example, why did funit-at-
> a-time switch from -O2 to -O1 a while ago? And, as I noticed from the
> 4.3.0 docs, why is fsplit-wide-types enabled at -O1, and not -O2? Is
> there some testing done, or is it just people saying "I think X
> belongs there"?

Where to put optimizations is a trade-off between the amount of time
they take and the amount of good they do.  The testing which is done
is compilation time testing.

-funit-at-a-time was moved from -O2 to -O1 because we are likely to
make it the default in all cases, including -O0.  Making
-funit-at-a-time the default will simplify several cases in the
compiler.  It is already the default in all cases for C++.

-fsplit-wide-types is at -O1 because it is normally cheap in terms of
compilation time.  It doesn't do anything if there are no "long long"
local variables in the function (or, more generally, no variables
whose type is such that they are twice the width of a general
register).

Ian

Re: TREE_CODE: arrays and variables

[Diego Novillo]

Andrea Callia D'Iddio wrote on 04/17/07 08:30:

> I know that if expression 'e' is a variable or an array element, then
> TREE_CODE(e)==VAR_DECL. But how can I know if 'e' is a variable, or an
> array element? and, if it's an array element, how can I know which is
> the index value? can I have other informations such as array's size
> and array's name?

If you only have 'e', then you can check TREE_TYPE('e') which should
return ARRAY_TYPE if 'e' is an array.

But before finding 'e' you should have found the ARRAY_REF that holds
'e' and the index into 'e'.  See tree.def for how to access ARRAY_REF
elements.

Re: Duplicate assembler function names in cgraph

[Paulo J. Matos]

On 4/17/07, Mike Stump <[EMAIL PROTECTED]> wrote:

On Apr 17, 2007, at 3:11 AM, Paulo J. Matos wrote:
> I wonder, that if I am to use gcc head, how can I do that?

This isn't a trick question is it?  Anyway, it is answered by our web
site.  Briefly, you check out trunk and then you edit it.  patch is
one way to mass edit a source tree for example.

> What I initially did was to import gcc 4.1.1 sources into my own
> repository and have my pass there also. If I am to use the svn head
> with my pass, how do people usually manage this, since svn head is on
> one repository and your pass in another, still the pass lives inside
> the gcc directory tree. Is there a way to handle this situation?

svn/svk questions should go to those lists.  Briefly, you merge in
trunk into your branch:

svn merge base gcc/trunk .

Or, you can take svn diff mybranch-base mybranch and apply that as a
patch to a checkout of trunk.  These are source code management 101
style questions.  While we might be able to offer help if you get
stuck, better would be to punt you to the svn/svk docs and users lists.



I think I understood. I'll look into it. Thank you!
--
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK

Re: GCC -On optimization passes: flag and doc issues

[Kenneth Hoste]

On 17 Apr 2007, at 18:18, Eric Weddington wrote:





-Original Message-
From: Kenneth Hoste [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 17, 2007 3:23 AM
To: gcc@gcc.gnu.org
Subject: GCC -On optimization passes: flag and doc issues



- finline-functions is enabled at -Os, but isn't listed so


And it seems to have some issues:

Comments #4 and #6.


This is exactly one of the reasons for our research: providing a  
usefull way to determine which flags should go where...
Of course, this still depends on the benchmarks used and the platform  
chosen, but still, the way it is done now it's just guessing IMHO (of  
course, using domain knowledge, but still)...


greetings,

K.

--

Statistics are like a bikini. What they reveal is suggestive, but  
what they conceal is vital (Aaron Levenstein)


Kenneth Hoste
ELIS - Ghent University
[EMAIL PROTECTED]
http://www.elis.ugent.be/~kehoste

Re: GCC -On optimization passes: flag and doc issues

[Steven Bosscher]

On 4/17/07, Eric Weddington <[EMAIL PROTECTED]> wrote:

> - finline-functions is enabled at -Os, but isn't listed so

And it seems to have some issues:

Comments #4 and #6.


The only real issue here is a wrong expectation: That a certain
combination of flags magically does the best thing for every target.
The -Ox options are "tuned" from time to time to get the best mix of
results of a certain set of targets. That does not mean it does the
best thing for all other targets. Then, folks who like to complain
come along and report silly bugs like this, when perhaps they should
also notice that the efficiency of GCC for -Os has increased
tremendeously in the past few years...

Just my US$0.02 about  this particular bug.

Gr.
Steven

RE: GCC -On optimization passes: flag and doc issues

[Eric Weddington]

 

> -Original Message-
> From: Steven Bosscher [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, April 17, 2007 2:52 PM
> To: Eric Weddington
> Cc: Kenneth Hoste; gcc@gcc.gnu.org
> Subject: Re: GCC -On optimization passes: flag and doc issues
> 
> On 4/17/07, Eric Weddington <[EMAIL PROTECTED]> wrote:
> > > - finline-functions is enabled at -Os, but isn't listed so
> >
> > And it seems to have some issues:
> > 
> > Comments #4 and #6.
> 
> The only real issue here is a wrong expectation: That a certain
> combination of flags magically does the best thing for every target.
> The -Ox options are "tuned" from time to time to get the best mix of
> results of a certain set of targets. 

Well this begs the question of why, when there are so many different
targets, are there are only 4 optimization flags (1,2,3,s), especially when
they only get tuned to certain targets? I know, "patches are welcome". ;-)

> That does not mean it does the
> best thing for all other targets. 

Bug #31528, comment #5:

"Also, as you mention the target code has a chance to tune this ..., can you
give me a hint about
where to look for these knobs?  I might give it a try to see whether I
can find a more optimal set of parameters."

This was in response to your comment in #4. Do you have any concrete
suggestions?

> Then, folks who like to complain
> come along and report silly bugs like this, 

Wow. Perhaps there is someone else here on the list who might point us in
the right direction, that doesn't think this is a silly bug, or that perhaps
thinks that we might be serious about getting this fixed for the AVR.

There is concerted effort to get the AVR port in shape wrt. fixing
outstanding bugs, updating the backend, regular regression testing, etc. One
of our goals is to propose the AVR to the "secondary platform" status,
hopefully in the next six months. The AVR is a popular GCC target, with
distros on FreeBSD, Linux, Windows, Mac OS X, it can build for Solaris, and
there have been at least 51,560 downloads in the last 2 months of the
Windows distro alone:



> when perhaps they should
> also notice that the efficiency of GCC for -Os has increased
> tremendously in the past few years...

That is what you think is important. To AVR users, compile time could
increase by 100% and they wouldn't care, but they do care when there is a
compiled code size regression of even 1%. Yes, part of it is the
responsibility of the port, but there are other target-independent portions
that affect this too. It would be nice if GCC could try to take all users
into consideration.

Eric Weddington

Re: GCC -On optimization passes: flag and doc issues

[Joerg Wunsch]

As Eric Weddington wrote:

> > > And it seems to have some issues:
> > >  Comments #4
> > > and #6.

> > The only real issue here is a wrong expectation: That a certain
> > combination of flags magically does the best thing for every
> > target.

No, the issue is that the -Os option is *documented* to *only* include
those optimizations that are known to not increase the code size.  It
is all fine with me to have automatic inlining of functions if and
only if that does not increase the code size -- because, after all,
that is the main idea behind -Os: to get the smallest code size
possible.

Since that bug report shows that the inlining as implemented now
increases the code size (for that test case) for every target where it
has been tested on so far, this is clearly in violation of the rules
for -Os, and thus a regression compared to older versions of GCC
(which generally didn't perform any automatic inlining with -Os).

If you don't accept that to be a regression, what else are you willing
to accept?

> > Then, folks who like to complain
> > come along and report silly bugs like this,

> Wow.

I hope you just had a bad day only.  Otherwise, I might eventually
lose my trust into the mental abilities of the GCC developers.  Sorry.
I spent a couple of hours to boil down the complaints of our users
(some of them still think that GCC 4 is a major step backwards for
them!, compared to GCC 3) to what really makes a meaningful bug report
(simple, reproducible).  I spent another couple of hours to
demonstrate this regression basically affects *all* GCC targets (not
just AVR which I realize is by now of quite minor importance), and
what am I called for doing that?

Sorry, but this is unbelievable.

-- 
cheers, J"org   .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

Re: GCC -On optimization passes: flag and doc issues

[Steven Bosscher]

On 4/17/07, Eric Weddington <[EMAIL PROTECTED]> wrote:

> when perhaps they should
> also notice that the efficiency of GCC for -Os has increased
> tremendously in the past few years...

That is what you think is important. To AVR users, compile time could
increase by 100% and they wouldn't care, but they do care when there is a
compiled code size regression of even 1%.


I was talking about code size, not compile time.

If you look at CSiBE, you can see how gcc improved for -Os over time:

   2004-01-11  2007-04-01  diff
arm-elf 385 357 -7.3%
mips-elf401 383 -4.5%
ppc-elf 367 349 -5%
sh-elf  330 317 -4%


   2004-08-08  2006-12-17  diff
arm-linux   342 337 -1.5%


   2004-12-05  2006-06-17  diff
bfin-elf314 312 -1%

Maybe you can look at the development of code size of AVR over time,
and show a different trend, but I'd be surprised.

Gr.
Steven

RE: GCC -On optimization passes: flag and doc issues

[Eric Weddington]

 

> -Original Message-
> From: Steven Bosscher [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, April 17, 2007 2:52 PM
> To: Eric Weddington
> Cc: Kenneth Hoste; gcc@gcc.gnu.org
> Subject: Re: GCC -On optimization passes: flag and doc issues
> 
> On 4/17/07, Eric Weddington <[EMAIL PROTECTED]> wrote:
> > > - finline-functions is enabled at -Os, but isn't listed so
> >
> > And it seems to have some issues:
> > 
> > Comments #4 and #6.
> 
> The only real issue here is a wrong expectation: That a certain
> combination of flags magically does the best thing for every target.
> The -Ox options are "tuned" from time to time to get the best mix of
> results of a certain set of targets. 

Well this begs the question of why, when there are so many different
targets, are there are only 4 optimization flags (1,2,3,s), especially when
they only get tuned to certain targets? I know, "patches are welcome". ;-)

> That does not mean it does the
> best thing for all other targets. 

Bug #31528, comment #5:

"Also, as you mention the target code has a chance to tune this ..., can you
give me a hint about
where to look for these knobs?  I might give it a try to see whether I
can find a more optimal set of parameters."

This was in response to your comment in #4. Do you have any concrete
suggestions?

> Then, folks who like to complain
> come along and report silly bugs like this, 

Wow. Perhaps there is someone else here on the list who might point us in
the right direction, that doesn't think this is a silly bug, or that perhaps
thinks that we might be serious about getting this fixed for the AVR.

There is concerted effort to get the AVR port in shape wrt. fixing
outstanding bugs, updating the backend, regular regression testing, etc. One
of our goals is to propose the AVR to the "secondary platform" status,
hopefully in the next six months. The AVR is a popular GCC target, with
distros on FreeBSD, Linux, Windows, Mac OS X, it can build for Solaris, and
there have been at least 51,560 downloads in the last 2 months of the
Windows distro alone:



> when perhaps they should
> also notice that the efficiency of GCC for -Os has increased
> tremendously in the past few years...

That is what you think is important. To AVR users, compile time could
increase by 100% and they wouldn't care, but they do care when there is a
compiled code size regression of even 1%. Yes, part of it is the
responsibility of the port, but there are other target-independent portions
that affect this too. It would be nice if GCC could try to take all users
into consideration.

Eric Weddington

Re: GCC -On optimization passes: flag and doc issues

[Ian Lance Taylor]

Eric Weddington <[EMAIL PROTECTED]> writes:

> "Also, as you mention the target code has a chance to tune this ..., can you
> give me a hint about
> where to look for these knobs?  I might give it a try to see whether I
> can find a more optimal set of parameters."
> 
> This was in response to your comment in #4. Do you have any concrete
> suggestions?

Define OPTIMIZATION_OPTIONS in the CPU.h file.  See the internal
documentation, and examples in many backends.

> > when perhaps they should
> > also notice that the efficiency of GCC for -Os has increased
> > tremendously in the past few years...
> 
> That is what you think is important. To AVR users, compile time could
> increase by 100% and they wouldn't care, but they do care when there is a
> compiled code size regression of even 1%. Yes, part of it is the
> responsibility of the port, but there are other target-independent portions
> that affect this too. It would be nice if GCC could try to take all users
> into consideration.

If the code size increases for AVR, when using -Os, when comparing an
older release to mainline or 4.2 branch, you should report that as a
regression in bugzilla.  Thanks.

Ian

Re: GCC -On optimization passes: flag and doc issues

[Joerg Wunsch]

As Steven Bosscher wrote:

> Maybe you can look at the development of code size of AVR over time,
> and show a different trend, but I'd be surprised.

Most AVR users use -Os, as small code is fast code in most of the
cases on the AVR.  The `overall summary' is that GCC continuously
decreased its efficiency in code generation throughout the 3.x version
line.  It's never been a dramatic change, but with each compiler
version, the code grew by a percent or two.  Sure, bugs have been
fixed than, and obviously, the older (smaller) code had a higher
probability of being incorrect.  However, the perception of the users
(and don't underestimate their perception!) was that GCC actually got
worse over time.

With GCC 4.x (where x >= 1 so the initial regressions had already been
sorted out), there's now a completely different picture.  There are
people who easily gained 5...10 % code size in large projects, but
there are as well numerous cases where the resulting code size
increased by a similar dramatical value when switching from GCC 3.x to
4.x.  As it turns out, most (if not all) of the latter are due to the
automatic inlining that is now enabled with -Os.

This is why that ``silly'' bug report has been filed: it *is* annoying
a good number of (AVR-)GCC users, and it *is* a regression, compared
to GCC 3.x.

-- 
cheers, J"org   .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

Re: GCC -On optimization passes: flag and doc issues

[Steven Bosscher]

On 4/18/07, Joerg Wunsch <[EMAIL PROTECTED]> wrote:

As Eric Weddington wrote:

> > > And it seems to have some issues:
> > >  Comments #4
> > > and #6.

> > The only real issue here is a wrong expectation: That a certain
> > combination of flags magically does the best thing for every
> > target.

No, the issue is that the -Os option is *documented* to *only* include
those optimizations that are known to not increase the code size.


My copy of the documentation says:

@item -Os
@opindex Os
Optimize for size.  @option{-Os} enables all @option{-O2} optimizations that
do not typically increase code size.  It also performs further
optimizations designed to reduce code size.

Note: typically.



Since that bug report shows that the inlining as implemented now
increases the code size (for that test case) for every target where it
has been tested on so far, this is clearly in violation of the rules
for -Os, and thus a regression compared to older versions of GCC
(which generally didn't perform any automatic inlining with -Os).


It shows so for this particular test case, but that does not count as
proof that the flag  always causes increased code size for every test
case.  When it was decided to inline at -Os, this was done because
there was proof that overall (for CSiBE) it resulted in smaller
binaries.



I spent a couple of hours to boil down the complaints of our users
(some of them still think that GCC 4 is a major step backwards for
them!, compared to GCC 3) to what really makes a meaningful bug report
(simple, reproducible).  I spent another couple of hours to
demonstrate this regression basically affects *all* GCC targets (not
just AVR which I realize is by now of quite minor importance), and
what am I called for doing that?


You got an explanation from me how the inlining decisions are made,
and why that may or may not work for every target that GCC supports.
Quote (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31528#c5):

Inlining decisions are based on heuristics. What works for one target may not
work quite as well for another. In this case, it seems that for AVR the
heuristics are not the best.  You can tune the heuristics for this target and
let the target options override the default heuristics parameters.


And now that you've shown that for this test case GCC actually may
have regressed on every target, you've shown that perhaps the global
inlining heuristics should be changed. May well be, for all I know.
Tuning heuristics is always hard and never provably optimal.

Gr.
Steven

Re: GCC -On optimization passes: flag and doc issues

[Joerg Wunsch]

As Ian Lance Taylor wrote:

> If the code size increases for AVR, when using -Os, when comparing an
> older release to mainline or 4.2 branch, you should report that as a
> regression in bugzilla.  Thanks.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31528

-- 
cheers, J"org   .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

Re: GCC -On optimization passes: flag and doc issues

[Mike Stump]

On Apr 17, 2007, at 2:56 PM, Eric Weddington wrote:
Well this begs the question of why, when there are so many  
different targets, are there are only 4 optimization flags  
(1,2,3,s), especially when they only get tuned to certain targets?


If you count again, you'll see there are more than 4 optimization  
flags.  There are merely four in the set {-O0, -O1, -O2, -O3, - 
Os}.  :-)  There are only 4 in the big-O set, as the poor users can't  
handle more.  If you want to submit a patch for the users, Genentech  
has a few openings.


If you want to tune your target, well, patches welcome.

"Also, as you mention the target code has a chance to tune  
this ..., can you give me a hint about where to look for these knobs?


See override_options (aka OVERRIDE_OPTIONS) in config/i386/i386.c for  
example.  See the documentation where this is described.  If you  
wonder around some more port files, you can find all sorts of cost  
things and tuning things, they might give you some addition ideas.


That is what you think is important. To AVR users, compile time  
could increase by 100% and they wouldn't care, but they do care  
when there is a compiled code size regression of even 1%.


Yes, part of it is the responsibility of the port, but there are  
other target-independent portions that affect this too. It would be  
nice if GCC could try to take all users into consideration.


If you set up a regression tester that checks nightly for code size  
regressions on your platform and send hate mail whenever one of these  
events happens, you would be one step closer to having no  
regressions.  If you maintain your port, and ask others that do the  
codesize tests (CSiBE), to also test your platform (if they don't  
already), they might be willing to do that.

Re: GCC -On optimization passes: flag and doc issues

[Paul Brook]

> No, the issue is that the -Os option is *documented* to *only* include
> those optimizations that are known to not increase the code size.  

Where exactly is the documented? My documentation says It 
enables "optimisations that do not *typically* increase code size" (emphasis 
mine).

Many optimizations (including inlining) are controlled by heuristics, which by 
their very nature give the "wrong" decision sometimes. The trick is to get 
the best overall settings, or the best settings for a particular target.

Paul

RE: GCC -On optimization passes: flag and doc issues

[Eric Weddington]

 

> -Original Message-
> From: Ian Lance Taylor [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, April 17, 2007 4:20 PM
> To: Eric Weddington
> Cc: 'Steven Bosscher'; gcc@gcc.gnu.org; 'Joerg Wunsch'; 
> 'Anatoly Sokolov'
> Subject: Re: GCC -On optimization passes: flag and doc issues
> 
> Eric Weddington <[EMAIL PROTECTED]> writes:
> 
> > "Also, as you mention the target code has a chance to tune 
> this ..., can you
> > give me a hint about
> > where to look for these knobs?  I might give it a try to 
> see whether I
> > can find a more optimal set of parameters."
> > 
> > This was in response to your comment in #4. Do you have any concrete
> > suggestions?
> 
> Define OPTIMIZATION_OPTIONS in the CPU.h file.  See the internal
> documentation, and examples in many backends.

Thanks for your help. We'll look into it. 
 
> If the code size increases for AVR, when using -Os, when comparing an
> older release to mainline or 4.2 branch, you should report that as a
> regression in bugzilla.  Thanks.

Will change the bug report to reflect that.

Eric

Re: GCC -On optimization passes: flag and doc issues

[Joerg Wunsch]

As Steven Bosscher wrote:

> And now that you've shown that for this test case GCC actually may
> have regressed on every target, you've shown that perhaps the global
> inlining heuristics should be changed. May well be, for all I know.
> Tuning heuristics is always hard and never provably optimal.

I accept that.  To me, it appears as if GCC is currently incorrectly
computing the costs for the inlining for very small functions.  Users
of the AVR target are particularly affected by that because obviously,
their usage pattern frequently contains that kind of short functions,
which are now being inlined though that is increasing the actual
costs.

> It shows so for this particular test case, but that does not count
> as proof that the flag always causes increased code size for every
> test case.  When it was decided to inline at -Os, this was done
> because there was proof that overall (for CSiBE) it resulted in
> smaller binaries.

Then, this is rather a proof to me that CSiBE does not expose the case
of very small functions well enough.

For the AVR users, we are probably happy if the target code can be
tuned enough to get a less aggressive inlining, and I think users of
large machines wouldn't care too much about a wasted byte of code or
two unless it is their typical usage pattern.

-- 
cheers, J"org   .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

RE: GCC -On optimization passes: flag and doc issues

[Eric Weddington]

 

> -Original Message-
> From: Mike Stump [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, April 17, 2007 4:28 PM
> To: Eric Weddington
> Cc: 'Steven Bosscher'; gcc@gcc.gnu.org; 'Joerg Wunsch'; 
> 'Anatoly Sokolov'
> Subject: Re: GCC -On optimization passes: flag and doc issues
> 
> On Apr 17, 2007, at 2:56 PM, Eric Weddington wrote:
> > Well this begs the question of why, when there are so many  
> > different targets, are there are only 4 optimization flags  
> > (1,2,3,s), especially when they only get tuned to certain targets?
> 
> If you count again, you'll see there are more than 4 optimization  
> flags.  There are merely four in the set {-O0, -O1, -O2, -O3, - 
> Os}.  :-)  There are only 4 in the big-O set, as the poor 
> users can't  
> handle more.

Oh? I wonder how that decision was reached... 

> If you want to tune your target, well, patches welcome.

That's exactly what we're trying to do, sarcasm aside.

 
> > "Also, as you mention the target code has a chance to tune  
> > this ..., can you give me a hint about where to look for 
> these knobs?
> 
> See override_options (aka OVERRIDE_OPTIONS) in 
> config/i386/i386.c for  
> example.  See the documentation where this is described.  If you  
> wonder around some more port files, you can find all sorts of cost  
> things and tuning things, they might give you some addition ideas.

Thanks for the suggestion, it's very much appreciated. We'll look into it.

 
> If you set up a regression tester that checks nightly for code size  
> regressions on your platform and send hate mail whenever one 
> of these  
> events happens, you would be one step closer to having no  
> regressions.  

Thanks for the suggestion. I'll see what I can do to implement it.

> If you maintain your port, and ask others that do the  
> codesize tests (CSiBE), to also test your platform (if they don't  
> already), they might be willing to do that.

Well, there's part of the problem. Somehow, I don't think that CSiBE
testsuite was designed for an 8-bit micro. It will be difficult to do a real
comparison. But it's definitely a start if we can tune things from the
backend.

Eric

Re: GCC -On optimization passes: flag and doc issues

[Ian Lance Taylor]

Joerg Wunsch <[EMAIL PROTECTED]> writes:

> As Ian Lance Taylor wrote:
> 
> > If the code size increases for AVR, when using -Os, when comparing an
> > older release to mainline or 4.2 branch, you should report that as a
> > regression in bugzilla.  Thanks.
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31528

The relevant code is in opts.c:

  if (optimize_size)
{
  /* Inlining of very small functions usually reduces total size.  */
  set_param_value ("max-inline-insns-single", 5);
  set_param_value ("max-inline-insns-auto", 5);
  flag_inline_functions = 1;

It was added here:
http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00147.html

Top of thread:
http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01350.html
http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00016.html

Inlining has changed considerably since then, and it is possible that
these parameter values are no longer appropriate.  The reports at the
time indicate space savings.

Ian

RE: GCC -On optimization passes: flag and doc issues

[Dave Korn]

On 17 April 2007 23:27, Paul Brook wrote:

>> No, the issue is that the -Os option is *documented* to *only* include
>> those optimizations that are known to not increase the code size.
> 
> Where exactly is the documented? My documentation says It
> enables "optimisations that do not *typically* increase code size" (emphasis
> mine).

  Sorry for butting in, but I just can't follow the reasoning here.  Unless a
function is only ever used once and is inlined at the single callsite, or
unless the prolog and epilog are several times the size of the function body,
isn't inlining /always/ (not just "typically", but actually *always*) going to
increase code size?  I feel I must be missing something really obvious... is
it just that the other optimisations that become possible on inline code
usually compensate?


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Segfault on OpenMP program

[FX Coudert]

Someone reported on bug on a trivial statically-linked Fortran progam  
with OpenMP and a I/O operation. I can reproduce the segfault, which  
happens at:


(gdb) where
#0  0x in ?? ()
#1  0x0804cdbb in get_external_unit (n=6, do_create=1)
at
/home/fxcoudert/gfortran_nightbuild/trunk/libgfortran/../gcc/gthr- 
posix.h:613

#2  0x0804b987 in data_transfer_init (dtp=0xbfe9b024, read_flag=0)
at /home/fxcoudert/gfortran_nightbuild/trunk/libgfortran/io/ 
transfer.c:1702

#3  0x0804827f in MAIN__.omp_fn.0 (.omp_data_i=0x0) at hello.f90:2
#4  0x08048235 in MAIN__ () at hello.f90:2
#5  0x080482dd in main (argc=Cannot access memory at address 0x1

The line 613 in gcc/gthr-posix.h is the call to pthread_mutex_trylock 
() in:


static inline int
__gthread_mutex_trylock (__gthread_mutex_t *mutex)
{
  if (__gthread_active_p ())
return __gthrw_(pthread_mutex_trylock) (mutex);
  else
return 0;
}


Andrew suggested on bugzilla that this might be a GLIBC issue (I use  
glibc-2.4 from redhat), with "pthreads not linking in correctly".  
Does this ring a bell? Can someone confirm that it's not a GCC issue  
(or that it is)? Details can be found in PR 31604.


Thanks,
FX

Re: GCC -On optimization passes: flag and doc issues

[Eric Christopher]

increase code size?  I feel I must be missing something really  
obvious... is
it just that the other optimisations that become possible on inline  
code

usually compensate?


That or the savings from not having to save/restore registers, set up  
the frame, etc as well.


-eric

Re: GCC -On optimization passes: flag and doc issues

[Dale Johannesen]

On Apr 17, 2007, at 4:20 PM, Eric Christopher wrote:



increase code size?  I feel I must be missing something really  
obvious... is
it just that the other optimisations that become possible on  
inline code

usually compensate?


That or the savings from not having to save/restore registers, set  
up the frame, etc as well.


Don't forget the call and its setup.  Trivially, inlining an empty  
function is always a size win.

There actually were a couple in Spec95.

Re: GCC -On optimization passes: flag and doc issues

[Ian Lance Taylor]

"Dave Korn" <[EMAIL PROTECTED]> writes:

>   Sorry for butting in, but I just can't follow the reasoning here.  Unless a
> function is only ever used once and is inlined at the single callsite, or
> unless the prolog and epilog are several times the size of the function body,
> isn't inlining /always/ (not just "typically", but actually *always*) going to
> increase code size?  I feel I must be missing something really obvious... is
> it just that the other optimisations that become possible on inline code
> usually compensate?

It's pretty much always going to be a win to inline
int f (int a) { return g (a); }
And while that kind of thing looks silly in isolation, it is quite
common in class methods in C++.

Ian

Recommend lecture about the meaning of PHI function from SSA.

[J.C. Pizarro]

For novice people, i recommend to read

http://en.wikipedia.org/wiki/Static_single_assignment_form

You see why the meaning of "y3 <- phi(y1,y2)" :)

Re: GCC -On optimization passes: flag and doc issues

[Joe Buck]

On Tue, Apr 17, 2007 at 03:44:36PM -0700, Ian Lance Taylor wrote:
> The relevant code is in opts.c:
> 
>   if (optimize_size)
> {
>   /* Inlining of very small functions usually reduces total size.  */
>   set_param_value ("max-inline-insns-single", 5);
>   set_param_value ("max-inline-insns-auto", 5);
>   flag_inline_functions = 1;
> ...
> Inlining has changed considerably since then, and it is possible that
> these parameter values are no longer appropriate.  The reports at the
> time indicate space savings.

Maybe there's a problem in setting the threshold in terms of
only the size of the function.  Inlining the function saves space if
the function itself is no longer than the code to pass the arguments and
do the call.  But the threshold is expressed in terms of only the
number of instructions.  For a zero-argument function, inlining a
5-instruction function will increase the code size, but if there are
3-4 arguments, the reverse is likely to be the case.

Perhaps the number of arguments should be taken into account as well.

Re: GCC -On optimization passes: flag and doc issues

[Joe Buck]

On Wed, Apr 18, 2007 at 12:16:32AM +0100, Dave Korn wrote:
>   Sorry for butting in, but I just can't follow the reasoning here.
> Unless a function is only ever used once and is inlined at the single
> callsite, or unless the prolog and epilog are several times the size of
> the function body, isn't inlining /always/ (not just "typically", but
> actually *always*) going to increase code size?

Nope.  C++ is full of tiny functions that (for example) get or set one
value of a class.  Inlining them strictly reduces code size.

regression hunt tools

[Janis Johnson]

***
Warning: Your file, reghunt-20070417.tar.bz2, contains more than 32 files after 
decompression and cannot be scanned.
***


Here's a set of my current regression hunt tools, along with a set of
example configuration files and test scripts and a README file that
is more of a brain dump than adequate documentation.  I'm looking for
a few brave souls to try these out on open problem reports that are
known to be regressions and then provide feedback to make the tools
more usable for people other than just me.  The goal is to add them
to contrib/reghunt in the GCC sources.  Comments in the files say they
are copyright FSF and covered by GPL v2 or later.

Enjoy!

Janis



reghunt-20070417.tar.bz2
Description: BZip2 compressed data

Re: CompileFarm and reghunt Was: GCC 4.2.0 Status Report (2007-04-15)

[Janis Johnson]

On Mon, Apr 16, 2007 at 10:09:35PM +0200, Laurent GUERBY wrote:
> On Mon, 2007-04-16 at 12:00 -0600, Tom Tromey wrote:
> > I wonder whether there is a role for the gcc compile farm in this?
> > For instance perhaps "someone" could keep a set of builds there and
> > provide folks with a simple way to regression-test ... like a shell
> > script that takes a .i file, ssh's to the farm, and does a reghunt... ?
> > 
> > I think this would only be worthwhile if the farm has enough disk, and
> > if regression hunting is a fairly common activity.
> > 
> > Tom
> 
> We're a bit "short" on the current CompileFarm machines,
> we have 5x16GB + 4x32GB (and as shown below it tends to
> be used, I have to ping users from time to time to get GB
> back :).
> 
> There is enough cpu power in the farm to build and check a version for
> each commit (all languages including Ada) on up to two branches (I sent
> a message a while ago about that) with a latency of about 8 hours IIRC.
> 
> We might be able to store only part of the compiler, or if this
> proves really useful, I could just add a storage unit to the
> farm with cheap & large current generation disks (machines are
> unfortunately SCSI based).
> 
> As announced a few weeks ago, all official releases are already
> installed on the CompileFarm (/n/b01/guerby/release/X.Y.Z/bin with X.Y.Z
> in 3.4.6, 4.0.0-4, 4.1.0-2).

Regression hunts using saved binaries are useful for some cases but
not all.  They are useful, for example, for narrowing down the range
to search for a front end bug.  They are not useful for finding bugs
for a specific target, other than the ones for which binaries are
saved, or for finding wrong-code bugs, or bugs in functionality that
is not enabled by default.  Unless a compiler is saved for every
revision, determining the patch at fault requires either time from
an experienced person looking through ChangeLog entries or else an
automated hunt for the smaller time period, but since the hunt uses
a binary search, it doesn't take that much longer to search for a
period of months than it does to search for patches applied in a 
single day.

About one-fourth of the regression hunts that I've run have required
some kind of manual intervention because the test wasn't set up
correctly, a build failed, or something unexpected happened when the
test was run with one of the compilers within the range.  No matter
how automated the hunts are, they always need at least a small amount
of individual attention.

A regression hunt setup requires a local copy of the GCC Subversion
repository, which takes LOTS of space.  If one of the CompileFarm
systems already has a copy of the repository, or can get more disk
space to handle one, then it would be great to have a regression hunt
setup on it as well.  The official releases of GCC installed on those
machines would be very useful in narrowing down ranges (and for
reporting information about regressions in general).  It would also
help to keep a mainline build from every few months.

I've posted my current reghunt tools in separate mail; see 
http://gcc.gnu.org/ml/gcc/2007-04/msg00635.html.

Janis

HTML of -fdump-tree-XXXX proposal.

[J.C. Pizarro]

Hello,

i've an idea to improve the report of -fdump-tree- using the HTML
format for its output.

I recommend XHTML-1.0 (26-Jan-2000) from http://www.w3.org/TR/xhtml1/

Note: HTML-4.01 (24-Dec-1999) from http://www.w3.org/TR/html401/
is very popular but very old and it's not XML-1.0 (16-Aug-2006) format
from http://www.w3.org/TR/xml/ implying that HTML-4.01 is hardful for
some parsers.

The proposal is instead of

gcc $CFLAGS -fdump-tree-ssa file.c
gcc $CFLAGS -fdump-tree-gimple file.c

to use the -html option for -fdump-tree- like so

gcc $CFLAGS -html -fdump-tree-ssa file.c
gcc $CFLAGS -html -fdump-tree-gimple file.c

and they will generate the files

file.c.tXX.ssa.html and file.c.tXX.gimple.html

instead of

file.c.tXX.ssa and file.c.tXX.gimple

Why? There are a good reason for ".ssa" principally.

1. To use "charset=utf-8" or &#number; from HTML for greek symbols.
2. Is better to use subscripted numbers than numbers.
3. There is a greek symbol for PHI-function
   ( e.g. # X_1 = PHI ; )
4. Underlining or middlelining the instructions, operands or labels
   marked like dead by example.
5. Etc.

The visual representation in HTML is more effective for humans than
in text.

Sincerely, J.C. Pizarro :)

Re: HTML of -fdump-tree-XXXX proposal.

[Diego Novillo]

J.C. Pizarro wrote on 04/17/07 21:48:

> The visual representation in HTML is more effective for humans than
> in text.

No.  Heck, no.

Re: Call to arms: testsuite failures on various targets

[Kaveh R. GHAZI]

On Thu, 12 Apr 2007, FX Coudert wrote:

> Hi all,
>
> I reviewed this afternoon the postings from the gcc-testresults
> mailing-list for the past month, and we have a couple of gfortran
> testsuite failures showing up on various targets. Could people with
> access to said targets (possibly maintainers) please file PRs in
> bugzilla for each testcase, reporting the error message and/or
> backtrace? (I'd be happy to be added to the Cc list of these)
>
> [...]
> * sparc{,64}-sun-solaris2.10: gfortran.dg/open_errors.f90 gfortran.dg/
> vect/vect-5.f90 (and gfortran.dg/cray_pointers_2.f90 when using -fPIC)

The cray_pointers_2.f90 failure is already noted under PR30774, it's a
solaris issue not necessarily specific to fortran.

The other two, I've opened PRs 31615 and 31616.

--Kaveh
--
Kaveh R. Ghazi  [EMAIL PROTECTED]

Re: HTML of -fdump-tree-XXXX proposal.

[David Daney]

Diego Novillo wrote:

J.C. Pizarro wrote on 04/17/07 21:48:

  

The visual representation in HTML is more effective for humans than
in text.



No.  Heck, no.
  

I agree.  PDF is clearly superior ;-)

J.C., Please submit a patch for PDF support.

David Daney

Re: GCC -On optimization passes: flag and doc issues

[Steven Bosscher]

On 4/18/07, Joe Buck <[EMAIL PROTECTED]> wrote:

Perhaps the number of arguments should be taken into account as well.


We've been doing that for years.

Gr.
Steven