I could use some help figuring out the best fix for the following problem where only the i686 builds fail:
cd /builddir/build/BUILD/oiio-Release-1.7.7/build/linux/src/libutil && /usr/bin/cmake -E cmake_link_script CMakeFiles/fmath_test.dir/link.txt --verbose=1 /usr/bin/c++ -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -O2 -g -DNDEBUG -Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld CMakeFiles/fmath_test.dir/fmath_test.cpp.o -o fmath_test -rdynamic libOpenImageIO_Util.so.1.7.7 -lboost_filesystem -lboost_regex -lboost_system -lboost_thread -lboost_chrono -lboost_date_time -lboost_atomic -lrt -ldl -lImath -lIex -lHalf -lIlmThread -lpthread -Wl,-rpath,/builddir/build/BUILD/oiio-Release-1.7.7/build/linux/src/libutil make[2]: Leaving directory '/builddir/build/BUILD/oiio-Release-1.7.7/build/linux' [ 72%] Built target fmath_test In file included from /builddir/build/BUILD/oiio-Release-1.7.7/src/include/OpenImageIO/fmath.h:64:0, from /builddir/build/BUILD/oiio-Release-1.7.7/src/include/OpenImageIO/hash.h:50, from /builddir/build/BUILD/oiio-Release-1.7.7/src/include/OpenImageIO/strutil.h:54, from /builddir/build/BUILD/oiio-Release-1.7.7/src/include/OpenImageIO/ustring.h:137, from /builddir/build/BUILD/oiio-Release-1.7.7/src/libtexture/texturesys.cpp:44: /builddir/build/BUILD/oiio-Release-1.7.7/src/include/OpenImageIO/simd.h: In member function 'bool OpenImageIO::v1_7::pvt::TextureSystemImpl::sample_bicubic(int, const float*, const float*, int, OpenImageIO::v1_7::pvt::TextureSystemImpl::TextureFile&, OpenImageIO::v1_7::pvt::TextureSystemImpl::PerThreadInfo*, OpenImageIO::v1_7::TextureOpt&, int, int, const float*, OpenImageIO::v1_7::simd::float4*, OpenImageIO::v1_7::simd::float4*, OpenImageIO::v1_7::simd::float4*)': /builddir/build/BUILD/oiio-Release-1.7.7/src/include/OpenImageIO/simd.h:308:71: error: '*((void*)& dwy +12)' may be used uninitialized in this function [-Werror=maybe-uninitialized] #define SIMD_CONSTRUCT(x) for (int i = 0; i < elements; ++i) m_val[i] = (x) ^ /builddir/build/BUILD/oiio-Release-1.7.7/src/libtexture/texturesys.cpp:2473:20: note: '*((void*)& dwy +12)' was declared here float4 wy, dwy;
Full build logs here: https://kojipkgs.fedoraproject.org//work/tasks/2540/15912540/build.log
Upstream does not test or use 32bit builds in production...
The following workaround was suggested by upstream and seemed to do the trick but upstream doesn't want to perform needless initialization on platforms/arches that don't require it.
Ok, in texturesys.cpp, circa line 2472, please add the following two lines (bold):
float4 wx, dwx; float4 wy, dwy; if (daccumds_) { evalBSplineWeights_and_derivs (&wx, sfrac, &dwx); evalBSplineWeights_and_derivs (&wy, tfrac, &dwy); } else { wx = evalBSplineWeights (float4(sfrac)); wy = evalBSplineWeights (float4(tfrac)); * dwx = float4::Zero();* * dwy = float4::Zero();* }
Any suggestions?
Thanks, Richard
On 10/13/2016 12:04 PM, Richard Shaw wrote:
The following workaround was suggested by upstream and seemed to do the trick but upstream doesn't want to perform needless initialization on platforms/arches that don't require it.
Why would it be arch-dependent whether or not a variable needs to be initialized?
On Thu, Oct 13, 2016 at 6:15 PM, Samuel Sieb samuel@sieb.net wrote:
On 10/13/2016 12:04 PM, Richard Shaw wrote:
The following workaround was suggested by upstream and seemed to do the trick but upstream doesn't want to perform needless initialization on platforms/arches that don't require it.
Why would it be arch-dependent whether or not a variable needs to be
initialized?
No clue, that's why I'm asking :)
Thanks, Richard
On 10/14/2016 01:15 AM, Samuel Sieb wrote:
On 10/13/2016 12:04 PM, Richard Shaw wrote:
The following workaround was suggested by upstream and seemed to do the trick but upstream doesn't want to perform needless initialization on platforms/arches that don't require it.
Why would it be arch-dependent whether or not a variable needs to be initialized?
These warnings are issued from the optimizers. There are some GCC optimizations which are architecture-specific and run very early, before the warnings discussed here are generated.
-Werror for optimizer-dependent warnings is usually not a good idea for this reason.
Florian
On Fri, Oct 14, 2016 at 1:24 AM, Florian Weimer fweimer@redhat.com wrote:
On 10/14/2016 01:15 AM, Samuel Sieb wrote:
On 10/13/2016 12:04 PM, Richard Shaw wrote:
The following workaround was suggested by upstream and seemed to do the trick but upstream doesn't want to perform needless initialization on platforms/arches that don't require it.
Why would it be arch-dependent whether or not a variable needs to be
initialized?
These warnings are issued from the optimizers. There are some GCC optimizations which are architecture-specific and run very early, before the warnings discussed here are generated.
-Werror for optimizer-dependent warnings is usually not a good idea for this reason.
Any specific recommendations for this issue? Should the variables be initialized on x86_64 too or some kind of conditional implemented?
Thanks, Richard
On 10/17/2016 03:08 PM, Richard Shaw wrote:
On Fri, Oct 14, 2016 at 1:24 AM, Florian Weimer fweimer@redhat.com wrote:
On 10/14/2016 01:15 AM, Samuel Sieb wrote:
On 10/13/2016 12:04 PM, Richard Shaw wrote:
The following workaround was suggested by upstream and seemed to do the trick but upstream doesn't want to perform needless initialization on platforms/arches that don't require it.
Why would it be arch-dependent whether or not a variable needs to be
initialized?
These warnings are issued from the optimizers. There are some GCC optimizations which are architecture-specific and run very early, before the warnings discussed here are generated.
-Werror for optimizer-dependent warnings is usually not a good idea for this reason.
Any specific recommendations for this issue? Should the variables be initialized on x86_64 too or some kind of conditional implemented?
What's the definition of the float4 type?
Thanks, Florian
On Mon, Oct 17, 2016 at 8:11 AM, Florian Weimer fweimer@redhat.com wrote:
On 10/17/2016 03:08 PM, Richard Shaw wrote:
Any specific recommendations for this issue? Should the variables be initialized on x86_64 too or some kind of conditional implemented?
What's the definition of the float4 type?
Does this help? I'm not very fluent in C/C++.
https://github.com/OpenImageIO/oiio/blob/master/src/include/OpenImageIO/simd...
Thanks, Richard