On 11 July 2017 at 17:59, Prathamesh Kulkarni <prathamesh.kulka...@linaro.org> wrote: > On 13 June 2017 at 01:47, Joseph Myers <jos...@codesourcery.com> wrote: >> This is OK with one fix: >> >>> +C ObjC Var(warn_enum_conversion) Init(0) Warning LangEnabledBy(C Objc,Wall) >> >> I believe the LangEnabledBy arguments are case-sensitive, so you need to >> have ObjC not Objc there for it to work correctly. (*.opt parsing isn't >> very good at detecting typos and giving errors rather than silently >> ignoring things.) > Hi, > Sorry for the late response, I was on a vacation. > The attached patch is rebased and bootstrap+tested on > x86_64-unknown-linux-gnu. > I have modified it slightly to not warn for enums with different names > but having same value ranges. > For eg: > enum e1 { e1_1, e1_2 }; > enum e2 { e2_1, e2_2 }; > > enum e1 x = e2_1; > With this version, there would be no warning for the above assignment > since both e1 and e2 have > same value ranges. Is that OK ? > > The patch has following fallouts in the testsuite: > > a) libgomp: > I initially assume it was a false positive because I thought enum > gomp_schedule_type > and enum omp_sched_t have same value-ranges but it looks like omp_sched_t > has range [1, 4] while gomp_schedule_type has range [0, 4] with one > extra element. > Is the warning then correct for this case ? > > b) libgfortran: > i) Implicit conversion from unit_mode to file_mode > ii) Implicit conversion from unit_sign_s to unit_sign. > I suppose the warning is OK for these cases since unit_mode, file_mode > have different value-ranges and similarly for unit_sign_s, unit_sign ? > > Also I tested the warning by compiling the kernel for x86_64 with > allmodconifg (attached), and there > have been quite few instances of the warning (attached). I have been > through few cases which I don't think are false positives > but I wonder then whether we should relegate the warning to Wextra instead ? ping: https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00514.html
Thanks, Prathamesh > > Thanks, > Prathamesh >> >> -- >> Joseph S. Myers >> jos...@codesourcery.com