[Bug translation/93864] typo: paramter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93864 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:71837f64ab07ed915ac333f620826668566b9cfb commit r10-6833-g71837f64ab07ed915ac333f620826668566b9cfb Author: Jakub Jelinek Date: Tue Feb 25 09:02:57 2020 +0100 Fix typo: paramter -> parameter [PR93864] 2020-02-25 Jakub Jelinek PR translation/93864 * config/lm32/lm32.c (lm32_setup_incoming_varargs): Fix comment typo paramter -> parameter. * config/aarch64/aarch64.c (aarch64_is_extend_from_extract): Likewise. * ipa-prop.h (struct ipa_agg_replacement_value): Likewise. * intrinsic.texi (CO_BROADCAST): Fix typo, paramter -> parameter. * trans-array.c (gfc_allocate_pdt_comp, gfc_deallocate_pdt_comp, gfc_check_pdt_dummy): Fix comment typo paramter -> parameter. * objc.dg/encode-2.m: Fix comment typo paramter -> parameter. * obj-c++.dg/encode-4.mm: Likewise. * gfortran.dg/data_array_5.f90: Likewise. * gcc.dg/decl-1.c: Likewise.
[Bug tree-optimization/93919] New: [10 Regression] vectorization of 18 char to char16_t conversion is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93919
Bug ID: 93919
Summary: [10 Regression] vectorization of 18 char to char16_t
conversion is miscompiled
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: kretz at kde dot org
Target Milestone: ---
Target: x86_64-*-*, i?86-*-*
Test case (https://godbolt.org/z/8QYarZ):
char in[18] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17};
int
main()
{
using V [[gnu::vector_size(32)]] = char;
const V seq
= {in[0], in[1], in[2], in[3], in[4], in[5], in[6], in[7], in[8],
in[9], in[10], in[11], in[12], in[13], in[14], in[15], in[16], in[17]};
char16_t out[18];
for (int i = 0; i < 18; ++i)
out[i] = static_cast(seq[i]);
for (int i = 0; i < 18; ++i)
{
const volatile char16_t reference(seq[i]);
if (out[i] != reference)
__builtin_abort();
}
}
Compile with `-O1 -ftree-vectorize`. Result:
pxor xmm1, xmm1
pcmpgtb xmm1, xmm0 # xmm0 is seq[0:15]
movdqa xmm2, xmm0
punpcklbw xmm2, xmm1
movaps XMMWORD PTR [rsp+16], xmm2
punpckhbw xmm0, xmm1
movaps XMMWORD PTR [rsp+32], xmm0
movsx eax, WORD PTR [rsp+80] # WORD PTR [rsp+80] is seq[16:17]
mov DWORD PTR [rsp+48], eax # out-of-bounds write by 2 Bytes
Conversion of the first 16 char to char16_t is correct. The latter 2 char are
loaded as a word and sign extended to a doubleword. The doubleword is stored to
the stack, exceeding the size of the destination array by 2 Bytes. Besides the
out-of-bounds access, the result in out[16] and out[17] is wrong.
[Bug c/93858] missing question mark in diagnostic: unknown option after #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93858 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:7b60f3ba7660ad8697843ed8d0198449b9ea0a90 commit r10-6834-g7b60f3ba7660ad8697843ed8d0198449b9ea0a90 Author: Jakub Jelinek Date: Tue Feb 25 09:04:39 2020 +0100 c: Small diagnostics tweak - add missing ? after did you mean [PR93858] 2020-02-25 Jakub Jelinek PR c/93858 * c-pragma.c (handle_pragma_diagnostic): Add missing ? after "did you mean" hint in diagnostics.
[Bug ipa/93763] [10 Regression] ice in propagate_vals_across_arith_jfunc, at ipa-cp.c:2039
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93763 --- Comment #7 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:103bc4db7665a03bf2390ccc8ceca0dc5a7a81b7 commit r10-6835-g103bc4db7665a03bf2390ccc8ceca0dc5a7a81b7 Author: Jakub Jelinek Date: Tue Feb 25 09:05:57 2020 +0100 testsuite: Fix recently added ipa testcases [PR93763] Seems the test has been badly reduced (if the original doesn't emit warnings, it is always better in the reduction script avoid introducing new ones). Also, the g++.dg/ipa/ test fails with -std=c++98 because it is written in C++11. 2020-02-25 Jakub Jelinek PR ipa/93763 * gcc.dg/ipa/pr93763.c: Adjust the test so that it compiles without warnings and still ICEs before the ipa-cp.c fix. * g++.dg/ipa/pr93763.C: Require c++11 effective target.
[Bug preprocessor/93920] New: Wrong comments preprocessing using -E and -CC with escaped end-of-line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93920
Bug ID: 93920
Summary: Wrong comments preprocessing using -E and -CC with
escaped end-of-line
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: m...@allan-blanchard.fr
Target Milestone: ---
If a comment contains a line with an escaped end-of-line, the last character of
the line is printed a second time on a new line after preprocessing.
void f(void){
/*
line \
contentX
new line
*/
}
Command:
$ gcc -E -CC example.c
Result:
// ... headers, etc.
# 1 "./example.cpp"
void f(void){
/*
line contentX
X
new line
*/
}
Found on:
- gcc (Arch Linux 9.2.1+20200130-2) 9.2.1 20200130
Reproduced on:
- gcc version 8.3.0 (Ubuntu 8.3.0-6ubuntu1)
- all GCC versions available on GodBolt.
[Bug c++/93905] [8 Regression] Cannot use Derived type of Base containing both enum and protected destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93905 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.4
[Bug c++/93921] New: -Os generates much bigger code than -O{1,2,3,fast} for std::string::size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93921
Bug ID: 93921
Summary: -Os generates much bigger code than -O{1,2,3,fast} for
std::string::size
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bsnoksru at cisco dot com
Target Milestone: ---
Testing with the following code-fragment
#include
#include
int foo() {
using namespace std::literals;
return "asdf"s.size();
}
int bar() {
using namespace std::string_view_literals;
return "asdf"sv.size();
}
using g++ from `trunk` (as reported by godbolt), with flags "--std=c++17" and
different optimiziation levels show that the string-view size gets inlined to a
constant for all relevant optimization levels, while the string-size code gets
inflated when optimizing for size.
[Bug c++/93921] -Os generates much bigger code than -O{1,2,3,fast} for std::string::size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93921 --- Comment #1 from Bjørnar Snoksrud --- Created attachment 47903 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47903&action=edit godbolt output for -Os
[Bug c++/93922] New: Fails to emit inline class template destructor instantiation, but which is called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93922
Bug ID: 93922
Summary: Fails to emit inline class template destructor
instantiation, but which is called
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
I came across this when building LibreOffice and its bundled Skia with recent
GCC 10 trunk and it failed to link due to two undefined references. I hope the
below is a faithfully stripped-down reproducer for the error I encountered:
> $ cat test.cc
> template struct sk_sp {
> template sk_sp(sk_sp const &);
> ~sk_sp() {}
> };
> struct SkPicture {};
> struct Wrapped: SkPicture {
> Wrapped(SkPicture const &);
> };
> struct S {
> sk_sp x;
> Wrapped y;
> };
> sk_sp ref(SkPicture *);
> void f(SkPicture * x, SkPicture const & y) {
> new S(ref(x), y);
> }
> $ g++ -std=c++2a -S test.cc -o - | grep _ZN5sk_spIK9SkPictureED1Ev
> call_ZN5sk_spIK9SkPictureED1Ev
shows that sk_sp::~sk_sp() (i.e., _ZN5sk_spIK9SkPictureED1Ev)
is called (from f) but not emitted.
[Bug c++/93921] -Os generates much bigger code than -O{1,2,3,fast} for std::string::size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93921 --- Comment #2 from Bjørnar Snoksrud --- Created attachment 47904 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47904&action=edit godbolt output for -O3
[Bug middle-end/93919] [10 Regression] vectorization of 18 char to char16_t conversion is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93919 Andrew Pinski changed: What|Removed |Added Target|x86_64-*-*, i?86-*-*|x86_64-*-*, i?86-*-*, ||aarch64-linux-gnu Status|UNCONFIRMED |NEW Last reconfirmed||2020-02-25 Component|tree-optimization |middle-end Target Milestone|--- |10.0 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- vector(8) char16_t vect__20.10; //8*2 = 16 bytes vect__19.9_55 = MEM [(vector(32) char *)&seq]; vect__20.10_56 = [vec_unpack_lo_expr] vect__19.9_55; vect__20.10_57 = [vec_unpack_hi_expr] vect__19.9_55; MEM [(char16_t *)&out] = vect__20.10_56; MEM [(char16_t *)&out + 16B] = vect__20.10_57; vect__20.15_63 = MEM [(vector(32) char *)&seq + 16B]; vect__33.16_58 = (vector(2) char16_t) vect__20.15_63; MEM [(char16_t *)&out + 32B] = vect__33.16_58; ;; MEM [(char16_t *)&out + 32B] = vect__33.16_58; (insn 165 164 166 (set (reg:SI 251) (sign_extend:SI (mem/c:HI (plus:DI (reg/f:DI 77 virtual-stack-vars) (const_int -80 [0xffb0])) [0 MEM [(vector(32) char *)&seq + 16B]+0 S2 A128]))) "t87656.c":14:14 -1 (nil)) (insn 166 165 0 (set (mem/c:SI (plus:DI (reg/f:DI 77 virtual-stack-vars) (const_int -32 [0xffe0])) [1 MEM [(char16_t *)&out + 32B]+0 S4 A256]) (reg:SI 251)) "t87656.c":14:14 -1 (nil)) HuH? We get this bad code also on aarch64-linux-gnu.
[Bug libstdc++/93923] New: [Regression 10] std::is_copy_constructible raises compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93923
Bug ID: 93923
Summary: [Regression 10] std::is_copy_constructible raises
compilation error
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: laurent.stacul at gmail dot com
Target Milestone: ---
Hello,
The following code does not compile anymore with gcc 10 although it works in
9.2, 9.2, 8.x.
#include
#include
class A;
template
struct B {
template<
class... Args,
std::enable_if_t::value, int> = 0 >
B(Args && ... args) {}
};
struct A {
A(const B& b) {}
};
int main(int argc, const char *argv[])
{
static_assert(std::is_copy_constructible::value);
return 0;
}
Compiling with the HEAD of gcc 10 I have the following error:
$ g++ is_constructible.cpp
[jobs: 0][history: 5132]
In file included from is_constructible.cpp:1:
/remote/tools/Linux/2.6/1A/toolchain/x86_64-v20.0.10/include/c++/10.0.1/type_traits:
In instantiation of ‘struct std::is_constructible’:
is_constructible.cpp:10:75: required by substitution of ‘template::value,
int>::type > B::B(Args&& ...) [with Args = {const A&}; typename
std::enable_if::value, int>::type
= ]’
/remote/tools/Linux/2.6/1A/toolchain/x86_64-v20.0.10/include/c++/10.0.1/type_traits:901:30:
required from ‘struct std::__is_constructible_impl’
/remote/tools/Linux/2.6/1A/toolchain/x86_64-v20.0.10/include/c++/10.0.1/type_traits:930:12:
required from ‘struct std::__is_copy_constructible_impl’
/remote/tools/Linux/2.6/1A/toolchain/x86_64-v20.0.10/include/c++/10.0.1/type_traits:936:12:
required from ‘struct std::is_copy_constructible’
is_constructible.cpp:21:48: required from here
/remote/tools/Linux/2.6/1A/toolchain/x86_64-v20.0.10/include/c++/10.0.1/type_traits:906:12:
error: invalid use of incomplete type ‘struct std::__is_constructible_impl’
906 | struct is_constructible
|^~~~
/remote/tools/Linux/2.6/1A/toolchain/x86_64-v20.0.10/include/c++/10.0.1/type_traits:900:12:
note: declaration of ‘struct std::__is_constructible_impl’
900 | struct __is_constructible_impl
|^~~
This is true in any standard versions (-std=c/gnu++14, c/gnu++17, c/gnu++2a,
c++20).
System information
$ gcc --version
gcc (GCC) 10.0.1 20200220 (experimental)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ uname -a
Linux ncerndobedev6196 4.12.14-95.45-default #1 SMP Wed Dec 11 13:09:13 UTC
2019 (12c8180) x86_64 x86_64 x86_64 GNU/Linux
[Bug fortran/93924] New: ICE in gfc_class_len_get at trans_expr.c:231 with function returning a procedure pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93924 Bug ID: 93924 Summary: ICE in gfc_class_len_get at trans_expr.c:231 with function returning a procedure pointer Product: gcc Version: 9.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mscfd at gmx dot net Target Milestone: --- The code below aborts with an ICE. This happens with 9.1.1 as well as a recent gfortran-10 compiled version. The ICE is due to the function selector. module cs implicit none private public classStar_map_ifc public apply, selector abstract interface function classStar_map_ifc(x) result(y) class(*), pointer:: y class(*), target, intent(in) :: x end function classStar_map_ifc end interface contains function fun(x) result(y) class(*), pointer:: y class(*), target, intent(in) :: x select type (x) type is (integer) y => x class default y => null() end select end function fun function apply(f, x) result(y) procedure(classStar_map_ifc) :: f integer, intent(in) :: x integer :: y class(*), pointer :: p p => f(x) select type (p) type is (integer) y = p end select end function apply function selector() result(f) procedure(classStar_map_ifc), pointer :: f f => fun end function selector end module cs program classStar_map use cs implicit none integer :: x, y procedure(classStar_map_ifc), pointer :: f x = 123654 f => selector() y = apply(f, x) print *, x, y end program classStar_map
[Bug c++/93921] -Os generates much bigger code than -O{1,2,3,fast} for std::string::size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93921 --- Comment #3 from Bjørnar Snoksrud --- Using '--std=c++20 -Os' generates minimal code.
[Bug testsuite/93909] [10 regression] new test cases gcc.dg/ipa/pr93763.c and g++.dg/ipa/pr93763.C fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93909 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.0
[Bug target/93913] [10 regression] r10-6762 breaks gcc.target/powerpc/fold-vec-st-*.c test cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93913 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.0
[Bug fortran/93925] New: Invalid memory reference upon call of a routine taking a procedure pointer as argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93925 Bug ID: 93925 Summary: Invalid memory reference upon call of a routine taking a procedure pointer as argument Product: gcc Version: 9.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mscfd at gmx dot net Target Milestone: --- The following code aborts with a segfault (invalid memory reference) upon call of the apply function. This happens with gfortran 9.1.1 as well as a recent gfortran-10. module cs implicit none private public classStar_map_ifc public fun, apply abstract interface function classStar_map_ifc(x) result(y) class(*), pointer:: y class(*), target, intent(in) :: x end function classStar_map_ifc end interface contains function fun(x) result(y) class(*), pointer:: y class(*), target, intent(in) :: x select type (x) type is (integer) y => x class default y => null() end select end function fun function apply(f, x) result(y) procedure(classStar_map_ifc) :: f integer, intent(in) :: x integer :: y class(*), pointer :: p p => f(x) select type (p) type is (integer) y = p end select end function apply end module cs program classStar_map2 use cs implicit none integer :: x, y procedure(classStar_map_ifc), pointer :: f x = 123654 y = apply(fun, x) print *, x, y end program classStar_map2
[Bug c/93858] missing question mark in diagnostic: unknown option after #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93858 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Fixed.
[Bug middle-end/93874] ICE due to command line options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93874 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:2473c81cb2d4627f2d72310f4eca951c6084b596 commit r10-6837-g2473c81cb2d4627f2d72310f4eca951c6084b596 Author: Jakub Jelinek Date: Tue Feb 25 10:21:34 2020 +0100 pass_manager: Fix ICE with -fdump-passes -fdisable-tree-* [PR93874] dump_passes pushes a dummy function for which it evaluates the gates and checks whether the pass is enabled or disabled. Unfortunately, if any -fdisable-*-*/-fenable-*-* options were seen, we ICE during is_pass_explicitly_enabled_or_disabled because slot is non-NULL then and the code will do: cgraph_uid = func ? cgraph_node::get (func)->get_uid () : 0; but the dummy function doesn't have a cgraph node. So, either we need to create and then remove a cgraph node for the dummy function like the following patch, or function.c would need to export the in_dummy_function flag (or have some way to query that flag from other TUs) and we'd need to check it in is_pass_explicitly_enabled_or_disabled. 2020-02-25 Jakub Jelinek PR middle-end/93874 * passes.c (pass_manager::dump_passes): Create a cgraph node for the dummy function and remove it at the end. * gcc.dg/pr93874.c: New test.
[Bug middle-end/93874] ICE due to command line options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93874 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug translation/93864] typo: paramter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93864 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #3 from Jakub Jelinek --- Fixed.
[Bug c++/93921] -Os generates much bigger code than -O{1,2,3,fast} for std::string::size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93921 --- Comment #4 from Andrew Pinski --- _S_copy_chars is just a wrapper function around _S_copy And _S_copy is a wrapper function around either assign or copy based on the size k1-k2 of the original _S_copy_chars. assign is just an assignment of one char. copy is just a wrapper around __builtin_memcpy. I don't understand the ipa dumps to understand why we are not inlining here at all.
[Bug c/93858] missing question mark in diagnostic: unknown option after #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93858 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |10.0
[Bug c++/93916] Implicit copy/assignment alters padding bits of storage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93916 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2020-02-25 Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- I think the behavior you see is perfectly valid. Also Andrews comment is valid, the memset is very likely elided.
[Bug tree-optimization/93868] [10 Regression] wrong-code with permuted SLP reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93868 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Guenther : https://gcc.gnu.org/g:81c833b311b16cfd87a947374d5ffbbd48facd03 commit r10-6838-g81c833b311b16cfd87a947374d5ffbbd48facd03 Author: Richard Biener Date: Tue Feb 25 10:31:16 2020 +0100 tree-optimization/93868 copy SLP tree before re-arranging stmts This avoids altering possibly shared SLP subtrees when attempting to get rid of permutations in SLP reductions by copying the SLP subtree before re-arranging stmts in it. 2020-02-25 Richard Biener PR tree-optimization/93868 * tree-vect-slp.c (slp_copy_subtree): New function. (vect_attempt_slp_rearrange_stmts): Copy the SLP tree before re-arranging stmts in it. * gcc.dg/torture/pr93868.c: New testcase.
[Bug tree-optimization/93917] VRP forgets range of value read from memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93917 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-02-25 Blocks||85316 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- VRP indeed doesn't start with SSA_NAME_RANGE_INFOs range but with UNDEF and if not "interesting" it sets defs to varying which doesn't retain the IL present range either. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316 [Bug 85316] [meta-bug] VRP range propagation missed cases
[Bug tree-optimization/93868] [10 Regression] wrong-code with permuted SLP reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93868 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed.
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 93868, which changed state. Bug 93868 Summary: [10 Regression] wrong-code with permuted SLP reduction https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93868 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/93918] Segfault with -Ofast when calling a routine with an array argument array(:)%component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93918 --- Comment #1 from Richard Biener --- -Ofast enables -fstack-arrays so this is a user error IMHO.
[Bug middle-end/93919] [10 Regression] vectorization of 18 char to char16_t conversion is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93919 Richard Biener changed: What|Removed |Added Priority|P3 |P1 CC||rsandifo at gcc dot gnu.org Depends on||93843 --- Comment #2 from Richard Biener --- Sounds like a dup of PR93843 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93843 [Bug 93843] [10 Regression] wrong code at -O3 on x86_64-linux-gnu
[Bug libstdc++/93923] [10 Regression] std::is_copy_constructible raises compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93923 Richard Biener changed: What|Removed |Added Keywords||rejects-valid Target Milestone|--- |10.0 Summary|[Regression 10] |[10 Regression] |std::is_copy_constructible |std::is_copy_constructible |raises compilation error|raises compilation error
[Bug tree-optimization/92768] [8 Regression] Maybe a wrong code for vector constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92768 --- Comment #21 from CVS Commits --- The releases/gcc-8 branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:e4efe90aec0a5f722341c1070680d2ab3a438a7d commit r8-10058-ge4efe90aec0a5f722341c1070680d2ab3a438a7d Author: Richard Sandiford Date: Thu Dec 5 14:20:38 2019 + Check for bitwise identity when encoding VECTOR_CSTs [PR92768] This PR shows that we weren't checking for bitwise-identical values when trying to encode a VECTOR_CST, so -0.0 was treated the same as 0.0 for -fno-signed-zeros. The patch adds a new OEP flag to select that behaviour. 2020-02-25 Richard Sandiford gcc/ Backport from mainline 2019-12-05 Richard Sandiford PR middle-end/92768 * tree-core.h (OEP_BITWISE): New flag. * fold-const.c (operand_compare::operand_equal_p): Handle it. * tree-vector-builder.h (tree_vector_builder::equal_p): Pass it. gcc/testsuite/ PR middle-end/92768 * gcc.dg/pr92768.c: New test.
[Bug tree-optimization/92420] [8 Regression] Vectorization miscompilation with negative strides since r238039
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92420 --- Comment #5 from CVS Commits --- The releases/gcc-8 branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:785eda9390473e42f0e0b7199c42032a0432de68 commit r8-10057-g785eda9390473e42f0e0b7199c42032a0432de68 Author: Richard Sandiford Date: Mon Nov 11 19:43:52 2019 + Fix SLP downward group access classification [PR92420] This PR was caused by the SLP handling in get_group_load_store_type returning VMAT_CONTIGUOUS rather than VMAT_CONTIGUOUS_REVERSE for downward groups. A more elaborate fix would be to try to combine the reverse permutation into SLP_TREE_LOAD_PERMUTATION for loads, but that's really a follow-on optimisation and not backport material. It might also not necessarily be a win, if the target supports (say) reversing and odd/even swaps as independent permutes but doesn't recognise the combined form. 2020-02-25 Richard Sandiford gcc/ Backport from mainline 2019-11-11 Richard Sandiford PR tree-optimization/92420 * tree-vect-stmts.c (get_negative_load_store_type): Move further up file. (get_group_load_store_type): Use it for reversed SLP accesses. gcc/testsuite/ PR tree-optimization/92420 * gcc.dg/vect/pr92420.c: New test.
[Bug middle-end/93926] New: [10 Regression] ICE: verify_cgraph_node failed (error: malloc attribute should be used for a function that returns a pointer)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93926
Bug ID: 93926
Summary: [10 Regression] ICE: verify_cgraph_node failed (error:
malloc attribute should be used for a function that
returns a pointer)
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-checking, ice-on-invalid-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-10.0.1-alpha20200223 snapshot (g:3133bed5d0327e8a9cd0a601b7ecdb9de4fc825d)
ICEs when compiling the following testcase on a 64-bit host w/ -m32 -fchecking:
long int
malloc (int);
int *
f (void)
{
return (int *) malloc (sizeof (int));
}
% gcc-10.0.1 -m32 -c uivreegs.c
uivreegs.c:8:1: error: malloc attribute should be used for a function that
returns a pointer
8 | }
| ^
malloc/1 (malloc) @0x7f022025d168
Type: function
Visibility: external public
References:
Referring:
Function flags:
Called by: f/0
Calls:
uivreegs.c:8:1: internal compiler error: verify_cgraph_node failed
0x92ae3e cgraph_node::verify_node()
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/cgraph.c:3755
0x91df74 symtab_node::verify()
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/symtab.c:1300
0x91f102 symtab_node::verify_symtab_nodes()
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/symtab.c:1320
0x931c24 symtab_node::checking_verify_symtab_nodes()
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/cgraph.h:667
0x931c24 symbol_table::compile()
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/cgraphunit.c:2720
0x933c5c symbol_table::compile()
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/cgraphunit.c:2717
0x933c5c symbol_table::finalize_compilation_unit()
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/cgraphunit.c:2984
Checking fails similarly for calloc(), strdup() and so on. When compiling w/
-m64, I see correct diagnostic instead:
% gcc-10.0.1 -c uivreegs.c
uivreegs.c:2:1: warning: conflicting types for built-in function 'malloc';
expected 'void *(long unsigned int)' [-Wbuiltin-declaration-mismatch]
2 | malloc (int);
| ^~
uivreegs.c:1:1: note: 'malloc' is declared in header ''
+++ |+#include
1 | long int
[Bug tree-optimization/93767] [8 Regression] wrong code at -O3 on x86_64-linux-gnu since r8-6064
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93767 --- Comment #5 from CVS Commits --- The releases/gcc-8 branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:a6378029183005ff05865496975ff706d91853d8 commit r8-10060-ga6378029183005ff05865496975ff706d91853d8 Author: Richard Sandiford Date: Tue Feb 18 18:06:32 2020 + vect: Fix offset calculation for -ve strides [PR93767] This PR is a regression caused by r256644, which added support for alias checks involving variable strides. One of the changes in that commit was to split the access size out of the segment length. The PR shows that I hadn't done that correctly for the handling of negative strides in vect_compile_time_alias. The old code was: const_length_a = (-wi::to_poly_wide (segment_length_a)).force_uhwi (); offset_a = (offset_a + vect_get_scalar_dr_size (a)) - const_length_a; where vect_get_scalar_dr_size (a) was cancelling out the subtraction of the access size inherent in "- const_length_a". Taking the access size out of the segment length meant that the addition was no longer needed/correct. 2020-02-25 Richard Sandiford gcc/ Backport from mainline 2020-02-19 Richard Sandiford PR tree-optimization/93767 * tree-vect-data-refs.c (vect_compile_time_alias): Remove the access-size bias from the offset calculations for negative strides. gcc/testsuite/ Backport from mainline 2020-02-19 Richard Sandiford PR tree-optimization/93767 * gcc.dg/vect/pr93767.c: New test.
[Bug tree-optimization/93434] [8 Regression] Miscompilation with -O3 starting from 8.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93434 --- Comment #10 from CVS Commits --- The releases/gcc-8 branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:50c7f76eb30041a9b219cd6535c8c09583cc052b commit r8-10059-g50c7f76eb30041a9b219cd6535c8c09583cc052b Author: Richard Sandiford Date: Mon Jan 27 19:37:55 2020 + predcom: Fix invalid store-store commoning [PR93434] predcom has the following code to stop one rogue load from interfering with other store-load opportunities: /* If A is read and B write or vice versa and there is unsuitable dependence, instead of merging both components into a component that will certainly not pass suitable_component_p, just put the read into bad component, perhaps at least the write together with all the other data refs in it's component will be optimizable. */ But when store-store commoning was added later, this had the effect of ignoring loads that occur between two candidate stores. There is code further up to handle loads and stores with unknown dependences: /* Don't do store elimination if there is any unknown dependence for any store data reference. */ if ((DR_IS_WRITE (dra) || DR_IS_WRITE (drb)) && (DDR_ARE_DEPENDENT (ddr) == chrec_dont_know || DDR_NUM_DIST_VECTS (ddr) == 0)) eliminate_store_p = false; But the store-load code above skips loads for *known* dependences if (a) the load has already been marked "bad" or (b) the data-ref machinery knows the dependence distance, but determine_offsets can't handle the combination. (a) happens to be the problem in the testcase, but a different sequence could have given (b) instead. We have writes to individual fields of a structure and reads from the whole structure. Since determine_offsets requires the types to be the same, it returns false for each such read/write combination. This patch records which components have had loads removed and prevents store-store commoning for them. It's a bit too pessimistic, since there shouldn't be a problem if a "bad" load dominates all stores in a component. But (a) we can't AFAIK use pcom_stmt_dominates_stmt_p here and (b) the handling for that case would probably need to be removed again if we handled more exotic cases in future. 2020-02-25 Richard Sandiford gcc/ Backport from mainline 2020-01-28 Richard Sandiford PR tree-optimization/93434 * tree-predcom.c (split_data_refs_to_components): Record which components have had aliasing loads removed. Prevent store-store commoning for all such components. gcc/testsuite/ PR tree-optimization/93434 * gcc.c-torture/execute/pr93434.c: New test.
[Bug c++/90313] [8 Regression] Is an assignment elided with gcc7.3 -O2?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90313 --- Comment #8 from CVS Commits --- The releases/gcc-8 branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:7a2f576c3b40eca0a846553af5b1dfb05d84eb71 commit r8-10056-g7a2f576c3b40eca0a846553af5b1dfb05d84eb71 Author: Richard Sandiford Date: Fri Aug 9 09:37:55 2019 + Reject tail calls that read from an escaped RESULT_DECL [PR90313] In this PR we have two return paths from a function "map". The common code sets to the value returned by one path, while the other path does: = map (&, ...); We treated this call as tail recursion, losing the copy semantics on the value returned by the recursive call. We'd correctly reject the same thing for variables: local = map (&local, ...); The problem is that RESULT_DECLs didn't get the same treatment. 2020-02-25 Richard Sandiford gcc/ Backport from mainline 2019-08-09 Richard Sandiford PR middle-end/90313 * tree-tailcall.c (find_tail_calls): Reject calls that might read from an escaped RESULT_DECL. gcc/testsuite/ PR middle-end/90313 * g++.dg/torture/pr90313.cc: New test.
[Bug middle-end/93919] [10 Regression] vectorization of 18 char to char16_t conversion is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93919 --- Comment #3 from Andrew Pinski --- (In reply to Richard Biener from comment #2) > Sounds like a dup of PR93843 Yes it does.
[Bug fortran/93918] Segfault with -Ofast when calling a routine with an array argument array(:)%component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93918 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- As documented, -fstack-arrays is enabled for -Ofast. https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Optimize-Options.html#index-Ofast : Disregard strict standards compliance. -Ofast enables all -O3 optimizations. It also enables optimizations that are not valid for all standard-compliant programs. It turns on -ffast-math and the Fortran-specific -fstack-arrays, unless -fmax-stack-var-size is specified, and -fno-protect-parens.
[Bug c++/90313] [8 Regression] Is an assignment elided with gcc7.3 -O2?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90313 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from rsandifo at gcc dot gnu.org --- Fixed on trunk and branches. Thanks for the bug report.
[Bug tree-optimization/93734] [8/9 Regression] Invalid code generated with -O2 -march=haswell -ftree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93734 Bug 93734 depends on bug 92420, which changed state. Bug 92420 Summary: [8 Regression] Vectorization miscompilation with negative strides since r238039 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92420 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/92420] [8 Regression] Vectorization miscompilation with negative strides since r238039
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92420 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from rsandifo at gcc dot gnu.org --- Fixed on trunk and branches.
[Bug tree-optimization/92768] [8 Regression] Maybe a wrong code for vector constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92768 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #22 from rsandifo at gcc dot gnu.org --- Fixed on trunk and branches.
[Bug c++/93922] Fails to emit inline class template destructor instantiation, but which is called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93922 Jakub Jelinek changed: What|Removed |Added Keywords|link-failure| Status|UNCONFIRMED |NEW Last reconfirmed||2020-02-25 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r10-5577-g942d334ec3fdf360dfedc0f97d1b4747a1f56f08 , though unsure if we can treat is as a regression, because the testcase hasn't been accepted until r10-5137-g43aae289866f5ea55d187444520412554aa2e171
[Bug c++/93916] Implicit copy/assignment alters padding bits of storage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93916 --- Comment #4 from andysem at mail dot ru --- Are you saying that implementation is allowed to not preserve unused storage state upon construction and assignment? Because I don't think this is what the standard says. Is there any other way to achieve the effect of initializing padding in a struct?
[Bug tree-optimization/93434] [8 Regression] Miscompilation with -O3 starting from 8.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93434 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from rsandifo at gcc dot gnu.org --- Fixed on trunk and branches. Thanks for the bug report.
[Bug fortran/93918] Segfault with -Ofast when calling a routine with an array argument array(:)%component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93918 --- Comment #3 from martin --- But there should not be an temporary array in the first place, which is causing the problem?
[Bug tree-optimization/93767] [8 Regression] wrong code at -O3 on x86_64-linux-gnu since r8-6064
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93767 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from rsandifo at gcc dot gnu.org --- Fixed on trunk and branches. Thanks for the bug report.
[Bug c++/93014] [9 Regression] ICE when initialising vector references with -flax-vector-conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93014 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from rsandifo at gcc dot gnu.org --- Not intending to backport this, not sure the benefit is worth any risk.
[Bug middle-end/93919] [10 Regression] vectorization of 18 char to char16_t conversion is miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93919 --- Comment #4 from Matthias Kretz (Vir) --- Yes, this is the same issue. FWIW, a vectorization with SSE4.1 could do: pxor xmm0, xmm0 pinsrw xmm0, WORD PTR in[rip], 0 pmovsxbw xmm0, xmm0 movd DWORD PTR out[rip], xmm0 Whether that's faster than movsx eax, BYTE PTR in[rip] mov WORD PTR out[rip], ax movsx eax, BYTE PTR in[rip+1] mov WORD PTR out[rip+2], ax probably depends on whether the load/store ports are limiting the performance on this section of code. Without SSE4.1 I don't think it's worth vectorizing this conversion. In any case, my analysis that there's an out-of-bounds store was wrong. Please disregard.
[Bug c++/93922] [10 Regression] Fails to emit inline class template destructor instantiation, but which is called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93922 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.0 Summary|Fails to emit inline class |[10 Regression] Fails to |template destructor |emit inline class template |instantiation, but which is |destructor instantiation, |called |but which is called --- Comment #3 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #1) > Started with r10-5577-g942d334ec3fdf360dfedc0f97d1b4747a1f56f08 , though > unsure if we can treat is as a regression, because the testcase hasn't been > accepted until r10-5137-g43aae289866f5ea55d187444520412554aa2e171 As I showed in comment #3, this is a regression. Just a simple change was needed to make it a valid C++11 testcase rather than using C++20 support.
[Bug target/38595] gcc.target/mips/mips16e-extends.c fails for -mlong64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38595 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from rsandifo at gcc dot gnu.org --- It's been 12 years and noone else has taken an interest, so...
[Bug tree-optimization/93927] New: ICE: 'verify_gimple' failed (error: invalid conversion in gimple call)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93927
Bug ID: 93927
Summary: ICE: 'verify_gimple' failed (error: invalid conversion
in gimple call)
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-checking, ice-on-invalid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-10.0.1-alpha20200223 snapshot (g:3133bed5d0327e8a9cd0a601b7ecdb9de4fc825d),
9.2, 8.3, 7.3, 6.3 all ICE when compiling the following testcase w/ -fchecking:
long int
strstr (const char *, const char *);
char *
bb (char *nl)
{
return !!strstr (nl, "0") ? "0" : "1";
}
% gcc-10.0.1 -c gjtieyri.c
gjtieyri.c: In function 'bb':
gjtieyri.c:5:1: error: invalid conversion in gimple call
5 | bb (char *nl)
| ^~
long int
char *
_1 = __builtin_strchr (nl, 48);
during GIMPLE pass: lower
gjtieyri.c:5:1: internal compiler error: 'verify_gimple' failed
0xdd03ed verify_gimple_in_seq(gimple*)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/tree-cfg.c:5111
0xcad140 execute_function_todo
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/passes.c:1985
0xcade5c do_per_function
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/passes.c:1638
0xcade5c execute_todo
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/passes.c:2037
Or:
--- /home/asolokha/t1/gjtieyri.c
+++ #
@@ -1,8 +1,8 @@
long int
-strstr (const char *, const char *);
+strchr (const char *, int);
char *
bb (char *nl)
{
- return !!strstr (nl, "0") ? "0" : "1";
+ return !!strchr (nl, 0) ? "0" : "1";
}
% gcc-10.0.1 -c gjtieyri.c
gjtieyri.c: In function 'bb':
gjtieyri.c:5:1: error: type mismatch in 'pointer_plus_expr'
5 | bb (char *nl)
| ^~
long int
char *
long unsigned int
_1 = nl + D.1941;
during GIMPLE pass: lower
gjtieyri.c:5:1: internal compiler error: 'verify_gimple' failed
0xdd03ed verify_gimple_in_seq(gimple*)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/tree-cfg.c:5111
0xcad140 execute_function_todo
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/passes.c:1985
0xcade5c do_per_function
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/passes.c:1638
0xcade5c execute_todo
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/passes.c:2037
Given the age of the issue, it must have been filed already, but I failed to
find an earlier PR.
[Bug libstdc++/93923] [10 Regression] std::is_copy_constructible raises compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93923 --- Comment #1 from Jonathan Wakely --- This started to fail with r271806 which enforces a requirement from the standard that the template arguments for is_constructible must be complete types. This program violates that requirement.
[Bug middle-end/63401] "optimize" attribute overwrites other options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63401 rsandifo at gcc dot gnu.org changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #2 from rsandifo at gcc dot gnu.org --- *** Bug 38716 has been marked as a duplicate of this bug. ***
[Bug c/38716] Undocumented __attribute__((optimize)) behaviour when the attribute specifies no optimisation level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38716 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from rsandifo at gcc dot gnu.org --- Agreed that 63401 is the same thing. *** This bug has been marked as a duplicate of bug 63401 ***
[Bug tree-optimization/93927] ICE: 'verify_gimple' failed (error: invalid conversion in gimple call)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93927 Andrew Pinski changed: What|Removed |Added Depends on||93926 Known to fail|10.0, 6.3.0, 7.3.0, 8.3.0, | |9.2.0 | --- Comment #1 from Andrew Pinski --- Most likely the same underlying issue as PR 93926; even though this one is not a regression. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93926 [Bug 93926] [10 Regression] ICE: verify_cgraph_node failed (error: malloc attribute should be used for a function that returns a pointer)
[Bug c/93910] -Waddress-of-packed-member triggered without actual access to a member or the address of a member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93910 --- Comment #8 from Frederic Marchal --- Regarding the pointer vs pointeur typo in French, it will be fixed with the next translation update. Thanks for reporting it.
[Bug target/51729] dspr2-MULT.c and dspr2-MULTU.c fail for MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51729 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #4 from rsandifo at gcc dot gnu.org --- Seems unlikely that this will ever be fixed. The main point of the PR was to act as a reference point for the XFAIL, and closing the PR wouldn't affect that.
[Bug c++/93922] [10 Regression] Fails to emit inline class template destructor instantiation, but which is called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93922 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 --- Comment #4 from Jakub Jelinek --- Indeed.
[Bug ipa/93763] [10 Regression] ice in propagate_vals_across_arith_jfunc, at ipa-cp.c:2039
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93763 --- Comment #8 from David Binderman --- (In reply to CVS Commits from comment #7) > Seems the test has been badly reduced (if the original doesn't emit > warnings, it is always better in the reduction script avoid introducing > new ones). I am no expert at creduce. Any guidance on suitable flags for this case, or indeed the general case, would be most welcome. Should, for instance, -std=xyz flags be preserved ?
[Bug libstdc++/93923] [10 Regression] std::is_copy_constructible raises compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93923
--- Comment #2 from Jonathan Wakely ---
You can make the program valid by ensuring you do not try to do the
is_constructible when performing overload resolution for copy initialization of
B:
#include
class A;
template
struct B {
template
static constexpr bool not_copy_constructor_candidate
= sizeof...(Args) != 1 || (std::is_same_v && ...);
template<
class... Args,
std::enable_if_t, int> = 0,
std::enable_if_t::value, int> = 0 >
B(Args && ... args) {}
};
struct A {
A(const B&) {}
};
int main()
{
static_assert(std::is_copy_constructible::value, "");
}
I think GCC is correct to reject the original code.
[Bug target/52152] MIPS ELF targets should use dbxelf.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52152 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #4 from rsandifo at gcc dot gnu.org --- Seems unlikely that this will ever be fixed. FWIW, I agree with Steve that the best thing now would be to remove stabs support from all MIPS variants.
[Bug target/52155] loongson.h requires -flax-vector-conversions with newlib targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52155 rsandifo at gcc dot gnu.org changed: What|Removed |Added Keywords||xfail Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from rsandifo at gcc dot gnu.org --- Seems unlikely that this will ever be fixed. The main point of the PR was to act as a reference point for the XFAIL, and closing the PR wouldn't affect that.
[Bug c++/93922] Fails to emit inline class template destructor instantiation, but which is called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93922
--- Comment #2 from Andrew Pinski ---
Note here is a C++11 testcase which shows the problem and shows it is a
regression:
template struct sk_sp {
template sk_sp(sk_sp const &);
~sk_sp() {}
};
struct SkPicture {};
struct Wrapped: SkPicture {
Wrapped(SkPicture const &);
};
struct S {
sk_sp x;
Wrapped y;
};
sk_sp ref(SkPicture *);
void f(SkPicture * x, SkPicture const & y) {
new S{ref(x), y};
}
[Bug target/52154] va_arg with empty aligned structure fails for MIPS EABI32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52154 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #5 from rsandifo at gcc dot gnu.org --- That said, it doesn't seem likely that this will ever be fixed, and the PR will act as a reference point whatever state it's in, so we might as well close it anyway...
[Bug other/93912] typo: probablity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93912 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-02-25 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Created attachment 47905 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47905&action=edit gcc10-pr93912.patch Untested fix.
[Bug ipa/93763] [10 Regression] ice in propagate_vals_across_arith_jfunc, at ipa-cp.c:2039
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93763 --- Comment #9 from Arseny Solokha --- (In reply to David Binderman from comment #8) > (In reply to CVS Commits from comment #7) > > Seems the test has been badly reduced (if the original doesn't emit > > warnings, it is always better in the reduction script avoid introducing > > new ones). > > I am no expert at creduce. Any guidance on suitable flags for this > case, or indeed the general case, would be most welcome. > > Should, for instance, -std=xyz flags be preserved ? Sorry for intervening. If you ask me, I have this in my reduction script: $GCCBINARY_GOOD -w -c $GCCOPTS_GOOD $INPUTFILE || exit 1 timeout 8 $GCCBINARY_BAD -w -c $GCCOPTS_BAD $INPUTFILE > $OUTPUTFILE 2>&1 && exit 1 where $GCCBINARY_BAD obviously corresponds to a version that has an issue in question and $GCCBINARY_GOOD to a version that doesn't, similarly for the sets of flags. It works in most cases where ICEs happen on inherently valid code.
[Bug tree-optimization/93843] [10 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93843
Matthias Kretz (Vir) changed:
What|Removed |Added
CC||kretz at kde dot org
--- Comment #5 from Matthias Kretz (Vir) ---
Simpler variant. I couldn't come up with a better barrier to force the last
line to load from out than inline asm.
char in[2] = {2, 2};
short out[2] = {};
int
main()
{
for (int i = 0; i < 2; ++i)
out[i] = in[i];
asm("":::"memory");
if (out[0] != 2) __builtin_abort();
}
[Bug libstdc++/93923] [10 Regression] std::is_copy_constructible raises compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93923 --- Comment #3 from Jonathan Wakely --- Sorry, that wasn't a correct fix, I missed a ! in the variable template, and adding that means it gives an error again. I still think GCC is right to reject the program, because it has an unresolvable cycle where is_copy_constructible depends on is_constructible which is obviously recursive.
[Bug tree-optimization/93891] CSE where clobber writes the same value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93891
--- Comment #3 from Richard Biener ---
So FRE/PRE see
_91 = __MEM ((const struct A &)__first_58).p;
__MEM (__cur_59).p = _91;
_92 = __MEM (_91);
if (_92 <= 0)
goto __BB5(precise(0));
else
goto __BB6(precise(134217728));
__BB(5,precise(0)):
__builtin_unreachable ();
__BB(6,guessed_local(-1430369669)):
_93 = _92 + 1;
__MEM (_91) = _93;
_94 = __first_58->p;
_95 = __MEM (_94);
_96 = _95 + _Literal (int) -1;
__MEM (_94) = _96;
but FRE4 sees
_91 = MEM[base: __first_58, offset: _Literal (int * *) 0];
MEM[base: __cur_59, offset: _Literal (int * *) 0] = _91;
_92 = __MEM (_91);
if (_92 <= 0)
goto __BB5(precise(0));
else
goto __BB6(precise(134217728));
__BB(5,precise(0)):
__builtin_unreachable ();
__BB(6,guessed_local(-1430369669)):
_93 = _92 + 1;
__MEM (_91) = _93;
_94 = MEM[base: __first_58, offset: _Literal (int * *) 0];
_95 = __MEM (_94);
_96 = _95 + _Literal (int) -1;
__MEM (_94) = _96;
which might be enough different TBAA-wise to have the intermediate
def stmt skipped.
Ah, so we don't do
if (is_gimple_reg_type (TREE_TYPE (lhs))
&& types_compatible_p (TREE_TYPE (lhs), vr->type)
&& ref->ref)
because we've valueized something in __first_75->sp and thus ref->ref
is NULL and we need ref->ref for the alignment check. But we can
use data->orig_ref.ref then. That doesn't help it seems because
the load was entered differently in the hash table (a different vuse
via the last_vuse mechanism - that's the immediately preceeding
clobber we disambiguated against).
Ideally the hash tables would contain entries for all virtual uses
the expression is valid in but that's somewhat hard to encode
(well, maybe simply not hash the vuse and record orig and last vuse
and then do dominance checks to see if a query vuse falls in range).
First piece of a fix:
diff --git a/gcc/tree-ssa-sccvn.c b/gcc/tree-ssa-sccvn.c
index a3fba2878f8..5d78be7e9d3 100644
--- a/gcc/tree-ssa-sccvn.c
+++ b/gcc/tree-ssa-sccvn.c
@@ -2455,7 +2455,7 @@ vn_reference_lookup_3 (ao_ref *ref, tree vuse, void
*data_,
and return the found value. */
if (is_gimple_reg_type (TREE_TYPE (lhs))
&& types_compatible_p (TREE_TYPE (lhs), vr->type)
- && ref->ref)
+ && (ref->ref || data->orig_ref.ref))
{
tree *saved_last_vuse_ptr = data->last_vuse_ptr;
/* Do not update last_vuse_ptr in vn_reference_lookup_2. */
@@ -2480,7 +2480,9 @@ vn_reference_lookup_3 (ao_ref *ref, tree vuse, void
*data_,
-fno-strict-aliasing. So simply resort to alignment to
rule out overlaps. Do this check last because it is
quite expensive compared to the hash-lookup above. */
- && multiple_p (get_object_alignment (ref->ref), ref->size)
+ && multiple_p (get_object_alignment
+ (ref->ref ? ref->ref : data->orig_ref.ref),
+ref->size)
&& multiple_p (get_object_alignment (lhs), ref->size))
return res;
}
[Bug c++/93916] Implicit copy/assignment alters padding bits of storage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93916 --- Comment #5 from rguenther at suse dot de --- On Tue, 25 Feb 2020, andysem at mail dot ru wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93916 > > --- Comment #4 from andysem at mail dot ru --- > Are you saying that implementation is allowed to not preserve unused storage > state upon construction and assignment? Because I don't think this is what the > standard says. I think the standard says that upon construction of an object the previous memory state becomes indeterminate. > Is there any other way to achieve the effect of initializing padding in a > struct? The only way I see would be to do that inside the constructor but I realize that's not something you control? I think the standard also gives you no way to access the padding or guarantees anything about the paddings value which essentially means you're relying on implementation behavior.
[Bug ipa/93921] -Os generates much bigger code than -O{1,2,3,fast} for std::string::size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93921 --- Comment #5 from Jonathan Wakely --- (In reply to Bjørnar Snoksrud from comment #3) > Using '--std=c++20 -Os' generates minimal code. That disables the explicit template instantiation declarations for std::string, so the compiler performs implicit instantiations and then inlines the code. Without C++20 the compiler sees the explicit instantiation declarations (i.e. the 'extern template' declarations) and emits calls to those external definitions, without inlining anything. I think GCC needs to be better at deciding when to ignore the explicit instantiations and to do implicit instantiations anyway.
[Bug c++/93916] Implicit copy/assignment alters padding bits of storage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93916 --- Comment #6 from Jonathan Wakely --- (In reply to andysem from comment #0) > It doesn't say anything about modifying padding bits, It also doesn't say anything about leaving them with their previous values. I think your expectation is wrong.
[Bug tree-optimization/93927] ICE: 'verify_gimple' failed (error: invalid conversion in gimple call)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93927 --- Comment #2 from Jakub Jelinek --- Created attachment 47906 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47906&action=edit gcc10-pr93927.patch We could do something like this, which is what we already do in tree-ssa-strlen.c. Or change the FEs, but that might not be stage4 material.
[Bug fortran/93918] Segfault with -Ofast when calling a routine with an array argument array(:)%component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93918 --- Comment #4 from martin --- After playing around a bit I am really confused about why and when array temporaries are created. The variant ppp_1 with a non-contiguous array pointer p works fine (with -Ofast), but the variation ppp_2 (this time even with a contiguous array pointer) fails. To make it even more puzzling, variation ppp_3, where the pointer association is done in a function, works. To me it seems obscure to understand and thus avoid creation of temporary arrays. program ppp_1 use mod implicit none integer :: n integer, dimension(:,:), pointer :: a integer, dimension(:), pointer :: p n = 1 allocate(a(1:2,1:n), source=1) p => a(1,1:n) call foo(p, n) deallocate(a) end program ppp_1 program ppp_2 use mod implicit none type :: tt integer :: u = 1 end type tt type(tt), dimension(:), pointer :: r integer :: n integer, dimension(:), pointer :: p n = 1 allocate(r(1:n)) p => r(:)%u call foo(p, n) deallocate(r) end program ppp_2 program ppp_3 use mod implicit none type :: tt integer :: u = 1 end type tt type(tt), dimension(:), pointer :: r integer :: n integer, dimension(:), pointer :: p n = 1 allocate(r(1:n)) p => get(r(1:n)) call foo(p, n) deallocate(r) contains function get(x) result(q) type(tt), dimension(:), target, intent(in) :: x integer, dimension(:), pointer :: q q => x(:)%u end function get end program ppp_3
[Bug tree-optimization/93843] [10 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93843
--- Comment #6 from Andrew Pinski ---
(In reply to Matthias Kretz (Vir) from comment #5)
> Simpler variant. I couldn't come up with a better barrier to force the last
> line to load from out than inline asm.
>
> char in[2] = {2, 2};
> short out[2] = {};
>
> int
> main()
> {
> for (int i = 0; i < 2; ++i)
> out[i] = in[i];
> asm("":::"memory");
> if (out[0] != 2) __builtin_abort();
> }
__atomic_signal_fence (__ATOMIC_RELAXED) If you don't want to use inline-asm
directly (it should translate to the same thing internally though).
[Bug c++/93916] Implicit copy/assignment alters padding bits of storage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93916 --- Comment #7 from Jonathan Wakely --- (In reply to andysem from comment #4) > Are you saying that implementation is allowed to not preserve unused storage > state upon construction and assignment? Because I don't think this is what > the standard says. I disagree. It doesn't say the values of padding bits are preserved after constructing an object in that storage. > Is there any other way to achieve the effect of initializing padding in a > struct? The standard requires zero-initialization to clear all padding bits. Other forms of initialization (including copy-initialization as in your example) do not specify the effect on padding bits.
[Bug tree-optimization/93891] CSE where clobber writes the same value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93891
--- Comment #4 from Richard Biener ---
While the last_vuse thing was originally added for PRE it's also useful for
FRE as the following testcase shows:
int foo(int *p, int b, float *q)
{
int tem;
if (b)
{
*q = 0;
tem = *p;
}
else
{
*q = 1;
tem = *p;
}
return *p - tem;
}
with last_vuse fre1 manages to optimize this to return 0 while w/o it doesn't
(the key is value-numbering loads from both if arms the same).
[Bug ipa/93763] [10 Regression] ice in propagate_vals_across_arith_jfunc, at ipa-cp.c:2039
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93763
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #10 from Jakub Jelinek ---
Really depends on the original source, but e.g. if the original testcase
doesn't have any warnings, then it would be better for the reduction script to
avoid introducing new warnings (so for start don't use -w in there). Sometimes
trying to avoid e.g. introducing -Wmaybe-uninitialized warnings or similar
might prevent reduction of the testcase into something short.
Sometimes you might just want to attempt avoiding introduction of a small
selected subset of warnings, e.g. punt on (for C):
warning: data definition has no type or storage class
warning: no semicolon at end of struct or union
-Wimplicit-int
-Wimplicit-function-declaration
-Wincompatible-pointer-types
And of course, when the testcase is reduced without that, whomever creates a
patch where it adds those into the testsuite, it should be tested; if one
tweaks the test after performing a bootstrap/regtest, it might be enough to do
make check-gcc check-c++-all RUNTESTFLAGS="--target_board=unix\{-m32,-m64\}
dg.exp=pr12345*"
style testing just to make sure the test actually passes.
[Bug c++/93916] Implicit copy/assignment alters padding bits of storage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93916 --- Comment #8 from andysem at mail dot ru --- (In reply to rguent...@suse.de from comment #5) > > Is there any other way to achieve the effect of initializing padding in a > > struct? > > The only way I see would be to do that inside the constructor but I > realize that's not something you control? Exactly. Also, I don't think you can portably access padding bits, except to do memset over the object storage, like in my attempt. But then the constructor has to manually initialize all members. And that would make the class non-trivially copyable, which is not suitable in my case anyway.
[Bug c++/93916] Implicit copy/assignment alters padding bits of storage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93916 --- Comment #9 from andysem at mail dot ru --- Ok, so it seems then that what I need cannot be implemented portably. In that case, this bug can be closed. Thanks to everyone. But we do need a solution for bug #88101 (and Boost.Atomic) eventually.
[Bug libstdc++/88101] Implement P0528R3, C++20 cmpxchg and padding bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88101 --- Comment #3 from andysem at mail dot ru --- As discussed in bug #93916, the approach of zeroing the storage before constructing the object with internal padding doesn't work and is not required to work by the C++ standard.
[Bug c++/93916] Implicit copy/assignment alters padding bits of storage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93916 Richard Biener changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #10 from Richard Biener --- Invalid.
[Bug libstdc++/93872] [10 Regression] std::move(first, last, out) with a move-only value type fails to compile with -std=c++2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93872
--- Comment #2 from Jonathan Wakely ---
It looks like those parameters have always been wrong (for more than a decade
anyway). When we optimized them to a memmove for both copies and moves it
didn't matter because memmove doesn't alter the source and so it can be const.
For C++20 when std::is_constant_evaluated() is true, we do the actual
assignments in a loop, and so the value category and cv-qualifiers need to be
correct.
I'm nervous about changing the parameter types in stage 4 because it affects
all modes, not just C++20. I think the conservative fix for now is:
--- a/libstdc++-v3/include/bits/stl_algobase.h
+++ b/libstdc++-v3/include/bits/stl_algobase.h
@@ -95,7 +95,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
for(; __num > 0; --__num)
{
if constexpr (_IsMove)
- *__dst = std::move(*__src);
+ // This const_cast looks unsafe, but we only use this function
+ // for trivially-copyable types, which means this assignment
+ // is trivial and so doesn't alter the source anyway.
+ // See PR 93872 for why it's needed.
+ *__dst = std::move(*const_cast<_Tp*>(__src));
else
*__dst = *__src;
++__src;
[Bug c/93928] New: Is there any interface to define the map of two register in one pattern ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93928 Bug ID: 93928 Summary: Is there any interface to define the map of two register in one pattern ? Product: gcc Version: new-ra Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: zhongyunde at huawei dot com Target Milestone: --- for example, if the following oril insns need two register for operand0 and operand1 have an implication constraint, i.e., after register reload, the regno(operand1) = regno(operand0) + 16; (define_insn "oril" 4595 [(set (match_operand:DI 0 "register_operand" "=r") 4596 (ior:DI (match_operand:DI 1 "register_operand" "r") 4597 (match_operand:DI 2 "register_operand" "r")))] 4598 "" 4599 "oril@%.\t%0, %1, %x2" 4600 )
[Bug middle-end/93926] [10 Regression] ICE: verify_cgraph_node failed (error: malloc attribute should be used for a function that returns a pointer)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93926 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.0
[Bug c++/93905] [8 Regression] Cannot use Derived type of Base containing both enum and protected destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93905
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #7 from Jakub Jelinek ---
The reason this doesn't FAIL on 9 branch or trunk is
r9-3835-g5dab8b11c41fe72ea606c38884f7730bd2aeafdc , in particular the
@@ -5097,18 +5101,18 @@ cxx_eval_outermost_constant_expr (tree t, bool
allow_non_constant,
if (TREE_CODE (r) == CONSTRUCTOR && CLASS_TYPE_P (TREE_TYPE (r)))
{
+ r = adjust_temp_type (type, r);
if (TREE_CODE (t) == TARGET_EXPR
&& TARGET_EXPR_INITIAL (t) == r)
return t;
- else
+ else if (TREE_CODE (t) != CONSTRUCTOR)
{
r = get_target_expr (r);
TREE_CONSTANT (r) = true;
- return r;
}
}
- else
-return r;
+
+ return r;
}
/* Returns true if T is a valid subexpression of a constant expression,
hunk from it (and for this testcase the adjust_temp_type isn't even needed, it
is purely about whether we call get_target_expr if t is a CONSTRUCTOR or not.
If I call it by hand on 9 branch, I get the same error.
Jason, I'm afraid I have no idea if e.g. just the else if (TREE_CODE (t) !=
CONSTRUCTOR) part could be safely cherry-picked alone, or if more changes are
needed, https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00197.html doesn't talk
about the particular reasons for not calling get_target_expr in that case.
Reversion of the above commit is an option too, though it was a regression fix
too and we had it in 8.x for more than a year already, so some people might be
upset if NSDMIs with enums in it stop working again.
[Bug middle-end/93806] Wrong optimization: instability of floating-point results with -funsafe-math-optimizations leads to nonsense
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #27 from Vincent Lefèvre ---
(In reply to jos...@codesourcery.com from comment #26)
> I wouldn't be surprised if such a test could be constructed in the absence
> of -funsafe-math-optimizations, that does a single conversion of an
> out-of-range integer to a floating-point type in the abstract machine but
I suppose that you meant the opposite: floating-point to integer.
> where that conversion gets duplicated so that one copy is done at compile
> time (valid with -fno-trapping-math, covered by other bugs in the
> -ftrapping-math case where it loses exceptions) and the other copy is done
> at run time and the particular instruction used doesn't follow the logic
> in fold_convert_const_int_from_real of converting NaN to zero and
> saturating other values.
Yes, here's an example:
#include
__attribute__((noipa)) // imagine it in a separate TU
static double opaque(double d) { return d; }
int main (void)
{
double x = opaque(50.0);
int i;
i = x;
printf ("%d\n", i);
if (x == 50.0)
printf ("%d\n", i);
return 0;
}
With -O3, I get:
-2147483648
2147483647
Tested with:
gcc-10 (Debian 10-20200222-1) 10.0.1 20200222 (experimental) [master revision
01af7e0a0c2:487fe13f218:e99b18cf7101f205bfdd9f0f29ed51caaec52779]
[Bug libstdc++/93872] [10 Regression] std::move(first, last, out) with a move-only value type fails to compile with -std=c++2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93872 --- Comment #3 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:5b904f175ff26269615f148459a8604f45880591 commit r10-6842-g5b904f175ff26269615f148459a8604f45880591 Author: Jonathan Wakely Date: Tue Feb 25 12:21:44 2020 + libstdc++: Fix regression in std::move algorithm (PR 93872) The std::move and std::move_backward algorithms dispatch to the std::__memmove helper when appropriate. That function uses a pointer-to-const for the source values, preventing them from being moved. The two callers of that function have the same problem. Rather than altering __memmove and its callers to work with const or non-const source pointers, this takes a more conservative approach of casting away the const at the point where we want to do a move assignment. This relies on the fact that we only use __memmove when the type is trivially copyable, so we know the move assignment doesn't alter the source anyway. PR libstdc++/93872 * include/bits/stl_algobase.h (__memmove): Cast away const before doing move assignment. * testsuite/25_algorithms/move/93872.cc: New test. * testsuite/25_algorithms/move_backward/93872.cc: New test.
[Bug middle-end/93806] Wrong optimization: instability of floating-point results with -funsafe-math-optimizations leads to nonsense
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #28 from Vincent Lefèvre ---
A slightly modified version of the example, showing the issue with GCC 5 to 7
(as the noipa attribute directive has been added in GCC 8):
#include
int main (void)
{
volatile double d = 50.0;
double x = d;
int i = x;
printf ("%d\n", i);
if (x == 50.0)
printf ("%d\n", i);
return 0;
}
The -O1 optimization level is sufficient to make the bug appear.
[Bug middle-end/93806] Wrong optimization: instability of floating-point results with -funsafe-math-optimizations leads to nonsense
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806
--- Comment #29 from Vincent Lefèvre ---
And with unsigned too (this should be a bit more readable):
#include
int main (void)
{
volatile double d = -1.0;
double x = d;
unsigned int i = x;
printf ("%u\n", i);
if (x == -1.0)
printf ("%u\n", i);
return 0;
}
gives
4294967295
0
[Bug middle-end/86827] [8 Regression] -Warray-bounds produces negative indicies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86827 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com Summary|[8/9/10 Regression] |[8 Regression] |-Warray-bounds produces |-Warray-bounds produces |negative indicies |negative indicies --- Comment #10 from Jeffrey A. Law --- Martin Sebor fixed this in gcc-9
[Bug libstdc++/93872] [10 Regression] std::move(first, last, out) with a move-only value type fails to compile with -std=c++2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93872 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely --- Fixed.
[Bug middle-end/93806] Wrong optimization: instability of floating-point results with -funsafe-math-optimizations leads to nonsense
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93806 --- Comment #30 from Vincent Lefèvre --- (In reply to Vincent Lefèvre from comment #28) > A slightly modified version of the example, showing the issue with GCC 5 to > 7 (as the noipa attribute directive has been added in GCC 8): Correction: This allows to test with old GCC versions, and this shows that the bug has been introduced in GCC 6. GCC 5 outputs consistent values.
[Bug middle-end/93786] [8/9/10 Regression] gimplifier ICE with statement expression since r8-5526
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93786
--- Comment #6 from Jakub Jelinek ---
Tried:
--- gcc/gimplify.c.jj 2020-02-09 08:16:19.399581468 +0100
+++ gcc/gimplify.c 2020-02-25 13:46:51.166409528 +0100
@@ -886,7 +886,29 @@ mostly_copy_tree_r (tree *tp, int *walk_
/* Cope with the statement expression extension. */
else if (code == STATEMENT_LIST)
-;
+{
+ if (!TREE_SIDE_EFFECTS (t))
+ {
+ tree nt = NULL_TREE;
+ tree_stmt_iterator i;
+ /* With -g we can get STATEMENT_LISTs without side-effects
+that contain some debug stmts and exactly one other stmt.
+"unshare" those by extracting the single other stmt in the
+copy. */
+ for (i = tsi_start (t); !tsi_end_p (i); tsi_next (&i))
+ if (TREE_CODE (tsi_stmt (i)) == DEBUG_BEGIN_STMT)
+ ;
+ else if (nt)
+ break;
+ else
+ nt = tsi_stmt (i);
+ if (nt && tsi_end_p (i) && TREE_TYPE (t) == TREE_TYPE (nt))
+ {
+ *tp = nt;
+ mostly_copy_tree_r (tp, walk_subtrees, data);
+ }
+ }
+}
/* Leave the bulk of the work to copy_tree_r itself. */
else
and while we don't ICE anymore on the testcase, it FAILs with -fcompare-debug:
- _1 = s->_vptr.S;
+ struct S * retval.0;
+
+ # DEBUG BEGIN_STMT
+ # DEBUG BEGIN_STMT
+ retval.0 = s;
+ _1 = retval.0->_vptr.S;
gimple difference.
[Bug rtl-optimization/93908] [8/9/10 Regression] git miscompilation on s390x-linux with -O2 -march=zEC12 -mtune=z13 starting with r8-1288
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93908 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:73dc4ae47418aef2eb470b8f71cef57dce37349e commit r10-6844-g73dc4ae47418aef2eb470b8f71cef57dce37349e Author: Jakub Jelinek Date: Tue Feb 25 13:56:47 2020 +0100 combine: Fix find_split_point handling of constant store into ZERO_EXTRACT [PR93908] git is miscompiled on s390x-linux with -O2 -march=zEC12 -mtune=z13. I've managed to reduce it into the following testcase. The problem is that during combine we see the s->k = -1; bitfield store and change the SET_SRC from a pseudo into a constant: (set (zero_extract:DI (mem/j:HI (plus:DI (reg/v/f:DI 60 [ s ]) (const_int 10 [0xa])) [0 +0 S2 A16]) (const_int 2 [0x2]) (const_int 7 [0x7])) (const_int -1 [0x])) This on s390x with the above option isn't recognized as valid instruction, so find_split_point decides to handle it as IOR or IOR/AND. src is -1, mask is 3 and pos is 7. src != mask (this is also incorrect, we want to set all (both) bits in the bitfield), so we go for IOR/AND, but instead of trying mem = (mem & ~0x180) | ((-1 << 7) & 0x180) we actually try mem = (mem & ~0x180) | (-1 << 7) and that is further simplified into: mem = mem | (-1 << 7) aka mem = mem | 0xff80 which doesn't set just the 2-bit bitfield, but also many other bitfields that shouldn't be touched. We really should do: mem = mem | 0x180 instead. The problem is that we assume that no bits but those low len (2 here) will be set in the SET_SRC, but there is nothing that can prevent that, we just should ignore the other bits. The following patch fixes it by masking src with mask, this way already the src == mask test will DTRT, and as the code for or_mask uses gen_int_mode, if the most significant bit is set after shifting it left by pos, it will be properly sign-extended. 2020-02-25 Jakub Jelinek PR rtl-optimization/93908 * combine.c (find_split_point): For store into ZERO_EXTRACT, and src with mask. * gcc.c-torture/execute/pr93908.c: New test.
[Bug c/93928] Is there any interface to define the map of two register in one pattern ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93928 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Richard Biener --- bugzilla is not for development questions, please use the mailing list.
[Bug tree-optimization/93927] ICE: 'verify_gimple' failed (error: invalid conversion in gimple call)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93927 --- Comment #3 from Richard Biener --- Change the frontends. Most definitely. Finally.
[Bug rtl-optimization/93908] [8/9/10 Regression] git miscompilation on s390x-linux with -O2 -march=zEC12 -mtune=z13 starting with r8-1288
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93908 --- Comment #4 from CVS Commits --- The releases/gcc-9 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:eeb31391b7f223e6ca8cbd4452b99b55f4afdb1c commit r9-8276-geeb31391b7f223e6ca8cbd4452b99b55f4afdb1c Author: Jakub Jelinek Date: Tue Feb 25 13:56:47 2020 +0100 combine: Fix find_split_point handling of constant store into ZERO_EXTRACT [PR93908] git is miscompiled on s390x-linux with -O2 -march=zEC12 -mtune=z13. I've managed to reduce it into the following testcase. The problem is that during combine we see the s->k = -1; bitfield store and change the SET_SRC from a pseudo into a constant: (set (zero_extract:DI (mem/j:HI (plus:DI (reg/v/f:DI 60 [ s ]) (const_int 10 [0xa])) [0 +0 S2 A16]) (const_int 2 [0x2]) (const_int 7 [0x7])) (const_int -1 [0x])) This on s390x with the above option isn't recognized as valid instruction, so find_split_point decides to handle it as IOR or IOR/AND. src is -1, mask is 3 and pos is 7. src != mask (this is also incorrect, we want to set all (both) bits in the bitfield), so we go for IOR/AND, but instead of trying mem = (mem & ~0x180) | ((-1 << 7) & 0x180) we actually try mem = (mem & ~0x180) | (-1 << 7) and that is further simplified into: mem = mem | (-1 << 7) aka mem = mem | 0xff80 which doesn't set just the 2-bit bitfield, but also many other bitfields that shouldn't be touched. We really should do: mem = mem | 0x180 instead. The problem is that we assume that no bits but those low len (2 here) will be set in the SET_SRC, but there is nothing that can prevent that, we just should ignore the other bits. The following patch fixes it by masking src with mask, this way already the src == mask test will DTRT, and as the code for or_mask uses gen_int_mode, if the most significant bit is set after shifting it left by pos, it will be properly sign-extended. 2020-02-25 Jakub Jelinek PR rtl-optimization/93908 * combine.c (find_split_point): For store into ZERO_EXTRACT, and src with mask. * gcc.c-torture/execute/pr93908.c: New test.
