From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29066 invoked by alias); 24 Aug 2011 13:31:37 -0000 Received: (qmail 29046 invoked by uid 22791); 24 Aug 2011 13:31:35 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from mx02.qsc.de (HELO mx02.qsc.de) (213.148.130.14) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 24 Aug 2011 13:31:20 +0000 Received: from [192.168.178.22] (port-92-204-66-235.dynamic.qsc.de [92.204.66.235]) by mx02.qsc.de (Postfix) with ESMTP id CEAC11E4C5; Wed, 24 Aug 2011 15:31:18 +0200 (CEST) Message-ID: <4E54FD25.601@net-b.de> Date: Wed, 24 Aug 2011 14:23:00 -0000 From: Tobias Burnus User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Mikael Morin CC: fortran@gcc.gnu.org, gcc patches Subject: Re: [Patch, Fortran] PR 50163 - ICE with nonconst expr in init expr References: <4E539C93.7070704@net-b.de> <201108241212.42494.mikael.morin@sfr.fr> In-Reply-To: <201108241212.42494.mikael.morin@sfr.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-08/txt/msg01996.txt.bz2 On 08/24/2011 12:12 PM, Mikael Morin wrote: > On Tuesday 23 August 2011 14:26:59 Tobias Burnus wrote: >> OK for the trunk? > OK. Thanks for the review! Committed to the 4.7 trunk (Rev. 178038); I will backport the patch later. (For cross-readers: That's a patch for a 4.3+ ice-on-invalid-code regression.) > Isn't there some rules about backporting? The way we do it now, it > looks completely arbitrary. I think it *is* arbitrary - and unavoidable so. The main idea behind regression fixing is to make sure that what once worked should continue to work. But what always had been broken can remain broken and will be only fixed on the trunk. Reason: If you fix more, the behaviour on the branch changes and you may introduce regressions. If thinks are known to be broken, you can simply work around them. Additional ingredients are: How serious is the problem? A wrong-code issue occurring in a potentially often used part has a different priority than an accepts-invalid or ice-on-invalid-code issue. Also, a patch which is huge is less suited than a small "trivial" patch. Regressions, which existed for a long time are typically also less important - otherwise they would have been fixed or found before. But there are also other items such as: Which is the last maintained version in GCC, which versions are still being used (such that it makes sense to backport), and which patches (Linux) distributions want to see. Additionally, as backporting takes time (bootstrap, regtesting, and maybe even adapting the patch slightly): How much time wants the developer spend on backporting. My impression is that gfortran is currently doing too much non-regression backporting, which should be left to serious ICE-on-valid code and wrong-code issues. Especially as older versions do not see as much testing as the trunk. On the other hand, backporting simple fixes to regressions or really bad wrong-code issues (which we hadn't for a while) down to 4.4 should be also fine. I think every modern (= F2003) developer can relatively simply update to 4.6 or the trunk. The older versions are mostly for those using the default compiler of the system; those typically only need some Fortran 77/90 compiler, for which the older versions (4.4 or 4.5) should be fine. But at the end it is question of style. That's similar to Linux distributions. I think Jakub/Red Hat ports many patches (bug fixes but also features) back to their old versions, while for instance Richard/SUSE's package has only few patches and essentially grabs the current branch. Both approaches makes sense and either one has advantages and disadvantages. I think we should try extra hard to avoid regressions on the branches and mostly concentrate on the trunk, but we can still backport one patch or the other to the branches. I didn't really answer your question, did I? Tobias