Re: [PATCH] Fix PR 51505

On 01/30/2012 01:22 PM, Eric Botcazou wrote: Does this help? Yep, this eliminates all the regressions, thanks! Committed as r183719. Thanks for testing. Paolo

Re: [PATCH] Fix PR 51505

stdarg-2.c execution, -Os FAIL: gcc.c-torture/execute/stdarg-2.c execution, -O2 -flto -flto-partition=none FAIL: gcc.c-torture/execute/stdarg-2.c execution, -O2 -flto for the exact same reason. Does this help? Paolo 2012-01-30 Paolo Bonzini * df-problems.c (df_kill_notes): Check that the use

Re: [build] Cleanup rs6000/t-ppccomm configurations (PR other/51022)

On 01/24/2012 12:20 PM, Alan Modra wrote: On Mon, Dec 05, 2011 at 07:25:35PM -0500, David Edelsohn wrote: Is this fixed or is someone writing a follow-up patch? This does the trick. You could also use case ${host}:${with_multisubdir} in *:*32*) ;;

Re: [PATCH] RFC: Interix resurrection

On 01/22/2012 10:16 PM, Douglas Rupp wrote: May I regenerate libiberty/configure and check it in, or does that require a libiberty maintainer? Yes, regenerate everything that is affected. Paolo

Re: [PATCH] RFC: Interix resurrection

On 01/01/2012 10:01 PM, Douglas Rupp wrote: -i[[34567]]86-*-interix3*) +i[[34567]]86-*-interix[[3-9]]*) # Interix 3.x gcc -fpic/-fPIC options generate broken code. # Instead, we relocate shared libraries at runtime. ;; Is this still true? Build parts are ok. Pa

Re: [PATCH] Fix up --enable-initfini-array autodetection in configure (PR bootstrap/50237)

On 01/19/2012 10:06 AM, Jakub Jelinek wrote: While the linker test is done using the target linker (it uses default linker flags btw, so in case a linker would be buggy for one target and not for a different target also supported by the same linker, it would be a problem, but let's assume that th

Re: [PATCH] Fix up --enable-initfini-array autodetection in configure (PR bootstrap/50237)

On 01/19/2012 12:24 AM, Jakub Jelinek wrote: if test "x${build}" = "x${target}"&& test "x${build}" = "x${host}"; then This test is no longer necessary, is it? ia64 does its own cross-compile detection via AC_RUN_IFELSE, and other hosts are cross-compile safe. The patch is okay if you rem

Re: [PATCH] Fix PR 51505

On 01/19/2012 08:34 AM, Jakub Jelinek wrote: > >Ok, thanks for working on this. > Installed, do you want this for 4.6/4.5? If yes, please give it at least a couple of weeks on the trunk. It's fine by me but yes, let's give it time to bake. Paolo

Re: [PATCH] Fix PR 51505

On 01/18/2012 05:41 PM, Andrey Belevantsev wrote: Hello, As discussed in Bugzilla, this is the patch implementing Paolo's suggestion of killing REG_EQUAL/REG_EQUIV notes from df_kill_notes. The code assumes there is at most one such note per insn. Bootstrapped and tested on x86-64, ok for trunk?

Re: [build] Disable dl_iterate_phdr on Solaris 10

On 01/17/2012 10:43 AM, Rainer Orth wrote: Rainer Orth writes: 2012-01-15 Rainer Orth * configure.ac (gcc_cv_target_dl_iterate_phdr): Only check on Solaris 11+. * configure: Regenerate. It helps to actually attach the patch. Ok. Paolo

Re: [PATCH, rtl-optimization]: Fix PR 51821, 64bit > 32bit conversion produces incorrect results with optimizations

On 01/13/2012 10:58 AM, Richard Sandiford wrote: > Yes, because new test ALWAYS includes the registers that were wrongly > marked as dead by previous test due to REG_UNUSED and noclobber > processing. Or to put it another way: the insn-to-insn changes in the current liveness sets are all prod

Re: RFC: allowing fwprop to propagate subregs

On 01/11/2012 05:55 PM, Ulrich Weigand wrote: In either case, it is always odd to have RTX in the insn stream that isn't "stable" under common simplication ... Do you have any suggestions on how to fix this? If we add the fwprop patch, should we then disable apply_distributive_law for SUBREGs?

Re: [build] Check if linker supports R_386_TLS_GD_PLT, R_386_TLS_LDM_PLT relocs

On 01/09/2012 05:14 PM, Rainer Orth wrote: While the combination of Sun as with GNU ld isn't a recommended configuration on Solaris, it used to work half a year ago, but doesn't right now: stage 1 libgomp fails to link: /vol/gcc/bin/gld-2.22: .libs/team.o: unrecognized relocation (0xc) in sectio

Re: [committed] forward_propagate_subreg vs. mode_rep_extended

On 12/19/2011 11:06 PM, Richard Sandiford wrote: I've normally tried to avoid self-approving rtl optimiser stuff, but since this is a simple extension of the existing MEM handling, and since the mode_rep_extended test effectively makes it MIPS-specific, I hope it's OK to make an exception here.

Re: Go patch committed: Multiplex goroutines onto OS threads

On 12/14/2011 05:04 PM, Ian Lance Taylor wrote: > The OpenBSD thread runtime. It's similar to old LinuxThreads, but > with only 1 kernel thread per process IIUC. Oh, hmmm, that might be a problem. The other Go compiler seems to use the rfork system call to create new threads, passing RFPROC

Re: Go patch committed: Multiplex goroutines onto OS threads

On 12/14/2011 04:45 PM, Ian Lance Taylor wrote: > - sigaltstack always returns EINVAL when using threads; That is odd. sigaltstack is very useful when using threads. > - the threads are identified by the runtime from their stack pointer, > so you risk confusing the runtime very much if you

Re: Go patch committed: Multiplex goroutines onto OS threads

On 12/14/2011 04:00 PM, Ian Lance Taylor wrote: > > This implementation relies on the functions getcontext, setcontext, and > > makecontext. If there are systems which don't have those, getcontext > > and setcontext can be replaced by setjmp and longjmp, but there is no > > obvious replaceme

Re: Go patch committed: Multiplex goroutines onto OS threads

On 11/28/2011 06:46 AM, Ian Lance Taylor wrote: This implementation relies on the functions getcontext, setcontext, and makecontext. If there are systems which don't have those, getcontext and setcontext can be replaced by setjmp and longjmp, but there is no obvious replacement for makecontext.

Re: [Patch,AVR] Light-weight DImode implementation.

On 11/22/2011 01:15 AM, Georg-Johann Lay wrote: ldi r30,lo8(1) ; 25*movqi/2[length = 1] cp r10,r18 ; 26*cmpqi/2[length = 1] brlo .L2 ; 27branch[length = 1] ldi r30,lo8(0) ; 28*movqi/1[length = 1] .L2: add r11,r19 ;

Re: [Patch ppc/darwin] fix vec unwinding part 1.

On 11/29/2011 03:02 PM, Iain Sandoe wrote: The following fails: FAIL: g++.dg/eh/simd-3.C -std=gnu++98 execution test FAIL: g++.dg/eh/simd-3.C -std=gnu++11 execution test FAIL: g++.dg/eh/simd-4.C -std=gnu++98 execution test FAIL: g++.dg/eh/simd-4.C -std=gnu++11 execution test are the tip of an "

Re: Massive breakage with your libgcc patches

On 11/29/2011 04:57 PM, Bernd Schmidt wrote: I've now tried to build c6x-uclinux, not only c6x-elf, and found another problem: crtbegin.o wasn't built. I committed the following patch; please doublecheck there wasn't a reason for how it was being done previously. It's ok, indeed we should look

Re: [build] Cleanup rs6000/t-ppccomm configurations (PR other/51022)

On 11/21/2011 05:01 PM, Rainer Orth wrote: As reported in the PR, powerpc-rtems bootstrap (and certainly several other powerpc targets) is currently broken since rs6000/ibm-ldouble.c appears twice in LIB2ADD, once from rs6000/t-ppccomm and rs6000/t-ppccomm-ldbl, which confuses make. It took me a

Re: Massive breakage with your libgcc patches

On 11/21/2011 04:43 PM, Rainer Orth wrote: Paolo Bonzini writes: On 11/07/2011 07:15 PM, Rainer Orth wrote: Bernd Schmidt writes: On 11/03/11 20:20, Rainer Orth wrote: * config/c6x/t-elf (LIB2ADDEH): Set. * config/c6x/t-c6x-elf: Remove. It builds now, but parts of

Re: RFA: libgcc: move emutls.c from LIB2ADDEH et al to LIB2ADD

On 11/21/2011 01:53 AM, Hans-Peter Nilsson wrote: Spotted while looking into (and yes, I fixed the ChangeLog typo before commit) and also mentioned at. Emulating TLS has nothing to do with

Re: Fix libgcc for FreeBSD 10

On 11/13/2011 04:18 PM, Gerald Pfeifer wrote: The snippet below was written when a new major release of FreeBSD would happen every couple of years, not as frequently as recently the case. FreeBSD 1.x and 2.x, and a.out support, have been obsolete for what must be a decade or so, yet the regular

Re: SPU build broken (Re: CFT: [build] Move libgcc2 to toplevel libgcc)

On 11/11/2011 05:23 PM, Rainer Orth wrote: The trivial patch allowed a x86_64-unknown-linux-gnu x spu-elf cross to finish the libgcc build, and at least the set of objects built before my patch series is identical to the set built now. Ok for mainline? Ok. Have you checked for other occurrenc

Re: RFA: New pass to delete unexecutable paths in the CFG

On 11/09/2011 06:53 PM, Jeff Law wrote: My patch totally ignores the other code on the unexecutable path. So we can miss externally visible side effects, if we were to somehow get on the unexecutable path. But that's the whole point, in a conforming program we can't ever get on the unexecutable

Re: RFA: New pass to delete unexecutable paths in the CFG

On 11/08/2011 09:24 PM, Jeff Law wrote: We don't have access to those assertions as they're removed well prior to this pass running. However, if we did, or if we had redundant PHIs in the stream which were propagated we'd be presented with something like BB0 if (p_1) goto BB1 else goto BB2 BB

Re: RFA: New pass to delete unexecutable paths in the CFG

On 11/08/2011 08:29 PM, Jeff Law wrote: Just to understand, what does this do with your optimization? void f(void *p) { if (p) { puts("sell_soul_to_devil"); puts("post_reload_rewrite"); } *p = 2; } ... f(NULL); Does the program sell its soul to the devil before crashing? If "f" is not

Re: Massive breakage with your libgcc patches

On 11/07/2011 07:15 PM, Rainer Orth wrote: > Bernd Schmidt writes: > >> On 11/03/11 20:20, Rainer Orth wrote: >>> >>> * config/c6x/t-elf (LIB2ADDEH): Set. >>> * config/c6x/t-c6x-elf: Remove. >> >> It builds now, but parts of libgcc are missing. There's no sign of >> muldf3, for examples.

Re: RFA: New pass to delete unexecutable paths in the CFG

On 11/07/2011 07:54 PM, Jeff Law wrote: But we're still stuck with the conditional leading to the path with the __builtin_trap. That's what we want to avoid since those conditionals are executed at runtime. Just to understand, what does this do with your optimization? void f(void *p) { if

Re: [build] Restore arm-eabi bootstrap (PR target/50978)

On 11/07/2011 06:01 PM, Rainer Orth wrote: Ok for mainline? Ok, thanks. Paolo

Re: RFA: New pass to delete unexecutable paths in the CFG

On 11/07/2011 04:54 PM, Tom Tromey wrote: "Jeff" == Jeff Law writes: Jeff> So, presumably there's no way to know we're throwing to Jeff> NullPointerException from the exception information attached to the Jeff> statement or BB? If not I could disable if the statement with the Jeff> memory

Re: [PATCH] Fix libgcc_tm.h dependency in libgcc Makefile

On 11/06/2011 06:43 PM, John David Anglin wrote: This is fixes a trunk build error noticed on hppa-linux at -j4. Tested on hppa-unknown-linux-gnu and hppa64-hp-hpux11.11. Ok? Ok. Paolo

Re: repost: [DF] Use HARD_REG_SETs instead of bitmaps

On 11/06/2011 03:19 AM, Dimitrios Apostolou wrote: I understand major hassle is when the register file is big, too much data is being copied on a function call, when it has a HARD_REG_SET as a pass by value parameter. So I did some testing on SPARC, which has the biggest register file I know of,

Re: [build] Restore arm-eabi bootstrap (PR target/50978)

On 11/04/2011 06:24 PM, Rainer Orth wrote: Ok, but unless it's urgent, I'd like to go over it over the weekend and commit on monday. I'm about to leave relatively soon. Sure. Let me know if you cannot fix arm and sh. Paolo

Re: [build] Restore arm-eabi bootstrap (PR target/50978)

Ok, so let's do the analysis. Looks like there are problems in t-rtems and sh/t-sh, in addition to ARM. But I think all of them can be changed. ./config/mcore/t-mcore:HOST_LIBGCC2_CFLAGS = -O3 -DNO_FLOATLIB_FIXUNSDFSI #-msifilter Used as tmake_file="mcore/t-mcore t-fdpbit" would

Re: [build] Restore arm-eabi bootstrap (PR target/50978)

On 11/04/2011 04:59 PM, Matthias Klose wrote: > On 11/04/2011 10:58 AM, Rainer Orth wrote: >> Matthias Klose 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: c

Re: RFA: Fix dse / postreload not to bypass add expanders

On 11/03/2011 08:01 PM, Eric Botcazou wrote: + info.insert_before = insn; + info.first = new_insn; + info.fixed_regs_live = insn_info->fixed_regs_live; + info.failure = false; + for (cur = new_insn; cur; cur = NEXT_INSN (cur)) +{ + info.current = cur; + note_stores (PATTERN (cu

Re: [Patch]: Fix PR rtl-optimization/50448

On 11/04/2011 09:50 AM, Eric Botcazou wrote: + /* If above failed and this is a single set, try to simplify the source of + the set given our substitution. We could perhaps try this for multiple + SETs, but it probably won't buy us anything. */ +rtx addr = simplify_replace_rtx (

Re: [Patch]: Fix PR rtl-optimization/50448

On 11/03/2011 10:21 PM, Eric Botcazou wrote: PR rtl-optimization/50448 >* cprop.c (try_replace_reg): Try to simplify SET_SRC given the >substitution. The whole patch is about SET_DEST though, so I'm a little confused. Yes, the changelog is wrong indeed. Registers in a SET_DEST

Re: [build] Restore arm-eabi bootstrap (PR target/50978)

On 11/03/2011 05:50 PM, Rainer Orth wrote: This patch restores arm-none-eabi bootstrap, which had been broken by my libgcc patches. They accidentally removed arm/t-bpabi in gcc/config.gcc while the file is still needed for its addition to EXTRA_HEADERS. Matt confirmed in the PR that it restored

Re: Build gcc/ with -fno-exceptions -fno-rtti

On 11/03/2011 03:16 PM, Michael Matz wrote: > > There is a bug about not using -fexceptions (50857). > > Then let's fix it, as you said there "We fail to pass -fno-exceptions > -fno-rtti to g++ for stage2 and stage3 building the host binaries. > That leads to increased compile-time and po

Re: CFT: [build] Move crtstuff support to toplevel libgcc

On 11/03/2011 01:52 PM, Rainer Orth wrote: ncrtn$(objext): $(srcdir)/config/rs6000/sol-cn.S - $(crt_compile) -c ncrtn.S + $(crt_compile) -c < Oops. Missing dollar sign. Paolo

Re: serious libgcc regression added recently

On 11/03/2011 04:41 AM, David Miller wrote: From: "Joseph S. Myers" Date: Thu, 3 Nov 2011 01:21:35 + (UTC) What is new is that you can now put tests in libgcc/configure.ac such as the "Check 32bit or 64bit for x86." one, and select t-* files based on those tests - whereas in the gcc/ direct

Re: RFC: PATCH to adjust warning flags for C++

On 11/02/2011 02:47 PM, Jason Merrill wrote: Is this a C++-only warning? Also, how did you test the patch? It is, but the flag is accepted and ignored by the C front end. Then please adjust libcpp/configure.ac too; otherwise the patch is okay to fix bootstrap. It can be reverted later if

Re: RFC: PATCH to adjust warning flags for C++

On 11/01/2011 06:54 PM, Jason Merrill wrote: Paolo Carlini's patch to add -Wnarrowing to -Wc++0x-compat (and thus -Wall) broke bootstrap because of narrowing warnings, so I'd like to add -Wno-narrowing to the stage 2+ warning flags. Is this the best way to do that? Is this a C++-only warning?

Re: [build] Properly test for madvise on Solaris 10 (PR bootstrap/50777)

On 10/19/2011 04:17 PM, Rainer Orth wrote: As described in the PR, Solaris 10 bootstrap is currently broken compiling ggc-page.c in stage2 due to no declaration for madvise(). This happens because g++ defines _XOPEN_SOURCE=600, which hides the declaration, and configure doesn't check for a declar

Re: RFA: Improve tree-ssa-sink block selection

On 10/18/2011 07:10 AM, Jeff Law wrote: --- 467,475 if (gimple_code (use) != GIMPLE_PHI) { sinkbb = gimple_bb (use); ! sinkbb = select_best_block (frombb, gimple_bb (use), stmt); ! if (sinkbb == frombb) return false; *togsi =

Re: [Patch,AVR] Print no-return functions as JMP

> -moptimize-noreturn-calls >        Optimize noreturn calls.  This might make debugging harder but >        will save storing the return address when calling roreturn >        functions. > >        Enabled at levels -O2, -O3, -Os. > > But the "makes debugging harder" clause is true for almost any

Re: [Patch,AVR] Print no-return functions as JMP

On Fri, Oct 14, 2011 at 19:19, Georg-Johann Lay wrote: > Paolo Bonzini schrieb: >> On 10/14/2011 06:23 PM, Georg-Johann Lay wrote: >>> +@item -mjump-to-noreturn >>> +@opindex mjump-to-noreturn >>> +Use a jump instruction instead of a call instruction when calli

Re: [Patch,AVR] Print no-return functions as JMP

On 10/14/2011 06:23 PM, Georg-Johann Lay wrote: +@item -mjump-to-noreturn +@opindex mjump-to-noreturn +Use a jump instruction instead of a call instruction when calling a +no-return functions. This option is active if optimization is turned +on and just affects the way a call instruction is prin

Re: PATCH: PR rtl-optimization/50696: [x32] Unnecessary lea

On 10/14/2011 05:36 PM, H.J. Lu wrote: There is a testcase at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50696 It passes with my patch. Cool, so let's wait for the results of testing. Paolo

Re: PATCH: PR rtl-optimization/50696: [x32] Unnecessary lea

On 10/13/2011 10:07 PM, H.J. Lu wrote: On Thu, Oct 13, 2011 at 11:15 AM, Richard Kenner wrote: The answer to H.J.'s "Why do we do it for MEM then?" is simply "because no one ever thought about not doing it" No, that's false. The same expand_compound_operation / make_compound_operation pair

Re: PATCH: PR rtl-optimization/50696: [x32] Unnecessary lea

On Thu, Oct 13, 2011 at 19:06, Richard Kenner wrote: >> An and:DI is cheaper than a zero_extend:DI of an and:SI. > > That depends strongly on the constants and whether the machine is 32-bit > or 64-bit. Yes, the rtx_costs take care of that. > But that's irrelevant in this case since the and:SI w

Re: PATCH: PR rtl-optimization/50696: [x32] Unnecessary lea

On Thu, Oct 13, 2011 at 19:19, H.J. Lu wrote: > On Thu, Oct 13, 2011 at 10:01 AM, Paolo Bonzini wrote: >> On 10/13/2011 06:35 PM, Richard Kenner wrote: >>>> >>>> It never calls make_extraction.  There are several cases handled >>>> for AND operati

Re: PATCH: PR rtl-optimization/50696: [x32] Unnecessary lea

On 10/13/2011 06:35 PM, Richard Kenner wrote: It never calls make_extraction. There are several cases handled for AND operation. But (and:DI (plus:DI (subreg:DI (mult:SI (reg/v:SI 85 [ i ]) (const_int 4 [0x4])) 0) (subreg:DI (reg:SI 106) 0)) (const_int 4294967292 [0x

Re: PATCH: PR rtl-optimization/50696: [x32] Unnecessary lea

On 10/13/2011 02:51 PM, Richard Kenner wrote: case MEM: /* Ensure that our address has any ASHIFTs converted to MULT in case address-recognizing predicates are called later. */ temp = make_compound_operation (XEXP (x, 0), MEM); SUBST (XEXP (x, 0), temp);

Re: PATCH: PR rtl-optimization/50696: [x32] Unnecessary lea

On 10/13/2011 01:04 AM, Richard Kenner wrote: I still don't like the patch, but I'm no longer as familiar with the code as I used to be so can't suggest a replacement. Let's see what others think about it. Same here, I don't like it but I hardly see any alternative. The only possibility cou

Re: [PATCH] Fix PR46556 (poor address generation)

On 10/11/2011 01:40 PM, Richard Guenther wrote: The pattern matching is still very ad-hoc and doesn't consider statements that feed the base address. There is conceptually no difference between p->a[n] and *(p + n * 4). You placed this lowering in reassoc to catch CSE opportunities with DOM, ri

Re: PATCH RFA: New configure option --with-native-system-header-dir

On 10/09/2011 08:18 AM, Ian Lance Taylor wrote: +#undef NATIVE_HEADER_HEADER_COMPONENT +#define NATIVE_SYSTEM_HEADER_COMPONENT "MINGW" Typo (I think), otherwise okay. Paolo

Re: RFA: Compare Elimination Pass: Fix use of dataflow info

On 10/07/2011 12:06 PM, Nick Clifton wrote: - df_analyze (); - gcc_checking_assert (all_compares == NULL); Ok except that this particular df_analyze should stay. If it doesn't fix the bug, please try the parts of rth's patch that add the gate and the TODO_df_finish flag. Paolo

Re: [PATCH] Fix PR46556 (poor address generation)

On 10/07/2011 10:00 AM, Richard Guenther wrote: It's a reasonable plan - you'd have to introduce a late reassoc pass though. Can you separate out the RTL fwprop changes? So we can iterate over the tree parts separately. That's indeed better, also because they became CSE changes. Paolo

Re: [RFC] split2 vs df

On 10/07/2011 12:15 AM, Richard Henderson wrote: diff --git a/gcc/recog.c b/gcc/recog.c index d3ecb73..e0557c5 100644 --- a/gcc/recog.c +++ b/gcc/recog.c @@ -3769,20 +3769,33 @@ struct rtl_opt_pass pass_split_all_insns = static unsigned int rest_of_handle_split_after_reload (void) { - /*

Re: [build] Restore FreeBSD/SPARC bootstrap (PR bootstrap/49804)

On 10/06/2011 03:29 PM, Rainer Orth wrote: As reported in the PR, FreeBSD/SPARC bootstrap is broken by one of my previous libgcc patches. While the crtstuff one will fix it, I'd like to avoid breaking the target. The following patch fixes the problem, as confirmed in the PR. Ok for mainline?

Re: Unreviewed libgcc patches

On 10/06/2011 12:21 PM, Rainer Orth wrote: > Can you post an updated patch for this one? I'll try to review the others > as soon as possible. Do you see a change to get the other patches reviewed before stage1 closes? I'd like to get them into 4.7 rather than carry them forward for several m

Re: [PATCH] Fix PR46556 (poor address generation)

On 10/05/2011 10:16 PM, William J. Schmidt wrote: OK, I see. If there's a better place downstream to make a swizzle, I'm certainly fine with that. I disabled locally_poor_mem_replacement and added some dump information in should_replace_address to show the costs for the replacement I'm trying t

Re: [PATCH] Fix PR46556 (poor address generation)

On 10/05/2011 07:22 PM, William J. Schmidt wrote: I don't know off the top of my head -- I'll have to gather that information. The issue is that the profitability is really context-sensitive, so just the isolated costs of insns aren't enough. The forward propagation of the add into (mem (reg REG

Re: [PATCH] Fix PR46556 (poor address generation)

On 10/05/2011 06:13 PM, William J. Schmidt wrote: One other general question about the pattern-match transformation: Is this an appropriate transformation for all targets, or should it be somehow gated on available addressing modes on the target processor? Bootstrapped and regression tested on

Re: PATCH: PR target/50603: [x32] Unnecessary lea

On 10/04/2011 01:00 AM, H.J. Lu wrote: + else +{ + /* Improve address combine in x32 mode. */ + if (TARGET_X32 + && code == PLUS + && !MEM_P (dst) + && !MEM_P (src1) + && MEM_P (src2) ) + src2 = force_reg (mode, src2); +} Perhaps this is wor

Re: Use i386/t-crtstuff for i?86-elf and x86_64-elf

On 10/04/2011 12:14 AM, Joseph S. Myers wrote: i?86-elf and x86_64-elf targets default to -fasynchronous-unwind-tables, like most other x86 targets, and so since they build crtend.o they need to build it with -fno-asynchronous-unwind-tables, like other targets. This patch accordingly makes them

Re: Always check modes in forward_propagate_and_simplify

On Sun, Sep 25, 2011 at 19:00, Richard Sandiford wrote: > There was some discussion a while back about whether we should propagate > hard regs.  But I think that was in the context of propagating a hard-reg > SET_SRC.  In this case, BLAH only mentions pseudos, and I think propagating > for: > >  

Re: [Patch,AVR]: Fix PR50447 (2/n)

On 09/23/2011 11:36 AM, Georg-Johann Lay wrote: Paolo Bonzini schrieb: On 09/23/2011 10:56 AM, Paolo Bonzini wrote: Also, I am curious about one thing: while this is of course a very pragmatic solution, you could also convert AVR to get rid of CC0, do this at expansion time, and get split-wide

Re: [build] Move gthr to toplevel libgcc

On 09/23/2011 11:23 AM, Rainer Orth wrote: Rainer Orth writes: John David Anglin writes: I could find no indication that HP-UX 10 supported anything but DCE threads (especially no POSIX threads), so _REENTRANT being defined must meant DCE threads, unless I'm mistaken. _REENTRANT doesn't i

Re: [Patch,AVR]: Fix PR50447 (2/n)

On 09/23/2011 10:56 AM, Paolo Bonzini wrote: Also, I am curious about one thing: while this is of course a very pragmatic solution, you could also convert AVR to get rid of CC0, do this at expansion time, and get split-wide-types to work as intended. compare-elim.c makes it relatively easy to

Re: [Patch,AVR]: Fix PR50447 (2/n)

On 09/23/2011 10:41 AM, Georg-Johann Lay wrote: Yes, can be done for comparisons, too. I'd prefer a separate patch for it. The subject is bit misleading; should be (2/n). Also, I am curious about one thing: while this is of course a very pragmatic solution, you could also convert AVR to get r

Re: [Patch,AVR]: Fix PR50447

On 09/22/2011 07:43 PM, Georg-Johann Lay wrote: This patch adds the PLUS part to fix the PR. addsi3 has a 8-bit scratch register now so that constants that are not covered by the constraints won't force a reload of the constant. The output routine tries adding the constant and subtracting the n

Re: Unreviewed libgcc patches

On 09/22/2011 08:18 PM, Rainer Orth wrote: [build] Move gthr to toplevel libgcc http://gcc.gnu.org/ml/gcc-patches/2011-08/msg00762.html Can you post an updated patch for this one? I'll try to review the others as soon as possible. Paolo

Re: Define FLAGS_TO_PASS for libquadmath

On 09/20/2011 09:51 PM, Joseph S. Myers wrote: Some target libraries have # Subdir rules rely on $(FLAGS_TO_PASS) FLAGS_TO_PASS = $(AM_MAKEFLAGS) in their Makefile.am. This was introduced to libstdc++-v3 by to fix a problem described in

Re: [build, ada] Allow Solaris bootstrap with C++ (PR bootstrap/49794)

On 07/25/2011 07:00 PM, Rainer Orth wrote: >> * Also, the definition of HAVE_DESIGNATED_INITIALIZERS was wrong for g++ >>on Solaris which again defines __STDC_VERSION__ 199901L. To fix this, >>I never define H_D_I if __cplusplus. > > Is this a valid definition of __STDC_VERSION__ at a

Re: RFC: allowing fwprop to propagate subregs

On 09/14/2011 05:44 PM, Richard Sandiford wrote: > A SUBREG may not be REG nor CONSTANT. Don't you need > to check REG_P/CONSTANT_P on SUBREG? Yeah, good point. There should be a "&& REG_P (SUBREG_REG (new_rtx))" in there. Probably also worth checking for non-paradoxical subregs. I was g

Re: [Ada] Speed up build of gnatools

On 09/06/2011 01:56 PM, Arnaud Charlet wrote: this means using as many processes as there are CPUs, right? It seems pretty Right, but only for gnattools, which is a relatively short time, and which always occurs at the end of the build (so with nothing else running at the same time). dubious

Re: Vector Comparison patch

On 08/18/2011 11:23 AM, Richard Guenther wrote: Yeah, well. That's really a question for language lawyers;) I agree that it would be nice to have mask ? val0 : val1 behave "the same" for scalars and vectors. The question is whether for vectors you define it on the bit-level (which makes it eq

Re: C1X _Noreturn

On 08/18/2011 11:37 PM, Joseph S. Myers wrote: C1X provides a standard way of declaring non-returning functions, with the _Noreturn keyword and a header stdnoreturn.h defining a macro "noreturn" to expand to _Noreturn. This patch implements this syntax and header. Bootstrapped with no regressio

Re: Don't assume hg convert in gcc_update

On 08/24/2011 12:58 PM, Rainer Orth wrote: With both ways, the output of hg log --debug looks like this: extra: branch=gcc-4_6-branch extra: convert_revision=svn:138bc75d-0d04-0410-961f-82ee72b054a4/branches/gcc-4_6-branch@177861 extra: branch=default extra: convert_re

Re: [PATCH] Add infrastructure to merge standard builtin enums with backend builtins

On 08/23/2011 07:29 PM, Michael Meissner wrote: + tm_builtin_funcs="$(tm_builtin_funcs) config/rs6000/rs6000-builtin.def" + tm_builtin_funcs="$(tm_builtin_funcs) config/rs6000/rs6000-builtin.def" These should use braces; build parts are otherwise okay. Paolo

Re: Reduce duplication of compilation commands

On 08/24/2011 12:06 AM, Joseph S. Myers wrote: This patch, relative to a tree with my patch applied, reduces the number of explicit compilation rules in gcc/ and subdirectory makefiles by using CFLAGS-$@ settings when a target needs extra

Re: Reduce duplication of compilation commands

On 08/24/2011 12:06 AM, Joseph S. Myers wrote: This patch, relative to a tree with my patch applied, reduces the number of explicit compilation rules in gcc/ and subdirectory makefiles by using CFLAGS-$@ settings when a target needs extra

Re: RFC: [build, ada] Centralize PICFLAG configuration

On 08/22/2011 07:11 PM, Rainer Orth wrote: installed, thanks. Do I need to sync the config and libiberty parts to src manually or does this happen by some sort of magic? I'll take care of that. Paolo

Re: PING: PATCH: PR target/46770: Use .init_array/.fini_array sections

On 08/22/2011 04:45 PM, H.J. Lu wrote: Can I check in this patch to address AIX issue first? I will submit a patch to test ".section .init_array" later? Thanks. Yes. Paolo

Re: RFC: [build, ada] Centralize PICFLAG configuration

On 08/19/2011 09:11 PM, Rainer Orth wrote: 2011-07-31 Rainer Orth config: * picflag.m4: New file. gcc: * configure.ac (GCC_PICFLAG_FOR_TARGET): Call it. (PICFLAG_FOR_TARGET): Substitute. * aclocal.m4: Regenerate. * configure: Regenerate.

Re: CFT: [build] Move libgcc2 to toplevel libgcc

On 08/16/2011 10:16 AM, Rainer Orth wrote: Agreed. I'd prefer to first complete the build side of the migration from gcc (mostly target headers left now, which seems to be somewhat involved on first check), then deal with the libgcc-only macros, and only then look into cleaning up the end result

Re: RFC: [build, ada] Centralize PICFLAG configuration

On 08/16/2011 01:08 PM, Arnaud Charlet wrote: Please post them. OK, here they are. FWIW, I have no idea how these changes will play with libada (in particular the stamp-tools handling), so I suspect these changes may require a bit of adjustment to be suitable. Wouldn't you use these targets wi

Re: RFC: [build, ada] Centralize PICFLAG configuration

On 08/16/2011 09:53 AM, Rainer Orth wrote: > actually makes some sense---so the general approach in your patch is good. Indeed, but IMO it makes sense in general, not only for SPARC, but for all targets that distinguish between -fpic and -fPIC. > The patch is okay. You mean as is, with all

Re: RFC: [build, ada] Centralize PICFLAG configuration

On 08/16/2011 09:44 AM, Rainer Orth wrote: > So passing PICFLAG down to the gcc/ada/gcc-interface Makefile and not > just via libada/Makefile is indeed important. This seems to be easy: unless I'm mistaken, it should suffice to just call GCC_PICFLAG in gcc/configure.ac and substitute the resul

Re: RFC: [build, ada] Centralize PICFLAG configuration

On 08/16/2011 09:52 AM, Arnaud Charlet wrote: > I've often had serious trouble when I tried to run make > gnatlib/gnatlib-shared in gcc/ada. Apparently "someone" in the past removed too many things from the Makefile which broke partly this support (probably thinking that with libada/Makefile

Re: CFT: [build] Move libgcc_tm_file to toplevel libgcc

On 08/16/2011 04:59 AM, Rainer Orth wrote: None of them uses any of those macros, so I think we're safe. Yes, I checked the same now. Looks like we're good. I'll review the other patches soon, but they are _huge_! :) Paolo

Re: CFT: [build] Move libgcc_tm_file to toplevel libgcc

On 08/15/2011 02:05 PM, Joseph S. Myers wrote: > This patch almost completes the build side of the libgcc moves. It > moves the libgcc_tm_file support to libgcc/config.host (tm_file), where > it belongs. It builds on a patch Paolo posted some time ago, with some > minor corrections (introdu

Re: RFC: [build, ada] Centralize PICFLAG configuration

On 08/15/2011 10:53 AM, Rainer Orth wrote: * The general approach between libtool and libiberty differs. Unless otherwise specified (PIC is the default or doesn't work for some reason), libtool defaults to -fPIC, while libiberty has a strange mixture of -fPIC/-fpic and nothing, without

Re: CFT: [build] Move libgcc_tm_file to toplevel libgcc

On 08/15/2011 10:30 AM, Rainer Orth wrote: This patch almost completes the build side of the libgcc moves. It moves the libgcc_tm_file support to libgcc/config.host (tm_file), where it belongs. It builds on a patch Paolo posted some time ago, with some minor corrections (introducing the require

<    1   2   3   4   5   6   >