search for: ffree

...================================ --- lang-specs.h (revision 57986) +++ lang-specs.h (working copy) @@ -14,7 +14,9 @@ "cc1 -E -lang-fortran -traditional-cpp -D_LANGUAGE_FORTRAN % (cpp_options) \ %{E|M|MM:%(cpp_debug_options)}\ %{!M:%{!MM:%{!E: -o %|.f |\n\ - f951 %|.f %{!ffree-form:-ffixed-form} %(cc1_options) %{J*} %{I*}\ + f951 %|.f %{!ffree-form:-ffixed-form} %(cc1_options) \ + %<Wformat %<Wformat-security %<Wno-format-extra-args %<Wno-format- zero-length %<Wno-nonull \ + %{J*} %{I*}\ "/* LLVM LOCAL */" \ %(llvm_optio...

On Oct 30, 2008, at 5:23 PM, Jack Howarth wrote: > ps We do have one oddity left in llvm-gfortran from current llvm > svn. I find everytime I compile something with llvm-gfortran that > I get a series of warning messages... > > f951: warning: command line option "-Wformat" is valid for C/C++/ > ObjC/ObjC++ but not for Fortran > f951: warning: command line option

...14 +401,21 @@ and check_guest_free_space mpstats = 10_000_000L in + (* Reasonable headroom for conversion operations. *) + let needed_inodes = 100L in + List.iter ( - fun { mp_path; mp_statvfs = { G.bfree; bsize } } -> + fun { mp_path; mp_statvfs = { G.bfree; bsize; files; ffree } } -> (* bfree = free blocks for root user *) let free_bytes = bfree *^ bsize in let needed_bytes = needed_bytes_for_mp mp_path in if free_bytes < needed_bytes then error (f_"not enough free space for conversion on filesystem ‘%s’. %Ld bytes free &l...

...14 +401,21 @@ and check_guest_free_space mpstats = 10_000_000L in + (* Reasonable headroom for conversion operations. *) + let needed_inodes = 100L in + List.iter ( - fun { mp_path; mp_statvfs = { G.bfree; bsize } } -> + fun { mp_path; mp_statvfs = { G.bfree; bsize; files; ffree } } -> (* bfree = free blocks for root user *) let free_bytes = bfree *^ bsize in let needed_bytes = needed_bytes_for_mp mp_path in if free_bytes < needed_bytes then error (f_"not enough free space for conversion on filesystem ‘%s’. %Ld bytes free &l...

Hello! I am creating a packege and I would like to inclued some Fortrun subrutines. I have two questions. 1. Can I use "free form fortan" - compiles well usinf g77 -ffree-form. 2. Is it enough to place the ".for" files in scr folder? Thank you in advance for any help! Ales Ziberna P.S.: I am runing R 2.1.1 on Win XP, SP2. I installed rtools, mingw, perl as suggested in the manuals. Here are some detailsabour R: platform i386-pc-mingw32 arch i386 os...

...375260  27% /boot tmpfs                      188376       0    188376   0% /run/user/0 using scripts: python -c 'import os; s = os.statvfs ("/"); print s' posix.statvfs_result(f_bsize=4096, f_frsize=4096, f_blocks=5886149, f_bfree=4802342, f_bavail=4802342, f_files=23556096, f_ffree=23435372, f_favail=23435372, f_flag=4096, f_namemax=255) python -c 'import os; s = os.statvfs ("/boot"); print s' posix.statvfs_result(f_bsize=4096, f_frsize=4096, f_blocks=127147, f_bfree=93815, f_bavail=93815, f_files=512000, f_ffree=511626, f_favail=511626, f_flag=4096, f_n...

Hello! I have writen some subrutines in Free-form Fortran. I would like to includ them in a package, which I would like to build on WinXP. I have all suggested tools/programs for bulding R packages on Windows (except latex). What is the best way of using these subrutines? Does sombody mybe know any translation tools for converting Free-form to fixed-form Fortran? Thanks for any suggestions,

...Thu, Jan 04, 2018 at 12:58:40PM +0800, Chen Fan wrote: >[In guest] >> python -c 'import os; s = os.statvfs ("/"); print s' >> posix.statvfs_result(f_bsize=4096, f_frsize=4096, f_blocks=5886149, >> f_bfree=4802342, f_bavail=4802342, f_files=23556096, >> f_ffree=23435372, f_favail=23435372, f_flag=4096, f_namemax=255) >> >> python -c 'import os; s = os.statvfs ("/boot"); print s' >> posix.statvfs_result(f_bsize=4096, f_frsize=4096, f_blocks=127147, >> f_bfree=93815, f_bavail=93815, f_files=512000, f_ffree=511626,...

...fc17 (3rd Nov) Fedora kernel 3.2.0-0.rc1.git2.1.fc17 (11th Nov) With 3.2.0-0.rc0.git4.1.fc17, and all earlier versions, the output of statvfs(2) on a freshly created 20M ext2 filesystem is: bsize: 1024 frsize: 1024 blocks: 19827 <-- NB bfree: 19655 bavail: 18631 files: 5136 ffree: 5125 favail: 5125 fsid: 1411286354856931562 flag: 4096 namemax: 255 With 3.2.0-0.rc1.git2.1.fc17, it changed to: bsize: 1024 frsize: 1024 blocks: 19939 <-- NB bfree: 19655 bavail: 18631 files: 5136 ffree: 5125 favail: 5125 fsid: -9088586685126948527 flag: 4096...

Chris and Bill, I have tested the proposed patch from... http://lists.cs.uiuc.edu/pipermail/llvmdev/2008-August/016490.html under i686-apple-darwin9 and it solves the problems building gfortran from llvm svn. The resulting compiler works fine so can we get that patch in before 2.4 is release? Jack ps We do have one oddity left in llvm-gfortran from current llvm svn. I find

...ot; attribute for C functions > > (which has similar effect)? > > Yes, we fully support it. I'm not sure why you think there is a bug here. > As several people have told you, LLVM is doing the right thing, and if you > want to build a kernel or something without libc, use -ffree-standing. > There are serveral existence cases of kernels built with LLVM. I did not say that I thought there was a bug here. That was Duncan. I *asked* if LLVM assumes that main is the only entry point because of the earlier malloc() discussion, which seemed to rely on knowing the control flo...

..." <rjones@redhat.com> wrote: >To summarise: > >>[In guest] >> python -c 'import os; s = os.statvfs ("/boot"); print s' >> posix.statvfs_result(f_bsize=4096, f_frsize=4096, f_blocks=127147, >> f_bfree=93815, f_bavail=93815, f_files=512000, f_ffree=511626, >> f_favail=511626, f_flag=4096, f_namemax=255) > >>[From the host via libguestfs] >> # sudo guestfish --ro -d rpm-build-for-7.2 -i statvfs /boot >> bsize: 4096 >> frsize: 4096 >> blocks: 127147 >> bfree: 100215 >> bavail: 100215 >> f...

On Thu, Jan 04, 2018 at 12:58:40PM +0800, Chen Fan wrote: [In guest] > python -c 'import os; s = os.statvfs ("/"); print s' > posix.statvfs_result(f_bsize=4096, f_frsize=4096, f_blocks=5886149, > f_bfree=4802342, f_bavail=4802342, f_files=23556096, > f_ffree=23435372, f_favail=23435372, f_flag=4096, f_namemax=255) > > python -c 'import os; s = os.statvfs ("/boot"); print s' > posix.statvfs_result(f_bsize=4096, f_frsize=4096, f_blocks=127147, > f_bfree=93815, f_bavail=93815, f_files=512000, f_ffree=511626, > f_favail=51...

To summarise: >[In guest] > python -c 'import os; s = os.statvfs ("/boot"); print s' > posix.statvfs_result(f_bsize=4096, f_frsize=4096, f_blocks=127147, > f_bfree=93815, f_bavail=93815, f_files=512000, f_ffree=511626, > f_favail=511626, f_flag=4096, f_namemax=255) >[From the host via libguestfs] > # sudo guestfish --ro -d rpm-build-for-7.2 -i statvfs /boot > bsize: 4096 > frsize: 4096 > blocks: 127147 > bfree: 100215 > bavail: 100215 > files: 512000 > ffree: 511626 > fav...

...start getting my hands dirty. Yes, globalopt does that. You're asking two questions: 1. Does llvm incorrectly assume things that break C++ constructors and the GNU extensions. 2. Does llvm assume things that break kernels. The answer to #1 is no. The answer to #2 is "not if you use -ffree-standing". Why do you care about globalopt.cpp specifically? -Chris -- http://nondot.org/sabre/ http://llvm.org/

...does that. > > You're asking two questions: > > 1. Does llvm incorrectly assume things that break C++ constructors and the > GNU extensions. > 2. Does llvm assume things that break kernels. > > The answer to #1 is no. The answer to #2 is "not if you use > -ffree-standing". Why do you care about globalopt.cpp specifically? Only because Duncan mentioned it.

...support the "init" attribute for C functions > (which has similar effect)? Yes, we fully support it. I'm not sure why you think there is a bug here. As several people have told you, LLVM is doing the right thing, and if you want to build a kernel or something without libc, use -ffree-standing. There are serveral existence cases of kernels built with LLVM. -Chris -- http://nondot.org/sabre/ http://llvm.org/

...thv) } value -guestfs_int_mllib_statvfs_free_space (value pathv) +guestfs_int_mllib_statvfs_statvfs (value pathv) { CAMLparam1 (pathv); - CAMLlocal1 (rv); + int64_t f_bsize; + int64_t f_frsize; + int64_t f_blocks; + int64_t f_bfree; + int64_t f_bavail; + int64_t f_files; + int64_t f_ffree; + int64_t f_favail; + int64_t f_fsid; + int64_t f_flag; + int64_t f_namemax; + CAMLlocal2 (rv, v); + +#ifdef HAVE_STATVFS struct statvfs buf; - int64_t free_space; - if (statvfs (String_val (pathv), &buf) == -1) { - perror ("statvfs"); - caml_failwith ("statvfs...

...so that it is run more than once and is iterative. 4) we want other passes to be able to optimize libcalls. For example, the stuff I added in r61918 requires GVN or memcpyopt to optimize things like strlen. 5) regardless of #1/2, we want to support things like -fno-builtin- free someday. -ffree-standing would also imply this sort of thing, as would -fno-builtins etc. 6) there are other routines that we want to make assumptions about, that are almost certainly true, but are not standard conformant. I'm thinking things like "operator new is sane and thus the result is noal...

On Wed, 2008-05-14 at 16:15 +0200, Duncan Sands wrote: > I don't think the logic is based on "main", but on whether functions > are marked "internal" or not. That said, GlobalOpt.cpp seems to reason > based on the name "main" (most likely bogus, because of constructors/ > destructors running before main). Umm. That sounds like a test case that really