Re: [PATCH] Fix PR53733

On Mon, 30 Jul 2012, William J. Schmidt wrote: > This fixes the de-canonicalization of commutative GIMPLE operations in > the vectorizer that occurs when processing reductions. A loop_vec_info > is flagged for cleanup when a de-canonicalization has occurred in that > loop, and the cleanup is done

Commit: XStormy16: Add __clrsbhi2() to libgcc

Hi Guys, I am checking in the patch below to add a __clrsbhi2 function to libgcc for the XStormy16 port. This fixes several gcc testsuite failures that need this particular function. Cheers Nick libgcc/ChangeLog 2012-07-31 Nick Clifton * config/stormy16/lib2funcs.c (__clrsbh

Re: [PATCH 0/2] Convert s390 to atomic optabs, v2

On Mon, 30 Jul 2012, Richard Henderson wrote: > The atomic_load/storedi_1 patterns are fixed to use LM, STM. > > I've had a go at generating better code in the HQImode CAS > loop for aligned memory, but I don't know that I'd call it > the most efficient thing ever. Some of this is due to > defi

Re: [Patch, Fortran] Update c_funloc/c_f_procpointer for TS29113

On 26/07/2012 16:01, Tobias Burnus wrote: > TS29113 allows also non interoperable procedures with > c_funloc/c_f_procpointer; hence, this patch allows them with -std=f2008ts: > > "The function C F PROCPOINTER from the intrinsic module ISO C BINDING > has the restriction in ISO/IEC 1539-1:2010 that

Re: [PATCH] Fix the LOOP_BRANCH prediction

On Tue, Jul 31, 2012 at 5:17 AM, Dehao Chen wrote: > Hi, > > This patch fixed the problem when a LOOP_EXIT edge for the inner loop > happened to target at the LOOP_LATCH of the outer loop. As the outer > loop is processed first, the LOOP_BRANCH heuristic is honored > (first_match), thus the inner

[PATCH]: Fix -Wmissing-format-attribute warnings

Hello! This patch removes all -Wmissing-format-attribute warnings on alphaev68-pc-linux-gnu native build. gcc/ChangeLog: 2012-07-31 Uros Bizjak * collect2.c (collect_execute): Add format strint to fatal_error call. * dwarf2asm.c (dw2_asm_output_vms_delta): Add format string t

Re: [patch] PR pch/53880

On Tue, Jul 31, 2012 at 7:04 AM, Laurynas Biveinis wrote: > Steven - > >> Bootstrapped&tested on powerpc64-unknown-linux-gnu. OK for trunk? > > Thanks for working on this. It looks good, couple of minor comments: Thanks for the review. I've made the adjustments you suggested and committed the pat

[Patch, Fortran] PR 42418: PROCEDURE: Rejects interface which is both specific and generic procedure

Hi all, here is a patch which does several things: 1) It fixes the original problem in the PR (cf. comments 0 and 6) by adding code which checks if a generic interface has a specific procedure of the same name (see resolve_procedure_interface). 2) It fixes other problems found along the way (cf.

[C++ PATCH] Introduce context struct for cxx_eval_constant_expression

The attached patch adds a context parameter to cxx_eval_constant_expression and its subprograms. This way, we do not have to thread all context parameters manually. This will simplify the introduction of additional location information, as suggested by Jason in

Commit: FRV: Fix typo in definition of QUAD macro

Hi Guys, I am checking in the patch below as an obvious fix for the definition of the QUAD macro in the FRV backend. Cheers Nick gcc/ChangeLog 2012-07-31 Nick Clifton * config/frv/frv.c (QUAD): Fix typo. Index: gcc/config/frv/frv.c =

[patch] Dump slim RTL to assembly file if the final dump is slim

Hello, For me, the slim RTL dumps are much easier to read than the default lisp-like representation. I use the -dAP option frequently, to see where an assembly instruction came from. This patch scratches an itch: The insns dumped to the assembly file are always dumped as lisp-like, ignoring the "s

Re: [PATCH] Fix the LOOP_BRANCH prediction

Are you suggesting a patch like this: Index: gcc/predict.c === --- gcc/predict.c (revision 189835) +++ gcc/predict.c (working copy) @@ -1319,6 +1319,7 @@ tree loop_bound_var = NULL; tree loop_iv_base = NULL;

Re: [patch] Dump slim RTL to assembly file if the final dump is slim

On Tue, Jul 31, 2012 at 12:13 PM, Steven Bosscher wrote: > Hello, > > For me, the slim RTL dumps are much easier to read than the default > lisp-like representation. I use the -dAP option frequently, to see > where an assembly instruction came from. This patch scratches an itch: > The insns dumped

Commit: FRV: Add support for -fstack-usage

Hi Guys, I am applying the patch below to add support for the -fstack-usage option to the FRV backend. Cheers Nick gcc/ChangeLog 2012-07-31 Nick Clifton * config/frv/frv.c (frv_expand_prologue): Report stack usage. gcc/testsuite/ChangeLog 2012-07-31 Nick Clifton *

Re: [PATCH] Fix the LOOP_BRANCH prediction

> Are you suggesting a patch like this: > > Index: gcc/predict.c > === > --- gcc/predict.c (revision 189835) > +++ gcc/predict.c (working copy) > @@ -1319,6 +1319,7 @@ >tree loop_bound_var = NULL; >tree loop_iv

Re: [PATCH] Fix the LOOP_BRANCH prediction

On Tue, Jul 31, 2012 at 12:20 PM, Dehao Chen wrote: > Are you suggesting a patch like this: > > Index: gcc/predict.c > === > --- gcc/predict.c (revision 189835) > +++ gcc/predict.c (working copy) > @@ -1319,6 +1319,7 @@ >

Re: [PATCH] Fix the LOOP_BRANCH prediction

> On Tue, Jul 31, 2012 at 12:20 PM, Dehao Chen wrote: > > Are you suggesting a patch like this: > > > > Index: gcc/predict.c > > === > > --- gcc/predict.c (revision 189835) > > +++ gcc/predict.c (working copy) > > @@ -1319

Re: [PATCH] Fix the LOOP_BRANCH prediction

On Tue, Jul 31, 2012 at 12:38 PM, Jan Hubicka wrote: >> On Tue, Jul 31, 2012 at 12:20 PM, Dehao Chen wrote: >> > Are you suggesting a patch like this: >> > >> > Index: gcc/predict.c >> > === >> > --- gcc/predict.c (revision 189

Re: [PATCH] Fix the LOOP_BRANCH prediction

On Tue, Jul 31, 2012 at 12:43 PM, Richard Guenther wrote: > On Tue, Jul 31, 2012 at 12:38 PM, Jan Hubicka wrote: >>> On Tue, Jul 31, 2012 at 12:20 PM, Dehao Chen wrote: >>> > Are you suggesting a patch like this: >>> > >>> > Index: gcc/predict.c >>> >

Re: [PATCH] Fix the LOOP_BRANCH prediction

> > > > Yeah, this may also work. The reason it is not done is that > > 1) it seemed expensive to force CFG changes just to compute profile decade > > ago > > 2) cfgcleanup afterwards will anyway remove the headers again. > > So I originally hoped to do the right thing without normalization

RFA: M32C: Add __clrsbhi2 to libgcc

Hi DJ, The patch below adds an implementation of the __clrsbhi2 function to libgcc for the M32C port. Implementing this function resolves several gcc testsuite failures that rely upon the function being present. Ok to apply ? Cheers Nick libgcc/ChangeLog 2012-07-31 Nick Clifton

[PATCH] PR 53975

Hello, This PR is about wrong speculation of an insn that doesn't support storing NaT bits done by the selective scheduler (more details in the PR audit trail). The reason for this is the wrong one-liner patch committed last year, the fix is to revert that patch and to clarify the comment bef

[C++ Patch] Mini int -> bool clean up

Hi, noticed yesterday, booted & tested x86_64-linux. Ok? Thanks, Paolo. // 2012-07-31 Paolo Carlini * pt.c (check_default_tmpl_args): Change is_primary and is_partial parameters to bool type, adjust. (push_template_decl_real): Tidy. * pars

Re: [PATCH]: Fix -Wmissing-format-attribute warnings

On Tue, Jul 31, 2012 at 11:20 AM, Uros Bizjak wrote: > This patch removes all -Wmissing-format-attribute warnings on > alphaev68-pc-linux-gnu native build. Ouch, I didn't notice that some of these strings may be a format string with %< and %>, etc and should not be printed with "%s". Is there a

[PATCH] Intrinsics for ADCX

Hi guys, Here is a third part of patch, refactored by Kirill. This one adds _addcarryx_u[32|64] intrinsics. Is it ok? Changelog entry: 2012-07-31 Michael Zolotukhin * common/config/i386/i386-common.c (OPTION_MASK_ISA_ADX_SET): New. (OPTION_MASK_ISA_ADX_UNSET): Likewise.

[RS6000] Fix PR54131, ICE building 416.gamess

This cures the 'Y' constraint of being overly restrictive with lo_sum offsets. I've added a comment that explains why it is wrong to limit the range of lo_sum offsets. Bootstrapped and regressiotn tested powerpc-linux. OK to apply? PR target/54131 * config/rs6000/rs6000.c (mem_o

[PATCH][RFC][6/n] into-SSA TLC

This makes rewriting decls into SSA form via SSA updating fully transparent and no longer requiring mark_sym_for_renaming calls. Much like the operand scanner marks virtual SSA form for renaming automagically if it adds new virtual operands the following patch makes sure it does so for real operan

Re: [PATCH] Fix the LOOP_BRANCH prediction

On Tue, Jul 31, 2012 at 6:56 PM, Jan Hubicka wrote: >> > >> > Yeah, this may also work. The reason it is not done is that >> > 1) it seemed expensive to force CFG changes just to compute profile >> > decade ago >> > 2) cfgcleanup afterwards will anyway remove the headers again. >> > So I o

Re: PR middle-end/53321: [4.8 Regression] LTO bootstrap failed with bootstrap-profiled

> Hi, > > 2012-07-06 H.J. Lu > > PR middle-end/53321 > PR middle-end/53865 > * Makefile.in (tree-profile.o): Depend on ipa-inline.h. > > * ipa.c (symtab_remove_unreachable_nodes): Restore > cgraph_propagate_frequency call when something was changed. > > *

Re: [PATCH] Fix the LOOP_BRANCH prediction

> On Tue, Jul 31, 2012 at 6:56 PM, Jan Hubicka wrote: > >> > > >> > Yeah, this may also work. The reason it is not done is that > >> > 1) it seemed expensive to force CFG changes just to compute profile > >> > decade ago > >> > 2) cfgcleanup afterwards will anyway remove the headers again. > >

Commit: XStormy16: Add support for -fstack-usage

Hi Guys, I am checking in the patch below to add support for reporting stack usage by the XStormy16 backend. Cheers Nick gcc/ChangeLog Index: gcc/ChangeLog 2012-07-31 Nick Clifton * config/stormy16/stormy16.c (xstormy16_expand_prologue): Add support for reporting stack

Re: [PATCH] Intrinsics for ADCX

On Tue, Jul 31, 2012 at 1:33 PM, Michael Zolotukhin wrote: > Hi guys, > Here is a third part of patch, refactored by Kirill. This one adds > _addcarryx_u[32|64] intrinsics. > > Is it ok? > > Changelog entry: > 2012-07-31 Michael Zolotukhin > > * common/config/i386/i386-common.c (OPTION_M

[Patch, Fortran, committed] PR 54134: [OOP] ICE overriding derived type bound function with allocatable character as result

Hi all, I have just committed as obvious a small patch for the PR in the subject line: http://gcc.gnu.org/viewcvs?view=revision&revision=190010 Cheers, Janus

Re: [PATCH][5/n] into-SSA TLC

On Mon, 30 Jul 2012, Michael Matz wrote: > Hi, > > On Mon, 30 Jul 2012, Richard Guenther wrote: > > > > > This makes into-SSA no longer rely on variable annotations and instead > > uses on-the-side information local to into/update-SSA. Lookups can > > probably be avoided in some places if we p

Re: [C++ Patch] Mini int -> bool clean up

OK. Jason

Re: [patch, fortran] Fix PR 54033, problems with -I, with test cases

On 07/29/2012 11:24 AM, Thomas Koenig wrote: here is an updated patch for PR 54033, this time with test cases. Thanks to Janis for pointing me in the right direction with these. Regression-tested. OK for trunk? Ok. Thanks for the patch - and to Janis for the first review. Can you eliminate the

Re: [PATCH] Fix the LOOP_BRANCH prediction

Thanks, Honza, Then shall I check in the following patch to trunk (after testing)? Dehao Index: gcc/testsuite/gcc.dg/predict-7.c === --- gcc/testsuite/gcc.dg/predict-7.c(revision 0) +++ gcc/testsuite/gcc.dg/predict-7.c(revis

Re: [RS6000] Fix PR54131, ICE building 416.gamess

On Tue, Jul 31, 2012 at 7:51 AM, Alan Modra wrote: > This cures the 'Y' constraint of being overly restrictive with lo_sum > offsets. I've added a comment that explains why it is wrong to limit > the range of lo_sum offsets. Bootstrapped and regressiotn tested > powerpc-linux. OK to apply? > >

Re: [PATCH] Fix the LOOP_BRANCH prediction

> Thanks, Honza, > > Then shall I check in the following patch to trunk (after testing)? Yes, this is OK (with a changelog). Thanks! Honza

Re: [PATCH]: Fix -Wmissing-format-attribute warnings

On Tue, 31 Jul 2012, Uros Bizjak wrote: > On Tue, Jul 31, 2012 at 11:20 AM, Uros Bizjak wrote: > > > This patch removes all -Wmissing-format-attribute warnings on > > alphaev68-pc-linux-gnu native build. > > Ouch, I didn't notice that some of these strings may be a format > string with %< and %

Re: [PATCH 0/2] Convert s390 to atomic optabs, v2

On 07/31/2012 05:09 AM, Richard Guenther wrote: On Thus, the bad news is that it's hard for the middle-end to recover alignment of a memory access that is represented as a builtin function call that takes addresses as parameters (which also makes them address-taken and thus possibly aliased). Did

Re: [Patch, Fortran] PR 42418: PROCEDURE: Rejects interface which is both specific and generic procedure

On 07/31/2012 11:50 AM, Janus Weil wrote: The patch was regtested successfully on x86_64-unknown-linux-gnu. Ok for trunk? The patch looks okay. I assume, the patch doesn't help to get PR 54035 fixed,does it? (That PR is about TBP binding to the generic instead of the specific name.) Tobias

Re: [Patch, fortran] Remove gfc_array_ref::offset field

On 07/27/2012 06:06 PM, Mikael Morin wrote: The offset field is never set; this patch removes it. Regression tested on x86_64-unknown-linux-gnu. OK for trunk? OK. Thanks for the nice clean-up patch. Tobias

Re: [PATCH 0/2] Convert s390 to atomic optabs, v2

On 2012-07-31 02:09, Richard Guenther wrote: > What do we expect __builtin_compare_exchange to do for > unaligned inputs? At the moment we expect it to SIGBUS, as a rule. We'd *like* to defer to the library routine for unaligned, but we don't do that yet. Too bad about not being able to query ad

Re: [PATCH] Intrinsics for ADCX

On 2012-07-31 04:33, Michael Zolotukhin wrote: > Here is a third part of patch, refactored by Kirill. This one adds > _addcarryx_u[32|64] intrinsics. Frankly I don't understand the point of these instructions being added to the ISA at all. I would have understood an add-with-carry that did *not*

Re: TPF: disable discriminators

On 2012-07-30 21:07, DJ Delorie wrote: > + > +/* GAS supports it, but the debuggers don't, so avoid it. */ > +#define SUPPORTS_DISCRIMINATOR 0 Then you shouldn't be fiddling this, but rather dwarf_strict. See e.g. darwin and vxworks ports. r~

[patch] sched-vis fixes

Hello, The pretty-printer in sched-vis.c hasn't been updated for all new RTX codes that have been added over time. The attached patch resolves all things that needed fixing for pretty -dAP -fdump-rtl-final-slim prints on powerpc64 (and probably everywhere else). It also changes things such that ne

Re: [Patch, Fortran] PR 42418: PROCEDURE: Rejects interface which is both specific and generic procedure

>> The patch was regtested successfully on x86_64-unknown-linux-gnu. Ok for >> trunk? > > > The patch looks okay. Thanks! > I assume, the patch doesn't help to get PR 54035 > fixed,does it? (That PR is about TBP binding to the generic instead of the > specific name.) Not directly. Although - si

[gimplefe] Patch for recognizing function declarations

Hi Diego, The following patch recognizes function declarations. I am now trying to create a gimple sequence of all the statements within the function body. The chagelog is as follows: 2012-07-31 Sandeep Soni * parser.c (gl_token_starts_decl): Modify. Matches function decls. (g

Re: [PATCH 0/2] Convert s390 to atomic optabs, v2

Richard Henderson wrote: > I've had a go at generating better code in the HQImode CAS > loop for aligned memory, but I don't know that I'd call it > the most efficient thing ever. Thanks for having a look at this! > (3) Support for IC, and ICM via the insv pattern is lacking. > I've adde

Re: [Patch, Fortran] PR 42418: PROCEDURE: Rejects interface which is both specific and generic procedure

>>> The patch was regtested successfully on x86_64-unknown-linux-gnu. Ok for >>> trunk? >> >> >> The patch looks okay. > > Thanks! Committed as r190017. Cheers, Janus >>> 2012-07-31 Janus Weil >>> >>> PR fortran/42418 >>> * decl.c (match_procedure_interface): Move some chec

Re: RFA: M32C: Add __clrsbhi2 to libgcc

Ok.

Re: [PATCH 0/2] Convert s390 to atomic optabs, v2

On 2012-07-31 11:17, Ulrich Weigand wrote: > This doesn't look correct: > + /* Emit a strict_low_part pattern if possible. */ > + if (bitpos == 0 && GET_MODE_BITSIZE (smode) == bitsize) > > With bitpos == 0 we need to insert into the *high* part, not > the low part on a big-endian platf

[PATCH, rs6000] Vectorizer heuristic

Now that the vectorizer cost model is set up to facilitate per-target heuristics, I'm revisiting the "density" heuristic I submitted previously. This allows the vec_permute and vec_promote_demote costs to be set to their natural values, but inhibits vectorization in cases like sphinx3 where vector

Re: [PATCH, rs6000] Vectorizer heuristic

On Tue, Jul 31, 2012 at 3:54 PM, William J. Schmidt wrote: > Now that the vectorizer cost model is set up to facilitate per-target > heuristics, I'm revisiting the "density" heuristic I submitted > previously. This allows the vec_permute and vec_promote_demote costs to > be set to their natural v

Re: TPF: disable discriminators

Ah, the original complaint was for a gcc branch which doesn't have your strict-dwarf/discriminator patch. How's this? Index: gcc/config/s390/s390.c === --- gcc/config/s390/s390.c (revision 190017) +++ gcc/config/s390/s390.c

Re: Commit: XStormy16: Add __clrsbhi2() to libgcc

Nick Clifton schrieb: Hi Guys, I am checking in the patch below to add a __clrsbhi2 function to libgcc for the XStormy16 port. This fixes several gcc testsuite failures that need this particular function. Cheers Nick Hi, just out of curiosity: Is there a special reason to add a storm

Re: [PATCH, 4.7] Enable the libstdc++ prettyprinters test suite

cc'ed the libstdc++ list. Ping? -- Michael On 25/07/12 12:12, Michael Hope wrote: The libstdc++ prettyprinters test suite isn't called out in Makefile.am. Backport Andreas's patch from mainline so that a sequential test run gives the same results as a parallel test. Tested with no regressi

Re: TPF: disable discriminators

On 2012-07-31 14:09, DJ Delorie wrote: > +#ifdef TARGET_TPF > + /* Don't emit DWARF3/4 unless specifically selected. The TPF > + debuggers do not yet support DWARF 3/4. */ > + if (!global_options_set.x_dwarf_strict) > +dwarf_strict = 1; > + if (!global_options_set.x_dwarf_version) > +

Re: TPF: disable discriminators

> TARGET_TPF is always defined. Just use a C if. > Otherwise ok. Thanks, checked in as attached. What about older branches? 4.7 needs this patch, 4.6 needs my original patch. 2012-07-31 DJ Delorie * config/s390/s390.c (s390_option_override): Disable DWARF 3/4 extensions fo

Re: TPF: disable discriminators

On 2012-07-31 15:21, DJ Delorie wrote: > What about older branches? 4.7 needs this patch, 4.6 needs my > original patch. I don't see that 4.6 requires a different patch. Otherwise ok to backport. r~

PING [PATCH] Fix PR libstdc++/54036, problem negating DFP NaNs

I'd like to ping the following libstdc++ DFP patch that fixes PR54036: http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00959.html Peter

Re: TPF: disable discriminators

On 2012-07-31 15:51, DJ Delorie wrote: >> I don't see that 4.6 requires a different patch. > > 4.6 is missing this: > > 2011-04-01 Richard Henderson > > PR 48400 > * dwarf2out.c (dwarf2out_source_line): Disable discriminators > in strict mode before dwarf4. Re-order tests t

Re: TPF: disable discriminators

> I don't see that 4.6 requires a different patch. 4.6 is missing this: 2011-04-01 Richard Henderson PR 48400 * dwarf2out.c (dwarf2out_source_line): Disable discriminators in strict mode before dwarf4. Re-order tests to early out before switching sections. S

Re: PR middle-end/53321: [4.8 Regression] LTO bootstrap failed with bootstrap-profiled

On Tue, Jul 31, 2012 at 5:39 AM, Jan Hubicka wrote: >> Hi, >> >> 2012-07-06 H.J. Lu >> >> PR middle-end/53321 >> PR middle-end/53865 >> * Makefile.in (tree-profile.o): Depend on ipa-inline.h. >> >> * ipa.c (symtab_remove_unreachable_nodes): Restore >> cgraph_propag

Re: TPF: disable discriminators

Ah, ok.

[RFC] Fix pr34548 -- unnecessary alignment from alloca

I've bootstrapped this on both ppc64 and x86_64. I'll leave some time for comment, but I can't immediately see how this could go wrong anywhere. r~ * function.h (struct rtl_data): Add max_dynamic_stack_alignment. * cfgexpand.c (gimple_expand_cfg): Initialise it. * explow

[PATCH, MIPS] Add 34Kn cpu

This patch makes GCC know about -march=34kn. MIPS asked us to add support for this processor to our local source base a couple of years ago; it's basically a 34Kc without the DSP ASE. OK for mainline? I have posted the corresponding assembler patch here: http://sourceware.org/ml/binutils/2012