Consistency of function attributes between prototype and definition

[Florian Weimer]

On 10/05/2015 11:56 AM, Segher Boessenkool wrote:
> On Mon, Oct 05, 2015 at 11:43:02AM +0200, Florian Weimer wrote:
>> On 10/05/2015 11:40 AM, Segher Boessenkool wrote:
>>> On Mon, Oct 05, 2015 at 11:20:20AM +0200, Florian Weimer wrote:
>>>> On 10/02/2015 09:37 PM, Segher Boessenkool wrote:
>>>>> On Fri, Oct 02, 2015 at 01:25:31PM +0200, Florian Weimer wrote:
>>>>>> glibc has a preprocessor macro called internal_function which switches
>>>>>> to a different calling convention on certain targets (i386 uses stdcall
>>>>>> and regparams).  For non-K&R function definitions, the compiler enforces
>>>>>> that both the prototype declaration and the definition match.
>>>>>>
>>>>>> When someone writes a patch on a different architecture than i386 and
>>>>>> forgets to specify internal_function on both prototype and definition,
>>>>>> the build will pass, even though i386 will not compile.
>>>>>>
>>>>>> Is there a way to use a certain harmless attribute to detect this
>>>>>> mismatch even on architectures where internal_function has no effect?
>>>>>
>>>>> Maybe aligned(1) will do what you want?
>>>>
>>>> Interesting idea.  Would this alter generated code?
>>>
>>> It shouldn't -- it can only increase alignment (not decrease it).
>>
>> Why do you think that?
> 
> Because the documentation says so.  Maybe it is wrong though, I didn't
> test it.  If so, please file a bug.

I see a difference on x86_64:

@@ -3,7 +3,6 @@
 .LCOLDB0:
 	.text
 .LHOTB0:
-	.p2align 4,,15
 	.globl	f
 	.type	f, @function
 f:

I don't think this is a bug because the manual says:

“However, when you explicitly specify a function alignment this
overrides the effect of the '-falign-functions' [Â…] option for this
function.”

So I think this attribute isn't useful for this purpose.  Looks like
we'd need a new attribute, as Jeff suggested.

Florian