[Bug libstdc++/60594] std::function of a type with a declared (but not defined) return type fails to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60594 --- Comment #3 from Chandler Carruth --- Personally, I've no idea what the standard says. However, it seems extremely useful to be able to freely use std::function with return types (and argument types) within the definition those types which is how this actually started. It also seems reasonable to need to observe whether the std::function will be copyable (it will) prior to completing it. Without this, somewhat basic uses if std::function as a member with a type-erased bit of logic pertaining to the enclosing class with value semantic interfaces don't work.
[Bug c/60490] please define __LITTLE_ENDIAN__/__BIG_ENDIAN__ for every target where it makes sense
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60490 --- Comment #5 from Chandler Carruth --- (In reply to Eric Christopher from comment #4) > I disagree for bare metal that including endian is the right way, but agree > that __BYTE_ORDER__ is the right way to do this in general. > > Thanks Jakub. I don't really have a strong feeling about __BYTE_ORDER__ vs. other systems, but it would be very nice if there were consistently available macros in both GCC and Clang that could be used to detect endianness. If you don't like just defining __BIG_ENDIAN__ and __LITTLE_ENDIAN__, could you suggest a concrete pattern for __BYTE_ORDER__ which should be defined by the compiler on every platform Jakub? I'm particularly interested for the sake of bare metal or other freestanding implementations which benefit from asking the compiler rather than a system header.
[Bug c/60490] please define __LITTLE_ENDIAN__/__BIG_ENDIAN__ for every target where it makes sense
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60490 --- Comment #7 from Chandler Carruth --- (In reply to Jakub Jelinek from comment #6) > Just look what GCC does? > Say on x86_64 it does: > gcc -E -dD -xc /dev/null | grep ENDIAN > #define __ORDER_LITTLE_ENDIAN__ 1234 > #define __ORDER_BIG_ENDIAN__ 4321 > #define __ORDER_PDP_ENDIAN__ 3412 > #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ > #define __FLOAT_WORD_ORDER__ __ORDER_LITTLE_ENDIAN__ > on e.g. ppc64 it does: > gcc -E -dD -xc /dev/null | grep ENDIAN > #define __ORDER_LITTLE_ENDIAN__ 1234 > #define __ORDER_BIG_ENDIAN__ 4321 > #define __ORDER_PDP_ENDIAN__ 3412 > #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__ > #define __FLOAT_WORD_ORDER__ __ORDER_BIG_ENDIAN__ > Don't have access to PDP nor built cross-compiler for that, but it would > expectably define __BYTE_ORDER__ to __ORDER_PDP_ENDIAN__. Cool, seems like we could easily support both this and consistently defining __BIG_ENDIAN__ and __LITTLE_ENDIAN__ in Clang. Is there any reason to specifically avoid defining the latter two on systems where __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ (or little respectively)? If there is a reason to not do so, we probably shouldn't do it in Clang either. If there isn't a reason, maybe both GCC and Clang should do so?
