Language extensions#

This page describes the extensions to ISO C that EmbCC accepts: the GNU C language extensions, attributes, builtin functions, the atomic builtins, the feature-test operators, preprocessor extensions and pragmas. For each one it says what EmbCC does, on which targets, and the exact diagnostic when EmbCC refuses it. It is for people porting code written for GCC or Clang and for people writing code for EmbCC directly. Standard C is described in C language, C++ in C++, and the asm statement in Inline assembly.

Overview#

Extensions are always enabled#

Every extension on this page is available under every --std= standard, as in GCC: under a strict cNN standard only the keywords asm and typeof are names, and __asm__ and __typeof__ still work. --pedantic reports each use of an extension, and --pedantic-errors refuses it, except in a system header or after __extension__.

When EmbCC does not implement an extension, it refuses the program with an error that names the construct, rather than compiling it to do something else. The few places where a construct is accepted and has no effect, without an error, are stated where they occur and collected in Accepted without effect.

Target names used on this page#

Where support depends on the code generator, this page names targets as follows. Each name covers every triple of that family; see Targets.

A construct that a code generator cannot lower is refused when the function containing it is compiled, with a message of the form

embcc: f.c:1: error: the MIPS64 backend cannot lower a 16-byte atomic (MIPS64's lld/scd are a doubleword; there is no 128-bit ll/sc) yet (function f) [cas16 w=16 size=16]

The bracketed part names the internal operation that could not be lowered.

Detecting EmbCC#

EmbCC predefines __EMBCC__ as 1. A C translation unit does not define __GNUC__, __GNUC_MINOR__ or __clang__, so a header that enables GNU features under #ifdef __GNUC__ takes its other path when compiled by EmbCC, unless -fgnuc-version= asks for them (CMSIS needs that; see Invoking). A C++ translation unit presents itself as g++ 16.2; see C++.

To test for a feature, use the feature-test operators, with the limits described there.

GNU C language extensions#

Summary#

Statement expressions#

A compound statement in parentheses is an expression. Its value is the value of its last statement, when that statement is an expression statement; otherwise its type is void. The value may be of any type, including a structure.

#define max(a, b) ({ __typeof__(a) _a = (a); __typeof__(b) _b = (b); \
                     _a > _b ? _a : _b; })

Statement expressions are supported on every target. One cannot appear in a static initializer (a static initializer must be a constant, a string literal, or the address of a global). break and continue inside one refer to a loop or switch inside the same statement expression; one that would leave it is refused ('break' outside of a loop or switch).

typeof#

typeof, __typeof__ and __typeof are one keyword. Each accepts a type name or an expression; the expression is not evaluated. C23's typeof_unqual gives the same type without its qualifiers.

The type of an expression is determined while the declaration is parsed, which covers the forms that macros use. The operand may be:

• an integer, floating or character constant, or a string literal without an encoding prefix other than u8;
• the name of an object: a variable in scope or one at file scope;
• a cast, a conditional (?:), unary -, ~ and !, *, &, array subscripting, . and ->;
• a binary arithmetic, shift, comparison or logical operator, including pointer arithmetic and the difference of two pointers;
• a call to a function by name, declared earlier, or through a function pointer.

Any other expression is refused:

embcc: t.c:1: error: typeof of an unsupported expression

This includes the name of a function or its address (typeof(f), typeof(&f)), an enumeration constant, an assignment, ++ and --, the comma operator, sizeof, _Generic, a compound literal, a statement expression, and a string literal with an L, u or U prefix. For a function, write its type as a type name.

__auto_type#

__auto_type name = initializer; declares name with the type of its initializer, after an array is converted to a pointer. The type is determined as for typeof, so the same expressions are accepted:

embcc: a.c:1: error: __auto_type cannot see the type of this initializer

The declaration must have exactly one plain identifier and an initializer (__auto_type needs a plain variable name, __auto_type needs an initializer: there is nothing else to take the type from). It is accepted at block scope only; at file scope it is a syntax error:

embcc: a.c:1:1: error: expected a type before ?

C23's auto x = expression; means the same thing, and is also accepted at block scope only.

Labels as values and computed goto#

&&label is the address of a label in the current function, of type void *, and goto *expression; jumps to such an address.

int dispatch(int op)
{
    void *table[] = { &&add, &&sub };
    goto *table[op];
add:
    return 1;
sub:
    return 2;
}

This is supported on every target. A label's address is a code address, the same kind of value a function pointer holds: on Cortex-M it has bit 0 set (Thumb state, ready for bx), and on AVR it is a word address in program memory, as gs() makes it.

A label address may also initialize an object with static storage duration inside its function, which is how a threaded interpreter keeps its dispatch table, and the difference of two label addresses is a constant there, as in GCC:

int step(int op)
{
    static void *const table[] = { &&add, &&sub };
    static const int off[] = { &&add - &&add, &&sub - &&add };
    if (op < 0)
        goto *(&&add + off[-op - 1]);
    goto *table[op];
add:
    return 1;
sub:
    return 2;
}

Arithmetic on a label address -- &&b - &&a, &&a + n -- is in bytes, as on a char * (on AVR, in words, since the address is one), the way arithmetic on a void * is (see Smaller GNU C forms). A label address cannot initialize an object outside its function: at file scope it is refused with a static initializer must be a constant, a string literal, or the address of a global. A label whose address is taken must be defined (label 'x' used but not defined). A function that contains a computed goto is never inlined; see Inlining. C++ refuses both forms (see C++).

Local labels#

__label__ name; at the start of a block, or anywhere a statement may start, declares name as a label local to that block. A macro that contains a label can then be expanded more than once in a function.

#define RETRY(stmt) do { __label__ again; again: if (!(stmt)) goto again; } while (0)

Several names may be declared at once (__label__ a, b;).

Case ranges#

case low ... high: matches every value from low to high inclusive. Write spaces around ...: case 1...5: is read as a number and refused (malformed floating constant).

switch (c) {
case '0' ... '9': return DIGIT;
case 'a' ... 'z': return LOWER;
}

A range whose bounds are reversed is an error (case range 5 ... 1 runs backwards), and so is a value that two labels cover (duplicate case label 3).

Designated range initializers#

In an array initializer, [first ... last] = value initializes every element from first to last:

int widths[10] = { [2 ... 5] = 8, [7] = 16 };

GCC's older spellings of a designator are accepted too, with a --pedantic warning: { x: 1 } for { .x = 1 }, and [3] 7, without the =, for [3] = 7.

Zero-length and flexible arrays#

A structure member may be declared as an array of length zero, the pre-C99 form of a flexible array member. It contributes no size.

An object may be an array of length zero too: int z[0];, or int z[] = {};, whose empty initializer gives it no elements. Its size is 0, and it still has an address: a local takes one byte of the frame and a global one byte of its section, so two of them never compare equal. int z[]; with no initializer is still an incomplete type. --pedantic warns about each (an array of size 0 is a GNU extension, not ISO C).

A structure with a flexible array member may be initialized statically, including its trailing array:

struct msg { int len; char data[]; };
struct msg hello = { 5, { 'h', 'e', 'l', 'l', 'o' } };

Additional types#

The size, alignment and format of each type per target are in Targets.

Alternate keywords#

These spellings are accepted wherever the standard keyword is, so that headers written for -ansi work:

Smaller GNU C forms#

--pedantic warns about each of these (... is a GNU extension, not ISO C), except in system headers and after __extension__; --pedantic-errors refuses them. $ gets the warning under --std=c89 and gnu89 only, as in GCC: C99 allows an implementation to accept other characters in identifiers.

GNU extensions that are not supported#

Each of these is refused with the diagnostic shown.

Attributes#

Syntax#

EmbCC reads attributes in two spellings:

• GNU: __attribute__((name)) or __attribute__((name(arguments))), with several attributes separated by commas;
• C23: [[name]], [[gnu::name]] or [[__gnu__::name]]. The standard names [[maybe_unused]], [[nodiscard]] and [[_Noreturn]] mean unused, warn_unused_result and noreturn; the others coincide with their GNU names. The scope is dropped whatever it is, so [[clang::packed]] also means packed.

Each name may also be written with two leading and two trailing underscores (__packed__). The two spellings share one parser, so an attribute means the same in both.

An attribute may appear:

• at the start of a declaration, or among its specifiers, after a storage class or a qualifier (static const __attribute__((aligned(4))) char t[4];), at any scope, and so in a structure member's or a parameter's specifiers;
• after a declarator, including after a function's parameter list;
• after struct, union or enum, before the tag, or after the closing brace of the definition (not between the tag and {);
• at the start of a structure member's declaration, or after the member's declarator;
• at the start of a parameter's declaration, before its type;
• after a * in a declarator, where weak, noreturn, format, packed, aligned, section and pcs apply to the declaration;
• as a statement on its own (__attribute__((fallthrough));, [[fallthrough]];), and after a label.

These positions are not accepted:

• after a parameter's name, int f(int x __attribute__((unused))): expected ')' before '__attribute__';
• a C23 attribute after a declarator's name, int x [[gnu::aligned(16)]];: expected an expression, got '[';
• on an enumerator: expected '}' before '__attribute__';
• after the * of a structure member's declarator, for an attribute that changes layout or linkage: __attribute__((weak)) is not supported in this position (after a declarator it is; on a struct or union, put it right after the keyword or after the closing '}');
• in the type name of a cast or sizeof, for an attribute that changes layout or linkage, which has no declaration there to apply to: __attribute__((aligned)) is not supported in a type name: there is no declaration here to carry it.

How EmbCC treats an attribute#

Every attribute name EmbCC knows has one of four dispositions:

• Honored: EmbCC acts on it, as described below.
• Accepted with no effect: it asks for something that is already true of EmbCC's output, or that only matters to an analysis EmbCC does not perform. It is accepted without a diagnostic.
• Accepted with a warning: error and warning. Ignoring them is not a miscompilation, but the check they ask for does not happen, so EmbCC says so under --warn=attributes.
• Refused: ignoring it would generate different code from what the program asks for, so it is an error that names the attribute.

An attribute EmbCC does not know is ignored with a warning, which --no-warn=attributes silences:

embcc: attr.c:1: warning: attribute 'frobnicate' is not one EmbCC knows, and is ignored [--warn=attributes]

Function attributes#

constructor(N) and destructor(N) take a priority, as in GCC. The address goes in a section of its own, .init_array.NNNNN or .fini_array.NNNNN (.init_array.00101 for 101), and the link orders the arrays:

• EmbLD's default layout places the numbered sections ascending, ahead of the plain .init_array, as GNU ld's default script does. A linker script orders them with KEEP(*(SORT_BY_INIT_PRIORITY(.init_array.*))) before KEEP(*(.init_array)).
• So constructor(101) runs before constructor(200), and both before every constructor without a priority. Destructors run in the reverse order, since the exit code walks .fini_array backwards.
• A priority from 0 to 100 is reserved for the implementation and warns under -Wprio-ctor-dtor (on by default, as in GCC); one above 65535 is refused. Objects from clang, which names the sections .init_array.101, sort with EmbCC's.

Declarations of one function that disagree are refused: two different sections ('f' is placed in section '.a' here and '.b' before) or two different pcs conventions.

Variable attributes#

Type attributes#

packed applies to a whole structure or union. Written on a single member, before or after its declarator, it is accepted and has no effect.

An alignment on a typedef name is the type's, as in GCC and Clang. It can be larger or smaller than the type's own, and the size does not change:

• typedef uint8_t dma_buf_t[64] __attribute__((aligned(32))); places every dma_buf_t object on a 32-byte boundary.
• typedef uint32_t u32_una __attribute__((aligned(1))); is the idiom for an unaligned access. Through a u32_una *, EmbCC reads and writes as it does a packed structure's member: byte by byte where the core would trap on a misaligned word (Cortex-M0, SPARC, MIPS).
• A structure member of such a type is placed by that alignment, so struct { char c; u32_una x; } is five bytes.

An array of a type whose alignment is greater than its size is refused, as GCC and Clang refuse it, since its second element could not be aligned. A function parameter of such a type is passed, and has its address, as its type would without the attribute.

A packed attribute on a typedef name, rather than on the structure it names, is refused inside a function. A typedef of a structure that carries its own aligned or packed keeps that layout.

Statement and label attributes#

fallthrough (as __attribute__((fallthrough)); or [[fallthrough]];) is accepted and has no effect; EmbCC does not warn about a case that falls through. unused after a label is accepted.

aligned#

The argument of aligned is an integer constant expression, evaluated as the operand of _Alignas is. aligned(2*32) and aligned((64)) give 64, and aligned(sizeof(long long)) gives the size of long long:

#define CACHE_LINE 64
struct ring { unsigned head, tail; } __attribute__((aligned(CACHE_LINE)));
struct line { char bytes[CACHE_LINE]; } __attribute__((aligned(2 * CACHE_LINE)));

The value must be a positive power of two. Any other value, including 0, and an argument that is not an integer constant expression are refused:

embcc: a.c:1: error: aligned wants a constant power of two

_Alignas makes the same check (_Alignas requires a constant power of two), except that _Alignas(0) is accepted and has no effect, as C11 specifies.

A local whose alignment exceeds what the stack pointer guarantees (16 bytes on x86-64, AArch64 and RISC-V, 8 on Cortex-M) is placed in storage that EmbCC aligns at function entry, so its address has the requested alignment at any call depth. That holds for a scalar as well as an array, structure or union; a scalar so aligned is read and written in that storage, as a variable whose address is taken is, rather than kept in a register.

On AVR, whose stack pointer has no alignment at all, every local with an alignment greater than 1 is placed that way.

_Alignas and #pragma pack interact with aligned as in GCC: the stricter of aligned(N) and _Alignas(N) applies, and #pragma pack(N) caps every member's alignment at N, including one raised by a member's aligned.

section#

section("name") places a file-scope variable or a function in the named section of the object file.

For a variable:

• A name beginning .text makes the section executable, and one beginning .rodata read-only. Any other name gives a writable section.
• .bss and names beginning .bss. give a section with no file contents (NOBITS). An object placed there cannot have an initializer: 'z' has an initializer but is placed in NOBITS section '.bss.x'.
• A const object with a section goes to that section, not to .rodata.
• An object without an initializer is zero-filled in its section.
• A thread-local object cannot have a section: 'z' is __thread and also names a section: a thread-local object has to be in .tdata or .tbss, which is what makes it per-thread.

For a function, the code is placed in the named section, and the functions that share a section are emitted together. With -g, a unit whose code is in more than one section describes it with DW_AT_ranges. A function and a variable cannot share a section name (section '.shared' holds a function, and 'd' cannot share it: one is code, the other data).

section on a static local places it as on a file-scope object, as GCC does: static uint32_t boots __attribute__((section(".noinit"))); inside a reset handler goes to .noinit, under the local symbol function.boots. On an automatic variable, which lives on the stack, it is refused:

embcc: s.c:1: error: section attribute on 'x', which is on the stack: only a static local can be placed in a section

On a structure member it is accepted and has no effect.

pcs#

pcs("aapcs") and pcs("aapcs-vfp") select the ARM procedure-call standard for one function, whatever -mfloat-abi selects for the rest of the program: aapcs passes floating-point values in core registers, and aapcs-vfp in VFP registers. Runtime libraries put pcs("aapcs") on helpers that must keep the base convention under --float-abi=hard. See Calling convention: AAPCS32.

On a function-pointer parameter, pcs is accepted and has no effect.

Attributes accepted with no effect#

These are accepted without a diagnostic. The reason is the one EmbCC records for each.

returns_twice is accepted because newlib's <setjmp.h> puts it on setjmp, and is not acted on. Above --opt=none, a local variable that the optimizer keeps in a register across a call to such a function can hold a stale value after the second return. A volatile local is kept in memory at every optimization level, so a value stored in it between the two returns is still there after the second, as C requires; declare a local volatile when it is changed after setjmp and read after longjmp.

error("message") and warning("message") are accepted with a warning, because GCC reports a call to such a function only after optimization, and EmbCC does not:

embcc: e.c:1: warning: __attribute__((error)) is accepted but does nothing here: it makes a CALL to this function a compile error unless the optimizer removes the call, so the diagnostic has to wait until after optimisation and EmbCC issues its own before then; a build-time assertion written with it will not fire [--warn=attributes]

A build-time assertion written with error therefore does not fail the build. Use _Static_assert.

Attributes that are refused#

Each of these is an error of the form __attribute__((NAME)) is not supported: REASON:

ms_abi and sysv_abi are refused on every target, including x86_64-windows-gnu.

Object formats#

Some attributes need support from the object-file writer.

Embedded programming attributes#

This section collects the attributes used in firmware. How to write a vector table, a startup routine and handlers for each board is in Embedded programming.

Interrupt handlers#

On RISC-V, MIPS, RX, ColdFire, TriCore and ARMv7-A a handler with parameters or a non-void result is refused, and so is a function given two different kinds; the attribute may be on a prototype, on the definition or on both. In C++ the attribute is refused except on Cortex-M. The refusals read:

embcc: isr.c:2: error: __attribute__((interrupt)) is not supported: the handler would return with an ordinary return instead of the interrupt return the CPU needs, and without saving the registers (on ARMv7-M it needs neither, and is accepted; on AVR, RISC-V, MIPS, RX, ColdFire, TriCore and ARMv7-A it is implemented)
embcc: isr.c:2: error: __attribute__((signal)) is not supported: an interrupt handler needs the machine's own return instruction and every register saved, which only the AVR backend does
embcc: isr.c:2: error: interrupt handler 'isr' takes parameters: the hardware calls it, so nothing passes them, and they would be read out of whatever the interrupted code left in the argument registers
embcc: isr.c:2: error: interrupt handler 'isr' returns a value: the interrupt return goes back to the interrupted instruction, and nothing there receives it -- it must return void

How to install a handler on each board, and what each one saves, is in Embedded programming: RISC-V and MIPS32. For the AVR vector names (__vector_N), see AVR.

naked is supported on every target but x86-64 and Apple arm64: the body is assembled as a block of the target's assembly (on AArch64, from its inline-asm vocabulary); see Naked functions. On those two it is refused, and a function that must run without a prologue is written in assembly.

Placing code and data#

section puts a vector table, a function that must run from RAM, or a table collected by the linker into a named section:

void reset(void);

__attribute__((section(".vectors"), used))
void (*const vectors[])(void) = { (void (*)(void))0x20010000u, reset };

__attribute__((section(".ramfunc"))) void flash_write(void) { /* ... */ }

Add used to a table that nothing in the program refers to by name, so that it is emitted.

Default handlers#

weak together with alias gives the CMSIS pattern in which every interrupt handler defaults to one function and the application overrides the ones it needs:

void Default_Handler(void) { for (;;) { } }
void SysTick_Handler(void) __attribute__((weak, alias("Default_Handler")));

The target of alias must be defined in the same file.

AVR program memory#

On AVR, __flash is GCC's address space 1: const data kept in program memory and read with lpm. It is predefined as clang defines it, __attribute__((__address_space__(1))), and EmbCC takes that attribute as a qualifier wherever const may stand. See Data in program memory for the rules. Another address space, or address space 1 on another target, is refused by name. __memx is not defined. __attribute__((progmem)) (avr-libc's PROGMEM) places a const static object in .progmem.data on AVR, without changing its type; it is read with pgm_read_byte() and the rest of <avr/pgmspace.h>. On other targets it is ignored with a --warn=attributes warning.

avr-gcc's __builtin_avr_* are there, each with the __BUILTIN_AVR_* macro avr-gcc predefines for it:

They are AVR's alone: on another target __has_builtin says no, and a call is an undeclared function. __builtin_avr_flash_segment (it needs __memx) and the fixed-point ones (_Fract, _Accum) are not there.

Builtin functions#

General rules#

A name is a builtin only in its __builtin_ spelling (and, for the atomics, its __atomic_ or __sync_ spelling). EmbCC treats no library function name, such as memcpy or printf, as a builtin, with or without --no-builtins.

A __builtin_ name EmbCC does not implement is an undeclared function:

embcc: f.c:1:22: error: '__builtin_cpu_supports' is not declared in 'f' — for a call, add a prototype or define it first [E0001]

Whether a builtin is available does not depend on the target, but its code generation can: the tables below give the targets where it compiles. Elsewhere it is refused when the function that uses it is compiled.

Integer bit operations#

All return int, take an integer argument, and compile on every target. The operand width is the target's: long is 32 bits on Cortex-M, RV32 and AVR, and int is 16 bits on AVR. GCC leaves clz and ctz of zero undefined; EmbCC returns the operand's width, as GCC folds them, which code should not depend on.

GCC 14's type-generic forms count at the operand's own width, whatever unsigned integer type it is, unsigned char to unsigned __int128 (and _BitInt up to 64 bits); ffsg and clrsbg take a signed one. bool and an enumeration are refused, as GCC refuses them (__builtin_clzg takes an unsigned integer type, as in GCC, not int). All return int:

C23's <stdbit.h> operations as builtins (GCC 15's), type-generic the same way -- EmbCC's own <stdbit.h> needs none of them, but code written for GCC calls them by name:

The counts are unsigned int. A width that is not a power of two is refused for the rotates, and above 64 bits only __int128 is taken.

Every builtin in this section -- and the byte swaps and clang's bit reversals and rotates below -- is a constant when its operands are, as in GCC and clang: _Static_assert(__builtin_popcount(MASK) == 4, ""), an array size, a case label, or a register field's shift written __builtin_ctz(FIELD_MASK) in a static table's initializer.

clang's bit reversals and rotates take and return the unsigned type of their width (uint8_t to uint64_t):

Byte swapping#

The result has the builtin's size on every target, and the argument is converted to the result type before its bytes are reversed. All three compile on every target. On Cortex-M, RV32 and AVR the swap is computed with shifts, masks and ORs.

Checked arithmetic#

__builtin_add_overflow(a, b, res), __builtin_sub_overflow and __builtin_mul_overflow compute a + b, a - b or a * b as if with unlimited range, store the result converted to the type *res points to, and return 1 if the stored value differs from the mathematical result and 0 otherwise. a and b are integers of any type; res points to an integer. They compile on every target.

__builtin_add_overflow_p(a, b, c), __builtin_sub_overflow_p and __builtin_mul_overflow_p return whether the same operation overflows the type of c. The value of c is not used; it is evaluated for its side effects only.

The result is int, not _Bool as in GCC. A wrong operand is refused: __builtin_add_overflow: operand 1 must be an integer, got double, or __builtin_add_overflow: the third argument points at the integer to store the result in.

Floating-point constants#

These are constants and may appear in static initializers. The string argument of __builtin_nan is not used: the result is always the same NaN, whatever payload the string names. The long double forms compile wherever long double values do; on RISC-V, operations on long double are refused (the RV32 backend cannot lower a 128-bit value yet ...).

Floating-point classification and sign#

fabs and copysign return the floating type their suffix names; the others return int. The classification builtins take a floating argument of any type, and refuse an integer (__builtin_isnan takes a floating-point argument). All of them operate on the bits of the value: they do not round, raise no floating-point exception, and call no library.

__builtin_powi(x, n), __builtin_powif and __builtin_powil raise a double, float or long double x to the int power n, by squaring and multiplying over n's bits and taking 1 / x^-n for a negative n, as libgcc does. They are calls to libgcc's names, __powidf2, __powisf2 and __powixf2 (x87 long double) or __powitf2 (binary128), which EmbCC's runtime defines on every target, so an object of GCC's that calls them links too. GCC documents no precision for them, and neither does EmbCC: a result can differ from pow's in the last bit.

__builtin_complex(re, im) is the complex of re's and im's type -- both one real floating type, as GCC requires (__builtin_complex takes two parts of one real floating type, as in GCC, not double and float) -- made of those two parts, whatever they are: an infinite or NaN imaginary part and a negative zero survive, which re + im * I does not keep. Of constants it is a constant, so EmbCC's <complex.h> defines C11's CMPLX, CMPLXF and CMPLXL with it, and they initialize a static object, as C11 asks.

Floating-point comparisons#

The operands are compared in their common real type, and each is evaluated once. They are <math.h>'s comparison macros; EmbCC does not track floating-point exceptions, so the quiet and signaling forms are the same comparisons.

Type classification#

__builtin_classify_type(x) is GCC's class of x's type, after an array or function decays and an integer is promoted: 1 for an integer (an enum and a _Bool among them), 5 for a pointer, 8 for a real floating type, 9 for a complex one, 12 for a structure, 13 for a union and 0 for void. x is not evaluated.

They compile on every target. A 16-byte long double (x87's 80-bit format on x86-64, IEEE binary128 on AArch64 ELF and Linux) is stored to a stack slot and its sign and exponent are read and written there; the other widths stay in registers. On RISC-V, where every operation on a long double is refused, so are these.

Square root#

Where the target has a square-root instruction for the type, the builtin is that instruction, and its result is correctly rounded:

Everywhere else -- a double on a single-precision Cortex-M FPU, soft-float Cortex-M, RISC-V, AVR, and a 16-byte long double -- the builtin is a call to sqrt, sqrtf or sqrtl, as with GCC, and the program must link a math library that defines it. The precision is then that library's; EmbCC's own sqrtl computes in double (see Libraries). On RISC-V, __builtin_sqrtl is refused with every other long double operation.

Library functions#

__builtin_memcpy, __builtin_memmove, __builtin_memset, __builtin_memcmp, __builtin_memchr, __builtin_strlen, __builtin_strcmp, __builtin_strncmp, __builtin_strcpy, __builtin_strncpy, __builtin_strcat and __builtin_strchr are the library functions under another name: each becomes a call to the function without the prefix, which the program must provide at link time. memcpy, memmove and memset may also be expanded inline. See What the compiler emits calls to.

The other C and POSIX library functions GCC has a builtin for are the same, without the inline expansion: __builtin_abort, __builtin_exit, __builtin_printf, __builtin_malloc, __builtin_stpcpy, __builtin_isdigit, __builtin_sin and __builtin_sinf, among the functions of <stdlib.h>, <stdio.h>, <string.h>, <strings.h>, <ctype.h>, <math.h> (each with its f and l variant) and <complex.h>. When the program has no declaration of the function, EmbCC declares it with its C prototype, so __builtin_printf needs no <stdio.h>. __builtin_memcmp_eq is memcmp.

The _FORTIFY_SOURCE forms, such as __builtin___memcpy_chk(d, s, n, size) and __builtin___sprintf_chk(s, flag, size, fmt, ...), are the call without the object-size arguments. They are what GCC calls when the size is unknown, and EmbCC has no sizes to check.

Object size#

__builtin_object_size(ptr, type) and __builtin_dynamic_object_size(ptr, type) return the number of bytes reachable through ptr, as a size_t constant. EmbCC answers with the object's size when ptr is the address of a named object that is not an array or a pointer (&s). For every other argument it returns the value that means "unknown": (size_t)-1 for type 0 and 1, and 0 for type 2 and 3. A _FORTIFY_SOURCE header reads that value as "do not check".

Compile-time builtins#

Control flow#

The trap is ud2 on x86-64, udf on AArch64 and Cortex-M, unimp on RISC-V and break on MIPS32. The breakpoint is the one each target's debugger plants: int3 on x86-64, brk #0xf000 on AArch64 (lldb steps over it, as for clang's), bkpt #0 on Cortex-M and ARMv7-A, ebreak on RISC-V, break on MIPS and AVR, break 0 on LoongArch, debug on TriCore, break 1, 15 on Xtensa, trap on PowerPC, ta 1 on SPARC, brk on RX and halt on ColdFire. AVR has no trapping instruction, and the trap is a jump to itself. A call to either builtin ends a path for the missing-return check, as a call to a noreturn function does.

Stack and frames#

level must be a non-negative integer constant (__builtin_frame_address needs a non-negative constant level).

A frame chain. x86-64, AArch64 and ColdFire code keeps a chain of saved frame pointers, so any level can be walked.

Level 0 only. Code for the other targets keeps no chain, and only the current function's own frame can be found. A higher level is refused:

embcc: r.c:1: error: __builtin_return_address(1) is not supported on riscv32-unknown-elf: code for this target keeps no frame-pointer chain, so only level 0 (this function's own frame) can be found

At level 0, a function that asks for its return address saves it, as a function that calls does. __builtin_return_address(0) is:

__builtin_frame_address(0) is:

Interrupt handlers. In a RISC-V, MIPS or AVR interrupt handler, __builtin_return_address is refused: a handler was not called, and what it returns to is the trap's. AVR refuses __builtin_frame_address there too.

A function that calls alloca is never inlined.

Variable arguments#

__builtin_va_list is the type char *, the representation of va_list on every target. __builtin_va_start(ap, last), __builtin_va_arg(ap, type), __builtin_va_copy(dest, src) and __builtin_va_end(ap) are what <stdarg.h>'s macros expand to. Using va_start in a function that is not variadic is refused (va_start in 'f', which is not variadic). Passing and retrieving structures through ... is described in C language.

__builtin_setjmp and __builtin_longjmp#

GCC's pair, for a jump with no C library behind it (a language runtime, an SJLJ unwinder): __builtin_setjmp(buf) returns 0, and 1 when __builtin_longjmp(buf, 1) comes back to it, from anywhere below while the function that called __builtin_setjmp has not returned. buf is GCC's five words. EmbCC keeps an ordinary jmp_buf in that function's frame, stores its address in buf[0], and calls the runtime's own setjmp and longjmp on it (lib/rt's, built from lib/libc's for every target; the system C library's _setjmp and _longjmp on Darwin and with --libc=system). As with setjmp, a local changed between the two and read after the jump must be volatile. __builtin_longjmp takes only the constant 1, as in GCC; both are refused on Windows (x86_64-windows-gnu), whose _setjmp takes a frame for its unwinder. clang has the pair on fewer targets (not on AArch64 macOS).

Builtins that are not supported#

These are refused as undeclared functions, as shown in General rules: __builtin_va_arg_pack, clang's __builtin_elementwise_*, __builtin_reduce_* and __builtin_nontemporal_load, __builtin_cpu_supports and __builtin_cpu_init, the x86 family (__builtin_ia32_*). __builtin_addressof, __builtin_bit_cast and __builtin_is_constant_evaluated exist in C++ only; see C++.

Atomic builtins#

The builtins#

EmbCC implements GCC's two families.

The _n and arithmetic forms take an integer or a pointer of 1, 2, 4, 8 or 16 bytes. A wrong argument count or type is refused, for example __atomic_load_n takes 2 arguments, not 3 or __atomic_fetch_add works on an integer or pointer of 1, 2, 4, 8 or 16 bytes, not double. The __sync builtins accept, and ignore, the trailing list of variables GCC allows.

clang's __c11_atomic_* family -- init, load, store, exchange, compare_exchange_strong and _weak, fetch_add, _sub, _and, _or, _xor and _nand, thread_fence, signal_fence and is_lock_free -- are the __atomic_* builtins of the same names with clang's arguments (init is a relaxed store, and a compare-exchange's strength is in its name). __c11_atomic_fetch_add and _fetch_sub of an atomic pointer count elements, as C11's atomic_fetch_add does (7.17.7.5), where GCC's __atomic_fetch_add counts bytes; EmbCC's <stdatomic.h> adds and subtracts with them, so atomic_fetch_add(&p, 1) on an _Atomic(int *) moves p by one int, as with clang -- GCC's <stdatomic.h> moves it by one byte.

On RISC-V the memory order of a read-modify-write or compare-exchange selects its .aq and .rl bits as clang's does: relaxed is bare, acquire .aq, release .rl, and acq_rel and seq_cst .aqrl on an AMO; an lr/sc loop takes the acquire on the lr and the release on the sc, and seq_cst is lr.aqrl/sc.rl. A compare-exchange's failure order strengthens its success order, as clang merges them. An order that is not a constant is seq_cst, as are the __sync builtins and the operators on an _Atomic object. On every other target every operation is sequentially consistent: the memory-order arguments are accepted and do not change the code. __atomic_signal_fence emits the same barrier as __atomic_thread_fence. No operation of 1, 2 or 4 bytes, or of 8 on a 64-bit target, calls a library; an eight-byte one on a 32-bit target does (below).

__atomic_always_lock_free and __atomic_is_lock_free are integer constant expressions, usable in _Static_assert. The size must be a constant (__atomic_is_lock_free needs a constant size). They answer 1 for sizes 1, 2, 4 and 8 and 0 otherwise, on every target; the answer does not reflect the table below.

Sizes per target#

16-byte operations need __int128 or a 16-byte object through the generic forms. Other sizes are refused, for example:

embcc: a.c:1: error: an atomic access of 16 bytes is not one access on this target (it moves 8 at once): the halves could be split by an interrupt or another core

Eight bytes on a 32-bit target#

Every 32-bit target -- Cortex-M, ARMv7-A, RV32, MIPS32, SPARC, PowerPC, ColdFire, TriCore, Xtensa and RX -- does an eight-byte atomic by calling libatomic's sized routine, as GCC and clang do there (none of them moves eight bytes atomically):

The orders are the __ATOMIC_* values as the call wrote them -- a variable order is passed as its value -- and seq_cst (5) for the __sync builtins and the operators, except __sync_lock_release's release (3), as clang passes them. lib/rt defines every one, weak, by masking interrupts; see Embedded programming for what that does and does not cover, and how to replace them.

The instructions used on each embedded target are described in Embedded programming. _Atomic objects and the <stdatomic.h> interface are described in C language.

Vector extensions#

__attribute__((vector_size(N))) makes a vector of N bytes of an integer or floating type, as in GCC:

typedef int v4si __attribute__((vector_size(16)));

v4si scale(v4si a, int k)
{
    return (a << 1) + k;        /* k goes to every lane */
}

The attribute is taken on a typedef, a variable, a member, a parameter and in a type name, before the type or after the declarator, so the usual macro spelling, #define vector __attribute__((vector_size(16))) with vector float x, works too. N is a power of two and a whole number of lanes; _Bool and long double lanes are refused.

A vector is assigned, passed, returned and placed in structures and arrays like a structure of its lanes. Its alignment is its size, up to 16 bytes on x86-64 and AArch64 and 8 on Arm, as GCC and clang align vectors there. A vector cannot be the condition of if, ?:, && or ||, as in GCC (used vector type where scalar is required).

EmbCC computes the operations lane by lane with the target's scalar instructions, so they run on every target, AVR and Cortex-M0 included. They are not translated to SIMD instructions; the optimizer's automatic vectorization is separate, see Optimization. A vector argument is passed as that structure would be. On x86-64 and AArch64, where GCC passes a vector in a SIMD register, a function taking or returning one by value does not interoperate with GCC-compiled code. Arithmetic on vectors in a static initializer is refused; a braced initializer, v4si g = {1, 2, 3, 4};, is fine. Clang's ext_vector_type is not recognized; it draws the unknown-attribute warning, and the type stays a scalar.

Feature-test operators#

__has_include and __has_include_next#

__has_include(<header>) and __has_include("header") are 1 if the header can be found by the search an #include of the same name would make, and 0 otherwise. __has_include_next asks the same about the search #include_next would make.

__has_builtin#

__has_builtin(name) is 1 for:

• the integer bit operations, byte swaps, checked arithmetic, floating-point constants, classification and square-root builtins, __builtin_alloca, __builtin_alloca_with_align, __builtin_assume_aligned, __builtin_constant_p, __builtin_expect, __builtin_expect_with_probability, __builtin_frame_address, __builtin_return_address, the memory and string builtins, __builtin_object_size, __builtin_dynamic_object_size, __builtin_offsetof, __builtin_prefetch, __builtin_trap, __builtin_unreachable, __builtin_va_arg, __builtin_va_copy, __builtin_va_end and __builtin_va_start;
• every __atomic_ and __sync_ builtin listed in Atomic builtins.

It is 0 for __builtin_types_compatible_p, __builtin_choose_expr, __builtin_LINE, __builtin_FILE and __builtin_va_list, although EmbCC implements them, and for every name it does not implement. The answer does not depend on the target: a builtin that the target's code generator refuses still answers 1.

__has_attribute#

__has_attribute(name) accepts name, __name__ and a gnu:: or __gnu__:: scope. It is 1 for: access, aligned, alloc_align, alloc_size, always_inline, artificial, cold, const, deprecated, fallthrough, flatten, format, gnu_inline, hot, leaf, malloc, may_alias, maybe_unused, no_sanitize, no_sanitize_address, nodiscard, noinline, noipa, nonnull, noreturn, nothrow, packed, pure, returns_nonnull, section, sentinel, unused, used, visibility, warn_unused_result and weak. It is also 1 for abi_tag, format_arg, likely, unavailable and unlikely, which C does not recognize (each draws the unknown attribute warning), and for externally_visible, which C takes with no effect.

It is 0 for every other name, including attributes EmbCC implements: alias, constructor, destructor, embcc_sret, interrupt, pcs and signal. Test for those with __EMBCC__ and the target macros.

__has_c_attribute and __has_cpp_attribute#

__has_c_attribute(name) is defined in C and is 0 for every name, although EmbCC accepts the C23 attributes [[noreturn]], [[deprecated]], [[nodiscard]], [[maybe_unused]] and [[fallthrough]]. __has_cpp_attribute is defined only in C++.

__has_feature and __has_extension#

Both answer the same. They are 1 for c_static_assert, c_generic_selections, c_atomic, c_alignas, c_alignof, c_thread_local, tls, attribute_deprecated_with_message, attribute_unavailable_with_message and enumerator_attributes, and 0 for every other name. Three of these answers overstate what C accepts: tls is 1 on Mach-O and COFF targets, where __thread is refused; unavailable is not recognized; and an attribute on an enumerator is a syntax error.

Using the operators#

Each operator counts as defined, so the guarded form used by portable headers works:

#if defined(__has_include) && __has_include(<stdatomic.h>)
#include <stdatomic.h>
#endif

#ifdef and #elifdef see them the same way. In C, an operator is evaluated only where it is written in the #if line itself. One that a macro expands to is not:

#define HAS(x) __has_builtin(x)
#if HAS(__builtin_clz)        /* error: trailing junk in #if expression */
#endif

In C++ both forms work.

Preprocessor extensions#

Supported#

Not supported#

Pragmas#

#pragma pack#

#pragma pack sets the maximum alignment of the members of the structures and unions defined after it. It takes these forms:

The limit applies to a structure as a whole, at the point where its definition starts, including a definition inside a function. _Pragma("pack(1)") is the same as #pragma pack(1). The argument is not macro-expanded, as in GCC on ELF targets.

#pragma once#

A file containing #pragma once is not read again by a later #include. The same file is recognized by its path, or, when it is reached by another spelling of the path, by its contents, as GCC does.

#pragma push_macro and #pragma pop_macro#

#pragma push_macro("NAME") saves the current definition of the macro NAME, or the fact that it has none. #pragma pop_macro("NAME") restores the most recently saved one: NAME is redefined as it was, or undefined if it was undefined then. Saves nest. A pop_macro with no matching push_macro does nothing, as in GCC. Both work as _Pragma operators, _Pragma("push_macro(\"NAME\")").

#pragma weak#

#pragma weak NAME makes NAME a weak symbol, as __attribute__((weak)) on its declaration does: a weak definition, or a weak reference that resolves to 0 when nothing defines it. The pragma may come before or after the declaration. #pragma weak NAME = TARGET also makes the function NAME an alias of TARGET, which must be defined in the same file. Refused forms:

#pragma GCC diagnostic#

#pragma GCC diagnostic KIND "-WNAME" sets the warning NAME from the pragma's position on; #pragma clang diagnostic and the _Pragma operator form are the same. Each warning is decided by the pragmas before it in the preprocessed text, so a pragma in a header applies after the #include unless the header pops it.

A pragma that names a warning EmbCC does not have is ignored without a diagnostic; EmbCC never reports that warning, so the pragma would change nothing. Other kinds, such as ignored_attributes, are ignored. --no-warnings and the suppression of warnings in system headers apply whatever the pragmas say. A warning located in a header that is included more than once is decided at the header's last inclusion.

Every other pragma is ignored#

Every other #pragma and _Pragma is removed without a diagnostic, and does not appear in -E output. This includes pragmas that change a program's meaning or its diagnostics in GCC and Clang:

Accepted without effect#

These constructs are accepted, have no effect, and draw no diagnostic. Each is described in its section above.

• Every pragma except pack, once, push_macro, pop_macro, weak and GCC diagnostic.
• packed and section on a single structure member.
• pcs on a function-pointer parameter.
• The memory-order arguments of the atomic builtins.
• The payload string of __builtin_nan.
• weak and visibility on COFF output, and visibility on Mach-O output.