Thank you!

contributions and your community gave me the opportunity to have a ton of fun. Thank you, -- Mark Mitchell

GCC Release Management

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

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

Re: Make C1X anonymous structs/unions follow N1549

-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

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

Re: PR debug/47510

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

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

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

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

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

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

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?

people think about this idea? Thank you, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: Mailing lists for back-end development?

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

Re: Discussion about merging Go frontend

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

/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

Re: Discussion about merging Go frontend

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

reading libraries. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: Discussion about merging Go frontend

with using elfcpp over libelf. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: Discussion about merging Go frontend

that this would be desirable? -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: Discussion about merging Go frontend

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

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

Re: check_cxa_atexit_available

-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

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

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

Re: End of GCC 4.6 Stage 1: October 27, 2010

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

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

Re: Add uninitialized attribute?

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

Re: Add uninitialized attribute?

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

Re: Add uninitialized attribute?

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?

not initializing i. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: GFDL/GPL issues

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

, 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

Re: GFDL/GPL issues

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

Re: GFDL/GPL issues

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

Re: GFDL/GPL issues

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

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

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

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

my permission! -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: GFDL/GPL issues

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

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

Re: GFDL/GPL issues

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

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

Re: GFDL/GPL issues

, 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

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

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

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

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

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

Re: Plug-ins on Windows

, 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

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

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

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

Re: Deprecating ARM FPA support

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

Re: ChangeLog licensing issues

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

Re: subreg against register allocation?

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+

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+

/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

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

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

Re: Using C++ in GCC is OK

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

seemingly simple code does something expensive, right? Right. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: GFDL/GPL Issue

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

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

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

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

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

Re: Using C++ in GCC is OK

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

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

. 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

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

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

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

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

if alienate those developers. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: Using C++ in GCC is OK

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

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

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

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

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

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

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

. 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

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

; 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

Re: GFDL/GPL issues

, 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?

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

-in if you chose to do that. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

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

Re: [patch] Remove TARGET_ADDR_SPACE_KEYWORDS target macro

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

Re: GFDL/GPL issues

branch. You could generate GPL'd documentation, though. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713

Re: GFDL/GPL issues

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

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

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

  1   2   3   4   5   6   7   8   9   10   >