On Sat, Jan 31, 2009 at 5:01 AM, Sean Callanan wrote:
> Dear mailing list:
>
> My research group (the High-Confidence Operating Systems group at Stony
> Brook University;
> home page http://www.fsl.cs.sunysb.edu/hcos/) continues to use a modified
> branch of
> Subversion GCC that hosts plug-ins wr
On Sat, Jan 31, 2009 at 5:26 AM, Kaveh R. Ghazi wrote:
> From: "Tobias Burnus"
>
>> Hi Kaveh,
>>
>> Kaveh R. GHAZI wrote:
>>>
>>> I'm trying to create complex number expressions that contain inf or
>>> nan in the imaginary part. I.e. (0 + inf I) or (0 + nan I).
>>
>> If it does not need to be C
Status
==
The trunk remains Stage 4, so only fixes for regressions (and changes
to documentation) are allowed.
The number of P1, P2 and P3 regressions is already under 100 and the only
remaining P1 has a patch approved. The old register allocator has been
removed. The 4.4 branch will be cre
Adam Nemet writes:
> -msym32 changes DWARF's address_size from 64 bits to 32 bits. This means that
> while symbols are 64-bit (due to ELF64), target addresses in the debug info
> are 32-bit.
>
> There is support for this in DWARF of course in fact you can specify different
> address_size for each
On Fri, Jan 30, 2009 at 23:01, Sean Callanan wrote:
> We've been off the ML for some time, but we're still out there.
> Is this something that is wanted, or have we been overtaken
> by events and should be porting to someone else's
> implementation?
Thanks for raising the issue. The last time w
On Sat, Jan 31, 2009 at 2:11 PM, Diego Novillo wrote:
> On Fri, Jan 30, 2009 at 23:01, Sean Callanan wrote:
>
>> We've been off the ML for some time, but we're still out there.
>> Is this something that is wanted, or have we been overtaken
>> by events and should be porting to someone else's
>> i
On Sat, Jan 31, 2009 at 08:24, Richard Guenther
wrote:
> On Sat, Jan 31, 2009 at 2:11 PM, Diego Novillo wrote:
>>
>> 1- Agree on a common API and document it in
>> http://gcc.gnu.org/wiki/GCC_PluginAPI
>
> Note that even for this taks being able to compare what the existing
> frameworks
> impl
Hi all,
Just to mention that we nearly finished the developments of the new GCC ICI
on top of the latest branch (Zbigniew Chamski is working on that) and
are finishing the documentation on Wiki. It was enhanced based on the feedback
of the current users while still keeping the core code of the plu
On Sat, Jan 31, 2009 at 4:34 AM, Jakub Jelinek wrote:
> Status
> ==
>
> The trunk remains Stage 4, so only fixes for regressions (and changes
> to documentation) are allowed.
>
> The number of P1, P2 and P3 regressions is already under 100 and the only
> remaining P1 has a patch approved. The
H.J. Lu wrote:
> On Sat, Jan 31, 2009 at 4:34 AM, Jakub Jelinek wrote:
>> Status
>> ==
>>
>> The trunk remains Stage 4, so only fixes for regressions (and changes
>> to documentation) are allowed.
>>
>> The number of P1, P2 and P3 regressions is already under 100 and the only
>> remaining P1 h
> removed. The 4.4 branch will be created when all the P1 fixes are committed
> and the licensing changes (see the GCC Runtime Library Exception thread on
> gcc mailing list) land on the trunk.
I noticed sometime ago that two files in the PA backend were incorrectly
changed from GPL 2 to GPL 3.
On Sat, Jan 31, 2009 at 6:57 PM, John David Anglin
wrote:
>> removed. The 4.4 branch will be created when all the P1 fixes are committed
>> and the licensing changes (see the GCC Runtime Library Exception thread on
>> gcc mailing list) land on the trunk.
>
> I noticed sometime ago that two files
On Sat, Jan 31, 2009 at 6:48 PM, Dave Korn
wrote:
> H.J. Lu wrote:
>> On Sat, Jan 31, 2009 at 4:34 AM, Jakub Jelinek wrote:
>>> Status
>>> ==
>>>
>>> The trunk remains Stage 4, so only fixes for regressions (and changes
>>> to documentation) are allowed.
>>>
>>> The number of P1, P2 and P3 re
Richard Guenther wrote:
>> Joseph/Jakub, I have all the required OKs to check in the patch for PR38904:
>>
>> http://gcc.gnu.org/ml/gcc-patches/2009-01/threads.html#01133
>>
>> may I quickly check that in before you branch?
>
> Sure.
Thanks, just updating my sandbox right now.
cheers,
From: "Joseph S. Myers"
On Thu, 29 Jan 2009, Kaveh R. GHAZI wrote:
I don't think these results are a bug, rather it's just an artifact of
the
way complex multiplcation is done and having these special values in
See bug 24581. Some aspects are a bug (GCC doesn't handle mixed
real/complex a
Dave Korn wrote:
> Richard Guenther wrote:
>>> Joseph/Jakub, I have all the required OKs to check in the patch for
>>> PR38904:
>>>
>>> http://gcc.gnu.org/ml/gcc-patches/2009-01/threads.html#01133
>>>
>>> may I quickly check that in before you branch?
>> Sure.
>
> Thanks, just updating my sandb
> > I noticed sometime ago that two files in the PA backend were incorrectly
> > changed from GPL 2 to GPL 3. The files are fptr.c and milli64.S. These
> > files are part of libgcc. Could this be corrected when the GCC Runtime
> > Library Exception is done?
>
> I guess it is safer if you do tha
Diego Novillo wrote:
On Fri, Jan 30, 2009 at 23:01, Sean Callanan wrote:
We've been off the ML for some time, but we're still out there.
Is this something that is wanted, or have we been overtaken
by events and should be porting to someone else's
implementation?
Thanks for raising th
On Sat, 31 Jan 2009, Diego Novillo wrote:
> 1- Agree on a common API and document it in
>http://gcc.gnu.org/wiki/GCC_PluginAPI
>
> 2- Create a new branch to implement that common API. The branch
>would *only* be for basic plugin functionality.
I also think it is strongly desirable that
On Sat, 31 Jan 2009, Taras Glek wrote:
> One simple and useful plugin could be a per-function warning suppressor. ie
> functions flagged with user(no-warn-unused-variable) could suppress a
> particular false warning.
I don't really think it makes sense for this to be a plugin; it's generic
infra
On Sat, 31 Jan 2009, Kaveh R. Ghazi wrote:
> From: "Joseph S. Myers"
>
> > On Thu, 29 Jan 2009, Kaveh R. GHAZI wrote:
> >
> > > I don't think these results are a bug, rather it's just an artifact of the
> > > way complex multiplcation is done and having these special values in
> >
> > See bug
>> So my question is whether the saving in the size of the debug info with
>> -msym32 is really worth the trouble here or should we just start generating
>> 64-bit addresses with -msym32?
>
> Generating 64-bit addresses would be fine with me FWIW. I'm not sure
> the current behaviour is exactly de
1- Agree on a common API and document it in
http://gcc.gnu.org/wiki/GCC_PluginAPI
So to get the ball rolling, here are some comments on the API as
documented:
-
(1) register_callback is an unnecessary API. It's already possible to
use dlsym() to get a pointer to a symbol in a plug-in.
23 matches
Mail list logo
