Re: Question on not sharing trees (tree_node_can_be_shared)

On Mon, Mar 21, 2022 at 11:56 AM Erick Ochoa wrote: > > Hi, > > I am interested in annotating INTEGER_CSTs. I have added a field to > typed_trees and set the value in some cases. However, INTEGER_CSTs can be > shared and copied across the function and even copied to other functions. I > don't w

Question on not sharing trees (tree_node_can_be_shared)

Hi, I am interested in annotating INTEGER_CSTs. I have added a field to typed_trees and set the value in some cases. However, INTEGER_CSTs can be shared and copied across the function and even copied to other functions. I don't want all INTEGER_CSTs with the same value to be shared as now they hav

Re: Why do these two trees print differently

only IR was > an AST and it was a really horrible IR so I'm glad GIMPLE > isn't an AST. But the tree expressions seem to be chunks > of AST (with some other stuff thrown in that could be thought of > as node attributes.) Am I wrong to think of them that way? trees are dual-p

Re: Why do these two trees print differently

k Cc: gcc@gcc.gnu.org Subject: Re: Why do these two trees print differently [EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please be mindful of safe email handling and proprietary information protection practices.] On Mon, Jan 3, 2022 at 9:16 PM Gary Oblock wrote: &

Re: Why do these two trees print differently

gnoring qualifiers. */ > && (TYPE_MAIN_VARIANT (TREE_TYPE (node)) > == TYPE_MAIN_VARIANT > (TREE_TYPE (TREE_TYPE (TREE_OPERAND (node, 1) > && (!(flags & TDF_ALIAS) > || MR_DEPENDENCE_CLIQUE (node) == 0)) > >

Re: Why do these two trees print differently

_ From: Richard Biener Sent: Monday, January 3, 2022 5:49 AM To: Gary Oblock Cc: gcc@gcc.gnu.org Subject: Re: Why do these two trees print differently [EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please be mindful of safe email handling and proprietary information

Re: Why do these two trees print differently

On Wed, Dec 15, 2021 at 7:10 AM Gary Oblock via Gcc wrote: > > This is one of those things that has always puzzled > me so I thought I break down and finally ask. > > There are two ways a memory reference (tree) prints: > > MEM[(struct arc_t *)_684].flow > > and > > _684->flow > > Poking under the

Why do these two trees print differently

This is one of those things that has always puzzled me so I thought I break down and finally ask. There are two ways a memory reference (tree) prints: MEM[(struct arc_t *)_684].flow and _684->flow Poking under the hood of them, the tree codes and operands are identical so what am I missing? T

Re: SSA Question related to Dominator Trees

On 1/27/20 10:46 AM, Jeff Law wrote: On Mon, 2020-01-27 at 10:18 -0500, Nicholas Krause wrote: Greetings, Sorry if this question has been asked before but do we extend out the core tree type for SSA or is there a actual dominator tree type. It seems to be we just extend or override the core

Re: SSA Question related to Dominator Trees

On Mon, 2020-01-27 at 10:18 -0500, Nicholas Krause wrote: > Greetings, > > Sorry if this question has been asked before but do we extend out the > core tree type for SSA or > is there a actual dominator tree type. It seems to be we just extend or > override the core tree > type parameters but wa

SSA Question related to Dominator Trees

Greetings, Sorry if this question has been asked before but do we extend out the core tree type for SSA or is there a actual dominator tree type. It seems to be we just extend or override the core tree type parameters but was unable to verify it by looking in the manual. Thanks, Nick

Re: Struct declaration and initialization in TREES

On 2019-12-18 1:33 p.m., Erick Ochoa wrote: > > > On 2019-12-18 6:02 a.m., Richard Biener wrote: >> On December 17, 2019 8:31:00 PM GMT+01:00, Erick Ochoa >> wrote: >>> Hi, >>> >>> I'm interested in printing VAR_DECL trees that

Re: Struct declaration and initialization in TREES

On 2019-12-18 6:02 a.m., Richard Biener wrote: > On December 17, 2019 8:31:00 PM GMT+01:00, Erick Ochoa > wrote: >> Hi, >> >> I'm interested in printing VAR_DECL trees that are of type >> RECORD_TYPE. I am using the function print_generic_decl >>

Re: Struct declaration and initialization in TREES

On December 17, 2019 8:31:00 PM GMT+01:00, Erick Ochoa wrote: >Hi, > >I'm interested in printing VAR_DECL trees that are of type >RECORD_TYPE. I am using the function print_generic_decl >for debugging and found this interesting behaviour. > >When I do initializ

Struct declaration and initialization in TREES

Hi, I'm interested in printing VAR_DECL trees that are of type RECORD_TYPE. I am using the function print_generic_decl for debugging and found this interesting behaviour. When I do initialization of structs using the following syntax: ``` struct aStruct { _Bool e; int a; char b; float c; d

SSA Trees and Making them MultiThreaded Aware

Richard, Sorry for the second email but I forget in the previous one but Jeff Law at Cauldron stated your the expert for the SSA code. Is it possible to make that code multithreaded in particular the dominator trees. I'm going to start researching that as Giuliano's branch does

SSA Trees and Lockless Implementation

Greetings, It seems possible after looking at the SSA dominator trees briefly to make them lockless at least partly for insertion/deletion/removal of both standard SSA nodes and PHI nodes. Am I right in assuming this or our there some subtle details that I'm missing when looking a

Re: [GSoC] generation of GCC expression trees from isl ast expressions

On 03/07/2014 19:24, Roman Gareev wrote: However, this form doesn't have loop guards which are generated by >>graphite_create_new_loop_guard in gcc/graphite-isl-ast-to-gimple.c and >>by graphite_create_new_loop_guard in graphite-clast-to-gimple.c. > > >Maybe the guards are directly constant fold

Re: [GSoC] generation of GCC expression trees from isl ast expressions

>> However, this form doesn't have loop guards which are generated by >> graphite_create_new_loop_guard in gcc/graphite-isl-ast-to-gimple.c and >> by graphite_create_new_loop_guard in graphite-clast-to-gimple.c. > > > Maybe the guards are directly constant folded? Can you try with: I've tried this

Re: [GSoC] generation of GCC expression trees from isl ast expressions

On 01/07/2014 14:53, Roman Gareev wrote: Hi Tobias, could you please advise me how to verify the results of gimple code generation? More comments inline, but here something on a very high level. I personally like testing already on the GIMPLE level and could see us matching for certain expres

Re: [GSoC] generation of GCC expression trees from isl ast expressions

Hi Tobias, could you please advise me how to verify the results of gimple code generation? I've written the first draft of the generation of loops with empty bodies and tried to verify gimple code using the representation, which is dumped at the end of the generation of the dump_file. If we consid

Re: [GSoC] generation of GCC expression trees from isl ast expressions

ut this in previous message. Sorry for being unclear.) I did not fully understand them. Are you comparing the resulting GIMPLE trees or are you statically evaluating the isl and gimple trees to check if the computed value is the same? I'm statically evaluating gimple tree expressions, which are

Re: [GSoC] generation of GCC expression trees from isl ast expressions

message. Sorry for being unclear.) > I did not fully understand them. Are you comparing the resulting GIMPLE > trees or are you statically evaluating the isl and gimple trees to check > if the computed value is the same? I'm statically evaluating gimple tree expressions, which are generat

Re: [GSoC] generation of GCC expression trees from isl ast expressions

> I assume so. However, we always want signed types, so the second > argument should be zero, no? Yes, you are right. > How did you verify that the semantics of the GCC and isl expressions are > identical? I haven't tested it on examples yet. I've only matched their semantics from the isl manual

Re: [GSoC] generation of GCC expression trees from isl ast expressions

On 23/06/2014 08:34, Roman Gareev wrote: Hi Tobias, I'm currently working on generation of GCC expression trees from isl ast expressions . Could you please answer a few questions about it? 1. How is it better to generate tree from isl_ast_expr_int? In the temporary variant I

[GSoC] generation of GCC expression trees from isl ast expressions

Hi Tobias, I'm currently working on generation of GCC expression trees from isl ast expressions . Could you please answer a few questions about it? 1. How is it better to generate tree from isl_ast_expr_int? In the temporary variant I call isl_ast_expr_get_int to get isl_int from isl_ast

Re: Traversing trees in a plugin...

Brett Foster writes: > 1) How to marking a node as visited by my algorithm (without screwing > up the compiler!) Use a pointer_set. > 2) How to associate additional data (perhaps a pointer to something > else) to a node (like a unique identifier, or a pointer to a data > structure). Use a poin

Re: Traversing trees in a plugin...

ta > > you know that > > this tree has been visited. > > I'll poke around the MELT source code - > > In Melt, where in source code may I have a look to see how trees and > mapped to the hash table? Are you able to summarize the basics? I.e. > the hash for a speci

Re: Traversing trees in a plugin...

ave e.g. an hash-table associating each tree (every tree is in > GCC a non-null > pointer to a structure) with data associated to it. Once it has some data you > know that > this tree has been visited. I'll poke around the MELT source code - In Melt, where in source code may I h

Re: Traversing trees in a plugin...

On Sat, 2 Jun 2012 20:31:26 +0200 Basile Starynkevitch wrote: > In a few words, plugins cannot extend existing GCC data structures, but can > associate them > to their own data. I forgot to mention that gimple-s (but not tree-s) give you a unsigned client number called a uid, which a single pas

Re: Traversing trees in a plugin...

On Sat, 2 Jun 2012 10:48:47 -0700 Brett Foster wrote: > Hi all, > > I'm working on a GCC plugin, having made a lot of progress on that > front. So far running my plugin works 'more or less' on things like > the linux kernel. On the other hand running it on the plugin itself > causes problems. Gi

Traversing trees in a plugin...

Hi all, I'm working on a GCC plugin, having made a lot of progress on that front. So far running my plugin works 'more or less' on things like the linux kernel. On the other hand running it on the plugin itself causes problems. Given that some of the data structures are pretty complicated in GCC I

Re: About trees and expanded code by macros

Alberto Lozano Alelu a écrit: > Hello. Hello Alberto, > I'am developing an statement detector for c++ and I would like to > detect if an statement is expanded from macro. I guess you are doing this from a plugin? > Can I detect in ast tree if an statement is expanded code from macro? As Manu

Re: About trees and expanded code by macros

Thanks for correcting me Manuel. I am just getting acquainted with GCC4.7, good to know that information has been added. Cheers, Paulo Matos On 14/05/12 10:07, Manuel López-Ibáñez wrote: This information is incorrect. GCC tracks macro expansion information since GCC 4.7, and it has been fur

Re: About trees and expanded code by macros

This information is incorrect. GCC tracks macro expansion information since GCC 4.7, and it has been further improved and enabled by default in GCC 4.8. See the option ftrack-macro-expansion and the interface located in libcpp/include/line-map.h. If you have trouble understanding the interface, f

Re: About trees and expanded code by macros

Hi Alberto, As far as I understand it you want to know if a statement was expanded from a preprocessor macro, right? This isn't possible. The preprocessor is a separate thing altogether and I doubt any preprocessing information remains for the compiler proper to deal with. Cheers, Paulo M

About trees and expanded code by macros

Hello. I'am developing an statement detector for c++ and I would like to detect if an statement is expanded from macro. Can I detect in ast tree if an statement is expanded code from macro? Thanks.

[gimplefe] update your local trees

Ketaki, Sandeep, My last merge from trunk into gimple-front-end was incomplete. I just realized that I had failed to commit several directories. I just committed a fix, so please make sure that your local checkout is at rev 174754. Diego.

How to stream trees in lto-cgraph.c?

Hi, in order to implement all sorts of IPA-devirtualization in WHOPR, I need to store type of OBJ_TYPE_REF_OBJECT when streaming a call graph edge. I assume that lto_output_tree and lto_input_tree are what I need to use. Unfortunately, I have not been really able to use neither. The problem wit

Re: Help with BLOCK vs BIND_EXPR trees

On Tue, Jun 16, 2009 at 3:19 PM, Jerry Quinn wrote: > On Tue, 2009-06-16 at 14:43 +0200, Richard Guenther wrote: >> BIND_EXPRs are containers for local variables in the GENERIC >> function body (they persist until GIMPLE is lowered).  BLOCKs >> represent the scope tree of the function (which also r

Re: Help with BLOCK vs BIND_EXPR trees

On Tue, 2009-06-16 at 14:43 +0200, Richard Guenther wrote: > BIND_EXPRs are containers for local variables in the GENERIC > function body (they persist until GIMPLE is lowered). BLOCKs > represent the scope tree of the function (which also refers to > local variables). The BLOCK tree is kept live

Re: Help with BLOCK vs BIND_EXPR trees

On Tue, Jun 16, 2009 at 1:50 PM, Jerry Quinn wrote: > (trying again) > Hi, all.  I have a basic question about GENERIC trees. > > I'm playing with writing a front end, and find the distinction between > BLOCK and BIND_EXPR to be somewhat confusing.  In particular, I'm tr

Help with BLOCK vs BIND_EXPR trees

(trying again) Hi, all. I have a basic question about GENERIC trees. I'm playing with writing a front end, and find the distinction between BLOCK and BIND_EXPR to be somewhat confusing. In particular, I'm trying to get a handle on how to represent a function in GENERIC form. On the s

Help with BLOCK vs BIND_EXPR trees?

Hi, all. I have a basic question about GENERIC trees. I'm playing with writing a front end, and find the distinction between BLOCK and BIND_EXPR to be somewhat confusing. In particular, I'm trying to get a handle on how to represent a function in GENERIC form. On the surface the tex

Re: Gcc trees

Revital1 Eres wrote: I work with Gcc trees to modify c++ original code and dont find and i need documentation about trees because the web isnt enought information. Where are docs about gcc trees and macros to access it? In GCC wiki you may find useful links: http://gcc.gnu.org/wiki (like

Re: Gcc trees

[EMAIL PROTECTED] wrote on 21/06/2007 15:44:27: > Hello. i am Alberto > > I work with Gcc trees to modify c++ original code and dont find and i > need documentation about trees because the web isnt enought information. > > Where are docs about gcc trees and macros to access

Gcc trees

Hello. i am Alberto I work with Gcc trees to modify c++ original code and dont find and i need documentation about trees because the web isnt enought information. Where are docs about gcc trees and macros to access it? Thanks you Alberto

Re: tuples: data structure separation from trees

> There are a lot of us that are happy to devote time and people > resources to helping you with this (both design and implementation), > so if you feel like you don't have time to go look at other IR's or > something, please let us help :) That would be great, especially the bit about looking at

Re: tuples: data structure separation from trees

ml It is moderately ugly because the approach does not work too well for frontends so I decided to not do it for a moment, but if we separate gimple and frontend trees, it would be clean solution. One approach I was considering is also to extend libcpp linemaps to deal with blocks too (via extensio

Re: tuples: data structure separation from trees

On 3/29/07, Aldy Hernandez <[EMAIL PROTECTED]> wrote: After doing the GIMPLE_MODIFY_STMT work, I've come to the conlusion that to continue overloading trees will be more work in the long run than doing the actual separation between tuples and trees. This business of "this is

Re: tuples: data structure separation from trees

On 29 Mar 2007 18:24:56 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: Aldy Hernandez <[EMAIL PROTECTED]> writes: There are a number of other compilers with successful IR implementations, and some of them are open source, such as LLVM or Open64. Since you are essentially proposing a new IR,

Re: tuples: data structure separation from trees

On 3/29/07, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote: On Thu, Mar 29, 2007 at 06:40:30PM -0700, Andrew Pinski wrote: > On 29 Mar 2007 18:24:56 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > >Why will expressions have location? It seems to me preferable to save > >the memory. After a fe

Re: tuples: data structure separation from trees

On Thu, Mar 29, 2007 at 09:38:02PM -0700, Ian Lance Taylor wrote: > Provided we keep locations on statements, specifically including > GIMPLE_MODIFY_EXPR, does it really help us to keep locations on > expressions within statements in optimized code? What could the > debugger do with that informati

Re: tuples: data structure separation from trees

"Andrew Pinski" <[EMAIL PROTECTED]> writes: > On 29 Mar 2007 18:24:56 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > > Why will expressions have location? It seems to me preferable to save > > the memory. After a few optimization passes many of the expressions > > have no location anyhow.

Re: tuples: data structure separation from trees

On Thu, Mar 29, 2007 at 06:40:30PM -0700, Andrew Pinski wrote: > On 29 Mar 2007 18:24:56 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > >Why will expressions have location? It seems to me preferable to save > >the memory. After a few optimization passes many of the expressions > >have no lo

Re: tuples: data structure separation from trees

On 29 Mar 2007 18:24:56 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: Why will expressions have location? It seems to me preferable to save the memory. After a few optimization passes many of the expressions have no location anyhow. And I know from past experiences, that this is really a

Re: tuples: data structure separation from trees

Aldy Hernandez <[EMAIL PROTECTED]> writes: > After doing the GIMPLE_MODIFY_STMT work, I've come to the conlusion that > to continue overloading trees will be more work in the long run than doing the > actual separation between tuples and trees. This business of "this is

Re: tuples: data structure separation from trees

tually save any memory, it might result in not having to load SUBCODE for the common case of recognizing straight copies. > * Unfortunately, we're going to have to duplicate a lot of the functionality > we currently have for trees. For example, since STATEMENT_LISTs are used > before gim

tuples: data structure separation from trees

Hi guys! I've been having sporadic conversations with both Diego and Rth regarding tuples, and I wanted to sum up, and get others' opinions. After doing the GIMPLE_MODIFY_STMT work, I've come to the conlusion that to continue overloading trees will be more work in the long run

Re: Bogus trees from Ada front-end (more VRP vs Ada) stuff)

Jeffrey A Law wrote: Presumably there's a reason why enumeral types don't have a base type? They don't in Ada (since there is no issue at the Ada semantic level of out of range intermediate values), but we could certainly introduce such a notion at the implementation level if it helps. I've

Re: Bogus trees from Ada front-end (more VRP vs Ada) stuff)

On Wed, 2006-03-08 at 12:36 +0100, Eric Botcazou wrote: > > Presumably there's a reason why enumeral types don't have a > > base type? > > They are viewed as full-blown types by Ada, forming the class of discrete > types with integral types, so there are probably no semantics reasons why > ENUME

Re: Bogus trees from Ada front-end (more VRP vs Ada) stuff)

They are viewed as full-blown types by Ada, forming the class of discrete types with integral types, so there are probably no semantics reasons why ENUMERAL_TYPE nodes should have an INTEGER_TYPE node as their base type. I'll add here that at one point I tried doing it the above way

Re: Bogus trees from Ada front-end (more VRP vs Ada) stuff)

> Presumably there's a reason why enumeral types don't have a > base type? They are viewed as full-blown types by Ada, forming the class of discrete types with integral types, so there are probably no semantics reasons why ENUMERAL_TYPE nodes should have an INTEGER_TYPE node as their base type.

Re: Bogus trees from Ada front-end (more VRP vs Ada) stuff)

On Tue, 2006-03-07 at 08:00 -0500, Richard Kenner wrote: > if (INTEGRAL_TYPE_P (etype) && TREE_TYPE (etype)) > { > etype = TREE_TYPE (etype); > exp = fold_convert (etype, exp); > low = fold_convert (etype, low); > value = fold_convert (etype, value); >

Re: Bogus trees from Ada front-end (more VRP vs Ada) stuff)

if (INTEGRAL_TYPE_P (etype) && TREE_TYPE (etype)) { etype = TREE_TYPE (etype); exp = fold_convert (etype, exp); low = fold_convert (etype, low); value = fold_convert (etype, value); } I gather that we should restrict the transformat

Re: Bogus trees from Ada front-end (more VRP vs Ada) stuff)

> This sounds like fold is merging the two comparisons above incorrectly into > the one upper comparison. Right. > It can do the merge, but it needs to convert to base types first. The type at stake is a ENUMERAL_TYPE and those have no base type constant invariant visited 8> unit size

Re: Bogus trees from Ada front-end (more VRP vs Ada) stuff)

On Mon, 2006-03-06 at 11:39 -0700, Jeffrey A Law wrote: > if Side = Right or else Side = Both then > while High >= Low and then Source (High) = Wide_Space loop > High := High - 1; > end loop; > end if; > > > side is an enumerated type with the following v

Re: Bogus trees from Ada front-end (more VRP vs Ada) stuff)

Here's the relevant bits from the .original dump if (side - 1 <= 1) Of particular interest is the (side - 1 <= 1) conditional which is implementing this hunk of code from the Trim function: if Side = Right or else Side = Both then I think it's time to hand this one to th

Re: Bogus trees from Ada front-end (more VRP vs Ada) stuff)

On Mar 6, 2006, at 1:39 PM, Jeffrey A Law wrote: I think it's time to hand this one to the Ada guys :-0 I bet this is actually a fold issue rather than an Ada front-end issue. -- Pinski

Re: Bogus trees from Ada front-end (more VRP vs Ada) stuff)

On Mon, 2006-03-06 at 00:31 +0100, Eric Botcazou wrote: > > > cxa4025 and cxa4033 are very likely yours, originating in a miscompilation of > the runtime (a-stwifi.adb) at -O2. They succeed if the aforementioned unit > is compiled at -O2 -fno-tree-vrp. You can pass -a to gnatmake to cause the

Re: Receive only special Trees (fdump-tree...)

Jan Wegner wrote: Hi! Is it possible to receive only special trees from -fdump-tree-{all-raw}? Try reading the docs for the -fdump-tree-* options. You can choose which dump files are created by using the appropriate option. I only need original, generic and gimple. Is there a description

Receive only special Trees (fdump-tree...)

Hi! Is it possible to receive only special trees from -fdump-tree-{all-raw}? I only need original, generic and gimple. Is there a description about the generic-file somewhere? I read http://zenii.linux.org.uk/~ajh/gcc/gccsummit-2003-proceedings.pdf but it's not enough yet. Thank you very mu

Re: information request about generated trees during gcc process

to do so. There is documentation for the structure of the trees that we use. See the gcc internals documentation, either in the source tree or on the web page. The format of the dump files follows from that. You may also want to take a look at the papers published in the GCC conference. So

information request about generated trees during gcc process

Hi, My name is Bruno Galleggianti and I am working for the CEA, a French research center. I'm looking for tools that can generate AST (Abstract Syntax Tree) from C files. I have found with gcc toolchain the option -dump-tree-original. The generated files are very interresting for me and I th

Re: Fwd: trees: function declaration

[EMAIL PROTECTED] wrote: I need some kind of assistance. I am trying to substitute function name during the compilation procedure. The only way to tell what is wrong is to debug the patch. And since it is your patch, you are the one that should be trying to debug it. Try setting breakpoints

Fwd: trees: function declaration

From: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Subject: trees: function declaration To: GCC Development Gentlemen. I need some kind of assistance. I am trying to substitute function name during the compilation procedure. In order to do that I am: 1. creating new identifier with my

trees: function declaration

Gentlemen. I need some kind of assistance. I am trying to substitute function name during the compilation procedure. In order to do that I am: 1. creating new identifier with my name, like this: t = get_identifier("Myfuction__ml_stub"); 2. setting this name: DECL_NAME(funcition) = t; function is t

Re: [RFH] Restrict support for trees

On Tue, 29 Nov 2005, Daniel Berlin wrote: > On Tue, 2005-11-29 at 22:08 +0100, Richard Guenther wrote: > > The patch below teaches points-to analysis about restrict qualifiers > > of incoming parameters. It is modeled after the special handling > > of malloc result type pointers, namely creating

Re: [RFH] Restrict support for trees

On Tue, 2005-11-29 at 22:08 +0100, Richard Guenther wrote: > The patch below teaches points-to analysis about restrict qualifiers > of incoming parameters. It is modeled after the special handling > of malloc result type pointers, namely creating fake variables we > point to and thus trigger creat

[RFH] Restrict support for trees

The patch below teaches points-to analysis about restrict qualifiers of incoming parameters. It is modeled after the special handling of malloc result type pointers, namely creating fake variables we point to and thus trigger creation of NMTs. Unfortunately it doesn't exactly work, as for the te

Re: trees

Gabriel Dos Reis wrote: > Hi, > > What kind of things did you want to put in doc/c-tree.texi under the > section "Trees" when you wrote > > @c-----

trees

Hi, What kind of things did you want to put in doc/c-tree.texi under the section "Trees" when you wrote @c- @c Trees @c- @node Macros and

Re: using multiple trees with subversion

Mike Stump wrote: > On Oct 19, 2005, at 2:56 AM, François-Xavier Coudert wrote: > >> Or am I the only person to find that disk is expensive (or working >> on his own hardware, maybe)? > > > A checkout costs US$0.50. This is around 2.6x more expensive than a > cvs checkout. Check around locally

Re: using multiple trees with subversion

On Oct 19, 2005, at 2:56 AM, François-Xavier Coudert wrote: Or am I the only person to find that disk is expensive (or working on his own hardware, maybe)? A checkout costs US$0.50. This is around 2.6x more expensive than a cvs checkout. Check around locally, maybe you can find `throwaways

Re: using multiple trees with subversion

On 2005-10-19 13:48:36 +0200, Giovanni Bajo wrote: > Probably you're the only one finding disk space expensive. One can also write data on memory cards and they are expensive. This would be important to use Subversion on a PDA. -- Vincent Lefèvre <[EMAIL PROTECTED]> - Web:

Re: using multiple trees with subversion

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Giovanni Bajo wrote: > > Probably you're the only one finding disk space expensive. HDs are quite > cheap nowadays. Anyway, I'm sure SVN people would be happy if you help Well, I'm another person who's concerned about growing local copy sizes. As it

Re: using multiple trees with subversion

Having 5 subversion trees will need much more space (for local pristine copies), which I don't really have. Is there any way to force subversion use one pristine tree for all modified trees, or is my way of handling things completely rotten? I have a script called svn-switch-patch that u

Re: using multiple trees with subversion

On Wed, 2005-10-19 at 08:14 -0400, Daniel Berlin wrote: > On Wed, 2005-10-19 at 11:56 +0200, François-Xavier Coudert wrote: > > > Not that I know of. As Daniel Berlin said, Subversion 1.4 will probably > > > have > > > support for checking out repositories with compressed local copies (or no > >

Re: using multiple trees with subversion

On Wed, 2005-10-19 at 11:56 +0200, François-Xavier Coudert wrote: > > Not that I know of. As Daniel Berlin said, Subversion 1.4 will probably have > > support for checking out repositories with compressed local copies (or no > > copy > > at all -- but I wouldn't suggest this, as you'd start to be

Re: using multiple trees with subversion

On Wed, 2005-10-19 at 13:48 +0200, Giovanni Bajo wrote: > François-Xavier Coudert <[EMAIL PROTECTED]> wrote: > > >> Not that I know of. As Daniel Berlin said, Subversion 1.4 will probably > >> have support for checking out repositories with compressed local copies > >> (or no copy at all -- but I

Re: using multiple trees with subversion

François-Xavier Coudert <[EMAIL PROTECTED]> wrote: >> Not that I know of. As Daniel Berlin said, Subversion 1.4 will probably >> have support for checking out repositories with compressed local copies >> (or no copy at all -- but I wouldn't suggest this, as you'd start to be >> slow in "svn diff",

Re: using multiple trees with subversion

> Not that I know of. As Daniel Berlin said, Subversion 1.4 will probably have > support for checking out repositories with compressed local copies (or no copy > at all -- but I wouldn't suggest this, as you'd start to be slow in "svn > diff", > "svn stat", etc). I guess no local copy would be fi

Re: using multiple trees with subversion

d sanity right now is to have a few complete trees (one for > 4.0 and 3-4 for mainline, each one with a local changes), called > gcc-newintrinsics, gcc-fpe, ... > Having 5 subversion trees will need much more space (for local > pristine copies), which I don't really have. Is there an

Re: using multiple trees with subversion

* François-Xavier Coudert: > Having 5 subversion trees will need much more space (for local > pristine copies), which I don't really have. Is there any way to force > subversion use one pristine tree for all modified trees, or is my way > of handling things completely rotten?

using multiple trees with subversion

5 at a time) on limited areas (gcc/fortran, libgfortran and gcc/testsuite), always on mainline or 4.0 branch. The way I manage to keep mind sanity right now is to have a few complete trees (one for 4.0 and 3-4 for mainline, each one with a local changes), called gcc-newintrinsics, gcc-fpe, ... Havi

Re: [RFC] propagating loop dependences from trees to RTL (for SMS)

On Sep 22, 2005, at 7:39 PM, Kenneth Zadeck wrote: I will pull a patch together tomorrow. There is currently nothing in the code for keeping the region stuff up to date as changes are made to the cfg. For most changes this would not be hard, but for some it is really hard. OK. I've cod

Re: [RFC] propagating loop dependences from trees to RTL (for SMS)

I will pull a patch together tomorrow. There is currently nothing in the code for keeping the region stuff up to date as changes are made to the cfg. For most changes this would not be hard, but for some it is really hard. Daniel Berlin wrote: On Thu, 2005-09-22 at 18:49 -0700, Devang Pate

Re: [RFC] propagating loop dependences from trees to RTL (for SMS)

On Thu, 2005-09-22 at 18:49 -0700, Devang Patel wrote: > On Sep 22, 2005, at 2:32 AM, Steven Bosscher wrote: > > > On Sep 22, 2005 11:25 AM, Zdenek Dvorak > > <[EMAIL PROTECTED]> wrote: > > > >>> 4. Other ideas? > >>> > >> > >> Preserving the information about loops throughout the > >> optimiz

Re: [RFC] propagating loop dependences from trees to RTL (for SMS)

On Sep 22, 2005, at 2:32 AM, Steven Bosscher wrote: On Sep 22, 2005 11:25 AM, Zdenek Dvorak <[EMAIL PROTECTED]> wrote: 4. Other ideas? Preserving the information about loops throughout the optimizations, and just keeping this information attached at the loop description would by far

Re: [RFC] propagating loop dependences from trees to RTL (for SMS)

On Sep 22, 2005 11:25 AM, Zdenek Dvorak <[EMAIL PROTECTED]> wrote: > > 4. Other ideas? > > Preserving the information about loops throughout the optimizations, and > just keeping this information attached at the loop description would by > far be the cleanest approach -- admitedly also the one tha

  1   2   >