Re: Warning specifically for a returning noreturn
On Fri, 21 Jul 2023 at 04:28, Julian Waters via Gcc wrote: > > Hi all, > > I've found the places responsible for the warnings, but before I do > anything I'd like to discuss a couple of things. > > 1. What would a good name for the warning switch be? How does > -Wreturning-noreturn sound? > 2. I've thought about this for a while, and I feel like throwing a warning > for a noreturn method that isn't explicitly noreturn in the Control Flow > Graph is a little too harsh. The point of the attribute is to hint to gcc > that the method will never return even if it appears so, Is it? My understanding is that it's for functions the compiler can't see the body of, e.g. user-defined functions similar to abort(). A function that doesn't return "even if it appears so" implies the function body is visible to the compiler. I don't think that's the primary use case. The compiler is already perfectly capable of optimizing callers appropriately if the function clearly never returns, you don't need the attribute for those cases. > and requiring that > the body explicitly do something like call abort() or loop infinitely kind > of defeats the purpose of the attribute, in my opinion I disagree, because the attribute is for the benefit of the calling code, not the function body itself. And so it still serves that purpose whatever the body of the function looks like. If you've added the attribute, so that calling code can be optimized accordingly, but then the body actually does return ... what are you playing it? That's weird and certainly deserves a warning. The calling code might not work correctly if the function does return, because it's been optimized assumed that can never happen, so you cause the program to have undefined behaviour by returning from a noreturn function. That certainly deserves a warning. The attribute's primary purpose is to inform callers the function won't return. A side effect of that is that the function itself might generate warnings if it appears to violate the contract you've made (that it won't return). To avoid those warnings, you need to write the function body so that it doesn't return. So instead of allowing the function to return, call another noreturn function (like abort), or add a __builtin_unreachable (or call std::unreachable in C++23), or throw an exception. > 3. If (2) is just me missing something, should I split the warning into 2 > different warnings for a noreturn definition with an explicit return > statement and an implicit one in the case of a method not explicitly > throwing/looping infinitely, etc? I'm not sure it's worth it, as they're closely related. Although I suppose you could have a noreturn function that must have a non-void return type in order to conform to some expected API (e.g. a virtual function, or a function who's address is taken and used as a callback), so want to disable the warning about a non-void return, but still get warnings for the function body to help you ensure it really doesn't return by mistake.
Re: [PATCH v5 4/5] c++modules: report imported CMI files as dependencies
On Thu, Jul 20, 2023 at 17:00:32 -0400, Nathan Sidwell wrote: > On 7/19/23 20:47, Ben Boeckel wrote: > > But it is inhibiting distributed builds because the distributing tool > > would need to know: > > > > - what CMIs are actually imported (here, "read the module mapper file" > >(in CMake's case, this is only the modules that are needed; a single > >massive mapper file for an entire project would have extra entries) or > >"act as a proxy for the socket/program specified" for other > >approaches); > > This information is in the machine (& human) README section of the CMI. Ok. That leaves it up to distributing build tools to figure out at least. > > - read the CMIs as it sends to the remote side to gather any other CMIs > >that may be needed (recursively); > > > > Contrast this with the MSVC and Clang (17+) mechanism where the command > > line contains everything that is needed and a single bolus can be sent. > > um, the build system needs to create that command line? Where does the build > system get that information? IIUC it'll need to read some file(s) to do that. It's chained through the P1689 information in the collator as needed. No extra files need to be read (at least with CMake's approach); certainly not CMI files. > > And relocatable is probably fine. How does it interact with reproducible > > builds? Or are GCC CMIs not really something anyone should consider for > > installation (even as a "here, maybe this can help consumers" > > mechanism)? > > Module CMIs should be considered a cacheable artifact. They are neither > object > files nor source files. Sure, cachable sounds fine. What about the installation? --Ben
Appointing a new reviewer for the BPF backend
Hello. I would like to recommend the GCC Steering Committee to appoint David Faust as a REVIEWER for the BPF backend. He has a lot of experience hacking the backend, and I trust his judgement to approve other's patches in the area. Thanks!
Re: [PATCH v5 4/5] c++modules: report imported CMI files as dependencies
On 7/21/23 10:57, Ben Boeckel wrote: On Thu, Jul 20, 2023 at 17:00:32 -0400, Nathan Sidwell wrote: On 7/19/23 20:47, Ben Boeckel wrote: But it is inhibiting distributed builds because the distributing tool would need to know: - what CMIs are actually imported (here, "read the module mapper file" (in CMake's case, this is only the modules that are needed; a single massive mapper file for an entire project would have extra entries) or "act as a proxy for the socket/program specified" for other approaches); This information is in the machine (& human) README section of the CMI. Ok. That leaves it up to distributing build tools to figure out at least. - read the CMIs as it sends to the remote side to gather any other CMIs that may be needed (recursively); Contrast this with the MSVC and Clang (17+) mechanism where the command line contains everything that is needed and a single bolus can be sent. um, the build system needs to create that command line? Where does the build system get that information? IIUC it'll need to read some file(s) to do that. It's chained through the P1689 information in the collator as needed. No extra files need to be read (at least with CMake's approach); certainly not CMI files. It occurs to me that the model I am envisioning is similar to CMake's object libraries. Object libraries are a convenient name for a bunch of object files. IIUC they're linked by naming the individual object files (or I think the could be implemented as a static lib linked with --whole-archive path/to/libfoo.a -no-whole-archive. But for this conversation consider them a bunch of separate object files with a convenient group name. Consider also that object libraries could themselves contain object libraries (I don't know of they can, but it seems like a useful concept). Then one could create an object library from a collection of object files and object libraries (recursively). CMake would handle the transitive gtaph. Now, allow an object library to itself have some kind of tangible, on-disk representation. *BUT* not like a static library -- it doesn't include the object files. Now that immediately maps onto modules. CMI: Object library Direct imports: Direct object libraries of an object library This is why I don't understand the need explicitly indicate the indirect imports of a CMI. CMake knows them, because it knows the graph. And relocatable is probably fine. How does it interact with reproducible builds? Or are GCC CMIs not really something anyone should consider for installation (even as a "here, maybe this can help consumers" mechanism)? Module CMIs should be considered a cacheable artifact. They are neither object files nor source files. Sure, cachable sounds fine. What about the installation? --Ben -- Nathan Sidwell
Please stop blocking xstyle/stylish
Your site is far too bright and is absolutely painful to the eyes, I have a simple invert style that I expected to work on all sites and I found your site is undertaking the vile act of blocking user styles. I expect that sort of rotten design from microsoft & apple (which ironically don't), not from a site that is supposed to be on the user freedom of choice side of the spectrum.
gcc-12-20230721 is now available
Snapshot gcc-12-20230721 is now available on https://gcc.gnu.org/pub/gcc/snapshots/12-20230721/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 12 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-12 revision f7ecd7ee5120b3b43f2facf7a862882f286f1e54 You'll find: gcc-12-20230721.tar.xz Complete GCC SHA256=34144b973c2fddf7747731982634f4c2ffbb491da82e692c5eace2ef8a6451e1 SHA1=ea30dd01245599c021f3e0e0a0bc98d927382a47 Diffs from 12-20230714 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-12 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
