RE: [avr-gcc-list] Re: optimizer removes volatile pin access code.why?

[Weddington, Eric]

> -----Original Message-----
> From: 
> address@hidden 
> [mailto:address@hidden
> org] On Behalf Of Weddington, Eric
> Sent: Monday, November 02, 2009 8:33 AM
> To: Joerg Wunsch; address@hidden
> Subject: RE: [avr-gcc-list] Re: optimizer removes volatile 
> pin access code.why?
> 
>  
> 
> > -----Original Message-----
> > From: Joerg Wunsch [mailto:address@hidden 
> > Sent: Monday, November 02, 2009 8:17 AM
> > To: address@hidden
> > 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.