[cfe-commits] r47850 - /cfe/trunk/Headers/mmintrin.h

[Eli Friedman]

On Mon, Mar 3, 2008 at 5:03 PM, Mike Stump <mrs at apple.com> wrote:
> On Mar 3, 2008, at 4:43 PM, Eli Friedman wrote:
>  > why does always_inline matter, though?
>
>  Because users expect them to be inlined.  When debugging for example,
>  they want to know they are in routine foo, if they are in routine foo,
>  even when there is little debug information.

Okay.

>  > Actually, I just realized an issue with the current implementation:
>  > shouldn't the functions in mmintrin.h actually be static inline?
>
>  No, that won't work for C99+, as that then prevents these routines
>  from being used in inline functions.  :-(  For non-c99 languages, yes,
>  I'd argue that static inline is the right choice.

Ah, I forgot... yeah, that sucks.  Then I guess we should mark them
"extern inline __attribute__((weak))"?  Just plain inline means that
we can't in general generate the right thing.  Or we could cheat and
add a "ignore_c99_6_7_4_3_restrictions" attribute.

>  > We don't ever want to depend on an external definition.
>
>  :-)  If they are always inline, it wouldn't be much of a
>  problem.  :-)  As I recall, the docs give us the latitude to reject
>  when someone wants the address of one of them.

Where does that put us here?  Should we attach some sort of
"address_not_allowed" attribute to these functions?

-Eli