gcc-4.1-20051105 is now available
Snapshot gcc-4.1-20051105 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20051105/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: /trunk You'll find: gcc-4.1-20051105.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20051105.tar.bz2 C front end and core compiler gcc-ada-4.1-20051105.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20051105.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20051105.tar.bz2 C++ front end and runtime gcc-java-4.1-20051105.tar.bz2 Java front end and runtime gcc-objc-4.1-20051105.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20051105.tar.bz2The GCC testsuite Diffs from 4.1-20051029 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
[RFC] Enabling loop unrolls at -O3?
Hello, any specific reason why we still don't unroll loops by default at -O3? It looks like it gives better results on most benchmark, and many people use it always together with -O3 to say "really optimize, I mean it". Giovanni Bajo Index: opts.c === --- opts.c (revision 106352) +++ opts.c (working copy) @@ -589,6 +589,7 @@ decode_options (unsigned int argc, const flag_inline_functions = 1; flag_unswitch_loops = 1; flag_gcse_after_reload = 1; + flag_unroll_loops = 1; } if (optimize < 2 || optimize_size)
Re: [RFC] Enabling loop unrolls at -O3?
Giovanni Bajo wrote: Hello, any specific reason why we still don't unroll loops by default at -O3? It looks like it gives better results on most benchmark, and many people use it always together with -O3 to say "really optimize, I mean it". Why O3 rather than O2, I thought O3 was just O2 + implicit inlining (we often find with Ada that implicit inlining is a bad idea, since Ada programmers routinely mark inlinable stuff as inlinable, and so having the compiler second guess this often pessimizes the code).
Re: [libgfortran] Patch to handle statically linked libgfortran
> Sorry for these stupid errors, I should really have read that one
> through one more time before posting. Attached is an updated version
> with both errors corrected. OK?
That doesn't work for me on Solaris when there is no static glibc (e.g. 64-bit
mode on Solaris 9):
check_effective_target_static_libgfortran doesn't work because it doesn't
compile with -static:
/opt/build/eric/gcc-4_0-branch/gcc/xgcc
Testing gfortran.dg/static_linking_1.f, -O0
check_effective_target_static_libgfortran: `' `unix'
check_effective_target_static_libgfortran compiling testfile static25620.f
options1: -static
options2: -static
options3: -static
{compiler=/opt/build/eric/gcc-4_0-branch/gcc/testsuite/../gfortran
-B/opt/build/eric/gcc-4_0-branch/gcc/testsuite/../}
options4:
{ldflags=-L/opt/build/eric/gcc-4_0-branch/sparc64-sun-solaris2.9/./libgfortran/.libs
-L/opt/build/eric/gcc-4_0-branch/sparc64-sun-solaris2.9/./libiberty } -static
{compiler=/opt/build/eric/gcc-4_0-branch/gcc/testsuite/../gfortran-B/opt/build/eric/gcc-4_0-branch/gcc/testsuite/../}
doing compile
Invoking the compiler
as /opt/build/eric/gcc-4_0-branch/gcc/testsuite/../gfortran
-B/opt/build/eric/gcc-4_0-branch/gcc/testsuite/../ static25620.f
-L/opt/build/eric/gcc-4_0-branch/sparc64-sun-solaris2.9/./libgfortran/.libs
-L/opt/build/eric/gcc-4_0-branch/sparc64-sun-solaris2.9/./libiberty -lm -o
static25620.x
Executing on host: /opt/build/eric/gcc-4_0-branch/gcc/testsuite/../gfortran
-B/opt/build/eric/gcc-4_0-branch/gcc/testsuite/../ static25620.f
-L/opt/build/eric/gcc-4_0-branch/sparc64-sun-solaris2.9/./libgfortran/.libs
-L/opt/build/eric/gcc-4_0-branch/sparc64-sun-solaris2.9/./libiberty -lm -o
static25620.x(timeout = 300)
pid is 25755 -25755
waitres is 25755 exp9 0 0
output is
Checking pattern "sparc-*-sunos*" with sparc64-sun-solaris2.9
Checking pattern "alpha*-*-*" with sparc64-sun-solaris2.9
Checking pattern "hppa*-*-hpux*" with sparc64-sun-solaris2.9
is-effective-target: static_libgfortran 1
with an instrumented gfortran_target_compile:
proc gfortran_target_compile { source dest type options } {
global tmpdir;
global gluefile wrap_flags
global ALWAYS_GFORTRANFLAGS;
global GFORTRAN_UNDER_TEST;
verbose "options1: $options" 2
if { [target_info needs_status_wrapper] != "" && [info exists gluefile] }
{
lappend options "libs=${gluefile}"
lappend options "ldflags=${wrap_flags}"
}
verbose "options2: $options" 2
lappend options "compiler=$GFORTRAN_UNDER_TEST";
verbose "options3: $options" 2
set options [concat "$ALWAYS_GFORTRANFLAGS" $options];
set options [dg-additional-files-options $options $source]
verbose "options4: $options" 2
return [target_compile $source $dest $type $options]
}
--
Eric Botcazou
Re: [RFC] Enabling loop unrolls at -O3?
On Saturday 05 November 2005 18:54, Giovanni Bajo wrote: > Hello, > > any specific reason why we still don't unroll loops by default at -O3? It > looks like it gives better results on most benchmark, and many people use > it always together with -O3 to say "really optimize, I mean it". One reason why it's not enabled is because it causes a huge compile time regression. Gr. Steven
Re: [RFC] Enabling loop unrolls at -O3?
> Why O3 rather than O2, I thought O3 was just O2 + implicit inlining In the old days only, i.e. that has not been true since 3.1 at least. -- Eric Botcazou
Re: [RFC] Enabling loop unrolls at -O3?
Steven Bosscher wrote: One reason why it's not enabled is because it causes a huge compile time regression. For the majority of Ada applications, as opposed to specific bench marks, we see little gain in -O2 over -O1 in any case, although that's for GCC 3.4 and it is always possible that GCC 4 is qualitatively different in this respect (I doubt it, optimizations are always less significant in real applications than you hope). Thus -O1 seems the general best choice if compile time is an issue. I think it is reasonable to figure that -O2 means I want good performance regardless of compile time. I guess the issue is what does "huge" mean, it is hard to discuss based on loaded adjectives taking the place of data :-)
Re: [RFC] Enabling loop unrolls at -O3?
Eric Botcazou wrote: Why O3 rather than O2, I thought O3 was just O2 + implicit inlining In the old days only, i.e. that has not been true since 3.1 at least. OK, so perhaps we should routinely recommend -O3 -fno-inline (I trust that turns off only the automatic inlining, and not the explicit inlining?) We should evaluate this again as soon as gcc 4 is working well enough to do so with GNAT (not quite true yet, but getting there).
Re: [RFC] Enabling loop unrolls at -O3?
On Saturday 05 November 2005 19:11, Robert Dewar wrote: > I guess the issue is what does "huge" mean, it is hard to discuss based > on loaded adjectives taking the place of data :-) Huge here means 15-20% on x86* hosts. Gr. Steven
copyright assignement
Hi, I'd like to contribute to the development of gfortran and for that, it appears that filling a copyright assignment form is mandatory. Can someone tell me where to get this? Thanks. -- Pierre-Matthieu Anglade
Re: [RFC] Enabling loop unrolls at -O3?
Steven Bosscher <[EMAIL PROTECTED]> wrote: >> I guess the issue is what does "huge" mean, it is hard to discuss based >> on loaded adjectives taking the place of data :-) > > Huge here means 15-20% on x86* hosts. I don't consider this huge for -O3. I think -O3 can be slower if it achieves better code, and -funroll-loops makes it do just that. -- Giovanni Bajo
Re: [RFC] Enabling loop unrolls at -O3?
> > Eric Botcazou wrote: > >>Why O3 rather than O2, I thought O3 was just O2 + implicit inlining > > > In the old days only, i.e. that has not been true since 3.1 at least. > > OK, so perhaps we should routinely recommend -O3 -fno-inline (I trust > that turns off only the automatic inlining, and not the explicit > inlining?) -O3 -fno-inline-functions is what you want. That turns off the automatic inlining. -- Pinski
Re: [RFC] Enabling loop unrolls at -O3?
On 11/5/05, Giovanni Bajo <[EMAIL PROTECTED]> wrote: > Steven Bosscher <[EMAIL PROTECTED]> wrote: > > >> I guess the issue is what does "huge" mean, it is hard to discuss based > >> on loaded adjectives taking the place of data :-) > > > > Huge here means 15-20% on x86* hosts. > > I don't consider this huge for -O3. I think -O3 can be slower if it achieves > better code, and -funroll-loops makes it do just that. First of all, this is too late for 4.1, second, we enable loop-unrolling with FDO. And without FDO, -funroll-loops is not necessarily an improvement. Richard.
Re: [RFC] Enabling loop unrolls at -O3?
Richard Guenther <[EMAIL PROTECTED]> wrote: I guess the issue is what does "huge" mean, it is hard to discuss based on loaded adjectives taking the place of data :-) >>> >>> Huge here means 15-20% on x86* hosts. >> >> I don't consider this huge for -O3. I think -O3 can be slower if it >> achieves better code, and -funroll-loops makes it do just that. > > First of all, this is too late for 4.1, second, we enable loop-unrolling > with FDO. And without FDO, -funroll-loops is not necessarily an > improvement. What is FDO? My feeling is that -funroll-loops is almost always an improvement. It might be false sometimes, but this can be said of many optimization passes. -- Giovanni Bajo
Re: [RFC] Enabling loop unrolls at -O3?
On 11/5/05, Giovanni Bajo <[EMAIL PROTECTED]> wrote: > Richard Guenther <[EMAIL PROTECTED]> wrote: > > I guess the issue is what does "huge" mean, it is hard to discuss based > on loaded adjectives taking the place of data :-) > >>> > >>> Huge here means 15-20% on x86* hosts. > >> > >> I don't consider this huge for -O3. I think -O3 can be slower if it > >> achieves better code, and -funroll-loops makes it do just that. > > > > First of all, this is too late for 4.1, second, we enable loop-unrolling > > with FDO. And without FDO, -funroll-loops is not necessarily an > > improvement. > > What is FDO? Feedback Directed Optimization, i.e. -fprofile-generate/-fprofile-use. > My feeling is that -funroll-loops is almost always an improvement. It might > be false sometimes, but this can be said of many optimization passes. Can you back up this feeling with numbers? SPEC -O2 vs. -O2 -funroll-loops and/or -O3 vs. -O3 -funroll-loops would do it. Richard.
Re: [RFC] Enabling loop unrolls at -O3?
Richard Guenther <[EMAIL PROTECTED]> wrote: >> My feeling is that -funroll-loops is almost always an improvement. It might >> be false sometimes, but this can be said of many optimization passes. > > Can you back up this feeling with numbers? SPEC -O2 vs. -O2 -funroll-loops > and/or -O3 vs. -O3 -funroll-loops would do it. I don't have access to SPEC, sorry. I believe you do, though? -- Giovanni Bajo
Re: [RFC] Enabling loop unrolls at -O3?
> > Richard Guenther <[EMAIL PROTECTED]> wrote: > > >> My feeling is that -funroll-loops is almost always an improvement. It > might > >> be false sometimes, but this can be said of many optimization passes. > > > > Can you back up this feeling with numbers? SPEC -O2 > vs. -O2 -funroll-loops > > and/or -O3 vs. -O3 -funroll-loops would do it. > > > I don't have access to SPEC, sorry. I believe you do, though? The last time this was proposed, -funroll-loops caused a couple of wrong-code in SPEC but nobody had the time to look into them. Note I proposed it and I don't think it is correct at this late stage into 4.1's release and it is not a bug fix either. -- Pinski
Re: [RFC] Enabling loop unrolls at -O3?
Andrew Pinski <[EMAIL PROTECTED]> wrote: > Note I proposed it and I don't think it is correct at this late > stage into 4.1's release and it is not a bug fix either. I never mentioned 4.1. Consider this patch proposed for 4.2. -- Giovanni Bajo
Re: [RFC] Enabling loop unrolls at -O3?
On Saturday 05 November 2005 19:49, Giovanni Bajo wrote: > My feeling is that -funroll-loops is almost always an improvement. It might > be false sometimes, but this can be said of many optimization passes. You can't enable an option based on a feeling ;-) Gr. Steven
Is -fvisibility patch possible on GCC 3.3.x
Hi, The -fvisibility feature in GCC 4.0 is a really useful way of hiding all non-public symbols in a dynamic shared object. While I'm aware of a patch which backports this feature to GCC 3.4 (over at nedprod.com), I was wondering whether there is a similar patch available for GCC 3.3. I'm aware that GCC 3.3 (and some vintages of 3.2) support the __attribute__ means of setting a symbol's visibility, but I want to be able to change the default visibility for all symbols. The problem is that we're stuck for now with the GCC 3.3 compiler as we need v5 ABI compatibility for Orbix 6.2 and cannot move to 3.4 until Iona catch up. Does anyone know if such a patch exists, or even if it is feasible in the 3.3 framework? Thanks, Gary
Re: [RFC] Enabling loop unrolls at -O3?
Giovanni Bajo wrote: Steven Bosscher <[EMAIL PROTECTED]> wrote: I guess the issue is what does "huge" mean, it is hard to discuss based on loaded adjectives taking the place of data :-) Huge here means 15-20% on x86* hosts. I don't consider this huge for -O3. I think -O3 can be slower if it achieves better code, and -funroll-loops makes it do just that. I would certainly agree, I am not sure I even find it huge for -O2. After all 20% compile time represents a couple of months advance in computer hardware (and that is true across the board, even if you are talking about upgrading 1990 hardware to 1991 hardware :-))
Re: GCC-generated code and i386 condition codes behavior
Paolo Bonzini wrote: Paolo, who made the first paid computer work on Realia COBOL well that is fun ... quite a while ago :-)
Re: [RFC] Enabling loop unrolls at -O3?
On Sunday 06 November 2005 01:12, Robert Dewar wrote: > Giovanni Bajo wrote: > > Steven Bosscher <[EMAIL PROTECTED]> wrote: > >>>I guess the issue is what does "huge" mean, it is hard to discuss based > >>>on loaded adjectives taking the place of data :-) > >> > >>Huge here means 15-20% on x86* hosts. > > > > I don't consider this huge for -O3. I think -O3 can be slower if it > > achieves better code, and -funroll-loops makes it do just that. > > I would certainly agree, I am not sure I even find it huge for -O2. > After all 20% compile time represents a couple of months advance > in computer hardware (and that is true across the board, even if > you are talking about upgrading 1990 hardware to 1991 hardware :-)) You must not have been paying attention to one of the most frequent complaints about gcc, which is that it is dog slow already ;-) Gr. Steven
Re: [RFC] Enabling loop unrolls at -O3?
Steven Bosscher <[EMAIL PROTECTED]> wrote: >>> Steven Bosscher <[EMAIL PROTECTED]> wrote: > I guess the issue is what does "huge" mean, it is hard to discuss > based on loaded adjectives taking the place of data :-) Huge here means 15-20% on x86* hosts. >>> >>> I don't consider this huge for -O3. I think -O3 can be slower if it >>> achieves better code, and -funroll-loops makes it do just that. >> >> I would certainly agree, I am not sure I even find it huge for -O2. >> After all 20% compile time represents a couple of months advance >> in computer hardware (and that is true across the board, even if >> you are talking about upgrading 1990 hardware to 1991 hardware :-)) > > You must not have been paying attention to one of the most frequent > complaints about gcc, which is that it is dog slow already ;-) It's not disabling the optimizers that you are making it faster. I believe you are missing my point. What is the GCC command line option for "try to optimize as best as you can, please, I don't care compiletime"? I believe that should be -O3. Otherwise let's make -O4. Or -O666. The only real argument I heard till now is that -funroll-loops isn't valuable without profile feedback. My experience is that it isn't true, I for sure use it for profit in my code. But it looks like the only argument that could make a difference is SPEC, and SPEC is not freely available. So I'd love if someone could SPEC -funroll-loops for me. Giovanni Bajo
Re: [RFC] Enabling loop unrolls at -O3?
Steven Bosscher wrote: You must not have been paying attention to one of the most frequent complaints about gcc, which is that it is dog slow already ;-) Sure, but to me -O2 says you don't care much about compilation time. As I say for complete large applications, I am not sure -O2 gains that much over -O2 in performance so you are asking to squeeze out a small amount of performance at the expense of compile time. It seems wrong in such a case to shy away from an optimization on the grounds that it improves performance but increases compile time. I am not clear what the philosophy of the difference between -O2 and -O3 is supposed to be ...
Re: [RFC] Enabling loop unrolls at -O3?
Giovanni Bajo wrote: I believe you are missing my point. What is the GCC command line option for "try to optimize as best as you can, please, I don't care compiletime"? I believe that should be -O3. Otherwise let's make -O4. Or -O666. The only real argument I heard till now is that -funroll-loops isn't valuable without profile feedback. My experience is that it isn't true, I for sure use it for profit in my code. But it looks like the only argument that could make a difference is SPEC, and SPEC is not freely available. So I'd love if someone could SPEC -funroll-loops for me. It is not at all the case that SPEC is the only good argument, in fact SPEC on its own is a bad argument. Much more important is impact on real life applications, so your data point that it makes a significant difference for your application is more interesting than SPEC marks. When it comes to GCC, we are more interested in performance than good SPEC figures! Giovanni Bajo
Problem with commas in macro parameters
Hello!
That's probably an old problem, but I haven't found any notion of
it in GCC docs. So...
I need to have a macro which takes ONE argument, and either
ignores it or outputs a "=arg":
#ifdef __SOMEFILE_C
#define D
#define V(value) = value
#else
#define D extern
#define V(value)
#endif /* __SOMEFILE_C */
(The file itself is somefile.h, and it must either define variables if
included from somefile.c, or simply declare the same variables, when
included from other source files.)
This works fine, until I try to pass it some complex value:
D int some_array[2] V({4,5})
causes an error stating that I'm trying to pass two parameters when only
one is expected.
This looks like C preprocessor is slightly inadequate... What I'm
passing is a SIGNLE valid C expression, but, due to intentionally-ignorant
nature of CPP, curly braces aren't recognized and the expression is
treated as TWO separate arguments...
I've tried the "usual" trick -- adding extra braces:
D int some_array[2] V(({4,5}))
but that doesn't work either --
error: braced-group within expression allowed only inside a function
(this error is issued by both gcc-2.95 and gcc-3.4.4; haven't checked
gcc-4 yet).
Sure, I can "#define COMMA ," and write "V({4 COMMA 5})", but
that's ugly and leads to other undesired consequences.
The question is: the construct I'm trying to use is quite
reasonable -- is there any "good" solution for this problem?
Thanks in advance!
_
Dmitry Yu. Bolkhovityanov
The Budker Institute of Nuclear Physics
Novosibirsk, Russia
successful 3.3.6 bootstrap on i686-pc-linux-gnu
1. Output from running srcdir/config.guess:
i686-pc-linux-gnu
2. The output of gcc -v for my newly installed gcc:
Reading specs from
/opt/gcc-3.3.6/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/specs
Configured with: ../gcc-3.3.6/configure --prefix=/opt/gcc-3.3.6
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-languages=c,c++ --disable-nls
Thread model: posix
gcc version 3.3.6
3. I downloaded and enabled only "core" and "g++".
4. The distribution name and version:
Hand-crafted, based on the first release of an ancient bare-bones distro
named "coredistro" (http://coredistro.sf.net), which was, in turn, based
on LFS (http://www.linuxfromscratch.org), and is now, to my knowledge,
defunct.
5. The version of the Linux kernel:
2.4.31 vanilla
6. The version of glibc you used:
2.2.4. Binutils is 2.16.1.
Two notes:
a) First I tried to disable the fixincludes script as suggested in
http://archives.linuxfromscratch.org/lfs-museum/5.1.1/LFS-BOOK-5.1.1-HTML/chapter05/gcc-pass2.html,
because I plan to update my glibc, so that I can use gcc-4. After I
manually realized
http://www.linuxfromscratch.org/patches/lfs/5.1.1/gcc-3.3.3-no_fixincludes-1.patch,
the build failed at the first invocation of xgcc. I started from the
beginning, letting fixincludes run, and everything worked.
b) After installation I tried to compile one C and one C++ two-liner. Both
C_INCLUDE_PATH and CPLUS_INCLUDE_PATH were set to
/usr/include:/usr/local/include. g++ was unable to compile the two-liner
until I removed /usr/include from CPLUS_INCLUDE_PATH. Then it succeeded.
Thank you
lacos
Two-liner:
#include
int main() { std::cout << "Hello world!" << std::endl; }
Failed to compile:
$ CPLUS_INCLUDE_PATH=/usr/include:/usr/local/include g++ -v a.cpp
Reading specs from
/opt/gcc-3.3.6/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/specs
Configured with: ../gcc-3.3.6/configure --prefix=/opt/gcc-3.3.6
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-languages=c,c++ --disable-nls
Thread model: posix
gcc version 3.3.6
/opt/gcc-3.3.6/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/cc1plus -quiet -v
-D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=6 -D_GNU_SOURCE
a.cpp -D__GNUG__=3 -quiet -dumpbase a.cpp -auxbase a -version -o
/tmp/ccokBQIh.s
GNU C++ version 3.3.6 (i686-pc-linux-gnu)
compiled by GNU C version 3.3.6.
GGC heuristics: --param ggc-min-expand=47 --param ggc-min-heapsize=32129
ignoring nonexistent directory "/opt/gcc-3.3.6/i686-pc-linux-gnu/include"
ignoring duplicate directory "/usr/local/include"
ignoring duplicate directory "/usr/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/include
/usr/local/include
/opt/gcc-3.3.6/include/c++/3.3.6
/opt/gcc-3.3.6/include/c++/3.3.6/i686-pc-linux-gnu
/opt/gcc-3.3.6/include/c++/3.3.6/backward
/opt/gcc-3.3.6/include
/opt/gcc-3.3.6/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/include
End of search list.
In file included from
/opt/gcc-3.3.6/include/c++/3.3.6/i686-pc-linux-gnu/bits/gthr-default.h:37,
from
/opt/gcc-3.3.6/include/c++/3.3.6/i686-pc-linux-gnu/bits/gthr.h:98,
from
/opt/gcc-3.3.6/include/c++/3.3.6/i686-pc-linux-gnu/bits/c++io.h:37,
from /opt/gcc-3.3.6/include/c++/3.3.6/bits/fpos.h:44,
from /opt/gcc-3.3.6/include/c++/3.3.6/iosfwd:49,
from /opt/gcc-3.3.6/include/c++/3.3.6/ios:44,
from /opt/gcc-3.3.6/include/c++/3.3.6/ostream:45,
from /opt/gcc-3.3.6/include/c++/3.3.6/iostream:45,
from a.cpp:1:
/usr/include/pthread.h:163: error: syntax error before `__thread'
/usr/include/pthread.h:165: error: `pthread_create' declared as function
returning a function
/usr/include/pthread.h:166: error: syntax error before `void'
/usr/include/pthread.h:591: error: storage class specifiers invalid in
parameter declarations
/usr/include/pthread.h:591: error: storage class specified for parameter `
parameter'
In file included from /usr/include/pthread.h:655,
from
/opt/gcc-3.3.6/include/c++/3.3.6/i686-pc-linux-gnu/bits/gthr-default.h:37,
from
/opt/gcc-3.3.6/include/c++/3.3.6/i686-pc-linux-gnu/bits/gthr.h:98,
from
/opt/gcc-3.3.6/include/c++/3.3.6/i686-pc-linux-gnu/bits/c++io.h:37,
from /opt/gcc-3.3.6/include/c++/3.3.6/bits/fpos.h:44,
from /opt/gcc-3.3.6/include/c++/3.3.6/iosfwd:49,
from /opt/gcc-3.3.6/include/c++/3.3.6/ios:44,
from /opt/gcc-3.3.6/include/c++/3.3.6/ostream:45,
from /opt/gcc-3.3.6/include/c++/3.3.6/iostream:45,
from a.cpp:1:
/usr/include/bits/sigthread.h:36: error: storage class specifiers invalid
in
parameter declarations
/usr/include/bits/sigthread.h:36: error: storage class specified for
parameter
`parameter'
Success:
$ CPLUS_INCLUDE_PATH=/usr/local/include g++ -v a.cpp
Reading s
