Re: [PATCH, rs6000, 4.8/4.9] Fix alignment of non-Altivec vector struct fields
Am 17.07.2014 02:41, schrieb Ulrich Weigand: Hello, this is the variant intended for the 4.8/4.9 branches of the patch: https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01072.html As discussed, it does *not* actually change ABI, but only warn when encountering a situation where the ABI will change in a future GCC. (Avoiding the specific term GCC 4.10 here since I'm not certain whether the next GCC release will in fact be called that ...) Tested on powerpc64-linux and powerpc64le-linux; also verified using the ABI compat suite (against an unpatched GCC) that this patch does not change the ABI. this causes PR libobjc/61920, link failures with -lobjc.
Re: [PATCH, rs6000, 4.8/4.9] Fix alignment of non-Altivec vector struct fields
Am 27.07.2014 13:59, schrieb pins...@gmail.com: On Jul 27, 2014, at 4:53 AM, Alan Modra amo...@gmail.com wrote: On Sun, Jul 27, 2014 at 07:16:07PM +0930, Alan Modra wrote: On Sat, Jul 26, 2014 at 01:45:12PM +0200, Matthias Klose wrote: Am 17.07.2014 02:41, schrieb Ulrich Weigand: Hello, this is the variant intended for the 4.8/4.9 branches of the patch: https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01072.html As discussed, it does *not* actually change ABI, but only warn when encountering a situation where the ABI will change in a future GCC. (Avoiding the specific term GCC 4.10 here since I'm not certain whether the next GCC release will in fact be called that ...) Tested on powerpc64-linux and powerpc64le-linux; also verified using the ABI compat suite (against an unpatched GCC) that this patch does not change the ABI. this causes PR libobjc/61920, link failures with -lobjc. Try this. Index: libobjc/encoding.c === --- libobjc/encoding.c(revision 213090) +++ libobjc/encoding.c(working copy) @@ -192,6 +192,7 @@ ? MAX (MAX (COMPUTED, SPECIFIED), 64)\ : MAX (COMPUTED, SPECIFIED));}) +#define rs6000_special_adjust_field_align_p false /* Skip a variable name, enclosed in quotes (). */ static inline Blah, that won't work of course. The macro needs to take two parameters. #define rs6000_special_adjust_field_align_p(FIELD, COMPUTED) false This is pre-approved if it works. I really should finish off the branch I started years ago :). #define rs6000_special_adjust_field_align_p(FIELD, COMPUTED) 0 is what succeeds for me. false is not defined for ObjC. Checked in on the trunk and the branches. these are still regressions, because the new warnings trigger on these test cases: Running /home/doko/gcc/gcc-4.9-4.9.1/src/gcc/testsuite/objc.dg/gnu-encoding/gnu-encoding.exp ... FAIL: objc.dg-struct-layout-encoding-1/t025_main.m execution test FAIL: objc.dg-struct-layout-encoding-1/t027_main.m execution test FAIL: objc.dg-struct-layout-encoding-1/t028_main.m execution test FAIL: objc.dg-struct-layout-encoding-1/t029_main.m execution test FAIL: objc.dg-struct-layout-encoding-1/t030_main.m execution test FAIL: objc.dg-struct-layout-encoding-1/t031_main.m execution test No regressions in the obj-c++ tests. Matthias
Re: [patch] remove picochip
Am 05.09.2014 um 05:40 schrieb Jeff Law: On 09/04/14 21:16, Trevor Saunders wrote: Hi, Looks like the patch is to big to send uncompressed, so sorry if this the second mail you get :) Given picochip has been obsolete for several years at this point, and when I asked a while back if anyone wanted to keep it nobody responded I'm going to claim its time to kill it. bootstrapped + regtested x86_64-unknown-linux-gnu, and checked picochip-elf is nolonger a recognized target. ok? It was obsoleted just shy of 2 years ago, so it's been through a release cycle. OK for the trunk. this left three empty directories: libgcc/config/picochip gcc/config/picochip gcc/common/config/picochip removed, and committed as obvious Matthias
Re: Towards GNU11
Am 08.10.2014 um 09:16 schrieb Richard Biener: On Tue, 7 Oct 2014, Marek Polacek wrote: I think it makes sense to do this (and I expect C++ will follow with defaulting to -std=c++11 once the ABI stuff has settled). Of course it would be nice to look at the actual fallout in a whole-distribution rebuild... I can certainly do that, once stage1 is finished, hopefully for more than x86 architectures. What happened to the plans to stabilize the libstdc++ c++11 ABI? Is this still a target for GCC 5? Matthias
Re: [PATCH C++] - SD-6 Implementation Part 4 - Test suite.
Am 07.09.2014 um 03:48 schrieb Ed Smith-Rowland:
Greetings,
I am finally getting back to my SD-6 C++ features test work.
This adds front end and preprocessor tests for the language feature tests and
__has_include.
I am still working on the fifth and last in this series to add
__had_cpp_attribute but these first four patches add a very useful subset of
the
SD-6 feature testing.
Bootstrapped and tested under x86_64-linux.
apparently this was checked in on the 4.9 branch as well. However the cxx14.X
testcase fails with:
ERROR: g++.dg/cpp1y/feat-cxx14.C -std=gnu++98: syntax error in target selector
target c++14 for dg-do 1 compile { target c++14 }
UNRESOLVED: g++.dg/cpp1y/feat-cxx14.C -std=gnu++98: syntax error in target
selector target c++14 for dg-do 1 compile { target c++14 }
ERROR: g++.dg/cpp1y/feat-cxx14.C -std=gnu++11: syntax error in target selector
target c++14 for dg-do 1 compile { target c++14 }
UNRESOLVED: g++.dg/cpp1y/feat-cxx14.C -std=gnu++11: syntax error in target
selector target c++14 for dg-do 1 compile { target c++14 }
ERROR: g++.dg/cpp1y/feat-cxx14.C -std=gnu++1y: syntax error in target selector
target c++14 for dg-do 1 compile { target c++14 }
UNRESOLVED: g++.dg/cpp1y/feat-cxx14.C -std=gnu++1y: syntax error in target
selector target c++14 for dg-do 1 compile { target c++14 }
Re: [PATCH] remove score-* support
Am 03.10.2014 um 17:35 schrieb Jeff Law: On 10/03/14 08:50, tsaund...@mozilla.com wrote: From: Trevor Saunders tsaund...@mozilla.com Hi, It was obsoleted back in 2011, so we're good to remove it. bootstrapped + regtested x86_64-unknown-linux-gnu, and checked configure doesn't recognize score-elf. Ok? Trev libgcc/ChangeLog: 2014-09-10 Trevor Saunders tsaund...@mozilla.com * config.host: Remove support for score-*. contrib/ChangeLog: 2014-09-10 Trevor Saunders tsaund...@mozilla.com * compare-all-tests: Don't test score-*. * config-list.mk: Likewise. gcc/ChangeLog: 2014-09-10 Trevor Saunders tsaund...@mozilla.com * common/config/score/score-common.c: Remove. * config.gcc: Remove support for score-*. * config/score/constraints.md: Remove. * config/score/elf.h: Remove. * config/score/predicates.md: Remove. * config/score/score-conv.h: Remove. * config/score/score-generic.md: Remove. * config/score/score-modes.def: Remove. * config/score/score-protos.h: Remove. * config/score/score.c: Remove. * config/score/score.h: Remove. * config/score/score.md: Remove. * config/score/score.opt: Remove. * doc/md.texi: Don't document score-*. OK. Jeff removed the empty directories common/config/score config/score committed as abvious. Matthias
[patch, rfc] fix warning building libssp in C11 mode
Building libssp in C11 mode shows a warning for 64bit configurations, ../../../src/libssp/gets-chk.c:62:12: warning: return makes pointer from integer without a cast [-Wint-conversion] Currently working around by adding a prototype in gets-chk.c, conditionally defined by the inverted condition found in glibc's stdio.h. Is there a better approach? Matthias # DP: Declare prototype for gets in C11 mode --- libssp/gets-chk.c +++ libssp/gets-chk.c @@ -51,6 +51,11 @@ # include string.h #endif +#if !(!defined __USE_ISOC11\ + || (defined __cplusplus __cplusplus = 201103L)) +extern char *gets (char *); +#endif + extern void __chk_fail (void) __attribute__((__noreturn__)); char *
Re: [jit] Drop libgccjit.pc
Am 20.10.2014 um 22:11 schrieb Basile Starynkevitch: On Mon, 2014-10-20 at 13:54 -0400, David Malcolm wrote: Committed to branch dmalcolm/jit: pkg-config appears to be controversial, so don't provide a .pc file. I would put it under contrib/; it is controversial, but some would like to have it. please don't. if it's not always installed, then you have to check for a fall back in any case. Matthias
[patch] fix impliedness of -Wunused-parameter depending on -Wexta option ordering
This fixes a regression introduced with 4.8, where the option ordering of
-Wextra and -Wunused-parameter emits a warning, which is not emitted with 4.7.
No regressions with the trunk, the 4.9 and 4.8 branches. Ok to check in for
these?
Matthias
2014-05-08 Manuel LC3B3pez-IbC3A1C3B1ez m...@gcc.gnu.org
Matthias Klose d...@ubuntu.com
PR driver/61106
* optc-gen.awk: Fix option handling for -Wunused-parameter.
gcc/testsuite/
2014-05-08 Matthias Klose d...@ubuntu.com
PR driver/61106
* gcc-dg/unused-8a.c: New.
* gcc-dg/unused-8b.c: Likewise.
gcc/
2014-05-08 Manuel López-Ibáñez m...@gcc.gnu.org
Matthias Klose d...@ubuntu.com
PR driver/61106
* optc-gen.awk: Fix option handling for -Wunused-parameter.
gcc/testsuite/
2014-05-08 Matthias Klose d...@ubuntu.com
PR driver/61106
* gcc-dg/unused-8a.c: New.
* gcc-dg/unused-8b.c: Likewise.
Index: gcc/optc-gen.awk
===
--- gcc/optc-gen.awk(revision 210245)
+++ gcc/optc-gen.awk(working copy)
@@ -406,11 +406,13 @@
if (opt_var_name != ) {
condition = !opts_set-x_ opt_var_name
if (thisenableif[j] != ) {
-condition = condition ( thisenableif[j] )
+value = ( thisenableif[j] )
+} else {
+value = value
}
print if ( condition )
print handle_generated_option (opts, opts_set,
-print opt_enum(thisenable[j])
, NULL, value,
+print opt_enum(thisenable[j])
, NULL, value ,
print lang_mask, kind, loc,
handlers, dc);
} else {
print #error thisenable[j] does not have a Var() flag
Index: gcc/testsuite/gcc.dg/unused-8a.c
===
--- gcc/testsuite/gcc.dg/unused-8a.c(revision 0)
+++ gcc/testsuite/gcc.dg/unused-8a.c(working copy)
@@ -0,0 +1,4 @@
+/* { dg-do compile } */
+/* { dg-options -Wall -Wextra -Wno-unused } */
+
+void foo(int x) { }
Index: gcc/testsuite/gcc.dg/unused-8b.c
===
--- gcc/testsuite/gcc.dg/unused-8b.c(revision 0)
+++ gcc/testsuite/gcc.dg/unused-8b.c(working copy)
@@ -0,0 +1,4 @@
+/* { dg-do compile } */
+/* { dg-options -Wall -Wno-unused -Wextra } */
+
+void foo(int x) { }
Re: [patch] fix impliedness of -Wunused-parameter depending on -Wexta option ordering
Am 08.05.2014 23:36, schrieb Joseph S. Myers: On Thu, 8 May 2014, Matthias Klose wrote: This fixes a regression introduced with 4.8, where the option ordering of -Wextra and -Wunused-parameter emits a warning, which is not emitted with 4.7. No regressions with the trunk, the 4.9 and 4.8 branches. Ok to check in for these? OK. I didn't look close enough to the gfortran test results. PR driver/61126 is a fix for the regression introduced with the fix for the above issue. With this patch proposed by Manuel, gfortran.dg/wextra_1.f now passes, and no new regressions seen on the trunk and the branches. Matthias gcc/fortran/ PR driver/61126 * options.c (gfc_handle_option): Don't enable -Wunused-parameter with -Wextra * lang.opt (Wunused-parameter): New. gcc/ PR driver/61126 * opts-global.c (set_default_handlers): Fix order of handlers. Index: gcc/fortran/lang.opt === --- a/src/gcc/fortran/lang.opt (revision 210277) +++ b/src/gcc/fortran/lang.opt (working copy) @@ -301,6 +301,10 @@ Fortran Warning Warn about unused dummy arguments. +Wunused-parameter +LangEnabledBy(Fortran,Wextra) +; Documented in common.opt + Wzerotrip Fortran Warning Warn about zero-trip DO loops Index: gcc/fortran/options.c === --- a/src/gcc/fortran/options.c (revision 210277) +++ b/src/gcc/fortran/options.c (working copy) @@ -674,12 +674,7 @@ break; case OPT_Wextra: - handle_generated_option (global_options, global_options_set, - OPT_Wunused_parameter, NULL, value, - gfc_option_lang_mask (), kind, loc, - handlers, global_dc); set_Wextra (value); - break; case OPT_Wfunction_elimination: Index: gcc/opts-global.c === --- a/src/gcc/opts-global.c (revision 210277) +++ b/src/gcc/opts-global.c (working copy) @@ -273,10 +273,10 @@ handlers-unknown_option_callback = unknown_option_callback; handlers-wrong_lang_callback = complain_wrong_lang; handlers-num_handlers = 3; - handlers-handlers[0].handler = lang_handle_option; - handlers-handlers[0].mask = initial_lang_mask; - handlers-handlers[1].handler = common_handle_option; - handlers-handlers[1].mask = CL_COMMON; + handlers-handlers[0].handler = common_handle_option; + handlers-handlers[0].mask = CL_COMMON; + handlers-handlers[1].handler = lang_handle_option; + handlers-handlers[1].mask = initial_lang_mask; handlers-handlers[2].handler = target_handle_option; handlers-handlers[2].mask = CL_TARGET; }
Re: [patch] fix impliedness of -Wunused-parameter depending on -Wexta option ordering
Am 12.05.2014 19:30, schrieb Joseph S. Myers: On Mon, 12 May 2014, Matthias Klose wrote: I didn't look close enough to the gfortran test results. PR driver/61126 is a fix for the regression introduced with the fix for the above issue. With this patch proposed by Manuel, gfortran.dg/wextra_1.f now passes, and no new regressions seen on the trunk and the branches. I think changing the order of the handlers has far too high a risk of introducing further nonobvious regressions to consider it for the branches. You need a clear and careful analysis of the circumstances under which the order of the handlers can affect observable compiler behavior in order to justify such a change as safe. But I think a better principle is that if the order matters, there is a bug in those handlers and they should be fixed so that the order doesn't matter (absent a clear design showing why it is desirable for the order to matter). reverted the fix for PR driver/61106 on the branches, keeping the unused-8b.c test case. Matthias
[patch] check that sys/sdt.h can be used with the target
The HAVE_SYS_SDT_H define succeeds when the file sys/sdt.h is found. It doesn't use the target compiler for that check, like AC_CHECK_HEADER does. This patch uses AC_COMPILE to check for the header and ensure that a dummy program succeeds to build. This is a different patch than the one proposed at https://gcc.gnu.org/ml/gcc-patches/2012-12/msg01122.html I think the conditional with the file check can be removed too, kept it for now. Ok for the trunk? Matthias PR other/61257 * configure.ac: Build a test program before defining HAVE_SYS_SDT_H. * configure: Regenerate. Index: gcc/configure.ac === --- gcc/configure.ac(revision 210677) +++ gcc/configure.ac(working copy) @@ -4971,9 +4971,13 @@ AC_MSG_CHECKING(sys/sdt.h in the target C library) have_sys_sdt_h=no if test -f $target_header_dir/sys/sdt.h; then - have_sys_sdt_h=yes - AC_DEFINE(HAVE_SYS_SDT_H, 1, -[Define if your target C library provides sys/sdt.h]) + AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include sys/sdt.h]], + [[DTRACE_PROBE(foo,bar); return 0;]]) +],[ + have_sys_sdt_h=yes + AC_DEFINE(HAVE_SYS_SDT_H, 1, + [Define if your target C library provides sys/sdt.h]) +]) fi AC_MSG_RESULT($have_sys_sdt_h)
Re: libgo patch committed: Merge from revision 18783 of master
Am 05.06.2014 03:28, schrieb Ian Lance Taylor: I have committed a patch to libgo to merge from revision 18783:00cce3a34d7e of the master library. This revision was committed January 7. I picked this revision to merge to because the next revision deleted a file that is explicitly merged in by the libgo/merge.sh script. Among other things, this patch changes type descriptors to add a new pointer to a zero value. In gccgo this is implemented as a common variable, and that requires some changes to the compiler and a small change to go-gcc.cc. As usual the patch is too large to include in this e-mail message. I've appended the changes to parts of libgo that are more gccgo-specific. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline. Is it time to bump the soname on trunk?
[ping] Re: [PATCH, AARCH64] MULTIARCH_DIRNAME breaks multiarch build
ping, adding build maintainers Am 10.01.2014 12:06, schrieb Matthias Klose: Am 10.01.2014 10:49, schrieb Zhenqiang Chen: On 10 January 2014 17:23, Matthias Klose d...@ubuntu.com wrote: Am 10.01.2014 09:23, schrieb Zhenqiang Chen: Hi, MULTIARCH_DIRNAME was removed @r196649 since the dir info had been combined in MULTILIB_OSDIRNAMES. But MULTIARCH_DIRNAME was re-added @r201164. With this change, the final multiarch_dir is combined as aarch64-linux-gnu:aarch64-linux-gnu, which is incorrect and leads to multiarch build fail if the sysroot is in correct multiarch layout. Any reason to add MULTIARCH_DIRNAME? If it is not necessary, can we remove it as the patch? see the thread [patch] set MULTIARCH_DIRNAME for multilib architectures from June 2013. I think it is necessary to have the default defined. Yesterday's build looks ok for me, looking at default and include paths, so maybe I don't yet understand the issue. In our build, we configure eglbc with rtlddir=/lib libdir=/usr/lib/aarch64-linux-gnu slibdir=/lib/aarch64-linux-gnu And we configure gcc with --disable-multilib --enable-multiarch, But when building gcc libraries, configure FAIL since it can not find the C libraries. And I try ./xgcc --print-multiarch the output is aarch64-linux-gnu:aarch64-linux-gnu Any comments? Thanks! -Zhenqiang I think aarch64 is the only architecture which introduces MULTILIB_* macros without actually building any multilib, just to set the default library name to lib64. So maybe this has some side effects. sorry, I have a local patch applied after the lib64 change, which I forgot to forward. * Makefile.in (s-mlib): Only pass MULTIARCH_DIRNAME if MULTILIB_OSDIRNAMES is not defined. --- a/src/gcc/Makefile.in +++ b/src/gcc/Makefile.in @@ -1837,7 +1837,7 @@ $(MULTILIB_EXCLUSIONS) \ $(MULTILIB_OSDIRNAMES) \ $(MULTILIB_REQUIRED) \ - $(MULTIARCH_DIRNAME) \ + $(if $(MULTILIB_OSDIRNAMES),,$(MULTIARCH_DIRNAME)) \ $(MULTILIB_REUSE) \ @enable_multilib@ \ tmp-mlib.h; \ applied/tested since July 2013 on the Debian/Ubuntu distro builds. It doesn't affect the non-multiarch case. Ok for the trunk? Matthias
Re: Is testing libgomp outside of the build tree supported?
Am 04.02.2014 03:14, schrieb Mike Stump: On Feb 3, 2014, at 3:52 PM, Joseph S. Myers jos...@codesourcery.com wrote: On Mon, 3 Feb 2014, Andrew Pinski wrote: On Mon, Feb 3, 2014 at 11:14 AM, Diego Novillo dnovi...@google.com wrote: On Mon, Feb 3, 2014 at 2:11 PM, Ian Lance Taylor i...@google.com wrote: If the presence of the build tree makes writing some tests significantly simpler, I think that is OK. I would like to discourage that. Testing an already installed GCC for which no build tree exists is a very useful feature. I agree. Here at Cavium, we use the packaged up toolchain that comes from a RPM and test it so we are testing exactly what we ship out to our customers. Similarly at Mentor. And the maintainer of the test suite thinks that supporting the people that ship gcc to large numbers of people who help ensure the quality of gcc is useful. :-) It is nice to hear from people that this type of testing is useful; thanks. could somebody please shed some light on how this is done? It's nice that everybody has this kind of testing, but the only bit in the gcc sources itself seems to be a bit bit-rot and incomplete (contrib/test_installed). thanks, Matthias
[patch] remove empty directory gcc/testsuite/g++.dg/cpp0x/regress
ok to remove the empty directory gcc/testsuite/g++.dg/cpp0x/regress on the trunk? Matthias
Re: [PATCH] Don't segv on __atomic_store (PR c/61553)
is this ok to backport to 4.9? testsuite passes without regressions with this
patch on the 4.9 branch.
Matthias
Am 23.06.2014 um 20:21 schrieb Marek Polacek:
On Mon, Jun 23, 2014 at 04:39:55PM +0200, Marek Polacek wrote:
--- gcc/testsuite/c-c++-common/pr61553.c
+++ gcc/testsuite/c-c++-common/pr61553.c
@@ -0,0 +1,8 @@
+/* PR c/61553 */
+/* { dg-do compile } */
+
+void
+foo (char *s)
+{
+ __atomic_store (s, (void *) 0, __ATOMIC_SEQ_CST);
Oops, dg-error disappeared from the final patch. I'm fixing it with
the following.
2014-06-23 Marek Polacek pola...@redhat.com
PR c/61553
* c-c++-common/pr61553.c (foo): Add dg-error.
diff --git gcc/testsuite/c-c++-common/pr61553.c
gcc/testsuite/c-c++-common/pr61553.c
index fa97e94..8a3b699 100644
--- gcc/testsuite/c-c++-common/pr61553.c
+++ gcc/testsuite/c-c++-common/pr61553.c
@@ -4,5 +4,5 @@
void
foo (char *s)
{
- __atomic_store (s, (void *) 0, __ATOMIC_SEQ_CST);
+ __atomic_store (s, (void *) 0, __ATOMIC_SEQ_CST); /* { dg-error size
mismatch } */
}
Marek
Re: [PATCH] Add support for GNU/Hurd in gnat-4.9
Am 20.08.2014 um 22:12 schrieb Svante Signell: On Wed, 2014-05-21 at 10:48 +0200, Samuel Thibault wrote: Svante Signell, le Wed 21 May 2014 10:44:54 +0200, a écrit : On Wed, 2014-05-21 at 10:33 +0200, Arnaud Charlet wrote: I think the majority of work has bee done, Now that patch will change slightly for every missing feature added to Hurd. Then it's all good, it's a matter of what I said above. Don't forget also the part where general changes are done in GNAT which require update to target specific files: these typically require someone to regularly test each port to detect any missing update, and report/fix them, even if GNU/Hurd hasn't changed itself. With the help from the dabian-ada people, especially Ludovic Brenta, gnat has been running on GNU/Hurd in Debian since gcc/gnat-4.6.3. Then it's all good. Just say that you wish to continue maintaining things like this, and upstream will be happy. Attached is the updated ada-hurd.diff patch for GNU/Hurd. It builds fine with gnat-4.9.1-1 and gcc-4.9.1-7. This patch now has the same amount of files as the kFreeBSD patch. Hopefully it can be material for upstream, but at least in Debian the Hurd port would be on par with kFreeBSD. Regarding remaining code commented out or irrelevant comments in the new file s-osinte-gnu.ads, please help me to iron out the left-overs. the patch is at least missing the ChangeLog entry. Also it is only tested using the Debian package based on the 4.9 branch, and which includes a bunch of local ada patches which are not forwarded upstream for years. Please prepare and test your patch with current trunk for upstream submission. Ludovic, can you consider using this file as ada-hurd.diff for next upload of Debian gnat-4.9? For clarity: I wish to continue to maintain the Ada port for Hurd, with the help of the Debian Ada and Hurd people, with or without being imported upstream. I disagree. Debian's current local ada patches are a mess, and no effort is made to cleanup these and forward these upstream. If the Debian Ada people can't do this, please do it yourself. Matthias
Re: [PATCH v2 AArch64]: Re: [PATCH AArch64]: Add constraint letter for stack_protect_test pattern.
Am 17.09.2014 um 00:03 schrieb James Greenhalgh:
If you have any other suggestions, or if =r is actually correct and
I am misreading the documentation please let me know.
with this patch I see a lot of ICEs in the testsuite for test cases built with
-O3 (and a build defaulting to -fstack-protector-strong by default), all of the
form:
Executing on host: /home/doko/gcc/4.9/gcc-4.9-4.9.1/build/gcc/xgcc
-B/home/doko/gcc/4.9/gcc-4.9-4.9.1/build/gcc/ -fno-diagnostics-show-caret -fdia
gnostics-color=never -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions -w -c -o 900116-1.o /home/doko/gcc/4.9/gcc-4.9-4.9.1/src/g
cc/testsuite/gcc.c-torture/compile/900116-1.c(timeout = 300)
spawn /home/doko/gcc/4.9/gcc-4.9-4.9.1/build/gcc/xgcc
-B/home/doko/gcc/4.9/gcc-4.9-4.9.1/build/gcc/ -fno-diagnostics-show-caret
-fdiagnostics-color
=never -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions -w -c -o
900116-1.o /home/doko/gcc/4.9/gcc-4.9-4.9.1/src/gcc/testsuite/gcc.c-
torture/compile/900116-1.c
/home/doko/gcc/4.9/gcc-4.9-4.9.1/src/gcc/testsuite/gcc.c-torture/compile/900116-1.c:
In function 'zloop':
/home/doko/gcc/4.9/gcc-4.9-4.9.1/src/gcc/testsuite/gcc.c-torture/compile/900116-1.c:14:1:
error: insn does not satisfy its constraints:
(insn 228 225 230 9 (parallel [
(set (reg:DI 1 x1 [279])
(unspec:DI [
(mem/v/f/c:DI (plus:DI (reg/f:DI 31 sp)
(const_int 24 [0x18])) [4 D.2626+0 S8 A64])
(mem/v/f/c:DI (reg/f:DI 2 x2 [277]) [4
__stack_chk_guard+0 S8 A64])
] UNSPEC_SP_TEST))
(clobber (reg:DI 2 x2 [320]))
])
/home/doko/gcc/4.9/gcc-4.9-4.9.1/src/gcc/testsuite/gcc.c-torture/compile/900116-1.c:14
741 {stack_protect_test_di}
(expr_list:REG_DEAD (reg/f:DI 13 x13 [277])
(expr_list:REG_UNUSED (reg:DI 2 x2 [320])
(nil
/home/doko/gcc/4.9/gcc-4.9-4.9.1/src/gcc/testsuite/gcc.c-torture/compile/900116-1.c:14:1:
internal compiler error: in copyprop_hardreg_forward_1, at regcprop.c:775
Please submit a full bug report,
with preprocessed source if appropriate.
for now only tested with the 4.9 linaro branch, now testing with trunk.
Matthias
--- - 2014-09-17 13:13:05.245022015 +
+++ test-summary2014-09-17 03:02:55.916771634 +
@@ -1,4 +1,4 @@
-Results for 4.9.1 (Ubuntu/Linaro 4.9.1-14ubuntu2) testsuite on
aarch64-unknown-linux-gnu
+Results for 4.9.1 (Ubuntu/Linaro 4.9.1-14ubuntu2.1) testsuite on
aarch64-unknown-linux-gnu
LAST_UPDATED: Fri Sep 12 17:12:16 UTC 2014 (revision 215228)
Native configuration is aarch64-unknown-linux-gnu
@@ -78,19 +78,16 @@
# of expected passes 116
# of unexpected failures 6
-/build/buildd/gcc-4.9-4.9.1/build/./gcc/gccgo version 4.9.1 (Ubuntu/Linaro
4.9.1-14ubuntu2)
+/home/doko/gcc/4.9/gcc-4.9-4.9.1/build/./gcc/gccgo version 4.9.1
(Ubuntu/Linaro 4.9.1-14ubuntu2.1)
=== libgomp tests ===
Running target unix
-WARNING: program timed out.
-FAIL: libgomp.graphite/force-parallel-6.c execution test
=== libgomp Summary for unix ===
-# of expected passes 3240
-# of unexpected failures 1
+# of expected passes 3241
# of unsupported tests 36
Running target unix/-fno-stack-protector
@@ -102,8 +99,7 @@
=== libgomp Summary ===
-# of expected passes 6481
-# of unexpected failures 1
+# of expected passes 6482
# of unsupported tests 72
=== libitm tests ===
@@ -198,14 +194,29 @@
# of expected failures 82
# of unsupported tests 504
Target: aarch64-linux-gnu
-gcc version 4.9.1 (Ubuntu/Linaro 4.9.1-14ubuntu2)
+gcc version 4.9.1 (Ubuntu/Linaro 4.9.1-14ubuntu2.1)
=== g++ tests ===
Running target unix
+FAIL: g++.dg/opt/unroll1.C -std=gnu++98 (internal compiler error)
+FAIL: g++.dg/opt/unroll1.C -std=gnu++98 (test for excess errors)
+UNRESOLVED: g++.dg/opt/unroll1.C -std=gnu++98 compilation failed to produce
executable
+FAIL: g++.dg/opt/unroll1.C -std=gnu++11 (internal compiler error)
+FAIL: g++.dg/opt/unroll1.C -std=gnu++11 (test for excess errors)
+UNRESOLVED: g++.dg/opt/unroll1.C -std=gnu++11 compilation failed to produce
executable
+FAIL: g++.dg/opt/unroll1.C -std=gnu++1y (internal compiler error)
+FAIL: g++.dg/opt/unroll1.C -std=gnu++1y (test for excess errors)
+UNRESOLVED: g++.dg/opt/unroll1.C -std=gnu++1y compilation failed to produce
executable
XPASS: g++.dg/tls/thread_local-order2.C -std=c++11 execution test
XPASS: g++.dg/tls/thread_local-order2.C -std=c++1y execution test
+FAIL: c-c++-common/torture/vector-shift.c -O3 -fomit-frame-pointer
-funroll-loops (internal compiler error)
+FAIL: c-c++-common/torture/vector-shift.c -O3 -fomit-frame-pointer
-funroll-loops (test for excess errors)
+UNRESOLVED: c-c++-common/torture/vector-shift.c -O3 -fomit-frame-pointer
-funroll-loops
Re: [PATCH v2 AArch64]: Re: [PATCH AArch64]: Add constraint letter for stack_protect_test pattern.
Am 17.09.2014 um 15:14 schrieb Matthias Klose:
Am 17.09.2014 um 00:03 schrieb James Greenhalgh:
If you have any other suggestions, or if =r is actually correct and
I am misreading the documentation please let me know.
with this patch I see a lot of ICEs in the testsuite for test cases built with
-O3 (and a build defaulting to -fstack-protector-strong by default), all of
the
form:
Executing on host: /home/doko/gcc/4.9/gcc-4.9-4.9.1/build/gcc/xgcc
-B/home/doko/gcc/4.9/gcc-4.9-4.9.1/build/gcc/ -fno-diagnostics-show-caret
-fdia
gnostics-color=never -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions -w -c -o 900116-1.o
/home/doko/gcc/4.9/gcc-4.9-4.9.1/src/g
cc/testsuite/gcc.c-torture/compile/900116-1.c(timeout = 300)
spawn /home/doko/gcc/4.9/gcc-4.9-4.9.1/build/gcc/xgcc
-B/home/doko/gcc/4.9/gcc-4.9-4.9.1/build/gcc/ -fno-diagnostics-show-caret
-fdiagnostics-color
=never -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions -w -c -o
900116-1.o /home/doko/gcc/4.9/gcc-4.9-4.9.1/src/gcc/testsuite/gcc.c-
torture/compile/900116-1.c
/home/doko/gcc/4.9/gcc-4.9-4.9.1/src/gcc/testsuite/gcc.c-torture/compile/900116-1.c:
In function 'zloop':
/home/doko/gcc/4.9/gcc-4.9-4.9.1/src/gcc/testsuite/gcc.c-torture/compile/900116-1.c:14:1:
error: insn does not satisfy its constraints:
(insn 228 225 230 9 (parallel [
(set (reg:DI 1 x1 [279])
(unspec:DI [
(mem/v/f/c:DI (plus:DI (reg/f:DI 31 sp)
(const_int 24 [0x18])) [4 D.2626+0 S8 A64])
(mem/v/f/c:DI (reg/f:DI 2 x2 [277]) [4
__stack_chk_guard+0 S8 A64])
] UNSPEC_SP_TEST))
(clobber (reg:DI 2 x2 [320]))
])
/home/doko/gcc/4.9/gcc-4.9-4.9.1/src/gcc/testsuite/gcc.c-torture/compile/900116-1.c:14
741 {stack_protect_test_di}
(expr_list:REG_DEAD (reg/f:DI 13 x13 [277])
(expr_list:REG_UNUSED (reg:DI 2 x2 [320])
(nil
/home/doko/gcc/4.9/gcc-4.9-4.9.1/src/gcc/testsuite/gcc.c-torture/compile/900116-1.c:14:1:
internal compiler error: in copyprop_hardreg_forward_1, at regcprop.c:775
Please submit a full bug report,
with preprocessed source if appropriate.
for now only tested with the 4.9 linaro branch, now testing with trunk.
seen with trunk r215323 as well, after disabling itm (--disable-libitm) which
currently doesn't seem to build.
Matthias
Re: [PATCH v2 AArch64]: Re: [PATCH AArch64]: Add constraint letter for stack_protect_test pattern.
Am 17.09.2014 um 15:14 schrieb Matthias Klose: Am 17.09.2014 um 00:03 schrieb James Greenhalgh: If you have any other suggestions, or if =r is actually correct and I am misreading the documentation please let me know. with this patch I see a lot of ICEs in the testsuite for test cases built with -O3 (and a build defaulting to -fstack-protector-strong by default), all of the form: I tested with the wrong patch. No regression, and fixing the original issue with the attached patch. Tested with the trunk and the Linaro 4.9 branch, Matthias --- gcc/config/aarch64/aarch64.md +++ gcc/config/aarch64/aarch64.md @@ -4031,7 +4031,7 @@ (unspec:PTR [(match_operand:PTR 1 memory_operand m) (match_operand:PTR 2 memory_operand m)] UNSPEC_SP_TEST)) - (clobber (match_scratch:PTR 3 r))] + (clobber (match_scratch:PTR 3 =r))] ldr\t%w3, %x1\;ldr\t%w0, %x2\;eor\t%w0, %w3, %w0 [(set_attr length 12)
Re: [patch] libgo - fix build errors and add ARM bits
Am 04.12.2012 07:26, schrieb Ian Lance Taylor:
On Mon, Nov 19, 2012 at 8:27 AM, Matthias Klose d...@ubuntu.com wrote:
libgo-fix-arm.diff: Work around parse error of struct timex_ on ARM (both
trunk
and 4.7 branch).
libgo-hardening.diff: Avoid compiler warnings in libgo with
-D_FORTIFY_SOURCE=2,
which let the build fail with -Werror. first chunk for the trunk and 4.7,
second
chunk for trunk only.
libgo-mksysinfo.diff: Fix TIOCNOTTY and TIOCSCTTY definitions, afaicr needed
for
ARM as well. for trunk and 4.7.
Thanks. I committed the libgo-hardening and libgo-mksysinfo patches
to mainline and 4.7 branch.
Can you tell me more about the libgo-fix-arm patch? The patch adds
these lines to mksysinfo.sh:
+# ARM
+sed -i '/type _timex/s/INVALID-bit-field/int32/g;/type _timex/s,^//
,,' gen-sysinfo.go
I don't understand why there would an INVALID-bit-field on ARM. This
struct comes from the sys/timex.h, which as far as I can see should
be the same on every glibc system.
What does struct timex look like in your sys/timex.h file? What
does the line look like in gen-sysinfo.go before the sed script above
is run?
defined in bits/timex.h
struct timex
{
unsigned int modes; /* mode selector */
__syscall_slong_t offset; /* time offset (usec) */
__syscall_slong_t freq; /* frequency offset (scaled ppm) */
__syscall_slong_t maxerror; /* maximum error (usec) */
__syscall_slong_t esterror; /* estimated error (usec) */
int status; /* clock command/status */
__syscall_slong_t constant; /* pll time constant */
__syscall_slong_t precision; /* clock precision (usec) (ro) */
__syscall_slong_t tolerance; /* clock frequency tolerance (ppm) (ro) */
struct timeval time; /* (read only) */
__syscall_slong_t tick; /* (modified) usecs between clock ticks */
__syscall_slong_t ppsfreq;/* pps frequency (scaled ppm) (ro) */
__syscall_slong_t jitter; /* pps jitter (us) (ro) */
int shift;/* interval duration (s) (shift) (ro) */
__syscall_slong_t stabil; /* pps stability (scaled ppm) (ro) */
__syscall_slong_t jitcnt; /* jitter limit exceeded (ro) */
__syscall_slong_t calcnt; /* calibration intervals (ro) */
__syscall_slong_t errcnt; /* calibration errors (ro) */
__syscall_slong_t stbcnt; /* stability limit exceeded (ro) */
int tai; /* TAI offset (ro) */
/* ??? */
int :32; int :32; int :32; int :32;
int :32; int :32; int :32; int :32;
int :32; int :32; int :32;
};
I'll have to re-run the build with out the patch, but this replaces just the
32bit bit fields with an int32.
Matthias
Re: [patch] libgo - fix build errors and add ARM bits
Am 04.12.2012 08:03, schrieb Ian Lance Taylor:
On Mon, Dec 3, 2012 at 10:47 PM, Matthias Klose d...@ubuntu.com wrote:
Am 04.12.2012 07:26, schrieb Ian Lance Taylor:
On Mon, Nov 19, 2012 at 8:27 AM, Matthias Klose d...@ubuntu.com wrote:
libgo-fix-arm.diff: Work around parse error of struct timex_ on ARM (both
trunk
and 4.7 branch).
libgo-hardening.diff: Avoid compiler warnings in libgo with
-D_FORTIFY_SOURCE=2,
which let the build fail with -Werror. first chunk for the trunk and 4.7,
second
chunk for trunk only.
libgo-mksysinfo.diff: Fix TIOCNOTTY and TIOCSCTTY definitions, afaicr
needed for
ARM as well. for trunk and 4.7.
Thanks. I committed the libgo-hardening and libgo-mksysinfo patches
to mainline and 4.7 branch.
Can you tell me more about the libgo-fix-arm patch? The patch adds
these lines to mksysinfo.sh:
+# ARM
+sed -i '/type _timex/s/INVALID-bit-field/int32/g;/type _timex/s,^//
,,' gen-sysinfo.go
I don't understand why there would an INVALID-bit-field on ARM. This
struct comes from the sys/timex.h, which as far as I can see should
be the same on every glibc system.
What does struct timex look like in your sys/timex.h file? What
does the line look like in gen-sysinfo.go before the sed script above
is run?
defined in bits/timex.h
struct timex
{
unsigned int modes; /* mode selector */
__syscall_slong_t offset; /* time offset (usec) */
__syscall_slong_t freq; /* frequency offset (scaled ppm) */
__syscall_slong_t maxerror; /* maximum error (usec) */
__syscall_slong_t esterror; /* estimated error (usec) */
int status; /* clock command/status */
__syscall_slong_t constant; /* pll time constant */
__syscall_slong_t precision; /* clock precision (usec) (ro) */
__syscall_slong_t tolerance; /* clock frequency tolerance (ppm) (ro) */
struct timeval time; /* (read only) */
__syscall_slong_t tick; /* (modified) usecs between clock ticks */
__syscall_slong_t ppsfreq;/* pps frequency (scaled ppm) (ro) */
__syscall_slong_t jitter; /* pps jitter (us) (ro) */
int shift;/* interval duration (s) (shift) (ro) */
__syscall_slong_t stabil; /* pps stability (scaled ppm) (ro) */
__syscall_slong_t jitcnt; /* jitter limit exceeded (ro) */
__syscall_slong_t calcnt; /* calibration intervals (ro) */
__syscall_slong_t errcnt; /* calibration errors (ro) */
__syscall_slong_t stbcnt; /* stability limit exceeded (ro) */
int tai; /* TAI offset (ro) */
/* ??? */
int :32; int :32; int :32; int :32;
int :32; int :32; int :32; int :32;
int :32; int :32; int :32;
};
I'll have to re-run the build with out the patch, but this replaces just the
32bit bit fields with an int32.
Thanks. That's more or less what timex.h looks like on my system, but
I don't see the bitfields. GCC treats the :32 fields as int32, in
both 32-bit and 64-bit mode.
sorry, this was fixed with the patch for PR52557.
Re: C++ PATCH for c++/54325 (wrong error initializing abstract base class)
Am 07.12.2012 06:05, schrieb Jason Merrill:
It's perfectly OK to initialize a base class of abstract type; it's only an
error to create a full object of such a type. So this patch moves the check
from more generic initialization code out into a function that's definitely
creating a new object.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.7.
this doesn't build on the branch:
../gcc/cp/tree.c: In function 'build_aggr_init_expr':
../gcc/cp/tree.c:399:1: error: parameter name omitted
this fixes the bootstrap, currently running the testsuite.
--- cp/tree.c~ 2012-12-07 10:01:16.665415647 +0100
+++ cp/tree.c 2012-12-07 10:11:01.373410862 +0100
@@ -396,7 +396,8 @@
callable. */
tree
-build_aggr_init_expr (tree type, tree init, tsubst_flags_t /*complain*/)
+build_aggr_init_expr (tree type, tree init,
+ tsubst_flags_t complain ATTRIBUTE_UNUSED)
{
tree fn;
tree slot;
Re: C++ PATCH for c++/54325 (wrong error initializing abstract base class)
Am 07.12.2012 10:17, schrieb Jakub Jelinek:
On Fri, Dec 07, 2012 at 10:13:11AM +0100, Matthias Klose wrote:
Am 07.12.2012 06:05, schrieb Jason Merrill:
It's perfectly OK to initialize a base class of abstract type; it's only an
error to create a full object of such a type. So this patch moves the check
from more generic initialization code out into a function that's definitely
creating a new object.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.7.
this doesn't build on the branch:
../gcc/cp/tree.c: In function 'build_aggr_init_expr':
../gcc/cp/tree.c:399:1: error: parameter name omitted
this fixes the bootstrap, currently running the testsuite.
Please commit as obvious with appropriate ChangeLog entry.
--- cp/tree.c~ 2012-12-07 10:01:16.665415647 +0100
+++ cp/tree.c2012-12-07 10:11:01.373410862 +0100
@@ -396,7 +396,8 @@
callable. */
tree
-build_aggr_init_expr (tree type, tree init, tsubst_flags_t /*complain*/)
+build_aggr_init_expr (tree type, tree init,
+ tsubst_flags_t complain ATTRIBUTE_UNUSED)
{
tree fn;
tree slot;
Jakub
comitted.
Matthias
2012-12-07 Matthias Klose d...@ubuntu.com
* tree.c (build_aggr_init_expr): Add parameter name, mark as unused.
[patch] libgcc unwind-arm.h: mark arguments as unused
This was seen and fixed on trunk building libbacktrace on arm:
http://gcc.gnu.org/ml/gcc-patches/2012-10/msg00628.html
I see this now cross building libgo targeting arm on the 4.7 branch. Ok to
backport to the 4.7 branch?
Matthias
2012-10-07 Matthias Klose d...@ubuntu.com
* config/arm/unwind-arm.h (__gnu_unwind_24bit): Mark parameters
as unused.
(_Unwind_decode_typeinfo_ptr): Mark base as unused.
--- libgcc/config/arm/unwind-arm.h~
+++ libgcc/config/arm/unwind-arm.h
@@ -39,7 +39,8 @@
#endif
/* Decode an R_ARM_TARGET2 relocation. */
static inline _Unwind_Word
- _Unwind_decode_typeinfo_ptr (_Unwind_Word base, _Unwind_Word ptr)
+ _Unwind_decode_typeinfo_ptr (_Unwind_Word base __attribute__ ((unused)),
+ _Unwind_Word ptr)
{
_Unwind_Word tmp;
@@ -65,7 +66,9 @@
}
static inline _Unwind_Reason_Code
- __gnu_unwind_24bit (_Unwind_Context * context, _uw data, int compact)
+ __gnu_unwind_24bit (_Unwind_Context * context __attribute__ ((unused)),
+ _uw data __attribute__ ((unused)),
+ int compact __attribute__ ((unused)))
{
return _URC_FAILURE;
}
[patch] [libstdc++] Fix build failure with --enable-libstdcxx-debug
Seen with a x86_64 x arm x arm cross build and --enable-libstdcxx-debug. The ../config.h should not be hard-coded. Using the macro guarantees that the rewritten macros for the debug builds are used. However I fail to see why the unpatched version does work for the native build. Ok for the trunk and the 4.7 branch? Matthias
Re: [patch] [libstdc++] Fix build failure with --enable-libstdcxx-debug
Am 10.12.2012 08:19, schrieb Matthias Klose: Seen with a x86_64 x arm x arm cross build and --enable-libstdcxx-debug. The ../config.h should not be hard-coded. Using the macro guarantees that the rewritten macros for the debug builds are used. However I fail to see why the unpatched version does work for the native build. Ok for the trunk and the 4.7 branch? and attaching the patch ... # DP: Fix cross build failure with --enable-libstdcxx-debug. * src/Makefile.am (libstdc++-symbols.ver): Use CONFIG_HEADER. * src/Makefile.in: Regenerate. --- libstdc++-v3/src/Makefile.am~ 2012-12-09 11:55:15.357516806 +0100 +++ libstdc++-v3/src/Makefile.am 2012-12-09 14:48:31.545377728 +0100 @@ -213,7 +213,7 @@ fi; \ fi $(EGREP) -v '^[ ]*#(#| |$$)' $@.tmp | \ - $(CC) -E -P -include ../config.h - $@ || (rm -f $@ ; exit 1) + $(CC) -E -P -include $(CONFIG_HEADER) - $@ || (rm -f $@ ; exit 1) rm -f $@.tmp CLEANFILES = libstdc++-symbols.ver
[patch] don't build multilib libraries during bootstrap, and disable some libstdc++ features
During bootstrap some things are built which are not required for the bootstrap:
- multilib libraries
- libstdc++ debug library, when configured with --enable-libstdcxx-debug
- libstdc++ precompiled header files
The attached patch disables building these during the bootstrap stages. The
additional dependencies on all-target-libgcc are necessary for multilib'd
builds, or else the configury bails out finding the wrong libgcc. I can't see a
way to add these dependencies for the multilib enabled build only.
Ok for the trunk?
Matthias
* Makefile.tpl (configure-stage[+id+]-[+prefix+][+module+]): Pass
bootstrap_configure_flags.
* Makefile.def (target_modules): Pass bootstrap_configure_flags
for libgcc, libgomp, libstdc++-v3.
(dependencies): For all target libraries, depend on all-target-libgcc.
--- Makefile.tpl~ 2012-11-29 17:44:18.0 +0100
+++ Makefile.tpl 2012-12-10 12:03:00.716683469 +0100
@@ -1060,7 +1060,9 @@
--target=[+target_alias+] $${srcdiroption} [+ IF prev +]\
--with-build-libsubdir=$(HOST_SUBDIR) [+ ENDIF prev +]\
$(STAGE[+id+]_CONFIGURE_FLAGS)[+ IF extra_configure_flags +] \
- [+extra_configure_flags+][+ ENDIF extra_configure_flags +]
+ [+extra_configure_flags+][+ ENDIF extra_configure_flags +] \
+ [+ IF bootstrap_configure_flags +][+bootstrap_configure_flags+] \
+ [+ ENDIF bootstrap_configure_flags +]
@endif [+prefix+][+module+]-bootstrap
[+ ENDFOR bootstrap_stage +]
[+ ENDIF bootstrap +]
--- Makefile.def~ 2012-12-01 22:34:06.0 +0100
+++ Makefile.def 2012-12-10 12:51:08.444647333 +0100
@@ -117,12 +117,14 @@
target_modules = { module= libstdc++-v3;
bootstrap=true;
lib_path=src/.libs;
- raw_cxx=true; };
+ raw_cxx=true;
+ bootstrap_configure_flags='--disable-multilib --disable-libstdcxx-debug --disable-libstdcxx-pch'; };
target_modules = { module= libmudflap; lib_path=.libs; };
target_modules = { module= libsanitizer; lib_path=.libs; };
target_modules = { module= libssp; lib_path=.libs; };
target_modules = { module= newlib; };
-target_modules = { module= libgcc; bootstrap=true; no_check=true; };
+target_modules = { module= libgcc; bootstrap=true; no_check=true;
+ bootstrap_configure_flags='--disable-multilib'; };
target_modules = { module= libbacktrace; };
target_modules = { module= libquadmath; };
target_modules = { module= libgfortran; };
@@ -142,7 +144,8 @@
target_modules = { module= boehm-gc; };
target_modules = { module= rda; };
target_modules = { module= libada; };
-target_modules = { module= libgomp; bootstrap= true; lib_path=.libs; };
+target_modules = { module= libgomp; bootstrap= true; lib_path=.libs;
+ bootstrap_configure_flags='--disable-multilib'; };
target_modules = { module= libitm; lib_path=.libs; };
target_modules = { module= libatomic; lib_path=.libs; };
@@ -504,6 +507,19 @@
dependencies = { module=configure-target-libobjc; on=configure-target-boehm-gc; };
dependencies = { module=all-target-libobjc; on=all-target-boehm-gc; };
dependencies = { module=configure-target-libstdc++-v3; on=configure-target-libgomp; };
+dependencies = { module=configure-target-libada; on=all-target-libgcc; };
+dependencies = { module=configure-target-libatomic; on=all-target-libgcc; };
+dependencies = { module=configure-target-libbacktrace; on=all-target-libgcc; };
+dependencies = { module=configure-target-libdecnumber; on=all-target-libgcc; };
+dependencies = { module=configure-target-libffi; on=all-target-libgcc; };
+dependencies = { module=configure-target-libgfortran; on=all-target-libgcc; };
+dependencies = { module=configure-target-libgomp; on=all-target-libgcc; };
+dependencies = { module=configure-target-libitm; on=all-target-libgcc; };
+dependencies = { module=configure-target-libmudflap; on=all-target-libgcc; };
+dependencies = { module=configure-target-libquadmath; on=all-target-libgcc; };
+dependencies = { module=configure-target-libssp; on=all-target-libgcc; };
+dependencies = { module=configure-target-libstdc++-v3; on=all-target-libgcc; };
+dependencies = { module=configure-target-zlib; on=all-target-libgcc; };
dependencies = { module=configure-target-libsanitizer; on=all-target-libstdc++-v3; };
// parallel_list.o and parallel_settings.o depend on omp.h, which is
// generated by the libgomp configure. Unfortunately, due to the use of
Re: [patch] don't build multilib libraries during bootstrap, and disable some libstdc++ features
Am 10.12.2012 13:16, schrieb Matthias Klose:
During bootstrap some things are built which are not required for the
bootstrap:
- multilib libraries
- libstdc++ debug library, when configured with --enable-libstdcxx-debug
- libstdc++ precompiled header files
The attached patch disables building these during the bootstrap stages. The
additional dependencies on all-target-libgcc are necessary for multilib'd
builds, or else the configury bails out finding the wrong libgcc. I can't see
a
way to add these dependencies for the multilib enabled build only.
Here is a reduced version which keeps building the multilibs, maybe better
suited for stage3.
Matthias
Index: Makefile.tpl
===
--- Makefile.tpl (Revision 194357)
+++ Makefile.tpl (Arbeitskopie)
@@ -1060,7 +1060,9 @@
--target=[+target_alias+] $${srcdiroption} [+ IF prev +]\
--with-build-libsubdir=$(HOST_SUBDIR) [+ ENDIF prev +]\
$(STAGE[+id+]_CONFIGURE_FLAGS)[+ IF extra_configure_flags +] \
- [+extra_configure_flags+][+ ENDIF extra_configure_flags +]
+ [+extra_configure_flags+][+ ENDIF extra_configure_flags +] \
+ [+ IF bootstrap_configure_flags +][+bootstrap_configure_flags+] \
+ [+ ENDIF bootstrap_configure_flags +]
@endif [+prefix+][+module+]-bootstrap
[+ ENDFOR bootstrap_stage +]
[+ ENDIF bootstrap +]
Index: Makefile.def
===
--- Makefile.def (Revision 194357)
+++ Makefile.def (Arbeitskopie)
@@ -117,7 +117,8 @@
target_modules = { module= libstdc++-v3;
bootstrap=true;
lib_path=src/.libs;
- raw_cxx=true; };
+ raw_cxx=true;
+ bootstrap_configure_flags='--disable-libstdcxx-debug --disable-libstdcxx-pch'; };
target_modules = { module= libmudflap; lib_path=.libs; };
target_modules = { module= libsanitizer; lib_path=.libs; };
target_modules = { module= libssp; lib_path=.libs; };
Re: application/xml mime-type in recent libstdc++ doc changes
Am 10.12.2012 18:52, schrieb Benjamin De Kosnik: libstdc++-v3/doc/xsl/customization.xsl.in is marked as svn:mime-type = application/xml at least on the 4.7 branch, having some unexpected outcome for svn diff. If this was unintended, could you change the svn:mime-type back to text? This is unintentional, and frankly I don't know how the inital mime type was created or how to fix it. Any pointers? Can you do it and tell me how? I did a 'svn propset svn:mime-type text/xml customization.xsl.in', both on the branch and the trunk. text/xml is the default mime-type for *.xsl files. The file now appears in svn diff output. Matthias
Re: [PATCH] PR go/55201: Link libgo against libatomic
Am 18.12.2012 15:28, schrieb Ian Lance Taylor: On Mon, Dec 17, 2012 at 2:26 PM, Andreas Schwab sch...@linux-m68k.org wrote: Since libgo uses 8-byte atomic operations it needs to link against libatomic. Tested on m68k-linux and powerpc-linux. Andreas. PR go/55201 * Makefile.def (all-target-libgo): Depend on all-target-libatomic. * Makefile.in: Regenerate. testsuite/: * lib/go.exp (go_link_flags): Add libatomic location to flags and ld_library_path. Thanks. Committed to mainline. this seems to break make install, at least for a multilib enabled build. /usr/bin/ld: cannot find -latomic collect2: error: ld returned 1 exit status libtool: install: error: relink `libgo.la' with the above command before installing it make[10]: *** [install-toolexeclibLTLIBRARIES] Error 1 make[10]: Leaving directory `/home/packages/gcc/4.8/gcc-4.8-4.8-20121218/build/x86_64-linux-gnu/32/libgo' test -z /usr/lib/../lib32 || /bin/mkdir -p /home/packages/gcc/4.8/gcc-4.8-4.8-20121218/debian/tmp/usr/lib/../lib32 /usr/bin/install -c -m 644 libgobegin.a '/home/packages/gcc/4.8/gcc-4.8-4.8-20121218/debian/tmp/usr/lib/../lib32' ( cd '/home/packages/gcc/4.8/gcc-4.8-4.8-20121218/debian/tmp/usr/lib/../lib32' ranlib libgobegin.a ) test -z /usr/lib/../lib32 || /bin/mkdir -p /home/packages/gcc/4.8/gcc-4.8-4.8-20121218/debian/tmp/usr/lib/../lib32 /bin/bash ./libtool --mode=install /usr/bin/install -c libgo.la '/home/packages/gcc/4.8/gcc-4.8-4.8-20121218/debian/tmp/usr/lib/../lib32' libtool: install: warning: relinking `libgo.la' libtool: install: (cd /home/packages/gcc/4.8/gcc-4.8-4.8-20121218/build/x86_64-linux-gnu/32/libgo; /bin/bash /home/packages/gcc/4.8/gcc-4.8-4.8-20121218/build/x86_64-linux-gnu/32/libgo/libtool --tag CC --mode=relink /home/packages/gcc/4.8/gcc-4.8-4.8-20121218/build/./gcc/xgcc -B/home/packages/gcc/4.8/gcc-4.8-4.8-20121218/build/./gcc/ -B/usr/x86_64-linux-gnu/bin/ -B/usr/x86_64-linux-gnu/lib/ -isystem /usr/x86_64-linux-gnu/include -isystem /usr/x86_64-linux-gnu/sys-include -isystem /home/packages/gcc/4.8/gcc-4.8-4.8-20121218/build/sys-include -m32 -fexceptions -fplan9-extensions -fsplit-stack -Wall -Wextra -Wwrite-strings -Wcast-qual -Werror -minline-all-stringops -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I ../../../../src/libgo/../libgcc -I ../../../../src/libgo/../libbacktrace -I ../../../gcc/include -g -O2 -m32 -version-info 3:1:0 -pthread -XCClinker -fsplit-stack -m32 -o libgo.la -rpath /usr/lib/../lib32 go-append.lo go-assert.lo go-assert-interface.lo go-byte-array-to-string.lo go-breakpoint.lo go-caller.lo go-callers.lo go-can-convert-interface.lo go-cgo.lo go-check-interface.lo go-construct-map.lo go-convert-interface.lo go-copy.lo go-defer.lo go-deferred-recover.lo go-eface-compare.lo go-eface-val-compare.lo go-fieldtrack.lo go-getgoroot.lo go-int-array-to-string.lo go-int-to-string.lo go-interface-compare.lo go-interface-eface-compare.lo go-interface-val-compare.lo go-make-slice.lo go-map-delete.lo go-map-index.lo go-map-len.lo go-map-range.lo go-matherr.lo go-memcmp.lo go-nanotime.lo go-now.lo go-new-map.lo go-new.lo go-nosys.lo go-panic.lo go-print.lo go-recover.lo go-reflect-call.lo go-reflect-map.lo go-rune.lo go-runtime-error.lo go-setenv.lo go-signal.lo go-strcmp.lo go-string-to-byte-array.lo go-string-to-int-array.lo go-strplus.lo go-strslice.lo go-traceback.lo go-trampoline.lo go-type-complex.lo go-type-eface.lo go-type-error.lo go-type-float.lo go-type-identity.lo go-type-interface.lo go-type-string.lo go-typedesc-equal.lo go-typestring.lo go-unsafe-new.lo go-unsafe-newarray.lo go-unsafe-pointer.lo go-unwind.lo chan.lo cpuprof.lo lfstack.lo lock_futex.lo thread-linux.lo mcache.lo mcentral.lo mem.lo mfinal.lo mfixalloc.lo mgc0.lo mheap.lo msize.lo panic.lo parfor.lo print.lo proc.lo runtime.lo signal_unix.lo thread.lo yield.lo iface.lo malloc.lo map.lo mprof.lo reflect.lo runtime1.lo sema.lo sigqueue.lo string.lo time.lo getncpu-linux.lo bufio.lo bytes.lo bytes/index.lo crypto.lo errors.lo expvar.lo flag.lo fmt.lo hash.lo html.lo image.lo io.lo log.lo math.lo mime.lo net.lo os.lo path.lo reflect-go.lo regexp.lo runtime-go.lo sort.lo strconv.lo strings.lo sync.lo syscall.lo syscall/errno.lo syscall/signame.lo syscall/wait.lo testing.lo time-go.lo unicode.lo archive/tar.lo archive/zip.lo compress/bzip2.lo compress/flate.lo compress/gzip.lo compress/lzw.lo compress/zlib.lo container/heap.lo container/list.lo container/ring.lo crypto/aes.lo crypto/cipher.lo crypto/des.lo crypto/dsa.lo crypto/ecdsa.lo crypto/elliptic.lo crypto/hmac.lo crypto/md5.lo crypto/rand.lo crypto/rc4.lo crypto/rsa.lo crypto/sha1.lo crypto/sha256.lo crypto/sha512.lo crypto/subtle.lo crypto/tls.lo crypto/x509.lo crypto/x509/pkix.lo database/sql.lo database/sql/driver.lo debug/dwarf.lo debug/elf.lo debug/gosym.lo debug/macho.lo debug/pe.lo encoding/ascii85.lo encoding/asn1.lo encoding/base32.lo
Re: PATCH RFA: PR go/55201: Create libatomic convenience library
Am 19.12.2012 01:28, schrieb Ian Lance Taylor:
On Tue, Dec 18, 2012 at 3:15 PM, Richard Henderson r...@redhat.com wrote:
On 12/18/2012 02:52 PM, Ian Lance Taylor wrote:
Argh. But why? Wouldn't that only apply to cases where the lock was
sometimes locked by one library and sometimes locked by a different
one?
Or did you really mean
... only apply to cases where the memory protected by the lock
was visible to more than one library.
Yes, if libgo is attempting atomic accesses to its own data structures,
which themselves are not exported from libgo, then a copy of libatomic
ought to work.
It would probably be better for the shared libgo to depend on the
shared libatomic though. That's simply more pedantically correct.
But according to Matthias's comment upthread, it would require
addressing some issue in libtool in order to get multilib working
correctly.
I'm not going to try to solve this today, but if somebody else wants
to that would be great.
you cannot reproduce this, if you already have libatomic.so.1 installed into
your destination/installation path. You should be able to reproduce this by
installing into an empty destination (maybe using DESTDIR). Then libgo can't
find the libatomic. calling make install-target-libatomic and then re-running
lets make install succeed.
Makefile.def doesn't define any dependencies on the installation targets,
however seldom people run make install with -j, and then the order the
target_modules are listed matters. libatomic comes behind the libgo target, otoh
libquadmath comes before libgfortran and installs without issues.
The following patch fixes this for me, maybe other target library dependencies
should be added too.
that would be for
libgfortran on libquadmath, libgcc
libsanitizer on libstdc++
libstdc++ on libgomp, libgcc
libjava on libstdc++, libgcc
libasan on libgcc
libobjc on libgcc
libitm on libgcc
Matthias
Index: Makefile.def
===
--- Makefile.def(Revision 194604)
+++ Makefile.def(Arbeitskopie)
@@ -514,6 +514,8 @@
// recursive make, we can't be that specific.
dependencies = { module=all-target-libstdc++-v3; on=configure-target-libgomp;
};
+dependencies = { module=install-target-libgo; on=install-target-libatomic; };
+
// Target modules in the 'src' repository.
lang_env_dependencies = { module=libtermcap; };
lang_env_dependencies = { module=rda; };
[patch] Fix typo in multiarch definition for kfreebsd
Fixes a typo in the multiarch definition for kfreebsd. Committed as obvious. Matthias 2012-12-19 Matthias Klose d...@ubuntu.com * config/i386/t-kfreebsd (MULTIARCH_DIRNAME): Add comma to separate arguments in make function. Index: config/i386/t-kfreebsd === --- config/i386/t-kfreebsd (Revision 194615) +++ config/i386/t-kfreebsd (Arbeitskopie) @@ -2,4 +2,4 @@ # MULTILIB_OSDIRNAMES are set in t-linux64. KFREEBSD_OS = $(filter kfreebsd%, $(word 3, $(subst -, ,$(target -MULTILIB_OSDIRNAMES := $(filter-out mx32=% $(subst linux,$(KFREEBSD_OS),$(MULTILIB_OSDIRNAMES))) +MULTILIB_OSDIRNAMES := $(filter-out mx32=%,$(subst linux,$(KFREEBSD_OS),$(MULTILIB_OSDIRNAMES)))
[patch] fix multiarch definition for powerpcspe-linux-gnu
The definition of the multiarch tuple for powerpcspe-linux-gnu was wrong. The t-spe fragment isn't included for the powerpc*-linux* case, so move it to t-linux, and use tm_file_list (tm_file is only used in config.gcc). Ok for the trunk? Matthias 2012-12-19 Roland Stigge sti...@debian.org Matthias Klose d...@ubuntu.com * config/rs6000/t-spe (MULTIARCH_DIRNAME): Remove. * config/rs6000/t-linux (MULTIARCH_DIRNAME): Define name for powerpc-linux-gnuspe. Index: config/rs6000/t-spe === --- config/rs6000/t-spe (Revision 194615) +++ config/rs6000/t-spe (Arbeitskopie) @@ -71,7 +71,3 @@ mabi=altivec/mlittle \ maltivec/mlittle \ maltivec/mabi=altivec/mlittle - -ifneq (,$(findstring linux, $(target))) -MULTIARCH_DIRNAME = powerpc-linux-gnuspe$(if $(findstring rs6000/e500-double.h, $(tm_file)),,v1) -endif Index: config/rs6000/t-linux === --- config/rs6000/t-linux (Revision 194615) +++ config/rs6000/t-linux (Arbeitskopie) @@ -1,5 +1,9 @@ # do not define the multiarch name if configured for a soft-float cpu # or soft-float. ifeq (,$(filter $(with_cpu),$(SOFT_FLOAT_CPUS))$(findstring soft,$(with_float))) +ifneq (,$(findstring spe,$(target))) +MULTIARCH_DIRNAME = powerpc-linux-gnuspe$(if $(findstring rs6000/e500-double.h, $(tm_file_list)),,v1) +else MULTIARCH_DIRNAME = powerpc-linux-gnu endif +endif
[patch] fix install dependencies for target libraries
This was seen with the libgo installation [1], but from my point of view can
happen when the install target is called with -j 1, libtool seems to fall back
to the system libraries if the library in the install location is not available
(which is always the case if you install into an empty dir set with DESTDIR).
Currently it just works for a non-parallel install because the dependencies in
Makefile.def are created in the right order.
Ok for the trunk?
Matthias
[1] http://gcc.gnu.org/ml/gcc-patches/2012-12/msg01192.html
2012-12-20 Matthias Klose d...@ubuntu.com
* Makefile.def (install-target-libgfortran): Depend on
install-target-libquadmath, install-target-libgcc.
(install-target-libsanitizer): Depend on install-target-libgcc.
(install-target-libjava): Depend on install-target-libgcc.
(install-target-libitm): Depend on install-target-libgcc.
(install-target-libobjc): Depend on install-target-libgcc.
(install-target-libstdc++-v3): Depend on install-target-libgcc.
* Makefile.in: Regenerate.
Index: Makefile.def
===
--- Makefile.def (Revision 194635)
+++ Makefile.def (Arbeitskopie)
@@ -515,6 +515,13 @@
dependencies = { module=all-target-libstdc++-v3; on=configure-target-libgomp; };
dependencies = { module=install-target-libgo; on=install-target-libatomic; };
+dependencies = { module=install-target-libgfortran; on=install-target-libquadmath; };
+dependencies = { module=install-target-libgfortran; on=install-target-libgcc; };
+dependencies = { module=install-target-libsanitizer; on=install-target-libgcc; };
+dependencies = { module=install-target-libjava; on=install-target-libgcc; };
+dependencies = { module=install-target-libitm; on=install-target-libgcc; };
+dependencies = { module=install-target-libobjc; on=install-target-libgcc; };
+dependencies = { module=install-target-libstdc++-v3; on=install-target-libgcc; };
// Target modules in the 'src' repository.
lang_env_dependencies = { module=libtermcap; };
Re: [patch] fix install dependencies for target libraries
Am 20.12.2012 20:11, schrieb Ian Lance Taylor: On Thu, Dec 20, 2012 at 10:22 AM, Matthias Klose d...@ubuntu.com wrote: This was seen with the libgo installation [1], but from my point of view can happen when the install target is called with -j 1, libtool seems to fall back to the system libraries if the library in the install location is not available (which is always the case if you install into an empty dir set with DESTDIR). Currently it just works for a non-parallel install because the dependencies in Makefile.def are created in the right order. Ok for the trunk? This is OK with a ChangeLog entry. committed, with the ChangeLog entry from the original mail. Matthias
[patch] fix relinking libasan and libtsan on installation
with the recent libsanitizer update, libasan and libtsan got a dependency on
libstdc++.so.6, however when installing into an empty directory, and
libstdc++.so.6 isn't installed there first, both libasan and libtsan are
relinked against the system libstdc++.so.6. So make sure that libstdc++-v3 is
installed first.
ok for the trunk?
Matthias
2013-01-13 Matthias Klose d...@ubuntu.com
* Makefile.def (install-target-libsanitizer): Depend on
install-target-libstdc++-v3.
* Makefile.in: Regenerate.
Index: Makefile.def
===
--- Makefile.def (Revision 195136)
+++ Makefile.def (Arbeitskopie)
@@ -524,6 +524,7 @@
dependencies = { module=install-target-libgo; on=install-target-libatomic; };
dependencies = { module=install-target-libgfortran; on=install-target-libquadmath; };
dependencies = { module=install-target-libgfortran; on=install-target-libgcc; };
+dependencies = { module=install-target-libsanitizer; on=install-target-libstdc++-v3; };
dependencies = { module=install-target-libsanitizer; on=install-target-libgcc; };
dependencies = { module=install-target-libjava; on=install-target-libgcc; };
dependencies = { module=install-target-libitm; on=install-target-libgcc; };
Index: Makefile.in
===
--- Makefile.in (Revision 195136)
+++ Makefile.in (Arbeitskopie)
@@ -46216,6 +46216,7 @@
install-target-libgo: maybe-install-target-libatomic
install-target-libgfortran: maybe-install-target-libquadmath
install-target-libgfortran: maybe-install-target-libgcc
+install-target-libsanitizer: maybe-install-target-libstdc++-v3
install-target-libsanitizer: maybe-install-target-libgcc
install-target-libjava: maybe-install-target-libgcc
install-target-libitm: maybe-install-target-libgcc
[patch] --with-build-sysroot requires --with-sysroot
this is documented in doc/install.texi:
This option is only useful when you are already using
@option{--with-sysroot}.
now, lets error out if you configure --with-build-sysroot without
--with-sysroot. Ok for the trunk?
This was hit in PR55743. I think the patch in
http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00198.html is still valid, but
independent of this.
Matthias
gcc/
2013-01-14 Matthias Klose d...@ubuntu.com
* configure.ac: fail --with-build-sysroot without --with-sysroot.
* configure: Regenerate.
Index: gcc/configure.ac
===
--- gcc/configure.ac (Revision 195151)
+++ gcc/configure.ac (Arbeitskopie)
@@ -755,15 +755,6 @@
configured_native_system_header_dir=${withval}
], [configured_native_system_header_dir=])
-AC_ARG_WITH(build-sysroot,
- [AS_HELP_STRING([--with-build-sysroot=sysroot],
- [use sysroot as the system root during the build])],
- [if test x$withval != x ; then
- SYSROOT_CFLAGS_FOR_TARGET=--sysroot=$withval
- fi],
- [SYSROOT_CFLAGS_FOR_TARGET=])
-AC_SUBST(SYSROOT_CFLAGS_FOR_TARGET)
-
if test x$prefix = xNONE; then
test_prefix=/usr/local
else
@@ -805,6 +796,19 @@
AC_SUBST(TARGET_SYSTEM_ROOT_DEFINE)
AC_SUBST(CROSS_SYSTEM_HEADER_DIR)
+AC_ARG_WITH(build-sysroot,
+ [AS_HELP_STRING([--with-build-sysroot=sysroot],
+ [use sysroot as the system root during the build])],
+ [if test x$withval != x ; then
+ SYSROOT_CFLAGS_FOR_TARGET=--sysroot=$withval
+ fi],
+ [SYSROOT_CFLAGS_FOR_TARGET=])
+AC_SUBST(SYSROOT_CFLAGS_FOR_TARGET)
+if test x$TARGET_SYSTEM_ROOT = x test x$SYSROOT_CFLAGS_FOR_TARGET != x
+then
+ AC_MSG_ERROR([option --with-build-sysroot requires --with-sysroot])
+fi
+
AC_ARG_WITH(specs,
[AS_HELP_STRING([--with-specs=SPECS],
[add SPECS to driver command-line processing])],
Re: [PATCH] Remove unnecessaily included limits.h in libgcc2.c
Am 04.01.2013 20:01, schrieb Wookey: I filed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55743 (my first upstream gcc bug so be gentle :-) Details are there but the short version is that the limits.h inclusion in libgcc2.c is now a relic because the constants that it brings in are no longer used (since http://repo.or.cz/w/official-gcc.git/blobdiff/49f0f270673c4512c11f72a038b84c321ae5534a..7429c938827aa98bf3b02c4ac89510f4d28ef0b1:/gcc/libgcc2.c ) And this inclusion can break --without-headers bootstrapping (which is how I noticed it). Doko poked me to send the patch to this list for consideration for inclusion in trunk. The --without-headers build failures is unrelated. To catch this mis-configuration I did propose a patch in http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00743.html I think the patch itself is correct. However - please submit your patch against trunk, and state that you did test the patch against trunk (of course, after testing it) - please provide a ChangeLog entry - thanks for your reference to the repo.or.cz repo, however it would be good to reference a GCC commit. looks like Alexandre Oliva did commit this without removing the unneeded bits in r39365. Matthias
[patch] libmudflap: check for NULL path in dlopen wrapper
From the bug report:
If mudflap is used to instrument a program using dlopen, and the program
(assuming it is compiled with -rdynamic) loads itself by passing NULL for the
path to dlopen, the program will crash unconditionally; that is, regardless of
the options passed to mudflap, so long as instrumentation is enabled.
This is because (at least with GNU/Linux) it is valid to pass a NULL pointer as
the path argument to dlopen, and the instrumentation code unconditionally uses
strlen on that pointer, without checking first if it is NULL.
Ok for the trunk?
Matthias
PR mudflap/24619
* mf-hooks2.c (dlopen wrapper): Check for NULL path.
Index: b/src/libmudflap/mf-hooks2.c
===
--- a/libmudflap/mf-hooks2.c
+++ b/libmudflap/mf-hooks2.c
@@ -1677,8 +1677,10 @@
size_t n;
TRACE (%s\n, __PRETTY_FUNCTION__);
n = strlen (path);
- MF_VALIDATE_EXTENT (path, CLAMPADD(n, 1), __MF_CHECK_READ, dlopen path);
- p = dlopen (path, flags);
+ if (NULL != path) {
+MF_VALIDATE_EXTENT (path, CLAMPADD(n, 1), __MF_CHECK_READ, dlopen path);
+p = dlopen (path, flags);
+ }
if (NULL != p) {
#ifdef MF_REGISTER_dlopen
__mf_register (p, 0, MF_REGISTER_dlopen, dlopen result);
Re: [PATCH, ARM] New CPU support for Marvell PJ4 cores
Am 18.01.2013 15:28, schrieb Ramana Radhakrishnan: On 06/20/12 03:53, Yi-Hsiu Hsu wrote: marvell-pj4 is added to BE8_LINK_SPEC. Sorry about the time it's taken to finish this patch up. I seem to have missed this one in the review process. I've now applied the attached patch after taking into account the recent attribute changes and treated alu_reg and simple_alu_imm as you have treated alu, rebased to trunk to fix up some small issues with BE8_LINK_SPECS. Additionally I've removed tune_marvell as that seems redundant at this point of time - an additional attribute and testing that appears to be unnecessary instead of just one more inequality test. The only part I'm not sure about is how to treat the simple_alu_shift category here , so a patch to handle them in the pj4 pipeline description would be welcome. Thanks Ramana 2013-01-18 Yi-Hsiu Hsu a...@marvell.com Ramana Radhakrishnan ramana.radhakrish...@arm.com * config/arm/marvell-pj4.md: New file. * config/arm/arm.c (arm_issue_rate): Add marvell_pj4. * config/arm/arm.md (generic_sched): Add marvell_pj4. (generic_vfp): Likewise. * config/arm/arm-cores.def: Add marvell-pj4. * config/arm/arm-tune.md: Regenerate. * config/arm/arm-tables.opt: Regenerate. * config/arm/bpabi.h (BE8_LINK_SPEC): Add marvell_pj4. * doc/invoke.texi: Document marvell-pj4. Modified patch is attached. the patch was missing the new file config/arm/marvell-pj4.md. Checked is as obvious to restore the bootstrap. Matthias
[patch] [libffi] do not install libffi library, headers and documentation
The libffi library, headers and documentation are still installed, although libffi provides separate releases for a long time. So do not install these anymore as part of a GCC install. Tested with a build and an install with go and java enabled (both using libffi_convenience). Ok for the trunk? Matthias 2013-02-12 Matthias Klose d...@ubuntu.com * Makefile.am: Do not install texinfo documentation and the libffi library. * include/Makefile.am: Do not install header files. * man/Makefile.am: Do not install man pages. * Makefile.in, include/Makefile.in, man/Makefile.in: Regenerate. Index: Makefile.am === --- Makefile.am (Revision 195973) +++ Makefile.am (Arbeitskopie) @@ -49,7 +49,7 @@ # Defines info, dvi, pdf and html targets MAKEINFOFLAGS = -I $(srcdir)/../gcc/doc/include -info_TEXINFOS = doc/libffi.texi +noinst_info_TEXINFOS = doc/libffi.texi # AM_CONDITIONAL on configure option --generated-files-in-srcdir if GENINSRC @@ -130,8 +130,7 @@ MAKEOVERRIDES= -toolexeclib_LTLIBRARIES = libffi.la -noinst_LTLIBRARIES = libffi_convenience.la +noinst_LTLIBRARIES = libffi.la libffi_convenience.la libffi_la_SOURCES = src/prep_cif.c src/types.c \ src/raw_api.c src/java_raw_api.c src/closures.c Index: include/Makefile.am === --- include/Makefile.am (Revision 195973) +++ include/Makefile.am (Arbeitskopie) @@ -9,4 +9,4 @@ gcc_version := $(shell cat $(top_srcdir)/../gcc/BASE-VER) toollibffidir := $(libdir)/gcc/$(target_alias)/$(gcc_version)/include -toollibffi_HEADERS = ffi.h ffitarget.h +noinst_HEADERS = ffi.h ffitarget.h Index: man/Makefile.am === --- man/Makefile.am (Revision 195973) +++ man/Makefile.am (Arbeitskopie) @@ -4,5 +4,5 @@ EXTRA_DIST = ffi.3 ffi_call.3 ffi_prep_cif.3 ffi_prep_cif_var.3 -man_MANS = ffi.3 ffi_call.3 ffi_prep_cif.3 ffi_prep_cif_var.3 +noinst_man_MANS = ffi.3 ffi_call.3 ffi_prep_cif.3 ffi_prep_cif_var.3
Re: [DOC PATCH] Add -Wunused-but-set-* note to gcc-4.6/changes.html and mention removal of cstddef in STL headers
On 10.03.2011 17:04, Jakub Jelinek wrote: +default by code-Wall/code flag and code-Wunused-but-set-parameter/code +by code-Wall -W/code flags./li -W is documented as old option. Maybe use -Wextra instead? Matthias
Re: [2/2] Reducing the overhead of dwarf2 location tracking
On 05.03.2011 15:37, Richard Sandiford wrote: Jakub Jelinek ja...@redhat.com writes: On Fri, Mar 04, 2011 at 01:56:55PM +, Richard Sandiford wrote: * dwarf2out.c (dw_loc_list_node): Add resolved_addr and replaced. (cached_dw_loc_list_def): New structure. (cached_dw_loc_list): New typedef. (cached_dw_loc_list_table): New variable. (cached_dw_loc_list_table_hash): New function. (cached_dw_loc_list_table_eq): Likewise. (add_location_or_const_value_attribute): Take a bool cache_p. Cache the list when the parameter is true. (gen_formal_parameter_die): Update caller. (gen_variable_die): Likewise. (dwarf2out_finish): Likewise. (dwarf2out_function_decl): Clear cached_dw_loc_list_table. (dwarf2out_init): Initialize cached_dw_loc_list_table. (resolve_addr): Cache the result of resolving a chain of location lists. I think you should handle the cached_dw_loc_list_table in dwarf2out_abstract_function similarly to say decl_loc_table, i.e. save/clear for the duration of the of recursive dwarf2out_decl call, restore afterwards and in the places where you actually use it guard it also with cached_dw_loc_list_table != NULL. OK, thanks for the pointer. How does this look? Bootstrapped regression-tested on x86_64-linux-gnu. tested with 4.6.0 on x86, x86_64 and arm-linux-genueabi without seeing regressions. Matthias
Re: [patch] make default linker --hash-style configurable option
On 04.04.2011 20:17, Paul Pluzhnikov wrote: Greetings, Several Linux distributions (e.g. Fedora) carry local patches that turn on --hash-style=gnu for all links. Attached is a proposed patch (originally by Satoru Takabayashi) that makes default hash style a configure option. Tested by doing native bootstrap and verifying that no --hash-style is passed to the linker, and also configuring with --with-linker-hash-style=gnu and verifying that --hash-style=gnu is then passed to the linker. Linux distributions pass more than that by default to the linker, e.g. --as-needed and --no-copy-dt-needed-entries. Wouldn't it make more sense to add something like --with-linker-default-options=... ? Matthias
Re: [patch] C6X unwinding/exception handling
This did break libobjc and libjava on arm-linux-gnueabi. libobjc now has an undefined reference to _Unwind_decode_target2, which can be avoided with --- libobjc/exception.c.orig2011-07-21 15:33:57.0 + +++ libobjc/exception.c 2011-10-09 10:53:12.554940776 + @@ -182,7 +182,7 @@ _Unwind_Ptr ptr; ptr = (_Unwind_Ptr) (info-TType - (i * 4)); - ptr = _Unwind_decode_target2 (ptr); + ptr = _Unwind_decode_typeinfo_ptr (info-ttype_base, (_Unwind_Word) ptr); /* NULL ptr means catch-all. Note that if the class is not found, this will abort the program. */ libjava fails to build, the same change doesn't work for libjava/exception.cc, because the struct lsda_header_info in exception.cc is missing the ttype_base member. Any suggestions? On 09/13/2011 02:48 PM, Paul Brook wrote: C6X uses an unwinding/exception handling echeme very similar to that defined by the ARM EABI. The core of the unwinder is the same, so I've pulled it out into a common file. Other than the obvious target specific bits, the main compiler visible difference is that the C6X assembler generates the unwinding tables from DWARF .cfi directives, rather than the separate set of directives used by the ARM assembler. The libstdc++ changes probably deserve a bit of explanation. The ttype_base field was clearly used in an early draft of the ARM EABI, and the current ARM definition is a compatible subset of that used by C6X. _GLIBCXX_OVERRIDE_TTYPE_ENCODING is an unfortunate hack because when doing the ARM implementation I failed to realise ttype_encoding was the same thing as R_ARM_TARGET2. We now have a lot of ARM binaries floating around with that field set incorrectly, so it's either this or an ABI bump. I've updated the patch to accomodate the move to libgcc/, done a quick sanity recheck of arm-linux and c6x-elf and applied to svn. P.S. in case it's not clear from my description, the libstdc++ changes aren't really a new hack, it's just making an old one more obvious. Paul 2011-09-13 Paul Brook p...@codesourcery.com gcc/ * config/arm/arm.h (ASM_PREFERRED_EH_DATA_FORMAT): Define. (ARM_TARGET2_DWARF_FORMAT): Provide default definition. * config/arm/linux-eabi.h (ARM_TARGET2_DWARF_FORMAT): Define. * config/arm/symbian.h (ARM_TARGET2_DWARF_FORMAT): Define. * config/arm/uclinux-eabi.h(ARM_TARGET2_DWARF_FORMAT): Define. * config/arm/t-bpabi (EXTRA_HEADERS): Add unwind-arm-common.h. * config/arm/t-symbian (EXTRA_HEADERS): Add unwind-arm-common.h. * config/c6x/c6x.c (c6x_output_file_unwind): Don't rely on dwarf2 code enabling unwind tables. (c6x_debug_unwind_info): New function. (TARGET_ARM_EABI_UNWINDER): Define. (TARGET_DEBUG_UNWIND_INFO): Define. * config/c6x/c6x.h (DWARF_FRAME_RETURN_COLUMN): Define. (TARGET_EXTRA_CFI_SECTION): Remove. * config/c6x/t-c6x-elf (EXTRA_HEADERS): Set. * ginclude/unwind-arm-common.h: New file. libgcc/ * config.host (tic6x-*-*): Add c6x/t-c6x-elf. Set unwind_header. * unwind-c.c (PERSONALITY_FUNCTION): Use UNWIND_POINTER_REG. * unwind-arm-common.inc: New file. * config/arm/unwind-arm.c: Use unwind-arm-common.inc. * config/arm/unwind-arm.h: Use unwind-arm-common.h. (_GLIBCXX_OVERRIDE_TTYPE_ENCODING): Define. * config/c6x/libunwind.S: New file. * config/c6x/pr-support.c: New file. * config/c6x/unwind-c6x.c: New file. * config/c6x/unwind-c6x.h: New file. * config/c6x/t-c6x-elf: New file. libstdc++-v3/ * libsupc++/eh_arm.cc (__cxa_end_cleanup): Add C6X implementation. * libsupc++/eh_call.cc (__cxa_call_unexpected): Set rtti_base. * libsupc++/eh_personality.cc (NO_SIZE_OF_ENCODED_VALUE): Remove __ARM_EABI_UNWINDER__ check. (parse_lsda_header): Check _GLIBCXX_OVERRIDE_TTYPE_ENCODING. (get_ttype_entry): Use generic implementation on ARM EABI. (check_exception_spec): Use _Unwind_decode_typeinfo_ptr and UNWIND_STACK_REG. (PERSONALITY_FUNCTION): Set ttype_base.
[patch] remove empty directory common/config/m32c
2011-10-10 Matthias Klose d...@ubuntu.com * common/config/m32c: Remove empty directory. committed as obvious. the last file in this directory was removed in r175969.
Re: [patch] C6X unwinding/exception handling
On 10/10/2011 12:32 PM, Andrew Haley wrote:
On 10/09/2011 12:09 PM, Matthias Klose wrote:
This did break libobjc and libjava on arm-linux-gnueabi.
libobjc now has an undefined reference to _Unwind_decode_target2, which can
be
avoided with
with this patch, the libobjc testsuite results looks as before this change.
--- libobjc/exception.c.orig2011-07-21 15:33:57.0 +
+++ libobjc/exception.c 2011-10-09 10:53:12.554940776 +
@@ -182,7 +182,7 @@
_Unwind_Ptr ptr;
ptr = (_Unwind_Ptr) (info-TType - (i * 4));
- ptr = _Unwind_decode_target2 (ptr);
+ ptr = _Unwind_decode_typeinfo_ptr (info-ttype_base, (_Unwind_Word) ptr);
/* NULL ptr means catch-all. Note that if the class is not found,
this will abort the program. */
libjava fails to build, the same change doesn't work for
libjava/exception.cc,
because the struct lsda_header_info in exception.cc is missing the ttype_base
member. Any suggestions?
Is this fixable without backing out Paul Brooks' patch?
currently testing
Index: libjava/exception.cc
===
--- libjava/exception.cc(revision 179739)
+++ libjava/exception.cc(working copy)
@@ -135,6 +135,7 @@
{
_Unwind_Ptr Start;
_Unwind_Ptr LPStart;
+ _Unwind_Ptr ttype_base;
const unsigned char *TType;
const unsigned char *action_table;
unsigned char ttype_encoding;
@@ -184,7 +185,7 @@
_Unwind_Ptr ptr;
ptr = (_Unwind_Ptr) (info-TType - (i * 4));
- ptr = _Unwind_decode_target2(ptr);
+ ptr = _Unwind_decode_typeinfo_ptr (info-ttype_base, (_Unwind_Word) ptr);
return reinterpret_castvoid **(ptr);
}
@@ -325,6 +326,7 @@
// Parse the LSDA header.
p = parse_lsda_header (context, language_specific_data, info);
+ info.ttype_base = base_of_encoded_value (info.ttype_encoding, context);
#ifdef HAVE_GETIPINFO
ip = _Unwind_GetIPInfo (context, ip_before_insn);
#else
[patch, libgo] remove empty directories
libgo currently has some empty directories. ok to remove? D go/encoding/line D go/exp/ogle D go/exp/eval D go/exp/draw D go/exp/draw/x11
[patch] remove empty directory in libgomp
2011-10-10 Matthias Klose d...@ubuntu.com * config/posix95: Remove empty directory. The last files in config/posix95 were removed in r177568. Comitted as obvious. Matthias
Re: [patch] C6X unwinding/exception handling
On 10/10/2011 02:23 PM, Paul Brook wrote:
Index: libjava/exception.cc
===
--- libjava/exception.cc (revision 179739)
+++ libjava/exception.cc (working copy)
@@ -135,6 +135,7 @@
{
_Unwind_Ptr Start;
_Unwind_Ptr LPStart;
+ _Unwind_Ptr ttype_base;
const unsigned char *TType;
const unsigned char *action_table;
unsigned char ttype_encoding;
@@ -184,7 +185,7 @@
_Unwind_Ptr ptr;
ptr = (_Unwind_Ptr) (info-TType - (i * 4));
- ptr = _Unwind_decode_target2(ptr);
+ ptr = _Unwind_decode_typeinfo_ptr (info-ttype_base, (_Unwind_Word)
ptr);
return reinterpret_castvoid **(ptr);
}
@@ -325,6 +326,7 @@
// Parse the LSDA header.
p = parse_lsda_header (context, language_specific_data, info);
+ info.ttype_base = base_of_encoded_value (info.ttype_encoding, context);
#ifdef HAVE_GETIPINFO
ip = _Unwind_GetIPInfo (context, ip_before_insn);
#else
No. The purpose of my patch was to remove the arm specific code.
The only difference I can see in this bit of code is that libstdc++ uses
base_of_encoded_value/read_encoded_value_with_base whereas libjava uses
context/read_encoded_value.
I expect you want something like the patch below (completely untested).
I checked the attached patch, test results at
http://gcc.gnu.org/ml/gcc-testresults/2011-10/msg01377.html
which are the same as with my suggested patch.
Ok for the trunk?
Matthias
libjava/
2011-10-17 Paul Brook p...@codesourcery.com
* exception.cc (parse_lsda_header): hardcode ttype_encoding for older
ARM EABI toolchains.
(get_ttype_entry) Remove __ARM_EABI_UNWINDER__ variant.
libobjc/
2011-10-17 Paul Brook p...@codesourcery.com
Matthias Klose d...@ubuntu.com
* exception.c (parse_lsda_header): hardcode ttype_encoding for older
ARM EABI toolchains.
(get_ttype_entry) Remove __ARM_EABI_UNWINDER__ variant.
Index: libjava/exception.cc
===
--- libjava/exception.cc(revision 180086)
+++ libjava/exception.cc(working copy)
@@ -161,6 +161,11 @@
info-ttype_encoding = *p++;
if (info-ttype_encoding != DW_EH_PE_omit)
{
+#if _GLIBCXX_OVERRIDE_TTYPE_ENCODING
+ /* Older ARM EABI toolchains set this value incorrectly, so use a
+hardcoded OS-specific format. */
+ info-ttype_encoding = _GLIBCXX_OVERRIDE_TTYPE_ENCODING;
+#endif
p = read_uleb128 (p, tmp);
info-TType = p + tmp;
}
@@ -176,22 +181,7 @@
return p;
}
-#ifdef __ARM_EABI_UNWINDER__
-
static void **
-get_ttype_entry(_Unwind_Context *, lsda_header_info* info, _uleb128_t i)
-{
- _Unwind_Ptr ptr;
-
- ptr = (_Unwind_Ptr) (info-TType - (i * 4));
- ptr = _Unwind_decode_target2(ptr);
-
- return reinterpret_castvoid **(ptr);
-}
-
-#else
-
-static void **
get_ttype_entry (_Unwind_Context *context, lsda_header_info *info, long i)
{
_Unwind_Ptr ptr;
@@ -202,8 +192,6 @@
return reinterpret_castvoid **(ptr);
}
-#endif
-
// Using a different personality function name causes link failures
// when trying to mix code using different exception handling models.
#ifdef SJLJ_EXCEPTIONS
Index: libobjc/exception.c
===
--- libobjc/exception.c (revision 180086)
+++ libobjc/exception.c (working copy)
@@ -159,6 +159,11 @@
info-ttype_encoding = *p++;
if (info-ttype_encoding != DW_EH_PE_omit)
{
+#if _GLIBCXX_OVERRIDE_TTYPE_ENCODING
+ /* Older ARM EABI toolchains set this value incorrectly, so use a
+hardcoded OS-specific format. */
+ info-ttype_encoding = _GLIBCXX_OVERRIDE_TTYPE_ENCODING;
+#endif
p = read_uleb128 (p, tmp);
info-TType = p + tmp;
}
@@ -174,27 +179,7 @@
return p;
}
-#ifdef __ARM_EABI_UNWINDER__
-
static Class
-get_ttype_entry (struct lsda_header_info *info, _uleb128_t i)
-{
- _Unwind_Ptr ptr;
-
- ptr = (_Unwind_Ptr) (info-TType - (i * 4));
- ptr = _Unwind_decode_target2 (ptr);
-
- /* NULL ptr means catch-all. Note that if the class is not found,
- this will abort the program. */
- if (ptr)
-return objc_getRequiredClass ((const char *) ptr);
- else
-return 0;
-}
-
-#else
-
-static Class
get_ttype_entry (struct lsda_header_info *info, _Unwind_Word i)
{
_Unwind_Ptr ptr;
@@ -211,8 +196,6 @@
return 0;
}
-#endif
-
/* Using a different personality function name causes link failures
when trying to mix code using different exception handling
models. */
[patch] MULTILIB_DEFAULTS needs an update for ARM multilib builds
I did see gcc-4.7 fail to build for an ARM soft-float/hard-float multilib
configuration. The reason is that gcc -print-multi-directory doesn't print
anything for the non-default, and gcc -print-multi-lib only prints `.' (and then
not building the runtime libs for the non-default). The reason is that
set_multilib_dir in gcc.c only consults MULTILIB_DEFAULTS (only defined in
linux-elf.h), but not configure_default_options in configargs.h. This proposed
patch updates MULTILIB_DEFAULTS depending on the configure options. An
alternative approach would be to update set_multilib_dir and print_multilib_info
to lookup configure_default_options in configargs.h as well.
Note that this didn't fail to build in gcc-4.6, but I can't see yet what change
did cause the build failure.
I didn't check if other targets need an update as well.
Ok for the trunk?
Matthias
# DP: Set MULTILIB_DEFAULTS for ARM multilib builds
* config.gcc (arm*-*-*): Set TARGET_CONFIGURED_FLOAT_ABI and
TARGET_CONFIGURED_THUMB_MODE when configured --with-float and
--with-mode.
* config/arm/linux-eabi.h (MULTILIB_DEFAULTS): Set depending
on TARGET_CONFIGURED_FLOAT_ABI, TARGET_CONFIGURED_THUMB_MODE and
TARGET_BIG_ENDIAN_DEFAULT.
Index: b/src/gcc/config.gcc
===
--- a/src/gcc/config.gcc2012-05-02 10:24:10.585842104 +
+++ b/src/gcc/config.gcc2012-05-02 10:26:12.509846641 +
@@ -3047,10 +3047,18 @@
esac
case $with_float in
-\
- | soft | hard | softfp)
+ )
# OK
;;
+ soft)
+ tm_defines=${tm_defines} TARGET_CONFIGURED_FLOAT_ABI=0
+ ;;
+ softfp)
+ tm_defines=${tm_defines} TARGET_CONFIGURED_FLOAT_ABI=1
+ ;;
+ hard)
+ tm_defines=${tm_defines} TARGET_CONFIGURED_FLOAT_ABI=2
+ ;;
*)
echo Unknown floating point type used in
--with-float=$with_float 12
exit 1
@@ -3094,6 +3102,9 @@
\
| arm | thumb )
#OK
+ if test $with_mode = thumb; then
+ tm_defines=${tm_defines}
TARGET_CONFIGURED_THUMB_MODE=1
+ fi
;;
*)
echo Unknown mode used in --with-mode=$with_mode
Index: b/src/gcc/config/arm/linux-eabi.h
===
--- a/src/gcc/config/arm/linux-eabi.h 2012-05-02 10:24:10.585842104 +
+++ b/src/gcc/config/arm/linux-eabi.h 2012-05-02 10:26:55.141848227 +
@@ -34,7 +34,21 @@
/* We default to a soft-float ABI so that binaries can run on all
target hardware. */
#undef TARGET_DEFAULT_FLOAT_ABI
+#ifdef TARGET_CONFIGURED_FLOAT_ABI
+#if TARGET_CONFIGURED_FLOAT_ABI == 2
+#define TARGET_DEFAULT_FLOAT_ABI ARM_FLOAT_ABI_HARD
+#define MULTILIB_DEFAULT_FLOAT_ABI mfloat-abi=hard
+#elif TARGET_CONFIGURED_FLOAT_ABI == 1
+#define TARGET_DEFAULT_FLOAT_ABI ARM_FLOAT_ABI_SOFTFP
+#define MULTILIB_DEFAULT_FLOAT_ABI mfloat-abi=softfp
+#else
+#define TARGET_DEFAULT_FLOAT_ABI ARM_FLOAT_ABI_SOFT
+#define MULTILIB_DEFAULT_FLOAT_ABI mfloat-abi=soft
+#endif
+#else
#define TARGET_DEFAULT_FLOAT_ABI ARM_FLOAT_ABI_SOFT
+#define MULTILIB_DEFAULT_FLOAT_ABI mfloat-abi=soft
+#endif
/* We default to the aapcs-linux ABI so that enums are int-sized by
default. */
@@ -68,6 +82,28 @@
%{mfloat-abi=hard: GLIBC_DYNAMIC_LINKER_HARD_FLOAT } \
%{!mfloat-abi=hard: GLIBC_DYNAMIC_LINKER_SOFT_FLOAT }
+/* Set the multilib defaults according the configuration, needed to
+ let gcc -print-multi-dir do the right thing. */
+
+#if TARGET_BIG_ENDIAN_DEFAULT
+#define MULTILIB_DEFAULT_ENDIAN mbig-endian
+#else
+#define MULTILIB_DEFAULT_ENDIAN mlittle-endian
+#endif
+
+#ifndef TARGET_CONFIGURED_THUMB_MODE
+#define MULTILIB_DEFAULT_MODE marm
+#elif TARGET_CONFIGURED_THUMB_MODE == 1
+#define MULTILIB_DEFAULT_MODE mthumb
+#else
+#define MULTILIB_DEFAULT_MODE marm
+#endif
+
+#undef MULTILIB_DEFAULTS
+#define MULTILIB_DEFAULTS \
+ { MULTILIB_DEFAULT_MODE, MULTILIB_DEFAULT_ENDIAN, \
+ MULTILIB_DEFAULT_FLOAT_ABI, mno-thumb-interwork }
+
/* At this point, bpabi.h will have clobbered LINK_SPEC. We want to
use the GNU/Linux version, not the generic BPABI version. */
#undef LINK_SPEC
Re: [patch] MULTILIB_DEFAULTS needs an update for ARM multilib builds
On 02.05.2012 16:53, Richard Earnshaw wrote:
On 02/05/12 14:26, Matthias Klose wrote:
I did see gcc-4.7 fail to build for an ARM soft-float/hard-float multilib
configuration. The reason is that gcc -print-multi-directory doesn't print
anything for the non-default, and gcc -print-multi-lib only prints `.' (and
then
not building the runtime libs for the non-default). The reason is that
set_multilib_dir in gcc.c only consults MULTILIB_DEFAULTS (only defined in
linux-elf.h), but not configure_default_options in configargs.h. This
proposed
patch updates MULTILIB_DEFAULTS depending on the configure options. An
alternative approach would be to update set_multilib_dir and
print_multilib_info
to lookup configure_default_options in configargs.h as well.
Note that this didn't fail to build in gcc-4.6, but I can't see yet what
change
did cause the build failure.
I didn't check if other targets need an update as well.
Ok for the trunk?
Matthias
This patch doesn't appear to be based of FSF trunk...
@@ -68,6 +82,28 @@
%{mfloat-abi=hard: GLIBC_DYNAMIC_LINKER_HARD_FLOAT } \
%{!mfloat-abi=hard: GLIBC_DYNAMIC_LINKER_SOFT_FLOAT }
This pre-amble code has never existed in the FSF build.
Please ensure you are testing patches against the FSF sources, not some
custom variant.
it was, not only on some custom variant. The second chunk applies with fuzz
2, and I didn't notice when submitting.
Matthias
Index: gcc/config.gcc
===
--- gcc/config.gcc (revision 187013)
+++ gcc/config.gcc (working copy)
@@ -3013,10 +3013,18 @@
esac
case $with_float in
-\
- | soft | hard | softfp)
+ )
# OK
;;
+ soft)
+ tm_defines=${tm_defines} TARGET_CONFIGURED_FLOAT_ABI=0
+ ;;
+ softfp)
+ tm_defines=${tm_defines} TARGET_CONFIGURED_FLOAT_ABI=1
+ ;;
+ hard)
+ tm_defines=${tm_defines} TARGET_CONFIGURED_FLOAT_ABI=2
+ ;;
*)
echo Unknown floating point type used in
--with-float=$with_float 12
exit 1
@@ -3060,6 +3068,9 @@
\
| arm | thumb )
#OK
+ if test $with_mode = thumb; then
+ tm_defines=${tm_defines}
TARGET_CONFIGURED_THUMB_MODE=1
+ fi
;;
*)
echo Unknown mode used in --with-mode=$with_mode
Index: gcc/config/arm/linux-eabi.h
===
--- gcc/config/arm/linux-eabi.h (revision 187013)
+++ gcc/config/arm/linux-eabi.h (working copy)
@@ -35,7 +35,21 @@
target hardware. If you override this to use the hard-float ABI then
change the setting of GLIBC_DYNAMIC_LINKER_DEFAULT as well. */
#undef TARGET_DEFAULT_FLOAT_ABI
+#ifdef TARGET_CONFIGURED_FLOAT_ABI
+#if TARGET_CONFIGURED_FLOAT_ABI == 2
+#define TARGET_DEFAULT_FLOAT_ABI ARM_FLOAT_ABI_HARD
+#define MULTILIB_DEFAULT_FLOAT_ABI mfloat-abi=hard
+#elif TARGET_CONFIGURED_FLOAT_ABI == 1
+#define TARGET_DEFAULT_FLOAT_ABI ARM_FLOAT_ABI_SOFTFP
+#define MULTILIB_DEFAULT_FLOAT_ABI mfloat-abi=softfp
+#else
#define TARGET_DEFAULT_FLOAT_ABI ARM_FLOAT_ABI_SOFT
+#define MULTILIB_DEFAULT_FLOAT_ABI mfloat-abi=soft
+#endif
+#else
+#define TARGET_DEFAULT_FLOAT_ABI ARM_FLOAT_ABI_SOFT
+#define MULTILIB_DEFAULT_FLOAT_ABI mfloat-abi=soft
+#endif
/* We default to the aapcs-linux ABI so that enums are int-sized by
default. */
@@ -78,6 +92,28 @@
%{mfloat-abi=soft*: GLIBC_DYNAMIC_LINKER_SOFT_FLOAT } \
%{!mfloat-abi=*: GLIBC_DYNAMIC_LINKER_DEFAULT }
+/* Set the multilib defaults according the configuration, needed to
+ let gcc -print-multi-dir do the right thing. */
+
+#if TARGET_BIG_ENDIAN_DEFAULT
+#define MULTILIB_DEFAULT_ENDIAN mbig-endian
+#else
+#define MULTILIB_DEFAULT_ENDIAN mlittle-endian
+#endif
+
+#ifndef TARGET_CONFIGURED_THUMB_MODE
+#define MULTILIB_DEFAULT_MODE marm
+#elif TARGET_CONFIGURED_THUMB_MODE == 1
+#define MULTILIB_DEFAULT_MODE mthumb
+#else
+#define MULTILIB_DEFAULT_MODE marm
+#endif
+
+#undef MULTILIB_DEFAULTS
+#define MULTILIB_DEFAULTS \
+ { MULTILIB_DEFAULT_MODE, MULTILIB_DEFAULT_ENDIAN, \
+ MULTILIB_DEFAULT_FLOAT_ABI, mno-thumb-interwork }
+
/* At this point, bpabi.h will have clobbered LINK_SPEC. We want to
use the GNU/Linux version, not the generic BPABI version. */
#undef LINK_SPEC
Re: [patch] MULTILIB_DEFAULTS needs an update for ARM multilib builds
On 02.05.2012 17:02, Richard Earnshaw wrote:
On 02/05/12 15:59, Matthias Klose wrote:
On 02.05.2012 16:53, Richard Earnshaw wrote:
On 02/05/12 14:26, Matthias Klose wrote:
I did see gcc-4.7 fail to build for an ARM soft-float/hard-float multilib
configuration. The reason is that gcc -print-multi-directory doesn't print
anything for the non-default, and gcc -print-multi-lib only prints `.'
(and then
not building the runtime libs for the non-default). The reason is that
set_multilib_dir in gcc.c only consults MULTILIB_DEFAULTS (only defined in
linux-elf.h), but not configure_default_options in configargs.h. This
proposed
patch updates MULTILIB_DEFAULTS depending on the configure options. An
alternative approach would be to update set_multilib_dir and
print_multilib_info
to lookup configure_default_options in configargs.h as well.
Note that this didn't fail to build in gcc-4.6, but I can't see yet what
change
did cause the build failure.
I didn't check if other targets need an update as well.
Ok for the trunk?
Matthias
This patch doesn't appear to be based of FSF trunk...
@@ -68,6 +82,28 @@
%{mfloat-abi=hard: GLIBC_DYNAMIC_LINKER_HARD_FLOAT } \
%{!mfloat-abi=hard: GLIBC_DYNAMIC_LINKER_SOFT_FLOAT }
This pre-amble code has never existed in the FSF build.
Please ensure you are testing patches against the FSF sources, not some
custom variant.
it was, not only on some custom variant. The second chunk applies with
fuzz
2, and I didn't notice when submitting.
So shouldn't the patch also update the setting of
GLIBC_DYNAMIC_LINKER_DEFAULT?
like this one?
Index: gcc/config.gcc
===
--- gcc/config.gcc (revision 187013)
+++ gcc/config.gcc (working copy)
@@ -3013,10 +3013,18 @@
esac
case $with_float in
-\
- | soft | hard | softfp)
+ )
# OK
;;
+ soft)
+ tm_defines=${tm_defines} TARGET_CONFIGURED_FLOAT_ABI=0
+ ;;
+ softfp)
+ tm_defines=${tm_defines} TARGET_CONFIGURED_FLOAT_ABI=1
+ ;;
+ hard)
+ tm_defines=${tm_defines} TARGET_CONFIGURED_FLOAT_ABI=2
+ ;;
*)
echo Unknown floating point type used in
--with-float=$with_float 12
exit 1
@@ -3060,6 +3068,9 @@
\
| arm | thumb )
#OK
+ if test $with_mode = thumb; then
+ tm_defines=${tm_defines}
TARGET_CONFIGURED_THUMB_MODE=1
+ fi
;;
*)
echo Unknown mode used in --with-mode=$with_mode
Index: gcc/config/arm/linux-eabi.h
===
--- gcc/config/arm/linux-eabi.h (revision 187013)
+++ gcc/config/arm/linux-eabi.h (working copy)
@@ -35,7 +35,21 @@
target hardware. If you override this to use the hard-float ABI then
change the setting of GLIBC_DYNAMIC_LINKER_DEFAULT as well. */
#undef TARGET_DEFAULT_FLOAT_ABI
+#ifdef TARGET_CONFIGURED_FLOAT_ABI
+#if TARGET_CONFIGURED_FLOAT_ABI == 2
+#define TARGET_DEFAULT_FLOAT_ABI ARM_FLOAT_ABI_HARD
+#define MULTILIB_DEFAULT_FLOAT_ABI mfloat-abi=hard
+#elif TARGET_CONFIGURED_FLOAT_ABI == 1
+#define TARGET_DEFAULT_FLOAT_ABI ARM_FLOAT_ABI_SOFTFP
+#define MULTILIB_DEFAULT_FLOAT_ABI mfloat-abi=softfp
+#else
#define TARGET_DEFAULT_FLOAT_ABI ARM_FLOAT_ABI_SOFT
+#define MULTILIB_DEFAULT_FLOAT_ABI mfloat-abi=soft
+#endif
+#else
+#define TARGET_DEFAULT_FLOAT_ABI ARM_FLOAT_ABI_SOFT
+#define MULTILIB_DEFAULT_FLOAT_ABI mfloat-abi=soft
+#endif
/* We default to the aapcs-linux ABI so that enums are int-sized by
default. */
@@ -71,13 +85,43 @@
#undef GLIBC_DYNAMIC_LINKER
#define GLIBC_DYNAMIC_LINKER_SOFT_FLOAT /lib/ld-linux.so.3
#define GLIBC_DYNAMIC_LINKER_HARD_FLOAT /lib/ld-linux-armhf.so.3
+#ifdef TARGET_CONFIGURED_FLOAT_ABI
+#if TARGET_CONFIGURED_FLOAT_ABI == 2
+#define GLIBC_DYNAMIC_LINKER_DEFAULT GLIBC_DYNAMIC_LINKER_HARD_FLOAT
+#else
#define GLIBC_DYNAMIC_LINKER_DEFAULT GLIBC_DYNAMIC_LINKER_SOFT_FLOAT
+#endif
+#else
+#define GLIBC_DYNAMIC_LINKER_DEFAULT GLIBC_DYNAMIC_LINKER_SOFT_FLOAT
+#endif
#define GLIBC_DYNAMIC_LINKER \
%{mfloat-abi=hard: GLIBC_DYNAMIC_LINKER_HARD_FLOAT } \
%{mfloat-abi=soft*: GLIBC_DYNAMIC_LINKER_SOFT_FLOAT } \
%{!mfloat-abi=*: GLIBC_DYNAMIC_LINKER_DEFAULT }
+/* Set the multilib defaults according the configuration, needed to
+ let gcc -print-multi-dir do the right thing. */
+
+#if TARGET_BIG_ENDIAN_DEFAULT
+#define MULTILIB_DEFAULT_ENDIAN mbig-endian
+#else
+#define MULTILIB_DEFAULT_ENDIAN mlittle-endian
+#endif
+
+#ifndef
[patch] don't check for execute bits of the liblto plugin
The lto plugin is installed without x bits set, but gcc-ar.c still checks for
the execute bits. There is no need to have the lto plugin to have the x bits
set, so just check that it is readable.
Ok for the trunk and the 4.7 branch?
Matthias
* (main): Don't check for execute bits for the plugin.
--- gcc/gcc-ar.c
+++ gcc/gcc-ar.c
@@ -70,7 +70,7 @@
dir_separator,
LTOPLUGINSONAME,
NULL);
- if (access (plugin, X_OK))
+ if (access (plugin, R_OK))
{
fprintf (stderr, %s: Cannot find plugin %s\n, av[0], plugin);
exit (1);
Re: [patch] support for multiarch systems
On 20.08.2011 21:51, Matthias Klose wrote:
Multiarch [1] is the term being used to refer to the capability of a system to
install and run applications of multiple different binary targets on the same
system.
please find attached an updated for the trunk (2012-05-08). The multiarch
triplets are now defined in the Debian Wiki [1], and progress is made to get the
triplet definitions into Debian Policy [2].
Matthias
[1] http://wiki.debian.org/Multiarch/Tuples
[2] http://bugs.debian.org/664257
gcc/
2012-05-08 Matthias Klose d...@ubuntu.com
* doc/invoke.texi: Document -print-multiarch.
* doc/install.texi: Document --enable-multiarch.
* doc/fragments.texi: Document MULTILIB_OSDIRNAMES, MULTIARCH_DIRNAME.
* configure.ac: Add --enable-multiarch option.
* configure.in: Regenerate.
* Makefile.in (s-mlib): Pass MULTIARCH_DIRNAME to genmultilib.
enable_multiarch, with_float: New macros.
if_multiarch: New macro, define in terms of enable_multiarch.
* genmultilib: Add new argument for the multiarch name.
* gcc.c (multiarch_dir): Define.
(for_each_path): Search for multiarch suffixes.
(driver_handle_option): Handle multiarch option.
(do_spec_1): Pass -imultiarch if defined.
(main): Print multiarch.
(set_multilib_dir): Separate multilib and multiarch names
from multilib_select.
(print_multilib_info): Ignore multiarch names in multilib_select.
* incpath.c (add_standard_paths): Search the multiarch include dirs.
* cppdeault.h (default_include): Document multiarch in multilib
member.
* cppdefault.c: [LOCAL_INCLUDE_DIR, STANDARD_INCLUDE_DIR] Add an
include directory for multiarch directories.
* common.opt: New options --print-multiarch and -imultilib.
* config.gcc: Add tmake fragments to tmake_file (alpha/t-linux
for alpha*-*-linux*, pa/t-linux for hppa*64*-*-linux*, ia64/t-glibc
for ia64*-*-linux*, rs6000/t-linux for powerpc-*-linux*, i386/t-kfreebsd
for i[34567]86-*-kfreebsd*-gnu and x86_64-*-kfreebsd*-gnu, i386/t-gnu
for i[34567]86-*-gnu*).
* config/i386/t-kfreebsd: Add multiarch names in MULTILIB_OSDIRNAMES,
Define MULTIARCH_DIRNAME.
* config/s390/t-linux64: Add multiarch names in MULTILIB_OSDIRNAMES.
* config/sparc/t-linux64: Likewise.
* config/rs6000/t-linux64: Likewise.
* config/i386/t-linux64: Likewise.
* config/mips/t-linux64: Likewise.
* config/alpha/t-linux: Define MULTIARCH_DIRNAME.
* config/arm/t-linux-eabi: Likewise.
* config/i386/t-gnu: Likewise:
* config/i386/t-linux: Likewise.
* config/pa/t-linux: Likewise.
* config/rs6000/t-linux: Likewise.
* config/rs6000/t-spe: Likewise.
* config/sparc/t-linux: Likewise.
* config/ia64/t-glibc: Define MULTIARCH_DIRNAME for linux target.
Index: libstdc++-v3/python/hook.in
===
--- libstdc++-v3/python/hook.in (revision 187271)
+++ libstdc++-v3/python/hook.in (working copy)
@@ -47,7 +47,10 @@
libdir = libdir[len (prefix):]
# Compute the ..s needed to get from libdir to the prefix.
-dotdots = ('..' + os.sep) * len (libdir.split (os.sep))
+backdirs = len (libdir.split (os.sep))
+if not os.path.basename(os.path.dirname(__file__)).startswith('lib'):
+backdirs += 1 # multiarch subdir
+dotdots = ('..' + os.sep) * backdirs
objfile = gdb.current_objfile ().filename
dir_ = os.path.join (os.path.dirname (objfile), dotdots, pythondir)
Index: gcc/common.opt
===
--- gcc/common.opt (revision 187271)
+++ gcc/common.opt (working copy)
@@ -345,6 +345,9 @@
-print-multi-os-directory
Driver Alias(print-multi-os-directory)
+-print-multiarch
+Driver Alias(print-multiarch)
+
-print-prog-name
Driver Separate Alias(print-prog-name=)
@@ -2286,6 +2289,10 @@
Common Joined Var(plugindir_string) Init(0)
-iplugindir=dir Set dir to be the default plugin directory
+imultiarch
+Common Joined Separate RejectDriver Var(imultiarch) Init(0)
+-imultiarch dir Set dir to be the multiarch include subdirectory
+
l
Driver Joined Separate
@@ -2342,6 +2349,9 @@
print-multi-os-directory
Driver Var(print_multi_os_directory)
+
+print-multiarch
+Driver Var(print_multiarch)
print-prog-name=
Driver JoinedOrMissing Var(print_prog_name)
Index: gcc/Makefile.in
===
--- gcc/Makefile.in (revision 187271)
+++ gcc/Makefile.in (working copy)
@@ -350,6 +350,17 @@
enable_plugin = @enable_plugin@
+# Multiarch support
+enable_multiarch = @enable_multiarch@
+with_float = @with_float@
+ifeq ($(enable_multiarch),yes)
+ if_multiarch = $(1)
+else ifeq ($(enable_multiarch),auto-detect
Re: [patch] support for multiarch systems
On 08.05.2012 15:20, Joseph S. Myers wrote: On Tue, 8 May 2012, Matthias Klose wrote: On 20.08.2011 21:51, Matthias Klose wrote: Multiarch [1] is the term being used to refer to the capability of a system to install and run applications of multiple different binary targets on the same system. please find attached an updated for the trunk (2012-05-08). The multiarch triplets are now defined in the Debian Wiki [1], and progress is made to get the triplet definitions into Debian Policy [2]. This still seems to suffer in some cases the problem of previous versions that it does not ensure triplets are never used for non-matching ABIs. For example, a compiler for powerpc-linux-gnu can be configured --with-float=soft but this patch will still use powerpc-linux-gnu as the multiarch triplet. For MIPS, I see you allowed for soft-float in setting the triplets - but the specification you point to doesn't mention the soft-float triplets. Likewise you allowed for powerpc-linux-gnuspe being e500v1 or e500v2 but haven't documented the e500v1 triplet. Likewise for big-endian ARM. I again suggest starting with a patch that does just one architecture - but makes sure to cover all the ABIs applicable to that architecture. For example, you could start with a patch for x86 (indeed, just x86 GNU/Linux) - and assign a multiarch triplet for x32 even if you're not building an x32 distribution with multiarch. Then, once the generic support has been reviewed by build system maintainers, and the x86 support by x86 maintainers and people familiar with all the applicable x86 ABIs, send patches for each other architecture (or architecture/OS combination), and the relevant architecture experts can review them to make sure the relevant ABIs are properly distinguished. ok, the attached patch includes just the support for the x86 targets, including the kfreebsd and the hurd systems. The x32 multiarch tuple isn't yet defined, so I'd like to keep it out of the first version. Matthias gcc/ 2012-05-08 Matthias Klose d...@ubuntu.com * doc/invoke.texi: Document -print-multiarch. * doc/install.texi: Document --enable-multiarch. * doc/fragments.texi: Document MULTILIB_OSDIRNAMES, MULTIARCH_DIRNAME. * configure.ac: Add --enable-multiarch option. * configure.in: Regenerate. * Makefile.in (s-mlib): Pass MULTIARCH_DIRNAME to genmultilib. enable_multiarch, with_float: New macros. if_multiarch: New macro, define in terms of enable_multiarch. * genmultilib: Add new argument for the multiarch name. * gcc.c (multiarch_dir): Define. (for_each_path): Search for multiarch suffixes. (driver_handle_option): Handle multiarch option. (do_spec_1): Pass -imultiarch if defined. (main): Print multiarch. (set_multilib_dir): Separate multilib and multiarch names from multilib_select. (print_multilib_info): Ignore multiarch names in multilib_select. * incpath.c (add_standard_paths): Search the multiarch include dirs. * cppdeault.h (default_include): Document multiarch in multilib member. * cppdefault.c: [LOCAL_INCLUDE_DIR, STANDARD_INCLUDE_DIR] Add an include directory for multiarch directories. * common.opt: New options --print-multiarch and -imultilib. * config.gcc: Add tmake fragments to tmake_file ( i386/t-kfreebsd for i[34567]86-*-kfreebsd*-gnu and x86_64-*-kfreebsd*-gnu, i386/t-gnu for i[34567]86-*-gnu*). * config/i386/t-kfreebsd: Add multiarch names in MULTILIB_OSDIRNAMES, Define MULTIARCH_DIRNAME. * config/i386/t-linux64: Likewise. * config/i386/t-gnu: Likewise: * config/i386/t-linux: Likewise. Index: gcc/common.opt === --- gcc/common.opt (revision 187271) +++ gcc/common.opt (working copy) @@ -345,6 +345,9 @@ -print-multi-os-directory Driver Alias(print-multi-os-directory) +-print-multiarch +Driver Alias(print-multiarch) + -print-prog-name Driver Separate Alias(print-prog-name=) @@ -2286,6 +2289,10 @@ Common Joined Var(plugindir_string) Init(0) -iplugindir=dir Set dir to be the default plugin directory +imultiarch +Common Joined Separate RejectDriver Var(imultiarch) Init(0) +-imultiarch dir Set dir to be the multiarch include subdirectory + l Driver Joined Separate @@ -2342,6 +2349,9 @@ print-multi-os-directory Driver Var(print_multi_os_directory) + +print-multiarch +Driver Var(print_multiarch) print-prog-name= Driver JoinedOrMissing Var(print_prog_name) Index: gcc/Makefile.in === --- gcc/Makefile.in (revision 187271) +++ gcc/Makefile.in (working copy) @@ -350,6 +350,17 @@ enable_plugin = @enable_plugin@ +# Multiarch support +enable_multiarch = @enable_multiarch
Re: [patch] support for multiarch systems
On 09.05.2012 15:37, Paolo Bonzini wrote:
Il 09/05/2012 02:38, Matthias Klose ha scritto:
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 187271)
+++ gcc/doc/invoke.texi (working copy)
@@ -6110,6 +6110,11 @@
@file{../lib32}, or if OS libraries are present in @file{lib/@var{subdir}}
subdirectories it prints e.g.@: @file{amd64}, @file{sparcv9} or @file{ev6}.
+@item -print-multiarch
+@opindex print-multiarch
+Print the path to OS libraries for the selected multiarch,
+relative to some @file{lib} subdirectory.
+
@item -print-prog-name=@var{program}
@opindex print-prog-name
Like @option{-print-file-name}, but searches for a program such as
@samp{cpp}.
So -print-multiarch is like --print-multi-os-directory?
the former prints the part before the `:' in the MULTILIB_OSDIRNAMES, the latter
the part after the `':', e.g. ../lib32 and i386-linux-gnu.
What is the difference, and where is it documented?
Not sure how it should be further documented.
Should it fail if multiarch support is not compiled in?
All the -print options always succeed. I would prefer if it just prints the
empty string if it is not configured (as it does now).
Matthias
Re: [patch] support for multiarch systems
On 09.05.2012 18:29, Paolo Bonzini wrote: Il 09/05/2012 17:34, Matthias Klose ha scritto: So -print-multiarch is like --print-multi-os-directory? the former prints the part before the `:' in the MULTILIB_OSDIRNAMES, the latter the part after the `':', e.g. ../lib32 and i386-linux-gnu. Yes, of course. What is the difference, and where is it documented? Not sure how it should be further documented. No idea, it is a new concept and people need to understand how it relates to multilibbing for example, what shortcomings are addressed etc. I went through the Debian pages (only cursorily, I admit) and I found nothing of this. these are referenced from the http://wiki.debian.org/Multiarch/Tuples https://wiki.ubuntu.com/MultiarchSpec#Filesystem_layout http://err.no/debian/amd64-multiarch-3 http://wiki.debian.org/Multiarch/TheCaseForMultiarch describes use cases for multiarch, and why Debian thinks that the existing approaches are not sufficient (having name collisions for different architectures or ad hoc names for new architectures like libx32). That may be contentious within the Linux community, but I would like to avoid this kind of discussion here. Another question I have is related to usage of the option. Are you supposed to look for libraries in the multilib directories too if the compiler is multiarch-enabled? Debian/Ubuntu always use /lib for the default MULTIOSDIR, and this needs to be looked up in the future too. The use of locations like ../lib32 will be faded out over time, but I don't see any harm not to have looked up as well. Or only in /lib/i386-linux-gnu? Which one takes priority, multiarch or multiosdir? From the patch I can guess the intended search path is /lib/MULTIARCH:/lib/MULTIOSDIR, but I'm not entirely sure about that and it needs documentation. yes, this is the intended search path. I assume such kind of documentation shouldn't go into invoke.texi. Should it fail if multiarch support is not compiled in? All the -print options always succeed. I would prefer if it just prints the empty string if it is not configured (as it does now). Will the empty string be a valid output for a multiarch-enabled compiler? For example gcc --print-multi-os-directory and gcc --print-multi-directory on a bi-arch x86-64 compiler will never print the empty string. Again, I guess the answer is no but I'm not sure. If the answer is no, returning the empty string is fine. The answer is no. If multiarch is enabled, then the string is always non-empty and should return a multiarch tuple as defined in http://wiki.debian.org/Multiarch/Tuples. Anything else should be considered an error. If the answer is yes, and assuming the search path is /lib/MULTIARCH:/lib/MULTIOSDIR, then programs need to know whether they need to omit the /lib/MULTIARCH component of the search path. Unrelated, but why would programs hard code this path and not use something like this? gcc -v -E - /dev/null 21 | grep ^LIBRARY_PATH Matthias
Re: [patch] support for multiarch systems
On 10.05.2012 08:42, Paolo Bonzini wrote:
Il 09/05/2012 19:19, Matthias Klose ha scritto:
these are referenced from the http://wiki.debian.org/Multiarch/Tuples
https://wiki.ubuntu.com/MultiarchSpec#Filesystem_layout
http://err.no/debian/amd64-multiarch-3
http://wiki.debian.org/Multiarch/TheCaseForMultiarch describes use cases for
multiarch, and why Debian thinks that the existing approaches are not
sufficient
(having name collisions for different architectures or ad hoc names for new
architectures like libx32). That may be contentious within the Linux
community,
but I would like to avoid this kind of discussion here.
I don't care about contentiousness, I just would like this to be
documented somewhere (for example in the internals manual where
MULTILIB_* is documented too).
ok, I did clarify it in the existing documentation of MULTIARCH_DIRNAME in
fragments.texi, detailing the search order for the files. Should the search
order be mentioned in some user documentation as well? if yes, where?
Matthias
Index: doc/fragments.texi
===
--- doc/fragments.texi (revision 187337)
+++ doc/fragments.texi (working copy)
@@ -152,6 +152,52 @@
of options to be used for all builds. If you set this, you should
probably set @code{CRTSTUFF_T_CFLAGS} to a dash followed by it.
+@findex MULTILIB_OSDIRNAMES
+@item MULTILIB_OSDIRNAMES
+If @code{MULTILIB_OPTIONS} is used, this variable specifies the list
+of OS subdirectory names. The format is either the same as of
+@code{MULTILIB_DIRNAMES}, or a set of mappings. When it is the same
+as @code{MULTILIB_DIRNAMES}, it describes the multilib directories
+using OS conventions, rather than GCC conventions. When it is a set
+of mappings of the form @var{gccdir}=@var{osdir}, the left side gives
+the GCC convention and the right gives the equivalent OS defined
+location. If the @var{osdir} part begins with a @samp{!}, the os
+directory names are used exclusively. Use the mapping when there is
+no one-to-one equivalence between GCC levels and the OS.
+
+For multilib enabled configurations (see @code{MULTIARCH_DIRNAME})
+below), the multilib name is appended to each directory name, separated
+by a colon (e.g. @samp{../lib:x86_64-linux-gnu}).
+
+@findex MULTIARCH_DIRNAME
+@item MULTIARCH_DIRNAME
+If @code{MULTIARCH_DIRNAME} is used, this variable specifies the
+multiarch name for this configuration. For multiarch enabled
+configurations it is used to search libraries, crt files and system
+header files in additional locations.
+
+Libraries and crt files are searched first in
+@var{prefix}/@var{multiarch} before @var{prefix} for each @var{prefix}
+added by @code{add_prefix} or @code{add_sysrooted_prefix}.
+System header files are searched first in
+@code{LOCAL_INCLUDE_DIR}/@var{multiarch} before
+@code{LOCAL_INCLUDE_DIR}, and in
+@code{NATIVE_SYSTEM_HEADER_DIR}/@var{multiarch} before
+@code{NATIVE_SYSTEM_HEADER_DIR}.
+
+E.g. for a multiarch enabled system compiler
+@file{/lib/@var{multiarch}} is searched before @file{/lib} and
+@file{/usr/lib/@var{multiarch}} before @file{/usr/lib}, and system
+header files are searched in @file{/usr/local/include/@var{multiarch}}
+before @file{/usr/local/include} and in
+@file{/usr/include/@var{multiarch}} before @file{/usr/include}.
+
+@code{MULTIARCH_DIRNAME} is not used for multilib enabled
+configurations, but encoded in @code{MULTILIB_OSDIRNAMES} instead.
+
+The multiarch tuples are defined
+in @uref{http://wiki.debian.org/Multiarch/Tuples}.
+
@findex SPECS
@item SPECS
Unfortunately, setting @code{MULTILIB_EXTRA_OPTS} is not enough, since
Re: [patch] support for multiarch systems
On 11.05.2012 12:51, Paolo Bonzini wrote:
Il 11/05/2012 07:13, Matthias Klose ha scritto:
ok, I did clarify it in the existing documentation of MULTIARCH_DIRNAME in
fragments.texi, detailing the search order for the files. Should the search
order be mentioned in some user documentation as well? if yes, where?
Thanks! I don't think the search order should be mentioned specially,
since anyway *_INCLUDE_PATH and LIBRARY_PATH are mentioned. However
under MULTILIB_DIRNAMES I would add something like this:
@code{MULTILIB_DIRNAMES} describes the multilib directories using GCC
conventions and is applied to directories that are part of the GCC
installation. When multilib-enabled, the compiler will add a
subdirectory of the form @var{prefix}/@var{multilib} before each
directory in the search path for libraries and crt files.
done.
+@findex MULTILIB_OSDIRNAMES
+@item MULTILIB_OSDIRNAMES
+If @code{MULTILIB_OPTIONS} is used, this variable specifies
... a list of subdirectory names, that are used to modify the search
path depending on the chosen multilib. Unlike @code{MULTILIB_DIRNAMES},
@code{MULTILIB_OSDIRNAMES} describes the multilib directories using
operating systems conventions, and is applied to the directories such as
@code{lib} or those in the @env{LIBRARY_PATH} environment variable.
The format is either the same as of
+@code{MULTILIB_DIRNAMES}, or a set of mappings. When it is the same
+as @code{MULTILIB_DIRNAMES}, it describes the multilib directories
+using OS conventions, rather than GCC conventions.
s/OS/operating system/
done.
When it is a set
+of mappings of the form @var{gccdir}=@var{osdir}, the left side gives
+the GCC convention and the right gives the equivalent OS defined
+location. If the @var{osdir} part begins with a @samp{!},
... GCC will not search in the non-multilib directory and use
exclusively the multilib directory. Otherwise, the compiler will
examine the search path for libraries and crt files twice; the first
time it will add @var{multilib} to each directory in the search path,
the second it will not.
Use the mapping when there is
+no one-to-one equivalence between GCC levels and the OS.
I'm not sure what you mean here?
The whole paragraph was taken from the genmultilib script. I left it out for
this version. I think I'll update the genmultilib script when these docs are
settled.
+For multilib enabled configurations (see @code{MULTIARCH_DIRNAME})
+below), the multilib name is appended to each directory name, separated
+by a colon (e.g. @samp{../lib:x86_64-linux-gnu}).
For configurations that support both multilib and multiarch,
@code{MULTILIB_OSDIRNAMES} also encodes the multiarch name, thus
subsuming @code{MULTIARCH_DIRNAME}. The multiarch name is appended to
each directory name, separated by a colon (e.g.
@samp{../lib32:i386-linux-gnu}).
Each multiarch subdirectory will be searched before the corresponding OS
multilib directory, for example @samp{/lib/i386-linux-gnu} before
@samp{/lib/..lib32}. The multiarch name will also be used to modify the
system header search path, as explained for @code{MULTIARCH_DIRNAME}.
done.
+@findex MULTIARCH_DIRNAME
+@item MULTIARCH_DIRNAME
+If @code{MULTIARCH_DIRNAME} is used, this variable specifies the
+multiarch name for this configuration.
+Libraries and crt files are searched first in
+@var{prefix}/@var{multiarch} before @var{prefix} for each @var{prefix}
+added by @code{add_prefix} or @code{add_sysrooted_prefix}.
+System header files are searched first in
+@code{LOCAL_INCLUDE_DIR}/@var{multiarch} before
+@code{LOCAL_INCLUDE_DIR}, and in
+@code{NATIVE_SYSTEM_HEADER_DIR}/@var{multiarch} before
+@code{NATIVE_SYSTEM_HEADER_DIR}.
+@code{MULTIARCH_DIRNAME} is not used for multilib enabled
+configurations, but encoded in @code{MULTILIB_OSDIRNAMES} instead.
This sounds simpler, and doesn't refer to GCC implementation details
such add_prefix/add_sysrooted_prefix:
This variable specifies the multiarch name for configurations that are
multiarch-enabled but not multilibbed configurations.
The multiarch name is used to augment the search path for libraries, crt
files and system header files with additional locations. The compiler
will add a multiarch subdirectory of the form
@var{prefix}/@var{multiarch} before each directory in the library and
crt search path. It will also add two directories
@code{LOCAL_INCLUDE_DIR}/@var{multiarch} and
@code{NATIVE_SYSTEM_HEADER_DIR}/@var{multiarch}) to the system header
search path, respectively before @code{LOCAL_INCLUDE_DIR} and
@code{NATIVE_SYSTEM_HEADER_DIR}.
@code{MULTIARCH_DIRNAME} is not used for configurations that support
both multilib and multiarch. In that case, multiarch names are encoded
in @code{MULTILIB_OSDIRNAMES} instead.
done. thanks for the wording.
+The multiarch tuples are defined
+in @uref{http://wiki.debian.org/Multiarch/Tuples}.
Is this needed? Aren't they defined
[ping] Re: [patch v2] support for multiarch systems
ping?
re-attaching the updated patch with the fixed comment in genmultilib.
Matthias
On 08.07.2012 20:48, Matthias Klose wrote:
Please find attached v2 of the patch updated for trunk 20120706, x86 only,
tested on
x86-linux-gnu, KFreeBSD and the Hurd.
I left in the comment about the multiarch names, but I'm fine to
change/discard
it. It was first required by Joseph Myers, then not found necessary by Paolo
Bonzini. The patch includes the changes suggested by Thomas Schwinge.
Ok for the trunk?
Matthias
2012-06-25 Matthias Klose d...@ubuntu.com
* doc/invoke.texi: Document -print-multiarch.
* doc/install.texi: Document --enable-multiarch.
* doc/fragments.texi: Document MULTILIB_OSDIRNAMES, MULTIARCH_DIRNAME.
* configure.ac: Add --enable-multiarch option.
* configure.in: Regenerate.
* Makefile.in (s-mlib): Pass MULTIARCH_DIRNAME to genmultilib.
enable_multiarch, with_float: New macros.
if_multiarch: New macro, define in terms of enable_multiarch.
* genmultilib: Add new argument for the multiarch name.
* gcc.c (multiarch_dir): Define.
(for_each_path): Search for multiarch suffixes.
(driver_handle_option): Handle multiarch option.
(do_spec_1): Pass -imultiarch if defined.
(main): Print multiarch.
(set_multilib_dir): Separate multilib and multiarch names
from multilib_select.
(print_multilib_info): Ignore multiarch names in multilib_select.
* incpath.c (add_standard_paths): Search the multiarch include dirs.
* cppdeault.h (default_include): Document multiarch in multilib
member.
* cppdefault.c: [LOCAL_INCLUDE_DIR, STANDARD_INCLUDE_DIR] Add an
include directory for multiarch directories.
* common.opt: New options --print-multiarch and -imultilib.
* config.gcc i[34567]86-*-linux* | x86_64-*-linux* (tmake_file):
Include i386/t-linux.
i[34567]86-*-kfreebsd*-gnu | x86_64-*-kfreebsd*-gnu (tmake_file):
Include i386/t-kfreebsd.
i[34567]86-*-gnu* (tmake_file): Include i386/t-gnu.
* config/i386/t-linux64: Add multiarch names in
MULTILIB_OSDIRNAMES, define MULTIARCH_DIRNAME.
* config/i386/t-gnu: New file.
* config/i386/t-kfreebsd: Likewise.
* config/i386/t-linux: Likewise.
Index: configure.ac
===
--- configure.ac(revision 188931)
+++ configure.ac(working copy)
@@ -623,6 +623,21 @@
[], [enable_multilib=yes])
AC_SUBST(enable_multilib)
+# Determine whether or not multiarch is enabled.
+AC_ARG_ENABLE(multiarch,
+[AS_HELP_STRING([--enable-multiarch],
+ [enable support for multiarch paths])],
+[case ${withval} in
+yes|no|auto-detect) enable_multiarch=$withval;;
+*) AC_MSG_ERROR(bad value ${withval} given for --enable-multiarch option) ;;
+esac], [enable_multiarch=auto-detect])
+AC_MSG_CHECKING(for multiarch configuration)
+AC_SUBST(enable_multiarch)
+AC_MSG_RESULT($enable_multiarch)
+
+# needed for setting the multiarch name on ARM
+AC_SUBST(with_float)
+
# Enable __cxa_atexit for C++.
AC_ARG_ENABLE(__cxa_atexit,
[AS_HELP_STRING([--enable-__cxa_atexit], [enable __cxa_atexit for C++])],
Index: cppdefault.c
===
--- cppdefault.c(revision 188931)
+++ cppdefault.c(working copy)
@@ -63,6 +63,7 @@
#endif
#ifdef LOCAL_INCLUDE_DIR
/* /usr/local/include comes before the fixincluded header files. */
+{ LOCAL_INCLUDE_DIR, 0, 0, 1, 1, 2 },
{ LOCAL_INCLUDE_DIR, 0, 0, 1, 1, 0 },
#endif
#ifdef PREFIX_INCLUDE_DIR
@@ -90,6 +91,7 @@
#endif
#ifdef NATIVE_SYSTEM_HEADER_DIR
/* /usr/include comes dead last. */
+{ NATIVE_SYSTEM_HEADER_DIR, NATIVE_SYSTEM_HEADER_COMPONENT, 0, 0, 1, 2 },
{ NATIVE_SYSTEM_HEADER_DIR, NATIVE_SYSTEM_HEADER_COMPONENT, 0, 0, 1, 0 },
#endif
{ 0, 0, 0, 0, 0, 0 }
Index: cppdefault.h
===
--- cppdefault.h(revision 188931)
+++ cppdefault.h(working copy)
@@ -43,9 +43,11 @@
C++. */
const char add_sysroot; /* FNAME should be prefixed by
cpp_SYSROOT. */
- const char multilib; /* FNAME should have the multilib path
- specified with -imultilib
- appended. */
+ const char multilib; /* FNAME should have appended
+ - the multilib path specified with -imultilib
+when 1 is passed,
+ - the multiarch path specified with
+-imultiarch, when 2 is passed. */
};
extern const struct default_include cpp_include_defaults[];
Index: Makefile.in
Re: C++ PATCH for c++/54341, c++/54253 (constexpr and virtual functions)
On 06.09.2012 17:37, Jason Merrill wrote: Vtables were causing several different problems for constexpr: 1) Value-initializing a nearly-empty class (that has a vptr but no data) meant two initializers for a single base. Fixed by not bothering to zero out a type with no data before calling its constructor. 2) A primary base is allocated at offset 0 even if it isn't at the beginning of the base-clause, but constructors initialize bases in the order of the base-clause. So we need to do some adjustment to get our CONSTRUCTOR in the right order. Looking at issue 2 also led me to notice that we were failing to ignore base fields as intended in cx_check_missing_mem_inits. thanks for the fix. looked at backporting this for 4.7. Is it really necessary to use C++ only syntax for this kind of patches, which are a candidate for 4.7? thanks, Matthias
Re: C++ PATCH for c++/54341, c++/54253 (constexpr and virtual functions)
On 07.09.2012 21:38, Jason Merrill wrote: On 09/07/2012 12:33 PM, Matthias Klose wrote: thanks for the fix. looked at backporting this for 4.7. Is it really necessary to use C++ only syntax for this kind of patches, which are a candidate for 4.7? It's not necessary to use this syntax, but even code that uses the VEC macros would need to be different between 4.7 and 4.8. Here's a 4.7 version: thanks. the testsuite passes without regressions on x86_64-linux-gnu and powerpc-linux-gnu with this patch. Matthias
Re: status of -fstack-protector-strong?
On 08.09.2012 01:07, Kees Cook wrote: Hi, I'm curious about the status of this patch: http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00974.html Chrome OS uses this, and the Ubuntu Security Team has expressed interest in it as well. What's needed to land this in gcc? I don't see any statement about testsuite results and possible regressions with this patch (not only on x86 platforms). Matthias
[patch] Disable static build for libjava
As discussed at the Google GCC gathering, disable the build of static libraries
in libjava, which should cut the build time of libjava by 50%. The static
libjava build isn't useful out of the box, and I don't see it packaged by Linux
distributions either.
The AC_PROG_LIBTOOL check is needed to get access to the enable_shared macro.
I'm unsure about the check in the switch construct. Taken from libtool.m4, and
determining the value of enable_shared_with_static_runtimes.
Ok for the trunk?
2011-07-07 Matthias Klose d...@ubuntu.com
* Makefile.def (target_modules/libjava): Pass
$(libjava_disable_static).
* configure.ac: Check for libtool, pass --disable-static
in libjava_disable_static.
* Makefile.in: Regenerate.
* configure: Likewise.
Index: Makefile.def
===
--- Makefile.def(revision 175963)
+++ Makefile.def(working copy)
@@ -132,7 +132,8 @@
target_modules = { module= winsup; };
target_modules = { module= libgloss; no_check=true; };
target_modules = { module= libffi; };
-target_modules = { module= libjava; raw_cxx=true; };
+target_modules = { module= libjava; raw_cxx=true;
+ extra_configure_flags=$(libjava_disable_static); };
target_modules = { module= zlib; };
target_modules = { module= boehm-gc; };
target_modules = { module= rda; };
Index: configure.ac
===
--- configure.ac(revision 175963)
+++ configure.ac(working copy)
@@ -443,6 +443,16 @@
;;
esac
+AC_PROG_LIBTOOL
+if test x$enable_shared = xyes ; then
+ case $host_cpu in
+ cygwin* | mingw* | pw32* | cegcc*)
+;;
+ *)
+libjava_disable_static=--disable-static
+ esac
+fi
+AC_SUBST(libjava_disable_static)
# Disable libmudflap on some systems.
if test x$enable_libmudflap = x ; then
Re: [patch] Disable static build for libjava
On 07/07/2011 07:56 PM, Andrew Haley wrote:
On 07/07/11 18:02, David Daney wrote:
On 07/07/2011 09:57 AM, Matthias Klose wrote:
On 07/07/2011 06:51 PM, David Daney wrote:
On 07/07/2011 09:27 AM, Matthias Klose wrote:
As discussed at the Google GCC gathering, disable the build of static
libraries
in libjava, which should cut the build time of libjava by 50%. The static
libjava build isn't useful out of the box, and I don't see it packaged by
Linux
distributions either.
The AC_PROG_LIBTOOL check is needed to get access to the enable_shared
macro.
I'm unsure about the check in the switch construct. Taken from
libtool.m4, and
determining the value of enable_shared_with_static_runtimes.
Ok for the trunk?
2011-07-07 Matthias Klosed...@ubuntu.com
* Makefile.def (target_modules/libjava): Pass
$(libjava_disable_static).
* configure.ac: Check for libtool, pass --disable-static
in libjava_disable_static.
* Makefile.in: Regenerate.
* configure: Likewise.
My autoconf fu is not what it used to be. It is fine if static libraries
are
disabled by default, but it should be possible to enable them from the
configure
command line. It is unclear to me if this patch does that.
no. I assume an extra option --enable-static-libjava would be needed.
Not being a libjava maintainer, I cannot force you to add something like
that as part of the patch, but I think it would be a good idea.
I think so.
Here is the updated patch, including the --enable-static-libjava option
ok for the trunk?
Matthias
gcc/
2011-07-07 Matthias Klose d...@ubuntu.com
* doc/install.texi: Document --enable-static-libjava.
toplevel
2011-07-07 Matthias Klose d...@ubuntu.com
* Makefile.tpl (EXTRA_CONFIGARGS_LIBJAVA): Define.
* Makefile.def (target_modules/libjava): Pass
$(EXTRA_CONFIGARGS_LIBJAVA).
* configure.ac: Check for libtool, pass --disable-static
in EXTRA_CONFIGARGS_LIBJAVA, if not configured with
--enable-static-libjava.
* Makefile.in: Regenerate.
* configure: Likewise.
Index: gcc/doc/install.texi
===
--- gcc/doc/install.texi (revision 175964)
+++ gcc/doc/install.texi (working copy)
@@ -1956,6 +1956,10 @@
@item --enable-browser-plugin
Build the gcjwebplugin web browser plugin.
+@item --enable-static-libjava
+Build static libraries in libjava. The default is to only build shared
+libraries if the target supports shared libraries.
+
@table @code
@item ansi
Use the single-byte @code{char} and the Win32 A functions natively,
Index: Makefile.tpl
===
--- Makefile.tpl (revision 175964)
+++ Makefile.tpl (working copy)
@@ -319,6 +319,8 @@
HOST_LIBELFLIBS = @libelflibs@
HOST_LIBELFINC = @libelfinc@
+EXTRA_CONFIGARGS_LIBJAVA = @EXTRA_CONFIGARGS_LIBJAVA@
+
# --
# Programs producing files for the BUILD machine
# --
Index: Makefile.def
===
--- Makefile.def (revision 175964)
+++ Makefile.def (working copy)
@@ -132,7 +132,8 @@
target_modules = { module= winsup; };
target_modules = { module= libgloss; no_check=true; };
target_modules = { module= libffi; };
-target_modules = { module= libjava; raw_cxx=true; };
+target_modules = { module= libjava; raw_cxx=true;
+ extra_configure_flags=$(EXTRA_CONFIGARGS_LIBJAVA); };
target_modules = { module= zlib; };
target_modules = { module= boehm-gc; };
target_modules = { module= rda; };
Index: configure.ac
===
--- configure.ac (revision 175964)
+++ configure.ac (working copy)
@@ -443,7 +443,27 @@
;;
esac
+AC_ARG_ENABLE(static-libjava,
+[AS_HELP_STRING([[--enable-static-libjava[=ARG]]],
+ [build static libjava @:@default=no@:@])],
+ENABLE_STATIC_LIBJAVA=$enableval,
+ENABLE_STATIC_LIBJAVA=no)
+enable_static_libjava=
+if test ${ENABLE_STATIC_LIBJAVA} = yes ; then
+ enable_static_libjava=yes
+fi
+AC_PROG_LIBTOOL
+if test x$enable_shared = xyes test x$enable_static_libjava != xyes ; then
+ case $host_cpu in
+ cygwin* | mingw* | pw32* | cegcc*)
+;;
+ *)
+EXTRA_CONFIGARGS_LIBJAVA=--disable-static
+ esac
+fi
+AC_SUBST(EXTRA_CONFIGARGS_LIBJAVA)
+
# Disable libmudflap on some systems.
if test x$enable_libmudflap = x ; then
case ${target} in
Re: [patch] Disable static build for libjava
On 07/07/2011 10:35 PM, Ralf Wildenhues wrote:
Hi Matthias,
On Thu, Jul 07, 2011 at 10:26:59PM +0200, Jakub Jelinek wrote:
On Thu, Jul 07, 2011 at 10:22:37PM +0200, Matthias Klose wrote:
+AC_PROG_LIBTOOL
This tests the wrong compiler and toolchain. The compiler you want
to test doesn't exist yet at the time this configure script is run.
So you might as well deduce the switch you need from a fixed set or
other GCC configure data.
Or you put AC_PROG_LIBTOOL in libjava/ but pass down the value of
enable_static_libjava as --en/disable-static there.
here is the updated patch. AC_PROG_LIBTOOL is already called in libjava/
ok to install?
Matthias
toplevel
2011-07-09 Matthias Klose d...@ubuntu.com
* Makefile.tpl (EXTRA_CONFIGARGS_LIBJAVA): Define.
* Makefile.def (target_modules/libjava): Pass
$(EXTRA_CONFIGARGS_LIBJAVA).
* configure.ac: Pass --disable-static in EXTRA_CONFIGARGS_LIBJAVA,
if not configured with --enable-static-libjava.
* Makefile.in: Regenerate.
* configure: Likewise.
gcc/
2011-07-09 Matthias Klose d...@ubuntu.com
* doc/install.texi: Document --enable-static-libjava.
Index: Makefile.tpl
===
--- Makefile.tpl(revision 176072)
+++ Makefile.tpl(working copy)
@@ -319,6 +319,8 @@
HOST_LIBELFLIBS = @libelflibs@
HOST_LIBELFINC = @libelfinc@
+EXTRA_CONFIGARGS_LIBJAVA = @EXTRA_CONFIGARGS_LIBJAVA@
+
# --
# Programs producing files for the BUILD machine
# --
Index: Makefile.def
===
--- Makefile.def(revision 176072)
+++ Makefile.def(working copy)
@@ -132,7 +132,8 @@
target_modules = { module= winsup; };
target_modules = { module= libgloss; no_check=true; };
target_modules = { module= libffi; };
-target_modules = { module= libjava; raw_cxx=true; };
+target_modules = { module= libjava; raw_cxx=true;
+ extra_configure_flags=$(EXTRA_CONFIGARGS_LIBJAVA); };
target_modules = { module= zlib; };
target_modules = { module= boehm-gc; };
target_modules = { module= rda; };
Index: configure.ac
===
--- configure.ac(revision 176072)
+++ configure.ac(working copy)
@@ -443,7 +443,21 @@
;;
esac
+AC_ARG_ENABLE(static-libjava,
+[AS_HELP_STRING([[--enable-static-libjava[=ARG]]],
+ [build static libjava @:@default=no@:@])],
+ENABLE_STATIC_LIBJAVA=$enableval,
+ENABLE_STATIC_LIBJAVA=no)
+enable_static_libjava=
+if test ${ENABLE_STATIC_LIBJAVA} = yes ; then
+ enable_static_libjava=yes
+fi
+if test x$enable_static_libjava != xyes ; then
+ EXTRA_CONFIGARGS_LIBJAVA=--disable-static
+fi
+AC_SUBST(EXTRA_CONFIGARGS_LIBJAVA)
+
# Disable libmudflap on some systems.
if test x$enable_libmudflap = x ; then
case ${target} in
Index: gcc/doc/install.texi
===
--- gcc/doc/install.texi(revision 176072)
+++ gcc/doc/install.texi(working copy)
@@ -1968,6 +1968,10 @@
@item --enable-browser-plugin
Build the gcjwebplugin web browser plugin.
+@item --enable-static-libjava
+Build static libraries in libjava. The default is to only build shared
+libraries.
+
@table @code
@item ansi
Use the single-byte @code{char} and the Win32 A functions natively,
Re: [PATCH] Build a bi-arch compiler on s390-linux-gnu
On 03/25/2009 04:30 PM, Andreas Krebbel wrote: 2009-03-23 Arthur Loiret aloi...@debian.org * config.gcc (s390-*-linux*): If 'enabled_targets' is 'all', build a bi-arch compiler defaulting to 31-bit. In this case: (tmake_file): Add s390/t-linux64. * doc/install.texi: Add s390-linux to the list of targets supporting --enable-targets=all. This is ok. Thanks! Now checked in. Matthias
Re: [PLUGIN] c-family files installation
On 07/11/2011 05:18 PM, Romain Geissler wrote: This patch add a new exception to the plugin header flattering strategy. c-family files can't be installed in the plugin include root directory as some other files like cp/cp-tree.h will look for them in the c-family directory. Furthermore, i had to correct an include in c-pretty-print.h so that it looks for c-common.h in the c-family directory. That way, headers will work out of the box when compiling a plugin, there is no need for additional include directory. Builds and installs fine Ok for the trunk (i have no write access) ? looks ok (but I cannot approve it). Almost the same patch submitted at http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01461.html, but this chunk unreviewed. Matthias
[patch] fix typo in doc/extend.texi, committed as obvious
fix a typo in doc/extend.texi, committed as obvious.
Matthias
2011-07-14 Matthias Klose d...@ubuntu.com
* doc/extend.texi (optimize attribute): Fix typo.
Index: doc/extend.texi
===
--- doc/extend.texi (revision 176263)
+++ doc/extend.texi (working copy)
@@ -3594,7 +3594,7 @@
@item cpu=@var{CPU}
@cindex @code{target(cpu=@var{CPU})} attribute
Specify the architecture to generate code for when compiling the
-function. If you select the @code{target(cpu=power7)} attribute when
+function. If you select the @code{target(cpu=power7)} attribute when
generating 32-bit code, VSX and Altivec instructions are not generated
unless you use the @option{-mabi=altivec} option on the command line.
Re: PATCH to support running the G++ testsuite in C++0x mode
On 07/15/2011 09:29 PM, Jason Merrill wrote: On 07/13/2011 04:28 PM, Jason Merrill wrote: I'm using --tool_opts to pass the extra -std=c++0x argument to the compiler. Previously in my own testing I've used --target_board=unix/-std=c++0x, but that is problematic because options from --target_board come after options from dg-options, leading to spurious failures on tests that explicitly specify -std=c++98. I also considered using the --additional_options flag which lib/g++.exp tries to support, but it doesn't work (runtest.exp treats any --a* as --all) and in any case is redundant with --tool_opts. Unfortunately, a bug in dejagnu means that --tool_opts breaks multilib support; see the URL in the patch and GCC bug 49741. So I've resurrected --additional_options, renamed to --extra_opts because runtest.exp will let that through. Applying to trunk. The change to the toplevel Makefile.in was made in the generated file. I didn't revert it with today's change. Matthias
[patch] [gcc/libgcc/ada/libstdc++] Match arm*-*-linux-*eabi* for ARM Linux/GNU EABI
gcc/config.gcc now allows matching arm*-*-linux-*eabi* instead of
arm*-*-linux-*eabi for ARM Linux/GNU EABI. This changes the matching in various
other places as well. arm-linux-gnueabihf is used as a triplet by some
distributions.
Ok for the trunk?
Matthias
gcc/testsuite/
2012-06-25 Matthias Klose d...@ubuntu.com
* lib/target-supports.exp (check_profiling_available): Match
arm*-*-linux-*eabi* for ARM Linux/GNU EABI.
gcc/ada/
2012-06-25 Matthias Klose d...@ubuntu.com
* gcc-interface/Makefile.in: Match arm*-*-linux-*eabi* for
ARM Linux/GNU EABI.
libgcc/
2012-06-25 Matthias Klose d...@ubuntu.com
* config.host: Match arm*-*-linux-*eabi* for ARM Linux/GNU EABI.
libstdc++-v3/
2012-06-25 Matthias Klose d...@ubuntu.com
* configure.host: Match arm*-*-linux-*eabi* for ARM Linux/GNU EABI.
* testsuite/20_util/make_signed/requirements/typedefs-2.cc: Likewise.
* testsuite/20_util/make_unsigned/requirements/typedefs-2.cc: Likewise.
libjava/
2012-06-25 Matthias Klose d...@ubuntu.com
* configure.ac: Match arm*-*-linux-*eabi* for ARM Linux/GNU EABI.
# DP: add support for arm-linux-*eabi* triplets; useful for armhf
--- a/src/libjava/configure.ac.orig
+++ b/src/libjava/configure.ac
@@ -924,7 +924,7 @@
# on Darwin -single_module speeds up loading of the dynamic libraries.
extra_ldflags_libjava=-Wl,-single_module
;;
-arm*linux*eabi)
+arm*-*-linux-*eabi*)
# Some of the ARM unwinder code is actually in libstdc++. We
# could in principle replicate it in libgcj, but it's better to
# have a dependency on libstdc++.
--- a/src/gcc/testsuite/lib/target-supports.exp.orig
+++ b/src/gcc/testsuite/lib/target-supports.exp
@@ -3235,7 +3235,7 @@
|| [istarget i?86-*-*]
|| [istarget x86_64-*-*]
|| [istarget alpha*-*-*]
-|| [istarget arm*-*-linux-gnueabi]
+|| [istarget arm*-*-linux-*eabi*]
|| [istarget bfin*-*linux*]
|| [istarget hppa*-*linux*]
|| [istarget s390*-*-*]
@@ -3266,7 +3266,7 @@
|| [istarget i?86-*-*]
|| [istarget x86_64-*-*]
|| [istarget alpha*-*-*]
-|| [istarget arm*-*-linux-gnueabi]
+|| [istarget arm*-*-linux-*eabi*]
|| [istarget hppa*-*linux*]
|| [istarget s390*-*-*]
|| [istarget powerpc*-*-*]
--- a/src/gcc/ada/gcc-interface/Makefile.in.orig
+++ b/src/gcc/ada/gcc-interface/Makefile.in
@@ -1846,7 +1846,7 @@
LIBRARY_VERSION := $(LIB_VERSION)
endif
-ifeq ($(strip $(filter-out arm% linux-gnueabi,$(arch) $(osys)-$(word
4,$(targ,)
+ifeq ($(strip $(filter-out arm%-linux,$(arch)-$(osys)) $(if $(findstring
eabi,$(word 4,$(targ))),,$(word 4,$(targ,)
LIBGNAT_TARGET_PAIRS = \
a-intnam.adsa-intnam-linux.ads \
s-inmaop.adbs-inmaop-posix.adb \
--- a/src/libstdc++-v3/configure.host.orig
+++ b/src/libstdc++-v3/configure.host
@@ -322,7 +322,7 @@
fi
esac
case ${host} in
- arm*-*-linux-*eabi)
+ arm*-*-linux-*eabi*)
port_specific_symbol_files=\$(srcdir)/../config/os/gnu-linux/arm-eabi-extra.ver
;;
esac
---
a/src/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs-2.cc.orig
+++
b/src/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs-2.cc
@@ -1,5 +1,5 @@
// { dg-options -std=gnu++0x -funsigned-char -fshort-enums }
-// { dg-options -std=gnu++0x -funsigned-char -fshort-enums
-Wl,--no-enum-size-warning { target arm*-*-linux*eabi } }
+// { dg-options -std=gnu++0x -funsigned-char -fshort-enums
-Wl,--no-enum-size-warning { target arm*-*-linux-*eabi* } }
// 2007-05-03 Benjamin Kosnik b...@redhat.com
//
---
a/src/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs-2.cc.orig
+++ b/src/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs-2.cc
@@ -1,5 +1,5 @@
// { dg-options -std=gnu++0x -funsigned-char -fshort-enums }
-// { dg-options -std=gnu++0x -funsigned-char -fshort-enums
-Wl,--no-enum-size-warning { target arm*-*-linux*eabi } }
+// { dg-options -std=gnu++0x -funsigned-char -fshort-enums
-Wl,--no-enum-size-warning { target arm*-*-linux-*eabi* } }
// 2007-05-03 Benjamin Kosnik b...@redhat.com
//
--- a/src/libgcc/config.host
+++ b/src/libgcc/config.host
@@ -334,7 +334,7 @@
arm*-*-linux*) # ARM GNU/Linux with ELF
tmake_file=${tmake_file} arm/t-arm t-fixedpoint-gnu-prefix
case ${host} in
- arm*-*-linux-*eabi)
+ arm*-*-linux-*eabi*)
tmake_file=${tmake_file} arm/t-elf arm/t-bpabi arm/t-linux-eabi
t-slibgcc-libgcc
tm_file=$tm_file arm/bpabi-lib.h
unwind_header=config/arm/unwind-arm.h
Re: [patch] support for multiarch systems
Please find attached the patch updated for trunk 20120625, x86 only, tested on
x86-linux-gnu, KFreeBSD and the Hurd.
I left in the comment about the multiarch names, but I'm fine to change/discard
it. It was first required by Joseph Myers, then not found necessary by Paolo
Bonzini.
Ok for the trunk?
Matthias
2012-06-25 Matthias Klose d...@ubuntu.com
* doc/invoke.texi: Document -print-multiarch.
* doc/install.texi: Document --enable-multiarch.
* doc/fragments.texi: Document MULTILIB_OSDIRNAMES, MULTIARCH_DIRNAME.
* configure.ac: Add --enable-multiarch option.
* configure.in: Regenerate.
* Makefile.in (s-mlib): Pass MULTIARCH_DIRNAME to genmultilib.
enable_multiarch, with_float: New macros.
if_multiarch: New macro, define in terms of enable_multiarch.
* genmultilib: Add new argument for the multiarch name.
* gcc.c (multiarch_dir): Define.
(for_each_path): Search for multiarch suffixes.
(driver_handle_option): Handle multiarch option.
(do_spec_1): Pass -imultiarch if defined.
(main): Print multiarch.
(set_multilib_dir): Separate multilib and multiarch names
from multilib_select.
(print_multilib_info): Ignore multiarch names in multilib_select.
* incpath.c (add_standard_paths): Search the multiarch include dirs.
* cppdeault.h (default_include): Document multiarch in multilib
member.
* cppdefault.c: [LOCAL_INCLUDE_DIR, STANDARD_INCLUDE_DIR] Add an
include directory for multiarch directories.
* common.opt: New options --print-multiarch and -imultilib.
* config.gcc: Add tmake fragments to tmake_file ( i386/t-kfreebsd
for i[34567]86-*-kfreebsd*-gnu and x86_64-*-kfreebsd*-gnu, i386/t-gnu
for i[34567]86-*-gnu*).
* config/i386/t-kfreebsd: Add multiarch names in
MULTILIB_OSDIRNAMES, define MULTIARCH_DIRNAME.
* config/i386/t-linux64: Likewise.
* config/i386/t-linux: Define MULTIARCH_DIRNAME.
* config/i386/t-gnu: Likewise.
Index: configure.ac
===
--- configure.ac(revision 188931)
+++ configure.ac(working copy)
@@ -623,6 +623,21 @@
[], [enable_multilib=yes])
AC_SUBST(enable_multilib)
+# Determine whether or not multiarch is enabled.
+AC_ARG_ENABLE(multiarch,
+[AS_HELP_STRING([--enable-multiarch],
+ [enable support for multiarch paths])],
+[case ${withval} in
+yes|no|auto-detect) enable_multiarch=$withval;;
+*) AC_MSG_ERROR(bad value ${withval} given for --enable-multiarch option) ;;
+esac], [enable_multiarch=auto-detect])
+AC_MSG_CHECKING(for multiarch configuration)
+AC_SUBST(enable_multiarch)
+AC_MSG_RESULT($enable_multiarch)
+
+# needed for setting the multiarch name on ARM
+AC_SUBST(with_float)
+
# Enable __cxa_atexit for C++.
AC_ARG_ENABLE(__cxa_atexit,
[AS_HELP_STRING([--enable-__cxa_atexit], [enable __cxa_atexit for C++])],
Index: cppdefault.c
===
--- cppdefault.c(revision 188931)
+++ cppdefault.c(working copy)
@@ -63,6 +63,7 @@
#endif
#ifdef LOCAL_INCLUDE_DIR
/* /usr/local/include comes before the fixincluded header files. */
+{ LOCAL_INCLUDE_DIR, 0, 0, 1, 1, 2 },
{ LOCAL_INCLUDE_DIR, 0, 0, 1, 1, 0 },
#endif
#ifdef PREFIX_INCLUDE_DIR
@@ -90,6 +91,7 @@
#endif
#ifdef NATIVE_SYSTEM_HEADER_DIR
/* /usr/include comes dead last. */
+{ NATIVE_SYSTEM_HEADER_DIR, NATIVE_SYSTEM_HEADER_COMPONENT, 0, 0, 1, 2 },
{ NATIVE_SYSTEM_HEADER_DIR, NATIVE_SYSTEM_HEADER_COMPONENT, 0, 0, 1, 0 },
#endif
{ 0, 0, 0, 0, 0, 0 }
Index: cppdefault.h
===
--- cppdefault.h(revision 188931)
+++ cppdefault.h(working copy)
@@ -43,9 +43,11 @@
C++. */
const char add_sysroot; /* FNAME should be prefixed by
cpp_SYSROOT. */
- const char multilib; /* FNAME should have the multilib path
- specified with -imultilib
- appended. */
+ const char multilib; /* FNAME should have appended
+ - the multilib path specified with -imultilib
+when 1 is passed,
+ - the multiarch path specified with
+-imultiarch, when 2 is passed. */
};
extern const struct default_include cpp_include_defaults[];
Index: Makefile.in
===
--- Makefile.in (revision 188931)
+++ Makefile.in (working copy)
@@ -350,6 +350,17 @@
enable_plugin = @enable_plugin@
+# Multiarch support
+enable_multiarch = @enable_multiarch@
+with_float = @with_float@
+ifeq ($(enable_multiarch),yes
Re: [patch] support for multiarch systems
On 25.06.2012 15:56, Joseph S. Myers wrote:
On Mon, 25 Jun 2012, Matthias Klose wrote:
Please find attached the patch updated for trunk 20120625, x86 only, tested
on
x86-linux-gnu, KFreeBSD and the Hurd.
This patch appears to include changes to config.gcc for other targets, not
mentioned in your ChangeLog entries. Please resubmit without those
changes, and submit them separately with their own rationale if needed.
my mistake, removed these bits now again.
2012-06-25 Matthias Klose d...@ubuntu.com
* doc/invoke.texi: Document -print-multiarch.
* doc/install.texi: Document --enable-multiarch.
* doc/fragments.texi: Document MULTILIB_OSDIRNAMES, MULTIARCH_DIRNAME.
* configure.ac: Add --enable-multiarch option.
* configure.in: Regenerate.
* Makefile.in (s-mlib): Pass MULTIARCH_DIRNAME to genmultilib.
enable_multiarch, with_float: New macros.
if_multiarch: New macro, define in terms of enable_multiarch.
* genmultilib: Add new argument for the multiarch name.
* gcc.c (multiarch_dir): Define.
(for_each_path): Search for multiarch suffixes.
(driver_handle_option): Handle multiarch option.
(do_spec_1): Pass -imultiarch if defined.
(main): Print multiarch.
(set_multilib_dir): Separate multilib and multiarch names
from multilib_select.
(print_multilib_info): Ignore multiarch names in multilib_select.
* incpath.c (add_standard_paths): Search the multiarch include dirs.
* cppdeault.h (default_include): Document multiarch in multilib
member.
* cppdefault.c: [LOCAL_INCLUDE_DIR, STANDARD_INCLUDE_DIR] Add an
include directory for multiarch directories.
* common.opt: New options --print-multiarch and -imultilib.
* config.gcc: Add tmake fragments to tmake_file ( i386/t-kfreebsd
for i[34567]86-*-kfreebsd*-gnu and x86_64-*-kfreebsd*-gnu, i386/t-gnu
for i[34567]86-*-gnu*).
* config/i386/t-kfreebsd: Add multiarch names in
MULTILIB_OSDIRNAMES, define MULTIARCH_DIRNAME.
* config/i386/t-linux64: Likewise.
* config/i386/t-linux: Define MULTIARCH_DIRNAME.
* config/i386/t-gnu: Likewise.
Index: configure.ac
===
--- configure.ac(revision 188931)
+++ configure.ac(working copy)
@@ -623,6 +623,21 @@
[], [enable_multilib=yes])
AC_SUBST(enable_multilib)
+# Determine whether or not multiarch is enabled.
+AC_ARG_ENABLE(multiarch,
+[AS_HELP_STRING([--enable-multiarch],
+ [enable support for multiarch paths])],
+[case ${withval} in
+yes|no|auto-detect) enable_multiarch=$withval;;
+*) AC_MSG_ERROR(bad value ${withval} given for --enable-multiarch option) ;;
+esac], [enable_multiarch=auto-detect])
+AC_MSG_CHECKING(for multiarch configuration)
+AC_SUBST(enable_multiarch)
+AC_MSG_RESULT($enable_multiarch)
+
+# needed for setting the multiarch name on ARM
+AC_SUBST(with_float)
+
# Enable __cxa_atexit for C++.
AC_ARG_ENABLE(__cxa_atexit,
[AS_HELP_STRING([--enable-__cxa_atexit], [enable __cxa_atexit for C++])],
Index: cppdefault.c
===
--- cppdefault.c(revision 188931)
+++ cppdefault.c(working copy)
@@ -63,6 +63,7 @@
#endif
#ifdef LOCAL_INCLUDE_DIR
/* /usr/local/include comes before the fixincluded header files. */
+{ LOCAL_INCLUDE_DIR, 0, 0, 1, 1, 2 },
{ LOCAL_INCLUDE_DIR, 0, 0, 1, 1, 0 },
#endif
#ifdef PREFIX_INCLUDE_DIR
@@ -90,6 +91,7 @@
#endif
#ifdef NATIVE_SYSTEM_HEADER_DIR
/* /usr/include comes dead last. */
+{ NATIVE_SYSTEM_HEADER_DIR, NATIVE_SYSTEM_HEADER_COMPONENT, 0, 0, 1, 2 },
{ NATIVE_SYSTEM_HEADER_DIR, NATIVE_SYSTEM_HEADER_COMPONENT, 0, 0, 1, 0 },
#endif
{ 0, 0, 0, 0, 0, 0 }
Index: cppdefault.h
===
--- cppdefault.h(revision 188931)
+++ cppdefault.h(working copy)
@@ -43,9 +43,11 @@
C++. */
const char add_sysroot; /* FNAME should be prefixed by
cpp_SYSROOT. */
- const char multilib; /* FNAME should have the multilib path
- specified with -imultilib
- appended. */
+ const char multilib; /* FNAME should have appended
+ - the multilib path specified with -imultilib
+when 1 is passed,
+ - the multiarch path specified with
+-imultiarch, when 2 is passed. */
};
extern const struct default_include cpp_include_defaults[];
Index: Makefile.in
===
--- Makefile.in (revision 188931)
+++ Makefile.in (working copy)
@@ -350,6 +350,17
Re: [patch] [gcc/libgcc/ada/libstdc++] Match arm*-*-linux-*eabi* for ARM Linux/GNU EABI
On 25.06.2012 15:22, Richard Earnshaw wrote: On 25/06/12 13:08, Matthias Klose wrote: gcc/config.gcc now allows matching arm*-*-linux-*eabi* instead of arm*-*-linux-*eabi for ARM Linux/GNU EABI. This changes the matching in various other places as well. arm-linux-gnueabihf is used as a triplet by some distributions. Ok for the trunk? now that all arm-linux ports are EABI conforming, why can't this just become arm*-*-linux* ? I assume it could. But I didn't check for other places where this would be needed.
Re: [patch] [gcc/libgcc/ada/libstdc++] Match arm*-*-linux-*eabi* for ARM Linux/GNU EABI
On 25.06.2012 18:21, Matthias Klose wrote: On 25.06.2012 15:22, Richard Earnshaw wrote: On 25/06/12 13:08, Matthias Klose wrote: gcc/config.gcc now allows matching arm*-*-linux-*eabi* instead of arm*-*-linux-*eabi for ARM Linux/GNU EABI. This changes the matching in various other places as well. arm-linux-gnueabihf is used as a triplet by some distributions. Ok for the trunk? now that all arm-linux ports are EABI conforming, why can't this just become arm*-*-linux* ? I assume it could. But I didn't check for other places where this would be needed. $ grep -r 'arm[^_]*eabi' . |egrep -v 'ChangeLog|\.svn/'|wc -l 87 this seems to be a larger change, which should have been committed when the old abi targets were deprecated. I'd like to get the eabi* change in first. Matthias
Re: [patch] support for multiarch systems
On 28.06.2012 12:01, Thomas Schwinge wrote:
Hi!
On Mon, 25 Jun 2012 18:19:26 +0200, Matthias Klose d...@ubuntu.com
wrote:
On 25.06.2012 15:56, Joseph S. Myers wrote:
On Mon, 25 Jun 2012, Matthias Klose wrote:
Please find attached the patch updated for trunk 20120625, x86 only,
tested on x86-linux-gnu, KFreeBSD and the Hurd.
2012-06-25 Matthias Klose d...@ubuntu.com
* doc/invoke.texi: Document -print-multiarch. * doc/install.texi:
Document --enable-multiarch. * doc/fragments.texi: Document
MULTILIB_OSDIRNAMES, MULTIARCH_DIRNAME. * configure.ac: Add
--enable-multiarch option. * configure.in: Regenerate. * Makefile.in
(s-mlib): Pass MULTIARCH_DIRNAME to genmultilib. enable_multiarch,
with_float: New macros. if_multiarch: New macro, define in terms of
enable_multiarch. * genmultilib: Add new argument for the multiarch
name. * gcc.c (multiarch_dir): Define. (for_each_path): Search for
multiarch suffixes. (driver_handle_option): Handle multiarch option.
(do_spec_1): Pass -imultiarch if defined. (main): Print multiarch.
(set_multilib_dir): Separate multilib and multiarch names from
multilib_select. (print_multilib_info): Ignore multiarch names in
multilib_select. * incpath.c (add_standard_paths): Search the multiarch
include dirs. * cppdeault.h (default_include): Document multiarch in
multilib member. * cppdefault.c: [LOCAL_INCLUDE_DIR,
STANDARD_INCLUDE_DIR] Add an include directory for multiarch
directories. * common.opt: New options --print-multiarch and -imultilib.
* config.gcc: Add tmake fragments to tmake_file ( i386/t-kfreebsd for
i[34567]86-*-kfreebsd*-gnu and x86_64-*-kfreebsd*-gnu, i386/t-gnu for
i[34567]86-*-gnu*). * config/i386/t-kfreebsd: Add multiarch names in
MULTILIB_OSDIRNAMES, define MULTIARCH_DIRNAME. * config/i386/t-linux64:
Likewise. * config/i386/t-linux: Define MULTIARCH_DIRNAME. *
config/i386/t-gnu: Likewise.
As I said before, »config/i386/t-{gnu,kfreebsd,linux}« are new files.
Instead of repeating: my comments from
http://news.gmane.org/find-root.php?message_id=%3C87zk94cg1h.fsf%40schwinge.name%3E
as well as the follow-up still hold.
Like
* config/i386/t-gnu: New, define MULTIARCH_DIRNAME.
?
Index: genmultilib
=== ---
genmultilib (revision 188931) +++ genmultilib (working copy) @@ -84,6
+84,8 @@ # This argument can be used together with MULTILIB_EXCEPTIONS
and will take # effect after the MULTILIB_EXCEPTIONS.
+# The optional eight argument is the multiarch name.
»ninth argument«.
fixed.
Re: [PATCH] Clarify cloog install docs
On 03.07.2012 15:37, Richard Guenther wrote:
People are running into issues when mixing cloog built against isl 0.08
and gcc building against isl 0.10 (which is expected I guess).
CLooG needs to be configured to use GMP
+internally, use @option{--with-bits=gmp} to direct it to do that.
why is this necessary? Even with this option I end up with a dependency on the
system gmp library. Or do you need to configure --with-gmp=build explicitly? Or
how can the system gmp be built that it can be used by cloog?
Matthias
Re: [patch v2] support for multiarch systems
Please find attached v2 of the patch updated for trunk 20120706, x86 only,
tested on
x86-linux-gnu, KFreeBSD and the Hurd.
I left in the comment about the multiarch names, but I'm fine to change/discard
it. It was first required by Joseph Myers, then not found necessary by Paolo
Bonzini. The patch includes the changes suggested by Thomas Schwinge.
Ok for the trunk?
Matthias
2012-06-25 Matthias Klose d...@ubuntu.com
* doc/invoke.texi: Document -print-multiarch.
* doc/install.texi: Document --enable-multiarch.
* doc/fragments.texi: Document MULTILIB_OSDIRNAMES, MULTIARCH_DIRNAME.
* configure.ac: Add --enable-multiarch option.
* configure.in: Regenerate.
* Makefile.in (s-mlib): Pass MULTIARCH_DIRNAME to genmultilib.
enable_multiarch, with_float: New macros.
if_multiarch: New macro, define in terms of enable_multiarch.
* genmultilib: Add new argument for the multiarch name.
* gcc.c (multiarch_dir): Define.
(for_each_path): Search for multiarch suffixes.
(driver_handle_option): Handle multiarch option.
(do_spec_1): Pass -imultiarch if defined.
(main): Print multiarch.
(set_multilib_dir): Separate multilib and multiarch names
from multilib_select.
(print_multilib_info): Ignore multiarch names in multilib_select.
* incpath.c (add_standard_paths): Search the multiarch include dirs.
* cppdeault.h (default_include): Document multiarch in multilib
member.
* cppdefault.c: [LOCAL_INCLUDE_DIR, STANDARD_INCLUDE_DIR] Add an
include directory for multiarch directories.
* common.opt: New options --print-multiarch and -imultilib.
* config.gcc i[34567]86-*-linux* | x86_64-*-linux* (tmake_file):
Include i386/t-linux.
i[34567]86-*-kfreebsd*-gnu | x86_64-*-kfreebsd*-gnu (tmake_file):
Include i386/t-kfreebsd.
i[34567]86-*-gnu* (tmake_file): Include i386/t-gnu.
* config/i386/t-linux64: Add multiarch names in
MULTILIB_OSDIRNAMES, define MULTIARCH_DIRNAME.
* config/i386/t-gnu: New file.
* config/i386/t-kfreebsd: Likewise.
* config/i386/t-linux: Likewise.
Index: configure.ac
===
--- configure.ac(revision 188931)
+++ configure.ac(working copy)
@@ -623,6 +623,21 @@
[], [enable_multilib=yes])
AC_SUBST(enable_multilib)
+# Determine whether or not multiarch is enabled.
+AC_ARG_ENABLE(multiarch,
+[AS_HELP_STRING([--enable-multiarch],
+ [enable support for multiarch paths])],
+[case ${withval} in
+yes|no|auto-detect) enable_multiarch=$withval;;
+*) AC_MSG_ERROR(bad value ${withval} given for --enable-multiarch option) ;;
+esac], [enable_multiarch=auto-detect])
+AC_MSG_CHECKING(for multiarch configuration)
+AC_SUBST(enable_multiarch)
+AC_MSG_RESULT($enable_multiarch)
+
+# needed for setting the multiarch name on ARM
+AC_SUBST(with_float)
+
# Enable __cxa_atexit for C++.
AC_ARG_ENABLE(__cxa_atexit,
[AS_HELP_STRING([--enable-__cxa_atexit], [enable __cxa_atexit for C++])],
Index: cppdefault.c
===
--- cppdefault.c(revision 188931)
+++ cppdefault.c(working copy)
@@ -63,6 +63,7 @@
#endif
#ifdef LOCAL_INCLUDE_DIR
/* /usr/local/include comes before the fixincluded header files. */
+{ LOCAL_INCLUDE_DIR, 0, 0, 1, 1, 2 },
{ LOCAL_INCLUDE_DIR, 0, 0, 1, 1, 0 },
#endif
#ifdef PREFIX_INCLUDE_DIR
@@ -90,6 +91,7 @@
#endif
#ifdef NATIVE_SYSTEM_HEADER_DIR
/* /usr/include comes dead last. */
+{ NATIVE_SYSTEM_HEADER_DIR, NATIVE_SYSTEM_HEADER_COMPONENT, 0, 0, 1, 2 },
{ NATIVE_SYSTEM_HEADER_DIR, NATIVE_SYSTEM_HEADER_COMPONENT, 0, 0, 1, 0 },
#endif
{ 0, 0, 0, 0, 0, 0 }
Index: cppdefault.h
===
--- cppdefault.h(revision 188931)
+++ cppdefault.h(working copy)
@@ -43,9 +43,11 @@
C++. */
const char add_sysroot; /* FNAME should be prefixed by
cpp_SYSROOT. */
- const char multilib; /* FNAME should have the multilib path
- specified with -imultilib
- appended. */
+ const char multilib; /* FNAME should have appended
+ - the multilib path specified with -imultilib
+when 1 is passed,
+ - the multiarch path specified with
+-imultiarch, when 2 is passed. */
};
extern const struct default_include cpp_include_defaults[];
Index: Makefile.in
===
--- Makefile.in (revision 188931)
+++ Makefile.in (working copy)
@@ -350,6 +350,17 @@
enable_plugin
Re: [RFC PATCH] update to libtool-2.4.2 and regenerate
On 10/28/2011 10:33 AM, Rainer Orth wrote: Markus Trippelsdorf mar...@trippelsdorf.de writes: By popular demand, I've prepared a patch that updates the in-tree libtool to version 2.4.2. It is needed for lto-bootstrap with -fno-fat-lto-objects and FreeBSD10.x versions. I see that your patch doesn't deal with libgo/config, where a private copy of libtool is kept. Would it be possible to get rid of that, given that 2.4.2 does support Go? same for libjava/libltdl
Re: [build] Restore arm-eabi bootstrap (PR target/50978)
On 11/04/2011 10:58 AM, Rainer Orth wrote: Matthias Klose d...@ubuntu.com writes: emutls_s.o indeed isn't built with -fPIC (it is on the 4.6 branch); PICFLAG in libgcc/Makefile is set but apparently not used. I think I see what's going on: config/arm/t-elf (and config/arm/t-strongarm-elf) override HOST_LIBGCC2_CFLAGS instead of appending to it. This way, we loose PICFLAG from config/t-libgcc-pic. Could you try that change? yes, using += gets my behind this point, now in stage2. thanks, Matthias
[patch] fix typo in gcc/java/expr.c
fix typo in message, committed as obvious. Matthias 2011-12-03 Matthias Klose d...@ubuntu.com * expr.c (SPECIAL_WIDE): Fix typo in message. Index: gcc/java/expr.c === --- gcc/java/expr.c (revision 181969) +++ gcc/java/expr.c (working copy) @@ -3546,7 +3546,7 @@ break; \ } \ default: \ -error (unrecogized wide sub-instruction); \ +error (unrecognized wide sub-instruction); \ } \ }
Re: [google] Normalize version number for google/gcc-4_6 (issue4454049)
On 05/02/2011 09:53 PM, Diego Novillo wrote: Since google/gcc-4_6 follows the 4.6 branch, changes in minor revisions cause unnecessary churn in directory names. Fixed with this. OK for google/gcc-4_6? Google ref 4335466. * BASE-VER: Change to 4.6.x-google. diff --git a/gcc/BASE-VER b/gcc/BASE-VER index 4110f74..33d4edd 100644 --- a/gcc/BASE-VER +++ b/gcc/BASE-VER @@ -1 +1 @@ -4.6.1-google +4.6.x-google is this enough? the subminor version number is encoded in more places, e.g. C++ headers, Go libraries, jar files. For the Debian/Ubuntu packaging I'm just using symlinks from 4.6.x to 4.6 to avoid this kind of dependency. Now that the -V option isn't supported anymore, maybe this could be addressed with something like a new configure option --version-alias=value, similar to the target alias. Matthias
Re: [PATCH 2/2] document ISL requirement for GCC installation
On 08/13/2011 06:02 PM, Sebastian Pop wrote: On Sat, Aug 13, 2011 at 10:32, Joseph S. Myers jos...@codesourcery.com wrote: I advise either removing the option for CLooG to use bundled ISL, or making the bundled version the recommended version for GCC. Having too many ways to configure things is bad. I would prefer using the ISL bundled with CLooG and not have to provide a way to configure GCC with ISL. which would be exactly the way no distribution would use it. So please just don't bundle ISL with CLoog. Matthias
[patch] support for multiarch systems
Multiarch [1] is the term being used to refer to the capability of a system to
install and run applications of multiple different binary targets on the same
system. The idea and name of multiarch dates back to 2004/2005 [2] (to be
confused with multiarch in glibc).
Multiarch defines new system directories for headers and libraries/object files:
/usr/include/multiarch
/lib/multiarch
/usr/lib/multiarch
/usr/local/include/multiarch
/usr/local/lib/multiarch
The attached patch
- searches for multiarch subdirectories in the list of
startfile_prefixes
- passes the option -imultiarch to the compiler binaries
- the compiler binaries add the multiarch include paths
to the system include path.
- adds a driver option -print-multiarch
The multiarch triplets are defined in the target specific tmake files, and
provided for all known existing multiarch implementations (currently Debian,
Ubuntu and derivatives). For non-multilib'd configurations, the triplet is
defined in MULTIARCH_DIRNAME, for multilib'd configurations each directory in
MULTILIB_OSDIRNAMES gets an multiarch directory associated, separated by a colon
(e.g. ../lib:x86_64-linux-gnu). The multiarch names are as used by Debian, the
mips names go back to a discussion from 2006 [3] to match the ones for glibc.
Tested on non-multilib'd and multilib'd systems, both native and cross builds.
Ok for the trunk?
Matthias
[1] http://wiki.debian.org/Multiarch
[2] http://debconf5.debconf.org/comas/general/proposals/27.html
[3] http://lists.debian.org/debian-mips/2006/03/msg4.html
2011-08-20 Matthias Klose d...@ubuntu.com
* doc/invoke.texi: Document -print-multiarch.
* Makefile.in (s-mlib): Pass MULTIARCH_DIRNAME to genmultilib.
* genmultilib: Add new option for the multiarch name.
* gcc.c (multiarch_dir): Define.
(for_each_path): Search for multiarch suffixes.
(driver_handle_option): Handle multiarch option.
(do_spec_1): Pass -imultiarch if defined.
(main): Print multiarch.
(set_multilib_dir): Separate multilib and multiarch names
from multilib_select.
(print_multilib_info): Ignore multiarch names in multilib_select.
* incpath.c (add_standard_paths): Search the multiarch include dirs.
* cppdeault.h (default_include): Document multiarch in multilib
member.
* cppdefault.c: [LOCAL_INCLUDE_DIR, STANDARD_INCLUDE_DIR] Add an
include directory for multiarch directories.
* common.opt: New options --print-multiarch and -imultilib.
* config/s390/t-linux64: Add multiarch names in MULTILIB_OSDIRNAMES.
* config/sparc/t-linux64: Likewise.
* config/powerpc/t-linux64: Likewise.
* config/i386/t-linux64: Likewise.
* config/mips/t-linux64: Likewise.
* config/alpha/t-linux: Define MULTIARCH_DIRNAME.
* config/arm/t-linux: Likewise.
* config/i386/t-linux: Likewise.
* config/pa/t-linux: Likewise.
* config/sparc/t-linux: Likewise.
* config/ia64/t-glibc: Define MULTIARCH_DIRNAME for linux target.
* gcc/config/i386/t-gnu: New, Define MULTIARCH_DIRNAME.
* gcc/config/i386/t-kfreebsd: New, Define MULTIARCH_DIRNAME and
MULTILIB_OSDIRNAMES.
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 177846)
+++ gcc/doc/invoke.texi (working copy)
@@ -5937,6 +5937,11 @@
@file{../lib32}, or if OS libraries are present in @file{lib/@var{subdir}}
subdirectories it prints e.g.@: @file{amd64}, @file{sparcv9} or @file{ev6}.
+@item -print-multiarch
+@opindex print-multiarch
+Print the path to OS libraries for the selected multiarch,
+relative to some @file{lib} subdirectory.
+
@item -print-prog-name=@var{program}
@opindex print-prog-name
Like @option{-print-file-name}, but searches for a program such as @samp{cpp}.
Index: gcc/incpath.c
===
--- gcc/incpath.c (revision 177846)
+++ gcc/incpath.c (working copy)
@@ -150,8 +150,14 @@
if (!filename_ncmp (p-fname, cpp_GCC_INCLUDE_DIR, len))
{
char *str = concat (iprefix, p-fname + len, NULL);
- if (p-multilib imultilib)
+ if (p-multilib == 1 imultilib)
str = concat (str, dir_separator_str, imultilib, NULL);
+ else if (p-multilib == 2)
+ {
+ if (!imultiarch)
+ continue;
+ str = concat (str, dir_separator_str, imultiarch, NULL);
+ }
add_path (str, SYSTEM, p-cxx_aware, false);
}
}
@@ -195,8 +201,14 @@
else
str = update_path (p-fname, p-component);
- if (p-multilib imultilib)
+ if (p-multilib == 1 imultilib)
str = concat
[patch] PR25508 - document MULTILIB_OSDIRNAMES
document MULTILIB_OSDIRNAMES, copied from genmultilib.
Ok for the trunk?
Matthias
PR bootstrap/25508
* doc/fragments.texi: Document MULTILIB_OSDIRNAMES.
Index: gcc/doc/fragments.texi
===
--- gcc/doc/fragments.texi (revision 177846)
+++ gcc/doc/fragments.texi (working copy)
@@ -128,6 +128,19 @@
of options to be used for all builds. If you set this, you should
probably set @code{CRTSTUFF_T_CFLAGS} to a dash followed by it.
+@findex MULTILIB_OSDIRNAMES
+@item MULTILIB_OSDIRNAMES
+If @code{MULTILIB_OPTIONS} is used, this variable specifies the list
+of OS subdirectory names. The format is either the same as of
+@code{MULTILIB_DIRNAMES}, or a set of mappings. When it is the same
+as @code{MULTILIB_DIRNAMES}, it describes the multilib directories
+using OS conventions, rather than GCC conventions. When it is a set
+of mappings of the form @code{gccdir=osdir}, the left side gives the
+GCC convention and the right gives the equivalent OS defined location.
+If the osdir part begins with a !, the os directory names are used
+exclusively. Use the mapping when there is no one-to-one equivalence
+between GCC levels and the OS.
+
@findex NATIVE_SYSTEM_HEADER_DIR
@item NATIVE_SYSTEM_HEADER_DIR
If the default location for system headers is not @file{/usr/include},
Re: [patch] PR25508 - document MULTILIB_OSDIRNAMES
On 08/21/2011 12:21 AM, Joseph S. Myers wrote:
On Sat, 20 Aug 2011, Matthias Klose wrote:
+@findex MULTILIB_OSDIRNAMES
+@item MULTILIB_OSDIRNAMES
+If @code{MULTILIB_OPTIONS} is used, this variable specifies the list
+of OS subdirectory names. The format is either the same as of
+@code{MULTILIB_DIRNAMES}, or a set of mappings. When it is the same
+as @code{MULTILIB_DIRNAMES}, it describes the multilib directories
+using OS conventions, rather than GCC conventions. When it is a set
I think more explanation is needed of what this means (where OS
conventions are used and where GCC conventions are used).
well, could you point me to the GCC conventions?
Re: [patch] support for multiarch systems
On 08/20/2011 10:07 PM, Jakub Jelinek wrote: On Sat, Aug 20, 2011 at 09:51:33PM +0200, Matthias Klose wrote: Tested on non-multilib'd and multilib'd systems, both native and cross builds. Ok for the trunk? I don't think we want to do this unconditionally, we already search way too many directories by default. This is a Debian/Ubuntu specific setup, I don't think many others are going to use such a setup. So, IMHO you should make it configure time selectable whether those extra dirs are searched or not. And by default either don't enable it, or enable it only on Debian/Ubuntu. Ok, I made it conditional, enabled only if the crti.o file is found in a multiarch path.
Re: [patch] support for multiarch systems
On 08/20/2011 10:39 PM, Joseph S. Myers wrote: On Sat, 20 Aug 2011, Matthias Klose wrote: The multiarch triplets are defined in the target specific tmake files, and provided for all known existing multiarch implementations (currently Debian, Ubuntu and derivatives). For non-multilib'd configurations, the triplet is Is there a specification somewhere of what the various triplets mean? there is https://lists.linux-foundation.org/pipermail/lsb-discuss/2011-February/006674.html http://wiki.debian.org/Multiarch/Tuples but the documentation is not up to date. The tuples in use are: $ for a in alpha amd64 armel armhf hppa i386 ia64 mips mipsel powerpc powerpcspe ppc64 s390 s390x sh4 sparc sparc64 kfreebsd-i386 kfreebsd-amd64 hurd-i386; do dpkg-architecture -a$a -qDEB_HOST_MULTIARCH 2/dev/null; done alpha-linux-gnu x86_64-linux-gnu arm-linux-gnueabi arm-linux-gnueabihf hppa-linux-gnu i386-linux-gnu ia64-linux-gnu mips-linux-gnu mipsel-linux-gnu powerpc-linux-gnu powerpc-linux-gnuspe powerpc64-linux-gnu s390-linux-gnu s390x-linux-gnu sh4-linux-gnu sparc-linux-gnu sparc64-linux-gnu i386-kfreebsd-gnu x86_64-kfreebsd-gnu i386-gnu defined in MULTIARCH_DIRNAME, for multilib'd configurations each directory in MULTILIB_OSDIRNAMES gets an multiarch directory associated, separated by a colon I don't see any documentation in fragments.texi for this (MULTIARCH_DIRNAME is new so certainly needs documenting, even if you get away with not adding to the nonexistent documentation for MULTILIB_OSDIRNAMES (PR 25508)). well, I hope I get away with copying it from genmultilib without closing the report ;) (e.g. ../lib:x86_64-linux-gnu). The multiarch names are as used by Debian, the Does this work with the gccdir=osdir and gccdir=!osdir cases before the colon? amd64 is configured this way, and I don't handle the !osdir case other than for the multilib osdir. mips names go back to a discussion from 2006 [3] to match thee, ones for glibc. For x86, shouldn't a name be allocated for x32? maybe, but I didn't see a port yet. For m68k, classic m68k and ColdFire have incompatible ABIs. So you need to define what m68k-linux-gnu means of the two ABIs. Unfortunately building for ColdFire has been broken for some time, since http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01845.html (this ought to have been dependent on the --with-arch configurey). it's the classic m68k. yes, it has to be defined. For 32-bit Power, hard-float and soft-float ABIs are incompatible. Furthermore, the soft-float ABI is used at function-calling level for e500v1 and e500v2 - but there are differences in the details of the glibc symbols exported (and at least the fenv.h ABI is incompatible between soft-float and e500). So actually there are four variants at the glibc level. You need to define what powerpc-linux-gnu means and avoid it being used for anything incompatible. same here. powerpc-linux-gnu is the hard-float one. Debian has an e500 port in development which currently uses powerpc-linux-gnuspe For MIPS, the hard-float and soft-float ABIs are incompatible. So you need twelve triplets, not six. yes. but I didn't see a soft-float mips port yet. For ARM, you have a ChangeLog entry with no corresponding patch. You need to distinguish big and little endian; old ABI, EABI soft-float ABI and EABI hard-float ABI (six triplets). ok, added. Debian has little endian ports only. I see that dpkg treats the obsolete armeb port as armeb-linux-gnu. Not all of those variants necessarily are configurable in a multilib configuration in the FSF tree (the e500 variants can be achieved with powerpc-linux-gnuspe triplets, for example, but those don't have other multilibs). So maybe some of the names won't actually appear in the FSF sources - but you still need to define the semantics of the names that do appear (whether in the manuals, on the GCC wiki or elsewhere) and preferably have somewhere to define semantics for the names not used in multilib configurations in FSF GCC. For now, the multiarch documentation should be consolidated; I would like to add a link from the FCC wiki to this documentation mentioned above. Matthias
Re: [patch] support for multiarch systems
On 08/20/2011 09:51 PM, Matthias Klose wrote:
Multiarch [1] is the term being used to refer to the capability of a system to
install and run applications of multiple different binary targets on the same
system. The idea and name of multiarch dates back to 2004/2005 [2] (to be
confused with multiarch in glibc).
attached is an updated patch which includes feedback from Jakub and Joseph.
Matthias
2011-08-21 Matthias Klose d...@ubuntu.com
* doc/invoke.texi: Document -print-multiarch.
* doc/install.texi: Document --enable-multiarch.
* doc/fragments.texi (MULTILIB_OSDIRNAMES): Document optional
multiarch name. (MULTIARCH_DIRNAME): Document.
* configure.ac: New option --enable-multiarch. Substitute with_float.
* configure: Regenerate.
* Makefile.in (s-mlib): Pass MULTIARCH_DIRNAME to genmultilib.
(if_multiarch): Helper macro for use in tmake_files.
(with_float): Define.
* genmultilib: Add new option for the multiarch name.
* gcc.c (multiarch_dir): Define.
(for_each_path): Search for multiarch suffixes.
(driver_handle_option): Handle multiarch option.
(do_spec_1): Pass -imultiarch if defined.
(main): Print multiarch.
(set_multilib_dir): Separate multilib and multiarch names
from multilib_select.
(print_multilib_info): Ignore multiarch names in multilib_select.
* incpath.c (add_standard_paths): Search the multiarch include dirs.
* cppdeault.h (default_include): Document multiarch in multilib
member.
* cppdefault.c: [LOCAL_INCLUDE_DIR, STANDARD_INCLUDE_DIR] Add an
include directory for multiarch directories.
* common.opt: New options --print-multiarch and -imultilib.
* config/s390/t-linux64: Add multiarch names in MULTILIB_OSDIRNAMES.
* config/sparc/t-linux64: Likewise.
* config/powerpc/t-linux64: Likewise.
* config/i386/t-linux64: Likewise.
* config/mips/t-linux64: Likewise.
* config/alpha/t-linux: Define MULTIARCH_DIRNAME.
* config/arm/t-linux: Likewise.
* config/i386/t-linux: Likewise.
* config/pa/t-linux: Likewise.
* config/sparc/t-linux: Likewise.
* config/ia64/t-glibc: Define MULTIARCH_DIRNAME for linux target.
* gcc/config/i386/t-gnu: New, Define MULTIARCH_DIRNAME.
* gcc/config/i386/t-kfreebsd: New, Define MULTIARCH_DIRNAME and
MULTILIB_OSDIRNAMES.
Index: gcc/doc/fragments.texi
===
--- gcc/doc/fragments.texi (revision 177846)
+++ gcc/doc/fragments.texi (working copy)
@@ -128,6 +128,33 @@
of options to be used for all builds. If you set this, you should
probably set @code{CRTSTUFF_T_CFLAGS} to a dash followed by it.
+@findex MULTILIB_OSDIRNAMES
+@item MULTILIB_OSDIRNAMES
+If @code{MULTILIB_OPTIONS} is used, this variable specifies the list
+of OS subdirectory names. The format is either the same as of
+@code{MULTILIB_DIRNAMES}, or a set of mappings. When it is the same
+as @code{MULTILIB_DIRNAMES}, it describes the multilib directories
+using OS conventions, rather than GCC conventions. When it is a set
+of mappings of the form @var{gccdir}=@var{osdir}, the left side gives
+the GCC convention and the right gives the equivalent OS defined
+location. If the @var{osdir} part begins with a @samp{!}, the os
+directory names are used exclusively. Use the mapping when there is
+no one-to-one equivalence between GCC levels and the OS.
+
+For multilib enabled configurations (see @code{MULTIARCH_DIRNAME})
+below), the multilib name is appended to each directory name, separated
+by a colon (e.g. @samp{../lib:x86_64-linux-gnu}).
+
+@findex MULTIARCH_DIRNAME
+@item MULTIARCH_DIRNAME
+If @code{MULTIARCH_DIRNAME} is used, this variable specifies the
+multiarch name for this configuration. For multiarch enabled
+configurations it is used to search libraries and crt files in
+@file{/lib/@var{multiarch}} and @file{/usr/lib/@var{multiarch}}, and
+system header files in @file{/usr/include/@var{multiarch}}.
+@code{MULTIARCH_DIRNAME} is not used for multilib enabled
+configurations, but encoded in @code{MULTILIB_OSDIRNAMES} instead.
+
@findex NATIVE_SYSTEM_HEADER_DIR
@item NATIVE_SYSTEM_HEADER_DIR
If the default location for system headers is not @file{/usr/include},
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 177846)
+++ gcc/doc/invoke.texi (working copy)
@@ -5937,6 +5937,11 @@
@file{../lib32}, or if OS libraries are present in @file{lib/@var{subdir}}
subdirectories it prints e.g.@: @file{amd64}, @file{sparcv9} or @file{ev6}.
+@item -print-multiarch
+@opindex print-multiarch
+Print the path to OS libraries for the selected multiarch,
+relative to some @file{lib} subdirectory.
+
@item -print-prog-name=@var{program}
@opindex print-prog-name
[patch] revert an obsolete part from the mips-triarch checkin
While looking at the multiarch patches, I noticed that a previous change is not necessary. MULTILIB_DEFAULTS is handled in config/mips/mips.h. Matthias gcc/ 2011-08-22 Matthias Klose d...@debian.org Revert: 2011-07-11 Arthur Loiret aloi...@debian.org Matthias Klose d...@debian.org * config/mips/t-linux64 (MULTILIB_DIRNAMES): Set to 'n32 . 64' if tm_defines contains MIPS_ABI_DEFAULT ABI_32, to follow the glibc convention. Index: gcc/config/mips/t-linux64 === --- gcc/config/mips/t-linux64 (revision 177952) +++ gcc/config/mips/t-linux64 (working copy) @@ -17,11 +17,7 @@ # http://www.gnu.org/licenses/. MULTILIB_OPTIONS = mabi=n32/mabi=32/mabi=64 -ifneq ($(filter MIPS_ABI_DEFAULT=ABI_32,$(tm_defines)),) -MULTILIB_DIRNAMES = n32 . 64 -else MULTILIB_DIRNAMES = n32 32 64 -endif MULTILIB_OSDIRNAMES = ../lib32 ../lib ../lib64 EXTRA_MULTILIB_PARTS=crtbegin.o crtend.o crtbeginS.o crtendS.o crtbeginT.o
Re: [patch] avoid '//' prefixes when sysroot is set to '/'
On 26.01.2012 18:57, Joseph S. Myers wrote:
On Thu, 26 Jan 2012, Matthias Klose wrote:
On 25.01.2012 17:45, Joseph S. Myers wrote:
On Wed, 25 Jan 2012, Matthias Klose wrote:
This can end up in generation for dependency files, and other files
parsing
the output. The solution I came up with is to check for sysroot set to '/'
and
special case this in two places. Afaics, there are no other places.
I could imagine a sysroot path that isn't just '/' but ends with '/'
resulting in duplicate '/' in the middle of the path - although that's not
a correctness issue in the way that '//' at the start could be, maybe the
best check is actually for '/' at end of sysroot (in which case skip the
'/' at the start of the path within the sysroot)?
as in the attached trailing.diff? built and regression tested.
Yes, that's OK (with copyright date updates in incpath.c).
there is one more issue, when configuring
--with-sysroot=/ --with-gxx-include-dir=/usr/include/c++/4.7
in that the leading / is stripped away in configure.ac. This case needs an
explicit check. Ok for the trunk?
Matthias
* configure.ac (gcc_gxx_include_dir): Don't strip a `/' sysroot value.
--- a/src/gcc/configure.ac
+++ b/src/gcc/configure.ac
@@ -149,7 +149,9 @@
if test ${with_sysroot+set} = set; then
gcc_gxx_without_sysroot=`expr ${gcc_gxx_include_dir} :
${with_sysroot}'\(.*\)'`
if test ${gcc_gxx_without_sysroot}; then
-gcc_gxx_include_dir=${gcc_gxx_without_sysroot}
+if test x${with_sysroot} != x/; then
+ gcc_gxx_include_dir=${gcc_gxx_without_sysroot}
+fi
gcc_gxx_include_dir_add_sysroot=1
fi
fi
Re: [patch] avoid '//' prefixes when sysroot is set to '/'
On 08.02.2012 02:01, Joseph S. Myers wrote:
On Wed, 8 Feb 2012, Matthias Klose wrote:
there is one more issue, when configuring
--with-sysroot=/ --with-gxx-include-dir=/usr/include/c++/4.7
in that the leading / is stripped away in configure.ac. This case needs an
explicit check. Ok for the trunk?
This looks like a case where any sysroot with a trailing '/' could
misbehave and remove a leading '/' that should be left there, i.e. where
gcc_gxx_without_sysroot should be computed in a way that ignores any
trailing '/' on the sysroot setting. Or is such a removal actually
harmless in all cases except for plain '/' as the sysroot?
not harmless, but not seen unless you pass --sysroot=path with trailing / to
the driver. so lets strip the trailing / as well.
this requires that the definition for
AC_ARG_WITH(sysroot, ...)
is moved before the use of the fixed with_sysroot before checking with_sysroot
in the gcc_gxx_without_sysroot check.
Matthias
* configure.ac: Move AC_ARG_WITH checks for native-system-header-dir,
build-sysroot, sysroot from the `Miscenalleous configure options'
to the `Directories' section.
Index: gcc/configure.ac
===
--- gcc/configure.ac(revision 183991)
+++ gcc/configure.ac(working copy)
@@ -118,6 +118,68 @@
local_prefix=/usr/local
fi
+AC_ARG_WITH([native-system-header-dir],
+ [ --with-native-system-header-dir=dir
+ use dir as the directory to look for standard
+ system header files in. Defaults to /usr/include.],
+[
+ case ${with_native_system_header_dir} in
+ yes|no) AC_MSG_ERROR([bad value ${withval} given for
--with-native-system-header-dir]) ;;
+ /* | [[A-Za-z]]:[[\\/]]*) ;;
+ *) AC_MSG_ERROR([--with-native-system-header-dir argument ${withval} must be
an absolute directory]) ;;
+ esac
+ configured_native_system_header_dir=${withval}
+], [configured_native_system_header_dir=])
+
+AC_ARG_WITH(build-sysroot,
+ [AS_HELP_STRING([--with-build-sysroot=sysroot],
+ [use sysroot as the system root during the build])],
+ [if test x$withval != x ; then
+ SYSROOT_CFLAGS_FOR_TARGET=--sysroot=$withval
+ fi],
+ [SYSROOT_CFLAGS_FOR_TARGET=])
+AC_SUBST(SYSROOT_CFLAGS_FOR_TARGET)
+
+AC_ARG_WITH(sysroot,
+[AS_HELP_STRING([[--with-sysroot[=DIR]]],
+ [search for usr/lib, usr/include, et al, within DIR])],
+[
+ case ${with_sysroot} in
+ yes) TARGET_SYSTEM_ROOT='${exec_prefix}/${target_noncanonical}/sys-root' ;;
+ *) TARGET_SYSTEM_ROOT=$with_sysroot ;;
+ esac
+
+ TARGET_SYSTEM_ROOT_DEFINE='-DTARGET_SYSTEM_ROOT=\$(TARGET_SYSTEM_ROOT)\'
+
CROSS_SYSTEM_HEADER_DIR='$(TARGET_SYSTEM_ROOT)$${sysroot_headers_suffix}$(NATIVE_SYSTEM_HEADER_DIR)'
+
+ if test x$prefix = xNONE; then
+ test_prefix=/usr/local
+ else
+ test_prefix=$prefix
+ fi
+ if test x$exec_prefix = xNONE; then
+ test_exec_prefix=$test_prefix
+ else
+ test_exec_prefix=$exec_prefix
+ fi
+ case ${TARGET_SYSTEM_ROOT} in
+ ${test_prefix}|${test_prefix}/*|\
+ ${test_exec_prefix}|${test_exec_prefix}/*|\
+ '${prefix}'|'${prefix}/'*|\
+ '${exec_prefix}'|'${exec_prefix}/'*)
+ t=$TARGET_SYSTEM_ROOT_DEFINE -DTARGET_SYSTEM_ROOT_RELOCATABLE
+ TARGET_SYSTEM_ROOT_DEFINE=$t
+ ;;
+ esac
+], [
+ TARGET_SYSTEM_ROOT=
+ TARGET_SYSTEM_ROOT_DEFINE=
+ CROSS_SYSTEM_HEADER_DIR='$(gcc_tooldir)/sys-include'
+])
+AC_SUBST(TARGET_SYSTEM_ROOT)
+AC_SUBST(TARGET_SYSTEM_ROOT_DEFINE)
+AC_SUBST(CROSS_SYSTEM_HEADER_DIR)
+
# Don't set gcc_gxx_include_dir to gxx_include_dir since that's only
# passed in by the toplevel make and thus we'd get different behavior
# depending on where we built the sources.
@@ -739,68 +801,6 @@
], [enable_shared=yes])
AC_SUBST(enable_shared)
-AC_ARG_WITH([native-system-header-dir],
- [ --with-native-system-header-dir=dir
- use dir as the directory to look for standard
- system header files in. Defaults to /usr/include.],
-[
- case ${with_native_system_header_dir} in
- yes|no) AC_MSG_ERROR([bad value ${withval} given for
--with-native-system-header-dir]) ;;
- /* | [[A-Za-z]]:[[\\/]]*) ;;
- *) AC_MSG_ERROR([--with-native-system-header-dir argument ${withval} must be
an absolute directory]) ;;
- esac
- configured_native_system_header_dir=${withval}
-], [configured_native_system_header_dir=])
-
-AC_ARG_WITH(build-sysroot,
- [AS_HELP_STRING([--with-build-sysroot=sysroot],
- [use sysroot as the system root during the build])],
- [if test x$withval != x ; then
- SYSROOT_CFLAGS_FOR_TARGET=--sysroot=$withval
- fi],
- [SYSROOT_CFLAGS_FOR_TARGET=])
-AC_SUBST(SYSROOT_CFLAGS_FOR_TARGET)
-
-AC_ARG_WITH(sysroot,
-[AS_HELP_STRING([[--with-sysroot[=DIR]]],
- [search for usr/lib, usr/include, et al, within DIR])],
-[
- case ${with_sysroot} in
- yes) TARGET_SYSTEM_ROOT='${exec_prefix}/${target_noncanonical}/sys-root' ;;
- *) TARGET_SYSTEM_ROOT
Re: [patch, libffi] Sync merge libffi
On 04.03.2012 22:20, Anthony Green wrote: Hello, The attached patch includes changes that have been reviewed, approved and merged into the stand-alone libffi release tree**. ** http://github.com/atgreen/libffi does this correspond to a libffi release or release candidate?
[patch] remove empty directories (libgo, libstdc++-v3, libgomp)
Ok to remove these three empty directories? libgo/go/exp/template libstdc++-v3/testsuite/30_threads/condition_variable_any/requirements libgomp/config/linux/arm
Re: [v3] libstdc++/49829
On 24.01.2012 00:27, Benjamin Kosnik wrote:
This modularizes the libstdc++ sources such that the resulting library
binaries are now composed of three convenience libraries. In short:
this breaks builds configured with --enable-libstdcxx-debug. Tried the following
(not yet working) fix.
Matthias
Index: src/Makefile.am
===
--- src/Makefile.am (revision 183477)
+++ src/Makefile.am (working copy)
@@ -194,8 +194,9 @@
# Take care to fix all possibly-relative paths.
stamp-debug:
if test ! -d ${debugdir}; then \
- mkdir -p ${debugdir}; \
+ for d in $(SUBDIRS); do mkdir -p ${debugdir}/$$d; done; \
(cd ${debugdir}; \
+ for d in . $(SUBDIRS); do \
sed -e 's/top_builddir = \.\./top_builddir = ..\/../' \
-e 's/top_build_prefix = \.\./top_build_prefix = ..\/../' \
-e 's/srcdir = \.\./srcdir = ..\/../' \
@@ -204,7 +205,8 @@
-e 's/MKDIR_P = \.\./MKDIR_P = ..\/../' \
-e 's/all-local: build_debug/all-local:/' \
-e 's/install-data-local: install_debug/install-data-local:/' \
- ../Makefile Makefile) ; \
+ ../$$d/Makefile $$d/Makefile; \
+ done); \
fi; \
echo `date` stamp-debug;
Re: [v3] libstdc++/49829
On 25.01.2012 06:26, Benjamin Kosnik wrote:
this breaks builds configured with --enable-libstdcxx-debug.
confirmed
Tried
the following (not yet working) fix.
OK. The attached is closer, but still not quite there.
one step further, to avoid the endless recursion in the install-debug target.
unsure if that is the right approach. the install now works, but the debug
library is now built in the install step, not in the build step.
Matthias
Index: src/Makefile.am
===
--- src/Makefile.am (revision 183514)
+++ src/Makefile.am (working copy)
@@ -172,13 +172,23 @@
# 1 debug library
# 2 supra-convenience library
if GLIBCXX_BUILD_DEBUG
-all-local: libstdc++convenience.la build_debug
-install-data-local: install_debug
+STAMP_DEBUG = build-debug
+STAMP_INSTALL_DEBUG = install-debug
+CLEAN_DEBUG = debug
else
-all-local: libstdc++convenience.la
-install-data-local:
+STAMP_DEBUG =
+STAMP_INSTALL_DEBUG =
+CLEAN_DEBUG =
endif
+all-local-once: libstdc++convenience.la $(STAMP_DEBUG)
+install-data-local-once: $(STAMP_INSTALL_DEBUG)
+
+all-local: all-local-once
+install-data-local: install-data-local-once
+clean-local:
+ rm -rf libstdc++convenience.la stamp* $(CLEAN_DEBUG)
+
# Make a non-installed convenience library, so that --disable-static
# may work.
libstdc++convenience.la: $(toolexeclib_LTLIBRARIES)
@@ -188,13 +198,13 @@
fi; \
echo `date` stamp-libstdc++convenience;
-debugdir = debug
-
-# Build a set of debug objects here.
+# Build a debug variant.
# Take care to fix all possibly-relative paths.
+debugdir = ${glibcxx_builddir}/src/debug
stamp-debug:
if test ! -d ${debugdir}; then \
mkdir -p ${debugdir}; \
+ for d in $(SUBDIRS); do mkdir -p ${debugdir}/$$d; done; \
(cd ${debugdir}; \
sed -e 's/top_builddir = \.\./top_builddir = ..\/../' \
-e 's/top_build_prefix = \.\./top_build_prefix = ..\/../' \
@@ -202,16 +212,27 @@
-e 's/VPATH = \.\./VPATH = ..\/../' \
-e 's/glibcxx_basedir = \.\./glibcxx_basedir = ..\/../' \
-e 's/MKDIR_P = \.\./MKDIR_P = ..\/../' \
- -e 's/all-local: build_debug/all-local:/' \
- -e 's/install-data-local: install_debug/install-data-local:/' \
- ../Makefile Makefile) ; \
+ -e 's/all-local: all-local-once/all-local:/' \
+ -e 's/install-data-local:
install-data-local-once/install-data-local:/' \
+ ../Makefile Makefile ; \
+ for d in . $(SUBDIRS); do \
+ sed -e 's/top_builddir = \.\./top_builddir = ..\/../' \
+ -e 's/top_build_prefix = \.\./top_build_prefix = ..\/../' \
+ -e 's/srcdir = \.\./srcdir = ..\/../' \
+ -e 's/VPATH = \.\./VPATH = ..\/../' \
+ -e 's/glibcxx_basedir = \.\./glibcxx_basedir = ..\/../' \
+ -e 's/MKDIR_P = \.\./MKDIR_P = ..\/../' \
+ ../$$d/Makefile $$d/Makefile ; \
+ done) ; \
fi; \
echo `date` stamp-debug;
-build_debug: stamp-debug
- (cd ${debugdir} $(MAKE) CXXFLAGS='$(DEBUG_FLAGS)' all)
+build-debug: stamp-debug
+ (cd ${debugdir} $(MAKE) CXXFLAGS='$(DEBUG_FLAGS)' libstdc++.la)
-# Install debug library here.
-install_debug:
- (cd ${debugdir} $(MAKE) \
- toolexeclibdir=$(glibcxx_toolexeclibdir)/debug install)
+# Install debug library.
+install-debug: stamp-debug
+ (if [ $$(basename $(CURDIR)) != debug ]; then \
+ cd ${debugdir} $(MAKE) \
+ toolexeclibdir=$(glibcxx_toolexeclibdir)/debug install; \
+ fi)
[patch] avoid '//' prefixes when sysroot is set to '/'
when setting sysroot to / (for whatever reason), then search directories and
headers start with a double-slash, as seen with gcc -v.
#include ... search starts here:
#include ... search starts here:
/usr/lib/gcc/x86_64-linux-gnu/4.6/include
//usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/4.6/include-fixed
//usr/include/x86_64-linux-gnu
//usr/include
End of search list.
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.6/:/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../lib/://lib/x86_64-linux-gnu/://lib/../lib/://usr/lib/x86_64-linux-gnu/://usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../://lib/://usr/lib/
This can end up in generation for dependency files, and other files parsing the
output. The solution I came up with is to check for sysroot set to '/' and
special case this in two places. Afaics, there are no other places.
With the patch, both the include paths and the library paths start with a single
slash. No regressions seen running the testsuite on x86_64-linux-gnu.
Matthias
2012-01-24 Matthias Klose d...@ubuntu.com
* gcc.c (add_sysrooted_prefix): Don't prefix with the system root,
if it is the root directory.
* incpath.c (add_standard_paths): Likewise.
Index: gcc/incpath.c
===
--- gcc/incpath.c (revision 183421)
+++ gcc/incpath.c (working copy)
@@ -166,7 +166,10 @@
/* Should this directory start with the sysroot? */
if (sysroot p-add_sysroot)
- str = concat (sysroot, p-fname, NULL);
+ if (IS_DIR_SEPARATOR (*sysroot) sysroot[1] == '\0')
+ str = concat (p-fname, NULL);
+ else
+ str = concat (sysroot, p-fname, NULL);
else if (!p-add_sysroot relocated
!filename_ncmp (p-fname, cpp_PREFIX, cpp_PREFIX_len))
{
Index: gcc/gcc.c
===
--- gcc/gcc.c (revision 183421)
+++ gcc/gcc.c (working copy)
@@ -2443,7 +2443,9 @@
if (!IS_ABSOLUTE_PATH (prefix))
fatal_error (system path %qs is not absolute, prefix);
- if (target_system_root)
+ if (target_system_root
+ !IS_DIR_SEPARATOR (*target_system_root)
+ target_system_root[1] != '\0')
{
if (target_sysroot_suffix)
prefix = concat (target_sysroot_suffix, prefix, NULL);
