> 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 w
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
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
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
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 th
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
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, c
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 t
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
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*/);
> > >
"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,
> 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
> 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
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
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
> >fol
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
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 compani
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
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:
>
>
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 subrouti
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,
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 spe
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 the
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 initialize
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
> -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 inte
"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
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
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
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.op
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
On 2007/11/29, J.C. Pizarro <[EMAIL PROTECTED]>, i wrote:
> Autovectorization is still a researching issue.
+--++--+ /---\ ++
| unroll-loops | -> | inline-functions | -> < big BBs > -> | autovectorize! |
+--++-
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
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 th
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
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 initializ
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
> arc
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 als
38 matches
Mail list logo
