On Tue, 10 Jun 2008, James Brown wrote:
> The link the the GCC 4.3 release notes to the TR1 implementation
> status page is dead.
No more, fixed with the patch below.
(This was one of the side effects of a documentation rewrite on the
libstdc++ side.)
> Also, the parallel mode page is somewhat u
Hi Alex,
On Tue, 10 Jun 2008, Alex Korolev wrote:
> I noticed I miss few important things in the first email regarding
> mirror.
>
> Mirror name: gcc.releasenotes.org
> Mirror url: http://gcc.releasenotes.org
> Location: USA, TX
> Supporter: [EMAIL PROTECTED]
I looked into this, and
I realized that our full FTP tree at ftp://gcc.gnu.org/pub/gcc/
consumes 27GB overall.
There is ample diskspace on gcc.gnu.org itself, but for (new) mirrors
this is quite a bit, for example, so I went ahead and reduced this to
18G by removing some older snapshots (from 2007 and RCs for previous
re
Hi, Ian!
On Tue, Jun 10, 2008 at 12:05:20PM -0700, Ian Lance Taylor wrote:
> Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> > Alan Mackenzie <[EMAIL PROTECTED]> writes:
> >> I'm thinking of things like
> >> foo (a < b, c > d);
[ ]
> Oh, wait, I forgot about constructors. This is val
I am crossing from i686-cygwin to sparc-solaris (my Sun cc won't compile gcc
due to macros with empty parameters like in c-common.c):
/src/gcc-4.3.1/gcc/config/sparc/gmon-sol2.c: In function '_mcleanup':
/src/gcc-4.3.1/gcc/config/sparc/gmon-sol2.c:182: error: 'PATH_MAX' undeclared
(first use in
When gcc configures the in-tree gmp/mpfr, why
does it use --host=none-${host_vendor}-${host_os}
--target=none-${host_vendor}-${host_os}
instead of --host=${host_alias} --target=${target_alias}
This "breaks" config.cache if used across directories, because the platforms
change.
I'm trying li
> I am crossing from i686-cygwin to sparc-solaris (my Sun cc won't compile
> gcc due to macros with empty parameters like in c-common.c):
>
> /src/gcc-4.3.1/gcc/config/sparc/gmon-sol2.c: In function '_mcleanup':
> /src/gcc-4.3.1/gcc/config/sparc/gmon-sol2.c:182: error: 'PATH_MAX'
> undeclared (firs
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
> i[34567]86-*-coff*
DJGPP is ix86-coff - how would this deprecation affect djgpp?
On Sun, 15 Jun 2008, DJ Delorie wrote:
> "Joseph S. Myers" <[EMAIL PROTECTED]> writes:
> > i[34567]86-*-coff*
>
> DJGPP is ix86-coff - how would this deprecation affect djgpp?
I thought DJGPP was i[34567]86-pc-msdosdjgpp*. I do not think having
generic CPU-*-OBJFMT triplets that really refer t
> "Le-Chun" == Le-Chun Wu <[EMAIL PROTECTED]> writes:
Le-Chun> Here is the design doc for the proposed annotations:
Le-Chun> http://docs.google.com/Doc?id=ddqtfwhb_0c49t6zgr
I am curious to know how this compares to the kind of lock checking
implemented in sparse, and in particular whether sp
> I thought DJGPP was i[34567]86-pc-msdosdjgpp*. I do not think
> having generic CPU-*-OBJFMT triplets that really refer to a
> particular OS is a good idea. It's only certain generic triplets
> I'm proposing to deprecate.
DJGPP is ix86-pc-msdosdjgpp, yes. However, it's based on the
ix86-coff
DJ Delorie <[EMAIL PROTECTED]> writes:
>> I thought DJGPP was i[34567]86-pc-msdosdjgpp*. I do not think
>> having generic CPU-*-OBJFMT triplets that really refer to a
>> particular OS is a good idea. It's only certain generic triplets
>> I'm proposing to deprecate.
>
> DJGPP is ix86-pc-msdosdjgp
On Sun, 15 Jun 2008, Ian Lance Taylor wrote:
> My understanding is that Joseph is just talking about removing the
> entries in config.gcc. He is not talking about removing the support
> in the code, except perhaps for cases where there is no longer any
> entry in config.gcc which requires that su
Dear all,
Just wanted to mention that we released the new version
of GCC ICI and GCC ICI Plugins that are used in the MILEPOST GCC
(machine learning based research compiler).
I will be at the GCC Summit next week presenting this work
and will be happy to discuss our current and future research &
On Wed, Jun 11, 2008 at 07:49:12AM -0700, H.J. Lu wrote:
> > I guess we all agree on passing variadic arguments on stack (that is
> > only those belonging on ...) and rest in registers. It seems easiest in
> > regard to future register set extensions too. Only negative thing is
> > that calls to
2008/6/13 Mark Mitchell:
> Jonathan Wakely wrote:
>>
>> Hi Volker, thanks for picking these issues up. I told Manuel I'd
>> review the rest of the remaining pedwarns, but haven't had time to do
>> it either.
>
> Just to chime in here: Volker, I agree with your comments.
I think we all do :-)
> Jo
On Sat, 2008-06-14 at 18:53 +, Joseph S. Myers wrote:
> m68k-*-aout*
> m68k-*-coff*
These would be fine with me; there has been no interest in these targets
in binutils-land for some time.
Ben
> On Wed, Jun 11, 2008 at 07:49:12AM -0700, H.J. Lu wrote:
> > > I guess we all agree on passing variadic arguments on stack (that is
> > > only those belonging on ...) and rest in registers. It seems easiest in
> > > regard to future register set extensions too. Only negative thing is
> > > that
> Hello,
> In our GCC porting, we use newlib instead of libc. Today I tried to use
> profiling feedback based optimization with option -fprofile-arcs. But
> the executable doesn't produce .gcda file. I examined the disassembled
> binary file and found the following functions are basically just d
Jonathan --
Thanks for pushing this forward!
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
On Jun 15, 2008, at 7:06 PM, "Jonathan Wakely" <[EMAIL PROTECTED]>
wrote:
2008/6/13 Mark Mitchell:
Jonathan Wakely wrote:
Hi Volker, thanks for picking these issues up. I tol
20 matches
Mail list logo
