Actually, think I know what's going on. I have a custom operator new() which does not necessarily return 8 byte aligned memory (I think)?
Would this be enough to cause problems in asm.js but not in wasm? On Mon, Dec 18, 2017 at 10:58 AM, Mark Sibly <[email protected]> wrote: > > what does the structure definition look like? > > Well, it's the output of a transpiler so it's a bit of a mess. But the > basic idea is: > > struct GCNode{ > GCNode *succ,*pred; > char pad[2]; > char state; > char flags; > > virtual ~GCNode(){ > } > }; > > struct Timer : GCNode{ > > Timer( double hertz ){ > period=1.0/hertz; > } > > double period; > }; > > ...where 'Timer' is the user class causing problems and GCNode is a system > class. > > When built by the transpiler, the end result is that the write to 'period' > seems to be accidentally writing to 'state '- so it's possibly worth noting > it's therefore not an asm.js alignment issue, the compiler is producing > valid but incorrect code. However, if you build/run this as is, it works > fine. I have only encountered the problem when running the output of the > transpiler, and all attempts to c++-ify an example have failed so far. It's > a real heisenbug! > > The 'period' field is indeed misligned for a double, as there is malloc > size+virtual function table (8 bytes) at start of allocation. And adding an > int 'pad' field just before 'period' fixes the problem. > > Could be the transpiler I guess, but I haven't had this issue with mingw32 > or android/ios 32 bit builds - or even wasm. Just asm.js builds. > > On Mon, Dec 18, 2017 at 9:56 AM, Brion Vibber <[email protected]> wrote: > >> In asm.js code, all memory loads and stores must be aligned (wasm does >> not have this limitation). >> >> Normally alignment rules on structs should 'just work' I think -- what >> does the structure definition look like? >> >> -- brion >> >> On Dec 17, 2017 12:46 PM, "Mark Sibly" <[email protected]> wrote: >> >>> Hi, >>> >>> I am having some intermittent problems with what appears to be float >>> point double alignment, where writing to a floating point double field ends >>> up writing to the wrong location. This has been solved in every case so far >>> by manually '8 byte aligning' the double field. >>> >>> Also, this only seems to be happening when generating asm.js 'apps' - so >>> far, there have been no problems with wasm. >>> >>> Unfortunately, this is happening in a translator I am writing, and every >>> attempt I have made so far to isolate some reproducable c++ code has failed! >>> >>> Just wondering of this was a known issue of some kind, or if anyone else >>> has had similar problems? With a bit of luck I'll be able to retire the >>> asm.js target soon in favour of wasm in which case it wont matter, but I >>> just thought I'd check... >>> >>> Bye, >>> Mark >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "emscripten-discuss" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "emscripten-discuss" group. >> To unsubscribe from this topic, visit https://groups.google.com/d/to >> pic/emscripten-discuss/l_P-aW8ZYm4/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
