> Sounds like you're almost in need of a generic data marshalling interface
> here.
>
Why do we need the complication of data marshaling?
I don't see why we need to define that all plugin hooks have the same
function interface as currently proposed. I.e. a single void*. This
makes a lot of w
Snapshot gcc-4.3-20081009 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20081009/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
[EMAIL PROTECTED] wrote:
Is anyone else seeing a long compile time on
gcc-c-torture/compile/limits-fnargs.c with -O2 optimization? limits-fnargs.c
contains a single call to a function with 10,000 arguments.
There is PR 31850 which talks about compile time on limits-fnargs.c,
but this was fixed
Is anyone else seeing a long compile time on
gcc-c-torture/compile/limits-fnargs.c with -O2 optimization? limits-fnargs.c
contains a single call to a function with 10,000 arguments.
There is PR 31850 which talks about compile time on limits-fnargs.c,
but this was fixed (at least on IA64, if not
Hi All,
I am having trouble distinguishing div vs mod while implementing the
divmodsi4 instruction. The gccint documentation states:
"If an instruction that just produces a quotient or just a remainder
exists and is more efficient than the instruction that produces both,
write the output routine o
On Thu, Oct 09, 2008 at 06:02:40PM +0200, Grigori Fursin wrote:
> Well, I see the point and I am fine with that. And as I mentioned I can
> continue
> using some patches for my projects that currently use environment variables
> or later
> move to the GCC wrappers if the majority decides not to
Taras Glek wrote on 09 October 2008 17:37:
> Grigori Fursin wrote:
>> Well, we need to return values or even structures using plugins for our
>> MILEPOST project
>> to tune cost models. A simple example is loop unrolling: in our current
>> plugin implementation (MILEPOST GCC/ICI) we register a pl
Grigori Fursin wrote:
Well, we need to return values or even structures using plugins for our
MILEPOST project
to tune cost models. A simple example is loop unrolling: in our current plugin
implementation
(MILEPOST GCC/ICI) we register a plugin function that will predict loop unrolling and pass
Well, we need to return values or even structures using plugins for our
MILEPOST project
to tune cost models. A simple example is loop unrolling: in our current plugin
implementation
(MILEPOST GCC/ICI) we register a plugin function that will predict loop
unrolling and pass some
code features to
That's right - I just now need to fight my laziness
and at some point write a few lines of code for the wrapper ;) ...
Cheers,
Grigori
> -Original Message-
> From: Dave Korn [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 09, 2008 6:09 PM
> To: 'Grigori Fursin'; 'Diego Novillo'; 'Hu
Hugh Leather wrote:
Aye up all,
I think the env var solution is easier for people to use and
immediately understand. There would be nothing to stop those people
who don't like env vars from using the shell wrapper approach. Why
not allow both?
I think the other replies addressed this que
Grigori Fursin wrote on 09 October 2008 17:03:
> Well, I see the point and I am fine with that. And as I mentioned I can
> continue using some patches for my projects that currently use
> environment variables or later move to the GCC wrappers if the majority
> decides not to support this mode ;)
Well, I see the point and I am fine with that. And as I mentioned I can
continue
using some patches for my projects that currently use environment variables or
later
move to the GCC wrappers if the majority decides not to support this mode ;)
Cheers,
Grigori
> -Original Message-
> Fro
Diego Novillo wrote on 09 October 2008 14:27:
> On Thu, Oct 9, 2008 at 05:26, Hugh Leather <[EMAIL PROTECTED]> wrote:
>
>> I think the env var solution is easier for people to use and
>> immediately understand. There would be nothing to stop those people who
>> don't like env vars from using t
Farlie A wrote:
> Hi,
>
> Would you be willing to consider supporting the PE object formats on the
> ARM based port of ReactOS?
If you are willing to contribute code for this, that's possible indeed.
Otherwise, no one will probably do the work.
Paolo
On Thu, Oct 9, 2008 at 05:26, Hugh Leather <[EMAIL PROTECTED]> wrote:
> I think the env var solution is easier for people to use and immediately
> understand. There would be nothing to stop those people who don't like env
> vars from using the shell wrapper approach. Why not allow both?
Envir
Can I get some updates on this please? Is the public version up for use?
Thanks!
Indu
On Thu, Jul 19, 2007 at 10:32 PM, Rask Ingemann Lambertsen
<[EMAIL PROTECTED]> wrote:
>
> On Thu, Jul 19, 2007 at 04:41:50PM +0200, Indu Bhagat wrote:
> > Hi,
> >
> > I need to study 16-bit binaries (Intel based
Hi,
Would you be willing to consider supporting the PE object formats on the
ARM based port of ReactOS?
(ReactOS is an attempt to reimplement the NT kernel architecture and API
as free software based on publicly
available specifications and API documentation)
Aye up all,
I think the env var solution is easier for people to use and
immediately understand. There would be nothing to stop those people who
don't like env vars from using the shell wrapper approach. Why not
allow both?
Are you sure about this style of event/callback mechanism?
Hallo zurück,
vielen Dank für die Antworten.
Mit z.B. "UNICODE" Unterstützung könnte man ja nicht nur lokalisierte
Sprachversionen anbieten, sondern auch eigene "mathematische
Beschreibungssprachen".
Mit z.B. xml-Karteien, die die einzelnen reservierten Wörter eigens einstellen
können, könnt
Steve Ellcey <[EMAIL PROTECTED]> writes:
> Does that mean you have a patch?
I've added it to PR 32277.
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
21 matches
Mail list logo
