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
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
> 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
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
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
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
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
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 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
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
> 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?
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
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.
---
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 --
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
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
16 matches
Mail list logo
