Re: RFC: [build, ada] Centralize PICFLAG configuration

On 08/22/2011 07:11 PM, Rainer Orth wrote: installed, thanks. Do I need to sync the config and libiberty parts to src manually or does this happen by some sort of magic? I'll take care of that. Paolo

Re: Vector Comparison patch

On Mon, Aug 22, 2011 at 11:11 PM, Artem Shinkarov wrote: > I'll just send you my current version. I'll be a little bit more specific. > > The problem starts when you try to lower the following expression: > > x = a > b; > x1 = vcond > vcond > > Now, you go from the beginning to the end of the bl

[PATCH][1/n] Wading through data-dependence analysis

I'm somewhat stuck with fixing PR50067 because when I fix some bugs I get missed-optimizations because we do rely on those bugs ... Well, I'm still trying to not dump in one mega-patch rewriting it all, so this is the only piece that passed bootstrap and regtest individually (heh ...). It will a

Re: Add __builtin_clrsb, similar to clz/ctz

On Mon, Jun 20, 2011 at 09:38:22PM +0200, Bernd Schmidt wrote: > D'oh. Blackfin has a (clrsb:HI (operand:SI)) instruction, so adding this > showed a problem with some of the existing simplify_const_unop cases: > for ffs/clz/ctz/clrsb/parity/popcount, we should look at the mode of the > operand, rat

Re: Add __builtin_clrsb, similar to clz/ctz

On 08/23/11 11:05, Jakub Jelinek wrote: > On Mon, Jun 20, 2011 at 09:38:22PM +0200, Bernd Schmidt wrote: >> D'oh. Blackfin has a (clrsb:HI (operand:SI)) instruction, so adding this >> showed a problem with some of the existing simplify_const_unop cases: >> for ffs/clz/ctz/clrsb/parity/popcount, we

Re: Vector Comparison patch

On Tue, Aug 23, 2011 at 9:17 AM, Richard Guenther wrote: > On Mon, Aug 22, 2011 at 11:11 PM, Artem Shinkarov > wrote: >> I'll just send you my current version. I'll be a little bit more specific. >> >> The problem starts when you try to lower the following expression: >> >> x = a > b; >> x1 = vco

[Patch, Fortran] PR 31600 - Better diagnosis when redeclaring used-assoc symbol

Before, one got the following error for the attached test case: integer :: bar 1 Error: Symbol 'bar' at (1) already has basic type of INTEGER Which can be a bit puzzling in larger programs. With the patch, one

Re: Add __builtin_clrsb, similar to clz/ctz

On Tue, Aug 23, 2011 at 11:35 AM, Bernd Schmidt wrote: > On 08/23/11 11:05, Jakub Jelinek wrote: >> On Mon, Jun 20, 2011 at 09:38:22PM +0200, Bernd Schmidt wrote: >>> D'oh. Blackfin has a (clrsb:HI (operand:SI)) instruction, so adding this >>> showed a problem with some of the existing simplify_co

Re: Add __builtin_clrsb, similar to clz/ctz

On Tue, Aug 23, 2011 at 11:35:07AM +0200, Bernd Schmidt wrote: > > cse_process_notes_1 > > perhaps could be changed for VOIDmode new_rtx to try to > > simplify_replace_rtx it... > > Is this where the problem came from? Sounds like it's worth a try. In this case, yes. But there are many other pla

Re: Add __builtin_clrsb, similar to clz/ctz

On 08/23/11 11:52, Jakub Jelinek wrote: > On Tue, Aug 23, 2011 at 11:35:07AM +0200, Bernd Schmidt wrote: >>> cse_process_notes_1 >>> perhaps could be changed for VOIDmode new_rtx to try to >>> simplify_replace_rtx it... >> >> Is this where the problem came from? Sounds like it's worth a try. > > I

Re: Add __builtin_clrsb, similar to clz/ctz

Bernd Schmidt writes: > Wasn't Richard S. working on a patch to give constants modes? A whole series more like. Don't hold your breath! Richard

Re: Vector Comparison patch

On Tue, Aug 23, 2011 at 11:44 AM, Artem Shinkarov wrote: > On Tue, Aug 23, 2011 at 9:17 AM, Richard Guenther > wrote: >> On Mon, Aug 22, 2011 at 11:11 PM, Artem Shinkarov >> wrote: >>> I'll just send you my current version. I'll be a little bit more specific. >>> >>> The problem starts when you

PING: allow match_test to be used for attribute rtxes

Ping for: http://gcc.gnu.org/ml/gcc-patches/2011-08/msg01181.html http://gcc.gnu.org/ml/gcc-patches/2011-08/msg01182.html which allow attributes to use (match_test ...) instead of (ne (symbol_ref ..) (const_int 0)). Uros has already approved the x86 part (thanks). Richard

Ping: Rename across basic block boundaries

Ping for the patch at http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01595.html > This patch requires > http://gcc.gnu.org/ml/gcc-patches/2011-05/msg02193.html > as a prerequisite, and supersedes > http://gcc.gnu.org/ml/gcc-patches/2011-05/msg02194.html > > The idea here is to allow regrename t

[PATCH] Fix PR50162

We fail to properly lookup the last argument of a pair of vectorized args when vectorizing a packing function call. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk sofar, to eventually catch fallout. Richard. 2011-08-23 Richard Guenther PR tree-optimization/501

Re: Vector Comparison patch

On Tue, Aug 23, 2011 at 11:08 AM, Richard Guenther wrote: > On Tue, Aug 23, 2011 at 11:44 AM, Artem Shinkarov > wrote: >> On Tue, Aug 23, 2011 at 9:17 AM, Richard Guenther >> wrote: >>> On Mon, Aug 22, 2011 at 11:11 PM, Artem Shinkarov >>> wrote: I'll just send you my current version. I'll

Re: Vector Comparison patch

On Tue, Aug 23, 2011 at 12:24 PM, Artem Shinkarov wrote: > On Tue, Aug 23, 2011 at 11:08 AM, Richard Guenther > wrote: >> On Tue, Aug 23, 2011 at 11:44 AM, Artem Shinkarov >> wrote: >>> On Tue, Aug 23, 2011 at 9:17 AM, Richard Guenther >>> wrote: On Mon, Aug 22, 2011 at 11:11 PM, Artem Shi

[rs6000] Fix creation of invalid CONST_VECTORs

My patches to more "accurately" detect the number of zero elements in a compound initialiser caused pr34856 to trigger on powerpc*-darwin: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34856 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49987 The problem is the same as it was on i386 and spu:

Re: Vector Comparison patch

On Tue, Aug 23, 2011 at 11:33 AM, Richard Guenther wrote: > On Tue, Aug 23, 2011 at 12:24 PM, Artem Shinkarov > wrote: >> On Tue, Aug 23, 2011 at 11:08 AM, Richard Guenther >> wrote: >>> On Tue, Aug 23, 2011 at 11:44 AM, Artem Shinkarov >>> wrote: On Tue, Aug 23, 2011 at 9:17 AM, Richard G

Re: Vector Comparison patch

On Tue, Aug 23, 2011 at 12:45 PM, Artem Shinkarov wrote: > On Tue, Aug 23, 2011 at 11:33 AM, Richard Guenther > wrote: >> On Tue, Aug 23, 2011 at 12:24 PM, Artem Shinkarov >> wrote: >>> On Tue, Aug 23, 2011 at 11:08 AM, Richard Guenther >>> wrote: On Tue, Aug 23, 2011 at 11:44 AM, Artem Sh

Re: [Patch, Fortran] PR 31600 - Better diagnosis when redeclaring used-assoc symbol

On Tuesday 23 August 2011 11:48:27 Tobias Burnus wrote: > Build and regtested on x86-64-linux. > OK for the trunk? > OK. Mikael

Re: Vector Comparison patch

On Tue, Aug 23, 2011 at 11:56 AM, Richard Guenther wrote: > On Tue, Aug 23, 2011 at 12:45 PM, Artem Shinkarov > wrote: >> On Tue, Aug 23, 2011 at 11:33 AM, Richard Guenther >> wrote: >>> On Tue, Aug 23, 2011 at 12:24 PM, Artem Shinkarov >>> wrote: On Tue, Aug 23, 2011 at 11:08 AM, Richard

Re: Vector Comparison patch

Sorry, not rhs = gimplify_build3 (gsi, VEC_COND_EXPR, a, b, {-1}, {0}> but rather rhs = gimplify_build3 (gsi, VEC_COND_EXPR, build2 (GT_EXPR, type, a, b), {-1}, {0}> Artem.

Re: [PATCH, testsuite, i386] AVX2 support for GCC

Sorry, lost body for previous message: Here is last patch to add initial support of AVX2 in GCC. It contains bunch of tests for built-ins. All tests pass under simulator and ignored when AVX2 is out. patch and testsuite/ChangeLog entry are attached, Is it OK Thanks, K On Tue, Aug 23, 2011 at 2

Re: Vector Comparison patch

On Tue, Aug 23, 2011 at 1:11 PM, Artem Shinkarov wrote: > On Tue, Aug 23, 2011 at 11:56 AM, Richard Guenther > wrote: >> On Tue, Aug 23, 2011 at 12:45 PM, Artem Shinkarov >> wrote: >>> I'm confused. >>> There is a set of problems which are tightly connected and you address >>> only one one of th

Re: [PATCH v3, i386] BMI2 support for GCC, mulx, rorx, x part

On Tue, Aug 23, 2011 at 1:07 PM, Kirill Yukhin wrote: > Hi, > I've slightly updated mulx split to avoid ICE. > Updated patch, ChangeLog entry (with Uros's contribution) and > ChangeLog.testsuite entry are attached. > > Bootstrapped and make-checked. > > Tests all pass under simulator (expept one,

Re: [PATCH, testsuite, i386] AVX2 support for GCC

On Tue, Aug 23, 2011 at 1:22 PM, Kirill Yukhin wrote: > Here is last patch to add initial support of AVX2 in GCC. > It contains bunch of tests for built-ins. > All tests pass under simulator and ignored when AVX2 is out. > > patch and testsuite/ChangeLog entry are attached, > > Is it OK Please d

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

Hi, On Mon, 22 Aug 2011, H.J. Lu wrote: > > void __attribute__((constructor)) bla(void) > > { > >  __cpu_indicator_init (); > > } > > > > I don't see any complication.? > > > > Order of constructors. A constructor may call functions > which use __cpu_indicator. That's why I wrote also: > The

Re: [var-tracking] small speed-ups

Hi jakub, On Mon, 22 Aug 2011, Jakub Jelinek wrote: On Mon, Aug 22, 2011 at 01:30:33PM +0300, Dimitrios Apostolou wrote: @@ -1191,7 +1189,7 @@ dv_uid2hash (dvuid uid) static inline hashval_t dv_htab_hash (decl_or_value dv) { - return dv_uid2hash (dv_uid (dv)); + return (hashval_t) (dv_uid

Re: Vector Comparison patch

On Tue, Aug 23, 2011 at 12:23 PM, Richard Guenther wrote: > On Tue, Aug 23, 2011 at 1:11 PM, Artem Shinkarov > wrote: >> On Tue, Aug 23, 2011 at 11:56 AM, Richard Guenther >> wrote: >>> On Tue, Aug 23, 2011 at 12:45 PM, Artem Shinkarov >>> wrote: I'm confused. There is a set of proble

[trans-mem] Add method groups and change TM method lifecycle and selection.

The patch adds method groups for TM methods, which group methods that can run concurrently together. The lifecycle and state management responsibilities of method groups and methods get documented. For now, there is just a method group for all serial methods, more will follow when further TM metho

[PATCH] For FFS/CLZ/CTZ/CLRSB/POPCOUNT/PARITY/BSWAP require operand mode equal to operation mode (or VOIDmode) (PR middle-end/50161)

On Tue, Aug 23, 2011 at 11:57:58AM +0200, Bernd Schmidt wrote: > On 08/23/11 11:52, Jakub Jelinek wrote: > > On Tue, Aug 23, 2011 at 11:35:07AM +0200, Bernd Schmidt wrote: > >>> cse_process_notes_1 > >>> perhaps could be changed for VOIDmode new_rtx to try to > >>> simplify_replace_rtx it... > >> >

[PATCH][2/n] Wading through data-dependence analysis

This patch tries to disentangle the loop vs. non-loop code in data dependence analysis. For loop data-dependences we always want (and need) to compute a distance vector if two references from any loop iteration may alias. Thus we have to disable all offset-based analysis. This is not yet what t

[Patch, Fortran] PR 50163 - ICE with nonconst expr in init expr

The bug is a regression: An error was printed with 4.1.x but since 4.3.x one gets an ICE. [No idea what GCC 4.2 does.] The solution is simply: Returning if there is a MATCH_ERROR. See PR (esp. comment 2) for a more detailed description: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50163#c0 Buil

Re: [trans-mem] Use __x86_64__ instead of __LP64__.

On Mon, 2011-08-22 at 14:42 -0700, Richard Henderson wrote: > On 08/22/2011 02:42 AM, Torvald Riegel wrote: > > Use __x86_64__ instead of __LP64__ in setjmp/longjmp and TLS > > definitions. > > > > H.J.: Is that sufficient for x32, or do we need entirely different code? > > If so, can you please p

[google] Remove timestamped line from gengtype state file comment headers

Remove the timestamped line from gengtype state file comment headers. Gcc builds after r177358 include a file .../plugin/gtype.state as part of their binary installation. The file contains a comment line that includes the current date and time. Variations in the file contents due to only changes

Re: [google] Remove timestamped line from gengtype state file comment headers

On Tue, Aug 23, 2011 at 2:36 PM, Simon Baldwin wrote: > Remove the timestamped line from gengtype state file comment headers. > > Gcc builds after r177358 include a file .../plugin/gtype.state as part of > their binary installation.  The file contains a comment line that includes > the current dat

Re: [google] Remove timestamped line from gengtype state file comment headers

Hi, On Tue, 23 Aug 2011, Richard Guenther wrote: > > This patch removes the comment line, to provide binary reproducibility for > > any generated gtype.state files. > > > > Tested for x86 and PowerPC, no bootstrap in both cases. > > > > OK for google/integration?  Also, OK for trunk? > > Ok for

Re: [var-tracking] small speed-ups

On Tue, Aug 23, 2011 at 02:40:56PM +0300, Dimitrios Apostolou wrote: > I was hoping you'd ask so I'll ask back :-) Why are we doing it that > way? Why so much indirection in the first place? Why create inline > functions just to typecast and why do we need this CONST_CAST2 > ugliness in C code. I b

Re: [PATCH] For FFS/CLZ/CTZ/CLRSB/POPCOUNT/PARITY/BSWAP require operand mode equal to operation mode (or VOIDmode) (PR middle-end/50161)

Jakub Jelinek wrote: > On Tue, Aug 23, 2011 at 11:57:58AM +0200, Bernd Schmidt wrote: >> On 08/23/11 11:52, Jakub Jelinek wrote: >>> On Tue, Aug 23, 2011 at 11:35:07AM +0200, Bernd Schmidt wrote: > cse_process_notes_1 > perhaps could be changed for VOIDmode new_rtx to try to > simplify_

Re: [var-tracking] small speed-ups

On Tue, 23 Aug 2011, Jakub Jelinek wrote: On Tue, Aug 23, 2011 at 02:40:56PM +0300, Dimitrios Apostolou wrote: dst->vars = (shared_hash) pool_alloc (shared_hash_pool); dst->vars->refcount = 1; dst->vars->htab -= htab_create (MAX (src1_elems, src2_elems), variable_htab_hash, += hta

Re: [rfa] Set alignment of pseudos via get_pointer_alignment

Hi, > > Like so.  Regstrapped on x86_64-linux (all languages + Ada).  Okay for > > trunk? > > Ok. r177989 (JFYI because it's some time ago to make searching the archives easier). Ciao, Michael.

Re: [google] Remove timestamped line from gengtype state file comment headers

On 23 August 2011 15:34, Michael Matz wrote: > > Hi, > > On Tue, 23 Aug 2011, Richard Guenther wrote: > > > > This patch removes the comment line, to provide binary reproducibility for > > > any generated gtype.state files. > > > > > > Tested for x86 and PowerPC, no bootstrap in both cases. > > >

Re: [trans-mem] Use __x86_64__ instead of __LP64__.

On Mon, Aug 22, 2011 at 6:44 AM, H.J. Lu wrote: > On Mon, Aug 22, 2011 at 2:42 AM, Torvald Riegel wrote: >> Use __x86_64__ instead of __LP64__ in setjmp/longjmp and TLS >> definitions. >> >> H.J.: Is that sufficient for x32, or do we need entirely different code? >> If so, can you please provide

Re: [PATCH] Fix configure --with-cloog

Ping

Re: [Patch] Properly find getopt system declaration

2011/8/10 Romain GEISSLER : > Hi > > Thanks to the recent changes made to stage 2 and 3 (now built with g++), i > noticed a little error in the configure script that tries the > system getopt declaration. Indeed, if your system defines it in a system > header file named "getopt.h" (for example /usr

Re: [PATCH, i386, testsuite] FMA intrinsics

On Tue, Aug 23, 2011 at 4:19 PM, Ilya Tocar wrote: > I removed unnecessary expands/builtins and tests are now compiled with -O2. > Is this version ok? OK with minor comments: - Please remove extra blank lines you introduced in sse.md - Also, I'd recomend you to pass new testcases through "indent

Re: [PATCH] PR c++/50055: Location information for the throw() specification in a function may be incorrect

On 08/12/2011 03:18 PM, Siddhesh Poyarekar wrote: When the location for throw() exception specification is not the same as the function it is written against, it leads gcov to give incorrect results. See bug 50055 for details of the the same. The following patch makes sure that the exception spec

Re: [PATCH] PR c++/50055: Location information for the throw() specification in a function may be incorrect

On Tue, Aug 23, 2011 at 10:56:26AM -0400, Jason Merrill wrote: > This patch is small enough not to need it, but for future > contributions please file a copyright assignment with the FSF. Send > email to ass...@gnu.org for more information. I think Siddhesh should be covered by the Red Hat assign

Re: [PATCH] PR c++/50055: Location information for the throw() specification in a function may be incorrect

On Tue, Aug 23, 2011 at 8:33 PM, Jakub Jelinek wrote: > On Tue, Aug 23, 2011 at 10:56:26AM -0400, Jason Merrill wrote: >> This patch is small enough not to need it, but for future >> contributions please file a copyright assignment with the FSF.  Send >> email to ass...@gnu.org for more informatio

[PATCH, MELT] Calling unloaded shared library

Hello, The following patch fixes a 'small' issue I have been facing since a couple of days: MELT would not be able to call the start_module_melt() symbol that is present in warmelt-first(...).so. It turned out that the shared library where *unloaded* at run time ; each one being loaded and then un

[PATCH] Fix .so handling on failure

When an invalid handle from dlopen() was generated, the else branch corresponding was not at the right place and was a child of 'if (!quiet_flag || flag_melt_debug)' condition. This leads to unloading of shared library just loaded by MELT runtime when debug is not enabled, hence the next call to m

C++ PATCH to allow 'this' in constexpr member functions

In a pre-standard version of the constexpr specification use of 'this' was not valid in a constexpr function except as part of a member access. We dropped the notion of potential constant expression from the standard, in favor of just saying that a constexpr function that can never produce a c

C++ PATCH for c++/50024 (ICE with new int{})

maybe_constant_value was failing to recognize that we can't ask for the constant value of an initializer list because it has no type. After fixing that, we still incorrectly rejected the testcase, so I had to fix a couple of other spots as well. Tested x86_64-pc-linux-gnu, applying to trunk a

C++ PATCH for core issue 975 (extended lambda return type deduction)

At the Bloomington meeting last week the committee finally accepted my proposal to allow return type deduction from lambdas of arbitrary form as long as the deduced type is the same for all return statements, as implemented in G++. My implementation did the type comparison at template definiti

Re: [PATCH] For FFS/CLZ/CTZ/CLRSB/POPCOUNT/PARITY/BSWAP require operand mode equal to operation mode (or VOIDmode) (PR middle-end/50161)

On Tue, Aug 23, 2011 at 02:06:05PM +0200, Jakub Jelinek wrote: > We can remove that restriction again once CONST_INTs are no longer VOIDmode. > > Here is an untested patch, will bootstrap/regtest it now on x86_64-linux > and i686-linux, on c6x it should make no difference IMHO (looked like a typo

[C++ PATCH] Fix -Wunused-but-set-* on RHS of x op= rhs if rhs has side-effects (PR c++/50158)

Hi! The recent cp_build_modify_expr change broke the following testcase, we now complain that b is set but not used. The problem is that when rhs has side-effects, stabilize_expr returns a temporary (+ creates a TARGET_EXPR), which means that mark_exp_read isn't actually called on the original RH

Re: [PATCH] For FFS/CLZ/CTZ/CLRSB/POPCOUNT/PARITY/BSWAP require operand mode equal to operation mode (or VOIDmode) (PR middle-end/50161)

On 08/23/11 17:42, Jakub Jelinek wrote: > On Tue, Aug 23, 2011 at 02:06:05PM +0200, Jakub Jelinek wrote: >> We can remove that restriction again once CONST_INTs are no longer VOIDmode. >> >> Here is an untested patch, will bootstrap/regtest it now on x86_64-linux >> and i686-linux, on c6x it should

C++ PATCH for core issue 903 (C++11 null pointer constant)

C++11 greatly expands the set of constant expressions, which aggravates the existing issue with overloading and null pointer constants. If an expression could potentially be a constant expression, we need to find its constant value in order to determine how it interacts with overload resolutio

Re: [C++ PATCH] Fix -Wunused-but-set-* on RHS of x op= rhs if rhs has side-effects (PR c++/50158)

OK. Jason

C++ PATCH for a fixme in build_functional_cast

While looking at another issue I noticed this fixme. A TARGET_EXPR of literal type should have TREE_CONSTANT set iff the initializer is constant, and this patch implements that. Tested x86_64-pc-linux-gnu, applying to trunk. commit 21aebcf68d774827647731368a5708e1c60c31af Author: Jason Merrill

C++ PATCH for c++/49045 (core 1321, equivalence of dependent names)

In this PR, g++ was treating two uses of "swap" in a decltype as different because the result of unqualified name lookup changed between them. At the meeting last week the committee decided that two dependent names should be considered equivalent even if that happens. Tested x86_64-pc-linux-g

C++ PATCH to make build_functional_cast call build_value_init unconditionally

The conditions for value-initialization of a class type have gotten more complicated, so we shouldn't try to duplicate them in the caller. Tested x86_64-pc-linux-gnu, applying to trunk. commit b45bd43f5bf3aceb81d467be40bc97bafacb5d1e Author: Jason Merrill Date: Fri Aug 19 16:35:40 2011 -0400

Re: [PATCH, testsuite, i386] AVX2 support for GCC

On Tue, Aug 23, 2011 at 6:03 PM, Kirill Yukhin wrote: > thanks for inputs! I've applied all. > > Also I fixed I a bug (which produced ICE). > > ChangeLog entry: > 2011-08-23  Kirill Yukhin   > >        * config/i386/sse.md (mul3_highpart): Update. > > Patch and testsuite/ChangeLog entry are attac

Re: [PATCH, testsuite, i386] AVX2 support for GCC

Thanks, done. Updated patch attached. -- K On Tue, Aug 23, 2011 at 8:16 PM, Uros Bizjak wrote: > On Tue, Aug 23, 2011 at 6:03 PM, Kirill Yukhin > wrote: > >> thanks for inputs! I've applied all. >> >> Also I fixed I a bug (which produced ICE). >> >> ChangeLog entry: >> 2011-08-23  Kirill Yukhi

Re: [PATCH v3, i386] BMI2 support for GCC, mulx, rorx, x part

On Tue, Aug 23, 2011 at 6:22 PM, Kirill Yukhin wrote: > thanks. I've applied your inputs. > > Updated patch, ChangeLog, testsuite/ChangeLog are attached. > > Are they ok now? OK for mainline. Thanks, Uros.

Re: [trans-mem] Add method groups and change TM method lifecycle and selection.

On 08/23/2011 05:01 AM, Torvald Riegel wrote: > Add method groups and change TM method lifecycle and selection. > > * retry.cc (GTM::gtm_thread::decide_retry_strategy): Cleanup. Fix > restarting without switching to serial mode. > (GTM::gtm_thread::decide_begin_dispatch):

Re: [PATCH, testsuite, i386] AVX2 support for GCC

On Tue, Aug 23, 2011 at 6:31 PM, Kirill Yukhin wrote: > Thanks, done. > Updated patch attached. OK for mainline. Thanks, Uros.

Re: [PATCH v3, i386] BMI2 support for GCC, mulx, rorx, x part

Great! Thanks. Could anybody please commit that? K On Tue, Aug 23, 2011 at 8:53 PM, Uros Bizjak wrote: > On Tue, Aug 23, 2011 at 6:22 PM, Kirill Yukhin > wrote: > >> thanks. I've applied your inputs. >> >> Updated patch, ChangeLog, testsuite/ChangeLog are attached. >> >> Are they ok now? > >

Re: [PATCH, testsuite, i386] AVX2 support for GCC

Thanks, could anybody please commit that? K On Tue, Aug 23, 2011 at 8:54 PM, Uros Bizjak wrote: > On Tue, Aug 23, 2011 at 6:31 PM, Kirill Yukhin > wrote: >> Thanks, done. >> Updated patch attached. > > OK for mainline. > > Thanks, > Uros. >

Re: [trans-mem] Use __x86_64__ instead of __LP64__.

On 08/23/2011 05:33 AM, Torvald Riegel wrote: > Use __x86_64__ instead of __LP64__. > > * config/x86/tls.h: Use __x86_64__ instead of __LP64__. > Add X32 support. > * config/x86/sjlj.S: Same. Ok. At some point we really should merge from mainline, so that we can test th

Re: [PATCH v3, i386] BMI2 support for GCC, mulx, rorx, x part

On Tue, Aug 23, 2011 at 9:55 AM, Kirill Yukhin wrote: > Great! Thanks. > > Could anybody please commit that? Done. Thanks. > K > > On Tue, Aug 23, 2011 at 8:53 PM, Uros Bizjak wrote: >> On Tue, Aug 23, 2011 at 6:22 PM, Kirill Yukhin >> wrote: >> >>> thanks. I've applied your inputs. >>> >>>

Re: [PATCH, testsuite, i386] AVX2 support for GCC

On Tue, Aug 23, 2011 at 9:55 AM, Kirill Yukhin wrote: > Thanks, > > could anybody please commit that? > Please regenerate AVX2 patch with the current trunk since your change won't apply after BMI2 checkin. Thanks. -- H.J.

[PATCH] Add infrastructure to merge standard builtin enums with backend builtins

Over the years, it has been a problem for ports like the PowerPC that have more builtins than the standard list. Code that references the built_in_decls and implicit_built_in_decls arrays are supposed to check DECL_BUILT_IN_CLASS being BUILT_IN_NORMAL first, but every so often code doesn't do this

Re: [rs6000] Fix creation of invalid CONST_VECTORs

On Aug 23, 2011, at 3:44 AM, Richard Sandiford wrote: > My patches to more "accurately" detect the number of zero elements in a > compound initialiser caused pr34856 to trigger on powerpc*-darwin: > >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34856 Thanks for fixing this... I don't think th

[PATCH] Handle CLRSB in nonzero_bits1

Hi! While looking at PR50168, I've noticed that CLRSB isn't handled in nonzero_bits1 (while FFS/POPCOUNT/PARITY/CLZ/CTZ are). It means that combine can't optimize say clrsb insn followed by zero or sign extension of the result. Fixed thusly, ok for trunk? 2011-08-23 Jakub Jelinek * r

Re: [PATCH] Handle CLRSB in nonzero_bits1

On 08/23/2011 10:52 AM, Jakub Jelinek wrote: > 2011-08-23 Jakub Jelinek > > * rtlanal.c (nonzero_bits1): Handle CLRSB. Ok. r~

[pph] Remove fixed FIXME in p4eabi.h (issue4939045)

This memory problem was probably due to the big line_table being created with the incorrect code before. This test now passes and this FIXME was irrelevant, removed it. Trivial patch, already discussed with Diego, committed to pph. 2011-08-23 Gabriel Charette * g++.dg/pph/p4eabi1.h:

[libcpp,lto,fortran PATCH] Fix linemap_add use and remove unnecessary kludge

Hello, There are a couple of places in the compiler that need to create line maps directly by calling linemap_add. The problem is, sometimes we wrongly do so by passing LC_RENAME as the reason argument even when creating the first map of a given file. But then linemap_add has some code to change

Re: [PATCH 4/7] Support -fdebug-cpp option

Alexandre Oliva writes: > On Jul 16, 2011, Dodji Seketeli wrote: > >> This patch adds -fdebug-cpp option. When used with -E this dumps the >> relevant macro map before every single token. This clutters the output >> a lot but has proved to be invaluable in tracking some bugs during the >> develo

Re: [PATCH, testsuite, i386] AVX2 support for GCC

Pulled down. Updated patch attached. -- Thanks, K On Tue, Aug 23, 2011 at 9:06 PM, H.J. Lu wrote: > On Tue, Aug 23, 2011 at 9:55 AM, Kirill Yukhin > wrote: >> Thanks, >> >> could anybody please commit that? >> > > Please regenerate AVX2 patch with the current trunk > since your change won't ap

Include $(CFLAGS-$@) in ALL_CXXFLAGS

I noticed that in gcc/Makefile.in, ALL_CFLAGS included $(CFLAGS-$@) but ALL_CXXFLAGS was missing it. I don't see any reason for this difference; this patch makes the two agree more closely. Bootstrapped with no regressions on x86_64-unknown-linux-gnu. OK to commit? 2011-08-23 Joseph Myers

Re: [PATCH, testsuite, i386] AVX2 support for GCC

On Tue, Aug 23, 2011 at 12:04 PM, Kirill Yukhin wrote: > Pulled down. Updated patch attached. I checked it in. Thanks. > -- > Thanks, K > > On Tue, Aug 23, 2011 at 9:06 PM, H.J. Lu wrote: >> On Tue, Aug 23, 2011 at 9:55 AM, Kirill Yukhin >> wrote: >>> Thanks, >>> >>> could anybody please com

Re: Include $(CFLAGS-$@) in ALL_CXXFLAGS

There are some gcc flags that are not legal g++ flags, though...

Re: Include $(CFLAGS-$@) in ALL_CXXFLAGS

On Tue, 23 Aug 2011, DJ Delorie wrote: > There are some gcc flags that are not legal g++ flags, though... True, but not relevant to this patch, since every flag currently in $(CFLAGS-$@) is valid for both (and I'm working on a follow-up patch moving more flags into $(CFLAGS-$@), that will be va

[lra] Rewriting caller saves subpass.

After some experiments I found that there is practically no a generated code improvement of the current LRA caller saves subpass in comparison of the subpass implemented in this patch. The current subpass was based on iterated global forward/backward solution of the problem putting save/res

Re: Include $(CFLAGS-$@) in ALL_CXXFLAGS

Hmm... ok, I'm just a tad paranoid about using the name "CFLAGS" for g++, someone's bound to do the stupid thing eventually.

[google] With FDO/LIPO inline some cold callsites

The following patch changes the inliner callsite filter with FDO/LIPO. Previously, cold callsites were unconditionally rejected. Now the callsite may still be inlined if the _caller_ is sufficiently hot (max count of any bb in the function is above hot threshold). This gives about 0.5 - 1% geome

[PATCH, i386]: Introduce Yp register constraint and merge *_lea add ans ashift patterns with base

Hello! Attached patch introduces Yp register constraint, conditionalized on TARGET_PARTIAL_REG_STALL. Using this constraint, several *_lea patterns can be merged with their base patterns, resulting in many removed lines of code. No functional changes otherwise. 2011-08-23 Uros Bizjak

Re: [google] With FDO/LIPO inline some cold callsites

The patch makes sense as inlining cold callsites can sharpen analysis in the hot caller leading to more aggressive optimization. Ok for google branch. Thanks, David On Tue, Aug 23, 2011 at 12:56 PM, Mark Heffernan wrote: > The following patch changes the inliner callsite filter with FDO/LIPO.

Re: [PATCH, i386]: Introduce Yp register constraint and merge *_lea add ans ashift patterns with base

On 08/23/2011 12:59 PM, Uros Bizjak wrote: > * config/i386/constraints.md (Yp): New register constraint. > * config/i386/i386.md (*addhi_1): Merge with *addhi_1_lea using > Yp register constraint. > (*addqi_1): Merge with *addqi_1_lea using Yp register constraint. > (*

Re: [PATCH, i386]: Introduce Yp register constraint and merge *_lea add ans ashift patterns with base

On Tue, Aug 23, 2011 at 10:04 PM, Richard Henderson wrote: >>       * config/i386/constraints.md (Yp): New register constraint. >>       * config/i386/i386.md (*addhi_1): Merge with *addhi_1_lea using >>       Yp register constraint. >>       (*addqi_1): Merge with *addqi_1_lea using Yp register

Re: [PATCH, i386]: Introduce Yp register constraint and merge *_lea add ans ashift patterns with base

On Tue, Aug 23, 2011 at 10:23:54PM +0200, Uros Bizjak wrote: > On Tue, Aug 23, 2011 at 10:04 PM, Richard Henderson wrote: > > >>       * config/i386/constraints.md (Yp): New register constraint. > >>       * config/i386/i386.md (*addhi_1): Merge with *addhi_1_lea using > >>       Yp register cons

Re: [PATCH, i386]: Introduce Yp register constraint and merge *_lea add ans ashift patterns with base

On 08/23/2011 01:23 PM, Uros Bizjak wrote: > Yes, I am aware of this attribute, but OTOH, I propose that we use it > for ISA changes and don't mix everything together. I think that's more confusing than not. We can use other sub-attributes than ISA if that makes it easier for you, but I do think

Re: [RFC] Cleanup DW_CFA_GNU_args_size handling

On 08/21/2011 02:51 PM, Eric Botcazou wrote: >> I'm afraid this patch casues i386 bootstraps to fail: >> >> Comparing stages 2 and 3 >> warning: gcc/cc1-checksum.o differs >> warning: gcc/cc1plus-checksum.o differs >> warning: gcc/cc1obj-checksum.o differs >> Bootstrap comparison failure!

[patch, hpux, committed] Fix libstdc++/50153, hppa*-hp-hpux11* build problem

The recent change for libstdc++/1773 included a change that defined __cplusplus to be 199711L instead of 1. That caused a problem with the integer abs() definition on hppa*-hp-hpux11*. It did not cause a problem on ia64-hp-hpux11* because of a fixincludes rule (hpux11_abs) that was applied to ia

Re: [PATCH, i386]: Introduce Yp register constraint and merge *_lea add ans ashift patterns with base

On 08/23/11 22:23, Uros Bizjak wrote: > On Tue, Aug 23, 2011 at 10:04 PM, Richard Henderson wrote: > >>> * config/i386/constraints.md (Yp): New register constraint. >>> * config/i386/i386.md (*addhi_1): Merge with *addhi_1_lea using >>> Yp register constraint. >>> (*addqi_

[Patch, fortran] Fix PR fortran/50050 breakage: ICE on valid with null pointer initialization

Hello, this is an attempt to fix my recent breakage for PR50050. I forgot that shape can't always be known, and thus, that for some expressions, the shape field is a NULL pointer. This patch adds an early return in gfc_free_shape in the case shape is NULL. Then some external NULL shape checks ar

Reduce duplication of compilation commands

This patch, relative to a tree with my patch applied, reduces the number of explicit compilation rules in gcc/ and subdirectory makefiles by using CFLAGS-$@ settings when a target needs extra compiler options. Not fixed are rules for buildi

Re: [cxx-mem-model] Atomic C++ header file changes

On 08/18/2011 06:33 PM, Richard Henderson wrote: On 08/17/2011 08:39 AM, Andrew MacLeod wrote: ! return __sync_mem_load (const_cast<__int_type *>(&_M_i), __m); This suggests the builtin is incorrectly defined. It ought to be const itself. Err, right. This patch declares the function pr

  1   2   >