On 12/7/20 4:04 PM, Jason Merrill wrote: > On 12/5/20 7:37 AM, Bernd Edlinger wrote: >> On 12/2/20 7:57 PM, Jason Merrill wrote: >>> On 12/1/20 1:28 PM, Bernd Edlinger wrote:>>>> + tree type = >>> targetm.cxx.guard_mask_bit () >>>> + ? TREE_TYPE (guard) : char_type_node; >>>> + >>>> + if (is_atomic_expensive_p (TYPE_MODE (type))) >>>> + guard = integer_zero_node; >>>> + else >>>> + guard = build_atomic_load_type (guard, MEMMODEL_ACQUIRE, type); >>> >>> It should still work to load a single byte, it just needs to be the >>> least-significant byte. > > I still don't think you need to load the whole word to check the guard bit. >
Of course that is also possible. But I would not expect an address offset and a byte access to be cheaper than a word access. I just saw that get_guard_bits does the same thing: access the first byte if !targetm.cxx.guard_mask_bit () and access the whole word otherwise, which is only there for ARM EABI. >> And this isn't an EABI issue; it looks like the non-EABI code is also broken >> for big-endian targets, both the atomic load and the normal load in >> get_guard_bits. >>> >> >> I think the non-EABI code is always using bit 0 in the first byte, >> by using the endian-neutral #define _GLIBCXX_GUARD_BIT __guard_test_bit (0, >> 1). > > Except that set_guard sets the least-significant bit on all targets. > Hmm, as I said, get_guard_bits gets the guard as a word if !targetm.cxx.guard_mask_bit (), and as the first byte otherwise. Of course it could get the third byte, if !targetm.cxx.guard_mask_bit () && BYTES_BIG_ENDIAN, but it would be more complicated this way, wouldn't it? Bernd. >> Only ARM EABI uses bit 0 in byte 3 if big-endian and bit 0 in byte 0 >> otherwise. >> >> For all other targets when _GLIBCXX_USE_FUTEX is defined, >> __cxa_guard_XXX accesses the value as int* while the memory >> is a 64-bit long, so I could imagine that is an aliasing violation. >> >> >> But nothing that needs to be fixed immediately. > > Agreed. > >> Attached is the corrected patch. >> >> Tested again on arm-none-eabi with arm-sim. >> Is it OK for trunk? >> >> Thanks >> Bernd. >> >>> Jason >>> >
