Re: RFC - Alternatives to gengtype
On 23/11/2012, Basile Starynkevitch wrote: > On Thu, Nov 22, 2012 at 09:29:43PM +0100, Florian Weimer wrote: >> On 11/18/2012 07:06 PM, NightStrike wrote: >> >> >What's wrong with std::shared_ptr? >> >> The pointer needs two words, and the per-object overhead for the >> reference counts etc. is four words, if I'm counting correctly. >> >> (Other forms of reference counting have less overhead, of course, >> but you were asking about std::shared_ptr.) > > > Actually, this observation may favor a real garbage collector. Marking GC as > simple as ggc+gengtype usually have one (or a few) mark bits, so can consume > only a few bits (or perhaps a byte in some mark array) per object. Copying > GC could avoid consuming any more storage per object. Of course useless > object may stay in memory for a while -until the GC deletes them or reuse > their memory- The research shows significantly higher memory usage when relying on GC in large systems. > but that observation is also true with traditional C++ "GC" > techniques like shared_ptr An object may be freed later than what > should be possible. Only if the code has a bug. Destructors are predictable, immediate and deterministic. > And some GC techniques are quite friendly with L1 or L2 caches on the > processor chip. And so are some reference counting techniques with intrusive counts, or using std::make_shared(), so the object and refcount are adjacent in memory.
Re: RFC - Alternatives to gengtype
On 11/23/2012 10:45 AM, Jonathan Wakely wrote: Actually, this observation may favor a real garbage collector. Marking GC as simple as ggc+gengtype usually have one (or a few) mark bits, so can consume only a few bits (or perhaps a byte in some mark array) per object. Copying GC could avoid consuming any more storage per object. Of course useless object may stay in memory for a while -until the GC deletes them or reuse their memory- The research shows significantly higher memory usage when relying on GC in large systems. I believe the research treats reference counting as a form of GC. 8-) It would be an interesting project to instrument GCC to obtain the precise point when any object becomes unreachable, synthesize a sequence of malloc()/free() calls from that, and run it against a traditional malloc implementation. I believe this is how some of the early research into GC memory overhead was done (at much, much smaller heap sizes for sure). -- Florian Weimer / Red Hat Product Security Team
Re: RFC - Alternatives to gengtype
Quoting Florian Weimer : On 11/18/2012 07:06 PM, NightStrike wrote: What's wrong with std::shared_ptr? The pointer needs two words, and the per-object overhead for the reference counts etc. is four words, if I'm counting correctly. (Other forms of reference counting have less overhead, of course, but you were asking about std::shared_ptr.) How about we require that in general, use of raw pointers to GC-able objects are banned, and instead we require the use of a class (maybe obtained by template?) that is a pointer to the GC-able object, with a special copy-constructor. The copy-constructor marks the pointed - to object as live. GC traverses an object by performing a dummy copy and destroying it. If we need more than one operation, or mark-things-live when copying during normal operation causes too much overhead, we could select operations to be performed by the copy constructor by adjusting some global state (need not literally be a global variable - it might be a static member variable in some class).
Re: RFC - Alternatives to gengtype
Quoting Joern Rennecke : P.S.: If we need more than one operation, or mark-things-live when copying during normal operation causes too much overhead, we could select operations to be performed by the copy constructor by adjusting some global state (need not literally be a global variable - it might be a static member variable in some class). This can also make the mark-operation cheaper, as we could make it just do the marking. And, to tackle GC roots, we could have another templated class to wrap pointers to GC-able pointers that, in addition, has a constructor that registers the address the pointer is going to be stored in. if the previous contents are zero. We'll have to have a check to avoid creating duplicates if a GC root is initialized more than once. Thus, we can get completely get rid of gengtype - the special GC semantics will be expressed in C++ by the types used. The gengtype code might get re-used for a final time to help find and rewrite all the GTY constructs we got in our current code base.
Re: RFC - Alternatives to gengtype
On 11/23/2012 11:17 AM, Joern Rennecke wrote: How about we require that in general, use of raw pointers to GC-able objects are banned, and instead we require the use of a class (maybe obtained by template?) that is a pointer to the GC-able object, with a special copy-constructor. The copy-constructor marks the pointed - to object as live. GC traverses an object by performing a dummy copy and destroying it. This will require *a* *lot* of stack space for the recursion, and cycle detection probably has to rely on undefined behavior. I'm pretty sure there are other drawbacks as well. The beauty of Cheney's scheme is that it uses the from space as a work queue, and I don't see how we can do something similar in mostly portable C++. (That being said, we could probably use Boehm GC for the bootstrap compiler and a different collector after bootstrapping.) -- Florian Weimer / Red Hat Product Security Team
Limit reload base register class of define_memory_constraint
Hello! x86_64 has particularly interesting address mode limitations when "high" 8bit registers (%ah, %dh, %ch and %bh) are handled. Following examples are all valid: movb (%rdx), %ah addb (%rdx), %ah but when extended register is part of a memory address, insn requires REX prefix and assembling following examples movb (%r8), %ah breaks with Error: can't encode register '%ah' in an instruction requiring REX prefix. Due to this limitation, all binary operations involving high 8bit registers are limited to non-memory operands on x86_64, also leading to many differences between x86_32 and x86_64 insn descriptions (i.e. addqi_ext_1). A possible solution would be to use define_memory_constraint that forces operand to BASE_REG_CLASS, which on x86_64 unfortunately also includes REX registers. So, we currently have no way to limit reload register to LEGACY_REG_CLASS that would elegantly solve this problem. I have a patch that unifies all *_ext patterns in the i386.md file, and the fixup would trigger only in one file in libgo library. Is there some other way to limit memory address operands to LEGACY_REG_CLASS for certain memory constraints? Uros.
Re: Hash table iterators.
Hi, On Thu, 22 Nov 2012, 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 prefer (2). Ciao, Michael.
Re: Hash table iterators.
On 11/22/2012 01:18 PM, Lawrence Crowl wrote: I have found that tree-flow.h implements iteration over htab_t, while there is no current facility to do that with hash_table. Unfortunately, the specific form does not match the standard C++ approach to iterators. We have several choices. (1) 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? Andrew
Re: Could we start accepting rich-text postings on the gcc lists?
On Fri, Nov 23, 2012 at 11:53 AM, Diego Novillo wrote: > In this day and age of rich-text capable mailers, restricting postings > to be text-only seems quaint and antiquated. Are there any hard > requirements that force us to only accept plain text messages? I think it is a bad idea to accept non plain text messages (except for attachments). > > I'm seeing two developments because of this: > > 1. Frustration on the part of developers who get their posts rejected. > This happens to me when I'm on my phone, the phone mailer does not > even offer the option of sending text-only mail (I filed a bug about > it ~3 years ago). This is mildly annoying, but annoying nonetheless. > Recently, I had to teach a couple of new developers how to set their > mailer to send plaintext messages (I felt like a dinosaur). This frustration is going to be on other people side if we start allowing rich-text emails. Plain text is still more readable than most richtext for the plain reason as the formatting is gone. Formatting in rich-text emails make most richtext emails hard to read. People like to reply in a different color and that just makes it hard to figure out who is replying to who. If you feel like a dinosaur for helping developers to set their mailers to send plaintext messages, then there is a problem with how people are learning about email and the internet and why richtext is bad news. > > 2. Posts disappear and are not re-posted in text form. If the message > was CC'd to another maintainer, then the original posters does not > care that their message got rejected. They got to their intended > recipient, who typically responds, leaving broken threads on the > mailing list. For example, check the thread index for > http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00011.html. You'll > notice that there are no messages from Dmitry Vyukov, despite him > sending no less than 6 replies to that thread. It is up to the contributor to read the requirements before submitting patches and plain text emails are a documented requirement right now. Bad formatted emails are less likely to happen with plain text. Allowing rich text will cause people to have worse formatted email. > > I'm more concerned about #2. Today's software is more than capable of > dealing with rich text. Is it really that important for us to stick > to this requirement? > > If the reason is "because we like it this way", please consider the > impact on contributors and would-be contributors. Why add one more > aggravation to the already long list? It is not just because we like it this way, rich text (or in some cases html) can cause security holes. Formatting issues are worse with rich text emails. Also once you start allowing richtext emails, you will find that people start depending on rich text to format tables and other things and the plain text part will not be readable. Thanks, Andrew Pinski PS I think this really should go to the gcc@ list rather than overseers list because even though overseers is in control of the machines, the decision about allowing rich text is a gcc policy rather than a machine policy.
Re: Could we start accepting rich-text postings on the gcc lists?
On Fri, Nov 23, 2012 at 12:12:17PM -0800, Andrew Pinski wrote: > On Fri, Nov 23, 2012 at 11:53 AM, Diego Novillo wrote: > > In this day and age of rich-text capable mailers, restricting postings > > to be text-only seems quaint and antiquated. Are there any hard > > requirements that force us to only accept plain text messages? incorrect accessment
Re: Could we start accepting rich-text postings on the gcc lists?
On Fri, Nov 23, 2012 at 3:14 PM, Ruben Safir wrote: > On Fri, Nov 23, 2012 at 12:12:17PM -0800, Andrew Pinski wrote: >> On Fri, Nov 23, 2012 at 11:53 AM, Diego Novillo wrote: >> > In this day and age of rich-text capable mailers, restricting postings >> > to be text-only seems quaint and antiquated. Are there any hard >> > requirements that force us to only accept plain text messages? > > > incorrect accessment I can't parse this.
Re: Could we start accepting rich-text postings on the gcc lists?
On Fri, Nov 23, 2012 at 3:12 PM, Andrew Pinski wrote: > On Fri, Nov 23, 2012 at 11:53 AM, Diego Novillo wrote: >> In this day and age of rich-text capable mailers, restricting postings >> to be text-only seems quaint and antiquated. Are there any hard >> requirements that force us to only accept plain text messages? > > I think it is a bad idea to accept non plain text messages (except for > attachments). > >> >> I'm seeing two developments because of this: >> >> 1. Frustration on the part of developers who get their posts rejected. >> This happens to me when I'm on my phone, the phone mailer does not >> even offer the option of sending text-only mail (I filed a bug about >> it ~3 years ago). This is mildly annoying, but annoying nonetheless. >> Recently, I had to teach a couple of new developers how to set their >> mailer to send plaintext messages (I felt like a dinosaur). > > This frustration is going to be on other people side if we start > allowing rich-text emails. Plain text is still more readable than > most richtext for the plain reason as the formatting is gone. What mailers are you thinking of? All the ones I've used in the last decade or so have been perfectly capable of dealing with rich-text. > If you feel like a dinosaur for helping developers to set their > mailers to send plaintext messages, then there is a problem with how > people are learning about email and the internet and why richtext is > bad news. I'm trying to adapt to the new reality of the internet. Not fight it. > >> >> 2. Posts disappear and are not re-posted in text form. If the message >> was CC'd to another maintainer, then the original posters does not >> care that their message got rejected. They got to their intended >> recipient, who typically responds, leaving broken threads on the >> mailing list. For example, check the thread index for >> http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00011.html. You'll >> notice that there are no messages from Dmitry Vyukov, despite him >> sending no less than 6 replies to that thread. > > It is up to the contributor to read the requirements before submitting > patches and plain text emails are a documented requirement right now. It is also up to the contributor to not care and take their contributions elsewhere. > Bad formatted emails are less likely to happen with plain text. > Allowing rich text will cause people to have worse formatted email. Do you have data to support this? > >> >> I'm more concerned about #2. Today's software is more than capable of >> dealing with rich text. Is it really that important for us to stick >> to this requirement? >> >> If the reason is "because we like it this way", please consider the >> impact on contributors and would-be contributors. Why add one more >> aggravation to the already long list? > > It is not just because we like it this way, rich text (or in some > cases html) can cause security holes. Again. Data? > PS I think this really should go to the gcc@ list rather than > overseers list because even though overseers is in control of the > machines, the decision about allowing rich text is a gcc policy rather > than a machine policy. Sure. First I wanted to find out whether this requirement is just a technical limitation with our mailing list software. Diego.
Re: Could we start accepting rich-text postings on the gcc lists?
> > > > incorrect accessment > > I can't parse this. Maybe HTML markup can help you. Stupid conversation
Re: Could we start accepting rich-text postings on the gcc lists?
Why are you using google for your mail? Can't you get a real mail client and a real mail access? Or maybe you work for google, in which I can undersand it.
Re: Could we start accepting rich-text postings on the gcc lists?
On Fri, Nov 23, 2012 at 3:31 PM, Ruben Safir wrote: >> > >> > incorrect accessment >> >> I can't parse this. > > > Maybe HTML markup can help you. > > > Stupid conversation No need to respond in such an arrogant and condescending manner. I do not understand what "incorrect accessment" means. Diego.
Re: Could we start accepting rich-text postings on the gcc lists?
On Fri, Nov 23, 2012 at 03:35:57PM -0500, Diego Novillo wrote: > On Fri, Nov 23, 2012 at 3:31 PM, Ruben Safir wrote: > >> > > >> > incorrect accessment > >> > >> I can't parse this. > > > > > > Maybe HTML markup can help you. > > > > > > Stupid conversation > > No need to respond in such an arrogant and condescending manner. I do > not understand what "incorrect accessment" means. Here is 50 cents kid. Get yourself a real operating system. Are we done with this nonsense yet and can we get back to discussing the GNU complier? Ruben ~~~ So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 © Copyright for the Digital Millennium
Re: Could we start accepting rich-text postings on the gcc lists?
On 11/23/2012 08:12 PM, Andrew Pinski wrote: > On Fri, Nov 23, 2012 at 11:53 AM, Diego Novillo wrote: >> In this day and age of rich-text capable mailers, restricting postings >> to be text-only seems quaint and antiquated. Are there any hard >> requirements that force us to only accept plain text messages? It's a reasonable compromise, I would have thought: it makes things easier for the reader while restricting the writer. There are many more readers than writers, so this is a win. Andrew.
Re: Could we start accepting rich-text postings on the gcc lists?
On Fri, Nov 23, 2012 at 4:14 PM, Andrew Haley wrote: > On 11/23/2012 08:12 PM, Andrew Pinski wrote: >> On Fri, Nov 23, 2012 at 11:53 AM, Diego Novillo wrote: >>> In this day and age of rich-text capable mailers, restricting postings >>> to be text-only seems quaint and antiquated. Are there any hard >>> requirements that force us to only accept plain text messages? > > It's a reasonable compromise, I would have thought: it makes things > easier for the reader while restricting the writer. There are many > more readers than writers, so this is a win. Well, it's not actually restricting writers, as I showed in that thread (there are others). When the writer reaches the intended individual recipient, they proceed to ignore the rejection message from the list. This is a net loss for us. And restricting writers, may result in the loss of contributors in the medium/long term. We are putting several roadblocks for new contributors. This is not a good long term strategy for us. Diego.
Re: Could we start accepting rich-text postings on the gcc lists?
> And restricting writers, may result in the loss of contributors in the > medium/long term. We have a lot of things we do that "restrict" writers. We insist that patches be tested. We insist that coding standards be followed. We insist that good documentation practices be applied. We don't allow certain changes at certain times in the process. Etc. We do this because we value quality above quantity. Are there really people who are disciplined enough to follow those rules who can't or won't follow a "text-only" rule?
Re: Could we start accepting rich-text postings on the gcc lists?
On Fri, Nov 23, 2012 at 4:27 PM, Richard Kenner wrote: >> And restricting writers, may result in the loss of contributors in the >> medium/long term. > > We have a lot of things we do that "restrict" writers. We insist that > patches be tested. We insist that coding standards be followed. We > insist that good documentation practices be applied. We don't allow certain > changes at certain times in the process. Etc. No. You are confusing artificial restrictions with QOI. Coding and testing standards are paramount for the long term viability of the project. > Are there really people who are disciplined enough to follow those rules > who can't or won't follow a "text-only" rule? It's not that they *cannot* follow an arbitrary rule. It is that the rule bears no relation with the quality of their work, so they see it as an artificial roadblock which merely irritates them. Add enough irritants and they may decide to take their contributions elsewhere. Diego.
Re: Could we start accepting rich-text postings on the gcc lists?
> It's not that they *cannot* follow an arbitrary rule. It is that the > rule bears no relation with the quality of their work, so they see it > as an artificial roadblock which merely irritates them. Add enough > irritants and they may decide to take their contributions elsewhere. Coding standards are "arbitrary" rules. For the vast majority of coding standards, you can't make a technical argument for or against them. We all agree to use the same standard because we understand that uniformity is important. Similarly for text-only vs. "rich text". You may argue that there's no compatibility issue, but I disagree. As was pointed out upthread, when people use "rich text", they often start to use colors or other mechanisms to express themselves, which can now be dependent on the rendering agent used to read the email. Requiring people to express themselves using only words seems to me to encourage the sorts of discipline that we require in contributors.
Re: Could we start accepting rich-text postings on the gcc lists?
On Fri, Nov 23, 2012 at 4:41 PM, Richard Kenner wrote: > Similarly for text-only vs. "rich text". You may argue that there's no > compatibility issue, but I disagree. As was pointed out upthread, when > people use "rich text", they often start to use colors or other mechanisms > to express themselves, which can now be dependent on the rendering agent > used to read the email. Requiring people to express themselves using only > words seems to me to encourage the sorts of discipline that we require in > contributors. We disagree on this point, then. While rich-text can be abused, it is not my experience that people do abuse it to the point of making their postings illegible. The markings you see commonly used are monospace font alterations, bolding and lists. I have noticed no correlation between the ability to use a markup language and quality of contributions. But more than anything, people write plain text with no markups. It's just that an increasing number of mail agents are configured by default to send rich-text. So, I disagree that we will start seeing posts with animated gif images, magenta backgrounds and green fonts. Would you be willing to give it a try? If we measure any loss in quality, then we can always flip back to text-only. Diego.
Re: Could we start accepting rich-text postings on the gcc lists?
> 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.
Re: Could we start accepting rich-text postings on the gcc lists?
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. Diego.
gcc-4.6-20121123 is now available
Snapshot gcc-4.6-20121123 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20121123/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch revision 193770 You'll find: gcc-4.6-20121123.tar.bz2 Complete GCC MD5=cd7c1279700354284ce0dd7cd62b498b SHA1=180a66569f9286b1e31872e1101281a7b657785f Diffs from 4.6-20121116 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 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.
Re: Unifying the GCC Debugging Interface
Thanks for all the comments. I have incorporated all the feedback (I hope). We will start implementing this in the cxx-conversion branch. I've created a new wiki page with the debugging proposal: http://gcc.gnu.org/wiki/cxx-conversion/debugging-dumps It is also indexed from the general improvement projects wiki: http://gcc.gnu.org/wiki/ImprovementProjects Diego.
Re: Could we start accepting rich-text postings on the gcc lists?
For me the most annoying thing about HTML burdened emails is idiots who choose totally inappropriate fonts, that make their stuff really hard to read. I choose a font for plain text emails that is just right on my screen etc. I do NOT want it overridden. And as for people who use color etc, well others have said enough there .
RE: Could we start accepting rich-text postings on the gcc lists?
> > Similarly for text-only vs. "rich text". You may argue that there's no > > compatibility issue, but I disagree. As was pointed out upthread, when > > people use "rich text", they often start to use colors or other mechanisms > > to express themselves, which can now be dependent on the rendering agent > > used to read the email. Requiring people to express themselves using only > > words seems to me to encourage the sorts of discipline that we require in > > contributors. > > We disagree on this point, then. While rich-text can be abused, it is > not my experience that people do abuse it to the point of making their > postings illegible. The markings you see commonly used are monospace > font alterations, bolding and lists. I have noticed no correlation > between the ability to use a markup language and quality of > contributions. I am regular reader of several mailing lists, some of which (such as this one) require plain text, and some (like cdt-dev) which allow rich text. My experience has been that the formatting of messages on plain-text lists is consistent across the board, while on rich-text lists you get a mess by mixing together different formatting conventions. A prominent example is the formatting convention used for quoting the message you're replying to. Plain-text lists always use one convention: greater-than signs (>) before each line of the quote, one for each level of quoting. On rich-text lists, some messages use greater-than signs, some use a vertical line to the left of the text, some use a different color, etc. The result is a mess that's difficult to follow. I think rich-text works well when everyone uses the same mail client. For example, at a company I used to work, for everyone used Microsoft Outlook as their mail client, and emails were sent in rich text. There was no readability problem there because everyone used the same formatting conventions. However, requiring that everyone that posts to a public mailing list use the same mail client is even more restrictive than requiring that they use plain text. The only other way to ensure consistency of formatting conventions is to use the lowest common denominator between mail clients, which is plain text. Regards, Nate
