What the hell gcc?

jochance

If you split assignment via a long i; and float y, halfx; does it still happen?

k5054

That is weird. But better than what clang does at any optimization level above -O0, as per Compiler Explorer for X86-64:

inv_sqrt: # @inv_sqrt
ret

Um, what?

"A little song, a little dance, a little seltzer down your pants" Chuckles the clown

honey the codewitch

no std available here

Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix

Rick York

Visual C++ does not complain about anything with that code. I think this qualifies as a bug.

"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"

honey the codewitch

It very well could be. I've encountered this error in error before, I think? I'm just really hesitant to file a bug against a compiler because I feel like they know a hell of a lot more about C and C++ than I do.

Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix

k5054

What machine are you targeting, and what are the sizes of float and long*?: If you compile this as 32 bit with gcc, you do not get any warnings. Theory: you're compiling in 64 bit mode sizeof(float) = 4 and sizeof(long*) = 8. So what the compiler is trying to tell you is that long i = *(long*)&y the conversion of the float to a pointer, half the bytes are uninitialized. My theory anyway.

"A little song, a little dance, a little seltzer down your pants" Chuckles the clown

honey the codewitch

it's 32-bit GCC My processor can handle 64-bit numbers, but not as a native word. Edit: I'm not sure long isn't 64 bit on this platform, but I've always used long long for that. My CPU will not handle 128-bit words under any circumstances.

Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix

k5054

The issue would arise if the size of a float is less than the size of a pointer. Maybe just ask the compiler to what sizeof(float) and sizeof(void*) return?

"A little song, a little dance, a little seltzer down your pants" Chuckles the clown

honey the codewitch

Thanks. I'll look into it as time and motivation allows. :) Edit: Turns out i had a project open so it was easy enough to check

sizeof(float): 4
sizeof(long*): 4

I checked sizeof long* just to be certain

Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix

k5054

Well, not that then :( Seemed like a good answer at the time. Maybe it's just the type punning that's baffling the compiler?

"A little song, a little dance, a little seltzer down your pants" Chuckles the clown

honey the codewitch

That's my theory, but I'm uncomfortable with it if nothing else because a) I hate assuming compiler bugs. So often it's some effing intricacy of the C or C++ language that is at play, rather than the compiler in error. b) You'd think it would have been found and fixed. Like I said, this isn't the first time I've run into it. The last time was a lot more innocuous - no type aliasing or fudging like that. it was an enum struct type declared as a local variable and initialized at declaration time. :confused: :rolleyes: I'd dig up the old example if i could, but I ended up working around it in order to get the warnings out of my code without using compiler specific pragmas. Edit: Duh. I am not using the latest GCC. I didn't think about that. Could easily be a bug.

Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix

k5054

I get the same warning with gcc-14.1.0, and with x86-64 gcc-trunk over at the compiler explorer, so it's not been fixed so far.

"A little song, a little dance, a little seltzer down your pants" Chuckles the clown

Rick York

As far as I am concerned, the fact that you have this line :

float y     = x;

which is clearly initializing the variable qualifies it as a bug. I can not conceive a situation where that is not a bug.

"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"

honey the codewitch

I didn't think of trying godbolt. I'm really distracted rn on the phone w/ an old friend.

Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix

0x01AA

Quote:

I hate assuming compiler bugs

No, it is definitely not a compiler bug. It is a defined behaviour, there are lots of documents in www which explain the background.

honey the codewitch

0x01AA wrote:

It is a defined behaviour

That's precisely what I was afraid of. :~

Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix

0x01AA

In a message above, you mentioned, there is no std available. But maybe in your environement some kind of bit_cast is available? If not, I think a similar behaviour (to inform the compiler [optimizer]) can be achived with reinterpret_cast, but at the moment I don't remember the document, from where I got this :( Sorry, for my strange English ...

honey the codewitch

It's possible I could do it with reinterpret_cast? I dunno

Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix

0x01AA

Try it ;) I think it simply informs the compiler 'you are aware' about a maybe not safe conversion ...