What the hell gcc?
-
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
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*): 4I 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
-
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*): 4I 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
-
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
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
-
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
-
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
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?"
-
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
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
-
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
-
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.
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 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
In a message above, you mentioned, there is no
std
available. But maybe in your environement some kind ofbit_cast
is available? If not, I think a similar behaviour (to inform the compiler [optimizer]) can be achived withreinterpret_cast
, but at the moment I don't remember the document, from where I got this :( Sorry, for my strange English ... -
In a message above, you mentioned, there is no
std
available. But maybe in your environement some kind ofbit_cast
is available? If not, I think a similar behaviour (to inform the compiler [optimizer]) can be achived withreinterpret_cast
, but at the moment I don't remember the document, from where I got this :( Sorry, for my strange English ...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
-
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