----- Am 15. Aug 2025 um 0:02 schrieb Jeff Law jeffreya...@gmail.com:
> On 8/13/25 9:00 PM, Sebastian Huber wrote:
>> Hello Jeff,
>>
>> thanks for your comment.
>>
>> ----- Am 10. Jul 2025 um 16:01 schrieb Jeff Law jeffreya...@gmail.com:
>>
>>> On 7/9/25 11:53 PM, Sebastian Huber wrote:
>>>> There are targets, which only offer 32-bit atomic operations (for
>>>> example 32-bit RISC-V). For these targets, split the 64-bit atomic
>>>> bitwise-or operation into two parts.
>>>>
>>>> For this test case
>>>>
>>>> int a(int i);
>>>> int b(int i);
>>>>
>>>> int f(int i)
>>>> {
>>>> if (i) {
>>>> return a(i);
>>>> } else {
>>>> return b(i);
>>>> }
>>>> }
>>>>
>>>> with options
>>>>
>>>> -O2 -fprofile-update=atomic -fcondition-coverage
> So looking at this again, this is sufficient to show some of the issues.
> I would file this as a bug. I think the question will turn into
> whether or not we want the instrumentation code to try and optimize away
> unnecessary ops or if it should be left to the gimple optimizers.
>
> In the opptimized dump we can see stuff like this:
>
>> __atomic_fetch_or_8 (&__gcov8.f[1], 0, 0);
>
> So that's not going to change the value at &__gcov8.f[1] and we don't
> use the result, so we don't actually need to do the load either. So
> this could in theory just be removed at the gimple phase. Or at least
> that's how it seems to me.
I created a bug report:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121560
--
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
