Hello Bruno, On Mon, 20 Jan 2025 16:48:43 +0100, Bruno Haible wrote:
> Dear Jₑₙₛ, > > > > By "extension", I assume you mean that [[unsequenced]] is > > > intended to be looser than __attribute__((const)). That is, every > > > const function is unsequenced, but the reverse is not true. This > > > is what Bruno said in the above quote. > > > > Yes that's my idea. > > > > > If so, I'm puzzled by n3424, which says the intent is that > > > [[unsequenced]] and [[reproducible]] be "as a superposition" of > > > __attribute__((const)) and __attribute__((pure)) respectively. To > > > me, "superposition" means that unsequenced and const mean the > > > same thing. > > > > ah, ok, that then just a bad expression from my part. > > This other part of the 3rd paragraph also gives the impression that > [[unsequenced]] is intended to be equivalent to, not looser than, > __attribute__((const)): > > ... gcc distinguishes the C attributes and their gnu predecessors > .... The goal of this paper is to revert this unfortunate incident ... > > I guess this part needs to be reworded as well? Ah ok, I'll look into this. > > > I see one issue in the Gnulib comments that n3424 possibly should > > > address, namely, functions that return more than once. The > > > classic example is setjmp. If I understand things correctly, > > > setjmp is reproducible, but I daresay that wouldn't work well > > > with common optimizations. (However, I could well be > > > misunderstanding n3424 as mentioned above, so maybe setjmp is not > > > reproducible.) > > > > To be honest I never thought about `setjmp`, only about `longjmp` on > > the other end. > > Why is setjmp an issue here at all? A jmp_buf cannot be used after > the function that invoked setjmp() has returned. But when we discuss > whether a compiler may combine two identical-looking invocations of > the same function, which happens to invoke setjmp() but not longjmp(), > the 1 or 2 invocations of the functions are terminated when control > comes back to the caller. So even if the function stored some bit > pattern in that jmp_buf, it is an irrelevant piece of state since > setjmp() must not be called on it. For `setjmp()` it makes not much sense to mark it with one of these attributes (C23 or gcc). You cannot do much optimizations with it, in particular you cannot hoist a call to it out of a loop or things like that. It reads hidden state (ad minima the program counter but maybe also other hardware registers) and on the 2nd return many things in the scope may have changed value without this access being attributable to the call to `setjmp` itself. And then, officially, `setjmp` is not even a function. In addition, syntactic positions where it can be placed are quite limited. In any case, I will try to integrate all of your feedback and work out the possible differences between C23 and gcc attributes more clearly. Thanks Jₑₙₛ -- :: ICube :::::::::::::::::::::::::::::: deputy director :: :: Université de Strasbourg :::::::::::::::::::::: ICPS :: :: INRIA antenne de Strasbourg :::::::::::::::::: Camus :: :: INRIA PIQ program Strasbourg :::::::::: piq.inria.fr :: :: :::::::::::::::::::::::::::::::::::: ☎ +33 368854536 :: :: https://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
