What the hell gcc?

[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 ...