Re: RFC: GCC 4.4 criteria - add Fortran as primary language?

1 msg	[tuples] Branch is still frozen
2 msg	Re: [PATCH] Add PAREN_EXPR
1 msg	gcc-4.3-20080221 is now available
2 msg	call site information
3 msg	[tuples] tree-tailcall.c
1 msg	Russia Host for GCC Archives
12 msg	Darwin long double issue (PR25477): any news or...
2 msg	Patch Testing Requirements
9 msg	-mfmovd enabled by default for SH2A but not for...
1 msg	gcc-4.2-20080220 is now available

RFC: GCC 4.4 criteria - add Fortran as primary ...
\ Tobias Burnus (20 Feb 2008)
. \ Joel Sherrill (20 Feb 2008)
. . \ Tim Prince (20 Feb 2008)
. . . \ Joe Buck (20 Feb 2008)
. . . . \ Joel Sherrill (20 Feb 2008)
. . . . \ David Daney (20 Feb 2008)
. . . . . \ Tobias Burnus (21 Feb 2008)
. . . . \ Weddington, Eric (21 Feb 2008)
. \ FX Coudert (21 Feb 2008)
. \ J.C. Pizarro (21 Feb 2008)
. \ Mark Mitchell (22 Feb 2008)
. . \ Joe Buck (22 Feb 2008)

2 msg	Dynamic macro expansion through a pipe?
2 msg	how to correct logs on my MELT branch?
3 msg	New GCC ICI v0.9.5 (bug fixes + new examples)
9 msg	SSA alias representation
2 msg	[PATCH] Complex arithmetic changes
3 msg	-fpic support detection in testsuite
1 msg	MELT branch created, barely usable.
35 msg	Redundant logical operations left after early s...
14 msg	GCC 4.3 branch created, 4.4 opens for stage1

Subject:	Re: RFC: GCC 4.4 criteria - add Fortran as primary language?
Group:	Gcc
From:	Joe Buck
Date:	22 Feb 2008

On Thu, Feb 21, 2008 at 06:29:20PM -0800, Mark Mitchell wrote:
> I think Fortran is way down the list. That's not about how good of a
> language Fortran is, or how solid the Fortran front-end is; it's just a
> comment about usage of GCC.
>
> That said, I think that the RMs do -- and should -- pay attention to
> Fortran. I just think that the statement that only C and C++
> regressions are release-critical is important.

Just because something isn't release-critical doesn't mean it isn't going
to be fixed. Think of releases as trains. We hold the train departure
only for release-critical bugs, but that doesn't prevent non-release-critical
bug fixes from catching the next train. This works when we know that
there will be an x.y.1 and an x.y.2 at reasonable intervals.