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

C++0x memory model code gen

I've created a wiki page with the changes to codegen for the C++ memory model that we're working on implementing. http://gcc.gnu.org/wiki/Atomic/GCCMM/CodeGen in a nutshell, it expands the set of __sync atomic builtin's to take another parameter for memory model, and then allow machine descrip

C++0x atomics and GCC - update

I've updated the original documents on the atomics page http://gcc.gnu.org/wiki/Atomic/GCCMM to add some clarity in places (especially in the 'synchronization models' section) and updated some bitrot. As mentioned last week, I've added a section on codegen which Aldy has begun implementing

Re: GCC 4.7.0 Status Report (2011-09-09)

On 09/09/2011 03:09 AM, Jakub Jelinek wrote: In particular, is transactional-memory branch mergeable within a month and half, at least some parts of cxx-mem-model branch, There will certainly be some parts of the branch which would be appropriate for merging with mainline in october. We ough

Re: should sync builtins be full optimization barriers?

On 09/09/2011 04:17 AM, Jakub Jelinek wrote: On Fri, Sep 09, 2011 at 10:07:30AM +0200, Paolo Bonzini wrote: sync builtins are described in the documentations as being full memory barriers, with the possible exception of __sync_lock_test_and_set. However, GCC is not enforcing the fact that they a

Re: should sync builtins be full optimization barriers?

On 09/09/2011 09:09 PM, Geert Bosch wrote: For the C++0x atomic types there are: void A::store(C desired, memory_order order = memory_order_seq_cst) volatile; void A::store(C desired, memory_order order = memory_order_seq_cst); where the first variant (with order = memory_order_relaxed) would a

Re: should sync builtins be full optimization barriers?

On 09/11/2011 02:22 PM, Paolo Bonzini wrote: On 09/11/2011 04:12 PM, Andrew MacLeod wrote: tail->value = othervalue // global variable write atomic_exchange (&var, tail) // acquire operation although the optimizer moving the store of tail->value to

Re: should sync builtins be full optimization barriers?

On 09/12/2011 02:40 PM, Geert Bosch wrote: thread 1 thread 2 thread 3 thread 4 x=1; r1=x x=3; r3=x; x=2; r2=x x=4; r4=x; Even with relaxed memory ordering, all modifications to x have to occur in some particular tot

Re: should sync builtins be full optimization barriers?

On 09/12/2011 09:52 PM, Geert Bosch wrote: No that's false. Even on systems with nice memory models, such as x86 and SPARC with a TSO model, you need a fence to avoid that a write-load of the same location is forced to make it all the way to coherent memory and not forwarded directly from th

Re: should sync builtins be full optimization barriers?

On 09/13/2011 10:58 AM, Geert Bosch wrote: On Sep 13, 2011, at 08:08, Andrew MacLeod wrote: On 09/12/2011 09:52 PM, Geert Bosch wrote: No that's false. Even on systems with nice memory models, such as x86 and SPARC with a TSO model, you need a fence to avoid that a write-load of the

Re: should sync builtins be full optimization barriers?

Hi, On Tue, 13 Sep 2011, Andrew MacLeod wrote: Your example was not about regular stores, it used atomic variables. This reads as if there exists non-atomic variables in the new C++ mem-model. Assuming that this is so, why do those ugly requirements of not introducing new data races also

Re: should sync builtins be full optimization barriers?

On 09/26/2011 01:31 PM, James Dennett wrote: On Mon, Sep 26, 2011 at 9:57 AM, Andrew MacLeod wrote: The C++11 memory model asserts that a program containing data races involving *non-atomic* variables has undefined semantics. The compiler is not allowed to introduce any data races into an

C++11 atomic library notes

I've been working on GCC's C++11 atomic implementation. In discussions with Lawrence, I've recently discovered a fundamental change in what libstdc++-v3 is likely to provide as far as an implementation. Previously, header files provided a choice between a locked or a lock-free implementation,

Re: C++11 atomic library notes

On 10/01/2011 02:55 AM, Marc Glisse wrote: "The compiler must ensure that for any given object, it either ALWAYS inlines lock free routines, OR calls the external routines. For any given object, these cannot be intermixed." Why? You give an example explaining why it is fine to link 386 and

Re: C++11 atomic library notes

On Sat, 1 Oct 2011, Andrew MacLeod wrote: Ah ok, I had understood: * if __atomic_store_8 is inlined on line 18, it should also be inlined on line 42 when instead it is: * we can't have a locked addition and a lock-free subtraction (hence the __atomic_is_lock_free which only takes a

Re: C++11 atomic library notes

On 10/03/2011 01:31 PM, Richard Henderson wrote: On 09/30/2011 01:36 PM, Andrew MacLeod wrote: http://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary __atomic_store (size_t obj_size, T *mem, T val, enum memory_model model) I don't like this. I really cannot imagine any situation for whic

Re: C++11 atomic library notes

On 10/05/2011 12:14 AM, Jeffrey Yasskin wrote: If, as the document proposes, "16 byte volatile will have to call the external rotines, but 16 byte non-volatiles would be lock-free.", and the external routines use locked accesses for 16-byte volatile atomics, then this makes the concurrent access

Re: C++11 atomic library notes

On 10/05/2011 10:44 AM, Jeffrey Yasskin wrote: Yes, that's what I'm suggesting. The rule for 'volatile' from the language is just that "Accesses to volatile objects are evaluated strictly according to the rules of the abstract machine." If the instruction-level implementation for a 16-byte atomi

C++11 atomic library notes V2 - updated

After some discussions and further coding, the external library has been refined. I've updated the document at http://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary In a nutshell, the changes are: 1 - generic routines = The generic version routines for arbitrary sized objects were unimplem

Potentially merging cxx-mem-model with mainline.

I'd like to have the cxx-mem-model branch considered for merging with mainline before we end stage 1 for GCC 4.7. What it is == GCC has had the __sync built-ins for atomic operations for a number of years now. They implement a "sequential consistent" (AKA seq-cst) synchronization mod

Re: Potentially merging cxx-mem-model with mainline.

On 10/27/2011 04:55 AM, Richard Guenther wrote: I am really expecting this branch to be merged for 4.7. The current status is very presentable IMHO. If you get (or already got) ack from maintainers covering the areas you touch then I am fine with merging this branch for 4.7 from a RM point of

C++ memory model... What to do with libatomic

Libstdc++-v3 use to provide a locked implementation of classes for sizes which didn't have lock-free support. That was removed for this release as it caused a program compiled with a specific version of GCC to be locked into that implementation. The design criteria for the new __atomic builti

Re: libsupc++/exception cannot find bits/atomic_lockfree_defines.h

On 12/02/2011 06:59 PM, Diego Novillo wrote: I just merged from trunk and several of my C++ tests are failing with the error: In file included from <...>/libstdc++-v3/libsupc++/new:42:0, from <...>/gcc/testsuite/g++.dg/pph/x5dynarray3.h:5:<...>/libstdc++-v3/libsupc++/excepti

Re: Memory corruption due to word sharing

And I assume that since the compiler does them, that would now make it impossible for us to gather a list of all the 'lock' prefixes so that we can undo them if it turns out that we are running on a UP machine. When we do SMP operations, we don't just add a "lock" prefix to it. We do this:

Re: Memory corruption due to word sharing

On 02/03/2012 12:16 PM, Linus Torvalds wrote: So we have several atomics we use in the kernel, with the more common being - add (and subtract) and cmpchg of both 'int' and 'long' This would be __atomic_fetch_add, __atomic_fetch_sub, and __atomic_compare_exchange. For 4.8 __atomic_compare_e

Re: [RFC] Better debug info by substitution tracking for inliner (and other passes eliminating whole user variables)

Jan Hubicka wrote: Hi, this patch resulted from attempt to solve regression we have in gdb.opt/inline-locals.exp gdb testsuite and also problems with fact that when clonning function by ipa-cp we lose any information on function argument. (and yes, it solves it) <...> I know that this is one of

Re: GCC 4.4.0 Status Report (2009-03-13)

Daniel Berlin wrote: 2. Where is the pushback by the SC onto the FSF? Why haven't we given them a hard deadline, or even any deadline at all? It's clear when they have no deadlines, they take forever to get anything done. After all, if they are allowed to not prioritize it and have no incentive t

Debuglocus

I was planning to send this note next week, but I guess I should know better than to put something on the wiki and think it won't be noticed, even if it is in a crusty dark corner :-) I see on #gcc that my debuglocus document has been discovered. It describes the work Aldy and I are experiment

Re: (known?) Issue with bitmap iterators

Daniel Berlin wrote: On Sat, Jun 20, 2009 at 10:54 AM, Jeff Law wrote: Imagine a loop like this EXECUTE_IF_SET_IN_BITMAP (something, 0, i, bi) { bitmap_clear_bit (something, i) [ ... whatever code we want to process i, ... ] } This code is unsafe. No, this is known, and in fact,

C++0x Memory model and gcc

I've been working for a while on understanding how the new memory model and Atomics work, and what the impacts are on GCC. It would be ideal to get as many of these changes into GCC 4.6 as possible. I've started work on some of the modifications and testing, and the overall impact on GCC shou

Re: C++0x Memory model and gcc

Joseph S. Myers wrote: On Thu, 6 May 2010, Andrew MacLeod wrote: - Implementation of atomic variables and synchronization modes as well as a new infrastructure to test these types of things. I presume you've read the long thread starting at <http://gcc.gnu.org/ml/gcc

Re: C++0x Memory model and gcc

Richard Guenther wrote: On Thu, May 6, 2010 at 5:50 PM, Richard Guenther wrote: First let me say that the C++ memory model is crap when it forces data-races to be avoided for unannotated data like the examples for packed data. And it isn't consistent across the board, since neighbouri

Re: C++0x Memory model and gcc

Ian Lance Taylor wrote: Andrew MacLeod writes: I've been working for a while on understanding how the new memory model and Atomics work, and what the impacts are on GCC. Thanks for looking at this. One issue I didn't see clearly was how to actually implement this in th

Re: C++0x Memory model and gcc

Richard Guenther wrote: On Thu, May 6, 2010 at 6:22 PM, Andrew MacLeod wrote: Richard Guenther wrote: I would have hoped that only data races between independent objects are covered, thus tmp = a.i; b.j = tmp; would qualify as a load of a and a store to b as far as dependencies are

[Fwd: Re: C++0x Memory model and gcc]

Oops, didn't reply all... Original Message Subject:Re: C++0x Memory model and gcc Date: Fri, 07 May 2010 10:37:40 -0400 From: Andrew MacLeod To: Ian Lance Taylor References: <4be2e39a.5060...@redhat.com> <4be2ecdb.2040...@redhat.com>

Re: C++0x Memory model and gcc

On 05/10/2010 12:39 AM, Ian Lance Taylor wrote: Albert Cohen writes: I agree. Or even, =c++0x or =gnu++0x On the other hand, I fail to see the differen between =single and =fast, and the explanation about "the same memory word" is not really relevant as memory models typically tell you ab

Re: C++0x Memory model and gcc

Miles Bader wrote: Andrew MacLeod writes: -fmemory-model=single - Enable all data races introductions, as they are today. (relax all 4 internal restrictions.) One could still use this mode with a multi-threaded program as long as explicit synchronization is done, right

Re: C++0x Memory model and gcc

Miles Bader wrote: Andrew MacLeod writes: -fmemory-model=single - Enable all data races introductions, as they are today. (relax all 4 internal restrictions.) One could still use this mode with a multi-threaded program as long as explicit synchronization is done, right

Re: C++0x Memory model and gcc

Michael Matz wrote: Hi, On Wed, 12 May 2010, Andrew MacLeod wrote: Well, you get the same thing you get today. Any synchronization done via a function call will tend to be correct since we never move shared memory operations across calls. Depending on your application, the types of

Re: C++0x Memory model and gcc

Michael Matz wrote: Hi, On Mon, 17 May 2010, Andrew MacLeod wrote: The guarantees you seem to want to establish by the proposed memory model. Possibly I misunderstood. I'm not 100% sure on the guarantees you want to establish. The proposed model seems to merge multiple con

alias time explosion

I'm not sure when this happened, but I noticed on the weekend that there has been an explosion in the time spent during the alias analysis phase. using cplusplus-grammer.ii, it use to compile on my machine in about 55 seconds, and its now up to about 150 seconds. A quick gprof indicated about 60%

Re: alias time explosion

On Mon, 2006-03-20 at 18:55 -0500, Andrew Pinski wrote: > On Mar 20, 2006, at 5:18 PM, Andrew MacLeod wrote: > > > I'm not sure when this happened, but I noticed on the weekend that > > there > > has been an explosion in the time spent during the alias analysis &

Re: alias time explosion

On Tue, 2006-03-21 at 10:10 +0100, Richard Guenther wrote: > On 3/21/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote: > > On Mon, 2006-03-20 at 18:55 -0500, Andrew Pinski wrote: > > > On Mar 20, 2006, at 5:18 PM, Andrew MacLeod wrote: > > > > It looks like so

Re: alias time explosion

On Tue, 2006-03-21 at 17:42 -0500, Daniel Berlin wrote: > On Tue, 2006-03-21 at 17:30 -0500, Andrew MacLeod wrote: > > On T > > I seem to have narrowed it down to this patch: > > > > http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00908.html > > > > That&#

Re: alias time explosion

On Wed, 2006-03-22 at 16:35 +0300, Andrey Belevantsev wrote: > Hi Daniel, > > I can't find the testcase attached to any message of the thread. Could > it be because of the message size? If so, please send the testcase both > to me and Maxim, one of us will look into it. > > Thanks, Andrey >

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

Re: RFC: gimple tuples data structures design

On Fri, 2006-06-09 at 19:32 -0400, Daniel Berlin wrote: > Aldy Hernandez wrote: > > Hi folks. > > > Also, one thing to throw on your todo list about gimple > temporaries/ssa_names is that a *lot* of places create one var per > ssa_name for no good reason. > > IE > foo = create_tmp_var (type); > f

Deprecating -f options?

Is there a standard process we use to eliminate -f options? or is it more on a per options basis. Im reworking out-of-ssa for 4.3 and there are a couple of options that were initially added which I prefer to no longer support. -ftree-combine-temps attempts to coalesce non-related ssa_names into a

Re: Deprecating -f options?

On Thu, 2006-06-15 at 19:06 +0100, Joern RENNECKE wrote: > In http://gcc.gnu.org/ml/gcc/2006-06/msg00549.html, you wrote: > > > -ftree-live-range-split splits live ranges on exit from ssa. This is > > on by default, and in fact it is more work to NOT split unrelated live > > ranges, and creates

Project RABLET

Last fall I produced the RABLE document which described the approach I thought should be taken to write a new register allocator for GCC. A new register allocator written from scratch is a very long term project (measured in years), and there is no guarantee after all that work that we'd end up w

Re: Project RABLET

On Fri, 2006-06-23 at 15:29 -0400, Robert Dewar wrote: > Andrew MacLeod wrote: > > > A new register allocator written from scratch is a very long term > > project (measured in years), and there is no guarantee after all that > > work that we'd end up with something wh

Re: Project RABLET

On Fri, 2006-06-23 at 23:08 -0400, Daniel Berlin wrote: > Ian Lance Taylor wrote: > > > > Here I think you are waving your hands a little too hard. RTL level > > CSE is significant for handling common expressions exposed by address > > calculations and by DImode (and larger) computations. On so

Re: Project RABLET

On Fri, 2006-06-23 at 15:07 -0700, Ian Lance Taylor wrote: > You omitted the RTL loop optimizer passes, which still do quite a bit > of work despite the tree-ssa loop passes. Also if-conversion and some > minor passes, though they are less relevant. Which brings up a good discussion. I presume t

Re: Project RABLET

On Sat, 2006-06-24 at 13:04 +0200, Steven Bosscher wrote: > On 6/24/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote: > > On Fri, 2006-06-23 at 15:07 -0700, Ian Lance Taylor wrote: > >= > > In general, I didnt mention anything that tends not to increase register > &

Re: Project RABLET

On Sat, 2006-06-24 at 12:36 -0400, Vladimir N. Makarov wrote: > Steven Bosscher wrote: > As for Andrew's proposal, my opinion is that all this > transformations are done too early and we need them to do again on > rtl sometime. > > o coalescing. CSE can create more moves but more important thi

Re: Project RABLET

On Sun, 2006-06-25 at 01:04 -0400, Vladimir N. Makarov wrote: > Andrew MacLeod wrote: > Having no information about the final register allocator decision, > the partial register pressure reducing through rematerialization is > not working in many cases. For example, making remateri

Register Allocator projects summary

Sorry Im late getting to this, but July was simply insane... There was a couple of discussions about register allocation at the GCC summit, including a dinner hosted by IBM and a BOF afterward. There may have been more activity after that, but I wasn't around so I don't know about it :-). Som

what to do with this testcase?

I've got the new out of ssa rewrite pretty much wrapped up, and in the process I have removed the -fno-tree-lrs option. This means we can no longer turn off live range splitting at the tree level. I mentioned I was planning to remove this a few months ago. Everything is fine, except for one te

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

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

<    1   2   3   >