Re: C provenance semantics proposal
On Wed, Apr 24, 2019 at 8:41 PM Jeff Law wrote: > > On 4/24/19 4:19 AM, Richard Biener wrote: > > On Thu, Apr 18, 2019 at 3:42 PM Jeff Law wrote: > >> > >> On 4/18/19 6:20 AM, Uecker, Martin wrote: > >>> Am Donnerstag, den 18.04.2019, 11:45 +0100 schrieb Peter Sewell: > On Thu, 18 Apr 2019 at 10:32, Richard Biener > wrote: > >>> > >>> > An equality test of two pointers, on the other hand, doesn't necessarily > mean that they are interchangeable. I don't see any good way to > avoid that in a provenance semantics, where a one-past > pointer might sometimes compare equal to a pointer to an > adjacent object but be illegal for accessing it. > >>> > >>> As I see it, there are essentially four options: > >>> > >>> 1.) Compilers do not use conditional equivalences for > >>> optimizations of pointers (or only when additional > >>> conditions apply which make it safe) > >> I know this will hit DOM and CSE. I wouldn't be surprised if it touches > >> VRP as well, maybe PTA. It seems simple enough though :-) > > > > Also touches fundamental PHI-OPT transforms like > > > > if (a == b) > > ... > > > > # c = PHI > > > > where we'd lose eliding such a conditional. IMHO that's bad > > and very undesirable. > But if we only suppress this optimization for pointers is it that terrible? I've at least seen a lot of cases with c = PHI for null pointer checks. It's just we're going to chase a lot of cases down even knowing RTL will fuck up later big times. > > > >>> > >>> 3.) We make comparison have the side effect that > >>> afterwards any of the two pointers could have any > >>> of the two provenances. (with disambiguitation > >>> similar to what we have for casts). > >> This could have some interesting effects on PTA. Richi? > > > > I played with this and doing this in an incomplete way like > > just handling > > > > if (a == b) > > > > as two-way assignment during constraint building is possible. > > But that's not enough of course since every call is implicitely > > producing equivalences between everything [escaped] ... > > which makes points-to degrade to a point where it is useless. > But the calls aren't generating conditional equivalences. I must be > missing something here. if (compare_a_and_b (a, b)) ... yes, they are not creating conditional equivalences that can be propagated out (w/o IPA info). But we compute points-to early, then inline (exposing the propagation opportunity), preserving the points-to result. > You're the expert in this space, so if you say > it totally degrades PTA, then it's a non-starter. Well, it's possible to fix all testcases that get thrown to us but what I have difficulties with is designing a way to follow the proposed standard. Btw, I've tried the trivial points-to patch for conditionals only and even that regressed points-to testcases. > > > > So I think we need a working scheme where points-to doesn't > > degrade from equivalencies being computed and the compiler > > being free to introduce equivalences as well as copy-propagate > > those. > > > > Honestly I can't come up with a working solution to this > > problem. > > > >> > >>> > >>> 4.) Compilers make sure that exposed objects never > >>> are allocated next to each other (as Jens proposed). > >> Ugh. Not sure how you enforce that. Consider that the compiler may > >> ultimately have no control over layout of data in static storage. > > > > Make everything 1 byte larger. > Not a bad idea. I suspect the embedded folks would go bananas though. Maybe, but those folks are also using -fno-strict-aliasing ... Anyhow, my issue is that I don't see a clean design that would follow the proposed standard wording (even our current desired implementation behavior btw!) and not degrade simple testcases :/ Richard. > jeff >
Re: C provenance semantics proposal
On Wed, Apr 24, 2019 at 11:18 PM Peter Sewell wrote: > > On 24/04/2019, Jeff Law wrote: > > On 4/24/19 4:19 AM, Richard Biener wrote: > >> On Thu, Apr 18, 2019 at 3:42 PM Jeff Law wrote: > >>> > >>> On 4/18/19 6:20 AM, Uecker, Martin wrote: > Am Donnerstag, den 18.04.2019, 11:45 +0100 schrieb Peter Sewell: > > On Thu, 18 Apr 2019 at 10:32, Richard Biener > > wrote: > > > > An equality test of two pointers, on the other hand, doesn't > > necessarily > > mean that they are interchangeable. I don't see any good way to > > avoid that in a provenance semantics, where a one-past > > pointer might sometimes compare equal to a pointer to an > > adjacent object but be illegal for accessing it. > > As I see it, there are essentially four options: > > 1.) Compilers do not use conditional equivalences for > optimizations of pointers (or only when additional > conditions apply which make it safe) > >>> I know this will hit DOM and CSE. I wouldn't be surprised if it touches > >>> VRP as well, maybe PTA. It seems simple enough though :-) > >> > >> Also touches fundamental PHI-OPT transforms like > >> > >> if (a == b) > >> ... > >> > >> # c = PHI > >> > >> where we'd lose eliding such a conditional. IMHO that's bad > >> and very undesirable. > > But if we only suppress this optimization for pointers is it that terrible? > > As far as I can see right now, there isn't a serious alternative. > Suppose x and y are adjacent, p=&x+1, and q=&y, so p==q might > be true (either in a semantics for the source-language == that just > compares the concrete representations or in one that's allowed > but not required to be provenance-sensitive). It's not possible > to simultaneously have *p UB (which AIUI the compiler has to > have in the intermediate language, to make alias analysis sound), > *q not UB, and p interchangeable with q.Am I missing something? No, you are not missing anything. We do have this issue right now, independent of standard wordings. But the standard has that, too, not allowing *(&x + 1), allowing the compare and allowing *&y. Isn't that a defect as well? Richard. > Peter > > > > > > 3.) We make comparison have the side effect that > afterwards any of the two pointers could have any > of the two provenances. (with disambiguitation > similar to what we have for casts). > >>> This could have some interesting effects on PTA. Richi? > >> > >> I played with this and doing this in an incomplete way like > >> just handling > >> > >> if (a == b) > >> > >> as two-way assignment during constraint building is possible. > >> But that's not enough of course since every call is implicitely > >> producing equivalences between everything [escaped] ... > >> which makes points-to degrade to a point where it is useless. > > But the calls aren't generating conditional equivalences. I must be > > missing something here. You're the expert in this space, so if you say > > it totally degrades PTA, then it's a non-starter. > > > >> > >> So I think we need a working scheme where points-to doesn't > >> degrade from equivalencies being computed and the compiler > >> being free to introduce equivalences as well as copy-propagate > >> those. > >> > >> Honestly I can't come up with a working solution to this > >> problem. > >> > >>> > > 4.) Compilers make sure that exposed objects never > are allocated next to each other (as Jens proposed). > >>> Ugh. Not sure how you enforce that. Consider that the compiler may > >>> ultimately have no control over layout of data in static storage. > >> > >> Make everything 1 byte larger. > > Not a bad idea. I suspect the embedded folks would go bananas though. > > > > jeff > > > >
Re: C provenance semantics proposal
On 25/04/2019, Richard Biener wrote: > On Wed, Apr 24, 2019 at 11:18 PM Peter Sewell > wrote: >> >> On 24/04/2019, Jeff Law wrote: >> > On 4/24/19 4:19 AM, Richard Biener wrote: >> >> On Thu, Apr 18, 2019 at 3:42 PM Jeff Law wrote: >> >>> >> >>> On 4/18/19 6:20 AM, Uecker, Martin wrote: >> Am Donnerstag, den 18.04.2019, 11:45 +0100 schrieb Peter Sewell: >> > On Thu, 18 Apr 2019 at 10:32, Richard Biener >> > wrote: >> >> >> > An equality test of two pointers, on the other hand, doesn't >> > necessarily >> > mean that they are interchangeable. I don't see any good way to >> > avoid that in a provenance semantics, where a one-past >> > pointer might sometimes compare equal to a pointer to an >> > adjacent object but be illegal for accessing it. >> >> As I see it, there are essentially four options: >> >> 1.) Compilers do not use conditional equivalences for >> optimizations of pointers (or only when additional >> conditions apply which make it safe) >> >>> I know this will hit DOM and CSE. I wouldn't be surprised if it >> >>> touches >> >>> VRP as well, maybe PTA. It seems simple enough though :-) >> >> >> >> Also touches fundamental PHI-OPT transforms like >> >> >> >> if (a == b) >> >> ... >> >> >> >> # c = PHI >> >> >> >> where we'd lose eliding such a conditional. IMHO that's bad >> >> and very undesirable. >> > But if we only suppress this optimization for pointers is it that >> > terrible? >> >> As far as I can see right now, there isn't a serious alternative. >> Suppose x and y are adjacent, p=&x+1, and q=&y, so p==q might >> be true (either in a semantics for the source-language == that just >> compares the concrete representations or in one that's allowed >> but not required to be provenance-sensitive). It's not possible >> to simultaneously have *p UB (which AIUI the compiler has to >> have in the intermediate language, to make alias analysis sound), >> *q not UB, and p interchangeable with q.Am I missing something? > > No, you are not missing anything. We do have this issue right now, > independent of standard wordings. But the standard has that, too, > not allowing *(&x + 1), allowing the compare and allowing *&y. > Isn't that a defect as well? In the source-language semantics, it's ok for p==q to not imply that p and q are interchangeable, and if compilers are doing provenance-based alias analysis (so address equality doesn't imply equally-readable/writable), it's pretty much inescapable. Hence why (without knowing much about the optimisations that actually go on) it's tempting to suggest that for pointer equality comparison one could just not infer that interchangeability. I'd be very interested to know the actual cost of that. (The standard does also have a defect in its definition of equality - on the one hand, it says that &x+1==&y comparison must be true if they are adjacent, but on the other (in DR260) that everything might be provenance-aware. My preference would be to resolve that by requiring source-language == to not be provenance aware, but I think this is a more-or-less independent thing.) Peter
Re: C provenance semantics proposal
On Thu, Apr 25, 2019 at 3:03 PM Peter Sewell wrote: > > On 25/04/2019, Richard Biener wrote: > > On Wed, Apr 24, 2019 at 11:18 PM Peter Sewell > > wrote: > >> > >> On 24/04/2019, Jeff Law wrote: > >> > On 4/24/19 4:19 AM, Richard Biener wrote: > >> >> On Thu, Apr 18, 2019 at 3:42 PM Jeff Law wrote: > >> >>> > >> >>> On 4/18/19 6:20 AM, Uecker, Martin wrote: > >> Am Donnerstag, den 18.04.2019, 11:45 +0100 schrieb Peter Sewell: > >> > On Thu, 18 Apr 2019 at 10:32, Richard Biener > >> > wrote: > >> > >> > >> > An equality test of two pointers, on the other hand, doesn't > >> > necessarily > >> > mean that they are interchangeable. I don't see any good way to > >> > avoid that in a provenance semantics, where a one-past > >> > pointer might sometimes compare equal to a pointer to an > >> > adjacent object but be illegal for accessing it. > >> > >> As I see it, there are essentially four options: > >> > >> 1.) Compilers do not use conditional equivalences for > >> optimizations of pointers (or only when additional > >> conditions apply which make it safe) > >> >>> I know this will hit DOM and CSE. I wouldn't be surprised if it > >> >>> touches > >> >>> VRP as well, maybe PTA. It seems simple enough though :-) > >> >> > >> >> Also touches fundamental PHI-OPT transforms like > >> >> > >> >> if (a == b) > >> >> ... > >> >> > >> >> # c = PHI > >> >> > >> >> where we'd lose eliding such a conditional. IMHO that's bad > >> >> and very undesirable. > >> > But if we only suppress this optimization for pointers is it that > >> > terrible? > >> > >> As far as I can see right now, there isn't a serious alternative. > >> Suppose x and y are adjacent, p=&x+1, and q=&y, so p==q might > >> be true (either in a semantics for the source-language == that just > >> compares the concrete representations or in one that's allowed > >> but not required to be provenance-sensitive). It's not possible > >> to simultaneously have *p UB (which AIUI the compiler has to > >> have in the intermediate language, to make alias analysis sound), > >> *q not UB, and p interchangeable with q.Am I missing something? > > > > No, you are not missing anything. We do have this issue right now, > > independent of standard wordings. But the standard has that, too, > > not allowing *(&x + 1), allowing the compare and allowing *&y. > > Isn't that a defect as well? > > In the source-language semantics, it's ok for p==q to not imply > that p and q are interchangeable, and if compilers are doing > provenance-based alias analysis (so address equality doesn't > imply equally-readable/writable), it's pretty much inescapable. > > Hence why (without knowing much about the optimisations that > actually go on) it's tempting to suggest that for pointer equality > comparison one could just not infer that interchangeability. I'd be > very interested to know the actual cost of that. Since we at the moment track provenance through non-pointers it means we cannot do this for non-pointer equivalences either. So doing this means no longer tracking provenance through non-pointers. > (The standard does also have a defect in its definition of equality - on > the one hand, it says that &x+1==&y comparison must be true > if they are adjacent, but on the other (in DR260) that everything > might be provenance-aware. My preference would be to resolve > that by requiring source-language == to not be provenance aware, > but I think this is a more-or-less independent thing.) I think it's related at least to us using provenance to optimize pointer comparisons. Richard. > Peter
Re: C provenance semantics proposal
On 25/04/2019, Richard Biener wrote: > On Thu, Apr 25, 2019 at 3:03 PM Peter Sewell > wrote: >> >> On 25/04/2019, Richard Biener wrote: >> > On Wed, Apr 24, 2019 at 11:18 PM Peter Sewell >> > >> > wrote: >> >> >> >> On 24/04/2019, Jeff Law wrote: >> >> > On 4/24/19 4:19 AM, Richard Biener wrote: >> >> >> On Thu, Apr 18, 2019 at 3:42 PM Jeff Law wrote: >> >> >>> >> >> >>> On 4/18/19 6:20 AM, Uecker, Martin wrote: >> >> Am Donnerstag, den 18.04.2019, 11:45 +0100 schrieb Peter Sewell: >> >> > On Thu, 18 Apr 2019 at 10:32, Richard Biener >> >> > wrote: >> >> >> >> >> >> > An equality test of two pointers, on the other hand, doesn't >> >> > necessarily >> >> > mean that they are interchangeable. I don't see any good way to >> >> > avoid that in a provenance semantics, where a one-past >> >> > pointer might sometimes compare equal to a pointer to an >> >> > adjacent object but be illegal for accessing it. >> >> >> >> As I see it, there are essentially four options: >> >> >> >> 1.) Compilers do not use conditional equivalences for >> >> optimizations of pointers (or only when additional >> >> conditions apply which make it safe) >> >> >>> I know this will hit DOM and CSE. I wouldn't be surprised if it >> >> >>> touches >> >> >>> VRP as well, maybe PTA. It seems simple enough though :-) >> >> >> >> >> >> Also touches fundamental PHI-OPT transforms like >> >> >> >> >> >> if (a == b) >> >> >> ... >> >> >> >> >> >> # c = PHI >> >> >> >> >> >> where we'd lose eliding such a conditional. IMHO that's bad >> >> >> and very undesirable. >> >> > But if we only suppress this optimization for pointers is it that >> >> > terrible? >> >> >> >> As far as I can see right now, there isn't a serious alternative. >> >> Suppose x and y are adjacent, p=&x+1, and q=&y, so p==q might >> >> be true (either in a semantics for the source-language == that just >> >> compares the concrete representations or in one that's allowed >> >> but not required to be provenance-sensitive). It's not possible >> >> to simultaneously have *p UB (which AIUI the compiler has to >> >> have in the intermediate language, to make alias analysis sound), >> >> *q not UB, and p interchangeable with q.Am I missing something? >> > >> > No, you are not missing anything. We do have this issue right now, >> > independent of standard wordings. But the standard has that, too, >> > not allowing *(&x + 1), allowing the compare and allowing *&y. >> > Isn't that a defect as well? >> >> In the source-language semantics, it's ok for p==q to not imply >> that p and q are interchangeable, and if compilers are doing >> provenance-based alias analysis (so address equality doesn't >> imply equally-readable/writable), it's pretty much inescapable. >> >> Hence why (without knowing much about the optimisations that >> actually go on) it's tempting to suggest that for pointer equality >> comparison one could just not infer that interchangeability. I'd be >> very interested to know the actual cost of that. > > Since we at the moment track provenance through non-pointers > it means we cannot do this for non-pointer equivalences either. > So doing this means no longer tracking provenance through > non-pointers. Yes, it would mean that. (As you may recall, we did earlier propose a source-language semantics that did track provenance through integers, so that's not inconceivable - but it does get complicated, and the current consensus seems to be towards the not-via-integer options.) >> (The standard does also have a defect in its definition of equality - on >> the one hand, it says that &x+1==&y comparison must be true >> if they are adjacent, but on the other (in DR260) that everything >> might be provenance-aware. My preference would be to resolve >> that by requiring source-language == to not be provenance aware, >> but I think this is a more-or-less independent thing.) > > I think it's related at least to us using provenance to optimize > pointer comparisons. Yes. If that's a significant win, one would want to keep allowing (but not requiring) == to be provenance-aware. The argument in the other direction is that it would simplify the source semantics. Peter > Richard. > >> Peter >
What's the status of of D on mingw?
Does anybody knows what's the plans for D on mingw. AFAIS the frontend builds and is enabled for mingw. But the D runtime is disabled for mingw and doesn't build. A quick dive into the source showed that there is code for mingw target. But it looks like the wrong configuration is selected. Any ideas? signature.asc Description: OpenPGP digital signature
GCC 9.0.1 Status Report (2019-04-25)
Status == We have reached zero P1 regressions today and branches/gcc-9-branch has been created; GCC 9.1-rc1 will be built and announced likely tomorrow. The branch is now frozen for blocking regressions and documentation fixes only, all changes to the branch require a RM approval now. If no show stoppers appear, we'd like to release 9.1 late next week, or soon after that, if any important issues are discovered and fixed, rc2 could be released next week. Quality Data Priority # Change from last report --- --- P10 - 12 P2 154 - 4 P3 13 - 12 P4 140 + 2 P5 25 + 1 --- --- Total P1-P3 167 - 28 Total 332 - 25 Previous Report === https://gcc.gnu.org/ml/gcc/2019-03/msg00254.html
GCC 10.0.0 Status Report (2019-04-25)
Status == The trunk has branched for the GCC 9 release and is now open again for general development, stage 1. Please consider not disrupting it too much during the RC phase of GCC 9 so it is possible to test important fixes for 9.1 on it. Quality Data Priority # Change from last report --- --- P11 - 11 P2 165 + 7 P3 16 - 9 P4 141 + 3 P5 25 + 1 --- --- Total P1-P3 182 - 13 Total 348 - 9 Previous Report === https://gcc.gnu.org/ml/gcc/2019-03/msg00254.html
Re: GCC 9.0.1 Status Report (2019-04-25)
On Thu, 25 Apr 2019 at 19:38, Jakub Jelinek wrote: > > Status > == > > We have reached zero P1 regressions today and branches/gcc-9-branch has > been created; GCC 9.1-rc1 will be built and announced likely tomorrow. > The branch is now frozen for blocking regressions and documentation > fixes only, all changes to the branch require a RM approval now. I'd like to make this small correction to the docs on gcc-9-branch: https://gcc.gnu.org/ml/gcc-patches/2019-04/msg01013.html
SAP CRM Accounts
Hi there, I wanted to check if you'd be interested in purchasing 2019 updated SAP CRM Users Contact for your marketing initiatives? We also have Users of: Microsoft Dynamics 365, Pipedrive, Zoho and HubSpot CRM etc. Help me out with your Target geography: _. Let me know you're interested, so that I will get you back with more information, Counts and Pricing for your review. Note: I could provide Any Industry, Any Job title of contact lists as per your requirements. Regards, Karla Armstrong Manager-Demand Generation If you're not interested please reply with "Not Interested" In the Subject Line.
gcc-7-20190425 is now available
Snapshot gcc-7-20190425 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20190425/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7-branch revision 270587 You'll find: gcc-7-20190425.tar.xzComplete GCC SHA256=9bb5b8795f6316309b6e3de6499a46832f2c76eaf030bf832cb4bb6f409faa38 SHA1=7b85039e590b2fc9f10f073b5f8afa785a8082ec Diffs from 7-20190418 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
