-ffreestanding no longer recognizes auto-returns_twice

[jsonn]

Bugzilla Link	11296
Resolution	WONTFIX
Resolved on	Feb 04, 2014 13:49
Version	trunk
OS	Linux
CC	@DimitryAndric,@efriedma-quic

Extended Description

Recently, the name matching in LLVM for functions like setjmp, savectx etc was removed and replaced by corresponding builtins in the C frontend.

Consequence 1: Functions need a proper, consistent prototype for this to work. This is not the case for savectx, which depending on the architecture and BSD returns either void or int. It is also used only in kernel and returns_twice semantic seems to only apply for FreeBSD.

Consequence 2: Since the kernel and modules are built with -ffreestanding, they no longer provides the returns_twice attribute for them. Compile the attached test case with and without -ffreestanding and compare IR:

w/ -ffreestanding:

declare i32 @​savectx(%struct.__jmp_buf_tag*)

w/o -ffreestanding:

declare i32 @​savectx(%struct.__jmp_buf_tag*) returns_twice

This bug is about tracking this change. I do not consider (2) a regression by itself, but it might be nice to detect and warn for this case specifically. The old behavior is certainly wrong and hides the real issue.

Based on (2), I would like to see savectx dropped from the list. It is non-standard and inconsistently defined and the only users don't benefit from the behavior anyway. For FreeBSD it should be trivial to add the attributes for the ports that need it.

[llvmbot]

Recently, the name matching in LLVM for functions like setjmp, savectx etc was
removed and replaced by corresponding builtins in the C frontend.

Consequence 1: Functions

[llvmbot]

Recently, the name matching in LLVM for functions like setjmp, savectx etc was
removed and replaced by corresponding builtins in the C frontend.

Consequence 1: Functions need a proper, consistent prototype for this to work.
This is not the case for savectx, which depending on the architecture and BSD
returns either void or int. It is also used only in kernel and returns_twice
semantic seems to only apply for FreeBSD.

If I read the code correctly, the way to handle this in clang would be to use

t -> signature is meaningless, use custom typechecking

Another option is making sure that the all relevant headers have the attribute and drop savectx from clang. If dropping, we should at least also notify gcc, as they have this since the beginning:

http://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=66d433c7be147672fb1da1afd42a311d79cb0531

Roman, if this were to be dropped from clang and/or gcc, do the FreeBSD headers have the attribute? If so, since when?

Consequence 2: Since the kernel and modules are built with -ffreestanding, they
no longer provides the returns_twice attribute for them. Compile the attached
test case with and without -ffreestanding and compare IR:

w/ -ffreestanding:

declare i32 @​savectx(%struct.__jmp_buf_tag*)

w/o -ffreestanding:

declare i32 @​savectx(%struct.__jmp_buf_tag*) returns_twice

This bug is about tracking this change. I do not consider (2) a regression by
itself, but it might be nice to detect and warn for this case specifically. The
old behavior is certainly wrong and hides the real issue.

I agree. If I understand it correctly, when using -ffreestanding the compiler should not know about specific functions and the code should use attribute as needed.

It would probably make sense to warn every time a "user visible" attribute would be added if not for -ffreestanding.

Based on (2), I would like to see savectx dropped from the list. It is
non-standard and inconsistently defined and the only users don't benefit from
the behavior anyway. For FreeBSD it should be trivial to add the attributes for
the ports that need it.

Roman, any opinions? We should also consider users of existing releases installing a new compiler.

[jsonn]

Neither FreeBSD nor NetBSD currently have the returns_twice attribution for in-kernel use, but adding it isn't a big deal. This mostly was under the radar due to the GCC magic. Since newer compiler always tend to require a few changes, that isn't a big deal either.

[llvmbot]

sorry, bugzilla tricked me into closing the wrong bug.

[jsonn]

As discussed with Rafael and Dimitry, FreeBSD and NetBSD have been adjusted to deal with it.