[llvm-dev] Provenance is not part of the existing C standard.

[Aaron Ballman via llvm-dev]

On Thu, Jun 17, 2021 at 4:55 AM Victor Yodaiken via llvm-dev
<llvm-dev at lists.llvm.org> wrote:

> 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.

N2676 is the base draft for an unpublished Technical Specification, so
hopefully it's well understood that this is not in the standard and
that the whole point is for implementers and users to weigh in on the
choices in the document and provide feedback based on implementation
and usage experience *before* the standard is changed. However, the TS
does suggest a particular path forward and that's based on years of
discussion in WG14 on the various potential options, so there's a
clear signal as to which path WG14 *thinks* it will be taking based on
the feedback we've received thus far. I'm really glad to see the LLVM
community evaluating the pros and cons of that option for our
particular implementation as that will provide extremely valuable
concrete feedback to WG14.

~Aaron

>
>
>
> 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
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev