<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">If the compiler is doing something that isn't what the source says to do, the compiler should say so. That's the principle behind this patch.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Even though the reason we ignore one attribute is because of a different attribute whose anticipated use-case is a temporary debugging measure, the principle
should still apply. Currently we're inconsistent, because we error if the attributes are on the same declaration but silently ignore one if they're on different declarations. That inconsistency is another Bad Thing.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">After this patch, we'd error on the same declaration and warn on different declarations, which is also inconsistent. I was contemplating downgrading that error
to a warning, so that the behavior is the same all around.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">--paulr<o:p></o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></a></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Sean Silva [mailto:chisophugis@gmail.com]
<br>
<b>Sent:</b> Thursday, December 11, 2014 5:33 PM<br>
<b>To:</b> Robinson, Paul<br>
<b>Cc:</b> cfe-commits@cs.uiuc.edu; Aaron Ballman (aaron.ballman@gmail.com)<br>
<b>Subject:</b> Re: [PATCH] Diagnose 'optnone' versus conflicting attrs on another decl<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Sort of a bigger-picture question: does it make sense to warn about this? I thought that optnone was just for debugging; is there a use case where the user would put optnone on something when debugging and actually care about whether optnone
is overriding something else?<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">-- Sean Silva<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Thu, Dec 11, 2014 at 4:27 PM, Robinson, Paul <<a href="mailto:Paul_Robinson@playstation.sony.com" target="_blank">Paul_Robinson@playstation.sony.com</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">Diagnose when attribute 'optnone' conflicts with attributes on a<br>
different declaration.<br>
<br>
I modeled this on how dllimport/dllexport are handled; specifically,<br>
I made 'optnone' continue to "win" over 'always_inline' and 'minsize'.<br>
This preserves the previous "winner" behavior but adds the diagnostics<br>
that were requested.<br>
<br>
I have two questions about all this.<br>
<br>
First, the diagnostics point to the attribute being ignored, but not<br>
to the attribute that caused it to be ignored. Is that okay? This<br>
would be a problem for dllimport/dllexport as well as the new cases.<br>
<br>
Second, now that there are 5 similar cases (dllimport v. dllexport,<br>
plus optnone v. always_inline/minsize) it seems like there could be<br>
an opportunity to refactor some of that diagnostic checking into a<br>
templated helper function, along the lines of mergeVisibilityAttr.<br>
Should I pursue that? (Not clear it's much of a win... but maybe.)<br>
<br>
Thanks,<br>
--paulr<br>
<br>
<br>
_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><o:p></o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>