On 17-09-23 22:51, Jonathan Wakely wrote:
Why would it be trapping? It's loading an int64_t, which might be
uninitialised but it can't trap.
In this context I think that Valgrind is considering that any memory
load could trap.
*f on a std::optional is not like dereferencing a pointer,
Hi, I am currently developing a new pass in the late_ipa_passes phase,
located behind the pass_ipa_pta and in front of the
pass_omp_simd_clone. I now hope that after the pass I developed, the
code can be vectorized, that is, the code that can be vectorized
during the pass_omp_simd_clone.
But not y
On Mon, 18 Sept 2023, 08:03 Paul Floyd via Gcc, wrote:
>
>
> On 17-09-23 22:51, Jonathan Wakely wrote:
>
> >
> > Why would it be trapping? It's loading an int64_t, which might be
> > uninitialised but it can't trap.
>
> In this context I think that Valgrind is considering that any memory
> load c
On Sat, Sep 16, 2023 at 10:38 AM Martin Uecker via Gcc wrote:
>
>
>
> (moved to gcc@)
>
> > On Fri, Sep 15, 2023 at 08:18:28AM -0700, Andrew Pinski wrote:
> > > On Fri, Sep 15, 2023 at 8:12 AM Qing Zhao wrote:
> > > >
> > > >
> > > >
> > > > > On Sep 15, 2023, at 3:43 AM, Xi Ruoyao wrote:
> > >
Hi Florian,
On Thu, 14 Sep 2023, Alexander Monakov wrote:
>
> On Thu, 14 Sep 2023, Florian Weimer via Gcc wrote:
>
> > While rebuilding CentOS Stream with -march=x86-64-v3, I rediscovered
> > several packages had test suite failures because x86-64 suddenly gained
> > FMA support. I say “redisc
On Mon, Sep 18, 2023 at 9:17 AM Hanke Zhang via Gcc wrote:
>
> Hi, I am currently developing a new pass in the late_ipa_passes phase,
> located behind the pass_ipa_pta and in front of the
> pass_omp_simd_clone. I now hope that after the pass I developed, the
> code can be vectorized, that is, the
On Mon, Sep 18, 2023 at 9:24 AM Jonathan Wakely via Gcc wrote:
>
> On Mon, 18 Sept 2023, 08:03 Paul Floyd via Gcc, wrote:
>
> >
> >
> > On 17-09-23 22:51, Jonathan Wakely wrote:
> >
> > >
> > > Why would it be trapping? It's loading an int64_t, which might be
> > > uninitialised but it can't trap
On Mon, Sep 18, 2023 at 9:51 AM Alexander Monakov wrote:
>
> Hi Florian,
>
> On Thu, 14 Sep 2023, Alexander Monakov wrote:
>
> >
> > On Thu, 14 Sep 2023, Florian Weimer via Gcc wrote:
> >
> > > While rebuilding CentOS Stream with -march=x86-64-v3, I rediscovered
> > > several packages had test sui
Thanks! That works!
Richard Biener 于2023年9月18日周一 15:56写道：
>
> On Mon, Sep 18, 2023 at 9:17 AM Hanke Zhang via Gcc wrote:
> >
> > Hi, I am currently developing a new pass in the late_ipa_passes phase,
> > located behind the pass_ipa_pta and in front of the
> > pass_omp_simd_clone. I now hope that
Am Montag, dem 18.09.2023 um 09:31 +0200 schrieb Richard Biener via Gcc:
> On Sat, Sep 16, 2023 at 10:38 AM Martin Uecker via Gcc
> wrote:
> >
> >
> >
> > (moved to gcc@)
> >
> > > On Fri, Sep 15, 2023 at 08:18:28AM -0700, Andrew Pinski wrote:
> > > > On Fri, Sep 15, 2023 at 8:12 AM Qing Zhao
On Mon, Sep 18, 2023 at 10:17 AM Martin Uecker wrote:
>
> Am Montag, dem 18.09.2023 um 09:31 +0200 schrieb Richard Biener via Gcc:
> > On Sat, Sep 16, 2023 at 10:38 AM Martin Uecker via Gcc
> > wrote:
> > >
> > >
> > >
> > > (moved to gcc@)
> > >
> > > > On Fri, Sep 15, 2023 at 08:18:28AM -0700,
On Mon, 18 Sept 2023 at 08:23, Jonathan Wakely wrote:
>
>
>
> On Mon, 18 Sept 2023, 08:03 Paul Floyd via Gcc, wrote:
>>
>>
>>
>> On 17-09-23 22:51, Jonathan Wakely wrote:
>>
>> >
>> > Why would it be trapping? It's loading an int64_t, which might be
>> > uninitialised but it can't trap.
>>
>> In
* Richard Biener:
>> > > GCC contraction behavior is rather inconsistent. It does not contract x
>> > > + x - x without -ffast-math, for example, although I believe it would be
>> > > permissible under the rules that enable FMA contraction. This whole
>
> Is that really just x + x - x? We curre
On Sep 17 2023, Paul Floyd via Gcc wrote:
> However, Valgrind thinks that these transpositions can't be done when
> there are potentially trapping memory loads like *f.
*f is not doing any pointer dereference. It just reads the _M_payload
member of f.
--
Andreas Schwab, SUSE Labs, sch...@suse.
On Mon, Sep 18, 2023 at 12:10 PM Florian Weimer wrote:
>
> * Richard Biener:
>
> >> > > GCC contraction behavior is rather inconsistent. It does not contract
> >> > > x
> >> > > + x - x without -ffast-math, for example, although I believe it would
> >> > > be
> >> > > permissible under the rule
On Mon, 18 Sep 2023, Florian Weimer via Gcc wrote:
> x - x is different because replacing it with 0 doesn't seem to be a
> valid contraction because it's incorrect for NaNs. x + x - x seems to
> be different in this regard, but in our implementation, there might be a
> quirk about sNaNs and qNa
Am Montag, dem 18.09.2023 um 10:06 +0200 schrieb Richard Biener via Gcc:
> On Mon, Sep 18, 2023 at 9:51 AM Alexander Monakov wrote:
> >
> > Hi Florian,
> >
> > On Thu, 14 Sep 2023, Alexander Monakov wrote:
> >
> > >
> > > On Thu, 14 Sep 2023, Florian Weimer via Gcc wrote:
> > >
> > > > While
On Mon, Sep 18, 2023 at 01:26:54PM +0200, Martin Uecker wrote:
> > I think that changing the default to =standard without -ffast-math is
> > reasonable.
> > IIRC the standard allows such default if it's indicated, so it doesn't
> > require
> > =off anywhere.
>
> The C standard requires a pragma t
* Alexander Monakov:
> On Mon, 18 Sep 2023, Florian Weimer via Gcc wrote:
>
>> x - x is different because replacing it with 0 doesn't seem to be a
>> valid contraction because it's incorrect for NaNs. x + x - x seems to
>> be different in this regard, but in our implementation, there might be a
>
* Richard Biener:
>> How much numerical code is compatible with that? For example, David
>> Goldberg's What Every Computer Scientist Should Know About
>> Floating-Point Arithmetic (revised) contains this sentence:
>>
>> | A language definition that does not require parentheses to be honored
>> |
On Mon, 18 Sep 2023, Jakub Jelinek wrote:
> Perhaps we should add some initial hammer approach for the pragma, like
> if you ever use the pragma to turn it somewhere off, it is turned off
> globally, or ditto per function. Might be far easier than trying to
> make it precise that contraction is
On Mon, 18 Sep 2023, Florian Weimer via Gcc wrote:
> But the contraction would still be valid after an isfinite check
> (something that ranger might catch these days), or with with
> -ffinite-math-only in general. Right?
Nope, still not valid for negative zero ('x + x - x' would yield
positive
Am Montag, dem 18.09.2023 um 14:43 +0300 schrieb Alexander Monakov:
> On Mon, 18 Sep 2023, Jakub Jelinek wrote:
>
> > Perhaps we should add some initial hammer approach for the pragma, like
> > if you ever use the pragma to turn it somewhere off, it is turned off
> > globally, or ditto per functio
Hi Richard and Jonathan
On 18/09/2023 10:00, Richard Biener wrote:
On Mon, Sep 18, 2023 at 9:24 AM Jonathan Wakely via Gcc wrote:
Yes, GCC assumes that the reference is bound to a valid object, because C++
requires that to be true. Of course memcheck can't assume that, because one
of its main
On Mon, Sep 18, 2023 at 4:49 PM Floyd, Paul via Gcc wrote:
>
> Hi Richard and Jonathan
>
> On 18/09/2023 10:00, Richard Biener wrote:
> > On Mon, Sep 18, 2023 at 9:24 AM Jonathan Wakely via Gcc
> > wrote:
> >> Yes, GCC assumes that the reference is bound to a valid object, because C++
> >> requi
Am Montag, dem 18.09.2023 um 10:47 +0200 schrieb Richard Biener via Gcc:
> On Mon, Sep 18, 2023 at 10:17 AM Martin Uecker wrote:
> >
> > Am Montag, dem 18.09.2023 um 09:31 +0200 schrieb Richard Biener via Gcc:
> > > On Sat, Sep 16, 2023 at 10:38 AM Martin Uecker via Gcc
> > > wrote:
> > > >
>
On Mon, Sep 18, 2023 at 12:33 AM Richard Biener via Gcc wrote:
>
> On Sat, Sep 16, 2023 at 10:38 AM Martin Uecker via Gcc
> wrote:
> >
> >
> >
> > (moved to gcc@)
> >
> > > On Fri, Sep 15, 2023 at 08:18:28AM -0700, Andrew Pinski wrote:
> > > > On Fri, Sep 15, 2023 at 8:12 AM Qing Zhao wrote:
>
On Mon, 18 Sep 2023, Martin Uecker wrote:
> > The hardest part would be popping the pragma state when leaving a block,
> > which didn't seem difficult (at least for C).
>
> It is fairly restricted where it can appear, it essentially operates
> on the level of compound statements (!= blocks).
* Alexander Monakov:
>> > Contracting 'x + x - x' to fma(x, 2, -x) would be fine.
>>
>> It still changes the result, doesn't it?
>
> I don't follow. I doesn't change the result for infinities (produces
> a NaN). It changes the result when x is so large that 'x + x' is
> not representable (exponen
On Mon, 18 Sep 2023, Florian Weimer wrote:
> Okay, you meant “changing the result” as in “changing the result in a
> permitted way”. Sorry, was confused. So this is a bad example all
> around. Are there better ones (that don't involve FMA)?
If you're looking for something similar to your ori
On Mon, 18 Sep 2023, Alexander Monakov wrote:
>
> On Mon, 18 Sep 2023, Florian Weimer wrote:
>
> > Okay, you meant “changing the result” as in “changing the result in a
> > permitted way”. Sorry, was confused. So this is a bad example all
> > around. Are there better ones (that don't involve
On 18-09-23 16:55, Richard Biener wrote:
What you could do is report the access only on the point of use of
the accessed value? (and disregard when the register holding the
value is re-used)
Hi Richard
Not sure that I follow what you're saying.
memcheck triggers errors like this at condi
Am Montag, dem 18.09.2023 um 19:56 +0200 schrieb Paul Floyd via Gcc:
>
> On 18-09-23 16:55, Richard Biener wrote:
>
> > What you could do is report the access only on the point of use of
> > the accessed value? (and disregard when the register holding the
> > value is re-used)
>
> Hi Richard
>
On 18-09-23 21:09, Martin Uecker wrote:
I do not understand why memcheck cares about the potential trap when
deciding to do the backwards transformation that combines the two
comparisons? Can't you just remove this condition? I assume it
is meant as a filter to only transform cases which re
Am Montag, dem 18.09.2023 um 22:15 +0200 schrieb Paul Floyd via Gcc:
>
> On 18-09-23 21:09, Martin Uecker wrote:
>
> > I do not understand why memcheck cares about the potential trap when
> > deciding to do the backwards transformation that combines the two
> > comparisons? Can't you just remove
On 18-09-23 22:52, Martin Uecker wrote:
Is the problem that valgrind transforms the code before it then
emulates it and the problem is that during emulation the code
could trap?
Yes, roughly the process is
guest ISA -> IR -> IR transformations -> IR optimizations -> execution
The && "idiom
36 matches
Mail list logo
