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
memory/time to compile?
And might recent changes in tree-ssa have increased memory and compile
time? A frysk build for example is a lot (almost twice) as slow with svn
trunk compared with 4.1.1. See also:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30588
Cheers,
Mark
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
it was a good idea, but at the time it was received
> unenthusiastically. I especially think "just use __builtin_trap()"
> misses the mark - at least some variants of the Linux kernel's BUG()
> macro, for instance, want to stick annotations in the assembly stream,
> wh
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
Richard Henderson wrote:
> On Mon, Feb 12, 2007 at 01:16:43PM -0800, Ian Lance Taylor wrote:
>> Mark Mitchell <[EMAIL PROTECTED]> writes:
>>
>>> But, aren't big C++ shared libraries rather different? Does KDE
>>> actually use throw() everywhere, or
so doing we'd lose bug
fixes for (other) correctness issues.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
timezone changes and Joseph's update of translation files. If the build
change for non-standard shells is also checked in tonight that's fine;
if not, there's a good workaround.
So, my current intent is build the final 4.1.2 release tomorrow evening
in California.
Thanks,
--
accurate information is
available.
My point is that I don't think that the right criteria for DF is whether
it makes the generated code faster. So long as it doesn't make the
generated code slower, and so long as the APIs seem well designed, and
so long as it doesn't make the compiler it
tions not
to be locally bound in shared libraries (which it determines by checking
flag_shlib) and flag_shlib is generally set if flag_pic is true.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
*/
> /* { dg-options "-O1 -fdump-tree-cfg" } */
> +/* { dg-skip-if "" { "*-*-*" } { "-fpic" "-fPIC" } { "" } } */
> double a;
> void t()
> {
I think this makes sense. At worst, it's overly conservative, and the
tes
The 4.1 branch is now open for changes under the usual regression-only
rules for release branches.
Here are the changes that I commited during the release process.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
2007-02-14 Mark Mitchell <[EMAIL PROTEC
ns for 4.2.0, and such comments would be entirely germane
in response to that message. But, for the purposes of this message,
please assume a 4.2.0 based on the 4.2 branch in the usual way.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
l have a 4.2.0 release by (worst case, and allowing for
lameness on my part) March 31.
Feedback and alternative suggestions are welcome, of course.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
-3.9%
> 459.GemsFDTD-18.3%
> 465.tonto -2.5%
> 470.lbm -4.1%
> 481.wrf -2.7%
What does that translate to in terms of overall score?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
no reason to expect that,
and I think two person-months is rather much.
Therefore, it sounds like the practical choices are revert the patch and
accept the bugs, or vice versa. Is there any reason to expect the bugs
to be particularly more prevalent in 4.2 than they were in 4.1?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
a smaller
regression relative to 4.1.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Paweł Sikora wrote:
> Current development line of PLD-Linux uses 4.2 too.
Thanks for that information.
> Mark, could you add the PR30052 to your 4.2-TODO ?
Did you mean personally? If so, I have no particular plans to work on
this PR. I'm afraid that my GCC time is pretty limit
er upgrading from 4.1.x to 4.2.0 will see a
regression, or if the 4% will be absorbed by other improvements. If
someone with a different chip is willing to provide the same
measurements, that would help eliminate Intel-specific characteristics
in the data as well.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
7;t imagine there would be; that seems like a good thing. However,
please avoid the bikeshed: we can all fuss over what font size to use,
etc., but there's not much upside. I vote you pick something, and we
all accept it. :-)
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Grigory Zagorodnev wrote:
> Mark Mitchell wrote:
>> Excellent question; I should have asked for that as well. If 4.2 has
>> gained on 4.1 in other respects, the 4.7% drop might represent a smaller
>> regression relative to 4.1.
>>
> There is the 4.2 (r120817) vs
le, trading potential aliasing bugs for performance, if that
seems like a win.
It doesn't make sense to compare unmodified FSF 4.2 compilers with
distribution-optimized 4.1 compilers.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
rom C.
The attribute syntax above works in both C and C++, and is
backwards-compatible; without the "(N)" you just get the default
initialization priority, as you do at present.
I plan to merge this functionality to the GCC mainline. Does anyone
object to this feature, in principle?
T
.2 branch? Are you able to try reverting the
aliasing patches to see how much of an impact they have on Itanium? It
would be interesting to know how that compares with the 4% on IA32.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
n
>> mainline, as they have been for more that three months.
>
> This patch (not yet approved) is my contribution to fixing the
> problem.
>
> http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00021.html
Please let me know if you feel this has gotten stuck, and I will try to
help mo
inger in my report next Monday. :-) Of course, that's not to say that
non-maintainers shouldn't contribute as well!
Let's get it done!
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
[1] http://gcc.gnu.org/ml/gcc/2007-02/msg00427.html
[2]
http://gcc.gnu.o
one of the choices are particularly pretty.
Ian, please do the backport and check in the changes as soon as you can.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Manuel López-Ibáñez wrote:
> On 05/03/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>> After reviewing all of the traffic[1] that stemmed from my previous
>> status report, I've decided that, indeed, it makes sense to steam ahead
>> with GCC 4.2.0 based on
the 4.3 marker there. In
future, when you fix a bug, please remove the release from the Summary
section, if you remember. (I forget too...)
> - 27986 This is in fact a variation of the issue in 21596, except this
> one crosses basic blocks. It will require all new work to get this case.
>
oudert
* David Daney
* Jerry DeLisle
* David Edelsohn
* Steve Ellcey
* Ben Elliston
* Daniel Franke
* Kaveh Ghazi
* Richard Guenther
* Richard Henderson
* Geoffrey Keating
* Thomas Koenig
* Simon Martin
* Andrew MacLeod
* Mark Mitchell
* Brooks Moses
* Joseph Myers
* Alexandre Oliva
* Andrew Pi
R 30221 (Sidwell, Mitchell) -- An ICE-on-valid for initializing
arrays of pointer-to-member functions in C++.
* PR 30590 (Guenther, Merill) -- Wrong code generated by NRV.
* PR 30700 (Hubicka) -- Cgraph causes undefined references.
* PR 30704 (Edelsohn) -- Bad code generation for long long on big-endi
Ulrich Weigand wrote:
> Mark Mitchell wrote:
>
>> * PR 28544 (Brook, Weigand) -- this is an ARM ICE which Paul has tracked
>> to reload, but he's not sure what to do there. Perhaps Ulrich can help.
>
> This description doesn't appear to match the bugzilla recor
last argument, the answer is as I expected. This seems odd to me;
is it the intended behavior?
The patch below (which is against an older version of libiberty, and
might need updating) fixes it. Assuming you agree that this is a bug,
would this patch (with updating and testing) be OK?
Thanks,
--
Ma
r to focus testing on the actual prereleases, as those are most
likely to contain any defects that I might introduce into the actual
release as well.
(*) I guess this should really be Beta 1; it's not quite a release
candidate, yet, in that I fully expect changes after this point.
Thanks,
--
Daniel Jacobowitz wrote:
> On Mon, Mar 12, 2007 at 10:47:28PM -0700, Mark Mitchell wrote:
>> It treats only "/opt" as a common component of the two paths, rathe
>> than "/opt/foo". If you use "/opt/foo/" (instead of "/opt/foo") for
>>
we do for
releaes), doc/gcc.1 is in the source directory. VPATH finds it, so the
dependency is satisfied, but the copy doesn't work.
I intend to fix this by changing the rule to be:
cp $< doc/g++.1
which will resolve VPATH correctly. Does anyone see a problem with this
plan?
Than
The GCC 4.2.0 RC1 build has failed (on x86_64-unknown-linux-gnu) with:
Comparing stages 2 and 3
Bootstrap comparison failure!
./java/parse.o differs
./java/parse-scan.o differs
Has anyone else seen this?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
t them to behave. Zero FAILs may not be
achievable on all targets, but if I had a magic XFAIL wand, that would
put the right XFAIL goo into all tests before every release so that all
users who built the toolchain correctly always got zero FAILs, I would
do it.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
So, the only real solutions are (a)
expand the width of the code field and (b) use subcodes. And, I agree
that we should do all we can to avoid expanding the size of tree nodes.
So, I think the subcode approach is the best choice.
Like Ian, I think the macros above are fine.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Joseph S. Myers wrote:
> On Tue, 13 Mar 2007, Mark Mitchell wrote:
>
>> The GCC 4.2.0 RC1 build has failed (on x86_64-unknown-linux-gnu) with:
>>
>> Comparing stages 2 and 3
>> Bootstrap comparison failure!
>> ./java/parse.o differs
>> ./java/parse-scan
ild GCC releases on an RHEL3 box. However, I
believe that I was using a version of GCC 3.4.x (built by CodeSourcery)
as the bootstrap compiler. It does seem like a suspiciously similar
situation, though; I'm sure that Joseph will be able to tell us if the
problem is reproducible with GCC 3.4.x
@ $<
And, then, just have java/parse.o depend on $(java_parse_c)?
I was going to give this a try, but if you know whether it's going to
break, let me know. :-)
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
uming that we can't do that, I'd rather
just fix the Makefiles, if there are any more such problems. As
Joseph's noted, the Java problem is already gone on mainline, thanks to
the ECJ integration.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Paolo Bonzini wrote:
> Mark Mitchell wrote:
>> Paolo Bonzini wrote:
>>
>>> IIUC, the problem only manifests while *building* the release candidates,
>>> not for users of the release candidate.
>>>
>>> For 4.2, my suggestion is to just use a bootst
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.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
TE_EXPR.
Especially (2) and (3) are relatively easy transformations. (2) is
unquestionably something that we want to do anyhow.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
compilation of the
compiler and runtime libraries.)
So, I still believe that I'll be able to build GCC 5.0 (on hardware
available at that point) in less time than it took to build GCC 3.4 (on
hardware available at that point).
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
; data structure so there will be a
> memory usage hit, I don't think there's disagreement about that.
I thought the plan was to this in TYPE_LANG_SPECIFIC, etc., so that it's
not a generic effect on all trees?
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
ompilers go.) They're complex.
I think I'm inclined to agree with Mike: I'm starting to prefer (2).
It's a simple solution, and pretty efficient. Anyone want to champion
(1) or (3)?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Jim's patch for PR 31273 tonight.
Joseph, would you please take a look at PR 31136? Andrew believes this
to be a front-end bug.
My hope is that we can fix these PRs, and then declare victory on the
GCC 4.2.0 release.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Mark Mitchell wrote:
> There are still a number of GCC 4.2.0 P1s, including the following which
> are new in GCC 4.2.0 (i.e., did not occur in GCC 4.1.x), together with
> -- as near as I can tell, based on Bugzilla -- the responsibility parties.
>
> PR 29585 (Novillo): ICE-on-v
th the additional steps you mention? I have no
opinion, but it might help Bruce to know for sure whether he's heading
in a direction you're likely to approve.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Joseph S. Myers wrote:
> On Thu, 22 Mar 2007, Mark Mitchell wrote:
>
>> Joseph, would you please take a look at PR 31136? Andrew believes this
>> to be a front-end bug.
>
> I don't think this is a front-end bug.
Thank you for investigating.
> (OK to commit this
Diego Novillo wrote:
> This one seems to be a bug in the C++ FE, compounded by alias analysis
> papering over the issue.
Doh! Thank you for tracking this down.
> Mark, does this look OK? (not tested yet)
>
> In
levels is obscure, and should probably be overhauled at some
point. But, this is it's current state, and it's been that way for a
long time, so to resolve this issue, we should just play the same game.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
#x27;t symbol-tablish? A not-so space-efficient approach would be to
allocate out of an ordinary block of memory, using ordinary pointers,
and then swizzle into self-relative pointers at serialization time.
Then, when you deserialize, you could just leave them self-relative, or
swizzle them back.
s, that we make
> the references be pc-relative.
Self-relative, not PC-relative, right? (If so, that happens to be what
I was suggesting earlier.)
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
he
FSF. I hope you choose to do that, as everyone agrees that this is good
stuff to have!
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
MAINTAINERS file to reflect your new appointment,
and thank you for agreeing to take on this responsibility!
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Thus, only users who want pedantic error messages see the message. They
can control whether the message is an error or a warning via
-pedantic-errors (or the C++ front-end's -fpermissive).
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
ism towards CodeSourcery personnel.
What do people think of that suggestion?
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
any closer to
release. And there's a good bit more functionality that we want to get
into 4.3, which, in the way of things, is likely to introduce new bugs,
no matter how positive its overall impact.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
me scripts are
> large and slightly clever, others are short and obvious.
For safety sake, we should probably get assignments on them. I'm not
sure how hard it is to get IBM to bless contributing the scripts. If
it's difficult, but IBM doesn't mind them being made public, perhaps
and just "Copyright
> FSF " on the small ones.
I guess I'd tend to be conservative and put the full GPL notice on all
of them. If it doesn't apply because the file is too small, whoever
wants to use it in some non-GPL way can assert that fact if they want.
Is there some
n just make the change. Of course, if people would prefer
that I ask the SC, I'm happy to do so.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
C 4.2 status report, and various other opinions
that have been presented to me. I've got some ideas, but I want to let
them percolate a bit before trying to write them down. In any case, I
want people to know that I'm listening.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
bled in a machine-independent way, by checking some property of the
back end, that would be superior.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Kaveh R. GHAZI wrote:
> On Mon, 23 Apr 2007, Mark Mitchell wrote:
>
>> I'm certainly not trying to suggest that we run SPEC on every
>> architecture, and then make -O2 be the set of optimization options that
>> happens to do best there, however bizarre.
>
>
27;t have it)
and you are a maintainer of the affected part of the compiler, please
mark the issue as P3, add a note to the issue explaining why you think
it should have higher priority, and CC: me. My default reaction will
probably be to deprioritize the issue -- especially if there's no pa
this and proposed a patch. Richard, is this
ready to go? If not, do you need help?
4. PR 31360: Missed optimization
I don't generally mark missed optimization bugs as P1, but not hoisting
loads of zero out of a 4-instruction loop is bad. Zdenek has fixed this
on mainline. Andrew says
Zdenek Dvorak wrote:
> Hello,
>
>> 4. PR 31360: Missed optimization
>>
>> I don't generally mark missed optimization bugs as P1, but not hoisting
>> loads of zero out of a 4-instruction loop is bad. Zdenek has fixed this
>> on mainline. Andrew says th
t;
> Danny identified the fix on the mainline, I applied it to the branch
> after testing. So that's fixed as well.
Thanks!!
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
In case anyone here sends me an email, and gets my vacation auto-reply
for the next week: I do still plan to proceed with the 4.2.0 release
schedule in my last status report.
FYI,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
?
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Mark Mitchell wrote:
> Zdenek, I would still be interested in a fix for PR31360. From the
> audit trail, it looks like your patch for this PR on mainline causes
> another problem (PR 31676), and that you are not working on PR 31676
> because you cannot build for powerpc-linux-gnu. (
hat the branch is now frozen:
that will give us a better chance at solving this problem, without
introducing new ones.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
, please download and test the actual
tarballs, rather than checking out from SVN tags, in order to help
detect packaging problems.
If you find a problem, please do not email me directly. Instead, file
an issue in Bugzilla:
http://gcc.gnu.org/bugzilla/
Thank you,
--
Mark Mitchell
CodeSourcery
o- to turn this off.)
In any case, we're not going to do this for 4.2.0. As per the policy I
posted recently on PRs, please find a C++ maintainer who wants to argue
for backporting this and ask them to mark the PR as P3 with an argument
as to why this is important to backport.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
change my mind
about that.
Please see:
http://gcc.gnu.org/ml/gcc/2007-05/msg00032.html
for information about reporting problems.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
,
against an SVN checkout, match what you see today, with a release tarball?
This is in no way a criticism, or a comment on RETMS testing (about
which I know almost nothing), etc.; just a general comment, which your
message gave me the excuse to make. :-)
Thanks,
--
Mark Mitchell
CodeSourcery
problems without requiring any tuning of the inlining algorithms. Has
anybody experimented with that potentially much less intrusive fix?
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
acceptable for 4.0 that would give people an easy to understand way of
getting the compiler to do what they want: put "inline" on functions
they really want to have inlined. That's in addition to the existing
heuristics. I think that's a plausible way of mitigating the pr
101 - 200 of 1839 matches
Mail list logo
