[Bug binutils/28614] New: [AArch64] opcodes/aarch64-*: -Werror=maybe-uninitialized hit unless assertations are enabled

[pexu at sourceware dot mail.kapsi.fi]

https://sourceware.org/bugzilla/show_bug.cgi?id=28614

            Bug ID: 28614
           Summary: [AArch64] opcodes/aarch64-*:
                    -Werror=maybe-uninitialized hit unless assertations
                    are enabled
           Product: binutils
           Version: 2.38 (HEAD)
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: binutils
          Assignee: unassigned at sourceware dot org
          Reporter: pexu at sourceware dot mail.kapsi.fi
  Target Milestone: ---

Created attachment 13802
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13802&action=edit
Use `abort ()' instead of `assert (0)'

Hi.

A recent SME patch set for AArch64 that touches several opcodes/aarch64-* files
uses the following pattern (with variations) in many places:

int output;
switch (input)
  {
  case /* ... */:
    output = /* ... */;
    break;
  default:
   assert (0);
  }
action (output);

Unless assert expands (i.e. is enabled) to something non-returning (or
unreachable) at least GCC11 diagnoses output as potentially uninitialized
variable at call site (and rightfully so) leading to a compile error.

So, `assert (0)' should be replaced by something else that is always expanded. 
Attaching a patch that simply replaces all `assert (0)' with `abort ()'.  This
includes generated code.  Given that `abort ()' ``results  in  the abnormal
termination of the process'' the patch also removes all preceding assertation
that always fire -- This and how unreachable code should be treated is of
course up to debate, so the patch is simply a suggestion (but it does compile).

Exluding gdb there are very few locations that use `assert (0)'.  Gold uses
gold_unreachable and gnulib/import/verify.h does not appear to provide any
public interface that would provide a system agnostic __builtin_unreachable.  I
presume the latter would generate more optimal code than abort.

-- 
You are receiving this mail because:
You are on the CC list for the bug.