<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class=""><div></div></span>How is it not a viable fight?  Is the section attribute coming from a completely different place?  Or are you suggesting that it is never viable to tell people that they ought to fix their code, no matter how unnecessarily perverse it is?  A section should be an intrinsic part of an definition, saying that you can’t define the same thing in multiple inconsistent ways is not even slightly unreasonable.</div></div></blockquote><div><br></div><div>The bug first got reported to us while trying to build glibc. The bug Richard noticed was fixed in gcc because it was breaking the linux kernel. If anyone thinks it is productive to try to get them to change, go for it.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>“Build everything GCC can without modification” has never been a fundamental requirement for clang, though, and that appears to be your standard.</div><div><br></div><div>PR16187 is an example that I would feel fairly comfortable diagnosing.  You could certainly construct a more challenging example, though.</div><div><span class=""><br></span></div></div></blockquote><div><br></div><div>It is an example where we *were* diagnosing. Except that then we cannot build firefox or chrome. You are also more than welcome to get them to change because you don't like how gcc implemented an extension.</div><div><br></div><div>It is not about being bug by bug compatible, it is about building *real* software versus having a slower (compute visibility multiple times per type) and fuzzier model for no reason other than not liking reality.</div><div><br></div><div>This is not the same case as, for example, requiring "this->" in dependent contexts, where our model was better (and eventually gcc switched). </div><div><br></div><div>>You’ll need to remind me what it is that we can’t implement here.</div><div><br></div><div>test/SemaCXX/anonymous-struct.cpp</div><div><br></div><div>Cheers,</div><div>Rafael</div><div><br></div></div></div></div>