Zdenek Dvorak wrote:
> Hello,
>
> this patch adds documentation for loop analysis and representation of
> loops, as well as other loop-related analyses, and for functions to
> manipulate loops. As I am not a native English speaker, there are
> probably many language errors in the document, so I w
> 2006/7/24, Andrew Pinski <[EMAIL PROTECTED]>:
> > No, GC is just not running as you have too much memory to cause it to
> > run with --disable-checking :).
>
> Oh! Now my performance results have totally different interpretation
> under Linux...
> Laurynas
There is a way to tweek this
Le Tue, Jul 25, 2006 at 12:30:04PM -0500, David Nicol écrivait/wrote:
> On 7/24/06, Laurynas Biveinis <[EMAIL PROTECTED]> wrote:
>
> >[How is it that setting pointers] to NULL can
> >actually increase peak GC memory usage?
>
> I'll guess that during collection phases, the list of
> collectible st
On Tue, 2006-07-25 at 10:49 -0700, Mike Stump wrote:
> On Jul 25, 2006, at 5:00 AM, Rafael Espíndola wrote:
> > In the particular case of two static functions or two static global
> > pointers, it is possible for the compiler to compute it. Isn't it? I
> > think that the linker will reorder the sec
On Jul 25, 2006, at 5:00 AM, Rafael Espíndola wrote:
In the particular case of two static functions or two static global
pointers, it is possible for the compiler to compute it. Isn't it? I
think that the linker will reorder the sections, but not the functions
inside a section.
:-) Your assump
On Jul 24, 2006, at 10:05 PM, Gichuru Riria wrote:
hi all, i help installing gcc 4.0.3
Please try the gcc-help list instead. Also, be sure to check out the
documentation at our web site that explains this in detail. Also,
4.0.3 is old, I'd recommend a newer version as well. Good Luck.
On 7/24/06, Laurynas Biveinis <[EMAIL PROTECTED]> wrote:
[How is it that setting pointers] to NULL can
actually increase peak GC memory usage?
I'll guess that during collection phases, the list of
collectible structures becomes longer.
GCC is just too huge to try and implement reference count
Use prelinking. That works for all relocation types, and doesn't
require additional coding.
It helps, but I still have 10639 relocations during a "import gtk" in
python. The relative table also has the advantage that it is constant
and can be shared.
Ian
Rafael
"Rafael Espíndola" <[EMAIL PROTECTED]> writes:
> The reason why I want to do this is to avoid relocations when a dso is
> loaded.
Use prelinking. That works for all relocation types, and doesn't
require additional coding.
Ian
On 25 July 2006 16:26, Denis Vlasenko wrote:
> I noticed that gcc's div-by-constant optimization is a bit
> suboptimal and want to improve it. I submitted it to
> bugzilla:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28417
>
> but I think "big guys" have no time for such a low-impact thing.
I noticed that gcc's div-by-constant optimization is a bit
suboptimal and want to improve it. I submitted it to
bugzilla:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28417
but I think "big guys" have no time for such a low-impact thing.
I want to do it myself.
However, I need a little helt in und
This isn't possible with global symbols in a DSO because some other
DSO (or indeed the exe) might also define one of the symbols.
Not with hidden symbols. Sorry, I forgot to mention that.
Andrew.
Rafael
On Mon, 24 Jul 2006 19:08:41 +0100, Richard Sandiford <[EMAIL PROTECTED]> wrote:
> You can set up DejaGNU's unix.exp to use rsh and rcp. It's usually
> a case of creating a board file "foo.exp" like this:
...
> and then running with "make -k check RUNTESTFLAGS='--target_board foo'".
>
> FWIW, I ca
2006/7/25, Daniel Berlin <[EMAIL PROTECTED]>:
There probably are.
But at some point, if you are tuning boehm's to this point, what is the
advantage of it over just writing your own collector like ggc-page? :)
Indeed. That's why I always welcome opinions, should I continue with
Boehm's or stop
Rafael Espíndola writes:
> > because that is what the language standard says.
> >
> > In general, the difference between two global pointers is something
> > known only to the linker -- too late to evaluate as constant
> > expression.
> In the particular case of two static functions or two st
On 7/25/06, Christian Wagner <[EMAIL PROTECTED]> wrote:
Hi,
I'm trying to extract information from C++ code during the compilation process.
I need information about declarations, statements, functions (including
parameters and symbol name), source line and source file.
Perhaps you can tell why
"Rafael Espíndola" <[EMAIL PROTECTED]> writes:
>> because that is what the language standard says.
>>
>> In general, the difference between two global pointers is something
>> known only to the linker -- too late to evaluate as constant
>> expression.
> In the particular case of two static functio
Hi,
I'm trying to extract information from C++ code during the compilation process.
I need information about declarations, statements, functions (including
parameters and symbol name), source line and source file.
In my opinion I have two ways to solve this problem:
1) The first one is to find
because that is what the language standard says.
In general, the difference between two global pointers is something
known only to the linker -- too late to evaluate as constant
expression.
In the particular case of two static functions or two static global
pointers, it is possible for the compi
>
> 6) Are there any data objects in GCC, that the only pointers pointing
> to them point to their interiors and not the beginning? If I could
> disable Boehm's interior pointer support, that should boost
> performance in all respects.
There probably are.
But at some point, if you are tuning boeh
Gabriel Dos Reis writes:
> "Rafael Espíndola" <[EMAIL PROTECTED]> writes:
>
> | I am trying to build a table with offsets of global pointers from a
> | given pointer:
> |
> | void *fs[] = {f1 - f1, f2 - f1};
> |
> | where f1 and f2 are functions.
> |
> | GCC is able to figure out that
21 matches
Mail list logo
