Bug 15303 - When gcc sees an unrecognized option, the exit status indicates success
Summary: When gcc sees an unrecognized option, the exit status indicates success
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: driver (show other bugs)
Version: 4.0.0
: P3 minor
Target Milestone: 4.6.0
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-05-06 00:59 UTC by Ian Lance Taylor
Modified: 2010-05-28 17:29 UTC (History)
2 users (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Known to work: 4.6.0
Known to fail:
Last reconfirmed: 2006-02-20 18:38:59


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ian Lance Taylor 2004-05-06 00:59:33 UTC
When gcc is invoked with an unrecognized option, it reports an error, but still
exits with a zero exit status indicating success.  This is not how most Unix
programs work.  I can't think of any reason why gcc should work that way.

For example:

gossamer> gcc -R/tmp -o hello hello.o
gcc: unrecognized option `-R/tmp'
gossamer> echo $?
0

Compare with:

gossamer> cat -q
cat: invalid option -- q
Try `cat --help' for more information.
gossamer> echo $?
1

Note that gcc has acted this way at least since 2.95.3.  Still, it seems wrong
to me.
Comment 1 Andrew Pinski 2004-05-06 04:51:20 UTC
Confirmed, but I think this is so that some options which have an effect on some target's 
native compiler it will not cause gcc to fail.  An example of this is -no-cpp-precomp on 
Darwin where Apple's GCC accepts it without an error but the FSF warnings about the 
option but does not fail, if it did then it will cause a bootstrap failure right now on the 
mainline of the FSF's GCC.
Comment 2 Wolfgang Bangerth 2004-05-06 04:55:14 UTC
I consider this to be a bug. I know that in one of our scripts we try 
to make sure that the compiler flags we figured out during configuration 
are consistent and possible by simply compiling an empty file with these 
flags. I now realize that this test must always succeed. I think this 
is not right, even if the file itself is compiled correctly with those 
parts of the flags that the compiler understood. 
 
W. 
Comment 3 Ian Lance Taylor 2004-05-06 14:36:34 UTC
Subject: Re:  When gcc sees an unrecognized option, the exit status indicates success

"pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

> ------- Additional Comments From pinskia at gcc dot gnu dot org  2004-05-06 04:51 -------
> Confirmed, but I think this is so that some options which have an effect on some target's 
> native compiler it will not cause gcc to fail.  An example of this is -no-cpp-precomp on 
> Darwin where Apple's GCC accepts it without an error but the FSF warnings about the 
> option but does not fail, if it did then it will cause a bootstrap failure right now on the 
> mainline of the FSF's GCC.

I don't think this is a very good reason.

For cases where we want gcc to accept a native compiler option, I
think we should implement that, perhaps using DRIVER_SELF_SPECS,
rather than implementing the general case of accepting all options.

As far as building gcc goes, we should be able to clearly separate
options which we pass to the native compiler and options which we pass
to gcc.  For an example of setting host specific compiler options, see
tentative_cc in the top level configure.in file.
Comment 4 David Arnold 2006-03-27 01:30:26 UTC
As a specific example, using autoconf to attempt to portably determine whether to use -pthreads (Solaris) or -pthread (Linux, etc) to request reentrant libraries and thread library linkage, gcc will warn, but otherwise accept, the wrong flag.

Comment 5 Andrew Pinski 2006-03-27 01:32:56 UTC
(In reply to comment #4)
> As a specific example, using autoconf to attempt to portably determine whether
> to use -pthreads (Solaris) or -pthread (Linux, etc) to request reentrant
> libraries and thread library linkage, gcc will warn, but otherwise accept, the
> wrong flag.
That does not matter any more in 4.1.0 and above :). as -pthread is good on Solaris as also on Linux.
Also you can look at the output of the compiler instead of depending on the return value :).
Comment 6 Tom Tromey 2007-01-22 04:16:09 UTC
The fix is simple -- change a single error() to a fatal().
I'll submit this after running the test suite.
Comment 7 Joseph S. Myers 2010-05-28 17:29:27 UTC
Subject: Bug 15303

Author: jsm28
Date: Fri May 28 17:28:57 2010
New Revision: 159986

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159986
Log:
	PR driver/15303
	* gcc.c (inform, warning, inform): New functions.
	(fatal_ice): Rename to internal_error; change cmsgid parameter to
	gmsgid.  All callers changed.
	(notice): Rename to fnotice; add parameter fp.  All callers
	changed.
	(fatal_error): Rename to fatal_signal.  All users changed.
	(fatal): Rename to fatal_error; change cmsgid parameter to
	gmsgid.  All callers changed.
	(process_command): Use warning instead of error for warnings.
	(end_going_arg): Don't use _() around argument of error.
	(do_spec_1): Use inform for message from %n specs.  Use warning
	instead of error for warnings.
	(main): Use inform for comparison messages.  Use warning for
	message about unused linker input.
	(error): Increment error_count.  Print "error: ".
	* gcc.h (fatal): Change to fatal_error.
	(warning): Declare.
	* config/darwin-driver.c (darwin_default_min_version): Use warning
	instead of fprintf for warnings.
	* cppspec.c (lang_specific_driver): Use fatal_error instead of
	fatal.

cp:
	* g++spec.c (lang_specific_driver): Use fatal_error instead of
	fatal.

fortran:
	* gfortranspec.c (append_arg, lang_specific_driver): Use
	fatal_error instead of fatal.  Use warning instead of fprintf for
	warnings.

java:
	* jvspec.c (lang_specific_driver): Use fatal_error instead of
	fatal.  Use warning instead of error for warnings.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/darwin-driver.c
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/g++spec.c
    trunk/gcc/cppspec.c
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/gfortranspec.c
    trunk/gcc/gcc.c
    trunk/gcc/gcc.h
    trunk/gcc/java/ChangeLog
    trunk/gcc/java/jvspec.c

Comment 8 Joseph S. Myers 2010-05-28 17:29:49 UTC
Fixed for 4.6.