* About behavior of -save-temps=obj option on GCC 4.5
@ 2010-03-20 16:59 Tadashi Koike
2010-03-20 18:47 ` Richard Guenther
0 siblings, 1 reply; 6+ messages in thread
From: Tadashi Koike @ 2010-03-20 16:59 UTC (permalink / raw)
To: gcc
Hi all,
(* I am weak in English, so pleas forgive my English mistake.)
Please teach me about a behavior of -save-temps=obj option
on gcc 4.5. A behavior I found is whether bug or specification ?
[ summary ]
compiling is failed when more than two source file are
specified with both -save-temps=obj and -o options.
1) Environment
-------------------------------------------------------
[System]: Fedora release 12 (Constantine)
[gcc version]:
% /usr/local/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.5-20100304-src/configure
--prefix=/usr/local --mandir=/usr/local/share/man
--infodir=/usr/local/share/info --enable-languages=c,c++ --disable-nls
Thread model: posix
gcc version 4.5.0 20100304 (experimental) (GCC)
-------------------------------------------------------
2) Source files I used are bellow:
[main.c]
+------------------------------------------------------
|extern int func(const char *);
|int main () {
| func("hello world!\n");
|}
+------------------------------------------------------
[func.c]
+------------------------------------------------------
|#include <stdio.h>
|int func (const char *str) {
| return(fprintf(stdout, str));
|}
+------------------------------------------------------
3) Files/Directory structure is bellow:
/tmp/test/hellow.c
/func.c
/obj_dir/
4) Test operations.
I tryed bellow operations at /tmp/test directory.
-------------------------------------------------------
[[ operations being successful ]]
% gcc main.c func.c
% gcc -o obj_dir/hello main.c func.c
% gcc -save-temps=cwd main.c func.c
% gcc -save-temps=cwd -o obj_dir/hello main.c func.c
% gcc -save-temps=obj main.c func.c
[[ 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
// example error messages //
obj_dir/hello.o: In function `func':
func.c:(.text+0x0): multiple definition of `func'
obj_dir/hello.o:func.c:(.text+0x0): first defined here
/usr/lib/../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: ld returned 1 exit status
// more information//
* in this error case, temporary files are nemed as
'hello.i' and that content is from 'func.c', but
contents of 'hello.s' is perhaps from 'main.c'.
-------------------------------------------------------
I think that two understanding are possible.
A) this behavior is a specification like '-o' option with
using -c option.
[ operation example ]
% gcc -c -o obj_dir/hello.o main.c func.c
gcc: cannot specify -o with -c, -S or -E with multiple files
B) this behavior is a bug.
[ reason ]
In below case, temporary files are made in current
directory. names of these files are based on 'source
file'.
% gcc -save-temps=cwd -o obj_dir/hello main.c func.c
When -save-temps=cwd option is exchanged to
-save-temps=obj, I expect to keep names of temporary
files as from 'source file', and only a place to save
temporary files are exchanged to object directory.
Because I don't understand that this behavior is whether
bug or specification, so I don't report this to bugzilla
yet.
I feel that function of -save-temps=obj option is great!
I would like to know how to use -save-temps=obj option.
So pleas teach me true behavior about -save-temps=obj.
Best regards,
Tadashi Koike
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: About behavior of -save-temps=obj option on GCC 4.5
2010-03-20 16:59 About behavior of -save-temps=obj option on GCC 4.5 Tadashi Koike
@ 2010-03-20 18:47 ` Richard Guenther
2010-03-25 15:04 ` Tadashi Koike
0 siblings, 1 reply; 6+ messages in thread
From: Richard Guenther @ 2010-03-20 18:47 UTC (permalink / raw)
To: Tadashi Koike; +Cc: gcc, Michael Meissner
On Sat, Mar 20, 2010 at 5:40 PM, Tadashi Koike <tadashiee@gmail.com> wrote:
> Hi all,
> (* I am weak in English, so pleas forgive my English mistake.)
>
> Please teach me about a behavior of -save-temps=obj option
> on gcc 4.5. A behavior I found is whether bug or specification ?
>
> [ summary ]
> compiling is failed when more than two source file are
> specified with both -save-temps=obj and -o options.
>
> 1) Environment
> -------------------------------------------------------
> [System]: Fedora release 12 (Constantine)
> [gcc version]:
> % /usr/local/bin/gcc -v
> Using built-in specs.
> COLLECT_GCC=/usr/local/bin/gcc
> COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
> Target: x86_64-unknown-linux-gnu
> Configured with: ../gcc-4.5-20100304-src/configure
> --prefix=/usr/local --mandir=/usr/local/share/man
> --infodir=/usr/local/share/info --enable-languages=c,c++ --disable-nls
> Thread model: posix
> gcc version 4.5.0 20100304 (experimental) (GCC)
> -------------------------------------------------------
>
> 2) Source files I used are bellow:
> [main.c]
> +------------------------------------------------------
> |extern int func(const char *);
> |int main () {
> | func("hello world!\n");
> |}
> +------------------------------------------------------
> [func.c]
> +------------------------------------------------------
> |#include <stdio.h>
> |int func (const char *str) {
> | return(fprintf(stdout, str));
> |}
> +------------------------------------------------------
>
> 3) Files/Directory structure is bellow:
> /tmp/test/hellow.c
> /func.c
> /obj_dir/
>
> 4) Test operations.
> I tryed bellow operations at /tmp/test directory.
> -------------------------------------------------------
> [[ operations being successful ]]
> % gcc main.c func.c
> % gcc -o obj_dir/hello main.c func.c
> % gcc -save-temps=cwd main.c func.c
> % gcc -save-temps=cwd -o obj_dir/hello main.c func.c
> % gcc -save-temps=obj main.c func.c
>
> [[ 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
>
> // example error messages //
> obj_dir/hello.o: In function `func':
> func.c:(.text+0x0): multiple definition of `func'
> obj_dir/hello.o:func.c:(.text+0x0): first defined here
> /usr/lib/../lib64/crt1.o: In function `_start':
> (.text+0x20): undefined reference to `main'
> collect2: ld returned 1 exit status
>
> // more information//
> * in this error case, temporary files are nemed as
> 'hello.i' and that content is from 'func.c', but
> contents of 'hello.s' is perhaps from 'main.c'.
> -------------------------------------------------------
>
> I think that two understanding are possible.
> A) this behavior is a specification like '-o' option with
> using -c option.
>
> [ operation example ]
> % gcc -c -o obj_dir/hello.o main.c func.c
> gcc: cannot specify -o with -c, -S or -E with multiple files
>
> B) this behavior is a bug.
> [ reason ]
> In below case, temporary files are made in current
> directory. names of these files are based on 'source
> file'.
>
> % gcc -save-temps=cwd -o obj_dir/hello main.c func.c
>
> When -save-temps=cwd option is exchanged to
> -save-temps=obj, I expect to keep names of temporary
> files as from 'source file', and only a place to save
> temporary files are exchanged to object directory.
>
> Because I don't understand that this behavior is whether
> bug or specification, so I don't report this to bugzilla
> yet.
>
> I feel that function of -save-temps=obj option is great!
> I would like to know how to use -save-temps=obj option.
> So pleas teach me true behavior about -save-temps=obj.
It should be an error to use -save-temps=obj with multiple
input files. Mike, can you look at this?
Thanks,
Richard.
> Best regards,
> Tadashi Koike
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: About behavior of -save-temps=obj option on GCC 4.5
2010-03-20 18:47 ` Richard Guenther
@ 2010-03-25 15:04 ` Tadashi Koike
2010-03-25 16:19 ` Michael Meissner
0 siblings, 1 reply; 6+ messages in thread
From: Tadashi Koike @ 2010-03-25 15:04 UTC (permalink / raw)
To: Richard Guenther; +Cc: gcc, Michael Meissner
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 <tadashiee@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.guenther@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".
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.)
- 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.)
- A purpose of "-save-temps=obj" option is to solve the "Compiling
failure by interfering", not to solve the "Overwritten by interfering".
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.
- "-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.
Best regards,
Tadashi Koike
2010/3/21 Richard Guenther <richard.guenther@gmail.com>:
> On Sat, Mar 20, 2010 at 5:40 PM, Tadashi Koike<tadashiee@gmail.com> wrote:
>> Hi all,
>> (* I am weak in English, so pleas forgive my English mistake.)
>>
>> Please teach me about a behavior of -save-temps=obj option
>> on gcc 4.5. A behavior I found is whether bug or specification ?
>>
>> [ summary ]
>> compiling is failed when more than two source file are
>> specified with both -save-temps=obj and -o options.
>>
>> 1) Environment
>> -------------------------------------------------------
>> [System]: Fedora release 12 (Constantine)
>> [gcc version]:
>> % /usr/local/bin/gcc -v
>> Using built-in specs.
>> COLLECT_GCC=/usr/local/bin/gcc
>> COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
>> Target: x86_64-unknown-linux-gnu
>> Configured with: ../gcc-4.5-20100304-src/configure
>> --prefix=/usr/local --mandir=/usr/local/share/man
>> --infodir=/usr/local/share/info --enable-languages=c,c++ --disable-nls
>> Thread model: posix
>> gcc version 4.5.0 20100304 (experimental) (GCC)
>> -------------------------------------------------------
>>
>> 2) Source files I used are bellow:
>> [main.c]
>> +------------------------------------------------------
>> |extern int func(const char *);
>> |int main () {
>> | func("hello world!\n");
>> |}
>> +------------------------------------------------------
>> [func.c]
>> +------------------------------------------------------
>> |#include<stdio.h>
>> |int func (const char *str) {
>> | return(fprintf(stdout, str));
>> |}
>> +------------------------------------------------------
>>
>> 3) Files/Directory structure is bellow:
>> /tmp/test/hellow.c
>> /func.c
>> /obj_dir/
>>
>> 4) Test operations.
>> I tryed bellow operations at /tmp/test directory.
>> -------------------------------------------------------
>> [[ operations being successful ]]
>> % gcc main.c func.c
>> % gcc -o obj_dir/hello main.c func.c
>> % gcc -save-temps=cwd main.c func.c
>> % gcc -save-temps=cwd -o obj_dir/hello main.c func.c
>> % gcc -save-temps=obj main.c func.c
>>
>> [[ 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
>>
>> // example error messages //
>> obj_dir/hello.o: In function `func':
>> func.c:(.text+0x0): multiple definition of `func'
>> obj_dir/hello.o:func.c:(.text+0x0): first defined here
>> /usr/lib/../lib64/crt1.o: In function `_start':
>> (.text+0x20): undefined reference to `main'
>> collect2: ld returned 1 exit status
>>
>> // more information//
>> * in this error case, temporary files are nemed as
>> 'hello.i' and that content is from 'func.c', but
>> contents of 'hello.s' is perhaps from 'main.c'.
>> -------------------------------------------------------
>>
>> I think that two understanding are possible.
>> A) this behavior is a specification like '-o' option with
>> using -c option.
>>
>> [ operation example ]
>> % gcc -c -o obj_dir/hello.o main.c func.c
>> gcc: cannot specify -o with -c, -S or -E with multiple files
>>
>> B) this behavior is a bug.
>> [ reason ]
>> In below case, temporary files are made in current
>> directory. names of these files are based on 'source
>> file'.
>>
>> % gcc -save-temps=cwd -o obj_dir/hello main.c func.c
>>
>> When -save-temps=cwd option is exchanged to
>> -save-temps=obj, I expect to keep names of temporary
>> files as from 'source file', and only a place to save
>> temporary files are exchanged to object directory.
>>
>> Because I don't understand that this behavior is whether
>> bug or specification, so I don't report this to bugzilla
>> yet.
>>
>> I feel that function of -save-temps=obj option is great!
>> I would like to know how to use -save-temps=obj option.
>> So pleas teach me true behavior about -save-temps=obj.
>
> It should be an error to use -save-temps=obj with multiple
> input files. Mike, can you look at this?
>
> Thanks,
> Richard.
>
>> Best regards,
>> Tadashi Koike
>>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: About behavior of -save-temps=obj option on GCC 4.5
2010-03-25 15:04 ` Tadashi Koike
@ 2010-03-25 16:19 ` Michael Meissner
2010-04-03 1:48 ` Tadashi Koike
0 siblings, 1 reply; 6+ messages in thread
From: Michael Meissner @ 2010-03-25 16:19 UTC (permalink / raw)
To: Tadashi Koike; +Cc: Richard Guenther, gcc, Michael Meissner
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 <tadashiee@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.guenther@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
meissner@linux.vnet.ibm.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: About behavior of -save-temps=obj option on GCC 4.5
2010-03-25 16:19 ` Michael Meissner
@ 2010-04-03 1:48 ` Tadashi Koike
2010-04-03 1:56 ` Tadashi Koike
0 siblings, 1 reply; 6+ messages in thread
From: Tadashi Koike @ 2010-04-03 1:48 UTC (permalink / raw)
To: Michael Meissner, Richard Guenther, gcc
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 <meissner@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 <tadashiee@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.guenther@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
> meissner@linux.vnet.ibm.com
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: About behavior of -save-temps=obj option on GCC 4.5
2010-04-03 1:48 ` Tadashi Koike
@ 2010-04-03 1:56 ` Tadashi Koike
0 siblings, 0 replies; 6+ messages in thread
From: Tadashi Koike @ 2010-04-03 1:56 UTC (permalink / raw)
To: Michael Meissner, Richard Guenther, gcc
Sorry, I miss. follow it:
2010/4/3 Tadashi Koike <tadashiee@gmail.com>:
> 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.
>
This quotation is forgotten
>> 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.
> 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 ...
:
Best regards,
Tadashi Koike
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-04-03 1:56 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-03-20 16:59 About behavior of -save-temps=obj option on GCC 4.5 Tadashi Koike
2010-03-20 18:47 ` Richard Guenther
2010-03-25 15:04 ` Tadashi Koike
2010-03-25 16:19 ` Michael Meissner
2010-04-03 1:48 ` Tadashi Koike
2010-04-03 1:56 ` Tadashi Koike
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).