(as an aside, as most target implementations treat pointers as unsigned
values, its not clear that presuming signed integer overflow semantics are
a reasonable choice for pointer comparison optimization)
The point is not of presuming signed integer overflow semantics (I was
corrected on this
> Date: Sun, 13 Apr 2008 16:18:04 +0530
> From: "Mohamed Shafi" <[EMAIL PROTECTED]>
> I am glad that the mistake has been rectified. But it would be of
> great help requirement of the '+' constraint for strict_low_part is
> mentioned somewhere in the gcc internals. Even though the mailing list
> h
Paul Schlie wrote:
Florian Weimer wrote:
Robert C. Seacord wrote:
i agree that the optimization is allowed by C99. i think this is a
quality of implementation issue, and that it would be preferable for
gcc to emphasize security over performance, as might be expected.
I don't think this is r
> Florian Weimer wrote:
>
>> Robert C. Seacord wrote:
>>
>> i agree that the optimization is allowed by C99. i think this is a
>> quality of implementation issue, and that it would be preferable for
>> gcc to emphasize security over performance, as might be expected.
>
> I don't think this is r
Florian Weimer wrote:
* Robert C. Seacord:
i agree that the optimization is allowed by C99. i think this is a
quality of implementation issue, and that it would be preferable for
gcc to emphasize security over performance, as might be expected.
I don't think this is reasonable. If you use
* Robert C. Seacord:
> i agree that the optimization is allowed by C99. i think this is a
> quality of implementation issue, and that it would be preferable for
> gcc to emphasize security over performance, as might be expected.
I don't think this is reasonable. If you use GCC and its C fronte
On Sat, Apr 12, 2008 at 12:13 AM, Jim Wilson <[EMAIL PROTECTED]> wrote:
> Mohamed Shafi wrote:
>
> > This looks like reordering is proper. When schedule-insn2 is run for
> > the above region/block the no:of instructions in the region
> > (rgn_n_insns) is 3.
> >
>
> Maybe bb reorder got the basic b
Hello all,
I have read in the internals that indirect_jump and jump pattern are
necessary in any back-end for the compiler to be build and work
successfully. For any back-end there will be some limitation as to how
big the offset used in the jump instructions can be. If the offset is
too big then
Hello all,
I am glad that the mistake has been rectified. But it would be of
great help requirement of the '+' constraint for strict_low_part is
mentioned somewhere in the gcc internals. Even though the mailing list
helped me to solve the problem , i could have saved some time had it
been documen
