Date: Wed, 4 Jul 2018 19:03:46 -0700 From: Mark Millard <marklmi26-fbsd@yahoo.com> To: Eitan Adler <lists@eitanadler.com>, svn-src-head@freebsd.org Subject: Re: svn commit: r335888 - in head: contrib/blacklist/bin lib/libpjdlog sbin/hastd Message-ID: <1DED9D35-81AF-4814-9CE0-8556193524DF@yahoo.com>
next in thread | raw e-mail | index | archive | help
Eitan Adler lists at eitanadler.com wrote on Thu Jul 5 00:56:02 UTC 2018 : > On Tue, 3 Jul 2018 at 08:22, John Baldwin <jhb at freebsd.org > > wrote: > > since GCC usually breaks > > them. > > > Could you explain what you mean or point to a prior conversation? I'll take a stab at it without giving much for specific code examples. I do not claim the wording gives complete coverage but it should suggest some types of problems to expect. A) Gcc considers various FreeBSD definitions wrong by their criteria and attempts to override them. (That is what the Gcc "include-fixed" headers are for relative to FreeBSD. The issue is not unique to FreeBSD.) B) FreeBSD considers various Gcc definitions wrong by its criteria and attempts to override them. (FreeBSD, being an OS, would normally have the larger set of definitions overall. For example Gcc likely would not consider FreeBSD's _STANDALONE distinctions for max_align_t, say. [I've not checked the details. Only illustrative of a potential example.]) The mixing of code with (A) and (B) tends to be problematical. One way is that if the details for Gcc or FreeBSD change, things tend to end up mis-matched (at least until both sides adjust) even if they were working together correctly before. But even without that there are frequently problems with various details as they have been. Part of the overall issue is that FredBSD targets multiple standards, not just language standards, and various standards are not in full agreement. Gcc does not necessarily target the same set of standards or have the same selections for dealing with potential conflicts for what it does target. There are also issues of file conflicts, such as the area with float.h (from C) for Gcc also having altivec.h (not from C) and FreeBSD having its own file of the name --and the system-clang compiler source also having one. The 3 altivec.h files serve different purposes and are not alternatives for each other, despite the common name. Having Gcc (as a cross compiler) build system-clang with __ALTIVEC__ defined and picking out clang's altivec.h would be painful. (Currently targeting powerpc64 that way does not build system-clang with __ALTIVEC__ defined. The lack avoids the file issue but does not cover altivec correctly in the built clang.) (A) has been a difficult area for a long time and sometime back a ways was finally disabled in various Gcc ports. Even without (A), there are issues like the altivec.h issue that can end up involved. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1DED9D35-81AF-4814-9CE0-8556193524DF>