> Furthermore, on 2014-05-12 I committed a patch changing libgfortran to > be built with -std=gnu11 instead of -std=gnu99, so that we can make > use of C11 functionality; see > https://gcc.gnu.org/ml/fortran/2014-04/msg00101.html .
Committed as rev. 212323, thanks for the review. I now propose the attached patch, which performs a small cleaning up: - Use the new _Noreturn language feature (supported in GCC since 2011) instead of the old attribute. This makes prototypes shorter and more generic. - Move the complex-related REALPART, IMAGPART and COMPLEX_ASSIGN macros from libgfortran.h to c99_intrinsics.c, which is the only place they’re ever used. Built and tested on x86_64-linux, OK to commit? FX
clean.ChangeLog
Description: Binary data
clean.diff
Description: Binary data
PS: I didn’t touch libcaf, as I assume this might be compiled with a different compiler. Am I right? PS2: A third issue I’ve though about is: should we get rid of the following __GNUC__ test? libgfortran is not used as a standalone Fortran runtime library, and I think it is (and never will) be built by something else than a stage3 compiler. > #ifndef __GNUC__ > #define __attribute__(x) > #define likely(x) (x) > #define unlikely(x) (x) > #else > #define likely(x) __builtin_expect(!!(x), 1) > #define unlikely(x) __builtin_expect(!!(x), 0) > #endif
