Hi,
GCC 4.5 already contains such patch.
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01186.html
If you are working on 4.4 branch, you can just apply the patch without problem.
Cheers,
Bingfeng
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On
> Behal
On 02/21/2010 12:13 PM, Richard Guenther wrote:
> On Sun, Feb 21, 2010 at 1:06 PM, Geert Bosch wrote:
>>
>> On Feb 21, 2010, at 06:18, Steven Bosscher wrote:
>>> My point: gcc may fail to attract users (and/or may be losing users)
>>> when it tries to tailor to the needs of minorities.
>>>
>>> IMH
On Mon, Feb 22, 2010 at 11:27 AM, Andrew Haley wrote:
> On 02/21/2010 12:13 PM, Richard Guenther wrote:
>> On Sun, Feb 21, 2010 at 1:06 PM, Geert Bosch wrote:
>>>
>>> On Feb 21, 2010, at 06:18, Steven Bosscher wrote:
My point: gcc may fail to attract users (and/or may be losing users)
w
Hi,
For anyone who still remembers what went on with 3.3.3, in global.c,
set_preference, why is there a bias to set preference for operand 0 of
src?
It is not intuitive and I there's no comment regarding this so I guess
there is some 'assumption' gcc makes regarding the order of operands.
Two gen
On 02/22/2010 12:29 AM, Erik Trulsson wrote:
> On Sun, Feb 21, 2010 at 11:35:11PM +, Dave Korn wrote:
>> On 21/02/2010 22:42, Erik Trulsson wrote:
>>
>>> Yes, it does if the user is using binaries compiled by somebody else,
>>> and that somebody else did not explicitly specify any CPU-flags.
>>
Hi Bingfeng.
Thanks for pointing me at that patch, but it doesn't do what I require,
which is probably fortunate because I would have wasted work otherwise!
My change incorporates the callee function name and caller function
name into the new name (e.g. bar.0.foo), so that we can trace that
name
Hi,
On Sun, 21 Feb 2010, Jon Turner wrote:
> I have recently encountered a gross inaccuracy in gprof that
> I can't explain. Yes, I know gprof uses a sampling technique
This is incorrect. Code compiled with -pg will call mcount on each
function entry. If there are many calls (compared to othe
Quoting "Paulo J. Matos" :
Hi,
For anyone who still remembers what went on with 3.3.3, in global.c,
set_preference, why is there a bias to set preference for operand 0 of
src?
I don't remember the detail of this specific code, but in general operand 0
is mostly used as an output operand; if a
Quoting Michael Matz :
Hi,
On Sun, 21 Feb 2010, Jon Turner wrote:
I have recently encountered a gross inaccuracy in gprof that
I can't explain. Yes, I know gprof uses a sampling technique
This is incorrect. Code compiled with -pg will call mcount on each
function entry. If there are many
You're not listening. I am using -pg and the program is statically
linked. The concern I am raising is not about the function counting,
but the reported running times, which are determined by sampling
(read the gprof manual, if this is news to you).
In this case, the mcount overhead cannot accoun
Hi Jon,
What does ldd says about your executable?
Thanks
++Cyrille
-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Jon
Turner
Sent: Monday, February 22, 2010 3:44 PM
To: Joern Rennecke
Cc: Michael Matz; gcc@gcc.gnu.org
Subject: Re: Gprof can ac
Hi Jon,
On Mon, Feb 22, 2010 at 08:43:31AM -0600, Jon Turner wrote:
> You're not listening. I am using -pg and the program is statically
> linked. The concern I am raising is not about the function counting,
> but the reported running times, which are determined by sampling
> (read the gprof manual
On 22/02/2010 14:43, Jon Turner wrote:
> You're not listening. I am using -pg and the program is statically
> linked.
> It conceivably I am doing something wrong. I hope so, since
> once I know what it is, I can fix it.
Providing a simple reproducible testcase with steps to reproduce the prob
On 22/02/2010 11:04, Andrew Haley wrote:
> On 02/22/2010 12:29 AM, Erik Trulsson wrote:
>> On Sun, Feb 21, 2010 at 11:35:11PM +, Dave Korn wrote:
>>> On 21/02/2010 22:42, Erik Trulsson wrote:
>>>
Yes, it does if the user is using binaries compiled by somebody else,
and that somebody e
Hello,
I'm cross-compiling glibc(eglibc) for new processor.
As far as I can see -fno-toplevel-reorder option is critical for
successful build.
Without option some files (initfini.c, source for crt*.o) can be miscompiled.
I've heard that option might become deprecated in future gcc versions
(e.g.
2010/2/20 Richard Guenther :
> On Sat, Feb 20, 2010 at 1:38 PM, Christoph Rupp wrote:
[...]
>> I fixed all warnings regarding dereferencing type-punned pointers and
>> I compile with -O3 AND -fno-strict-aliasing.
>>
>> and i still get the same crash as earlier. it does not crash with -O2.
>>
>> Fr
Sergey Yakoushkin writes:
> I'm cross-compiling glibc(eglibc) for new processor.
> As far as I can see -fno-toplevel-reorder option is critical for
> successful build.
> Without option some files (initfini.c, source for crt*.o) can be miscompiled.
>
> I've heard that option might become deprecate
Dave Korn wrote:
On 21/02/2010 20:03, Martin Guy wrote:
The point about defaults is that the GCC default tends to filter down
into the default for distributions;
I'd find it surprising if that was really the way it happens; don't
distributions make deliberate and conscious decisions abou
Hi, Ian
I mean exactly -fno-toplevel-reorder option. There are some compilers
which don't support it.
If option is going to deprecate in gcc in near future as well, than it
make sense to consider changes in glibc(eglibc).
So, there are no plans to deprecate option. Did I understand correctly?
Ser
On 22/02/2010 20:32, Toon Moene wrote:
[ Not singling you out here, yours just happens to be the latest reply: ]
> Dave Korn wrote:
>
>> On 21/02/2010 20:03, Martin Guy wrote:
>
>>> The point about defaults is that the GCC default tends to filter down
>>> into the default for distributions;
>>
On Mon, 2010-02-22 at 21:17 +0100, Christoph Rupp wrote:
> 2010/2/20 Richard Guenther :
> > On Sat, Feb 20, 2010 at 1:38 PM, Christoph Rupp wrote:
> [...]
> >> I fixed all warnings regarding dereferencing type-punned pointers and
> >> I compile with -O3 AND -fno-strict-aliasing.
> >>
> >> and i st
On Mon, Feb 22, 2010 at 1:06 PM, Janis Johnson wrote:
> If you can reproduce the problem with a small, self-contained test then
> please file a bug report. It might be possible to issue a warning or
> to detect that the loop should not be vectorized. If not, maybe the
> compiler should disable v
On Mon, 2010-02-22 at 13:11 -0800, Andrew Pinski wrote:
> On Mon, Feb 22, 2010 at 1:06 PM, Janis Johnson wrote:
> > If you can reproduce the problem with a small, self-contained test then
> > please file a bug report. It might be possible to issue a warning or
> > to detect that the loop should n
On Mon, Feb 22, 2010 at 03:23:52PM -0600, Jon Turner wrote:
> In it, you will find a directory with all the source code
> needed to observe the problem for yourself.
> The top level directory contains a linux executable called
> maxFlo, which you should be able to run on a linux box
> as is. But if
Ok, this is not as simple as I would like to make it,
but hopefully it's simple enough. I've placed a tar file at
www.arl.wustl.edu/~jst/gprof-tarfile
In it, you will find a directory with all the source code
needed to observe the problem for yourself.
The top level directory contains a linux ex
Sergey Yakoushkin writes:
> I mean exactly -fno-toplevel-reorder option. There are some compilers
> which don't support it.
Yes. The option was introduced in gcc 4.2.
> If option is going to deprecate in gcc in near future as well, than it
> make sense to consider changes in glibc(eglibc).
> S
Doh! Thanks, Nathan. I think you put your finger on it.
I was well aware of the overhead that gprof can introduce,
but did not recognize that this overhead was not being
counted by gprof.
Jon
Nathan Froyd wrote:
On Mon, Feb 22, 2010 at 03:23:52PM -0600, Jon Turner wrote:
In it, you will find a
On Mon, Feb 22, 2010 at 05:09:53PM -0600, Jon Turner wrote:
> Doh! Thanks, Nathan. I think you put your finger on it.
> I was well aware of the overhead that gprof can introduce,
> but did not recognize that this overhead was not being
> counted by gprof.
gprof generally does not have any support
Daniel Jacobowitz writes:
> gprof generally does not have any support for shared libraries. It
> will ignore profiling samples that lie outside the executable. And in
> this case, that includes _mcount (which is in libc.so.6). That's
> probably why.
Even when statically linked, gprof will alw
I am trying to build an eabi cross tool-chain for the arm using
version 4.3.3. I noticed from earlier mailing list posts that the
configuration flag --disable-libunwind-exceptions is not working as
intended and that --without-system-unwind is the preferred flag. I
wonder what is the change in the
30 matches
Mail list logo
