Re: [Patch,testsuite]: Filter more test cases to fit target capabilities

Georg-Johann Lay wrote: > Hi, I am struggling against hundreds of fails in the testsuite because > many cases are not carefully written, e.g. stull like shifting an int > by 19 bits if int is only 16 bits wide. > > This patch adds some additional tests to avoid FAILs that are confusing. > > Sorry

Re: [1/11] Use targetm.shift_truncation_mask more consistently

Bernd Schmidt writes: > On 07/06/11 20:06, Richard Sandiford wrote: >> Bernd Schmidt writes: >>> At some point we've grown a shift_truncation_mask hook, but we're not >>> using it everywhere we're masking shift counts. This patch changes the >>> instances I found. >> >> The documentation reads:

Re: [CFT][PATCH 0/6] Move dwarf2 cfi creation to a new pass

On 7 Jul 2011, at 00:15, Bernd Schmidt wrote: On 07/03/11 22:01, Richard Henderson wrote: Bernd's original patch to optimize dwarf2 cfi for shrink-wrapping is difficult to analyze because that optimization was done via a random debugging hook during final, and the cfi notes are deleted at the

RFA: Fix bogus mode in choose_reload_regs

This patch fixes an ICE in smallest_mode_for_size on the attached testcase. The smallest_mode_for_size call comes from this part of the reload inheritance code in choose_reload_regs: if (byte == 0) need_mode = mode; else n

Re: [PATCH, testsuite] Fix for PR49519, miscompiled 447.dealII in SPEC CPU 2006

Let me try again: I've prepared a patch for: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519 It fixes the problem of tailcall optimization: check for stack overlapping was not strict enough. Patch adds another check for clobbered stack area. If address comes from a register - we have no idea abo

Re: [testsuite] fixes for gcc.target/arm/mla-1.c

> OK for trunk, and for 4.6 in a few days if no problems? > This is OK. Thanks, Ramana

Re: [PATCH] Add -mno-r11 option to suppress load of ppc64 static chain in indirect calls

On Thu, Jul 7, 2011 at 12:29 AM, Michael Meissner wrote: > This patch adds an option to not load the static chain (r11) for 64-bit > PowerPC > calls through function pointers (or virtual function).  Most of the languages > on the PowerPC do not need the static chain being loaded when called, and

Re: Remove obsolete %[] specs operator

On Thu, Jul 7, 2011 at 2:03 AM, Joseph S. Myers wrote: > The %[] spec operator is marked as obsolete and not used by any specs > in GCC; I'm also not sure it would work properly now the canonical > form of -D options is defined to have separate argument.  This patch > removes support for that obso

Re: [PATCH] Add -mno-r11 option to suppress load of ppc64 static chain in indirect calls

On Thu, Jul 07, 2011 at 10:59:36AM +0200, Richard Guenther wrote: > Hum. Can't the compiler figure this our itself per-call-site? At least > the name of the command-line switch -m[no-]r11 is meaningless to me. > Points-to information should be able to tell you if the function pointer > points to

Re: plugin event for C/C++ declarations

> On Tue, Dec 22, 2009 at 11:45 AM, Diego Novillo wrote: >> On Tue, Dec 22, 2009 at 13:00, Brian Hackett wrote: >>> Hi, this patch adds a new plugin event FINISH_DECL, which is invoked >>> at every finish_decl in the C and C++ frontends. ?Previously there did >>> not seem to be a way for a plugin

Re: [v3] Correctly determine baseline_subdir for 64-bit default Solaris gcc

Hi, Ok for mainline if that passes? I'm going to trust you Rainer on this and it seems very safe on x86_64-linux anyway. Please wait just one more day or so and then check it in. Thanks, Paolo.

Re: [PATCH] Add -mno-r11 option to suppress load of ppc64 static chain in indirect calls

On Thu, Jul 7, 2011 at 11:03 AM, Jakub Jelinek wrote: > On Thu, Jul 07, 2011 at 10:59:36AM +0200, Richard Guenther wrote: >> Hum.  Can't the compiler figure this our itself per-call-site?  At least >> the name of the command-line switch -m[no-]r11 is meaningless to me. >> Points-to information sho

Re: [v3] Correctly determine baseline_subdir for 64-bit default Solaris gcc

Hi Paolo, >> Ok for mainline if that passes? > I'm going to trust you Rainer on this and it seems very safe on > x86_64-linux anyway. Please wait just one more day or so and then check it > in. ok, will do. The x86_64-unknown-linux-gnu bootstrap has completed without regressions and the correct

Re: [Patch, AVR]: Fix PR46779

Denis Chertykov wrote: > 2011/6/27 Georg-Johann Lay: >> Denis Chertykov wrote: >>> The main problem for me is that the new addressing mode produce a >>> worse code in many tests. >> You have an example source? > > In attachment. > > Denis. Hi Denis. I had a look at the sources you sent. sort.

Re: [PATCH (3/7)] Widening multiply-and-accumulate pattern matching

On Mon, Jul 4, 2011 at 4:23 PM, Andrew Stubbs wrote: > On 01/07/11 13:25, Richard Guenther wrote: >> >> Well - some operations work the same on both signedness if you >> just care about the twos-complement result.  This includes >> multiplication (but not for example division).  For this special >

Re: Provide 64-bit default Solaris/x86 configuration (PR target/39150)

Rainer Orth writes: > There has long been some clamoring for a amd64-*-solaris2 configuration > similar to sparcv9-sun-solaris2. I've resisted this for quite some > time, primarily because it doubles the maintenance effort of testing > both the 32-bit default and 64-bit default configurations. [

Re: [PATCH (4/7)] Unsigned multiplies using wider signed multiplies

On Mon, Jul 4, 2011 at 4:26 PM, Andrew Stubbs wrote: > On 28/06/11 15:14, Andrew Stubbs wrote: >> >> On 28/06/11 13:33, Andrew Stubbs wrote: >>> >>> On 23/06/11 15:41, Andrew Stubbs wrote: If one or both of the inputs to a widening multiply are of unsigned type then the compiler wil

Re: Improve Solaris mudflap support (PR libmudflap/49550)

Hi Frank, >> I could either commit the current version with the MFWRAP_SPEC addition >> and work from there, or wait until those failures are understood and >> fixed, too. > > Committing now would be fine, assuming no regressions on a primary > platform. below is the patch I've actually comitted,

Re: [PATCH (5/7)] Widening multiplies for mis-matched mode inputs

On Mon, Jul 4, 2011 at 4:29 PM, Andrew Stubbs wrote: > On 28/06/11 16:08, Andrew Stubbs wrote: >> >> On 23/06/11 15:41, Andrew Stubbs wrote: >>> >>> This patch removes the restriction that the inputs to a widening >>> multiply must be of the same mode. >>> >>> It does this by extending the smaller

[PATCH, MELT] new function register_data_handler

Hi, this patch add a new function allowing to add a pragma handler more easily. In the past, we were directly modifying the :sysdata_meltpragmas field of initial_system_data. The pragma handler take a list of new pragma handler that we want to add. The reason is that the field :sysdata_meltpra

Re: [PATCH (6/7)] More widening multiply-and-accumulate pattern matching

On Mon, Jul 4, 2011 at 4:31 PM, Andrew Stubbs wrote: > On 28/06/11 16:30, Andrew Stubbs wrote: >> >> On 23/06/11 15:42, Andrew Stubbs wrote: >>> >>> This patch fixes the case where widening multiply-and-accumulate were >>> not recognised because the multiplication itself is not actually >>> wideni

[PATCH] Fix dead_debug_insert_before ICE (PR debug/49522, take 3)

On Wed, Jul 06, 2011 at 10:36:02PM +0200, Eric Botcazou wrote: > > And here is a version that passed bootstrap/regtest on x86_64-linux and > > i686-linux: > > > > 2011-07-06 Jakub Jelinek > > > > PR debug/49522 > > * df-problems.c (dead_debug_reset): Remove dead_debug_uses > > refere

Re: [PATCH (3/7)] Widening multiply-and-accumulate pattern matching

On 07/07/11 10:58, Richard Guenther wrote: I think you should assume that series of widenings, (int)(short)char_variable are already combined. Thus I believe you only need to consider a single conversion in valid_types_for_madd_p. Hmm, I'm not so sure. I'll look into it a bit further. +/* Ch

[build] Move dfp-bit support to toplevel libgcc

The next patch in the `move to toplevel libgcc' series is hopefully easier to get review and approval for. This one moves dfp-bit and related build stuff to libgcc. I think it's completely straight forward: it moves D{32, 64, 128}PBIT{, _FUNCS}, related Makefile fragments, and the source files th

Re: [PATCH, MELT] new function register_data_handler

On Thu, Jul 07, 2011 at 12:10:30PM +0200, Pierre Vittet wrote: > Hi, this patch add a new function allowing to add a pragma handler > more easily. In the past, we were directly modifying the > :sysdata_meltpragmas field of initial_system_data. > > 2011-07-07 Pierre Vittet > > * melt/war

[PATCH] Fix UNRESOLVED gcc.dg/graphite/pr37485.c

Committed. Richard. 2011-07-07 Richard Guenther * gcc.dg/graphite/pr37485.c: Add -floop-block. Index: gcc/testsuite/gcc.dg/graphite/pr37485.c === --- gcc/testsuite/gcc.dg/graphite/pr37485.c (revision 175915) +++ gcc

[PATCH, graphite]: "Fix" UNRESOLVED: gcc.dg/graphite/pr37485.c scan-tree-dump-times graphite "Loop blocked"

Hello! We should add loop blocking flags (the same as in graphite.exp) if we want to check graphite tree dump. 2011-07-07 Uros Bizjak * gcc.dg/graphite/pr37485.c (dg-options): Add -floop-block -fno-loop-strip-mine -fno-loop-interchange -ffast-math. Tested on x86_64-pc-linux-g

Re: [build] Move dfp-bit support to toplevel libgcc

On 07/07/2011 12:27 PM, Rainer Orth wrote: one might as well argue that they are generic and belong into libgcc itself. Agreed. i[34567]86-*-linux* | i[34567]86-*-kfreebsd*-gnu | i[34567]86-*-knetbsd*-gnu | i[34567]86-*-gnu* | i[34567]86-*-kopensolaris*-gnu) extra_parts="$extra_par

Re: [PATCH (4/7)] Unsigned multiplies using wider signed multiplies

On 07/07/11 11:04, Richard Guenther wrote: Both types are equal, so please share the temporary variable you create + rhs1 = build_and_insert_cast (gsi, gimple_location (stmt), + create_tmp_var (type1, NULL), rhs1, type1); + rhs2 = build_and_i

[Patch, Fortran] PR fortran/49648 ICE with use-associated array-returning function

Hello, this is the patch I posted yesterday on bugzilla at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49648#c8 The problem is a NULL pointer encountered during code generation when trying to get the rank from the array spec. The array ref's array spec is normally copied in resolve_ref from th

Re: [build] Move dfp-bit support to toplevel libgcc

Paolo Bonzini writes: >> i[34567]86-*-linux* | i[34567]86-*-kfreebsd*-gnu | >> i[34567]86-*-knetbsd*-gnu | i[34567]86-*-gnu* | >> i[34567]86-*-kopensolaris*-gnu) >> extra_parts="$extra_parts crtprec32.o crtprec64.o crtprec80.o >> crtfastmath.o" >> -tmake_file="${tmake_file} i386/t-c

Re: [PATCH (4/7)] Unsigned multiplies using wider signed multiplies

On Thu, Jul 7, 2011 at 12:41 PM, Andrew Stubbs wrote: > On 07/07/11 11:04, Richard Guenther wrote: >> >> Both types are equal, so please share the temporary variable you >> create >> >> +         rhs1 = build_and_insert_cast (gsi, gimple_location (stmt), >> +                                      

[PATCH][1/n] Do not force sizetype for POINTER_PLUS_EXPR

This is the first of a series of enabling patches to make POINTER_PLUS_EXPR not forcefully take a sizetype offset (I'm still no 100% what requirements I will end up implementing, but the first goal is to have less TYPE_IS_SIZETYPE types). This patch removes the (T *)index +p (int)PTR -> PTR +p i

[go]: Port to ALPHA arch - epoll problems

On Tue, Jul 5, 2011 at 10:12 PM, Ian Lance Taylor wrote: >> What remains is a couple of unrelated failures in the testsuite: >> >> Epoll unexpected fd=0 >> pollServer: unexpected wakeup for fd=0 mode=w >> panic: test timed out >> ../../../gcc-svn/trunk/libgo/testsuite/gotest: line 388:  7123 Abor

Re: [Patch, Fortran] Add stat=/errmsg= support to _gfortran_caf_register

On Thursday 07 July 2011 07:35:07 Tobias Burnus wrote: > diff --git a/libgfortran/caf/mpi.c b/libgfortran/caf/mpi.c > index 83f39f6..2d4af6b 100644 > --- a/libgfortran/caf/mpi.c > +++ b/libgfortran/caf/mpi.c > @@ -103,10 +110,19 @@ _gfortran_caf_register (ptrdiff_t size, caf_register_t type, >

[PATCH][C] Fixup pointer-int-sum

This tries to make sense of the comments and code in the code doing the index - size multiplication in pointer-int-sum. It also fixes a bogus integer-constant conversion which results in not properly canonicalized integer constants. The comment in the code claims the index - size multiplication

Re: [PATCH (3/7)] Widening multiply-and-accumulate pattern matching

On 07/07/11 11:26, Andrew Stubbs wrote: On 07/07/11 10:58, Richard Guenther wrote: I think you should assume that series of widenings, (int)(short)char_variable are already combined. Thus I believe you only need to consider a single conversion in valid_types_for_madd_p. Hmm, I'm not so sure.

[go]: Many valgrind errors (use of uninit value, jump depends on uninit value) in the testsuite

On Tue, Jul 5, 2011 at 10:12 PM, Ian Lance Taylor wrote: >> What remains is a couple of unrelated failures in the testsuite: >> ../../../gcc-svn/trunk/libgo/testsuite/gotest: line 388: 13945 >> Segmentation fault      ./a.out -test.short -test.timeout=$timeout >> "$@" >> FAIL: compress/flate >>

Re: plugin event for C/C++ declarations

On 11-07-07 05:06 , Romain Geissler wrote: gcc/ChangeLog: * plugin.def: Add event for finish_decl. * plugin.c (register_callback, invoke_plugin_callbacks): Same. * c-decl.c (finish_decl): Invoke callbacks on above event. * doc/plugins.texi: Document above event.

Re: [Patch, Fortran] PR fortran/49648 ICE with use-associated array-returning function

Dear Mikael, On 07/07/2011 12:42 PM, Mikael Morin wrote: this is the patch I posted yesterday on bugzilla at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49648#c8 This patch calls gfc_resolve_array_spec on sym->result, which calls gfc_resolve_expr on every bound, which in turn calls resolve_ref

Re: [PATCH (3/7)] Widening multiply-and-accumulate pattern matching

On Thu, Jul 7, 2011 at 1:43 PM, Andrew Stubbs wrote: > On 07/07/11 11:26, Andrew Stubbs wrote: >> >> On 07/07/11 10:58, Richard Guenther wrote: >>> >>> I think you should assume that series of widenings, >>> (int)(short)char_variable >>> are already combined.  Thus I believe you only need to consi

Re: Improve Solaris mudflap support (PR libmudflap/49550)

Hello! > diff --git a/libmudflap/testsuite/libmudflap.c/pass47-frag.c > b/libmudflap/testsuite/libmudflap.c/pass47-frag.c > --- a/libmudflap/testsuite/libmudflap.c/pass47-frag.c > +++ b/libmudflap/testsuite/libmudflap.c/pass47-frag.c > @@ -8,3 +8,5 @@ int main () > tolower (buf[4]

Re: [PATCH] Fix UNRESOLVED gcc.dg/graphite/pr37485.c

Hello! > Committed. > > Richard. > > 2011-07-07 Richard Guenther > > * gcc.dg/graphite/pr37485.c: Add -floop-block. Heh, you were faster by a minute! Uros.

Re: [PATCH (3/7)] Widening multiply-and-accumulate pattern matching

On Thu, Jul 7, 2011 at 2:28 PM, Richard Guenther wrote: > On Thu, Jul 7, 2011 at 1:43 PM, Andrew Stubbs wrote: >> On 07/07/11 11:26, Andrew Stubbs wrote: >>> >>> On 07/07/11 10:58, Richard Guenther wrote: I think you should assume that series of widenings, (int)(short)char_variable

Re: [Patch, Fortran] Add stat=/errmsg= support to _gfortran_caf_register

On 07/07/2011 01:35 PM, Mikael Morin wrote: if (type == CAF_REGTYPE_COARRAY_STATIC) { This will return the same error (memory allocation failure) as in the case just above. Is this expected or should it have an error of its own? I think it is OK in either case. CAF_REFTYPE_COARRAY_ST

[committed] Regimplify last 2 ARRAY_*REF operands and last COMPONENT_REF operand (PR middle-end/49640)

Hi! The attached testcase ICEs, because gimple_regimplify_operands ignores lb: and sz: operands on ARRAY*_REF (and last operand on COMPONENT_REF), assuming that if it is non-NULL, it is valid GIMPLE and doesn't need further processing. That is true for gimplification, as FEs/generic leave those o

[PATCH] Fix complex {*,/} real or real * complex handling in C FE (PR c/49644)

Hi! For MULT_EXPR and TRUNC_DIV_EXPR, both sides of COMPLEX_EXPR contain a copy of the non-complex operand, which means its side-effects can be evaluated twice. For PLUS_EXPR/MINUS_EXPR they appear just in one of the operands and thus it works fine as is. Fixed thusly, bootstrapped/regtested on

Re: PATCH [1/n] X32: Add initial -x32 support

On Wed, Jul 6, 2011 at 9:22 AM, H.J. Lu wrote: > On Wed, Jul 6, 2011 at 8:02 AM, Richard Guenther > wrote: >> On Wed, Jul 6, 2011 at 4:48 PM, H.J. Lu wrote: >>> Hi Paolo, DJ, Nathanael, Alexandre, Ralf, >>> >>> Is the change >>> . >>>        * configure.ac: Support --enable-x32. >>>        * con

Re: RFA: Fix bogus mode in choose_reload_regs

Richard Sandiford wrote: > gcc/ > * reload1.c (choose_reload_regs): Use mode sizes to check whether > an old relaod register completely defines the required value. > > gcc/testsuite/ > * gcc.target/arm/neon-modes-3.c: New test. This is OK. Thanks, Ulrich -- Dr. Ulrich Weig

Re: PATCH [1/n] X32: Add initial -x32 support

On Thu, Jul 7, 2011 at 2:59 PM, H.J. Lu wrote: Hi Paolo, DJ, Nathanael, Alexandre, Ralf, Is the change .        * configure.ac: Support --enable-x32.        * configure: Regenerated. diff --git a/gcc/configure.ac b/gcc/configure.ac index 5f3641b..bddab

Re: CFT: Move unwinder to toplevel libgcc

Tristan Gingold writes: >> Otherwise, the patch is unchanged from the original submission: >> >> [build] Move unwinder to toplevel libgcc >> http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01452.html >> >> Unfortunately, it hasn't seen much comment. I'm now looking for testers >> especi

Re: RFA: Fix bogus mode in choose_reload_regs

On 7 July 2011 09:09, Richard Sandiford wrote: > gcc/ >        * reload1.c (choose_reload_regs): Use mode sizes to check whether >        an old relaod register completely defines the required value. s/relaod/reload/ Jay.

[PATCH] Fix folding of -(unsigned)(a * -b)

Folding of $subject is currently broken (noticed that when playing with types in pointer_int_sum). We happily ignore the fact that the negate operates on an unsigned type and change it to operate on a signed one - which may cause new undefined overflow. Seen with the testcase below which aborts w

Re: PATCH [1/n] X32: Add initial -x32 support

Did you even _think_ of looking at the sh configury, and do something vaguely similar for x86? You should not duplicate t-linux64 at all. Instead, in config.gcc set m64/m32 as the default value for with_multilib_list on i386 biarch and x86_64. Pass $with_multilib_list to t-linux64 using TM_MULTI

[PATCH] Make VRP optimize useless conversions

The following patch teaches VRP to disregard the intermediate conversion in a sequence (T1)(T2)val if that sequence is value-preserving for val. There are possibly some more cases that could be handled when a sign-change is involved but the following is a first safe step. Bootstrapped on x86_64-

Re: Remove unused t-* fragments

On 7/6/2011 4:14 PM, Joseph S. Myers wrote: 2011-07-06 Joseph Myers * config/i386/t-crtpic, config/i386/t-svr3dbx, config/pa/t-pa: Remove. Ok for pa. Dave -- John David Anglindave.ang...@bell.net

Re: [PATCH, graphite]: "Fix" UNRESOLVED: gcc.dg/graphite/pr37485.c scan-tree-dump-times graphite "Loop blocked"

On Thu, Jul 7, 2011 at 05:36, Uros Bizjak wrote: > Hello! > > We should add loop blocking flags (the same as in graphite.exp) if we > want to check graphite tree dump. > > 2011-07-07  Uros Bizjak   > >        * gcc.dg/graphite/pr37485.c (dg-options): Add -floop-block >        -fno-loop-strip-mine

Re: [patch tree-optimization]: Do bitwise operator optimizations for X op !X patterns

On Mon, Jul 4, 2011 at 8:55 PM, Kai Tietz wrote: > Ok, reworked version.  The folding of X op X and !X op !X seems indeed > not being necessary. So function simplifies much. > > Bootstrapped and regression tested for all standard languages (plus > Ada and Obj-C++). Ok for apply? Ok with a proper

Re: [PATCH 4/6] Shrink-wrapping

Bernd Schmidt writes: > This adds the actual optimization, and reworks the JUMP_LABEL handling > for return blocks. See the introduction mail or the new comment ahead of > thread_prologue_and_epilogue_insns for more notes. It seems a shame to have both (return) and (simple_return). You said that

Re: [PATCH][C] Fixup pointer-int-sum

On Thu, 7 Jul 2011, Richard Guenther wrote: > not overflow (what is actually the C semantics - is the > multiplication allowed to overflow for unsigned intop? If not Overflow is not allowed. Formally the multiplication is as-if to infinite precision, and then there is undefined behavior if the

Re: [PATCH] Fix complex {*,/} real or real * complex handling in C FE (PR c/49644)

On Thu, 7 Jul 2011, Jakub Jelinek wrote: > Hi! > > For MULT_EXPR and TRUNC_DIV_EXPR, both sides of COMPLEX_EXPR contain > a copy of the non-complex operand, which means its side-effects can be > evaluated twice. For PLUS_EXPR/MINUS_EXPR they appear just in one of > the operands and thus it works

Re: [PATCH][C] Fixup pointer-int-sum

On Thu, 7 Jul 2011, Joseph S. Myers wrote: > On Thu, 7 Jul 2011, Richard Guenther wrote: > > > not overflow (what is actually the C semantics - is the > > multiplication allowed to overflow for unsigned intop? If not > > Overflow is not allowed. Formally the multiplication is as-if to infinite

Re: [Patch,testsuite]: Filter more test cases to fit target capabilities

On Jul 6, 2011, at 10:26 AM, Georg-Johann Lay wrote: > Hi, I am struggling against hundreds of fails in the testsuite because > many cases are not carefully written, e.g. stull like shifting an int > by 19 bits if int is only 16 bits wide. > Ok to commit? Ok.

Re: PATCH [1/n] X32: Add initial -x32 support

On Thu, Jul 7, 2011 at 6:21 AM, Paolo Bonzini wrote: > Did you even _think_ of looking at the sh configury, and do something > vaguely similar for x86? > > You should not duplicate t-linux64 at all.  Instead, in config.gcc set > m64/m32 as the default value for with_multilib_list on i386 biarch an

Re: [PATCH] Fix complex {*,/} real or real * complex handling in C FE (PR c/49644)

On Thu, Jul 07, 2011 at 02:55:45PM +, Joseph S. Myers wrote: > On Thu, 7 Jul 2011, Jakub Jelinek wrote: > > For MULT_EXPR and TRUNC_DIV_EXPR, both sides of COMPLEX_EXPR contain > > a copy of the non-complex operand, which means its side-effects can be > > evaluated twice. For PLUS_EXPR/MINUS_E

Re: PATCH [1/n] X32: Add initial -x32 support

On Thu, Jul 7, 2011 at 5:02 PM, H.J. Lu wrote: >> Did you even _think_ of looking at the sh configury, and do something >> vaguely similar for x86? >> >> You should not duplicate t-linux64 at all.  Instead, in config.gcc set >> m64/m32 as the default value for with_multilib_list on i386 biarch an

Re: [PATCH] Fix complex {*,/} real or real * complex handling in C FE (PR c/49644)

On Thu, 7 Jul 2011, Jakub Jelinek wrote: > On Thu, Jul 07, 2011 at 02:55:45PM +, Joseph S. Myers wrote: > > On Thu, 7 Jul 2011, Jakub Jelinek wrote: > > > For MULT_EXPR and TRUNC_DIV_EXPR, both sides of COMPLEX_EXPR contain > > > a copy of the non-complex operand, which means its side-effects

Re: [ARM] Deprecate -mwords-little-endian

Richard Earnshaw writes: > On 29/06/11 12:28, Richard Sandiford wrote: >> ARM has an option called -mwords-little-endian that provides big-endian >> compatibility with pre-2.8 compilers. When I asked Richard about it, >> he seemed to think it had outlived its usefulness, so this patch >> deprecat

Re: PATCH [1/n] X32: Add initial -x32 support

On Thu, Jul 7, 2011 at 17:12, Uros Bizjak wrote: > On Thu, Jul 7, 2011 at 5:02 PM, H.J. Lu wrote: > >>> Did you even _think_ of looking at the sh configury, and do something >>> vaguely similar for x86? >>> >>> You should not duplicate t-linux64 at all.  Instead, in config.gcc set >>> m64/m32 as

Re: [PATCH 4/6] Shrink-wrapping

Whee! Thanks for reviewing (reviving?) this old thing. I should be posting an up-to-date version of this, but for the moment it has to wait until dwarf2out is sorted out, and I'm rather busy with other stuff. I hope to squeeze this in in the not too distant future. I'll try to answer some of the

Re: [ARM] Deprecate -mwords-little-endian

On 07/07/11 16:18, Richard Sandiford wrote: > Richard Earnshaw writes: >> On 29/06/11 12:28, Richard Sandiford wrote: >>> ARM has an option called -mwords-little-endian that provides big-endian >>> compatibility with pre-2.8 compilers. When I asked Richard about it, >>> he seemed to think it had

Re: Generic hwloop support library

On 07/05/11 21:25, Richard Sandiford wrote: > (Could you bootstrap this on x86_64 to check for things like that? That has no loop_end pattern so it wouldn't be much of a test, but a x86_64 x bfin compiler has no warnings in this file with the intptr_t thing fixed. > A C bootstrap only should be

Re: [PATCH] Fix folding of -(unsigned)(a * -b)

Hi, On Thu, 7 Jul 2011, Richard Guenther wrote: > Index: gcc/fold-const.c > === > --- gcc/fold-const.c (revision 175962) > +++ gcc/fold-const.c (working copy) > @@ -7561,7 +7561,7 @@ fold_unary_loc (location_t loc, enum tre >if

Re: [PATCH] Add -mno-r11 option to suppress load of ppc64 static chain in indirect calls

On Thu, Jul 07, 2011 at 10:59:36AM +0200, Richard Guenther wrote: > On Thu, Jul 7, 2011 at 12:29 AM, Michael Meissner > wrote: > > This patch adds an option to not load the static chain (r11) for 64-bit > > PowerPC > > calls through function pointers (or virtual function).  Most of the > > langu

Ping Re: Remove config.gcc support for *local* configurations

Ping. This patch is pending review. -- Joseph S. Myers jos...@codesourcery.com

Re: [PATCH] Fix dead_debug_insert_before ICE (PR debug/49522, take 3)

> So, here is a new patch which doesn't need two loops, just might go a > little bit backwards to unchain dead_debug_use for the reset insn. > > It still needs the change of the gcc_assert (reg) into if (reg == NULL) > return;, because the dead->used bitmap is with this sometimes a false > positive

Re: CFT: Move unwinder to toplevel libgcc

On Thu, 2011-07-07 at 15:08 +0200, Rainer Orth wrote: > Tristan Gingold writes: > > >> Otherwise, the patch is unchanged from the original submission: > >> > >>[build] Move unwinder to toplevel libgcc > >>http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01452.html > >> > >> Unfortunately, i

Re: [PATCH] Add -mno-r11 option to suppress load of ppc64 static chain in indirect calls

On Thu, Jul 7, 2011 at 5:47 PM, Michael Meissner wrote: > On Thu, Jul 07, 2011 at 10:59:36AM +0200, Richard Guenther wrote: >> On Thu, Jul 7, 2011 at 12:29 AM, Michael Meissner >> wrote: >> > This patch adds an option to not load the static chain (r11) for 64-bit >> > PowerPC >> > calls through

Re: [PATCH 4/6] Shrink-wrapping

On 07/07/11 15:34, Richard Sandiford wrote: > It seems a shame to have both (return) and (simple_return). You said > that we need the distinction in order to cope with targets like ARM, > whose (return) instruction actually performs some of the epilogue too. > It feels like the load of the saved r

Re: [PATCH] Make VRP optimize useless conversions

Hi, On Thu, 7 Jul 2011, Richard Guenther wrote: > + tree rhs1 = gimple_assign_rhs1 (stmt); > + gimple def_stmt = SSA_NAME_DEF_STMT (rhs1); > + value_range_t *final, *inner; > + > + /* Obtain final and inner value-ranges for a conversion > + sequence (final-type)(intermediate-type)in

Re: Ping Re: Remove config.gcc support for *local* configurations

On 07/07/2011 05:49 PM, Joseph S. Myers wrote: Ping. This patch is pending review. Ok. Paolo

Re: [testsuite] ARM wmul tests: require arm_dsp_multiply

On 06/07/11 18:33, Janis Johnson wrote: > On 06/29/2011 06:25 AM, Richard Earnshaw wrote: >> On 23/06/11 22:38, Janis Johnson wrote: >>> Tests wmul-[1234].c and mla-2.c in gcc.target/arm require support that >>> the arm backend identifies as TARGET_DSP_MULTIPLY. The tests all >>> specify a -march

Re: [PATCH] New IPA-CP with real function cloning

Hi, patch is long, so let me review it in more passes. > > > 2011-06-22 Martin Jambor > > * ipa-prop.h: Include alloc-pool.h. > (ipa_lattice_type): Removed. > (ipcp_value_source): New type. > (ipcp_value): Likewise. > (ipcp_values_pool): Declare. > (ipcp_so

[patch tree-optimization]: [1 of 3]: Boolify compares & more

Hello, This patch - first of series - adds to fold and some helper routines support for one-bit precision bitwise folding and detection. This patch is necessary for - next patch of series - boolification of comparisons. Bootstrapped and regression tested for all standard-languages (plus Ada and O

[patch tree-optimization]: [2 of 3]: Boolify compares & more

Hello, This patch - second of series - adds boolification of comparisions in gimplifier. For this casts from/to boolean are marked as not-useless. And in fold_unary_loc casts to non-boolean integral types are preserved. The hunk in tree-ssa-forwprop.c in combine_cond-expr_cond is not strictly nec

[patch tree-optimization]: [3 of 3]: Boolify compares & more

Hello, This patch - third of series - fixes vrp to handle bitwise one-bit precision typed operations. And it introduces a second - limitted to non-switch-statement range - vrp pass. Bootstrapped and regression tested for all standard-languages (plus Ada and Obj-C++) on host x86_64-pc-linux-gnu.

Re: [PATCH] Add -mno-r11 option to suppress load of ppc64 static chain in indirect calls

On Thu, Jul 07, 2011 at 05:53:09PM +0200, Richard Guenther wrote: > Well, I guess you don't propose to build glibc with -mno-r11? The compiler > certainly can't figure out in _all_ cases - but it should be able to handle > most of the cases (with LTO even more cases) ok, no? No, we are no proposi

Re: [testsuite] arm tests: remove -march= and dg-prune-output from 3 tests

On 07/07/11 00:26, Janis Johnson wrote: > For three tests in gcc.target/arm that don't depend on processor-specific > behavior, don't specify the -march option. This makes dg-prune-output > for warnings about conflicts unnecessary, so remove it. > > Two of these tests are for internal compiler er

Re: [PATCH] Add -mno-r11 option to suppress load of ppc64 static chain in indirect calls

[...] On Jul 7, 2011, at 5:53 PM, Richard Guenther wrote: > On Thu, Jul 7, 2011 at 5:47 PM, Michael Meissner > wrote: >> I certainly can call the switch -mno-static-chain, which is perhaps more >> meaningful (at least to us compiler folk, I'm not sure static chain means >> much >> to the normal

Re: [patch tree-optimization]: [3 of 3]: Boolify compares & more

On 07/07/2011 06:07 PM, Kai Tietz wrote: + /* We redo folding here one time for allowing to inspect more + complex reductions. */ + substitute_and_fold (op_with_constant_singleton_value_range, + vrp_fold_stmt, false); + /* We need to mark this second pass to avoid re-

Re: Fix PR 49014

On 07/01/2011 10:50 AM, Andrey Belevantsev wrote: On 26.05.2011 17:32, Andrey Belevantsev wrote: 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 insn

Re: [patch tree-optimization]: [3 of 3]: Boolify compares & more

2011/7/7 Paolo Bonzini : > On 07/07/2011 06:07 PM, Kai Tietz wrote: >> >> +  /* We redo folding here one time for allowing to inspect more >> +     complex reductions.  */ >> +  substitute_and_fold (op_with_constant_singleton_value_range, >> +                      vrp_fold_stmt, false); >> +  /* We

[patch] Disable static build for libjava

As discussed at the Google GCC gathering, disable the build of static libraries in libjava, which should cut the build time of libjava by 50%. The static libjava build isn't useful out of the box, and I don't see it packaged by Linux distributions either. The AC_PROG_LIBTOOL check is needed to ge

Re: [testsuite] arm tests: remove -march= and dg-prune-output from 3 tests

On 07/07/2011 09:14 AM, Richard Earnshaw wrote: > On 07/07/11 00:26, Janis Johnson wrote: >> Index: gcc.target/arm/pr41679.c > > I think this should just be moved to gcc.c-torture/compile. There > doesn't seem to be anything processor-specific here. > >> Index: gcc.target/arm/pr46883.c > > Lik

Re: [testsuite] arm thumb tests: remove -march= and dg-prune-output from 9 tests

On 07/07/11 00:28, Janis Johnson wrote: > This patch removes -march= from nine tests that also check for relevant > effective targets. If -march is removed there is no need to ignore > compiler warnings about conflicting options with dg-prune-output, so the > patch removes that from the tests. >

Re: CFT: Move unwinder to toplevel libgcc

On Thu, 2011-07-07 at 15:08 +0200, Rainer Orth wrote: > In that case, perhaps Steve could have a look? I'd finally like to make > some progress on this patch. > > Thanks. > Rainer It looks like the GCC build is trying to compile unwind-ia64.c on IA64 HP-UX even though it should not use

Re: [testsuite] arm tests: remove -march= and dg-prune-output from 3 tests

On 07/07/11 17:30, Janis Johnson wrote: > On 07/07/2011 09:14 AM, Richard Earnshaw wrote: >> On 07/07/11 00:26, Janis Johnson wrote: >>> Index: gcc.target/arm/xor-and.c >>> === >>> --- gcc.target/arm/xor-and.c(revision 175921)

Re: [patch] Disable static build for libjava

On 07/07/2011 09:27 AM, Matthias Klose wrote: As discussed at the Google GCC gathering, disable the build of static libraries in libjava, which should cut the build time of libjava by 50%. The static libjava build isn't useful out of the box, and I don't see it packaged by Linux distributions ei

Re: [patch] Disable static build for libjava

On 07/07/2011 06:51 PM, David Daney wrote: > On 07/07/2011 09:27 AM, Matthias Klose wrote: >> As discussed at the Google GCC gathering, disable the build of static >> libraries >> in libjava, which should cut the build time of libjava by 50%. The static >> libjava build isn't useful out of the bo

Re: [PATCH 4/6] Shrink-wrapping

On Jul 7, 2011, at 11:38 AM, Bernd Schmidt wrote: > ... > >> It'd also be nice to get rid of all these big blocks of code that are >> conditional on preprocessor macros, but I realise you're just following >> existing practice in the surrounding code, so again it can be left to >> a future clean

  1   2   >