Re: [PATCH][RFC] Adjust the middle-end memory model

dependence > which we cannot exclude in this case (no TBAA is allowed here). By "not allowed", you don't mean "would be an invalid optimization", but rather "will no longer be done by GCC", right? -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: bitfields: types vs modes?

uld sure be nice if it was; it maps directly onto how people think about memory-mapped peripherals. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: [PATCH][RFC] Adjust the middle-end memory model

optimization; clearly we need to be correct first and foremost. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: bitfields: types vs modes?

the container of a non-volatile bit-field overlaps a volatile > bit-field then it is undefined whether access to the non-volatile > field will cause the volatile field to be accessed. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: [PATCH][RFC] Adjust the middle-end memory model

Richard Guenther wrote: > Yes, that's the primary motivation of this patch. Can I take this > as an approval for the C++ frontend changes? OK. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: Should -Wjump-misses-init be in -Wall?

don't think that trying never to emit new errors with -Wall is a sensible kind of backwards compatibility. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Graphite Merge Expected in Mid/Late July

iscussing those issues on the mailing list as soon as possible so that we have everything ready when the time comes. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: C++0x Memory model and gcc

ferent threads may break > unpredictably. > -fmemory-model=safe > The compiler will do its best to protect you. That makes sense to me. I think that's an appropriately user-oriented view of the choices. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: [RFC] Introduce -Ofast

definitely should not. As a user, I don't want to know about the option; I just want -O3 to generate fast code. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: ARM Neon Tests Failing on non-Neon Target

Richard Earnshaw wrote: > Speaking of which, we should probably formally deprecate the old arm-elf > derived targets in 4.6 so that we can remove them in 4.7. > Similarly, we should deprecate support for the FPA on ARM. I agree. -- Mark Mitchell CodeSourcery m...@codesourcery.com

Re: arm-elf float-abi defaults...

doesn't mean that we shouldn't try to get the defaults to match up, but making it explicit is the right thing to do. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: arm-elf float-abi defaults...

xist in arm-elf, then you should be able to use it there too. But, of course, arm-elf is really a dead ABI at this point... -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: arm-elf float-abi defaults...

4.6. I think that's reasonable; most of the major operating systems (not just GNU/Linux, but embedded operating systems too) have switched to the EABI, not just for compatibility with one another, but because it's technically superior. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: arm-elf float-abi defaults...

it isn't, then you can either punt on arm-elf, or enable some EABI functionality there. If, on the other hand, you think there's a problem when using the EABI, then we should talk about how to solve it. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

RM Q&A Session on May 27th

ons to: http://gcc.gnu.org/wiki/Release%20Manager%20Q%26A We'll try to give somewhat intelligent answers to those questions, as well as to those asked live. Thanks! -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: RM Q&A Session on May 27th

atever else is being discussed. It would also probably be better if it were a moderated discussion so that everyone doesn't talk at once. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: RM Q&A Session on May 27th

- to build plugin infrastructure?" One of my current goals is to understand what things are possible in GCC and to drive funding for those features. I gave a talk at the Linux Foundation Collaboration Summit recently where I specifically highlighted plugin infrastructure and link-time/w

Re: powerpc-eabi-gcc no implicit FPU usage

ccept it. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: powerpc-eabi-gcc no implicit FPU usage

e legacy source code problem, and also the problem that you can't mix code within a file, which does sometimes have performance advantages. (For example, because calls to static functions need not have the standard ABIs.) -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: powerpc-eabi-gcc no implicit FPU usage

, we might be able to get that into 4.6. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: Deprecating ARM FPA support (was: ARM Neon Tests Failing on non-Neon Target)

7;s not an argument for not *deprecating* them. We may as well deprecate them now, and then we can remove them later. The actual removal won't happen until at least 4.7, which is probably another couple of years away. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: Deprecating ARM FPA support

t here we're talking about deprecating a feature; whether to remove it is an independent decision for later. I think deprecation of FPA is reasonable; at what point removal is reasonable isn't something we have to answer until *at least* the 4.7 release cycle. -- Mark Mitchell CodeSourcery

Re: Deprecating ARM FPA support

's good evidence that nobody really cares about new versions of GCC supporting these things. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: Where does the time go?

g gained more cheaply in other ways - than because of > intrinsic technical obstacles. I completely agree. This is a tractable problem, approximately on the same scale as GIMPLE tuples. I would guess approximately a person-year, perhaps spread out over a longer time. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: Where does the time go?

tion for RTL doesn't really help you. I'd accept either set of patches, if someone were to provide them. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: Help needed: banishing RTL from the front ends

easonable plan to me. It will, of course, take some work to achieve, but in concept I completely agree that the front ends should have no knowledge whatsoever of RTL. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

GFDL/GPL issues

r two), I'd suggest that we operate under the assumption that it will not be possible to combine GFDL manuals and GPL code in the near future. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

RM Q&A Session on irc.oftc.net

eing asked by people who will apparently be unable to participate. We'll try to answer those as breaks in the conversation occur. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: GFDL/GPL issues

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?

y 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

, 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

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

Re: [patch] Remove TARGET_ADDR_SPACE_KEYWORDS target macro

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

Re: GFDL/GPL issues

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

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

ves 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

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

GCC RM Q&A, C++ in GCC

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

Using C++ in GCC is OK

uld 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

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

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

e 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

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

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

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

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

Re: Using C++ in GCC is OK

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

hat'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++

e 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

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

e.) > 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++

e 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

Re: Using C++ in GCC is OK

uld 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

ly 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

MS. (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

eps 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: GFDL/GPL Issue

ly 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

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

t 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

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

t.) 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

Auto-generated cross-references can be distributed under the GPL

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

Re: Using C++ in GCC is OK

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

"+". >> > 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: plugin_is_GPL_compatible mangling

ith 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

Re: license & copyright patch to MELT for dual GPLv3+ & GFDL1.2+

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

; http://gcc.gnu.org/wiki/MELT%20tutorial?action=AttachFile&do=view&target=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: subreg against register allocation?

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: ChangeLog licensing issues

; 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

Re: Deprecating ARM FPA support

r policy is that we can't remove it. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: Patch pinging

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

Re: Plug-ins on Windows

tart 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

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

ht 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

ARM GNU/Linux has replaced ARM EABI on primary platform list

ch 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

Re: Triplet for ARM Linux HardFP ABI

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

adly 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

Re: GFDL/GPL issues

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

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

ual, 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: GFDL/GPL issues

e 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...@c

Re: GFDL/GPL issues

e 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

. 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

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

st 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

x27;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 Q&A: August 5th

will be unable to attend, and we will try to address those questions during the Q&A 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)? Than

Re: GCC RM Q&A: 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

t 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

F'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: GFDL/GPL issues

learly that he thinks that you *cannot* do this? -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: GFDL/GPL issues

uggest that we do that in the context of FSF GCC? -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: GFDL/GPL issues

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

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

Re: Add uninitialized attribute?

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 t

Re: Add uninitialized attribute?

to indicate that you were knowingly not initializing i. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: Add uninitialized attribute?

the programming model in C++. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: Add uninitialized attribute?

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

. Thank you, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

<    3   4   5   6   7   8   9   10   11   12   >