"Andrew Pinski" <[EMAIL PROTECTED]> writes:
> On Jan 30, 2008 7:38 PM, Dongsheng Song <[EMAIL PROTECTED]> wrote:
>> See: http://www.linuxonly.nl/docs/2/0_Page_1.html
>
> It says:
> This is because NULL is not of the right type: it is defined as
> integer 0 instead of a pointer with the value 0.
>
Hi!
I have to insert NOP-instructions into the insn-stream in my back-
end. I do this with something ala emit_insn_after(gen_nop, xyz). This
works so far.
GCC leaves control-flow operations as they are, if it there are no
instructions which can be used to fill the branch delay slots. My
On Jan 31, 2008 12:45 AM, DJ Delorie <[EMAIL PROTECTED]> wrote:
>
> I'm debugging an EH failure on m32c-elf (-mcpu=m32c). The test case
> is this:
>
> extern int U();
>
> void *ra;
>
> main()
> {
> foo((ra + U()) - 1);
> }
>
> In the context of the bug, sizeof(void *) is 32 (well, PSImode = 24
>
Hi.
On cygwin with gcc trunk Fri Jan 25 12:38:35 UTC 2008 (revision 131824)
I get the following failure (among a few others... many ICE) that
might be easy to fix:
Executing on host: /usr/local/src/trunk/objdir/gcc/xgcc
-B/usr/local/src/trunk/objdir/gcc/
/usr/local/src/trunk/gcc/gcc/testsuite/gcc
Hiya.
On cygwin with gcc trunk Fri Jan 25 12:38:35 UTC 2008 (revision
131824), I get quite a few FAIL in the gnat testsuite due to errors
like this:
Executing on host: /usr/local/src/trunk/objdir/gcc/gnatmake
-I/usr/local/src/trunk/objdir/gcc/ada/rts
--GCC=/usr/local/src/trunk/objdir/gcc/xgcc
--G
Boris Boesler <[EMAIL PROTECTED]> writes:
> I have to insert NOP-instructions into the insn-stream in my back-
> end. I do this with something ala emit_insn_after(gen_nop, xyz). This
> works so far.
>
> GCC leaves control-flow operations as they are, if it there are no
> instructions which
2008/1/31, Manuel López-Ibáñez <[EMAIL PROTECTED]>:
> Nonetheless, if someone decided to go through the hassle of collecting
> tutorials and hints for various cross-compiling configurations in the
> wiki, I think many users will appreciate it. It is still considered by
> many to be a "dark art"[*].
> One issue here is that in some cases const and pure calls can get
> combined and eliminated even with attribute noinline (unless this
> changed recently). So in addition to attribute noinline, putting an
> asm volatile ("") in the function can help make it non-pure and
> non-const.
Yes, that di
On Jan 31, 2008 8:40 PM, DJ Delorie <[EMAIL PROTECTED]> wrote:
>
> > The problem you are running into is that sizeof(sizetype) !=
> > sizeof(void *). In the middle-end the type used as offset
> > (sizetype) doesn't have a defined signedness (it's unsigned for C,
> > signed for Ada for example), so
> The problem you are running into is that sizeof(sizetype) !=
> sizeof(void *). In the middle-end the type used as offset
> (sizetype) doesn't have a defined signedness (it's unsigned for C,
> signed for Ada for example), so we rely on the fact that its size
> should match that of pointers (as t
> Can you represent all pointer offsets (well, those you actually
> support) within sizetype?
Yes. It's a limit, but we live with it. It would be nice if the
offsets were extended according to their own sign, which gives us 1.5x
the range of choosing a single signedness.
> If so you probably o
On Jan 31, 2008 12:00 PM, DJ Delorie <[EMAIL PROTECTED]> wrote:
> Which file would that be in? It wasn't obvious from a simple grep.
> Or is that sprinkled all over the place?
The expansion is in expr.c with a comment of:
case POINTER_PLUS_EXPR:
/* Even though the sizetype mode and the
On Jan 31, 2008 9:11 PM, DJ Delorie <[EMAIL PROTECTED]> wrote:
>
> > case POINTER_PLUS_EXPR:
> > /* Even though the sizetype mode and the pointer's mode can be
> > different
> > expand is able to handle this correctly and get the correct result
> > out
> > of the PLUS_
> It's correct to always sign-extend the offset to the pointer mode
> width (or simply truncate it, if the offset width is larger than
> pointer mode width).
I'd argue against that if you're dereferencing a large structure
pointer. P->foo would always be an unsigned offset. Similarly for
arrays
> case POINTER_PLUS_EXPR:
> /* Even though the sizetype mode and the pointer's mode can be different
> expand is able to handle this correctly and get the correct result
> out
> of the PLUS_EXPR code. */
Me thinks that comment now needs some rethinking ;-)
On Jan 31, 2008 9:26 PM, DJ Delorie <[EMAIL PROTECTED]> wrote:
>
> > It's correct to always sign-extend the offset to the pointer mode
> > width (or simply truncate it, if the offset width is larger than
> > pointer mode width).
>
> I'd argue against that if you're dereferencing a large structure
>
On Mon, 21 Jan 2008, Tomas Bily wrote:
> Line 1250 in invoke.texi looks like: @include
> @value{srcdir}/../libiberty/at-file.texi
>
> It seems that @value{srcdir} after @include is not expanded (though). I
> found in archives that this problem was found few years ago
> (http://gcc.gnu.org/ml/gcc
17 matches
Mail list logo
