[Bug middle-end/94004] [8/9/10 Regression] missing -Walloca on calls to alloca due to -Wno-system-headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94004 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |8.4 --- Comment #3 from Richard Biener --- ISTR dups about -Wno-system-headers and these kind of diagnostics.
[Bug tree-optimization/88970] ICE: verify_ssa failed (error: definition in block 2 follows the use)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88970 --- Comment #3 from Arseny Solokha --- (In reply to Arseny Solokha from comment #0) > But it may have a number of duplicates already… …like recently fixed PR86216 and still open but unreproducible PR79627?
[Bug analyzer/94011] New: ICE in validate, at analyzer/region-model.cc:3727
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94011
Bug ID: 94011
Summary: ICE in validate, at analyzer/region-model.cc:3727
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
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-alpha20200301 snapshot (g:151bf47e78f5d919f6cc591d11cc1f6aff61078f)
ICEs when compiling the following testcase w/ -O1 -fanalyzer:
template DV
vu (DV j4)
{
return [j4] () { return j4 () ? j4 : throw j4 (); } ();
}
void
foo ()
{
auto n1 = [] { return nullptr; };
vu (n1);
}
% g++-10.0.1 -O1 -fanalyzer -c ubufsom0.cc
during IPA pass: analyzer
ubufsom0.cc: In lambda function:
ubufsom0.cc:4:40: internal compiler error: in validate, at
analyzer/region-model.cc:3727
4 | return [j4] () { return j4 () ? j4 : throw j4 (); } ();
|^~~
0x7dc6fd ana::region_model::validate() const
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/analyzer/region-model.cc:3727
0x135f8d7 ana::region_model::handle_unrecognized_call(gcall const*,
ana::region_model_context*)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/analyzer/region-model.cc:4494
0x133cc30 ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode
const*, gimple const*, ana::program_state*, ana::state_change*) const
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/analyzer/engine.cc:1107
0x133d3c1 ana::exploded_graph::process_node(ana::exploded_node*)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/analyzer/engine.cc:2517
0x133d8aa ana::exploded_graph::process_worklist()
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/analyzer/engine.cc:2335
0x133dfd9 ana::impl_run_checkers(ana::logger*)
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/analyzer/engine.cc:3793
0x133ea7c ana::run_checkers()
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/analyzer/engine.cc:3850
0x1333908 execute
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/analyzer/analyzer-pass.cc:84
[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 #5 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a422f68924dbe9e0d8c4b0a0acbbadeaf0965d49 commit r10-6986-ga422f68924dbe9e0d8c4b0a0acbbadeaf0965d49 Author: Jakub Jelinek Date: Tue Mar 3 07:58:12 2020 +0100 testsuite: Add testcases for already fixed PR [PR93927] 2020-03-03 Jakub Jelinek PR tree-optimization/93927 * gcc.c-torture/compile/pr93927-1.c: New test. * gcc.c-torture/compile/pr93927-2.c: New test.
[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #41 from fdlbxtqi ---
(In reply to Jonathan Wakely from comment #38)
> We could also use memcmp for std::equal when it's using std::equal_to<> or
> std::equal_to<_ValueType1> or std::equal_to<_ValueType2>, and for
> std::lexicographical_compare when it's using std::less<> or
> std::less<_ValueType1> or std::less<_ValueType2> (as long as the existing
> conditions are also met).
>
> Currently we only use memcmp when those algos are used without a comparison
> function.
And the volatile bugs haven't fixed either. The code works fine in GCC 9.0. Now
it failed to work. Even I swap the standard to C++17, it still does not work.
Does deprecate volatile work in this case in C++20?? However, even that is the
case, C++17 should still work.
#include
auto f(std::array arr)
{
decltype(arr) arr2;
std::copy(arr.begin(),arr.end(),arr2.begin());
}
https://godbolt.org/z/Tn87r5
[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059 --- Comment #39 from fdlbxtqi --- (In reply to Jonathan Wakely from comment #38) > We could also use memcmp for std::equal when it's using std::equal_to<> or > std::equal_to<_ValueType1> or std::equal_to<_ValueType2>, and for > std::lexicographical_compare when it's using std::less<> or > std::less<_ValueType1> or std::less<_ValueType2> (as long as the existing > conditions are also met). > > Currently we only use memcmp when those algos are used without a comparison > function. Hi Jonathan. Another bug I found before and you haven't fixed: https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/stl_algobase.h#L1706 const auto __c = __builtin_memcmp(&*__first1, &*__first2, __len) <=> 0; You cannot call &*__first, &*__first2 for contiguous_iterator since a lot of implementations of contiguous iterators will check bounds at debugging mode (for example MSVC's STL vector implementation). Yours will break code. __second is not allowed to dereference, that is UB. Instead, you should call to_address(__first),to_address(__second)
[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059 --- Comment #40 from fdlbxtqi --- to_address(__first),to_address(__second) to_address(__first1),to_address(__first2)
[Bug c++/94008] "use of deleted function" error when using "std::unique_ptr", std::move() and lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94008
Nicholas Krause changed:
What|Removed |Added
CC||xerofoify at gmail dot com
--- Comment #1 from Nicholas Krause ---
I tried compiling this on both clang trunk and gcc trunk on godbolt. Your
problem seems to be this:
test_lambda([test_uniq = std::move(test_uniq)] {
test_lambda([test_uniq = std::move(test_uniq)] {});
})
Your passing into std::move and then again. That's incorrect as your moving and
moving again into the test_lamba. I tried with:
test_lambda([test_uniq = test_uniq.get()]() mutable {
test_lambda([test_uniq = std::move(test_uniq)] {});
});
And this does not miscompile due to test uniq getting the actual reference
rather than the r value and going back into another r value reference. This
therefore is not a bug.
[Bug tree-optimization/94010] New: [missed optimization] -fmerge-all-constants misses simple array merging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94010
Bug ID: 94010
Summary: [missed optimization] -fmerge-all-constants misses
simple array merging
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: aleksey.covacevice at gmail dot com
Target Milestone: ---
-fmerge-all-constants misses a very simple optimization scenario involving an
array:
extern void g(const char* c);
void f() {
const char c[] = "12345";
g(c);
}
produces a local array (with or without the flag).
If `const char c[]` is replaced by `const char* c`, the above code produces a
global array as expected.
This seems to be the case in every GCC version I have tested, starting from
4.9.
[Bug libstdc++/52590] std::thread Segmentation fault static linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52590 Andrew Pinski changed: What|Removed |Added CC||fengshenjun at yeah dot net --- Comment #5 from Andrew Pinski --- *** Bug 94009 has been marked as a duplicate of this bug. ***
[Bug libstdc++/94009] program (which use condition_variable) segment fault when compile with -static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94009 Andrew Pinski changed: What|Removed |Added Resolution|INVALID |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 52590 ***
[Bug libstdc++/94009] program (which use condition_variable) segment fault when compile with -static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94009 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c++ |libstdc++ Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- There are three issues here. First is libstdc++ uses weak for the pthread library. The second issue is libpthread is not linked unless you do -pthread or -lpthread. The third and final issue is libpthread.a is not fully linked because of the first issue and libpthread.a is not an object file.
[Bug c++/94009] New: program (which use condition_variable) segment fault when compile with -static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94009
Bug ID: 94009
Summary: program (which use condition_variable) segment fault
when compile with -static
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fengshenjun at yeah dot net
Target Milestone: ---
a.out segment fault when I use condition_variable.
1、gcc version 7.4.0 (Ubuntu 7.4.0-1ubuntu1~18.04.1). gcc 9.2.0 also
2、g++ test.cpp -std=c++17 -static -g
3、./a.out
// test.cpp
#include
#include
using namespace std;
int main() {
condition_variable* cv = new condition_variable();
delete cv;
return 0;
}
[Bug c++/94008] New: "use of deleted function" error when using "std::unique_ptr", std::move() and lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94008
Bug ID: 94008
Summary: "use of deleted function" error when using
"std::unique_ptr", std::move() and lambda
Product: gcc
Version: 8.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: xxhdx1985126 at gmail dot com
Target Milestone: ---
the following code will trigger a "use of deleted function" error when
compiling:
--
#include
template
void test_lambda(Func f)
{
}
int main()
{
std::unique_ptr test_uniq = std::make_unique(0);
test_lambda([test_uniq = test_uniq.get()] () mutable {
test_lambda([test_uniq] {
});
});
test_lambda([test_uniq = std::move(test_uniq)] {
test_lambda([test_uniq = std::move(test_uniq)] {});
});
}
--
the error:
test_unique_ptr_lambda.cpp: In lambda function:
test_unique_ptr_lambda.cpp:16:19: error: use of deleted function
‘std::unique_ptr<_Tp, _Dp>::unique_ptr(const std::unique_ptr<_Tp, _Dp>&) [with
_Tp = int; _Dp = std::default_delete]’
test_lambda([test_uniq = std::move(test_uniq)] {});
^
In file included from /opt/rh/devtoolset-8/root/usr/include/c++/8/memory:80,
from test_unique_ptr_lambda.cpp:1:
/opt/rh/devtoolset-8/root/usr/include/c++/8/bits/unique_ptr.h:394:7: note:
declared here
unique_ptr(const unique_ptr&) = delete;
^~
system: CentOS 8
compile command: g++ -std=c++17 test_unique_ptr_lambda.cpp
[Bug libstdc++/94007] Appending a view into a string to the same string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94007 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- >The pointer returned may be invalidated by further calls to other member >functions that modify the object. This is not a bug. You are violating a constraint on the return value of string::data that is the pointer might become invalid while string is being modified.
[Bug libstdc++/94007] New: Appending a view into a string to the same string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94007 Bug ID: 94007 Summary: Appending a view into a string to the same string Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: philwill at fb dot com Target Milestone: --- std::string a = "...whatever..."; a.append(a.data(), a.size()); // a must now contain 2 copies of whatever it had in it before With current trunk libstdc++ this doesn't work if `a` needs to be resized during `append` because the original buffer is deallocated before the copy of the bytes being appended is performed. Anyone encountering this bug can work around it by ensuring that they have called `reserve` with an appropriate size before calling `append` so that `append` does not need to resize the buffer.
[Bug c++/90732] [9 Regression] ICE with std::apply after variable length array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90732 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jason Merrill --- Fixed for 9.3/10.
[Bug c++/16994] [meta-bug] VLA and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16994 Bug 16994 depends on bug 90732, which changed state. Bug 90732 Summary: [9 Regression] ICE with std::apply after variable length array https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90732 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/94006] Poor codegen for cond ? lval1 : lval2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94006 --- Comment #2 from Andrew Pinski --- I thought SRA would have done it. BUT it does not. The C front-end does the optimization while it is gimplifying the original tree for some reason ...
[Bug tree-optimization/94006] Poor codegen for cond ? lval1 : lval2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94006
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-03-03
Ever confirmed|0 |1
Severity|normal |enhancement
--- Comment #1 from Andrew Pinski ---
Confirmed.
Reduced testcase:
struct f
{
int t;
};
static const struct f g0 = {0};
static const struct f g1 = {-1};
struct f f1(int a, int b)
{
return a == b ? g0 : g1;
}
CUT -
NOTE the C front-end has it done correctly.
[Bug tree-optimization/90883] Generated code is worse if returned struct is unnamed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90883 --- Comment #32 from Jim Wilson --- The proposed patch looks OK to me. I suggest you submit it to gcc-patches.
[Bug tree-optimization/93986] [10 Regression] ICE in decompose, at wide-int.h:984 since r10-5451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93986 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #2 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2020-03/msg00087.html
[Bug tree-optimization/94006] New: Poor codegen for cond ? lval1 : lval2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94006
Bug ID: 94006
Summary: Poor codegen for cond ? lval1 : lval2
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
I noticed that this (compiled with -std=c++2a and any optimization level except
-O0):
#include
std::strong_ordering f1(int a, int b)
{
return a == b ? std::strong_ordering::equal
: std::strong_ordering::less;
}
compiles to:
_Z2f1ii:
cmp edi, esi
jne .L3
mov al, BYTE PTR _ZNSt15strong_ordering5equalE[rip]
ret
.L3:
mov al, BYTE PTR _ZNSt15strong_ordering4lessE[rip]
ret
_ZNSt15strong_ordering5equalE:
.zero 1
_ZNSt15strong_ordering4lessE:
.byte -1
Whereas this less readable form:
#include
std::strong_ordering f2(int a, int b)
{
return (a == b) <=> true;
}
produces much smaller code:
_Z2f2ii:
cmp edi, esi
setne al
neg eax
ret
Jason observed that it seems to be because the result of <=> is a prvalue,
whereas the ?: version is returning from lvalues.
We get similar codegen (but with a less extreme difference in size) for this:
struct A { int i; };
constexpr A a1 { 1 };
constexpr A a2 { 0 };
A f1 (int a, int b)
{
return a == b ? a1 : a2;
}
A f2 (int a, int b)
{
return A{a == b ? a1.i : a2.i};
}
The first function is obviously easier to read, but the second produces smaller
code because the two global variables are not emitted.
[Bug debug/94005] New: gcc generates wrong debug information at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94005
Bug ID: 94005
Summary: gcc generates wrong debug information at -Og
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: qrzhang at gatech dot edu
Target Milestone: ---
It appears to be a regression in gcc-9.
bisection points to g:36f6476b80ca559ff0fc436d2ab84130b
The value of l at line 11 is 153. At -Og it generates l=0. O3 and O2 works
fine.
$ gcc-trunk -v
gcc version 10.0.1 20200302 (experimental) [master revision
778a77357ca:87d8bb8fb8c:917e56a94f9d3189d7fa9d1944b7513258195887] (GCC)
#correct value:
$ gcc-trunk -g abc.c
$ gdb -x cmds -batch a.out
Breakpoint 1 at 0x4004ec: file abc.c, line 11.
Breakpoint 1, i () at abc.c:11
11l = e; // optimize_me_not()
$1 = 153
Kill the program being debugged? (y or n) [answered Y; input not from terminal]
[Inferior 1 (process 24999) killed]
#incorrect value:
$ gcc-trunk -g -Og abc.c
$ gdb -x cmds -batch a.out
Breakpoint 1 at 0x400495: file abc.c, line 11.
Breakpoint 1, i () at abc.c:11
11l = e; // optimize_me_not()
$1 = 0
Kill the program being debugged? (y or n) [answered Y; input not from terminal]
[Inferior 1 (process 32681) killed]
$ cat abc.c
int a, b = -7L;
short d;
static int e;
char f;
char g() {}
int h(c) {}
void i() {
int l;
(a && g()) > (e && h(d = 5));
f = l = b & 159;
l = e; // b here
}
int main() { i(); }
$ cat cmds
b abc.c:11
r
p l
kill
q
[Bug analyzer/93959] g++.dg/analyzer/malloc.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93959 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Should be fixed by the above commit.
[Bug analyzer/93959] g++.dg/analyzer/malloc.C FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93959 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:9f00b22f98ec0688fcd9816a03aa3f7eea58bcf7 commit r10-6981-g9f00b22f98ec0688fcd9816a03aa3f7eea58bcf7 Author: David Malcolm Date: Thu Feb 27 14:19:33 2020 -0500 analyzer: detect malloc, free, calloc within "std" [PR93959] PR analyzer/93959 reported that g++.dg/analyzer/malloc.C was failing with no output on Solaris. The issue is that there has "using std::free;", converting all the "free" calls to std::free, which fails the name-matching via is_named_call_p. This patch implements an is_std_named_call_p variant of is_named_call_p to check for the name within "std", and uses it in sm-malloc.c to check for std::malloc, std::calloc, and std::free. gcc/analyzer/ChangeLog: PR analyzer/93959 * analyzer.cc (is_std_function_p): New function. (is_std_named_call_p): New functions. * analyzer.h (is_std_named_call_p): New decl. * sm-malloc.cc (malloc_state_machine::on_stmt): Check for "std::" variants when checking for malloc, calloc and free. gcc/testsuite/ChangeLog: PR analyzer/93959 * g++.dg/analyzer/cstdlib-2.C: New test. * g++.dg/analyzer/cstdlib.C: New test.
[Bug c++/93442] [8/9 Regression] lambda in if constexpr fails to compile since r8-5529
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93442 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|8.4 |9.3 --- Comment #5 from Jason Merrill --- Fixed for 9.3/10.
[Bug c++/86917] [8/9 Regression] ICE in verify_ctor_sanity, at cp/constexpr.c:2798
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86917 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|8.4 |9.3 --- Comment #11 from Jason Merrill --- Fixed for 9.3/10.
[Bug c++/16994] [meta-bug] VLA and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16994 Bug 16994 depends on bug 88256, which changed state. Bug 88256 Summary: [8/9 Regression] ICE: Segmentation fault (in make_ssa_name_fn) with VLA cast, C++ FE missing DECL_EXPRs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88256 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/81862] [C++11][constexpr] Constructor Parenthesized Initialization of Member Array Crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81862 Bug 81862 depends on bug 86917, which changed state. Bug 86917 Summary: [8/9 Regression] ICE in verify_ctor_sanity, at cp/constexpr.c:2798 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86917 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 86917, which changed state. Bug 86917 Summary: [8/9 Regression] ICE in verify_ctor_sanity, at cp/constexpr.c:2798 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86917 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/88256] [8/9 Regression] ICE: Segmentation fault (in make_ssa_name_fn) with VLA cast, C++ FE missing DECL_EXPRs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88256 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|8.4 |9.3 --- Comment #16 from Jason Merrill --- Fixed for 9.3/10.
[Bug c++/90333] [9 Regression] Can't apply attributes to lambdas with trailing returns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90333 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jason Merrill --- Fixed for 9.3.
[Bug c++/86917] [8/9 Regression] ICE in verify_ctor_sanity, at cp/constexpr.c:2798
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86917
--- Comment #10 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:054aeaef276572c2ccbedbd7aa86046be338603c
commit r9-8324-g054aeaef276572c2ccbedbd7aa86046be338603c
Author: Jason Merrill
Date: Mon Mar 2 14:42:47 2020 -0500
c++: Fix ({ ... }) array mem-initializer.
Here, we were going down the wrong path in perform_member_init because of
the incorrect parens around the mem-initializer for the array. And then
cxx_eval_vec_init_1 didn't know what to do with a CONSTRUCTOR as the
initializer. For GCC 9, let's just fix the latter issue.
gcc/cp/ChangeLog
2020-03-02 Jason Merrill
PR c++/86917
* constexpr.c (cxx_eval_vec_init_1): Handle CONSTRUCTOR.
[Bug c++/92601] [9 Regression] error: type variant differs by TYPE_NEEDS_CONSTRUCTING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92601 --- Comment #2 from CVS Commits --- The releases/gcc-9 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:9d5df8e3221c5fe5c8aca0334655b075bd9ea556 commit r9-8321-g9d5df8e3221c5fe5c8aca0334655b075bd9ea556 Author: Jason Merrill Date: Mon Mar 2 14:42:47 2020 -0500 checking: avoid verify_type_variant crash on incomplete type. Here, we end up calling gen_type_die_with_usage for a type that's in the middle of finish_struct_1, after we set TYPE_NEEDS_CONSTRUCTING on it but before we copy all the flags to the variants--and, significantly, before we set its TYPE_SIZE. It seems reasonable to only look at TYPE_NEEDS_CONSTRUCTING on complete types, since we aren't going to try to create an object of an incomplete type any other way. gcc/ChangeLog 2020-03-02 Jason Merrill PR c++/92601 * tree.c (verify_type_variant): Only verify TYPE_NEEDS_CONSTRUCTING of complete types.
[Bug c++/90333] [9 Regression] Can't apply attributes to lambdas with trailing returns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90333 --- Comment #7 from CVS Commits --- The releases/gcc-9 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:166c024a1969ca9e77ed450fb65ce5c926a315dc commit r9-8318-g166c024a1969ca9e77ed450fb65ce5c926a315dc Author: Jason Merrill Date: Mon Mar 2 14:42:47 2020 -0500 c++: Fix attributes with lambda and trailing return type. My fix for 60503 fixed handling of C++11 attributes following the lambda-declarator. My patch for 89640 re-added support for GNU attributes, but attributes after the trailing return type were parsed as applying to the return type rather than to the function. This patch adjusts parsing of a trailing-return-type to ignore GNU attributes at the end of the declaration so that they will be applied to the declaration as a whole. I also considered parsing the attributes between the closing paren and the trailing-return-type, and tried a variety of approaches to implementing that, but I think it's better to stick with the documented rule that "An attribute specifier list may appear immediately before the comma, '=' or semicolon terminating the declaration of an identifier" Anyone disagree? Meanwhile, C++ committee discussion about the lack of any way to apply attributes to a lambda op() seems to have concluded that they should go between the introducer and declarator, so I've implemented that as well. gcc/cp/ChangeLog 2020-03-02 Jason Merrill PR c++/90333 PR c++/89640 PR c++/60503 * parser.c (cp_parser_type_specifier_seq): Don't parse attributes in a trailing return type. (cp_parser_lambda_declarator_opt): Parse C++11 attributes before parens.
[Bug c++/88256] [8/9 Regression] ICE: Segmentation fault (in make_ssa_name_fn) with VLA cast, C++ FE missing DECL_EXPRs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88256 --- Comment #15 from CVS Commits --- The releases/gcc-9 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:f137a7c6b122e524294fb792bb97d5f3b0600c4f commit r9-8322-gf137a7c6b122e524294fb792bb97d5f3b0600c4f Author: Jason Merrill Date: Mon Mar 2 14:42:47 2020 -0500 c++: Fix cast to pointer to VLA. The C front-end fixed this issue in r257620 by adding a DECL_EXPR from grokdeclarator. We don't have an easy way to do that in the C++ front-end, but it works fine to create and prepend a DECL_EXPR when we are genericizing the NOP_EXPR for the cast. The C patch wraps the DECL_EXPR in a BIND_EXPR, but that seems unnecessary in C++; this is just a hook to run gimplify_type_sizes, we aren't actually declaring anything that we need to worry about scoping for. gcc/cp/ChangeLog 2020-03-02 Jason Merrill PR c++/88256 * cp-gimplify.c (predeclare_vla): New. (cp_genericize_r) [NOP_EXPR]: Call it.
[Bug c++/90732] [9 Regression] ICE with std::apply after variable length array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90732 --- Comment #8 from CVS Commits --- The releases/gcc-9 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:1ccbda907d1fd3a202ff2bd951828cc97abb1a8d commit r9-8319-g1ccbda907d1fd3a202ff2bd951828cc97abb1a8d Author: Jason Merrill Date: Mon Mar 2 14:42:47 2020 -0500 PR c++/90732 - ICE with VLA capture and generic lambda. We were failing to handle VLA capture in tsubst_lambda_expr; initially building a DECLTYPE_TYPE for the capture and then tsubsting it doesn't give the special VLA handling. So with this patch we call add_capture again for VLAs. gcc/cp/ChangeLog 2020-03-02 Jason Merrill PR c++/90732 - ICE with VLA capture and generic lambda. * pt.c (tsubst_lambda_expr): Repeat add_capture for VLAs.
[Bug c++/89640] [9 Regression] g++ chokes on lambda with __attribute__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89640 --- Comment #11 from CVS Commits --- The releases/gcc-9 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:166c024a1969ca9e77ed450fb65ce5c926a315dc commit r9-8318-g166c024a1969ca9e77ed450fb65ce5c926a315dc Author: Jason Merrill Date: Mon Mar 2 14:42:47 2020 -0500 c++: Fix attributes with lambda and trailing return type. My fix for 60503 fixed handling of C++11 attributes following the lambda-declarator. My patch for 89640 re-added support for GNU attributes, but attributes after the trailing return type were parsed as applying to the return type rather than to the function. This patch adjusts parsing of a trailing-return-type to ignore GNU attributes at the end of the declaration so that they will be applied to the declaration as a whole. I also considered parsing the attributes between the closing paren and the trailing-return-type, and tried a variety of approaches to implementing that, but I think it's better to stick with the documented rule that "An attribute specifier list may appear immediately before the comma, '=' or semicolon terminating the declaration of an identifier" Anyone disagree? Meanwhile, C++ committee discussion about the lack of any way to apply attributes to a lambda op() seems to have concluded that they should go between the introducer and declarator, so I've implemented that as well. gcc/cp/ChangeLog 2020-03-02 Jason Merrill PR c++/90333 PR c++/89640 PR c++/60503 * parser.c (cp_parser_type_specifier_seq): Don't parse attributes in a trailing return type. (cp_parser_lambda_declarator_opt): Parse C++11 attributes before parens.
[Bug c++/60503] gcc looks for C++ attributes in the wrong place in a lambda-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60503 --- Comment #5 from CVS Commits --- The releases/gcc-9 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:166c024a1969ca9e77ed450fb65ce5c926a315dc commit r9-8318-g166c024a1969ca9e77ed450fb65ce5c926a315dc Author: Jason Merrill Date: Mon Mar 2 14:42:47 2020 -0500 c++: Fix attributes with lambda and trailing return type. My fix for 60503 fixed handling of C++11 attributes following the lambda-declarator. My patch for 89640 re-added support for GNU attributes, but attributes after the trailing return type were parsed as applying to the return type rather than to the function. This patch adjusts parsing of a trailing-return-type to ignore GNU attributes at the end of the declaration so that they will be applied to the declaration as a whole. I also considered parsing the attributes between the closing paren and the trailing-return-type, and tried a variety of approaches to implementing that, but I think it's better to stick with the documented rule that "An attribute specifier list may appear immediately before the comma, '=' or semicolon terminating the declaration of an identifier" Anyone disagree? Meanwhile, C++ committee discussion about the lack of any way to apply attributes to a lambda op() seems to have concluded that they should go between the introducer and declarator, so I've implemented that as well. gcc/cp/ChangeLog 2020-03-02 Jason Merrill PR c++/90333 PR c++/89640 PR c++/60503 * parser.c (cp_parser_type_specifier_seq): Don't parse attributes in a trailing return type. (cp_parser_lambda_declarator_opt): Parse C++11 attributes before parens.
[Bug c++/93442] [8/9 Regression] lambda in if constexpr fails to compile since r8-5529
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93442 --- Comment #4 from CVS Commits --- The releases/gcc-9 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:e83a2d943a1affc8d945430b8feca290169fe3d7 commit r9-8320-ge83a2d943a1affc8d945430b8feca290169fe3d7 Author: Jason Merrill Date: Mon Mar 2 14:42:47 2020 -0500 c++: Fix return deduction of lambda in discarded stmt. A return statement in a discarded statement is not used for return type deduction, but we still want to do deduction for a return statement in a lambda in a discarded statement. gcc/cp/ChangeLog 2020-03-02 Jason Merrill PR c++/93442 * parser.c (cp_parser_lambda_expression): Clear in_discarded_stmt.
[Bug c++/91953] [8/9 Regression] G++ rejects lambda with constexpr variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91953 --- Comment #8 from CVS Commits --- The releases/gcc-9 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:b4e53e9b3c963b1c0fe9637618dec8042764f599 commit r9-8323-gb4e53e9b3c963b1c0fe9637618dec8042764f599 Author: Jason Merrill Date: Mon Mar 2 14:42:47 2020 -0500 c++: Allow parm of empty class type in constexpr. Since copying a class object is defined in terms of the copy constructor, copying an empty class is OK even if it would otherwise not be usable in a constant expression. Relatedly, using a parameter as an lvalue is no more problematic than a local variable, and calling a member function uses the object as an lvalue. gcc/cp/ChangeLog 2020-03-02 Jason Merrill PR c++/91953 * constexpr.c (potential_constant_expression_1) [PARM_DECL]: Allow empty class type. [COMPONENT_REF]: A member function reference doesn't use the object as an rvalue.
[Bug rtl-optimization/94002] [9/10 Regression] ICE: in decompose, at rtl.h:2279 with -O -fPIC -fno-tree-dce -fno-tree-reassoc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94002 Jakub Jelinek changed: What|Removed |Added Status|WAITING |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 47954 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47954&action=edit gcc10-pr94002.patch Untested fix. Were you using -march=rv64g -mabi=lp64 or similar options if you have differently configured cross-compiler?
[Bug libfortran/93871] COTAN is slow for complex types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 --- Comment #36 from Steve Kargl --- On Mon, Mar 02, 2020 at 11:20:56AM +, thenlich at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871 > > --- Comment #35 from Thomas Henlich --- > (In reply to Steve Kargl from comment #34) > > Even this appears to have some irregularities as my exhaustive > > test in the interval [1.e-8,1) with direct call to sinf() yields > > > > This looks like a job for FMA: "Correctly rounded multiplication > by arbitrary precision constants" > (http://perso.ens-lyon.fr/jean-michel.muller/MultConstant.html) > show that it can be proven to always work. > It can also be show to be slow. :-) I spent the last few days looking into an implementation. Here is a summary of my findings. Someone, who does numerical analysis for a living and is smarter than I, may be able to do better. Exhaustive testing in the indicated intervals for "float sindf(float x)", "float cosdf(float x)", and "float tandf(float x)". The reference values are taken to be that of double (e.g., "double sindd(double x)". All tests were done with GCC 9.2.0 with FreeBSD's libm on amd64. The methods are described below. It is noted the selected algorithm should be used for all precision to minimize maintenance. The choice seems to come down to method 2 or method 4. Those methods are likely slower than method 5. The domain [1,360] is folded into [0,45] by symmetries in sine and cosine, and the computation is done by selecting sinf() or cosf(). I've only started to consider tandf(), so have only looked at [0,90] with [0,45] shown below as [45,90] get messes with tanf(x)->inf for x->90. sindf in [1, 360] --+--+--+--+--+--+ | Method 1 | Method 2 | Method 3 | Method 4 | Method 5 | --+--+--+--+--+--+ count | 70516737 | 70516737 | 70516737 | 70516737 | 70516737 | ulp > 1.0 | 101589 | 101586 | 279027 | 101599 | 303168 | ulp > 1.5 | 0| 0| 682 | 0| 79 | ulp > 1.6 | 0| 0| 9| 0| 18 | ulp > 1.7 | 0| 0| 0| 0| 3| max ulp | 1.485345 | 1.485345 | 1.621218 | 1.485345 | 1.717592 | x max ulp | 7.173496 | 7.173496 | 1.790705 | 7.173496 | 1.790707 | --+--+--+--+--+--+ cosdf in [1, 360] --+---+---+---+---+---+ | Method 1 | Method 2 | Method 3 | Method 4 | Method 5 | --+---+---+---+---+---+ count | 70516737 | 70516737 | 70516737 | 70516737 | 70516737 | ulp > 1.0 | 59680 | 59681 | 94071 | 59682 | 70892 | ulp > 1.5 | 0 | 0 | 191 | 0 | 8 | ulp > 1.6 | 0 | 0 | 0 | 0 | 0 | ulp > 1.7 | 0 | 0 | 0 | 0 | 0 | max ulp | 1.475156 | 1.475156 | 1.587572 | 1.475156 | 1.571779 | x max ulp | 88.209297 | 88.209297 | 82.834091 | 88.209297 | 86.417046 | --+---+---+---+---+---+ tandf in [1, 45] --+---+---+---+---+---+ | Method 1 | Method 2 | Method 3 | Method 4 | Method 5 | --+---+---+---+---+---+ count | 45350913 | 45350913 | 45350913 | 45350913 | 45350913 | ulp > 1.0 | 779426| 779588| 1317335 | 779423| 981293| ulp > 1.5 | 4945 | 4946 | 14704 | 4947 | 5017 | ulp > 1.6 | 796 | 794 | 4905 | 796 | 820 | ulp > 1.7 | 25| 25| 812 | 25| 33| max ulp | 1.748144 | 1.748144 | 1.947416 | 1.748144 | 1.771557 | x max ulp | 44.998692 | 44.998692 | 44.998466 | 44.998692 | 44.998627 | --+---+---+---+---+---+ Method 1: Split x = xhi + xlo and (pi/180) = shi + slo into high and low parts. For 32-bit float, the splitting has 12 bits in high parts shi and xhi, and low parts contain the trailing 12 and 24 bits in xlo and slo. The conversion from degrees to radians, is then f = slo * xlo + slo * xhi + shi * xlo + shi * xhi. Method 2: Do the multiplication of x*(pi/180) is a higher precision type. This works for 32-bit float with 53-bit double, because the multiplication provides the needed 48 bits. For higher precisions, the methods fails or will depend of software extended precision. Method 3: Break x and (pi/180) into their significands and exponents with frexpf, then multiply significands followed by scaling with scalbnf. Method 4: Split (pi/180) = shi + slo into high and low parts, then use fmaf(x, shi, slo). Method 5: Use a naive splitting of x into an integer and rema
[Bug c++/91678] [9 Regression] decltype returns wrong type under certain conditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91678 --- Comment #9 from Marek Polacek --- I'm not sure yet -- I remember issues I'd seen with the patch, but those issues were somehow resolved, so the maybe_lvalue_p bit was all that was needed on trunk. I need to do a regtest/bootstrap on 9 to see if there's anything broken by this change. If not, then this should be fine to backport.
[Bug c++/91678] [9 Regression] decltype returns wrong type under certain conditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91678 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #8 from Jason Merrill --- Marek, is this backportable for 9.3?
[Bug target/93997] [10 Regression] ICE: maximum number of generated reload insns per insn achieved (90) since r10-2156-g82534f65d86d48da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93997 Uroš Bizjak changed: What|Removed |Added Status|NEW |RESOLVED CC|ubizjak at gmail dot com | Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com --- Comment #5 from Uroš Bizjak --- .
[Bug target/93997] [10 Regression] ICE: maximum number of generated reload insns per insn achieved (90) since r10-2156-g82534f65d86d48da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93997 --- Comment #4 from Uroš Bizjak --- Fixed.
[Bug tree-optimization/93986] [10 Regression] ICE in decompose, at wide-int.h:984 since r10-5451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93986 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED CC||msebor at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org
[Bug tree-optimization/93982] [10 Regression] Assignment incorrectly omitted by -foptimize-strlen since r10-2528
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93982 Martin Sebor changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Martin Sebor --- The reported bug is fixed. Please open a new bug for the other problems.
[Bug rtl-optimization/93974] [10 Regression] ICE in decompose_normal_address, at rtlanal.c:6403 on powerpc64le-linux-gnu since r10-6762
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974 Peter Bergner changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #14 from Peter Bergner --- (In reply to Vladimir Makarov from comment #13) > Sorry, I have no good knowledge of decompose_address. The original author > is Richard Sandiford and it is even not in RA sources (it is in rtlanal.c). > > I'd recommend to ask Richard may be he has some insights or just modify to > make it work in this case. I can only say it is a sensitive code which can > affect a lot of targets if something is not done right. We had such problems > with this code in the past. Ah, ok, CCing Richard. Richard, can you comment on the findings in Comment #4? Do we just need to add support for seeing a (plus (and: ) (const int 8)) type of address or should we have never created anything like that in the first place or ???
[Bug target/93997] [10 Regression] ICE: maximum number of generated reload insns per insn achieved (90) since r10-2156-g82534f65d86d48da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93997 --- Comment #3 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:b80cbe2d8d46c8518dca2d781c8ee4d02c5ba1ed commit r10-6979-gb80cbe2d8d46c8518dca2d781c8ee4d02c5ba1ed Author: Uros Bizjak Date: Mon Mar 2 21:13:36 2020 +0100 i386: Allow only registers with VALID_INT_MODE_P modes in movstrict [PR93997] *movstrict_1 insn pattern allows only general registers, so we have to reject modes not suitable for general regs in corresponding movstrict expander. PR target/93997 * config/i386/i386.md (movstrict): Allow only registers with VALID_INT_MODE_P modes. testsuite/ChangeLog: PR target/93997 * gcc.target/i386/pr93997.c: New test.
[Bug c++/93989] [c++20] Error initializing trivial types in constexpr constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93989 --- Comment #5 from Michael de Lang --- Created attachment 47953 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47953&action=edit self-contained minimal test case I managed to reduce the test case to a single file, which also produces the two aforementioned error messages. Compile command: /home/oipo-unencrypted/Programming/gcc-build/./gcc/xg++ -shared-libgcc -B/home/oipo-unencrypted/Programming/gcc-build/./gcc -nostdinc++ -L/home/oipo-unencrypted/Programming/gcc-build/x86_64-linux-gnu/libstdc++-v3/src -L/home/oipo-unencrypted/Programming/gcc-build/x86_64-linux-gnu/libstdc++-v3/src/.libs -L/home/oipo-unencrypted/Programming/gcc-build/x86_64-linux-gnu/libstdc++-v3/libsupc++/.libs -B/opt/gcc/10/x86_64-linux-gnu/bin/ -B/opt/gcc/10/x86_64-linux-gnu/lib/ -isystem /opt/gcc/10/x86_64-linux-gnu/include -isystem /opt/gcc/10/x86_64-linux-gnu/sys-include -B/home/oipo-unencrypted/Programming/gcc-build/x86_64-linux-gnu/./libstdc++-v3/src/.libs -fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++ -I/home/oipo-unencrypted/Programming/gcc-build/x86_64-linux-gnu/libstdc++-v3/include/x86_64-linux-gnu -I/home/oipo-unencrypted/Programming/gcc-build/x86_64-linux-gnu/libstdc++-v3/include -I/home/oipo-unencrypted/Programming/gcc/libstdc++-v3/libsupc++ -I/home/oipo-unencrypted/Programming/gcc/libstdc++-v3/include/backward copy_assign_constexpr.cc-std=gnu++2a -fno-diagnostics-show-caret -fdiagnostics-color=never -Wl,--gc-sections -L/home/oipo-unencrypted/Programming/gcc-build/x86_64-linux-gnu/libstdc++-v3/src/filesystem/.libs -lm -o ./copy_assign_constexpr.exe
[Bug tree-optimization/80635] [8/9/10 regression] std::optional and bogus -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635 --- Comment #48 from Andrew Pinski --- (In reply to Jeffrey A. Law from comment #47) > Martin, yea, your patch does prevent creation of the V_C_E. That in turn > allows maybe_a$live_7 to be directly used in the conditional which in turn > allows tree-ssa-uninit.c to realize the problematic path isn't runtime > feasible and suppresses the warning. This should also work too: diff --git a/gcc/tree-sra.c b/gcc/tree-sra.c index ea8594db193..83b1d981439 100644 --- a/gcc/tree-sra.c +++ b/gcc/tree-sra.c @@ -2499,6 +2499,7 @@ analyze_access_subtree (struct access *root, struct access *parent, For integral types this means the precision has to match. Avoid assumptions based on the integral type kind, too. */ if (INTEGRAL_TYPE_P (root->type) + && TREE_CODE (root->type) != BOOLEAN_TYPE && (TREE_CODE (root->type) != INTEGER_TYPE || TYPE_PRECISION (root->type) != root->size) /* But leave bitfield accesses alone. */ CUT
[Bug tree-optimization/93982] [10 Regression] Assignment incorrectly omitted by -foptimize-strlen since r10-2528
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93982
Jakub Jelinek changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |---
--- Comment #6 from Jakub Jelinek ---
I don't really think this is fixed.
Besides the bogus hunk mentioned above (either do it unconditionally, or not at
all, what it does isn't even a good heuristics, the pointer type on the MEM_REF
first operand really is irrelevant both for the VN reasons and for because user
can as the testcase shows use other pointer types too, I'd say the
count_nonzero_bytes function isn't well designed.
The problem is that it doesn't differentiate between whether the EXP it is
looking at are the bytes that are being stored, or is a pointer which points to
those bytes. Each of those cases needs to be treated significantly
differently.
When not counting count_nonzero_bytes called recursively or from the other
count_nonzero_bytes, I see it called from handle_store twice, each time the
argument is the gimple_assign_rhs1 (store), i.e. either the constant that is
being stored (e.g. INTEGER_CST), or e.g. a MEM_REF and similarly in
handle_integral_assign where it is called with the MEM_REF that is being
loaded.
Now, count_nonzero_bytes starts with get_stridx (exp) call. This makes no
sense, that doesn't give you anything related to the bytes being stored, but to
bytes pointed by exp.
Then it goes through into the ADDR_EXPR case and just uses its operand.
Now, with the PR93829 change it at least sets nbytes to something, but
shouldn't e.g. the get_stridx call be done only if nbytes is non-zero? A clean
design would be to have separate functions, one that handles the length of the
exp bytes itself and another one that handles the case where exp points to
those bytes. Otherwise, you just need to hope zero sized objects (such as
MEM_REFs) won't appear anywhere etc.
E.g. in
void
foo (char *p)
{
char buf[16];
__builtin_memcpy (buf, "abcde", 6);
*(char **) p = &buf[0];
...
}
case get_stridx (exp) returns > 0, even when it is in any way relevant to the
store.
The native_encode_expr call should be guarded, the usual check is
CHAR_BIT == 8 && BITS_PER_UNIT == 8.
And the formatting is off, e.g. the hunk mentioned in #c3 is misindented as
whole,
const value_range_equiv *vr
= CONST_CAST (class vr_values *, rvals)
->get_value_range (si->nonzero_chars);
should have been something like:
const value_range_equiv *vr
= (CONST_CAST (class vr_values *, rvals)
->get_value_range (si->nonzero_chars));
or better
vr_values *r = CONT_CAST (vr_values *, rvals);
const value_range_equiv *vr = r->get_value_range (si->nonzero_chars);
[Bug c++/93279] [9 Regression] C++ Template substitution ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93279 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Jason Merrill --- Fixed for 9.3/10.
[Bug tree-optimization/93982] [10 Regression] Assignment incorrectly omitted by -foptimize-strlen since r10-2528
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93982 David Malcolm changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org --- Comment #5 from David Malcolm --- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92982#c4 reports Martin added test coverage added for this bug, in: https://gcc.gnu.org/g:f26688fbe441375e907f0dd2f35837681870b1f4 commit r10-6978-gf26688fbe441375e907f0dd2f35837681870b1f4 (but appears to have been typoed as PR 92982 rather than PR 93982).
[Bug tree-optimization/93982] [10 Regression] Assignment incorrectly omitted by -foptimize-strlen since r10-2528
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93982 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||msebor at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Martin Sebor --- This was caused by the same mistake as PR 93829 which is now fixed.
[Bug preprocessor/92982] cpp_string_location_reader :: m_line_table seems redundant ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92982 --- Comment #4 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:f26688fbe441375e907f0dd2f35837681870b1f4 commit r10-6978-gf26688fbe441375e907f0dd2f35837681870b1f4 Author: Martin Sebor Date: Mon Mar 2 11:49:01 2020 -0700 Add new test for PR tree-optimization/92982. gcc/testsuite/ChangeLog: PR tree-optimization/92982 * gcc.dg/strlenopt-94.c: New test.
[Bug c++/71283] Inconsistent location for C++ warning options in the manual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71283 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|msebor at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #12 from Martin Sebor --- I'm not working on this right now.
[Bug tree-optimization/80635] [8/9/10 regression] std::optional and bogus -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635 --- Comment #47 from Jeffrey A. Law --- Martin, yea, your patch does prevent creation of the V_C_E. That in turn allows maybe_a$live_7 to be directly used in the conditional which in turn allows tree-ssa-uninit.c to realize the problematic path isn't runtime feasible and suppresses the warning.
[Bug tree-optimization/93927] ICE: 'verify_gimple' failed (error: invalid conversion in gimple call)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93927 Martin Sebor changed: What|Removed |Added Status|NEW |RESOLVED CC||msebor at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Martin Sebor --- I can no longer reproduce the ICE. Bisection shows that fixing pr93926 also took care of this.
[Bug c++/93998] [10 Regression] ICE in adjust_temp_type, at cp/constexpr.c:1426
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93998 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- Created attachment 47952 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47952&action=edit gcc10-pr93998.patch This seems to work on the testcase, but haven't bootstrapped/regtested it yet.
[Bug c++/93992] fail to compile specialization of inner class with template template parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93992 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|UNCONFIRMED Assignee|jakub at gcc dot gnu.org |unassigned at gcc dot gnu.org Ever confirmed|1 |0 --- Comment #2 from Jakub Jelinek --- Oops, please ignore the last comment, it was meant for PR93998.
[Bug c++/93992] fail to compile specialization of inner class with template template parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93992 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-03-02 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Created attachment 47950 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47950&action=edit gcc10-pr93992.patch This seems to work on the testcase, but haven't bootstrapped/regtested it yet.
[Bug inline-asm/93981] No EH information generated for asm statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93981 jwjagersma at gmail dot com changed: What|Removed |Added Attachment #47941|0 |1 is obsolete|| --- Comment #14 from jwjagersma at gmail dot com --- Created attachment 47951 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47951&action=edit proposed patch v3 I went with the option to ignore these debug statements. This works for me now, I am able to build target libraries and some of my own code with -fnon-call-exceptions. However I still think it's strange that this used to work for other throwing or control statements. I feel like I'm missing something here.
[Bug c++/93958] gcc trunk supports -std=c++20 but not -std=gnu++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93958 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek --- Fixed.
[Bug c++/93958] gcc trunk supports -std=c++20 but not -std=gnu++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93958 --- Comment #2 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:e78e50d57edf4e0e49576a7a31b01477eed08223 commit r10-6977-ge78e50d57edf4e0e49576a7a31b01477eed08223 Author: Marek Polacek Date: Sat Feb 29 14:50:19 2020 -0500 c++: Add -std=gnu++20 option [PR93958] One missing bit from r10-6656. The docs and target-supports.exp already handle -std=gnu++20. 2020-03-02 Marek Polacek PR c++/93958 - add missing -std=gnu++20. * c.opt: Add -std=gnu++20.
[Bug fortran/93486] ICE on valid with nested submodules and long submodule names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93486 Andrew Benson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Andrew Benson --- Fixed by r10-6976-gf3c276aec26d9e406cc4bbf0e18b1105df63f0ee
[Bug fortran/93486] ICE on valid with nested submodules and long submodule names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93486 --- Comment #4 from CVS Commits --- The master branch has been updated by Andrew Benson : https://gcc.gnu.org/g:f3c276aec26d9e406cc4bbf0e18b1105df63f0ee commit r10-6976-gf3c276aec26d9e406cc4bbf0e18b1105df63f0ee Author: Andrew Benson Date: Mon Mar 2 17:28:35 2020 + Ensure sufficient size of variables used for module+submodule names. PR fortran/93486 * module.c: Increase size of variables used to read module names when loading interfaces from module files to permit cases where the name is the concatenation of a module and submodule name. * gfortran.dg/pr93486.f90: New test.
[Bug middle-end/94004] [8/9/10 Regression] missing -Walloca on calls to alloca due to -Wno-system-headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94004 --- Comment #2 from Martin Sebor --- Bisection points to r254630 which doesn't look related to -Walloca: commit 025d57f037ad13eb479818b677ef4be4d97b639c Author: Martin Sebor Date: Fri Nov 10 16:35:26 2017 + PR c/81117 - Improve buffer overflow checking in strncpy gcc/ChangeLog: PR c/81117 * builtins.c (compute_objsize): Handle arrays that compute_builtin_object_size likes to fail for. Make extern. * builtins.h (compute_objsize): Declare. (check_strncpy_sizes): New function. (expand_builtin_strncpy): Call check_strncpy_sizes. * gimple-fold.c (gimple_fold_builtin_strncpy): Implement -Wstringop-truncation. (gimple_fold_builtin_strncat): Same. * gimple.c (gimple_build_call_from_tree): Set call location. * tree-ssa-strlen.c (strlen_to_stridx): New global variable. (maybe_diag_bound_equal_length, is_strlen_related_p): New functions. (handle_builtin_stxncpy, handle_builtin_strncat): Same. (handle_builtin_strlen): Use strlen_to_stridx. (strlen_optimize_stmt): Handle flavors of strncat, strncpy, and stpncpy. Use strlen_to_stridx. (pass_strlen::execute): Release strlen_to_stridx. * doc/invoke.texi (-Wsizeof-pointer-memaccess): Document enhancement. (-Wstringop-truncation): Document new option. gcc/ada/ChangeLog: PR c/81117 * ada/adadecode.c (__gnat_decode): Use memcpy instead of strncpy. * ada/argv.c (__gnat_fill_arg, __gnat_fill_env): Same. gcc/c-family/ChangeLog: PR c/81117 * c-common.c (catenate_strings): Use memcpy instead of strncpy. * c-warn.c (sizeof_pointer_memaccess_warning): Handle arrays. * c.opt (-Wstringop-truncation): New option. ... From-SVN: r254630
[Bug c++/93998] [10 Regression] ICE in adjust_temp_type, at cp/constexpr.c:1426
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93998
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
But SAVE_EXPR does the same thing, so if we need to fix that, we should fix
SAVE_EXPR too.
If we didn't do:
/* If builtin_valid_in_constant_expr_p is true,
potential_constant_expression_1 has not recursed into the arguments
of the builtin, verify it here. */
if (!builtin_valid_in_constant_expr_p (fun)
|| potential_constant_expression (arg))
{
bool dummy1 = false, dummy2 = false;
arg = cxx_eval_constant_expression (&new_ctx, arg, false,
&dummy1, &dummy2);
}
during the builtin handling where we ignore the non_constant_p, we wouldn't
have this problem, so one way out of this would be to in this case record
save_exprs and if dummy1, reset them.
And yet another option is don't push to global->values or push the cleanups if
*non_constant_p.
[Bug middle-end/94004] [8/9/10 Regression] missing -Walloca on calls to alloca due to -Wno-system-headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94004
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Known to work||7.3.0
Summary|missing -Walloca on calls |[8/9/10 Regression] missing
|to alloca due to|-Walloca on calls to alloca
|-Wno-system-headers |due to -Wno-system-headers
Known to fail||10.0, 8.2.0, 9.1.0
--- Comment #1 from Martin Sebor ---
GCC 7 issues a warning for each call to alloca, but GCC 8 diagnoses just the
__builtin_alloca call and not the one to alloca, making this a regression.
$ cat t.c && gcc-7 -S -O -Walloca-larger-than=8 t.c
#include
void f (void*, ...);
void g (int n)
{
if (n < 8)
n = 8;
char *p = (char*) __builtin_alloca (n);
f (p, 0);
}
void h (int n)
{
if (n < 9)
n = 9;
char *p = (char*) alloca (n);
f (p, 1);
}
t.c: In function ‘g’:
t.c:9:9: warning: unbounded use of ‘alloca’ [-Walloca-larger-than=]
char *p = (char*) __builtin_alloca (n);
^
t.c: In function ‘h’:
t.c:17:9: warning: unbounded use of ‘alloca’ [-Walloca-larger-than=]
char *p = (char*) alloca (n);
^
[Bug tree-optimization/93971] std::string considered to alias declared objects of incompatible types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93971 --- Comment #10 from Jonathan Wakely --- Using std::string as a dynamically-resizable buffer of bytes isn't completely unreasonable, although I can't see many reasons to prefer std::string to std::vector for that purpose. For either type, it might already be undefined because the placement new would begin the lifetime of a new object at that location, leading to undefined behaviour when the container destroys its elements, because there are no longer active char objects there (even if such destruction is trivial and doesn't actually execute any code). On the other hand, it could be argued that it's fine as long as the user recreates chars there before the container is resized/deallocated. So the compiler has to allow the placement new if it can't prove the user never restores objects of the right type. Yuck. I think asking LWG to decide whether we want to outlaw that for std::string would make sense.
[Bug libstdc++/93972] ranges::lexicographical_compare gives wrong answer for signed integers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93972 --- Comment #5 from Jonathan Wakely --- Even more fixed now.
[Bug rtl-optimization/94002] [9/10 Regression] ICE: in decompose, at rtl.h:2279 with -O -fPIC -fno-tree-dce -fno-tree-reassoc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94002 --- Comment #2 from Zdenek Sojka --- Thanks for checking this; I can reproduce this with r10-6970 with "yes-only" checking: $ riscv64-unknown-linux-gnu-gcc -O -fPIC -fno-tree-dce -fno-tree-reassoc testcase.c -wrapper valgrind,-q during RTL pass: ira testcase.c: In function 'foo': testcase.c:8:1: internal compiler error: in decompose, at rtl.h:2279 8 | } | ^ Please submit a full bug report, with preprocessed source if appropriate. See <https://gcc.gnu.org/bugs/> for instructions. $ riscv64-unknown-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-riscv64/bin/riscv64-unknown-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-20200302132420-gac3148a3d7d-checking-yes-riscv64/bin/../libexec/gcc/riscv64-unknown-linux-gnu/10.0.1/lto-wrapper Target: riscv64-unknown-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes --with-cloog --with-ppl --with-isl --with-sysroot=/usr/riscv64-unknown-linux-gnu --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=riscv64-unknown-linux-gnu --with-ld=/usr/bin/riscv64-unknown-linux-gnu-ld --with-as=/usr/bin/riscv64-unknown-linux-gnu-as --disable-multilib --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-20200302132420-gac3148a3d7d-checking-yes-riscv64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.0.1 20200302 (experimental) (GCC) I verified I uploaded the correct testcase. $ md5sum testcase.c 7bb83f9b5b51256c6151de99df6d6d58 testcase.c
[Bug libstdc++/93972] ranges::lexicographical_compare gives wrong answer for signed integers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93972 --- Comment #4 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:d112e173ea093f55a16a14b26ef65088381ee09c commit r10-6975-gd112e173ea093f55a16a14b26ef65088381ee09c Author: Jonathan Wakely Date: Mon Mar 2 17:03:28 2020 + libstdc++: Fix std::lexicographic_compare for unsigned char (PR 93972) The new 25_algorithms/lexicographical_compare/93972.cc test fails on targets where char is unsigned, revealing an existing regression with the std::__memcmp helper that had gone unnoticed in std::lexicographical_compare. When comparing char and unsigned char, the memcmp optimisation is enabled, but the new std::__memcmp function fails to compile for mismatched types. PR libstdc++/93972 * include/bits/stl_algobase.h (__memcmp): Allow pointer types to differ. * testsuite/25_algorithms/lexicographical_compare/uchar.cc: New test.
[Bug c++/94003] is_constructible seems to have sideeffects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94003 --- Comment #1 from Julius Hülsmann --- Created attachment 47949 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47949&action=edit preprocessed file (g++ --save-temps file.cc) This contains the preprocessed file generated via g++ --save-templs file.cc of the source code snipplet from my original report.
[Bug middle-end/94004] New: missing -Walloca on calls to alloca due to -Wno-system-headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94004
Bug ID: 94004
Summary: missing -Walloca on calls to alloca due to
-Wno-system-headers
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
When alloca is a macro defined in a system header like (for example
in Glibc), the -Walloca and -Walloca-larger-than= don't point out offending
calls to alloca unless -Wsystem-headers is also set.
$ cat t.c && gcc -S -O2 -Walloca-larger-than=8 t.c
#include
void f (void*, ...);
void g (int n)
{
if (n < 8)
n = 8;
char *p = (char*) __builtin_alloca (n); // warning (good)
f (p, 0);
}
void h (int n)
{
if (n < 9)
n = 9;
char *p = (char*) alloca (n); // missing warning
f (p, 1);
}
t.c: In function ‘g’:
t.c:9:21: warning: argument to ‘alloca’ may be too large
[-Walloca-larger-than=]
9 | char *p = (char*) __builtin_alloca (n);
| ^~~~
t.c:9:21: note: limit is 8 bytes, but argument may be as large as 2147483647
When -Wsystem-headers is also set on the command line GCC diagnoses both calls
as expected:
t.c:9:21: warning: argument to ‘alloca’ may be too large
[-Walloca-larger-than=]
9 | char *p = (char*) __builtin_alloca (n);
| ^~~~
t.c:9:21: note: limit is 8 bytes, but argument may be as large as 2147483647
In file included from t.c:1:
t.c: In function ‘h’:
t.c:17:21: warning: argument to ‘alloca’ may be too large
[-Walloca-larger-than=]
17 | char *p = (char*) alloca (n);
| ^~
t.c:17:21: note: limit is 8 bytes, but argument may be as large as 2147483647
[Bug c++/94003] New: is_constructible seems to have sideeffects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94003
Bug ID: 94003
Summary: is_constructible seems to have sideeffects
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: julius_huelsmann at freenet dot de
Target Milestone: ---
When executing the following code
#include
```c++
class Class { Class() {} };
template static bool why() { return
std::is_constructible::value; }
int main() { return std::is_constructible::value; }
```
the is_constructible returns true (which -- as I understand it -- should not be
the case as `Class` has a private constructor. When commenting out the static
templated function why, the return value of is_constructible changes. This
cannot be intended.
The following behavior is observed:
- when using is_constructible_v instead of is_constructible, the result is 1
and does not change
- the bug appears to only occus when declaring a templated static function
"above" the first check of is_constructible
[Bug fortran/93832] [8/9/10 Regression] ICE in gfc_convert_to_structure_constructor, at fortran/primary.c:3100
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93832
markeggleston at gcc dot gnu.org changed:
What|Removed |Added
CC||markeggleston at gcc dot
gnu.org
--- Comment #3 from markeggleston at gcc dot gnu.org ---
Using the patch comment 2 and the example program:
program p
type t
character :: a
integer :: b
integer :: c(t(1))
end type
type(t) :: z = t('a', 2, [3])
end
5 | integer :: c(t(1))
|1
Error: No initializer for component 'b' given in the structure constructor at
(1)
Adding a second initializer:
program p
type t
character :: a
integer :: b
integer :: c(t(1, "rubbish"))
end type
type(t) :: z = t('a', 2, [3])
end
5 | integer :: c(t(1))
|1
Error: No initializer for component 'c' given in the structure constructor at
(1)
There is no reporting of incompatible types i.e, integer(4) to character(1) and
character(7) to integer(4).
Finally if all initializers are given:
program p
type t
character :: a
integer :: b
integer :: c(t(1, "rubbish", 7.5))
end type
type(t) :: z = t('a', 2, [3])
end
The result is an ICE without a call stack:
gfortran: internal compiler error: Segmentation fault signal terminated program
f951
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug tree-optimization/93971] std::string considered to alias declared objects of incompatible types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93971
--- Comment #9 from Martin Sebor ---
The possibility of storing something other than char in std::string never
entered my mind, and I'm pretty sure the container was never meant for that.
But whether the standard has all the restrictions in place to rule it out is a
different question. If accommodating this use case is a serious concern then
getting a clarification from WG21 would seem advisable.
Richard's example (slightly modified to avoid const errors):
std::string s { "x" };
char *p = &s[0];
*p = s[0];
certainly has to work, just as it or the equivalent version using vector:
std::vector v { 7 };
int *p = v.data ();
*p = v[0];
works. What I'd like to do is prevent stores to the string (like 's[0] = 0'
i.e., those involving the container or pointers that can be traced to it) from
being treated as if they might modify any object in the program just because
s._M_dataplus._M_p happens to be a char*. (That seems like an implementation
detail that should be possible to change to something unrelated like struct
std::string::_Foo*.)
[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059 --- Comment #38 from Jonathan Wakely --- We could also use memcmp for std::equal when it's using std::equal_to<> or std::equal_to<_ValueType1> or std::equal_to<_ValueType2>, and for std::lexicographical_compare when it's using std::less<> or std::less<_ValueType1> or std::less<_ValueType2> (as long as the existing conditions are also met). Currently we only use memcmp when those algos are used without a comparison function.
[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059 --- Comment #37 from Jonathan Wakely --- Similarly, the condition for using memcmp in std::equal is too strict: typedef typename iterator_traits<_II1>::value_type _ValueType1; typedef typename iterator_traits<_II2>::value_type _ValueType2; const bool __simple = ((__is_integer<_ValueType1>::__value || __is_pointer<_ValueType1>::__value) && __is_pointer<_II1>::__value && __is_pointer<_II2>::__value && __are_same<_ValueType1, _ValueType2>::__value); If the types are integers of the same size and same signedness then we can use memcmp, they don't have to be exactly the same type. And for lexicographical_compare we have: typedef typename iterator_traits<_II1>::value_type _ValueType1; typedef typename iterator_traits<_II2>::value_type _ValueType2; const bool __simple = (__is_byte<_ValueType1>::__value && __is_byte<_ValueType2>::__value && !__gnu_cxx::__numeric_traits<_ValueType1>::__is_signed && !__gnu_cxx::__numeric_traits<_ValueType2>::__is_signed && __is_pointer<_II1>::__value && __is_pointer<_II2>::__value); On big endian targets we could also use memcmp for unsigned integer types larger than one byte.
[Bug rtl-optimization/93974] [10 Regression] ICE in decompose_normal_address, at rtlanal.c:6403 on powerpc64le-linux-gnu since r10-6762
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974 --- Comment #13 from Vladimir Makarov --- (In reply to Peter Bergner from comment #4) > I'm CCing Vlad, since I need some guidance/help for some LRA questions. > > Vlad, do you have some guidance on what should be done when we see > an address like the above? I tried hacking some changes to recognize > the extra PLUS, but ended up causing an infinite loop in LRA. > Do you have thoughts on how to fix this properly? Sorry, I have no good knowledge of decompose_address. The original author is Richard Sandiford and it is even not in RA sources (it is in rtlanal.c). I'd recommend to ask Richard may be he has some insights or just modify to make it work in this case. I can only say it is a sensitive code which can affect a lot of targets if something is not done right. We had such problems with this code in the past.
[Bug inline-asm/93981] No EH information generated for asm statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93981 --- Comment #13 from jwjagersma at gmail dot com --- Is there some point at which debug statements are supposed to be copied over to the next BBs? That appears to be what maybe_move_debug_stmts_to_successors (tree-inline.c:2799) does, but it is only called for inlined functions. Or alternatively, should mark_reachable_handlers and verify_gimple_in_cfg be made to ignore the debug statement, by using gsi_last_nondebug_bb?
[Bug c++/93998] [10 Regression] ICE in adjust_temp_type, at cp/constexpr.c:1426
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93998
--- Comment #4 from Marek Polacek ---
It's the new
5452 /* Avoid evaluating a TARGET_EXPR more than once. */
5453 if (tree *p = ctx->global->values.get (TARGET_EXPR_SLOT (t)))
5454 {
5455 if (lval)
5456 return TARGET_EXPR_SLOT (t);
5457 r = *p;
5458 break;
5459 }
hunk. Before it, when op1 of the TARGET_EXPR was *non_constant_p, we returned
the whole TARGET_EXPR, now we return its op1 even when the evaluation would be
*non_constant_p.
[Bug libstdc++/86976] [meta-bug] Issues with std::time_get, std::time_put etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86976 Bug 86976 depends on bug 93991, which changed state. Bug 93991 Summary: FAIL: 22_locale/time_get/get_time/char/2.cc execution test - 'errorstate == ios_base::eofbit' failed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93991 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug libstdc++/93991] FAIL: 22_locale/time_get/get_time/char/2.cc execution test - 'errorstate == ios_base::eofbit' failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93991 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=71367 Resolution|--- |DUPLICATE --- Comment #3 from Jonathan Wakely --- I misremembered. Recent versions of glibc use %p in the T_FMT string, and libstdc++ doesn't support %p yet. That's Bug 71367 and Bug 71637 comment 1 mentions these FAILs. *** This bug has been marked as a duplicate of bug 71367 ***
[Bug libstdc++/71367] std::time_get does not implement 'r' or 'p'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71367 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=93991 CC||danglin at gcc dot gnu.org --- Comment #4 from Jonathan Wakely --- *** Bug 93991 has been marked as a duplicate of this bug. ***
[Bug fortran/92305] [10 regression] libgomp.fortran/use_device_addr-1.f90 fails starting with r277606
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92305 Thomas Schwinge changed: What|Removed |Added Assignee|burnus at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #21 from Thomas Schwinge --- For posterity: (In reply to CVS Commits from comment #19) > The following patch fixes > -FAIL: libgomp.fortran/use_device_addr-1.f90 -O0 execution test > -FAIL: libgomp.fortran/use_device_addr-2.f90 -O0 execution test > that has been FAILing for several months on powerpc64le-linux. Likewise for the 'libgomp.fortran/use_device_ptr-optional-3.f90' execution test for '-O0', given 'dg-do run' added (I'll commit that later). And, for nvptx target, this also fixes 'gfortran.dg/optional_absent_3.f90' for '-O0', which was: ptxas /tmp/cc5Ae8i1.o, line 72; error : Arguments mismatch for instruction 'mov' [...] ptxas /tmp/cc5Ae8i1.o, line 615; error : Arguments mismatch for instruction 'mov' ptxas /tmp/cc5Ae8i1.o, line 627; error : State space mismatch between instruction and address in instruction 'st' [...] ptxas /tmp/cc5Ae8i1.o, line 1046; error : State space mismatch between instruction and address in instruction 'st' ptxas /tmp/cc5Ae8i1.o, line 72; error : Unknown symbol '%ar3' ptxas /tmp/cc5Ae8i1.o, line 72; error : Label expected for forward reference of '%ar3' [...] ptxas /tmp/cc5Ae8i1.o, line 615; error : Unknown symbol '%ar12' ptxas /tmp/cc5Ae8i1.o, line 615; error : Label expected for forward reference of '%ar12' ptxas /tmp/cc5Ae8i1.o, line 627; error : Unknown symbol '%stack' ptxas /tmp/cc5Ae8i1.o, line 627; error : Label expected for forward reference of '%stack' [...] ptxas /tmp/cc5Ae8i1.o, line 1046; error : Unknown symbol '%stack' ptxas /tmp/cc5Ae8i1.o, line 1046; error : Label expected for forward reference of '%stack' ptxas fatal : Ptx assembly aborted due to errors nvptx-as: ptxas returned 255 exit status compiler exited with status 1
[Bug fortran/92844] [10 regression] libgomp.fortran/use_device_ptr-optional-2.f90 fails after r279004
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92844 Thomas Schwinge changed: What|Removed |Added Keywords||openmp CC||tschwinge at gcc dot gnu.org Component|libgomp |fortran Assignee|unassigned at gcc dot gnu.org |burnus at gcc dot gnu.org --- Comment #7 from Thomas Schwinge --- For posterity: (In reply to Tobias Burnus from comment #1) > I think that is or could be a duplicate of PR 92305. No, per my logs, this one here you already fixed in r279858 "Fortran] OpenMP/OpenACC – fix more issues with OPTIONAL". (In reply to seurer from comment #6) > I see no failures after 2020-02-01. ACK. :-)
[Bug libstdc++/93991] FAIL: 22_locale/time_get/get_time/char/2.cc execution test - 'errorstate == ios_base::eofbit' failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93991 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-03-02 Blocks||86976 Ever confirmed|0 |1 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86976 [Bug 86976] [meta-bug] Issues with std::time_get, std::time_put etc.
[Bug libstdc++/93991] FAIL: 22_locale/time_get/get_time/char/2.cc execution test - 'errorstate == ios_base::eofbit' failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93991 Jonathan Wakely changed: What|Removed |Added Target|hppa-unknown-linux-gnu |*-*-linux-gnu Host|hppa-unknown-linux-gnu |*-*-linux-gnu Build|hppa-unknown-linux-gnu |*-*-linux-gnu --- Comment #2 from Jonathan Wakely --- (In reply to John David Anglin from comment #1) > Revision 275589 was okay. I don't think it was, because I've been seeing these failures on recent Fedora versions for much longer than that. I think what's changed since then is you've updated your glibc. IIRC the problem is that recent versions of glibc use multibyte UTF-8 strings for some nl_langinfo strings, and libstdc++ can't handle them because it expects a single byte. Something like that anyway.
[Bug inline-asm/93981] No EH information generated for asm statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93981 --- Comment #12 from Richard Biener --- (In reply to jwjagersma from comment #11) > (In reply to Richard Biener from comment #10) > > Some stmt-ends-BB predicates are probably off for asms. > > For stmt_ends_bb_p (tree-cfg.c:2763) the call chain looks like this: > > stmt_ends_bb_p -> is_ctrl_altering_stmt -> stmt_can_throw_internal -> > stmt_could_throw_p -> gimple_asm_volatile_p > > So volatile asms are considered bb-enders, now that they have a landing > pad, which stmt_can_throw_internal checks for. I am not sure how > that works actually, do all throwing statements get a landing pad at > first, even if there is no try block? Because that looks to be the > case, I assume these are eliminated in some later pass. > > Using gdb I found that the DEBUG stmt is added in rewrite_stmt > (tree-into-ssa.c:1417) which does so without considering if the bb has > an EH edge or not. How does this work for other throwing statements? I guess it's a "first" for this case... I'd say it should be reproducible with call exceptions and a register LHS?!
[Bug tree-optimization/93946] Bogus redundant store removal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93946 --- Comment #6 from Richard Biener --- Created attachment 47948 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47948&action=edit DSE part I'm now testing the combined (and will squash if that succeeds).
[Bug rtl-optimization/94002] [9/10 Regression] ICE: in decompose, at rtl.h:2279 with -O -fPIC -fno-tree-dce -fno-tree-reassoc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94002 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.3
[Bug tree-optimization/93946] Bogus redundant store removal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93946 Richard Biener changed: What|Removed |Added Attachment #47922|0 |1 is obsolete|| --- Comment #5 from Richard Biener --- Created attachment 47947 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47947&action=edit patch w/o RTL DSE
[Bug c++/93998] [10 Regression] ICE in adjust_temp_type, at cp/constexpr.c:1426
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93998 --- Comment #3 from Viktor Ostashevskyi --- Bisected to: ee1de08d4d22648cf3168caa60e283135755da85 is the first bad commit commit ee1de08d4d22648cf3168caa60e283135755da85 Author: Jakub Jelinek Date: Tue Dec 3 20:27:47 2019 +0100 re PR c++/91369 (Implement P0784R7: constexpr new) PR c++/91369 * constexpr.c (struct constexpr_global_ctx): Add cleanups member, initialize it in the ctor. (cxx_eval_constant_expression) : If TARGET_EXPR_SLOT is already in the values hash_map, don't evaluate it again. Put TARGET_EXPR_SLOT into hash_map even if not lval, and push it into save_exprs too. If there is TARGET_EXPR_CLEANUP and not CLEANUP_EH_ONLY, push the cleanup to cleanups vector. : Save outer cleanups, set cleanups to local auto_vec, after evaluating the body evaluate cleanups and restore previous cleanups. : Don't crash if the first operand is NULL_TREE. (cxx_eval_outermost_constant_expr): Set cleanups to local auto_vec, after evaluating the expression evaluate cleanups. * g++.dg/cpp2a/constexpr-new8.C: New test. From-SVN: r278945
[Bug ipa/94001] [10 Regression] ICE: in fold_convert_loc, at fold-const.c:2435 at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94001 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.0
