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:
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
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 - De
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
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 PRODUCT
>
> 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):
>
>
* 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
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' ==
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
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 require
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 i
> 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!=
> 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 su
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
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 Netherland
>
> 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
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 ?
>
> 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
> a
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 menti
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 mi
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 --
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
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 t
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
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 h
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 a
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
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-g
28 matches
Mail list logo
