--- 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 #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 #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: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 #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 #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 #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
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 #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
-
--- 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 #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:33
---
ABI breakage: 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 #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 #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:40
---
Leaving as P2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24490
--- 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 #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: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:44
---
Leave as P2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24582
--- 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 #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 #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 #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 #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
301 - 325 of 325 matches
Mail list logo
