Re: PING: PATCH [4/n]: Prepare x32: Permute the conversion and addition if one operand is a constant

On 07/27/2011 07:29 PM, H.J. Lu wrote: If IRNORE_ADDRESS_WRAP_AROUND is TRUE, we + also permute the conversion and addition of a constant. It is used to + optimize cases where overflow of base + constant offset won't happen or + its behavior is implementation-defined for a given target. *

Re: [DF] Replace various bitmaps with HARD_REG_SETs

On 07/27/2011 06:17 PM, Joseph S. Myers wrote: > --- gcc/target.h 2011-04-06 11:08:17 + > +++ gcc/target.h 2011-07-27 10:27:56 + > @@ -50,6 +50,7 @@ >#define GCC_TARGET_H > >#include "tm.h" > +#include "hard-reg-set.h" >#include "insn-modes.h" Please send a patch agai

Re: PING: PATCH [4/n]: Prepare x32: Permute the conversion and addition if one operand is a constant

On 07/28/2011 12:59 AM, H.J. Lu wrote: > Regarding correctness: you're converting a SImode operation to DImode by > "pushing in" the zero_extend operation. What makes you think that base + > constant offset won't overflow in any case? You have not answered this. > And also: what are you

Re: PING: PATCH [4/n]: Prepare x32: Permute the conversion and addition if one operand is a constant

On 07/28/2011 11:30 AM, Uros Bizjak wrote: > convert_memory_address_addr_space has a special PLUS/MULT case for > POINTERS_EXTEND_UNSIGNED< 0. ?It turns out that it is also needed > for all Pmode != ptr_mode cases. ?OK for trunk? > 2011-06-11 ?H.J. Lu ? > > ? ? ? ?PR middle-end/47727 > ? ?

Re: PING: PATCH [4/n]: Prepare x32: Permute the conversion and addition if one operand is a constant

Ok, you removed ignore_address_wrap_around, so we're almost there. On 07/28/2011 07:59 PM, H.J. Lu wrote: @@ -712,7 +715,16 @@ convert_modes (enum machine_mode mode, enum machine_mode oldmode, rtx x, int uns if (GET_CODE (x) == SUBREG&& SUBREG_PROMOTED_VAR_P (x) && GET_MODE_SIZE (

Re: PING: PATCH [4/n]: Prepare x32: Permute the conversion and addition if one operand is a constant

On 07/29/2011 08:34 AM, Paolo Bonzini wrote: + temp = rtl_hooks.gen_lowpart_no_emit (mode, x); This line is obviously spurious, sorry. + if (no_emit) + return rtl_hooks.gen_lowpart_no_emit (mode, x); + else +return gen_lowpart (mode, x); Paolo

Re: PING Re: PATCH: move Valgrind header checks from "valgrind" to "misc" checking

On 07/29/2011 03:27 PM, Laurynas Biveinis wrote: Pinging yet again... 2011/7/22 Laurynas Biveinis: PING again... 2011/5/28 Laurynas Biveinis: PING http://codereview.appspot.com/4250047 http://gcc.gnu.org/ml/gcc/2011-01/msg00363.html this patch moves Valgrind header detection from "valgrind"

Re: [DF] [performance] generate DF_REF_BASE REFs in REGNO order

On 07/29/2011 07:23 PM, Dimitrios Apostolou wrote: 2011-07-29 Dimitrios Apostolou Paolo Bonzini (df_def_record_1): Assert a parallel must contain an EXPR_LIST at this point. Receive the LOC and move its extraction... (df_defs_record): ... here. Rewrote

Re: PING: PATCH [4/n]: Prepare x32: Permute the conversion and addition if one operand is a constant

On Sat, Jul 30, 2011 at 00:32, H.J. Lu wrote: > The whole approach doesn't work. The testcase at > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49721#c1 > > shows GCC depends on transforming: > > (zero_extend:DI (plus:SI (FOO:SI) (const_int Y))) > > to > > (plus:DI (zero_extend:DI (FOO:SI)) (cons

Re: [RFC] hard-reg-set.h refactoring

On Sat, Jul 30, 2011 at 19:21, Dimitrios Apostolou wrote: > I don't intend for this to go mainline, Jakub has explained on IRC that > certain ABIs make it slower to pass structs and we wouldn't want that. This can be "fixed" by marking the functions as always_inline. They should be always inline

Re: [DF] Replace various bitmaps with HARD_REG_SETs

On Sat, Jul 30, 2011 at 19:08, Jakub Jelinek wrote: > And for bigger HARD_REG_SET, making it a struct would mean that all > functions that use HARD_REG_SET in a read-only way and thus are passed > a HARD_REG_SET argument rather than HARD_REG_SET * suddenly copy the whole > bitset The fix could be

Re: [DF] Replace various bitmaps with HARD_REG_SETs

On Sun, Jul 31, 2011 at 14:44, Jakub Jelinek wrote: > But I really think it is a mistake to change HARD_REG_SET itself, at least > before we are actually there to be able to have a full multi-target cc1 (if > that is a goal). I'd agree, but tm.h was already removed from target.h. Better, we can

Re: Support -mcpu=native on Solaris/SPARC

On 08/01/2011 03:51 PM, Rainer Orth wrote: Here's an updated version of the patch, containing two changes: * Solaris 8 doesn't support KSTAT_DATA_STRING. * I've updated the list of known cpu types, based on the /platform/sun4?/kernel/cpu{, /sparcv9} entries found in Solaris 8, 9, 10 and 1

Re: [RFC] hard-reg-set.h refactoring

On 08/01/2011 05:57 PM, Dimitrios Apostolou wrote: I don't fully understand the output from -fdump-tree-all, but my conclusion based also on profiler output and objdump, is that both unrolling and inlining is happening in both versions. Nevertheless I can see that assembly output is a bit differ

Re: [RFC] hard-reg-set.h refactoring

On 08/01/2011 09:10 PM, Dimitrios Apostolou wrote: Keeping my patch exactly the same, just changing the hook_void_hard_reg_set to receive a (HOST_WIDEST_FAST_INT *) arg and doing the necessary typecasts, added an extra 3 M instructions. But the ix86_live_on_entry is only called 1233x times from

Re: [build, lto] Only accept -fuse-linker-plugin if linker supports -plugin (PR lto/46944)

On 04/04/2011 06:15 PM, Rainer Orth wrote: I haven't found if there are provisions for in-tree gold, though, and still cannot test that. In-tree gold definitely works (or should). Paolo

Re: [build] Avoid ld -v error message with Sun ld on SPARC

On 04/26/2011 05:25 PM, Rainer Orth wrote: David, Thanks Rainer, if you cons up a patch to add the ".align" directive I'll ACK that as well. here's the patch that I've been testing over the weekend. It caused no change for HAVE_AS_SPARC_GOTDATA_OP on anything but Solaris 10 with gas and Sun

Re: Toplevel cleanup: split out libgcj disabling

On 04/27/2011 05:50 PM, Joseph S. Myers wrote: Continuing the toplevel cleanups separating the cases disabling different subdirectories - on the basis that eventually this information should come from the subdirectories, and that as previously discussed much of the default disabling of ${libgcj}

Re: Toplevel cleanup: disable Java when libffi not supported

On 04/27/2011 06:33 PM, Joseph S. Myers wrote: This patch, relative to a tree with applied, continues the cleanup of toplevel cases relating to disabling Java or Java libraries by arranging for Java to be disabled (via unsupported_languag

Re: Toplevel cleanup: reduce libgcj disabling

On 04/28/2011 06:17 PM, Joseph S. Myers wrote: This patch cleans up the libgcj-disabling case statement at toplevel, removing the default disabling for *-*-* (which allows other empty cases to be removed) and disabling based on architecture, or most cases of architecture-OS combination where the

Re: Remove obsolete compiler settings in toplevel configure

On 05/04/2011 09:12 PM, Joseph S. Myers wrote: -# hpux11 in 64bit mode has libraries in a weird place. Arrange to find -# them automatically. - -# The Solaris /usr/ucb/cc compiler does not appear to work. Ok. Paolo

Re: Toplevel newlib/libgloss disabling cleanup

There is indeed more simplification possible (alpha-vms for example caught my attention while reviewing), but proceeding incrementally does not hurt. This patch is okay, thanks. Paolo 2011/5/4, Joseph S. Myers : > This patch separates cases disabling newlib and libgloss for various > target OSe

Re: [PATCH] Canonicalize compares in combine [2/3] Modifications to try_combine()

On 04/22/2011 05:21 PM, Chung-Lin Tang wrote: Also, instead of testing for XEXP(SET_SRC(PATTERN(i3)),1) == const0_rtx at the top, it now allows CONST_INT_P(XEXP(SET_SRC(PATTERN(i3)),1)), tries to adjust it by simplify_compare_const() from the last patch, and then tests if op1 == const0_rtx. This

Re: [PATCH] Canonicalize compares in combine [2/3] Modifications to try_combine()

On 05/06/2011 12:56 PM, Chung-Lin Tang wrote: > I'm not sure why it doesn't allow both? > > Paolo Hi Paolo, I'm not sure I understand your meaning of 'both', but before this patch, it only tested for == const0_rtx, without any attempt of other cases. Now it tests CONST_INT_P(XEXP(SET_SRC(PATT

Re: [PATCH] allow setting LDFLAGS_FOR_TARGET in top-level configuration.

On 05/09/2011 04:38 AM, Doug Kwan (關振德) wrote: Sorry, forgot the patch and the ChangeLog 2011-05-08 Doug Kwan * configure.ac: Propagate LDFLAGS_FOR_TARGET. * configure: Regenerated. * Makefile.tpl (LDFLAGS_FOR_TARGET): Use LDFLAGS_FOR_TARGET value from configure

Re: [PATCH] allow setting LDFLAGS_FOR_TARGET in top-level configuration.

On 05/09/2011 11:49 AM, Joseph S. Myers wrote: > The x86 Android toolchain needs setting LDFLAGS_FOR_TARGET to > build. This patch does that. The patch was tested by bootstrapping > natively on x86_64 linux. Do I also need to submit this to binutils > as well? My view is that you don

Re: [patch] make default linker --hash-style configurable option

On 05/09/2011 05:59 PM, Paul Pluzhnikov wrote: Ping? Ping? Ping? Ping? Ping? http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00246.html CC'ing the rest of build system maintainers. None of the build system maintainers can approve gcc.c changes. And those can be approved only by either a global

Re: [patch] make default linker --hash-style configurable option

On Mon, May 9, 2011 at 18:45, Joseph S. Myers wrote: > On Mon, 9 May 2011, Paolo Bonzini wrote: > >> On 05/09/2011 05:59 PM, Paul Pluzhnikov wrote: >> > Ping? Ping? Ping? Ping? Ping? >> > >> > http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00246.html &g

Re: [patch gimplifier]: Boolify more strict conditional expressions and transform simple form to binary

On 05/10/2011 05:23 PM, Richard Guenther wrote: I suppose you have testcases for all the cases you looked at, please add some that cover these corner cases. Also, there is quite some tree-vrp.c dead code with these changes. Removing the TRUTH_*_CODE handling in VRP will help finding more place

Re: [google] support for building Linux kernel with FDO (issue4523061)

On 05/13/2011 03:03 AM, Rong Xu wrote: * gcc/coverage.c(revision 173717): set a flag if building for Linux kernel. * gcc/tree-profile.c(revision 173717): don't emit TLS declarations for Linux kernel builds. I think this should be done without touching at all the pr

Re: [google] support for building Linux kernel with FDO (issue4523061)

On 05/13/2011 06:31 PM, Xinliang David Li wrote: > 1) add a new TLS model -ftls-model=none and make the kernel uses it. The > model would simply force targetm.have_tls to false. > This is a good idea. > 2) as Richi mentioned, gcov-io and libgcov changes then can move to the > kernel, and

Re: C6X port 8/11: A new FUNCTION_ARG macro

On 05/12/2011 05:40 PM, Bernd Schmidt wrote: + if (targetm.calls.function_arg_round_to_arg_boundary (passed_mode, type)) +round_boundary = boundary; + else +round_boundary = PARM_BOUNDARY; Why add an if, instead of making the new target hook function_arg_round_boundary? The default

Re: Prefixes for libgcc symbols (C6X 9.5/11)

On 05/13/2011 03:40 PM, Bernd Schmidt wrote: gcc/ * libgcc2.h (__NW, __NDW): Define using a __gnu_ prefix if LIBGCC2_GNU_PREFIX is defined. (__N): New macro. (__powisf2, __powidf2, __powitf2, __powixf2, __bswapsi2, __bswapdi2, __mulsc3, __muldc3, _

Re: Link more common objects consistently into host programs

On 05/20/2011 02:21 PM, Joseph S. Myers wrote: 2011-05-20 Joseph Myers * Makefile.in (LIBDEPS): Add libcommon.a. (LIBS): Likewise. (GCC_OBJS): Remove diagnostic.o, pretty-print.o and input.o. (OBJS-common): Remove diagnostic.o, input.o, intl.o, pretty-pri

Re: Merge OBJS-common,-md,-archive

On 05/20/2011 03:49 PM, Michael Matz wrote: Hi, On Fri, 20 May 2011, Joseph S. Myers wrote: (Apart from the arbitrary division between GCC_OBJS and the xgcc link rule, mentioned above, there are other arbitrary divisions that don't make sense to me. In particular, the separation between OBJS-

Re: ivopts improvement

On 03/03/2011 03:28 PM, Tom de Vries wrote: reg-tested on x86_64. Better? Yes, very much so (talking about patch 6.5; the other one is an optimization but not essential based on the new comments). Just one question: what happens if the COND_EXPR is indeed turned into a MAX_EXPR? Is it a mi

Re: ivopts improvement

On 03/04/2011 02:57 PM, Tom de Vries wrote: The MAX_EXPR however expands into control flow, and is not hoisted out of the outer loop, while the rest of the bound calculation is. That looks like a pass-ordering problem too (both on the tree level, for ivopts versus invariant motion, and on the

Re: [build, lto] Only accept -fuse-linker-plugin if linker supports -plugin (PR lto/46944)

On 03/10/2011 12:26 PM, Rainer Orth wrote: + # GNU gold (GNU Binutils 2.21.51.20110225) 1.11 + # + # We extract the binutils version which is more familiar and specific + # than the gold version. + ld_vers=`echo $ld_ver | sed -n \ + -e 's,^.*[ ]\([0-9][0-9]*\.

Re: [patch, score] Remove score3 from score backend, delete unusual insn generate

On 03/11/2011 07:16 AM, Liqin Chen wrote: @@ -181,10 +181,8 @@ score_output_mi_thunk (FILE *file, tree HOST_WIDE_INT delta, HOST_WIDE_INT vcall_offset, tree function) { - if (TARGET_SCORE5 || TARGET_SCORE5U || TARGET_SCORE7 || TARGET_SCORE7D) +

Re: Minor VRP jump threading improvement

On 03/15/2011 10:37 PM, Jeff Law wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I noticed that VRP was missing many obvious jump threading opportunities; investigation showed that it wasn't threading through conditionals with pointer types, just those with integral types. Fix is rather

Re: [PATCH] Fix RTL DSE compile time hog (PR rtl-optimization/48141)

On 03/16/2011 12:12 AM, Kenneth Zadeck wrote: so how much time does this save? I agree that this is a useful simplification, but it seems unlikely to be that important in real code. it seems like the 5000 store test would in general provide a better safety valve. I think having both is a good

Re: [build, lto] Only accept -fuse-linker-plugin if linker supports -plugin (PR lto/46944)

On 03/16/2011 10:23 AM, Rainer Orth wrote: > I'm ok with this for mainline - Paolo, can you double-check the > autofoo stuff? As for 4.6 I'd like to give it a day or two on > trunk to allow people to report problems. Paolo, do you have any comments on the configure.ac part of the patch? It

Re: [PATCH] Fix RTL DSE compile time hog (PR rtl-optimization/48141)

On 03/16/2011 12:59 PM, Richard Guenther wrote: On Wed, Mar 16, 2011 at 12:52 PM, Jakub Jelinek wrote: On Wed, Mar 16, 2011 at 09:46:20AM +0100, Paolo Bonzini wrote: On 03/16/2011 12:12 AM, Kenneth Zadeck wrote: so how much time does this save? I agree that this is a useful simplification

Re: [PATCH] Fix -fcrossjumping at -O1 (PR rtl-optimization/48156)

On Fri, Mar 18, 2011 at 17:23, Kenneth Zadeck wrote: > I believe that this is not the right way to go. > > if someone specifies -fcrossjumping, then the pass should turn on live for > the duration of the pass just as ifcvt does.    If they ask for crossjumping > you should give them crossjumping a

Re: [PATCH] Fix -fcrossjumping at -O1 (PR rtl-optimization/48156)

On Fri, Mar 18, 2011 at 17:31, Jakub Jelinek wrote: > On Fri, Mar 18, 2011 at 12:23:11PM -0400, Kenneth Zadeck wrote: >> I believe that this is not the right way to go. >> >> if someone specifies -fcrossjumping, then the pass should turn on >> live for the duration of the pass just as ifcvt does.

Re: [PATCH] Fix -fcrossjumping at -O1 (PR rtl-optimization/48156)

On Fri, Mar 18, 2011 at 19:18, Kenneth Zadeck wrote: > yes, but i think that the reason this is a pr is that it seems to be needed > for correctness. Note that df_get_bb_dirty is defaulting to "return false", not "abort". This is what tricked crossjumping and caused the bug. If I can get hold o

Re: [build, lto] Only accept -fuse-linker-plugin if linker supports -plugin (PR lto/46944)

On 03/21/2011 11:18 AM, Rainer Orth wrote: Richard Guenther writes: On Fri, 18 Mar 2011, Rainer Orth wrote: Richard Guenther writes: It seemed to have disabled linker-plugin support for old binutils with --with-plugin-ld=/usr/local/bin/gold, explicit -fuse-linker-plugin says it is not sup

Re: Prune empty cases from toplevel configure.ac

On 03/21/2011 11:41 AM, Joseph S. Myers wrote: This patch, relative to a tree with my deprecated targets removal patch applied, further cleans up the toplevel configure.ac by removing empty cases from a case statement. The original patch

Re: [build] Honor --disable-symvers (PR bootstrap/48135)

On 03/21/2011 12:34 PM, Rainer Orth wrote: Prompted by PR bootstrap/48135, I found that only libstdc++-v3 honors --disable-symvers. The following patch corrects this, but also notices again the mess we've created by having at least 3 different sets of checks for symbol versioning, each with its

Re: [build] Link with libstdc++ for libpwl test (PR bootstrap/48120)

On 03/21/2011 12:48 PM, Rainer Orth wrote: As reported in the PR, the toplevel configure test for libpwl doesn't work since it fails to link with libstdc++. The following patch corrects this. There were a couple of issues: * One cannot use LDFLAGS here since that is passed to $CC before -lpwl,

Re: [build] Link with libstdc++ for libpwl test (PR bootstrap/48120)

On 03/21/2011 01:40 PM, Rainer Orth wrote: Paolo Bonzini writes: On 03/21/2011 12:48 PM, Rainer Orth wrote: As reported in the PR, the toplevel configure test for libpwl doesn't work since it fails to link with libstdc++. The following patch corrects this. There were a couple of i

Re: [testsuite, build] Convert boehm-gc testsuite to DejaGnu (PR boehm-gc/11412)

On Mon, Mar 21, 2011 at 19:27, Mike Stump wrote: > On Mar 21, 2011, at 5:59 AM, Rainer Orth wrote: >> I've applied those changes, and also managed to fix the problems I had >> in Tru64 UNIX testing.  Here's the patch I'd like to commit to 4.7. > >> +# Build shared library from LIB. >> +proc boehm-

Re: Remove dead cases from toplevel configure.ac

On 03/24/2011 12:26 PM, Joseph S. Myers wrote: This patch removes various dead cases from the toplevel configure.ac. Target ep9312-* isn't known to config.sub at all so those cases have been dead for a long time; likewise parisc*64*-* (those parisc cases it does know have also been handled by con

Re: Remove old host cases from toplevel configure

On 03/24/2011 03:11 PM, Joseph S. Myers wrote: Furthermore, the whole idea of the toplevel configure tentative_cc setting code is dubious since this is an autoconf-generated script and it's autoconf's job to deal with finding a working compiler, putting it in ANSI C mode, etc. - so if someone did

cleanup host fragments more 1/n

AR_CFLAGS = cr is already the default. Committed to gcc and src. Paolo 2011-03-24 Paolo Bonzini * mh-sysv4: Remove AR_CFLAGS. Index: mh-sysv4 === --- mh-sysv4(revision 171413) +++ mh-sysv4(working copy

[toplevel] remove tentative_cc

As Joseph pointed out in his mail, its time has come. Paolo 2011-03-24 Paolo Bonzini * configure.ac: Remove all mentions of tentative_cc. * configure: Regenerate. Index: configure.ac === --- configure.ac

[toplevel] cleanup X11_FLAGS_TO_PASS

Yet another relic of cygnus configure. Eliminate. Committed to gcc and (shortly) to src. Paolo 2011-03-24 Paolo Bonzini * configure.ac: Remove all mentions of mh-sysv4 and mh-solaris. * configure: Regenerate. * Makefile.def: Remove all mentions of X11_FLAGS_TO_PASS

[toplevel] cleanup mh-cygwin

The cygwin host fragment is using obsolete variables and constructs, modernize it. Committed to gcc and (shortly) src. Paolo 2011-03-24 Paolo Bonzini * Makefile.def: Add dependency from termcap to gdb. * Makefile.in: Regenerate. config: 2011-03-24 Paolo Bonzini

[toplevel] remove empty cases

This enables omit-frame-pointer for i386-solaris. I honestly haven't bootstrapped it, but I don't expect any problems (and if they appear, it's much better to fix them ;). Committed to gcc and (shortly) to src. Paolo 2011-03-24 Paolo Bonzini * configure.ac: Rem

Re: [toplevel] remove empty cases

On 03/24/2011 06:18 PM, Joseph S. Myers wrote: > On Thu, 24 Mar 2011, Paolo Bonzini wrote: > > This enables omit-frame-pointer for i386-solaris. I honestly haven't > > bootstrapped it, but I don't expect any problems (and if they appear, it's > > much

mt-mep using EXTRA_TARGET_HOST_ALL_MODULES?

Is this actually desired? And what's all-utils? Can we just kill mt-mep? Thanks! :) Paolo

[toplevel] Target fragments cleanups

EXTRA_TARGET_HOST_* has been obsolete for years, GDB_NLM_DEPS was touched exactly once in 1995, and mt-v810 has no references. Committed to gcc and src. Paolo 2011-03-24 Paolo Bonzini * configure.ac: Remove references to mt-mep, mt-netware, mt-wince. * Makefile.def

Re: mt-mep using EXTRA_TARGET_HOST_ALL_MODULES?

On 03/24/2011 06:43 PM, Joseph S. Myers wrote: On Thu, 24 Mar 2011, Paolo Bonzini wrote: Is this actually desired? And what's all-utils? Can we just kill mt-mep? utils at least exists in the src tree. Indeed I didn't know about it. :) However it's not necessary to ad

Re: mt-mep using EXTRA_TARGET_HOST_ALL_MODULES?

On 03/24/2011 08:43 PM, Joseph S. Myers wrote: On Thu, 24 Mar 2011, Paolo Bonzini wrote: One thing I wonder is if we can kill the toplevel support for building lots of miscellaneous tools that aren't in the gcc or src trees and that aren't libraries used by tools in those trees (s

Re: Remove old host cases from toplevel configure

On 03/24/2011 08:49 PM, Joseph S. Myers wrote: Related to that point, I notice a piece of code starting "we might need to use some other shell than /bin/sh for running subshells" that tries to determine a shell on Windows hosts. It's autoconf's job to find a suitable shell, so if this code is st

Re: More toplevel configure.ac pruning

On 03/24/2011 09:12 PM, Joseph S. Myers wrote: -native_only="autoconf automake libtool fileutils find gawk gettext gzip hello indent m4 rcs recode sed shellutils tar textutils uudecode wdiff target-groff guile perl time ash bash bzip2 prms gnuserv target-gperf" +native_only="autoconf automake l

Re: [testsuite, build] Convert boehm-gc testsuite to DejaGnu (PR boehm-gc/11412)

On 03/21/2011 01:59 PM, Rainer Orth wrote: diff -r 8efcb4b03d45 boehm-gc/Makefile.am --- a/boehm-gc/Makefile.am Sun Mar 20 14:28:11 2011 +0100 +++ b/boehm-gc/Makefile.am Sun Mar 20 21:37:14 2011 +0100 @@ -4,10 +4,10 @@ ## files that should be in the distribution are not mentioned in t

Re: mt-mep using EXTRA_TARGET_HOST_ALL_MODULES?

On 03/25/2011 11:59 AM, Joseph S. Myers wrote: * Maybe turn it into a build tool, and it may even make sense: dejagnu dejagnu and expect used to have copies in the src tree but they were removed a long time ago, so I think of the rules for them both as a legacy (and I think those two go togethe

Re: More toplevel configure.ac pruning

On 03/25/2011 12:03 PM, Joseph S. Myers wrote: > Removing the whole native_only stuff is preapproved. What about my patch your just replied to as a first (or Nth) step? Sure, if I didn't write an explicit okay that was just a mistake. :) Paolo

Re: More toplevel configure.ac pruning

On 03/25/2011 12:33 PM, Joseph S. Myers wrote: This patch removes native_only, and removes code disabling various components (not in gcc or src) on various hosts or targets, on the basis you give that if you put such a component in tree you want it to be built (which I think applies even for any

Re: More toplevel configure.ac pruning

On 03/28/2011 01:34 PM, Joseph S. Myers wrote: 2011-03-28 Joseph Myers * configure.ac (i[[3456789]]86-*-msdosdjgpp*): Don't disable libffi on host. (x86_64-*-mingw*, i[[3456789]]86-*-mingw32*): Don't disable newlib on host. (c54x*-*-* | tic54x-*-*): Don't

Re: Random cleanups [2/4]: canonicalize ctor values

On 03/31/2011 03:22 AM, Michael Matz wrote: this came up when looking into why the static ctors contain useless trees (like casts). We can simply canonicalize them while varpool analyzes pending decls. It'll look at initialzers once, where we can "gimplify" them. This requires making canonical

Re: More old target toplevel cleanup

On 04/01/2011 02:34 PM, Joseph S. Myers wrote: This patch does some more toplevel configure cleanup related to targets no longer supported by GCC: * The code to enable libgomp on hosted POSIX systems handled *-*-sysv4*; GCC no longer supports any such targets. * The md_exec_prefix code covered

Re: PATCH: PR middle-end/48440: [4.7 Regression] FAIL: gcc.c-torture/compile/labels-3.c

>>> Index: cgraphbuild.c >>> === >>> --- cgraphbuild.c.orig  2011-04-03 11:28:45.0 +0200 >>> +++ cgraphbuild.c       2011-04-03 11:31:21.0 +0200 >>> @@ -53,6 +53,12 @@ record_reference (tree *tp, int *walk_su >>>   tree

Re: Remove old toplevel subdirectory support

On 04/06/2011 02:07 PM, Joseph S. Myers wrote: This patch removes toplevel support for various subdirectories not present in the gcc or src repositories, as agreed in the thread including. Some other directories may in fact also be no longer usefu

<    1   2   3   4   5   6