GCC 11.3.1 Status Report (2022-04-21)
Status == The gcc-11 branch is again open for regression and documentation fixes. Quality Data Priority # Change from last report --- --- P1 0 P2 428 + 6 P3 55 P4 232 + 1 P5 26+ 1 --- --- Total P1-P3 483 + 6 Total 743 + 8 Previous Report === https://gcc.gnu.org/pipermail/gcc/2022-April/238547.html
GCC 11.3 Released
The GNU Compiler Collection version 11.3 has been released. GCC 11.3 is a bug-fix release from the GCC 11 branch containing important fixes for regressions and serious bugs in GCC 11.2 with more than 189 bugs fixed since the previous release. This release is available from the WWW and FTP servers listed here: https://sourceware.org/pub/gcc/releases/gcc-11.3.0/ https://gcc.gnu.org/mirrors.html Please do not contact me directly regarding questions or comments about this release. Instead, use the resources available from http://gcc.gnu.org. As always, a vast number of people contributed to this GCC release -- far too many to thank them individually!
unsubscribe
Unsubscribe El jue., 21 abr. 2022 06:26, Richard Biener via gcc-announce < gcc-annou...@gcc.gnu.org> escribió: > > The GNU Compiler Collection version 11.3 has been released. > > GCC 11.3 is a bug-fix release from the GCC 11 branch containing important > fixes for regressions and serious bugs in GCC 11.2 with more than 189 bugs > fixed since the previous release. > > This release is available from the WWW and FTP servers listed here: > > https://sourceware.org/pub/gcc/releases/gcc-11.3.0/ > https://gcc.gnu.org/mirrors.html > > Please do not contact me directly regarding questions or comments > about this release. Instead, use the resources available from > http://gcc.gnu.org. > > As always, a vast number of people contributed to this GCC release > -- far too many to thank them individually! >
Re: [modules] Preprocessing requires compiled header unit modules
On Thu, Apr 21, 2022 at 06:05:52 +0200, Boris Kolpackov wrote: > I don't think it is. A header unit (unlike a named module) may export > macros which could affect further dependencies. Consider: > > import "header-unit.hpp"; // May or may not export macro FOO. > > #ifdef FOO > import "header-unit2.hpp" > #endif I agree that the header needs to be *found*, but scanning cannot require a pre-existing BMI for that header. A new mode likely needs to be laid down to get the information necessary (instead of just piggy-backing on `-E` behavior to get what I want). --Ben
Re: unsubscribe
On Thu, 21 Apr 2022 at 12:35, David Valtorta via Gcc wrote: > > Unsubscribe See https://gcc.gnu.org/lists.html#subscribe > > El jue., 21 abr. 2022 06:26, Richard Biener via gcc-announce < > gcc-annou...@gcc.gnu.org> escribió: > > > > > The GNU Compiler Collection version 11.3 has been released. > > > > GCC 11.3 is a bug-fix release from the GCC 11 branch containing important > > fixes for regressions and serious bugs in GCC 11.2 with more than 189 bugs > > fixed since the previous release. > > > > This release is available from the WWW and FTP servers listed here: > > > > https://sourceware.org/pub/gcc/releases/gcc-11.3.0/ > > https://gcc.gnu.org/mirrors.html > > > > Please do not contact me directly regarding questions or comments > > about this release. Instead, use the resources available from > > http://gcc.gnu.org. > > > > As always, a vast number of people contributed to this GCC release > > -- far too many to thank them individually! > >
Re: [modules] Preprocessing requires compiled header unit modules
Hi Ben, > On 21 Apr 2022, at 13:05, Ben Boeckel via Gcc wrote: > > On Thu, Apr 21, 2022 at 06:05:52 +0200, Boris Kolpackov wrote: >> I don't think it is. A header unit (unlike a named module) may export >> macros which could affect further dependencies. Consider: >> >> import "header-unit.hpp"; // May or may not export macro FOO. 1. If you know how this was built, then you could do an -E -fdirectives-only build (both GCC and clang support this now) to obtain the macros. 2. I suppose we could invent a tool (or FE mode) to dump the macros exported by a HU *** >> #ifdef FOO >> import "header-unit2.hpp" >> #endif > > I agree that the header needs to be *found*, but scanning cannot require > a pre-existing BMI for that header. A new mode likely needs to be laid > down to get the information necessary (instead of just piggy-backing on > `-E` behavior to get what I want). perhaps that means (2)? Iain *** it’s kinda frustrating that this is hard infomation to get as a developer, so perhaps we can anticipate users wanting such output.
Re: [modules] Preprocessing requires compiled header unit modules
On Thu, Apr 21, 2022 at 18:59:56 +0100, Iain Sandoe wrote: > Hi Ben, > > > On 21 Apr 2022, at 13:05, Ben Boeckel via Gcc wrote: > > > > On Thu, Apr 21, 2022 at 06:05:52 +0200, Boris Kolpackov wrote: > >> I don't think it is. A header unit (unlike a named module) may export > >> macros which could affect further dependencies. Consider: > >> > >> import "header-unit.hpp"; // May or may not export macro FOO. > > 1. If you know how this was built, then you could do an -E -fdirectives-only > build (both >GCC and clang support this now) to obtain the macros. My understanding is that how it gets used determines how it should be made for Clang (because the consumer's `-D`, `-W`, etc. flags matter). I do not yet know how I am to support this in CMake. > 2. I suppose we could invent a tool (or FE mode) to dump the macros exported > by a HU *** Fun considerations: - are `-D` flags exported? `-U`? - how about this if `value` is the same as or different from the at-start expansion: ```c++ #undef SOME_MACRO #define SOME_MACRO value ``` - how about `#undef FOO`? > >> #ifdef FOO > >> import "header-unit2.hpp" > >> #endif > > > > I agree that the header needs to be *found*, but scanning cannot require > > a pre-existing BMI for that header. A new mode likely needs to be laid > > down to get the information necessary (instead of just piggy-backing on > > `-E` behavior to get what I want). > > perhaps that means (2)? Can't it just read the header as if it wasn't imported? AFAIU, that's what GCC did in Jan 2019. I understand that CPP state is probably not easy, but something to consider. > *** it’s kinda frustrating that this is hard infomation to get as a > developer, so > perhaps we can anticipate users wanting such output. I think cacheing and distributed build tools are the most likely consumers of such information. --Ben
Re: [modules] Preprocessing requires compiled header unit modules
> On 21 Apr 2022, at 19:08, Ben Boeckel wrote: > > On Thu, Apr 21, 2022 at 18:59:56 +0100, Iain Sandoe wrote: >> Hi Ben, >> >>> On 21 Apr 2022, at 13:05, Ben Boeckel via Gcc wrote: >>> >>> On Thu, Apr 21, 2022 at 06:05:52 +0200, Boris Kolpackov wrote: I don't think it is. A header unit (unlike a named module) may export macros which could affect further dependencies. Consider: import "header-unit.hpp"; // May or may not export macro FOO. >> >> 1. If you know how this was built, then you could do an -E >> -fdirectives-only build (both >> GCC and clang support this now) to obtain the macros. > > My understanding is that how it gets used determines how it should be > made for Clang (because the consumer's `-D`, `-W`, etc. flags matter). I > do not yet know how I am to support this in CMake. I think that is what I mean by “if you know how it is built” - it means you can replicate those conditions, but produce the fdirectives-only output. Perhaps I’m missing a subtelty … >> 2. I suppose we could invent a tool (or FE mode) to dump the macros >> exported by a HU *** > > Fun considerations: > > - are `-D` flags exported? `-U`? > - how about this if `value` is the same as or different from the >at-start expansion: > > ```c++ > #undef SOME_MACRO > #define SOME_MACRO value > ``` > > - how about `#undef FOO`? AFAIU, that is defined by the standard - only the defined state of a macro is exported. So if the file contains #define FOO 1 …. …. #undef FOO — there will be no mention of FOO in the exported macros (at least, that is what my impl. does ;) ). — and the output would contain 'SOME_MACRO value’ for your other case. This is quite different from the behaviour of PCH where the macro history is preserved. #ifdef FOO import "header-unit2.hpp" #endif >>> >>> I agree that the header needs to be *found*, but scanning cannot require >>> a pre-existing BMI for that header. A new mode likely needs to be laid >>> down to get the information necessary (instead of just piggy-backing on >>> `-E` behavior to get what I want). >> >> perhaps that means (2)? > > Can't it just read the header as if it wasn't imported? AFAIU, that's > what GCC did in Jan 2019. I understand that CPP state is probably not > easy, but something to consider. The BMIs (at least the two I’ve got some familiarity with) are quite complex - there would have to be some mode that specifically extracted the macros only. >> *** it’s kinda frustrating that this is hard infomation to get as a >> developer, so >>perhaps we can anticipate users wanting such output. > > I think cacheing and distributed build tools are the most likely > consumers of such information. On an “industrial scale”, sure - but the ability for a user to check that what they think is present _is_ present, is valuable - at least in debug. Iain
unsubscribe
-Original Message-
From: gcc-announce On Behalf
Of Richard Biener via gcc-announce
Sent: Thursday, April 21, 2022 5:13 AM
To: gcc-annou...@gcc.gnu.org; gcc@gcc.gnu.org; info-...@gnu.org
Cc: Richard Biener
Subject: [EXT] GCC 11.3 Released
[Actual Sender is gcc-announce-bounces+pdubuc=cas@gcc.gnu.org]
The GNU Compiler Collection version 11.3 has been released.
GCC 11.3 is a bug-fix release from the GCC 11 branch containing important fixes
for regressions and serious bugs in GCC 11.2 with more than 189 bugs fixed
since the previous release.
This release is available from the WWW and FTP servers listed here:
https://sourceware.org/pub/gcc/releases/gcc-11.3.0/
https://gcc.gnu.org/mirrors.html
Please do not contact me directly regarding questions or comments about this
release. Instead, use the resources available from http://gcc.gnu.org.
As always, a vast number of people contributed to this GCC release
-- far too many to thank them individually!
Confidentiality Notice: This electronic message transmission, including any
attachment(s), may contain confidential, proprietary, or privileged information
from CAS, a division of the American Chemical Society ("ACS"). If you have
received this transmission in error, be advised that any disclosure, copying,
distribution, or use of the contents of this information is strictly
prohibited. Please destroy all copies of the message and contact the sender
immediately by either replying to this message or calling 614-447-3600.
gcc-9-20220421 is now available
Snapshot gcc-9-20220421 is now available on https://gcc.gnu.org/pub/gcc/snapshots/9-20220421/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 9 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-9 revision 30e6e43f0bbd84ac01cfcbfbd4b60f4495365b7d You'll find: gcc-9-20220421.tar.xzComplete GCC SHA256=653da91f1c3a49fd47245c8004c2b0be9e003a0a56db13e98ac4f8beeb8e3635 SHA1=399a43207ddb2be3ea296c9e8ca276b615895cbd Diffs from 9-20220414 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-9 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.
Why does GCC(libgcc) pack libgcc_eh.a into libgcc.a in baremetal ?
Hi, Are there some history or reason for this design ? I think it’s clear & simple to keep coherent logic, namely that there should be libgcc_eh.a for exceptions :) Add Makefile.in segment of libgcc as following: # Build LIB2ADDEH, LIB2ADDEHSTATIC, and LIB2ADDEHSHARED. If we don't have # libgcc_eh.a, only LIB2ADDEH matters. If we do, only LIB2ADDEHSTATIC and # LIB2ADDEHSHARED matter. (Usually all three are identical.) c_flags := -fexceptions ifeq ($(enable_shared),yes) libgcc-eh-objects += $(addsuffix $(objext),$(basename $(notdir $(LIB2ADDEHSTATIC libgcc-s-objects += $(addsuffix _s$(objext),$(basename $(notdir $(LIB2ADDEHSHARED iter-items := $(sort $(LIB2ADDEHSTATIC) $(LIB2ADDEHSHARED)) include $(iterator) else # Not shared. LIB2ADDEH are added to libgcc.a. libgcc-objects += $(addsuffix $(objext),$(basename $(notdir $(LIB2ADDEH iter-items := $(LIB2ADDEH) include $(iterator) endif — Jojo
