Date: Sat, 26 Jun 2021 08:30:17 -0700 From: Mark Millard <marklmi@yahoo.com> To: Dimitry Andric <dim@FreeBSD.org> Cc: dev-commits-src-branches@freebsd.org Subject: Re: git: 450f3e55bdad - stable/13 - Work around bogus old gcc "initializer element is not constant" error Message-ID: <F713D9F1-63F1-4F17-8607-367053768469@yahoo.com> In-Reply-To: <62DD1D7C-68FA-4931-A219-2C90A97A56A7@FreeBSD.org> References: <87104032-C5B9-447D-9545-B30AF983ACB7.ref@yahoo.com> <87104032-C5B9-447D-9545-B30AF983ACB7@yahoo.com> <62DD1D7C-68FA-4931-A219-2C90A97A56A7@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Jun-26, at 06:36, Dimitry Andric <dim at FreeBSD.org> wrote: > On 26 Jun 2021, at 06:11, Mark Millard <marklmi@yahoo.com> wrote: >>=20 >> Dimitry Andric dim at FreeBSD.org wrote on >> Fri Jun 25 18:46:00 UTC 2021 : >>=20 >> . . . >>> In file included from /workspace/src/lib/msun/src/s_llround.c:11:0: >>> /workspace/src/lib/msun/src/s_lround.c:54:31: error: initializer = element is not constant >>> static const type dtype_min =3D type_min - 0.5; >>> ^~~~~~~~ >>> /workspace/src/lib/msun/src/s_lround.c:55:31: error: initializer = element is not constant >>> static const type dtype_max =3D type_max + 0.5; >>> ^~~~~~~~ >>>=20 >>> Since 'type_min' and 'type_max' are constants declared just above = these >>> lines this error is nonsensical, but older gcc's are not smart = enough. >> . . . >>=20 >> Well, in C "const" historically means closer to "read-only" than >> to is-a-constant-expression in the language, unfortunately. Part >> of this is the conversion away from being an lvalue (so: where >> an lvalue is not required) loses the const qualification as part >> of the conversion. >=20 > FWIW, this changed in gcc 8.1+, here: > = https://gcc.gnu.org/git/?p=3Dgcc.git;a=3Dcommit;h=3Df9c59f7e9511856bd6dc13= d2d4904ebd9249c095 >=20 > referencing these bugs: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D66618 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D69960 >=20 > In one of the comments, joseph@codesourcery.com mentions: >> Although diagnosing this probably makes sense, it's not required by = the >> standard ("An implementation may accept other forms of constant >> expressions." - and this expression doesn't contain "assignment, >> increment, decrement, function-call, or comma operators", so isn't >> required by the Constraints for constant expressions not to be one). >=20 > I guess the gcc people also decided that POLA applied here. :) Yea. If one wants one's C code to reliably compile in valid C compilers generally, one must avoid treating such things as type_min in: static const type type_min =3D (type)DTYPE_MIN; as any of an integer, floating, enumeration, or character constant (in C terms). (C++ used the likes of "integer literal" as terminology to avoid the ambiguity that makes "integer constant" read funny vs. what is a constant expression.) Otherwise some compilers may reject the code without violating the language standard. =3D=3D=3D 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?F713D9F1-63F1-4F17-8607-367053768469>