On Fri, Jan 31, 2020 at 1:05 PM Uecker, Martin
wrote:
>
> Am Freitag, den 31.01.2020, 09:02 +0100 schrieb Richard Biener:
> > On Thu, Jan 30, 2020 at 6:09 PM Uecker, Martin
> > wrote:
> > >
> > > Am Donnerstag, den 30.01.2020, 16:50 + schrieb Michael Matz:
> > > > Hi,
> > > >
> > > > On Thu,
Am Freitag, den 31.01.2020, 09:02 +0100 schrieb Richard Biener:
> On Thu, Jan 30, 2020 at 6:09 PM Uecker, Martin
> wrote:
> >
> > Am Donnerstag, den 30.01.2020, 16:50 + schrieb Michael Matz:
> > > Hi,
> > >
> > > On Thu, 30 Jan 2020, Uecker, Martin wrote:
> > >
> > > > > guarantees face ser
On Thu, Jan 30, 2020 at 6:09 PM Uecker, Martin
wrote:
>
> Am Donnerstag, den 30.01.2020, 16:50 + schrieb Michael Matz:
> > Hi,
> >
> > On Thu, 30 Jan 2020, Uecker, Martin wrote:
> >
> > > > guarantees face serious implementation difficulties I think
> > > > so the only alternative to PVNI (whi
Am Donnerstag, den 30.01.2020, 16:50 + schrieb Michael Matz:
> Hi,
>
> On Thu, 30 Jan 2020, Uecker, Martin wrote:
>
> > > guarantees face serious implementation difficulties I think
> > > so the only alternative to PVNI (which I think is implementable
> > > but at a optimization opportunity c
Hi,
On Thu, 30 Jan 2020, Michael Matz wrote:
> > and the pointers have the same address, then it would evaluate to true
> > at run-time. If I understand correctly, you somehow want to make this
> > case be UB, but I haven't quite understood how (if it is not the
> > comparison of such pointers
Hi,
On Thu, 30 Jan 2020, Uecker, Martin wrote:
> > guarantees face serious implementation difficulties I think
> > so the only alternative to PVNI (which I think is implementable
> > but at a optimization opportunity cost) is one that makes
> > two pointers with the same value always have the sam
Am Donnerstag, den 30.01.2020, 09:30 +0100 schrieb Richard Biener:
> On Wed, Jan 29, 2020 at 3:00 PM Uecker, Martin
> wrote:
...
> > > I guess I'd me much more happy if PVNI said that when
> > > an integer is converted to a pointer and the integer
> > > is value-equivalent to pointers { p1, p2,
On Wed, Jan 29, 2020 at 3:00 PM Uecker, Martin
wrote:
>
> Am Mittwoch, den 29.01.2020, 09:45 +0100 schrieb Richard Biener:
> > On Tue, Jan 28, 2020 at 1:24 PM Uecker, Martin
> > wrote:
>
> > > >
> > > > Note for the current PTA implementation there's almost no cases we can
> > > > handle conserva
Am Mittwoch, den 29.01.2020, 09:45 +0100 schrieb Richard Biener:
> On Tue, Jan 28, 2020 at 1:24 PM Uecker, Martin
> wrote:
> > >
> > > Note for the current PTA implementation there's almost no cases we can
> > > handle conservatively enough. Consider the simple
> > >
> > > int a[4];
> > > in
On Tue, Jan 28, 2020 at 1:24 PM Uecker, Martin
wrote:
>
> Am Dienstag, den 28.01.2020, 11:01 +0100 schrieb Richard Biener:
> > On Tue, Jan 28, 2020 at 8:20 AM Alexander Monakov
> > wrote:
> > >
> > > On Tue, 28 Jan 2020, Uecker, Martin wrote:
> > >
> > > > > (*) this also shows the level of "obf
On Tue, 28 Jan 2020, Uecker, Martin wrote:
> Unfortunately, this is not as simple. It is not trivial to
> define the set of objects whose "address could have participated
> in the computation"
> [...]
I am not satisfied with the response, but I'm not sure I should
continue arguing here.
Alexande
Am Dienstag, den 28.01.2020, 11:01 +0100 schrieb Richard Biener:
> On Tue, Jan 28, 2020 at 8:20 AM Alexander Monakov wrote:
> >
> > On Tue, 28 Jan 2020, Uecker, Martin wrote:
> >
> > > > (*) this also shows the level of "obfuscation" needed to fool compilers
> > > > to lose provenance knowledge
Am Dienstag, den 28.01.2020, 10:20 +0300 schrieb Alexander Monakov:
> On Tue, 28 Jan 2020, Uecker, Martin wrote:
>
> > > (*) this also shows the level of "obfuscation" needed to fool compilers
> > > to lose provenance knowledge is hard to predict.
> >
> > Well, this is exactly the problem we want
On Tue, Jan 28, 2020 at 8:20 AM Alexander Monakov wrote:
>
> On Tue, 28 Jan 2020, Uecker, Martin wrote:
>
> > > (*) this also shows the level of "obfuscation" needed to fool compilers
> > > to lose provenance knowledge is hard to predict.
> >
> > Well, this is exactly the problem we want to addres
On Tue, 28 Jan 2020, Uecker, Martin wrote:
> > (*) this also shows the level of "obfuscation" needed to fool compilers
> > to lose provenance knowledge is hard to predict.
>
> Well, this is exactly the problem we want to address by defining
> a clear way to do this. Casting to an integer would be
Hi Richard,
thank you for your response.
Am Montag, den 27.01.2020, 15:42 +0100 schrieb Richard Biener:
> On Fri, Jan 24, 2020 at 12:46 AM Uecker, Martin
> wrote:
> >
> > Am Donnerstag, den 23.01.2020, 14:18 +0100 schrieb Richard Biener:
> > > On Wed, Jan 22, 2020 at 12:40 PM Martin Sebor w
On Fri, Jan 24, 2020 at 12:46 AM Uecker, Martin
wrote:
>
> Am Donnerstag, den 23.01.2020, 14:18 +0100 schrieb Richard Biener:
> > On Wed, Jan 22, 2020 at 12:40 PM Martin Sebor wrote:
> > >
> > > On 1/22/20 8:32 AM, Richard Biener wrote:
> > > > On Tue, 21 Jan 2020, Alexander Monakov wrote:
> > >
Am Donnerstag, den 23.01.2020, 14:18 +0100 schrieb Richard Biener:
> On Wed, Jan 22, 2020 at 12:40 PM Martin Sebor wrote:
> >
> > On 1/22/20 8:32 AM, Richard Biener wrote:
> > > On Tue, 21 Jan 2020, Alexander Monakov wrote:
> > >
> > > > On Tue, 21 Jan 2020, Richard Biener wrote:
> > > >
> > >
On Wed, Jan 22, 2020 at 12:40 PM Martin Sebor wrote:
>
> On 1/22/20 8:32 AM, Richard Biener wrote:
> > On Tue, 21 Jan 2020, Alexander Monakov wrote:
> >
> >> On Tue, 21 Jan 2020, Richard Biener wrote:
> >>
> >>> Fourth. That PNVI (I assume it's the whole pointer-provenance stuff)
> >>> wants to g
On 1/22/20 8:32 AM, Richard Biener wrote:
On Tue, 21 Jan 2020, Alexander Monakov wrote:
On Tue, 21 Jan 2020, Richard Biener wrote:
Fourth. That PNVI (I assume it's the whole pointer-provenance stuff)
wants to get the "best" of both which can never be done since a compiler
needs to have a way
On Wed, 22 Jan 2020, Joseph Myers wrote:
> On Tue, 21 Jan 2020, Richard Biener wrote:
>
> > Second. Fact is RTL does not distinguish between pointers and
> > integers and thus any attempt to make something valid when you
> > use integers and invalid when you use pointers is not going to work.
>
On Tue, 21 Jan 2020, Alexander Monakov wrote:
> On Tue, 21 Jan 2020, Richard Biener wrote:
>
> > Fourth. That PNVI (I assume it's the whole pointer-provenance stuff)
> > wants to get the "best" of both which can never be done since a compiler
> > needs to have a way to be conservative - in this
On Tue, 21 Jan 2020, Richard Biener wrote:
> Second. Fact is RTL does not distinguish between pointers and
> integers and thus any attempt to make something valid when you
> use integers and invalid when you use pointers is not going to work.
That simply means that an earlier stage in the compil
On Tue, 21 Jan 2020, Alexander Monakov wrote:
> My intent was more basic. I observed that the paragraph can be interpreted as
> saying that if you have a cast 'I1 = (intptr_t) P1', then perform some
> computations on I1 that do not in any way depend on values of other pointers,
> then casting the
On Tue, 21 Jan 2020, Richard Biener wrote:
> Fourth. That PNVI (I assume it's the whole pointer-provenance stuff)
> wants to get the "best" of both which can never be done since a compiler
> needs to have a way to be conservative - in this area it's conflicting
> conservative treatment which is i
On Tue, 21 Jan 2020, Alexander Monakov wrote:
> On Mon, 20 Jan 2020, Joseph Myers wrote:
>
> > On Mon, 20 Jan 2020, Alexander Monakov wrote:
> >
> > > Hi,
> > >
> > > we have this paragraph in the documentation that attempts to prohibit
> > > something that is allowed by the language. Instead
On Mon, 20 Jan 2020, Joseph Myers wrote:
> On Mon, 20 Jan 2020, Alexander Monakov wrote:
>
> > Hi,
> >
> > we have this paragraph in the documentation that attempts to prohibit
> > something that is allowed by the language. Instead, I think we should
> > say that this generally should work an
On Mon, 20 Jan 2020, Alexander Monakov wrote:
> Hi,
>
> we have this paragraph in the documentation that attempts to prohibit
> something that is allowed by the language. Instead, I think we should
> say that this generally should work and explain that a problem in GCC
> implementation breaks
On Mon, 20 Jan 2020, Sandra Loosemore wrote:
> I'm not happy with this -- we shouldn't be talking about internal concepts
> like GIMPLE and RTL in the GCC user manual. Can we instead talk about which
> user-visible optimization options cause problems, so that users who feel the
> urgent need to w
On 1/20/20 8:08 AM, Alexander Monakov wrote:
Hi,
we have this paragraph in the documentation that attempts to prohibit something
that is allowed by the language. Instead, I think we should say that this
generally should work and explain that a problem in GCC implementation
breaks this.
OK to a
30 matches
Mail list logo
