On Jul 1, 2010, at 11:29 PM, Eric Siroker wrote:
Hello Darwin port maintainers,
I'm getting the frontend for the Go programming language to work in
Darwin. I encountered what looks like a bug in Darwin-specific gcc
code.
The Go frontend saves language-specific export information in the
obj
On Mon, 28 Jun 2010, Richard Guenther wrote:
> The trunk is frozen for all changes starting this Wednesday, 20:00 UTC
> in preparation for merging the mem-ref2 branch. The freeze is expected
> to last until early Friday morning. An explicit un-freeze mail will
> be sent as a reply to this mail.
Joern Rennecke writes:
> [...] But if the function is very simple, the only reason to keep
> it would be if its address was taken somewhere, or if we tailcall
> it.
... or to make it available from gdb as an inferior call.
- FChE
On Fri, Jul 2, 2010 at 4:06 PM, Frank Ch. Eigler wrote:
> Joern Rennecke writes:
>
>> [...] But if the function is very simple, the only reason to keep
>> it would be if its address was taken somewhere, or if we tailcall
>> it.
>
> ... or to make it available from gdb as an inferior call.
We do
> The main utility of plugins is that they make developing, testing and
> deploying modifications to gcc easier. I don't think that MS windows users
> will miss too much if they can't dynamically load the plugins, as long
> as their sysadmin can provide them with a linked-in version - the sysadmi
[I proposed removing RIOS support, since it heavily gets in the way
for my project exposing the XER[CA] flag].
My argument is simply this, sorry if it wasn't clear in the last
email, bottom line up front:
- It can just as easily be removed in the future if it is broken for
more than one release
> Quoting Richard Guenther :
>
>> That is, we no longer optimistically assume that comdat functions
>> can be eliminated if there are no callers in the local TU in 4.5
>> (but we did in previous releases).
>
> But if the function is very simple, the only reason to keep it would be
> if its address
Quoting Jan Hubicka :
The behaviour change is about COMDAT functions that are larger than call
overhead but either called just once or small enough so code growth caused
by inlining is smaller than the function body size itself. In these cases
we made the assumption that overall program size wi
> Quoting Jan Hubicka :
>
>> The behaviour change is about COMDAT functions that are larger than call
>> overhead but either called just once or small enough so code growth caused
>> by inlining is smaller than the function body size itself. In these cases
>> we made the assumption that overall pr
Hello All
My understanding of the description of the tag GTY option in
http://gcc.gnu.org/onlinedocs/gccint/GTY-Options.html#GTY-Options is that a
given discriminated union case can have several tags. so in MELT I did code
(file gcc/melt-runtime.h near line 1108 of rev 161710)
[The // c++ like co
10 matches
Mail list logo
