Thank you!
Folks -- It's been a long time since I've posted to the GCC mailing list because (as is rather obvious) I haven't been directly involved in GCC development for quite some time. As of today, I'm no longer at Mentor Graphics (the company that acquired CodeSourcery), so I no longer even have a management role in a company involved in GCC development. And, as I don't have plans to be involved in GCC development in the foreseeable future, it seems best to admit that I'm no longer a maintainer of GCC. I've also tendered my resignation to the GCC Steering Committee. David Edelsohn has kindly agreed to make the requisite changes to the MAINTAINERS file on my behalf. GCC has been an interest of mine for a very long time, beginning with the point at which I convinced a previous employer to deploy it as a cross-platform compiler solution because we were having so many problems with incompatibility between the various proprietary compilers we were using. Of course, GCC itself still had a few bugs left at that point, so I fixed one or two, and, later, when I should have been writing papers in graduate school, I implemented some C++ template features (with much help from Jason Merrill and others) instead, and, eventually became very involved in the development of GCC. I'll of course remain interested in GCC, even if more as an observer than as a participant! I'd very much like to thank all who are, have been, or will be developers and maintainers of GCC. Of course, I'm particularly grateful to those who reviewed my patches, fixed the bugs I introduced, endured my nit-picking reviews of their patches, and so forth. But, there are literally hundreds of you -- perhaps thousands -- who have contributed, and I'd like to thank all of you; your contributions and your community gave me the opportunity to have a ton of fun. Thank you, -- Mark Mitchell
GCC Release Management
The GCC Steering Committee appointed me to the role of GCC Release Manager on March 22, 2000, as part of the GCC 3.0 release cycle. Eleven years and umpteen releases later, it's time for me to relinquish that position. I am just as interested in GCC as ever, but I simply no longer have the time to contribute to GCC on a day-to-day basis. Fortunately, in 2008, the GCC SC added three co-RMs: Jakub Jelinek, Joseph Myers, and Richard Guenther. The three of them have shouldered the majority of the load over the past couple of years. The SC collectively and I personally have every confidence in their ability to do continue onwards. In fact, I have no doubt that they will do a better job together of managing future releases than I did. During my tenure as RM, I received the support, kind words, and constructive criticism of many, many people -- far too many to name. I am very grateful for all of that and, more generally, for having had the opportunity to be involved in such an important open-source project. Thank you, -- Mark Mitchell CodeSourcery / Mentor Graphics m...@codesourcery.com (650) 331-3385 x713
Re: [PATCH, 4.7] PR 48192, Make conditional macros not defined for #ifdef
On 3/18/2011 4:26 PM, Michael Meissner wrote: This patch makes conditional macros that are used in the PowerPC and SPU ports not be 'defined' for the #ifdef, #ifndef, and #if defined(...) tests. I think that's a desirable change, from a language semantics point of view, but I would defer to Joseph on this issue; he has a much more comprehensive understanding of the C preprocessing rules than I do. I would like to backport this to 4.6, 4.5 and maybe 4.4. Are there objections to backporting it? I have no objection to a backport. Thank you, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Make C1X anonymous structs/unions follow N1549
On 3/18/2011 2:52 PM, Jakub Jelinek wrote: This week's London WG14 meeting agreed to disallow the use of typedefs in declaring anonymous structure and union fields, as per N1549. This patch implements this, restricting the use of typedefs in this case to -fms-extensions and -fplan9-extensions as in 4.5 and earlier releases. I guess it is ok for 4.6.0 too. I think avoiding the ping-pong in behavior between 4.5 and 4.7 is a good call. So, I think the patch is OK for 4.6. Thank you, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: PR debug/47510
On 3/17/2011 4:08 AM, Dodji Seketeli wrote: Yesterday after discussing this on IRC, Jakub expressed his personal opinion by saying the patch could go in 4.6. I mistakenly took it as a formal approval from the RMs and I committed it. I should have waited for an approval by email. You don't have to apologize -- an approval from any RM, in any forum (IRC, email, etc.) is sufficient authorization. It's a regression from 4.5, caused by the fix for PR c++/44188. And, in any case, if it's a regression it's OK with me. Thank you, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: PR debug/47510
On 3/16/2011 1:04 PM, Dodji Seketeli wrote: Would the RMs (in CC) object to this patch going into 4.6? What would be the justification for that? The bar is pretty high on putting a patch onto a release branch. I don't see any evidence that this is a regression, and a bug that affects debugging is never *that* serious compared to (for example) silent wrong-code generation. In this case, we're dealing with anonymous structs, which aren't very common. This just seems like a run-of-the-mill bug to me. Thank you, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
PATCH: Remove README.QMTEST
It was recently pointed out to me that we still have the README.QMTEST file in gcc/testsuite. That file talks about how to use QMTest instead of DejaGNU to test G++ -- but the information there is just not accurate anymore. Various things have bit-rotted since the point at which that was written. Given that nobody is actively working on making this work, it's best just to remove the file. Applied. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713 2011-03-06 Mark Mitchell m...@codesourcery.com * README.QMTEST: Remove. [actual diff elided for brevity]
Re: PATCH: Remove README.QMTEST
On 3/6/2011 2:57 PM, Mike Stump wrote: It was recently pointed out to me that we still have the README.QMTEST file in gcc/testsuite. That file talks about how to use QMTest instead of DejaGNU to test G++ If you were to summarize the 3 most compelling features provided, I'd be interested. I'm thinking it was parallel testing... That's one. A couple of others: (a) QMTest is a structured system, i.e., you can enumerate all of the tests and ask questions about them. In contrast, with DejaGNU, you can only figure out what tests you have by running them -- we depend on executable .exp files to enumerate tests, not declarative information. For example, try asking DejaGNU how many tests do I have?, or how many tests do I have for Solaris targets that aren't applicable to Linux targets? (b) QMTest has a facility for saving results in structured formats (rather than text-based .log/.sum files) so that they can be processed or queried later. One immediate use of this is that you can compare results today with results yesterday in ways more structured that diff. Thank you, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Liqin Chen now maintainer of SCORE port
Liqin -- The GCC SC has appointed you the maintainer of the SCORE back-end. Congratulations! As we've discussed previously, the mere fact that there is a maintainer for a port does not imply that the port will not be deprecated or removed. So, I hope that you will be able to actively maintain the port from this point forward. Please remember to update the MAINTAINERS file. Thank you, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
New libquadmath maintainers: Jakub and Tobias
Jakub, Tobias -- The GCC SC has appointed you as maintainers of libquadmath within GCC. Please update the MAINTAINERS file to reflect your new positions. Congratulations! -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: PATCH RFA: Do not build java by default
On 11/11/2010 3:20 PM, Ian Lance Taylor wrote: On Sun, Oct 31, 2010 at 12:09 PM, Ian Lance Taylor i...@google.com wrote: Currently we build the Java frontend and libjava by default. At the GCC Summit we raised the question of whether should turn this off, thus only building it when java is explicitly selected at configure time with --enable-languages. Among the people at the summit, there was general support for this, and nobody was opposed to it. I count 33 messages on the topic and it is clear that there is no consensus. I am withdrawing this proposed patch. I think that's a mistake. The arguments raised, such as the fact that Java tests non-call exceptions, are just not persuasive to me. If we need tests for a middle-end feature, we can almost always write them in C or C++. The bottom line is that libjava takes a very long time to build and that the marginal benefit is out of proportion to the cost. Building zillions of Java class files cannot be the best way to test non-call exceptions. If we have no tests for non-call exceptions in the C/C++ testsuite, perhaps you (Ian) could write a few in C++? Ian, I was prepared to approve the patch. I certainly won't do that if you now think it's a bad idea, but if you still think it's a good idea, I think you should go for it. I think that it should still be the case that if you break Java, and one of the Java testers catches you, you still have an obligation to fix the problem. All we're changing is whether you build Java by default; nothing else. Thank you, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: PATCH RFA: Do not build java by default
On 11/18/2010 2:00 AM, Andrew Haley wrote: I made it pretty clear that as long as the autotesters build java, and I get emails when something breaks, and you have the obligation to fix whatever broke, I have no objection. Great. In contrast to Ian's statement, then, I think we *do* have a consensus: remove Java from default languages, but do leave it in autotesters (with consequences as above). Thank you, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: PATCH RFA: Do not build java by default
On 11/18/2010 9:16 AM, Diego Novillo wrote: I wouldn't mind this change. It is still the case that Ada will selectively turn itself off when it cannot find a stage0 gnat compiler, right? I don't mind this either, but let's treat them as orthogonal. Let's not let a possible change on the Ada side prevent us from making the Java change. Thank you, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Mailing lists for back-end development?
I spoke with a partner today who suggested that perhaps it would be a bit easier to follow the voluminous GCC mailing list if we had separate lists for patches related to particular back-ends (e.g., ARM, MIPS, Power, SuperH, x86, etc.). The idea here is that (as with libstdc++), we'd send patches to gcc-patches@ and gcc-$arch@, but that reviewers for a particular back-end would find it easier to keep track of things on the architecture-specific lists, and also that this would make it easier when trying to track down patches to backport to distribution versions of the compiler. What do people think about this idea? Thank you, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Mailing lists for back-end development?
On 11/16/2010 11:24 AM, Dave Korn wrote: I think it's probably an over-engineered solution to a problem we could really address best by remembering to use []-tags in the subject lines. OK, that seems to be as close to consensus as we're probably going to get. Let's try and do that. Thank you, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Discussion about merging Go frontend
On 10/28/2010 6:31 PM, Ian Lance Taylor wrote: This patch requires approval from the LTO maintainers. I don't need approval for the libiberty changes (if the code stays in libiberty) but of course I would appreciate it if somebody could look it over. I think the configure and Makefile changes are sufficiently obvious given the other changes as to not require approval. This all looks good to me, and seems like a reasonable solution. I think libiberty is as good a place as any for the routines, FWIW. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Discussion about merging Go frontend
On 10/26/2010 10:41 AM, Joseph S. Myers wrote: Well, slow on hosts where process creation is slow (just like the separate gcc/cc1/as/collect2/ld/lto-wrapper/... processes). The separate process design was probably based on process creation being fast A lot of this is also historical; gcc/cc1/as/ld mirror typical UNIX compilers of the era at which GCC was built. collect2 was presumably necessary because of dependence on proprietary ld; if we could assume GNU ld (or GOLD) everywhere, we could fold that functionality directly into the linker. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Discussion about merging Go frontend
On 10/24/2010 10:52 PM, Ian Lance Taylor wrote: It's hard for me to believe that BFD is the correct answer. It's poorly designed for the kinds of things the compiler needs to do. Any program which links against BFD effectively links in the GNU linker. It sounded from your mail like all the compiler needs to do is to read the binary contents of a named section. Isn't that something that BFD does well? -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Discussion about merging Go frontend
On 10/25/2010 7:01 PM, Dave Korn wrote: What would be even nicer would be if we could share the same code-reader interface between lto and go (and the lto-plugin), thereby getting object format independence equally everywhere for no extra cost. That could be orthogonal to plugging elfcpp into the role currently occupied by libelf in that reader. I think it's reasonable to argue that GCC should, going forward, be an ELF-only toolchain -- with postprocessing tools for generating PE/COFF, Symbian DLLs, Mach-O or what have you. But, we haven't made that decision. So, I don't think we should get there by half-measures. Either we should decide that's what we want to do, or we should try to keep the compiler independent of the object file format -- as we have up until now. I understand Ian's distaste for BFD, but it is the format-independent object file reader we have, so it seems a natural choice. And libelf, which we already rely on seems more natural than elfcpp, if we're willing to go ELF-only -- unless we're going to replace the use of libelf in LTO with elfcpp as well. In any case, I think we should avoid a single compiler build requiring multiple object-file reading libraries. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Discussion about merging Go frontend
On 10/25/2010 10:07 PM, Dave Korn wrote: - integrate gccgo, with elfcpp - then common out the file-reading stuff from gcc/lto/ up to gcc/ so that all the FEs can share it - then convert it to use elfcpp (with a bit of file I/O added) and stop using libelf altogether - then switch gccgo over to using it I think that's a reasonable plan. It makes things no less object-file netural than they are now, which is OK. (And, before someone else points it out, I believe it was I who started using libelf in the LTO prototype, so I know full well how we got here!) I certainly have no problem with using elfcpp over libelf. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Discussion about merging Go frontend
On 10/25/2010 10:34 PM, Frank Ch. Eigler wrote: By the way, is there some necessity in accomplishing this by means of a linked library, as opposed to via a spawned objcopy process? Probably none in theory, but it certainly seems messy and likely to be slow in practice. Is there a reason that this would be desirable? -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Discussion about merging Go frontend
On 10/25/2010 10:39 PM, Frank Ch. Eigler wrote: It would seem to moot the present discussion about competing elf consumer libraries. none of the above is a possible answer. True. It seems that LTO and Go need a very simple interface; presumably we can abstract that in the compiler and then we can implement that interface as we please. I agree that a fallback to an external objcopy is plausible, as is linking with BFD. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Laurynas Biveinis now gengtype reviewer
Laurynas -- The GCC SC has appointed you as a reviewer for the gengtype/GTY machinery in GCC. You now have the authority to review and approve patches to the gengtype programs, to use of GTY markers, and other related topics. Please update MAINTAINERS to reflect your appointment. Thank you, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: check_cxa_atexit_available
On 9/29/2010 3:53 PM, Richard Henderson wrote:
The test program in target-supports.exp is broken, since
it doesn't preclude the use of cleanups instead. Indeed,
the init/cleanup3.C seems to be essentially identical to
the target-supports test.
Why isn't the test program in target-supports.exp just a link-time test
that __cxa_atexit exists? In other words:
void main () {
__cxa_atexit (...);
}
Is the idea that we want to be able to run the tests with
-fno-use-cxa-atexit in the command-line options? I guess we have to
worry about that. In that case, yes, I guess an assembly-scan test in
target-supports.exp is the best that we can do.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
Re: -Wdouble-promotion noise
On 9/14/2010 10:59 AM, Daniel Jacobowitz wrote: printf(%f, f); double.cc:5:7: warning: implicit conversion from 'float' to 'double' My two cents, but that looks exactly right to me. Passing the float to printf is going to convert it to a double and it will be printed as a double, so you're unexpectedly adding double-precision operations to the program. Indeed. Even if printf always used software emulation, if you had a hardware floating-point ABI in which floats were passed in registers, but doubles on the stack (due to a lack of double-precision registers), this would be slow. Does printf(%f, (double) f) suppress the warning? It should; if it does not, that would be a bug. I guess I can see an argument that printf is a special case, by virtue of being a well-known library function, and that we should not warn in that specific case even if we should warn about calls to functions written by users. But, the cast to double is valid on all platforms, so I'm not sure that's a bad solution either. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: End of GCC 4.6 Stage 1: October 27, 2010
On 9/4/2010 9:23 PM, NightStrike wrote: We would like x86_64-w64-mingw32 to become a secondary target for 4.6. Who is we in this context? What has to be checked off for that to happen? It's not so much a matter of checking off. It's a combination of the SC's perception of the importance of the target and the technical stats of the port. I can raise the issue with the SC, if you like, but, personally, I'm not sure that 64-bit Windows is significant enough as a target platform for GCC to merit that status. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: End of GCC 4.6 Stage 1: October 27, 2010
On 9/5/2010 11:23 AM, NightStrike wrote: It's not so much a matter of checking off. It's a combination of the SC's perception of the importance of the target and the technical stats of the port. I can raise the issue with the SC, if you like, but, personally, I'm not sure that 64-bit Windows is significant enough as a target platform for GCC to merit that status. Ouch. What criteria do you use for that analysis? I can't say what criteria the SC uses; I don't know what basis other SC members use to decide. I use my own instincts (which, I admit, is not a scientific basis) for deciding. I spend much of my life talking to various stakeholders in GCC, and so I have a reasonable feel for where people are presently using GCC, and where they would like to use it. Thus far, I've certainly heard of some interest in 64-bit Windows, but nowhere near as much as 32-bit Windows or Cygwin. I certainly don't mind raising the issue, if you want me to do that; I'm happy to carry messages to the SC independent of my own opinions. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: End of GCC 4.6 Stage 1: October 27, 2010
On 9/5/2010 11:34 AM, NightStrike wrote: I certainly don't mind raising the issue, if you want me to do that; I'm happy to carry messages to the SC independent of my own opinions. Yes, definitely bring it up. I'm just trying to get more cards stacked in our favor :) OK, I've asked the SC to consider it. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Add uninitialized attribute?
On 8/31/2010 1:19 AM, Andrew Haley wrote: On 08/30/2010 03:50 PM, Vincent Lefevre wrote: On 2010-08-30 14:46:57 +0200, Michael Matz wrote: int x = x; is the way GCC offers this idiom since about forever, no need for an attribute. Downthread I see that people worry about this generating an actual (uninitialized) access to x. They are confused. This is not a good idea as int x = x; may really generate an (uninitialized) access to x with other compilers. Absolutely so. I suspect it's even undefined behaviour in the standard language. There's no way that this idiom should appear anywhere in GNU code. I agree; an attribute, or the __unitialized__ keyword would be much cleaner. On the other hand, I think GCC should continue to accept int x = x; as a synonym for the forseeable future; whether or not it's good language design it has been a de facto part of GNU C for a long time. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
End of GCC 4.6 Stage 1: October 27, 2010
We (GCC RMs) plan to close GCC 4.6 Stage 1 on or or about October 27, 2010 (the closing day of the GCC Summit). Major features should be checked in prior to this point. Please let us know if you have a major feature that you think you will not be able to get checked in prior to October 27th. Thank you, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Add uninitialized attribute?
Kreitzer, David L wrote:
There are some situations where an __undefined__ keyword would be useful
Thanks for the example.
I suppose that in C the natural syntax is a pseudo-function that takes a
type, rather than an object, as an argument:
__undefined__(int)
__undefined__(vector float)
...
In GCC, at least, __undefined__ could be a macro, for the purposes of
defining its semantics:
#define __undefined__(T) \
({ T t; t })
That is, create an new variable of type T, do not initialize it, and use
its value.
But, we would not issue warnings about it.
The macro definition is possibly also useful in that I think it says the
right thing for C++. In particular, in C++, for a class that has
constructors, constructors should run. You *should not* be able to say:
__undefined__(std::vectorint)
and somehow bypass the constructor. That violates key assumptions of
the programming model in C++.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
Re: Add uninitialized attribute?
Bernd Schmidt wrote: int x __attribute__ ((uninitialized)); to tell compiler that it is OK for x to be uninitialized? Better to call it initialized, analogous to attribute used/unused. I agree. I think the general idea is reasonable. I also think it might be worth spending a few minutes thinking about whether we can implement some more general diagnostic suppression mechanism. E.g., int x __attribute__ ((ignore (-Wuninitialized))); Or this. FWIW, I think that's overly ambitious. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Add uninitialized attribute?
H.J. Lu wrote: void *undef __attribute__ ((uninitialized)); // Or something similar foo (undef); Compiler can pass some junk to foo. I don't think that's a very good idea. If we need this, which I doubt, it should be something like a new __undefined__ keyword, that expands to an undefined value. In C++, a syntax like __undefined__X() would be plausible; I'm not sure there's a good C syntax. Perhaps you could do what tgmath does. I guess if you had this, you could use it in place of the attribute; int i = __undefined__int(); would serve to indicate that you were knowingly not initializing i. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: GFDL/GPL issues
Richard Kenner wrote: That is true, but very often the documentation is needed in two places: in the code and in the manual. Especially for things like machine constraints, flags and options. Yes, but the audiences are different between users who read the manual and developers who read the code. Richard, your argument is a distraction from the important issue at hand. Unless you posit that there is no useful way in which to generate documentation from code (and comments therein), which seems an extreme statement, then it is desirable that we have the ability to do that. Right now we don't. That's bad. I certainly don't disagree that it might be desirable for documentation for constraints might be different for end users and for GCC developers. But, there is nothing that says that both kinds of documentation might not be located physically in the code, so that when you add/delete/modify a constraint you can also easily update the documentation. And, furthermore, just because it might be desirable for the documentation to be different for end-users and compiler developers doesn't mean that it's practical for them to be different. I don't see a mob of people beating down the doors to write GCC documentation. So, I'm not inclined to let perfect be the enemy of good. If we only get one flavor of documentation, that's a lot better than none at all! In any case, the key issue here isn't how we should write documentation. It's whether we can use a technological measure to generate documentation if we find cases where that is desirable. It makes no sense for the FSF to artificially erect legal barriers to using a given technical approach to creating documentation. If this is really about documentation quality, the FSF could simply have a policy saying that GNU maintainers should not do this -- there is no reason to have a legal prohibition preventing people from doing it! -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: GFDL/GPL issues
Richard Kenner wrote: bad isn't very precise. The claim was made that a reason that it's bad is that not being able to automatically generate documentation lowers the quality of the documentation. That's what I disagree with. OK, fine; that's a reasonably debatable point. But, we currently can't automatically generate manuals -- which is something we used to be able to do -- and that's bad. In general, a policy that prevents us from being able to use a particular technical method to achieve a goal is silly. But, there is nothing that says that both kinds of documentation might not be located physically in the code, so that when you add/delete/modify a constraint you can also easily update the documentation. In that case, wouldn't we have two distinctly different kinds of material in the same file: an extract from a manual and code. So why couldn't the file have a license that says this part is GFDL and this part is GPL? Maybe it could. But, maybe it can't. It depends on how closely you can weave the documents together before you end up with something that is more than mere aggregation. None of this really answers the key question, which is, in my opinion, what is the GFDL actually buying us? And, if all it's buying us is that people can't remove the FSF's philosophical statements in manuals, is that worth having to split hairs about exactly what parts of what documentation can be generated in what exact manner? -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: GFDL/GPL issues
Robert Dewar wrote: I don't think it is making this impossible, my advice is simply to consider this fair use and steam ahead, then worry if someone objects. Despite the copyright holder (well, RMS, but he certainly can be interpreted as speaking for the FSF) saying plainly and clearly that he thinks that you *cannot* do this? -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: GFDL/GPL issues
Robert Dewar wrote: Whether something is fair use has to be judged on the very specific instance in question, not clear to me that RMS has opined on a very specific issue, if so, I missed it. We don't want to ask RMS every time we want to do this. RMS has opined on some of the specific cases, such as generating documentation for command-line options from comments in the code. He hasn't specifically said whether he thinks it's a GPL/GFDL violation -- but nothing in what he's said would suggest to me that he thinks it's not a violation. In fact, the statement that we can only run such generation scripts in the FSF repository, since only the FSF can relicense the code, would seem to suggest that he believes that, in general, you can't do this. In any case, you're suggesting we go against the express wishes of the FSF. Would you suggest that we do that in the context of FSF GCC? -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: GFDL/GPL issues
Richard Kenner wrote: Could part of the problem here be that RMS's view on documentation is that it's meant to be a creative process, somewhat akin to writing a book, and that mechanically creating documentation will produce something of much lower quality than what's done by hand? Back when he and I spoke regularly, I know that he cared a lot about the literary quality of the documentation and I think that part of this might be due to a why would you want to do that anyway? position on automaticaly-generated stuff. Yes, that is part of his thinking. And, yes, we can split our manuals up into GPL and GFDL pieces, and in some cases that will work fine. But, documentation of constraints (important to users for writing inline assembly), or documentation of command-line options (important to all users), or documentation of built-in functions (important to users to understand the dialect of C we support) are all things that belong in the manual, not in separate GPL documents. FSF policy is making it impossible for us to do something useful to users, that poses no real risk to the FSF's objectives (manuals were under the GPL for ages without the world ending), and which GCC's competitors can do. That's a suboptimal policy. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: GCC RM QA: August 5th
Mark Mitchell wrote: As before, feel free to put questions that you would like to ask on this Wiki page: I failed to include the URL. It is: http://gcc.gnu.org/wiki/Release%20Manager%20Q%26A Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: GFDL/GPL issues
Steven Bosscher wrote: Why not just ignore RMS and the license issues and simply do what we think suits us and the project. Let the FSF deal with the legal consequences, they put us in this messy situation, they deal with it. It seems to me that escalating the issue is more helpful. GCC is not the only project with this problem. Sadly, at this point, RMS is simply taking the position that this is not a problem worth solving. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: GFDL/GPL issues
Robert Dewar wrote: I'm disappointed that a license improvement (changing GPL to GFDL on manuals) has made it impossible to do something that we, as developers, used to be able to do (when documentation was under the GPL we could move things back and forth between code and documentation at will), and which benefited users (by making it easier for us to generate better documentation). I agree that it is essential to be able to do this kind of movement backwards and forwards. Would you like to contact RMS about this? He doesn't seem to think that it's important, let alone essential. His suggestion is that we do this in the FSF repository (where we can explicitly make such license changes), but of course that denies that same freedom to third parties. RMS has proposed a script that regenerates GFDL'd documentation from GPL'd code. But, that is not sufficient because I can regenerate the GFDL'd manual after I change GPL'd code (my changes can be licensed as I see fit), but I cannot regenerate the GFDL'd manual after *you* change GPL'd code if you have not regenerated the GFDL'd manual. I believe that the right fix (short of simply abandoning the GFDL, which would be fine with me, but is presumably not going to pass muster with RMS) is a revision to the GPL that explicitly permits relicensing GPL'd content under the GFDL, by anyone. Movement in that direction should not be of concern to the FSF; the point of the GFDL was to prevent people removing the FSF's philosophical statements in its manuals, not to prevent GPL'd content from being used in manuals. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: GFDL/GPL issues
Benjamin Kosnik wrote: I believe that the right fix (short of simply abandoning the GFDL, which would be fine with me, but is presumably not going to pass muster with RMS) is a revision to the GPL that explicitly permits relicensing GPL'd content under the GFDL, by anyone. I like the sound of this proposed solution and agree fully with your intent to get back to a more workable state for documentation production and creation. I've made the case on the SC list. RMS has thus far not responded directly to this suggestion, but thus far has not seemed terribly concerned about the inability to move things between code and documentation. A few of the other SC members have weighed in, but it would certainly be helpful if more would do so. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: GFDL/GPL issues
Joe Buck wrote: We might need to go in the other direction (less radical, but enough to solve the immediate problem). What if only constraints files are dual-licensed (GPL3+ or GFDL) for now? Then documentation can be generated from them and we've at least solved that problem. If RMS agrees to that and sees that the world doesn't end, maybe he'll be open later on to opening this door wider. It would be a bit frustrating to have to do this piecemeal, but half a loaf is better than nothing. It's certainly fine with me if you want to suggest that on the SC list -- not that you need my permission! -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: GFDL/GPL issues
Richard Guenther wrote: Why not just ignore RMS and the license issues and simply do what we think suits us and the project. Let the FSF deal with the legal consequences, they put us in this messy situation, they deal with it. We should not distribute things in violation of their licenses; that would be both unethical and legally actionable. And, worse yet, we should not induce third parties to take that kind of legal risk. At this point, the manuals are GFDL and the code is GPL; we can't mix them. I suppose we could ask contributors to expressly permit their GPL'd contributions to be licensed under the GFDL, but that's not terribly useful unless we can get some dispensation for the existing code. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
GCC RM QA: August 5th
Joseph Myers, Richard Guenther, and I will be hosting the second GCC Release Manager QA on Thursday, August 5th at 9:00 AM Pacific Daylight Time. (Jakub Jelinek is unfortunately unable to attend.) As before, feel free to put questions that you would like to ask on this Wiki page: if you will be unable to attend, and we will try to address those questions during the QA session. We very much appreciated everyone's participation during the previous session, and look forward to doing it again! Gerald, would you please update the web site as you see fit (if at all)? Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: GFDL/GPL issues
Benjamin Kosnik wrote: What if we ask the FSF if we can dual license the constraints.md files under both the GPL and the GFDL? I agree that we are likely to get more traction with a request to dual license as opposed to re-license. Well, I've asked -- but RMS shot down that idea. Not for the first time I find myself wishing the FSF spent more mental effort on documentation for free software, at every level. I (and I speak here not for the FSF, the SC, CodeSourcery, or anybody else) wish the FSF spent less time improving licenses and more time focused on making FSF software attractive to end users. I'm disappointed that a license improvement (changing GPL to GFDL on manuals) has made it impossible to do something that we, as developers, used to be able to do (when documentation was under the GPL we could move things back and forth between code and documentation at will), and which benefited users (by making it easier for us to generate better documentation). -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: GFDL/GPL issues
Ian Lance Taylor wrote: I believe that the only real fix here is (a) for the FSF to abandon the GFDL, and relicense manuals under the GPL, or (b) for the FSF to add an exception to the GFDL, making it compatible with the GPL in some way. However, I have no evidence that the FSF is considering either of these ideas; RMS didn't provide encouraging feedback when I made such suggestions. What if we ask the FSF if we can dual license the constraints.md files under both the GPL and the GFDL? We could do that. It's a hack, but it might be an acceptable hack. I've been thinking about this from the perspective of how can we get the FSF to put an exception into the GFDL to allow inclusion/generation from GPL'd code?; your clever idea is that if all the code is also GFDL'd then you don't have a problem. I call this is a hack, because we're changing the code license to deal with a problem created by the FSF's insistence on a separate license for documentation, but, hey, it might work. Do you think we should just ask the FSF to dual-license all of GCC? -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: GFDL/GPL issues
Ian Lance Taylor wrote: Do you think we should just ask the FSF to dual-license all of GCC? Sure, it might at least be worth finding out whether they think there is any problem with that. I've asked on the SC list. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: GFDL/GPL issues
Benjamin Kosnik wrote: Is there a separate issue for libstdc++ doxygen? This situation is subtly different from the one outlined above: it is the application of a GPL'd tool over GPL'd sources, which the FSF + Red Hat legal have both told me for years results in GPL'd docs (and is clearly noted as such in the libstdc++ manual under Licensing.) I consider this sane, actually, and would be most unhappily surprised if the act of generating the HTML changed the license to GFDL. As far as I know, everything you say above is correct; the documentation you're generating is GPL'd. (IANAL, of course.) In any case, that wasn't what the discussion with RMS was about. It was about two things: 1. What license should manuals have? The FSF wants them to be GFDL. However, RMS agreed that it's OK for cross-reference information (as opposed to manuals), auto-generated from source code, such as the documentation you're generating with doxygen to be GPL'd. So, the procedure you're using is fine, not just from a is this legal point of view, but also from an FSF policy point of view. 2. Can we move GPL'd code into GFDL'd manuals, or copy text from GFDL's manuals into GPL'd code, or auto-generated GFDL's manuals from GPL'd code? This got complicated; see previous postings. But, it's not relevant to your question, since you're not trying to do that. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: GFDL/GPL issues
Steven Bosscher wrote: 2. Can we move GPL'd code into GFDL'd manuals, or copy text from GFDL's manuals into GPL'd code, or auto-generated GFDL's manuals from GPL'd code? This got complicated; see previous postings. But, it's not relevant to your question, since you're not trying to do that. I would like to do this for the constraints.md files, but it's not clear to me right now whether this is allowed or not. What do you think? I think it's allowed, but not a good idea, due to the fact that I think it creates a trap for people. The FSF has said that it's OK for *us* to do it, in the FSF repository, because the FSF can itself relicense code. But, it's said that it's not OK for third parties to do it, because they can't. And, the natural way for us to do it is via generator programs. This creates a situation where a third party could rerun the generator program and end up with something they couldn't distribute. That seems very tricky to me. I believe that the only real fix here is (a) for the FSF to abandon the GFDL, and relicense manuals under the GPL, or (b) for the FSF to add an exception to the GFDL, making it compatible with the GPL in some way. However, I have no evidence that the FSF is considering either of these ideas; RMS didn't provide encouraging feedback when I made such suggestions. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: GFDL/GPL issues
Joe Buck wrote: However, if we have text that is entirely generated from a GPL program by some kind of generator program, that text can be distributed under the GPL. As a license statement, that's accurate. As a policy statement, the FSF seems to object if the output is a manual, but not if it is a cross reference. If we had a useful manual generated in this way, I'd argue very strongly to the FSF that we should permit its distribution under the GPL, but we don't have such a case, so there's no need for the argument at this time. RMS didn't object to what he called a cross reference or an index, generated this way, to be distributed under the GPL. Right. Not a great solution, but perhaps it can be made to work for a while. Certainly, for the purposes of libstdc++, we're OK. Nothing has to change to keep distributing the doxygen-generated cross-reference for libstdc++. I agree with you that RMS is unlikely to shift his position regarding the GFDL. However, I think it's goofy that we cannot auto-generate parts of the internals manual, or the user's manual, from GPL'd source code. If the FSF's policy of using the GFDL on manuals means that we can't have as good a user's manual as we would otherwise, then -- whatever its purported benefits -- the GFDL is not serving us well, and we should continue making that case to the FSF. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Triplet for ARM Linux HardFP ABI
Richard Earnshaw wrote: The reason why a new triplet is required is that config.guess needs to generate it when running native. Config.guess is the only way to communicate the information needed for a native compiler when no other information is communicated on the command line, and it only reports a triplet. Why not fix this? For example, it could also give back configure options (--with-float=hard) that should be implicitly assumed to have been provided. It really does seem like a hack to use triplets in this way; I think Paul's point that anything that depends on the toolchain triplet to determine ABI is inherently busted is pretty persuasive. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Triplet for ARM Linux HardFP ABI
Richard Earnshaw wrote: Why not fix this? For example, it could also give back configure options (--with-float=hard) that should be implicitly assumed to have been provided. That would be useful for GCC perhaps, but not for other projects that use config.guess (which is part of the generic GNU infrastructure). If those extra args could be made invisible to other users; then that might be a way forward. Presumably config.guess would be passed a new argument that causes it to produce this extra output. It really does seem like a hack to use triplets in this way; I think Paul's point that anything that depends on the toolchain triplet to determine ABI is inherently busted is pretty persuasive. Which means the whole GNU way of doing this has always been busted, since that's essentially how the world has always worked... :-) Well, indeed. There's always the question of when one ought to go clean up the mess and when one ought to just go with the flow. We've seen these kinds of problems on every embedded architecture; MIPS, for example, has suffered rather badly from this problem. Deriving ABI behavior from triplets is a problem that's caused brokenness for multilib'd toolchains in various packages. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
ARM GNU/Linux has replaced ARM EABI on primary platform list
The Steering Committee has decided to replace arm-eabi with arm-linux-gnueabi on the primary platform list for GCC 4.6. That change reflects the increasing use of ARM cores in GNU/Linux systems and the fact that it is now relatively easy to obtain such systems. I've applied the attached patch to reflect that change. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713 ? htdocs/.#cvs.html.1.178 ? htdocs/cvs.html.~1.178.~ ? htdocs/develop.html.~1.62.~ ? htdocs/index.html.~1.538.~ Index: htdocs/gcc-4.6/criteria.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.6/criteria.html,v retrieving revision 1.1 diff -c -5 -p -r1.1 criteria.html *** htdocs/gcc-4.6/criteria.html6 Apr 2010 11:34:45 - 1.1 --- htdocs/gcc-4.6/criteria.html11 Jul 2010 19:34:59 - *** application testing./p *** 95,105 h2Primary Platform List/h2 pThe primary platforms are:/p ul ! liarm-eabi/li lii386-unknown-freebsd/li lii686-pc-linux-gnu/li limipsisa64-elf/li lipowerpc64-unknown-linux-gnu/li lisparc-sun-solaris2.10/li --- 95,105 h2Primary Platform List/h2 pThe primary platforms are:/p ul ! liarm-linux-gnueabi/li lii386-unknown-freebsd/li lii686-pc-linux-gnu/li limipsisa64-elf/li lipowerpc64-unknown-linux-gnu/li lisparc-sun-solaris2.10/li
Re: Plug-ins on Windows
Joern Rennecke wrote: The main utility of plugins is that they make developing, testing and deploying modifications to gcc easier. This may be true now, but I certainly hope it will not be true in future. I view the current plug-in mechanism as a prototype. I think that we should be working toward a much more robust mechanism, similar to plug-ins for Eclipse, Firefox, MySQL, or other popular software stacks. I certainly see no reason that plug-ins cannot work on any system that has something roughly equivalent to dlopen (which Windows and OS X certainly do). There's lots of prior art here. The key change we need to make is that instead of the current unstructured approach where we essentially expose the entirety of the GCC internals, we provide a stable, documented API that exposes a portion of the internals. (It's fine with me if there's an expert mode in which you can do anything you want, but it should be easy to stay within the stable API if you want to do that.) I would start with an API for observing (rather than modifying) the internal representation, and add modification later. With observation alone, you could start to build interesting static-checking tools, including, for example, domain-specific tools that could check requirements of the Linux kernel. This would be a powerful and exciting feature to have in GCC. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: RFD: test requirements for slow platforms
Ian Lance Taylor wrote: I'm personally reluctant to codify it, because it's really hard to codify good judgment. But if you say in your patch how you tested it, the reviewers should be able to consider whether that is sufficient. I agree. I always claim that my most valuable contribution to GCC was the argument I started a decade ago that culminated in us deciding that you had to run the regression testsuites before check-in. So, I'm a big fan of testing, and the general idea that you shouldn't have to deal with breakage because I was too lazy to test. On the other hand, I think we can get obsessive about it. Testing Ada and Java libraries for every C front-end change seems excessive to me. Testing is not free. Similarly, doing a bootstrap on Super-H GNU/Linux is possible, but it takes a *long* time. I doubt that's worthwhile most of the time. I think we should allow some judgment, and, as you say, we should provide transparency with respect to which testing was done. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Plug-ins on Windows
Manuel López-Ibáñez wrote: So I would prefer that GCC developers do not say We want to provide an API when what is actually meant is We will be happy if people contribute patches towards providing an API. OK, I agree with that. As far as I know, nobody right now is actively working on improving the plug-in API in the way that I suggested. So, yes, I would be happy if someone would like to work on that and to contribute patches. I will volunteer to help review patches that move in this direction. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Patch pinging
Ian Lance Taylor wrote: Thanks for the info. So there is now a provenance, which is the point: there is a more-or-less real person associated with each contribution. I certainly would like the FSF to move to a similar model. I agree. I do understand the rationale for the FSF's desire to hold copyright, and have a paper trail. But, at this point, I think that's making it harder to people to participate, and with no real benefit. The FSF is clinging to an outmoded policy due to a single occurrence from long ago. However, I believe that there is nothing we can do about that; I don't imagine that this is something on which RMS or the SFLC would likely move. I think that means that our only pragmatic choice is whether to be an FSF project or not. If we don't want that, then, of course, we could adopt the Linux kernel's rules on contribution instead. (We'd also give up any ability to relicense code going forward (e.g., between GPL and GFDL) since we'd likely have many copyright holders, and no practical hope of getting them all to agree on any change.) But, as long as we do want to be an FSF project, we have to play by the FSF's rules. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Deprecating ARM FPA support
Martin Guy wrote: For ARM boards without mainline Linux support whose manufacturers' kernel ports predates 2.6.16, it is mandatory, as is also is for users who just want to compile code for a given existing system that happens not to be running a recent kernel and userspace. But what are the chances that GCC 4.7 (the first release in which FPA would actually be removed, and probably not released until about two years from now) is actually useful on this system? It's very unlikely that GCC 4.7 will successfully compile the 2.6.16 kernel, or, I would expect, a lot of userspace applications. My feeling is that it makes sense to deprecate this now, which allows us in the 4.7 cycle to decide whether or not to remove the functionality. If we decide then that it's still needed, we can always keep it. But, if we don't deprecate it now, then our policy is that we can't remove it. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: ChangeLog licensing issues
Joseph S. Myers wrote: But if identifieres were OK, wouldn't that mean that auto-generating documentation that shows hook names along with argument types and names are also OK? I do not see any copyright issues with the hook names and argument types and names. With the bodies of the descriptions of the semantics of the hooks (in .texi or comments), yes, but not with the names and types of hooks and their arguments. I agree. Joern, I don't think anything in the ChangeLogs that you are writing is going to be a problem. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: subreg against register allocation?
Ian Lance Taylor wrote: Well, as you know, subregs have two meanings which look similar but are in fact entirely different. It's valid to set subregs of the same pseudo in parallel if the subregs represent different hard registers. Are you aware of any examples of this in the compiler? The explanation is of course plausible, but do we know that we handle this correctly everywhere? Hmmm, you could be right. Of course, if we think this *should* work in principle (i.e., that it makes sense for this to be meaningful RTL), and we don't know that it doesn't work, it's reasonable to put this into GCC, changing the documentation to specify the semantics of this form of RTL, and then fixing any bugs as they occur. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: license copyright patch to MELT for dual GPLv3+ GFDL1.2+
Basile Starynkevitch wrote: Meanwhile, I think we should try to make use of the fact that RMS is permitting auto-generated reference documentation (which I have been instructed not to call a manual) using JavaDoc/Doxygen tools. If we use those tools, and demonstrate their value, we're then in a stronger position to say how generation of actual manuals is important. What I don't understand is what is so special about Doxygen. Basile, there's nothing special about Doxygen. It's just an example of a tool that generates cross-reference information. I think you can reasonably distinguish the kind of thing that comes out of JavaDoc or Doxygen from a manual. If you don't know what kind of output JavaDoc and Doxygen produce, please go read about them for a while and look at some examples. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: license copyright patch to MELT for dual GPLv3+ GFDL1.2+
Basile Starynkevitch wrote: So I still don't understand why generating cross-reference documentation with Doxygen for C++ code is permitted, while generating cross-reference documentation witb ÂMELT for MELT code is prohibited. As far as I know, nobody said that. http://gcc.gnu.org/wiki/MELT%20tutorial?action=AttachFiledo=viewtarget=GCC-MELT--gcc-internals-snapshot.pdf That contains much more than cross-reference documentation! -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: plugin_is_GPL_compatible mangling
Joern Rennecke wrote:
#ifdef __cplusplus
extern C {
#endif
extern int plugin_is_GPL_compatible;
#ifdef __cplusplus
}
#endif
I think that's a good idea; I don't think that at this point we've made
any plugin compatibility guarantees. (In the future, I think we should
-- but only when we have a much more structured plug-in API.)
Also, the type we suggest in the documentation is int, but some people
might have choosen a different type to be on the safe side not to use GFDL
code (pasted from the manual) together with GPL code
extern int foo is not something that is going to be covered by
copyright; there's no expression in something like that. I don't think
anybody should be worried.
Thanks,
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
Auto-generated cross-references can be distributed under the GPL
The FSF has approved the inclusion of automatically generated cross-reference information (such as that generated by Doxygen, Synopsis, or JavaDoc) in GCC, using GPLv3 for that documentation, rather than the GFDL. There was no license issue in this regard; the question was a policy question. In particular: is it OK to have documentation that is not under the GFDL in GCC? Of course, this cross-reference documentation cannot be combined with GFDL documentation to form a single manual. But, if we want to generate/ship internal API documentation, or plugin API documentation, in this form, we can do so. (I understand, of course, that the libstdc++ team has been doing this for some time.) This explicit permission re. cross-references does not resolve the question of auto-generating parts of GFDL manuals, such as those containing documentation about target hooks or about command-line options. (For target hooks, we might wish to consider using the permission given above to generate a separate document, though.) I will continue to work on the GPL-GFDL issue as best I can, but my expectation is that getting general permission regarding use of GPL'd code to generate GFDL'd documentation, including the right for downstream recipients to regenerate the documentation, will take a long time. I'm disappointed to see these islands (GPLv2 vs. GPLv3 vs. GFDL) of code and documentation that cannot be combined, but that seems to be the state of the world. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Using C++ in GCC is OK
Joseph S. Myers wrote: I repeat my request from the RM QA for a guide for reviewers on how to detect hidden overhead in the presence of C++ features. When will a structure/class/union be larger than might be expected in C? When will C++ statements involve runtime overhead that might not be expected from equivalent C statements? I think you're being unnecessarily fearful. A C++ structure/class/union will be larger than the same data structure written in C iff (a) it uses virtual functions, (b) it uses virtual inheritance. The former adds exactly one pointer to the very beginning of the structure, independent of the number of virtual functions, and even if there is (non-virtual) inheritance. The latter is forbidden by Ian's proposed coding standards. So, you do indeed want to avoid virtual functions in small, plentiful objects, as it can make them much bigger. Statements in the C subset of C++ have the same performance they would in C. (I'm sure someone can come up with an exception, but it will be vanishingly rare.) In C++, you can of course make what looks like simple code do something expensive; for example, you can make a + b be arbitrarily complex if a and b are instances of class types and you have overloaded +. But, if you just recompile your C program as C++, it doesn't suddenly get significantly bigger or slower. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Using C++ in GCC is OK
Jeff Law wrote: In C++, you can of course make what looks like simple code do something expensive; for example, you can make a + b be arbitrarily complex if a and b are instances of class types and you have overloaded +. And, in general, we are trying to avoid situations where seemingly simple code does something expensive, right? Right. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: GFDL/GPL Issue
Dave Korn wrote: If Texinfo text is included the .h files specifically to be copied into a manual, it is ok to for you copy that text into a manual and release the manual under the GFDL. In context, you means the GCC maintainers and the permission would be limited only to changes contributed to the FSF. This is specifically not permission for random people to do even this outside the context of the FSF repository. So to be clear: would redistributors be in breach if they were to ship the generated docs in their binary packages? No, not if they ship the docs unmodified from the version from the FSF. They would also not be in breach if they themselves added some new text and regenerated the docs, since they can license their changes as they see fit (provided, of course, that's compatible with the GPL and GFDL). However, if I changed the code, but did not regenerate the docs, and you then picked up my changes, possibly made more of your own, and then regenerated the docs, *you* would be in breach. (Because my changes are only available to you under the GPL; you do not have the right to relicense my changes under the GFDL.) I find that consequence undesirable. In particular, what I did is OK in that scenario, but suddenly, now, you, are a possibly unwitting violator. (Yes, I have confirmed the above interpretation is correct directly with RMS.) Because this scheme depends not on a general license exception, but rather on particular power that the FSF has by virtue of owning the code, the ultimate downstream recipient cannot be guaranteed that they can rebuild the documentation. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: GFDL/GPL Issue
Richard Kenner wrote: However, if I changed the code, but did not regenerate the docs, and you then picked up my changes, possibly made more of your own, and then regenerated the docs, *you* would be in breach. (Because my changes are only available to you under the GPL; you do not have the right to relicense my changes under the GFDL.) Just to be clear, I don't believe that regenerating the docs itself would be a breach since NOTHING you do internally can be a GPL or GFDL breach). What would be a breach would be *distributing* those regenerated docs. Indeed; I was too casual in my description. Dave can regenerate the docs, and even pass them around his company, but he can't distribute them. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: GFDL/GPL Issue
Matthias Klose wrote: I will state explicitly up front a few topics I am not raising, because I do not think they are either necessary, or likely to be productive: * Whether or not the GFDL is a free license, or whether it's a good license, or anything else about its merits or lack thereof Maybe, but GFDL is not GFDL. Please could you clarify if such documentation is licensed under a GFDL with frontcover/backcover texts and/or invariant sections? GCC's current documentation does have some of these things on at least some manuals. Would any of these clauses even make sense for this kind of documentation? To the extent that we'd be auto-generating parts of existing manuals, I think such sections make as much sense as they do now. For example, were we to auto-generate a list of command-line options for the main GCC manual, replacing the current hand-generated list, there would be no reason to change any of the invariant sections, etc. For API documentation, or, in general, for new manuals, I have no opinion. My guess, though, is that the FSF would want the same invariant sections and such as are on the existing manuals. (If it were up to me, manuals would just be GPL, whether or not that's a great license for documentation. But, it's not up to me.) -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: GFDL/GPL Issue
Dave Korn wrote: Just to be clear, I don't believe that regenerating the docs itself would be a breach since NOTHING you do internally can be a GPL or GFDL breach). What would be a breach would be *distributing* those regenerated docs. Indeed; I was too casual in my description. Dave can regenerate the docs, and even pass them around his company, but he can't distribute them. Well, I can't say I like this idea. The whole scheme seems laden with unforeseen potential booby-traps. I agree. However, to convince RMS that this isn't sufficient, I need to explain this is in a way that shows that this solution is a problem *for the FSF*. (The fact that the FSF has special superpowers that other parties don't isn't something the FSF considers a problem; the FSF wants people to assign code to them in part precisely so that it can change the licenses at will. I think RMS does recognize that this issue for distributors is a problem in this situation, though. He also doesn't feel that he can get a license exception very quickly, though, if at all.) -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Using C++ in GCC is OK
Richard Earnshaw wrote: I think virtual functions are on the edge; quite useful, but do result in the compiler adding a pointer to data objects and in uninlinable indirect calls at run-time. Therefore, I would avoid them in the initial subset of C++ used in GCC. We do, of course, have one very big 'virtual function' table in gcc -- namely the target hooks. It would be a shame if that couldn't be made into a proper class with virtual functions by some arbitrary rule -- it's a perfect example of when they should be considered. Ian has bravely taken on the task of C++ coding standards and he's more liberal than I am with respect to the subset to use. (That suits me fine, since I like virtual functions fine, and now I don't have to feel guilty about stuffing them down anybody's throat.) So, anyhow, it looks to me as if current consensus is trending in the direction you suggest... -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Using C++ in GCC is OK
Ian Lance Taylor wrote: I have written a proposed set of C++ coding conventions on the wiki at http://gcc.gnu.org/wiki/CppConventions This is only a preliminary proposal. It requires fleshing out and discussion. Thank you for volunteering to do this. How would you like to receive comments? Directly on the Wiki page, or by email? Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Using C++ in GCC is OK
Richard Guenther wrote: Btw - can we intially just link with libsup++ omitting libstdc++ so that we do not get the expected flood of convert-to-STL patches? Or is the idea of an STL free gcc bad? I view STL as one of the bits of low-hanging C++ fruit. I think we're all vaguely confused by the VEC APIs, for example; using std::vector seems much better. And, using those kinds of things doesn't require a lot of knowledge of C++ arcana, even if the implementations may use some of that arcana. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
GFDL/GPL Issue
As I mentioned last week, I've been talking to the SC and RMS about the issue of automatically generating GFDL'd documentation from GPL'd code. I will state explicitly up front a few topics I am not raising, because I do not think they are either necessary, or likely to be productive: * Whether or not the GFDL is a free license, or whether it's a good license, or anything else about its merits or lack thereof * Whether we can take things out of the current GFDL manuals and put them into GPL'd code The first is immaterial from the limited perspective of trying to figure out how to make it possible for us to make better (in terms of content) manuals more easily. The second issue *is* relevant, in that we might want to bring some of what's currently in manuals into the code, but I think it's less important than the question of whether we can auto-generate manuals from code on a going-forwards basis. And, it's simpler to work on one thing at a time. At this point, RMS has said, answered this question from me: Can we take comments (not code) from FSF-owned GPL'd code and process them in some way that results in them being included in a GFDL'd manual? by saying, in part: If Texinfo text is included the .h files specifically to be copied into a manual, it is ok to for you copy that text into a manual and release the manual under the GFDL. In context, you means the GCC maintainers and the permission would be limited only to changes contributed to the FSF. This is specifically not permission for random people to do even this outside the context of the FSF repository. RMS acknowledges that this is a problem, but he says (and I agree) that we would need a GPL license exception to make this a fully general permission, and he says that will take a long time. This limited permission might be enough to solve some problems. For example, we could write TeXinfo in special comments for hooks, and have some script that pulled out the comments and generated a TeXinfo document listing all the hooks. But, it doesn't help with things more like Javadoc or Doxygen or Synopsis. (Disclosure: Stefan Seefeld, one of my fellow Sourcerers is the lead author of Synopsis.) These tools can parse the code, creating cross-references of various kinds, while also extracting documentation intended for users of the API. So, my question is this: is the permission above sufficient for what people want to do at this point? Or do we need more? And if we need more (as I suspect), can we be specific about what toolflow we want to follow and what content will be generated? It would help if I could show RMS inputs and outputs, not just with some random example, but with GCC itself. Is someone willing to apply enough effort to produce at least some fragments of documentation using some method, and document that method for me, so that I can provide it to RMS. (An obvious strategy generate these manuals under the GPL, rather than the GFDL, thereby dodging the issue. But, RMS does not want GCC having GPL'd manuals. Maybe if we show him what we want to do, he will conclude that GPL'd manuals are an acceptable outcome, and easier than trying to do license exceptions.) Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: GFDL/GPL Issue
Joern Rennecke wrote: And if we need more (as I suspect), can we be specific about what toolflow we want to follow and what content will be generated? It would help if I could show RMS inputs and outputs, not just with some random example, but with GCC itself. Is someone willing to apply enough effort to produce at least some fragments of documentation using some method, and document that method for me, so that I can provide it to RMS. See: http://gcc.gnu.org/ml/gcc-patches/2010-05/msg02255.html OK, I see what that is doing. Why did you choose to use a .def file rather than something more like Doxygen to generate the documentation? Consistency with existing practice of .def files in GCC? Or you don't like Doxygen-like tools? Or something else? (I'm not making a judgment here, but I need to understand why so that I can explain things to RMS.) Search for GPL and/or GFDL for a sample of things that we currently can't fix due to licensing issues. I'm happy to act as an advocate, but I don't have the time to do a lot of research. Would you please describe the steps and provide the inputs and outputs of the process for some of these issues? I want to able to show RMS an actual input file, an actual output file, and describe the transformation process that leads from one to the other. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Using C++ in GCC is OK
Eric Botcazou wrote: We do require long long for 32-64 cross compilers. Right, only in this case, and I don't see why this should be changed with the transition to C++, that's orthogonal. I agree. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Using C++ in GCC is OK
Basile Starynkevitch wrote:
At last, there is a very important issue when switching to C++. What is
our ideal class hierarchy? Do we aim at a large forest, or on the
contrary at a single tree of classes, so we have a single root class,
providing common services (dump or debug printing, serialization, ...)
or not?
There's no reason to get into these kinds of questions at this point.
The goal is not to reimplement GCC from the ground up using modern
OO/C++ techniques. The goal is simply to permit ourselves to use C++
features where appropriate in the codebase.
With respect to a class hierarchy, we already have inheritance in a few
places. For example, the tree data structures are inheriting from a
base class by doing things like:
struct tree_derived {
struct tree_base base;
/* derived fields here. */
};
It's natural to use actual C++ inheritance there. But, there's no a
priori reason to start making other things inherit from each other or
start trying to factor out base classes that we don't currently have,
unless it's actually demonstrably useful to do so.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
Re: Using C++ in GCC is OK
Basile Starynkevitch wrote: Except that perhaps these questions are important for any gengtype enhancement. In particular, one could consider that marking a GTY-ed data would be done by a virtual method (generated by gengtype), and then having every GTY-ed data inheriting from an abstract class providing this method will make both gengtype ggc*.c simpler. There is no pressing need for a gengtype enhancement as far as I can tell. I think the right way to look at this is that we can now use C++ going-forward to implement things, and that is helpful. In some cases, we'll want to convert existing things to C++ because that helps us to do new things. But, we don't need to convert things just because we can. We don't get a prize for having a tidier code base *in and of itself*. I think we should focus on some user-visible deliverable (better optimization, faster compiler, new language feature, plugin API, whatever). If converting something to use C++ helps achieve that goal, great. If it doesn't, then why bother? I'm not saying that we should reject clean-up patches that use C++ in some way that makes things notably tidier. I'm just saying that I'm more excited if I see how that patch is going to help us build new functionality. And, I think it's premature to start talking about particular changes to particular parts of the compiler. Step 1 is to agree on the subset of C++ we're willing to use. Step 2 is for someone to propose a C++-using patch that does something useful and get it approved. So far, I've seen a lot of input on Step 1, but nobody that wants to step up and take responsibility for the task. Any takers? -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Using C++ in GCC is OK
Jakub Jelinek wrote: I just really hope we will have strict criteria that any transition will not make compiler slower and will not increase compiler build time. Nor will grow the memory footprint, at least of the important data structures, or increase maintanance costs by making the code less readable, etc. There is no reason that use of C++ should increase the memory footprint of the compiler, make the compiler slower, or make the code less readable. Poor use of C++ might lead to those things; good use will not. That is why we need coding standards and patch review. It is likely that use of C++ will make the compiler build time somewhat longer since G++ is generally a bit slower than GCC and since parsing things like the C++ vector include file is certainly more expensive than parsing our own vec.h. (Precompiled header files may help, of course.) I would expect that this delta will be quite small in the scope of a complete compiler bootstrap, especially if you include building libstdc++ and/or libjava. As usual, we won't know for sure until we measure. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Using C++ in GCC is OK
Richard Guenther wrote: Oh - and we didn't yet decide to switch to C++ as implementation language. Did we? I'm not sure exactly what you're asking. We now have permission to switch. The reason we wanted permission to switch was that there was a consensus that we wanted to switch; as far as I know, we didn't want the permission just so that we could at some later point consider switching! I think we've decided to switch, but we haven't decided to what subset of C++ we're switching. I think that we want what might be called the syntactic sugar subset. For example, single inheritance to replace our C-style inheritance, constructors/destructors to replace explicit calls to required initialization/finalization functions, and member functions to implement ADTs, namespaces to save us some typing. None of these things impacts memory use, or run-time performance. Generally speaking, these are things that remove lines of code, help to prevent mistakes made by casting or forgetting to obey requirements of APIs, and make it easier to replace particular components without impacting large parts of the rest of the source code. The more exotic bits of C++ (RTTI, exceptions, virtual inheritance, templates, etc.) all involve the compiler doing a lot more implicit generation of data structures and code, including, in some cases, implicitly making data structures bigger. I think these techniques are valuable when used appropriately, but I wouldn't propose using them in GCC soon. It is easy to mis-use them and for them to have unintended consequences. I think virtual functions are on the edge; quite useful, but do result in the compiler adding a pointer to data objects and in uninlinable indirect calls at run-time. Therefore, I would avoid them in the initial subset of C++ used in GCC. (If we decide at some point, for example, that we want to be able to use multiple back-ends in a single compiler, then virtual functions are a good way of implementing that -- but we need to understand that there will be an indirection for every call to a back-end function. If that's too high a price to pay, then we won't want to do that. The point here is that use virtual functions should not be the goal; the goal should be multiple back-ends and then use virtual functions is just an implementation technique, with costs approximately equivalent to doing the same thing by hand in C.) I am certainly a C++ guy, and I feel that all these features have their place, but I think we should err on the side of using less of C++, rather than more. We have C code that works, and we have a group of developers comfortable in C. We lose if we break our code, and even more if alienate those developers. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Using C++ in GCC is OK
Gabriel Dos Reis wrote: There are good C++ coding standards out there, and I would be reluctant to encourage a NIH-driven design as opposed to adapting existing ones that have been given lot of considerations: http://www2.research.att.com/~bs/bs_faq2.html#coding-standard http://www2.research.att.com/~bs/JSF-AV-rules.pdf certainly there are elements there that are use for us to consider. I've already asked if someone wants to volunteer to put together coding standards. I'm happy for that to end up being some set of coding standards that already exist, whether Bjarne's, Google's, or whatever. I don't have any inherent desire to invent a completely fresh set of standards. On the other hand, as Bjarne says, the right subset is dependent on context. We're not in a safety-critical environment, we have a large existing C codebase, and we have a developer team made up of experienced C programmers, not all of whom are used to programming in C++. So, we need to take those factors into account. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: [RFC] Switching implementation language to C++
Diego Novillo wrote: By switch, do you using a C++ compiler to compile everything, or that some components may be written only in C++ with sufficient care that they can be linked with other part written in C? Ideally, the former. If we cannot get consensus on that, then I guess we'd have to settle for the latter. I don't think a partial conversion strategy will be very successful. As soon as we use C++ in tree.h, we're going to have to use it everywhere. And, I suspect that using single inheritance in tree.h is the sort of change that will cut down on a fair bit of casting, possibly helping us to invalid conversions. That doesn't necessarily mean that we have to use lots of C++ features everywhere. We can use the C (almost) subset of C++ if we want to in some places. As an example, if the Fortran folks want to use C in the Fortran front-end, then -- except to the extent required by the common interfaces, those files could read as if they were C code. But, I think they'd still need to be compiled with a C++ compiler because they'll probably pull in headers that use C++ constructs. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Using C++ in GCC is OK
Andi Kleen wrote: I think virtual functions are on the edge; quite useful, but do result in the compiler adding a pointer to data objects and in uninlinable indirect calls at run-time. Therefore, I would avoid them in the Is that still true given profile feedback and the recent devirtualization work? I would assume the common case to get inlined then anyways. I don't think we have enough evidence to make that a safe assumption. I would prefer to be conservative in making this transition; we have a consensus that we want to use C++, but quite a few people who are concerned about what that means in practice, and so I think we should make the transition slowly and carefully. Don't get me wrong; I think virtual functions are very useful. The target hooks and language hooks we have are essentially poor man's virtual functions, and we could naturally (and mechanically) convert them to actual virtual functions. That's why I think virtual functions are on the edge. If the consensus is that it's OK to use them now that's OK by me, but I'd prefer to keep them out of the initial set of coding guidelines. I would, however, expect that they will be one of the first advanced features to make their way into GCC in the future. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: [RFC] Switching implementation language to C++
Gabriel Dos Reis wrote: Yes, this is the sort of issues I have in mind. For example, I do not see how we can use C++ in tree.h without requiring other front-ends to use C++, at least for the parts that use tree.h. By components, I meant for example, is it the case that the C++ front-end would use C++, but with sufficient care that it can be linked with the common C codes if the C front-end is not using C++?. Yes, I think it's possible for a front-end or a back-end to use C++ without the rest of the compiler doing so. I doubt that's where we get maximum bang from allowing use of C++, but it could certainly be done. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: [RFC] Switching implementation language to C++
Gabriel Dos Reis wrote: OK, I will reformulate my question to you and Diego is: is this what we want, e.g. C++ as THE common implementation language, or just ONE common implementation language (the other being C)? I believe that we want (a subset of) C++ to be the language used to implement all of GCC, including front-ends, back-ends, and common code. Where we currently use C, we wish to instead use C++. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: possible license issue (documentation generated from source) in MELT branch of GCC
Basile Starynkevitch wrote: To my greatest extremely positive surprise, I got today an answer from the FSF (I really am very happy of such a quick answer)! I hope it OK to cite here part of the reply I've got to my question [gnu.org #579118] to licens...@fsf.org since Karl Berry replied to me From RMS' comments on the SC list, I'm not sure if Karl had full context. His answer is certainly reasonable as an explanation of how you could create a project that had GPL'd code and GFDL'd manuals. Whether or not it's an answer to how the FSF wants to deal with the code it owns, however, is not obvious to me. I have asked RMS to clarify. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: [RFC] Switching implementation language to C++
Basile Starynkevitch wrote: You forgot to mention plugins. In my understanding, any future GCC plugin would necessarily be coded in C++ and be compiled by a C++ compiler. Am I right? Not necessarily. If we felt it desirable, the interface exposed for plug-ins could be C, not C++. However, I would expect it would be better to expose a C++ API. We'll have to see what consensus emerges on that point. (I do not feel that plug-ins should have full access to GCC's internals; I want to see a structured API that permits plug-ins access to a documented, stable interface.) I would even imagine that later, one could configure GCC to have only a C++ front-end, but no more a C one. I suppose, though thinking about that doesn't seem a great use of time at this point. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: [RFC] Switching implementation language to C++
Geert Bosch wrote: If we're just going to get some new power tools for our workshop and let people have at it, the lessons we'll learn might end up being more about what not to do, rather than a show case of their effective use. That's why we're not doing that. Instead, we're going to determine what subset of C++ we're comfortable using, and then we're going to let people propose ways of using that subset. Nobody's suggesting letting people run around using their favorite C++ features in random ways. This is a chicken-egg thing. We couldn't reasonably ask people to start proposing ways of using C++ without knowing that the SC would allow it to be used. Now we've got that approval, and now people can suggest uses. I've already implicitly suggested one, namely, using single inheritance to implement the tree data structures, thereby avoiding casts up and down the hierarchy. Including, for example, declaring a routine that's supposed to take a DECL as taking a tree_decl, instead of just a tree *. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Using C++ in GCC is OK
I am pleased to report that the GCC Steering Committee and the FSF have approved the use of C++ in GCC itself. Of course, there's no reason for us to use C++ features just because we can. The goal is a better compiler for users, not a C++ code base for its own sake. Before we start to actually use C++, we need to determine a set of coding standards that will apply to use of C++ within GCC. At first, I believe that we should keep the set of C++ features permitted small, in part so that GCC developers not familiar with C++ are not rapidly overwhelmed by a major change in the implementation language for the compiler itself. We can always use more of C++ later if it seems appropriate to do so, then. For example, I think it goes without question that at this point we are limiting ourselves to C++98 (plus long long so that we have a 64-bit integer type); C++0x features should not be used. Using multiple inheritance, templates (other than when using the C++ standard library, e.g. std::listX), or exceptions also seems overly aggressive to me. We should use features that are relatively easy for C programmers to understand and relatively hard for new C++ programmers to misuse. (For example, I think constructors and destructors are pretty easy and hard to misuse.) Because C++ is a big language, I think we should try to enumerate what is OK, rather than what is not OK. But, at the same time, I don't think we should try to get overly legalistic about exactly what is in and what is out. We need information guidelines, not an ISO standard. Is there anyone who would like to volunteer to develop the C++ coding standards? I think that this could be done as a Wiki page. (If nobody volunteers, I will volunteer myself.) Whoever ends up doing this, I would urge the rest of us not to spend too much time in the C++ coding-standards bikeshed; we're not going to win or lose too much because we do or do not permit default parameters. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
GCC RM QA, C++ in GCC
Thanks to all who participated in the GCC Release Manager QA on IRC earlier today. Joseph Myers logged the chat session and will put it on the GCC Wiki soon. There were a lot of good comments and questions. Thanks especially to Richard Guenther and Joseph Myers who both accommodated my unilateral setting of the schedule for the chat. Unfortunately, Jakub had a conflict and could not attend. The consensus seemed to be that this was a useful discussion, so we will do it again in a month or two; I will announce a date soon. The issue of using C++ to build GCC itself came up again in the discussion. Although there is certainly not unanimity, there seems to be an overall consensus in the GCC developer community that limited use of C++ would be beneficial. That consensus was present today on IRC, present in previous email discussions on this list, and present at the GCC Summits over the past two years. Therefore, I've asked the SC for permission to do require a C++98 host compiler to build GCC. Once that permission has been obtained, we can then work on what coding standards are appropriate. My expectation is that we will limit use of C++ features at first quite strictly; for example, we might forbid use of virtual functions, or multiple inheritance, or overloading. But, we'll take advantage of some obvious benefits, like use of std::vector in lieu of VEC.h. I will report further once the SC discussion has reached a conclusion. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: GFDL/GPL issues
Frank Ch. Eigler wrote: c. change the licenses of the melt*texi files [I certainly won't do that without explicit approval] to something compatible. Perhaps the fact that I am the only contributor to these files might help. Would dual-licensing the .texi files (GFDL + GPL3) solve these problems? Presumably so, but we cannot unilaterally do that with source code that has been assigned to the FSF. The FSF assignment agreement generally allows the original contributor to relicense his/her own work under different terms, so Basile could (if he is the sole contributor) dual-license the MELT .texi documentation -- but it's not clear to me that this permits us to then take advantage of that in the context of FSF GCC. In the context of FSF GCC, there is both a legal question and a policy question; even if we can do it legally, is that what the FSF wants? That last consideration, of course, does not apply to not-FSF GCC, e.g., to a release that Basile does himself. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Target macros vs. target hooks - policy/goal is hooks, isn't it?
Ulrich Weigand wrote: So the question is: The goal is to have hooks, not macros, right? If so, can reviewers please take care to reject patches that introduce new macros? I don't know to which extent this is a formal goal these days, but I personally agree that it would be nice to eliminate macros. Yes, the (informally agreed) policy is to have hooks, not macros. There may be situations where that is technically impossible, but I'd expect those to be very rare. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: GFDL/GPL issues
Basile Starynkevitch wrote: My dream [I'm not sure it can happen] would be that some GCC steering committee member would just say here to me that dual-licensing such and such files is permitted and would solve any issue. If I had such a informal blessing I would be ok. The SC cannot do that in the context of FSF GCC, and, of course, the SC has no control of any other GCC. This is the downside of copyright assignment; it gives the FSF a lot control over licensing issues. If you don't want to give the FSF that control, you can't assign copyright to the FSF. But, that also means you can't contribute to FSF GCC. Of course, in the context of plug-ins, you'd have more options, in that you could develop and independently distribute a plug-in where you had more control of licensing. The plug-in would have to be GPLv3-compatible, but you'd be able to dual-license the code in the plug-in if you chose to do that. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: GFDL/GPL issues
Basile Starynkevitch wrote: Does the FSF want anything about GCC? AFAIK, the plugin exception to the runtime license was not wanted by the FSF. It was only wanted by the GCC community (and probably the FSF was reluctant to any changes). I don't speak for the FSF. I don't know what the FSF wants, other than what it's said in public. So what should I do concretely? What is the current status of the pdf file generated inside GCC MELT, an old version of which is on http://gcc.gnu.org/wiki/MELT% 20tutorial?action=AttachFiledo=viewtarget=GCC-MELT--gcc-internals-snapshot.pdf Is it completely illegal? I don't know. I don't know enough about Melt to give an answer, even an informal one. (And I'm not a lawyer, so I certainly couldn't give you good legal advice.) Does that mean that even if a MELT plugin package appears in Debian, it could not contain any documentation? I thought Debian didn't like the GFDL at all. But, in any case, that's really a question for the Debian folks; I don't have any involvement in Debian. As for practical advice regarding getting quicker decisions from the FSF on licensing issues, I have none. I've worked on several such issues with the FSF over the years, and they've all been lengthy processes. If I knew how to do it faster, I certainly would. The best way to work with the FSF on license issues is always to explain how whatever request you are making furthers the FSF's goals. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: [patch] Remove TARGET_ADDR_SPACE_KEYWORDS target macro
Ulrich Weigand wrote: * c-common.h (c_register_addr_space): Add prototype. (ADDR_SPACE_KEYWORD): Remove. * c-common.c (c_register_addr_space): New function. (c_addr_space_name): Reimplement. (c_common_reswords): Do not include TARGET_ADDR_SPACE_KEYWORDS. * config/spu/spu.h (TARGET_ADDR_SPACE_KEYWORDS): Remove. (REGISTER_TARGET_PRAGMAS): Call c_register_addr_space. * doc/tm.texi (Named Address Spaces): Mention c_register_addr_space. Remove TARGET_ADDR_SPACE_KEYWORDS. OK. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: GFDL/GPL issues
Basile Starynkevitch wrote: The best way to work with the FSF on license issues is always to explain how whatever request you are making furthers the FSF's goals. [not being a native english speaker, I had lots of trouble understanding the last sentence above; apparently, according to my RobertCollins english-french dictionnary applied twice, to further means to favour in that context; is that understanding the right one?]. I would that to further in this context means to advance. If you show the FSF how some change will help the FSF achieve its goals, then they will generally consider it. First, I have no idea of who the FSF really means (except RMS). Me neither. I usually contact RMS directly because ultimately he seems to make most of the decisions about these things, often after getting input from the SFLC and probably other people I don't know about. Are there any reason for which I should expect more attention now? I don't understand why a question nobody cared about on May 7th should become interesting on May 27th of the same year (2010). If you can't explain to the FSF why a license change will help the FSF achieve its goals, I'd expect that your request will be ignored. The discussion I started with RMS at Joseph's behest was not about MELT. It was about the general issue of generating documentation from code. I wasn't aware it had anything to do with MELT. And there is one even more basic thing I don't understand. Why are GFDL GPL incompatible? I suggest you search the internet for the answer; there's a lot of discussion about this out there. I don't understand the full situation with MELT. But, you cannot combine GPL'd and GFDL's stuff, so I don't think you can auto-generate GFDL documentation from GPL'd code on the MELT branch. You could generate GPL'd documentation, though. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: GFDL/GPL issues
Joern Rennecke wrote: Well, then we were still kind of hoping the FSF would come up with a useful policy that allows using copyrightable elements from the code to be used in its documentation, and vice versa. However, now it doesn't look like that such a policy is forthcoming in a timeframe relevant to current GCC development. I did get a response from RMS today, within about 24 hours of the mail I sent him yesterday. But, the response was a request for more information, not a commitment to doing anything. I'm also at a loss why the GNU package maintainers ... cannot authorize to put pieces of GPLed code/documentation under the GFDL, or pieces of GFDLed code under the GPL, as long this is done in order to pursue the goals set out in the above documents. AFAIK, as a GNU maintainer, I don't have the right to bind the FSF in any legal manner. I don't think I have the right to dual-license GPL'd code under the GFDL any more than I have the right to license it under the BSD license or the CodeSourcery Super-Sekrit Proprietary License o' Doom. Allowing dual-license of GPL'd code under GFDL might further the interests of the FSF (and, in fact, I've argued to RMS that at least in the context of GCC it would do so), but I don't think any of us have the right to do that without the FSF's permission. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: GFDL/GPL issues
Matthias Klose wrote: there is another issue with the manual pages. It would be nice to know if the files used to generate the manual pages (gcc/doc/invoke.texi, gcc/fortran/gfortran.texi, gcc/java/gcj.texi) could be dual-licensed as well, so that is possible to provide basic documentation in Debian as well. I could ask that question, but I don't know how to do so in a way that is likely to get the desired answer. The FSF considers the GFDL meritorious, and, as far as I can tell, doesn't care whether that inconveniences Debian. So, I don't know how to make the argument that this change helps the FSF. I've argued that allowing GFDL documentation to be extracted from GPL'd code, and allowing the current GFDL text in the manuals to be placed into comments in GPL'd code, is a win in that it reduces developer effort and improves the quality of the product -- but I can't argue that this is true for the manual pages. But, if we could get the documentation for command-line options into GPL'd code in a structured way, then I think you could probably generate GPL'd manual pages from that. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: GFDL/GPL issues
Steven Bosscher wrote: Would it help to include in this more information to emphasize that the issue is especially urgent for internals documentation? I think I've expressed that reasonably well, with help from Jason Merill and Toon Moene. I gave examples involving both the internals manuals (e.g., target hooks) and the user manual (e.g., command-line options). I've not raised any of the Debian issues with RMS and don't intend to do so; I will not convince the FSF by making this into an argument about whether the GFDL is a good license. I'm trying to focus on use of the GPL'd code in GFDL manuals and vice versa, particularly in the context of GCC's manuals, as a way of reducing developer effort and improving the documentation. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
