--- Comment #14 from tkoenig at gcc dot gnu dot org 2005-10-31 07:52
---
Can we disable -fweb for 4.1.0 for fortran?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22509
--- Comment #7 from mark at codesourcery dot com 2005-10-31 07:44 ---
Subject: Re: [3.4/4.0/4.1 Regression] bitfield layout
change (regression?)
steven at gcc dot gnu dot org wrote:
> --- Comment #6 from steven at gcc dot gnu dot org 2005-10-31 07:21
> ---
> This was not a s
--- Comment #6 from steven at gcc dot gnu dot org 2005-10-31 07:21 ---
This was not a show stopper for GCC 3.4 and GCC 4.0. Why is it a show stopper
now for GCC 4.1?
And we can't unconditionally change it back now. We already have GCC 3.4 and
4.0 based compilers in production environm
--- Comment #6 from jkj at sco dot com 2005-10-31 07:12 ---
rth has a completely different fix for this that is much more comprehensive.
http://gcc.gnu.org/ml/gcc/2005-10/msg00412.html has the details. I'm still
working on bringing my 4.1 tree up to speed so I can help him test this.
-
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-31 06:45
---
This is a showstopper, unless we can convince ourselves that this is not a bug,
or, at least, not a regression.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Adde
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-31 06:44
---
Leave as P2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24582
--- Comment #2 from mmitchel at gcc dot gnu dot org 2005-10-31 06:43
---
Wrong-code; showstopper.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-31 06:42
---
Showstopper. Fortunately, I have a patch; just need to check it in.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from mmitchel at gcc dot gnu dot org 2005-10-31 06:41
---
Leaving as P2; we shoudl fix this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24560
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-10-31 06:40
---
Leaving as P2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24490
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-31 06:39
---
Rather than increasing the estimate for loops with unknown bounds or throttling
the maximum for loops with known bounds, why not notice, when inlining, that
we've mixed the two, and drop all frequency guesses in th
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-10-31 06:35
---
ICE on reasonable code; showstopper.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from mmitchel at gcc dot gnu dot org 2005-10-31 06:33
---
Leaving as P2, pending analysis.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24476
--- Comment #3 from mmitchel at gcc dot gnu dot org 2005-10-31 06:33
---
ABI breakage: showstopper.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-31 06:32
---
I guess I'll leave this as P2, but I really do think we should find a fix
before the next release, for the affected targets.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
--- Comment #3 from mmitchel at gcc dot gnu dot org 2005-10-31 06:30
---
Leaving as P2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24408
--- Comment #1 from mmitchel at gcc dot gnu dot org 2005-10-31 06:29
---
Wrong code, easy fix -- showstopper.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
-
In tree_expand_cfg, we have:
if (DECL_NAME (current_function_decl)
&& MAIN_NAME_P (DECL_NAME (current_function_decl))
&& DECL_FILE_SCOPE_P (current_function_decl))
expand_main_function ();
This code should also check TREE_PUBLIC (c_f_d) (and the entire predicate
should probably
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-31 06:25
---
Kean, I think you need to check TREE_PUBLIC (decl) as well; a "static" main
function isn't the main you're looking for. Note that a "static" main is
permitted by gcc, with a warning, by default.
(It looks like th
--- Comment #8 from mmitchel at gcc dot gnu dot org 2005-10-31 06:18
---
ICE on reasonable valid code; showstopper.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #9 from mmitchel at gcc dot gnu dot org 2005-10-31 06:16
---
Danny, when you refer to PR 24288, do you mean a different PR? I don't see the
relevance of PR 24288, but I do remember discussing this issue with you and
Jason.
Anyhow, for the time being, I think it's fair to p
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-10-31 06:13
---
We need to analyze this. Unless this is a Darwin libc bug, this is a
showstopper.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #7 from mmitchel at gcc dot gnu dot org 2005-10-31 06:12
---
Leaving as P2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24309
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-10-31 06:10
---
This is a corner-case; we can leave this at P2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24306
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-10-31 06:07
---
Does the analysis in Comment #3 imply that -fmove-loop-invariants is really not
ready for use by the general public?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24265
--- Comment #9 from mmitchel at gcc dot gnu dot org 2005-10-31 06:05
---
How broken is -fgcse-sm? Is it broken enough that it should not only be
disabled by default but also hard-wired off on release branches?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24257
--- Comment #19 from mmitchel at gcc dot gnu dot org 2005-10-31 06:04
---
Altivec is very popular; this is a showstopper.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #9 from mmitchel at gcc dot gnu dot org 2005-10-31 06:02
---
I'm marking this as P1, at least until we do some analysis.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #13 from mmitchel at gcc dot gnu dot org 2005-10-31 06:00
---
This is a showstopper.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-10-31 05:58
---
I'm not sure whether we want to try to allow this in C++. (I think this is
valid C99, using the flexible array extension, but I'm not certain.) Clearly,
however, ICEing is bad; leaving as P2.
--
http://gcc.g
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-10-31 05:57
---
Leaving as P2. This really should be fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24101
--- Comment #9 from mmitchel at gcc dot gnu dot org 2005-10-31 05:56
---
Should this be marked as fixed, or as 4.0-only, given the patch in Comment #8?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24093
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-31 05:54
---
Leaving as P2; we need to fix this or figure out why we can't.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24037
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-31 05:54
---
A bug in the -E -C output is never going to be release-critical.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-10-31 05:53
---
We should either fix this, or, at least, figure out why we can't; leaving as
P2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24009
--- Comment #23 from mmitchel at gcc dot gnu dot org 2005-10-31 05:52
---
Do we have a C/C++ testcase for this problem?
I'm going to leave this as P2 for now, given that we think it's not
language-dependent, and given that we seem close to a fix.
--
http://gcc.gnu.org/bugzilla/sho
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-10-31 05:50
---
This is a showstopper, at least until we analyze it better.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #20 from mmitchel at gcc dot gnu dot org 2005-10-31 05:48
---
This is a showstopper.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #22 from mmitchel at gcc dot gnu dot org 2005-10-31 05:46
---
Downgrading to P4. I'd like to see more progress for 4.1, but it's not going
to be release-critical.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from mmitchel at gcc dot gnu dot org 2005-10-31 05:42
---
Leaving as P2, pending investigation.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23821
--- Comment #8 from mmitchel at gcc dot gnu dot org 2005-10-31 05:41
---
Yup, this is a showstoppper.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23775
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-10-31 05:39
---
Elevating to P1; this is a serious wrong-code regression.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from mmitchel at gcc dot gnu dot org 2005-10-31 05:36
---
I don't think this PR is, in-and-of-itself, is very interesting, as it's a
1-byte size increase with -O2, which, as has been said, is not aimed at
minimizing code size. So, I'm going to close this PR -- but, leav
--- Comment #9 from mmitchel at gcc dot gnu dot org 2005-10-31 05:28
---
Certainly, the test-case in Comment #1 does depend on libstdc++ at all. Let's
fix this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23497
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-31 05:26 ---
This still fails as of today.
I will repost and retest the patch later today.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
Testcase:
void abort (void);
int ii;
typedef struct {} raw_spinlock_t;
typedef struct {
raw_spinlock_t raw_lock;
} spinlock_t;
raw_spinlock_t one_raw_spinlock (void)
{
raw_spinlock_t raw_lock;
ii++;
return raw_lock;
}
int main(void)
{
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-10-31 05:22
---
This patch is OK, assuming no objections within 24 hours.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from mmitchel at gcc dot gnu dot org 2005-10-31 05:17
---
I'd like to see this fixed. Is there any throttling we can do here?
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-31 05:13 ---
I decided against committing the patch as obvious.
Anyways the patch was posted:
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01770.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #10 from mmitchel at gcc dot gnu dot org 2005-10-31 05:13
---
Leaving as P2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23488
--- Comment #3 from mmitchel at gcc dot gnu dot org 2005-10-31 05:09
---
Leaving as P2; we should fix this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23457
--- Comment #9 from mmitchel at gcc dot gnu dot org 2005-10-31 05:09
---
Leaving as P2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23453
--- Comment #2 from mmitchel at gcc dot gnu dot org 2005-10-31 05:05
---
We don't need speculation; we need facts. I'll leave this at P2, in the hopes
that someone will analyze this properly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23451
--- Comment #10 from mmitchel at gcc dot gnu dot org 2005-10-31 05:03
---
Dale, would you please attach the C++ testcase for this PR?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23392
--- Comment #8 from mmitchel at gcc dot gnu dot org 2005-10-31 05:02
---
Leaving as P2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23382
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-31 05:02 ---
Here is a C testcase (so that Mark does not lower this to P5):
struct f {};
struct g1 {struct f l;};
static inline void g(struct f a, int i){}
void h(void)
{
struct g1 t;
g(t.l , 1);
}
--
http://gcc.gnu.org/
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-31 05:01
---
Leaving as P2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23378
--- Comment #14 from mmitchel at gcc dot gnu dot org 2005-10-31 05:00
---
Leaving as P2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23372
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-10-31 04:59 ---
Subject: Re: [4.1 Regression] FRE before DCE makes a mess of loads or need to
sink loads
>
>
>
> --- Comment #7 from mmitchel at gcc dot gnu dot org 2005-10-31 04:58
> ---
> Why have we regressed relat
--- Comment #7 from mmitchel at gcc dot gnu dot org 2005-10-31 04:58
---
Why have we regressed relative to 4.0?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23346
--- Comment #2 from mmitchel at gcc dot gnu dot org 2005-10-31 04:56
---
Leaving as P2; we should definitely fix this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23336
--- Comment #9 from mmitchel at gcc dot gnu dot org 2005-10-31 04:55
---
I'm going to resolve this as INVALID. If there's a bug here, we need a test
case that shows that inferior code; then, we can reopen this bug.
--
mmitchel at gcc dot gnu dot org changed:
What|Re
--- Comment #13 from dann at godzilla dot ics dot uci dot edu 2005-10-31
04:50 ---
(In reply to comment #12)
> A more interesting test would be to see the Linux kernel size difference,
There's such a comparison now in comment #8 in PR23153. It confirms the size
increase.
--
http:/
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-31 04:49
---
Do we have any analysis about why the register allocator is doing a worse job?
Leaving as P2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23322
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-10-31 04:45
---
Jan, what's your analysis on this PR?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23303
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-31 04:43
---
I think we should look for some solution to this problem, without reverting the
previous patch. If this problem is amenable to a peephole, let's solve it that
way.
That said, I'm going to downgrade this to P4; if
--- Comment #8 from mmitchel at gcc dot gnu dot org 2005-10-31 04:40
---
Leaving as P2. I'm only 75% sure this is valid, but we should at least
investigate.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23287
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-10-31 04:39
---
Leavinga s P2. We should at least look at this, and understand what's wrong.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23211
--- Comment #10 from mmitchel at gcc dot gnu dot org 2005-10-31 04:37
---
Leaving as P2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200
--- Comment #9 from mmitchel at gcc dot gnu dot org 2005-10-31 04:36
---
So, Jeff, is it your opinion that this is just an inevitable case of
optimizers-aren't-perfect? If so, would you please just close this PR?
Leaving as P2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23181
--- Comment #8 from mmitchel at gcc dot gnu dot org 2005-10-31 04:31
---
Leaving as P2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23172
--- Comment #8 from mmitchel at gcc dot gnu dot org 2005-10-31 04:31
---
Leaving as P2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23171
--- Comment #7 from dannysmith at users dot sourceforge dot net 2005-10-31
04:30 ---
This is an i386 bug, not specific to MS windows target. However, it is only a
problem with -mtune=i386 -mrtd.
Danny
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22017
--- Comment #11 from mmitchel at gcc dot gnu dot org 2005-10-31 04:29
---
Leaving as P2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23155
--- Comment #2 from mmitchel at gcc dot gnu dot org 2005-10-31 04:28
---
This will never be release-critical.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from mmitchel at gcc dot gnu dot org 2005-10-31 04:23
---
I'm on the fence as to whether to call this P1 or P2. People have really
started to use -ftree-vectorize and it's a major advantage of the more recent
compilers over 3.4.x, so I'd really like to see this fixed. O
--- Comment #8 from mmitchel at gcc dot gnu dot org 2005-10-31 04:20
---
This is a serious wrong-code problem; it's a showstopper.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-10-31 04:19 ---
(In reply to comment #7)
> Downgraded to P4. If we can fix this great; otherwise, we'll look at it
> again for 4.2.
It is not like I did not post a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23104
--- Comment #7 from mmitchel at gcc dot gnu dot org 2005-10-31 04:18
---
Downgraded to P4. If we can fix this great; otherwise, we'll look at it again
for 4.2.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #20 from mmitchel at gcc dot gnu dot org 2005-10-31 04:15
---
This is a showstopper; ICE on simple, valid code. We need to resolve what
approach (es) to use to fix this and get it done.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed
--- Comment #8 from dann at godzilla dot ics dot uci dot edu 2005-10-31
04:15 ---
More data, the Linux kernel compiled for i686:
size -f *
textdata bss dec hex filename
2625471 534012 611768 3771251 398b73 vmlinux.4.0
3023306 429364 347384 3800054 39fbf6 vmlinu
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-10-31 04:13 ---
(In reply to comment #3)
> Andrew, what is your point about the C++ front-end? What is it you think is
> wrong?
There is no mention of the C++ front-end here at all.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #7 from mmitchel at gcc dot gnu dot org 2005-10-31 04:12
---
Leaving as P2.
I've seen reports of similar bitfield problems on a variety of problems. This
kind of code doesn't show up much in scientific computing, but it does show up
in network applications, operating-syste
--- Comment #22 from mmitchel at gcc dot gnu dot org 2005-10-31 04:10
---
Downgraded to P5. If this is not Ada-specific, please attach a C/C++ test
case.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from mmitchel at gcc dot gnu dot org 2005-10-31 04:08
---
I've set this to P5. If it's not Fortran-specific, Cc: me -- after attaching
the C/C++ test-case. Or, just fix the bug. :-)
--
mmitchel at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-31 04:07
---
This will prevent compiling real programs with -g; it's a showstopper.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-10-31 04:07
---
This will never be release-critical.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-10-31 04:05
---
I'm not sure what's ging on here, but I know we should fix it... Leaving as
P2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22434
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-31 04:04
---
This is a showstopper; wrong code on a primary platform.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #12 from mmitchel at gcc dot gnu dot org 2005-10-31 04:03
---
This is a showstopper; wrong code on a primary platform using plausible inputs.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from mmitchel at gcc dot gnu dot org 2005-10-31 04:02
---
The patch in Comment #1 has been applied.
Andrew, what is your point about the C++ front-end? What is it you think is
wrong?
In any case, this will never be release critical.
--
mmitchel at gcc dot gnu dot o
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-10-31 03:59 ---
(In reply to comment #2)
> Leaving as P2.
> Do we know what's different?
Yes in 4.0 and above there is no CONSTRUCTOR so we don't see the full
CONSTRUCTOR in expand so it could expand to just one integer store.
>The
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-10-31 03:57
---
This is a showstopper; we need to at least understand why this changed and
whether or not we should change it back.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-10-31 03:55
---
Gaby, please apply the simple OBJ_TYPE_REF patch so that we can remove the
regression markers from this PR.
(I agree that a complete solution is difficult; my opinion continues to be that
we should use carets, rat
--- Comment #2 from mmitchel at gcc dot gnu dot org 2005-10-31 03:54
---
Leaving as P2.
Do we know what's different? The structure type is byte-aligned. How did 2.95
justify using a 4-byte store?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22141
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-10-31 03:50
---
Leaving as P2; we should fix this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22136
--- Comment #10 from mmitchel at gcc dot gnu dot org 2005-10-31 03:49
---
Regardless of *where* getcontext() should be recognized, it's clear that the
compiler should be aware that it has special behavior.
This is a wrong-code regression on a primary platform with no non-default
opti
--- Comment #14 from mmitchel at gcc dot gnu dot org 2005-10-31 03:46
---
Leaving as P2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22042
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-10-31 03:45
---
Leaving at P2, only because Cygwin is not a primary platform. (Otherwise, I'd
make this P1.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22017
--- Comment #6 from dberlin at gcc dot gnu dot org 2005-10-31 03:43 ---
Realistically?
No.
I'm about to start solving it on the improved-aliasing branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20643
1 - 100 of 325 matches
Mail list logo
