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

On 08/23/2011 07:29 PM, Michael Meissner wrote: + tm_builtin_funcs="$(tm_builtin_funcs) config/rs6000/rs6000-builtin.def" + tm_builtin_funcs="$(tm_builtin_funcs) config/rs6000/rs6000-builtin.def" These should use braces; build parts are otherwise okay. Paolo

Re: Reduce duplication of compilation commands

On 08/24/2011 12:06 AM, Joseph S. Myers wrote: 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

Re: Reduce duplication of compilation commands

On 08/24/2011 12:06 AM, Joseph S. Myers wrote: 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

Re: [RFC] Cleanup DW_CFA_GNU_args_size handling

On Tue, Aug 23, 2011 at 6:07 PM, Gerald Pfeifer wrote: > Hmm, does a copy of my build tree (including logs in nohup.out) help? > > I put up one at http://people.freebsd.org/~gerald/objtree.tar.xz . > I couldn't reproduce the bootstrap failure n Linux/ia32 either. Have you tried the latest binuti

Re: [RFC] Cleanup DW_CFA_GNU_args_size handling

Hmm, does a copy of my build tree (including logs in nohup.out) help? I put up one at http://people.freebsd.org/~gerald/objtree.tar.xz . Gerald

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

On Aug 23, 2011, at 10:29 AM, Michael Meissner wrote: > This patch growes the bit field that has the builtin function number by one > bit. I _use_ 13 bits on my port. If you do 13, we won't have to change it for 10 years, I promise. :-)

Re: [RFC] Cleanup DW_CFA_GNU_args_size handling

On 08/23/2011 03:42 PM, Gerald Pfeifer wrote: > On Tue, 23 Aug 2011, Richard Henderson wrote: >> I've been trying for 2 days to replicate this with various >> configurations and none have failed. > > Thanks for investigating, and sorry that this proves a worthy opponent! > > > On my testers, the

patch to solve recent SPEC2000 degradation

Starting Aug 20, there is about 1.5% degradation on x86 SPEC2000, please see http://vmakarov.fedorapeople.org/spec/. The reason for this was my patch http://gcc.gnu.org/ml/gcc-patches/2011-08/msg01623.html for solving code performance degradation on MIPS. Instead of using explicitly ne

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

On 08/23/2011 03:24 PM, Andrew MacLeod wrote: > On 08/23/2011 06:20 PM, Richard Henderson wrote: >> On 08/23/2011 03:13 PM, Andrew MacLeod wrote: >>> ! DEF_FUNCTION_TYPE_2 (BT_FN_I1_CONST_VPTR_INT, BT_I1, >>> BT_CONST_VOLATILE_PTR, >>> ! BT_INT) >> Given that VPTR means "volatile PTR"

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

On 08/23/2011 06:20 PM, Richard Henderson wrote: On 08/23/2011 03:13 PM, Andrew MacLeod wrote: ! DEF_FUNCTION_TYPE_2 (BT_FN_I1_CONST_VPTR_INT, BT_I1, BT_CONST_VOLATILE_PTR, !BT_INT) Given that VPTR means "volatile PTR", I suggest you use CVPTR instead of CONST_VPTR. Hmm, w

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

On 08/23/2011 03:13 PM, Andrew MacLeod wrote: > ! DEF_FUNCTION_TYPE_2 (BT_FN_I1_CONST_VPTR_INT, BT_I1, BT_CONST_VOLATILE_PTR, > ! BT_INT) Given that VPTR means "volatile PTR", I suggest you use CVPTR instead of CONST_VPTR. Otherwise ok. r~

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

Hi Mikael: > 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

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

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

[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

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, 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: [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!

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: [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 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 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: [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.

[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

[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

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.

[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

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

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

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

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

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

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

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

[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

[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:

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~

[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: [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] 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: [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.

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: [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, 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: [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

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] 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 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: [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, 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

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

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 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

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 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: [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] 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 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 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

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 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

[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

[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

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

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 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, 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] 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] Fix configure --with-cloog

Ping

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: [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: [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: [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: [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, 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: [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: [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

[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: [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

[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

[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] 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... > >> >

[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

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

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: [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: [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: [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: 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, 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

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: 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: [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 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: 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

[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 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

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

[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

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

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

  1   2   >