Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. Other Discussions
  3. The Weird and The Wonderful
  4. What the hell gcc?

What the hell gcc?

Scheduled Pinned Locked Moved The Weird and The Wonderful
designcomgraphicsiot
24 Posts 6 Posters 54 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • H 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

    K Offline
    K Offline
    k5054
    wrote on last edited by
    #11

    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

    H 1 Reply Last reply
    0
    • K 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

      H Offline
      H Offline
      honey the codewitch
      wrote on last edited by
      #12

      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

      K 1 Reply Last reply
      0
      • H 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

        K Offline
        K Offline
        k5054
        wrote on last edited by
        #13

        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

        H 1 Reply Last reply
        0
        • K 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

          H Offline
          H Offline
          honey the codewitch
          wrote on last edited by
          #14

          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

          K 1 Reply Last reply
          0
          • H 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

            K Offline
            K Offline
            k5054
            wrote on last edited by
            #15

            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

            H 1 Reply Last reply
            0
            • K 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

              H Offline
              H Offline
              honey the codewitch
              wrote on last edited by
              #16

              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

              K R 0 3 Replies Last reply
              0
              • H 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

                K Offline
                K Offline
                k5054
                wrote on last edited by
                #17

                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

                H 1 Reply Last reply
                0
                • H 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

                  R Offline
                  R Offline
                  Rick York
                  wrote on last edited by
                  #18

                  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?"

                  1 Reply Last reply
                  0
                  • K 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

                    H Offline
                    H Offline
                    honey the codewitch
                    wrote on last edited by
                    #19

                    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

                    1 Reply Last reply
                    0
                    • H 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

                      0 Offline
                      0 Offline
                      0x01AA
                      wrote on last edited by
                      #20

                      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.

                      H 1 Reply Last reply
                      0
                      • 0 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.

                        H Offline
                        H Offline
                        honey the codewitch
                        wrote on last edited by
                        #21

                        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

                        0 1 Reply Last reply
                        0
                        • H 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

                          0 Offline
                          0 Offline
                          0x01AA
                          wrote on last edited by
                          #22

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

                          H 1 Reply Last reply
                          0
                          • 0 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 ...

                            H Offline
                            H Offline
                            honey the codewitch
                            wrote on last edited by
                            #23

                            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

                            0 1 Reply Last reply
                            0
                            • H 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

                              0 Offline
                              0 Offline
                              0x01AA
                              wrote on last edited by
                              #24

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

                              1 Reply Last reply
                              0
                              Reply
                              • Reply as topic
                              Log in to reply
                              • Oldest to Newest
                              • Newest to Oldest
                              • Most Votes


                              • Login

                              • Don't have an account? Register

                              • Login or register to search.
                              • First post
                                Last post
                              0
                              • Categories
                              • Recent
                              • Tags
                              • Popular
                              • World
                              • Users
                              • Groups