Thank you!

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

Re: RFC: Make dllimport/dllexport imply default visibility

directly above, but not the dllimport case. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC Status Report (2007-06-15)

on Linux/PPC, which uses DPD encoding, and Linux/x86, which uses BID encoding. So Intel BID patch only affects Linux/x86 as it changes libgcc/Makefile.in to use Intel BID library. Who has the final say on this patch? The build system maintainers and the x86 maintainers. -- Mark Mitchell

Re: Activate -mrecip with -ffast-math?

can assume the output isn't a NaN or an Inf, it can freely switch one and the other. If -fno-finite-math-only is specified, then the generated code should do the right thing if an argument or result is inf or NaN. Also agreed. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: New LTO branch ready

not to That's great, thanks. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.3.0 Status Report (2007-06-07)

preparing patches against mainline for those bits. How does that sound? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.3.0 Status Report (2007-06-07)

-controversial, and can go into mainline in real time, which is nice. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: RFC: Make dllimport/dllexport imply default visibility

in practice. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: A reload inheritance bug

on all code I've tried - does it fix your test case? Mark, did you get a chance to try Bernd's patch? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: ppc64 __attribute__((visibility (hidden))) and multiple TOCs

my two cents; the Power maintainers might have a different take. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: ppc64 __attribute__((visibility (hidden))) and multiple TOCs

in default_binds_local_p_1. A DECL_EXTERNAL entity never binds locally. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: ppc64 __attribute__((visibility (hidden))) and multiple TOCs

be using DECL_REPLACEABLE_P). So, perhaps binds_local_p needs to return a tri-state value. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: ppc64 __attribute__((visibility (hidden))) and multiple TOCs

the contents of the function. So, I guess that just means that the Power back end needs to check for !DECL_EXTERNAL in addition to binds_local_p? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: ppc64 __attribute__((visibility (hidden))) and multiple TOCs

David Edelsohn wrote: Mark Mitchell writes: Mark Good point -- if there's no definition in the current translation unit, Mark then I guess we aren't going to make any bad assumptions about the Mark contents of the function. So, I guess that just means that the Power Mark back end needs

LTO reader support for MEMORY_PARTITION_TAG

would like to be able to begin pushing forward on getting small functions to go through the compiler. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: LTO reader support for MEMORY_PARTITION_TAG

in at this point. Would you care to take a try at that? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Status of trunk freeze

something which is just as important as people who are contributing new optimizations. I will be sending out a status report shortly. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.3.0 Status Report (2007-06-29)

on closing regressions. Danny, I would still appreciate your help in setting up additional fields in Bugzilla that we can use to help make people aware of regresions that they have caused Previous Report: http://gcc.gnu.org/ml/gcc/2007-06/msg00411.html Thanks, -- Mark Mitchell CodeSourcery [EMAIL

Re: RFC: Make dllimport/dllexport imply default visibility

to say. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: RFC: Make dllimport/dllexport imply default visibility

. It seems unlikely to me that RealView would add the visibility attribute but disallow usage that is valid with the __declspec syntax, but, of course, I can't speak for ARM. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.2.1 Status Report (2007-07-03)

-- P1: 29 P2: 113 P3: 2 Total: 144 Previous Report --- http://gcc.gnu.org/ml/gcc/2007-05/msg00670.html -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: RFC: Make dllimport/dllexport imply default visibility

Geoffrey Keating wrote: On 03/07/2007, at 7:37 PM, Mark Mitchell wrote: Geoffrey Keating wrote: Yes. __attribute__((visibility)) has consistent GNU semantics, and other features (eg. -fvisibility-ms-compat, __dllspec) match other compilers. The only semantics that make sense

GCC 4.2.1 RC1

will be frozen in preparation for the release. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: flag_complex_method = 2 in C++?

. And, users can use -ffast-math to get the performance back -- in all languages, uniformly. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: flag_complex_method = 2 in C++?

, but not for C89 or C++, but can be overridden by -ffast-math or -fcomplex-method. * Method 2 is the default for C99 and all variants of C++, but can be overridden by -ffast-math or -fcomplex-method. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.2.1 Status Report (2007-07-10)

-aliasing ... Priority# Change from Last Report --- - --- P1 21 -8 P2 113 0 P3 3 +1 Previous Report --- http://gcc.gnu.org/ml/gcc/2007-07/msg00062.html -- Mark Mitchell CodeSourcery

Re: GCC 4.2.1 Status Report (2007-07-10)

don't want to do that -- but thanks for working on the PR. If you can do some performance testing up front, then I might consider it for a post-RC2 inclusion, even if it means an RC3. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

RFH: GPLv3

being GPLv3. If you have thoughts about that, you might wish to contact the FSF. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: RFH: GPLv3

if we accidentally make something V3 than it will be to go forward to V3 if we miss something. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: RFH: GPLv3

list! But, if there's a clear consensus here, I'm fine with that. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.2.1 RC2

remains frozen to all changes, without my explicit permission. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GPL exception for fptr.c and milli64.s

with the change. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

4.2 branch frozen for release

I plan to spin the GCC 4.2.1 release tomorrow. Please do not make any further changes to the branch. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.2 branch open

The GCC 4.2 branch is now open under the usual release branch rules. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Should gcc/DEV-PHASE in gcc 4.2 branch be updated?

H.J. Lu wrote: According to gcc/ChangeLog, gcc 4.2.1 was released on 2007-07-19. Shouldn't gcc/DEV-PHASE in gcc 4.2 branch be marked as prerelease? I've now updated BASE-VER and DEV-PHASE. Good catch, thanks! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Semicolons at the end of member function definitions

for this case. The previous patch removed semicolons from lots of valid code, but probably none of those test cases were specifically for this case. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: [RFC] Migrate pointers to members to the middle end

. Michael and Danny have expressed opinions; does anyone else have one? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: [RFC] Migrate pointers to members to the middle end

., with the strategy that Daniel is advocating), we don't do some optimization that we could in theory do. Have you worked out why not? Perhaps that would shed some light on whether or not it's tractable to recover this information from our current IR. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED

Re: GCC 4.3.0 Status Report (2007-06-29)

a target milestone, unless I've explicitly marked them that way, at some point. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713 Index: index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v retrieving

GCC 4.3.0 Status Report (2007-08-09)

and exciting bugs, and we need to fix those. Do we need another 1-week stabilization period? Previous Report --- http://gcc.gnu.org/ml/gcc/2007-06/msg00954.html -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: [RFC] Migrate pointers to members to the middle end

of it, and see what, if any, limitations pop up. Yes, I agree. Again, thank you for being patient with the process. Let me know when you're at the point where you'd like me to review the front-end lowering patch again; send me a URL, and I'll be happy to do so. Thanks, -- Mark Mitchell

Re: GCC 4.3.0 Status Report (2007-08-09)

the checker happy? If the latter, have you measured the compile-time and memory usage to see what impact that has? We'd like to avoid making the compiler slower just to make the checker happy -- but, of course, it might be worth a small hit to get the checking benefit. Thanks, -- Mark Mitchell

Re: recent troubles with float vectors bitwise ops

platforms, but that's no worse than using intrinsics. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: recent troubles with float vectors bitwise ops

. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: recent troubles with float vectors bitwise ops

Andrew Pinski wrote: On 8/24/07, Mark Mitchell [EMAIL PROTECTED] wrote: Let a and b be floating-point operands of type F, where F is a floating-point type. Let N be the number of bytes in F. Then, a | b is defined as: Yes that makes sense, not. I'm not following. Are you agreeing

Re: recent troubles with float vectors bitwise ops

flip some bit in the x86 backend. Totally agreed. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: PING SC members [was RE: RFA: GCC 4.2.1: Stabalizing coalesce_list's qsort]

Dave Korn wrote: On 23 August 2007 22:34, Mark Mitchell wrote: I do think that generating the same code, independent of host system, is a very important property of GCC's design, just like generating the same code independent of whether or not we're compiling with -g. Hear, hear

Re: Stage 2 project: upgrade decNumber

; I'd probably do the C++ comments and leave it at that, just to ease future merges. But, that's just my two cents. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

RFC: Hack to make restrict more useful

to call a function argument_noalias() which will return an int with the same meaning as flag_argument_noalias. Does that plan sound OK to folks? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Stage 2 project: new interference graph representation.

cases can save a significant amount of memory. That sounds exciting. If you can get it done, and the middle-end maintainers feel confident in the code, it's fine by me. Thanks for the heads-up! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: RFC: Hack to make restrict more useful

it. Do you agree? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: RFC: Hack to make restrict more useful

was curious on the status of Dannys work and if it would obsolete what you propose. OK, great. Here's a draft patch for the trick; this works on the test case I had, and I'll be testing it now. If it passes testing, and I add testcases, does this look OK to you? Thanks, -- Mark Mitchell CodeSourcery

Re: RFC: Hack to make restrict more useful

, I'll finish up testing and wait for Danny's comments. Thanks! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: RFC: Hack to make restrict more useful

alias when they can. Indeed. The most obvious example is: return a != b; If the compiler knows the pointers don't alias, the compiler will happily, but wrongly, fold that to 1. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: RFC: Hack to make restrict more useful

should consider my patch withdrawn. Although, if the new meaning of restrict matches standard Fortran semantics, then our Fortran handling must be wrong, since all my patch did was make us match our current Fortran semantics. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331

GCC 4.2.2 Status Report

regressions) down. Previous Report === http://gcc.gnu.org/ml/gcc/2007-07/msg00704.html -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.3.0 Status Report (2007-09-04)

different bugs too, but those are all fixed in 4.4 and so forth. Previous Report === http://gcc.gnu.org/ml/gcc/2007-08/msg00181.html -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.3.0 Status Report (2007-09-04)

DJ Delorie wrote: Mark Mitchell [EMAIL PROTECTED] writes: Are there Stage 1 or Stage 2 patches in need of review? Do you want the diagnostic pragma push/pop patch in? In, if it works. :-) URL, please? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.2.2 Status Report

Joseph S. Myers wrote: On Tue, 4 Sep 2007, Mark Mitchell wrote: One critical issue: has GCC 4.2.x been fully converted to GPLv3, at this point? If not, we'll have to wait until that is done before we can release, per the FSF's instructions. Apart from anything else, we are still awaiting

Re: GCC 4.3.0 Status Report (2007-09-04)

the push/pop stuff fully reliable, including warnings emitted from the middle-end. That's not an over-my-dead-body; if other people feel differently, I'm happy to discuss. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: [RFC] missing return warnings

possible bugs in their software, not just the ones that affect them in their current configuration, depending on how much optimization applies, etc. If we want the middle end to warn about this kind of case, we should make sure that it does so for all functions, used or not. -- Mark Mitchell

Re: [RFC] missing return warnings

made unconditional: ... With the noreturn warning disabled completely: ... So it seems to be all about those warnings now. OK, that sounds pretty encouraging. Thansk, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: [RFC] missing return warnings

was being instantiated so that we could inline it. Now, that's probably no longer true. We can probably always avoid the deep stack, and just let cgraph handle it. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.3.0 Status Report (2007-09-04)

from when we're operating under -O2? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.3.0 Status Report (2007-09-04)

Rask Ingemann Lambertsen wrote: On Tue, Sep 04, 2007 at 07:40:19PM -0700, Mark Mitchell wrote: Are there Stage 1 or Stage 2 patches in need of review? I'll do my best to either (a) convince someone to review them, or (b) review them myself. http://gcc.gnu.org/ml/gcc-patches/2007-08/msg02217

Re: [RFC] Marking C++ new operator as malloc?

, then it would be safe -- but less useful. Can we do better? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.3.0 Status Report (2007-09-04)

this? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.3.0 Status Report (2007-09-04)

be more concerned. Let me know. Thanks! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.3.0 Status Report (2007-09-04)

Jagasia, Harsha wrote: I still plan to submit a patch for the x86 target cost model tuning. Assuming that this isn't too dramatic, I'll leave approval of that during Stage 3 to the x86 back-end maintainers. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: [RFC] Marking C++ new operator as malloc?

don't know about, but in such a way that pointers in our source code are being laundered back to us. Perhaps we could have an ext/i_promise_i_will_not_define_new header, which you can include if you aren't overriding the operator... -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: [RFC] Marking C++ new operator as malloc?

suppose it's possible. Do we have any way to guarantee that aliasing information will not be used when analyzing pointer comparisons, but only when analyzing stores through pointers? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: [RFC] Marking C++ new operator as malloc?

. (Of course, they could be NULL if you called the nothrow variant, or another operator new declared throw().) We should optimize away things like: int *p = new int; if (!p) cerr Could not allocate memory\n; -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: [RFC] Marking C++ new operator as malloc?

it in the standard headers. I'm not arguing that the attribute is meaningless in C++, or does not apply to the libstdc++ implementation; I'm just arguing that putting it into new is not safe. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: [RFC] Marking C++ new operator as malloc?

for particular implementations of operator new. So, I don't think we can put any attribute to that affect in our standard headers. You need a command-line switch, macro, etc., for the user to use to say that they are using an implementation that meets the requirements. -- Mark Mitchell CodeSourcery

Re: [RFC] Marking C++ new operator as malloc?

Richard Guenther wrote: On 9/9/07, Mark Mitchell [EMAIL PROTECTED] wrote: But, I don't think that even the C meaning is safe in C++ for use with the library declaration of new. I'm also somewhat skeptical of the idea that we will never do any optimization on pointer comparisons. What design

Re: GCC 4.3.0 Status Report (2007-09-04)

for muddying the waters, then. Roger, thank you for reviewing. I'll leave Richard G., Roger, and Diego to work out what best to do; please let me know if I can help. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: [RFC] Marking C++ new operator as malloc?

in which *p does not alias *q fails to imply p != q, for p and q pointers of the same type, is a weird place to be. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.2.2 RC1

. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.3.0 Status Report (2007-09-04)

should consider GCC diagnostic a defined, machine-readable format and that we should modify it only in backwards-compatible ways. Or, make incompatible changes only under control of an option or environment variable. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: deadline extension for debug info project into GCC 4.3 stage3?

at it when you submit it and decide. However, in general, introducing churn for the sake of a feature that will be off by default isn't something that I would want to do. The more compartmentalized you make it, the better your chances are. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED

Re: GCC 4.3.0 Status Report (2007-09-04)

Peter Bergner wrote: On Tue, 2007-09-04 at 19:40 -0700, Mark Mitchell wrote: Are there Stage 1 or Stage 2 patches in need of review? I'll do my best to either (a) convince someone to review them, or (b) review them myself. It has only been four days since I posted the patch, but I am

Re: [RFC] Marking C++ new operator as malloc?

of reasons? Isn't the situation exactly analogous? I think I'm getting confused. Perhaps you could sum up in a single email the argument for why putting this attribute in our standard headers is safe, even in view of possible replacement in user programs? Sorry, -- Mark Mitchell CodeSourcery [EMAIL

Re: [RFC] Marking C++ new operator as malloc?

standard headers. I'd rather let people who know what they're doing put that in their own headers if they want to do so. And, I'd certainly suggest that we ask the ISO committee before doing this. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.2 Branch Status: Slush

; I'll review what's happened and decide what to do. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.3.0: Stage 3

that people have been working hard to get their Stage 2 patches submitted in timely fashion. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.3.0 Status Report (2007-09-04)

to leave this to the x86 back-end maintainers. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.2 Branch Status: Slush

Bob Wilson wrote: Mark Mitchell wrote: When I sent out the notice about GCC 4.2.2 RC1, I failed to note the GCC 4.2 branch should now be considered slushy; please get my explicit approval before check-in. Obviously, there was no way anyone could have known that, so if things have been

Re: GCC 4.3.0 Status Report (2007-09-04)

largely been reviewed. But, of course, we do need to make sure all the targets work. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.3.0 Status Report (2007-09-04)

precise with size costs for builtins while inlining. I guess that should be alright for stage3 . Yes, that sounds OK. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.3.0 Status Report (2007-09-04)

predicates ought to be looking at the type to support calling through function pointers? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.3.0 Status Report (2007-09-04)

Meissner, Michael wrote: I didn't hear back from you, so I checked in the machine independent and i386 parts in my SSE5 patch. Now, on to making the various ports still work with the change. All right; sounds good. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Does g++ have a intel/msdn __COUNTER__ macro equivalent??

; this isn't reference information. In a tutorial, or in release notes, I have no objection. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.3.0 Status Report (2007-09-04)

it would have to accept a FUNCTION_TYPE. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.3.0 Status Report (2007-09-04)

, but calling conventions are certainly properly thought of as a property of types, not of declarations. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.2.2 RC2 (finally)

I'm finally spinning GCC 4.2.2 RC2. Please do not make any further check-ins to the GCC 4.2 branch, even those that have been previously approved, without my explicit approval. I apologize to everyone for the delay in bringing out GCC 4.2.2. Thanks, -- Mark Mitchell CodeSourcery [EMAIL

GCC 4.2.2 RC2 Available

, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.2.2 RC2 Available

think that this is a showstopper. (AFAIK, you're the first person to notice this, and you've indicated that it's now a relatively long-standing bug.) Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Inconsistent error/pedwarn: ISO C++

is converted to the pointer type, as if by a cast. A patch to convert to pedwarns is pre-approved, if accompanied by a testcase. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.2 branch open

David Daney wrote: Mark Mitchell wrote: v v GCC 4.3 Stage 1 (ends Jan 20 2007) GCC 4.2.0 release (May 13 2007) |\ v v GCC 4.3 Stage 2

Re: gcc-4.2-20071011 is now available

inconvenience the FreeBSD folks. I remembered that you'd asked me to leave the previous 4.2.1 RCs around, but I hadn't realized that was a general request, as opposed to something specific to 4.2.1. This patch is OK, thanks! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

  1   2   3   4   5   6   7   8   9   10   >