[Bug c/37192] New: --combine problems with one source defining _GNU_SOURCE and the other one doesn't

[Bug c/37192] New: --combine problems with one source defining _GNU_SOURCE and the other one doesn't

[edwintorok at gmail dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1925 bytes --]

Consider these two minimal files:
p1.c:
#define _GNU_SOURCE
#include <sys/select.h>

p2.c:
#include <sys/types.h>

They compile just fine by themselves.

Now trying --combine:
$ gcc --combine -c p1.c p2.c
In file included from /usr/include/sys/types.h:220,
                 from p2.c:1:
/usr/include/sys/select.h:109: error: conflicting types for ‘select’
/usr/include/sys/select.h:109: error: previous declaration of ‘select’ was here
/usr/include/sys/select.h:121: error: conflicting types for ‘pselect’
/usr/include/sys/select.h:121: error: previous declaration of ‘pselect’ was
here

Of course the prototype is different with _GNU_SOURCE vs. non _GNU_SOURCE, but
why does --combine care?

$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.1-9'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-cld --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.3.1 (Debian 4.3.1-9)


-- 
           Summary: --combine problems with one source defining _GNU_SOURCE
                    and the other one doesn't
           Product: gcc
           Version: 4.3.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: edwintorok at gmail dot com
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


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

[Bug c/37192] --combine problems with one source defining _GNU_SOURCE and the other one doesn't

[edwintorok at gmail dot com]

------- Comment #1 from edwintorok at gmail dot com  2008-08-21 17:48 -------
Created an attachment (id=16122)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16122&action=view)
preprocessed source 

Generated with:
gcc --combine p1.c p2.c -c -save-temps


-- 


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

[Bug c/37192] --combine problems with one source defining _GNU_SOURCE and the other one doesn't

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2008-08-21 17:50 -------
This sounds like a glibc bug really.  glibc's headers has invalid C in it :).

>why does --combine 
Because GCC checks that the prototypes are compatible across translational
units with --combine and errors out if they are not since that is invalid C :).


-- 


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

[Bug c/37192] --combine problems with one source defining _GNU_SOURCE and the other one doesn't

[edwintorok at gmail dot com]

------- Comment #3 from edwintorok at gmail dot com  2008-08-21 17:52 -------
(In reply to comment #2)
> This sounds like a glibc bug really.  glibc's headers has invalid C in it :).
> 
> >why does --combine 
> Because GCC checks that the prototypes are compatible across translational
> units with --combine and errors out if they are not since that is invalid C :).
> 

Agreed, but I thought --combine is smarter than to just concatenate the
sources.
Compiling the sources separately works, and they are valid C separately.

IMHO LTO should deal with situations like this, or make an exception for system
headers.


-- 


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

[Bug c/37192] --combine problems with one source defining _GNU_SOURCE and the other one doesn't

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2008-08-21 17:56 -------
>Compiling the sources separately works, and they are valid C separately.

Well they are valid if compiled separately but once you link them, they become
invalid C :).  This is one place where the C standard says the code is invalid
but no diagnostic is required.  GCC is producing the diagnostic in --combine
case as it is able to see both prototypes so it complains.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


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

[Bug c/37192] --combine problems with one source defining _GNU_SOURCE and the other one doesn't

[pinskia at gcc dot gnu dot org]

------- Comment #5 from pinskia at gcc dot gnu dot org  2008-08-21 17:57 -------
> IMHO LTO should deal with situations like this, or make an exception for system headers.

No glibc should be fixed instead really.


-- 


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