<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - no diagnostic for gnu::pure and gnu::const functions"
href="https://bugs.llvm.org/show_bug.cgi?id=48766">48766</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>no diagnostic for gnu::pure and gnu::const functions
</td>
</tr>
<tr>
<th>Product</th>
<td>clang
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>enhancement
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>C++
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedclangbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>federico.kircheis@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>blitzrakete@gmail.com, dgregor@apple.com, erik.pilkington@gmail.com, llvm-bugs@lists.llvm.org, richard-llvm@metafoo.co.uk
</td>
</tr></table>
<p>
<div>
<pre>clang supports the [[gnu::const]] and [[gnu::pure]] attributes of GCC, but does
not diagnose any misuses.
I think it would be very valuable when the attribute is used correctly, as it
can help the compiler optimize the code, but more importantly help the reader
reason about it (and verify the correctness of a program).
Currently those attributes are problematic when maintaining code.
If for example a [[gnu::const]] function gets refactored and it's not pure
anymore, then the code might misbehave, as the compiler might optimize
incorrectly, and tracking down the bug is not easy.
For example, suppose we have
----
// bar.hpp
[[gnu::const]] int get_value();
// bar.cpp
int get_value(){ return 42;}
// foo.cpp
#include "bar.hpp"
int foo(){
int i = get_value();
int j = get_value();
return i+j;
}
----
The the compiler can and will optimize the second call of `get_value`.
But if the code changes, and one forgets to change the declaration:
----
// bar.hpp
[[gnu::const]] int get_value();
// bar.cpp
int get_value(){static int i = 0; return ++i;}
// foo.cpp
#include "bar.hpp"
int foo(){
int i = get_value();
int j = get_value();
return i+j;
}
----
The compiler will still optimize the call to get_value, (unless it is able to
see the definition of get_value and see that there are side effects).
I think a warning that even only works for trivial case is much better than
nothing, because at least I know I can safely use the attribute for some
functions as a contract to the caller, and have it checked.
If the compiler has false positives I can at least recheck the offending
functions and evaluate if leaving the attribute, or removing it.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>