On 04/23/2015 09:47 AM, Martin Sebor wrote: > On 04/22/2015 11:42 PM, Scotty wrote: >> This link https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html says "As the addition is performed in infinite signed precision, these built-in functions have fully defined behavior for all argument values. " >> >> I'm curious if these types of builtins are well defined for things like the following: >> >> int a, b; >> a = 5; >> b = 10; >> __builtin_add_overflow(a,b,&a); > > Note that in cases like this one where the operands values are > known to the compiler the entire computation is optimized into > a straight assignment (i.e., the addition and the overflow > checking is done during compilation). > >> >> Notice the re-use of the variable a. I'm wondering if there is a sequencing issue and we need to use a third variable for the storage or if this is fine as well. > > The text in the manual seems fairly clear that the computation > is performed on the promoted operands (i.e., not on the operands > themselves) and that the result is stored in the destination after > the computation. > > Compiling an example program and examining the debug dumps from > the compiler output with the -fdump-tree-all option or the > generated assembly bears this out. The operands are copied into > temporaries (registers) first, the computation is done on those, > and when its complete the result is cast to the destination type > (if necessary) and copied into the destination location. > > I think the concern might perhaps be justified if the computation > were to be done in software, but since it's done in hardware (and > thus on copies of the operands) there is no issue. Thank you this is exactly what I was looking for. > Martin >
