OpenImageIO: i686 builds failing

[Richard Shaw]

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

[Samuel Sieb]

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?

[Richard Shaw]

On Thu, Oct 13, 2016 at 6:15 PM, Samuel Sieb <samuel(a)sieb.net&gt; 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

[Florian Weimer]

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

[Richard Shaw]

On Fri, Oct 14, 2016 at 1:24 AM, Florian Weimer <fweimer(a)redhat.com&gt; 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

[Florian Weimer]

On 10/17/2016 03:08 PM, Richard Shaw wrote:
>  On Fri, Oct 14, 2016 at 1:24 AM, Florian Weimer
> <fweimer(a)redhat.com&gt; 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

[Richard Shaw]

On Mon, Oct 17, 2016 at 8:11 AM, Florian Weimer <fweimer(a)redhat.com&gt; 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/s...


Thanks,
Richard