On 05.03.2011 22:21, Branko Čibej wrote:
> On 05.03.2011 19:52, Stefan Fuhrmann wrote:
>> On 05.03.2011 11:55, Branko Čibej wrote:
>>> On 05.03.2011 11:34, Stefan Fuhrmann wrote:
>>>> I suspect that -fstrict-aliasing (or something similar)
>>>> might have broken svn_temp_deserializer__resolve().
>>>>
>>>> r1078256 tries to circumvent that.
>>> Ahem. Type casting will not help, at least GCC's optimizer sees right
>>> through them.
>> Well, my hypothesis is that the optimizer breaks the
>> code *due to* the casting:
>>
>> *(const char**)ptr = buffer + (size_t)*ptr;
>> assert(*ptr> buffer);
>>
>> might become:
>>
>> temp1 = *ptr;
>> *ptr = buffer + temp1;
>> assert(temp1> buffer);
> Oh I see, you're doing pointer/offset fixups in shared memory. Yah.
> Have you considered using a union { const char*, size_t } instead of a
> pointer? That /should/ be safe even with strict aliasing, as long as you
> always read the union member that you last wrote (which should work fine
> given what you're doing). This way you avoid all the casts, too.
>
>> I would consider that a bug
> ... but it's not, given strict-aliasing semantics ...
You are right. I was simply surprised that these semantics
would cause the compiler to consider two occurrences of
the same address (pointer) within one statement as unrelated.
Of course there is no consistent way one could define a
meaningful scope in which that semantics would not apply.
Just hadn't thought about it too deeply ...
-- Stefan^2.
Received on 2011-03-13 11:45:47 CET