[llvm-bugs] [Bug 48766] New: no diagnostic for gnu::pure and gnu::const functions

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=48766

            Bug ID: 48766
           Summary: no diagnostic for gnu::pure and gnu::const functions
           Product: clang
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: federico.kircheis at gmail.com
                CC: blitzrakete at gmail.com, dgregor at apple.com,
                    erik.pilkington at gmail.com, llvm-bugs at lists.llvm.org,
                    richard-llvm at metafoo.co.uk

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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210115/958b7f2c/attachment.html>