Here were the compiler flags used with ICC:
-trigraphs -fno-omit-frame-pointer -fp-model source -fno-strict-aliasing -mIPOPT_clone_max_total_clones=0 -mP2OPT_hpo_enable_short_trip_vec=F -sox=profile -sox=inline -no-global-hoist -mP2OPT_tls_control=0 -wd191 -wd175 -wd188 -wd810 -we127 -we1345 -we1338 -wd279 -wd186 -wd1572 -wd589 -wd11505 -we592 -wd69 -we172 -Qoption,cpp,--treat_func_as_string_literal -mP2OPT_spill_parms=T -wd11505 -wd411 -wd273 -ww174 -we266 -ww279 -we589 -we810 -we1011 -ww1418 -strict-ansi -wd66 -wd76 -wd82 -wd94 -we102 -wd271 -wd424 -wd561 -wd662 -wd1511 -std=c99 -ww344 -we137 -fPIC -mP2OPT_tls_control=2
-----Original Message-----
From: Gerd Rausch
Sent: Thursday, May 23, 2019 11:15 PM
To: Jason Gunthorpe <jgg@xxxxxxxxxxxx>
Cc: linux-rdma@xxxxxxxxxxxxxxx; Aron Silverton <aron.silverton@xxxxxxxxxx>; Sharon Liu <sharon.s.liu@xxxxxxxxxx>; ZUOYU.TAO <zuoyu.tao@xxxxxxxxxx>
Subject: Re: <infiniband/verbs.h> & ICC
+Zuoyu,
Hi Zuoyo,
What compiler flags were you using while compiling the <verbs.h> file throwing the error about 'enumeration value is out of "int" range'?
On 23/05/2019 18.30, Jason Gunthorpe wrote:
> On Thu, May 23, 2019 at 03:57:29PM -0700, Gerd Rausch wrote:
>>
>> error: enumeration value is out of "int" range
>> IBV_RX_HASH_INNER = (1UL << 31),
>
> I assume you are running with some higher warning flags and -Werror?
> gcc will not emit this warning without -Wpedantic
>
Perhaps. I've added Zuoyu, who reported this issue to this e-mail thread.
>
>> Since "int" is signed, it can't hold the unsigned value of 1UL<<31 on
>> target platforms with sizeof(int) <= 4.
>
> Pedentically yes, but gcc and any compiler that can compile on linux
> supports an extension where the underlying type of an enum constant is
> automatically increased until it can hold the value of the constant.
> In this case the constant is type promoted to long, IIRC.
>
Evidently ICC supports that as well:
% icc --version
icc (ICC) 17.0.5 20170817
Copyright (C) 1985-2017 Intel Corporation. All rights reserved.
% cat foo.c
enum { FOO = 1UL << 31 } foo = FOO;
% icc -c -g foo.c && gdb -ex 'ptype foo' -ex 'print sizeof foo' foo.o type = enum {FOO = -2147483648}
$1 = 4
% cat bar.c
enum { FOO = 1UL << 31, BAR = -1 } bar = BAR; % icc -c -g bar.c && gdb -ex 'ptype bar' -ex 'print sizeof bar' bar.o type = enum {FOO = -2147483648, BAR = -1}
$1 = 8
I can't say that I'm thrilled with this behavior though, as it appears error-prone:
As soon as an enum value goes out of range for an "int", the type silently changes, potentially rendering structures and functions silently incompatible.
It's quite the pitfall (e.g. the foo.c vs bar.c case above).
>
> Can you clarify if icc is being run in some wonky mode that is causing
> this warning? AFAIK icc will compile the linux kernel, and the kernel
> makes extensive use of this extension. So I think the compiler is not
> configured properly.
>
I've added Zuoyu to the distribution to shed some light on that.
> IIRC I looked at this once for -Wpedantic support and decided it was a
> lot of work as there are more cases than just this.
>
Not exactly shocking news ;-)
Thanks for providing the information,
Gerd
