Re: GCC 4.1.2 RC2

Richard Henderson wrote: > On Mon, Feb 12, 2007 at 01:16:43PM -0800, Ian Lance Taylor wrote: >> Mark Mitchell <[EMAIL PROTECTED]> writes: >> >>> But, aren't big C++ shared libraries rather different? Does KDE >>> actually use throw() everywhere, or

Re: GCC 4.1.2 RC2

so doing we'd lose bug fixes for (other) correctness issues. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.1.2 RC3 Cancelled

timezone changes and Joseph's update of translation files. If the build change for non-standard shells is also checked in tonight that's fine; if not, there's a good workaround. So, my current intent is build the final 4.1.2 release tomorrow evening in California. Thanks, --

Re: Some thoughts and quetsions about the data flow infrastracture

accurate information is available. My point is that I don't think that the right criteria for DF is whether it makes the generated code faster. So long as it doesn't make the generated code slower, and so long as the APIs seem well designed, and so long as it doesn't make the compiler it

Re: GCC 4.1.2 RC3 Cancelled

tions not to be locally bound in shared libraries (which it determines by checking flag_shlib) and flag_shlib is generally set if flag_pic is true. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.1.2 RC3 Cancelled

*/ > /* { dg-options "-O1 -fdump-tree-cfg" } */ > +/* { dg-skip-if "" { "*-*-*" } { "-fpic" "-fPIC" } { "" } } */ > double a; > void t() > { I think this makes sense. At worst, it's overly conservative, and the tes

4.1 branch open

The 4.1 branch is now open for changes under the usual regression-only rules for release branches. Here are the changes that I commited during the release process. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713 2007-02-14 Mark Mitchell <[EMAIL PROTEC

Re: 40% performance regression SPEC2006/leslie3d on gcc-4_2-branch

ns for 4.2.0, and such comments would be entirely germane in response to that message. But, for the purposes of this message, please assume a 4.2.0 based on the 4.2 branch in the usual way. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.2.0 Status Report (2007-02-19)

l have a 4.2.0 release by (worst case, and allowing for lameness on my part) March 31. Feedback and alternative suggestions are welcome, of course. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: 40% performance regression SPEC2006/leslie3d on gcc-4_2-branch

-3.9% > 459.GemsFDTD-18.3% > 465.tonto -2.5% > 470.lbm -4.1% > 481.wrf -2.7% What does that translate to in terms of overall score? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: 40% performance regression SPEC2006/leslie3d on gcc-4_2-branch

no reason to expect that, and I think two person-months is rather much. Therefore, it sounds like the practical choices are revert the patch and accept the bugs, or vice versa. Is there any reason to expect the bugs to be particularly more prevalent in 4.2 than they were in 4.1? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: 40% performance regression SPEC2006/leslie3d on gcc-4_2-branch

a smaller regression relative to 4.1. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.2.0 Status Report (2007-02-19)

ed, and I'm trying to put as much of it as possible into being RM and C++ maintainer. However, that PR is in the list of open 4.2 PRs, so when I next make a pass over those PRs, I'll certainly look at it. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.2.0 Status Report (2007-02-19)

er upgrading from 4.1.x to 4.2.0 will see a regression, or if the 4% will be absorbed by other improvements. If someone with a different chip is willing to provide the same measurements, that would help eliminate Intel-specific characteristics in the data as well. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: "Installing GCC" documentation: Why a nonstandard title page?

7;t imagine there would be; that seems like a good thing. However, please avoid the bikeshed: we can all fuss over what font size to use, etc., but there's not much upside. I vote you pick something, and we all accept it. :-) -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: 40% performance regression SPEC2006/leslie3d on gcc-4_2-branch

Grigory Zagorodnev wrote: > Mark Mitchell wrote: >> Excellent question; I should have asked for that as well. If 4.2 has >> gained on 4.1 in other respects, the 4.7% drop might represent a smaller >> regression relative to 4.1. >> > There is the 4.2 (r120817) vs

Re: 40% performance regression SPEC2006/leslie3d on gcc-4_2-branch

le, trading potential aliasing bugs for performance, if that seems like a win. It doesn't make sense to compare unmodified FSF 4.2 compilers with distribution-optimized 4.1 compilers. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

RFC: Constructor and destructor priority attributes

rom C. The attribute syntax above works in both C and C++, and is backwards-compatible; without the "(N)" you just get the default initialization priority, as you do at present. I plan to merge this functionality to the GCC mainline. Does anyone object to this feature, in principle? T

Re: Comparison of Itanium gcc 4.1 and 4.2 on Spec2000

.2 branch? Are you able to try reverting the aliasing patches to see how much of an impact they have on Itanium? It would be interesting to know how that compares with the 4% on IA32. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Who should fix platforms broken by extern inline hack?

n >> mainline, as they have been for more that three months. > > This patch (not yet approved) is my contribution to fixing the > problem. > > http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00021.html Please let me know if you feel this has gotten stuck, and I will try to help mo

GCC 4.2.0 Status Report (2007-03-04)

inger in my report next Monday. :-) Of course, that's not to say that non-maintainers shouldn't contribute as well! Let's get it done! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713 [1] http://gcc.gnu.org/ml/gcc/2007-02/msg00427.html [2] http://gcc.gnu.o

Re: Signed overflow patches OK for 4.2?

one of the choices are particularly pretty. Ian, please do the backport and check in the changes as soon as you can. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.2.0 Status Report (2007-03-04)

Manuel López-Ibáñez wrote: > On 05/03/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: >> After reviewing all of the traffic[1] that stemmed from my previous >> status report, I've decided that, indeed, it makes sense to steam ahead >> with GCC 4.2.0 based on

Re: GCC 4.2.0 Status Report (2007-03-04)

r whatever you > do to indicate they aren't going to be resolved in 4.2. I'm going to leave them open, but I've added a link to your message to the audit trails. Optimistically, someone might miraculously fix them, but it's very helpful to know that that's going to be unlikley. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.2.0 RC1 Status

oudert * David Daney * Jerry DeLisle * David Edelsohn * Steve Ellcey * Ben Elliston * Daniel Franke * Kaveh Ghazi * Richard Guenther * Richard Henderson * Geoffrey Keating * Thomas Koenig * Simon Martin * Andrew MacLeod * Mark Mitchell * Brooks Moses * Joseph Myers * Alexandre Oliva * Andrew Pi

Import GCC 4.2.0 PRs

R 30221 (Sidwell, Mitchell) -- An ICE-on-valid for initializing arrays of pointer-to-member functions in C++. * PR 30590 (Guenther, Merill) -- Wrong code generated by NRV. * PR 30700 (Hubicka) -- Cgraph causes undefined references. * PR 30704 (Edelsohn) -- Bad code generation for long long on big-endi

Re: Import GCC 4.2.0 PRs

Ulrich Weigand wrote: > Mark Mitchell wrote: > >> * PR 28544 (Brook, Weigand) -- this is an ARM ICE which Paul has tracked >> to reload, but he's not sure what to do there. Perhaps Ulrich can help. > > This description doesn't appear to match the bugzilla recor

PATCH: make_relative_prefix oddity

last argument, the answer is as I expected. This seems odd to me; is it the intended behavior? The patch below (which is against an older version of libiberty, and might need updating) fixes it. Assuming you agree that this is a bug, would this patch (with updating and testing) be OK? Thanks, -- Ma

GCC 4.2 branch snapshots disabled

r to focus testing on the actual prereleases, as those are most likely to contain any defects that I might introduce into the actual release as well. (*) I guess this should really be Beta 1; it's not quite a release candidate, yet, in that I fully expect changes after this point. Thanks, --

Re: PATCH: make_relative_prefix oddity

Daniel Jacobowitz wrote: > On Mon, Mar 12, 2007 at 10:47:28PM -0700, Mark Mitchell wrote: >> It treats only "/opt" as a common component of the two paths, rathe >> than "/opt/foo". If you use "/opt/foo/" (instead of "/opt/foo") for >>

RFH: G++ manual page in GCC 4.2.0

we do for releaes), doc/gcc.1 is in the source directory. VPATH finds it, so the dependency is satisfied, but the copy doesn't work. I intend to fix this by changing the rule to be: cp $< doc/g++.1 which will resolve VPATH correctly. Does anyone see a problem with this plan? Than

GCC 4.2 branch comparision failure building Java

The GCC 4.2.0 RC1 build has failed (on x86_64-unknown-linux-gnu) with: Comparing stages 2 and 3 Bootstrap comparison failure! ./java/parse.o differs ./java/parse-scan.o differs Has anyone else seen this? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: XFAILing gcc.c-torture/execute/mayalias-2.c -O3 -g (PR 28834)

t them to behave. Zero FAILs may not be achievable on all targets, but if I had a magic XFAIL wand, that would put the right XFAIL goo into all tests before every release so that all users who built the toolchain correctly always got zero FAILs, I would do it. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: We're out of tree codes; now what?

So, the only real solutions are (a) expand the width of the code field and (b) use subcodes. And, I agree that we should do all we can to avoid expanding the size of tree nodes. So, I think the subcode approach is the best choice. Like Ian, I think the macros above are fine. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.2 branch comparision failure building Java

Joseph S. Myers wrote: > On Tue, 13 Mar 2007, Mark Mitchell wrote: > >> The GCC 4.2.0 RC1 build has failed (on x86_64-unknown-linux-gnu) with: >> >> Comparing stages 2 and 3 >> Bootstrap comparison failure! >> ./java/parse.o differs >> ./java/parse-scan

Re: GCC 4.2 branch comparision failure building Java

ild GCC releases on an RHEL3 box. However, I believe that I was using a version of GCC 3.4.x (built by CodeSourcery) as the bootstrap compiler. It does seem like a suspiciously similar situation, though; I'm sure that Joseph will be able to tell us if the problem is reproducible with GCC 3.4.x

Re: GCC 4.2 branch comparision failure building Java

@ $< And, then, just have java/parse.o depend on $(java_parse_c)? I was going to give this a try, but if you know whether it's going to break, let me know. :-) -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.2 branch comparision failure building Java

uming that we can't do that, I'd rather just fix the Makefiles, if there are any more such problems. As Joseph's noted, the Java problem is already gone on mainline, thanks to the ECJ integration. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.2 branch comparision failure building Java

Paolo Bonzini wrote: > Mark Mitchell wrote: >> Paolo Bonzini wrote: >> >>> IIUC, the problem only manifests while *building* the release candidates, >>> not for users of the release candidate. >>> >>> For 4.2, my suggestion is to just use a bootst

GCC 4.2.0 RC1

CC: list for the issue. Please do not send me reports without first filing a PR, as I am unable to keep track of all the issues if they are not in the database. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: We're out of tree codes; now what?

TE_EXPR. Especially (2) and (3) are relatively easy transformations. (2) is unquestionably something that we want to do anyhow. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: We're out of tree codes; now what?

compilation of the compiler and runtime libraries.) So, I still believe that I'll be able to build GCC 5.0 (on hardware available at that point) in less time than it took to build GCC 3.4 (on hardware available at that point). -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: We're out of tree codes; now what?

; data structure so there will be a > memory usage hit, I don't think there's disagreement about that. I thought the plan was to this in TYPE_LANG_SPECIFIC, etc., so that it's not a generic effect on all trees? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: We're out of tree codes; now what?

ompilers go.) They're complex. I think I'm inclined to agree with Mike: I'm starting to prefer (2). It's a simple solution, and pretty efficient. Anyone want to champion (1) or (3)? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.2.0 Status Report (2007-03-22)

Jim's patch for PR 31273 tonight. Joseph, would you please take a look at PR 31136? Andrew believes this to be a front-end bug. My hope is that we can fix these PRs, and then declare victory on the GCC 4.2.0 release. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.2.0 Status Report (2007-03-22)

Mark Mitchell wrote: > There are still a number of GCC 4.2.0 P1s, including the following which > are new in GCC 4.2.0 (i.e., did not occur in GCC 4.1.x), together with > -- as near as I can tell, based on Bugzilla -- the responsibility parties. > > PR 29585 (Novillo): ICE-on-v

Re: [patch] generated string libraries & -Wformat

th the additional steps you mention? I have no opinion, but it might help Bruce to know for sure whether he's heading in a direction you're likely to approve. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.2.0 Status Report (2007-03-22)

Joseph S. Myers wrote: > On Thu, 22 Mar 2007, Mark Mitchell wrote: > >> Joseph, would you please take a look at PR 31136? Andrew believes this >> to be a front-end bug. > > I don't think this is a front-end bug. Thank you for investigating. > (OK to commit this

Re: GCC 4.2.0 Status Report (2007-03-22)

s (a) the change above, (b) remove the TREE_ADDRESSABLE setting from mark_vtable_entries (possibly replacing it with an assert.) If that works, it's OK. If not, and you want to punt it back, go ahead. Thanks again for working on this! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: error: "no newline at end of file"

levels is obscure, and should probably be overhauled at some point. But, this is it's current state, and it's been that way for a long time, so to resolve this issue, we should just play the same game. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: RFC: GIMPLE tuples. Design and implementation proposal

#x27;t symbol-tablish? A not-so space-efficient approach would be to allocate out of an ordinary block of memory, using ordinary pointers, and then swizzle into self-relative pointers at serialization time. Then, when you deserialize, you could just leave them self-relative, or swizzle them back.

Re: RFC: GIMPLE tuples. Design and implementation proposal

s, that we make > the references be pc-relative. Self-relative, not PC-relative, right? (If so, that happens to be what I was suggesting earlier.) -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: [RFA] C++ language compatibility in sources [was RE: Add missing casts in gengtype-lex]

he FSF. I hope you choose to do that, as everyone agrees that this is good stuff to have! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Maintainers for C preprocessor

MAINTAINERS file to reflect your new appointment, and thank you for agreeing to take on this responsibility! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: error: "no newline at end of file"

Thus, only users who want pedantic error messages see the message. They can control whether the message is an error or a warning via -pedantic-errors (or the C++ front-end's -fpermissive). -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.2.0 Status Report (2007-04-15)

ism towards CodeSourcery personnel. What do people think of that suggestion? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.2.0 Status Report (2007-04-15)

any closer to release. And there's a good bit more functionality that we want to get into 4.3, which, in the way of things, is likely to introduce new bugs, no matter how positive its overall impact. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.2.0 Status Report (2007-04-15)

me scripts are > large and slightly clever, others are short and obvious. For safety sake, we should probably get assignments on them. I'm not sure how hard it is to get IBM to bless contributing the scripts. If it's difficult, but IBM doesn't mind them being made public, perhaps

Re: GCC 4.2.0 Status Report (2007-04-15)

and just "Copyright > FSF " on the small ones. I guess I'd tend to be conservative and put the full GPL notice on all of them. If it doesn't apply because the file is too small, whoever wants to use it in some non-GPL way can assert that fact if they want. Is there some

Re: GCC mini-summit - compiling for a particular architecture

n just make the change. Of course, if people would prefer that I ask the SC, I'm happy to do so. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC mini-summit

C 4.2 status report, and various other opinions that have been presented to me. I've got some ideas, but I want to let them percolate a bit before trying to write them down. In any case, I want people to know that I'm listening. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC mini-summit - compiling for a particular architecture

bled in a machine-independent way, by checking some property of the back end, that would be superior. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC mini-summit - compiling for a particular architecture

Kaveh R. GHAZI wrote: > On Mon, 23 Apr 2007, Mark Mitchell wrote: > >> I'm certainly not trying to suggest that we run SPEC on every >> architecture, and then make -O2 be the set of optimization options that >> happens to do best there, however bizarre. > >

Changes to PR prioritization policy

lity to the various maintainers. So, if you're not a maintainer, but you want to make one of the changes above, lobby a maintainer. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.2.0 Status Report (2007-04-24)

w: release when there are no severe bugs. I've gotten a little paralyzed with this release. I've wanted to take some combination of (4), (5), and (6), and I've made a hash of it. I'm going to cut my losses and 4.2.0 out the door. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.2.0 Status Report (2007-04-24)

at patch has a bug. So, what's the story here? > > I found the problem, I will send a patch once it passes regtesting. Thanks! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.2.0 Status Report (2007-04-24)

t; > Danny identified the fix on the mainline, I applied it to the branch > after testing. So that's fixed as well. Thanks!! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.2.0: Still planning on RC1, etc.

In case anyone here sends me an email, and gets my vacation auto-reply for the next week: I do still plan to proceed with the 4.2.0 release schedule in my last status report. FYI, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.2.0 RC2 Building

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

Re: GCC 4.2.0 RC2 Building

Mark Mitchell wrote: > Zdenek, I would still be interested in a fix for PR31360. From the > audit trail, it looks like your patch for this PR on mainline causes > another problem (PR 31676), and that you are not working on PR 31676 > because you cannot build for powerpc-linux-gnu. (

Re: GCC 4.2.0 RC2 Building

hat the branch is now frozen: that will give us a better chance at solving this problem, without introducing new ones. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.2 RC2 Available

, please download and test the actual tarballs, rather than checking out from SVN tags, in order to help detect packaging problems. If you find a problem, please do not email me directly. Instead, file an issue in Bugzilla: http://gcc.gnu.org/bugzilla/ Thank you, -- Mark Mitchell CodeSourcery

Re: Backport fix for spurious anonymous ns warnings PR29365 to 4.2?

o- to turn this off.) In any case, we're not going to do this for 4.2.0. As per the policy I posted recently on PRs, please find a C++ maintainer who wants to argue for backporting this and ask them to mark the PR as P3 with an argument as to why this is important to backport. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.2.0 RC3 Available

change my mind about that. Please see: http://gcc.gnu.org/ml/gcc/2007-05/msg00032.html for information about reporting problems. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.2.0 RC3 Available

, against an SVN checkout, match what you see today, with a release tarball? This is in no way a criticism, or a comment on RETMS testing (about which I know almost nothing), etc.; just a general comment, which your message gave me the excuse to make. :-) Thanks, -- Mark Mitchell CodeSourcery

Re: Inlining and estimate_num_insns

problems without requiring any tuning of the inlining algorithms. Has anybody experimented with that potentially much less intrusive fix? -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Re: Inlining and estimate_num_insns

acceptable for 4.0 that would give people an easy to understand way of getting the compiler to do what they want: put "inline" on functions they really want to have inlined. That's in addition to the existing heuristics. I think that's a plausible way of mitigating the pr

Re: GCC 4.1 Projects

Nathan Sidwell wrote: Mark Mitchell wrote: Nathan Sidwell wrote: You've not included the completion of gcc_assertification, did you miss that email, or did you not think it necessary to add it as a specific project, or ... ? The former; I thought we'd corresponded about that previ

Re: GCC 4.1 Projects

in this branch, as it would seem to be in their best interest to do so? -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Re: Inlining and estimate_num_insns

ister a lot. In the case or "register", we now have a compiler which seems to generate just as good code by ignoring the keyword as it did by honoring it, we avoid the kinds of ICEs you discuss. We don't know whether those things are true about "inline" or not. -- Mark Mit

Re: GCC 4.1 Projects

Daniel Jacobowitz wrote: On Sun, Feb 27, 2005 at 02:57:05PM -0800, Mark Mitchell wrote: Nathanael said it did not interfere with any of the other _projects_, not that it would be disjoint from all Stage 1 _patches_. Fair point. I would certainly prefer that you hold off until Stage 2, as

Re: GCC 4.1 Projects

upon submission. Since that seems to be the consensus, I'll implement that in the next release cycle.) I think the constraints on the process ought to include (a) relatively little effort invested by relatively few people in the decision making process, and (b) clear termination condition

Re: GCC 4.1 Projects

rhaps it will become obvious before then, one way or the other. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Re: Inlining and estimate_num_insns

Giovanni Bajo wrote: Mark Mitchell <[EMAIL PROTECTED]> wrote: 1. The C++ community has split into two sub-communities. One is very heavily focused on template metaprogramming. The other is doing more "traditional" object-oriented programming. I would postulate that most of the

Re: GCC 4.1 Projects

tested and completely ready to go before Stage 1 started. I'd like to think that the fact that I've expressed willingness to reconsider Nathanael's patch would be encouraging to those who might try to game the system. If I'm wrong about the risk level of Nathanael's

Re: GCC 4.1 Projects

rying to make the whole thing work; while I have my objections against the idea, it may turn out that most of the people work in a different way and will actually prefer it (I admit to enjoy a controlled amount of chaos :-) Thank you for the kind words. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROT

Re: GCC 4.1 Projects

over the years. However, I think that this was an inappropriate action on your part. I'd appreciate your assurance that you will not take this kind of preemptive action again. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Re: Apologies to Mark

copies of mail, though, and so CC'ing directly to me is always a good bet, if you think I might be interested. Regards, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Re: GCC 4.1 Projects

Gabriel Dos Reis wrote: And, yes, I appreciate your work a lot. That does not rule out occasional disagreements. I agree. And, I think Nathanael and I have resolved the situation very satisfactorily, so, as far as I'm concerned, everything worked as well as could be hoped. -- Mark Mit

Re: Hot and Cold Partitioning (Was: GCC 4.1 Projects)

ke it work better on more systems, such as those with DWARF. I think that Joern's objections can be dealt with after you get those fixes in place; I would imagine that you would just mark small basic blocks directly reachable from hot blocks as "hot", whether or not profiling data act

Re: Constant pointer to (member) function, indirect call

probably something that could be done via range propagation. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Re: Pascal front-end integration

progress in realizing it...) -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Re: Pascal front-end integration

act that someone's willing to maintain it; we ought to convince ourselves that the benefit to users will be sufficiently great that it's worth imposing these costs. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Re: Constant pointer to (member) function, indirect call

Helge Bahmann wrote: On Tue, 1 Mar 2005 Mark Mitchell wrote: Helge Bahmann wrote: void (A::*function2)(void) throw()=&A::function2; (a.*function2)(); however for the call through pointer function2 gcc will always generate an indirect call, i386 assembly for example looks like: Yes

Re: [patch] fold-const.c: Reorganize fold - Part 1/n

es locally until the prescribed time, but I thought I'd make the offer anyway. Yes, that's eminently sensible. Thanks for making yourself available! -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Re: Question about ObjC++ state

r the RM to declare at this point what a future decision would be. I suspect that if done well, the RM would entertain allowing it in 4.0.[n+1]; but that is just speculation. I have it on good authority that the RM agrees with all of the statements above. -- Mark Mitchell CodeSourcery, LLC [

Re: Question w.r.t. `'class Foo' has virtual functions but non-virtualdestructor` warning.

bout possibly broken interfaces, or late about definitely broken usage? I think that warning early, together with what DJ is calling fine-grained warning control is the best solution. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Re: Question w.r.t. `'class Foo' has virtual functions but non-virtualdestructor` warning.

le actually make the same argument sometimes about things like: void f() { int *p = 0; *p = 3; } saying "but I never call f, so I don't want a warning for it". Languages like Python or LISP are the (extreme) logical extension of your point of view: just start running the program and

Re: Question w.r.t. `'class Foo' has virtual functions but non-virtualdestructor` warning.

ibute you can put on the class to say "don't issue this warning about this class." -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

Re: [PING] [PATCH]: New Port(MAXQ)

ode in any substantial way, and I don't see any reason to modify this policy. The same certainly goes for 4.1. As you say, what's needed is a reviewer. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304

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