[Bug fortran/93736] Add .f18 and .F18 file suffixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93736 --- Comment #7 from Thomas Henlich --- This should have a test-case added, ideally by renaming an already existing test-case containing Fortran 2018 features to .f18.
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 --- Comment #17 from Thomas Henlich --- The following should give an error message, not a ICE: program test_dtrig2 real, parameter :: d = asind(1.1) print *, d end gfortran -fdec-math test_dtrig2.f90 f951.exe: internal compiler error: Segmentation fault ... program test_dtrig2 real, parameter :: d = asin(1.1) print *, d end test_dtrig2.f90:2:30: 2 | real, parameter :: d = asin(1.1) | 1 Error: Argument of ASIN at (1) must be between -1 and 1
[Bug analyzer/93899] New: ICE in make_region_for_type, at analyzer/region-model.cc:6094
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93899 Bug ID: 93899 Summary: ICE in make_region_for_type, at analyzer/region-model.cc:6094 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- g++-10.0.1-alpha20200223 snapshot (g:3133bed5d0327e8a9cd0a601b7ecdb9de4fc825d) ICEs when compiling gcc/testsuite/g++.dg/abi/mangle55.C w/ -fanalyzer: % g++-10.0.1 -fanalyzer -c gcc/testsuite/g++.dg/abi/mangle55.C during IPA pass: analyzer gcc/testsuite/g++.dg/abi/mangle55.C:14:1: internal compiler error: in make_region_for_type, at analyzer/region-model.cc:6094 14 | } | ^ 0x7dbad7 make_region_for_type /var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/analyzer/region-model.cc:6094 0x135b49c ana::region_model::add_region_for_type(ana::region_id, tree_node*) /var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/analyzer/region-model.cc:6104 0x135b49c ana::map_region::get_or_create(ana::region_model*, ana::region_id, tree_node*, tree_node*) /var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/analyzer/region-model.cc:1676 0x135b9b1 ana::root_region::push_frame(ana::region_model*, function*, vec*, ana::region_model_context*) /var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/analyzer/region-model.cc:2920 0x133ba07 ana::exploded_graph::add_function_entry(function*) /var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/analyzer/engine.cc:1832 0x133bd32 ana::exploded_graph::build_initial_worklist() /var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/analyzer/engine.cc:2151 0x133e5ec ana::impl_run_checkers(ana::logger*) /var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/analyzer/engine.cc:3667 0x133f09c ana::run_checkers() /var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/analyzer/engine.cc:3727 0x13347d8 execute /var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/analyzer/analyzer-pass.cc:84
[Bug driver/47785] GCC with -flto does not pass -Wa/-Xassembler options to the assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47785 --- Comment #17 from CVS Commits --- The master branch has been updated by Prathamesh Kulkarni : https://gcc.gnu.org/g:f1a681a174cdfb82e62c246d6f4add9a25fc2e43 commit r10-6807-gf1a681a174cdfb82e62c246d6f4add9a25fc2e43 Author: Prathamesh Kulkarni Date: Mon Feb 24 11:55:45 2020 +0530 PR47785: Add support for handling Xassembler/Wa options with LTO. 2020-02-24 Prathamesh Kulkarni Kugan Vivekandarajah PR driver/47785 * gcc.c (putenv_COLLECT_AS_OPTIONS): New function. (driver::main): Call putenv_COLLECT_AS_OPTIONS. * opts-common.c (parse_options_from_collect_gcc_options): New function. (prepend_xassembler_to_collect_as_options): Likewise. * opts.h (parse_options_from_collect_gcc_options): Declare prototype. (prepend_xassembler_to_collect_as_options): Likewise. * lto-opts.c (lto_write_options): Stream assembler options in COLLECT_AS_OPTIONS. * lto-wrapper.c (xassembler_options_error): New static variable. (get_options_from_collect_gcc_options): Move parsing options code to parse_options_from_collect_gcc_options and call it. (merge_and_complain): Validate -Xassembler options. (append_compiler_options): Handle OPT_Xassembler. (run_gcc): Append command line -Xassembler options to collect_gcc_options. * doc/invoke.texi: Add documentation about using Xassembler options with LTO. testsuite/ * gcc.target/arm/pr78353-1.c: New test. * gcc.target/arm/pr78353-2.c: Likewise.
[Bug target/93658] [9/10 Regression] infinite loop building ghostscript and icu with -O3 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93658 Peter Bergner changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #16 from Peter Bergner --- Fixed everywhere.
[Bug target/93658] [9/10 Regression] infinite loop building ghostscript and icu with -O3 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93658 --- Comment #15 from CVS Commits --- The releases/gcc-8 branch has been updated by Peter Bergner : https://gcc.gnu.org/g:53efbfe030a5fda41e5e7856d76ea827dd09f49c commit r8-10050-g53efbfe030a5fda41e5e7856d76ea827dd09f49c Author: Peter Bergner Date: Sun Feb 23 22:04:44 2020 -0600 rs6000: Fix infinite loop building ghostscript and icu [PR93658] Fix rs6000_legitimate_address_p(), which erroneously marks a valid Altivec address as being invalid, which causes LRA's process_address() to go into an infinite loop spilling the same address over and over again. Include Mike's earlier commits that fix bugs this patch exposes. Backport from master 2020-02-20 Peter Bergner PR target/93658 * config/rs6000/rs6000.c (rs6000_legitimate_address_p): Handle VSX vector modes. * gcc.target/powerpc/pr93658.c: New test. * gcc.target/powerpc/vsx-vector-6-le.c: Update fragile insn count.
[Bug target/93568] [10 regression] r10-6418 causes many ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93568 --- Comment #5 from CVS Commits --- The releases/gcc-8 branch has been updated by Peter Bergner : https://gcc.gnu.org/g:e88c006ab2b919913fcdb5a5d9db147f372cd156 commit r8-10049-ge88c006ab2b919913fcdb5a5d9db147f372cd156 Author: Michael Meissner Date: Sun Feb 23 21:57:11 2020 -0600 Adjust how variable vector extraction is done. Backport from master 2020-02-03 Michael Meissner * config/rs6000/rs6000.c (get_vector_offset): New helper function to calculate the offset in memory from the start of a vector of a particular element. Add code to keep the element number in bounds if the element number is variable. (rs6000_adjust_vec_address): Move calculation of offset of the vector element to get_vector_offset. (rs6000_split_vec_extract_var): Do not do the initial AND of element here, move the code to get_vector_offset. Fix PR 93568 (thinko) Backport from master 2020-02-05 Michael Meissner PR target/93568 * config/rs6000/rs6000.c (get_vector_offset): Fix Q constraint assert to use MEM.
[Bug target/93568] [10 regression] r10-6418 causes many ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93568 --- Comment #4 from CVS Commits --- The releases/gcc-9 branch has been updated by Peter Bergner : https://gcc.gnu.org/g:428a4feef8594142e5324c0f5cfc8281e43bf75a commit r9-8268-g428a4feef8594142e5324c0f5cfc8281e43bf75a Author: Michael Meissner Date: Sun Feb 23 18:17:12 2020 -0600 Adjust how variable vector extraction is done. Backport from master 2020-02-03 Michael Meissner * config/rs6000/rs6000.c (get_vector_offset): New helper function to calculate the offset in memory from the start of a vector of a particular element. Add code to keep the element number in bounds if the element number is variable. (rs6000_adjust_vec_address): Move calculation of offset of the vector element to get_vector_offset. (rs6000_split_vec_extract_var): Do not do the initial AND of element here, move the code to get_vector_offset. Fix PR 93568 (thinko) Backport from master 2020-02-05 Michael Meissner PR target/93568 * config/rs6000/rs6000.c (get_vector_offset): Fix Q constraint assert to use MEM.
[Bug target/93658] [9/10 Regression] infinite loop building ghostscript and icu with -O3 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93658 --- Comment #14 from CVS Commits --- The releases/gcc-9 branch has been updated by Peter Bergner : https://gcc.gnu.org/g:066184a282b622ac6880150eb4e42fe57881b606 commit r9-8269-g066184a282b622ac6880150eb4e42fe57881b606 Author: Peter Bergner Date: Sun Feb 23 18:22:57 2020 -0600 rs6000: Fix infinite loop building ghostscript and icu [PR93658] Fix rs6000_legitimate_address_p(), which erroneously marks a valid Altivec address as being invalid, which causes LRA's process_address() to go into an infinite loop spilling the same address over and over again. Include Mike's earlier commits that fix bugs this patch exposes. Backport from master 2020-02-20 Peter Bergner PR target/93658 * config/rs6000/rs6000.c (rs6000_legitimate_address_p): Handle VSX vector modes. * gcc.target/powerpc/pr93658.c: New test.
[Bug c++/93898] [9/10 Regression] internal compiler error: in output_constructor_regular_field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93898 Marek Polacek changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P2 CC||jason at gcc dot gnu.org Target Milestone|--- |9.3 Summary|internal compiler error: in |[9/10 Regression] internal |output_constructor_regular_ |compiler error: in |field |output_constructor_regular_ ||field
[Bug c++/93898] New: internal compiler error: in output_constructor_regular_field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93898
Bug ID: 93898
Summary: internal compiler error: in
output_constructor_regular_field
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
struct empty { };
struct foo
{
[[no_unique_address]]
empty x;
constexpr
foo() : x{}
{ }
};
struct bar : foo
{
using foo::foo;
int i;
constexpr bar() : i{1} {}
};
constexpr bar a{};
$ ./cc1plus -quiet x.C
x.C:20:18: internal compiler error: in output_constructor_regular_field, at
varasm.c:5230
20 | constexpr bar a{};
| ^
0x1a28da5 output_constructor_regular_field
/home/mpolacek/src/gcc/gcc/varasm.c:5230
0x1a29cbe output_constructor
/home/mpolacek/src/gcc/gcc/varasm.c:5536
0x1a28617 output_constant
/home/mpolacek/src/gcc/gcc/varasm.c:5065
0x1a1e192 assemble_variable_contents
/home/mpolacek/src/gcc/gcc/varasm.c:2148
0x1a1ec30 assemble_variable(tree_node*, int, int, int)
/home/mpolacek/src/gcc/gcc/varasm.c:2327
0x1a3967c varpool_node::assemble_decl()
/home/mpolacek/src/gcc/gcc/varpool.c:587
0xe7a4fc output_in_order
/home/mpolacek/src/gcc/gcc/cgraphunit.c:2564
0xe7ab82 symbol_table::compile()
/home/mpolacek/src/gcc/gcc/cgraphunit.c:2801
0xe7afd0 symbol_table::finalize_compilation_unit()
/home/mpolacek/src/gcc/gcc/cgraphunit.c:2984
Started with r9-5710-g7e574f68fa82e7c5f879fd468291ec8b5ebecc83
[Bug c++/93892] Aggregate initialisation of std::array takes forever to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93892 Andrew Pinski changed: What|Removed |Added Component|libstdc++ |c++ --- Comment #1 from Andrew Pinski --- This might be improved for GCC 10.
[Bug target/93897] Poor trivial structure initialization code with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93897 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Target||x86_64-*-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2020-02-23 Summary|Poor trivial structure |Poor trivial structure |initialization code.|initialization code with ||-O3 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- This is a vector cost model.
[Bug tree-optimization/93893] MIPS32r2: GCC is unable to figure out that it can use a single INS instruction instead of SLL+OR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93893 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-02-23 Component|middle-end |tree-optimization Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Mine for GCC 11. I have a patch which fixes this but won't be included until GCC 11: transpose_c: .frame $sp,0,$31 # vars= 0, regs= 0/0, args= 0, gp= 0 .mask 0x,0 .fmask 0x,0 .setnoreorder .setnomacro lw $2,0($4) lw $3,0($5) ins $3,$2,16,16 jr $31 sw $3,0($6)
[Bug tree-optimization/93896] Store merging uses SSE only for trivial types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93896
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-02-23
Ever confirmed|0 |1
Severity|normal |enhancement
--- Comment #2 from Andrew Pinski ---
> MEM[(struct M *)this_2(D)].p = 0B;
> MEM [(unsigned int *)this_2(D) + 8B] = 0;
Could be stored merged (but only because 0 is 0) into:
MEM [(struct M *)this_2(D)] = {}
[Bug tree-optimization/93896] Store merging uses SSE only for trivial types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93896
--- Comment #1 from Marc Glisse ---
Without the constructor, we get plain
*this_2(D).a = {};
which is expanded as an __int128 store. With the constructor, we get
MEM[(struct M *)this_2(D)].p = 0B;
MEM[(struct M *)this_2(D)].sz = 0;
MEM[(struct M *)this_2(D)].cz = 0;
and store merging turns it into
MEM[(struct M *)this_2(D)].p = 0B;
MEM [(unsigned int *)this_2(D) + 8B] = 0;
but no further.
[Bug rtl-optimization/93564] [10 Regression] 470.lbm regresses by 25% on znver2 with -Ofast -march=native LTO and PGO since r10-6384-g2a07345c4f8dabc2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93564 --- Comment #2 from CVS Commits --- The master branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:3133bed5d0327e8a9cd0a601b7ecdb9de4fc825d commit r10-6804-g3133bed5d0327e8a9cd0a601b7ecdb9de4fc825d Author: Vladimir N. Makarov Date: Sun Feb 23 16:20:05 2020 -0500 Changing cost propagation and ordering colorable bucket heuristics for PR93564. 2020-02-23 Vladimir Makarov PR rtl-optimization/93564 * ira-color.c (struct update_cost_queue_elem): New member start. (queue_update_cost, get_next_update_cost): Add new arg start. (allocnos_conflict_p): New function. (update_costs_from_allocno): Add new arg conflict_cost_update_p. Add checking conflicts with allocnos_conflict_p. (update_costs_from_prefs, restore_costs_from_copies): Adjust update_costs_from_allocno calls. (update_conflict_hard_regno_costs): Add checking conflicts with allocnos_conflict_p. Adjust calls of queue_update_cost and get_next_update_cost. (assign_hard_reg): Adjust calls of queue_update_cost. Add debugging print. (bucket_allocno_compare_func): Restore previous version.
[Bug target/93897] New: Poor trivial structure initialization code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93897
Bug ID: 93897
Summary: Poor trivial structure initialization code.
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: maxim.yegorushkin at gmail dot com
Target Milestone: ---
The following code:
#include
struct B {
std::int64_t x;
std::int32_t y;
std::int32_t z;
};
B f(std::int64_t x, std::int32_t y, std::int32_t z) {
return {x, y, z};
}
Compiled with `gcc -O3 -std=gnu++17 -march=skylake` generates the following
assembly:
f(long, int, int):
mov QWORD PTR [rsp-16], 0
mov QWORD PTR [rsp-24], rdi
vmovdqa xmm1, XMMWORD PTR [rsp-24]
vpinsrd xmm0, xmm1, esi, 2
vpinsrd xmm2, xmm0, edx, 3
vmovdqa XMMWORD PTR [rsp-24], xmm2
mov rax, QWORD PTR [rsp-24]
mov rdx, QWORD PTR [rsp-16]
ret
Which looks a bit excessive.
Whereas when compiled with `clang-9.0 -O3 -std=gnu++17 -march=skylake` it
produces the expected:
f(long, int, int):
mov rax, rdi
shl rdx, 32
mov ecx, esi
or rdx, rcx
ret
https://gcc.godbolt.org/z/udsiyF
[Bug tree-optimization/93896] New: Store merging uses SSE only for trivial types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93896
Bug ID: 93896
Summary: Store merging uses SSE only for trivial types
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msharov at users dot sourceforge.net
Target Milestone: ---
struct M {
constexpr M() :p{},sz{},cz{}{}
public:
char* p;
unsigned sz;
unsigned cap;
};
struct A { M a,b,c; A(); };
A::A() :a{},b{},c{}{}
gcc 9.2.1 with -march=native -Os on Haswell generates:
_ZN1AC2Ev:
movq$0, (%rdi)
movq$0, 8(%rdi)
movq$0, 16(%rdi)
movq$0, 24(%rdi)
movq$0, 32(%rdi)
movq$0, 40(%rdi)
ret
Store merging is obviously working here, but does not use SSE movups. If the
constructor is removed or defaulted the output is:
_ZN1AC2Ev:
vpxor %xmm0, %xmm0, %xmm0
vmovups %xmm0, (%rdi)
vmovups %xmm0, 16(%rdi)
vmovups %xmm0, 32(%rdi)
ret
Whether the type is trivial should not matter by the time store merging occurs,
but for some reason it does.
[Bug fortran/83118] [8/9/10 Regression] Bad intrinsic assignment of class(*) array component of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118 --- Comment #28 from Paul Thomas --- (In reply to Damian Rouson from comment #27) > Thanks, Paul! We'll test the patch. > > Damian Hi Damian, What was the outcome of the test? I have spent much of today coming to grips with git and successfully submitted and committed my first patch with it (PR57710). It still is not especially obvious to me but I at least have a workflow that allows me to do things. Regards Paul
[Bug c++/93769] Slightly wrong diagnostic message for static_asserts with no message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93769 --- Comment #2 from Gennaro Prota --- (In reply to Marek Polacek from comment #1) > (In reply to Gennaro Prota from comment #0) [...] > -std=c++20 implies -std=c++17. I don't think viewing it this way is in general correct. > I suppose we could say what you're > suggesting but there are many places that would need changing. I'm dubious > if it's worth it. Well, I thought this would require changing a single string literal in the compiler source code.
[Bug c++/93895] [10 Regression] ICE (segmentation fault) in use of __is_constructible intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93895 --- Comment #3 from Marek Polacek --- The ICE started with r10-3735-gcb57504a550158913258e5be8ddb991376475efb
[Bug c++/93895] [10 Regression] ICE (segmentation fault) in use of __is_constructible intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93895 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-02-23 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |10.0 Summary|ICE (segmentation fault) in |[10 Regression] ICE |use of __is_constructible |(segmentation fault) in use |intrinsic |of __is_constructible ||intrinsic Ever confirmed|0 |1 --- Comment #2 from Marek Polacek --- Confirmed. G++ 9 doesn't ICE but spits tons of errors.
[Bug c++/93895] ICE (segmentation fault) in use of __is_constructible intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93895
--- Comment #1 from Eric Niebler ---
Here is the error:
repro.cpp.i: In instantiation of ‘bool bf::{anonymous}::bb, false> >’:
repro.cpp.i:158:67: required from ‘df::operator Container() [with
Container = view_facade,
false>::outer_cursor::inner_view, bh>; bool dk = true; dd =
chunk_view_, false>; bg de = bh]’
repro.cpp.i:206:1: required from ‘chunk_view_::outer_cursor::inner_view chunk_view_::outer_cursor::q()
[with cd = debug_input_view]’
repro.cpp.i:102:5: required from ‘auto ci::q(ck) [with ck =
chunk_view_, false>::outer_cursor]’
repro.cpp.i:123:6: required from ‘auto cf::operator*() [with ck =
chunk_view_, false>::outer_cursor]’
repro.cpp.i:57:1: required from ‘void cm::is_iterator(bw) requires t
[with bw = cf, false>::outer_cursor>]’
repro.cpp.i:129:12: required from ‘auto cm::cp::operator()(bx) requires
co [with bx = chunk_view >]’
repro.cpp.i:148:49: required from here
repro.cpp.i:40:50: internal compiler error: Segmentation fault: 11
40 | template bool bb = __is_constructible(ah,
an...);
|
^
[Bug c++/93895] New: ICE (segmentation fault) in use of __is_constructible intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93895 Bug ID: 93895 Summary: ICE (segmentation fault) in use of __is_constructible intrinsic Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: eric.niebler at gmail dot com Target Milestone: --- Created attachment 47892 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47892&action=edit result of creduce on the error Happens with trunk. Compile the attached repro.cpp.i with: g++ -std=c++2a -xc++ -c repro.cpp.i The attached file is the result of creduce which sadly made the code invalid, but the original ICE happened on valid code.
[Bug libstdc++/88101] Implement P0528R3, C++20 cmpxchg and padding bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88101 --- Comment #2 from andysem at mail dot ru --- Another use case is C++20 atomic_ref, which may be bound to an object whose padding bits are in indeterminate state. An intrinsic to clear padding bits without altering the object value could be useful.
[Bug fortran/93889] missing closing parenthesis in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93889 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Thomas Koenig --- Fixed, closing.
[Bug fortran/93889] missing closing parenthesis in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93889 --- Comment #2 from CVS Commits --- The master branch has been updated by Thomas Kथघnig : https://gcc.gnu.org/g:92e8508edaccca6f33098972ce29679375c07cd6 commit r10-6803-g92e8508edaccca6f33098972ce29679375c07cd6 Author: Thomas König Date: Sun Feb 23 17:22:26 2020 +0100 Add missing closing parenthises in error message. 2020-02-23 Thomas Koenig PR fortran/93889 * interface.c (compare_parameter): Fix error message.
[Bug fortran/93890] trailing space in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93890 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org --- Comment #3 from Thomas Koenig --- Fixed.
[Bug fortran/93890] trailing space in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93890 --- Comment #2 from CVS Commits --- The master branch has been updated by Thomas Kथघnig : https://gcc.gnu.org/g:7260547dbffd8e6442f99da8adf98ab0ce294e4e commit r10-6802-g7260547dbffd8e6442f99da8adf98ab0ce294e4e Author: Thomas König Date: Sun Feb 23 17:04:06 2020 +0100 Fix error message. 2020-02-23 Thomas Koenig PR fortran/93890 * interface.c: Replace "can not" by "cannot" and remove trailing space. 2020-02-23 Thomas Koenig PR fortran/93890 * gfortran.dg/argument_checking_24.f90: Correct test case.
[Bug fortran/57710] [OOP] [F08] _vptr not set for allocatable CLASS component inside BLOCK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57710 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Paul Thomas --- Fixed in r10-6801-g61c8d9e4e5f540501eaa98aae1d6c74bde7d4299 Thanks for the report. Paul
[Bug fortran/93889] missing closing parenthesis in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93889 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-02-23 CC||tkoenig at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Thomas Koenig --- Let's see.
[Bug fortran/93890] trailing space in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93890 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-02-23 CC||tkoenig at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Thomas Koenig --- Let's take this one as git practice.
[Bug tree-optimization/93891] CSE where clobber writes the same value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93891
--- Comment #1 from Marc Glisse ---
On the original code (I can attach it if needed, but it is large, it is
resizing a std::vector with reference-counted elements) FRE3 fails to simplify
MEM[(struct Handle_for *)__cur_16] ={v} {CLOBBER};
_17 = MEM[(const struct Handle_for &)__first_15].ptr_;
MEM[(struct Handle_for *)__cur_16].ptr_ = _17;
_18 = *_17.count;
_19 = _18 + 1;
*_17.count = _19;
_20 = &__first_15->D.202020;
_31 = MEM[(struct Handle_for *)__first_15].ptr_;
while FRE4 sees
MEM[(struct Handle_for *)__cur_3] ={v} {CLOBBER};
_17 = MEM[base: __first_20, offset: 0B];
MEM[base: __cur_3, offset: 0B] = _17;
_18 = *_17.count;
_19 = _18 + 1;
*_17.count = _19;
_31 = MEM[base: __first_20, offset: 0B];
and replaces _31 with _17. That's confusing, since the main difference between
the 2 is removing a statement without VOP.
(optimizing in FRE4 is way too late in this case, I want the simplified version
before ldist, and it still requires at least DSE, some pass detecting a
self-assignment, and DCE before that)
Here is another simplified version of the testcase, but you need to compile it
with -fno-early-inlining to see the issue:
void g();
struct A {
int*p;
A(A const&a)noexcept:p(a.p){if(*p<=0)__builtin_unreachable();++*p;}
~A(){if(--*p==0)g();}
};
#include
void f(std::vector&v){
v.reserve(1<<20);
}
At the end of gimple, we still have
_92 = *_91;
*_91 = _92;
in the main loop, while I would want that gone before ldist.
[Bug c/93894] -Wimplicit-fallthrough false warning with operator %
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93894 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Yeah, -Wimplicit-fallthrough is intentionally an early warning, so that it isn't dependent on optimizations etc., and you are asking that it depends on VRP or some poor man's VRP. There will always be ways to obfuscate code so that the compiler doesn't understand something can't fall through.
[Bug c/93894] -Wimplicit-fallthrough false warning with operator %
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93894 --- Comment #3 from Andrew Pinski --- The warning is not sensitive to what is being switched on. That is the inner most switch is considered as falling through as the switch is not checked for the values it will be switched on.
[Bug c/93894] -Wimplicit-fallthrough false warning with operator %
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93894
--- Comment #2 from Dmitry G. Dyachenko ---
`unsigned' changes nothing
$ cat xxu.i
int f1(int j, unsigned k)
{
switch (j) {
case 0:
switch (k % 2) {
case 0:
return 0;
case 1:
return 1;
}
// return 3; // uncomment to fix warning
default:
return 2;
}
}
$ gcc -fpreprocessed -Wimplicit-fallthrough=2 -Og -c xxu.i
xx.i: In function ‘f1’:
xx.i:5:2: warning: this statement may fall through [-Wimplicit-fallthrough=]
5 | switch (k % 2) {
| ^~
xx.i:12:5: note: here
12 | default:
| ^~~
[Bug c/93894] -Wimplicit-fallthrough false warning with operator %
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93894 --- Comment #1 from Andreas Schwab --- case -1 is missing.
[Bug c/82283] Wrong warning with -Wmissing-field-initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82283
--- Comment #5 from Yann Droneaud ---
For a full combo, here's the almost original code that trigger the two errors
above with GLibc < 2.28, only one with newer Glibc.
#define _GNU_SOURCE 1
#include
#include
#include
int test(int fd)
{
static const char message[] = "Hello world";
struct sockaddr_in addr = {
.sin_family = AF_INET,
.sin_addr.s_addr = htonl(INADDR_LOOPBACK),
.sin_port = htons(12345),
};
struct iovec vec = {
.iov_base = (void *)message,
.iov_len = sizeof(message),
};
struct mmsghdr mmsghdr = {
.msg_hdr = (struct msghdr) {
.msg_name = &addr,
.msg_namelen = sizeof(addr),
.msg_iov = &vec,
.msg_iovlen = 1,
},
};
return sendmmsg(fd, &mmsghdr, 1, 0);
}
see https://godbolt.org/z/pwXyzE
[Bug c/93894] New: -Wimplicit-fallthrough false warning with operator %
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93894
Bug ID: 93894
Summary: -Wimplicit-fallthrough false warning with operator %
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dimhen at gmail dot com
Target Milestone: ---
SVN:r257061 8.0.1 20180125 FAIL
r10-6795 FAIL
$ cat xx.i
int f(int j, int k)
{
switch (j) {
case 0:
switch (k % 2) {
case 0:
return 0;
case 1:
return 1;
}
// return 3; // uncomment to fix warning
default:
return 2;
}
}
$ gcc -fpreprocessed -Wimplicit-fallthrough=2 -O[0123] -c xx.i
xx.i: In function ‘f’:
xx.i:5:2: warning: this statement may fall through [-Wimplicit-fallthrough=]
5 | switch (k % 2) {
| ^~
xx.i:12:5: note: here
12 | default:
| ^~~
[Bug c++/84364] [8 Regression] -Weffc++ warns on "return *this" in template after r253599
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84364
icegood1980 at gmail dot com changed:
What|Removed |Added
CC||icegood1980 at gmail dot com
--- Comment #9 from icegood1980 at gmail dot com
---
I obtained given issue on 9th version of compiler with the next code:
template
inline Node& Node::operator=(const T& rhs) {
Assign(rhs);
return *this;
}
gcc --version
gcc (Ubuntu 9.2.1-9ubuntu2) 9.2.1 20191008
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Please, reopen an issue
[Bug c/93893] New: MIPS32r2: GCC is unable to figure out that it can use a single INS instruction instead of SLL+OR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93893 Bug ID: 93893 Summary: MIPS32r2: GCC is unable to figure out that it can use a single INS instruction instead of SLL+OR Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: siarhei.siamashka at gmail dot com Target Milestone: --- Created attachment 47891 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47891&action=edit Testcase for a single INS instruction vs. SLL+OR $ mipsel-unknown-linux-gnu-gcc -c -Os -march=mips32r2 testcase.c $ mipsel-unknown-linux-gnu-objdump -d testcase.o testcase.o: file format elf32-tradlittlemips Disassembly of section .text: : 0: 8c82lw v0,0(a0) 4: 94a3lhu v1,0(a1) 8: 00021400sll v0,v0,0x10 c: 00431025or v0,v0,v1 10: 03e8jr ra 14: acc2sw v0,0(a2) 0018 : 18: 8ca2lw v0,0(a1) 1c: 8c83lw v1,0(a0) 20: 7c62fc04ins v0,v1,0x10,0x10 24: 03e8jr ra 28: acc2sw v0,0(a2) 2c: nop The C implementation uses an extra instruction compared to the inline assembly variant of the same function.
[Bug libstdc++/93892] New: Aggregate initialisation of std::array takes forever to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93892
Bug ID: 93892
Summary: Aggregate initialisation of std::array takes forever to compile
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: zoid at riseup dot net
Target Milestone: ---
Created attachment 47890
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47890&action=edit
preprocessed mwe
Aggregate initialisation of a std::array with a non-trivial type and a large
number of elements, say 10, takes ages to compile and produces
correspondingly huge binaries on any optimisation level. Cranking up the size
parameter exacerbates the problem.
Note: There are similar bug reports of very old versions of gcc. This might be
a regression.
Minimal working example:
#include
int main() {
struct nontriv { nontriv() { } };
std::array array = {}; // <- aggregate init
}
// g++ -Wall -Wextra -pedantic -std=c++17 -O1 mwe.cpp -save-temps -v
Attached mwe.ii of the above mwe.cpp.
g++ version information:
Configured with: ../src/configure -v --with-pkgversion='Debian 9.2.1-25'
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-9
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none,hsa --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu --with-build-config=bootstrap-lto-lean
--enable-link-mutex
Thread model: posix
gcc version 9.2.1 20200123 (Debian 9.2.1-25)
[Bug c++/93842] generic lambda accesses a variable with with automatic storage duration that wasn't captured by the lambda expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93842
--- Comment #4 from kuzniar95 at o2 dot pl ---
I meant that dropping constness:
char ch = '='; // OK
results in an error:
lambda.cpp: In lambda function:
lambda.cpp:4:23: error: ‘ch’ is not captured
4 | [](auto) { return ch; }; // OK
| ^~
lambda.cpp:4:6: note: the lambda has no capture-default
4 | [](auto) { return ch; }; // OK
| ^
lambda.cpp:2:7: note: ‘char ch’ declared here
2 | char ch = '=';
| ^~
which is actually good.
