This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: __sync_fetch_ prototypes.


thanks for the link, indeed
"
For the following intrinsics, <type> is either a 32-bit or 64-bit integer.
Atomic Fetch-and-op Operations

<type> __sync_fetch_and_add(<type> *ptr,<type> val)
...
"

clearly states that the types are signed and the same for the input/output values. So GCC implementation is probably bogus but as you say fixing it might imply legacy problems.

I logged the issue and the patch with http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41639

Thanks,

-c

Ian Lance Taylor wrote:
Christian BRUEL <christian.bruel@st.com> writes:

Can I assume from the gcc sources that the __sync_fetch_ builtins take
only unsigned value as inputs, and thus also return unsigned values.

These builtins came from Intel. This page


http://software.intel.com/sites/products/documentation/hpc/compilerpro/en-us/cpp/lin/compiler_c/intref_cls/common/intref_itanium_synchro_prim.htm

suggests but does not clearly state that the return type should be the
same as the value type.  We could probably implement that in gcc, but
I think it would be awkward to simply change the sign of the return
type now; it might break currently working programs.

This is probably worth a bug report in any case.

Ian



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]