On Tue, Apr 25, 2017 at 2:37 PM, Peter Robinson <pbrobinson@xxxxxxxxx> wrote: > On Tue, Apr 25, 2017 at 4:52 PM, Jakub Jelinek <jakub@xxxxxxxxxx> wrote: >> Hi! >> >> A severe ABI bug on AArch64 and especially on ARM 32-bit has been >> recently discovered and GCC 7.1 is going to have that ABI change in. >> For details see http://gcc.gnu.org/PR77728 >> gcc-7.1.1-0.16.fc{26,27} which I'll build tomorrow will contain the >> ABI changes as well as a -Wpsabi diagnostics (note:) on code that is >> changing the ABI. >> The ABI change should affect primarily just C++ code passing PODs > > By primarily is it guaranteed to be limited to C++ or is it possible > it could affect other code? > >> by value where all the non-static data members and base classes are at most >> word aligned, but there are some static data members with doubleword >> or bigger alignment or there are typedefs or other nested types in >> the class/struct which are doubleword or bigger aligned, and are passed >> in certain positions in the argument list (passing them in even registers >> is fine, passing them in odd ones changes ABI, on the stack at odd positions >> might change the ABI too). For the typedefs, the broken ABI of GCC 5.2 to 7.0.1 >> has been actually not even self-consitent in some templates, earlier >> instantiation vs. lack thereof could affect the ABI. GCC 5.1 and earlier >> for structs used to match earlier AAPCS version and had different rules and >> issues. >> >> Could somebody from rel-eng perform a test mass rebuild on armv7hl >> and aarch64 of F26 to determine which packages are affected by the >> ABI changes so that we could rebuild only those that actually need changing? >> >> If grepping for note: is not good enough for the test mass rebuild, I could >> hack up a test compiler that does something different when it encounters >> this (say abort if it encounters this and some special env var is set, >> or writes something into some /tmp/ file and let some brp script collect >> info from there, etc.). >> Could this be the reason why capnproto builds fail on ARM? I've been trying to build it for months, and it seems to just die in the build process. c.f.: https://koji.fedoraproject.org/koji/taskinfo?taskID=18098874 -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
