Commit Graph

3 Commits

Author SHA1 Message Date
makise-homura
e5d9fce03f LCC: Add dedicated support for MCST LCC compiler
Divert LCC compiler as a new one, instead of treating it as GNU.

Since old times, Elbrus C/C++/Fortran Compiler (LCC) by MCST has been
passing checks for GNU compilers, so it has been identified as GNU.
Now, with intent of seriously upstreaming its support, it has been
added as a separate LCC compiler, and its version displays not a
supported GCC version, but LCC version itself (e.g. LCC 1.25.19 instead
of GNU 7.3.0).

This commit adds its support for detection, and also converts basically
every check like 'is this compiler GNU?' to 'is this compiler GNU or
LCC?'. The only places where this check is untouched, is where it
regards other platforms where LCC is unavailable (primarily non-Linux),
and where it REALLY differs from GNU compiler.

Note: this transition may break software that are already ported to
Elbrus, but hardly relies that LCC will be detected as GNU; still such
software is not known.
2021-10-15 05:05:19 +03:00
Alex Turbov
7b2dd9dedc Refactor: Use added message types in various modules
Co-Authored-By: Craig Scott <craig.scott@crascit.com>
2019-11-02 14:10:09 +02:00
Raphael Kubo da Costa
ffa6f057b4 Avoid using C11 to build CMake if _Thread_local support is broken
Support for C11's _Thread_local was introduced in GCC in the 4.9 series,
even though we make the C11 compiler flags available in CMake with GCC
>= 4.6.

FreeBSD's runetype.h uses _Thread_local, which causes CMake's own build
to fail when using GCC < 4.9 and -std=gnu11:

  /usr/include/runetype.h:92:22: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'const'
   extern _Thread_local const _RuneLocale *_ThreadRuneLocale;

Add a test for _Thread_local support and only build CMake itself with
C11 support if it works.

Bug: http://www.cmake.org/Bug/view.php?id=15741
2015-09-15 10:51:54 -04:00