[PATCH, ARM] PR47855 Compute attr length for thumb2 insns, 3/3 (issue4475042)

Hi This is the third part of the fixing for http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47855 This patch contains the length computation/refinement for insn patterns "*thumb2_movsi_insn", "*thumb2_cbz" and "*thumb2_cbnz". At the same time this patch revealed two bugs. The first is the maximum o

[Patch, Fortran] Support scalar coarrays in this_image/ucobound/image_index

Before, scalar coarrays were not supported in the coindex intrinsics as they did not have - on tree level - cobounds attached to them. This patch adds them. Additionally, it fixes the algorithm of this_image, which seemingly only worked by chance for the test case; hopefully it now works alway

[Patch, Fortran] -std=f2008tr, TR 29113 and OPTIONAL arguments with BIND(C)

This patch does the first minor steps towards TR 29113: It accepts the OPTIONAL attribute in procedures with C binding. As gfortran already passes absent arguments a NULL pointer, there is no changed needed, except in the diagnostics part. Additionally, it is a feature also supported by other c

[google] improves option mismatch handling for LIPO (issue4479045)

This patch improves cross module option mismatch handling in LIPO mode -- will be commited to google/main. 1) Remove duplicates in the option list before comparison; 2) Force module incompatiblity when two modules disagree in -fexceptions setting. In LIPO mode, when option mismatch is discovered

Go patch committed: Use backend interface for slice types

This patch to the Go frontend uses the backend interface for slice types. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline. Ian diff -r 37dae2a9c21b go/gogo-tree.cc --- a/go/gogo-tree.cc Wed May 04 08:38:47 2011 -0700 +++ b/go/gogo-tree.cc Wed May 04 22:18:22

[PATCH] don't use build_function_type in the ObjC/C++ frontends

The last remaining uses of build_function_type in the ObjC/C++ frontends comes from this pattern: tree method_param_types = get_arg_type_list (method_prototype, METHOD_REF, super_flag); tree ftype = build_function_type (ret_type, method_param_types); To eliminate this, I made the followin

Re: Don't use pending_sizes list for C

On May 4, 2011, at 9:38 AM, Joseph S. Myers wrote: > Following recent discussions of variable_size, this patch stops the C > front end from using the global pending_sizes list > Are the ObjC changes OK to commit? Ok. Don't forget about Objective-C++. It isn't the default.

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

On May 4, 2011, at 11:40 AM, Gerald Pfeifer wrote: > Documentation may be a bit more relaxed, and if you have one doc > maintainer approve and the other abstain that may be more boring > that you might hope for. :-) Actually, I was aiming for a global person to ack gcc/*... This could be less bo

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

On May 4, 2011, at 11:46 AM, Joseph S. Myers wrote: > I explicitly approve trailing whitespace removal from all .texi files and > other documentation not imported from upstream sources outside of GCC > (subject to handling generated files properly, so any changes to tm.texi > should be done by c

Re: PR 47793 - Support relative paths using -fprofile-generate

Is this patch ok for trunk? Allowing relative path in -fprofile-generate= is very useful when running the program remotely -- the profile data will be just dumped in the dir relative to the working dir in the remote machine. Using GCOV_PREFIX_STRIP can workaround the problem, but it is not always

[v3] libstdc++/47913 (again)

Hi, Marc kindly contributed the below rewrite of std::ratio_add (and ratio_less), algorithmically derived from the macro __udiv_qrnnd_c in gcc's longlong.h, which amounts to the best behavior in terms of accepted inputs: a pair of std::ratio is *never* rejected unless the resulting std::ratio

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

> Well, I disagree. STATEMENT_LISTs are just another kind of thing you > encounter in an expression; if a caller wants special handling, they can > arrange for it. But you're unilaterally choosing one special handling (copying) among several ones (copying, not copying, aborting) just because of

Minor inliner speedup

Hi, this patch makes inliner more selective about when to test can_inline_edge_p and when to reset edge caches. The first appears quite hot in Mozilla LTO build profiles now, since we used to do way too many resets even when not neccesary. After inlining function A to B, we need: 1) reset edge

C++ PATCH for c++/48749 (ICE regression in template)

The problem was that fixed_type_or_null was looking closely at things that aren't meant to be looked at closely when we're in templates, namely a COMPONENT_REF where operand 1 is an IDENTIFIER. In a template we're going to discard the conversion anyway once we decide it's OK, so we might as we

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

> > I can think of some more-or-less obvious high-level forms, one would > for example simply stick a new DISPATCH tree into gimple_call_fn > (similar to how we can have OBJ_TYPE_REF there), the DISPATCH > tree would be of variable length, first operand the selector function > and further operands

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

I submitted the patch. Thanks, -Sri. On Wed, May 4, 2011 at 3:13 PM, Diego Novillo wrote: > On Wed, May 4, 2011 at 15:35, Sriraman Tallam wrote: > >>        * tree-pass.h (pass_tree_convert_builtin_dispatch): New pass. >>        (pass_ipa_multiversion_dispatch): New pass. >>        * builtin-ty

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

On Wed, May 4, 2011 at 15:35, Sriraman Tallam wrote: >        * tree-pass.h (pass_tree_convert_builtin_dispatch): New pass. >        (pass_ipa_multiversion_dispatch): New pass. >        * builtin-types.def (BT_PTR_FN_INT): New pointer type. >        (BT_FN_INT_PTR_FN_INT_PTR_PTR_VAR): New functio

Re: [google/main][RFA] backport trunk morestack changes (issue4465045)

On Wed, May 4, 2011 at 15:50, Chris Demetriou wrote: > 2011-05-04  Chris Demetriou   > >        Backport from trunk r173391: >        2011-05-04  Chris Demetriou   > >        * config/i386/morestack.S (__i686.get_pc_thunk.bx): Rename to... >        (__x86.get_pc_thunk.bx): ...this. >        (__mo

Committed: fd_truncate test-cases updated for recent libgfortran changes

Once or twice a year some regression results from changed I/O in libgfortran, such that some existing test-case starts calling libgfortran/io/unix.c:raw_truncate, which on limited-I/O-bare-iron targets will emit "required ftruncate or chsize support not present" and fail. After a while, I get to i

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

Re: [google]Add support for sampled profile collection (issue4438083)

Committed the attached patch to google/main. Will send a patch for trunk soon. On Thu, Apr 28, 2011 at 10:03 PM, Xinliang David Li wrote: > Please add regression test cases for the feature. Address the comments > when available. Ok for google/main. > > Thanks, > > David > > On Thu, Apr 28, 2011

Re: Remove obsolete compiler settings in toplevel configure

On 05/04/2011 09:12 PM, Joseph S. Myers wrote: -# hpux11 in 64bit mode has libraries in a weird place. Arrange to find -# them automatically. - -# The Solaris /usr/ucb/cc compiler does not appear to work. Ok. Paolo

[pph] Add streamer hook for preloading common nodes (issue4478043)

This patch adds a new streamer hook to populate the streamer cache with common nodes. The nodes we populate for GIMPLE in lto_get_common_nodes is not sufficient for C++, unsurprisingly. The patch fixes these regressions in pph.exp: FAIL: g++.dg/pph/p1stdlib.cc -fpph-map=pph.map -I. (test for e

Re: [RFC PATCH] Typed DWARF stack

> "Jakub" == Jakub Jelinek writes: Tom> Should DW_OP_bra be restricted to integral types? Several other opcodes Jakub> Yes. If you want to test other types, just compare them against 0 Jakub> using DW_OP_ne etc. Great, thanks. Tom> Currently, the comparison operators are all defined as p

Re: [patch, libgfortran] PR48787 Invalid UP/DOWN rounding with F editing

On Wed, May 4, 2011 at 06:19, Jerry DeLisle wrote: > Hi Folks, > > This patch fixes the latest 'round' of test cases from Thomas.  The patch > adjusts the count of digits before the decimal point by one where w>0 and > d==0.  The patch also consolidates some of the code as a clean up. > > Regressi

[google/main][RFA] backport trunk morestack changes (issue4465045)

Diego, Testing w/ ubuntu lucid native bootstrap + check (C/C++), with --with-pic and numerous other flags, looking good. OK for google/main (assuming tests succeed)? chris -- [libgcc/ChangeLog.google-main] 2011-05-04 Chris Demetriou Backport from trunk r173391: 2011-05-04 C

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

[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

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

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

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

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

[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

> 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

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.

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

[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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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

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

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

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

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

[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

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

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

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

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

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

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

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

  1   2   >