Re: [PATCH] use build_function_type_list in the avr backend

2011/4/20 Nathan Froyd : > As $SUBJECT suggests.  Tested with cross to avr-elf.  OK to commit? > > -Nathan > >        * config/avr/avr.c (avr_init_builtins): Call >        build_function_type_list instead of build_function_type. > Please, commit. Denis.

Ping: Make 128 bits the default vector size for NEON

http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02172.html The last version: ChangeLog: * doc/invoke.texi (preferred-vector-size): Document. * params.h (PREFERRED_VECTOR_SIZE): Define. * config/arm/arm.c (arm_preferred_simd_mode): Use param PREFERRED_VECTOR_SIZE instead of

Go patch committed: Use mpfr_prec_round to constraint floats

This patch to the Go frontend changes it to use mpfr_prec_round rather than real_convert to constrain untyped float or complex constants to their actual type. This is a simplification and also eliminates a call from the frontend to a gcc-specific middle-end function. Bootstrapped and ran Go tests

Re: FDO usability patch -- cfg and lineno checksum

On Tue, Apr 19, 2011 at 3:20 PM, Jan Hubicka wrote: > I can not review tree.c changes.  I would probably suggest making crc_byte > inline. Diego, can you review this change? This is just a simple refactoring. > >> +#if IN_LIBGCOV >> + >> +/* These functions are guarded by #if to avoid compile

Some small C++ PATCHes

1) While looking at 48530 I noticed that my recent change to put array literals in static storage again needed to check for non-trivial destructors. 2) I also added support for trivial destructors to build_over_call, though it isn't currently used by anything. 3) lookup_fnfields_slot wasn't

Re: fix memory leak in gengtype

Dimitrios - The patch is OK with a ChangeLog entry. Also a patch to fix the same in gengtype.c:matching_file_name_substitute is pre-approved (but it looks like Jeff will beat you to this :) > P.S. I was trying to test gcc on a rare arch (sparc-unknown-linux-gnu) but > unfortunately the sparcstati

Re: C++ PATCH for c++/48594 (failure with overloaded ->* in template)

While backporting this to 4.5 and 4.4 I noticed that making the object non-dependent shouldn't be conditionalized. Tested x86_64-pc-linux-gnu, applying to 4.6 and trunk. Applying the two patches folded together on 4.4 and 4.5. commit a39f5c2859bb16af16945830f3c0802c40441b70 Author: Jason Merri

Re: [RFA] [PowerPC]

The test and-1.c has wrong logic. In the formula: y & ~(y & -y) The part (y & -y) is always a mask with one bit set, which corresponds to the least significant "1" bit in y. The final result is that bit, is set to zero (y & ~mask) There is no boolean simplification possible, and the compiler alw

Re: Ping^2 Re: Target header etc. cleanup patch

On Apr 20, 2011, at 5:09 PM, Joseph S. Myers wrote: > Ping^2. This patch > is still pending > review. This version applies cleanly to current trunk. > ... pdp11 is fine. Thanks! paul

Re: [PATCH] use build_function_type_list in the rs6000 backend

On Wed, Apr 20, 2011 at 3:49 PM, Nathan Froyd wrote: > As $SUBJECT suggests.  The only tricky part is in builtin_function_type, > where we fill in unused args with NULL_TREE so that passing extra > arguments to build_function_type_list doesn't matter. > > Tested with cross to powerpc-eabi.  OK to

Re: fix memory leak in gengtype

On Wed, 20 Apr 2011, Jeff Law wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/20/11 15:08, Dimitrios Apostolou wrote: Hello list, while trying to build gcc-4.6.0 on my sparcstation, I got gengtype OOM killed. That's when I noticed that its RAM usage peaks at 150MB, which is a bit ex

Re: [patch testsuite committed] Skip gcc.dg/torture/pr37868.c on sh

On Apr 20, 2011, at 5:22 AM, Kaz Kojima wrote: > Mike Stump wrote: >> I'd pre-approve hoisting these up into the lib/.exp files and checking a >> generic target requirement... :-) >> >>> -/* { dg-skip-if "unaligned access" { sparc*-*-* } "*" "" } */ >>> +/* { dg-skip-if "unaligned access" { spa

Re: fix memory leak in gengtype

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/20/11 15:08, Dimitrios Apostolou wrote: > Hello list, > > while trying to build gcc-4.6.0 on my sparcstation, I got gengtype OOM > killed. That's when I noticed that its RAM usage peaks at 150MB, which > is a bit excessive for parsing a ~500K te

Re: Fix PR48703: segfault in mangler due to -g

Hi, I wrote: > Basically we have to set assembler names early also for TYPE_DECLs, we > can't rely on the frontends langhook to do that after free_lang_data. > > Okay for trunk assuming regstrapping on x86_64-linux works? Patch retracted, doesn't even survive testsuite. The problem is that we

Re: [patch] Split Parse Timevar (issue4378056)

On 04/12/2011 11:49 AM, Lawrence Crowl wrote: This patch is available for review at http://codereview.appspot.com/4378056 I tried to comment there, but it didn't seem to be working; looking at the side-by-side diffs didn't show any changes, and double-clicking on a line in the patch form didn

Re: [PATCH] use build_function_type_list in the ia64 backend

On Wed, 2011-04-20 at 17:25 -0400, Nathan Froyd wrote: > On Wed, Apr 20, 2011 at 02:09:49PM -0700, Steve Ellcey wrote: > > I am not sure what the patch would look like then. You removed the > > assignment to decl, so what are you putting in ia64_builtins? Can you > > send the full correct patch.

Re: [PATCH] use build_function_type_list in the ia64 backend

On Wed, Apr 20, 2011 at 02:09:49PM -0700, Steve Ellcey wrote: > I am not sure what the patch would look like then. You removed the > assignment to decl, so what are you putting in ia64_builtins? Can you > send the full correct patch. Sure. Updated patch below, which probably looks somewhat more

Re: Ping^2 Re: Target header etc. cleanup patch

The m32c one is OK

Ping Re: Don't use linux.h for non-Linux targets

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

Re: [PATCH] use build_function_type_list in the ia64 backend

On Wed, 2011-04-20 at 13:03 -0700, Nathan Froyd wrote: > On Wed, Apr 20, 2011 at 03:29:19PM -0400, Nathan Froyd wrote: > > As $SUBJECT suggests. Tested with cross to ia64-linux-gnu. OK to > > commit? > > > > - ftype = build_function_type (float128_type, void_list_node); > > - decl = add

Ping^2 Re: Target header etc. cleanup patch

Ping^2. This patch is still pending review. This version applies cleanly to current trunk. 2011-04-20 Joseph Myers * config/alpha/alpha.c (struct machine_function): Use rtx, not struct rtx_def *. * config/bfi

Re: [PATCH] use build_function_type_list a few places in the ObjC frontend

On Apr 20, 2011, at 10:27 AM, Nathan Froyd wrote: > Tested on x86_64-unknown-linux-gnu. IIUC the changes to > objc-next-runtime-abi-02.c would not be tested on that platform, so it > would be helpful to have a Darwin tester double-check my work. Just check http://gcc.gnu.org/regtest/HEAD/ after a

fix memory leak in gengtype

Hello list, while trying to build gcc-4.6.0 on my sparcstation, I got gengtype OOM killed. That's when I noticed that its RAM usage peaks at 150MB, which is a bit excessive for parsing a ~500K text file. The attached patch fixes the leak and gengtype now uses a peak of 4MB heap. Hopefully I

Re: [patch] Do not generate discriminator directive in strict mode

On 04/20/2011 12:09 PM, Eric Botcazou wrote: >> How is this not redundant with the existing >> >> /* The discriminator column was added in dwarf4. Simplify the below >> by simply removing it if we're not supposed to output it. */ >> if (dwarf_version < 4 && dwarf_strict) >> discrimin

Re: Second ping for cannot_force_const_mem & LEGITIMATE_CONSTANT_P changes

On 04/18/2011 02:30 AM, Richard Sandiford wrote: > Ping for these two changes: > > http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00194.html > http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00195.html > Both ok. r~

[PATCH] use build_function_type_list in the sh backend

As $SUBJECT suggests. The only tricky bit is the initialization of `args' to NULL_TREEs so that we can safely pass all of the relevant args to build_function_type_list, regardless of whether the function type in question has that many args. Tested with cross to sh-elf. OK to commit? -Nathan

[PATCH] use build_function_type_list in the stormy16 backend

As $SUBJECT suggests. For safety's sake, we initialize all the arguments to NULL before passing them to build_function_type_list. This is not necessary currently, as we always completely fill in the args array, but it might save some future coder from quite some grief... Tested with cross to xst

[PATCH] use build_function_type_list in the spu backend

As $SUBJECT suggests. The only tricky bit is initializing all the args to NULL_TREE so that we can safely pass all the args to build_function_type_list. Tested with cross to spu-elf; I couldn't build all of libgcc, but that appears to be a pre-existing problem. OK to commit? -Nathan *

Re: [PATCH] use build_function_type_list in the pa backend

> * config/pa/pa.c (pa_init_builtins): Call build_function_type_list > instead of build_function_type. Ok. Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602)

Re: [PATCH] use build_function_type_list in the ia64 backend

On Wed, Apr 20, 2011 at 03:29:19PM -0400, Nathan Froyd wrote: > As $SUBJECT suggests. Tested with cross to ia64-linux-gnu. OK to > commit? > > - ftype = build_function_type (float128_type, void_list_node); > - decl = add_builtin_function ("__builtin_infq", ftype, > -

[PATCH] use build_function_type_list in the arm backend

As $SUBJECT suggests. There's one remaining use of build_function_type, but replace that will have to wait until we have a better FUNCTION_TYPE-building interface. Tested with cross to arm-eabi. OK to commit? -Nathan * config/arm/arm.c (arm_init_iwmmxt_builtins): Call build_fun

[PATCH] use build_function_type_list in the pa backend

As $SUBJECT suggests. Tested with cross to hppa-linux-gnu. OK to commit? -Nathan * config/pa/pa.c (pa_init_builtins): Call build_function_type_list instead of build_function_type. diff --git a/gcc/config/pa/pa.c b/gcc/config/pa/pa.c index e05cf19..aeb8061 100644 --- a/gcc/confi

[PATCH] use build_function_type_list in the avr backend

As $SUBJECT suggests. Tested with cross to avr-elf. OK to commit? -Nathan * config/avr/avr.c (avr_init_builtins): Call build_function_type_list instead of build_function_type. diff --git a/gcc/config/avr/avr.c b/gcc/config/avr/avr.c index 500a5b2..6dbf8b4 100644 --- a/gcc/confi

[PATCH, i386]: Expand insv pattern to pinsr{q,w,d,q} insn

Hello! Attached patch enhances the fix for PR target/48678 to generate pinsr{q,w,d,q} insn when value is inserted into vector register. 2011-04-20 Uros Bizjak PR target/48678 * config/i386/i386.md (insv): Change operand 0 constraint to "register_operand". Change opera

[PATCH] use build_function_type_list in the picochip backend

As $SUBJECT suggests. Tested with cross to picochip-elf. OK to commit? -Nathan * config/picochip/picochip.c (picochip_init_builtins): Call build_function_type_list instead of build_function_type. Delete `endlink' variable. diff --git a/gcc/config/picochip/picochip.c b/g

[PATCH] use build_function_type_list in the rs6000 backend

As $SUBJECT suggests. The only tricky part is in builtin_function_type, where we fill in unused args with NULL_TREE so that passing extra arguments to build_function_type_list doesn't matter. Tested with cross to powerpc-eabi. OK to commit? -Nathan * config/rs6000/rs6000.c (spe_init_bu

Re: [PATCH] use build_function_type_list in the mips backend

Nathan Froyd writes: > * config/mips/mips.c (mips16_build_function_stub): Call > build_function_type_list instead of build_function_type. > (mips16_build_call_stub): Likewise. OK, thanks, but: > - build_function_type (void_type_node, NULL_TREE)); > +

[PATCH] use build_function_type_list in the xtensa backend

As $SUBJECT suggests. Tested with cross to xtensa-elf. OK to commit? -Nathan * config/xtensa/xtensa.c (xtensa_init_builtins): Call build_function_type_list instead of build_function_type. diff --git a/gcc/config/xtensa/xtensa.c b/gcc/config/xtensa/xtensa.c index fe70270..574e08

[PATCH] use build_function_type_list in the sparc backend

As $SUBJECT suggests. Tested with cross to sparc-elf. OK to commit? -Nathan * config/sparc/sparc.c (sparc_file_end): Call build_function_type_list instead of build_function_type. diff --git a/gcc/config/sparc/sparc.c b/gcc/config/sparc/sparc.c index 03b5e66..e7dd75b 100644 ---

[PATCH] use build_function_type_list in the s390 backend

As $SUBJECT suggests. Tested with cross to s390-linux-gnu. OK to commit? -Nathan * config/s390/s390.c (s390_init_builtins): Call build_function_type_list instead of build_function_type. diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c index caee077..adacfa3 100644 -

C++ PATCH for c++/48657 (rejects-valid with local variable used as non-type template argument)

The problem in this testcase was that we were recognizing a local const variable with a constant initializer as a constant expression, but we weren't doing the necessary adjustments to convert the initializer to the type of the variable. But some of the other bits of cp_finish_decl caused prob

Re: [PATCH] use build_function_type_list in the mep backend

> * config/mep/mep.c (mep_init_builtins): Call build_function_type_list > instead of build_function_type. Ok.

[PATCH] use build_function_type_list in the mips backend

As $SUBJECT suggests. Tested with cross to mips-elf. OK to commit? -Nathan * config/mips/mips.c (mips16_build_function_stub): Call build_function_type_list instead of build_function_type. (mips16_build_call_stub): Likewise. diff --git a/gcc/config/mips/mips.c b/gcc/conf

[PATCH] use build_function_type_list in the mep backend

As $SUBJECT suggests. Tested with cross to mep-elf. OK to commit? -Nathan * config/mep/mep.c (mep_init_builtins): Call build_function_type_list instead of build_function_type. diff --git a/gcc/config/mep/mep.c b/gcc/config/mep/mep.c index 02c825a..b8ef440 100644 --- a/gcc/confi

[PATCH] use build_function_type_list in the iq2000 backend

As $SUBJECT suggests. Tested with cross to iq2000-elf. OK to commit? -Nathan * config/iq2000/i2000.c (iq2000_init_builtins): Call build_function_type_list instead of build_function_type. Delete `endlink' variable. diff --git a/gcc/config/iq2000/iq2000.c b/gcc/config/iq2

[PATCH] use build_function_type_list in the ia64 backend

As $SUBJECT suggests. Tested with cross to ia64-linux-gnu. OK to commit? -Nathan * config/ia64/ia64.c (ia64_init_builtins): Call build_function_type_list instead of builtin_function_type. diff --git a/gcc/config/ia64/ia64.c b/gcc/config/ia64/ia64.c index 5f22b17..166ec43 100644

[PATCH] use build_function_type_list in the i386 backend

As $SUBJECT suggests. There's still one use of build_function_type; replacing that type will have to wait for an improved FUNCTION_TYPE-building interface. Tested on x86_64-unknown-linux-gnu. OK to commit? -Nathan * config/i386/i386.c (ix86_code_end): Call build_function_type_list

[PATCH] use build_function_type_list in the frv backend

As $SUBJECT suggests. Tested with cross to frv-elf. OK to commit? -Nathan * config/frv/frv.c (frv_init_builtins): Delete `endlink' variable. Call builtin_function_type_list instead of builtin_function_type. (UNARY, BINARY, TRINARY, QUAD): Likewise. diff --git a/gcc/conf

[PATCH] use build_function_type_list in the bfin backend

As $SUBJECT suggests. Tested with cross to bfin-elf. OK to commit? -Nathan * config/bfin/bfin.c (bfin_init_builtins): Call build_function_type_list instead of build_function_type. diff --git a/gcc/config/bfin/bfin.c b/gcc/config/bfin/bfin.c index 5d08437..03a833d 100644 --- a/g

[PATCH] use build_function_type_list in the alpha backend

As $SUBJECT suggests. Tested with cross to alpha-elf. OK to commit? -Nathan * config/alpha/alpha.c (alpha_init_builtins): Call build_function_type_list instead of build_function_type. diff --git a/gcc/config/alpha/alpha.c b/gcc/config/alpha/alpha.c index 5e85e2b..237e9b3 100644

Re: FDO usability: pid handling

Please review the latest patch. SPEC2k FDO testing pass. Thanks, David On Wed, Apr 20, 2011 at 11:22 AM, Xinliang David Li wrote: > Here is the revised patch. Basic FDO testing went fine. I still saw > the ipa-inline assertion in SPEC FDO. Will run it when the regression > is fixed. > > Thanks,

Re: [patch] Do not generate discriminator directive in strict mode

> How is this not redundant with the existing > > /* The discriminator column was added in dwarf4. Simplify the below > by simply removing it if we're not supposed to output it. */ > if (dwarf_version < 4 && dwarf_strict) > discriminator = 0; > > check near the top of the function?

Re: Allow union variables to share stack slots wwith -fno-strict-aliasing (issue4444051)

On Wed, Apr 20, 2011 at 2:12 AM, Eric Botcazou wrote: >> 2011-04-19  Easwaran Raman   >> >>       * gcc/testsuite/gcc.dg/stack-layout-1.c: New >>       * gcc/cfgexpand.c (add_alias_set_conflicts): Add conflicts >>       with a variable containing union type only with >>       -fstrict-aliasing. >

Re: FDO usability: pid handling

Discard this version of the patch. I have not updated source properly and the build/test was invalid. David On Wed, Apr 20, 2011 at 11:22 AM, Xinliang David Li wrote: > Here is the revised patch. Basic FDO testing went fine. I still saw > the ipa-inline assertion in SPEC FDO. Will run it when th

unnecessary test before free changes committed

FYI, I've just pushed the following two change sets. I verified that "make check" on x86_64 produced the same set of 92 failures without as with my changes. However, when I ran "make check MALLOC_PERTURB_=0 MALLOC_CHECK_=0", I saw only 91 failures. (normally those MALLOC_*_ variables are set to no

Added myself to MAINTAINERS (write after approval)

Changelog: 2011-04-20 Easwaran Raman * MAINTAINERS (Write After Approval): Add myself. Index: MAINTAINERS === --- MAINTAINERS (revision 172782) +++ MAINTAINERS (working copy) @@ -455,6 +455,7 @@ Yao Qi

Re: FDO usability: pid handling

Here is the revised patch. Basic FDO testing went fine. I still saw the ipa-inline assertion in SPEC FDO. Will run it when the regression is fixed. Thanks, David On Tue, Apr 19, 2011 at 5:33 PM, Jan Hubicka wrote: >> On Tue, Apr 19, 2011 at 4:49 PM, Jan Hubicka wrote: >> >> Actually, among all

[Patch, Fortran, committed] PR 48692 - Fix gfortran.dg/module_write_1.f90 failure

The committal of the patch for PR 48588 caused that gfortran.dg/module_write_1.f90 was now failing (ICE). After some debugging (cf. PR 48692) it turned out that it only worked by chance before. The attached patch fixes the issue more properly. (The ICE occurred as a check whether all symbols w

Re: [PATCH] Stop in note_eh_region_may_contain_throw after ERT_MUST_NOT_THROW (PR tree-optimization/48611)

On 04/18/2011 02:35 PM, Jakub Jelinek wrote: > PR tree-optimization/48611 > * tree-eh.c (note_eh_region_may_contain_throw): Don't propagate > beyond ERT_MUST_NOT_THROW region. Ok. r~

Re: Improve stack layout heuristic.

On Wed, Apr 20, 2011 at 6:53 AM, Michael Matz wrote: > Hi, > > On Tue, 19 Apr 2011, Easwaran Raman wrote: > >> > That is correct but is also what the use of stack_vars[u].representative >> > achieves alone, ... >> > >> >> I am adding a check to that effect. >> > >> > ... without any check. >> > >>

Re: [patch] Do not generate discriminator directive in strict mode

On 04/19/2011 06:40 AM, Eric Botcazou wrote: > - if (SUPPORTS_DISCRIMINATOR && discriminator != 0) > + if (SUPPORTS_DISCRIMINATOR > + && discriminator != 0 > + && (dwarf_version >= 4 || !dwarf_strict)) > fprintf (asm_out_file, " discriminator %d", discriminator); How is

[Patch,AVR]: Solve PR42210

This solves some missed optimization that can be seen when moving around bits. There are 4 combiner patterns that operate on regs and one that uses them as intermediate patterns and works on I/O. Even if just an intermediate pattern matches it's still an improvement because avoid of shift. Tested

Re: [patch middle-end]: Missed optimization for (x & ~y) | (~x & y)

2011/4/20 Kai Tietz : > 2011/4/20 Richard Henderson : >> On 04/20/2011 08:50 AM, Kai Tietz wrote: >>> +      if (TREE_CODE (arg0) == TREE_CODE (arg1) >>> +       && TREE_CODE (arg1) == TRUTH_AND_EXPR) >> >> Ok with these both explicitly testing TRUTH_AND_EXPR now. >> >> >> r~ >> > > Committed at re

Re: [pph] Namespaces, step 1. Trace formatting. (issue4433054)

On 4/20/11, dnovi...@google.com wrote: > http://codereview.appspot.com/4433054/diff/1/gcc/cp/pph-streamer.c > File gcc/cp/pph-streamer.c (right): > > http://codereview.appspot.com/4433054/diff/1/gcc/cp/pph-streamer.c#newcode144 > gcc/cp/pph-streamer.c:144: return; > + if ((type == PPH_TRACE_TREE

Re: [PATCH] Optimize (x * 8) | 5 and (x << 3) ^ 3 to use lea (PR target/48688)

On 04/20/2011 09:09 AM, Jakub Jelinek wrote: > Hi! > > This splitter allows us to optimize (x {* {2,4,8},<< {1,2,3}}) {|,^} y > for constant integer y <= {1ULL,3ULL,7ULL} using lea{l,q} (| or ^ in > that case, when the low bits are known to be all 0, is like plus). > > Bootstrapped/regtested on x

[PATCH] use build_function_type_list a few places in the ObjC frontend

Just as $SUBJECT suggests. All the other uses of build_function_type_list are tied up with get_arg_type_list and will therefore have to wait for a better FUNCTION_TYPE builder. Tested on x86_64-unknown-linux-gnu. IIUC the changes to objc-next-runtime-abi-02.c would not be tested on that platform

Re: [Patch,AVR]: FIX ICE in optabs due to bad rotate expander.

On 04/19/2011 02:52 AM, Denis Chertykov wrote: > 2011/4/19 Georg-Johann Lay : >> How can add, sub etc. be split? This would need an explicit >> representation of carry. > > Yes. > > Look at http://gcc.gnu.org/ml/gcc/2005-03/msg00871.html Well, sort-of, but not really. It gets a tad ugly, but ha

[PATCH] make Ada runtime function building use build_function_type_list

This patch changes most of the uses of build_function_type in the Ada to use build_function_type_list. There are a handful of build_function_type calls left; replacing those will have to wait until we get a build_function_type_{n,vec} interface. Tested on x86_64-unknown-linux-gnu. OK to commit?

Re: [PATCH][ARM] New testcases for NEON

On 19/04/11 15:58, Richard Earnshaw wrote: OK. 2008-12-03 Daniel Jacobowitz gcc/testsuite/ * gcc.dg/vect/vect-shift-3.c, gcc.dg/vect/vect-shift-4.c: New. * lib/target-supports.exp (check_effective_target_vect_shift_char): New function. Committed, thanks.

Re: [PATCH][ARM] Clean up movw support

On 20/04/11 16:46, Richard Earnshaw wrote: 2011-04-20 Andrew Stubbs gcc/ * config/arm/arm.c (arm_gen_constant): Move mowv support (const_ok_for_op): ... to here. it's movw (not mowv :) Otherwise OK. Committed, thanks. Andrew

Re: FDO usage: -Wcoverage-mismatch should not ignore -Wno-error

This would work if there is a way to set Werror=coverage-mismatch without having to explicitly set the option classification as DK_ERROR. Does this mechanism exist? Thanks, David On Tue, Apr 19, 2011 at 12:52 AM, Richard Guenther wrote: > On Tue, Apr 19, 2011 at 9:13 AM, Xinliang David Li wr

Re: [patch middle-end]: Missed optimization for (x & ~y) | (~x & y)

2011/4/20 Richard Henderson : > On 04/20/2011 08:50 AM, Kai Tietz wrote: >> +      if (TREE_CODE (arg0) == TREE_CODE (arg1) >> +       && TREE_CODE (arg1) == TRUTH_AND_EXPR) > > Ok with these both explicitly testing TRUTH_AND_EXPR now. > > > r~ > Committed at revision 172776 with explicit testing

Re: [PATCH][ARM] Remove redundant code in arm.c

On 20/04/11 16:34, Richard Earnshaw wrote: On Wed, 2011-04-20 at 13:55 +0100, Andrew Stubbs wrote: This patch removes some redundant code that caused me some confusion. It's not possible to construct a constant from multiple ORN instructions, just as it's not possible to do it with multiple AND

[PATCH] Optimize (x * 8) | 5 and (x << 3) ^ 3 to use lea (PR target/48688)

Hi! This splitter allows us to optimize (x {* {2,4,8},<< {1,2,3}}) {|,^} y for constant integer y <= {1ULL,3ULL,7ULL} using lea{l,q} (| or ^ in that case, when the low bits are known to be all 0, is like plus). Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2011-04-20 Jaku

Fix PR48703: segfault in mangler due to -g

Hi, as noted in the bug trail the fix for PR48207 broke compilation of C++ programs with -g. This variant fixes the bug too without breaking -g. Basically we have to set assembler names early also for TYPE_DECLs, we can't rely on the frontends langhook to do that after free_lang_data. Okay fo

Re: [patch middle-end]: Missed optimization for (x & ~y) | (~x & y)

2011/4/20 Jakub Jelinek : > On Wed, Apr 20, 2011 at 05:22:31PM +0200, Kai Tietz wrote: >> --- gcc.orig/gcc/fold-const.c 2011-04-20 17:10:39.478091900 +0200 >> +++ gcc/gcc/fold-const.c      2011-04-20 17:11:22.901039400 +0200 >> @@ -10660,6 +10660,28 @@ fold_binary_loc (location_t loc, >>         &&

Re: [patch middle-end]: Missed optimization for (x & ~y) | (~x & y)

On 04/20/2011 08:50 AM, Kai Tietz wrote: > + if (TREE_CODE (arg0) == TREE_CODE (arg1) > + && TREE_CODE (arg1) == TRUTH_AND_EXPR) Ok with these both explicitly testing TRUTH_AND_EXPR now. r~

Re: [patch middle-end]: Missed optimization for (x & ~y) | (~x & y)

2011/4/20 Richard Henderson : > On 04/20/2011 08:22 AM, Kai Tietz wrote: >> +      if (TREE_CODE (arg0) == BIT_AND_EXPR >> +       && TREE_CODE (arg1) == BIT_AND_EXPR) >> +        { >> +       tree a0, a1, l0, l1, n0, n1; >> + >> +       a0 = fold_convert_loc (loc, type, TREE_OPERAND (arg1, 0)); >>

[PATCH] Fix PR47892

This fixes PR47892, we are failing to if-convert function calls, even those we can vectorize. This includes pow() which we canonicalize x*x to with -ffast-math (yeah, I know ...). No reason to not if-convert at least const builtins. Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to

Re: [PATCH][ARM] Clean up movw support

On Wed, 2011-04-20 at 15:20 +0100, Andrew Stubbs wrote: > This patch doesn't change the compiler behaviour; it merely moves the > support for MOVW's 16-bit immediate constant to const_ok_for_op. > > This patch is broken out of my previous (rejected) Thumb2-constants > patch. I'll be posting v2 o

Re: [PATCH][ARM] Add support for ADDW and SUBW instructions

On 20/04/11 16:27, Andrew Stubbs wrote: (*arm_subsi3_insn): Add subw support. Oh, I should probably say that I've added subw support to arm_subsi3 even though it's not obvious that anything will ever use this. The existing implementation of arm_subsi3 (sans 'w') supports immediates,

Re: [patch middle-end]: Missed optimization for (x & ~y) | (~x & y)

On Wed, Apr 20, 2011 at 05:22:31PM +0200, Kai Tietz wrote: > --- gcc.orig/gcc/fold-const.c 2011-04-20 17:10:39.478091900 +0200 > +++ gcc/gcc/fold-const.c 2011-04-20 17:11:22.901039400 +0200 > @@ -10660,6 +10660,28 @@ fold_binary_loc (location_t loc, > && reorder_operands_p (arg0, TREE_

Re: [patch middle-end]: Missed optimization for (x & ~y) | (~x & y)

On 04/20/2011 08:22 AM, Kai Tietz wrote: > + if (TREE_CODE (arg0) == BIT_AND_EXPR > + && TREE_CODE (arg1) == BIT_AND_EXPR) > +{ > + tree a0, a1, l0, l1, n0, n1; > + > + a0 = fold_convert_loc (loc, type, TREE_OPERAND (arg1, 0)); > + a1 = fold_convert_loc (loc, ty

Re: [PATCH][ARM] Remove redundant code in arm.c

On Wed, 2011-04-20 at 13:55 +0100, Andrew Stubbs wrote: > This patch removes some redundant code that caused me some confusion. > > It's not possible to construct a constant from multiple ORN > instructions, just as it's not possible to do it with multiple AND > instructions. > > OK? > > Andr

Re: [patch, ARM] PR48250, rehaul arm_legitimize_reload_address()

On 2011/4/20 11:12 PM, Richard Earnshaw wrote: > > On Wed, 2011-04-20 at 23:06 +0800, Chung-Lin Tang wrote: >> On 2011/4/20 09:24 PM, Richard Sandiford wrote: >>> Hi Chung-Lin, >>> >>> I'm seeing an ICE with this patch, specifically; >>> >>> Chung-Lin Tang writes: + if (coproc_p) +

[PATCH][ARM] Add support for ADDW and SUBW instructions

This patch adds basic support for the Thumb ADDW and SUBW instructions. The patch permits the compiler to use the new instructions for constants that can be loaded with a single instruction (i.e. 16-bit unshifted), but does not support use of addw with split-constants; I have a patch for that

libgo patch committed: Remove empty directory

I committed a patch to remove the now-empty directory libgo/go/crypto/block. Ian

Re: [PATCH] Fix incorrect devirtualization (PR middle-end/48661)

> On Wed, 20 Apr 2011, Jan Hubicka wrote: > > > > Hi, > > > > > > On Tue, Apr 19, 2011 at 02:15:18AM +0200, Jan Hubicka wrote: > > > > Actually what happens here is that CCP devirtualize by propagating the > > > > constructors and due to Richard's new code to drop OBJ_TYPE_REF we > > > > finally

Re: [PATCH] Fix incorrect devirtualization (PR middle-end/48661)

Hi, On Wed, Apr 20, 2011 at 04:38:25PM +0200, Jan Hubicka wrote: > > Hi, > > > > On Tue, Apr 19, 2011 at 02:15:18AM +0200, Jan Hubicka wrote: > > > Actually what happens here is that CCP devirtualize by propagating the > > > constructors and due to Richard's new code to drop OBJ_TYPE_REF we > >

[patch middle-end]: Missed optimization for (x & ~y) | (~x & y)

Hello, well the bonus points might gain somebody else ... But this adds a missing optimization for tree level implemented in fold-const. ChangeLog gcc/ 2011-04-20 Kai Tietz * fold-const.c (fold_binary_loc): Add handling for (X & ~Y) | (~X & Y) and (X && !Y) | (!X && Y) optimiza

Re: [PATCH] Fix incorrect devirtualization (PR middle-end/48661)

On Wed, 20 Apr 2011, Jan Hubicka wrote: > > Hi, > > > > On Tue, Apr 19, 2011 at 02:15:18AM +0200, Jan Hubicka wrote: > > > Actually what happens here is that CCP devirtualize by propagating the > > > constructors and due to Richard's new code to drop OBJ_TYPE_REF we > > > finally get > > > a dir

Re: better wpa [1/n]: merge types during read-in

Hi, On Wed, 20 Apr 2011, Richard Guenther wrote: > >> If t is a type, why fix up its field if it may not be the canonical > >> variant? > > > > Because type merging to work sometimes requires already canonicalized > > fields, at least that's what I found in investigating why some types > > weren

Re: [patch, ARM] PR48250, rehaul arm_legitimize_reload_address()

On Wed, 2011-04-20 at 23:06 +0800, Chung-Lin Tang wrote: > On 2011/4/20 09:24 PM, Richard Sandiford wrote: > > Hi Chung-Lin, > > > > I'm seeing an ICE with this patch, specifically; > > > > Chung-Lin Tang writes: > >> + if (coproc_p) > >> + low = SIGN_MAG_LOW_ADDR_BITS (val, 10); > > > >

Re: [pph] Namespaces, step 1. Trace formatting. (issue4433054)

http://codereview.appspot.com/4433054/diff/1/gcc/cp/pph-streamer.c File gcc/cp/pph-streamer.c (right): http://codereview.appspot.com/4433054/diff/1/gcc/cp/pph-streamer.c#newcode144 gcc/cp/pph-streamer.c:144: return; + if ((type == PPH_TRACE_TREE || type == PPH_TRACE_CHAIN) + && !data && fl

Re: [patch, ARM] PR48250, rehaul arm_legitimize_reload_address()

On 2011/4/20 09:24 PM, Richard Sandiford wrote: > Hi Chung-Lin, > > I'm seeing an ICE with this patch, specifically; > > Chung-Lin Tang writes: >> + if (coproc_p) >> +low = SIGN_MAG_LOW_ADDR_BITS (val, 10); > > We generate: > > Reload 1: reload_out (V4SI) = (mem/c:V4SI (plus:SI (plus:

[vms/committed]: fix ICE on alpha-vms

Hi, This patch fixes a compiler crash for alpha-vms. Back-ends should not lie to the middle-end by defining macros to plain abort since the middle-end is entitled to infer properties from their existence. The correct thing to do is not to define the macros in the first place. Committed on trunk

Re: [google]Pass --save-temps to the assembler (issue4436049)

On Tue, Apr 19, 2011 at 20:32, Easwaran Raman wrote: > The revised patch has a comment that this should be used with an > assembler wrapper that can recognize --save-temps. Thanks. Will commit after testing finishes. Diego.

Re: [RFA] MIPS 24K Errata Support

Catherine Moore writes: > +Work around the 24K E48 Lost Data on Stores during Refill errata. I think this should either be: Work around the 24K E48 (@cite{Lost Data on Stores During Refill}) errata. or: Work around the 24K E48 (lost data on stores during refill) errata. Maybe the second i

Re: [PATCH] Fix incorrect devirtualization (PR middle-end/48661)

> Hi, > > On Tue, Apr 19, 2011 at 02:15:18AM +0200, Jan Hubicka wrote: > > Actually what happens here is that CCP devirtualize by propagating the > > constructors and due to Richard's new code to drop OBJ_TYPE_REF we finally > > get > > a direct call. This is all good and desirable. > > > > I t

[committed/vms]: do not use vms-dwarf2.o for gnu-ld

Hi, when gnu-ld is used, we do not need the extra vms-dwarf2.o file - which is needed only for the native vms linker. Committed on trunk. Tristan. 2011-04-20 Tristan Gingold * config/alpha/vms.h (LINK_SPEC): Do not use vms-dwarf2.o for gnu-ld.

  1   2   >