Date: Sat, 17 Aug 2013 15:44:57 +0100 From: David Chisnall <theraven@FreeBSD.org> To: "O. Hartmann" <ohartman@zedat.fu-berlin.de> Cc: FreeBSD CURRENT <freebsd-current@FreeBSD.org>, FreeBSD Ports <freebsd-ports@FreeBSD.org> Subject: Re: graphics/blender: math.h: isnan(): error: controlling expression type 'unsigned int' not compatible with any generic association type Message-ID: <2097500C-2A49-4532-BF6C-C4AFB5778BC7@FreeBSD.org> In-Reply-To: <20130817163929.1993d012@thor.walstatt.dyndns.org> References: <20130817114818.7d5cd89a@thor.walstatt.dyndns.org> <779CBD97-A751-4168-BFF0-F984BEE615CE@FreeBSD.org> <20130817163929.1993d012@thor.walstatt.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_66689E9D-464E-4899-962F-C7EE5BE4DA38 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 17 Aug 2013, at 15:39, "O. Hartmann" <ohartman@zedat.fu-berlin.de> = wrote: > On Sat, 17 Aug 2013 11:24:41 +0100 > David Chisnall <theraven@FreeBSD.org> wrote: >=20 >> On 17 Aug 2013, at 10:48, "O. Hartmann" <ohartman@zedat.fu-berlin.de> >> wrote: >>=20 >>> port graphics/blender doesn't compiler neither in CURRENT nor >>> 9.2-PRE for the moment. On CURRENT (FreeBSD 10.0-CURRENT #4 >>> r254430: Fri Aug 16 23:23:08 CEST 2013 amd64), compilation fails >>> with the belwo shown error message - for roughly a month now.=20 >>>=20 >>> I think this is dur to some issues of inconsistency/incompatibility >>> of the math.h/cmath headers regarding the reported c++11 issues. >>>=20 >>>=20 >>> Since port graphics/blender doesn't compile on 9.2 nor does it >>> compile in CURRENT and the fact that the math.h isn't fixed in the >>> 9.2-RELEASE as I was told, the port should be marked broken. >>>=20 >>>=20 >>>=20 >>> [ 55%] Building C object >>> = source/blender/imbuf/intern/cineon/CMakeFiles/bf_imbuf_cineon.dir/cineon_d= px.c.o >>> [ 55%] Building C object >>> = source/blender/imbuf/intern/cineon/CMakeFiles/bf_imbuf_cineon.dir/cineonli= b.c.o = /usr/ports/graphics/blender/work/blender-2.68/source/blender/imbuf/intern/= cineon/cineonlib.c:280:70: >>> error: controlling expression type 'unsigned int' not compatible >>> with any generic association type if (cineon->element[i].refLowData >>> =3D=3D CINEON_UNDEFINED_U32 || isnan(cineon->element[i].refLowData)) >>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/include/math.h:118:19: note: >>> expanded from macro 'isnan' __fp_type_select(x, __inline_isnanf, >>> __inline_isnan, __inline_isnanl) ^ /usr/include/math.h:86:49: note: >>> expanded from macro '__fp_type_select' #define __fp_type_select(x, >>> f, d, ld) _Generic((x), =20 >>=20 >> This looks like a correct error. isnan(unsigned int) is undefined >> behaviour in C or C++. Now, we have a hard error instead of doing >> something random. This change was made it make it easier to find >> logic errors at compile time, and it seems to be doing exactly that >> here: now the port fails to build, rather than building and having >> undefined behaviour. >>=20 >> David >>=20 >=20 > Hello David. >=20 > Thank you very much for this insight. >=20 > As I understand it for now, the math.h/cmath behaviour is as expected = by > defintion an correct so far in FreeBSD? If yes, it would imply that = the > port graphics/blender is broken then. In the latter case the blender > developers should be correct this upstream, shouldn't they? Yes, I believe (and am willing to be convinced otherwise by test cases) = that we now accept anything that the standard allows and reject with a = compile-time error things that are undefined behaviour. =46rom the tiny snipped of code in the error message, my guess would be = that refLowData is something that is read from a file (header?) as an = unsigned int and is supposed to be a float here, and so needs a cast via = a union (or just a *(float*)& if strict aliasing is not turned on). David --Apple-Mail=_66689E9D-464E-4899-962F-C7EE5BE4DA38 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJSD4xqAAoJEKx65DEEsqIdNIgQAIEam38OPstMFkMo8lSuzVDP tPfqRdHL3rxuxB6dWsBr0cB25nG0bPfcBpaj2Cyb3YwRCET2uMvg6236h377tLQM 4xvD5NXYLSdsHsZtzZMt2ZmPq0vDU8sjJW4I+UE+TUi987/XVbS+osG6mQwncB3Y X/JSZDF0Og/3W9hOVLCVAxF4xW0qRWwQ/JhZgExPNvxBBgJjwouABs4XwXx82Ldh 7prC6h6a6Czs67yeJgEh7Iqs9MxnAXFsXK8S1hh9PRBgP3wD/hU2VgOfImZHLVin 93QqQRodOIKoumUUq6IwByIUMNMZMt0ztForWAGtvKmkeXSAVlGTArgv2ksO8dsV ADnBWNpT1O3RHVzPFT+xZL6ZAl2RJyOQwjMAVlitNY5pCQMD+akFX3LZgsIFPNpg gC4VGVgUapIJ2SRVfDVSopJaMOhOSA/k2tVhvsGFxj/n0xeEJjTTjWJ0E8YpbRhK L4TOBfEN71wIwF5Sap/icR8DeN0h+0Hx0mWq8ZknrO6/inm4PKvQ+Y6ZjBA3G+Ex SPBg1cpf85VuKcv4rDzxxq/np1qvGilqn10qMATPgkehCcVP4WZFt28qXnEj8spY 76XG0DOK2R3g07xS7ZMFriRLddak4KRRgxJuJ2kIMGxK4QfqZoGmAEKq4JLSOhgZ wnx20D0/COEZNZTMY6TW =OUOY -----END PGP SIGNATURE----- --Apple-Mail=_66689E9D-464E-4899-962F-C7EE5BE4DA38--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2097500C-2A49-4532-BF6C-C4AFB5778BC7>