[Bug fortran/92587] [9/10/11 Regression] Compiler is unable to generate finalization wrapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92587 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED CC||burnus at gcc dot gnu.org Resolution|--- |FIXED --- Comment #16 from Tobias Burnus --- FIXED for (upcoming) GCC 11 and on the GCC 9 + 10 branches. Thanks for the report – and sorry for the long delay.
[Bug libgomp/98258] Can't compile programs for both OpenMP (CPU) + OpenACC (GPU)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98258 --- Comment #8 from Alexander Monakov --- (In reply to Chinoune from comment #7) > $ gfortran-10 -O3 -fopenmp -fopenacc -c bug_omp_acc.f90 > $ gfortran-10 bug_omp_acc.o -lgomp -o test.x Contrary to my suggestion, you have omitted -fopenacc from the second command line, why?
[Bug libstdc++/98473] std::vector::insert(pos, first, last) doesn't compile for T which has a deleted assignment operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98473 --- Comment #3 from Borislav Stanimirov --- By the way, this is not just some esoteric synthetic example. A type which is copy-constructible but not copy-assignable is very useful to model immutable objects.
[Bug c++/98523] New: Bug with class static definition and non-type template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98523
Bug ID: 98523
Summary: Bug with class static definition and non-type template
parameters
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eldlistmailingz at tropicsoft dot com
Target Milestone: ---
The code, as test_predicate.cpp:
template < typename T, T *d > class atmp { atmp() {} };
template < typename T > struct ast
{
static T avar;
static atmp acst;
};
template < typename T > T ast::avar;
template < typename T > atmp::avar> ast::acst;
int main()
{
return 0;
}
The command line:
"/usr/bin/g++" -fvisibility-inlines-hidden -fPIC -m64 -pthread -O0
-fno-inline -Wall -g -fvisibility=hidden -std=c++11 -c -o "test_predicate.o"
"test_predicate.cpp"
The result:
test_predicate.cpp:10:47: error: conflicting declaration ‘atmp::avar)> ast::acst’
10 | template < typename T > atmp::avar> ast::acst;
| ^~
test_predicate.cpp:6:26: note: previous declaration as ‘atmp::avar)> ast::acst’
6 | static atmp acst;
| ^~~~
The code compiles successfully with clang-11.0 and with VC++ 14.2 on Windows.
[Bug libgomp/98258] Can't compile programs for both OpenMP (CPU) + OpenACC (GPU)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98258 --- Comment #7 from Chinoune --- $ gfortran -O3 -fopenmp -fopenacc -foffload=-fno-openmp bug_omp_acc.f90 -o test.x mkoffload: fatal error: either '-fopenacc' or '-fopenmp' must be set compilation terminated. lto-wrapper: fatal error: /usr/lib/gcc/x86_64-linux-gnu/9//accel/nvptx-none/mkoffload returned 1 exit status compilation terminated. /usr/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status $ gfortran-10 -O3 -fopenmp -fopenacc -foffload=-fno-openmp bug_omp_acc.f90 -o test.x mkoffload: fatal error: either '-fopenacc' or '-fopenmp' must be set compilation terminated. lto-wrapper: fatal error: /usr/lib/gcc/x86_64-linux-gnu/10//accel/nvptx-none/mkoffload returned 1 exit status compilation terminated. /usr/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status $ gfortran-10 -O3 -fopenmp -fopenacc -c bug_omp_acc.f90 $ gfortran-10 bug_omp_acc.o -lgomp -o test.x mkoffload: fatal error: either '-fopenacc' or '-fopenmp' must be set compilation terminated. lto-wrapper: fatal error: /usr/lib/gcc/x86_64-linux-gnu/10//accel/nvptx-none/mkoffload returned 1 exit status compilation terminated. /usr/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status Please, stop suggesting untested workarounds.
[Bug tree-optimization/98365] Miss vectoization for signed char ifcvt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98365 --- Comment #2 from Hongtao.liu --- > cnt.1_7 = (unsigned char) cnt_21; > _8 = cnt.1_7 + 1; > cnt_16 = (char) _8; > cnt_9 = _3 == _6 ? cnt_16 : cnt_21; > In tree_if_conversion, there's is_cond_scalar_reduction, i'm think to extend the currect implementation to reduce bellow loop-header: cnt_21 = PHI <0, cnt_9> ... if (cond_expr) tmp1 = (unsigned type) cnt_21 tmp2 = tmp1 +/- rhs2 cnt_16 = (signed type) tmp2 cnt_9 = PHI to cnt_9 = PHI <0, cnt_21> tmp1 = (unsigned type)cnt_9; ifcvt = cond_expr ? rhs2 : 0 tmp2 = tmp1 +/- ifcvt; cnt_21 = (signed type)tmp2; I hope vectorizer reduction can handle the upper sequence.
[Bug tree-optimization/98365] Miss vectoization for signed char ifcvt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98365 --- Comment #1 from Hongtao.liu --- > Shouldn't cnt_21 = PHI , stmt relevant? > for stmt: cnt.1_7 = (unsigned char) cnt_21, the operand is defined by a previous iteration of the loop which is assumed to be handled in induction/reduction. But vect_analyze_scalar_cycles can't get reduction of cnt as (cnt_9 = _3 == _6 ? cnt_16 : cnt_21;_ since scalar evolution only handle - an SSA_NAME, - an INTEGER_CST, - a PLUS_EXPR, - a POINTER_PLUS_EXPR, - a MINUS_EXPR, - an ASSERT_EXPR, - other cases are not yet handled. */
[Bug libgomp/98258] Can't compile programs for both OpenMP (CPU) + OpenACC (GPU)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98258 --- Comment #6 from Chinoune --- There is no mention of "-foffload=-fno-openmp" on documentation https://gcc.gnu.org/wiki/Offloading#Compilation_options
[Bug c/89126] missing -Wtype-limits for int variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89126
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
--- Comment #4 from Kewen Lin ---
(In reply to Martin Sebor from comment #3)
> Eventually, after the function returns the inequality expression without a
> warning, c_parser_condition() calls c_fully_fold() on it which folds it into
> a constant, without a warning.
Happened to notice this PR when trying to answer the question [1]. The part
doing the folding is from match.pd.
/* Non-equality compare simplifications from fold_binary */
(for cmp (lt gt le ge)
/* Comparisons with the highest or lowest possible integer of
the specified precision will have known values. */
(simplify
(cmp (convert?@2 @0) uniform_integer_cst_p@1)
...
(if (wi::to_wide (cst) == max)
(switch
(if (cmp == GT_EXPR)
{ constant_boolean_node (false, type); })
(if (cmp == GE_EXPR)
(eq @2 @1))
(if (cmp == LE_EXPR)
{ constant_boolean_node (true, type); })
I noticed there are some warning support in match.pd like
fold_overflow_warning. Not sure whether we can add the similar supports there.
Probably hard to get LOC?
[1] https://gcc.gnu.org/pipermail/gcc-help/2021-January/139755.html
[Bug target/95381] [11 Regression]: Build fails with --disable-bootstrap on m68k with ICE: in operator[], at vec.h:867
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95381 Jeffrey A. Law changed: What|Removed |Added Status|WAITING |NEW --- Comment #16 from Jeffrey A. Law --- I've been able to reproduce this. It's either the enabling jit or host shared libraries (which is required to enable jit). It's faulting in the escaped string tests which makes sense given John's bisection info. I'm debugging in the background as this isn't anywhere near the top of my todo list.
[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519 --- Comment #9 from Michael Meissner --- I agree with Segher. Given the 'magic' we need to add the missing 'p' and set the length for normal RTL, I don't see any reasonable way to add it to asm. We will just need to use a hook (or make one) to make sure no PCREL addresses are passed to asm.
[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519 --- Comment #8 from Segher Boessenkool --- Yes, "m" can not allow PC-relative, in inline asm (just think of all existing code that uses "m").
[Bug target/98522] New: _mm_cvttps_pi32 and _mm_cvtps_pi32 raise spurious FP exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98522
Bug ID: 98522
Summary: _mm_cvttps_pi32 and _mm_cvtps_pi32 raise spurious FP
exceptions
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: foom at fuhm dot net
Target Milestone: ---
This is a regression due to the MMX in SSE work in GCC10. As far as I can tell,
it affects only these two functions.
Example test, which should return 0, but instead throws SIGFPE:
#pragma stdc fenv_access
#define _GNU_SOURCE
#include
#include
__attribute__((noinline)) __m64 test(__m128 a) {
return _mm_cvtt_ps2pi(a);
}
int main() {
feenableexcept(FE_INVALID);
__m128 x = (__m128)(__m128i){0xLL, 0x7fffLL};
volatile __m64 y = test(x);
}
In GCC 10 and trunk, the function test is compiled to:
cvttps2dq xmm0, xmm0
ret
which will convert the upper 64 bits as well as the lower 64 bits -- and
therefore raises FP exceptions accordingly. But, it ought to be ignoring the
upper 64bits.
[Bug target/98521] [x86] Missing/incorrect XOP functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98521 --- Comment #1 from Evan Nemerson --- Sorry, VS has two parametrs for _mm_frcz_ss and _mm_frcz_sd; clang is the outlier. So just the missing _mm256_cmov_si256.
[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519 --- Comment #7 from Steven Munroe --- Then you have problem as @pcrel is never valid for an instruction like lxsd%X1. Seems like you will need a new constrain or modifier specific to @pcrel.
[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519 --- Comment #6 from Segher Boessenkool --- You cannot look at the instruction, ever. The inline asm template is just text, nothing else. You cannot assume it is valid instructions.
[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519 --- Comment #5 from Steven Munroe --- I would think you need to look at the instruction and the "m" constraint. In this case lxsd%X1 would need to be converted to plxsd and the "m" constraint would have to allow @pcrel. I would think a static variable would be valid, but stack local or explicit pointer with (nonconst) offset/index would not.
[Bug target/98310] drivers/mtd/tests/subpagetest.c:426:1: error: could not split insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98310 --- Comment #3 from Rong Chen --- Created attachment 49880 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49880=edit kconfig file
[Bug target/98521] New: [x86] Missing/incorrect XOP functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98521 Bug ID: 98521 Summary: [x86] Missing/incorrect XOP functions Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: e...@coeus-group.com Target Milestone: --- _mm256_cmov_si256 is missing from xopintrin.h. It is present on clang and Visual Studio, and mentioned in AMD's documentation at https://developer.amd.com/wordpress/media/2012/10/New-Bulldozer-and-Piledriver-Instructions.pdf Additionally, _mm_frcz_ss and _mm_frcz_sd take two arguments in GCC's header but should only take one (as they do in clang and VS).
[Bug tree-optimization/98512] [11 Regression] “#pragma GCC diagnostic ignored” ineffective in conjunction with alias attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98512 Martin Sebor changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Martin Sebor --- Let me see what can be done about it.
[Bug tree-optimization/98512] [11 Regression] “#pragma GCC diagnostic ignored” ineffective in conjunction with alias attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98512 Martin Sebor changed: What|Removed |Added Known to fail||11.0 Status|UNCONFIRMED |NEW Summary|“#pragma GCC diagnostic |[11 Regression] “#pragma |ignored” ineffective in |GCC diagnostic ignored” |conjunction with alias |ineffective in conjunction |attribute |with alias attribute Last reconfirmed||2021-01-05 Ever confirmed|0 |1 Known to work||10.2.0 --- Comment #1 from Martin Sebor --- The warning looks for the location into which the memchr caller was inlined (to see if the caller is defined in a system header but itself called from user code). Without the alias it doesn't find one (because the caller isn't called from anywhere) but with the alias it finds the memchr caller, __rawmemchr_ppc.
[Bug analyzer/98293] [11 Regression] ICE in get_subregion_within_ctor, at analyzer/store.cc:494
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98293 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from David Malcolm --- Should be fixed by the above commit
[Bug analyzer/98293] [11 Regression] ICE in get_subregion_within_ctor, at analyzer/store.cc:494
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98293 --- Comment #3 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:15af33a88065f983181550fc53821f1c6e14c5c7 commit r11-6452-g15af33a88065f983181550fc53821f1c6e14c5c7 Author: David Malcolm Date: Mon Jan 4 19:20:32 2021 -0500 analyzer: fix ICE with -fsanitize=undefined [PR98293] -fsanitize=undefined with calls to nonnull functions creates struct __ubsan_nonnull_arg_data instances with CONSTRUCTORs for RECORD_TYPEs with NULL index values. The analyzer was mistakenly using INTEGER_CST for these fields, leading to ICEs. Fix the issue by iterating through the fields in the type for such cases, imitating similar logic in varasm.c's output_constructor. gcc/analyzer/ChangeLog: PR analyzer/98293 * store.cc (binding_map::apply_ctor_to_region): When "index" is NULL, iterate through the fields for RECORD_TYPEs, rather than creating an INTEGER_CST index. gcc/testsuite/ChangeLog: PR analyzer/98293 * gcc.dg/analyzer/pr98293.c: New test.
[Bug analyzer/98223] gcc.dg/analyzer/pr94851-1.c XPASSes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98223 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2021-01-05 --- Comment #1 from David Malcolm --- Thanks for filing this. I'm seeing it with x86_64-pc-linux-gnu. 1644d7f4c1c4f99231d7de5e35fa7ce2d2e2c4c6 builds and does not have the XPASS fcae5121154d1c3382b056bcc2c563cedac28e74 aka "Hybrid EVRP and testcases" builds and has the XPASS (the intervening commit (90e88fd376bb9ad6223a1f5ccd803d1bd9539b05 aka "Ranger classes doesn't build) Hence it looks like the hybrid EVRP range changed this testcase.
[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
--- Comment #4 from Segher Boessenkool ---
"m" is already handled differently for inline asm, so perhaps we can just
extend that? ("m" in machine descriptions is "m<>" in asm, for example).
[Bug c++/90799] noexcept specification dependent on template argument throws internal compiler error when trying to deduce it from a function argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90799 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #5 from Marek Polacek --- My patch for PR82099 fixes this one too.
[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519 --- Comment #3 from Peter Bergner --- (In reply to Michael Meissner from comment #2) > That fell off the plate. I imagine we are going to need a hook with asm > that makes sure none of the memory references are PC-relative. I guess since we cannot see which mnemonic is used in the inline asm, we have to be conservative and always reject pc-relative addresses with the "m" constraint (other constraints too?). Do we need to create a new memory constraint inline asm users can use to say pc-relative addresses are ok? How does x86 handle this?
[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519 --- Comment #2 from Michael Meissner --- That fell off the plate. I imagine we are going to need a hook with asm that makes sure none of the memory references are PC-relative.
[Bug fortran/78746] charlen_03, charlen_10 ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78746
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #21 from anlauf at gcc dot gnu.org ---
Potential fix:
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index fa6f756d285..891db391907 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -14384,7 +14396,7 @@ resolve_component (gfc_component *c, gfc_symbol *sym)
/* F2008, C448. */
if (c->ts.type == BT_CLASS)
{
- if (CLASS_DATA (c))
+ if (c->attr.class_ok && CLASS_DATA (c))
{
attr = &(CLASS_DATA (c)->attr);
At least valgrind is happy with that change.
[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 98503, which changed state. Bug 98503 Summary: [11 regression] -Warray-bounds false positive with global variables at -O2 since r11-3306-g3f9a497d1b0dd9da https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98503 What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |---
[Bug c/98503] [11 regression] -Warray-bounds false positive with global variables at -O2 since r11-3306-g3f9a497d1b0dd9da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98503
Willy Tarreau changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED|REOPENED
--- Comment #7 from Willy Tarreau ---
It's not easy because as often with optimizations, depending on the code moves
I'm doing, the issue appears and disappears. The closest looking one is below.
The general idea is that we're having a function that is called to dump a
certain number of elements to a buffer and return when the buffer is full, to
give back control to other parts of the code, then it's called again from the
last list element where the dump was started. A common practice with such
interruptible processing of list consists in starting from the head and letting
the dump function iterate. This would roughly look like this (still simplified
quite a bit to grasp the principle). The code below manages to trigger the
warning. If you're interested in the original code (I doubt it), it's on this
line: https://github.com/haproxy/haproxy/blob/master/src/ssl_sock.c#L6366 and
the initial call is made here:
https://github.com/haproxy/haproxy/blob/master/src/ssl_sock.c#L6437
#include
#define container_of(ptr, type, member) ({ \
void *__mptr = (void *)(ptr); \
((type *)(__mptr - __builtin_offsetof(type, member))); })
// returns number of bytes emitted or 0 if it failed to dump.
extern int try_dump_string(const char *name);
struct list {
struct list *n;
struct list *p;
};
static struct list head;
struct ref {
struct list list;
char *filename;
};
static struct ref *last_dumped;
/* try to dump one ref, returns 0 on failure */
static inline int try_dump_next_ref(struct ref *ref)
{
return try_dump_string(ref->filename);
}
static inline struct ref *get_initial_step()
{
return container_of(, struct ref, list);
}
static inline struct ref *next_step(struct ref *cur)
{
return container_of(cur->list.n, struct ref, list);
}
/* restarts a dump from dump_context or starts a new one if NULL */
struct ref *restart_dump(struct ref *last)
{
struct ref *curr;
if (!last)
last = get_initial_step();
curr = next_step(last);
while (>list != ) {
if (try_dump_next_ref(curr)) {
last = curr;
curr = next_step(curr);
} else {
/* do something to yield or flush the output */
}
}
return last;
}
void cont_dump()
{
restart_dump(last_dumped);
}
Please note that here "last_dump" isn't updated and if the compiler sees it
being written to, it eliminates some optimizations that result in the warning
(I think it sees that the get_initial_step() is conditional and thus doesn't
complain anymore).
I understand from your description that there could be an aliasing issue. I'd
argue that as soon as we're using lists there are potential aliasing issues and
that these may then be addressed using -fno-strict-aliasing but this one has no
effect here either.
Also I suspect based on your description, that accessing *any* field of a
struct implies the whole struct must be mapped in memory. But then there are
limits in case of aliased struct like above, or even when using VLAs since you
can't figure the possible extent of the variable part.
I think I see how I could cheat to eliminate the warning (not easy to test as I
don't have the trunk version of the compiler locally), but I suspect that doing
so would definitely make the code more error-prone.
I sincerely think that this *exact* case is counter-productive as it will
basically force a number of users of lists to disable the whole warning, which
was otherwise particularly effective at detecting real out-of-bounds accesses,
especially in such use cases. Or maybe you could assign it a different level
(-Warray-bounds=3 ?) to indicate a suspicious usage that might also be a valid
one ?
Thanks!
Willy
[Bug bootstrap/98323] current trunk won't build with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98323 --- Comment #9 from joseph at codesourcery dot com --- The original intent in the C standard was definitely to allow at least some cases of subobjects; the May 20, 1988 list of changes in the third public review draft of C89 has as item 10 "The offsetof macro has been generalized to allow more than just a simple identifier as its second argument.".
[Bug c++/98520] New: nodiscard not diagnosed in comma operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98520
Bug ID: 98520
Summary: nodiscard not diagnosed in comma operator
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tiagomacarios at gmail dot com
Target Milestone: ---
https://godbolt.org/z/13j51h
struct [[nodiscard]] S{};
void f();
void _()
{
f(), S{};
}
[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519 Peter Bergner changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||dje at gcc dot gnu.org, ||meissner at gcc dot gnu.org, ||munroesj at gcc dot gnu.org, ||segher at gcc dot gnu.org, ||wschmidt at gcc dot gnu.org Last reconfirmed||2021-01-04 Target||powerpc64le-linux Ever confirmed|0 |1 --- Comment #1 from Peter Bergner --- Steve reported the error and I have confirmed it. I believe this also fails on GCC 10 (ie, everywhere POWER10 is supported).
[Bug target/98519] New: rs6000: @pcrel unsupported on this instruction error in pveclib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519
Bug ID: 98519
Summary: rs6000: @pcrel unsupported on this instruction error
in pveclib
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
Using latest GCC trunk and binutils trunk from today, we see the following
error on a reduced test case from pveclib:
bergner@pike:~/gcc/BUGS/PVECLIB$ cat bug.i
typedef __attribute__((altivec(vector__))) double vf64_t;
static double test_f64[16];
vf64_t
bug (void)
{
vf64_t j0;
__asm__("lxsd%X1 %0,%1;" : "=v" (j0) : "m" (test_f64));
return j0;
}
bergner@pike:~/gcc/BUGS/PVECLIB$
/home/bergner/gcc/build/gcc-fsf-mainline-pveclib-debug/gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-mainline-pveclib-debug/gcc -c -O2
-mcpu=power10 bug.i
/tmp/ccNVSo9c.s: Assembler messages:
/tmp/ccNVSo9c.s:15: Warning: @pcrel unsupported on this instruction
/tmp/ccNVSo9c.s:15: Error: unsupported relocation for DS offset field
/tmp/ccNVSo9c.s:15: Error: missing operand
The problematic insn is:
lxsd 2,.LANCHOR0@pcrel;
[Bug c/98029] [11 Regression] volatile triggers incorrect "warning: right-hand operand of comma expression has no effect [-Wunused-value]" since r11-5188-g32934a4f45a72144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98029 --- Comment #6 from CVS Commits --- The master branch has been updated by Martin Uecker : https://gcc.gnu.org/g:a000eb5918e09d28838ef572f4eea924d32db09b commit r11-6450-ga000eb5918e09d28838ef572f4eea924d32db09b Author: Martin Uecker Date: Mon Jan 4 22:53:58 2021 +0100 C: Add test for incorrect warning for assignment of certain volatile expressions fixed by commit 58a45ce [PR98029] 2021-01-04 Martin Uecker gcc/testsuite/ PR c/98029 * gcc.dg/pr98029.c: New test.
[Bug libgomp/98258] Can't compile programs for both OpenMP (CPU) + OpenACC (GPU)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98258 --- Comment #5 from Alexander Monakov --- One possible solution is -foffload=-fno-openmp Another possible solution is separate compilation and linking, with only OpenACC enabled at link step (needs explicit -lgomp): gfortran -fopenmp -fopenacc bug_omp_acc.f90 -c -o test.o gfortran -fopenacc test.o -lgomp -o test.x
[Bug libstdc++/98518] New: std::array not bound checked with _GLIBCXX_ASSERTIONS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98518
Bug ID: 98518
Summary: std::array not bound checked with _GLIBCXX_ASSERTIONS
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: arnaud02 at users dot sourceforge.net
Target Milestone: ---
operator[] of std::array is not bound checked when specifying
_GLIBCXX_ASSERTIONS.
Considering:
#define _GLIBCXX_ASSERTIONS 1
#include
#include
int f(int i) {
std::array x = {1, 4};
return x[i]; // bounds are not checked
}
int main() {
volatile int i = 2;
printf("f=%d\n", f(i));
}
the array bound violation is not detected. By constrast, replacing std::array
by std::vector results in the expected assertion violation.
[Bug go/98504] [11 Regression] bootstrap broken in libgo on ia64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98504 --- Comment #3 from Ian Lance Taylor --- Maybe I'm missing something obvious, but I don't see how this is possible. The code in the Go frontend is if (suffix.compare(2, 5, "thunk") == 0 && Gogo::is_digits(suffix.substr(7))) return pos; The crash is apparently occurring on the call to suffix.substr(7). Given that suffix.compare already worked, there should be no way that that code could crash. So to me this looks like a miscompilation of the Go frontend code, rather than a bug in the Go frontend.
[Bug fortran/96381] gfc_find_vtab can use a character type typespec as a derived type (causing invalid access)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96381 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from anlauf at gcc dot gnu.org --- Fixed on all branches where testcase gfortran.dg/pr93337.f90 was committed. Thanks for the report!
[Bug fortran/96381] gfc_find_vtab can use a character type typespec as a derived type (causing invalid access)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96381 --- Comment #7 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:2bfcf6011a6cdce0439e3d1b94bcb5fcf078f4c2 commit r9-9151-g2bfcf6011a6cdce0439e3d1b94bcb5fcf078f4c2 Author: Harald Anlauf Date: Fri Jan 1 18:55:41 2021 +0100 PR fortran/96381 - invalid read in gfc_find_derived_vtab An invalid declaration of a CLASS instance can lead to an internal state with inconsistent attributes during parsing that needs to be handled with sufficient care when processing subsequent statements. Avoid a lookup of the vtab entry for such cases. gcc/fortran/ChangeLog: * class.c (gfc_find_vtab): Add check on attribute is_class. (cherry picked from commit d816b0c144d15e6570eb5b124b9f3ccbe3d40082)
[Bug fortran/96381] gfc_find_vtab can use a character type typespec as a derived type (causing invalid access)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96381 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:78ff090d0a0bb5a77560203b3b49bb7da7fcb88c commit r10-9200-g78ff090d0a0bb5a77560203b3b49bb7da7fcb88c Author: Harald Anlauf Date: Fri Jan 1 18:55:41 2021 +0100 PR fortran/96381 - invalid read in gfc_find_derived_vtab An invalid declaration of a CLASS instance can lead to an internal state with inconsistent attributes during parsing that needs to be handled with sufficient care when processing subsequent statements. Avoid a lookup of the vtab entry for such cases. gcc/fortran/ChangeLog: * class.c (gfc_find_vtab): Add check on attribute is_class. (cherry picked from commit d816b0c144d15e6570eb5b124b9f3ccbe3d40082)
[Bug c++/98327] C++ Module ICE on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98327 --- Comment #4 from Nathan Sidwell --- I cannot reproduce the reported crash -- like I said, I think this is fixed (thanks for the backtrace). I suspect Martin failed to copy the first line of the testcase 'module;' That's important -- it's not an English introduction of a piece of code :) The error message could be improved to say where these decls are permitted, rather than 'computer says no'.
[Bug c++/98515] [11 Regression] Possible regression causing "is protected within this context" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98515 Marek Polacek changed: What|Removed |Added Target Milestone|--- |11.0 Last reconfirmed||2021-01-04 Status|UNCONFIRMED |NEW Priority|P3 |P1 Ever confirmed|0 |1 Summary|Possible regression causing |[11 Regression] Possible |"is protected within this |regression causing "is |context" error |protected within this ||context" error Keywords||rejects-valid CC||mpolacek at gcc dot gnu.org, ||ppalka at gcc dot gnu.org --- Comment #4 from Marek Polacek --- Confirmed. Started with r11-1350.
[Bug fortran/98517] New: gfortran segfault on character array initialization from parameter value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98517 Bug ID: 98517 Summary: gfortran segfault on character array initialization from parameter value Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: emr-gnu at hev dot psu.edu Target Milestone: --- ~/fortran_bug$ cat source.for SUBROUTINE TEST_BUG IMPLICIT NONE CHARACTER*(*) DEF_VAL PARAMETER (DEF_VAL = 'ABCDEFGH') STRUCTURE /SOME_STRUCT/ CHARACTER*64SOME_VAR /DEF_VAL/ END STRUCTURE END ~/fortran_bug$ gfortran-10.2 -fdec-structure -c source.for f951: internal compiler error: Segmentation fault 0xbfa08f crash_signal toplev.c:328 0x6fc7e0 resolve_charlen resolve.c:12369 0x709019 resolve_charlen resolve.c:12347 0x709019 resolve_types resolve.c:17183 0x70472c gfc_resolve(gfc_namespace*) resolve.c:17300 0x6ec82c resolve_all_program_units parse.c:6245 0x6ec82c gfc_parse_file() parse.c:6492 0x7388ff gfc_be_parse_file f95-lang.c:210 Note: This may be related to #82721
[Bug c++/98327] C++ Module ICE on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98327 Nathan Sidwell changed: What|Removed |Added Status|WAITING |ASSIGNED Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org --- Comment #3 from Nathan Sidwell --- three things. a) I think this is now fixed b) it's not invalid code c) Martin, I think you're falling foul of some of the requirements of where you place code that is in the GMF (the bit between 'module;' and '[export] module foo;' But I think the diagnostic you're getting is not helping there.
[Bug tree-optimization/98516] Wrong code generated by tree vectorizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98516 --- Comment #1 from Martin Reinecke --- Minimal set of flags to trigger the problem seems to be g++ -std=c++17 -O1 -ftree-vectorize -fno-signed-zeros bug.cc
[Bug fortran/92587] [9/10/11 Regression] Compiler is unable to generate finalization wrapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92587 --- Comment #15 from CVS Commits --- The releases/gcc-9 branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:b7be64f9079dee9f326c791bcec1897047ae0de5 commit r9-9150-gb7be64f9079dee9f326c791bcec1897047ae0de5 Author: Tobias Burnus Date: Thu Dec 17 10:39:09 2020 +0100 Fortran: Delay vtab generation until after parsing [PR92587] gcc/fortran/ChangeLog: PR fortran/92587 * match.c (gfc_match_assignment): Move gfc_find_vtab call from here ... * resolve.c (gfc_resolve_code): ... to here. gcc/testsuite/ChangeLog: PR fortran/92587 * gfortran.dg/finalize_37.f90: New test. (cherry picked from commit ba9fa684053917a07bfa8f4742da0e196e72b9a2)
[Bug fortran/92587] [9/10/11 Regression] Compiler is unable to generate finalization wrapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92587 --- Comment #14 from CVS Commits --- The releases/gcc-10 branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:6f3f06e431c181d3e51d31f49a2bf0be2944ae93 commit r10-9199-g6f3f06e431c181d3e51d31f49a2bf0be2944ae93 Author: Tobias Burnus Date: Thu Dec 17 10:39:09 2020 +0100 Fortran: Delay vtab generation until after parsing [PR92587] gcc/fortran/ChangeLog: PR fortran/92587 * match.c (gfc_match_assignment): Move gfc_find_vtab call from here ... * resolve.c (gfc_resolve_code): ... to here. gcc/testsuite/ChangeLog: PR fortran/92587 * gfortran.dg/finalize_37.f90: New test. (cherry picked from commit ba9fa684053917a07bfa8f4742da0e196e72b9a2)
[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 98503, which changed state. Bug 98503 Summary: [11 regression] -Warray-bounds false positive with global variables at -O2 since r11-3306-g3f9a497d1b0dd9da https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98503 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |INVALID
[Bug c/98503] [11 regression] -Warray-bounds false positive with global variables at -O2 since r11-3306-g3f9a497d1b0dd9da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98503 Martin Sebor changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |INVALID --- Comment #6 from Martin Sebor --- In the test case in comment #0 the operand of the return statement in first() dereferences the tmp pointer: return tmp->list.n; The expression is equivalent to (*tmp).list.n where the dereference should be more obvious. The dereference is invalid if tmp points to an object of an incompatible type. This is a basic type-based aliasing requirement that GCC relies on. If the test case isn't representative of the problem you see in the code base please submit one that does.
[Bug libgomp/98258] Can't compile programs for both OpenMP (CPU) + OpenACC (GPU)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98258 --- Comment #4 from Chinoune --- gfortran -O3 -fopenmp -fopenacc -foffload=disable bug_omp_acc.f90 -o test.x ./test.x 2048 dim1 = dim2 = 2048 CPU Time =4.9989E-03 libgomp: target function wasn't mapped gfortran -O3 -fopenacc -foffload=disable bug_omp_acc.f90 -o test.x ./test.x 2048 dim1 = dim2 = 2048 CPU Time =1.9012 libgomp: target function wasn't mapped gfortran -O3 -fopenmp -foffload=disable bug_omp_acc.f90 -o test.x ./test.x 2048 dim1 = dim2 = 2048 CPU Time =6.0005E-03 GPU Time =1.4455 Max(|C2-C1|) =559.285156
[Bug tree-optimization/98516] New: Wrong code generated by tree vectorizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98516 Bug ID: 98516 Summary: Wrong code generated by tree vectorizer Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: mar...@mpa-garching.mpg.de Target Milestone: --- Created attachment 49879 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49879=edit Code to reproduce the problem The attached code is a distilled test case from an FFT library, which works fine with current released GCC versions, but produces incorrect results with current trunk when tree optimization is switched on via -O3: martin@debian:~/codes/ducc$ g++ -I src/ -std=c++17 -O3 -march=native -ffast-math bug.cc martin@debian:~/codes/ducc$ ./a.out (0.362978,0.601326) (0.362155,0.18782) (1.63193,-0.0779749) (1.26662,0.327246) (-1.0024,1.03302) The third complex number in the result line is wrong. When disabling tree vectorization (or when using a released GCC version), the correct answer is produced: martin@debian:~/codes/ducc$ g++ -I src/ -std=c++17 -O3 -march=native -ffast-math bug.cc -fno-tree-vectorize martin@debian:~/codes/ducc$ ./a.out (0.362978,0.601326) (0.362155,0.18782) (0.380433,0.228703) (1.26662,0.327246) (-1.0024,1.03302) My gcc version is martin@debian:~/codes/ducc$ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/home/martin/codes/umaster/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /home/martin/codes/gccgit/configure --disable-bootstrap --disable-multilib --prefix=/home/martin/codes/umaster --enable-languages=c++,fortran --enable-target=all --enable-checking=release Thread model: posix Supported LTO compression algorithms: zlib gcc version 11.0.0 20210103 (experimental) [master revision 37d0bb1f5b5:d78f978936b:3335c9f954f8939403eabb5ad3d8739be9984f81] (GCC) I have tried to narrow down this failure further, but without success so far. It's quite possible that the mistake is on my side, but using the sanitizers and valgrind I have not been able to find anything. Maybe a git bisect could locate the commit that introduced the change in behaviour.
[Bug tree-optimization/95817] Failure to optimize shift with constant to compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95817 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- There isn't really any advantage of either form, both are the same number of instructions, and after all, for higher shift counts the shift is more efficient (we have a combine splitter for that already). So, the only reason for the transformation would be code canonicalization.
[Bug c++/98515] Possible regression causing "is protected within this context" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98515 --- Comment #3 from Julian Sikorski --- The initial comment meant to say: This fails with gcc-11 but works on gcc-10.2.
[Bug libgomp/98258] Can't compile programs for both OpenMP (CPU) + OpenACC (GPU)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98258 Jakub Jelinek changed: What|Removed |Added CC||amonakov at gcc dot gnu.org, ||burnus at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- The error comes from config/nvptx/mkoffload.c if (!(fopenacc ^ fopenmp)) fatal_error (input_location, "either %<-fopenacc%> or %<-fopenmp%> " "must be set"); I guess this is because in order to compile NVPTX offloading OpenMP code one needs different Options (e.g. -mgomp ) than for OpenACC code, making NVPTX offloading incompatible between the two standards. I think you can use both if you disable nvptx offloading (e.g. through -foffload= option).
[Bug c++/98515] Possible regression causing "is protected within this context" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98515 --- Comment #2 from Julian Sikorski --- Created attachment 49878 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49878=edit failing test case
[Bug c++/98515] Possible regression causing "is protected within this context" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98515 --- Comment #1 from Julian Sikorski --- Created attachment 49877 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49877=edit compiling test case
[Bug c++/98515] New: Possible regression causing "is protected within this context" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98515
Bug ID: 98515
Summary: Possible regression causing "is protected within this
context" error
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: belegdol at gmail dot com
Target Milestone: ---
mame-0.227 has failed to compile with gcc-11 in Fedora 34 [1]
(gcc-11.0.0-0.11.fc34). mame developers have kindly provided a minimal test
case. This fails with gcc-11 but works on
class A {
public:
A() = default;
protected:
int var0 = 0;
};
template class B : public A {
public:
using A::A;
};
template class C : public B {
public:
using B::B;
void g();
};
template void C::g()
{
A::var0++;
}
template class C<0, 0>;
While this works:
class A {
public:
A() = default;
protected:
int var0 = 0;
};
template class B : public A {
public:
using A::A;
};
template class C : public B {
public:
using B::B;
void g() { A::var0++; }
};
template class C<0, 0>;
[1] https://github.com/mamedev/mame/issues/7616
[Bug rtl-optimization/97978] [11 Regression] ICE in lra_assign, at lra-assigns.c:1648 since r11-5066-gbe39636d9f68c437
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97978 --- Comment #3 from Vladimir Makarov --- Thank you for reporting it. I've started work on the PR. It seems a rare but dangerous bug and its fix might affect many targets and will require a lot of testing but I try to fix the PR on this week.
[Bug libgomp/98258] Can't compile programs for both OpenMP (CPU) + OpenACC (GPU)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98258 --- Comment #2 from Chinoune --- program main use omp_lib implicit none integer, parameter :: sp = selected_real_kind(6,37) integer :: i, j, k integer :: n character(len=5) :: var real(sp), allocatable :: a(:,:), b(:,:), c(:,:), cc(:,:) integer :: t1, t2, t3 real(sp) :: tic ! call get_command_argument( 1, var ) read( var, '(i5.3)') n print*, "dim1 = dim2 = ", n ! allocate( a(n,n), b(n,n), c(n,n), cc(n,n) ) call random_number(a) call random_number(b) cc = 0._sp c = 0._sp ! call system_clock(t1, tic) !$omp parallel do collapse(3) do j = 1, n do k = 1, n do i = 1, n cc(i,j) = a(i,k)*b(k,j) + cc(i,j) end do end do end do ! call system_clock( t2 ) print*, "CPU Time = ", (t2-t1)/tic !$acc data copyin(a,b) copy(c) !$acc parallel loop collapse(3) do j = 1, n do k = 1, n do i = 1, n c(i,j) = a(i,k)*b(k,j) + c(i,j) end do end do end do !$acc end data call system_clock(t3) print*, "GPU Time = ", (t3-t2)/tic print*, "Max(|C2-C1|) = ", maxval( abs(cc-c) ) ! end program main gfortran -fopenmp -fopenacc bug_omp_acc.f90 -o test.x mkoffload: fatal error: either '-fopenacc' or '-fopenmp' must be set compilation terminated. lto-wrapper: fatal error: /usr/lib/gcc/x86_64-linux-gnu/9//accel/nvptx-none/mkoffload returned 1 exit status compilation terminated. /usr/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status
[Bug tree-optimization/98514] ICE in insert_operand_rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98514 --- Comment #2 from Jakub Jelinek --- Oops, sorry, it is just SSA_NAMEs which are default definitions, so that is less than that; more than 32768 parameters to a function are unlikely, but one can have thousands of uninitialized SSA_NAMEs, or one can have tens of thousands of basic blocks. Even the number of bbs alone is what causes this on the function. And I forgot to change %ld to " HOST_WIDE_INT_PRINT_DEC " when printing the rank, fixed in my copy.
[Bug tree-optimization/98513] [10/11 Regression] Wrong code with -O3 since r10-2804-gbf05a3bbb58b3558
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98513 --- Comment #3 from Martin Liška --- Happens with -O2 -funswitch-loops.
[Bug tree-optimization/98513] [10/11 Regression] Wrong code with -O3 since r10-2804-gbf05a3bbb58b3558
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98513
--- Comment #2 from Martin Liška ---
Even more reduced test-case:
$ cat combined.cc
unsigned var;
unsigned array[2];
int zero = 0, minus_2 = -2;
const int (const int , const int ) { return a > b ? a : b; }
void test(int minus_1)
{
for (unsigned i_0 = 0; i_0 < 2; i_0++)
{
for (int i_3 = 0; i_3 < zero; i_3++)
for (int i_4 = 0; i_4 < 2; i_4++)
var = max(minus_1, 0);
for (int i_6 = minus_2 + 2; i_6 < minus_1 + 3; i_6++)
array[i_6] = zero;
}
}
int main() { test(-1); }
[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 98503, which changed state. Bug 98503 Summary: [11 regression] -Warray-bounds false positive with global variables at -O2 since r11-3306-g3f9a497d1b0dd9da https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98503 What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |---
[Bug c/98503] [11 regression] -Warray-bounds false positive with global variables at -O2 since r11-3306-g3f9a497d1b0dd9da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98503 Willy Tarreau changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED|REOPENED --- Comment #5 from Willy Tarreau --- apparently I closed it by accident, reopening, sorry.
[Bug c/98503] [11 regression] -Warray-bounds false positive with global variables at -O2 since r11-3306-g3f9a497d1b0dd9da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98503 --- Comment #4 from Willy Tarreau --- Hi Martin, I'm sorry but I'm missing something, as this is how linked lists are implemented everywhere nowadays. I'm not actually casting the pointer, it was made for simplification. I'm only following the list elements which are linked together from a list head accessed via a container_of. The code does nothing but follow the list from the head (which is only a struct list) and visiting all nodes in turn. There is absolutely zero dereference of a list using a wrong pointer here.
[Bug tree-optimization/98514] ICE in insert_operand_rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98514 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Last reconfirmed||2021-01-04 --- Comment #1 from Jakub Jelinek --- Created attachment 49876 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49876=edit gcc11-pr98512.patch Untested fix.
[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 98503, which changed state. Bug 98503 Summary: [11 regression] -Warray-bounds false positive with global variables at -O2 since r11-3306-g3f9a497d1b0dd9da https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98503 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID
[Bug c/98503] [11 regression] -Warray-bounds false positive with global variables at -O2 since r11-3306-g3f9a497d1b0dd9da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98503 Martin Sebor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Martin Sebor --- The phrasing of the warning could stand to be made clearer but it is by design. With the exception of a union with a /common initial sequence/, it's not valid to access [members of] an object of one type (struct list) using a pointer to an incompatible type (struct ref). It doesn't matter if the offset of the member is less than the size of the object.
[Bug tree-optimization/98514] New: ICE in insert_operand_rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98514
Bug ID: 98514
Summary: ICE in insert_operand_rank
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
When building gmic on i686-linux (or other 32-bit arches) with LTO, one gets:
gmic.cpp: In member function '_run.isra':
gmic.cpp:4981:7: internal compiler error: in insert_operand_rank, at
tree-ssa-reassoc.c:367
4981 | gmic& gmic::_run(const CImgList& commands_line, unsigned int&
position,
| ^
It is in 101th partition and the function is huge, so am not going to reduce,
but it seems a general reassoc issue on 32-bit hosts.
The function in question has 104549 SSA_NAMEs and 36954 basic blocks.
Now, the bb ranks are computed as:
/* Give each default definition a distinct rank. This includes
parameters and the static chain. Walk backwards over all
SSA names so that we get proper rank ordering according
to tree_swap_operands_p. */
for (i = num_ssa_names - 1; i > 0; --i)
{
tree name = ssa_name (i);
if (name && SSA_NAME_IS_DEFAULT_DEF (name))
insert_operand_rank (name, ++rank);
}
/* Set up rank for each BB */
for (i = 0; i < n_basic_blocks_for_fn (cfun) - NUM_FIXED_BLOCKS; i++)
bb_rank[bbs[i]] = ++rank << 16;
and bb_rank as well as everything else that deals with ranks is long,
so obviously it can't work properly in any function which has more than
32767 (num_ssa_names + n_basic_blocks_for_fn (cfun)).
Either we should punt on trying to reassociate such functions, but that would
make 32-bit hosts behave differently from 64-bit hosts even when targeting the
same target, or my preferred way out of this is make the ranks just
HOST_WIDE_INTs, yes, it will need more memory on 32-bit hosts and will be
slightly slower, but it will be consistent with 64-bit hosts. We have vectors
of ssa names and basic blocks and those have int length, so even on 64-bit
hosts we can't support more than 4 billion ssa names and more than 4 billion
basic blocks.
[Bug tree-optimization/98339] GCC could not vectorize loop with conditional reduced add and store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98339
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Target||x86_64-*-*
Ever confirmed|0 |1
Blocks||53947
Last reconfirmed||2021-01-04
--- Comment #1 from Richard Biener ---
The issue is that we need to vectorize this as reduction and since there's no
"masked scalar store" on GIMPLE LIM itself doesn't help. The issue why
LIM doesn't apply store-motion here is the _load_ which can trap. LIM would
like to do
ret0 = ret[0];
bool stored = false;
for (int i = 0; i < n; i++)
{
int pos = start + i;
if ( pos <= m)
{
ret0 += x[i];
stored = true;
}
}
if (stored)
ret[0] = ret0;
but as you can see the unconditional load breaks this. LIM would need to
be changed to handle the whole load-update-store sequence delaying the
load as well (thereby re-associating the reduction).
An alternative would be to split the loop and apply store-motion to the tail.
for (int i = 0; i < n; i++)
{
int pos = start + i;
if ( pos <= m)
break;
}
if (i < n)
{
ret0 = ret[0];
for (int i = 0; i < n; i++)
{
int pos = start + i;
if ( pos <= m)
ret0 += x[i];
}
ret[0] = ret0;
}
we can then vectorize the second loop.
At the source level the fix is to make sure the load from ret[0] doesn't trap.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug bootstrap/98338] [11 Regression] profiledbootstrap failure on x86_64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98338 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0 Priority|P3 |P1
[Bug tree-optimization/98337] Failure to optimize out on-stack array construction when unneeded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98337
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2021-01-04
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from Richard Biener ---
It could be optimized to return x even ...
Note we're forcing the array to the stack because of the variable array access.
We could optimize this on the GIMPLE level from
MEM [(int *)] = 3547642986509;
_5 = a[x_4(D)];
to
3547642986509ul >> (x_4(D)*32)
for example when using more "interesting" constants like
int f(int x) {
int a[] = {13, 826};
return a[x];
}
[Bug c++/98448] [11 Regression] bootstrap-O3 comparison fails due to libcody
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98448 --- Comment #2 from ktkachov at gcc dot gnu.org --- Indeed, I see it passing with today's trunk. Nathan, if you can't reproduce it feel free to close this.
[Bug tree-optimization/98513] [10/11 Regression] Wrong code with -O3 since r10-2804-gbf05a3bbb58b3558
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98513
Martin Liška changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot
gnu.org
--- Comment #1 from Martin Liška ---
A cleaner test-case:
$ cat combined.cc
extern unsigned long long var_20;
extern unsigned short arr_8[][26][1][1][11];
const int (int , const int ) { return a > b ? a : b; }
int test___trans_tmp_1, var_5 = -1, var_6 = -2;
void test(int var_5, int var_6,
signed char arr_1[1][1][1]) {
for (unsigned i_0 = 0; i_0 < 21; i_0 += 2)
for (int i_2 = 0; i_2 < 8; i_2 += 82) {
for (int i_3 = 0; i_3 < test___trans_tmp_1; i_3++)
for (short i_4 = 0; i_4 < 20; i_4 += 4)
var_20 = max(var_5, 0);
for (int i_5 = 0; i_5 < 19;
i_5 += 20)
for (int i_6 = var_6 + 2; i_6 < var_5 + 3; i_6++)
arr_8[3][2][i_2][i_5][i_6] = arr_1[0][0][0];
}
}
unsigned long long var_20;
signed char arr_1[1][1][1];
unsigned short arr_8[22][26][1][1][11];
int main() { test(var_5, var_6, arr_1); }
Optimized dump contains:
[local count: 17523394]:
_93 = MEM[(signed char[26][19] *)arr_1_31(D) + 1482B][2][0];
_94 = (short unsigned int) _93;
arr_8[3][2][0][0][-2147483648] = _94; < HERE
if (i_6_103 > _131)
goto ; [11.00%]
else
goto ; [89.00%]
which is instruction that causes the segfault. I'm going to take a look.
[Bug tree-optimization/98335] [9/10/11 Regression] Poor code generation for partial struct initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98335
Richard Biener changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org,
||jakub at gcc dot gnu.org
Keywords||missed-optimization
Priority|P3 |P2
Component|rtl-optimization|tree-optimization
Last reconfirmed||2021-01-04
Ever confirmed|0 |1
Target Milestone|--- |9.4
Status|UNCONFIRMED |NEW
--- Comment #2 from Richard Biener ---
We expand the first case from
MEM [(struct Data *) + 1B] = {};
c.0_1 = c;
D.2365.a = c.0_1;
return D.2365;
I guess store-merging could "merge" the stores as
D.2365 = {};
D.2365.a = c.0_1;
thus figure the partial unaligned zeroing is better done aligned
(and redundant). Alternatively it could emit
V_C_E = (unsigned) c.0_1;
The second testcase looks vectorization/ABI related for which we have plenty
of dups.
[Bug rtl-optimization/98334] Failure to optimally optimize add loop to mul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98334 --- Comment #3 from Richard Biener --- I think turning (int) (y - 1U) * x + x into unsigned mult is OK even early.
[Bug tree-optimization/94021] -Wformat-truncation false positive due to excessive integer range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94021
--- Comment #9 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #6)
> CCing Andrew and Aldy to see what the ranger does or can do, talking about
> I mean, if we have:
> h_1 = x_2 / 3600;
> if (x_2 <= -3599 && x_2 <= 8)
> use (h_1);
> figure out that h_1 is set to x_2 / 3600 and even when that
> SSA_NAME_DEF_STMT is not in a guarded block, its use is in one and so from
> the [-3599, 8] range of x_2 at the point of use derive that h_1 there is
> [0, 24]?
> Surely if it is like:
> if (x_2 <= -3599 && x_2 <= 8)
> {
> h_1 = x_2 / 3600;
> use (h_1);
> }
> I'd expect it to handle it that way.
Certainly we get the latter case. The earlier case is currently...
inconsistent. Something I hope to address in the next release.
if we have precisely:
h_1 = x_2 / 3600;
if (x_2 <= -3599 && x_2 <= 8)
use (h_1);
and if that is calculated in such a way that all of the conditions are
evaluated in a single basic block, then the GORI engine well mark h1 and x_2
both as exports and the evaluator will calculate the desired value for h_1.
Once we start to pull them further apart, the current implementation loses the
ability to recalculate h_1 when we get new ranges for x_2.
I have plans to segregate the def chains from the export lists in blocks, and
allow for greater ability to recalculate things like this.
When I look at #c4 in EVRP, I see:
=== BB 4
:
# x_10 = PHI
h_15 = x_10 / 3600;
_1 = x_10 % 3600;
m_16 = _1 / 60;
h.0_2 = (unsigned int) h_15;
_3 = h.0_2 > 23;
_5 = _3;
if (_5 != 0)
goto ; [INV]
else
goto ; [INV]
_1 : int [0, 3599]
h.0_2 : unsigned int [0, 596523]
x_10 : int [0, +INF]
h_15 : int [0, 596523]
m_16 : int [0, 59]
4->6 (T) h.0_2 : unsigned int [0, 596523]
4->6 (T) _5 : _Bool [1, 1]
4->6 (T) x_10 :int [0, +INF]
4->6 (T) h_15 :int [0, 596523]
4->5 (F) h.0_2 : unsigned int [0, 596523]
4->5 (F) _5 : _Bool [0, 0]
4->5 (F) x_10 :int [0, +INF]
4->5 (F) h_15 :int [0, 596523]
and then later on:
=== BB 8
x_10int [0, +INF]
:
if (x_10 <= 8)
goto ; [INV]
else
goto ; [INV]
8->9 (T) x_10 :int [0, 8]
8->10 (F) x_10 : int [9, +INF]
=== BB 9
:
__builtin_snprintf (, 8, "%s%02i%02i", "+", h_15, m_16);
The defchains already indicate that h_15 is dependant on the value of x_10, and
I am hoping to enable recalculation of h_15 when a dependant range has
changed.. and not just when they are exported from the same block.
so in this case, when we ask for the range of h_15 in BB_9, we should be able
to see that x_10 has a range of int [0, 8] and trigger a recalculation of
h_15 using "current" values. and come up with h_15 = [0,24]
The pieces are all there, but they need to be assembled in a non time consuming
way :-)
It is on the radar for next release.
[Bug c++/98333] [10/11 Regression] ICE in check_qualified_type, at tree.c:6593 since r10-1280-g78f7607db4c53f8c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98333 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/98331] [9/10/11 Regression] ICE in haifa_luid_for_non_insn, at haifa-sched.c:7845 since r8-5479-g67a8d7199fe4e474
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98331 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.4
[Bug c++/98330] [11 Regression] ICE in compute_parm_map, at ipa-modref.c:2900
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98330 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Status|WAITING |NEW CC||hubicka at gcc dot gnu.org Target Milestone|--- |11.0 Keywords||ice-on-valid-code --- Comment #2 from Richard Biener --- Confirmed on trunk (with z2.cc): > ./cc1plus -quiet t.ii t.ii: In function 'float f(float)': t.ii:3:25: warning: pointer to a function used in arithmetic [-Wpointer-arith] 3 | return __builtin_pow[1] (x, 2); | ^ rguenther@ryzen:~/obj-gcc2-g/gcc> ./cc1plus -quiet t.ii -O2 t.ii: In function 'float f(float)': t.ii:3:25: warning: pointer to a function used in arithmetic [-Wpointer-arith] 3 | return __builtin_pow[1] (x, 2); | ^ during IPA pass: modref t.ii: At global scope: t.ii:4:1: internal compiler error: Segmentation fault 4 | } | ^ 0x1851657 crash_signal /home/rguenther/src/gcc2/gcc/toplev.c:327 0xc8fbe8 symtab_node::ultimate_alias_target(availability*, symtab_node*) /home/rguenther/src/gcc2/gcc/cgraph.h:3182 0x10c5fbe cgraph_node::ultimate_alias_target(availability*, symtab_node*) /home/rguenther/src/gcc2/gcc/cgraph.h:3203 0x10c2224 cgraph_node::function_or_virtual_thunk_symbol(availability*, symtab_node*) /home/rguenther/src/gcc2/gcc/cgraph.c:3868 0x1477503 compute_parm_map /home/rguenther/src/gcc2/gcc/ipa-modref.c:2900
[Bug c++/98329] [11 Regression] ICE in cp_build_bit_cast, at cp/semantics.c:10730
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98329 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0
[Bug c++/98326] [10/11 Regression] ICE: in create_tmp_var, at gimple-expr.c:482, converting stateless generic-lambda to function pointer since r10-599-gc652ff8312433483
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98326 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug testsuite/98325] [11 regression] gcc.dg/pr25376.c fails after r11-5027
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98325 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0
[Bug bootstrap/98318] [11 Regression] libcody breaks DragonFly bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98318 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0 Summary|libcody breaks DragonFly|[11 Regression] libcody |bootstrap |breaks DragonFly bootstrap Target||x86_64-*-dragonfly
[Bug c++/98316] [11 regression] cc1plus doesn't link on Solaris 11.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98316 Richard Biener changed: What|Removed |Added Keywords||build Priority|P3 |P1
[Bug target/98310] drivers/mtd/tests/subpagetest.c:426:1: error: could not split insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98310 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2021-01-04 Target||csky --- Comment #2 from Richard Biener --- please attach preprocessed source
[Bug target/98302] [9/10 Regression] Wrong code on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98302 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.4 Known to work||11.0 Priority|P3 |P2 Summary|[?? Regression] Wrong code |[9/10 Regression] Wrong |on aarch64 |code on aarch64
[Bug bootstrap/98300] GCC 11 failed to build on Windows 10. I guess the new module completely breaks this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98300 Richard Biener changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #12 from Richard Biener --- Fixed (please re-open if not).
[Bug tree-optimization/98299] Failure to optimize sub loop into modulo-based pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98299 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-01-04 Ever confirmed|0 |1 --- Comment #4 from Richard Biener --- Btw for the similar division pattern kernel folks once complained ;) But yes, confirmed. SCCP is doing such transform usually but we don't do it because we consider the replacement (n_2(D) + -45) + (int) (((unsigned int) n_2(D) + 4294967251) / 45) * -45 too expensive (guess the cast makes recognizing this as modulo not valid).
[Bug tree-optimization/98513] [10/11 Regression] Wrong code with -O3 since r10-2804-gbf05a3bbb58b3558
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98513 Martin Liška changed: What|Removed |Added Known to work||9.3.0 Last reconfirmed||2021-01-04 Known to fail||10.2.0, 11.0 Target Milestone|--- |10.3 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug tree-optimization/98513] New: [10/11 Regression] Wrong code with -O3 since r10-2804-gbf05a3bbb58b3558
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98513
Bug ID: 98513
Summary: [10/11 Regression] Wrong code with -O3 since
r10-2804-gbf05a3bbb58b3558
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: acoplan at gcc dot gnu.org, rguenth at gcc dot gnu.org
Target Milestone: ---
It's reduced from a yarpgen test-case:
$ cat combined.cc
extern unsigned long long var_20;
extern unsigned short arr_8[][26][1][1][11];
const int (int , const int ) { return a > b ? a : b; }
int test___trans_tmp_1, var_5 = -1251116163, var_6 = -1745956746;
void test(int var_5, int var_6,
signed char arr_1[][26][19]) {
for (unsigned i_0 = 0; i_0 < 21; i_0 += 2)
for (int i_2 = 0; i_2 < 8; i_2 += 82) {
for (int i_3 = 0; i_3 < test___trans_tmp_1; i_3 += 70)
for (short i_4 = 0; i_4 < 20; i_4 += 4)
var_20 = max(var_5, 0);
for (int i_5 = 0; i_5 < 19;
i_5 += 20)
for (int i_6 = var_6 + 1745956746; i_6 < var_5 + 1251116173; i_6 += 1)
arr_8[3][2][i_2][i_5][i_6] = arr_1[3][2][i_2];
}
}
unsigned long long var_20;
signed char arr_1[1][26][19];
unsigned short arr_8[22][26][1][1][11];
int main() { test(var_5, var_6, arr_1); }
$ g++-10 -O3 combined.cc -Wall -Wextra -Werror && timeout 2 valgrind ./a.out
==9389== Memcheck, a memory error detector
==9389== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==9389== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==9389== Command: ./a.out
==9389==
==9389== Invalid write of size 2
==9389==at 0x401250: test(int, int, signed char (*) [26][19]) (in
/home/marxin/Programming/yarpgen/objdir/S3105191294/a.out)
==9389==by 0x401035: main (in
/home/marxin/Programming/yarpgen/objdir/S3105191294/a.out)
==9389== Address 0x00404740 is not stack'd, malloc'd or (recently)
free'd
==9389==
==9389==
==9389== Process terminating with default action of signal 11 (SIGSEGV):
dumping core
==9389== Access not within mapped region at address 0x00404740
==9389==at 0x401250: test(int, int, signed char (*) [26][19]) (in
/home/marxin/Programming/yarpgen/objdir/S3105191294/a.out)
==9389==by 0x401035: main (in
/home/marxin/Programming/yarpgen/objdir/S3105191294/a.out)
==9389== If you believe this happened as a result of a stack
==9389== overflow in your program's main thread (unlikely but
==9389== possible), you can try to increase the size of the
==9389== main thread stack using the --main-stacksize= flag.
==9389== The main thread stack size used in this run was 8388608.
==9389==
==9389== HEAP SUMMARY:
==9389== in use at exit: 0 bytes in 0 blocks
==9389== total heap usage: 1 allocs, 1 frees, 72,704 bytes allocated
==9389==
==9389== All heap blocks were freed -- no leaks are possible
==9389==
==9389== For lists of detected and suppressed errors, rerun with: -s
==9389== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
timeout: the monitored command dumped core
Segmentation fault
It should not contain any undefined behavior, verified with:
$ clang++ combined.cc -Wall -Wextra -Werror && timeout 1 ./a.out && g++
combined.cc -Wall -Wextra -Werror && timeout 1 ./a.out && g++-10
-fsanitize=address,undefined -fno-sanitize-recover=all combined.cc && timeout 2
./a.out
[Bug c++/98295] [8/9/10/11 Regression] ICE in verify_ctor_sanity, at cp/constexpr.c:4312
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98295 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug fortran/96320] gfortran 8-10 shape mismatch in assumed-length dummy argument character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96320 --- Comment #27 from Paul Thomas --- Created attachment 49875 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49875=edit Fix for the cases in comments 23 and 24 Hi Damian, Happy New Year! or I wish you a better one anyway. I have been doing a bit of catching up. The original patch for this PR is now applied as far back as I want to go. The new attachment fixes the testcases in comments 23 and 24. It even regtests OK. Thanks for your patience. Paul
[Bug c/98294] [9/10/11 Regression] ICE in calculate_line_spans, at diagnostic-show-locus.c:1296 since r6-6901-g876217ae71cf0b34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98294 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.4
[Bug analyzer/98293] [11 Regression] ICE in get_subregion_within_ctor, at analyzer/store.cc:494
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98293 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |11.0
[Bug rtl-optimization/98287] [10/11 Regression] ICE: in expand_expr_real_2, at expr.c:10000 with -O2 -fno-tree-ccp -fno-tree-forwprop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98287 --- Comment #3 from Richard Biener --- We need to guard the patterns. Handling V1 modes in the expanders is possible but it doesn't fix the root cause (there's also vector-by-scalar shifts). Maybe we should define/document a set of arithmetics we assume available for all vector modes (including bitwise and) and make this one a target bug?
[Bug tree-optimization/96697] Failure to optimize mod+div to 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96697 --- Comment #4 from Andrew Macleod --- (In reply to Jakub Jelinek from comment #2) > Shall we do that as a specific matcher or e.g. in the ranger once it gets > code for symbolic comparisons? I mean, for signed t = x % y note that t is > in [-y + 1, y + 1] and on the division use that information to determine the > division result range to be [0, 0] ? > It could then handle even e.g. ((unsigned) x % y) / (y + 32) for signed y > etc. IN theory the ranger should handle this when relations are available. : _1 = x_2(D) % y_3(D); // Establish relation _1 < y_3 _4 = _1 / y_3(D); return _4; IT should recognize the relation _1 < y_3 from the first statement and when we calculate _1 / y_3, it again ought to then apply the relation and determine that _4 = [0,0]
[Bug testsuite/98280] [11 regression] gcc.target/powerpc/fold-vec-logical-ors-char.c fails after t11-5958 with assembler output differences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98280 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |11.0 --- Comment #2 from Richard Biener --- Fixed I assume.
