[Bug target/98981] gcc-10.2 for RISC-V has extraneous register moves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98981
--- Comment #4 from Jim Wilson ---
With this testcase
extern void sub2 (void);
void
sub (int *i, int *j)
{
int k = *i + 1;
*j = k;
if (k == 0)
sub2 ();
}
Compiling without the riscv_rtx_cost patch, I get
lw a5,0(a0)
addiw a4,a5,1
sw a4,0(a1)
beq a4,zero,.L4
compiling with the riscv_rtx_cost patch, I get
lw a5,0(a0)
addiw a4,a5,1
sw a4,0(a1)
addiw a5,a5,1
beq a5,zero,.L4
The problem here is that we have RTL
(insn 9 7 10 2 (set (reg:SI 76)
(plus:SI (subreg:SI (reg:DI 78 [ *i_4(D) ]) 0)
(const_int 1 [0x1]))) "tmp.c":6:7 3 {addsi3}
(expr_list:REG_DEAD (reg:DI 78 [ *i_4(D) ])
(nil)))
(insn 10 9 11 2 (set (reg/v:DI 73 [ k ])
(sign_extend:DI (reg:SI 76))) "tmp.c":6:7 90 {extendsidi2}
(nil))
with the SImode 76 used for the sw and the DImode 73 used for the beq. With
the riscv_rtx_cost change, which makes the sign_extend add cheap, combine folds
the add into the sign-extend to get
(insn 9 7 10 2 (set (reg:SI 76)
(plus:SI (subreg:SI (reg:DI 78 [ *i_4(D) ]) 0)
(const_int 1 [0x1]))) "tmp.c":6:7 3 {addsi3}
(nil))
(insn 10 9 11 2 (set (reg/v:DI 73 [ k ])
(sign_extend:DI (plus:SI (subreg:SI (reg:DI 78 [ *i_4(D) ]) 0)
(const_int 1 [0x1] "tmp.c":6:7 5 {*addsi3_extended}
(expr_list:REG_DEAD (reg:DI 78 [ *i_4(D) ])
(nil)))
and now we have two adds which is wrong. Without the patch, combine does
nothing, then ree manages to merge the sign_extend into the add and subseg the
sw, so we end up with only the one addw and no explicit sign extend.
My take on this is that we never should have generated the SImode add in the
first place, because we don't actually have that instruction. If we would have
generated the sign-extended add at rtl generation time, and subreged the
result, then we would have gotten the right result. In theory.
So I think the riscv_rtx_cost change is useful, but only if combined with the
rtl generation change I proposed in comment 1.
[Bug c++/99072] [modules] Compiling header unit with partial preprocessing (-E -fdirectives-only) twice causes CRC mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99072 --- Comment #4 from Boris Kolpackov --- You need to use different .ii file names on the first and second header unit builds. Using your original command lines as a reference: # first build of header-unit devvm1702:45>./xg++ [...] -o 99072_a.ii 99072_a.H devvm1702:46>./xg++ [...] -c 99072_a.ii # second build of string devvm1702:45>./xg++ [...] -o 99072_a.so.ii 99072_a.H devvm1702:46>./xg++ [...] -c 99072_a.so.ii
[Bug tree-optimization/99067] Missed optimization for induction variable elimination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99067 --- Comment #3 from bin cheng --- Though not sure if the underlying root causes are the same, I think these are two different issues, at least, they are handled by different parts of code in IVOPTs. For the first one, it's a known issue in GCC and IV elimination is complicated yet quite conservative for long time, while for the second one, we indeed don't know whether "i*N+j" wraps or not. Even though we might be able to improve IVOPTs under condition of wrapping behavior.
[Bug target/99092] Using -O3 and -fprefetch-loop-arrays to compile BLAS on Apple M1 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99092 --- Comment #10 from Andrew Pinski --- >From the ARM ARM: An assembler program translating a Load/Store instruction, for example LDR, is required to encode an unambiguous offset using the unscaled 9-bit offset form, and to encode an ambiguous offset using the scaled 12-bit offset form. A programmer might force the generation of the unscaled 9-bit form by using one of the mnemonics in Table C3-17. Arm recommends that a disassembler outputs all unscaled 9-bit offset forms using one of these mnemonics, but unambiguous offsets can be output using a Load/Store single register mnemonic, for example, LDR.
[Bug target/99092] Using -O3 and -fprefetch-loop-arrays to compile BLAS on Apple M1 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99092 --- Comment #9 from Andrew Pinski --- hmmm, see https://gcc.gnu.org/legacy-ml/gcc-patches/2014-07/msg00612.html : "When it comes to emitting the pattern, always use "prfm" -- the prfum form can be generated from the prfm mnemonic when the offset implies this is necessary." >From readin the ARM ARM, it does look like the prfm mnemonic should accept the unscaled 9bit signed value. Just like how ldr vs ldur. So the bug is in LLVM assembler I think.
[Bug target/99092] Using -O3 and -fprefetch-loop-arrays to compile BLAS on Apple M1 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99092
--- Comment #8 from Iain Sandoe ---
it seems that GAS is accepting an encoding that's not specified in at least
version DDI0487Fc_armv8_arm.
that says that
C6.2.212 PRFM (immediate) takes
" Is the optional positive immediate byte offset, a multiple of 8 in the
range 0 to 32760, defaulting to 0 and encoded in the "imm12" field as
/8."
= and
C6.2.215 PRFUM
" Is the optional signed immediate byte offset, in the range -256 to 255,
defaulting to 0 and encoded in the "imm9" field."
===
so probably the bug is present for all targets, not just Darwin - it just
happens to show there. FWIW, the encoding is shown thus:
PRFM (|#), [{, #}]
So LLVM might well also reject it without the '#' (I have encountered at least
one case before where that happened).
[Bug tree-optimization/96188] -Wstringop-overflow false positive on std::vector::push_back with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96188
Martin Sebor changed:
What|Removed |Added
Keywords||alias
Component|c++ |tree-optimization
--- Comment #6 from Martin Sebor ---
The example in comment #4 is due to the same problem/limitation in the
optimizer. The IL that triggers the warning is below:
[local count: 1073741833]:
MEM[(struct _Vector_impl_data *)] ={v} {CLOBBER};
_32 = operator new (3);
_27 = _32 + 3; <<< _27
*_32.x = 0;
MEM[(struct S *)_32 + 1B].x = 0;
MEM[(struct S *)_32 + 2B].x = 0;
__cur_3 = [(void *)_32 + 3B]; <<< same as _27
if (__cur_3 != _27) <<< must be false
goto ; [82.57%]
else
goto ; [17.43%]
[local count: 797929761]:
MEM[(struct S *)_32 + 3B] = 0; <<< -Wstringop-overflow=
goto ; [100.00%]
GCC doesn't fold the equality (_32 + 3 == [(void *)_32 + 3B]).
A simplified test case for that limitation is below:
$ cat t.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout t.c
struct S { char a[3]; };
void f (struct S *p)
{
void *q0 = p + 1;
void *q1 = p->a + sizeof *p;
if (q0 != q1) // not folded but should be
__builtin_abort ();
}
;; Function f (f, funcdef_no=0, decl_uid=1945, cgraph_uid=1, symbol_order=0)
void f (struct S * p)
{
void * q1;
void * q0;
[local count: 1073741824]:
q0_2 = p_1(D) + 3;
q1_3 = [(void *)p_1(D) + 3B];
if (q0_2 != q1_3)
goto ; [0.00%]
else
goto ; [100.00%]
[count: 0]:
__builtin_abort ();
[local count: 1073741824]:
return;
}
[Bug target/99092] Using -O3 and -fprefetch-loop-arrays to compile BLAS on Apple M1 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99092 --- Comment #7 from Jeff Hammond --- @Martin % gfortran -O3 -fprefetch-loop-arrays --verbose -c ctrsm.f && echo OKAY Using built-in specs. COLLECT_GCC=gfortran Target: aarch64-apple-darwin20 Configured with: ../configure --build=aarch64-apple-darwin20 --prefix=/opt/homebrew/Cellar/gcc/10.2.0_3 --libdir=/opt/homebrew/Cellar/gcc/10.2.0_3/lib/gcc/10 --disable-nls --enable-checking=release --enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-10 --with-gmp=/opt/homebrew/opt/gmp --with-mpfr=/opt/homebrew/opt/mpfr --with-mpc=/opt/homebrew/opt/libmpc --with-isl=/opt/homebrew/opt/isl --with-system-zlib --with-pkgversion='Homebrew GCC 10.2.0_3' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues --disable-multilib --with-native-system-header-dir=/usr/include --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk SED=/usr/bin/sed Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.2.1 20201220 (Homebrew GCC 10.2.0_3) COLLECT_GCC_OPTIONS='-O3' '-fprefetch-loop-arrays' '-v' '-c' '-mmacosx-version-min=11.2.0' '-asm_macosx_version_min=11.2' '-mlittle-endian' '-mabi=lp64' /opt/homebrew/Cellar/gcc/10.2.0_3/libexec/gcc/aarch64-apple-darwin20/10.2.1/f951 ctrsm.f -ffixed-form -fPIC -quiet -dumpbase ctrsm.f -mmacosx-version-min=11.2.0 -mlittle-endian -mabi=lp64 -auxbase ctrsm -O3 -version -fprefetch-loop-arrays -fintrinsic-modules-path /opt/homebrew/Cellar/gcc/10.2.0_3/lib/gcc/10/gcc/aarch64-apple-darwin20/10.2.1/finclude -o /var/folders/8n/llwp7zmd4jx697g8sw5w46p0gn/T//ccR79V1w.s GNU Fortran (Homebrew GCC 10.2.0_3) version 10.2.1 20201220 (aarch64-apple-darwin20) compiled by GNU C version 10.2.1 20201220, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.23-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Fortran2008 (Homebrew GCC 10.2.0_3) version 10.2.1 20201220 (aarch64-apple-darwin20) compiled by GNU C version 10.2.1 20201220, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.23-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 COLLECT_GCC_OPTIONS='-O3' '-fprefetch-loop-arrays' '-v' '-c' '-mmacosx-version-min=11.2.0' '-mlittle-endian' '-mabi=lp64' as -arch arm64 -v -mmacosx-version-min=11.2 -o ctrsm.o /var/folders/8n/llwp7zmd4jx697g8sw5w46p0gn/T//ccR79V1w.s Apple clang version 12.0.0 (clang-1200.0.32.29) Target: aarch64-apple-darwin20.3.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1as -triple arm64-apple-macosx11.2.0 -filetype obj -main-file-name ccR79V1w.s -target-cpu vortex -target-feature +v8.3a -target-feature +fp-armv8 -target-feature +neon -target-feature +crc -target-feature +crypto -target-feature +fullfp16 -target-feature +ras -target-feature +lse -target-feature +rdm -target-feature +rcpc -target-feature +zcm -target-feature +zcz -target-feature +sha2 -target-feature +aes -fdebug-compilation-dir /tmp -dwarf-debug-producer "Apple clang version 12.0.0 (clang-1200.0.32.29)" -dwarf-version=4 -mrelocation-model pic -o ctrsm.o /var/folders/8n/llwp7zmd4jx697g8sw5w46p0gn/T//ccR79V1w.s /var/folders/8n/llwp7zmd4jx697g8sw5w46p0gn/T//ccR79V1w.s:362:23: error: index must be a multiple of 8 in range [0, 32760]. prfmPLDL1KEEP, [x0, -8] ^
[Bug jit/99126] Compilation ICE trying insert trap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99126 --- Comment #3 from David Malcolm --- Created attachment 50216 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50216=edit Minimal reproducer as a test case Attached is a minimal reproducer, as a test case. I don't have a fix for this yet.
[Bug target/99143] Bad section alignment on AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99143 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-02-17 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- are you complaining that the objects j and z are aligned in the object file as 8 bytes? Or that aj, az have the value of 1? Both are valid things to do. This is the code which does exactly that GCC: /* Align definitions of arrays, unions and structures so that initializations and copies can be made more efficient. This is not ABI-changing, so it only affects places where we can see the definition. Increasing the alignment tends to introduce padding, so don't do this when optimizing for size/conserving stack space. */ #define AARCH64_EXPAND_ALIGNMENT(COND, EXP, ALIGN) \ (((COND) && ((ALIGN) < BITS_PER_WORD) \ && (TREE_CODE (EXP) == ARRAY_TYPE \ || TREE_CODE (EXP) == UNION_TYPE\ || TREE_CODE (EXP) == RECORD_TYPE)) ? BITS_PER_WORD : (ALIGN))
[Bug target/99144] New: -mtune=68040 doesn't respect restrictions set by -march=68060
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99144
Bug ID: 99144
Summary: -mtune=68040 doesn't respect restrictions set by
-march=68060
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: miro.kropacek at gmail dot com
Target Milestone: ---
man gcc states:
-m68060
[...]
This option inhibits the use of 68020 and 68881/68882 instructions that have to
be emulated by software on the 68060.
-mtune=tune
Tune the code for a particular microarchitecture, within the constraints set by
-march and -mcpu.
... and yet when I compile this code with -march=68060 -mtune=68040:
extern float x(int i);
extern unsigned long long y(int h);
extern unsigned long long z;
int main() {
z = y(0)*y(1);
return 0;
}
I can see a "mulu.l %d1,%d1:%d2" generated in the final code. This shouldn't be
possible as the 64-bit mulu has to be emulated by software on the 68060.
The same can be observered in a reverse scenario when "fintrz" (emulated on
040) is generated even if I set -march=68040 -mtune=68060.
Looking into m68k.md and m68k.h the reason is obvious, there is no TARGET_68060
defined, i.e. 040 and 060 instruction sets are considered equal and only
TUNE_68040 and TUNE_68060 is taken into account.
[Bug c/99143] New: Bad section alignment on AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99143 Bug ID: 99143 Summary: Bad section alignment on AArch64 Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: nyphbl8d at gmail dot com Target Milestone: --- aarch64-rtems6-gcc -v output: Using built-in specs. COLLECT_GCC=aarch64-rtems6-gcc COLLECT_LTO_WRAPPER=/home/opticron/rtems-development/tools/libexec/gcc/aarch64-rtems6/10.2.1/lto-wrapper Target: aarch64-rtems6 Configured with: ../gnu-mirror-gcc-949e0ad/configure --prefix=/home/opticron/rtems-development/tools --bindir=/home/opticron/rtems-development/tools/bin --exec_prefix=/home/opticron/rtems-development/tools --includedir=/home/opticron/rtems-development/tools/include --libdir=/home/opticron/rtems-development/tools/lib --libexecdir=/home/opticron/rtems-development/tools/libexec --mandir=/home/opticron/rtems-development/tools/share/man --infodir=/home/opticron/rtems-development/tools/share/info --datadir=/home/opticron/rtems-development/tools/share --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=aarch64-rtems6 --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --verbose --with-newlib --disable-nls --without-included-gettext --disable-win32-registry --enable-version-specific-runtime-libs --disable-lto --enable-newlib-io-c99-formats --enable-newlib-iconv --enable-newlib-iconv-encodings=big5,cp775,cp850,cp852,cp855,cp866,euc_jp,euc_kr,euc_tw,iso_8859_1,iso_8859_10,iso_8859_11,iso_8859_13,iso_8859_14,iso_8859_15,iso_8859_2,iso_8859_3,iso_8859_4,iso_8859_5,iso_8859_6,iso_8859_7,iso_8859_8,iso_8859_9,iso_ir_111,koi8_r,koi8_ru,koi8_u,koi8_uni,ucs_2,ucs_2_internal,ucs_2be,ucs_2le,ucs_4,ucs_4_internal,ucs_4be,ucs_4le,us_ascii,utf_16,utf_16be,utf_16le,utf_8,win_1250,win_1251,win_1252,win_1253,win_1254,win_1255,win_1256,win_1257,win_1258 --enable-threads --disable-plugin --enable-libgomp --enable-languages=c,c++ Thread model: rtems Supported LTO compression algorithms: zlib gcc version 10.2.1 20200918 (RTEMS 6, RSB f5fc2bfabbd18f31901ffa6fc0e5b6b47874797c-modified, Newlib 749cbcc) (GCC) Source file test-align.c: char i; char j[1]; char z[0]; unsigned long ai = _Alignof(i); unsigned long aj = _Alignof(j); unsigned long az = _Alignof(z); Command line: aarch64-rtems6-gcc -O2 -S -o - test-align.c -mabi=ilp32 -fdata-sections Compiler output: .arch armv8-a .file "test-align.c" .text .global az .global aj .global ai .global z .global j .global i .section.bss.i,"aw",@nobits .type i, %object .size i, 1 i: .zero 1 .section.bss.j,"aw",@nobits .align 3 .type j, %object .size j, 1 j: .zero 1 .section.bss.z,"aw",@nobits .align 3 .type z, %object .size z, 0 z: .section.data.ai,"aw" .align 2 .type ai, %object .size ai, 4 ai: .word 1 .section.data.aj,"aw" .align 2 .type aj, %object .size aj, 4 aj: .word 1 .section.data.az,"aw" .align 2 .type az, %object .size az, 4 az: .word 1 .ident "GCC: (GNU) 10.2.1 20200918 (RTEMS 6, RSB f5fc2bfabbd18f31901ffa6fc0e5b6b47874797c-modified, Newlib 749cbcc)" test-align.i from --save-temps: # 1 "test-align.c" # 1 "" # 1 "" # 1 "test-align.c" char i; char j[1]; char z[0]; unsigned long ai = _Alignof(i); unsigned long aj = _Alignof(j); unsigned long az = _Alignof(z); Description: When generating data sections for i, j, z for AArch64/ILP32 (also applies to LP64), GCC does not align data sections to anything less than 8 bytes, even when _Alignof() claims that the alignment of all three data elements should be 1 byte.
[Bug tree-optimization/99142] [11 Regression] __builtin_clz match.pd transformation too greedy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99142 Hans-Peter Nilsson changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |hp at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-02-17
[Bug tree-optimization/99142] New: [11 Regression] __builtin_clz match.pd transformation too greedy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99142 Bug ID: 99142 Summary: [11 Regression] __builtin_clz match.pd transformation too greedy Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hp at gcc dot gnu.org Target Milestone: --- Created attachment 50215 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50215=edit test-case gcc.dg/tree-ssa/prX.c See the attachment test-case, which is de-macroized from gcc.target/cris/pr93372-31.c, which started regressing with d2eb616a0f7b "match.pd: Add clz(X) == 0 -> (int)X < 0 etc. simpifications [PR94802]" In the test-case, the result *is* used more than once (twice more besides the transformed compare) and the match.pd matching expression *does* have the s modifier: (op (clz:s @0) INTEGER_CST@1), but since the transformation doesn't result in "an expression with more than one operator" (cf. doc/match-and-simplify.texi), it's still performed. The result is that the *input* is kept alive *after* the clz instruction. This generally causes additional register pressure and throws away any re-use of incidentally computed condition codes. Though the original observation was for cris-elf, where the effect is more dramatic, the effect is visible even for x86_64 and of the same kind: losing the re-use of non-zero condition codes from the bsrl instruction, i.e. the transformation causes an additional instruction: --- prX.s.64good2021-02-17 02:26:57.646183108 +0100 +++ prX.s.64bad 2021-02-17 02:27:33.124979464 +0100 @@ -9,7 +9,8 @@ f: bsrl%edi, %eax xorl$31, %eax movl%eax, (%rsi) - je .L1 + testl %edi, %edi + js .L1 movl%eax, (%rdx) .L1: ret To wit, my conclusion is that the matching condition should better be gated by single_use(clz result) *everywhere*. Alternatively, the "s" modifier adjusted somehow, but I'm not sure besides obviously just making it *exactly* single_use, and that suggestion has been shot down before. Maybe there should be an additional *reverse* version of the "simplification", replacing "y = clz(x); if (x < 0) ...stuff using y but not x" -> "y = clz(x); if (y != 0) ...stuff using y but not x"!
[Bug analyzer/94596] possible false positive when analyze OVS macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94596 David Malcolm changed: What|Removed |Added Resolution|--- |WORKSFORME Status|ASSIGNED|RESOLVED --- Comment #5 from David Malcolm --- Regression test coverage added by above commit; closing out as "WORKSFORME".
[Bug c++/96188] -Wstringop-overflow false positive on std::vector::push_back with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96188 --- Comment #5 from Egor Suvorov --- Created attachment 50214 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50214=edit Preprocessor output for Egor Suvorov's example
[Bug c++/96188] -Wstringop-overflow false positive on std::vector::push_back with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96188
Egor Suvorov changed:
What|Removed |Added
CC||egor_suvorov at mail dot ru
--- Comment #4 from Egor Suvorov ---
A possibly related example (also available at Godbolt:
https://godbolt.org/z/P65dx1 )
At my Windows machine the following code
#include
int main() {
struct S { // Defining the structure inside main is important.
bool x = false; // Initialization is important.
};
std::vector v(3); // Can also be 2, 3, and 4, but not 0, 1, 5, or 6.
v.emplace_back(S());
}
yields following when compiled with g++ -O2 -Wextra:
In member function 'void std::vector<_Tp, _Alloc>::emplace_back(_Args&& ...)
[with _Args = {main()::S}; _Tp = main()::S; _Alloc =
std::allocator]',
inlined from 'int main()' at a.cpp:7:19:
cc1plus.exe: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
In file included from
C:/Software/msys64/mingw64/include/c++/10.2.0/x86_64-w64-mingw32/bits/c++allocator.h:33,
from
C:/Software/msys64/mingw64/include/c++/10.2.0/bits/allocator.h:46,
from C:/Software/msys64/mingw64/include/c++/10.2.0/vector:64,
from a.cpp:1:
C:/Software/msys64/mingw64/include/c++/10.2.0/ext/new_allocator.h: In function
'int main()':
C:/Software/msys64/mingw64/include/c++/10.2.0/ext/new_allocator.h:115:41: note:
at offset 3 to an object with size 0 allocated by 'operator new' here
115 | return static_cast<_Tp*>(::operator new(__n * sizeof(_Tp)));
| ~~^~~
My g++ version is
g++ (Rev6, Built by MSYS2 project) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug analyzer/94596] possible false positive when analyze OVS macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94596 --- Comment #4 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:963aecff2473080d748b2fc1ea2e32cef36cab11 commit r11-7272-g963aecff2473080d748b2fc1ea2e32cef36cab11 Author: David Malcolm Date: Wed Feb 17 17:50:52 2021 -0500 testsuite: add regression test for PR analyzer/94596 This use-after-free false positive affected GCC 10, but seems to be fixed in trunk for GCC 11; adding a reduced version as a regression test. gcc/testsuite/ChangeLog: PR analyzer/94596 * gcc.dg/analyzer/pr94596.c: New test.
[Bug fortran/69090] Allocatable arrays mishandled in 'omp declare target'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69090 John Donners changed: What|Removed |Added CC||john.donners at atos dot net --- Comment #7 from John Donners --- I have a similar issue, but the allocatable array is defined in a module. The array is used in a subroutine that is also DECLARE TARGET. Because the routine is DECLARE TARGET, the allocatable array must be DECLARE TARGET as well. The case works fine with target intelmicemul, but it does not work on the target nvptx-none (cuCtxSynchronize error). Test case: module b !$omp declare target (a) real, allocatable,dimension(:) :: a end module b module c use b contains subroutine d !$omp declare target a=7 end subroutine end module program arr_a use b use c implicit none allocate(a(2)) a=5 !$omp target map(tofrom:a) call d !$omp end target print*,a end
[Bug c/99127] ICE in expand_expr_addr_expr_1, at expr.c:8026 (during RTL pass: expand) at -O1 or higher on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99127
--- Comment #6 from Kurt Miller ---
For clarity, I see now there are two reduced test cases. My test patch fixed
the initial reduced test case but not the second one.
apoc$ cat pr99127.i
int c_pow_r_1, c_pow_r_0, c_pow_phase;
void
c_pow() {
c_pow_r_0 = __builtin_cos(c_pow_phase);
c_pow_r_1 = __builtin_sin(c_pow_phase);
}
apoc$ egcc -c -O1 -o pr99127.o pr99127.i
apoc$
apoc$ cat pr99127a.i
int c_pow_r_1, c_pow_r_0, c_pow_phase;
void
c_pow() {
_Complex double r = __builtin_cexpi(c_pow_phase);
c_pow_r_0 = __real__ r;
c_pow_r_1 = __imag__ r;
}
apoc$ egcc -c -O1 -o pr99127a.o pr99127a.i
during RTL pass: expand
pr99127a.i: In function 'c_pow':
pr99127a.i:5:23: internal compiler error: in expand_expr_addr_expr_1, at
expr.c:8026
_Complex double r = __builtin_cexpi(c_pow_phase);
^~~~
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug analyzer/94596] possible false positive when analyze OVS macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94596 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-02-17 Ever confirmed|0 |1 --- Comment #3 from David Malcolm --- I'm able to reproduce this with gcc 10.2 and have reduced it to < 100 lines. I'm not able to reproduce it with trunk, so I plan to add the reproducer as a regression test. Marking as ASSIGNED to cover that.
[Bug c/99127] ICE in expand_expr_addr_expr_1, at expr.c:8026 (during RTL pass: expand) at -O1 or higher on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99127
--- Comment #5 from Kurt Miller ---
(In reply to Jakub Jelinek from comment #4)
> So, do you get the ICE with
> int c_pow_r_1, c_pow_r_0, c_pow_phase;
>
> void
> c_pow() {
> _Complex double r = __builtin_cexpi(c_pow_phase);
> c_pow_r_0 = __real__ r;
> c_pow_r_1 = __imag__ r;
> }
> too?
I made the following change to the 8.4.0 port:
Index: gcc/tree-ssa-math-opts.c
--- gcc/tree-ssa-math-opts.c.orig
+++ gcc/tree-ssa-math-opts.c
@@ -1922,7 +1922,11 @@ class pass_cse_sincos : public gimple_opt_pass (public
{
/* We no longer require either sincos or cexp, since powi expansion
piggybacks on this pass. */
+#if defined(__hppa__)
+ return false;
+#else
return optimize;
+#endif
}
virtual unsigned int execute (function *);
I know this is not correct for cross compiling but I'm building native on hppa.
That change fixed the python builds but does not fix the reduced test case
above.
apoc$ egcc -c -O1 -o hppatest.o hppatest.c
apoc$
apoc$ egcc -c -O1 -o pr99127.o pr99127.i
during RTL pass: expand
pr99127.i: In function 'c_pow':
pr99127.i:5:23: internal compiler error: in expand_expr_addr_expr_1, at
expr.c:8026
_Complex double r = __builtin_cexpi(c_pow_phase);
^~~~
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug analyzer/93773] Analyzer probably fails to recognize end of C macros in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93773
--- Comment #5 from David Malcolm ---
Specifically:
+--> ‘make_assignable’: events 5-6
|
| 5352 | make_assignable(INSTRUCTION *ip)
| | ^~~
| | |
| | (5) entry to ‘make_assignable’
| 5353 | {
| 5354 | switch (ip->opcode) {
| | ~~
| | |
| | (6) following ‘default:’ branch...
|
‘make_assignable’: event 7
|
|cc1:
| (7): ...to here
|
<--+
|
‘mk_getline’: events 8-9
|
| 6025 | tp = make_assignable(var->lasti);
| | ^~~
| | |
| | (8) return of NULL to ‘mk_getline’ from
‘make_assignable’
|..
| 6029 | if (tp->opcode == Op_push_lhs
| | ~~
| | |
| | (9) dereference of NULL ‘tp’
(albeit where event 7 doesn't have a source location, but is a "return NULL")
[Bug analyzer/93773] Analyzer probably fails to recognize end of C macros in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93773 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #4 from David Malcolm --- A year later, I had another ago at reproducing this, but am still failing; I see reasonable output on a single -Wanalyzer-null-dereference warning with trunk (for gcc 11). I'm going to close this out as "WORKSFORME". Thanks for filing this; feel free to reopen if you can come up with a reproducer.
[Bug c/99127] ICE in expand_expr_addr_expr_1, at expr.c:8026 (during RTL pass: expand) at -O1 or higher on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99127
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
So, do you get the ICE with
int c_pow_r_1, c_pow_r_0, c_pow_phase;
void
c_pow() {
_Complex double r = __builtin_cexpi(c_pow_phase);
c_pow_r_0 = __real__ r;
c_pow_r_1 = __imag__ r;
}
too?
[Bug c/99127] ICE in expand_expr_addr_expr_1, at expr.c:8026 (during RTL pass: expand) at -O1 or higher on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99127 --- Comment #3 from Kurt Miller --- Changing the gate function to return false does work-around the python ICEs.
[Bug fortran/99139] ICE: gfc_get_default_type(): Bad symbol '__tmp_UNKNOWN_0_rank_1'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99139
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
Last reconfirmed||2021-02-17
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Priority|P3 |P4
--- Comment #2 from kargl at gcc dot gnu.org ---
Fixes problem with original code. Not regression tested.
diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
index 2df6191d7e6..eb51b9905da 100644
--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -6634,6 +6639,18 @@ gfc_match_select_rank (void)
gfc_current_ns = gfc_build_block_ns (ns);
m = gfc_match (" %n => %e", name, );
+
+ /* If expr2 corresponds to an implicitly typed variable, then the actual
+ type of the variable may not have been resolved. Set it here. */
+ if (!gfc_current_ns->seen_implicit_none
+ && expr2->expr_type == EXPR_VARIABLE
+ && expr2->ts.type == BT_UNKNOWN
+ && expr2->symtree && expr2->symtree->n.sym)
+{
+ gfc_set_default_type (expr2->symtree->n.sym, 0, gfc_current_ns);
+ expr2->ts.type = expr2->symtree->n.sym->ts.type;
+}
+
if (m == MATCH_YES)
{
expr1 = gfc_get_expr ();
[Bug c++/98741] [modules] ICE/SIGSEGV reading compiled module cluster
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98741
Nathan Sidwell changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2021-02-17
--- Comment #1 from Nathan Sidwell ---
// pr98741_a.H
namespace foo
{
}
// pr98741_b.H
namespace foo
{
}
// pr98741_b.C
export module Foo;
import "pr98741_a.H";
// pr98741_d.C
module Foo;
import "pr98741_b.H";
(added an assert earlier)
zathras:178>./cc1plus -fmodules-ts -quiet -fmodule-header pr98741_a.H
zathras:179>./cc1plus -fmodules-ts -quiet -fmodule-header pr98741_b.H
zathras:180>./cc1plus -fmodules-ts -quiet pr98741_c.C
zathras:181>./cc1plus -fmodules-ts -quiet pr98741_d.C
pr98741_d.C:2:22: internal compiler error: in append_imported_binding_slot, at
cp/name-lookup.c:371
2 | import "pr98741_b.H";
| ^
0xd2fe45 append_imported_binding_slot
../../../src/gcc/cp/name-lookup.c:371
0xd5010c add_imported_namespace(tree_node*, tree_node*, unsigned int, unsigned
int, bool, bool)
../../../src/gcc/cp/name-lookup.c:9024
[Bug analyzer/94362] False analyzer report due to i >= 0 and i < 0 on openssl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94362 --- Comment #2 from David Malcolm --- Oops; I was wrong; this isn't yet fixed on trunk. I can reproduce this with the attachment. It also reports warnings from -Wanalyzer-too-complex.
[Bug analyzer/94362] False analyzer report due to i >= 0 and i < 0 on openssl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94362 David Malcolm changed: What|Removed |Added Last reconfirmed||2021-02-17 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from David Malcolm --- Looks like this no longer affects trunk. I can reproduce the false positive with -fno-analyzer-feasibility, but by default, the diagnostic is (correctly) rejected as infeasible. Moving to ASSIGNED to cover adding a regression test for this.
[Bug c++/99141] New: Name of deduced type unchecked in deduction guide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99141 Bug ID: 99141 Summary: Name of deduced type unchecked in deduction guide Product: gcc Version: 11.0 URL: https://godbolt.org/z/bEhjsc Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: johelegp at gmail dot com CC: johelegp at gmail dot com Target Milestone: --- Context (https://timsong-cpp.github.io/cppwp/n4861/temp.deduct.guide#nt:deduction-guide): > deduction-guide: > explicit-specifieropt template-name ( parameter-declaration-clause ) -> > simple-template-id ; The requirement (https://timsong-cpp.github.io/cppwp/n4861/temp.deduct.guide#3.sentence-3): > The template-name shall be the same identifier as the template-name of the > simple-template-id. See https://godbolt.org/z/bEhjsc. ```C++ templatestruct A; templateusing B=A; A(int)->B; ```
[Bug libstdc++/97362] [8/9/10 Regression] `__deref` in in debug mode clashes with internal macro in Windows system header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97362 Jonathan Wakely changed: What|Removed |Added Status|WAITING |ASSIGNED --- Comment #9 from Jonathan Wakely --- Ah, it's a recent change. I think my mingw headers are too old. I guess I'd better backport this then.
[Bug c++/99072] [modules] Compiling header unit with partial preprocessing (-E -fdirectives-only) twice causes CRC mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99072 --- Comment #3 from Nathan Sidwell --- Cannot reproduce: devvm1702:150>./xg++ -B./ -nostdinc++ -I../x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I../x86_64-pc-linux-gnu/libstdc++-v3/include -I../../..//src/libstdc++-v3/libsupc++ -I../../../src/libstdc++-v3/include/backward -I../../../src/libstdc++-v3/testsuite/util -std=c++2a -fmodule-header -E -fdirectives-only -o 99072_a.so.ii 99072_a.H devvm1702:151>./xg++ -B./ -nostdinc++ -I../x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I../x86_64-pc-linux-gnu/libstdc++-v3/include -I../../..//src/libstdc++-v3/libsupc++ -I../../../src/libstdc++-v3/include/backward -I../../../src/libstdc++-v3/testsuite/util -std=c++2a -fmodule-header -fpreprocessed -fdirectives-only -c 99072_a.so.ii devvm1702:152>./xg++ -B./ -nostdinc++ -I../x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I../x86_64-pc-linux-gnu/libstdc++-v3/include -I../../..//src/libstdc++-v3/libsupc++ -I../../../src/libstdc++-v3/include/backward -I../../../src/libstdc++-v3/testsuite/util -std=c++2a -fmodules-ts -c 99072_b.C devvm1702:153>./xg++ -B./ -nostdinc++ -I../x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I../x86_64-pc-linux-gnu/libstdc++-v3/include -I../../..//src/libstdc++-v3/libsupc++ -I../../../src/libstdc++-v3/include/backward -I../../../src/libstdc++-v3/testsuite/util -std=c++2a -fmodule-header -fpreprocessed -fdirectives-only -c 99072_a.so.ii devvm1702:154>./xg++ -B./ -nostdinc++ -I../x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I../x86_64-pc-linux-gnu/libstdc++-v3/include -I../../..//src/libstdc++-v3/libsupc++ -I../../../src/libstdc++-v3/include/backward -I../../../src/libstdc++-v3/testsuite/util -std=c++2a -fmodules-ts -c 99072_c.C
[Bug c++/99071] [modules] ICE with initializer_list & iostream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99071 Nathan Sidwell changed: What|Removed |Added Status|SUSPENDED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Nathan Sidwell --- yup, same secondary issue d8889c99aab 2021-02-17 | c++: Macros need to be GTY-reachable [PR 99023]
[Bug c++/99023] [modules] ICE/SIGSEGV in module_state::write_define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99023 Nathan Sidwell changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Nathan Sidwell --- d8889c99aab 2021-02-17 | c++: Macros need to be GTY-reachable [PR 99023]
[Bug middle-end/99140] New: missing -Warray-bounds on a negative index into a multidimensional VLA cast to one-dimensional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99140
Bug ID: 99140
Summary: missing -Warray-bounds on a negative index into a
multidimensional VLA cast to one-dimensional
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: ---
The negative subscript in the three functions below is diagnosed only when
accessing an ordinary array but not when accessing a VLA.
$ cat t.c && gcc -O2 -S -Wall t.c
void f (void*);
void f_4_8 (int n)
{
int a[4][8];
((int*)a)[-1] = 0; // -Warray-bounds
f (a);
}
void f_4_n (int n)
{
int a[4][n];
((int*)a)[-1] = 0; // missing warning
f (a);
}
void f_n_8 (int n)
{
int a[n][8];
((int*)a)[-1] = 0; // missing warning
f (a);
}
t.c: In function ‘f_4_8’:
t.c:6:12: warning: array subscript -1 is outside array bounds of ‘int[4][8]’
[-Warray-bounds]
6 | ((int*)a)[-1] = 0; // -Warray-bounds
| ~^~~~
t.c:5:7: note: while referencing ‘a’
5 | int a[4][8];
| ^
[Bug c++/99023] [modules] ICE/SIGSEGV in module_state::write_define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99023 --- Comment #1 from CVS Commits --- The master branch has been updated by Nathan Sidwell : https://gcc.gnu.org/g:d8889c99aab4b599aa7ceb7079e69a9766171336 commit r11-7271-gd8889c99aab4b599aa7ceb7079e69a9766171336 Author: Nathan Sidwell Date: Wed Feb 17 10:43:21 2021 -0800 c++: Macros need to be GTY-reachable [PR 99023] I'd missed that macros were allocated from GC storage, and that they can become unattached from an identifier, and therefore not GC-reachable. And then bad things happen. Fixed by making the module machinery's reference vector a GC root. PR c++/99023 gcc/cp/ * module.cc (struct macro_export): Add GTY markers. (macro_exports): Likewise, us a va_gc Vector. gcc/testsuite/ * g++.dg/modules/pr99023_a.H: New. * g++.dg/modules/pr99023_b.H: New.
[Bug c/99136] ICE in gimplify_expr, at gimplify.c:14854
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99136 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-02-17 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 50213 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50213=edit gcc11-pr99136.patch Untested fix.
[Bug c/99136] ICE in gimplify_expr, at gimplify.c:14854
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99136 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- ICEs since -std=c11, resp. -std=c1x, resp. -fexcess-precision=standard (the last one r0-92195-g8ce94e44465bcc958dc11270d9dee1775c7a4f43 ) options have been introduced when using those options.
[Bug fortran/99139] ICE: gfc_get_default_type(): Bad symbol '__tmp_UNKNOWN_0_rank_1'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99139 G. Steinmetz changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #1 from G. Steinmetz --- This variant compiles ... $ cat z0.f90 subroutine s(x) real, target :: x(..) select rank (y => x) rank (1) rank (2) end select end $ gfortran-11-20210214 -c z0.f90 $ ... with one exception : $ gfortran-11-20210214 -c z0.f90 -finit-local-zero # or -finit-real=snan z0.f90:3:22: 3 |select rank (y => x) | 1 Error: Assumed-rank variable y at (1) may only be used as actual argument
[Bug fortran/99139] New: ICE: gfc_get_default_type(): Bad symbol '__tmp_UNKNOWN_0_rank_1'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99139 Bug ID: 99139 Summary: ICE: gfc_get_default_type(): Bad symbol '__tmp_UNKNOWN_0_rank_1' Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started between 20190825 and 20190901 : $ cat z1.f90 subroutine s(x) target :: x(..) select rank (y => x) rank (1) rank (2) end select end $ gfortran-11-20210214 -c z1.f90 f951: internal compiler error: gfc_get_default_type(): Bad symbol '__tmp_UNKNOWN_0_rank_1' 0x687519 gfc_report_diagnostic ../../gcc/fortran/error.c:782 0x688c3a gfc_internal_error(char const*, ...) ../../gcc/fortran/error.c:1402 0x7206dc gfc_get_default_type(char const*, gfc_namespace*) ../../gcc/fortran/symbol.c:239 0x724408 gfc_set_default_type(gfc_symbol*, int, gfc_namespace*) ../../gcc/fortran/symbol.c:298 0x6ff33c resolve_symbol ../../gcc/fortran/resolve.c:15380 0x71e2c2 do_traverse_symtree ../../gcc/fortran/symbol.c:4170 0x702bb4 resolve_types ../../gcc/fortran/resolve.c:17296 0x6fe22c gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:17411 0x6fd667 gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:11720 0x6fd667 resolve_select_rank ../../gcc/fortran/resolve.c:9717 0x6fd667 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:12055 0x6fe177 resolve_codes ../../gcc/fortran/resolve.c:17378 0x6fe23e gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:17413 0x6e6784 resolve_all_program_units ../../gcc/fortran/parse.c:6290 0x6e6784 gfc_parse_file() ../../gcc/fortran/parse.c:6542 0x7330ff gfc_be_parse_file ../../gcc/fortran/f95-lang.c:212
[Bug c/99137] ICE in gimplify_scan_omp_clauses, at gimplify.c:9833
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99137 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2021-02-17 CC||burnus at gcc dot gnu.org, ||jakub at gcc dot gnu.org, ||tschwinge at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Not a regression, ICEs since r5-6458-g41dbbb3789850dfea98dd8984f69806284f87b6e when -fopenacc support has been introduced.
[Bug fortran/99138] New: ICE in gfc_match_rvalue, at fortran/primary.c:3738
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99138 Bug ID: 99138 Summary: ICE in gfc_match_rvalue, at fortran/primary.c:3738 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- This invalid code affects versions down to r6 : (print statement in contains section) $ cat z1.f90 module m interface module function f(x) integer, intent(in) :: x class(*), allocatable :: f end end interface end submodule(m) m2 contains module function f(x) integer, intent(in) :: x class(*), allocatable :: f end print *, f(3) end $ gfortran-11-20210214 -c z1.f90 f951: internal compiler error: Segmentation fault 0xc09bcf crash_signal ../../gcc/toplev.c:327 0x6ec98e gfc_match_rvalue(gfc_expr**) ../../gcc/fortran/primary.c:3738 0x6c0eae match_primary ../../gcc/fortran/matchexp.c:157 0x6c0eae match_level_1 ../../gcc/fortran/matchexp.c:211 0x6c0eae match_mult_operand ../../gcc/fortran/matchexp.c:267 0x6c10f8 match_add_operand ../../gcc/fortran/matchexp.c:356 0x6c134c match_level_2 ../../gcc/fortran/matchexp.c:480 0x6c14a2 match_level_3 ../../gcc/fortran/matchexp.c:551 0x6c1594 match_level_4 ../../gcc/fortran/matchexp.c:599 0x6c1594 match_and_operand ../../gcc/fortran/matchexp.c:693 0x6c1782 match_or_operand ../../gcc/fortran/matchexp.c:722 0x6c1852 match_equiv_operand ../../gcc/fortran/matchexp.c:765 0x6c1924 match_level_5 ../../gcc/fortran/matchexp.c:811 0x6c0d01 gfc_match_expr(gfc_expr**) ../../gcc/fortran/matchexp.c:870 0x6a8c99 match_io_element ../../gcc/fortran/io.c:3661 0x6ab575 match_io_list ../../gcc/fortran/io.c:3709 0x6ab974 match_io ../../gcc/fortran/io.c:4387 0x6af3fa gfc_match_print() ../../gcc/fortran/io.c:4443 0x6dbc21 match_word ../../gcc/fortran/parse.c:65 0x6e07a3 decode_statement ../../gcc/fortran/parse.c:537
[Bug c/99137] New: ICE in gimplify_scan_omp_clauses, at gimplify.c:9833
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99137
Bug ID: 99137
Summary: ICE in gimplify_scan_omp_clauses, at gimplify.c:9833
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Affects versions down to at least r5 :
$ cat z1.c
void f ()
{
#pragma acc parallel async(1,2)
;
}
$ gcc-11-20210214 -c z1.c -fopenacc
z1.c: In function 'f':
z1.c:3:31: internal compiler error: in gimplify_expr, at gimplify.c:14854
3 | #pragma acc parallel async(1,2)
| ^
0x8fe7b1 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:14854
0x8f5ecf gimplify_scan_omp_clauses
../../gcc/gimplify.c:9833
0x8fa488 gimplify_omp_workshare
../../gcc/gimplify.c:13248
0x8fb1ba gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:14599
0x8fe8d8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6876
0x8fee31 gimplify_bind_expr
../../gcc/gimplify.c:1421
0x8fc9d2 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:14271
0x8fe8d8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6876
0x8ff8fd gimplify_body(tree_node*, bool)
../../gcc/gimplify.c:15306
0x8ffd5f gimplify_function_tree(tree_node*)
../../gcc/gimplify.c:15460
0x79cb67 cgraph_node::analyze()
../../gcc/cgraphunit.c:670
0x79f4a7 analyze_functions
../../gcc/cgraphunit.c:1233
0x79fdfd symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2511
[Bug c/99136] New: ICE in gimplify_expr, at gimplify.c:14854
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99136
Bug ID: 99136
Summary: ICE in gimplify_expr, at gimplify.c:14854
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Affects versions down to at least r5,
ICEs with -m16 and -m32, but not with -m64 :
$ cat z1.c
void f (double x)
{
return 1.0/x;
}
$ gcc-11-20210214 -c z1.c -m32 -std=c11
z1.c: In function 'f':
z1.c:3:13: warning: 'return' with a value, in function returning void
3 | return 1.0/x;
| ~~~^~
z1.c:1:6: note: declared here
1 | void f (double x)
| ^
z1.c:3:13: internal compiler error: in gimplify_expr, at gimplify.c:14854
3 | return 1.0/x;
| ~~~^~
0x8fe7b1 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:14854
0x8fe8d8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6876
0x8fc1ad gimplify_and_add(tree_node*, gimple**)
../../gcc/gimplify.c:489
0x8fc1ad gimplify_return_expr
../../gcc/gimplify.c:1671
0x8fc1ad gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:14331
0x8fe8d8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6876
0x8fee31 gimplify_bind_expr
../../gcc/gimplify.c:1421
0x8fc9d2 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:14271
0x8fe8d8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6876
0x8ff8fd gimplify_body(tree_node*, bool)
../../gcc/gimplify.c:15306
0x8ffd5f gimplify_function_tree(tree_node*)
../../gcc/gimplify.c:15460
0x79cb67 cgraph_node::analyze()
../../gcc/cgraphunit.c:670
0x79f4a7 analyze_functions
../../gcc/cgraphunit.c:1233
0x79fdfd symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2511
[Bug ipa/99122] [10/11 Regression] ICE in force_constant_size, at gimplify.c:733
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122 --- Comment #7 from Jakub Jelinek --- (In reply to Martin Jambor from comment #6) > > For punting on inlining these, I couldn't find any spot that would try to > > verify at least remote compatibility of the passed in arguments and the > > arguments the callee expects. > > No, with LTO it would be too late even if we tried to, (IPA) inlining > decisions are not meant to be un-doable. The idea was that mismatches > are undefined and so we should try our best to emulate non-inlining > and not ICE. But apparently we don't manage that now. Well, I meant decide not to inline because either any of the gimple_call_arg (stmt, ?) is a variable length or any of the expected arguments of the function are variable length during the IPA inlining decisions.
[Bug ipa/99122] [10/11 Regression] ICE in force_constant_size, at gimplify.c:733
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122 --- Comment #6 from Martin Jambor --- (In reply to Jakub Jelinek from comment #5) > That could perhaps work for the #c0 testcase where the function actually has > a non-VL parameter and so garbage in garbage out. > But would that work also for #c2? No, at least not on its own. It leaks struct S, which is local to bar, to the IL of foo, which hits an assert in make_decl_rtl. Einline dump has: struct T b; ... x.1_28 = __builtin_alloca_with_align (_26, 8); _20 = (long unsigned int) n_14(D); _21 = _28->a; __builtin_memset (_21, 0, _20); b = MEM [(struct S *)x.1_28]; > If one dumps the #c2 testcase with -O2 -fno-inline -fdump-tree-optimized, > the PARM_DECL is clearly variable length but not lowered to *ptr, while > in the caller it is lowered that way and allocated through > __builtin_alloca_with_align. > So, clearly PARM_DECLs can be variable length but VAR_DECLs should not be > (they should be gimplified into ptr = __builtin_alloca_with_align with stack > save/restore around the scope and DECL_VALUE_EXPR of *ptr. > The inliner certainly doesn't do that right now. > > For punting on inlining these, I couldn't find any spot that would try to > verify at least remote compatibility of the passed in arguments and the > arguments the callee expects. No, with LTO it would be too late even if we tried to, (IPA) inlining decisions are not meant to be un-doable. The idea was that mismatches are undefined and so we should try our best to emulate non-inlining and not ICE. But apparently we don't manage that now.
[Bug ipa/99122] [10/11 Regression] ICE in force_constant_size, at gimplify.c:733
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122 --- Comment #5 from Jakub Jelinek --- That could perhaps work for the #c0 testcase where the function actually has a non-VL parameter and so garbage in garbage out. But would that work also for #c2? If one dumps the #c2 testcase with -O2 -fno-inline -fdump-tree-optimized, the PARM_DECL is clearly variable length but not lowered to *ptr, while in the caller it is lowered that way and allocated through __builtin_alloca_with_align. So, clearly PARM_DECLs can be variable length but VAR_DECLs should not be (they should be gimplified into ptr = __builtin_alloca_with_align with stack save/restore around the scope and DECL_VALUE_EXPR of *ptr. The inliner certainly doesn't do that right now. For punting on inlining these, I couldn't find any spot that would try to verify at least remote compatibility of the passed in arguments and the arguments the callee expects.
[Bug libstdc++/97362] [8/9/10 Regression] `__deref` in in debug mode clashes with internal macro in Windows system header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97362 --- Comment #8 from frankhb1989 at gmail dot com --- The first diagnostic message of `#pragma GCC poison __deref` points to in my MSYS2 installation. The change is made here: https://sourceforge.net/p/mingw-w64/mingw-w64/ci/555bee806560144c6a59077f3c860bc83411153c/.
[Bug ipa/99122] [10/11 Regression] ICE in force_constant_size, at gimplify.c:733
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122 --- Comment #4 from Martin Jambor --- With the patch from comment #3, the following sequence with the problematic call: x.1_26 = __builtin_alloca_with_align (_24, 8); g (WITH_SIZE_EXPR <*x.1_26, _22>, WITH_SIZE_EXPR <*x.1_26, _22>); __builtin_stack_restore (saved_stack.2_15); is turned by einline into: x.1_26 = __builtin_alloca_with_align (_24, 8); x_27 = MEM [(struct *)x.1_26]; y_29 = MEM [(struct *)x.1_26]; _30 = x_27 u<= y_29; _31 = ~_30; _32 = (int) _31; __builtin_stack_restore (saved_stack.2_15); Which looks OKish, under the circumstances, to me. Let me look at the second testcase now.
[Bug ipa/99122] [10/11 Regression] ICE in force_constant_size, at gimplify.c:733
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122 --- Comment #3 from Martin Jambor --- Looking at how expr.c deals with WITH_SIZE_EXPR, perhaps we should do something like the following: diff --git a/gcc/tree-inline.c b/gcc/tree-inline.c index a710fa59027..cdabeb6bafd 100644 --- a/gcc/tree-inline.c +++ b/gcc/tree-inline.c @@ -3418,6 +3418,9 @@ force_value_to_type (tree type, tree value) Still if we end up with truly mismatched types here, fall back to using a VIEW_CONVERT_EXPR or a literal zero to not leak invalid GIMPLE to the following passes. */ + if (TREE_CODE (value) == WITH_SIZE_EXPR) +value = TREE_OPERAND (value, 0); + if (!is_gimple_reg_type (TREE_TYPE (value)) || TYPE_SIZE (type) == TYPE_SIZE (TREE_TYPE (value))) return fold_build1 (VIEW_CONVERT_EXPR, type, value);
[Bug libstdc++/77691] [8/9/10/11 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 --- Comment #47 from dave.anglin at bell dot net --- On 2021-02-17 11:46 a.m., redi at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 > > --- Comment #46 from Jonathan Wakely --- > (In reply to John David Anglin from comment #45) >> It seems we have 8-byte alignment specified using std::max_align_t and >> 16-byte >> alignment for pthread mutexes and malloc. > That's not a libstdc++ issue though. std::max_align_t isn't defined by > libstdc++, it comes from GCC's stddef.h Thanks, looking at it.
[Bug libstdc++/77691] [8/9/10/11 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 --- Comment #46 from Jonathan Wakely --- (In reply to John David Anglin from comment #45) > It seems we have 8-byte alignment specified using std::max_align_t and > 16-byte > alignment for pthread mutexes and malloc. That's not a libstdc++ issue though. std::max_align_t isn't defined by libstdc++, it comes from GCC's stddef.h
[Bug ipa/99122] [10/11 Regression] ICE in force_constant_size, at gimplify.c:733
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99122
--- Comment #2 from Jakub Jelinek ---
Another, still undefined, but perhaps slightly less so, testcase is:
static int foo ();
int
bar (int n)
{
struct S { char a[n]; } x;
__builtin_memset (x.a, 0, n);
return foo (n, x);
}
static inline int
foo (int n, struct T { char a[n]; } b)
{
int r = 0, i;
for (i = 0; i < n; i++)
r += b.a[i];
return r;
}
I wonder if the easiest fix isn't just to disable inlining if any of the
arguments has variable length. The inliner seems to be clearly unprepared to
handle that. VLAs when passed are passed as pointers to the elements, so it is
only about variable length structures or if some front-end would pass arrays as
arrays and not as pointers.
[Bug c/99131] gcc doesn't detect missing comma in array initialisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99131 --- Comment #2 from David Binderman --- I usually write code that compiles warning free on both gcc and clang. I only noticed this difference between gcc and clang as a result of compiling the latest release of the tor browser. I thought it would be good to generalise it. I guess there must be some way to get both gcc and clang to emit all possible warning messages they can, then diff the two lists, to find out where one compiler could be enhanced. The strings command might be the way forward on this. I'd be happy to help with testing any prototype implementation. Interesting, my usual static analyser, cppcheck, has nothing to say also, so that's probably worth a bug report too.
[Bug libstdc++/77691] [8/9/10/11 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 --- Comment #45 from John David Anglin --- We see this fail on hppa-linux: https://buildd.debian.org/status/fetch.php?pkg=mysql-8.0=hppa=8.0.23-3=1613526368=0 [ 49%] Building CXX object storage/innobase/CMakeFiles/innobase.dir/api/api0api.cc.o cd /<>/builddir/storage/innobase && /usr/bin/hppa-linux-gnu-g++ -DBOOST_GEOMETRY_SQRT_CHECK_FINITENESS -DCOMPILER_HINTS -DHAVE_CONFIG_H -DHAVE_FALLOC_FL_ZERO_RANGE=1 -DHAVE_FALLOC_PUNCH_HOLE_AND_KEEP_SIZE=1 -DHAVE_IB_GCC_ATOMIC_THREAD_FENCE=1 -DHAVE_IB_GCC_SYNC_SYNCHRONISE=1 -DHAVE_IB_LINUX_FUTEX=1 -DHAVE_LZ4=1 -DHAVE_NANOSLEEP=1 -DHAVE_SCHED_GETCPU=1 -DHAVE_TLSv13 -DLINUX_NATIVE_AIO=1 -DLOG_SUBSYSTEM_TAG=\"InnoDB\" -DLZ4_DISABLE_DEPRECATE_WARNINGS -DMUTEX_EVENT -DMYSQL_SERVER -DPFS_DIRECT_CALL -DRAPIDJSON_NO_SIZETYPEDEFINE -DRAPIDJSON_SCHEMA_USE_INTERNALREGEX=0 -DRAPIDJSON_SCHEMA_USE_STDREGEX=1 -DUNIV_LINUX -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D_USE_MATH_DEFINES -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/<>/builddir -I/<>/builddir/include -I/<> -I/<>/include -I/<>/storage/innobase -I/<>/storage/innobase/include -I/<>/storage/innobase/handler -I/<>/sql -I/<>/sql/auth -isystem /<>/extra/rapidjson/include -isystem /usr/include/editline -std=c++14 -fno-omit-frame-pointer -g -O2 -ffile-prefix-map=/<>=. -Wformat -Werror=format-security -Wall -Wextra -Wformat-security -Wvla -Wundef -Woverloaded-virtual -Wcast-qual -Wimplicit-fallthrough=2 -Wstringop-truncation -Wsuggest-override -Wlogical-op -Wno-unused-parameter -Wno-cast-qual -DDBUG_OFF -ffunction-sections -fdata-sections -O2 -g -DNDEBUG -fPIC -Wdate-time -D_FORTIFY_SOURCE=2 -o CMakeFiles/innobase.dir/api/api0api.cc.o -c /<>/storage/innobase/api/api0api.cc In file included from /<>/storage/innobase/include/sync0types.h:42, from /<>/storage/innobase/include/univ.i:588, from /<>/storage/innobase/os/file.h:47, from /<>/storage/innobase/include/os0file.h:47, from /<>/storage/innobase/include/api0misc.h:40, from /<>/storage/innobase/api/api0api.cc:41: /<>/storage/innobase/include/ut0new.h: In instantiation of ‘class ut_allocator > >’: /<>/storage/innobase/include/ut0new.h:1033:19: required from ‘void ut_delete(T*) [with T = PolicyMutex >]’ /<>/storage/innobase/include/dict0mem.h:2568:5: required from here /<>/storage/innobase/include/ut0new.h:583:28: error: static assertion failed: ut_allocator does not support over-aligned types. Use aligned_memory or another similar allocator for this type. 583 | static_assert(alignof(T) <= alignof(std::max_align_t), | ~~~^~~~ make[4]: *** [storage/innobase/CMakeFiles/innobase.dir/build.make:85: storage/innobase/CMakeFiles/innobase.dir/api/api0api.cc.o] Error 1 It seems we have 8-byte alignment specified using std::max_align_t and 16-byte alignment for pthread mutexes and malloc.
[Bug debug/95343] IPA-SRA can result in wrong debug info about removed function arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95343 Martin Jambor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Martin Jambor --- This bug is fixed, the debug info is no longer wrong, just also missing in cases where we could actually provide it. But that is a different thing, so let me close this one.
[Bug target/99133] Power10 xxspltiw, xxspltidp, xxsplti32dx instructions need to be marked as prefixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99133 Michael Meissner changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |meissner at gcc dot gnu.org Last reconfirmed||2021-02-17
[Bug rtl-optimization/96264] [10/11 Regression] wrong code with -Os -fno-forward-propagate -fschedule-insns -fno-tree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96264 --- Comment #11 from Vladimir Makarov --- I've reproduced this bug and started to work on it. The bug is serious and should be probably considered as P1 one. I try to fix it on this week.
[Bug analyzer/98969] [11 Regression] ICE: Segmentation fault (in print_mem_ref)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98969 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #13 from David Malcolm --- The above commit fixes the remaining leak false positive. Marking this as resolved.
[Bug analyzer/98969] [11 Regression] ICE: Segmentation fault (in print_mem_ref)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98969
--- Comment #12 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:e0139b2a912585496f23c352f0e2c56895f78fbf
commit r11-7270-ge0139b2a912585496f23c352f0e2c56895f78fbf
Author: David Malcolm
Date: Wed Feb 17 10:37:16 2021 -0500
analyzer: fix false leak involving params [PR98969]
This patch updates the svalue liveness code so that the initial value
of parameters at top-level functions to the analysis are treated as
live (since the values are presumably still live within the
outside-of-the-analysis calling code).
This fixes the false leak in PR analyzer/98969 seen on:
void
test (long int i)
{
struct foo *f = (struct foo *)i;
f->expr = __builtin_malloc (1024);
}
since the calling code can presumably still access the allocated
buffer via:
((struct foo *)i)->expr
The patch also removes the expected leak warnings from
g++.dg/analyzer/pr99064.C and gcc.dg/analyzer/pr96841.c, which now
appear to me to be false positives.
gcc/analyzer/ChangeLog:
PR analyzer/98969
* constraint-manager.cc (dead_svalue_purger::should_purge_p):
Update for change to svalue::live_p.
* program-state.cc (sm_state_map::on_liveness_change): Likewise.
(program_state::detect_leaks): Likewise.
* region-model-reachability.cc (reachable_regions::init_cluster):
When dealing with a symbolic region, if the underlying pointer is
implicitly live, add the region to the reachable regions.
* region-model.cc (region_model::compare_initial_and_pointer):
Move logic for detecting initial values of params to
initial_svalue::initial_value_of_param_p.
* svalue.cc (svalue::live_p): Convert "live_svalues" from a
reference to a pointer; support it being NULL.
(svalue::implicitly_live_p): Convert first param from a
refererence to a pointer.
(region_svalue::implicitly_live_p): Likewise.
(constant_svalue::implicitly_live_p): Likewise.
(initial_svalue::implicitly_live_p): Likewise. Treat the initial
values of params for the top level frame as still live.
(initial_svalue::initial_value_of_param_p): New function, taken
from a test in region_model::compare_initial_and_pointer.
(unaryop_svalue::implicitly_live_p): Convert first param from a
refererence to a pointer.
(binop_svalue::implicitly_live_p): Likewise.
(sub_svalue::implicitly_live_p): Likewise.
(unmergeable_svalue::implicitly_live_p): Likewise.
* svalue.h (svalue::live_p): Likewise.
(svalue::implicitly_live_p): Likewise.
(region_svalue::implicitly_live_p): Likewise.
(constant_svalue::implicitly_live_p): Likewise.
(initial_svalue::implicitly_live_p): Likewise.
(initial_svalue::initial_value_of_param_p): New decl.
(unaryop_svalue::implicitly_live_p): Convert first param from a
refererence to a pointer.
(binop_svalue::implicitly_live_p): Likewise.
(sub_svalue::implicitly_live_p): Likewise.
(unmergeable_svalue::implicitly_live_p): Likewise.
gcc/testsuite/ChangeLog:
PR analyzer/98969
* g++.dg/analyzer/pr99064.C: Convert dg-bogus to dg-warning.
* gcc.dg/analyzer/pr96841.c: Add -Wno-analyzer-too-complex to
options. Remove false leak directive.
* gcc.dg/analyzer/pr98969.c (test_1): Remove xfail from leak
false positive.
(test_3): New.
[Bug c++/99132] [11 Regression] ICE in C++20 mode for constexpr not_null evaluation -- in cxx_eval_indirect_ref, at cp/constexpr.c:4905
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99132 --- Comment #9 from Jakub Jelinek --- Ah, the reason it only ICEs with -std=c++20 is that C++17 and earlier don't allow virtual functions to be constexpr and therefore potential_constant_expression_1 doesn't let it try to evaluate the expression. And the reason for the ICE is that genericization changed the h parameter from having B type to B& as it needs to be passed by invisible reference, and the constexpr code is not prepared to handle that (i.e. be run so late). Thus I think the above patch is the right fix.
[Bug c/99131] gcc doesn't detect missing comma in array initialisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99131 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2021-02-17 Ever confirmed|0 |1 --- Comment #1 from Eric Gallager --- Having this warning would have saved me a lot of grief trying to hunt down a particular bug I remember having to deal with in the past; confirmed.
[Bug target/99133] Power10 xxspltiw, xxspltidp, xxsplti32dx instructions need to be marked as prefixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99133 --- Comment #1 from Michael Meissner --- Note, the comment should read: Note unlike the load/store/paddi instructions, these prefixed instructions do NOT have a 'p' prefix, which means the code in rs6000_final_prescan_insn will have to be modified so it does not add a 'p' for these cases.
[Bug c++/99132] [11 Regression] ICE in C++20 mode for constexpr not_null evaluation -- in cxx_eval_indirect_ref, at cp/constexpr.c:4905
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99132
--- Comment #8 from Jakub Jelinek ---
We certainly can (and IMHO should) do:
--- gcc/cp/cp-gimplify.c.jj 2021-02-10 07:52:32.702901304 +0100
+++ gcc/cp/cp-gimplify.c2021-02-17 16:06:03.045953720 +0100
@@ -1386,7 +1386,7 @@ cp_genericize_r (tree *stmt_p, int *walk
break;
}
- if (tree fndecl = cp_get_callee_fndecl (stmt))
+ if (tree fndecl = cp_get_callee_fndecl_nofold (stmt))
if (DECL_IMMEDIATE_FUNCTION_P (fndecl))
{
gcc_assert (source_location_current_p (fndecl));
because addresses of immediate functions shouldn't be leaking in the IL
anywhere and so only direct calls to them are possible.
The strange thing is why it ICEs only with -std=c++20...
[Bug tree-optimization/98736] [10/11 Regression] Wrong partition order generated in loop distribution pass since r10-619-g5879ab5fafedc8f6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98736 --- Comment #3 from bin cheng --- hmm, seems topological order isn't enough for distributing a loop nest, we need topological order plus inner loop depth-first.
[Bug debug/96997] [10/11 Regression] step over in gdb always stops in basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96997 --- Comment #13 from CVS Commits --- The releases/gcc-10 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:d7fa3fa5796a46deb308c8c38b247e290d97f1f6 commit r10-9372-gd7fa3fa5796a46deb308c8c38b247e290d97f1f6 Author: Patrick Palka Date: Wed Feb 17 09:55:42 2021 -0500 c++: Revert EXPR_LOCATION change to build_aggr_init_expr [PR96997] My change in r10-7718 to make build_aggr_init_expr set EXPR_LOCATION (mimicking build_target_expr) causes the debuginfo regression PR96997. Given that this change is mostly independent of the rest of the commit, and that the only fallout of reverting it is a less accurate error message location in a testcase introduced in the same commit, it seems the best way forward is to just revert this part of the commit. gcc/cp/ChangeLog: PR debug/96997 PR c++/94034 * tree.c (build_aggr_init_expr): Revert r10-7718 change. gcc/testsuite/ChangeLog: PR debug/96997 PR c++/94034 * g++.dg/cpp1y/constexpr-nsdmi7b.C: Adjust expected location of "call to non-'constexpr' function" error message. (cherry picked from commit 78a6d0e30d7950216dc0c5be5d65d0cbed13924c)
[Bug c++/94034] [10 Regression] Broken diagnostic: 'result_decl' not supported by dump_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94034 --- Comment #11 from CVS Commits --- The releases/gcc-10 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:d7fa3fa5796a46deb308c8c38b247e290d97f1f6 commit r10-9372-gd7fa3fa5796a46deb308c8c38b247e290d97f1f6 Author: Patrick Palka Date: Wed Feb 17 09:55:42 2021 -0500 c++: Revert EXPR_LOCATION change to build_aggr_init_expr [PR96997] My change in r10-7718 to make build_aggr_init_expr set EXPR_LOCATION (mimicking build_target_expr) causes the debuginfo regression PR96997. Given that this change is mostly independent of the rest of the commit, and that the only fallout of reverting it is a less accurate error message location in a testcase introduced in the same commit, it seems the best way forward is to just revert this part of the commit. gcc/cp/ChangeLog: PR debug/96997 PR c++/94034 * tree.c (build_aggr_init_expr): Revert r10-7718 change. gcc/testsuite/ChangeLog: PR debug/96997 PR c++/94034 * g++.dg/cpp1y/constexpr-nsdmi7b.C: Adjust expected location of "call to non-'constexpr' function" error message. (cherry picked from commit 78a6d0e30d7950216dc0c5be5d65d0cbed13924c)
[Bug c++/99135] [modules] implementation partitions are too visible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99135 Nathan Sidwell changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2021-02-17 Keywords||accepts-invalid Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org
[Bug c++/99135] New: [modules] implementation partitions are too visible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99135
Bug ID: 99135
Summary: [modules] implementation partitions are too visible
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nathan at gcc dot gnu.org
Target Milestone: ---
imported implementation partitions are exported :(
// p_a.ii
module Foo:A;
void frob ();
// p_b.ii
export module Foo;
import :A;
// p_c.ii
module Foo;
void f () { frob (); }
zathras:113>./cc1plus -fmodules-ts -quiet p_a.ii
zathras:114>./cc1plus -fmodules-ts -quiet p_b.ii
zathras:115>./cc1plus -fmodules-ts -quiet p_c.ii
zathras:116>
the p_c implementation unit should not see the decls of implementation
partition Foo:A. It needs to explicitly import :A to do that.
[Bug c/99134] New: S390x: pfpo instructions are not used for dfp[128|64|32] to/from long double conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99134 Bug ID: 99134 Summary: S390x: pfpo instructions are not used for dfp[128|64|32] to/from long double conversions Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: stli at linux dot ibm.com Target Milestone: --- Created attachment 50212 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50212=edit Test which runs the dfpXYZ <-> long double conversions which are not performed via pfpo instruction, but by calling __dpd_[trunc|extend] functions. See libdfp-issue "s390x: 3 test failures on Fedora Rawhide #160" https://github.com/libdfp/libdfp/issues/160 (Notice that Rawhide is using GCC 11 now.) Reproduced the issues with gcc commit 78a6d0e30d7950216dc0c5be5d65d0cbed13924c You have to configure gcc with --enable-decimal-float All decimal-floating-point[128|64|32] <-> binary-floating-point[128|64|32] conversions should emit the pfpo (PERFORM FLOATING-POINT OPERATION) instruction as used in previous GCC versions. GCC 11 is not using the pfpo instruction if bfp128 (long double) is involved in the conversion. In the libdfp implementation of dpd_extend/trunc functions, this leads to be a recursive call to itself which segfaults as it runs out of stack: - bfp128 -> dfp128 (do__dpd_extendtftd(): brasl %r14,<__dpd_extendtftd>) - bfp128 -> dfp64 (do_bfp128_to_dfp64(): brasl %r14,<__dpd_trunctfdd>) - bfp128 -> dfp32 (do_bfp128_to_dfp32(): brasl %r14,<__dpd_trunctfsd>) - dfp128 -> bfp128 (do__dpd_trunctdtf(): brasl %r14,<__dpd_trunctdtf>) - dfp64 -> bfp128 (do_dfp64_to_bfp128(): brasl %r14,<__dpd_extendddtf>) - dfp32 -> bfp128 (do_dfp32_to_bfp128(): brasl %r14,<__dpd_extendsdtf>)
[Bug target/99133] New: Power10 xxspltiw, xxspltidp, xxsplti32dx instructions need to be marked as prefixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99133 Bug ID: 99133 Summary: Power10 xxspltiw, xxspltidp, xxsplti32dx instructions need to be marked as prefixed Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: meissner at gcc dot gnu.org Target Milestone: --- The power10 instructions added for loading up constants in the vector registers (xxspltib, xxspltidp, xxsplti32dx) are prefixed instructions, and we need to set the prefixed attribute, so that the instruction length is correct. Note unlike the load/store/paddi instructions, these prefixed instructions do have a 'p' prefix, which means the code in rs6000_final_prescan_insn will have to be modified so it does not add a 'p' for these cases.
[Bug c++/99132] [11 Regression] ICE in C++20 mode for constexpr not_null evaluation -- in cxx_eval_indirect_ref, at cp/constexpr.c:4905
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99132 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- Ok, will have a look then...
[Bug c++/99132] [11 Regression] ICE in C++20 mode for constexpr not_null evaluation -- in cxx_eval_indirect_ref, at cp/constexpr.c:4905
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99132
--- Comment #6 from Jakub Jelinek ---
template struct A { T c; };
template struct B {
A d;
constexpr T operator->() { return d.c; }
B(B &&);
};
struct C {
virtual void foo ();
void bar (B h) { h->foo (); }
};
[Bug c++/99132] [11 Regression] ICE in C++20 mode for constexpr not_null evaluation -- in cxx_eval_indirect_ref, at cp/constexpr.c:4905
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99132 --- Comment #5 from Marek Polacek --- Started with r11-5685.
[Bug c++/99132] [11 Regression] ICE in C++20 mode for constexpr not_null evaluation -- in cxx_eval_indirect_ref, at cp/constexpr.c:4905
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99132 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Reducing...
[Bug c++/99132] [11 Regression] ICE in C++20 mode for constexpr not_null evaluation -- in cxx_eval_indirect_ref, at cp/constexpr.c:4905
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99132 Marek Polacek changed: What|Removed |Added Summary|ICE in C++20 mode for |[11 Regression] ICE in |constexpr not_null |C++20 mode for constexpr |evaluation -- in |not_null evaluation -- in |cxx_eval_indirect_ref, at |cxx_eval_indirect_ref, at |cp/constexpr.c:4905 |cp/constexpr.c:4905 Target Milestone|--- |11.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org Keywords||ice-on-valid-code Last reconfirmed||2021-02-17 Priority|P3 |P1 --- Comment #3 from Marek Polacek --- Confirmed.
[Bug c++/99132] ICE in C++20 mode for constexpr not_null evaluation -- in cxx_eval_indirect_ref, at cp/constexpr.c:4905
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99132 --- Comment #2 from Bob Miller --- I have reported this bug to the gsl-lite maintainer as well here: https://github.com/gsl-lite/gsl-lite/issues/281
[Bug c++/99132] ICE in C++20 mode for constexpr not_null evaluation -- in cxx_eval_indirect_ref, at cp/constexpr.c:4905
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99132 --- Comment #1 from Bob Miller --- Created attachment 50211 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50211=edit preprocessed file that triggers the bug
[Bug c++/99132] New: ICE in C++20 mode for constexpr not_null evaluation -- in cxx_eval_indirect_ref, at cp/constexpr.c:4905
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99132 Bug ID: 99132 Summary: ICE in C++20 mode for constexpr not_null evaluation -- in cxx_eval_indirect_ref, at cp/constexpr.c:4905 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: bobmiller at nvidia dot com Target Milestone: --- Usage of gsl-lite::not_null can cause an internal compiler error. Minimal online example: https://godbolt.org/z/Y8n93K I also intend to report this to the gsl-lite maintainer, but I don't believe their code should trigger an ICE regardless. My system is x86-linux-amd64. I confirmed in current trunk, commit hash 24bf79f1798ad1d64812709001d2d11cd3e6849f The attached preprocessed output (a-test.ii) was built with the following command: g++-11 -v -save-temps --std=c++20 test.cpp Full output: -- Using built-in specs. COLLECT_GCC=/home/bob/bin/g++-11 COLLECT_LTO_WRAPPER=/home/bob/libexec/gcc/x86_64-linux-gnu/11.0.0/lto-wrapper Target: x86_64-linux-gnu Configured with: ../gcc/configure -v --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --prefix=/home/bob/ --enable-checking=release --enable-languages=c,c++ --disable-multilib --program-suffix=-11 Thread model: posix Supported LTO compression algorithms: zlib gcc version 11.0.0 20210217 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++20' '-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a-' /home/bob/libexec/gcc/x86_64-linux-gnu/11.0.0/cc1plus -E -quiet -v -imultiarch x86_64-linux-gnu -D_GNU_SOURCE /home/bob/test.cpp -mtune=generic -march=x86-64 -std=c++20 -fpch-preprocess -o a-test.ii ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring nonexistent directory "/home/bob/lib/gcc/x86_64-linux-gnu/11.0.0/../../../../x86_64-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /home/bob/lib/gcc/x86_64-linux-gnu/11.0.0/../../../../include/c++/11.0.0 /home/bob/lib/gcc/x86_64-linux-gnu/11.0.0/../../../../include/c++/11.0.0/x86_64-linux-gnu /home/bob/lib/gcc/x86_64-linux-gnu/11.0.0/../../../../include/c++/11.0.0/backward /home/bob/lib/gcc/x86_64-linux-gnu/11.0.0/include /usr/local/include /home/bob/include /home/bob/lib/gcc/x86_64-linux-gnu/11.0.0/include-fixed /usr/include/x86_64-linux-gnu /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++20' '-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a-' /home/bob/libexec/gcc/x86_64-linux-gnu/11.0.0/cc1plus -fpreprocessed a-test.ii -quiet -dumpdir a- -dumpbase test.cpp -dumpbase-ext .cpp -mtune=generic -march=x86-64 -std=c++20 -version -o a-test.s GNU C++20 (GCC) version 11.0.0 20210217 (experimental) (x86_64-linux-gnu) compiled by GNU C version 11.0.0 20210216 (experimental), GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C++20 (GCC) version 11.0.0 20210217 (experimental) (x86_64-linux-gnu) compiled by GNU C version 11.0.0 20210216 (experimental), GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 4db0a130394a49defb276090de10ab74 /home/bob/test.cpp: In member function ‘virtual void Source::attachSink(gsl::not_null)’: /home/bob/test.cpp:15:13: in ‘constexpr’ expansion of ‘sink.gsl::not_null::operator->()’ /home/bob/test.cpp:16:5: internal compionline example: https://godbolt.org/z/Y8n93K ler error: in cxx_eval_indirect_ref, at cp/constexpr.c:4905 16 | } | ^ 0x6649a2 cxx_eval_indirect_ref ../../gcc/gcc/cp/constexpr.c:4905 0x6649a2 cxx_eval_constant_expression ../../gcc/gcc/cp/constexpr.c:6362 0x6dfc1a cxx_eval_component_reference ../../gcc/gcc/cp/constexpr.c:3797 0x6dfc1a cxx_eval_constant_expression ../../gcc/gcc/cp/constexpr.c:6538 0x6dfc1a cxx_eval_component_reference ../../gcc/gcc/cp/constexpr.c:3797 0x6dfc1a cxx_eval_constant_expression ../../gcc/gcc/cp/constexpr.c:6538 0x6dfa23 cxx_eval_constant_expression ../../gcc/gcc/cp/constexpr.c:6634 0x6e8875 cxx_eval_binary_expression ../../gcc/gcc/cp/constexpr.c:3122 0x6df609 cxx_eval_constant_expression ../../gcc/gcc/cp/constexpr.c:6500 0x6e1889 cxx_eval_conditional_expression ../../gcc/gcc/cp/constexpr.c:3232 0x6e1889 cxx_eval_constant_expression ../../gcc/gcc/cp/constexpr.c:6581 0x6e04e0 cxx_eval_constant_expression ../../gcc/gcc/cp/constexpr.c:6309 0x6e003c cxx_eval_constant_expression ../../gcc/gcc/cp/constexpr.c:6320 0x6e0c26 cxx_eval_
[Bug sanitizer/99106] [9/10/11 Regression] ICE in tree_to_poly_int64, at tree.c:3091
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99106 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:7768cadb4246117964a9ba159740da3b9c20811d commit r11-7267-g7768cadb4246117964a9ba159740da3b9c20811d Author: Jakub Jelinek Date: Wed Feb 17 15:03:25 2021 +0100 c++: Fix up build_zero_init_1 once more [PR99106] My earlier build_zero_init_1 patch for flexible array members created an empty CONSTRUCTOR. As the following testcase shows, that doesn't work very well because the middle-end doesn't expect CONSTRUCTOR elements with incomplete type (that the empty CONSTRUCTOR at the end of outer CONSTRUCTOR had). The following patch just doesn't add any CONSTRUCTOR for the flexible array members, it doesn't seem to be needed. 2021-02-17 Jakub Jelinek PR sanitizer/99106 * init.c (build_zero_init_1): For flexible array members just return NULL_TREE instead of returning empty CONSTRUCTOR with non-complete ARRAY_TYPE. * g++.dg/ubsan/pr99106.C: New test.
[Bug middle-end/51839] GCC not generating adc instruction for canonical multi-precision add sequence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51839 Paweł Bylica changed: What|Removed |Added CC||chfast at gmail dot com --- Comment #1 from Paweł Bylica --- This is fixed in GCC 8.1 (at least for add+adc pair). https://godbolt.org/z/9j4f6r
[Bug c++/99071] [modules] ICE with initializer_list & iostream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99071 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|SUSPENDED --- Comment #4 from Nathan Sidwell --- believed dup of 99023 remains
[Bug c++/99071] [modules] ICE with initializer_list & iostream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99071 --- Comment #3 from Nathan Sidwell --- d46c7e2c546 2021-02-17 | c++: ICE with header-units [PR 99071] but there's now an ICE in write_defines. (reported elsewhere too)
[Bug c++/99116] [11 Regression] ICE in set_identifier_type_value_with_scope, at cp/name-lookup.c:4764
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99116 Nathan Sidwell changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Nathan Sidwell --- 24bf79f1798 2021-02-17 | c++: More set_identifier_type_value fixing [PR 99116]
[Bug c++/99116] [11 Regression] ICE in set_identifier_type_value_with_scope, at cp/name-lookup.c:4764
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99116 --- Comment #2 from CVS Commits --- The master branch has been updated by Nathan Sidwell : https://gcc.gnu.org/g:24bf79f1798ad1d64812709001d2d11cd3e6849f commit r11-7266-g24bf79f1798ad1d64812709001d2d11cd3e6849f Author: Nathan Sidwell Date: Wed Feb 17 05:33:45 2021 -0800 c++: More set_identifier_type_value fixing [PR 99116] My recent change looked under template_parms in two places, but that was covering up a separate problem. We were attempting to set the identifier_type_value of a template_parm into the template_parm scope. The peeking stopped us doing that, but confused poplevel, leaving an identifier value lying around. This fixes the underlying problem in do_pushtag -- we only need to set the identifier_type_value directly when we're in a template_parm scope (a later pushdecl will push the actual template_decl). for non-class non-template-parm bindings do_pushdecl already ends up manipulating identifier_type_value correctly. PR c++/99116 gcc/cp/ * name-lookup.c (do_pushdecl): Don't peek under template_parm bindings here ... (set_identifier_type_value_with_scope): ... or here. (do_pushtag): Only set_identifier_type_value_with_scope at non-class template parm scope, and use parent scope. gcc/testsuite/ * g++.dg/lookup/pr99116-1.C: New. * g++.dg/lookup/pr99116-2.C: New.
[Bug c++/99071] [modules] ICE with initializer_list & iostream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99071 --- Comment #2 from CVS Commits --- The master branch has been updated by Nathan Sidwell : https://gcc.gnu.org/g:d46c7e2c546b26d036856cf570694b832d3b1f54 commit r11-7265-gd46c7e2c546b26d036856cf570694b832d3b1f54 Author: Nathan Sidwell Date: Wed Feb 17 05:28:09 2021 -0800 c++: ICE with header-units [PR 99071] This ICE was caused by dereferencing the wrong pointer and not finding the expected thing there. Pointers are like that. PR c++/99071 gcc/cp/ * name-lookup.c (maybe_record_mergeable_decl): Deref the correct pointer. gcc/testsuite/ * g++.dg/modules/pr99071_a.H: New. * g++.dg/modules/pr99071_b.H: New.
[Bug target/98491] [MIPS] ICE: in mode_size_inline, with -mmsa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98491 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:06505e701dcfdb1b9855601d6cf0aa1caea62975 commit r11-7264-g06505e701dcfdb1b9855601d6cf0aa1caea62975 Author: Xi Ruoyao Date: Wed Feb 17 11:57:13 2021 + mips: Avoid out-of-bounds access in mips_symbol_insns [PR98491] An invalid use of MSA_SUPPORTED_MODE_P was causing an ICE on mips64el with -mmsa. The detailed analysis is posted on bugzilla. gcc/ChangeLog: 2021-02-17 Xi Ruoyao PR target/98491 * config/mips/mips.c (mips_symbol_insns): Do not use MSA_SUPPORTED_MODE_P if mode is MAX_MACHINE_MODE.
[Bug c/99131] gcc doesn't detect missing comma in array initialisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99131 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic Severity|normal |enhancement Blocks||87403 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 [Bug 87403] [Meta-bug] Issues that suggest a new warning
[Bug c/99131] New: gcc doesn't detect missing comma in array initialisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99131
Bug ID: 99131
Summary: gcc doesn't detect missing comma in array
initialisation
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C code:
const char * a[ 4] = {
" fred ",
" bert "
" harry ",
" eric "
};
Note missing "," on the bert line. gcc doesn't say very much:
$ /home/dcb/gcc/results/bin/gcc -c -g -O2 -Wall -Wextra feb17f.cc
$
Here is a recent clang doing something more useful:
$ /home/dcb/llvm/clang1200rc1/bin/clang++ -c -g -O2 -Wall -Wextra feb17f.cc
feb17f.cc:7:2: warning: suspicious concatenation of string literals in an array
initialization; did you mean to separate the elements with a comma?
[-Wstring-concatenation]
" harry ",
^
feb17f.cc:6:2: note: place parentheses around the string literal to silence
warning
" bert "
^
1 warning generated.
[Bug target/99115] ICE in extract_insn, at recog.c:2309 on alpha (error: unrecognizable insn) with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99115 --- Comment #4 from Uroš Bizjak --- Compiles OK with: GNU C++14 (GCC) version 8.4.1 20210216 [releases/gcc-8 revision c6513400d84:39c49bc104d:1f3a07da9b6bcfa4733750826746bd18ac6f20db] (alpha-unknown-openbsd6.8) built as a cross from x86_64-linux-gnu, and configured with: --target=alpha-unknown-openbsd6.8 Please try to trigger the ICE with the x86_64 crosscompiler.
[Bug c++/99050] [modules] ICE in cpp_directive_only_process on include translation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99050 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- https://gcc.gnu.org/g:b37695c9bf101a3a30a231cfeb6da7a6c17657d6 commit r11-7260-gb37695c9bf101a3a30a231cfeb6da7a6c17657d6 Author: Nathan Sidwell Date: Tue Feb 16 12:23:12 2021 -0800 c++: directives-only preprocessing and include translation [PR 99050] We make sure files end in \n by placing one at the limit of the buffer (just past the end of what is read). We need to do the same for buffers generated via include-translation. Fortunately they have space. libcpp/ * files.c (_cpp_stack_file): Make buffers end in unread \n. gcc/testsuite/ * g++.dg/modules/pr99050_a.H: New. * g++.dg/modules/pr99050_b.C: New.
[Bug c/99127] ICE in expand_expr_addr_expr_1, at expr.c:8026 (during RTL pass: expand) at -O1 or higher on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99127
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC||marxin at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed||2021-02-17
--- Comment #2 from Martin Liška ---
Confirmed on the current master. There's a reduced test-case:
$ cat pr99127.i
int c_pow_r_1, c_pow_r_0, c_pow_phase;
void
c_pow() {
c_pow_r_0 = __builtin_cos(c_pow_phase);
c_pow_r_1 = __builtin_sin(c_pow_phase);
}
It's related to sincos optimization we do:
-fdump-tree-optimized=/dev/stdout:
sincostmp_10 = __builtin_cexpi (_2);
_3 = REALPART_EXPR ;
_4 = (int) _3;
c_pow_r_0 = _4;
_5 = IMAGPART_EXPR ;
Unfortunately, we don't have an option which can be used to disable the
optimization:
gcc/tree-ssa-math-opts.c:2252:
/* opt_pass methods: */
virtual bool gate (function *)
{
/* We no longer require either sincos or cexp, since powi expansion
piggybacks on this pass. */
return optimize;
}
[Bug jit/99126] Compilation ICE trying insert trap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99126 Martin Liška changed: What|Removed |Added Last reconfirmed||2021-02-17 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Thanks for the report. > This is my understanding of what is going on here: we have a some > generated code that in GIMPLE is proved to dereference a null pointer > (BTW this code should be unreachable). That's fine. > > MEM[(struct comp_Lisp_Cons *)0B].u.s.car = _35; > So I guess JIT should really initialize the builtins. I tried manually calling: gcc_jit_context_get_builtin_function (ctxt_0x8892590, "__builtin_trap"); and then your reproducer is fine. Leaving to David.
