FreeBSD C compiler version

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Vadim Yanitskiy axilirator at gmail.com
Mon May 8 21:09:22 UTC 2017


Hi Max and Harald,

As I mentioned above, my suggestion is to keep the source code
"as portable as possible", which doesn't mean absolutely portable.
I don't suggest to add other UNIX platforms (Darwin, Solaris, etc.)
to our portability scope, I suggest to perform checks on the same
platforms as we currently do, but additionally to have both Clang
and GCC on both slaves.

Why Clang?

  - it's default compiler on FreeBSD (recent distributions);
  - it has its own big community;
  - it has growing compatibility with GCC, see:
    en.wikipedia.org/wiki/Clang#Performance_and_GCC_compatibility

Why different versions?

  - different distributions provide different versions available
    out of the box, i.e. some (such as FreeBSD) provide the latest
    version, while some other provide a bit dated versions;
  - some things may change in newer versions, e.g. from my recent
    experience: Clang 4.0 has support of the __builtin_cpu_supports
    built-in, while older versions don't.

I see the only disadvantage of this approach - longer total build
time. So, if you guys support this idea, I could do all configuration
and installation related work. Also, I'll try to contribute some
computing power to Jenkins: there are some servers in my university,
which power isn't used anyhow, so they mostly idle all the time.

> Recently I decided to dig into FreeBSD's world, because one of my
> changes in Gerrit does build fine on Debian slave, but doesn't on
> FreeBSD.

Here I found the problem. Cite from GCC's documentation page
x86-Built-in-Functions.html at gcc.gnu.org:

> If you specify command-line switches such as -msse, the compiler
> could use the extended instruction sets even if the built-ins
> are not used explicitly in the program. For this reason, applications
> that perform run-time CPU detection must compile separate files for
> each supported architecture, using the appropriate flags. In
> particular, the file containing the CPU detection code should be
> compiled without these options.

Adding SIMD flags to a whole project breaks portability between
different CPUs, so I added these flags for viterbi_sse.lo only.
Now the problem seems solved.


With best regards,
Vadim Yanitskiy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170509/e81a2859/attachment.htm>


More information about the OpenBSC mailing list