:D haha, yeah, the original code actually initializes the value to 0
(and setting r to 0 does not change the resulting code either)
The thing is that I was trying to figure out "the best way (tm)" to
return an optional<T> from a function that reads from a buffer
(the read might fail if the buffer doesn't contain sizeof(T) chars in
it) and was a bit confused with the generated code difference
between clang and GCC, until I realized the thing was only reading one
byte from the buffer, and then I got even more confused with the
redundant store
on the stack that GCC was not removing, as I've never seen GCC
generate that sort of code before in my tests.
Thanks.
2017-11-27 22:39 GMT-03:00 Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx>:
> On Mon, Nov 27, 2017 at 10:02:53PM -0300, Juan Cabrera wrote:
>> int read(const void* buffer)
>> {
>> int r;
>> std::memcpy(&r, buffer, 1);
>> // std::memcpy(&r, buffer, sizeof(r));
>> return r;
>> }
>
> This is undefined behaviour (you are returning uninitialised data).
> Try with int r = 0; instead? (It is still not portable then, but
> at least not undefined behaviour anymore).
>
>> Do you think there's a reason for this or is this just an optimizer bug?
>
> We do not care too much about generating efficient binary code for
> incorrect source code ;-)
>
>
> Segher
