On Wed, 2009-02-11 at 18:14 -0500, Diego Novillo wrote:
> On Wed, Feb 11, 2009 at 11:46, Pjotr Kourzanov
> wrote:
>
> > Should we not have a way to specify a plugin in the source itself?
> > This could be achieved by tagging a function with a __plugin__
> > attribute (or a #pragma), exporting th
On Wed, 2009-02-11 at 22:47 +, Joseph S. Myers wrote:
> On Wed, 11 Feb 2009, Janis Johnson wrote:
>
> > I'm rewriting function interpret_float_suffix in libcpp/expr.c to fix
> > suffixes in decimal float literal constants for c/33466. While I'm at
> > it I'm fixing suffixes for fixed-point li
On Wed, Feb 11, 2009 at 11:46, Pjotr Kourzanov
wrote:
> Should we not have a way to specify a plugin in the source itself?
> This could be achieved by tagging a function with a __plugin__
> attribute (or a #pragma), exporting the PluginAPI as a bunch of
> built-in functions and having the compil
On Wed, 11 Feb 2009, Janis Johnson wrote:
> I'm rewriting function interpret_float_suffix in libcpp/expr.c to fix
> suffixes in decimal float literal constants for c/33466. While I'm at
> it I'm fixing suffixes for fixed-point literal constants. Currently for
> fixed-point GCC accepts any orderi
Snapshot gcc-4.2-20090211 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20090211/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
"Janis Johnson" wrote:
> On Wed, 2009-02-11 at 10:42 -0800, Fu, Chao-Ying wrote:
> > Janis Johnson wrote:
> > >
> > > I'm rewriting function interpret_float_suffix in libcpp/expr.c to fix
> > > suffixes in decimal float literal constants for c/33466. While I'm at
> > > it I'm fixing suffixes for
On Wed, 2009-02-11 at 10:42 -0800, Fu, Chao-Ying wrote:
> Janis Johnson wrote:
> >
> > I'm rewriting function interpret_float_suffix in libcpp/expr.c to fix
> > suffixes in decimal float literal constants for c/33466. While I'm at
> > it I'm fixing suffixes for fixed-point literal constants.
>
Paolo Bonzini wrote:
>> I think the only reasonable release criteria is zero P1 regressions over
>> some period. 50 P2 regressions doesn't make a release blocker, neither
>> is 49 P2 regressions a clear sign for a non-blocked release.
>
> I agree.
I mostly agree. P1 regressions are, by definit
Janis Johnson wrote:
>
> I'm rewriting function interpret_float_suffix in libcpp/expr.c to fix
> suffixes in decimal float literal constants for c/33466. While I'm at
> it I'm fixing suffixes for fixed-point literal constants.
> Currently for
> fixed-point GCC accepts any ordering of the letter
Janis Johnson writes:
> My question, though, is about the case of the letters in the suffixes.
> N1169 says "note that the suffix is case insensitive"; should I take
> that literally and allow any mix of cases (as GCC currently does), or
> require that the same case be used within a particular su
I'm rewriting function interpret_float_suffix in libcpp/expr.c to fix
suffixes in decimal float literal constants for c/33466. While I'm at
it I'm fixing suffixes for fixed-point literal constants. Currently for
fixed-point GCC accepts any ordering of the letters in the suffix. The
technical rep
Dne 11.02.2009 (sre) ob 16:31 +0100 je Paolo Bonzini zapisal(a):
> > Assuming you have a copyright assignment, just send a patch to
> > gcc-patches with the explanation. This is code which will never be used
> > for any popular target.
>
> The patch is probably small enough that it does not requi
Dear GCC developers,
I've been following the plugins discussion and have seen various
proposals. So far all of them seem to be focusing on plugins as
dynamically linkable libraries (with all associated versioning and
portability ballast). While you could also easily extend that, and
integrate p
> Assuming you have a copyright assignment, just send a patch to
> gcc-patches with the explanation. This is code which will never be used
> for any popular target.
The patch is probably small enough that it does not require assignment,
given the description in his original message.
Paolo
Jaka Močnik writes:
> Dne 10.02.2009 (tor) ob 17:14 -0800 je Ian Lance Taylor zapisal(a):
>> I don't quite see it. highest_outgoing_args_in_use is at least as large
>> as args_size.constant, and that counts the locate.size for each
>> argument. So it should always include the extra padding.
>>
Hi!
Maximilian Nesnidal wrote:
> i don´t recognize that sending an Email to the mailing list will be
> stored in a public archive.
> http://gcc.gnu.org/ml/gcc-help/2009-02/msg00070.html
> I'm not happy with my email address and my name published there.
> Can you please delete my email address and
Hello,
I am trying to build a GCC 4.2.4 cross compiler targeted for
sparc-sun-solaris2.10 and hosted on x86_64-unknown-linux-gnu.
The compiler is configured with:
--target=sparc-sun-solaris2.10\
--disable-nls \
--enable-shared \
--enable-debug \
--enable-threads=posix \
--enable-__cxa_atexitx \
Hi
i don´t recognize that sending an Email to the mailing list will be
stored in a public archive.
http://gcc.gnu.org/ml/gcc-help/2009-02/msg00070.html
I'm not happy with my email address and my name published there.
Can you please delete my email address and my name?
Thank you!
Dne 10.02.2009 (tor) ob 17:14 -0800 je Ian Lance Taylor zapisal(a):
> I don't quite see it. highest_outgoing_args_in_use is at least as large
> as args_size.constant, and that counts the locate.size for each
> argument. So it should always include the extra padding.
>
> That said, it would not b
19 matches
Mail list logo
