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

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

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

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

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

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: 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: 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: 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: [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: [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

. Michael and Danny have expressed opinions; does anyone else have one? 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: 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

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

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.1 RC2

remains frozen to all changes, without my explicit permission. 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

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

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

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 RC1

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

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

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

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

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: 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: 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: 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: RFC: Make dllimport/dllexport imply default visibility

conflicting with existing practice of other compilers and large bodies of application code. How does that serve our users? Note: I'm not arguing about issuing a warning about this with -W, if people want to do that. These mixtures of visibility are certainly not the typical case. -- Mark Mitchell

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

Kaveh R. GHAZI wrote: On Fri, 15 Jun 2007, Mark Mitchell wrote: GCC 4.3 Stage 1 is now closed. [...] As previously discussed, the mainline will be in lockdown for 1-2 weeks, starting midnight tonight. Other then the merges mentioned above, and documentation improvements, the only patches

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

and x86 backend. That sounds correct to me. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

RFC: Make dllimport/dllexport imply default visibility

or dllexport attribute imply default visibility. Is that a bad idea? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: [fixed-point] Fixed-point branch merge plan

your merge. However, you may of course start preparing your patches, and posting them for review, if you like. I just want you to let Andrew go first in terms of actually checking in the changes. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC Status Report (2007-06-15)

of a shorter release process than we achieved for 4.2.0. Previous Report: http://gcc.gnu.org/ml/gcc/2007-06/msg00201.html Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: RFC: Make dllimport/dllexport imply default visibility

Bill Wendling wrote: On Jun 15, 2007, at 12:48 AM, Mark Mitchell wrote: Consider: struct __attribute__((vsibility (hidden))) S { void __declspec(dllimport) f(); }; At present, we give f hidden visibility. That seems odd since the user has explicitly told us that the symbol

Re: RFC: Make dllimport/dllexport imply default visibility

) that implements different class members in different DLLs, while still not exporting the class from its home DLL. One situation where this is useful is when the class members are actually shared between multiple classes, or are also callable as C functions, etc. -- Mark Mitchell CodeSourcery [EMAIL

Re: RFC: Make dllimport/dllexport imply default visibility

(notshared) S { __declspec(dllimport) void f(); void g(); }; void S::g() { f(); } And, there's a large body of code that uses this. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: RFC: Make dllimport/dllexport imply default visibility

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

Re: Merge PTR_PLUS branch?

Andrew Pinski wrote: If you could review the C++ front-end changes, that would be nice. Would you please point me at a URL for those changes? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Merge PTR_PLUS branch?

approved, so I don't mean for you to get bogged down in the review process. But, I would like a maintainer to approve the commit. I will help review if necessary. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

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

Michael Meissner wrote: On Fri, Jun 08, 2007 at 01:27:39PM -0700, Mark Mitchell wrote: Joseph S. Myers wrote: On Thu, 7 Jun 2007, Mark Mitchell wrote: I am aware of three remaining projects which are or might be appropriate for Stage 1: Do we at this point believe that the people who were

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

Andrew Pinski wrote: On 6/7/07, Mark Mitchell [EMAIL PROTECTED] wrote: * PTR_PLUS branch. I believe that this branch should be included in GCC 4.3. Andrew, would you please update me as to its status? In particular, are there any regressions on primary or secondary targets at this point

LTO Status Report (2007-06-10)

concrete tasks.) At present, I know that Daniel Berlin is currently moving the existing LTO patches forward to a new branch based on the current mainline. Daniel will let us know when the new branch is ready. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

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

expecting to end the lockdown and open Stage 2? I would play it a little bit by ear, but I was anticipating a couple of weeks. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

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

Mike Stump wrote: On Jun 7, 2007, at 10:33 PM, Mark Mitchell wrote: I am aware of three remaining projects which are or might be appropriate for Stage 1: I wasn't sure of the Objective-C 2.0 timing until recently... I'd like to contribute it during stage 2. That's OK with me, but with two

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

Joseph S. Myers wrote: On Thu, 7 Jun 2007, Mark Mitchell wrote: I am aware of three remaining projects which are or might be appropriate for Stage 1: Do we at this point believe that the people who were working on updating the TYPE_ARG_TYPES changes (from the old LTO branch) for trunk

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

are in order: gfortran is now a real Fortran compiler and people really are using it! But, regressions, wrong-code, and ICEs isn't a bad criteria for this intermediate lockdown. I do expect Fortran to honor the regressions-only rule once the 4.3 release branch has been made. Thanks, -- Mark Mitchell

Re: Fixed-point branch?

, fractional to floating point. */ DEF_RTL_EXPR(FRACT_CONVERT, fract_convert, e, RTX_UNARY) Yes, I think that's better. Thanks! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Fixed-point branch?

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

GCC 4.3.0 Status Report (2007-06-07)

15th during which we would go into a regressions-only mode (other than possible merges of the functionality above) in order to begin eliminating some of the problems that have come in with the exciting new infrastructure. Any comments on that course of action? Thanks, -- Mark Mitchell CodeSourcery

Re: Something weird with cp/decl.c switch statement

Ian Lance Taylor wrote: And Simon already sent in a tested patch for a couple of days ago: http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00199.html This patch is OK, thanks. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Fixed-point branch?

to look over the infrastructure changes. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Fixed-point branch?

provide comments to Chao-Ying, and also please let me know whether you think the work is nearly ready for inclusion? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Volunteer for bug summaries?

that storing a range might be useful, but I think it's important that we impose enough structure that we can easily run queries without having to do a lot of parsing on the field. Just my two cents, though. I have to look into bugzilla 3.0 migration first though. Understood. Thanks, -- Mark

POINTER_PLUS branch status?

of the status? Are there regressions on major platforms? Also, does anyone feel that this representation change is a bad thing? Are there any objections to merging this branch in principle, assuming that it's not causing regressions, either in generate code or at compile time? Thanks, -- Mark

Fixed-point branch?

be to disable this functionality in C++ -- although, of course, we will eventually want to turn it on so that GNU C++ is as much as possible a superset of GNU C.) Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.1.x Status Report (2007-05-28)

use of GCC 4.1.x can update from there. And, I would of course be happy to turn the branch over to someone else, if there is interest in future releases. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.2.1 Status Report (2007-05-28)

to actually make the release July 13th, I've put a note in my calendar to make 4.2.1 RC1 on July 1st. If there are 4.2.x regressions that you're interested in fixing, please do your best to fix them by that date. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.3.0 Status Report (2007-05-28)

important functionality, let me know. If you feel that's too long, let me know that too. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Volunteer for bug summaries?

whose name is in the ChangeLog entries for P3 and higher regressions, with the SVN field filled in. I will volunteer to work on this part of things, but hopefully I can get some help from our SVN and Bugzilla experts. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Volunteer for bug summaries?

messes, even when I'm busy. What do others think? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.2 branch open for regression fixes

, please let me know! I'll be sending out a release announcement momentarily. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713 Index: ChangeLog === --- ChangeLog (revision 124663) +++ ChangeLog (working copy

Re: GCC 4.2.0 Status Report (2007-05-11)

Jason Merrill wrote: Mark Mitchell wrote: PR 30252: Wrong code generation, perhaps due to the C++ front end's representation for base classes. Jason, are you actively investigating this one? I haven't been; I've been working on the forced unwind stuff, and looking at the rvalue refs patch

Re: GCC 4.2.0 Status Report (2007-05-11)

/bugzilla/show_bug.cgi?id=31586 Maybe someone could solve this, so it is solved in GCC 4.2 and others? Yes, this would be an easy bug to fix, and it would be good to do so, but I don't think this is likely before 4.2.0. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.2.0 Status Report (2007-05-13)

out the door. Please consider the 4.2.0 branch completely frozen at this time. I will be working through the release checklist tonight. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.2.0 Status Report (2007-05-11)

Jason Merrill wrote: Mark Mitchell wrote: No, I don't think we know. There's speculation in the PR trail, but that's it. I'd appreciate it if you were able to investigate further, but I think I'd best just accept that this will not be fixed for 4.2.0. Or revert the patch that revealed

GCC 4.2.0 Branch Frozen for Release

As per: http://gcc.gnu.org/ml/gcc/2007-05/msg00329.html Therefore, I'm going to get 4.2.0 out the door. Please consider the 4.2.0 branch completely frozen at this time. I will be working through the release checklist tonight. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650

Re: GCC 4.2.0 Status Report (2007-05-11)

Jason Merrill wrote: Mark Mitchell wrote: I'm concerned about either of the other approaches, in that we don't fully understand why they work, so we can't really be confident we're not just pushing the bug around. Yes. But I would assert that pushing the bug back to where

GCC 4.2.0 Status Report (2007-05-11)

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

Re: GCC 4.2.0 Status Report (2007-05-11)

Steven Bosscher wrote: On 5/12/07, Mark Mitchell [EMAIL PROTECTED] wrote: PR 31797: An infinite loop in the compiler while building RTEMS. Daniel, I see you've been commenting on this; are you working on the fix? If so, do you have an ETA? Why are you waiting for this one? RTEMS

<    1   2   3   4   5   6   7   8   9   10   >