[Bug libstdc++/11953] _REENTRANT defined when compiling non-threaded code.
--- Comment #38 from carlo at gcc dot gnu dot org 2005-11-29 16:05 --- That never works because it always defines _REENTRANT. You probably mean: #ifdef _REENTRANT #define GCC_BUGFIX 1 #endif #include #undef _REENTRANT #ifdef GCC_BUGFIX #define _REENTRANT 1 #endif The drawback of this "fix" is that it is hardly usable for library writers like you and me. You can add this to every .cpp file of an application, but it doesn't help to determine if the _user_ (of your library) wants thread-safeness or not. Such a user will add -pthread when compiling his application but we cannot detect that anymore. We can also not demand that users of our library add the above kludge at the top of every .cpp file of their application (before any system headers are included) or, equivalently, demand they include the header of our library before any system header. That being said, I obviously agree completely with Marc that this is a bug: _REENTRANT should only be defined by the compiler iff -pthread is passed to the compiler. I know that is not a written standard, but it certainly is widely used and something developers have come to rely on so much that it is pure arrogance to break it. I'd say, ignorance-- but given the fact that I reported this BEFORE it was released (after running into it in a cvs version), and it was released anyway... Nevertheless-- I've seen enough of the gcc development (that is, what is related with C++) to know that 'we' cannot rely on (the) g++ (developers) being interested in keeping backwards compatibility with ANYTHING that isn't set in stone by some ISO committee (refering to some GNU extensions here). Therefore I suggest to everyone reading this: don't rely on common sense. The define of _REENTRANT isn't some standard and therefore you cannot not rely on it (when using g++). Even if it was fixed in 4.1, you can count on it being broken again in 4.2. The only reliable "solution" left is to demand that the users define a macro on the command line. So, expect to see this kind of compilations in the future: g++ -pthread -DBOOST_THREAD_SAFE -DLIBCWD_THREAD_SAFE -DLIBXML2_THREAD_SAFE -DLIBC_THREAD_SAFE -DLIBFOO_THREAD_SAFE -DLIBGTK_THREAD_SAFE [...] application.cc until some guru proposes that all libraries make use of one and the same define: GURU_THREAD_SAFE. Unfortunately... two decades later, once that macro made it's way into AX[3.4]UbuOS-6.8 and some bug needs it to be defined always... g++ will think it's allowed to unconditionally define GURU_THREAD_SAFE too... because it wasn't an official standard [...] Yeah, history repeats itself. Watch and see. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11953
[Bug c++/20350] New: 4.0 and higher: ICE
/usr/local/gcc-cvs-4.1/libexec/gcc/i686-redhat-linux/4.1.0/cc1plus -fpreprocessed threading.ii -quiet -dumpbase threading.cc -mtune=pentiumpro -auxbase-strip .libs/libcwd_r_la-threading.o -g -Wall -Woverloaded-virtual -Wundef -Wpointer-arith -Wwrite-strings -Werror -version -fno-exceptions -fno-exceptions -fPIC -o threading.s GNU C++ version 4.1.0 20050306 (experimental) (i686-redhat-linux) compiled by GNU C version 4.1.0 20050306 (experimental). GGC heuristics: --param ggc-min-expand=90 --param ggc-min-heapsize=113285 ../libcwd/threading.cc:704: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. threading.ii.bz2 is attached. -- Summary: 4.0 and higher: ICE Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: carlo at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-redhat-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20350
[Bug c++/20350] 4.0 and higher: ICE
--- Additional Comments From carlo at gcc dot gnu dot org 2005-03-06 22:33 --- Created an attachment (id=8345) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8345&action=view) bzip2-ed preprocessed source code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20350
[Bug c++/20350] 4.0 and higher: ICE
--- Additional Comments From carlo at gcc dot gnu dot org 2005-03-06 23:20 --- Created an attachment (id=8348) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8348&action=view) Same, but without PCH. Sorry, the previous one was compiled with pch. This one is without PCH. -- What|Removed |Added Attachment #8345 is|0 |1 obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20350
[Bug c++/37773] New: -Wfatal-errors aborts too early
Many errors span multiple lines. However, any of the first lines start with 'error:' (or so it seems) the rest is not printed anymore (with using -Wfatal-errors). For example: hikaru:~/projects/cwchessboard/cwchessboard-objdir>make tstpgn source='PgnDatabase.cc' object='tstpgn-PgnDatabase.o' libtool=no \ DEPDIR=.deps depmode=pch /bin/sh ../cwchessboard/depcomp \ g++ -DHAVE_CONFIG_H -I. -I../cwchessboard-DCWDEBUG -I/usr/local/install/4.3.1/include $(pkg-config --cflags giomm-2.4) -g3 -Winline -Wfatal-errors -DDEBUG -c -o tstpgn-PgnDatabase.o `test -f 'PgnDatabase.cc' || echo '../cwchessboard/'`PgnDatabase.cc ../cwchessboard/MemoryBlockList.h: In member function âvoid cwchess::pgn::DatabaseSeekable::read_async_open_ready(Glib::RefPtr&)â: ../cwchessboard/MemoryBlockList.h:124: error: âchar* util::MemoryBlockNode::block_begin()â is private compilation terminated due to -Wfatal-errors. make: *** [tstpgn-PgnDatabase.o] Error 1 This is little useful. Now I have to recompile without -Wfatal-errors to find: ../cwchessboard/PgnDatabase.cc:52: error: within this context -- Summary: -Wfatal-errors aborts too early Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: carlo at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37773
[Bug c++/37773] -Wfatal-errors aborts too early
--- Comment #1 from carlo at gcc dot gnu dot org 2008-10-08 16:48 --- Here's another one: ../cwchessboard/PgnDatabase.cc:65: error: no matching function for call to âutil::MemoryBlockList::append(gssize&)â ../cwchessboard/MemoryBlockList.h:232: note: candidates are: void util::MemoryBlockList::append(Glib::RefPtr&, size_t) With -Wfatal-errors the second line is not printed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37773
[Bug tree-optimization/37810] New: Bad store sinking job
The following code snippet:
void g();
struct A {
int n;
int m;
A& operator++(void)
{
if (__builtin_expect(n == m, false))
g();
else
++n;
return *this;
}
A() : n(0), m(0) { }
friend bool operator!=(A const& a1, A const& a2) { return a1.n != a2.n; }
};
void testfunction(A& iter)
{
A const end;
while (iter != end)
++iter;
}
Results in the following assembly code, using maximum optimization:
movl(%rdi), %eax
jmp .L6
.L4:
cmpl%eax, 4(%rdi) // n == m ?
je .L8 // unlikely jump
addl$1, %eax // ++n
movl%eax, (%rdi) // *** store result to memory ***
.L6:
testl %eax, %eax// iter != end ?
jne .L4 // continue while loop
The storing (back) of %eax to (%rdi) remains inside the inner
loop no matter what I try. It could/should be moved outside
the loop, since nothing inside the L4 loop is accessing (%rdi)
or could possibly be accessing that memory.
This loop has two exits: below the last jne .L4, and the
jump to .L8. The store could be sinked to both exits.
This grows the code, but it seems reasonable to do for
a loop with a very small body, especially if one of the
exits is marked as unlikely :p.
--
Summary: Bad store sinking job
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carlo at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37810
[Bug tree-optimization/37810] Bad store sinking job
--- Comment #4 from carlo at gcc dot gnu dot org 2008-10-12 15:32 ---
Note that the original code was:
A& operator++(void)
{
++n;
if (__builtin_expect(n == m, false))
g();
return *this;
}
but g++ fails to optimize that by decrementing m outside
the loop (so I'm decrementing m myself now and use the
former code). The former code has as advantage, namely,
that the result of the addl $1,%eax can be used for the
conditional jump. However, gcc ALSO doesn't do that: in
the above assembly it follows the add with a redundant
testl %eax,%eax.
Anyway, using the operator++ given in this comment,
the assembly code is:
movl(%rdi), %eax
jmp .L3
.L4:
addl$1, %eax
cmpl4(%rdi), %eax
movl%eax, (%rdi)
je .L8
.L3:
testl %eax, %eax
jne .L4
which is essentially the same, except now the
testl %eax,%eax is indeed "needed" ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37810
[Bug c++/35405] New: Internal compiler error
~>g++-svn-4.3 troep.cc
troep.cc: In instantiation of âcheckâ:
troep.cc:38: instantiated from here
troep.cc:14: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
All 3.x (that I have installed) and all 4.x versions ice on this.
Content of troep.cc:
typedef char no;
typedef char (&yes)[2];
template class Concept>
struct check
{
template
struct hint;
template
static no test(...);
template class C, typename X, C* = 0>
struct helper
{
typedef yes type;
};
template
static typename helper::type test(U* t);
static bool const value = (sizeof(check::template test(0)) ==
sizeof(yes));
};
template
struct member
{
typedef T type;
};
template
struct Saveable : member
{
};
int main()
{
check::value;
}
--
Summary: Internal compiler error
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carlo at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35405
[Bug c++/36659] New: Confusion error message order 'error: ‘functionname’ declared as an ‘inline’ variable'
The order of the error messages
error: âfunctionnameâ declared as an âinlineâ variable
and
error: âUnDefinedClassâ was not declared in this scope
should be swapped.
See following testcase:
struct A {};
int functionname(A foo);
inline int functionname(UnDefinedClass foo)
{
return 0;
}
which results in the errors:
hikaru:~>g++ -c troep.cc
troep.cc:4: error: âfunctionnameâ declared as an âinlineâ variable
troep.cc:4: error: âint functionnameâ redeclared as different kind of
symbol
troep.cc:2: error: previous declaration of âint functionname(A)â
troep.cc:4: error: âUnDefinedClassâ was not declared in this scope
A much better or would be:
troep.cc:4: error: âUnDefinedClassâ was not declared in this scope
troep.cc:4: error: âfunctionnameâ declared as an âinlineâ variable
troep.cc:4: error: âint functionnameâ redeclared as different kind of
symbol
troep.cc:2: error: previous declaration of âint functionname(A)â
--
Summary: Confusion error message order 'error: âfunctionnameâ
declared as an âinlineâ variable'
Product: gcc
Version: 4.2.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carlo at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36659
[Bug c++/20350] [4.0/4.1 Regression] extern template and struct initializer and specification for a static variable
--- Additional Comments From carlo at gcc dot gnu dot org 2005-05-31 02:33
---
If you remove the 'extern', the compiler still crashes:
struct a { int i, j; };
template struct mutex_tct { static a S_mutex; };
template a mutex_tct::S_mutex = {0,1};
template <> a mutex_tct<0>::S_mutex;
template <> a mutex_tct<0>::S_mutex = {0,1};
void g() { mutex_tct<0>::S_mutex.i = 0; }
>g++-4.0.0 -v troep.cc
Using built-in specs.
Target: i686-redhat-linux
Configured with: /usr/src/gcc/gcc-4.0.0/configure --prefix=/usr/local/gcc-4.0.0
--enable-shared --with-gnu-as --with-gnu-ld--enable-languages=c++ --enable-debug
--enable-threads=posix --disable-checking --with-system-zlib
--enable-__cxa_atexit --host=i686-redhat-linux
Thread model: posix
gcc version 4.0.0
/usr/local/gcc-4.0.0/libexec/gcc/i686-redhat-linux/4.0.0/cc1plus -quiet -v
-D_GNU_SOURCE troep.cc -quiet -dumpbase troep.cc -mtune=pentiumpro -auxbase
troep -version -o /tmp/ccDplkLP.s
ignoring nonexistent directory
"/usr/local/gcc-4.0.0/lib/gcc/i686-redhat-linux/4.0.0/../../../../i686-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/gcc-4.0.0/lib/gcc/i686-redhat-linux/4.0.0/../../../../include/c++/4.0.0
/usr/local/gcc-4.0.0/lib/gcc/i686-redhat-linux/4.0.0/../../../../include/c++/4.0.0/i686-redhat-linux
/usr/local/gcc-4.0.0/lib/gcc/i686-redhat-linux/4.0.0/../../../../include/c++/4.0.0/backward
/usr/local/include
/usr/local/gcc-4.0.0/include
/usr/local/gcc-4.0.0/lib/gcc/i686-redhat-linux/4.0.0/include
/usr/include
End of search list.
GNU C++ version 4.0.0 (i686-redhat-linux)
compiled by GNU C version 4.0.0.
GGC heuristics: --param ggc-min-expand=90 --param ggc-min-heapsize=113235
troep.cc:5: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20350
[Bug libstdc++/11953] _REENTRANT defined when compiling non-threaded code.
--- Additional Comments From carlo at gcc dot gnu dot org 2004-10-08 13:53 --- This wording is very boost specific and does not give a solution for other libraries that need to detect at prepocessing time whether or not -pthread is being used. Consider a library libjohndoe, this library comes in two flavours: one that is not thread-safe (-ljohndoe) and one that is thread-safe, but considerably slower and larger so that users really only want to use it when they are actually using threads (-ljohndoe_r). The header files of libjohndoe also need to adjust prototypes and macros based on whether a user is linking with -ljohndoe or -ljohndoe_r, so a macro is needed. If that macro is not provided by -pthreads, then the users of libjohndoe will be forced to provide it themselfs: g++ app.cc -ljohndoe or g++ -pthread app.cc -DMT_JOHNDOE -ljohndoe_r -lpthread In my opinion that is the same as when users of Tru64 are forced to define _REENTRANT when including pthread.h and when that is not acceptable then forcing user-defined macros to be defined in order to tell whether or not an application is expected to be thread-safe (while previous this was not necessary) seems at least to be undesirable. Most importantly however - it is totally unnecessary. At all times there will be this -pthread commandline option that imho has exactly the meaning that we are looking for: This application is using threads and needs thread-safe libraries. Wouldn't it be a very reasonable and logical solution to define some, any, macro when -pthread is used on the command line? It would solve my problem and it would solve boosts problem, and it would solve the problem of the author of libjohndoe too. I think this new macro really must be added to 4.0.0 before its release. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11953
[Bug c++/18110] New: Possible regression with error no match for 'operator*'
Not sure if this is a bug (probably not even), but reporting it
here anyway on request of pinskia after I asked him about it online.
I used to be able to compile the following with 3.3.3:
poly left = (x2 + b) * x + a;
where all variables involved are of type 'poly'.
With 3.4.2 I get this error:
../../../libecc/testsuite/point/pointTest.cc:190: error: no match for
'operator*' in 'libecc::operator+ [with unsigned int m = 5u, unsigned int k =
2u](((const libecc::polynomial<5u, 2u>&)((const libecc::polynomial<5u,
2u>*)(+x2))), ((const libecc::polynomial<5u, 2u>&)((const libecc::polynomial<5u,
2u>*)(&b * x'
And, in order for it compile I have to use split up the
expression like this:
poly const& tmp1 = (x2 + b);
poly left = tmp1 * x + a;
I've attached the full preprocessed source with stripped line numbers.
The results with that file are as follows:
$ /usr/local/gcc-3.3.3/lib/gcc-lib/i686-redhat-linux/3.3.3/cc1plus
-fpreprocessed pointTest.ii -quiet -dumpbase pointTest.cc -auxbase-strip
pointTest.o -g -version -o pointTest.s
GNU C++ version 3.3.3 (i686-redhat-linux)
compiled by GNU C version 3.3.3.
GGC heuristics: --param ggc-min-expand=90 --param ggc-min-heapsize=113264
(no errors), and:
$ /usr/local/gcc-3.4.2/libexec/gcc/i686-redhat-linux/3.4.2/cc1plus
-fpreprocessed pointTest.ii -quiet -dumpbase pointTest.cc -auxbase-strip
pointTest.o -g -version -o pointTest.s
GNU C++ version 3.4.2 (i686-redhat-linux)
compiled by GNU C version 3.4.2.
GGC heuristics: --param ggc-min-expand=90 --param ggc-min-heapsize=113264
pointTest.ii: In function `int main()':
pointTest.ii:41496: error: no match for 'operator*' in 'libecc::operator+ [with
unsigned int m = 5u, unsigned int k = 2u](((const libecc::polynomial<5u,
2u>&)((const libecc::polynomial<5u, 2u>*)(+x2))), ((const libecc::polynomial<5u,
2u>&)((const libecc::polynomial<5u, 2u>*)(&b * x'
pointTest.ii:41502: error: no match for 'operator==' in 'left ==
libecc::operator+ [with unsigned int m = 5u, unsigned int k = 2u](((const
libecc::polynomial<5u, 2u>&)((const libecc::polynomial<5u, 2u>*)(+y2))), ((const
libecc::polynomial<5u, 2u>&)((const libecc::polynomial<5u,
2u>*)(&libecc::operator*(const libecc::polynomial&, const
libecc::polynomial&) [with unsigned int m = 5u, unsigned int k =
2u](((const libecc::polynomial<5u, 2u>&)((const libecc::polynomial<5u,
2u>*)(&y'
pointTest.ii:29745: note: candidates are: bool libecc::operator==(const
libecc::bitset_index&, const libecc::bitset_index&)
Attaching pointTest.ii.bz2 in a minute.
--
Summary: Possible regression with error no match for 'operator*'
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carlo at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i686-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18110
[Bug c++/18110] Possible regression with error no match for 'operator*'
--- Additional Comments From carlo at gcc dot gnu dot org 2004-10-22 13:56 --- Created an attachment (id=7398) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7398&action=view) bzip2-ed preprocessed source code without line numbers (s/^# .*//). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18110
[Bug c++/18110] Possible regression with error no match for 'operator*'
--- Additional Comments From carlo at gcc dot gnu dot org 2004-10-22 15:01 --- Created an attachment (id=7399) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7399&action=view) Stripped down test case. I managed to strip it down to a more reasonable size. Still not sure what is going on though. -- What|Removed |Added Attachment #7398 is|0 |1 obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18110
[Bug c++/18110] Possible regression with error no match for 'operator*'
--- Additional Comments From carlo at gcc dot gnu dot org 2004-10-22 15:32 --- Created an attachment (id=7400) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7400&action=view) Maximal stripped down test case. This snippet still shows the same difference. If the 'friend' is removed from class B, then also 3.3.3 gives the same error. If however class B is changed to not be a template anymore, than 3.3.3 and 3.4.2 both compile this just fine. Which part in the standard says that 3.4.2 is the correct behaviour for this case? -- What|Removed |Added Attachment #7399 is|0 |1 obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18110
[Bug c++/18110] Possible regression with error no match for 'operator*'
--- Additional Comments From carlo at gcc dot gnu dot org 2004-10-22 15:39 --- Ok, thanks Volker. Our last posted crossed, sorry. I'll close the PR because I suppose you are right. I want my library to accept (a + b) * c however, so I guess I'd have to add new operator* prototypes :(. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18110
