> -----Original Message----- > From: > avr-gcc-list-bounces+eric.weddington=atmel....@nongnu.org > [mailto:avr-gcc-list-bounces+eric.weddington=atmel....@nongnu. > org] On Behalf Of Weddington, Eric > Sent: Monday, November 02, 2009 8:33 AM > To: Joerg Wunsch; avr-gcc-list@nongnu.org > Subject: RE: [avr-gcc-list] Re: optimizer removes volatile > pin access code.why? > > > > > -----Original Message----- > > From: Joerg Wunsch [mailto:j...@uriah.heep.sax.de] > > Sent: Monday, November 02, 2009 8:17 AM > > To: avr-gcc-list@nongnu.org > > Cc: Weddington, Eric > > Subject: Re: [avr-gcc-list] Re: optimizer removes volatile > > pin access code.why? > > > > As Weddington, Eric wrote: > > > > > And IMHO, I highly doubt that this proposal will be approved. They > > > will probably just come back to you and say that there's > no need for > > > it. > > > > Why not? Why do you think issuing a warning for something that is > > known it cannot work would be rejected? If the always_inline > > attribute is known to only work for a function declared inline, it > > should be legitimate to warn the user about a situation where this > > prerequisite is not met. > > Ok, *that* proposal I can understand (warning if inline not > present). But I think that changing 'always_inline' attribute > to imply inline might not fly. But who knows? In the end I > think you're right in that it would be an effort to get it > through the commit process.
To be a bit more specific (now that I've had a bit more caffiene): Adding a feature (a warning) is always easier than trying to change the semantics of an existing feature (always_inline). Changing semantics seems to incur a bit more debate and risks earlier rejection. But I agree that it's not impossible. _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
