[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Fixed tests build on EDG-based compilers

From: Michael Shigorin
Subject: Re: [PATCH] Fixed tests build on EDG-based compilers
Date: Mon, 6 Dec 2021 21:09:21 +0300
User-agent: Mutt/1.10.1 (2018-07-13)

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 __GNUC__ or __clang__ when it
>   does not behave like GCC or clang?

Rather up to MCST but I'll try to guess the answer.

My understanding is that it's a common logic shared with e.g.
icc and armcc (through their common EDG upstream's provided
means): the amount of patching needed to get the typical code
compiled is less this way.  Yes, it's a lie on their behalf
when these don't even pretend well enough let along *are*
those claimed.

> - Why are people at altlinux.org attempting to support a
>   proprietary compiler? What benefit is it for a Linux distro
>   user to have binaries compiled by a compiler that is neither
>   GCC nor clang and thus does not have the quality maintained
>   by a large user community?

Rather up to me.

A year ago mcst-lcc was basically the only one yielding usable
compilation result, and now with llvm9 having been somewhat
ported onto e2k it's still /the/ production one.  We're rather
living with that (I did UEFI/SB related code in ALT back then
and I've specifically insisted that it's not called "SB support"
but rather "hardware enablement"; cf.: [1][2]) and all the
pains involved; the main positive result to me is heaps of
real bugs caught by the non-gcc EDG frontend in erm... code
that should have been frowned upon by gcc as well.

Still Ilya has taken an active stance on the matter and actually
works on an independent/free e2k codegen; there's a published port
of Embox RTOS onto e2k as well, and a reverse-engineered qemu port.

On Mon, Dec 06, 2021 at 05:50:43PM +0100, Bruno Haible wrote:
> > Same, but LCC prints only the second error:
> > 
> > lcc: "test.c", line 2: error #59: function call is not allowed in a constant
> >            expression
> >    _Static_assert(__builtin_add_overflow_p (0x7fffffff, 1, 0), "");
> >                   ^
> Thanks for the confirmation.
> I pushed the change.

Guys, thank you for this exchange and the resulting fix.

[1] http://en.altlinux.org/rescue
[2] http://en.altlinux.org/UEFI_SecureBoot_mini-HOWTO

 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

reply via email to

[Prev in Thread] Current Thread [Next in Thread]