GCC 13.2 Release Candidate available from gcc.gnu.org
The first release candidate for GCC 13.2 is available from https://gcc.gnu.org/pub/gcc/snapshots/13.2.0-RC-20230720/ ftp://gcc.gnu.org/pub/gcc/snapshots/13.2.0-RC-20230720/ and shortly its mirrors. It has been generated from git commit r13-7597-g9aac37ab8a7b91. I have so far bootstrapped and tested the release candidate on x86_64-linux. Please test it and report any issues to bugzilla. If all goes well, we'd like to release 13.2 on Thursday, July 27th.
GCC 13.1.1 Status Report (2023-07-20)
Status == The GCC 13 branch is frozen for the release of GCC 13.2 with a first release candidate published. All changes require release manager approval. Quality Data Priority # Change from last report --- --- P10 - 2 P2 511 - 3 P3 120 + 11 P4 214 - 2 P5 24 --- --- Total P1-P3 631 + 6 Total 869 + 4 Previous Report === https://gcc.gnu.org/pipermail/gcc/2023-June/241838.html
LRA for avr: Clobber with match_dup
Hi,
The avr backend has this define_insn_and_split
(define_insn_and_split "*tablejump_split"
[(set (pc)
(unspec:HI [(match_operand:HI 0 "register_operand" "!z,*r,z")]
UNSPEC_INDEX_JMP))
(use (label_ref (match_operand 1 "" "")))
(clobber (match_dup 0))
(clobber (const_int 0))]
"!AVR_HAVE_EIJMP_EICALL"
"#"
"&& reload_completed"
[(parallel [(set (pc)
(unspec:HI [(match_dup 0)]
UNSPEC_INDEX_JMP))
(use (label_ref (match_dup 1)))
(clobber (match_dup 0))
(clobber (const_int 0))
(clobber (reg:CC REG_CC))])]
""
[(set_attr "isa" "rjmp,rjmp,jmp")])
Note the (clobber (match_dup 0)). When building
$ avr-gcc -mmcu=avr51 gcc/gcc/testsuite/gcc.c-torture/compile/930120-1.c -O3
-funroll-loops -fdump-rtl-all
The web pass transforms this insn from
(jump_insn 120 538 124 25 (parallel [
(set (pc)
(unspec:HI [
(reg:HI 138)
] UNSPEC_INDEX_JMP))
(use (label_ref 121))
(clobber (reg:HI 138))
(clobber (const_int 0 [0]))
]) "gcc/gcc/testsuite/gcc.c-torture/compile/930120-1.c":55:5 779
{*tablejump_split}
(expr_list:REG_DEAD (reg:HI 138)
(expr_list:REG_UNUSED (reg:HI 138)
(nil)))
-> 121)
to
Web oldreg=138 newreg=279
Updating insn 120 (138->279)
(jump_insn 120 538 124 25 (parallel [
(set (pc)
(unspec:HI [
(reg:HI 138)
] UNSPEC_INDEX_JMP))
(use (label_ref 121))
(clobber (reg:HI 279))
(clobber (const_int 0 [0]))
]) "gcc/gcc/testsuite/gcc.c-torture/compile/930120-1.c":55:5 779
{*tablejump_split}
(expr_list:REG_DEAD (reg:HI 138)
(expr_list:REG_UNUSED (reg:HI 138)
(nil)))
-> 121)
Note the reg in the clobber is now 279, and not 138.
With classic reload, however, this gets set back to whatever hardreg was
assigned to r138.
(jump_insn 120 538 121 26 (parallel [
(set (pc)
(unspec:HI [
(reg/f:HI 30 r30 [138])
] UNSPEC_INDEX_JMP))
(use (label_ref 121))
(clobber (reg/f:HI 30 r30 [138]))
(clobber (const_int 0 [0]))
]) "gcc/gcc/testsuite/gcc.c-torture/compile/930120-1.c":55:5 779
{*tablejump_split}
(nil)
-> 121)
With LRA, however, the pseudo reg remains unassigned, eventually causing an ICE
in cselib_invalidate_regno.
(jump_insn 120 538 121 26 (parallel [
(set (pc)
(unspec:HI [
(reg/f:HI 30 r30 [138])
] UNSPEC_INDEX_JMP))
(use (label_ref 121))
(clobber (reg:HI 279))
(clobber (const_int 0 [0]))
]) "gcc/gcc/testsuite/gcc.c-torture/compile/930120-1.c":55:5 779
{*tablejump_split}
(nil)
-> 121)
Is this something that LRA should be able to fix?
Making operand 0 read/write in define_insn_and_split prevents the web pass from
creating a new pseudo
for the clobber, avoiding the whole problem.
(define_insn_and_split "*tablejump_split"
[(set (pc)
(unspec:HI [(match_operand:HI 0 "register_operand" "+!z,*r,z")]
UNSPEC_INDEX_JMP))
(use (label_ref (match_operand 1 "" "")))
(clobber (match_dup 0))
(clobber (const_int 0))]
"!AVR_HAVE_EIJMP_EICALL"
"#"
"&& reload_completed"
[(parallel [(set (pc)
(unspec:HI [(match_dup 0)]
UNSPEC_INDEX_JMP))
(use (label_ref (match_dup 1)))
(clobber (match_dup 0))
(clobber (const_int 0))
(clobber (reg:CC REG_CC))])]
""
[(set_attr "isa" "rjmp,rjmp,jmp")])
However, https://gcc.gnu.org/onlinedocs/gccint/Side-Effects.html has this to
say for clobber
"There is one other known use for clobbering a pseudo register in a parallel:
when one of the input operands of the insn is also
clobbered by the insn. In this case, using the same pseudo register in the
clobber and elsewhere in the insn produces the expected
results."
so I'm not sure if that's the right way to fix it. I could add a matching
constraint (i.e "=0,0,0"), but until reload runs,
the clobber reg would be different from input reg, so that seems wrong to me
too.
Any ideas?
Regards
Senthil
Re: LRA for avr: Clobber with match_dup
> Making operand 0 read/write in define_insn_and_split prevents the web pass > from creating a new pseudo > for the clobber, avoiding the whole problem. That is the right solution. If you clobber a match_dup of an input operand, that makes it and input-and-output operand, so you should mark it as such.
Beginner Looking for Mentors to Get Started
Hi, I'm a college student interested in contributing to gcc. I'm passionate about compilers and have worked on a few personnel projects using Rust, C++ and C. Please let me know if anyone is interested in mentoring me on where I can get started? Thanks, Veera
Re: LRA for avr: Clobber with match_dup
On 7/20/23 07:17, senthilkumar.selva...@microchip.com wrote:
Hi,
The avr backend has this define_insn_and_split
(define_insn_and_split "*tablejump_split"
[(set (pc)
(unspec:HI [(match_operand:HI 0 "register_operand" "!z,*r,z")]
UNSPEC_INDEX_JMP))
(use (label_ref (match_operand 1 "" "")))
(clobber (match_dup 0))
(clobber (const_int 0))]
"!AVR_HAVE_EIJMP_EICALL"
"#"
"&& reload_completed"
[(parallel [(set (pc)
(unspec:HI [(match_dup 0)]
UNSPEC_INDEX_JMP))
(use (label_ref (match_dup 1)))
(clobber (match_dup 0))
(clobber (const_int 0))
(clobber (reg:CC REG_CC))])]
""
[(set_attr "isa" "rjmp,rjmp,jmp")])
Note the (clobber (match_dup 0)). When building
$ avr-gcc -mmcu=avr51 gcc/gcc/testsuite/gcc.c-torture/compile/930120-1.c -O3
-funroll-loops -fdump-rtl-all
The web pass transforms this insn from
(jump_insn 120 538 124 25 (parallel [
(set (pc)
(unspec:HI [
(reg:HI 138)
] UNSPEC_INDEX_JMP))
(use (label_ref 121))
(clobber (reg:HI 138))
(clobber (const_int 0 [0]))
]) "gcc/gcc/testsuite/gcc.c-torture/compile/930120-1.c":55:5 779
{*tablejump_split}
(expr_list:REG_DEAD (reg:HI 138)
(expr_list:REG_UNUSED (reg:HI 138)
(nil)))
-> 121)
to
Web oldreg=138 newreg=279
Updating insn 120 (138->279)
(jump_insn 120 538 124 25 (parallel [
(set (pc)
(unspec:HI [
(reg:HI 138)
] UNSPEC_INDEX_JMP))
(use (label_ref 121))
(clobber (reg:HI 279))
(clobber (const_int 0 [0]))
]) "gcc/gcc/testsuite/gcc.c-torture/compile/930120-1.c":55:5 779
{*tablejump_split}
(expr_list:REG_DEAD (reg:HI 138)
(expr_list:REG_UNUSED (reg:HI 138)
(nil)))
-> 121)
Note the reg in the clobber is now 279, and not 138.
With classic reload, however, this gets set back to whatever hardreg was
assigned to r138.
It is just a fortunate side effect of algorithm how the reload pass
changes pseudos to their hard registers.
(jump_insn 120 538 121 26 (parallel [
(set (pc)
(unspec:HI [
(reg/f:HI 30 r30 [138])
] UNSPEC_INDEX_JMP))
(use (label_ref 121))
(clobber (reg/f:HI 30 r30 [138]))
(clobber (const_int 0 [0]))
]) "gcc/gcc/testsuite/gcc.c-torture/compile/930120-1.c":55:5 779
{*tablejump_split}
(nil)
-> 121)
With LRA, however, the pseudo reg remains unassigned, eventually causing an ICE
in cselib_invalidate_regno.
(jump_insn 120 538 121 26 (parallel [
(set (pc)
(unspec:HI [
(reg/f:HI 30 r30 [138])
] UNSPEC_INDEX_JMP))
(use (label_ref 121))
(clobber (reg:HI 279))
(clobber (const_int 0 [0]))
]) "gcc/gcc/testsuite/gcc.c-torture/compile/930120-1.c":55:5 779
{*tablejump_split}
(nil)
-> 121)
Is this something that LRA should be able to fix?
No, LRA can not do this but it keeps match_dup correct after any reloads
and insn transformations.
I think it is a web optimization bug. RA assumes the insn recognition
should give the same insn code as it present in the insn.
In my opinion any optimization pass can assume this at the pass start
and should keep this condition after its work finish.
Re: Beginner Looking for Mentors to Get Started
Hi, Veera Thanks for your interest in GCC. Welcome! A good place to start is the GCC Wiki Getting Started page: https://gcc.gnu.org/wiki/#Getting_Started_with_GCC_Development David Malcolm has written a wonderful introduction to GCC for newcomers: https://gcc-newbies-guide.readthedocs.io/en/latest/ and browse other recent answers to similar questions in the archives of this mailing list. Thanks, David On Thu, Jul 20, 2023 at 2:37 PM Veera Sivarajan via Gcc wrote: > > Hi, > > I'm a college student interested in contributing to gcc. I'm passionate > about compilers and have worked on a few personnel projects using Rust, C++ > and C. Please let me know if anyone is interested in mentoring me on where > I can get started? > > Thanks, > Veera
Re: [PATCH v5 4/5] c++modules: report imported CMI files as dependencies
On 7/19/23 20:47, Ben Boeckel wrote: On Wed, Jul 19, 2023 at 17:11:08 -0400, Nathan Sidwell wrote: GCC is neither of these descriptions. a CMI does not contain the transitive closure of its imports. It contains an import table. That table lists the transitive closure of its imports (it needs that closure to do remapping), and that table contains the CMI pathnames of the direct imports. Those pathnames are absolute, if the mapper provded an absolute pathm or relative to the CMI repo. The rationale here is that if you're building a CMI, Foo, which imports a bunch of modules, those imported CMIs will have the same (relative) location in this compilation and in compilations importing Foo (why would you move them?) Note this is NOT inhibiting relocatable builds, because of the CMI repo. 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. - 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. 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. On 7/18/23 20:01, Ben Boeckel wrote: Maybe I'm missing how this *actually* works in GCC as I've really only interacted with it through the command line, but I've not needed to mention `a.cmi` when compiling `use.cppm`. Is `a.cmi` referenced and read through some embedded information in `b.cmi` or does `b.cmi` include enough information to not need to read it at all? If the former, distributed builds are going to have a problem knowing what files to send just from the command line (I'll call this "implicit thin"). If the latter, that is the "fat" CMI that I'm thinking of. please don't use perjorative terms like 'fat' and 'thin'. Sorry, I was internally analogizing to "thinLTO". --Ben -- Nathan Sidwell
Re: semantics of uninitialized values in GIMPLE
On Tue, 11 Jul 2023, Krister Walfridsson wrote: On Tue, 11 Jul 2023, Richard Biener wrote: I'll update my implementation, and will come back with a more detailed proposal in a few weeks when I have tried some more things. Thanks! I've also taken the opportunity given by your work at the recent bugs to propose a talk at this years GNU Cauldron about undefined behavior on GCC and hope to at least start on documenting the state of art^WGCC in the internals manual for this. If you have any pointers to your work / research I'd be happy to point to it, learn from it (and maybe steal a word or two ;)). Nice! No, I have not published anything since the original release of 'pysmtgcc' last year -- I was planning to document it in detail, but found out that nothing worked, and I did not really understand what I was doing... And the Python prototype started to be annoying, so I threw all away and wrote a new tool in C++. The new implementation now handles most of GIMPLE (but it still does not handle loops or function calls). I also have support for checking that the generated assembly has the same semantics as the optimized GIMPLE (only partial support for RISC-V for now). I plan to publish a write-up of the memory model soon in a series of blog posts -- I'll send you the link when it is available. I have now published a few blog posts about my work. You can find them at: https://github.com/kristerw/pysmtgcc I'll publish the remaining blog posts next week. /Krister
gcc-11-20230720 is now available
Snapshot gcc-11-20230720 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-20230720/ 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 7bd1373f87d581b1e5482f9c558d481c38027a99 You'll find: gcc-11-20230720.tar.xz Complete GCC SHA256=14996fb0a8aa45dec9031bffd42d9da553f4f79a5634c6c14a592472ed406c1a SHA1=9fde135a3cb84f7c30119cea689d2679e5046ee5 Diffs from 11-20230713 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.
Re: Warning specifically for a returning noreturn
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, 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 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? Thoughts? best regards, Julian On Wed, Jul 5, 2023 at 9:13 PM Julian Waters wrote: > Hi Jonathan, > > Thanks for the reply, is there a place in gcc's source code I could look > at for this? As for the returning an explicit value from noreturn, I'm > unfortunately not the one who wrote the code that way; I'm merely a build > systems developer trying to get it to work with gcc :/ > > best regards, > Julian > > On Wed, 5 Jul 2023, 19:26 Jonathan Wakely, wrote: > >> On Wed, 5 Jul 2023 at 12:01, Julian Waters via Gcc >> wrote: >> > >> > I see, thanks Andrew. >> > >> > Anyone else have opinions on this besides Liu or Andrew? The responses >> have >> > been surprisingly quiet thus far >> >> IMHO all warnings should have an option controlling them, so that you >> can disable them via pragmas. >> >> But I agree that you shouldn't need to return from a noreturn >> function, it can either throw or use __builtin_unreachable() on the >> line where you currently return. >> >> >> > >> > best regards, >> > Julian >> > >> > On Wed, 5 Jul 2023, 09:40 Andrew Pinski, wrote: >> > >> > > On Tue, Jul 4, 2023 at 6:32 PM Julian Waters > > >> > > wrote: >> > > > >> > > > Hi Andrew, thanks for the quick response, >> > > > >> > > > What if the method has a return value? I know it sounds >> > > counterintuitive, but in some places HotSpot relies on the noreturn >> > > attribute being applied to methods that do return a value in an >> unreachable >> > > code path. Does the unreachable builtin cover that case too? >> > > >> > > It is wrong to use noreturn on a function other than one which has a >> > > return type of void as documented. >> > > >> > > >> https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-noreturn-function-attribute >> > > : >> > > ``` >> > > It does not make sense for a noreturn function to have a return type >> > > other than void. >> > > ``` >> > > >> > > Thanks, >> > > Andrew Pinski >> > > >> > > >> > > > >> > > > best regards. >> > > > Julian >> > > > >> > > > On Wed, Jul 5, 2023 at 9:07 AM Andrew Pinski >> wrote: >> > > >> >> > > >> On Tue, Jul 4, 2023 at 5:54 PM Julian Waters via Gcc < >> gcc@gcc.gnu.org> >> > > wrote: >> > > >> > >> > > >> > Hi all, >> > > >> > >> > > >> > Currently to disable the warning that a noreturn method does >> return, >> > > it's >> > > >> > required to disable warnings entirely. This can be very >> inconvenient >> > > when >> > > >> > -Werror is enabled with a noreturn method that isn't specifically >> > > calling >> > > >> > something like std::abort() at the end, when one wants all other >> > > -Wall and >> > > >> > -Wextra warnings to be reported, for instance in the Java >> HotSpot VM >> > > (which >> > > >> > I'm currently adapting to compile with gcc on all supported >> > > platforms). Is >> > > >> > there a possibility we can add a disable warning option >> specifically >> > > for >> > > >> > this case? Something like -Wno-returning-noreturn. I'm >> interested in >> > > adding >> > > >> > this myself if it's not convenient for gcc's maintainers to do >> so at >> > > the >> > > >> > moment, but I'd need some guidance on where to look and what the >> > > relevant >> > > >> > code is >> > > >> >> > > >> You could just add >> > > >> __builtin_unreachable(); (or std::unreachable(); if you are C++23 >> or >> > > >> unreachable() if you are using C23). >> > > >> Or even add while(true) ; >> > > >> >> > > >> I am pretty sure not having an option is on purpose and not really >> > > >> interested in adding an option here because of the above >> workarounds. >> > > >> >> > > >> Thanks, >> > > >> Andrew Pinski >> > > >> >> > > >> > >> > > >> > best regards, >> > > >> > Julian >> > > >> >
