erPC ELF ABI
group decides what to do with them.
It's certainly good to minimize the number of times we introduce ABI
changes, so waiting for a definitive plan makes sense.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
're doing and what
impact it might have on the various stakeholders.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
save whatever AltiVec registers its using? Is
that what you're suggesting?
Daniel, perhaps you can put a full proposal on the table so that we can
try to get consensus on thsi?
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
ems.
Or, is it the case that the patch to use abs_srcdir means that no matter
what Texinfo you have, it's not going to work on MinGW?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
nt conversion
between them.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
ions in future, if we add mangling support
for attributes.
But, yes, if we need to mangle these types, we need to have a mangling
for attributes.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
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
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 ordin
d Richard all agreed to help out
in this way. Please join me in thanking and congratulating our new co-RMs!
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
s no sane C++ programmer would do at this point, but we
want to support for legacy C++ code.
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 b
sible. I can't think of a way in which it changes
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
like:
sizeof(__builtin_expect(1, 1))
will change its value. And, the current prototype is documented in the
manual.
What do people think? 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
h is
progress. So, I think we've moved forward a bit more than the raw
numbers might indicate.
Previous Report
===
http://gcc.gnu.org/ml/gcc/2007-11/msg00109.html
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
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
amount = GEN_INT (offsets->saved_args + saved_regs
> - - offsets->outgoing_args);
> + + static_chain_size - offsets->outgoing_args);
>
>insn = emit_insn (gen_addsi3 (stack_pointer_rtx, stack_pointer_rtx,
> amount));
>
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
to work on now. The problem there is that importance is in
the eye 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
; expressable using builtin_expect as-is, at least when it comes
> to the syntax?
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
t these fundamental
questions about what information you want to provide and what the
correctness criteria are.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
them time to
> upgrade.
> Ok for mainline?
OK, under the guidelines you suggest above.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
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
CodeSour
So, I
suppose the all-singing, all-dancing version of this would be some
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
f-consistent; if we decide to change the overall strategy, then we
can do that all at once.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
n, support, etc. use other
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
J? Do you agree it's OK to drop 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 w
amount of
target-specificity, so you'd presumably end up with multiple cache files
for various targets, but that sounds like it would work. The tradeoff
is that you might end up adding checks for functions that are in fact
available in Newlib, but, because nobody added them to the cache file,
that libstdc++ actually depends on --with-newlib meaning that you're
using Newlib (rather than some other C library) in that it uses
facilities 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
n to work on
bare-metal targets, then we should make it's configure script work 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&#
sking whether the
function is in the C library, whether by linking, having the answer
hard-coded, or doing some other kind of probe (running nm?).
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
est "x${with_newlib}" != "xyes"; then
AC_LIBTOOL_DLOPEN
fi
will fix the problem. (We already have checks 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, Rich
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
>
o understand the situation better.
> What 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 jus
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 lib
---
P1 33 - 3
P2 97 - 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
ports. In particular, if run-time libraries are allowed
to depend on linking in their configure tests, that's something everyone
should know.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
rd Sandiford, as I discussed some of the MIPS
stuff with him at one point.
Note that libstdc++/configure.ac carefully avoids 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
lt behaviour, but it started
> to fail the libstdc++ configury once Jie changed that to use
> target-specific linker scripts.
I 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
on here because it sounded to me from your patch like we were making 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
Why accept it, but make it imply the simulator?
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
uaranteed to see
the changed value? Or is seeing the previous value OK? What about some
intermediate value if "x" is being changed byte-by-byte? What about a
garbage value if the compiler happens to optimize by throwing away the
old value of "x" before assigning a new one?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
typedef union U_ U2 __attribute ((transparent_union));
in the compiler. For example, in the parser, we could skip over the
union body, scan the attributes, notice transparent_union, and pretend
that the user had written:
typedef union __attribute((transparent_union) { ... } U;
if we wanted. That
s likely to be correct,
either that maintainer, or I, decide that there's too much 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 m
s (i.e., that describing local variables, line numbers for
statements, etc.) is required for LTO processing. The LTO use is
confined to global variables, functions, types, etc. So, that local
information could be stripped (or not generated in the first place)
without adversely affecting usage wi
to put the LTO declarative information in a
separate section, we might well be able to do better than DWARF. I
don't feel like we know enough yet to do that.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
them has an attribute.
If we can mandate that all 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
t the value is unavailable -- rather
than cleverly telling the debugger that the value is a constant. I
don't see that as an unreasonable limitation when debugging optimized
code, but that's open for debate.
I'm not claiming this is better than what you're suggesting. I'm just
throwing it out there.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
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
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
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
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
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
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
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.
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
ttributes after the definition, which is fine by me.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
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
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
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
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
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
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
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
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
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
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
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
g/ml/gcc/2007-09/msg00286.html
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
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
removing APIs from the library.
My two cents,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
put new functionality into than to
move old headers out of existing include directories.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
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
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
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
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
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
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
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
,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
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
[
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
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
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
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
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
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
#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
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
x27;m going to leave this to the x86 back-end
maintainers.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
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
fine; I'll review what's happened and decide what to do.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
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
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
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
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
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.
.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
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
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
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
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-
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
301 - 400 of 1433 matches
Mail list logo
