[patch] Fix PR tree-optimization/49038

Hi, The vectorizer supports strided loads with gaps, e.g., when only a[4i] and a[4i+2] are accessed, it generates a vector load a[4i:4i+3], i.e., creating an access to a[4i+3], which doesn't exist in the scalar code. This access maybe invalid as described in the PR. This patch creates an epilogue

Re: ICE with -fgraphite-opencl-ignore-dep

On 05/24/2011 10:21 PM, Sebastian Pop wrote: Hi Alexey, Thanks again for the cleanup patch. While I was testing the change, I found out that there are some flag combinations that are iceing the compiler. Could you please have a look at this PR: http://gcc.gnu.org/PR49147 Thanks, Sebastian

Re: [ARM] TLS Descriptor support

On 05/10/11 07:49, Nathan Sidwell wrote: This patch implements TLS descriptor support in GCC. TLS descriptors are described at http://www.codesourcery.com/publications/RFC-TLSDESC-ARM.txt and blessed by ARM, who have reserved the relocation numbers. http://gcc.gnu.org/ml/gcc-patches/2011-05/msg

Re: RFA: another patch to solve PR49154

On Wed, 25 May 2011, Vladimir Makarov wrote: > On 11-05-25 6:58 PM, Hans-Peter Nilsson wrote: > > On Wed, 25 May 2011, Vladimir Makarov wrote: > > > > > This patch solves http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49154 for > > > CRIS. > > > The problem was in that the pressure classes did not con

Re: PATCH: Add pause intrinsic

On 25/05/11 20:17, Basile Starynkevitch wrote: > On Wed, 25 May 2011 11:26:51 +0100 > Andrew Haley wrote: > >> On 05/24/2011 07:28 PM, H.J. Lu wrote: >> >>> This patch implements pause intrinsic suggested by Andi. OK >>> for trunk? >> >> What does "full memory barrier" here mean? >> >> +@table @

Re: [google] Disable getpagesize() for Android toolchain (issue4515131)

Hi I've tested the #ifndef __ANDROID__ on arm qemu without regression. And also built Android toolchain without this error. thanks Carrot 2011-05-26 Jing Yu * ChangeLog.google-main: New file. * getpagesize.c(getpagesize): Disable it for bionic. Index: ChangeLog.google-ma

Re: New options to disable/enable any pass for any functions (issue4550056)

On Wed, May 25, 2011 at 6:53 PM, Joseph S. Myers wrote: > On Wed, 25 May 2011, Xinliang David Li wrote: > >> Ping. The link to the message: >> >> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01303.html > > I don't consider this an option handling patch.  Patches adding whole new > features involvi

Re: [PATCH] Fix VRP switch handling (PR tree-optimization/49161)

On Wed, May 25, 2011 at 7:21 PM, Jakub Jelinek wrote: > Hi! > > The following testcase is miscompiled, because there are multiple > CASE_LABELs for the same target bb in a switch: > : >  switch (x_1(D)) , case 3: l4, case 4: l1, case 6: l3> > > l3: >  bar (-1); > > l2: > l1: > l4: >  bar (0); > >

Fix missing function declaration warnings in yesterday's libobjc patch

This patch fixes a problem with the patch from Richard/David that was committed yesterday; presumably since the patch was originally written before the new libobjc API revamp, it was still using objc_lookup_class(), which is not part of the Modern API, hence currently undeclared in sendmsg.c. I

Re: [PATCH] More pow(x,c) expansions in cse_sincos pass (PR46728, patch 3)

On Wed, May 25, 2011 at 7:43 PM, William J. Schmidt wrote: > This patch adds logic to gimple_expand_builtin_pow () to optimize > pow(x,y), where y is one of 0.5, 0.25, 0.75, 1./3., or 1./6.  I noticed > that there were two missing calls to gimple_set_location () in my > previous patch, so I've cor

Re: [testsuite] remove XFAIL for all but ia64 for g++.dg/tree-ssa/pr43411.C

On Wed, May 25, 2011 at 8:03 PM, Mike Stump wrote: > On May 25, 2011, at 1:38 AM, Rainer Orth wrote: >> Janis Johnson writes: >> >>> Archived test results for 4.7.0 for most processors with C++ results have: >>> >>> XPASS: g++.dg/tree-ssa/pr43411.C scan-tree-dump-not optimized "OBJ_TYPE_REF" >>>

Re: [PATCH, testsuite] Additional tests for PR46728 (PR46728 patch 4)

On Wed, May 25, 2011 at 9:45 PM, William J. Schmidt wrote: > Since I'm in process of moving the lowering of pow and powi calls from > expand into gimple, I wrote some tests to improve coverage in this area. > Most of these look for specific code generation patterns in PowerPC > assembly where the

libobjc - indentation patch for sendmsg.c

Applied to trunk. Thanks Index: ChangeLog === --- ChangeLog (revision 174268) +++ ChangeLog (working copy) @@ -1,5 +1,10 @@ 2011-05-26 Nicola Pero + * sendmsg.c: Reindented part of the file. No non-trivial changes +

Better location streaming

Hi, we spend a lot of effort (and disk space) into streaming file/line/column and sys_p fields of locations. Since often the trees come from same statement, it is common for those to not change. We even already have current location info in output_block and data_in, but don't use it. This patch u

Re: PATCH: Add pause intrinsic

On Wed, May 25, 2011 at 7:19 PM, H.J. Lu wrote: > On Wed, May 25, 2011 at 9:43 AM, Andrew Haley wrote: >> On 05/25/2011 04:32 PM, H.J. Lu wrote: >>> On Wed, May 25, 2011 at 8:27 AM, Richard Guenther >>> wrote: On Wed, May 25, 2011 at 5:20 PM, Michael Matz wrote: > Hi, > > On We

Re: Better location streaming

On Thu, May 26, 2011 at 11:34 AM, Jan Hubicka wrote: > Hi, > we spend a lot of effort (and disk space) into streaming file/line/column and > sys_p fields of locations. Since often the trees come from same statement, it > is common for those to not change.  We even already have current location inf

[patch gimplify]: Make sure comparison using boolean-type after gimplification

Hello, this patch ensures that after gimplification also comparison expressions using FE's boolean_type_node. As we need to deal here with C/C++'s (obj-c/c++ and java's), Ada's, and Fortran's specific boolean types, this patch alters some checks in tree-cfg for Ada's sake, and we need to deal

RE: [PATCH] Fix PR target/48807

Ping Ping. -Original Message- From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On Behalf Of Henderson, Stuart Sent: 19 May 2011 13:39 To: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Fix PR target/48807 Ping http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00503.htm

[testsuite] Require TLS support with tree profiling (PR gcov-profile/48845)

Prompted by the recent tree profiling testsuite failures on platforms that require special handling for TLS runtime support, I looked at the testsuite side of things. While Solaris now works again thanks to Eric's patch http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01719.html there should

[PATCH] Handle C++ x ? y : throw 1 COND_EXPRs in shortcut_cond_r (PR c++/49165)

Hi! The C++ FE creates COND_EXPRs which have non-void type and the same type on one of the arms, but the other arm is THROW_EXPR (which has void type). gimplify_cond_expr knows how to gimplify this, but shortcut_cond_r tried to optimize if (a ? b : throw 1) goto yes; else goto no; into if (a) if

Re: Go patch committed: Update to current Go library

Ian Lance Taylor writes: > Rainer Orth writes: > >> * While I get >> >> // var ___iob [59+1]___FILE >> >> now, there's still >> >> var __lastbuf *_FILE >> >> left, with commented >> >> // type _FILE struct { _cnt int32; _ptr *uint8; _base *uint8; _flag uint8; >> _file >> uint8; __orientati

Re: Better location streaming

> > This looks all very hackish with no immediate benefit mostly because > of the use of lto_output_string. I think what you should do instead > is split up lto_output_string_with_length into the piece that streams > the string itself to the string-stream and returns an index into it > and the pi

Re: [patch gimplify]: Make sure comparison using boolean-type after gimplification

On Thu, May 26, 2011 at 12:20 PM, Kai Tietz wrote: > Hello, > > this patch ensures that after gimplification also comparison expressions > using FE's boolean_type_node.  As we need to deal here with C/C++'s > (obj-c/c++ and java's), Ada's, and Fortran's specific boolean types, this > patch alte

Re: [build] Fix Solaris 2/x86 GD/LD TLS code sequences with Sun ld

Uros Bizjak writes: >> We could certainly duplicate (some of) the logic that %P already uses, >> but I though it easier to just introduce a straightforward variant (%p) >> instead.  It's not pretty, but it worked. > > OK then... can you propose a new patch, please, changing as little of > generic

Re: [patch gimplify]: Make sure comparison using boolean-type after gimplification

On Thu, May 26, 2011 at 12:46 PM, Richard Guenther wrote: > On Thu, May 26, 2011 at 12:20 PM, Kai Tietz wrote: >> Hello, >> >> this patch ensures that after gimplification also comparison expressions >> using FE's boolean_type_node.  As we need to deal here with C/C++'s >> (obj-c/c++ and java's

Re: Better location streaming

> > > > This looks all very hackish with no immediate benefit mostly because > > of the use of lto_output_string. I think what you should do instead > > is split up lto_output_string_with_length into the piece that streams > > the string itself to the string-stream and returns an index into it >

Re: Better location streaming

On Thu, May 26, 2011 at 12:45 PM, Jan Hubicka wrote: >> >> This looks all very hackish with no immediate benefit mostly because >> of the use of lto_output_string.  I think what you should do instead >> is split up lto_output_string_with_length into the piece that streams >> the string itself to t

Re: [patch gimplify]: Make sure comparison using boolean-type after gimplification

On Thu, May 26, 2011 at 12:46 PM, Richard Guenther wrote: > On Thu, May 26, 2011 at 12:20 PM, Kai Tietz wrote: >> Hello, >> >> this patch ensures that after gimplification also comparison expressions >> using FE's boolean_type_node.  As we need to deal here with C/C++'s >> (obj-c/c++ and java's

Re: [patch gimplify]: Make sure comparison using boolean-type after gimplification

2011/5/26 Richard Guenther : > On Thu, May 26, 2011 at 12:20 PM, Kai Tietz wrote: >> Hello, >> >> this patch ensures that after gimplification also comparison expressions >> using FE's boolean_type_node.  As we need to deal here with C/C++'s >> (obj-c/c++ and java's), Ada's, and Fortran's specif

Completing toplevel libgcc move (Was: Re: [SPARC] Hookize PRINT_OPERAND, PRINT_OPERAND_ADDRESS and PRINT_OPERAND_PUNCT_VALID_P)

"Joseph S. Myers" writes: > On Wed, 4 May 2011, Rainer Orth wrote: > >> Your expansion of the wiki page on toplevel libgcc migration is >> certainly welcome: I hadn't seen before that *-unwind.h files and >> related macros can be moved over as well. > > I've no idea whether they can be moved *at

Re: [patch gimplify]: Make sure comparison using boolean-type after gimplification

2011/5/26 Richard Guenther : > On Thu, May 26, 2011 at 12:46 PM, Richard Guenther > wrote: >> On Thu, May 26, 2011 at 12:20 PM, Kai Tietz wrote: >>> Hello, >>> >>> this patch ensures that after gimplification also comparison expressions >>> using FE's boolean_type_node.  As we need to deal here

Only expose sparc_solaris_elf_asm_named_section declaration on Solaris (PR target/49099)

As reported in the PR, mainline fails to build on non-Solaris SPARC targets. The following patch fixes this. Bootstrapped without regressions on sparc-sun-solaris2.11 with as and gas, tested with a i386-pc-solaris2.10 x sparc-elf cross with --enable-werror-always. Ok for mainline? Raine

Re: [patch gimplify]: Make sure comparison using boolean-type after gimplification

On Thu, May 26, 2011 at 1:05 PM, Kai Tietz wrote: > 2011/5/26 Richard Guenther : >> On Thu, May 26, 2011 at 12:20 PM, Kai Tietz wrote: >>> Hello, >>> >>> this patch ensures that after gimplification also comparison expressions >>> using FE's boolean_type_node.  As we need to deal here with C/C++

Re: [patch gimplify]: Make sure comparison using boolean-type after gimplification

On Thu, May 26, 2011 at 1:11 PM, Kai Tietz wrote: > 2011/5/26 Richard Guenther : >> On Thu, May 26, 2011 at 12:46 PM, Richard Guenther >> wrote: >>> On Thu, May 26, 2011 at 12:20 PM, Kai Tietz wrote: Hello, this patch ensures that after gimplification also comparison expressions

Re: [patch gimplify]: Make sure comparison using boolean-type after gimplification

2011/5/26 Richard Guenther : > On Thu, May 26, 2011 at 1:11 PM, Kai Tietz wrote: >> 2011/5/26 Richard Guenther : >>> On Thu, May 26, 2011 at 12:46 PM, Richard Guenther >>> wrote: On Thu, May 26, 2011 at 12:20 PM, Kai Tietz wrote: > Hello, > > this patch ensures that after gimpli

Re: [patch gimplify]: Make sure comparison using boolean-type after gimplification

On Thu, May 26, 2011 at 1:20 PM, Kai Tietz wrote: > 2011/5/26 Richard Guenther : >> On Thu, May 26, 2011 at 1:11 PM, Kai Tietz wrote: >>> 2011/5/26 Richard Guenther : On Thu, May 26, 2011 at 12:46 PM, Richard Guenther wrote: > On Thu, May 26, 2011 at 12:20 PM, Kai Tietz wrote: >>>

Re: [patch gimplify]: Make sure comparison using boolean-type after gimplification

2011/5/26 Richard Guenther : > On Thu, May 26, 2011 at 1:20 PM, Kai Tietz wrote: >> 2011/5/26 Richard Guenther : >>> On Thu, May 26, 2011 at 1:11 PM, Kai Tietz wrote: 2011/5/26 Richard Guenther : > On Thu, May 26, 2011 at 12:46 PM, Richard Guenther > wrote: >> On Thu, May 26, 20

Re: [patch gimplify]: Make sure comparison using boolean-type after gimplification

On Thu, May 26, 2011 at 1:28 PM, Kai Tietz wrote: > 2011/5/26 Richard Guenther : >> On Thu, May 26, 2011 at 1:20 PM, Kai Tietz wrote: >>> 2011/5/26 Richard Guenther : On Thu, May 26, 2011 at 1:11 PM, Kai Tietz wrote: > 2011/5/26 Richard Guenther : >> On Thu, May 26, 2011 at 12:46 PM

Re: [patch gimplify]: Make sure comparison using boolean-type after gimplification

2011/5/26 Richard Guenther : > On Thu, May 26, 2011 at 1:28 PM, Kai Tietz wrote: >> 2011/5/26 Richard Guenther : >>> On Thu, May 26, 2011 at 1:20 PM, Kai Tietz wrote: 2011/5/26 Richard Guenther : > On Thu, May 26, 2011 at 1:11 PM, Kai Tietz > wrote: >> 2011/5/26 Richard Guenthe

Re: [PATCH PR45098, 4/10] Iv init cost.

Hi Richard, On 05/25/2011 03:44 PM, Richard Sandiford wrote: > Sorry for being so late. I was just curious... > > Tom de Vries writes: >> The init cost of an iv will in general not be zero. It will be >> exceptional that the iv register happens to be initialized with the >> proper value at no c

Re: Better location streaming

> On Thu, May 26, 2011 at 12:45 PM, Jan Hubicka wrote: > >> > >> This looks all very hackish with no immediate benefit mostly because > >> of the use of lto_output_string.  I think what you should do instead > >> is split up lto_output_string_with_length into the piece that streams > >> the string

Re: Better location streaming

2011/5/26 Jan Hubicka : >> On Thu, May 26, 2011 at 12:45 PM, Jan Hubicka wrote: >> >> >> >> This looks all very hackish with no immediate benefit mostly because >> >> of the use of lto_output_string.  I think what you should do instead >> >> is split up lto_output_string_with_length into the piece

Re: [google] Disable getpagesize() for Android toolchain (issue4515131)

On Wed, 25 May 2011, Jing Yu wrote: > I am wondering how to disable build of libiberty for target? I Tear out all the target-libiberty code unconditionally? See and references therein; building target libiberty at all is a bug in my vie

Re: Better location streaming

> 2011/5/26 Jan Hubicka : > >> On Thu, May 26, 2011 at 12:45 PM, Jan Hubicka wrote: > >> >> > >> >> This looks all very hackish with no immediate benefit mostly because > >> >> of the use of lto_output_string.  I think what you should do instead > >> >> is split up lto_output_string_with_length in

Re: Prefixes for libgcc symbols (C6X 9.5/11)

It occurred to me to do another test, building libgcc with and without the patch and comparing the binaries. That showed a problem - if there are multiple version files, their order matters. In all cases where $$(libgcc_objdir)/libgcc-std.ver occurs, it occurs first, so I've changed the order in sr

Re: New options to disable/enable any pass for any functions (issue4550056)

On Thu, 26 May 2011, Richard Guenther wrote: > + if (is_enable) > +error ("unrecognized option -fenable"); > + else > +error ("unrecognized option -fdisable"); > > I think that should be fatal_error - Joseph? No, all existing errors for unknown options are ordinary erro

Re: Better location streaming

2011/5/26 Jan Hubicka : >> 2011/5/26 Jan Hubicka : >> >> On Thu, May 26, 2011 at 12:45 PM, Jan Hubicka wrote: >> >> >> >> >> >> This looks all very hackish with no immediate benefit mostly because >> >> >> of the use of lto_output_string.  I think what you should do instead >> >> >> is split up lt

Re: Completing toplevel libgcc move (Was: Re: [SPARC] Hookize PRINT_OPERAND, PRINT_OPERAND_ADDRESS and PRINT_OPERAND_PUNCT_VALID_P)

On Thu, 26 May 2011, Rainer Orth wrote: > But doesn't this mean that e.g. MD_UNWIND_SUPPORT can only be moved to > libgcc/config for all targets together? How can you poison the macro > when a single target using it is left behind in gcc/config? Nothing about the libgcc_tm.h implementation stops

[PATCH, picochip] cbranch pattern change

Hello all, The gimple->rtl expander phase now expects cbranch to not have a :CC after the match operator. This is the case for cbranch for all the other ports anyway, so now picochip matches this pattern. Committed to mainline as ChangeLog: * config/picochip/picochip.md (cbranchhi4):

[Patch, AVR, 4.6] PR target/44643

This is a straight forward 4.7 -> 4.6 backport for PR44643 http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00544.html http://gcc.gnu.org/viewcvs?view=revision&revision=172415 Johann PR target/44643 * config/avr/avr.c (avr_insert_attributes): Leave TREE_READONLY alone. Error if non-

Re: Completing toplevel libgcc move

"Joseph S. Myers" writes: > On Thu, 26 May 2011, Rainer Orth wrote: > >> But doesn't this mean that e.g. MD_UNWIND_SUPPORT can only be moved to >> libgcc/config for all targets together? How can you poison the macro >> when a single target using it is left behind in gcc/config? > > Nothing about

Re: Only expose sparc_solaris_elf_asm_named_section declaration on Solaris (PR target/49099)

> 2011-05-24 Rainer Orth > > PR target/49099 > * config/sparc/sparc.c (sparc_solaris_elf_asm_named_section): Wrap > declaration in TARGET_SOLARIS. OK, thanks. -- Eric Botcazou

RE: [Patch, AVR, 4.6] PR target/44643

> -Original Message- > From: Georg-Johann Lay [mailto:a...@gjlay.de] > Sent: Thursday, May 26, 2011 6:24 AM > To: gcc-patches@gcc.gnu.org > Cc: Weddington, Eric; Anatoly Sokolov; Denis Chertykov > Subject: [Patch, AVR, 4.6] PR target/44643 > > This is a straight forward 4.7 -> 4.6 backpo

Re: [SPARC] Disable -fira-share-save-slots by default

> It's the new slot sharing code that doesn't have support for saving > larger hunks. Having written the original code to handle larger saves > specifically to help sparc, I can certainly understand why the new code > is causing you grief :-) Thanks for the historical perspective. :-) > No objec

Re: [Patch, Fortran] -fcoarray=lib - add registering calls for nonallocatable coarrays

Dear Tobias, This looks fine to me. It does the things that you described and is well hidden behind the co-array associated conditions. Thus it is OK for trunk. Maybe I am being stupid but what is the call, in the testcase, to subroutine test for? Cheers Paul

[PATCH] Fix PR48702

This patch fixes PR48702. IVOPTs does not guarantee that the base addresses it uses for memory accesses is within the bounds that the C standard (and the middle-end) would allow. Thus, make sure that for those bases where we cannot guarantee this we use TARGET_MEM_REF instead of MEM_REF and rela

C++ PATCH for c++/48424 (function parameter packs not at the end of the list)

The initial specification of variadic templates required function parameter packs to be at the end of the parameter list, but that restriction was soon found to be undesirable; this patch updates G++ to support packs earlier in the parameter list as specified in the FDIS. Tested x86_64-pc-linu

Re: [PATCH] Fix PR target/48807

On 05/19/2011 12:39 PM, Henderson, Stuart wrote: > * config/bfin/bfin.c: Check return value of cgraph_local_info for null > before > attempting to use it. Needs to mention the function name, and wrap the long line properly. > Index: gcc/config/bfin/bfin.c > ==

Re: [PATCH] Handle C++ x ? y : throw 1 COND_EXPRs in shortcut_cond_r (PR c++/49165)

On 05/26/2011 06:32 AM, Jakub Jelinek wrote: gimplify_cond_expr knows how to gimplify this, but shortcut_cond_r tried to optimize if (a ? b : throw 1) goto yes; else goto no; into if (a) if (b) goto yes; else goto no; else if (throw 1) goto yes; else goto no; which ICEs or errors out. Fixe

Re: PATCH: Add pause intrinsic

On 05/26/2011 10:34 AM, Richard Guenther wrote: >> Index: doc/extend.texi >> === >> --- doc/extend.texi (revision 174216) >> +++ doc/extend.texi (working copy) >> @@ -8699,7 +8699,8 @@ The following built-in function is alway

Re: C6X port 9/11: Allow defining attributes in terms of another

On 05/25/2011 01:45 PM, Hans-Peter Nilsson wrote: > On Wed, 25 May 2011, Bernd Schmidt wrote: > >> I'm not sure where you're looking for added documentation for this >> patch. > > I guess no surprise that'd be md.texi node Defining Attributes, That covers define_attr, not set_attr, so it seems i

Re: Fix PR 49014

On 25.05.2011 19:31, Bernd Schmidt wrote: On 05/25/2011 03:29 PM, Andrey Belevantsev wrote: I think the hook is a better idea than the attribute because nobody will care to mark all offending insns with an attribute. I don't know. IIRC when I looked at sh or whatever the broken port was, it wa

Re: [patch][simplify-rtx] Fix 16-bit -> 64-bit multiply and accumulate

On 25/05/11 14:47, Joseph S. Myers wrote: The shift must be by a positive constant amount, strictly less than the precision (GET_MODE_PRECISION) of the mode (of the value being shifted). If that applies, the relevant number of bits is the precision of the mode minus the number of bits of the shif

Re: [PATCH PING] unreviewed tree-slimming patches

On 05/25/2011 10:21 PM, Nathan Froyd wrote: An alternative solution would be to initialize cur_stmt_list somewhere with an actual 1-element VEC; Or just push NULL onto the stack and let append_to_statement_list_1 allocate the VEC? the check in add_stmt would then be unnecessary, as we'd alw

Re: [PATCH] Handle C++ x ? y : throw 1 COND_EXPRs in shortcut_cond_r (PR c++/49165)

On Thu, May 26, 2011 at 09:26:58AM -0400, Jason Merrill wrote: > On 05/26/2011 06:32 AM, Jakub Jelinek wrote: > >gimplify_cond_expr knows how to gimplify this, but shortcut_cond_r > >tried to optimize > >if (a ? b : throw 1) goto yes; else goto no; > >into > >if (a) > > if (b) goto yes; else goto

Re: [PATCH] Handle C++ x ? y : throw 1 COND_EXPRs in shortcut_cond_r (PR c++/49165)

On 05/26/2011 09:41 AM, Jakub Jelinek wrote: That is how it ends up being optimized later on, I just think given how long the bug has been in this is so rare that we don't need to try to optimize it already at the gimplifier level. Makes sense. Jason

RFC: explicitely mark out-of-scope deaths

Hi, on IRC we discussed about this, here's the RFC patch. It bootstraps and causes some minor regressions most probably due to some missing sprinkled checks for the special clobber insns and sometimes due to having to adjust some regexps. Anyway, stack slot sharing is currently using the heur

Re: [PATCH PING] unreviewed tree-slimming patches

On 05/26/2011 09:39 AM, Jason Merrill wrote: > On 05/25/2011 10:21 PM, Nathan Froyd wrote: >> An alternative solution would be to initialize cur_stmt_list somewhere with >> an >> actual 1-element VEC; > > Or just push NULL onto the stack and let append_to_statement_list_1 allocate > the VEC? Did

[PATCH] Remove bogus fold code

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk. Richard. 2011-05-26 Richard Guenther * fold-const.c (fold_unary_loc): Remove bogus code. Index: gcc/fold-const.c === --- gcc/fold-const.c(revisi

Re: [PATCH PING] unreviewed tree-slimming patches

On 05/26/2011 09:46 AM, Nathan Froyd wrote: On 05/26/2011 09:39 AM, Jason Merrill wrote: On 05/25/2011 10:21 PM, Nathan Froyd wrote: An alternative solution would be to initialize cur_stmt_list somewhere with an actual 1-element VEC; Or just push NULL onto the stack and let append_to_statemen

Re: PATCH: Add pause intrinsic

On Thu, May 26, 2011 at 3:30 PM, Andrew Haley wrote: > On 05/26/2011 10:34 AM, Richard Guenther wrote: > >>> Index: doc/extend.texi >>> === >>> --- doc/extend.texi     (revision 174216) >>> +++ doc/extend.texi     (working copy) >>> @

Re: PATCH: Add pause intrinsic

On 05/26/2011 02:51 PM, Richard Guenther wrote: > On Thu, May 26, 2011 at 3:30 PM, Andrew Haley wrote: >> On 05/26/2011 10:34 AM, Richard Guenther wrote: >> Index: doc/extend.texi === --- doc/extend.texi (revision 1

Re: [patch][simplify-rtx] Fix 16-bit -> 64-bit multiply and accumulate

On Thu, 26 May 2011, Andrew Stubbs wrote: > On 25/05/11 14:47, Joseph S. Myers wrote: > > The shift must be by a positive constant amount, strictly less than the > > precision (GET_MODE_PRECISION) of the mode (of the value being shifted). > > If that applies, the relevant number of bits is the pre

Re: RFC: explicitely mark out-of-scope deaths

On Thu, May 26, 2011 at 03:43:45PM +0200, Michael Matz wrote: > --- tree-stdarg.c.orig2011-05-26 14:15:01.0 +0200 > +++ tree-stdarg.c 2011-05-26 14:15:41.0 +0200 > @@ -872,8 +872,12 @@ execute_optimize_stdarg (void) > if (get_gimple_rhs_class (gimple_assi

Re: [Patch, Fortran] -fcoarray=lib - add registering calls for nonallocatable coarrays

Dear Paul, thanks for the review. Regarding: Paul Thomas wrote: > Maybe I am being stupid but what is the call, in the > testcase, to subroutine test for? Well, it is supposed to test coarray decls in functions, contained functions, and in not-referenced functions. However, I forgot the [*] (

Re: RFC: explicitely mark out-of-scope deaths

On Thu, May 26, 2011 at 4:00 PM, Jakub Jelinek wrote: > On Thu, May 26, 2011 at 03:43:45PM +0200, Michael Matz wrote: >> --- tree-stdarg.c.orig        2011-05-26 14:15:01.0 +0200 >> +++ tree-stdarg.c     2011-05-26 14:15:41.0 +0200 >> @@ -872,8 +872,12 @@ execute_optimize_stdarg (v

Re: PATCH: Add pause intrinsic

On Thu, May 26, 2011 at 3:53 PM, Andrew Haley wrote: > On 05/26/2011 02:51 PM, Richard Guenther wrote: >> On Thu, May 26, 2011 at 3:30 PM, Andrew Haley wrote: >>> On 05/26/2011 10:34 AM, Richard Guenther wrote: >>> > Index: doc/extend.texi > ===

[PATCH][JAVA] Sanitize Java frontend global tree building

In preparation to move all frontends common tree node building to the middle-end this makes the Java frontend actually use the standard routines. It's still severely broken in overriding things with stuff that does not match the targets C ABI, but well, Java ... Bootstrapped and tested on x86_64

Re: PATCH: Add pause intrinsic

On Thu, May 26, 2011 at 04:29:50PM +0200, Richard Guenther wrote: > To make it a compiler memory barrier you have to "expand" the > builtin already in the frontend and present the middle-end with > __asm__ ("" : : : "memory"). That will serve as a compiler > memory barrier also covering local

Re: PATCH: Add pause intrinsic

On Thu, May 26, 2011 at 4:34 PM, Jakub Jelinek wrote: > On Thu, May 26, 2011 at 04:29:50PM +0200, Richard Guenther wrote: >> To make it a compiler memory barrier you have to "expand" the >> builtin already in the frontend and present the middle-end with >> __asm__ ("" : : : "memory").  That wi

Re: PATCH: Add pause intrinsic

On 05/26/2011 03:29 PM, Richard Guenther wrote: > On Thu, May 26, 2011 at 3:53 PM, Andrew Haley wrote: >> On 05/26/2011 02:51 PM, Richard Guenther wrote: >>> On Thu, May 26, 2011 at 3:30 PM, Andrew Haley wrote: On 05/26/2011 10:34 AM, Richard Guenther wrote: >> Index: doc/extend.tex

[PATCH] PR debug/49047 (linkage name missing for cdtors)

Hello, The constructors (resp. destructors) of a given class K are cloned. For each constructor (resp. destructor) There is thus an abstract version of the function and (at least) a concrete version that actually contains the code of the abstract version. The debug info generated for a constructo

Re: PATCH: Add pause intrinsic

Hi, On Thu, 26 May 2011, Andrew Haley wrote: > >>> +Generates the @code{pause} machine instruction. > >> > >> But that's missing the fact that it generates a compiler memory > >> barrier, which is important. And if you think it's not a compiler > >> memory barrier, please explain > >> > >> a.

[PATCH] Fix bug in uniquify_nodes reorg

I merged one if too eagerly, resulting in not fixing up the cache for merged types. Oops. LTO bootstrapped on x86_64-unknown-linux-gnu, testing and SPEC2k6 build in progress. Richard. 2011-05-26 Richard Guenther lto/ * lto.c (uniquify_nodes): Fix bug in one of the previous

Re: ICE with -fgraphite-opencl-ignore-dep

On Thu, May 26, 2011 at 03:11, Alexey Kravets wrote: > Here is the patch for this issue. > It is caused by the bug in opencl_get_perfect_nested_loop_depth. > This functions ignores  -fgraphite-opencl-ignore-dep flag while > opencl_transform_stmt_list considers this flag. > > This patch adds a new

Re: [testsuite] remove XFAIL for all but ia64 for g++.dg/tree-ssa/pr43411.C

On May 26, 2011, at 2:25 AM, Richard Guenther wrote: > The XPASS is suprious - that's the whole point of XPASSes. It should > FAIL (well, XFAIL). A patch making it PASS is bogus. There are deeper reasons for my position. Take a look at: http://google1.osuosl.org:8011/waterfall the idea is t

Re: [PATCH] PR debug/49047 (linkage name missing for cdtors)

Why not just call add_linkage_name after add_abstract_origin_attribute? Jason

Re: Libiberty: POSIXify psignal definition

> Yes please. I've been arguing for that for some time. Since you feel so strongly about it and nobody objects, go ahead. > http://gcc.gnu.org/ml/gcc/2009-04/msg00410.html > http://gcc.gnu.org/ml/gcc/2010-03/msg2.html > http://gcc.gnu.org/ml/gcc/2010-03/msg00012.html > http://gcc.gnu.org/ml

Re: Better location streaming

Hi, On Thu, 26 May 2011, Richard Guenther wrote: > > Hmm, I plan to optimize string streaming (since we always stream one > > uleb to set it is non-NULL that can be easilly handled by assigining > > NULL string index 0).  How precisely you however suggest to bitpack > > line/column and string

Re: [PATCH,c++] describe reasons for function template overload resolution failure

On 05/25/2011 02:15 PM, Nathan Froyd wrote: The patch below implements just such an idea. The only twist is that the `explain' parameter is actually a `location_t *' so that when we provide explanations that aren't produced via tf_warning_or_error blocks, the explanations are attached to the tem

Re: Faster streaming of enums

Hi, this is updated patch. For whatever reason we now end up with longer .o file for tramp3d than with my prevoius attempt (by 9KB). We need at average 15 bytes for location, well, the encoding of small ints might be better with uleb style, perhaps with smaller chunk (like 4 bits per chunk as oppo

Re: [PATCH, ARM] Unaligned accesses for packed structures [1/2]

On Mon, 9 May 2011 18:01:12 +0100 Julian Brown wrote: > How does this look now? (Re-testing in progress.) The previously-posted version contained a bug in the "extv" expander, which became apparent only when testing together with my fixed-point support patch. This is a corrected version. Re-tes

Re: [testsuite] remove XFAIL for all but ia64 for g++.dg/tree-ssa/pr43411.C

On Thu, May 26, 2011 at 5:16 PM, Mike Stump wrote: > On May 26, 2011, at 2:25 AM, Richard Guenther wrote: >> The XPASS is suprious - that's the whole point of XPASSes.  It should >> FAIL (well, XFAIL).  A patch making it PASS is bogus. > > There are deeper reasons for my position.  Take a look at:

Re: PATCH: Add pause intrinsic

Richard Guenther writes: > > To make it a compiler memory barrier you have to "expand" the > builtin already in the frontend and present the middle-end with > __asm__ ("" : : : "memory"). That will serve as a compiler Those are the intended semantics (at least those I asked for :-). For all

Re: PATCH: Add pause intrinsic

Basile Starynkevitch writes: > > Perhaps the doc might explain why is it necessary to have a builtin for > two independent roles: first, the full compiler memory barrier (which > probably means to spill all the registers on the stack - definitely a > task for a compiler); second, to "pause" the pr

Re: RFC: explicitely mark out-of-scope deaths

On Thu, May 26, 2011 at 3:43 PM, Michael Matz wrote: > on IRC we discussed about this, here's the RFC patch.  It bootstraps and > causes some minor regressions most probably due to some missing sprinkled > checks for the special clobber insns and sometimes due to having to adjust > some regexps.

Re: [PATCH] ARM fixed-point support [6/6]: target-specific parts

On Fri, 13 May 2011 17:31:18 +0100 Julian Brown wrote: > On Fri, 13 May 2011 14:54:47 + (UTC) > "Joseph S. Myers" wrote: > > > On Fri, 13 May 2011, Julian Brown wrote: > > > > > although Joseph's comments have (hopefully) all been addressed. > > > One must now configure with "--enable-fixe

Re: PATCH: Add pause intrinsic

On Thu, May 26, 2011 at 09:10:32AM -0700, Andi Kleen wrote: > Richard Guenther writes: > As for why having a builtin: one reason would be portability. You mean portability to other compilers (I think reasonable amount of them support gcc-ish inline asm), or to other architectures? __builtin_ia32_

Re: [PATCH] ARM fixed-point support [5/6]: make long-long support optional for fixed-point tests

On Fri, 13 May 2011 14:58:08 +0100 Julian Brown wrote: > This makes makes the requirement for "long long" fixed-point types > optional in the testsuite (fixed-point.exp tests), since they are > unsupported by the ARM backend. > > Tested alongside other patches in the series. OK to apply? This p

Re: PATCH: Add pause intrinsic

On Thu, 26 May 2011 09:12:06 -0700 Andi Kleen wrote: > Basile Starynkevitch writes: > > > > Perhaps the doc might explain why is it necessary to have a builtin for > > two independent roles: first, the full compiler memory barrier (which > > probably means to spill all the registers on the stack

  1   2   >