This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Patch fixing 3.3 bug PR 9745 and PR 10021
- From: Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>
- To: David Edelsohn <dje at watson dot ibm dot com>,Mark Mitchell <mark at codesourcery dot com>
- Cc: Marcus Meissner <meissner at suse dot de>,gcc at gcc dot gnu dot org,wilson at tuliptree dot org,Olaf Hering <olh at suse dot de>
- Date: Wed, 2 Jul 2003 19:51:12 +0200
- Subject: Re: Patch fixing 3.3 bug PR 9745 and PR 10021
- References: <200307021722.NAA25842@makai.watson.ibm.com>
On Wednesday 02 July 2003 19:22, David Edelsohn wrote:
> >>>>> Mark Mitchell writes:
>
> Mark> Personally, I'd choose slow code. Not only is that better for our
> Mark> users, some of whom use GCC to build very critical systems, but it
> would Mark> also encourage someone to go solve the optimization problem.
>
> If you want to apply Jim's patch to GCC 3.3 a week before the GCC
> 3.3.1 release, that's your perogative as Release Manager. I expect that
> will have an extremely negative impact on people upgrading to GCC 3.3.1 or
> using the GCC 3.3 branch.
I don't understand you here, IMHO we _have_ to fix it for 3.3.1/3.3.2 since
it's a code correctness regression from 3.2.3 and the suggested patches are
non-invasive. Since the user cannot prove if the "faster" application is
compiled correctly, he has to compile with -O1 (this is what Suse does for
their _whole_ build system now) or -O2 -fno-strict-aliasing anyway. And
certainly this is slower than half-working aliasing, or? BTW, do you have any
hard numbers on how badly performance is affected (compared to 3.2.3 and
3.3)?
I think we should be very careful on what we decide here. With the 3.2 series
we've built up a lot of credit among the users and with this bug even I like
Suse would be forced to tell users "don't trust 3.3, stay with 3.2.3 for
everyday use" until this bug is fixed.
Franz.