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

Ok, you removed ignore_address_wrap_around, so we're almost there. On 07/28/2011 07:59 PM, H.J. Lu wrote: @@ -712,7 +715,16 @@ convert_modes (enum machine_mode mode, enum machine_mode oldmode, rtx x, int uns if (GET_CODE (x) == SUBREG&& SUBREG_PROMOTED_VAR_P (x) && GET_MODE_SIZE (

[google] Backport r175347 from trunk to google/gcc-4_6 (issue4835041)

Hi This trunk patch fixed a test failure in target arm. So I want to backport it to google/gcc-4_6. Tested on both x86 and arm with make check-gcc RUNTESTFLAGS="--target_board=arm-sim/arch=armv7-a tree-ssa.exp=asm-1.c" make check-gcc RUNTESTFLAGS="tree-ssa.exp=asm-1.c" OK for google/gcc-4_6? t

[PATCH] Use HOST_WIDE_INTs in gcd and least_common_multiple.

Hi Richi, On Mon, 31 Jan 2011, Richard Guenther wrote: > On Fri, Jan 28, 2011 at 9:31 PM, Sebastian Pop wrote: > > Hi Joseph, > > > > Thanks for your careful review. =A0This patch fixes the remaining > > problems. =A0The patch passed regstrap on amd64-linux. =A0Ok for trunk? > I don't think addi

PATCH: Add a testcase for PR rtl-optimization/47958

PR rtl-optimization/47958 is fixed now. I checked in this patch to add a testcase. H.J. --- Index: gcc.dg/torture/pr47958-1.c === --- gcc.dg/torture/pr47958-1.c (revision 0) +++ gcc.dg/torture/pr47958-1.c (revision 0) @@ -0,0 +1,13

[google] Do not declare pmu and sampling rate related vars for profile-use build (issue4832042)

The following trivial patch will be applied to google branches. Bootstrap and tessted on x86-64/linux 2011-07-28 David Li * coverage.c (coverage_init): Remove checking of profile-use flags. Index: coverage.c === -

Re: [pph] Free buffers used during tree encoding/decoding

On Thu, Jul 28, 2011 at 16:30, Lawrence Crowl wrote: > I'm getting massive failures after incorporating this change: > >   bytecode stream: trying to read 1735 bytes after the end of the >   input buffer > > where the number of bytes changes.  Suggestions? Odd. I'm getting the usual results with

Re: [RS6000] asynch exceptions and unwind info

On Thu, Jul 28, 2011 at 12:09:51PM -0700, Richard Henderson wrote: > Well, even if we're not able to hoist the R2 store, we may be able > to simply add REG_CFA_OFFSET and REG_CFA_RESTORE notes to the insns > in the stream. You'd need to mark every non-local call with something that says R2 may be

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

"H.J. Lu" writes: > On Thu, Jul 28, 2011 at 1:07 PM, Richard Henderson wrote: >> On 07/28/2011 12:42 PM, H.J. Lu wrote: >>> +#ifdef __LP64__ >>>       movq    %rax,%fs:0x70           # Save the new stack boundary. >>> +#else >>> +     movl    %eax,%fs:0x40           # Save the new stack boundary

Re: [pph] Put tinst_level list in forward order (issue4823059)

LGTM http://codereview.appspot.com/4823059/

RE: PING: [PATCH, ARM, iWMMXt][5/5]: pipeline description

Ping. http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01106.html At 2011-07-14 15:50:55,"Xinyu Qi" wrote: > > > Hi, > > > > It is the fifth part of iWMMXt maintenance. > > > > *config/arm/t-arm (MD_INCLUDES): Add marvell-f-iwmmxt.md. > *config/arm/marvell-f-iwmmxt.md: New file. > *config/arm/arm.

RE: PING: [PATCH, ARM, iWMMXt][4/5]: WMMX machine description

Ping. http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01105.html At 2011-07-14 15:45:09,"Xinyu Qi" wrote: > > Hi, > > > > It is the fourth part of iWMMXt maintenance. > > > > Since "*cond_iwmmxt_movsi_insn" would be got rid of soon, I keep it unchanged. > > *config/arm/arm.c (arm_output_iwmmxt_sh

RE: PING: [PATCH, ARM, iWMMXt][3/5]: built in define and expand

Ping. http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01103.html At 2011-07-14 15:38:47,"Xinyu Qi" wrote: > > Hi, > > > > It is the third part of iWMMXt maintenance. > > > > *config/arm/arm.c (enum arm_builtins): Built-in fcode. > (builtin_description bdesc_2arg): Built in declare. > (builtin_d

RE: PING: [PATCH, ARM, iWMMXt][2/5]: intrinsic head file change

Ping. http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01101.html At 2011-07-14 15:38:04,"Xinyu Qi" wrote: > > Hi, > > > > It is the second part of iWMMXt maintenance. > > > *config/arm/mmintrin.h: Revise. > > Thanks, > Xinyu

RE: PING: [PATCH, ARM, iWMMXt][1/5]: ARM code generic change

Ping. http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01100.html At 2011-07-14 15:35:52,"Xinyu Qi" wrote: > > > Hi, > > > > > > It is the first part of iWMMXt maintenance. > > > > > > *config/arm/arm.c (arm_option_override): > > > Enable iWMMXt with VFP. iWMMXt and NEON are incompatible. > > iWMM

Re: [PATCH] Handle vectorization of invariant loads (PR46787)

On Mon, Jul 4, 2011 at 6:28 AM, H.J. Lu wrote: > On Wed, Jun 29, 2011 at 4:19 AM, Richard Guenther wrote: >> >> The following patch makes us handle invariant loads during vectorization. >> Dependence analysis currently isn't clever enough to disambiguate them >> thus we insert versioning-for-alia

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

According to Richard, -march=armv7-a is not required. So the finally installed is: Index: gcc/ChangeLog === --- gcc/ChangeLog (revision 176910) +++ gcc/ChangeLog (working copy) @@ -1,3 +1,9 @@ +2011-07-29 Wei Guozhi +

Re: [RS6000] asynch exceptions and unwind info

On Thu, Jul 28, 2011 at 11:49:16AM -0700, Richard Henderson wrote: > 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

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

On Thu, Jul 28, 2011 at 4:25 PM, H.J. Lu wrote: > On Thu, Jul 28, 2011 at 3:46 PM, H.J. Lu wrote: >> On Thu, Jul 28, 2011 at 3:40 PM, Uros Bizjak wrote: >>> On Fri, Jul 29, 2011 at 12:28 AM, H.J. Lu wrote: >>> TP is 32bit in x32  For load_tp_x32, we load SImode value and >>

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

On 07/28/2011 04:40 AM, Richard Guenther wrote: field). Now, the question is of course what to do for DECL_PACKED fields (I suppose, simply ignore the C++ memory model as C++ doesn't have a notion of packed or specially (mis-)aligned structs or bitfields). I think treat them as bitfields for t

Re: [pph] Free buffers used during tree encoding/decoding

I'm getting massive failures after incorporating this change: bytecode stream: trying to read 1735 bytes after the end of the input buffer where the number of bytes changes. Suggestions? On 7/28/11, Diego Novillo wrote: > Noticed this while debugging the new tree encoding cache. No > f

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

On Thu, Jul 28, 2011 at 3:46 PM, H.J. Lu wrote: > On Thu, Jul 28, 2011 at 3:40 PM, Uros Bizjak wrote: >> On Fri, Jul 29, 2011 at 12:28 AM, 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

[pph] Put tinst_level list in forward order (issue4823059)

Place the tinst_level list in forward order. Tested on x64. Index: gcc/cp/ChangeLog.pph 2011-07-28 Lawrence Crowl * pt.c (pph_in_tinst_level): Put tinst_level list in forward order. Index: gcc/cp/pt.c === --- gcc/cp/

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

On Thu, Jul 28, 2011 at 3:40 PM, Uros Bizjak wrote: > On Fri, Jul 29, 2011 at 12:28 AM, 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.

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

On Fri, Jul 29, 2011 at 12:28 AM, 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 4/6] Shrink-wrapping

On 28/07/11 11:35, Bernd Schmidt wrote: > 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;

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

On Thu, Jul 28, 2011 at 3:03 PM, Uros Bizjak wrote: > On Thu, Jul 28, 2011 at 10:15 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

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

Thanks! Committed.

Re: [pph] Save pending and specialized templates (issue4814054)

On 7/26/11, Gabriel Charette wrote: >> +/* Load a tinst_level list. */ >> + >> +static struct tinst_level * >> +pph_in_tinst_level (pph_stream *stream) >> +{ >> + struct tinst_level *last = NULL; >> + unsigned count = pph_in_uint (stream); >> + /* FIXME pph: This leaves the list in reverse ord

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

On Thu, Jul 28, 2011 at 10:15 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. > Here

Re: PING: PATCH [8/n]: Prepare x32: PR other/48007: Unwind library doesn't work with UNITS_PER_WORD > sizeof (void *)

Hi Richard, Jason, Is this patch http://gcc.gnu.org/ml/gcc-patches/2011-06/msg02401.html OK for trunk? Thanks. H.J. On Mon, Jul 11, 2011 at 3:21 PM, H.J. Lu wrote: > Ping. > > On Wed, Jul 6, 2011 at 2:20 PM, H.J. Lu wrote: >> PING. >> >> On Thu, Jun 30, 2011 at 1:47 PM, H.J. Lu wrote: >>>

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

On 07/28/2011 01:30 PM, DJ Delorie wrote: > Fails the same way with a parameter as with a local: > > int result; > void __attribute__((naked)) ISRFunction(int x) { >result = subFunction(&x); > } > > but I'm certainly open to a better explanation of how a user program > can trigger an ICE that

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

I believe that any after-the-fact attempt to recover bitfield boundaries is going to fail unless you preserve more information during bitfield layout. Consider struct { char : 8; char : 0; char : 8; }; where the : 0 isn't preserved in any way and you can't distinguish it from struct

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

On Thu, 2011-07-28 at 22:46 +0200, Paolo Carlini wrote: > Hi, > > > I ran into this problem on the IA64 HP-UX bootstrap and tried your > > patch to semantics.c. It fixed the problem for me and I was able > > to bootstrap. > > Thanks Steve. I say let's commit it, I'm pretty sure it's by and large

Re: [PATCH] Optimize minloc (rank1array) and maxloc (rank1array) (PR fortran/31067)

Jakub Jelinek wrote: The minloc/maxloc intrinsics without DIM argument used on rank 1 arrays aren't inline optimized, because unlike their DIM=1 counterparts they return a rank 1 array with size 1. Handling that during genericization looked too hard to me, so instead this patch optimizes minloc

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

Hi, > I ran into this problem on the IA64 HP-UX bootstrap and tried your > patch to semantics.c. It fixed the problem for me and I was able > to bootstrap. Thanks Steve. I say let's commit it, I'm pretty sure it's by and large correct and anyway it unbreaks the bootstrap for many people. Can yo

[PATCH] Optimize minloc (rank1array) and maxloc (rank1array) (PR fortran/31067)

Hi! The minloc/maxloc intrinsics without DIM argument used on rank 1 arrays aren't inline optimized, because unlike their DIM=1 counterparts they return a rank 1 array with size 1. Handling that during genericization looked too hard to me, so instead this patch optimizes minloc (a) for rank 1 a i

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

Fails the same way with a parameter as with a local: int result; void __attribute__((naked)) ISRFunction(int x) { result = subFunction(&x); } but I'm certainly open to a better explanation of how a user program can trigger an ICE that way. Hmmm... the only use of targetm.calls.allocate_stack

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

On 07/28/2011 04:43 AM, Paolo Carlini wrote: /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, uni

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

Paolo, I ran into this problem on the IA64 HP-UX bootstrap and tried your patch to semantics.c. It fixed the problem for me and I was able to bootstrap. Steve Ellcey s...@cup.hp.com

Re: [Patch,AVR]: Fix PR29560 (map 16-bit shift to 8-bit)

On 07/27/2011 10:00 AM, Georg-Johann Lay wrote: > Richard Henderson wrote: >>> +;; "*ashluqihiqi3.mem" >>> +;; "*ashlsqihiqi3.mem" >>> +(define_insn_and_split "*ashlqihiqi3.mem" >>> + [(set (match_operand:QI 0 "memory_operand" "=m") >>> +(subreg:QI (ashift:HI (any_extend:HI (match_operand:

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

On 07/28/2011 12:42 PM, H.J. Lu wrote: > +#ifdef __LP64__ > movq%rax,%fs:0x70 # Save the new stack boundary. > +#else > + movl%eax,%fs:0x40 # Save the new stack boundary. > +#endif Please macro-ize this. r~

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

On 07/28/2011 12:45 PM, H.J. Lu wrote: > * config/i386/64/sfp-machine.h (_FP_W_TYPE): Always use _WIN64 > version. > (_FP_WS_TYPE): Likewise. > (_FP_I_TYPE): Likewise. Ok. r~

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

On Thu, Jul 28, 2011 at 9:03 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/bugzilla/show_bug.cgi?id=47766 > > Actually, they ar

Re: [trans-mem] Beginning of refactoring

On 07/28/2011 12:36 PM, Torvald Riegel wrote: > No, this is correct because it calls the factory function in libitm_i.h. > However, the classes in method-serial.cc were named differently than > those factory functions, so I renamed them like this: > > -class serial_dispatch : public abi_dispatch >

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

On 07/28/2011 12:38 PM, DJ Delorie wrote: > 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 me

Re: PATCH: Add x32 support to libgomp

On Thu, Jul 28, 2011 at 12:45 PM, Jakub Jelinek wrote: > On Thu, Jul 28, 2011 at 12:32:26PM -0700, H.J. Lu wrote: >> This patch fixes 2 issues in libgomp for x32: >> >> 1. x32 should use the same futex functions as x86-64. > > What kind of syscalls is -mx32 using on Linux?  I thought it was using

Re: PATCH: Add x32 support to libgomp

On Thu, Jul 28, 2011 at 12:32:26PM -0700, H.J. Lu wrote: > This patch fixes 2 issues in libgomp for x32: > > 1. x32 should use the same futex functions as x86-64. What kind of syscalls is -mx32 using on Linux? I thought it was using the -m32 compat layer, isn't that the case? If it works proper

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

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_

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.

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

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

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

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

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.

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

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

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

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

[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

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

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

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

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 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: [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: [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: 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: 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] 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] Fix -gdwarf-3 DW_AT_data_member_location for >= 64KB offsets (PR debug/49871)

OK. Jason

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

[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

  1   2   >