Re: ARM constant folding bug?

On Fri, Aug 03, 2007 at 06:24:06PM +0100, Paul Brook wrote: On Friday 03 August 2007, Jonathan S. Shapiro wrote: Then it seems very curious that the constant folding should fail on this platform. Any idea what may be going on here? You're exploiting a hole in the C aliasing rules by

[lto] project: adding --with-libelf to configure

The LTO driver requires libelf and currently grovels around in the system directories looking for it, which may not always be the right place to find it. (This bit me when building LTO on our new Linux machines, which do not have libelf installed.) The Right Thing would be to add a --with-libelf

[lto] preliminary SPECint benchmark numbers

In one of my recent messages about a patch to the LTO branch, I mentioned that we could compile and successfully run all of the C SPECint benchmarks except 176.gcc. Chris Lattner asked if I had done any benchmarking now that real programs could be run; I said that I hadn't but would try to do

Re: Is anyone testing for a (cross-) target (board) with dynlinking?

On Tue, Feb 12, 2008 at 02:47:39AM +0100, Hans-Peter Nilsson wrote: Is it as simple as nobody having tested cross-gcc setups for targets with dynamic linking, or are they incorrectly using the wrong (the installed, not the newly compiled) libgcc_s.so.1? Or how did you do it? NFS mounts on

Re: Is anyone testing for a (cross-) target (board) with dynlinking?

On Tue, Feb 12, 2008 at 05:13:45AM +0100, Hans-Peter Nilsson wrote: From: Nathan Froyd [EMAIL PROTECTED] One way to do it is with NFS mounts and setting -Wl,-dynamic-linker -Wl,-rpath for your ldflags. Thanks to you and David Daney. Have you used it yourself? Apparently tricks

Re: GCC 4.3.0-20080228 (powerpc-linux-gnuspe) ICE on 20000718.c test

On Mon, Mar 10, 2008 at 03:22:13PM +0300, Sergei Poselenov wrote: I've got the ICE on the gcc.c-torture/compile/2718.c test: powerpc-linux-gnuspe-gcc -c -O3 -funroll-loops 2718.c 2718.c: In function 'baz': 2718.c:14: internal compiler error: Segmentation fault Please submit a

Re: [PATCH,rs6000] split up crtsavres into individual files

they were previously. OK to commit as is? Or should I do a testing run as well? -Nathan libgcc/ 2008-06-24 Nathan Froyd [EMAIL PROTECTED] * config/rs6000/t-ppccomm: Remove rules that conflict with auto-generated rules. Index: config/rs6000/t-ppccomm

Re: gcc-4.3.2 generated vmhraddshs instruction when I compiled with -mcpu=8540

On Tue, Dec 16, 2008 at 12:28:10PM +0700, Ha Luong wrote: I used gcc-4.3.2 to compile the c source(*) and it generated vmhraddshs instruction when I compiled with -mcpu=8540. 000103A4: 11EB0321 vmhraddshs vr15,vr11,vr0,vr12 You are running into the problem that the Altivec and SPE opcode

Re: gcc-4.3.2 generated vmhraddshs instruction when I compiled with -mcpu=8540

On Wed, Dec 17, 2008 at 01:33:38PM +0700, Ha Luong wrote: Thanks for your guide. When I debugged the exe file or make it ran on 8548 board, the vmhaddshs makes the exe file hang out. Could I compile the source for 8540 (e500v1 instructions) only? Sure. But evstdd{,x} are e500v1 instructions

Re: Binary Autovectorization

On Thu, Jan 29, 2009 at 04:46:37PM -0500, Rodrigo Dominguez wrote: I am looking at binary auto-vectorization or taking a binary and rewriting it to use SIMD instructions (either statically or dynamically). I was wondering if anyone knew of similar work and could help me with some links.

Re: Preserving the argument spills for GDB

On Wed, Nov 04, 2009 at 11:24:34AM -0500, Jean Christophe Beyler wrote: However, I've been going through the first step : running GDB, setting a break-point and doing a continue to see what I get and try to get the information right for O3 too. In O0, I get: Breakpoint @@ 1, foo (a=4, b=3,

Re: PowerPC : GCC2 optimises better than GCC4???

On Mon, Jan 04, 2010 at 04:08:17PM +, Andrew Haley wrote: On 01/04/2010 12:07 PM, Jakub Jelinek wrote: IMHO we really should have some late tree pass that converts adjacent bitfield operations into integral operations on non-bitfields (likely with alias set of the whole containing

Re: RTL question for I64

On Thu, Feb 11, 2010 at 09:43:31AM -0800, Douglas B Rupp wrote: A pointer would be much appreciated! In ia64.md for *cmpdi_normal this is found: cmp.%C1 %0, %I0 = %3, %r2 Where are %C, %I, %r described? Above gcc/config/ia64/ia64.c:ia64_print_operand. -Nathan

Re: Gprof can account for less than 1/3 of execution time?!?!

On Mon, Feb 22, 2010 at 03:23:52PM -0600, Jon Turner wrote: In it, you will find a directory with all the source code needed to observe the problem for yourself. The top level directory contains a linux executable called maxFlo, which you should be able to run on a linux box as is. But if you

Re: Compiling OpenCV 2.0 on Solaris 10 with GCC 4.4.3

On Wed, Mar 10, 2010 at 01:30:36PM +, Nick Fielding wrote: The first syntax error the compiler complains about I think is the main problem: /tmp/OpenCV-2.0.0/src/cxcore/cxmatmul.cpp:673: error: expected ',' or '...' before numeric constant However, when I look at the line of code it's

Re: Questions about Handle constant exponents. in gcc/builtins.c

On Thu, Mar 18, 2010 at 04:34:56PM +0100, Vincent Lefevre wrote: On 2010-03-18 15:32:04 +0100, Michael Matz wrote: But unfortunately you are right, this expansion can only be done for -fno-signed-zeros. (FWIW the general expandsion of pow(x,N/2) where N!=1 is already guarded by unsafe_math,

Re: Vanilla cross compiling and libstdc++v3

On Mon, Apr 05, 2010 at 10:29:07AM -0430, Kofi Doku Atuah wrote: The process of building a simply, plain vanilla cross compiler for arch-fmt-no_os is really probably overdone. To build, for example, a GCC cross compiler for an i586-elf target, the build process requires you to have a libc for

Re: lower subreg optimization

On Tue, Apr 06, 2010 at 09:58:23AM -0700, Ian Lance Taylor wrote: In the code the register is always accessed via a subreg, so the lower-subregs pass thinks that it is OK to decompose the register. Once it is decomposed, nothing is expected to put it back together. To fix this, you should

Re: lower subreg optimization

On Tue, Apr 06, 2010 at 11:55:01AM -0700, Ian Lance Taylor wrote: Nathan Froyd froy...@codesourcery.com writes: Compiling anything that uses doubles on powerpc e500v2 produces awful code due in part to lower-subregs (the register allocator doesn't help, either, but that's a different story

Re: i386 SSE Test Question

On Mon, Apr 12, 2010 at 09:47:04AM -0500, Joel Sherrill wrote: qemu with no cpu argument specified. So qemu32. It does run OK when I change the cpu model to 486 or pentium. Is qemu reporting that it supports SSE and not doing a good enough job to make gcc happen? I think that's quite

Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

On Wed, Apr 14, 2010 at 11:30:44AM -0400, Diego Novillo wrote: On Wed, Apr 14, 2010 at 11:18, Manuel López-Ibáñez lopeziba...@gmail.com wrote: Otherwise, as Ian said in another topic [2]: I have a different fear: that gcc will become increasing irrelevant. That's my impression, as well.

Re: Notes from the GROW'10 workshop panel (GCC research opportunities workshop)

On Wed, Apr 14, 2010 at 09:49:08PM +0200, Basile Starynkevitch wrote: Toon Moene wrote: Mutatis mutandis, the same goes for GCC: There might be too many hurdles to use GCC in academia. This is probably true, however, the plugin ability of the just released GCC 4.5 (or is it released

Re: GCC 4.5.0 Released

On Mon, Apr 19, 2010 at 09:35:44AM -0400, Jack Howarth wrote: The annoucement should probably note that targets which lack objdump currently can't build plugins. I've had about as much luck getting the patch to fix this... http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00610.html

Re: Passing options down to assembler and linker

On Fri, Apr 23, 2010 at 01:55:48PM -0400, Jean Christophe Beyler wrote: I know we can pass -Wl,option, -Wa,option from gcc down to as and ld however if I have to write : gcc -mArch2 -Wl,--arch2 -Wa,--arch2 hello.c it gets a bit redundant, I must be blind because I can't seem to find how

Re: powerpc-eabi-gcc no implicit FPU usage

On Thu, May 20, 2010 at 08:59:32PM -0700, Mark Mitchell wrote: David Edelsohn wrote: No one disagrees with the potential benefit of the feature. OK; I must have misremembered. I believe our current implementation keeps track of FP usage through the front-end, and then disables any

Re: Bootstrap failed for i386-pc-solaris2.10 and sparc-sun-solaris2.10

On Fri, Jun 04, 2010 at 01:44:02PM +, Art Haas wrote: This morning's i386 build fails with the following error: libbackend.a(sol2.o): In function `solaris_output_init_fini': /home/ahaas/gnu/gcc.git/gcc/config/sol2.c:109: undefined reference to `print_operand'

Re: Bootstrap failed for i386-pc-solaris2.10 and sparc-sun-solaris2.10

On Fri, Jun 04, 2010 at 07:45:20AM -0700, Ian Lance Taylor wrote: Nathan Froyd froy...@codesourcery.com writes: * config/i386/i386-protos.h (ix86_print_operand): Declare. * config/i386/i386.c (ix86_print_operand): Make non-static. * config/i386/sol2.h (ASM_OUTPUT_CALL): Call

Re: Bootstrap failed for i386-pc-solaris2.10 and sparc-sun-solaris2.10

On Fri, Jun 04, 2010 at 08:32:26AM -0700, Ian Lance Taylor wrote: Nathan Froyd froy...@codesourcery.com writes: Looking at things a little more closely, output_address is exported in output.h. I suppose output_operand should be exported there as well? Yes, put the declaration

Re: Question about type conversion when GCC compile the file?

On Wed, Feb 18, 2009 at 06:03:58PM +0800, JCX wrote: Hello, After I compile the following file for testing, I check the dump file called 129t.final_cleanup. I doubt about why the type short int changes into short unsigned int during the array operations, and at last changes back to short

Re: Question about type conversion when GCC compile the file?

On Wed, Feb 18, 2009 at 05:55:43AM -0800, Nathan Froyd wrote: On Wed, Feb 18, 2009 at 06:03:58PM +0800, JCX wrote: Hello, After I compile the following file for testing, I check the dump file called 129t.final_cleanup. I doubt about why the type short int changes into short unsigned

Re: constant propagation optimization

On Thu, Mar 05, 2009 at 11:39:45AM +, charfi asma wrote: intc; int main() { Calcul ca; c=3; ca.affich(); ca.inc(c); cout the value of c is c endl; return 0; } [...] int main() { Calcul ca; ca.affich(); c=3; ca.inc(c); cout the value of c is c

Re: generating functions and eh region

On Fri, Apr 03, 2009 at 08:05:47PM +0100, Dave Korn wrote: Ian Lance Taylor wrote: No fundamental difficulty that I know of. Lots of tedious work for every backend setting RTX_FRAME_RELATED_P and adding REG_FRAME_RELATED_EXPR notes to the manually constructed epilogue insns. I think

Re: Gimple Pass

On Fri, Jul 24, 2009 at 05:20:16AM -0700, pms wrote: But I want to know what are the TREE_CODEs for other remaing constructs viz declration stmt, conditions, count for constants and how to use them in the gimple pass. Can anybody help in this regard The names are defined in tree.def.

Re: Better performance on older version of GCC

On Fri, Aug 27, 2010 at 09:44:25AM -0400, Corey Kasten wrote: I find that the executable compiled on system A runs faster (on both systems) than the executable compiled on system B (on both system), by a factor about approximately 4 times. I have attempted to play with the GCC optimizer flags

Re: passing #define-d values to #define-d macros

On Sun, Sep 26, 2010 at 06:09:34PM -0700, ir_idjit wrote: i can seem to get this to work: #define PREFIX p_ #define HIGHER_INTERFACE(id) LOWER_INTERFACE(PREFIX, id) #define LOWER_INTERFACE(prefix, id) struct prefix##id \ { \ int i; \ } int main(void) {

Re: Questions about selective scheduler and PowerPC

On Mon, Oct 18, 2010 at 02:49:21PM +0800, Jie Zhang wrote: 3. The aforementioned rs6000 hack rs6000_issue_rate was added by 2003-03-03 David Edelsohn edels...@gnu.org * config/rs6000/rs6000.c (rs6000_multipass_dfa_lookahead): Delete.

Re: Bug in expand_builtin_setjmp_receiver ?

On Thu, Oct 21, 2010 at 02:14:15PM +0200, Frederic Riss wrote: On 19 October 2010 15:31, Ian Lance Taylor i...@google.com wrote: However, I agree that it does seem that it should be added to or subtracted from hard_frame_pointer_rtx before setting virtual_stack_vars_rtx, or something.  I

Re: Bug in expand_builtin_setjmp_receiver ?

On Tue, Oct 26, 2010 at 01:07:26PM +0100, Jon Beniston wrote: lm32 has a gdb simulator available, so it should be fairly easy to write a board file for it if one doesn't already exist. Unfortunately, building lm32-elf is broken in several different ways right now. What problems do

decimal float, LIBGCC2_FLOAT_WORDS_BIG_ENDIAN, and ARM ABI issues

The easiest way to deal with the use of LIBGCC2_FLOAT_WORDS_BIG_ENDIAN in libgcc is to define a preprocessor macro __FLOAT_WORD_ORDER__ similar to how WORDS_BIG_ENDIAN was converted. That is, cppbuiltin.c will do: cpp_define_formatted (FOO, __FLOAT_WORD_ORDER__=%s,

Re: CUMULATIVE_ARGS in hooks (Was: RFC: semi-automatic hookization)

On Wed, Nov 17, 2010 at 03:40:39AM +0100, Paolo Bonzini wrote: True, but you can hide that cast in a base class. For example you can use a hierarchy Target // abstract base TargetImplBaseTargetI386 // provides strong typing TargetI386

Re: CUMULATIVE_ARGS in hooks (Was: RFC: semi-automatic hookization)

On Tue, Nov 16, 2010 at 10:22:00PM -0500, Joern Rennecke wrote: Quoting Nathan Froyd froy...@codesourcery.com: I am admittedly a C++ newbie; the first thing I thought of was: class gcc::cumulative_args { virtual void advance (...) = 0; virtual rtx arg (...) = 0; virtual rtx

Re: RFC: semi-automatic hookization

On Tue, Nov 16, 2010 at 06:23:32AM -0800, Ian Lance Taylor wrote: Joern Rennecke amyl...@spamcop.net writes: Before I go and make all these target changes test them, is there at least agreemwent that this is the right approach, i.e replacing CUMULATIVE_ARG * with void *, and splitting up

Re: RFD: hookizing BITS_PER_UNIT in tree optimizers / frontends

On Wed, Nov 24, 2010 at 02:48:01PM +, Pedro Alves wrote: On Wednesday 24 November 2010 13:45:40, Joern Rennecke wrote: Quoting Pedro Alves pe...@codesourcery.com: Also, these separate hooks for common operations can make the code more readable, particularly in the bits_in_units_ceil

Re: ppc: const data not in RO section

On Tue, Nov 30, 2010 at 08:04:06PM +0100, Joakim Tjernlund wrote: Why is not const char cstr[] = mystr; const int myint = 3; added to a read only section? Especially since const int myarr[]={1,2,3}; is placed in .rodata. hmm, -G 0 does place these in .rodata but why do I have to

Re: [ARM] Implementing doloop pattern

On Thu, Jan 06, 2011 at 09:59:08AM +0200, Revital1 Eres wrote: Index: loop-doloop.c + Some targets (ARM) do the comparison before the branch, as in the + folloring form: ^ following + /* In case the pattern is not PARALLEL we expect two forms + of doloop

TREE_LIST removals and cleanups for 4.7

Since people are starting to post interesting patches for 4.7, I thought it would be good to talk about bits I plan to cleanup in 4.7. Comments on other ugly things would also be welcome. TREE_LIST related things: - TREE_VECTOR_CST_ELTS. I have a patch for this. - ASM_EXPR operands, clobbers,

Re: TREE_LIST removals and cleanups for 4.7

On Sat, Jan 22, 2011 at 08:02:33PM +0100, Michael Matz wrote: On Sat, 22 Jan 2011, Nathan Froyd wrote: - Similarly to the work I did for s/TREE_CHAIN/DECL_CHAIN/, I'd like to replace TREE_TYPE for things like {POINTER,FUNCTION,ARRAY}_TYPE, etc. This work would be a good step towards

Re: Target deprecations for 4.6

On Fri, Jan 28, 2011 at 01:11:10AM +, Joseph S. Myers wrote: Here is a concrete list I propose for deprecation in 4.6; please send any other suggestions... score-* doesn't have a maintainer and score-elf couldn't build libgcc last I checked (it was also mentioned in your previous message).

Re: Target deprecations for 4.6

On Sat, Feb 12, 2011 at 08:11:07AM -0500, David Edelsohn wrote: On Fri, Feb 11, 2011 at 9:15 PM, Joseph S. Myers jos...@codesourcery.com wrote: appear to involve a simultaneously maintained set of upstream components that are usable together in their current upstream forms; they got Linux

Re: Target deprecations for 4.6

On Mon, Feb 14, 2011 at 09:41:50AM -0800, Nathan Froyd wrote: Patch for adding score-* and crx-* to obsolete ports below. Last contact for SCORE and current crx maintainer CC'd. I have committed this patch. The crx maintainer (Pompapathi Gadad) contacted me via private mail and indicated

Re: how can I write a right V32QI Unpack Low Data insn pattern?

On Wed, Mar 02, 2011 at 07:14:53AM -0800, Ian Lance Taylor wrote: This patch should at least cause genrecog to crash for you rather than generating bogus output. I've verified that this patch bootstraps on x86_64 and makes no difference in the generated insn-recog.c. Can you see whether this

Handling strictness in {predicates,constraints}.md [was: Re: Converting CRIS to constraints.md]

[moving to gcc@ to get input from a wider audience] On Thu, Mar 10, 2011 at 06:47:20AM +0100, Hans-Peter Nilsson wrote: From: Nathan Froyd froy...@codesourcery.com On Thu, Mar 10, 2011 at 04:02:27AM +0100, Hans-Peter Nilsson wrote: PS. If you really feel for it, I won't stop you converting

Re: GCC Optimisation, Part 0: Introduction

On Fri, Apr 29, 2011 at 09:18:56AM +0200, Paolo Bonzini wrote: * Get rid of EXPR_LIST and INSN_LIST This is reasonably difficult, though particular subprojects may be easy enough. Notable uses of EXPR_LIST: - loop-iv.c - the interface to TARGET_FUNCTION_VALUE - the scheduler - REG_NOTES -

Re: GCC Optimisation, Part 0: Introduction

On Fri, Apr 29, 2011 at 04:20:15PM +0200, Paolo Bonzini wrote: On 04/29/2011 04:15 PM, Nathan Froyd wrote: * cxx_binding should be 16 bytes, not 20. Not your fault, but comments like this on SpeedupAreas are so opaque as to be useless. *Why* should cxx_binding be 16 bytes? Should we take

Re: how to distinguish patched GCCs

On Fri, May 27, 2011 at 06:30:21AM -0700, Ian Lance Taylor wrote: Jonathan Wakely jwakely@gmail.com writes: It's an additional maintenance burden. It's not a maintenance burden on gcc, though. I think we should have the gcc configure script provide a way to add a preprocessor macro.

Re: [cfe-dev] [RFC] Reliable compiler specification setting (at least include/lib dirs) through the process environment

On Tue, Oct 18, 2016 at 8:59 AM, Ludovic Courtès via cfe-dev wrote: > Shea Levy skribis: > >> Your patches look good! My biggest concern is how the ld wrapper behaves >> in the presence of response files. Have you tested that? > > It surely doesn’t

Re: More informative ODR warnings

- Original Message - /aux/hubicka/firefox/netwerk/sctp/datachannel/DataChannel.h:64:0: warning: field ‘mSpa’ (of type ‘struct BufferedMsg’) violates one definition rule [-Wodr] Can we reword this warning? The of type 'struct BufferedMsg' could be easily taken to mean that the type of

[4.7 PATCH 00/18] slim down a number of tree nodes

not developed in this order; the checking bits were introduced first, then any bootstrap or testsuite failures were fixed up, then the patches were committed in the proper order. Nathan Froyd (18): add typed_tree structure enforce TREE_CHAIN and TREE_TYPE accesses remove TREE_CHAIN from *_CST nodes

[PATCH 03/18] remove TREE_CHAIN from *_CST nodes

*_CST nodes don't need TREE_CHAIN. Make them include typed_tree instead, mark them as such in initialize_tree_contains_struct, and don't print out their TREE_CHAIN. -Nathan gcc/ * tree.h (struct tree_int_cst, struct real_value): Include typed_tree instead of tree_common.

[PATCH 04/18] remove TREE_CHAIN from SSA_NAME nodes

This conversion is straightforward. The tricky part is converting FREE_SSANAMES into a VEC to eliminate the only use of TREE_CHAIN on SSA_NAMEs. -Nathan gcc/ * tree-flow.h (struct gimple_df): Make free_ssanames a VEC. * tree-ssanames.c (fini_ssanames): VEC_free it.

[PATCH 06/18] define CASE_CHAIN accessor for CASE_LABEL_EXPR

This patch begins a subseries of patches aimed at removing TREE_CHAIN from expression trees. tree-cfg.c uses TREE_CHAIN for some analysis steps on CASE_LABEL_EXPRs. I looked at this for a while, thinking it'd be easy to use VECs instead, but AFAICS, it wasn't. I went for the next best thing,

[PATCH 07/18] generalize build_case_label to the rest of the compiler

If we're going to add another TREE_OPERAND to CASE_LABEL_EXPR, then we'd have to update a number of calls to buildN or similar to know about the new operand. But that's not a good idea; the new operand is a strictly private thing and FEs in particular shouldn't have to know anything about it.

[PATCH 13/18] move TS_EXP to be a substructure of TS_TYPED

After all that, we can finally make tree_exp inherit from typed_tree. Quite anticlimatic. -Nathan gcc/ * tree.h (struct tree_exp): Inherit from struct typed_tree. * tree.c (initialize_tree_contains_struct): Mark TS_EXP as TS_TYPED instead of TS_COMMON. diff --git

[PATCH 16/18] make TS_IDENTIFIER be a substructure of TS_BASE

Now that we've done the requisite surgery on the C++ FE, we can eliminate TREE_CHAIN and TREE_TYPE from IDENTIFIER_NODEs. Doing so turns up a couple different places that need to be tweaked. The bit I'm not quite sure about is free_lang_data_in_decl and find_decls_types_r. Previously, due to

[PATCH 12/18] make CASE_LABEL_EXPR not abuse TREE_CHAIN

Move CASE_CHAIN into a local operand for CASE_LABEL_EXPR. Nothing to see here. -Nathan gcc/ * tree.def (CASE_LABEL_EXPR): Add an operand. * tree.h (CASE_CHAIN): Use TREE_OPERAND instead of TREE_CHAIN. diff --git a/gcc/tree.def b/gcc/tree.def index eb94ad2..9c6606d 100644 ---

Re: [PATCH 17/18] introduce block_chainon and use BLOCK_CHAIN more

On Fri, Mar 11, 2011 at 02:15:20PM +0100, Richard Guenther wrote: On Fri, Mar 11, 2011 at 5:23 AM, Nathan Froyd froy...@codesourcery.com wrote: BLOCKs have a TREE_CHAIN and a TREE_TYPE; TREE_TYPE is useless for blocks, but we can't remove TREE_TYPE without also removing TREE_CHAIN

Re: [PATCH 15/18] move REAL_IDENTIFIER_TYPE_VALUE to be a field of lang_identifier

On Fri, Mar 11, 2011 at 08:40:24AM -0500, Jason Merrill wrote: On 03/10/2011 11:23 PM, Nathan Froyd wrote: I'm not overly fond of the conditionals (especially in error_operand_p) but I don't think it's reasonable to make IDENTIFIER_NODE bigger and penalize the other FEs just because the C++ FE

Re: [PATCH 15/18] move REAL_IDENTIFIER_TYPE_VALUE to be a field of lang_identifier

On Fri, Mar 11, 2011 at 06:04:45AM -0800, Nathan Froyd wrote: On Fri, Mar 11, 2011 at 08:40:24AM -0500, Jason Merrill wrote: On 03/10/2011 11:23 PM, Nathan Froyd wrote: The C++ FE expects that we can check the TREE_TYPE of anything that appears as an expression, and uses IDENTIFIER_NODE

Re: [PATCH 02/18] enforce TREE_CHAIN and TREE_TYPE accesses

On Sat, Mar 12, 2011 at 01:08:23PM +0100, Eric Botcazou wrote: gcc/ada/ * gcc-interface/ada-tree.h (union lang_tree_node): Check for TS_COMMON before calling TREE_CHAIN. * gcc-interface/misc.c (gnat_init_ts): New function. (LANG_HOOKS_INIT_TS): Define. I presume that

Re: [PATCH 2/2] refactor emit_*_{after,before}{,_setloc} using common functions

On Tue, Mar 22, 2011 at 02:28:30PM -0700, Richard Henderson wrote: On 03/21/2011 08:18 PM, Nathan Froyd wrote: +/* Insert PATTERN before BEFORE, setting its INSN_LOCATION to LOC. + MAKE_RAW indicates how to turn PATTERN into a real insn. INSNP + indicates if PATTERN is meant

Re: [PATCH 2/2] refactor emit_*_{after,before}{,_setloc} using common functions

On Wed, Mar 23, 2011 at 11:36:26AM -0700, Richard Henderson wrote: On 03/23/2011 05:09 AM, Nathan Froyd wrote: Did you mean loc == UNKNOWN_LOCATION? Also, it looks like that's conflating INSN_LOCATORs and location_ts; it seems like it'd be better to keep them separate. Ug. Yes and yes

Re: [PATCH 2/2] refactor emit_*_{after,before}{,_setloc} using common functions

On Wed, Mar 23, 2011 at 01:55:34PM -0700, Richard Henderson wrote: I can't see how emitting a NULL_RTX should be a Good Thing, ever, and thus I don't see why we should be doing special things to handle it. Ah, I thought the same thing and gcc_assert'ed emitting a NULL_RTX. I didn't get very

[PATCH] use cfglayout mode for instatiate_virtual_regs

As $SUBJECT suggests. The patch looks much bigger than it actually is due to re-indentation. Tested on x86_64-unknown-linux-gnu. OK to commit? -Nathan * function.c (instantiate_virtual_regs): Use FOR_EACH_BB and FOR_BB_INSNS_SAFE to iterate through insns. Re-indent. *

[PATCH PING] fortran-specific bits of tree-slimming patches

The Fortran-specific bits of these patches: [PATCH 02/18] enforce TREE_CHAIN and TREE_TYPE accesses http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00565.html [PATCH 07/18] generalize build_case_label to the rest of the compiler http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00557.html

[PATCH] fix memory accounting for copying nodes

tree.c can gather optionally statistics--counts and total bytes allocated--when tree nodes are created. Due to an oversight, however, this accounting is not performed when nodes are copied. The patch below corrects this oversight and moves things around so the accounting is done in (almost) only

Re: [patch, ARM] Make 128 bits the default vector size for NEON

On Thu, Mar 31, 2011 at 01:39:05PM +0200, Ira Rosen wrote: This patch changes NEON's default vector size from 64 to 128 bits. No comments about the patch itself, but this change should be noted in changes.html. -Nathan

[PATCH] macroize some rs6000 call patterns

This patch does as $SUBJECT suggests. It doesn't macroize all the call insns, as iterators don't support substituting CONST_INTs, but it does clean up quite a bit. Tested on powerpc64-unknown-linux-gnu. OK to commit? -Nathan * config/rs6000/rs6000.md (*call_local32): Rename to...

[PATCH] make LABEL_DECL has its own rtx field for its associated CODE_LABEL

This patch does just what $SUBJECT suggests: pushes down the DECL_RTL field into LABEL_DECL. In this way, LABEL_DECL can inherit from tree_decl_common instead of tree_decl_with_rtl. I realize this looks like pure code shuffling; the reason for doing this is that I want to split tree_decl_common

Re: [PATCH] cleanup gcse.c:canon_modify_mem_list

On Mon, Apr 04, 2011 at 05:42:42PM +0200, Steven Bosscher wrote: Nice cleanup. I can't approve it but it looks alright to me. I suppose you're planning something similar for modify_mem_list? That's the plan, along with numerous other users of {INSN,EXPR}_LIST. -Nathan

Re: [PATCH] make LABEL_DECL has its own rtx field for its associated CODE_LABEL

On Mon, Apr 04, 2011 at 05:52:00PM +0200, Steven Bosscher wrote: Have you looked into maybe putting the CODE_LABEL for a LABEL_DECL in an on-the-side structure (hash table, whatever)? It looks like it is only used during expansion of SWITCH statements. I haven't, though it'd be easy enough

[PATCH] allocate combine.c:LOG_LINKS in an alloc_pool

This patch does just what $SUBJECT suggests. Benefits: - Smaller data structures in combine; - Freeing LOG_LINKS becomes much easier (don't have to transfer everything to the INSN_LIST free list); Potential downsides: - Less sharing of INSN_LIST nodes might mean more cache thrashing.

Re: [PATCH] allocate combine.c:LOG_LINKS in an alloc_pool

On Mon, Apr 04, 2011 at 09:01:20PM +0200, Steven Bosscher wrote: On Mon, Apr 4, 2011 at 8:49 PM, Nathan Froyd froy...@codesourcery.com wrote: This patch does just what $SUBJECT suggests.  Benefits: - Smaller data structures in combine; - Freeing LOG_LINKS becomes much easier (don't have

[PATCH] don't use TYPE_ARG_TYPES in type_generic or sentinel attribute handling

The type_generic and sentinel attribute handlers for c-family, LTO, and Ada grovel through TYPE_ARG_TYPES; this patch changes them to use the standard functions prototype_p and stdarg_p instead. Less TYPE_ARG_TYPES usage is a good thing. The prototype_p check in the type_generic handlers is

[PATCH] move some debug routines from final.c to dbxout.c

I was looking at debug_flush_symbol_queue and thought gosh, it's inefficient if we're calling this all the time, but it only does work when we want DBX_DEBUGGING_INFO. So I looked around and saw that debug_flush_symbol_queue and friends are only called from dbxout.c. So this patch moves them

Re: [PATCH] cleanup gcse.c:canon_modify_mem_list

On Mon, Apr 04, 2011 at 12:01:09PM -0600, Jeff Law wrote: + canon_modify_mem_list = GCNEWVEC (VEC(modify_pair,heap) *, + last_basic_block); nit; You're missing some whitespace here (after the VEC). This doesn't seem to be a hard-and-fast policy; all of the VEC

Re: [PATCH] cleanup gcse.c:canon_modify_mem_list

On Tue, Apr 05, 2011 at 01:22:39PM +0100, Richard Earnshaw wrote: On Tue, 2011-04-05 at 04:44 -0700, Nathan Froyd wrote: nit; You're missing some whitespace here (after the VEC). This doesn't seem to be a hard-and-fast policy; all of the VEC code I remember writing or looking

[PATCH] use build_function_type_list for float128 functions

When the real16/float128 bits were added to the Fortran FE, some uses of build_function_type snuck in. This patch changes them to use build_function_type_list. The patch also corrects a small bug: the types for frexp and scalbn had their argument types in the wrong order. Tested on

[PATCH] make gcse.c:modify_mem_list hold VECs instead of INSN_LISTs

As promised, this patch turns modify_mem_list into an array of VECs, similar to the changes done to canon_modify_mem_list. Since I'm in the area, I took the liberty of tweaking the VEC declarations related to canon_modify_mem_list to have spaces before parens, as folks seem to think that's the

Re: [PATCH] allocate combine.c:LOG_LINKS in an obstack

On Mon, Apr 04, 2011 at 02:49:54PM -0400, Nathan Froyd wrote: This patch does just what $SUBJECT suggests. v2, now with obstacks! Tested on x86_64-unknown-linux-gnu. OK to commit? -Nathan * combine.c: Include obstack.h (struct insn_link): Define. (uid_log_links

Re: [PATCH] allocate combine.c:LOG_LINKS in an obstack

On Tue, Apr 05, 2011 at 04:42:27PM +0200, Steven Bosscher wrote: On Tue, Apr 5, 2011 at 3:59 PM, Nathan Froyd froy...@codesourcery.com wrote: v2, now with obstacks! @findex LOG_LINKS @item LOG_LINKS (@var{i}) A list (chain of @code{insn_list} expressions) giving information about

Re: [PATCH] make LABEL_DECL has its own rtx field for its associated CODE_LABEL

On Tue, Apr 05, 2011 at 05:55:33PM +0200, Michael Matz wrote: I have a preference in having just one DECL_RTL field for conceptual reasons: Most DECLs are actually objects (there are some prominent exceptions, but those always would be better described with something like NAMED_ENTITY,

[PATCH] use use_reg in several backends

Several places in the compiler could be usefully modified to use use_reg instead of hand-building EXPR_LISTs. This patch makes such changes. Since this patch implements equivalent functionality with an existing function call, I believe it counts as obvious. Tested by building cc1 for

Re: [PATCH] allocate combine.c:LOG_LINKS in an obstack

On Tue, Apr 05, 2011 at 09:59:43AM -0400, Nathan Froyd wrote: On Mon, Apr 04, 2011 at 02:49:54PM -0400, Nathan Froyd wrote: This patch does just what $SUBJECT suggests. v2, now with obstacks! This broke compilation on AUTO_INC_DEC targets. Currently putting together a fix and testing via

Re: [PATCH] allocate combine.c:LOG_LINKS in an obstack

On Tue, Apr 05, 2011 at 11:22:56AM -0700, Nathan Froyd wrote: On Tue, Apr 05, 2011 at 09:59:43AM -0400, Nathan Froyd wrote: On Mon, Apr 04, 2011 at 02:49:54PM -0400, Nathan Froyd wrote: This patch does just what $SUBJECT suggests. v2, now with obstacks! This broke compilation

Re: [PATCH] allocate combine.c:LOG_LINKS in an obstack

On Tue, Apr 05, 2011 at 12:29:45PM -0700, H.J. Lu wrote: On Tue, Apr 5, 2011 at 11:28 AM, Nathan Froyd froy...@codesourcery.com wrote: This broke compilation on AUTO_INC_DEC targets.  Currently putting together a fix and testing via cross to powerpc-eabispe. ...and here's the patch I'm

Re: [PATCH] cleanup gcse.c:canon_modify_mem_list

On Tue, Apr 05, 2011 at 07:18:16PM +, Joseph S. Myers wrote: On Tue, 5 Apr 2011, Nathan Froyd wrote: Certainly vec.h never uses spaces; I thought this was simply The Way Things Were. I also had the impression that for certain special macros such as VEC, GTY, _, N_, G_ - macros

Re: [PATCH] Fix LTO bootstrap on i686-linux (problem with two Ldebug_info0 labels; PR bootstrap/48148)

On Tue, Apr 05, 2011 at 04:19:39PM +0200, Jakub Jelinek wrote: + for (i = 0; i VEC_length (deferred_locations, deferred_locations_list); i++) +{ + add_location_or_const_value_attribute ( + VEC_index (deferred_locations, deferred_locations_list, i)-die, + VEC_index

[PATCH] fix PR bootstrap/48471

My changes that moved bits of final.c to dbxout.c caused compilation failures on targets that *didn't* enable DBX_DEBUGGING_INFO, since some now-static symbols could be unused. To fix this, the patch below moves all the new static variables and two macros that use some of said variables below an

[PATCH,c++] fix PR objc++/48479, ICE in cxx_mark_addressable

My recent patch removing DECL_RTL from CONST_DECLs caused regressions in the ObjC++ testsuite on Darwin targets. The problem is that DECL_REGISTER was being called on CONST_DECLs; DECL_REGISTER says: /* In VAR_DECL and PARM_DECL nodes, nonzero means declared `register'. */ #define

[PATCH] add statistics counting to postreload, copy-rename, and math-opts

It's a shame more passes don't make use of the statistics_* infrastructure. This patch is a step towards rectifying that and adds statistics_counter_event calls to passes mentioned in $SUBJECT. postreload-gcse already tracked the stats for the dump file and so only needs the

  1   2   3   >