On Fri, Mar 27, 2009 at 19:38, Richard Guenther wrote:
> I plan to merge the alias-improvements branch next weekend (in 7 days)
Looking forward to that! Thanks for doing this.
Diego.
I plan to merge the alias-improvements branch next weekend (in 7 days)
if all goes well. I will do bootstrap & regtesting on the archs
I have available (x86_64, i?86, ppc, ppc64, ia64, s390 and s390x).
During the next week I will try to extract all bugfixes from the branch
and apply them separat
Snapshot gcc-4.5-20090327 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20090327/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
Daniel Berlin wrote:
>> If we want to deprecate gccbug in 4.4 and remove it in 4.5 (and so not
>> need 4.5.1 or subsequent versions in this script), there is still time to
>> do so (though not to get it in the first deprecated-features-removal patch
>> for 4.5 - that has already been approved for
On Fri, Mar 27, 2009 at 6:34 PM, Joseph S. Myers
wrote:
> On Fri, 27 Mar 2009, Mark Mitchell wrote:
>
>> 12. Updating the email parsing script. AFAICT, this hasn't been done in
>> a while, so I wasn't sure if it was considered obsolete.
>
> I have done this. I'll deal with the snapshot and .pot
Snapshot gcc-4.4-20090327 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090327/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Fri, 27 Mar 2009, Mark Mitchell wrote:
> 12. Updating the email parsing script. AFAICT, this hasn't been done in
> a while, so I wasn't sure if it was considered obsolete.
I have done this. I'll deal with the snapshot and .pot files later.
I'll close 4.2 branch at some point after the PR s
[Joseph, Danny, see below for request.]
At long last, I have created the GCC 4.4 release branch.
We are now in Stage 1 on the mainline. Please go ahead and begin
checking in approved patches. Please try to coordinate so that we do
not have multiple overlapping radical changes. Please announce
Steven Bosscher wrote:
The problem doesn't happen on machines I own or have root access to.
It's only a problem when you try to do gcc development on machines
hosted by 3rd parties (SF compile farm, HP cluster, machines at places
where I work and/or where I try to convince people to use gfortran
On Fri, Mar 27, 2009 at 8:40 PM, Toon Moene wrote:
> Steven Bosscher wrote:
>
>> On Thu, Mar 26, 2009 at 10:39 PM, Kaveh R. Ghazi
>> wrote:
>>>
>>> If there are no objections, I'll create a patch.
>>
>> P... for those of us who just install the latest-and-greatest
>> fedora/suse/ubuntu/... on
Steven Bosscher wrote:
On Thu, Mar 26, 2009 at 10:39 PM, Kaveh R. Ghazi wrote:
If there are no objections, I'll create a patch.
P... for those of us who just install the latest-and-greatest
fedora/suse/ubuntu/... once and don't change installations for two or
three years (stable machine,
Bernd Roesch schrieb:
without changed headers old ompiler and libs do not work, because for C
there is no
sqrtf and other C99 funcs and many C++ programs get also many errors.
Ok, you are trying to add C99 functions to your libc. Apparently you
made a mistake if you get linker errors.
i see o
Eric Botcazou writes:
>> I need to add support for some custom attributes that I need to know during
>> operand matching. I have no problem adding the attributes, but I don't
>> know what to do so that I can access the information later. My function
>> that is called to handle the attribute loo
Ian Lance Taylor wrote:
By the way, from reading this messages I think that people have a
slightly rosier recollection of the egcs split than I do. I think the
egcs split was the right thing to do, but it was also a power play on
the part of Cygnus because we could not continue operating under
> I need to add support for some custom attributes that I need to know during
> operand matching. I have no problem adding the attributes, but I don't
> know what to do so that I can access the information later. My function
> that is called to handle the attribute looks like this:
>
> static tre
From: "Joe Buck"
Debian stable, and Ubuntu Hardy (most recent LTS release) have 2.3.1.
Same with OpenSUSE 11.0. So I think 2.3.1 is typical of current stable
releases; Fedora tends to be bleeding edge and not typical.
I still have to deal with older distros (e.g. RHEL 4), but it's
already nec
> Jan Hubicka wrote:
>
> > OK, pragma_java_exceptions variable is not there
>
> It's in mainline now.
>
> > does something like this work for you?
>
> Yes.
OK, I will do full testing cycle (x86_64-linux) and commit it.
Thanks!
Honza
>
> Andrew.
Jan Hubicka wrote:
> OK, pragma_java_exceptions variable is not there
It's in mainline now.
> does something like this work for you?
Yes.
Andrew.
> Jan Hubicka wrote:
>
> > current mainline is buggy in EH unwinding effectivly ignoring
> > MUST_NOT_THROW regions when reached via RESX from local handlers.
> > See http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01285.html for details.
> >
> > Unfortunately this patch causes bootstrap failure whe
I need to add support for some custom attributes that I need to know during
operand matching. I have no problem adding the attributes, but I don't know
what to do so that I can access the information later. My function that is
called to handle the attribute looks like this:
static tree
attr_mya
daniel tian writes:
> I am porting gcc to a 32bit RISC chip, and I met a logical
> error with 16bit arithmetic operations in generating assemble code.
> the error is between two 16bit data movement(unsigned short).
> While like A = B, A, and B are all unsigned short type. B is a
> result
Jan Hubicka wrote:
> current mainline is buggy in EH unwinding effectivly ignoring
> MUST_NOT_THROW regions when reached via RESX from local handlers.
> See http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01285.html for details.
>
> Unfortunately this patch causes bootstrap failure when building lib
Eus wrote:
> Hi Ho!
>
> On Fri, 2009-03-06 at 15:29 +0100, Paolo Bonzini wrote:
>>> So while trapping variants can certainly be introduced it looks like
>>> this task may be more difficult.
>> I don't think you need to introduce trapping tree codes. You can
>> introduce them directly in the front
Hi,
current mainline is buggy in EH unwinding effectivly ignoring
MUST_NOT_THROW regions when reached via RESX from local handlers.
See http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01285.html for details.
Unfortunately this patch causes bootstrap failure when building libjava,
because std::termina
Hi Ho!
On Fri, 2009-03-06 at 15:29 +0100, Paolo Bonzini wrote:
> > So while trapping variants can certainly be introduced it looks like
> > this task may be more difficult.
>
> I don't think you need to introduce trapping tree codes. You can
> introduce them directly in the front-end as
>
>
Hello,
I am porting gcc to a 32bit RISC chip, and I met a logical
error with 16bit arithmetic operations in generating assemble code.
the error is between two 16bit data movement(unsigned short).
While like A = B, A, and B are all unsigned short type. B is a
result of a series of computati
26 matches
Mail list logo
