[Scilab-Dev] 64-bit build oddness

[Crispin Boylan]

sure, I have attached.

i have tried builds with -fno-stack-protector, -fstack-protector and 
-fstack-protector-all  - all give the same result.

one thing i did to was write a little test fortran program that does the 
same as number_properties('denorm') ie:

program hell

c     EXTERNAL FUNCTIONS
       double precision dlamch
       external         dlamch

          if (dlamch('u') / dlamch('b') .gt. 0.d0) then
             print *, "denorm"
          else
             print *, "dang this thing is borked"
          endif
end

gfortran hell.f -llapack


prints denorm on the simple test case, and if i stick the same trace in 
sci_f_number_properties.f i get "dang this thing is borked", despite 
dlamch('u') and dlamch('b') returning the same thing in both cases........


thanks
cris.



On 26/08/15 08:48, Clément David wrote:
> Hello Crispin,
>
> Can you send me your config.log for the failed build ? Did you use any
> '-fstack-protector' flags ?
>
> --
> Clément
>
> Le mardi 25 août 2015 à 20:45 +0100, Crispin Boylan a écrit :
>> hi
>>
>> thanks for taking a look , but it is already linking against refBLAS,
>> i
>> dont have openBLAS installed anywhere.
>>
>> i tried running the lapack/blas testsuite and all tests pass
>> successfully.
>>
>> given that the binary version runs successfully. on the same machine
>> i
>> figure it's not glibc...
>>
>> any other ideas for me to try?
>>
>> thanks
>> cris.
>>
>>
>> On 25/08/15 13:30, Clément David wrote:
>>> Hello,
>>>
>>> On my Fedora 22 laptop, the build PASS on Intel platforms (both
>>> i686
>>> x86_64) [1].
>>>
>>> On your log I found that you are using openblas ; can you try
>>> linking
>>> against refBLAS ?
>>>
>>> [1]: https://apps.fedoraproject.org/packages/scilab
>>>
>>> Regards,
>>>
>>> --
>>> Clément <davidcl> David
>>>
>>> Le dimanche 23 août 2015 à 23:55 +0100, Crispin Boylan a écrit :
>>>> hi
>>>>
>>>> i wonder if anyone can help me with some build weirdness i'm
>>>> experiencing.  Any help appreciated as it has me totally stumped.
>>>>
>>>> On openmandriva I can build i586 fine, no problems all tests
>>>> pass. On
>>>> x86_64 i'm seeing odd behaviour:
>>>>
>>>> 1. looks like some sort of corruption in the 'debug' output:
>>>>
>>>>     setgetmode  ¦q¦  d   ¦¦         -1     307
>>>>     stackg  ¦4¦%  7¦  ¦4¦%        -4
>>>>
>>>> I know on windows for example this does not happen.  However I
>>>> can
>>>> also
>>>> see this on the prebuilt binaries for x86_64 so I'm wondering if
>>>> this
>>>> is
>>>> just a linux thing.
>>>>
>>>> 2. make doc fails with an 'invalid index error' ( i raised bug
>>>> 14088
>>>> about this).
>>>>
>>>> I finally tracked this down to:
>>>>
>>>> a=[]
>>>> a($)
>>>>
>>>> giving an invalid index.  It seems this was working on 5.3.3 but
>>>> only
>>>> because the extra checks on empty lists in matext1/2 between
>>>> 5.5.0
>>>> -beta1
>>>> and 5.5.0 were not there.
>>>>
>>>> This part of the code is producing the error:
>>>>
>>>>             if(
>>>>         &     stk(sadr(il1+4)).le.0.and.
>>>>         &     abs(istk(il1)).ne.4.or.
>>>>         &   (abs(istk(il1)).ne.1.and.
>>>>         &   abs(istk(il1)).ne.2.and.
>>>>         &   abs(istk(il1)).ne.4.and.
>>>>         &   abs(istk(il1)).ne.129)) then
>>>>                call error(21)
>>>>                return
>>>>             endif
>>>>
>>>>
>>>> so for some reason stk(sadr(il1+4)) is giving a negative number
>>>> for
>>>> a($).  If I add the type check for 2 and 129 to the first part of
>>>> the
>>>> expression it succeeds.
>>>>
>>>>
>>>> 3. IEEEcompatibility test fails.
>>>>
>>>> This is due to number_properties('denorm') returning F.  I've
>>>> tried
>>>> fiddling with the build properties of lapack to remove
>>>> optimisation
>>>> etc
>>>> without success.
>>>>
>>>>
>>>> So i'm thinking overall there's something odd about this build,
>>>> but I
>>>> cant for the life of me think what.  Some things i've tried:
>>>>
>>>> Using a different kernel
>>>> Freshly built gcc 5.2.0 with no patches
>>>> Updating a gcc
>>>> Rebuilding lapack (3.5) with various options removed
>>>> Rebuilding glibc with most of our patches and optimisation levels
>>>> removed
>>>> Rebuilding scilab with no optimisation
>>>>
>>>> The fact that this happens on both our platforms (2014.2 has gcc
>>>> 4.8/glibc 2.19 and dev has gcc 5.2/glibc 2.22) is odd...
>>>>
>>>> Any suggestions?
>>>>
>>>> thanks
>>>> cris.
>>>>
>>>> _______________________________________________
>>>> dev mailing list
>>>> dev at lists.scilab.org
>>>> http://lists.scilab.org/mailman/listinfo/dev
>>> _______________________________________________
>>> dev mailing list
>>> dev at lists.scilab.org
>>> http://lists.scilab.org/mailman/listinfo/dev
>> _______________________________________________
>> dev mailing list
>> dev at lists.scilab.org
>> http://lists.scilab.org/mailman/listinfo/dev
> _______________________________________________
> dev mailing list
> dev at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: config.log.xz
Type: application/x-xz
Size: 22248 bytes
Desc: not available
URL: <https://lists.scilab.org/pipermail/dev/attachments/20150826/d8a7cc87/attachment.xz>