> Am 08.09.2025 um 17:53 schrieb Iain Sandoe <i...@sandoe.co.uk>:
>
>
>
>>> On 8 Sep 2025, at 15:53, Richard Biener <richard.guent...@gmail.com> wrote:
>>>
>>>
>>>
>>>> Am 08.09.2025 um 16:28 schrieb Iain Sandoe <i...@sandoe.co.uk>:
>>>
>>>
>>>
>>>>> On 8 Sep 2025, at 15:20, Iain Sandoe <i...@sandoe.co.uk> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> On 8 Sep 2025, at 15:05, Jakub Jelinek <ja...@redhat.com> wrote:
>>>>>
>>>>> On Mon, Sep 08, 2025 at 02:54:18PM +0100, Iain Sandoe wrote:
>>>>>> (for pre-conditions) they lower to a series of statements like
>>>>>> if (some check fails)
>>>>>> handle the contract violation
>>>>>> if (some other check fails)
>>>>>> handle the contract violation
>>>>>> …
>>>>>>
>>>>>>> The only "example" is for in(p) in (*p > 5) where the contract
>>>>>>> *p > 5 would "elide" the 'p' one. Whatever "eliding" means here.
>>>>>>
>>>>>> So, IIRC, the argument was
>>>>>>
>>>>>> *p > 5 would be UB for p == nullptr
>>>>>>
>>>>>> therefore an earlier check for p == nulptr can be removed, because
>>>>>> that case cannot happen in a well-formed program.
>>>>>>
>>>>>> However, that prevents the contract check from doing its job (diagnosing
>>>>>> the bad case).
>>>>>>
>>>>>> I cannot say that GCC would make that optimisation - it was, in general,
>>>>>> quite hard to find cases that time-traveled.
>>>>>
>>>>> If handle the contract violation is just __builtin_unreachable () or
>>>>> it isn't evaluated at all and handled more like [[assume ()]] for the
>>>>> ignore
>>>>> semantics, then I don't see a problem with that kind of time travel.
>>>>> If handle the contract violation is a function call which gcc knows
>>>>> nothing
>>>>> about (including calling ::handle_contract_violation), I don't see how gcc
>>>>> could optimize that (unless it is buggy), exactly because it needs to
>>>>> count
>>>>> with the function exiting or looping forever or doing thread
>>>>> synchronization
>>>>> and other threads observe the state etc.
>>>>
>>>> The contract violation handling depends on the chosen contract semantic
>>>> it can:
>>>>
>>>> * terminate (in an implementation-defined way - so could trap or abort
>>>> equally).
>>>> * do some diagnostic output or logging and then terminate (etc).
>>>> * do some diagnostic output or logging and then continue.
>>>>
>>>> I completely agree with Richi that, in the given case, continuation means
>>>> that the program will segv. I guess the question is whether the violation
>>>> handler logging a cause before that is considered a useful functionality.
>>>
>>> I think the big thing with contracts is that they are not there to deal with
>>> correct programs, they are there to try and help in the case that the
>>> program
>>> is buggy (in a way that cannot be detected at compile-time).
>>
>> Usually sth like contracts aids in formal program verification. But … too
>> many C++ papers to read. Still C++ sometimes feels like going the „coming
>> from X, now also available in C++“, aka chasing for feature completeness as
>> its own merit.
>
> I fear we might be getting de-railed somewhat from the P1494 case - IIUC
> contracts is only one use.
>
> I do not suppose that there are many designs for which we all agree with
> all the details - for the discussions here, I am just trying to represent what
> I believe to be the designer’s intents (so not necessarily my personal POV).
>
> Trying to see how to proceed here; currently P1494 + P3641 are part of the
> working draft, and so are expected to be in C++26.
>
> If it is demonstrably the case that the design is not useable - then we should
> raise a comment to that effect (soon, because the deadline is close).
>
> Otherwise, I’m looking for guidance on what’s needed to land this.
IIRC the paper talks about a call to an unknown function having the desired
semantics. I’ll go with that, making it not throwing, const but looping and
leaf. We can make it stronger if necessary, weakening it after people rely on
semantics is less useful IMO. On RTL we have nothing at all, I’ve heard
,volatile‘ asm is only about missing outputs, not side effects in general. So
I’d expand to nothing on RTL, watching what breaks.
Richard
> thanks
> Iain
>
>>
>> Richard
>>>
>>> Iain
>>>
>
