On Sat, Aug 28, 2010 at 05:56:57PM -0700, Steve Kargl wrote:
> On Sat, Aug 28, 2010 at 05:47:28PM -0700, Steve Kargl wrote:
> > On Sun, Aug 29, 2010 at 01:24:47AM +0200, FX wrote:
> > > Before I submit it officially for review, I want this patch to get some
> > > exposure while I clean up a few re
On Sat, Aug 28, 2010 at 05:47:28PM -0700, Steve Kargl wrote:
> On Sun, Aug 29, 2010 at 01:24:47AM +0200, FX wrote:
> > Before I submit it officially for review, I want this patch to get some
> > exposure while I clean up a few remaining dusty corners. To test the patch
> > on x86_64-linux, procee
On Sun, Aug 29, 2010 at 01:24:47AM +0200, FX wrote:
> Before I submit it officially for review, I want this patch to get some
> exposure while I clean up a few remaining dusty corners. To test the patch on
> x86_64-linux, proceed as follows:
>
> -- Get libquad from http://quatramaran.ens.fr/~c
Before I submit it officially for review, I want this patch to get some
exposure while I clean up a few remaining dusty corners. To test the patch on
x86_64-linux, proceed as follows:
-- Get libquad from http://quatramaran.ens.fr/~coudert/tmp/libquad.tar.bz2 ,
then ./configure --prefix=/foo &
Snapshot gcc-4.6-20100828 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20100828/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
On Sat, Aug 28, 2010 at 12:43, NightStrike wrote:
> On Sat, Aug 28, 2010 at 12:45 PM, Eric Botcazou wrote:
>>> I'm very sceptical about "or any later version" instructions when
>>> building the gcc prerequisites. In practice this can never be certain
>>> to work, because the upstream maintainers
On Sat, Aug 28, 2010 at 12:45 PM, Eric Botcazou wrote:
>> I'm very sceptical about "or any later version" instructions when
>> building the gcc prerequisites. In practice this can never be certain
>> to work, because the upstream maintainers of these tools can change
>> them in ways that break gc
Basile,
you fully understood what I was asking. And I think I understood that I may
have to rethink what I wanted to do since the effort is seemingly out-weighing
the benefits.
thanks again.
jeff
--- On Sat, 8/28/10, Basile Starynkevitch wrote:
> From: Basile Starynkevitch
> Subject: Re: Guid
On Thu, 2010-08-26 at 18:16 -0700, Jeff Saremi wrote:
> I'm hoping someone here could take the time to outline what I need to do (i'm
> not looking for code but if you point me to some i'd appreciate it).
>
> I'd like to track an object from the it's created until it's destroyed (in
> C++). And
> I'm very sceptical about "or any later version" instructions when
> building the gcc prerequisites. In practice this can never be certain
> to work, because the upstream maintainers of these tools can change
> them in ways that break gcc.
Indeed, on the SPARC we seem to have problems (miscompil
On Thursday 26 August 2010 11:02 PM, Jonathan Wakely wrote:
On 26 August 2010 12:56, wrote:
a) Is there any way to observe the effect of a particular optimization,
without the obvious option of using a lot of -fno switches.
b) And do the -f* switches serve any purpose, if I can't enable ind
On Friday 27 August 2010 06:07 AM, Paul Brook wrote:
Hi,
I wish to selectively enable specific optimizations to observe its effect
on the source. My project requires me to do this analysis. It seemed, the
-f* flags would enable me to do that. But it turns out that individual
optimizations can't b
[ Redirect to gcc. This is a dev issue. ]
On 08/27/2010 10:39 PM, Tom Browder wrote:
>> On Fri, Aug 27, 2010 at 09:17, Andrew Haley wrote:
>>> However, just running download_prerequisites is, IMVHO, the only sane way
>>> to do it.
>
> That's the solution I used, and I got a good build--thanks fo
FX wrote:
Tobias' address doesn't accept my mails. Tobias, I hope you get those I send to
the list.
I have not seen any emails since 9:53 (CEST) at fortran@ - neither
directly nor via gcc.gnu.org/ml/fortran.
Le 28 août 2010 à 11:58, Mail Delivery Subsystem
a écrit :
Technical details o
Tobias' address doesn't accept my mails. Tobias, I hope you get those I send to
the list.
FX
Le 28 août 2010 à 11:58, Mail Delivery Subsystem
a écrit :
> Delivery to the following recipient failed permanently:
>
> bur...@net-b.de
>
> Technical details of permanent failure:
> Google tri
On Fri, Aug 27, 2010 at 4:03 PM, Richard Guenther
wrote:
>
> In fact we might want to move switch optimization up to the tree level
> (just because it's way easier to deal with there). Thus, lower switch
> to a mixture of binary tree & jump-tables (possibly using perfect
> hashing).
>
Doing the
16 matches
Mail list logo
