Re: [Ping] Fix gcc/gcov.c and libgcc/libgcov.c to fix build on VxWorks

Il 11/06/2012 13:56, rbmj ha scritto: >>> 1. VxWorks does not have a variadic open - it must receive three >>> arguments. gcc/gcov.c however opens a file for reading and does not >>> pass in a mode argument, which causes an error on vxWorks. This just >>> adds a platform-based ifdef around this.

Re: [Patch] Add AC_ARG_ENABLE for libstdc++-v3

Il 11/06/2012 13:59, rbmj ha scritto: > On 05/22/2012 04:37 PM, rbmj wrote: >> This patch adds an AC_ARG_ENABLE option to build/not build >> libstdc++-v3. I wrote the patch in order to allow the user to >> override the automatic disable for libstdc++-v3 for certain targets. > Ping^2 on http://gcc.

Re: [RFC PATCH] Add alloc_size attribute to the default operator new and operator new[]

On 08/03/2011 02:46 PM, Richard Guenther wrote: If that's reasonable then adding the malloc attribute should be, too. Making aliasing stricter for -D_FORTIFY_SOURCE=2 sounds wrong though. Paolo

Re: CFT: [build] Move fp-bit support to toplevel libgcc

On 08/03/2011 03:46 PM, Rainer Orth wrote: Ok for mainline if they pass? I think the avr-lib.h and h8300-lib.h files should be modified to only define the constants when compiling fp-bit, because they pollute the namespace. Both avr and h8300 only use floats, so you can wrap them in #ifdef

Re: CFT: [build] Move soft-fp support to toplevel libgcc

On 08/03/2011 04:01 PM, Rainer Orth wrote: Configure tests could also make a better replacement for softfp_wrap_start and softfp_wrap_end. We've got two uses left right now: * libgcc/config/arm/t-softfp has #ifdef __ARM_ARCH_6M__. One could probably use AC_EGREP_CPP([__ARM_ARCH_6M__], , [a

Re: [PATCH] Correct zlib checks [Was: binutils prerequisites (recent zlib version - what else?)]

On 08/05/2011 12:07 AM, Maciej W. Rozycki wrote: 2011-08-04 Maciej W. Rozycki config/ * zlib.m4 (AM_ZLIB): Check for compressBound instead of zlibVersion. Ok. Paolo

Re: [PATCH, ARM] Generate conditional compares in Thumb2 state

On 08/05/2011 03:19 AM, Ramana Radhakrishnan wrote: cmp r0, #43 it ne cmpne r1, #45 it ne movne r0, r1 bx lr [...] there could be a single it block to handle both and thus you could make this even better with cmp r0, #43 i

Re: [build] Move unwinder to toplevel libgcc (v2)

On 08/03/2011 03:32 PM, Rainer Orth wrote: It should incorporate all review comments and a few errors I've noticed during final review have been corrected. I've received approval for the Darwin bits, Steve successfully tested on HP-UX/IA64 and Linux/IA64 at least bootstrapped. VMS/IA64 approval

Re: [PATCH] Extend VRP BIT_IOR_EXPR to handle sign-bit

On 08/05/2011 01:04 PM, Richard Guenther wrote: (I believe that's the only bit we know sth about when both vr.min and vr.max are negative). Depends, if the value is between -2^16 and -1, we know something about all the bits to the left of bit 15. I think a better mask is: * MUST_BE_NONZERO

Re: [build] Move unwinder to toplevel libgcc (v2)

On 08/05/2011 01:46 PM, Rainer Orth wrote: >> How should we proceed with this patch, especially given the quite >> moderate comments from most affected target maintainers? > > ARM is the only target we should care a bit about. Any chance you can try > cross-compiling it (with a combined tre

Re: [build] Move unwinder to toplevel libgcc (v2)

On Fri, Aug 5, 2011 at 20:18, Mikael Morin wrote: > I suppose it is this patch that breaks bootstrap on 86_64-unknown-freebsd8.2: > /home/mik/gcc4x/src/gcc/crtstuff.c:64:28: fatal error: unwind-dw2-fde.h: No > such file or directory > > Fixed by the the following pat^Whack > Index: crtstuff.c > ==

Re: [build] Move unwinder to toplevel libgcc (v2)

On 08/06/2011 12:43 PM, Mikael Morin wrote: On Friday 05 August 2011 21:48:34 Paolo Bonzini wrote: On Fri, Aug 5, 2011 at 20:18, Mikael Morin wrote: I suppose it is this patch that breaks bootstrap The culprit is indeed r177447. Adding a -I flag? I suppose that makes sense even if

Re: [PATCH] Handle BIT_NOT_EXPR in VRP

On 08/05/2011 02:31 PM, Richard Guenther wrote: This extends VRP to handle BIT_NOT_EXPR by composing ~X as -X - 1 (which should give us anti-range handling for free). Just a small detail, but why not -1 - X which saves the NEGATE_EXPR? :) Paolo

Re: [build] Move unwinder to toplevel libgcc (v2)

On 08/06/2011 05:07 PM, Mikael Morin wrote: On Saturday 06 August 2011 16:31:48 Paolo Bonzini wrote: Can you try this instead? It works. Thanks Committed, thanks. Paolo

Re: [build] Link gengtype with $(LDFLAGS)

On 08/08/2011 02:21 PM, Rainer Orth wrote: IRIX 6.5 bootstrap was broken this weekend: gengtype failed to link in stage2 since it was linked with -lstdc++ (for graphite, from HOST_LIBS), but LDFLAGS (which provides the necessary -L option) is missing. With this patch, the bootstrap continues. I

Re: [build] Move gthr to toplevel libgcc

On 08/08/2011 03:47 PM, Rainer Orth wrote: This patch was bootstrapped without regressions on i386-pc-solaris2.10 and i386-pc-solaris2.11. It probably needs more testing on other non-posix platforms. Did you include Ada? Paolo

Re: [build] Move gthr to toplevel libgcc

On 08/08/2011 03:47 PM, Rainer Orth wrote: This patch moves gthr*.h and related code to toplevel libgcc. Unlike the other outstanding patches (libgcc1, libgcc2, crtstuff, shlib), it is pretty independent from the rest, so I'm posting it first. It was developed last, so there may be conflicts (g

Re: [build] Remove posix95 thread model

On 08/08/2011 02:30 PM, Rainer Orth wrote: While preparing the patch to move gthr* to toplevel libgcc, I noticed that we still have half-hearted support for the posix95 thread model. No port uses it as the default, and the posix95 subdir in libgomp/config isn't referenced anywhere and cannot be u

Re: [PATCH, i386]: Generate addr32 prefixed addresses

On 08/08/2011 05:16 PM, Uros Bizjak wrote: BTW: There is a strange optimization in combine pass, where zero-extended address is converted on-the-fly to: Trying 9 -> 10: Failed to match this instruction: (... (and:DI (subreg:DI (plus:SI (ashift:SI (reg/v:SI 63 [ i ]) (const_

Re: [build] Move gthr to toplevel libgcc

On 08/08/2011 05:42 PM, John David Anglin wrote: ** _DCE_THREADS is used to select gthr-dce.h, but again dce is the only/default model on hppa[12]*-*-hpux10* (pa-hpux10.h), so the special-casing can be removed. DCE threads and thread single are both supported. There are multilibs for both.

Re: [build] Move gthr to toplevel libgcc

On 08/08/2011 05:51 PM, Rainer Orth wrote: libgfortran/acinclude.m4 (LIBGFOR_GTHREAD_WEAK) tries to determine a sensible value. I think libgfortran's approach is the nicest to be added in libgcc/configure.ac. I'm not convinced: when it was introduced (or used more extensively), I w

Re: [PING] [PATCH] Fix PR49907

On 08/09/2011 04:22 PM, Richard Guenther wrote: > > This fixes PR49907 - ok for trunk? Ping. Thanks, Richard. Ok. Paolo

Re: [build] Move sync, mips16.S to toplevel libgcc

On 08/09/2011 02:14 PM, Rainer Orth wrote: > OK for the MIPS parts. Paolo, are you ok with the build parts? Yes. Paolo

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

On 08/10/2011 01:42 PM, Rainer Orth wrote: * Centralize the determination of PICFLAG. Currently, three libraries inside the gcc tree are built PIC without libtool: libgcc, libiberty, and libgnat/libgnarl. libiberty/configure.ac has a hardcoded list of PICFLAG that could be moved to

Re: [build] Move unwinder to toplevel libgcc (v2)

On 08/10/2011 03:56 PM, Rainer Orth wrote: "Joseph S. Myers" writes: This is strange: they copy explicitly goes into $(gcc_objdir): from libgcc/Makefile.in: install-unwind_h: cp unwind.h $(gcc_objdir)/include/unwind.h chmod a+r $(gcc_objdir)/include/unwind.h For an in-tree

Re: [build] Move unwinder to toplevel libgcc (v2)

On 08/10/2011 06:05 PM, Rainer Orth wrote: >> True: it is called once per multilib. > > Just to doublecheck, are we sure that unwind.h is always the same? Yep: it's unwind-generic.h for almost all targets, just a few arm targets use config/arm/unwind-arm.h for all multilibs. Patch doing rm

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

On 08/10/2011 01:14 PM, Rainer Orth wrote: * At the moment, SHLIB_LINK is used in gcc/Makefile.in and the various Make-lang.in fragments to check if the target supports a shared libgcc_s. I've introduced gcc/config/t-slibgcc (from t-slibgcc-dummy) for this, which sets SHLIB = true, addi

Re: [build] Move unwinder to toplevel libgcc (v2)

On 08/10/2011 06:50 PM, Pedro Alves wrote: On Wednesday 10 August 2011 17:05:08, Rainer Orth wrote: > Paolo Bonzini writes: > > >> True: it is called once per multilib. > > > > Just to doublecheck, are we sure that unwind.h is always the same? > >

Re: [build] Move unwinder to toplevel libgcc (v2)

On 08/11/2011 04:25 PM, Joseph S. Myers wrote: > The actual problem are not the runtime libraries, which already know to > search $builddir/.../libgcc for unwind.h and related files. The > copyback is only for the benefit of the testsuite (gcc.target, g++.dg, > gnat.dg, and gcc.dg) where I w

Re: [build] Move unwinder to toplevel libgcc (v2)

On 08/11/2011 05:26 PM, Rainer Orth wrote: > Actually I think the installation of all the installed target headers > should move to libgcc's Makefiles (and the headers themselves should move > under the libgcc/ directory). Agreed, added to my ever-growing todo list for the libgcc move. Thi

Re: [build] Move unwinder to toplevel libgcc (v2)

On Thu, Aug 11, 2011 at 20:19, H.J. Lu wrote: > On Thu, Aug 11, 2011 at 8:23 AM, Rainer Orth > wrote: >> Paolo Bonzini writes: >> >>> On 08/10/2011 06:05 PM, Rainer Orth wrote: >>>>>> >>  True: it is called once per multilib. >>>>

Re: [build] Move unwinder to toplevel libgcc (v2)

On 08/11/2011 08:24 PM, H.J. Lu wrote: On Thu, Aug 11, 2011 at 11:19 AM, H.J. Lu wrote: On Thu, Aug 11, 2011 at 8:23 AM, Rainer Orth wrote: Paolo Bonzini writes: On 08/10/2011 06:05 PM, Rainer Orth wrote: True: it is called once per multilib. Just to doublecheck, are we sure that

Re: [build] Move unwinder to toplevel libgcc (v2)

On 08/12/2011 02:13 PM, H.J. Lu wrote: We may have a race condition here. I opened: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50047 Does the attached patch work? Can you provide a patch instead of the whole Makefile.in? Sorry, that was not intended. Paolo 2011-08-12 Paolo Bonzini

Re: [build] Move unwinder to toplevel libgcc (v2)

rrect. Paolo 2011-08-12 Paolo Bonzini * Makefile.in (install-unwind_h): Create $(gcc_objdir)/include/unwind.h atomically. Index: Makefile.in === --- Makefile.in (revision 177688) +++ Makefile.in (working copy) @@ -991,8 +1001,9 @@ gcc-

Re: [build] Move unwinder to toplevel libgcc (v2)

On 08/12/2011 05:50 PM, H.J. Lu wrote: > Thanks, you are correct. It should work. Thanks. I prefer to wait for testing results to commit it, the breakage is minor. Paolo

Re: [build] Move unwinder to toplevel libgcc (v2)

On 08/12/2011 06:25 PM, H.J. Lu wrote: > > I prefer to wait for testing results to commit it, the breakage is minor. It bootstraps successfully with "make -j12" on a 24 core machine. Thanks. Committed. Paolo

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

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 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: 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: 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: 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: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 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: 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/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: 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/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: 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: [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: 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: 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: 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: [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: 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: [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: 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: 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: [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: [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 (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: [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 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: 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: 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: 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: [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] 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 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: 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: [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: [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: [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: 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 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: [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: 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: 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 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 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 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 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 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,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,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, i386]: Avoid partial reg stall with arith insn + setCC + movzbl sequence

Il 12/03/2012 09:52, Uros Bizjak ha scritto: > +(define_peephole2 > + [(parallel [(set (reg FLAGS_REG) (match_operand 0 "" "")) > + (match_operand 4 "" "")]) > + (set (match_operand:QI 1 "register_operand" "") > + (match_operator:QI 2 "ix86_comparison_operator" > + [(reg FLAG

Re: [Patch ARM/ configury] Add fall-back check for gnu_unique_object

Il 14/03/2012 16:37, Ramana Radhakrishnan ha scritto: > Empirically I spotted this odd behaviour with > gcc_GAS_CHECK_FEATURE and comments - Attached are the 2 alternate > patches that I tried and the difference in the configure scripts > themselves . I am no m4 expert but it does look like the m4

Re: [PATCH] allowing fwprop to propagate subregs

Il 19/03/2012 17:07, Ulrich Weigand ha scritto: > Hello, > > now that the apply_distributive_law change is in, I'd like to pick up > Richard's original patch, see discussion here: > http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00852.html > > The version below integrates all requests for changes t

Re: [debug/profile-mode] broken c++config.h

Il 19/03/2012 13:32, Paolo Carlini ha scritto: Should the addition be \$$ to escape it for the shell as well as for make? (I know it works, but that might not be true for all shells.) >>> i don't think that $, could be expaneded by any shell. >> I'm not worried about it not expanding

Re: [PATCH] Make vector lowering use vectors of proper sign

Il 14/03/2012 15:53, Richard Guenther ha scritto: > > I noticed when trying to fix PR52584 that vector lowering always > creates unsigned vector types. The following fixes that, also > getting rid of the weird use of a langhook. > > Bootstrapped and tested on x86_64-unknown-linux-gnu. > > Richa

Re: PATCH: Properly generate X32 IE sequence

Il 19/03/2012 20:13, Uros Bizjak ha scritto: > 2012-03-19 Uros Bizjak > > * config/i386/i386.c (get_thread_pointer): Add tp_mode argument. > Generate ZERO_EXTEND in place if GET_MODE (tp) != tp_mode. > (legitimize_tls_address) : Always generate > DImode UNSPEC_GOTNTPOFF

Re: [debug/profile-mode] broken c++config.h

Il 20/03/2012 11:33, Paolo Carlini ha scritto: > On 03/20/2012 10:22 AM, Paolo Bonzini wrote: >> I think \$$ is better. Besides that it looks good. > Thanks for the review. Yesterday, when Benjamin had a look, I decided to > go ahead and just commit the patch as posted (afte

Re: [Patch V2] libgfortran: do not assume libm

Il 22/03/2012 09:30, Tristan Gingold ha scritto: > Hi, > > this is version 2 of the patch. > > The initial problem is that libgfortran configure.ac used AC_CHECK_LIB([m]…) > to check wether several math functions are available. That doesn't work on > VMS, because there is no such things as a l

Re: [Ping][PATCH, libstdc++-v3] Enable to cross-test libstdc++ on simulator

Il 23/03/2012 13:40, Paolo Carlini ha scritto: > Hi, > > On 03/07/2012 06:22 AM, Terry Guo wrote: >> Hello, >> >> Can anybody please review and approve the following simple patch? Thanks >> very much. >> >> http://gcc.gnu.org/ml/libstdc++/2011-08/msg00063.html > apparently somebody, somewhere, app

Re: [Patch V2] libgfortran: do not assume libm

Il 30/03/2012 12:22, Tristan Gingold ha scritto: > > On Mar 27, 2012, at 10:38 AM, Janne Blomqvist wrote: > >> On Tue, Mar 27, 2012 at 11:01, Tristan Gingold wrote: >>> Hi, >>> >>> this patch fixes this issue. Is it OK ? >> >> Ok. >> >>> Maybe we should include the AC_DEFINE action within GCC_C

Re: [Patch]: use mmap.m4 in gcc/configure

Il 03/04/2012 11:25, Tristan Gingold ha scritto: > Hi, > > the gcc_AC_FUNC_MMAP_BLACKLIST function in gcc/acinclude.m4 is exactly the > same as the GCC_AC_FUNC_MMAP_BLACKLIST function in config/mmap.m4 (except the > case of the first three letters). This patch makes gcc/configure.ac uses > con

Re: fix left-over debug insns in DCE

Il 13/04/2012 17:58, Alexandre Oliva ha scritto: > > I've just installed the patch, but if you find the need for any further > improvement, let me know and I'll do it right away. I wonder if it makes any sense to move the dead_debug_* stuff to its own file... Paolo

Re: [patch] Remove strange case cost code

Il 17/04/2012 10:45, Richard Guenther ha scritto: > > Also it is possble to get an historgrams from profile feedback into > > switch expansion. I always wanted to do that once switch expansion code > > is cleaned up and moved to gimple level... > > Indeed. At least the parts that expand switch st

Re: [RFA] Update config.sub to 2012-04-18 version.

Il 20/04/2012 02:27, Joel Brobecker ha scritto: > Hello everyone, > > I wasn't sure if I needed approval for this patch or not, but better > be safe than sorry. I'll apply to both GCC and then src when I receive > confirmation that it's OK to apply. > > I would like to update the config.sub scrip

<    1   2   3   4   5   6   >