[Bug tree-optimization/104603] [10/11/12 Regression] wrong detection of -Warray-bounds for interesting tail resusive case

2022-03-09 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104603

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Priority|P3  |P2

[Bug tree-optimization/104603] [10/11/12 Regression] wrong detection of -Warray-bounds for interesting tail resusive case

2022-03-01 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104603

Martin Sebor  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-03-01
 CC||msebor at gcc dot gnu.org

--- Comment #8 from Martin Sebor  ---
It looks like the problem is that the call to Base::operator==() might enter
infinite recursion.  With the changed test case below GCC issues
-Winfinite-recursion pointing it out.  With the original test case the infinite
recursion isn't inevitable but because it can't be ruled out GCC emits
(invalid) code that then triggers -Warray-bounds.  It might be possible to do
better: detect the possible infinite recursion early and fold the equality to
false.  (As far as I can see, that's what recent Clang seems to do.)

$ cat pr104603.C && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout
pr104603.C
struct Base {
  bool isX_;
  Base(bool isX = false) : isX_(isX) { }
  bool isX() const { return isX_; }
  bool operator==(const Base& rhs) const;
};

struct X : public Base {
  X(const Base& b) : Base(true), b_(b) { }
  bool operator==(const X& rhs) const { return b_ == rhs.b_; }
  Base b_;
};

inline bool Base::operator==(const Base& rhs) const
{
return /* isX() && rhs.isX() && */ static_cast(*this) ==
static_cast(rhs);
}

Base base (true);

int main ()
{
  return X(base) == X(base);
}
pr104603.C: In member function ‘bool X::operator==(const X&) const’:
pr104603.C:10:8: warning: infinite recursion detected [-Winfinite-recursion]
   10 |   bool operator==(const X& rhs) const { return b_ == rhs.b_; }
  |^~~~
In member function ‘bool Base::operator==(const Base&) const’,
inlined from ‘bool X::operator==(const X&) const’ at pr104603.C:10:51:
pr104603.C:16:69: note: recursive call
   16 | rn /* isX() && rhs.isX() && */ static_cast(*this) ==
static_cast(rhs);
  |   
~^


;; Function main (main, funcdef_no=9, decl_uid=2452, cgraph_uid=10,
symbol_order=10) (executed once)

Merging blocks 3 and 4
int main ()
{
   [local count: 10631108]:

   [local count: 1073741824]:
  goto ; [100.00%]

}

[Bug tree-optimization/104603] [10/11/12 Regression] wrong detection of -Warray-bounds for interesting tail resusive case

2022-02-18 Thread herumi at nifty dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104603

--- Comment #7 from herumi  ---
Created attachment 52478
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52478=edit
an original code

The array-bounds.zip file is a little stripped original issue.

array-bounds% g++-11.2 -O2 -c a.cpp -Warray-bounds -save-temps

[Bug tree-optimization/104603] [10/11/12 Regression] wrong detection of -Warray-bounds for interesting tail resusive case

2022-02-18 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104603

--- Comment #6 from Andrew Pinski  ---
(In reply to herumi from comment #5)
> >Can you file a seperate issue with the preprocessed source (-save-temps) 
> >since it really does look like a seperate issue all together.
> 
> May I attach a zipped a.ii which is generated by the following commands?

Zipped is perfect.

[Bug tree-optimization/104603] [10/11/12 Regression] wrong detection of -Warray-bounds for interesting tail resusive case

2022-02-18 Thread herumi at nifty dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104603

--- Comment #5 from herumi  ---

>Can you file a seperate issue with the preprocessed source (-save-temps) since 
>it really does look like a seperate issue all together.

May I attach a zipped a.ii which is generated by the following commands?
The size of a.ii is over 1700KiB.

---
>cat a.cpp
#include 

using namespace Xbyak::util;

void f()
{
  ptr[eax] == ptr[eax];
}
---
---
g++-11.2 -O2 -I ../ -Warray-bounds -c a.cpp -save-temps
---

[Bug tree-optimization/104603] [10/11/12 Regression] wrong detection of -Warray-bounds for interesting tail resusive case

2022-02-18 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104603

--- Comment #4 from Andrew Pinski  ---
(In reply to herumi from comment #3)
> The reason why I made this code is from the issue:
> https://github.com/herumi/xbyak/issues/137

Can you file a seperate issue with the preprocessed source (-save-temps) since
it really does look like a seperate issue all together. If it is not a seperate
issue in the end, at least we recorded the issue with the original source.

[Bug tree-optimization/104603] [10/11/12 Regression] wrong detection of -Warray-bounds for interesting tail resusive case

2022-02-18 Thread herumi at nifty dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104603

--- Comment #3 from herumi  ---
>Also if this is from some larger code,
>it might be useful to have the non-reduced testcase
>since the reduced testcase might being showing something different.

The reason why I made this code is from the issue:
https://github.com/herumi/xbyak/issues/137

[Bug tree-optimization/104603] [10/11/12 Regression] wrong detection of -Warray-bounds for interesting tail resusive case

2022-02-18 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104603

Andrew Pinski  changed:

   What|Removed |Added

Summary|wrong detection of g++  |[10/11/12 Regression] wrong
   |-Warray-bounds about|detection of
   |downcast|-Warray-bounds for
   ||interesting tail resusive
   ||case
  Component|c++ |tree-optimization
   Target Milestone|--- |10.4

--- Comment #2 from Andrew Pinski  ---
Someone else needs to look into this further than me because the warning only
happens because there are cases where the access can happen but the accesses
are not really used.

Also if this is from some larger code, it might be useful to have the
non-reduced testcase since the reduced testcase might being showing something
different.