Re: Function specific optimizations call for discussion

[Ramana Radhakrishnan]

Hi Michael,

I had a comment / query regarding Stage 2 where you talk about
Function cloning for different targets.

I understand that the mechanism is to have a hidden function pointer
that actually gets initialized based on the cpuid.

I don't know if it is worth the effort to have debug info also
enhanced to be such that a breakpoint put on the function my_min
actually sets the breakpoint on any of the clones since the logic
would be similar to the same.  This sounds logically similar to the
way that gdb currently handles breakpoints to multiple constructors.

The other option ofcourse is to fake debug information for such to
actually set a breakpoint on the value of the function pointer that
you so set up. I am no DWARF expert but there might be other folks on
the list who might have better ideas about how to implement this.

cheers
Ramana



On Nov 29, 2007 2:27 AM, Michael Meissner <[EMAIL PROTECTED]> wrote:
> One of the things that I've been interested in is adding support to GCC to
> compile individual functions with specific target options.  I first presented 
> a
> draft at the Google mini-summit, and then another draft at the GCC developer
> summit last July.
>
> In the x86 world this would mean saying that an individual function can use
> SSE5 instructions or SSE4.1 instructions.  This would simplify things for
> people who need to write high performance libraries that run on different
> architectures, and need to be optimal on each platform.  Ultimately, the goal
> is to allow hotspot functions to be compiled several times with different
> target specific optimizations.  I would welcome any thoughts or suggestions
> about this proposal.
>
> The proposal is at:
> http://gcc.gnu.org/wiki/FunctionSpecificOpt
>
> Part of the infrastructure work for doing this is already addressed in 
> function
> adaption project and we will work together with that team:
> http://gcc.gnu.org/wiki/functionAdaptation
>
> One of the things that I have considered and not added to the current proposal
> is to change most of the -f, -O, -W options for a function.  This would be
> relatively simple to add once the infrastructure is in place, but it can 
> really
> complicate things, since various optimizations depend on other optimizations
> having been done.  Similarly, the -mtune= and -march= options can overly
> complicate matters.
>
> In addition, attribute(cold) and attribute(hot) will set the optimization 
> level
> to -Os and -O3.
>
> I will be away on vacation from December 3-8th, and not reading mail during
> that time.
>
> --
> Michael Meissner, AMD
> 90 Central Street, MS 83-29, Boxborough, MA, 01719, USA
> [EMAIL PROTECTED]
>
>
>



-- 
Ramana Radhakrishnan
GNU Tools
Celunite Inc.

Re: Function specific optimizations call for discussion

[Ramana Radhakrishnan]

Hi,

Hit the send button a bit too soon on my earlier mail .



> In the x86 world this would mean saying that an individual function can use
> SSE5 instructions or SSE4.1 instructions.  This would simplify things for
> people who need to write high performance libraries that run on different
> architectures, and need to be optimal on each platform.  Ultimately, the goal
> is to allow hotspot functions to be compiled several times with different
> target specific optimizations.  I would welcome any thoughts or suggestions
> about this proposal.

I noticed this from your proposal.

Stage1: Teach the inliner about target specific functions

We will teach the inliner not to inline functions compiled with target
specific optimizations inside of a general function. However, if a
function that has target specific optimizations it should be able to
inline normal functions, or functions compiled with the same set of
target specific optimizations. I estimate that this should take 2
weeks of time.



This is already handled in the inliner and could be handled by
defining the target hook TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P .We use
it in the private port that we maintain to disable inlining of certain
attributed functions like interrupt handlers. The way we do it already
is to look at DECL_ATTRIBUTES of the tree to figure this out. You
would have to munge in the attributes into the DECL_ATTRIBUTES and the
check later when you do the same but I guess you know that already.


cheers
Ramana


On Nov 29, 2007 2:27 AM, Michael Meissner <[EMAIL PROTECTED]> wrote:
> One of the things that I've been interested in is adding support to GCC to
> compile individual functions with specific target options.  I first presented 
> a
> draft at the Google mini-summit, and then another draft at the GCC developer
> summit last July.
>
> In the x86 world this would mean saying that an individual function can use
> SSE5 instructions or SSE4.1 instructions.  This would simplify things for
> people who need to write high performance libraries that run on different
> architectures, and need to be optimal on each platform.  Ultimately, the goal
> is to allow hotspot functions to be compiled several times with different
> target specific optimizations.  I would welcome any thoughts or suggestions
> about this proposal.
>
> The proposal is at:
> http://gcc.gnu.org/wiki/FunctionSpecificOpt
>
> Part of the infrastructure work for doing this is already addressed in 
> function
> adaption project and we will work together with that team:
> http://gcc.gnu.org/wiki/functionAdaptation
>
> One of the things that I have considered and not added to the current proposal
> is to change most of the -f, -O, -W options for a function.  This would be
> relatively simple to add once the infrastructure is in place, but it can 
> really
> complicate things, since various optimizations depend on other optimizations
> having been done.  Similarly, the -mtune= and -march= options can overly
> complicate matters.
>
> In addition, attribute(cold) and attribute(hot) will set the optimization 
> level
> to -Os and -O3.
>
> I will be away on vacation from December 3-8th, and not reading mail during
> that time.
>
> --
> Michael Meissner, AMD
> 90 Central Street, MS 83-29, Boxborough, MA, 01719, USA
> [EMAIL PROTECTED]
>
>
>



-- 
Ramana Radhakrishnan

Fwd: Function specific optimizations call for discussion

[Karthik Kumar]

On Nov 29, 2007 2:09 PM, Ramana Radhakrishnan <[EMAIL PROTECTED]> wrote:
> Hi Michael,
>
> I had a comment / query regarding Stage 2 where you talk about
> Function cloning for different targets.
>
> I understand that the mechanism is to have a hidden function pointer
> that actually gets initialized based on the cpuid.
>
> I don't know if it is worth the effort to have debug info also
> enhanced to be such that a breakpoint put on the function my_min
> actually sets the breakpoint on any of the clones since the logic
> would be similar to the same.  This sounds logically similar to the
> way that gdb currently handles breakpoints to multiple constructors.
>

If the user has written the clone (for manual dispatch), then the
debug info would point to his code version. If it were generated
automatically (stage 2), the information would pertain to the function
cloned multiple times.The disassembly on those breakpoints might be
different, of course.

> The other option ofcourse is to fake debug information for such to
> actually set a breakpoint on the value of the function pointer that
> you so set up. I am no DWARF expert but there might be other folks on
> the list who might have better ideas about how to implement this.
>

There is an idea to modify the dynamic linker to take advantage of the
detection; If in such case, setting a breakpoint would be easier. Then
we wouldn't require indirect calls either. The breakpoints can be set
in each of the clones, and they will be processed only after setting
up the pointer and their subsequent execution.

The idea is to make use of the debugging information as provided by
the inline-cloner.

> cheers
> Ramana

Karthik



-- 
Karthik
http://guilt.bafsoft.net

Re: Function specific optimizations call for discussion

[Ramana Radhakrishnan]

Hi Karthik,

Thanks for your email .

> > Hi Michael,
> >
> > I had a comment / query regarding Stage 2 where you talk about
> > Function cloning for different targets.
> >
> > I understand that the mechanism is to have a hidden function pointer
> > that actually gets initialized based on the cpuid.
> >
> > I don't know if it is worth the effort to have debug info also
> > enhanced to be such that a breakpoint put on the function my_min
> > actually sets the breakpoint on any of the clones since the logic
> > would be similar to the same.  This sounds logically similar to the
> > way that gdb currently handles breakpoints to multiple constructors.
> >
>
> If the user has written the clone (for manual dispatch), then the
> debug info would point to his code version. If it were generated
> automatically (stage 2), the information would pertain to the function
> cloned multiple times.The disassembly on those breakpoints might be
> different, of course.

All I am saying is that while doing the automatic dispatch try and
have debug info in sync with the source written by the user. The
disassembly is not what I am worrying about. Its only the ability to
place breakpoints on all the clones.

b do_min  and voila gdb will automagically put breakpoints on all the clones.


>
> > The other option ofcourse is to fake debug information for such to
> > actually set a breakpoint on the value of the function pointer that
> > you so set up. I am no DWARF expert but there might be other folks on
> > the list who might have better ideas about how to implement this.
> >
>
> There is an idea to modify the dynamic linker to take advantage of the
> detection; If in such case, setting a breakpoint would be easier. Then
> we wouldn't require indirect calls either. The breakpoints can be set
> in each of the clones, and they will be processed only after setting
> up the pointer and their subsequent execution.

Hmmm some kind of dl symbol resolver work where  you have a cloned
attribute for the symbol in ELF and figure out the best clone based on
a runnable hunk which detects the best function . Might increase a bit
of overhead at run time but its a one time expense. If we did
prelinking that could be removed too.

This might preclude my earlier statement.

>
> The idea is to make use of the debugging information as provided by
> the inline-cloner.

All I wanted was the requirement of debug information consistency to
be a part of the proposal for the inline cloner.

cheers
Ramana
>
> > cheers
> > Ramana
>
> Karthik
>



-- 
Ramana Radhakrishnan
GNU Tools
Celunite Inc.

Re: Function specific optimizations call for discussion

[Sylvain Pion]

Michael Meissner a écrit :

One of the things that I've been interested in is adding support to GCC to
compile individual functions with specific target options.  I first presented a
draft at the Google mini-summit, and then another draft at the GCC developer
summit last July.

In the x86 world this would mean saying that an individual function can use
SSE5 instructions or SSE4.1 instructions.  This would simplify things for
people who need to write high performance libraries that run on different
architectures, and need to be optimal on each platform.  Ultimately, the goal
is to allow hotspot functions to be compiled several times with different
target specific optimizations.  I would welcome any thoughts or suggestions
about this proposal.


I'm wondering if this proposal would support specifying things
like adding -frounding-math when compiling specific functions.
( This particular case is connected to pragma FENV_ACCESS though. )

Also, would this work when the functions is inline?
I mean the case when the caller does not have the same attribute,
but the inlined code of the callee still respects the attribute
set for the inlined callee.

--
Sylvain Pion
INRIA Sophia-Antipolis
Geometrica Project-Team
CGAL, http://cgal.org/



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Function specific optimizations call for discussion

[J.C. Pizarro]

On 2007/11/29, Sylvain Pion <[EMAIL PROTECTED]>
> Michael Meissner a écrit :
> > One of the things that I've been interested in is adding support to GCC to
> > compile individual functions with specific target options.  I first 
> > presented a
> > draft at the Google mini-summit, and then another draft at the GCC developer
> > summit last July
> >
> > In the x86 world this would mean saying that an individual function can use
> > SSE5 instructions or SSE4.1 instructions.  This would simplify things for
> > people who need to write high performance libraries that run on different
> > architectures, and need to be optimal on each platform.  Ultimately, the 
> > goal
> > is to allow hotspot functions to be compiled several times with different
> > target specific optimizations.  I would welcome any thoughts or suggestions
> > about this proposal.
>
>
> I'm wondering if this proposal would support specifying things
> like adding -frounding-math when compiling specific functions.
> ( This particular case is connected to pragma FENV_ACCESS though. )
>
>
> Also, would this work when the functions is inline?
> I mean the case when the caller does not have the same attribute,
> but the inlined code of the callee still respects the attribute
> set for the inlined callee.

Autovectorization is still a researching issue.

The generated program/library should depend of the capabilities of present
historical machines from no-SIMD instructions until the last SSE9
instructions set (SSE, SSE2, SSE3, SSE4, SSE4.1, SSE5, 3DNow!, 3DNow+!...)

But there are many distros LiveCDs/LiveDVDs that they don't want to
grow brutally their sizes
(e.g. one specific LiveCD for supporting each one i-arch that has SSEi, i=1..9).

The good solution is extending the ELF format to insert SIMD stubs to unique
portable program/library for historical machines, and the loader will do the
work of choosing the adequate stub for the correspondent old or new machine.

But there is another problem, this strategy doesn't works fully in clusters
with processes's migration (ala old OpenMosix) because OpenMosix only
migrates processes with identical instructions sets to use for all machines.

   J.C.Pizarro

Re: Function specific optimizations call for discussion

[J.C. Pizarro]

On 2007/11/29, J.C. Pizarro <[EMAIL PROTECTED]>, i wrote:
> Autovectorization is still a researching issue.

+--++--+ /---\ ++
| unroll-loops | -> | inline-functions | -> < big BBs > -> | autovectorize! |
+--++--+ \---/ ++

Besides inlining functions, inline non-virtual methods (from C++) too!

   J.C.Pizarro

RE: Bug in builtins.def, the execve. don't use execle, use execel.

[Dave Korn]

On 29 November 2007 00:12, J.C. Pizarro wrote:


> The more weird thing was "..." in middle of the C's stack from
> int execle(const char *path, const char *arg, ..., char * const envp[]);
> extracted from "man execle".

http://www.opengroup.org/onlinepubs/95399/functions/exec.html

 int execle(const char *path, const char *arg0, ... /*,
   (char *)0, char *const envp[]*/);

  Note the comment markers.  The last two 'arguments' are not real args, it is
just a comment to tell you what the last two parameters in the varargs list
should be equal to.


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

Re: Bug in builtins.def, the execve. don't use execle, use execel.

[J.C. Pizarro]

On 2007/11/29, Dave Korn <[EMAIL PROTECTED]> wrote:
> On 29 November 2007 00:12, J.C. Pizarro wrote:
>
>
> > The more weird thing was "..." in middle of the C's stack from
> > int execle(const char *path, const char *arg, ..., char * const envp[]);
> > extracted from "man execle".
>
> http://www.opengroup.org/onlinepubs/95399/functions/exec.html
>
>  int execle(const char *path, const char *arg0, ... /*,
>(char *)0, char *const envp[]*/);
>
>   Note the comment markers.  The last two 'arguments' are not real args, it is
> just a comment to tell you what the last two parameters in the varargs list
> should be equal to.
>
>
> cheers,
>   DaveK
> --
> Can't think of a witty .sigline today

That's absurd complex specification!

The more easy specification will be

int execel(const char *path, const char *arg0, char *const envp[],
... /*, (char *)0*/);

with same functionality but reordered the parameters of the function
following the general pattern of putting '...' in the last position.

   J.C.Pizarro

Re: Bug in builtins.def, the execve. don't use execle, use execel.

[Paolo Bonzini]

The more easy specification will be

int execel(const char *path, const char *arg0, char *const envp[],
... /*, (char *)0*/);

with same functionality but reordered the parameters of the function
following the general pattern of putting '...' in the last position.


Don't blame gcc developers (whose mailing list this is, unless something 
changed recently and I wasn't warned); take the discussion in the 
appropriate places and they'll care to explain you the reasons (maybe).


Paolo

Re: Testsuite infrastructure for comparing outputs

[Janis Johnson]

On Wed, 2007-11-28 at 20:32 -0600, Sebastian Pop wrote:
> On Nov 28, 2007 6:36 PM, Janis Johnson <[EMAIL PROTECTED]> wrote:
> >
> > On Wed, 2007-11-28 at 15:00 -0600, Sebastian Pop wrote:
> > > Hi,
> > >
> > > In a recent update of the page http://gcc.gnu.org/wiki/Graphite I left
> > > the "Testing Lambda and Graphite frameworks" part in the open tasks.
> > > One of the subitems of this task is:
> > >
> > > "Add expect scripts for comparing outputs of testcases compiled with
> > > different options.  For instance compare output of a program compiled
> > > with "-O2" versus "-O2 -fgraphite"."
> > >
> > > Are there already such scripts that we could use?  I suspect that the
> > > answer is not yet.
> >
> > I'm not sure what you mean.  Would it be enough to add -fgraphite to
> > TORTURE_OPTIONS when you run the existing execute tests?
> >
> 
> Sorry for not being clear.
> 
> I want to compile twice a testcase once with an option turned on, and
> another time without that option: this produces two executables.  Then
> I want to compare the outputs of the two executables as they should be
> the same with and without the transformation.  Here is an example:
> 
> gcc -O2 -fgraphite file.c -o ./a
> gcc -O2 -fno-graphite file.c -o ./b
> ./a > output.a
> ./b > output.b
> diff output.a output.b
> 
> And there should be no difference between the outputs.
> 
> My question was whether we have an infrastructure in the gcc testsuite
> that allows to specify the flags to compare, something like:
> 
> /* { dg-same-output "-O2 -fgraphite" "-O2 -fno-graphite" } */
> 
> that would trigger the above commands and succeed when the outputs are
> identical.

Tests in the GCC testsuite are self-checking: they abort if the
results of computations aren't as expected, rather than writing
output that is then compared against expected output.  Most tests
don't depend on specific optimizations and so should pass with
whatever optimizations are used on them.  Torture tests are built
with a variety of optimizations and are expected to pass each
time.  There are sets of options that are used every time the
tests are run, and the person running the tests can override
those to use different, or additional, sets of options.

There are also groups of tests, like those in gcc.dg/vect and
gcc.dg/tree-ssa, that examine dump output to verify that expected
transformations have been done for particular code.

Does this help?  If I'm still missing something then perhaps an
example would help.

Janis

Re: Bug in builtins.def, the execve.

[Ian Lance Taylor]

"J.C. Pizarro" <[EMAIL PROTECTED]> writes:

> builtins.def:635: DEF_EXT_LIB_BUILTIN(BUILT_IN_EXECVE,
> "execve", BT_FN_INT_CONST_STRING_PTR_CONST_STRING_PTR_CONST_STRING,
> ATTR_NOTHROW_LIST)
> 
> Is it BT_FN_INT_CONST_STRING_PTR_CONST_STRING_PTR_CONST_STRING
> a weird bug?
> 
> The correct const symbol is BT_FN_INT_CONST_STRING_PTR_CONST_STRING

No, it isn't.

>From :

extern int execve (__const char *__path, char *__const __argv[],
   char *__const __envp[]) __THROW __nonnull ((1));

Ian

RE: Function specific optimizations call for discussion

[Weddington, Eric]

 

> -Original Message-
> From: Michael Meissner [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, November 28, 2007 1:58 PM
> To: gcc@gcc.gnu.org; [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Function specific optimizations call for discussion
> 
> One of the things that I've been interested in is adding 
> support to GCC to
> compile individual functions with specific target options.  I 
> first presented a
> draft at the Google mini-summit, and then another draft at 
> the GCC developer
> summit last July.
 
> I would welcome any thoughts 
> or suggestions
> about this proposal.

As I spoke to you about this at the Summit, the users of the AVR port,
and I would also postulate the general embedded community, would
*really* like to have this functionality, especially your Stage 1. There
are many AVR, or embedded, applications where they are generally
optimized for size, but have a time-critical function that needs to be
optimized for speed. I would vote for including both the attribute
syntax and the pragma syntax. I have many users who would be more
comfortable with the pragma syntax, despite any shortcomings.

Eric Weddington

Re: Function specific optimizations call for discussion

[Michael Meissner]

On Thu, Nov 29, 2007 at 02:25:46PM +0530, Ramana Radhakrishnan wrote:
> Hi,
> 
> Hit the send button a bit too soon on my earlier mail .
> 
> 
> 
> > In the x86 world this would mean saying that an individual function can use
> > SSE5 instructions or SSE4.1 instructions.  This would simplify things for
> > people who need to write high performance libraries that run on different
> > architectures, and need to be optimal on each platform.  Ultimately, the 
> > goal
> > is to allow hotspot functions to be compiled several times with different
> > target specific optimizations.  I would welcome any thoughts or suggestions
> > about this proposal.
> 
> I noticed this from your proposal.
> 
> Stage1: Teach the inliner about target specific functions
> 
> We will teach the inliner not to inline functions compiled with target
> specific optimizations inside of a general function. However, if a
> function that has target specific optimizations it should be able to
> inline normal functions, or functions compiled with the same set of
> target specific optimizations. I estimate that this should take 2
> weeks of time.
> 
> 
> 
> This is already handled in the inliner and could be handled by
> defining the target hook TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P .We use
> it in the private port that we maintain to disable inlining of certain
> attributed functions like interrupt handlers. The way we do it already
> is to look at DECL_ATTRIBUTES of the tree to figure this out. You
> would have to munge in the attributes into the DECL_ATTRIBUTES and the
> check later when you do the same but I guess you know that already.

Yes, though some of the work will be gluing the pieces together.  I haven't
looked at the inliner in detail right now.

-- 
Michael Meissner, AMD
90 Central Street, MS 83-29, Boxborough, MA, 01719, USA
[EMAIL PROTECTED]

Re: Function specific optimizations call for discussion

[Michael Meissner]

On Thu, Nov 29, 2007 at 02:09:27PM +0530, Ramana Radhakrishnan wrote:
> Hi Michael,
> 
> I had a comment / query regarding Stage 2 where you talk about
> Function cloning for different targets.
> 
> I understand that the mechanism is to have a hidden function pointer
> that actually gets initialized based on the cpuid.
> 
> I don't know if it is worth the effort to have debug info also
> enhanced to be such that a breakpoint put on the function my_min
> actually sets the breakpoint on any of the clones since the logic
> would be similar to the same.  This sounds logically similar to the
> way that gdb currently handles breakpoints to multiple constructors.
> 
> The other option ofcourse is to fake debug information for such to
> actually set a breakpoint on the value of the function pointer that
> you so set up. I am no DWARF expert but there might be other folks on
> the list who might have better ideas about how to implement this.

I must admit I hadn't thought much about debugging.  I guess I was assuming the
cloning that we already support in the compiler had solved the debug problem,
but that is a whole other discussion that is going on right now.

-- 
Michael Meissner, AMD
90 Central Street, MS 83-29, Boxborough, MA, 01719, USA
[EMAIL PROTECTED]

Re: Function specific optimizations call for discussion

[Michael Meissner]

On Thu, Nov 29, 2007 at 12:58:55PM +0100, Sylvain Pion wrote:
> Michael Meissner a écrit :
> >One of the things that I've been interested in is adding support to GCC to
> >compile individual functions with specific target options.  I first 
> >presented a
> >draft at the Google mini-summit, and then another draft at the GCC 
> >developer
> >summit last July.
> >
> >In the x86 world this would mean saying that an individual function can use
> >SSE5 instructions or SSE4.1 instructions.  This would simplify things for
> >people who need to write high performance libraries that run on different
> >architectures, and need to be optimal on each platform.  Ultimately, the 
> >goal
> >is to allow hotspot functions to be compiled several times with different
> >target specific optimizations.  I would welcome any thoughts or suggestions
> >about this proposal.
> 
> I'm wondering if this proposal would support specifying things
> like adding -frounding-math when compiling specific functions.
> ( This particular case is connected to pragma FENV_ACCESS though. )

I imagine it could be made to work once the infrastructure is in place.  I had
forgotten about the C99 math pragmas.

> Also, would this work when the functions is inline?
> I mean the case when the caller does not have the same attribute,
> but the inlined code of the callee still respects the attribute
> set for the inlined callee.

Right now I specify that for stage 1 if a generic function calls a function
with target specific support, that it not be inlined.  However a function with
target specific support can call and inline either generic functions or other
functions with the same target specific options.

-- 
Michael Meissner, AMD
90 Central Street, MS 83-29, Boxborough, MA, 01719, USA
[EMAIL PROTECTED]

Re: Function specific optimizations call for discussion

[Michael Meissner]

On Thu, Nov 29, 2007 at 01:29:51PM -0700, Weddington, Eric wrote:
>  
> 
> > -Original Message-
> > From: Michael Meissner [mailto:[EMAIL PROTECTED] 
> > Sent: Wednesday, November 28, 2007 1:58 PM
> > To: gcc@gcc.gnu.org; [EMAIL PROTECTED]
> > Cc: [EMAIL PROTECTED]
> > Subject: Function specific optimizations call for discussion
> > 
> > One of the things that I've been interested in is adding 
> > support to GCC to
> > compile individual functions with specific target options.  I 
> > first presented a
> > draft at the Google mini-summit, and then another draft at 
> > the GCC developer
> > summit last July.
>  
> > I would welcome any thoughts 
> > or suggestions
> > about this proposal.
> 
> As I spoke to you about this at the Summit, the users of the AVR port,
> and I would also postulate the general embedded community, would
> *really* like to have this functionality, especially your Stage 1. There
> are many AVR, or embedded, applications where they are generally
> optimized for size, but have a time-critical function that needs to be
> optimized for speed. I would vote for including both the attribute
> syntax and the pragma syntax. I have many users who would be more
> comfortable with the pragma syntax, despite any shortcomings.

Yes, I remember that discussion.  I think a lot of people in the embedded
community (and also things like one laptop per child which tend to have small
memory systems) could use the ability to mark cold functions as save space, hot
functions do as much optimization as possible.  For example, Arm users might
want to switch to thumb code generation instead of arm for cold functions.

-- 
Michael Meissner, AMD
90 Central Street, MS 83-29, Boxborough, MA, 01719, USA
[EMAIL PROTECTED]

Re: Function specific optimizations call for discussion

[tbp]

On Nov 29, 2007 9:29 PM, Weddington, Eric <[EMAIL PROTECTED]> wrote:
> and I would also postulate the general embedded community, would
> *really* like to have this functionality, especially your Stage 1. There
> are many AVR, or embedded, applications where they are generally
> optimized for size, but have a time-critical function that needs to be
> optimized for speed.
I would personally, and i think it hasn't been evoked  yet, *really*
like to be able to toggle fast-math (or related flags) per function,
basically for the same reason.

GNAT SVN trunk on PowerPC and SPARC

[Joel Sherrill]

Hi,

I am trying to test some RTEMS specific
Ada modifications on the SVN trunk.
I cannot get simple programs to work.

The SPARC target produces executables
which die very early.  I haven't looked
into them much but something seems bad.

The PowerPC target is passing bad values
into some subroutines and failing in
weird ways later on.

I repeated this with my changes out and
nothing improved.

Can anyone report that Ada works on the
head on a SPARC or PowerPC self-hosted
system?

Thanks.

--joel

Re: Link tests after GCC_NO_EXECUTABLES

[Richard Sandiford]

Mark Mitchell <[EMAIL PROTECTED]> writes:
> However, I think there's a solution.  In particular, on
> libstdc++-v3/configure.ac, we do:
>
> AC_LIBTOOL_DLOPEN
> AM_PROG_LIBTOOL
>
> The AC_LIBTOOL_DLOPEN call enables checking for dlopen support in
> libtool.  The libtool documentation says:
>
>  Enable checking for dlopen support. This macro should be used if
>  the package makes use of the `-dlopen' and `-dlpreopen' flags,
>  otherwise libtool will assume that the system does not support
>  dlopening.  The macro must be called *before* `AC_PROG_LIBTOOL'.
>
> But, for a bare-metal toolchain, I don't think we need that.  So, I'm
> guessing that:
>
>   if test "x${with_newlib}" != "xyes"; then
> AC_LIBTOOL_DLOPEN
>   fi
>
> will fix the problem.  (We already have checks for $with_newlib
> elsewhere in configure.ac, so I think this is in the same spirit, though
> a libstdc++ maintainer would of course be best to review the patch.)

I built a version of binutils that treated an undefined _start as
a hard error.  (I also had another local binutils patch to fix an
unrelated .eh_frame_hdr problem.)  Reverting the libgloss change
and applying the change above introduced no regressions.

Applying this patch would revert to the previous situation of
libgfortran being unbuildable for mips*-elf*.  That's not a regression
from previous releases, and I'm not sure how useful the status quo is.
Even though current mainline can build libgfortran, all tests fail for
simulator testing, and I'm not sure whether you could get it work for
bare-metal boards or not.  It sounds like we've agreed that, if we want
to support libgfortran on targets like mips*-elf*, we should use
libstd++-like with_newlib checks there too.

Perhaps we should turn target-libgfortran off by default for mips*-elf*.
I'll work on a patch to do that if this one is OK.

Richard


Revert:

2007-09-10  Rask Ingemann Lambertsen  <[EMAIL PROTECTED]>

PR other/32154
* configure.ac: For libgloss targets, point the linker to the linker
script, startup code and simulator library.
* configure: Regenerate.

libstdc++-v3/
2007-xx-xx  Mark Mitchell  <[EMAIL PROTECTED]>

* configure.ac: Don't check AC_LIBTOOL_DLOPEN if using newlib.
* configure: Regenerate.

Index: configure.ac
===
--- configure.ac(revision 130491)
+++ configure.ac(working copy)
@@ -399,9 +399,6 @@ if test x$enable_libgomp = x ; then
 esac
 fi
 
-# Default libgloss CPU subdirectory.
-libgloss_dir="$target_cpu"
-
 case "${target}" in
   *-*-chorusos)
 noconfigdirs="$noconfigdirs target-newlib target-libgloss ${libgcj}"
@@ -507,7 +504,6 @@ case "${target}" in
   *) noconfigdirs="$noconfigdirs gdb readline"
 ;;
 esac
-libgloss_dir=wince
 ;;
   arc-*-*)
 noconfigdirs="$noconfigdirs target-libgloss ${libgcj}"
@@ -516,11 +512,9 @@ case "${target}" in
 ;;
   arm-*-coff | strongarm-*-coff | xscale-*-coff)
 noconfigdirs="$noconfigdirs ${libgcj}"
-libgloss_dir=arm
 ;;
   arm-*-elf* | strongarm-*-elf* | xscale-*-elf* | arm*-*-eabi* )
 noconfigdirs="$noconfigdirs target-libffi target-qthreads"
-libgloss_dir=arm
 ;;
   arm*-*-linux-gnueabi)
 noconfigdirs="$noconfigdirs target-qthreads"
@@ -528,11 +522,9 @@ case "${target}" in
 case ${with_newlib} in
   no) noconfigdirs="$noconfigdirs target-newlib target-libgloss"
 esac
-libgloss_dir=arm
 ;;
   arm*-*-symbianelf*)
 noconfigdirs="$noconfigdirs ${libgcj} target-libiberty"
-libgloss_dir=arm
 ;;
   arm-*-pe*)
 noconfigdirs="$noconfigdirs target-libgloss ${libgcj}"
@@ -579,7 +571,6 @@ case "${target}" in
unsupported_languages="$unsupported_languages fortran"
noconfigdirs="$noconfigdirs ${libgcj} target-newlib target-libgloss";;
 esac
-libgloss_dir=cris
 ;;
   crx-*-*)
 noconfigdirs="$noconfigdirs target-libstdc++-v3 target-mudflap ${libgcj}"
@@ -590,9 +581,6 @@ case "${target}" in
   d30v-*-*)
 noconfigdirs="$noconfigdirs ${libgcj} gdb"
 ;;
-  ep9312-*-elf | ep9312-*-coff)
-libgloss_dir=arm
-;;
   fr30-*-elf*)
 noconfigdirs="$noconfigdirs ${libgcj} gdb"
 ;;
@@ -624,9 +612,6 @@ case "${target}" in
   hppa*-hp-hpux11*)
 noconfigdirs="$noconfigdirs ld shellutils"
 ;;
-  hppa*-*-pro*)
-libgloss_dir=pa
-;;
   hppa*-*-*)
 # According to Alexandre Oliva <[EMAIL PROTECTED]>, libjava won't
 # build on HP-UX 10.20.
@@ -647,7 +632,6 @@ case "${target}" in
 ;;
   i[[3456789]]86-*-coff | i[[3456789]]86-*-elf)
 noconfigdirs="$noconfigdirs ${libgcj}"
-libgloss_dir=i386
 ;;
   i[[3456789]]86-*-linux*)
 # The GCC port for glibc1 has no MD_FALLBACK_FRAME_STATE_FOR, so let's
@@ -717,7 +701,6 @@ case "${target}" in
 ;;
   m68hc11-*-*|m6811-*-*|m68hc12-*-*|m6812-*-*)
 noconfigdirs="$noconfigdirs target-libiberty target-libstd

Re: Describing commercial support on our website

[Joe Buck]

On Thu, Nov 29, 2007 at 01:08:26AM +0100, Manuel López-Ibáñez wrote:
> On 29/11/2007, Ben Elliston <[EMAIL PROTECTED]> wrote:
> > > Actually, I wanted to provide some examples, but I couldn't easily
> > > find a list of companies providing commercial support for GCC.
> > > Shouldn't we have such a list in the website in a prominent place?
> >
> > This is explained in the gcc/SERVICE file.
> >
> 
> Perhaps we should have that link in our website + a list specific to GCC.
> 
> By the way, the link is broken. The correct link seems to be
> http://www.fsf.org/resources/service
> 
> I can send a patch, but I think it would be better if we linked to our
> own http://gcc.gnu.org/support page and from there to wherever the FSF
> wants us to link. That way we could include and update ourselves the
> information specific to gcc.

Unfortunately, that's an area that the FSF wants tight control over;
they would be especially cheesed off if we linked to a consultant's page
and the consultant also advertised his/her ability to support proprietary
compiler development.

But the page on fsf.org is outdated and mostly-useless; people are
unlikely to find it.  It should be possible to do something better and
still meet the FSF's requirements (which mainly are that FSF sites don't
promote proprietary software or link to pages that do).

Re: Describing commercial support on our website

[Richard Guenther]

On Nov 29, 2007 11:13 PM, Joe Buck <[EMAIL PROTECTED]> wrote:
>
> On Thu, Nov 29, 2007 at 01:08:26AM +0100, Manuel López-Ibáñez wrote:
> > On 29/11/2007, Ben Elliston <[EMAIL PROTECTED]> wrote:
> > > > Actually, I wanted to provide some examples, but I couldn't easily
> > > > find a list of companies providing commercial support for GCC.
> > > > Shouldn't we have such a list in the website in a prominent place?
> > >
> > > This is explained in the gcc/SERVICE file.
> > >
> >
> > Perhaps we should have that link in our website + a list specific to GCC.
> >
> > By the way, the link is broken. The correct link seems to be
> > http://www.fsf.org/resources/service
> >
> > I can send a patch, but I think it would be better if we linked to our
> > own http://gcc.gnu.org/support page and from there to wherever the FSF
> > wants us to link. That way we could include and update ourselves the
> > information specific to gcc.
>
> Unfortunately, that's an area that the FSF wants tight control over;
> they would be especially cheesed off if we linked to a consultant's page
> and the consultant also advertised his/her ability to support proprietary
> compiler development.
>
> But the page on fsf.org is outdated and mostly-useless; people are
> unlikely to find it.  It should be possible to do something better and
> still meet the FSF's requirements (which mainly are that FSF sites don't
> promote proprietary software or link to pages that do).

So maybe we should instead drop the SERVICE file completely.

Richard.

Re: Link tests after GCC_NO_EXECUTABLES

[Mark Mitchell]

Richard Sandiford wrote:

[I've added the libstdc++ list to this mail.  If the libstdc++
maintainers need more context, I'll be happy to provide pointers, as I'm
sure will others CC'd above.]

>>   if test "x${with_newlib}" != "xyes"; then
>> AC_LIBTOOL_DLOPEN
>>   fi

> Reverting the libgloss change
> and applying the change above introduced no regressions.

Thank you for working on this.

> Perhaps we should turn target-libgfortran off by default for mips*-elf*.

I think that is the right thing to do.  If we want Fortran to work on
bare-metal targets, then we should make it's configure script work like
the libstdc++ one, as you say.

I would like to give the libstdc++ maintainers a chance to comment on
the libstdc++ patch above and Rask and other maintainers a chance to
comment on the libgloss reversion.  I'll pre-approve the patch if no
objections in 48 hours.

Thanks,

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: Bug in builtins.def, the execve. don't use execle, use execel.

[Michael Meissner]

On Thu, Nov 29, 2007 at 05:39:33PM +0100, Paolo Bonzini wrote:
> >The more easy specification will be
> >
> >int execel(const char *path, const char *arg0, char *const envp[],
> >... /*, (char *)0*/);
> >
> >with same functionality but reordered the parameters of the function
> >following the general pattern of putting '...' in the last position.
> 
> Don't blame gcc developers (whose mailing list this is, unless something 
> changed recently and I wasn't warned); take the discussion in the 
> appropriate places and they'll care to explain you the reasons (maybe).
> 
> Paolo

These system calls are part of the Opengroup standard for UNIX (which Linux
adheres to), and they have been around for many years.  At this point, I don't
recall if they were part of the UNIX V7 that is the ancestor of all modern
Linux, UNIX, BSD, etc. systems or whether they first appeared in System III or
BSD 4.2 (early 1980's).  You would need a time machine to change the
functionality.
http://opengroup.org/onlinepubs/009695399/functions/exec.html

Basically the execl function takes the arguments to the program as separate
arguments, ending in a NULL pointer to mark the end of the arguments.  When the
environment support was added to UNIX, the execle call just took the arguments
that execl took, and added the environment pointer argument after the
arguments.  I tend to think the execl* functions are a hack, and think execv*
is better (where you pass the arguments & environment as a vector of char *),
but that is how the function is defined.

-- 
Michael Meissner, AMD
90 Central Street, MS 83-29, Boxborough, MA, 01719, USA
[EMAIL PROTECTED]

Re: Function specific optimizations call for discussion

[Michael Meissner]

On Thu, Nov 29, 2007 at 05:08:11PM +0530, Ramana Radhakrishnan wrote:
> Hi Karthik,
> 
> Thanks for your email .
> 
> > > Hi Michael,
> > >
> > > I had a comment / query regarding Stage 2 where you talk about
> > > Function cloning for different targets.
> > >
> > > I understand that the mechanism is to have a hidden function pointer
> > > that actually gets initialized based on the cpuid.
> > >
> > > I don't know if it is worth the effort to have debug info also
> > > enhanced to be such that a breakpoint put on the function my_min
> > > actually sets the breakpoint on any of the clones since the logic
> > > would be similar to the same.  This sounds logically similar to the
> > > way that gdb currently handles breakpoints to multiple constructors.
> > >
> >
> > If the user has written the clone (for manual dispatch), then the
> > debug info would point to his code version. If it were generated
> > automatically (stage 2), the information would pertain to the function
> > cloned multiple times.The disassembly on those breakpoints might be
> > different, of course.
> 
> All I am saying is that while doing the automatic dispatch try and
> have debug info in sync with the source written by the user. The
> disassembly is not what I am worrying about. Its only the ability to
> place breakpoints on all the clones.
> 
> b do_min  and voila gdb will automagically put breakpoints on all the clones.

Yes, that is the desired goal.
 
> 
> >
> > > The other option ofcourse is to fake debug information for such to
> > > actually set a breakpoint on the value of the function pointer that
> > > you so set up. I am no DWARF expert but there might be other folks on
> > > the list who might have better ideas about how to implement this.
> > >
> >
> > There is an idea to modify the dynamic linker to take advantage of the
> > detection; If in such case, setting a breakpoint would be easier. Then
> > we wouldn't require indirect calls either. The breakpoints can be set
> > in each of the clones, and they will be processed only after setting
> > up the pointer and their subsequent execution.
> 
> Hmmm some kind of dl symbol resolver work where  you have a cloned
> attribute for the symbol in ELF and figure out the best clone based on
> a runnable hunk which detects the best function . Might increase a bit
> of overhead at run time but its a one time expense. If we did
> prelinking that could be removed too.

It would be nice if we could get something like this done.  However, given that
it spans several different groups that don't always talk together (compiler,
glibc, binary utilities, dynamic linker, linux system vendors), it is a much
harder problem to solve.  Also, doing it in the Linux space only, means it
isn't available to the non-Linux gcc users.

One approach is the fat binary approach, where you compile the program N times,
and at runtime the system maps in the correct code image depending on the
target bits.  However, this is very space inefficient.
 
> This might preclude my earlier statement.
> 
> >
> > The idea is to make use of the debugging information as provided by
> > the inline-cloner.
> 
> All I wanted was the requirement of debug information consistency to
> be a part of the proposal for the inline cloner.
> 
> cheers
> Ramana
> >
> > > cheers
> > > Ramana
> >
> > Karthik
> >
> 
> 
> 
> -- 
> Ramana Radhakrishnan
> GNU Tools
> Celunite Inc.
> 
> 

-- 
Michael Meissner, AMD
90 Central Street, MS 83-29, Boxborough, MA, 01719, USA
[EMAIL PROTECTED]

Re: Link tests after GCC_NO_EXECUTABLES

[Benjamin Kosnik]

> I would like to give the libstdc++ maintainers a chance to comment on
> the libstdc++ patch above and Rask and other maintainers a chance to
> comment on the libgloss reversion.  I'll pre-approve the patch if no
> objections in 48 hours.

This looks fine to me.

-benjamin

Re: GNAT SVN trunk on PowerPC and SPARC

[Eric Botcazou]

> Can anyone report that Ada works on the
> head on a SPARC or PowerPC self-hosted
> system?

http://gcc.gnu.org/ml/gcc-testresults/2007-11/msg00945.html

-- 
Eric Botcazou

Re: Bug in builtins.def, the execve. don't use execle, use execel.

[Andreas Schwab]

"Michael Meissner" <[EMAIL PROTECTED]> writes:

> These system calls are part of the Opengroup standard for UNIX (which Linux
> adheres to), and they have been around for many years.  At this point, I don't
> recall if they were part of the UNIX V7 that is the ancestor of all modern
> Linux, UNIX, BSD, etc. systems or whether they first appeared in System III or
> BSD 4.2 (early 1980's).

According to  they were already in
V7.

(I don't think V7 had  yet.)

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Bug in builtins.def, the execve. don't use execle, use execel.

[Joe Buck]

On Thu, Nov 29, 2007 at 05:44:02PM -0500, Michael Meissner wrote:
> On Thu, Nov 29, 2007 at 05:39:33PM +0100, Paolo Bonzini wrote:
> > >The more easy specification will be
> > >
> > >int execel(const char *path, const char *arg0, char *const envp[],
> > >... /*, (char *)0*/);
> > >
> > >with same functionality but reordered the parameters of the function
> > >following the general pattern of putting '...' in the last position.
> > 
> > Don't blame gcc developers (whose mailing list this is, unless something 
> > changed recently and I wasn't warned); take the discussion in the 
> > appropriate places and they'll care to explain you the reasons (maybe).
> > 
> > Paolo
> 
> These system calls are part of the Opengroup standard for UNIX (which Linux
> adheres to), and they have been around for many years.  At this point, I don't
> recall if they were part of the UNIX V7 that is the ancestor of all modern
> Linux, UNIX, BSD, etc. systems or whether they first appeared in System III or
> BSD 4.2 (early 1980's).

V7 only had execl and execv.  The C library was much smaller in those
days; see

http://minnie.tuhs.org/UnixTree/V7/usr/lib/llib-lc.html

for a list of all the calls (as a Lint library).  Those of you who
don't remember K&R C, and lint, might find it a bit confusing.

Re: GNAT SVN trunk on PowerPC and SPARC

[Joel Sherrill]

Eric Botcazou wrote:

Can anyone report that Ada works on the
head on a SPARC or PowerPC self-hosted
system?



http://gcc.gnu.org/ml/gcc-testresults/2007-11/msg00945.html

  

Thanks.  That doesn't appear to be as bad as
what I am seeing. 


Have you seen anything like the gnat1 compile
time I reported yesterday?

http://gcc.gnu.org/ml/gcc/2007-11/msg00791.html

You know.. I turned the optimization of the Ada
run-time from -O2 -> -O0 to work around the
huge compile time.  Is it possible that that
is breaking the run-time?

--joel

Re: Bug in builtins.def, the execve. don't use execle, use execel.

[Michael Meissner]

On Fri, Nov 30, 2007 at 12:17:25AM +0100, Andreas Schwab wrote:
> "Michael Meissner" <[EMAIL PROTECTED]> writes:
> 
> > These system calls are part of the Opengroup standard for UNIX (which Linux
> > adheres to), and they have been around for many years.  At this point, I 
> > don't
> > recall if they were part of the UNIX V7 that is the ancestor of all modern
> > Linux, UNIX, BSD, etc. systems or whether they first appeared in System III 
> > or
> > BSD 4.2 (early 1980's).
> 
> According to  they were already in
> V7.

At this stage of the game, it doesn't matter, since they have been around at
least 20 years.  However, I didn't think the environment varient of the
functions (and main's arguments) was added until after V7.

> (I don't think V7 had  yet.)

By the time I started writing a C compiler for Data General (about 1981),
varargs.h was already provided, though I did run into a lot of programs that
did it the old fashioned way (take address of last argument, and do pointer
arithmetic).  This was just one of the many features that made programming in C
on the Data General MV/Eclipse such a chore (different flavors of pointers was
the main thing, unsigned chars, unsigned shifts, and IBM floating point were
some other features).

-- 
Michael Meissner, AMD
90 Central Street, MS 83-29, Boxborough, MA, 01719, USA
[EMAIL PROTECTED]

Re: Bug in builtins.def, the execve. don't use execle, use execel.

[Michael Meissner]

On Thu, Nov 29, 2007 at 03:18:01PM -0800, Joe Buck wrote:
> On Thu, Nov 29, 2007 at 05:44:02PM -0500, Michael Meissner wrote:
> > On Thu, Nov 29, 2007 at 05:39:33PM +0100, Paolo Bonzini wrote:
> > > >The more easy specification will be
> > > >
> > > >int execel(const char *path, const char *arg0, char *const envp[],
> > > >... /*, (char *)0*/);
> > > >
> > > >with same functionality but reordered the parameters of the function
> > > >following the general pattern of putting '...' in the last position.
> > > 
> > > Don't blame gcc developers (whose mailing list this is, unless something 
> > > changed recently and I wasn't warned); take the discussion in the 
> > > appropriate places and they'll care to explain you the reasons (maybe).
> > > 
> > > Paolo
> > 
> > These system calls are part of the Opengroup standard for UNIX (which Linux
> > adheres to), and they have been around for many years.  At this point, I 
> > don't
> > recall if they were part of the UNIX V7 that is the ancestor of all modern
> > Linux, UNIX, BSD, etc. systems or whether they first appeared in System III 
> > or
> > BSD 4.2 (early 1980's).
> 
> V7 only had execl and execv.  The C library was much smaller in those
> days; see
> 
> http://minnie.tuhs.org/UnixTree/V7/usr/lib/llib-lc.html
> 
> for a list of all the calls (as a Lint library).  Those of you who
> don't remember K&R C, and lint, might find it a bit confusing.

Ah yes, K&R C.  So simple  And then there were the 6-7 years of X3J11
meetings to come out with C89 to add little things like prototypes, stdarg.h,
void *, unsigned short/long types, etc.

Of course if you actually tried to use the grammar in the back of the book, you
would find that it had some typos (such as not being able to describe functions
that returned pointers to functions if memory serves).

-- 
Michael Meissner, AMD
90 Central Street, MS 83-29, Boxborough, MA, 01719, USA
[EMAIL PROTECTED]

Re: Bug in builtins.def, the execve. don't use execle, use execel.

[Joe Buck]

On Thu, Nov 29, 2007 at 06:27:06PM -0500, Michael Meissner wrote:
> On Fri, Nov 30, 2007 at 12:17:25AM +0100, Andreas Schwab wrote:
> > "Michael Meissner" <[EMAIL PROTECTED]> writes:
> > 
> > > These system calls are part of the Opengroup standard for UNIX (which 
> > > Linux
> > > adheres to), and they have been around for many years.  At this point, I 
> > > don't
> > > recall if they were part of the UNIX V7 that is the ancestor of all modern
> > > Linux, UNIX, BSD, etc. systems or whether they first appeared in System 
> > > III or
> > > BSD 4.2 (early 1980's).
> > 
> > According to  they were already in
> > V7.
> 
> At this stage of the game, it doesn't matter, since they have been around at
> least 20 years.  However, I didn't think the environment varient of the
> functions (and main's arguments) was added until after V7.
> 
> > (I don't think V7 had  yet.)

The V7 sources have been freed and are online, so we don't have to rely on
memory.  Yes, V7 had varargs.h, it is at

http://minnie.tuhs.org/UnixTree/V7/usr/include/varargs.h.html

Re: Function specific optimizations call for discussion

[Joseph S. Myers]

On Thu, 29 Nov 2007, Michael Meissner wrote:

> > I'm wondering if this proposal would support specifying things
> > like adding -frounding-math when compiling specific functions.
> > ( This particular case is connected to pragma FENV_ACCESS though. )
> 
> I imagine it could be made to work once the infrastructure is in place.  I had
> forgotten about the C99 math pragmas.

Stephen Moshier's testcases for FENV_ACCESS, attached to PR 20785, may be 
of use (though more tests may also be needed, certainly for the other 
pragmas).

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: gnat1 huge time

[Krister Walfridsson]

On Wed, 28 Nov 2007, Joel Sherrill wrote:


I am trying to get the SVN head built locally again
and back at work on the GNAT/RTEMS work I was doing.
Unfortunately, I have tripped across something that
is quite bad. Compiling on Linux x86 targeting the
PowerPC or SPARC leads to a huge compilation time
on a single file.


FWIW.  I see the same behavior for i386-unknown-netbsdelf3.1 too (when 
compiling natively, i.e. not using cross compiler).


The problem was introduced by revision 125624 (the dataflow merge).

   /Krister

Re: Link tests after GCC_NO_EXECUTABLES

[Mark Mitchell]

Rask Ingemann Lambertsen wrote:

>> Perhaps we should turn target-libgfortran off by default for mips*-elf*.
> 
>No. There is a point in excercising the compiler: Testing. In most cases,
> you don't find problems with the compiler until you try to compile something.

When building the compiler and its libraries, testing is of incidental
benefit; the primary goal is to build things. :-) The testsuite is for
testing things.

It's great to know that gfortran works for other ELF targets.  That
means that there must be something a bit odd in the MIPS support
somewhere, and I'm sure we can find it and fix it.

Thanks for working on the gfortran configure script.  I think it would
be great to make that work like the libstdc++ script.

>This hunk should be left out. And I would prefer that we don't revert the
> patch until everything that builds with the patch also builds without the
> patch.

I don't think that's necessary -- unless these things built with
previous releases, in which case I'd be very concerned about making a
change that caused fewer things to build.  Did this work in 4.2?  I
don't know, but I'm expecting that it did not?

It sounds like we upgraded libtool, and that introduced link-time tests
into libstdc++, which caused build failures.  So you came up with the
top-level patch, which then probably made it possible to build some of
the other target libraries that didn't build before for bare metal
because they had always depended on link-time tests.  Is that correct?

We should be conservative about making changes in assumptions.  If we're
going to change the assumption that target library configure scripts
cannot rely on link-time tests when $with_newlib is set, then let's do
that consciously.  I think it's reasonable to take that position (even
though it's not my preference), but I don't want to change the
assumption quietly.  And, I think libstdc++ is our canonical model of a
run-time library; others should follow its lead, until/unless we
consciously decide otherwise.

I also don't want to see each architecture or run-time library doing
things in different ways.  GCC's biggest strength is its cross-platform
nature; we undermine that every time we do things in slightly different
ways within our own individual areas of concentration.

I'm in no way criticizing you or your top-level patch.  I understand
completely why you did what you did and its benefits.  But, I want to
get everyone on the same page, and until that happens, I want to stick
with how things have been in the past.

>Additionally, I would prefer we call the option something else than
> --with-newlib - suppose there's no newlib for the target. At least the AVR
> uses something else.

That might be a good idea -- I think we do need to know which C library
is in use for at least some of the target libraries.  I'm pretty sure
that libstdc++ actually depends on --with-newlib meaning that you're
using Newlib (rather than some other C library) in that it uses
facilities in Newlib that aren't necessarily part of a standard C
library.  I could be wrong about that, though.

Thanks,

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: Link tests after GCC_NO_EXECUTABLES

[Rask Ingemann Lambertsen]

On Thu, Nov 29, 2007 at 10:05:54PM +, Richard Sandiford wrote:

> Even though current mainline can build libgfortran, all tests fail for
> simulator testing, and I'm not sure whether you could get it work for
> bare-metal boards or not. 

   It works on arm-unknown-elf, v850-unknown-elf and frv-unknown-elf:
http://gcc.gnu.org/ml/gcc-testresults/2007-11/msg01428.html
http://gcc.gnu.org/ml/gcc-testresults/2007-11/msg01468.html
http://gcc.gnu.org/ml/gcc-testresults/2007-11/msg00427.html

   Some work has been and is being done in this area:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185

   Hans, you showed gfortran results for cris-elf, but we don't seem to be
building gfortran for the cris?

> It sounds like we've agreed that, if we want
> to support libgfortran on targets like mips*-elf*, we should use
> libstd++-like with_newlib checks there too.

   Likewise for the other target libraries - how many did you test?

   I tried a build of sparc-unknown-elf (which is know to fail link tests)
with "with_newlib" checks around the AC_LIBTOOL_DLOPEN macro in both
libstdc++ and libgfortran. It fails because:

configure:3391: checking whether symbol versioning is supported
configure:3402: error: Link tests are not allowed after GCC_NO_EXECUTABLES.

With this patch I get marginally further:

Index: libgfortran/configure.ac
===
--- libgfortran/configure.ac(revision 130442)
+++ libgfortran/configure.ac(working copy)
@@ -142,12 +142,14 @@
   global: *foo*; bar; local: *;
 };
 EOF
-save_LDFLAGS="$LDFLAGS"
-LDFLAGS="$LDFLAGS -fPIC -shared -Wl,--version-script,./conftest.map"
-AC_TRY_LINK([int foo;],[],[gfortran_use_symver=yes],[gfortran_use_symver=no])
-LDFLAGS="$save_LDFLAGS"
-AC_MSG_RESULT($gfortran_use_symver)
-AM_CONDITIONAL(LIBGFOR_USE_SYMVER, [test "x$gfortran_use_symver" = xyes])
+if test "x${with_newlib}" != "xyes"; then
+  save_LDFLAGS="$LDFLAGS"
+  LDFLAGS="$LDFLAGS -fPIC -shared -Wl,--version-script,./conftest.map"
+  AC_TRY_LINK([int foo;],[],[gfortran_use_symver=yes],[gfortran_use_symver=no])
+  LDFLAGS="$save_LDFLAGS"
+  AC_MSG_RESULT($gfortran_use_symver)
+  AM_CONDITIONAL(LIBGFOR_USE_SYMVER, [test "x$gfortran_use_symver" = xyes])
+fi

 # Find other programs we need.
 AC_CHECK_TOOL(AS, as)
@@ -158,7 +160,9 @@

 # Configure libtool
 #AC_MSG_NOTICE([== Starting libtool configuration])
-AC_LIBTOOL_DLOPEN
+if test "x${with_newlib}" != "xyes"; then
+  AC_LIBTOOL_DLOPEN
+fi
 AM_PROG_LIBTOOL
 AC_SUBST(enable_shared)
 AC_SUBST(enable_static)

configure:18061: checking for getrusage
configure:18067: error: Link tests are not allowed after GCC_NO_EXECUTABLES.

> Perhaps we should turn target-libgfortran off by default for mips*-elf*.

   No. There is a point in excercising the compiler: Testing. In most cases,
you don't find problems with the compiler until you try to compile something.

> @@ -2410,6 +2368,16 @@ fi
>  
>  # Search for other target-specific linker scripts and such.
>  case "${target}" in
> +  m32c-*-* )
> +if test -d ${srcdir}/libgloss/m32c; then
> +  # This is for crt0.o
> +  FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET' 
> -B$$r/$(TARGET_SUBDIR)/libgloss/m32c'
> +  # This is for r8c.ld
> +  FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET' 
> -L$$r/$(TARGET_SUBDIR)/libgloss/m32c'
> +  # This is for libnosys.a
> +  FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET' 
> -L$$r/$(TARGET_SUBDIR)/libgloss/libnosys'
> +fi
> +;;
>mep*)
>  FLAGS_FOR_TARGET="$FLAGS_FOR_TARGET -mlibrary"
>  ;;

   This hunk should be left out. And I would prefer that we don't revert the
patch until everything that builds with the patch also builds without the
patch.

   Additionally, I would prefer we call the option something else than
--with-newlib - suppose there's no newlib for the target. At least the AVR
uses something else.

-- 
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year

Re: GNAT SVN trunk on PowerPC and SPARC

[Eric Botcazou]

> Thanks.  That doesn't appear to be as bad as
> what I am seeing.

Quite good actually.

> Have you seen anything like the gnat1 compile
> time I reported yesterday?

Try to configure with --enable-checking=release.

> You know.. I turned the optimization of the Ada
> run-time from -O2 -> -O0 to work around the
> huge compile time.  Is it possible that that
> is breaking the run-time?

That should not, in any cases.

-- 
Eric Botcazou