Hi,
I want to get the profiling data of an application in linux. Now I am
using -pg options of gcc for generating the profile data. then used
gprof for generating profiles. Here I am getting only in terms of
seconds. But I want in millisecond resolution. can anybody help me.
Thanks regards
Hi Vladimir,
On Sat, 18 Mar 2006, Vladimir N. Makarov wrote:
What I am going to do in short perspective is
o work on code quality of some SPECINT tests (e.g. reload is doing
better job for crafty with many multi-registers than YARA)
I haven't looked at the new branch yet, so forgive me
Good morning everyone!
Here's a simple testcase that illustrates what I'm observing in gcc-3.3.3
-snip-
extern void abort (void) __attribute ((noreturn));
int foo (int a, int b)
{
if (a 25)
abort ();
return (a + b);
}
int
On Sun, 19 Mar 2006, Laurent GUERBY wrote:
Are statistics for GCC download available somewhere? I suspect
in these days of broadband that just about everyone gets the full
tarball (especially for releases...).
The FreeSD ports, for example, by default do not build gfortran nor
Java at this
On Sat, Mar 11, 2006 at 12:41:32AM -, Dave Korn wrote:
So, what if the decision it needs to make depends on the stack frame
size of the current function?
How can this possibly be? When the sibcall is done, the current
function's stack frame is removed.
r~
On 20 March 2006 14:45, Richard Henderson wrote:
Hi Richard :)
On Sat, Mar 11, 2006 at 12:41:32AM -, Dave Korn wrote:
So, what if the decision it needs to make depends on the stack frame
size of the current function?
How can this possibly be? When the sibcall is done, the current
On Mon, Mar 20, 2006 at 02:56:00PM -, Dave Korn wrote:
If the stack frame size is 32kB, I need to use a temporary register in the
epilogue to assemble the lo/hi parts of the frame size before adding it to the
SP. In the non-sibcall version of the epilogue[*] it uses one of the
On Mon, Mar 20, 2006 at 12:57:14PM -, Dave Korn wrote:
Taking a look at leaf_function_p, I see that it specifically discounts
sibcalls; why not noreturncalls as well?
Because generally losing unwind information from noreturn calls
is a lose when it comes to debugging.
r~
Michael Matz wrote:
Hi Vladimir,
On Sat, 18 Mar 2006, Vladimir N. Makarov wrote:
What I am going to do in short perspective is
o work on code quality of some SPECINT tests (e.g. reload is doing
better job for crafty with many multi-registers than YARA)
I haven't looked at the new
Paolo Bonzini wrote:
Michael Matz wrote:
Hi Vladimir,
On Sat, 18 Mar 2006, Vladimir N. Makarov wrote:
What I am going to do in short perspective is
o work on code quality of some SPECINT tests (e.g. reload is doing
better job for crafty with many multi-registers than YARA)
The
On 20 March 2006 15:14, Richard Henderson wrote:
On Mon, Mar 20, 2006 at 02:56:00PM -, Dave Korn wrote:
If the stack frame size is 32kB, I need to use a temporary register in
the epilogue to assemble the lo/hi parts of the frame size before adding
it to the SP. In the non-sibcall
On 20 March 2006 15:31, Richard Henderson wrote:
On Mon, Mar 20, 2006 at 12:57:14PM -, Dave Korn wrote:
Taking a look at leaf_function_p, I see that it specifically discounts
sibcalls; why not noreturncalls as well?
Because generally losing unwind information from noreturn calls
is a
The lower-subreg patch that Richard Henderson posted, and that comes
up again and again from time to time, may also help. It does require
a bit of hacking in the MDs (mostly removing the DImode patterns for
logical operations since the middle-end is able to synthesize them on
its own).
Using libmudflap to test a program that uses libxml2, I found that if
a program access a constant pointer in a non-instrumented library,
mudflap thinks that a read violation has occurred.
A simple test that illustrates this is:
a.c:
-
char *p = abc;
Paolo Bonzini [EMAIL PROTECTED] writes:
The lower-subreg patch that Richard Henderson posted, and that
comes up again and again from time to time, may also help. It does
require a bit of hacking in the MDs (mostly removing the DImode
patterns for logical operations since the middle-end
Ling-hua Tseng [EMAIL PROTECTED] writes:
Because I need to use the feature of `length' attribute (i.e., use
get_attr_length() in machine description),
I have to insert NOPs explicitly before performing the pass 58
(shorten) such that the shorten pass can calculate the length of insns
rafael.espindola wrote:
[...]
extern char *p;
[...]
char a = p[0];
[...]
compile and link with
gcc -shared -fPIC a.c -o liba.so
gcc -fmudflap -lmudflap b.c -la -L. -o b
Did the compiler give you a warning about inability to track the
lifetime of p? It should have.
- FChE
Did the compiler give you a warning about inability to track the
lifetime of p? It should have.
No. Not even with -Wall -O2.
gcc -v:
gcc (GCC) 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9)
- FChE
Thanks,
Rafael
Hello again Daniel and all!
I'm still working on building the iWMMXt/EABI/NPTL toolchain. I've got to the
stage where I have everything built upto the final linking of glibc. Sadly
despite making a lot of progress and fixing many problems I am now stuck.
As I previously discovered the current
I'm not sure when this happened, but I noticed on the weekend that there
has been an explosion in the time spent during the alias analysis phase.
using cplusplus-grammer.ii, it use to compile on my machine in about 55
seconds, and its now up to about 150 seconds.
A quick gprof indicated about 60%
On Mar 20, 2006, at 5:18 PM, Andrew MacLeod wrote:
I'm not sure when this happened, but I noticed on the weekend that
there
has been an explosion in the time spent during the alias analysis
phase.
using cplusplus-grammer.ii, it use to compile on my machine in about 55
seconds, and its now up
Mark == Mark Mitchell [EMAIL PROTECTED] writes:
Mark The FSF and GCC SC have decided to move fastjar to savannah, and
Mark stop including it in future GCC releases, which will clarify
Mark this situation. Will someone please volunteer to migrate
Mark fastjar out of our repository?
I'll take it
Tom Tromey wrote:
I am leaning toward putting it into the rhug repository on
sourceware.org, simply because then we (the gcj hackers) won't have to
go through some long project registration process. Speak up if you
have a particular problem with this.
Thanks!
I would prefer it go on
On Sat, 2006-03-18 at 10:24 +0100, Laurent GUERBY wrote:
On Fri, 2006-03-17 at 12:51 -0700, Jeffrey A Law wrote:
I'm not suggesting the FEs deduce more types and track ranges;
that would be rather absurd. What I'm saying is that exposing
these types outside the FE is most likely costing
I don't see any progress on GCOV, so I assume it's up to me to fix
these bugs. I'm writing here to cooperate with GCOV developers to
avoid duplicate work.
There are two gcov maintainers listed in the GCC maintainers file:
gcovJan Hubicka [EMAIL PROTECTED]
gcov
On Mon, 2006-03-20 at 18:55 -0500, Andrew Pinski wrote:
On Mar 20, 2006, at 5:18 PM, Andrew MacLeod wrote:
I'm not sure when this happened, but I noticed on the weekend that
there
has been an explosion in the time spent during the alias analysis
phase.
using cplusplus-grammer.ii, it
Take the following C code:
typedef long atype[];
typedef long atype1[];
int NumSift (atype *a, atype1 *a1)
{
(*a)[0] = 0;
(*a1)[0] = 1;
return (*a)[0];
}
Shouldn't the aliasing set for the type atype be the same as atype1?
In NumSift, shouldn't the store to (*a1)[0] interfere with (*a)[0]
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-20 08:08 ---
Confirmed, this is an enhancement because this is no support at all in libffi
for var args.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
GCC trunk gets this ICE when building glibc. The ICE happens on gcc 4.1 too.
This happens when -O2 is turned on. Here is a reduced testcase to reproduce the
problem.
example.c
==
__thread int *a = 0;
void foo (void)
{
extern int *b;
b = (int *) ((*a));
}
how to reproduce
--- Comment #7 from neil at fnxweb dot com 2006-03-20 08:48 ---
Fair enough; for the record, I did spend an obscene amount of time trying to
make the example more straightforward, but *any* simplification over what I
attached worked OK.
--
Hi,
I just checked recursive I/O which was addressed in PR 19352.
It is declared resolved, but still fails with this example:
program gfcbug32
implicit none
character (len=4) :: str
write (str, '(a)') foo (-1)
write (*,*) Test 1:, str
write (str, '(a)') foo (1234)
write (*,*) Test
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-03-20 09:09 ---
I wonder why this seems to be ppc specific. powerpc64 works, as does i686.
3.3.3 also fails, so probably not a regression.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
Following program generates different outputs for -O1 and -O3 optimization
levels.
#include stdio.h
typedef struct _airInfo{
unsigned int craftNo : 16;
unsigned int onAir:1;
unsigned int numCrew:2;
unsigned int numPassenger:2;
unsigned int onLand:1;
--- Comment #1 from mor_gopal at yahoo dot com 2006-03-20 10:00 ---
Following details are added.
// g++ version info
$ g++ -v
Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-03-20 10:08 ---
*** This bug has been marked as a duplicate of 21920 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #87 from rguenth at gcc dot gnu dot org 2006-03-20 10:08
---
*** Bug 26767 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-20 10:15 ---
Confirmed. -fno-tree-loop-optimize makes it work.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
the float.h hader gets just replaced with another version, it doesn't patch the
system one. Some constants like
#define FP_PLUS_ZERO 2
are thus not defined. I was told that on newer os versions this doesn't get
noticed since these are duplicated in math.h which gets patched.
--
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-03-20
12:49 ---
(In reply to comment #2)
Isn't this just a dup of bug 20861?
... and, in fact, was fixed by the patch for 20861.
I will set this one as resolved tonight.
Paul
--
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #2 from rth at gcc dot gnu dot org 2006-03-20 16:43 ---
Failing to call GOMP_loop_end.
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-20 17:02 ---
float.h is a standard header required to be supplied by the compiler and
FP_PLUS_ZERO is non standard.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from cristipp at excite dot com 2006-03-20 17:07 ---
(In reply to comment #11)
There is an one defintion rule in C++ unlike most other languages which have
weak symbols. And if you are working around it by using hidden symbols well
you are asking to run into
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-20 17:20 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO|
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-20 17:30 ---
First this is a bug but glibc does not support mips-elf as a target though, it
does support mips-linux-gnu though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26765
--- Comment #13 from hjl at lucon dot org 2006-03-20 17:30 ---
FWIW, the current GNU binutils and glibc treat the weak definition in
shared libraries as strong. There is even a whole set of testsuite for
this in the GNU binutils.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21405
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-20 17:56 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from cristipp at excite dot com 2006-03-20 18:32 ---
The problem is not how the dynamic linker treats 'weak' symbols. The problem is
that template originating functions having no version numbers. It just happen
that template originating functions are also marked as weak
The following program fails to link:
[scala] test/fortran cat transpose_10.f90
real(10) :: a(3,3)
a = 1.0_10
a(1,3) = 0.0_10
print *, transpose(a)
end
[scala] test/fortran gfc transpose_10.f90
/tmp/ccaMoldQ.o(.text+0x1b2): In function `MAIN__':
: undefined reference to `_gfortran_transpose_i10'
--- Comment #15 from pluto at agmk dot net 2006-03-20 19:34 ---
see PR19664, PR20218, PR20297.
--
pluto at agmk dot net changed:
What|Removed |Added
CC|
--- Comment #1 from tkoenig at gcc dot gnu dot org 2006-03-20 19:33 ---
Same for reshape, as noted on the mailing list.
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from pluto at agmk dot net 2006-03-20 19:35 ---
(In reply to comment #15)
see PR19664, PR20218, PR20297.
ops, this is the note for C#10.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21405
--- Comment #5 from pedz at easesoftware dot net 2006-03-20 19:40 ---
This is also on 4.0.2.
This is marked as Serverity of enhancement. Can we change that to normal?
--
pedz at easesoftware dot net changed:
What|Removed |Added
--- Comment #7 from cvs-commit at developer dot classpath dot org
2006-03-20 20:03 ---
Subject: Bug 11070
CVSROOT:/cvsroot/classpath
Module name:classpath
Branch:
Changes by: Chris Burdess [EMAIL PROTECTED]06/03/20 19:54:35
Modified files:
.
--- Comment #2 from tkoenig at gcc dot gnu dot org 2006-03-20 20:13 ---
The way to solve is is to add transpose_r_10.c and reshape_r_10.c
to libgfortran's Makefile.am, then regenerating (which I am always a
little afraid of :-) and modifying the front end to call the 'r'
version if
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-20 21:00 ---
Subject: Bug 26629
Author: pinskia
Date: Mon Mar 20 21:00:18 2006
New Revision: 112227
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112227
Log:
2006-03-20 Andrew Pinski [EMAIL PROTECTED]
PR
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-03-20 21:00 ---
Fixed in rev 112227.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
unnamed namespace restricts the visibility of the defined entities
to the source file in which the anonymous namespace is defined.
IMHO gcc should hide by default symbols from anonymous namespaces.
current gcc behaviour exports useless anon. symbols:
... g DF .text ... Base (anonymous
--- Comment #1 from pluto at agmk dot net 2006-03-20 21:08 ---
Created an attachment (id=11074)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11074action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26770
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-20 21:11 ---
*** This bug has been marked as a duplicate of 21581 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-03-20 21:11
---
*** Bug 26770 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
The following code snippet causes an ICE on mainline when compiled with
-fmudflap -O2:
===
extern C
{
extern void __mf_unregister (void*, __SIZE_TYPE__, int) throw();
}
struct A
{
int i;
A(int j) : i(j) { }
};
struct B
{
B(const
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-20 21:52 ---
The ICE is after VRP.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-20 21:54 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from tkoenig at gcc dot gnu dot org 2006-03-20 21:56 ---
Subject: Bug 20935
Author: tkoenig
Date: Mon Mar 20 21:56:00 2006
New Revision: 112230
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112230
Log:
2006-03-20 Thomas Koenig [EMAIL PROTECTED]
PR
Program
#include stdio.h
struct A
{
A() { printf( %p %p\n, buf[0], this ); }
A( int j ) : i(j) { printf( %p %p\n, buf[0], this ); }
A( const A a ) : i(a.i) { printf( %p %p\n, buf[0], this ); }
A operator =( const A a ) { printf( %p %p\n, buf[0], this ); return
*this; }
A operator =(
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-20 22:35 ---
Fixed in 4.0.0, 3.4.6 was the last release of 3.4.x.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from raj dot khem at gmail dot com 2006-03-21 01:20 ---
(In reply to comment #1)
First this is a bug but glibc does not support mips-elf as a target though, it
does support mips-linux-gnu though.
True. I found it on mips-linux-gnu but because I verified the reduced
--- Comment #12 from jason at gcc dot gnu dot org 2006-03-21 02:48 ---
tweak summary
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #6 from bje at gcc dot gnu dot org 2006-03-21 02:54 ---
Based on an investigation of the problem by myself and Tom, it appears to be
due to the object layout chosen for PPC32 (and presumably other) targets.
--
bje at gcc dot gnu dot org changed:
What
--- Comment #5 from jason at gcc dot gnu dot org 2006-03-21 03:19 ---
Subject: Bug 19238
Author: jason
Date: Tue Mar 21 03:19:06 2006
New Revision: 112239
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112239
Log:
PR c++/21764
* c-pragma.c (visstack): Move out of
--- Comment #11 from jason at gcc dot gnu dot org 2006-03-21 03:19 ---
Subject: Bug 21764
Author: jason
Date: Tue Mar 21 03:19:06 2006
New Revision: 112239
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112239
Log:
PR c++/21764
* c-pragma.c (visstack): Move out of
--- Comment #4 from jason at gcc dot gnu dot org 2006-03-21 03:24 ---
I believe that 'hidden' references must bind to a definition in the current
.so, so this is not a bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22063
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #2 from jason at gcc dot gnu dot org 2006-03-21 04:03 ---
Probably the same bug as 17470.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
The attached 9-line file causes a checking=all build of GCC 4.1.0 to exhaust
memory, on both Ubuntu Linux 5.04/2.6.10-6-386 and Mac OSX 10.4.5. It's a
Delta-reduced version of a preprocessed version of the Linux Kernel file
drivers/media/video/msp3400.c, which exhibited the same behavior. The
--- Comment #1 from flash at pobox dot com 2006-03-21 04:22 ---
Created an attachment (id=11075)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11075action=view)
Delta-reduced version
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26774
--- Comment #2 from flash at pobox dot com 2006-03-21 04:23 ---
Created an attachment (id=11076)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11076action=view)
Unreduced preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26774
--- Comment #6 from law at redhat dot com 2006-03-21 05:09 ---
Subject: Re: [4.1/4.2 Regression] missed jump
threading after unroller
On Sat, 2006-02-11 at 00:59 +, pinskia at gcc dot gnu dot org wrote:
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-11
--- Comment #8 from law at redhat dot com 2006-03-21 05:10 ---
Today's patch picks up the missed const-propagation and allows
simplification of the modulo operation.
THere's still the opportunitity to use range information to simplify
a conditional. However, fixing that is just
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net
|dot org
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2006-03-21 06:05
---
Looking at -fdump-tree-original, should the internal unit descriptors in foo
and in main have the same value?
foo (__result, .__result, i)
{
if (*i 0)
{
_gfortran_copy_string (4, __result, 4,
When an alloca() is used with large auto variable area, a stack pointer is not
recovered correctly.
--
Summary: a stack pointer is not recovered correctly when using
alloca.
Product: gcc
Version: 3.4.6
Status: UNCONFIRMED
--- Comment #1 from inaoka dot kazuhiro at renesas dot com 2006-03-21
07:51 ---
Created an attachment (id=11078)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11078action=view)
testcase
m32r-linux-gnu-gcc -S alloca.c
Asm output has the following code.
; EPILOGUE
--- Comment #2 from inaoka dot kazuhiro at renesas dot com 2006-03-21
07:52 ---
Created an attachment (id=11079)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11079action=view)
ng output
NG case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26775
A stack frame can't be recovered when using large auto variable area.
/tmp/ccJXOHSj.s: Assembler messages:
/tmp/ccJXOHSj.s:68: Error: bad instruction `ld24 r4,#16777216'
/tmp/ccJXOHSj.s:83: Error: bad instruction `ld24 r4,#16777216'
/tmp/ccJXOHSj.s:278: Error: bad instruction `ld24 r4,#16777216'
--- Comment #1 from inaoka dot kazuhiro at renesas dot com 2006-03-21
07:58 ---
Created an attachment (id=11080)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11080action=view)
testcase
m32r-linux-gnu-gcc -c large.c
/tmp/ccJXOHSj.s: Assembler messages:
/tmp/ccJXOHSj.s:68:
89 matches
Mail list logo
