[Scilab-Dev] 64-bit build oddness

[Crispin Boylan]

further to this:

* I'm talking about scilab 5.x here.

* regarding denorm numbers, i get:

Scilab 5.5.2 (Aug 21 2015, 21:23:02)

-->number_properties('radix')
  ans  =

     2.

-->number_properties('tiny')
  ans  =

     2.22D-308

-->number_properties('tiny') / number_properties('radix')
  ans  =

     0.

-->

which is all that number_properties('denorm') really does. interesting 
because tiny/radix is done in fortran on the scilab side, so it looks 
like lapack is working just not the basic division..

I've also tried rebuilding mpfr/gmp/mpc latest versions and after that 
gcc in case that is anything to do with it.



On 23/08/15 23:55, Crispin Boylan wrote:
> 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