llvm dev - Jun 2021 - Provenance is not part of the existing C standard.

Am Mi., 16. Juni 2021 um 19:32 Uhr schrieb Victor Yodaiken via
llvm-dev <llvm-dev at lists.llvm.org>:
>  Provenance is not part of the existing C standard. This proposal is by no
means a settled issue. It would be interesting to hear what Clang/llvm
developers think. Speaking for myself, I think the proposal has interesting
ideas, but papers over a lot of difficult issues, lacks motivation, and
potentially could have very negative effects on C semantics in its current
state. I'd prefer to fix the C standard so that it is possible to write
operating systems, malloc, and other important code in standard C before we
consider adding such a far reaching change.
Provenance/N2676 is that fix of the C standard. All current C/C++
specifications have wordings that are obviously motivated to make some
compiler optimizations possible, but when those are implemented leads
to miscompilation of programs that most agree should have worked. The
current situation of implementing an optimization and only later
finding out that it is bad when someone complains about it is
obviously unsatisfying. As a result, the only safe option is to treat
a pointer like an integer, but this would also prohibit many
optimizations that an optimizing compiler nowadays is expected to do.

I am curious, what are those negative effects on semantics that you
are referring to? How would you fix the C standard?

Michael

I don't see how to write a memory allocator under N2676 (what is the
provenance of a freed block of storage?)
---"Our semantics special-cases malloc and the related functions, by giving
their results fresh provenances. This is stylistically consistent with the
ISO text, which also special-cases them,
but it would be better for C to support a general-purpose annotation, to
let both stdlib implementations and other
libraries return pointers that are treated as having fresh provenance
outside (but not inside) their abstraction
boundaries."

So how does one write an allocator not called "malloc"? And how does
the
code inside the abstraction boundaries work since free(p) needs to transform
the type of the storage pointed to by "p" and presumably zero the
provenance so it can consolidate storage blocks etc.?

 or consider for device memory:
----"We leave the design of exactly what escape-hatch mechanisms are needed
here as an open problem. For memory-
mapped devices, one could simply posit implementation-defined ranges of
such memory which are guaranteed not
to alias C objects. The more general linkage case is more interesting, but
well outside current ISO C. The tracking
of provenance through embedded assembly is similar."

and

--- "To be conservative w.r.t. current compiler behaviour, pointer equality
in the
semantics should give false if the addresses are not equal, but
nondeterministically ( either take provenance into ac-
 count or not if the addresses are equal "

To me, all these things need to be decided first otherwise provenance makes
things worse.

My intent is not to debate N2676 here, but to suggest it is not a done
deal. Provenance is not in the standard now and not necessarily in the
standard in the future and its not too late for people to weigh in.



On Thu, Jun 17, 2021 at 1:57 AM Michael Kruse <llvmdev at meinersbur.de>
wrote:
> Am Mi., 16. Juni 2021 um 19:32 Uhr schrieb Victor Yodaiken via
> llvm-dev <llvm-dev at lists.llvm.org>:
> >  Provenance is not part of the existing C standard. This proposal is
by
> no means a settled issue. It would be interesting to hear what Clang/llvm
> developers think. Speaking for myself, I think the proposal has interesting
> ideas, but papers over a lot of difficult issues, lacks motivation, and
> potentially could have very negative effects on C semantics in its current
> state. I'd prefer to fix the C standard so that it is possible to write
> operating systems, malloc, and other important code in standard C before we
> consider adding such a far reaching change.
>
> Provenance/N2676 is that fix of the C standard. All current C/C++
> specifications have wordings that are obviously motivated to make some
> compiler optimizations possible, but when those are implemented leads
> to miscompilation of programs that most agree should have worked. The
> current situation of implementing an optimization and only later
> finding out that it is bad when someone complains about it is
> obviously unsatisfying. As a result, the only safe option is to treat
> a pointer like an integer, but this would also prohibit many
> optimizations that an optimizing compiler nowadays is expected to do.
>
> I am curious, what are those negative effects on semantics that you
> are referring to? How would you fix the C standard?
>
> Michael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210617/b06a7fc6/attachment.html>