GCC 12.1 Released
The GCC developers are proud to announce another major GCC release, 12.1. This year we celebrated the 35th anniversary of the first GCC beta release and this month we will celebrate 35 years since the GCC 1.0 release! This release deprecates support for the STABS debugging format and introduces support for the CTF debugging format [1]. The C and C++ frontends continue to advance with extending support for features in the upcoming C2X and C++23 standards and the C++ standard library improves support for the experimental C++20 and C++23 parts. The Fortran frontend now fully supports TS 29113 for interoperability with C. GCC now understands clangs __builtin_shufflevector extension making it easier to share generic vector code. Starting with GCC 12 vectorization is enabled at the -O2 optimization level using the very-cheap cost model which puts extra constraints on code size expansion. On the security side GCC can now initialize stack variables implicitly using -ftrivial-auto-var-init to help tracking down and mitigating uninitialized stack variable flaws. The C and C++ frontends now support __builtin_dynamic_object_size compatible with the clang extension. The x86 backend gained mitigations against straight line speculation with -mharden-sls. The experimental Static Analyzer gained uninitialized variable use detection and many other improvements. The x86 backend gained support for AVX512-FP16 via _Float16. The BPF backend now supports CO-RE, the RISC-V backend gained support for many new ISA extensions. Some code that compiled successfully with older GCC versions might require source changes, see http://gcc.gnu.org/gcc-12/porting_to.html for details. See https://gcc.gnu.org/gcc-12/changes.html for more information about changes in GCC 12.1. This release is available from the WWW and FTP servers listed here: https://sourceware.org/pub/gcc/releases/gcc-12.1.0/ https://gcc.gnu.org/mirrors.html The release is in the gcc-12.1.0/ subdirectory. If you encounter difficulties using GCC 12.1, please do not contact me directly. Instead, please visit http://gcc.gnu.org for information about getting help. Driving a leading free software project such as GCC would not be possible without support from its many contributors. Not only its developers, but especially its regular testers and users which contribute to its high quality. The list of individuals is too large to thank individually! [1] See https://ctfstd.org/
GCC 12.1.1 Status Report (2022-05-06)
Status == GCC 12.1 has been released, the releases/gcc-12 branch is open again for regression and documentation bugfixing. GCC 12.2 can be expected in 2-3 months from now unless something serious changes the plans. Quality Data Priority # Change from last report --- --- P1 0 P2 367 + 3 P3 85+ 9 P4 248 - 5 P5 26 --- --- Total P1-P3 452 + 12 Total 726 + 7 Previous Report === https://gcc.gnu.org/pipermail/gcc/2022-April/238617.html
GCC 9.4.1 Status Report (2022-05-06)
Status == The GCC 9 branch is in regression and documentation fixing mode. After the release of GCC 12.1 it's time to retire this branch and do a last release from it - GCC 9.5. I will do a GCC 9.5 release candidate in two weeks from now, May 20th, following by the release a week after that if no serious problems arise. Following the GCC 9.5 release and branch closing will be the release of GCC 10.4 with a timeline still to be announced. So this is now the time to consider backporting fixes that landed in GCC 11.3 to the GCC 10 branch and possibly also the GCC 9 branch. Please consider that there will be no further release from the GCC 9 branch and thus be extra careful to not introduce new regressions on it. It's also a very good point in time to ensure the branch still builds and has reasonable testresults for the target you maintain. Quality Data Priority # Change from last report --- --- P1 P2 427 + 123 P3 42+ 16 P4 188 + 15 P5 25+ 2 --- --- Total P1-P3 469 + 138 Total 682 + 155 Previous Report === https://gcc.gnu.org/pipermail/gcc/2021-June/236176.html
unsubscribe
pls Am 06.05.2022 um 10:48 schrieb Richard Biener via gcc-announce : The GCC developers are proud to announce another major GCC release, 12.1. This year we celebrated the 35th anniversary of the first GCC beta release and this month we will celebrate 35 years since the GCC 1.0 release! This release deprecates support for the STABS debugging format and introduces support for the CTF debugging format [1]. The C and C++ frontends continue to advance with extending support for features in the upcoming C2X and C++23 standards and the C++ standard library improves support for the experimental C++20 and C++23 parts. The Fortran frontend now fully supports TS 29113 for interoperability with C. GCC now understands clangs __builtin_shufflevector extension making it easier to share generic vector code. Starting with GCC 12 vectorization is enabled at the -O2 optimization level using the very-cheap cost model which puts extra constraints on code size expansion. On the security side GCC can now initialize stack variables implicitly using -ftrivial-auto-var-init to help tracking down and mitigating uninitialized stack variable flaws. The C and C++ frontends now support __builtin_dynamic_object_size compatible with the clang extension. The x86 backend gained mitigations against straight line speculation with -mharden-sls. The experimental Static Analyzer gained uninitialized variable use detection and many other improvements. The x86 backend gained support for AVX512-FP16 via _Float16. The BPF backend now supports CO-RE, the RISC-V backend gained support for many new ISA extensions. Some code that compiled successfully with older GCC versions might require source changes, see http://gcc.gnu.org/gcc-12/porting_to.html for details. See https://gcc.gnu.org/gcc-12/changes.html for more information about changes in GCC 12.1. This release is available from the WWW and FTP servers listed here: https://sourceware.org/pub/gcc/releases/gcc-12.1.0/ https://gcc.gnu.org/mirrors.html The release is in the gcc-12.1.0/ subdirectory. If you encounter difficulties using GCC 12.1, please do not contact me directly. Instead, please visit http://gcc.gnu.org for information about getting help. Driving a leading free software project such as GCC would not be possible without support from its many contributors. Not only its developers, but especially its regular testers and users which contribute to its high quality. The list of individuals is too large to thank individually! [1] See https://ctfstd.org/
[RFC] Adding division/modulo on arbitrary precision integers to libgcc
Hello! We would like to add support for division/modulo on large arbitrary precision integers to libgcc/compiler-rt as required by C23's _BitInt type [0]. >From what I know, gcc doesn't yet support C23 _BitInt, but we would still like to ensure that libgcc and compiler-rt can stay compatible in the future. We created a prototype in compiler-rt [1], which uses the following declarations: /// Computes the unsigned division of a / b for two large integers /// composed of n significant words. /// Writes the quotient to quo and the remainder to rem. /// /// \param quo The quotient represented by n words. Must be non-null. /// \param rem The remainder represented by n words. Must be non-null. /// \param a The dividend represented by n + 1 words. Must be non-null. /// \param b The divisor represented by n words. Must be non-null. /// \note The word order is in host endianness. /// \note Might modify a and b. /// \note The storage of 'a' needs to hold n + 1 elements because some /// implementations need extra scratch space in the most significant word. /// The value of that word is ignored. void __udivmodei5(uint32_t *quo, uint32_t *rem, uint32_t *a, uint32_t *b, unsigned n); /// Computes the signed division of a / b. /// See __udivmodei5 for details. void __divmodei5(uint32_t *quo, uint32_t *rem, uint32_t *a, uint32_t *b, unsigned n); The current prototype requires the compiler backend to first promote large integers to a multiple of 32 bits. The extra word of storage in argument `a` is required to allow implementations to use Knuth's algorithm efficiently. We are not fixed on the current function prototypes, and would like to take your feedback. E.g. is the naming of the functions in line with the scheme used by libgcc? Best wishes, Matthias CC'ing Martin Liska as recommended by MaskRay on the PR [0] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2763.pdf [1] https://reviews.llvm.org/D120327#change-mseSeWmhjTZf Dr. Matthias Gehre SMTS Software Development Engineer | AMD Adaptive Computing Tools -- 2485 Augustine Drive, Santa Clara, CA 95054 Facebook | Twitter | amd.com
Re: [RFC] Adding division/modulo on arbitrary precision integers to libgcc
On Fri, 6 May 2022, Matthias Gehre via Gcc wrote: > We would like to add support for division/modulo on large arbitrary > precision integers to libgcc/compiler-rt as required by C23's _BitInt > type [0]. Note that each architecture also needs to specify its _BitInt ABI (including such things as whether the values of padding bits inside the size of the _BitInt type, or outside that size but within a register used for argument passing or return, have specified values or are arbitrary). HJ has a proposal for x86_64 on a branch of the ABI, but it hasn't been merged to master yet. > /// Computes the unsigned division of a / b for two large integers > /// composed of n significant words. > /// Writes the quotient to quo and the remainder to rem. > /// > /// \param quo The quotient represented by n words. Must be non-null. > /// \param rem The remainder represented by n words. Must be non-null. > /// \param a The dividend represented by n + 1 words. Must be non-null. > /// \param b The divisor represented by n words. Must be non-null. > > /// \note The word order is in host endianness. > /// \note Might modify a and b. > /// \note The storage of 'a' needs to hold n + 1 elements because some > /// implementations need extra scratch space in the most significant > word. > /// The value of that word is ignored. This proposed interface doesn't say anything about what aliasing is or isn't permitted among the four arrays pointed to. -- Joseph S. Myers jos...@codesourcery.com
Re: [RFC] Adding division/modulo on arbitrary precision integers to libgcc
On Fri, May 06, 2022 at 02:09:21PM +, Matthias Gehre via Gcc wrote: > /// \param quo The quotient represented by n words. Must be non-null. > /// \param rem The remainder represented by n words. Must be non-null. > /// \param a The dividend represented by n + 1 words. Must be non-null. > /// \param b The divisor represented by n words. Must be non-null. > > /// \note The word order is in host endianness. > /// \note Might modify a and b. > /// \note The storage of 'a' needs to hold n + 1 elements because some > /// implementations need extra scratch space in the most significant > word. > /// The value of that word is ignored. > void __udivmodei5(uint32_t *quo, uint32_t *rem, uint32_t *a, > uint32_t *b, unsigned n); > > /// Computes the signed division of a / b. > /// See __udivmodei5 for details. > void __divmodei5(uint32_t *quo, uint32_t *rem, uint32_t *a, uint32_t *b, > unsigned n); Sizes certainly should be with size_t, not unsigned type. Rather than uint32_t, wouldn't using the word size (64-bit for lp64, 32-bit for ilp32) be better? And I really don't like the N + 1 stuff you're proposing, at least for _BigInts that would be represented as an array of those word etc. elements from least to most significant (or vice versa? That really needs to be specified too), if they are same precision having to copy one of them just to get the extra scratch is bad. Jakub
Re: [RFC] Adding division/modulo on arbitrary precision integers to libgcc
On Fri, 6 May 2022, Jakub Jelinek via Gcc wrote: > And I really don't like the N + 1 stuff you're proposing, at least for > _BigInts that would be represented as an array of those word etc. elements > from least to most significant (or vice versa? That really needs to be > specified too), if they are same precision having to copy one of them just > to get the extra scratch is bad. Note that the proposed x86_64 ABI for _BitInt (branch usr/hjl/bitint) says that padding bits are unspecified. That means that when the width isn't a multiple of the word size, either you need to copy to zero-extend / sign-extend (in the general case where a variable of _BitInt type is read from memory / function argument / ..., so the code doing arithmetic on it doesn't have any further information about the values of those bits that it might have if it had computed the value itself), even in the absence of needing to allocate extra memory or allowing the libgcc function to write to those arrays, or you need to pass in a width in bits (rather than a number of words) to the libgcc function so that it can tell which bits are padding. -- Joseph S. Myers jos...@codesourcery.com
AW: [RFC] Adding division/modulo on arbitrary precision integers to libgcc
On Fri, May 06, 2022 at 02:09:21PM +, Matthias Gehre via Gcc wrote: > /// \param quo The quotient represented by n words. Must be non-null. > /// \param rem The remainder represented by n words. Must be non-null. > /// \param a The dividend represented by n + 1 words. Must be non-null. > /// \param b The divisor represented by n words. Must be non-null. > > /// \note The word order is in host endianness. > /// \note Might modify a and b. > /// \note The storage of 'a' needs to hold n + 1 elements because some > /// implementations need extra scratch space in the most significant > word. > /// The value of that word is ignored. > void __udivmodei5(uint32_t *quo, uint32_t *rem, uint32_t *a, > uint32_t *b, unsigned n); > > /// Computes the signed division of a / b. > /// See __udivmodei5 for details. > void __divmodei5(uint32_t *quo, uint32_t *rem, uint32_t *a, uint32_t *b, > unsigned n); > Sizes certainly should be with size_t, not unsigned type. Agreed > Rather than uint32_t, wouldn't using the word size (64-bit for lp64, 32-bit for ilp32) be better? Is there a portable way to specify this in C? (size_t, uintptr_t?) And is the word size clearly defined for each target? (I'm not a backend expert). > And I really don't like the N + 1 stuff you're proposing, at least for > _BigInts that would be represented as an array of those word etc. elements > from least to most significant (or vice versa? That really needs to be > specified too), if they are same precision having to copy one of them just > to get the extra scratch is bad. Yes, that's a trade-off. Knuth algorithm is generally a good choice, but not having the extra scratch space would introduce more branches into it. Also, the proposed __udivmodei5 is allowed to overwrite the inputs, so you might need to copy them anyways. I actually didn't have this N + 1 initially, but then I got a comment on the compiler-rt review, and added it subsequently. Personally, I don't mind either way.
AW: [RFC] Adding division/modulo on arbitrary precision integers to libgcc
> Note that each architecture also needs to specify its _BitInt ABI > (including such things as whether the values of padding bits inside the > size of the _BitInt type, or outside that size but within a register used > for argument passing or return, have specified values or are arbitrary). > HJ has a proposal for x86_64 on a branch of the ABI, but it hasn't been > merged to master yet. Thanks, I didn't know that this is currently in progress. This is still slightly different, because the ABI can choose to make different choices for _BitInt(N) depending on N, but here we need to specify an interface that works independent of N. > This proposed interface doesn't say anything about what aliasing is or > isn't permitted among the four arrays pointed to. Good catch. I would lean into saying that none of the four arrays must alias because allowing them to alias would require most implementations to allocate extra scratch space. What do you think? -- Joseph S. Myers jos...@codesourcery.com
Re: AW: [RFC] Adding division/modulo on arbitrary precision integers to libgcc
On Fri, 6 May 2022, Matthias Gehre via Gcc wrote: > > This proposed interface doesn't say anything about what aliasing is or > > isn't permitted among the four arrays pointed to. > Good catch. I would lean into saying that none of the four arrays must alias > because allowing them to alias would require most implementations to allocate > extra scratch space. > What do you think? Given that all four arrays can be written to, that seems reasonable (along with declaring them all as "restrict"). -- Joseph S. Myers jos...@codesourcery.com
Re: AW: [RFC] Adding division/modulo on arbitrary precision integers to libgcc
On Friday, May 6 2022, "Matthias Gehre" wrote to "lennox" saying: > Jakub Jelinek wrote: > > Rather than uint32_t, wouldn't using the word size (64-bit for lp64, 32-bit > for ilp32) be better? > Is there a portable way to specify this in C? (size_t, uintptr_t?) And is the > word size > clearly defined for each target? (I'm not a backend expert). Wouldn't this just be 'unsigned long' by definition? -- Jonathan Lennox len...@cs.columbia.edu
Re: GCC 12.1 Released
UNSUBSCRIBE On Fri, 6 May 2022, 14:57 Richard Biener via gcc-announce, < gcc-annou...@gcc.gnu.org> wrote: > > The GCC developers are proud to announce another major GCC release, 12.1. > > This year we celebrated the 35th anniversary of the first GCC beta release > and this month we will celebrate 35 years since the GCC 1.0 release! > > This release deprecates support for the STABS debugging format and > introduces support for the CTF debugging format [1]. The C and C++ > frontends continue to advance with extending support for features > in the upcoming C2X and C++23 standards and the C++ standard library > improves support for the experimental C++20 and C++23 parts. > The Fortran frontend now fully supports TS 29113 for interoperability with > C. > > GCC now understands clangs __builtin_shufflevector extension making > it easier to share generic vector code. Starting with GCC 12 > vectorization is enabled at the -O2 optimization level using the > very-cheap cost model which puts extra constraints on code size expansion. > > On the security side GCC can now initialize stack variables implicitly > using -ftrivial-auto-var-init to help tracking down and mitigating > uninitialized stack variable flaws. The C and C++ frontends now support > __builtin_dynamic_object_size compatible with the clang extension. > The x86 backend gained mitigations against straight line speculation > with -mharden-sls. The experimental Static Analyzer gained uninitialized > variable use detection and many other improvements. > > The x86 backend gained support for AVX512-FP16 via _Float16. > The BPF backend now supports CO-RE, the RISC-V backend gained support > for many new ISA extensions. > > Some code that compiled successfully with older GCC versions might require > source changes, see http://gcc.gnu.org/gcc-12/porting_to.html for > details. > > See > > https://gcc.gnu.org/gcc-12/changes.html > > for more information about changes in GCC 12.1. > > This release is available from the WWW and FTP servers listed here: > > https://sourceware.org/pub/gcc/releases/gcc-12.1.0/ > https://gcc.gnu.org/mirrors.html > > The release is in the gcc-12.1.0/ subdirectory. > > If you encounter difficulties using GCC 12.1, please do not contact me > directly. Instead, please visit http://gcc.gnu.org for information about > getting help. > > Driving a leading free software project such as GCC would not be possible > without support from its many contributors. > Not only its developers, but especially its regular testers and users which > contribute to its high quality. The list of individuals > is too large to thank individually! > > > > [1] See https://ctfstd.org/ >
Re: [RFC] Adding division/modulo on arbitrary precision integers to libgcc
Hi! On Fri, May 06, 2022 at 02:09:21PM +, Matthias Gehre via Gcc wrote: > We would like to add support for division/modulo on large arbitrary precision > integers to libgcc/compiler-rt > as required by C23's _BitInt type [0]. > > >From what I know, gcc doesn't yet support C23 _BitInt, but we would still > like to ensure that libgcc and compiler-rt can stay compatible in the future. Why? Why would that be useful at all? libgcc is an implementation detail. It is not meant to be used by anything but GCC itself, and then only to implement things that aren't implemented some other way (by target code typically). The names of the functions it implements are based on the GCC-internal RTL names, often identical even. Defining the libgcc names first is not only futile, but also the wrong order. Most functions in libgcc are a not-so-ideal-but-at-least-it-works implementation that target maintainers who cannot be bothered to implement this functionality more optimally can use. Typically what you really want is not a library routine at all! As noted elsewhere (I forgot by whom, sorry) the target ABI will probably have somemthing to say about the actual data representation, so it is very counterproductive if we have something in libgcc that does something else. Segher
gcc-11-20220506 is now available
Snapshot gcc-11-20220506 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-20220506/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 11 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-11 revision d38212762549d12b9c6428b1ff9fecbc05db2b99 You'll find: gcc-11-20220506.tar.xz Complete GCC SHA256=aaa0de3c4538b20c0c4b7e3add628d56fe819340efcdf192076f2b01f1cb1a21 SHA1=a7a64dcf52d0dc5828ee51b22425acb5f552b220 Diffs from 11-20220429 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-11 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.
