[Bug analyzer/96608] Build failure due to cast to type long on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608 --- Comment #11 from Pekka S --- Hi, that indeed does solve the build issue, though I only tried using --disable-analyzer. I've been using a similar patch up until this point, but retired my local patch in favour of this. Thanks!
[Bug c++/97610] New: [10/11] template argument deduction fails for function with defaulted lambda as non-type-template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97610
Bug ID: 97610
Summary: [10/11] template argument deduction fails for function
with defaulted lambda as non-type-template parameter
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lutztonineubert at gmail dot com
Target Milestone: ---
The following code (with C++20 enabled):
template
constexpr auto nested() {
return 1;
}
template
constexpr void test() {
static_assert(nested());
}
--
Fails with:
: In function 'constexpr void test()':
:8:30: error: no matching function for call to 'nested()'
8 | static_assert(nested());
| ^
:2:16: note: candidate: 'template > constexpr auto
nested()'
2 | constexpr auto nested() {
|^~
:2:16: note: template argument deduction/substitution failed:
--
* same error happens if nested() has template as
this template parameters
* if the template non-type parameter of nested() is defaulted to 1, it compiles
* if test() is not a template function, it compiles
* if static_assert(nested<[]{}>()); is used, it compiles
[Bug tree-optimization/97603] Failure to optimize out compare into reuse of subtraction result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97603
--- Comment #2 from Hongtao.liu ---
(In reply to Hongtao.liu from comment #1)
> Shouldn't it be marked as target issue for x86?
Or you means that middle-end should transform code to
int g();
int f(int a, int b)
{
int c = a - b;
if (c)
return c;
return g();
}
[Bug tree-optimization/97472] [11 Regression] Another EVRP problem since r11-3685-gfcae5121154d1c33
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97472 --- Comment #2 from Arseny Solokha --- I cannot reproduce it w/ gcc-11.0.0-alpha20201025 snapshot.
[Bug tree-optimization/97603] Failure to optimize out compare into reuse of subtraction result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97603 --- Comment #1 from Hongtao.liu --- Shouldn't it be marked as target issue for x86?
[Bug target/97606] internal compiler error: in extract_constrain_insn, at recog.c:2196
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97606 Hongtao.liu changed: What|Removed |Added CC||crazylht at gmail dot com --- Comment #1 from Hongtao.liu --- Same bug as PR97532
[Bug tree-optimization/97609] New: [11 Regression] ICE: tree check: expected tree that contains 'decl common' structure, have 'component_ref' in tree_could_trap_p, at tree-eh.c:2708
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97609 Bug ID: 97609 Summary: [11 Regression] ICE: tree check: expected tree that contains 'decl common' structure, have 'component_ref' in tree_could_trap_p, at tree-eh.c:2708 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- Created attachment 49457 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49457&action=edit Testcase g++-11.0.0-alpha20201025 snapshot (g:308e40331f9d2820f8286769b5fc764671187364) ICEs when compiling the attached testcase, reduced from test/std/containers/sequences/forwardlist/forwardlist.ops/unique.pass.cpp from the libcxx 10.0.1 test suite, w/ -O2 -fno-tree-fre -fnon-call-exceptions: % g++-11.0.0 -O2 -fno-tree-fre -fnon-call-exceptions -c d1sutzlp.cpp during GIMPLE pass: evrp d1sutzlp.cpp: In member function 'forward_list< , >::__remove_return_type forward_list< , >::unique(_BinPred) [with _BinPred = int; = int; = int]': d1sutzlp.cpp:41:1: internal compiler error: tree check: expected tree that contains 'decl common' structure, have 'component_ref' in tree_could_trap_p, at tree-eh.c:2708 41 | } | ^ 0x7dbdc8 tree_contains_struct_check_failed(tree_node const*, tree_node_structure_enum, char const*, int, char const*) /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/tree.c:9903 0x780afc contains_struct_check(tree_node*, tree_node_structure_enum, char const*, int, char const*) /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/tree.h:3417 0x780afc tree_could_trap_p(tree_node*) /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/tree-eh.c:2708 0x10875f4 stmt_could_throw_1_p /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/tree-eh.c:2868 0x10875f4 stmt_could_throw_p(function*, gimple*) /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/tree-eh.c:2922 0x1088fe5 stmt_could_throw_p(function*, gimple*) /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/tree-eh.c:2894 0x1088fe5 stmt_can_throw_internal(function*, gimple*) /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/tree-eh.c:2996 0x12cdff5 infer_value_range(gimple*, tree_node*, tree_code*, tree_node**) /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/tree-vrp.c:1331 0x12cdff5 infer_value_range(gimple*, tree_node*, tree_code*, tree_node**) /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/tree-vrp.c:1317 0x19b157f non_null_ref::process_name(tree_node*) /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/gimple-range-cache.cc:102 0x19b1694 non_null_ref::non_null_deref_p(tree_node*, basic_block_def*) /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/gimple-range-cache.cc:60 0x19b1694 non_null_ref::non_null_deref_p(tree_node*, basic_block_def*) /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/gimple-range-cache.cc:53 0x19b3a78 ranger_cache::fill_block_cache(tree_node*, basic_block_def*, basic_block_def*) /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/gimple-range-cache.cc:772 0x19b3efd ranger_cache::block_range(irange&, basic_block_def*, tree_node*, bool) /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/gimple-range-cache.cc:589 0x19ac7e4 gimple_ranger::range_on_entry(irange&, basic_block_def*, tree_node*) /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/gimple-range.cc:939 0x19ad13b gimple_ranger::range_of_expr(irange&, tree_node*, gimple*) /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/gimple-range.cc:910 0x130e921 range_query::value_of_expr(tree_node*, gimple*) /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/value-query.cc:86 0x19bb0c1 hybrid_folder::value_of_expr(tree_node*, gimple*) /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/gimple-ssa-evrp.c:235 0x11c2784 substitute_and_fold_engine::replace_uses_in(gimple*) /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/tree-ssa-propagate.c:871 0x11c2aab substitute_and_fold_dom_walker::before_dom_children(basic_block_def*) /var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/tree-ssa-propagate.c:1141
[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504 --- Comment #17 from Alexandre Oliva --- Created attachment 49456 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49456&action=edit fix for riscv targets > Still broken Sorry, it's the first I hear of this problem on riscv. The fix is target-specific. Here's one for riscv*.
[Bug analyzer/97608] New: -Wanalyzer-malloc-leak false positive when returning p+1 instead of p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97608
Bug ID: 97608
Summary: -Wanalyzer-malloc-leak false positive when returning
p+1 instead of p
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
Target Milestone: ---
On the following program tst.c
#include
void *f (void)
{
void *p = malloc (8);
if (p == NULL)
abort ();
return (void *) ((char *) p + 0);
}
void *g (void)
{
void *p = malloc (8);
if (p == NULL)
abort ();
return (void *) ((char *) p + 1);
}
I get:
cventin:~> gcc -c -fanalyzer tst.c
tst.c: In function ‘g’:
tst.c:16:10: warning: leak of ‘p’ [CWE-401] [-Wanalyzer-malloc-leak]
16 | return (void *) ((char *) p + 1);
| ^
‘g’: events 1-5
|
| 13 | void *p = malloc (8);
| | ^~
| | |
| | (1) allocated here
| 14 | if (p == NULL)
| | ~
| | |
| | (2) assuming ‘p’ is non-NULL
| | (3) following ‘false’ branch (when ‘p’ is non-NULL)...
| 15 | abort ();
| 16 | return (void *) ((char *) p + 1);
| | ~
| | |
| | (4) ...to here
| | (5) ‘p’ leaks here; was allocated at (1)
|
(MPFR has something similar in its talloc-cache.c test in order to test the
behavior of memory allocators, implemented in this test program as wrappers
around malloc).
Tested with gcc (GCC) 11.0.0 20201028 (experimental), based on commit
c25d317cf7d4ea8df0402feb939ce286e5f42988.
[Bug target/96892] [ARM]Wrong __stack_chk_guard for comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96892 --- Comment #3 from John Dong --- (In reply to Thomas Preud'homme from comment #2) > Wouldn't it be enough to add: > > "emit_move_insn (operands[3], gen_rtx_MEM(SImode, operands[3]));" > > just before the line "if (TARGET_32BIT)" in stack_protect_combined_test_insn > insn pattern? but adding two ldr instructions may significantly harm performance ;(
[Bug rtl-optimization/97607] New: Spurious sign extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97607
Bug ID: 97607
Summary: Spurious sign extension
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: elronnd at elronnd dot net
Target Milestone: ---
The following code
extern void fun(char);
void wrapper(char x) { fun(x); }
Should compile 'wrapper' to a single jump, but instead it does this (on amd64):
wrapper:
movsx edi, dil
jmp fun
Presumably 'x' is getting promoted to int in wrapper, and the promotion never
gets removed.
[Bug target/97606] New: internal compiler error: in extract_constrain_insn, at recog.c:2196
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97606
Bug ID: 97606
Summary: internal compiler error: in extract_constrain_insn, at
recog.c:2196
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
Created attachment 49455
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49455&action=edit
C++ source code
The attached C++ code, with compiler flags -c -w -std=c++14 -mavx512cd -O1,
on c86_64, does this:
bug662.cc: In member function ‘virtual void v::t(void*, const D*, const D*,
void
*, unsigned int, unsigned int, unsigned int) const’:
bug662.cc:61:3: error: insn does not satisfy its constraints:
61 | }
| ^
(insn 22 21 23 2 (set (reg:V8DI 20 xmm0 [108])
(plus:V8DI (reg:V8DI 20 xmm0 [orig:104 ba ] [104])
(vec_duplicate:V8DI (mem/f:DI (mem/c:DI (plus:DI (reg/f:DI 6 bp)
(const_int -56 [0xffc8])) [14 %sfp+-8
S8
A64]) [1 p2_14(D)->ac+0 S8 A64] "bug662.cc":58:12 3497 {*addv8di3}
(expr_list:REG_EQUIV (mem/c:V8DI (symbol_ref:DI ("aq") [flags 0x2]
) [10 aq+0 S64 A512])
(nil)))
during RTL pass: reload
bug662.cc:61:3: internal compiler error: in extract_constrain_insn, at
recog.c:2
196
0xec00e6 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../trunk.git/gcc/rtl-error.c:108
0xec0115 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../trunk.git/gcc/rtl-error.c:118
0xe8ac69 extract_constrain_insn(rtx_insn*)
../../trunk.git/gcc/recog.c:2196
The bug first seems to appear sometime between 20201021 and 20201022.
[Bug tree-optimization/97605] New: unused conditionally freed allocation not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97605
Bug ID: 97605
Summary: unused conditionally freed allocation not eliminated
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
In the test program below GCC eliminates the unnecessary pair of malloc/free in
f() but it doesn't perform the likely much more impactful optimization in g()
whose body could be transformed into:
void* g (int i)
{
if (i)
return 0;
return malloc (1);
}
$ cat q.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout q.c
typedef __SIZE_TYPE__ size_t;
extern void free (void*);
extern void* malloc (size_t);
void f (int i)
{
void *p = malloc (1); // eliminated
free (p); // ditto
}
void* g (int i)
{
void *p = malloc (1);
if (i)
{
free (p);
return 0;
}
return p;
}
;; Function f (f, funcdef_no=0, decl_uid=1936, cgraph_uid=1, symbol_order=0)
f (int i)
{
[local count: 1073741824]:
return;
}
;; Function g (g, funcdef_no=1, decl_uid=1940, cgraph_uid=2, symbol_order=1)
Removing basic block 5
g (int i)
{
void * p;
void * _1;
[local count: 1073741824]:
p_5 = malloc (1);
if (i_6(D) != 0)
goto ; [9.39%]
else
goto ; [90.61%]
[local count: 100824360]:
free (p_5);
[local count: 1073741824]:
# _1 = PHI <0B(3), p_5(2)>
return _1;
}
[Bug gcov-profile/97461] [11 Regression] allocate_gcov_kvp() deadlocks in firefox LTO+PGO build (overridden malloc() recursion)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97461 --- Comment #13 from Sergei Trofimovich --- Tried firefox-82 with LTO+PGO today on gcc-11-4428-g4a369d199bf. It gets a lot more forward, but still gets stuck. This time on free()->allocate_gcov_kvp ()->alloc() deadloc. The backtrace: (gdb) bt #0 __lll_lock_wait (futex=0x77800018, private=0) at lowlevellock.c:52 #1 0x77f69305 in __GI___pthread_mutex_lock (mutex=0x77800018) at ../nptl/pthread_mutex_lock.c:135 #2 0x555b2151 in arena_t::MallocSmall(unsigned long, bool) () #3 0x555b307c in arena_t::Malloc(unsigned long, bool) () #4 0x555b41f2 in calloc () #5 0x556a49ab in allocate_gcov_kvp () at /var/tmp/portage/sys-devel/gcc-11.0.0_pre/work/gcc-11.0.0_pre/libgcc/libgcov.h:431 #6 gcov_topn_add_value (count=1, use_atomic=1, increment_total=1, value=496, counters=0x557158c0 <__gcov3._ZL20arena_run_reg_dallocP11arena_run_tP11arena_bin_tPvm>) at /var/tmp/portage/sys-devel/gcc-11.0.0_pre/work/gcc-11.0.0_pre/libgcc/libgcov.h:477 #7 __gcov_topn_values_profiler_body (use_atomic=1, value=496, counters=0x557158c0 <__gcov3._ZL20arena_run_reg_dallocP11arena_run_tP11arena_bin_tPvm>) at /var/tmp/portage/sys-devel/gcc-11.0.0_pre/work/gcc-11.0.0_pre/libgcc/libgcov-profiler.c:103 #8 __gcov_topn_values_profiler_atomic (counters=0x557158c0 <__gcov3._ZL20arena_run_reg_dallocP11arena_run_tP11arena_bin_tPvm>, value=496) at /var/tmp/portage/sys-devel/gcc-11.0.0_pre/work/gcc-11.0.0_pre/libgcc/libgcov-profiler.c:128 #9 0x555b1065 in arena_t::DallocSmall(arena_chunk_t*, void*, arena_chunk_map_t*) () #10 0x555b166c in free () #11 0x7fffe1b0ef1a in CollectProcessInfo(ProcessInfo&) () at /home/slyfox/tmp/portage/www-client/firefox-82.0/work/firefox_build/instrumented/dist/firefox/libxul.so #12 0x7fffea0afa72 in PreRecordMetaInformation() () at /home/slyfox/tmp/portage/www-client/firefox-82.0/work/firefox_build/instrumented/dist/firefox/libxul.so #13 0x7fffea0b28c8 in profiler_shutdown(IsFastShutdown) () at /home/slyfox/tmp/portage/www-client/firefox-82.0/work/firefox_build/instrumented/dist/firefox/libxul.so #14 0x7fffea7c6aa0 in XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) () at /home/slyfox/tmp/portage/www-client/firefox-82.0/work/firefox_build/instrumented/dist/firefox/libxul.so #15 0x7fffea7c7543 in XRE_main(int, char**, mozilla::BootstrapConfig const&) () at /home/slyfox/tmp/portage/www-client/firefox-82.0/work/firefox_build/instrumented/dist/firefox/libxul.so #16 0x7fffea7cfbd0 in mozilla::BootstrapImpl::XRE_main(int, char**, mozilla::BootstrapConfig const&) () at /home/slyfox/tmp/portage/www-client/firefox-82.0/work/firefox_build/instrumented/dist/firefox/libxul.so #17 0x5559a370 in do_main(int, char**, char**) () #18 0x555980a1 in main () Worth filing a new bug, or this would be good enough?
[Bug driver/97574] Allow for nul output with Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97574
--- Comment #4 from Tamar Christina ---
Submitted a patch to get the driver to stop mangling nul so it makes it easier
for binutils to detect.
That said Jonathan is right in that there's still a binutils bug here. I had
forgotten that even though MSDN recommends against using extensions with
special filenames that it's not an error.
It looks like binutils is failing in bfd_close, looks like it's using stat to
detect special files, however on windows stat("nul") seems to be returning
_S_IFREG. You'll need to report a ticker there for this.
I'll leave this open since the nul device shouldn't get an extension.
[Bug preprocessor/97604] New: Bad digit separators accepted in pp-numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97604 Bug ID: 97604 Summary: Bad digit separators accepted in pp-numbers Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: jsm28 at gcc dot gnu.org CC: emsr at gcc dot gnu.org Target Milestone: --- cpplib lexes pp-numbers in lex_number. Following bug 64626 that includes some logic to disallow a pp-number ending with C++ digit separators. However, that logic is insufficient to cover all cases where the lexing includes too many characters in the pp-number. Compile the following with -std=c++17: int a = 0x0'e-0xe; This gives a bogus error: t.cc:1:9: error: unable to find numeric literal operator 'operator""-0xe' 1 | int a = 0x0'e-0xe; | ^ t.cc:1:9: note: use '-fext-numeric-literals' to enable more built-in suffixes The pp-number syntax starts a pp-number with "digit" or ". digit" and then allows various things to follow, one of which is "' nondigit" and another one of which is "e sign". The longest possible preprocessing token starting with the first 0 in the above example is 0x0'e because the text preceding "e-" ends with "'" and so is not a pp-number. So 0x0'e is a preprocessing token, followed by "-", and the above is in fact a subtraction of two separate integer literals, i.e. valid C++ input. "'" must only be accepted in a pp-number when followed by a digit or nondigit, and if that nondigit is e, E, p or P, it terminates the pp-number if a sign follows. Although I haven't given examples here, you can probably construct rejects-valid examples (ones involving macro expansion, at least) also for the case of wrongly accepting a digit separator followed by a UCN / UTF-8 character (an identifier-nondigit that is not a nondigit) or '.'. The case of consecutive digit separators shouldn't introduce rejects-valid bugs because '' isn't valid at the start of a preprocessing token, but bug 83873 would be fixed by following the syntax in lex_number and rejecting them there rather than trying to catch them later.
[Bug tree-optimization/97603] New: Failure to optimize out compare into reuse of subtraction result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97603
Bug ID: 97603
Summary: Failure to optimize out compare into reuse of
subtraction result
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 g();
int f(int a, int b)
{
if (a != b)
return a - b;
return g();
}
This can be optimized to using the result of `a - b` to check for `a != b`.
This is done by LLVM, but not by GCC. For example, on x86, LLVM generates this
:
f(int, int):
sub edi, esi
jne .LBB0_1
jmp g()
.LBB0_1:
mov eax, edi
ret
GCC generates this :
f(int, int):
cmp edi, esi
je .L7
mov eax, edi
sub eax, esi
ret
.L7:
jmp g()
[Bug preprocessor/97602] New: #line overflow check incomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97602 Bug ID: 97602 Summary: #line overflow check incomplete Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: jsm28 at gcc dot gnu.org Target Milestone: --- Preprocessing the following test with -pedantic does not produce a diagnostic, just silent wrapping of the line number. #line 50 By comparison, if you instead have #line 30 then you get a diagnostic t.c:1:7: warning: line number out of range 1 | #line 30 | ^~ The code in directives.c:strtolinenum tries to check for overflow after it occurs, with logic "if (reg < reg_prev)" that doesn't cover all cases. Checking before it occurs (allowing properly for the case of UINT_MAX / 10 where overflow depends on the value of the next digit) is needed instead.
[Bug libfortran/97581] libgfortran/intrinsics/random.c:754: bad array size ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97581 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|WAITING |ASSIGNED --- Comment #3 from anlauf at gcc dot gnu.org --- Patch submitted: https://gcc.gnu.org/pipermail/fortran/2020-October/055242.html
[Bug rtl-optimization/97497] gcse wrong code generation with partial register clobbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97497 --- Comment #8 from CVS Commits --- The master branch has been updated by Andreas Krebbel : https://gcc.gnu.org/g:2b3e722a3ca1b9dcfff1c016e651d0d681de1af0 commit r11-4460-g2b3e722a3ca1b9dcfff1c016e651d0d681de1af0 Author: Andreas Krebbel Date: Tue Oct 27 20:57:39 2020 +0100 Fix PR97497 This works around a limitation of gcse with handling of partially clobbered registers. With this patch our GOT pointer register r12 is not marked as partially clobbered anymore for the -m31 -mzarch -fpic combination. This is correct since all the bits in r12 we actually care about are in fact preserved. gcc/ChangeLog: PR rtl-optimization/97497 * config/s390/s390.c (s390_hard_regno_call_part_clobbered): Do not return true for r12 when -fpic is used. gcc/testsuite/ChangeLog: * gcc.target/s390/pr97497.c: New test.
[Bug fortran/97491] Wrong restriction for VALUE arguments of pure procedures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97491 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #5 from anlauf at gcc dot gnu.org --- Fixed on master so far. If there is no fallout, and if after some waiting time the patch still seems to be safe, I'll consider to backport to 10-branch, as Paul mentioned on the ML.
[Bug fortran/97491] Wrong restriction for VALUE arguments of pure procedures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97491 --- Comment #4 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:a764c40079a493826a3678174f908941a383644e commit r11-4459-ga764c40079a493826a3678174f908941a383644e Author: Harald Anlauf Date: Tue Oct 27 20:25:23 2020 +0100 PR fortran/97491 - Wrong restriction for VALUE arguments of pure procedures A dummy argument with the VALUE attribute may be redefined in a PURE or ELEMENTAL procedure. Adjust the associated purity check. gcc/fortran/ChangeLog: * resolve.c (gfc_impure_variable): A dummy argument with the VALUE attribute may be redefined without making a procedure impure. gcc/testsuite/ChangeLog: * gfortran.dg/value_8.f90: New test.
[Bug libstdc++/97600] [ranges] result of static assertion depends on unrelated statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97600
--- Comment #2 from Patrick Palka ---
I think all views whose begin()/end() has a placeholder return type and
performs direct initialization of a _Iterator/_Sentinel from *this are affected
by some variant of this issue.
A library-side workaround would be to templatize view_interface::operator
bool() like so:
diff --git a/libstdc++-v3/include/bits/ranges_util.h
b/libstdc++-v3/include/bits/ranges_util.h
index cc50e2ad4e4..8563a5dfcb0 100644
--- a/libstdc++-v3/include/bits/ranges_util.h
+++ b/libstdc++-v3/include/bits/ranges_util.h
@@ -86,13 +86,15 @@ namespace ranges
empty() const requires forward_range
{ return ranges::begin(_M_derived()) == ranges::end(_M_derived()); }
- constexpr explicit
- operator bool() requires requires { ranges::empty(_M_derived()); }
- { return !ranges::empty(_M_derived()); }
-
- constexpr explicit
- operator bool() const requires requires { ranges::empty(_M_derived()); }
- { return !ranges::empty(_M_derived()); }
+ template _Tp>
+ constexpr explicit
+ operator _Tp() requires requires { ranges::empty(_M_derived()); }
+ { return !ranges::empty(_M_derived()); }
+
+ template _Tp>
+ constexpr explicit
+ operator _Tp() const requires requires { ranges::empty(_M_derived()); }
+ { return !ranges::empty(_M_derived()); }
constexpr auto
data() requires contiguous_iterator>
So that when we considering this conversion function in step 5, we deduce
_Tp=_Iterator and short circuit satisfaction of the conversion function's
associated constraints in step 6.
[Bug libstdc++/97600] [ranges] result of static assertion depends on unrelated statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97600
Patrick Palka changed:
What|Removed |Added
Known to fail||10.2.0, 11.0
--- Comment #1 from Patrick Palka ---
This happens because of the following chain of events:
1. Calling basic_istream_view::begin() entails instantiating its definition to
perform return type deduction.
2. We perform overload resolution of the direct-initialization _Iterator{*this}
inside its definition.
3. As part of overload resolution, we consider the copy ctor _Iterator(const
_Iterator&).
4. We try to find an implicit conversion sequence from basic_istream_view to
const _Iterator&.
5. We consider a conversion sequence that goes through the conversion function
view_interface::operator bool().
6. We check the conversion function's constraint 'requires {
ranges::empty(_M_derived()); }'.
7. ranges::empty() checks that view_interface::empty() is callable and
therefore has satisfied constraints
8. view_interface::empty() requires range, which requires
that basic_istream_view::begin() is callable, which requires that we deduce its
return type. But we're already in the the middle of deducing it, so we hit a
SFINAE error, which causes satisfaction of range to fail.
9. We cache this negative satisfaction result for (the atomic constraint of)
range.
10. We rule out the copy ctor during overload resolution and eventually resolve
the direct-initialization in the expected way.
When we later evaluate the static assert, we just return the cached
satisfaction result.
I have an experimental patch here
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557117.html that makes
us rule out the conversion function in step 5 sooner without first checking its
constraints, which would be one way to fix this.
[Bug fortran/97592] Incorrectly set pointer remapping with array pointer argument to CONTIGUOUS dummy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97592 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #1 from anlauf at gcc dot gnu.org --- gfortran seems to see the CONTIGUOUS attribute in the declaration of the dummy argument C_2D of SetPointer, but no corresponding attribute to B_2D. Workaround: add CONTIGUOUS to the declaration of B_2D.
[Bug c/97598] -Wself-init alone fails to warn of a pointless assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97598 --- Comment #1 from Philip R Brenan --- Created attachment 49454 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49454&action=edit Test case
[Bug c++/97601] New: ICE when using type determined by std::tuple_element_t<...>, on tuple generated from type id stored in std::array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97601
Bug ID: 97601
Summary: ICE when using type determined by
std::tuple_element_t<...>, on tuple generated from
type id stored in std::array
Product: gcc
Version: 10.2.1
URL: https://gcc.godbolt.org/z/n13PKr
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: milasudril at gmail dot com
Target Milestone: ---
Host: any
Target: any
Code that triggers the bug(s). It uses enum values stored in an std::array, to
generate an std::tuple. Using std::tuple_element_t on the generated tuple
causes ICE.
Compiler options: -Wall -std=c++20 -O3
#include
#include
#include
#include
namespace Enum
{
template
using Empty = std::type_identity;
template
constexpr auto add(T base, std::underlying_type_t offset = 1)
{
return static_cast(std::underlying_type_t(base) +
offset);
}
namespace detail
{
template
class EnumItemTraits,
class T = std::make_integer_sequence>
struct make_tuple_from_array;
template class EnumItemTraits,
size_t index>
struct int_to_type_array: public EnumItemTraits
{
};
template class EnumItemTraits,
size_t... indices>
struct make_tuple_from_array>
{
using type =
std::tuple::type...>;
};
}
template class EnumItemTraits>
using TupleFromTypeArray = typename
detail::make_tuple_from_array::type;
}
enum class PortType : size_t
{
RgbaPixels,
GrayscaleRealPixels,
GrayscaleComplexPixels,
};
constexpr PortType begin(Enum::Empty) { return PortType::RgbaPixels;
}
constexpr PortType end(Enum::Empty)
{
return Enum::add(PortType::GrayscaleComplexPixels);
}
using vec4_t __attribute__((vector_size(16))) = float;
using RgbaValue= vec4_t;
using RealValue= double;
using ComplexValue = std::complex;
template
struct PortTypeToType;
template<>
struct PortTypeToType
{
using type = std::unique_ptr;
};
template<>
struct PortTypeToType
{
using type = std::unique_ptr;
};
template<>
struct PortTypeToType
{
using type = std::unique_ptr;
};
template
struct InputPortType
{
using type = std::conditional_t<(sizeof(T) <= 16), T,
std::reference_wrapper>;
};
template
struct InputPortType>
{
using type = T const*;
};
template
struct InputPortType>
{
using type = std::reference_wrapper;
};
namespace detail
{
template
struct GenInputPortType
{
using type = typename InputPortType::type>::type;
};
}
namespace detail
{
template
constexpr decltype(auto) create_impl(F&& f, std::index_sequence)
{
return Object{f(std::integral_constant{})...};
}
}
template
constexpr decltype(auto) createTuple(F&& f)
{
return detail::create_impl(std::forward(f),
std::make_index_sequence>{});
}
template
void doStuffWithTArg(T);
template
void doStuffWithT();
template
class InArgTuple
{
using storage_type = Enum::TupleFromTypeArray;
public:
constexpr explicit InArgTuple()
: m_data{createTuple([](Tag) {
using T = typename
detail::GenInputPortType::type;
// Trunk gets stuck here
// internal compiler error: in cxx_eval_constant_expression, at
cp/constexpr.c:6188
using OtherT = std::tuple_element_t;
static_assert(std::is_same_v);
T foo{};
// This triggers ICE: in finish_expr_stmt, at cp/semantics.c:681
// doStuffWithT();
doStuffWithT(); // Not ICE
OtherT bar{};
// This also triggers ICE: in tsubst_copy, at cp/pt.c:16485
//doStuffWithTArg(bar);
doStuffWithTArg(foo); // Not ICE
//
// Also in tsubst_copy, at cp/pt.c:16485
//
// return bar;
//
return foo;
})}
{
}
static constexpr auto size() { return types.size(); }
template
constexpr auto get() const
{
static_assert(index < types.size());
return std::get(m_data);
}
private:
storage_type m_data;
};
void test()
{
constexpr std::array types{PortType::RgbaPixels};
InArgTuple test{};
}
[Bug libstdc++/97600] New: [ranges] result of static assertion depends on unrelated statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97600
Bug ID: 97600
Summary: [ranges] result of static assertion depends on
unrelated statement
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
$ cat testcase.C
$#include
#include
int main() {
using namespace std::ranges;
basic_istream_view> v;
v.begin();
static_assert(range);
}
$ g++ -std=c++20 testcase.C
testcase.C:8:17: error: static assertion failed
8 | static_assert(range);
| ^~
Unexpectedly, this static assert fails. Even more unexpectedly, if we remove
the 'v.begin()' line before it, then the static assert succeeds.
[Bug ipa/97586] [11 Regression] "make check" failures in binutils with -flto since r11-3641-gc34db4b6f8a5d803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97586 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #17 from H.J. Lu --- Fixed for GCC 11.
[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504 --- Comment #16 from Eric Botcazou --- > It's actually a partial cross compiler (-m32), please take a look at the > build log. What's this beast exactly? I'm afraid the build log is useless here, it would be better to post the configure line and the CC or CXX variables if any.
[Bug target/97457] [10/11 Regression] SVE: wrong code since r10-4752-g2d56600c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97457 rsandifo at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org CC||rsandifo at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-10-27 --- Comment #3 from rsandifo at gcc dot gnu.org --- Ugh. This is yet another problem with calculating value ranges for POLY_INT_CSTs. We have: ivtmp_76 = ASSERT_EXPR POLY_INT_CST [9, 4294967294]> where the VQ coefficient is unsigned but is effectively acting as a negative number. We wrongly give the POLY_INT_CST the range: [9, INT_MAX] and things go downhill from there. I guess this is the final nail in the coffin for doing VRP on POLY_INT_CSTs. :-( For other similarly exotic testcases we could have overflow for any coefficient, not just those that could be treated as contextually negative. Let's see what the fallout is from removing the code...
[Bug target/97535] [9/10 Regression] On AArch64 memcpy expansion cannot handle length > 32-bit signed int max
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97535 Tamar Christina changed: What|Removed |Added Summary|[9/10/11 Regression] On |[9/10 Regression] On |AArch64 memcpy expansion|AArch64 memcpy expansion |cannot handle length > |cannot handle length > |32-bit signed int max |32-bit signed int max Status|NEW |ASSIGNED --- Comment #6 from Tamar Christina --- fixed in trunk, will backport in a few days.
[Bug debug/97599] [8/9/10/11 Regression] missing unspecified_parameters DIE in DWARF for functions with variable arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97599 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |8.5 CC||rguenth at gcc dot gnu.org
[Bug debug/97599] New: [8/9/10/11 Regression] missing unspecified_parameters DIE in DWARF for functions with variable arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97599
Bug ID: 97599
Summary: [8/9/10/11 Regression] missing unspecified_parameters
DIE in DWARF for functions with variable arguments
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: aldyh at gcc dot gnu.org, woodard at redhat dot com
Depends on: 71855
Target Milestone: ---
Target: x86-64-Linux
+++ This bug was initially created as a clone of Bug #71855 +++
Since PR71855, we emit bad debug info e.g. for
#include
static __attribute__((noinline)) int
foo (int unused, int args, ...)
{
va_list ap;
int ret = 0;
va_start (ap, args);
if (args)
ret = va_arg (ap, int);
va_end (ap);
return ret;
}
int
bar (int x)
{
return foo (0, 0) + foo (0, 1, 1) + foo (0, 1, 3) + foo (0, 0) + foo (0, 0,
4);
}
Also, with LTO:
#include
void
foo (int args, ...)
{
va_list ap;
va_start (ap, args);
va_end (ap);
}
gcc -shared -g -fpic -flto test.c
As written in https://bugzilla.redhat.com/show_bug.cgi?id=1891787 , it seems it
isn't enough to rely on the DW_TAG_unspecified_parameters DIE being present
among the abstract origin DIE of the DW_TAG_subprogram's children; the debug
info consumer can't know if the clone of that original function is really still
variadic, or if e.g. the variadic-ness has been removed.
For the non-LTO case, it is I think fairly easy to do, subr_die != old_die
should be true if it is a fresh new DIE, but I'm afraid for in_lto_p we don't
really know easily if it is a fresh new DIE or not.
As we have nothing to lookup in the hash tables to find out cheaply if it is
there or not already, the following is a painful way of doing that.
Thoughts on that?
--- gcc/dwarf2out.c.jj 2020-10-26 10:53:56.0 +0100
+++ gcc/dwarf2out.c 2020-10-27 17:56:07.249711468 +0100
@@ -23365,6 +23365,35 @@ gen_subprogram_die (tree decl, dw_die_re
else if (DECL_INITIAL (decl) == NULL_TREE)
gen_unspecified_parameters_die (decl, subr_die);
}
+ else if (prototype_p (TREE_TYPE (decl))
+ && stdarg_p (TREE_TYPE (decl)))
+ {
+ /* Emit DW_TAG_unspecified_parameters even in late DWARF,
+but ensure to do it only when it isn't present already.
+If subr_die != old_die, this is a new DIE to which it
+should be added, otherwise if in_lto_p, we don't really
+know if it is a freshly created one or something older,
+so look it up. */
+ bool emit = subr_die != old_die;
+ if (!emit && in_lto_p)
+ {
+ dw_die_ref c;
+ emit = true;
+ FOR_EACH_CHILD (subr_die, c,
+ do
+ {
+ if (c->die_tag
+ == DW_TAG_unspecified_parameters)
+ {
+ emit = false;
+ break;
+ }
+ }
+ while (0));
+ }
+ if (emit)
+ gen_unspecified_parameters_die (decl, subr_die);
+ }
}
if (subr_die != old_die)
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71855
[Bug 71855] duplicate unspecified_parameters DIE in DWARF for functions with
variable arguments
[Bug middle-end/19430] taking address of a var causes missing uninitialized warning (virtual PHI with MEM)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19430
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #35 from Martin Sebor ---
GCC 11 issues a warning when the address of an uninitialized variable is passed
to a function that takes a const pointer but it (still) doesn't warn when the
address escapes. In both cases, it's possible for the called function to store
a value into the variable but because it's highly unlikely issuing a warning
regardless would be appropriate. In addition, in cases where the address of
the variable doesn't escape until after the function call its value cannot be
affected even when the address is assigned to a non-const pointer. The escape
analysis is flow insensitive so it alone cannot be relied on to make the
distinction. But modifying variables this way is rare so issuing the warning
regardless is likely worthwhile.
$ cat a.c && gcc -O2 -S -Wall a.c
extern void f (const void*);
int g (void)
{
int i;
f (&i); // -Wmaybe-uninitialized
return i;
}
int h (void)
{
extern const void *p;
int i;
f (0);
p = &i;
return i; // missing -Wmaybe-uninitialized
}
a.c: In function ‘int g()’:
a.c:6:5: warning: ‘i’ may be used uninitialized [-Wmaybe-uninitialized]
6 | f (&i);
| ~~^~~~
a.c:1:13: note: by argument 1 of type ‘const void*’ to ‘void f(const void*)’
declared here
1 | extern void f (const void*);
| ^
a.c:5:7: note: ‘i’ declared here
5 | int i;
| ^
[Bug target/97535] [9/10/11 Regression] On AArch64 memcpy expansion cannot handle length > 32-bit signed int max
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97535 --- Comment #5 from CVS Commits --- The master branch has been updated by Tamar Christina : https://gcc.gnu.org/g:0f801e0b6cc9f67c9a8983127e23161f6025c5b6 commit r11-4453-g0f801e0b6cc9f67c9a8983127e23161f6025c5b6 Author: Tamar Christina Date: Tue Oct 27 16:30:31 2020 + AArch64: Fix overflow in memcopy expansion on aarch64. Currently the inline memcpy expansion code for AArch64 is using a signed int to hold the number of elements to copy. When you giver give it a value larger than INT_MAX it will overflow. The overflow causes the maximum number of instructions we want to expand to check to fail since this assumes an unsigned number. This patch changes the maximum isns arithmetic to be unsigned HOST_WIDE_INT. note that the calculation *must* remained signed as the memcopy issues overlapping unaligned copies. This means the pointer must be moved back and so you need signed arithmetic. gcc/ChangeLog: PR target/97535 * config/aarch64/aarch64.c (aarch64_expand_cpymem): Use unsigned arithmetic in check. gcc/testsuite/ChangeLog: PR target/97535 * gcc.target/aarch64/pr97535.c: New test.
[Bug tree-optimization/97595] [11 Regression] bogus -Wstringop-overflow due to DECL_SIZE_UNIT underreporting field size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97595
Martin Sebor changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
Summary|[11 Regression] warning:|[11 Regression] bogus
|writing 1 byte into a |-Wstringop-overflow due to
|region of size 0|DECL_SIZE_UNIT
|[-Wstringop-overflow=] |underreporting field size
Keywords||diagnostic
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2020-10-27
--- Comment #3 from Martin Sebor ---
I can confirm the warning but I'm not sure the bug is in the middle end code.
Let me CC Jason for his comments.
The warning triggers for the MEM_REF below:
MEM[(char &)_10 + 224] = _24;
in the following GIMPLE ("type" is char). The destination of the access is
this_3(D)->D.45669 which is the basic_istream subobject. Its size reported by
DECL_SIZE_UNIT() in component_ref_size() is 16. The initial offset (i.e., _10)
is indeterminate but it's taken to be in the range bounded by the size of the
object, or [0, 16]. Given that, the constant offset 224 is determined to be
out of bounds.
The change introduced in r11-3827 that triggers the warning is the assumption
that unless determined otherwise, an indeterminate offset into an object must
be bounded by the object's size.
But sizeof (basic_istream) is 280, not 16. This is also what TYPE_SIZE_UNIT()
reports, so the bug here is either in DECL_SIZE_UNIT(), or in using it in lieu
of TYPE_SIZE_UNIT(). I'd expect the two to return the same result so this
seems like a front end bug to me but I will defer to Jason.
std::basic_iostream::swap (struct basic_iostream * const this, struct
basic_iostream & __rhs)
{
struct basic_istream * _1;
struct basic_istream * _2;
int (*) () * _7;
long int _8;
sizetype _9;
struct basic_ios * _10;
int (*) () * _11;
long int _12;
sizetype _13;
struct basic_ios & _14;
long int _15;
long int _16;
struct ios_base * _17;
struct ios_base * _18;
struct locale * _19;
struct locale * _20;
struct basic_ostream * _21;
struct basic_ostream * _22;
char _23;
char _24;
bool _25;
bool _26;
[local count: 1073741824]:
_1 = &this_3(D)->D.45669;
_2 = &__rhs_4(D)->D.45669;
_7 = MEM[(struct basic_istream *)this_3(D)]._vptr.basic_istream;
_8 = MEM[(long int *)_7 + -24B];
_9 = (sizetype) _8;
_10 = _1 + _9;
_11 = MEM[(struct basic_istream *)__rhs_4(D)]._vptr.basic_istream;
_12 = MEM[(long int *)_11 + -24B];
_13 = (sizetype) _12;
_14 = _2 + _13;
_17 = &_10->D.42253;
_18 = &_14->D.42253;
std::ios_base::_M_swap (_17, _18);
_19 = &_10->D.42253._M_ios_locale;
std::basic_ios::_M_cache_locale (_10, _19);
_20 = &_14->D.42253._M_ios_locale;
std::basic_ios::_M_cache_locale (_14, _20);
_21 = MEM[(struct basic_ostream * &)_10 + 216];
_22 = MEM[(struct basic_ostream * &)_14 + 216];
MEM[(struct basic_ostream * &)_10 + 216] = _22;
MEM[(struct basic_ostream * &)_14 + 216] = _21;
_23 = MEM[(type &)_10 + 224];<<< -Wstringop-overflow
_24 = MEM[(type &)_14 + 224];
MEM[(char &)_10 + 224] = _24;
MEM[(char &)_14 + 224] = _23;
_25 = MEM[(type &)_10 + 225];
_26 = MEM[(type &)_14 + 225];
MEM[(bool &)_10 + 225] = _26;
MEM[(bool &)_14 + 225] = _25;
_15 = MEM[(type &)this_3(D) + 8];
_16 = MEM[(type &)__rhs_4(D) + 8];
MEM[(long int &)this_3(D) + 8] = _16;
MEM[(long int &)__rhs_4(D) + 8] = _15;
return;
}
[Bug c/97598] New: -Wself-init alone fails to warn of a pointless assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97598
Bug ID: 97598
Summary: -Wself-init alone fails to warn of a pointless
assignment
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: philiprbrenan at gmail dot com
Target Milestone: ---
Created attachment 49453
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49453&action=edit
-Wself-init alone fails to warn of a pointless assignment
The assignment int a = a; below does not create a warning to let me know that
the assignment is pointless even when I use -Winit-self xor -Wall as per the
attached image. The warning only appears if I enable both options. This leads
to subtle errors in generated ({ code ...}) constructs that are difficult to
debug. Please add a warning for such pointless assignments that is enabled
with -Wall.
#include
int main(void)
{int a = 1;
{int a = a; // Pointless
printf(" %d\n", a);
}
printf(" %d\n", a);
}
// 0
// 1
GCC details:
gcc -v -save-temps -Winit-self assign.c
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
10.1.0-2ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-10
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-10-eDoCEC/gcc-10-10.1.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-eDoCEC/gcc-10-10.1.0/debian/tmp-gcn/usr,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.1.0 (Ubuntu 10.1.0-2ubuntu1~18.04)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Winit-self' '-mtune=generic'
'-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/10/cc1 -E -quiet -v -imultiarch x86_64-linux-gnu
assign.c -mtune=generic -march=x86-64 -Winit-self -fpch-preprocess
-fasynchronous-unwind-tables -fstack-protector-strong -Wformat
-Wformat-security -o assign.i
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/10/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/10/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-linux-gnu/10/include
/usr/local/include
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Winit-self' '-mtune=generic'
'-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/10/cc1 -fpreprocessed assign.i -quiet -dumpbase
assign.c -mtune=generic -march=x86-64 -auxbase assign -Winit-self -version
-fasynchronous-unwind-tables -fstack-protector-strong -Wformat
-Wformat-security -o assign.s
GNU C17 (Ubuntu 10.1.0-2ubuntu1~18.04) version 10.1.0 (x86_64-linux-gnu)
compiled by GNU C version 10.1.0, GMP version 6.1.2, MPFR version
4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C17 (Ubuntu 10.1.0-2ubuntu1~18.04) version 10.1.0 (x86_64-linux-gnu)
compiled by GNU C version 10.1.0, GMP version 6.1.2, MPFR version
4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 797ff541be7d2acc7d0ced3c057e002c
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Winit-self' '-mtune=generic'
'-march=x86-64'
as -v --64 -o assign.o assign.s
GNU assembler version 2.30 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Ubuntu) 2.30
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/10/:/usr/lib/gcc/x86_64-linux-gnu/10/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/10/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/10/:/usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/10/../../../../lib/:/l
[Bug tree-optimization/97579] [11 Regression] ICE in gimple_expand_vec_cond_expr, at gimple-isel.cc:201 since r11-4123-g128f43cf679e5156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97579 --- Comment #2 from Martin Liška --- (In reply to Richard Biener from comment #1) > So we have used_vec_cond_exprs == 1 and a V16SI eq/ne compare with a > vector(16) HImode result. We fall into > > gcc_assert (known_eq (GET_MODE_SIZE (mode), GET_MODE_SIZE (cmp_op_mode)) > && known_eq (GET_MODE_NUNITS (mode), >GET_MODE_NUNITS (cmp_op_mode))); > > then but this is clearly a case where we _have_ to use the vec_cmp_expr > (because of the scalar mode). So either simply remove the > used_vec_cond_exprs check or amend it with the negative of the above assert. No, used_vec_cond_exprs == 2, but we fail here: 166if (used_vec_cond_exprs >= 2 167&& (get_vcond_mask_icode (mode, TYPE_MODE (op0a_type)) 168!= CODE_FOR_nothing) 169&& expand_vec_cmp_expr_p (op0a_type, TREE_TYPE (lhs), tcode)) where: #0 get_vcond_mask_icode (vmode=E_HImode, mmode=E_V16SImode) at /home/marxin/Programming/gcc/gcc/optabs-query.h:131 returns false.
[Bug tree-optimization/97596] [11 Regression] ICE in wide_int_to_tree_1, at tree.c:1535 r11-3685-gfcae5121154d1c33
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97596 Martin Liška changed: What|Removed |Added Last reconfirmed||2020-10-27 Priority|P3 |P1 Summary|[11 Regression] ICE in |[11 Regression] ICE in |wide_int_to_tree_1, at |wide_int_to_tree_1, at |tree.c:1535 |tree.c:1535 ||r11-3685-gfcae5121154d1c33 Status|UNCONFIRMED |NEW CC||aldyh at gcc dot gnu.org, ||amacleod at redhat dot com, ||marxin at gcc dot gnu.org Target Milestone|--- |11.0 Known to work||10.2.0 Known to fail||11.0 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Started with r11-3685-gfcae5121154d1c33.
[Bug c++/97597] [11 Regression] ICE in build_over_call, at cp/call.c:9034
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97597 Marek Polacek changed: What|Removed |Added CC||jason at gcc dot gnu.org Priority|P3 |P1 --- Comment #2 from Marek Polacek --- Started with r11-2704: commit 320054784250e572cb75d6f69ab44b2330d61d8b Author: Jason Merrill Date: Wed Aug 12 05:45:02 2020 -0400 c++: Copy elision and [[no_unique_address]]. [PR93711]
[Bug c++/97597] [11 Regression] ICE in build_over_call, at cp/call.c:9034
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97597 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Target Milestone|--- |11.0 Last reconfirmed||2020-10-27 CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c++/97597] New: [11 Regression] ICE in build_over_call, at cp/call.c:9034
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97597
Bug ID: 97597
Summary: [11 Regression] ICE in build_over_call, at
cp/call.c:9034
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: ---
g++-11.0.0-alpha20201025 snapshot (g:308e40331f9d2820f8286769b5fc764671187364)
ICEs when compiling the following testcase, reduced from
test/CodeGenCXX/copy-constructor-elim-2.cpp from the clang 10.0.1 test suite:
struct pq {
pq (const pq &);
};
struct a9 {
operator pq () const;
};
struct zp : pq {
zp (const a9 &k3) : pq (k3) { }
};
% g++-11.0.0 -c oowewmvl.cpp
oowewmvl.cpp: In constructor 'zp::zp(const a9&)':
oowewmvl.cpp:10:29: internal compiler error: in build_over_call, at
cp/call.c:9034
10 | zp (const a9 &k3) : pq (k3) { }
| ^
0x5fbf1b build_over_call
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/cp/call.c:9034
0x8a29ec build_new_method_call_1
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/cp/call.c:10439
0x8a75cb build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/cp/call.c:10514
0x8a75cb build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/cp/call.c:9917
0x971fdc expand_default_init
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/cp/init.c:1986
0x971fdc expand_aggr_init_1
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/cp/init.c:2101
0x978e4f emit_mem_initializers(tree_node*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/cp/init.c:1357
0x9ecf8f cp_parser_mem_initializer_list
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/cp/parser.c:15401
0x9ecf8f cp_parser_ctor_initializer_opt
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/cp/parser.c:15309
0x9ecf8f cp_parser_ctor_initializer_opt_and_function_body
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/cp/parser.c:23272
0x9f0359 cp_parser_function_definition_after_declarator
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/cp/parser.c:29182
0x9f174c cp_parser_late_parsing_for_member
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/cp/parser.c:30084
0x9cd0c3 cp_parser_class_specifier_1
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/cp/parser.c:24346
0x9cdfeb cp_parser_class_specifier
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/cp/parser.c:24370
0x9cdfeb cp_parser_type_specifier
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/cp/parser.c:17873
0x9cefb4 cp_parser_decl_specifier_seq
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/cp/parser.c:14498
0x9cfdb4 cp_parser_simple_declaration
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/cp/parser.c:13755
0x9fc666 cp_parser_declaration
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/cp/parser.c:13575
0x9fccd0 cp_parser_translation_unit
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/cp/parser.c:4793
0x9fccd0 c_parse_file()
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/cp/parser.c:44170
[Bug gcov-profile/97594] [11 Regression] new test case gcc.dg/tree-prof/pr97461.c execution failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97594 --- Comment #2 from Martin Liška --- (In reply to Martin Liška from comment #1) > Mine, I see a strange error: > > $ Program received signal SIGBUS, Bus error. > 0x3fffb7ceddbc in __GI__IO_link_in () from /lib64/libc.so.6 > Missing separate debuginfos, use: debuginfo-install > glibc-2.17-307.el7.1.ppc64le > (gdb) bt > #0 0x3fffb7ceddbc in __GI__IO_link_in () from /lib64/libc.so.6 > #1 0x3fffb7cebe58 in _IO_new_file_init_internal () from /lib64/libc.so.6 > #2 0x3fffb7cd9dcc in fdopen@@GLIBC_2.17 () from /lib64/libc.so.6 > #3 0x10002928 in __gcov_open (name=0x100204f0 > "/home/marxin/Programming/gcc/objdir/gcc/testsuite/gcc35/pr97461.gcda") at > ../../../libgcc/../gcc/gcov-io.c:171 > #4 0x10002db8 in gcov_exit_open_gcda_file (gi_ptr=0x10020408, > gi_ptr=0x10020408, gf=) at > ../../../libgcc/libgcov-driver-system.c:312 > #5 dump_one_gcov (run_max=, run_counted=, > gf=, gi_ptr=0x10020408) at > ../../../libgcc/libgcov-driver.c:478 > #6 gcov_do_dump (list=, run_counted=) at > ../../../libgcc/libgcov-driver.c:555 > #7 0x100047d8 in __gcov_dump_one (root=0x10040590 <__gcov_root>) at > ../../../libgcc/libgcov-driver.c:578 > #8 __gcov_dump_one (root=0x10040590 <__gcov_root>) at > ../../../libgcc/libgcov-driver.c:573 > #9 __gcov_exit () at ../../../libgcc/libgcov-driver.c:600 > #10 0x1e18 in _sub_D_00100_1 () > #11 0x3fffb7fc7c68 in _dl_fini () from /lib64/ld64.so.2 > #12 0x3fffb7ca4a34 in __run_exit_handlers () from /lib64/libc.so.6 > #13 0x3fffb7ca4a84 in exit () from /lib64/libc.so.6 > #14 0x3fffb7c85308 in generic_start_main.isra.0 () from /lib64/libc.so.6 > #15 0x3fffb7c854f4 in __libc_start_main () from /lib64/libc.so.6 > #16 0x in ?? () All right, so the test-case overloads malloc and returns a memory that is a static buffer. For some reason, it leads to SEGBUS. Do Power people know what's causing that?
[Bug ipa/97586] [11 Regression] "make check" failures in binutils with -flto since r11-3641-gc34db4b6f8a5d803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97586 --- Comment #16 from CVS Commits --- The master branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:fe90c504416e6423c6a56f37a9265deabdb03de9 commit r11-4445-gfe90c504416e6423c6a56f37a9265deabdb03de9 Author: Jan Hubicka Date: Tue Oct 27 16:25:12 2020 +0100 Fix ipa-modref signature updates PR ipa/97586 * ipa-modref-tree.h (modref_tree::remap_params): New member function. * ipa-modref.c (modref_summaries_lto::duplicate): Check that optimization summaries are not duplicated. (remap_arguments): Remove. (modref_transform): Rename to ... (update_signature): ... this one; handle also lto summary. (pass_ipa_modref::execute): Update signatures here rather than in transform hook.
[Bug other/97417] RISC-V Unnecessary andi instruction when loading volatile bool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417 --- Comment #5 from Jim Wilson --- Yes, the volatile is the problem. We need to disable some optimizations like the combiner to avoid breaking the semantics of volatile. However, if you try looking at other ports, like arm, you can see that they don't have this problem because they generate different RTL at the start and hence do not need the combiner to generate the sign-extended load. So the proposal here is that we modify the RISC-V gcc port to also emit the sign-extended load at RTL generation time, which solves this problem. And then we need to do some testing to make sure that this actually generates good code in every case, as we don't want to accidentally introduce a code size or performance regression while fixing this volatile optimization problem. If you are curious about the combiner issue, see the init_recog_no_volatile call in combine.c. If you comment that out, the andi will be optimized away. But we can't remove that call, because that would break programs using volatile.
[Bug tree-optimization/97595] [11 Regression] warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97595 --- Comment #1 from Jonathan Wakely --- Created attachment 49452 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49452&action=edit preprocessed source, unreduced, gzipped
[Bug tree-optimization/97596] New: [11 Regression] ICE in wide_int_to_tree_1, at tree.c:1535
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97596
Bug ID: 97596
Summary: [11 Regression] ICE in wide_int_to_tree_1, at
tree.c:1535
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: x86_64-unknown-linux-gnu
gcc-11.0.0-alpha20201025 snapshot (g:308e40331f9d2820f8286769b5fc764671187364)
ICEs when compiling the following testcase w/ -O1 -ftree-vrp:
void
q8 (__int128 *uv, unsigned short int nf)
{
__int128 i4;
i4 = -nf;
if (i4 << 1 != 0)
*uv += nf;
}
% x86_64-unknown-linux-gnu-gcc-11.0.0 -O1 -ftree-vrp -c imh2lgdh.c
during GIMPLE pass: evrp
imh2lgdh.c: In function 'q8':
imh2lgdh.c:9:1: internal compiler error: in wide_int_to_tree_1, at tree.c:1535
9 | }
| ^
0x71dc76 wide_int_to_tree_1
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/tree.c:1535
0x184164c int_range<2u>::int_range(tree_node*,
generic_wide_int const&, generic_wide_int
const&, value_range_kind)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/value-range.h:430
0x184164c operator_lshift::op1_range(irange&, tree_node*, irange const&, irange
const&) const
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/range-op.cc:1620
0x174fe13 gori_compute::compute_operand1_range(irange&, gimple*, irange const&,
tree_node*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/gimple-range-gori.cc:878
0x1752a4e gori_compute::compute_operand_range(irange&, gimple*, irange const&,
tree_node*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/gimple-range-gori.cc:575
0x1752a4e gori_compute_cache::compute_operand_range(irange&, gimple*, irange
const&, tree_node*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/gimple-range-gori.cc:1280
0x174fed1 gori_compute::compute_operand1_range(irange&, gimple*, irange const&,
tree_node*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/gimple-range-gori.cc:903
0x1752a4e gori_compute::compute_operand_range(irange&, gimple*, irange const&,
tree_node*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/gimple-range-gori.cc:575
0x1752a4e gori_compute_cache::compute_operand_range(irange&, gimple*, irange
const&, tree_node*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/gimple-range-gori.cc:1280
0x1751a07 gori_compute::outgoing_edge_range_p(irange&, edge_def*, tree_node*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/gimple-range-gori.cc:1003
0x174d99e ranger_cache::iterative_cache_update(tree_node*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/gimple-range-cache.cc:636
0x174dee2 ranger_cache::fill_block_cache(tree_node*, basic_block_def*,
basic_block_def*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/gimple-range-cache.cc:808
0x174e696 ranger_cache::block_range(irange&, basic_block_def*, tree_node*,
bool)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/gimple-range-cache.cc:589
0x1746f74 gimple_ranger::range_on_entry(irange&, basic_block_def*, tree_node*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/gimple-range.cc:939
0x17478cb gimple_ranger::range_of_expr(irange&, tree_node*, gimple*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/gimple-range.cc:910
0x1748d04 gimple_ranger::range_of_range_op(irange&, gimple*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/gimple-range.cc:424
0x174af4f gimple_ranger::calc_stmt(irange&, gimple*, tree_node*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/gimple-range.cc:369
0x174b2df gimple_ranger::range_of_stmt(irange&, gimple*, tree_node*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/gimple-range.cc:1016
0x1747998 gimple_ranger::range_of_expr(irange&, tree_node*, gimple*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/gimple-range.cc:907
0x10a9d21 range_query::value_of_expr(tree_node*, gimple*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201025/work/gcc-11-20201025/gcc/value-query.cc:86
[Bug tree-optimization/97595] [11 Regression] warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97595 --- Comment #2 from Jonathan Wakely --- Reduced: #include template void std::basic_iostream::swap(basic_iostream&); The preprocessed code is no smaller, but this should only generate code for the problematic function, not the entire class and all its bases.
[Bug tree-optimization/97595] New: [11 Regression] warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97595 Bug ID: 97595 Summary: [11 Regression] warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org CC: msebor at gcc dot gnu.org Target Milestone: --- This code (reduced from the libstdc++) produces spurious -Wstringop-overflow diagnostics since r11-3827 when compiled with -Wsystem-headers: #include template class std::basic_iostream; In file included from /usr/include/c++/10/bits/nested_exception.h:40, from /usr/include/c++/10/exception:148, from /usr/include/c++/10/ios:39, from /usr/include/c++/10/ostream:38, from /usr/include/c++/10/iostream:39, from inst.cc:1: In member function ‘void std::basic_ios<_CharT, _Traits>::swap(std::basic_ios<_CharT, _Traits>&) [with _CharT = char; _Traits = std::char_traits]’, inlined from ‘void std::basic_istream<_CharT, _Traits>::swap(std::basic_istream<_CharT, _Traits>&) [with _CharT = char; _Traits = std::char_traits]’ at /usr/include/c++/10/istream:634:18, inlined from ‘void std::basic_iostream<_CharT, _Traits>::swap(std::basic_iostream<_CharT, _Traits>&) [with _CharT = char; _Traits = std::char_traits]’ at /usr/include/c++/10/istream:882:29, inlined from ‘std::basic_iostream<_CharT, _Traits>& std::basic_iostream<_CharT, _Traits>::operator=(std::basic_iostream<_CharT, _Traits>&&) [with _CharT = char; _Traits = std::char_traits]’ at /usr/include/c++/10/istream:876:6: /usr/include/c++/10/bits/move.h:198:11: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] In file included from /usr/include/c++/10/iostream:40, from inst.cc:1: /usr/include/c++/10/istream: In member function ‘std::basic_iostream<_CharT, _Traits>& std::basic_iostream<_CharT, _Traits>::operator=(std::basic_iostream<_CharT, _Traits>&&) [with _CharT = char; _Traits = std::char_traits]’: /usr/include/c++/10/istream:824:11: note: at offset 224 to object ‘std::basic_iostream::’ with size 16 declared here In file included from /usr/include/c++/10/bits/nested_exception.h:40, from /usr/include/c++/10/exception:148, from /usr/include/c++/10/ios:39, from /usr/include/c++/10/ostream:38, from /usr/include/c++/10/iostream:39, from inst.cc:1: In member function ‘void std::basic_ios<_CharT, _Traits>::swap(std::basic_ios<_CharT, _Traits>&) [with _CharT = char; _Traits = std::char_traits]’, inlined from ‘void std::basic_istream<_CharT, _Traits>::swap(std::basic_istream<_CharT, _Traits>&) [with _CharT = char; _Traits = std::char_traits]’ at /usr/include/c++/10/istream:634:18, inlined from ‘void std::basic_iostream<_CharT, _Traits>::swap(std::basic_iostream<_CharT, _Traits>&) [with _CharT = char; _Traits = std::char_traits]’ at /usr/include/c++/10/istream:882:29, inlined from ‘std::basic_iostream<_CharT, _Traits>& std::basic_iostream<_CharT, _Traits>::operator=(std::basic_iostream<_CharT, _Traits>&&) [with _CharT = char; _Traits = std::char_traits]’ at /usr/include/c++/10/istream:876:6: /usr/include/c++/10/bits/move.h:199:11: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] In file included from /usr/include/c++/10/iostream:40, from inst.cc:1: /usr/include/c++/10/istream: In member function ‘std::basic_iostream<_CharT, _Traits>& std::basic_iostream<_CharT, _Traits>::operator=(std::basic_iostream<_CharT, _Traits>&&) [with _CharT = char; _Traits = std::char_traits]’: /usr/include/c++/10/istream:824:11: note: at offset 224 to object ‘std::basic_iostream::’ with size 16 declared here In file included from /usr/include/c++/10/bits/nested_exception.h:40, from /usr/include/c++/10/exception:148, from /usr/include/c++/10/ios:39, from /usr/include/c++/10/ostream:38, from /usr/include/c++/10/iostream:39, from inst.cc:1: In member function ‘void std::basic_ios<_CharT, _Traits>::swap(std::basic_ios<_CharT, _Traits>&) [with _CharT = char; _Traits = std::char_traits]’, inlined from ‘void std::basic_istream<_CharT, _Traits>::swap(std::basic_istream<_CharT, _Traits>&) [with _CharT = char; _Traits = std::char_traits]’ at /usr/include/c++/10/istream:634:18, inlined from ‘void std::basic_iostream<_CharT, _Traits>::swap(std::basic_iostream<_CharT, _Traits>&) [with _CharT = char; _Traits = std::char_traits]’ at /usr/include/c++/10/istream:882:29: /usr/include/c++/10/bits/move.h:198:11: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] In file included from /usr/include/c++/10/iostream:
[Bug gcov-profile/97594] [11 Regression] new test case gcc.dg/tree-prof/pr97461.c execution failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97594 Martin Liška changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-10-27 --- Comment #1 from Martin Liška --- Mine, I see a strange error: $ Program received signal SIGBUS, Bus error. 0x3fffb7ceddbc in __GI__IO_link_in () from /lib64/libc.so.6 Missing separate debuginfos, use: debuginfo-install glibc-2.17-307.el7.1.ppc64le (gdb) bt #0 0x3fffb7ceddbc in __GI__IO_link_in () from /lib64/libc.so.6 #1 0x3fffb7cebe58 in _IO_new_file_init_internal () from /lib64/libc.so.6 #2 0x3fffb7cd9dcc in fdopen@@GLIBC_2.17 () from /lib64/libc.so.6 #3 0x10002928 in __gcov_open (name=0x100204f0 "/home/marxin/Programming/gcc/objdir/gcc/testsuite/gcc35/pr97461.gcda") at ../../../libgcc/../gcc/gcov-io.c:171 #4 0x10002db8 in gcov_exit_open_gcda_file (gi_ptr=0x10020408, gi_ptr=0x10020408, gf=) at ../../../libgcc/libgcov-driver-system.c:312 #5 dump_one_gcov (run_max=, run_counted=, gf=, gi_ptr=0x10020408) at ../../../libgcc/libgcov-driver.c:478 #6 gcov_do_dump (list=, run_counted=) at ../../../libgcc/libgcov-driver.c:555 #7 0x100047d8 in __gcov_dump_one (root=0x10040590 <__gcov_root>) at ../../../libgcc/libgcov-driver.c:578 #8 __gcov_dump_one (root=0x10040590 <__gcov_root>) at ../../../libgcc/libgcov-driver.c:573 #9 __gcov_exit () at ../../../libgcc/libgcov-driver.c:600 #10 0x1e18 in _sub_D_00100_1 () #11 0x3fffb7fc7c68 in _dl_fini () from /lib64/ld64.so.2 #12 0x3fffb7ca4a34 in __run_exit_handlers () from /lib64/libc.so.6 #13 0x3fffb7ca4a84 in exit () from /lib64/libc.so.6 #14 0x3fffb7c85308 in generic_start_main.isra.0 () from /lib64/libc.so.6 #15 0x3fffb7c854f4 in __libc_start_main () from /lib64/libc.so.6 #16 0x in ?? ()
[Bug gcov-profile/97594] [11 Regression] new test case gcc.dg/tree-prof/pr97461.c execution failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97594 Richard Biener changed: What|Removed |Added Summary|new test case |[11 Regression] new test |gcc.dg/tree-prof/pr97461.c |case |execution failure |gcc.dg/tree-prof/pr97461.c ||execution failure CC||marxin at gcc dot gnu.org Target Milestone|--- |11.0 Component|other |gcov-profile
[Bug c++/97591] Segmentation fault by non-type template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97591 --- Comment #4 from Vladimir Meremyanin --- Maybe but in the #95291 crash occurs when access member, and here when operator() is called. So probably both issues have a single cause.
[Bug c++/51577] dependent name lookup finds operator in global namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51577 --- Comment #17 from Nathan Sidwell --- ah, the logic to squirrel away lookups on a magic attribute list, records that nothing is found. But we don't preserve that negative lookup when injecting these lookups into the parameter binding. So we'll end up finding later-declared namespace-scope entities.
[Bug ipa/97593] [11 Regression] ICE in gt_pch_nx, at symbol-summary.h:290 since r11-4329-g67f3791f7d133214
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97593 --- Comment #4 from Jan Hubicka --- > I see. > Can you please take care of it? I will - as a natural punishment for cleaning this up :))
[Bug ipa/97586] [11 Regression] "make check" failures in binutils with -flto since r11-3641-gc34db4b6f8a5d803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97586 --- Comment #15 from Jan Hubicka --- > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97586 > > --- Comment #14 from Martin Liška --- > (In reply to Jan Hubicka from comment #13) > > Created attachment 49450 [details] > > fix > > > > > Yes, I noticed that right now :) Please attach me the patch here. > > Sorry for bogus patch. This one has chance to work. > > Honza > > Nice, this one fixes that! Thanks. Great, thanks for confirmation! I will commit it once ltoboottrap concludes. Honza
[Bug ipa/97586] [11 Regression] "make check" failures in binutils with -flto since r11-3641-gc34db4b6f8a5d803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97586 --- Comment #14 from Martin Liška --- (In reply to Jan Hubicka from comment #13) > Created attachment 49450 [details] > fix > > > Yes, I noticed that right now :) Please attach me the patch here. > Sorry for bogus patch. This one has chance to work. > Honza Nice, this one fixes that! Thanks.
[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504 --- Comment #15 from Martin Liška --- Created attachment 49451 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49451&action=edit Build log It's actually a partial cross compiler (-m32), please take a look at the build log.
[Bug ipa/97586] [11 Regression] "make check" failures in binutils with -flto since r11-3641-gc34db4b6f8a5d803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97586 --- Comment #13 from Jan Hubicka --- > Yes, I noticed that right now :) Please attach me the patch here. Sorry for bogus patch. This one has chance to work. Honza
[Bug other/97594] New: new test case gcc.dg/tree-prof/pr97461.c execution failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97594 Bug ID: 97594 Summary: new test case gcc.dg/tree-prof/pr97461.c execution failure Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:14e19b82c1e67ead60c3095ac23347317298904b, r11-4423 make -k check-gcc RUNTESTFLAGS=tree-prof.exp=gcc.dg/tree-prof/pr97461.c FAIL: gcc.dg/tree-prof/pr97461.c execution,-fprofile-generate -D_PROFILE_GENERATE # of expected passes1 # of unexpected failures1 # of unsupported tests 1 # of unresolved testcases 2 Executing on host: /home3/seurer/gcc/git/build/gcc-trunk/gcc/xgcc -B/home3/seurer/gcc/git/build/gcc-trunk/gcc/ /home/seurer/gcc/git/gcc-trunk/gcc/testsuite/gcc.dg/tree-prof/pr97461.c -fdiagnostics-plain-output -O2 -ldl -fprofile-generate -D_PROFILE_GENERATE -dumpbase-ext .x01 -lm -o /home/seurer/gcc/git/build/gcc-trunk/gcc/testsuite/gcc/pr97461.x01(timeout = 300) spawn -ignore SIGHUP /home3/seurer/gcc/git/build/gcc-trunk/gcc/xgcc -B/home3/seurer/gcc/git/build/gcc-trunk/gcc/ /home/seurer/gcc/git/gcc-trunk/gcc/testsuite/gcc.dg/tree-prof/pr97461.c -fdiagnostics-plain-output -O2 -ldl -fprofile-generate -D_PROFILE_GENERATE -dumpbase-ext .x01 -lm -o /home/seurer/gcc/git/build/gcc-trunk/gcc/testsuite/gcc/pr97461.x01 PASS: gcc.dg/tree-prof/pr97461.c compilation, -fprofile-generate -D_PROFILE_GENERATE Setting LD_LIBRARY_PATH to :/home3/seurer/gcc/git/build/gcc-trunk/gcc::/home3/seurer/gcc/git/build/gcc-trunk/gcc:/home/seurer/gcc/git/build/gcc-trunk/./gmp/.libs:/home/seurer/gcc/git/build/gcc-trunk/./prev-gmp/.libs:/home/seurer/gcc/git/build/gcc-trunk/./mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-trunk/./prev-mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-trunk/./mpc/src/.libs:/home/seurer/gcc/git/build/gcc-trunk/./prev-mpc/src/.libs:/home/seurer/gcc/git/build/gcc-trunk/./isl/.libs:/home/seurer/gcc/git/build/gcc-trunk/./prev-isl/.libs Execution timeout is: 300 spawn [open ...] FAIL: gcc.dg/tree-prof/pr97461.c execution,-fprofile-generate -D_PROFILE_GENERATE UNRESOLVED: gcc.dg/tree-prof/pr97461.c compilation, -fprofile-use -D_PROFILE_USE UNRESOLVED: gcc.dg/tree-prof/pr97461.c execution,-fprofile-use -D_PROFILE_USE UNSUPPORTED: gcc.dg/tree-prof/pr97461.c -fauto-profile testcase /home/seurer/gcc/git/gcc-trunk/gcc/testsuite/gcc.dg/tree-prof/tree-prof.exp completed in 1 seconds === gcc Summary === # of expected passes1 # of unexpected failures1 # of unresolved testcases 2 # of unsupported tests 1 commit 14e19b82c1e67ead60c3095ac23347317298904b (HEAD) Author: Martin Liska Date: Mon Oct 19 17:40:00 2020 +0200 gcov-profile: use static pool for TOPN first gcc/ChangeLog: PR gcov-profile/97461 * gcov-io.h (GCOV_PREALLOCATED_KVP): Pre-allocate 64 static counters. libgcc/ChangeLog: PR gcov-profile/97461 * libgcov.h (gcov_counter_add): Use first static counters as it should help to have malloc wrappers set up. gcc/testsuite/ChangeLog: PR gcov-profile/97461 * gcc.dg/tree-prof/pr97461.c: New test.
[Bug c++/86465] [8/9/10/11 Regression] C++17 triggers: ‘’ may be used uninitialized in this function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86465 --- Comment #10 from Jonathan Wakely --- Created attachment 49449 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49449&action=edit preprocessed source, unreduced, gzipped Here's another example that produces this kind of warning, this time from the libstdc++ sources (when built with -Wsystem-headers -Werror) It seems to be complaining about the std::allocator object, which is an empty class so (1) who cares if it's uninitialized and (2) it's not uninitialized. $ ~/gcc/11/bin/g++ -O2 -Wall cow-fs_path.ii -c In file included from /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/string:55, from /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/stdexcept:38, from /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/system_error:40, from /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/fs_fwd.h:35, from /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/filesystem:43, from /home/jwakely/src/gcc/libstdc++-v3/src/c++17/fs_path.cc:34, from /home/jwakely/src/gcc/libstdc++-v3/src/c++17/cow-fs_path.cc:26: In static member function ‘static _CharT* std::basic_string<_CharT, _Traits, _Alloc>::_S_construct(_InIterator, _InIterator, const _Alloc&, std::forward_iterator_tag) [with _FwdIterator = const char*; _CharT = char; _Traits = std::char_traits; _Alloc = std::allocator]’, inlined from ‘static _CharT* std::basic_string<_CharT, _Traits, _Alloc>::_S_construct(_InIterator, _InIterator, const _Alloc&, std::forward_iterator_tag) [with _FwdIterator = const char*; _CharT = char; _Traits = std::char_traits; _Alloc = std::allocator]’ at /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:589:7, inlined from ‘static _CharT* std::basic_string<_CharT, _Traits, _Alloc>::_S_construct(_InIterator, _InIterator, const _Alloc&) [with _InIterator = const char*; _CharT = char; _Traits = std::char_traits; _Alloc = std::allocator]’ at /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.h:5151:30, inlined from ‘std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, std::basic_string<_CharT, _Traits, _Alloc>::size_type, const _Alloc&) [with _CharT = char; _Traits = std::char_traits; _Alloc = std::allocator]’ at /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.h:3620:9, inlined from ‘std::basic_string<_CharT, _Traits, _Alloc>::basic_string(std::basic_string<_CharT, _Traits, _Alloc>::__sv_wrapper, const _Alloc&) [with _CharT = char; _Traits = std::char_traits; _Alloc = std::allocator]’ at /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.h:3541:65, inlined from ‘std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _Tp&, const _Alloc&) [with _Tp = std::basic_string_view; = void; _CharT = char; _Traits = std::char_traits; _Alloc = std::allocator]’ at /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.h:3731:58, inlined from ‘std::filesystem::path::path(const _Source&, std::filesystem::path::format) [with _Source = std::basic_string_view; _Require = std::filesystem::path]’ at /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/fs_path.h:304:9, inlined from ‘void std::filesystem::path::_M_concat(std::basic_string_view)’ at /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/fs_path.h:340:24: /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:604:36: warning: ‘’ may be used uninitialized [-Wmaybe-uninitialized] 604 | _Rep* __r = _Rep::_S_create(__dnew, size_type(0), __a); | ~~~^~~ In file included from /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/string:55, from /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/stdexcept:38, from /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/system_error:40, from /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/fs_fwd.h:35, from /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/filesystem:43, from /home/jwakely/src/gcc/libstdc++-v3/src/c++17/fs_path.cc:34, from /home/jwakely/src/gcc/libstdc++-v3/src/c++17/cow-fs_path.cc:26: /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc: In member function ‘void std::filesystem::path::_M_concat(std::basic_string_view)’: /home/jwakely/build/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:980:5: note: by argument 3 of t
[Bug ipa/97586] [11 Regression] "make check" failures in binutils with -flto since r11-3641-gc34db4b6f8a5d803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97586 --- Comment #12 from Martin Liška --- (In reply to Jan Hubicka from comment #11) > > Hi, > > this is patch that moves updates to WPA time. Does it work for you? > Actually it won't help, since it updates only non-lto summary. I am > testing better patch, sorry for that. > > Honza Yes, I noticed that right now :) Please attach me the patch here.
[Bug ipa/97593] [11 Regression] ICE in gt_pch_nx, at symbol-summary.h:290 since r11-4329-g67f3791f7d133214
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97593 --- Comment #3 from Martin Liška --- (In reply to Jan Hubicka from comment #2) > Hmm, this is anoying: we can not store summary to PCH. I guess we want to > collect thunks to a vector and annotate them to callgraph at finalization > time :( I see. Can you please take care of it?
[Bug ipa/97593] [11 Regression] ICE in gt_pch_nx, at symbol-summary.h:290 since r11-4329-g67f3791f7d133214
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97593 --- Comment #2 from Jan Hubicka --- Hmm, this is anoying: we can not store summary to PCH. I guess we want to collect thunks to a vector and annotate them to callgraph at finalization time :(
[Bug ipa/97586] [11 Regression] "make check" failures in binutils with -flto since r11-3641-gc34db4b6f8a5d803
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97586 --- Comment #11 from Jan Hubicka --- > Hi, > this is patch that moves updates to WPA time. Does it work for you? Actually it won't help, since it updates only non-lto summary. I am testing better patch, sorry for that. Honza
Re: [Bug ipa/97586] [11 Regression] "make check" failures in binutils with -flto since r11-3641-gc34db4b6f8a5d803
> Hi, > this is patch that moves updates to WPA time. Does it work for you? Actually it won't help, since it updates only non-lto summary. I am testing better patch, sorry for that. Honza
[Bug ipa/97593] [11 Regression] ICE in gt_pch_nx, at symbol-summary.h:290 since r11-4329-g67f3791f7d133214
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97593 --- Comment #1 from Martin Liška --- The original commit was sent here: https://gcc.gnu.org/legacy-ml/gcc-patches/2019-10/msg01745.html Git commit: g:315d42482cf3
[Bug ipa/97593] New: [11 Regression] ICE in gt_pch_nx, at symbol-summary.h:290 since r11-4329-g67f3791f7d133214
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97593
Bug ID: 97593
Summary: [11 Regression] ICE in gt_pch_nx, at
symbol-summary.h:290 since r11-4329-g67f3791f7d133214
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
Target Milestone: ---
The following fails since r11-4329-g67f3791f7d133214:
$ cat prusa.ii
class ConfigBase {
virtual int *def() const;
};
class DynamicConfig : virtual ConfigBase {
int *def() const { return 0; }
};
$ g++ -x c++-header prusa.ii -o x.pch
prusa.ii:6:2: internal compiler error: in gt_pch_nx, at symbol-summary.h:329
6 | };
| ^
0x758fea void gt_pch_nx(function_summary* const&)
/home/marxin/Programming/gcc/gcc/symbol-summary.h:329
0x758fea gt_pch_nx_function_summary_thunk_info__(void*)
/dev/shm/objdir/gcc/gtype-desc.c:6428
0x758fea gt_pch_nx_symbol_table(void*)
/dev/shm/objdir/gcc/gtype-desc.c:6451
0x758fea gt_pch_nx_symbol_table(void*)
/dev/shm/objdir/gcc/gtype-desc.c:6440
0xd4c785 gt_pch_save(_IO_FILE*)
/home/marxin/Programming/gcc/gcc/ggc-common.c:430
0xb3c5a5 c_common_write_pch()
/home/marxin/Programming/gcc/gcc/c-family/c-pch.c:177
0x97bd8c c_parse_final_cleanups()
/home/marxin/Programming/gcc/gcc/cp/decl2.c:4866
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug ipa/97593] [11 Regression] ICE in gt_pch_nx, at symbol-summary.h:290 since r11-4329-g67f3791f7d133214
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97593 Martin Liška changed: What|Removed |Added Target Milestone|--- |11.0 Known to work||10.2.0 Ever confirmed|0 |1 Last reconfirmed||2020-10-27 Status|UNCONFIRMED |NEW Known to fail||11.0 Priority|P3 |P1
[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 Bug 88443 depends on bug 92942, which changed state. Bug 92942 Summary: missing -Wstringop-overflow for allocations with a negative lower bound size https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92942 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/92942] missing -Wstringop-overflow for allocations with a negative lower bound size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92942 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |11.0 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=97342 Status|ASSIGNED|RESOLVED --- Comment #4 from Martin Sebor --- The patch referenced in comment #2 was never reviewed but the bug was resolved by the improvements to compute_objsize() committed as part of the fix for pr97342. GCC 11 detects both buffer overflows: $ gcc -O2 -S -Wall pr92942.c pr92942.c: In function ‘f’: pr92942.c:10:3: warning: ‘__builtin_memcpy’ writing 6 bytes into a region of size between 0 and 3 [-Wstringop-overflow=] 10 | strcpy (p, "12345"); // buffer overflow detected | ^~~ pr92942.c:9:13: note: at offset 0 to an object with size at most 3 allocated by ‘malloc’ here 9 | void *p = malloc (n); | ^~ pr92942.c: In function ‘g’: pr92942.c:20:3: warning: ‘__builtin_memcpy’ writing 6 bytes into a region of size between 0 and 3 [-Wstringop-overflow=] 20 | strcpy (p, "12345"); // buffer overflow not detected | ^~~ pr92942.c:19:13: note: at offset 0 to an object with size at most 3 allocated by ‘malloc’ here 19 | void *p = malloc (n); | ^~
[Bug middle-end/92942] missing -Wstringop-overflow for allocations with a negative lower bound size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92942 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:c0b09c1296d5334d1d264ba4d39ca932f9572330 commit r11-4441-gc0b09c1296d5334d1d264ba4d39ca932f9572330 Author: Martin Sebor Date: Tue Oct 27 08:31:53 2020 -0600 Add tests for PR92942 - missing -Wstringop-overflow for allocations with a negative lower bound size. gcc/testsuite/ChangeLog: PR middle-end/92942 * gcc.dg/Wstringop-overflow-56.c: New test. * gcc.dg/Wstringop-overflow-57.c: Same.
[Bug fortran/97592] New: Incorrectly set pointer remapping with array pointer argument to CONTIGUOUS dummy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97592 Bug ID: 97592 Summary: Incorrectly set pointer remapping with array pointer argument to CONTIGUOUS dummy Product: gcc Version: og10 (devel/omp/gcc-10) Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: reubendb at gmail dot com Target Milestone: --- Hi, The following code produces an incorrect results with GCC 10.1.0, 10.2.0. The code works as expected with GCC/6.4.0,7.4.0,8.1.0,8.1.1 program RemappingTest implicit none real, dimension ( :, : ), pointer :: & B_2D real, dimension ( :, :, : ), pointer :: & B_3D !-- Prepare B_2D allocate ( B_2D ( 16, 3 ) ) B_2D = - huge ( 1.0 ) !-- Point B_3D to Storage call SetPointer ( B_2D, 4, 4, 3, B_3D ) !-- Set B_3D B_3D = 2.0 !-- See if the result is reflected in Storage print* print*, "B_2D = ", B_2D !-- expect 2.0 for all elements contains subroutine SetPointer ( C_2D, n1, n2, n3, C_3D ) real, dimension ( :, : ), intent ( inout ), target, contiguous :: & C_2D integer :: & n1, n2, n3 real, dimension ( :, :, : ), intent ( inout ), pointer :: & C_3D C_3D ( 1 : n1, 1 : n2, 1 : n3 ) => C_2D end subroutine SetPointer end program RemappingTest ]$ gfortran --version GNU Fortran (GCC) 10.2.0 Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ]$ gfortran -Wall -Wextra -fno-strict-aliasing -fwrapv -Warray-temporaries PointerRemapTest.f90 PointerRemapTest.f90:13:20: 13 | call SetPointer ( B_2D, 4, 4, 3, B_3D ) |1 Warning: Creating array temporary at (1) [-Warray-temporaries] ]$ ./a.out B_2D = -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 -3.40282347E+38 It seems to be issue is because inside the subroutine SetPointer, a new array `C_2D` is created. So `C_3D` points to this new array instead. Outside of subroutine, this pointer (now `B_3D`) actually points to an invalid memory location. In some cases I can trigger a segfault with the code with GCC-10.2.0
[Bug tree-optimization/97567] [11 Regression] wrong code at -Os and above on x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97567 --- Comment #5 from Andrew Macleod --- Created attachment 49448 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49448&action=edit Adjust test case for 32 bit change the testcase type to long long to avoid issues on 32 bit targets.
[Bug c++/95291] ICE in resolve_args at gcc/cp/call.c:4482
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95291 Marek Polacek changed: What|Removed |Added CC||v.stiff at gmail dot com --- Comment #6 from Marek Polacek --- *** Bug 97591 has been marked as a duplicate of this bug. ***
[Bug c++/97591] Segmentation fault by non-type template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97591 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #3 from Marek Polacek --- Looks like a dup. *** This bug has been marked as a duplicate of bug 95291 ***
[Bug analyzer/97568] -fanalyzer assumes that an extern const pointer is NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97568 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from David Malcolm --- Should be fixed by the above commit.
[Bug c++/97591] Segmentation fault by non-type template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97591
--- Comment #2 from Vladimir Meremyanin ---
Program source:
// /usr/local/Cellar/gcc/10.2.0/bin/g++-10 -std=c++20 type-level-routes.cpp
#include
#include
// FixedString from
https://www.reddit.com/r/cpp/comments/bhxx49/c20_string_literals_as_nontype_template/
template
struct FixedString {
char buf[N + 1]{};
constexpr FixedString(char const* s) {
for (unsigned i = 0; i != N; ++i) buf[i] = s[i];
}
constexpr operator char const*() const { return buf; }
};
template FixedString(char const (&)[N]) -> FixedString;
// own code
// Static url part
template
struct Slug {
static constexpr char const* path = Path;
};
// Dynamic url part
template
struct Capture {
using value_t = Value;
};
// Route
template
struct Route;
template
struct Route, Rest...> {
static std::string toString(ValueT value, auto... rest) {
return "/" + std::to_string(value) + Route::toString(rest...);
}
};
template
struct Route, Rest...> { /* <--- Path() here causes
compiler segfault */
static std::string toString(auto... rest) {
return "/" + std::string(SlugT::path) + Route::toString(rest...);
}
};
template <>
struct Route<> {
static std::string toString() {
return "";
}
};
using BlogRoot = Route< "blog" >;
using AllPosts = Route< "blog", "posts" >;
using SinglePost = Route< "blog", "posts", Capture >;
int main() {
// /blog
std::cout << "blog = " << BlogRoot::toString() << std::endl;
// /blog/posts
std::cout << "allPosts = " << AllPosts::toString() << std::endl;
// invalid path, compilation error
// std::cout << "singlePost = " << SinglePost::toString() << std::endl;
// /blog/posts/42
std::cout << "singlePost = " << SinglePost::toString(42) << std::endl;
return 0;
}
[Bug analyzer/96608] Build failure due to cast to type long on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2020-10-27 --- Comment #10 from David Malcolm --- I've pushed Markus's patch here: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/555148.html to master as g:942086bf73ee2ba6cfd7fdacc552940048437a6e though for some reason this bug didn't get auto-notified. My reply to his email is here: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557204.html Does this resolve the build issues seen on MinGW?
[Bug c++/97591] Segmentation fault by non-type template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97591 --- Comment #1 from Vladimir Meremyanin --- g++-10 -v Using built-in specs. COLLECT_GCC=/usr/local/Cellar/gcc/10.2.0/bin/g++-10 COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/10.2.0/libexec/gcc/x86_64-apple-darwin19/10.2.0/lto-wrapper Target: x86_64-apple-darwin19 Configured with: ../configure --build=x86_64-apple-darwin19 --prefix=/usr/local/Cellar/gcc/10.2.0 --libdir=/usr/local/Cellar/gcc/10.2.0/lib/gcc/10 --disable-nls --enable-checking=release --enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-10 --with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl --with-system-zlib --with-pkgversion='Homebrew GCC 10.2.0' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues --disable-multilib --with-native-system-header-dir=/usr/include --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk SED=/usr/bin/sed Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.2.0 (Homebrew GCC 10.2.0)
[Bug c++/97591] New: Segmentation fault by non-type template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97591
Bug ID: 97591
Summary: Segmentation fault by non-type template parameters
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: v.stiff at gmail dot com
Target Milestone: ---
I was experimenting with new C++20 features and stumbled on segfault in GCC
10.2.0:
type-level-routes.cpp:45:25: internal compiler error: Segmentation fault: 11
45 | struct Route, Rest...> {
| ^
[Bug c++/51577] dependent name lookup finds operator in global namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51577 Jonathan Wakely changed: What|Removed |Added CC||barry.revzin at gmail dot com --- Comment #15 from Jonathan Wakely --- *** Bug 70099 has been marked as a duplicate of this bug. ***
[Bug c++/83035] Using decltype fails with an operator using non-ADL lookup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83035 Jonathan Wakely changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jonathan Wakely --- Another dup of 51577 *** This bug has been marked as a duplicate of bug 51577 ***
[Bug c++/70099] Function found by ADL, but shouldn't be visible at point of definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70099 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- Another dup of an old bug of mine *** This bug has been marked as a duplicate of bug 51577 ***
[Bug c++/51577] dependent name lookup finds operator in global namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51577 Jonathan Wakely changed: What|Removed |Added CC||tonvandenheuvel at gmail dot com --- Comment #16 from Jonathan Wakely --- *** Bug 83035 has been marked as a duplicate of this bug. ***
[Bug analyzer/97568] -fanalyzer assumes that an extern const pointer is NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97568 --- Comment #3 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:16ad9ae85bb5b9acf80f9d1cf2be5a989ef7ba49 commit r11-4437-g16ad9ae85bb5b9acf80f9d1cf2be5a989ef7ba49 Author: David Malcolm Date: Tue Oct 27 09:54:25 2020 -0400 analyzer: don't assume extern const vars are zero-initialized [PR97568] gcc/analyzer/ChangeLog: PR analyzer/97568 * region-model.cc (region_model::get_initial_value_for_global): Move check that !DECL_EXTERNAL from here to... * region.cc (decl_region::get_svalue_for_initializer): ...here, using it to reject zero initialization. gcc/testsuite/ChangeLog: PR analyzer/97568 * gcc.dg/analyzer/pr97568.c: New test.
[Bug c++/51577] dependent name lookup finds operator in global namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51577 Jonathan Wakely changed: What|Removed |Added CC||zhonghao at pku dot org.cn --- Comment #14 from Jonathan Wakely --- *** Bug 86577 has been marked as a duplicate of this bug. ***
[Bug c++/86577] non-ADL name lookup for operator<< at instantiation time?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86577 Jonathan Wakely changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #4 from Jonathan Wakely --- . *** This bug has been marked as a duplicate of bug 51577 ***
[Bug c++/51577] dependent name lookup finds operator in global namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51577 Jonathan Wakely changed: What|Removed |Added CC||andrea_iob at hotmail dot com --- Comment #13 from Jonathan Wakely --- *** Bug 97584 has been marked as a duplicate of this bug. ***
[Bug c++/97584] ADL inconsistency when calling the stream operator with x << y or with operator<<(x,y)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97584 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- This is a duplicate *** This bug has been marked as a duplicate of bug 51577 ***
[Bug libstdc++/70940] pmr::resource_adaptor requires optional allocator requirements and incorrectly aligns returned pointers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70940 --- Comment #14 from Jonathan Wakely --- P.S. if that failure only appeared recently it would be more useful to mail the libstdc++ list than to add a comment to an old bug that hasn't been touched in years.
[Bug libstdc++/70940] pmr::resource_adaptor requires optional allocator requirements and incorrectly aligns returned pointers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70940 --- Comment #13 from Jonathan Wakely --- Should be fixed at g:01079b6a9236bd467b445fafaff2659840789a85
[Bug analyzer/97514] [11 Regression] ICE in add_function_entry, at analyzer/engine.cc:1958
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97514 --- Comment #5 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:ea0ae4e77a89d4a0492dcbbc13e9cbc19bcc2361 commit r11-4433-gea0ae4e77a89d4a0492dcbbc13e9cbc19bcc2361 Author: David Malcolm Date: Tue Oct 27 09:50:24 2020 -0400 analyzer: fix param "analyzer-max-enodes-per-program-point" This was effectively checking for one beyond the limit, rather than the limit itself. Seen when fixing PR analyzer/97514. gcc/analyzer/ChangeLog: * engine.cc (exploded_graph::get_or_create_node): Fix off-by-one when imposing param_analyzer_max_enodes_per_program_point limit.
[Bug target/97205] arm: Compiler fails with an ICE for -O0 on Trunk and GCC-10 for _Generic feature.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97205
--- Comment #4 from SRINATH PARVATHANENI ---
(In reply to Bernd Edlinger from comment #2)
> Thanks for reporting this.
>
> The expansion of assignments to misaligned ssa names
> does not handle the case of misaligned stores, which
> would result in incorrect code without the assertion.
>
> I have an untested patch below:
>
> diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c
> index 3706f0a..12b81cd 100644
> --- a/gcc/emit-rtl.c
> +++ b/gcc/emit-rtl.c
> @@ -2089,7 +2089,8 @@ set_mem_attributes_minus_bitpos (rtx ref, tree t, int
> objectp,
> {
> gcc_assert (handled_component_p (t)
> || TREE_CODE (t) == MEM_REF
> - || TREE_CODE (t) == TARGET_MEM_REF);
> + || TREE_CODE (t) == TARGET_MEM_REF
> + || TREE_CODE (t) == SSA_NAME);
> attrs.expr = t;
> attrs.offset_known_p = true;
> attrs.offset = 0;
> diff --git a/gcc/expr.c b/gcc/expr.c
> index 9d951e8..49f2699 100644
> --- a/gcc/expr.c
> +++ b/gcc/expr.c
> @@ -5200,6 +5200,9 @@ expand_assignment (tree to, tree from, bool
> nontemporal)
>|| (TREE_CODE (to) == MEM_REF
> && (REF_REVERSE_STORAGE_ORDER (to)
> || mem_ref_refers_to_non_mem_p (to)))
> + || (TREE_CODE (to) == SSA_NAME
> + && mode != BLKmode
> + && TYPE_ALIGN (TREE_TYPE (to)) < GET_MODE_ALIGNMENT (mode))
>|| TREE_CODE (TREE_TYPE (to)) == ARRAY_TYPE)
> {
>machine_mode mode1;
> diff --git a/gcc/testsuite/gcc.c-torture/compile/pr97205.c
> b/gcc/testsuite/gcc.c-torture/compile/pr97205.c
> new file mode 100644
> index 000..6600011
> --- /dev/null
> +++ b/gcc/testsuite/gcc.c-torture/compile/pr97205.c
> @@ -0,0 +1,7 @@
> +int a;
> +typedef __attribute__((aligned(2))) int x;
> +int f ()
> +{
> + x b = a;
> + return b;
> +}
With the above patch I'm getting ICE as below while building arm-none-eabi
target:
checking for scalbnl... during RTL pass: expand
generice_bug/src/gcc/libstdc++-v3/src/c++98/locale_init.cc: In constructor
'std::locale::_Impl::_Impl(std::size_t)':
generice_bug/src/gcc/libstdc++-v3/src/c++98/locale_init.cc:471:3: internal
compiler error: tree check: expected bit_field_ref or mem_ref, have ssa_name in
expand_assignment, at expr.c:5203
471 | locale::_Impl::
| ^~
[Bug tree-optimization/97560] [11 Regression] ICE: tree check: expected tree that contains 'decl common' structure, have 'component_ref' in tree_could_trap_p, at tree-eh.c:2708 since r11-3685
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97560 --- Comment #6 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:31ec7242e1ff1e8da376ec9ffef10b07ac562881 commit r11-4430-g31ec7242e1ff1e8da376ec9ffef10b07ac562881 Author: Jakub Jelinek Date: Tue Oct 27 14:45:15 2020 +0100 testsuite: restrict test to c++11 and later [PR97590] 2020-10-27 Jakub Jelinek PR tree-optimization/97560 PR testsuite/97590 * g++.dg/pr97560.C: Require c++11 effective target and add comment with PR number.
[Bug testsuite/97590] new test case g++.dg/pr97560.C compilation errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97590 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:31ec7242e1ff1e8da376ec9ffef10b07ac562881 commit r11-4430-g31ec7242e1ff1e8da376ec9ffef10b07ac562881 Author: Jakub Jelinek Date: Tue Oct 27 14:45:15 2020 +0100 testsuite: restrict test to c++11 and later [PR97590] 2020-10-27 Jakub Jelinek PR tree-optimization/97560 PR testsuite/97590 * g++.dg/pr97560.C: Require c++11 effective target and add comment with PR number.
[Bug testsuite/97590] new test case g++.dg/pr97560.C compilation errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97590 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-10-27 --- Comment #1 from Richard Biener --- Confirmed. Probably misses a dg-require-effective-target c++11
[Bug testsuite/97590] New: new test case g++.dg/pr97560.C compilation errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97590
Bug ID: 97590
Summary: new test case g++.dg/pr97560.C compilation errors
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: seurer at gcc dot gnu.org
Target Milestone: ---
g:18cb6195fda69ea8ab8b8a5290dd8c9f8d52b0e6, r11-4404
make -k check-gcc RUNTESTFLAGS=dg.exp=g++.dg/pr97560.C
FAIL: g++.dg/pr97560.C -std=gnu++98 (test for excess errors)
# of expected passes3
# of unexpected failures1
commit 18cb6195fda69ea8ab8b8a5290dd8c9f8d52b0e6
Author: Aldy Hernandez
Date: Tue Oct 27 07:29:42 2020 +0100
Add test for pr97560.
gcc/testsuite/ChangeLog:
PR tree-optimization/97560
* g++.dg/pr97560.C: New test.
/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0
-std=gnu++98 -O2 -fno-tree-forwprop -fnon-call-exceptions -S -o pr97560.s
(timeout = 300)
spawn -ignore SIGHUP
/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/pr97560.C
-fdiagnostics-plain-output -nostdinc++
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0
-std=gnu++98 -O2 -fno-tree-forwprop -fnon-call-exceptions -S -o pr97560.s
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/pr97560.C:13:28: error:
expected ',' or '...' before '&&' token
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/pr97560.C: In function
'typename pv< >::g7 hq(Q6)':
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/pr97560.C:15:42: error:
expected '>' before '&&' token
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/pr97560.C:15:42: error:
expected '(' before '&&' token
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/pr97560.C:15:44: error:
expected identifier before '>' token
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/pr97560.C:15:47: error: 'lb'
was not declared in this scope
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/pr97560.C:15:50: error:
expected ')' before ';' token
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/pr97560.C: At global scope:
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/pr97560.C:26:10: error:
expected ',' or '...' before '&&' token
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/pr97560.C:26:3: error:
invalid constructor; you probably meant 'xz (const xz&)'
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/pr97560.C:44:15: error: no
matching function for call to 'hq(be&)'
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/pr97560.C:13:21: note:
candidate: 'template typename pv< >::g7
hq(Q6)'
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/pr97560.C:13:21: note:
template argument deduction/substitution failed:
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/pr97560.C: In substitution
of 'template typename pv< >::g7 hq(Q6) [with
Q6 = be]':
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/pr97560.C:44:15: required
from here
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/pr97560.C:13:21: error:
invalid use of incomplete type 'struct pv'
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/pr97560.C:5:8: note:
declaration of 'struct pv'
compiler exited with status 1
[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504 --- Comment #14 from seurer at gcc dot gnu.org --- Builds fine for me on powerpc64 LE and BE.
[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504 --- Comment #13 from Eric Botcazou --- This builds for me on powerpc64-linux, so I gather it's on powerpc64le-linux?
