[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug binutils/28614] New: [AArch64] opcodes/aarch64-*: -Werror=maybe-uni
From: |
pexu at sourceware dot mail.kapsi.fi |
Subject: |
[Bug binutils/28614] New: [AArch64] opcodes/aarch64-*: -Werror=maybe-uninitialized hit unless assertations are enabled |
Date: |
Mon, 22 Nov 2021 13:25:48 +0000 |
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.
- [Bug binutils/28614] New: [AArch64] opcodes/aarch64-*: -Werror=maybe-uninitialized hit unless assertations are enabled,
pexu at sourceware dot mail.kapsi.fi <=
- [Bug binutils/28614] [AArch64] opcodes/aarch64-*: -Werror=maybe-uninitialized hit unless assertations are enabled, pexu at sourceware dot mail.kapsi.fi, 2021/11/22
- [Bug binutils/28614] [AArch64] opcodes/aarch64-*: -Werror=maybe-uninitialized hit unless assertations are enabled, cvs-commit at gcc dot gnu.org, 2021/11/25
- [Bug binutils/28614] [AArch64] opcodes/aarch64-*: -Werror=maybe-uninitialized hit unless assertations are enabled, nickc at redhat dot com, 2021/11/25
- [Bug binutils/28614] [AArch64] opcodes/aarch64-*: -Werror=maybe-uninitialized hit unless assertations are enabled, pexu at sourceware dot mail.kapsi.fi, 2021/11/25
- [Bug binutils/28614] [AArch64] opcodes/aarch64-*: -Werror=maybe-uninitialized hit unless assertations are enabled, tnfchris at sourceware dot org, 2021/11/26
- [Bug binutils/28614] [AArch64] opcodes/aarch64-*: -Werror=maybe-uninitialized hit unless assertations are enabled, nickc at redhat dot com, 2021/11/26
- [Bug binutils/28614] [AArch64] opcodes/aarch64-*: -Werror=maybe-uninitialized hit unless assertations are enabled, tnfchris at sourceware dot org, 2021/11/26