Re: [Mingw-w64-public] format check broken
On 5/3/2013 10:05, Jim Michaels wrote:
sorry, my yahoo mail can only top-post, so don't email me about that. still
investigating this problem.
when I try
#include cstdio
#include stdint.h
int main(void) {
int64_t maxi=0x7fffLL;
int64_t mini=0xLL;
//__int128 i=0x7fff;//gives error
printf(0x7fffLL=%I64d\n, maxi);//gives warning about int
printf(0xLL=%I64d\n, mini);//gives warning about int
//printf(0x7fff=%I128d\n, i); //gives error
return 0;
}
I64.cpp:7:48: warning: format '%d' expects argument of type 'int', but
argument 2 has type 'int64_t {aka long long int}' [-Wformat=]
I64.cpp:8:48: warning: format '%d'
expects argument of type 'int', but argument 2 has type 'int64_t {aka long
long int}' [-Wformat=]
%I64d does not completely work for me without warnings.
If you use -D__MINGW_USE_ANSI_STDIO=1, use %lld.
If you DO NOT USE -D__MINGW_USE_ANSI_STDIO=1, use %I64d.
There is no 128bit print yet.
signature.asc
Description: OpenPGP digital signature
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with 2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] format check broken
Hi JonY, If you use -D__MINGW_USE_ANSI_STDIO=1, use %lld. If you DO NOT USE -D__MINGW_USE_ANSI_STDIO=1, use %I64d. Tell me please, what can be reasons to use '%I64d' and do not use '-D__MINGW_USE_ANSI_STDIO=1' ? I'm just curious, why not just use the GNU style format string? Thanks. -- Regards, niXman ___ Dual-target(32 64-bit) MinGW compilers for 32 and 64-bit Windows: http://sourceforge.net/projects/mingwbuilds/ ___ Another online IDE: http://liveworkspace.org/ -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] format check broken
I'm just curious, why not just use the GNU style format string? I'm just curious, why not just use the GNU style format string _by_default_? -- Regards, niXman ___ Dual-target(32 64-bit) MinGW compilers for 32 and 64-bit Windows: http://sourceforge.net/projects/mingwbuilds/ ___ Another online IDE: http://liveworkspace.org/ -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] format check broken
On Fri, May 3, 2013 at 12:51 PM, niXman i.nix...@gmail.com wrote: Hi JonY, If you use -D__MINGW_USE_ANSI_STDIO=1, use %lld. If you DO NOT USE -D__MINGW_USE_ANSI_STDIO=1, use %I64d. Tell me please, what can be reasons to use '%I64d' and do not use '-D__MINGW_USE_ANSI_STDIO=1' ? I'm just curious, why not just use the GNU style format string? One may want to avoid mingw-provided print routines, which are linked statically, and want to use the ones from msvcrt.dll (which is shared code). Personally, I always use windows-native stuff, e.g. %I64 in cases such as this, but yes it may be hard to do so when porting posix and/or c99- compliant code which rely on pure conformance. Thanks. -- Regards, niXman -- O.S. -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] format check broken
于 2013/5/3 星期五 17:59, Ozkan Sezer 写道: On Fri, May 3, 2013 at 12:51 PM, niXman i.nix...@gmail.com wrote: Hi JonY, If you use -D__MINGW_USE_ANSI_STDIO=1, use %lld. If you DO NOT USE -D__MINGW_USE_ANSI_STDIO=1, use %I64d. Tell me please, what can be reasons to use '%I64d' and do not use '-D__MINGW_USE_ANSI_STDIO=1' ? I'm just curious, why not just use the GNU style format string? One may want to avoid mingw-provided print routines, which are linked statically, and want to use the ones from msvcrt.dll (which is shared code). Personally, I always use windows-native stuff, e.g. %I64 in cases such as this, but yes it may be hard to do so when porting posix and/or c99- compliant code which rely on pure conformance. Thanks. -- Regards, niXman -- O.S. Kai wants to set it by default on MinGW(64) -- Hi, this patch enables the POSIX-printf variant for mingw-hosts by default. ChangeLog 2013-03-22 Kai Tietzkti...@redhat.com * config/i386/xm-mingw32.h (__USE_MINGW_ANSI_STDIO): Enable POSIX-printf for mingw-hosted builds. Tested for i686-w64-mingw32, and x86_64-w64-mingw32. I will apply tomorrow, if there aren't any objections by other Windows-maintainers. Regards, Kai Index: gcc/config/i386/xm-mingw32.h === --- gcc/config/i386/xm-mingw32.h(Revision 196898) +++ gcc/config/i386/xm-mingw32.h(Arbeitskopie) @@ -29,6 +29,12 @@ along with GCC; see the file COPYING3. If not see /* The st_ino field of struct stat is always 0. */ #define HOST_LACKS_INODE_NUMBERS +#ifdef __MINGW32__ +#undef __USE_MINGW_ANSI_STDIO +#define __USE_MINGW_ANSI_STDIO 1 +#else /* MSVCRT does not support the ll format specifier for printing long long values. Instead, we use I64. */ #define HOST_LONG_LONG_FORMAT I64 +#endif + -- Best Regards, xunxun -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] format check broken
On Fri, May 3, 2013 at 1:09 PM, xunxun xunxun1...@gmail.com wrote: 于 2013/5/3 星期五 17:59, Ozkan Sezer 写道: On Fri, May 3, 2013 at 12:51 PM, niXman i.nix...@gmail.com wrote: Hi JonY, If you use -D__MINGW_USE_ANSI_STDIO=1, use %lld. If you DO NOT USE -D__MINGW_USE_ANSI_STDIO=1, use %I64d. Tell me please, what can be reasons to use '%I64d' and do not use '-D__MINGW_USE_ANSI_STDIO=1' ? I'm just curious, why not just use the GNU style format string? One may want to avoid mingw-provided print routines, which are linked statically, and want to use the ones from msvcrt.dll (which is shared code). Personally, I always use windows-native stuff, e.g. %I64 in cases such as this, but yes it may be hard to do so when porting posix and/or c99- compliant code which rely on pure conformance. Thanks. -- Regards, niXman -- O.S. Kai wants to set it by default on MinGW(64) -- Hi, this patch enables the POSIX-printf variant for mingw-hosts by default. ChangeLog 2013-03-22 Kai Tietzkti...@redhat.com * config/i386/xm-mingw32.h (__USE_MINGW_ANSI_STDIO): Enable POSIX-printf for mingw-hosted builds. Tested for i686-w64-mingw32, and x86_64-w64-mingw32. I will apply tomorrow, if there aren't any objections by other Windows-maintainers. Regards, Kai Index: gcc/config/i386/xm-mingw32.h === --- gcc/config/i386/xm-mingw32.h(Revision 196898) +++ gcc/config/i386/xm-mingw32.h(Arbeitskopie) @@ -29,6 +29,12 @@ along with GCC; see the file COPYING3. If not see /* The st_ino field of struct stat is always 0. */ #define HOST_LACKS_INODE_NUMBERS +#ifdef __MINGW32__ +#undef __USE_MINGW_ANSI_STDIO +#define __USE_MINGW_ANSI_STDIO 1 +#else /* MSVCRT does not support the ll format specifier for printing long long values. Instead, we use I64. */ #define HOST_LONG_LONG_FORMAT I64 +#endif + -- Best Regards, xunxun Aside from the fact that I don't get the relevance of __MINGW32__ check (didn't look at the code), that patch seems to affect gcc's own code and not any user code being compiled against mingw. Am I wrong? -- O.S. -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] format check broken
2013/5/3 Ozkan Sezer seze...@gmail.com: On Fri, May 3, 2013 at 1:09 PM, xunxun xunxun1...@gmail.com wrote: 于 2013/5/3 星期五 17:59, Ozkan Sezer 写道: On Fri, May 3, 2013 at 12:51 PM, niXman i.nix...@gmail.com wrote: Hi JonY, If you use -D__MINGW_USE_ANSI_STDIO=1, use %lld. If you DO NOT USE -D__MINGW_USE_ANSI_STDIO=1, use %I64d. Tell me please, what can be reasons to use '%I64d' and do not use '-D__MINGW_USE_ANSI_STDIO=1' ? I'm just curious, why not just use the GNU style format string? One may want to avoid mingw-provided print routines, which are linked statically, and want to use the ones from msvcrt.dll (which is shared code). Personally, I always use windows-native stuff, e.g. %I64 in cases such as this, but yes it may be hard to do so when porting posix and/or c99- compliant code which rely on pure conformance. Thanks. -- Regards, niXman -- O.S. Kai wants to set it by default on MinGW(64) -- Hi, this patch enables the POSIX-printf variant for mingw-hosts by default. ChangeLog 2013-03-22 Kai Tietzkti...@redhat.com * config/i386/xm-mingw32.h (__USE_MINGW_ANSI_STDIO): Enable POSIX-printf for mingw-hosted builds. Tested for i686-w64-mingw32, and x86_64-w64-mingw32. I will apply tomorrow, if there aren't any objections by other Windows-maintainers. Regards, Kai Index: gcc/config/i386/xm-mingw32.h === --- gcc/config/i386/xm-mingw32.h(Revision 196898) +++ gcc/config/i386/xm-mingw32.h(Arbeitskopie) @@ -29,6 +29,12 @@ along with GCC; see the file COPYING3. If not see /* The st_ino field of struct stat is always 0. */ #define HOST_LACKS_INODE_NUMBERS +#ifdef __MINGW32__ +#undef __USE_MINGW_ANSI_STDIO +#define __USE_MINGW_ANSI_STDIO 1 +#else /* MSVCRT does not support the ll format specifier for printing long long values. Instead, we use I64. */ #define HOST_LONG_LONG_FORMAT I64 +#endif + -- Best Regards, xunxun Aside from the fact that I don't get the relevance of __MINGW32__ check (didn't look at the code), that patch seems to affect gcc's own code and not any user code being compiled against mingw. Am I wrong? -- O.S. You are right. That patch affects gcc's own compilation only. It doesn't affects user-code. Nevertheless for libstdc++-v3 uses - starting with 4.8 - by default POSIX-printf due it relies badly on this behavior internally. Kai -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] format check broken
On Fri, May 3, 2013 at 1:23 PM, Kai Tietz ktiet...@googlemail.com wrote: 2013/5/3 Ozkan Sezer seze...@gmail.com: On Fri, May 3, 2013 at 1:09 PM, xunxun xunxun1...@gmail.com wrote: 于 2013/5/3 星期五 17:59, Ozkan Sezer 写道: On Fri, May 3, 2013 at 12:51 PM, niXman i.nix...@gmail.com wrote: Hi JonY, If you use -D__MINGW_USE_ANSI_STDIO=1, use %lld. If you DO NOT USE -D__MINGW_USE_ANSI_STDIO=1, use %I64d. Tell me please, what can be reasons to use '%I64d' and do not use '-D__MINGW_USE_ANSI_STDIO=1' ? I'm just curious, why not just use the GNU style format string? One may want to avoid mingw-provided print routines, which are linked statically, and want to use the ones from msvcrt.dll (which is shared code). Personally, I always use windows-native stuff, e.g. %I64 in cases such as this, but yes it may be hard to do so when porting posix and/or c99- compliant code which rely on pure conformance. Thanks. -- Regards, niXman -- O.S. Kai wants to set it by default on MinGW(64) -- Hi, this patch enables the POSIX-printf variant for mingw-hosts by default. ChangeLog 2013-03-22 Kai Tietzkti...@redhat.com * config/i386/xm-mingw32.h (__USE_MINGW_ANSI_STDIO): Enable POSIX-printf for mingw-hosted builds. Tested for i686-w64-mingw32, and x86_64-w64-mingw32. I will apply tomorrow, if there aren't any objections by other Windows-maintainers. Regards, Kai Index: gcc/config/i386/xm-mingw32.h === --- gcc/config/i386/xm-mingw32.h(Revision 196898) +++ gcc/config/i386/xm-mingw32.h(Arbeitskopie) @@ -29,6 +29,12 @@ along with GCC; see the file COPYING3. If not see /* The st_ino field of struct stat is always 0. */ #define HOST_LACKS_INODE_NUMBERS +#ifdef __MINGW32__ +#undef __USE_MINGW_ANSI_STDIO +#define __USE_MINGW_ANSI_STDIO 1 +#else /* MSVCRT does not support the ll format specifier for printing long long values. Instead, we use I64. */ #define HOST_LONG_LONG_FORMAT I64 +#endif + -- Best Regards, xunxun Aside from the fact that I don't get the relevance of __MINGW32__ check (didn't look at the code), that patch seems to affect gcc's own code and not any user code being compiled against mingw. Am I wrong? -- O.S. You are right. That patch affects gcc's own compilation only. It doesn't affects user-code. Nevertheless for libstdc++-v3 uses - starting with 4.8 - by default POSIX-printf due it relies badly on this behavior internally. Even then, it affects libstdc++ compilation itself. IMO, mingw[-w64] should not default to __USE_MINGW_ANSI_STDIO=1 by itself and leave the decision to user (which is what we already do at present.) Kai -- O.S. -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] format check broken
On 5/3/2013 20:12, Ozkan Sezer wrote: You are right. That patch affects gcc's own compilation only. It doesn't affects user-code. Nevertheless for libstdc++-v3 uses - starting with 4.8 - by default POSIX-printf due it relies badly on this behavior internally. Even then, it affects libstdc++ compilation itself. IMO, mingw[-w64] should not default to __USE_MINGW_ANSI_STDIO=1 by itself and leave the decision to user (which is what we already do at present.) IIRC it is required if C++11 is used due to the presence of print templates. signature.asc Description: OpenPGP digital signature -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] format check broken
On Fri, May 3, 2013 at 3:24 PM, JonY jo...@users.sourceforge.net wrote: On 5/3/2013 20:12, Ozkan Sezer wrote: You are right. That patch affects gcc's own compilation only. It doesn't affects user-code. Nevertheless for libstdc++-v3 uses - starting with 4.8 - by default POSIX-printf due it relies badly on this behavior internally. Even then, it affects libstdc++ compilation itself. IMO, mingw[-w64] should not default to __USE_MINGW_ANSI_STDIO=1 by itself and leave the decision to user (which is what we already do at present.) IIRC it is required if C++11 is used due to the presence of print templates. As I said, if the user is doing c++11, he should as well know that he needs __USE_MINGW_ANSI_STDIO=1, so it's a user thing. -- O.S. -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] format check broken
-Original Message- From: Ozkan Sezer [mailto:seze...@gmail.com] Sent: Friday, May 03, 2013 2:12 PM To: mingw-w64-public@lists.sourceforge.net Subject: Re: [Mingw-w64-public] format check broken [...] Even then, it affects libstdc++ compilation itself. IMO, mingw[-w64] should not default to __USE_MINGW_ANSI_STDIO=1 by itself and leave the decision to user (which is what we already do at present.) Since all newer versions of MSVC runtimes support e.g. %lldb I think having an ANSI compliant default would make IMO even more sense. Anyhow, isn't the problem that gcc on windows still defaults to win_printf? So even if your printf supports %lldb, it'll warn about it? Regards Kai -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] format check broken
-Original Message- From: Koehne Kai [mailto:kai.koe...@digia.com] Sent: Friday, May 03, 2013 2:29 PM To: mingw-w64-public@lists.sourceforge.net Subject: Re: [Mingw-w64-public] format check broken -Original Message- From: Ozkan Sezer [mailto:seze...@gmail.com] Sent: Friday, May 03, 2013 2:12 PM To: mingw-w64-public@lists.sourceforge.net Subject: Re: [Mingw-w64-public] format check broken [...] Even then, it affects libstdc++ compilation itself. IMO, mingw[-w64] should not default to __USE_MINGW_ANSI_STDIO=1 by itself and leave the decision to user (which is what we already do at present.) Since all newer versions of MSVC runtimes support e.g. %lldb I mean %lld, of course. Actually I am compiling lldb in the background, but for entirely different reasons ... I think having an ANSI compliant default would make IMO even more sense. Anyhow, isn't the problem that gcc on windows still defaults to win_printf? It's called ms_printf. :) So even if your printf supports %lldb, it'll warn about it? -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] format check broken
2013/5/3 Ozkan Sezer seze...@gmail.com On Fri, May 3, 2013 at 3:24 PM, JonY jo...@users.sourceforge.net wrote: On 5/3/2013 20:12, Ozkan Sezer wrote: You are right. That patch affects gcc's own compilation only. It doesn't affects user-code. Nevertheless for libstdc++-v3 uses - starting with 4.8 - by default POSIX-printf due it relies badly on this behavior internally. Even then, it affects libstdc++ compilation itself. IMO, mingw[-w64] should not default to __USE_MINGW_ANSI_STDIO=1 by itself and leave the decision to user (which is what we already do at present.) IIRC it is required if C++11 is used due to the presence of print templates. As I said, if the user is doing c++11, he should as well know that he needs __USE_MINGW_ANSI_STDIO=1, so it's a user thing. This is documented *nowhere* and far from obvious nor logical. But you're right. The right fix would be to make libstdc++ use the right printf only internally, but that is either some long macro defining a __GLIBCXX_PRINTF to use the MinGW-w64 POSIX version if possible. Although this would still screw up std::printf, which is probably the one used all over the place. In short, this is messy, but as Ozkan said, there is a way it works, which is better than nothing. /rant Ruben -- O.S. -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [OT] top posting from yahoo [WAS: format check broken]
On Thu, May 2, 2013 at 10:05 PM, Jim Michaels jmich...@yahoo.com wrote: sorry, my yahoo mail can only top-post, so don't email me about that. still investigating this problem. Yahoo mail has nothing to do with TOP posting. You have to configure and maneuver the cursor in the mail but it works just the same. Sure the client may put the cursor at the top of the page but the editor allows you to maneuver within the text. BTW, you shouldn't just do BOTTOM posting either, INLINE is what you want removing the unneeded quotes. -- Earnie -- https://sites.google.com/site/earnieboyd -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Partially missing posix clock support in winpthreads
Well int clock_getcpuclockid we miss. I think it is obvious that we
would like to provide it, so a patch to clock.c file would be desired
here. The patch for an implementation for this function takes for
sure less time as it took you to collect all those information. So
why you weren't providing one in you mail?
int clock_getcpuclockid(pid_t pid, clockid_t *clock_id)
{
/* TODO: we might want to check pid to verify process. */
(void) pid;
*clock_id = CLOCK_PROCESS_CPUTIME_ID;
return 0;
}
and as we are about it the
int pthread_getcpuclockid(pthread_t thread_id, clockid_t *clock_id)
function we could add here too. Implementation is nearly the same ...
and well we would be even capable to verify that thread_id is even
valid proper.
Kai
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with 2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [RFC] Change the default size of time_t and off_t
Since Visual C++ 2005 (released in November 2005), time_t is now a 64-bit integer by default [1] . But mingw-w64 still use 32-bit integer by default on 32 bit Windows. I recommend use 64-bit integer by default on 3.0 CRT. mingw-w64 use off_t 32-bit integer on 64 bit Windows, I think this is a mistake. [1] http://msdn.microsoft.com/en-us/library/3b2e7499.aspx -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [RFC] Change the default size of time_t and off_t
2013/5/3 Dongsheng Song dongsheng.s...@gmail.com Since Visual C++ 2005 (released in November 2005), time_t is now a 64-bit integer by default [1] . But mingw-w64 still use 32-bit integer by default on 32 bit Windows. I recommend use 64-bit integer by default on 3.0 CRT. I agree with the spirit of this change, but... 1) This will break a ton of mingw-specific code 2) this requires mingw-w64 to provide a ton of code wrapping the newer-than-msvcrt.dll functions 3) This is an all-or-nothing thing: you can't pick what functions you take from the newer ones, and only implement a few. Now we can say: look at MSDN for VS2003. If that changes, that's not good. 4) I suggest at least delaying this to 4.0, 3.0 should really be released. Unless I'm mistaken on the effort it would take to actually make this work, b this meaning, switching all MinGW-w64 C API to be on-par with MSVS2005 or some other one, without requiring the redistributable (although I see no shame in requiring this to be installed, others might). mingw-w64 use off_t 32-bit integer on 64 bit Windows, I think this is a mistake. [1] http://msdn.microsoft.com/en-us/library/3b2e7499.aspx As I said above, you should be reading http://msdn.microsoft.com/en-us/library/3b2e7499%28v=vs.71%29.aspx for anything MinGW-w64 CRT related (unless it concerns POSIX stuff MinGW-w64 provides). Ruben -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Partially missing posix clock support in winpthreads
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03.05.2013 18:11, Kai Tietz wrote:
Well int clock_getcpuclockid we miss. I think it is obvious that we
would like to provide it, so a patch to clock.c file would be desired
here. The patch for an implementation for this function takes for
sure less time as it took you to collect all those information. So
why you weren't providing one in you mail?
int clock_getcpuclockid(pid_t pid, clockid_t *clock_id)
{
/* TODO: we might want to check pid to verify process. */
(void) pid;
*clock_id = CLOCK_PROCESS_CPUTIME_ID;
return 0;
}
and as we are about it the
This is wrong.
Correct stub is:
int
clock_getcpuclockid (pid_t pid, clockid_t *clock_id)
{
if (0 == pid)
{
/* Calling with 0 pid is the same as using
* CLOCK_PROCESS_CPUTIME_ID.
*/
*clock_id = CLOCK_PROCESS_CPUTIME_ID;
return 0;
}
/* Special clock values for getting time of other
* processes are not supported yet.
*/
errno = ENOSYS;
return ENOSYS;
}
Whether it could be correctly implemented or not - i can't tell. Maybe
if you restrict the CLOCK_* constants to a particular range, and then
use special pid+CLOCK_PROCESS_MAX_ID constants...that might just work
(as long as pid is less than (MAX_PID_T - CLOCK_PROCESS_MAX_ID)).
- --
O ascii ribbon - stop html email! - www.asciiribbon.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)
iQEcBAEBAgAGBQJRhAlIAAoJEOs4Jb6SI2CwR4oIAIiLnfe0MhR1XcFxXoCQxUfQ
vAlHxdkOXhebCm/6q9LwX/U9j1lkZa7sP7HM4vWS6/L6M/D19c0vQNVoI3FYefga
g0heuQaqCMQPI6xkoYTZEK643l41F8HKWsGVzeIHqmEAzvWIu5U5K1dzDbBekC5g
D1sGDrvUizSH5qtHKxn+d5e846eeMDq5JngsnpZaMeIwA8/cpi9wT+wcneVg9Xt7
ejSI4/ruxOJHUGpIQnkmJizNffESXhpU5A1D3NeIITY/UeXTCa3LkqMXYoFUnpzK
4YsDB0Z/JwI+KBfoFfHz5mbS6DrfjWwPhzjTKnP//6hpAlspPg+LId7tr8PCLHU=
=Jf3g
-END PGP SIGNATURE-
--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with 2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] OpenMP-related hangup with winpthreads
--with-arch=pentium4 --with-tune=core-avx-i
I only use it for some popurse or perf. (Some lto needs -msse2, or will
cause compiler ICE.)
--enable-cxx-flags='-fno-function-sections -fno-data-sections'
At present, MinGW target linker can't support --gc-sections, so
-fno-function-sections -fno-data-sections is not effective, and will
increase code size.
Kai has a patch to solve it, but after my test, something is wrong with
gcc4.7, I will check it again some time.
Ruben has explained other options.
And I don't know where is your problem, can you try my built :
http://pcxprj.googlecode.com/files/MinGW64CRT_gcc4.7.3release_sse2static_win32.7z
On Fri, May 3, 2013 at 1:53 AM, LRN lrn1...@gmail.com wrote:
On 01.05.2013 18:56, xunxun wrote:
于 2013/5/1 星期三 21:15, LRN 写道:
On 01.05.2013 10:32, xunxun wrote:
On Wed, May 1, 2013 at 3:13 AM, LRN lrn1...@gmail.com wrote:
On 30.04.2013 19:18, xunxun wrote:
于 2013/4/24 星期三 19:12, LRN 写道:
msgmerge.exe (from gettext, i guess) hangs up, consuming 100% of a
CPU
core, this is the backtrace:
#0 0x74d53b64 in SleepEx () from C:\Windows\syswow64\KernelBase.dll
#1 0x74d54498 in Sleep () from C:\Windows\syswow64\KernelBase.dll
#2 0x6494406b in _spin_lite_lock (l=0x64943003 mutex_ref+19) at
../winpthreads-svn-r5792/src/spinlock.c:256
#3 0x0001 in ?? ()
#4 0x64943003 in mutex_ref (m=0x11, m@entry=0x534fb4) at
../winpthreads-svn-r5792/src/mutex.c:60
#5 0x6494317f in pthread_mutex_lock_intern (timeout=4294967295,
m=0x534fb4) at ../winpthreads-svn-r5792/src/mutex.c:236
#6 pthread_mutex_lock (m=m@entry=0x534fb4) at
../winpthreads-svn-r5792/src/mutex.c:223
#7 0x64943482 in rwlock_gain_both_locks
(rwlock=rwlock@entry=0x534fa0) at
../winpthreads-svn-r5792/src/rwlock.c:107
#8 0x64943b5e in pthread_rwlock_wrlock
(rwlock_=rwlock_@entry=0x6494f08c) at
../winpthreads-svn-r5792/src/rwlock.c:430
#9 0x64944f26 in pthread_key_delete (key=0) at
../winpthreads-svn-r5792/src/thread.c:739
#10 0x6360da61 in team_destructor () from
f:\s31\mingw\bin\libgomp-1.dll
#11 0x in ?? ()
I'm using an svn-r5792 version of winpthreads + libgomp patches from
ktietz.
Where is the libgomp patches?
He pastebinned that patch at 2013-04-22 15:24:19 (that pastebin is
no longer alive, so i've attached the copy that i've got back then).
And what's your gettext configure option?
I don't know whether gettext has one option which can only use
pthread lib but not use openmp.
- --prefix=${prefix} \
- --enable-shared --enable-static --enable-silent-rules \
- --enable-threads=win32 \
- --with-included-gettext --with-included-glib --with-included-libcroco
\
- --with-included-unistring --with-included-libxml \
- --disable-rpath \
- --without-emacs --disable-native-java --disable-curses \
and i've added --disable-openmp for now, to work around this problem.
Now that you've mentioned it, maybe i should use --enable-threads=posix
with openmp?
Maybe using posix thread is right.
And I use my built gettext, but can't reproduce the issue (when running
msgmerge.exe --update -q nul nul)
I use static winpthread and static posix gcc 4.7.3.
My gettext configure option is :
./configure --prefix=/mingw/gettext \
--disable-shared --enable-static \
--enable-threads=posix \
--with-included-gettext --with-included-glib --with-included-libcroco
\
--with-included-unistring --with-included-libxml \
--disable-rpath --disable-nls \
--without-emacs --disable-native-java --disable-curses \
--enable-relocate
My winpthread configure option is :
./configure --prefix=/mingw --host=i686-w64-mingw32
--build=i686-w64-mingw32 --target=i686-w64-mingw32 --enable-static
--disable-shared
My gcc configure option is :
../gcc-4.7.3/configure --prefix=/mingw \
--with-arch=pentium4 --with-tune=core-avx-i \
--build=i686-w64-mingw32 --host=i686-w64-mingw32
--target=i686-w64-mingw32 \
--with-lto-plugin --with-host-libstdcxx=-lstdc++
--disable-bootstrap --disable-werror \
--enable-languages=c,c++,fortran --enable-libgomp
--enable-threads=posix --enable-libstdcxx-threads
--enable-libstdcxx-time --enable-lto --with-system-zlib --with-libiconv \
--enable-version-specific-runtime-libs
--enable-fully-dynamic-string --disable-libstdcxx-pch
--disable-libstdcxx-debug --enable-graphite \
--disable-sjlj-exceptions --with-dwarf2 --disable-symvers
--enable-checking=release --enable-cxx-flags='-fno-function-sections
-fno-data-sections' \
--enable-cloog-backend=isl --disable-shared --enable-static
--disable-win32-registry --disable-rpath --enable-plugins \
--enable-libquadmath-support --enable-libquadmath
--disable-multilib --disable-ppl-version-check
--disable-cloog-version-check --with-gnu-as --with-gnu-ld \
--disable-nls
Re: [Mingw-w64-public] OpenMP-related hangup with winpthreads
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04.05.2013 06:39, xunxun wrote: And I don't know where is your problem, can you try my built : http://pcxprj.googlecode.com/files /MinGW64CRT_gcc4.7.3release_sse2static_win32.7z I'm gearing towards 4.8.0, and shared. 4.8.0 is not really a requirement (new version has some nice properties, but i can live with 4.7.x as well), but shared is. - -- O ascii ribbon - stop html email! - www.asciiribbon.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJRhHlpAAoJEOs4Jb6SI2CwoHAH/3IuAc8NTfV3QUJ9Gc31D2TY qbBB8oz/5hMkYHdGNd5IkUriwdRLs49GGGnYvp5GLiLQhQ/iDB57KVZknwZ63w7g JTgFyiTbySHvPvDMAlVEMTLIAH5idubRCpRjCxRn5C94UVKdUUx4af2Qd92caIgK 4Z3Lg5csmhc90BcQc7m+aJ9EPz4OF2sNW2CDHOFEyCu5xw2xk55WO90CrxdBFPlj 8LF4jzxgilnKHDCn+xu6Inp2TkOdGU+C/smu/FLqn9kxdn1riAfoGe+EeJXoeAMt OOIAiCRsnScMb5uDRqd/bpFMqTNCieCgq6bUFjrEGFl7M5L/JyHO1svGxKZQi48= =HRmu -END PGP SIGNATURE- -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
