Bug 11953 - _REENTRANT defined when compiling non-threaded code.
Summary: _REENTRANT defined when compiling non-threaded code.
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: libstdc++ (show other bugs)
Version: 3.4.0
: P2 normal
Target Milestone: 4.1.2
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 15415 17398 (view as bug list)
Depends on: 20705
Blocks:
  Show dependency treegraph
 
Reported: 2003-08-17 02:21 UTC by carlo
Modified: 2012-05-15 11:35 UTC (History)
10 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2005-04-30 16:13:12


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description carlo 2003-08-17 02:21:06 UTC
This can't be right imho.

>g++-3.3 troep.cc
>a.out; echo $?
0

>g++-cvs-3.4 troep.cc
>a.out; echo $?
1

Where

>cat troep.cc
#include <iosfwd>

int main()
{
#ifdef _REENTRANT
  return 1;
#else
  return 0;
#endif
}

_REENTRANT is defined regardless in
bits/gthr-default.h at the moment.
Comment 1 Andrew Pinski 2003-08-17 02:28:10 UTC
I can confirm this on the mainline (20030814) on i686-pc-linux-gnu but on powerpc-apple-
darwin6.6 or i686-unknown-openbsd3.1 with the mainline (20030816) I cannot reproduce it.

powerpc-apple-darwin6.6 and i686-pc-linux-gnu are configured with --enable-threads=posix, 
while i686-unknown-openbsd3.1 is not.

I do not know what is going one.
Comment 2 Andrew Pinski 2003-08-17 02:37:18 UTC
This was done on purpose:
+/* Some implementations of <pthread.h> require this to be defined.  */
+#ifndef _REENTRANT
+#define _REENTRANT 1
+#endif
+
Comment 3 carlo 2003-08-17 02:56:17 UTC
Subject: Re:  _REENTRANT defined when compiling non-threaded code.

On Sun, Aug 17, 2003 at 02:37:18AM -0000, pinskia at gcc dot gnu dot org wrote:
> PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11953
> 
> 
> pinskia at gcc dot gnu dot org changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|NEW                         |RESOLVED
>           Component|libstdc++                   |other
>          Resolution|                            |INVALID
> 
> 
> ------- Additional Comments From pinskia at gcc dot gnu dot org  2003-08-17 02:37 -------
> This was done on purpose:
> +/* Some implementations of <pthread.h> require this to be defined.  */
> +#ifndef _REENTRANT
> +#define _REENTRANT 1
> +#endif
> +

Yes, so?

How is a developer supposed to know when an application is
compiled with threading now?
My code is FULL of
#ifdef _REENTRANT 
...
#else
...
#endif

Suddenly all code that is compiled with the intension
to be not thread-safe, and which will not be linked
with libpthread.so is suddenly compiled as if it
has to be thread-safe?

Why was this done on purpose?  It breaks a lot of code!

Comment 4 Benjamin Kosnik 2003-09-10 12:55:16 UTC
Carlo. 

I'm not going to comment on this issue directly, but instead will tell you that
I've just learned that g++ doesn't define _REENTRANT on s390x and ia64 when
--enable-threads=posix and using -pthread on the command line. (Found while
compiling boost threads package on the afflicted platforms.) Supposdely this is
a known issues.

Thus, people who are using _REENTRANT as a macro to see if thread-enabled are
already going to have problems. The suggestion, made elsewhere, is to use
_POSIX_THREADS and check >= 0 (see unistd.h).

Best,
benjamin
Comment 5 Carlo Wood 2004-04-15 13:22:37 UTC
No, it was not resolved.  I think it is stupid indeed.
I now detect the use of _REENTRANT before any headerfile
is included; I can do that because I always include
a custom "sys.h" as very first header in all my projects
that I use to work around OS bugs.  However, this still
causes _REENTRANT to be defined or not defined purely
depending on if some standard header was or was not
included yet - and as such breaks third party libraries
that depend directly on _REENTRANT.

On Thu, Apr 15, 2004 at 04:44:06PM +0800, Yu Wang wrote:
> Hi, Carlo,
>   I found your email from gcc.gnu.org archives, in finding the solution
> for a same problem you met(quoted below). My gcc version  is 3.3.2
> (release). Could you told me how is your status on this?Is it solved?
>   Any help would be appreciated.
>
> Regards.
> Yu
Comment 6 Andrew Pinski 2004-05-13 10:53:30 UTC
*** Bug 15415 has been marked as a duplicate of this bug. ***
Comment 7 Jonathan Wakely 2004-05-13 11:15:09 UTC
Bug 15415 relates to problems using Boost due to this issue, which I don't think
is INVALID.

Ben's suggestion of using _POSIX_THREADS >= 0 doesn't work either, as it is also
defined whether you use -pthread or not (at least on Linux and FreeBSD)

Would it be possible for all relevant platforms to define something such as
_GXX_PTHREADS when -pthread is given? This would allow Boost to reliably detect
whether or not to use threadsafe constructs when compiled with G++ 3.4
Comment 8 Wolfgang Bangerth 2004-05-13 22:54:03 UTC
Let's reopen it. I believe that this causes significant grief to 
application writers, and defining system flags like these that 
have traditionally been set on the command line is at least not 
very good style. If unnecessary, it should be done only for 
those platforms where it really is necessary. 
 
It would be good if everyone would try to think hard again and 
figure out a way to work around this problem. The idea of 
defining something like __GXX_PTHREADS__ or similar wouldn't 
be such a bad idea -- after all we already have a number of other 
command line options that do similarly. 
 
W. 
Comment 9 Loren Rittle 2004-05-14 01:27:56 UTC
Please do not reopen this bug unless you engage the original author of the patch
that broke it (e.g. ro).  Users should not be writing code which depends on the
state of _REENTRANT.

Like Benjamin I will only comment indirectly: I will just state that every other
port which enabled threading support did not require this define to be
(unconditionally) blasted into gthr-posix.h .  Every other port figured out how
to stuff it in port-specific places. I don't know if Rainer should be asked to
rework his thread support for alpha*-dec-osf[45]*... (but that would be my
choice to properly close this bug even though I don't think portable code should
even use this macro's state in any way)
Comment 10 John Maddock 2004-05-14 10:40:00 UTC
IMO there are several issues here:

1) Documentation - the thread compiler options are undocumented currently.
2) Consistency - we currently appear to have -pthread (Linux) -pthreads 
(solaris) -mthread (mingwin), or nothing required (BSD, cygwin).  Please can 
we have some kind of consistent policy here?
3) The C++ headers should not be defining a symbol that's normally defined on 
the compiler command line (and usually by the appropriate compiler option 
rather than a direct define).
4) It would be nice if _REENTRANT was a compiler define when it's in thread-
safe mode - that's the way most other compiler vendors handle it (although 
some spell it _MT :-) ).

Regards,

John Maddock.
Comment 11 Rainer Orth 2004-05-18 18:40:29 UTC
Subject: Re:  _REENTRANT defined when compiling non-threaded code.

ljrittle at gcc dot gnu dot org writes:

> Please do not reopen this bug unless you engage the original author of the patch
> that broke it (e.g. ro).  Users should not be writing code which depends on the
> state of _REENTRANT.

Exactly: I have yet to see some normative text stating that _REENTRANT must
not be defined without threading support enabled.  So far the assertions
have only been `we have always used it to determine if threading support is
available', but no indication whatsoever why this is necessary and why they
use _REENTRANT for that purpose.  Proper tests should test for the
respective functions instead, it seems.

> Like Benjamin I will only comment indirectly: I will just state that every other
> port which enabled threading support did not require this define to be
> (unconditionally) blasted into gthr-posix.h .  Every other port figured out how
> to stuff it in port-specific places. I don't know if Rainer should be asked to
> rework his thread support for alpha*-dec-osf[45]*... (but that would be my
> choice to properly close this bug even though I don't think portable code should
> even use this macro's state in any way)

I can try to stuff this definition into a (new) config/os/osf/os_defines.h,
but that means I'll have to duplicate config/os/generic/ctype_* to allow
this.

	Rainer
Comment 12 Jonathan Wakely 2004-05-18 21:21:26 UTC
Rainer,

Admittedly, Boost was never correct to use that macro, but the fact remains that
the change has caused problems that Boost must now address.

If there is a better way to tell (at preprocessing stage) whether g++ will link
to the real pthread_* symbols or the weak ones defined in gthr-posix.c I'm sure
the Boost developers would be glad to use it.

Detecting _REENTRANT used to work on linux and other key platforms and so my
naive opinion is that a similar, but documented and cross-platform, macro such
as __GXX_PTHREADS__ would serve the purpose better.

If something like this were acceptable I'd help the work where possible
(is there an easier way than adding it to the all the config/${cpu}/*.h files
for relevant platforms?)
Comment 13 John Maddock 2004-05-19 10:33:33 UTC
To respond to your recent comments, here's the history:

There are a number of compilers which can compile code in either "thread safe 
mode", or "non thread safe mode" depending upon which compiler switches are 
passed to the C++ front end.  Some of these compilers use _MT to indicate that 
they are in thread safe mode (the Windows ones), and some commercial Unix 
compilers use _REENTRANT for this (don't ask me which ones I've lost my the 
right now).  Gcc historically didn't touch _REENTRANT at all, so we were safe 
in detecting this macro to test to see if the compiler was *capable* of 
producing thread safe code.

Note that testing for the presence of _POSIX_THREADS or whatever is *not* 
sufficient: that tells you whether the OS has the POSIX thread API's or not, 
it does not tell you whether the C++ compiler you are using will generate 
thread safe code or not (the C++ runtime, and in particular the exception 
handling code needs to be thread safe, if that's not the case the code will 
compile and link, but will likely crash if a thread throws an exception, 
obviously I'm generalising here, because the details depend on the compiler). 

In this respect C++ compilers are different from native platform C compilers, 
which can use _POSIX_THREADS.

Moving back to gcc.... I believe that if the compiler is configured with --
disable-threads, the underlying platform will still report that _POSIX_THREADS 
is set won't it?  Even though the compiler itself is incapable of producing 
thread safe code in this configuration.  As a next best approximation, we can 
test to see if libstdc++ has been configured with threads on, by detecting the 
undocumented macro _GLIBCXX_HAVE_GTHR_DEFAULT, but you know that's not right 
either.

Regards,

John Maddock.
Comment 14 Mark Mitchell 2004-06-09 19:18:13 UTC
Can we conditionalize the definition of _REENTRANT only for those platforms
whose POSIX threads implementation really does depend on this?
Comment 15 Rainer Orth 2004-06-09 19:24:57 UTC
Subject: Re:  _REENTRANT defined when compiling non-threaded code.

mmitchel at gcc dot gnu dot org writes:

> Can we conditionalize the definition of _REENTRANT only for those platforms
> whose POSIX threads implementation really does depend on this?

That would be one possibility.  Currently, only Tru64 UNIX V5.1[AB] is
known to need this.

Otherwise, a patch like the following would be necessary, which is really
ugly.  It requires every user of gthr.h to define _REENTRANT for Tru64 UNIX
(or other platforms that need might it), even without knowing if pthreads
are in use at all.  Currently, libjava has a mechanism for
platform-specific defines, while libobjc (the other gthr.h user) has not.

	Rainer



Index: gcc/gthr-posix.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/gthr-posix.h,v
retrieving revision 1.28
diff -u -p -r1.28 gthr-posix.h
--- gcc/gthr-posix.h	28 May 2004 20:18:23 -0000	1.28
+++ gcc/gthr-posix.h	9 Jun 2004 14:09:19 -0000
@@ -35,11 +35,6 @@ Software Foundation, 59 Temple Place - S
 
 #define __GTHREADS 1
 
-/* Some implementations of <pthread.h> require this to be defined.  */
-#ifndef _REENTRANT
-#define _REENTRANT 1
-#endif
-
 #include <pthread.h>
 #include <unistd.h>
 
Index: gcc/config/alpha/t-osf-pthread
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/alpha/t-osf-pthread,v
retrieving revision 1.1
diff -u -p -r1.1 t-osf-pthread
--- gcc/config/alpha/t-osf-pthread	31 Jul 2003 12:01:06 -0000	1.1
+++ gcc/config/alpha/t-osf-pthread	9 Jun 2004 14:09:21 -0000
@@ -2,4 +2,4 @@
 LIB2FUNCS_EXTRA += $(srcdir)/gthr-posix.c
 
 # Compile libgcc2 with POSIX threads supports
-TARGET_LIBGCC2_CFLAGS=-pthread
+TARGET_LIBGCC2_CFLAGS += -pthread
Index: libobjc/thr-objc.c
===================================================================
RCS file: /cvs/gcc/gcc/libobjc/thr-objc.c,v
retrieving revision 1.3
diff -u -p -r1.3 thr-objc.c
--- libobjc/thr-objc.c	23 May 2003 20:25:39 -0000	1.3
+++ libobjc/thr-objc.c	9 Jun 2004 14:10:43 -0000
@@ -30,6 +30,10 @@ Boston, MA 02111-1307, USA.  */
 #include "defaults.h"
 #include <objc/thr.h>
 #include "runtime.h"
+/* Tru64 UNIX V5.1[AB] <pthread.h> requires this to be defined.  */
+#ifndef _REENTRANT
+#define _REENTRANT 1
+#endif
 #include <gthr.h>
 
 /* Backend initialization functions */
Index: libstdc++-v3/configure.host
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/configure.host,v
retrieving revision 1.25
diff -u -p -r1.25 configure.host
--- libstdc++-v3/configure.host	27 Feb 2004 20:56:43 -0000	1.25
+++ libstdc++-v3/configure.host	9 Jun 2004 14:10:43 -0000
@@ -184,6 +184,9 @@ case "${host_os}" in
   netbsd*)
     os_include_dir="os/bsd/netbsd"
     ;;
+  osf*)
+    os_include_dir="os/osf"
+    ;;
   qnx6.[12]*)
     os_include_dir="os/qnx/qnx6.1"
     c_model=c

with libstdc++-v3/config/os/osf containing copies of the generic ctype*.h
files and os_defines.h changed like this:

--- ../generic/os_defines.h	Mon Jul  7 13:29:14 2003
+++ os_defines.h	Mon May 24 17:08:38 2004
@@ -1,6 +1,6 @@
-// Specific definitions for generic platforms  -*- C++ -*-
+// Specific definitions for HP Tru64 UNIX  -*- C++ -*-
 
-// Copyright (C) 2000 Free Software Foundation, Inc.
+// Copyright (C) 2004 Free Software Foundation, Inc.
 //
 // This file is part of the GNU ISO C++ Library.  This library is free
 // software; you can redistribute it and/or modify it under the
@@ -34,4 +34,9 @@
 // System-specific #define, typedefs, corrections, etc, go here.  This
 // file will come before all others.
 
+// Tru64 UNIX V5.1[AB] <pthread.h> requires this to be defined.
+#ifndef _REENTRANT
+#define _REENTRANT 1
+#endif
+
 #endif
Comment 16 Andrew Pinski 2004-06-09 19:30:41 UTC
Subject: Re:  _REENTRANT defined when compiling non-threaded code.

> 
> 
> ------- Additional Comments From ro at techfak dot uni-bielefeld dot de  2004-06-09 19:24 -------
> Subject: Re:  _REENTRANT defined when compiling non-threaded code.
> 
> mmitchel at gcc dot gnu dot org writes:
> 
> > Can we conditionalize the definition of _REENTRANT only for those platforms
> > whose POSIX threads implementation really does depend on this?
> 
> That would be one possibility.  Currently, only Tru64 UNIX V5.1[AB] is
> known to need this.
> 
> Otherwise, a patch like the following would be necessary, which is really
> ugly.  It requires every user of gthr.h to define _REENTRANT for Tru64 UNIX
> (or other platforms that need might it), even without knowing if pthreads
> are in use at all.  Currently, libjava has a mechanism for
> platform-specific defines, while libobjc (the other gthr.h user) has not.

The libobjc part is fine with me since there is no need for platform-specific
defines as the header file is only included the sources of libobjc and never
included with from any user code.

Thanks,
Andrew Pinski

Comment 17 Rainer Orth 2004-06-09 19:37:04 UTC
Subject: Re:  _REENTRANT defined when compiling non-threaded code.

pinskia at physics dot uc dot edu writes:

> The libobjc part is fine with me since there is no need for platform-specific
> defines as the header file is only included the sources of libobjc and never
> included with from any user code.

I'd prefer guarding the _REENTRANT definition in gthr-posix.h nonetheless,
since it centralizes the ugliness in one place (if this is necessary at
all, which I'm not really convinced yet, and neither several other
reviewers, it seems).

Anyway, I'll be away until June 15th in a few minutes, so this will have to
wait until then.

	Rainer
Comment 18 Mark Mitchell 2004-06-18 23:41:45 UTC
Postponed until GCC 3.4.2.
Comment 19 Benjamin Kosnik 2004-07-20 00:50:03 UTC
Sorry guys, I'm just getting back to this.

Ranier, I think you are right: we should make an osf directory, dupe the files,
and remove the gthr-posix.h unconditional defines.

Do you want to do this? Let's try to fix this for 3.4.2. I think this is a high
priority bug BTW.

I have to say that John Maddock really does have a huge point with the
consistency issue. It's incredibly annoying that -pthreads/-pthread/-mthread
even exist, when -pthread across all would have been much, much better. Why does
gcc do this crazy stuff? Ugh. I guess we cannot fix this particular bit for
3.4.2, although, quite frankly, we should.

-benjamin
Comment 20 Jonathan Wakely 2004-07-22 13:19:05 UTC
Would it be possible to add a caveat to http://gcc.gnu.org/gcc-3.4/changes.html
saying that users of Boost (on Linux at least) might get linker errors, which
can be avoided by _either_ compiling with -pthread, _or_ defining
BOOST_DISABLE_THREADS ?

I can supply the wording if wanted.
Comment 21 Giovanni Bajo 2004-07-22 13:40:02 UTC
Jonathan: I think it makes sense. Prepare a HTML patch against changes.html and 
send it to gcc-patches@gcc.gnu.org.
Comment 22 Mark Mitchell 2004-08-19 20:30:57 UTC
Postponed until GCC 3.4.3.
Comment 23 Andrew Pinski 2004-09-10 15:25:17 UTC
*** Bug 17398 has been marked as a duplicate of this bug. ***
Comment 24 Jonathan Wakely 2004-10-08 13:13:40 UTC
I've finally sent a wwwdocs patch to gcc-patches for approval.

http://gcc.gnu.org/ml/gcc-patches/2004-10/msg00736.html
Comment 25 Carlo Wood 2004-10-08 13:53:46 UTC
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.

Comment 26 Jonathan Wakely 2004-10-11 11:39:23 UTC
Carlo, I realise the text (which I've committed btw) is quite Boost-specific,
that's because
1) Boost is the only code I use which is affected by this PR (selfish, I know)
2) Boost is the only library for which a simple workaround is given on this PR.

Comment 27 Jonathan Wakely 2004-10-11 12:22:23 UTC
I've been thinking about this PR, probably too much. I assume my concerns are
unfounded, or we'd have noticed bigger problems by now, but here goes:

The change to gthr-posix.h means that if GCC is configured with thread-support
on Tru64 then it _always_ compiles thread-safe programs, even when -pthread
is not used. The only way to prevent that is to configure with --disable-threads.
Carlo said in comment #25 that this means even single-threaded apps will use
slower, reentrant versions of libs. For system libs, this is not true,
because if -pthread is not given then the reentrant libs won't be linked to,
even though _REENTRANT was defined. Is it even well-formed to define
_REENTRANT and include <pthread.h> but _not_ link to the reentrant libs?

Tru64's <pthread.h> (at least, the fixincluded version) says:

 * You should always define _REENTRANT on the command line, usually by using
 * "cc -pthread" or "cxx -pthread", to be sure that it will be available for
 * all header files.

This recommendation is not followed by gthr-posix.h, which defines _REENTRANT
only before including <pthread.h>. Not all libstdc++ headers include
gthr-posix.h, so _REENTRANT won't always be defined e.g. <utility> doesn't
include gthr-posix.h, so in this code:

  #include <utility>
  #include <unistd.h>
  #include <iostream>

_REENTANT will not be defined when unistd.h is included. The above comment
from Tru64's pthread.h is followed by "#include <unistd.h>" which will have no
effect if that file was already included before _REENTRANT was defined.

Rainer's proposal to put _REENTRANT in os_defines.h will ensure that
_REENTRANT is always defined, but it won't get around the issue of including
thread-safe definitions but not linking to them (but maybe that's a non-issue).

Would it be possible to only include <pthread.h> if _REENTRANT is defined,
and include some <pthread-dummy.h> otherwise, which just has dummy decls for
the pthread_xxx() functions needed by gthreads? That way whether reentrant
code is used would depend on whether -pthread was used, as is intended.

I have very litle experience with either MT or Tru64, so probably haven't got
this analysis right, I'm just trying to understand the issues better.
Comment 28 Mark Mitchell 2004-10-30 19:37:39 UTC
Postponed until GCC 3.4.4.
Comment 29 Andrew Pinski 2005-06-13 03:29:01 UTC
Did we decide this is a bug or not?
Comment 30 cludwig 2005-06-14 13:19:33 UTC
Subject: Re:  _REENTRANT defined when compiling non-threaded code.

On Mon, Jun 13, 2005 at 03:29:02AM -0000, pinskia at gcc dot gnu dot org wrote:
> ------- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-13 03:29 -------
> Did we decide this is a bug or not?

Strictly speaking, it is not a bug AFAICT because gcc does not violate any
standard. However, current gcc releases make the life unnecessarily hard for
developers because there is no way to decide at compile time (more precisely:
in the preprocessing stage) whether g++ will link against the "real" pthread_*
symbols. They have to resort to their own preprocessor macros
MY_LIB_USE_THREADS and rely on their users who include the respective headers
to (un-)define those macros correctly. So it is a QoI issue. (If I am not
mistaken then gcc is the only compiler for which the Boost libraries cannot
detect automatically whether the code needs to support MT.)

Perhaps I am missing something, but wouldn't it be sufficient if gcc defined a
dedicated preprocessor constant whenever the option -pthreads was found on the
command line? (I know next to nothing about the gcc source code, so I cannot
say whether that would be straightforward to implement.)

Regards

Christoph
Comment 31 David Hopwood 2005-07-29 11:25:04 UTC
The option inconsistency between platforms is bug 20705.

I agree there should be a #define that says whether POSIX threads are usable
(rather than just supported by the platform), but I think _REENTRANT is the
wrong #define to use. This applies to both C and C++, so the name should be
something like __GCC_PTHREADS__, not __GXX_PTHREADS__.
Comment 32 David Hopwood 2005-07-29 11:58:44 UTC
<http://gcc.gnu.org/ml/libstdc++/2002-02/msg00231.html> suggests defining
__GNUC_THREADMODEL__ to a string specifying the thread model.
Comment 33 Jonathan Wakely 2005-07-29 12:40:55 UTC
Should a separate PR be opened requesting __GCC_PTHREADS__, so this PR can focus
on whether _REENTRANT should be defined unconditionally and discussion of an
alternative macro can take place separately?

I have the beginnings of a patch to define __GCC_PTHREADS__ whenever -pthread is
given if that would help. It's incomplete, as not all gcc/config/* files use
-pthread in the CPP_SPEC and I have only added -D__GCC_PTHREADS__ where CPP_SPEC
already does something for -pthread/-pthreads.  If I'm not wasting my time I'll
finish it off.
Comment 34 Marc Wäckerlin 2005-11-28 13:37:38 UTC
What now? What happened since July? There's not even a new trouble report open asking for "__GCC_PTHREADS__".

What can I as library writer now do, if I want to know whether or not I am in valid multithreaded environment, and if I don't want to force my clients to use silly defines like "-pthreads -DWE_HAVE_MULTIHREADING"?

Especially, there are tons of code reliyng on the "#ifdef _REENTRANT" check, so breaking this compatibility was really stupid! But the wort thin is, that there is not even an equivalent replacement, not even in gcc release 4.0.2!

If other compilor vendors use either _REENTRANT or _MT to distiguish multithreaded from non-threaded environments, gcc should do it exactly the same way, and not introduce seomething new and compiler dependent!

Now, to be backward compatible, I have to modify my code in the way:

#if (__GNUC__==3 && __GNUC_MINOR__>=4 || __GNUC__>3) && MY_SILLY_FLAG || (__GNUC__==3 && __GNUC_MINOR__<4 || __GNUC__<3) && _REENTRANT || _MT
// multithreaded code here
#endif

and to tell my clients to add -DMY_SILLY_FLAG in addition to -pthread if they use gcc>=3.4 and want threadsafe code.

Or, slightly better, use "_MT" and define _MT automatically if possible, or have to add -D_MT otherwise:

#if (__GNUC__==3 && __GNUC_MINOR__<4 || __GNUC__<3) && _REENTRANT
#define _MT
#endif
[...]
#ifdef _MT
// multithreaded code here
#endif

Any better idea?!?

I would cleary declare this breaking with backward-compatibility as a major bug in gcc!
Comment 35 Marc Wäckerlin 2005-11-29 09:13:55 UTC
I had a look in google about "#ifdef _REENTRANT", and it gets about 20'200 entries, so this is a widely used funtinality that must not be broken!

Imagine all the code the does the "#ifdef _REENTRANT" to enable threading: If now _REENTRANT is always true, regardless of whether -pthreads is given or not, then all this code will crash when compiled with gcc += 3.4!

This is really a severe problem!

Please return to the previous behaviour of _REENTRANT, and fix it for those platforms, where it previousely did not work (s390x and ia64).

The _REENTRANT must work as 90% of the programmers expect it to work! It wasn't my idea to look for _REENTRANT, i learnt it from a collegue who has seen it in system C libraries and e.g. the QpThread library. It is a widely used feature! It must neither be broken, nor be replaced by something else, sich as __GCC_PTHREADS__ or the like!

In errno.h, AFAIK they also tested for _REENTRANT, now they test for:
#  if !defined _LIBC || defined _LIBC_REENTRANT

Is this an acceptable way to do it now, test for _LIBC_REENTRANT?

Reentrant is also used in /usr/include/features.h:
/* These are defined by the user (or the compiler)
   to specify the desired environment:
     [...]
   _REENTRANT		Select additionally reentrant object.
   _THREAD_SAFE		Same as _REENTRANT, often used by other systems.
     [...]
*/
  --> So it should be set correctly by the compiler!!!!
#if defined _REENTRANT || defined _THREAD_SAFE
# define __USE_REENTRANT	1
#endif
Comment 36 Marc Wäckerlin 2005-11-29 09:27:09 UTC
New information:

_REENTRANT is definitively defined in the headers:

> echo "" | g++ \
    -I /usr/include/c++/4.0.2 -I /usr/include/c++/4.0.2/i586-suse-linux \
    -E -dM -c - | grep REENTRANT
> echo "" | g++ \
    -I /usr/include/c++/4.0.2 -I /usr/include/c++/4.0.2/i586-suse-linux \
    -E -dM -c -pthread - | grep REENTRANT
#define _REENTRANT 1
> echo "#include<iostream>" | g++ \
    -I /usr/include/c++/4.0.2 -I /usr/include/c++/4.0.2/i586-suse-linux \
    -E -dM -c - | grep REENTRANT
#define _REENTRANT 1
#define _POSIX_REENTRANT_FUNCTIONS 1

--> So, without "#include <iostream>" it works as expected!

This opens a new possibility to work around this bug:

--------------file.cpp
#define GCC_BUGFIX _REENTRANT
#include <iostream>
#include ...
#undef _REENTRANT
#define _REENTRANT GCC_BUGFIX

#ifdef _REENTRANT
  ...
#endif
----------------------



> g++ -v
Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,objc,f95,java,ada --disable-checking --with-gxx-include-dir=/usr/include/c++/4.0.2 --enable-java-awt=gtk --disable-libjava-multilib --with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit --without-system-libunwind --host=i586-suse-linux
Thread model: posix
gcc version 4.0.2 20050901 (prerelease) (SUSE Linux)
Comment 37 Marc Wäckerlin 2005-11-29 09:33:56 UTC
Correction: The above work around only works, as long, as your file is not included by another file...
Comment 38 Carlo Wood 2005-11-29 16:05:58 UTC
That never works because it always defines _REENTRANT.
You probably mean:

#ifdef _REENTRANT
#define GCC_BUGFIX 1
#endif
#include <iostream>
#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.
Comment 39 Jakub Jelinek 2006-02-17 21:49:26 UTC
Subject: Bug 11953

Author: jakub
Date: Fri Feb 17 21:49:22 2006
New Revision: 111212

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111212
Log:
	PR libstdc++/11953
	* gthr-posix.h (_REENTRANT): Only define if __osf__ is defined.

	* config/ia64/linux.h (CPP_SPEC): Define.
	* config/s390/linux.h (CPP_SPEC): Define.

Modified:
    branches/redhat/gcc-4_1-branch/gcc/ChangeLog
    branches/redhat/gcc-4_1-branch/gcc/config/ia64/linux.h
    branches/redhat/gcc-4_1-branch/gcc/config/s390/linux.h
    branches/redhat/gcc-4_1-branch/gcc/gthr-posix.h

Comment 40 Gabriel Dos Reis 2006-02-28 08:46:09 UTC
Fixed in 4.1. and up.
Comment 41 Debian GCC Maintainers 2006-10-05 16:06:34 UTC
the patch was applied in the redhat/gcc-4_1-branch, not in the gcc-4_1-branch. either the target milestone should be changed or the bug reopened.

  Matthias
Comment 42 Daniel Berlin 2006-12-11 18:13:24 UTC
This bug (against the regular development branches) should not be marked fixed simply because a patch was applied to the redhat branch.

Either it needs to go into mainline 4.1, or the bug needs to be closed in some other manner.

I am simply reopening it because it looks like it hasn't actually been resolved.

I have no opinion on any of the actual issues involved :)
Comment 43 Jakub Jelinek 2006-12-12 15:15:38 UTC
Subject: Bug 11953

Author: jakub
Date: Tue Dec 12 15:15:19 2006
New Revision: 119788

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119788
Log:
	PR libstdc++/11953
	* gthr-posix.h (_REENTRANT): Only define if __osf__ is defined.

	* config/ia64/linux.h (CPP_SPEC): Define.
	* config/s390/linux.h (CPP_SPEC): Define.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/ia64/linux.h
    trunk/gcc/config/s390/linux.h
    trunk/gcc/gthr-posix.h

Comment 44 Jakub Jelinek 2006-12-12 15:22:11 UTC
Subject: Bug 11953

Author: jakub
Date: Tue Dec 12 15:21:53 2006
New Revision: 119789

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119789
Log:
	PR libstdc++/11953
	* gthr-posix.h (_REENTRANT): Only define if __osf__ is defined.

	* config/ia64/linux.h (CPP_SPEC): Define.
	* config/s390/linux.h (CPP_SPEC): Define.

Modified:
    branches/gcc-4_2-branch/gcc/ChangeLog
    branches/gcc-4_2-branch/gcc/config/ia64/linux.h
    branches/gcc-4_2-branch/gcc/config/s390/linux.h
    branches/gcc-4_2-branch/gcc/gthr-posix.h

Comment 45 Jakub Jelinek 2006-12-12 15:24:22 UTC
Subject: Bug 11953

Author: jakub
Date: Tue Dec 12 15:24:07 2006
New Revision: 119790

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119790
Log:
	PR libstdc++/11953
	* gthr-posix.h (_REENTRANT): Only define if __osf__ is defined.

	* config/ia64/linux.h (CPP_SPEC): Define.
	* config/s390/linux.h (CPP_SPEC): Define.

Modified:
    branches/gcc-4_1-branch/gcc/ChangeLog
    branches/gcc-4_1-branch/gcc/config/ia64/linux.h
    branches/gcc-4_1-branch/gcc/config/s390/linux.h
    branches/gcc-4_1-branch/gcc/gthr-posix.h

Comment 46 Andrew Pinski 2006-12-13 09:38:18 UTC
Fixed.
Comment 47 Matthias Klose 2006-12-17 13:47:12 UTC
Subject: Bug 11953

Author: doko
Date: Sun Dec 17 13:46:58 2006
New Revision: 119986

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119986
Log:
2006-12-17  Matthias Klose  <doko@debian.org>

        PR libstdc++/11953
        * gcc/config/mips/linux.h (SUBTARGET_CPP_SPEC): Extend.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/mips/linux.h

Comment 48 Matthias Klose 2006-12-17 13:53:17 UTC
Subject: Bug 11953

Author: doko
Date: Sun Dec 17 13:53:07 2006
New Revision: 119987

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119987
Log:
2006-12-17  Matthias Klose  <doko@debian.org>

        PR libstdc++/11953
        * gcc/config/mips/linux.h (SUBTARGET_CPP_SPEC): Extend.

Modified:
    branches/gcc-4_2-branch/gcc/ChangeLog
    branches/gcc-4_2-branch/gcc/config/mips/linux.h

Comment 49 Matthias Klose 2006-12-17 13:57:43 UTC
Subject: Bug 11953

Author: doko
Date: Sun Dec 17 13:57:31 2006
New Revision: 119988

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119988
Log:
2006-12-17  Matthias Klose  <doko@debian.org>

        PR libstdc++/11953
        * gcc/config/mips/linux.h (SUBTARGET_CPP_SPEC): Extend.

Modified:
    branches/gcc-4_1-branch/gcc/ChangeLog
    branches/gcc-4_1-branch/gcc/config/mips/linux.h

Comment 50 Blogspot 2012-05-15 11:35:32 UTC
that solved the problem thanks, most of these bugs are now solved and corrected, i do not think bug is the correct word anyway, this is my bodybuilding blog called deniserutkowski check it out http://deniserutkowski.blogspot.co.uk/