[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137 --- Comment #7 from Martin Liška --- In the meantime, I run all tests in gcc/testsuite/g++.dg/coroutines/torture and I see: $ g++ co-ret-17-void-ret-coro.C -fsanitize=address -fcoroutines -O2 && ./a.out = ==8226==ERROR: AddressSanitizer: heap-use-after-free on address 0x60400010 at pc 0x00401286 bp 0x7fffe130 sp 0x7fffe128 READ of size 8 at 0x60400010 thread T0 #0 0x401285 in main (/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/coroutines/torture/a.out+0x401285) #1 0x770dfcea in __libc_start_main ../csu/libc-start.c:308 #2 0x401309 in _start (/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/coroutines/torture/a.out+0x401309) 0x60400010 is located 0 bytes inside of 48-byte region [0x60400010,0x60400040) freed by thread T0 here: #0 0x776ae9f7 in operator delete(void*) /home/marxin/Programming/gcc/libsanitizer/asan/asan_new_delete.cpp:160 #1 0x4015b7 in _Z7my_coroRNSt7__n486116coroutine_handleIvEE.actor(my_coro(std::__n4861::coroutine_handle&)::_Z7my_coroRNSt7__n486116coroutine_handleIvEE.frame*) (/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/coroutines/torture/a.out+0x4015b7) previously allocated by thread T0 here: #0 0x776adff7 in operator new(unsigned long) /home/marxin/Programming/gcc/libsanitizer/asan/asan_new_delete.cpp:99 #1 0x401902 in my_coro(std::__n4861::coroutine_handle&) (/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/coroutines/torture/a.out+0x401902) #2 0x403d8f in __local_asan_preinit (/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/coroutines/torture/a.out+0x403d8f) SUMMARY: AddressSanitizer: heap-use-after-free (/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/coroutines/torture/a.out+0x401285) in main Shadow bytes around the buggy address: 0x0c087fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c087fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c087fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c087fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c087fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0c087fff8000: fa fa[fd]fd fd fd fd fd fa fa fa fa fa fa fa fa 0x0c087fff8010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c087fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c087fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c087fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c087fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe Left alloca redzone: ca Right alloca redzone:cb Shadow gap: cc ==8226==ABORTING
[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137 Martin Liška changed: What|Removed |Added Status|WAITING |NEW Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #8 from Martin Liška --- Created attachment 48555 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48555&action=edit Failures for UBSAN in coroutine test-suite And there are quite many UBSAN errors.
[Bug d/95184] New: GDC reporting multiple definitions of functions where DMD and LDC do not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95184 Bug ID: 95184 Summary: GDC reporting multiple definitions of functions where DMD and LDC do not Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: oss at cogitri dot dev Target Milestone: --- Created attachment 48556 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48556&action=edit Full build log When compiling glibd 2.1.0 with gir-to-d 0.21 with gdc 9.3.0 it errors out, complaining about multiple definitions of functions: /usr/lib/gcc/x86_64-alpine-linux-musl/9.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: glibd-2.0@sha/output_generated_gio_DataInputStream.d.o: in function `_DT56_D3gio19BufferedInputStream19BufferedInputStream9__mixin1517getSeekableStructMFbZPS3gio1c5types9GSeekable': DataInputStream.d:(.text+0x1be4): multiple definition of `_DT56_D3gio19BufferedInputStream19BufferedInputStream9__mixin1517getSeekableStructMFbZPS3gio1c5types9GSeekable'; glibd-2.0@sha/output_generated_gio_BufferedInputStream.d.o:BufferedInputStream.d:(.text+0x10c): first defined here Since the source is generated via gir-to-d I don't think providing the source makes much sense here, if you need assistance in building glibd I can help
[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137 Iain Sandoe changed: What|Removed |Added Assignee|marxin at gcc dot gnu.org |iains at gcc dot gnu.org --- Comment #9 from Iain Sandoe --- some of the issues noted are likely addressed by patches already in my queue - so taking this for now.
[Bug target/94991] aarch64: ICE: Segmentation fault with option -mgeneral-regs-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94991 rsandifo at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED CC||rsandifo at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #3 from rsandifo at gcc dot gnu.org --- Fixed on trunk.
[Bug d/95184] GDC reporting multiple definitions of functions where DMD and LDC do not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95184 --- Comment #1 from Iain Buclaw --- Could this be a duplicate of PR d/92216?
[Bug target/94934] Failure to inline addv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94934 --- Comment #3 from Gabriel Ravier --- In that case, it looks really easy to reimplemnet `-ftrapv` as literally just enabling `-fsanitize=signed-integer-overflow -fsanitize-undefined-trap-on-error`.
[Bug target/94962] Suboptimal AVX2 code for _mm256_zextsi128_si256(_mm_set1_epi8(-1))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94962
Hongtao.liu changed:
What|Removed |Added
CC||crazylht at gmail dot com
--- Comment #1 from Hongtao.liu ---
redudant vmovdaq xmm0, xmm0 is generated by
(insn:TI 7 6 14 2 (set (reg:V8SI 20 xmm0 [84])
(vec_concat:V8SI (reg:V4SI 20 xmm0 [86])
(const_vector:V4SI [
(const_int 0 [0]) repeated x4
])))
"/export/users2/liuhongt/install/gcc10_trunk/lib/gcc/x86_64-pc-linux-gnu/10.0.1/include/avxintrin.h":770:20
5296 {avx_vec_concatv8si}
(expr_list:REG_EQUIV (const_vector:V8SI [
(const_int -1 [0x]) repeated x4
(const_int 0 [0]) repeated x4
])
(nil)))
-
could be eliminated if src operand has same regno as dest operand.
---
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 7a7ecd4be87..4ff4cf55f74 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -21123,6 +21123,9 @@
}
case 2:
case 3:
+ if (register_operand (operands[1], MODE)
+ && REGNO (operands[1]) == REGNO (operand[0]))
+ return "";
switch (get_attr_mode (insn))
{
case MODE_V16SF:
---
[Bug fortran/94925] Undesired runtime warning message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94925 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org Status|UNCONFIRMED |WAITING Last reconfirmed||2020-05-18 Ever confirmed|0 |1 --- Comment #3 from Thomas Koenig --- Please provide a self-contained example and the complete command line that you use.
[Bug tree-optimization/94919] Failure to recognize max pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94919 --- Comment #2 from Gabriel Ravier --- Essentially, what I've been doing in my spare time for the past few weeks is looking at random pieces of code all over the internet, looking at the results trunk gcc/clang give (usually on x86-64 (though I've been thinking about looking at arm and other architectures), with flags like -Ofast -march=tigerlake) and seeing whether GCC or LLVM optimizes them better than the other (and making appropriate bug reports). Some of these are from actual projects, some are from websites listing bithacks, some are from books like Hacker's Delight, some were written by myself when studying the code from those above sources, and finally a few of them were from testsuites in either LLVM or GCC (though those are rarer, especially for LLVM, since it takes time to convert them from LLVM bytecode to something I can compile with both GCC and Clang). For this particular bug report, I believe this is *probably* from somewhere in Hacker's Delight.
[Bug fortran/94978] [8/9/10/11 Regression] Bogus warning "Array reference at (1) out of bounds in loop beginning at (2)"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94978 Thomas Koenig changed: What|Removed |Added Ever confirmed|0 |1 Blocks||90302 Status|UNCONFIRMED |NEW Last reconfirmed||2020-05-18 CC||tkoenig at gcc dot gnu.org --- Comment #2 from Thomas Koenig --- Two ways to fix this: When checking for outer do loops, also check if the inner one will be executed at all. Or PR 90302, which is looking more attractive than ever. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90302 [Bug 90302] Implement __builtin_warning
Lingual Translation & Interpertation Services
Respected Sir/Ma’am, I would like to introduce a *Translation Company *that specializes in the providing *Translation, **Interpretation* (Language Translator on contract/permanent basis) and *Web/Soft/App. Localization **services *since last seventeen years. The company is a pioneer in the fields of translation and interpretation across the globe. It has on board a number of experienced translators and interpreters who are specialized in different languages and areas. Some reputed Clients: *TCS, Global Sign, BHEL**, **Interglobe Technologies, Schneider Electric** and **NISC Export Services* *I would be highly grateful if you consider us for providing **any of the above** service**s.* Kind Regards, Preety Ahuja Dept. (Tr & In) [image: beacon]
[Bug d/92216] GDC generate duplicate symbols when mixins and interfaces are used to gather
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92216 Rasmus Thomsen changed: What|Removed |Added CC||oss at cogitri dot dev --- Comment #5 from Rasmus Thomsen --- *** Bug 95184 has been marked as a duplicate of this bug. ***
[Bug d/95184] GDC reporting multiple definitions of functions where DMD and LDC do not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95184 Rasmus Thomsen changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Rasmus Thomsen --- Yes, the patch mentioned in that bug fixed it, thanks! *** This bug has been marked as a duplicate of bug 92216 ***
[Bug libstdc++/95170] GetTickCount64 cannot get found in KERNEL32.dll on Legacy Windows Platforms like Windows XP, 2000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95170 --- Comment #3 from Jonathan Wakely --- Right, libstdc++ doesn't use GetTickCount64 anywhere.
[Bug sanitizer/94910] detect_stack_use_after_return=1 is much slower than clang's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94910 Martin Liška changed: What|Removed |Added Status|WAITING |NEW --- Comment #4 from Martin Liška --- I was able to reproduce that! The problem is the number of fake stacks that are exhausted. I see 27000x: FakeStack (stack_size_log=20):succ after 0 FakeStack (stack_size_log=20):succ after 0 FakeStack (stack_size_log=20):succ after 0 FakeStack (stack_size_log=20):succ after 0 ... FakeStack (stack_size_log=20):bail out after 8192 FakeStack (stack_size_log=20):bail out after 16384 FakeStack (stack_size_log=20):bail out after 4096 FakeStack (stack_size_log=20):bail out after 8192 ... So it seems that the program uses enormous number of stacks. Or the run-time does not release them in an efficient way.
[Bug sanitizer/94910] detect_stack_use_after_return=1 is much slower than clang's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94910 --- Comment #5 from Martin Liška --- > FakeStack (stack_size_log=20):bail out after 8192 > FakeStack (stack_size_log=20):bail out after 16384 > FakeStack (stack_size_log=20):bail out after 4096 > FakeStack (stack_size_log=20):bail out after 8192 > ... This comes after the 27000 success Fake stack allocations.
[Bug d/95184] GDC reporting multiple definitions of functions where DMD and LDC do not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95184 Iain Buclaw changed: What|Removed |Added Resolution|DUPLICATE |FIXED --- Comment #3 from Iain Buclaw --- OK, I'll prep a backport then.
[Bug c++/71954] template partial specialization for constexpr error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71954
--- Comment #2 from Vladislav Suratov ---
Confirmed with 9.3, 10.1 and current trunk (11.0).
Tested with --std=c++17, meanwhile clang 10.0 (and trunk) and MSVC 19.24 and
MSVC 19.25 successfully compile it.
The following example is what I used for testing:
#include
struct Test1
{
template
struct Helper1{
static constexpr bool value = false;
};
template
struct Helper1>{
static constexpr bool value = true;
};
};
struct Test2
{
template
static constexpr bool Helper1 = false;
template
static constexpr bool Helper1> = true;
};
static_assert(Test1::Helper1>::value, "Check");
static_assert(Test2::Helper1>, "Check");
[Bug target/94934] Failure to inline addv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94934 --- Comment #4 from Jakub Jelinek --- (In reply to Gabriel Ravier from comment #3) > In that case, it looks really easy to reimplemnet `-ftrapv` as literally > just enabling `-fsanitize=signed-integer-overflow > -fsanitize-undefined-trap-on-error`. It shouldn't be literally that, because -ftrapv should be able to coexist with other UBSan sanitizers (just not signed-integer-overflow) and e.g. let the other UBSan sanitizers have different decision on what to do on error (the trap. vs. fatal error vs. just diagnostics and continue). And for -ftrapv we should consider using the library functions rather than emitting code inline if it would be too large to match past behavior.
[Bug d/95075] gcc/d/dmd/dscope.c: 2 * strange assignments ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95075 --- Comment #2 from Iain Buclaw --- """ I think I wrote it that way to emphasize what the result should be, and relied on the optimizer removing the self-assignment. So, the code is correct. """ So I'll remove the self-assignment with a comment expressing this instead.
[Bug target/94962] Suboptimal AVX2 code for _mm256_zextsi128_si256(_mm_set1_epi8(-1))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94962 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- But such an instruction isn't always redundant, it really depends on what the previous setter of the register did, whether the upper 128 bit of the 256-bit register are already guaranteed to be zero or not. Thus the #c1 patch looks incorrect to me, one would need peephole2s or some combine patterns or target specific pass etc. to discover that at least for the common cases; and it isn't something we model in the RTL patterns (what insns guarantee which upper bits zero and what do not; and for some there can be different choices even in the same define_insn, we could implement something using widened registers and then there would be no guarantee etc.).
[Bug tree-optimization/95172] [11 Regression] wrong code at -O1 on x86_64-linux-gnu since r11-272-gb6ff3ddecfa93d53
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95172 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Blocks||57359 Status|ASSIGNED|RESOLVED --- Comment #4 from Richard Biener --- Fixed. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359 [Bug 57359] store motion causes wrong code for union access at -O3
[Bug tree-optimization/95172] [11 Regression] wrong code at -O1 on x86_64-linux-gnu since r11-272-gb6ff3ddecfa93d53
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95172 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:52a0f83980082c9995f2d8ec9b88548520fb8a5f commit r11-450-g52a0f83980082c9995f2d8ec9b88548520fb8a5f Author: Richard Biener Date: Mon May 18 09:17:24 2020 +0200 tree-optimization/95172 - avoid mixing conditionalized and ordered SM The following testcase shows a missed optimization that then leads to wrong-code when issueing SMed stores on exits. When we were able to compute an ordered sequence of stores for an exit we need to emit that in the correct order and we can emit it disregarding to any conditional for whether a store actually happened (we know it did). We can also improve detection as of whether we need conditional processing at all. Both parts fix the testcase. 2020-05-18 Richard Biener PR tree-optimization/95172 * tree-ssa-loop-im.c (execute_sm): Get flag whether we eventually need the conditional processing. (execute_sm_exit): When processing an orderd sequence avoid doing any conditional processing. (hoist_memory_references): Pass down whether all edges have ordered processing for a ref to execute_sm. * gcc.dg/torture/pr95172.c: New testcase.
[Bug tree-optimization/57359] store motion causes wrong code for union access at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57359 Bug 57359 depends on bug 95172, which changed state. Bug 95172 Summary: [11 Regression] wrong code at -O1 on x86_64-linux-gnu since r11-272-gb6ff3ddecfa93d53 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95172 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug target/94962] Suboptimal AVX2 code for _mm256_zextsi128_si256(_mm_set1_epi8(-1))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94962 --- Comment #3 from Hongtao.liu --- You're right, from intel SDM: VEX.128 encoded version: Bits (MAXVL-1:128) of the destination register are zeroed.
[Bug target/94962] Suboptimal AVX2 code for _mm256_zextsi128_si256(_mm_set1_epi8(-1))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94962 --- Comment #4 from Hongtao.liu --- (In reply to Jakub Jelinek from comment #2) > But such an instruction isn't always redundant, it really depends on what > the previous setter of the register did, whether the upper 128 bit of the > 256-bit register are already guaranteed to be zero or not. (define_insn "avx_vec_concat" [(set (match_operand:V_256_512 0 "register_operand" "=x,v,x,Yv") (vec_concat:V_256_512 (match_operand: 1 "nonimmediate_operand" "x,v,xm,vm") (match_operand: 2 "nonimm_or_0_operand" "xm,vm,C,C")))] define_insn "*_vinsert_0" [(set (match_operand:AVX512_VEC 0 "register_operand" "=v,x,Yv") (vec_merge:AVX512_VEC (match_operand:AVX512_VEC 1 "reg_or_0_operand" "v,C,C") (vec_duplicate:AVX512_VEC (match_operand: 2 "nonimmediate_operand" "vm,xm,vm")) (match_operand:SI 3 "const_int_operand" "n,n,n")))] Upper part already zeroed. > Thus the #c1 patch looks incorrect to me, one would need peephole2s or some > combine patterns or target specific pass etc. to discover that at least for > the common cases; and it isn't something we model in the RTL patterns (what > insns guarantee which upper bits zero and what do not; and for some there > can be different choices even in the same define_insn, we could implement > something using widened registers and then there would be no guarantee etc.).
[Bug tree-optimization/95171] ICE: verify_flow_info failed (error: wrong outgoing edge flags at end of bb 2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95171 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:fe168751c5c1c517c7c89c9a1e4e561d66b24663 commit r11-451-gfe168751c5c1c517c7c89c9a1e4e561d66b24663 Author: Richard Biener Date: Mon May 18 08:51:23 2020 +0200 middle-end/95171 - inlining of trapping compare into non-call EH fn This fixes always-inlining across -fnon-call-exception boundaries for conditions which we do not allow to throw. 2020-05-18 Richard Biener PR middle-end/95171 * tree-inline.c (remap_gimple_stmt): Split out trapping compares when inlining into a non-call EH function. * gcc.dg/pr95171.c: New testcase.
[Bug tree-optimization/95171] ICE: verify_flow_info failed (error: wrong outgoing edge flags at end of bb 2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95171 Richard Biener changed: What|Removed |Added Known to fail|11.0| Known to work||11.0 --- Comment #5 from Richard Biener --- Fixed on trunk sofar.
[Bug sanitizer/94910] detect_stack_use_after_return=1 is much slower than clang's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94910 --- Comment #6 from Jakub Jelinek --- (In reply to Martin Liška from comment #5) > > FakeStack (stack_size_log=20):bail out after 8192 > > FakeStack (stack_size_log=20):bail out after 16384 > > FakeStack (stack_size_log=20):bail out after 4096 > > FakeStack (stack_size_log=20):bail out after 8192 > > ... > > This comes after the 27000 success Fake stack allocations. I guess the important question is what is different with clang that it behaves differently, whether it allocates fake stack for fewer functions, or what else. E.g. try ltrace on it to see how many each one allocates and if it is very different, it would be nice to understand why.
[Bug tree-optimization/95185] New: Failure to optimize specific kind of sign comparison check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95185
Bug ID: 95185
Summary: Failure to optimize specific kind of sign comparison
check
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
int f(int x, int y)
{
return (x >= 0) == (y <= 0);
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94718 was resolved and most of the
patterns are now optimized, but this specific one isn't. It's equivalent to `(x
< 0) ^ (y <= 0)`, which can be done with a single compare instead of two. That
transformation is made by LLVM, but not by GCC.
[Bug preprocessor/95183] [11 Regression] ICE: Segmentation fault (in _cpp_lex_direct)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95183 Nathan Sidwell changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org
[Bug c++/95181] [10/11 Regression] ICE in push_access_scope, at cp/pt.c:241 since r10-3735-gcb57504a55015891
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95181
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #5 from Patrick Palka ---
Another testcase:
template class f {
template f();
template requires false f();
};
[Bug target/78838] msp430 option -mcode-region=either, -ffunction-sections, and interrupt function attributes cause incorrect section to be created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78838 jozefl at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED CC||jozefl at gcc dot gnu.org --- Comment #6 from jozefl at gcc dot gnu.org --- Fixed.
[Bug target/78554] Internal Compiler Error in msp430 target with -mlarge, -O{s123}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78554 jozefl at gcc dot gnu.org changed: What|Removed |Added CC||jozefl at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from jozefl at gcc dot gnu.org --- Fixed.
[Bug fortran/95186] New: Optimize allocate(..., source=0) or allocate(..., source=[0.0, 0.0, ...]) to use calloc instead of malloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95186 Bug ID: 95186 Summary: Optimize allocate(..., source=0) or allocate(..., source=[0.0, 0.0, ...]) to use calloc instead of malloc Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Target Milestone: --- calloc returns zeroed memory, hence, for "source=0.0" or "source=0" (or the array equivalent, if ever used), calloc instead of malloc could be used.
[Bug target/58507] Incorrect parsing of `-mmcu=msp430*`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58507 jozefl at gcc dot gnu.org changed: What|Removed |Added CC||jozefl at gcc dot gnu.org Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from jozefl at gcc dot gnu.org --- Fixed.
[Bug target/70320] msp430 asm volatile does not accept lower-case register names in clobber list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70320 jozefl at gcc dot gnu.org changed: What|Removed |Added CC||jozefl at gcc dot gnu.org Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from jozefl at gcc dot gnu.org --- Fixed since GCC 10.
[Bug tree-optimization/95185] Failure to optimize specific kind of sign comparison check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95185 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Keywords||easyhack, ||missed-optimization Last reconfirmed||2020-05-18 Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- Confirmed.
[Bug tree-optimization/95185] Failure to optimize specific kind of sign comparison check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95185 --- Comment #2 from Richard Biener --- Btw, thanks for all these bugreports!
[Bug tree-optimization/95187] New: Failure to optimize bool check into consecutive literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95187
Bug ID: 95187
Summary: Failure to optimize bool check into consecutive
literals
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
int f(bool b)
{
if (b)
return 1;
return 2;
}
This can be optimized into `2 - (int)b`. LLVM does this transformation, but GCC
does not.
[Bug d/92216] GDC generate duplicate symbols when mixins and interfaces are used to gather
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92216 --- Comment #6 from CVS Commits --- The releases/gcc-9 branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:3e84ee0fab9cedfa57fe86ea3c00608f6a873ab9 commit r9-8603-g3e84ee0fab9cedfa57fe86ea3c00608f6a873ab9 Author: Iain Buclaw Date: Mon Mar 16 23:04:49 2020 +0100 d: Fix multiple definition error when using mixins and interfaces. gcc/d/ChangeLog: PR d/92216 * decl.cc (make_thunk): Don't set TREE_PUBLIC on thunks if the target function is external to the current compilation. gcc/testsuite/ChangeLog: PR d/92216 * gdc.dg/imports/pr92216.d: New. * gdc.dg/pr92216.d: New test.
[Bug d/95184] GDC reporting multiple definitions of functions where DMD and LDC do not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95184 --- Comment #4 from Iain Buclaw --- Done in r9-8603.
[Bug c/95141] [8/9/10/11 Regression] Incorrect integer overflow warning message for bitand expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95141 --- Comment #3 from Richard Biener --- (In reply to Richard Biener from comment #2) > So there's already (OVF) at > > ((long unsigned int) IA1 & 158(OVF)) & 1 > > but we only check > > 375 if (TREE_OVERFLOW_P (ret) > 376 && !TREE_OVERFLOW_P (op0) > 377 && !TREE_OVERFLOW_P (op1)) > 378 overflow_warning (EXPR_LOC_OR_LOC (expr, input_location), > ret, expr); > > which doesn't catch the pre-existing overflow on op0 which then propagates. > > The original overflow is introduced folding short 158 to signed char -98(OVF) > via convert.c:do_narrow: > > 437 /* We should do away with all this once we have a proper > 438 type promotion/demotion pass, see PR45397. */ > 439 expr = maybe_fold_build2_loc (dofold, loc, ex_form, typex, > 440 convert (typex, arg0), > 441 convert (typex, arg1)); > > specifically the convert (typex, arg1). > > Now TREE_OVERFLOW in general is quite a fragile thing, but it's tempting to > adjust the overflow_warning guard for this case ... > > The do_narrow code also specifically looks for overflow cases that matter > and does not perform narrowing then so clearing TREE_OVERFLOW there would > also look reasonable. > > Thus like the following? Should be cheaper than adding walk_tree to the > diagnostic guard. > > diff --git a/gcc/convert.c b/gcc/convert.c > index 42509c518a9..ed00ded1a89 100644 > --- a/gcc/convert.c > +++ b/gcc/convert.c > @@ -436,9 +436,16 @@ do_narrow (location_t loc, > } >/* We should do away with all this once we have a proper > type promotion/demotion pass, see PR45397. */ > + /* Above we checked for all cases where overflow matters, avoid > +geneating overflowed constants here which otherwise propagate > +and cause spurious warnings, see PR95141. */ > + tree converted_arg1 = convert (typex, arg1); > + if (TREE_OVERFLOW_P (converted_arg1) > + && !TREE_OVERFLOW_P (arg1)) > + converted_arg1 = drop_tree_overflow (converted_arg1); >expr = maybe_fold_build2_loc (dofold, loc, ex_form, typex, > convert (typex, arg0), > - convert (typex, arg1)); > + converted_arg1); >return convert (type, expr); > } Regresses FAIL: gcc.dg/overflow-warn-5.c (test for warnings, line 6) which looks like a useful warning to preserve. Lame "walk-tree" variant catching this case: diff --git a/gcc/c/c-fold.c b/gcc/c/c-fold.c index 63becfeaf2c..bd21d247051 100644 --- a/gcc/c/c-fold.c +++ b/gcc/c/c-fold.c @@ -374,6 +374,7 @@ c_fully_fold_internal (tree expr, bool in_init, bool *maybe_const_operands, ret = fold (expr); if (TREE_OVERFLOW_P (ret) && !TREE_OVERFLOW_P (op0) + && !(BINARY_CLASS_P (op0) && TREE_OVERFLOW_P (TREE_OPERAND (op0, 1))) && !TREE_OVERFLOW_P (op1)) overflow_warning (EXPR_LOC_OR_LOC (expr, input_location), ret, expr); if (code == LSHIFT_EXPR
[Bug analyzer/95188] New: analyzer-unsafe-call-within-signal-handler shows wrong statement for signal registration event
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95188 Bug ID: 95188 Summary: analyzer-unsafe-call-within-signal-handler shows wrong statement for signal registration event Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: mark at gcc dot gnu.org Target Milestone: --- Reproducer: wget https://sourceware.org/ftp/bzip2/bzip2-1.0.8.tar.gz tar zxf bzip2-1.0.8.tar.gz cd bzip2-1.0.8/ gcc -g -O2 -fanalyzer -c bzip2.c In function ‘showFileNames.part.0’: bzip2.c:677:4: warning: call to ‘fprintf’ from within signal handler [CWE-479] [-Wanalyzer-unsafe-call-within-signal-handler] 677 |fprintf ( |^ 678 | stderr, | ~~~ 679 | "\tInput file = %s, output file = %s\n", | 680 | inName, outName | ~~~ 681 |); |~ ‘main’: events 1-2 | | 1776 | IntNative main ( IntNative argc, Char *argv[] ) | | ^~~~ | | | | | (1) entry to ‘main’ |.. | 1792 |smallMode = False; | |~ | || | |(2) registering ‘mySIGSEGVorSIGBUScatcher’ as signal handler | event 3 | |cc1: | (3): later on, when the signal is delivered to the process | +--> ‘mySIGSEGVorSIGBUScatcher’: events 4-5 | | 676 |if (noisy) | | ~ | | | | | (5) following ‘true’ branch... |.. | 816 | void mySIGSEGVorSIGBUScatcher ( IntNative n ) | | ^~~~ | | | | | (4) entry to ‘mySIGSEGVorSIGBUScatcher’ | ‘mySIGSEGVorSIGBUScatcher’: event 6 | |cc1: | (6): ...to here | ‘mySIGSEGVorSIGBUScatcher’: event 7 | |cc1: | (7): calling ‘showFileNames.part.0’ from ‘mySIGSEGVorSIGBUScatcher’ | +--> ‘showFileNames.part.0’: events 8-9 | | 674 | void showFileNames ( void ) | | ^ | | | | | (8) entry to ‘showFileNames.part.0’ |.. | 677 |fprintf ( | |~ | || | |(9) call to ‘fprintf’ from within signal handler | 678 | stderr, | | ~~~ | 679 | "\tInput file = %s, output file = %s\n", | | | 680 | inName, outName | | ~~~ | 681 |); | |~ | Note that the signal handler registration points to the wrong instruction: | 1792 |smallMode = False; | |~ | || | |(2) registering ‘mySIGSEGVorSIGBUScatcher’ as signal handler A workaround is to add -fanalyzer-fine-grained, then it does show to correct signal registration event: | 1808 |signal (SIGSEGV, mySIGSEGVorSIGBUScatcher); | |~~ | || | |(2) registering ‘mySIGSEGVorSIGBUScatcher’ as signal handler
[Bug c/95189] New: memcmp being wrongly stripped (regression)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189
Bug ID: 95189
Summary: memcmp being wrongly stripped (regression)
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at pkh dot me
Target Milestone: ---
Given the following C code:
% cat a.c
#include
static const float z[1] = {0};
int f(float x) { return memcmp(&x, z, sizeof(x)); }
GCC 10 generates this on x86-64:
% gcc -Wall -O2 -c a.c && objdump -d -Mintel a.o
a.o: file format elf64-x86-64
Disassembly of section .text:
:
0: f3 0f 11 44 24 fc movss DWORD PTR [rsp-0x4],xmm0
6: 0f b6 44 24 fc movzx eax,BYTE PTR [rsp-0x4]
b: c3 ret
This doesn't happen if "= {0}" is removed from the z initialization (wtf?).
It also doesn't happen with -O1.
[Bug c++/95190] New: Documentation for -Wstringop-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95190 Bug ID: 95190 Summary: Documentation for -Wstringop-overflow Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: stayprivate at gmail dot com Target Milestone: --- I'm compiling code with 10.1 for the first time. I'm getting a warning: "writing 1 bytes into a region of size 0 -Wstringop-overflow=". Yet -Wno-stringop-overflow is passed to the compiler. I tried disabling the warning with #pragma diagnostic, no luck there. Then I realized the error came from the link stage. Surely related to lto. I modified my cmake files to add the -Wno-stringop-overflow to the link command line and the warning disappear. I'm surprise by this behavior. I looked through the documentation and could not find anything that mentionned this. Is this something that is worth improving in the documentation or do I just need to get smarter ;-)
[Bug fortran/94925] Undesired runtime warning message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94925 --- Comment #4 from Fred Krogh --- Before submitting this I tried to make a small test case to show the problem. It did not show the problem. I was hoping that the fact that the message just started and there were no options that would turn it off would be sufficient. Sorry.
[Bug d/95174] [D] Incorrect compiled functions involving const fixed size arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95174
Iain Buclaw changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Iain Buclaw ---
(In reply to Witold Baryluk from comment #0)
> https://explore.dgnu.org/z/LppySp
>
>
[--snip--]
>
> Is incorrectly compiled to 'nop; ret'
>
It is correct, all those functions do nothing. What you're missing is a 'ref'
or 'out' storage class on the 'o' parameter.
Rationale, static arrays are value types in D (they don't saturate to pointers
like in C).
See https://dlang.org/spec/arrays.html#static-arrays
>
> As a bonus:
>
> ```
> void f(immutable(float[4]) x, float[4] o) {
>o[2] = x[1] + x[3];
> }
>
> import std.stdio : writeln;
>
> void main() {
> immutable(float[4]) k = [7.0f, 5.3f, 1.2f, 3.2f];
> float[4] o;
> f(k, o);
> writeln(o);
> }
>
> ```
>
> prints '[nan, nan, nan, nan]', but it should: '[nan, nan, 8.5, nan]'.
>
>
All NaNs is the correct result here too.
[Bug d/95120] [D] Incorrectly allows fqdn access to imported symbols when doing selective imports.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95120 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Iain Buclaw --- (In reply to Witold Baryluk from comment #0) > Created attachment 48529 [details] > Example of incorrectly accepted d source by gdc-10 > > gdc does violatate D language spec: > > https://dlang.org/spec/module.html#selective_imports > This bug (upstream http://issues.dlang.org/show_bug.cgi?id=313) was first deprecated in 2.070, then made an error in 2.083, The upstream front-end merged in gdc is based off 2.076. Please compile with -Wdeprecated.
[Bug preprocessor/95183] [11 Regression] ICE: Segmentation fault (in _cpp_lex_direct)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95183 --- Comment #2 from Nathan Sidwell --- This is a bug, but you're running a --traditional C preprocessor test through the c++ compiler, right? (A regular test run doesn't fail this test for me at least)
[Bug preprocessor/95183] [11 Regression] ICE: Segmentation fault (in _cpp_lex_direct)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95183 --- Comment #3 from Arseny Solokha --- (In reply to Nathan Sidwell from comment #2) > This is a bug, but you're running a --traditional C preprocessor test > through the c++ compiler, right? Through the C compiler, but otherwise yes. I've posted the compiler invocation in comment 0 verbatim. > (A regular test run doesn't fail this test > for me at least) Yep, because trad.exp adds -traditional-cpp, as intended. But I don't run the testsuite, but rather use its test cases as part of my larger test corpus, compiling every individual case in that corpus with randomly chosen compiler options. IOW, my testing ignores DejaGNU directives in gcc testsuite (which means it also often ignores common sense when choosing compiler options, as a consequence). I can further describe my setup if you are interested, but it's off-topic in this PR.
[Bug target/94962] Suboptimal AVX2 code for _mm256_zextsi128_si256(_mm_set1_epi8(-1))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94962 --- Comment #5 from Nemo --- (In reply to Jakub Jelinek from comment #2) I would be happy if GCC could just emit optimal code (single vcmpeqd instruction) for this useful constant: _mm256_set_m128i(_mm_setzero_si128(), _mm_set1_epi8(-1)) aka. _mm256_inserti128_si256(_mm256_setzero_si256(), _mm_set1_epi8(-1), 0) (The latter is just what GCC uses to implement _mm256_zextsi128_si256, if I am reading the headers correctly.) It's a minor thing, but I was a little surprised to find that none of the compilers I know of are able to do this. At least, not with any input I tried.
[Bug fortran/94109] Memory leak introduced in 8.3.0->8.3.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109 --- Comment #4 from Antony Lewis --- Not sure why no one has at least picked up on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94361 since it is a reproducible regression with a simple test case, an a bug that effectively kills some previously-working code from 7.x updates onwards?
[Bug target/95169] [10/11 Regression] i386 comparison between nan and 0.0 triggers Invalid operation exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95169 --- Comment #7 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:8f17461bdfeed758f2be71529fc3af55a76ea3e1 commit r11-457-g8f17461bdfeed758f2be71529fc3af55a76ea3e1 Author: Uros Bizjak Date: Mon May 18 17:52:14 2020 +0200 i386: Avoid reversing a non-trapping comparison to a trapping one [PR95169] gcc/ChangeLog: PR target/95169 * config/i386/i386-expand.c (ix86_expand_int_movcc): Avoid reversing a non-trapping comparison to a trapping one. testsuite/ChangeLog: PR target/95169 * gcc.target/i386/pr95169.c: New test.
[Bug fortran/95191] New: Hang in WAIT with a bad ID= value if threading specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95191 Bug ID: 95191 Summary: Hang in WAIT with a bad ID= value if threading specified Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: longb at cray dot com Target Milestone: --- > cat test.f90 program test real a(1) integer my_id integer bad_id data my_id /1/ data bad_id /2/ a = 1. open (unit=10, file='test.dat', form='unformatted', & &asynchronous='yes') write (unit=10, asynchronous='yes', id=my_id) a wait (unit=10, id=bad_id) close (unit=10, status='delete') end program test If there are no command line options for the compile, there is no issue. However, if -fopenmp is added (or -lpthreads is added for the link), then the code hangs. > gfortran test.f90 > ./a.out > gfortran -fopenmp test.f90 > ./a.out ^C <<<-- hangs here. > gfortran --version GNU Fortran (GCC) 9.3.0 20200312 (Cray Inc.) Copyright (C) 2019 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. Original submitter says it hangs here: hang in __gthread_cond_wait.
[Bug lto/95190] Documentation for -Wstringop-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95190 Martin Sebor changed: What|Removed |Added Last reconfirmed||2020-05-18 Status|UNCONFIRMED |WAITING Component|c++ |lto Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org, ||msebor at gcc dot gnu.org Keywords||documentation --- Comment #1 from Martin Sebor --- Which part do you find surprising? That the warning is issued during the LTO stage at all or that -Wno-stringop-overflow can be used during the LTO stage to suppress it? During LTO the same compiler options should be implicitly enabled as during ordinary compilation, including warnings. (This presents some challenges when the compilation was done with different options for different files.) It also means that all the same warnings should be expected to be implicitly enabled during LTO that were explicitly enabled during the compilation stage. I'd expect to see only "late" warnings during LTO, i.e., those that depend on optimization. (I understand this doesn't work completely consistently yet but I believe that's the goal.) So this effect isn't specific to -Wstringop-overflow, but perhaps it would be worth mentioning under -flto?
[Bug target/94833] vec_first_match_index does not function as described in its description
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94833 --- Comment #3 from CVS Commits --- The master branch has been updated by Carl Love : https://gcc.gnu.org/g:24f68831d25bad739a6fe167a58b5b4c0c3cbf9a commit r11-458-g24f68831d25bad739a6fe167a58b5b4c0c3cbf9a Author: Carl Love Date: Wed Apr 29 10:23:11 2020 -0500 pr94833, fix vec_first_match_index for nulls gcc/ChangeLog 2020-04-30 Carl Love PR target/94833 * config/rs6000/vsx.md (define_expand): Fix instruction generation for first_match_index_. * testsuite/gcc.target/powerpc/builtins-8-p9-runnable.c (main): Add additional test cases with zero vector elements.
[Bug c++/95143] SFINAE failure with static_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95143 --- Comment #13 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:be464161b4ae128681958d94aa460531cf30e0a4 commit r11-459-gbe464161b4ae128681958d94aa460531cf30e0a4 Author: Marek Polacek Date: Mon May 18 13:50:39 2020 -0400 c++: Add test for c++/95143 Already fixed by r10-8124-gceae6a13366d9646e172fc943fe8e221b70f0920. PR c++/95143 * g++.dg/cpp0x/sfinae66.C: New test.
[Bug tree-optimization/94952] Possible false positive of uninitialized variable usage during release build in gimple-ssa-store-merging.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94952 --- Comment #1 from CVS Commits --- The master branch has been updated by Stefan Schulze Frielinghaus : https://gcc.gnu.org/g:2c832ffedf06ff614fc36c44ab6c892d84075e08 commit r11-460-g2c832ffedf06ff614fc36c44ab6c892d84075e08 Author: Stefan Schulze Frielinghaus Date: Tue May 5 19:44:19 2020 +0200 tree-optimization: Fix use of uninitialized variables warnings [PR94952] While bootstrapping GCC on S/390 with --enable-checking=release several warnings about use of uninitialized variables bitpos, bitregion_start, and bitregion_end of function pass_store_merging::process_store are raised. According to PR94952 these seem to be false positives which are silenced by initialising the mentioned variables. Bootstrapped on S/390. Ok for master and releases/gcc-10 assuming that regtest succeeds (still running but I don't see a reason why it should fail)? gcc/ChangeLog: 2020-05-18 Stefan Schulze Frielinghaus PR tree-optimization/94952 * gimple-ssa-store-merging.c (pass_store_merging::process_store): Initialize variables bitpos, bitregion_start, and bitregion_end in order to silence warnings about use of uninitialized variables.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 94952, which changed state. Bug 94952 Summary: Possible false positive of uninitialized variable usage during release build in gimple-ssa-store-merging.c https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94952 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/94952] Possible false positive of uninitialized variable usage during release build in gimple-ssa-store-merging.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94952 Stefan Schulze Frielinghaus changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Stefan Schulze Frielinghaus --- Closing as fixed by 2c832ffedf0
[Bug fortran/95053] [11 regression] ICE in f951: gfc_divide()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053 --- Comment #29 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:e5abd1cb9160619721336ed800779a01548231f1 commit r11-461-ge5abd1cb9160619721336ed800779a01548231f1 Author: Harald Anlauf Date: Mon May 18 20:27:29 2020 +0200 PR fortran/95053 - division by zero constants Partially revert the fix for PR93499. Replace by checks for valid expressions in the declaration of array shape and PDT KIND and LEN expressions at a later stage. gcc/fortran/ 2020-05-18 Harald Anlauf PR fortran/95053 * arith.c (gfc_divide): Revert hunk introduced by patch for PR93499. * decl.c (variable_decl): Generate error for array shape not being an INTEGER constant. (gfc_get_pdt_instance): Generate error if KIND or LEN expressions in declaration of a PDT instance do not simplify to INTEGER constants. gcc/testsuite/ 2020-05-18 Harald Anlauf PR fortran/95053 * gfortran.dg/dec_structure_23.f90: Adjust to new error messages. * gfortran.dg/pr93499.f90: Adjust to new error messages. * gfortran.dg/pr95053_2.f90: New test. * gfortran.dg/pr95053_3.f90: New test.
[Bug fortran/95191] Hang in WAIT with a bad ID= value if threading specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95191 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Priority|P3 |P4 CC||anlauf at gcc dot gnu.org Last reconfirmed||2020-05-18 Status|UNCONFIRMED |NEW --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed.
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 95053, which changed state. Bug 95053 Summary: [11 regression] ICE in f951: gfc_divide() https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug fortran/95053] [11 regression] ICE in f951: gfc_divide()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #30 from anlauf at gcc dot gnu.org --- Should be fixed now. Sorry for the breakage.
[Bug middle-end/95021] [10/11 Regression] Bogus -Wclobbered warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95021 Rainer Orth changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #11 from Rainer Orth --- Two of the new tests FAIL on 32-bit Solaris/x86: +FAIL: gcc.target/i386/pr95021-1.c scan-assembler movq[ \\t]%xmm[0-9]+, (%esp) +FAIL: gcc.target/i386/pr95021-3.c scan-assembler movq[ \\t]+[^\\n]*, %xmm
[Bug fortran/94361] Memory leak in nested types with final
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94361 anlauf at gcc dot gnu.org changed: What|Removed |Added Known to fail||10.1.1, 11.0, 7.4.1, 8.2.1, ||8.3.1, 9.3.1 Summary|Regression: Memory leak in |Memory leak in nested types |nested types with final |with final Last reconfirmed||2020-05-18 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||anlauf at gcc dot gnu.org --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed regarding the memory leak. Cannot confirm as regression. My 8.2.1 (OpenSuse) leaks the same as other versions according to valgrind. Regression marker therefore removed.
[Bug fortran/94361] Memory leak in nested types with final
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94361 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P4
[Bug c++/95192] New: [11 Regression] ICE: tree check: expected tree_list, have error_mark in handle_assume_aligned_attribute, at c-family/c-attribs.c:2996
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95192
Bug ID: 95192
Summary: [11 Regression] ICE: tree check: expected tree_list,
have error_mark in handle_assume_aligned_attribute, at
c-family/c-attribs.c:2996
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-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-alpha20200517 snapshot (g:2b9a271b2d0ba340234a138b7f8289bd7dca2fc5)
ICEs when compiling the following testcase, extracted from
test/SemaCXX/builtin-assume-aligned-tmpl.cpp from the clang 10.0.0 test suite:
template __attribute__((assume_aligned(sizeof(int(T()) T *f();
void test21() {
void *p = f()
}
% g++-11.0.0 -c iu1wkpbg.cpp
iu1wkpbg.cpp: In substitution of 'template T* f() [with T = void]':
iu1wkpbg.cpp:3:21: required from here
iu1wkpbg.cpp:1:75: internal compiler error: tree check: expected tree_list,
have error_mark in handle_assume_aligned_attribute, at
c-family/c-attribs.c:2996
1 | template __attribute__((assume_aligned(sizeof(int(T())
T *f();
|
^
0x7c0c50 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/tree.c:9686
0x6af9db tree_check(tree_node*, char const*, int, char const*, tree_code)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/tree.h:3296
0x6af9db handle_assume_aligned_attribute
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/c-family/c-attribs.c:2996
0x6af9db handle_assume_aligned_attribute
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/c-family/c-attribs.c:2977
0xa96507 decl_attributes(tree_node**, tree_node*, int, tree_node*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/attribs.c:714
0x9236f7 cplus_decl_attributes(tree_node**, tree_node*, int)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/decl2.c:1598
0xa178f4 tsubst_function_decl
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/pt.c:13929
0xa0196f tsubst_decl
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/pt.c:14182
0xa11b19 instantiate_template_1
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/pt.c:20678
0xa2137c instantiate_template(tree_node*, tree_node*, int)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/pt.c:20735
0xa2137c fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/pt.c:21179
0x876223 add_template_candidate_real
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/call.c:3415
0x876cf6 add_template_candidate
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/call.c:3500
0x876cf6 add_candidates
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/call.c:5866
0x8771e7 add_candidates
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/call.c:4522
0x8771e7 perform_overload_resolution
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/call.c:4530
0x87eea5 build_new_function_call(tree_node*, vec**, int)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/call.c:4604
0xa3d1b4 finish_call_expr(tree_node*, vec**, bool,
bool, int)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/semantics.c:2675
0x9b3e51 cp_parser_postfix_expression
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/parser.c:7465
0x9958e9 cp_parser_binary_expression
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/parser.c:9559
[Bug c++/95063] [11 Regression] ICE in tsubst_decl, at cp/pt.c:14633
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95063 --- Comment #6 from Arseny Solokha --- Is there more work pending, or can this PR be closed?
[Bug c++/95192] [11 Regression] ICE: tree check: expected tree_list, have error_mark in handle_assume_aligned_attribute, at c-family/c-attribs.c:2996
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95192 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2020-05-18 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed. Started with r11-423-gcda6396a1b6e6bba2a3b0847931567c3458f2184
[Bug c++/95063] [11 Regression] ICE in tsubst_decl, at cp/pt.c:14633
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95063 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Fixed.
[Bug c++/95193] New: [11 Regression] ICE in tsubst_decl, at cp/pt.c:14624
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95193
Bug ID: 95193
Summary: [11 Regression] ICE in tsubst_decl, at cp/pt.c:14624
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-alpha20200517 snapshot (g:2b9a271b2d0ba340234a138b7f8289bd7dca2fc5)
ICEs when compiling the following testcase, extracted from
test/SemaCXX/cxx1z-lambda-star-this.cpp from the clang 10.0.0 test suite, w/
-std=c++17:
struct X {
void foo() const {
auto GL1 = [*this](auto a) {
};
GL1("abc");
}
};
% g++-11.0.0 -std=c++17 -c g5fztf1w.cpp
g5fztf1w.cpp: In instantiation of 'X::foo() const:: [with
auto:1 = const char*]':
g5fztf1w.cpp:6:14: required from here
g5fztf1w.cpp:3:30: internal compiler error: in tsubst_decl, at cp/pt.c:14624
3 | auto GL1 = [*this](auto a) {
| ^
0x662811 tsubst_decl
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/pt.c:14624
0x9fa006 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/pt.c:17921
0x9f8267 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/pt.c:18138
0x9f536a instantiate_decl(tree_node*, bool, bool)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/pt.c:25609
0x926d1a maybe_instantiate_decl
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/decl2.c:5377
0x929558 maybe_instantiate_decl
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/tree.h:3411
0x929558 mark_used(tree_node*, int)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/decl2.c:5573
0x87afa3 build_over_call
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/call.c:9077
0x87ff91 build_op_call_1
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/call.c:4883
0x87ff91 build_op_call(tree_node*, vec**, int)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/call.c:4912
0xa3d83e finish_call_expr(tree_node*, vec**, bool,
bool, int)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/semantics.c:2692
0x9b3e51 cp_parser_postfix_expression
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/parser.c:7465
0x9958e9 cp_parser_binary_expression
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/parser.c:9559
0x99759e cp_parser_assignment_expression
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/parser.c:9864
0x997963 cp_parser_expression
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/parser.c:10032
0x99a918 cp_parser_expression_statement
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/parser.c:11692
0x9a5f73 cp_parser_statement
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/parser.c:11488
0x9a7828 cp_parser_statement_seq_opt
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/parser.c:11839
0x9a7908 cp_parser_compound_statement
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/parser.c:11789
0x9bfcf5 cp_parser_function_body
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200517/work/gcc-11-20200517/gcc/cp/parser.c:23058
[Bug c++/95193] [11 Regression] ICE in tsubst_decl, at cp/pt.c:14624
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95193 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||jason at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Target Milestone|--- |11.0 Last reconfirmed||2020-05-18 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Started with r11-15-gbcbf334afe091ad7d0f5ffe164299f8730cf41d1
[Bug c++/87699] Implement CWG 1512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87699
--- Comment #7 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:ae8ed736addb2b005d54c0b3191ac599a04ec170
commit r11-467-gae8ed736addb2b005d54c0b3191ac599a04ec170
Author: Marek Polacek
Date: Wed May 13 15:52:42 2020 -0400
c++: Implement DR 1512, Pointer comparison vs qual convs [PR87699]
This patch resolves DR 1512 (and, by turn, DR 583). This entails:
1) Relational pointer comparisons against null pointer constants have
been made ill-formed:
void f(char *p) {
if (p > 0)
// ...
}
was always invalid in C but was -- accidentally -- allowed in C++.
2) This was ill-formed:
bool foo(int** x, const int** y) {
return x < y;
}
because 'int**' couldn't be converted to 'const int**'. This was
fixed by re-defining a generic composite pointer type. The composite
type of these two pointers will be 'const int *const *', to which
both pointers can be converted.
3) The overload descriptions for built-in operators were adjusted,
because objects of type std::nullptr_t cannot be used with relational
operators any more.
I fixed 1) by adjusting cp_build_binary_op; we already had a warning
for it so made it a hard error now.
Then 2) required tweaking composite_pointer_type_r. [expr.type] defines
the composite pointer type by using the "cv-combined type." We didn't
implement the [conv.qual]/3.3 part; previously the composite type of
'int**' and 'const int**' was 'const int**', so this didn't compile:
void f(const int **p, int **q) {
true ? p : q;
}
I wrote a more extensive test for this which uses decltype and some
template magic to check the composite type, see composite-ptr-type.C.
We still don't handle everything that [expr.type] requires us to,
but it's pretty close.
And finally 3) was handled in add_builtin_candidate. Turned out we
weren't creating built-in operator candidates when the type was
std::nullptr_t at all. We should, for == and !=. Tested in builtin4.C.
In passing, I'm fixing some of the comments too.
DR 1512
PR c++/87699
* call.c (add_builtin_candidate) : Create candidate
operator functions when type is std::nullptr_t for ==/!=.
* typeck.c (composite_pointer_type_r): Add bool a * parameter. Use
it
to maybe add "const" to the pointer type.
(composite_pointer_type): Update the call to
composite_pointer_type_r.
(cp_build_binary_op): Turn two warning_at into error_at. Print the
types.
* g++.dg/cpp0x/constexpr-array-ptr10.C: Change dg-warning to
dg-error
and adjust the expected messages in dg-error.
* g++.dg/expr/composite-ptr-type.C: New test.
* g++.dg/expr/ptr-comp1.C: New test.
* g++.dg/expr/ptr-comp2.C: New test.
* g++.dg/expr/ptr-comp3.C: New test.
* g++.dg/overload/builtin4.C: New test.
* g++.dg/warn/Wextra-3.C: Change dg-warning to dg-error.
[Bug c++/87699] Implement CWG 1512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87699 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Marek Polacek --- Implemented in GCC 11.
[Bug target/82261] x86: missing peephole for SHLD / SHRD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82261 Michael Clark changed: What|Removed |Added CC||michaeljclark at mac dot com --- Comment #2 from Michael Clark --- Just refreshing this issue. I found it while testing some code-gen on Godbolt: - https://godbolt.org/z/uXGxZ9 I noticed that Haswell code-gen uses SHRX/SHLX, but I think -Os and pre-Haswell would benefit from this peephole if it is not complex to add. Noting that Clang prefers SHLD / SHRD over the SHRX+SHLX pair no matter the -march flavor.
[Bug c++/95181] [10/11 Regression] ICE in push_access_scope, at cp/pt.c:241 since r10-3735-gcb57504a55015891
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95181 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #6 from Patrick Palka --- I will look into this.
[Bug middle-end/94940] [10/11 Regression] spurious -Warray-bounds for a zero length array member of union since r10-4300-g49fb45c81f4ac068
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94940 --- Comment #9 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:3956244c58acceebf1ef2cf9a63e99f0f82abcb7 commit r11-469-g3956244c58acceebf1ef2cf9a63e99f0f82abcb7 Author: Martin Sebor Date: Mon May 18 15:07:48 2020 -0600 PR middle-end/94940 - spurious -Warray-bounds for a zero length array member of union gcc/testsuite/ChangeLog: PR middle-end/94940 * gcc.dg/Warray-bounds-61.c: New test. gcc/ChangeLog: PR middle-end/94940 * tree-vrp.c (vrp_prop::check_mem_ref): Remove unreachable code. * tree.c (component_ref_size): Correct the handling or array members of unions. Drop a pointless test. Rename a local variable.
[Bug middle-end/92815] [8/9/10/11 Regression] spurious -Wstringop-overflow writing into a flexible array of an extern struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92815 --- Comment #6 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:7a41fcde6c67faafab8c8ee2a31140999383dcef commit r11-470-g7a41fcde6c67faafab8c8ee2a31140999383dcef Author: Martin Sebor Date: Mon May 18 15:24:12 2020 -0600 PR middle-end/92815 - spurious -Wstringop-overflow writing into a flexible array of an extern struct gcc/ChangeLog: PR middle-end/92815 * tree-object-size.c (decl_init_size): New function. (addr_object_size): Call it. * tree.h (last_field): Declare. (first_field): Add attribute nonnull. gcc/testsuite/ChangeLog: PR middle-end/92815 * gcc.dg/Warray-bounds-56.c: Remove xfails. * gcc.dg/builtin-object-size-20.c: New test. * gcc.dg/builtin-object-size-21.c: New test.
[Bug middle-end/92815] [8/9/10 Regression] spurious -Wstringop-overflow writing into a flexible array of an extern struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92815 Martin Sebor changed: What|Removed |Added Known to work||11.0 Summary|[8/9/10/11 Regression] |[8/9/10 Regression] |spurious|spurious |-Wstringop-overflow writing |-Wstringop-overflow writing |into a flexible array of an |into a flexible array of an |extern struct |extern struct --- Comment #7 from Martin Sebor --- Fixed on trunk for now.
[Bug fortran/94361] Memory leak in nested types with final
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94361 --- Comment #2 from Antony Lewis --- I tried it on another system where gfortran 6.5 and 7.4.0 that don't leak, but 8.4.0 does, so in that sense at least I think it is a regression.
[Bug middle-end/94940] [10 Regression] spurious -Warray-bounds for a zero length array member of union since r10-4300-g49fb45c81f4ac068
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94940 --- Comment #10 from CVS Commits --- The releases/gcc-10 branch has been updated by Martin Sebor : https://gcc.gnu.org/g:ff61c5bd1490a006c00bed9259dc672351eb217a commit r10-8154-gff61c5bd1490a006c00bed9259dc672351eb217a Author: Martin Sebor Date: Mon May 18 16:04:56 2020 -0600 PR middle-end/94940 - spurious -Warray-bounds for a zero length array member of union gcc/testsuite/ChangeLog: PR middle-end/94940 * gcc.dg/Warray-bounds-61.c: New test. gcc/ChangeLog: PR middle-end/94940 * tree-vrp.c (vrp_prop::check_mem_ref): Remove unreachable code. * tree.c (component_ref_size): Correct the handling or array members of unions. Drop a pointless test. Rename a local variable.
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 94940, which changed state. Bug 94940 Summary: [10 Regression] spurious -Warray-bounds for a zero length array member of union since r10-4300-g49fb45c81f4ac068 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94940 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/94940] [10 Regression] spurious -Warray-bounds for a zero length array member of union since r10-4300-g49fb45c81f4ac068
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94940 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Martin Sebor --- Fixed for GCC 11 and 10.2.
[Bug c++/90915] [9/10/11 Regression] ICE in has_attribute, at c-family/c-attribs.c:4221
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90915 --- Comment #6 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:5d2246a32c638e9caea109e5dd9f182f5cd43b2a commit r11-471-g5d2246a32c638e9caea109e5dd9f182f5cd43b2a Author: Marek Polacek Date: Thu May 7 21:10:42 2020 -0400 c++: Sorry about type-dependent arg for __builtin_has_attribute [PR90915] Until 92104 is fixed, let's sorry rather than crash. PR c++/90915 * parser.c (cp_parser_has_attribute_expression): Sorry on a type-dependent argument. * g++.dg/ext/builtin-has-attribute.C: New test.
[Bug c++/90915] [9/10 Regression] ICE in has_attribute, at c-family/c-attribs.c:4221
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90915 Marek Polacek changed: What|Removed |Added Summary|[9/10/11 Regression] ICE in |[9/10 Regression] ICE in |has_attribute, at |has_attribute, at |c-family/c-attribs.c:4221 |c-family/c-attribs.c:4221 Assignee|paolo.carlini at oracle dot com|mpolacek at gcc dot gnu.org --- Comment #7 from Marek Polacek --- Fixed on trunk. I'll also backport to 10.
[Bug middle-end/92815] [8/9/10 Regression] spurious -Wstringop-overflow writing into a flexible array of an extern struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92815 --- Comment #8 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:8edf0adb6616bd717312d9b305c7d7c9a6b7a171 commit r11-472-g8edf0adb6616bd717312d9b305c7d7c9a6b7a171 Author: Martin Sebor Date: Mon May 18 16:31:13 2020 -0600 PR middle-end/92815 - spurious -Wstringop-overflow writing into a flexible array of an extern struct Adjust test to avoid failures in ILP32 mode. gcc/testsuite/ChangeLog: PR middle-end/92815 * gcc.dg/builtin-object-size-20.c: Adjust to avoid failures in ILP32 mode.
[Bug lto/95194] New: bootstrap-lto fails on musl (bundled libintl uses asm aliases)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95194
Bug ID: 95194
Summary: bootstrap-lto fails on musl (bundled libintl uses asm
aliases)
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at inbox dot ru
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
Target Milestone: ---
The bug is originally reported by Andrew Savchenko as
https://bugs.gentoo.org/723370. There gcc's bootstrap-lto fails on musl libc.
It's slightly different from glibc as libintl relies on glibc-specific gettext
symbols like '_nl_msg_cat_cntr'.
The bug:
$ /var/tmp/portage/sys-devel/gcc-10.1.0/work/gcc-10.1.0/configure
--host=x86_64-gentoo-linux-musl --build=x86_64-gentoo-linux-musl --prefix=/usr
--bindir=/usr/x86_64-gentoo-linux-musl/gcc-bin/10.1.0
--includedir=/usr/lib/gcc/x86_64-gentoo-linux-musl/10.1.0/include
--datadir=/usr/share/gcc-data/x86_64-gentoo-linux-musl/10.1.0
--mandir=/usr/share/gcc-data/x86_64-gentoo-linux-musl/10.1.0/man
--infodir=/usr/share/gcc-data/x86_64-gentoo-linux-musl/10.1.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-gentoo-linux-musl/10.1.0/include/g++-v10
--with-python-dir=/share/gcc-data/x86_64-gentoo-linux-musl/10.1.0/python
--enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror
--with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion=Gentoo Hardened 10.1.0 p1 --enable-esp
--enable-libstdcxx-time --with-build-config=bootstrap-lto
--disable-libstdcxx-pch --enable-shared --enable-threads=posix
--enable-__cxa_atexit --disable-multilib --with-multilib-list=m64
--disable-altivec --disable-fixed-point --enable-targets=all --enable-libgomp
--disable-libmudflap --disable-libssp --disable-libada --disable-systemtap
--disable-vtable-verify --disable-libvtv --without-zstd --disable-libquadmath
--enable-lto --without-isl --disable-libsanitizer --enable-default-pie
--enable-default-ssp
$ make -j8 -l10 'LDFLAGS=-march=native -pipe
-Wl,-O1,--as-needed,--sort-common,-z,combreloc,-z,relro,-z,now,--relax,--hash-style=gnu'
STAGE1_CFLAGS= LIBPATH=/usr/lib/gcc/x86_64-gentoo-linux-musl/10.1.0
'BOOT_CFLAGS=-m64 -march=native -pipe -O2' bootstrap-lean
/var/tmp/portage/sys-devel/gcc-10.1.0/work/build/./prev-gcc/xg++
-B/var/tmp/portage/sys-devel/gcc-10.1.0/work/build/./prev-gcc/
-B/usr/x86_64-gentoo-linux-musl/bin/ -nostdinc++
-B/var/tmp/portage/sys-devel/gcc-10.1.0/work/build/prev-x86_64-gentoo-linux-musl/libstdc++-v3/src/.libs
-B/var/tmp/portage/sys-devel/gcc-10.1.0/work/build/prev-x86_64-gentoo-linux-musl/libstdc++-v3/libsupc++/.libs
-isystem
/var/tmp/portage/sys-devel/gcc-10.1.0/work/build/prev-x86_64-gentoo-linux-musl/libstdc++-v3/include/x86_64-gentoo-linux-musl
-isystem
/var/tmp/portage/sys-devel/gcc-10.1.0/work/build/prev-x86_64-gentoo-linux-musl/libstdc++-v3/include
-isystem
/var/tmp/portage/sys-devel/gcc-10.1.0/work/gcc-10.1.0/libstdc++-v3/libsupc++
-L/var/tmp/portage/sys-devel/gcc-10.1.0/work/build/prev-x86_64-gentoo-linux-musl/libstdc++-v3/src/.libs
-L/var/tmp/portage/sys-devel/gcc-10.1.0/work/build/prev-x86_64-gentoo-linux-musl/libstdc++-v3/libsupc++/.libs
-DEXTRA_OPTIONS -m64 -march=native -pipe -O2 -fno-checking -flto=jobserver
-frandom-seed=1 -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE
-static-libstdc++ -static-libgcc -no-pie -o build/genmatch \
build/genmatch.o ../libcpp/libcpp.a ../libiberty/libiberty.a build/errors.o
build/vec.o build/hash-table.o build/sort.o .././libiberty/libiberty.a
./../intl/libintl.a
...
/usr/x86_64-gentoo-linux-musl/bin/ld:
/var/tmp/portage/sys-devel/gcc-10.1.0/temp/genmatch.NlicMk.ltrans2.ltrans.o: in
function `main':
:(.text.startup+0x94ba): undefined reference to `libintl_dgettext'
/usr/x86_64-gentoo-linux-musl/bin/ld:
/var/tmp/portage/sys-devel/gcc-10.1.0/temp/genmatch.NlicMk.ltrans3.ltrans.o: in
function `cpp_diagnostic(cpp_reader*, cpp_diagnostic_level, cpp_warning_reason,
char const*, __va_list_tag (*) [1])':
:(.text+0x2732): undefined reference to `libintl_dgettext'
...
Mechanically it fails because 'libintl_dgettext' is decclared as an asm alias:
"""
extern char *dgettext (const char *__domainname, const char *__msgid)
__asm__ ("" "libintl_dgettext")
__attribute__ ((__format_arg__ (2)));
$ ../prev-gcc/lto-dump -list errors.o | fgrep dgettext
function default 0 *libintl_dgettext
$ ../prev-gcc/lto-dump -demangle -list errors.o | fgrep dgettext
function default 0 dgettext
"""
I'm not sure if gcc should be able to link such
[Bug lto/95194] bootstrap-lto fails on musl (bundled libintl uses asm aliases)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95194 --- Comment #1 from Sergei Trofimovich --- https://gcc.gnu.org/PR48200 touches on why asm aliases are problematic.
[Bug fortran/95195] New: gfortran poorly handles a program error of writing a namelist to an unformatted file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95195 Bug ID: 95195 Summary: gfortran poorly handles a program error of writing a namelist to an unformatted file. Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: longb at cray dot com Target Milestone: --- gfortran poorly handles a program error of writing a namelist to an unformatted file. > cat test.f90 program test character(len=16) my_form character(len=240) msg data my_form /'unformatted'/ namelist /nml1/ i, j, k i = 1; j = 2; k = 3 open (unit=10, file='test.dat') write (10, nml=nml1) close (10) open (unit=10, file='test.dat', form=my_form) read (unit=10, nml=nml1) close (unit=10, status='delete') end program test > gfortran test.f90 > ./a.out Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7fadb087459f in ??? #1 0x7fadb15bf69e in fbuf_getc at ../../../cray-gcc-9.3.0-202003310324.b29d417121fbe/libgfortran/io/fbuf.h:78 #2 0x7fadb15bf69e in next_char_default at ../../../cray-gcc-9.3.0-202003310324.b29d417121fbe/libgfortran/io/list_read.c:215 #3 0x7fadb15bf69e in next_char_default at ../../../cray-gcc-9.3.0-202003310324.b29d417121fbe/libgfortran/io/list_read.c:207 #4 0x7fadb15c8db7 in finalize_transfer at ../../../cray-gcc-9.3.0-202003310324.b29d417121fbe/libgfortran/io/transfer.c:4109 #5 0x400bf7 in ??? #6 0x400c7c in ??? #7 0x7fadb085f349 in ??? #8 0x400779 in ??? at ../sysdeps/x86_64/start.S:120 #9 0x in ??? Segmentation fault (core dumped) > gfortran --version GNU Fortran (GCC) 9.3.0 20200312 (Cray Inc.) Copyright (C) 2019 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. A diagnostic message along the lines of the Cray or Intel compilers is preferred: > module swap PrgEnv-gnu PrgEnv-cray > ftn test.f90 > ./a.out lib-4080 : UNRECOVERABLE library error A formatted read or write is not allowed on an unformatted file. Encountered during a namelist READ from unit 10 Fortran unit 10 is connected to a sequential unformatted file: "test.dat" Aborted (core dumped) > module swap PrgEnv-cray PrgEnv-intel > ifort test.f90 > ./a.out forrtl: severe (257): formatted I/O to unit open for unformatted transfers, unit 10, file //test.dat Image PC Routine Line Source a.out 0040546B Unknown Unknown Unknown a.out 0041EF5E Unknown Unknown Unknown a.out 00402C31 Unknown Unknown Unknown a.out 00402A12 Unknown Unknown Unknown libc-2.26.so 7FC2FABAF34A __libc_start_main Unknown Unknown a.out 0040292A Unknown Unknown Unknown
[Bug c++/94937] [10/11 Regression] ICE with if constexpr (in cp_get_fndecl_from_callee, at cp/cvt.c:1000) since r10-2835-g14da3939da3adcef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94937 --- Comment #19 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:bf732686c0b9c42a2fe119db774c5a65e5a97174 commit r11-473-gbf732686c0b9c42a2fe119db774c5a65e5a97174 Author: Marek Polacek Date: Wed May 6 19:24:58 2020 -0400 c++: ICE with -Wall and constexpr if [PR94937] An ICE arises here because we call cp_get_callee_fndecl_nofold in a template, and we've got a CALL_EXPR whose CALL_EXPR_FN is a BASELINK. This tickles the INDIRECT_TYPE_P assert in cp_get_fndecl_from_callee. Fixed by turning the assert into a condition and returning NULL_TREE in that case. PR c++/94937 * cvt.c (cp_get_fndecl_from_callee): Return NULL_TREE if the function type is not INDIRECT_TYPE_P. * decl.c (omp_declare_variant_finalize_one): Call cp_get_callee_fndecl_nofold instead of looking for the function decl manually. * g++.dg/cpp1z/constexpr-if34.C: New test. * g++.dg/cpp2a/is-constant-evaluated10.C: New test.
[Bug c++/94937] [10 Regression] ICE with if constexpr (in cp_get_fndecl_from_callee, at cp/cvt.c:1000) since r10-2835-g14da3939da3adcef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94937 Marek Polacek changed: What|Removed |Added Summary|[10/11 Regression] ICE with |[10 Regression] ICE with if |if constexpr (in|constexpr (in |cp_get_fndecl_from_callee, |cp_get_fndecl_from_callee, |at cp/cvt.c:1000) since |at cp/cvt.c:1000) since |r10-2835-g14da3939da3adcef |r10-2835-g14da3939da3adcef --- Comment #20 from Marek Polacek --- Fixed on trunk so far.
[Bug c++/94955] [10/11 Regression] ICE in to_wide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94955 --- Comment #6 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:2d4e1e144c25e526e4f668be5a0bc10d0c1c738c commit r11-474-g2d4e1e144c25e526e4f668be5a0bc10d0c1c738c Author: Marek Polacek Date: Wed May 6 15:53:33 2020 -0400 c++: ICE when shortening right shift [PR94955] Since r10-6527 fold_for_warn calls maybe_constant_value, which means it can fold more than it previously could. In this testcase it means that cp_build_binary_op/RSHIFT_EXPR set short_shift because now we were able to fold op1 to an INTEGER_CST. But then when actually performing the shortening we crashed because cp_fold_rvalue wasn't able to fold as much as f_f_w and so tree_int_cst_sgn crashed on a NOP_EXPR. Therefore the calls should probably match. PR c++/94955 * typeck.c (cp_build_binary_op): Use fold_for_warn instead of cp_fold_rvalue. * g++.dg/cpp0x/constexpr-shift2.C: New test.
[Bug c++/94955] [10 Regression] ICE in to_wide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94955 Marek Polacek changed: What|Removed |Added Summary|[10/11 Regression] ICE in |[10 Regression] ICE in |to_wide |to_wide --- Comment #7 from Marek Polacek --- Fixed on trunk so far.
[Bug fortran/95196] New: Assumed-rank incorrect array bounds inside select rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95196 Bug ID: 95196 Summary: Assumed-rank incorrect array bounds inside select rank Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 48557 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48557&action=edit Fortran code demonstrating problems. Hi all! Assumed-rank array has incorrect array bounds inside select rank clauses. Probably related to Bug 94289. Seen with: GNU Fortran (GCC) 10.1.1 20200513 GNU Fortran (GCC) 11.0.0 20200513 (experimental) Thank you very much. Best regards, José Rui
[Bug c++/12341] Request for additional warning for variable shadowing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12341 Martin Sebor changed: What|Removed |Added Blocks||87403 Last reconfirmed|2005-12-11 23:28:15 |2020-5-18 CC||msebor at gcc dot gnu.org --- Comment #3 from Martin Sebor --- Reconfirming with GCC 11.0. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 [Bug 87403] [Meta-bug] Issues that suggest a new warning
[Bug c++/95175] [9/10/11 Regression] constexpr and alias template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95175 Marek Polacek changed: What|Removed |Added Keywords||rejects-valid Priority|P3 |P2 Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW Summary|constexpr and alias |[9/10/11 Regression] |template|constexpr and alias ||template Target Milestone|--- |9.4 Last reconfirmed||2020-05-18 --- Comment #1 from Marek Polacek --- Confirmed, we used to accept this. Started with r9-6136-g43574e4ff2afd4a2e47c179921a9b5661786ebf3
[Bug c/30368] missing warning for dereferencing null pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30368 Martin Sebor changed: What|Removed |Added Keywords||diagnostic CC||msebor at gcc dot gnu.org Last reconfirmed|2007-03-13 16:12:46 |2020-5-18 --- Comment #9 from Martin Sebor --- Missing warning reconfirmed with GCC 11. The last pass where the null pointer is still available is the CCP1 pass whose output shows that it removes it: $ gcc -O2 -S -Wall -Wextra -fdump-tree-ccp1-all=/dev/stdout pr30368.c ... Substituting values and folding statements Folding statement: _1 = &a_3->b; Folded into: _1 = 0B; Folding statement: if (_1 != 0B) ... So it should be possible to diagnose the dereference there, just prior to its removal.
