[Bug libgomp/32789] Profiling not possible with -fopenmp

[Bug libgomp/32789] Profiling not possible with -fopenmp

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32789

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |MOVED
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
gprof and mcount is under control of glibc project.
There was an old email about this on the glibc side at
https://sourceware.org/legacy-ml/libc-hacker/1999-01/msg00105.html .

[Bug libgomp/32789] Profiling not possible with -fopenmp

[jensseidel at users dot sf dot net]

------- Comment #6 from jensseidel at users dot sf dot net  2007-07-17 11:00 -------
(In reply to comment #4)
> grpof profiling is all done via a call to mcount and mcount is controlled by
> libc (in the GNU/Linux case glibc).   So I doubt this is a GCC bug.> 

OK, for the record: I use OpenSuse 10.2 with glibc 2.5.

According to http://www.cs.utah.edu/dept/old/texinfo/as/gprof.html#SEC1
mcount occurs in the gprof output but I haven't seen this yet (gprof
2.17.50.0.5).

(In reply to comment #5)
> And that is the reason why GCC added atomic builtins when openmp came
> in also.  There are manuals for a reason :).

I don't understand this but it may be off topic. (Should I inform the Open MPI
people about atomic assembler locking code in gcc so that they can reuse it?)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32789

[Bug libgomp/32789] Profiling not possible with -fopenmp

[pinskia at gmail dot com]

------- Comment #5 from pinskia at gmail dot com  2007-07-17 10:26 -------
Subject: Re:  Profiling not possible with -fopenmp

On 17 Jul 2007 10:24:12 -0000, jensseidel at users dot sf dot net
<gcc-bugzilla@gcc.gnu.org> wrote:
> An Open MPI related discussion about atomic operations happened
> the last days, because architecture specific assembler code failed again
> for some exotic platforms.

And that is the reason why GCC added atomic builtins when openmp came
in also.  There are manuals for a reason :).

-- Pinski


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32789

Re: [Bug libgomp/32789] Profiling not possible with -fopenmp

[Andrew Pinski]

On 17 Jul 2007 10:24:12 -0000, jensseidel at users dot sf dot net
<gcc-bugzilla@gcc.gnu.org> wrote:
> An Open MPI related discussion about atomic operations happened
> the last days, because architecture specific assembler code failed again
> for some exotic platforms.

And that is the reason why GCC added atomic builtins when openmp came
in also.  There are manuals for a reason :).

-- Pinski

[Bug libgomp/32789] Profiling not possible with -fopenmp

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2007-07-17 10:24 -------
grpof profiling is all done via a call to mcount and mcount is controlled by
libc (in the GNU/Linux case glibc).   So I doubt this is a GCC bug.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32789

[Bug libgomp/32789] Profiling not possible with -fopenmp

[jensseidel at users dot sf dot net]

------- Comment #3 from jensseidel at users dot sf dot net  2007-07-17 10:24 -------
(In reply to comment #2)
> And to reply to myself, it needs either to use thread local storage to hold the
> counters and then to add some piece of code to fuse the values of the various
> counters at the end of a thread (which might not be easy ?) or to use atomic
> operations (which existence depends on the architecture, but I hope that all
> multi-core processors have such instructions).

(Don't forget about SMP machines, I have a SGI Octane (2 x Mips R12000 CPUs).)

An Open MPI related discussion about atomic operations happened
the last days, because architecture specific assembler code failed again
for some exotic platforms. See e.g.
http://lists.debian.org/debian-mips/2007/07/msg00036.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32789

[Bug libgomp/32789] Profiling not possible with -fopenmp

[theodore dot papadopoulo at sophia dot inria dot fr]

------- Comment #2 from theodore dot papadopoulo at sophia dot inria dot fr  2007-07-17 10:11 -------
And to reply to myself, it needs either to use thread local storage to hold the
counters and then to add some piece of code to fuse the values of the various
counters at the end of a thread (which might not be easy ?) or to use atomic
operations (which existence depends on the architecture, but I hope that all
multi-core processors have such instructions).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32789

[Bug libgomp/32789] Profiling not possible with -fopenmp

[theodore dot papadopoulo at sophia dot inria dot fr]

------- Comment #1 from theodore dot papadopoulo at sophia dot inria dot fr  2007-07-17 09:55 -------
This is similar to the comment (maybe misplaced) of 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31862
The problem, as far as I understand it is that any kind of profiling (gprof,
profile-arcs, probably mudflap, ...) rely on some global variables that would
need
to be made thread local.

I do not know how difficult this would be however....


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32789