From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13852 invoked by alias); 28 Jun 2011 06:29:15 -0000 Received: (qmail 13844 invoked by uid 22791); 28 Jun 2011 06:29:14 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 28 Jun 2011 06:29:00 +0000 From: "j at uriah dot heep.sax.de" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/46261] avr-gcc: Segfaults when compiled with the -mint8 option X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: j at uriah dot heep.sax.de X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Date: Tue, 28 Jun 2011 06:29:00 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2011-06/txt/msg02684.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D46261 --- Comment #15 from Joerg Wunsch 2011-06-28 0= 6:27:17 UTC --- (In reply to comment #14) > > . Regardless of whether someone votes to remove an option, a segfault > > should always be analyzed. > Except that this is a segfault on a compiler switch that is unmaintained, Did you analyze it to make sure there is no chance for this to happen also without -mint8? OK, I did, and it's indeed the case. "unmaintained" =E2=80=94 by the original maintainers. The people contribut= ing (patches!) to this bug report demonstrate there actually *is* some effort to still maintain it =E2=80=94 by the users. Why ignore this effort, and do it away as "we don't want to maintain that anymore"? The only drawback I could see with that patch is that it introduces a couple of #ifdefs outside of the AVR code path in the compiler, to give the AVR backend an override option for the type sizes. > and > there are little to no user complaints about it. That's simply because all the compiler versions that are "out in the field" (4.3.x, 4.4.x) still have a working (within their known limitations, of course) -mint8 option. Be assured, we will get complaints about it if you release another WinAVR with a non-working -mint8 option, or with the option dropped. > Actually it does. The attiny10 series (attiny10/4/5/9/20/40) is still wha= t I > would call "experimental", in that they are only in distros and not upstr= eam, > and you know as well as I do that there is a serious wrong-code bug with = them > anyway. That doesn't matter much. The wrong-code bug can (probably) be fixed, but the integer promotion issues won't be affected by that fix. If you don't like the reference to ATtiny10 (&Co.), just keep the ATtiny13 (and probably also ATtiny2313, ATtiny25, ATtiny45) in your mind by now. > As to the other small device users, > those devices still use avr-libc They *can* use it. We've always told them however, that using -mint8 and avr-libc doesn't mix. Nevertheless, it appears to be useful enough to some users to decide pro -mint8 (and thus against using the library). (It isn't even entirely true that both don't mix: a lot of the library stuff just comes as inline functions and macros within the header files, and this part is likely working to a large degree even with -mint8.) > We all know that the ideal solution is to fix the avr backend regarding > optimizing (removing) unnecessary promotion. We can start by biting the b= ullet > and removing -mint8. I'd do it the other way around: fix the optimization issues, until the users don't benefit from the -mint8 hack anymore. By that time, it can be removed without anyone complaining. You cannot impose any pressure to the *developers* (to fix the optimization issues) by removing the option now, but you'll cause some impact for users of that option =E2=80=94 users who can't do anything about= it other than voicing their complaints in public that more recent versions of GCC get worse and worse in their usability. I'd like to avoid this situation.