[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #38 from Terry Guo --- (In reply to Kai Tietz from comment #37) > I confirm that in libgcc we still have an issue ... > Could you please make a new report for libgcc's libgcov-util.c for it. > > Thanks in advance Reported it at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65038. Not sure we can mark them as duplication.
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #37 from Kai Tietz --- I confirm that in libgcc we still have an issue ... Could you please make a new report for libgcc's libgcov-util.c for it. Thanks in advance
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #36 from Kai Tietz --- Well, I guess that you missed to reconfigure gcc. By checking current source is the include of ftw.h guarded by HAVE_FTW_H check, which get defined by configure if header is found.
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 Terry Guo changed: What|Removed |Added CC||terry.guo at arm dot com --- Comment #35 from Terry Guo --- I am building trunk for mingw and still having issue: /home/build/work/GCC-5-0-build/src/gcc/gcc/../libgcc/libgcov-util.c:55:17: fatal error: ftw.h: No such file or directory compilation terminated. make[1]: *** [libgcov-util.o] Error 1 Is this something we just missed?
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 Kai Tietz changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #34 from Kai Tietz --- Fixed.
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #33 from Kai Tietz --- Author: ktietz Date: Tue Feb 10 14:14:58 2015 New Revision: 220584 URL: https://gcc.gnu.org/viewcvs?rev=220584&root=gcc&view=rev Log: 2015-02-10 Rainer Emrich PR gcov-profile/61889 * gcov-tool.c: Remove wrong #if !defined(_WIN32) Modified: trunk/gcc/ChangeLog trunk/gcc/gcov-tool.c
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #32 from Kai Tietz --- Author: ktietz Date: Tue Feb 10 14:13:13 2015 New Revision: 220582 URL: https://gcc.gnu.org/viewcvs?rev=220582&root=gcc&view=rev Log: 2015-02-10 Rainer Emrich PR gcov-profile/61889 * libgcc/libgcov-driver-system.c: undefine clashing macro for mkdir. Modified: trunk/libgcc/ChangeLog trunk/libgcc/libgcov-driver-system.c
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #31 from Rainer Emrich --- (In reply to Kai Tietz from comment #30) > Yes, this patch slipped under my radar. It would be good if you - Rainer - > would have pinged on it. As far as I recalled I awaited at that time a full > patch by Rong on this subject. (See comment #16 and after that). Sorry, I had not much time the last few month. > Nevertheless patch looks ok. I will give it some testing and will apply it > after that. The change to undef mkdir in libgcc's part of the patch looks > to me being the real patch. The patch in gcc's part is more cosmetic part > getting rid of this (also mentioned to Rong too) wrong _WIN32 check. This part is necessary because otherwise the definition of the mkdir macro in system.h expects 2 arguments what isn't satisfied.
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #30 from Kai Tietz --- Yes, this patch slipped under my radar. It would be good if you - Rainer - would have pinged on it. As far as I recalled I awaited at that time a full patch by Rong on this subject. (See comment #16 and after that). Nevertheless patch looks ok. I will give it some testing and will apply it after that. The change to undef mkdir in libgcc's part of the patch looks to me being the real patch. The patch in gcc's part is more cosmetic part getting rid of this (also mentioned to Rong too) wrong _WIN32 check.
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #29 from Rainer Emrich --- Am 10.02.2015 12:12, schrieb jakub at gcc dot gnu.org: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 > > --- Comment #28 from Jakub Jelinek --- > http://gcc.gnu.org/ml/gcc-patches/2014-09/msg02137.html ? > Yes, that's it.
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #28 from Jakub Jelinek --- http://gcc.gnu.org/ml/gcc-patches/2014-09/msg02137.html ?
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #27 from Kai Tietz --- (In reply to Jakub Jelinek from comment #26) > Instead of the #undef mkdir you'd IMHO better just use (mkdir) (filename) > in the second case. > Anyway, if you've posted your patch to gcc-patches, you should be pinging it > until it is reviewed. Kai, can you please have a look? Sure, I will have a look. Was this patch sent to ML? If so I am sorry for not noticing it. Could you please ping it?
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #26 from Jakub Jelinek --- Instead of the #undef mkdir you'd IMHO better just use (mkdir) (filename) in the second case. Anyway, if you've posted your patch to gcc-patches, you should be pinging it until it is reviewed. Kai, can you please have a look?
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 Rainer Emrich changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #25 from Rainer Emrich --- (In reply to Jeffrey A. Law from comment #24) > Fixed by Trevor's patch to the trunk. We have a configure check for ftw.h > and if it's not found we disable things that are dependent on ftw. The issue described in comment 8 isn't solved at all!
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #24 from Jeffrey A. Law --- Fixed by Trevor's patch to the trunk. We have a configure check for ftw.h and if it's not found we disable things that are dependent on ftw.
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #23 from tbsaunde at gcc dot gnu.org --- Author: tbsaunde Date: Tue Feb 10 03:40:20 2015 New Revision: 220566 URL: https://gcc.gnu.org/viewcvs?rev=220566&root=gcc&view=rev Log: Support gcov-tool without ftw.h gcc/ PR gcov-profile/61889 * config.in: regenerate. * configure.in: Likewise. * configure.ac: Check for ftw.h. * gcov-tool.c: Check for ftw.h before using nftw. Modified: trunk/gcc/ChangeLog trunk/gcc/config.in trunk/gcc/configure trunk/gcc/configure.ac trunk/gcc/gcov-tool.c
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #22 from Jakub Jelinek --- So, can you just check for nftw with the arguments you want to use in a compile test in configure and if that fail, perhaps for now don't do that at all? The next step would be to provide in libiberty a nftw implementation for some or all targets that don't have it. mingw surely isn't the only problematic target.
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #21 from Kai Tietz --- (In reply to xur from comment #20) > Thanks for the comments. I'll work on this to get it fixed this time. > > Let me understand your idea correctly: > We will have two patches: The first one will check FTW-API and make > the gcov-tool build configurable. > if -disable-gcov-tool is specified, we will not build gcov-tool. > if -enable-gcov-tool is specified, we will build gcov-tool > if neither specified, we will check the FTW-API and build gcovtool if > FTW-API is available. No, we always check if FTW-API is present. The presence of FTW-API should have no impact on case that gcov-tool gets built, or not. Instead gcov-tool should take care that for cases where FTW-API isn't used the specific part of functionality (it is used for file-unlinking) is simply disabled. Otherwise the standard code-path should be used. Btw, as I already mentioned has mingw-w64 flavor the ftw/nftw API on its master version. And it works OOTB with current code. So no need to break that by assuming wild things in configure. > The second patch is to emulate FTW in libiberty for MINGW32? > I'm a little confused here. libiberty is built after the configure. Do > we need to a special handling of MINGW32 in config? Well, if we put that into libiberty, or put it in gcov-tool directly - I would assume that you alway have dependency to libiberty, otherwise you should add it for this tool, as it prevents you from reinventing the wheel again. Anyway this part is something different and should be handled via the ML and not via the bug-tracker. > Thanks, > > -Rong
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #20 from xur at google dot com --- Thanks for the comments. I'll work on this to get it fixed this time. Let me understand your idea correctly: We will have two patches: The first one will check FTW-API and make the gcov-tool build configurable. if -disable-gcov-tool is specified, we will not build gcov-tool. if -enable-gcov-tool is specified, we will build gcov-tool if neither specified, we will check the FTW-API and build gcovtool if FTW-API is available. The second patch is to emulate FTW in libiberty for MINGW32? I'm a little confused here. libiberty is built after the configure. Do we need to a special handling of MINGW32 in config? Thanks, -Rong On Mon, Oct 13, 2014 at 3:03 PM, ktietz at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 > > --- Comment #19 from Kai Tietz --- > Hi Xur, > > I asked you in my intial support to check for existance of FTW-API, and not to > implement it for Win32. > > So first, send patch checking in a valid way if API can be used. > > The ftw/nftw emulation you wrote seems to me more suitable for libiberty. And > again in most places the check for _WIN32 isn't right. You should check > instead for mingw-target, means for __MINGW32__ instead, as for cygwin this > macro might be defined in some circumstances. And make sure that you disable > code-paths only for mingw-targets iff we don't have the FTW-API. > > I would suggest to make out this patch 2 separate patches. > > -- > You are receiving this mail because: > You are the assignee for the bug.
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #19 from Kai Tietz --- Hi Xur, I asked you in my intial support to check for existance of FTW-API, and not to implement it for Win32. So first, send patch checking in a valid way if API can be used. The ftw/nftw emulation you wrote seems to me more suitable for libiberty. And again in most places the check for _WIN32 isn't right. You should check instead for mingw-target, means for __MINGW32__ instead, as for cygwin this macro might be defined in some circumstances. And make sure that you disable code-paths only for mingw-targets iff we don't have the FTW-API. I would suggest to make out this patch 2 separate patches.
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #18 from xur at google dot com --- This patch is after Kai Tietz's comment. and it does check the nfw headers. On Mon, Oct 13, 2014 at 2:40 PM, fxcoudert at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 > > --- Comment #17 from Francois-Xavier Coudert > --- > (In reply to xur from comment #16) >> I sent a patch to fix this, a few weeks ago, but I have got the review >> or approval. >> https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00186.html > > Kai Tietz, mingw maintainer, commented on it (comment #6 above) and it is not > OK as is (support should be checked, not hard-coded). > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #17 from Francois-Xavier Coudert --- (In reply to xur from comment #16) > I sent a patch to fix this, a few weeks ago, but I have got the review > or approval. > https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00186.html Kai Tietz, mingw maintainer, commented on it (comment #6 above) and it is not OK as is (support should be checked, not hard-coded).
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #16 from xur at google dot com --- I sent a patch to fix this, a few weeks ago, but I have got the review or approval. https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00186.html Honza, could you take a quick look? -Rong On Mon, Oct 13, 2014 at 12:29 PM, rai...@emrich-ebersheim.de wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 > > --- Comment #11 from Rainer Emrich --- > Dear friends this issue seems to become a never ending story. > In my understanding the person causing the issue is responsible for a fix. > There are several hints in this thread how to solve the issue. So please get > on > to it. > Otherwise we have a massive issue here. > And last but not least I don't see any reason why this bug has status WAITING. > If there is a solid reason please post it here. > > -- > You are receiving this mail because: > You are the assignee for the bug.
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #15 from StaffLeavers at arm dot com --- tony.wang no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #14 from StaffLeavers at arm dot com --- tony.wang no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 Francois-Xavier Coudert changed: What|Removed |Added Status|WAITING |NEW CC|tony.wang at arm dot com |
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #13 from StaffLeavers at arm dot com --- tony.wang no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #12 from StaffLeavers at arm dot com --- tony.wang no longer works for ARM. Your email will be forwarded to their line manager. Please do not reply to this email. If you need more information, please email real-postmas...@arm.com Thank you.
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #11 from Rainer Emrich --- Dear friends this issue seems to become a never ending story. In my understanding the person causing the issue is responsible for a fix. There are several hints in this thread how to solve the issue. So please get on to it. Otherwise we have a massive issue here. And last but not least I don't see any reason why this bug has status WAITING. If there is a solid reason please post it here.
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 Francois-Xavier Coudert changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #10 from Francois-Xavier Coudert --- Why is this 2.5 month old bug WAITING? Looks like a clear issue to me.
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #9 from Rainer Emrich --- Created attachment 33548 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33548&action=edit Proposed patch to fix the mingw case.
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889
--- Comment #8 from Rainer Emrich ---
(In reply to xur from comment #7)
> OK. I'll fix this and submit another patch.
What is the status for that?
>
> On Wed, Aug 20, 2014 at 11:26 AM, ktietz at gcc dot gnu.org
> wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889
> >
> > --- Comment #6 from Kai Tietz ---
> > Yes, I remember. I didn't comment on it.
> > The following checks aren't ok.
> > '#if !defined(_WIN32)'
> >
> > you should disable those parts *only* if ftw API isn't present. This you
> > should
> > check by a HAVE_FTW_H configure-check-macro. To disable it just because
> > _WIN32
> > is defined is wrong.
> >
Quoting Kai Tietz:
Issue got fixed on mingw-w64's side by providing on trunk ftw/nftw API.
Nevertheless there is still an issue with the use of "mkdir":
g++ -c -g -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables
-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format
-Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I.
-I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc
-I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc/.
-I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc/../include
-I./../intl
-I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc/../libcpp/include
-I/opt/devel/SCRATCH/tmp.Yed3qsDdVp/install/include
-I/opt/devel/SCRATCH/tmp.Yed3qsDdVp/install/include
-I/opt/devel/SCRATCH/tmp.Yed3qsDdVp/install/include
-I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc/../libdecnumber
-I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc/../libdecnumber/bid
-I../libdecnumber
-I../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc/../libbacktrace
-DCLOOG_INT_GMP -I/opt/devel/SCRATCH/tmp.Yed3qsDdVp/install/include
-DCLOOG_INT_GMP -I/opt/devel/SCRATCH/tmp.Yed3qsDdVp/install/include -o
gcov-tool.o -MT gcov-tool.o -MMD -MP -MF ./.deps/gcov-tool.TPo
../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc/gcov-tool.c
../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc/gcov-tool.c:95:21:
error: macro "mkdir" requires 2 arguments, but only 1 given
if (mkdir (out) == -1 && errno != EEXIST)
^
../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc/gcov-tool.c:
In function 'void gcov_output_files(const char*, gcov_info*)':
../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc/gcov-tool.c:95:27:
error: ISO C++ forbids comparison between pointer and integer [-fpermissive]
if (mkdir (out) == -1 && errno != EEXIST)
^
This clashes with the macro definition for mkdir in system.h:
/* Some systems have mkdir that takes a single argument. */
#ifdef MKDIR_TAKES_ONE_ARG
# define mkdir(a,b) mkdir (a)
#endif
Removing the wrong #if !defined(_WIN32) solves the issue for gcov-tool.c:
Index: gcc/gcov-tool.c
===
--- gcc/gcov-tool.c(Revision 215554)
+++ gcc/gcov-tool.c(Arbeitskopie)
@@ -89,11 +89,7 @@ gcov_output_files (const char *out, stru
/* Try to make directory if it doesn't already exist. */
if (access (out, F_OK) == -1)
{
-#if !defined(_WIN32)
if (mkdir (out, S_IRWXU | S_IRWXG | S_IRWXO) == -1 && errno != EEXIST)
-#else
- if (mkdir (out) == -1 && errno != EEXIST)
-#endif
fatal_error ("Cannot make directory %s", out);
} else
unlink_profile_dir (out);
At a second point the issue is more complex. In libgcc/libgcov-driver-system.c
there is the following code:
#ifdef TARGET_POSIX_IO
&& mkdir (filename, 0755) == -1
#else
&& mkdir (filename) == -1
#endif
libgcov-driver-system.c is used in two places, in the gcc directory and in the
the libgcc directory for libgcov. In the first case the macro for mkdir is
defined in the second it isn't.
An ugly hack solves this issue and lets me at least build gcc-5.0.0 on
x86_64-w64-mingw32.
Index: libgcc/libgcov-driver-system.c
===
--- libgcc/libgcov-driver-system.c(Revision 215554)
+++ libgcc/libgcov-driver-system.c(Arbeitskopie)
@@ -66,6 +66,9 @@ create_file_directory (char *filename)
#ifdef TARGET_POSIX_IO
&& mkdir (filename, 0755) == -1
#else
+#ifdef mkdir
+#undef mkdir
+#endif
&& mkdir (filename) == -1
#endif
/* The directory might have been made by another process. */
Someone with more insight should have a look on this, please!
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #7 from xur at google dot com --- OK. I'll fix this and submit another patch. On Wed, Aug 20, 2014 at 11:26 AM, ktietz at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 > > --- Comment #6 from Kai Tietz --- > Yes, I remember. I didn't comment on it. > The following checks aren't ok. > '#if !defined(_WIN32)' > > you should disable those parts *only* if ftw API isn't present. This you > should > check by a HAVE_FTW_H configure-check-macro. To disable it just because > _WIN32 > is defined is wrong. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #6 from Kai Tietz --- Yes, I remember. I didn't comment on it. The following checks aren't ok. '#if !defined(_WIN32)' you should disable those parts *only* if ftw API isn't present. This you should check by a HAVE_FTW_H configure-check-macro. To disable it just because _WIN32 is defined is wrong.
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 --- Comment #5 from xur at google dot com --- I sent a patch for this a few days ago: https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg87155.html It's pending review. Thanks, -Rong On Wed, Aug 20, 2014 at 10:36 AM, ktietz at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 > > Kai Tietz changed: > >What|Removed |Added > > Status|NEW |WAITING > Known to fail|4.10.0 |5.0 > > --- Comment #4 from Kai Tietz --- > Issue got fixed on mingw-w64's side by providing on trunk ftw/nftw API. > Nevertheless it would be good that for ftw include and use at least a > header-check is done. That gcov data isn't deleted isn't necessarily that > bad. > IMO better then disabling complete tool. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug gcov-profile/61889] [5 Regression] gcov-tool.c uses nftw, ftw.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61889 Kai Tietz changed: What|Removed |Added Status|NEW |WAITING Known to fail|4.10.0 |5.0 --- Comment #4 from Kai Tietz --- Issue got fixed on mingw-w64's side by providing on trunk ftw/nftw API. Nevertheless it would be good that for ftw include and use at least a header-check is done. That gcov data isn't deleted isn't necessarily that bad. IMO better then disabling complete tool.
