Skip to content
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

Conversation

dhebbeker
Copy link
Contributor

Fixes #592.

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.
@jwellbelove
Copy link
Contributor

I was wondering if the __has_include variation should be qualified with a defined(__AVR__) just in case it breaks an existing user's setup.

@@ -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")
Copy link
Contributor Author

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.

Suggested change
#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.

@jwellbelove jwellbelove changed the base branch from master to hotfix/#593-workaround-for-__has_include-and-ICCAVR September 7, 2022 10:15
@jwellbelove jwellbelove merged commit 63e3106 into ETLCPP:hotfix/#593-workaround-for-__has_include-and-ICCAVR Sep 7, 2022
@dhebbeker
Copy link
Contributor Author

In case somebody else stumbles across this issue with ICCAVR. This error occurs in case of an indirection of __has_include(<file>) through a macro. There is no problem with __has_include("file") or without indirection. See example:

test.cpp:

#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:


   IAR C/C++ Compiler V6.70.1.929 for Atmel AVR
   Copyright 1996-2015 IAR Systems AB.
   Standalone license - IAR Embedded Workbench for Microchip AVR 6.70

        #warning (1) found header
         ^
"test.cpp",2  Warning[Pe1105]:
          #warning directive: (1) found header

        #warning (2) found header
         ^
"test.cpp",9  Warning[Pe1105]:
          #warning directive: (2) found header

  #if HAS_INCLUDE2 // this is line 15
      ^
"test.cpp",15  Error[Pe008]:
          missing closing quote
"test.cpp",15  Internal error:
          [Front end]: assertion failed at:
          "..\..\Translator\compiler_core\src\parser\edg\literals.c", line 1159
Fatal error detected, aborting.

(1) and (2) are OK, whereas (3) produces an internal compiler error.

@jwellbelove
Copy link
Contributor

In that case, there may be a better workaround change.

#if __has_include(<new>)
  #define ETL_USING_STD_NEW 1
#else
  #define ETL_USING_STD_NEW 0
#endif

dhebbeker added a commit to dhebbeker/etl that referenced this pull request Sep 7, 2022
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)
dhebbeker added a commit to dhebbeker/etl that referenced this pull request Sep 7, 2022
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)
jwellbelove pushed a commit that referenced this pull request Sep 7, 2022
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)
jwellbelove added a commit that referenced this pull request Sep 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Issue with __has_include(<...>) and ICCAVR
2 participants