Warning: shared mutable data
Recently I read about Value-Oriented Programming ( https://accu.org/journals/overload/31/173/teodorescu/ ) There it is pointed out that sharing mutable data. i. e., code like my_push_back(vec, vec[0]); can lead to subtle errors. Of course GCC cannot change C++ to a language like Val that forbids such code. From my understanding, however, sharing of mutable data can be detected by the compiler on caller side (looking at the prototype of the function - are all shared arguments const or is there some mutable argument?) and it might be possible to add a warning "shared mutable data". How difficult is it to implement such a warning? If we have such a warning, it will be possible to get some information .) How often such code occurs in real programs? .) Is it difficult to fix such code (e.g. by making a copy of the data before passing it to the function) .) Is it possible to find all such possbible errors when the complete program is compiled with this warning enabled? Even if it were not possible to detect all cases, also detecting some cases might prevent some bugs. What do you think about adding a warning "shared mutable data" to GCC? Helmut Zeisel
Aw: Re: Warning: shared mutable data
Von: "Jonathan Wakely"
> What exactly are you suggesting for the semantics of the warning?
Good question. It is difficult to detect all suspiscious cases, but at least
some of the can be defined:
If we have a function prototype
f(...,Ti xi,...Tj xj,...)
and call the function f(... xi, ... xj,...) with some xi, xj with aliasing /
data sharing,
and both Ti and Tj are references/pointers and at least one is a non-const
pointer / reference,
then the warning should be given.
E.g. for both int:
Ti int: no warning
Ti int& or int*: warning if Tj is int*, const int*, int&, or const int&; no
warning for Tj int.
Ti const int& or const int*: warning if Tj is int*, or int&; no warning if Tj
is const int*, const int&, or int.
Or maybe some code example:
void increase_x_by_y_and_z(int& x, const int& y, const int& z)
{
x+=y;
x+=z;
}
This should be OK (no sharing, no warning):
x=1;
y=1;
z=1;
increase_x_by_y_and_z(x,y,z);
This should give a warning (sharing of int& and const int&):
x=1;
y=1;
increase_x_by_y_and_z(x,y,x);
On the other hand, this is OK (y is shared but not mutable - two times const
int&):
x=1;
y=1;
increase_x_by_y_and_z(x,y,y);
Helmut
GCC 13.1 compile error when using CXXFLAGS=-std=c++20
I compiled GCC 13.1.0 with GCC 12 and had the environment variable CXXFLAGS set to -std=c++20 This gives the error (both linux and cygin) gcc-13.1.0/libstdc++-v3/src/c++98/bitmap_allocator.cc:51:23: error: ISO C++17 does not allow dynamic exception specifications 51 | _M_get(size_t __sz) throw(std::bad_alloc) After unset CXXFLAGS compilation works Helmut
Aw: Re: GCC 13.1 compile error when using CXXFLAGS=-std=c++20
>Von: "Jakub Jelinek" >An: "Helmut Zeisel" >Cc: gcc@gcc.gnu.org >Betreff: Re: GCC 13.1 compile error when using CXXFLAGS=-std=c++20 >On Thu, Apr 27, 2023 at 11:09:19AM +0200, Helmut Zeisel via Gcc wrote: >> I compiled GCC 13.1.0 with GCC 12 and had the environment variable CXXFLAGS >> set to -std=c++20 >> This gives the error (both linux and cygin) >> >> gcc-13.1.0/libstdc++-v3/src/c++98/bitmap_allocator.cc:51:23: error: ISO >> C++17 does not allow dynamic exception specifications >> 51 | _M_get(size_t __sz) throw(std::bad_alloc) >> >> After >> >> unset CXXFLAGS >> >> compilation works >Don't do it. Dont do *what*? export CXXFLAGS=... ? unset CXXFLAGS ? Compile GCC 13 with GCC 12? Helmut
When do I need -fnon-call-exceptions?
I wrote some simple program that set a signal handler for SIGFPE, throws a C++ exception in the signal handler and catches the exception. I compiled with and without -fnon-call-exceptions (on x64 Linux). In both cases, the result was the same: the exception was caught and the destructors were called as expected. I also tried "-fno-non-call-exceptions -fexceptions" and got the same result. My question: when do I really need -fnon-call-exceptions? Is there some simple program where I can see the difference whether it is on or off?? Helmut
What should be the type of 9223372036854775808L ? unsigned long or signed __int128?
GCC13, c++, cygwin 64:
auto x = 9223372036854775808L
gives the warning: "integer constant is so large that it is unsigned"
But actually the type is signed __int128:
std::cout << x;
gives the error: "ambiguous overload for ‘operator<<’ (operand types are
‘std::ostream’ {aka ‘std::basic_ostream’} and ‘__int128’"
and
std::cout << (x-x-1<0) << std::endl;
prints 1.
So what is the correct type of 9223372036854775808L ?
unsigned long, as the warning says, or signed __int128?
Helmut
