Re: [GSOC] few question about Bypass assembler when generating LTO object files
Hi, On Tue, Apr 04 2023, Rishi Raj wrote: > Thanks, Jan for the Reply! I have completed a draft proposal for this > project. I will appreciate your's, Martin's, or anybody else feedback on > the same. > Here is the link to my proposal > https://docs.google.com/document/d/1r9kzsU96kOYfIhWZx62jx4ALG-J_aJs5U0sDpwFUtts/edit?usp=sharing > in my opinion, the proposal looks rather good. I don't know how to significantly improve it, not in the remaining nine hours before the deadline (just maybe fix the spelling of Honza's surname, it is Hubicka :-). So please go ahead and submit it. (How the selection goes will then depend on how many slots we get from Google). Thanks for putting in the effort, Martin > On Tue, 4 Apr 2023 at 04:35, Jan Hubicka wrote: > >> Hello, >> > While going through the patch and simple-object.c I understood that the >> > file simple-object.c is used to handle the object file format. However, >> > this file does not contain all the architecture information required for >> > LTO object files, so the workaround used in the patch is to read the >> > crtbegin.o file and merge the missing attributes. While this workaround >> is >> > functional, it is not optimal, and the ideal solution would be to extend >> > simple-object.c to include the missing information. >> >> Yes, simple-object.c simply uses architecture settings it read earlier >> which is problem since at compile time we do not read any object files, >> just parse sources). In my original patch the architecture flags were >> simply left blank. I am not sure if there is a version reading >> crtbeing.o which would probably not a be that bad workaround, at least >> for the start. Having a way to specify this from the machine descriptions >> would be better. >> > > >> >> Besides the architecture bits, for simple-object files to work we need >> to add the symbol table. For practically useful information we also need >> to stream the debug info. >> >> >> > Regarding the phrase "Support in the driver to properly execute *1 >> binary", >> > it is not entirely clear what it refers to. My interpretation is that the >> > compiler driver (the program that coordinates the compilation process) >> > needs to be modified to correctly output LTO object files instead of >> > assembler files (the current approach involves passing the -S and -o >> > .o options) and also skip the assembler option while using >> > -fbypass-asm option but I am not sure. Can Jan or Martin please shed some >> > light on this? >> Yes, compiler drivers decides what to do and it needs to know that with >> -flto it does not need to produce assembly file and then invoke gas. If >> we go the way of reading in crtbegin.o it will also need to pass correct >> crtbegin to *1 binary. This is generally not that hard to do, just >> needs to be done :) >> > Honza >> > >> > Thanks & Regards >> > >> > Rishi Raj >> > >> > On Sun, 2 Apr 2023 at 03:05, Rishi Raj wrote: >> > >> > > Hii Everyone, >> > > I had already expressed my interest in the " Bypass assembler when >> > > generating LTO object files" project and making a proposal for the >> same. I >> > > know I should have done it earlier but I was admitted to the hospital >> for >> > > past few days :(. >> > > I have a few doubts. >> > > 1) >> > > >> > > "One problem is that the object files produced by >> libiberty/simple-object.c >> > > (which is the low-level API used by the LTO code) >> > > are missing some information (such as the architecture info and symbol >> > > table) and API of the simple object will need to be extended to handle >> > > that" I found this in the previous mailing list discussion. So who >> output this information currently in the object file, is it assembler? >> > > >> > > Also in the current patch for this project by Jan Hubica, from where >> are we getting these information from? Is it from crtbegin.o? >> > > >> > > 2) >> > > "Support in driver to properly execute *1 binary." I found this on Jan >> original patch's email. what does it mean >> > > >> > > exactly? >> > > >> > > Regards >> > > >> > > Rishi Raj >> > > >> > > >> > > >> > > >>
Re: [GSOC] few question about Bypass assembler when generating LTO object files
Hello, > Thanks, Jan for the Reply! I have completed a draft proposal for this > project. I will appreciate your's, Martin's, or anybody else feedback on > the same. > Here is the link to my proposal > https://docs.google.com/document/d/1r9kzsU96kOYfIhWZx62jx4ALG-J_aJs5U0sDpwFUtts/edit?usp=sharing Here are few comments on the proposal: > The current Implementation of GCC first write the IL representation along > with other section in an assembly file and then the assembler is used to > convert it into LTO object files. Sections containing different IL > representation is created and data is appended in lto-streamer-out.cc.I The .o generated withh -flto file contains the IL (in different sections), debug info, symbol table, etc. "along with other section" sounds odd to me. Perhaps sections. Second sentence seems bit odd too. Perhaps "Streaming of individual sections is implemented in lto-streamer-out.cc which can either be used to produce assembly code containing the section data (dumped hexadecimally) or simple-object API provided by libiberty to produce object files directly" > In the slim object file (Default when using -flto, fat lto can be obtained > using -ffat-lto-object) some section contains the IL and other contains the > info related to architecture, command line options, symbol table, etc. Technically the architecture is part of ELF header and not section itself (I think). There are some other grammar errors, but I am not too good on fixing these, so perhaps Martin can help. The timeline looks reasonable. It certianly makes sense to look into non-ELF object files to understand what API we need, but implementation wise I would suggest implementing ELF path first to get a working implementation. Adding support for other object formats can be done incrementally. Honza > > On Tue, 4 Apr 2023 at 04:35, Jan Hubicka wrote: > > > Hello, > > > While going through the patch and simple-object.c I understood that the > > > file simple-object.c is used to handle the object file format. However, > > > this file does not contain all the architecture information required for > > > LTO object files, so the workaround used in the patch is to read the > > > crtbegin.o file and merge the missing attributes. While this workaround > > is > > > functional, it is not optimal, and the ideal solution would be to extend > > > simple-object.c to include the missing information. > > > > Yes, simple-object.c simply uses architecture settings it read earlier > > which is problem since at compile time we do not read any object files, > > just parse sources). In my original patch the architecture flags were > > simply left blank. I am not sure if there is a version reading > > crtbeing.o which would probably not a be that bad workaround, at least > > for the start. Having a way to specify this from the machine descriptions > > would be better. > > > > > > > > Besides the architecture bits, for simple-object files to work we need > > to add the symbol table. For practically useful information we also need > > to stream the debug info. > > > > > > > Regarding the phrase "Support in the driver to properly execute *1 > > binary", > > > it is not entirely clear what it refers to. My interpretation is that the > > > compiler driver (the program that coordinates the compilation process) > > > needs to be modified to correctly output LTO object files instead of > > > assembler files (the current approach involves passing the -S and -o > > > .o options) and also skip the assembler option while using > > > -fbypass-asm option but I am not sure. Can Jan or Martin please shed some > > > light on this? > > Yes, compiler drivers decides what to do and it needs to know that with > > -flto it does not need to produce assembly file and then invoke gas. If > > we go the way of reading in crtbegin.o it will also need to pass correct > > crtbegin to *1 binary. This is generally not that hard to do, just > > needs to be done :) > > > Honza > > > > > > Thanks & Regards > > > > > > Rishi Raj > > > > > > On Sun, 2 Apr 2023 at 03:05, Rishi Raj wrote: > > > > > > > Hii Everyone, > > > > I had already expressed my interest in the " Bypass assembler when > > > > generating LTO object files" project and making a proposal for the > > same. I > > > > know I should have done it earlier but I was admitted to the hospital > > for > > > > past few days :(. > > > > I have a few doubts. > > > > 1) > > > > > > > > "One problem is that the object files produced by > > libiberty/simple-object.c > > > > (which is the low-level API used by the LTO code) > > > > are missing some information (such as the architecture info and symbol > > > > table) and API of the simple object will need to be extended to handle > > > > that" I found this in the previous mailing list discussion. So who > > output this information currently in the object file, is it assembler? > > > > > > > > Also in the current patch for this project by Jan Hubica, from where > >
ARMv7 doubleword atomicity
*sending this email again, now in plain text Hi Will, I'm working at Huawei on verification of atomic primitives. I thought it would be appropriate to write to you because you're mentioned in several papers on ARM concurrency (https://www.cl.cam.ac.uk/~pes20/papers/topics.html), gcc patches and you're an author of several patches to kernel regarding this. I've recently been looking into our implementation of atomic loads/stores on ARMv7 and found out that we treat stores specially - with LDREXD/STREXD loop - while load is just LDREXD. The latest version of manual (DDI 0406C.d) explicitly prohibits this saying in A3.5.3 that "The way to atomically load two 32-bit quantities is to perform an LDREXD/STREXD sequence, reading and writing the same value, for which the STREXD succeeds, and use the read values." Both GCC and LLVM produce the same code as us (https://godbolt.org/z/bYaWbEbjh). The explanation for this in GCC (https://gcc.gnu.org/pipermail/gcc-patches/2012-April/338841.html) given by Richard Earnshaw is based on older version of ARM ARM (before C.c), which says that LDREXDs are atomic: --- C.b +++ C.c In ARMv7, the single-copy atomic processor accesses are *** - memory accesses caused by LDREXD and STREXD instructions to doubleword-aligned locations. + Memory accesses caused by a LDREXD/STREXD to a doubleword-aligned location for which the STREXD succeeds + cause single-copy atomic updates of the doubleword being accessed. Interestingly, prior to issue C.c LDREXD's pseudocode contained one single-copy atomic memory access (0406C.b A8.8.77): MemA[address,8] , whereas now it contains two (0406C.d A8.8.78): MemA[address,4] and MemA[address+4,4]. Also regarding LPAE, there is a discrepancy between prose and pseudocode explanations of atomicity of LDRD/STRD on LPAE. In prose LDRD/STRD are atomic only in locations that might be used to hold translations, while in pseudocode they are always atomic. LLVM doesn't change its code output for LPAE. GCC produces regular LDRD for load and keeps the LDREXD/STREXD loop for store. In the kernel both loads and stores are regular LDRD/STRD. I've ran some litmus tests on a bunch of boards. Here are the results: - cortex-a7 (BCM2836, RK3128), cortex-a9 (Exynos4412) and cortex-a17 (RK3188) - LDRD/STRD are single-copy atomic; - cortex-a5 (MSM8625Q) - LDRD/STRD are not single-copy atomic, but it's enough to use LDEXRD/STRD to fix it: two writers with STRD and one reader with LDEXRD don't produce inconsistent results. Interestingly, on cortex-a9 (without LPAE) regular LDRD/STRD are atomic. Can you shed some light on the situation with LDREXD/STREXD? Why was the manual changed? Do you think we should change implementation in kernel and elsewhere to what manual suggests? Also about LPAE, manual doesn't pose a requirement that all locations in the memory system are 64-bit single-copy atomic - only those that might be used to hold translations, "such as bulk SDRAM". Does this mean we can safely use LDRD/STRD? Related patches/discussion: http://lists.infradead.org/pipermail/linux-arm-kernel/2009-December/005934.html https://lists.infradead.org/pipermail/linux-arm-kernel/2013-March/157817.html https://gcc.gnu.org/pipermail/gcc-patches/2012-April/338781.html https://gcc.gnu.org/pipermail/gcc-patches/2016-February/442717.html https://reviews.llvm.org/rGc882eb0723afa9dfe626eebb9699c1871a8bbbab --- Peter
Re: [GSOC] few question about Bypass assembler when generating LTO object files
Thanks to Martin, Honza, and Théo for your feedback. I have incorporated almost all of it, updated my proposal accordingly, and submitted it. Regarding grammar errors, I have fixed many, but there may still be some left (I could be better at grammar, to be honest :( ). On Tue, 4 Apr 2023 at 15:55, Jan Hubicka wrote: > Hello, > > Thanks, Jan for the Reply! I have completed a draft proposal for this > > project. I will appreciate your's, Martin's, or anybody else feedback on > > the same. > > Here is the link to my proposal > > > https://docs.google.com/document/d/1r9kzsU96kOYfIhWZx62jx4ALG-J_aJs5U0sDpwFUtts/edit?usp=sharing > > Here are few comments on the proposal: > > > The current Implementation of GCC first write the IL representation > along with other section in an assembly file and then the assembler is used > to convert it into LTO object files. Sections containing different IL > representation is created and data is appended in lto-streamer-out.cc.I > > The .o generated withh -flto file contains the IL (in different > sections), debug info, symbol table, etc. > "along with other section" sounds odd to me. Perhaps sections. > > Second sentence seems bit odd too. Perhaps "Streaming of individual > sections is implemented in lto-streamer-out.cc which can either be used > to produce assembly code containing the section data (dumped > hexadecimally) or simple-object API provided by libiberty to produce > object files directly" > > > In the slim object file (Default when using -flto, fat lto can be > obtained using -ffat-lto-object) some section contains the IL and other > contains the info related to architecture, command line options, symbol > table, etc. > > Technically the architecture is part of ELF header and not section > itself (I think). > > There are some other grammar errors, but I am not too good on fixing > these, so perhaps Martin can help. > > The timeline looks reasonable. It certianly makes sense to look into > non-ELF object files to understand what API we need, but implementation > wise I would suggest implementing ELF path first to get a working > implementation. Adding support for other object formats can be done > incrementally. > > Honza > > > > On Tue, 4 Apr 2023 at 04:35, Jan Hubicka wrote: > > > > > Hello, > > > > While going through the patch and simple-object.c I understood that > the > > > > file simple-object.c is used to handle the object file format. > However, > > > > this file does not contain all the architecture information required > for > > > > LTO object files, so the workaround used in the patch is to read the > > > > crtbegin.o file and merge the missing attributes. While this > workaround > > > is > > > > functional, it is not optimal, and the ideal solution would be to > extend > > > > simple-object.c to include the missing information. > > > > > > Yes, simple-object.c simply uses architecture settings it read earlier > > > which is problem since at compile time we do not read any object files, > > > just parse sources). In my original patch the architecture flags were > > > simply left blank. I am not sure if there is a version reading > > > crtbeing.o which would probably not a be that bad workaround, at least > > > for the start. Having a way to specify this from the machine > descriptions > > > would be better. > > > > > > > > > > > > > Besides the architecture bits, for simple-object files to work we need > > > to add the symbol table. For practically useful information we also > need > > > to stream the debug info. > > > > > > > > > > Regarding the phrase "Support in the driver to properly execute *1 > > > binary", > > > > it is not entirely clear what it refers to. My interpretation is > that the > > > > compiler driver (the program that coordinates the compilation > process) > > > > needs to be modified to correctly output LTO object files instead of > > > > assembler files (the current approach involves passing the -S and -o > > > > .o options) and also skip the assembler option while > using > > > > -fbypass-asm option but I am not sure. Can Jan or Martin please shed > some > > > > light on this? > > > Yes, compiler drivers decides what to do and it needs to know that with > > > -flto it does not need to produce assembly file and then invoke gas. > If > > > we go the way of reading in crtbegin.o it will also need to pass > correct > > > crtbegin to *1 binary. This is generally not that hard to do, just > > > needs to be done :) > > > > > Honza > > > > > > > > Thanks & Regards > > > > > > > > Rishi Raj > > > > > > > > On Sun, 2 Apr 2023 at 03:05, Rishi Raj > wrote: > > > > > > > > > Hii Everyone, > > > > > I had already expressed my interest in the " Bypass assembler when > > > > > generating LTO object files" project and making a proposal for the > > > same. I > > > > > know I should have done it earlier but I was admitted to the > hospital > > > for > > > > > past few days :(. > > > > > I have a few doubts. > > > > > 1) > > > > > > > > > > "O
Linker removal of trampolines on Microsoft Windows targets
Hi all, Microsoft's Visual C++ compiler has the ability to remove trampolines generated by the linker (which ultimately calls __imp_SymbolName from the DLL import address table) when linking with code that is intended to be loaded from a DLL if link time optimization on their compiler was specified, even if the symbol in question was not marked as msvc::dllimport (which would normally be required for some an optimization). Is there a way we can add this to gcc or ld as well, to enable it to call from the import address table directly without having to go through the indirection? Or at least where to look at in the linker's code, I'd be willing to help add such an enhancement myself best regards, Julian
Re: [GSOC] few question about Bypass assembler when generating LTO object files
> Thanks to Martin, Honza, and Théo for your feedback. I have incorporated > almost all of it, updated my proposal accordingly, and submitted it. > Regarding grammar errors, I have fixed many, but there may still be some > left (I could be better at grammar, to be honest :( ). I could be better too, I think grammar is not critical here. Thanks a lot for making and submitting the proposal. Honza > > On Tue, 4 Apr 2023 at 15:55, Jan Hubicka wrote: > > > Hello, > > > Thanks, Jan for the Reply! I have completed a draft proposal for this > > > project. I will appreciate your's, Martin's, or anybody else feedback on > > > the same. > > > Here is the link to my proposal > > > > > https://docs.google.com/document/d/1r9kzsU96kOYfIhWZx62jx4ALG-J_aJs5U0sDpwFUtts/edit?usp=sharing > > > > Here are few comments on the proposal: > > > > > The current Implementation of GCC first write the IL representation > > along with other section in an assembly file and then the assembler is used > > to convert it into LTO object files. Sections containing different IL > > representation is created and data is appended in lto-streamer-out.cc.I > > > > The .o generated withh -flto file contains the IL (in different > > sections), debug info, symbol table, etc. > > "along with other section" sounds odd to me. Perhaps sections. > > > > Second sentence seems bit odd too. Perhaps "Streaming of individual > > sections is implemented in lto-streamer-out.cc which can either be used > > to produce assembly code containing the section data (dumped > > hexadecimally) or simple-object API provided by libiberty to produce > > object files directly" > > > > > In the slim object file (Default when using -flto, fat lto can be > > obtained using -ffat-lto-object) some section contains the IL and other > > contains the info related to architecture, command line options, symbol > > table, etc. > > > > Technically the architecture is part of ELF header and not section > > itself (I think). > > > > There are some other grammar errors, but I am not too good on fixing > > these, so perhaps Martin can help. > > > > The timeline looks reasonable. It certianly makes sense to look into > > non-ELF object files to understand what API we need, but implementation > > wise I would suggest implementing ELF path first to get a working > > implementation. Adding support for other object formats can be done > > incrementally. > > > > Honza > > > > > > On Tue, 4 Apr 2023 at 04:35, Jan Hubicka wrote: > > > > > > > Hello, > > > > > While going through the patch and simple-object.c I understood that > > the > > > > > file simple-object.c is used to handle the object file format. > > However, > > > > > this file does not contain all the architecture information required > > for > > > > > LTO object files, so the workaround used in the patch is to read the > > > > > crtbegin.o file and merge the missing attributes. While this > > workaround > > > > is > > > > > functional, it is not optimal, and the ideal solution would be to > > extend > > > > > simple-object.c to include the missing information. > > > > > > > > Yes, simple-object.c simply uses architecture settings it read earlier > > > > which is problem since at compile time we do not read any object files, > > > > just parse sources). In my original patch the architecture flags were > > > > simply left blank. I am not sure if there is a version reading > > > > crtbeing.o which would probably not a be that bad workaround, at least > > > > for the start. Having a way to specify this from the machine > > descriptions > > > > would be better. > > > > > > > > > > > > > > > > > > Besides the architecture bits, for simple-object files to work we need > > > > to add the symbol table. For practically useful information we also > > need > > > > to stream the debug info. > > > > > > > > > > > > > Regarding the phrase "Support in the driver to properly execute *1 > > > > binary", > > > > > it is not entirely clear what it refers to. My interpretation is > > that the > > > > > compiler driver (the program that coordinates the compilation > > process) > > > > > needs to be modified to correctly output LTO object files instead of > > > > > assembler files (the current approach involves passing the -S and -o > > > > > .o options) and also skip the assembler option while > > using > > > > > -fbypass-asm option but I am not sure. Can Jan or Martin please shed > > some > > > > > light on this? > > > > Yes, compiler drivers decides what to do and it needs to know that with > > > > -flto it does not need to produce assembly file and then invoke gas. > > If > > > > we go the way of reading in crtbegin.o it will also need to pass > > correct > > > > crtbegin to *1 binary. This is generally not that hard to do, just > > > > needs to be done :) > > > > > > > Honza > > > > > > > > > > Thanks & Regards > > > > > > > > > > Rishi Raj > > > > > > > > > > On Sun, 2 Apr 2023 at 03:05, Rishi Raj > > wrote: > > > > > > > > > > > Hii Everyone
Re: Re: GSoC: want to take part in `Extend the static analysis pass for CPython Extension`
Thanks Martin! Sounds good; I submitted my proposal unchanged for now (i.e assuming an independent project), but as Dave mentioned in another thread, it may be divided into several logical components, perhaps with certain features extended, to be suited for collaboration. Best, Eric On Mon, Apr 3, 2023 at 11:29 AM Martin Jambor wrote: > > Hello, > > On Mon, Apr 03 2023, Eric Feng via Gcc wrote: > > Hi Steven, > > > > I’m happy to collaborate on this project together — it would be great > > to have your experience with CPython internals on the team. > > > > While I normally welcome collaboration, please note that GSoC rules and > reasonable caution dictate that the two project must not be dependent on > one another. I.e. if one of you, for any reason, could not finish your > bits in time, it must not have severe adverse effects on the other. > > If mostly independent collaboration is possible (and David agrees), > then sure, go ahead. > > Thanks for understanding, > > Martin
Re: [PATCH] sockaddr.3type: Document that sockaddr_storage is the API to be used
Hi Eric, I'm going to reply both your emails here so that GCC is CCed, and they can suggest better stuff. I'm worried about sending something to POSIX without enough eyes checking it. So this will be a long email. On 3/30/23 20:36, eblake wrote: > On Thu, Mar 30, 2023 at 06:25:30PM +0200, Alejandro Colomar wrote: >> Hi Eric! >> >> On 3/30/23 17:22, Austin Group Bug Tracker via austin-group-l at The Open >> Group wrote: >>> >>> The following issue has been RESOLVED. >>> == >>> https://austingroupbugs.net/view.php?id=1641 > ... >> >> Thanks for taking care of this bug! > > My pleasure. :-) > >> >> >> On 3/30/23 17:20, Austin Group Bug Tracker via austin-group-l at The Open >> Group wrote: >>> On page 386 line 13115 section DESCRIPTION, change: >>> >>> When a pointer to a sockaddr_storage structure is cast as a pointer to >>> a sockaddr structure, the ss_family field of the sockaddr_storage structure >>> shall map onto the sa_family field of the sockaddr structure. When a >>> pointer to a sockaddr_storage structure is cast as a pointer to a >>> protocol-specific address structure, the ss_family field shall map onto a >>> field of that structure that is of type sa_family_t and that identifies the >>> protocol’s address family. >>> >>> to: >>> >>> When a pointer to a sockaddr_storage structure is cast as a pointer to >>> a sockaddr structure, or vice versa, the ss_family field of the >>> sockaddr_storage structure shall map onto the sa_family field of the >>> sockaddr structure. When a pointer to a sockaddr_storage structure is cast >>> as a pointer to a protocol-specific address structure, or vice versa, the >>> ss_family field shall map onto a field of that structure that is of type >>> sa_family_t and that identifies the protocol’s address family. When a >>> pointer to a sockaddr structure is cast as a pointer to a protocol-specific >>> address structure, or vice versa, the sa_family field shall map onto a >>> field of that structure that is of type sa_family_t and that identifies the >>> protocol’s address family. Additionally, the structures shall be defined in >>> such a way that these casts do not cause the compiler to produce >>> diagnostics about aliasing issues when compiling conforming application >>> (xref to XBD section 2.2) source files. >> >> I will add a CAVEATS section in sockaddr(3type) covering this, and will >> CC you just to check. > > Sure, I'll be happy to review. > > The intent from the meeting (and perhaps requires a bit of reading > between the lines compared to what was captured as the approved text) > was that implementations MUST ensure that existing code does not get > miscompiled under the guise of undefined behavior, but without stating > how to do it other than suggesting that implementation-specific > extensions may be needed (somewhat similar as how POSIX requires that > when dlsym() returns a void* for a function entry point, converting > that pointer to a function pointer that can then be called MUST be > compiled to work as intended, even though C doesn't define it). We > want the burden to be on the libc and system header providers to > guarantee defined behavior, and not on the average coder to make > careful use of memcpy() between storage of different effective types > to avoid what might be otherwise undefined if it were written using > types declared using only C99 syntax. > > Whether gcc already has all the attributes you need is not my area of > expertise. In my skim of the glibc list conversation, I saw mention > of attribute [[gnu:transparent_union]] rather than [[__may_alias__]] - > if that's a better implementation-defined extension that does what we > need, then use it. The standard developers were a bit uncomfortable > directly putting [[gnu:transparent_union]] in the standard, but > [[__may_alias__]] was noncontroversial (it's in the namespace reserved > for the implementation) Not really; implementation-defined attributes are required to use an implementation-defined prefix like 'gnu::'. So [[__may_alias__]] is reserved by ISO C, AFAIR. Maybe it would be better to just mention attributes without any specific attribute name; being fuzzy about it would help avoid making promises that we can't hold. > and deemed to be a sufficient hint for > developers to figure out that they can use whatever works best to meet > the actual requirement of not letting the compiler optimize away > socket operations under the premise of undefined behavior. > >>> >>> On page 390 line 13260 section APPLICATION USAGE, append a >>> sentence: >>> >>> Note that this example only deals with size and alignment; see >>> RATIONALE for additional issues related to these structures. >>> >>> >>> >>> On page 390 line 13291 section , change RATIONALE from "None" >>> to: >>> >>> Note that defining the sockaddr_storage and sockaddr structures using >>> only mechanism
