[So far I have not checked if there is a
somewhat analogous C (not C++) issue or
not for gcc9 . For C++, when registers are
used vs. when stack space is used does not
always match system-clang++ for g++9
targeting 32-bit powerpc.]
Building on a head -r356426 32-bit powerpc
the following program:
# more just_now.cpp
#include <chrono>
#include <vector>
int main(void)
{
auto now0{std::chrono::steady_clock::now()};
auto now1{std::chrono::steady_clock::now()};
volatile std::vector<decltype(now0)> ta{ {now0,now1} };
return 0;
}
via:
# g++9 -std=c++17 -nostdinc++ -I/usr/include/c++/v1 \
-pedantic -g -O2 -nodefaultlibs -lc++ -lc -lgcc_s \
just_now.cpp
produces an a.out that SIGSEGV's. Note: lack of -O?
still fails, the code is just shorter for my presentation
purposes when I use something like -O2 .
# ldd a.out
a.out:
libc++.so.1 => /usr/lib/libc++.so.1 (0x41861000)
libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x4193d000)
libc.so.7 => /lib/libc.so.7 (0x41969000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x41b74000)
The same is true for powerpc-unknown-freebsd13.0-g++9 ,
including when used via just:
# /usr/local/bin/powerpc-unknown-freebsd13.0-g++9 \
-std=c++17 -pedantic -g -O2 just_now.cpp
# ldd a.out
a.out:
libc++.so.1 => /usr/lib/libc++.so.1 (0x41861000)
libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x4193d000)
libm.so.5 => /lib/libm.so.5 (0x41969000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x419a4000)
libc.so.7 => /lib/libc.so.7 (0x419cc000)
( The two g++9 variants use /usr/local/bin/ld vs.
/usr/local/bin/powerpc-unknown-freebsd13.0-ld . )
Here is the beginning of main's code from the g++9
variants:
Dump of assembler code for function main():
0x01800530 <+0>: stwu r1,-48(r1)
0x01800534 <+4>: mflr r0
0x01800538 <+8>: stw r0,52(r1)
0x0180053c <+12>: stw r30,40(r1)
0x01800540 <+16>: stw r31,44(r1)
0x01800544 <+20>: bl 0x1810d3c
<_znst3__16chrono12steady_clock3no...@got.plt>
0x01800548 <+24>: mr r30,r3
0x0180054c <+28>: mr r31,r4
0x01800550 <+32>: bl 0x1810d3c
<_znst3__16chrono12steady_clock3no...@got.plt>
. . .
Note the last 2 mr instructions: the code is expecting
now()'s time_point to be returned in registers, not
in stack space provided by main. It is not expecting
now() to require an address for the time_point (in r3).
(That does not match the system-libraries
implementation: that code will try to use r3
as pointing to where to put the time_point.)
By contrast, via system clang:
# c++ -std=c++17 -nostdinc++ -I/usr/include/c++/v1 \
-pedantic -g -O2 -nodefaultlibs -lc++ -lc -lgcc_s \
just_now.cpp
# ldd a.out
a.out:
libc++.so.1 => /usr/lib/libc++.so.1 (0x41861000)
libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x4193d000)
libc.so.7 => /lib/libc.so.7 (0x41969000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x41b74000)
Dump of assembler code for function main():
0x01800768 <+0>: mflr r0
0x0180076c <+4>: stw r0,4(r1)
0x01800770 <+8>: stwu r1,-32(r1)
0x01800774 <+12>: addi r3,r1,24
0x01800778 <+16>: bl 0x1810aa0
<_znst3__16chrono12steady_clock3no...@got.plt>
0x0180077c <+20>: addi r3,r1,16
0x01800780 <+24>: bl 0x1810aa0
<_znst3__16chrono12steady_clock3no...@got.plt>
. . .
clang++ creates stack space and passes the address
of that stack space, with distinct values for
each call. It does not expect to get the
time_point from a now() from registers after the
calls.
(That does match the system-libraries
implementation: that code will try to use r3
as pointing to where to put the time_point.)
This may mean that building gcc9 without
the full bootstrap vs. with the full
bootstrap would have consequences for the
gcc library code and if it matched the
FreeBSD system or not: when built by
clang++ the code would have clang++'s
code generation ABI properties.
But even without a full bootstrap, use
of g++9 variants (as they are) may be
problematical for building ports and
other code.
For reference:
# g++9 -v
Using built-in specs.
COLLECT_GCC=g++9
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc9/gcc/powerpc-portbld-freebsd13.0/9.2.0/lto-wrapper
Target: powerpc-portbld-freebsd13.0
Configured with: /wrkdirs/usr/ports/lang/gcc9/work/gcc-9.2.0/configure
--disable-multilib --disable-plugin --disable-bootstrap --disable-nls
--enable-gnu-indirect-function --libdir=/usr/local/lib/gcc9
--libexecdir=/usr/local/libexec/gcc9 --program-suffix=9
--with-as=/usr/local/bin/as --with-gmp=/usr/local
--with-gxx-include-dir=/usr/local/lib/gcc9/include/c++/
--with-ld=/usr/local/bin/ld --with-pkgversion='FreeBSD Ports Collection'
--with-system-zlib --enable-languages=c,c++,objc,fortran --prefix=/usr/local
--localstatedir=/var --mandir=/usr/local/man
--infodir=/usr/local/share/info/gcc9 --build=powerpc-portbld-freebsd13.0
Thread model: posix
gcc version 9.2.0 (FreeBSD Ports Collection)
# powerpc-unknown-freebsd13.0-g++9 -v
Using built-in specs.
COLLECT_GCC=powerpc-unknown-freebsd13.0-g++9
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/powerpc-unknown-freebsd13.0/9.2.0/lto-wrapper
Target: powerpc-unknown-freebsd13.0
Configured with:
/wrkdirs/usr/ports/devel/freebsd-gcc9/work-powerpc/gcc-9.2.0/configure
--target=powerpc-unknown-freebsd13.0 --disable-nls --enable-languages=c,c++
--enable-gnu-indirect-function --enable-initfini-array
--program-prefix=powerpc-unknown-freebsd13.0- --program-suffix=9
--without-headers --with-gmp=/usr/local --with-pkgversion='FreeBSD Ports
Collection for powerpc' --with-system-zlib
--with-gxx-include-dir=/usr/include/c++/v1/ --with-sysroot=/
--with-as=/usr/local/bin/powerpc-unknown-freebsd13.0-as
--with-ld=/usr/local/bin/powerpc-unknown-freebsd13.0-ld --prefix=/usr/local
--localstatedir=/var --mandir=/usr/local/man --infodir=/usr/local/share/info/
--build=powerpc-unknown-freebsd13.0
Thread model: posix
gcc version 9.2.0 (FreeBSD Ports Collection for powerpc)
# c++ -v
FreeBSD clang version 9.0.1 (g...@github.com:llvm/llvm-project.git
c1a0a213378a458fbea1a5c77b315c7dce08fd05) (based on LLVM 9.0.1)
Target: powerpc-unknown-freebsd13.0
Thread model: posix
InstalledDir: /usr/bin
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
_______________________________________________
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
