[Patch, gcc, testsuite] Adjust optimization levels for some cases.

Hello, These four cases check the amount of the desired instructions. At O2 level, some factors like loop unroll will increase the amount of them. This patch is proposing to adjust the optimization level to O1 (the minimal requirement) to avoid such impact. In this way, the cases are more robust.

Re: [PATCH, i386, PR50766] Fix incorrect mem/reg operands order

On Thu, Oct 20, 2011 at 6:39 AM, Kirill Yukhin wrote: > Updated patch is attached. Test fails wihout and passing with the fix. > > ChangeLog entry: > 2011-10-20  Kirill Yukhin   > >        PR target/50766 >        * config/i386/i386.md (bmi_bextr_): Update register/ >        memory operand order.

Re: RFA: Improve tree-ssa-sink block selection

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/18/11 01:44, Paolo Bonzini wrote: > On 10/18/2011 07:10 AM, Jeff Law wrote: >> --- 467,475 if (gimple_code (use) != GIMPLE_PHI) { sinkbb = >> gimple_bb (use); ! sinkbb = select_best_block (frombb, >> gimple_bb (use), stmt); >> >> !

Re: [PATCH, i386, PR50766] Fix incorrect mem/reg operands order

Thank you guys, Updated patch is attached. Test fails wihout and passing with the fix. ChangeLog entry: 2011-10-20 Kirill Yukhin PR target/50766 * config/i386/i386.md (bmi_bextr_): Update register/ memory operand order. (bmi2_bzhi_3): Ditto. (bmi2_pdep_3

[PATCH] Use can_create_pseudo_p() in the sparc backend.

Committed to trunk. gcc/ * config/sparc/sparc.c (sparc_expand_move): Use can_create_pseudo_p. (sparc_emit_set_const32): Likewise. (sparc_emit_set_const64_longway): Likewise. (sparc_emit_set_const64): Likewise. (sparc_legitimize_pic_address): Likewi

Re: [v3] tr2: bool_set, dynamic_bitset, ratio

On 10/19/2011 06:48 PM, Benjamin Kosnik wrote: Hi Edward! I have reviewed and selectively merged your development branch, libstdcxx-tr2-ideas-branch, into trunk. As ISO C++ is now looking at new library efforts for TR2 (and N2965 has already been checked in to trunk) I thought it well-timed. Pl

Re: [C++ Patch] PR 48630 (PR 31423)

Hi, I think I made a suggestion in my previous message: -- decouple this particular diagnostic from 'incomplete type' error. Because it has nothing to do with incomplete type error. -- once the diagnostic is decoupled, you could "grep" for all the places where cxx_incomplete_type_e

Re: [C++ Patch] PR 48630 (PR 31423)

On Wed, Oct 19, 2011 at 7:47 PM, Gabriel Dos Reis wrote: > On Wed, Oct 19, 2011 at 7:09 PM, Paolo Carlini > wrote: >> On 10/20/2011 02:00 AM, Gabriel Dos Reis wrote: >>> >>> I believe the effect of your new patch is that if will >>> always emit the suggest "did you forget "()"?" for member funct

Re: [C++ Patch] PR 48630 (PR 31423)

On Wed, Oct 19, 2011 at 7:09 PM, Paolo Carlini wrote: > On 10/20/2011 02:00 AM, Gabriel Dos Reis wrote: >> >> I believe the effect of your new patch is that if will >> always emit the suggest "did you forget "()"?" for member functions, >> even in the case where the current suggestion is correct.

[cxx-mem-model] compare_exchange implementation II

OK, here's the updated patch. I also made the changes to the C++ include files to use __atomic_compare_exchange in the header file. I think I covered everything that was mentioned previously... Bootstraps and no new regressions on x86_64-unknown-linux-gnu. Andrew * optabs.h (direct_o

Re: [SH] PR 50694 - SH2A little endian does not actually work

On Thu, 2011-10-20 at 08:40 +0900, Kaz Kojima wrote: > The patch makes 4 logically separable changes into one. It'd > be better to split it to 4 independent patches. > The changes except cmpgeusi_t look essentially OK to me. But > please test them as usual for both endian. Sure, no problem. Wi

Re: [C++ Patch] PR 48630 (PR 31423)

On 10/20/2011 02:00 AM, Gabriel Dos Reis wrote: I believe the effect of your new patch is that if will always emit the suggest "did you forget "()"?" for member functions, even in the case where the current suggestion is correct. Using the type context would prevent that regression. If you could

Avoid -mno-accumulate-outgoing-args in tests on Windows target

The -mno-accumulate-outgoing-args option does not work with the stack probing used on Windows targets, giving a warning and so causing tests using that option to fail. This patch makes three tests not use that option on affected targets, like sse-10.c (see

Re: [C++ Patch] PR 48630 (PR 31423)

On Wed, Oct 19, 2011 at 6:36 PM, Paolo Carlini wrote: > On 10/20/2011 12:32 AM, Jason Merrill wrote: >> >> Surely we should only make this change for function members. > > Thanks Gaby and Jason. So, what about the below? I believe the effect of your new patch is that if will always emit the sugge

Re: new patches using -fopt-info (issue5294043)

OK. I'll keep it in mind. We probably won't include all the messages in one shot. But we do plan to add all of them finally because we believe they are helpful for tracking the performance. -Rong On Wed, Oct 19, 2011 at 4:33 PM, Andi Kleen wrote: > x...@google.com (Rong Xu) writes: > >> After so

Re: [SH] PR 50694 - SH2A little endian does not actually work

Oleg Endo wrote: > the attached patch addresses PR 50694 and also does some cleanups in > sh.md. > > I haven't run the testsuite with this one since it's basically just text > replacements, except for the changed cmpgeusi_t insn. However, CSiBE > didn't show any code size changes with the change

Re: [C++ Patch] PR 48630 (PR 31423)

On 10/20/2011 12:32 AM, Jason Merrill wrote: Surely we should only make this change for function members. Thanks Gaby and Jason. So, what about the below? Tested x86_64-linux. Paolo. /cp 2011-10-19 Paolo Carlini PR c++/31423 PR c++/48630 * type

Re: new patches using -fopt-info (issue5294043)

x...@google.com (Rong Xu) writes: > After some off-line discussion, we decided to use a more general approach > to control the printing of optimization messages/warnings. We will > introduce a new option -fopt-info: > * fopt-info=0 or fno-opt-info: no message will be emitted. > * fopt-info or fo

new patches using -fopt-info (issue5294043)

After some off-line discussion, we decided to use a more general approach to control the printing of optimization messages/warnings. We will introduce a new option -fopt-info: * fopt-info=0 or fno-opt-info: no message will be emitted. * fopt-info or fopt-info=1: emit important warnings and optimi

Avoid gcc.dg/tree-prof/val-prof-7.c dependence on

The testcase gcc.dg/tree-prof/val-prof-7.c includes to get a declaration of bzero. This causes it to fail on targets where bzero (a legacy function removed in the latest version of POSIX) is not declared in that header; declaring it explicitly in the testcase is more reliable. This patch changes

[v3] tr2: bool_set, dynamic_bitset, ratio

jamin 20111019-1.patch.bz2 Description: application/bzip

Re: [C++ Patch] PR 48630 (PR 31423)

Surely we should only make this change for function members. Jason

Re: [C++ Patch] PR 13657

OK. Jason

[SH] PR 50694 - SH2A little endian does not actually work

Hello, the attached patch addresses PR 50694 and also does some cleanups in sh.md. I haven't run the testsuite with this one since it's basically just text replacements, except for the changed cmpgeusi_t insn. However, CSiBE didn't show any code size changes with the changed insn. As far as I c

[C++ Patch] PR 13657

Hi, this tries to implement what Jason suggested in the audit trail: do not refer to an argument and use instead 'cannot convert...", like, eg, in cvt.c. Tested x86_64-linux. Thanks, Paolo. // /cp 2011-10-19 Paolo Carlini PR c++/13657 * class.c (insta

Re: Intrinsics for N2965: Type traits and base classes

> Please post a ChangeLog entry with a patch. Someone added one for > you: > > 2011-10-17 Michael Spertus > > * gcc/c-family/c-common.c (c_common_reswords): Add __bases, > __direct_bases. > * gcc/c-family/c-common.h: Add RID_BASES and RID_DIRECT_BASES. > > but it is in the

C++ PATCH for c++/50793 (incomplete value-initialization with default argument)

When bot_manip regenerates TARGET_EXPR/AGGR_INIT_EXPR, it needs to preserve the AGGR_INIT_ZERO_FIRST flag. Tested x86_64-pc-linux-gnu, applying to trunk and release branches. commit f56f4ec3e3620b4ae4e07986a17338d607952c65 Author: Jason Merrill Date: Wed Oct 19 17:21:34 2011 -0400 PR c+

Re: [PATCH] Don't assume that constants can clobber vtbl

On 11/10/2011, at 4:05 AM, Martin Jambor wrote: > > Just before this, there is the following test (guarded by > flag_strict_aliasing per explicit Richi's request). > > if (flag_strict_aliasing > && !POINTER_TYPE_P (TREE_TYPE (lhs))) > return false; > > Why is it n

Re: [trans-mem] Add gl_wt TM method.

Committed with the changes below. On Wed, 2011-10-19 at 12:17 -0700, Richard Henderson wrote: > > Add support for TM-method-specific begin code. > > > > * libitm_i.h (GTM::gtm_restart_reason): Re-arrange and clean up > > declarations. > > * dispatch.h (

Re: [patch] Fix PR tree-optimization/49960 ,Fix self data dependence

gcc-patches-ow...@gcc.gnu.org wrote on 17/10/2011 09:03:59 AM: > From: Richard Guenther > To: Razya Ladelsky/Haifa/IBM@IBMIL > Cc: gcc-patches@gcc.gnu.org, Sebastian Pop > Date: 17/10/2011 09:04 AM > Subject: Re: [patch] Fix PR tree-optimization/49960 ,Fix self data dependence > Sent by: gcc-pa

Re: [Patch, Fortran] PR 47023: C_Sizeof: Rejects valid code

>> If I saw it correctly, one still needs to fix the vendor-extension SIZEOF >> for procedure pointers (it currently returns one byte!) > > Right. Actually I don't quite understand where that 1 byte comes from. I have just committed the patch from comment #23 of the PR (which has been approved by

Re: [PATCH] Account for devirtualization opportunities in inliner

On 28/09/2011, at 4:56 PM, Maxim Kuvyrkov wrote: > Jan, > > The following patch starts a series of patches which improve devirtualization > optimizations in GCC. > > This patch builds on ipa-cp.c and ipa-prop.c infrastructure for analyzing > parameters and jump functions and adds basic estimat

Re: [google] AddressSanitizer for gcc, first attempt. (issue 5272048)

what kind of failures? David On Wed, Oct 19, 2011 at 2:04 PM, wrote: > On 2011/10/19 20:38:35, kcc wrote: >> >> Added code to avoid bitfields. > > Is there anything I should know about splitting basic blocks in the > presence of EH? > Currently, asan fails on 483.xalancbmk, 453.povray and 450.s

Re: [C++ Patch] PR 48630 (PR 31423)

On Wed, Oct 19, 2011 at 4:34 PM, Paolo Carlini wrote: > Hi, > > in these two twin PRs filed by Ian and Gerald, it is pointed out that cases > like: > >   struct C { >     int f() { return 1; } >   }; > >   int f(C&c) { >     return ( 1 == c.f ); >   } > > where the user actually forgot the open-cl

[C++ Patch] PR 48630 (PR 31423)

Hi, in these two twin PRs filed by Ian and Gerald, it is pointed out that cases like: struct C { int f() { return 1; } }; int f(C&c) { return ( 1 == c.f ); } where the user actually forgot the open-closed round braces are much more likely than cases where an ampersand

[PATCH, m68k] Fix floating-point comparisons with zero

Hi, It appears that m68k floating-point comparisons may have been subtly broken since 2007 when the following patch was applied: http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01570.html The bug shows with our internal 4.6-based branch, but appears to be latent on mainline (generated code is per

regcprop.c bug fix

So while tracking down a hairy address reload for an output reload bug, copyprop_hardreg_forward_1 was faulting because it was trying to extract move patterns that didn't work out, and when it came back to the code, it then tries to access recog_data, but the problem is, the exploration of other

Re: [PATCH, testsuite]: Fix PR 50796, FAIL: gcc.dg/plugin/plugindir[1234].c

Uros Bizjak writes: > Index: gcc.dg/plugin/plugindir1.c > === > --- gcc.dg/plugin/plugindir1.c(revision 180206) > +++ gcc.dg/plugin/plugindir1.c(working copy) > @@ -1,4 +1,4 @@ > /* { dg-do compile } */ > /* { dg-op

[PATCH, testsuite]: Fix PR 50796, FAIL: gcc.dg/plugin/plugindir[1234].c

Hello! Update dg-prune-output due to inacessible -> inaccessible change. 2011-10-19 Uros Bizjak PR testsuite/50796 * gcc.dg/plugin/plugindir?.c Update dg-prune-output. Tested on x86_64-pc-linux-gnu, committed to mainline SVN. Uros. Index: gcc.dg/plugin/plugindir1.c =

Re: [PATCH] Further i?86 vector permutation fixes

On Wed, Oct 19, 2011 at 01:36:25PM -0700, Richard Henderson wrote: > Although I think a good followup would be to fix > this so that we don't need a copy to another register. > That could be done by adding a d.one_operand field, and > using that test instead of explicit equality everywhere. Perhap

Re: [PATCH] Add an intermediate coverage format for gcov

On Oct 19, 2011, at 12:12 PM, Sharad Singhai wrote: > Sorry, I misunderstood your comment. I see that you are asking for > unmangled function names whereas the current patch supports only > mangled names. I can print unmangled names under another option. Would > that work? I defer to the person t

Re: [4.6,patch,libgfortran/io] Fix build issue with _commit [PR5016]

Pre-remark: Jakub (4.6.2 RM) had no objects - and thus I have committed it to the branch. Steve Kargl wrote: I don't have an objection, just a question. Does this issue appear on trunk? Yes and no. The MinGW build issue this patch fixes was unique to the branch. However, the actual issue - t

Re: C++ PATCH for c++/49172 (allow constexpr reference variables)

On 06/22/2011 12:19 AM, Jason Merrill wrote: We decided at the Madrid meeting to allow constexpr reference variables, and this patch adds that support to GCC. The cp_parser_initializer_clause hunk also fixes 50787, a bug with direct binding of references in 4.6, so I'm applying that one there.

Re: [PATCH] Further i?86 vector permutation fixes

On 10/19/2011 12:25 PM, Jakub Jelinek wrote: > 2011-10-19 Jakub Jelinek > > * config/i386/i386.c (expand_vec_perm_vpshufb2_vpermq_even_odd): Use > d->op1 instead of d->op0 for the second vpshufb. > (expand_vec_perm_even_odd_1): For V8SImode fix vpshufd immediates. > (ix8

Re: Fix g++.dg/compat/struct-layout-1_generate.c options for Windows targets

On Oct 19, 2011, at 11:58 AM, "Joseph S. Myers" wrote: > g++.dg/compat/struct-layout-1_generate.c generates a dg-options line > using -mno-mmx -Wno-abi for i?86-*-* x86_64-*-* - and one using > -fno-common, which takes precedence, for alpha*-dec-osf* hppa*-*-hpux* > powerpc*-*-darwin* *-*-mingw32*

Re: [PATCH 2/6] Generate virtual locations for tokens

This is probably going to take some back and forth as I don't have any SPU target at hand to debug, so I have filed http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50801 to track this issue, along with a candidate fix. Could you please test it and reply to the bug with your results? Thank you for you

Re: [PATCH, testsuite]: Require non_strict_align effective target for gcc.dg/ipa/ipa-sra-[26].c

From: Uros Bizjak Date: Wed, 19 Oct 2011 21:50:14 +0200 > Hello! > > These two tests require non_strict_aligned effective target, since IPA > fails in tree_non_mode_aligned_mem_p () for "cow" and "calf" > candidates for STRICT_ALIGNMENT targets. Mode alignment requires 32 > bytes, while data is

[PATCH, testsuite]: Require non_strict_align effective target for gcc.dg/ipa/ipa-sra-[26].c

Hello! These two tests require non_strict_aligned effective target, since IPA fails in tree_non_mode_aligned_mem_p () for "cow" and "calf" candidates for STRICT_ALIGNMENT targets. Mode alignment requires 32 bytes, while data is aligned to 8 bytes. 2011-10-19 Uros Bizjak * gcc.dg/ipa/i

Re: [Patch ARM] Fix PR target/50106

On 10/19/2011 3:27 PM, Ramana Radhakrishnan wrote: Index: gcc/config/arm/arm.c - live_regs_mask |= extra_mask<< (size / UNITS_PER_WORD); + live_regs_mask |= extra_mask<< ((size + 3) / UNITS_PER_WORD); IIUC, wouldn't ((size + UNITS_PER_WORD - 1) / UNITS_PER_WORD) be clearer? -Nathan

[Patch ARM] Fix PR target/50106

Hi, This fixes PR target/50106 which was missing handling return register size from 1-3 for Thumb1. Fixed thusly. Final testing on-going with arm-linux-gnueabi with thumb1. Ok to backport to 4.6 branch given it is branch freeze time ? I'll be able to commit this to the branch latest by tomorrow A

[PATCH] Further i?86 vector permutation fixes

Hi! This patch adds two new permutations to the vshuf* tests (VEC_PACK_TRUNC style) and fixes problems related to them. The first two fix issues with AVX2, the rest of the patch deals with the problem that if the shuffle mask suggests two operands, testing whether there is a permutation supported

Re: [cxx-mem-model] compare_exchange implementation

On 10/19/2011 11:31 AM, Andrew MacLeod wrote: > If, which is more likely as I think about it, thats not the case and > the fences can look like they do in the second example (closer to the > CAS than the copies) , then the CAS can take care of both fences, > which would be much more preferable and

Re: [trans-mem] Add gl_wt TM method.

> Add support for TM-method-specific begin code. > > * libitm_i.h (GTM::gtm_restart_reason): Re-arrange and clean up > declarations. > * dispatch.h (GTM::abi_dispatch::begin_or_restart): New. > * method-serial.cc: Implement begin_or_restart(). > * beginend.cc

Re: [google] AddressSanitizer for gcc, first attempt. (issue 5272048)

On Wed, Oct 19, 2011 at 12:02 PM, wrote: > Minimized the crash to this: > > struct Foo { >  unsigned bf1:1; >  unsigned bf2:1; >  unsigned bf3:1; > }; > > void foo (struct Foo *ob) { >  ob->bf2 = 1; > } > > > > D.2731_4 = &ob_1(D)->bf2; > __asan_base_addr.2 = (long unsigned int) D.2731_4; > D.273

Re: [PATCH] Add an intermediate coverage format for gcov

Sorry, I misunderstood your comment. I see that you are asking for unmangled function names whereas the current patch supports only mangled names. I can print unmangled names under another option. Would that work? Thanks, Sharad On Wed, Oct 19, 2011 at 12:06 PM, Sharad Singhai wrote: > Since the

Re: [PATCH] Add an intermediate coverage format for gcov

Since the updated patch already uses unmangled function names, is it good to commit then? Sharad On Wed, Oct 19, 2011 at 1:48 AM, Jan Hubicka wrote: >> On Oct 18, 2011, at 4:19 PM, Sharad Singhai wrote: >> > Okay, I liked the idea of self-descriptive tags. I have updated the >> > patch based on

Fix g++.dg/compat/struct-layout-1_generate.c options for Windows targets

g++.dg/compat/struct-layout-1_generate.c generates a dg-options line using -mno-mmx -Wno-abi for i?86-*-* x86_64-*-* - and one using -fno-common, which takes precedence, for alpha*-dec-osf* hppa*-*-hpux* powerpc*-*-darwin* *-*-mingw32* *-*-cygwin*. But at least i686-mingw32 still needs the -Wno-ab

Re: [4.6,patch,libgfortran/io] Fix build issue with _commit [PR5016]

On Wed, Oct 19, 2011 at 07:11:02PM +0200, Tobias Burnus wrote: > I intent to commit this patch - created mostly by Janne - soon to > gcc-4_6-branch; it should solve a build issue. > > The patch was build and regtested on x86-64-linux and build and tested > on MinGW and Cygwin by Kai. > > It is

Re: [cxx-mem-model] compare_exchange implementation

On 10/19/2011 01:55 PM, Richard Henderson wrote: On 10/19/2011 09:26 AM, Andrew MacLeod wrote: well, they are explicitly'compare_exchange_strong' and 'compare_exchange_weak' calls... so yes, they have 'hardcoded' one or the other :-) we could alternatively do 2 separate builtins, but I

Re: [PATCH] Handle VEC_PERM_EXPR and WIDEN_LSHIFT_EXPR in expand_debug_expr (PR middle-end/50754)

On 10/19/2011 10:11 AM, Jakub Jelinek wrote: > Hi! > > These two tree codes have been added recently, but not to expand_debug_expr. > The following patch adds them there, bootstrapped/regtested on x86_64-linux > and i686-linux, ok for trunk? > > 2011-10-19 Jakub Jelinek > > PR middle-en

Re: [cxx-mem-model] compare_exchange implementation

On 10/19/2011 09:26 AM, Andrew MacLeod wrote: > well, they are explicitly'compare_exchange_strong' and > 'compare_exchange_weak' calls... so yes, they have 'hardcoded' one or the > other :-) > we could alternatively do 2 separate builtins, but I didn't see the point. > But Im ambivalent.

Re: [VTA, PR49310] O(n+m)-ish emit_notes

On Tue, Oct 18, 2011 at 7:50 AM, Alexandre Oliva wrote: > On Oct 17, 2011, Jakub Jelinek wrote: > >> On Tue, Oct 11, 2011 at 04:19:52PM -0300, Alexandre Oliva wrote: >>> Here's what I've got so far.  Regstrapped on x86_64-linux-gnu and >>> i686-linux-gnu.  Ok to install? > >> I see >> +FAIL: gcc.

[PATCH] Extend vect_recog_bool_pattern also to stores into bool memory (PR tree-optimization/50596)

Hi! Similarly to casts of bool to integer, even stores into bool arrays can be handled similarly. Just we need to ensure tree-vect-data-refs.c doesn't reject vectorization before tree-vect-patterns.c has a chance to optimize it. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk

[PATCH] Handle VEC_PERM_EXPR and WIDEN_LSHIFT_EXPR in expand_debug_expr (PR middle-end/50754)

Hi! These two tree codes have been added recently, but not to expand_debug_expr. The following patch adds them there, bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2011-10-19 Jakub Jelinek PR middle-end/50754 * cfgexpand.c (expand_debug_expr): Handle WID

[4.6,patch,libgfortran/io] Fix build issue with _commit [PR5016]

I intent to commit this patch - created mostly by Janne - soon to gcc-4_6-branch; it should solve a build issue. The patch was build and regtested on x86-64-linux and build and tested on MinGW and Cygwin by Kai. It is a follow up to http://gcc.gnu.org/ml/fortran/2011-10/msg00132.html / http:

Fwd: Re: [cxx-mem-model] compare_exchange implementation

grr, reposting due to thunderbird apparently sneaking some HTML in and it being rejected... sigh. On 10/19/2011 11:34 AM, Richard Henderson wrote: ! weak = expand_expr (CALL_EXPR_ARG (exp, 3), NULL_RTX, ptr_mode, ! EXPAND_NORMAL); ! ! if (weak != const0_rtx&& weak !=

Re: [PATCH PR50572] Tune loop alignment for Atom

On Wed, Oct 19, 2011 at 9:30 AM, Sergey Ostanevich wrote: > 2011-10-18  Sergey Ostanevich > >    * config/i386/i386.c (processor_target_table): Change Atom >    align_loops_max_skip to 15. Please add PR # in ChangeLog. > > diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c > index 2c

PR bootstrap/50709 (bootstrap miscompare)

Hi, the ENABLE_CHECKING code verifying consistency of inliner cache has effect on changing order of querries to the fibheap that consequentely makes entries with same key come in different orders. Fixed by enabling the checking aways. I also added extra check that the keys are conservatively c

Re: [PATCH 2/6] Generate virtual locations for tokens

"Ulrich Weigand" writes: > The problem seems to be that the preprocessor somehow stripped > off the "unsigned" keyword. A reduced test case is: > > #define isinf(__x) > > #define vec_uint4 __vector unsigned int > > vec_uint4 isinf; > > (Using the name of a function-like macro as identifer is may

Re: [PATCH, m68k] Enable building for ColdFire Linux

Julian Brown writes: > Maxim Kuvyrkov > > gcc/ > * config/m68k/t-linux (M68K_MLIB_CPU): Add ColdFire CPUs. Ok. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely d

Re: [PATCH 2/2] Free large chunks in ggc

> Why? For one, such allocations are very rare (you only get them when > a single GC allocation requests > page of memory, like perhaps a string > literal over 4KB or similar or function call with over 1000 arguments etc.). > And if they are unlikely to be reused, not munmapping them means wasting

Re: [translation patch] Bunch of trivial PRs: 48638, 49517, 49704

On Wed, Oct 19, 2011 at 6:11 AM, Paolo Carlini wrote: > Hi, > > a bunch of trivial fixes from Roland. The only one I deem *slightly* more > controversial is "AST" uppercase instead of "ast" in cp/semantics.c, I'm > gonna wait a bit in case Jason has a different opinion... > > Thanks, > Paolo. > W

Re: [cxx-mem-model] compare_exchange implementation

On 10/19/2011 11:16 AM, Jakub Jelinek wrote: On Wed, Oct 19, 2011 at 08:05:26AM -0700, Richard Henderson wrote: In one of Andrew's previous ideas he split _ace into two separate builtins: T __atomic_compare_exchange (T* mem, T oldval, T newval, ...); bool __atomic_compare_exchange_success

Re: [PATCH, i386, PR50766] Fix incorrect mem/reg operands order

On Wed, Oct 19, 2011 at 6:21 AM, Uros Bizjak wrote: > On Wed, Oct 19, 2011 at 3:07 PM, Kirill Yukhin > wrote: > >> Here is (almost obvous) patch, which fixes PR50766. >> >> ChangeLog  entry: >> 2011-10-19  Kirill Yukhin   >> >>        * config/i386/i386.md (bmi_bextr_): Update register/ >>      

Re: [cxx-mem-model] compare_exchange implementation

> ! weak = expand_expr (CALL_EXPR_ARG (exp, 3), NULL_RTX, ptr_mode, > ! EXPAND_NORMAL); > ! > ! if (weak != const0_rtx && weak != const1_rtx) > ! { > ! error ("strong/weak parameter must be 0 or 1 for > %<__atomic_compare_exchange%>"); > ! return NULL_RTX; >

Re: [PATCH, PR50769] Fix ICE in phi_alternatives_equal.

On Wed, Oct 19, 2011 at 10:23 AM, Tom de Vries wrote: > Richard, > > For the example from the PR, -ftree-tail-merge discovers that blocks 6 and 7 > are > equal, removes block 7 and redirects the outgoing edge of it's predecessor > block > 11 to block 6. > > Block 6 contains a phi, which after re

Re: [Patch, Fortran ] PR 50016: Slow Fortran I/O on Windows and flushing/_commit

On Mon, Oct 17, 2011 at 23:52, Janne Blomqvist wrote: > On Mon, Oct 17, 2011 at 19:03, Tobias Burnus wrote: >> Hi Janne, >> >> On 10/17/2011 05:30 PM, Janne Blomqvist wrote: >>> >>> On Mon, Oct 17, 2011 at 15:49, Tobias Burnus  wrote: This patch adds a call to _commit() on _WIN32 for th

Re: [cxx-mem-model] compare_exchange implementation

On Wed, Oct 19, 2011 at 08:05:26AM -0700, Richard Henderson wrote: > In one of Andrew's previous ideas he split _ace into two separate builtins: > > T __atomic_compare_exchange (T* mem, T oldval, T newval, ...); > bool __atomic_compare_exchange_success (T); > > where the input to __ace_succes

[cxx-mem-model] fix some trivial renaming fallout

As was pointed out, __get_builtin_sync_mem was renamed to __get_builtin_atomic which isn't really right, so this patch renames it back. It also includes some formatting fixes which resulted from __sync_mem having a different number of letters than __atomic. Andrew * optabs.c (add_

Re: [cxx-mem-model] compare_exchange implementation

On 10/18/2011 03:07 PM, Jakub Jelinek wrote: > On Tue, Oct 18, 2011 at 06:03:16PM -0400, Andrew MacLeod wrote: >> >> Here's the last of the missing intrinsics. compare_exchange is >> slightly different than the others since it doesn't map directly to >> an rtl pattern. Its format is : >> >> boo

Re: [cxx-mem-model] compare_exchange implementation

On 10/18/2011 06:25 PM, Andrew MacLeod wrote: Its impossible to implement a weak compare and swap unless you return both parameters in one operation. the compare_exchange matches the atomic interface for c++, and if we can't resolve it with a lock free instruction sequence, we have to leave

Re: [Patch,AVR]: PR50447: Tweak addhi3

Denis Chertykov schrieb: >> Georg-Johann Lay schrieb: >>> Denis Chertykov schrieb: >>> What difference in size of avr-libc ? >>> I have no tool for smart size analysis, so here is just a diff: >>> >>> After rebuilding avr-libc with respective compiler version, did >>> respectively: >>> >>> $ f

Re: [PATCH PR50572] Tune loop alignment for Atom

On Wed, Oct 19, 2011 at 6:09 AM, Sergey Ostanevich wrote: > On Wed, Oct 19, 2011 at 4:46 PM, Uros Bizjak wrote: >> On Wed, Oct 19, 2011 at 2:26 PM, Sergey Ostanevich >> wrote: >> You can just change the default in processor_target_table. Uros. >>> >>> Will it be applicable d

Re: [PATCH 2/2] Free large chunks in ggc

On Wed, Oct 19, 2011 at 04:37:45PM +0200, Andi Kleen wrote: > > If the size to free is smaller than the quirk size, then it has the very > > undesirable effect that with using GC only you might run unnecessarily out > > of virtual address space, because it allocates pages in 2MB chunks, but > > if

Re: [trans-mem] Rename/split __transaction into __transaction_atomic and __transaction_relaxed.

On 10/19/2011 03:16 AM, Torvald Riegel wrote: > On Tue, 2011-10-18 at 14:29 -0500, Aldy Hernandez wrote: >>> Several ICEs in the TM tests on C++, but I think they are old. C TM >>> tests work except some missing optimizations (old failures too). >>> c-c++-common/tm/wrap-[12].c fail on C++, but not

Re: [PATCH 2/2] Free large chunks in ggc

> If the size to free is smaller than the quirk size, then it has the very > undesirable effect that with using GC only you might run unnecessarily out > of virtual address space, because it allocates pages in 2MB chunks, but > if they are released in 1MB chunks, those released chunks will never be

Re: [build] Properly test for madvise on Solaris 10 (PR bootstrap/50777)

On 10/19/2011 04:17 PM, Rainer Orth wrote: As described in the PR, Solaris 10 bootstrap is currently broken compiling ggc-page.c in stage2 due to no declaration for madvise(). This happens because g++ defines _XOPEN_SOURCE=600, which hides the declaration, and configure doesn't check for a declar

[build] Properly test for madvise on Solaris 10 (PR bootstrap/50777)

As described in the PR, Solaris 10 bootstrap is currently broken compiling ggc-page.c in stage2 due to no declaration for madvise(). This happens because g++ defines _XOPEN_SOURCE=600, which hides the declaration, and configure doesn't check for a declaration at all. The following patch fixes both

Re: [PATCH 2/6] Generate virtual locations for tokens

Dodji Seketeli wrote: > libcpp/ChangeLog > 2011-10-15 Tom Tromey > Dodji Seketeli > > (cpp_get_token_1): New static function. Split and extended from > cpp_get_token. Use reached_end_of_context and > consume_next_token_from_context. Unify its return point. Move

[PATCH] Fix PR50780, make comparisons able to throw again ...

This fixes PR50780 by validating a condition is gimple before substituting it into a COND_EXPR during forwprop. When looking at this I noticed that comparisons no longer are marked as possibly throwing - because of an old tuplification bug :/ Thus, fixed as well, hopefully without fallout. Boots

Re: [PATCH, i386, PR50766] Fix incorrect mem/reg operands order

On Wed, Oct 19, 2011 at 3:07 PM, Kirill Yukhin wrote: > Here is (almost obvous) patch, which fixes PR50766. > > ChangeLog  entry: > 2011-10-19  Kirill Yukhin   > >        * config/i386/i386.md (bmi_bextr_): Update register/ >        memory operand order. >        (bmi2_bzhi_3): Ditto. >        (b

Re: [translation patch] Bunch of trivial PRs: 48638, 49517, 49704

OK. Jason

[translation patch] Bunch of trivial PRs: 48638, 49517, 49704

Hi, a bunch of trivial fixes from Roland. The only one I deem *slightly* more controversial is "AST" uppercase instead of "ast" in cp/semantics.c, I'm gonna wait a bit in case Jason has a different opinion... Thanks, Paolo. 2011-10-19 Roland Stigge PR tran

Re: [PATCH PR50572] Tune loop alignment for Atom

On Wed, Oct 19, 2011 at 4:46 PM, Uros Bizjak wrote: > On Wed, Oct 19, 2011 at 2:26 PM, Sergey Ostanevich > wrote: > >>> You can just change the default in processor_target_table. >>> >>> Uros. >>> >> >> Will it be applicable during optimizations for size? It will hurt, >> although not much (see

[PATCH, i386, PR50766] Fix incorrect mem/reg operands order

Hi, Here is (almost obvous) patch, which fixes PR50766. ChangeLog entry: 2011-10-19 Kirill Yukhin * config/i386/i386.md (bmi_bextr_): Update register/ memory operand order. (bmi2_bzhi_3): Ditto. (bmi2_pdep_3): Ditto. (bmi2_pext_3): Ditto. Bootstrapped,

Re: [PATCH PR50572] Tune loop alignment for Atom

On Wed, Oct 19, 2011 at 2:26 PM, Sergey Ostanevich wrote: >> You can just change the default in processor_target_table. >> >> Uros. >> > > Will it be applicable during optimizations for size? It will hurt, > although not much (see PR). Looking at the code, I'd say that we don't handle -Os in dif

Re: [C++ Patch] PR 38761, 40872

OK. Jason

Re: [PATCH PR50572] Tune loop alignment for Atom

On Wed, Oct 19, 2011 at 4:14 PM, Uros Bizjak wrote: > > You can just change the default in processor_target_table. > > Uros. > Will it be applicable during optimizations for size? It will hurt, although not much (see PR). New patch is below. Ok for trunk as obvious? Sergos 2011-10-19 Sergey Os

[commit, spu] Fix PR target/50310 (unordered vector compares)

Hello, the pr50310 test cases are failing on SPU with internal compiler errors. It seems that if the back-end provides a vcond pattern, it must support all comparison operations, including unordered ones which are missing in the SPU implementation. Since we don't actually have any specific instru

Re: [PATCH PR50572] Tune loop alignment for Atom

Hello! > 2011-10-19 Sergey Ostanevich > > * gcc/config/i386/i386.c (ix86_option_override_internal): use loop > align by 16 bytes for Atom platform > > diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c > index 2c53423..7a93144 100644 > --- a/gcc/config/i386/i386.c > +++ b/gcc/co

  1   2   >