Richard Henderson wrote:
On Thu, Apr 14, 2005 at 05:26:15PM -0700, Mark Mitchell wrote:
Richard, what's your level of confidence here? I'd rather not break C++
or Java...
I think it's pretty safe.
OK, Alexandre, please install the patch.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL
4.0.0.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
even for this bug, though. Instead, I'm
going to get 4.0.0 out the door, and move on to 4.0.1, sticking as close
to the announced schedule as possible.
So, there will be a 4.0.0 release within the next week.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
out the door in the next few days; then on to 4.0.1...
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
Kaveh R. Ghazi wrote:
> > 2005-04-12 Paolo Bonzini <[EMAIL PROTECTED]>
> >
> > * acx.m4 (ACX_PROG_GNAT): Remove stray break.
>
> OK for 4.0.0.
Mark,
When this patch went into 4.0, Paolo didn't regenerate the top level
configure, although the ChangeLo
Richard Sandiford wrote:
Results for mips-elf are here:
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01331.html
and look good. No regressions.
Thanks; added to the Wiki.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
, but I do think any fix will be too
intrusive for 4.0.0. I'd suggest that we try to fix it for 4.0.1.
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Andrew Haley wrote:
Geoffrey Keating writes:
> Mark Mitchell <[EMAIL PROTECTED]> writes:
>
> > RC2 is available here:
> >
> > ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.0-20050417/
> >
> > As before, I'd very much appreciate it if p
Geoffrey Keating wrote:
Mark Mitchell <[EMAIL PROTECTED]> writes:
RC2 is available here:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.0-20050417/
As before, I'd very much appreciate it if people would test these bits
on primary and secondary platforms, post test results with the
contrib/t
Eric Botcazou wrote:
SPARC/Solaris is OK:
Thanks; I've added your information to the Wiki.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
. Based on the follow-up, and the fact that Java is not
release-critical, this is not a showstopper. FWIW, we've seen similar
problems on HP-UX; there's confusion about which paths will be searched
by the build compiler vis a vis the compiler we're building.
--
Mark Mitchell
Co
ss.c for remove_zero_width_bitfields. (Spelling might be a
little off.)
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Joe Buck wrote:
On Mon, Apr 18, 2005 at 07:44:03AM -0700, Mark Mitchell wrote:
RC2 is available here:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.0-20050417/
x86_64-unknown-linux-gnu results (for RHEL v3) are at
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01333.html
The failures are almost all
Joseph S. Myers wrote:
Results for hppa2.0w-hp-hpux11.11, no regressions:
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01379.html
Thanks; posted on the Wiki.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
is a fine value to represent "unknown" -- the fact
that it's likely to cause crashes is probably a feature, in that any
parts of the compiler that go trying to use the field will probably be
found more quickly. So, your original patch is fine for mainline. It's
also OK for
The GCC 4.0 branch is now open for regression fixes only, under the
usual release branch rules.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
/changes.html
This release is available from the FTP servers listed here:
http://www.gnu.org/order/ftp.html
The release is in the gcc/gcc-4.0.0 subdirectory.
As usual, a vast number of people contributed to this release -- far too
many to thank by name!
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL
Toon Moene wrote:
Mark Mitchell wrote:
The GCC 4.0 branch is now open for regression fixes only, under the
usual release branch rules.
I presume this means that we (The Fortran Illuminati) can fix any bug in
the gfortran frontend, as we don't have any regressions yet (at least
not ag
ay
enough to be useful in some circumstances.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
ful -- except for testing GCC. I'd build GCC on
some fast workstation, even if I eventually wanted it to run native on
the target.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
s
look like? In the meantime, I'm trying to plan 3.4.4
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
itical C++ bugs that I fixed, and
backport the patches. I'd encourage others to do the same, and
to look in particular at wrong-code problems that affect your favorite
platforms.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
e case-by-case judgements. But, I do think
that preference should be given to those projects that were previously
announced, and that if your changes seem too invasive, it might be
reasonable to hold them for 4.2. We shall have to see.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Paolo Carlini wrote:
Hi Kriang and Mark,
[ friend PRs snipped ]
I know that, technically, we are not talking about regressions wrt 3.x, still, important packages that used to compile and, well, apparently at least, *work* well, now don't even compile (see c++/19403, c++/21235, many others l
; it might make sense to
use WONTFIX if the bug was introduced on the 3.4 branch and never
present elsewhere.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Richard Guenther wrote:
On 4/29/05, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Joseph S. Myers wrote:
What's the position on closing 3.4 regression bugs which are fixed in 4.0
and where it doesn't seem worthwhile to attempt to backport a fix?
They should be closed as FIXED, with a no
us friend declarations
around, and I'd expect that as a KDE distributor you would want to
encourage them to use the syntax that means what they want, even in
parallel to possibly fixing the compiler.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Paolo Carlini wrote:
Hi Mark,
I agree; that's why I asked to see the patches.
Humm, maybe a couple of links are in order, for your convenience:
http://gcc.gnu.org/ml/gcc-cvs/2005-03/msg00681.html
http://gcc.gnu.org/ml/gcc-cvs/2005-03/msg00679.html
(I understand that Kriang volunteer
casual look suggests that there are at least some
of those that should not in fact have a release target. We do still
have a lot of 4.0 regressions, though, that also apply to 4.1; I would
encourage people to particularly target PRs that apply to both releases.
--
Mark Mitchell
CodeSourcery, L
27;s really far from being a
major change. I'll be away for the next two weeks, Keith may submit it as
he may need this bit for Item 2.1 (versioning for alignment).
I agree, this can be part of Stage 2.
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Steven Bosscher wrote:
On Thursday 05 May 2005 07:40, Mark Mitchell wrote:
# CFG Transparent Inlining, Profile-Guided Inlining (1.3)
This one was submitted on April 29, but nobody has reviewed it.
# Compilation Level Analysis of Types and Static Variables (1.3)
# Pre-Inline Optimizations (1.3
tween us developers and them? I would
like to better understand the actual problems these users see that we
developers might be missing.
Thanks,
Mark
--
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
Join the community at http://planet.classpath.org/
signature.asc
Description: This is a digitally signed message part
\
: (REGNO) == CR2_REGNO ? 64 \
: DBX_REGISTER_NUMBER (REGNO))
and, in rs6000_dbx_register_number:
if (regno == LINK_REGISTER_REGNUM)
return 108;
So, for non-EH, we get 108.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Andrew Pinski wrote:
On May 6, 2005, at 7:48 PM, Mark Mitchell wrote:
On PowerPC, we have a test case which results in a mismatch between
the register number used for the return address in the DWARF2 CIE and
the FDE. That causes backtraces to go wonky. The test case is kinda
big, but I&#x
>
Probably; so, if you submit preprocessed source, etc., that will
probably help. I'm pretty sure that patch was bootstraped on
x86_64-unknown-linux-gnu, so it's probably something freebsd-ish.
I can volunteer Julian to look into it, once you file a full report. :-)
--
Mark Mi
some tricky bits, in that if we're doing a dynamic
initialization, we presently cannot mark it TREE_READONLY, but this is a
static initialization, so it should be fine. Isn't TREE_OPERAND (T, 0)
the VAR_DECL for array itself? If so, waht's probably going wrong is
that i
sable
literal, yes?)
No, it's not.
static const int i = f();
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Steve Kargl wrote:
On Mon, May 09, 2005 at 05:03:23PM -0700, Mark Mitchell wrote:
Steve Kargl wrote:
I suspect the problem arose with this commit
2005-05-08 Julian Brown <[EMAIL PROTECTED]>
H.J. Lu <[EMAIL PROTECTED]>
Paul Brook <[EMAIL PROTECTED]>
Pr
than you could have
expected. :-)
So, if you've got 3.4.x patches that you want to get in, work quick.
After the freeze, and before the release, I'll likely approve only
patches to fix wrong-code bugs.
FYI,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
GCC 3.4.4 is now slushy.
All non-documentation patches require my explicitly approval.
3.4.4 RC1 will be building overnight.
FYI,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
g to rebuild
the compiler, which seems better than any autoconfery.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
serious regressions from previous 3.4.x compilers.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
e compiler treats all
parameters as if they had this atrribute. We would then also add a
switch to disable the optimization for people who have legacy code, just
as we have -fno-strict-aliasing.
[ I did not discuss this with Kenny, but another option is to have a
-fassume-X switch, off by default, which treats your code as if you had
the magic attribute everywhere. ]
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
must make the conservative assumption.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Giovanni Bajo wrote:
Mark Mitchell <[EMAIL PROTECTED]> wrote:
Our proposed approach is to -- by default -- assume that "g" may
access all of "b". However, in the event that the corresponding parameter to
"g" has an attribute (name TBD, possibly the same as th
Bernd Jendrissek wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, May 11, 2005 at 11:42:05AM -0700, Mark Mitchell wrote:
no obvious answer.
May I bash my head against the wall? :)
Sure, it's a free world!
The struct declaration places an obligation on the compiler to provi
Wolfgang Bangerth wrote:
Mark,
it occurred to me that asking the question you pose may use language that is
more unfamiliar than necessary. How about this question instead -- assume
struct S { int s; };
struct X {
int i;
struct S s;
};
void g(struct S*);
void f() {
X x
Theodore Papadopoulo wrote:
On Wed, 2005-05-11 at 15:30 -0700, Mark Mitchell wrote:
Given the following:
struct A {
B& b1;
B& b2;
const B& b3;
A(B& b): b1(b),b2(b),b3(b) { }
};
Is the compiler allowed to suppress b2 and/or b3 from the layout of the
object. T
GCC 3.4.4 RC2 is now available here:
ftp://gcc.gnu.org/pub/gcc/prerelease-3.4.4-20050512
There are just a few changes from RC1 to fix critical problems people
experienced with RC1.
Please download, build, and test.
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Andreas Schwab wrote:
Ulrich Weigand <[EMAIL PROTECTED]> writes:
It would appear the problem is this patch:
2005-05-12 Mark Mitchell <[EMAIL PROTECTED]>
2005-04-04 Mark Mitchell <[EMAIL PROTECTED]>
* testsuite/Makefile.am (check-local): Remove.
The problem i
branch.
Yes, I asked Janis to test each branch separately, because the patches
were separate. She has confirmed that the 4.0 version of the patch
works OK. So, that patch will go on 4.0 today, along with the
additional patch Andreas found.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED
Andreas Schwab wrote:
Mark Mitchell <[EMAIL PROTECTED]> writes:
While I really do appreciate your help, such changes need my approval.
We are in a freeze situation, which means I might be spinning a release
at any moment. Please consult with me in future in such situations.
I apologi
Ulrich Weigand wrote:
Greg Schafer wrote:
On Fri, May 13, 2005 at 03:44:59PM -0700, Mark Mitchell wrote:
GCC 3.4.4 RC2 is now available here:
ftp://gcc.gnu.org/pub/gcc/prerelease-3.4.4-20050512
There are just a few changes from RC1 to fix critical problems people
experienced with RC1.
Please
rty headers, including
hashtab.h, by substituting a simple dictonary object.
3. Adjust struct-layout-1.exp accordingly.
Thoughts?
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
struct-layout-1.exp accordingly.
This is what I would recommend anyhow.
OK; that's what we'll do, then.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Once we've validated, we'll go ahead and check
in your patch.
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
d you care to take a try? It sounds
like Ian would probably approve it, or maybe one of our build
maintainers would.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Etienne Lorrain wrote:
GCC 3.4.4 RC2 is now available here:
ftp://gcc.gnu.org/pub/gcc/prerelease-3.4.4-20050512
There are just a few changes from RC1 to fix critical problems people
experienced with RC1.
Work for me, thanks.
Good; thanks for confirming.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL
for -m32 and -m64 as
expected.
I'm very sorry I didn't notice this earlier.
Not to worry; already fixed! On 3.4, we just had a merge botch, which
Andreas fixed. On 4.0, the behavior you're seeing is as intended; the
ABI test is now included in "make check".
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
e case, there may be no very good solution.
We'll not be able to say for sure unless you post additional information
about the failures.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
will often work, but
create a real file with that name. It would be better, and avoid
portability problems, to guard the calls to fwrite, etc., with "if
(file)" rather than spew to "/dev/null", but that's for another day.)
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTEC
I've very nearly ready to release GCC 3.4.4. If you have objections or
high-priority fixes that you think will be required for this release,
please speak up within the next 24 hours.
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
rograms that might or might not themselves
want to write to things. Of course, this particular program is not
performance-critical, so it's not like anyone has, or should have, tried
hard to make it go maximally fast. :-)
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
have opinions about what the default should be?
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
David Edelsohn wrote:
Mark Mitchell writes:
Mark> In the past, if libiconv wasn't set in site.exp,
Mark> target_supports.exp:check_iconv_available would crash. So, I changed it
Mark> to default to "-liconv".
Mark> On GNU/Linux, that's not a very good defaul
led. Would you please
apply your patch to 4.0 as well, or, if you don't have time, let me know
so that I can do that?
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
included.
I think best would be just to kill this hunk and unconditionally do it the
slower way.
Good point! I checked in this patch, on mainline and 4.0 branches,
after testing on x86_64-unknown-linux-gnu.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
2005-05-17 Mark Mitchell
testsuite issues, but I think it's
OK that we didn't. Thanks for testing!
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
ons; maybe it could.
It's perfectly reasonable to have "typed_decl" as a derived class of
"decl" which contains a type; then "var_decl" and "function_decl" would
be derived from that, for example.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
eek that this was not in fact true, in that you can do:
ptrdiff_t x = &v.b - &v.a;
and then use that instead of "offsetof (Foo, b) - offsetof (Foo, a)".
because (a) badfuncs are more than likely rare and (b) it would be a useful
aid to the programmer.[1] Mark outlines an __I_
Jonathan Wakely wrote:
On Mon, May 16, 2005 at 05:41:03PM -0700, Mark Mitchell wrote:
I've very nearly ready to release GCC 3.4.4. If you have objections or
high-priority fixes that you think will be required for this release,
please speak up within the next 24 hours.
Sorry for the
Nathan Sidwell wrote:
Mark Mitchell wrote:
Will the UK committee open a DR for this? Or, would you care to send
mail to Steve Adamczyk about it?
this can be done. I shall wait until the minutes have been written up.
Excellent.
The observation was made that if A is non-POD, one cannot play
.0 for
which I'm not sure that it has a full ISO C90 library. So I hope
you're not seriously proposing to remove these functions from
libiberty.
Mark
it. So,
I'd claim the optimizer has to know about constants already.
I fail to see your point, unless it is that whether or not you spell "8"
as "8", "&s.x - &s.y", or "offsetof (S, x) - offsetof (S, y)" should not
matter, in which case I ce
ng at gcc-testresults mail showing
allegedly clean results for that platform *and* update:
http://gcc.gnu.org/wiki/GCC%204.1%20Slush
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Kriang Lerdsuwanakij wrote:
Mark Mitchell wrote:
OK. Do you happen to have access to any other testsuites, beyond the
GCC testsuite? If so, it would be great to validate the behavior of
the compiler on the 4.0 branch with and without your patch to make
sure that we're not doing any harm
Paolo Carlini wrote:
Mark Mitchell wrote:
OK, please go ahead and apply the relevant patch -- once we are out of
the slush.
Thanks a lot Mark. To be sure: in my understanding, only mainline is in
slush, not 4_0-branch, where we want to backport the patches. If I'm
mistaken please let us
://www.gnu.org/order/ftp.html
The release is in the gcc/gcc-3.4.4 subdirectory.
As usual, a vast number of people contributed to this release -- far
too many to thank by name!
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
Joe Buck wrote:
On Fri, May 20, 2005 at 05:48:38PM +0100, Dave Korn wrote:
Original Message
From: Mark Mitchell
Sent: 20 May 2005 17:24
GCC 3.4.4 has been released.
This release is a minor release, containing fixes for regressions in
GCC 3.4.3 relative to previous versions of GCC. A more
the order of a day, everyone
can wait; if it's a week, that might be more of a problem.
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Jeffrey A Law wrote:
On Mon, 2005-05-23 at 11:04 -0700, Mark Mitchell wrote:
Jeffrey A Law wrote:
much rather bite the bullet and get them fixed now. The fact that it's
affecting a lot of people keep the coals hot on my feet :-)
Jeff --
I know you're doing everything you can
ation processing we sometimes check whether or not
two declarations match more than once.
The changes you suggest might still be helpful, but I'd prefer to see
the bigger algorithms fixed first, as those changes will have secondary
benefits beyond comptypes as well.
--
Mark Mitchell
CodeSou
Karel Gardas wrote:
On Mon, 23 May 2005, Mark Mitchell wrote:
Mike Stump wrote:
On May 17, 2005, at 3:16 PM, Karel Gardas wrote:
1) the most expensive seems to be comptypes -- at least from data L2
refill point of view (~17%)
2) comptypes is also the most CPU intensive operation since
EMBLER_NAME nor DECL_SECTION_NAME. If we
do, that's a bug in whatever is using them -- but I don't know how hard
it would be to fix. In GCC, things that look like fields, but are
really variables, like C++ static data members or anonymous union
members, should be represented as VAR_DECLs.
--
M
Daniel Berlin wrote:
On Mon, 2005-05-23 at 12:26 -0700, Mark Mitchell wrote:
Daniel Berlin wrote:
While moving FIELD_DECL to it's own substruct, the following questions
have come up. I figured one of you might know:
1. Do we need DECL_ASSEMBLER_NAME on FIELD_DECL? I can't think
s case and otherwise!
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
epresentation, which you can force in C++
by declaring extra enumeration constants of values like UINT_MAX, and
then use explicit casts at places where you want to go back and forth.
I think this is not as nice as the incomplete structure approach.)
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
exception of casting the return value of
malloc, which will be hidden in a macro that's probably less error-prone
that writing out the malloc calls directly) -- but you're concerned
about the fact that doing this work now might make it too easy for us to
switch to C++ without think
Zack Weinberg wrote:
Mark Mitchell <[EMAIL PROTECTED]> writes:
[snip stuff addressed elsewhere]
I agree with the goal of more hiding.
You can do this in C by using an incomplete structure type in most
places, and then, in the files where you want the definition visible,
defini
use of C++ keywords;
>
declaring structure fields with the same name as a structure tag in
scope.
I don't think we should be reverting patches that fall afoul of these
last two, even if they break Gaby's build-with-a-C++-compiler builds.
But, I would tend to accept patches from G
o actually using C++. I'd say just code how
you always have, within our existing coding standards, and ignore the
issue; let people who care fix it up after the fact, or comment on your
patches when you post them.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
lift the slush, effective noon Pacific time tomorrow, i.e., 12
hours from now. However, if three or more global write privileges
people object, then we'll leave it in place at least until I'm back
online and can review the situation.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
ut causing this level
of disruption to other developers.
I agree.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
thout the critical bug before the
next official release.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
Giovanni Bajo wrote:
Mark,
is it OK to remove the link "Last-Minute Requests for 4.0.0" from the Wiki
main page? The page is obviously unneded there. If you want, we can keep the
link somewhere else (like collected in a page "obsolete misc pages").
I tried to remove it --
ute this, using
techniques similar to those in target-supports.exp.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Steven Bosscher wrote:
On Friday 03 June 2005 10:48, Mark Mitchell wrote:
DJ Delorie wrote:
Do we have a standard way of telling the testsuite how big target
types are, or some standard "this test assumes 32 bit int" dejagnu
flag?
I don't think we have any way of doing this
I'd really like to see fixed.
* 21528: SRA and/or aliasing problem.
* 21847: DCE over-eagerness.
* 20928: IA32 ICE.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Steven Bosscher wrote:
On Sunday 05 June 2005 19:18, Mark Mitchell wrote:
The reason that this release is slightly ahead of schedule is because of
a relatively frequently-encountered wrong-code regression in C++.
Which regression is this?
The bug that caused KDE miscompilations.
>
Steven Bosscher wrote:
On Sunday 05 June 2005 19:29, Mark Mitchell wrote:
Steven Bosscher wrote:
On Sunday 05 June 2005 19:18, Mark Mitchell wrote:
The reason that this release is slightly ahead of schedule is because of
a relatively frequently-encountered wrong-code regression in C
301 - 400 of 1846 matches
Mail list logo
