Re: ARM and AArch64 GCC 7.1 ABI change

[Jakub Jelinek]

On Fri, May 05, 2017 at 04:18:47PM +0200, Marek Polacek wrote:
> I've started our own mass rebuild.  To whittle down the list of packages
> to rebuild, I chose to only build C++ packages.  This I did by looking
> at *.debug files, DW_AT_producer in particular.
> 
> The aarch64 rebuild is done, and these packages seem to be affected:

I should note that the rebuilds should be performed with gcc-7.1.1-1.fc26 or
newer (I've pushed it to stable, but it still doesn't appear there, so
perhaps a buildroot override will be needed).

Also, aarch64 needs to have kernel rebuilt (inline asm miscompilation in
there).

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: ARM and AArch64 GCC 7.1 ABI change

[Marek Polacek]

On Tue, Apr 25, 2017 at 12:55:47PM -0500, Dennis Gilmore wrote:
> El mar, 25-04-2017 a las 17:52 +0200, Jakub Jelinek escribió:
> > 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 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? 
> 
> We do not currently have resources or tooling to do test rebuilds.  Do
> you have any idea what would be needed in order to do so?

I've started our own mass rebuild.  To whittle down the list of packages
to rebuild, I chose to only build C++ packages.  This I did by looking
at *.debug files, DW_AT_producer in particular.

The aarch64 rebuild is done, and these packages seem to be affected:

libtorrent-0.13.6-2.fc24.src.rpm
ceres-solver-1.12.0-4.fc26.src.rpm
codeblocks-16.01-8.fc27.src.rpm
opencv-3.2.0-1.fc26.src.rpm
mmseq-1.0.8a-17.fc26.src.rpm
zhu3d-4.2.6-7.fc24.src.rpm
libmediainfo-0.7.94-1.fc27.src.rpm
fawkes-1.0.1-3.fc27.src.rpm
fmt-3.0.1-2.fc26.src.rpm
step-16.12.3-1.fc27.src.rpm
mlpack-2.0.1-3.fc26.src.rpm
hyperrogue-8.3-3.j.fc26.src.rpm
root-6.08.06-3.fc27.src.rpm
vxl-1.17.0-21.fc26.src.rpm
repsnapper-2.4-0.1.a2.fc27.src.rpm
tellico-2.3.12-1.fc26.src.rpm
pcl-1.8.0-6.fc26.src.rpm
avogadro2-libs-1.90.0-5.fc27.src.rpm

But the aarch32 rebuild is much slower and hasn't finished yet, though it seems
to be near its end now.  So far these packages need to be rebuilt:

znc-1.6.5-1.fc27.src.rpm
purple-line-20170331gitb330e2b-1.fc27.src.rpm
nload-0.7.4-8.fc26.src.rpm
jsoncpp-1.8.0-2.fc26.src.rpm
libepubgen-0.0.0-11.fc26.src.rpm
device-mapper-persistent-data-0.7.0-0.1.rc6.fc27.src.rpm
libgnomecanvasmm26-2.26.0-15.fc26.src.rpm
kig-16.12.3-1.fc27.src.rpm
coan-6.0.1-8.fc25.src.rpm
plotmm-0.1.2-24.fc26.src.rpm
fuse-emulator-utils-1.3.1-2.fc26.src.rpm
eris-1.3.23-7.fc26.src.rpm
harmonyseq-0.16-21.fc26.src.rpm
afflib-3.7.15-1.fc27.src.rpm
libopenraw-0.1.1-1.fc27.src.rpm
coin-or-Alps-1.5.5-2.fc26.src.rpm
ccgo-0.3.6.5-3.fc27.src.rpm
cfdg-3.0-0.beta2.fc26.10.src.rpm
linbox-1.4.2-7.fc27.src.rpm
recoll-1.23.1-1.fc27.src.rpm
votca-csg-1.4-1.fc26.2.src.rpm
flxmlrpc-0.1.4-4.fc26.src.rpm
coin-or-CoinUtils-2.10.13-2.fc26.src.rpm
stage-4.1.1-16.fc27.src.rpm
glogg-1.1.3-1.fc27.src.rpm
mongo-cxx-driver-1.1.2-5.fc26.src.rpm
libmediainfo-0.7.94-1.fc27.src.rpm
gsmartcontrol-0.8.7-11.fc26.src.rpm
ochusha-0.6.0.1-0.14.cvs20100817T.fc26.1.7.src.rpm
verilator-3.890-3.fc26.src.rpm
rb_libtorrent-1.1.2-1.fc27.src.rpm
rmol-1.00.1-10.fc26.src.rpm
exempi-2.4.2-2.fc26.src.rpm
pdns-recursor-4.0.4-4.fc26.src.rpm
gparted-0.28.1-1.fc26.src.rpm
ardour2-2.8.16-24.fc26.src.rpm
librime-1.2-13.fc26.src.rpm
mm3d-1.3.8a-14.fc26.src.rpm
qt5-qtconnectivity-5.8.0-1.fc27.src.rpm
airtsp-1.01.3-2.fc26.src.rpm
normaliz-3.1.4-1.fc27.src.rpm
vulkan-1.0.46.0-2.fc27.src.rpm
kf5-kio-5.33.0-1.fc27.src.rpm
gpsim-0.29.0-4.fc26.src.rpm
monotone-1.1-19.fc26.src.rpm
mmapper-2.3.6-3.fc26.src.rpm
ember-0.7.2-17.fc26.src.rpm
qpdf-6.0.0-4.fc26.src.rpm
wireshark-2.2.6-2.fc27.src.rpm
mapserver-7.0.4-3.gitb4bc015.fc26.src.rpm
filezilla-3.25.2-0.rc1.fc27.src.rpm
extremetuxracer-0.7.4-2.fc26.src.rpm
mypaint-1.1.0-11.fc26.src.rpm
alliance-5.1.1-7.20160506gitd8c05cd.fc26.src.rpm
kstars-16.12.3-1.fc27.src.rpm
qgis-2.18.7-1.fc27.src.rpm
ardour5-5.8.0-1.fc27.src.rpm
opencv-3.2.0-1.fc26.src.rpm
qcad-3.16.7.0-1.fc27.src.rpm
passenger-5.0.30-3.fc26.src.rpm
calf-0.0.60-4.fc26.src.rpm
qt5-qtbase-5.8.0-8.fc27.src.rpm
kopete-16.12.3-1.fc27.src.rpm
digikam-5.5.0-1.fc27.src.rpm
nodejs-mapnik-3.5.14-4.fc26.src.rpm
stellarium-0.15.2-1.fc27.src.rpm
opencity-0.0.6.5-5.fc26.src.rpm
icecat-52.0.2-3.fc27.src.rpm
qm-vamp-plugins-1.7.1-2.fc26.src.rpm
pingus-0.7.6-22.fc26.src.rpm
abiword-3.0.2-5.fc26.src.rpm

Re: ARM and AArch64 GCC 7.1 ABI change

[Neal Gompa]

On Tue, Apr 25, 2017 at 2:37 PM, Peter Robinson  wrote:
> On Tue, Apr 25, 2017 at 4:52 PM, Jakub Jelinek  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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: ARM and AArch64 GCC 7.1 ABI change

[Jakub Jelinek]

On Tue, Apr 25, 2017 at 07:37:03PM +0100, Peter Robinson wrote:
> On Tue, Apr 25, 2017 at 4:52 PM, Jakub Jelinek  wrote:
> > 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?

I'm not 100% sure about e.g. Ada.  C is certainly not affected, for Fortran
in theory some OOP code could be, would need to investigate.
The testbox I've bootstrapped earlier version of the patch is gone, I
vaguely remember only seeing the notes in g++.dg/ and libstdc++/ testsuites
and not elsewhere, but that is not a proof that it can't happen.
The only thing that is clear is that C doesn't have anything but field decls
in aggregates and so can't be affected.

Jakub
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: ARM and AArch64 GCC 7.1 ABI change

[Peter Robinson]

On Tue, Apr 25, 2017 at 4:52 PM, Jakub Jelinek  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.).
>
> Jakub
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: ARM and AArch64 GCC 7.1 ABI change

[Dan Horák]

forwarding to the ARM list for better visibility by the ARM team


Dan

On Tue, 25 Apr 2017 12:55:47 -0500
Dennis Gilmore  wrote:

> El mar, 25-04-2017 a las 17:52 +0200, Jakub Jelinek escribió:
> > 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 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? 
> 
> We do not currently have resources or tooling to do test rebuilds.  Do
> you have any idea what would be needed in order to do so?
> 
> > 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.).
> 
> Dennis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: ARM and AArch64 GCC 7.1 ABI change

[Dennis Gilmore]

El mar, 25-04-2017 a las 17:52 +0200, Jakub Jelinek escribió:
> 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 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? 

We do not currently have resources or tooling to do test rebuilds.  Do
you have any idea what would be needed in order to do so?

> 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.).

Dennis

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org