[Bug target/100866] PPC: Inefficient code for vec_revb(vector unsigned short) < P9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100866
--- Comment #5 from luoxhu at gcc dot gnu.org ---
(In reply to Segher Boessenkool from comment #4)
> This PR is specifically about the vec_revb builtin. But yes, we should
> look at what is generated for all other code (having only the builtin
> generate good code is suboptimal for a generic thing like this), and for
> other sizes as well.
Sorry I don't quite understand what you mean. IMO vec_revb is expanded by
CODE_FOR_revb_v8hi through revb_ pattern. So this is where we should
change to make better code generation...
For V8HI, it is natural to use vspltish 8+vrlh to turn
{0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15} to
{1,0,3,2,5,4,7,6,9,8,11,10,13,12,15,14}.
But for V4SI, we need use vspltish+vrlh to turn it to
{1,0,3,2,5,4,7,6,9,8,11,10,13,12,15,14} first, and a "vrlw 16" to turn it to
{3,2,1,0,7,6,5,4,11,10,9,8,15,14,13,12}. I am not sure whether this is better
than lvx+xxlnor+vperm especially for V2DI with additional "vrld 32" or
"vrld 32"+"vrlq 64"? (Those are all operations on register without load from
memory like lvx.)
bt 5
#0 gen_revb_v8hi (operand0=0x74d4ce40, operand1=0x74d4cf60) at
../../gcc/gcc/config/rs6000/vsx.md:5858
#1 0x10b05360 in insn_gen_fn::operator()
(this=0x130ab188 ) at../../gcc/gcc/recog.h:407
#2 0x11aa1e30 in rs6000_expand_unop_builtin (icode=CODE_FOR_revb_v8hi,
exp=
, target=0x74d4ce40) at ../../gcc/gcc/config/rs6000/rs6000-call.c:9451
#3 0x11ab27a4 in rs6000_expand_builtin (exp=, target=0x74d4ce40, subtarget=0x0, mode=E_V8HImode,
ignore=0) at ../../gcc/gcc/config/rs6000/rs6000-call.c:13157
#4 0x10815268 in expand_builtin (exp=,
target=0x74d4ce40, subtarget=0x0, mode=E_V8HImode, ignore=0) at
../../gcc/gcc/builtins.c:9559
[Bug c/92249] ICE in c_parser_gimple_compound_statement w/ GIMPLE testcases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92249 --- Comment #7 from Arseny Solokha --- I've been considering nominating this PR as a blocker for PR101057, but cannot reproduce the ICE w/ gcc-12.0.0_alpha20210613 snapshot.
[Bug tree-optimization/101088] New: [12 Regression] ICE in sm_seq_valid_bb, at tree-ssa-loop-im.c:2383
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101088 Bug ID: 101088 Summary: [12 Regression] ICE in sm_seq_valid_bb, at tree-ssa-loop-im.c:2383 Product: gcc Version: 12.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: --- Created attachment 51026 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51026=edit Testcase gcc-12.0.0-alpha20210613 snapshot (g:681143b9b94d7f1c88a7c34e2250865c31191959) ICEs when compiling the attached testcase w/ -O1: % gcc-12.0.0 -O1 -c eltbeodv.c during GIMPLE pass: lim eltbeodv.c: In function 'qw': eltbeodv.c:4:1: internal compiler error: in sm_seq_valid_bb, at tree-ssa-loop-im.c:2383 4 | qw (int n2) | ^~ 0x7048b8 sm_seq_valid_bb /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210613/work/gcc-12-20210613/gcc/tree-ssa-loop-im.c:2383 0xf652cd hoist_memory_references /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210613/work/gcc-12-20210613/gcc/tree-ssa-loop-im.c:2538 0xf66e0a store_motion_loop /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210613/work/gcc-12-20210613/gcc/tree-ssa-loop-im.c:2925 0xf69092 do_store_motion /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210613/work/gcc-12-20210613/gcc/tree-ssa-loop-im.c:2945 0xf69092 loop_invariant_motion_in_fun(function*, bool) /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210613/work/gcc-12-20210613/gcc/tree-ssa-loop-im.c:3170 0xf695e9 execute /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210613/work/gcc-12-20210613/gcc/tree-ssa-loop-im.c:3231
[Bug fortran/82376] Duplicate function call using -fcheck=pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82376 José Rui Faustino de Sousa changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from José Rui Faustino de Sousa --- Fixed on mainline for gcc-12, 11-branch and 10-branch. Best regards, José Rui
[Bug testsuite/101020] [12 regression] Several test case failures after r12-1316
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101020 luoxhu at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from luoxhu at gcc dot gnu.org --- Fixed.
[Bug analyzer/101082] new test case gcc.dg/analyzer/bitfields-1.c from r12-1303 fails on BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101082 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from David Malcolm --- Should be fixed by the above commit. Please reopen if it's still failing on another target. Sorry again for the breakage.
[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212 --- Comment #19 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:ec3fafa9ec7d16b9d89076efd3bac1d1af0502b8 commit r12-1491-gec3fafa9ec7d16b9d89076efd3bac1d1af0502b8 Author: David Malcolm Date: Tue Jun 15 17:53:34 2021 -0400 analyzer: fix bitfield endianness issues [PR99212,PR101082] Looks like my patch for PR analyzer/99212 implicitly assumed little-endian, which the following patch fixes. Fixes bitfields-1.c on: - armeb-none-linux-gnueabihf - cris-elf - powerpc64-darwin - s390-linux-gnu gcc/analyzer/ChangeLog: PR analyzer/99212 PR analyzer/101082 * engine.cc: Include "target.h". (impl_run_checkers): Log BITS_BIG_ENDIAN, BYTES_BIG_ENDIAN, and WORDS_BIG_ENDIAN. * region-model-manager.cc (region_model_manager::maybe_fold_binop): Move support for masking via ARG0 & CST into... (region_model_manager::maybe_undo_optimize_bit_field_compare): ...this new function. Flatten by converting from nested conditionals to a series of early return statements to reject failures. Reject if type is not unsigned_char_type_node. Handle BYTES_BIG_ENDIAN when determining which bits are bound in the binding_map. * region-model.h (region_model_manager::maybe_undo_optimize_bit_field_compare): New decl. * store.cc (bit_range::dump): New function. * store.h (bit_range::dump): New decl. Signed-off-by: David Malcolm
[Bug analyzer/101082] new test case gcc.dg/analyzer/bitfields-1.c from r12-1303 fails on BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101082 --- Comment #3 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:ec3fafa9ec7d16b9d89076efd3bac1d1af0502b8 commit r12-1491-gec3fafa9ec7d16b9d89076efd3bac1d1af0502b8 Author: David Malcolm Date: Tue Jun 15 17:53:34 2021 -0400 analyzer: fix bitfield endianness issues [PR99212,PR101082] Looks like my patch for PR analyzer/99212 implicitly assumed little-endian, which the following patch fixes. Fixes bitfields-1.c on: - armeb-none-linux-gnueabihf - cris-elf - powerpc64-darwin - s390-linux-gnu gcc/analyzer/ChangeLog: PR analyzer/99212 PR analyzer/101082 * engine.cc: Include "target.h". (impl_run_checkers): Log BITS_BIG_ENDIAN, BYTES_BIG_ENDIAN, and WORDS_BIG_ENDIAN. * region-model-manager.cc (region_model_manager::maybe_fold_binop): Move support for masking via ARG0 & CST into... (region_model_manager::maybe_undo_optimize_bit_field_compare): ...this new function. Flatten by converting from nested conditionals to a series of early return statements to reject failures. Reject if type is not unsigned_char_type_node. Handle BYTES_BIG_ENDIAN when determining which bits are bound in the binding_map. * region-model.h (region_model_manager::maybe_undo_optimize_bit_field_compare): New decl. * store.cc (bit_range::dump): New function. * store.h (bit_range::dump): New decl. Signed-off-by: David Malcolm
[Bug c++/96003] [11 Regression] spurious -Wnonnull calling a member on the result of static_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96003 Nadav Har'El changed: What|Removed |Added CC||nyh at math dot technion.ac.il --- Comment #27 from Nadav Har'El --- I think this problem still exists at least in some form, and should be reopened. It just hit the Seastar project, with gcc 11.1.1 - https://github.com/scylladb/seastar/issues/914. The problem there is that it uses C-style callbacks (of the c-ares library) that cannot be modified; The callback gets a void* argument. We pass a C++'s object's address into this void*, and then inside the callback function itself, cast the void* back (using reinterpret_cast) to the object pointer - and then attempt to run methods of this pointer. Here is where gcc 11.1.1. warns us that this pointer may be a null (the message erroneously says "is a null") - although I know for a fact it cannot be a null, and sadly even adding an assert(p) to tell the compiler I'm sure it is not a null - doesn't help.
[Bug c++/101087] New: Unevaluated operand of sizeof affects noexcept operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101087 Bug ID: 101087 Summary: Unevaluated operand of sizeof affects noexcept operator Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: rkhlebnikov at bloomberg dot net Target Milestone: --- clang, icc, MSVC all agree that the following `static_assert` should pass: ``` int f(); static_assert(noexcept(sizeof(f())), ""); // Fails on GCC ``` Such is not the case for gcc. However, adding `decltype` to the mix helps: ``` int f(); static_assert(noexcept(sizeof(decltype(f(, ""); // OK ```
[Bug rtl-optimization/101086] New: ICE at -O2 and -O3 on x86_64-linux-gnu with "-ftracer -fvar-tracking-assignments -fsel-sched-pipelining -fselective-scheduling -fschedule-insns": in create_block_for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101086
Bug ID: 101086
Summary: ICE at -O2 and -O3 on x86_64-linux-gnu with "-ftracer
-fvar-tracking-assignments -fsel-sched-pipelining
-fselective-scheduling -fschedule-insns": in
create_block_for_bookkeeping, at sel-sched.c:4537
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
It seems to affect GCC 10.* and later.
[516] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210615 (experimental) [master revision
4602714382f:c4ce2fa5b57:6d43ec50966cafb339eb6a370a5d767a24f673e1] (GCC)
[517] %
[517] % gcctk -O2 -c -ftracer -fvar-tracking-assignments -fsel-sched-pipelining
-fselective-scheduling -fschedule-insns small.c
cc1: warning: var-tracking-assignments changes selective scheduling
during RTL pass: sched1
small.c: In function ‘main’:
small.c:12:1: internal compiler error: in create_block_for_bookkeeping, at
sel-sched.c:4537
12 | }
| ^
0xd63b4c create_block_for_bookkeeping
../../gcc-trunk/gcc/sel-sched.c:4537
0xd63b4c find_place_for_bookkeeping
../../gcc-trunk/gcc/sel-sched.c:4686
0xd63b4c generate_bookkeeping_insn
../../gcc-trunk/gcc/sel-sched.c:4786
0xd63b4c move_op_at_first_insn
../../gcc-trunk/gcc/sel-sched.c:6063
0xd6435d code_motion_path_driver
../../gcc-trunk/gcc/sel-sched.c:6657
0xd64c6b code_motion_process_successors
../../gcc-trunk/gcc/sel-sched.c:6342
0xd64c6b code_motion_path_driver
../../gcc-trunk/gcc/sel-sched.c:6608
0xd64c6b code_motion_process_successors
../../gcc-trunk/gcc/sel-sched.c:6342
0xd64c6b code_motion_path_driver
../../gcc-trunk/gcc/sel-sched.c:6608
0xd64c6b code_motion_process_successors
../../gcc-trunk/gcc/sel-sched.c:6342
0xd64c6b code_motion_path_driver
../../gcc-trunk/gcc/sel-sched.c:6608
0xd653e3 move_op
../../gcc-trunk/gcc/sel-sched.c:6702
0xd653e3 move_exprs_to_boundary
../../gcc-trunk/gcc/sel-sched.c:5223
0xd653e3 schedule_expr_on_boundary
../../gcc-trunk/gcc/sel-sched.c:5436
0xd6928b fill_insns
../../gcc-trunk/gcc/sel-sched.c:5578
0xd6ae60 schedule_on_fences
../../gcc-trunk/gcc/sel-sched.c:7353
0xd6ae60 sel_sched_region_2
../../gcc-trunk/gcc/sel-sched.c:7491
0xd6bd98 sel_sched_region_1
../../gcc-trunk/gcc/sel-sched.c:7533
0xd6d1f4 sel_sched_region(int)
../../gcc-trunk/gcc/sel-sched.c:7634
0xd6da89 run_selective_scheduling()
../../gcc-trunk/gcc/sel-sched.c:7720
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.
[518] %
[518] % cat small.c
extern int k(int);
int a, b;
int c(int d) { return d ? 0 : a; }
unsigned e(int d, int f) { return f < 0 ? d : d << f; }
int main() {
int h;
long i = 2412553438;
while (b)
if (k(c(e(h, i
i = 0;
return 0;
}
[Bug fortran/101084] [10/11/12 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1124
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101084 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 --- Comment #2 from anlauf at gcc dot gnu.org --- Regtests ok. Submitted: https://gcc.gnu.org/pipermail/fortran/2021-June/056166.html
[Bug analyzer/101082] new test case gcc.dg/analyzer/bitfields-1.c from r12-1303 fails on BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101082 --- Comment #2 from seurer at gcc dot gnu.org --- Ah, crud. I picked the wrong test case to look at. If I'd searched on gcc.dg/analyzer/data-model-1.c I would have seen that other PR.
[Bug gcov-profile/80223] RFE: Exclude functions from profile instrumentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80223 --- Comment #8 from Fangrui Song --- I am thinking of __attribute__((no_profile)). In Clang, -fprofile-generate(-fcs-profile-generate)/-fprofile-instr-generate/-fprofile-arcs are all different. It will make sense to have a attribute disabling all such profiling related features. I am not sure an umbrella __attribute__((no_instrument_function)) is suitable. The Linux kernel wanting noinstr to exclude -fprofile-* is a very specific characteristic, not suitable for other applications.
[Bug libstdc++/100940] views::take and views::drop should not define _S_has_simple_extra_args
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100940 --- Comment #8 from Patrick Palka --- (In reply to TC from comment #7) > (In reply to Patrick Palka from comment #6) > > > > For the other adaptors, we still unconditionally disable perfect forwarding > > call wrapper semantics. I'm not sure if the performance/diagnostic tradeoff > > is worth it to enable perfect forwarding semantics when the function object > > is non-trivial. > > Personally, I'd happily pay some diagnostic complexity when I get things > wrong if that means I get better performance when I get things right. Good > diagnostics only matter when my code is broken, while performance matters > when my code is working. The former should (hopefully) be a transient > condition. Sounds good; a followup patch that implements this is at https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572829.html The patch limits the "simple" forwarding case to only trivially copyable extra arguments, and does so for all adaptors. So take_while/drop_while/filter/transform(std::function) as well as split(non_triv_copyable_view) would be considered non-simple under this restriction.
[Bug analyzer/101082] new test case gcc.dg/analyzer/bitfields-1.c from r12-1303 fails on BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101082 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-06-15 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from David Malcolm --- Sorry about this. As noted in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212#c18 I'm testing a fix for targets where BYTES_BIG_ENDIAN is set; FWIW the fix seems to work on --target=powerpc64-darwin.
[Bug fortran/101084] [10/11/12 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1124
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101084
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Target Milestone|--- |10.4
Last reconfirmed||2021-06-15
Priority|P3 |P4
Status|UNCONFIRMED |NEW
CC||anlauf at gcc dot gnu.org
--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.
Untested fix:
diff --git a/gcc/fortran/io.c b/gcc/fortran/io.c
index 40cd76eb585..fc97df79eca 100644
--- a/gcc/fortran/io.c
+++ b/gcc/fortran/io.c
@@ -1763,7 +1763,7 @@ resolve_tag_format (gfc_expr *e)
if (e->ts.type != BT_CHARACTER)
{
if (e->ts.type == BT_DERIVED || e->ts.type == BT_CLASS
- || e->ts.type == BT_VOID)
+ || e->ts.type == BT_VOID || e->ts.type == BT_UNKNOWN)
{
gfc_error ("Non-character non-Hollerith in FORMAT tag at %L",
>where);
This would give:
pr101084-z1.f90:3:8:
3 |print int(a)
|1
Error: Non-character non-Hollerith in FORMAT tag at (1)
[Bug middle-end/100876] [11 Regression] -Wmismatched-new-delete should understand placement new when it's not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100876 --- Comment #5 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:71790f398e119c7fed867b0cfce60a7500629dff commit r12-1490-g71790f398e119c7fed867b0cfce60a7500629dff Author: Martin Sebor Date: Tue Jun 15 12:42:06 2021 -0600 Consider size_t mangling as unsigned int and long [PR100876]. gcc/ChangeLog: PR middle-end/100876 * builtins.c: (gimple_call_return_array): Account for size_t mangling as either unsigned int or unsigned long
[Bug tree-optimization/101066] [10/11/12 Regression] Wrong code after fixup_cfg3 since r10-3311-gff6686d2e5f797d6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101066 Martin Jambor changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Martin Jambor --- The IPA-SRA transform is indeed invalid. There is a thinko in the point where safe_to_import_accesses check is overruled. So mine.
[Bug fortran/101085] ICE in gfc_conv_intrinsic_to_class, at fortran/trans-expr.c:1039
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101085 G. Steinmetz changed: What|Removed |Added Keywords||ice-on-invalid-code --- Comment #1 from G. Steinmetz --- $ cat z2.f90 program p type t integer :: n end type class(t), allocatable :: c(:) character(3) :: a(1) = ['abc'] c = [t(1)] if ( f(c, a) /= 1 ) stop 1 contains integer function f(x, y) class(t) :: x(:) class(*) :: y(size(x)) f = size(y) end end $ cat z3.f90 program p type t integer :: n end type class(t), allocatable :: c(:) integer :: a = 3 c = [t(1)] if ( f(c, a) /= 1 ) stop 1 contains integer function f(x, y) class(t) :: x(:) class(*) :: y(size(x)) f = size(y) end end $ gfortran-12-20210613 -c z2.f90 $ $ gfortran-12-20210613 -c z3.f90 z3.f90:8:13: 8 |if ( f(c, a) /= 1 ) stop 1 | 1 Error: Rank mismatch in argument 'y' at (1) (rank-1 and scalar)
[Bug fortran/101085] New: ICE in gfc_conv_intrinsic_to_class, at fortran/trans-expr.c:1039
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101085 Bug ID: 101085 Summary: ICE in gfc_conv_intrinsic_to_class, at fortran/trans-expr.c:1039 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- This invalid code z1 (rank mismatch scalar versus array) affects versions down to r7. Case z2 is a correct variant of z1, similar invalid case z3 is detected (integer instead of character) : $ cat z1.f90 program p type t integer :: n end type class(t), allocatable :: c(:) character(3) :: a = 'abc' c = [t(1)] if ( f(c, a) /= 1 ) stop 1 contains integer function f(x, y) class(t) :: x(:) class(*) :: y(size(x)) f = size(y) end end $ gfortran-12-20210613 -c z1.f90 z1.f90:8:8: 8 |if ( f(c, a) /= 1 ) stop 1 |1 internal compiler error: in fold_convert_loc, at fold-const.c:2553 0x9b26a3 fold_convert_loc(unsigned int, tree_node*, tree_node*) ../../gcc/fold-const.c:2553 0x7d4c5b gfc_conv_intrinsic_to_class(gfc_se*, gfc_expr*, gfc_typespec) ../../gcc/fortran/trans-expr.c:1039 0x7d5e65 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vec*) ../../gcc/fortran/trans-expr.c:5878 0x7cdaca gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.c:9017 0x7cde9d gfc_conv_expr_op ../../gcc/fortran/trans-expr.c:3883 0x7cde9d gfc_conv_expr(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.c:9013 0x7d0993 gfc_conv_expr_val(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-expr.c:9070 0x80dcf9 gfc_trans_if_1 ../../gcc/fortran/trans-stmt.c:1469 0x8158aa gfc_trans_if(gfc_code*) ../../gcc/fortran/trans-stmt.c:1507 0x79f9c7 trans_code ../../gcc/fortran/trans.c:2006 0x7c6054 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6893 0x74c876 translate_all_program_units ../../gcc/fortran/parse.c:6461 0x74c876 gfc_parse_file() ../../gcc/fortran/parse.c:6730 0x798bbf gfc_be_parse_file ../../gcc/fortran/f95-lang.c:212
[Bug tree-optimization/101083] [12 Regression] ICE with -Ofast in TYPE_VECTOR_SUBPARTS, at tree.h:3929
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101083 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug fortran/101084] New: [10/11/12 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1124
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101084 Bug ID: 101084 Summary: [10/11/12 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1124 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Changed between 20191215 and 20200105 : $ cat z1.f90 program p integer, parameter :: a(0) = 1 print int(a) end $ gfortran-10-20191215 -c z1.f90 z1.f90:3:8: 3 |print int(a) |1 Error: Constant expression in FORMAT tag at (1) must be of type default CHARACTER $ gfortran-12-20210613 -c z1.f90 z1.f90:3:8: 3 |print int(a) |1 Warning: Legacy Extension: Non-character in FORMAT tag at (1) z1.f90:3:15: 3 |print int(a) | 1 internal compiler error: in gfc_typenode_for_spec, at fortran/trans-types.c:1124 0x822a30 gfc_typenode_for_spec(gfc_typespec*, int) ../../gcc/fortran/trans-types.c:1124 0x7ada4c gfc_conv_expr_descriptor(gfc_se*, gfc_expr*) ../../gcc/fortran/trans-array.c:7544 0x7b46cb gfc_conv_array_parameter(gfc_se*, gfc_expr*, bool, gfc_symbol const*, char const*, tree_node**) ../../gcc/fortran/trans-array.c:8110 0x7fa20c gfc_convert_array_to_string ../../gcc/fortran/trans-io.c:788 0x7fa20c set_string ../../gcc/fortran/trans-io.c:848 0x7fc1be build_dt ../../gcc/fortran/trans-io.c:1941 0x79fb37 trans_code ../../gcc/fortran/trans.c:2110 0x7c6054 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6893 0x74c876 translate_all_program_units ../../gcc/fortran/parse.c:6461 0x74c876 gfc_parse_file() ../../gcc/fortran/parse.c:6730 0x798bbf gfc_be_parse_file ../../gcc/fortran/f95-lang.c:212
[Bug c/101083] New: [12 Regression] ICE with -Ofast in TYPE_VECTOR_SUBPARTS, at tree.h:3929
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101083
Bug ID: 101083
Summary: [12 Regression] ICE with -Ofast in
TYPE_VECTOR_SUBPARTS, at tree.h:3929
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Needs -Ofast, test case derived from pr97832-2.c (-3.c),
changed recently between 20210606 and 20210613 :
$ cat z1.c
void foo1x1(double* restrict y, const double* restrict x, int clen)
{
int xi = clen & 2;
double f_re = x[0+xi+0];
double f_im = x[4+xi+0];
int clen2 = (clen+xi) * 2;
for (int c = 0; c < clen2; c += 8) {
// y[c] = y[c] - x[c]*conj(f);
for (int k = 0; k < 4; ++k) {
double x_re = x[k];
double x_im = x[c+4+k];
double y_re = y[c+0+k];
double y_im = y[c+4+k];
y_re = y_re - x_re * f_re - x_im * f_im;;
y_im = y_im + x_re * f_im - x_im * f_re;
y[c+0+k] = y_re;
y[c+4+k] = y_im;
}
}
}
$ gcc-12-20210613 -c z1.c -O3
$
$ gcc-12-20210613 -c z1.c -Ofast
during GIMPLE pass: vect
z1.c: In function 'foo1x1':
z1.c:1:6: internal compiler error: Segmentation fault
1 | void foo1x1(double* restrict y, const double* restrict x, int clen)
| ^~
0xbd1bef crash_signal
../../gcc/toplev.c:327
0xe321c4 TYPE_VECTOR_SUBPARTS(tree_node const*)
../../gcc/tree.h:3929
0xe321c4 vect_get_num_vectors
../../gcc/tree-vectorizer.h:1658
0xe321c4 vect_slp_analyze_node_operations_1
../../gcc/tree-vect-slp.c:4254
0xe321c4 vect_slp_analyze_node_operations
../../gcc/tree-vect-slp.c:4432
0xe32134 vect_slp_analyze_node_operations
../../gcc/tree-vect-slp.c:4412
0xe32134 vect_slp_analyze_node_operations
../../gcc/tree-vect-slp.c:4412
0xe32134 vect_slp_analyze_node_operations
../../gcc/tree-vect-slp.c:4412
0xe34cc9 vect_slp_analyze_operations(vec_info*)
../../gcc/tree-vect-slp.c:4619
0xe0f73c vect_analyze_loop_2
../../gcc/tree-vect-loop.c:2396
0xe117c4 vect_analyze_loop(loop*, vec_info_shared*)
../../gcc/tree-vect-loop.c:2986
0xe4064c try_vectorize_loop_1
../../gcc/tree-vectorizer.c:1004
0xe40e41 vectorize_loops()
../../gcc/tree-vectorizer.c:1238
[Bug analyzer/101082] New: new test case gcc.dg/analyzer/bitfields-1.c from r12-1303 fails on BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101082 Bug ID: 101082 Summary: new test case gcc.dg/analyzer/bitfields-1.c from r12-1303 fails on BE Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:d3b1ef7a83c0c0cd5b20a1dd1714b868f3d2b442, r12-1303 These fail on BE on powerpc64. make -k check-gcc RUNTESTFLAGS="analyzer.exp=gcc.dg/analyzer/bitfields-1.c" FAIL: gcc.dg/analyzer/bitfields-1.c (test for warnings, line 24) FAIL: gcc.dg/analyzer/bitfields-1.c (test for warnings, line 26) FAIL: gcc.dg/analyzer/bitfields-1.c (test for warnings, line 29) FAIL: gcc.dg/analyzer/bitfields-1.c (test for warnings, line 31) FAIL: gcc.dg/analyzer/bitfields-1.c (test for warnings, line 36) FAIL: gcc.dg/analyzer/bitfields-1.c (test for warnings, line 41) FAIL: gcc.dg/analyzer/bitfields-1.c (test for warnings, line 81) FAIL: gcc.dg/analyzer/bitfields-1.c (test for warnings, line 83) FAIL: gcc.dg/analyzer/bitfields-1.c (test for warnings, line 85) FAIL: gcc.dg/analyzer/bitfields-1.c (test for warnings, line 87) FAIL: gcc.dg/analyzer/bitfields-1.c (test for warnings, line 92) FAIL: gcc.dg/analyzer/bitfields-1.c (test for warnings, line 94) FAIL: gcc.dg/analyzer/bitfields-1.c (test for warnings, line 96) FAIL: gcc.dg/analyzer/bitfields-1.c (test for warnings, line 113) FAIL: gcc.dg/analyzer/bitfields-1.c (test for warnings, line 115) FAIL: gcc.dg/analyzer/bitfields-1.c (test for warnings, line 117) FAIL: gcc.dg/analyzer/bitfields-1.c (test for warnings, line 119) FAIL: gcc.dg/analyzer/bitfields-1.c (test for warnings, line 121) FAIL: gcc.dg/analyzer/bitfields-1.c (test for warnings, line 123) FAIL: gcc.dg/analyzer/bitfields-1.c (test for warnings, line 125) FAIL: gcc.dg/analyzer/bitfields-1.c (test for warnings, line 127) FAIL: gcc.dg/analyzer/bitfields-1.c (test for excess errors) # of expected passes12 # of unexpected failures22 Excess errors: /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/bitfields-1.c:24:3: warning: UNKNOWN /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/bitfields-1.c:26:3: warning: UNKNOWN /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/bitfields-1.c:29:3: warning: UNKNOWN /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/bitfields-1.c:31:3: warning: UNKNOWN /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/bitfields-1.c:36:3: warning: FALSE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/bitfields-1.c:41:3: warning: FALSE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/bitfields-1.c:81:3: warning: UNKNOWN /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/bitfields-1.c:83:3: warning: UNKNOWN /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/bitfields-1.c:85:3: warning: UNKNOWN /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/bitfields-1.c:87:3: warning: UNKNOWN /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/bitfields-1.c:92:3: warning: FALSE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/bitfields-1.c:94:3: warning: FALSE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/bitfields-1.c:96:3: warning: FALSE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/bitfields-1.c:113:3: warning: UNKNOWN /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/bitfields-1.c:115:3: warning: UNKNOWN /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/bitfields-1.c:117:3: warning: UNKNOWN /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/bitfields-1.c:119:3: warning: UNKNOWN /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/bitfields-1.c:121:3: warning: UNKNOWN /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/bitfields-1.c:123:3: warning: UNKNOWN /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/bitfields-1.c:125:3: warning: UNKNOWN /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/bitfields-1.c:127:3: warning: UNKNOWN commit d3b1ef7a83c0c0cd5b20a1dd1714b868f3d2b442 Author: David Malcolm Date: Tue Jun 8 14:45:57 2021 -0400 analyzer: bitfield fixes [PR99212]
[Bug c/100653] usage of scalar_storage_order produces incorrect result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100653 --- Comment #10 from Eric Botcazou --- > The bisect ended up giving commit e7a3e0c653be4bd32f116dae06438896b7dc915b. > Reverting it for test purposes in gcc-7/gcc-8 just confirmed it is the > right trigger. > > There's obviously nothing wrong with that commit but at least it gave me > a clue what to look for. To my understanding of the code : > The RPO change affects evaluation order when merging and eliminating blocks. > In the case of the example, the compiler ends up checking if both fields > of the union are the same and can be merged/eliminated. Their both in the > same location. The code currently considers different signedness and bails > out, but not different endianness and eliminates one depending one > evaluation order. That's by design, the entire implementation assumes that every scalar in memory is accessed using the same storage order throughout the entire program. If you want to overcome this limitation, you need to reimplement it from scratch.
[Bug analyzer/101081] analyzer testsuite failures seen with new glibc due to malloc attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101081 David Malcolm changed: What|Removed |Added Last reconfirmed||2021-06-15 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED
[Bug analyzer/101081] New: analyzer testsuite failures seen with new glibc due to malloc attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101081 Bug ID: 101081 Summary: analyzer testsuite failures seen with new glibc due to malloc attribute Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Target Milestone: --- Fedora's build of GCC showed some new analyzer failures: +FAIL: gcc.dg/analyzer/analyzer-verbosity-2a.c (test for excess errors) +FAIL: gcc.dg/analyzer/analyzer-verbosity-3a.c (test for excess errors) +FAIL: gcc.dg/analyzer/edges-1.c (test for excess errors) +FAIL: gcc.dg/analyzer/file-1.c (test for excess errors) +FAIL: gcc.dg/analyzer/file-2.c (test for excess errors) +FAIL: gcc.dg/analyzer/file-paths-1.c (test for excess errors) +FAIL: gcc.dg/analyzer/file-pr58237.c (test for excess errors) +FAIL: gcc.dg/analyzer/pr99716-1.c (test for excess errors) which appeared between: gcc/11.1.1/3.fc35: glibc-2.33.9000-2.fc35.x86_64 gcc/11.1.1/4.fc35: glibc-2.33.9000-13.fc35.x86_64 These testcases all use Almost all of these seem to be due to new -Wanalyzer-malloc-leak warnings, where the testcases are expecting to emit -Wanalyzer-file-leak (from sm-file.cc), but are now *also* emitting -Wanalyzer-malloc-leak. Presumably the new glibc gained __attribute__((malloc)) within stdio.h. As well as these, pr99716-1.c adds these excess errors: /builddir/build/BUILD/gcc-11.1.1-20210531/gcc/testsuite/gcc.dg/analyzer/pr99716-1.c:11:5: warning: use of possibly-NULL 'fp' where non-null expected [CWE-690] [-Wanalyzer-possible-null-argument] /builddir/build/BUILD/gcc-11.1.1-20210531/gcc/testsuite/gcc.dg/analyzer/pr99716-1.c:23:5: warning: use of possibly-NULL 'fp' where non-null expected [CWE-690] [-Wanalyzer-possible-null-argument] /builddir/build/BUILD/gcc-11.1.1-20210531/gcc/testsuite/gcc.dg/analyzer/pr99716-1.c:36:5: warning: use of possibly-NULL '*fpp' where non-null expected [CWE-690] [-Wanalyzer-possible-null-argument] which look like genuine warnings: passing unchecked ptrs to fprintf. Looks like: (a) these testcases should avoid and instead have their own copy of the decls, to avoid from changing under us (b) the malloc attribute gave us some genuine warnings, so it's valuable; the analyzer should do something to support this, but it's probably overkill to emit *both* -Wanalyzer-malloc-leak and -Wanalyzer-file-leak.
[Bug tree-optimization/101061] tree-vrp misoptimization on skylake+ using union-based aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101061
--- Comment #8 from rguenther at suse dot de ---
On June 15, 2021 4:27:37 PM GMT+02:00, "alexander.gr...@tu-dresden.de"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101061
>
>--- Comment #6 from Alexander Grund ---
>Oh and for completeness: The same applies to the following union,
>doesn't it?
>I.e. given this:
>
>struct TF_TString_Raw {
> uint8_t raw[24];
>};
>struct TF_TString_Small {
> uint8_t size;
> char str[23];
>};
>struct TF_TString_Large {
> size_t size;
> size_t cap;
> char *ptr;
>};
>union{
>TF_TString_Raw raw;
>TF_TString_Small smll;
>TF_TString_Large large;
>} x;
>
>it is not allowed to access x.raw.raw[0] AND then x.large.size (not
>even a
>common initial subsequence) but also not x.raw.raw[0] AND then
>x.small.size
>(maybe a common sequence, not sure about the array, but not implemented
>in GCC)
Note that when the union type is visible in the access path then GCC allows
punning without further restrictions. Thus the accesses as written above are
OK. What is not OK is mixed accesses via pointers to the small/large/base
aggregate types. What is OK is accesses via an effective character type
(uint8_t is usually as implementation detail, not sure if by the standard),
thus char *
[Bug tree-optimization/101061] tree-vrp misoptimization on skylake+ using union-based aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101061
--- Comment #7 from rguenther at suse dot de ---
On June 15, 2021 4:21:12 PM GMT+02:00, "alexander.gr...@tu-dresden.de"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101061
>
>--- Comment #5 from Alexander Grund ---
>So am I right assuming that the following is basically UB as per GCC
>(although
>it should work as per the standard)?
>
>template
>union slot_type {
> map_slot_type() {}
> ~map_slot_type() = delete;
> using value_type = std::pair;
> using mutable_value_type = std::pair;
>
> value_type value;
> mutable_value_type mutable_value;
> K key;
>};
>
>--> I.e. given a pointer `slot_type* slot` it _should_ have been
>possible to
>access `slot->value.first`, `slot->mutable_value.first`, `slot->key`
>interchangeably but in fact it is not, i.e. not implemented in GCC.
That's correct.
>I'm asking because it "may" work, and e.g. seemingly does in GCC 9+,
Yeah, the circumstances have been so there's incentive to do an invalid
transform...
>but
>yeah... If that is indeed unsupported I'll open a bug report against
>the repo
>using this. Note that this effectively disallows having "flat" maps
>that return
>`std::pair` via their iterators but have support for moving
>items
>effectively (i.e. via `std::pair` pointers)
[Bug c/100653] usage of scalar_storage_order produces incorrect result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100653 --- Comment #9 from George Thopas --- Created attachment 51025 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51025=edit avoid eliminating fields with different endianess as equal Short story : Ran a bisect to find why this always works in the gcc-6 branch and has different behaviour outside. Found out what happens (see below) and attached a 2-line patch for what I assume is missing. Works for me but is it the 'right thing'(tm) todo ? Thanks. Long story: I started digging into this in the hope to get a better understanding In the last 3 years I've never seen this on the gcc-6 branch. Even though there's a tons of code and mixed endianess structures and unions validation. If I missed it, I at least needed to know at least why. The bisect ended up giving commit e7a3e0c653be4bd32f116dae06438896b7dc915b. Reverting it for test purposes in gcc-7/gcc-8 just confirmed it is the right trigger. There's obviously nothing wrong with that commit but at least it gave me a clue what to look for. To my understanding of the code : The RPO change affects evaluation order when merging and eliminating blocks. In the case of the example, the compiler ends up checking if both fields of the union are the same and can be merged/eliminated. Their both in the same location. The code currently considers different signedness and bails out, but not different endianness and eliminates one depending one evaluation order. Whatever one that is.
[Bug target/101022] rs6000: __builtin_altivec_vcmpequt expands to wrong pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101022 --- Comment #5 from CVS Commits --- The master branch has been updated by Carl Love : https://gcc.gnu.org/g:913b13fcb1dceea0e57a04cb77b11097b132cbf6 commit r12-1483-g913b13fcb1dceea0e57a04cb77b11097b132cbf6 Author: Carl Love Date: Thu Jun 10 17:36:25 2021 -0500 Fix for vcmpequt builtin The vcmpequt builtin define eqvv1ti3 points to the eqv define instruction for the eqv instruction. The vcmpequt builtin define should point to the vector_eqv1ti instruction definition for the vcmpequq instruction. 2021-06-15 Carl Love gcc/ChangeLog PR target/101022 * config/rs6000/rs6000-builtin.def (VCMPEQUT): Fix the ICODE for the enum definition. (VRLQ, VSLQ, VSRQ, VSRAQ): Remove unused BU_P10_OVERLOAD_2 definitions.
[Bug tree-optimization/100453] [12 Regression] wrong code at -O1 and above since r12-434
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100453 --- Comment #13 from Martin Jambor --- Another attempt to fix this: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572814.html
[Bug c++/101078] [11/12 Regression] Rejected code since r12-1272-gf07edb5d7f3e7721
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101078
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #2 from Patrick Palka ---
Reduced rejects-valid testcase:
struct A {
static void f();
};
template
struct B : private A {
struct C {
void g() { f(); }
};
};
int main() {
B::C().g();
}
This might be a latent bug, for if the call f() is replaced with B::f(), then
we started rejecting after r8-5270.
If the call f() is replaced with A::f(), we accept.
[Bug tree-optimization/100494] [11/12 Regression] Unterminated recursion in gimple-range.cc (x86_64-w64-mingw32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100494 --- Comment #10 from Andrew Macleod --- I would imagine there is some check I should be making that i was unaware of.. but since I'm unaware of it, I don't know what it is :-) This wouldn't be a "dont use -O2" issue, this would be an "Andrew, check the darn limits before going hogwild on call depth" issue
[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212 --- Comment #18 from David Malcolm --- (In reply to Stefan Schulze Frielinghaus from comment #17) > The new testcases introduced by commit d3b1ef7a83c fail on IBM Z as well as > some older data-model tests: Sorry about this; it sounds similar to the issues reported by Christophe Lyon on armeb-none-linux-gnueabihf here: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572375.html That one appears to be a bug with that patch, for targets where BYTES_BIG_ENDIAN is set. I'm testing a fix for it, using config-list.mk to test all targets, but it's taking a while; FWIW the fix seems to work on s390-linux-gnu, which for my reference has: BITS_BIG_ENDIAN: 1 BYTES_BIG_ENDIAN: 1 WORDS_BIG_ENDIAN: 1
[Bug tree-optimization/101061] tree-vrp misoptimization on skylake+ using union-based aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101061
--- Comment #6 from Alexander Grund ---
Oh and for completeness: The same applies to the following union, doesn't it?
I.e. given this:
struct TF_TString_Raw {
uint8_t raw[24];
};
struct TF_TString_Small {
uint8_t size;
char str[23];
};
struct TF_TString_Large {
size_t size;
size_t cap;
char *ptr;
};
union{
TF_TString_Raw raw;
TF_TString_Small smll;
TF_TString_Large large;
} x;
it is not allowed to access x.raw.raw[0] AND then x.large.size (not even a
common initial subsequence) but also not x.raw.raw[0] AND then x.small.size
(maybe a common sequence, not sure about the array, but not implemented in GCC)
[Bug tree-optimization/100494] [11/12 Regression] Unterminated recursion in gimple-range.cc (x86_64-w64-mingw32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100494 --- Comment #9 from J.M. Eubank --- > I am unfamiliar with what mitigations/flags the compiler has for trying to > control this. It would certainly be possible to monitor the call depth and > cease at a certain point, but Im not sure what needs to be queried. Is this > information communicated by a target in some way? and checked against some > criteria for passes which may need to limit their consumption? +1, this would be nice? I'm running a build with -Wl,--stack=10485760 (10 MiB) to see if this alleviates the problem. However, I'm definitely curious to see how this might be handled for other actually constrained targets where that's not an option - do they simply recommend not to use -O2?
[Bug tree-optimization/101061] tree-vrp misoptimization on skylake+ using union-based aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101061
--- Comment #5 from Alexander Grund ---
So am I right assuming that the following is basically UB as per GCC (although
it should work as per the standard)?
template
union slot_type {
map_slot_type() {}
~map_slot_type() = delete;
using value_type = std::pair;
using mutable_value_type = std::pair;
value_type value;
mutable_value_type mutable_value;
K key;
};
--> I.e. given a pointer `slot_type* slot` it _should_ have been possible to
access `slot->value.first`, `slot->mutable_value.first`, `slot->key`
interchangeably but in fact it is not, i.e. not implemented in GCC.
I'm asking because it "may" work, and e.g. seemingly does in GCC 9+, but
yeah... If that is indeed unsupported I'll open a bug report against the repo
using this. Note that this effectively disallows having "flat" maps that return
`std::pair` via their iterators but have support for moving items
effectively (i.e. via `std::pair` pointers)
[Bug tree-optimization/101080] New: wrong code with "-O3"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101080
Bug ID: 101080
Summary: wrong code with "-O3"
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: suochenyao at 163 dot com
Target Milestone: ---
***
OS and Platform:
CentOS Linux release 7.8.2003 (Core), x86_64 GNU/Linux
***
Program:
struct a {
unsigned b : 3;
} const c;
char d;
int e;
long f;
void g(const struct a h) {
for (; d != 20; d = d + 4) {
int i = h.b;
e = h.b;
f = h.b || 0;
}
}
int main() { g(c); }
***
gcc version:
$ gcc -v
Using built-in specs.
COLLECT_GCC=/data/bin/gcc-dev/bin/gcc
COLLECT_LTO_WRAPPER=/data/bin/gcc-dev/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/data/bin/gcc-dev --disable-multilib
--enable-languages=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210614 (experimental) (GCC)
git version: f9598d89a9f5a327ecdfa6f6978a0cfbe4447111
***
Command Lines:
$ gcc a.c -o a1.out
$ gcc -O3 -Wall -Wextra -fno-strict-aliasing -fwrapv a.c -o a2.out
a.c: In function ‘g’:
a.c:9:9: warning: unused variable ‘i’ [-Wunused-variable]
9 | int i = h.b;
| ^
$ ./a1.out
$ ./a2.out
Segmentation fault (core dumped)
[Bug tree-optimization/100494] [11/12 Regression] Unterminated recursion in gimple-range.cc (x86_64-w64-mingw32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100494 --- Comment #8 from Andrew Macleod --- ah. So this is an issue with excessive stack consumption. yeah, we don't really try to reign that in, so certain patterns can get quite deep. I am unfamiliar with what mitigations/flags the compiler has for trying to control this. It would certainly be possible to monitor the call depth and cease at a certain point, but Im not sure what needs to be queried. Is this information communicated by a target in some way? and checked against some criteria for passes which may need to limit their consumption?
[Bug fortran/92568] OpenMP 5 - implicit mapping of scalar with TARGET/ALLOCATABLE/POINTER attribute: shall be 'tofrom' mapped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92568 Tobias Burnus changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Tobias Burnus --- FIXED. Follow-up issue: * PR 90742 comment 3 (target/mapping: firstprivate mishandles allocatables) * PR 100991 - optional scalars misclassified as pointer (and firstprivate does not handle absent scalars)
[Bug fortran/92568] OpenMP 5 - implicit mapping of scalar with TARGET/ALLOCATABLE/POINTER attribute: shall be 'tofrom' mapped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92568 --- Comment #4 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:1de31913d20a467b78904c0e96efd5fbd6facd2c commit r12-1482-g1de31913d20a467b78904c0e96efd5fbd6facd2c Author: Tobias Burnus Date: Tue Jun 15 16:06:38 2021 +0200 Fortran/OpenMP: Extend defaultmap clause for OpenMP 5 [PR92568] PR fortran/92568 gcc/fortran/ChangeLog: * dump-parse-tree.c (show_omp_clauses): Update for defaultmap. * f95-lang.c (LANG_HOOKS_OMP_ALLOCATABLE_P, LANG_HOOKS_OMP_SCALAR_TARGET_P): New. * gfortran.h (enum gfc_omp_defaultmap, enum gfc_omp_defaultmap_category): New. * openmp.c (gfc_match_omp_clauses): Update defaultmap matching. * trans-decl.c (gfc_finish_decl_attrs): Set GFC_DECL_SCALAR_TARGET. * trans-openmp.c (gfc_omp_allocatable_p, gfc_omp_scalar_target_p): New. (gfc_omp_scalar_p): Take 'ptr_alloc_ok' argument. (gfc_trans_omp_clauses, gfc_split_omp_clauses): Update for defaultmap changes. * trans.h (gfc_omp_scalar_p): Update prototype. (gfc_omp_allocatable_p, gfc_omp_scalar_target_p): New. (struct lang_decl): Add scalar_target. (GFC_DECL_SCALAR_TARGET, GFC_DECL_GET_SCALAR_TARGET): New. gcc/ChangeLog: * gimplify.c (enum gimplify_defaultmap_kind): Add GDMK_SCALAR_TARGET. (struct gimplify_omp_ctx): Extend defaultmap array by one. (new_omp_context): Init defaultmap[GDMK_SCALAR_TARGET]. (omp_notice_variable): Update type classification for Fortran. (gimplify_scan_omp_clauses): Update calls for new argument; handle GDMK_SCALAR_TARGET; for Fortran, GDMK_POINTER avoid GOVD_MAP_0LEN_ARRAY. * langhooks-def.h (lhd_omp_scalar_p): Add 'ptr_ok' argument. * langhooks.c (lhd_omp_scalar_p): Likewise. (LANG_HOOKS_OMP_ALLOCATABLE_P, LANG_HOOKS_OMP_SCALAR_TARGET_P): New. (LANG_HOOKS_DECLS): Add them. * langhooks.h (struct lang_hooks_for_decls): Add new hooks, update omp_scalar_p pointer type to include the new bool argument. libgomp/ChangeLog: * testsuite/libgomp.fortran/defaultmap-8.f90: New test. gcc/testsuite/ChangeLog: * gfortran.dg/gomp/pr99928-1.f90: Uncomment 'defaultmap(none)'. * gfortran.dg/gomp/pr99928-2.f90: Uncomment 'defaultmap(none)'. * gfortran.dg/gomp/pr99928-3.f90: Uncomment 'defaultmap(none)'. * gfortran.dg/gomp/pr99928-4.f90: Uncomment 'defaultmap(none)'. * gfortran.dg/gomp/pr99928-5.f90: Uncomment 'defaultmap(none)'. * gfortran.dg/gomp/pr99928-6.f90: Uncomment 'defaultmap(none)'. * gfortran.dg/gomp/pr99928-8.f90: Uncomment 'defaultmap(none)'. * gfortran.dg/gomp/defaultmap-1.f90: New test. * gfortran.dg/gomp/defaultmap-2.f90: New test. * gfortran.dg/gomp/defaultmap-3.f90: New test. * gfortran.dg/gomp/defaultmap-4.f90: New test. * gfortran.dg/gomp/defaultmap-5.f90: New test. * gfortran.dg/gomp/defaultmap-6.f90: New test. * gfortran.dg/gomp/defaultmap-7.f90: New test.
[Bug tree-optimization/100494] [11/12 Regression] Unterminated recursion in gimple-range.cc (x86_64-w64-mingw32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100494 --- Comment #7 from J.M. Eubank --- Created attachment 51024 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51024=edit sha1.c.038t.evrp.gz > Does the compilation not finish? or just take ma very long time? On the > other targets it finishes very quickly, spending very little time in EVRP. > Its unclear to me why this target would be so different, unless a deep call > stack is a problem. The default stack limit is 1 MiB, so a bit of quick math from the above addresses I posted puts us at 1.2 MiB - this definitely is in line with chkstk failing as we go out of bounds, I think. > Does the issue go away with --param=evrp-mode=legacy ? Yes, it does! > If it does seem to go into an infinite loop, can you try it with >-fdump-tree-evrp-details --param=evrp-mode=trace Attached. joeub@DESKTOP-1LUONFR MINGW64 /crossdev/gccmaster/build-cross4/binutils/libiberty $ /crossdev/gccmaster/host-toolchain-cross4/bin/x86_64-w64-mingw32-gcc -I . -I C:/crossdev/src/binutils-git-2_36_1/libiberty/../include -iprefix c:\crossdev\gccmaster\host-toolchain-cross4\bin\../lib/gcc/x86_64-w64-mingw32/11.1.0/ -D_REENTRANT -D HAVE_CONFIG_H -D __USE_MINGW_ACCESS -D _GNU_SOURCE C:/crossdev/src/binutils-git-2_36_1/libiberty/sha1.c -g -O2 -c -fdump-tree-evrp-details --param=evrp-mode=trace joeub@DESKTOP-1LUONFR MINGW64 /crossdev/gccmaster/build-cross4/binutils/libiberty $ echo $? 1 <-- indicator for chkstk failure in cc1 joeub@DESKTOP-1LUONFR MINGW64 /crossdev/gccmaster/build-cross4/binutils/libiberty $ gzip sha1.c.038t.evrp
[Bug target/100866] PPC: Inefficient code for vec_revb(vector unsigned short) < P9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100866 --- Comment #4 from Segher Boessenkool --- This PR is specifically about the vec_revb builtin. But yes, we should look at what is generated for all other code (having only the builtin generate good code is suboptimal for a generic thing like this), and for other sizes as well.
[Bug tree-optimization/100494] [11/12 Regression] Unterminated recursion in gimple-range.cc (x86_64-w64-mingw32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100494 --- Comment #6 from Andrew Macleod --- WE collided making comments :-) --- or maybe not.. that traceback doesn't look like it would be affected :-(. The traceback also doesn't look like its in an infinite loop?.. there can be long chains of calls to resolve things on back edges. Looking at the listing for that file, I see at its maximal depth, the call chain is 492 "traceable" statements deep. This does not include range_of_range_op or calc_stmt method calls, so Id expect the peak call depth to be about 30-40% higher than that, so somewhere in the 640-690 deep range from the first hybrid_folder::value_on_edge call. Your call chain is at 619, so that is not completely unexpected. Does the compilation not finish? or just take ma very long time? On the other targets it finishes very quickly, spending very little time in EVRP. Its unclear to me why this target would be so different, unless a deep call stack is a problem. Does the issue go away with --param=evrp-mode=legacy ? If it does seem to go into an infinite loop, can you try it with -fdump-tree-evrp-details --param=evrp-mode=trace That will generate a sha1*.evrp file, and if you are truly in an infinite loop it will become quite long. On x86-64 mine is 48940 lines long when it finishes. If you have to stop it, and its growing excessively, I shouldn't need more than the first 50,000 lines to see what going on.
[Bug tree-optimization/100494] [11/12 Regression] Unterminated recursion in gimple-range.cc (x86_64-w64-mingw32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100494 --- Comment #5 from J.M. Eubank --- Unfortunately it doesn't seem to have made a difference in this case. x86_64-w64-mingw32-gcc -c -DHAVE_CONFIG_H -O2 -g -D__USE_MINGW_ACCESS -I. -I/crossdev/src/binutils-git-2_36_1/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -Wshadow=local -ped make[3]: *** [Makefile:1260: sha1.o] Error 1 $ /c/crossdev/gccmaster/host-toolchain-cross4/bin/x86_64-w64-mingw32-gcc -v Using built-in specs. COLLECT_GCC=C:\crossdev\gccmaster\host-toolchain-cross4\bin\x86_64-w64-mingw32-gcc.exe COLLECT_LTO_WRAPPER=c:/crossdev/gccmaster/host-toolchain-cross4/bin/../libexec/gcc/x86_64-w64-mingw32/12.0.0/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../../../src/gcc-git-ecc5644fa3bc7f37eada2a3e9c627cd1918922e0/configure --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --enable-targets=all --target=x86_64-w64-mingw32 --prefix=/crossdev/prefix-cross2-x86_64-w64-mingw32 --enable-static --disable-shared --enable-languages=ada,c,c++ --disable-werror --with-gnu-ld --disable-nls --disable-win32-registry --disable-bootstrap --enable-sjlj-exceptions --enable-threads=posix Thread model: posix Supported LTO compression algorithms: zlib gcc version 12.0.0 20210614 (experimental) (GCC)
[Bug analyzer/101068] Analyzer does not purge constraints in loops (e.g. in explode-2.c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101068 --- Comment #1 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:954c9235297f2e63acacefd448bc5dabe039ea7c commit r12-1479-g954c9235297f2e63acacefd448bc5dabe039ea7c Author: David Malcolm Date: Tue Jun 15 09:29:23 2021 -0400 analyzer testsuite: add explode-2a.c [PR101068] Due to a bug (PR analyzer/101068), the analyzer only explores a limited subset of the possible paths through gcc.dg/analyzer/explode-2.c, and this artifically helps stop this testcase from exploding. I intend to fix this at some point, but for now, this patch adds a revised test case which captures the effective CFG due to the bug, so that we explicitly have test coverage for that CFG. gcc/testsuite/ChangeLog: PR analyzer/101068 * gcc.dg/analyzer/explode-2a.c: New test. Signed-off-by: David Malcolm
[Bug fortran/101079] New: [OPENMP] The value of list-item in linear clause in loop construct is not calculated on each iteration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101079 Bug ID: 101079 Summary: [OPENMP] The value of list-item in linear clause in loop construct is not calculated on each iteration Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: xiao@compiler-dev.com Target Milestone: --- The testcase is, program p use omp_lib integer :: i, j j = 0 !$omp parallel num_threads(2) !$omp do linear(j:1) schedule(static, 4) do i= 1, 10 print *, i, j, omp_get_thread_num() end do !$omp end parallel print *, "final j: ", j end program The result is, 1 0 0 2 0 0 3 0 0 4 0 0 9 8 0 10 8 0 5 4 1 6 4 1 7 4 1 8 4 1 final j:8 It looks like that the calculation for list-item 'j' is invoked after task dispatching not on each iteration. See OpenMP 4.5 specification, 2.15.3.7 "When a linear clause is specified on a construct, the value of the new list item on each iteration of the associated loop(s) corresponds to the value of the original list item before entering the construct plus the logical number of the iteration times linear-step. The value corresponding to the sequentially last iteration of the associated loop(s) is assigned to the original list item." The expected result seems to be that 'j' always equals (i-1), and final j equals 9.
[Bug tree-optimization/101061] tree-vrp misoptimization on skylake+ using union-based aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101061
--- Comment #4 from rguenther at suse dot de ---
On Tue, 15 Jun 2021, alexander.gr...@tu-dresden.de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101061
>
> --- Comment #3 from Alexander Grund ---
> You are right, it actually seems to be the combination of those to, so -O2
> -fno-strict-aliasing and -O2 -fno-tree-vrp both make it work.
>
> The layout-compatible refers to the "common initial sequence" that is allowed
> to be inspected for inactive union members, see the link.
We definitely do not implement the common initial sequence rule. Where
this manifests is when you for example have
struct X { int i; };
struct Y { int i; int j; } *a;
and access *(struct X *)a - thus when you do an access with an effective
type of the _aggregate_ that forms the common initial sequence. Accessing
the members via a pointer to their type works fine (here int *). Note
that ((struct X *)a)->i also constitutes an access of an object of
type X and thus is not implemented with the common initial sequence
rule in mind.
Note this is never going to change for GCC since this rule is not
well thought out (to name it politely ;)).
You can, as workaround use sth like
struct X { int i; } __attribute__((may_alias));
where the indirect accesses to type X will alias everything.
Or alternatively use type composition.
[Bug tree-optimization/101014] [12 Regression] Big compile time hog with -O3 since r12-1268-g9858cd1a6827ee7a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101014 Andrew Macleod changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Andrew Macleod --- I swear I put that text in and moved this to resolved... :-( sigh. sorry. Anyway, this does not appear to be an issue in GCC 11.. the effect appears to have been magnified by the new aggressive import/export calculation code in the GORI rework.
[Bug tree-optimization/101061] tree-vrp misoptimization on skylake+ using union-based aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101061 --- Comment #3 from Alexander Grund --- You are right, it actually seems to be the combination of those to, so -O2 -fno-strict-aliasing and -O2 -fno-tree-vrp both make it work. The layout-compatible refers to the "common initial sequence" that is allowed to be inspected for inactive union members, see the link. I also tested GCC 8.5.0 but there it is not fixed. (BTW: I checked the Github mirror which doesn't list 8.5.0) I'm aware that it is no longer supported but I too think that it is a latent bug or maybe just outright unsupported/UB > If you have ways to pinpoint the function where things go wrong then it might > be possible to spot a wrong transform there In the provided source the bug happens in this 2 lines: auto it = uniq.emplace(Tin(i), j); idx_vec(i) = it.first->second; Tin and idx_vec can be replaced by std::vector and std::vector respectively and the bug still occurs. However there are quite some abstractions especially in the first line including a conversion from their custom string type to their custom string_view I know it has got not main, because it is part of the tensorflow shared library loaded into the Python process and run from there. I wasn't able to reduce this further as mentioned as almost any change leads to this bug disappearing. I see that the tree-vrp has had many string-related changes which may handle their custom string better, see https://github.com/tensorflow/tensorflow/blob/c405c59212c764485818fad8b34294c0b553e6fb/tensorflow/core/platform/ctstring_internal.h#L118-L121 However they are dangerously close to UB in many places, e.g. https://github.com/tensorflow/tensorflow/blob/c405c59212c764485818fad8b34294c0b553e6fb/tensorflow/core/platform/ctstring_internal.h#L184-L186 (the code executed here) accesses an array of one union member and a variable of another. I'm also not sure if allocating a chunk of memory and in-place construction of an union containing a const member is actually allowed. I just want to know for sure, that either their code is non-compliant or there is a bug in the compiler. I can do experiments with the source but lack the knowledge to trace it through the compiler. See also my issue in the TF repo: https://github.com/tensorflow/tensorflow/issues/47179
[Bug c++/101078] [11/12 Regression] Rejected code since r12-1272-gf07edb5d7f3e7721
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101078 Martin Liška changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #1 from Martin Liška --- *** Bug 101077 has been marked as a duplicate of this bug. ***
[Bug c++/101077] [11/12 Regression] ceph build fails with access error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101077 Martin Liška changed: What|Removed |Added Resolution|--- |DUPLICATE CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #2 from Martin Liška --- Dup. *** This bug has been marked as a duplicate of bug 101078 ***
[Bug c++/100796] [11 Regression] GCC does not honor #pragma diagnostic ignored when using the integrated preprocessor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100796 --- Comment #6 from Giuseppe D'Angelo --- Hi, Wow, that was quick! I can't really judge the merit of the patch, but I've picked it on top of the GCC 11.1.0 tarball and can confirm that it seems to fix all the warnings for us. Thank you very much!
[Bug c++/101078] [11/12 Regression] Rejected code since r12-1272-gf07edb5d7f3e7721
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101078 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Priority|P3 |P1 Target Milestone|--- |11.2 Status|UNCONFIRMED |NEW Last reconfirmed||2021-06-15
[Bug c++/101078] New: [11/12 Regression] Rejected code since r12-1272-gf07edb5d7f3e7721
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101078
Bug ID: 101078
Summary: [11/12 Regression] Rejected code since
r12-1272-gf07edb5d7f3e7721
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: jason at gcc dot gnu.org
Target Milestone: ---
I noticed that in ceph package, note the patch was backported to 11 branch:
$ cat HttpClient.ii
namespace system {
struct error_code {};
} // namespace system
int async_initiate_token, operator0_handler2;
struct async_result {
template
static void initiate(Initiation initiation, RawCompletionToken token,
Args... args) {
initiation(token, args...);
}
};
template
void async_initiate(Initiation initiation, Args... args) {
async_result::initiate(initiation, async_initiate_token, args...);
}
using system::error_code;
struct stream_base {
using time_point = struct op_state { bool pending; };
struct pending_guard {
pending_guard(bool);
};
static time_point never();
};
template
struct basic_stream : private stream_base {
struct ops;
template
auto async_read_some(MutableBufferSequence const &, ReadHandler &&);
};
struct async_base {
template async_base(Handler_, int);
};
template
struct basic_stream::ops {
struct transfer_op : async_base {
pending_guard pg_;
op_state state();
template
transfer_op(Handler_, basic_stream, int)
: async_base(0, 0), pg_(state().pending) {
(*this)({});
}
void operator()(long) { never(); }
};
struct run_read_op {
template
void operator()(ReadHandler, basic_stream *s, Buffers b) {
transfer_op(0, *s, b);
}
};
};
template
template
auto basic_stream::async_read_some(
MutableBufferSequence const , ReadHandler &&) {
async_initiate(typename ops::run_read_op{}, this,
buffers);
}
template struct io_op {
io_op(Stream, int, Operation, Handler);
void operator()(error_code) { next_layer_.async_read_some(0, this); }
Stream next_layer_;
};
template
void async_io(Stream next_layer, int core, Operation op, Handler handler) {
io_op(next_layer, core, op, handler)(error_code());
}
struct stream {
void operator0() { async_io(next_layer_, core_, int(), operator0_handler2); }
basic_stream next_layer_;
int core_;
};
$ g++ HttpClient.ii -c -std=c++17
HttpClient.ii: In instantiation of ‘void basic_stream<
, ,
>::ops::transfer_op::operator()(long int) [with Protocol = int; Executor = int;
RatePolicy = int]’:
HttpClient.ii:41:14: required from ‘basic_stream< ,
,
>::ops::transfer_op::transfer_op(Handler_, basic_stream<
, , >,
int) [with Handler_ = int; Protocol = int; Executor = int; RatePolicy = int;
basic_stream< , ,
> = basic_stream]’
HttpClient.ii:48:7: required from ‘void basic_stream<
, ,
>::ops::run_read_op::operator()(ReadHandler, basic_stream<
, ,
>*, Buffers) [with ReadHandler = int; Buffers = int; Protocol = int; Executor =
int; RatePolicy = int]’
HttpClient.ii:9:15: required from ‘static void
async_result::initiate(Initiation, RawCompletionToken, Args ...) [with
Initiation = basic_stream::ops::run_read_op; RawCompletionToken = int;
Args = {basic_stream*, int}]’
HttpClient.ii:14:25: required from ‘void async_initiate(Initiation, Args ...)
[with = io_op, int, int>*;
= void; Initiation =
basic_stream::ops::run_read_op; Args = {basic_stream*,
int}]’
HttpClient.ii:56:36: required from ‘auto basic_stream<
, ,
>::async_read_some(const MutableBufferSequence&, ReadHandler&&) [with
MutableBufferSequence = int; ReadHandler = io_op, int, int>*;
= int; = int;
= int]’
HttpClient.ii:60:60: required from ‘void io_op::operator()(system::error_code) [with Stream = basic_stream;
Operation = int; Handler = int]’
HttpClient.ii:65:39: required from ‘void async_io(Stream, int, Operation,
Handler) [with Stream = basic_stream; Operation = int; Handler = int]’
HttpClient.ii:68:30: required from here
HttpClient.ii:43:34: error: ‘static stream_base::time_point
stream_base::never()’ is inaccessible within this context
43 | void operator()(long) { never(); }
| ~^~
HttpClient.ii:22:21: note: declared here
22 | static time_point never();
| ^
[Bug c++/101077] [11/12 Regression] ceph build fails with access error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101077 --- Comment #1 from Richard Biener --- OK, xz compressed preprocessed source is too large to attach. Will reduce later.
[Bug c++/101077] [11/12 Regression] ceph build fails with access error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101077 Richard Biener changed: What|Removed |Added Summary|ceph build fails with |[11/12 Regression] ceph |access error|build fails with access ||error Target Milestone|--- |11.2 Keywords||rejects-valid
[Bug c++/101077] New: ceph build fails with access error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101077 Bug ID: 101077 Summary: ceph build fails with access error Product: gcc Version: 11.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- /usr/bin/c++ -DBOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION -DHAVE_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_REENTRANT -D_THREAD_SAFE -D__CEPH__ -D__STDC_FORMAT_MACROS -D__linux__ -I/home/abuild/rpmbuild/BUILD/ceph-16.2.4-26-g555d38aa5a5/build/src/include -I/home/abuild/rpmbuild/BUILD/ceph-16.2.4-26-g555d38aa5a5/src -isystem /home/abuild/rpmbuild/BUILD/ceph-16.2.4-26-g555d38aa5a5/build/boost/include -isystem /home/abuild/rpmbuild/BUILD/ceph-16.2.4-26-g555d38aa5a5/build/include -isystem /home/abuild/rpmbuild/BUILD/ceph-16.2.4-26-g555d38aa5a5/src/xxHash -isystem /home/abuild/rpmbuild/BUILD/ceph-16.2.4-26-g555d38aa5a5/src/rapidjson/include -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -g --param ggc-min-expand=20 --param ggc-min-heapsize=32768 -O2 -g -DNDEBUG -fPIC -U_FORTIFY_SOURCE -Wall -fno-strict-aliasing -fsigned-char -Wtype-limits -Wignored-qualifiers -Wpointer-arith -Werror=format-security -Winit-self -Wno-unknown-pragmas -Wnon-virtual-dtor -Wno-ignored-qualifiers -ftemplate-depth-1024 -Wpessimizing-move -Wredundant-move -Wstrict-null-sentinel -Woverloaded-virtual -fno-new-ttp-matching -fstack-protector-strong -fdiagnostics-color=auto -fno-builtin-malloc -fno-builtin-calloc -fno-builtin-realloc -fno-builtin-free -std=c++17 -MD -MT src/librbd/CMakeFiles/rbd_internal.dir/migration/HttpClient.cc.o -MF CMakeFiles/rbd_internal.dir/migration/HttpClient.cc.o.d -o CMakeFiles/rbd_internal.dir/migration/HttpClient.cc.o -c /home/abuild/rpmbuild/BUILD/ceph-16.2.4-26-g555d38aa5a5/src/librbd/migration/HttpClient.cc ... build/boost/include/boost/beast/core/impl/basic_stream.hpp:311:47: error: 'static boost::beast::detail::stream_base::time_point boost::beast::detail::stream_base::never()' is inaccessible within this context 311 | if(state().timer.expiry() != never()) | ~^~ ... works fine with g++ (GCC) 11.1.1 20210428
[Bug target/101046] ICE: in gen_rtx_CONST_VECTOR, at emit-rtl.c:6031 with -mavx512vbmi -mavx512vl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101046 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |12.0
[Bug target/101046] ICE: in gen_rtx_CONST_VECTOR, at emit-rtl.c:6031 with -mavx512vbmi -mavx512vl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101046 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug target/100866] PPC: Inefficient code for vec_revb(vector unsigned short) < P9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100866
--- Comment #3 from luoxhu at gcc dot gnu.org ---
diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md
index 097a127be07..35b3f1a0e1a 100644
--- a/gcc/config/rs6000/altivec.md
+++ b/gcc/config/rs6000/altivec.md
@@ -1932,7 +1932,7 @@ (define_insn "altivec_vpkuum_direct"
}
[(set_attr "type" "vecperm")])
-(define_insn "*altivec_vrl"
+(define_insn "altivec_vrl"
[(set (match_operand:VI2 0 "register_operand" "=v")
(rotate:VI2 (match_operand:VI2 1 "register_operand" "v")
(match_operand:VI2 2 "register_operand" "v")))]
diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md
index 8c5865b8c34..88b34a2285a 100644
--- a/gcc/config/rs6000/vsx.md
+++ b/gcc/config/rs6000/vsx.md
@@ -5849,9 +5849,18 @@ (define_expand "revb_"
/* Want to have the elements in reverse order relative
to the endian mode in use, i.e. in LE mode, put elements
in BE order. */
- rtx sel = swap_endian_selector_for_mode(mode);
- emit_insn (gen_altivec_vperm_ (operands[0], operands[1],
- operands[1], sel));
+ if (mode == V8HImode)
+ {
+ rtx splt = gen_reg_rtx (V8HImode);
+ emit_insn (gen_altivec_vspltish (splt, GEN_INT (8)));
+ emit_insn (gen_altivec_vrlh (operands[0], operands[1], splt));
+ }
+ else
+ {
+ rtx sel = swap_endian_selector_for_mode ( mode);
+ emit_insn (gen_altivec_vperm_ (operands[0], operands[1],
+ operands[1], sel));
+ }
}
With above change, it could generate the expected code:
revb:
.LFB0:
.cfi_startproc
vspltisw 0,8
vrlw 2,2,0
blr
[Bug target/101046] ICE: in gen_rtx_CONST_VECTOR, at emit-rtl.c:6031 with -mavx512vbmi -mavx512vl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101046 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:008153c8435ca3bf587e11654c31f05c0f99b43a commit r12-1448-g008153c8435ca3bf587e11654c31f05c0f99b43a Author: Jakub Jelinek Date: Tue Jun 15 11:36:47 2021 +0200 expr: Fix up VEC_PACK_TRUNC_EXPR expansion [PR101046] The following testcase ICEs, because we have a mode mismatch. VEC_PACK_TRUNC_EXPR's operands have different modes from the result (same vector mode size but twice as large element), but we were passing non-NULL subtarget with the mode of the result to the expansion of its arguments, so the VEC_PERM_EXPR in one of the operands which had V8SImode operands and result had V16HImode target. Fixed by clearing the subtarget if we are changing mode. 2021-06-15 Jakub Jelinek PR target/101046 * expr.c (expand_expr_real_2) : Clear subtarget when changing mode. * gcc.target/i386/pr101046.c: New test.
[Bug target/100866] PPC: Inefficient code for vec_revb(vector unsigned short) < P9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100866
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
CC||luoxhu at gcc dot gnu.org
--- Comment #2 from luoxhu at gcc dot gnu.org ---
But it only works for V8HImode, no better code generation for other modes like
V4SI/V2DI/V1TI to do byte swap with only two instructions vspltish+vrlh?
unsigned int swap1[16] = {15,14,13,12,11,10,9,8,7,6,5,4,3,2,1,0};
unsigned int swap2[16] = {7,6,5,4,3,2,1,0,15,14,13,12,11,10,9,8};
unsigned int swap4[16] = {3,2,1,0,7,6,5,4,11,10,9,8,15,14,13,12};
unsigned int swap8[16] = {1,0,3,2,5,4,7,6,9,8,11,10,13,12,15,14};
For example V4SI, need swap short first, then swap word, it seems not so
straight forward than vperm?
[Bug middle-end/101062] [10/11/12 Regression] wrong code with "-O2 -fno-toplevel-reorder -frename-registers"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101062 --- Comment #11 from Richard Biener --- (In reply to Jakub Jelinek from comment #10) > Created attachment 51023 [details] > gcc12-pr101062.patch > > Untested fix for this in stor-layout.c. LGTM
[Bug middle-end/101062] [10/11/12 Regression] wrong code with "-O2 -fno-toplevel-reorder -frename-registers"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101062 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #10 from Jakub Jelinek --- Created attachment 51023 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51023=edit gcc12-pr101062.patch Untested fix for this in stor-layout.c.
[Bug middle-end/101062] [10/11/12 Regression] wrong code with "-O2 -fno-toplevel-reorder -frename-registers"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101062
--- Comment #9 from rguenther at suse dot de ---
On Tue, 15 Jun 2021, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101062
>
> --- Comment #8 from Jakub Jelinek ---
> (In reply to Richard Biener from comment #7)
> > Now, it looks to me this is rather an issue that the access is larger than
> > the object and thus a general bug - at least I don't see how it should only
> > manifest with bitfields in unions?
> >
> > Note we do
> >
> > if (TREE_CODE (to) == COMPONENT_REF
> > && DECL_BIT_FIELD_TYPE (TREE_OPERAND (to, 1)))
> > get_bit_range (_start, _end, to, ,
> > );
> > /* The C++ memory model naturally applies to byte-aligned fields.
> > However, if we do not have a DECL_BIT_FIELD_TYPE but BITPOS or
> > BITSIZE are not byte-aligned, there is no need to limit the range
> > we can access. This can occur with packed structures in Ada. */
> > else if (maybe_gt (bitsize, 0)
> >&& multiple_p (bitsize, BITS_PER_UNIT)
> >&& multiple_p (bitpos, BITS_PER_UNIT))
> > {
> > bitregion_start = bitpos;
> > bitregion_end = bitpos + bitsize - 1;
> > }
> >
> > but if we assume that for DECL_BIT_FIELD_TYPE there's a representative
> > then we miss the else if, so - maybe get_bit_range should return whether
> > it handled things or the else if part should be done unconditionally
> > in case bitregion_start/end is not {0,0}?
>
> This wouldn't help us, bitsize is > 0, but not a multiple of BITS_PER_UNIT in
> this case. Furthermore, even if we add there bitregion_start/end for the base
> variable if any as further fallthrough, I think most C/C++ programmers will
> expect that with
> union U { int a; int b : 5; } u[64];
> u[4].b = 1; can be done safely in one thread and
> u[5].a = 2; in another one.
>
> My patch fixes that (or another possibility would be to compute the
> representative even in UNION_TYPE (no idea about QUAL_UNION_TYPE) - could be
> as
> simple as removing the early out and instead of doing prev = field; in the
> loop
> do if (TREE_CODE (t) != RECORD_TYPE) { finish_bitfield_representative (repr,
> field); repr = NULL_TREE; } else prev = field; and in
> finish_bitfield_representative override nextf to NULL_TREE).
Yes, as said - the caller of get_bit_range seems to expect it to always
handle cases that do not run into the byte-align case to make sure to
not cross to next objects. I don't remember why I didn't handle
UNION_TYPE (I guess because it was about bitfield groups, not single
bitfields), so maybe we should indeed handle them.
There are also other callers of get_bit_range it seems, even on
!DECL_BIT_FIELD_TYPE fields.
So let's try handling [QUAL_]UNION_TYPE in finish_bitfield_layout?
[Bug tree-optimization/83129] calloc zero initialization is not taken into account by gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83129 --- Comment #3 from Richard Biener --- Created attachment 51022 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51022=edit other ineffective prototype
[Bug tree-optimization/83129] calloc zero initialization is not taken into account by gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83129 Richard Biener changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #2 from Richard Biener --- *** Bug 101074 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/101074] calloc result not treated as zeroed out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101074 Richard Biener changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from Richard Biener --- dup *** This bug has been marked as a duplicate of bug 83129 ***
[Bug tree-optimization/101074] calloc result not treated as zeroed out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101074 --- Comment #2 from Richard Biener --- Created attachment 51021 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51021=edit prototype patch for VN ineffective prototype patch
[Bug tree-optimization/101074] calloc result not treated as zeroed out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101074 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Keywords||missed-optimization Last reconfirmed||2021-06-15 CC||rguenth at gcc dot gnu.org --- Comment #1 from Richard Biener --- Confirmed. value-numbering knows about memset but not calloc, adding calloc support isn't hard but requires quite some boiler-plate code (there might already be a bug about this). Note that currently calloc() is not considered having a side-effect besides the allocation at all (that can't really cause any issue), so we do not consider it a possible definition of p->i. This allows better disambiguation at the expense of this missed optimization (which in turn is an implementation detail missed optimization).
[Bug tree-optimization/101062] [10/11/12 Regression] wrong code with "-O2 -fno-toplevel-reorder -frename-registers"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101062
--- Comment #8 from Jakub Jelinek ---
(In reply to Richard Biener from comment #7)
> Now, it looks to me this is rather an issue that the access is larger than
> the object and thus a general bug - at least I don't see how it should only
> manifest with bitfields in unions?
>
> Note we do
>
> if (TREE_CODE (to) == COMPONENT_REF
> && DECL_BIT_FIELD_TYPE (TREE_OPERAND (to, 1)))
> get_bit_range (_start, _end, to, ,
> );
> /* The C++ memory model naturally applies to byte-aligned fields.
> However, if we do not have a DECL_BIT_FIELD_TYPE but BITPOS or
> BITSIZE are not byte-aligned, there is no need to limit the range
> we can access. This can occur with packed structures in Ada. */
> else if (maybe_gt (bitsize, 0)
>&& multiple_p (bitsize, BITS_PER_UNIT)
>&& multiple_p (bitpos, BITS_PER_UNIT))
> {
> bitregion_start = bitpos;
> bitregion_end = bitpos + bitsize - 1;
> }
>
> but if we assume that for DECL_BIT_FIELD_TYPE there's a representative
> then we miss the else if, so - maybe get_bit_range should return whether
> it handled things or the else if part should be done unconditionally
> in case bitregion_start/end is not {0,0}?
This wouldn't help us, bitsize is > 0, but not a multiple of BITS_PER_UNIT in
this case. Furthermore, even if we add there bitregion_start/end for the base
variable if any as further fallthrough, I think most C/C++ programmers will
expect that with
union U { int a; int b : 5; } u[64];
u[4].b = 1; can be done safely in one thread and
u[5].a = 2; in another one.
My patch fixes that (or another possibility would be to compute the
representative even in UNION_TYPE (no idea about QUAL_UNION_TYPE) - could be as
simple as removing the early out and instead of doing prev = field; in the loop
do if (TREE_CODE (t) != RECORD_TYPE) { finish_bitfield_representative (repr,
field); repr = NULL_TREE; } else prev = field; and in
finish_bitfield_representative override nextf to NULL_TREE).
Improving expand_assignment can be done too, sure, but independently to this.
[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212 Stefan Schulze Frielinghaus changed: What|Removed |Added CC||stefansf at linux dot ibm.com --- Comment #17 from Stefan Schulze Frielinghaus --- The new testcases introduced by commit d3b1ef7a83c fail on IBM Z as well as some older data-model tests: +FAIL: gcc.dg/analyzer/bitfields-1.c (test for warnings, line 113) +FAIL: gcc.dg/analyzer/bitfields-1.c (test for warnings, line 115) +FAIL: gcc.dg/analyzer/bitfields-1.c (test for warnings, line 117) +FAIL: gcc.dg/analyzer/bitfields-1.c (test for warnings, line 119) +FAIL: gcc.dg/analyzer/bitfields-1.c (test for warnings, line 121) +FAIL: gcc.dg/analyzer/bitfields-1.c (test for warnings, line 123) +FAIL: gcc.dg/analyzer/bitfields-1.c (test for warnings, line 125) +FAIL: gcc.dg/analyzer/bitfields-1.c (test for warnings, line 127) +FAIL: gcc.dg/analyzer/bitfields-1.c (test for warnings, line 24) +FAIL: gcc.dg/analyzer/bitfields-1.c (test for warnings, line 26) +FAIL: gcc.dg/analyzer/bitfields-1.c (test for warnings, line 29) +FAIL: gcc.dg/analyzer/bitfields-1.c (test for warnings, line 31) +FAIL: gcc.dg/analyzer/bitfields-1.c (test for warnings, line 36) +FAIL: gcc.dg/analyzer/bitfields-1.c (test for warnings, line 41) +FAIL: gcc.dg/analyzer/bitfields-1.c (test for warnings, line 81) +FAIL: gcc.dg/analyzer/bitfields-1.c (test for warnings, line 83) +FAIL: gcc.dg/analyzer/bitfields-1.c (test for warnings, line 85) +FAIL: gcc.dg/analyzer/bitfields-1.c (test for warnings, line 87) +FAIL: gcc.dg/analyzer/bitfields-1.c (test for warnings, line 92) +FAIL: gcc.dg/analyzer/bitfields-1.c (test for warnings, line 94) +FAIL: gcc.dg/analyzer/bitfields-1.c (test for warnings, line 96) +FAIL: gcc.dg/analyzer/bitfields-1.c (test for excess errors) +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 947) +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 950) +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 965) +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 968) +FAIL: gcc.dg/analyzer/data-model-1.c (test for excess errors) The actual warning for those failing tests is "UNKNOWN".
[Bug c++/101073] [9/10/11/12 Regression] ICE in cxx_eval_constant_expression, at cp/constexpr.c:6941
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101073 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.5
[Bug c++/101072] [11/12 Regression] ICE in build_target_expr_with_type, at cp/tree.c:845 since r11-5681-gd9288bd28e24c755
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101072 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |11.2
[Bug tree-optimization/101066] [10/11/12 Regression] Wrong code after fixup_cfg3 since r10-3311-gff6686d2e5f797d6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101066 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/101062] [10/11/12 Regression] wrong code with "-O2 -fno-toplevel-reorder -frename-registers"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101062
--- Comment #7 from Richard Biener ---
(In reply to Eric Botcazou from comment #6)
> > Does Ada allow bitfields in unions and if yes, what does it want for those?
>
> Yes, it does, and I don't think there is any specific need so the default
> should be OK like for structures.
I also think since there's at most a single active union member the default
should work.
Now, it looks to me this is rather an issue that the access is larger than
the object and thus a general bug - at least I don't see how it should only
manifest with bitfields in unions?
Note we do
if (TREE_CODE (to) == COMPONENT_REF
&& DECL_BIT_FIELD_TYPE (TREE_OPERAND (to, 1)))
get_bit_range (_start, _end, to, , );
/* The C++ memory model naturally applies to byte-aligned fields.
However, if we do not have a DECL_BIT_FIELD_TYPE but BITPOS or
BITSIZE are not byte-aligned, there is no need to limit the range
we can access. This can occur with packed structures in Ada. */
else if (maybe_gt (bitsize, 0)
&& multiple_p (bitsize, BITS_PER_UNIT)
&& multiple_p (bitpos, BITS_PER_UNIT))
{
bitregion_start = bitpos;
bitregion_end = bitpos + bitsize - 1;
}
but if we assume that for DECL_BIT_FIELD_TYPE there's a representative
then we miss the else if, so - maybe get_bit_range should return whether
it handled things or the else if part should be done unconditionally
in case bitregion_start/end is not {0,0}?
[Bug tree-optimization/101061] tree-vrp misoptimization on skylake+ using union-based aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101061 --- Comment #2 from Richard Biener --- If it is related to those union accesses then it should have nothing to do with -ftree-vrp but it should vanish with -O2 -fno-strict-aliasing at least. Note we do not implement any of "layout compatible" (whatever that exactly is) for union members but if the difference is really just 'const T' vs. 'T' then this should work. Also note that GCC 8 is no longer supported and there's a newer 8.5.0 release available as well. It looks like the bug requires quite special circumstances to happen thus it's likely just gone latent with newer compilers and/or different flags. Unfortunately the preprocessed source lacks a main() and thus it's hard to determine whether the bug occurs or not. If you have ways to pinpoint the function where things go wrong then it might be possible to spot a wrong transform there (but a C++ code base is always hard to analyze because of all the inlining and abstraction that happens).
[Bug c++/101072] [11/12 Regression] ICE in build_target_expr_with_type, at cp/tree.c:845 since r11-5681-gd9288bd28e24c755
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101072 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-06-15 Summary|[11/12 Regression] ICE in |[11/12 Regression] ICE in |build_target_expr_with_type |build_target_expr_with_type |, at cp/tree.c:845 |, at cp/tree.c:845 since ||r11-5681-gd9288bd28e24c755 Ever confirmed|0 |1 CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Started with r11-5681-gd9288bd28e24c755.
[Bug tree-optimization/101066] [10/11/12 Regression] Wrong code after fixup_cfg3 since r10-3311-gff6686d2e5f797d6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101066 Martin Liška changed: What|Removed |Added Summary|Wrong code after fixup_cfg3 |[10/11/12 Regression] Wrong ||code after fixup_cfg3 since ||r10-3311-gff6686d2e5f797d6 Ever confirmed|0 |1 Target Milestone|--- |10.4 CC||jamborm at gcc dot gnu.org, ||marxin at gcc dot gnu.org Last reconfirmed||2021-06-15 Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- Confirmed, started with r10-3311-gff6686d2e5f797d6.
[Bug rtl-optimization/101076] RTL Combine pass won't generate sign_extnd RTX in some senario
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101076 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=98981 --- Comment #5 from Andrew Pinski --- I suspect it is similar to the reason why there is an extra move in PR 98981
[Bug c++/101065] "internal compiler error: Segmentation fault signal terminated program cc1plus" when compiling some malformed code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101065 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Last reconfirmed||2021-06-15 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- Confirmed, an old issue.
[Bug rtl-optimization/101076] RTL Combine pass won't generate sign_extnd RTX in some senario
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101076 --- Comment #4 from Coco Wang --- (In reply to Andrew Pinski from comment #3) > This sounds like a rsicv backend issue really ... I think the key is the subreg, the reason why x86_64 and aarch64 have no problems is that subreg does not appear in RTL. The code of this part is not right if (!OBJECT_P (lhs) && ! (GET_CODE (lhs) == SUBREG && (OBJECT_P (SUBREG_REG (lhs && CONST_INT_P (rhs) && INTVAL (rhs) >= 0 && INTVAL (rhs) < HOST_BITS_PER_WIDE_INT && INTVAL (rhs) < mode_width && (new_rtx = extract_left_shift (mode, lhs, INTVAL (rhs))) != 0) new_rtx = make_extraction (mode, make_compound_operation (new_rtx, next_code), 0, NULL_RTX, mode_width - INTVAL (rhs), code == LSHIFTRT, 0, in_code == COMPARE);
[Bug tree-optimization/101014] [12 Regression] Big compile time hog with -O3 since r12-1268-g9858cd1a6827ee7a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101014 --- Comment #5 from Martin Liška --- Should be fixed with: commit ecc5644fa3bc7f37eada2a3e9c627cd1918922e0 Author: Andrew MacLeod Date: Mon Jun 14 15:33:59 2021 -0400 Limit new value calculations to first order effects. When utilzing poor values during propagation, we mostly care about values that were undefined/processed directly used in calcualting the SSA_NAME being processed. 2nd level derivations of such poor values rarely affect the inital calculation. Leave them to when they are directly encountered. * gimple-range-cache.cc (ranger_cache::ranger_cache): Adjust. (ranger_cache::enable_new_values): Set to specified value and return the old value. (ranger_cache::disable_new_values): Delete. (ranger_cache::fill_block_cache): Disable non 1st order derived poor values. * gimple-range-cache.h (ranger_cache): Adjust prototypes. * gimple-range.cc (gimple_ranger::range_of_expr): Adjust.
[Bug rtl-optimization/101076] RTL Combine pass won't generate sign_extnd RTX in some senario
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101076 Andrew Pinski changed: What|Removed |Added Status|WAITING |UNCONFIRMED Target||riscv Keywords||missed-optimization Ever confirmed|1 |0 --- Comment #3 from Andrew Pinski --- This sounds like a rsicv backend issue really ...
[Bug rtl-optimization/101076] RTL Combine pass won't generate sign_extnd RTX in some senario
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101076
--- Comment #2 from Coco Wang ---
(In reply to Andrew Pinski from comment #1)
> What target is this for?
> For both x86_64 and aarch64 we have both shifts in SI mode so we don't end
> up with problem.
> We get the following RTL for aarch64 (before combine):
> (insn 6 3 7 2 (set (reg:SI 96)
> (ashift:SI (reg/v:SI 94 [ a ])
> (const_int 16 [0x10]))) "t551.c":3:15 692
> {*aarch64_ashl_sisd_or_int_si3}
> (expr_list:REG_DEAD (reg/v:SI 94 [ a ])
> (nil)))
> (insn 7 6 12 2 (set (reg:SI 95)
> (ashiftrt:SI (reg:SI 96)
> (const_int 16 [0x10]))) "t551.c":3:22 696
> {*aarch64_ashr_sisd_or_int_si3}
> (expr_list:REG_DEAD (reg:SI 96)
> (nil)))
>
> And then we get:
> Trying 6 -> 7:
> 6: r96:SI=r97:SI<<0x10
> REG_DEAD r97:SI
> 7: r95:SI=r96:SI>>0x10
> REG_DEAD r96:SI
> Successfully matched this instruction:
> (set (reg:SI 95)
> (sign_extend:SI (subreg:HI (reg:SI 97) 0)))
> In combine.
>
>
> I Noticed you have:
> r76:SI=r78:DI#0<<0x10
> 7: r75:SI=r76:SI>>0x10
>
> In combine, so you have a subreg of r78, where is the subreg produced ...
The target is RISCV64, I will check the reason why there is a subreg produced.
[Bug rtl-optimization/3507] appalling optimisation with sub/cmp on multiple targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3507
Ivan Sorokin changed:
What|Removed |Added
CC||vanyacpp at gmail dot com
--- Comment #60 from Ivan Sorokin ---
Another similar case. On this function:
unsigned wrap(unsigned index, unsigned limit)
{
if (index >= limit)
index -= limit;
return index;
}
GCC 11.1 -O2 generates:
wrap(unsigned int, unsigned int):
mov edx, edi
mov eax, edi
sub edx, esi
cmp edi, esi
cmovnb eax, edx
ret
I believe cmp here is redundant as the flags are already set after sub. After
removing cmp we get:
wrap(unsigned int, unsigned int):
mov edx, edi
mov eax, edi
sub edx, esi
cmovnb eax, edx
ret
Now the register edx becomes unneeded:
wrap(unsigned int, unsigned int):
mov eax, edi
sub edi, esi
cmovnb eax, edi
ret
[Bug rtl-optimization/101076] RTL Combine pass won't generate sign_extnd RTX in some senario
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101076
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-06-15
Ever confirmed|0 |1
Status|UNCONFIRMED |WAITING
--- Comment #1 from Andrew Pinski ---
What target is this for?
For both x86_64 and aarch64 we have both shifts in SI mode so we don't end up
with problem.
We get the following RTL for aarch64 (before combine):
(insn 6 3 7 2 (set (reg:SI 96)
(ashift:SI (reg/v:SI 94 [ a ])
(const_int 16 [0x10]))) "t551.c":3:15 692
{*aarch64_ashl_sisd_or_int_si3}
(expr_list:REG_DEAD (reg/v:SI 94 [ a ])
(nil)))
(insn 7 6 12 2 (set (reg:SI 95)
(ashiftrt:SI (reg:SI 96)
(const_int 16 [0x10]))) "t551.c":3:22 696
{*aarch64_ashr_sisd_or_int_si3}
(expr_list:REG_DEAD (reg:SI 96)
(nil)))
And then we get:
Trying 6 -> 7:
6: r96:SI=r97:SI<<0x10
REG_DEAD r97:SI
7: r95:SI=r96:SI>>0x10
REG_DEAD r96:SI
Successfully matched this instruction:
(set (reg:SI 95)
(sign_extend:SI (subreg:HI (reg:SI 97) 0)))
In combine.
I Noticed you have:
r76:SI=r78:DI#0<<0x10
7: r75:SI=r76:SI>>0x10
In combine, so you have a subreg of r78, where is the subreg produced ...
