[I added the gcc list too since this is more than just a discussion about
a single patch.]
> > So, I went looking for an approach which would fix this in the C++
> > front-end instead. However, I discovered that the C front-end has a
> > similar problem.
> > And so, not changing the
> > middle-
On 8/26/06, Richard Kenner <[EMAIL PROTECTED]> wrote:
[I added the gcc list too since this is more than just a discussion about
a single patch.]
> > So, I went looking for an approach which would fix this in the C++
> > front-end instead. However, I discovered that the C front-end has a
> > si
> I completely agree. But only up to the point defining "proper analysis" -
> bootstrapping and regtesting is required for a patch to be accepted and
> I think it is a valid request from your side to require testing of Ada on
> Sparc for this patch as you remember problems on that platform. Given
On Aug 25, 2006, at 7:35 PM, Eric Christopher wrote:
Yes, it's a necessary part of the x86_64 work - the question is
whether or not x86_64-darwin might go in for 4.2 at all.
Mark has recently stated his position (http://gcc.gnu.org/ml/gcc-
patches/2006-08/msg00924.html) on patches that are va
Paolo Bonzini <[EMAIL PROTECTED]> writes:
>> If the general replacement of REG_OK_STRICT is indeed
>> reload_in_progress || reload_completed, then the substitution
>> *should* of course be in principle be correct (as in: subject to
>> testing. ;)
> Sure. After I'm done with the base_reg_class chan
If we have the following IR (before the first may_alias pass):
f1 (a)
{
short int b;
short unsigned int b.2;
short int b.1;
int D.1525;
short unsigned int a.0;
:
a.0_2 = (short unsigned int) a_1;
# b_4 = V_MUST_DEF ;
VIEW_CONVERT_EXPR(b) = a.
b.1_5 = b;
b.2_6 = (short unsigne
Eric,
I just reran "make -k check RUNTESTFLAGS='--target_board "unix{-m64}"'" in
the
darwin_objdir/powerpc-apple-darwin8/libstdc++-v3 directory after applying the
following patch to suppress the "can't find atom for N_GSYM stabs" ld64 linker
warnings...
--- gcc-4.2-20060825/libstdc++-v3/test
Snapshot gcc-4.2-20060826 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20060826/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
Would any of the gcc developers care to drop by the python-dev
mailing list and give the author of python an answer?
http://mail.python.org/pipermail/python-dev/2006-August/068482.html
On 8/26/06, Jack Howarth wrote:
>
On Sat, 2006-08-26 at 09:48 -0700, Andrew Pinski wrote:
> If we have the following IR (before the first may_alias pass):
> The may_alias pass removes the TREE_ADDRESSABLE on b so we ICE in the
> checking pass after may_alias runs. Does someone have an idea on where
> it is going wrong?
I have a
Dan,
Thanks for the detailed reply on the python-dev mailing list. I
had a feeling we would run into resistance on this (otherwise these
issues would have been already fixed). That's why discussions like
the "gcc trunk vs python" thread can be useful even though they are
off-topic to the list. O
Jack Howarth wrote:
Would any of the gcc developers care to drop by the python-dev
mailing list and give the author of python an answer?
http://mail.python.org/pipermail/python-dev/2006-August/068482.html
*Guido van Rossum wrote:
*
I'm not sure I follow why this isn't considered a regre
Michael Veksler wrote:
First, you can always use -fwarpv and retail old behavior. Any code that
^^
-fwrapv
13 matches
Mail list logo
