-
-
Notifications
You must be signed in to change notification settings - Fork 393
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Workaround for __has_include(<...>) and ICCAVR. #593
Workaround for __has_include(<...>) and ICCAVR. #593
Conversation
ICCAVR: IAR C/C++ Compiler V6.70.1.929 for Atmel AVR There seems to be an issue with the ICCAVR compiler and `__has_include(<...>)` syntax: ``` Error[Pe008]: missing closing quote etl\include\etl\placement_new.h 48 Tool Internal Error: Internal Error: [Front end]: assertion failed at: "..\..\Translator\compiler_core\src\parser\edg\literals.c", line 1159 Internal Error: [Front end]: assertion failed at: "..\..\Translator\compiler_core\src\parser\edg\literals.c", line 1159 etl\include\etl\placement_new.h 48 Error while running C/C++ Compiler ``` Which is weird, as I wonder why `__has_include` is defined in first place. The compiler is supposed to support some dialect of C++98. Anyhow, `__has_include()` seems to work in general with ICCAVR. And with this change the code compiles well.
I was wondering if the |
@@ -37,7 +37,7 @@ SOFTWARE. | |||
// Figure out if we can use the standard library <new> header, if haven't already done so in etl_profile.h | |||
#if !defined(ETL_USING_STD_NEW) | |||
#if defined(__has_include) | |||
#define ETL_USING_STD_NEW __has_include(<new>) | |||
#define ETL_USING_STD_NEW __has_include("new") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I understand cppreference.com on source file inclusion it should not matter with new
whether ""
or <>
is used.
In order to provide for all contingencies a compiler switch could be introduced. I assume AVR-GCC does behave correctly for __has_include
thus it would not need the workaround.
#define ETL_USING_STD_NEW __has_include("new") | |
#if defined(__ICCAVR__) | |
#define ETL_USING_STD_NEW __has_include("new") | |
#else | |
#define ETL_USING_STD_NEW __has_include(<new>) | |
#endif |
__ICCAVR__
is an integer that is set to 1 when the code is compiled with the IAR C/C++ Compiler for AVR.
63e3106
into
ETLCPP:hotfix/#593-workaround-for-__has_include-and-ICCAVR
In case somebody else stumbles across this issue with ICCAVR. This error occurs in case of an indirection of
#if __has_include(<cstddef>)
#warning (1) found header
#else
#warning (1) did not find header
#endif
#define HAS_INCLUDE1 __has_include("cstddef")
#if HAS_INCLUDE1
#warning (2) found header
#else
#warning (2) did not find header
#endif
#define HAS_INCLUDE2 __has_include(<cstddef>)
#if HAS_INCLUDE2 // this is line 15
#warning (3) found header
#else
#warning (3) did not find header
#endif Compile with iccavr.exe test.cpp --eec++ Output:
(1) and (2) are OK, whereas (3) produces an internal compiler error. |
In that case, there may be a better workaround change.
|
This approach may be better as is uses the same syntax using `< ... >` as before. Has been suggested here: ETLCPP#593 (comment) This is based on the insight, that the problem with IARCC occurs only in case the `__has_include` is used as part of a preprocessor definition. See ETLCPP#593 (comment)
This approach may be better as is uses the same syntax using `< ... >` as before. Has been suggested here: ETLCPP#593 (comment) This is based on the insight, that the problem with IARCC occurs only in case the `__has_include` is used as part of a preprocessor definition. See ETLCPP#593 (comment)
This approach may be better as is uses the same syntax using `< ... >` as before. Has been suggested here: #593 (comment) This is based on the insight, that the problem with IARCC occurs only in case the `__has_include` is used as part of a preprocessor definition. See #593 (comment)
…ttps://github.com/ETLCPP/etl into hotfix/#593-workaround-for-__has_include-and-ICCAVR
Fixes #592.