[Bug c/24068] New: Unconditional warning when using -fwhole-program

[Bug c/24068] New: Unconditional warning when using -fwhole-program

[dann at godzilla dot ics dot uci dot edu]

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?

-- 
           Summary: Unconditional warning when using -fwhole-program
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dann at godzilla dot ics dot uci dot edu
                CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24068

[Bug c/24068] Unconditional warning when using -fwhole-program

[dann at godzilla dot ics dot uci dot edu]

------- Additional Comments From dann at godzilla dot ics dot uci dot edu  2005-09-26 19:25 -------
Created an attachment (id=9808)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9808&action=view)
xlwmenu.i


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24068

[Bug c/24068] Unconditional warning when using -fwhole-program

[dann at godzilla dot ics dot uci dot edu]

------- Additional Comments From dann at godzilla dot ics dot uci dot edu  2005-09-26 19:25 -------
Created an attachment (id=9807)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9807&action=view)
xterm.i


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24068

[Bug c/24068] Unconditional warning when using -combine

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Unconditional warning when  |Unconditional warning when
                   |using -fwhole-program       |using -combine


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24068

[Bug c/24068] Unconditional warning when using -combine

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-09-26 19:31 -------
Actually this is where C standard is werid really.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24068

[Bug c/24068] Unconditional warning when using -combine

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-09-26 19:41 -------
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.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24068

[Bug c/24068] Unconditional warning when using -combine

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-09-26 19:46 -------
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.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24068

[Bug c/24068] Unconditional warning when using -combine

[dann at godzilla dot ics dot uci dot edu]

------- Additional Comments From dann at godzilla dot ics dot uci dot edu  2005-09-26 19:54 -------
(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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24068

[Bug c/24068] Unconditional warning when using -combine

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-09-26 19:59 -------
This is not a regression.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
      Known to fail|                            |3.4.0 4.0.0 4.1.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24068

[Bug c/24068] Unconditional warning when using -combine

[dann at godzilla dot ics dot uci dot edu]

------- Additional Comments From dann at godzilla dot ics dot uci dot edu  2005-09-26 20:46 -------
(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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24068

[Bug c/24068] Unconditional warning when using -combine

[drow at false dot org]

------- Additional Comments From drow at false dot org  2005-09-29 18:58 -------
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.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24068

[Bug c/24068] Unconditional warning when using -combine

[dann at godzilla dot ics dot uci dot edu]

------- Additional Comments From dann at godzilla dot ics dot uci dot edu  2005-09-29 20:10 -------
(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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24068

[Bug c/24068] Unconditional warning when using -combine

[tromey at gcc dot gnu dot org]

------- Comment #11 from tromey at gcc dot gnu dot org  2007-11-12 20:43 -------
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.


-- 

tromey at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-11-12 20:43:26
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24068

[Bug c/24068] Unconditional warning when using -combine

[rguenth at gcc dot gnu dot org]

------- Comment #12 from rguenth at gcc dot gnu dot org  2010-09-17 09:06 -------
-combine has been removed from GCC 4.6 in favor of LTO, closing as WONTFIX.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24068