Re: may_alias attribute and type identity (PR c++/34935)

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

Re: How to stop gcc from not calling noinline functions

g() { f(); } A valid GNU C compiler cannot eliminate the call to f, as long as the call itself is reachable. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: may_alias attribute and type identity (PR c++/34935)

to mangle these types, we need to have a mangling for attributes. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Changes in C++ FE regarding pedwarns to be errors are harmful

Joe Buck wrote: Mark Mitchell wrote: I don't see any a priori problem with changing to match the C front end. We could of course change some of the pedwarns into errors if we really think they ought to be errors. Or, some of them could be ordinary warnings when not -pedantic, and pedwarns

Release Management

in this way. Please join me in thanking and congratulating our new co-RMs! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Changes in C++ FE regarding pedwarns to be errors are harmful

problem with changing to match the C front end. We could of course change some of the pedwarns into errors if we really think they ought to be errors. Or, some of them could be ordinary warnings when not -pednatic, and pedwarns when -pedantic. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED

Re: __builtin_expect for indirect function calls

current behavior, unless you call __builtin_expect with a long long, and that's probably not going to do what you expect right now anyhow. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: __builtin_expect for indirect function calls

? Do we have the leeway to change this? Or should we add __builtin_expect2? Or add an -fno-polymorphic-builtin-expect? Or...? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: What is a regression?

Gerald Pfeifer wrote: On Tue, 23 Oct 2007, Mark Mitchell wrote: [...] I realized that the documentation we currently have up at http://gcc.gnu.org/bugs/management.html was partly incorrect (only listing P1 to P2) and certainly quite incomplete, so I tried to cast my understanding

Re: __builtin_expect for indirect function calls

? That was my first thought as well. Before we add __builtin_expect_call, I think there needs to be a justification of why this can't be done with __builtin_expect as-is. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Regression count, and how to keep bugs around forever

of the beholder. The PN system expressions something about regressions that's moderately useful, but nothing else. I suspect that we need more database fields, so that people could run more interesting searches. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Problem with ARM_DOUBLEWORD_ALIGN on ARM

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

Re: Designs for better debug info in GCC

of a variable is when it has been optimized away? If that's still your goal, then pointing at the DWARF3 specification doesn't help. Diego and I are asking you to confront these fundamental questions about what information you want to provide and what the correctness criteria are. -- Mark Mitchell

Re: PATCH: Update MPFR versions (was Re: Revisiting GCC's minimum MPFR version)

, under the guidelines you suggest above. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Revisiting GCC's minimum MPFR version

Richard Guenther wrote: I would update the recommended version to 2.3.0 and fail for anything less than 2.2.1. I agree. Not optimizing bessel functions as builtins doesn't bother me too much, but we might as well move past the buggy version. Thanks, -- Mark Mitchell CodeSourcery [EMAIL

Re: Link tests after GCC_NO_EXECUTABLES

decide to change the overall strategy, then we can do that all at once. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Link tests after GCC_NO_EXECUTABLES

option that allows you to specify a cache file per multilib. But, I think that could be left for later. What do you and others think? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Link tests after GCC_NO_EXECUTABLES

that hunk? I'm not quite sure if you're asking for agreement to leave it in our sourcebase, or to remove it therefrom, so, unambiguously: I would prefer to revert DJ's change, for the same reason as the other changes under discussion, so that we're consistent across architectures. -- Mark Mitchell

Re: Describing commercial support on our website

means to figure out who provides those services. Then we don't have to worry about who's listed in what order on the web site, etc. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Link tests after GCC_NO_EXECUTABLES

like the libstdc++ one, as you say. I would like to give the libstdc++ maintainers a chance to comment on the libstdc++ patch above and Rask and other maintainers a chance to comment on the libgloss reversion. I'll pre-approve the patch if no objections in 48 hours. Thanks, -- Mark Mitchell

Re: Link tests after GCC_NO_EXECUTABLES

in Newlib that aren't necessarily part of a standard C library. I could be wrong about that, though. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Link tests after GCC_NO_EXECUTABLES

for $with_newlib elsewhere in configure.ac, so I think this is in the same spirit, though a libstdc++ maintainer would of course be best to review the patch.) Bernd, Richard, Rask, would one of you be willing to explore that route? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Link tests after GCC_NO_EXECUTABLES

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

Re: Link tests after GCC_NO_EXECUTABLES

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

Re: Link tests after GCC_NO_EXECUTABLES

really think that we ought to compare with what happens with MIPS or Power and figure out what's different. Are you by any chance configuring a native compiler, rather than a cross? Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Link tests after GCC_NO_EXECUTABLES

the compiler accept options that don't make sense in order to work around some problem -- and maybe that problem is what should really be solved. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Link tests after GCC_NO_EXECUTABLES

linking except for $GLIBCXX_IS_NATIVE. It's a design property that you should not need to link. Where in libstdc++ is it requiring linking? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Link tests after GCC_NO_EXECUTABLES

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

GCC 4.3.0 Status Report (2007-11-27)

- 18 P34 + 1 --- --- Total 134 - 20 Previous Report === http://gcc.gnu.org/ml/gcc/2007-11/msg00109.html -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Link tests after GCC_NO_EXECUTABLES

Joseph S. Myers wrote: On Tue, 27 Nov 2007, Mark Mitchell wrote: In any case, I think this is something that ought to be decided as a global policy for GCC and its run-time libraries, not something that differs between ports. In particular, if run-time libraries are allowed to depend

Re: Link tests after GCC_NO_EXECUTABLES

I'm trying to do here is to ensure that gcc-4.3 will work out of the box as a compiler for our uClinux distribution. Understood. Out of curiousity, do you eventually build a bfin-uclinux compiler, once you've built uClibc, or do you just use the bfin-elf compiler on uClinux? -- Mark Mitchell

Re: Link tests after GCC_NO_EXECUTABLES

Joseph S. Myers wrote: On Tue, 27 Nov 2007, Mark Mitchell wrote: Yes, that makes sense to me. Bare metal systems are of course somewhat different. What do you think about that? I think it's well established that at least some bare-metal systems default to not linking with any

Re: Designs for better debug info in GCC

to optimize by throwing away the old value of x before assigning a new one? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Limits of stage3 changes

associated risk. So, I don't want to promise that we would accept the patch in Stage 3, either. Steven, I recognize that might not be as definitive an answer as you would like, but I hope you will understand my thinking. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Attributes on structs

semantic type attributes apply only at the point of definition, then we can dodge all these issues; there will always be only one class X, whatever attributes it might happen to have. So, I like that answer. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: undocumented optimization options

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 program get the right answer. On the other hand

Re: Designs for better debug info in GCC

these problems? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Designs for better debug info in GCC

else we're trying to do. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713

Re: Designs for better debug info in GCC

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 ?

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

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 might use for that. Yes, it is a good thing

Re: Designs for better debug info in GCC

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

the definition, which is fine by me. -- 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, would you please review this patch

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)

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: Tree-SSA and POST_INC address mode inompatible in GCC4?

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

that the option is experimental, deprecated, or otherwise in danger of being removed or changes, but we should document the option. If an option is only useful for developers, and we really think that users should not be allowed to twiddle it, we should hide it under an #ifdef. Thanks, -- Mark Mitchell

GCC 4.3.0 Status Report (2007-11-04)

--- --- 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 release schedule

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 preparation. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED

Re: GCC 4.3 release schedule

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 a good plan to me. Thanks, -- Mark Mitchell

Re: GCC 4.3 release schedule

, 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: Removal of pre-ISO C++ items from include/backwards

misread the Subject: what disappeared under my back, without any warning nor deprecation period, actually was ext/hash_map and friends. Whether or not we've been through a deprecation cycle, I still think there should be a very high bar for removing APIs from the library. My two cents, -- Mark

GCC 4.3.0 Status Report (2007-10-25)

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

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

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

Re: What is a regression?

. 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 open, so we can't really call them release blockers. OK

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

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

GCC 4.2.2 RC2 Available

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

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

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)

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

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

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