[[!meta copyright="Copyright © 2012, 2013, 2015 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] [[!tag open_issue_glibc open_issue_gnumach open_issue_hurd open_issue_mig]] # IRC, freenode, #hurd, 2012-07-04 we should perhaps build the hurd with -fno-strict-aliasing, considering the number of warnings i can see during the build :/ braunr: wouldn't be better to "just" fix the mig-generated stubs instead? pinotree: if we can rely on gcc for the warnings, yes but i suspect there might be other silent issues in very old code # IRC, freenode, #hurd, 2012-07-12 btw, i'm building glibc right now, and i can see a few strict aliasing warnings fixing them will allow us to avoid wasting time on very obscure issues (if gcc catches them all) The strict aliasing things should be fixed, yes. Some might be from MIG. # IRC, freenode, #hurd, 2013-10-17 we should build gnumach and the hurd with -fno-strict-aliasing aren't the mig-generated stubs the only issues related to that? no b/c we often have pointers of different type pointing to the same address? for example code using libports? the old linux code, including pfinet, and even the hurd libraries, use techniques that assume aliasing exactly right, I agree # 2015-10-30 Noticed that there are no `warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]` diagnostics when compiling a [[GDB|binutils]] build's MIG-generated stub files.