Thread overview | |||||||||
---|---|---|---|---|---|---|---|---|---|
|
March 04, 2016 [Bug 214] memory aligment issue ARM builds after 4.9.0 | ||||
---|---|---|---|---|
| ||||
Attachments:
| http://bugzilla.gdcproject.org/show_bug.cgi?id=214 vlevenfeld@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |vlevenfeld@gmail.com -- You are receiving this mail because: You are watching all bug changes. |
March 04, 2016 [Bug 214] memory aligment issue ARM builds after 4.9.0 | ||||
---|---|---|---|---|
| ||||
Attachments:
| http://bugzilla.gdcproject.org/show_bug.cgi?id=214 vlevenfeld@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Hardware|All |ARM OS|All |Linux -- You are receiving this mail because: You are watching all bug changes. |
March 04, 2016 [Bug 214] memory aligment issue ARM builds after 4.9.0 | ||||
---|---|---|---|---|
| ||||
Attachments:
| http://bugzilla.gdcproject.org/show_bug.cgi?id=214 --- Comment #1 from vlevenfeld@gmail.com --- Found a fix: If I go into phobos' epoll.d and change align(1) to align(8), everything works. According to this thread (https://github.com/nodejs/node-v0.x-archive/issues/4565) ARM systems require 64-bit data elements to be 8-byte-aligned. Looks like that got broken between 4.9.0 and 4.9.2? -- You are receiving this mail because: You are watching all bug changes. |
March 04, 2016 [Bug 214] memory aligment issue ARM builds after 4.9.0 | ||||
---|---|---|---|---|
| ||||
Attachments:
| http://bugzilla.gdcproject.org/show_bug.cgi?id=214 --- Comment #2 from Iain Buclaw <ibuclaw@gdcproject.org> --- Is the library different between 4.9.0 and 4.9.2? Either the align was added to the library, or the compiler started doing what the code requested. -- You are receiving this mail because: You are watching all bug changes. |
March 04, 2016 [Bug 214] memory aligment issue ARM builds after 4.9.0 | ||||
---|---|---|---|---|
| ||||
Attachments:
| http://bugzilla.gdcproject.org/show_bug.cgi?id=214 Johannes Pfau <johannespfau@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |johannespfau@gmail.com Status|NEW |ASSIGNED --- Comment #3 from Johannes Pfau <johannespfau@gmail.com> --- I guess the library changed, as that old forum thread mentioned in 2014 there was no align(1) in epoll.d which was wrong on X86. Whether the struct is packed depends on the target architecture. On ARM the struct is not packed. The ARM version should just use standard alignment (no explicit align(8)), the align(1) version should be restricted to X86/(64) and an additional else static assert(false) should be added. Needs to go into upstream druntime as well. (grep __EPOLL_PACKED in glibc). Actually, AFAICS X86 ist the only architecture using a packed struct. -- You are receiving this mail because: You are watching all bug changes. |
March 04, 2016 [Bug 214] memory aligment issue ARM builds after 4.9.0 | ||||
---|---|---|---|---|
| ||||
Attachments:
| http://bugzilla.gdcproject.org/show_bug.cgi?id=214 --- Comment #4 from vlevenfeld@gmail.com --- The library is the same - it is actually not phobos' epoll but libasync's epoll that is being used in this specific instance (though the two files don't appear to differ). So the same file is being used with different compilers. It appears as though, before 4.9.2, GDC ignored the alignment directive (at least on ARM). So this is not a bug with GDC, but rather with libasync and phobos? The epoll implementation should be responsible for setting the correct alignment for the architecture? -- You are receiving this mail because: You are watching all bug changes. |
March 06, 2016 [Bug 214] memory aligment issue ARM builds after 4.9.0 | ||||
---|---|---|---|---|
| ||||
Attachments:
| http://bugzilla.gdcproject.org/show_bug.cgi?id=214 --- Comment #5 from Johannes Pfau <johannespfau@gmail.com> --- The align(1) in epoll.d was introduced in 2.066 but IIRC there were also some changes in align() handling at some point. I think it used to be ignored. But either way, the compiler is correct and druntime (and probably libasync) need to be fixed: https://github.com/D-Programming-Language/druntime/pull/1502 -- You are receiving this mail because: You are watching all bug changes. |
Copyright © 1999-2021 by the D Language Foundation