graphics/blender: math.h: isnan(): error: controlling expression type 'unsigned int' not compatible with any generic association type
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. I think this is dur to some issues of inconsistency/incompatibility of the math.h/cmath headers regarding the reported c++11 issues. 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. [ 55%] Building C object source/blender/imbuf/intern/cineon/CMakeFiles/bf_imbuf_cineon.dir/cineon_dpx.c.o [ 55%] Building C object source/blender/imbuf/intern/cineon/CMakeFiles/bf_imbuf_cineon.dir/cineonlib.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 == 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), signature.asc Description: PGP signature
Re: graphics/blender: math.h: isnan(): error: controlling expression type 'unsigned int' not compatible with any generic association type
On 17 Aug 2013, at 10:48, O. Hartmann ohart...@zedat.fu-berlin.de wrote: 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. I think this is dur to some issues of inconsistency/incompatibility of the math.h/cmath headers regarding the reported c++11 issues. 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. [ 55%] Building C object source/blender/imbuf/intern/cineon/CMakeFiles/bf_imbuf_cineon.dir/cineon_dpx.c.o [ 55%] Building C object source/blender/imbuf/intern/cineon/CMakeFiles/bf_imbuf_cineon.dir/cineonlib.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 == 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), 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. David signature.asc Description: Message signed with OpenPGP using GPGMail
Re: graphics/blender: math.h: isnan(): error: controlling expression type 'unsigned int' not compatible with any generic association type
On Sat, 17 Aug 2013 11:24:41 +0100 David Chisnall thera...@freebsd.org wrote: On 17 Aug 2013, at 10:48, O. Hartmann ohart...@zedat.fu-berlin.de wrote: 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. I think this is dur to some issues of inconsistency/incompatibility of the math.h/cmath headers regarding the reported c++11 issues. 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. [ 55%] Building C object source/blender/imbuf/intern/cineon/CMakeFiles/bf_imbuf_cineon.dir/cineon_dpx.c.o [ 55%] Building C object source/blender/imbuf/intern/cineon/CMakeFiles/bf_imbuf_cineon.dir/cineonlib.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 == 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), 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. David Hello David. Thank you very much for this insight. 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? Again, thank you very much and for the patience explaining it again. Regards, Oliver signature.asc Description: PGP signature
Re: graphics/blender: math.h: isnan(): error: controlling expression type 'unsigned int' not compatible with any generic association type
On 17 Aug 2013, at 15:39, O. Hartmann ohart...@zedat.fu-berlin.de wrote: On Sat, 17 Aug 2013 11:24:41 +0100 David Chisnall thera...@freebsd.org wrote: On 17 Aug 2013, at 10:48, O. Hartmann ohart...@zedat.fu-berlin.de wrote: 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. I think this is dur to some issues of inconsistency/incompatibility of the math.h/cmath headers regarding the reported c++11 issues. 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. [ 55%] Building C object source/blender/imbuf/intern/cineon/CMakeFiles/bf_imbuf_cineon.dir/cineon_dpx.c.o [ 55%] Building C object source/blender/imbuf/intern/cineon/CMakeFiles/bf_imbuf_cineon.dir/cineonlib.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 == 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), 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. David Hello David. Thank you very much for this insight. 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. From 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 signature.asc Description: Message signed with OpenPGP using GPGMail
