[Bug middle-end/96625] Unnecessarily large assembly generated when a bit-offsetted higher-end end of a uint64_t-backed bitfield is shifted toward the high end (left) by its bit-offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96625 --- Comment #1 from Hongtao.liu --- movabs rax,0x1ff8 --- it also clear high 3 bits. andrax,rdi differs from andrax,0xfff8 using g++ -O2 test.c -S got --- movq%rdi, %rax andq$-8, %rax ret --- but gcc -O2 test.c -S got --- movabsq $2305843009213693944, %rax (1FF8₁₆) andq%rdi, %rax ret --- Is this related to language standard?
[Bug c++/81043] [concepts] partially specializing on differing constraints gives cryptic error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81043 Mike Detwiler changed: What|Removed |Added CC||shazamancan at gmail dot com --- Comment #2 from Mike Detwiler --- I would like to share a temporary workaround that I have developed for this. Consider the usual pattern for writing a partial specialization: original decl: template class my_class; specialization: template class my_class; If ORIGINAL_PARAMS, SPECIAL_PARAMS, and MODIFIED_PARAMS are all identical, then it is an error, as it should be. Example of a true error: template class my_class; template // <-- identical to ORIGINAL_PARAMS class my_class; // <-- T is unmodified, so MODIFIED_PARAMS is also identical All three *PARAMS are identical, so it is an error. Example of a true non-error: template class my_class; template // <-- identical to ORIGINAL_PARAMS class my_class; // <-- T is modified, so MODIFIED_PARAMS is NOT identical Not all three *PARAMS are identical, so it is not an error. Another example of a true non-error: template concept C = (sizeof(T) <= 4); template class my_class; template // <-- NOT identical to ORIGINAL_PARAMS (typename vs C) class my_class; // <-- T is unmodified, so MODIFIED_PARAMS is also identical
[Bug c++/81043] [concepts] partially specializing on differing constraints gives cryptic error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81043 --- Comment #3 from Mike Detwiler --- I would like to share a temporary workaround that I have developed for this. Consider the usual pattern for writing a partial specialization: original decl: template class my_class; specialization: template class my_class; If ORIGINAL_PARAMS, SPECIAL_PARAMS, and MODIFIED_PARAMS are all identical, then it is an error, as it should be. Example of a true error: template class my_class; template // <-- identical to ORIGINAL_PARAMS class my_class; // <-- T is unmodified, so MODIFIED_PARAMS is also identical All three *PARAMS are identical, so it is an error. Example of a true non-error: template class my_class; template // <-- identical to ORIGINAL_PARAMS class my_class; // <-- T is modified, so MODIFIED_PARAMS is NOT identical Not all three *PARAMS are identical, so it is not an error. Another example of a true non-error: template concept C = (sizeof(T) <= 4); template class my_class; template // <-- NOT identical to ORIGINAL_PARAMS (typename vs C) class my_class; // <-- T is unmodified, so MODIFIED_PARAMS is identical Since not all three *PARAMS are identical it is not an error. Now for the tird and final example of a true non-error (that GCC reports as a false error due to this bug): template concept C0 = (sizeof(T) <= 4); template concept C1 = (sizeof(T) > 4); template class my_class; template // <-- NOT identical to ORIGINAL_PARAMS (typename vs C0) class my_class; // <-- T is unmodified, so MODIFIED_PARAMS is identical template // <-- NOT identical to ORIGINAL_PARAMS (typename vs C1) class my_class; // <-- T is unmodified, so MODIFIED_PARAMS is identical **BUT notice: MODIFIED_PARAMS for the first and second specialization are identical Neither partial specialization is an error because not all three *PARAMS are identical in each specialization. GCC gets confused and reports this as an error though. GCC only gets confused and falsely reports an error when two or more specializations have identical MODIFIED_PARAMS like in the third example. So my workaround is as follows: #include template concept C0 = (sizeof(T) <= 4); template concept C1 = (sizeof(T) > 4); template using spec_id = void; template class my_class; template class my_class>; template class my_class>; If you have two or more specializations where MODIFIED_PARAMS would be unmodified like in the third example, you have to use spec_id with unique N for each specialization. spec_id is NOT necessary if for the following additional specializations (so just pass void directly): template class my_class; template class my_class; This is because MODIFIED_PARAMS for these two is not identical to any other MODIFIED_PARAMS in some other specialization.
[Bug libstdc++/96645] New: std::variant default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645
Bug ID: 96645
Summary: std::variant default constructor
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: dev at hrookami dot icu
Target Milestone: ---
Appears in version 9 and above.
Flags: -std=c++17
Code:
#include
void testVariant()
{
struct DataWithVariant {
using Member = std::variant;
Member d;
};
auto d = DataWithVariant{};
}
void testVarStruct()
{
struct DataWithStruct {
struct A {
int number = 5; // compiles, if remove initialization
};
struct B {
bool flag = false;
};
using Member = std::variant;
Member data;
};
auto d = DataWithStruct{};
}
int main() {
testVariant();
testVarStruct();
}
Compiler output:
: In function 'void testVarStruct()':
:26:29: error: use of deleted function 'std::variant<_Types>::variant()
[with _Types = {testVarStruct()::DataWithStruct::A,
testVarStruct()::DataWithStruct::B}]'
26 | auto d = DataWithStruct{};
| ^
In file included from :1:
/opt/compiler-explorer/gcc-9.1.0/include/c++/9.1.0/variant:1287:7: note:
'std::variant<_Types>::variant() [with _Types =
{testVarStruct()::DataWithStruct::A, testVarStruct()::DataWithStruct::B}]' is
implicitly deleted because the default definition would be ill-formed:
1287 | variant() = default;
| ^~~
/opt/compiler-explorer/gcc-9.1.0/include/c++/9.1.0/variant:1287:7: error: use
of deleted function 'constexpr std::_Enable_default_constructor::_Enable_default_constructor() [with _Tag =
std::variant]'
In file included from
/opt/compiler-explorer/gcc-9.1.0/include/c++/9.1.0/variant:38,
from :1:
/opt/compiler-explorer/gcc-9.1.0/include/c++/9.1.0/bits/enable_special_members.h:110:15:
note: declared here
110 | constexpr _Enable_default_constructor() noexcept = delete;
| ^~~
It compiles if move nested structs in global namespace or remove initializer.
[Bug tree-optimization/96633] missed optimization?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96633 Martin Liška changed: What|Removed |Added Last reconfirmed||2020-08-17 Status|UNCONFIRMED |NEW Keywords||missed-optimization CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Nice trick! Generally speaking about the optimization (for longer types), it can be tricky as: shr$6, %ecx can be bigger than 64 and so shrq%cl, %rax can result in undefined behavior as 1 << X, where X > 64.
[Bug gcov-profile/96622] gcov misses to count break statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96622
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #2 from Martin Liška ---
Please use -O0 for more precise gcov instrumentation:
-:0:Source:my_strndup.c
-:1:#include
-:2:#include
-:3:#include
-:4:
3:5:void *my_strndup(const char *s, size_t n)
-:6:{
3:7:size_t len = 0;
23:8:for (len = 0; len < n; len++)
22:9:if (s[len] == '\0')
2: 10:break;
-: 11:
3: 12:char *p = malloc(len + 1);
3*: 13:assert(p);
-: 14:
3: 15:memcpy(p, s, len);
3: 16:p[len] = '\0';
-: 17:
3: 18:return p;
-: 19:}
[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137 --- Comment #35 from Iain Sandoe --- (In reply to niek from comment #34) > Any progress on this issue? > > (The issue is still present in gcc-trunk...) I have a couple of ideas, but very short of time to try them out, sorry about that.
[Bug analyzer/96646] New: [11 Regression] ICE: Segmentation fault (in tree_class_check)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96646
Bug ID: 96646
Summary: [11 Regression] ICE: Segmentation fault (in
tree_class_check)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-11.0.0-alpha20200816 snapshot (g:c99116aeeb9644ebddec653ee8b19de4d38b65bd)
ICEs when compiling the following testcase w/ -O1 -fanalyzer:
struct zx {
struct zx *b4, *g0;
};
struct oo {
int ph;
struct zx el;
};
inline void
k7 (struct zx *xj)
{
xj->b4->g0 = 0;
xj->b4 = 0;
}
void
n8 (struct oo *yx)
{
k7 (&yx->el);
n8 (yx);
}
% gcc-11.0.0 -O1 -fanalyzer -c rn6i1ylt.c
during IPA pass: analyzer
rn6i1ylt.c:13:5: internal compiler error: Segmentation fault
13 | xj->b4->g0 = 0;
| ~~^~~~
0xd7da1f crash_signal
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/toplev.c:327
0x89a9d9 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/tree.h:3417
0x89a9d9 c_pretty_printer::unary_expression(tree_node*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/c-family/c-pretty-print.c:1793
0x898fd7 c_pretty_printer::postfix_expression(tree_node*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/c-family/c-pretty-print.c:1605
0x89a5f5 c_pretty_printer::unary_expression(tree_node*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/c-family/c-pretty-print.c:1797
0x898fd7 c_pretty_printer::postfix_expression(tree_node*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/c-family/c-pretty-print.c:1605
0x8017fd c_tree_printer
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/c/c-objc-common.c:317
0x8017fd c_tree_printer
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/c/c-objc-common.c:254
0x189db05 pp_format(pretty_printer*, text_info*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/pretty-print.c:1475
0x1850f1b ana::evdesc::event_desc::formatted_print(char const*, ...) const
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/pending-diagnostic.cc:63
0x183edf6 ana::state_change_event::get_desc(bool) const
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/checker-path.cc:255
0x183e892 ana::checker_event::prepare_for_emission(ana::checker_path*,
ana::pending_diagnostic*, diagnostic_event_id_t)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/checker-path.cc:144
0x184e360 ana::checker_path::prepare_for_emission(ana::pending_diagnostic*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/checker-path.h:498
0x184e360 ana::diagnostic_manager::emit_saved_diagnostic(ana::exploded_graph
const&, ana::saved_diagnostic const&, ana::exploded_path const&, gimple const*,
int)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/diagnostic-manager.cc:568
0x184fc7e ana::dedupe_winners::emit_best(ana::diagnostic_manager*,
ana::exploded_graph const&)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/diagnostic-manager.cc:469
0x184e728 ana::diagnostic_manager::emit_saved_diagnostics(ana::exploded_graph
const&)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/diagnostic-manager.cc:522
0x10f6eb4 ana::impl_run_checkers(ana::logger*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/engine.cc:4121
0x10f7aac ana::run_checkers()
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/engine.cc:4175
0x10ec468 execute
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/analyzer-pass.cc:84
[Bug c++/96647] New: Can't resolve pointer to overloaded member with auto return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96647
Bug ID: 96647
Summary: Can't resolve pointer to overloaded member with auto
return type
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rustamabd at gmail dot com
Target Milestone: ---
auto return type in combination with overloading and CRTP results in an
overload set that cannot be disambiguated.
Example:
template
struct Base {
auto f(int) { return static_cast(this); }
auto f(char) { return static_cast(this); }
};
struct A : Base {};
int main() {
A instance;
// instance.f('x') // "fixes" the issue
auto ptr = static_cast(&A::f); // error here
(instance.*ptr)('x');
}
Error:
error: no matches converting function 'f' to type 'struct A* (struct
A::*)(char)'
14 | auto ptr = static_cast(&A::f); // error here
| ^
note: candidates are: 'auto Base::f(char) [with T = A]'
4 | auto f(char) { return static_cast(this); }
| ^
note: 'auto Base::f(int) [with T = A]'
3 | auto f(int) { return static_cast(this); }
| ^
Replacing "auto" with "T*", as well as invoking instance.f('x'), fixes the
issue.
clang compiles the code fine.
[Bug c++/88242] static_assertion only fires when class is templated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88242 fiesh at zefix dot tv changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from fiesh at zefix dot tv --- I'll close this as invalid.
[Bug c++/78022] constexpr int template rejected unless constructor is used before hand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78022 fiesh at zefix dot tv changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from fiesh at zefix dot tv --- I'll close this since it now compiles fine.
[Bug c++/92583] [8/9 Regression] internal compiler error: in tsubst_copy, at cp/pt.c:15552
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92583 fiesh at zefix dot tv changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from fiesh at zefix dot tv --- Closing since it's been fixed. (Funny side not, the code crashes icc 19.0.1.)
[Bug c++/92654] [8/9 Regression] internal compiler error: in lookup_template_class_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92654 fiesh at zefix dot tv changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #15 from fiesh at zefix dot tv --- Closing since fixed.
[Bug libstdc++/70560] Review configure checks for _GLIBCXX_ATOMIC_BUILTINS and atomicity_dir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70560 James Hilliard changed: What|Removed |Added CC||james.hilliard1 at gmail dot com --- Comment #2 from James Hilliard --- We've been hitting a bug in buildroot with an application(apcupsd) that links against libsupc++.a directly. This issue appears to be due to a sparc/arc specific missing symbols bug in libsupc++, we aren't seeing this build error for any other architectures at the moment. See discussions: http://lists.busybox.net/pipermail/buildroot/2020-May/282779.html http://lists.busybox.net/pipermail/buildroot/2020-August/289413.html Build error http://autobuild.buildroot.org/results/3be/3bedf404de0ea42ee3ba624cded65d310a847af9//build-end.log: /tmp/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/sparc-buildroot-linux-uclibc/8.3.0/../../../../sparc-buildroot-linux-uclibc/bin/ld: /tmp/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/sparc-buildroot-linux-uclibc/8.3.0/../../../../sparc-buildroot-linux-uclibc/lib/libsupc++.a(eh_throw.o): in function `__gxx_exception_cleanup(_Unwind_Reason_Code, _Unwind_Exception*)': eh_throw.cc:(.text._ZL23__gxx_exception_cleanup19_Unwind_Reason_CodeP17_Unwind_Exception+0x38): undefined reference to `__gnu_cxx::__exchange_and_add(int volatile*, int)' collect2: error: ld returned 1 exit status make[2]: *** [Makefile:33: apcupsd] Error 1
[Bug c++/61372] Add warning to detect noexcept functions that might throw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61372 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic Blocks||87403 --- Comment #2 from Jonathan Wakely --- extern "C" functions can throw, so it would be wrong to unconditionally assume they can't. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 [Bug 87403] [Meta-bug] Issues that suggest a new warning
[Bug analyzer/96648] New: [11 Regression] ICE in get_field_at_bit_offset, at analyzer/region.cc:229
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96648
Bug ID: 96648
Summary: [11 Regression] ICE in get_field_at_bit_offset, at
analyzer/region.cc:229
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-11.0.0-alpha20200816 snapshot (g:c99116aeeb9644ebddec653ee8b19de4d38b65bd)
ICEs when compiling the following testcase w/ -O1 -fanalyzer:
struct vd {
struct vd *rs;
};
struct fh {
struct vd cl;
};
struct i3 {
struct fh *h4;
};
struct fh *
gm (void);
void
j7 (struct vd *);
inline void
mb (struct vd *e7)
{
j7 (e7->rs);
}
void
po (struct i3 *d2)
{
struct i3 *s2;
d2->h4 = gm ();
mb (&d2->h4->cl);
s2 = ({ d2 - 1; });
po (s2);
}
% gcc-11.0.0 -O1 -fanalyzer -c yepd00sw.c
during IPA pass: analyzer
yepd00sw.c: In function 'po':
yepd00sw.c:22:3: internal compiler error: in get_field_at_bit_offset, at
analyzer/region.cc:229
22 | j7 (e7->rs);
| ^~~
0x720bb1 ana::region::get_subregions_for_binding(ana::region_model_manager*,
generic_wide_int >,
generic_wide_int >, tree_node*,
auto_vec*) const
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/region.cc:229
0x113822c ana::binding_cluster::get_representative_path_vars(ana::region_model
const*, hash_set >*, ana::region const*, ana::svalue const*, auto_vec*) const
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/store.cc:1121
0x11392e7 ana::store::get_representative_path_vars(ana::region_model const*,
hash_set >*,
ana::svalue const*, auto_vec*) const
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/store.cc:1805
0x110dc5d ana::region_model::get_representative_path_var(ana::svalue const*,
hash_set >*)
const
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/region-model.cc:1806
0x110e3a7 ana::region_model::get_representative_tree(ana::svalue const*) const
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/region-model.cc:1851
0x10f8474 ana::impl_sm_context::get_diagnostic_tree(tree_node*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/engine.cc:295
0x11320df on_stmt
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/sm-malloc.cc:805
0x10f318f ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode
const*, gimple const*, ana::program_state*) const
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/engine.cc:1098
0x10f426d ana::exploded_graph::process_node(ana::exploded_node*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/engine.cc:2526
0x10f4d5a ana::exploded_graph::process_worklist()
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/engine.cc:2341
0x10f6e8f ana::impl_run_checkers(ana::logger*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/engine.cc:4107
0x10f7aac ana::run_checkers()
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/engine.cc:4175
0x10ec468 execute
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/analyzer-pass.cc:84
[Bug c++/94799] [8/9/10 Regression] Calling a member template function fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94799 --- Comment #11 from Volker Reichelt --- Hi Marek, any news on this one? It's three months now... Or should I file a new bug for the regression on trunk?
[Bug c++/94062] Cannot construct tuple from convertible types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94062 --- Comment #11 from Jonathan Wakely --- > Standard says that if: > std::is_constructible_v > then > std::is_constructible_v, Foo&&> Where does it say that? The fact a constructor participates in overload resolution doesn't mean it has to be well-formed for all template arguments. > So I think this is not an instance of PR 82113, but an unfortunate > consequence of how tuple is implemented in libstdc++. If tuple elements were > not stored as base classes, but as members than elision is mandatory and it > would work. Members using [[no_unique_address]] have the same restrictions. > But I guess to fix this you would have to break ABI (or change C++ standard). It wouldn't be an ABI break to make this compile with our std::tuple, because it never compiled previously. But I'm a little uncomfortable with making the ABI of std::tuple depend on whether its elements are copy constructible, rather than just on the elements' layout. That would mean that std::tuple changes layout if you later add a move constructor to Bar.
[Bug target/96649] New: parisc: very slow compilation when multiplying by a large constatnt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96649
Bug ID: 96649
Summary: parisc: very slow compilation when multiplying by a
large constatnt
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: mikulas at artax dot karlin.mff.cuni.cz
Target Milestone: ---
This simple program takes 34 seconds to compile on 1GHz parisc machine.
#define GR_64 0x61C886f680B583EBULL
unsigned long long mul(unsigned long long x)
{
return x * GR_64;
}
[Bug analyzer/96650] New: [11 Regression] ICE in on_fact, at analyzer/constraint-manager.cc:1785
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96650
Bug ID: 96650
Summary: [11 Regression] ICE in on_fact, at
analyzer/constraint-manager.cc:1785
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-11.0.0-alpha20200816 snapshot (g:c99116aeeb9644ebddec653ee8b19de4d38b65bd)
ICEs when compiling the following testcase w/ -O2 -fanalyzer:
int *wf;
void
yd (void);
int
cy (void);
int *
ee (int hp)
{
if (hp != 0)
yd ();
return 0;
}
void
z0 (int co)
{
int l4 = sizeof (int);
aq:
wf = ee (l4);
if (l4 < co)
l4 = cy () + sizeof (int);
goto aq;
}
% gcc-11.0.0 -O2 -fanalyzer -c apa68zkr.c
during IPA pass: analyzer
apa68zkr.c: In function 'z0':
apa68zkr.c:12:6: internal compiler error: in on_fact, at
analyzer/constraint-manager.cc:1785
12 | if (hp != 0)
| ^
0x7a3d5f ana::merger_fact_visitor::on_fact(ana::svalue const*, tree_code,
ana::svalue const*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/tree.h:3409
0x7a3d5f ana::constraint_manager::for_each_fact(ana::fact_visitor*) const
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/constraint-manager.cc:1833
0x1849ed2 ana::constraint_manager::merge(ana::constraint_manager const&,
ana::constraint_manager const&, ana::constraint_manager*, ana::model_merger
const&)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/constraint-manager.cc:1812
0x110d5fb ana::region_model::can_merge_with_p(ana::region_model const&,
ana::program_point const&, ana::region_model*) const
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/region-model.cc:2501
0x110382f ana::program_state::can_merge_with_p(ana::program_state const&,
ana::program_point const&, ana::program_state*) const
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/program-state.cc:916
0x10f2788 ana::exploded_graph::get_or_create_node(ana::program_point const&,
ana::program_state const&, ana::exploded_node const*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/engine.cc:1949
0x10f4157 ana::exploded_graph::process_node(ana::exploded_node*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/engine.cc:2650
0x10f4d5a ana::exploded_graph::process_worklist()
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/engine.cc:2341
0x10f6e8f ana::impl_run_checkers(ana::logger*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/engine.cc:4107
0x10f7aac ana::run_checkers()
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/engine.cc:4175
0x10ec468 execute
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/analyzer-pass.cc:84
[Bug analyzer/96651] New: -fanalyzer switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96651
Bug ID: 96651
Summary: -fanalyzer switch
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: uso.cosmo.ray at gmail dot com
Target Milestone: ---
When compiling this code with -fanalyzer:
static int a;
int main(void)
{
char *src = NULL;
char buf[128];
switch (a) {
case 1:
strcpy(buf, src);
break;
case 0:
strcpy(buf, "hello");
}
printf("%s\n", buf);
}
GCC seems to think the code can enter case 1 and use strcpy with a NULL value,
but it can't because a is initialize to 0, and isn't touch anywhere.
It also find have the same error if a isn't static.
Note: I've create a small snippet of code that allow to reproduce the error,
I've actually encounter the error here: https://github.com/curl/curl/pull/5815
in sws.c
[Bug c++/96652] New: Segmentation fault with instantiate_class_template_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96652
Bug ID: 96652
Summary: Segmentation fault with instantiate_class_template_1
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tangyixuan at mail dot dlut.edu.cn
Target Milestone: ---
g++ crashes on the following code, while clang++ compiles successfully:
$: cat s.cpp
struct A {};
template
struct B
{
A a;
friend decltype(a);
};
int main()
{
A a;
B b;
}
$: g++ -std=c++11 -c s.cpp
s.cpp: In instantiation of ‘struct B’:
s.cpp:12:12: required from here
s.cpp:5:7: internal compiler error: Segmentation fault
5 | A a;
| ^
0xc6a68f crash_signal
../../gcc-11-20200628/gcc/toplev.c:328
0x77745a instantiate_class_template_1
../../gcc-11-20200628/gcc/cp/pt.c:11974
0x778202 instantiate_class_template(tree_node*)
../../gcc-11-20200628/gcc/cp/pt.c:12098
0x7a7d8d complete_type(tree_node*)
../../gcc-11-20200628/gcc/cp/typeck.c:137
0x7a7d8d complete_type(tree_node*)
../../gcc-11-20200628/gcc/cp/typeck.c:111
0x6a031b start_decl_1(tree_node*, bool)
../../gcc-11-20200628/gcc/cp/decl.c:5490
0x6b0bef start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../gcc-11-20200628/gcc/cp/decl.c:5453
0x738d3e cp_parser_init_declarator
../../gcc-11-20200628/gcc/cp/parser.c:20818
0x71c052 cp_parser_simple_declaration
../../gcc-11-20200628/gcc/cp/parser.c:13785
0x71dbdd cp_parser_declaration_statement
../../gcc-11-20200628/gcc/cp/parser.c:13217
0x71e7b0 cp_parser_statement
../../gcc-11-20200628/gcc/cp/parser.c:11523
0x71f5c8 cp_parser_statement_seq_opt
../../gcc-11-20200628/gcc/cp/parser.c:11889
0x71f680 cp_parser_compound_statement
../../gcc-11-20200628/gcc/cp/parser.c:11839
0x735280 cp_parser_function_body
../../gcc-11-20200628/gcc/cp/parser.c:23116
0x735280 cp_parser_ctor_initializer_opt_and_function_body
../../gcc-11-20200628/gcc/cp/parser.c:23167
0x73887d cp_parser_function_definition_after_declarator
../../gcc-11-20200628/gcc/cp/parser.c:29063
0x73975f cp_parser_function_definition_from_specifiers_and_declarator
../../gcc-11-20200628/gcc/cp/parser.c:28979
0x73975f cp_parser_init_declarator
../../gcc-11-20200628/gcc/cp/parser.c:20722
0x71c052 cp_parser_simple_declaration
../../gcc-11-20200628/gcc/cp/parser.c:13785
0x741e16 cp_parser_declaration
../../gcc-11-20200628/gcc/cp/parser.c:13484
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug libstdc++/70560] Review configure checks for _GLIBCXX_ATOMIC_BUILTINS and atomicity_dir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70560 --- Comment #3 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #1) > It would be better to fix the lock policy at configure-time, so it is a > constant for a given build of libstdc++. That was done for PR 67843 with r266533, present in gcc 9.1 and later.
[Bug analyzer/96653] New: Compile time and memory hog w/ -O1 -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96653 Bug ID: 96653 Summary: Compile time and memory hog w/ -O1 -fanalyzer Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: compile-time-hog, memory-hog Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- Created attachment 49068 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49068&action=edit Testcase gcc-11.0.0-alpha20200816 snapshot (g:c99116aeeb9644ebddec653ee8b19de4d38b65bd) takes indefinite time and consumes ever-increasing amount of memory when compiling the attached testcase, preprocessed and reduced from drivers/media/v4l2-core/v4l2-ctrls.c from Linux 5.9-rc1, w/ -O1 -fanalyzer: % timeout 60 gcc-11.0.0 -O1 -fanalyzer -c cdkkdewb.c zsh: exit 124 timeout 60 gcc-11.0.0 -O1 -fanalyzer -c cdkkdewb.c Typical profiles captured by perf top at different time: 72.47% cc1 [.] ana::constraint_manager::add_constraint_internal 25.53% cc1 [.] ana::constraint::implied_by 0.80% cc1 [.] ana::constraint_manager::get_equiv_class_by_svalue 0.45% cc1 [.] ana::constraint_manager::eval_condition 0.20% cc1 [.] ana::constraint_manager::validate 0.15% cc1 [.] ana::constraint_manager::eval_condition 0.10% cc1 [.] ana::constraint_manager::get_or_add_equiv_class 0.10% cc1 [.] fold_binary_loc 0.07% cc1 [.] ana::constraint_manager::get_ec_bounds 0.07% cc1 [.] tree_strip_sign_nop_conversions 0.02% cc1 [.] wi::lts_p >, generic_wide_int > > 0.02% cc1 [.] tree_int_cst_equal * * * 48.80% cc1 [.] ana::constraint_manager::add_constraint_internal 25.31% cc1 [.] ana::constraint_manager::get_equiv_class_by_svalue 17.42% cc1 [.] ana::constraint::implied_by 1.40% cc1 [.] qsort_chk 0.95% cc1 [.] ana::constraint_cmp 0.62% cc1 [.] fold_binary_loc 0.55% cc1 [.] cmp2to3 0.55% cc1 [.] ana::constraint_manager::hash 0.55% cc1 [.] ana::constraint_manager::eval_condition 0.40% cc1 [.] ana::constraint_manager::eval_condition 0.32% cc1 [.] hash_table, false, xcallocator>::find_slot_with_hash 0.30% cc1 [.] mergesort 0.27% cc1 [.] ana::constraint_manager::validate 0.22% cc1 [.] ana::constraint_manager::eval_condition 0.17% cc1 [.] ana::constraint_manager::for_each_fact 0.17% cc1 [.] fold_relational_const 0.17% cc1 [.] ana::constraint_manager::get_ec_bounds 0.15% cc1 [.] const_binop 0.15% cc1 [.] ana::svalue::unwrap_any_unmergeable 0.15% cc1 [.] tree_int_cst_lt 0.15% libc-2.32.so [.] memcpy@@GLIBC_2.14 0.12% cc1 [.] tree_strip_sign_nop_conversions 0.12% cc1 [.] ana::constant_svalue::get_kind 0.12% cc1 [.] wi::extended_tree<192>::extended_tree 0.10% cc1 [.] wi::lts_p >, generic_wide_int > > 0.10% cc1 [.] constant_boolean_node 0.10% cc1 [.] ana::constraint_manager::constraint_manager 0.07% cc1 [.] ana::svalue::dyn_cast_unmergeable_svalue 0.07% cc1 [.] ana::constraint_manager::get_or_add_equiv_class 0.07% cc1 [.] ana::constraint_manager::canonicalize 0.05% cc1 [.] ana::equiv_class_cmp 0.02% libc-2.32.so [.] _int_malloc 0.02% cc1 [.] ana::constraint_manager::operator== 0.02% cc1 [.] tree_int_cst_equal 0.02% cc1 [.] wi::eq_p >, generic_wide_int > > 0.02% libc-2.32.so [.] unlink_chunk.constprop.0 0.02% cc1 [.] ana::store::can_merge_p 0.02% cc1 [.] memcpy@plt 0.02% cc1 [.] cmp1 0.02% cc1 [.] ana::constraint_manager::purge 0.02% cc1 [.] ana::store::canonicalize
[Bug libstdc++/70560] Review configure checks for _GLIBCXX_ATOMIC_BUILTINS and atomicity_dir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70560 --- Comment #4 from Jonathan Wakely --- (In reply to James Hilliard from comment #2) > We've been hitting a bug in buildroot with an application(apcupsd) that > links against libsupc++.a directly. Maybe I missed it, but I don't see the linker command in the build log. Could you show the command that's failing? Could you check if the symbol _ZN9__gnu_cxx18__exchange_and_addEPVii is actually defined in libsupc++.a or if something else like _ZN9__gnu_cxx18__exchange_and_addEPVll is defined instead?
[Bug c++/96647] Can't resolve pointer to overloaded member with auto return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96647 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Target Milestone|--- |11.0 CC||ppalka at gcc dot gnu.org Last reconfirmed||2020-08-17 Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Patrick Palka --- Confirmed, not a regression.
[Bug target/96654] New: Failure to optimize vectorized conversion to `int` with AVX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96654
Bug ID: 96654
Summary: Failure to optimize vectorized conversion to `int`
with AVX
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
void f(double *src, int *dst)
{
for (int i = 0; i < 4; i ++)
dst[i] = (int)src[i];
}
With -O3 -mavx, LLVM outputs this :
f(double*, int*):
vcvttpd2dq xmm0, ymmword ptr [rdi]
vmovupd xmmword ptr [rsi], xmm0
ret
GCC outputs this :
f(double*, int*):
push rbp
vmovupd xmm1, XMMWORD PTR [rdi]
vinsertf128 ymm0, ymm1, XMMWORD PTR [rdi+16], 0x1
mov rbp, rsp
vcvttpd2dq xmm0, ymm0
vmovdqu XMMWORD PTR [rsi], xmm0
vzeroupper
pop rbp
ret
[Bug libstdc++/70560] Review configure checks for _GLIBCXX_ATOMIC_BUILTINS and atomicity_dir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70560 --- Comment #5 from James Hilliard --- (In reply to Jonathan Wakely from comment #4) > (In reply to James Hilliard from comment #2) > > We've been hitting a bug in buildroot with an application(apcupsd) that > > links against libsupc++.a directly. > > Maybe I missed it, but I don't see the linker command in the build log. That might be somewhere here: http://autobuild.buildroot.org/results/3be/3bedf404de0ea42ee3ba624cded65d310a847af9/apcupsd-3.14.14/config.log > Could you show the command that's failing? Could you check if the symbol > _ZN9__gnu_cxx18__exchange_and_addEPVii is actually defined in libsupc++.a or > if something else like _ZN9__gnu_cxx18__exchange_and_addEPVll is defined > instead? The toolchain in that failed build is available here: http://autobuild.buildroot.org/toolchains/tarballs/br-sparc-uclibc-2020.02.tar.bz2 It appears reference to _ZN9__gnu_cxx18__exchange_and_addEPVii are in the following objects in libsupc++.a. $ nm eh_throw.o U __cxa_begin_catch U __cxa_free_exception U __cxa_get_globals T __cxa_init_primary_exception T __cxa_rethrow T __cxa_throw U _GLOBAL_OFFSET_TABLE_ w __pthread_key_create W __sparc_get_pc_thunk.l7 U _Unwind_RaiseException U _Unwind_Resume_or_Rethrow t _ZL23__gxx_exception_cleanup19_Unwind_Reason_CodeP17_Unwind_Exception U _ZN10__cxxabiv111__terminateEPFvvE U _ZN9__gnu_cxx18__exchange_and_addEPVii U _ZSt13get_terminatev U _ZSt14get_unexpectedv U _ZSt9terminatev $ nm eh_tm.o U __cxa_call_unexpected U __cxa_free_dependent_exception U __cxa_free_exception U __cxa_get_globals_fast T __cxa_tm_cleanup V DW.ref.__gxx_personality_v0 U _GLOBAL_OFFSET_TABLE_ U __gxx_personality_v0 w __pthread_key_create W __sparc_get_pc_thunk.l7 U _Unwind_DeleteException U _Unwind_Resume t _ZL22free_any_cxa_exceptionP17_Unwind_Exception U _ZN9__gnu_cxx18__exchange_and_addEPVii $ nm eh_ptr.o U __cxa_allocate_dependent_exception U __cxa_begin_catch U __cxa_free_dependent_exception U __cxa_free_exception U __cxa_get_globals V DW.ref.__gxx_personality_v0 U _GLOBAL_OFFSET_TABLE_ U __gxx_personality_v0 w __pthread_key_create W __sparc_get_pc_thunk.l7 U _Unwind_RaiseException t _ZL33__gxx_dependent_exception_cleanup19_Unwind_Reason_CodeP17_Unwind_Exception U _ZN10__cxxabiv111__terminateEPFvvE U _ZN9__gnu_cxx12__atomic_addEPVii U _ZN9__gnu_cxx18__exchange_and_addEPVii T _ZNKSt15__exception_ptr13exception_ptr20__cxa_exception_typeEv T _ZNKSt15__exception_ptr13exception_ptr6_M_getEv T _ZNKSt15__exception_ptr13exception_ptrcvMS0_FvvEEv T _ZNKSt15__exception_ptr13exception_ptrntEv T _ZNSt15__exception_ptr13exception_ptr10_M_releaseEv T _ZNSt15__exception_ptr13exception_ptr18_M_safe_bool_dummyEv T _ZNSt15__exception_ptr13exception_ptr4swapERS0_ T _ZNSt15__exception_ptr13exception_ptr9_M_addrefEv T _ZNSt15__exception_ptr13exception_ptraSERKS0_ T _ZNSt15__exception_ptr13exception_ptrC1EMS0_FvvE T _ZNSt15__exception_ptr13exception_ptrC1EPv T _ZNSt15__exception_ptr13exception_ptrC1ERKS0_ T _ZNSt15__exception_ptr13exception_ptrC1Ev T _ZNSt15__exception_ptr13exception_ptrC2EMS0_FvvE T _ZNSt15__exception_ptr13exception_ptrC2EPv T _ZNSt15__exception_ptr13exception_ptrC2ERKS0_ T _ZNSt15__exception_ptr13exception_ptrC2Ev T _ZNSt15__exception_ptr13exception_ptrD1Ev T _ZNSt15__exception_ptr13exception_ptrD2Ev T _ZNSt15__exception_ptreqERKNS_13exception_ptrES2_ T _ZNSt15__exception_ptrneERKNS_13exception_ptrES2_ U _ZSt13get_terminatev U _ZSt14get_unexpectedv T _ZSt17current_exceptionv T _ZSt17rethrow_exceptionNSt15__exception_ptr13exception_ptrE U _ZSt9terminatev
[Bug c++/94062] Cannot construct tuple from convertible types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94062
--- Comment #12 from m.cencora at gmail dot com ---
(In reply to Jonathan Wakely from comment #11)
> > Standard says that if:
> > std::is_constructible_v
> > then
> > std::is_constructible_v, Foo&&>
>
> Where does it say that?
>
> The fact a constructor participates in overload resolution doesn't mean it
> has to be well-formed for all template arguments.
Indirectly from following paragraph 20.5.3.1 in latest C++ draft:
template constexpr explicit(see below) tuple(UTypes&&... u);
11
#
Constraints: sizeof...(Types) equals sizeof...(UTypes) and sizeof...(Types)≥1
and is_constructible_v is true for all i.
12
#
Effects: Initializes the elements in the tuple with the corresponding value in
std::forward(u).
13
#
Remarks: The expression inside explicit is equivalent to:
!conjunction_v...>
So unless I am missing something, I see no escape hatch for making such
constructor ill-formed for some types.
>
> > So I think this is not an instance of PR 82113, but an unfortunate
> > consequence of how tuple is implemented in libstdc++. If tuple elements were
> > not stored as base classes, but as members than elision is mandatory and it
> > would work.
>
> Members using [[no_unique_address]] have the same restrictions.
>
> > But I guess to fix this you would have to break ABI (or change C++
> > standard).
>
> It wouldn't be an ABI break to make this compile with our std::tuple,
> because it never compiled previously. But I'm a little uncomfortable with
> making the ABI of std::tuple depend on whether its elements are copy
> constructible, rather than just on the elements' layout.
>
> That would mean that std::tuple changes layout if you later add a move
> constructor to Bar.
Not sure how, because you can create std::tuple already by using other
constructors, e.g.:
#include
struct Bar
{
Bar() = default;
Bar(int i);
Bar(const Bar&) = delete;
};
struct ConvertibleToBar
{
operator Bar();
};
std::tuple ok1()
{
return {};
}
std::tuple ok2()
{
return {0};
}
std::tuple fail1()
{
return {ConvertibleToBar{}};
}
[Bug tree-optimization/96633] missed optimization?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96633
--- Comment #2 from Alexander Monakov ---
Martin added me to CC so I assume he wants me to chime in.
First of all, I find Nathan's behavior in that gcc@ thread distasteful at best
(but if you ask me, such responses are simply more harm than good; link:
https://lwn.net/ml/gcc/1a363f89-6f98-f583-e22a-a7fc02efb...@acm.org/ ).
Next, statements like "I've determined the following is abot 12% faster" don't
carry weight without details such as the CPU family, structure of the benchmark
and the workload. Obviously, on input that lacks whitespace GCC's original code
is faster as the initial branch is 100% predictable. Likewise, if the input was
taken from /dev/random, the 12% figure is irrelevant to real-world uses of such
code. What the benchmark is doing with the return value of the function also
matters a lot.
With that out of the way: striving to get efficient branchless code on this
code is not very valuable in practice, because the caller is likely to perform
a conditional branch on the result anyway. So making isWhitespace branchless
simply moves the misprediction cost to the caller, making the overall code
slower.
(but of course such considerations are too complex for the compiler's limited
brain)
In general such "bitmask tests" will benefit from the BT instruction on x86
(not an extension, was in the ISA since before I was born), plus CMOV to get
the right mask if it doesn't fit in a register.
For 100% branchless code we want to generate code similar to:
char is_ws(char c)
{
unsigned long long mask = 1ll<<' ' | 1<<'\t' | 1<<'\r' | 1<<'\n';
unsigned long long v = c;
if (v > 32)
#if 1
mask = 0;
#else
return 0;
#endif
char r;
asm("bt %1, %2; setc %0" : "=r"(r) : "r"(v), "r"(mask));
return r;
}
movsbq %dil, %rax
movl$0, %edx
movabsq $4294977024, %rdi
cmpq$33, %rax
cmovnb %rdx, %rdi
bt %rax, %rdi; setc %al
ret
(note we get %edx zeroing suboptimal, should have used xor %edx, %edx)
This is generalizable to any input type, not just char.
We even already get the "test against a mask" part of the idea right ;)
Branchy testing is even cheaper with BT:
void is_ws_cb(unsigned char c, void f(void))
{
unsigned long long mask = 1ll<<' ' | 1<<'\t' | 1<<'\r' | 1<<'\n';
if (c <= 32 && (mask & (1ll<
[Bug fortran/96655] New: [OOP] CLASS dummy arguments: Bogus "Duplicate OPTIONAL attribute specified"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96655 Bug ID: 96655 Summary: [OOP] CLASS dummy arguments: Bogus "Duplicate OPTIONAL attribute specified" Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Target Milestone: --- The following fails with: Duplicate OPTIONAL attribute specified subroutine sub2(val1a, val4) class(*), allocatable :: val1a, val3 optional :: val1a, val3 end
[Bug c++/96656] New: Segmentation fault with make_friend_class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96656
Bug ID: 96656
Summary: Segmentation fault with make_friend_class
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tangyixuan at mail dot dlut.edu.cn
Target Milestone: ---
Please consider the following code. Clang++ compiles it successfully, while g++
fails:
$: cat s.cpp
struct a{};
template struct b {
using c=a;
};
class B {
template
friend class b::c;
};
int main() {
B b;
}
$: g++ -c s.cpp
s.cpp:8:25: internal compiler error: Segmentation fault
8 | friend class b::c;
| ^
0xc6a68f crash_signal
../../gcc-11-20200628/gcc/toplev.c:328
0x6d01b4 make_friend_class(tree_node*, tree_node*, bool)
../../gcc-11-20200628/gcc/cp/friend.c:400
0x73ef87 cp_parser_template_declaration_after_parameters
../../gcc-11-20200628/gcc/cp/parser.c:29140
0x73f0aa cp_parser_explicit_template_declaration
../../gcc-11-20200628/gcc/cp/parser.c:29388
0x718a29 cp_parser_member_specification_opt
../../gcc-11-20200628/gcc/cp/parser.c:24850
0x718a29 cp_parser_class_specifier_1
../../gcc-11-20200628/gcc/cp/parser.c:23947
0x71a603 cp_parser_class_specifier
../../gcc-11-20200628/gcc/cp/parser.c:24254
0x71a603 cp_parser_type_specifier
../../gcc-11-20200628/gcc/cp/parser.c:17762
0x71b422 cp_parser_decl_specifier_seq
../../gcc-11-20200628/gcc/cp/parser.c:14410
0x71bf41 cp_parser_simple_declaration
../../gcc-11-20200628/gcc/cp/parser.c:13664
0x741e16 cp_parser_declaration
../../gcc-11-20200628/gcc/cp/parser.c:13484
0x742504 cp_parser_translation_unit
../../gcc-11-20200628/gcc/cp/parser.c:4761
0x742504 c_parse_file()
../../gcc-11-20200628/gcc/cp/parser.c:44043
0x80bc8b c_common_parse_file()
../../gcc-11-20200628/gcc/c-family/c-opts.c:1190
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug libstdc++/70560] Review configure checks for _GLIBCXX_ATOMIC_BUILTINS and atomicity_dir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70560
--- Comment #6 from Jonathan Wakely ---
(In reply to James Hilliard from comment #5)
> That might be somewhere here:
> http://autobuild.buildroot.org/results/3be/
> 3bedf404de0ea42ee3ba624cded65d310a847af9/apcupsd-3.14.14/config.log
No, I meant the command that fails when running 'make'. But it doesn't matter
now, because ...
> It appears reference to _ZN9__gnu_cxx18__exchange_and_addEPVii are in the
> following objects in libsupc++.a.
I was looking for the definition of the function not the references to it, but
I think the problem is that those functions are defined by
src/c++98/atomicity.cc which isn't included in libsupc++.a at all.
Using the atomic functions in libsupc++.a assumes that atomic builtins are
supported and so we won't need the extern functions from atomicity.cc, which
isn't necessarily true.
I think this has been broken since r244051 enabled std::exception_ptr for
targets without lock-free atomic built-ins. Previously if we didn't have atomic
built-ins, libsupc++ just wouldn't try to use atomics. Now it uses the
built-ins or falls back to the extern functions in atomicity.cc, but the latter
are not in libsupc++.a so it only works if you link to the full
libstdc++.{a,so} library.
Please file a new bug, yours is a separate issue to this one.
[Bug tree-optimization/96597] valgrind error in do_hoist_insertion during O3 build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96597 Martin Liška changed: What|Removed |Added Target Milestone|--- |11.0
[Bug libstdc++/96657] New: libsupc++.a missing required functions from src/c++98/atomicity.cc when atomic builtins are not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96657 Bug ID: 96657 Summary: libsupc++.a missing required functions from src/c++98/atomicity.cc when atomic builtins are not supported Product: gcc Version: 9.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: james.hilliard1 at gmail dot com CC: redi at gcc dot gnu.org Target Milestone: --- We've been hitting a bug in buildroot with an application(apcupsd) that links against libsupc++.a directly. This issue appears to be due to a sparc/arc specific missing symbols bug in libsupc++, we aren't seeing this build error for any other architectures at the moment. See discussions: http://lists.busybox.net/pipermail/buildroot/2020-May/282779.html http://lists.busybox.net/pipermail/buildroot/2020-August/289413.html Build error http://autobuild.buildroot.org/results/3be/3bedf404de0ea42ee3ba624cded65d310a847af9//build-end.log: /tmp/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/sparc-buildroot-linux-uclibc/8.3.0/../../../../sparc-buildroot-linux-uclibc/bin/ld: /tmp/instance-0/output-1/host/opt/ext-toolchain/bin/../lib/gcc/sparc-buildroot-linux-uclibc/8.3.0/../../../../sparc-buildroot-linux-uclibc/lib/libsupc++.a(eh_throw.o): in function `__gxx_exception_cleanup(_Unwind_Reason_Code, _Unwind_Exception*)': eh_throw.cc:(.text._ZL23__gxx_exception_cleanup19_Unwind_Reason_CodeP17_Unwind_Exception+0x38): undefined reference to `__gnu_cxx::__exchange_and_add(int volatile*, int)' collect2: error: ld returned 1 exit status make[2]: *** [Makefile:33: apcupsd] Error 1 Based on previous discussions(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70560#c6) it appears this has been broken since r244051 enabled std::exception_ptr for targets without lock-free atomic built-ins.
[Bug libstdc++/70560] Review configure checks for _GLIBCXX_ATOMIC_BUILTINS and atomicity_dir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70560
--- Comment #7 from James Hilliard ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to James Hilliard from comment #5)
> > That might be somewhere here:
> > http://autobuild.buildroot.org/results/3be/
> > 3bedf404de0ea42ee3ba624cded65d310a847af9/apcupsd-3.14.14/config.log
>
> No, I meant the command that fails when running 'make'. But it doesn't
> matter now, because ...
>
> > It appears reference to _ZN9__gnu_cxx18__exchange_and_addEPVii are in the
> > following objects in libsupc++.a.
>
> I was looking for the definition of the function not the references to it,
> but I think the problem is that those functions are defined by
> src/c++98/atomicity.cc which isn't included in libsupc++.a at all.
>
> Using the atomic functions in libsupc++.a assumes that atomic builtins are
> supported and so we won't need the extern functions from atomicity.cc, which
> isn't necessarily true.
>
> I think this has been broken since r244051 enabled std::exception_ptr for
> targets without lock-free atomic built-ins. Previously if we didn't have
> atomic built-ins, libsupc++ just wouldn't try to use atomics. Now it uses
> the built-ins or falls back to the extern functions in atomicity.cc, but the
> latter are not in libsupc++.a so it only works if you link to the full
> libstdc++.{a,so} library.
>
> Please file a new bug, yours is a separate issue to this one.
New bug report opened here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96657
[Bug analyzer/96616] pr93032-mztools.c -Wanalyzer-too-complex warnings on some targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96616 David Malcolm changed: What|Removed |Added Summary|Many new analyzer failures |pr93032-mztools.c ||-Wanalyzer-too-complex ||warnings on some targets --- Comment #5 from David Malcolm --- Updating title to reflect that the remaining work is fixing the -Wanalyzer-too-complex warnings that are showing up on some targets (at least arm, aarch64, and powerpc64, but not x86_64 as far as I can tell).
[Bug c++/94062] Cannot construct tuple from convertible types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94062
--- Comment #13 from Jonathan Wakely ---
(In reply to m.cencora from comment #12)
> So unless I am missing something, I see no escape hatch for making such
> constructor ill-formed for some types.
Consider:
#include
struct X
{
template
X(T)
{ static_assert(!std::is_same_v); }
};
static_assert(std::is_constructible_v);
static_assert(std::is_constructible_v, int>);
std::tuple t{1};
The fact that a type meets a function's constraints does not mean it has to
compile, it just means the function is not removed from the candidate functions
for overload resolution.
The standard is pretty clear about that:
Constraints: the conditions for the function’s participation in overload
resolution
That's it. It doesn't mean any more than that.
The constructor's effects say it initializes the element from the argument, and
if that initialization is ill-formed (e.g. because it requires a copy that
isn't elided) then the constructor is ill-formed.
> > That would mean that std::tuple changes layout if you later add a move
> > constructor to Bar.
>
> Not sure how, because you can create std::tuple already by using other
> constructors, e.g.:
That's irrelevant. I'm talking about a change that would make it possible to
construct non-movable types, so if you change whether a type is movable or not,
it would affect std::tuple. The fact other constructors are already present is
irrelevant, I'm not talking about making anything depend on those.
Bar is an empty class, so we will try to make tuple use a
potentially-overlapping subobject (storing a Bar as a base class today, or a
data member with [[no_unique_address] in the near future). That doesn't support
initialization from ConvertibleToBar because the copy cannot be elided.
I could change the tuple code to not use a potentially-overlapping subobject
for non-movable types, so that copy elision works. But now if you add a move
constructor the decision of whether to use a potentially-overlapping subobject
changes. So that means the std::tuple layout would depend on the presence of a
move constructor.
#include
namespace std
{
template && std::is_move_constructible_v>
struct Tuple_impl
{
T t;
template
Tuple_impl(U&& u) : t(static_cast(u)) { }
};
template
struct Tuple_impl
{
[[no_unique_address]] T t;
template
Tuple_impl(U&& u) : t(static_cast(u)) { }
};
template
struct tuple : Tuple_impl...
{
template
tuple(U&&... u)
: Tuple_impl(static_cast(u))...
{ }
};
}
struct Bar
{
Bar() = default;
Bar(int i);
Bar(const Bar&) = delete;
#ifdef MAKE_IT_MOVABLE
Bar(Bar&&) = default;
#endif
};
struct ConvertibleToBar
{
operator Bar();
};
std::tuple fail1()
{
return {ConvertibleToBar{}};
}
static_assert( sizeof(std::tuple) == 8 );
If you define MAKE_IT_MOVABLE then the static assertion fails. This shows that
the toy implementation above can support construction from ConvertibleToBar but
at the cost of changing layout if a move constructor is added later.
I don't think supporting guaranteed elision for non-copyable, non-movable,
empty types is a sufficiently important use case to make the layout fragile.
[Bug analyzer/96641] [11 Regression] ICE in get_rvalue_1, at analyzer/region-model.cc:1082
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96641
--- Comment #1 from Arseny Solokha ---
A C++ testcase, for that matter.
struct uh {
virtual void
sx ();
};
struct iz : uh {
virtual void
sx ()
{
sx ();
}
};
void
a2 ()
{
iz ().sx ();
}
% gcc-11.0.0 -fanalyzer -c dmkwon0d.cc
during IPA pass: analyzer
dmkwon0d.cc: In member function 'virtual void iz::sx()':
dmkwon0d.cc:10:8: internal compiler error: in get_rvalue_1, at
analyzer/region-model.cc:1082
10 | sx ();
| ~~~^~
0x7e4de2 ana::region_model::get_rvalue_1(ana::path_var,
ana::region_model_context*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/region-model.cc:1082
0x1373218 ana::region_model::get_rvalue(ana::path_var,
ana::region_model_context*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/region-model.cc:1173
0x1373218 ana::region_model::get_rvalue(tree_node*, ana::region_model_context*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/region-model.cc:1186
0x13746e1 ana::region_model::get_fndecl_for_call(gcall const*,
ana::region_model_context*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/region-model.cc:2519
0x137806b ana::region_model::on_call_pre(gcall const*,
ana::region_model_context*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/region-model.cc:630
0x13571a4 ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode
const*, gimple const*, ana::program_state*) const
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/engine.cc:1083
0x135800d ana::exploded_graph::process_node(ana::exploded_node*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/engine.cc:2526
0x1358afa ana::exploded_graph::process_worklist()
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/engine.cc:2341
0x135ac2f ana::impl_run_checkers(ana::logger*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/engine.cc:4107
0x135b84c ana::run_checkers()
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/engine.cc:4175
0x1350208 execute
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20200816/work/gcc-11-20200816/gcc/analyzer/analyzer-pass.cc:84
(I can file it as a new PR, if it is actually unrelated.)
[Bug tree-optimization/96658] New: Unhelpful -Wstrict-overflow warning from std::push_heap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96658
Bug ID: 96658
Summary: Unhelpful -Wstrict-overflow warning from
std::push_heap
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
Reduced from https://stackoverflow.com/q/63405519/981959
This code produces a warning that is of zero value to users:
#include
void f(unsigned long* v) { std::push_heap(v, v+3); }
$ g++ -c -O3 -Wstrict-overflow=3 p.C
p.C: In function 'void std::push_heap(_RAIter, _RAIter) [with _RAIter = long
unsigned int*]':
p.C:2:52: warning: assuming signed overflow does not occur when changing X +-
C1 cmp C2 to X cmp C2 -+ C1 [-Wstrict-overflow]
2 | void f(unsigned long* v) { std::push_heap(v, v+3); }
|^
The user doesn't have any signed integers, and the C1 cmp C2 expression doesn't
appear in the user's code (it doesn't even appear in the libstdc++ headers).
This warning seems totally useless to users. The library code is correct, no
useful location is shown to the user, and the user can't change the library
anyway.
The code can be simplified to:
template
inline void
push_heap(T* first, T* last)
{
T value = (*(last - 1));
long holeIndex = last - first - 1;
long topIndex = 0;
long parent = (holeIndex - 1) / 2;
while (holeIndex > topIndex && *(first + parent) < value)
{
*(first + holeIndex) = *(first + parent);
holeIndex = parent;
parent = (holeIndex - 1) / 2;
}
*(first + holeIndex) = value;
}
void f(unsigned long* v) { push_heap(v, v+3); }
Which still warns and still shows no useful information:
p.C: In function 'void push_heap(T*, T*) [with T = long unsigned int]':
p.C:18:47: warning: assuming signed overflow does not occur when changing X +-
C1 cmp C2 to X cmp C2 -+ C1 [-Wstrict-overflow]
18 | void f(unsigned long* v) { push_heap(v, v+3); }
| ^
I know the documentation says that -Wstrict-overflow=3 easily gives false
positives, but this case seems especially unhelpful.
[Bug libstdc++/96657] [9/10/11 Regression] libsupc++.a missing required functions from src/c++98/atomicity.cc when atomic builtins are not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96657 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-08-17 Summary|libsupc++.a missing |[9/10/11 Regression] |required functions from |libsupc++.a missing |src/c++98/atomicity.cc when |required functions from |atomic builtins are not |src/c++98/atomicity.cc when |supported |atomic builtins are not ||supported --- Comment #1 from Jonathan Wakely --- I think r244051 caused libsupc++.a to depend on libstdc++.so for targets that don't support lock-free atomics for int.
[Bug libstdc++/96657] [9/10/11 Regression] libsupc++.a missing required functions from src/c++98/atomicity.cc when atomic builtins are not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96657 --- Comment #2 from James Hilliard --- (In reply to Jonathan Wakely from comment #1) > I think r244051 caused libsupc++.a to depend on libstdc++.so for targets > that don't support lock-free atomics for int. Yeah, the current workaround we came up with was to force linking to libstdc++.so, but that's probably not a real fix for the root cause of the issue. I'm assuming the real fix would be to change libsupc++.a so that it includes the missing symbols?
[Bug c++/94062] Cannot construct tuple from convertible types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94062
--- Comment #14 from m.cencora at gmail dot com ---
(In reply to Jonathan Wakely from comment #13)
> (In reply to m.cencora from comment #12)
> > So unless I am missing something, I see no escape hatch for making such
> > constructor ill-formed for some types.
>
>
> Consider:
>
> #include
>
> struct X
> {
> template
> X(T)
> { static_assert(!std::is_same_v); }
> };
>
> static_assert(std::is_constructible_v);
> static_assert(std::is_constructible_v, int>);
>
> std::tuple t{1};
>
> The fact that a type meets a function's constraints does not mean it has to
> compile, it just means the function is not removed from the candidate
> functions for overload resolution.
>
> The standard is pretty clear about that:
>
> Constraints: the conditions for the function’s participation in overload
> resolution
>
> That's it. It doesn't mean any more than that.
Ok, but how is it relevant here?
We could provide full definition of well-formed Bar constructors and
CovertibleToBar conversion operator, and it will still fail to compile with
libstdc++'s tuple.
>
> The constructor's effects say it initializes the element from the argument,
> and if that initialization is ill-formed (e.g. because it requires a copy
> that isn't elided) then the constructor is ill-formed.
But the user didn't introduce any ill-formed code.
Implementation did by relying on copy-elision to work in a place where it is
not guaranteed by the standard.
>
>
> > > That would mean that std::tuple changes layout if you later add a
> > > move
> > > constructor to Bar.
> >
> > Not sure how, because you can create std::tuple already by using other
> > constructors, e.g.:
>
> That's irrelevant. I'm talking about a change that would make it possible to
> construct non-movable types, so if you change whether a type is movable or
> not, it would affect std::tuple. The fact other constructors are already
> present is irrelevant, I'm not talking about making anything depend on those.
>
> Bar is an empty class, so we will try to make tuple use a
> potentially-overlapping subobject (storing a Bar as a base class today, or a
> data member with [[no_unique_address] in the near future). That doesn't
> support initialization from ConvertibleToBar because the copy cannot be
> elided.
>
> I could change the tuple code to not use a potentially-overlapping subobject
> for non-movable types, so that copy elision works. But now if you add a move
> constructor the decision of whether to use a potentially-overlapping
> subobject changes. So that means the std::tuple layout would depend on the
> presence of a move constructor.
>
> #include
>
> namespace std
> {
> template bool compress = std::is_empty_v &&
> std::is_move_constructible_v>
> struct Tuple_impl
> {
> T t;
>
> template
> Tuple_impl(U&& u) : t(static_cast(u)) { }
> };
>
> template
> struct Tuple_impl
> {
> [[no_unique_address]] T t;
>
> template
> Tuple_impl(U&& u) : t(static_cast(u)) { }
> };
>
> template
> struct tuple : Tuple_impl...
> {
> template
> tuple(U&&... u)
> : Tuple_impl(static_cast(u))...
> { }
> };
> }
>
> struct Bar
> {
> Bar() = default;
> Bar(int i);
> Bar(const Bar&) = delete;
> #ifdef MAKE_IT_MOVABLE
> Bar(Bar&&) = default;
> #endif
> };
>
> struct ConvertibleToBar
> {
> operator Bar();
> };
>
> std::tuple fail1()
> {
> return {ConvertibleToBar{}};
> }
>
> static_assert( sizeof(std::tuple) == 8 );
>
> If you define MAKE_IT_MOVABLE then the static assertion fails. This shows
> that the toy implementation above can support construction from
> ConvertibleToBar but at the cost of changing layout if a move constructor is
> added later.
>
> I don't think supporting guaranteed elision for non-copyable, non-movable,
> empty types is a sufficiently important use case to make the layout fragile.
Whether Bar is empty class or not is irrelevant for this bug.
Maybe this could be fixed it without breaking the ABI for empty classes
scenario, but I see no way around it for non-empty classes.
[Bug libstdc++/96657] [9/10/11 Regression] libsupc++.a missing required functions from src/c++98/atomicity.cc when atomic builtins are not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96657 --- Comment #3 from Jonathan Wakely --- Yes, I think that's what we need to do.
[Bug c++/94062] Cannot construct tuple from convertible types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94062 --- Comment #15 from Jonathan Wakely --- (In reply to m.cencora from comment #14) > Whether Bar is empty class or not is irrelevant for this bug. No it isn't. Your examples already work for tuples of non-empty classes.
[Bug c++/96630] dangling reference accepted in constexpr evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96630 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-08-17 Keywords||accepts-invalid Status|UNCONFIRMED |NEW
[Bug c++/96387] gnu gmp c source edit g++ internal compiler error appear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96387 cents2823 at yahoo dot co.jp changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #7 from cents2823 at yahoo dot co.jp --- >GCC uses GMP, MPFR (which uses GMP internally) and MPC (which uses MPFR). so >yes it depends on GMP ABI being stable. I understood the mutual relationship. I found a way to change gmp ABI and make gcc work properly. Steps to follow: #1 ubuntu install #2 apt-get gcc(gcc-9.3.0) #3 gcc source install(for example gcc-10.1.0) #3-1 gcc source download #3-2 ./contrib/download_prerequisites(GMP,MPFR,MPC,.:download) *#3-3 gmp ABI update(mpz struct change) #3-4 configure,make,make install #4 ABI update gmp install use new gcc This bug was caused by incorrect use, and since the normality of normal use has been confirmed, I will closed it. Thanking you in advance. Frome:Tsukamoto
[Bug c++/96645] [9/10/11 Regression] std::variant default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Summary|std::variant default|[9/10/11 Regression]
|constructor |std::variant default
||constructor
Last reconfirmed||2020-08-17
Status|UNCONFIRMED |NEW
Known to fail||10.2.0, 11.0, 9.3.0
Component|libstdc++ |c++
Known to work||8.4.0
CC||jason at gcc dot gnu.org
Keywords||rejects-valid
--- Comment #1 from Jonathan Wakely ---
This is not a bug in std::variant:
template
struct bool_constant
{
static constexpr bool value = B;
using type = bool_constant;
};
using true_type = bool_constant;
template
struct is_default_constructible
: bool_constant<__is_constructible(T)>
{ };
void testVarStruct()
{
struct DataWithStruct {
struct A {
int number = 5; // compiles, if remove initialization
};
is_default_constructible::type t = true_type{};
};
}
v.C: In function 'void testVarStruct()':
v.C:22:47: error: could not convert 'true_type{}' from 'bool_constant' to
'bool_constant'
22 | is_default_constructible::type t = true_type{};
| ^~~
| |
| bool_constant
This stopped working with r269032 which changed the result of the
__is_constructible built-in.
Clang also rejects this, for the same reason, but EDG accepts it.
[Bug c++/96645] [9/10/11 Regression] std::variant default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645
--- Comment #2 from Sergey ---
(In reply to Jonathan Wakely from comment #1)
> This is not a bug in std::variant:
>
>
> template
> struct bool_constant
> {
> static constexpr bool value = B;
> using type = bool_constant;
> };
>
> using true_type = bool_constant;
>
> template
> struct is_default_constructible
> : bool_constant<__is_constructible(T)>
> { };
>
> void testVarStruct()
> {
> struct DataWithStruct {
> struct A {
> int number = 5; // compiles, if remove initialization
> };
>
> is_default_constructible::type t = true_type{};
> };
> }
>
> v.C: In function 'void testVarStruct()':
> v.C:22:47: error: could not convert 'true_type{}' from 'bool_constant'
> to 'bool_constant'
>22 | is_default_constructible::type t = true_type{};
> | ^~~
> | |
> | bool_constant
>
>
> This stopped working with r269032 which changed the result of the
> __is_constructible built-in.
>
> Clang also rejects this, for the same reason, but EDG accepts it.
Clang compiles it if use libc++ instead of libstdc++
[Bug c++/94062] Cannot construct tuple from convertible types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94062 --- Comment #16 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:91e6226f880b048275a7ceedef716e159c7cefd9 commit r11-2720-g91e6226f880b048275a7ceedef716e159c7cefd9 Author: Jonathan Wakely Date: Fri Aug 7 17:13:56 2020 +0100 libstdc++: Remove inheritance from elements in std::tuple This fixes a number of std::tuple bugs by no longer making use of the empty base-class optimization. By using the C++20 [[no_unique_address]] attribute we can always store the element as a data member, while still compressing the layout of tuples containing empty types. Since we no longer use inheritance we could also apply the compression optimization for final types and for tuples of tuples, but doing so would be an ABI break. Using [[no_unique_address]] more liberally for the unstable std::__8 configuration is left for a later date. There may be reasons not to apply the attribute unconditionally, e.g. see the discussion about guaranteed elision in PR 94062. libstdc++-v3/ChangeLog: PR libstdc++/55713 PR libstdc++/71096 PR libstdc++/93147 * include/std/tuple [__has_cpp_attribute(no_unique_address)] (_Head_base): New definition of the partial specialization, using [[no_unique_address]] instead of inheritance. * testsuite/libstdc++-prettyprinters/48362.cc: Adjust expected output. * testsuite/20_util/tuple/comparison_operators/93147.cc: New test. * testsuite/20_util/tuple/creation_functions/55713.cc: New test. * testsuite/20_util/tuple/element_access/71096.cc: New test.
[Bug libstdc++/55713] std::tuple incorrectly is convertible to "ElementType" when it is an empty class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55713 --- Comment #7 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:91e6226f880b048275a7ceedef716e159c7cefd9 commit r11-2720-g91e6226f880b048275a7ceedef716e159c7cefd9 Author: Jonathan Wakely Date: Fri Aug 7 17:13:56 2020 +0100 libstdc++: Remove inheritance from elements in std::tuple This fixes a number of std::tuple bugs by no longer making use of the empty base-class optimization. By using the C++20 [[no_unique_address]] attribute we can always store the element as a data member, while still compressing the layout of tuples containing empty types. Since we no longer use inheritance we could also apply the compression optimization for final types and for tuples of tuples, but doing so would be an ABI break. Using [[no_unique_address]] more liberally for the unstable std::__8 configuration is left for a later date. There may be reasons not to apply the attribute unconditionally, e.g. see the discussion about guaranteed elision in PR 94062. libstdc++-v3/ChangeLog: PR libstdc++/55713 PR libstdc++/71096 PR libstdc++/93147 * include/std/tuple [__has_cpp_attribute(no_unique_address)] (_Head_base): New definition of the partial specialization, using [[no_unique_address]] instead of inheritance. * testsuite/libstdc++-prettyprinters/48362.cc: Adjust expected output. * testsuite/20_util/tuple/comparison_operators/93147.cc: New test. * testsuite/20_util/tuple/creation_functions/55713.cc: New test. * testsuite/20_util/tuple/element_access/71096.cc: New test.
[Bug libstdc++/71096] std::get did not work for nested derived classes from std::tuple if one element is empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71096 --- Comment #3 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:91e6226f880b048275a7ceedef716e159c7cefd9 commit r11-2720-g91e6226f880b048275a7ceedef716e159c7cefd9 Author: Jonathan Wakely Date: Fri Aug 7 17:13:56 2020 +0100 libstdc++: Remove inheritance from elements in std::tuple This fixes a number of std::tuple bugs by no longer making use of the empty base-class optimization. By using the C++20 [[no_unique_address]] attribute we can always store the element as a data member, while still compressing the layout of tuples containing empty types. Since we no longer use inheritance we could also apply the compression optimization for final types and for tuples of tuples, but doing so would be an ABI break. Using [[no_unique_address]] more liberally for the unstable std::__8 configuration is left for a later date. There may be reasons not to apply the attribute unconditionally, e.g. see the discussion about guaranteed elision in PR 94062. libstdc++-v3/ChangeLog: PR libstdc++/55713 PR libstdc++/71096 PR libstdc++/93147 * include/std/tuple [__has_cpp_attribute(no_unique_address)] (_Head_base): New definition of the partial specialization, using [[no_unique_address]] instead of inheritance. * testsuite/libstdc++-prettyprinters/48362.cc: Adjust expected output. * testsuite/20_util/tuple/comparison_operators/93147.cc: New test. * testsuite/20_util/tuple/creation_functions/55713.cc: New test. * testsuite/20_util/tuple/element_access/71096.cc: New test.
[Bug libstdc++/93147] std::tuple of empty structs with member equality operators has ambiguous equality operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93147 --- Comment #10 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:91e6226f880b048275a7ceedef716e159c7cefd9 commit r11-2720-g91e6226f880b048275a7ceedef716e159c7cefd9 Author: Jonathan Wakely Date: Fri Aug 7 17:13:56 2020 +0100 libstdc++: Remove inheritance from elements in std::tuple This fixes a number of std::tuple bugs by no longer making use of the empty base-class optimization. By using the C++20 [[no_unique_address]] attribute we can always store the element as a data member, while still compressing the layout of tuples containing empty types. Since we no longer use inheritance we could also apply the compression optimization for final types and for tuples of tuples, but doing so would be an ABI break. Using [[no_unique_address]] more liberally for the unstable std::__8 configuration is left for a later date. There may be reasons not to apply the attribute unconditionally, e.g. see the discussion about guaranteed elision in PR 94062. libstdc++-v3/ChangeLog: PR libstdc++/55713 PR libstdc++/71096 PR libstdc++/93147 * include/std/tuple [__has_cpp_attribute(no_unique_address)] (_Head_base): New definition of the partial specialization, using [[no_unique_address]] instead of inheritance. * testsuite/libstdc++-prettyprinters/48362.cc: Adjust expected output. * testsuite/20_util/tuple/comparison_operators/93147.cc: New test. * testsuite/20_util/tuple/creation_functions/55713.cc: New test. * testsuite/20_util/tuple/element_access/71096.cc: New test.
[Bug c++/96645] [9/10/11 Regression] std::variant default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645 --- Comment #3 from Jonathan Wakely --- It doesn't compile the code in comment 1. That code doesn't use any standard library components, so it doesn't make any difference whether you use libc++ or not.
[Bug libstdc++/71096] std::get did not work for nested derived classes from std::tuple if one element is empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71096 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely --- Fixed for GCC 11.
[Bug libstdc++/55713] std::tuple incorrectly is convertible to "ElementType" when it is an empty class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55713 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jonathan Wakely --- Fixed for GCC 11.
[Bug libstdc++/93147] std::tuple of empty structs with member equality operators has ambiguous equality operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93147 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #11 from Jonathan Wakely --- Fixed for GCC 11.
[Bug analyzer/96639] [11 Regression] ICE: Segmentation fault (in useless_type_conversion_p)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96639 David Malcolm changed: What|Removed |Added Last reconfirmed||2020-08-17 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from David Malcolm --- Thanks for filing this; confirmed.
[Bug target/96536] -fcf-protection code in i386.md:restore_stack_nonlocal uses invalid compare-and-jump rtl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96536
--- Comment #6 from Uroš Bizjak ---
(In reply to Hongtao.liu from comment #1)
> I'm testing patch like
>
>emit_insn ((word_mode == SImode)
> ? gen_incsspsi (reg_255)
> : gen_incsspdi (reg_255));
> - tmp = gen_rtx_SET (reg_adj, gen_rtx_MINUS (ptr_mode,
> -reg_adj,
> -GEN_INT (255)));
> - clob = gen_rtx_CLOBBER (VOIDmode, gen_rtx_REG (CCmode, FLAGS_REG));
> - tmp = gen_rtx_PARALLEL (VOIDmode, gen_rtvec (2, tmp, clob));
> - emit_insn (tmp);
> -
> - tmp = gen_rtx_COMPARE (CCmode, reg_adj, GEN_INT (255));
> + emit_insn ((ptr_mode == SImode)
> + ? gen_subsi3 (reg_adj, reg_adj, GEN_INT (255))
> + : gen_subdi3 (reg_adj, reg_adj, GEN_INT (255)));
> + tmp = gen_rtx_COMPARE (CCmode, reg_adj, const0_rtx);
>flags = gen_rtx_REG (CCmode, FLAGS_REG);
>emit_insn (gen_rtx_SET (flags, tmp));
The above part is not correct. The original code compares result with 255, your
patch compares result with 0.
So, the minimum patch (for backport) should just introduce:
--cut here--
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 292de142e90..6c207be3512 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -18695,6 +18695,10 @@
tmp = gen_rtx_PARALLEL (VOIDmode, gen_rtvec (2, tmp, clob));
emit_insn (tmp);
+ tmp = gen_rtx_COMPARE (CCZmode, reg_ssp, const0_rtx);
+ flags = gen_rtx_REG (CCZmode, FLAGS_REG);
+ emit_insn (gen_rtx_SET (flags, tmp));
+
/* Compare and jump over adjustment code. */
noadj_label = gen_label_rtx ();
flags = gen_rtx_REG (CCZmode, FLAGS_REG);
--cut here--
The patch creates correct form of sub insn (tested with cet-sjlj-1.c testcase):
#(insn 15 14 16 2 (parallel [
#(set (reg:CCZ 17 flags)
#(compare:CCZ (minus:DI (reg:DI 0 ax [85])
#(mem:DI (const:DI (plus:DI (symbol_ref:DI ("buf")
[flags 0x2] )
#(const_int 16 [0x10]))) [2 S8 A8]))
#(const_int 0 [0])))
#(set (reg:DI 0 ax [85])
#(minus:DI (reg:DI 0 ax [85])
#(mem:DI (const:DI (plus:DI (symbol_ref:DI ("buf") [flags
0x2] )
#(const_int 16 [0x10]))) [2 S8 A8])))
#]) "cet-sjlj-1.c":16:3 262 {*subdi_2}
# (nil))
subqbuf+16(%rip), %rax # 15[c=8 l=7] *subdi_2/1
[Bug c++/96645] [9/10/11 Regression] std::variant default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645
--- Comment #4 from Jonathan Wakely ---
And libc++'s std::variant is still affected by the same issue, but instead of
the default constructor being deleted it just has the wrong exception
specification:
#include
void testVarStruct()
{
struct DataWithStruct {
struct A {
int number = 5; // compiles, if remove initialization
};
using Member = std::variant;
Member data;
static_assert(std::is_nothrow_default_constructible_v);
};
}
The difference is that GCC defines the std::variant default constructor as
defaulted, but libc++ defines it as:
constexpr variant()
noexcept(is_nothrow_default_constructible_v)
That means the constructor isn't deleted for libc++, it just has the wrong
noexcept-specifier.
It looks like the nested class DataWithStruct::A isn't considered complete
until after DataWithStruct is complete, but I'm not sure why that is.
[Bug c++/94062] Cannot construct tuple from convertible types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94062 --- Comment #17 from m.cencora at gmail dot com --- Ah, I see. I was under the impression, that tuple elements were always stored as base classes, but now I see that it is only the case if element type is empty non-final class.
[Bug analyzer/96642] [11 Regression] ICE in in apply_ctor_to_region, at analyzer/store.cc:418
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96642 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-08-17 --- Comment #1 from David Malcolm --- Thanks for filing this bug; confirmed on x86_64 at least.
[Bug analyzer/96659] New: error: cast from 'const ana::region*' to 'long int' loses precision in store.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96659 Bug ID: 96659 Summary: error: cast from 'const ana::region*' to 'long int' loses precision in store.h Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: trass3r at gmail dot com Target Milestone: --- x86_64-w64-mingw32-g++ -fno-PIE -c -O3 -g -pipe -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -fno-common -DHAVE_CONFIG_H -I. -Ianalyzer -I/mnt/host/sources/gcc-master/gcc -I/mnt/host/sources/gcc-master/gcc/analyzer -I/mnt/host/sources/gcc-master/gcc/../include -I/mnt/host/sources/gcc-master/gcc/../libcpp/include -I/mnt/host/buildWin64/prerequisites/gmp-6.2.0/include -I/mnt/host/buildWin64/prerequisites/mpfr-4.0.2/include -I/mnt/host/buildWin64/prerequisites/mpc-1.1.0/include -I/mnt/host/sources/gcc-master/gcc/../libdecnumber -I/mnt/host/sources/gcc-master/gcc/../libdecnumber/dpd -I../libdecnumber -I/mnt/host/sources/gcc-master/gcc/../libbacktrace -I/mnt/host/buildWin64/prerequisites/isl-0.22.1/include -I/mnt/host/buildWin64/prerequisites/zlib-1.2.11/include -pipe -O3 -g0 -fno-plt -fno-pie -no-pie -fno-pic -march=haswell -I/mnt/host/buildWin64/prerequisites/libiconv-1.16/include -o analyzer/checker-path.o -MT analyzer/checker-path.o -MMD -MP -MF analyzer/.deps/checker-path.TPo /mnt/host/sources/gcc-master/gcc/analyzer/checker-path.cc /mnt/host/sources/gcc-master/gcc/analyzer/store.h:271:47: error: cast from 'const ana::region*' to 'long int' loses precision [-fpermissive] 271 | return (binding_key::impl_hash () ^ (long)m_region); | ^~~~ https://github.com/Trass3r/bleeding-edge-toolchain/runs/992134193
[Bug analyzer/96608] Build failure due to cast to type long on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608 David Malcolm changed: What|Removed |Added CC||trass3r at gmail dot com --- Comment #3 from David Malcolm --- *** Bug 96659 has been marked as a duplicate of this bug. ***
[Bug analyzer/96659] error: cast from 'const ana::region*' to 'long int' loses precision in store.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96659 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from David Malcolm --- Thanks for filing this; marking it as duplicate of PR 96608. *** This bug has been marked as a duplicate of bug 96608 ***
[Bug analyzer/96608] Build failure due to cast to type long on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608 --- Comment #4 from Andrew Pinski --- Do we ever transverse the hashtable that use symbolic_binding? If so using the pointer value should almost never use really.
[Bug analyzer/96608] Build failure due to cast to type long on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608 --- Comment #5 from David Malcolm --- (In reply to Andrew Pinski from comment #4) > Do we ever transverse the hashtable that use symbolic_binding? If so using > the pointer value should almost never use really. Andrew: sorry, I'm having difficulty parsing and understanding your comment. Could you rephrase it please?
[Bug analyzer/96608] Build failure due to cast to type long on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608 --- Comment #6 from Andrew Pinski --- (In reply to David Malcolm from comment #5) > (In reply to Andrew Pinski from comment #4) > > Do we ever transverse the hashtable that use symbolic_binding? If so using > > the pointer value should almost never use really. > > Andrew: sorry, I'm having difficulty parsing and understanding your comment. > Could you rephrase it please? Sory I had a spelling mistake. What I mean is if you ever traversing a hashtable, the hash should not use the value of a pointer because it could change between runs.
[Bug analyzer/96608] Build failure due to cast to type long on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608 --- Comment #7 from David Malcolm --- (In reply to Andrew Pinski from comment #6) > What I mean is if you ever traversing a hashtable, the hash should not use > the value of a pointer because it could change between runs. Thanks. Unfortunately I'm doing that in quite a few places in the new implementation, I think. The new implementation folds instances of symbolic values and regions into unique instances, and then uses pointer equality on them (which is good), and also pointer hashing (which is likely bad, and likely leading to changeable results). I suspect what I need to do is to come up with a deterministic hash for each of these objects that doesn't rely on pointer values, and to use that value instead, rather than their addresses. Given the uniqueness of values/regions per analysis run, I think I'll add a globally unique ID per value/region and base the hash off of that. There are a few places I'm hashing based on trees, for constants and types. Is there a good way to hash those? (avoiding pointer values)
[Bug c++/96634] missing documentation for __builtin_addressof()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96634 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org Last reconfirmed||2020-08-17 Resolution|WONTFIX |--- Ever confirmed|0 |1 Status|RESOLVED|NEW --- Comment #2 from Martin Sebor --- Documenting built-ins, even those meant only to be used internally, is helpful for a number of reasons: to GCC developers ourselves not familiar with the built-in, to users both as a heads up that they should prefer the documented alternative and to help understand compiler messages that refer to the built-in[1], and to implementers of third party tools such as compilers or static analyzers who may not have access to GCC sources for IP reasons. The Clang documentation of the built-in is below https://clang.llvm.org/docs/LanguageExtensions.html#builtin-addressof [*] https://stackoverflow.com/questions/48639190/intel-icc-compile-c-code-cause-error
[Bug analyzer/96608] Build failure due to cast to type long on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96608 --- Comment #8 from Andrew Pinski --- (In reply to David Malcolm from comment #7) > There are a few places I'm hashing based on trees, for constants and types. > Is there a good way to hash those? (avoiding pointer values) Maybe iterative_hash_expr ?
[Bug analyzer/96660] New: [11 regression] ICE and many failures in gcc.dg/analyzer/data-model-1.c after r11-2708
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96660 Bug ID: 96660 Summary: [11 regression] ICE and many failures in gcc.dg/analyzer/data-model-1.c after r11-2708 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:2867118ddda9b56d991c16022f7d3d634ed08313, r11-2708 spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c -fdiagnostics-plain-output -fanalyzer -fdiagnostics-path-format=separate-events -Wanalyzer-too-complex -fanalyzer-call-summaries -S -o data-model-1.s /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c: In function 'test_1': /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c:20:3: warning: TRUE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c: In function 'test_2': /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c:27:3: warning: UNKNOWN /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c:29:3: warning: TRUE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c: In function 'test_3': /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c:36:3: warning: UNKNOWN /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c:38:3: warning: TRUE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c: In function 'test_3a': /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c:47:3: warning: UNKNOWN /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c:49:3: warning: TRUE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c: In function 'test_4': /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c:60:3: warning: TRUE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c: In function 'test_5': /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c:69:3: warning: TRUE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c: In function 'test_5a': /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c:78:3: warning: TRUE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c: In function 'test_6': /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c:86:3: warning: UNKNOWN /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c:88:3: warning: TRUE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c: In function 'test_7': /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c:95:3: warning: UNKNOWN /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c:97:3: warning: TRUE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c: In function 'test_10': /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c:106:3: warning: UNKNOWN /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c:108:3: warning: TRUE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c: In function 'test_11': /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c:119:3: warning: FALSE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c:120:3: warning: TRUE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c:121:3: warning: UNKNOWN /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c:122:3: warning: UNKNOWN /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c:123:3: warning: UNKNOWN /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c:124:3: warning: UNKNOWN /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c:126:3: warning: TRUE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c:127:3: warning: FALSE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c:128:3: warning: TRUE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c:129:3: warning: TRUE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c:130:3: warning: FALSE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c:131:3: warning: FALSE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c: In function 'test_12': /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c:147:3: warning: FALSE /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/analyzer/data-model-1.c: In function 'test_12b': /home/seurer/gcc/git/gcc-test/gcc/testsui
[Bug middle-end/87256] hppa spends huge amount of time in synth_mult()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87256 Andrew Pinski changed: What|Removed |Added CC||mikulas at artax dot karlin.mff.cu ||ni.cz --- Comment #13 from Andrew Pinski --- *** Bug 96649 has been marked as a duplicate of this bug. ***
[Bug target/96649] parisc: very slow compilation when multiplying by a large constatnt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96649 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 87256. *** This bug has been marked as a duplicate of bug 87256 ***
[Bug tree-optimization/96615] Failure to optimize out loop that eventually ends but has no side effects involving decrease of loop counter using an unsigned operation and the loop being done through r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96615 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug c/96606] Shift operator not working correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96606 --- Comment #3 from Andrew Pinski --- (In reply to RyuaNerin from comment #2) > Unsigned long int is 64bit integer in x64. Or rather unsigned long on x86 Linux is 64 bits while on x86 Windows, it is 32bits. There is no bug with GCC here still.
[Bug libgomp/96661] New: configure:16984: error: unsupported system, cannot find Fortran int kind=16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96661 Bug ID: 96661 Summary: configure:16984: error: unsupported system, cannot find Fortran int kind=16 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org CC: burnus at gcc dot gnu.org, jakub at gcc dot gnu.org Target Milestone: --- Host: hppa64-hp-hpux11.11 Target: hppa64-hp-hpux11.11 Build: hppa64-hp-hpux11.11 Whiling configuring libgomp, the following error occurs: configure:16984: error: unsupported system, cannot find Fortran int kind=16, nee ded for omp_depend_kind ## ## ## Cache variables. ## ## ## ac_cv_build=hppa64-hp-hpux11.11 ac_cv_c_compiler_gnu=yes Looks like this was introduced by: 2020-07-23 Tobias Burnus * configure.ac: Add OMP_DEPEND_KIND and OMP_INT128_SIZE. * libgomp_f.h.in (omp_check_defines): Check whether sizeof of determined Fortran kind and C typedef match. * omp_lib.f90.in: Add omp_depened_kind. * omp_lib.h.in: Likewise; fix omp_alloctrait_key_kind. * configure: Regenerate. * Makefile.in: Regenerate. * testsuite/Makefile.in: Regenerate. Guess this is because target doesn't support int128. For the most part, libgomp used to work on this target.
[Bug target/96662] New: s390x uses clc taking variable execution time in crypto code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96662
Bug ID: 96662
Summary: s390x uses clc taking variable execution time in
crypto code
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
In this test case:
void bar (void);
void f1 (unsigned short *p) { if (p[0] < p[1]) bar (); }
void f2 (unsigned int *p) { if (p[0] < p[1]) bar (); }
void f3 (unsigned long long *p) { if (p[0] < p[1]) bar (); }
void f4 (unsigned short *p) { if (p[0] != p[1]) bar (); }
void f5 (unsigned int *p) { if (p[0] != p[1]) bar (); }
void f6 (unsigned long long *p) { if (p[0] != p[1]) bar (); }
void f7 (short int *p) { if (p[0] != p[1]) bar (); }
void f8 (int *p) { if (p[0] != p[1]) bar (); }
void f9 (long long *p) { if (p[0] != p[1]) bar (); }
GCC generates clc on s390x. That is problematical in crypto code, because clc
works like memcmp, which has a variable execution time. So it is theoretically
possible to gauge some information by measuring how long the operation takes
(for 128 or 255 byte long comparisons).
Other arches supposedly generate instructions that take constant time,
therefore don't suffer from this issue.
[Bug c++/94799] [8/9/10 Regression] Calling a member template function fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94799 --- Comment #12 from Marek Polacek --- (In reply to Volker Reichelt from comment #11) > Hi Marek, any news on this one? It's three months now... > Or should I file a new bug for the regression on trunk? No news yet. I've been largely away from upstream GCC for the past two months, but I should have more time now. I hope this will be fixed within the next couple of weeks. Sorry it's taking so long.
[Bug fortran/96613] SIGFPE on min1() with -ffpe-trap=invalid switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96613 --- Comment #5 from anlauf at gcc dot gnu.org --- (In reply to kargl from comment #4) > I thought that this might be a good candidate for frontend fix. > Similar to thomas's frontend optimizations except except the > transformation is always done. That is, we should be able to do > substitutions based on Table 16.3 before we even get to backend. If frontend optimization is preferred, I'll step out of the way. Nevertheless, one also need to address issues like: % cat maxmin.f90 program p implicit none print *, min (2.0, 1.d0) print *, min (2.d0, 1.0) print *, kind (min (2.0, 1.d0)) print *, kind (min (2.d0, 1.0)) end program p % gfc-11 maxmin.f90 && ./a.out 1. 1. 4 8 The only compiler I found having the same is PGI/NVIDIA. OTOH ifort (and similarly sunf95, g95(!)) result in the expected: 1.00 1.00 8 8
[Bug c++/83445] conversion function has too high priority in overload resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83445 Alexander Karzhenkov changed: What|Removed |Added CC||karzh at mail dot ru --- Comment #1 from Alexander Karzhenkov --- Candidate functions considered by overload resolution are Target::Target(Source const&); constexpr Target::Target(Target const&); constexpr Target::Target(Target&&); The first one doesn't require any user-defined conversion and therefore should win. The bug appears to be fixed in gcc 8, but it occurs again in gcc 9 and later versions.
[Bug libgomp/96661] configure:16984: error: unsupported system, cannot find Fortran int kind=16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96661 --- Comment #1 from Tobias Burnus --- (In reply to John David Anglin from comment #0) > Guess this is because target doesn't support int128. For "omp depend", the OpenMP spec requires that an integer type is used – and the libgomp implementation uses two pointer [= 2*sizeof(void*)] for this. If (as I assume) hppa64-hp-hpux11.11 uses 64bit pointers, this indeed means that in128 is needed. In principle, OpenMP should have used some opaque data type (user-defined derived type). But as they didn't think of this when specifying the data type and the best choice for the implementation in GCC was to have storage for two pointers, I now have this problem. I do not see an easy way out; we had the same issue before with GCN and there the solution was to add support for int128, cf. PR 96306. > For the most part, libgomp used to work on this target. Probably still the case when ignoring the 'depend' feature in Fortran...
[Bug libgomp/96661] configure:16984: error: unsupported system, cannot find Fortran int kind=16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96661 --- Comment #2 from dave.anglin at bell dot net --- On 2020-08-17 2:10 p.m., burnus at gcc dot gnu.org wrote: > I do not see an easy way out; we had the same issue before with GCN and there > the solution was to add support for int128, cf. PR 96306. While this probably is possible, there is no library support for __int128. I guess as long as the "long long" type still maps to a 64-bit int this might be okay.
[Bug analyzer/96642] [11 Regression] ICE in in apply_ctor_to_region, at analyzer/store.cc:418
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96642 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:35c5f8fb432c8e68af68ab48c8d3107e7839775e commit r11-2723-g35c5f8fb432c8e68af68ab48c8d3107e7839775e Author: David Malcolm Date: Sat Aug 15 15:34:21 2020 -0400 analyzer: handle &STRING_CST in constant pool initializers [PR96642] In r11-2708-g2867118ddda9b56d991c16022f7d3d634ed08313 I added support to the analyzer for initialization from var_decls in the global constant pool. However, that commit didn't support initialization from ADDR_EXPR of a STRING_CST leading to an ICE seen in data-model-1.c and pr94639.c on arm and powerpc64 at least, and as PR analyzer/96642 on x86_64 at least. This patch adds support for such initializers, fixing the ICE. gcc/analyzer/ChangeLog: PR analyzer/96642 * store.cc (get_svalue_for_ctor_val): New. (binding_map::apply_ctor_to_region): Call it. gcc/testsuite/ChangeLog: PR analyzer/96642 * gcc.dg/analyzer/pr96642.c: New test.
[Bug analyzer/96639] [11 Regression] ICE: Segmentation fault (in useless_type_conversion_p)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96639 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:42c5ae5d7f0ad89b75d93c497fe44b6c66da7e76 commit r11-2724-g42c5ae5d7f0ad89b75d93c497fe44b6c66da7e76 Author: David Malcolm Date: Mon Aug 17 11:40:44 2020 -0400 analyzer: fix ICE due to NULL type [PR96639] gcc/analyzer/ChangeLog: PR analyzer/96639 * region.cc (region::get_subregions_for_binding): Check for "type" being NULL. gcc/testsuite/ChangeLog: PR analyzer/96639 * gcc.dg/analyzer/pr96639.c: New test.
[Bug analyzer/96644] [11 Regression] ICE in get_region_for_unexpected_tree_code, at analyzer/region-model-manager.cc:930
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96644 --- Comment #1 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:b00a83047574eb6f8d1e670ad439609125873506 commit r11-2725-gb00a83047574eb6f8d1e670ad439609125873506 Author: David Malcolm Date: Mon Aug 17 12:30:56 2020 -0400 analyzer: fix ICE on NULL dereference [PR96644] gcc/analyzer/ChangeLog: PR analyzer/96644 * region-model-manager.cc (get_region_for_unexpected_tree_code): Handle ctxt being NULL. gcc/testsuite/ChangeLog: PR analyzer/96644 * gcc.dg/analyzer/pr96644.c: New test.
[Bug fortran/96613] SIGFPE on min1() with -ffpe-trap=invalid switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96613
--- Comment #6 from Steve Kargl ---
On Mon, Aug 17, 2020 at 06:03:31PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96613
>
> --- Comment #5 from anlauf at gcc dot gnu.org ---
> (In reply to kargl from comment #4)
> > I thought that this might be a good candidate for frontend fix.
> > Similar to thomas's frontend optimizations except except the
> > transformation is always done. That is, we should be able to do
> > substitutions based on Table 16.3 before we even get to backend.
>
> If frontend optimization is preferred, I'll step out of the way.
>
> Nevertheless, one also need to address issues like:
>
> % cat maxmin.f90
> program p
> implicit none
> print *, min (2.0, 1.d0)
> print *, min (2.d0, 1.0)
> print *, kind (min (2.0, 1.d0))
> print *, kind (min (2.d0, 1.0))
> end program p
>
> % gfc-11 maxmin.f90 && ./a.out
>1.
>1.
>4
>8
>
> The only compiler I found having the same is PGI/NVIDIA.
>
> OTOH ifort (and similarly sunf95, g95(!)) result in the expected:
>
>1.00
>1.00
>8
>8
Personally, I would rather issue an error if types of the
arguments are not the same, but that ship sailed years ago.
To fix, the above, you'll need to look at iresolve.c
static void
gfc_resolve_minmax (const char *name, gfc_expr *f, gfc_actual_arglist *args)
{
gfc_actual_arglist *a;
f->ts.type = args->expr->ts.type;
f->ts.kind = args->expr->ts.kind;
and re-do the conversion stuff. AFAICT, type conversion is
not handled correctly. The largest kind is found regardless
of the type and this kind with the type of first argument is
used to to do conversion.
[Bug analyzer/96644] [11 Regression] ICE in get_region_for_unexpected_tree_code, at analyzer/region-model-manager.cc:930
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96644 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from David Malcolm --- Thanks for filing this. Should be fixed by the above commit.
[Bug analyzer/96639] [11 Regression] ICE: Segmentation fault (in useless_type_conversion_p)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96639 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/96642] [11 Regression] ICE in in apply_ctor_to_region, at analyzer/store.cc:418
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96642 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Should be fixed by the above commit.
[Bug tree-optimization/96654] Failure to optimize vectorized conversion to `int` with AVX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96654
Uroš Bizjak changed:
What|Removed |Added
Ever confirmed|0 |1
Component|target |tree-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-08-17
--- Comment #1 from Uroš Bizjak ---
The relevant pattern is present in sse.md:
(define_insn "fix_truncv4dfv4si2"
[(set (match_operand:V4SI 0 "register_operand" "=v")
(fix:V4SI (match_operand:V4DF 1 "nonimmediate_operand" "vm")))]
"TARGET_AVX || (TARGET_AVX512VL && TARGET_AVX512F)"
"vcvttpd2dq{y}\t{%1, %0|%0, %1}"
but for some reason not exercised by target-independent part of the compiler.
Confirmed as a tree optimization problem.
[Bug analyzer/96642] [11 Regression] ICE in in apply_ctor_to_region, at analyzer/store.cc:418
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96642 David Malcolm changed: What|Removed |Added CC||seurer at gcc dot gnu.org --- Comment #4 from David Malcolm --- *** Bug 96660 has been marked as a duplicate of this bug. ***
[Bug fortran/96613] SIGFPE on min1() with -ffpe-trap=invalid switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96613
--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #6)
> To fix, the above, you'll need to look at iresolve.c
>
> static void
> gfc_resolve_minmax (const char *name, gfc_expr *f, gfc_actual_arglist *args)
> {
> gfc_actual_arglist *a;
>
> f->ts.type = args->expr->ts.type;
> f->ts.kind = args->expr->ts.kind;
>
> and re-do the conversion stuff. AFAICT, type conversion is
> not handled correctly. The largest kind is found regardless
> of the type and this kind with the type of first argument is
> used to to do conversion.
I played around with other potential testcases. So far it seems
sufficient to just "fix" the simplification:
diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
index eb8b2afeb29..074b50c2e68 100644
--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -4924,6 +4924,8 @@ min_max_choose (gfc_expr *arg, gfc_expr *extremum, int
sign, bool back_val)
switch (arg->ts.type)
{
case BT_INTEGER:
+ if (extremum->ts.kind < arg->ts.kind)
+ extremum->ts.kind = arg->ts.kind;
ret = mpz_cmp (arg->value.integer,
extremum->value.integer) * sign;
if (ret > 0)
@@ -4931,6 +4933,8 @@ min_max_choose (gfc_expr *arg, gfc_expr *extremum, int
sign, bool back_val)
break;
case BT_REAL:
+ if (extremum->ts.kind < arg->ts.kind)
+ extremum->ts.kind = arg->ts.kind;
if (mpfr_nan_p (extremum->value.real))
{
ret = 1;
Not fully regtested though.
[Bug analyzer/96660] [11 regression] ICE and many failures in gcc.dg/analyzer/data-model-1.c after r11-2708
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96660 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from David Malcolm --- The ICE in data-model-1.c's test_49 is a duplicate of PR analyzer/96642 which I've now fixed, in r11-2723-g35c5f8fb432c8e68af68ab48c8d3107e7839775e. I've tested with --target=powerpc64-unknown-linux-gnu with -m32 and -m64, and I'm no longer seeing FAILs in data-model-1.c Marking this one as a duplicate. Sorry about the breakage. *** This bug has been marked as a duplicate of bug 96642 ***
[Bug middle-end/87256] hppa spends huge amount of time in synth_mult()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87256 Sergei Trofimovich changed: What|Removed |Added CC||slyfox at gcc dot gnu.org --- Comment #14 from Sergei Trofimovich --- Created attachment 49069 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49069&action=edit hack-25_all_hppa-faster-synth_mult.patch For those who need to be unblocked right now Gentoo uses the following hack: hack-25_all_hppa-faster-synth_mult.patch I'll ask around in #gcc on how to convert it to proper gcc-friendly hash table based solution discussed above.
[Bug ada/96663] New: Composite type default 'Read attribute does not perform validity checking for defaulted components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96663 Bug ID: 96663 Summary: Composite type default 'Read attribute does not perform validity checking for defaulted components Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: mrhatch97 at gmail dot com Target Milestone: --- Created attachment 49070 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49070&action=edit Source file for the program demonstrating the bug System type: Windows x64 (MINGW provided by MSYS2). Target string is "x86_64-w64-mingw32" Configured with: ../gcc-10.2.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include --libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64 --with-tune=generic --enable-languages=c,lto,c++,fortran,ada,objc,obj-c++ --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-filesystem-ts=yes --enable-libstdcxx-time=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --disable-plugin --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev1, Built by MSYS2 project' --with-bugurl=https://github.com/msys2/MINGW-packages/issues --with-gnu-as --with-gnu-ld Invoked by: gcc -c -gnatVa parse.adb (forwarded from gnat make) Expected behavior: When run with a text file in the same directory as the executable with the name "value.txt" containing a single character 'a', the output "Parse FAILED" should be output to stdout. This should occur because the default implementation of the 'Read attribute should raise Constraint_error in the given setup. This behavior is prescribed by the Ada 2012 Reference Manual (Section 13.13.2, paragraph 35). The 'Read attribute is invoked for a composite type which contains a single scalar component with an implicit initial value of 65. The value read from the file is 'a' (97) which is outside the subtype range of the scalar component. According to the ARM, Constraint_Error should be raised. Actual behavior: Under the described circumstances, the output "Parse OK" is given, followed by "Parsed value is INVALID". No exception is raised, and the parsed value does not belong to its subtype. Note: I added -gnatVa to the compile flags to see if that would affect whether it performed the validity checking, but it didn't change the outcome.
[Bug analyzer/96651] gcc 10 -fanalyzer fail to track (static) global variable in a switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96651 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2020-08-17 --- Comment #1 from David Malcolm --- Thanks for filing this. Note that the analyzer is still experimental. The issue is that the analyzer is treating the values of globals as arbitrary unknown values, ignoring their initialization values, even for code paths from the entrypoint of "main". I'm looking at patching it so that code paths from "main" can assume these initial values (until a call to code outside the TU occurs on the path), so that we can assume that a is 0 at the start of main.
[Bug fortran/96613] SIGFPE on min1() with -ffpe-trap=invalid switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96613 --- Comment #8 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2020-August/054884.html
[Bug middle-end/93644] [10/11 Regression] spurious -Wreturn-local-addr with PHI of PHI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93644 Bruno Haible changed: What|Removed |Added CC||bruno at clisp dot org --- Comment #9 from Bruno Haible --- We now have a generic workaround to this bug: If the bug occurs in a function foo: 1. Rename foo to foo_internal, mark it as '__attribute__ ((__noinline__)) static' and add a 'char stack_buf[1024]' parameter. 2. In the function foo_internal, drop the stack-allocated buffer and use the new parameter instead. 3. Create a new function foo, with the same signature as before, that merely allocates a 'char stack_buf[1024]' on the stack and passes it to foo_internal. For an example, see https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=2a3468c9f263596815a3383c0157ba9a81cf2d24
[Bug libstdc++/96592] [10/11 Regression] Tuple element w/ member reference to incomplete template type rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96592 Marek Polacek changed: What|Removed |Added Last reconfirmed||2020-08-17 Keywords||rejects-valid Ever confirmed|0 |1 Target Milestone|--- |10.3 Component|c++ |libstdc++ CC||mpolacek at gcc dot gnu.org Summary|Tuple element w/ member |[10/11 Regression] Tuple |reference to incomplete |element w/ member reference |template type rejected |to incomplete template type ||rejected Status|UNCONFIRMED |NEW --- Comment #2 from Marek Polacek --- Started with r10-908.
