
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jul 19, 2019, at 8:04 PM, James Y Knight <<a href="mailto:jyknight@google.com" class="">jyknight@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I think it was not a good idea to remove __VERSION__, but only because it actually breaks software (and not just Python). I don't think it's terribly important to preserve theoretically-pure compatibility at this point, but it is rather useful to keep practical compatibility.</div></div></blockquote><div><br class=""></div><div>All I’m saying is that the motivation didn’t contain a section on “we checked and nobody seems to use it”.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class="">I note a couple other changes in this area which might also be problematic.</div><div class="">- "4.2.1 Compatible" was removed from the beginning of __VERSION__. </div><div class="">- clang -dumpversion reports clang's version (e.g. "9.0.0", rather than always saying "4.2.1")</div><div class=""><br class=""></div><div class="">My inclination is that the former is very unlikely to break something (why would anyone use that string for anything other than human readable output, for which the new value is better?).</div></div></div></div></blockquote><div><br class=""></div><div>It has broken non-humans in the past.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div class="">The latter, though, seems more risky, and I'm not sure there's much value to that change. Possibly it should be put back.<br class=""></div><div class=""><br class=""></div></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 19, 2019 at 7:53 AM JF Bastien <<a href="mailto:jfbastien@apple.com" target="_blank" class="">jfbastien@apple.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Jul 19, 2019, at 1:50 PM, JF Bastien via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="gmail-m_-4286581131322355373gmail-m_-6546144872589228683gmail-m_729309539028946889Apple-interchange-newline"><div class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jul 17, 2019, at 2:13 PM, James Y Knight via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="gmail-m_-4286581131322355373gmail-m_-6546144872589228683gmail-m_729309539028946889Apple-interchange-newline"><div class=""><div dir="ltr" class="">The reason has always been that changing it would undoubtedly break some software which uses features of newer GCCs that aren't implemented in Clang. And there are indeed some of those features, even if they are weird edge cases.</div></div></blockquote><div class=""><br class=""></div><div class="">What you’re saying leads me to believe that <a href="https://reviews.llvm.org/rL365962" target="_blank" class="">https://reviews.llvm.org/rL365962</a> shouldn’t have been committed. Unless we now decide it’s OK to break code which check GCC quirks?</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">To be clear, it was reverted, but we don’t really seem to have a standing policy. It was more “Python broke” that caused a revert.</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">Also, by this point, Clang is a widely-enough used compiler, that I'd expect most maintained software to be attempting to support it explicitly -- best via __has_builtin/__has_feature/__has_attribute/etc tests as applicable, falling back to the GCC version check if those macros don't exist.</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 17, 2019 at 7:22 AM Simon Atanasyan via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br class="">

<br class="">

Recently I get a request to implement in Clang a MIPS-related feature<br class="">

which exists in GCC pre 4.4 and removed in later versions. There is a<br class="">

rationale behind such strange request -- third-party software checks a<br class="">

compiler's compatibility using __GNUC__,__GNUC_MINOR__ macros and<br class="">

selects code dedicated for obsoleted version of GCC.<br class="">

<br class="">

As to me I would use for __GNUC__,__GNUC_MINOR__,__GNUC_PATCHLEVEL__<br class="">

macros defined in the InitializePredefinedMacros function the same<br class="">

values as a minimal GCC version required for building LLVM/Clang [1].<br class="">

Now it's 5.1.0.<br class="">

<br class="">

Is there any rationale to continue declare compatibility with old GCC 4.2.1?<br class="">

<br class="">

[1] <a href="https://llvm.org/docs/GettingStarted.html#software" rel="noreferrer" target="_blank" class="">https://llvm.org/docs/GettingStarted.html#software</a><br class="">

<br class="">

-- <br class="">

Simon Atanasyan<br class="">

_______________________________________________<br class="">

cfe-dev mailing list<br class="">

<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class="">

<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class="">

</blockquote></div>

_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class=""><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class=""></div></blockquote></div><br class=""></div>_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class=""><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class=""></div></blockquote></div><br class=""></div></blockquote></div>

</div></blockquote></div><br class=""></body></html>