On 09/06/2016 02:38 PM, David Edelsohn wrote: > On Tue, Sep 6, 2016 at 8:14 AM, Nathan Sidwell wrote: >> On 09/06/16 06:57, David Edelsohn wrote: >> >>> What about Jakub's comment in the PR? >>> >>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77378#c6 >> >> >> This needs addressing. Can you clarify PPC behaviour, because I may have >> misunderstood: >> >> 1) PPC currently has 64 bit counters -- but cannot support 64bit atomic ops >> in 32 bit mode. >> >> 2) PPC currently has 32 bit counters anyway. > > The rs6000 port ABIs implement 64 bit "long long" type. The current > code uses LONG_LONG_TYPE_SIZE for the counters. I assume that most > ports don't support native 64 bit atomic operations in 32 bit ABI -- > PowerPC does not. > > The previous code allowed gcov type to be overridden, but I don't > think that it was 32 bit on most targets. > >> >> I had interpreted the comment to be implying #2, but now I'm not so sure. >> >>> The proposed patch seems wrong or at least incomplete. The recent >>> change is imposing a 64 bit DImode counter when producing 32 bit code. >>> PowerPC does support 64 bit atomic operations in 32 bit mode. >> >> >> I'm presuming you've missed a 'NOT' in that sentence. > > Yes, I omitted a "NOT". > > PowerPC64 has 64 bit atomics, but PowerPC32 subset only provides 32 > bit atomics in the ISA. > > If the counters always should be 64 bit, then a poor-man's 64 bit > atomic operation proposed by Jakub seems like a better solution. > > Thanks, David Hi David. I sent the previous email before I read the Jakub's comment. I'm attaching simplified patch (based of the comment), which works for i386 target. I'm testing that on on m68k target. I prefer to have a single type for one config, same what Nathan suggested. I like the idea of poor-man's atomics, I can make an incremental patch. Martin > >> >>> Was there a design decision that profile counters always should be 64 >>> bits? Either 32 bit targets won't support multi-threaded profiling or >>> 32 bit targets can overflow the counter sooner. >> >> >> >>> Which is worse? >>> Which is more likely? >> >> >> My initial thought is that it is probably awkward to support 2 different >> sized counter types in the 'same' config. I.e. 64-bit single-threaded >> counters and 32-bit threaded counters. >> >> nathan