[PD-dev] Compiling objects with gnu++14
Robert Esler
robert at urbanstew.org
Wed Jun 3 21:15:41 CEST 2015
Hi Arshia,
I’ve built numerous C++ Pd objects and have found at times C++ doesn’t seem to work well with C when it comes to binary runtime. I learned that here: http://stackoverflow.com/questions/5397447/struct-padding-in-c
Though I haven’t encountered what Miller is saying that all struct elements are 64-bit aligned, did he mean pointers? Because that is certainly the case.
I don’t fully comprehend the scope of your code, essentially what is the need for a 4 byte offset? And why does this statement need to be true: (boundmsg->a_w.w_symbol->s_name == atom_getsymbol(boundmsg)->s_name) ? Or maybe I’m completely misinterpreting your issue?
For the former, can you eliminate the issue by checking for offset size, like:
#include <stddef.h>
#include <iostream>
struct D
{
double *d;
};
struct T {
int *i;
short *j;
D *k;
};
int main() {
int a = offsetof(T, i);
int b = offsetof(T, j);
int c = offsetof(T, k);
if(b - a == 8 && c - b == 8)
std::cout << "8 offset" << std::endl; // do something here
else if (b - a == 4 && c - b == 4)
std::cout << "4 offset" << std::endl; // do something else here
}
Best,
Rob Esler
----------------------------------------------------------------------
Message: 1
Date: Wed, 3 Jun 2015 11:29:42 +0200
From: Arshia Cont <Arshia.Cont at ircam.fr>
To: Antoine Rousseau <ant1rousseau1 at gmail.com>
Cc: pd-dev <pd-dev at lists.iem.at>
Subject: Re: [PD-dev] Compiling objects with gnu++14
Message-ID: <30D6E725-3B91-4A4E-B5B7-F22714396B02 at ircam.fr>
Content-Type: text/plain; charset="utf-8"
Antoine,
Ignore details of my short code… the t_atom is actually correctly allocated..
What happens is that when boundmsg is accessed outside this score (using atom_getsymbol) the address of its struct members are NOT the same (we have verified this in different ways).
Miller suggested that “It looks like C++11 has decided that structure elements should all be 64-bit aligned. This would mean that you simply can’t link C++11 and Gnu C code together”
You could check it by printing out the pointers,
boundmsg->a_type
boundmsg->a_w.w_symbol
These differ by 4 in Pd - if your compiler wants them to differ by 8, the two aren’t compatible.
I can’t seem to find a compiler flag in clang that globally sets the alignment!!! I can do that locally for each struct but this will make the object non-distributable… .
> On 03 Jun 2015, at 10:33, Antoine Rousseau <ant1rousseau1 at gmail.com> wrote:
>
> Maybe I don't understand well, but your short code example is incorrect :
>
> t_atom *boundmsg;
> boundmsg->a_type = A_SYMBOL;boundmsg->a_w.w_symbol = ss;
>
> because you are assigning fields of a not allocated structure : boundmsg here is just the undefined address of a potential storage.
>
> This should work :
>
> t_atom boundmsg;
> boundmsg.a_type = A_SYMBOL; boundmsg.a_w.w_symbol = ss;
>
>
> Or :
>
> t_atom *boundmsg = getbytes(sizeof(t_atom));
> boundmsg->a_type = A_SYMBOL;boundmsg->a_w.w_symbol = ss;
>
>
> Hope this helps, sorry if I'm off topic.
>
> 2015-06-03 10:00 GMT+02:00 Arshia Cont <Arshia.Cont at ircam.fr <mailto:Arshia.Cont at ircam.fr>>:
> Thomas,
>
> My clang version is
> Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
> Target: x86_64-apple-darwin14.3.0
> Thread model: posix
>
>
> Before I give you the compilation flags, here is what it comes down to.. basically, the following code gives indeterministic behaviour due to memory misalignment when the atom pointer is passed to :
>
> t_atom *boundmsg; // etc.
> boundmsg->a_type = A_SYMBOL;boundmsg->a_w.w_symbol = ss;
>
> assert(boundmsg->a_w.w_symbol->s_name == atom_getsymbol(boundmsg)->s_name); // imagine that my assert works on char*! simplifying here
>
>
> Here is an example of the compilation, following Katja’s blog on soundtouch~. I am using i386 on purpose here for testing.You can ignore capital letter flags that come from us:
>
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x c++ -arch i386 -fmessage-length=0 -fdiagnostics-show-note-include-stack -fmacro-backtrace-limit=0 -std=gnu++1y -stdlib=libc++ -Wno-trigraphs -fshort-enums -Os -Wno-missing-field-initializers -Wmissing-prototypes -Wno-return-type -Wunreachable-code -Wnon-virtual-dtor -Wno-overloaded-virtual -Wno-exit-time-destructors -Wmissing-braces -Wparentheses -Wswitch -Wno-unused-function -Wno-unused-label -Wno-unused-parameter -Wno-unused-variable -Wunused-value -Wempty-body -Wno-uninitialized -Wno-unknown-pragmas -Wno-shadow -Wno-four-char-constants -Wno-conversion -Wno-constant-conversion -Wno-int-conversion -Wno-bool-conversion -Wno-enum-conversion -Wassign-enum -Wno-shorten-64-to-32 -Wno-newline-eof -Wno-c++11-extensions -DNDEBUG=1 -DDEPLOYMENT_VERSION=1 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk -fasm-blocks -fstrict-aliasing -Wdeprecated-declarations -Winvalid-offsetof -mmacosx-version-min=10.7 -g -fvisibility-inlines-hidden -Wno-sign-conversion -I/Users/acont/Devs/MyFlextProjects/antescofo/build/antescofo~.build/Deployment/pd_static.build/antescofo~.hmap -I/Users/acont/Devs/MyFlextProjects/antescofo/build/Deployment/include -I/Users/acont/Devs/MyFlextProjects/antescofo/build/antescofo~.build/Deployment/pd_static.build/DerivedSources/i386 -I/Users/acont/Devs/MyFlextProjects/antescofo/build/antescofo~.build/Deployment/pd_static.build/DerivedSources -Wmost -Wno-unknown-pragmas -Wno-four-char-constants -F/Users/acont/Devs/MyFlextProjects/antescofo/build/Deployment -F/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks -DNDEBUG=1 -DARCHI_MAC_OS=4 -DARCHI_LINUX=5 -DARCHI_WINDOWS=6 -DANTESCOFO_ARCHI=ARCHI_MAC_OS -DTARGET_PD=2 -DTARGET_STANDALONE_FILE=3 -DTARGET_MAXSDK=4 -DTARGET_ASCOGRAPH=7 -I/Users/acont/Devs/MyFlextProjects/antescofo/../Mutant-libs/oscpack_1_1_0_RC2/ip -I/Users/acont/Devs/MyFlextProjects/antescofo/../Mutant-libs/oscpack_1_1_0_RC2/osc -I/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include -DANTESCOFO_TARGET=TARGET_PD -I/Users/acont/Devs/MyFlextProjects/antescofo/../Mutant-libs/pd-0.46-6/src -fvisibility=hidden -fcheck-new -MMD -MT dependencies -MF /Users/acont/Devs/MyFlextProjects/antescofo/build/antescofo~.build/Deployment/pd_static.build/Objects-normal/i386/Antescofo_PdClass.d --serialize-diagnostics /Users/acont/Devs/MyFlextProjects/antescofo/build/antescofo~.build/Deployment/pd_static.build/Objects-normal/i386/Antescofo_PdClass.dia -c /Users/acont/Devs/MyFlextProjects/antescofo/sources/Antescofo_PdClass.cpp -o /Users/acont/Devs/MyFlextProjects/antescofo/build/antescofo~.build/Deployment/pd_static.build/Objects-normal/i386/Antescofo_PdClass.o
>
> Arshia Cont
>
>
>
>
>> On 02 Jun 2015, at 21:43, Thomas Grill <gr at grrrr.org <mailto:gr at grrrr.org>> wrote:
>>
>> Hi Arshia,
>> which compiler is it exactly that you use? Can you copy the options?
>> best, Thomas
>>
>> 2015-06-02 14:35 GMT+02:00 Arshia Cont <Arshia.Cont at ircam.fr <mailto:Arshia.Cont at ircam.fr>>:
>> Thank you Katja for the swift response! We will wait for that then.
>>
>> Any one running into run-time problems when compiling with C++11 or C++14? We seem to have memory alignment issues… .
>>
>> Arshia Cont
>>
>>
>>
>>
>>> On 02 Jun 2015, at 14:23, katja <katjavetter at gmail.com <mailto:katjavetter at gmail.com>> wrote:
>>>
>>> On Tue, Jun 2, 2015 at 1:07 PM, Arshia Cont <Arshia.Cont at ircam.fr <mailto:Arshia.Cont at ircam.fr>> wrote:
>>>
>>> [...]
>>>
>>>> My second question would be on double-precision audio externals.. I see discussions on class_new64 but can’t seem to find any trace of it in 0.46-6.. I dig into the archives to figure this one out first!
>>>
>>> In 2011 I made a set of patch files for vanilla pd 0.43 to enable
>>> double precision builds (where t_float and t_sample are doubles). That
>>> can be found here:
>>>
>>> https://github.com/pd-projects/pd-double <https://github.com/pd-projects/pd-double>
>>>
>>> You could try it out for evaluation but Miller wants to scrutinize,
>>> test and improve the patch files before accepting them.
>>>
>>> Katja
>>>
>>
>>
>> _______________________________________________
>> Pd-dev mailing list
>> Pd-dev at lists.iem.at <mailto:Pd-dev at lists.iem.at>
>> http://lists.puredata.info/listinfo/pd-dev <http://lists.puredata.info/listinfo/pd-dev>
>>
>>
>>
>> --
>> Thomas Grill
>> http://grrrr.org <http://grrrr.org/>
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at lists.iem.at <mailto:Pd-dev at lists.iem.at>
> http://lists.puredata.info/listinfo/pd-dev <http://lists.puredata.info/listinfo/pd-dev>
>
>
>
>
> --
> Antoine Rousseau
> http://www.metalu.net <http://metalu.net/> __ http://www.metaluachahuter.com/<http://www.metaluachahuter.com/compagnies/al1-ant1/> __ http://al1ant1.free.fr <http://al1ant1.free.fr/>
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at lists.iem.at
> http://lists.puredata.info/listinfo/pd-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20150603/65501099/attachment-0001.html>
More information about the Pd-dev
mailing list