You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Newer versions of XL C/C++ implement __has_attribute, __has_builtin, etc., but the results are untrustworthy. They routinely return true to indicate that the feature is supported, but if you try to actually use it you'll end up with a compile-time warning or error informing you that the feature isn't supported.
error: 1540-2990 The attribute " __attribute__((flag_enum))" is not supported. The attribute is ignored.
__attribute__((__flag_enum__))
^
1 error generated.
This seems to be the norm, not the exception (at least some of the bitreverse builtins do the same thing, unless they've fixed that in more recent versions). Anything that the version of clang that release of xlc is based on will return true, but IBM regularly omits the implementation and generates a diagnostic when you try to actually use it. This means that unless people are explicitly testing xlc (which is unlikely), code directly relying on HEDLEY_HAS_* (which wrap the __has_* macros) is likely broken.
I think the best thing to do would be to just have HEDLEY_HAS_ATTRIBUTE, HEDLEY_HAS_BUILTIN, etc., just unconditionally return 0 on xlc (like it does for compilers like gcc, msvc, etc., which don't support the feature testing macros at all).
Internally this isn't really a problem since; we already have version number based checks for most features since __has_* is a fairly recent feature in xlc and most of the attributes we have macros for are supported in earlier versions which Hedley also tries to support.
This could be a problem for projects using HEDLEY_HAS_*… there is a good chance that they are broken on xlc anyways, but it's also possible that people are relying on it for attributes which actually are supported by xlc.
If IBM fixes their feature detection macros in a future version of xlc we can always re-enable HEDLEY_HAS_* for newer versions but keep it disabled for older versions.
If anyone is relying on HEDLEY_HAS_* macros for feature testing on XL C/C++, please let me know. If this would break a lot of projects we can try to find another solution (maybe a HEDLEY_SUPPORTS_* group of macros, and deprecating HEDLEY_HAS_*?). If nobody speaks up I'll probably go ahead and commit this change soon and it will be in the next release.
The text was updated successfully, but these errors were encountered:
Newer versions of XL C/C++ implement
__has_attribute
,__has_builtin
, etc., but the results are untrustworthy. They routinely return true to indicate that the feature is supported, but if you try to actually use it you'll end up with a compile-time warning or error informing you that the feature isn't supported.For example:
Will result in something like:
This seems to be the norm, not the exception (at least some of the bitreverse builtins do the same thing, unless they've fixed that in more recent versions). Anything that the version of clang that release of xlc is based on will return true, but IBM regularly omits the implementation and generates a diagnostic when you try to actually use it. This means that unless people are explicitly testing xlc (which is unlikely), code directly relying on
HEDLEY_HAS_*
(which wrap the__has_*
macros) is likely broken.I think the best thing to do would be to just have
HEDLEY_HAS_ATTRIBUTE
,HEDLEY_HAS_BUILTIN
, etc., just unconditionally return 0 on xlc (like it does for compilers like gcc, msvc, etc., which don't support the feature testing macros at all).Internally this isn't really a problem since; we already have version number based checks for most features since
__has_*
is a fairly recent feature in xlc and most of the attributes we have macros for are supported in earlier versions which Hedley also tries to support.This could be a problem for projects using
HEDLEY_HAS_*
… there is a good chance that they are broken on xlc anyways, but it's also possible that people are relying on it for attributes which actually are supported by xlc.If IBM fixes their feature detection macros in a future version of xlc we can always re-enable
HEDLEY_HAS_*
for newer versions but keep it disabled for older versions.If anyone is relying on
HEDLEY_HAS_*
macros for feature testing on XL C/C++, please let me know. If this would break a lot of projects we can try to find another solution (maybe aHEDLEY_SUPPORTS_*
group of macros, and deprecatingHEDLEY_HAS_*
?). If nobody speaks up I'll probably go ahead and commit this change soon and it will be in the next release.The text was updated successfully, but these errors were encountered: