[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const

[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fizzbooze at gmail dot com

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 64720 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I don't think I agree with closing this as won't fix as shown now we have three
duplicated bugs asking the same thing.

[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487

David Malcolm <dmalcolm at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
                 CC|                            |dmalcolm at gcc dot gnu.org
         Resolution|WONTFIX                     |---
     Ever confirmed|1                           |0

--- Comment #9 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #8)
> I don't think I agree with closing this as won't fix as shown now we have
> three duplicated bugs asking the same thing.

I agree; reopening.

It may not be possible to implement a perfect test for this, but it seems to me
that it's possible to implement a warning that catches a subset of cases
without false positives (at the cost of having false negatives).

As a first iteration of an implementation:

  for all fns labelled as pure/const:
    for all basic blocks that are guaranteed to be in a
         path through the function:
      for all stmts in BB:
        if stmt is non-pure/non-const:
          issue a warning

(yes, this would miss some things e.g.
   if (COND)
     non-pure
   else
     non-pure
but could be cheap and effective)

[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487

--- Comment #10 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
fizzbooze: you were asking on IRC about where the existing implementation is;
see gcc/ipa-pure-const.c - though I believe that merely covers tracking the
user-provided flags interprocedurally; I don't think it covers walking
individual stmts and detecting side-effects.

[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
It would have to be a warning, and would necessarily not catch many things,
e.g. if you use inline asm, it is hard to find out if it is non-pure, as has
been mentioned earlier, dead code or possible dead code should not be warned
about, and if you call other functions, even if they aren't declared pure, it
might be that they don't write anything with the given arguments or arranged
through other means.

[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
And then there is the case of endless loops in such functions (either
unconditional, or ones the compiler is not able to detect), exit calls, both
either directly in the const/pure function or in some function it calls.  So in
all, I'm afraid such a warning would diagnose only the most trivial cases.

[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |msebor at gcc dot gnu.org

--- Comment #20 from Martin Sebor <msebor at gcc dot gnu.org> ---
Working on a solution.

[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const

[federico.kircheis at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487

Federico Kircheis <federico.kircheis at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |federico.kircheis at gmail dot com

--- Comment #21 from Federico Kircheis <federico.kircheis at gmail dot com> ---
FWIW I was going to open a similar ticket that there are no diagnostic for
[[gnu::const]] and [[gnu::pure]] used incorrectly, so I would like to add my
opinion.

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::pure]] 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 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.

[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zhongyunde at huawei dot com

--- Comment #22 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 101119 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WONTFIX
             Status|ASSIGNED                    |RESOLVED

--- Comment #23 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
In https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101119#c1 it was decided this
was not to be fixed.

[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |ASSIGNED
         Resolution|WONTFIX                     |---

--- Comment #24 from Martin Sebor <msebor at gcc dot gnu.org> ---
Andrew, please don't close bugs that others are working on (i.e., in an
ASSIGNED state with an active Assignee).  Thanks!

[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const

[dberlin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487

--- Comment #25 from Daniel Berlin <dberlin at gcc dot gnu.org> ---
This seems like a bad idea, and is impossible in general.

The whole point of the attributes is to tell the compiler things are pure/const
in cases it can't already prove.

It can already prove a lot, and doesn't need help in most of the simple
examples being given (in other bugs). 

You are basically going to warn in the cases the compiler can't prove it (IE
sees something it thinks makes the function not pure/const), and those are
*exactly* the cases the attribute exists for - where the compiler doesn't know,
but you do.

[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const

[federico.kircheis at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487

--- Comment #26 from Federico Kircheis <federico.kircheis at gmail dot com> ---
As multiple people commented this Ticket, I do not know to who the least
message is sent, but I would like to give again my opinion on it, as I would
really like to use those attributes in non-toy projects.

> This seems like a bad idea

I think there are valid use-cases for those warnings.


> and is impossible in general

Let me quote myself:

> ... 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.

There are now two possible outcomes if a compiler emits a warning.

1)
I look at the definition, and *gasp*, the compiler is actually right.
The function was pure before, but the last changes made it impure.
Either I did not realize it, or I forgot to change the function declaration.
Thank you GCC for making me aware of the issue, I'll fix it.

2) 
I look at the definition an think that GCC is wrong.
I know better, and the function is pure.
I can either try to simplify the function in such a way that GCC does not
complain anymore (which might be a good idea), or I can use a pragma to ignore
this one warning (and comment why it's ignored), or remove the attribute
altogether, as GCC might call the function multiple times if it thinks it's
impure (see example at the end).
In the first approach, I can still benefit from warnings if the function
changes again.
In the second case I cant but at least, I can still grep in the entire codebase
and check periodically which warnings have been disabled locally, just like I
do for other warnings.
In the third case yes, I would probably report a bug with a minimal example.
This (hopefully), would improve GCC analysis capabilities.


> The whole point of the attributes is to tell the compiler things are pure/const in cases it can't already prove.

That does not mean that it is not useful to let it do the check, *especially if
it can prove that the attribute is used incorrectly*, but even if it can't
prove anything.
And also see the example at the end why this is not completely true.

> It can already prove a lot, and doesn't need help in most of the simple examples being given (in other bugs). 


But programmers (at least for the most use-cases I've seen) needs that type of
support.
I would like to know if a function has side effects.
It's great if the compiler can see it automatically, but when reading and
writing code, especially code not written by me or maintained by multiple
authors, we might want to restrict the functionality of some functions.

For side-effect free functions, the attributes const and pure are great, but
using them is more harmful, because if used wrongly it introduces UB, thus

1) they do not really document if a function is pure, as there is no tooling
checking if the statement is true
2) they introduce bugs that no-one can explain (see at the end).

Thus a comment "this function is pure", is by contrast much better, as it does
not introduce UB, but we all know that those kind of commends do not age well.
Thus at the end, they get ignored because not trustworthy, and one need always
to look at the implementation.

> You are basically going to warn in the cases the compiler can't prove it [...]

And for many use-cases it is fine.




Also the second example I gave:

----
// bar.hpp
[[gnu::const]] int get_value();

// bar.cpp
int get_value(){static int i = 0; return ++i;}


// foo.cpp
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).

Thus, if the function is marked pure, the compiler

* will not call it a second time if it does not see the implementation of
`get_value`
* will call it a second time if it sees the implementation of `get_value` and
notices it is not pure.

This is one of those bugs that no-one can explain, as simply moving code
(making a function, for example, inline, or move it to another file), or
changing optimization level, changes the behavior of the program.


Thus, given main.cpp

----
[[gnu::const]] int foo();

// foo.cpp
int main(){
    int i = foo();
    int j = foo();
    return i+j;
}
----


how many times is GCC going to call foo?

If GCC thinks that the function is pure, then only once.
If it thinks it is not pure, twice.

I have no idea what GCC thinks, because there are no diagnostics for it!
And look, it does not even matter if foo is pure or not, it matters if GCC
thinks if it is pure or not. 

I can similarly tell GCC to inline functions, but if GCC doesn't at least it
will tell me he didn't.(warning: 'always_inline' function might not be
inlinable [-Wattributes])



We can of course say "those attributes are only for those people that really
know better", but as the compiler is already checking if a function is pure or
not (as described, if it sees the implementation it does not elide the second
call), some information is already available.
I fail to see how not making this information visible to the end user who is
doing an error, and making thus those attributes available for more
programmers, is a bad thing.

I'm unable to judge how difficult it is (I suppose a lot as the bug report is
of 2004), and this might be the reason GCC will never be able to output the
information, but please do not dismiss it because "it works as designed", as me
(and suppose other reporters) believe it could be more useful than it currently
is, without invalidating it's original use-case.

[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const

[federico.kircheis at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487

--- Comment #27 from Federico Kircheis <federico.kircheis at gmail dot com> ---
Edit: sorry, my last comment about what GCC thinks is wrong.

GCC seems to follow the gnu::pure/gnu::const directive to the letter, it does
not ignore it when it sees the implementation of the function, thus my comment
about information are already available can be ignored.

[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const

[federico.kircheis at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487

--- Comment #28 from Federico Kircheis <federico.kircheis at gmail dot com> ---
>Edit: sorry, my last comment about what GCC thinks is wrong.

Unless it is going to inline the function call, in that case the attributes are
as-if ignored (at least the case I've tested with GCC 11.2).

[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const

[dberlin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487

--- Comment #29 from Daniel Berlin <dberlin at gcc dot gnu.org> ---
Let me try to explain a different way:
The only functions GCC can warn about are those that don’t need the
attributes in the first place. The way any warning would work is to detect
whether it is pure/const, and then see how the user marked it. So anything
it can properly detect as right or wrong didn’t need an attribute to begin
with - the compiler could already tell if it was pure/const

Rather than tell the user they got it wrong, you might as well tell the
user to remove the attribute because it isn’t necessary and won’t be
necessary.

This is precisely why attributes are meant for when you are sure you know
more than the compiler can tell, and *no other time *. It is a tool for
experts.
Giving a bunch of really contrived examples where users may update things
wrong doesn’t seem like a good motivation to make a warning that can only
possibly have a really high false positive rate.
The same logic applies to a lot of expert-use-only attributes.  It is
assumed you know what you are doing, because the compiler can’t tell you
you are wrong accurately




On Sat, Sep 4, 2021 at 4:40 PM federico.kircheis at gmail dot com <
gcc-bugzilla@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487
>
> --- Comment #28 from Federico Kircheis <federico.kircheis at gmail dot
> com> ---
> >Edit: sorry, my last comment about what GCC thinks is wrong.
>
> Unless it is going to inline the function call, in that case the
> attributes are
> as-if ignored (at least the case I've tested with GCC 11.2).
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const

[federico.kircheis at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487

--- Comment #30 from Federico Kircheis <federico.kircheis at gmail dot com> ---
It seems to me we are not going to agree as we tend to repeat ourselves, lets
see if we go around and around in circles or if it is more like a spiral ;)



Your view is more about the compiler, how it is interpreting the attributes and
thus why it is unneeded, mine is more about the developers writing (but most
importantly) reading it.


> The only functions GCC can warn about are those that don’t need the
attributes in the first place. The way any warning would work is to detect
whether it is pure/const, and then see how the user marked it. So anything
it can properly detect as right or wrong didn’t need an attribute to begin
with - the compiler could already tell if it was pure/const


My knowledge about how GCC (or other compilers) works, is very limited, but If
the function is implemented in another
  * translation unit
  * library
  * pre-compiled library
  * pre-compiled library created by another compiler
does GCC know it can avoid calling it multiple times?


Whole-program-optimization might help in some of those cases (I admit I have no
idea; can the linker remove multiple function calls and replace them with a
variable?), but depending on the project size it might add up a lot in term of
compile-times.
So even for simple functions, where GCC can clearly determine its purity, it
can be useful adding the attribute.


And even assuming that whole-program-optimization helps in most of those cases
(which do not depend on the complexity or length of a function) how does
someone know if adding those attributes to a function that is pure makes sense
or not?

Adding pure to `inline int answer_of_life(){return 42;}` might not make any
difference (both for programmers and compiler, because of it's simplicity and
because inline), but where should the line be drawn?

Should I mark my functions (with something else as you are suggesting too it
might do more harm than good), add for all those dummy tests, and check in the
generated assembly if GCC recognizes them as pure and elides the second call?
There must be surely be a better way, but I currently know no other.


> Rather than tell the user they got it wrong, you might as well tell the
user to remove the attribute because it isn’t necessary and won’t be
necessary.

No, removing it as unnecessary would be wrong.
Then you cannot tell anymore the difference between functions that are pure by
accident and by design.
And you cannot prevent anymore a pure-function to getting nonpure, except by
reading the code.
It is useful for programmers (yes, even they look at the code), even for those
function where GCC does not need the attribute.

> Giving a bunch of really contrived examples where users may update things
wrong doesn’t seem like a good motivation to make a warning that can only
possibly have a really high false positive rate.

Just adding a "printf" statement for debugging, or increasing/decreasing a
global counter invalidates the pure attributes.
Thus by trying to understand/analyze a bug, another is added.


> It is a tool for experts.

And I see no harm in making it more developer-friendly.
Why would that be a bad idea? As you claimed previously.

Because it is difficult to implement?
I do not know if it is, but that would not make it a bad idea.

Because of false positives?
Developers can handle them, case-by-case by documenting and disabling (or
ignoring) the diagnostic, or globally by not turning the diagnostic on.
Just like any other diagnostic.

Because it adds nothing from a compiler perspective?
I'm still not convinced that it has no added value, especially when interacting
with "extern" code/libraries.

But it definitively has some value for developers.
It's part of the API of a function, just like declaring the member function of
a class const (or the parameter of a function).
Adding const might even avoid some optimization, and leads to code-duplication
when one needs overloads (like for operator[] in container-like classes), but
from a developer perspective it's great. It helps to catch errors.
Of course one could never use it, for the compiler it would be the same.
And it would not invalidate it's original use-case, thus it would still be
possible to use those attributes like today if someone wants to, they would not
even need to change a thing.

[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |NEW
           Assignee|msebor at gcc dot gnu.org          |unassigned at gcc dot gnu.org

--- Comment #31 from Martin Sebor <msebor at gcc dot gnu.org> ---
I'm not working on this anymore.

[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xry111 at gcc dot gnu.org

--- Comment #32 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 109792 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2007-08-11 17:54 -------
*** Bug 33048 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ed at catmur dot co dot uk


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487

[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const

[gnu at behdad dot org]

------- Comment #5 from gnu at behdad dot org  2007-08-13 05:40 -------
(In reply to comment #2)

> If the compiler could tell whether you were right or not in all cases, you
> wouldn't need the attributes in the first place.

This is not completely true though: the compiler cannot tell by just seeing the
prototype.  So, even if the compiler could recognize all pure and const
functions when compiling them, that doesn't help when you need to mark the
prototypes of those functions as pure/const to help the compiler compiling
other programs using them.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487

[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const

[pinskia at gcc dot gnu dot org]

------- Comment #6 from pinskia at gcc dot gnu dot org  2008-08-08 21:01 -------
*** Bug 37064 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sebor at roguewave dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487

[Bug tree-optimization/18487] New: Warnings for pure and const functions that are not actually pure or const

[kazu at cs dot umass dot edu]

It would be nice if GCC can issue warnings for pure or const functions
that are not actually pure or const.

int foo (int) __attribute__ ((pure));
int bar (int) __attribute__ ((const));

int g;

int
foo (int a)
{
  g = a; /* A pure function is not supposed to write to memory.  */
  return 0;
}

int
bar (int a)
{
  return g; /* A const function is not supposed to read memory.  */
}

-- 
           Summary: Warnings for pure and const functions that are not
                    actually pure or const
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P2
         Component: tree-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: kazu at cs dot umass dot edu
                CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487

[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-14 21:57 -------
Confirmed.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
           Keywords|                            |diagnostic
   Last reconfirmed|0000-00-00 00:00:00         |2004-11-14 21:57:50
               date|                            |
            Version|unknown                     |4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487

[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const

[dberlin at gcc dot gnu dot org]

------- Additional Comments From dberlin at gcc dot gnu dot org  2004-11-16 22:43 -------
Actually, I think this is a remarkably bad idea, and would like to close this as
wontfix.

Pure and const are things that are not easily verifiable by the compiler in a
lot of common cases (it may get false negatives), and it's something the user is
affirmatively asserting.

In short, you shouldn't be saying it's pure or const if it's not pure or const.
If the compiler could tell whether you were right or not in all cases, you
wouldn't need the attributes in the first place.

False negatives appear commonly because left to it's own devices, no external
function could be marked pure or const by the compiler (because it has no idea
about what they do), and any function that called external functions could get
false negatives (because if the compiler couldn't rely on your assertions about
const or pure, these functions would also necessarily be not const or pure).
If the compiler is allowed to rely on your assertions when trying to verify it
for purposes of this warning, then the warning would miss cases where you got it
wrong anyway, because it would rely on your wrong assertion :P.

So basically, this is not something we can verify in anything but the most
trivial cases, we almost always end up relying on what the user tells us.   And
if the user is marking trivial functions const or pure when they clearly aren't,
they deserve what they get :).







-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487

[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const

[kazu at cs dot umass dot edu]

------- Additional Comments From kazu at cs dot umass dot edu  2004-11-17 00:09 -------
This is hard.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |WONTFIX


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18487