[llvm-bugs] [Bug 48441] New: SVE builtins accepting enum svprfop or svpattern do not fire -Wenum-conversion on misuse

via llvm-bugs llvm-bugs at lists.llvm.org
Tue Dec 8 06:03:44 PST 2020


https://bugs.llvm.org/show_bug.cgi?id=48441

            Bug ID: 48441
           Summary: SVE builtins accepting enum svprfop or svpattern do
                    not fire -Wenum-conversion on misuse
           Product: clang
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
          Assignee: peter.waller at arm.com
          Reporter: peter.waller at arm.com
                CC: llvm-bugs at lists.llvm.org, neeilans at live.com,
                    richard-llvm at metafoo.co.uk

The Arm C Language Extensions for SVE specification (Version 00bet6) defines a
number of builtins accepting two enum types, `svprfop` and `svpattern`.

The problem is that clang currently defines the builtins to take a values of
type "immediate integer", and this conversion-to-integer is allowed even with
-Wenum-conversion specified.

GCC correctly raises a warning with -Wenum-conversion, clang does not. Consider
this example in this case when we pass an enum prfop value through to an
intrinsic expecting an svpattern, gcc reports:

  foo.c: In function 'test_pattern_fail':
  foo.c:3:25: warning: implicit conversion from 'enum svprfop' to 'enum
svpattern' [-Wenum-conversion]
  3 |   return svptrue_pat_b8(SV_PLDL1KEEP);
    |                         ^~~~~~~~~~~~

  // REQUIRES: aarch64-registered-target
  // RUN: %clang_cc1 %s -triple aarch64-none-linux-gnu -target-feature +sve
-fallow-half-arguments-and-returns  -fsyntax-only -verify -Wenum-conversion

  #include <arm_sve.h>
  svbool_t test_pattern_fail() {
    return svptrue_pat_b8(SV_PLDL1KEEP);
  }

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20201208/1e469ed3/attachment.html>


More information about the llvm-bugs mailing list