Bug 9511 - [Cygwin] Can't detect whether threading enabled
Summary: [Cygwin] Can't detect whether threading enabled
Status: VERIFIED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 3.2
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-01-30 17:56 UTC by Dave Abrahams
Modified: 2007-05-02 15:41 UTC (History)
2 users (show)

See Also:
Host: i686-pc-cygwin
Target: i686-pc-cygwin
Build: i686-pc-cygwin
Known to work:
Known to fail:
Last reconfirmed: 2004-05-21 03:04:42


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dave Abrahams 2003-01-30 17:56:01 UTC
There seems to be no way to detect whether threading
support has been enabled (with -mthread) in Cygwin GCC: from the specs
file it looks to me like it only sets a preprocessor symbol in
-mno-cygwin (mingw) mode.  There ought to be a way to detect that threading support is disabled so that pessimizations like mutex locks can be left out.

Release:
unknown

Environment:
Cygwin GCC 3.2
Comment 1 Dara Hazeghi 2003-05-31 19:37:47 UTC
Hello,

would it be possible for you to check whether this problem is still present on gcc 3.3, now that it 
has been released? Also, you filed this bug in the category c++. Don't you think this is probably a 
target specific problem and should be in the target category? Thanks,

Dara
Comment 2 Dave Abrahams 2003-05-31 22:25:13 UTC
Subject: Re:  [Cygwin] Can't detect whether threading enabled

"dhazeghi@yahoo.com" <gcc-bugzilla@gcc.gnu.org> writes:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9511
>
>
> dhazeghi@yahoo.com changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|UNCONFIRMED                 |WAITING
>    GCC host triplet|                            |i686-pc-cygwin
>  GCC target triplet|                            |i686-pc-cygwin
>             Version|unknown                     |3.2
>
>
> ------- Additional Comments From dhazeghi@yahoo.com  2003-05-31 19:37 -------
> Hello,
>
> would it be possible for you to check whether this problem is still
> present on gcc 3.3, now that it has been released? 

I'm afraid I'm going to resist installing GCC 3.3 as long as possible,
because it introduces so many C++ bugs that it would break all my
builds.

> Also, you filed this bug in the category c++. Don't you think this
> is probably a target specific problem and should be in the target
> category?  

Feel free to change it.  I am not familiar enough with the system to
know how best to file it.  I defer to your expertise.


Comment 3 Gabriel Dos Reis 2003-05-31 22:45:01 UTC
Subject: Re:  [Cygwin] Can't detect whether threading enabled

"dave@boost-consulting.com" <gcc-bugzilla@gcc.gnu.org> writes:

| I'm afraid I'm going to resist installing GCC 3.3 as long as possible,
| because it introduces so many C++ bugs that it would break all my
| builds.

I guess I can understand that :-)

-- Gaby
Comment 4 Dara Hazeghi 2003-06-02 05:27:41 UTC
Very well then, I'll recategorize this problem, and leave it in waiting...
Comment 5 Giovanni Bajo 2003-06-21 02:31:44 UTC
Really? Many C++ bugs were fixed between 3.2.3 and 3.3. Maybe you could submit 
some new 3.3 bug? Even a decently sized preprocessed source can help, we can 
reduce it ourselves.
Comment 6 Dave Abrahams 2003-06-21 03:30:42 UTC
To do that I'd have to install it, wouldn't I? <wink>

My experience of 3.3 bugs is anecdotal evidence from Ralf W. Grosse-Kunstleve, 
rwgk@cci.lbl.gov, who reports having to work around several Boost.Python bugs 
and on MacOS X, many internal compiler errors.
Comment 7 Giovanni Bajo 2003-06-21 13:23:51 UTC
Does this mean that if I get a fresh Boost CVS snapshot I'll see several 
BOOST_WORKAROUNDs for GCC 3.3 in Boost.Python, pinpointing to the bugs?
Comment 8 Ralf W. Grosse-Kunstleve 2003-06-22 11:46:17 UTC
David asked me to comment.

I've tried gcc 3.3 only under Redhat 8.0 and Mac OS X.

IIRC there is one bug that lead to code rearrangement in Boost.Python.
The problem is (e.g.) reported here:

http://mail.python.org/pipermail/c++-sig/2003-May/003935.html

Here is our final workaround (not marked as such in the code):

http://cvs.sourceforge.net/cgi-
bin/viewcvs.cgi/boost/boost/boost/python/converter/as_to_python_function.hpp.dif
f?r1=1.1&r2=1.2

Under Redhat 8.0 the only other problem I know about is that the
optimizer is broken for *some* of our extensions, but I've not tried to
track this down.

Under Mac OS 10 the worst problem are the internal compiler errors,
as reported here:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10922

There is also a problem with the Boost alignment calculation under OS
10, but I don't think (any longer) that this is a gcc 3.3 bug. For the
records, here is a related thread:

http://aspn.activestate.com/ASPN/Mail/Message/1641891

Under Mac OS 10 the gcc 3.3 optimizer is broken for *almost all* of
our extensions. You can reproduce this by following the instructions
given here:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10922#c5

Hope this is useful even though it is not strictly related to
the 9511 bug report.

Ralf
Comment 9 Dara Hazeghi 2003-07-11 21:16:30 UTC
Looks like this is present in gcc 3.3 too (the spec file barely changes). Note
the other bugs you referenced here have either been fixed, or determined to be
OS issues (low Darwin stack limit).
Comment 10 cgf@gcc.gnu.org 2003-07-12 17:32:24 UTC
Subject: Re:  [cygwin] Can't detect whether threading enabled

On Fri, Jul 11, 2003 at 09:16:31PM -0000, dhazeghi at yahoo dot com 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=9511
>
>
>dhazeghi at yahoo dot com changed:
>
>           What    |Removed                     |Added
>----------------------------------------------------------------------------
>             Status|WAITING                     |NEW
>     Ever Confirmed|                            |1
>   Last reconfirmed|0000-00-00 00:00:00         |2003-07-11 21:16:30
>               date|                            |
>
>
>------- Additional Comments From dhazeghi at yahoo dot com  2003-07-11 21:16 -------
>Looks like this is present in gcc 3.3 too (the spec file barely changes). Note
>the other bugs you referenced here have either been fixed, or determined to be
>OS issues (low Darwin stack limit).

Looks like a patch should be pretty trivial, if someone wants to submit one.
Comment 11 Dave Korn 2007-05-02 15:38:47 UTC
  From the initial PR:

> There ought to be a way to detect that threading support is disabled so that pessimizations like mutex locks can be left out.

  From the definition of -mthreads in TFM:

" `-mthreads'
     Support thread-safe exception handling on `Mingw32'.  Code that
     relies on thread-safe exception handling must compile and link all
     code with the `-mthreads' option.  When compiling, `-mthreads'
     defines `-D_MT'; when linking, it links in a special thread helper
     library `-lmingwthrd' which cleans up per thread exception
     handling data. "

  Having checked, the /only/ effects of -mthreads are to define the preprocessor symbol and add the library to the linker command (i.e., it makes no difference to the code generated by the backend, there is no target flag for it, no target switch, and no reference to it anywhere except in the specs), it is simply the case that cygwin does not implement or support the functionality in question; there is no equivalent cygwin link library.

  So, given that cygwin does *not* support -mthread and does *not* define _MT, I don't see any reason why #ifdef _MT / #ifndef _MT won't do the exactly correct thing on all platforms.

  Hence I am closing this 3-year old PR as invalid, just to tidy up Bugzila a little.  Sorry for any surprise caused by seeing this ghost of the past coming at you from out of nowhere!

    cheers,
      DaveK
Comment 12 Dave Korn 2007-05-02 15:41:27 UTC
Sorry for the repeated emails, bugzilla wouldn't let me verify and close this bug without forcing me to add a comment.