<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 16 November 2016 at 18:38, Nico Weber via cfe-commits <span dir="ltr"><<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I'm a bit surprised that this landed, given that gcc bug. I can see the motivation for the gcc bug: If you say your enum is going to need underlying 8 bits, then warning that your bitfield where you store it is smaller _is_ surprising.</div></blockquote><div><br></div><div>Yeah, suggesting adding an underlying type to the enum to solve this problem seems like a bad idea, since that fundamentally changes the nature of the enum -- typically allowing it to store a lot more values, and making putting it in a bitfield a bad idea.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I'm not sure if landing this while gcc still behaves the way it does is a good idea :-(</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 10, 2016 at 9:38 PM, Mehdi AMINI <span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">mehdi_amini added a comment.<br>
<span><br>
> So when this modification tells the developer to add 'unsigned' to their enum, they are subsequently causing a warning to occur in GCC.<br>
><br>
> I have commented on the bug on GCC for this (<a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242#c28" rel="noreferrer" target="_blank">https://gcc.gnu.org/bugzilla/<wbr>show_bug.cgi?id=51242#c28</a>), but it looks unlikely to be fixed.<br>
><br>
> Should we go ahead and add this warning when following its instructions will cause a warning in the GCC compiler? Even though GCC is at fault here, I'm not sure what the right thing is to do.<br>
<br>
</span>GCC seems to agree that they should fix it: <a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61414" rel="noreferrer" target="_blank">https://gcc.gnu.org/bugzilla/s<wbr>how_bug.cgi?id=61414</a> ; so I wouldn't consider it a blocker.<br>
<br>
But I'm not using GCC either, and I don't know what is our usual policy, so it'd be nice to have another opinion here.<br>
<br>
<br>
<a href="https://reviews.llvm.org/D24289" rel="noreferrer" target="_blank">https://reviews.llvm.org/D2428<wbr>9</a><br>
<br>
<br>
<br>
</blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@lists.llvm.org">cfe-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-commits</a><br>
<br></blockquote></div><br></div></div>