https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99117
--- Comment #17 from Jakub Jelinek ---
Pedantically speaking if __e in the end reads _M_data of some std::valarray
that happens to alias __p it will be still violating aliasing, but at least
current GCC won't do anything with that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99117
--- Comment #16 from Jakub Jelinek ---
So perhaps (totally untested):
--- libstdc++-v3/include/std/valarray.jj2021-01-04 10:26:02.366967342
+0100
+++ libstdc++-v3/include/std/valarray 2021-02-23 15:16:22.402688841 +0100
@@ -838,7 +838,7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99117
--- Comment #15 from Jakub Jelinek ---
So, based on IRC discussion, the problem is that in:
template template
inline valarray<_Tp>&
valarray<_Tp>::operator=(const _Expr<_Dom, _Tp>& __e)
{
// _GLIBCXX_RESOLVE_LIB_DEFECTS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99117
Jakub Jelinek changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org
--- Comment #14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99117
--- Comment #13 from Richard Biener ---
So the valarray behavior boils down to
struct _Array { int * __restrict m_data; };
void foo (struct _Array dest, int *src, int n)
{
for (int i = 0; i < n; ++i)
dest.m_data[i] = src[i];
}
which we t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99117
--- Comment #12 from rguenther at suse dot de ---
On Tue, 23 Feb 2021, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99117
>
> --- Comment #11 from Jonathan Wakely ---
> So is Jakub wrong in comment 5 when he su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99117
--- Comment #11 from Jonathan Wakely ---
So is Jakub wrong in comment 5 when he suggests that this should "lose" the
__restrict__ qualification?
_Tp* __p (__a._M_data);
Is there a better way to drop that qual so that we can assign somethi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99117
Richard Biener changed:
What|Removed |Added
Keywords|needs-reduction |
--- Comment #10 from Richard Biener -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99117
--- Comment #9 from Jonathan Wakely ---
Something like this prevents the miscompilation, at the cost of an extra copy:
--- a/libstdc++-v3/include/std/valarray
+++ b/libstdc++-v3/include/std/valarray
@@ -838,7 +838,13 @@ _GLIBCXX_BEGIN_NAMESPACE_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99117
--- Comment #8 from rguenther at suse dot de ---
On Tue, 16 Feb 2021, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99117
>
> --- Comment #7 from Jonathan Wakely ---
> (In reply to Jakub Jelinek from comment #5)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99117
--- Comment #7 from Jonathan Wakely ---
(In reply to Jakub Jelinek from comment #5)
> int* p = sum._M_data;
> int* e1 = sum._M_data;
>
> If p and e1 aren't __restrict__ too, shouldn't that be fine?
p (called __p below) doesn't use __restrict__:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99117
--- Comment #6 from rguenther at suse dot de ---
On Tue, 16 Feb 2021, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99117
>
> Jakub Jelinek changed:
>
>What|Removed |Added
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99117
Jakub Jelinek changed:
What|Removed |Added
Known to work|7.5.0, 8.4.0|
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99117
--- Comment #4 from Jonathan Wakely ---
The problem is that sum + e returns an expression template that holds
references to its operands, so that the sum is done lazily.
When that expression template result is assigned back to sum it evaluates t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99117
--- Comment #3 from Jonathan Wakely ---
Regression started with r260318
tree-ssa-sccvn.c (vn_reference_lookup_3): Improve memset handling.
2018-05-17 Richard Biener
* tree-ssa-sccvn.c (vn_reference_lookup_3): Improve memset ha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99117
Richard Biener changed:
What|Removed |Added
Component|middle-end |libstdc++
--- Comment #2 from Richard B
16 matches
Mail list logo
