Re: value-range.cc:2165: ICE in invert

On 8/25/24 03:48, Richard Biener wrote: On Sat, Aug 24, 2024 at 6:19 PM Georg-Johann Lay wrote: Trying to use the value-range interface and functions I am running into that ICE when using invert(). From what the sources suggest, invert() computes the complement of the current set (the unio

Re: get_range_query vs NULL argument

On 2/15/23 14:50, Andrew Pinski wrote: Hi, While fixing PR 108354, I came across that ssa_name_has_boolean_range calls get_range_query with cfun as the argument but sometimes while in IPA passes cfun is currently nullptr. The question should we check the argument before calling get_range_que

Re: Documentation format question

On 5/27/22 02:38, Richard Biener wrote: On Wed, May 25, 2022 at 10:36 PM Andrew MacLeod via Gcc wrote: I am going to get to some documentation for ranger and its components later this cycle. I use to stick these sorts things on the wiki page, but i find that gets out of date really quickly

Documentation format question

I am going to get to some documentation for ranger and its components later this cycle. I use to stick these sorts things on the wiki page, but i find that gets out of date really quickly.  I could add more comments to the top of each file, but that doesnt seem very practical for larger archit

Re: getting branch conditions using ranger

On 12/14/21 18:55, Martin Sebor wrote: Andrew, to improve the context of the late warnings I'm trying to see how to get the execution path(s) leading from function entry up to a statement.  For example, for the code below I'd like to "collect" and show the three conditionals in the context of the

Re: [TCWG CI] 471.omnetpp slowed down by 8% after gcc: Avoid invalid loop transformations in jump threading registry.

On 9/29/21 7:59 AM, Maxim Kuvyrkov wrote: Does it run like once a day/some-time-period, and if you note a regression, narrow it down? Configurations that track master branches have 3-day intervals. Configurations that track release branches — 6 days. If a regression is detected it is n

Re: [TCWG CI] 471.omnetpp slowed down by 8% after gcc: Avoid invalid loop transformations in jump threading registry.

On 9/27/21 11:39 AM, Maxim Kuvyrkov via Gcc wrote: On 27 Sep 2021, at 16:52, Aldy Hernandez wrote: [CCing Jeff and list for broader audience] On 9/27/21 2:53 PM, Maxim Kuvyrkov wrote: Hi Aldy, Your patch seems to slow down 471.omnetpp by 8% at -O3. Could you please take a look if this is so

bug in DSE?

I dont't want to immediately open a PR,  so I'll just ask about testsuite/gcc.dg/pr83609.c. the compilation string  is   -O2 -fno-tree-forwprop -fno-tree-ccp -fno-tree-fre -fno-tree-pre -fno-code-hoisting Which passes as is. if I however add   -fno-tree-vrp   as well, then it looks like dead

Re: wide int knowledge/bug?

On 10/27/20 1:46 PM, Richard Sandiford wrote: Jakub Jelinek via Gcc writes: On Tue, Oct 27, 2020 at 01:18:03PM -0400, Andrew MacLeod via Gcc wrote: I was looking at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97596 and the ranger is constructing some 128 bit constants and calling

wide int knowledge/bug?

I was looking at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97596 and the ranger is constructing some 128 bit constants and calling wide_int_to_tree to turn them into trees. In particular, it starts with the value p r.lower_bound(0) { = {val = {-65535, 9223372036854775807, 140737488257608}

Project Ranger Status

We originally intended to start pushing ranger code into trunk shortly after the start of stage 1, but of course.. delays, delays :-) So here is the latest status/changes since last fall and our proposed time-line going forward.  I'll do the executive summary here, and more details at each sub

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

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

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: 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: 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");

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: 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

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 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 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 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 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/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 [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/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/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 [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/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 [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

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

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 [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 [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 [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

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 :

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: 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: 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

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: 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

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 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 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

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: 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

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

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: 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

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

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: 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: 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: [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: [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: 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: 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

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: 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

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

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: 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.

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: 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: 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 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

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: [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

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: 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

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: [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

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: 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: 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: 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

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: 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 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: 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: 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 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 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 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: [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: [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

[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: 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

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: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:

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: 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

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: 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

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

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: 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

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

  1   2   3   >