[Bug fortran/87127] External function not recognised from within an associate block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87127 --- Comment #7 from Paul Thomas --- Author: pault Date: Wed Apr 24 07:27:42 2019 New Revision: 270532 URL: https://gcc.gnu.org/viewcvs?rev=270532&root=gcc&view=rev Log: 2019-04-24 Paul Thomas PR fortran/87127 * resolve.c (check_host_association): If an external function is typed but not declared explicitly to be external, change the old symbol from a variable to an external function. 2019-04-24 Paul Thomas PR fortran/87127 * gfortran.dg/external_procedures_4.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/external_procedures_4.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/resolve.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug c/90219] New: Wrong source location for "cannot convert to a pointer type" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90219
Bug ID: 90219
Summary: Wrong source location for "cannot convert to a pointer
type" warning
Product: gcc
Version: 8.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tbaeder at redhat dot com
Target Milestone: ---
Using gcc 8.3.1 and the following sample code:
static int use_float(float *f) {
return (int)*f;
}
// Type your code here, or load an example.
int square(int num) {
float f = 1.0f;
return use_float((float*)f);
}
it prints the following error:
: In function 'square':
:8:5: error: cannot convert to a pointer type
return use_float((float*)f);
^~
which is highlighting the wrong part of that line. The error message itself
could be improved as well (I forgot to take the address of f of course!) but I
think the cast should be highlighted.
If use_float() is instead called stand-alone and not as part of the return
statment:
int square(int num) {
float f = 1.0f;
use_float((float*)f);
return 1;
}
The source location is slightly better:
: In function 'square':
:8:5: error: cannot convert to a pointer type
use_float((float*)f);
^
[Bug c/90219] Wrong source location for "cannot convert to a pointer type" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90219 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-24 Ever confirmed|0 |1
[Bug c/90219] Wrong source location for "cannot convert to a pointer type" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90219
--- Comment #1 from Jonathan Wakely ---
(In reply to Timm Bäder from comment #0)
> Using gcc 8.3.1 and the following sample code:
>
> static int use_float(float *f) {
> return (int)*f;
> }
>
> // Type your code here, or load an example.
> int square(int num) {
> float f = 1.0f;
> return use_float((float*)f);
> }
>
> it prints the following error:
>
> : In function 'square':
> :8:5: error: cannot convert to a pointer type
> return use_float((float*)f);
> ^~
>
> which is highlighting the wrong part of that line. The error message itself
> could be improved as well (I forgot to take the address of f of course!)
Well if you took the address you wouldn't need to cast it to (float*) so I
don't think the diagnostic should try to infer that you wanted to say &f here.
It certainly looks like the code is attempting to do an invalid type
conversion, so the message seems reasonable. The highlighted location is
definitely poor though.
> but
> I think the cast should be highlighted.
>
> If use_float() is instead called stand-alone and not as part of the return
> statment:
>
> int square(int num) {
> float f = 1.0f;
> use_float((float*)f);
> return 1;
> }
>
> The source location is slightly better:
>
> : In function 'square':
> :8:5: error: cannot convert to a pointer type
> use_float((float*)f);
> ^
Well it's still just the start of the statement, which is not really any
better.
[Bug tree-optimization/90211] [8/9 Regression] ICE: tree check: expected ssa_name, have real_cst in first_readonly_imm_use, at ssa-iterators.h:351
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90211 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Wed Apr 24 08:13:29 2019 New Revision: 270533 URL: https://gcc.gnu.org/viewcvs?rev=270533&root=gcc&view=rev Log: PR tree-optimization/90211 * tree-parloops.c (try_create_reduction_list): Ignore phi arguments which are not SSA_NAMEs. * gcc.dg/autopar/pr90211.c: New test. Added: trunk/gcc/testsuite/gcc.dg/autopar/pr90211.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-parloops.c
[Bug tree-optimization/90208] [7/8/9 Regression] error: EH landing pad label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90208 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Wed Apr 24 08:14:50 2019 New Revision: 270534 URL: https://gcc.gnu.org/viewcvs?rev=270534&root=gcc&view=rev Log: PR tree-optimization/90208 * tree-cfg.c (remove_bb): Move forced labels from removed bbs after labels of new_bb, not before them. * gcc.dg/tsan/pr90208-1.c: New test. * gcc.dg/tsan/pr90208-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tsan/pr90208-1.c trunk/gcc/testsuite/gcc.dg/tsan/pr90208-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093 --- Comment #80 from Jakub Jelinek --- Author: jakub Date: Wed Apr 24 08:16:07 2019 New Revision: 270535 URL: https://gcc.gnu.org/viewcvs?rev=270535&root=gcc&view=rev Log: PR target/89093 * raise-gcc.c (TARGET_ATTRIBUTE): Define. (continue_unwind, personality_body, PERSONALITY_FUNCTION): Add TARGET_ATTRIBUTE. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/raise-gcc.c
[Bug tree-optimization/90208] [7/8 Regression] error: EH landing pad label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90208 Jakub Jelinek changed: What|Removed |Added Known to work||9.0 Summary|[7/8/9 Regression] error: |[7/8 Regression] error: EH |EH landing pad label|landing pad label Known to fail|9.0 | --- Comment #3 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug tree-optimization/90211] [8 Regression] ICE: tree check: expected ssa_name, have real_cst in first_readonly_imm_use, at ssa-iterators.h:351
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90211 Jakub Jelinek changed: What|Removed |Added Summary|[8/9 Regression] ICE: tree |[8 Regression] ICE: tree |check: expected ssa_name, |check: expected ssa_name, |have real_cst in|have real_cst in |first_readonly_imm_use, at |first_readonly_imm_use, at |ssa-iterators.h:351 |ssa-iterators.h:351 --- Comment #4 from Jakub Jelinek --- Fixed for 9.1+ so far.
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093 --- Comment #81 from Jakub Jelinek --- Fixed for Ada as well, only Go left to do.
[Bug middle-end/90075] [7/8 Regression] [AArch64] ICE during RTL pass when member of union passed to copysignf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90075 --- Comment #5 from ramana.radhakrishnan at arm dot com --- The main reason for the ICE is this bit of code here. GCC-8 and earlier have this bit of code in the expansion for copysignsf3 .. rtx op2 = lowpart_subreg (V2SFmode, operands[2], SFmode); .. which looks quite a bit different to the approach taken with copysigndf3 until your rewrite. This gets an input in operands[2] which is subreg:SF (reg:SI 100) and then lower_subreg->simplify_gen_subreg seems to get into a tangle that it can't get out of. That causes simplify_gen_subreg to get confused and that ends up returning a Null pointer as it is unable to do the conversion - we then don't check and thus ICE with a null pointer error. Having looked at it again this morning my reaction is that while there be dragons in subreg's of vector modes and such mode casting, the newer rewrite seems reasonable and is not papering over any underlying modes. For the release branches, I think backporting your patch (and any followups , do you remember any ?) should be fine and we should just do it ./ Ramana From: rearnsha at gcc dot gnu.org Sent: 23 April 2019 15:57 To: ram...@gcc.gnu.org Subject: [Bug middle-end/90075] [7/8 Regression] [AArch64] ICE during RTL pass when member of union passed to copysignf https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90075 --- Comment #4 from Richard Earnshaw --- (In reply to Ramana Radhakrishnan from comment #3) > Seems to have been "fixed" by the commit to fix PR87369, > > Richard, is this something to backport ? Prima-facie , it appears not and we > will need an appropriate fix for the release branches. Given that the patch for PR87369 eliminates the ICE, it's probably preferable for backporting to a separate patch that is only used on the release branches. That patch has now been soaking on trunk for a while now, so is likely to be pretty safe. I am a bit worried however, that the patch papers over a likely trunk ICE that isn't really fixed. It would be nice to investigate further if some additional mitigation is warranted. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
[Bug c/90167] invalid example in GCC documentation wrt. effective type rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90167
--- Comment #4 from Laszlo Ersek (RH) ---
So one way to define the behavior for the original example (from the gcc docs)
would be:
int f(void) {
double d = 3.0;
union a_union u = *(union a_union *)&d;
return u.i;
}
Thanks.
[Bug target/90187] [8/9 Regression] ICE in extract_insn, at recog.c:2304 x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90187 --- Comment #8 from Jakub Jelinek --- Author: jakub Date: Wed Apr 24 09:27:14 2019 New Revision: 270537 URL: https://gcc.gnu.org/viewcvs?rev=270537&root=gcc&view=rev Log: PR target/90187 * config/i386/i386.c (ix86_expand_sse_fp_minmax): Force if_true into a register if both if_true and if_false are MEMs. * g++.target/i386/pr90187.C: New test. Added: trunk/gcc/testsuite/g++.target/i386/pr90187.C Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/90220] New: std::any_cast misbehaves for function and array types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90220
Bug ID: 90220
Summary: std::any_cast misbehaves for function and array types
Product: gcc
Version: 8.3.1
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
This valid program fails to compile:
#include
int main() {
std::any a;
std::any_cast(&a);
}
In file included from a.cc:1:
/home/jwakely/gcc/9/include/c++/9.0.1/any: In instantiation of '_ValueType*
std::any_cast(std::any*) [with _ValueType = void()]':
a.cc:4:27: required from here
/home/jwakely/gcc/9/include/c++/9.0.1/any:544:9: error: invalid static_cast
from type 'void*' to type 'void (*)()'
544 | return static_cast<_ValueType*>(__any_caster<_ValueType>(__any));
| ^
The contained value can never be a function type, so any_cast can just return
nullptr if !is_object_v<_ValueType>.
This program compiles but fails the assertion:
#include
#include
#include
int main()
{
int arr[3];
std::any a(arr);
assert( a.type() == typeid(int*) ); // contained value is decayed
int (*p)[3] = std::any_cast(&a);
assert( p == nullptr );
}
a.out: b.cc:12: int main(): Assertion `p == nullptr' failed.
Aborted (core dumped)
The problem is that __any_caster uses decay_t<_ValueType> to see if the manager
function matches the requested type. That's wrong, because decaying should only
happen on construction, not when accessing the value with any_cast.
[Bug libstdc++/90220] std::any_cast misbehaves for function and array types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90220 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-04-24 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1
[Bug libstdc++/90221] New: Resource leak in object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90221
Bug ID: 90221
Summary: Resource leak in object
Product: gcc
Version: 6.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: venkateshprabu at gmail dot com
Target Milestone: ---
https://github.com/gcc-mirror/gcc/blob/gcc-6_4_0-release/libstdc++-v3/include/bits/shared_ptr_base.h#L646
Is this false positive by coverity ?
Coverity report:
{
633 // _GLIBCXX_RESOLVE_LIB_DEFECTS
634 // 2415. Inconsistency between unique_ptr and shared_ptr
1. Condition __r->get() == NULL, taking false branch.
635 if (__r.get() == nullptr)
636return;
637
638 using _Ptr = typename unique_ptr<_Tp, _Del>::pointer;
639 using _Del2 = typename conditional::value,
640 reference_wrapper::type>,
641 _Del>::type;
642 using _Sp_cd_type
643= _Sp_counted_deleter<_Ptr, _Del2, allocator, _Lp>;
644 using _Alloc = allocator<_Sp_cd_type>;
645 using _Alloc_traits = allocator_traits<_Alloc>;
646 _Alloc __a;
CID 8655046 (#1 of 1): Resource leak in object (CTOR_DTOR_LEAK)
2. alloc_fn: Calling allocation function allocate. [show details]
3. assign: Assigning: __mem =
std::allocator_traits, std::allocator,
(__gnu_cxx::_Lock_policy)2> > >::allocate(__a, 1UL).
647 _Sp_cd_type* __mem = _Alloc_traits::allocate(__a, 1);
648 _Alloc_traits::construct(__a, __mem, __r.release(),
649 __r.get_deleter()); // non-throwing
4. assign: Assigning: this->_M_pi = __mem.
5. ctor_dtor_leak: The constructor allocates field _M_pi of
std::__shared_count<(__gnu_cxx::_Lock_policy)2> but the destructor and whatever
functions it calls do not free it.
650 _M_pi = __mem;
651}
652
653 // Throw bad_weak_ptr when __r._M_get_use_count() == 0.
654 explicit __shared_count(const __weak_count<_Lp>& __r);
655
656 // Does not throw if __r._M_get_use_count() == 0, caller must check.
657 explicit __shared_count(const __weak_count<_Lp>& __r, std::nothrow_t);
658
A1. destructor: This is the destructor implementation.
659 ~__shared_count() noexcept
660 {
661if (_M_pi != nullptr)
662 _M_pi->_M_release();
663 }
664
665 __shared_count(const __shared_count& __r) noexcept
666 : _M_pi(__r._M_pi)
667 {
668if (_M_pi != 0)
669 _M_pi->_M_add_ref_copy();
670 }
671
672 __shared_count&
673 operator=(const __shared_count& __r) noexcept
674 {
675_Sp_counted_base<_Lp>* __tmp = __r._M_pi;
676if (__tmp != _M_pi)
677 {
678if (__tmp != 0)
679 __tmp->_M_add_ref_copy();
680if (_M_pi != 0)
681 _M_pi->_M_release();
CID 285739: Unsafe assignment operator (SELF_ASSIGN) [select issue]
682_M_pi = __tmp;
683 }
684return *this;
685 }
686
687 void
688 _M_swap(__shared_count& __r) noexcept
689 {
690_Sp_counted_base<_Lp>* __tmp = __r._M_pi;
691__r._M_pi = _M_pi;
692_M_pi = __tmp;
693 }
694
695 long
696 _M_get_use_count() const noexcept
697 { return _M_pi != 0 ? _M_pi->_M_get_use_count() : 0; }
698
699 bool
700 _M_unique() const noexcept
701 { return this->_M_get_use_count() == 1; }
702
703 void*
704 _M_get_deleter(const std::type_info& __ti) const noexcept
705 { return _M_pi ? _M_pi->_M_get_deleter(__ti) : nullptr; }
706
707 bool
708 _M_less(const __shared_count& __rhs) const noexcept
709 { return std::less<_Sp_counted_base<_Lp>*>()(this->_M_pi,
__rhs._M_pi); }
710
711 bool
712 _M_less(const __weak_count<_Lp>& __rhs) const noexcept
713 { return std::less<_Sp_counted_base<_Lp>*>()(this->_M_pi,
__rhs._M_pi); }
714
715 // Friend function injected into enclosing namespace and found by ADL
716 friend inline bool
717 operator==(const __shared_count& __a, const __shared_count& __b)
noexcept
718 { return __a._M_pi == __b._M_pi; }
719
720private:
721 friend class __weak_count<_Lp>;
722
723 _Sp_counted_base<_Lp>* _M_pi;
724};
725
726
727 template<_Lock_policy _Lp>
728class __weak_count
729{
730public:
731 constexpr __weak_count() noexcept : _M_pi(nullptr)
732 { }
733
734 __weak_count(const __shared_count<_Lp>& __r) noexcept
735 : _M_pi(__r._M_pi)
736 {
737if (_M_pi != nullptr)
738 _M_pi->_M_weak_add_ref();
739 }
740
741 __weak_count(const __weak_count& __r) noexcept
742 : _M_pi(__r._M_pi)
743 {
744if (_M_pi != nullptr)
745 _M_pi->_M_weak_add_ref();
746 }
747
748 __weak_count(__weak_count&& __r) noe
[Bug target/90187] [8 Regression] ICE in extract_insn, at recog.c:2304 x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90187 Jakub Jelinek changed: What|Removed |Added Summary|[8/9 Regression] ICE in |[8 Regression] ICE in |extract_insn, at|extract_insn, at |recog.c:2304 x86_64 |recog.c:2304 x86_64 --- Comment #9 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug libstdc++/90222] New: Speculative execution data leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90222
Bug ID: 90222
Summary: Speculative execution data leak
Product: gcc
Version: 6.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: venkateshprabu at gmail dot com
Target Milestone: ---
File:
aarch64-gnu-linux/usr/include/c++/6.4.1/aarch64-gnu-linux/bits/ctype_inline.h
Speculative execution data leak
An attacker might be able to read the process' memory.
In std::ctype::scan_is(unsigned short, char const *, char const *):
Accessing memory based on a speculative out-of-bounds access. (CWE-200)
Coverity report:
37namespace std _GLIBCXX_VISIBILITY(default)
38{
39_GLIBCXX_BEGIN_NAMESPACE_VERSION
40
41 bool
42 ctype::
43 is(mask __m, char __c) const
44 { return _M_table[static_cast(__c)] & __m; }
45
46 const char*
47 ctype::
48 is(const char* __low, const char* __high, mask* __vec) const
49 {
50while (__low < __high)
CID 8654704: Nested memory access
(AUDIT.SPECULATIVE_EXECUTION_DATA_LEAK) [select issue]
51 *__vec++ = _M_table[static_cast(*__low++)];
52return __high;
53 }
54
55 const char*
56 ctype::
57 scan_is(mask __m, const char* __low, const char* __high) const
58 {
1. compare_value: Comparing __low in __low < __high.
2. Condition __low < __high, taking true branch.
3. compared_memory_access: Using compared value __low to access memory
in *__low, yielding a potentially sensitive 1-byte value.
CID 8655024 (#1 of 1): Speculative execution data leak
(AUDIT.SPECULATIVE_EXECUTION_DATA_LEAK)
4. sensitive_memory_access: Using sensitive value static_cast(*__low) to access memory in this->_M_table[static_cast(*__low)].
Insert a barrier, such as the lfence instruction, between the
comparison and the memory accesses to prevent speculative execution.
59while (__low < __high
60 && !(_M_table[static_cast(*__low)] & __m))
61 ++__low;
62return __low;
63 }
64
65 const char*
66 ctype::
67 scan_not(mask __m, const char* __low, const char* __high) const
68 {
CID 8654818: Speculative execution data leak
(AUDIT.SPECULATIVE_EXECUTION_DATA_LEAK) [select issue]
69while (__low < __high
70 && (_M_table[static_cast(*__low)] & __m) != 0)
71 ++__low;
72return __low;
73 }
74
75_GLIBCXX_END_NAMESPACE_VERSION
76} // namespace
[Bug libstdc++/90220] std::any_cast misbehaves for function and array types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90220 --- Comment #1 from Jonathan Wakely --- Author: redi Date: Wed Apr 24 09:46:07 2019 New Revision: 270538 URL: https://gcc.gnu.org/viewcvs?rev=270538&root=gcc&view=rev Log: PR libstdc++/90220 Fix std::any_cast for function pointers PR libstdc++/90220 (partial) * include/std/any (any_cast(any*), any_cast(const any*)): Do not attempt ill-formed static_cast to pointers to non-object types. * testsuite/20_util/any/misc/any_cast.cc: Test std::any_cast with function types. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/any trunk/libstdc++-v3/testsuite/20_util/any/misc/any_cast.cc
[Bug libstdc++/90223] New: Speculative execution data leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90223
Bug ID: 90223
Summary: Speculative execution data leak
Product: gcc
Version: 6.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: venkateshprabu at gmail dot com
Target Milestone: ---
File :
/aarch64-gnu-linux/usr/include/c++/6.4.1/aarch64-gnu-linux/bits/ctype_inline.h
scan_not
Speculative execution data leak
An attacker might be able to read the process' memory.
In std::ctype::scan_not(unsigned short, char const *, char const *):
Accessing memory based on a speculative out-of-bounds access. (CWE-200)
Is this false postivie by coverity ??
Coverity report:
37namespace std _GLIBCXX_VISIBILITY(default)
38{
39_GLIBCXX_BEGIN_NAMESPACE_VERSION
40
41 bool
42 ctype::
43 is(mask __m, char __c) const
44 { return _M_table[static_cast(__c)] & __m; }
45
46 const char*
47 ctype::
48 is(const char* __low, const char* __high, mask* __vec) const
49 {
50while (__low < __high)
CID 8654704: Nested memory access
(AUDIT.SPECULATIVE_EXECUTION_DATA_LEAK) [select issue]
51 *__vec++ = _M_table[static_cast(*__low++)];
52return __high;
53 }
54
55 const char*
56 ctype::
57 scan_is(mask __m, const char* __low, const char* __high) const
58 {
CID 8655024: Speculative execution data leak
(AUDIT.SPECULATIVE_EXECUTION_DATA_LEAK) [select issue]
59while (__low < __high
60 && !(_M_table[static_cast(*__low)] & __m))
61 ++__low;
62return __low;
63 }
64
65 const char*
66 ctype::
67 scan_not(mask __m, const char* __low, const char* __high) const
68 {
1. compare_value: Comparing __low in __low < __high.
2. Condition __low < __high, taking true branch.
3. compared_memory_access: Using compared value __low to access memory
in *__low, yielding a potentially sensitive 1-byte value.
CID 8654818 (#1 of 1): Speculative execution data leak
(AUDIT.SPECULATIVE_EXECUTION_DATA_LEAK)
4. sensitive_memory_access: Using sensitive value static_cast(*__low) to access memory in this->_M_table[static_cast(*__low)].
Insert a barrier, such as the lfence instruction, between the
comparison and the memory accesses to prevent speculative execution.
69while (__low < __high
70 && (_M_table[static_cast(*__low)] & __m) != 0)
71 ++__low;
72return __low;
73 }
74
75_GLIBCXX_END_NAMESPACE_VERSION
76} // namespace
[Bug libstdc++/90221] Resource leak in object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90221 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- (In reply to Venkatesh Prabhu from comment #0) > Is this false positive by coverity ? Yes, the destructor frees it.
[Bug libstdc++/90224] New: Resource leak..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90224
Bug ID: 90224
Summary: Resource leak..
Product: gcc
Version: 6.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: venkateshprabu at gmail dot com
Target Milestone: ---
File: /aarch64-gnu-linux/usr/include/c++/6.4.1/bits/unordered_set.hoperator
=
Resource leak
The system resource will not be reclaimed and reused, reducing the future
availability of the resource.
In std::unordered_set,
std::equal_to,
std::allocator>::operator
=(std::unordered_set,
std::equal_to,
std::allocator> const&): Leak of
memory or pointers to system resources (CWE-404)
Is this false positive by coverity ?
Coverity report:
242 unordered_set(initializer_list __l,
243size_type __n,
244const allocator_type& __a)
245 : unordered_set(__l, __n, hasher(), key_equal(), __a)
246 { }
247
248 unordered_set(initializer_list __l,
249size_type __n, const hasher& __hf,
250const allocator_type& __a)
251 : unordered_set(__l, __n, __hf, key_equal(), __a)
252 { }
253
254 /// Copy assignment operator.
255 unordered_set&
1. alloc_arg: operator = allocates memory that is stored into
this->_M_h._M_buckets. [show details]
CID 8652455 (#1 of 1): Resource leak (RESOURCE_LEAK)
2. overwrite_var: Overwriting this->_M_h._M_buckets in call to operator = leaks
the storage that this->_M_h._M_buckets points to. [show details]
256 operator=(const unordered_set&) = default;
257
258 /// Move assignment operator.
259 unordered_set&
260 operator=(unordered_set&&) = default;
261
262 /**
263 * @brief %Unordered_set list assignment operator.
264 * @param __l An initializer_list.
265 *
266 * This function fills an %unordered_set with copies of the elements
in
267 * the initializer list @a __l.
268 *
269 * Note that the assignment completely changes the %unordered_set and
270 * that the resulting %unordered_set's size is the same as the number
271 * of elements assigned. Old data may be lost.
272 */
273 unordered_set&
274 operator=(initializer_list __l)
275 {
276_M_h = __l;
277return *this;
278 }
279
280 /// Returns the allocator object with which the %unordered_set was
281 /// constructed.
282 allocator_type
283 get_allocator() const noexcept
284 { return _M_h.get_allocator(); }
285
286 // size and capacity:
287
288 /// Returns true if the %unordered_set is empty.
289 bool
290 empty() const noexcept
[Bug libstdc++/90220] std::any_cast misbehaves for function and array types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90220 --- Comment #2 from Jonathan Wakely --- The first example compiles OK on trunk now, the second isn't fixed yet.
[Bug libstdc++/90225] New: Resource leak..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90225
Bug ID: 90225
Summary: Resource leak..
Product: gcc
Version: 6.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: venkateshprabu at gmail dot com
Target Milestone: ---
File:
Resource leak
The system resource will not be reclaimed and reused, reducing the future
availability of the resource.
In std::unordered_map, std::allocator>,
std::__cxx11::basic_string,
std::allocator>, std::hash, std::allocator>>,
std::equal_to,
std::allocator>>,
std::allocator, std::allocator> const,
std::__cxx11::basic_string,
std::allocator::operator
=(std::unordered_map, std::allocator>,
std::__cxx11::basic_string,
std::allocator>, std::hash, std::allocator>>,
std::equal_to,
std::allocator>>,
std::allocator, std::allocator> const,
std::__cxx11::basic_string,
std::allocator const &): Leak of memory or pointers to system
resources (CWE-404)
Is this false positive by coverity?
Coverity report:
unordered_map(initializer_list __l,
255size_type __n, const hasher& __hf,
256const allocator_type& __a)
257 : unordered_map(__l, __n, __hf, key_equal(), __a)
258 { }
259
260 /// Copy assignment operator.
261 unordered_map&
1. alloc_arg: operator = allocates memory that is stored into
this->_M_h._M_buckets. [show details]
CID 8650859 (#1 of 1): Resource leak (RESOURCE_LEAK)
2. overwrite_var: Overwriting this->_M_h._M_buckets in call to operator = leaks
the storage that this->_M_h._M_buckets points to. [show details]
262 operator=(const unordered_map&) = default;
263
264 /// Move assignment operator.
265 unordered_map&
266 operator=(unordered_map&&) = default;
267
268 /**
269 * @brief %Unordered_map list assignment operator.
270 * @param __l An initializer_list.
271 *
272 * This function fills an %unordered_map with copies of the elements
in
273 * the initializer list @a __l.
274 *
[Bug target/90226] New: ICE in expand_expr_addr_expr_1, at expr.c:7994
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90226
Bug ID: 90226
Summary: ICE in expand_expr_addr_expr_1, at expr.c:7994
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: powerpc-*-linux-gnu
g++-9.0.0-alpha20190421 snapshot (r270485) ICEs when compiling the following
testcase w/ -m32 -Os -fno-inline -fno-ipa-cp -fno-ipa-sra:
struct sa {
};
struct j4 {
template constexpr
j4 (VY...)
{
}
int at, os = 0;
};
j4 lu { sa { } };
% powerpc-e300c3-linux-gnu-g++-9.0.0-alpha20190421 -m32 -Os -fno-inline
-fno-ipa-cp -fno-ipa-sra -c fzgqcnnp.cc
during RTL pass: expand
fzgqcnnp.cc: In constructor 'constexpr j4::j4(VY ...) [with VY = {sa}]':
fzgqcnnp.cc:8:3: internal compiler error: in expand_expr_addr_expr_1, at
expr.c:7994
8 | }
| ^
0x678a4e expand_expr_addr_expr_1
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/expr.c:7994
0xc147e6 expand_expr_addr_expr
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/expr.c:8107
0xc147e6 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/expr.c:11262
0xaec7c6 expand_normal
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/expr.h:285
0xaec7c6 precompute_register_parameters
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/calls.c:967
0xaec7c6 expand_call(tree_node*, rtx_def*, int)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/calls.c:4001
0xc16305 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/expr.c:11033
0xafda0d expand_expr
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/expr.h:279
0xafda0d expand_call_stmt
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/cfgexpand.c:2724
0xafda0d expand_gimple_stmt_1
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/cfgexpand.c:3691
0xafda0d expand_gimple_stmt
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/cfgexpand.c:3850
0xb0342c expand_gimple_tailcall
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/cfgexpand.c:3897
0xb0342c expand_gimple_basic_block
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/cfgexpand.c:5863
0xb05507 execute
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190421/work/gcc-9-20190421/gcc/cfgexpand.c:6509
[Bug libstdc++/90224] Resource leak..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90224 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- (In reply to Venkatesh Prabhu from comment #0) > Is this false positive by coverity ? Yes, it's just nonsense.
[Bug libstdc++/90223] Speculative execution data leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90223 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-04-24 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Why are you bothering to test and report issues in GCC 6.4.1, which is not a released version, and is from a closed, unsupported branch?
[Bug libstdc++/90222] Speculative execution data leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90222 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-04-24 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Why are you bothering to test and report issues in GCC 6.4.1, which is not a released version, and is from a closed, unsupported branch?
[Bug libstdc++/90225] Resource leak..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90225 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- This is the same nonsense as PR 90224, please stop.
[Bug libstdc++/90225] Resource leak..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90225 --- Comment #2 from Venkatesh Prabhu --- (In reply to Jonathan Wakely from comment #1) > This is the same nonsense as PR 90224, please stop. Sorry for the trouble. Thanks a lot for quicker response.
[Bug libstdc++/90223] Speculative execution data leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90223 --- Comment #2 from Jonathan Wakely --- I already said GCC 6.x is not supported in PR 88673
[Bug libstdc++/90222] Speculative execution data leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90222 --- Comment #2 from Jonathan Wakely --- I already said GCC 6.x is not supported in PR 88673
[Bug middle-end/90075] [7/8 Regression] [AArch64] ICE during RTL pass when member of union passed to copysignf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90075 --- Comment #6 from Richard Earnshaw --- (In reply to ramana.radhakrish...@arm.com from comment #5) > For the release branches, I think backporting your patch (and any followups > , do you remember any ?) should be fine and we should just do it ./ I don't recall any. Certainly none are recorded in the PR.
[Bug c++/90215] [8/9 Regression] ICE with lambda in fold expression over comma and assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90215
--- Comment #3 from Vittorio Romeo ---
Changing the lambda to the following
std::apply([&xs...](auto&... ys)
{
(xs.f([&ys...](auto y)
{
ys = y;
}), ...);
}, t);
produces a different ICE:
:20:9: internal compiler error: Segmentation fault
20 | (xs.f([&ys...](auto y)
| ^
https://gcc.godbolt.org/z/hp2hMN
[Bug middle-end/85164] poly-int.h:845:5: runtime error: signed integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164 --- Comment #18 from David Binderman --- (In reply to rsand...@gcc.gnu.org from comment #14) > Yeah, the patch I committed fixed two separate instances of > undefined overflow, but I think there are a lot more left. Excellent results so far, but I have new data on remaining runtime errors. I tried all the C code in the testsuite with a ubsan version of gcc trunk 270500. I used compiler flags -g -O3 -march=native -Wall. I got 26 runtime errors, of which 20 are poly-int.h C++ and fortran remain untested. I'll get to those soon. Of the C errors, the 6 that aren't poly-int.h, I will report on in other bug reports. Of the 20 runtime errors from poly-int.h, they are produced by this list of C source code files: ./c-c++-common/Warray-bounds-2.c ./c-c++-common/Warray-bounds.c ./gcc.dg/strlenopt-55.c ./gcc.dg/torture/pr84811.c ./gcc.dg/torture/pr84929.c ./gcc.dg/Warray-bounds-22.c ./gcc.dg/Warray-bounds-30.c ./gcc.dg/Warray-bounds-31.c Most of these are array bounds. I'll find out stack backtraces for each of these.
[Bug libffi/90146] Add support for NetBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90146 --- Comment #1 from Richard Biener --- Note that libffi has a different upstream (but we've not updated since quite some time)
[Bug translation/90149] diagnostics containing BIT_FIELD_REF don't conform to diagnostics guideline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90149 --- Comment #6 from Richard Biener --- IMNSHO the IL checker "errors" should continue to use GCC terms since they check the GIMPLE intermediate language. They also shouldn't necessarily be translated (though they may end up user-facing if they turn on -fchecking).
[Bug c++/90170] [7/8/9 Regression] ICE in unify, at cp/pt.c:22209
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90170 Richard Biener changed: What|Removed |Added Keywords||error-recovery Priority|P3 |P4
[Bug middle-end/85164] poly-int.h:845:5: runtime error: signed integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164 --- Comment #19 from David Binderman --- For ./c-c++-common/Warray-bounds-2.c ../../trunk/gcc/poly-int.h:1107:5: runtime error: signed integer overflow: 8 * -9223372036854775796 cannot be represented in type 'long int' #0 0x2ddd587 in poly_int<1u, poly_result::is_poly>::type, long, poly_coeff_pair_traits::is_poly>::type, long>::result_kind>::type> operator*<1u, int, long>(int const&, poly_int_pod<1u, long> const&) ../../trunk/gcc/poly-int.h:1107 #1 0x2ddd587 in ao_ref_init_from_ptr_and_size(ao_ref*, tree_node*, tree_node*) ../../trunk/gcc/tree-ssa-alias.c:703 #2 0x2ea1f49 in initialize_ao_ref_for_dse ../../trunk/gcc/tree-ssa-dse.c:106 #3 0x2ea1f49 in initialize_ao_ref_for_dse ../../trunk/gcc/tree-ssa-dse.c:91 #4 0x2ea784b in dse_dom_walker::dse_optimize_stmt(gimple_stmt_iterator*) ../../trunk/gcc/tree-ssa-dse.c:851 For ./c-c++-common/Warray-bounds.c ../../trunk/gcc/poly-int.h:715:21: runtime error: signed integer overflow: 9223372036854775804 + 4 cannot be represented in type 'long int' #0 0x318ecb2 in poly_int<1u, long>& poly_int<1u, long>::operator+=(poly_int_pod<1u, long> const&) ../../trunk/gcc/poly-int.h:715 #1 0x318ecb2 in vn_reference_compute_hash ../../trunk/gcc/tree-ssa-sccvn.c:657 #2 0x31b26b5 in vn_reference_lookup(tree_node*, tree_node*, vn_lookup_kind, vn_reference_s**, bool) ../../trunk/gcc/tree-ssa-sccvn.c:2714 #3 0x31ea070 in visit_reference_op_load ../../trunk/gcc/tree-ssa-sccvn.c:4091 #4 0x31ea070 in visit_stmt ../../trunk/gcc/tree-ssa-sccvn.c:4509 For /gcc.dg/strlenopt-55.c ../../trunk/gcc/poly-int.h:1095:5: runtime error: signed integer overflow: 9223372036854775805 * 8 cannot be represented in type 'long int' #0 0x31917e4 in poly_int<1u, poly_result::is_poly>::type, poly_coeff_pair_traits::is_poly>::type>::result_kind>::type> operator*<1u, long, int>(poly_int_pod<1u, long> const&, int const&) ../../trunk/gcc/poly-int.h:1095 #1 0x31917e4 in fully_constant_vn_reference_p(vn_reference_s*) ../../trunk/gcc/tree-ssa-sccvn.c:1485 #2 0x31b26c3 in vn_reference_lookup(tree_node*, tree_node*, vn_lookup_kind, vn_reference_s**, bool) ../../trunk/gcc/tree-ssa-sccvn.c:2715 #3 0x31ea070 in visit_reference_op_load ../../trunk/gcc/tree-ssa-sccvn.c:4091 #4 0x31ea070 in visit_stmt ../../trunk/gcc/tree-ssa-sccvn.c:4509 For ./gcc.dg/torture/pr84811.c ../../trunk/gcc/cse.c:2215:34: runtime error: signed integer overflow: 162675373468811328 - -9060696663385964544 cannot be represented in type 'long int' #0 0x4e5f416 in use_related_value ../../trunk/gcc/cse.c:2215 #1 0x4e5f416 in cse_insn ../../trunk/gcc/cse.c:4877 #2 0x4e60b7e in cse_extended_basic_block ../../trunk/gcc/cse.c:6662 #3 0x4e60b7e in cse_main ../../trunk/gcc/cse.c:6841 #4 0x4e680ee in rest_of_handle_cse2 ../../trunk/gcc/cse.c:7743 For /gcc.dg/torture/pr84929.c ../../trunk/gcc/poly-int.h:753:21: runtime error: signed integer overflow: -5621332293356458048 * 8 cannot be represented in type 'long int' #0 0x1929e14 in if_nonpoly, poly_int_traits::is_poly>::type& poly_int<1u, long>::operator*=(int const&) ../../trunk/gcc/poly-int.h:753 #1 0x1929e14 in fold_const_aggregate_ref_1(tree_node*, tree_node* (*)(tree_node*)) ../../trunk/gcc/gimple-fold.c:6992 #2 0x192b422 in gimple_fold_stmt_to_constant_1(gimple*, tree_node* (*)(tree_node*), tree_node* (*)(tree_node*)) ../../trunk/gcc/gimple-fold.c:6426 #3 0x2e1ab24 in ccp_fold ../../trunk/gcc/tree-ssa-ccp.c:1257 #4 0x2e1ab24 in evaluate_stmt ../../trunk/gcc/tree-ssa-ccp.c:1785 For ./gcc.dg/Warray-bounds-22.c ../../trunk/gcc/poly-int.h:1095:5: runtime error: signed integer overflow: 9223372036854775807 * 8 cannot be represented in type 'long int' #0 0xf85e20 in poly_int<1u, poly_result::is_poly>::type, poly_coeff_pair_traits::is_poly>::type>::result_kind>::type> operator*<1u, long, int>(poly_int_pod<1u, long> const&, int const&) ../../trunk/gcc/poly-int.h:1095 #1 0xf85e20 in get_object_alignment_2 ../../trunk/gcc/builtins.c:344 #2 0xf86d9d in get_object_alignment_1(tree_node*, unsigned int*, unsigned long*) ../../trunk/gcc/builtins.c:394 #3 0xf86d9d in get_object_alignment(tree_node*) ../../trunk/gcc/builtins.c:405 #4 0x1690d75 in expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../trunk/gcc/expr.c:10343 For ./gcc.dg/Warray-bounds-30.c ../../trunk/gcc/cse.c:2215:34: runtime error: signed integer overflow: 0 - -9223372036854775808 cannot be represented in type 'long int' #0 0x4e5f416 in use_related_value ../../trunk/gcc/cse.c:2215 #1 0x4e5f416 in cse_insn ../../trunk/gcc/cse.c:4877 #2 0x4e60b7e in cse_extended_basic_block ../../trunk/gcc/cse.c:6662 #3 0x4e60b7e in cse_main ../../trunk/gcc/cse.c:6841 #4 0x4e67ef5 in rest_of_handle_cse ../../trunk/gcc/cse.c:7678 For ./gcc.dg/Warray-bounds-31.c ../../trunk/gcc/poly-int.h:1095:5: runtime error: signed integer overflo
[Bug c++/90173] [9 Regression] ICE: Segmentation fault (in strip_declarator_types)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90173 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug d/90130] gdc.test/runnable/test12.d FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90130 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #3 from Iain Buclaw --- > I think it should be done in r270485. Indeed. It works fine on i386-pc-solaris2.11 and sparc-sun-solaris2.11 with gas. I do get BUS errors in gcc.unwind.pe.read_encoded_value_with_base on Solaris 11/SPARC when using /bin/as, but that's unrelated: there are several more failures that don't occur with gas.
[Bug c/85608] ubsan in cse.c:2194
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85608 --- Comment #4 from David Binderman --- Still going wrong in revision 270500. Here is a stack backtrace: ../../trunk/gcc/cse.c:2215:34: runtime error: signed integer overflow: 1 - -9223 372036854775807 cannot be represented in type 'long int' #0 0x4e5f416 in use_related_value ../../trunk/gcc/cse.c:2215 #1 0x4e5f416 in cse_insn ../../trunk/gcc/cse.c:4877 #2 0x4e60b7e in cse_extended_basic_block ../../trunk/gcc/cse.c:6662 #3 0x4e60b7e in cse_main ../../trunk/gcc/cse.c:6841 #4 0x4e67ef5 in rest_of_handle_cse ../../trunk/gcc/cse.c:7678
[Bug c++/90201] -Werror=useless-cast in move constructir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90201 --- Comment #2 from Dima Pro --- without -Werror=useless-cast no warning for this code at all.(In reply to Jonathan Wakely from comment #1) > N.B. This is a warning, not an error. Reporting that you get an error > because you turned it into an error doesn't change that is a warning :-) without -Werror=useless-cast no warning for this code at all.
[Bug d/90079] SEGV in _aaKeys, _aaValues on 32-bit SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90079 --- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #6 from Iain Buclaw --- > It ended up being a little more work, as the proposed patch had a bug in it. No wonder given that I just started with D ;-) > But it's now done in r270514. Excellent, thanks.
[Bug c++/90227] New: [9 Regression] trunk rejects polymake since r269965
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90227
Bug ID: 90227
Summary: [9 Regression] trunk rejects polymake since r269965
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
template < int b > struct c {
static constexpr int d = b;
typedef c e;
};
template < bool, typename a > using f = a;
template < bool g > using h = c< g >;
template < int g > using i = c< g >;
template < typename... > struct ab {};
template < typename... j > struct k { using e = ab< j... >; };
template < typename > struct ad;
template < typename j, typename... l > struct ad< ab< j, l... > > {
using e = ab< l... >;
};
template < typename > struct ae;
template < typename... m > struct ae< ab< m... > > : i< sizeof...(m) > {};
template < typename af, int, int = ae< af >::d > struct ag;
template < typename... m > struct ag< ab< m... >, 0, 0 > { using e = ab<>; };
template < typename... m, int ah >
struct ag< ab< m... >, 0, ah >
: k< typename ag< typename ad< ab< m... > >::e, ah - 1 >::e > {};
template < typename... m, int ai, int ah >
struct ag< ab< m... >, ai, ah > : ag< typename ad< ab< m... > >::e, ai - 1 >
{};
template < typename, template < typename > class > struct aj;
template < typename... j, template < typename > class ak >
struct aj< ab< j... >, ak > {
using e = ab< typename ak< j >::e... >;
};
template < typename, template < typename > class > struct am;
template < typename > struct an {};
template < typename a, a > using ap = an< a >;
template < long... aq > using ar = an< unsigned long, aq... >;
template < long ao > using as = ap< unsigned long, ao >;
class au {
public:
using e = h< c< false >::d >;
};
template < typename, template < typename > class, typename... >
struct ax : au::e {};
struct az {
using e = ar<>;
};
template < typename > struct bb;
template < typename... j > struct bb< ab< j... > > {
using e = as< sizeof...(j) >;
};
template < typename, typename > struct bc;
template < typename... j, long... ba > struct bc< ab< j... >, ar< ba... > > {
using e = az::e;
};
template < typename j, template < typename > class ak >
struct bb< am< j, ak > > : bc< k<>::e, bb< k<>::e >::e > {};
namespace be {
enum bf { bg };
class bk {
public:
enum bl { bm };
};
struct bn {
static const bk::bl bo = bk::bm;
};
template < typename bq > struct br { using e = bq; };
template < typename, bf, int, typename... > class bs;
template < typename bq, bf bt, int bu, typename... j, long... anchors >
class bs< bq, bt, bu, ab< j... >, ar< anchors... > > : bk {
public:
static const bl bo = bq::bo;
static const long bv = bu;
using bw = int;
using bx = ab< j... >;
using by = typename ag< bx, bu >::e;
using bz = typename ag< bx, bu >::e;
using ca = as< bv >;
using cb = typename br< bq >::e;
using c = decltype(cb()(bw(), by(), bz(), ca()));
};
class cf;
template < typename > struct cg : c< false > {};
template < typename bq, bf bt, int bu, typename... j >
class bs< bq, bt, bu, ab< j... > >
: public bs<
bq, bt, bu, typename aj< ab< j... >, cg >::e,
typename bb< am< typename ag< ab< j... >, bu >::e, cg > >::e > {};
} using be::bf;
using be::cf;
template < typename cj > class ck {
template < typename cl > ck(cl) { c< cj::bo >(); }
static ck n;
};
namespace be {
template < typename > class cm;
template < typename j > using cn = ax< j, cm >;
template < typename, typename co >
void r(co, f< cn< co >::d, void * > = nullptr);
} using be::r;
struct cq : be::bn {
template < typename... cs, typename... ct >
auto operator()(int cu, ab< cs... >, ab< ct... >, ar<>) {
r< cs... >(cu);
}
};
template <>
ck< be::bs< cq, bf::bg, 1, ab< int, cf > > >
ck< be::bs< cq, bf::bg, 1, ab< int, cf > > >::n(0);
at -std=c++14 started to be rejected with r269965.
Unreduced testcase is in https://bugzilla.redhat.com/show_bug.cgi?id=1702533#c0
and slightly tweaked unreduced testcase (to workaround lack of clang++
features, ugh, didn't know it doesn't even have __builtin_va_arg_pack, can't
handle constexpr math builtins etc.) in
https://bugzilla.redhat.com/show_bug.cgi?id=1702533#c2 is still accepted before
r269965 and rejected after it, but both clang++ trunk and icpc 19.0.1 reject
both the unreduced and reduced testcases (both with completely different
errors).
So, whether what polymake does is valid is unclear.
[Bug c++/90227] [9 Regression] trunk rejects polymake since r269965
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90227 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |9.0
[Bug c++/90190] [8 regression] CTAD confuses with {one element} initializer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90190 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/90190] [8 regression] CTAD confuses with {one element} initializer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90190 Richard Biener changed: What|Removed |Added Keywords||rejects-valid Target Milestone|--- |8.4
[Bug tree-optimization/88239] ./gcc.dg/torture/pr84929.c with -O3 -march=native causes ubsan error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88239 --- Comment #3 from David Binderman --- Still going wrong at revision 270500. Here is a stack backtrace: ../../trunk/gcc/tree-ssa-loop-prefetch.c:468:14: runtime error: signed integer o verflow: 7818038963515661296 * 4 cannot be represented in type 'long int' #0 0x30177c3 in idx_analyze_ref ../../trunk/gcc/tree-ssa-loop-prefetch.c:468 #1 0x303b6d8 in for_each_index(tree_node**, bool (*)(tree_node*, tree_node** , void*), void*) ../../trunk/gcc/tree-ssa-loop.c:622 #2 0x30147d3 in analyze_ref ../../trunk/gcc/tree-ssa-loop-prefetch.c:530 #3 0x30147d3 in gather_memory_references_ref ../../trunk/gcc/tree-ssa-loop-p refetch.c:548 #4 0x3018fec in gather_memory_references ../../trunk/gcc/tree-ssa-loop-prefe tch.c:651
[Bug fortran/83118] [7/8/9 Regression] Bad intrinsic assignment of class(*) array component of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118 --- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #17 from Paul Thomas --- > Created attachment 46216 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46216&action=edit > Patch for the remaining problems. > > I am registering this now as a measure of progress towards doing a proper job > of fixing this PR for good. I've just applied the patch to trunk, rebuilt f951 on sparc-sun-solaris2.11 and tested unlimited_polymorphic_30.f03: the test now PASSes for both 32 and 64-bit. I'll include the patch in tonight's bootstrap and let you know if there are any problems elsewhere.
[Bug d/90065] Unaligned accesses on strict-alignment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90065
--- Comment #2 from Iain Buclaw ---
I have my suspicions that the following code will throw an unaligned access
error as well.
shared int var;
void main() {
synchronized { var = 1; }
}
As synchronized statements are lowered to the following equivalent C.
static char __critsec64[48];
_d_criticalenter(& __critsec64);
var = 0;
_d_criticalexit(& __critsec64);
Just going off memory, but I don't think the artificial __critsec variable
would be suitably aligned for use as a pthread_mutex_t.
[Bug debug/90194] ICE in expand_debug_expr, at cfgexpand.c:5244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90194
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-04-24
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
Confirmed. update-address-taken does, after CCP:
af (int xn)
{
void * D.2359;
- void * _2;
[local count: 1073741824]:
# DEBUG BEGIN_STMT
# DEBUG D.2357 => 4
# DEBUG nq => &xn
# DEBUG BEGIN_STMT
- _4 = &xn;
# DEBUG D.2357 => NULL
# DEBUG nq => NULL
- _2 = _4;
- MEM[(struct cb *)_2] = {};
+ xn_5 = VIEW_CONVERT_EXPR({});
+ # DEBUG xn => xn_5
return;
which failed to "fold" the V_C_E. It does reach
rhs = fold_build1 (VIEW_CONVERT_EXPR,
TREE_TYPE (lhs), rhs);
but this does nothing.
[Bug debug/90194] ICE in expand_debug_expr, at cfgexpand.c:5244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90194 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Mine.
[Bug c++/90201] -Werror=useless-cast in move constructir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90201 --- Comment #3 from Jonathan Wakely --- You get a warning with -Wuseless-cast
[Bug libstdc++/90220] std::any_cast misbehaves for function and array types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90220 --- Comment #3 from Jonathan Wakely --- Patch for the second bit posted: https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00927.html
[Bug c++/90201] -Werror=useless-cast in move constructir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90201 --- Comment #4 from Dima Pro --- (In reply to Jonathan Wakely from comment #3) > You get a warning with -Wuseless-cast Yes, sorry. Miss this. Anyway, no useless cast warning should be for this code.
[Bug c++/90228] New: [UBSAN]: get_addr_base_and_unit_offset_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90228 Bug ID: 90228 Summary: [UBSAN]: get_addr_base_and_unit_offset_1 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- From the C++ testsuite, for source code file ./g++.dg/warn/Wplacement-new-size-5.C with gcc trunk version 207500 and compiler flag -O2, I get this: ../../trunk/gcc/poly-int.h:715:21: runtime error: signed integer overflow: 92233 72036854775807 + 1 cannot be represented in type 'long int' #0 0x331775c in poly_int<1u, long>& poly_int<1u, long>::operator+=(pol y_int_pod<1u, long> const&) ../../trunk/gcc/poly-int.h:715 #1 0x331775c in get_addr_base_and_unit_offset_1(tree_node*, poly_int_pod<1u, long>*, tree_node* (*)(tree_node*)) ../../trunk/gcc/tree-dfa.c:796 #2 0x48d in gimple_fold_stmt_to_constant_1(gimple*, tree_node* (*)(tree_ node*), tree_node* (*)(tree_node*)) ../../trunk/gcc/gimple-fold.c:6350 #3 0x36ea4f4 in ccp_fold ../../trunk/gcc/tree-ssa-ccp.c:1257 #4 0x36ea4f4 in evaluate_stmt ../../trunk/gcc/tree-ssa-ccp.c:1785
[Bug target/90202] AVX-512 instructions not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90202 Richard Biener changed: What|Removed |Added Keywords||ra Target||x86_64-*-* i?86-*-* Status|UNCONFIRMED |RESOLVED CC||hjl.tools at gmail dot com Resolution|--- |WORKSFORME --- Comment #3 from Richard Biener --- The same pushes/moves appear for the AVX2 code. I think we have a duplicate for this issue and it appears because we eventually have to align the local stack to be able to spill ymm/zmm registers and we can't fully elide the frame construction after RA. Original issue worksfrme (works as designed), frame issue has a duplicate somewhere.
[Bug lto/90229] New: Interaction among -Wl,--as-needed and LTO results in an undefined symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90229 Bug ID: 90229 Summary: Interaction among -Wl,--as-needed and LTO results in an undefined symbol Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- As seen in few openSUSE packages with LTO enabled: https://bugzilla.opensuse.org/show_bug.cgi?id=1133232 https://bugzilla.opensuse.org/show_bug.cgi?id=1133131 There's some issue: $ cat lib.cc int FLAGS_verbose; $ g++ -shared -fPIC lib.cc -o mylib.so $ g++ -pthread 1.ii libpes.so -Wl,--as-needed -O [OK] But: $ g++ -pthread 1.ii libpes.so -Wl,--as-needed -O -flto /usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/bin/ld: /usr/lib64/gcc/x86_64-suse-linux/8/libstdc++.so: undefined reference to `pthread_create' collect2: error: ld returned 1 exit status
[Bug target/90204] [8/9 Regression] C code is optimized worse than C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90204
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #4 from Richard Biener ---
The difference is that for C++ we directly use DECL_RESULT in the GIMPLE IL
while for C we end up with a copy to it. The C++ FE does
;; Function v test(v, v) (null)
;; enabled by -tree-original
{
struct v res [value-expr: ];
and at the end
<>>;
}
while the C FE uses plain res:
{
struct v res;
...
return res;
}
which in the end also results in try/finally processing for CLOBBERs. Not sure
where the C++ FE decides using for res is fine and whether the C
FE could do the same. Certainly eliding this extra copy is beneficial.
[Bug lto/90229] Interaction among -Wl,--as-needed and LTO results in an undefined symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90229
--- Comment #1 from Martin Liška ---
$ cat 1.ii
extern int FLAGS_verbose;
extern "C" void pthread_create();
void a(const char *b...) {
if (FLAGS_verbose) {
__builtin_va_list ap;
__builtin_va_start(ap, b);
}
}
void a() { pthread_create(); }
int main() { a(""); return 0; }
[Bug lto/90229] Interaction among -Wl,--as-needed and LTO results in an undefined symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90229 Martin Liška changed: What|Removed |Added CC||matz at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #2 from Martin Liška --- CCing my favorite --as-needed experts ;)
[Bug fortran/90207] Debugging generated tree code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90207 --- Comment #1 from Richard Biener --- (In reply to Thomas Koenig from comment #0) > This could also be implemented by a transformation of > what -fdump-tree-original produces into a valid C program, > using data structures from libgfortran. Note this is probably not OK with the FSF (opens up the possibility of using the gfortran frontend with a proprietary backend).
[Bug tree-optimization/90208] [7/8 Regression] error: EH landing pad label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90208 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/90211] [8 Regression] ICE: tree check: expected ssa_name, have real_cst in first_readonly_imm_use, at ssa-iterators.h:351
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90211 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Known to work||9.0 Known to fail||8.3.0
[Bug target/90204] [8/9 Regression] C code is optimized worse than C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90204 --- Comment #5 from Jakub Jelinek --- That would be likely NRV optimization in the C++ FE, but then why doesn't the generic NRV optimization handle it in the middle-end later on?
[Bug middle-end/85164] poly-int.h:845:5: runtime error: signed integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164 --- Comment #20 from rsandifo at gcc dot gnu.org --- > Most of these are array bounds. I'll find out stack backtraces for > each of these. Thanks for the testing. Could you open new PRs for the new backtraces? These are really independent bugs, and it'd be useful to keep this PR specific to the two problems fixed in r270442. > I got 26 runtime errors, of which 20 are poly-int.h FWIW, whether something occurs in poly-int.h or not isn't usually that relevant. A lot of arithmetic that used to be open-coded now goes through functions in poly-int.h, so it tends to show up a lot as the immediate point of failure. But whether the operation triggers UB is usually determined by the operation being done (i.e. by the caller) rather than the way poly-int.h implements it. On x86 targets, what poly-int.h does is usually the same as what the original pre-poly-int code did. This was the case in both of the bugs fixed in r270442 for example.
[Bug c++/90212] [8/9 Regression] by-ref capture of constexpr class object rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90212 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/90213] UBSAN: signed integer overflow: -5621332293356458048 * 8 cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90213 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Lemme fix it.
[Bug tree-optimization/90213] UBSAN: signed integer overflow: -5621332293356458048 * 8 cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90213 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-24 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- The code even says /* TODO: This code seems wrong, multiply then check to see if it fits. */ offset *= tree_to_uhwi (unit_size); offset *= BITS_PER_UNIT; it might be as simple as moving the multiplication above the to_shwi check.
[Bug target/90204] [8/9 Regression] C code is optimized worse than C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90204 --- Comment #6 from rguenther at suse dot de --- On Wed, 24 Apr 2019, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90204 > > --- Comment #5 from Jakub Jelinek --- > That would be likely NRV optimization in the C++ FE, but then why doesn't the > generic NRV optimization handle it in the middle-end later on? Probably getting address-taken due to vectorization / IVOPTs. NRV runs pretty late.
[Bug c++/90215] [8/9 Regression] ICE with lambda in fold expression over comma and assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90215 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug libstdc++/88888] Cannot construct filesystem::path from variable length array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8
--- Comment #1 from Jonathan Wakely ---
I'm not sure we should bother doing anything here. There are various
workarounds possible:
std::filesystem::path p(vla);
std::filesystem::path p({vla, (size_t)i});
std::filesystem::path p = (const char*)vla;
std::filesystem::path p = std::string(vla);
std::filesystem::path p = std::string(vla, i);
std::filesystem::path p = std::string_view(vla);
std::filesystem::path p = std::string_view(vla, i);
[Bug c++/90217] Greater optimization of C++ Code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90217 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |WAITING Last reconfirmed||2019-04-24 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Please attach the testcases.
[Bug libstdc++/88888] Cannot construct filesystem::path from variable length array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8 --- Comment #2 from Jonathan Wakely --- (The versions passing i as the length will do the wrong thing here, because the array actually contains the empty string "", but I'm just showing examples of valid syntax that work with VLAs).
[Bug libstdc++/89728] ctype is underconstrained
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89728 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-24 Ever confirmed|0 |1
[Bug c++/90228] [UBSAN]: get_addr_base_and_unit_offset_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90228 --- Comment #1 from Richard Biener --- Hmm. We return signed offset because the maximum object size is half of the address space. So I think the code is OK and just invalid C input will produce undefined output here. Otherwise we'd need one bit more in precision and sacrifice speed of compilation quite a bit for this hot function.
[Bug c++/90215] [8/9 Regression] ICE with lambda in fold expression over comma and assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90215
--- Comment #4 from Vittorio Romeo ---
Simplified quite a lot, removed `` dependency:
https://gcc.godbolt.org/z/6uNcCN
struct X
{
template
void f(F f)
{
f(0);
}
};
template
void bug(Xs... xs)
{
int i;
[&](auto&... ys)
{
(xs.f([&](auto)
{
ys;
}), ...);
}(i);
}
int main()
{
bug(X{});
}
[Bug libstdc++/89728] ctype is underconstrained
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89728 Jonathan Wakely changed: What|Removed |Added Severity|normal |enhancement
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093 --- Comment #82 from ian at gcc dot gnu.org --- Author: ian Date: Wed Apr 24 12:45:45 2019 New Revision: 270542 URL: https://gcc.gnu.org/viewcvs?rev=270542&root=gcc&view=rev Log: PR target/89093 runtime: mark unwind functions general-regs-only on ARM For https://gcc.gnu.org/PR89093. Change-Id: Ic426b43d633c77104bda01d4e7835bc9ab4695ef Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/173657 Reviewed-by: Ian Lance Taylor Modified: trunk/gcc/go/gofrontend/MERGE trunk/libgo/runtime/go-unwind.c
[Bug lto/90229] Interaction among -Wl,--as-needed and LTO results in an undefined symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90229 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-24 CC||hjl.tools at gmail dot com Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- This is probably a linker bug. 1 1.o 5 207 247afdd8dccf97e2 PREVAILING_DEF_IRONLY _Z1aPKcz 210 247afdd8dccf97e2 PREVAILING_DEF_IRONLY _Z1av 213 247afdd8dccf97e2 PREVAILING_DEF main 228 247afdd8dccf97e2 RESOLVED_DYN FLAGS_verbose 224 247afdd8dccf97e2 UNDEF pthread_create ld is invoked as /usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/bin/ld -plugin /usr/lib64/gcc/x86_64-suse-linux/8/liblto_plugin.so -plugin-opt=/usr/lib64/gcc/x86_64-suse-linux/8/lto-wrapper -plugin-opt=-fresolution=1.res -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lpthread -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --build-id --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib64/gcc/x86_64-suse-linux/8/../../../../lib64/crt1.o /usr/lib64/gcc/x86_64-suse-linux/8/../../../../lib64/crti.o /usr/lib64/gcc/x86_64-suse-linux/8/crtbegin.o -L. -L/usr/lib64/gcc/x86_64-suse-linux/8 -L/usr/lib64/gcc/x86_64-suse-linux/8/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib64/gcc/x86_64-suse-linux/8/../../../../x86_64-suse-linux/lib -L/usr/lib64/gcc/x86_64-suse-linux/8/../../.. 1.o mylib.so --as-needed -lstdc++ -lm -lgcc_s -lgcc -lpthread -lc -lgcc_s -lgcc /usr/lib64/gcc/x86_64-suse-linux/8/crtend.o /usr/lib64/gcc/x86_64-suse-linux/8/../../../../lib64/crtn.o works fine with -fuse-ld=gold.
[Bug c++/90228] [UBSAN]: get_addr_base_and_unit_offset_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90228 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-24 CC||marxin at gcc dot gnu.org Blocks||63426 Ever confirmed|0 |1 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 [Bug 63426] [meta-bug] Issues found with -fsanitize=undefined
[Bug c++/90186] optimizing options -O1 and -O2 produce different results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90186
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Richard Biener ---
Note that using #pragma pack(1) on struct Ipv4 makes u_short members not
naturally aligned and thus code like
void UpdateChecksum()
{
u_long sum(0);
SetChecksum(0);
u_short *buf = (u_short*)ip->Payload();
u_long nwords = ip->PayloadSize() / 2;
for (unsigned i = 0; i < nwords; ++i)
{
sum += ntohs(*buf++);
dereferences pointers to u_short that might not be aligned to a 2 byte
boundary.
Confirmed though, even when using -fno-inline. -fno-strict-aliasing fixes
it. Possibly the very same issue above - using u_short * to access memory
with a different dynamic type. The same happens here:
buf = (u_short*)&ph;
nwords = 6;
for (unsigned i = 0; i < nwords; ++i)
{
sum += ntohs(*buf++);
ph is of type PseudoHeader. You cannot use lvalues of type u_short to
refer to them.
[Bug debug/90197] [8/9 Regression] Cannot step through simple loop at -O -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90197 --- Comment #7 from Jakub Jelinek --- Created attachment 46238 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46238&action=edit gcc9-pr90197-wip.patch Untested WIP patch (for the C FE so far only, C++ needs something similar though).
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #83 from Jakub Jelinek --- Fixed then.
[Bug c++/90227] [9 Regression] trunk rejects polymake since r269965
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90227
Jakub Jelinek changed:
What|Removed |Added
Keywords||rejects-valid
Priority|P3 |P1
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-04-24
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
Ah, unfortunately the originally submitted preprocessed source has been
hand-edited and so clang++ rejected it while g++ 8 still accepted it, I bet in
the category of what can but doesn't have to be diagnosed in uninstantiated
templates. I've hand-edited that back from original polymake sources so that
it compiled with clang++ and creduced again, verifying that it compiles without
errors with g++ 8 as well as clang++ and is rejected by g++ trunk this way.
The result is -std=c++14:
template struct c { static constexpr int d = b; typedef c e; };
template using f = a;
template using h = c;
template using i = c;
template struct ab {};
template struct k { using e = ab; };
template struct ad;
template struct ad> { using e =
ab; };
template struct ae;
template struct ae> : i {};
template ::d> struct ag;
template struct ag, 0, 0> { using e = ab<>; };
template
struct ag, 0, ah> : k>::e, ah -
1>::e> {};
template
struct ag, ai, ah> : ag>::e, ai - 1> {};
template class> struct aj;
template class ak> struct aj, ak>
{
using e = ab::e...>;
};
template struct an;
struct ao { typedef an<0> ap; };
template struct aq {};
template struct as;
template struct as> { typedef
aq ap; };
template using au = typename as::ap;
template using av = aq;
template using aw = au;
struct ay { using e = h::d>; };
template class, typename...>
struct bb : ay::e {};
struct bd { using e = av<>; };
struct bg { using e = bd::e; };
namespace bi {
enum bj { bk };
struct bo { enum n { bp }; };
struct bq { bool br; static const bo::n bs = bo::bp; };
template struct bw { using e = bv; };
template class bx;
template
struct bx, av> : bo {
static const n bs = bv::bs;
static const long ca = sizeof bv::br;
using cb = int;
using cc = ab;
using cd = typename ag::e;
using ce = typename ag::e;
using cf = aw;
using cg = typename bw::e;
using ch = decltype(cg()(cb(), cd(), ce(), cf()));
};
class ck;
template struct cl : c {};
template
struct bx> : public bx,
cl>::e, bg::e> {};
}
using bi::bj;
using bi::ck;
template class co {
template co(p) { c(); }
static co o;
};
namespace bi {
template class cp;
template using cq = bb;
template void cs(cr, f::d, void *> = nullptr);
}
using bi::cs;
struct cu : bi::bq {
template
auto operator()(int q, ab, ab, av<>) {
cs(q);
}
};
template <>
co>>
co>>::o(0);
[Bug target/89952] S/390: Inconsistent CFI info when restoring frame pointer from fpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89952 --- Comment #2 from Andreas Krebbel --- Author: krebbel Date: Wed Apr 24 13:40:38 2019 New Revision: 270544 URL: https://gcc.gnu.org/viewcvs?rev=270544&root=gcc&view=rev Log: S/390: Fix PR89952 incorrect CFI This patch fixes a cases where inconsistent CFI is generated. After restoring the hard frame pointer (r11) from an FPR we have to set the CFA register. In order to be able to set it back to the stack pointer (r15) we have to make sure that r15 has been restored already. The patch also adds a scheduler dependency to prevent the instruction scheduler from swapping the r11 and r15 restore again. gcc/ChangeLog: 2019-04-24 Andreas Krebbel PR target/89952 * config/s390/s390.c (s390_restore_gprs_from_fprs): Restore GPRs from FPRs in reverse order. Generate REG_CFA_DEF_CFA note also for restored hard frame pointer. (s390_sched_dependencies_evaluation): Implement new target hook. (TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK): New macro definition. gcc/testsuite/ChangeLog: 2019-04-24 Andreas Krebbel PR target/89952 * gcc.target/s390/pr89952.c: New test. Added: trunk/gcc/testsuite/gcc.target/s390/pr89952.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/s390/s390.c trunk/gcc/testsuite/ChangeLog
[Bug target/89952] S/390: Inconsistent CFI info when restoring frame pointer from fpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89952 Andreas Krebbel changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Andreas Krebbel --- Fixed upstream with the patch from comment #2
[Bug libstdc++/88888] Cannot construct filesystem::path from variable length array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8 Ville Voutilainen changed: What|Removed |Added CC||ville.voutilainen at gmail dot com --- Comment #3 from Ville Voutilainen --- Work-around #3 looks splendidly sufficient to me, let's close this without further extension-work into this wonderful overload set.
[Bug libstdc++/88888] Cannot construct filesystem::path from variable length array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #4 from Jonathan Wakely --- Agreed.
[Bug fortran/90230] New: newunit in open function is not threadsafe with openmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90230 Bug ID: 90230 Summary: newunit in open function is not threadsafe with openmp Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mweiland at freenet dot de Target Milestone: --- Created attachment 46239 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46239&action=edit Source file to reproduce the error The issue can be reproduced with: gfortran -c -fopenmp minimal.f90 gfortran -fopenmp minimal.o ./a.out It yields: opened file with lun: -10 At line 7 of file minimal.f90 Fortran runtime error: File already opened in another unit It seems to me that the newunit feature of open() is not threadsafe. I get the output: opened file with lun: -11 At line 7 of file minimal.f90 Fortran runtime error: File already opened in another unit Error termination. Backtrace: ... With ifort/14.0 and NagCompiler, this example works, e.g.: ifort -c -fopenmp minimal.f90 ifort -fopenmp minimal.o ./a.out opened file with lun:-130 closed file with lun:-130 opened file with lun:-133 opened file with lun:-131 opened file with lun:-134 opened file with lun:-135 closed file with lun:-134 opened file with lun:-129 closed file with lun:-133 closed file with lun:-131 closed file with lun:-129 opened file with lun:-132 closed file with lun:-132 opened file with lun:-136 opened file with lun:-137 closed file with lun:-137 closed file with lun:-135 opened file with lun:-138 closed file with lun:-138 closed file with lun:-136 Not sure if this is really a bug, since I do not know if newunit is actually supposed to be treadsafe from the Fortran standard.
[Bug d/88654] Hangs in libphobos testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88654 --- Comment #8 from ibuclaw at gcc dot gnu.org --- Author: ibuclaw Date: Wed Apr 24 14:17:34 2019 New Revision: 270545 URL: https://gcc.gnu.org/viewcvs?rev=270545&root=gcc&view=rev Log: libphobos: Skip curl tests if libcurl is not installed on the target. libphobos/ChangeLog: 2019-04-24 Iain Buclaw PR d/88654 * testsuite/lib/libphobos.exp (libphobos-dg-test): Check libphobos_skipped_test_p before running test. (libphobos-dg-prune): New proc. (libphobos_init): Set libphobos_skip_tests. (libphobos_skipped_test_p): New proc. (check_effective_target_libcurl_available): New proc. * testsuite/libphobos.phobos/phobos.exp: Skip curl tests if library not found. * testsuite/libphobos.phobos_shared/phobos_shared.exp: Likewise. Modified: trunk/libphobos/ChangeLog trunk/libphobos/testsuite/lib/libphobos.exp trunk/libphobos/testsuite/libphobos.phobos/phobos.exp trunk/libphobos/testsuite/libphobos.phobos_shared/phobos_shared.exp
[Bug d/88654] Hangs in libphobos testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88654 Iain Buclaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #9 from Iain Buclaw --- (In reply to Jakub Jelinek from comment #0) > 3) and, if libcurl isn't available, I think it would be better to skip the > test as UNSUPPORTED, i.e. add some effective-target that tests if libcurl is > available and if it fails, don't even try to run the test This has been done in r270545, nothing else left do here as far as I can see.
[Bug target/59888] Darwin linker error "illegal text-relocation" with -shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59888 Zaak changed: What|Removed |Added CC||zbeekman at gmail dot com --- Comment #15 from Zaak --- This is preventing gtk-fortran from compiling on macOS with GCC 8.3, AFAICT. cd /tmp/gtk-fortran-20190424-36870-ggjnvc/gtk-fortran-19.04.gtk3.24.8/build/src && /usr/local/Cellar/cmake/3.14.3/bin/cmake -E cmake_link_script CMakeFiles/gtk-fortran_shared.dir/link.txt --verbose=1 /usr/local/bin/gfortran -pthread -O2 -fPIC -dynamiclib -Wl,-headerpad_max_install_names -compatibility_version 0.1.0 -current_version 0.1.0 -o libgtk-3-fortran.0.1.dylib -install_name @rpath/libgtk-3-fortran.0.1.dylib CMakeFiles/gtk-fortran_object.dir/atk-auto.f90.o CMakeFiles/gtk-fortran_object.dir/cairo-auto.f90.o CMakeFiles/gtk-fortran_object.dir/gdk-auto.f90.o CMakeFiles/gtk-fortran_object.dir/gdk-pixbuf-auto.f90.o CMakeFiles/gtk-fortran_object.dir/glib-auto.f90.o CMakeFiles/gtk-fortran_object.dir/gtk.f90.o CMakeFiles/gtk-fortran_object.dir/gtk-hl.f90.o CMakeFiles/gtk-fortran_object.dir/gtk-hl-container.f90.o CMakeFiles/gtk-fortran_object.dir/gtk-hl-button.f90.o CMakeFiles/gtk-fortran_object.dir/gtk-hl-entry.f90.o CMakeFiles/gtk-fortran_object.dir/gtk-hl-tree.f90.o CMakeFiles/gtk-fortran_object.dir/gtk-hl-menu.f90.o CMakeFiles/gtk-fortran_object.dir/gtk-hl-combobox.f90.o CMakeFiles/gtk-fortran_object.dir/gtk-hl-spin-slider.f90.o CMakeFiles/gtk-fortran_object.dir/gtk-hl-chooser.f90.o CMakeFiles/gtk-fortran_object.dir/gtk-hl-dialog.f90.o CMakeFiles/gtk-fortran_object.dir/gtk-hl-progress.f90.o CMakeFiles/gtk-fortran_object.dir/gtk-hl-accelerator.f90.o CMakeFiles/gtk-fortran_object.dir/gtk-hl-infobar.f90.o CMakeFiles/gtk-fortran_object.dir/gtk-hl-assistant.f90.o CMakeFiles/gtk-fortran_object.dir/gtk-hl-misc.f90.o CMakeFiles/gtk-fortran_object.dir/gtk-draw-hl.f90.o CMakeFiles/gtk-fortran_object.dir/gtk-sup.f90.o CMakeFiles/gtk-fortran_object.dir/gdk-pixbuf-hl.f90.o CMakeFiles/gtk-fortran_object.dir/pango-auto.f90.o CMakeFiles/gtk-fortran_object.dir/gdkevents-auto3.f90.o CMakeFiles/gtk-fortran_object.dir/unixonly-auto.f90.o -L/usr/local/Cellar/plplot/5.14.0_1/lib -Wl,-rpath,/usr/local/Cellar/plplot/5.14.0_1/lib /usr/local/lib/libatk-1.0.dylib /usr/local/lib/libcairo.dylib /usr/local/lib/libgdk-3.0.dylib /usr/local/lib/libgdk_pixbuf-2.0.dylib /usr/local/lib/libglib-2.0.dylib /usr/local/lib/libgio-2.0.dylib /usr/local/lib/libgobject-2.0.dylib /usr/local/lib/libgtk-3.0.dylib /usr/local/lib/libpango-1.0.dylib ld: illegal text-relocation to '_hl_gtk_listn_edit_cb' in CMakeFiles/gtk-fortran_object.dir/gtk-hl-tree.f90.o from 'lC72' in CMakeFiles/gtk-fortran_object.dir/gtk-hl-tree.f90.o for architecture x86_64 collect2: error: ld returned 1 exit status make[2]: *** [src/libgtk-3-fortran.0.1.dylib] Error 1 make[1]: *** [src/CMakeFiles/gtk-fortran_shared.dir/all] Error 2 make: *** [all] Error 2
[Bug target/88496] Unnecessary stack adjustment with -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88496
--- Comment #1 from H.J. Lu ---
From PR 90202:
[hjl@gnu-cfl-1 pr90202]$ cat x.ii
struct v {
int val[16];
};
struct v test(struct v a, struct v b) {
struct v res;
for (int i = 0; i < 16; i++)
res.val[i] = a.val[i] + b.val[i];
return res;
}
[hjl@gnu-cfl-1 pr90202]$ make CC=gcc
gcc -O3 -march=skylake -S x.ii
[hjl@gnu-cfl-1 pr90202]$ cat x.s
.file "x.ii"
.text
.p2align 4,,15
.globl _Z4test1vS_
.type _Z4test1vS_, @function
_Z4test1vS_:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq%rdi, %rax
movq%rsp, %rbp
.cfi_def_cfa_register 6
vmovdqu 16(%rbp), %ymm1
vmovdqu 48(%rbp), %ymm2
vpaddd 80(%rbp), %ymm1, %ymm0
vmovdqu %ymm0, (%rdi)
vpaddd 112(%rbp), %ymm2, %ymm0
vmovdqu %ymm0, 32(%rdi)
vzeroupper
popq%rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
[Bug debug/90231] New: ivopts causes iterator in the loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231
Bug ID: 90231
Summary: ivopts causes iterator in the loop
Product: gcc
Version: 8.3.1
Status: UNCONFIRMED
Keywords: wrong-debug
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: aoliva at gcc dot gnu.org, jakub at gcc dot gnu.org,
rguenth at gcc dot gnu.org, rsandifo at gcc dot gnu.org,
unassigned at gcc dot gnu.org
Depends on: 90197
Target Milestone: ---
+++ This bug was initially created as a clone of Bug #90197 +++
In the PR90197 testcase with -g -O2 ivopts results in bad debug info quality,
at least on x86_64-linux.
__attribute__((noipa))
void
test (unsigned int *dst, unsigned int base, int count)
{
for (int i = 0; i < count; ++i, base += 15)
dst[i] = base;
}
int
main (void)
{
unsigned int dst[100];
test (dst, 0x4000, 100);
}
Before ivopts pass, the IL is:
[local count: 105119324]:
[local count: 955630224]:
# base_17 = PHI
# i_18 = PHI <0(5), i_12(6)>
# DEBUG i => i_18
# DEBUG base => base_17
# DEBUG BEGIN_STMT
_1 = (long unsigned int) i_18;
_2 = _1 * 4;
_3 = dst_10(D) + _2;
*_3 = base_17;
# DEBUG BEGIN_STMT
i_12 = i_18 + 1;
# DEBUG i => i_12
base_13 = base_17 + 15;
# DEBUG base => base_13
# DEBUG i => i_12
# DEBUG base => base_13
# DEBUG BEGIN_STMT
if (count_9(D) > i_12)
goto ; [89.00%]
else
goto ; [11.00%]
[local count: 850510900]:
goto ; [100.00%]
The IVOPTS pass keeps the base IV and replaces the i IV with a different one:
[local count: 105119324]:
ivtmp.11_5 = (unsigned long) dst_10(D);
_16 = (unsigned int) count_9(D);
_15 = _16 * 15;
_14 = base_7(D) + _15;
[local count: 955630224]:
# base_17 = PHI
# ivtmp.11_20 = PHI
# DEBUG i => NULL
# DEBUG base => base_17
# DEBUG BEGIN_STMT
_4 = (void *) ivtmp.11_20;
MEM[base: _4, offset: 0B] = base_17;
# DEBUG BEGIN_STMT
# DEBUG D#1 => NULL
# DEBUG i => D#1
base_13 = base_17 + 15;
# DEBUG base => base_13
# DEBUG i => D#1
# DEBUG base => base_13
# DEBUG BEGIN_STMT
ivtmp.11_6 = ivtmp.11_20 + 4;
if (base_13 != _14)
goto ; [89.00%]
else
goto ; [11.00%]
[local count: 850510900]:
goto ; [100.00%]
The problem is that i => NULL and D#1 => NULL; while we don't have any register
holding the i value at runtime through iterations of the loop, I would hope
that ivopts pass has enough information on how to express one IV from another
IV and should be able to emit that information in a form of debug stmts into
the IL. In this case, I guess it can either say that the i at the beginning of
the loop is either (int) ((ivtmp.11_20 - (unsigned long) dst_10(D)) / 4), or
(int) ((base_17 - base_7(D)) / 15). Even if those dst_10(D) or base_7(D)
aren't really used later in the function (that is the case of both in this
function), those can be still live in some register (e.g. count argument is
live in a register) or memory and even if it doesn't, in some cases it could be
expressed through DW_OP_entry_value (the callers sets those up in this
testcase).
It could be as simple as replacing the debug uses of i_18 (the IV that is going
away) with a debug temp decl, either
# DEBUG D#2 = ivtmp.11_20 - ivtmp.11_5
# DEBUG D#3 = D#2 / 4
# DEBUG i => D#3
or similar and let the normal debug handling code do the rest when ivtmp.11_5
is no longer needed or optimized away etc.
I guess one needs to properly think if the to be removed IV is actually
properly expressible through some other IV, in the ivtmp case when that one is
64-bit and the IV is 32-bit and division just by 4 that is clearly the case, in
other cases we could use assumption that signed integer overflow is UB etc.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90197
[Bug 90197] [8/9 Regression] Cannot step through simple loop at -O -g
[Bug debug/90231] ivopts causes iterator in the loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231 Jakub Jelinek changed: What|Removed |Added CC||amker at gcc dot gnu.org Version|8.3.1 |9.0 --- Comment #1 from Jakub Jelinek --- Alex or Bin, could you please have a look into this during GCC 10 stage1?
[Bug d/89432] FAIL: libphobos.unittests/druntime/{static,shared}/core.time on CentOS 5.11, Linux 2.6.18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89432 --- Comment #5 from Iain Buclaw --- Created attachment 46240 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46240&action=edit patch for pr89432 (In reply to Uroš Bizjak from comment #4) > Created attachment 46182 [details] > Proposed patch > > Attached patch introduces DRUNTIME_OS_LINUX_PRE_2639 function that detects > linux version < 2.6.39 and sets LINUX_PRE_2639_FLAG. However, as shown in > the Comment #0, CentOS 5.11 (kernel 2.6.18) lacks several other clock types > besides CLOCK_BOOTTIME, so the patch does not fix the failure for these > older kernels. > > I doubt it is worth pushing this any further, so I'll just attach the patch > here for reference. Now that the unit-test runner has been hauled out properly into dejagnu, I was thinking of this being the better way.
[Bug c++/90227] [9 Regression] trunk rejects polymake since r269965
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90227 --- Comment #2 from Jakub Jelinek --- icc also accepts #c1 with -std=c++14.
[Bug libstdc++/90220] std::any_cast misbehaves for function and array types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90220 --- Comment #4 from Jonathan Wakely --- Author: redi Date: Wed Apr 24 15:17:43 2019 New Revision: 270547 URL: https://gcc.gnu.org/viewcvs?rev=270547&root=gcc&view=rev Log: PR libstdc++/90220 Fix std::any_cast for array types Although the std::any constructors use decay_t to determine the type of the contained value, std::any_cast should use the un-decayed type (and so always fail for function and array types that decay to pointers). Using remove_cv_t is correct, because the condition for std::any_cast to return non-null is operand.type() == typeid(T) and typeid ignores top-level cv-qualifiers. PR libstdc++/90220 * include/std/any (__any_caster): Use remove_cv_t instead of decay_t. Avoid a runtime check for types that can never be stored in std::any. * testsuite/20_util/any/misc/any_cast.cc: Test std::any_cast with array types. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/any trunk/libstdc++-v3/testsuite/20_util/any/misc/any_cast.cc
