David Daney <[EMAIL PROTECTED]> writes:
> > Eventually we should manually mark certain function DECLs as
> > not-returning-null instead of my kludgy test for this one case. I don't
> > know if/when I can get to that. Perhaps somebody else can take it from
> > here.
>
> Looks like all the bits i
Thanks Anthony. This has been bothering me for quite some time.
Anthony Green wrote:
Our compiler inlines many null pointer tests because the language
requires that we throw NullPointerExeceptions in certain cases that can
only be detected through explicit tests.
What's frustrating is that the
Aldy Hernandez wrote:
> (Frustratingly, max_index above yields false on integer_all_onesp(), but
> we can tackle that once we can agree what to do here.)
>
> Is it ok to special case max_index being -1?
Definitely.
This problem appears in various places; we represent array bounds using
a number
On Nov 11, 2005, at 4:15 PM, Andrew Pinski wrote:
I thought this was fixed by:
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00735.html
Thanks, I'm sure it was... (updating and rebuilding now)
Bobby McNulty wrote:
> Since this is just staying on the cutting edge of programming, I am only
> going to use release cygwin1.dll.
> Waiting for cygwin 1.5.19
FYI, http://cygwin.com/ml/cygwin-cvs/2005-q4/msg00072.html
>
> Anyone else seeing:
>
> ld64 failed: bl out of range (57687405 max is +/-16M) from
> ___ieee754_pow in .libs/libgcj.lax/libfdlibm.a/e_pow.o to _L4
> in .libs/libgcj.7.0.0.dylib
> /usr/bin/libtool: internal link edit command failed
> make[5]: *** [libgcj.la] Error 1
> make[5]: Leaving dire
Anyone else seeing:
ld64 failed: bl out of range (57687405 max is +/-16M) from
___ieee754_pow in .libs/libgcj.lax/libfdlibm.a/e_pow.o to _L4
in .libs/libgcj.7.0.0.dylib
/usr/bin/libtool: internal link edit command failed
make[5]: *** [libgcj.la] Error 1
make[5]: Leaving directory `/Volumes/m
Brian Dessent wrote:
Brian Dessent wrote:
/home/sherlock/gcc/o/gcc/xgcc -B/home/sherlock/gcc/o/gcc/
-B/usr/local/i686-pc-c
ygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem
/usr/local/i686-pc-cygwin/i
nclude -isystem /usr/local/i686-pc-cygwin/sys-include -DHAVE_CONFIG_H
-I. -I../.
./../../g
On Nov 11, 2005, at 8:18 AM, Ioannis E. Venetis wrote:
I sent this message about a week ago, but didn't get any response.
So, I try again.
Please don't. Imagine this list is about 100x more costly than
filing a bug report, even if the bug report is wrong.
If you want to discuss what a val
Gabriel Dos Reis wrote:
> Plain compiler bug. I'm not aware of any existing report to that
> effect, though GCC/g++ currently is completely confused when it sees
> apparently ambiguous declarations, and would report non-existent
> declaration. That needs fixing.
I have a patch-in-progress for t
On Fri, 2005-11-11 at 19:33 +, drizzle drizzle wrote:
> Hi .
>I want to use gcc's alias analysis in a standalone way. What I
> observe is that a lot of the information is hidden because of
> additional temporaries that have been generated. Can any one suggest
> as to if there is a simpl
When you compile a file that contains a line directive, e.g.:
# 1 "../../libgcc2.c"
int f ()
{
return 0;
}
using the -fpreprocessed option to cc1, but without -fdumpbase, the base
filename of the
line number directive us used both for the assembly output file and for
debugging dumps
from -da.
Hi .
I want to use gcc's alias analysis in a standalone way. What I
observe is that a lot of the information is hidden because of
additional temporaries that have been generated. Can any one suggest
as to if there is a simple workaround to this ?
To illustrate what I am saying
for a stmt
Adrian Prantl <[EMAIL PROTECTED]> writes:
> Another question is whether there is actually a need to carry around the two
> concepts of BYTES and UNITS anyway. It seems that for most backends those
> are of the same size anyway, and for the other backends it would be much
> easier if there were onl
>
> Hi,
>
> Something fixed something:
> http://www.inf.u-szeged.hu/csibe/draw-diag.php?draw=sum-ot&basephp=s-i686-linux
>
> Obviously there's no reason to complain. But does anyone know where
> this came from?
Actually only i686-linux is different. All the rest of the targets are still
high
Hi,
Something fixed something:
http://www.inf.u-szeged.hu/csibe/draw-diag.php?draw=sum-ot&basephp=s-i686-linux
Obviously there's no reason to complain. But does anyone know where
this came from?
Gr.
Steven
I sent this message about a week ago, but didn't get any response. So, I
try again. My question is whether this is a bug of gfortran and if I
should open a bug report about it. I haven't found this in Bugzilla.
Thank you!
Adrian Prantl wrote:
Hello everybody,
I am currently working on creating a new gcc backend for a word-addressable
machine with 24-Bit general purpose registers.
While doing so I came across a few inconsistencies regarding the usage of the
BITS_PER_UNIT Macro. (and UNITS_PER_WORD, in a related st
On Fri, 11 Nov 2005, Adrian Prantl wrote:
> Hello everybody,
>
> I am currently working on creating a new gcc backend for a word-addressable
> machine with 24-Bit general purpose registers.
If the smallest unit you can address, the one between
address N and N+1, is a "word" then the unit must be a
Hello everybody,
I am currently working on creating a new gcc backend for a word-addressable
machine with 24-Bit general purpose registers.
While doing so I came across a few inconsistencies regarding the usage of the
BITS_PER_UNIT Macro. (and UNITS_PER_WORD, in a related story)
Apparently a lot
20 matches
Mail list logo
