[Bug target/100041] ICE in curr_insn_transform, at lra-constraints.c:4022
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100041 Uroš Bizjak changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #23 from Uroš Bizjak --- Fixed for gcc-12, no plan to backport.
[Bug rtl-optimization/96796] [9/10 Regression] aarch64: ICE during RTL pass: reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96796
--- Comment #10 from CVS Commits ---
The releases/gcc-10 branch has been updated by Richard Sandiford
:
https://gcc.gnu.org/g:e720d3033f84802147d2da9e923bd862cdb73164
commit r10-9764-ge720d3033f84802147d2da9e923bd862cdb73164
Author: Richard Sandiford
Date: Sat Apr 24 09:37:26 2021 +0100
lra: Avoid cycling on certain subreg reloads [PR96796]
This PR is about LRA cycling for a reload of the form:
Changing pseudo 196 in operand 1 of insn 103 on equiv [r105:DI*0x8+r140:DI]
Creating newreg=287, assigning class ALL_REGS to slow/invalid mem
r287
Creating newreg=288, assigning class ALL_REGS to slow/invalid mem
r288
103: r203:SI=r288:SI<<0x1+r196:DI#0
REG_DEAD r196:DI
Inserting slow/invalid mem reload before:
316: r287:DI=[r105:DI*0x8+r140:DI]
317: r288:SI=r287:DI#0
The problem is with r287. We rightly give it a broad starting class of
POINTER_AND_FP_REGS (reduced from ALL_REGS by preferred_reload_class).
However, we never make forward progress towards narrowing it down to
a specific choice of class (POINTER_REGS or FP_REGS).
I think in practice we rely on two things to narrow a reload pseudo's
class down to a specific choice:
(1) a restricted class is specified when the pseudo is created
This happens for input address reloads, where the class is taken
from the target's chosen base register class. It also happens
for simple REG reloads, where the class is taken from the chosen
alternative's constraints.
(2) uses of the reload pseudo as a direct input operand
In this case get_reload_reg tries to reuse the existing register
and narrow its class, instead of creating a new reload pseudo.
However, neither occurs here. As described above, r287 rightly
starts out with a wide choice of class, ultimately derived from
ALL_REGS, so we don't get (1). And as the comments in the PR
explain, r287 is never used as an input reload, only the subreg is,
so we don't get (2):
Choosing alt 13 in insn 317: (0) r (1) w {*movsi_aarch64}
Creating newreg=291, assigning class FP_REGS to r291
317: r288:SI=r291:SI
Inserting insn reload before:
320: r291:SI=r287:DI#0
IMO, in this case we should rely on the reload of r316 to narrow
down the class of r278. Currently we do:
Choosing alt 7 in insn 316: (0) r (1) m {*movdi_aarch64}
Creating newreg=289 from oldreg=287, assigning class GENERAL_REGS to
r289
316: r289:DI=[r105:DI*0x8+r140:DI]
Inserting insn reload after:
318: r287:DI=r289:DI
---
i.e. we create a new pseudo register r289 and give *that* pseudo
GENERAL_REGS instead. This is because get_reload_reg only narrows
down the existing class for OP_IN and OP_INOUT, not OP_OUT.
But if we have a reload pseudo in a reload instruction and have chosen
a specific class for the reload pseudo, I think we should simply install
it for OP_OUT reloads too, if the class is a subset of the existing class.
We will need to pick such a register whatever happens (for r289 in the
example above). And as explained in the PR, doing this actually avoids
an unnecessary move via the FP registers too.
This backport is less aggressive than the trunk version, in that the new
code reuses the test for a reload move from in_class_p. We will therefore
only narrow OP_OUT classes if the instruction is a register move or memory
load that was generated by LRA itself.
gcc/
PR rtl-optimization/96796
* lra-constraints.c (in_class_p): Add a default-false
allow_all_reload_class_changes_p parameter. Do not treat
reload moves specially when the parameter is true.
(get_reload_reg): Try to narrow the class of an existing OP_OUT
reload if we're reloading a reload pseudo in a reload instruction.
gcc/testsuite/
PR rtl-optimization/96796
* gcc.c-torture/compile/pr96796.c: New test.
[Bug analyzer/100244] New: [11/12 Regression] ICE: Segmentation fault (in describe_state_change)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100244
Bug ID: 100244
Summary: [11/12 Regression] ICE: Segmentation fault (in
describe_state_change)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
g++-11.0.1-alpha20210418 snapshot (g:b412ce8e961052e6becea3bc783a53e1d5feaa0f)
ICEs when compiling the following testcase, reduced from
libstdc++-v3/testsuite/23_containers/unordered_map/allocator/default_init.cc,
w/ -O1 -fanalyzer:
inline void *operator new (unsigned long int, void *__p) { return __p; }
struct __aligned_buffer {
int _M_storage;
int *_M_addr() { return &_M_storage; }
};
struct _Hashtable_alloc {
int _M_single_bucket;
int *_M_buckets = &_M_single_bucket;
~_Hashtable_alloc () { delete _M_buckets; }
};
void
test01 (__aligned_buffer buf)
{
_Hashtable_alloc *tmp = new (buf._M_addr ()) _Hashtable_alloc;
tmp->~_Hashtable_alloc ();
}
% g++-11.0.1 -O1 -fanalyzer -c tao11weu.cc
during IPA pass: analyzer
cc1plus: internal compiler error: Segmentation fault
0x10d6d5f crash_signal
/var/tmp/portage/sys-devel/gcc-11.0.1_alpha20210418/work/gcc-11-20210418/gcc/toplev.c:327
0x14b7b54 describe_state_change
/var/tmp/portage/sys-devel/gcc-11.0.1_alpha20210418/work/gcc-11-20210418/gcc/analyzer/sm-malloc.cc:1306
0x1c73666 ana::state_change_event::get_desc(bool) const
/var/tmp/portage/sys-devel/gcc-11.0.1_alpha20210418/work/gcc-11-20210418/gcc/analyzer/checker-path.cc:259
0x1c73272 ana::checker_event::prepare_for_emission(ana::checker_path*,
ana::pending_diagnostic*, diagnostic_event_id_t)
/var/tmp/portage/sys-devel/gcc-11.0.1_alpha20210418/work/gcc-11-20210418/gcc/analyzer/checker-path.cc:149
0x1c85fda ana::checker_path::prepare_for_emission(ana::pending_diagnostic*)
/var/tmp/portage/sys-devel/gcc-11.0.1_alpha20210418/work/gcc-11-20210418/gcc/analyzer/checker-path.h:559
0x1c85fda ana::diagnostic_manager::emit_saved_diagnostic(ana::exploded_graph
const&, ana::saved_diagnostic const&)
/var/tmp/portage/sys-devel/gcc-11.0.1_alpha20210418/work/gcc-11-20210418/gcc/analyzer/diagnostic-manager.cc:1146
0x1c89188 ana::dedupe_winners::emit_best(ana::diagnostic_manager*,
ana::exploded_graph const&)
/var/tmp/portage/sys-devel/gcc-11.0.1_alpha20210418/work/gcc-11-20210418/gcc/analyzer/diagnostic-manager.cc:1051
0x1c863e6 ana::diagnostic_manager::emit_saved_diagnostics(ana::exploded_graph
const&)
/var/tmp/portage/sys-devel/gcc-11.0.1_alpha20210418/work/gcc-11-20210418/gcc/analyzer/diagnostic-manager.cc:1100
0x1478c8d ana::impl_run_checkers(ana::logger*)
/var/tmp/portage/sys-devel/gcc-11.0.1_alpha20210418/work/gcc-11-20210418/gcc/analyzer/engine.cc:4887
0x1479b20 ana::run_checkers()
/var/tmp/portage/sys-devel/gcc-11.0.1_alpha20210418/work/gcc-11-20210418/gcc/analyzer/engine.cc:4944
0x146aab8 execute
/var/tmp/portage/sys-devel/gcc-11.0.1_alpha20210418/work/gcc-11-20210418/gcc/analyzer/analyzer-pass.cc:87
[Bug fortran/100245] New: ICE on automatic reallocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100245 Bug ID: 100245 Summary: ICE on automatic reallocation Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 50667 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50667&action=edit Fortran code showing problem Hi All! Automatic reallocation ICEs when assigning class to derived type. Seen on: GNU Fortran (GCC) 12.0.0 20210424 (experimental) GNU Fortran (GCC) 11.0.1 20210424 (prerelease) GNU Fortran (GCC) 10.3.1 20210424 GNU Fortran (GCC) 9.3.1 20210424 Thank you very much. Best regards, José Rui
[Bug c++/88580] Parameter pack expansion fails (variadic constructor template inside a variadic class template)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88580
Rustam Abdullaev changed:
What|Removed |Added
CC||rustamabd at gmail dot com
--- Comment #4 from Rustam Abdullaev ---
Works if I change
: Base(std::forward(args)...)...
To
: Base{std::forward(args)...}...
[Bug fortran/100245] ICE on automatic reallocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100245 Dominique d'Humieres changed: What|Removed |Added Last reconfirmed||2021-04-24 Priority|P3 |P4 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Dominique d'Humieres --- Confirmed since at least GCC7.
[Bug fortran/100218] Allow target of the pointer resulting from the evaluation of function-reference in a variable definition context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100218 Dominique d'Humieres changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-04-24
[Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 Iain Sandoe changed: What|Removed |Added Target Milestone|10.4|8.5 --- Comment #42 from Iain Sandoe --- actually, it seems clear that this case was just exposing a latent problem and the fix is needed on all open branches (and by distros if they care about it on older branches). Adjusting the target milestone.
[Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #43 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:b6600392bf71c4a9785f8f49948b611425896830 commit r12-103-gb6600392bf71c4a9785f8f49948b611425896830 Author: Iain Sandoe Date: Sat Apr 24 13:34:49 2021 +0100 Darwin : Adjust darwin_binds_local_p for PIC code [PR100152]. Darwin's dynamic linker supports interposition and lazy symbol binding. If we are generating PIC code and a symbol is public, then it could potentially be indirected via a lazy-resolver stub; we cannot tell at compile-time if this will be done (since the indirection can be the result of adding a -flat-namespace option at link-time). Here we are conservative and assume that any such symbol cannot bind locally. The default implementation for binds_local_p handles undefined, weak and common symbols which are always indirected (for mdynamic-no-pic also). gcc/ChangeLog: PR target/100152 * config/darwin.c (darwin_binds_local_p): Assume that any public symbol might be interposed for PIC code. Update function header comment to reflect current Darwin capability.
[Bug target/100241] internal compiler error: in curr_insn_transform, at lra-constraints.c:4133
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100241 --- Comment #3 from Marek Polacek --- Now reproduced with a single file. Reducing that...
[Bug target/82735] _mm256_zeroupper does not invalidate previously computed registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82735 --- Comment #5 from Jeffrey Walton --- I think we are seeing this bug in the field. We are catching lots of failed self tests as we test on multiple platforms, including Ubuntu 14 ERS and Ubuntu 16 LTS. The problem makes GCC 4.8.4 through 7.5 practically useless for AVX and AVX2. I don't see the problem with GCC 9.3. Maybe the problem got fixed somewhere along the way?
[Bug target/82735] _mm256_zeroupper does not invalidate previously computed registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82735 --- Comment #6 from Jeffrey Walton --- Add 9.3 to the know to fail list: $ gcc --version gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0 Copyright (C) 2019 Free Software Foundation, Inc.
[Bug target/100241] internal compiler error: in curr_insn_transform, at lra-constraints.c:4133
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100241
--- Comment #4 from Marek Polacek ---
Single, hopefully valid TU, no LTO needed:
$ gcc -march=armv8-a -fPIC -O3 100241.c -fvisibility=internal -c
100241.c: In function ‘vp9_first_pass_encode_tile_mb_row’:
100241.c:32:1: error: unable to generate reloads for:
32 | }
| ^
(insn 74 89 90 14 (set (reg:V2DI 136)
(vec_concat:V2DI (mem:DI (plus:DI (reg/v/f:DI 178 [orig:113 fp_acc_data
] [113])
(const_int 16 [0x10])) [3
fp_acc_data_15(D)->frame_noise_energy+0 S8 A64])
(mem:DI (plus:DI (reg/v/f:DI 178 [orig:113 fp_acc_data ] [113])
(const_int 24 [0x18])) [3 fp_acc_data_15(D)->intra_error+0
S8 A64]))) "100241.c":23:63 2473 {load_pair_lanesdi}
(nil))
during RTL pass: reload
100241.c:32:1: internal compiler error: in curr_insn_transform, at
lra-constraints.c:4133
0x152862f diagnostic_impl(rich_location*, diagnostic_metadata const*, int, char
const*, std::__va_list*, diagnostic_t)
???:0
0xce52ff internal_error(char const*, ...)
???:0
0xce53f3 fancy_abort(char const*, int, char const*)
???:0
0x7db1d7 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
???:0
0xea8d57 curr_insn_transform(bool)
???:0
0xea3d87 lra_constraints(bool)
???:0
0x131523b lra(_IO_FILE*)
???:0
0x1308fff (anonymous namespace)::pass_reload::execute(function*)
???:0
extern char num_4x4_blocks_high_lookup, num_4x4_blocks_wide_lookup,
vp9_foreach_transformed_block_in_plane_xd_0_0_0;
int vp9_first_pass_encode_tile_mb_row_cpi_0,
vp9_first_pass_encode_tile_mb_row_tile_data_0_0, vp9_encode_sby_pass1_x;
typedef void foreach_transformed_block_visitor();
void vp9_encode_sby_pass1();
typedef struct {
long coded_error;
long sr_coded_error;
long frame_noise_energy;
long intra_error;
} FIRSTPASS_DATA;
typedef struct {
FIRSTPASS_DATA fp_data;
} TileDataEnc;
TileDataEnc accumulate_fp_mb_row_stat_this_tile;
void vp9_first_pass_encode_tile_mb_row(FIRSTPASS_DATA *fp_acc_data) {
int mb_col_end = vp9_first_pass_encode_tile_mb_row_tile_data_0_0;
for (; mb_col_end;) {
vp9_encode_sby_pass1();
if (vp9_first_pass_encode_tile_mb_row_cpi_0) {
FIRSTPASS_DATA __trans_tmp_1 = *fp_acc_data;
accumulate_fp_mb_row_stat_this_tile.fp_data.coded_error +=
accumulate_fp_mb_row_stat_this_tile.fp_data.sr_coded_error +=
__trans_tmp_1.sr_coded_error;
accumulate_fp_mb_row_stat_this_tile.fp_data.frame_noise_energy +=
__trans_tmp_1.frame_noise_energy;
accumulate_fp_mb_row_stat_this_tile.fp_data.intra_error +=
__trans_tmp_1.intra_error;
}
}
}
foreach_transformed_block_visitor vp9_foreach_transformed_block_in_plane_visit;
void vp9_foreach_transformed_block_in_plane(void *arg) {
int c, max_blocks_wide = num_4x4_blocks_wide_lookup;
for (; num_4x4_blocks_high_lookup;) {
c = 0;
for (; c < max_blocks_wide;
c += vp9_foreach_transformed_block_in_plane_xd_0_0_0)
vp9_foreach_transformed_block_in_plane_visit(arg);
}
}
void vp9_encode_sby_pass1() {
vp9_foreach_transformed_block_in_plane(&vp9_encode_sby_pass1_x);
}
[Bug target/100241] internal compiler error: in curr_insn_transform, at lra-constraints.c:4133
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100241 --- Comment #5 from Marek Polacek --- I can't reproduce this with latest trunk :-(. Bisecting...
[Bug bootstrap/100246] New: [11/12 Regression] GCC will not bootstrap with clang 3.4/3.5 [xcode 5/6, Darwin 12/13]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100246
Bug ID: 100246
Summary: [11/12 Regression] GCC will not bootstrap with clang
3.4/3.5 [xcode 5/6, Darwin 12/13]
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
Target Milestone: ---
using CC=clang and CXX="clang++ -stdlib=libc++" which is needed to get C++11
support.
In file included from /src-local/gcc-git-11/gcc/config/i386/i386-options.c:94:
/src-local/gcc-git-11/gcc/config/i386/x86-tune-costs.h:363:13: error: call to
implicitly-deleted default constructor of 'const struct stringop_strategy'
{libcall, {{-1, rep_prefix_4_byte, false}}},
^
/src-local/gcc-git-11/gcc/config/i386/i386.h:254:15: note: default constructor
of 'stringop_strategy' is implicitly deleted because field 'max' of
const-qualified type 'const int' would not be initialized
const int max;
when building in c++89 mode, (GCC10.x and earlier) this worked fine. It does
look like a clang bug (but the rules are quite complex around this topic). It
would seem it's trying to find a constructor for the empty elements in the
lists (and that is implicitly deleted).
A workaround is to ensure that all the elements have a complete initialisers
with dummy entries for those that are not needed. Patch pending.
[Bug bootstrap/100246] [11/12 Regression] GCC will not bootstrap with clang 3.4/3.5 [xcode 5/6, Darwin 12/13]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100246 Iain Sandoe changed: What|Removed |Added Host||x86_64-darwin12, ||x86_64-darwin13 Keywords||build Build||x86_64-darwin12, ||x86_64-darwin13 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-04-24
[Bug jit/100242] libgccjit.so: error: in expmed_mode_index, at expmed.h:249
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100242 --- Comment #3 from Antoni --- Created attachment 50668 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50668&action=edit Smaller reproducer Ok, I figured out how to find the location of the error. In this case, it's caused by using the modulo operation on floats. I guess it should either be forbidden or use the `fmodf` intrinsics.
[Bug tree-optimization/100247] New: x86-64 bad register allocation for unsigned type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100247
Bug ID: 100247
Summary: x86-64 bad register allocation for unsigned type
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ammarfaizi2 at gmail dot com
Target Milestone: ---
GCC 12.0.0 allocates unnecessary register for unsigned type. Below is the
reproduction code:
Compile with: `gcc -Wall -Wextra -O3 -fno-tree-vectorize -fno-unroll-loops`
--
#include
long add_arrays(long *arr1, long *arr2, size_t num) {
size_t i = 0;
long sum = 0;
for (i = 0; i < num; ++i) {
sum += arr1[i];
sum += arr2[i];
}
return sum;
}
unsigned long unsigned_add_arrays(unsigned long *arr1, unsigned long *arr2,
size_t num) {
size_t i = 0;
unsigned long sum = 0;
for (i = 0; i < num; ++i) {
sum += arr1[i];
sum += arr2[i];
}
return sum;
}
#define PSTR(P) #P
#define XSTR(P) PSTR(P)
const char gcc_ver[] =
"It is GCC "
XSTR(__GNUC__) "."
XSTR(__GNUC_MINOR__) "."
XSTR(__GNUC_PATCHLEVEL__);
--
GCC 12.0.0 Result
add_arrays:
xorl%eax, %eax
testq %rdx, %rdx
je .L4
xorl%ecx, %ecx
.L3:
addq(%rdi,%rcx,8), %rax
addq(%rsi,%rcx,8), %rax
addq$1, %rcx
cmpq%rcx, %rdx
jne .L3
ret # Why do even we need this ret?
.L4:
ret
unsigned_add_arrays:
xorl%r8d, %r8d # Using %r8 is unnecessary
testq %rdx, %rdx
je .L7
xorl%eax, %eax
.L9:
movq(%rsi,%rax,8), %rcx
addq(%rdi,%rax,8), %rcx
addq$1, %rax
addq%rcx, %r8 # %r8 is used as `sum` variable
cmpq%rax, %rdx
jne .L9
.L7:
movq%r8, %rax # set return value to %r8
ret
gcc_ver:
.string "It is GCC 12.0.0"
--
GCC 4.6.4 produces better result here:
add_arrays:
xorl%eax, %eax
testq %rdx, %rdx
je .L2
xorl%ecx, %ecx
.L3:
addq(%rdi,%rcx,8), %rax
addq(%rsi,%rcx,8), %rax
addq$1, %rcx
cmpq%rdx, %rcx
jne .L3
.L2:
rep
ret
unsigned_add_arrays:
xorl%eax, %eax
testq %rdx, %rdx
je .L8
xorl%ecx, %ecx
.L9:
addq(%rdi,%rcx,8), %rax
addq(%rsi,%rcx,8), %rax
addq$1, %rcx
cmpq%rdx, %rcx
jne .L9
.L8:
rep
ret
gcc_ver:
.string "It is GCC 4.6.4"
--
Golbolt link: https://godbolt.org/z/9Pj5Ph1Gn
[Bug c++/100248] New: ICE with global "default" keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100248
Bug ID: 100248
Summary: ICE with global "default" keyword
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
10.2, 10.3, 11 and 12 regression:
https://godbolt.org/z/qrvE98Taa
#include
struct S {};
auto operator<=>(S&&, S&&) = default;
:4:30: internal compiler error: Segmentation fault
4 | auto operator<=>(S&&, S&&) = default;
| ^~~
0x1cff079 internal_error(char const*, ...)
???:0
0x1366c60 strip_array_types(tree_node*)
???:0
0x9c97d8 cp_type_quals(tree_node const*)
???:0
0x9ba523 cp_build_qualified_type_real(tree_node*, int, int)
???:0
0x82f194 defaultable_fn_check(tree_node*)
???:0
0x7b2cc8 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
???:0
0x8e1f3d c_parse_file()
???:0
0xa62212 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
[Bug c++/95486] ICE for alias CTAD with non-dependent argument and constrained constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95486 --- Comment #11 from Johel Ernesto Guerrero Peña --- Thank you. But the first CE link: https://godbolt.org/z/cPWdGW, and with the addition in Comment 2: https://godbolt.org/z/Gezh5h5W4, they still ICE.
[Bug libstdc++/100249] New: missing forwarding std::__invoke result in ranges::is_permutation and ranges::clamp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100249
Bug ID: 100249
Summary: missing forwarding std::__invoke result in
ranges::is_permutation and ranges::clamp
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
Hey, in ranges::is_permutation in ranges_algo.h#L808:
auto __proj_scan = std::__invoke(__proj1, *__scan);
auto __comp_scan = [&] (_Tp&& __arg) {
return std::__invoke(__pred, __proj_scan,
std::forward<_Tp>(__arg));
};
the __proj_scan seems to forget to use auto&& to receive the std::__ invoke
call, which will cause compile failure if the return type is non-copyable:
https://godbolt.org/z/WaKc7bWM4
also, we should perfect forward the type of __proj_scan to the next
std::__invoke call, and ranges::clamp in ranges_algo.h#L3232 has the same
issue:
auto&& __proj_val = std::__invoke(__proj, __val);
if (std::__invoke(__comp, __proj_val, std::__invoke(__proj, __lo)))
return __lo;
when the type of __proj_val is an rvalue reference, we need to convert it to
rvalue for the next std::__invoke call: https://godbolt.org/z/1G7aqxs3c.
So I think it should be relatively safe to inline all std::__invoke calls.
[Bug fortran/100218] Allow target of the pointer resulting from the evaluation of function-reference in a variable definition context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100218 --- Comment #2 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:32c4d970ea3a9fc330d6aa8fd83f9dae0b9afc64 commit r12-106-g32c4d970ea3a9fc330d6aa8fd83f9dae0b9afc64 Author: Harald Anlauf Date: Sat Apr 24 20:38:06 2021 +0200 Fortran - allow target of pointer from evaluation of function-reference Fortran allows the target of a pointer from the evaluation of a function-reference in a variable definition context (e.g. F2018:R902). gcc/fortran/ChangeLog: PR fortran/100218 * expr.c (gfc_check_vardef_context): Extend check to allow pointer from a function reference. gcc/testsuite/ChangeLog: PR fortran/100218 * gfortran.dg/ptr-func-4.f90: New test.
[Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #44 from Iain Sandoe --- unfortunately, wider testing showed sanitiser fails - so this has been reverted for now.
[Bug analyzer/100244] [11/12 Regression] ICE: Segmentation fault (in describe_state_change)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100244 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-04-24 --- Comment #1 from David Malcolm --- Thanks for filing this bug. Confirmed; I'm testing a fix.
[Bug fortran/100154] [9/10/11/12 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100154 --- Comment #10 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:d0e7833b94953ba6b4a915150666969ad9fc66af commit r12-107-gd0e7833b94953ba6b4a915150666969ad9fc66af Author: Harald Anlauf Date: Sat Apr 24 20:51:41 2021 +0200 PR fortran/100154 - ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131 Add appropriate static checks for the character and status arguments to the GNU Fortran intrinsic extensions fget[c], fput[c]. Extend variable check to allow a function reference having a data pointer result. gcc/fortran/ChangeLog: PR fortran/100154 * check.c (variable_check): Allow function reference having a data pointer result. (arg_strlen_is_zero): New function. (gfc_check_fgetputc_sub): Add static check of character and status arguments. (gfc_check_fgetput_sub): Likewise. * intrinsic.c (add_subroutines): Fix argument name for the character argument to intrinsic subroutines fget[c], fput[c]. gcc/testsuite/ChangeLog: PR fortran/100154 * gfortran.dg/pr100154.f90: New test.
[Bug c++/100240] Compiler crashes with segmentation fault on a chrono library using nvcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100240 --- Comment #5 from Peter Taraba --- Also, not sure if this info helps, but this bug does not seem to appear with gcc 10.2 (I tried it on Manjaro KDE Plasma linux). So it's probably some new code which came after 10.2. Cheers.
[Bug target/100241] internal compiler error: in curr_insn_transform, at lra-constraints.c:4133
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100241 --- Comment #6 from Marek Polacek --- Fixed by r11-7864. Not sure if we want this test. It doesn't contain __fp16 like the test in r11-7864.
[Bug fortran/100154] [9/10/11/12 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100154 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org
[Bug fortran/100218] Allow target of the pointer resulting from the evaluation of function-reference in a variable definition context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100218 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
[Bug fortran/100158] Some issues with fortran testsuite files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100158
--- Comment #1 from anlauf at gcc dot gnu.org ---
The files testsuite/substr_{9,10}.f90 were moved by Tobias:
r12-68-gac456fd981db6b0c2f7ee1ab0d17d36087a74dc2
[Bug bootstrap/100246] [11/12 Regression] GCC will not bootstrap with clang 3.4/3.5 [xcode 5/6, Darwin 12/13]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100246 --- Comment #1 from Iain Sandoe --- Created attachment 50669 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50669&action=edit Patch that works around the clang issue/bug this is against GCC-11.1rc2, but not likely to need much/any amendment for GCC12.
[Bug target/100241] internal compiler error: in curr_insn_transform, at lra-constraints.c:4133
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100241 --- Comment #7 from Andrew Pinski --- (In reply to Marek Polacek from comment #6) > Fixed by r11-7864. Not sure if we want this test. It doesn't contain > __fp16 like the test in r11-7864. PR 99787 also has a testcase that could be done too. I think we should add a testcase for both bugs.
[Bug target/99932] OpenACC/nvptx offloading execution regressions starting with CUDA 11.2-era Nvidia Driver 460.27.04
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99932 --- Comment #5 from Tom de Vries --- FIled https://developer.nvidia.com/nvidia_bug/3299227
[Bug tree-optimization/100250] New: ICE related to -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100250 Bug ID: 100250 Summary: ICE related to -Wmaybe-uninitialized Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: muecker at gwdg dot de Target Milestone: --- Created attachment 50670 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50670&action=edit minimized test case (possibly also affects 11.0) xgcc (GCC) 12.0.0 20210424 (experimental) bcd77b7b9f35bd5b559ed593c3b3e346c1e6f364 $ ../gcc_build_clean/gcc/xgcc -B../gcc_build_clean/gcc/ -Wmaybe-uninitialized ice.c ice.c: In function ‘md_reshape2’: ice.c:34:9: warning: ‘’ may be used uninitialized [-Wmaybe-uninitialized] 34 | md_permute2(D, order, dims2, strs2, idims); | ^~ during GIMPLE pass: *early_warn_uninitialized ice.c:35:1: internal compiler error: Speicherzugriffsfehler 35 | } | ^ 0xe00f3f crash_signal ../../gcc/gcc/toplev.c:327 0x7f26a437583f ??? /build/glibc-vjB4T1/glibc-2.28/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 0x80db7c tree_check(tree_node*, char const*, int, char const*, tree_code) ../../gcc/gcc/tree.h:3352 0x80db7c attr_access::array_as_string[abi:cxx11](tree_node*) const ../../gcc/gcc/attribs.c:2391 0x101789d maybe_warn_pass_by_reference ../../gcc/gcc/tree-ssa-uninit.c:566 0x101789d warn_uninitialized_vars ../../gcc/gcc/tree-ssa-uninit.c:648 0x1017c70 execute_early_warn_uninitialized ../../gcc/gcc/tree-ssa-uninit.c:3089 0x1017c70 execute ../../gcc/gcc/tree-ssa-uninit.c:3124 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions.
[Bug ada/100251] New: Byte order mark in gnat.adc raises compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100251 Bug ID: 100251 Summary: Byte order mark in gnat.adc raises compilation error Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: stephen.sangwine at btinternet dot com Target Milestone: --- Created attachment 50671 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50671&action=edit Trivial gnat.adc file starting with a BOM. When using gnatmake to compile an Ada program (any program, even a Hello World program), if a gnat.adc file exists in the directory where the main source file is located, and gnat.adc starts with a byte order mark (BOM), the gnat compiler reports the following error and compilation fails: gnatmake: gnat.adc:1:1: non pragma encountered Why is this an issue? LRM 2.1(16/3) specifies that source code files containing a BOM shall be accepted. The Gnat User Guide section 3.4.2 says that gnat.adc is in the same format as a source code file. Therefore one would expect that a BOM in gnat.adc would be accepted. If you wish to format Ada source code files with a BOM, it is handy to set your editor to add the BOM if not present. Yet if you then edit gnat.adc with the same editor, a BOM will be inserted, and your next compilation will fail.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #214 from Peter Bisroev --- (In reply to Andrew Pinski from comment #213) > Does this still happen with GCC 8 or above? Hi Andrew, yes it does from my last tests. As we have found out here, before newer versions of GCC can work on HP-UX we need to get a working gas. Please refer to this gas Bugzilla ticket for details: https://sourceware.org/bugzilla/show_bug.cgi?id=25599
[Bug analyzer/100244] [11/12 Regression] ICE: Segmentation fault (in describe_state_change)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100244 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:61bfff562e3b6091d5a0a412a7d496bd523868a8 commit r12-108-g61bfff562e3b6091d5a0a412a7d496bd523868a8 Author: David Malcolm Date: Sat Apr 24 19:49:31 2021 -0400 analyzer: fix ICE on NULL change.m_expr [PR100244] PR analyzer/100244 reports an ICE on a -Wanalyzer-free-of-non-heap due to a case where free_of_non_heap::describe_state_change can be passed a NULL change.m_expr for a suitably complicated symbolic value. Bulletproof it by checking for change.m_expr being NULL before dereferencing it. gcc/analyzer/ChangeLog: PR analyzer/100244 * sm-malloc.cc (free_of_non_heap::describe_state_change): Bulletproof against change.m_expr being NULL. gcc/testsuite/ChangeLog: PR analyzer/100244 * g++.dg/analyzer/pr100244.C: New test.
[Bug analyzer/100244] [11 Regression] ICE: Segmentation fault (in describe_state_change)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100244 David Malcolm changed: What|Removed |Added Summary|[11/12 Regression] ICE: |[11 Regression] ICE: |Segmentation fault (in |Segmentation fault (in |describe_state_change) |describe_state_change) --- Comment #3 from David Malcolm --- Fixed on trunk for gcc 12 by above commit.
[Bug target/98911] Add folding and remove expanders for x86 *pcmp{et,gt}* builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98911
--- Comment #1 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:c54a9f7259fce1a221270f21d8076c960c7d0163
commit r12-110-gc54a9f7259fce1a221270f21d8076c960c7d0163
Author: liuhongt
Date: Tue Feb 23 11:17:40 2021 +0800
Add folding and remove expanders for x86 *pcmp{et,gt}* builtins [PR
target/98911]
gcc/ChangeLog:
PR target/98911
* config/i386/i386-builtin.def (BDESC): Change the icode of
the following builtins to CODE_FOR_nothing.
* config/i386/i386.c (ix86_gimple_fold_builtin): Fold
IX86_BUILTIN_PCMPEQB128, IX86_BUILTIN_PCMPEQW128,
IX86_BUILTIN_PCMPEQD128, IX86_BUILTIN_PCMPEQQ,
IX86_BUILTIN_PCMPEQB256, IX86_BUILTIN_PCMPEQW256,
IX86_BUILTIN_PCMPEQD256, IX86_BUILTIN_PCMPEQQ256,
IX86_BUILTIN_PCMPGTB128, IX86_BUILTIN_PCMPGTW128,
IX86_BUILTIN_PCMPGTD128, IX86_BUILTIN_PCMPGTQ,
IX86_BUILTIN_PCMPGTB256, IX86_BUILTIN_PCMPGTW256,
IX86_BUILTIN_PCMPGTD256, IX86_BUILTIN_PCMPGTQ256.
* config/i386/sse.md (avx2_eq3): Deleted.
(sse2_eq3): Ditto.
(sse4_1_eqv2di3): Ditto.
(sse2_gt3): Rename to ..
(*sse2_gt3): .. this.
gcc/testsuite/ChangeLog:
PR target/98911
* gcc.target/i386/pr98911.c: New test.
* gcc.target/i386/funcspec-8.c: Replace __builtin_ia32_pcmpgtq
with __builtin_ia32_pcmpistrm128 since it has been folded.
[Bug target/98911] Add folding and remove expanders for x86 *pcmp{et,gt}* builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98911 --- Comment #2 from Hongtao.liu --- Fixed in GCC12.
[Bug c++/100252] New: Internal compiler error during template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100252
Bug ID: 100252
Summary: Internal compiler error during template instantiation
Product: gcc
Version: 10.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sand at rifkin dot dev
Target Milestone: ---
An internal compiler error occurs while compiling this template code:
https://godbolt.org/z/rP9Wf97vP.
Error message:
: In member function 'typename example::Ac::gt::k& tcc::gr()
[with int I = 1; A = {float, int}]':
:97:62: internal compiler error: in replace_placeholders_r, at
cp/tree.c:3332
97 | return typename example::Ac::template gt{k}.K;
| ~^
0x1cff079 internal_error(char const*, ...)
???:0
0x6bac69 fancy_abort(char const*, int, char const*)
???:0
0x13971f3 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
[Bug rtl-optimization/100253] New: [10/11/12 Regression] wrong code with -O2 -fno-tree-bit-ccp -ftree-slp-vectorize (unaligned movdqa)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100253 Bug ID: 100253 Summary: [10/11/12 Regression] wrong code with -O2 -fno-tree-bit-ccp -ftree-slp-vectorize (unaligned movdqa) Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Created attachment 50672 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50672&action=edit testcase Output: $ x86_64-pc-linux-gnu-g++ testcase.C -O2 -fno-tree-bit-ccp -ftree-slp-vectorize $ ./a.out Segmentation fault Program received signal SIGSEGV, Segmentation fault. 0x004011aa in S::operator= (this=0x404120 ) at testcase.C:7 7 struct S (gdb) disas Dump of assembler code for function main(): 0x00401180 <+0>: push %rbp 0x00401181 <+1>: mov$0x404120,%edi 0x00401186 <+6>: push %rbx 0x00401187 <+7>: sub$0x8,%rsp 0x0040118b <+11>:movsbq 0x2f2d(%rip),%rbp# 0x4040c0 0x00401193 <+19>:shl$0x6,%rbp 0x00401197 <+23>:lea0x4040e0(%rbp),%rsi 0x0040119e <+30>:call 0x4014e0 <_ZNSt6vectorIS_I1TSaIS0_EESaIS2_EEaSERKS4_> 0x004011a3 <+35>:movzbl 0x4040f8(%rbp),%eax => 0x004011aa <+42>:movdqa 0x404109(%rbp),%xmm0 0x004011b2 <+50>:movdqa 0x4040f9(%rbp),%xmm1 0x004011ba <+58>:mov%al,0x2f78(%rip)# 0x404138 0x004011c0 <+64>:xor%eax,%eax 0x004011c2 <+66>:movups %xmm1,0x2f70(%rip)# 0x404139 0x004011c9 <+73>:movups %xmm0,0x2f79(%rip)# 0x404149 0x004011d0 <+80>:add$0x8,%rsp 0x004011d4 <+84>:pop%rbx 0x004011d5 <+85>:pop%rbp 0x004011d6 <+86>:ret
[Bug libstdc++/100249] missing forwarding std::__invoke result in ranges::is_permutation and ranges::clamp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100249 --- Comment #1 from 康桓瑋 --- (In reply to 康桓瑋 from comment #0) > when the type of __proj_val is an rvalue reference, we need to convert it to > rvalue for the next std::__invoke call: https://godbolt.org/z/1G7aqxs3c. More simple case: https://godbolt.org/z/Y11c71cq6
