[Bug c++/8211] -Weffc++ warns about copyable classes with func ptr members
--- Additional Comments From olly at survex dot com 2005-09-15 21:38 --- Confirmed fixed in: g++-4.0 (GCC) 4.0.0 20050301 (prerelease) (Debian 4.0-0pre6ubuntu7) -- What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8211
[Bug c/55299] New: missed optimization: ASR idiom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55299
Bug #: 55299
Summary: missed optimization: ASR idiom
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: o...@survex.com
This is similar to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54579 but for a
different (and perhaps clearer) idiom for arithmetic shift right. I've filed
this as a separate PR rather than adding it as a comment, but if it's actually
the same issue underneath, please merge or mark as a duplicate.
int asr(int a, int b)
{
return a < 0 ? ~((~a) >> b) : a >> b;
}
olly@gcc12:~$ /opt/cfarm/gcc-latest/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/opt/cfarm/gcc-latest/bin/gcc
COLLECT_LTO_WRAPPER=/home/iulius/autobuild/bin/gcc-4.7.1/libexec/gcc/x86_64-unknown-linux-gnu/4.7.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.7.1-src/configure
--prefix=/home/iulius/autobuild/bin/gcc-4.7.1
--with-gmp=/home/iulius/autobuild/bin/gmp-5.0.5
--with-mpfr=/home/iulius/autobuild/bin/mpfr-3.1.0
--with-mpc=/home/iulius/autobuild/bin/mpc-0.9 --disable-nls
--enable-threads=posix --disable-multilib --enable-languages=c,c++
Thread model: posix
gcc version 4.7.1 (GCC)
Compiling with:
LD_LIBRARY_PATH=/opt/cfarm/mpc-latest/lib:/opt/cfarm/mpfr-latest/lib:/opt/cfarm/gmp-latest/lib
/opt/cfarm/gcc-latest/bin/gcc -O2 -S asr.c -o asr.S
Gives this for the function asr:
asr:
.LFB0:
movl%edi, %eax
movl%esi, %ecx
sarl%cl, %eax
testl%edi, %edi
js.L5
rep
ret
.p2align 4,,10
.p2align 3
.L5:
movl%edi, %eax
notl%eax
sarl%cl, %eax
notl%eax
ret
Ideally the conditional would be optimised down to just the sarl instruction.
I've checked the older compiler versions on gcc12 (back to 4.1.1) and they all
leave the branch in. So if this is a regression, it isn't at all recent.
[Bug c/55299] missed optimization: ASR idiom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55299 --- Comment #2 from olly at survex dot com 2012-11-13 20:40:06 UTC --- Interestingly clang (at least 3.0-6 from Debian testing) fails to optimise the same testcase but shifting by a constant. For that variant case clang generates essentially the same code as GCC currently does.
[Bug preprocessor/12258] -Wold-style-cast triggers on casts in macros from system headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12258 olly at survex dot com changed: What|Removed |Added CC||olly at survex dot com --- Comment #4 from olly at survex dot com --- It looks like this was fixed in GCC 4.8 where -ftrack-macro-expansion=2 was made the default. With 4.7 the warning goes away if I explicitly pass -ftrack-macro-expansion=2, while with 4.8 it comes back if I override this new default with -ftrack-macro-expansion=0.
[Bug libstdc++/42261] New: infinite recursion from string(string::size_type(6), string::size_type('f'))
Attempting to construct a string from two size_type parameters causes infinite
recursion. Test code, badstring.cc:
#include
using namespace std;
int main() {
string s(string::size_type(6), string::size_type('f'));
}
Compiled with:
g++ -O2 -o badstring badstring.cc
Loops infinitely when called. If compiled with -O0, segfaults when it runs out
of stack.
Analysis:
It appears that this ctor is used (with _InputIterator being string::size_type)
template
template
basic_string<_CharT, _Traits, _Alloc>::
basic_string(_InputIterator __beg, _InputIterator __end, const _Alloc& __a)
: _M_dataplus(_S_construct(__beg, __end, __a), __a)
{ }
This leads to an infinite recursion between these two methods:
// _GLIBCXX_RESOLVE_LIB_DEFECTS
// 438. Ambiguity in the "do the right thing" clause
template
static _CharT*
_S_construct_aux(_Integer __beg, _Integer __end,
const _Alloc& __a, __true_type)
{ return _S_construct(static_cast(__beg), __end, __a); }
template
static _CharT*
_S_construct(_InIterator __beg, _InIterator __end, const _Alloc& __a)
{
typedef typename std::__is_integer<_InIterator>::__type _Integral;
return _S_construct_aux(__beg, __end, __a, _Integral());
}
The infinite recursion also happens with GCC 4.3.2. GCC 4.1.3 constructs a
string containing "ff".
I'm not familiar enough with the standard to know whether GCC 4.1.3 is correct,
or whether 4.3.2 and 4.4.1 are (or whether neither behaviour is right), but
generating an infinite loop for seemingly innocent looking code seems
unhelpful.
FWIW, the Comeau online compiler accepts the code, but I can't tell how it
interprets it.
--
Summary: infinite recursion from string(string::size_type(6),
string::size_type('f'))
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: olly at survex dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42261
[Bug c++/34772] New: -Winit-self ignored when compiling C++ (and ObjC++)
The info manual says:
`-Winit-self (C, C++, Objective-C and Objective-C++ only)'
Warn about uninitialized variables which are initialized with
themselves. Note this option can only be used with the
`-Wuninitialized' option, which in turn only works with `-O1' and
above.
For example, GCC will warn about `i' being uninitialized in the
following snippet only when `-Winit-self' has been specified:
int f()
{
int i = i;
return i;
}
However, trying that exact example, I get:
$ g++-4.2 -O -Wuninitialized -c warnings.cc
warnings.cc: In function int f():
warnings.cc:3: warning: i is used uninitialised in this function
$ g++-4.2 -O -Wuninitialized -Wno-init-self -c warnings.cc
warnings.cc: In function int f():
warnings.cc:3: warning: i is used uninitialised in this function
Compiling the same code as C:
$ gcc-4.2 -x c -O -Wuninitialized -c warnings.cc
$ gcc-4.2 -x c -O -Wuninitialized -Winit-self -c warnings.cc
warnings.cc: In function f:
warnings.cc:3: warning: i is used uninitialised in this function
$
So it appears that g++ simply ignores the -Winit-self setting and always warns
about such code, contrary to what the documentation states (and gcc works as
documented). ObjC seems to handle this as C does (as documented). ObjC++
seems to handle it as C++ does (contrary to documentation).
This could be viewed as a documentation bug, though it seems more useful for
this to work for C++ (and ObjC++) as is currently documented.
It looks like -Winit-self was new in GCC 3.4, and I can the same behaviour for
C++ with g++ 3.4.4, so I don't think this is a regression.
--
Summary: -Winit-self ignored when compiling C++ (and ObjC++)
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: olly at survex dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34772
[Bug c++/34772] -Winit-self ignored when compiling C++ (and ObjC++)
--- Comment #1 from olly at survex dot com 2008-01-13 18:23 --- I've just noticed that Debian have a packaged 4.3 snapshot: g++-4.3 (Debian 4.3-20080104-1) 4.3.0 20080104 (experimental) [trunk revision 131316] Testing with this shows the same behaviour for C++. -- olly at survex dot com changed: What|Removed |Added Known to fail||3.4.4 4.2.1 4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34772
[Bug c++/34772] -Winit-self ignored when compiling C++ (and ObjC++)
--- Comment #3 from olly at survex dot com 2008-01-14 00:58 --- If by "delete this option from the C++ FE" you mean that `g++ -Winit-self [...]' would give an error, I'm not sure that's the best approach if the option is likely to be sorted out for C++ in the future. Removing it now will break existing makefiles which use -Winit-self for C++ compilations. And once -Winit-self is sorted out for C++, it will be harder to write a makefile which gives a warning for self-initialised variables for any GCC version (if it's left as-is for now, then -Winit-self can just be specified all the time for any GCC version >= 3.4). The situation here is slightly odd in that -Winit-self is effectively always on for C++, so in a way it does work - it's not specifying it (or -Wno-init-self) which doesn't! I think it would be better to fix the documentation to reflect the current behaviour for C++/ObjC++, and mark this bug as an enhancement request. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34772
[Bug c++/120585] New: "error: ‘signed’ specified with ‘typeof’" in code with no typeof
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120585 Bug ID: 120585 Summary: "error: ‘signed’ specified with ‘typeof’" in code with no typeof Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: olly at survex dot com Target Milestone: --- $ echo 'typedef signed wchar_t x;' | g++-15 -c -xc++ - :1:9: error: ‘signed’ specified with ‘typeof’ However there's no `typeof` in the code. Perhaps there's a `typeof` involved somehow behind the scenes, but from a user viewpoint I'd expect the error to be something like: :1:9: error: ‘signed’ specified with ‘wchar_t’ Reproducible with with the debian g++15 package version 15-20250319-1: g++-15 (Debian 15-20250319-1) 15.0.1 20250319 (experimental) [master r15-8284-gd0110185eb7] Also reproducible on godbolt.org: g++ (Compiler-Explorer-Build-gcc-e1719c3c20bee7caac0f6cc1a6e2deda9820e030-binutils-2.42) 16.0.0 20250607 (experimental) AIUI this code isn't valid ISO C++ but older GCC (e.g. 8.4.0) and clang (e.g. 8.0.1) both accepted it so instances likely exist in the wild.
