Re: [PATCH] don't use TYPE_ARG_TYPES in the Ada FE

> * gcc-interface/decl.c (intrin_arglists_compatible_p): Use iterators > instead of accessing TYPE_ARG_TYPES directly. > * gcc-interface/utils.c (handle_nonnull_attribute): Likewise. Probably fine, but please patch the C front-end first. I'm afraid that the coverage of this par

Re: [trunk][RFA] Add __i686.get_pc_thunk.bx to libgcc i386 morestack.S

On Tue, May 3, 2011 at 16:39, Chris Demetriou wrote: > > It is also OK if you s/__i686/__x86/ to correspond to your earlier > > change.  Either way is OK. > > Well, that change is not in trunk. > Should that change move to trunk, yes, it's appropriate to change this > as well (though strictly not

Re: C++ PATCHes relating to c++/48834, c++/40975 (array new)

> Well, let's look at the users of copy_tree_r. > > cp/tree.c (bot_manip): The case I want to fix. Then I'd put the fix there. The old behaviour of copy_tree_r is IMO the most sensible one and its callers should cope, as almost all already do it seems. -- Eric Botcazou

Re: [PATCH, SMS] Avoid considering debug_insn when calculating SCCs

Hello, The following is a summary of discussion I had with Ayal regarding the patch: Some background: currently, SMS supports only targets where the doloop pattern is decoupled from the rest of the loop's instructions (for example PowerPC) (we'll call it 'case decoupled' for simplicity) In this

Re: [PATCH, SMS] Avoid considering debug_insn when calculating SCCs

My apologies, the previous email refers to the patch: http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00350.html - Support closing_branch_deps and not to 'Avoid considerin​g debug_insn when calculatin​g SCCs' as the title implies. Thanks, Revital

[patch] Remove error from variable_size

Hi, on the heels of the discussion with Joseph, the attached patch removes the error issued by variable_size, as it appears to be totally useless at this point. FEs should be responsible for catching errors here. Tested on x86_64-suse-linux, OK for the mainline? 2011-05-04 Eric Botcazou

Re: [google]: initialize language field for clone function struct

> Well - the errors in variable_size aren't used by C any more (since 4.5), > but I don't know whether any other languages use them. Apparently not, let's remove them. > And pending sizes are used to a limited extent for C (to handle side effects > in sizes of array parameters, as described in th

Re: debug insns in SMS

On May 4, 2011, Alexandre Oliva wrote: > I think this will restore proper functioning to SMS in the presence of > debug insns. A while ago, we'd never generate deps of non-debug insns > on debug insns. I introduced them to enable sched to adjust (reset) > debug insns when non-debug insns were

Re: [google] Add -fstrict-enum-precision flag (issue4433083)

On Tue, May 3, 2011 at 8:34 PM, Jason Merrill wrote: > On 04/28/2011 03:50 PM, Diego Novillo wrote: >> >> This patch from Silvius Rus adds a new flag (-fstrict-enum-precision). >> While porting the patch to 4.6, I noticed that the C++ FE now has a >> similar flag that seems to have similar semanti

Re: [google] Check if the nonnull attribute is applied to 'this' (issue4446070)

On Tue, May 3, 2011 at 10:10 PM, wrote: > As I commented on the -Wnonnull patch, rather than complain about people > getting the argument number wrong we should ignore 'this' (and other > artificial parms) for attribute argument numbers. I don't think we can reasonably change that now for existi

Re: [PING] [PATCH] PR debug/28767 (Support pointer-to-member-function)

On Tue, May 3, 2011 at 10:36 PM, Dodji Seketeli wrote: > FWIW, this was posted to > http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00949.html > > > > -- Forwarded message -- > From: Dodji Seketeli > To: Jason Merrill > Date: Wed, 16 Mar 2011 20:56:37 +0100 > Subject: [PATCH] PR de

Re: [PATCH] less build_function_type usage in the Fortran FE

On 05/03/2011 09:06 PM, Nathan Froyd wrote: Testing in progress on x86_64-unknown-linux-gnu. OK to commit if testing successful? The Fortran part is OK. Thanks for the janitorial work. Tobias gcc/ * tree.h (build_function_type_array): Declare. (build_varargs_function_type_ar

Some backports from mainline to gcc 4.4 branch

Hi! And here are 3 backports to 4.4 branch, bootstrapped/regtested on x86_64-linux and i686-linux, committed to gcc-4_4-branch. Jakub 2011-05-04 Jakub Jelinek Backported from mainline 2011-05-03 Uros Bizjak Jakub Jelinek PR target/4877

Re: [google] Patch to support calling multi-versioned functions via new GCC builtin. (issue4440078)

On Tue, May 3, 2011 at 11:57 PM, Xinliang David Li wrote: > On Tue, May 3, 2011 at 3:00 AM, Richard Guenther > wrote: >> On Tue, May 3, 2011 at 1:07 AM, Xinliang David Li wrote: >>> On Mon, May 2, 2011 at 2:33 PM, Richard Guenther >>> wrote: On Mon, May 2, 2011 at 6:41 PM, Xinliang David L

Re: [google] Normalize version number for google/gcc-4_6 (issue4454049)

On Wed, May 4, 2011 at 12:20 AM, Matthias Klose wrote: > On 05/02/2011 09:53 PM, Diego Novillo wrote: >> >> Since google/gcc-4_6 follows the 4.6 branch, changes in minor >> revisions cause unnecessary churn in directory names. >> >> Fixed with this.  OK for google/gcc-4_6? >> >>        Google ref

Re: debug insns in SMS (was: Re: Debug_insn)

Hello Alexandre > I think this will restore proper functioning to SMS in the presence of > debug insns. A while ago, we'd never generate deps of non-debug insns > on debug insns. I introduced them to enable sched to adjust (reset) > debug insns when non-debug insns were moved before them. I bel

Re: [PATCH, powerpc], Fix PR48857, pass/return V2DI as other vector types

On Wed, May 4, 2011 at 4:51 AM, David Edelsohn wrote: > On Tue, May 3, 2011 at 5:27 PM, Michael Meissner > wrote: >> When I added VSX support to the powerpc, I overlooked passing and return >> V2DImode arguments, since the only machine operation that supports V2DI is >> vector floating point conv

Re: [patch] Remove error from variable_size

On Wed, May 4, 2011 at 10:32 AM, Eric Botcazou wrote: > Hi, > > on the heels of the discussion with Joseph, the attached patch removes the > error issued by variable_size, as it appears to be totally useless at this > point.  FEs should be responsible for catching errors here. > > Tested on x86_64

Re: [google]: initialize language field for clone function struct

On Tue, May 3, 2011 at 6:15 PM, Xinliang David Li wrote: > On Tue, May 3, 2011 at 3:55 AM, Jan Hubicka wrote: >>> Is this one ok? >> Hi, >> we did quite some work on removing a langhooks for LTO, where they become >> quite impossible >> So I would like to know what testcase causes the problem an

Re: [PATCH] less build_function_type usage in the Fortran FE

On Wed, May 4, 2011 at 11:22 AM, Tobias Burnus wrote: > On 05/03/2011 09:06 PM, Nathan Froyd wrote: >> >> Testing in progress on x86_64-unknown-linux-gnu.  OK to commit if >> testing successful? > > The Fortran part is OK. Thanks for the janitorial work. The middle-end parts are also ok. Richard

Re: [PATCH, ARM] Reload register class fix for NEON constants

On Mon, 2011-04-25 at 19:39 +0400, Dmitry Melnik wrote: > Hi All, > > The attached patch changes the reload class for NEON constant vectors > from GENERAL_REGS to NO_REGS. > The issue was found on this code from libevas: > > void > _op_blend_p_caa_dp(unsigned *s, unsigned* e, unsigned *d, unsig

Re: [google]: initialize language field for clone function struct

> Umm, I think most of them (if not all) are just bogus. If a FE doesn't > want to fold some stuff when at global scope it should not call fold. That isn't so easy because fold is invoked on sizes of types by stor-layout.c and these sizes can be variable (at least in Ada). So I think that the c

[PATCH, i386]: Fix target/48860: bootstrap fails on x86_64-apple-darwin10; broken assembler edition.

Hello! Oh well... some broken assemblers got confused with "movq %reg, %xmm" DImode move mnemonic. "movd" works correctly as well, so use this form instead. 2011-05-04 Uros Bizjak PR target/48860 * config/i386/i386.md (*movdi_internal_rex64) Use %vmovd for reg<->xmm mo

Re: [PATCH, i386]: Fix target/48860: bootstrap fails on x86_64-apple-darwin10; broken assembler edition.

On Wed, May 04, 2011 at 12:02:17PM +0200, Uros Bizjak wrote: > Tested on x86_64-pc-linux-gnu, committed to mainline SVN. I will audit > movq usage in other release branches as well. s/reqire/require/g > --- config/i386/i386.md (revision 173353) > +++ config/i386/i386.md (working copy)

Re: [PATCH 2/4] Docs: extend.texi: Remove trailing blanks from lines

On Tue, 3 May 2011, Gerald Pfeifer wrote: > > sed -i "s/[ $(printf '\t')]\{1,\}\$//" trunk/gcc/doc/extend.texi > > I believe we usually don't do whitespace changes just for the sake > of cleaning up things. > > Unless someone else indicates otherwise, I believe this patch is > rejected. I thin

RE: Move cgraph_node_set and varpool_node_set out of GGC and make them use pointer_map

> Hi, > I always considered the cgrpah_node_set/varpool_node_set to be > overengineered > but they also turned out to be quite ineffective since we do quite a > lot of > queries into them during stremaing out. > > This patch moves them to pointer_map, like I did for streamer cache. > While > doing

Re: [google]: initialize language field for clone function struct

On Wed, 4 May 2011, Eric Botcazou wrote: > That isn't so easy because fold is invoked on sizes of types by stor-layout.c That's what we should phase out. The eventual aim should be for (a) folding on GIMPLE (gimple-fold etc. - working with SSA not combined trees) as an optimization and (b) fo

Re: [google]: initialize language field for clone function struct

> That's what we should phase out. The eventual aim should be for (a) > folding on GIMPLE (gimple-fold etc. - working with SSA not combined trees) > as an optimization and (b) folding done by front ends only when required > for language semantics (e.g. constant expressions). If you want to > opti

Re: [google]: initialize language field for clone function struct

On Wed, May 4, 2011 at 12:00 PM, Eric Botcazou wrote: >> Umm, I think most of them (if not all) are just bogus.  If a FE doesn't >> want to fold some stuff when at global scope it should not call fold. > > That isn't so easy because fold is invoked on sizes of types by stor-layout.c > and these si

Re: [build] mips-tfile.c, mips-tdump.c cleanup

"Joseph S. Myers" writes: > The most obvious other low-hanging fruit in the circumstances would be to > stop these files being built for non-native as a fix for bug 3746, so that > all-targets cross builds of "make all-gcc" (e.g. through Joern's > config-list.mk, which is pending review) don't

Toplevel newlib/libgloss disabling cleanup

This patch separates cases disabling newlib and libgloss for various target OSes from the main toplevel case statement over targets. By doing so, the logic is significantly simplified; there is now a single case for all *-*-linux* targets that disables newlib and libgloss for them, for example. (

Re: [google] Normalize version number for google/gcc-4_6 (issue4454049)

On Tue, May 3, 2011 at 18:20, Matthias Klose wrote: > On 05/02/2011 09:53 PM, Diego Novillo wrote: >> >> Since google/gcc-4_6 follows the 4.6 branch, changes in minor >> revisions cause unnecessary churn in directory names. >> >> Fixed with this.  OK for google/gcc-4_6? >> >>        Google ref 433

Re: [google]: initialize language field for clone function struct

> That's what we should phase out. The eventual aim should be for (a) > folding on GIMPLE (gimple-fold etc. - working with SSA not combined trees) > as an optimization and (b) folding done by front ends only when required > for language semantics (e.g. constant expressions). Why? Isn't it a

Re: [SPARC] Hookize PRINT_OPERAND, PRINT_OPERAND_ADDRESS and PRINT_OPERAND_PUNCT_VALID_P

"Joseph S. Myers" writes: >> What is so hard about running grep when removing/renaming symbols??? > > Generically, the presence of lots of nonobvious places that may turn out > to use a symbol - ada/gcc-interface/, go/gofrontend, config/ for what one > thinks of as front-end symbols, libgcc/ an

rs6000_handle_option global state avoidance, part 1

This patch implements the simpler parts of stopping rs6000_handle_option from using global state. Many options are converted to use .opt features such as Var and Enum, replacing explicit code, while other code is changed to use the opts and opts_set pointers. -mabi=, -mcpu= and -mtune= will be de

Re: [google]: initialize language field for clone function struct

Hi, On Wed, 4 May 2011, Richard Guenther wrote: > > It prevents save_expr from being called at global level, since you > > cannot create SAVE_EXPRs outside functions.  Likewise in > > variable_size. > > I see several places in fold-const.c that are not properly guarded then. > But anyway, if

[Patch, Fortran+gcc/doc/invoke.texi] PR48864: -Ofast implies -fno-protect parens

As the example in the PR shows, using -fno-protect parens can make a huge difference. As -fno-protect is in the spirit of -Ofast, enable it with that option. Build on x86-64-linux. OK for the trunk? Tobias gcc/ 2011-05-04 Tobias Burnus PR fortran/48864 * doc/invoke.texi (Ofast): Document

Re: [SPARC] Hookize PRINT_OPERAND, PRINT_OPERAND_ADDRESS and PRINT_OPERAND_PUNCT_VALID_P

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 present*, but certainly the eventual

Re: [google]: initialize language field for clone function struct

On Wed, May 4, 2011 at 1:56 PM, Michael Matz wrote: > Hi, > > On Wed, 4 May 2011, Richard Guenther wrote: > >> > It prevents save_expr from being called at global level, since you >> > cannot create SAVE_EXPRs outside functions.  Likewise in >> > variable_size. >> >> I see several places in fold-c

[build] Define HAVE_GAS_HIDDEN on Darwin

The following patch is a prerequisite for making [lto, testsuite] Don't use visibility on targets that don't support it (PR lto/47334) http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00295.html work on Darwin by defining HAVE_GAS_HIDDEN on that target, too. Instead of special-casin

config/mep/mep.c: don't translate syntax description.

While checking the current german tanslations I noticed that mep_validate_vliw passes the syntax description directly to inform and thus they appear in the message catalogue which is IMO bogus. This patch makes the syntax descriptions untanslkatable. OK to check in? 2011-05-04 Philipp Thomas

Re: [google]: initialize language field for clone function struct

On Wed, May 4, 2011 at 07:44, Richard Kenner wrote: >> That's what we should phase out.  The eventual aim should be for (a) >> folding on GIMPLE (gimple-fold etc. - working with SSA not combined trees) >> as an optimization and (b) folding done by front ends only when required >> for language sema

Re: [google]: initialize language field for clone function struct

> There are pros and cons about early optimization, actually. > Generating extremely optimized IL very early can actually tie up > subsequent passes. For instance, loop unrolling and vectorization. > There are others in the literature. Sure, in the sorts of examples you mention where there's a le

Re: [google]: initialize language field for clone function struct

On Wed, May 4, 2011 at 08:30, Richard Kenner wrote: >> There are pros and cons about early optimization, actually. >> Generating extremely optimized IL very early can actually tie up >> subsequent passes.  For instance, loop unrolling and vectorization. >> There are others in the literature. > > S

Re: [PATCH][ARM] RTABI half-precision conversion functions

On 27 April 2011 17:26, Andrew Stubbs wrote: > On 21/04/11 16:58, Joseph S. Myers wrote: >> >> You need to add >> >> %inherit GCC_4.7.0 GCC_4.6.0 >> GCC_4.7.0 { >> } > > Ok, done. Is this OK now? I can't approve the target independent parts of this but as I said on IRC based on a brief look I'm n

[PATCH][C] Avoid passing NULL to build_int_cst

This is the C family parts, bootstrapped and tested on x86_64-unknown-linux-gnu. Ok for trunk? Thanks, Richard. 2011-05-04 Richard Guenther * c-decl.c (check_bitfield_type_and_width): Do not pass NULL to build_int_cst. * c-typeck.c (really_start_incremental_init): U

[commit, spu] Fix compiler crash on gcc.c-torture/compile/pr48767.c

Hello, the new gcc.c-torture/compile/pr48767.c test cases were all crashing the compiler on SPU, for a similar reason as on the SH where this problem was originally found. Fixed by calling the common code pass_by_reference routine instead of calling spu_pass_by_reference directly. The common cod

[PATCH][Fortran] Avoid passing NULL to build_int_cst

Fortran parts. Bootstrapped on x86_64-unknown-linux-gnu, testing in progress, ok if it passes? Thanks, Richard. 2011-05-04 Richard Guenther * trans-array.c (gfc_trans_array_constructor_value): Use size_int for bounds of range types. (gfc_trans_array_constructor_value

Re: [google]: initialize language field for clone function struct

Hi, On Wed, 4 May 2011, Richard Kenner wrote: > > There are pros and cons about early optimization, actually. > > Generating extremely optimized IL very early can actually tie up > > subsequent passes. For instance, loop unrolling and vectorization. > > There are others in the literature. > > S

Re: [PATCH][Fortran] Avoid passing NULL to build_int_cst

On 05/04/2011 02:49 PM, Richard Guenther wrote: Fortran parts. Bootstrapped on x86_64-unknown-linux-gnu, testing in progress, ok if it passes? OK. Thanks for doing the janitorial work. Tobias 2011-05-04 Richard Guenther * trans-array.c (gfc_trans_array_constructor_value): Use

Re: [google]: initialize language field for clone function struct

On Wed, May 04, 2011 at 08:30:40AM -0400, Richard Kenner wrote: > > There are pros and cons about early optimization, actually. > > Generating extremely optimized IL very early can actually tie up > > subsequent passes. For instance, loop unrolling and vectorization. > > There are others in the li

Re: [google]: initialize language field for clone function struct

On Wed, May 4, 2011 at 09:19, Nathan Froyd wrote: > On Wed, May 04, 2011 at 08:30:40AM -0400, Richard Kenner wrote: >> > There are pros and cons about early optimization, actually. >> > Generating extremely optimized IL very early can actually tie up >> > subsequent passes.  For instance, loop unr

Re: [google]: initialize language field for clone function struct

> I think we may be talking at different levels. It's my impression > that Richard K. was referring to local transformations like "a - a" -> > "0" once we are in the middle end. I agree that doing that > transformation close to the FE is undesirable, but once we are in the > middle end that shoul

Re: [PING] Fix PR46399 - missing mode promotion for libcall args

On Mon, Apr 18, 2011 at 10:17 AM, Andreas Krebbel wrote: > Hi, > > the attached patch uses the existing promote_function_mode hook.  For > a libcall neither TYPE nor FNTYPE is available so I had to change a > few related function in order to deal with that. > > The patch also fixes the s390 DFP pr

Re: [PING] Fix PR46399 - missing mode promotion for libcall args

2011/5/4 Richard Guenther : > On Mon, Apr 18, 2011 at 10:17 AM, Andreas Krebbel > wrote: >> Hi, >> >> the attached patch uses the existing promote_function_mode hook.  For >> a libcall neither TYPE nor FNTYPE is available so I had to change a >> few related function in order to deal with that. >>

Re: [PATCH] less build_function_type usage in the Fortran FE

On Wed, May 04, 2011 at 11:22:02AM +0200, Tobias Burnus wrote: > On 05/03/2011 09:06 PM, Nathan Froyd wrote: >> Testing in progress on x86_64-unknown-linux-gnu. OK to commit if >> testing successful? > > The Fortran part is OK. Thanks for the janitorial work. Thanks for the review! We'll see if

Re: [PING] Fix PR46399 - missing mode promotion for libcall args

On Wed, May 4, 2011 at 3:45 PM, Kai Tietz wrote: > 2011/5/4 Richard Guenther : >> On Mon, Apr 18, 2011 at 10:17 AM, Andreas Krebbel >> wrote: >>> Hi, >>> >>> the attached patch uses the existing promote_function_mode hook.  For >>> a libcall neither TYPE nor FNTYPE is available so I had to change

Recognize -Ofast like -ffast-math for crtfastmath.o

Hi, -Ofast is intended to be -O3 plus -ffast-math. For the compiler proper this works, but under -ffast-math we add crtfastmath.o (or some equivalent) to the link command line on some targets. As usual for our specs this uses matching on command line arguments, hence we'll explicitely have t

Re: [PATCH] Fix PR46399 - missing mode promotion for libcall args - updated

On 04/18/2011 10:26 AM, Andreas Krebbel wrote: > If it is not for ABI differences anymore what's the reason for > handling libcalls differently from normal calls anymore? Couldn't we > get rid of all the special handling and deal with them like normal > calls? That would be desirable IMO. Bernd

Re: [PATCH][C] Avoid passing NULL to build_int_cst

On Wed, 4 May 2011, Richard Guenther wrote: > 2011-05-04 Richard Guenther > > * c-decl.c (check_bitfield_type_and_width): Do not pass NULL > to build_int_cst. > * c-typeck.c (really_start_incremental_init): Use bitsize_int > for constructor indices. > (push_init_l

Re: Recognize -Ofast like -ffast-math for crtfastmath.o

Hi Michael, > -Ofast is intended to be -O3 plus -ffast-math. For the compiler proper > this works, but under -ffast-math we add crtfastmath.o (or some > equivalent) to the link command line on some targets. As usual for our > specs this uses matching on command line arguments, hence we'll >

[PATCH] More build_int_cst changes

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk. Richard. 2011-05-04 Richard Guenther * coverage.c (tree_coverage_counter_ref): Use integer_type_node for array-ref indices. (tree_coverage_counter_addr): Likewise. (build_fn_info_type): Use

Re: [google]: initialize language field for clone function struct

> And I'm not sure you can't do SAVE_EXPRs outside of functions - you > could simply emit global temporaries. How do you initialize global temporaries with non-trivial initializers? -- Eric Botcazou

Re: [PATCH] Cleanup expand_shift

> 2011-05-03 Richard Guenther > > * expmed.c (expand_variable_shift): Rename to ... > (expand_shift_1): ... this. Take an expanded shift amount. > For rotates recurse directly not building trees for the shift amount. > (expand_variable_shift): Wrap around expand_shift_1.

Re: [google] Check if the nonnull attribute is applied to 'this' (issue4446070)

On 05/04/2011 05:08 AM, Richard Guenther wrote: On Tue, May 3, 2011 at 10:10 PM, wrote: As I commented on the -Wnonnull patch, rather than complain about people getting the argument number wrong we should ignore 'this' (and other artificial parms) for attribute argument numbers. I don't think

Re: [PATCH] Cleanup expand_shift

On Wed, 4 May 2011, Eric Botcazou wrote: > > 2011-05-03 Richard Guenther > > > > * expmed.c (expand_variable_shift): Rename to ... > > (expand_shift_1): ... this. Take an expanded shift amount. > > For rotates recurse directly not building trees for the shift amount. > > (expan

Go patch committed: Use backend interface for named types

This patch to the Go frontend uses the backend interface for named types, and also array type. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline. Ian 2011-05-04 Ian Lance Taylor * go-gcc.cc (Gcc_backend::struct_type): Call fill_in_struct.

Re: C++ PATCHes relating to c++/48834, c++/40975 (array new)

On 05/04/2011 04:12 AM, Eric Botcazou wrote: Well, let's look at the users of copy_tree_r. cp/tree.c (bot_manip): The case I want to fix. Then I'd put the fix there. The old behaviour of copy_tree_r is IMO the most sensible one and its callers should cope, as almost all already do it seems.

Re: [google]: initialize language field for clone function struct

On Wed, May 4, 2011 at 5:10 PM, Eric Botcazou wrote: >> And I'm not sure you can't do SAVE_EXPRs outside of functions - you >> could simply emit global temporaries. > > How do you initialize global temporaries with non-trivial initializers? Actually it turns out that it doesn't matter. If we arr

Re: [PATCH] Cleanup expand_shift

> I think I did it that way because the old code tried to re-construct > the type of the original amount. I can surely simply use op1 here > if that is preferred. Right, but it used the value of OP1 so I think the new code should as well. > Btw, do you happen to know any target that would excerc

Re: [PATCH] Cleanup expand_shift

On Wed, 4 May 2011, Eric Botcazou wrote: > > I think I did it that way because the old code tried to re-construct > > the type of the original amount. I can surely simply use op1 here > > if that is preferred. > > Right, but it used the value of OP1 so I think the new code should as well. Ok, I

Re: Recognize -Ofast like -ffast-math for crtfastmath.o

On Wed, May 4, 2011 at 4:22 PM, Rainer Orth wrote: > Hi Michael, > >> -Ofast is intended to be -O3 plus -ffast-math.  For the compiler proper >> this works, but under -ffast-math we add crtfastmath.o (or some >> equivalent) to the link command line on some targets.  As usual for our >> specs this

Don't use pending_sizes list for C

Following recent discussions of variable_size, this patch stops the C front end from using the global pending_sizes list, instead using the existing grokdeclarator support for tracking size expressions in the one case where pending sizes were still needed. c_variable_size is replaced by a call to

Re: [Patch, Fortran+gcc/doc/invoke.texi] PR48864: -Ofast implies -fno-protect parens

Hi Tobias, As the example in the PR shows, using -fno-protect parens can make a huge difference. As -fno-protect is in the spirit of -Ofast, enable it with that option. Build on x86-64-linux. OK for the trunk? OK. Out of curiosity: Why do you do gfc_option.flag_protect_parens = optimize_fas

[PATCH] don't use TYPE_ARG_TYPES in c-family/

As $SUBJECT suggests. The patch is somewhat larger than it needs to be due to reindenting c-common.c:check_main_parameter_types. Tested on x86_64-unknown-linux. OK to commit? -Nathan gcc/c-family/ * c-common.c (check_main_parameter_types): Reindent. Don't use TYPE_ARG_TYPES di

[PATCH, i386]: Backport recent AVX fixes to 4.6 and 4.5 branch

Hello! 2011-05-04 Uros Bizjak * config/i386/i386.md (*movdi_internal_rex64) : Use %v prefix in insn mnemonic to handle TARGET_AVX. (*movdi_internal): Use "maybe_vex" instead of "vex" in "prefix" attribute calculation. (*movdf_internal): Output AVX mnemon

Re: [PATCH] don't use TYPE_ARG_TYPES in c-family/

On Wed, 4 May 2011, Nathan Froyd wrote: > As $SUBJECT suggests. The patch is somewhat larger than it needs to be > due to reindenting c-common.c:check_main_parameter_types. > > Tested on x86_64-unknown-linux. OK to commit? Since you're reindenting you should also wrap the pedwarn calls in the

[PATCH, i386 AVX]: Fix gcc.target/i386/pad-1.c

Hello! The problem was with the ordering of vzeroupper removal pass and pad-return pass, both in mach pass. Attached patch changes pass ordering so vzeroupper removal is run before pad-return pass. Pad-return pass then (correctly) finds empty function and emits long return. 2011-05-04 Uros Bizja

Re: [Patch, Fortran+gcc/doc/invoke.texi] PR48864: -Ofast implies -fno-protect parens

On 05/04/2011 06:43 PM, Thomas Koenig wrote: Out of curiosity: Why do you do gfc_option.flag_protect_parens = optimize_fast ? 0 : 1; instead of gfc_option.flag_protect_parens = optimize_fast; I found it more clearer than = !optimize_fast (note the "!"), but that's seemingly not the case.

Re: [google]: initialize language field for clone function struct

> Actually it turns out that it doesn't matter. If we arrive here with > something that needs a SAVE_EXPR we have to be able to generate code > for it somewhere, where there would be obviously the possibility to > also generate code for a SAVE_EXPR. The transformations done in fold are optimizati

[obv] remove gfc_chainon_list

As promised in http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00211.html . Tested by building f951. Committed as r173386. -Nathan gcc/fortran/ * trans.h (gfc_chainon_list): Delete. * trans.c (gfc_chainon_list): Delete. Index: gcc/fortran/ChangeLog

Re: [google]: initialize language field for clone function struct

Joseph> I don't know if Fortran, Java or Go use variable-size types at Joseph> all. Java doesn't have variable-size types. AFAIK, gcj does not generate them internally for anything, either. Tom

Re: [PATCH, powerpc], Fix PR48857, pass/return V2DI as other vector types

On Wed, 2011-05-04 at 11:33 +0200, Richard Guenther wrote: > On Wed, May 4, 2011 at 4:51 AM, David Edelsohn wrote: > > On Tue, May 3, 2011 at 5:27 PM, Michael Meissner > > wrote: > >> > >> This patch fixes that so that V2DImode values are passed and returned like > >> other vector types. [snip]

Re[2]: [SPARC] Hookize PRINT_OPERAND, PRINT_OPERAND_ADDRESS and PRINT_OPERAND_PUNCT_VALID_P

Hi. > Richard Henderson writes: >> On 04/27/2011 11:13 AM, Anatoly Sokolov wrote: >>> * config/sparc/sparc.h (PRINT_OPERAND, PRINT_OPERAND_ADDRESS, >>> PRINT_OPERAND_PUNCT_VALID_P): Remove. >>> * config/sparc/sparc-protos.h (print_operand): Remove declaration. >>>

Re: [SPARC] Hookize PRINT_OPERAND, PRINT_OPERAND_ADDRESS and PRINT_OPERAND_PUNCT_VALID_P

Hi Anatoly, > Sorry for my mistake. I think that the patch is obvious, but I have no > capability to test it. > > > * config/sparc/sol.h (ASM_OUTPUT_CALL): Use print_operand target > hook. > > > Index: gcc/config/sparc/sol2.h >

Re: [PATCH 2/4] Docs: extend.texi: Remove trailing blanks from lines

On May 3, 2011, at 10:27 PM, Michael Witten wrote: > On Tue, 3 May 2011 22:52:25 +0200 (CEST), Gerald Pfeifer wrote: > >> >> sed -i "s/[ $(printf '\t')]\{1,\}\$//" trunk/gcc/doc/extend.texi >> >> I believe we usually don't do whitespace changes just for the sake >> of cleaning up things. >> >> U

Re: [RFC PATCH] Typed DWARF stack

> "Jakub" == Jakub Jelinek writes: Jakub> This patch on top of Jakub> http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01224.html Jakub> and Jakub> http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01723.html Jakub> implements parts of Cary's typed DWARF stack proposal: Jakub> http://www.dwarfstd.org/

Re: [RFC PATCH] Typed DWARF stack

> Should DW_OP_bra be restricted to integral types?  Several other opcodes > are restricted in this way, and it seems like an oversight to me that > DW_OP_bra is lacking this restriction.  (I've added this restriction in > GDB.) Yes, that was an oversight. > Currently, the comparison operators ar

Re: [PATCH 2/4] Docs: extend.texi: Remove trailing blanks from lines

On May 4, 2011, at 3:08 AM, Joseph S. Myers wrote: > On Tue, 3 May 2011, Gerald Pfeifer wrote: > >> >> sed -i "s/[ $(printf '\t')]\{1,\}\$//" trunk/gcc/doc/extend.texi >> >> I believe we usually don't do whitespace changes just for the sake >> of cleaning up things. >> >> Unless someone else ind

Re: [RFC PATCH] Typed DWARF stack

On Wed, May 04, 2011 at 12:04:40PM -0600, Tom Tromey wrote: > Should DW_OP_bra be restricted to integral types? Several other opcodes Yes. If you want to test other types, just compare them against 0 using DW_OP_ne etc. > Currently, the comparison operators are all defined as performing signed

Re: [PATCH 2/4] Docs: extend.texi: Remove trailing blanks from lines

On Wed, 4 May 2011, Mike Stump wrote: > > I think we *should* make such formatting cleanups (not just trailing > > whitespace removal, but other changes to match formatting conventions, > > including fixing leading whitespace in C code to use tabs where it doesn't > > as well as more visible ch

Re: [PATCH 2/4] Docs: extend.texi: Remove trailing blanks from lines

On Wed, May 04, 2011 at 10:44:14AM -0700, Mike Stump wrote: > On May 3, 2011, at 10:27 PM, Michael Witten wrote: > > To what do we owe this tradition other than laziness? > > By flat out rejecting style fixing patches, you preserve the > annotations made by vc-blame (svn blame). That's the only r

Re: [Patch, Fortran+gcc/doc/invoke.texi] PR48864: -Ofast implies -fno-protect parens

On 05/04/2011 02:00 PM, Tobias Burnus wrote: As the example in the PR shows, using -fno-protect parens can make a huge difference. As -fno-protect is in the spirit of -Ofast, enable it with that option. As long as -Ofast -fprotect-parens still works, I don't think this would be objectionable.

Re: [PATCH 2/4] Docs: extend.texi: Remove trailing blanks from lines

On Wed, 4 May 2011, Joseph S. Myers wrote: >> I believe we usually don't do whitespace changes just for the sake >> of cleaning up things. >> >> Unless someone else indicates otherwise, I believe this patch is >> rejected. > I think we *should* make such formatting cleanups (not just trailing > w

Re: [PR debug/47590] rework md option overriding to delay var-tracking

On 04/02/2011 10:15 AM, Alexandre Oliva wrote: > Some targets delayed the var-tracking pass to run it after > machine-specific transformations. The introduction of option saving and > restoring broke this, because the machine-specific overriding took place > too late for it to be saved, so, after

Re: [PATCH 2/4] Docs: extend.texi: Remove trailing blanks from lines

On Wed, 4 May 2011, Gerald Pfeifer wrote: > On Wed, 4 May 2011, Joseph S. Myers wrote: > >> I believe we usually don't do whitespace changes just for the sake > >> of cleaning up things. > >> > >> Unless someone else indicates otherwise, I believe this patch is > >> rejected. > > I think we *shou

[PATCH, i386 testsuite]: Cleanup gcc.target/i386/ for AVX targets a bit

Hello! This patch increases/decreases array sizes a bit to prevent loop unrolling and adds appropriate -no-* ABI flags. 2011-05-04 Uros Bizjak * gcc.target/i386/recip-vec-divf.c: Decrease array sizes. * gcc.target/i386/recip-vec-sqrtf.c: Ditto. * gcc.target/i386/recip-

Re: [trunk][RFA] Add __i686.get_pc_thunk.bx to libgcc i386 morestack.S

On Wed, May 4, 2011 at 00:52, Chris Demetriou wrote: > Ian, per your previous comment (which I read as pre-approval for this > change 8-), I'm planning to commit the attached as soon as it's done > testing. > > > chris > - > [libgcc/ChangeLog] > 2011-05-04  Chris Demetriou   > >        * confi

[SPARC] Remove unused macros

Hi. This patch remove some unused macros from sparc.h. The RTX_OK_FOR_OFFSET_P and RTX_OK_FOR_OLO10_P macros is used only in sparc_legitimate_address_p function and moved to sparc.c. Bootstrapped on sparc64-unknown-linux-gnu. OK to install? * config/sparc/sparc.h (REG_OK_FOR_I

Remove obsolete compiler settings in toplevel configure

In I noted a couple of bits of code in the toplevel configure.ac that appeared to be doing things that are properly the responsibility of autoconf. This patch removes them. OK to commit? (Along with

  1   2   >