https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118261

            Bug ID: 118261
           Summary: ICE with sve and lto
           Product: gcc
           Version: 14.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: yyc1992 at gmail dot com
  Target Milestone: ---

The following c++ program using SVE crashes the linker if lto is enabled.

```
#include <arm_sve.h>

svfloat64_t f(svfloat64_t x, uint32_t npoints, const double *points)
{
    auto ptrue = svptrue_b64();
    auto ovr_ok = svcmplt(ptrue, x, 1);
    auto lo = svcvt_s64_x(ptrue, x);
    auto vlo = svld1_gather_index(ptrue, points, lo);
    return svdup_f64_m(vlo, svnot_z(ptrue, ovr_ok), points[npoints - 1]);
}
```

```
g++ -march=armv8-a+sve -O1 -flto -o /dev/null -shared f.cpp
during GIMPLE pass: forwprop
f.cpp: In function 'f':
f.cpp:4:13: internal compiler error: Segmentation fault
    4 | svfloat64_t f(svfloat64_t x, uint32_t npoints, const double *points)
      |             ^
0x1a9d44f internal_error(char const*, ...)
        ???:0
0x1051be4 aarch64_sve::gimple_folder::redirect_pred_x()
        ???:0
0x1051cd3 aarch64_sve::gimple_folder::fold()
        ???:0
0x1051dc3 aarch64_sve::gimple_fold_builtin(unsigned int, gimple_stmt_iterator*,
gcall*)
        ???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://github.com/archlinuxarm/PKGBUILDs/issues> for instructions.
lto-wrapper: fatal error: g++ returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
```

This is using gcc 14.1.1+r1+g43b730b9134-1 from the archlinux arm repo.
Removing -ftlo or disable optimization suppresses the issue. Any optimization
(triggers this). Splitting this into two command (one to compile the object
file and one to link it) crashes in the linker command when the optimization is
done.

According to compiler explorer, this may be a regression since 13.3 but might
have been fixed on trunk.

Reply via email to