<< Back to previous view

[PCC-419] files included from system-include files, need to be treated as system-include files Created: 26/Mar/13  Updated: 21/Apr/14

Status: Closed
Project: pcc
Component/s: C preprocessor
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Iain Hibbert Assignee: Iain Hibbert
Resolution: Won't Fix Votes: 0
Environment: NetBSD/i386 (current sources as of March 2013)


 Description   
I found a problem compiling in NetBSD, where some symbols were being reported as duplicately defined, but gcc did not complain about this. I have narrowed this down to the following (somewhat environment dependent) example

#include <machine/limits.h>
#include <float.h>

and compiling this produces

% pcc -E -I/usr/src/sys foo.c | grep float
/usr/src/sys/sys/float_ieee754.h:78: warning: FLT_DIG redefined (previously defined at "/usr/include//machine/limits.h" line 86)
# 1 "/usr/include//float.h" 3
/usr/src/sys/sys/float_ieee754.h:80: warning: FLT_MIN redefined (previously defined at "/usr/include//machine/limits.h" line 88)
/usr/src/sys/sys/float_ieee754.h:83: warning: FLT_MAX redefined (previously defined at "/usr/include//machine/limits.h" line 87)
/usr/src/sys/sys/float_ieee754.h:88: warning: DBL_DIG redefined (previously defined at "/usr/include//machine/limits.h" line 82)
/usr/src/sys/sys/float_ieee754.h:90: warning: DBL_MIN redefined (previously defined at "/usr/include//machine/limits.h" line 84)
/usr/src/sys/sys/float_ieee754.h:93: warning: DBL_MAX redefined (previously defined at "/usr/include//machine/limits.h" line 83)
# 1 "/usr/include//x86/float.h" 3
# 1 "/usr/src/sys/sys/float_ieee754.h"
# 42 "/usr/src/sys/sys/float_ieee754.h"
# 43 "/usr/src/sys/sys/float_ieee754.h"
# 51 "/usr/src/sys/sys/float_ieee754.h"
# 53 "/usr/src/sys/sys/float_ieee754.h"
# 16 "/usr/include//x86/float.h" 3
# 3 "/usr/include//float.h" 3

and with gcc

% gcc -I /usr/src/sys/ -E foo.c | grep float
# 1 "/usr/include/float.h" 1 3 4
# 1 "/usr/include/x86/float.h" 1 3 4
# 16 "/usr/include/x86/float.h" 3 4
# 1 "/usr/src/sys/sys/float_ieee754.h" 1 3 4
# 42 "/usr/src/sys/sys/float_ieee754.h" 3 4
# 43 "/usr/src/sys/sys/float_ieee754.h" 2 3 4
# 44 "/usr/src/sys/sys/float_ieee754.h" 2 3 4
# 51 "/usr/src/sys/sys/float_ieee754.h" 3 4
# 51 "/usr/src/sys/sys/float_ieee754.h" 3 4
# 53 "/usr/src/sys/sys/float_ieee754.h" 3 4
# 53 "/usr/src/sys/sys/float_ieee754.h" 3 4
# 17 "/usr/include/x86/float.h" 2 3 4
# 3 "/usr/include/float.h" 2 3 4

as you can see, pcc produces an error but also the flags on the output indicate that the /usr/src/sys/sys/float_ieee754.h file which was included from /usr/include/float.h is treated by gcc as a system-include file (even though it was not in the system-include directories), therefore no error about duplicate symbols is produced, whereas with pcc the file is not treated that way, and a diagnostic is produced

I think this may have always been the case, but since I changed the front end to pass -Werror to cpp, this results in an error.

 Comments   
Comment by Anders Magnusson [ 27/Mar/13 10:12 AM ]
Redefinition of the same definition to identical value is allowed, and that has worked in cpp.
Can you check that this is the same?

Gcc also have some trick that system defines quietly overrides local defines, or something, that our cpp also should support.
Comment by Iain Hibbert [ 27/Mar/13 11:05 PM ]
I could probably fabricate a better example, but the definitions in this case are slightly different though they resolve to the same in the end, eg

/usr/include/machine/limits.h:
  #define FLT_DIG 6

/usr/src/sys/sys/float_ieee754.h:
  #define FLT_DIG __FLT_DIG__

with __FLT_DIG__ being provided by pcc front end as -D__FLT_DIG__=6

I managed to also contrive to get gcc to complain about the redefinition, but only if the second file is not treated as a system-include file.

(I hope to have some time in the next couple of weeks to look at this closer)
Comment by Iain Hibbert [ 11/Apr/14 12:48 PM ]
here is a testcase which does not depend on environment

% cat test.c
#define FOO xxx
#define BAR xxx

#include <foo.h>
% cat foo/foo.h
#define FOO foo

#include <bar.h>
% cat bar/bar.h
#define BAR bar

So, this seems straightforward.. when compiled normally pcc produces warnings:

% pcc -c -I foo -I bar test.c
bar/bar.h:1: warning: BAR redefined (previously defined at "test.c" line 2)
foo/foo.h:3: warning: FOO redefined (previously defined at "test.c" line 1)

but it seems dubious if the foo.h file is moved to a system include directory. Strictly, the bar.h file was not in a system include directly, but it was included from a system file. The FOO warning goes away, but the BAR remains:

% pcc -c -isystem foo -I bar test.c
bar/bar.h:1: warning: BAR redefined (previously defined at "test.c" line 2)

Whereas GCC does not complain about this, since it considers that once it has entered a system include directory, all files subsequently descended into are considered as system headers:

% gcc -c -isystem foo -I bar test.c

It is not clear from the documentation that this is intended behaviour, so I do not know if this should be considered a bug in pcc, what do you think? I can fix pcc to be in line with GCC, or I can go back and work on the NetBSD sources to make this redefinition not happen..
Comment by Iain Hibbert [ 21/Apr/14 05:06 PM ]
I am closing this, it is not clear to me that pcc is doing anything wrong though it does act slightly differently than gcc and clang in the handling of system include directories (pcc follows the documentation!)

In the meantime, the upstream NetBSD sources have been changed and this should no longer be an issue.
Generated at Sun Nov 23 19:45:57 CET 2014 using JIRA Enterprise Edition, Version: 3.13.1-#333.