On Sat, 2 May 2009, Anthony Green wrote:
> The top level configury suggests that you can simply drop gmp, ppl, etc
> into the top level source dir and they will get configured and used.
> Does this really work?
It is supposed to. I haven't worked on or tested the ppl machinery so I
don't know wh
Thanks Jim and Ian. I've added a secondary_reload which does this:
...
if (code == MEM)
{
if (fp_plus_const_operand(XEXP(x, 0), mode))
{
sri->icode = in_p ? CODE_FOR_reload_insi : CODE_FOR_reload_outsi;
return NO_REGS;
}
where fp_plus_const_operand
Paolo Carlini wrote:
> Ok, thanks. Then, I think I'll implement this, for now. Seems in any
> case conservative to have a link type test identical to the one used in
> libgomp and libgfortran and a fall back to the .s file (as currently used).
>
I committed the below to mainline. Assuming no iss
Paolo Carlini wrote:
>> Subject to fixing the bug I think is present with static-only libgcc
>> functions and C++ shared libraries (so that being able to link an
>> executable with the functions means it is also possible to link libstdc++
>> and have the symbols resolved in that link), it would
On 2009-04-19, at 23:19 +0200, Oliver Kellogg wrote:
> [...]
>
> How about not doing the name expansion in-place but rather
> storing the expanded name in an extra node field?
I haven't received any reaction on this question yet.
Perhaps I could reuse the Str3 field instead? (I haven't looked
int
Oliver Kellogg wrote:
On 2009-04-19, at 23:19 +0200, Oliver Kellogg wrote:
[...]
How about not doing the name expansion in-place but rather
storing the expanded name in an extra node field?
I haven't received any reaction on this question yet.
Perhaps I could reuse the Str3 field instead? (I
Sorry if I'm slow in understanding:
Are you saying that introducing an extra field would
cause problems (memory or other) ?
Do you think it would be okay to use the Str3 field, then?
Thanks.
Robert Dewar wrote:
> Oliver Kellogg wrote:
> > On 2009-04-19, at 23:19 +0200, Oliver Kellogg wrote:
> >>
I just completed a sync to trunk that I have not committed back yet and I get
the following error during bootstrap on the local branch.
libbackend.a(plugin.o): In function `plugin_default_version_check':
/home/jerry/gcc/objdev/gcc/../../gccdev/gcc/plugin.c:825: undefined reference to
`plugin_gc
Snapshot gcc-4.3-20090503 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20090503/
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
> Jan Hubicka:
>
> >There are also few annotations that I would like to add to functions
> >declared in headers where GCC don't know if they are finite so it is not
> >sure it can remove call to them even if it can prove there are no side
> >effects otherwise.
>
> Hi,
>
> You may be interested i
2009/5/4 Joseph S. Myers:
> On Mon, 4 May 2009, Jan Hubicka wrote:
>
>> On mainline I enabled infinite loop removal at
>> -funsafe-loop-optimizations. I would suggest adding
>> -fempty-loops-terminate and make it default for C++? It does not apply
>> for C, right?
>
> You mean for C++0x (I see no
> 2009/5/4 Joseph S. Myers:
> > On Mon, 4 May 2009, Jan Hubicka wrote:
> >
> >> On mainline I enabled infinite loop removal at
> >> -funsafe-loop-optimizations. I would suggest adding
> >> -fempty-loops-terminate and make it default for C++? It does not apply
> >> for C, right?
> >
> > You mean fo
On Mon, 4 May 2009, Jan Hubicka wrote:
> On mainline I enabled infinite loop removal at
> -funsafe-loop-optimizations. I would suggest adding
> -fempty-loops-terminate and make it default for C++? It does not apply
> for C, right?
You mean for C++0x (I see no such rule in C++03), and there is no
On Sun, May 3, 2009 at 4:17 PM, Jonathan Wakely wrote:
>
> Yes, the rule is new for C++0x, and it is in the context of for, while
> and do-while loops only, not recursive calls.
Does this include loops form from gotos also? Because this seems like
it is very limited and not useful for optimizati
Jonathan Wakely:
2009/5/4 Joseph S. Myers:
> On Mon, 4 May 2009, Jan Hubicka wrote:
>
>> On mainline I enabled infinite loop removal at
>> -funsafe-loop-optimizations. I would suggest adding
>> -fempty-loops-terminate and make it default for C++? It does not apply
>> for C, right?
>
> You mean fo
Oliver Kellogg wrote:
Sorry if I'm slow in understanding:
Are you saying that introducing an extra field would
cause problems (memory or other) ?
Do you think it would be okay to use the Str3 field, then?
I don't see that Str3 is free in any of these nodes, what
nodes are you talking about (rem
Robert Dewar wrote:
>
> I don't see that Str3 is free in any of these nodes, what
> nodes are you talking about (remember that Str3 overlaps
> Node3, List3 etc).
Okay.
> How about not doing the name expansion in-place but rather
> storing the expanded name in an extra node field?
>
>
17 matches
Mail list logo
