my automated GCC bug-fixing bot finished I am going to have
an easy life. Unfortunately, I use GCC to build the bot, and I'm
getting an ICE in reload...
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
sion testing is good, and hugely useful --
but what makes it *really* valuable is having someone who comes in every
morning, looks at the output, and figures out who to blame, and, if
necessary, fixes the problem herself.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Daniel Jacobowitz wrote:
On Mon, Jun 13, 2005 at 12:56:36PM -0700, Richard Henderson wrote:
On Mon, Jun 13, 2005 at 11:16:04AM -0700, Mark Mitchell wrote:
1. For a bi-arch compiler for which 32-bit code is the default, we no
longer need to override ASM_SPEC.
Well, this is the only way
assembler
if the user tries to use a 64-bit compiler with a 32-bit assembler.
OK?
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
2005-06-13 Mark Mitchell <[EMAIL PROTECTED]>
* config/i386/x86-64.h (ASM_SPEC): Explicitly pass --64 to the
assembler in 64-bit m
eeing one of several problems...)
We're in a holding pattern (branch frozen) until we resolve these issues.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
4.0 soon, your patch would be
included automatically.
would be nice.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Andrew Pinski wrote:
On Jun 8, 2005, at 12:57 PM, Mark Mitchell wrote:
The GCC 4.0.1 RC1 prerelease is available here:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.1-20050607/
Please test these tarballs, and let me know about showstoppers.
Can I revert a patch which I accidentally applied
ose the door on the code-generation bugs that are causing
us to do *this* release.
I plan to make the final release this weekend, unless major problems arise.
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
s out, assuming all goes well.
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
that I had a strong opinion up
front, and I really do think this ought to be up to you, but if that's
the conclusion you draw, that's certainly fine. You should certainly
feel free to ask MIPS for more information, if you need that to help
judge the contribution.
Thanks,
--
Mark M
e. Dan Jacobowitz and/or Nathan Sidwell and/or Phil
Edwards would be good choices.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Diego Novillo wrote:
On Sun, Jun 05, 2005 at 10:18:05AM -0700, Mark Mitchell wrote:
* 21528: SRA and/or aliasing problem.
I'll take a look at this tomorrow.
Thanks!
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
t the GCC
bits with the actual FSF binutils bits. Our current internal versions
are based on GCC 3.3.2 and we have some ugly binutils hacks that are
being cleaned up as we push out to the FSF.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Andrew Pinski wrote:
On Jun 5, 2005, at 2:01 PM, Mark Mitchell wrote:
I agree that these are both serious, though neither seems to rise to
the level of the KDE issues, in that these both affect "only"
debugging. PR 19523 affects only stabs, which I do not think is the
defa
company, now, that we would have to drop it if
it were not maintained. That could be part of negotiating with them
to get a commitment of support.
We could also ask them whether they plan to provide support for GDB
and the binutils, or when they plan to release the manual so that
others can do so
Andrew Pinski wrote:
On Jun 5, 2005, at 1:41 PM, Devang Patel wrote:
On Jun 5, 2005, at 10:18 AM, Mark Mitchell wrote:
Here are three bugs I'd really like to see fixed.
* 21528: SRA and/or aliasing problem.
* 21847: DCE over-eagerness.
* 20928: IA32 ICE.
* 19523: [4.0/4.1 Regre
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
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.
>
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 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
ute this, using
techniques similar to those in target-supports.exp.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
but I didn't seem to have sufficient
permissions. Please go ahead!
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
thout the critical bug before the
next official release.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
ut causing this level
of disruption to other developers.
I agree.
--
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
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
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
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
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
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
s case and otherwise!
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
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
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
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
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
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
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
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
://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]
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
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
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
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
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
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
AM_GOOD__ attribute, I
think
it would be better to have both flavours and then the compiler switch can
specify which way the default goes.
Makes sense to me.
--
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
testsuite issues, but I think it's
OK that we didn't. Thanks for testing!
--
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
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
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
have opinions about what the default should be?
--
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
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
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
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
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
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
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
Once we've validated, we'll go ahead and check
in your patch.
Thanks,
--
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
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
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
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
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:
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
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
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
" is
addressed, we must assume that all of "x" is addressed -- unless we can
prove otherwise, by, say, looking at the body of "g".
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
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
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
must make the conservative assumption.
--
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
serious regressions from previous 3.4.x compilers.
--
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
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
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
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
sable
literal, yes?)
No, it's not.
static const int i = f();
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
t's not being marked TREE_READONLY because we're afraid of the
dynamic initialization case. We're missing a call to
c_apply_quals_to_decl (sp?) somewhere.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
>
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
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
\
: (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
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
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
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
oblem
case is that the friend declaration looks like "friend class C" where
there is a C in a containing scope, but no C in the class with the
friend declaration?
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
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
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
; 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
doesn't seem so attractive.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
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
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]
s
look like? In the meantime, I'm trying to plan 3.4.4
--
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
ay
enough to be useful in some circumstances.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
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
/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
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
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
1201 - 1300 of 1433 matches
Mail list logo
