Re: [toolchain] gcc5-devel question
On 03/01/16 15:33, Gerald Pfeifer wrote:
On Tue, 1 Mar 2016, William A. Mahaffey III wrote:
When I run gcc5 from the CLI or under make as a regular user, it reports no
Graphite support compiled in. When I update the gcc5-devel port, it reports
Graphite enabled:
[root@devbox, gcc5-devel, 10:24:47am] 504 % make showconfig
===> The following configuration options are available for
gcc5-devel-5.3.1.s20160223:
BOOTSTRAP=on: Build using a full bootstrap
GRAPHITE=on: Support for Graphite loop optimizations
JAVA=on: Java platform support
===> Use 'make config' to modify these settings
[root@devbox, gcc5-devel, 10:24:51am] 505 %
This appears odd.
Just to make sure, in both cases it's the gcc5-devel port / package?
Or might one be gcc5, and the other gcc5-devel? That should not make
a difference (cf. `diff gcc5/Makefile gcc5-devel/Makefile`), but might
if there are local changes on your system somewhere.
Best of my knowlege, yes. That's why I included some of the other info
in my OP. When I did the pkg upgrade, the /usr/local/bin/gcc5 upgraded
to something dated Feb 27. When I build the port (make install), I get
some error trying to install it, but it builds OK & leaves everything in
a deep 'staging' directory. The binaries are different.
pkg output:
[root@devbox, /etc, 4:00:55pm] 512 % grep gcc5 LIST.installed.txt
gcc5-devel-5.3.1.s20160223 GNU Compiler Collection 5
[root@devbox, /etc, 4:01:04pm] 513 % pkg info | grep -i gcc5
gcc5-devel-5.3.1.s20160223 GNU Compiler Collection 5
[root@devbox, /etc, 4:01:14pm] 514 % uname -a
FreeBSD devbox 9.3-RELEASE-p33 FreeBSD 9.3-RELEASE-p33 #0: Wed Jan 13
17:55:39 UTC 2016
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
[root@devbox, /etc, 4:01:19pm] 515 %
Checking the actual files (as regular user, from earlier today):
[wam@devbox, pre, 10:34:26am] 576 % !566
find /usr/local/bin/ -name gcc\* -exec ls -CFltr {} +
-r-xr-xr-x 3 root wheel 643768 Nov 30 21:34 /usr/local/bin/gcc48*
-r-xr-xr-x 2 root wheel 24880 Nov 30 21:34 /usr/local/bin/gcc-ranlib48*
-r-xr-xr-x 2 root wheel 24880 Nov 30 21:34 /usr/local/bin/gcc-nm48*
-r-xr-xr-x 2 root wheel 24920 Nov 30 21:34 /usr/local/bin/gcc-ar48*
lrwxr-xr-x 1 root wheel 20 Nov 30 21:35 /usr/local/bin/gcc@ ->
/usr/local/bin/gcc48
-r-xr-xr-x 3 root wheel 846360 Feb 20 05:07 /usr/local/bin/gcc49*
-r-xr-xr-x 2 root wheel 25464 Feb 20 05:07 /usr/local/bin/gcc-ranlib49*
-r-xr-xr-x 2 root wheel 25464 Feb 20 05:07 /usr/local/bin/gcc-nm49*
-r-xr-xr-x 2 root wheel 25464 Feb 20 05:07 /usr/local/bin/gcc-ar49*
-r-xr-xr-x 3 root wheel 895144 Feb 27 23:00 /usr/local/bin/gcc5*
-r-xr-xr-x 2 root wheel 25912 Feb 27 23:00 /usr/local/bin/gcc-ranlib5*
-r-xr-xr-x 2 root wheel 25912 Feb 27 23:00 /usr/local/bin/gcc-nm5*
-r-xr-xr-x 2 root wheel 25944 Feb 27 23:00 /usr/local/bin/gcc-ar5*
[wam@devbox, pre, 10:34:33am] 577 % ( ll
/usr/ports/lang/gcc5-devel/work/stage/usr/local/bin/gcc* )
-r-xr-xr-x 2 root wheel 25944 Mar 1 10:27
/usr/ports/lang/gcc5-devel/work/stage/usr/local/bin/gcc-ar5*
-r-xr-xr-x 2 root wheel 25912 Mar 1 10:27
/usr/ports/lang/gcc5-devel/work/stage/usr/local/bin/gcc-nm5*
-r-xr-xr-x 2 root wheel 25912 Mar 1 10:27
/usr/ports/lang/gcc5-devel/work/stage/usr/local/bin/gcc-ranlib5*
-r-xr-xr-x 3 root wheel 895144 Mar 1 10:27
/usr/ports/lang/gcc5-devel/work/stage/usr/local/bin/gcc5*
[wam@devbox, pre, 10:34:48am] 578 % diff /usr/local/bin/gcc5
/usr/ports/lang/gcc5-devel/work/stage/usr/local/bin/gcc5
Files /usr/local/bin/gcc5 and
/usr/ports/lang/gcc5-devel/work/stage/usr/local/bin/gcc5 differ
[wam@devbox, pre, 10:35:03am] 579 %
Is it intentional that the port & pkg have different support options
(specifically Graphite) ?
Nope. Unless you changed it locally. ;-)
Gerald
Where is that info stored ? When I do a 'ls -ltr' on the port directory,
the Makefile shows up as dated Feb 27:
[root@devbox, gcc5-devel, 4:05:55pm] 517 % ( lltr )
total 1060
-rw-r--r-- 1 root wheel 239 Aug 23 2014 pkg-descr
-rw-r--r-- 1 root wheel 2869 Sep 26 06:09 pkg-plist
-rw-r--r-- 1 root wheel 140 Feb 27 16:23 distinfo
-rw-r--r-- 1 root wheel 5342 Feb 27 16:23 Makefile
drwxr-xr-x 2 root wheel 6 Mar 1 09:29 files/
drwxr-xr-x 5 root wheel17 Mar 1 10:27 work/
-rw-r--r-- 1 root wheel 12157916 Mar 1 10:27 LIST
[root@devbox, gcc5-devel, 4:05:56pm] 517 %
I thought that would trump anything else, no ?
--
William A. Mahaffey III
--
"The M1 Garand is without doubt the finest implement of war
ever devised by man."
-- Gen. George S. Patton Jr.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to
Re: [toolchain] gcc5-devel question
On Tue, 1 Mar 2016, William A. Mahaffey III wrote: > When I run gcc5 from the CLI or under make as a regular user, it reports no > Graphite support compiled in. When I update the gcc5-devel port, it reports > Graphite enabled: > > > [root@devbox, gcc5-devel, 10:24:47am] 504 % make showconfig > ===> The following configuration options are available for > gcc5-devel-5.3.1.s20160223: > BOOTSTRAP=on: Build using a full bootstrap > GRAPHITE=on: Support for Graphite loop optimizations > JAVA=on: Java platform support > ===> Use 'make config' to modify these settings > [root@devbox, gcc5-devel, 10:24:51am] 505 % This appears odd. Just to make sure, in both cases it's the gcc5-devel port / package? Or might one be gcc5, and the other gcc5-devel? That should not make a difference (cf. `diff gcc5/Makefile gcc5-devel/Makefile`), but might if there are local changes on your system somewhere. > Is it intentional that the port & pkg have different support options > (specifically Graphite) ? Nope. Unless you changed it locally. ;-) Gerald ___ 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"
gcc5-devel question
I did a full pkg upgrade on my FreeBSD 9.3R developement box this A.M. This upgraded gcc5-devel, as it should have. My system gcc5 seems to come from the pkg: [root@devbox, /etc, 10:22:49am] 494 % pkg query '%Fp' gcc5-devel | grep 'local/bin/gcc' /usr/local/bin/gcc-ar5 /usr/local/bin/gcc-nm5 /usr/local/bin/gcc-ranlib5 /usr/local/bin/gcc5 [root@devbox, /etc, 10:22:54am] 495 % ll -tr /usr/local/bin/gcc* -r-xr-xr-x 3 root wheel 643768 Nov 30 21:34 /usr/local/bin/gcc48* -r-xr-xr-x 2 root wheel 24880 Nov 30 21:34 /usr/local/bin/gcc-ranlib48* -r-xr-xr-x 2 root wheel 24880 Nov 30 21:34 /usr/local/bin/gcc-nm48* -r-xr-xr-x 2 root wheel 24920 Nov 30 21:34 /usr/local/bin/gcc-ar48* lrwxr-xr-x 1 root wheel 20 Nov 30 21:35 /usr/local/bin/gcc@ -> /usr/local/bin/gcc48 -r-xr-xr-x 3 root wheel 846360 Feb 20 05:07 /usr/local/bin/gcc49* -r-xr-xr-x 2 root wheel 25464 Feb 20 05:07 /usr/local/bin/gcc-ranlib49* -r-xr-xr-x 2 root wheel 25464 Feb 20 05:07 /usr/local/bin/gcc-nm49* -r-xr-xr-x 2 root wheel 25464 Feb 20 05:07 /usr/local/bin/gcc-ar49* -r-xr-xr-x 3 root wheel 895144 Feb 27 23:00 /usr/local/bin/gcc5* -r-xr-xr-x 2 root wheel 25912 Feb 27 23:00 /usr/local/bin/gcc-ranlib5* -r-xr-xr-x 2 root wheel 25912 Feb 27 23:00 /usr/local/bin/gcc-nm5* -r-xr-xr-x 2 root wheel 25944 Feb 27 23:00 /usr/local/bin/gcc-ar5* [root@devbox, /etc, 10:22:56am] 496 % which gcc5 /usr/local/bin/gcc5 [root@devbox, /etc, 10:23:49am] 497 % When I run gcc5 from the CLI or under make as a regular user, it reports no Graphite support compiled in. When I update the gcc5-devel port, it reports Graphite enabled: [root@devbox, gcc5-devel, 10:24:47am] 504 % make showconfig ===> The following configuration options are available for gcc5-devel-5.3.1.s20160223: BOOTSTRAP=on: Build using a full bootstrap GRAPHITE=on: Support for Graphite loop optimizations JAVA=on: Java platform support ===> Use 'make config' to modify these settings [root@devbox, gcc5-devel, 10:24:51am] 505 % Is it intentional that the port & pkg have different support options (specifically Graphite) ? -- William A. Mahaffey III -- "The M1 Garand is without doubt the finest implement of war ever devised by man." -- Gen. George S. Patton Jr. ___ 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"
Re: clang 3.8.0 can mess up __builtin_dwarf_cfa (), at least for TARGET_ARCH=armv6, powerpc, powerpc64: a bug 207325 update
[TARGET_ARCH=powerpc context for all the evidence.] I found another clang++ 3.8.0 vs. g++ 4.2.1 difference where the system libgcc_s depends on how it works for g++ 4.2.1 when clang 3.8.0 does not work the same way: _Unwind_RaiseException is special in a way that makes it save and restore lots of registers it does not directly use. (I'm not sure what triggers having so many registers saved/restored.) But gcc/g++ 4.2.1 saves and restores more registers than clang/clang++ 3.8.0 does. That in turn leaves .eh_frame information for more registers for _Unwind_RaiseException for the gcc/g++ 4.2.1 context. _Unwind_RaiseException from a clang++ 3.8.0 build of libgcc_s does not have save/restore for r3, r4, r5, r6, "r70" (from mfcr, dwarfdump notation). The C++ exception handling library code in libgcc_s depends on r3 (as one example). The pointer for r3 ends up being 0x0 and that causes a crash in examples that get that far using the system's libgcc_s. _Unwind_RaiseException from a g++ 4.2.1 build of libgcc_s has save/restore for r3, r4, r5, r6, "r70" (from mfcr). Later below I list one form of the specific evidence for the differences. It may be that this and the __builtin_dwarf_cfa() "fix" covers all the problems for when libstdc++/libsupc++ are involved with the system libgcc_s instead of libc++/libcxxrt being involved. In my view the registers to save/restore in routines like _Unwind_RaiseException should be considered as part of the overall ABI criteria. Under the rule "the TARGET_ARCH=powerpc ABI is always such that it is gcc/g++ 4.2.1 compatible", I take it that clang 3.8.0 is wrong for FreeBSD TARGET_ARCH=powerpc here: Another ABI violation. TARGET_ARCH=powerpc64 and possibly others could have the same sort of issue. I've never gotten a clang/clang++ based TARGET_ARCH=powerpc64 as far as a complete buildworld. And for now I'm more interested in finding new types of errors for TARGET_ARCH=powerpc rather then what range of TARGET_ARCH's get a specific clang 3.8.0 problem. Separately from the above I've shown that copying the following 3 files to a gcc 4.2.1 buildworld/buildkernel TARGET_ARCH=powerpc context allows exception_test.clang++380.powerpc to run just fine: > exception_test.clang++380.powerpc > /usr/lib/libc++.so.1 > /lib/libcxxrt.so.1 (debug files for the libraries also copied) That leaves the following libraries listed by ldd as being from the gcc 4.2.1 buildworld: > /lib/libm.so.5 > /lib/libc.so.7 > /lib/libgcc_s.so.1 > # ldd exception_test.clang++380.powerpc > exception_test.clang++380.powerpc: > libc++.so.1 => /usr/lib/libc++.so.1 (0x4183e000) > libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x41917000) > libm.so.5 => /lib/libm.so.5 (0x41942000) > libc.so.7 => /lib/libc.so.7 (0x41979000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x41b1d000) exception_test.clang++380.powerpc used with the clang 3.8.0 buildworld and its libgcc_s shows different behavior not likely to be explained by the _Unwind_RaiseException register save/restore differences. (The lack of some saves/restores would still be a problem if I get exception_test.clang++380.powerpc to get that far before doing something odd.) I'm still trying to get evidence of the specific low-level problem for exception_test.clang++380.powerpc. It may be some time before I figure out anything useful. Using some dwarfdump -v -v -F output for the evidence of register save/restore differences. . . _Unwind_RaiseException from a g++ 4.2.1 build of libgcc_s has r3, r4, r5, r6, r70 (from mfcr). The library depends on r3 (as one example). > fde section offset 1104 0x0450 cie offset for fde: 1108 0x0454 > 0 DW_CFA_advance_loc 8 (8 * 1) > 1 DW_CFA_def_cfa_offset 3024 > 4 DW_CFA_advance_loc1 156 > 6 DW_CFA_offset r4 -232 (58 * -4) > 8 DW_CFA_offset r3 -236 (59 * -4) > 10 DW_CFA_offset r28 -160 (40 * -4) > 12 DW_CFA_offset r27 -164 (41 * -4) > 14 DW_CFA_offset r26 -168 (42 * -4) > 16 DW_CFA_offset r25 -172 (43 * -4) > 18 DW_CFA_offset r24 -176 (44 * -4) > 20 DW_CFA_offset r23 -180 (45 * -4) > 22 DW_CFA_offset r22 -184 (46 * -4) > 24 DW_CFA_offset r21 -188 (47 * -4) > 26 DW_CFA_offset r20 -192 (48 * -4) > 28 DW_CFA_offset r19 -196 (49 * -4) > 30 DW_CFA_offset r18 -200 (50 * -4) > 32 DW_CFA_offset r17 -204 (51 * -4) > 34 DW_CFA_offset r16 -208 (52 * -4) > 36 DW_CFA_offset r15 -212 (53 * -4) > 38 DW_CFA_offset r14 -216 (54 * -4) > 40 DW_CFA_offset r63 -8 (2 * -4) > 42 DW_CFA_offset r62 -16 (4 * -4) > 44 DW_CFA_offset r61 -24 (6 * -4) > 46 DW_CFA_offset r60 -32 (8 * -4) > 48 DW_CFA_offset r59 -40 (10 * -4) > 50 DW_CFA_offset r58 -48 (12 * -4) > 52 DW_CFA_offset r57 -56 (14 * -4) > 54 DW_CFA_offset r56 -64 (16 * -4) > 56
