Re: Time for GCC 5.0? (TIC)
DJ Delorie schrieb: Ian Lance Taylor writes: Also the fact that GCC is now written in C++ seems to me to be deserving of a bump to 5.0. I see no reason why an internal design change that has no user visible effects should have any impact on the version number. Changing the implementation language is not an internal change. GCC is a source project. Anyone who takes the sources and who wants to roll a distribution or just wants to compile GCC, will need a C++ compiler now. Thus, it's a major change for these "first-level" users. Johann Typically a major version bump is reserved for either massive new functionality or a break with backwards compatibility.
Re: a question for the c/c++ front end / standards people.
On Mon, Nov 5, 2012 at 10:13 PM, Kenneth Zadeck wrote: > On 11/05/2012 03:37 PM, Joseph S. Myers wrote: >> >> On Mon, 5 Nov 2012, Kenneth Zadeck wrote: >> >>> This switch to doing math within the precision causes many test cases to >>> behave differently. However, I want to know if differently means >>> "incorrectly" or "I have fixed problems that we have just decided to live >>> with". >> >> As far as I know, the TREE_OVERFLOW settings follow the most sensible >> interpretation of the C standard requirements (that any overflowing >> operation, with signed result type, whose operands are integer constant >> expressions, results in the overall containing expression, wherein that >> overflowing operation is evaluated in the abstract C semantics, not being >> an integer constant expression). >> >> Nothing in the testcases should care in the least about the "two HWI" >> internal implementation - from the front-end perspective, arithmetic >> according to the relevant precision is always right, and overflow should >> always be determined according to that precision. >> >>> The question is why is having a case label of 256 on a unsigned char >>> switch >>> legal? >> >> "The integer promotions are performed on the controlling expression. The >> constant expression in each case label is converted to the promoted type >> of the controlling expression." (C11, 6.8.4.2 paragraph 5). That is, in >> the semantics of C the switch is on an int value, not an unsigned char, >> and 256 is converted to int (which leaves it unchanged). If the value >> *is* modified by the conversion (say if it's 0x1ULL, converted to >> int), that's still valid C, as long as you don't get duplicate case >> labels. >> >> I don't know if the *implementation* of this bit of C does anything funny >> with constants outside the range of their types, but the specification is >> clear enough. >> > What i see is that the front end builds an int_cst with the type unsigned > char and a value 0x100. I consider this invalid gimple and i think the > iant's email does too. It seems like the front end is wrong to create this > and should have promoted this value to an int before it ever created gimple > for it. Note this would be invalid GENERIC at most (INTEGER_CST is a generic tree). I think if the TREE_OVERFLOW bit is not set on the constant then it is not a valid INTEGER_CST in GENERIC (and thus GIMPLE). Note that there are present cases that violate this inside the frontends which is why we still have the path in the tree.c INTEGER_CST construction routines that do not "canonicalize" the constants (by properly sign-/zero-extending the input value according to the type - where there are still callers that use the fallback integer_type type as they feed the constructors with a NULL_TREE type). Before converting any of the above to wide_int's the above mess should be sorted out (mostly by making the frontends use a different thing than INTEGER_CSTs in the affected places - formerly I'd say double_ints, with wide-ints around I'm not so sure). Richard. > kenny
Re: Unused components in sese.[hc]?
On Tue, Nov 20, 2012 at 2:45 AM, Lawrence Crowl wrote: > I believe the following components in sese.[hc] are completely unused. > > phis -- functions declared extern in sese.h but never defined > > extern void insert_loop_close_phis (htab_t, loop_p); > extern void insert_guard_phis (basic_block, edge, edge, htab_t, htab_t); > > ivtype_map -- the hash table infrastructure is defined but never used. > > (In particular, the hash function and equality functions are defined > but never used, and so no instances of the hash table can exist.) > > static inline ivtype_map_elt > new_ivtype_map_elt (const char *cloog_iv, tree type) > static void debug_ivtype_elt (ivtype_map_elt elt); > static int debug_ivtype_map_1 (void **slot, void *s ATTRIBUTE_UNUSED); > DEBUG_FUNCTION void debug_ivtype_map (htab_t map); > hashval_t ivtype_map_elt_info (const void *elt); > int eq_ivtype_map_elts (const void *e1, const void *e2); > > I have successfully built and tested with these components #if'd out. > Should I remove them? Yes, counts as obvious. Thanks, Richard. > -- > Lawrence Crowl
Re: Unused DSE Functions
On Tue, Nov 20, 2012 at 11:20 AM, Steven Bosscher wrote: > On Mon, 19 Nov 2012 18:31:27 -0800, Lawrence Crowl wrote: > >> Richi, ping? > > Just guessing... isn't he simply out on Honeymoon? > > Those functions were introduced to handle alias sets for spill slots > better, but IIRC this never worked properly. The whole path through > dse_step2_spill is dead. > > The code was introduced on the DF-branch with this patch: > http://gcc.gnu.org/ml/gcc-patches/2007-04/msg00216.html. Its purpose > was to make aliasing transparent for spill slots created by a never > posted pre-spiller pass (i.e. spill before register allocation to > reduce register pressure). The idea was that pre-spilled pseudos could > be promoted back to registers, and the associated stack slots > eliminated, if register pressure turned out to be low enough that the > pre-spilling was unnecessary. > > But even on the DF-branch before the merge) this code never worked > properly and the whole approach was abandoned, see ChangeLog.dataflow: > > * dse.c (replace_inc_dec, delete_dead_store_insn, scan_insn, > dse_record_singleton_alias_set, dse_confluence_0, > dse_confluence_n, step4, step5_nospill, step5_spill, > rest_of_handle_dse, pass_rtl_dse1, pass_rtl_dse2): Removed code > to allow dse to run on trunk in front of flow.c > (problem): Removed. > > > I would go ahead and eliminate this clear_alias_sets and all related > code, and commit that patch as obvious (or after Diego has given it > his blessing). Counts as obvious. Richard. > In fact, the complete pass_rtl_dse2 pass may be useless now, perhaps > that's something you could look into also, while at it? > > Thanks for all the C++ and other compiler long-term structural improvements!!! > > Ciao! > Steven
Re: Hash table iterators.
On Fri, Nov 23, 2012 at 5:15 PM, Andrew MacLeod wrote: > 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) Ignore the problem and leave all such tables as htab_t. >> >> (2) Write new hash_table iteration functions to match the form of >> the existing GCC macro/function approach. >> >> (3) Write new hash_table iteration functions to match the form used >> by the C++ standard. This approach would entail modifying the loops. >> >> Diego and I have a preference for (3). What do you prefer? > > > I don't like (1) for sure. > > Before deciding a preference between (2) and (3), what are the actual > differences? ie, is (2) doing something practical that (3) has to bend > over for, or is (3)'s format better but wasn't practical before? is (2) > otherwise useful going forward? I prefer (2) with internally using (3). I have such patch for the loop iterator around (that takes care of disposing of the iterator via a destructor - so no longer a need for the fancy BREAK_FROM_XXX stuff). Richard. > Andrew >
Re: Unifying the GCC Debugging Interface
On Thu, Nov 15, 2012 at 2:12 AM, Lawrence Crowl wrote: > Diego and I seek your comments on the following (loose) proposal. > > > It is sometimes hard to remember which printing function is used > for debugging a type, or even which type you have. > > We propose to rely on overloading to unify the interface to a small > set of function names. Every major data type should have associated > debug/dump functionality. We will unify the current *_dump/*_debug > functions under the same common overloaded name. Just to add another case which seems to be not covered in the thread. When dumping from inside a gdb session in many cases I cut&paste addresses literally. For overloading to work I'd need to write casts in front of the inferior call argument. That sounds ugly - so at least keep the old interfaces as well. Or rather for debugging purposes provide python helpers rather than new inferior overloads. Richard. > We intend to only apply this approach to functions that take the > type to display as an argument, and that are routinely used in > debugging. > > 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 pretty-printer functions in their > implementation. > > dump_raw > > This function overload set provides the raw oriented dump, > e.g. a tuple. > > dump_verbose > > This function overload set provides the extra details dump. > > > All of these functions come in two forms. > > function (FILE *, item_to_dump, formatting) > function (item_to_dump, formatting) > > If the FILE* is not specified, the output is to stderr. The > formatting argument is optional, with a default suitable to the kind > of item to dump. > > > We should remove tree-browser.c. It is not used at all and it is > likely broken. > > -- > Lawrence Crowl
Re: Could we start accepting rich-text postings on the gcc lists?
On Fri, Nov 23, 2012 at 11:03 PM, Diego Novillo wrote: > On Fri, Nov 23, 2012 at 5:00 PM, Richard Kenner > wrote: >>> It's just that an increasing number of mail agents are configured by >>> default to send rich-text. >> >> And people who know enough about computing to work on compilers don't know >> how to change the default on their MUA? That seems like a poor reason to >> make such a change. > > I already addressed this upthread. We are starting to talk in > circles. The point is not to add unnecessary irritation. We don't add irritation - it's already there. Btw, maybe time to bug your friends at google that an option to turn off html postings for the GMail android app would be nice ;) That said, filtering any non text/plain mail into spam keeps me off most spam. Thus be warned when you try to get patches in non text/plain sent to me ;) I strongly prefer to keep the restriction in place. Richard. > > Diego.
Re: Could we start accepting rich-text postings on the gcc lists?
On Sat, Nov 24, 2012 at 6:47 PM, Robert Dewar wrote: > >> 2) The fact that Android refuses to provide a non-HTML e-mail capability >> is ridiculous but does not seem to me to be a reason for us to change >> our policy. > > > Surely there are altenrative email client for Android that have plain > text capability??? Of course, I use one. Richard.
Re: Could we start accepting rich-text postings on the gcc lists?
On Sat, Nov 24, 2012 at 7:08 PM, Robert Dewar wrote: > On 11/24/2012 12:59 PM, Daniel Berlin wrote: >> >> On Sat, Nov 24, 2012 at 12:47 PM, Robert Dewar wrote: >>> >>> 2) The fact that Android refuses to provide a non-HTML e-mail capability is ridiculous but does not seem to me to be a reason for us to change our policy. >>> >>> >>> >>> Surely there are altenrative email client for Android that have plain >>> text capability??? >>> >> >> Yes, we should expect users to change, instead of keeping up with users. > > > Well my experience with HTML-burdened mail is awful. From people who set > ludicrous font choices, to bad color choices, to inappropriate use of > multiple fonts, to inappropriate use of colors, it's a mess. > > I think it is perfectly reasonable to expect serious developers to > send text messages in text form. BTW, our experience at AdaCore, where > we get lots of email from lots of customers, users, hobbyists, and > students, sending email from all sorts > of programs, is that yes, occasionally they send us HTML burdened > email, but almost always when we ask them to adjust their mailers to > send text, they can do so without problems. Hey - customers even send mails with only a pdf attachment that contains a scanned sheet of paper with hand-writing ... Richard.
Re: Time for GCC 5.0? (TIC)
On Tue, Nov 6, 2012 at 7:06 AM, Jeff Law wrote: > On 11/05/2012 07:43 PM, DJ Delorie wrote: >> >> >> Ian Lance Taylor writes: >>> >>> Also the fact that GCC is now written in C++ seems to me to be >>> deserving of a bump to 5.0. >> >> >> I see no reason why an internal design change that has no user visible >> effects should have any impact on the version number. >> >> Typically a major version bump is reserved for either massive new >> functionality or a break with backwards compatibility. > > I tend to agree that major version number bumps ought to be tied to major > user-visible changes. > > I think dropping reload would quality, particularly if there are other major > user visible changes going on. For example, significant improvements in > modularity allowing for easier plugin development, major improvements in > static & dynamic analysis capabilities, etc. I'd rather make version numbers "simpler" by dropping one sub-part. Thus 4.8.0 would become 5.0 (and branch releases 5.1, 5.2, etc.) and 4.9.0 would then be 6.0. Marketing loves high numbers after all! Richard. > jeff
Re: RFC - Alternatives to gengtype
On Fri, Nov 16, 2012 at 1:59 AM, Diego Novillo wrote:
> As we continue adding new C++ features in the compiler, gengtype
> is becoming an increasing source of pain. In this proposal, we
> want to explore different approaches to GC that we could
> implement.
>
> 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 these directions:
>
> Diego:
> Get rid of GC completely. Move into pool allocation.
> If we continue to use GC, then either use boehm-gc or
> continue use the precise allocator, but with user
> generated marking.
>
> Lawrence:
> Get rid of GC completely. Move into pool allocation.
> If we continue to use GC, either move to user-generated
> marking or implement the GTY attributes in cc1plus (read
> below). For PCH, used a fixed address where all the
> PCH-able data would go, as this would represent less work
> than implementing streamable types.
>
>
>
> Gengtype is a poor C parser. It is a long way from handling all
> of the C++ constructs what are used by the C++ standard library.
> We have a few potential solutions. Solution: Stick with Gengtype
>
>
> As gengtype currently does not handle what we need, something
> must change.
I'd say the most pragmatic solution is to stick with gengtype but
make it more dependent on annotations (thus, explicit). That is,
instead of trying to parse a struct declaration annotate respective
things explicitely thus,
class X GTY(()) : public Y GTY((base)) {
Foo *x GTY(());
Bar y;
};
thus in the above example instead of GTY((skip)) on y explicitely
mark 'x' as to be handled by gengtype.
I suppose I agree that garbage collection is not technically
required for writing a compiler, but getting rid of GC in GCC
entirely will be a hard and error-prone task (even if you
factor out PCH which is an entirely different mess).
Richard.
>
> === Approach: Limit the Language Used
>
> We could avoid the problem by limiting the language we use to
> near that which gengtype currently understands. This approach
> has significant consequences. It will make the standard library
> incompatible with GTY. It will prevent the use of common idioms,
> such as iterators, within GTY types. These limitations are
> significant and not desirable. Approach: Upgrade Gengtype
>
>
> Full C++ support would essentially require building a new C++
> parser.
>
>
> === Approach: Both Limit and Upgrade
>
> We can try upgrading gengtype to handle a more extensive subset
> of C++, without trying to handle the full language. See Thoughts
> on Gengtype and Single Inheritance. Taking this approach would
> likely mean we would be unable to use the C++ standard library
> within GCC.
>
>
> === Approach: Move GTY to cc1plus.
>
> Instead of a separate weak parser, we would make cc1plus
> understand GTY attributes. The compiler would emit IL in the
> object files instead of generating source.
>
> This solution would require a first boot stage that did not
> support PCH, because we cannot rely on the seed compiler
> supporting GTY. We would probably need to use the Boehm
> collector during the first stage as well.
>
> Because the first stage would be fundamentally different from the
> second stage, we may need to add an additional pass for correct
> object file comparisons.
>
>
> === Approach: Do GTY manually
>
> In this approach we would be converting GTY from a declarative
> form into a procedural one using the C++ type system and
> manually-implemented structure field handlers. At the highest
> level, this roughly means that all the structures using GTY(())
> markers will start using GTY((user)).
>
> The marking code dealing with the semantics of the marked data
> structure is co-located with the data structure. When GC
> problems occur, this simplifies debugging. The user is no longer
> faced with a mass of auto generated code that is unfamiliar and
> hard to trace. The code to implement is straightforward. For
> every pointer field in the given instance pointer, a single
> "mark" function needs to be called.
>
> Common facilities to mark arrays will be provided via a base GC
> class. No generated header files to #include at the end of the
> source file. No new dependencies to add to the Makefile. No need
> to parse C++.
>
> The problem with this approach is that the declarative approach
> puts the field additions and the GTY annotations in the same
> place, as opposed to in separate code. While it is possible to
> use standard library containers with GC pointers in them, we
> would not be able to write these containers to PCH images.
>
>
> === Approach: Get rid of GTY
>
> This approach engenders more choices. The pre-compiled header
> implementation uses gengtype, so this approach is not viable
> unless we h
Re: RFC - Alternatives to gengtype
On Sun, Nov 25, 2012 at 10:09 AM, Richard Biener wrote: > I'd say the most pragmatic solution is to stick with gengtype but > make it more dependent on annotations (thus, explicit). That is, Yes. That is the direction in which I've been leaning towards. My preference is to transitionally move to manual markers (http://gcc.gnu.org/wiki/cxx-conversion/gc-alternatives#Do_GC_marking_manually) and over time transition to memory pool management. > I suppose I agree that garbage collection is not technically > required for writing a compiler, but getting rid of GC in GCC > entirely will be a hard and error-prone task (even if you > factor out PCH which is an entirely different mess). Agreed. As far as PCH is concerned, my preferred long term approach is to move to streamable types. We have an almost working implementation in the PPH branch and we already have a streaming framework in LTO. Diego.
Re: Could we start accepting rich-text postings on the gcc lists?
On Sun, Nov 25, 2012 at 8:54 AM, Richard Biener wrote: > That said, filtering any non text/plain mail into spam keeps me off most > spam. Thus be warned when you try to get patches in non text/plain > sent to me ;) It would be OK for me if the mailing list software we use stripped the text/html part of messages. That would solve the majority of the issues I see, and I understand that this is doable. My main concern is losing valid content because of this limitation. Diego.
Re: Reorg a reorg.c comment
On 24-Nov-12, at 9:19 PM, Steven Bosscher wrote: +;; This machine description is inspired by sparc.md and (to a lesser +;; extend) mips.md. Change "extend" to "extent". Don't need parentheses. + +;; Possible improvements, if anyone is still interested in working on +;; improving this machine description in 2012: Please remove the "if anyone ..." part. +;; +;; * With PA2.0, most computational instructions can conditionally nullify +;; the execution of the following instruction. Nullification is performed Add statement to effect that nullification is a very efficient for it does not cause the instruction pipeline to stall. +;; conditionally based on the outcome of a test specified in the opcode. +;; The test result is stored in PSW[N] and can only be used to nullify the +;; instruction following immediately after the test. For example: +;; +;; ldi 10,%r26 ldi 10,%r26 +;; ldi 5,%r25 ldi 5,%r25 +;; sub,< %r26,%r25,%r28 sub,> %r26,%r25,%r28 +;; sub %r28,%r25,%r28sub %r28,%r25,%r28 +;; ; %r28 == 0 ; %r28 == 5 Find the parallel layout somewhat confusing. Maybe we just need one. +;; +;; This could be tricky to implement because the result of the test has +;; to be propagated one instruction forward, which, in the worst case, +;; would involve (1) adding a fake register for PSW[N]; (2) adding the +;; variants of the computational instructions that set or consume this +;; fake register. The cond_exec infrastructure is probably not helpful +;; for this. +;; Another improvement might be to implement the static branch prediction hints for conditional branches (Section I-3 in PA-RISC 2.0 Architecture). ;;- See file "rtl.def" for documentation on define_insn, match_*, et. al. Dave -- John David Anglin dave.ang...@bell.net
Re: RFC - Alternatives to gengtype
On Sun, Nov 25, 2012 at 4:21 PM, Diego Novillo wrote: > On Sun, Nov 25, 2012 at 10:09 AM, Richard Biener > wrote: > >> I'd say the most pragmatic solution is to stick with gengtype but >> make it more dependent on annotations (thus, explicit). That is, > > Yes. That is the direction in which I've been leaning towards. My > preference is to transitionally move to manual markers > (http://gcc.gnu.org/wiki/cxx-conversion/gc-alternatives#Do_GC_marking_manually) > and over time transition to memory pool management. Note that the most GCed thing is a 'tree' and the solution is not to move trees to memory pools but to use less trees in the first place! If trees were not GCed GIMPLE would not be I bet, and thus if GIMPLE would not refer to trees there would be no reason to GC it! Improving things wrt tree usage also means to isolate C/C++ frontend IL from the middle-end. I once proposed to cp tree.[ch] and at gimplification time re-allocate and copy from the frontend tree "kind" to the gimple tree "kind". Of course our FE / middle-end separation enemy (debug info) makes this not so viable at the moment. >> I suppose I agree that garbage collection is not technically >> required for writing a compiler, but getting rid of GC in GCC >> entirely will be a hard and error-prone task (even if you >> factor out PCH which is an entirely different mess). > > Agreed. As far as PCH is concerned, my preferred long term approach > is to move to streamable types. We have an almost working > implementation in the PPH branch and we already have a streaming > framework in LTO. Of course that's not all we preserve in PCH ... (look for "interesting" global data marked as GC root just for the sake of PCH). Richard. > > Diego.
Sumbitting 'patches' that add lots of files (Was: Re: Could we start accepting rich-text postings on the gcc lists?)
Quoting Richard Biener : That said, filtering any non text/plain mail into spam keeps me off most spam. Thus be warned when you try to get patches in non text/plain sent to me ;) Should I uuencode new port submissions? Expressing addition of several score files as a 'patch' is not always an option. Uncompressed, the Synopsys Designware ARC port weighs in at more than a megabyte.
Re: Sumbitting 'patches' that add lots of files (Was: Re: Could we start accepting rich-text postings on the gcc lists?)
On Sun, Nov 25, 2012 at 4:47 PM, Joern Rennecke wrote: > Quoting Richard Biener : > >> That said, filtering any non text/plain mail into spam keeps me off most >> spam. Thus be warned when you try to get patches in non text/plain >> sent to me ;) > > > Should I uuencode new port submissions? > Expressing addition of several score files as a 'patch' is not always an > option. Uncompressed, the Synopsys Designware ARC port weighs in at more > than a megabyte. I don't know - I usually don't review new port submissions. I think for new files attaching the new file itself instead of a patch producing it is common practice (though doesn't save much space). One file per mail is then convenient for review anyway. Richard.
Re: Sumbitting 'patches' that add lots of files (Was: Re: Could we start accepting rich-text postings on the gcc lists?)
Quoting Richard Biener : (though doesn't save much space). One file per mail is then convenient for review anyway. That would be 84 mails then just for the added files. And if the testsuite was bigger, that figure would only get larger. Is that really the preferred way to do this?
Re: Sumbitting 'patches' that add lots of files (Was: Re: Could we start accepting rich-text postings on the gcc lists?)
On Sun, Nov 25, 2012 at 5:03 PM, Joern Rennecke wrote: > Quoting Richard Biener : > >> (though doesn't save much space). One file per mail is then convenient >> for >> review anyway. > > > That would be 84 mails then just for the added files. > And if the testsuite was bigger, that figure would only get larger. > Is that really the preferred way to do this? Apply common sense - the above applies to large files only of course. Richard.
Re: Could we start accepting rich-text postings on the gcc lists?
On Sun, Nov 25, 2012 at 10:28:39AM -0500, Diego Novillo wrote: > My main concern is losing valid content because of this limitation. > Your only concern is to send email with your android gmail. You also need to learn to trim the CC line
Re: RFC - Alternatives to gengtype
On Sun, Nov 25, 2012 at 7:45 AM, Richard Biener wrote: > On Sun, Nov 25, 2012 at 4:21 PM, Diego Novillo wrote: >> On Sun, Nov 25, 2012 at 10:09 AM, Richard Biener >> wrote: >> >>> I'd say the most pragmatic solution is to stick with gengtype but >>> make it more dependent on annotations (thus, explicit). That is, >> >> Yes. That is the direction in which I've been leaning towards. My >> preference is to transitionally move to manual markers >> (http://gcc.gnu.org/wiki/cxx-conversion/gc-alternatives#Do_GC_marking_manually) >> and over time transition to memory pool management. > > Note that the most GCed thing is a 'tree' and the solution is not > to move trees to memory pools but to use less trees in the first place! > If trees were not GCed GIMPLE would not be I bet, and thus if GIMPLE > would not refer to trees there would be no reason to GC it! > > Improving things wrt tree usage also means to isolate C/C++ frontend > IL from the middle-end. I once proposed to cp tree.[ch] and at gimplification > time re-allocate and copy from the frontend tree "kind" to the gimple > tree "kind". Isolation can help but if FE creates too many unused trees and leave them for ME to clean up, I wonder how effective it wil be -- It is not uncommon to see C++ FE generate > 200k functions (by looking at funcdef_no value) from a moderately sized source. David > Of course our FE / middle-end separation enemy (debug info) makes this not > so viable at the moment. > >>> I suppose I agree that garbage collection is not technically >>> required for writing a compiler, but getting rid of GC in GCC >>> entirely will be a hard and error-prone task (even if you >>> factor out PCH which is an entirely different mess). >> >> Agreed. As far as PCH is concerned, my preferred long term approach >> is to move to streamable types. We have an almost working >> implementation in the PPH branch and we already have a streaming >> framework in LTO. > > Of course that's not all we preserve in PCH ... (look for "interesting" global > data marked as GC root just for the sake of PCH). > > Richard. > >> >> Diego.
Re: Could we start accepting rich-text postings on the gcc lists?
On Sat, Nov 24, 2012 at 11:13 AM, Ian Lance Taylor wrote: > 2) The fact that Android refuses to provide a non-HTML e-mail capability > is ridiculous but does not seem to me to be a reason for us to change > our policy. Amen. Rich texts in technical conversations where people people use various mail agents and mail readers/senders is a fracking mess. That the designers at infinite loop and amphitheatre parkway won't let their devices and software send plain text emails is is the problem, not the solution. It is not a software progress in the 21st century; it is a regression. -- Gaby
Re: Unifying the GCC Debugging Interface
On Sun, Nov 25, 2012 at 7:45 AM, Richard Biener wrote: > Just to add another case which seems to be not covered in the thread. > When dumping from inside a gdb session in many cases I cut&paste > addresses literally. For overloading to work I'd need to write casts > in front of the inferior call argument. That sounds ugly - so at least > keep the old interfaces as well. Or rather for debugging purposes > provide python helpers rather than new inferior overloads. this means that we need an improvement from GDB. This is not useful only to the small GCC community. It is very useful to the wider GDB/C++ user community. -- Gaby
Re: Could we start accepting rich-text postings on the gcc lists?
On Sun, Nov 25, 2012 at 7:28 AM, Ruben Safir wrote: > On Sun, Nov 25, 2012 at 10:28:39AM -0500, Diego Novillo wrote: >> My main concern is losing valid content because of this limitation. >> > > Your only concern is to send email with your android gmail. > > You also need to learn to trim the CC line At what point does obvious trolling get someone banned on the gcc lists? This user has been nothing but purely abusive: http://gcc.gnu.org/ml/gcc/2012-11/msg00432.html http://gcc.gnu.org/ml/gcc/2012-11/msg00411.html http://gcc.gnu.org/ml/gcc/2012-11/msg00406.html http://gcc.gnu.org/ml/gcc/2012-11/msg00405.html http://gcc.gnu.org/ml/gcc/2012-11/msg00383.html etc. throughout this thread.
gcc-4.8-20121125 is now available
Snapshot gcc-4.8-20121125 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20121125/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 193798 You'll find: gcc-4.8-20121125.tar.bz2 Complete GCC MD5=ed95f7a77520aa77391d24ceab6dae51 SHA1=552667e3bcb54fee1ab50d79c726ef014c1033fc Diffs from 4.8-20121118 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Dependences for call-preserved regs on exposed pipeline target?
I'm working onaport to a VLIW DSP with anexposed pipeline (i.e., no interlocks). Some operations OPhave as much as 2-cycle latency on values of the call-preserved regs CPR. E.g., if the callee's epiloguerestores a CPR in the delay slot of the return instruction, then any OP with that CPR as input needs to schedule 2 clocks after the call in order to get the expected value. If OP schedules immediately after the call, then it will getthevalue the callee's value prior to the epilogue restore. The easy, low-performance way to solve the problem is to schedule epilogues to restore CPRs before the return and its delay slot. The harder, usually better performing way is to manage dependences in the caller so that uses of CPRs for OPs that require extra cycles schedule at sufficient distance from the call. How shall I introduce these dependences for only the scheduler? As an experiment, I added CLOBBERs to the call insn, which createdtrue depencences between the call and downstream instructions that read the CPRs, but had the undesired effect of perturbing dataflowacross calls. I'm thinking sched-depsneedsnew code for targets with TARGET_SCHED_EXPOSED_PIPELINE to add dependencesfor call-insn producers and CPR-user consumers. Comments? Greg
Re: Dependences for call-preserved regs on exposed pipeline target?
On 26/11/2012, at 1:28 PM, Greg McGary wrote: > I'm working onaport to a VLIW DSP with anexposed pipeline (i.e., no > interlocks). Some operations OPhave as much as 2-cycle latency on values > of the call-preserved regs CPR. E.g., if the callee's epiloguerestores a > CPR in the delay slot of the return instruction, then any OP with that CPR > as input needs to schedule 2 clocks after the call in order to get the > expected value. If OP schedules immediately after the call, then it will > getthevalue the callee's value prior to the epilogue restore. > > The easy, low-performance way to solve the problem is to schedule > epilogues to restore CPRs before the return and its delay slot. The > harder, usually better performing way is to manage dependences in the > caller so that uses of CPRs for OPs that require extra cycles schedule > at sufficient distance from the call. > > How shall I introduce these dependences for only the scheduler? As an > experiment, I added CLOBBERs to the call insn, which createdtrue > depencences between the call and downstream instructions that read the > CPRs, but had the undesired effect of perturbing dataflowacross calls. > I'm thinking sched-depsneedsnew code for targets with > TARGET_SCHED_EXPOSED_PIPELINE to add dependencesfor call-insn producers > and CPR-user consumers. You essentially need a fix-up pass just before the end of compilation (machine-dependent reorg, if memory serves me right) to space instructions consuming values from CPRs from the CALL_INSNS that set those CPRs. I.e., for the 99% of compilation you don't care about this restriction, it's only the very last VLIW bundling and delay slot passes that need to know about it. You, probably, want to make the 2nd scheduler pass run as machine-dependent reorg (as ia64 does) and enable an additional constraint (through scheduling bypass) for the scheduler DFA to space CALL_INSNs from their consumers for at least for 2 cycles. One challenge here is that scheduler operates on basic blocks, and it is difficult to track dependencies across basic block boundaries. To workaround basic-block scope of the scheduler you could emit dummy instructions at the beginning of basic blocks that have predecessors that end with CALL_INSNs. These dummy instructions would set the appropriate registers (probably just assign the register to itself), and you will have a bypass (see define_bypass) between these dummy instructions and consumers to guarantee the 2-cycle delay. -- Maxim Kuvyrkov CodeSourcery / Mentor Graphics
