Date: Thu, 20 Jun 2024 00:18:53 -0600 From: Warner Losh <imp@bsdimp.com> To: Minsoo Choo <minsoochoo0122@proton.me> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: Minimum gcc and clang supported to generate FreeBSD binaries Message-ID: <CANCZdfqWW6a4O40YZFURBW431WR%2BFLuHFk79=0UgyHcJ7CBsoQ@mail.gmail.com> In-Reply-To: <8kCLO-zgfcTHi04hPyNkywfhk22Kav80DMTwDpLqLmOO0yj95gKO5MP-5pLF3WwlgG9ELgNCJywzhpQLIn4BIl_FiLULl6KUuCbCOdolZfM=@proton.me> References: <CANCZdfqBdsoNf8tVwX6MH=Dd24e114b_Pn5hA5UjxtSBX-h%2BGA@mail.gmail.com> <8kCLO-zgfcTHi04hPyNkywfhk22Kav80DMTwDpLqLmOO0yj95gKO5MP-5pLF3WwlgG9ELgNCJywzhpQLIn4BIl_FiLULl6KUuCbCOdolZfM=@proton.me>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000b0adeb061b4c4ab3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 19, 2024 at 8:26=E2=80=AFPM Minsoo Choo <minsoochoo0122@proton.= me> wrote: > I'm fine with these changes. GCC 5 was released 9 years ago and I think > most people have migrated to newer versions. > > As long as <sys/cdefs.h> is compatible with POSIX standard, code written > on FreeBSD will be portable on Linux and mac, and vice versa. There might > be problems with tcc and pcc, but it is compiler dev's responsibility to > follow posix, not our's to modify the base system for each compiler > Except we don't follow POSIX and so each compiler needs special support for these things (they are outside of POSIX). Fortunately, it looks like both tcc and pcc will work after my changes. > I think "__CC_SUPPORTS___INLINE" can be replaced with "__STDC_VERSION__ > >=3D 199901L" and thnigs under "NO_ANSI_KEYWORDS" can be removed. > I'm not so sure, but that will be for a second round of cleanup. I'm not looking to touch that stuff just yet. > I would like to review the changes once they are posted on phabricator. T= o > me, it has been a huge difficulty to read the cdefs.h header because it h= as > to many compatibility macros for old versions of GCC. Thank you for your > work. > I'll add you to the work. I also need to re-review and/or land your POSIX.1-2024 changes to a few headers now that I have a copy of the standard and we know the values that will be mandated. https://reviews.freebsd.org/D45653 https://reviews.freebsd.org/D45654 https://reviews.freebsd.org/D45655 https://reviews.freebsd.org/D45656 https://reviews.freebsd.org/D45657 Are what I've come up with now that I've had a chance to study tcc and pcc a bit. These all should be safe to remove since the ones that are > the 4.3 that pcc supports aren't used in headers. Warner > On Wednesday, June 19th, 2024 at 9:01 PM, Warner Losh <imp@bsdimp.com> > wrote: > > Greetings, > > I've been having a go at cleaning up sys/cdefs.h for going on 5 years now= . > One big problem is that it's chock-o-block of special cases and hacks goi= ng > back to the early 1990s (before some people on this list were even born). > > I'd like to remove a lot of that, while still retaining useful versions o= f > gcc and clang to work (plus preserving what support that we have for pcc > and tcc (including fixing the latter). Note: this is "building binaries > on FreeBSD" not "building FreeBSD" which has much much tighter requiremen= ts > for compilers. This won't affect that at all. > > To that end, I'd like to draw a line in the sand. If you are building > FreeBSD binaries for FreeBSD 15 and newer, you need to use gcc9 (or newer= ) > or llvm/clang 11 (or newer). Stable/12 has clang 13 at its tip. These > compilers are 5 years old or so. And are the oldest compilers in the port= s > tree that we use to generate FreeBSD binaries (there's three older ones: > gcc 6 for ada, gcc 4.2 for TI calculators (but it doesn't use system > headers) and gcc 2.7.2 for hp48 calculators (same). So from a ports > perspective, > > From a looking at changes perspective, there's about 30 instances of > GNU_PREREQU in the tree. The newest one is for gcc 5.1. So nominally > supporting just gcc9 and newer means assuming that these are all true > (which is true for gcc and clang) and removing specific support for them. > clang and gcc easily clears these bars. > > Ah, but what do you say about tcc and pcc which are't gcc? Well, tcc lies= , > and says it supports gcc (version 9 I think, but it's been a while since = I > checked). tcc can't work today because we have qsort.h using versioned > symbols unconditionally, and it doesn't support versioned symbols.... And > patches to do that have been stalled for reasons unrelated to this desire= . > pcc doesn't support gnuc symbols at all last I checked. But it has real > issues building some things in the tree, so I'll not gate things by it > unless somebody steps up to actually do the work to make it work. The pcc > upstream has been weird lately too. > > ICC used to be supported, but unless someone turns up with patches for th= e > latest icc, it will remain supported only to the extent it pretends to be > gcc. I've had reports that it works, to this extent and nothing special i= s > needed to build FreeBSD binaries. There are a couple of touch ups require= d > to build FreeBSD itself with icc I'm told, but I've not seen patches and > have little desire to chase this windmill. > > In practical sense, this will just be writing down what's the reality on > the ground today: old compiler versions haven't been tested and there's a > lot of known issues we've introduced since moving to clang that will > preclude even our old gcc 4.2 from working with system headers. > > Of course, I'll do an exp run with all these changes. But I wanted to giv= e > people a heads up that I'll be doing this before 15.0 is branched. > > For the vast majority (all?) users, I expect you'll not notice. > > Warner > > > --000000000000b0adeb061b4c4ab3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jun 19, 2024 at 8:26=E2=80=AF= PM Minsoo Choo <<a href=3D"mailto:minsoochoo0122@proton.me">minsoochoo01= 22@proton.me</a>> wrote:<br></div><blockquote class=3D"gmail_quote" styl= e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin= g-left:1ex"><div>I'm fine with these changes. GCC 5 was released 9 year= s ago and I think most people have migrated to newer versions.<br></div><di= v style=3D"font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);bac= kground-color:rgb(255,255,255)"><br></div><div style=3D"font-family:Arial,s= ans-serif;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)= ">As long as <sys/cdefs.h> is compatible with POSIX standard, code wr= itten on FreeBSD will be portable on Linux and mac, and vice versa. There m= ight be problems with tcc and pcc, but it is compiler dev's responsibil= ity to follow posix, not our's to modify the base system for each compi= ler</div></blockquote><div><br></div><div>Except we don't follow POSIX = and so each compiler needs special support for these things (they are outsi= de of POSIX). Fortunately, it looks like both tcc and pcc will work after m= y changes.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl= e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin= g-left:1ex"><div style=3D"font-family:Arial,sans-serif;font-size:14px;color= :rgb(0,0,0);background-color:rgb(255,255,255)"> I think "<span>__CC_SU= PPORTS___INLINE</span>" can be replaced with "<code>__STDC_VERSIO= N__</code> >=3D <code>199901L</code>" and thnigs under "<span>= NO_ANSI_KEYWORDS</span>" can be removed.</div></blockquote><div><br></= div><div>I'm not so sure, but that will be for a second round of cleanu= p. I'm not looking to touch that stuff just yet.<br></div><div>=C2=A0</= div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor= der-left:1px solid rgb(204,204,204);padding-left:1ex"><div style=3D"font-fa= mily:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);background-color:rgb(= 255,255,255)">I would like to review the changes once they are posted on ph= abricator. To me, it has been a huge difficulty to read the cdefs.h header = because it has to many compatibility macros for old versions of GCC. Thank = you for your work.<br></div></blockquote><div><br></div><div>I'll add y= ou to the work. I also need to re-review and/or land your POSIX.1-2024 chan= ges to a few headers now that I have a copy of the standard and we know the= values that will be mandated.</div><div><br></div><div><a href=3D"https://= reviews.freebsd.org/D45653">https://reviews.freebsd.org/D45653</a></div><di= v><a href=3D"https://reviews.freebsd.org/D45654">https://reviews.freebsd.or= g/D45654</a></div><div><a href=3D"https://reviews.freebsd.org/D45655">https= ://reviews.freebsd.org/D45655</a></div><div><a href=3D"https://reviews.free= bsd.org/D45656">https://reviews.freebsd.org/D45656</a></div><div><a href=3D= "https://reviews.freebsd.org/D45657">https://reviews.freebsd.org/D45657</a>= <br></div><div><br></div><div>Are what I've come up with now that I'= ;ve had a chance to study tcc and pcc a bit. These all should be safe to re= move since the ones that are=C2=A0 > the 4.3 that pcc supports aren'= t used in headers.<br></div><div><br></div><div>Warner<br></div><div>=C2=A0= </div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b= order-left:1px solid rgb(204,204,204);padding-left:1ex"><div style=3D"font-= family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);background-color:rg= b(255,255,255)"></div><div> On Wednesday, June 19th, 2024 at 9:01 PM, Warner Losh <<a href= =3D"mailto:imp@bsdimp.com" target=3D"_blank">imp@bsdimp.com</a>> wrote:<= br> <blockquote type=3D"cite"> <div dir=3D"ltr"><div>Greetings,</div><div><br></div><div>I'= ;ve been having a go at cleaning up sys/cdefs.h for going on 5 years now. O= ne big problem is that it's chock-o-block of special cases and hacks go= ing back to the early 1990s (before some people on this list were even born= ).</div><div><br></div><div>I'd like to remove a lot of that, while sti= ll retaining useful versions of gcc and clang to work (plus preserving what= support that we have for pcc and tcc<b> </b>(including fixing the latter).= Note: this is "building binaries on FreeBSD" not "building = FreeBSD" which has much much tighter requirements for compilers. This = won't affect that at all.<br></div><div><br></div><div>To that end, I&#= 39;d like to draw a line in the sand. If you are building FreeBSD binaries = for FreeBSD 15 and newer, you need to use gcc9 (or newer) or llvm/clang 11 = (or newer). Stable/12 has clang 13 at its tip. These compilers are 5 years = old or so. And are the oldest compilers in the ports tree that we use to ge= nerate FreeBSD binaries (there's three older ones: gcc 6 for ada, gcc 4= .2 for TI calculators (but it doesn't use system headers) and gcc 2.7.2= for hp48 calculators (same). So from a ports perspective, <br></div><div><= br></div><div>From a looking at changes perspective, there's about 30 i= nstances of GNU_PREREQU in the tree. The newest one is for gcc 5.1. So nomi= nally supporting just gcc9 and newer means assuming that these are all true= (which is true for gcc and clang) and removing specific support for them. = clang and gcc easily clears these bars.<br></div><div><br></div><div>Ah, bu= t what do you say about tcc and pcc which are't gcc? Well, tcc lies, an= d says it supports gcc (version 9 I think, but it's been a while since = I checked). tcc can't work today because we have qsort.h using versione= d symbols unconditionally, and it doesn't support versioned symbols....= And patches to do that have been stalled for reasons unrelated to this des= ire. pcc doesn't support gnuc symbols at all last I checked. But it has= real issues building some things in the tree, so I'll not gate things = by it unless somebody steps up to actually do the work to make it work. The= pcc upstream has been weird lately too.</div><div><br></div><div>ICC used = to be supported, but unless someone turns up with patches for the latest ic= c, it will remain supported only to the extent it pretends to be gcc. I'= ;ve had reports that it works, to this extent and nothing special is needed= to build FreeBSD binaries. There are a couple of touch ups required to bui= ld FreeBSD itself with icc I'm told, but I've not seen patches and = have little desire to chase this windmill.<br></div><div><br></div><div>In = practical sense, this will just be writing down what's the reality on t= he ground today: old compiler versions haven't been tested and there= 9;s a lot of known issues we've introduced since moving to clang that w= ill preclude even our old gcc 4.2 from working with system headers.</div><d= iv><br></div><div>Of course, I'll do an exp run with all these changes.= But I wanted to give people a heads up that I'll be doing this before = 15.0 is branched.</div><div><br></div><div>For the vast majority (all?) use= rs, I expect you'll not notice.<br></div><div><br></div><div>Warner<br>= </div></div> </blockquote><br> </div></blockquote></div></div> --000000000000b0adeb061b4c4ab3--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqWW6a4O40YZFURBW431WR%2BFLuHFk79=0UgyHcJ7CBsoQ>