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
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
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
* 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
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
> 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
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
> 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
(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
