Gary Knott wrote:
Dear Gnu gcc person,
We have written our own FP exception handler for our
use (because we want 1e155*1e155 to return 1.797...e308 (maxpos),
and not a NaN!, and so on.)
I assume you mean plus infinity?
For this to work in our gcc-compiled code, we need gcc t
Dear Gnu gcc person,
We have written our own FP exception handler for our
use (because we want 1e155*1e155 to return 1.797...e308 (maxpos),
and not a NaN!, and so on.)
For this to work in our gcc-compiled code, we need gcc to generate
fwaits where needed (after all non-interrupting FP instructio
OK, I have put a preview of the tree-check pass (performing lightweight
user-defined checks) on:
http://mygcc.free.fr.
Any comments are welcome.
Nic.
On Tue, 2006-03-28 at 17:23, Diego Novillo wrote:
> On 03/27/06 16:35, Nic Volanschi wrote:
>
> > The checks are specified using a new option --
The v850 is a dwarf-debug target, but not a dwarf-unwind target. In
dwarf2out.c we first calculate the "fp to fb offset" in
compute_frame_pointer_to_fb_displacement. The frame pointer is not
needed, so note that we include the fp-sp elimination offset in
frame_pointer_fb_offset.
---
Hi,
I've sent this request for assignment last week to [EMAIL PROTECTED]
Will I receive (only) a snail mail answer? Did I submit the right version
of the form?
Thanks for any help,
Nic.
--
REQUEST: SEND FORM FOR PAST AND FUTURE
> Ranjit Mathew writes:
Ranjit> Did the SC get to deliberate on this issue? Was this
Ranjit> message:
Ranjit> http://gcc.gnu.org/ml/gcc/2006-03/msg00558.html
Ranjit> on inclusion of source code from other projects in GCC a
Ranjit> direct result of these discussions or a mere coincidence?
configured with:
../srcw/configure --with-arch=i686 --enable-languages=c,c++,java,objc
failure:
/mnt/scratch/nightly/2006-04-03/i686/./gcc/xgcc
-B/mnt/scratch/nightly/2006-04-03/i686/./gcc/
-B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/
-isystem /usr/local/i686-pc-lin
On Mon, Apr 03, 2006 at 10:31:19AM -0400, Martin Hicks wrote:
>
> Hi,
>
> I've run into a piece of code on ppc405 that does the wrong thing when a
> function is automatically inlined. I don't really do ppc asm so I
> haven't been able to isolate what exactly the problem is, but the code
> blata
It seems that there is already a PIC port for gcc.. in the form of
Microchips own MPLAB C30 compiler.. I didn't realise this (and google
certainly didn't tell me) until I had started on the PIC14 port for gcc, and
went to the Microchip website for some info, and searched on "C compiler"
and the
On 4/4/06, Andrew Haley <[EMAIL PROTECTED]> wrote:
> Rémy Saissy writes:
>
> > > It would take a massive target-specific backend hack to make that
> > > happen, as GCC > currently only supports flat address spaces. ;-)
> >
> > I don't understand why.
> > gcc currently consider every data acces
Rémy Saissy writes:
> > It would take a massive target-specific backend hack to make that
> > happen, as GCC > currently only supports flat address spaces. ;-)
>
> I don't understand why.
> gcc currently consider every data access on i386 to be %ds:offset or
> %ss:offset
> depending on th
Ashwin writes:
> I have a combiner pattern that converts a sub-cmp pattern to a cmp insn,
> something like this -
> "if (a-1 < 0)"
> is converted to
> "if (a<1)"
>
> Now consider the following test case -
>
>
> f(long a){return (--a > 0);}
> main(){if(f(0x8000L)==0)abort();exit(0
On 04 April 2006 10:39, Ashwin wrote:
> I have a combiner pattern that converts a sub-cmp pattern to a cmp insn,
> something like this -
> "if (a-1 < 0)"
> is converted to
> "if (a<1)"
>
> When 1 is subtracted from MIN,
> Similar problem seems to arise when MAX is passed to a function that
> do
> It would take a massive target-specific backend hack to make that happen, as
> GCC > currently only supports flat address spaces. ;-)
I don't understand why.
gcc currently consider every data access on i386 to be %ds:offset or %ss:offset
depending on the instruction. The purpose is only to add
I have a combiner pattern that converts a sub-cmp pattern to a cmp insn,
something like this -
"if (a-1 < 0)"
is converted to
"if (a<1)"
Now consider the following test case -
f(long a){return (--a > 0);}
main(){if(f(0x8000L)==0)abort();exit(0);}
The compiler generates the following code
On 4/2/06, Roger Sayle <[EMAIL PROTECTED]> wrote:
>
> Following some of my recent middle-end clean-ups, I believe that
> we're now at the point where incrementally the middle-end can
> start ignoring the TREE_OVERFLOW bits on constant tree nodes.
> As a step in this direction, the patch below remov
16 matches
Mail list logo
