Paul Eggert wrote:
> intprops.h
> should look at __EDG__ and not bother with __ICC. (Perhaps this should
> be true elsewhere in Gnulib?)
Ilya, you can investigate in this direction by creating a full gnulib
testdir and compiling it with your LCC:
$ ./gnulib-tool --create-testdir
Thanks for fixing that, Bruno. Some other complications:
* ICC defines __EDG__ (at least, ICC 2021.3 does), so the underlying
issue seems to be EDG-based not ICC-specific, which means intprops.h
should look at __EDG__ and not bother with __ICC. (Perhaps this should
be true elsewhere in
On Mon, Dec 06, 2021 at 12:41:49AM +0100, Bruno Haible wrote:
> > -#if __GNUC__ || __clang__ || __SUNPRO_C
> > +#if (__GNUC__ || __clang__ || __SUNPRO_C) && !defined(__EDG__)
> If you want us to support such compilers, I would appreciate
> a couple of words about:
> - Why does a compiler define
Ilya Kurdyukov wrote:
> This is a different LCC (but also use __LCC__ macro) and sometimes we
> have name collision issues. Recently in OpenModelica.
Then let's remember to NOT use __LCC__ for the Moscow LCC compiler.
> Same, but LCC prints only the second error:
>
> lcc: "test.c", line 2:
On 06.12.2021 22:31, Bruno Haible wrote:
> It sounds like this compiler is *not* the same as the small LCC [1], and
> thus when [2] states the macro __LCC__, they mean [1], not your compiler.
This is a different LCC (but also use __LCC__ macro) and sometimes we
have name collision issues.
Илья Курдюков wrote:
> To reproduce the issue, try this as C code using ICC 19.0.1 in Compiler
> Explorer:
>
> #ifdef __GNUC__
> _Static_assert(__builtin_add_overflow_p (0x7fff, 1, 0), "");
> #endif
>
> Compiler output:
>
> (2): error: expression must be an integral constant expression
>
Ilya Kurdyukov wrote:
> The EDG frontend is used by MCST, which designs Elbrus 2000 processors,
> for their compiler named LCC. Which generates the fastest code at the
> moment. There is a Clang backend, but its quality is low (bugs, poor
> performance).
>
> This LCC runs in GNUC compatibility
The EDG frontend is used by MCST, which designs Elbrus 2000 processors,
for their compiler named LCC. Which generates the fastest code at the
moment. There is a Clang backend, but its quality is low (bugs, poor
performance).
This LCC runs in GNUC compatibility mode, so it has a __GNUC__ macro
To reproduce the issue, try this as C code using ICC 19.0.1 in Compiler
Explorer:
#ifdef __GNUC__
_Static_assert(__builtin_add_overflow_p (0x7fff, 1, 0), "");
#endif
Compiler output:
(2): error: expression must be an integral constant expression
_Static_assert(__builtin_add_overflow_p
On 12/5/21 15:41, Bruno Haible wrote:
- Why does a compiler define __GNUC__ or __clang__ when it does not
behave like GCC or clang?
- Why are people at altlinux.org attempting to support a proprietary
compiler?
Both good questions, especially since this issue (whatever it is:
> -#if __GNUC__ || __clang__ || __SUNPRO_C
> +#if (__GNUC__ || __clang__ || __SUNPRO_C) && !defined(__EDG__)
Hi,
If you want us to support such compilers, I would appreciate a couple of
words about:
- Why does a compiler define __GNUC__ or __clang__ when it does not
behave like GCC or
From: Ilya Kurdyukov
---
tests/test-intprops.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/test-intprops.c b/tests/test-intprops.c
index fff421874..08f9a397f 100644
--- a/tests/test-intprops.c
+++ b/tests/test-intprops.c
@@ -48,7 +48,7 @@
These tests should be
12 matches
Mail list logo
