[Bug fortran/96012] [9/10/11 Regression] ICE in fold_convert_loc, at fold-const.c:2558
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96012 Ev Drikos changed: What|Removed |Added CC||drikosev at gmail dot com --- Comment #3 from Ev Drikos --- Created attachment 49809 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49809&action=edit deferred length character array Hello P. Thomas, At first, this is obviously a complex patch, which as it seems should normally have no regressions, so far. It's my impression that the attachment is relevant, ie due to variable realloc_flag in trans-expr.c, but currently I can't rebuild the code from trunk. So, I can't be sure if the test case would fail or pass. Note that this example have been submitted to c.l.f by a third person, I haven't written it. Hope this helps, Ev. Drikos
[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 --- Comment #12 from Dominique d'Humieres --- The following test compiles (swapping fun1 and fun2): module buggy implicit none type :: bar integer :: x end type bar type :: foo integer :: n contains procedure :: fun1 procedure :: fun2 end type foo contains integer function fun1(this, a) implicit none class(foo) :: this class(bar), intent(in) :: a(this%n) fun1 = a(1)%x end function fun1 subroutine fun2(this, a) implicit none class(foo) :: this class(bar), intent(in) :: a(this%n) end subroutine fun2 end module buggy
[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 --- Comment #13 from Thomas Koenig --- (In reply to Gabor from comment #10) > Good to know that gfortran has come to an end. It means, for example, that > i will not rely on the openacc implementation either. Or openmp5. Those two fields are actually seeing a lot of funded development right now, done by Mentor Graphics. OpenMP5 is not yet supported, but this is being worked on. As far as general development is concerned: Like Steve, I am one of the volunteers maintaining the compiler. You write that you're not a compiler writer; well, neither am I, in a professional sense. I am a chemical engineer who very occasionally uses Fortran for his day-time job. I contribute to gfortran mainly for three reasons: a) I like the language b) I like the intellectual challenge and c) I want to give something back to the open source community. People often think that you need to be an exceptionally good programmer to contribute to a compiler. I can testify from first-hand experience that this is not necessary, since I am absolutely certain that I am not exceptionally good :-) If you feel strongly that some bug should be fixed, there are several options available to you. You can convince the organization you work for to fund some bug-fixing. You can try to motivate people to fix this (negative motivation usually does not work), or you can try to fix it yourself. Although there is an entry barrier to doing things to the compiler, it is quite possible to find an entry to this, and it is always possible to ask for advice. A starting point is https://gcc.gnu.org/wiki/GFortranHacking . You will need a general-level knowledge of C for this (technically, the gfortran front end to gcc is written in C++, but it is very close to the common subset of C and C++).
[Bug target/98399] New: x86: Awful code generation for shifting vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98399 Bug ID: 98399 Summary: x86: Awful code generation for shifting vectors Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: gabravier at gmail dot com Target Milestone: --- typedef char U __attribute__((vector_size(16))); U f(U u) { return u >> (u & 1); } When compiled with -O3, on LLVM, this code generates this : .LCPI0_0: .zero 16,1 f(char __vector(16)): # @f(char __vector(16)) movdqa xmm3, xmmword ptr [rip + .LCPI0_0] # xmm3 = [1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1] pand xmm3, xmm0 punpckhbw xmm1, xmm0 # xmm1 = xmm1[8],xmm0[8],xmm1[9],xmm0[9],xmm1[10],xmm0[10],xmm1[11],xmm0[11],xmm1[12],xmm0[12],xmm1[13],xmm0[13],xmm1[14],xmm0[14],xmm1[15],xmm0[15] psllw xmm3, 5 punpckhbw xmm4, xmm3 # xmm4 = xmm4[8],xmm3[8],xmm4[9],xmm3[9],xmm4[10],xmm3[10],xmm4[11],xmm3[11],xmm4[12],xmm3[12],xmm4[13],xmm3[13],xmm4[14],xmm3[14],xmm4[15],xmm3[15] pxor xmm2, xmm2 pxor xmm5, xmm5 pcmpgtw xmm5, xmm4 movdqa xmm6, xmm5 pandn xmm6, xmm1 psraw xmm1, 4 pand xmm1, xmm5 por xmm1, xmm6 paddw xmm4, xmm4 pxor xmm5, xmm5 pcmpgtw xmm5, xmm4 movdqa xmm6, xmm5 pandn xmm6, xmm1 psraw xmm1, 2 pand xmm1, xmm5 por xmm1, xmm6 paddw xmm4, xmm4 pxor xmm5, xmm5 pcmpgtw xmm5, xmm4 movdqa xmm4, xmm5 pandn xmm4, xmm1 psraw xmm1, 1 pand xmm1, xmm5 por xmm1, xmm4 psrlw xmm1, 8 punpcklbw xmm0, xmm0 # xmm0 = xmm0[0,0,1,1,2,2,3,3,4,4,5,5,6,6,7,7] punpcklbw xmm3, xmm3 # xmm3 = xmm3[0,0,1,1,2,2,3,3,4,4,5,5,6,6,7,7] pxor xmm4, xmm4 pcmpgtw xmm4, xmm3 movdqa xmm5, xmm4 pandn xmm5, xmm0 psraw xmm0, 4 pand xmm0, xmm4 por xmm0, xmm5 paddw xmm3, xmm3 pxor xmm4, xmm4 pcmpgtw xmm4, xmm3 movdqa xmm5, xmm4 pandn xmm5, xmm0 psraw xmm0, 2 pand xmm0, xmm4 por xmm0, xmm5 paddw xmm3, xmm3 pcmpgtw xmm2, xmm3 movdqa xmm3, xmm2 pandn xmm3, xmm0 psraw xmm0, 1 pand xmm0, xmm2 por xmm0, xmm3 psrlw xmm0, 8 packuswb xmm0, xmm1 ret Which is rather long, however GCC generates this : f(char __vector(16)): push r15 movd edx, xmm0 push r14 push r13 push r12 push rbp push rbx sub rsp, 400 movdqa xmm1, XMMWORD PTR .LC0[rip] movaps XMMWORD PTR [rsp+376], xmm0 movzx ebx, BYTE PTR [rsp+377] pand xmm1, xmm0 movaps XMMWORD PTR [rsp+344], xmm0 movzx ebp, BYTE PTR [rsp+346] movd ecx, xmm1 movaps XMMWORD PTR [rsp+360], xmm1 sar dl, cl movzx ecx, BYTE PTR [rsp+361] movaps XMMWORD PTR [rsp+328], xmm1 movaps XMMWORD PTR [rsp+312], xmm0 movzx edx, dl movzx r12d, BYTE PTR [rsp+315] sar bl, cl movzx ecx, BYTE PTR [rsp+330] movaps XMMWORD PTR [rsp+296], xmm1 movaps XMMWORD PTR [rsp+280], xmm0 movzx ebx, bl movzx r13d, BYTE PTR [rsp+284] sar bpl, cl movzx ecx, BYTE PTR [rsp+299] movaps XMMWORD PTR [rsp+264], xmm1 movaps XMMWORD PTR [rsp+248], xmm0 movzx ebp, bpl movzx r14d, BYTE PTR [rsp+253] sar r12b, cl movzx ecx, BYTE PTR [rsp+268] movaps XMMWORD PTR [rsp+232], xmm1 movaps XMMWORD PTR [rsp+216], xmm0 movzx r12d, r12b movzx r15d, BYTE PTR [rsp+222] sar r13b, cl movzx ecx, BYTE PTR [rsp+237] movaps XMMWORD PTR [rsp+200], xmm1 movzx r13d, r13b sar r14b, cl movzx ecx, BYTE PTR [rsp+206] movaps XMMWORD PTR [rsp+184], xmm0 movzx eax, BYTE PTR [rsp+191] movaps XMMWORD PTR [rsp+168], xmm1 movzx r14d, r14b sar r15b, cl movzx ecx, BYTE PTR [rsp+175] movaps XMMWORD PTR [rsp+120], xmm0 movzx edi, BYTE PTR [rsp+129] movaps XMMWORD PTR [rsp+152], xmm0 movzx esi, BYTE PTR [rsp+160] movzx r15d, r15b sar al, cl movaps XMMWORD PTR [rsp+136], xmm1 movzx ecx, BYTE PTR [rsp+144] movaps XMMWORD PTR [rsp+104], xmm1 sar sil, cl movzx ecx, BYTE PTR [rsp+113] movaps XMMWORD PTR [rsp+88], xmm0 mov BYTE PTR [rsp-89], sil sar dil, cl movaps XMMWORD PTR [rsp+72], xmm1 movzx ecx, BYTE PTR [rsp+82] movzx esi, dil movzx edi, BYTE PTR [rsp+98] movaps XMMWORD PTR [rsp+56], xmm0 movzx r8d, BYTE PTR [rsp+67] movaps XMMWORD PTR [rsp+40], xmm1 sar dil, cl movzx ecx, BYTE PTR [rsp+51] movaps XMMWORD PTR [rsp+24], xmm0 movzx r9d, BYTE PTR [rsp+36] movaps XMMWORD PTR [rsp+8], xmm1 movzx edi, dil sar r8b, cl movzx ecx, BYTE PTR [rsp+20] movaps XMMWORD PTR [rsp-8], xmm0 movzx r10d, BYTE PTR [rsp+5] movaps XMMWORD PTR [rsp-24], xmm1 movzx r8d, r8b sar r9b, cl movzx ecx, BYTE PTR [rsp-11] mov BYTE PTR [rsp-120], al movaps XMMWORD PTR [rsp-40], xmm0 movzx r9d, r9b sar r10b, cl movaps XMMWORD PTR [rsp-56], xmm1 movzx ecx, BYTE PTR [rsp-42] movzx r11d, BYTE PTR [rsp-26] movaps XMMWORD PTR [rsp-72], xmm0 movzx eax, BYTE PTR [rsp-57] movzx r10d, r10b sar r11b, cl movaps XMMWORD PTR [rsp-88], xmm1 movzx ecx, BYTE PTR [rsp-73] movzx r11d, r11b sar al, cl movzx ecx, al movzx eax, BYT
[Bug c++/93480] Defaulted <=> doesn't expand array elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93480 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Jakub Jelinek --- Created attachment 49810 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49810&action=edit gcc11-pr93480.patch Untested fix.
[Bug other/98400] New: GCC online docs "S/390 and zSeries Options" has a typo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98400 Bug ID: 98400 Summary: GCC online docs "S/390 and zSeries Options" has a typo Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: firasuke at gmail dot com Target Milestone: --- There's a typo in the following page: https://gcc.gnu.org/onlinedocs/gcc/S_002f390-and-zSeries-Options.html#S_002f390-and-zSeries-Options in the "-mbackchain" and "-mno-backchain" section: "In general, code compiled with -mbackchain is call-compatible with code compiled with -mmo-backchain; however, use of the backchain for..." where it says "-mmo-backchain" instead of "-mno-backchain".
[Bug c++/98401] New: Temporaries passed to co_await sometimes cause an extraneous call to destructor at incorrect address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98401 Bug ID: 98401 Summary: Temporaries passed to co_await sometimes cause an extraneous call to destructor at incorrect address Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: brandt.milo2 at gmail dot com Target Milestone: --- Created attachment 49811 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49811&action=edit main file I was writing some code using coroutines the other day and started noticing that the destructor of a std::string was crashing in certain situations. The problem seems to arise in gcc's handling of passing a temporary to co_await, but it's a bit finicky when exactly this arises. I found a minimal working example, which is attached (both the original .cpp and the post-pre-processed .ii file, although only standard library headers are #include'd). It does the following: (1) Defines a class lifetime_tester that prints something whenever its constructed, assigned, or destructed. It also has a single member that must, by all rights, always equal this to demonstrate some further perplexing behavior. (2) Defines a struct tag whose single element is a lifetime_tester. (3) Defines the simplest possible coroutine, which just runs the code without suspending and has a single await_transform member accepting a tag&& and outputting the address and value of the member of that reference. (4) A coroutine which passes a temporary of type tag. (5) An invocation of that coroutine in main(). The expected output of this program (and the output I get when compiled with clang++ and the experimental parts of libc++) would be something like: Constructed at 0x1ba32e0 Poked at 0x1ba32e0 with ptr to 0x1ba32e0 Destructed at 0x1ba32e0 End of coroutine body. Where a lifetime_tester is constructed at some address, observed at that address, then destructed. However, when I compile the code with g++-10 -std=c++20 -fcoroutines main.cpp -o program where g++-10 --version gives g++-10 (Ubuntu 10.2.0-5ubuntu1~20.04) 10.2.0. I get some very surprising output: Constructed at 0x560814d21ee0 Poked at 0x560814d21ed8 with ptr to 0x560814d21ee0 Destructed at 0x560814d21ed8 Destructed at 0x560814d21ee0 End of coroutine body. The constructor is called at some address, but then when we look at the temporary passed to co_await, its address is 8 bytes higher than where the constructor was called (yet it somehow has a member pointing to the original address). Then, the destructor is called at this higher address and then called again at the correct address. The difference between the two addresses is consistent between runs. Various perturbations of the code yield varying results: * If we change the signature of await_transform to auto await_transform(tag), the bug remains. * If we construct a local variable of type tag in the coroutine, then pass it to co_await (possibly calling std::move on it), the program behaves correctly, regardless of whether we pass by rvalue or lvalue reference or by value. * If we remove the struct tag and just pass lifetime_tester, the program behaves as expected. * If we change the struct to be struct tag { int x; lifetime_tester tester; }; the incorrect address appears 8 bytes lower than the original one instead of 8 bytes higher. Similarly if we did struct tag{ lifetime_tester tester; int x; }; * If we leave the struct tag as it originally was, but add more elements to lifetime_tester (e.g. add a member char padding[1024]), the difference between the addresses increases - and seems to always equal -sizeof(lifetime_tester) bytes. I also tried compiling the master branch of the gcc git repository and noticed the same behavior when compiling the program (--version gives g++ (GCC) 11.0.0 20201219 (experimental)). The same behavior happens if I try the code on godbolt on various recent gcc branches (https://godbolt.org/z/fx6YPb) - though, oddly, selecting x86-64 gcc 10.2 on the compiler explorer produces a different incorrect output: Constructed at 0x21cbed8 Poked at 0x21cbed8 with ptr to 0x21cbed8 End of coroutine body. Where the destructor is not called on the temporary at all. Attached is the original main.cpp file which can be compiled with the command listed earlier.
[Bug c++/98401] Temporaries passed to co_await sometimes cause an extraneous call to destructor at incorrect address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98401 --- Comment #1 from Milo Brandt --- Created attachment 49812 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49812&action=edit A zipped copy of the preprocessed source (main.ii) - which is slightly larger than the 1000 KB file size limit alone
[Bug go/98402] New: [11 Regression] libgo build broken on arm-linux-gnueabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98402 Bug ID: 98402 Summary: [11 Regression] libgo build broken on arm-linux-gnueabi Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: doko at debian dot org CC: cmang at google dot com Target Milestone: --- seen with trunk 20201219 on arm-linux-gnueabihf: runtime_sysinfo.go:800:29: error: floating-point exponent too large to represent 800 | const ___FLT32_NORM_MAX__ = 3.4028234663852886e+3832 | ^ runtime_sysinfo.go:4593:24: error: floating-point exponent too large to represent 4593 | const ___FLT32_MAX__ = 3.4028234663852886e+3832 |^ make[6]: *** [Makefile:2967: runtime.lo] Error 1 make[6]: *** Waiting for unfinished jobs configured with: --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-11 --program-prefix=arm-linux-gnueabihf- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --disable-libquadmath-support --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-werror --enable-multilib --enable-checking=yes --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf make target is profiledbootstrap-lean
[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 --- Comment #14 from Gabor --- Hi All, I am sorry if I hurt anyone’s feelings. My goal was to get things improved for the future. If my dry humor offended you, my apologies. Even if you fixed the bug today, I would still have to find a work-around. My nightly tests fail, the users of our software will not upgrade to the latest gfortran, the super computers keep running old versions, and they are not willing to update. So, why I may look selfish in your eyes, the main goal of reporting that the bug still exists in gfortran 10 was to get things better eventually. I have no time to learn how gcc works and find this bug in it and fix it. One would assume that the person who wrote this part of the compiler could fix it easily given the tiny amount of code that can reproduce the problem. For anyone else it is hard. In the end, I have split my module into two parts and that somehow solved the problem. The smallest code producing the issue had 4 functions. I am attaching it in case anyone actually wants it. I have assumed, apparently incorrectly, that gcc and its part gfortran are maintained by the GNU project and that the GNU project has some business model. gcc seems to thrive. I guess gfortran is not important enough. You should take pride in having a compiler as good as intel, nag and much better than pgi. Cheers, Gabor
[Bug other/98400] GCC online docs "S/390 and zSeries Options" has a typo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98400 --- Comment #1 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:8b01af02b50761bbe4e078c60d030912ab359c9a commit r11-6275-g8b01af02b50761bbe4e078c60d030912ab359c9a Author: Jakub Jelinek Date: Sun Dec 20 18:59:57 2020 +0100 doc: Fix a typo [PR98400] Fix a typo in an option name in documentation. 2020-12-20 Jakub Jelinek PR other/98400 * doc/invoke.texi (-mbackchain): Fix a typo - -mmo-backchain -> -mno-backchain.
[Bug other/98400] GCC online docs "S/390 and zSeries Options" has a typo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98400 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jakub Jelinek --- Fixed. The online docs will be regenerated within a week.
[Bug target/98403] New: [11 Regression] ICE: in add_def, at rtl-ssa/accesses.cc:837 with -Og -march=goldmont -fPIC -fcse-follow-jumps -fipa-ra -mforce-indirect-call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98403 Bug ID: 98403 Summary: [11 Regression] ICE: in add_def, at rtl-ssa/accesses.cc:837 with -Og -march=goldmont -fPIC -fcse-follow-jumps -fipa-ra -mforce-indirect-call Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 49815 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49815&action=edit auto-reduced testcase (from OpenTTD sources) Compiler output: $ x86_64-pc-linux-gnu-gcc -Og -march=goldmont -fPIC -fcse-follow-jumps -fipa-ra -mforce-indirect-call ai_gui.ii during RTL pass: fwprop1 ai_gui.ii: In function 'void __static_initialization_and_destruction_0(int, int)': ai_gui.ii:191:58: internal compiler error: in add_def, at rtl-ssa/accesses.cc:837 191 | SetDataTip(2, 3)}; | ^ 0xa44aac rtl_ssa::function_info::add_def(rtl_ssa::def_info*) /repo/gcc-trunk/gcc/rtl-ssa/accesses.cc:837 0x1e06fed rtl_ssa::function_info::apply_changes_to_insn(rtl_ssa::insn_change&) /repo/gcc-trunk/gcc/rtl-ssa/changes.cc:540 0x1e0976f rtl_ssa::function_info::change_insns(array_slice) /repo/gcc-trunk/gcc/rtl-ssa/changes.cc:707 0x1e09957 rtl_ssa::function_info::change_insn(rtl_ssa::insn_change&) /repo/gcc-trunk/gcc/rtl-ssa/changes.cc:715 0x1cdea78 try_fwprop_subst_pattern /repo/gcc-trunk/gcc/fwprop.c:530 0x1cdea78 try_fwprop_subst /repo/gcc-trunk/gcc/fwprop.c:603 0x1cdf1a0 forward_propagate_and_simplify /repo/gcc-trunk/gcc/fwprop.c:801 0x1cdf1a0 forward_propagate_into /repo/gcc-trunk/gcc/fwprop.c:861 0x1cdf48b forward_propagate_into /repo/gcc-trunk/gcc/fwprop.c:813 0x1cdf48b fwprop_insn /repo/gcc-trunk/gcc/fwprop.c:918 0x1cdf569 fwprop /repo/gcc-trunk/gcc/fwprop.c:970 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r11-6272-20201220001621-geb460c5986b-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r11-6272-20201220001621-geb460c5986b-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.0.0 20201220 (experimental) (GCC)
[Bug other/98400] GCC online docs "S/390 and zSeries Options" has a typo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98400 --- Comment #3 from Firas Khalil Khana --- Awesome, thanks for your time.
[Bug libstdc++/98374] No #include on windows. Bootstrapping failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98374 Jonathan Wakely changed: What|Removed |Added CC|jwakely at redhat dot com | --- Comment #4 from Jonathan Wakely --- Please stop adding random unrelated people to the CC list of your bugs.
[Bug go/98402] [11 Regression] libgo build broken on arm-linux-gnueabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98402 --- Comment #1 from Ian Lance Taylor --- Odd. What version of mpfr do you have installed?
[Bug fortran/92065] [8/9/10/11 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 Dominique d'Humieres changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #16 from Dominique d'Humieres --- If a set a breakpoint at expr.c:10270, after continuing several times I get * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.2 frame #0: 0x0001014af237 f951`expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) at expr.c:10270:7 10267 been lowered by this point. */ 10268 if (exp) 10269context = decl_function_context (exp); -> 10270 gcc_assert (!exp 10271 || SCOPE_FILE_SCOPE_P (context) 10272 || context == current_function_decl 10273 || TREE_STATIC (exp) Target 0: (f951) stopped. (lldb) p tree_node* exp (lldb) p context (lldb) c Process 43535 resuming during RTL pass: expand pr92065.f90:23:31: 23 | integer function fun2(this, a) | ^ internal compiler error: in expand_expr_real_1, at expr.c:10270 With the modified program I get * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 frame #0: 0x0001009839b7 f951`expand_expr_real_1(exp=, target=, tmode=E_DImode, modifier=EXPAND_CONST_ADDRESS, alt_rtl=0x, inner_reference_p=) at expr.c:10270:7 10267 been lowered by this point. */ 10268 if (exp) 10269context = decl_function_context (exp); -> 10270 gcc_assert (!exp 10271 || SCOPE_FILE_SCOPE_P (context) 10272 || context == current_function_decl 10273 || TREE_STATIC (exp) Target 0: (f951) stopped. (lldb) c Process 43494 resuming Time variable usr sys wall GGC phase setup: 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 186k ( 8%) phase parsing : 0.01 ( 50%) 0.00 ( 0%) 0.01 ( 0%) 1765k ( 79%) phase opt and generate : 0.01 ( 50%) 0.01 (100%) 39.53 (100%) 284k ( 13%) callgraph construction : 0.00 ( 0%) 0.00 ( 0%) 24.16 ( 61%) 12k ( 1%) parser (global): 0.01 ( 50%) 0.00 ( 0%) 0.01 ( 0%) 1765k ( 79%) expand : 0.01 ( 50%) 0.01 (100%) 15.35 ( 39%) 19k ( 1%) initialize rtl : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 12k ( 1%) verify RTL sharing : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 ( 0%) TOTAL : 0.02 0.01 39.55 2239k
[Bug c++/98383] internal compiler error: in make_decl_rtl, at varasm.c:1342
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98383 --- Comment #2 from Cebtenzzre --- I tried GCC 9.3.0 in Godbolt and there was no ICE, so I ran a git bisect. It turns out this issue is a regression caused by commit d81ab49d0586fca0f3ee2f49c4581dd02508fcca ("tree.h (OMP_CLAUSE_LASTPRIVATE_TASKLOOP_IV): Rename to ...").
[Bug c/98404] New: Compiler emits unexpected function call that may cause security problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98404 Bug ID: 98404 Summary: Compiler emits unexpected function call that may cause security problems Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: msharov at users dot sourceforge.net Target Milestone: --- int rotate_argv (const char** argv, int first, int mid, int end) { const char** p = argv+first; int n1 = mid-first; int n2 = end-mid; int nm = n1+n2-1; for (int j = 0; j < n2; ++j) { const char* v = p[nm]; for (int i = 0; i < nm; ++i) p[nm-i] = p[nm-i-1]; p[0] = v; } return n1; } This bit of code unexpectedly emits a call to memmove to replace the inner copy loop. Such behavior is highly inappropriate, breaking the "what-you-see-is-what-you-get" spirit of C. Sure, the loop is equivalent to a memmove call, but if I wanted to call memmove, I would have called memmove. Doing it behind my back brings in code paths that may cause problems impossible to understand by looking at the code. Worse yet, the compiler only does this in the optimized build (-Os, -O2, and -O3, but not -O1 or -O0), making debugging of the resulting problem a beat-your-head-on-the-desk frustrating exercise. The bug in my code was causing memory corruption in argv to happen in that inner loop, but looking at the code above will not reveal the problem, no matter how much you scream at the debugger. The bug was in my memmove implementation returning the wrong value, which the compiler then helpfully reloaded into p. Naturally, it's a good thing that I fixed the bug; having never used the return value of memmove myself I doubt I would have discovered it anytime soon. But this illustrates how a malicious exploit could be introduced into that loop without anybody being able to figure it out. Let's remember that we still have that LD_PRELOAD abomination. On a more mundane note, replacing the loop with memmove causes the compiled code to grow from 107 bytes to 166. This is using the -Os, switch, of course. I have complained many times about how gcc doesn't care about size optimization and doesn't inline stuff because it can't understand that inserting a function call into code that currently has none has great costs of register saving and all that. I have by now resigned to having to #define inline inline __attribute__((always_inline)) everywhere, but will you perhaps someday reconsider your position that size optimization does not matter? If 55% code bloat in this example doesn't convince you, what will? Finally, calling memmove will make the code slower, not faster, due to its much higher startup overhead that is justifiable for copying large blocks, but not for copying one or two elements, which is what the code above is made for. The conceit of the compiler, in thinking it knows better, thus results in worse outcome all around; in size, speed, and security.
[Bug c/98404] Compiler emits unexpected function call that may cause security problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98404 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- NOT A BUG. GCC implements non-freestanding implementation of the C langauge which means it can emit memcpy/memmove and other functions that part of the C language. If your libc has a bug in it, it is not a GCC bug as you found out. The security bug happens only if your libc has a bug.
[Bug fortran/93685] [9/10/11 Regression] ICE in gfc_constructor_append_expr, at fortran/constructor.c:135
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93685 --- Comment #4 from anlauf at gcc dot gnu.org --- A first attempt to fix the character / non-character issue seem to require a replacement of the following hunk from commit eb401400f59e4d1f28bbdc788c3234e0968081d7 Author: Andre Vehreschild Date: Wed Dec 14 12:52:09 2016 +0100 re PR fortran/78672 (Gfortran test suite failures with a sanitized compiler) diff --git a/gcc/fortran/data.c b/gcc/fortran/data.c index 139ce880534..ea19732ccc3 100644 --- a/gcc/fortran/data.c +++ b/gcc/fortran/data.c @@ -483,7 +483,10 @@ gfc_assign_data_value (gfc_expr *lvalue, gfc_expr *rvalue, mpz_t index, if (ref || last_ts->type == BT_CHARACTER) { - if (lvalue->ts.u.cl->length == NULL && !(ref && ref->u.ss.length != NULL)) + /* An initializer has to be constant. */ + if (rvalue->expr_type != EXPR_CONSTANT + || (lvalue->ts.u.cl->length == NULL + && !(ref && ref->u.ss.length != NULL))) return false; expr = create_character_initializer (init, last_ts, ref, rvalue); } by diff --git a/gcc/fortran/data.c b/gcc/fortran/data.c index 3e52a5717b5..76ddd9dab7f 100644 --- a/gcc/fortran/data.c +++ b/gcc/fortran/data.c @@ -546,12 +546,11 @@ gfc_assign_data_value (gfc_expr *lvalue, gfc_expr *rvalue, mpz_t index, return false; } - if (ref || last_ts->type == BT_CHARACTER) + if (ref || (last_ts->type == BT_CHARACTER + && rvalue->expr_type == EXPR_CONSTANT)) { /* An initializer has to be constant. */ - if (rvalue->expr_type != EXPR_CONSTANT - || (lvalue->ts.u.cl->length == NULL - && !(ref && ref->u.ss.length != NULL))) + if (lvalue->ts.u.cl->length == NULL && !(ref && ref->u.ss.length != NULL)) return false; expr = create_character_initializer (init, last_ts, ref, rvalue); } which fixes the ICE to the second testcase in comment#3. However, it changes the traceback for comment#0 to: pr93685.f90:1:9: 1 | program p | 1 internal compiler error: in gfc_conv_string_init, at fortran/trans-const.c:148 0x79a56a gfc_conv_string_init(tree_node*, gfc_expr*) ../../gcc-trunk/gcc/fortran/trans-const.c:148 0x7c735f gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool, bool) ../../gcc-trunk/gcc/fortran/trans-expr.c:7883 0x7c79e6 gfc_conv_structure(gfc_se*, gfc_expr*, int) ../../gcc-trunk/gcc/fortran/trans-expr.c:8754 0x7c7391 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool, bool) ../../gcc-trunk/gcc/fortran/trans-expr.c:7876 0x7a7f2a gfc_get_symbol_decl(gfc_symbol*) ../../gcc-trunk/gcc/fortran/trans-decl.c:1917 0x7aba8f generate_local_decl ../../gcc-trunk/gcc/fortran/trans-decl.c:5950 0x75bf12 do_traverse_symtree ../../gcc-trunk/gcc/fortran/symbol.c:4171 0x7acfcc generate_local_vars ../../gcc-trunk/gcc/fortran/trans-decl.c:6156 0x7acfcc gfc_generate_function_code(gfc_namespace*) ../../gcc-trunk/gcc/fortran/trans-decl.c:6815 0x724cc7 translate_all_program_units ../../gcc-trunk/gcc/fortran/parse.c:6351 0x724cc7 gfc_parse_file() ../../gcc-trunk/gcc/fortran/parse.c:6620 0x77187f gfc_be_parse_file ../../gcc-trunk/gcc/fortran/f95-lang.c:212
[Bug c/98404] Compiler emits unexpected function call that may cause security problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98404 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- You can always -fno-tree-loop-distribute-patterns. And as for -Os, especially in the earlier optimizations, GCC can't really know if a particular optimization will for a particular code result in larger or smaller code, it needs to use heuristics, which is tuned for improving code size in general, but can always misfire on some particular testcases. For inlining, GCC has -Os heuristics and estimation if function will grow or decrease overall size.
[Bug fortran/93685] [9/10/11 Regression] ICE in gfc_constructor_append_expr, at fortran/constructor.c:135
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93685 --- Comment #5 from anlauf at gcc dot gnu.org --- The following seems to do the latter job: diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c index bfe08be2a94..f66afab85d1 100644 --- a/gcc/fortran/trans-expr.c +++ b/gcc/fortran/trans-expr.c @@ -7877,12 +7877,14 @@ gfc_conv_initializer (gfc_expr * expr, gfc_typespec * ts, tree type, return se.expr; case BT_CHARACTER: - { - tree ctor = gfc_conv_string_init (ts->u.cl->backend_decl,expr); - TREE_STATIC (ctor) = 1; - return ctor; - } + if (expr->expr_type == EXPR_CONSTANT) + { + tree ctor = gfc_conv_string_init (ts->u.cl->backend_decl, expr); + TREE_STATIC (ctor) = 1; + return ctor; + } + /* Fallthrough. */ default: gfc_init_se (&se, NULL); gfc_conv_constant (&se, expr);
[Bug fortran/93685] [9/10/11 Regression] ICE in gfc_constructor_append_expr, at fortran/constructor.c:135
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93685 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #6 from anlauf at gcc dot gnu.org --- Patch submitted: https://gcc.gnu.org/pipermail/fortran/2020-December/055452.html
[Bug middle-end/98405] New: missing -Wmaybe-uninitialized passing a member by reference in a ctor initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98405 Bug ID: 98405 Summary: missing -Wmaybe-uninitialized passing a member by reference in a ctor initializer list Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- As discussed in https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559258.html, GCC 11 issues -Wmaybe-uninitialized when passing uninitialized variables by reference to functions that take a const pointer or const reference. However, it fails to diagnose the same problem involving members in a C++ constructor. For example, in the test case below, only the first instance triggers the warning. The other two don't. $ cat a.C && gcc -O2 -S -Wall a.C int f (const int*); struct X { int a, b; }; void g () { X x; x.a = f (&x.b); // warning (good) } struct Y { Y (); Y (int); int a, b; }; Y::Y (): a (f (&b)) { }// missing warning Y::Y (int) { f (&b); } // missing warning a.C: In function ‘void g()’: a.C:10:11: warning: ‘x’ may be used uninitialized [-Wmaybe-uninitialized] 10 | x.a = f (&x.b); // warning (good) | ~~^~ a.C:1:5: note: by argument 1 of type ‘const int*’ to ‘int f(const int*)’ declared here 1 | int f (const int*); | ^ a.C:9:5: note: ‘x’ declared here 9 | X x; | ^
[Bug middle-end/98405] missing -Wmaybe-uninitialized passing a member by reference in a ctor initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98405 Martin Sebor changed: What|Removed |Added Blocks||24639 Status|UNCONFIRMED |ASSIGNED Keywords||diagnostic Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Last reconfirmed||2020-12-20 Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- I'm testing a fix. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 [Bug 24639] [meta-bug] bug to track all Wuninitialized issues
[Bug middle-end/98406] New: missing -Wmaybe-uninitialized passing a member by reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98406 Bug ID: 98406 Summary: missing -Wmaybe-uninitialized passing a member by reference Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- In the test case below, only the first (likely) uninitialized read by f() is diagnosed. The other two are not even though all three should be. $ cat a.c && gcc -O2 -S -Wall a.c int f (const int*); struct A { int i; }; struct B { struct A a; int j; }; void g0 (void) { struct B b; f (&b.j);// warning (good) } void g1 (void) { struct B b; f (0); f (&b.j);// missing warning } void g2 (void) { struct B b; b.a.i = 0; f (&b.a.i); f (&b.j);// missing warning } a.c: In function ‘g0’: a.c:9:3: warning: ‘b’ may be used uninitialized [-Wmaybe-uninitialized] 9 | f (&b.j);// warning (good) | ^~~~ a.c:1:5: note: by argument 1 of type ‘const int *’ to ‘f’ declared here 1 | int f (const int*); | ^ a.c:8:12: note: ‘b’ declared here 8 | struct B b; |^
[Bug libstdc++/98374] No #include on windows. Bootstrapping failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98374 --- Comment #5 from cqwrteur --- (In reply to Jonathan Wakely from comment #4) > Please stop adding random unrelated people to the CC list of your bugs. bugs for libstdc++. CC you. What's wrong with it?
[Bug libfortran/98301] random_init() is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98301 --- Comment #4 from kargl at gcc dot gnu.org --- Created attachment 49816 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49816&action=edit Newest patch. This new patch implements Thomas idea of generating appropriate library calls for the different ways that gfortran handles coarrays. * gcc/fortran/trans-decl.c: . Add definitions for gfor_fndecl_caf_random_init and gfor_fndecl_cas_random_init. * gcc/fortran/trans-intrinsic.c: . For -fcoarray=lib, generate a call to _gfortran_caf_random_init(). . For -fcoarray=shared, generate a call to _gfortran_cas_random_init(). . For -fcoarray=single or without the -fcoarray option, generate a call to _gfortran_random_init(). * gcc/fortran/trans.h: . Add declares for gfor_fndecl_caf_random_init and gfor_fndecl_cas_random_init * libgfortran/intrinsics/random_init.f90: . Rework _gfortran_random_init(), but preserve the ABI.
[Bug target/98399] x86: Awful code generation for shifting vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98399 --- Comment #1 from Hongtao.liu --- I'll take a look.
[Bug target/96892] [ARM]Wrong __stack_chk_guard for comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96892 --- Comment #4 from John Dong --- diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md index 1a8e498ba4c..97c2f6a1174 100644 --- a/gcc/config/arm/arm.md +++ b/gcc/config/arm/arm.md @@ -9301,6 +9301,7 @@ (define_insn_and_split "*stack_protect_combined_test_insn" emit_move_insn (operands[3], mem); } } + emit_move_insn (operands[3], gen_rtx_MEM(SImode, operands[3])); if (TARGET_32BIT) { emit_insn (gen_arm_stack_protect_test_insn (operands[4], operands[0], @@ -9333,8 +9334,8 @@ (define_insn "arm_stack_protect_test_insn" (clobber (match_operand:SI 0 "register_operand" "=&l,&r")) (clobber (match_dup 2))] "TARGET_32BIT" - "ldr\t%0, [%2]\;ldr\t%2, %1\;eors\t%0, %2, %0\;mov\t%2, #0" - [(set_attr "length" "12,16") + "ldr\t%0, [%2]\;ldr\t%2, %1\;ldr\t%2, [%2]\;eors\t%0, %2, %0\;mov\t%2, #0" + [(set_attr "length" "16,20") (set_attr "conds" "set") (set_attr "type" "multiple") (set_attr "arch" "t,32")] diff --git a/gcc/config/arm/thumb1.md b/gcc/config/arm/thumb1.md index 56705c9f1eb..31466405fae 100644 --- a/gcc/config/arm/thumb1.md +++ b/gcc/config/arm/thumb1.md @@ -2035,8 +2035,8 @@ (define_insn "thumb1_stack_protect_test_insn" UNSPEC_SP_TEST)) (clobber (match_dup 2))] "TARGET_THUMB1" - "ldr\t%0, [%2]\;ldr\t%2, %1\;eors\t%0, %2, %0\;movs\t%2, #0" - [(set_attr "length" "10") + "ldr\t%0, [%2]\;ldr\t%2, %1\;ldr\t%2, [%2]\;eors\t%0, %2, %0\;movs\t%2, #0" + [(set_attr "length" "12") (set_attr "conds" "clob") (set_attr "type" "multiple")] ) a simple patch as suggested by Thomas
[Bug c/98407] New: [11 Regression] ICE: Aborted (in constant_byte_string; free(): invalid pointer)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98407 Bug ID: 98407 Summary: [11 Regression] ICE: Aborted (in constant_byte_string; free(): invalid pointer) Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- gcc-11.0.0-alpha20201220 snapshot (g:18e86fae2a14f78e70aae06afce6bb9853068bb1) ICEs when compiling the following testcase w/ -O1: struct gk { int mi; int vq[]; }; const struct gk un = { 0, { 0, }, }, og = { 0, { 0, }, }; int ia (void) { return __builtin_memcmp (&un, &og, sizeof og); } % MALLOC_PERTURB_=3 MALLOC_CHECK_=3 gcc-11.0.0 -O1 -c jenyen4s.c free(): invalid pointer jenyen4s.c: In function 'ia': jenyen4s.c:11:3: internal compiler error: Aborted 11 | return __builtin_memcmp (&un, &og, sizeof og); | ^~ 0xdf83df crash_signal /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201220/work/gcc-11-20201220/gcc/toplev.c:327 0xa6fe97 constant_byte_string /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201220/work/gcc-11-20201220/gcc/expr.c:11836 0xaa58ef getbyterep(tree_node*, unsigned long*) /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201220/work/gcc-11-20201220/gcc/fold-const.c:16242 0xad94a7 fold_const_call(combined_fn, tree_node*, tree_node*, tree_node*, tree_node*) /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201220/work/gcc-11-20201220/gcc/fold-const-call.c:1806 0x921958 fold_builtin_3 /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201220/work/gcc-11-20201220/gcc/builtins.c:12034 0x921958 fold_builtin_n /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201220/work/gcc-11-20201220/gcc/builtins.c:12115 0xaa3fca fold_build_call_array_loc(unsigned int, tree_node*, tree_node*, int, tree_node**) /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201220/work/gcc-11-20201220/gcc/fold-const.c:13827 0x8297e1 build_function_call_vec(unsigned int, vec, tree_node*, vec*, vec*, tree_node*) /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201220/work/gcc-11-20201220/gcc/c/c-typeck.c:3155 0x84924a c_parser_postfix_expression_after_primary /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201220/work/gcc-11-20201220/gcc/c/c-parser.c:10470 0x840599 c_parser_postfix_expression /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201220/work/gcc-11-20201220/gcc/c/c-parser.c:10143 0x844a6a c_parser_unary_expression /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201220/work/gcc-11-20201220/gcc/c/c-parser.c:8230 0x84629b c_parser_cast_expression /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201220/work/gcc-11-20201220/gcc/c/c-parser.c:8072 0x846547 c_parser_binary_expression /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201220/work/gcc-11-20201220/gcc/c/c-parser.c:7875 0x8478c8 c_parser_conditional_expression /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201220/work/gcc-11-20201220/gcc/c/c-parser.c:7598 0x847fc4 c_parser_expr_no_commas /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201220/work/gcc-11-20201220/gcc/c/c-parser.c:7513 0x848275 c_parser_expression /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201220/work/gcc-11-20201220/gcc/c/c-parser.c:10606 0x848abb c_parser_expression_conv /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201220/work/gcc-11-20201220/gcc/c/c-parser.c:10645 0x83e927 c_parser_statement_after_labels /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201220/work/gcc-11-20201220/gcc/c/c-parser.c:6160 0x8400c2 c_parser_compound_statement_nostart /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201220/work/gcc-11-20201220/gcc/c/c-parser.c:5788 0x85e435 c_parser_compound_statement /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201220/work/gcc-11-20201220/gcc/c/c-parser.c:5597 There's a memory corruption issue somewhere, so it's better reproducible w/ Valgrind, MALLOC_PERTURB_ functionality provided by glibc, or some similar means.
[Bug go/98402] [11 Regression] libgo build broken on arm-linux-gnueabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98402 --- Comment #2 from Matthias Klose --- 4.1.0, no change since July.