Hi All,

Just a heads up, I'm currently looking into a tricky problem that has
surfaced for runtime-type identification code and word sizing /
structure padding.  The current code was written in the way it is now
to deal with differences in structure padding for various systems,
particularly to address an issue with ARM CPUs.  However, an issue has
appeared that affects builds using floats but compiled for 64-bit
CPUs.  It looks like the size used for floats are still 32 bits (4
bytes), as expected, but when used in a struct, it gets allocated as a
size of 64 bits (8 bytes) to match the word size of the 64-bit CPU.
This has gone undetected up until now as we had not been using float
builds on 64-bit CPUs, but this is the case for iOS and arm64 CPUs
(i.e., recent iPads and iPhones).  From what I can gather, the
existing code works fine for floats and doubles on 32-bit CPUs, and
doubles on 64-bit CPUs, regardless of padding.

I've updated the memory offset calculation to take into account the
word size and that now seems correct.  However, the test CSD is still
causing problems, which leads me to think that code calculating sizes
for variable memory and pointer assignment needs review.  I suspect we
may need to do extra padding to the size of MYFLT which should
hopefully fix the issue.  I'm out of time for tonight, but hope to get
this sorted out tomorrow. Once a fix is found, I will do testing on
platforms I can test on, but will need others to test more broadly
across CPU types and platforms. I will report back here once a fix is
found.

Thanks!

Did you try changing the build on arm64 to doubles?

Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy
Maynooth University
Ireland

> On 11 Apr 2016, at 04:06, Steven Yi  wrote:
> 
> Hi All,
> 
> Just a heads up, I'm currently looking into a tricky problem that has
> surfaced for runtime-type identification code and word sizing /
> structure padding.  The current code was written in the way it is now
> to deal with differences in structure padding for various systems,
> particularly to address an issue with ARM CPUs.  However, an issue has
> appeared that affects builds using floats but compiled for 64-bit
> CPUs.  It looks like the size used for floats are still 32 bits (4
> bytes), as expected, but when used in a struct, it gets allocated as a
> size of 64 bits (8 bytes) to match the word size of the 64-bit CPU.
> This has gone undetected up until now as we had not been using float
> builds on 64-bit CPUs, but this is the case for iOS and arm64 CPUs
> (i.e., recent iPads and iPhones).  From what I can gather, the
> existing code works fine for floats and doubles on 32-bit CPUs, and
> doubles on 64-bit CPUs, regardless of padding.
> 
> I've updated the memory offset calculation to take into account the
> word size and that now seems correct.  However, the test CSD is still
> causing problems, which leads me to think that code calculating sizes
> for variable memory and pointer assignment needs review.  I suspect we
> may need to do extra padding to the size of MYFLT which should
> hopefully fix the issue.  I'm out of time for tonight, but hope to get
> this sorted out tomorrow. Once a fix is found, I will do testing on
> platforms I can test on, but will need others to test more broadly
> across CPU types and platforms. I will report back here once a fix is
> found.
> 
> Thanks!

I can confirm this on x86_64 with the float build.
========================
Dr Victor Lazzarini
Dean of Arts, Celtic Studies and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 11 Apr 2016, at 04:06, Steven Yi  wrote:
> 
> Hi All,
> 
> Just a heads up, I'm currently looking into a tricky problem that has
> surfaced for runtime-type identification code and word sizing /
> structure padding.  The current code was written in the way it is now
> to deal with differences in structure padding for various systems,
> particularly to address an issue with ARM CPUs.  However, an issue has
> appeared that affects builds using floats but compiled for 64-bit
> CPUs.  It looks like the size used for floats are still 32 bits (4
> bytes), as expected, but when used in a struct, it gets allocated as a
> size of 64 bits (8 bytes) to match the word size of the 64-bit CPU.
> This has gone undetected up until now as we had not been using float
> builds on 64-bit CPUs, but this is the case for iOS and arm64 CPUs
> (i.e., recent iPads and iPhones).  From what I can gather, the
> existing code works fine for floats and doubles on 32-bit CPUs, and
> doubles on 64-bit CPUs, regardless of padding.
> 
> I've updated the memory offset calculation to take into account the
> word size and that now seems correct.  However, the test CSD is still
> causing problems, which leads me to think that code calculating sizes
> for variable memory and pointer assignment needs review.  I suspect we
> may need to do extra padding to the size of MYFLT which should
> hopefully fix the issue.  I'm out of time for tonight, but hope to get
> this sorted out tomorrow. Once a fix is found, I will do testing on
> platforms I can test on, but will need others to test more broadly
> across CPU types and platforms. I will report back here once a fix is
> found.
> 
> Thanks!

I have not tried anything for arm64 as I do not have a device with
that CPU at this time.  I reproduced and tested on x86_64 with floats
build.

On Mon, Apr 11, 2016 at 1:30 AM, Victor Lazzarini
 wrote:
> Did you try changing the build on arm64 to doubles?
>
> Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy
> Maynooth University
> Ireland
>
>> On 11 Apr 2016, at 04:06, Steven Yi  wrote:
>>
>> Hi All,
>>
>> Just a heads up, I'm currently looking into a tricky problem that has
>> surfaced for runtime-type identification code and word sizing /
>> structure padding.  The current code was written in the way it is now
>> to deal with differences in structure padding for various systems,
>> particularly to address an issue with ARM CPUs.  However, an issue has
>> appeared that affects builds using floats but compiled for 64-bit
>> CPUs.  It looks like the size used for floats are still 32 bits (4
>> bytes), as expected, but when used in a struct, it gets allocated as a
>> size of 64 bits (8 bytes) to match the word size of the 64-bit CPU.
>> This has gone undetected up until now as we had not been using float
>> builds on 64-bit CPUs, but this is the case for iOS and arm64 CPUs
>> (i.e., recent iPads and iPhones).  From what I can gather, the
>> existing code works fine for floats and doubles on 32-bit CPUs, and
>> doubles on 64-bit CPUs, regardless of padding.
>>
>> I've updated the memory offset calculation to take into account the
>> word size and that now seems correct.  However, the test CSD is still
>> causing problems, which leads me to think that code calculating sizes
>> for variable memory and pointer assignment needs review.  I suspect we
>> may need to do extra padding to the size of MYFLT which should
>> hopefully fix the issue.  I'm out of time for tonight, but hope to get
>> this sorted out tomorrow. Once a fix is found, I will do testing on
>> platforms I can test on, but will need others to test more broadly
>> across CPU types and platforms. I will report back here once a fix is
>> found.
>>
>> Thanks!

I've pushed a fix to Git that I think fixes the issue.  At least, I'm
now getting the test CSD to work with float builds for 64-bit CPU, and
C and csdtests are passing with doubles builds and 64-bit CPU. For
float and 64-bit, my setup is not building the C tests, and the
csdtests are currently hanging on test_fsig_udo.csd which tests
copying of fsigs for UDOs.  Killing that process continues on with
further hangs on other CSDs.  I have to leave shortly but will plan to
continue looking at this in the afternoon here.

On Mon, Apr 11, 2016 at 9:15 AM, Steven Yi  wrote:
> I have not tried anything for arm64 as I do not have a device with
> that CPU at this time.  I reproduced and tested on x86_64 with floats
> build.
>
> On Mon, Apr 11, 2016 at 1:30 AM, Victor Lazzarini
>  wrote:
>> Did you try changing the build on arm64 to doubles?
>>
>> Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy
>> Maynooth University
>> Ireland
>>
>>> On 11 Apr 2016, at 04:06, Steven Yi  wrote:
>>>
>>> Hi All,
>>>
>>> Just a heads up, I'm currently looking into a tricky problem that has
>>> surfaced for runtime-type identification code and word sizing /
>>> structure padding.  The current code was written in the way it is now
>>> to deal with differences in structure padding for various systems,
>>> particularly to address an issue with ARM CPUs.  However, an issue has
>>> appeared that affects builds using floats but compiled for 64-bit
>>> CPUs.  It looks like the size used for floats are still 32 bits (4
>>> bytes), as expected, but when used in a struct, it gets allocated as a
>>> size of 64 bits (8 bytes) to match the word size of the 64-bit CPU.
>>> This has gone undetected up until now as we had not been using float
>>> builds on 64-bit CPUs, but this is the case for iOS and arm64 CPUs
>>> (i.e., recent iPads and iPhones).  From what I can gather, the
>>> existing code works fine for floats and doubles on 32-bit CPUs, and
>>> doubles on 64-bit CPUs, regardless of padding.
>>>
>>> I've updated the memory offset calculation to take into account the
>>> word size and that now seems correct.  However, the test CSD is still
>>> causing problems, which leads me to think that code calculating sizes
>>> for variable memory and pointer assignment needs review.  I suspect we
>>> may need to do extra padding to the size of MYFLT which should
>>> hopefully fix the issue.  I'm out of time for tonight, but hope to get
>>> this sorted out tomorrow. Once a fix is found, I will do testing on
>>> platforms I can test on, but will need others to test more broadly
>>> across CPU types and platforms. I will report back here once a fix is
>>> found.
>>>
>>> Thanks!

Tried here and it seems to fix the offending CSD (from Dr B’s project).
========================
Dr Victor Lazzarini
Dean of Arts, Celtic Studies and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 11 Apr 2016, at 14:36, Steven Yi  wrote:
> 
> I've pushed a fix to Git that I think fixes the issue.  At least, I'm
> now getting the test CSD to work with float builds for 64-bit CPU, and
> C and csdtests are passing with doubles builds and 64-bit CPU. For
> float and 64-bit, my setup is not building the C tests, and the
> csdtests are currently hanging on test_fsig_udo.csd which tests
> copying of fsigs for UDOs.  Killing that process continues on with
> further hangs on other CSDs.  I have to leave shortly but will plan to
> continue looking at this in the afternoon here.
> 
> On Mon, Apr 11, 2016 at 9:15 AM, Steven Yi  wrote:
>> I have not tried anything for arm64 as I do not have a device with
>> that CPU at this time.  I reproduced and tested on x86_64 with floats
>> build.
>> 
>> On Mon, Apr 11, 2016 at 1:30 AM, Victor Lazzarini
>>  wrote:
>>> Did you try changing the build on arm64 to doubles?
>>> 
>>> Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy
>>> Maynooth University
>>> Ireland
>>> 
>>>> On 11 Apr 2016, at 04:06, Steven Yi  wrote:
>>>> 
>>>> Hi All,
>>>> 
>>>> Just a heads up, I'm currently looking into a tricky problem that has
>>>> surfaced for runtime-type identification code and word sizing /
>>>> structure padding.  The current code was written in the way it is now
>>>> to deal with differences in structure padding for various systems,
>>>> particularly to address an issue with ARM CPUs.  However, an issue has
>>>> appeared that affects builds using floats but compiled for 64-bit
>>>> CPUs.  It looks like the size used for floats are still 32 bits (4
>>>> bytes), as expected, but when used in a struct, it gets allocated as a
>>>> size of 64 bits (8 bytes) to match the word size of the 64-bit CPU.
>>>> This has gone undetected up until now as we had not been using float
>>>> builds on 64-bit CPUs, but this is the case for iOS and arm64 CPUs
>>>> (i.e., recent iPads and iPhones).  From what I can gather, the
>>>> existing code works fine for floats and doubles on 32-bit CPUs, and
>>>> doubles on 64-bit CPUs, regardless of padding.
>>>> 
>>>> I've updated the memory offset calculation to take into account the
>>>> word size and that now seems correct.  However, the test CSD is still
>>>> causing problems, which leads me to think that code calculating sizes
>>>> for variable memory and pointer assignment needs review.  I suspect we
>>>> may need to do extra padding to the size of MYFLT which should
>>>> hopefully fix the issue.  I'm out of time for tonight, but hope to get
>>>> this sorted out tomorrow. Once a fix is found, I will do testing on
>>>> platforms I can test on, but will need others to test more broadly
>>>> across CPU types and platforms. I will report back here once a fix is
>>>> found.
>>>> 
>>>> Thanks!

Thanks Victor for the feedback! I suspect the UDO issue I was seeing was also related to padding, but I will have to investigate further when I'm back on my computer later today. For now though, it seems like there are no regressions (fingers crossed!) and at least a partial fix.

Update: I'm looking into the UDO issue and it's a bit strange. I'm
consistently getting problems when running "make csdtests" from the
commandline where I have to use ctrl-\ to send a SIGQUIT for 8 of the
tests.  They all have to do with UDO's with more complex data types
(i.e., fsigs, arrays).  Now, when I run test_fsig_udo.csd from the
commandline, it runs fine.  Running test_karrays_udo.csd gives a
segfault.  When I run these from XCode, they run without problems.
(!!!)

>From the commandline with lldb, I get:

Process 38495 launched: './csound' (x86_64)
0dBFS level = 32768.0
Csound version 6.07 (float samples) Apr 11 2016
libsndfile-1.0.25
Reading options from $HOME/.csound6rc
csound->FileOpen2 failed:: No such file or directory
UnifiedCSD:  ../tests/commandline/test_karrays_udo.csd
STARTING FILE
Creating options
Creating orchestra
Creating score
Elapsed time at end of orchestra compile: real: 0.002s, CPU: 0.002s
sorting score ...
... done
Elapsed time at end of score sort: real: 0.002s, CPU: 0.002s
--Csound version 6.07 (float samples) Apr 11 2016
displays suppressed
0dBFS level = 32768.0
orch now loaded
audio buffered in 1024 sample-frame blocks
 unknown rtaudio module: 'pa_bl', using dummy module
rtaudio: dummy module enabled
writing 1024 sample blks of 32-bit floats to dac
SECTION 1:
new alloc for instr 1:

Process 38495 stopped
* thread #1: tid = 0x2c0f3, 0x0000000100026cf5 CsoundLib`mfree + 85,
queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=EXC_I386_GPFLT)
    frame #0: 0x0000000100026cf5 CsoundLib`mfree + 85
CsoundLib`mfree:
->  0x100026cf5 <+85>: movq   (%rax), %rax
    0x100026cf8 <+88>: movq   %rax, -0x20(%rbp)
    0x100026cfc <+92>: movq   -0x18(%rbp), %rax
    0x100026d00 <+96>: movq   0x8(%rax), %rax

(lldb) bt

* thread #1: tid = 0x2c0f3, 0x0000000100026cf5 CsoundLib`mfree + 85,
queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=EXC_I386_GPFLT)

  * frame #0: 0x0000000100026cf5 CsoundLib`mfree + 85
    frame #1: 0x000000010003d2e0 CsoundLib`array_copy_value + 400
    frame #2: 0x0000000100022f80 CsoundLib`xinset + 224
    frame #3: 0x00000001000212f4 CsoundLib`useropcdset + 2180
    frame #4: 0x000000010001d1bd CsoundLib`insert + 3293
    frame #5: 0x000000010002d6b2 CsoundLib`process_score_event + 2114
    frame #6: 0x000000010002bf16 CsoundLib`sensevents + 966
    frame #7: 0x00000001001869af CsoundLib`csoundPerform + 223
    frame #8: 0x0000000100001a9b csound`main + 731
    frame #9: 0x00000001000017b4 csound`start + 52

I'm not quit sure what is going on yet.

Victor: Could you by chance run the csdtests on your computer with a
float build for 64-bit cpu and see if the same problems manifest?

On Mon, Apr 11, 2016 at 11:34 AM, Steven Yi  wrote:
> Thanks Victor for the feedback! I suspect the UDO issue I was seeing was
> also related to padding, but I will have to investigate further when I'm
> back on my computer later today. For now though, it seems like there are no
> regressions (fingers crossed!) and at least a partial fix.
>
>
> On Mon, Apr 11, 2016, 10:18 AM Victor Lazzarini 
> wrote:
>>
>> Tried here and it seems to fix the offending CSD (from Dr B’s project).
>> ========================
>> Dr Victor Lazzarini
>> Dean of Arts, Celtic Studies and Philosophy,
>> Maynooth University,
>> Maynooth, Co Kildare, Ireland
>> Tel: 00 353 7086936
>> Fax: 00 353 1 7086952
>>
>> > On 11 Apr 2016, at 14:36, Steven Yi  wrote:
>> >
>> > I've pushed a fix to Git that I think fixes the issue.  At least, I'm
>> > now getting the test CSD to work with float builds for 64-bit CPU, and
>> > C and csdtests are passing with doubles builds and 64-bit CPU. For
>> > float and 64-bit, my setup is not building the C tests, and the
>> > csdtests are currently hanging on test_fsig_udo.csd which tests
>> > copying of fsigs for UDOs.  Killing that process continues on with
>> > further hangs on other CSDs.  I have to leave shortly but will plan to
>> > continue looking at this in the afternoon here.
>> >
>> > On Mon, Apr 11, 2016 at 9:15 AM, Steven Yi  wrote:
>> >> I have not tried anything for arm64 as I do not have a device with
>> >> that CPU at this time.  I reproduced and tested on x86_64 with floats
>> >> build.
>> >>
>> >> On Mon, Apr 11, 2016 at 1:30 AM, Victor Lazzarini
>> >>  wrote:
>> >>> Did you try changing the build on arm64 to doubles?
>> >>>
>> >>> Victor Lazzarini
>> >>> Dean of Arts, Celtic Studies, and Philosophy
>> >>> Maynooth University
>> >>> Ireland
>> >>>
>> >>>> On 11 Apr 2016, at 04:06, Steven Yi  wrote:
>> >>>>
>> >>>> Hi All,
>> >>>>
>> >>>> Just a heads up, I'm currently looking into a tricky problem that has
>> >>>> surfaced for runtime-type identification code and word sizing /
>> >>>> structure padding.  The current code was written in the way it is now
>> >>>> to deal with differences in structure padding for various systems,
>> >>>> particularly to address an issue with ARM CPUs.  However, an issue
>> >>>> has
>> >>>> appeared that affects builds using floats but compiled for 64-bit
>> >>>> CPUs.  It looks like the size used for floats are still 32 bits (4
>> >>>> bytes), as expected, but when used in a struct, it gets allocated as
>> >>>> a
>> >>>> size of 64 bits (8 bytes) to match the word size of the 64-bit CPU.
>> >>>> This has gone undetected up until now as we had not been using float
>> >>>> builds on 64-bit CPUs, but this is the case for iOS and arm64 CPUs
>> >>>> (i.e., recent iPads and iPhones).  From what I can gather, the
>> >>>> existing code works fine for floats and doubles on 32-bit CPUs, and
>> >>>> doubles on 64-bit CPUs, regardless of padding.
>> >>>>
>> >>>> I've updated the memory offset calculation to take into account the
>> >>>> word size and that now seems correct.  However, the test CSD is still
>> >>>> causing problems, which leads me to think that code calculating sizes
>> >>>> for variable memory and pointer assignment needs review.  I suspect
>> >>>> we
>> >>>> may need to do extra padding to the size of MYFLT which should
>> >>>> hopefully fix the issue.  I'm out of time for tonight, but hope to
>> >>>> get
>> >>>> this sorted out tomorrow. Once a fix is found, I will do testing on
>> >>>> platforms I can test on, but will need others to test more broadly
>> >>>> across CPU types and platforms. I will report back here once a fix is
>> >>>> found.
>> >>>>
>> >>>> Thanks!

I will try.

Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy
Maynooth University
Ireland

> On 12 Apr 2016, at 02:55, Steven Yi  wrote:
> 
> Update: I'm looking into the UDO issue and it's a bit strange. I'm
> consistently getting problems when running "make csdtests" from the
> commandline where I have to use ctrl-\ to send a SIGQUIT for 8 of the
> tests.  They all have to do with UDO's with more complex data types
> (i.e., fsigs, arrays).  Now, when I run test_fsig_udo.csd from the
> commandline, it runs fine.  Running test_karrays_udo.csd gives a
> segfault.  When I run these from XCode, they run without problems.
> (!!!)
> 
> From the commandline with lldb, I get:
> 
> Process 38495 launched: './csound' (x86_64)
> 0dBFS level = 32768.0
> Csound version 6.07 (float samples) Apr 11 2016
> libsndfile-1.0.25
> Reading options from $HOME/.csound6rc
> csound->FileOpen2 failed:: No such file or directory
> UnifiedCSD:  ../tests/commandline/test_karrays_udo.csd
> STARTING FILE
> Creating options
> Creating orchestra
> Creating score
> Elapsed time at end of orchestra compile: real: 0.002s, CPU: 0.002s
> sorting score ...
> ... done
> Elapsed time at end of score sort: real: 0.002s, CPU: 0.002s
> --Csound version 6.07 (float samples) Apr 11 2016
> displays suppressed
> 0dBFS level = 32768.0
> orch now loaded
> audio buffered in 1024 sample-frame blocks
> unknown rtaudio module: 'pa_bl', using dummy module
> rtaudio: dummy module enabled
> writing 1024 sample blks of 32-bit floats to dac
> SECTION 1:
> new alloc for instr 1:
> 
> Process 38495 stopped
> * thread #1: tid = 0x2c0f3, 0x0000000100026cf5 CsoundLib`mfree + 85,
> queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
> (code=EXC_I386_GPFLT)
>    frame #0: 0x0000000100026cf5 CsoundLib`mfree + 85
> CsoundLib`mfree:
> ->  0x100026cf5 <+85>: movq   (%rax), %rax
>    0x100026cf8 <+88>: movq   %rax, -0x20(%rbp)
>    0x100026cfc <+92>: movq   -0x18(%rbp), %rax
>    0x100026d00 <+96>: movq   0x8(%rax), %rax
> 
> (lldb) bt
> 
> * thread #1: tid = 0x2c0f3, 0x0000000100026cf5 CsoundLib`mfree + 85,
> queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
> (code=EXC_I386_GPFLT)
> 
>  * frame #0: 0x0000000100026cf5 CsoundLib`mfree + 85
>    frame #1: 0x000000010003d2e0 CsoundLib`array_copy_value + 400
>    frame #2: 0x0000000100022f80 CsoundLib`xinset + 224
>    frame #3: 0x00000001000212f4 CsoundLib`useropcdset + 2180
>    frame #4: 0x000000010001d1bd CsoundLib`insert + 3293
>    frame #5: 0x000000010002d6b2 CsoundLib`process_score_event + 2114
>    frame #6: 0x000000010002bf16 CsoundLib`sensevents + 966
>    frame #7: 0x00000001001869af CsoundLib`csoundPerform + 223
>    frame #8: 0x0000000100001a9b csound`main + 731
>    frame #9: 0x00000001000017b4 csound`start + 52
> 
> I'm not quit sure what is going on yet.
> 
> Victor: Could you by chance run the csdtests on your computer with a
> float build for 64-bit cpu and see if the same problems manifest?
> 
>> On Mon, Apr 11, 2016 at 11:34 AM, Steven Yi  wrote:
>> Thanks Victor for the feedback! I suspect the UDO issue I was seeing was
>> also related to padding, but I will have to investigate further when I'm
>> back on my computer later today. For now though, it seems like there are no
>> regressions (fingers crossed!) and at least a partial fix.
>> 
>> 
>> On Mon, Apr 11, 2016, 10:18 AM Victor Lazzarini 
>> wrote:
>>> 
>>> Tried here and it seems to fix the offending CSD (from Dr B’s project).
>>> ========================
>>> Dr Victor Lazzarini
>>> Dean of Arts, Celtic Studies and Philosophy,
>>> Maynooth University,
>>> Maynooth, Co Kildare, Ireland
>>> Tel: 00 353 7086936
>>> Fax: 00 353 1 7086952
>>> 
>>>> On 11 Apr 2016, at 14:36, Steven Yi  wrote:
>>>> 
>>>> I've pushed a fix to Git that I think fixes the issue.  At least, I'm
>>>> now getting the test CSD to work with float builds for 64-bit CPU, and
>>>> C and csdtests are passing with doubles builds and 64-bit CPU. For
>>>> float and 64-bit, my setup is not building the C tests, and the
>>>> csdtests are currently hanging on test_fsig_udo.csd which tests
>>>> copying of fsigs for UDOs.  Killing that process continues on with
>>>> further hangs on other CSDs.  I have to leave shortly but will plan to
>>>> continue looking at this in the afternoon here.
>>>> 
>>>>> On Mon, Apr 11, 2016 at 9:15 AM, Steven Yi  wrote:
>>>>> I have not tried anything for arm64 as I do not have a device with
>>>>> that CPU at this time.  I reproduced and tested on x86_64 with floats
>>>>> build.
>>>>> 
>>>>> On Mon, Apr 11, 2016 at 1:30 AM, Victor Lazzarini
>>>>>  wrote:
>>>>>> Did you try changing the build on arm64 to doubles?
>>>>>> 
>>>>>> Victor Lazzarini
>>>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>>>> Maynooth University
>>>>>> Ireland
>>>>>> 
>>>>>>> On 11 Apr 2016, at 04:06, Steven Yi  wrote:
>>>>>>> 
>>>>>>> Hi All,
>>>>>>> 
>>>>>>> Just a heads up, I'm currently looking into a tricky problem that has
>>>>>>> surfaced for runtime-type identification code and word sizing /
>>>>>>> structure padding.  The current code was written in the way it is now
>>>>>>> to deal with differences in structure padding for various systems,
>>>>>>> particularly to address an issue with ARM CPUs.  However, an issue
>>>>>>> has
>>>>>>> appeared that affects builds using floats but compiled for 64-bit
>>>>>>> CPUs.  It looks like the size used for floats are still 32 bits (4
>>>>>>> bytes), as expected, but when used in a struct, it gets allocated as
>>>>>>> a
>>>>>>> size of 64 bits (8 bytes) to match the word size of the 64-bit CPU.
>>>>>>> This has gone undetected up until now as we had not been using float
>>>>>>> builds on 64-bit CPUs, but this is the case for iOS and arm64 CPUs
>>>>>>> (i.e., recent iPads and iPhones).  From what I can gather, the
>>>>>>> existing code works fine for floats and doubles on 32-bit CPUs, and
>>>>>>> doubles on 64-bit CPUs, regardless of padding.
>>>>>>> 
>>>>>>> I've updated the memory offset calculation to take into account the
>>>>>>> word size and that now seems correct.  However, the test CSD is still
>>>>>>> causing problems, which leads me to think that code calculating sizes
>>>>>>> for variable memory and pointer assignment needs review.  I suspect
>>>>>>> we
>>>>>>> may need to do extra padding to the size of MYFLT which should
>>>>>>> hopefully fix the issue.  I'm out of time for tonight, but hope to
>>>>>>> get
>>>>>>> this sorted out tomorrow. Once a fix is found, I will do testing on
>>>>>>> platforms I can test on, but will need others to test more broadly
>>>>>>> across CPU types and platforms. I will report back here once a fix is
>>>>>>> found.
>>>>>>> 
>>>>>>> Thanks!

All tests passing on x86_64.
========================
Dr Victor Lazzarini
Dean of Arts, Celtic Studies and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 12 Apr 2016, at 06:43, Victor Lazzarini  wrote:
> 
> I will try.
> 
> Victor Lazzarini
> Dean of Arts, Celtic Studies, and Philosophy
> Maynooth University
> Ireland
> 
>> On 12 Apr 2016, at 02:55, Steven Yi  wrote:
>> 
>> Update: I'm looking into the UDO issue and it's a bit strange. I'm
>> consistently getting problems when running "make csdtests" from the
>> commandline where I have to use ctrl-\ to send a SIGQUIT for 8 of the
>> tests.  They all have to do with UDO's with more complex data types
>> (i.e., fsigs, arrays).  Now, when I run test_fsig_udo.csd from the
>> commandline, it runs fine.  Running test_karrays_udo.csd gives a
>> segfault.  When I run these from XCode, they run without problems.
>> (!!!)
>> 
>> From the commandline with lldb, I get:
>> 
>> Process 38495 launched: './csound' (x86_64)
>> 0dBFS level = 32768.0
>> Csound version 6.07 (float samples) Apr 11 2016
>> libsndfile-1.0.25
>> Reading options from $HOME/.csound6rc
>> csound->FileOpen2 failed:: No such file or directory
>> UnifiedCSD:  ../tests/commandline/test_karrays_udo.csd
>> STARTING FILE
>> Creating options
>> Creating orchestra
>> Creating score
>> Elapsed time at end of orchestra compile: real: 0.002s, CPU: 0.002s
>> sorting score ...
>> ... done
>> Elapsed time at end of score sort: real: 0.002s, CPU: 0.002s
>> --Csound version 6.07 (float samples) Apr 11 2016
>> displays suppressed
>> 0dBFS level = 32768.0
>> orch now loaded
>> audio buffered in 1024 sample-frame blocks
>> unknown rtaudio module: 'pa_bl', using dummy module
>> rtaudio: dummy module enabled
>> writing 1024 sample blks of 32-bit floats to dac
>> SECTION 1:
>> new alloc for instr 1:
>> 
>> Process 38495 stopped
>> * thread #1: tid = 0x2c0f3, 0x0000000100026cf5 CsoundLib`mfree + 85,
>> queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
>> (code=EXC_I386_GPFLT)
>>   frame #0: 0x0000000100026cf5 CsoundLib`mfree + 85
>> CsoundLib`mfree:
>> ->  0x100026cf5 <+85>: movq   (%rax), %rax
>>   0x100026cf8 <+88>: movq   %rax, -0x20(%rbp)
>>   0x100026cfc <+92>: movq   -0x18(%rbp), %rax
>>   0x100026d00 <+96>: movq   0x8(%rax), %rax
>> 
>> (lldb) bt
>> 
>> * thread #1: tid = 0x2c0f3, 0x0000000100026cf5 CsoundLib`mfree + 85,
>> queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
>> (code=EXC_I386_GPFLT)
>> 
>> * frame #0: 0x0000000100026cf5 CsoundLib`mfree + 85
>>   frame #1: 0x000000010003d2e0 CsoundLib`array_copy_value + 400
>>   frame #2: 0x0000000100022f80 CsoundLib`xinset + 224
>>   frame #3: 0x00000001000212f4 CsoundLib`useropcdset + 2180
>>   frame #4: 0x000000010001d1bd CsoundLib`insert + 3293
>>   frame #5: 0x000000010002d6b2 CsoundLib`process_score_event + 2114
>>   frame #6: 0x000000010002bf16 CsoundLib`sensevents + 966
>>   frame #7: 0x00000001001869af CsoundLib`csoundPerform + 223
>>   frame #8: 0x0000000100001a9b csound`main + 731
>>   frame #9: 0x00000001000017b4 csound`start + 52
>> 
>> I'm not quit sure what is going on yet.
>> 
>> Victor: Could you by chance run the csdtests on your computer with a
>> float build for 64-bit cpu and see if the same problems manifest?
>> 
>>> On Mon, Apr 11, 2016 at 11:34 AM, Steven Yi  wrote:
>>> Thanks Victor for the feedback! I suspect the UDO issue I was seeing was
>>> also related to padding, but I will have to investigate further when I'm
>>> back on my computer later today. For now though, it seems like there are no
>>> regressions (fingers crossed!) and at least a partial fix.
>>> 
>>> 
>>> On Mon, Apr 11, 2016, 10:18 AM Victor Lazzarini 
>>> wrote:
>>>> 
>>>> Tried here and it seems to fix the offending CSD (from Dr B’s project).
>>>> ========================
>>>> Dr Victor Lazzarini
>>>> Dean of Arts, Celtic Studies and Philosophy,
>>>> Maynooth University,
>>>> Maynooth, Co Kildare, Ireland
>>>> Tel: 00 353 7086936
>>>> Fax: 00 353 1 7086952
>>>> 
>>>>> On 11 Apr 2016, at 14:36, Steven Yi  wrote:
>>>>> 
>>>>> I've pushed a fix to Git that I think fixes the issue.  At least, I'm
>>>>> now getting the test CSD to work with float builds for 64-bit CPU, and
>>>>> C and csdtests are passing with doubles builds and 64-bit CPU. For
>>>>> float and 64-bit, my setup is not building the C tests, and the
>>>>> csdtests are currently hanging on test_fsig_udo.csd which tests
>>>>> copying of fsigs for UDOs.  Killing that process continues on with
>>>>> further hangs on other CSDs.  I have to leave shortly but will plan to
>>>>> continue looking at this in the afternoon here.
>>>>> 
>>>>>> On Mon, Apr 11, 2016 at 9:15 AM, Steven Yi  wrote:
>>>>>> I have not tried anything for arm64 as I do not have a device with
>>>>>> that CPU at this time.  I reproduced and tested on x86_64 with floats
>>>>>> build.
>>>>>> 
>>>>>> On Mon, Apr 11, 2016 at 1:30 AM, Victor Lazzarini
>>>>>>  wrote:
>>>>>>> Did you try changing the build on arm64 to doubles?
>>>>>>> 
>>>>>>> Victor Lazzarini
>>>>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>>>>> Maynooth University
>>>>>>> Ireland
>>>>>>> 
>>>>>>>> On 11 Apr 2016, at 04:06, Steven Yi  wrote:
>>>>>>>> 
>>>>>>>> Hi All,
>>>>>>>> 
>>>>>>>> Just a heads up, I'm currently looking into a tricky problem that has
>>>>>>>> surfaced for runtime-type identification code and word sizing /
>>>>>>>> structure padding.  The current code was written in the way it is now
>>>>>>>> to deal with differences in structure padding for various systems,
>>>>>>>> particularly to address an issue with ARM CPUs.  However, an issue
>>>>>>>> has
>>>>>>>> appeared that affects builds using floats but compiled for 64-bit
>>>>>>>> CPUs.  It looks like the size used for floats are still 32 bits (4
>>>>>>>> bytes), as expected, but when used in a struct, it gets allocated as
>>>>>>>> a
>>>>>>>> size of 64 bits (8 bytes) to match the word size of the 64-bit CPU.
>>>>>>>> This has gone undetected up until now as we had not been using float
>>>>>>>> builds on 64-bit CPUs, but this is the case for iOS and arm64 CPUs
>>>>>>>> (i.e., recent iPads and iPhones).  From what I can gather, the
>>>>>>>> existing code works fine for floats and doubles on 32-bit CPUs, and
>>>>>>>> doubles on 64-bit CPUs, regardless of padding.
>>>>>>>> 
>>>>>>>> I've updated the memory offset calculation to take into account the
>>>>>>>> word size and that now seems correct.  However, the test CSD is still
>>>>>>>> causing problems, which leads me to think that code calculating sizes
>>>>>>>> for variable memory and pointer assignment needs review.  I suspect
>>>>>>>> we
>>>>>>>> may need to do extra padding to the size of MYFLT which should
>>>>>>>> hopefully fix the issue.  I'm out of time for tonight, but hope to
>>>>>>>> get
>>>>>>>> this sorted out tomorrow. Once a fix is found, I will do testing on
>>>>>>>> platforms I can test on, but will need others to test more broadly
>>>>>>>> across CPU types and platforms. I will report back here once a fix is
>>>>>>>> found.
>>>>>>>> 
>>>>>>>> Thanks!

Sorry I realise now you wanted to test floats on x86_64. No, 7 of them are failing. Most of these failures are
segfaults which hang execution (I had to kill the process with -9).

They are passing only in the doubles build.
========================
Dr Victor Lazzarini
Dean of Arts, Celtic Studies and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 12 Apr 2016, at 08:20, Victor Lazzarini  wrote:
> 
> All tests passing on x86_64.
> ========================
> Dr Victor Lazzarini
> Dean of Arts, Celtic Studies and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952 
> 
>> On 12 Apr 2016, at 06:43, Victor Lazzarini  wrote:
>> 
>> I will try.
>> 
>> Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy
>> Maynooth University
>> Ireland
>> 
>>> On 12 Apr 2016, at 02:55, Steven Yi  wrote:
>>> 
>>> Update: I'm looking into the UDO issue and it's a bit strange. I'm
>>> consistently getting problems when running "make csdtests" from the
>>> commandline where I have to use ctrl-\ to send a SIGQUIT for 8 of the
>>> tests.  They all have to do with UDO's with more complex data types
>>> (i.e., fsigs, arrays).  Now, when I run test_fsig_udo.csd from the
>>> commandline, it runs fine.  Running test_karrays_udo.csd gives a
>>> segfault.  When I run these from XCode, they run without problems.
>>> (!!!)
>>> 
>>> From the commandline with lldb, I get:
>>> 
>>> Process 38495 launched: './csound' (x86_64)
>>> 0dBFS level = 32768.0
>>> Csound version 6.07 (float samples) Apr 11 2016
>>> libsndfile-1.0.25
>>> Reading options from $HOME/.csound6rc
>>> csound->FileOpen2 failed:: No such file or directory
>>> UnifiedCSD:  ../tests/commandline/test_karrays_udo.csd
>>> STARTING FILE
>>> Creating options
>>> Creating orchestra
>>> Creating score
>>> Elapsed time at end of orchestra compile: real: 0.002s, CPU: 0.002s
>>> sorting score ...
>>> ... done
>>> Elapsed time at end of score sort: real: 0.002s, CPU: 0.002s
>>> --Csound version 6.07 (float samples) Apr 11 2016
>>> displays suppressed
>>> 0dBFS level = 32768.0
>>> orch now loaded
>>> audio buffered in 1024 sample-frame blocks
>>> unknown rtaudio module: 'pa_bl', using dummy module
>>> rtaudio: dummy module enabled
>>> writing 1024 sample blks of 32-bit floats to dac
>>> SECTION 1:
>>> new alloc for instr 1:
>>> 
>>> Process 38495 stopped
>>> * thread #1: tid = 0x2c0f3, 0x0000000100026cf5 CsoundLib`mfree + 85,
>>> queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
>>> (code=EXC_I386_GPFLT)
>>>  frame #0: 0x0000000100026cf5 CsoundLib`mfree + 85
>>> CsoundLib`mfree:
>>> ->  0x100026cf5 <+85>: movq   (%rax), %rax
>>>  0x100026cf8 <+88>: movq   %rax, -0x20(%rbp)
>>>  0x100026cfc <+92>: movq   -0x18(%rbp), %rax
>>>  0x100026d00 <+96>: movq   0x8(%rax), %rax
>>> 
>>> (lldb) bt
>>> 
>>> * thread #1: tid = 0x2c0f3, 0x0000000100026cf5 CsoundLib`mfree + 85,
>>> queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
>>> (code=EXC_I386_GPFLT)
>>> 
>>> * frame #0: 0x0000000100026cf5 CsoundLib`mfree + 85
>>>  frame #1: 0x000000010003d2e0 CsoundLib`array_copy_value + 400
>>>  frame #2: 0x0000000100022f80 CsoundLib`xinset + 224
>>>  frame #3: 0x00000001000212f4 CsoundLib`useropcdset + 2180
>>>  frame #4: 0x000000010001d1bd CsoundLib`insert + 3293
>>>  frame #5: 0x000000010002d6b2 CsoundLib`process_score_event + 2114
>>>  frame #6: 0x000000010002bf16 CsoundLib`sensevents + 966
>>>  frame #7: 0x00000001001869af CsoundLib`csoundPerform + 223
>>>  frame #8: 0x0000000100001a9b csound`main + 731
>>>  frame #9: 0x00000001000017b4 csound`start + 52
>>> 
>>> I'm not quit sure what is going on yet.
>>> 
>>> Victor: Could you by chance run the csdtests on your computer with a
>>> float build for 64-bit cpu and see if the same problems manifest?
>>> 
>>>> On Mon, Apr 11, 2016 at 11:34 AM, Steven Yi  wrote:
>>>> Thanks Victor for the feedback! I suspect the UDO issue I was seeing was
>>>> also related to padding, but I will have to investigate further when I'm
>>>> back on my computer later today. For now though, it seems like there are no
>>>> regressions (fingers crossed!) and at least a partial fix.
>>>> 
>>>> 
>>>> On Mon, Apr 11, 2016, 10:18 AM Victor Lazzarini 
>>>> wrote:
>>>>> 
>>>>> Tried here and it seems to fix the offending CSD (from Dr B’s project).
>>>>> ========================
>>>>> Dr Victor Lazzarini
>>>>> Dean of Arts, Celtic Studies and Philosophy,
>>>>> Maynooth University,
>>>>> Maynooth, Co Kildare, Ireland
>>>>> Tel: 00 353 7086936
>>>>> Fax: 00 353 1 7086952
>>>>> 
>>>>>> On 11 Apr 2016, at 14:36, Steven Yi  wrote:
>>>>>> 
>>>>>> I've pushed a fix to Git that I think fixes the issue.  At least, I'm
>>>>>> now getting the test CSD to work with float builds for 64-bit CPU, and
>>>>>> C and csdtests are passing with doubles builds and 64-bit CPU. For
>>>>>> float and 64-bit, my setup is not building the C tests, and the
>>>>>> csdtests are currently hanging on test_fsig_udo.csd which tests
>>>>>> copying of fsigs for UDOs.  Killing that process continues on with
>>>>>> further hangs on other CSDs.  I have to leave shortly but will plan to
>>>>>> continue looking at this in the afternoon here.
>>>>>> 
>>>>>>> On Mon, Apr 11, 2016 at 9:15 AM, Steven Yi  wrote:
>>>>>>> I have not tried anything for arm64 as I do not have a device with
>>>>>>> that CPU at this time.  I reproduced and tested on x86_64 with floats
>>>>>>> build.
>>>>>>> 
>>>>>>> On Mon, Apr 11, 2016 at 1:30 AM, Victor Lazzarini
>>>>>>>  wrote:
>>>>>>>> Did you try changing the build on arm64 to doubles?
>>>>>>>> 
>>>>>>>> Victor Lazzarini
>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>>>>>> Maynooth University
>>>>>>>> Ireland
>>>>>>>> 
>>>>>>>>> On 11 Apr 2016, at 04:06, Steven Yi  wrote:
>>>>>>>>> 
>>>>>>>>> Hi All,
>>>>>>>>> 
>>>>>>>>> Just a heads up, I'm currently looking into a tricky problem that has
>>>>>>>>> surfaced for runtime-type identification code and word sizing /
>>>>>>>>> structure padding.  The current code was written in the way it is now
>>>>>>>>> to deal with differences in structure padding for various systems,
>>>>>>>>> particularly to address an issue with ARM CPUs.  However, an issue
>>>>>>>>> has
>>>>>>>>> appeared that affects builds using floats but compiled for 64-bit
>>>>>>>>> CPUs.  It looks like the size used for floats are still 32 bits (4
>>>>>>>>> bytes), as expected, but when used in a struct, it gets allocated as
>>>>>>>>> a
>>>>>>>>> size of 64 bits (8 bytes) to match the word size of the 64-bit CPU.
>>>>>>>>> This has gone undetected up until now as we had not been using float
>>>>>>>>> builds on 64-bit CPUs, but this is the case for iOS and arm64 CPUs
>>>>>>>>> (i.e., recent iPads and iPhones).  From what I can gather, the
>>>>>>>>> existing code works fine for floats and doubles on 32-bit CPUs, and
>>>>>>>>> doubles on 64-bit CPUs, regardless of padding.
>>>>>>>>> 
>>>>>>>>> I've updated the memory offset calculation to take into account the
>>>>>>>>> word size and that now seems correct.  However, the test CSD is still
>>>>>>>>> causing problems, which leads me to think that code calculating sizes
>>>>>>>>> for variable memory and pointer assignment needs review.  I suspect
>>>>>>>>> we
>>>>>>>>> may need to do extra padding to the size of MYFLT which should
>>>>>>>>> hopefully fix the issue.  I'm out of time for tonight, but hope to
>>>>>>>>> get
>>>>>>>>> this sorted out tomorrow. Once a fix is found, I will do testing on
>>>>>>>>> platforms I can test on, but will need others to test more broadly
>>>>>>>>> across CPU types and platforms. I will report back here once a fix is
>>>>>>>>> found.
>>>>>>>>> 
>>>>>>>>> Thanks!

Thanks for that Victor. I realized just now that I had switched to a
32-bit CPU build yesterday in XCode and forgot to switch back to
64-bit CPU, which explains the discrepancy between the XCode and
command-line builds. I can reproduce the error now in XCode and am
investigating the problem now.

On Tue, Apr 12, 2016 at 3:24 AM, Victor Lazzarini
 wrote:
> Sorry I realise now you wanted to test floats on x86_64. No, 7 of them are failing. Most of these failures are
> segfaults which hang execution (I had to kill the process with -9).
>
> They are passing only in the doubles build.
> ========================
> Dr Victor Lazzarini
> Dean of Arts, Celtic Studies and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952
>
>> On 12 Apr 2016, at 08:20, Victor Lazzarini  wrote:
>>
>> All tests passing on x86_64.
>> ========================
>> Dr Victor Lazzarini
>> Dean of Arts, Celtic Studies and Philosophy,
>> Maynooth University,
>> Maynooth, Co Kildare, Ireland
>> Tel: 00 353 7086936
>> Fax: 00 353 1 7086952
>>
>>> On 12 Apr 2016, at 06:43, Victor Lazzarini  wrote:
>>>
>>> I will try.
>>>
>>> Victor Lazzarini
>>> Dean of Arts, Celtic Studies, and Philosophy
>>> Maynooth University
>>> Ireland
>>>
>>>> On 12 Apr 2016, at 02:55, Steven Yi  wrote:
>>>>
>>>> Update: I'm looking into the UDO issue and it's a bit strange. I'm
>>>> consistently getting problems when running "make csdtests" from the
>>>> commandline where I have to use ctrl-\ to send a SIGQUIT for 8 of the
>>>> tests.  They all have to do with UDO's with more complex data types
>>>> (i.e., fsigs, arrays).  Now, when I run test_fsig_udo.csd from the
>>>> commandline, it runs fine.  Running test_karrays_udo.csd gives a
>>>> segfault.  When I run these from XCode, they run without problems.
>>>> (!!!)
>>>>
>>>> From the commandline with lldb, I get:
>>>>
>>>> Process 38495 launched: './csound' (x86_64)
>>>> 0dBFS level = 32768.0
>>>> Csound version 6.07 (float samples) Apr 11 2016
>>>> libsndfile-1.0.25
>>>> Reading options from $HOME/.csound6rc
>>>> csound->FileOpen2 failed:: No such file or directory
>>>> UnifiedCSD:  ../tests/commandline/test_karrays_udo.csd
>>>> STARTING FILE
>>>> Creating options
>>>> Creating orchestra
>>>> Creating score
>>>> Elapsed time at end of orchestra compile: real: 0.002s, CPU: 0.002s
>>>> sorting score ...
>>>> ... done
>>>> Elapsed time at end of score sort: real: 0.002s, CPU: 0.002s
>>>> --Csound version 6.07 (float samples) Apr 11 2016
>>>> displays suppressed
>>>> 0dBFS level = 32768.0
>>>> orch now loaded
>>>> audio buffered in 1024 sample-frame blocks
>>>> unknown rtaudio module: 'pa_bl', using dummy module
>>>> rtaudio: dummy module enabled
>>>> writing 1024 sample blks of 32-bit floats to dac
>>>> SECTION 1:
>>>> new alloc for instr 1:
>>>>
>>>> Process 38495 stopped
>>>> * thread #1: tid = 0x2c0f3, 0x0000000100026cf5 CsoundLib`mfree + 85,
>>>> queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
>>>> (code=EXC_I386_GPFLT)
>>>>  frame #0: 0x0000000100026cf5 CsoundLib`mfree + 85
>>>> CsoundLib`mfree:
>>>> ->  0x100026cf5 <+85>: movq   (%rax), %rax
>>>>  0x100026cf8 <+88>: movq   %rax, -0x20(%rbp)
>>>>  0x100026cfc <+92>: movq   -0x18(%rbp), %rax
>>>>  0x100026d00 <+96>: movq   0x8(%rax), %rax
>>>>
>>>> (lldb) bt
>>>>
>>>> * thread #1: tid = 0x2c0f3, 0x0000000100026cf5 CsoundLib`mfree + 85,
>>>> queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
>>>> (code=EXC_I386_GPFLT)
>>>>
>>>> * frame #0: 0x0000000100026cf5 CsoundLib`mfree + 85
>>>>  frame #1: 0x000000010003d2e0 CsoundLib`array_copy_value + 400
>>>>  frame #2: 0x0000000100022f80 CsoundLib`xinset + 224
>>>>  frame #3: 0x00000001000212f4 CsoundLib`useropcdset + 2180
>>>>  frame #4: 0x000000010001d1bd CsoundLib`insert + 3293
>>>>  frame #5: 0x000000010002d6b2 CsoundLib`process_score_event + 2114
>>>>  frame #6: 0x000000010002bf16 CsoundLib`sensevents + 966
>>>>  frame #7: 0x00000001001869af CsoundLib`csoundPerform + 223
>>>>  frame #8: 0x0000000100001a9b csound`main + 731
>>>>  frame #9: 0x00000001000017b4 csound`start + 52
>>>>
>>>> I'm not quit sure what is going on yet.
>>>>
>>>> Victor: Could you by chance run the csdtests on your computer with a
>>>> float build for 64-bit cpu and see if the same problems manifest?
>>>>
>>>>> On Mon, Apr 11, 2016 at 11:34 AM, Steven Yi  wrote:
>>>>> Thanks Victor for the feedback! I suspect the UDO issue I was seeing was
>>>>> also related to padding, but I will have to investigate further when I'm
>>>>> back on my computer later today. For now though, it seems like there are no
>>>>> regressions (fingers crossed!) and at least a partial fix.
>>>>>
>>>>>
>>>>> On Mon, Apr 11, 2016, 10:18 AM Victor Lazzarini 
>>>>> wrote:
>>>>>>
>>>>>> Tried here and it seems to fix the offending CSD (from Dr B’s project).
>>>>>> ========================
>>>>>> Dr Victor Lazzarini
>>>>>> Dean of Arts, Celtic Studies and Philosophy,
>>>>>> Maynooth University,
>>>>>> Maynooth, Co Kildare, Ireland
>>>>>> Tel: 00 353 7086936
>>>>>> Fax: 00 353 1 7086952
>>>>>>
>>>>>>> On 11 Apr 2016, at 14:36, Steven Yi  wrote:
>>>>>>>
>>>>>>> I've pushed a fix to Git that I think fixes the issue.  At least, I'm
>>>>>>> now getting the test CSD to work with float builds for 64-bit CPU, and
>>>>>>> C and csdtests are passing with doubles builds and 64-bit CPU. For
>>>>>>> float and 64-bit, my setup is not building the C tests, and the
>>>>>>> csdtests are currently hanging on test_fsig_udo.csd which tests
>>>>>>> copying of fsigs for UDOs.  Killing that process continues on with
>>>>>>> further hangs on other CSDs.  I have to leave shortly but will plan to
>>>>>>> continue looking at this in the afternoon here.
>>>>>>>
>>>>>>>> On Mon, Apr 11, 2016 at 9:15 AM, Steven Yi  wrote:
>>>>>>>> I have not tried anything for arm64 as I do not have a device with
>>>>>>>> that CPU at this time.  I reproduced and tested on x86_64 with floats
>>>>>>>> build.
>>>>>>>>
>>>>>>>> On Mon, Apr 11, 2016 at 1:30 AM, Victor Lazzarini
>>>>>>>>  wrote:
>>>>>>>>> Did you try changing the build on arm64 to doubles?
>>>>>>>>>
>>>>>>>>> Victor Lazzarini
>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>>>>>>> Maynooth University
>>>>>>>>> Ireland
>>>>>>>>>
>>>>>>>>>> On 11 Apr 2016, at 04:06, Steven Yi  wrote:
>>>>>>>>>>
>>>>>>>>>> Hi All,
>>>>>>>>>>
>>>>>>>>>> Just a heads up, I'm currently looking into a tricky problem that has
>>>>>>>>>> surfaced for runtime-type identification code and word sizing /
>>>>>>>>>> structure padding.  The current code was written in the way it is now
>>>>>>>>>> to deal with differences in structure padding for various systems,
>>>>>>>>>> particularly to address an issue with ARM CPUs.  However, an issue
>>>>>>>>>> has
>>>>>>>>>> appeared that affects builds using floats but compiled for 64-bit
>>>>>>>>>> CPUs.  It looks like the size used for floats are still 32 bits (4
>>>>>>>>>> bytes), as expected, but when used in a struct, it gets allocated as
>>>>>>>>>> a
>>>>>>>>>> size of 64 bits (8 bytes) to match the word size of the 64-bit CPU.
>>>>>>>>>> This has gone undetected up until now as we had not been using float
>>>>>>>>>> builds on 64-bit CPUs, but this is the case for iOS and arm64 CPUs
>>>>>>>>>> (i.e., recent iPads and iPhones).  From what I can gather, the
>>>>>>>>>> existing code works fine for floats and doubles on 32-bit CPUs, and
>>>>>>>>>> doubles on 64-bit CPUs, regardless of padding.
>>>>>>>>>>
>>>>>>>>>> I've updated the memory offset calculation to take into account the
>>>>>>>>>> word size and that now seems correct.  However, the test CSD is still
>>>>>>>>>> causing problems, which leads me to think that code calculating sizes
>>>>>>>>>> for variable memory and pointer assignment needs review.  I suspect
>>>>>>>>>> we
>>>>>>>>>> may need to do extra padding to the size of MYFLT which should
>>>>>>>>>> hopefully fix the issue.  I'm out of time for tonight, but hope to
>>>>>>>>>> get
>>>>>>>>>> this sorted out tomorrow. Once a fix is found, I will do testing on
>>>>>>>>>> platforms I can test on, but will need others to test more broadly
>>>>>>>>>> across CPU types and platforms. I will report back here once a fix is
>>>>>>>>>> found.
>>>>>>>>>>
>>>>>>>>>> Thanks!

Just FYI, the issue is quite hairy, to say the least. There seems to
be a number of offset and index calculations for the instrument
instance memory that are affected.  It's taking a while to remember
what some of this code meant, so I suspect it will be end of day at
the earliest for a fix.

On Tue, Apr 12, 2016 at 5:13 AM, Steven Yi  wrote:
> Thanks for that Victor. I realized just now that I had switched to a
> 32-bit CPU build yesterday in XCode and forgot to switch back to
> 64-bit CPU, which explains the discrepancy between the XCode and
> command-line builds. I can reproduce the error now in XCode and am
> investigating the problem now.
>
> On Tue, Apr 12, 2016 at 3:24 AM, Victor Lazzarini
>  wrote:
>> Sorry I realise now you wanted to test floats on x86_64. No, 7 of them are failing. Most of these failures are
>> segfaults which hang execution (I had to kill the process with -9).
>>
>> They are passing only in the doubles build.
>> ========================
>> Dr Victor Lazzarini
>> Dean of Arts, Celtic Studies and Philosophy,
>> Maynooth University,
>> Maynooth, Co Kildare, Ireland
>> Tel: 00 353 7086936
>> Fax: 00 353 1 7086952
>>
>>> On 12 Apr 2016, at 08:20, Victor Lazzarini  wrote:
>>>
>>> All tests passing on x86_64.
>>> ========================
>>> Dr Victor Lazzarini
>>> Dean of Arts, Celtic Studies and Philosophy,
>>> Maynooth University,
>>> Maynooth, Co Kildare, Ireland
>>> Tel: 00 353 7086936
>>> Fax: 00 353 1 7086952
>>>
>>>> On 12 Apr 2016, at 06:43, Victor Lazzarini  wrote:
>>>>
>>>> I will try.
>>>>
>>>> Victor Lazzarini
>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>> Maynooth University
>>>> Ireland
>>>>
>>>>> On 12 Apr 2016, at 02:55, Steven Yi  wrote:
>>>>>
>>>>> Update: I'm looking into the UDO issue and it's a bit strange. I'm
>>>>> consistently getting problems when running "make csdtests" from the
>>>>> commandline where I have to use ctrl-\ to send a SIGQUIT for 8 of the
>>>>> tests.  They all have to do with UDO's with more complex data types
>>>>> (i.e., fsigs, arrays).  Now, when I run test_fsig_udo.csd from the
>>>>> commandline, it runs fine.  Running test_karrays_udo.csd gives a
>>>>> segfault.  When I run these from XCode, they run without problems.
>>>>> (!!!)
>>>>>
>>>>> From the commandline with lldb, I get:
>>>>>
>>>>> Process 38495 launched: './csound' (x86_64)
>>>>> 0dBFS level = 32768.0
>>>>> Csound version 6.07 (float samples) Apr 11 2016
>>>>> libsndfile-1.0.25
>>>>> Reading options from $HOME/.csound6rc
>>>>> csound->FileOpen2 failed:: No such file or directory
>>>>> UnifiedCSD:  ../tests/commandline/test_karrays_udo.csd
>>>>> STARTING FILE
>>>>> Creating options
>>>>> Creating orchestra
>>>>> Creating score
>>>>> Elapsed time at end of orchestra compile: real: 0.002s, CPU: 0.002s
>>>>> sorting score ...
>>>>> ... done
>>>>> Elapsed time at end of score sort: real: 0.002s, CPU: 0.002s
>>>>> --Csound version 6.07 (float samples) Apr 11 2016
>>>>> displays suppressed
>>>>> 0dBFS level = 32768.0
>>>>> orch now loaded
>>>>> audio buffered in 1024 sample-frame blocks
>>>>> unknown rtaudio module: 'pa_bl', using dummy module
>>>>> rtaudio: dummy module enabled
>>>>> writing 1024 sample blks of 32-bit floats to dac
>>>>> SECTION 1:
>>>>> new alloc for instr 1:
>>>>>
>>>>> Process 38495 stopped
>>>>> * thread #1: tid = 0x2c0f3, 0x0000000100026cf5 CsoundLib`mfree + 85,
>>>>> queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
>>>>> (code=EXC_I386_GPFLT)
>>>>>  frame #0: 0x0000000100026cf5 CsoundLib`mfree + 85
>>>>> CsoundLib`mfree:
>>>>> ->  0x100026cf5 <+85>: movq   (%rax), %rax
>>>>>  0x100026cf8 <+88>: movq   %rax, -0x20(%rbp)
>>>>>  0x100026cfc <+92>: movq   -0x18(%rbp), %rax
>>>>>  0x100026d00 <+96>: movq   0x8(%rax), %rax
>>>>>
>>>>> (lldb) bt
>>>>>
>>>>> * thread #1: tid = 0x2c0f3, 0x0000000100026cf5 CsoundLib`mfree + 85,
>>>>> queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
>>>>> (code=EXC_I386_GPFLT)
>>>>>
>>>>> * frame #0: 0x0000000100026cf5 CsoundLib`mfree + 85
>>>>>  frame #1: 0x000000010003d2e0 CsoundLib`array_copy_value + 400
>>>>>  frame #2: 0x0000000100022f80 CsoundLib`xinset + 224
>>>>>  frame #3: 0x00000001000212f4 CsoundLib`useropcdset + 2180
>>>>>  frame #4: 0x000000010001d1bd CsoundLib`insert + 3293
>>>>>  frame #5: 0x000000010002d6b2 CsoundLib`process_score_event + 2114
>>>>>  frame #6: 0x000000010002bf16 CsoundLib`sensevents + 966
>>>>>  frame #7: 0x00000001001869af CsoundLib`csoundPerform + 223
>>>>>  frame #8: 0x0000000100001a9b csound`main + 731
>>>>>  frame #9: 0x00000001000017b4 csound`start + 52
>>>>>
>>>>> I'm not quit sure what is going on yet.
>>>>>
>>>>> Victor: Could you by chance run the csdtests on your computer with a
>>>>> float build for 64-bit cpu and see if the same problems manifest?
>>>>>
>>>>>> On Mon, Apr 11, 2016 at 11:34 AM, Steven Yi  wrote:
>>>>>> Thanks Victor for the feedback! I suspect the UDO issue I was seeing was
>>>>>> also related to padding, but I will have to investigate further when I'm
>>>>>> back on my computer later today. For now though, it seems like there are no
>>>>>> regressions (fingers crossed!) and at least a partial fix.
>>>>>>
>>>>>>
>>>>>> On Mon, Apr 11, 2016, 10:18 AM Victor Lazzarini 
>>>>>> wrote:
>>>>>>>
>>>>>>> Tried here and it seems to fix the offending CSD (from Dr B’s project).
>>>>>>> ========================
>>>>>>> Dr Victor Lazzarini
>>>>>>> Dean of Arts, Celtic Studies and Philosophy,
>>>>>>> Maynooth University,
>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>> Tel: 00 353 7086936
>>>>>>> Fax: 00 353 1 7086952
>>>>>>>
>>>>>>>> On 11 Apr 2016, at 14:36, Steven Yi  wrote:
>>>>>>>>
>>>>>>>> I've pushed a fix to Git that I think fixes the issue.  At least, I'm
>>>>>>>> now getting the test CSD to work with float builds for 64-bit CPU, and
>>>>>>>> C and csdtests are passing with doubles builds and 64-bit CPU. For
>>>>>>>> float and 64-bit, my setup is not building the C tests, and the
>>>>>>>> csdtests are currently hanging on test_fsig_udo.csd which tests
>>>>>>>> copying of fsigs for UDOs.  Killing that process continues on with
>>>>>>>> further hangs on other CSDs.  I have to leave shortly but will plan to
>>>>>>>> continue looking at this in the afternoon here.
>>>>>>>>
>>>>>>>>> On Mon, Apr 11, 2016 at 9:15 AM, Steven Yi  wrote:
>>>>>>>>> I have not tried anything for arm64 as I do not have a device with
>>>>>>>>> that CPU at this time.  I reproduced and tested on x86_64 with floats
>>>>>>>>> build.
>>>>>>>>>
>>>>>>>>> On Mon, Apr 11, 2016 at 1:30 AM, Victor Lazzarini
>>>>>>>>>  wrote:
>>>>>>>>>> Did you try changing the build on arm64 to doubles?
>>>>>>>>>>
>>>>>>>>>> Victor Lazzarini
>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>>>>>>>> Maynooth University
>>>>>>>>>> Ireland
>>>>>>>>>>
>>>>>>>>>>> On 11 Apr 2016, at 04:06, Steven Yi  wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi All,
>>>>>>>>>>>
>>>>>>>>>>> Just a heads up, I'm currently looking into a tricky problem that has
>>>>>>>>>>> surfaced for runtime-type identification code and word sizing /
>>>>>>>>>>> structure padding.  The current code was written in the way it is now
>>>>>>>>>>> to deal with differences in structure padding for various systems,
>>>>>>>>>>> particularly to address an issue with ARM CPUs.  However, an issue
>>>>>>>>>>> has
>>>>>>>>>>> appeared that affects builds using floats but compiled for 64-bit
>>>>>>>>>>> CPUs.  It looks like the size used for floats are still 32 bits (4
>>>>>>>>>>> bytes), as expected, but when used in a struct, it gets allocated as
>>>>>>>>>>> a
>>>>>>>>>>> size of 64 bits (8 bytes) to match the word size of the 64-bit CPU.
>>>>>>>>>>> This has gone undetected up until now as we had not been using float
>>>>>>>>>>> builds on 64-bit CPUs, but this is the case for iOS and arm64 CPUs
>>>>>>>>>>> (i.e., recent iPads and iPhones).  From what I can gather, the
>>>>>>>>>>> existing code works fine for floats and doubles on 32-bit CPUs, and
>>>>>>>>>>> doubles on 64-bit CPUs, regardless of padding.
>>>>>>>>>>>
>>>>>>>>>>> I've updated the memory offset calculation to take into account the
>>>>>>>>>>> word size and that now seems correct.  However, the test CSD is still
>>>>>>>>>>> causing problems, which leads me to think that code calculating sizes
>>>>>>>>>>> for variable memory and pointer assignment needs review.  I suspect
>>>>>>>>>>> we
>>>>>>>>>>> may need to do extra padding to the size of MYFLT which should
>>>>>>>>>>> hopefully fix the issue.  I'm out of time for tonight, but hope to
>>>>>>>>>>> get
>>>>>>>>>>> this sorted out tomorrow. Once a fix is found, I will do testing on
>>>>>>>>>>> platforms I can test on, but will need others to test more broadly
>>>>>>>>>>> across CPU types and platforms. I will report back here once a fix is
>>>>>>>>>>> found.
>>>>>>>>>>>
>>>>>>>>>>> Thanks!

Hi All,

I *think* I've got the memory calculations working now.  At least,
"make csdtests" is passing for both the float and doubles builds on
64-bit CPU (OSX).  I'll try to testing on other platforms, but will
assume things are okay now. If you try this out and find any issues,
please let me know and I will investigate.

Thanks!
steven

On Tue, Apr 12, 2016 at 6:15 AM, Steven Yi  wrote:
> Just FYI, the issue is quite hairy, to say the least. There seems to
> be a number of offset and index calculations for the instrument
> instance memory that are affected.  It's taking a while to remember
> what some of this code meant, so I suspect it will be end of day at
> the earliest for a fix.
>
> On Tue, Apr 12, 2016 at 5:13 AM, Steven Yi  wrote:
>> Thanks for that Victor. I realized just now that I had switched to a
>> 32-bit CPU build yesterday in XCode and forgot to switch back to
>> 64-bit CPU, which explains the discrepancy between the XCode and
>> command-line builds. I can reproduce the error now in XCode and am
>> investigating the problem now.
>>
>> On Tue, Apr 12, 2016 at 3:24 AM, Victor Lazzarini
>>  wrote:
>>> Sorry I realise now you wanted to test floats on x86_64. No, 7 of them are failing. Most of these failures are
>>> segfaults which hang execution (I had to kill the process with -9).
>>>
>>> They are passing only in the doubles build.
>>> ========================
>>> Dr Victor Lazzarini
>>> Dean of Arts, Celtic Studies and Philosophy,
>>> Maynooth University,
>>> Maynooth, Co Kildare, Ireland
>>> Tel: 00 353 7086936
>>> Fax: 00 353 1 7086952
>>>
>>>> On 12 Apr 2016, at 08:20, Victor Lazzarini  wrote:
>>>>
>>>> All tests passing on x86_64.
>>>> ========================
>>>> Dr Victor Lazzarini
>>>> Dean of Arts, Celtic Studies and Philosophy,
>>>> Maynooth University,
>>>> Maynooth, Co Kildare, Ireland
>>>> Tel: 00 353 7086936
>>>> Fax: 00 353 1 7086952
>>>>
>>>>> On 12 Apr 2016, at 06:43, Victor Lazzarini  wrote:
>>>>>
>>>>> I will try.
>>>>>
>>>>> Victor Lazzarini
>>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>>> Maynooth University
>>>>> Ireland
>>>>>
>>>>>> On 12 Apr 2016, at 02:55, Steven Yi  wrote:
>>>>>>
>>>>>> Update: I'm looking into the UDO issue and it's a bit strange. I'm
>>>>>> consistently getting problems when running "make csdtests" from the
>>>>>> commandline where I have to use ctrl-\ to send a SIGQUIT for 8 of the
>>>>>> tests.  They all have to do with UDO's with more complex data types
>>>>>> (i.e., fsigs, arrays).  Now, when I run test_fsig_udo.csd from the
>>>>>> commandline, it runs fine.  Running test_karrays_udo.csd gives a
>>>>>> segfault.  When I run these from XCode, they run without problems.
>>>>>> (!!!)
>>>>>>
>>>>>> From the commandline with lldb, I get:
>>>>>>
>>>>>> Process 38495 launched: './csound' (x86_64)
>>>>>> 0dBFS level = 32768.0
>>>>>> Csound version 6.07 (float samples) Apr 11 2016
>>>>>> libsndfile-1.0.25
>>>>>> Reading options from $HOME/.csound6rc
>>>>>> csound->FileOpen2 failed:: No such file or directory
>>>>>> UnifiedCSD:  ../tests/commandline/test_karrays_udo.csd
>>>>>> STARTING FILE
>>>>>> Creating options
>>>>>> Creating orchestra
>>>>>> Creating score
>>>>>> Elapsed time at end of orchestra compile: real: 0.002s, CPU: 0.002s
>>>>>> sorting score ...
>>>>>> ... done
>>>>>> Elapsed time at end of score sort: real: 0.002s, CPU: 0.002s
>>>>>> --Csound version 6.07 (float samples) Apr 11 2016
>>>>>> displays suppressed
>>>>>> 0dBFS level = 32768.0
>>>>>> orch now loaded
>>>>>> audio buffered in 1024 sample-frame blocks
>>>>>> unknown rtaudio module: 'pa_bl', using dummy module
>>>>>> rtaudio: dummy module enabled
>>>>>> writing 1024 sample blks of 32-bit floats to dac
>>>>>> SECTION 1:
>>>>>> new alloc for instr 1:
>>>>>>
>>>>>> Process 38495 stopped
>>>>>> * thread #1: tid = 0x2c0f3, 0x0000000100026cf5 CsoundLib`mfree + 85,
>>>>>> queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
>>>>>> (code=EXC_I386_GPFLT)
>>>>>>  frame #0: 0x0000000100026cf5 CsoundLib`mfree + 85
>>>>>> CsoundLib`mfree:
>>>>>> ->  0x100026cf5 <+85>: movq   (%rax), %rax
>>>>>>  0x100026cf8 <+88>: movq   %rax, -0x20(%rbp)
>>>>>>  0x100026cfc <+92>: movq   -0x18(%rbp), %rax
>>>>>>  0x100026d00 <+96>: movq   0x8(%rax), %rax
>>>>>>
>>>>>> (lldb) bt
>>>>>>
>>>>>> * thread #1: tid = 0x2c0f3, 0x0000000100026cf5 CsoundLib`mfree + 85,
>>>>>> queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
>>>>>> (code=EXC_I386_GPFLT)
>>>>>>
>>>>>> * frame #0: 0x0000000100026cf5 CsoundLib`mfree + 85
>>>>>>  frame #1: 0x000000010003d2e0 CsoundLib`array_copy_value + 400
>>>>>>  frame #2: 0x0000000100022f80 CsoundLib`xinset + 224
>>>>>>  frame #3: 0x00000001000212f4 CsoundLib`useropcdset + 2180
>>>>>>  frame #4: 0x000000010001d1bd CsoundLib`insert + 3293
>>>>>>  frame #5: 0x000000010002d6b2 CsoundLib`process_score_event + 2114
>>>>>>  frame #6: 0x000000010002bf16 CsoundLib`sensevents + 966
>>>>>>  frame #7: 0x00000001001869af CsoundLib`csoundPerform + 223
>>>>>>  frame #8: 0x0000000100001a9b csound`main + 731
>>>>>>  frame #9: 0x00000001000017b4 csound`start + 52
>>>>>>
>>>>>> I'm not quit sure what is going on yet.
>>>>>>
>>>>>> Victor: Could you by chance run the csdtests on your computer with a
>>>>>> float build for 64-bit cpu and see if the same problems manifest?
>>>>>>
>>>>>>> On Mon, Apr 11, 2016 at 11:34 AM, Steven Yi  wrote:
>>>>>>> Thanks Victor for the feedback! I suspect the UDO issue I was seeing was
>>>>>>> also related to padding, but I will have to investigate further when I'm
>>>>>>> back on my computer later today. For now though, it seems like there are no
>>>>>>> regressions (fingers crossed!) and at least a partial fix.
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Apr 11, 2016, 10:18 AM Victor Lazzarini 
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Tried here and it seems to fix the offending CSD (from Dr B’s project).
>>>>>>>> ========================
>>>>>>>> Dr Victor Lazzarini
>>>>>>>> Dean of Arts, Celtic Studies and Philosophy,
>>>>>>>> Maynooth University,
>>>>>>>> Maynooth, Co Kildare, Ireland
>>>>>>>> Tel: 00 353 7086936
>>>>>>>> Fax: 00 353 1 7086952
>>>>>>>>
>>>>>>>>> On 11 Apr 2016, at 14:36, Steven Yi  wrote:
>>>>>>>>>
>>>>>>>>> I've pushed a fix to Git that I think fixes the issue.  At least, I'm
>>>>>>>>> now getting the test CSD to work with float builds for 64-bit CPU, and
>>>>>>>>> C and csdtests are passing with doubles builds and 64-bit CPU. For
>>>>>>>>> float and 64-bit, my setup is not building the C tests, and the
>>>>>>>>> csdtests are currently hanging on test_fsig_udo.csd which tests
>>>>>>>>> copying of fsigs for UDOs.  Killing that process continues on with
>>>>>>>>> further hangs on other CSDs.  I have to leave shortly but will plan to
>>>>>>>>> continue looking at this in the afternoon here.
>>>>>>>>>
>>>>>>>>>> On Mon, Apr 11, 2016 at 9:15 AM, Steven Yi  wrote:
>>>>>>>>>> I have not tried anything for arm64 as I do not have a device with
>>>>>>>>>> that CPU at this time.  I reproduced and tested on x86_64 with floats
>>>>>>>>>> build.
>>>>>>>>>>
>>>>>>>>>> On Mon, Apr 11, 2016 at 1:30 AM, Victor Lazzarini
>>>>>>>>>>  wrote:
>>>>>>>>>>> Did you try changing the build on arm64 to doubles?
>>>>>>>>>>>
>>>>>>>>>>> Victor Lazzarini
>>>>>>>>>>> Dean of Arts, Celtic Studies, and Philosophy
>>>>>>>>>>> Maynooth University
>>>>>>>>>>> Ireland
>>>>>>>>>>>
>>>>>>>>>>>> On 11 Apr 2016, at 04:06, Steven Yi  wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>
>>>>>>>>>>>> Just a heads up, I'm currently looking into a tricky problem that has
>>>>>>>>>>>> surfaced for runtime-type identification code and word sizing /
>>>>>>>>>>>> structure padding.  The current code was written in the way it is now
>>>>>>>>>>>> to deal with differences in structure padding for various systems,
>>>>>>>>>>>> particularly to address an issue with ARM CPUs.  However, an issue
>>>>>>>>>>>> has
>>>>>>>>>>>> appeared that affects builds using floats but compiled for 64-bit
>>>>>>>>>>>> CPUs.  It looks like the size used for floats are still 32 bits (4
>>>>>>>>>>>> bytes), as expected, but when used in a struct, it gets allocated as
>>>>>>>>>>>> a
>>>>>>>>>>>> size of 64 bits (8 bytes) to match the word size of the 64-bit CPU.
>>>>>>>>>>>> This has gone undetected up until now as we had not been using float
>>>>>>>>>>>> builds on 64-bit CPUs, but this is the case for iOS and arm64 CPUs
>>>>>>>>>>>> (i.e., recent iPads and iPhones).  From what I can gather, the
>>>>>>>>>>>> existing code works fine for floats and doubles on 32-bit CPUs, and
>>>>>>>>>>>> doubles on 64-bit CPUs, regardless of padding.
>>>>>>>>>>>>
>>>>>>>>>>>> I've updated the memory offset calculation to take into account the
>>>>>>>>>>>> word size and that now seems correct.  However, the test CSD is still
>>>>>>>>>>>> causing problems, which leads me to think that code calculating sizes
>>>>>>>>>>>> for variable memory and pointer assignment needs review.  I suspect
>>>>>>>>>>>> we
>>>>>>>>>>>> may need to do extra padding to the size of MYFLT which should
>>>>>>>>>>>> hopefully fix the issue.  I'm out of time for tonight, but hope to
>>>>>>>>>>>> get
>>>>>>>>>>>> this sorted out tomorrow. Once a fix is found, I will do testing on
>>>>>>>>>>>> platforms I can test on, but will need others to test more broadly
>>>>>>>>>>>> across CPU types and platforms. I will report back here once a fix is
>>>>>>>>>>>> found.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks!