https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127740
Bug ID: 127740
Summary: [GCC C] `__atomic_store_n (&v, f + 1, ...)` with a
`_Float16` operand into an integer object: ICE in
`c_fully_fold_internal` (c-fold.cc:677,
`EXCESS_PRECISION_EXPR`)
Product: gcc
Version: 17.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: 0599jiangyc at gmail dot com
Target Milestone: ---
**Repo:** gcc-mirror/gcc · **Commit:** `d373724d1` (master, 2026-09-17) ·
**Build:** `--enable-languages=c,c++ --disable-bootstrap
--enable-checking=yes,extra,rtl` (x86_64-pc-linux-gnu, Ubuntu 22.04)
## What happens
`var + 1` on a `_Float16` is evaluated in excess precision and wrapped in an
`EXCESS_PRECISION_EXPR`. The overloaded-builtin path
(`resolve_overloaded_builtin` ->
`build_function_call_vec` -> `convert_arguments` -> `c_fully_fold`) hands that
wrapper to
`c_fully_fold_internal`, whose `EXCESS_PRECISION_EXPR` case is `gcc_unreachable
()`. No
diagnostic, default flags (`-O0`, `-std=gnu17`).
```
t.c: In function 'store':
t.c:5:3: internal compiler error: in c_fully_fold_internal, at c/c-fold.cc:677
5 | __atomic_store_n (&v, var + 1, __ATOMIC_RELAXED);
| ^~~~~~~~~~~~~~~~
0x2cb9bab internal_error(char const*, ...)
diagnostic-global-context.cc:787
0xcdc9e4 fancy_abort(char const*, int, char const*)
diagnostics/context.cc:1813
0x7a5b9c c_fully_fold_internal
c/c-fold.cc:677
0xda489a c_fully_fold_internal
c/c-fold.cc:502
0xda489a c_fully_fold_internal
c/c-fold.cc:502
```
## Reproducer
`gcc-atomic-store-float16-excess-precision.c`:
```c
_Float16 var;
void store (void)
{
__int128_t v;
__atomic_store_n (&v, var + 1, __ATOMIC_RELAXED);
}
```
```bash
gcc -S -o /dev/null gcc-atomic-store-float16-excess-precision.c
```
A plain `v = var + 1;` compiles, `float var` compiles, storing `var` without
arithmetic
compiles; `__atomic_exchange_n` ICEs the same way. `long v` behaves like
`__int128_t v`.
## Expected
Compile; the stored value is `(long) (var + 1)` as for a non-atomic store.
## Notes
Found by fusing `gcc.target/nvptx/float16-1.c` (the `_Float16` global) with
`gcc.dg/atomic-store-5.c`. Searched Bugzilla for `c_fully_fold_internal`,
`_Float16 __atomic_store_n`,
`_Float16 atomic`: no match (PR126779 is `_Float16` with `-mno-sse2`, a
different site).
**Upstream dedup 2026-10-06:** Bugzilla quicksearch (ALL states)
`c_fully_fold_internal _Float16`, `c_fully_fold_internal
EXCESS_PRECISION_EXPR`, `__atomic_store_n _Float16`, `_Float16 atomic excess
precision`, `c-fold.cc c_fully_fold_internal`, `EXCESS_PRECISION_EXPR builtin
ICE`, `__atomic_store_n excess precision`, `EXCESS_PRECISION_EXPR builtin
argument`, `excess precision __sync builtin`, `__atomic_exchange_n _Float16`,
plus a sweep of every bug filed since 2026-09-17 and WebSearch
`site:gcc.gnu.org/bugzilla _Float16 __atomic_store_n c_fully_fold_internal`;
gcc-patches Sept/Oct 2026 subject index: only "c: Do not keep excess precision
for the result of ! [PR123370]" (Oct, unrelated operator). Verdict: **new**.
Related, mention:
[PR104427](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104427)
(`__builtin_assoc_barrier` on `_Float16 x + y` left an `EXCESS_PRECISION_EXPR`
where `c_fully_fold_internal` cannot take it; fixed r12-7148 by routing through
`build_unary_op`) is the same class of bug for a different builtin and a good
model for the fix in `resolve_overloaded_builtin`/`sync_resolve_params`;
[PR126779](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126779) (`_Float16`
with `-mno-sse2`) is a different site.
