Re: RFH: GPLv3

d update source files that say "v2 or later". Please err on the side of caution; it will be harder to go back to V2 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

cular item (e.g., delaying GCC 4.2.1, releasing GCC 4.2.2 as GPLv2, etc.); I think that RMS has made his decision. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: RFH: GPLv3

act that it's at the top of the FSF's priority 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

ranch 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

e 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

And, if you have time, please add a test-case specifically 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

tion is in fact there, so I guess we could go that way. 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

ering patch (i.e., 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, --

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

hout 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/i

GCC 4.3.0 Status Report (2007-08-09)

p;value0-0-0= I have not yet triaged the many P3 bugs, so I expect that some of these will be downgraded. An interesting fact is that now about half of the 34 P1s re 4.3-only regressions. So, we have been introducing some new 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

approach, exercise the hell out 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 b

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

f a real bug? Or just to make 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 checki

Re: recent troubles with float vectors & bitwise ops

ly generic (e.g., move float operands to integer registers, bitwise operation, move the result back) then we could always issue a sorry. Users may then have to use #ifdefs on some 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

lt; N; ++i) au.bytes[i] |= bu.bytes[i]; au.f; }) If the resulting floating-point value is denormal, NaN, etc., whether or not exceptions are raised is unspecified. -- 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: &

Re: recent troubles with float vectors & bitwise ops

not just quietly 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'r

Re: Stage 2 project: upgrade decNumber

his as much like the upstream sources as possible seems desirable to me; 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

Lazily set it, when something wants to check it. (3) Change checks of flag_argument_noalias 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.

interference graph > that in some 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

ode, and that it will get a lot of the common cases, I think it's worth it. Do you agree? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: RFC: Hack to make restrict more useful

t. Do you agree? > > Yes, I agree. I just 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 testca

Re: RFC: Hack to make restrict more useful

gument_noalias > for noalias everywhere? Either will work, but you're right; using noalias is clearer. (In an earlier version I'd not organized things in the same way, so that wouldn't have worked.) I'll make those changes too. As you suggest, 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

break, and they all involve the compiler claiming a and b can't 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

optimize test cases like the one in the PR I filed? In any case, I guess we 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 Fortra

GCC 4.2.2 Status Report

er of regressions (and, particularly, P1 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)

d in 4.3" and then realize that "oh, well, 4.3 has 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. >

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

ite ready for prime-time; I do think we'd want to make 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

warn about this kind of case, we should make sure that it does so for all functions, used or not. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: [RFC] missing return warnings

noreturn warning 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

line, then we needed to make sure its body was available when g 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)

ith less dense switch statements? Do we want want separate params when we're operating under -Os 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.

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

useful optimization to me, and I understand that it will work 99.99% of the time, and it's in the spirit of the standard -- but how do we actually make it safe? If the attribute only applied to other values returned from the same function, 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)

of you care to review this? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

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

s substantially, then I'd 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?

loc"; hide the implementation somewhere the rest of the program can't see it (modulo LTO). But, to declare it with the "malloc" attribute in the headers seems dangerous, since we have no way of knowing if the user replaced it, off in some file somewhere we don't know about, b

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

quot; and "delete" themselves, after the first allocation? If comparing addresses is allowed, it's weird to think that: if (p == i) *p = '\0'; is invalid, while: if (p == i) *i = '\0'; is valid, but I 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?

on if the allocation fails. (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?

we let users use this attribute optionally, for their implementations of operator new when they "know" it's OK to do so, but do not actually put 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 is not safe. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

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

here (i.e., assume that pointers returned by operator new are all distinct, and distinct from all other pointers we can see) is only safe 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-

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 . I'm also somewhat skeptical of the >> idea that we will never do any optimiz

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

Btw, diego already approved the patch. I apologize 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?

w, or in future -- is very likely to make exactly that deduction, since it is logically true. More broadly, my point was that a universe 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)

e this will need changing anyway to do something > reasonable with it I think we 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.

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

to commit at this point. We can have a look 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. Th

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

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

it's OK to put the "malloc" attribute on operator new, why did you say earlier that you can't implement "malloc" in C itself, for exactly these kinds of reasons? Isn't the situation exactly analogous? I think I'm getting confused. Perhaps you could sum up in

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

alloc" must be even stronger -- the value returned must not alias *any* other pointer. I don't think that affects your argument, but just for the sake of clarity, that must be your claim. I think my point of view on this is that, whether or not the standard can be read to support you

GCC 4.2 Branch Status: Slush

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

fact 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)

x27;m going 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 >> kn

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

#x27;s already 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)

rivial and > tries to be more 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)

TION_DECL, rather than a FUNCTION_TYPE? I'd think that all calling-convention 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??

n. The manual should say what the options do. Referencing specific tools, which may or may not continue to exist, etc., seems odd to me. The manual is a reference text; 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)

a macro to control the calling convention that accepts a FUNCTION_DECL; I would think 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)

e attributes here should be recorded *only* on the type, in order to avoid duplication. That's not strictly speaking necessary, 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 [

GCC 4.2.2 RC2 Available

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

Re: GCC 4.2.2 RC2 Available

just relies on the compiler build to install the documentation. In either case, I don't 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++

l-defined GNU semantics, but don't happen to be legal. That's especially true for things that are valid in GNU C. Here, the well-defined GNU semantics are that the integer 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

GCC 4.2 branch open

The GCC 4.2 branch is now open for checkins, under the usual regressions-only rules. (Release announcement coming shortly.) This patch is the mechanical web-site required in the wake of the 4.2.2 release. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713 Index: index.html

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

Re: gcc-4.2-20071011 is now available

e. I was just checking off items on the checklist. :-) I hope this didn't 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 i

Re: What is a regression?

ion bug a release blocker. Now, all that said, of course I think that other bugs are important too, and I'm all for fixing them. But, in terms of looking at a release and deciding how ready-to-go it is, I think regressions are as reasonable a measure as any. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: What is a regression?

Jason Merrill wrote: > Mark Mitchell wrote: >> When I mark a PR as "P1", that means "This is a regression, and I think >> it's embarrassing for us, as a community, to have this bug in a >> release." Unfortunately, every release goes out with P1 bugs

Re: Removal of pre-ISO C++ items from include/backwards

put new functionality into than to move old headers out of existing include directories. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Removal of pre-ISO C++ items from include/backwards

removing APIs from the library. My two cents, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Removal of pre-ISO C++ items from include/backwards

went through the packages in and they all build" isn't a very good measure; those packages are probably reasonably actively maintained. It's the millions upon millions of lines of existing code in truly big applications out there that's a problem. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.3.0 Status Report (2007-10-25)

g/ml/gcc/2007-09/msg00286.html -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.3 release schedule

und of major features. In any case, after we make the branch, it's in regression-only mode, so stability tends to be quite good, though dot-zero releases are, after all, dot-zero releases. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: GCC 4.3 release schedule

at increase pressure to focus on the release -- but that will only work if enough people are actually motivated to work on the release anyhow. It seems like there's enough momentum in this cycle to make that work. I'll keep listening, in case there's more feedback, but it seems like

Re: GCC 4.3 release schedule

e release is ready rather than have > branch criteria and then release criteria. Yes, that's what I'm imagining too, under this plan. All we'd be doing differently is delaying Stage 1 until after the release, instead of parallelizing Stage 1 with the final release preparat

Re: Tree-SSA and POST_INC address mode inompatible in GCC4?

increment is an important code-size optimization and we are not presently doing a very good job taking advantage. So, whatever solution we settle on should not be dependent on being in a loop. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: undocumented optimization options

ers should not be allowed to twiddle it, we should hide it under an #ifdef. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

GCC 4.3.0 Status Report (2007-11-04)

0 P33 -30 --- --- Total 154 -30 Previous Report === http://gcc.gnu.org/ml/gcc/2007-10/msg00441.html -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

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

Alexandre Oliva wrote: > On Nov 5, 2007, Mark Mitchell <[EMAIL PROTECTED]> wrote: > >> * Are there any unreviewed patches that I could help to review? > > Also, how about the patch for PR27898? > > http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00187.html Joseph

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

H.J. Lu wrote: > http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00305.html OK. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

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

H.J. Lu wrote: > http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01865.html > > which involves reload. I'm not going to try to wade into reload. Ulrich, Eric, Ian -- would one of you please review this patch? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

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

goal for GCC, so when we find problems like this, we need to fix them, even if there's some memory cost. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Designs for better debug info in GCC

David Edelsohn wrote: >>>>>> Mark Mitchell writes: > > Mark> I think we all agree that providing better debugging of optimized code > Mark> is a priori a good thing. So, as I see it, this thread is focused on > Mark> what internal representation we migh

Re: Designs for better debug info in GCC

to do, I don't see how we can make a good decision about the representation. Clearly, in the abstract, we can represent data either on-the-side or in the instruction stream, but until we know what output we want, I'm not sure how we can pick. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Attributes on structs

ttributes after the definition, which is fine by me. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Designs for better debug info in GCC

Alexandre Oliva wrote: > On Nov 7, 2007, Mark Mitchell <[EMAIL PROTECTED]> wrote: > >> Until we all know what we're trying to do > > Here's what I am trying to do: I think these are laudable goals, but you didn't really provide the information I wanted.

Re: Designs for better debug info in GCC

To be clear, I'm not trying to set the goals here; I'm just trying to make sure we have a clear set of objectives and a plan to get there. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Progress on GCC plugins ?

of the arguments that have been made in this thread. If people want to influence the FSF, the best approach is probably going to be sending mail directly to RMS, not discussing it on this list. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Designs for better debug info in GCC

ather than notes on instructions that say what affect the instruction has on user variables? (For example, "this SET makes the value of V unavailable". Or "this SET makes the value of the V available in the destination register"?) As a meta-question, have you or anyone else on the list looked at the literature (IEEE/ACM, etc.) or how other compilers handle these problems? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Designs for better debug info in GCC

se values (might) die. Thus, we can probably do a reasonable job of guaranteeing that when we say a variable is somewhere, it is in fact in that place. I don't yet understand what else we're trying to do. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: undocumented optimization options

ions that return constants, but, because this optimization can create multiple copies of code fragments, it may significantly increase code size. == -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Designs for better debug info in GCC

Alexandre Oliva wrote: > On Nov 12, 2007, Mark Mitchell <[EMAIL PROTECTED]> wrote: > >> Clearly, for some users, incorrect debugging information on optimized >> code is not a terribly big deal. It's certainly less important to many >> users than that the pr

<    9   10   11   12   13   14   15   >