with this?
Diego, I think that given Aldy's offer, we can remove this as an issue.
Go ahead with the merge, if you're ready.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
to only be a problem for
AIX at this point, so that may not be that much of a problem.
This is the approach I would suggest. Dump out the debug info for types
before you throw away all the information, and then leave it aside.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
X)" should print the
same value when debugging optimized code as when debugging unoptimized
code, even if the compiler has optimized X away to an empty structure!
There are other things we could do, like mark the *variables* of type X
(rather than the type) as having no location, so that you can&#x
ld be better than modifying the
debugger to make assumptions about magic variable names.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
hat's what everyone is talking about, I think. "Emit"
here may also mean "cache in memory some place", rather than "write to a
file". It could mean, for example, fill in the data structures we
already use for types in dwarf2out.c early, and then throw away th
ot;could I stick a
random data byte there and have it affect the function". For example,
for a Thumb function whose ISA address is "0x0001", I would consider
for size purposes that it starts at "0x", since altering that
byte at run-time would change the me
non-DWARF debug info. As long as it we design it
carefully, there's no reason we should have that limitation.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Kenneth Zadeck wrote:
Paolo Bonzini wrote:
Mark Mitchell wrote:
For that matter, "print sizeof(X)" should print the same value when
debugging optimized code as when debugging unoptimized code, even if
the compiler has optimized X away to an empty structure!
I disagree. sizeof
don't escape --
or if the user explicitly tells you that they are.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
nt that has that ABI-specified value. If the compiler emits code
that behaves differently based on whether I wrote "sizeof (X)" or "12"
(assuming X is a 12-byte structure), then the compiler is broken.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
at we need at that point,
based only on what we are going to output. (And for DECL_COMDAT things,
we should be outputting LTO information only if actually referenced.)
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
sk. Maybe we should just not write the data out to the LTO
file, rather than trying to free it early. If you like, have a
free-it-early mode for error-checking (to make sure that we aren't
relying on that data) in the same way that we have an always-collect
mode for GC (to make sure w
appy if GCC "tricked"
me into violating some other license as well. So, if we have a
configuration that we know is undistributable, then making me hack the
source code to disable the error, or making me use a configure-time
override option seems like a good call.
Thanks,
--
Mark Mitc
> Date: Wed, 6 Aug 2008 11:27:36 -0400
> From: Daniel Jacobowitz <[EMAIL PROTECTED]>
>
> On Wed, Aug 06, 2008 at 07:19:26PM +0400, Sergei Poselenov wrote:
> > (gdb) bt
> > #0 0x4004ec0c in raise () from /lib/libc.so.6
> > #1 0x40050234 in abort () from /lib/libc.so.6
> > Backtrace stopped: frame
probably be difficult to fix.
Previous Report
===
http://gcc.gnu.org/ml/gcc/2008-04/msg00539.html
Next Report
===
The next report for 4.4.0 will be sent by Richard.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
eport
===
While normally the next report would be given by Richard, I'd like to
skip ahead to Joseph, so that the same RM isn't responsible for two
reports in the same week.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
agnostics would be an improvement. Some of these
problems that we consistently struggle with (printing complex
expressions, using the same spellings of keywords and types that the
user did, etc.) would be significantly improved by using carets -- even
if the carets didn't point in exactly the right
's quality.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
sions. The caret
output format may be desirable to some users as well, but most of the
work here will be in getting the locations correct and in showing the
user's original text.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
tack the problem directly, by working with others to improve
the location information in the compiler. My experience has been that
if you get the ball rolling, other people will get behind and help, when
they see that the problem is tractable.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
olerate CPUs without this feature. It can of
course offer reduced functionality (at compile-time or at run-time) on
CPUs without the necessary support.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
sources that require i686.)
That seems entirely reasonable to me.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Hi barrat... run the midi output to the maths patch have the midi as
the initial value then add a multiply value (in your case 360)
works for me.. Ta Mark
I've a simple question:
What's the best way of scaling midi data - for example the 0 - 1
from the midi to scale to rotat
language level, and "char" and "signed char" are
different types -- even when "char" is signed.
For example:
char* q;
signed char *p = q;
is not valid without a cast.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
r
**" cannot point at the same thing, for example.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
ecause the chances that everybody in
in this community will be happy about anything is about as good as pigs
flying through frozen-over hell under a blue moon in a month of Sundays. :-)
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Richard Earnshaw wrote:
>> Mark Mitchell wrote:
>>> GCC 4.2.0 RC3 is now available from:
>>>
>>> ftp://gcc.gnu.org/pub/gcc/prerelease-4.2.0-20070501
>>>
>>> This build now contains the fixes for the Ada build problem present in RC2.
>>>
e an evidence that this is a real problem.
Do we build stage1 with checking enabled even if --disable-checking is
in effect? Otherwise, how to do folks like Richard E. that are running
natively on small systems work around this issue?
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
nd mainline, assuming that someone verifies
that the switch actually performs as advertised.
Thanks!
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Ian Lance Taylor wrote:
> This patch appears to fix the problem. I'm running the libjava tests
> now. Does this look OK to the java maintainers for 4.2 branch and
> mainline? Mark, should I commit to 4.2 branch?
If this (or a variant) is approved by the Java maintainers, pleas
he mode provided to access, which is its privilege.
There's a simple GCC change to fix this: have libiberty wrap the access
function and mask out X_OK on non-Cygwin Windows. It's reasonable to
put this change in libiberty, since it's job is to provide portability
between systems.
My two cents,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Ross Ridge wrote:
> Mark Mitchell writes:
>> In my opinion, this is a GCC bug: there's no such thing as X_OK on
>> Windows (it's not in the Microsoft headers, or documented by Microsoft
>> as part of the API), and so GCC shouldn't be using it.
>
> Strict
me, but I don't think other participants were ever as
excited about it. It's certainly not paramount, and Kenny has shown
that it's probably more practical just to read/write the IL directly.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
ust proceed with what we've got.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Steven Bosscher wrote:
> On 5/12/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>> PR 31797: An infinite loop in the compiler while building RTEMS.
>> Daniel, I see you've been commenting on this; are you working on the
>> fix? If so, do you have an ETA?
>
> W
asis of Darwin
alone, I would not further hold up the release. That is not to say that
I would not consider a patch to fix it, of course.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
as that introduced (in
theory) for 4.2?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Daniel Berlin wrote:
> On 5/11/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>> Every time I think we're almost there with this release, I seem to
>> manage to get stuck. :-( However, we're very close: the only PRs that
>> I'm waiting for are:
>>
>
Jason Merrill wrote:
> Mark Mitchell wrote:
>> PR 30252: Wrong code generation, perhaps due to the C++ front end's
>> representation for base classes. Jason, are you actively investigating
>> this one?
>
> I haven't been; I've been working on the forced
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31586
>
> Maybe someone could solve this, so it is solved in GCC 4.2 and others?
Yes, this would be an easy bug to fix, and it would be good to do so,
but I don't think this is likely before 4.2.0.
Thanks,
--
Mark Mitchell
CodeSourcer
Therefore, I'm going to get 4.2.0 out the door.
Please consider the 4.2.0 branch completely frozen at this time.
I will be working through the release checklist tonight.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Jason Merrill wrote:
> Mark Mitchell wrote:
>> No, I don't think we know. There's speculation in the PR trail, but
>> that's it. I'd appreciate it if you were able to investigate further,
>> but I think I'd best just accept that this will not be
As per:
http://gcc.gnu.org/ml/gcc/2007-05/msg00329.html
> Therefore, I'm going to get 4.2.0 out the door.
>
> Please consider the 4.2.0 branch completely frozen at this time.
>
> I will be working through the release checklist tonight.
Thanks,
--
Mark Mitchell
CodeSourc
Jason Merrill wrote:
> Mark Mitchell wrote:
>> I'm concerned about either of the other approaches, in that we don't
>> fully understand why they work, so we can't really be confident we're
>> not just pushing the bug around.
>
> Yes. But I would a
eck for the input case too?
I'm quite keen to make the fix for this bug cover all eventualities
in terms of the various varieties of reload that might arise, if
possible...
Thanks in advance for any help. Once this is fixed, I shall add the
necessary comments, test it a
Rask Ingemann Lambertsen wrote:
On Mon, May 14, 2007 at 10:47:13PM +0100, Mark Shinwell wrote:
[snip]
- the last use of reg2 (in B) is inside a matched input operand;
[snip]
The reload used for the instruction at B looks like this:
Reload 0: reload_in (SI) = (plus:SI (reg/f:SI 9 r9
Rask Ingemann Lambertsen wrote:
On Tue, May 15, 2007 at 09:31:10AM +0100, Mark Shinwell wrote:
Rask Ingemann Lambertsen wrote:
On Mon, May 14, 2007 at 10:47:13PM +0100, Mark Shinwell wrote:
[snip]
- the last use of reg2 (in B) is inside a matched input operand;
[snip]
The reload used
Rask Ingemann Lambertsen wrote:
On Mon, May 14, 2007 at 10:47:13PM +0100, Mark Shinwell wrote:
I'm fairly certain that this is the correct approach to fix this
issue, but I'm less certain that I have correctly guarded the call
to forget_old_reloads_1, and indeed that I've don
Bernd Schmidt wrote:
Mark Shinwell wrote:
The bug is currently only exhibiting itself on a proprietary testcase
when compiled for an ARM target and is extremely sensitive to the
particular code involved. It arises as follows, using the same notation
as in Richard's mail:
If you can&#
Rask Ingemann Lambertsen wrote:
On Mon, May 14, 2007 at 10:47:13PM +0100, Mark Shinwell wrote:
I'm fairly certain that this is the correct approach to fix this
issue, but I'm less certain that I have correctly guarded the call
to forget_old_reloads_1,
[snip]
Index:
Bernd Schmidt wrote:
Mark Shinwell wrote:
These dumps are of course taken before the application of my patch.
Hope that helps,
Thanks. I may have missed it in the previous mails, but which piece of
code exactly decides to use R9 for reload 0 of insn 5314?
I'm afraid I'm not su
if you spot any, please let me know!
I'll be sending out a release announcement momentarily.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Index: ChangeLog
===
--- ChangeLog (revision 124663)
+++ Chang
to clean up my messes, even
when I'm busy.
What do others think?
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
tion, and it causes us to generate an inferior error message
for some obscure test case, then that's a regression -- but we should
mark it P4, and you shouldn't have to worry about it. On the other
hand, if your great new optimization causes wrong code on a major
platform, then you should figure
summary of the status? Are there regressions
on major platforms?
Also, does anyone feel that this representation change is a bad thing?
Are there any objections to merging this branch in principle, assuming
that it's not causing regressions, either in generate code or at compile
time?
Th
e short term, would be to disable this functionality in
C++ -- although, of course, we will eventually want to turn it on so
that GNU C++ is as much as possible a superset of GNU C.)
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
-term use of GCC 4.1.x can update from there. And, I would of
course be happy to turn the branch over to someone else, if there is
interest in future releases.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
actually make the release July 13th, I've put a note in my
calendar to make 4.2.1 RC1 on July 1st. If there are 4.2.x regressions
that you're interested in fixing, please do your best to fix them by
that date.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
t's going to
exclude some very important functionality, let me know. If you feel
that's too long, let me know that too.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
to look into bugzilla 3.0 migration first though.
Understood.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
an insn with
a REG_DEAD note for the corresponding pseudo that is the real cause
because it upsets the later code -- that's what my patch was trying to
correct.)
Mark
e of hours) to look at the branch, and provide some feedback?
Please provide comments to Chao-Ying, and also please let me know
whether you think the work is nearly ready for inclusion?
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
ter (rather than just any register). Bernd, could you
clarify the precise meaning of "spill register" in this context? I've
not yet managed to completely pin this down.
Mark
d too.
So what do you think is the best approach to fix all of this? :-)
Mark
Bernd Schmidt wrote:
Mark Shinwell wrote:
and the code following in emit_reload_insns? Perhaps if spill_reg_index
took account of registers selected during find_reloads then this could
be simplified too.
So what do you think is the best approach to fix all of this? :-)
Sounds like you gave
Ian Lance Taylor wrote:
> And Simon already sent in a tested patch for a couple of days ago:
>
> http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00199.html
This patch is OK, thanks.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
e me -- and
people who know better than I! -- a chance to look over the
infrastructure changes.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
E_FAMILY(sat, fract);
MAKE_FIXED_TYPE_NODE_FAMILY(sat, accum);
etc.
That's not right, but you get the idea. :-)
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
eriod beginning June 15th during
which we would go into a regressions-only mode (other than possible
merges of the functionality above) in order to begin eliminating some of
the problems that have come in with the exciting new infrastructure.
Any comments on that course of action?
Thanks
Mike Stump wrote:
> On Jun 7, 2007, at 10:33 PM, Mark Mitchell wrote:
>> I am aware of three remaining projects which are or might be appropriate
>> for Stage 1:
>
> I wasn't sure of the Objective-C 2.0 timing until recently... I'd like
> to contribute it durin
Joseph S. Myers wrote:
> On Thu, 7 Jun 2007, Mark Mitchell wrote:
>
>> I am aware of three remaining projects which are or might be appropriate
>> for Stage 1:
>
> Do we at this point believe that the people who were working on updating
> the TYPE_ARG_TYPES changes (f
the regressions-only rule once the 4.3
release branch has been made.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
al to signed integer,
> floating point to fractional,
> fractional to floating point. */
> DEF_RTL_EXPR(FRACT_CONVERT, "fract_convert", "e", RTX_UNARY)
Yes, I think that's better.
Thanks!
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
d of the intermediate lockdown when Stage 2 opens?
Correct.
> When were you expecting to end the lockdown and open Stage 2?
I would play it a little bit by ear, but I was anticipating a couple of
weeks.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Andrew Pinski wrote:
> On 6/7/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>> * PTR_PLUS branch.
>>
>> I believe that this branch should be included in GCC 4.3. Andrew,
>> would you please update me as to its status?
>> In particular, are there
>
ackling.
(Since we're just now restarting the project, nobody has yet been
assigned concrete tasks.)
At present, I know that Daniel Berlin is currently moving the existing
LTO patches forward to a new branch based on the current mainline.
Daniel will let us know when the new branch is ready.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Bernd Schmidt wrote:
Mark Shinwell wrote:
and the code following in emit_reload_insns? Perhaps if spill_reg_index
took account of registers selected during find_reloads then this could
be simplified too.
So what do you think is the best approach to fix all of this? :-)
Sounds like you gave
Michael Meissner wrote:
> On Fri, Jun 08, 2007 at 01:27:39PM -0700, Mark Mitchell wrote:
>> Joseph S. Myers wrote:
>>> On Thu, 7 Jun 2007, Mark Mitchell wrote:
>>>
>>>> I am aware of three remaining projects which are or might be appropriate
>>>>
approved, so I don't mean for you
to get bogged down in the review process. But, I would like a
maintainer to approve the commit. I will help review if necessary.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Andrew Pinski wrote:
> If you could review the C++ front-end changes, that would be nice.
Would you please point me at a URL for those changes?
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
to make any dllimport or dllexport attribute imply default
visibility. Is that a bad idea?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Fu, Chao-Ying wrote:
> As Mark requested, we propose a merge plan for the fixed-point branch
> as follows.
I think this is a good plan. Since there have been no negative
comments, let's go with this approach.
I've looked at the big patch you posted, and I think it looks v
3, in the hopes of a shorter release process than we achieved for
4.2.0.
Previous Report: http://gcc.gnu.org/ml/gcc/2007-06/msg00201.html
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Bill Wendling wrote:
> On Jun 15, 2007, at 12:48 AM, Mark Mitchell wrote:
>
>> Consider:
>>
>> struct __attribute__((vsibility ("hidden"))) S {
>>void __declspec(dllimport) f();
>> };
>>
>> At present, we give "f" hidden
ether or not there is on GNU/Linux) that
implements different class members in different DLLs, while still not
exporting the class from its home DLL. One situation where this is
useful is when the class members are actually shared between multiple
classes, or are also callable as C functions, etc.
--
d S::f() { S::g(); };
In any case, in practice, ARM's RealView compiler accepts:
struct __declspec(notshared) S {
__declspec(dllimport) void f();
void g();
};
void S::g() {
f();
}
And, there's a large body of code that uses this.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
variables from C,
things won't work then too.
You seem to be saying that because you can do things that don't work, we
should disallow a useful construct.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
uing about issuing a warning about this with "-W", if
people want to do that. These mixtures of visibility are certainly not
the typical case.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Kaveh R. GHAZI wrote:
> On Fri, 15 Jun 2007, Mark Mitchell wrote:
>
>> GCC 4.3 Stage 1 is now closed.
>> [...]
>> As previously discussed, the mainline will be in "lockdown" for 1-2
>> weeks, starting midnight tonight. Other then the merges mentioned
>&
rs for
> DFP, libgcc and x86 backend.
That sounds correct to me.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
r that users want.
We have accepted this code:
>> struct __attribute__((visibility("hidden"))) S {
>> __attribute__((visibility("default"))) void f();
>> void g();
>> };
for quite some time. It would be surprising to make that an error now.
The question which prompted this debate was where "f" has been marked
"dllimport" rather than with an explicit visibility. But, "dllimport"
certainly implies default visibility. It would be inconsistent to
accept the case directly above, but not the "dllimport" case.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
ntly, DFP is only
> supported on Linux/PPC, which uses DPD encoding, and Linux/x86, which
> uses BID encoding. So Intel BID patch only affects Linux/x86 as
> it changes libgcc/Makefile.in to use Intel BID library. Who has
> the final say on this patch?
The build system maintainers and t
that they are more independent. They have
no commercial stake in which companies have maintainers, what
development projects are done by whom, etc. Presumably, to the extent
they have a vested interest in the outcome it's in making GCC useful for
their own development, which is probably as
ce the compiler can assume the output isn't a NaN or an Inf, it can
freely switch one and the other.
> If -fno-finite-math-only is specified, then the generated code should
> "do the right thing" if an argument or result is inf or NaN.
Also agreed.
--
Mark Mitchell
CodeSourcery
these are different types. And, yes, the
call that you suggest is a type error, for the reason that you say.
It's QoI for LTO to diagnose that, but, hopefully, it will.
>> The question which prompted this debate was where "f" has been marked
>> "dllimport" rather than with an explicit visibility. But, "dllimport"
>> certainly implies default visibility. It would be inconsistent to
>> accept the case directly above, but not the "dllimport" case.
>
> dllimport implies default visibility, but it also requires (afaik) that
> the implementation be outside the current shlib.
On the systems I've used, it just affords that option. If the function
ends up being in the same shared library, you may have slower access to
it, because you end up going through an indirection you don't need, but
it works.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
s see a good reason not to
That's great, thanks.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Richard Earnshaw wrote:
> On Mon, 2007-06-18 at 10:04 -0700, Mark Mitchell wrote:
>>> I suspect that the realview compiler accepts
>>> this as an oversight or a bug, not as an intentional feature.
>> Let's ask.
>>
>> Richard E., is the fact that RealV
YPES is used directly. And, we
don't have to create a branch to do that part. So, I'd suggest
preparing patches against mainline for those bits. How does that sound?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
wait for 4.4 when we get to it. But, 1, 2, 3
I think are non-controversial, and can go into mainline in real time,
which is nice.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
s, that's crossing an
abstraction barrier, and yes, it means that as a programmer, you need to
understand that "there's some vtables and stuff out there", but that's
they way people use these bits in practice.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
1501 - 1600 of 1839 matches
Mail list logo
