Re: GCC internal re-architecture proposal

On 03/19/2014 05:08 AM, Richard Biener wrote: On Tue, Mar 18, 2014 at 5:34 PM, Diego Novillo wrote: On Tue, Mar 18, 2014 at 10:19 AM, Richard Biener wrote: On Fri, Jun 21, 2013 at 5:27 PM, Andrew MacLeod wrote: [ I foolishly sent this with the document as an attachment... hopefully it gets

Re: ICE with atomic_store

On 06/18/2014 12:59 PM, Basile Starynkevitch wrote: Hello All, The following code: #include struct s1_st { char* i_name; struct s1_st* i_foo; }; void clear_s1 (struct s1_st*s) { __atomic_store(s->i_name, NULL, __ATOMIC_SEQ_CST); } gives an ICE when c

Re: Using BUILT_IN_ATOMIC_...

On 07/09/2014 02:17 AM, Tobias Burnus wrote: Hello all, I am trying to use BUILT_IN_ATOMIC_..., but it does not quite work. I am calling them as: tmp = builtin_decl_explicit (BUILT_IN_ATOMIC_LOAD_4); tmp = build_call_expr_loc (input_location, tmp, 2, atom.expr, ... That gives the followi

Re: [GNU Tools Cauldron 2014] GCC Re-architecture BOF

On 08/05/2014 10:21 AM, Prathamesh Kulkarni wrote: Hi, I have written notes on "GCC re-architecture BOF" presented at the Cauldron. I would be grateful if you would review it for me. Seems to cover the core parts well... all subject to change as we go tho :-) initial focus wlll be the ty

plugins header file

During the re-architecture session at Cauldron, I mentioned the possibility of introducing a plugin-headers.h. This would be a file which plugins could use which would protect them somewhat from header file restructuring. The idea is that it includes all the common things plugins need, (like

Re: plugins header file

On 09/15/2014 02:18 PM, Andrew MacLeod wrote: During the re-architecture session at Cauldron, I mentioned the possibility of introducing a plugin-headers.h. This would be a file which plugins could use which would protect them somewhat from header file restructuring. The idea is that it

Re: [gimple-classes, committed 4/6] tree-ssa-tail-merge.c: Use gassign

On 11/13/2014 05:45 AM, Richard Biener wrote: On Thu, Nov 13, 2014 at 2:41 AM, David Malcolm wrote: On Tue, 2014-11-11 at 11:43 +0100, Richard Biener wrote: On Tue, Nov 11, 2014 at 8:26 AM, Jakub Jelinek wrote: On Mon, Nov 10, 2014 at 05:27:50PM -0500, David Malcolm wrote: On Sat, 2014-11-0

Re: [gimple-classes, committed 4/6] tree-ssa-tail-merge.c: Use gassign

On 11/13/2014 09:34 AM, Richard Biener wrote: On Thu, Nov 13, 2014 at 3:24 PM, Andrew MacLeod wrote: On 11/13/2014 05:45 AM, Richard Biener wrote: On Thu, Nov 13, 2014 at 2:41 AM, David Malcolm wrote: On Tue, 2014-11-11 at 11:43 +0100, Richard Biener wrote: On Tue, Nov 11, 2014 at 8:26 AM

Query about the TREE_TYPE field

I was poking around attribs.c while trial running my tree-type-safety stuff, and it triggered something in decl_attributes() that seems fishy to me. It looks like it was part of the fix for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35315 decl_attributes() can be passed a tree node which is

Re: Query about the TREE_TYPE field

On 11/18/2014 09:40 AM, Jason Merrill wrote: On 11/18/2014 09:26 AM, Andrew MacLeod wrote: I was poking around attribs.c while trial running my tree-type-safety stuff, and it triggered something in decl_attributes() that seems fishy to me. It looks like it was part of the fix for https

Re: Query about the TREE_TYPE field

On 11/18/2014 09:52 AM, Andrew MacLeod wrote: On 11/18/2014 09:40 AM, Jason Merrill wrote: On 11/18/2014 09:26 AM, Andrew MacLeod wrote: I was poking around attribs.c while trial running my tree-type-safety stuff, and it triggered something in decl_attributes() that seems fishy to me. It

Re: Query about the TREE_TYPE field

On 11/18/2014 01:36 PM, Jeff Law wrote: On 11/18/14 09:30, Andrew MacLeod wrote: I tried doing the if before chaning to TREE_TYPE... absolutely no effect on the testsuite or anything else :-) What do you think, should I check this in? What is there is clearly incorrect.we could also

Re: Atomic operations and unaligned memory

On 03/26/2015 04:02 PM, Jason Merrill wrote: The wiki page https://gcc.gnu.org/wiki/Atomic/GCCMM/UnalignedPolicy says, --- typedef char B3[3]; _Atomic B3 obj2; An object will be promoted up to the next lock-free size in order to enable lock free operations, as long as it isn't already a do

Re: Do we have any plans to un-flatten our header files?

On 04/20/2015 09:18 AM, Richard Biener wrote: On Mon, Apr 20, 2015 at 3:02 PM, Martin Jambor wrote: Hi, because I really dislike the hassle our (almost) flattened header files cause quite often, I have made a very simple experiment to find out how the header files really depend on each other.

trunk test result inconsistencies

Is anyone else seeing comparison problems on trunk? I was having problems testing a patch on a 4/16 extraction, so last night I checked out a fresh trunk, built it, ran make check... then removed the build directory, re-built it from scratch again. make check.. and get a bunch of different re

Re: trunk test result inconsistencies

On 04/22/2015 08:19 AM, Jakub Jelinek wrote: On Wed, Apr 22, 2015 at 08:04:03AM -0400, Andrew MacLeod wrote: Is anyone else seeing comparison problems on trunk? I was having problems testing a patch on a 4/16 extraction, so last night I checked out a fresh trunk, built it, ran make check

Re: trunk test result inconsistencies

On 04/22/2015 08:33 AM, Jeff Law wrote: On 04/22/2015 06:28 AM, Andrew MacLeod wrote: On 04/22/2015 08:19 AM, Jakub Jelinek wrote: On Wed, Apr 22, 2015 at 08:04:03AM -0400, Andrew MacLeod wrote: Is anyone else seeing comparison problems on trunk? I was having problems testing a patch on a 4

Spurious parallel make failures in libgcc.

I occasionally get a build failure in libgcc when doing a scratch build (onx86_64-unknown-linux-gnu) , and if I simply do another make, it works fine. I am always building with make -j16, so its never been easy to spot. This morning, it happened to fail in such a way that I can sort of see wh

Re: Spurious parallel make failures in libgcc.

which ends up overwriting gthr-default.h at what turns out to be a poor time ? that sort of makes sense I guess. Im not sure how we synchronize the parallel bits. Andrew so it probably is related to rerunning config.status On 07/15/2015 10:07 AM, Andrew MacLeod wrote: I occasionally get a build

Re: Spurious parallel make failures in libgcc.

On 07/15/2015 02:58 PM, Jeff Law wrote: On 07/15/2015 08:33 AM, Andrew MacLeod wrote: Maybe if gthr-default already existed (as well as config.status), the makefile would spawn the libgcov-interface.c object builds... meanwhile a reconfigure is going which ends up overwriting gthr-default.h

Re: [gimplefe] [gsoc16] Gimple Front End Project

On 03/07/2016 11:33 AM, David Malcolm wrote: So for testing specific passes, I'd much rather have an input format for testing individual passes that: * can be easily generated by GCC from real test cases * ability to turn into unit tests, which implies: * human-readable and editabl

Re: [gimplefe] [gsoc16] Gimple Front End Project

On 03/09/2016 10:47 AM, Richard Biener wrote: On Wed, Mar 9, 2016 at 3:27 PM, Andrew MacLeod wrote: On 03/07/2016 11:33 AM, David Malcolm wrote: So for testing specific passes, I'd much rather have an input format for testing individual passes that: * can be easily generated b

Re: fold() can't fold simple expressions?

On 09/14/2016 09:33 AM, Richard Biener wrote: On Wed, Sep 14, 2016 at 3:25 PM, Aldy Hernandez wrote: Hi folks. I'm working on better range information with Macleod, and I've been playing with folding arbitrary range expressions, which I expect fold() to ahem...fold. I'm surprised that even se

Re: fold() can't fold simple expressions?

On 09/14/2016 03:29 PM, Richard Biener wrote: On September 14, 2016 6:39:14 PM GMT+02:00, Jeff Law wrote: On 09/14/2016 08:08 AM, Andrew MacLeod wrote: range generator understands, we just thought it would be handy to leverage the folder during the proof of concept stage. It's also

Re: FIXME in gcc/gimplify.c

On 4/1/19 12:49 PM, nick wrote: On 2019-04-01 4:21 a.m., Martin Liška wrote: On 3/29/19 11:29 PM, nick wrote: Greetings all, Not sure why this exists still as tree-eh.h is including in tree-eh.c which defines this header as used for this FIXME: #include "tree-pass.h" /* FIXME: onl

Re: FIXME in gcc/gimplify.c

On 4/1/19 5:17 PM, nick wrote: On 2019-04-01 1:54 p.m., Andrew MacLeod wrote: #include "tree-flow.h" #include "cgraph.h" #include "timevar.h" #include "hashtab.h" #include "flags.h" #include "function.h" #include "ggc.h" #i

Re: SSA Pressure Reduction

On 5/7/19 2:40 PM, nick wrote: Andrew, I read through your notes briefly on this issue and if you want help I'm game for it. I assuming it's fixed not through as the gcc projects pages tend to me out of date in my experience. Nick Yeah, very old project and not really on the radar any more :

On-Demand range technology [2/5] - Major Components : How it works

*This note will talk about the 4 major components of the prototype and explain how they work together.   I will be fairly light on detail just to give an overview, we can delve into whatever details are needed. - Range-ops : Range operations at the statement level - GORI - Generates Outgoing Ran

On-Demand range technology [1/5] - Executive Summary

Now that stage 1 has reopened, I’d like to reopen a discussion about the technology and experiences we have from the Ranger project I brought up last year. https://gcc.gnu.org/ml/gcc/2018-05/msg00288.html .  (The original wiki pages are now out of date, and I will work on updating them soon.)

On-Demand range technology [3/5] - The Prototype

There is a functioning prototype in branch “ssa-range” which is a proof of concept that the approach is functional as well as quick, and can be used to answer questions which come up regarding what it can and can’t do.  Our last merge was on April 13th, so it's fairly up to date. We have imple

On-Demand range technology [4/5] - Performance results

We have done extensive performance analysis to help address concerns about the nature of an on-demand model. LLVM made an attempt at something similar,  but suffered from significant performance issues they could not solve with their approach. This approach is not the same, and we have seen no

On-Demand range technology [5/5] - Looking to the future.

A primary goal of this approach is to try to pull the various aspects of VRP apart and make them individually viable so they can be used at appropriate places as needed.  The various components of VRP were identified as:     - Ranges     - Relational queries     - Equivalencies     - Bitmask tr

Re: On-Demand range technology [2/5] - Major Components : How it works

On 5/23/19 8:55 AM, Richard Biener wrote: On Thu, May 23, 2019 at 3:28 AM Andrew MacLeod wrote: 2 * GORI The second component is the “Generates Outgoing Range Info” engine. This is a basic-block oriented component which determines what ssa-names have ranges created on outgoing

Re: On-Demand range technology [3/5] - The Prototype

On 5/23/19 9:10 AM, Richard Biener wrote: On Thu, May 23, 2019 at 3:29 AM Andrew MacLeod wrote: This aspect of symbolics would be handled by a relational/equivalence processing engine that would be follow on work. Using the same basic model as ranges, each tree code is taught to understand

Re: On-Demand range technology [4/5] - Performance results

On 5/23/19 9:29 AM, Richard Biener wrote: On Thu, May 23, 2019 at 3:29 AM Andrew MacLeod wrote: All times are with a release configured compiler. Out of the 242 files, pretty much across the board in all 4 sets of figures, RVRP was faster in about 90% of the cases, and slower in the other 10

Re: On-Demand range technology [5/5] - Looking to the future.

On 5/23/19 10:07 AM, Richard Biener wrote: On Thu, May 23, 2019 at 3:30 AM Andrew MacLeod wrote: This aspect of all calculations being driven from the opcode and combined generically without special casing at a higher level is both very powerful and less prone to produce errors. Our initial

Re: On-Demand range technology [3/5] - The Prototype

On 5/24/19 5:36 AM, Richard Biener wrote: On Fri, May 24, 2019 at 12:27 AM Eric Botcazou wrote: While I agree that symbolic ranges are a complication and that most cases it currently handles are not "value-range" things I do not agree with the idea that we can simply remove handling them and de

Re: On-Demand range technology [2/5] - Major Components : How it works

On 5/27/19 9:02 AM, Richard Biener wrote: On Fri, May 24, 2019 at 5:50 PM Andrew MacLeod wrote: The above suggests that iff this is done at all it is not in GORI because those are not conditional stmts or ranges from feeding those. The machinery doing the use-def walking from stmt context

Re: On-Demand range technology [3/5] - The Prototype

On 5/29/19 9:11 AM, Richard Biener wrote: On Tue, May 28, 2019 at 4:41 PM Jeff Law wrote: This aspect of symbolics would be handled by a relational/equivalence processing engine that would be follow on work. Using the same basic model as ranges, each tree code is taught to understand the rel

Re: On-Demand range technology [2/5] - Major Components : How it works

On 5/29/19 7:15 AM, Richard Biener wrote: On Tue, May 28, 2019 at 4:17 PM Andrew MacLeod wrote: On 5/27/19 9:02 AM, Richard Biener wrote: On Fri, May 24, 2019 at 5:50 PM Andrew MacLeod wrote: The above suggests that iff this is done at all it is not in GORI because those are not conditional

Re: On-Demand range technology [2/5] - Major Components : How it works

On 5/31/19 2:16 PM, Jeff Law wrote: On 5/31/19 9:40 AM, Andrew MacLeod wrote: On 5/29/19 7:15 AM, Richard Biener wrote: On Tue, May 28, 2019 at 4:17 PM Andrew MacLeod wrote: On 5/27/19 9:02 AM, Richard Biener wrote: On Fri, May 24, 2019 at 5:50 PM Andrew MacLeod wrote: The above suggests

Re: On-Demand range technology [2/5] - Major Components : How it works

On 5/31/19 6:00 PM, Jeff Law wrote: On 5/31/19 2:26 PM, Andrew MacLeod wrote: On 5/31/19 2:16 PM, Jeff Law wrote: On 5/31/19 9:40 AM, Andrew MacLeod wrote: stmt-level tracking of ranges are sometimes important.  This is something the machinery cannot provide - correct?  At least not

Re: On-Demand range technology [2/5] - Major Components : How it works

On 6/4/19 11:26 AM, Richard Biener wrote: On Fri, May 31, 2019 at 5:40 PM Andrew MacLeod wrote: On 5/29/19 7:15 AM, Richard Biener wrote: On Tue, May 28, 2019 at 4:17 PM Andrew MacLeod wrote: On 5/27/19 9:02 AM, Richard Biener wrote: On Fri, May 24, 2019 at 5:50 PM Andrew MacLeod wrote

Re: On-Demand range technology [2/5] - Major Components : How it works

On 6/4/19 11:37 AM, Richard Biener wrote: On Tue, Jun 4, 2019 at 5:26 PM Richard Biener wrote: But you still have a reference to the range in evry BB dominated by the definition? Btw, I was thinking of unsigned char foo(long); void baz(unsigned char c) { try{ long i = c; i +

Re: On-Demand range technology [2/5] - Major Components : How it works

On 6/4/19 1:07 PM, Richard Biener wrote: On June 4, 2019 6:50:07 PM GMT+02:00, Andrew MacLeod wrote: On 6/4/19 11:37 AM, Richard Biener wrote: where the single(!) query of the range of i on the alloca call will populate N BBs caches with the Nth having ranges for all SSA defs of i running

Re: On-Demand range technology [2/5] - Major Components : How it works

On 6/4/19 4:21 PM, Marc Glisse wrote: On Tue, 4 Jun 2019, Martin Sebor wrote: On 5/31/19 9:40 AM, Andrew MacLeod wrote: On 5/29/19 7:15 AM, Richard Biener wrote: On Tue, May 28, 2019 at 4:17 PM Andrew MacLeod wrote: On 5/27/19 9:02 AM, Richard Biener wrote: On Fri, May 24, 2019 at 5:50 PM

On-Demand range technology [6/5] - Integration

After the various discussions, I've evaluated how I think everything can fit together, so this is my proposal for integration with trunk. The complete Ranger prototype consists of 5 major  components, one of which is missing/un-implemented as yet :-) 1 - irange -  This is the non-symboli

Re: Dead code at gcc/tree-ssa-loop.c:772?

On 6/6/19 6:20 AM, Martin Liška wrote: Hi. The code is dead: 757 char * 758 get_lsm_tmp_name (tree ref, unsigned n, const char *suffix) 759 { 760 char ns[2]; 761 762 lsm_tmp_name_length = 0; 763 gen_lsm_tmp_name (ref); 764 lsm_tmp_name_add ("_lsm");

Re: Dead code at gcc/tree-ssa-loop.c:772?

On 6/6/19 1:20 PM, Jeff Law wrote: On 6/6/19 7:02 AM, Andrew MacLeod wrote: On 6/6/19 6:20 AM, Martin Liška wrote: Hi. The code is dead:     757    char *     758    get_lsm_tmp_name (tree ref, unsigned n, const char *suffix)     759    {     760  char ns[2];     761     762

Re: On-Demand range technology [6/5] - Integration

On 6/7/19 8:25 AM, Richard Biener wrote: On Wed, Jun 5, 2019 at 10:56 PM Andrew MacLeod wrote: After the various discussions, I've evaluated how I think everything can fit together, so this is my proposal for integration with trunk. The complete Ranger prototype consists of 5

Re: On-Demand range technology [1/5] - Executive Summary

On 6/19/19 11:04 PM, Kugan Vivekanandarajah wrote: Hi Andrew, Thanks for working on this. Enable elimination of zext/sext with VRP patch had to be reverted in (https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00672.html) due to the need for value ranges in PROMOTED_MODE precision for at least 1 te

Project Ranger Update

With the end of stage 1 approaching, I figure its time for an update on project Ranger. range-ops was integrated with trunk on Oct 2, all ranges are generated now using this component. GORI-computes was the other piece we were hoping to get in. This component is "Generates Outgoing Range Inf

getting the right boolean type

I'm a little confused. In gimple I need to do a comparison between 2 values, and I create a boolean_type_node result. I then combine it with an existing condition, but fortran is crapping out on me because the boolean_type I created is not compatible with the boolean type is has already created

Re: getting the right boolean type

On 11/09/2017 10:16 AM, Richard Biener wrote: On Thu, Nov 9, 2017 at 3:44 PM, Andrew MacLeod wrote: I'm a little confused. In gimple I need to do a comparison between 2 values, and I create a boolean_type_node result. I then combine it with an existing condition, but fortran is crappin

Re: getting the right boolean type

On 11/09/2017 10:29 AM, Richard Biener wrote: On Thu, Nov 9, 2017 at 4:24 PM, Andrew MacLeod wrote: On 11/09/2017 10:16 AM, Richard Biener wrote: On Thu, Nov 9, 2017 at 3:44 PM, Andrew MacLeod wrote: I'm a little confused. In gimple I need to do a comparison between 2 values, and I c

Types of operands in a gimple equality operation

Before I open a PR, I want to confirm my beliefs. Is it not true that both operations of a gimple operation such as == or != must satisfy types_compatible_p (op1_type, op2_type) ? Even when one is a constant? given : _10 = _2 != 0 so the generic node for the 0 needs to be a type compat

Re: Types of operands in a gimple equality operation

On 11/10/2017 08:49 AM, Andrew MacLeod wrote: The IL is comparing ptr == 0B and I see: Type op1 : 0x7fd8e312df18 -> integer(kind=4) (*) (void) Type op2 : 0x7fd8e2fa10a8 -> void * These 2 types fail the types_compatible_p test. So is this a bug like I think it is? Andrew Inter

Re: Types of operands in a gimple equality operation

On 11/10/2017 09:03 AM, Richard Biener wrote: On Fri, Nov 10, 2017 at 2:49 PM, Andrew MacLeod wrote: Before I open a PR, I want to confirm my beliefs. Is it not true that both operations of a gimple operation such as == or != must satisfy types_compatible_p (op1_type, op2_type) ? Even when

Project Ranger

I'd like to introduce a project we've been working on for the past year an a half. The original project goal was to see if we could derived accurate range information from the IL without requiring much effort on the client side. The idea being that a pass could simply ask "what is the range of

Re: Project Ranger

On 05/30/2018 03:41 AM, Eric Botcazou wrote: The Ranger is far enough along now that we have confidence in both its approach and ability to perform, and would like to solicit feedback on what you think of it, any questions, possible uses, as well as potential requirements to integrate with trun

Re: Project Ranger

On 05/30/2018 10:39 AM, David Malcolm wrote: On Tue, 2018-05-29 at 19:53 -0400, Andrew MacLeod wrote: [...snip...] The code is located on an svn branch *ssa-range*. It is based on trunk at revision *259405***circa mid April 2018. Is this svn branch mirrored on gcc's git mirror? I tri

Re: Project Ranger

On 06/01/2018 05:48 AM, Richard Biener wrote: On Wed, May 30, 2018 at 1:53 AM Andrew MacLeod wrote: This allows queries for a range on an edge, on entry to a block, as an operand on an specific statement, or to calculate the range of the result of a statement. There are no prerequisites to

Re: Project Ranger

On 06/04/2018 11:21 AM, Richard Biener wrote: On Mon, Jun 4, 2018 at 5:17 PM Richard Biener wrote:> On Fri, Jun 1, 2018 at 10:38 PM Andrew MacLeod wrote: On 06/01/2018 05:48 AM, Richard Biener wrote: On Wed, May 30, 2018 at 1:53 AM Andrew MacLeod wrote: bah, gmail now completely mang

Re: Project Ranger

On 06/04/2018 11:17 AM, Richard Biener wrote: It wont be perfect however as many of those routines are written with the assumption that ranges are either a single range or an anti range. we no longer have that restriction and we will diverge in those cases. But having 1 single range or N ran

switch statement type incompatibilities ?

What is valid in a switch statement for type compatibility?  I would have expected it to follow what appears to be the gimple "standard"  of allowing types that pass the "useless_type_convserion_p()"  test. I am doing some switch analysis and an triggering a failure in ADA when the gimple_sw

Re: switch statement type incompatibilities ?

On 10/29/18 1:30 PM, Richard Biener wrote: On October 29, 2018 6:20:25 PM GMT+01:00, Andrew MacLeod wrote: What is valid in a switch statement for type compatibility?  I would have expected it to follow what appears to be the gimple "standard"  of allowing types tha

Dealing with alignment on atomic operations.

I punted on determinig what to do with alignment issues when implementing atomics for 4.7. The time has come however to address what is to be done. I've put together a wiki page and discussed its contents with a few people to get this cut. Hopefully it seems reasonably sane. :-) I've added

Re: How much time left till phase 3?

On 10/02/2012 05:45 AM, Richard Guenther wrote: I expect stage1 to close mid to end of October (after which it lasted for more than 7 months). Btw, I realize that the aarch64 port probably also wants to merge even if I didn't see a merge proposal or know whether they have patches to generic co

Re: RFC - Alternatives to gengtype

On 11/15/2012 07:59 PM, Diego Novillo wrote: At this point, we are trying to reach consensus on the general direction that we should take. Given how intertwined GC and PCH are, the choices we make for one affect the other. We don't have a strong preference at the moment, but we are leaning in

Re: RFC - Alternatives to gengtype

On 11/19/2012 08:24 PM, Lawrence Crowl wrote: On 11/16/12, Diego Novillo wrote: On Nov 16, 2012 Basile Starynkevitch wrote: I actually disagree with the "Get rid of GC" idea, but I am not sure that we all understand the same thing about it (and I have the feeling of the opposite). I would pro

Re: Simplifying Gimple Generation

On 11/14/2012 08:13 PM, Lawrence Crowl wrote: Diego and I seek your comments on the following (loose) proposal. We propose a simplified form using new build helper classes ssa_seq and ssa_stmt that would allow the above code to be written as follows. ssa_seq q; ssa_stmt t = q.stmt (NE_EXPR, s

Re: Unifying the GCC Debugging Interface

On 11/14/2012 08:12 PM, Lawrence Crowl wrote: Diego and I seek your comments on the following (loose) proposal. We propose to provide several function overload sets, as below. dump_pretty This function overload set provides the bulk of the printing. They will use the existing prett

Re: Hash table iterators.

On 11/22/2012 01:18 PM, Lawrence Crowl wrote: I have found that tree-flow.h implements iteration over htab_t, while there is no current facility to do that with hash_table. Unfortunately, the specific form does not match the standard C++ approach to iterators. We have several choices. (1) Ignor

GCC internal re-architecture proposal

[ I foolishly sent this with the document as an attachment... hopefully it gets rejected and anyone interested can simply download the document from the wiki..] Over the past couple of months, I've slowly been putting together an action plan to help modernize GCC's source base. We've had vari

Re: GCC internal re-architecture proposal

On 06/21/2013 11:27 AM, Andrew MacLeod wrote: I hope this link will work :-)... http://gcc.gnu.org/wiki/AndrewMacLeod?action=AttachFile&do=view&target=gccrestructureplan2.1.odt Highlander or you can use this PDF file... http://gcc.gnu.org/wiki/AndrewMacLeod?action=AttachFile

Re: GCC internal re-architecture proposal

On 06/21/2013 12:16 PM, Joseph S. Myers wrote: A few observations: * You don't mention anything about separating host-side and target-side configuration, which are also entangled. A slightly out-of-date list of target macros used in target-side code is at

GCC Re-architecture BOF

In case anyone is planning to attend the BOF on Sunday and missed the proposal document posted last month, it can be found here: http://gcc.gnu.org/wiki/AndrewMacLeod?action=AttachFile&do=view&target=gccrestructureplan2.1.pdf Andrew

Re: New file extension

On 07/30/2013 08:27 AM, Marek Polacek wrote: On Tue, Jul 30, 2013 at 07:13:22AM -0400, Diego Novillo wrote: On Tue, Jul 30, 2013 at 5:04 AM, Marek Polacek wrote: On Mon, Jul 29, 2013 at 10:08:26PM +0200, Martin Jambor wrote: I do not care very much but I disagree. Having some files with .c s

Re: i386 __atomic_compare_exchange_n not found

On 08/09/2013 12:59 PM, Joe Buck wrote: On Fri, Aug 09, 2013 at 11:23:51AM -0500, Joel Sherrill wrote: On 8/9/2013 11:05 AM, Deng Hengyi wrote: Hi Joel, I have done a test, it seems that '-march=i386' does not provide "__atomic_compare_exchange_n" libs. And '-march=i486' or '-march=pentium' c

RFC: Inlines, LTO and GCC

A number of header files have inline functions declared in them. Some of these functions are actually quite large, and I doubt that inlining them is the right thing. For instance, tree-flow-inline.h has some quite large functions. Many of the op_iter* functions are 30-40 lines long, and get_

Re: RFC: Inlines, LTO and GCC

On 09/10/2013 04:44 AM, Richard Biener wrote: On Tue, Sep 10, 2013 at 10:11 AM, Jakub Jelinek wrote: On Tue, Sep 10, 2013 at 10:06:04AM +0200, David Brown wrote: This last point is crucial. I haven't looked at the code in question, but one point to check is how the functions are called. If t

Mothballing C11 atomic work for now.

I don't have the time to finish pushing through the C11 atomic work for this release. Much of the remaining parts are in the parser, which I know very little about, and I won't be able to do a sufficient job in the time remaining, so I am switching my focus to the interface work and getting the

Re: graphite-scop-detection.c:1335:26: error: ‘replace_exp’ was not declared in this scope

On 10/02/2013 03:29 PM, Paolo Carlini wrote: Hi, currently bootstrap is broken for me with errors of this kind: /scratch/Gcc/svn-dirs/trunk/gcc/graphite-scop-detection.c: In function ‘void canonicalize_loop_closed_ssa(loop_p)’: /scratch/Gcc/svn-dirs/trunk/gcc/graphite-scop-detection.c:1335:26:

Re: graphite-scop-detection.c:1335:26: error: ‘replace_exp’ was not declared in this scope

On 10/02/2013 03:33 PM, Andrew MacLeod wrote: On 10/02/2013 03:29 PM, Paolo Carlini wrote: Hi, currently bootstrap is broken for me with errors of this kind: /scratch/Gcc/svn-dirs/trunk/gcc/graphite-scop-detection.c: In function ‘void canonicalize_loop_closed_ssa(loop_p)’: /scratch/Gcc/svn

Re: graphite-scop-detection.c:1335:26: error: ‘replace_exp’ was not declared in this scope

On 10/02/2013 03:55 PM, Paolo Carlini wrote: .. patchlet worked for me. Thanks again! NP.. , all checked in. thanks for testing it. Andrew

[RFC] Include file structuring.

The tree-flow.h restructuring now brings us to the larger question of exactly how we want includes organized. All the remaining includes in tree-ssa.h are required by numerous other .c files. The actual number of .c files which will need to #include any given file is: (roughly calculated by t

Re: [RFC] Include file structuring.

On 10/18/2013 12:55 PM, Jeff Law wrote: On 10/18/13 08:00, Andrew MacLeod wrote: The question is... Do we allow a .h file like this to be an aggregator, meaning a file can just include tree-ssa.h and get all this, or do we push it all down to the .c file, and actually include what each one

Re: [RFC] Include file structuring.

On 10/22/2013 08:27 AM, Joern Rennecke wrote: On 18 October 2013 19:16, Andrew MacLeod wrote: So I think I am in favour of no includes in .h files... It may make it more obvious when a file is using some other inappropriate file for something, and it is easier for my simple analysis tools to

Re: Question about a fix for PR 58925

on a related note, is there something I have to do to make the compiler bootstrap on x86_64? on x86_64 I checked out a fresh branch this morning, and my bootstrap fails trying to configure cilk runtime. It was doing it yesterday to me when I updated, so I tried a fresh checkout this morning..

Re: Question about a fix for PR 58925

On 10/31/2013 12:05 PM, Iyer, Balaji V wrote: -Original Message- From: Andrew MacLeod [mailto:amacl...@redhat.com] Sent: Thursday, October 31, 2013 11:44 AM To: Iyer, Balaji V Cc: 'gcc@gcc.gnu.org'; Jeff Law Subject: Re: Question about a fix for PR 58925 on a related note,

Re: Question about a fix for PR 58925

On 10/31/2013 12:13 PM, Andrew MacLeod wrote: On 10/31/2013 12:05 PM, Iyer, Balaji V wrote: -Original Message- From: Andrew MacLeod [mailto:amacl...@redhat.com] Sent: Thursday, October 31, 2013 11:44 AM To: Iyer, Balaji V Cc: 'gcc@gcc.gnu.org'; Jeff Law Subject: Re: Questi

Re: Question about a fix for PR 58925

On 10/31/2013 01:02 PM, Andrew MacLeod wrote: On 10/31/2013 12:13 PM, Andrew MacLeod wrote: There isnt much difference in the log or status files... nothing real obvious. ie, no fails or anything... still looking... I *hate* configuration crud. sigh. Andrew OK, hacking around with

Re: Question about a fix for PR 58925

On 10/31/2013 03:31 PM, Andrew MacLeod wrote: On 10/31/2013 01:02 PM, Andrew MacLeod wrote: On 10/31/2013 12:13 PM, Andrew MacLeod wrote: but the file is in the correct directory: /gcc/2013-10-31/build/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs/libstdc++.so -> libstdc++.so.6.0

Re: RFC: gimple.[ch] break apart

On 11/01/2013 10:45 AM, Diego Novillo wrote: On Wed, Oct 30, 2013 at 10:26 PM, Andrew MacLeod wrote: I've made 4 attempts now to split gimple.[ch] into reasonable component parts, and I've finally found something that I can make work and fits my plans. I've attached a diagra

Re: RFC: gimple.[ch] break apart

On 11/01/2013 10:59 AM, Diego Novillo wrote: On Fri, Nov 1, 2013 at 10:56 AM, Andrew MacLeod wrote: Isnt "gimplify" clear to everyone? :-) I've even been referring to an interface to the backend target info for the front end as "targetify" lately :-) Yes, but onl

Re: RFC: gimple.[ch] break apart

On 11/01/2013 11:17 AM, Diego Novillo wrote: On Fri, Nov 1, 2013 at 11:11 AM, Andrew MacLeod wrote: Longer term... the BE will not be calling into gimplify at all.. it will be purely a front end thing. As direct tree access vanishes, the optimizers will be forced to generate gimple directly

Re: include tree.h instead of tree-core.h in expr.h

On 12/18/2013 08:08 AM, Diego Novillo wrote: On Wed, Dec 18, 2013 at 6:57 AM, Prathamesh Kulkarni wrote: Would it be better to include tree.h instead of tree-core.h (tree.h includes tree-core.h anyway), or shall I leave these macros untouched ? Better leave these macros intact for now. We are

mainline problems?

I *just* checked out mainline, and it is failing to build like so: (x86 with checking enabled) libbackend.a(print-rtl.o): In function `print_decl_name': /src/gcc/2006-05-16/gcc/gcc/print-rtl.c:73: multiple definition of `flag_dump_unnumbered' libbackend.a(options.o):(.bss+0x1ac): first defined h

Re: mainline problems?

On Tue, 2006-05-16 at 11:50 -0400, Andrew MacLeod wrote: > I *just* checked out mainline, and it is failing to build like so: > > (x86 with checking enabled) > > libbackend.a(print-rtl.o): In function `print_decl_name': > /src/gcc/2006-05-16/gcc/gcc/print-rtl.c:73:

Re: mainline problems?

On Tue, 2006-05-16 at 10:20 -0700, H. J. Lu wrote: > On Tue, May 16, 2006 at 12:49:13PM -0400, Andrew MacLeod wrote: > > On Tue, 2006-05-16 at 11:50 -0400, Andrew MacLeod wrote: > > > I *just* checked out mainline, and it is failing to build like so: > > > >

  1   2   3   >