Am Dienstag, den 18.01.2022, 09:31 +0100 schrieb Richard Biener:
> On Mon, Jan 17, 2022 at 3:11 PM Michael Matz via Gcc wrote:
> > Hello,
> >
> > On Sat, 15 Jan 2022, Martin Uecker wrote:
> >
> > > > Because it interferes with existing optimisations. An explicit
> > > > checkpoint has a clear me
On Mon, Jan 17, 2022 at 3:11 PM Michael Matz via Gcc wrote:
>
> Hello,
>
> On Sat, 15 Jan 2022, Martin Uecker wrote:
>
> > > Because it interferes with existing optimisations. An explicit
> > > checkpoint has a clear meaning. Using every volatile access that way
> > > will hurt performance of code
Hello,
On Sat, 15 Jan 2022, Martin Uecker wrote:
> > Because it interferes with existing optimisations. An explicit
> > checkpoint has a clear meaning. Using every volatile access that way
> > will hurt performance of code that doesn't require that behaviour for
> > correctness.
>
> This is w
Am Samstag, den 15.01.2022, 16:38 -0500 schrieb Paul Koning:
> > On Jan 15, 2022, at 4:28 PM, Martin Sebor wrote:
> >
> > On 1/14/22 07:58, Paul Koning via Gcc wrote:
> > > > On Jan 14, 2022, at 9:15 AM, Michael Matz via Gcc
> > > > wrote:
> > > >
> > > > > ...
> > > > But right now that's equ
> On Jan 15, 2022, at 4:28 PM, Martin Sebor wrote:
>
> On 1/14/22 07:58, Paul Koning via Gcc wrote:
>>> On Jan 14, 2022, at 9:15 AM, Michael Matz via Gcc wrote:
>>>
...
>>> But right now that's equivalent to making it observable,
>>> because we don't have any other terms than observable
On 1/14/22 07:58, Paul Koning via Gcc wrote:
On Jan 14, 2022, at 9:15 AM, Michael Matz via Gcc wrote:
Hello,
On Thu, 13 Jan 2022, Martin Uecker wrote:
Handling all volatile accesses in the very same way would be
possible but quite some work I don't see much value in.
I see some value.
Am Samstag, den 15.01.2022, 16:33 + schrieb Jonathan Wakely:
> On Sat, 15 Jan 2022, 09:00 Martin Uecker, wrote:
>
> > Am Freitag, den 14.01.2022, 19:54 + schrieb Jonathan Wakely:
> > > On Fri, 14 Jan 2022, 14:17 Michael Matz via Gcc,
> > wrote:
> > > > Hello,
> > > >
> > > > On Thu, 13
On Sat, 15 Jan 2022, 09:00 Martin Uecker, wrote:
> Am Freitag, den 14.01.2022, 19:54 + schrieb Jonathan Wakely:
> > On Fri, 14 Jan 2022, 14:17 Michael Matz via Gcc,
> wrote:
> >
> > > Hello,
> > >
> > > On Thu, 13 Jan 2022, Martin Uecker wrote:
> > >
> > > > > > > Handling all volatile acce
Am Freitag, den 14.01.2022, 19:54 + schrieb Jonathan Wakely:
> On Fri, 14 Jan 2022, 14:17 Michael Matz via Gcc, wrote:
>
> > Hello,
> >
> > On Thu, 13 Jan 2022, Martin Uecker wrote:
> >
> > > > > > Handling all volatile accesses in the very same way would be
> > > > > > possible but quite
On Fri, 14 Jan 2022, 14:17 Michael Matz via Gcc, wrote:
> Hello,
>
> On Thu, 13 Jan 2022, Martin Uecker wrote:
>
> > > > > Handling all volatile accesses in the very same way would be
> > > > > possible but quite some work I don't see much value in.
> > > >
> > > > I see some value.
> > > >
> >
Am Freitag, den 14.01.2022, 14:15 + schrieb Michael Matz:
> Hello,
>
> On Thu, 13 Jan 2022, Martin Uecker wrote:
...
> > > I think to define this
> > > all rigorously seems futile (you need a new
> > > category between observable and UB), so it comes
> > > down to compiler QoI on a case b
> On Jan 14, 2022, at 9:15 AM, Michael Matz via Gcc wrote:
>
> Hello,
>
> On Thu, 13 Jan 2022, Martin Uecker wrote:
>
> Handling all volatile accesses in the very same way would be
> possible but quite some work I don't see much value in.
I see some value.
But
Hello,
On Thu, 13 Jan 2022, Martin Uecker wrote:
> > > > Handling all volatile accesses in the very same way would be
> > > > possible but quite some work I don't see much value in.
> > >
> > > I see some value.
> > >
> > > But an alternative could be to remove volatile
> > > from the observ
Am Donnerstag, den 13.01.2022, 16:45 + schrieb Michael Matz:
> Hello,
>
> On Tue, 11 Jan 2022, Martin Uecker via Gcc wrote:
>
> > > Handling all volatile accesses in the
> > > very same way would be possible but quite some work I don't
> > > see much value in.
> >
> > I see some value.
> >
Hello,
On Tue, 11 Jan 2022, Martin Uecker via Gcc wrote:
> > Handling all volatile accesses in the
> > very same way would be possible but quite some work I don't
> > see much value in.
>
> I see some value.
>
> But an alternative could be to remove volatile
> from the observable behavior in
Am Dienstag, den 11.01.2022, 10:13 +0100 schrieb Richard Biener:
> On Tue, Jan 11, 2022 at 9:17 AM Martin Uecker wrote:
> > Am Dienstag, den 11.01.2022, 08:11 +0100 schrieb Richard Biener:
> > > On Mon, Jan 10, 2022 at 6:36 PM Martin Uecker wrote:
> > > > Am Montag, den 10.01.2022, 10:04 +0100 sc
On 11/01/2022 08:11, Richard Biener via Gcc wrote:
> On Mon, Jan 10, 2022 at 6:36 PM Martin Uecker wrote:
>>
>
> I realize that UB in a + b isn't (usually) observable but
> UB resulting in traps are.
>
> So I'm still wondering why you think that 'volatile' makes
> a critical difference we oug
On Tue, Jan 11, 2022 at 9:17 AM Martin Uecker wrote:
>
> Am Dienstag, den 11.01.2022, 08:11 +0100 schrieb Richard Biener:
> > On Mon, Jan 10, 2022 at 6:36 PM Martin Uecker wrote:
> > > Am Montag, den 10.01.2022, 10:04 +0100 schrieb Richard Biener:
>
> Hi Richard,
>
> > > > > For volatile, it seem
Am Dienstag, den 11.01.2022, 08:11 +0100 schrieb Richard Biener:
> On Mon, Jan 10, 2022 at 6:36 PM Martin Uecker wrote:
> > Am Montag, den 10.01.2022, 10:04 +0100 schrieb Richard Biener:
Hi Richard,
> > > > For volatile, it seems this would need some tweaks.
> > >
> > > Yes, likewise when re-or
On Mon, Jan 10, 2022 at 6:36 PM Martin Uecker wrote:
>
> Am Montag, den 10.01.2022, 10:04 +0100 schrieb Richard Biener:
> > On Sat, Jan 8, 2022 at 10:09 PM Martin Uecker via Gcc
> > wrote:
> > > Am Samstag, den 08.01.2022, 10:35 -0800 schrieb Andrew Pinski:
> > > > On Sat, Jan 8, 2022 at 12:33 A
Am Montag, den 10.01.2022, 10:04 +0100 schrieb Richard Biener:
> On Sat, Jan 8, 2022 at 10:09 PM Martin Uecker via Gcc wrote:
> > Am Samstag, den 08.01.2022, 10:35 -0800 schrieb Andrew Pinski:
> > > On Sat, Jan 8, 2022 at 12:33 AM Martin Uecker via Gcc
> > > wrote:
> > > > Hi Richard,
> > > >
>
On Sat, Jan 8, 2022 at 10:09 PM Martin Uecker via Gcc wrote:
>
> Am Samstag, den 08.01.2022, 10:35 -0800 schrieb Andrew Pinski:
> > On Sat, Jan 8, 2022 at 12:33 AM Martin Uecker via Gcc
> > wrote:
> > >
> > > Hi Richard,
> > >
> > > I have a question regarding reodering of volatile
> > > accesse
Am Samstag, den 08.01.2022, 10:35 -0800 schrieb Andrew Pinski:
> On Sat, Jan 8, 2022 at 12:33 AM Martin Uecker via Gcc wrote:
> >
> > Hi Richard,
> >
> > I have a question regarding reodering of volatile
> > accesses and trapping operations. My initial
> > assumption (and hope) was that compile
On Sat, Jan 8, 2022 at 12:33 AM Martin Uecker via Gcc wrote:
>
>
> Hi Richard,
>
> I have a question regarding reodering of volatile
> accesses and trapping operations. My initial
> assumption (and hope) was that compilers take
> care to avoid creating traps that are incorrectly
> ordered relativ
> Most C programmers would assume that volatile accesses already
> provides this guarantee, so actually doing so would be good.
I'm a little skeptical of this statement: if it was true, how come the most
recent version of the standard does not provide it 30 years after the language
was first sta
Am Samstag, den 08.01.2022, 16:03 +0100 schrieb David Brown:
> On 08/01/2022 09:32, Martin Uecker via Gcc wrote:
> > Hi Richard,
> >
> > I have a question regarding reodering of volatile
> > accesses and trapping operations. My initial
> > assumption (and hope) was that compilers take
> > care to
Am Samstag, den 08.01.2022, 15:41 +0100 schrieb Eric Botcazou:
> > Yes, although I think potentially trapping ops
> > are not moved before calls (as this would be
> > incorrect). So do you think it would be feasable
> > to prevent this for volatile too?
>
> Feasible probably, but why would this b
On 08/01/2022 09:32, Martin Uecker via Gcc wrote:
>
> Hi Richard,
>
> I have a question regarding reodering of volatile
> accesses and trapping operations. My initial
> assumption (and hope) was that compilers take
> care to avoid creating traps that are incorrectly
> ordered relative to observa
> Yes, although I think potentially trapping ops
> are not moved before calls (as this would be
> incorrect). So do you think it would be feasable
> to prevent this for volatile too?
Feasible probably, but why would this be desirable in C? It's not Java!
--
Eric Botcazou
On Sat, 8 Jan 2022, Martin Uecker via Gcc wrote:
Am Samstag, den 08.01.2022, 13:41 +0100 schrieb Richard Biener:
On January 8, 2022 9:32:24 AM GMT+01:00, Martin Uecker
wrote:
Hi Richard,
thank you for your quick response!
I have a question regarding reodering of volatile
accesses and tra
Am Samstag, den 08.01.2022, 13:41 +0100 schrieb Richard Biener:
> On January 8, 2022 9:32:24 AM GMT+01:00, Martin Uecker
> wrote:
> > Hi Richard,
thank you for your quick response!
> > I have a question regarding reodering of volatile
> > accesses and trapping operations. My initial
> > assumpt
On January 8, 2022 9:32:24 AM GMT+01:00, Martin Uecker
wrote:
>
>Hi Richard,
>
>I have a question regarding reodering of volatile
>accesses and trapping operations. My initial
>assumption (and hope) was that compilers take
>care to avoid creating traps that are incorrectly
>ordered relative to o
Hi Richard,
I have a question regarding reodering of volatile
accesses and trapping operations. My initial
assumption (and hope) was that compilers take
care to avoid creating traps that are incorrectly
ordered relative to observable behavior.
I had trouble finding examples, and my cursory
gla
33 matches
Mail list logo