<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Sure, there's nothing preventing us from adding aliases for warnings (or, in rare cases, changing warning flags), although ideally GCC will hopefully try and match our choice of warning flags as well when they add new ones. :)<div><br></div><div><div><div><div>On Aug 11, 2011, at 5:58 PM, Jonny Yu wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div bgcolor="#FFFFFF"><div>hi kremenek,</div><div>Thinking one step forward, F<span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); ">or the new warnings not existed now, if GCC added the same warning flag later, could Clang support that flag as well?</span></div><div><span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); ">I'm asking that because we need use both compilers, if the new options are different, it might break the current command line compatibility.</span></div><div><span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); ">Does this make sense?</span></div><div><br>Sent from my iPhone</div><div><br>On 2011-8-12, at 上午4:27, Ted Kremenek <<a href="mailto:kremenek@apple.com">kremenek@apple.com</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div><div><div>On Aug 10, 2011, at 9:25 PM, Miles Bader wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">Clang's gcc-compatibility [both for source and invocation] is absolutely<br>brilliant for users, and it's done a great job of it so far. But of<br>course for every new feature added, there's potential for divergence,<br>and it would be nice to at keep that in check as much as possible...<br><br>Is there some established mechanism for coordinating interface changes<br>with gcc where it would make sense?<br></span></blockquote></div><br><div>For existing warnings, we try and match GCC's flag names. For new warnings being added to Clang that (to our knowledge) aren't being added to GCC, there is no dialog with the GCC developers to support the same warning flag. I think dialog between the communities would be helpful in this regard, but I'm not interested in establishing an official process here for coordinating warnings between the two compilers. Generally speaking it hasn't been a problem at all, and that formal process would likely burden both communities.</div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>cfe-dev mailing list</span><br><span><a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a></span><br><span><a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a></span><br></div></blockquote></div></blockquote></div><br></div></div></body></html>