Hi Mike, I'm sorry to spend a week to response your replay, and thank you for explanation of -save-temps=obj specifications.
> I tend to agree with Richard, that if there are multiple source inputs, it > should be an error to use -save-temps=obj without the -c/-S option. I reached a true understanding, and this explanation should help my project. Certainly this case is not god. In this case(= multiple input files that have same filename), compiling should became failure neither by -save-temps=cwd nor by -save-temps=obj. It is difficult ... However this suggestion also gave idea to help my project. > Yes, the motivation was for doing large builds (notably spec 2006) where > several of the files have the same base name but are in different > subdirectories. In particular, I could not build 436.cactusADM with -j8 > without getting conflicts (bugzilla 39293). Even if I built it with -j1 so > they wouldn't interfere, I would lose the asm files for some of the builds, > which would mean my static analysis programs would miss some objects. > > I have also seen conflicts with -save-temps if you use have -j numbers when > doing a compiler bootstrap. I have sympathies with you strongly. On my project, I had same motivation. I have a tiny project, GAST (Gcc Automatically Save Temps). GAST: http://en.sourceforge.jp/projects/gast/ (I am weak in English, so pleas forgive my English mistake in Web page) This project provides a wrapper script to preserve intermediate files automatically. In this project, I made an effort to preserve intermediate files which are from source file having same base name but in different subdirectories. To preserve all the intermediate files and not to interfere with build process, I had to control -j number to 1. But this is not friendly to larger builds (like a linux kernel building), so that I was grad when I heard about -save-temps=obj option. I expected -save-temps=obj option to liberate me to control -j numbers. But in case of multiple input files, if -save-temps=obj option is added automatically with no consideration, it interfere build process, so I am confused. However, I understood the specification of -save-temps=obj, and then I had an idea for a workaround in GAST implementation. the GAST script can detected a number of input files, so that only if GAST detected a number of input file as 1, GAST use -save-temps=obj option (the other hands if multiple input files are detected, GAST use -save-temps). This method still has a small risk of interfering parallel build, but probably it is usable in almost all the case. I thank Michael and Richard from the bottom of my heart for your kindness. Best regards, Tadashi Koike 2010/3/26 Michael Meissner <meiss...@linux.vnet.ibm.com>: > On Thu, Mar 25, 2010 at 11:33:17PM +0900, Tadashi Koike wrote: >> Hi Richard >> (* I am weak in English, so pleas forgive my English mistake.) >> >> Thank you for your reply, and I'm sorry to be late a reply. >> >> > On Sat, Mar 20, 2010 at 5:40 PM, Tadashi Koike <tadash...@gmail.com> wrote: >> >> [ summary ] >> >> compiling is failed when more than two source file are >> >> specified with both -save-temps=obj and -o options. >> : >> >> [[ operations being error ]] >> >> % gcc -save-temps=obj -o hellow main.c func.c >> >> % gcc -save-temps=obj -o obj_dir/hellow main.c func.c >> >> 2010/3/21 Richard Guenther <richard.guent...@gmail.com>: >> > >> > It should be an error to use -save-temps=obj with multiple >> > input files. Mike, can you look at this? >> > >> > Thanks, >> > Richard. >> > >> >> After I received your reply, I confirm an information about >> "-save-temps=obj". > > I tend to agree with Richard, that if there are multiple source inputs, it > should be an error to use -save-temps=obj without the -c/-S option. > > Though it might be friendlier to allow: > > gcc -o dir/exe a.c b.c c.c > > and put the temp files in: > > dir/a.{s,i} > dir/b.{s,i} > dir/c.{s,i} > > But it would fail for doing: > > gcc -o exe dir1/a.c dir2/a.c > > where the names overlap. Let me look at it. > >> In this URL(http://gcc.gnu.org/gcc-4.5/changes.html), "-save-temps=obj" >> option are introduced as follow: >> >> | The -save-temps=obj switch will write files into the directory specified >> | with the -o option, and the intermediate filenames are based on the >> | output file. >> >> If above is a specification of "-save-temps=obj" option, found behaviors >> in my report about "-save-temps=obj" are true behaviors (but cannot >> deal in case of multiple input files). >> >> I considered. And I read a purpose of this option in above URL : >> >> | This will allow the user to get the compiler intermediate files when >> | doing parallel builds without two builds of the same filename located in >> | different directories from interfering with each other. >> >> My recognition is below: >> - True purpose is a failure of compiling under parallel builds. In detail, >> problem is a compiling failure under parallel builds caused by >> interfering >> intermediate file each other. To solve this problem, developer thought >> that the intermediate files have to be created in different directory. >> So a directory specified with the -o option are choose as these purpose. >> >> (I named this problem as "Compiling failure by interfering" for following >> discussion.) > > Yes, the motivation was for doing large builds (notably spec 2006) where > several of the files have the same base name but are in different > subdirectories. In particular, I could not build 436.cactusADM with -j8 > without getting conflicts (bugzilla 39293). Even if I built it with -j1 so > they wouldn't interfere, I would lose the asm files for some of the builds, > which would mean my static analysis programs would miss some objects. > > I have also seen conflicts with -save-temps if you use have -j numbers when > doing a compiler bootstrap. > >> - If two builds of the same file name located in different directories are >> done as serial, each build is successful fine, but intermediate file is >> overwritten by a latest compiling. >> (I named this problem as "Overwritten by interfering" for following >> discussion.) > > Yes. > >> - A purpose of "-save-temps=obj" option is to solve the "Compiling >> failure by interfering", not to solve the "Overwritten by interfering". > > Well the real purpose is to allow me to better debug stuff when doing large > builds, so that I can go back without having to do the build by hand. Just > like when I added the original -save-temps option around 1988 or so. > >> From my consideration, I reached some understanding as follow: >> - True solution for "Compiling failure by interferng" is using a >> true independent file name which is assured by System (such as >> filename returned by tmpnam() function in stdio.h) for each >> intermediate file. After compiling are successful, filename of >> intermediate files need to change as true filenames based on >> source/object files. > > Well if this is a big problem for you, when 4.6 opens up, feel free to add a > new varient of -save-temps=<xxx>. The current implementation of > -save-temps=obj meets the needs that I had in doing large builds. > >> - "-save-temps=obj" option is useful to solve some "Overwritten >> by interfering" problems. Trouble will decrease caused this >> problem. (so I hope/want this option very much) >> >> - I hope that the filename of intermediate file by "-save-temps=obj" >> is also based on source files. >> >> I hope to hear someone's opinion else. > > -- > Michael Meissner, IBM > 4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA > meiss...@linux.vnet.ibm.com >
