[Mingw-w64-public] 64 bits cygwin gcc produces wrong constants with mingw win32 headers.

[Nicolas Noble]

Hello,

  I've been following breadcrumbs now about that issue, and I finally
ended up here. I have reported that issue already on msys2 and on
cygwin (see https://github.com/Alexpux/MSYS2-packages/issues/555 and
https://cygwin.com/ml/cygwin/2016-04/msg00379.html).

  The problem I see is that the w32api-headers package available on
cygwin originates from mingw, and sometime will do the wrong thing
when compiling a 64 bits cygwin binary that uses the win32 API,
because in 64 bits, with cygwin gcc, sizeof(long) == 8.

  As an example of what I am talking about is the definition of
FIONBIO in winsock2.h. Using cygwin's gcc, we end up with a value of
0x8008667e in 64 bits, whereas the correct value is 0x8004667e,
because it's using sizeof(u_long) in its definition.

  Corinna Vinschen over in cygwin suggested that this might be
something the mingw-w64 team might want to look at, possibly by
replacing these definitions with sizeof(__ms_u_long):
https://cygwin.com/ml/cygwin/2016-04/msg00383.html

  Thanks!

  -- Nicolas Noble

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Adding a new thread model to GCC

[lh_mouse]

>>> If the current code assumes a struct and the Windows API calls need an
>>> integer then either the existing code needs to be made more flexible,
>>> or you need to define it as a struct and then convert to an integer
>>> inside your new gthread wrapper functions.
>>
>> The Windows APIs involved use LARGE_INTEGER - a union of a 64-bit integer 
>> and an array of two 32-bit integers - because some languages might have no 
>> native 64-bit integer types.
>> Actually in C99 and C++11 we just assume there is long long and int64_t 
>> despite the fact that ISO C marks int64_t as optional, so it can be regarded 
>> as a union whose only element is an int64_t.
>> 
> What are the units of the argument? Milliseconds?

>From Windows SDK:
  File Times
  A file time is a 64-bit value that represents the number of 100-nanosecond 
intervals that have elapsed since 12:00 A.M. January 1, 1601 Coordinated 
Universal Time (UTC).

This decision makes it much easier to count leap years, no?

> You have two choices, either modify all the places in libstdc++ that
> use __gthread_time_t, changing the code to use some new function
> template that populates a __gthread_time_t from a
> std::chrono::time_point or std::chrono::duration, or define
> a similar struct in your gthreads header and convert it to int64_t
> inside your functions.  For functions taking a relative time the
> conversion from a { seconds, nanoseconds } struct to milliseconds is
> trivial, for functions taking an absolute time you need to know the
> epoch of the clock that was used when populating the struct.

Will do that next week. Still need to make gcc work with my library.

--   
Best regards,
lh_mouse
2016-04-18



--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Adding a new thread model to GCC

[Jonathan Wakely]

On 18 April 2016 at 10:57, Jonathan Wakely wrote:
> On 18 April 2016 at 10:18, lh_mouse wrote:
>>> I don't see why it has to be a struct, it just has to be suitable as
>>> an argument to the relevant __gthread functions.
>>
>> The type __gthread_time_t is referenced in 
>> gcc/libstdc++-v3/include/std/mutex:157
>>   __gthread_time_t __ts = {
>> static_cast(__s.time_since_epoch().count()),
>> static_cast(__ns.count())
>>   };
>> This definition uses a braced-init-list that has two elements and is 
>> unsuitable for scalar types.
>
> Yes I know.
>
> What I meant is that there's no fundamental reason it needs to be a
> struct. That code could be changed.

However, that code in  is only needed for timed mutexes, and I
thought you said that wouldn't be supported.

There is code using __gthread_time_t in  that
needs to work even if timed mutexes are not supported.

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Adding a new thread model to GCC

[lh_mouse]

Oh I missed the build-in specs in gcc/config/i386/mingw32.h and it was lack of 
-lmcfgthread in it that caused the failure. Stage 1 seemed ok.
Already hacked that. Rebuilding.

Apologize for that.

--   
Best regards,
lh_mouse
2016-04-18

-
发件人：Jonathan Wakely 
发送日期：2016-04-18 16:59
收件人：lh_mouse
抄送：gcc,mingw-w64-public
主题：Re: Re: Adding a new thread model to GCC

On 18 April 2016 at 08:39, lh_mouse wrote:
> I have added a thread model and added its corresponding header files. But it 
> failed the linker.
>
> The file 'gcc/libgcc/config/i386/t-mingw-pthread' which contained two lines:
>   SHLIB_PTHREAD_CFLAG = -pthread
>   SHLIB_PTHREAD_LDFLAG = -Wl,-lpthread
>
> I copied the file to 'gcc/libgcc/config/i386/t-mingw-mcfgthread' and modified 
> the two lines to:
>   SHLIB_PTHREAD_CFLAG = -lmcfgthread
>   SHLIB_PTHREAD_LDFLAG = -Wl,-lmcfgthread
>
> It didn't work and I got a number of undefined references. The command line 
> that invoked the linker didn't include either option.
>
> How to solve this problem?

What are the linker errors? When do they happen?



--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Adding a new thread model to GCC

[Jonathan Wakely]

On 18 April 2016 at 08:39, lh_mouse wrote:
> I have added a thread model and added its corresponding header files. But it 
> failed the linker.
>
> The file 'gcc/libgcc/config/i386/t-mingw-pthread' which contained two lines:
>   SHLIB_PTHREAD_CFLAG = -pthread
>   SHLIB_PTHREAD_LDFLAG = -Wl,-lpthread
>
> I copied the file to 'gcc/libgcc/config/i386/t-mingw-mcfgthread' and modified 
> the two lines to:
>   SHLIB_PTHREAD_CFLAG = -lmcfgthread
>   SHLIB_PTHREAD_LDFLAG = -Wl,-lmcfgthread
>
> It didn't work and I got a number of undefined references. The command line 
> that invoked the linker didn't include either option.
>
> How to solve this problem?

What are the linker errors? When do they happen?

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Adding a new thread model to GCC

[Jonathan Wakely]

On 17 April 2016 at 17:56, lh_mouse  wrote:
> A glance over gthr.h reminds me __gthread_time_t. There seem few requirements 
> documented in gthr.h.
> I discussed this with Adrien Nader on mingw-w64's mailing list a few days ago.
>
> Specifically, here are the two questions:
> 0) Should __gthread_time_t be a struct or a plain integral type?
> The 'struct timespec' used by pthread is a struct introduced in POSIX.
> However my implementation uses a plain uint64_t.

I don't see why it has to be a struct, it just has to be suitable as
an argument to the relevant __gthread functions.

If the current code assumes a struct and the Windows API calls need an
integer then either the existing code needs to be made more flexible,
or you need to define it as a struct and then convert to an integer
inside your new gthread wrapper functions.


> 1) How to obtain a __gthread_time_t representing the current time?
> According to Linux man pages, the timeout parameter of 
> pthread_cond_timedwait() is the same as gettimeofday() - that is, it uses the 
> wall clock.
> My implementation uses GetTickCount64() - that is, my implementation uses a 
> monotonic clock.

std::condition_variable::__clock_t must be a typedef for the clock
used by the underlying implementation, so it sounds like you should
use std::chrono::steady_clock for your thread model.


> Quoting from ISO/IEC WG21 Draft N4582 (C++1z):
> [quote]
> 30.4.1.3.1 Class timed_mutex [thread.timedmutex.class]
> ...
> template 
> bool try_lock_for(const chrono::duration& rel_time);
> template 
> bool try_lock_until(const chrono::time_point& abs_time);
> ...
> [/quote]
> the std::timed_mutex::try_lock_for() function template shall accept any clock 
> type, hence we have to do timestamp translation. It is also important to know 
> how libstdc++ handles this.

All conversions are done using the std::chrono facilities, before any
conversion to __gthread_time_t. That means the conversions are
portable.

--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Adding a new thread model to GCC

[lh_mouse]

I have added a thread model and added its corresponding header files. But it 
failed the linker.

The file 'gcc/libgcc/config/i386/t-mingw-pthread' which contained two lines:
  SHLIB_PTHREAD_CFLAG = -pthread
  SHLIB_PTHREAD_LDFLAG = -Wl,-lpthread

I copied the file to 'gcc/libgcc/config/i386/t-mingw-mcfgthread' and modified 
the two lines to:
  SHLIB_PTHREAD_CFLAG = -lmcfgthread
  SHLIB_PTHREAD_LDFLAG = -Wl,-lmcfgthread

It didn't work and I got a number of undefined references. The command line 
that invoked the linker didn't include either option.

How to solve this problem?

--   
Best regards,
lh_mouse
2016-04-18
--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public