Hi Maxime!
On Tue, Dec 5, 2023, 05:26 Maxime Devos <maximede...@telenet.be> wrote: > > > Op 03-12-2023 om 18:26 schreef Nala Ginrut: > > (jit-define (square x) > > (:anno: (int) -> int) > > (* x x)) > > (square 5) > > > Potentially-overflowing arithmetic involving ints (not unsigned ints, > but ints)? Best document somewhere to what the jit code '(* x x)' > evaluates when (not (<= min-int (* x x) max-int))). > There's no type inference in libgccjit, so the high level framework has to handle accurate types. I use "int" here because libgccjit only provides int rvalue constructor, yet. It seems lack of rich number types as rvalue in the present implementation. Even boolean has to be handled by high level framework and cast it to int respectively. May be we need GCC folks help. > Personally, I'm in favor of explicit long names like > > */error-on-overflow (<-- maybe on the C-level the function could > return a tagged union representing (failure [no value]) / (success [some > value], at a slight performance cost) > */wrap-around > */undefined-on-overflow (<-- like in C, for maximal performance and > dragons). > There was such check, but I've removed it. Since even you detect the int/short/long exactly, libgccjit only provides int rvalue for all cases of numbers. I'm not sure if it's waiting for contribution or intended as an unified int abstract. > (Likewise for +, - and unsigned int) > > Sure, they are a bit verbose, but they are explicit and > non-explicitness+undefined behaviour of'*' in C has caused serious > issues in the past, so I'd think it's better that the programmer has to > choose what, in their situation, are the appropriate semantics. > I see your point :-) Yes, it's a bit hard to provide an abstract arithmetic with type inference for all cases, providing each for different types will be easier and flexible. Thanks! Best regards. >
