[PATCH, i386]: Fix i386.md:5807: warning: source missing a mode?

Hello! 2011-07-28 Uros Bizjak * config/i386/i386.c (add->lea splitter): Add SWI mode to PLUS RTX. Tested on x86_64-pc-linux-gnu, committed to mainline. Uros. Index: i386.md === --- i386.md (revision 176858) +++ i386

Re: [RS6000] asynch exceptions and unwind info

On Wed, Jul 27, 2011 at 03:00:45PM +0930, Alan Modra wrote: > Ideally what I'd like to > do is have ld and gcc emit accurate r2 tracking unwind info and > dispense with hacks like frob_update_context. If ld did emit accurate > unwind info for .glink, then the justification for frob_update_context

Re: PING: PATCH [4/n]: Prepare x32: Permute the conversion and addition if one operand is a constant

On 07/28/2011 12:59 AM, H.J. Lu wrote: > Regarding correctness: you're converting a SImode operation to DImode by > "pushing in" the zero_extend operation. What makes you think that base + > constant offset won't overflow in any case? You have not answered this. > And also: what are you

[PATCH] PR49799: Don't generate illegal bit field extraction instruction

Hi In function combine.c:make_compound_operation, it tries to transforms the expression (ashiftrt (ashift foo C1) C2) with C2 >= C1 into SIGN_EXTRACT. It works pretty well in usual cases. But for the test case in PR49799, there is an expression (X << (tmp-1)) >> 16 tmp is an uninitializ

Re: PATCH: PR target/47715: [x32] TLS doesn't work

On Thu, Jul 28, 2011 at 8:52 AM, Uros Bizjak wrote: >> TLS on X32 is almost identical to TLS on x86-64.  The only difference is >> x32 address space is 32bit.  That means TLS symbols can be in either >> SImode or DImode with upper 32bit zero.  This patch updates >> tls_global_dynamic_64 to suppor

Re: PATCH: PR target/47715: [x32] Use SImode for thread pointer

On Thu, Jul 28, 2011 at 5:11 AM, H.J. Lu wrote: > In x32, thread pointer is 32bit and choice of segment register for the > thread base ptr load should be based on TARGET_64BIT.  This patch > implements it.  OK for trunk? -ENOTESTCASE. Uros.

Re: [PATCH] Fix PR49876: Continue code generation with integer_zero_node on gloog_error

On Wed, Jul 27, 2011 at 8:49 PM, Sebastian Pop wrote: > When setting gloog_error, graphite should continue code generation > without early returns, as otherwise the SSA representation would not > be complete.  So set the new expression to integer_zero_node, that > would not require more SSA update

Re: [PATCH, PR 49094] Refrain from creating misaligned accesses in SRA

On Wed, Jul 27, 2011 at 9:23 PM, Ulrich Weigand wrote: > Martin Jambor wrote: >> On Wed, Jul 27, 2011 at 02:34:59PM +0200, Ulrich Weigand wrote: >> > Martin Jambor wrote: >> > >> > > OK, this is what I have just committed as revision 176797 after >> > > re-testing. >> > >> > Thanks, this has fixed

Re: [PATCH] PR49799: Don't generate illegal bit field extraction instruction

On Thu, Jul 28, 2011 at 03:38:07PM +0800, Carrot Wei wrote: > OK for trunk and 4.6? > > ChangeLog: > 2011-07-28 Wei Guozhi > > PR rtl-optimization/49799 > * combine.c (make_compound_operation): Check if the bit field is valid > before change it to bit field extraction.

Re: [C++0x] contiguous bitfields race implementation

On Wed, Jul 27, 2011 at 7:36 PM, Aldy Hernandez wrote: > >> Oh, and >> >>    INNERDECL is the actual object being referenced. >> >>       || (!ptr_deref_may_alias_global_p (innerdecl) >> >> is surely not what you want.  That asks if *innerdecl is global memory. >> I suppose you want is_global_var

Re: [C++0x] contiguous bitfields race implementation

On Wed, Jul 27, 2011 at 7:19 PM, Andrew MacLeod wrote: > On 07/27/2011 01:08 PM, Aldy Hernandez wrote: >> >>> Anyway, I don't think a --param is appropriate to control a flag whether >>> to allow store data-races to be created.  Why not use a regular option >>> instead? >> >> I don't care either w

Re: [PATCH] PR49799: Don't generate illegal bit field extraction instruction

Test case added. Tested with make check-gcc RUNTESTFLAGS="--target_board=arm-sim/thumb/arch=armv7-a arm.exp=pr49799.c" make check-gcc RUNTESTFLAGS="--target_board=arm-sim/arch=armv7-a arm.exp=pr49799.c" It fails without this patch and passes with this patch. OK for trunk and 4.6 now? thanks Car

Re: [PATCH] PR49799: Don't generate illegal bit field extraction instruction

On Thu, Jul 28, 2011 at 04:40:53PM +0800, Carrot Wei wrote: > ChangeLog: > 2011-07-28 Wei Guozhi > > PR rtl-optimization/49799 > * pr49799.c : New test case. Space shouldn't be between .c and :. And the filename should be relative to gcc/testsuite/ dir, so either gcc.target/ar

Re: [PATCH PR43513, 1/3] Replace vla with array - Implementation.

On Wed, 27 Jul 2011, Michael Matz wrote: > Hi, > > On Wed, 27 Jul 2011, Richard Guenther wrote: > > > > > I don't think it is safe to try to get at the VLA type the way you do. > > > > > > I don't understand in what way it's not safe. Do you mean I don't manage > > > to find > > > the type alw

Re: [v3] Library bits of c++/49813

Paolo Carlini writes: > 2011-07-27 Paolo Carlini > > PR c++/49813 > * include/c_global/cmath: Use _GLIBCXX_CONSTEXPR and constexpr. I'm seeing this error on ia64: /usr/local/gcc/gcc-20110728/Build/./gcc/xgcc -shared-libgcc -B/usr/local/gcc/gcc-20110728/Buil

Re: [PATCH] Fix PR47594: Sign extend constants while translating to Graphite

On Wed, 27 Jul 2011, Sebastian Pop wrote: > On Tue, Jul 26, 2011 at 09:34, Richard Guenther wrote: > > Truncating -1 doesn't matter - it matters that if you perform any > > unsigned arithmetic in arbitrary precision signed arithmetic that > > you properly truncate after each operation to simulate

Re: [Patch,AVR]: PR49687 (better widening 32-bit mul)

Weddington, Eric wrote: >> Subject: Re: [Patch,AVR]: PR49687 (better widening 32-bit mul) >> >>> I didn't review the asm code, but the rest of the patch look ok to me. >>> >>> r~ >> Thanks, Eric will review the asm part :-) > > LOL > I trust you on the asm stuff. Ok by me. Ok, I installed it. D

[patch tree-optimization]: Remove TRUTH_NOT from vrp and adjust

Hello, this patch removes the handling for TRUTH_NOT_EXPR in tree-vrp.c and adjust some simplifications to be compatible with BIT_NOT_EXPR. ChangeLog 2011-07-28 Kai Tietz * tree-vrp.c (simplify_stmt_using_ranges): Remove TRUTH_NOT_EXPR case. (simplify_truth_ops_using

Re: [PATCH PR43513, 1/3] Replace vla with array - Implementation.

On Wed, 27 Jul 2011, Tom de Vries wrote: > On 07/27/2011 05:27 PM, Richard Guenther wrote: > > On Wed, 27 Jul 2011, Tom de Vries wrote: > > > >> On 07/27/2011 02:12 PM, Richard Guenther wrote: > >>> On Wed, 27 Jul 2011, Tom de Vries wrote: > >>> > On 07/27/2011 01:50 PM, Tom de Vries wrote:

Re: PING: PATCH [4/n]: Prepare x32: Permute the conversion and addition if one operand is a constant

Hello! > convert_memory_address_addr_space has a special PLUS/MULT case for > POINTERS_EXTEND_UNSIGNED < 0. ?It turns out that it is also needed > for all Pmode != ptr_mode cases. ?OK for trunk? > 2011-06-11 ?H.J. Lu ? > > ? ? ? ?PR middle-end/47727 > ? ? ? ?* explow.c (convert_memory_address_add

Re: PING: PATCH [4/n]: Prepare x32: Permute the conversion and addition if one operand is a constant

On 07/28/2011 11:30 AM, Uros Bizjak wrote: > convert_memory_address_addr_space has a special PLUS/MULT case for > POINTERS_EXTEND_UNSIGNED< 0. ?It turns out that it is also needed > for all Pmode != ptr_mode cases. ?OK for trunk? > 2011-06-11 ?H.J. Lu ? > > ? ? ? ?PR middle-end/47727 > ? ?

Re: [patch tree-optimization]: Remove TRUTH_NOT from vrp and adjust

On Thu, Jul 28, 2011 at 11:21 AM, Kai Tietz wrote: > Hello, > > this patch removes the handling for TRUTH_NOT_EXPR in tree-vrp.c and adjust > some simplifications to be compatible with BIT_NOT_EXPR. > > ChangeLog > > 2011-07-28  Kai Tietz   > >        * tree-vrp.c (simplify_stmt_using_ranges): Re

[PATCH] PR rtl-optimization/49884: get_last_value checks register mode before returning value

Hello, This is an attempt to fix 49884. get_last_value checks the register mode before returning any value. If the register was set using a different mode than the one we are currently inquiring about then we avoid making a wrong guess about the current value and return 0. PMatos 2011-07-28

Re: [v3] Library bits of c++/49813

Hi Andreas, /usr/local/gcc/gcc-20110728/Build/ia64-suse-linux/libstdc++-v3/include/cmath: In function 'constexpr float std::fma(float, float, float)': /usr/local/gcc/gcc-20110728/Build/ia64-suse-linux/libstdc++-v3/include/cmath:1288:43: sorry, unimplemented: unexpected ast of kin

Re: [PATCH, RFC] PR49749 biased reassociation for accumulator patterns

On Wed, Jul 27, 2011 at 5:11 PM, William J. Schmidt wrote: > This is a draft patch that biases the reassociation machinery so that > each iteration of an accumulator pattern in a loop is independent of the > other iterations.  This addresses a problem identified as an accidental > side effect of t

Re: Mention avx2 patch

On Thu, 28 Jul 2011, Kirill Yukhin wrote: > Ping Oh, sure. I had somehow thought this had been applied already. Instead of just removing ix86/avx, would you mind moving it to the "Inactive Development Branches" section? Gerald

Re: [PATCH 4/6] Shrink-wrapping

On 07/21/11 11:52, Richard Sandiford wrote: > The name "active_insn_after" seems a bit too similar to "next_active_insn" > for the difference to be obvious. How about something like > "first_active_target_insn" instead? Changed. >> - for (; insn; insn = next) >> + for (; insn && !ANY_RETURN_P (

[Revert,Committed,AVR]: Undo r176835

The two patches http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02424.html (PR target/49313) committed as r176835 and http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02391.html (PR target/49687) committed as r176862 are incompatible. The reason is that the first contains expanders that emit (set (r

[MELT] split_string_* functions now take a value

Hi, I changed the argument type for the cs argument in split_string functions. Indeed, there is no way to access the boxed string from a value, and sometimes we can't avoid working with boxed strings. As we can box a :cstring in a value, split_string_* functions are usable in all cases. Find atta

Re: [PATCH 4/6] Shrink-wrapping

Bernd Schmidt writes: >>> - for (; insn; insn = next) >>> + for (; insn && !ANY_RETURN_P (insn); insn = next) >>> { >>>if (NONJUMP_INSN_P (insn) && GET_CODE (PATTERN (insn)) == SEQUENCE) >>> insn = XVECEXP (PATTERN (insn), 0, 0); >> >> Since ANY_RETURN looks for patterns, while

Re: [C++0x] contiguous bitfields race implementation

On Wed, Jul 27, 2011 at 5:03 PM, Richard Guenther wrote: > On Wed, Jul 27, 2011 at 4:56 PM, Richard Guenther > wrote: >> On Wed, Jul 27, 2011 at 4:52 PM, Richard Guenther >> wrote: >>> On Tue, Jul 26, 2011 at 7:38 PM, Jason Merrill wrote: On 07/26/2011 10:32 AM, Aldy Hernandez wrote: >

[PATCH] unbreak attribute((optimize(...))) on m68k (PR47908)

On m68k-linux, gcc ICEs on any occurrence of attribute((optimize(...))) ever since gcc-4.4. Default optimization flags enable scheduling, which the backend doesn't support for non-ColdFire targets. The backend disables scheduling for non-ColdFire targets when processing command-line options, but

Re: [Patch ARM] Rejig constraint order in *movdf_vfp and *thumb2_movdf_vfp patterns.

Ok to commit ? Richard was ok with this offline and the tests showed no regressions. So I've committed this today. Ramana

Re: [PATCH] PR49799: Don't generate illegal bit field extraction instruction

On 28/07/11 09:40, Carrot Wei wrote: > Index: pr49799.c > === > --- pr49799.c (revision 0) > +++ pr49799.c (revision 0) > @@ -0,0 +1,25 @@ > +/* PR rtl-optimization/49799 */ > +/* { dg-do assemble } */ > +/* { dg-options "-O2 -w -march

Re: PATCH: PR target/47364: [x32] internal compiler error: in emit_move_insn, at expr.c:3355

On Thu, Jul 28, 2011 at 8:30 AM, Uros Bizjak wrote: >> We should only expand strlen to Pmode.  Otherwise, we got >> >> [hjl@gnu-6 ilp32-38]$ cat x.i >> char one[50] = "ijk"; >> int >> main (void) >> { >>  return __builtin_strlen (one) != 3; >> } >> [hjl@gnu-6 ilp32-38]$ /export/build/gnu/gcc/buil

Re: PATCH: PR target/47364: [x32] internal compiler error: in emit_move_insn, at expr.c:3355

On Thu, Jul 28, 2011 at 5:44 AM, Uros Bizjak wrote: > On Thu, Jul 28, 2011 at 8:30 AM, Uros Bizjak wrote: > >>> We should only expand strlen to Pmode.  Otherwise, we got >>> >>> [hjl@gnu-6 ilp32-38]$ cat x.i >>> char one[50] = "ijk"; >>> int >>> main (void) >>> { >>>  return __builtin_strlen (one

Re: PATCH: PR target/47715: [x32] Use SImode for thread pointer

On Thu, Jul 28, 2011 at 12:45 AM, Uros Bizjak wrote: > On Thu, Jul 28, 2011 at 5:11 AM, H.J. Lu wrote: > >> In x32, thread pointer is 32bit and choice of segment register for the >> thread base ptr load should be based on TARGET_64BIT.  This patch >> implements it.  OK for trunk? > > -ENOTESTCASE

Re: PATCH: PR target/47715: [x32] Use SImode for thread pointer

On Thu, Jul 28, 2011 at 6:08 AM, H.J. Lu wrote: > On Thu, Jul 28, 2011 at 12:45 AM, Uros Bizjak wrote: >> On Thu, Jul 28, 2011 at 5:11 AM, H.J. Lu wrote: >> >>> In x32, thread pointer is 32bit and choice of segment register for the >>> thread base ptr load should be based on TARGET_64BIT.  This

Re: Support -mcpu=native on Tru64 UNIX

Richard Henderson writes: > On 07/27/2011 04:57 AM, Rainer Orth wrote: >> The following patch does so for -mcpu=native/-mtune=native on Tru64 >> UNIX, using getsysinfo(2). A non-bootstrap C-only build is currently >> running, the options above work as expected. > > I hadn't realized that the =na

Re: Allow IRIX Ada bootstrap with C++

Eric Botcazou writes: >> That's what I did in my last patch, but without SA_SIGINFO set. This >> doesn't work since the additional args passed in the sa_handler case are >> not in any prototype, to g++ rightly complains (and this is an >> implementation detail I'd not rely upon if it can be avoi

Re: Allow IRIX Ada bootstrap with C++

> Bootstrapped without regressions on mips-sgi-irix6.5, all signal > handling failures introduced by my previous patch are gone again. > > Ok for mainline? OK.

Re: PATCH: PR target/47715: [x32] TLS doesn't work

On Thu, Jul 28, 2011 at 12:44 AM, Uros Bizjak wrote: > On Thu, Jul 28, 2011 at 8:52 AM, Uros Bizjak wrote: > >>> TLS on X32 is almost identical to TLS on x86-64.  The only difference is >>> x32 address space is 32bit.  That means TLS symbols can be in either >>> SImode or DImode with upper 32bit

Re: PATCH: PR target/47715: [x32] TLS doesn't work

On Wed, Jul 27, 2011 at 11:52 PM, Uros Bizjak wrote: > On Thu, Jul 28, 2011 at 4:55 AM, H.J. Lu wrote: >> TLS on X32 is almost identical to TLS on x86-64.  The only difference is >> x32 address space is 32bit.  That means TLS symbols can be in either >> SImode or DImode with upper 32bit zero.  Th

Re: Allow IRIX Ada bootstrap with C++

Rainer Orth writes: > diff --git a/gcc/ada/init.c b/gcc/ada/init.c > --- a/gcc/ada/init.c > +++ b/gcc/ada/init.c > @@ -787,7 +787,11 @@ extern struct Exception_Data _abort_sign > static void > __gnat_error_handler (int sig, siginfo_t *reason, void *uc ATTRIBUTE_UNUSED) > { > - int code = reas

Re: Support -mcpu=native on Tru64 UNIX

On 07/28/2011 06:29 AM, Rainer Orth wrote: > +{ IMPLVER_EV6_FAMILY, AMASK_BWX|AMASK_MVI|AMASK_FIX, "ev6" }, > +{ IMPLVER_EV5_FAMILY, AMASK_BWX, "ev56" }, In between is the pca56 with BWX+MVI. Otherwise ok. r~

Re: PATCH: PR target/47715: [x32] Use SImode for thread pointer

On Thu, Jul 28, 2011 at 6:40 AM, Uros Bizjak wrote: > On Thu, Jul 28, 2011 at 3:24 PM, H.J. Lu wrote: > > In x32, thread pointer is 32bit and choice of segment register for the > thread base ptr load should be based on TARGET_64BIT.  This patch > implements it.  OK for trunk? >>>

Re: PATCH: PR target/47715: [x32] TLS doesn't work

On Thu, Jul 28, 2011 at 7:42 AM, Uros Bizjak wrote: > On Thu, Jul 28, 2011 at 3:47 PM, H.J. Lu wrote: > > TLS on X32 is almost identical to TLS on x86-64.  The only difference is > x32 address space is 32bit.  That means TLS symbols can be in either > SImode or DImode with upper 32bit

[PATCH, ARM] Fix broken testcase, vfp-1.c, for Thumb

This patch makes the vfp-1.c testcase work for Thumb. It became broken when we restricted the negative offsets allowed for Thumb to fix up a Spec2K failure some months back. (It was previously possible to generate illegal offsets.) OK for trunk? Cheers, Ian 2011-07-28 Ian Bolton testsuit

Re: PATCH: PR target/47715: [x32] Use SImode for thread pointer

On Thu, Jul 28, 2011 at 6:40 AM, Uros Bizjak wrote: > On Thu, Jul 28, 2011 at 3:24 PM, H.J. Lu wrote: > > In x32, thread pointer is 32bit and choice of segment register for the > thread base ptr load should be based on TARGET_64BIT.  This patch > implements it.  OK for trunk? >>>

Re: PATCH: PR target/47715: [x32] Use SImode for thread pointer

On Thu, Jul 28, 2011 at 4:47 PM, H.J. Lu wrote: >> In x32, thread pointer is 32bit and choice of segment register for the >> thread base ptr load should be based on TARGET_64BIT.  This patch >> implements it.  OK for trunk? > > -ENOTESTCASE. > There is no standal

Re: [PATCH] Fix PR49876: Continue code generation with integer_zero_node on gloog_error

On Thu, Jul 28, 2011 at 09:49, Richard Guenther wrote: > And it's always integers or pointers only?  Otherwise you'd probably > want build_zero_cst (type) instead. Ok, I started regstrapping again with build_zero_cst. Thanks, Sebastian

Re: Unreviewed libgcc patches

NightStrike writes: > On Mon, Jul 18, 2011 at 8:21 AM, Rainer Orth > wrote: >> The following two libgcc patches have seen almost no comments, and >> certainly neither testing or review in a week: >> >>        CFT: [build] Move fp-bit support to toplevel libgcc >>        http://gcc.gnu.org/ml/gcc

Re: [PATCH PR43513, 1/3] Replace vla with array - Implementation.

On Thu, 28 Jul 2011, Tom de Vries wrote: > On 07/28/2011 12:22 PM, Richard Guenther wrote: > > On Wed, 27 Jul 2011, Tom de Vries wrote: > > > >> On 07/27/2011 05:27 PM, Richard Guenther wrote: > >>> On Wed, 27 Jul 2011, Tom de Vries wrote: > >>> > On 07/27/2011 02:12 PM, Richard Guenther wro

Re: [Patch,AVR]: PR49687 (better widening 32-bit mul)

On 07/28/2011 07:59 AM, Georg-Johann Lay wrote: > So it appears that IRA is not as smart as we thought and not > prepared for this... > > Or did I do something fundamentally wrong? It sure doesn't look like you've done anything wrong. r~

Re: [PATCH] Fix -gdwarf-3 DW_AT_data_member_location for >= 64KB offsets (PR debug/49871)

OK. Jason

Re: [PATCH] Disable size optimizations of -gdwarf-2 DW_AT_data_member_location DW_OP_plus_uconst

I'd find the logic easier to read if it were inverted, but OK. Jason

Re: PATCH: PR target/47715: [x32] Use SImode for thread pointer

On Thu, Jul 28, 2011 at 7:59 AM, Uros Bizjak wrote: > On Thu, Jul 28, 2011 at 4:47 PM, H.J. Lu wrote: > >>> In x32, thread pointer is 32bit and choice of segment register for the >>> thread base ptr load should be based on TARGET_64BIT.  This patch >>> implements it.  OK for trunk? >>

Re: PATCH: PR target/47715: [x32] Use SImode for thread pointer

On Thu, Jul 28, 2011 at 8:59 AM, H.J. Lu wrote: > On Thu, Jul 28, 2011 at 7:59 AM, Uros Bizjak wrote: >> On Thu, Jul 28, 2011 at 4:47 PM, H.J. Lu wrote: >> In x32, thread pointer is 32bit and choice of segment register for the thread base ptr load should be based on TARGET_64BI

Re: [trans-mem] Beginning of refactoring

> New erase method and placement new for aatree. > > * aatree.h (aa_tree::remove): New. > (aa_tree::operator new): Add placement new. Ok. > Change pr_hasElse to the value specified in the ABI. > > * libitm.h (_ITM_codeProperties): Change pr_ha

Re: [trans-mem] Beginning of refactoring

On 07/27/2011 03:35 AM, Torvald Riegel wrote: > patch7: gtm_transaction::decide_begin_dispatch() gets the transaction > properties from the caller instead of reading from > gtm_transaction::prop, which might not have been updated by the caller > yet. > > patch8: Fix nesting level reset when rollin

Re: [PATCH 0/3] Move Graphite to CLooG 0.16.3 with isl backend.

On 07/26/2011 08:30 PM, Sebastian Pop wrote: On Fri, Jul 22, 2011 at 07:32, Joseph S. Myers wrote: On Fri, 22 Jul 2011, Tobias Grosser wrote: I propose to switch to the official cloog.org cloog version with isl backend and at the same time to remove support for both CLooG-PPL legacy as well a

Re: [PATCH 0/3] Move Graphite to CLooG 0.16.3 with isl backend.

On 07/27/2011 06:20 PM, Jack Howarth wrote: On Fri, Jul 22, 2011 at 01:00:09AM +0200, Tobias Grosser wrote: Hi, I propose to switch to the official cloog.org cloog version with isl backend and at the same time to remove support for both CLooG-PPL legacy as well as CLooG-Parma. We want to switc

Re: [PATCH 1/3] Fix PR47653: do not handle loops using wrapping semantics in graphite

On 07/24/2011 08:25 AM, Sebastian Pop wrote: 2011-07-23 Sebastian Pop PR middle-end/47653 * graphite-scop-detection.c (graphite_can_represent_loop): Discard loops using wrapping semantics. * gcc.dg/graphite/run-id-pr47653.c: New. * gcc.dg/graphite/interc

[PATCH, PR 49886] Prevent fnsplit from changing signature when there are type attributes

Hi, pass_split_functions is happy to split functions which have type attributes but cannot update them if the new clone has in any way different parameters than the original. This can lead to miscompilations in cases like the testcase. This patch solves it by 1) making the inliner set the can_ch

Re: [PATCH] Fix PR48648: Handle CLAST assignments.

On 07/23/2011 12:01 AM, Sebastian Pop wrote: The CLAST produced by CLooG-ISL contains an assignment and GCC chokes on it. The exact CLAST contains an assignment followed by an if: scat_1 = max(0,ceild(T_4-7,8)); if (scat_1<= min(1,floord(T_4-1,8))) { S7(scat_1); } This is equivalent to a lo

Re: [PATCH PR43513, 1/3] Replace vla with array - Implementation.

On 07/28/2011 06:25 PM, Richard Guenther wrote: > On Thu, 28 Jul 2011, Tom de Vries wrote: > >> On 07/28/2011 12:22 PM, Richard Guenther wrote: >>> On Wed, 27 Jul 2011, Tom de Vries wrote: >>> On 07/27/2011 05:27 PM, Richard Guenther wrote: > On Wed, 27 Jul 2011, Tom de Vries wrote: >

[pph] Free buffers used during tree encoding/decoding

Noticed this while debugging the new tree encoding cache. No functional changes. This frees the memory used by the buffers used during tree streaming. It also moves the reader and writer data into a union to better distinguish them. Tested on x86_64. Diego. * pph-streamer.h (pph_str

Remove unused line_maps field last_listed (issue4810058)

The last_listed field in struct line_maps was never used, removed it. Gab 2011-07-28 Gabriel Charette * libcpp/include/line-map.h (struct line_maps): Remove unused field last_listed. diff --git a/libcpp/include/line-map.h b/libcpp/include/line-map.h index 3234423..f1d5bee 1

Re: Remove unused line_maps field last_listed (issue4810058)

Forgot to mention: Tested with bootstrap build and full regression testing. On 2011/07/28 17:55:15, Gabriel Charette wrote: The last_listed field in struct line_maps was never used, removed it. Gab 2011-07-28 Gabriel Charette * libcpp/include/line-m

Re: PING: PATCH [4/n]: Prepare x32: Permute the conversion and addition if one operand is a constant

On Thu, Jul 28, 2011 at 7:59 PM, H.J. Lu wrote: >>> >  convert_memory_address_addr_space has a special PLUS/MULT case for >>> >  POINTERS_EXTEND_UNSIGNED<  0. ?It turns out that it is also needed >>> >  for all Pmode != ptr_mode cases. ?OK for trunk? >>> >  2011-06-11 ?H.J. Lu ? >>> > >>> >  ? ?

PATCH: PR middle-end/49721: convert_memory_address_addr_space may generate invalid new insns

On Thu, Jul 28, 2011 at 11:05 AM, Uros Bizjak wrote: > On Thu, Jul 28, 2011 at 7:59 PM, H.J. Lu wrote: > >  convert_memory_address_addr_space has a special PLUS/MULT case for >  POINTERS_EXTEND_UNSIGNED<  0. ?It turns out that it is also needed >  for all Pmode != ptr_mode cases. ?

PATCH: PR target/47766: [x32] -fstack-protector doesn't work

Hi, This patch adds x32 support to UNSPEC_SP_XXX patterns. OK for trunk? Thanks. H.J. --- 2011-07-28 H.J. Lu PR target/47766 * config/i386/i386.md (PTR): New. (stack_protect_set: Check TARGET_LP64 instead of TARGET_64BIT. (stack_protect_test): Likewise.

Re: [patch] attribute to reverse bitfield allocations

> Seeing little opposition, I plod further... now with documentation > and a test case. OK yet? Ping? http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01889.html

Re: PATCH: PR target/47715: [x32] Use SImode for thread pointer

On Thu, Jul 28, 2011 at 8:03 PM, H.J. Lu wrote: >> So, instead of huge complications with new mode iterator, just >> introduce two new patterns that will shadow existing ones for >> TARGET_X32. >> >> Like in attached (untested) patch. >> > > I tried the following p

Re: PATCH: PR middle-end/49721: convert_memory_address_addr_space may generate invalid new insns

On Thu, Jul 28, 2011 at 8:09 PM, H.J. Lu wrote: > >  convert_memory_address_addr_space has a special PLUS/MULT case for > >  POINTERS_EXTEND_UNSIGNED<  0. ?It turns out that it is also needed > >  for all Pmode != ptr_mode cases. ?OK for trunk? > >  2011-06-11 ?H.J. Lu ? > > >

Re: PATCH: PR target/47715: [x32] Use SImode for thread pointer

On Thu, Jul 28, 2011 at 11:21 AM, Uros Bizjak wrote: > On Thu, Jul 28, 2011 at 8:03 PM, H.J. Lu wrote: > >>> So, instead of huge complications with new mode iterator, just >>> introduce two new patterns that will shadow existing ones for >>> TARGET_X32. >>> >>> Like in attache

Re: PATCH: PR target/47715: [x32] Use SImode for thread pointer

On Thu, Jul 28, 2011 at 8:30 PM, H.J. Lu wrote: > TP is 32bit in x32  For load_tp_x32, we load SImode value and > zero-extend to DImode. For add_tp_x32, we are adding SImode > value.  We can't pretend TP is 64bit.  load_tp_x32 and add_tp_x32 > must take SImode TP. >

Re: PATCH: PR middle-end/49721: convert_memory_address_addr_space may generate invalid new insns

On Thu, Jul 28, 2011 at 11:23 AM, Uros Bizjak wrote: > On Thu, Jul 28, 2011 at 8:09 PM, H.J. Lu wrote: > >> >  convert_memory_address_addr_space has a special PLUS/MULT case for >> >  POINTERS_EXTEND_UNSIGNED<  0. ?It turns out that it is also needed >> >  for all Pmode != ptr_mode ca

Re: [PATCH] Fix PR48648: Handle CLAST assignments.

On 07/28/2011 06:56 PM, Sebastian Pop wrote: Hi Tobi, On Thu, Jul 28, 2011 at 12:13, Tobias Grosser wrote: + struct clast_user_stmt *body += clast_get_body_of_loop ((struct clast_stmt *) stmt); I am not a big fan of using clast_get_body_of_loop as it is buggy. Introducing new uses of it

Re: [RS6000] asynch exceptions and unwind info

On 07/28/2011 12:27 AM, Alan Modra wrote: > On Wed, Jul 27, 2011 at 03:00:45PM +0930, Alan Modra wrote: >> Ideally what I'd like to >> do is have ld and gcc emit accurate r2 tracking unwind info and >> dispense with hacks like frob_update_context. If ld did emit accurate >> unwind info for .glink,

Re: PATCH: PR middle-end/49721: convert_memory_address_addr_space may generate invalid new insns

On Thu, Jul 28, 2011 at 8:32 PM, H.J. Lu wrote: >>> >  convert_memory_address_addr_space has a special PLUS/MULT case for >>> >  POINTERS_EXTEND_UNSIGNED<  0. ?It turns out that it is also needed >>> >  for all Pmode != ptr_mode cases. ?OK for trunk? >>> >  2011-06-11 ?H.J. Lu ? >

Re: PATCH: PR target/47766: [x32] -fstack-protector doesn't work

On Thu, Jul 28, 2011 at 8:13 PM, H.J. Lu wrote: > This patch adds x32 support to UNSPEC_SP_XXX patterns.  OK for trunk? http://gcc.gnu.org/contribute.html#patches Uros.

Re: PATCH: PR middle-end/49721: convert_memory_address_addr_space may generate invalid new insns

On Thu, Jul 28, 2011 at 11:49 AM, Uros Bizjak wrote: > On Thu, Jul 28, 2011 at 8:32 PM, H.J. Lu wrote: > >  convert_memory_address_addr_space has a special PLUS/MULT case for >  POINTERS_EXTEND_UNSIGNED<  0. ?It turns out that it is also needed >  for all Pmode != ptr_m

Re: [RS6000] asynch exceptions and unwind info

On Thu, Jul 28, 2011 at 2:49 PM, Richard Henderson wrote: > The whole problem is that toc pointer copy in 40(1) is only valid > during indirect call sequences, and iff ld inserted a stub?  I.e. > direct calls between functions that share toc pointers never save > the copy? > > Would it make sense

Re: PATCH: PR target/47766: [x32] -fstack-protector doesn't work

On Thu, Jul 28, 2011 at 11:55 AM, Uros Bizjak wrote: > On Thu, Jul 28, 2011 at 8:13 PM, H.J. Lu wrote: > >> This patch adds x32 support to UNSPEC_SP_XXX patterns.  OK for trunk? > > http://gcc.gnu.org/contribute.html#patches > Sorry. I should have mentioned testcase in: http://gcc.gnu.org/bugzi

Re: [RS6000] asynch exceptions and unwind info

On 07/28/2011 12:02 PM, David Edelsohn wrote: > The other problem is hoisting the store into the prologue is not > always profitable for performance. It should be better once shrink > wrapping is implemented. Currently the PPC ABI may perform a lot of > stores in the prologue if the function *may

Re: [PATCH] [google] [annotalysis] Fix remove operation from pointer_set in case of hash collisions

On 07/26/2011 04:13 PM, Delesley Hutchins wrote: > This patch fixes a bug in pointer_set.c, where removing a pointer from > a pointer set would corrupt the hash table if the pointer was involved > in any hash collisions. > > Bootstrapped and passed gcc regression testsuite on x86_64-unknown-linux-

Re: [PATCH] Improve call site argument debug info for floating point stack arguments (PR debug/49846)

On 07/26/2011 01:19 PM, Jakub Jelinek wrote: > PR debug/49846 > * var-tracking.c (prepare_call_arguments): For non-MODE_INT stack > arguments also check if they aren't initialized with a MODE_INT > mode of the same size. Ok. r~

Re: [patch] arm,rx: don't ICE on naked functions with local vars

On 07/26/2011 12:52 PM, DJ Delorie wrote: > This patch tests for at least one user-caused reason for this > assertion failing - requiring a local frame in a naked function. For > this case at least, it would be better to trigger an error than to > ICE. OK? > > static int bar; > void __attribute_

Re: [PATCH, PR 49886] Prevent fnsplit from changing signature when there are type attributes

On Thu, Jul 28, 2011 at 6:52 PM, Martin Jambor wrote: > Hi, > > pass_split_functions is happy to split functions which have type > attributes but cannot update them if the new clone has in any way > different parameters than the original.  This can lead to > miscompilations in cases like the testc

Re: [PATCH PR43513, 1/3] Replace vla with array - Implementation.

On Thu, Jul 28, 2011 at 7:20 PM, Tom de Vries wrote: > On 07/28/2011 06:25 PM, Richard Guenther wrote: >> On Thu, 28 Jul 2011, Tom de Vries wrote: >> >>> On 07/28/2011 12:22 PM, Richard Guenther wrote: On Wed, 27 Jul 2011, Tom de Vries wrote: > On 07/27/2011 05:27 PM, Richard Guenthe

PATCH: Add x32 support to libgomp

Hi, This patch fixes 2 issues in libgomp for x32: 1. x32 should use the same futex functions as x86-64. 2. IA32 tests should check ia32 instead of ilp32. OK for trunk? Thanks. H.J. --- 2011-07-28 H.J. Lu * config/linux/x86/futex.h: Check __x86_64__ instead of __LP64__.

Re: [C++0x] contiguous bitfields race implementation

if (TREE_CODE (to) == COMPONENT_REF && DECL_BIT_FIELD_TYPE (TREE_OPERAND (to, 1))) get_bit_range (&bitregion_start,&bitregion_end, to, tem, bitpos, bitsize); and shouldn't this test DECL_BIT_FIELD instead of DECL_BIT_FIELD_TYPE? As I mention

Re: [trans-mem] Beginning of refactoring

On Thu, 2011-07-28 at 09:02 -0700, Richard Henderson wrote: > > Add information to dispatch about closed nesting and uninstrumented > > code. > > > > * dispatch.h (GTM::abi_dispatch): Add > > can_run_uninstrumented_code and > > closed_nesting flags, as well as a c

Re: Remove unused line_maps field last_listed (issue4810058)

Hello Gabriel, gch...@google.com (Gabriel Charette) a écrit: > 2011-07-28 Gabriel Charette > > * libcpp/include/line-map.h (struct line_maps): > Remove unused field last_listed. > I cannot approve or reject this patch, but FWIW, it looks good (and obvious) to me. I am CC-ing

Re: [patch] arm,rx: don't ICE on naked functions with local vars

Naked is related to TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS - ARM and RX set the latter based on the former, and nobody else uses that target hook. So, naked functions don't have stack slots for args. Without stack slots, args can't be assigned to memory locations - even if they're TREE_ADDRESSABLE

Re: Remove unused line_maps field last_listed (issue4810058)

> "Gabriel" == Gabriel Charette writes: Gabriel> 2011-07-28 Gabriel Charette Gabriel>* libcpp/include/line-map.h (struct line_maps): Gabriel> Remove unused field last_listed. Ok. Tom

Re: [C++0x] contiguous bitfields race implementation

On Thu, Jul 28, 2011 at 9:12 PM, Aldy Hernandez wrote: > >> Yes.  Together with the above it looks then optimal. > > Attached patch tested on x86-64 Linux. > > OK for mainline? Ok with the || moved to the next line as per coding-standards. Thanks, Richard.

PATCH: Fix config/i386/morestack.S for x32

Hi Ian, x32 is similar to x86-64 with 32bit pointer size. This patch adds x32 support to config/i386/morestack.S. Tested on x32. OK for trunk? Thanks. H.J. --- 2011-07-28 H.J. Lu * config/i386/morestack.S: Properly save the x32 new stack boundary. Properly check __x86_64_

PATCH: Use long long for 64bit int in config/i386/64/sfp-machine.h

Hi Ian, For 64bit x86 targets, long is 32bit for x32 and win64. But long long is always 64bit. This patch removes _WIN64 check. OK for trunk? Thanks. H.J. --- 2010-07-28 H.J. Lu * config/i386/64/sfp-machine.h (_FP_W_TYPE): Always use _WIN64 version. (_FP_WS_TYPE):

  1   2   >