When trying to compile the attached preprocessed files using gcc -c -fwhole-program --combine xterm.i xlwmenu.i These warnings are produced unconditionally: /home/dann/build/Emacs-CVS/emacs/lwlib/xlwmenu.c:57: warning: prototype for 'x_alloc_nearest_color_for_widget' follows non-prototype definition /home/dann/build/Emacs-CVS/emacs/lwlib/xlwmenu.c:58: warning: prototype for 'x_alloc_lighter_color_for_widget' follows non-prototype definition /home/dann/build/Emacs-CVS/emacs/lwlib/xlwmenu.c:64: warning: prototype for 'x_clear_errors' follows non-prototype definition /home/dann/build/Emacs-CVS/emacs/lwlib/xlwmenu.c:65: warning: prototype for 'x_copy_dpy_color' follows non-prototype definition AFAICT the warnings don't make much sense. The code is correct. The functions in questions are defined in one file and then prototyped and used in the other file. This kind of stuff appears in countless C programs. Can this warning be turned off by default?
Created attachment 9807 [details] xterm.i
Created attachment 9808 [details] xlwmenu.i
Actually this is where C standard is werid really.
Because one file uses K&R style function defintions and the other uses a prototype which is ANSI/ISO style. Simple example: file1.c: int f(int); --- file2.c: int f(a) int a; { return a; } --- Compile it as: gcc file2.c file1.c -combine So this about the following: int f(a) int a; { return a; } int f(int); Which is questionable. So I don't think this is not an inappropriate warning. -------------------------------------------- As an aside, I wish people would stop using K&R style C already.
I really want to say this is a bug in their code as x_alloc_nearest_color_for_widget's prototype is in the source file which is bad form really.
(In reply to comment #4) > Because one file uses K&R style function defintions and the other uses a prototype which is ANSI/ISO > style. > Simple example: [snip] > So I don't think this is not an inappropriate warning. The question is: can this EVER result in incorrect behavior? Is it incorrect from the standard point of view? If the answer to the above is no, then there no reason to warn. > -------------------------------------------- > As an aside, I wish people would stop using K&R style C already. Aggreed.
This is not a regression.
(In reply to comment #4) > So this about the following: > int f(a) > int a; > { > return a; > } > int f(int); > > Which is questionable. > > So I don't think this is not an inappropriate warning. It seems that the warning was designed for code like your example above. But if you have 1 K&R file and one C90 file, then there should be no warning... Another bad thing is that if you swap the files on the command line then you get no warning.
Subject: Re: Unconditional warning when using -combine On Mon, Sep 26, 2005 at 08:46:20PM -0000, dann at godzilla dot ics dot uci dot edu wrote: > > So this about the following: > > int f(a) > > int a; > > { > > return a; > > } > > int f(int); > > > > Which is questionable. > > > > So I don't think this is not an inappropriate warning. > > It seems that the warning was designed for code like your example above. > But if you have 1 K&R file and one C90 file, then there should be no warning... > Another bad thing is that if you swap the files on the command line then you get > no warning. There certainly should be a warning. It's not obvious on most targets with int, but what you're doing here won't work with float arguments; if the prototype includes an argument list, the definition should also.
(In reply to comment #9) > Subject: Re: Unconditional warning when using -combine > > On Mon, Sep 26, 2005 at 08:46:20PM -0000, dann at godzilla dot ics dot uci dot edu wrote: > > > So this about the following: > > > int f(a) > > > int a; > > > { > > > return a; > > > } > > > int f(int); > > > > > > Which is questionable. > > > > > > So I don't think this is not an inappropriate warning. > > > > It seems that the warning was designed for code like your example above. > > But if you have 1 K&R file and one C90 file, then there should be no warning... > > Another bad thing is that if you swap the files on the command line then you get > > no warning. > > There certainly should be a warning. It's not obvious on most targets > with int, but what you're doing here won't work with float arguments; > if the prototype includes an argument list, the definition should also. > Sorry, I am not sure I understand what are you referring to... Both in the original bug report and in Andrew's example above both the definition and the prototype included an argument list with types for all the declarations.
We unconditionally warn for a prototype following an old-style definition. The oddity here is that these are in different files, glommed together with --combine, and so don't represent exactly the same sort of style violation as the warning is apparently intended to prevent. I think the point behind comment #9 is that it is important that a prototype always be visible, because one argument may require widening; in a case like the sample code, if this were true, it would result in bugs. See the info node "Prototypes and Old-Style Function Definitions" for details.
-combine has been removed from GCC 4.6 in favor of LTO, closing as WONTFIX.