Re: GCC 4.3.3 Released
Dennis Clarke: [ Charset ISO-8859-1 converted... ] > > >> > I'll try sparc64, powerpc64 and ia64 when the machines are available. > >> > >> I can probably help you with the Sparc64 requirement. To be precise, do > >> you need Sun UltraSparc or are you looking for the multicore SPARC64 > >> processor which is a ( slightly ) different beast? > > > > Thanks for your offer. > > > > I do have access to a sparc64, in fact it's the same machine that I used > > for the sparc (32 bits) report in the farm, but it is down since since > > morning and will probably be up again in the next few days. > > I am always a very careful with the 32-bit Sparc build because I often end > up with a 32-bit gcc but the ABI says SPARC V8PLUS or some such. > > Thus I use a genuine old old Sparc to build GCC with. A 64-bit build would require a cross compilation, or perhaps I missed something? I need to tell gmp's ./configure that --build=sparc first, due to the old old 32-bit bundled compiler, and also --disable-multilib to build GCC. On an (possibly) off-topic note, it seems that gmp requires GNU ld, but GCC needs the native ld. I haven't ben able to pin down where in the build process that the libs and the compiler suddenly require the 32-bitness. This on a sparc64 with a new install of Solaris10 (seems yet to require /usr/bin/ksh as the login shell and the addition of GNU sed). -- Ctalk Home Page: http://www.ctalklang.org
Re: GCC 4.3.3 Released
> > On an (possibly) off-topic note, it seems that gmp requires GNU ld, but GCC > > needs the native ld. > > Neither is supposed to be true (and I've built GMP with Sun ld and GCC with > GNU ld many times). I didn't take notes, and you wouldn't find my configuration very useful (much symlinking to the bundled GNU utilities) so I won't add anything to the information about the two disparate build chains -- Ctalk Home Page: http://www.ctalklang.org
Warnings while building gcc-4.3-20080605 on Solaris2.10
The build of gcc-4.3-20080605 snapshot on holly with Solaris2.10 generated the following warnings. ../../gcc-4.3-20080605/gcc/expr.c: In function 'expand_expr_real_1': ../../gcc-4.3-20080605/gcc/expr.c:8024: warning: unknown conversion type character 'K' in format ../../gcc-4.3-20080605/gcc/expr.c:8024: warning: too many arguments for format ../../gcc-4.3-20080605/gcc/expr.c:8033: warning: unknown conversion type character 'K' in format ../../gcc-4.3-20080605/gcc/expr.c:8033: warning: format '%qs' expects type 'char *', but a rgument 2 has type 'tree' ../../gcc-4.3-20080605/gcc/expr.c:8033: warning: too many arguments for format ../../gcc-4.3-20080605/gcc/expr.c:8039: warning: unknown conversion type character 'K' in format ../../gcc-4.3-20080605/gcc/expr.c:8039: warning: format '%qs' expects type 'char *', but a rgument 3 has type 'tree' ../../gcc-4.3-20080605/gcc/expr.c:8039: warning: too many arguments for format The build on holly used the native SunOS build tools, so YMMV. If not a duplication of effort, should I submit a patch to correct these warnings? Robert -- Ctalk Home Page: http://www.ctalklang.org
Re: Warnings while building gcc-4.3-20080605 on Solaris2.10
Andrew Pinski: > On Sat, Jun 7, 2008 at 2:43 AM, rkiesling <[EMAIL PROTECTED]> wrote: > > The build on holly used the native SunOS build tools, so YMMV. If not > > a duplication of effort, should I submit a patch to correct these > > warnings? > > Are these warnings during building stage1? If so ignore them. The > different version of GCC don't understand the format warnings for the > GCC internals error/warning functions which change between releases. > > Thanks, > Andrew Pinski Okay, thank you. -- Ctalk Home Page: http://www.ctalklang.org
Re: Feature request - a macro defined for GCC
Robert Dewar: [ Charset ISO-8859-1 converted... ] > Andrew Haley wrote: > > x z wrote: > > > >> 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. > > > > They don't use GNU CPP. > > > >> Therefore, the fact that __GNUC__ is defined does not necessarily > >> mean the GCC compiler proper is being used. > > > > I don't think you've thought about this thoroughly. > > > > Any compiler that is not GNU C but defines __GNUC__ is lying to its > > users. If we define __REAL_GNUC__ they'll just define that as well. I guess the last reply didn't make it to the list. The include files need __GNUC__ and other builtin macros to include type definitions. The builtin macros aren't needed by the compiler proper, and adding another builtin wouldn't help in special cases. For example, the GNU configurations occationionally need to use -DWITH_GCC or something similar. I didn't know that anyone had a special claim to GNU and/or GCC. I thought the trademark thing was tried, but, with all of the instances of GCC already on bookshelves, for example, it didn't seem very successful. But, IANTL, of course. -- Add this signature to your message and contribute to world nomidation.
Re: Feature request - a macro defined for GCC
Vincent Lefevre: [ Charset ISO-8859-1 converted... ] > On 2008-07-01 11:11:42 -0700, Ian Lance Taylor wrote: > > __GNUC__ is indeed defined by the compiler proper, not by the > > preprocessor. > > What do you mean here? > > Even when calling the preprocessor directly, __GNUC__ is defined: > > vin% gcc -dM -E -xc /dev/null | grep __GNUC__ > #define __GNUC__ 4 > vin% cpp -dM /dev/null | grep __GNUC__ > #define __GNUC__ 4 > > > 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. > > But in any case, there's a separate preprocessor: cpp. And perhaps cpp > shouldn't define __GNUC__. > > (BTW, this isn't a compiler, but xrdb uses cpp by default.) Try: $ echo ' ' | cpp -undef -dM - and determine if there's any output (varies by platform). The ctpp preprocessor undefines all builtins when -undef is present. See the URL below (plug, I know). -- Ctalk Home Page: http://www.ctalklang.org
Re: Feature request - a macro defined for GCC
Paul Koning: > > "Ralf" == Ralf Wildenhues <[EMAIL PROTECTED]> writes: > > Ralf> I feel like I'm stating the obvious, but maybe you're just > Ralf> trying to rediscover feature-based tests: do a test compile > Ralf> that exposes the compiler bug or feature you're looking for. > > Ralf> Autoconf provides a framework that supports this kind of > Ralf> testing, among others. > > Autoconf is a massively cryptic and complicated way to make up for the > lack of "I have feature X" CPP flags in the compiler. > > Chris is right, that's the correct way to do things. > > paul Cpp does not, however, define macros based on command line options, for example __C99_STD_CMD_LINE_OPTION__. You could do the same thing yourself with a -D__MY_C99_STUFF__, for example, on the command line. I also feel like I keep stating the obvious, but there are a lot of GNU C platforms that don't use glibc and wouldn't have any need for such feature-based macros, (or they would need their own unique features) but they still comply with standard C. -- Ctalk Home Page: http://www.ctalklang.org
