http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46261
--- Comment #15 from Joerg Wunsch <j at uriah dot heep.sax.de> 2011-06-28 06: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" — by the original maintainers. The people contributing (patches!) to this bug report demonstrate there actually *is* some effort to still maintain it — 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 what I > would call "experimental", in that they are only in distros and not upstream, > 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 bullet > 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 — 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.
