On Tue, Mar 11, 2014 at 1:26 PM, David Brown <da...@westcontrol.com> wrote: > On 10/03/14 18:26, Shahbaz Youssefi wrote: > You can tell the compiler about the likely paths: > > struct option_float inverse(int x) { > if (__builtin_expect(x != 0, 1)) { > return (struct option_float){ .value = 1.0f / x, .succeeded > = true }; > } else { > return (struct option_float){ .succeeded = false, > .error_code = > EDOM }; > }
True, but I was actually referring to the fact that like this, you have to write the status to stack, where the return value resides, while with a built-in method you could do away with returning it in a register. This is not just for performance, but also to be compatible with the previous ABI. > I am not sure that it would be possible to get the sort of effect you > are looking for without disrupting the syntax too much for a gcc extension. > > Speaking as an embedded developer who often wants to get the smallest > and fastest code on small processors, it would be very nice is to have > the ability to return an extra flag along with the main return value of > a function. Typically that would be a flag to indicate success or > failure, but it might have other purposes - and it could be the only > return value of an otherwise void function. Key to the implementation > would be a calling convention to use a processor condition code flag > here - that would let you generate optimal code for the "if (error) > goto" part. I too am an embedded developer (with some kernel module programming too) and what you say is another reason why I'd personally like to see this happen. Thanks for the feedback.