[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.
