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: 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: 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: [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/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: [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: [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: 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: 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 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 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: [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: [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: 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: [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: [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] 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: [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 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 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] 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] 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: [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] 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: [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

On 01/30/2012 09:44 AM, Andrey Belevantsev wrote: Does this help? That would fix the problem of multiple notes per insn (as we wanted to do initially), but I didn't understand whether this is the real problem or the problem is the reload not happy with disappearing notes. Also I can't reprodu

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

Jakub Jelinek writes: The following patch attempts to perform a separate linker check (grepping objdump of a linked binary) and checks so far glibc version which is known to support .init_array properly. Perhaps other C libraries could be added there too (does e.g. Solaris support .init_array

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

On 01/30/2012 06:00 PM, Rainer Orth wrote: > Can you test Linux too? The change of -e0 looks good, but I'd rather check > on the actual system. I can test on x86_64-unknown-linux-gnu, just not on my laptop at home. Note that you only need to test ./configure, not bootstrap/regtest. Actual

Re: [RFC, 4.8] Magic matching for flags clobbering and setting

On 02/14/2012 12:52 AM, Steven Bosscher wrote: Other than that: To convert a port, there is still a lot of work to be done to define and handle the various CC modes properly (well, not for the pdp11, because it writes out >1 insn for most define_insns), but it is great not having to define all th

Re: [PATCH] Prefer reg as first operand in commutative operator

On 02/14/2012 10:52 AM, Jakub Jelinek wrote: >/* Complex expressions should be the first, so decrease priority > of objects. Prefer pointer objects over non pointer objects. */ > - if ((REG_P (op) && REG_POINTER (op)) > -|| (MEM_P (op) && MEM_POINTER (op))) > - retur

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

On 02/15/2012 06:09 PM, Rainer Orth wrote: > Paolo Bonzini writes: > >> This must be a separate macro in acinclude.m4 that is AC_REQUIREd from >> gcc_AC_INITFINI_ARRAY. > > Here's an updated patch that does so. During testing, I found one > additional complicati

Re: [PATCH] Fix up libstdc++ build breakage with ldbl-extra.ver

Il 28/02/2012 09:50, Jakub Jelinek ha scritto: > - $(EGREP) -v '#(#| |$$)' $@.tmp | \ > + $(EGREP) -v '^[ ]*#(#| |$$)' $@.tmp | \ I don't know this part very well, so I wonder why you have to remove comments at all... hence I wonder if sed 's/##.*//;s/# .*//;s/#$//' (alternation i

Re: [PATCH] Fix up libstdc++ build breakage with ldbl-extra.ver

Il 28/02/2012 10:19, Jakub Jelinek ha scritto: >>> > > - $(EGREP) -v '#(#| |$$)' $@.tmp | \ >>> > > + $(EGREP) -v '^[ ]*#(#| |$$)' $@.tmp | \ >> > >> > I don't know this part very well, so I wonder why you have to remove >> > comments at all... hence I wonder if sed 's/##.*//;

Re: [PATCH] Ignore hard register uses in DEBUG_INSNs for regs_ever_live (PR bootstrap/52397)

Il 29/02/2012 00:37, Jakub Jelinek ha scritto: > Hi! > > Bootstrap fails on ia64-linux with Ada currently, because we get > a -fcompare-debug failure on one of the files, where a debug_insn > is the only insn that references in5 hard register (which is live on > entry of the first bb). hard_regs_

Re: [build, ada, doc] Remove --enable-threads=gnat support

On 05/23/2011 12:33 PM, Rainer Orth wrote: > Certainly looks good to me, although I probably can't officially approve it. I think you can since this only affects Ada. I'll wait a day or two if anyone objects, then install the patch. It's okay for me too. Paolo

Re: Put more common objects in libcommon-target.a

On 05/24/2011 01:42 PM, Joseph S. Myers wrote: This patch continues preparing for a target structure shared by the driver (including for this purpose collect2 and gnatbind) and the core compilers by creating a library libcommon-target.a to contain the shared code that may have such target depende

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

On 05/27/2011 05:54 PM, Bernd Schmidt wrote: Like this? Untested so far beyond making sure it builds. Yes. Paolo

Re: Faster string streaming

On 05/29/2011 06:14 PM, Richard Guenther wrote: > > -/* Returns a hash code for P. */ > +/* Returns a hash code for P. > + Shamelessly*/ ... stolen from libiberty. ? Ok with that comment adjusted. Why steal it :) if you can instead add the code to libiberty? Paolo

Re: [build] Move MD_UNWIND_SUPPORT to toplevel libgcc

On 05/30/2011 07:54 PM, Kai Tietz wrote: > -/* For 64-bit Windows we can't use DW2 unwind info. Also for multilib > - builds we can't use it, too. */ > -#if !TARGET_64BIT_DEFAULT&& !defined (TARGET_BI_ARCH) > -#define MD_UNWIND_SUPPORT "config/i386/w32-unwind.h" > -#endif > - > /* This matc

Re: [build] Move MD_UNWIND_SUPPORT to toplevel libgcc

On 05/30/2011 05:43 PM, Rainer Orth wrote: +md-unwind-support.h: config.status + if test -n "$(md_unwind_header)"; then \ + echo "#include \"config/$(md_unwind_header)\""> $@; \ + else \ + :> $@; \ + fi Can you add a default file md-unwind-none.h and use AC_

Re: [build] Move ENABLE_EXECUTE_STACK to toplevel libgcc

On 05/30/2011 05:59 PM, Rainer Orth wrote: This is my hopefully last patch for toplevel libgcc moves: it moves ENABLE_EXECUTE_STACK to $target-lib.h headers in libgcc/config. Since gcc/config/sol2.h is only used on Solaris targets anymore and Solaris 8 is the minimal supported version, I've remo

Re: [build] Move Solaris 2 startup files to toplevel libgcc, revised

On 05/30/2011 04:29 PM, Rainer Orth wrote: * Non-Solaris SPARC changes: >> >> After I had moved sparc/sol2-c[in].asm to libgcc, I noticed that >> despite the name a few non-Solaris targets uses those files, too: >> >> sparc-*-elf*, sparc-*-rtems*, sparc64-*-elf*, sparc64-*-rtems* > >

Re: [build] Move Tru64 UNIX startup files to toplevel libgcc

On 05/30/2011 05:12 PM, Rainer Orth wrote: Ok for mainline after a fresh bootstrap? Ok. This depends on the t-slibgcc-dummy file from the Solaris patch, so feel free to move it to this patch (together with s/t-slibgcc-darwin/t-slibgcc-dummy/). Paolo

Re: [build] Move MD_UNWIND_SUPPORT to toplevel libgcc

On 05/31/2011 11:30 AM, Kai Tietz wrote: The issue is that in combination of 32-bit and 64-bit we need to default here to SjLj, Ok, then what you're testing is actually whether you're using sjlj or dw2 unwinding. config/i386/cygming.h will ensure that this is the same as testing TARGET_BI_AR

Re: [build] Move ENABLE_EXECUTE_STACK to toplevel libgcc

Seems like a plan, but I didn't go in this direction since I couldn't test anything like this. As long as you test the general configury on 1-2 platforms, it's not any less tested than what you have now. The various __enable_execute_stack implementations differ in minor ways that would have

Re: [build] Move MD_UNWIND_SUPPORT to toplevel libgcc

On 06/03/2011 04:35 PM, Rainer Orth wrote: Apart from those changes, the patch addresses the PowerPC Darwin and Windows32 issues as suggested: * rs6000/darwin-unwind.h is wrapped in !__LP64__, while removing the need for the !DARWIN_LIBSYSTEM_HAS_UNWIND test (only defined on Darwin 9 and u

Re: [build] Move ENABLE_EXECUTE_STACK to toplevel libgcc

On 06/03/2011 05:45 PM, Rainer Orth wrote: Paolo Bonzini writes: >> Seems like a plan, but I didn't go in this direction since I couldn't >> test anything like this. > > As long as you test the general configury on 1-2 platforms, it's not any >

Re: [build] Remove LIB2ADDEHDEP

On 06/03/2011 05:11 PM, Rainer Orth wrote: Bootstrapped without regressions on i386-pc-solaris2.11, ok for mainline? I suppose this is obvious. The patch is okay, I'll look at the rest next week. Paolo

Re: [build] Move ENABLE_EXECUTE_STACK to toplevel libgcc

On 06/06/2011 11:17 AM, Rainer Orth wrote: * Instead of __FreeBSD__, one could use HAVE_SYSCTLBYNAME instead, but that would need a new libgcc config.h header. In addition, we might have to check for kern.stackprot to make sure the code really works. * Similarly, instead of testing __sun_

Re: [build] Use crtfastmath.c on IRIX 6

On 06/06/2011 11:32 AM, Rainer Orth wrote: On top of the IRIX 6 toplevel libgcc move, I noticed that IRIX doesn't use crtfastmath.o yet. This patch corrects this, bootstrapped without regressions on mips-sgi-irix6.5. While doing this, I noticed that libgcc/config/mips/t-crtfm is identical (modu

Re: [PATCH] fixincludes/Makefile for Interix Rev 2

On 06/07/2011 06:37 AM, Douglas B Rupp wrote: Revised and retested patch attached. OK to commit? It should be enough to add AC_USE_SYSTEM_EXTENSIONS to configure.ac instead (right after AC_PROG_CC). Paolo

Re: [build] Move ENABLE_EXECUTE_STACK to toplevel libgcc

On 06/07/2011 05:30 PM, Rainer Orth wrote: > So my view is that you should define __LIBGCC_TRAMPOLINE_SIZE__, only if > -fbuilding-libgcc. I can give it a try if I can figure out how to define -fbuilding-libgcc via the option handling machinery. I just want to avoid having to implement too ma

Re: Patch: aesthetics for gcc/cp/cxx-pretty-print.c

On 06/06/2011 04:17 AM, Bruce Korb wrote: It also caused a code analysis tool to wander off into the weeds. And "x, break;" didn't? :) (First time I see it, I swear). Paolo

Re: [PATCH] fixincludes/Makefile for Interix Rev 3

On 06/08/2011 08:02 AM, Douglas B Rupp wrote: Reformulated as per your suggestion, and retested. OK to commit? Yes, thanks! Paolo

Re: PING: PATCH: PR other/49325: Incorrect target HAVE_INITFINI_ARRAY check

Why are you not changing the gcc_AC_ macro and instead introducing duplicate code? Perhaps the right solution is to add a final argument to the AC_RUN_IFELSE macro (don't know, I should be on holiday and hence I do not have the source code at hand :)); in any case this is _not_ how you add tests th

Re: PING: PATCH: PR other/49325: Incorrect target HAVE_INITFINI_ARRAY check

On Sat, Jun 18, 2011 at 01:24, H.J. Lu wrote: >> Why are you not changing the gcc_AC_ macro and instead introducing >> duplicate code? Perhaps the right solution is to add a final argument >> to the AC_RUN_IFELSE macro (don't know, I should be on holiday and >> hence I do not have the source code

Re: Unreviewed libgcc build patch

Ok without the commented info evaluation, and with the per-target macro renamed to c_flags-$<. Thanks, Paolo 2011/6/20, Rainer Orth : > The following patch > > [build, libgcc] Correctly apply c_flags in shared-object.mk > http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01055.html > >

Re: [PATCH (4/7)] Unsigned multiplies using wider signed multiplies

On 06/23/2011 04:41 PM, Andrew Stubbs wrote: I believe this should be legal as long as the top bit of both inputs is guaranteed to be zero. The code achieves this guarantee by zero-extending the inputs to a wider mode (which must still be narrower than the output mode). Yes, that's correct. P

Re: Unreviewed build/libgcc, mudflap patches

On 06/27/2011 01:32 PM, Rainer Orth wrote: Support libmudflap on Solaris (PR libmudflap/38738) http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01446.html This needs the mudflap maintainer. Build changes are okay, the rest is pretty obvious. For pass-stratcliff I'd rather use aut

Re: [build] Move MD_UNWIND_SUPPORT to toplevel libgcc

On 06/21/2011 12:04 PM, Rainer Orth wrote: For md_unwind_header on the other hand, you'd have almost as many cases as in the general case. I fear it's hard to have the configuration split over too many places. So I'd suggest to split the affected cases into Linux and non-Linux ones, with the sl

Re: [build] Move unwinder to toplevel libgcc

On 06/20/2011 02:24 PM, Rainer Orth wrote: * The only unwinder-related macro I haven't moved is LIBGCC2_UNWIND_ATTRIBUTE. It is only defined gcc/config/mips/mips.h. I suppose we would need a libgcc equivalent of tm.h for that, something I didn't want to attack at this point. Something

Re: [build] Move unwinder to toplevel libgcc

On 06/29/2011 12:41 PM, Joseph S. Myers wrote: On Wed, 29 Jun 2011, Paolo Bonzini wrote: On 06/20/2011 02:24 PM, Rainer Orth wrote: * The only unwinder-related macro I haven't moved is LIBGCC2_UNWIND_ATTRIBUTE. It is only defined gcc/config/mips/mips.h. I suppose we would n

Re: [PATCH (3/7)] Widening multiply-and-accumulate pattern matching

On 07/01/2011 01:58 PM, Stubbs, Andrew wrote: Given this test case: unsigned long long foo (unsigned long long a, signed char *b, signed char *c) { return a + *b * *c; } Those rules say that it should not be suitable for optimization because there's an implicit cast from s

Re: [PATCH (3/7)] Widening multiply-and-accumulate pattern matching

On 07/01/2011 03:30 PM, Stubbs, Andrew wrote: > However, perhaps there is a catch. We can do the following thought > experiment. What would happen if you had multiple widening multiplies? > Like 8-bit signed to 64-bit unsigned and then 64-bit unsigned to 128-bit > unsigned? I believe in this

Re: [PATCH (3/7)] Widening multiply-and-accumulate pattern matching

On 07/01/2011 04:55 PM, Stubbs, Andrew wrote: > > What about (u128)c + (u64)((s8)a * (s8)b)? You cannot convert this to > (u128)c + (u128)((s8)a * (s8)b). Oh I see, sorry. Yes, that's exactly what I'm trying to do here. No, wait, I don't see. Where are these multiple widening multiplies you'r

Re: PATCH [6/n]: Prepare x32: PR rtl-optimization/47449: Don't propagate hard register non-local goto save area

On 07/05/2011 01:54 AM, Alan Modra wrote: > Before that, fwprop never tries to work on hard registers. I question this claim. It seems to me that fwprop did look at paradoxical subregs of hard regs before my change. That wasn't part of the design anyway. The main purpose of fwprop's parad

Re: PATCH [6/n]: Prepare x32: PR rtl-optimization/47449: Don't propagate hard register non-local goto save area

On 07/05/2011 10:51 AM, Richard Sandiford wrote: > The patch is okay as far as I'm concerned, but I'm not a maintainer of > fwprop. You probably should be:-) I'd have no problem with that! Paolo

Re: [build] Move MD_UNWIND_SUPPORT to toplevel libgcc

On 07/05/2011 01:52 PM, Rainer Orth wrote: Instead of nested cases, I'd rather use one i[34567]86-*-linux* case and another for the rest, duplicating extra_parts and tmake_file. Same for x86_64-*-linux* vs. the rest. But that's just me. I agree. Paolo

Re: [build] Move MD_UNWIND_SUPPORT to toplevel libgcc

On 07/05/2011 02:13 PM, Thomas Schwinge wrote: Hallo! On Tue, 05 Jul 2011 13:52:08 +0200, Rainer Orth wrote: Like this? [...] Instead of nested cases, I'd rather use one i[34567]86-*-linux* case and another for the rest, duplicating extra_parts and tmake_file. Same for x86_64-*-linux* vs.

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

On 07/07/2011 12:27 PM, Rainer Orth wrote: one might as well argue that they are generic and belong into libgcc itself. Agreed. i[34567]86-*-linux* | i[34567]86-*-kfreebsd*-gnu | i[34567]86-*-knetbsd*-gnu | i[34567]86-*-gnu* | i[34567]86-*-kopensolaris*-gnu) extra_parts="$extra_par

Re: PATCH [1/n] X32: Add initial -x32 support

Did you even _think_ of looking at the sh configury, and do something vaguely similar for x86? You should not duplicate t-linux64 at all. Instead, in config.gcc set m64/m32 as the default value for with_multilib_list on i386 biarch and x86_64. Pass $with_multilib_list to t-linux64 using TM_MULTI

Re: PATCH [1/n] X32: Add initial -x32 support

On Thu, Jul 7, 2011 at 17:12, Uros Bizjak wrote: > On Thu, Jul 7, 2011 at 5:02 PM, H.J. Lu wrote: > >>> Did you even _think_ of looking at the sh configury, and do something >>> vaguely similar for x86? >>> >>> You should not duplicate t-linux64 at all.  Instead, in config.gcc set >>> m64/m32 as

Re: Ping Re: Remove config.gcc support for *local* configurations

On 07/07/2011 05:49 PM, Joseph S. Myers wrote: Ping. This patch is pending review. Ok. Paolo

Re: [patch tree-optimization]: [3 of 3]: Boolify compares & more

On 07/07/2011 06:07 PM, Kai Tietz wrote: + /* We redo folding here one time for allowing to inspect more + complex reductions. */ + substitute_and_fold (op_with_constant_singleton_value_range, + vrp_fold_stmt, false); + /* We need to mark this second pass to avoid re-

Re: [df-scan.c] Optimise DF_REFs ordering in collection_rec, use HARD_REG_SETs instead of bitmaps

On 07/08/2011 05:51 AM, Dimitrios Apostolou wrote: + /* first write DF_REF_BASE */ This is not necessary. These uses are written to use_vec, while the uses from REG_EQUIV and REG_EQUAL are written to eq_use_vec (see df_ref_create_structure). Also, anyway this wouldn't work because

what can be in a group set?

df-scan.c has this code to deal with group sets: /* It is legal to have a set destination be a parallel. */ if (GET_CODE (dst) == PARALLEL) { int i; for (i = XVECLEN (dst, 0) - 1; i >= 0; i--) { rtx temp = XVECEXP (dst, 0, i); if (GET_CODE (temp) =

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

On 07/08/2011 12:33 PM, Rainer Orth wrote: The next patch in the line of toplevel libgcc moves proved to be completely trivial: fixed-bit.[ch] is moved over with corresponding include and Makefile changes. Tested with a C-only --enable-fixed-point non-bootstrap build/test on mips-sgi-irix6.5. W

Re: [build] Move libgcov support to toplevel libgcc

On 07/08/2011 01:31 PM, Rainer Orth wrote: And another easy one: moving libgcov over to libgcc. Bootstrapped without regressions on i386-pc-solaris2.11 and x86_64-unknown-linux-gnu. Ok for mainline? After this one, and once the problems with the unwinder move are sorted out, I've got a few mor

Re: what can be in a group set?

On 07/08/2011 12:43 PM, Richard Sandiford wrote: The docs also say that the first expr_list can be null: If @var{lval} is a @code{parallel}, it is used to represent the case of a function returning a structure in multiple registers. Each element of the @code{parallel} is an @code{expr_

Re: what can be in a group set?

On 07/08/2011 03:05 PM, Dimitrios Apostolou wrote: > > Paolo, something else, in df_mark_reg() is it ever possible for regno to > be >= FIRST_PSEUDO_REGISTER? An assert I've put doesn't trigger for my > simple test :-) >From reading the docs of EH_RETURN_STACKADJ_RTX and EH_RETURN_HANDLER_RTX,

Re: [df-scan.c] Optimise DF_REFs ordering in collection_rec, use HARD_REG_SETs instead of bitmaps

On 07/08/2011 11:05 AM, Dimitrios Apostolou wrote: On Fri, 8 Jul 2011, Jakub Jelinek wrote: On Fri, Jul 08, 2011 at 06:20:04AM +0300, Dimitrios Apostolou wrote: The attached patch does two things for df_get_call_refs(): * First it uses HARD_REG_SETs for defs_generated and regs_invalidated_by_ca

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

On 07/05/2011 04:27 PM, H.J. Lu wrote: diff --git a/gcc/explow.c b/gcc/explow.c index 7387dad..b343bf8 100644 --- a/gcc/explow.c +++ b/gcc/explow.c @@ -383,18 +383,13 @@ convert_memory_address_addr_space (enum machine_mode to_mode ATTRIBUTE_UNUSED, case PLUS: case MULT: -

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

On Sat, Jul 9, 2011 at 23:31, H.J. Lu wrote: > On Sat, Jul 9, 2011 at 2:18 PM, Paolo Bonzini wrote: >> On 07/05/2011 04:27 PM, H.J. Lu wrote: >>>> >>>>  diff --git a/gcc/explow.c b/gcc/explow.c >>>>  index 7387dad..b343bf8 100644 >>>>  ---

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

On 07/11/2011 02:04 AM, H.J. Lu wrote: With my original change, I got (const:DI (plus:DI (symbol_ref:DI ("iplane.1577") [flags 0x2] ) (const_int -4 [0xfffc]))) I think it is safe to permute the conversion and addition operation if one operand is a constant and we are zero-

Re: [build] Remove crt0, mcrt0 support

On 07/12/2011 06:45 PM, Rainer Orth wrote: +crt0.o: $(srcdir)/config/i386/netware-crt0.c + $(crt_commpile) $(CRTSTUFF_T_CFLAGS) -c $< Typo here. Otherwise looks good, thanks. Paolo

Re: [build] Move i386/crtprec to toplevel libgcc

On 07/12/2011 06:37 PM, Rainer Orth wrote: The next easy step in toplevel libgcc migration is moving i386/crtprec.c. I noticed that -mpc{32, 64, 80} wasn't supported on Solaris/x86 yet and corrected that. The only testcase using the switch was adapted to also do so on Darwin/x86 (which already

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

On 07/11/2011 05:54 PM, H.J. Lu wrote: The key is the > > XEXP (x, 1) == convert_memory_address_addr_space >(to_mode, XEXP (x, 1), as) > > test. It ensures basically that the constant has 31-bit precision, because > otherwise the constant would change from e.g. (const_i

Re: [PATCH] bash vs. dash: Avoid unportable shell feature in gcc/configure.ac

On 07/13/2011 06:13 PM, Thomas Schwinge wrote: Alternatively, gcc_GAS_CHECK_FEATURE could be changed to emit the temporary file by using a shell here-doc, which is what AC_TRY_COMPILE is doing, for example. Change instead echo ifelse(...) > conftest.s to AS_ECHO([m4_if(...)]) > conftest.s i

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

On Wed, Jul 13, 2011 at 18:39, H.J. Lu wrote: >> Why?  Certainly Y = 8 has 31-bit (or less) precision.  So it has the same >> representation in SImode and DImode, and the test above on XEXP (x, 1) >> succeeds. > > And then we permute conversion and addition, which leads to the issue you > raised

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

>>> Why?  Certainly Y = 8 has 31-bit (or less) precision.  So it has the same >>> representation in SImode and DImode, and the test above on XEXP (x, 1) >>> succeeds. >> >> And then we permute conversion and addition, which leads to the issue you >> raised above.  In another word, the current code

Re: [PATCH] bash vs. dash: Avoid unportable shell feature in gcc/configure.ac

Ok. Paolo On Wed, Jul 13, 2011 at 19:17, Thomas Schwinge wrote: > Hallo! > > On Wed, 13 Jul 2011 18:23:50 +0200, Paolo Bonzini wrote: >> On 07/13/2011 06:13 PM, Thomas Schwinge wrote: >> > Alternatively, gcc_GAS_CHECK_FEATURE could be changed to emit the >> >

Re: Remove NetWare support

On 07/14/2011 08:40 PM, Rainer Orth wrote: I've got a preliminary NetWare removal patch ready (yet untested), but have a couple of questions: * Given that there's a considerable amount of NetWare support still in src, toplevel support has to stay. On the other hand, the reference in confi

Re: [RFC] Avoid unnecessary futex_wake syscalls when all threads are busy waiting

On 07/15/2011 11:37 AM, Jakub Jelinek wrote: While __sync_lock_test_and_set isn't a full barrier on all targets, I hope it doesn't matter, because the inline caller has already done one __sync_val_compare_and_swap which is a full barrier. Why not take the occasion to add the __sync_swap extensi

Re: [RFC, cfg/dataflow] Properly split EH edges for -freorder-blocks-and-partition

On Fri, Jul 22, 2011 at 02:09, Richard Henderson wrote: > I should mention here that I suspect the Cleanest solution is > to make DF_DEFER_INSN_RESCAN imply that we also shouldn't grab > data from the blocks those new insns are in either.  In this > way one can create the block, link it up properl

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

On Wed, Jul 20, 2011 at 18:35, Rainer Orth wrote: >  I've hacked around this by wrapping the AM_ICONV calls in >  AC_LANG_{PUSH, POP}(C++), but I think this exposes a fundamental >  issue: the configure tests must be performed with the compiler used >  for the build.  That this works without is p

Re: [RFC, cfg/dataflow] Properly split EH edges for -freorder-blocks-and-partition

On Sat, Jul 23, 2011 at 02:32, Richard Henderson wrote: > Does anyone object to me committing the patch as-is, with the > understanding that either Paulo or myself will, before too long, > clean up the DF interface as described above? I would kind of object for a pass that is enabled at some -O l

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

On 07/13/2011 07:48 PM, H.J. Lu wrote: Here is the patch. OK for trunk? Again, at least you should explain clearly _why_ you need ignore_address_wrap_around. You said elsewhere x32 should be first clean, then fast. if (GET_CODE (x) == SUBREG && SUBREG_PROMOTED_VAR_P (x) && GET_

[PATCH] Saner return value for gen_lowpart_no_emit

be changed to try other simplifications if gen_lowpart_no_emit fails; for now, I'm just avoiding a NULL pointer dereference. 2011-07-25 Paolo Bonzini * rtlhooks.c (gen_lowpart_no_emit_general): Remove. * rtlhooks-def.h (gen_lowpart_no_emit_general): R

Re: added some assert checks in hard-reg-set.h

On Mon, Jul 25, 2011 at 21:03, Dimitrios Apostolou wrote: >        * hard-reg-set.h (TEST_HARD_REG_BIT, SET_HARD_REG_BIT, > CLEAR_HARD_REG_BIT): Added some assert checks for test, set and clear > operations of HARD_REG_SETs, enabled when RTL checks are on. Runtime > overhead was measured as neglig

Re: PATCH RFA: Correct toplevel configury

On 07/26/2011 08:00 PM, Ian Lance Taylor wrote: Ping. On Thu, Jul 21, 2011 at 11:20 PM, Ian Lance Taylor wrote: One of my recent patches broke the toplevel configury. I moved a test of $configdirs to a point before nonexistent directories have been removed from configdirs. The test was for w

<    1   2   3   4   5   6   >