ify the alignment of memory
returned by "operator new", or a GNU attribute that libstdc++ could add
to the default declaration (with a system-dependent value, of course),
etc. seems fine to me, but I'd be very hesitant to change the ABI proper.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
of these restrictions in
future, if we add mangling support for attributes.)
A variable declaration involving attributes, like:
__attribute__((...)) S v;
is treated as syntactic sugar for:
typedef __attribute__((...)) S T;
T v;
where T is some invented type name different from all others in the program.
For example given:
__attribute__((packed)) S v;
the type of "&v" is "__attribute__((packed)) S *", and cannot be passed
to a function expecting an "S*", but can of course be passed to a
function expecting an "__attribute__((packed)) S *", or a typedef for
such a type.
Thoughts?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Joseph S. Myers wrote:
On Sun, 15 Oct 2006, Mark Mitchell wrote:
We have a number of C++ PRs open around problems with code like this:
struct S {
void f();
virtual void g();
};
typedef __attribute__((...)) struct S T;
I was happy with the state before r115086 (i.e. with it
e you'd never be able to
get a "this" pointer for them); do you think that's OK?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
raries, so that seems like a logical place to add header directories.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Ian Lance Taylor wrote:
"Carlos O'Donell" <[EMAIL PROTECTED]> writes:
A relocated compiler should not look in $prefix.
I agree.
I can't approve your patches, though.
This patch is OK, once we reach Stage 1.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
ass with
that type.
Right. And, since there seems to be consensus that you shouldn't be
able to apply semantic attributes to class types, "packed" is a bad
example there too. (If you applied "packed" at the point of declaration
of "S", then "S" has a
at's not a
bad thing, since LTO is clearly at least one more release cycle away,
and IMA might be ready sooner. On the other hand, if the IMA changes
were disruptive to the C++ front end in general, then that might be a
problem. I guess we just have to evaluate the patch, when it's
hanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
al-name).
That's true, but is there a reason not to use the discriminator
encoding? There might well be an ambiguity, but I didn't see at first
blush. If so, that would seem most natural to me.
I do think that your proposed encoding is unambiguous, though, so it
certainly seems
onsider the proposal amended to
have that.
also seems OK, assuming that we need to do this at all.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
, or sent them off to the
translation project. Joseph, would you please do that, at your convenience?
The mainline is now in Stage 1.
Thanks to those who helped fix PRs to meet the 4.2 branch criteria!
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
signed to be extended, so that's no problem. I continue to
think think that using DWARF (with extensions) since it makes this
information accessible to other tools (including GDB). I think that
before there ought to be a compelling reason to abandon a strategy based
on DWARF.
--
Mar
. LTO would use the GIMPLE type attribute (if present)
when reconstructing the type.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
ill now ask Daniel to help with the SQL bits.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Mark Mitchell wrote:
Andrew Pinski wrote:
On Sun, 2006-10-22 at 12:58 +, Joseph S. Myers wrote:
All the bugs with "4.2" in their summaries ("[4.1/4.2 Regression]"
etc.) need to have it changed to "4.2/4.3". I don't know the
procedure for this, but perha
Thanks to Joseph for helping me with this.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
--- Begin Message ---
Snapshot gcc-4.3-20061023 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20061023/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for de
Jack Howarth wrote:
Mark,
What happened to the gcc 4.2 snapshot
tarball for this week?
It gets build on Tuesdays, or at least it does now according to crontab.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Daniel Berlin wrote:
Anyway, i made 43changer.pl and ran it, so the bug summaries have been
updated.
Thanks!
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
try to put
patches on release branches, especially if they fix P1 regressions.
Sacrificing code quality for correctness is the right tradeoff for a
release branch, if we have to pick, so if a patch is "only" going to
pessimize code, it should be a very strong candidate for a release
merging as you go is fine, in principle. Every little bit
helps. My only concern would be whether you'll disrupt other
large-scale projects that might find global changes hard to handle. I'd
suggest posting your patch and seeing if anyone makes unhappy sounds. :-)
--
Mark Mitchell
Aldy Hernandez wrote:
Does the tuples branch include the CALL_EXPR reworking from the LTO branch?
No.
Though, that is a similar global-touch-everything project, so hopefully
whatever consensus develops from tuples will carry over.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331
readily buildable
GMP available, including one that works on OS X, in time for 4.3. We
should provide a tarball for it from gcc.gnu.org, if there isn't a
suitable GMP release by then.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
to that. It's a bit more build-system complexity, but
if it makes it easier for people, then it's worth it.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Ian Lance Taylor wrote:
Mark Mitchell <[EMAIL PROTECTED]> writes:
I would strongly oppose downloading stuff during the build
process. We're not in the apt-get business; we can leave that to the
GNU/Linux distributions, the Cygwin distributors, etc. If you want to
build a KDE appli
st case, declare that external library beyond salvage.
In contrast, as I understand it, Ian's perturbed about the idea of
having an external library at all.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
y're too immature; the problems we're seeing
don't seem particularly worse than the problems I would expect in early
Stage 1 with any other kind of big infrastructure change.)
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
tensions before standardization, especially without use of GNU
keywords/syntax), but I think we should preserve both cross-system
compatibility and Linux compilation in the meanwhile.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Ian Lance Taylor wrote:
Mark Mitchell <[EMAIL PROTECTED]> writes:
Ian Lance Taylor wrote:
Here is a review followed by a proposal.
How does this proposal handle the current problematic situation that
-std=c99 is broken on Linux?
According to the proposal, we will restore the GNU ha
ges. fixincludes causes sufficient
problems for people that ensuring that only users putting new compilers
on old systems suffer might be a good goal.
On the other hand, I agree that if we have fixincludes in place, then
4.3 would not be in any way broken on GNU/Linux, so I think this is a
And, there are lots of
people that have reported link failures involving _chkstk.
So, my (perhaps naive) question is: why don't we define _chkstk as an
alias for _alloca in MinGW, so that we can link with these MSVC libraries?
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650
Ross Ridge wrote:
There are other MSC library functions that MinGW doesn't provide, so
other libraries may not link even with a _chkstk alias.
Got a list?
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
sm, though, we could
add thresholding on a pass-by-pass basis.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
ing
it a near-free operation would be a huge benefit.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
e are talking about
canonicalizing. We already have only one pointer to each type, for example.
Yes, but to compare two types, you have to recur on them, because of
typedefs. In:
typedef int I;
"int *" and "I *" are distinct types, and you have to drill down to "I&q
time is a factor in how
many patches I can write, because I'm not great at keeping track of
multiple patches at once.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Modify the driver so that --lto passes -flto to the C front-end and
--lto to collect2.
Any objections to this plan?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Andrew Pinski wrote:
> On Thu, 2006-11-09 at 12:32 -0800, Mark Mitchell wrote:
>> 1. Add a --lto option to collect2. When collect2 sees this option,
>> treat all .o files as if they were .rpo files and recompile them. We
>> will do this after all C++ template instantiation
Ian Lance Taylor wrote:
> Mark Mitchell <[EMAIL PROTECTED]> writes:
>
>> 1. Add a --lto option to collect2. When collect2 sees this option,
>> treat all .o files as if they were .rpo files and recompile them. We
>> will do this after all C++ template instantiat
Ian Lance Taylor wrote:
> Mark Mitchell <[EMAIL PROTECTED]> writes:
>
>>> I assume that in the long run, the gcc driver with --lto will invoke
>>> the LTO frontend rather than collect2. And that the LTO frontend will
>>> then open all the .o files which it
Ian Lance Taylor wrote:
> Mark Mitchell <[EMAIL PROTECTED]> writes:
>
>> Though, if we *are* doing the template-repository dance, we'll have to
>> do that for a while, declare victory, then invoke the LTO front end,
>> and, finally, the actual linker, which will
file, the parser accepts either?
I like that idea.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
same_type_p fast, then that's still a big win.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Dave Korn wrote:
> On 10 November 2006 20:06, Mark Mitchell wrote:
>
>> Dave Korn wrote:
>>
>>> It may seem a bit radical, but is there any reason not to modify the
>>> option-parsing machinery so that either '-' or '=' are treated
>
nodes should be
> necessary (I think).
Do you need new class types, or just an anonymous FUNCTION_DECL?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Michael Eager wrote:
> GCC 4.1.1 for PowerPC generates a 162K executable for a
> minimal program "int main() { return 0; }". GCC 3.4.1
> generated a 7.2K executable. Mark Mitchell mentioned the
> same problem for ARM and proposed a patch to remove the
> reference to
here is something missing from N1958: there
is no discussion about what happens when you apply typeid to a lambda
function, or otherwise use it in a context that requires type_info.
(Can you throw it as an exception, for example?) Can you capture its
type with typeof()? Can you declare a function with a paramter of type
pointer-to-lambda-function? Is this discussed, or am I missing something?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
re it's known whether or not EH is really needed.
I believe that you need the personality routine if you will be unwinding
through a function, which is why -fno-exceptions is the test.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Michael Eager wrote:
> Mark Mitchell wrote:
>>> Generating __gxx_personality_v0 is suppressed with the -fno-exceptions
>>> flag, but it would seem better if this symbol were only generated
>>> when catch/throw was used. This happens in cxx_init_decl_processing(),
&
Michael Eager wrote:
> Mark Mitchell wrote:
>> Michael Eager wrote:
>>> Why should the personality routine be included in all C++ programs?
>>
>> Because all non-trivial, exceptions-enabled programs, may need to do
>> stack unwinding.
>
> It would seem
the personality routine here. Unless the entire program doesn't
contain anything that needs cleaning up, we'll still need it in the
final executable, but omitting it would make our object files smaller,
and unwinding a little faster, since we don't call personality routines
that aren't there.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Daniel Jacobowitz wrote:
> On Sun, Nov 12, 2006 at 05:11:39PM -0800, Mark Mitchell wrote:
>> Daniel Jacobowitz wrote:
>>
>>> If you try what Michael's been saying, you'll notice that trivial
>>> C++ files get the personality routine reference even if the
e the list here:
http://gcc.gnu.org/wiki/GCC_4.1.2_Status
as you encounter such PRs.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
. Also, in the paradigm described above,
"blocker" should mean "blocks the user from making progress, there is no
workaround", not "blocks the release". (In my experience, severities
are normally things like "mild", "critical", "emergency.)
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
yet written out to the
DWARF information (like GCC machine modes), but most things (types,
functions, variables) are present.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
l review these patches in the next couple of days.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
meone against fixing this? What would be the preferred message?
I slightly prefer the more-grammatical C++ version, but, if there's any
controversy at all, I'm perfectly happy with the C version too, and it's
certainly a good thing to use the same message in both languages.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
ndomly"
choosing between two equally good choices?
Have you tested with flag_check_canonical_types on, and verified that
you get no warnings? (I agree that a --param for that would be better;
if a user ever has to turn this on, we broke the compiler.)
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
ng an external MPFR, so that
people who do have it on their system can leverage that. So, we still
have to decide whether to allow older versions.
On that point, I agree with previous posters who have suggested we
should be liberal; we can issue a warning saying that we recommend
2.2.1, but not req
I can no longer do inside a just built GCC do:
> ./cc1 t.c
> or
> ./xgcc -B. t.c
> If I used the same prefix of an already installed GCC.
> This makes debugging driver issues without installing the driver again.
What are the contents of t.c? What if you set GCC_EXEC_PREFIX?
--
M
w I have to set that now.
> Seems like a change like this should be mentioned on
> http://gcc.gnu.org/gcc-4.3/changes.html
> Because some people liked the old behavior when debugging the driver.
This not a user-visible change; it does not affect installed compilers.
It only affects GCC deve
27;s fine by me.
But, fwprop is described as a new feature (faster compiler, better
code), and the build system affects people building the compiler. The
change we're talking about seems to affect only people debugging the
compiler.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Paolo --
The GCC SC has appointed you as a co-maintainer of the build machinery.
Please add an appropriate MAINTAINERS entry.
Congratulations, and thank you for accepting this position!
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
ctice, we probably won't "miscompile" many
non-conforming programs, and we probably won't miss two many useful
optimization opportunities.
Perhaps Richard G. would be so kind as to turn this off in VRP, and
rerun SPEC with that change?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Ian, and I are all agreed on that point,
and, I think, that disabling the assumption about signed overflow not
occurring during VRP (perhaps leaving that available under control of a
command-line option, for those users who think it will help their code),
is the right thing to try.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Richard Guenther wrote:
>> Perhaps Richard G. would be so kind as to turn this off in VRP, and
>> rerun SPEC with that change?
>
> I can do this.
Thank you very much!
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
e using to build the libraries), rather than the $host->$target
compiler (which may be the one in the tree).
Given the constraints, I'm not sure that autoconf is a huge win. I'm
not violently opposed, but I'm not sure there are big benefits.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
ith a final release approximately a week later.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
being made.
FYI,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
gree with Joe
that there's benefit in getting these closed out. On the other hand, if
someone wants to create an UNREPRODUCIBLE state (which is a "terminal"
state, like WONTFIX), that's OK with me too. But, let's not dither too
much over what state to use.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
y
provide performance advantages, but makes the security part harder. If
someone handed me a contract to write a secure application, with a
penalty clause for security bugs, I'd sure be looking for a language
that raised exceptions on overflow, bounds-checking failures, etc.)
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
were enough people unhappy about bugs, there would be more people
contributing bug fixes.
It may be that not too many people pick up 4.2.0. But, if 4.3 isn't
looking very stable, there will be a point when people decide that 4.2.0
is looking very attractive. The worst outcome of trying to d
at security-critical packages are that much
less likely to do bad things, while making the rest of the system go
faster by not using the option.
I think we've selected a very reasonable path here.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
ed to get us to being
able to handle most of C.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Introduction
This document summarizes work remaining in the LTO front end to
achieve the initial goal of correct operation on single-file C
programs.
Changes to the DWARF R
state the problem and ask for help (as you did) without
attacking anyone.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
t seen a
response to this point.
Certainly, if we're generating zillions of zero-initializations to
contiguous memory, rather than using memset, or an inline loop, that
seems unfortunate. Would you please file a bug report?
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
with arrays. Another
possibility is that we're SRA-ing a lot of small structures, which add
up to a ton of stack space.
I realize that we need a full bug report to be sure, though.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
unspecified* behavior.
In practice, this warning from GCC is keyed off what it thinks the
effective range of "E" is. If it starts assuming that "e" can only have
the values { 0, 1 }, it will also stop warning about the missing case.
It would be hard to stop emitting the warning without making that
assumption, and it may not be easy to make the assumption, but still
avoid the expensive masking operations.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
know of problems that you think should prevent a 4.1.2 release,
particularly critical regressions from earlier 4.1.x releases, please
make sure that there is a Bugzilla PR for the issue of concern to you,
and send an email to me with a pointer to the PR.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL
tbp wrote:
> On 1/28/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>> Certainly, if we're generating zillions of zero-initializations to
>> contiguous memory, rather than using memset, or an inline loop, that
>> seems unfortunate. Would you please file a bug report?
o make your own decisions, but, personally, I
would certainly feel free to assume that no undefined behavior happened
in the application -- but I wouldn't assume that no unspecified behavior
occurred.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
ay to get rid of this use of
> TREE_COMPLEXITY
I refrained from specifically criticizing RTH's check-in, but I did not
in any way try to defend his use of TREE_COMPLEXITY. I agree that using
TREE_COMPLEXITY for OpenMP is undesirable, and that we should eliminate
that use.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Steven Bosscher wrote:
> On 1/29/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>> Email is a tricky thing. I've learned -- the hard way -- that it's best
>> to put a smiley on jokes, because otherwise people can't always tell
>> that they're jokes.
&
dd me to
the CC: list for the issue. Please do not send me reports without first
filing a PR, as I am unable to keep track of all the issues if they are
not in the database.
We'll do either the final GCC 4.1.2 release (if all goes well), or RC2
(if it doesn't) in about a week.
Th
Rask Ingemann Lambertsen wrote:
> On Sun, Jan 28, 2007 at 11:53:41AM -0800, Mark Mitchell wrote:
>> I plan to create GCC 4.1.2 RC1 sometime this afternoon, US/Pacific time.
>>
>> Therefore, please do not make any checkins to the 4.1 branch after 2PM
>> PST. Once RC1 i
h to 4.1 because it
requires a newer GAS. Paul's counter that the newer GAS is only needed
if your compiler would otherwise crash seems persuasive to me, if true,
but I'd certainly want Richard to be comfortable with the change.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Joseph S. Myers wrote:
> On Tue, 30 Jan 2007, Mark Mitchell wrote:
>
>>>PR target/30370 (powerpc-unknown-eabispe can't build libgcc2) is a
>>> regression from 4.1.1. A patch was posted earlier this month at
>>> http://gcc.gnu.org/ml/gcc-patches/2007-01/
Paul Brook wrote:
> On Wednesday 31 January 2007 01:26, Mark Mitchell wrote:
>> Robert Schwebel wrote:
>>> What about PR28516, would it be acceptable for 4.1.2?
>> There are two issues:
>>
>> (1) it's not marked as a 4.1 regression, let alone a regressio
ate and Joe) for the information. I'm not going to
consider this issue a showstopper, but if setting CONFIG_SHELL doesn't
fix it, I would consider it more serious. Please let me know if that's
the case.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
ill make
that decision after getting the answers to the issues above.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
derstand correctly, the aliasing algorithm in 4.1 has relatively
fundamental problems, which is rather different.)
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
o warrant
> this.
For the record, I don't think the workaround argument is as strong,
though. When the user compiles a large application and it doesn't work,
there's no hint that -fno-strict-aliasing is the work-around. It's not
like an ICE that makes you think "Hmm, m
ould get comlicated
in a hurry.
I think clobbering the PC is a reasonably good way to represent a
control-flow barrier at user level.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Bugzilla.
Based on the absence of issues reported for GCC 4.1.2 RC1, I expect GCC
4.1.2 to be identical to these sources, other than version numbers, and
so forth. I intend to spin the final release early next week.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
n GCC 4.1.2?
Unfortunately, I think it's too late for that. Java is not a major
release priority, and at this point I'm not anticipating a 4.1.2 RC3.
However, I would suggest that we apply the patch to the 4.1 branch after
4.1.2 is released, assuming that the Java maintainers
sparc64 -fpic/-fPIC.
This is unfortunate, but I don't see any evidence of a major blocking
issue there.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
approved for
mainline and 4.2. However, the same rules apply: I'll back it out,
rather than try to fix it, for a final release.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
ssue; it would be bad for Mozilla, KDE,
> etc., to suffer a significant optimization issue in going from 4.1.1 to
> 4.1.2. I was pretty determined to get 4.1.2 out the door, and I really
> don't want to have any functional changes between the last RC and the
> actual release. So, I feel that I have no choice but to do a 4.1.2 RC3
> with a more conservative version of DECL_REPLACEABLE_P.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Richard Henderson wrote:
> On Mon, Feb 12, 2007 at 10:06:11AM -0800, Mark Mitchell wrote:
>> Does it seem overly aggressive to you to assume "f" cannot throw
>> in "g", given:
>>
>> void f() {}
>> void g() { f(); }
>>
>> where
However, if there were really some special case where we could do
markedly better without it, and no feasible way to give the special-case
information to the core DF code, then I'm sure everyone would agree that
it made sense to use something different. But, that would be only in
extraordinary sit
1 - 100 of 1433 matches
Mail list logo
