Re: Bad-sounding schur.cc compilation warnings

[Rik]

On 05/02/2016 02:09 PM, Daniel J Sebald wrote:
>
>>>> around Fortran function calls can potentially use longjmp to recover
>>>> from errors which is why you're getting the message.  If you look at the
>>>> actual C++ code it immediately returns after calling the Fortran
>>>> function and so any clobbered value would not get used.
>>>>
>>>> Most of the time we have used the volatile keyword as part of the
>>>> variable declaration just to quiet the compiler.  There is probably a
>>>> small performance penalty for doing so, but since we've done it
>>>> everywhere else, we could also do it here.  For what it's worth, I don't
>>>> get any such nasty warning with gcc-5.2.1.
>>>
>>> OK. I've version 4.8.4:
>>>
>>> gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.1)
>>>
>>> Mint/Unbuntu seems behind a bit in software versions, maybe with the
>>> intent of being more bug stable.
>>>
>>> Dan
>>>
>> Dan,
>>
>> Can you try the attached cset?  It should suppress the warning message.
>>
>> --Rik
>
> I did
>
> touch /home/sebald/octave/octave/octave/liboctave/numeric/schur.cc
> make
> [I see the errors]
> patch -p1 < ~/octave/rik/schurv.cset
> make
> [I don't see the error at 176 any longer]
>
> So, yes, prevents the warning.  But there are three more instances of
> this error at these lines
>
> /home/sebald/octave/octave/octave/liboctave/numeric/schur.cc:263:18:
> warning: variable 'selector' might be clobbered by 'longjmp' or 'vfork'
> [-Wclobbered]
>    float_selector selector = 0;
>                   ^
> /home/sebald/octave/octave/octave/liboctave/numeric/schur.cc:352:20:
> warning: variable 'selector' might be clobbered by 'longjmp' or 'vfork'
> [-Wclobbered]
>    complex_selector selector = 0;
>                     ^
> /home/sebald/octave/octave/octave/liboctave/numeric/schur.cc:461:26:
> warning: variable 'selector' might be clobbered by 'longjmp' or 'vfork'
> [-Wclobbered]
>    float_complex_selector selector = 0;
>                           ^
>
> Thanks,
>
> Dan
>
Dan,

I fixed up the other instances and checked in a cset here
http://hg.savannah.gnu.org/hgweb/octave/rev/79414f8e6f24.

--Rik