Why doesn't gcc report an error or warning in such a case: gcc filename.c -g -o filename.c I have a very long C program, whose sources that got lost because of the above command. All I see in my program are some junk letters. I know it's human error, but can you please incorporate any warning message about the above compile option. That the user is overwriting his/her own C code?
Happened to me as well.
(In reply to comment #1) > Happened to me as well. any remedy...so as to recover the lost C codes?
I didn't lose anything - the internet backs up for me.
(In reply to comment #3) > I didn't lose anything - the internet backs up for me. THe problem with me is rather grave. I dont even have a backup. Any method by which I can recover the source code? I need the codes desperately.
A warning would be of no use, as it would be too late to recover the input file. Having GCC refuse to run in this case would be great.
*** Bug 63462 has been marked as a duplicate of this bug. ***
Created attachment 33656 [details] Possible fix The attached patch implements this for the driver and toplev.c. Probably the final version needs to move canonical_filename_eq to libiberty. It builds but I haven't tested it beyond a few quick tests. Perhaps it needs testcases.
Author: manu Date: Wed Nov 5 17:23:46 2014 New Revision: 217149 URL: https://gcc.gnu.org/viewcvs?rev=217149&root=gcc&view=rev Log: gcc/testsuite/ChangeLog: 2014-11-05 Anthony Brandon <anthony.brandon@gmail.com> PR driver/36312 * gcc.misc-tests/output.exp: New test case for identical input and output files. include/ChangeLog: 2014-11-05 Anthony Brandon <anthony.brandon@gmail.com> PR driver/36312 * filenames.h: Add prototype for canonical_filename_eq. gcc/ChangeLog: 2014-11-05 Anthony Brandon <anthony.brandon@gmail.com> PR driver/36312 * diagnostic-core.h: Add prototype for fatal_error. * diagnostic.c (fatal_error): New function fatal_error. * gcc.c (store_arg): Remove have_o_argbuf_index. (process_command): Check if input and output files are the same. * toplev.c (init_asm_output): Check if input and output files are the same. libiberty/ChangeLog: 2014-11-05 Anthony Brandon <anthony.brandon@gmail.com> PR driver/36312 * filename_cmp.c (canonical_filename_eq): New function to check if file names are the same. * functions.texi: Updated with documentation for new function. Added: trunk/gcc/testsuite/gcc.misc-tests/output.exp Modified: trunk/gcc/ChangeLog trunk/gcc/diagnostic-core.h trunk/gcc/diagnostic.c trunk/gcc/gcc.c trunk/gcc/testsuite/ChangeLog trunk/gcc/toplev.c trunk/include/ChangeLog trunk/include/filenames.h trunk/libiberty/ChangeLog trunk/libiberty/filename_cmp.c trunk/libiberty/functions.texi
Anthony Brandon updated my patch and added a testcase, so this is fixed in GCC 5.0. This was his second contribution to GCC, which shows that "Contributing to GCC is hard" is a myth.
I'm very happy seeing it in GCC. On Wed, Nov 5, 2014 at 9:24 AM, manu at gcc dot gnu.org < gcc-bugzilla@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36312 > > --- Comment #8 from Manuel López-Ibáñez <manu at gcc dot gnu.org> --- > Author: manu > Date: Wed Nov 5 17:23:46 2014 > New Revision: 217149 > > URL: https://gcc.gnu.org/viewcvs?rev=217149&root=gcc&view=rev > Log: > > gcc/testsuite/ChangeLog: > > 2014-11-05 Anthony Brandon <anthony.brandon@gmail.com> > > PR driver/36312 > * gcc.misc-tests/output.exp: New test case for identical input and > output files. > > include/ChangeLog: > > 2014-11-05 Anthony Brandon <anthony.brandon@gmail.com> > > PR driver/36312 > * filenames.h: Add prototype for canonical_filename_eq. > > gcc/ChangeLog: > > 2014-11-05 Anthony Brandon <anthony.brandon@gmail.com> > > PR driver/36312 > * diagnostic-core.h: Add prototype for fatal_error. > * diagnostic.c (fatal_error): New function fatal_error. > * gcc.c (store_arg): Remove have_o_argbuf_index. > (process_command): Check if input and output files are the same. > * toplev.c (init_asm_output): Check if input and output files are > the same. > > libiberty/ChangeLog: > > 2014-11-05 Anthony Brandon <anthony.brandon@gmail.com> > > PR driver/36312 > * filename_cmp.c (canonical_filename_eq): New function to check if > file names are the same. > * functions.texi: Updated with documentation for new function. > > Added: > trunk/gcc/testsuite/gcc.misc-tests/output.exp > Modified: > trunk/gcc/ChangeLog > trunk/gcc/diagnostic-core.h > trunk/gcc/diagnostic.c > trunk/gcc/gcc.c > trunk/gcc/testsuite/ChangeLog > trunk/gcc/toplev.c > trunk/include/ChangeLog > trunk/include/filenames.h > trunk/libiberty/ChangeLog > trunk/libiberty/filename_cmp.c > trunk/libiberty/functions.texi > > -- > You are receiving this mail because: > You are on the CC list for the bug. >
Author: manu Date: Wed Nov 5 22:17:22 2014 New Revision: 217159 URL: https://gcc.gnu.org/viewcvs?rev=217159&root=gcc&view=rev Log: Revert revision 217149 because it breaks Ada: gcc/testsuite/ChangeLog: 2014-11-05 Anthony Brandon <anthony.brandon@gmail.com> PR driver/36312 * gcc.misc-tests/output.exp: New test case for identical input and output files. include/ChangeLog: 2014-11-05 Anthony Brandon <anthony.brandon@gmail.com> PR driver/36312 * filenames.h: Add prototype for canonical_filename_eq. gcc/ChangeLog: 2014-11-05 Anthony Brandon <anthony.brandon@gmail.com> PR driver/36312 * diagnostic-core.h: Add prototype for fatal_error. * diagnostic.c (fatal_error): New function fatal_error. * gcc.c (store_arg): Remove have_o_argbuf_index. (process_command): Check if input and output files are the same. * toplev.c (init_asm_output): Check if input and output files are the same. libiberty/ChangeLog: 2014-11-05 Anthony Brandon <anthony.brandon@gmail.com> PR driver/36312 * filename_cmp.c (canonical_filename_eq): New function to check if file names are the same. * functions.texi: Updated with documentation for new function. Removed: trunk/gcc/testsuite/gcc.misc-tests/output.exp Modified: trunk/gcc/ChangeLog trunk/gcc/diagnostic-core.h trunk/gcc/diagnostic.c trunk/gcc/gcc.c trunk/gcc/testsuite/ChangeLog trunk/gcc/toplev.c trunk/include/ChangeLog trunk/include/filenames.h trunk/libiberty/ChangeLog trunk/libiberty/filename_cmp.c trunk/libiberty/functions.texi
Unfortunately, the patch broke Ada: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00368.html so I have reverted it.
Author: manu Date: Tue Nov 11 23:33:25 2014 New Revision: 217391 URL: https://gcc.gnu.org/viewcvs?rev=217391&root=gcc&view=rev Log: gcc/testsuite/ChangeLog: 2014-11-11 Anthony Brandon <anthony.brandon@gmail.com> Manuel López-Ibáñez <manu@gcc.gnu.org> PR driver/36312 * gcc.misc-tests/output.exp: New test case for identical input and output files. include/ChangeLog: 2014-11-11 Anthony Brandon <anthony.brandon@gmail.com> Manuel López-Ibáñez <manu@gcc.gnu.org> PR driver/36312 * filenames.h: Add prototype for canonical_filename_eq. gcc/ChangeLog: 2014-11-11 Anthony Brandon <anthony.brandon@gmail.com> Manuel López-Ibáñez <manu@gcc.gnu.org> PR driver/36312 * diagnostic-core.h: Add prototype for fatal_error. * diagnostic.c (fatal_error): New function fatal_error. * gcc.c (store_arg): Remove have_o_argbuf_index. (process_command): Check if input and output files are the same. * toplev.c (init_asm_output): Check if input and output files are the same. libiberty/ChangeLog: 2014-11-11 Anthony Brandon <anthony.brandon@gmail.com> Manuel López-Ibáñez <manu@gcc.gnu.org> PR driver/36312 * filename_cmp.c (canonical_filename_eq): New function to check if file names are the same. * functions.texi: Updated with documentation for new function. Added: trunk/gcc/testsuite/gcc.misc-tests/output.exp Modified: trunk/gcc/ChangeLog trunk/gcc/diagnostic-core.h trunk/gcc/diagnostic.c trunk/gcc/gcc.c trunk/gcc/testsuite/ChangeLog trunk/gcc/toplev.c trunk/include/ChangeLog trunk/include/filenames.h trunk/libiberty/ChangeLog trunk/libiberty/filename_cmp.c trunk/libiberty/functions.texi
Fixed.
This breaks glibc builds. It is a common configure idiom to use /dev/null in both input and output files. For example: configure:72: checking for AVX support configure:78: /home/triegel/local/gcc/bin/gcc -mavx -xc /dev/null -S -o /dev/null gcc: fatal error: input file '/dev/null' is the same as output file compilation terminated. configure:81: $? = 1 configure:89: result: no There is no need for a temporary file and it would slow down configure. I expect that this change will break many more packages in the distribution builds because of this common idiom. It would be sufficient if /dev/null were special cased in some way for Linux configurations.
(In reply to carlos from comment #15) > It would be sufficient if /dev/null were special cased in some way for Linux > configurations. There is a pre-approved patch here (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63837#c12) that I'm testing. Unfortunately, there seems to be a problem with the machine in the compile farm that I use for gcc development, and I'm not able to finish a bootstrap®ression test. I always get: couldn't create output pipe for command: too many open files even for a pristine copy of GCC. This didn't happen a few days ago. I didn't have time yet to investigate what is wrong.
Author: jakub Date: Wed Nov 19 18:11:54 2014 New Revision: 217789 URL: https://gcc.gnu.org/viewcvs?rev=217789&root=gcc&view=rev Log: PR driver/36312 PR driver/63837 * gcc.c (process_command): Don't check for input/output filename equality if output is HOST_BIT_BUCKET. * toplev.c (init_asm_output): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/gcc.c trunk/gcc/toplev.c
*** Bug 66531 has been marked as a duplicate of this bug. ***
*** Bug 40200 has been marked as a duplicate of this bug. ***
Not sure if this is the best place to start, but here goes. I've noticed another similar issue. Let's say you've compiled a binary, `test`, from a source `test.c`. If you then flip the arguments to gcc by mistake, `gcc -o test.c test` rather than `gcc -o test test.c`, you will overwrite the source file by trying to compile the binary, thus losing it permanently without some other backup. Can I add some functionality that double checks against compiling *into* a source file extension? Is this cruft, or something that would actually be used - and if so, what is a good way to go about doing this? Would love to do it ASAP.
(In reply to Riccardo Mutschlechner from comment #21) > Is this cruft, or something that would actually be used - and if so, what is > a good way to go about doing this? https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps
Created attachment 56105 [details] possible fix to overwriting source code added a possible fix, not sure whether thats the best approach as some source extensions may be missed alternatively list of extensions for executable files may be used but *I think* it is easier to get list of all extensions for source files rather than executables
(In reply to Riccardo Mutschlechner from comment #21) > Not sure if this is the best place to start, but here goes. I've noticed > another similar issue. > > Let's say you've compiled a binary, `test`, from a source `test.c`. If you > then flip the arguments to gcc by mistake, `gcc -o test.c test` rather than > `gcc -o test test.c`, you will overwrite the source file by trying to > compile the binary, thus losing it permanently without some other backup. That is PR 80182 really.