Re: Fwd: [Bug debug/53754] [4.8 Regression][lto] ICE in lhd_decl_printable_name, at langhooks.c:222 (with -g)

On Thu, 28 Jun 2012, Cary Coutant wrote: > [resending in plain text. Sorry, gmail defaulted to HTML.] > > Ping. I'm not looking for commit approval yet, just advice on how > thorough we need to be to support -g and LTO together. > > (What's the right way to send a patch to fix a PR? I'm not even

Commit: LM32: Fix typo in

Hi Sebastien, Hi Steven I am applying the patch below as obvious fix for a typo in lm32.c. Cheers Nick gcc/ChangeLog 2012-06-29 Nick Clifton * config/lm32/lm32.c (lm32_compute_frame_size): Fix typo. Index: lm32.c ==

RFA: MEP: Fix use of delete_insn.

Hi DJ, The delete_insn() function no longer returns the insn after the one that has been deleted, so gcc/config/mep/mep.c:mep_reorg_regmove() no longer compiles. The patch below is a simple fix for the problem, but I was not sure whether it would be better to use next_nonnote_nondebug_i

Re: [PATCH] Add MULT_HIGHPART_EXPR

On Thu, Jun 28, 2012 at 6:44 PM, H.J. Lu wrote: > On Thu, Jun 28, 2012 at 8:57 AM, Richard Henderson wrote: >> On 2012-06-28 07:05, Jakub Jelinek wrote: >>> Unfortunately the addition of the builtin_mul_widen_* hooks on i?86 seems >>> to pessimize the generated code for gcc.dg/vect/pr51581-3.c >>

RFA: MN10300: Replace REG_SAVE_BYTES macro with calls to mn10300_get_live_callee_saved_regs

Hi Jeff, Hi Alex, I recently encountered a problem with the REG_SAVE_BYTES macro in the mn10300 backend. When compiling some code in -fPID mode it was producing a different result to the mask computed by mn10300_get_live_callee_saved_regs. The problem turned out to be that the macro wa

Re: [PATCH] Add MULT_HIGHPART_EXPR

On Fri, Jun 29, 2012 at 11:00:14AM +0200, Richard Guenther wrote: > Indeed - the lack of cross-sub-128bit-word operations makes it very much > expensive for some vectorizations. Initially we added the patterns for > vectorization of the hi/lo and interleave stuff because we didn't want > regressio

[Patch ARM] Backport fix for off-by-one vrev error.

Hi, This backports the off-by-one fix for vrev to the ARM port as mentioned in my post earlier here. Since I've heard no objections from the release branch maintainers or anyone else , and given I've not seen any fallout from the auto-testers I'm backporting this to the FSF 4.7 branch. http://g

[Patch ARM] Backport fix for gnu_unique_object to 4.7 branch

Hi, Taking Richi's statement here http://gcc.gnu.org/ml/gcc-patches/2012-06/msg01399.html as an approval - I've backported the comment character fix for gnu_unique_object on ARM to the FSF 4.7 branch. regards, Ramana 2012-06-29 Ramana Radhakrishnan * configure: Regenerate. Ba

Re: [onlinedocs]: No more automatic rebuilt?

Next problem: libiberty. This looks reasonably well in dvi and pdf. OK? That should really be the last error. Andreas. * copying-lib.texi (Library Copying): Don't use @heading inside @enumerate. diff --git a/libiberty/copying-lib.texi b/libiberty/copying-lib.texi index 79e1038.

Re: [onlinedocs]: No more automatic rebuilt?

On Fri, 29 Jun 2012, Andreas Schwab wrote: > Next problem: libiberty. This looks reasonably well in dvi and pdf. > OK? That should really be the last error. > > Andreas. > > * copying-lib.texi (Library Copying): Don't use @heading inside > @enumerate. Looks reasonable. Thanks, And

Re: [ARM Patch 1/n] PR53447: optimizations of 64bit ALU operation with constant

Hi So the following is updated patch. Tested on qemu with arm/thumb modes without regression. thanks Carrot 2012-06-29 Wei Guozhi PR target/53447 * gcc.target/arm/pr53447-1.c: New testcase. * gcc.target/arm/pr53447-2.c: New testcase. 2012-06-29 Wei Guozhi

Re: [PATCH][RFC, Reload]. Reload bug?

Tejas Belagod wrote: > Therefore strict_memory_address_addr_space_P () thinks that > (mem:OI (reg sp)) is a valid target address and lets it pass as > a subreg and does not narrow the subreg into a narrower memref. > find_reloads_toplev () should have infact given > strict_memory_address_addr_spa

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

> From: Hans-Peter Nilsson > Date: Fri, 22 Jun 2012 04:24:01 +0200 > > From: Hans-Peter Nilsson > > Date: Fri, 15 Jun 2012 04:07:23 +0200 > > A ping. And another ping, now CCing ARM maintainers, . > > Y is 28 for introduction of the quo

[PATCH] Testcase for fixed PR52589

Tested on x86_64-unknown-linux-gnu, applied. Richard. 2012-06-29 Richard Guenther PR tree-optimization/52589 * gcc.dg/tree-ssa/vrp70.c: New testcase. Index: testsuite/gcc.dg/tree-ssa/vrp70.c === --- testsuite/gc

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

> From: "Joseph S. Myers" > Date: Fri, 22 Jun 2012 13:09:42 +0200 > On Fri, 22 Jun 2012, Hans-Peter Nilsson wrote: > > > > > > Fix configure test for "stack protector support in target C > > > > > library". > > > > > * configure.ac (test_prefix, test_exec_prefix): Move setting > >

Re: [graphite] RFC: Add ISL variants of remaining PPL things

On 06/26/2012 12:21 PM, Michael Matz wrote: Hi, so, to make progress on the graphite front we want to get rid of the ppl dependency. We start from Tobis move-to-isl-and-isl-scheduler branch at github, merged current trunk into that (see also Richis mails about cloog/isl configury), and add ISL

Re: [RFC, ARM] later split of symbol_refs

On 06/27/2012 07:55 PM, Ramana Radhakrishnan wrote: > I must admit that I had been suggesting to Zhenqiang about turning > this off by tightening the movsi_insn predicates rather than adding a > split, but given that it appears to produce enough benefit in this > case I don't have any reasons to

Re: [RFC, ARM] later split of symbol_refs

On 06/27/2012 07:53 PM, Richard Earnshaw wrote: Please update the ChangeLog entry (it's not appropriate to mention Sourcery G++) and add a comment as Steven has suggested. Otherwise OK. Updated. Ok to commit now? -- Best regards, Dmitry 2009-05-29 Julian Brown gcc/ * config/arm/arm

Re: [PATCH][RFC, Reload]. Reload bug?

Ulrich Weigand wrote: Tejas Belagod wrote: Therefore strict_memory_address_addr_space_P () thinks that (mem:OI (reg sp)) is a valid target address and lets it pass as a subreg and does not narrow the subreg into a narrower memref. find_reloads_toplev () should have infact given strict_memory_a

[PATCH] Adjust gcc.dg/tree-ssa/pr37508.c for PR37541

Tested on x86_64-unknown-linux-gnu, applied. Richard. 2012-06-29 Richard Guenther PR tree-optimization/37541 * gcc.dg/tree-ssa/pr37508.c: Adjust and un-XFAIL. Index: gcc/testsuite/gcc.dg/tree-ssa/pr37508.c === -

Re: [ARM Patch 1/n] PR53447: optimizations of 64bit ALU operation with constant

On 29 June 2012 12:23, Carrot Wei wrote: > Hi > > So the following is updated patch. Tested on qemu with arm/thumb modes Assuming this testing was with and without neon ? Because the patterns changed are different whether you use Neon or not. > without regression. Can you add some tests for all

[trunk, 4.7, PR 38474] Avoid unnecessary vdef walks in compute_known_type_jump_func

Hi, PR 38474 testcase revealed what we can do a lot of entirely unnecessary vdef walking only to throw away the result later because of a much cheaper check. This patch fixes that. The patch applies to both trunk and the 4.7 branch, I have bootstrapped and tested it on both on an x86_64-linux wi

[4.6, PR 38474] Avoid unnecessary vdef walks in compute_known_type_jump_func

Hi, PR 38474 testcase revealed what we can do a lot of entirely unnecessary vdef walking only to throw away the result later because of a much cheaper check. I have posted a patch for trunk and 4.7 just a moment ago. this is a version for 4.6, doing essentially the same thing. I am about to boo

[PATCH] Testcase for PR47061

Tested on x86_64-unknown-linux-gnu, applied. Richard. 2012-06-29 Richard Guenther PR tree-optimization/47061 * gcc.dg/tree-ssa/vrp71.c: New testcase. Index: gcc/testsuite/gcc.dg/tree-ssa/vrp71.c === --- gcc/test

Re: Ping: Reorganized documentation for warnings -- attempt 2

Try CC:ing Gerald as the most likely maintainer to review this. -- Joseph S. Myers jos...@codesourcery.com

Re: [RFC, ARM] later split of symbol_refs

> +;; Split symbol_refs at the later stage (after cprop), instead of generating > +;; movt/movw pair directly at expand. Otherwise corresponding high_sum > +;; and lo_sum would be merged back into memory load at cprop. However, I would rewrite part of your comment as > +;; movt/movw is preferab

Re: [patch][RFA] Move the C front end to gcc/c/

On Fri, 29 Jun 2012, Steven Bosscher wrote: > Alright then. Here is the patch that, I think, is ready for the trunk. > > Bootstrapped&tested on x86_64-unknown-linux-gnu (-m64/-m32) with > c,c++,objc,obj-c++,fortran enabled. > Compared the pre- and post-patch results of "make install". > OK for tr

Re: [RFC, ARM] later split of symbol_refs

On 29 June 2012 14:48, Dmitry Melnik wrote: > > On 06/27/2012 07:55 PM, Ramana Radhakrishnan wrote: > >> I must admit that I had been suggesting to Zhenqiang about turning >> this off by tightening the movsi_insn predicates rather than adding a >> split, but given that it appears to produce enough

[patch] Remove CASE_USE_BIT_TESTS target macro

Hello, This patch removes the CASE_USE_BIT_TESTS target macro. The default value of the macro is defined in stmt.c, where the only user of the macro is also. No target re-defines the macro. (I wonder if the test is necessary at all. AFAICT all targets support shifts in word_mode. The macro was or

Re: [patch] Remove CASE_USE_BIT_TESTS target macro

On Fri, Jun 29, 2012 at 4:35 PM, Steven Bosscher wrote: > Hello, > > This patch removes the CASE_USE_BIT_TESTS target macro. The default > value of the macro is defined in stmt.c, where the only user of the > macro is also. No target re-defines the macro. > > (I wonder if the test is necessary at

Re: [patch] Remove CASE_USE_BIT_TESTS target macro

On Fri, Jun 29, 2012 at 4:42 PM, Richard Guenther wrote: > On Fri, Jun 29, 2012 at 4:35 PM, Steven Bosscher > wrote: >> Hello, >> >> This patch removes the CASE_USE_BIT_TESTS target macro. ... > Ok.  (poison CASE_USE_BIT_TESTS?) Right, I've done that in the patch I commited. Ciao! Steven

Re: [testsuite] gcc.dg/vect/vect-50.c: combine two scans

On 06/28/2012 08:02 PM, Mike Stump wrote: > On Jun 28, 2012, at 10:26 AM, Janis Johnson wrote: >> No, there is no way to combine "target" and "xfail", > > Ah... Grrr I hate non-composability. Given that, I think the original > patch is fine, subject of course to the wants and wishes of vec

Use builtin_widen_mult_even/odd in expand_vector_divmod

We use it everywhere else, but it got forgotten here. Saves two shuffles on Altivec. Although with all of this duplication it makes me wonder if we shouldn't just give up on the idea of auto-generating MULT_HIGHPART from other operations (particularly given the extra type frobbing involved).

[lra] patch to fix ia64 bootstrap

The following patch fixes IA64 bootstrap after the last merge. The patch was sucessfully bootstrapped on ia64 and x86/x86-64. Committed as rev. 189079. 2012-06-29 Vladimir Makarov * lra-constraints.c (get_op_class): Don't process SUBREG. (check_and_process_move): Simplify the

Re: Fwd: [Bug debug/53754] [4.8 Regression][lto] ICE in lhd_decl_printable_name, at langhooks.c:222 (with -g)

> > (What's the right way to send a patch to fix a PR? I'm not even sure > > whether you were cc'ed on my response.) > > The right way to send a patch to fix a PR is to send it to gcc-patches ;) Well, yeah, but in this case I was just proposing a patch for discussion, and using the bugzilla mechan

Re: [testsuite] gcc.dg/vect/vect-50.c: combine two scans

On Jun 29, 2012, at 8:45 AM, Janis Johnson wrote: > Something like: > > target { selector } xfail { selector } > > where "target" is the first argument, "xfail" is the third. Forcing (requiring) an ordering would be bad. > Selectors can be lists of target triplets, but those can be within > br

Re: PATCH: PR target/53539: Different __WCHAR_TYPE__/wchar_t for gcc -m32 on Linux/i386 and Linux/x86-64

On Thu, May 31, 2012 at 7:10 AM, H.J. Lu wrote: > On Thu, May 31, 2012 at 6:50 AM, Jakub Jelinek wrote: >> On Thu, May 31, 2012 at 06:35:19AM -0700, H.J. Lu wrote: >>> This patch makes __WCHAR_TYPE__/wchar_t the same for gcc -m32 on >>> Linux/i386 and Linux/x86-64.  OK for trunk? >> >> That looks

Re: [wwwdocs] Update coding conventions for C++

Resend, as I replied to a message that didn't have the usual suspects on the cc line. On 6/27/12, Lawrence Crowl wrote: > ..., does anyone object to removing the permission to use C++ > streams? Having heard no objection, I removed the permission. The following patch is the current state of the

Re: Use builtin_widen_mult_even/odd in expand_vector_divmod

On Fri, Jun 29, 2012 at 9:50 AM, Richard Henderson wrote: > We use it everywhere else, but it got forgotten here.  Saves two shuffles on > Altivec. > > Although with all of this duplication it makes me wonder if we shouldn't just > give up > on the idea of auto-generating MULT_HIGHPART from othe

[PATCH] Fix up mksysinfo.sh

Hi! The recent mksysinfo.sh change for glibc 2.16 bits/resource.h unfortunately doesn't work, because the sed invocation two lines earlier removes the {}s this sed command is looking for. The following makes gcc 4.7 as well as trunk build in Fedora rawhide. --- libgo/mksysinfo.sh 2012-06-29 14:2

Re: RFA: MEP: Fix use of delete_insn.

We have this at the top of the loop, so I don't think it matters: next = NEXT_INSN (insn); if (GET_CODE (insn) != INSN) continue; However, I think an insn will be skipped if we use NEXT. Perhaps we want PREV? Or the loop might need to be altered to account for t

Re: Use builtin_widen_mult_even/odd in expand_vector_divmod

On Fri, Jun 29, 2012 at 11:33:39AM -0700, H.J. Lu wrote: > On Fri, Jun 29, 2012 at 9:50 AM, Richard Henderson wrote: > > We use it everywhere else, but it got forgotten here.  Saves two shuffles > > on Altivec. > > > > Although with all of this duplication it makes me wonder if we shouldn't > >

[patch] Do not include typeclass.h in expr.c

Not even sure why it's included in the first place - it's not used. Will commit as obvious in a couple of days, unless someone objects. Ciao! Steven * expr.c: Do not include typeclass.h. Index: expr.c === --- expr.c (

Re: [testsuite] don't use lto plugin if it doesn't work

On Jun 28, 2012, at 3:19 PM, Alexandre Oliva wrote: > On Jun 28, 2012, Mike Stump wrote: >> The next would be because it would be a speed hit to re-check at >> runtime the qualities of the linker and do something different. > > But then, our testsuite *does* re-check at runtime, but without my >

Re: Use builtin_widen_mult_even/odd in expand_vector_divmod

On 06/29/2012 12:43 PM, Jakub Jelinek wrote: > 2012-06-29 Jakub Jelinek > > * tree-vect-generic.c (expand_vector_divmod): For even/odd > widening multiply, put even always as first argument to > VEC_PERM_EXPR. Ok. r~

Re: Fwd: [Bug debug/53754] [4.8 Regression][lto] ICE in lhd_decl_printable_name, at langhooks.c:222 (with -g)

>> That's sensible anyways - you avoid useless work.  So the patch is ok. > > OK, I'll submit this patch, but leave the PR open and follow up with > something to fix the underlying problem as you suggest. Here's the patch I'm committing (as soon as bootstrap and testing completes)... -cary 2012

Re: PATCH: PR target/53539: Different __WCHAR_TYPE__/wchar_t for gcc -m32 on Linux/i386 and Linux/x86-64

On 06/29/2012 11:10 AM, H.J. Lu wrote: >> 2012-05-31 H.J. Lu >> >>PR target/53539 >>* config/i386/gnu-user64.h (WCHAR_TYPE): Use "int" only for >>TARGET_LP64. >> >> diff --git a/gcc/config/i386/gnu-user64.h b/gcc/config/i386/gnu-user64.h >> index 0e66d26..2941332 100644 >

[Obvious] Add previously approved comment

Enclosed is a patch that fixes indention and adds an already-approved comment that I missed when porting the previous patch. I have checked it in under the obvious rule. Sterling obvious.patch Description: Binary data

Fix oversight during try-finally lowering

It pertains to the source location assigned to the finally switch: the comment in lower_try_finally_switch reads: /* The location of the finally is either the last stmt in the finally block or the location of the TRY_FINALLY itself. */ but the code reads: finally_loc = gimple_seq_la

Re: Remove obsolete Solaris 8 support

Hi! On Mon, 12 Mar 2012 18:44:24 +0100, Rainer Orth wrote: > 2012-03-11 Rainer Orth > gcc: > * config.gcc (enable_obsolete): Remove *-*-solaris2.8*. > (*-*-solaris2.[0-8], *-*-solaris2.[0-8].*): Mark unsupported. > (i[34567]86-*-solaris2*, x86_64-*-solaris2.1[0-9]*):