Re: backslash whitespace newline
For what it's worth, my opinion: A program whose semantics depends on invisible end-of-line whitespace is erroneous and a disaster waiting to happen. The portability argument wrt other compilers is all very well, but the code fails to be portable in so many other ways, as people have mentioned: cut-and-paste; web archives; reading printed-out code; not to mention virtual 80-column punch cards on VM/CMS ... I'd like to keep the current behavior, but add a warning, which should default to on. I'll go along with a compromise: change the behavior to match the "other compilers", as along as a warning is emitted. The warning can be turned off with our generic turn-off-specific-warnings framework (I'm so out of gcc development I'm not sure we have one - but I vaguely remember reading about it). However, the warning should be on by default. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: resolving backslash newline whisky tango foxtrot: a proposal
Rather than adding new flags, I'd think I'd prefer: 1. Change the behavior (back) so only '\\$', not '\\ *$', causes a line to be continued. 2. Make -Wcomment more useful to it only warns when it might matter: The following line contains non-comment whitespace. 3. Make -Wcomment the default - not just for -Wall, but always. It can be turned off with -Wno-comment -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Post-Mont-Tremblant mailing
The Post-Mont-Tremblant WG14 mailing is now available from the WG14 website. Particular points of note: * The current decimal FP draft is now N1150 (no longer N1107 which is the version mentioned in svn.html); I don't what what's changed since N1107. * The draft minutes say: TR 24732 - Decimal Floating Point. The committee revising IEEE 754R has run into a significant issue in the revision. TR 24732 depends on that document. There is nothing we can do to proceed with that TR until the key issues are resolved. We need to tell SC22 what our plans are for proceeding. Fred volunteered to work with Edison to develop a rationale. I don't know what the issue with 754R is and how it affects dfp-branch, but I presume the DFP developers are following 754R development and know about and understand the issue and its impact. * DRs 315 (bit-field types) and 314 (cross-translation-unit tagged type compatibility are moving backwards and are less resolved than they were before, with a WG14 paper to be written on 314. * Something might happen on DR 323 (N1138) (Annex G now conflicts with normative standard) and DR 324 (N1123) (partial preprocessing tokens), but what is unclear. -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ [EMAIL PROTECTED] (personal mail) [EMAIL PROTECTED] (CodeSourcery mail) [EMAIL PROTECTED] (Bugzilla assignments and CCs)
Re: resolving backslash newline whisky tango foxtrot: a proposal
Per Bothner <[EMAIL PROTECTED]> writes: | Rather than adding new flags, I'd think I'd prefer: | | 1. Change the behavior (back) so only '\\$', not '\\ *$', causes a | line to be continued. | 2. Make -Wcomment more useful to it only warns when it might matter: | The following line contains non-comment whitespace. Not just contains a non-comment, but is a non-comment line modulo leading whitespaces. -- Gaby
Revisiting generalized lvalues
I don't know if it's too late, but there is yet another reason for the use of generalized lvalues besides just ignorance: using them in macros that verify pointer and struct usage in a large framework. A comma expression makes it very convenient, for example (just a general idea): #ifdef PRODUCTION #define X_ABC(x) ( check( x ), x->abc ) #else #define X_ABC(x)x->abc #endif which expands X_ABC(x) = y; to: ( check( x ), x->abc ) = y; It is something that is used during development only and is switched off for the production builds. C++ compatibility is not an issue either. Eliminating this construct makes macros much less flexible and requires much more work for creating self-verifying frameworks, which is a big issue for small companies with large codebase. I understand that supporting generalized lvalues for all possible usage cases (C++, etc.) creates problems, but why not allowing them for such limited cases via an obscure special option? GCC always provided more options that other compilers, it would be sad to see it changing... /mike
Re: Revisiting generalized lvalues
>
> I don't know if it's too late, but there is yet another reason
> for the use of generalized lvalues besides just ignorance:
> using them in macros that verify pointer and struct usage
> in a large framework. A comma expression makes it very
> convenient, for example (just a general idea):
>
> #ifdef PRODUCTION
> #define X_ABC(x) ( check( x ), x->abc )
> #else
> #define X_ABC(x)x->abc
> #endif
>
> which expands
>
> X_ABC(x) = y;
>
> to:
>
> ( check( x ), x->abc ) = y;
>
> It is something that is used during development only and
> is switched off for the production builds. C++ compatibility
> is not an issue either.
GCC does this through another extension, like:
#ifdef CHECKING
#define CHECK_X(x) ({const tree __t = x; check(__t); __t; })
#else
#define CHECK_X(x) x
#endif
#define X_ABC(x)CHECK_X(x)->abc
-- Pinski
Re: Revisiting generalized lvalues
* Michael Krasnik: > #ifdef PRODUCTION > #define X_ABC(x) ( check( x ), x->abc ) > #else > #define X_ABC(x)x->abc > #endif > > which expands > > X_ABC(x) = y; > > to: > > ( check( x ), x->abc ) = y; > Eliminating this construct makes macros much less flexible > and requires much more work for creating self-verifying > frameworks, which is a big issue for small companies with > large codebase. There seems to be a trivial fix: modifiy the check function to return its argument.
GCC 4.0.2 Canadian Cross Compile
Hi,
I have been having problems building GCC 4.0.2 using a GCC 4.0.2 cross
compiler.
The issue appears to be that the 'is_cross_compiler' macro in the
configure scripts does not check to see if 'build' = 'host'. It only
check to see if 'target' = 'host'.
In a Canadian Cross Compile, 'target' == 'host' != 'build' and the
compiler that is created may not run on the computer building the
compiler.
If I use 'configure --host=sparc-linux --target=sparc-linux
--build=i686-pc-linux-gnu ...' then the compiler/tools and additional
libraries need to be built using a previously made sparc-linux cross
compiler. The existing libraries used by the sparc-linux cross compiler do
not actually need to be re-built if the sparc-linux cross compiler was
compiled from the same source.
The procedure I end up with is:
---
# Set up paths etc for the build
# header files/libraries are in ${CROSS_DIR}/sparc-linux/sys-root/...
PATH=${BUILD_TMP_DIR}/bin:${CROSS_DIR}/bin:${PATH}
LD_LIBRARY_PATH=${BUILD_TMP_DIR}/lib:${CROSS_DIR}/lib:${LD_LIBRARY_PATH}
export PATH LD_LIBRARY_PATH
# Create Build compiler (required as ADA Cross Compile fails
#if made with gcc-3.4.2)
# Code runs on and compiles for (i686-pc-linux-gnu)
cd gcc-local
../gcc-4.0.2/configure --prefix=${BUILD_TMP_DIR} \
--enable-languages='c,ada' ...
make bootstrap
make install
cd ..
# Generate Cross Binary Utilities
# Code runs on and creates binaries for (sparc-linux)
cd binutils-cross
../binutils-2.16.1/configure --target=sparc-linux --prefix=${CROSS_DIR} \
...
make all
make install
cd ..
{additional steps to build C library}
# Generate Cross Compiler
# Code runs on and compiles for (sparc-linux)
cd gcc-cross
../gcc-4.0.2/configure --target=sparc-linux --prefix=${CROSS_DIR} \
--enable-languages='c,c++,ada' ...
make all
make install
cd ..
# Generate Canadian Cross Binary Utilities
# Code runs on and creates binaries for (sparc-linux)
cd can-binutils-cross
../binutils-2.16.1/configure --host=sparc-linux --target=sparc-linux \
--prefix=${CAN_CROSS_DIR} ...
make all
make install
cd ..
# Generate Canadian Cross Compiler
# Code runs on and compiles for (sparc-linux)
cd can-cross-gcc
configure --host=sparc-linux --target=sparc-linux --prefix=${CROSS_DIR} \
--enable-languages='c,c++,ada' ...
make all
{ Curently fails here as it has set the LD_LIBRARY_PATH incorrectly for
generating code to run on to create the documentation }
make install
cd ..
-
Fixing the 'is_cross_compiler' macro to check 'host' != 'build' fixes
things untill the compiler attempts to build ADA library. At this point it
fails again as the ADA library make system tries to use xgcc. If it is a
canadian cross compile, it needs to use the cross compiler, not the
canadian cross compiler.
I will submit a patch if I get the canadian cross compile to work
properly. I have not achived this since gcc-2.8.1/gnat-3.14p.
I hope this is of use for future revisions of the compiler/configure
scripts.
Regards
Mark Fortescue.
Re: Copies of the GCC repository
Daniel Berlin wrote: > On Fri, 2005-10-28 at 22:40 +0100, Paul Brook wrote: >> > I am still working on tarballs of a .svk/local dir for people. >> >> Any reason you're doing a tarball instead of a bootstrap dump? >> http://svk.elixus.org/?SVKBootStrap > > > Same thing, more or less :) Yes and no - the problem with using a tarball is getting the UUID changed. And this is *important*, at least for anyone who wants to use svk to maintain local branches, rather than just to avoid a text-base in the checkout. I'm not actually sure what the 'right' approach to changing the uuid in a repository tarball is, though uuidgen > $repo/db/uuid before using it is *probably* ok.
Re: Revisiting generalized lvalues
Florian Weimer wrote: * Michael Krasnik: #ifdef PRODUCTION #define X_ABC(x) ( check( x ), x->abc ) #else #define X_ABC(x)x->abc #endif which expands X_ABC(x) = y; to: ( check( x ), x->abc ) = y; Eliminating this construct makes macros much less flexible and requires much more work for creating self-verifying frameworks, which is a big issue for small companies with large codebase. There seems to be a trivial fix: modifiy the check function to return its argument. The check( x ) is not a function but another set of macros. Functions are too strongly typed and cause too much code replication, while we use it generically... Thanks anyway, /mike
Re: Revisiting generalized lvalues
Andrew Pinski wrote:
I don't know if it's too late, but there is yet another reason
for the use of generalized lvalues besides just ignorance:
using them in macros that verify pointer and struct usage
in a large framework. A comma expression makes it very
convenient, for example (just a general idea):
#ifdef PRODUCTION
#define X_ABC(x) ( check( x ), x->abc )
#else
#define X_ABC(x)x->abc
#endif
which expands
X_ABC(x) = y;
to:
( check( x ), x->abc ) = y;
It is something that is used during development only and
is switched off for the production builds. C++ compatibility
is not an issue either.
GCC does this through another extension, like:
#ifdef CHECKING
#define CHECK_X(x) ({const tree __t = x; check(__t); __t; })
#else
#define CHECK_X(x) x
#endif
#define X_ABC(x)CHECK_X(x)->abc
-- Pinski
Your example is a fancier way of rewriting our macros as:
#ifdef PRODUCTION
#define X_ABC(x) ( check( x ), &x )->abc
#else
#define X_ABC(x)x->abc
#endif
to get around the "invalid lvalue" error. It's fine for a
distilled simple example, but quickly becomes ugly for
real multi-level nested macros. Well, I guess we have to
forget about elegance and use the same tricks we do for
other compilers...
Thanks,
/m
Re: GCC 4.0.2 Canadian Cross Compile
> In a Canadian Cross Compile, 'target' == 'host' != 'build' and the > compiler that is created may not run on the computer building the > compiler. You're describing a cross-built native, not a canadian. http://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html Whenever --target=foo and build!=host, you need to have a pre-built foo-gcc that runs on $build. One obvious bug I see in your scripts is that you are specifying --host without also specifying --build. The documentation explicitly tells you to never do that. Your last step is attempting to build a NATIVE compiler, assuming that the machine it's running on is sparc-linux.
Re: Exception propagation problem on IA-64/Linux
> We could uniquify exception names in Ada, since they have only a static > nesting identify, not a dynamic one (e.g. the exception XYZ declared > within a recursive procedure is the same at all levels of recursion). > > That would be an easy change if it would help ... Yes, but only in Ada. I suspect it's not so easy in C++. Anyway the generic fix turns out to be straightforward so I think we should take that path. -- Eric Botcazou
gcc-4.1-20051029 is now available
Snapshot gcc-4.1-20051029 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20051029/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 CVS branch with the following options: -D2005-10-29 17:43 UTC You'll find: gcc-4.1-20051029.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20051029.tar.bz2 C front end and core compiler gcc-ada-4.1-20051029.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20051029.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20051029.tar.bz2 C++ front end and runtime gcc-java-4.1-20051029.tar.bz2 Java front end and runtime gcc-objc-4.1-20051029.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20051029.tar.bz2The GCC testsuite Diffs from 4.1-20051022 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.
How do we retrieve wwwdocs from SVN ?
I might have missed something, but I can't find how to retrieve the - updateable - sources for wwwdocs. Please point me to the (in hindsight obvious) documentation ... Thanks, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
Re: How do we retrieve wwwdocs from SVN ?
> > I might have missed something, > but I can't find how to retrieve the > - updateable - sources for wwwdocs. > > Please point me to the (in hindsight obvious) > documentation ... wwwdocs is still in cvs (I have not looked into the docs to see if that is mentioned at all). -- Pinski
Broken versions
Hi I detected build issues with 2 of the versions that I tried to build, one the latest version from CVS, the other- the improved alias branch. Both give me the following error. Would anyone else have faced it and found a fix or is it that these releases are not supposed to be used at this time ? libiberty/regex.c:4221: internal compiler error: in extract_insn, at recog.c:2084 thanks Shrey
Re: Broken versions
> > Hi > I detected build issues with 2 of the versions that I tried to build, > one the latest version from CVS, the other- the improved alias branch. > Both give me the following error. Would anyone else have faced it and > found a fix or is it that these releases are not supposed to be used > at this time ? This is not enough information to figure out what is going on. First what target is this (for an example i686-pc-linux-gnu)? Second how did you configure/build gcc? -- Pinski
Re: How do we retrieve wwwdocs from SVN ?
On Sat, 29 Oct 2005, Andrew Pinski wrote: I might have missed something, but I can't find how to retrieve the - updateable - sources for wwwdocs. Please point me to the (in hindsight obvious) documentation ... wwwdocs is still in cvs (I have not looked into the docs to see if that is mentioned at all). It is.
Re: gcc-4.1-20051029 is now available
Errr. This is really a snapshot from CVS, since i haven't committed the svn version of gcc-release yet. Sorry about that. On Sat, 29 Oct 2005, [EMAIL PROTECTED] wrote: Snapshot gcc-4.1-20051029 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20051029/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 CVS branch with the following options: -D2005-10-29 17:43 UTC You'll find: gcc-4.1-20051029.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20051029.tar.bz2 C front end and core compiler gcc-ada-4.1-20051029.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20051029.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20051029.tar.bz2 C++ front end and runtime gcc-java-4.1-20051029.tar.bz2 Java front end and runtime gcc-objc-4.1-20051029.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20051029.tar.bz2The GCC testsuite Diffs from 4.1-20051022 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.
Re: Broken versions
Sorry abt that, my source is mcore-elf and these are the options I use to configure, followed by gmake and gmake install. ./im-alias-source/configure --srcdir=../im-alias-source/ --target=mcore-elf --with-newlib --disable-threads --disable-multilib --disable-nls --prefix=/usr/local/gcc4-mcore --enable-languages=c thanks Shrey On 10/29/05, Andrew Pinski <[EMAIL PROTECTED]> wrote: > > > > Hi > > I detected build issues with 2 of the versions that I tried to build, > > one the latest version from CVS, the other- the improved alias branch. > > Both give me the following error. Would anyone else have faced it and > > found a fix or is it that these releases are not supposed to be used > > at this time ? > > This is not enough information to figure out what is going on. > First what target is this (for an example i686-pc-linux-gnu)? > Second how did you configure/build gcc? > > > -- Pinski > >
Tag reorg
Now that we have a repo set up, i suggest we reorg the tags into some sort of sane structure so that there aren't 900 of them in the same dir :). I'm pretty sure we can't get consensus on where to put *all* the tags, but I'm also pretty sure we can agree to the following: 1. Apple tags should go in a subdirectory named "apple". (Whether you guys want to further subdivide your taggings, is your business) Not to single apple out, i imagine anyone who wants to do daily or significant amounts of tagging should have their own subdir. 2. All the old old-gcc tags should go in a subdirectory named "old-gcc". Whether we want to further subdivide them, no idea (IE there's a bunch of libc tags, etc). 3. Snapshot tags should go into a subdirectory named "snapshots" Again, we could subdivide them further by release. I've avoided the question of what to do with old branchpoints and branch merge tags for now. I figure we should start somewhere, instead of having an all encompassing mega-plan. --Dan
Re: svn troubles
On Fri, 2005-10-28 at 08:49 +0200, Andreas Jaeger wrote: > Ralf Corsepius <[EMAIL PROTECTED]> writes: > > > Hi, > > > > I don't seem to be able to access svn: > > > > # svn ls svn://gcc.gnu.org/svn/gcc > > [several (2-3) minutes pass, during which svn is non-interruptable] > > svn: Can't connect to host 'gcc.gnu.org': Connection timed out > > I didn't read that it's up again after the switch from CVS to SVN - I > suggest to wait until Danny sends the announcement, For the record: This wasn't the only cause. My firewall/router blocked the svn-port (port 3690/tcp) ;) Ralf
svn: Is it there yet?
Daniel, I have been trying, unsuccessfully, to discern from the list if mainline/head/gcc-4_1-branch is available from the svn repository. Is it available and what will it be called, please? Cheers Paul T
Re: Tag reorg
Daniel Berlin <[EMAIL PROTECTED]> writes: > 1. Apple tags should go in a subdirectory named "apple". > > (Whether you guys want to further subdivide your taggings, is your > business) > > Not to single apple out, i imagine anyone who wants to do daily or > significant amounts of tagging should have their own subdir. And, not to omit the obvious, Apple should reconsider whether they need to do a daily tag at all. The daily tag was clearly useful for CVS. For SVN it should suffice to write down a single revision number. Is there any reason to continue the daily tag? > 2. All the old old-gcc tags should go in a subdirectory named "old-gcc". > > Whether we want to further subdivide them, no idea (IE there's a bunch > of libc tags, etc). I would vote for simply ditching the old-gcc libc, gcc-2_8_1, make, gnumach, and hurd tags. If I had thought about it, I would have had the gccmerge process discard them. Ian
Re: svn: Is it there yet?
Paul Thomas <[EMAIL PROTECTED]> writes: > I have been trying, unsuccessfully, to discern from the list if > mainline/head/gcc-4_1-branch is available from the svn repository. > > Is it available and what will it be called, please? It is available. It is simply called 'trunk'. There is no actual 4.1 branch yet. See http://gcc.gnu.org/svn.html http://gcc.gnu.org/ml/gcc/2005-10/msg01083.html Ian
Re: svn: Is it there yet?
Ian, It is available. It is simply called 'trunk'. There is no actual 4.1 branch yet. See http://gcc.gnu.org/svn.html http://gcc.gnu.org/ml/gcc/2005-10/msg01083.html Ah! I thought that this was the sandpit branch. Thanks Paul
[gomp] libgomp/fortran.c:37: warning: implicit declaration of function 'malloc'
Currently, in the gomp branch, I get this: if /bin/sh ./libtool --mode=compile /usr/local/src/branch/objdir.gomp/./gcc/xgcc -B/usr/local/src/branch/objdir.gomp/./gcc/ -B/usr/local/sparc64-unknown-linux-gnu/bin/ -B/usr/local/sparc64-unknown-linux-gnu/lib/ -isystem /usr/local/sparc64-unknown-linux-gnu/include -isystem /usr/local/sparc64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc.gomp/libgomp -I. -I../../../gcc.gomp/libgomp/config/posix -I../../../gcc.gomp/libgomp -Wall -Werror -Wc,-pthread -ftls-model=initial-exec -O2 -g -O2 -MT fortran.lo -MD -MP -MF ".deps/fortran.Tpo" -c -o fortran.lo ../../../gcc.gomp/libgomp/fortran.c; \ then mv -f ".deps/fortran.Tpo" ".deps/fortran.Plo"; else rm -f ".deps/fortran.Tpo"; exit 1; fi /usr/local/src/branch/objdir.gomp/./gcc/xgcc -B/usr/local/src/branch/objdir.gomp/./gcc/ -B/usr/local/sparc64-unknown-linux-gnu/bin/ -B/usr/local/sparc64-unknown-linux-gnu/lib/ -isystem /usr/local/sparc64-unknown-linux-gnu/include -isystem /usr/local/sparc64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc.gomp/libgomp -I. -I../../../gcc.gomp/libgomp/config/posix -I../../../gcc.gomp/libgomp -Wall -pthread -Werror -ftls-model=initial-exec -O2 -g -O2 -MT fortran.lo -MD -MP -MF .deps/fortran.Tpo -c ../../../gcc.gomp/libgomp/fortran.c -fPIC -DPIC -o .libs/fortran.o cc1: warnings being treated as errors ../../../gcc.gomp/libgomp/fortran.c: In function 'omp_init_lock_': ../../../gcc.gomp/libgomp/fortran.c:37: warning: implicit declaration of function 'malloc' ../../../gcc.gomp/libgomp/fortran.c:37: warning: incompatible implicit declaration of built-in function 'malloc' ../../../gcc.gomp/libgomp/fortran.c: In function 'omp_init_nest_lock_': ../../../gcc.gomp/libgomp/fortran.c:46: warning: incompatible implicit declaration of built-in function 'malloc' ../../../gcc.gomp/libgomp/fortran.c: In function 'omp_destroy_lock_': ../../../gcc.gomp/libgomp/fortran.c:56: warning: implicit declaration of function 'free' Also, could I ask for someone to consider merging with mainline again, or at leaqst the gcc_updated get merged in (with appropriate changes for the gomp branch...) -- Cheers, /ChJ
