Re: Commit: ARM: Document -munaligned-access

> From: nick clifton > Date: Fri, 20 Jul 2012 09:18:52 +0200 > "approved - please apply". Thanks! I see the last sentence could do with better punctuation, so I added the obvious comma. Installed as follows. Index: changes.html =

Committed, CRIS: remove unused variables from cris_asm_output_ident

Looks like these were left from Steven's ident-cleanup. Steven, for future reference, you might want to use contrib/warn_summary on the build-logs. ;) Incidentally, the magic option to increase diff context for svn is -x -U as in "-x -U5" below, just to show there's not much else in that function.

Yet another gcc.c-torture/execute/20101011-1.c DO_TEST 0

The #elif defined ... #define DO_TEST 0 exceptions are accumulating. Maybe the DO_TEST = 1 case should be the exception... Committed. gcc/testsuite: * gcc.c-torture/execute/20101011-1.c (DO_TEST): Define as 0 for CRIS. Index: gcc.c-torture/execute/20101011-1.c

Re: [RESEND-2][PATCH] Allow printing of escaped curly braces in assembler directives with operands

On Wed, 18 Jul 2012, Siddhesh Poyarekar wrote: > Hi, > > Resending. I did not get any responses the last two times and I too > forgot about it. Can someone please review this? This is *not* an approver-review. > An assembler directive with an operand is filtered through > output_asm_insn (or asm

Committed: executable-stack note for CRIS

Tested crisv32-linux (much as you can do without actually installing a new /lib/ld.so.1 with the changed defaults). Yep, this is actually a change of the default in glibc (port to be submitted), but changing it this way is safe: with old libraries lacking a note, they default to not having an execu

Committed: testsuite updates for recent changes in atomics for cris*-linux*

I changed the defaults for cris*-linux*, but didn't fix the test-suite to go with that, so with unaligned accesses working, the test-suite still checked that they trapped, doh. Here's the update, checked trunk cris-elf and crisv32-elf (because of difference in atomics) and crisv32-linux* on the lo

Re: Commit: ARM: Document -munaligned-access

On Fri, 20 Jul 2012, Ryan Mansfield wrote: > On 12-07-19 05:33 PM, Hans-Peter Nilsson wrote: > > > > Index: changes.html > > > > +some source codes generates code that accesses memory on unaligned > > > > +adresses. This will require the kernel

Re: [patch] Move lowering of switches to bit tests to GIMPLE

On Tue, 24 Jul 2012, Richard Henderson wrote: > On 07/21/2012 06:10 AM, Oleg Endo wrote: > > I think on SH the cost test in lshift_cheap_p with > > gen_rtx_ASHIFT (word_mode, const1_rtx, reg), speed_p); > > > > will always 'fail', because of sh.c (shiftcosts): > > /* There is no pattern for co

Re: [RFC] Target-specific limits on vector alignment

> From: Ulrich Weigand > Date: Tue, 24 Jul 2012 19:38:15 +0200 > > > I've implemented this as a separate hook, rather than using the existing > > > hooks because there's a strong likelihood of breaking some existing ABIs > > > if I did it another way. > > > > > > There are a couple of tests that

Re: [PATCH/MIPS] Emit stack executable note

On Wed, 25 Jul 2012, Andrew Pinski wrote: > Hi, > The Linux kernel already supports non-executable stack since around > February 2010. This patch has GCC emit the notes that are associated > with non-executable stack. What does the kernel do when the note isn't present? > OK? Bootstrapped and

Re: [PATCH v2] Target-specific limits on vector alignment

> From: Ulrich Weigand > Date: Fri, 27 Jul 2012 17:24:08 +0200 > Richard (Earnshaw) has asked me to take over working on this patch now. > > I've now made the change requested above and removed the size argument. > The target is now simply asked to return the required alignment for the > given v

Re: [PATCH,mmix] convert to constraints.md

On Thu, 2 Aug 2012, Nathan Froyd wrote: > As $SUBJECT says. There's not too much interesting here. I did a > fairly literal-minded conversion, so it's possible there's smarter ways > to do some things. Doesn't look too bad though, but ... > Compiled with cross to mmix-knuth-mmixware and spot-ch

Re: Assembly output optimisations (was: PR 51094 - fprint_w() in output_addr_const() reinstated)

On Tue, 7 Aug 2012, Dimitrios Apostolou wrote: > Thanks Andreas, hp, Mike, for your comments. Mike I'd appreciate if you > elaborated on how to speed-up sprint_uw_rev(), I don't think I understood what > you have in mind. I just commented on comments and just above the nit-level; formatting and co

Re: add strnlen to libiberty (was Re: Assembly output optimisations)

On Mon, 6 Aug 2012, Ian Lance Taylor wrote: > On Mon, Aug 6, 2012 at 10:44 PM, Dimitrios Apostolou wrote: > > > > What else is missing to make this patch appropriate for libiberty? Should I > > change the prolog in strnlen.c, since I only copied it intact from gnulib? > > We generally try to avoid

Committed: Fix PR53156, testsuite regression from recent reload change

The regression was mostly due to a failed assumption by the test-case (a minimal solution must match the assembly code patterns), but also due to a different suboptimal sequence after the reload change. The committed patch below fixes the regresssed code, the test-case, and tweaks the comment to m

Heads-up, PR53273: testsuite separation and dilution problem. Fix for PR53272

The problem was spotted while fixing PR53272, a target bug with crisv32-* involving the error-prone notice_update_cc function. When wrapping up the test-case to use as a run-test, adding main and auxiliary functions to the reduced test-case unexpectedly made the bug go away. This despite all func

Re: Heads-up, PR53273: testsuite separation and dilution problem. Fix for PR53272

> From: Richard Guenther > Date: Tue, 8 May 2012 10:50:43 +0200 > On Tue, May 8, 2012 at 5:39 AM, Hans-Peter Nilsson > wrote: > > The problem was spotted while fixing PR53272, a target bug with > > crisv32-* involving the error-prone notice_update_cc function. > >

Fix gcc.dg/lower-subreg-1.c failure (was: [C Patch]: pr52543)

> From: Richard Sandiford > Date: Tue, 1 May 2012 16:46:38 +0200 > To repeat: as things stand, very few targets define proper rtx costs > for SET. IMHO it's wrong to start blaming targets when rtx_cost doesn't take the mode in account in the first place, for the default cost. (Well, except for

Re: Fix gcc.dg/lower-subreg-1.c failure

> From: Richard Sandiford > Date: Wed, 9 May 2012 11:14:49 +0200 > Hans-Peter Nilsson writes: > >> From: Richard Sandiford > >> Date: Tue, 1 May 2012 16:46:38 +0200 > > > >> To repeat: as things stand, very few targets define proper rtx costs >

Re: Use "sed -n …" instead of "sed s/…/p -e d" in s-header-vars

On Mon, 30 Apr 2012, Olivier Hainque wrote: > Hello, > > "sed s/?/p -e d" as used in s-header-vars doesn't work on > at least ia64-hpux, where s/.../p only prints out if -n was > requested as well. > > The attached patch fixes this by using '-n' instead of a > trailing '-e d' > * Makefile.

Committed: fix source-code reference in SIZE_TYPE docs (was: How do I set SIG_ATOMIC_TYPE to a variant of a C-type?)

(Originally a post to gcc@. I don't know why I bother posting there; it usually ends up with a patch. :) > From: Hans-Peter Nilsson > Date: Tue, 15 May 2012 23:44:49 +0200 > > From: "Joseph S. Myers" > > Date: Tue, 15 May 2012 22:06:03 +0200 > > > A

[RFA:] doc: TARGET_LEGITIMIZE_ADDRESS needs to be defined for native TLS

An old patch I finally came around to submit. Verified that the DVI and info output looks ok. Ok to commit with inherent relicensing and whatever? gcc: * doc/tm.texi.in (Addressing Modes) : Mention that this hook needs to be defined for native TLS. * doc/tm.texi: Regenerat

ping: Fix gcc.dg/lower-subreg-1.c failure (was: [C Patch]: pr52543)

> From: Hans-Peter Nilsson > Date: Wed, 9 May 2012 08:02:25 +0200 Ping. I missed the PR number decoration on the ChangeLog entry: PR rtl-optimization/53176 > * rtlanal.c (rtx_cost): Adjust default cost for X with a > UNITS_PER_WORD factor for all X according to

Fix negation in stack_protect_test docs. Heads-up: prediction bug

The label is for branching *around* a block calling a noreturn function. See also the open-coded version which calls emit_cmp_and_jump_insns with EQ. All ports defining it seem ok. They'd notice very quickly, no code compiled with -fstack-protector code requiring stack-protection would work. Als

ping*2: Fix gcc.dg/lower-subreg-1.c failure (was: [C Patch]: pr52543)

> From: Hans-Peter Nilsson > Date: Wed, 16 May 2012 08:24:41 +0200 > > From: Hans-Peter Nilsson > > Date: Wed, 9 May 2012 08:02:25 +0200 > > Ping. I missed the PR number decoration on the ChangeLog entry: > > PR rtl-optimization/53176 > > * rtlan

Re: [PATCH 2/2] Better system header location detection for built-in macro tokens

> From: Dodji Seketeli > Date: Mon, 21 May 2012 15:55:19 +0200 > The location for a built-in macro token is BUILTIN_LOCATION. When we > see that location value, we cannot know if that token was used in a > system header or not. And that can trigger some unwanted warnings on > e.g, the use of __

Committed: typos in atomic patterns docs, md.texi

Committed as obvious. gcc: * doc/md.texi (Standard Names): Fix typos in documentation of atomic patterns. Index: doc/md.texi === --- doc/md.texi (revision 187934) +++ doc/md.texi (working copy) @@ -5885,7 +5885,7 @@ from a c

Committed: "trap" for CRIS.

Implemented because the overhead of calling abort spills over into the frame of the almost-never-calling function. Tested cris-elf, committed. gcc: * config/cris/cris.h (TARGET_HAS_BREAK, TARGET_TRAP_USING_BREAK8): New macros. * config/cris/cris.md ("trap"): Define, enabl

Ping: [RFA:] doc: TARGET_LEGITIMIZE_ADDRESS needs to be defined for native TLS

> From: Hans-Peter Nilsson > Date: Wed, 16 May 2012 02:24:02 +0200 Ping... > An old patch I finally came around to submit. > Verified that the DVI and info output looks ok. > > Ok to commit with inherent relicensing and whatever? > > gcc: > * doc/t

ping*3: Fix gcc.dg/lower-subreg-1.c failure (was: [C Patch]: pr52543)

> From: Hans-Peter Nilsson > Date: Wed, 23 May 2012 06:41:58 +0200 > > From: Hans-Peter Nilsson > > Date: Wed, 16 May 2012 08:24:41 +0200 > > > From: Hans-Peter Nilsson > > > Date: Wed, 9 May 2012 08:02:25 +0200 > > > > Ping. I missed

Committed, CRIS: fix assembling for other ISA variant

If you specified another ISA variant with e.g. -march=, that option got through to the compiler proper and the assembler only if it was -march=v32. Now fixed, tested crisv32-elf and cris-elf. gcc: * config/cris/cris.h (CC1_SPEC): Pass through all -march= and -mcpu= options.

[RFA:] fix bug in configure header-probing for stack protector support in target C library

This patch fixes target-header-probing for cross-builds that aren't using sysroot (just --target and --prefix), as in the difference for crisv32-axis-linux-gnu with an eglibc-2.15-based port: --- cllog.prev Thu May 31 22:00:10 2012 +++ cllog Thu May 31 22:00:09 2012 @@ -1276,7 +1276,7 @@ ch

Committed: atomic support for CRIS

Unfortunately for subtargets where atomic accesses matter, the LL/SC scheme only works for aligned data (i.e. excluding plain cris-elf which is hardly usable), and the CRIS ABI doesn't mandate any alignment (except for functions, mandated 16-bit aligned by the ISA). I guess I could have emitted ca

Re: Committed: atomic support for CRIS

> From: Hans-Peter Nilsson > Date: Fri, 1 Jun 2012 07:58:13 +0200 > - the gUSA atomic method in config/sh/sh.md is really cute, go > see it. Doh, I mean config/sh/sync.md. brgds, H-P

ping*4: Fix gcc.dg/lower-subreg-1.c failure (was: [C Patch]: pr52543)

> From: Hans-Peter Nilsson > Date: Wed, 30 May 2012 04:49:27 +0200 > > From: Hans-Peter Nilsson > > Date: Wed, 23 May 2012 06:41:58 +0200 > > > From: Hans-Peter Nilsson > > > Date: Wed, 16 May 2012 08:24:41 +0200 > > > > From: Hans-Peter Nilss

Committed: xfail gcc.dg/pr46647.c for cris-* and crisv32-*

See the PR. Note well, there is no effect on the emitted assembly code; the failure is in this pass but fixed in another. Thus it does not pass the work/benefit threshold for adding a separate test-case from the code in the PR, just for xfailing this one; and for every xfail there should be a PR.

[RFA:] Caveat for ARM in gcc-4.7/changes.html: unaligned accesses

(CC to ARM maintainer approving the original patch.) I'm listing this under "caveats" rather than "improvements" and before the current top ARM-related caveat (as this one is more important :) because I don't see performance figures in the context of the original patch (r178852) backing up this as

Ping: [RFA:] fix bug in configure header-probing for stack protector support in target C library

> From: Hans-Peter Nilsson > Date: Fri, 1 Jun 2012 01:38:22 +0200 > gcc: > Fix configure test for "stack protector support in target C library". > * configure.ac (test_prefix, test_exec_prefix): Move setting from > inside sysroot handl

Ping*2: [RFA:] doc: TARGET_LEGITIMIZE_ADDRESS needs to be defined for native TLS

> From: Hans-Peter Nilsson > Date: Wed, 16 May 2012 02:24:02 +0200 > gcc: > * doc/tm.texi.in (Addressing Modes) : > Mention that this hook needs to be defined for native TLS. > * doc/tm.texi: Regenerate. <http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01070.html> brgds, H-P

Re: [RFA:] Caveat for ARM in gcc-4.7/changes.html: unaligned accesses

> From: Michael Hope > Date: Fri, 8 Jun 2012 04:42:30 +0200 > On 8 June 2012 12:15, Hans-Peter Nilsson wrote: > > The "some source > > codes" was in the analyzed case a strcpy of a five-byte string > > (busybox/libbb/procps.c:365 'strcpy(filename_t

Re: [RFA:] Caveat for ARM in gcc-4.7/changes.html: unaligned accesses

> From: Michael Hope > Date: Fri, 8 Jun 2012 05:50:52 +0200 > On 8 June 2012 15:20, Hans-Peter Nilsson wrote: > > So the default for ALIGNMENT_TRAP changed in >3.1? > > ALIGNMENT_TRAP is on by default but the early boot time trap is now > conditiona

Re: [RFA:] Caveat for ARM in gcc-4.7/changes.html: unaligned accesses

> From: Hans-Peter Nilsson > Date: Fri, 8 Jun 2012 06:29:04 +0200 > > From: Michael Hope > > Date: Fri, 8 Jun 2012 05:50:52 +0200 > > The combination of > > older Linux ARM kernels and GCC 4.7 gives a faulty kernel. > > We're in agreement! Oh wait sor

Re: [RFC, ivopts] fix bugs in ivopts address cost computation

On Tue, 5 Jun 2012, Sandra Loosemore wrote: > (1) While the address cost computation is assuming in some situations > that pre/post increment/decrement addressing will be used if > supported by the target, it isn't actually using the target's address > cost for such forms -- instead, just the cost

Re: [patch][cris] Clean up some cris-aout remnants

On Tue, 5 Jun 2012, Steven Bosscher wrote: > This patch just cleans up some remaining code for removed cris-aout > subtarget by folding away code that was conditional on TARGET_ELF. > > Tested with a x86_64-linux X cris-elf cross-compiler. OK for trunk? Woohoo, that's a lot of left-over cruft! @@

Committed: fix CRIS build errors with --enable-build-with-cxx.

Trying --enable-build-with-cxx revealed a build regression for cris-elf from the recent atomic support bits. Tested the same, no regressions. Casting those INTVAL's would've been a tiny bit uglier than using a temp, thus. Hey, those were stashed there as ints so what's wrong with passing them as

inc-dec (was: Re: [RFC, ivopts] fix bugs in ivopts address cost computation)

On Sun, 10 Jun 2012, Oleg Endo wrote: > I've tried some of the cases mentioned in > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50749 > with Sandra's patch applied. Unfortunately it didn't help much. But thanks for checking! > There > seem to be other things going wrong with auto-inc-dec. Yeah

Re: [RFA:] Caveat for ARM in gcc-4.7/changes.html: unaligned accesses

> From: Michael Hope > Date: Mon, 11 Jun 2012 00:04:19 +0200 > On 8 June 2012 16:53, Hans-Peter Nilsson wrote: > >> From: Hans-Peter Nilsson > >> Date: Fri, 8 Jun 2012 06:29:04 +0200 > > > >> > From: Michael Hope > >> > Date:

Re: [RFA:] Caveat for ARM in gcc-4.7/changes.html: unaligned accesses

> From: Gerald Pfeifer > Date: Mon, 11 Jun 2012 00:27:21 +0200 > This is only a review wearing my web hat; it is orthogonal to the > discussion with the ARM guys. ;-) > > On Fri, 8 Jun 2012, Hans-Peter Nilsson wrote: > > +On ARM, when compiling for ARMv6 (b

Re: [RFC] Target-specific limits on vector alignment

> From: Richard Earnshaw > Date: Mon, 11 Jun 2012 15:16:50 +0200 > The ARM ABI states that vectors larger than 64 bits in size still have > 64-bit alignment; never-the-less, the HW supports alignment hints of up > to 128-bits in some cases and will trap in a vector has an alignment > that less th

Re: [SH] PR 50749 - Auto-inc-dec does not find subsequent contiguous mem accesses

On Tue, 12 Jun 2012, Kaz Kojima wrote: > Oleg Endo wrote: > > Some of the tests pass, some of them don't because > > of the auto-inc-dec issues mentioned in the PR. > > I thought that the tests which are known to fail are marked > with XFAIL, Yes, with a clear reference to the PR at the xfail. T

Re: [RFA:] Caveat for ARM in gcc-4.7/changes.html: unaligned accesses

> From: Hans-Peter Nilsson > Date: Mon, 11 Jun 2012 00:59:57 +0200 > > From: Michael Hope > > Date: Mon, 11 Jun 2012 00:04:19 +0200 > > > On 8 June 2012 16:53, Hans-Peter Nilsson > > wrote: > > >> From: Hans-Peter Nilsson > > >>

Re: Committed: atomic support for CRIS

> From: Richard Henderson > Date: Tue, 12 Jun 2012 23:04:02 +0200 > On 2012-05-31 22:58, Hans-Peter Nilsson wrote: > > +(define_expand "atomic_compare_and_swap" > > + [(match_operand:SI 0 "register_operand") > > + (match_operand:BWD 1 &

Re: [RFA:] Caveat for ARM in gcc-4.7/changes.html: unaligned accesses

> From: Michael Hope > Date: Wed, 13 Jun 2012 00:43:47 +0200 > On 13 June 2012 02:32, Hans-Peter Nilsson wrote: > >> From: Hans-Peter Nilsson > >> Date: Mon, 11 Jun 2012 00:59:57 +0200 > >> > > user-space code".  Maybe the kernel too, I can't

Re: [RFA:] Caveat for ARM in gcc-4.7/changes.html: unaligned accesses

> From: Hans-Peter Nilsson > Date: Mon, 11 Jun 2012 01:16:09 +0200 > +to be compiled with -mno-unaligned-accesses. Better spelled as "-mno-unaligned-access". Bah. brgds, H-P

Re: [CFT, delay slots] Fix middle-end/49977

On Thu, 4 Aug 2011, Richard Henderson wrote: > This seems to do the trick for sim testing of sh-elf and cris-elf. > > I'm interested in advice re debugging experiences with delay slots. > It seems like for calls there's no alternative but to have the unwind > info be incorrect when stopped at the c

Re: PATCH: Add -mavx2 and properly check numbers of mask bits

On Sun, 7 Aug 2011, H.J. Lu wrote: > Hi, > > opth-gen.awk has > > print "#define " mask name " (1 << " masknum[vname]++ ")" > > and int has 32bits. We should check > > if (masknum[var] > 32) > > instead of > > if (masknum[var] > 31) IIUC the (int32_t) sign-bit is supposed to be reserved and this i

Re: [MMIX] Hookize REGISTER_MOVE_COST

On Mon, 8 Aug 2011, Anatoly Sokolov wrote: > Hi. > > This patch removes obsolete REGISTER_MOVE_COST macro from MMIX back end in > the GCC and introduces equivalent TARGET_REGISTER_MOVE_COST target hook. ...and removed a comment about a moot issue (perfectly ok). > > Regression tested on mmix-

Re: [MMIX] Remove REG_OK_FOR_BASE_P and REG_OK_FOR_INDEX_P macros

On Mon, 8 Aug 2011, Anatoly Sokolov wrote: > Hello. > > This patch remove unused REG_OK_FOR_BASE_P and REG_OK_FOR_INDEX_P macros > from the MMIX back end. > > Regression tested on mmix-knuth-mmixware. > > OK to install? > > * config/mmix/mmix.h (REG_OK_FOR_BASE_P, REG_OK_FOR_INDEX_P):

Re: [build] Move gthr to toplevel libgcc

On Mon, 8 Aug 2011, Rainer Orth wrote: > * SUPPORTS_WEAK is probably best detected with autoconf. We have > libgfortran/acinclude.m4 (LIBGFOR_GTHREAD_WEAK), but should probably > go for m4/ax_sys_weak_alias.m4 from the autoconf-archive instead. If > we're lucky, that macro can detect suppor

Re: [PATCH] Fix PR49937

On Tue, 9 Aug 2011, Richard Guenther wrote: > > This fixes PR49937 - callers of get_{pointer,object}_alignment > probably should not use BIGGEST_ALIGNMENT to limit what these > functions return (why do they do that? Maybe because formerly > the routines returned TYPE_ALIGN? But why wasn't that bo

Re: [Patch,AVR]: Fix PR49903

On Thu, 11 Aug 2011, Georg-Johann Lay wrote: > This is an optimization in machine dependent reorg to > remove redundant comparisons like in > >cc0 = compare (Reg, Num) >if (cc0 == 0) > goto L1 > >cc0 = compare (Reg, Num) >if (cc0 > 0) > goto L2 > > The second comparison

Re: [Patch,AVR]: Fix PR49903

On Sat, 13 Aug 2011, Georg-Johann Lay wrote: > Hans-Peter Nilsson schrieb: > > A glance at AVR makes me think this should already be handled by > > the NOTICE_UPDATE_CC machinery. Any analysis why this doesn't > > happen? With the same test-case (at -Os) I don't

Re: Allow match_test to be used for .md attribute tests

On Sat, 13 Aug 2011, Richard Sandiford wrote: > If the patch is OK, I'd like to make corresponding changes to each port's > .md files. Are they simple enough to count as obvious, or should I get > persmission for each one? Preapproved for CRIS and MMIX. brgds, H-P

Fix spurious match testsuite regressions from "[PATCH, middle end]: Introduce BUILT_IN_I{CEIL_FLOOR_ROUND_RINT} FP-to-int conversion functions"

This patch: > 2011-08-11 Uros Bizjak > > * builtins.def (BUILT_IN_ICEIL{,F,L}, BUILT_IN_IFLOOR{,F,L}, > BUILT_IN_IRINT{,F,L}, BUILT_IN_IROUND{,F,L}: New builtin definitions. > * convert.c (convert_to_integer): Convert to BUILT_IN_ICEIL, > BUILT_IN_IFLOOR, BUILT_IN_IRINT

Re: Fix spurious match testsuite regressions from "[PATCH, middle end]: Introduce BUILT_IN_I{CEIL_FLOOR_ROUND_RINT} FP-to-int conversion functions"

> Date: Mon, 15 Aug 2011 10:43:35 +0200 (CEST) > From: Richard Guenther > On Mon, 15 Aug 2011, Hans-Peter Nilsson wrote: > > So, ok as is? > > If not, would you preapprove tree-dumping decl_uids only at a > > higher dump verbosity level? > > Ok. Yes, definitely

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

> From: Rainer Orth > Date: Mon, 15 Aug 2011 19:01:39 +0200 > * Unlike any other target, cris has crisv32-*-none and cris-*-none > targets which seem to be aliases for their *-elf counterparts. Do we > really need to keep those? While I can inherit e.g. extra_parts from > *-*-elf, there's

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

> From: Rainer Orth > Date: Mon, 15 Aug 2011 19:19:23 +0200 > On top of the crtstuff and libgcc1 patches (and requiring the PICFLAG > centralization still under discussion), here's the bulk of the remaining > moves: it moves all LIBGCC2*, LIB2* macros and referenced files. > > Despite its size,

Re: [4.7][google]Support for getting CPU type and feature information at run-time. (issue4893046)

On Tue, 16 Aug 2011, Sriraman Tallam wrote: (I don't see anyone else making this comment, so maybe I missed something obvious, but I don't think so...) > Support for getting CPU type and feature information at run-time. > > The following patch provides support for finding the platform type at >

Re: [rtl, delay-slot] Fix overload of "unchanging" bit

> Date: Thu, 18 Aug 2011 15:48:41 -0700 > From: Richard Henderson > The following has passed stage2-gcc on sparc64-linux host (full build still > in progress), with --enable-checking=yes,rtl. It surely needs more than that, > and I'm asking for help from the relevant maintainers to give this a t

Re: [PATCH] Add VIS intrinsics header for sparc.

On Fri, 16 Sep 2011, David Miller wrote: > > I've been meaning to toss something like this together for a while. > > If we were going to do this, I wanted to get it out of the way before > adding VIS2 and VIS3 support. While revisiting VIS, *please* consider fixing a big usability problem: the pac

Re: [PATCH] Add VIS intrinsics header for sparc.

On Wed, 21 Sep 2011, David Miller wrote: > From: Hans-Peter Nilsson > Date: Wed, 21 Sep 2011 21:27:08 -0400 (EDT) > > > While revisiting VIS, *please* consider fixing a big usability > > problem: the pack and aligndata builtins don't take GSR in > > account; i

Re: [PATCH] Add VIS intrinsics header for sparc.

On Thu, 22 Sep 2011, David Miller wrote: > Positive feedback for the fact that someone is at least working on > this stuff at all would be appreciated as well. Using it or working on it? Not that much of either, sorry, but what I found when using it, I put in PR48974 (well, besides the ICE's, whi

Re: [PATCH] Add VIS intrinsics header for sparc.

On Sat, 24 Sep 2011, David Miller wrote: > Hans, here is what I'm playing with right now against current > trunk. A spot-check review: > I looked at the use cases for making use of the scale factor in the > VIS %gsr register and it's used similar to how rounding modes are > modified in the FPU co

Re: [PATCH] Add VIS intrinsics header for sparc.

On Sat, 24 Sep 2011, David Miller wrote: > From: Hans-Peter Nilsson > Date: Sat, 24 Sep 2011 17:15:06 -0400 (EDT) > > I'd prefer it as a parameter to the builtins (expanding to two > > insns, letting gcc get rid of the redundant ones; let the > > initialization valu

Re: [PATCH] Add VIS intrinsics header for sparc.

On Sat, 24 Sep 2011, David Miller wrote: > From: Hans-Peter Nilsson > Date: Sat, 24 Sep 2011 18:37:33 -0400 (EDT) > > > BTW, don't forget to clobber GSR at call insns! > > This I explicitly want to avoid and is an explicit design decision. Aha, now I get it; that&#x

Re: [PATCH] Add VIS intrinsics header for sparc.

On Sun, 25 Sep 2011, David Miller wrote: > For some reason I can't take ownership of your PR and mark it > closed, otherwise I'd do so as well. Done, thanks. The most common cause is not using your gcc.gnu.org account in bugzilla, needed to get those superpowers. (For future reference, marking t

Re: [CRIS] Hookize OUTPUT_ADDR_CONST_EXTRA

> Date: Sun, 2 Oct 2011 21:36:50 +0400 > From: Anatoly Sokolov > OK to install? > > * config/cris/m32c.c (cris_output_addr_const_extra): Make static. > (TARGET_OUTPUT_ADDR_CONST_EXTRA): Define. > * config/cris/cris.h (OUTPUT_ADDR_CONST_EXTR

Re: [PATCH] Minor fixups to the sparc bmask/bshuffle patterns.

On Mon, 3 Oct 2011, David Miller wrote: > * config/sparc/sparc.md (bmask_vis): Split into explicit 'di' > and 'si' patterns which describe the GSR changes explicitly in the > RTL using zero_extract. > (bshuffle_vis): Put the GSR use inside of the unspec. (Heh, so I guess US

Re: Vector shuffling

On Fri, 30 Sep 2011, Artem Shinkarov wrote: > gcc/doc > * extend.texi: Adjust. Pretty please document the new pattern names in doc/md.texi as well. Thanks in advance. brgds, H-P

Re: Fix pr50607 bconstp-3.c failure

On Thu, 6 Oct 2011, Artem Shinkarov wrote: > Successfully regtested on x86-unknown-linux-gnu. Committed to the > mainline with the revision 179588. > > ChangeLog: > 2011-10-06 Artjoms Sinkarovs > * c-tree.h (c_expr_t): New typedef for struct c_expr. > (C_EXPR_APPEND): New macro.

Re: Fix pr50607 bconstp-3.c failure

On Thu, 6 Oct 2011, Artem Shinkarov wrote: > On Thu, Oct 6, 2011 at 3:27 AM, Hans-Peter Nilsson wrote: > > Write that changelog entry as: > > > >        PR middle-end/50607 > >        * c-tree.h (c_expr_t): New typedef for struct c_expr. > >        (C_EXPR_A

Re: [CRIS] Hookize PREFERRED_RELOAD_CLASS

> Date: Sun, 9 Oct 2011 17:47:22 +0400 > From: Anatoly Sokolov > OK to install? > > * config/cris/cris.c (cris_preferred_reload_class): New function. > (TARGET_PREFERRED_RELOAD_CLASS): Define. > * config/cris/cris.h (OUTPUT_ADDR_CONST_EXTRA): Remove.

Re: [patch] Don't try to reload match_operator

On Mon, 19 Sep 2011, Ulrich Weigand wrote: > Richard Earnshaw wrote: > > On 19/09/11 15:14, Ulrich Weigand wrote: > > > So it seems to me that for match_operator operands, the > > > goal_alternative_win flag should always be true ... > > > > > > Can you find out why this isn't true in your case? >

Re: [PATCH, testsuite]: Close and unlink test file before exit

On Tue, 11 Oct 2011, Uros Bizjak wrote: > Hello! > > Remove another orphan file from the testsuite directory. > > 2011-10-11 Uros Bizjak > > * lib/target-supports.exp (check_effective_target_fd_truncate): > Close and unlink test file before exit. (can't quote attachment...) Or s

Re: [arm-embedded] Tune loop unrolling for cortex-m

On Wed, 21 Sep 2011, Joey Ye wrote: > Committed in ARM/embedded-4_6-branch. > > 2011-09-21 Jiangning Liu > > Tune loop unrolling for cortex-m > * config/arm/arm-cores.def (cortex-m0): Change to new tune > cortex_v6m. > (cortex-m1): Likewise. > * config/arm/arm-prot

Re: [PATCH, i386] RTM support

On Tue, 13 Mar 2012, Uros Bizjak wrote: > A small no-op change - there is no need for a constraint in an expand > pattern. Plus some formatting. If you want to remove it, then remove it, don't just empty it. ;) > 2012-03-13 Uros Bizjak > > * config/i386/i386.md (xbegin): Remove constrai

Committed: fix PR target/53120, constraint modifier "+" on operand tied by matching-constraint, "0".

The subject line points out the bug. This combination of constraints is invalid, and almost no other target has it (and none together with strict_low_part): you can't reload a read/write operand (one with a "+" modifier, such as a strict_low_part destination) for which there is an input-only match

CFG review needed for fix of "PowerPC shrink-wrap support 3 of 3"

> From: Bernd Schmidt > Date: Mon, 14 Nov 2011 10:51:56 +0100 > On 11/11/11 20:13, Hans-Peter Nilsson wrote: > > AFAICT, your patch has got sufficiently testing now (on three > > targets to boot) to be considered safe to check in. Or is > > something amiss? > >

Re: CFG review needed for fix of "PowerPC shrink-wrap support 3 of 3"

> From: Richard Henderson > Date: Mon, 14 Nov 2011 18:48:03 +0100 > On 11/14/2011 04:10 AM, Hans-Peter Nilsson wrote: > > Looks like all we need is a positive review of > > <http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01409.html> and a > > ChangeLog entry

Re: CFG review needed for fix of "PowerPC shrink-wrap support 3 of 3"

> From: Alan Modra > Date: Mon, 14 Nov 2011 22:56:48 +0100 > I haven't really looked into what Bernd's fix does. I know this one > fixes what I broke.. Hm... Oh well, I'm trusting RTH and Bernd that it fixed a real issue. Thanks for looking (and a belated thanks to RTH for the review). brgds,

Re: [CRIS] Hookize FUNCTION_VALUE_REGNO_P

> From: Anatoly Sokolov > Date: Wed, 9 Nov 2011 22:42:53 +0100 > Regression tested on cris-axis-elf. > > OK to install? > > * config/cris/cris.c (cris_function_value_regno_p): Make static. > (TARGET_FUNCTION_VALUE_REGNO_P): Define. > * config/cris/cris.h (FUNCTION_VA

Massive EH regressions after "[patch, ia64, libgcc] Patch to fix libunwind build on IA64"

> From: Steve Ellcey > Date: Fri, 18 Nov 2011 18:24:22 +0100 > This patch fixes the IA64 bootstrap when building libunwind. When using > -fexceptions libunwind will have a reference to __gcc_personality_v0 and > the bootstrap fails, using -fno-exceptions fixes this. This problem > started with

Re: Massive EH regressions after "[patch, ia64, libgcc] Patch to fix libunwind build on IA64"

> From: Hans-Peter Nilsson > Date: Sun, 20 Nov 2011 09:27:06 +0100 > the patch somehow affects all of libgcc, verified by > diffing the build-logs around this commit. Correction: it affects those parts that are not fp-bit.c, so "just" the unwinder and the target-specifi

Re: Massive EH regressions after "[patch, ia64, libgcc] Patch to fix libunwind build on IA64"

;m going to commit the following as obvious after verifying that it fixes the regressions and doesn't cause any. libgcc: 2011-11-20 Hans-Peter Nilsson * shared-object.mk (c_flags-$o): Save c_flags. ($(b

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

Spotted while looking into (and yes, I fixed the ChangeLog typo before commit) and also mentioned at . Emulating TLS has nothing to do with exception-handling, nor is there something that mig

CFT: Re: libgcc: why emutls.c in LIB2ADDEH instead of LIB2ADD?

> From: Paolo Bonzini > Sender: Paolo Bonzini > Date: Mon, 21 Nov 2011 10:20:39 +0100 > H-P, can you try bootstrapping your patch on cygwin and/or mingw too > before applying it? Sorry, I don't have that. Dave? brgds, H-P

Re: CFT: Re: libgcc: why emutls.c in LIB2ADDEH instead of LIB2ADD?

> From: Iain Sandoe > Date: Mon, 21 Nov 2011 11:04:18 +0100 > On 21 Nov 2011, at 09:34, Hans-Peter Nilsson wrote: > > >> From: Paolo Bonzini > >> Sender: Paolo Bonzini > >> Date: Mon, 21 Nov 2011 10:20:39 +0100 > > > >> H-P, can you t

Re: Adjust omp-low test for alignment

On Sat, 26 Nov 2011, Richard Henderson wrote: > The m68k-linux failure for the various omp atomic tests > is due to the fact that BIGGEST_ALIGNMENT is 16 bits on > that platform. I think it's pretty reasonable to assume > that if something is aligned to BIGGEST_ALIGNEMENT, then > it can be conside

Re: Adjust omp-low test for alignment

On Tue, 29 Nov 2011, Richard Henderson wrote: > On 11/28/2011 08:49 PM, Hans-Peter Nilsson wrote: > > On Sat, 26 Nov 2011, Richard Henderson wrote: > >> The m68k-linux failure for the various omp atomic tests > >> is due to the fact that BIGGEST_ALIGNMENT is 16 bits on &

Re: Adjust omp-low test for alignment

On Tue, 29 Nov 2011, Hans-Peter Nilsson wrote: > On Tue, 29 Nov 2011, Richard Henderson wrote: > > On 11/28/2011 08:49 PM, Hans-Peter Nilsson wrote: > > > On Sat, 26 Nov 2011, Richard Henderson wrote: > > >> The m68k-linux failure for the various omp atomic tests

<    12   13   14   15   16   17   18   19   20   21   >