This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: ANSI compliance bug in Apple C compiler on OS X
- To: Michael Hopkins <mhopkins at netmatters dot co dot uk>
- Subject: Re: ANSI compliance bug in Apple C compiler on OS X
- From: Eric Peyton <epeyton at epicware dot com>
- Date: Mon, 29 Jan 2001 19:09:39 -0600 (CST)
- cc: macosx-dev at omnigroup dot com, R Clint Whaley <rwhaley at cs dot utk dot edu>, gcc-bugs at gcc dot gnu dot org
Have you read Stan Sheb's state of the union on the Apple compilers and
related tools on the archives of the darwin developement mailling
pages? I think that information will answer the questions you pose
below.
Eric
On Mon, 29 Jan 2001, Michael Hopkins wrote:
>
> Hi
>
> I am trying to find the right place to ask the following questions, get
> an authoritative answer and then try to get something done about it.
> These groups seems like they must be pretty close to the heart of OS X
> development. Any advice or suggestions of who to contact will be
> greatly appreciated. Is it worth sending a bug report to Apple & if so
> where to? I can't find it.. I've sent one to the Darwin page.
>
> In brief, the pre-processor in the Apple OS X cc compiler that I have
> for OS X (from the ADC site) appears not to be ANSI compliant and
> obviously should be, for it to be of much use to the people who want to
> port substantial projects from UNIX & Linux (or elsewhere). Please
> see the email copied below for some detail.
>
> Many have suggested using '-traditional-cpp' flags and they solve some
> of the problems below, but introduce others - probably because they also
> break ANSI compliance.
>
> What have Apple done to GNU cc? This behaviour is not present on any
> other UNIX/Linux platform as far as I can establish.
>
> As I say above (& below) - this will affect all of us who want to take
> advantage of our new 'industrial strength' OS...
>
> Michael
>
> P.S. Apologies if some of you have seen this part before...
>
>
> _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
>
> I am trying to compile a set of libraries that will be important for
> anyone doing serious mathematical or scientific work on Mac OS X. They
> are from the ATLAS project, and automatically produce a set of
> highly-optimised linear algebra routines that are customised to an
> individual architecture. I want to produce a set for the dual G4
> machines to leverage the maximum amount of processing power & try to
> narrow the gap between what is available for us Mac math/science
> programmers and the rest of the world.
>
> ATLAS compiles happily on all major UNIX’s (including BSD) & will have a
> substantial impact on the ability of Mac OS X programmers to easily
> manipulate large linear systems. Unfortunately, I have discovered what
> I believe are some bugs in the implementation of cc that is available
> from the ADC site in the Development Tools TAR files. Both myself &
> Clint Whaley (who runs ATLAS) feel that the C pre-processor is to blame
> as they currently look like macro substitution bugs. What have Apple
> done to GNU cc (or cpp)? Is there a more recent version available
> somewhere that already has this solved?
>
> If you compile the following sample code under the current standard gcc
> compiler or CodeWarrior 6, you will get the correct error that the
> include file could not be found and nothing else.
>
> i.e. line 9: atlas_dNCmm.h: No such file or directory
>
> -----------------------------------------------------------------
> #define TYPE double
> #define SCALAR double
>
> #define Mjoin(pre, nam) my_join(pre, nam)
> #define my_join(pre, nam) pre ## nam
> #define Mstr2(m) # m
> #define Mstr(m) Mstr2(m)
>
> #include Mstr(Mjoin(Mjoin(atlas_,d),NCmm.h))
>
> void Mjoin(Mjoin(Mjoin(NCmm0,NN),0x0x0),_a1_b1)
> (const int M, const int N, const int K, const SCALAR alpha, const
> TYPE *A, const int lda, const TYPE *B, const int ldb, const SCALAR
> beta, TYPE *C, const int ldc);
>
> void Mjoin(Mjoin(Mjoin(NCmm00,Mjoin(0x0x,KB)),NN),0x0x0_aX_bX)
> (const int M, const int N, const int K, const SCALAR alpha, const
> TYPE *A, const int lda, const TYPE *B, const int ldb, const SCALAR
> beta, TYPE *C, const int ldc);
>
> int main()
> {
> return 0;
> }
> -----------------------------------------------------------------
>
> The Apple cc gives you this - note incorrect space before 'h'
> |
> V
> test.c:9: header file 'atlas_dNCmm. h' not found
> test.c:11: warning: numeric constant contains digits beyond the radix
> test.c:16: warning: numeric constant contains digits beyond the radix
> test.c:16: warning: numeric constant contains digits beyond the radix
> test.c:16: illegal external declaration, missing `;' after
> `NCmm000x0xKBNN0x0x0'
> test.c:17: illegal external declaration, missing `;' after `,'
> test.c:17: illegal external declaration, missing `;' after `,'
> test.c:17: illegal external declaration, missing `;' after `,'
> test.c:17: illegal external declaration, missing `;' after `,'
> test.c:18: illegal external declaration, missing `;' after `,'
> test.c:18: illegal external declaration, missing `;' after `,'
> test.c:18: illegal external declaration, missing `;' after `,'
> test.c:18: illegal external declaration, missing `;' after `,'
> test.c:19: illegal external declaration, missing `;' after `,'
> test.c:19: illegal external declaration, missing `;' after `,'
> test.c:19: illegal external declaration, missing `;' after `ldc'
>
>
> Clearly, all members of the OS X development community should be aware
> of this issue but I’m unsure who to go to & where to report it. Does
> anyone please have an idea? Apple? GNU? ‘Some sub-division of Apple
> that directly deals with the port of the GNU tools to OS X’ is my best
> guess, but I haven’t the faintest idea where they would be found.
>
> Any help is appreciated, as solving this will not only produce the
> optimised ATLAS libraries for us all, but remove what appears to be a
> bug introduced into the OS X gcc by Apple - and let's face it, the C
> compiler is essentially the heart of a UNIX system...
>
> _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
>
> _/_/_/ _/_/_/ _/_/_/ ACS Consultancy
> _/ _/ _/ _/ _/
> _/_/_/_/ _/ _/_/_/ Information Sciences for Industry
> _/ _/ _/ _/
> _/ _/ _/_/_/ _/_/_/ Telephone/Fax: 01732~463519 (UK)
>
> _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
>
> `All models are wrong, but some are useful' - George Box
> _______________________________________________
> MacOSX-dev mailing list
> MacOSX-dev@omnigroup.com
> http://www.omnigroup.com/mailman/listinfo/macosx-dev
>
--
Eric Peyton
epeyton@epicware.com
Software and Source for Mac OS X