| Message ID | 20150921103620.GA49423@msticlxl57.ims.intel.com |
|---|---|
| State | New |
| Headers | show |
Dear Kirill, > When libgfortran is configured w/ HAVE_WORKING_STAT undefined > *and* current system is not MinGW - FIND_FILE_[DECL|ARGS} still > trying to use Windows's handles (id). Well, if HAVE_WORKING_STAT is not defined, then it means some other mechanism has to be used. If your target is not mingw32 and stat() is not reliable, we’ll need to provide an alternate way of handling things. Your patch would default to the unusable stat(). What’s your target? FX
On 21 Sep 12:53, FX wrote: > Dear Kirill, > > > When libgfortran is configured w/ HAVE_WORKING_STAT undefined > > *and* current system is not MinGW - FIND_FILE_[DECL|ARGS} still > > trying to use Windows's handles (id). > > Well, if HAVE_WORKING_STAT is not defined, then it means some other mechanism has to be used. If your target is not mingw32 and stat() is not reliable, we’ll need to provide an alternate way of handling things. Your patch would default to the unusable stat(). That's right, but maybe at least allow bootstrap to pass? > What’s your target? I am trying to pass bootstrap w/ couple of insns siwtched on, which are not available on host. While configureing libgfortran test checking whether the target stat is reliable... returns no, since test program fails to execute (due to illegal insn exception). So, we have non MinGW system w/o stat. I am not going to use resulting libgfortran, only extra sanity check for my changes to i386 target. -- Thanks, K > > FX
diff --git a/libgfortran/io/unix.c b/libgfortran/io/unix.c index b86bd67..772725a 100644 --- a/libgfortran/io/unix.c +++ b/libgfortran/io/unix.c @@ -1551,8 +1551,13 @@ compare_file_filename (gfc_unit *u, const char *name, int len) # define FIND_FILE0_DECL struct stat *st # define FIND_FILE0_ARGS st #else -# define FIND_FILE0_DECL uint64_t id, const char *path -# define FIND_FILE0_ARGS id, path +# if defined(__MINGW32__) +# define FIND_FILE0_DECL uint64_t id, const char *path +# define FIND_FILE0_ARGS id, path +# else +# define FIND_FILE0_DECL const char *path +# define FIND_FILE0_ARGS path +# endif #endif /* find_file0()-- Recursive work function for find_file() */
Hello, When libgfortran is configured w/ HAVE_WORKING_STAT undefined *and* current system is not MinGW - FIND_FILE_[DECL|ARGS} still trying to use Windows's handles (id). Proposed patch discriminates MinGW case under HAVE_WORKING_STAT switched off. Bootstrapped (on Linux). libgfortran/ * io/unix.c (FIND_FILE0_DECL): Don't use `id' when HAVE_WORKING_STAT is not defined and system is not MinGW. (FIND_FILE0_ARGS): Ditto. Is it ok for trunk? Is it ok for gcc-5-branch? (if bootstrap passed) -- Thanks, K $ git show c1d01f74051f65e75b0de73b1b43c76b9b2e1b02 commit c1d01f74051f65e75b0de73b1b43c76b9b2e1b02 Author: Kirill Yukhin <kirill.yukhin@intel.com> Date: Fri Sep 18 19:00:52 2015 +0300 Fix libgfortran/io/unix.c to allow not stable STAT for non MinGW.