[Bug c++/109740] -Woverloaded-virtual is too aggressive

2023-11-02 Thread emerg.reanimator at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109740

--- Comment #5 from Alexander Goomenuk  ---
Created attachment 56495
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56495&action=edit
Overloaded virtual testcase

Another relevant issue with gcc (GCC) 13.2.1 20231011 (Red Hat 13.2.1-4) and
-Woverloaded-virtual.

Overloading method f() in Derived class affects the warning that is caused by
assignment operator! 

Woverloaded-virtual-test.cpp:6:28: warning: ‘virtual const Parent&
Parent::operator=(int&)’ was hidden [-Woverloaded-virtual=]
6 | virtual const Parent & operator=(int &x)
  |^~~~
Woverloaded-virtual-test.cpp:15:8: note:   by ‘constexpr Derived&
Derived::operator=(const Derived&)’
   15 | struct Derived : public Parent
  |^~~

[Bug c++/109740] -Woverloaded-virtual is too aggressive

2023-11-01 Thread emerg.reanimator at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109740

--- Comment #4 from Alexander Goomenuk  ---
https://en.cppreference.com/w/cpp/language/using_declaration

# In class definition
...
If the derived class already has a member with the same name, parameter list,
and qualifications, *the derived class member hides or overrides (doesn't
conflict with) the member that is introduced from the base class*.



https://gcc.gnu.org/onlinedocs/gcc-13.1.0/gcc/C_002b_002b-Dialect-Options.html#index-Woverloaded-virtual

In cases where the different signatures are not an accident, the simplest
solution is to add a *using-declaration to the derived class to un-hide the
base function*, e.g. add using A::f; to B. 



These two statements contradict each other, isn't it?

[Bug c++/109740] -Woverloaded-virtual is too aggressive

2023-11-01 Thread emerg.reanimator at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109740

Alexander Goomenuk  changed:

   What|Removed |Added

 CC||emerg.reanimator at gmail dot 
com

--- Comment #3 from Alexander Goomenuk  ---
Let consider the following case:
- There is a base class that implement virtual assignment operator with
arbitrary input argument (not copy operator).
- There is a derived class that inherits the assignment operator from base
class.

g++ version >= 13 produces the warning in this case because implicitly-defined
copy operator of derived class pretends to hide the user defined assignment
operator of base class. The code is totally fine and the assignment operator
works as expected. 

Even worse, the warning is produced by compiler even if no implicitly-defined
copy operator is NOT generated by the compiler and the code fails to build due
to the lack of copy operator. So the warning is misleading and incorrect in
this case.

See
https://stackoverflow.com/questions/77378553/woverloaded-virtual-with-default-shallow-copy-operator
for more details.

[Bug rtl-optimization/90255] [9/10/11 regression] r266385 caused code size regressions on Arm, thumb and thumb2

2021-01-04 Thread emerg.reanimator at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90255

Alexander Goomenuk  changed:

   What|Removed |Added

 CC||emerg.reanimator at gmail dot 
com

--- Comment #7 from Alexander Goomenuk  ---
Created attachment 49872
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49872&action=edit
GCC Version Benchmarks

Here is some GCC benchmarks of real-life scenarios.

There are three applications (A,B,C) built for cortex-m3 ARM architecture using
several GCC versions with two optimisation sets (Debug (D) and Release (R)).

One may find the details in attached file [GCC_Benchmarks.txt];

Here is an summary of Application C build artifacts.

*
 Application C, text size, --specs=nano.specs
*
   MCU 9.2.1.1  MCU 9.3.1.4 MCU 10.2.1-1.1  ARM 9.3.1   ARM 10.2.1
D: 316864   321000  321316  317288  317476
   041364452424 612
   0,00 %   1,29 %  1,39 %  0,13 %  0,19 %

R: 292748   296884  295968  293172  292128
   620  4756384010440
   0,21 %   1,60 %  1,30 %  0,36 %  0,00 %