Is gcc optimized for thread level parallelism?

[x z]

Is gcc optimized for thread level parallelism, in view of the recent 
development of SMT and multicore architectures?  Does gcc look for thread 
level parallelism given a single threaded program (that is, when the 
programmer does not parallelize the program using pthread etc.)?
And does gcc support any NUMA (non-uniform memory access) machines?  That 
is, does gcc
a) automatically parallelize the program for as many processors in the 
machine as possible?
b) take advantage of the non-uniform memory access (i.e. co-locate a thread 
and the data it needs on a particular processor)?

Feature request - a macro defined for GCC

[x z]

I would like to see that GCC define a macro in the case it is being used to 
compile a program. Currently there is a __GNUC__ macro defined by the GNU C 
preprocessor CPP.  That does not suit the need.  As the CPP Manual says: 
__GNUC__ is "defined by all GNU compilers that use the C preprocessor".  It 
seems to imply that any (non-GNU) compiler that uses the GNU C preprocessor 
would also have __GNUC__ defined.  According to their respective manuals, Intel 
C++ Compiler and Portable C Compiler also pre-define __GNUC__, possibly because 
they use the GNU CPP.  Therefore, the fact that __GNUC__ is defined does not 
necessarily mean the GCC compiler proper is being used.  There is a need for a 
macro that definitely confirms that GCC is being used.  (It is another matter 
if another complier deliberately misleads people by defining the same macro.) 
And I hope that macro can be documented in the GCC Manual.

_
Need to know now? Get instant answers with Windows Live Messenger.
http://www.windowslive.com/messenger/connect_your_way.html?ocid=TXT_TAGLM_WL_Refresh_messenger_062008

Re: Feature request - a macro defined for GCC

[x z]

I think an important point was missed in the discussion.  Some seem to focus on 
the dishonest definition of __GNUC__ by non-GNU C compilers.  That was not my 
point.  My point is that if __GNUC__ is defined by CPP, not the GNU C compiler 
proper, (and this seems to be supported by the CPP Manual,) and any (non-GNU) C 
compiler can use CPP, then those non-GNU C compilers would "inadverdently" 
define __GNUC__ and lead people to believe that they are GNU C.  That is why I 
think the GNU C compiler should define a macro independently from CPP.  Or, 
alternatively, __GNUC__ should be defined by the GCC compiler proper, not CPP.
_
The i’m Talkaton. Can 30-days of conversation change the world?
http://www.imtalkathon.com/?source=EML_WLH_Talkathon_ChangeWorld

RE: Feature request - a macro defined for GCC

[x z]

> I very much doubt that any compiler other than gcc uses the gcc
> preprocessor.
>
> In any case, the documentation has in some sense misled you. __GNUC__
> is indeed defined by the compiler proper, not by the preprocessor.
> But that in turn does not matter, as if any non-gcc compiler *did* use
> the gcc preprocessor, it would do so via gcc -E. In gcc, the
> preprocessor is not a separate program.

Just one piece of info: A mpC compiler for parallel language uses GNU CPP: "The 
mpC compiler uses standard preprocessor cpp. You should specify the directory 
where cpp is placed when editing Makefile. We recommend to use GNU cpp."  
(http://www.ispras.ru/~mpc/mpc-122-iguide.html).  I know, mpC is not exactly a 
C compiler.  But it seems that it is feasible (and was done) to use GNU CPP as 
a preprocesser in a compiler for C or a language based on C.

_
Need to know now? Get instant answers with Windows Live Messenger.
http://www.windowslive.com/messenger/connect_your_way.html?ocid=TXT_TAGLM_WL_messenger_072008

RE: Feature request - a macro defined for GCC

[x z]

> In any case, the documentation has in some sense misled you. __GNUC__
> is indeed defined by the compiler proper, not by the preprocessor.
> But that in turn does not matter, as if any non-gcc compiler *did* use
> the gcc preprocessor, it would do so via gcc -E. 

> Googling "Intel C++ __GNUC__" shows several major projects have been
> affected by this icc misfeature.

Upon further checking the GNU CPP Manual, some interesting things are revealed.
The current manual 
(http://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html#Common-Predefined-Macros)
 (version unspecified) says: 
__GNUC__
__GNUC_MINOR__
__GNUC_PATCHLEVEL__
These macros are defined by all GNU compilers that use the C preprocessor: C, 
C++, Objective-C and Fortran. ... These macros are also defined if you invoke 
the preprocessor directly.  ... If all you need to know is whether or not your 
program is being compiled by GCC, or a non-GCC compiler that claims to accept 
the GNU C dialects, you can simply test __GNUC__. 
Therefore, Intel C++ Compiler's definition of __GNUC__ appears to be legitimate 
if Intel honestly makes a reasonable claim that its compiler accepts the GNU C 
dialects.
In comparison, the GNU CPP 2.8.1 (1997) Manual 
(http://sunsite.ualberta.ca/Documentation/Gnu/gcc-2.8.1/html_node/cpp_13.html#SEC14)
  says:
__GNUC__ 
This macro is defined if and only if this is GNU C. This macro is defined only 
when the entire GNU C compiler is in use; if you invoke the preprocessor 
directly, `__GNUC__' is undefined. 
It seems this 1997 definition is more strict: a non-GCC compiler should never 
define __GNUC__.  In other words, in 1997, __GNUC__ can be used to uniquely 
identify the GNU C compiler, now it can't; and nothing can.  
On the other hand, the 1997 sentence "if you invoke the preprocessor directly, 
`__GNUC__' is undefined" is now replaced by "These macros are also defined if 
you invoke the preprocessor directly."  I have not had the time to find out 
what "invoke the preprocessor directly" means ('gcc -E' ?) but now the 
implication is that a non-'GNU C'-compliant compiler that uses GNU CPP as its 
preprocessor would have __GNUC__ defined, unless it takes the extra effort to 
somehow undefine it.
And this also raises an interesting question: "These macros are also defined if 
you invoke the preprocessor directly" seems to imply that __GNUC__ is defined 
by the preprocessor, not the compiler proper.  This appears to contradict the 
claim in a previous post (see above quote) that "__GNUC__ is indeed defined by 
the compiler proper, not by the preprocessor."
_
It’s a talkathon – but it’s not just talk.
http://www.imtalkathon.com/?source=EML_WLH_Talkathon_JustTalk

RE: Feature request - a macro defined for GCC

[x z]

This is somewhat off-topic.  Perhaps the GCC development team should
consider making this __GNUC__ stuff more clarified in the GCC Manual.
Now, this __GNUC__ stuff appears to appear only in the CPP Manual
(section 3.7.2).  And the definition of similar macros such as __GFORTRAN__
and __GNUG__ may need to be further explained in this vein.  Currently, 
__GFORTRAN__ means "The GNU Fortran compiler defines this."  Should it 
rather mean "This is a GNU Fortran-complaint compiler", to be consistent
with the meaning of __GNUC__?  And, for example, should there be 
__GNUG_MINOR__ and __GNUG_PATCHLEVEL__ too?
Interestingly, there is a __VERSION__ macro ("which describes the version 
of the compiler in use").  There is some discussion in this thread on whether  
these macros are defined in the preprocessor or the compiler proper.  If 
these macros are processed by the preprocessor, and the C, C++, Fortran,
etc compilers all share CPP, then how would the preprocessor report the
correct version of the compiler in use?  It somehow checks with the
compiler to see whether it is C or Fortran, and then report the appropriate
version of the compiler?  

_
It’s a talkathon – but it’s not just talk.
http://www.imtalkathon.com/?source=EML_WLH_Talkathon_JustTalk

RE: Feature request - a macro defined for GCC

[x z]

> If we want to fix this, gcc must change. And this may
> also require GNU libc changes and linux kernel changes, etc.
Maybe you can enlighten us a bit on why GNU libc and linux kernel need 
changes so that we can realize better how complicated the issue is.

> The talk about whether __GNUC__ is defined by the preprocessor or the
> compiler proper is irrelevant. Either way, it is still ambiguous.
IMHO, it is irrelevant as far as whether __GNUC__ is ambiguous.  However,
I think it is relevant as far as how it can be fixed, if at all.  So, if you
have some insight as to whether __GNUC__ is defined by the preprocessor 
or the compiler proper, please let us know.  It does not hurt anyway.

> You are right that we may also have trouble with other related macros.
> I am not sure if there is a GNU Fortran language, if there is, then we
> may have the same problem with __GFORTRAN__.
There is a GNU Fortran compiler for sure.  So, just as people consider
the syntax and semantics of a language accepted by the GNU C compiler
as sort of a C language specification (i.e. whatever accepted by GNU C
compiler 4.3.1 becomes GNU C Standard 4.3.1), there is a GNU Fortran
language.  Whatever accepted by the GNU Fortran compiler becomes
the GNU Fortran language spec. 

> We don't need things like __GNUG_MINOR__ as G++ is always distributed in
> lock step with the C compiler, so we only need one set of macros for gcc
> version numbers.
Then maybe __GNUFORTRAN_MINOR__ .

Anyway, assumed GNU Fortran and GNU C are not distributed in lock step, then
the __VERSION__ macro should be clarified as to whether it refers to the
C or Fortran version (or the version of CPP itself - well, I guess CPP is also
distributed with C in lock step so they share the same version).
_
Need to know now? Get instant answers with Windows Live Messenger.
http://www.windowslive.com/messenger/connect_your_way.html?ocid=TXT_TAGLM_WL_messenger_072008