This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libstdc++/32683] Compiling HPCToolkit causes many errors and warnings using GCC 4.3 (but not prior versions)



------- Comment #7 from rob1weld at aol dot com  2007-07-10 04:55 -------
>------- Comment #3 From Paolo Carlini 2007-07-09 08:43 [reply] ------- 
>Note that in 4.3 the header dependencies have been streamlined and it's well
>possible that some projects around are failing to include required headers. 
>Please double check in this light, thanks.

In _some_ cases that is true "some projects around are failing to include
required headers".


In _other_ cases the problem is that GCC 4.3 has re-ordered the resulting
inclusion sequence by not "polluting" (if that is how you feel about it) some
files with _assumed_ excess header files.

The lack of these _assumed_ excess header files early in the resulting ".ii"
file is causing the undefined errors. Since the "new" GCC 4.3 headers are
'light' (no extra baggage) the include _may_ get used later (in _some_ cases a
'popular' include (like types.h) is _bound_ to be included, in many cases).

Since all correctly written .h (or .hpp) files use [ "#ifndef XXXXX_H" "#define
XXXXX_H" "Eendif" ] to surround themselves (and avoid being included twice) in
the case of removing "sys/types.h" (and likely a couple of others) we have a
situation that causes breakage rather than actually lightening the resulting .h
(or .hpp) file. It would make the resulting object file no smaller either.


Here is an example:


I compiled the files using -save-temps and renamed the ".ii" files by GCC
version. Here is a comparison of the files produced by GCC 4.1 and GCC 4.3:


In file OAInterface_4.1.ii we have this:

/* Line 5955 */
# 1 "/usr/include/sys/types.h" 1 3 4
/* Line 6022 */
typedef unsigned short int ushort;
/* Line 39661 */
  ushort insnSize;



In file OAInterface_4.3.ii we have this:

/* Line 28636 */
  ushort insnSize;
/* Line 33996 */
# 1 "/usr/include/sys/types.h" 1 3 4
/* Line 34063 */
typedef unsigned short int ushort;



Notice that the file "/usr/include/sys/types.h" has it's line number ONE on
line number 5955 using version 4.1, but it is on line 33996 using 4.3 !

The omission of "/usr/include/sys/types.h" from one of the includes in 4.3
(where it was present in 4.1) means that it eventually gets picked up by a 
later include file (in 4.3) and appears too late (after it is neccesary).

This means that source code that worked previously with 4.1 (or older) will
need their local source include files line numbers permutated to occur after
the inclusion of what GCC 4.3 _might_ define in a particular include file and
prior to what any later includes _might_ need defined by that particular local
include.

Simply placing the local includes last in the list of all included files (at
the
top of the source file, assuming that "#include" does not occur later in the
file (like it sometimes does in GCC)) will not always work since the include
files sometimes use defines that activate features used in later includes.

That is a "travelling salesman" problem _BUT_ in addition you need to know
how to alter each "salesman's" wares (not part of the clasical "TS" problem).
That means it is very time consuming; in case what I am saying is unclear.


I don't use C++ much (and know how to fix this) so one of you is welcome to
"Reopen bug" or "Leave as RESOLVED INVALID" - since I did not change the
setting.


I thank you both and appreciate your expert advice on this matter. If this is
how C++ is "really supposed to be" then it is technically correct to leave this
and let the world deal with it's problem. I'm not working the tech support
lines. :)


-- 


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]