On Fri, Apr 14, 2006 at 09:00:14PM +0100, Dave Murphy wrote:
> Ranjit Mathew wrote:
> >-BEGIN PGP SIGNED MESSAGE-
> >Hash: SHA1
> >
> >Dave Murphy wrote:
> >
> >>I've been having some odd problems with relocation of 4.x toolchains -
> >>i.e. when a toolchain is configured, built and inst
Snapshot gcc-4.1-20060414 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20060414/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Mike Hearn wrote:
> [So, what does
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24660
> Versioning weak symbols in libstdc++
> mean for ISVs? Will it solve the backwards compatibility problems
> mentioned in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21405 ? How?]
I'd love to know, too. I
Ranjit Mathew wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dave Murphy wrote:
I've been having some odd problems with relocation of 4.x toolchains -
i.e. when a toolchain is configured, built and installed with one prefix
but later moved to another location. The binaries appear to b
On Apr 14, 2006, at 10:16 AM, Shantonu Sen wrote:
Yes, I set that. That's the goal, using new features available in
Mac OS X 10.4 and creating binaries that are compatible with a
stock 10.4 system.
Right. Since the symbol doesn't exist on 10.4 you can't use it so we
can't update the 10.4
Yes, I set that. That's the goal, using new features available in Mac
OS X 10.4 and creating binaries that are compatible with a stock 10.4
system.
Shantonu
On Apr 14, 2006, at 10:13 AM, Eric Christopher wrote:
On Apr 14, 2006, at 8:29 AM, Shantonu Sen wrote:
(Moving to gcc@)
Eric, whe
On Apr 14, 2006, at 8:29 AM, Shantonu Sen wrote:
(Moving to gcc@)
Eric, when will this be resolved? It's been over a month, and test
suite results still are horrible
I had MACOSX_DEPLOYMENT_TARGET set in my environment, when I removed
that everything worked just fine for me... I can test
Hi,
A while ago I brought up the subject of C++ inlined symbols conflicting
inside a process image due to them having ELF global scope:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21405
Template inlines have global visibility
It seems there's now been a sort of fix, at least for libstdc++,
On 13 April 2006 20:04, Martin Hicks wrote:
> On Thu, Apr 13, 2006 at 07:32:39PM +0100, Dave Korn wrote:
>> On 13 April 2006 13:37, Martin Hicks wrote:
>>
>>> I posted a couple weeks ago to the list, but never got any responses.
>>> http://gcc.gnu.org/ml/gcc/2006-04/msg00054.html
>>>
>>> mh
>>
On Thu, Apr 13, 2006 at 01:29:13PM +0200, Paolo Bonzini wrote:
>
> What combine is doing is to expand compound operations such as
> zero_extract, simplifying them, and try to make new compound operations.
> Therefore you should first try to understand what's causing combine to
> miss the simpl
I think it is simply because combine.c doesn't have any code to simplify this kind of expression.
In theory it should have...
However, if you add these simplifications to simplify-rtx.c, it will
be picked up by combine.
There is a lot of simplification code in combine.c too. Should I
On Thu, 13 Apr 2006 13:29:13 +0200, Paolo Bonzini wrote
> > Also, is there a function for simplifying a zero_extract?
>
> What combine is doing is to expand compound operations such as
> zero_extract, simplifying them, and try to make new compound
> operations. Therefore you should first try t
12 matches
Mail list logo
