This is the mail archive of the gcc@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] |
For use in both the Fortran front-end and in libgfortran, it would be really nice to have __builtin_signbit() be type-generic. It makes sense from the C point of view too, because itâs the only built-in from the C99 type-generic floating-point macros that is not type-generic. So far, I have built a compiler with the trivial change attached (marking the built-in type-generic in gcc/builtins.def) on x86_64-apple-darwin14, where I can confirm that the built-in is correctly expanded (without function call) on all floating-point types. Is there something more to do (apart from adjusting the documentation)? Joseph, Iâm CCâing you because of a 7-year old comment in PR 36757, where you said: > It's necessary to avoid the type-generic signbit expanding to call a library > function that may not exist, but as all currently supported floating-point > formats do have a sign bit specified in signbit_ro I believe the case > of failing to expand inline can be made into an abort. I can confirm that even in 2015, the only format which has (signbit_ro < 0) is real_internal_format, which I think doesnât matter here. So: should I, in addition to the change in gcc/builtins.def, add some aborts() or sorry() in gcc/builtins.c if we canât expand (which should never happen)? Thanks in advance for your help, FX
Attachment:
signbit.diff
Description: Binary data
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |