See:
https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01975.html
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap comparison failure!
gcc/tree-ssa-uninit.o differs
gcc/tree-switch-conversion.o d
On Fri, Apr 17, 2015 at 10:16 AM, Toon Moene wrote:
> See:
>
> https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01975.html
>
> Comparing stages 2 and 3
> warning: gcc/cc1-checksum.o differs
> warning: gcc/cc1obj-checksum.o differs
> warning: gcc/cc1plus-checksum.o differs
> Bootstrap comparison f
Hi,
I think the rtl dump in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64916
is not jump2 phase rtl dump.
Because jump2 is after ira, the register number should be hardware
register number.
the jump2 rtl dump should as follow
...
31: NOTE_INSN_BASIC_BLOCK 5
32: [r6:SI]=r4:SI
REG_D
I allowed me to CC Vladimir; maybe he can propose how the backend can describe
an efficient, constraint-based solution. The problem is about expanders
producing insns with non-fixed hard-regs as in/out operands or clobbers. This
includes move insn from non-generic address spaces which require
On 04/17/2015 10:49 AM, Richard Biener wrote:
On Fri, Apr 17, 2015 at 10:16 AM, Toon Moene wrote:
See:
https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01975.html
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1plus-checksu
Hi,
While investigating why the IRA preferencing algorithm often chooses incorrect
preferences from the
costs, I noticed this thread: https://gcc.gnu.org/ml/gcc/2011-05/msg00186.html
I am seeing the exact same issue on AArch64 - during the final preference
selection ira-costs takes
the union of
Dear gcc list,
we are trying to clarify what behaviour of C implementations is
actually relied upon in modern practice, and what behaviour is
guaranteed by current mainstream implementations (these are quite
different from the ISO standards, and may differ in different
contexts).
Focussing on the
Wilco Dijkstra writes:
> While investigating why the IRA preferencing algorithm often chooses
> incorrect preferences from the costs, I noticed this thread:
> https://gcc.gnu.org/ml/gcc/2011-05/msg00186.html
>
> I am seeing the exact same issue on AArch64 - during the final
> preference selection
> On Apr 17, 2015, at 9:14 AM, Peter Sewell wrote:
>
> Dear gcc list,
>
> we are trying to clarify what behaviour of C implementations is
> actually relied upon in modern practice, and what behaviour is
> guaranteed by current mainstream implementations (these are quite
> different from the ISO
On 17 April 2015 at 15:19, wrote:
>
>> On Apr 17, 2015, at 9:14 AM, Peter Sewell wrote:
>>
>> Dear gcc list,
>>
>> we are trying to clarify what behaviour of C implementations is
>> actually relied upon in modern practice, and what behaviour is
>> guaranteed by current mainstream implementations
On Tue, 14 Apr 2015 08:09:05 +0200, Jan Kratochvil wrote:
> On Fri, 10 Apr 2015 14:31:45 +0200, Jan Kratochvil wrote:
> > What is the recommended fix? I expect pointer to a declaration / opaque
> > type
> > which gets completed only when one references the 'p' field later?
>
> It looks as it got
> Matthew Fortune wrote:
> Wilco Dijkstra writes:
> > While investigating why the IRA preferencing algorithm often chooses
> > incorrect preferences from the costs, I noticed this thread:
> > https://gcc.gnu.org/ml/gcc/2011-05/msg00186.html
> >
> > I am seeing the exact same issue on AArch64 - dur
On 04/17/2015 09:01 AM, Peter Sewell wrote:
On 17 April 2015 at 15:19, wrote:
On Apr 17, 2015, at 9:14 AM, Peter Sewell wrote:
Dear gcc list,
we are trying to clarify what behaviour of C implementations is
actually relied upon in modern practice, and what behaviour is
guaranteed by curren
On 04/17/2015 03:57 AM, Shiva Chen wrote:
Hi,
I think the rtl dump in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64916
is not jump2 phase rtl dump.
Because jump2 is after ira, the register number should be hardware
register number.
the jump2 rtl dump should as follow
...
31: NOTE_INSN_B
On 03/10/2015 07:40 AM, BELBACHIR Selim wrote:
Me again :)
I enhanced my patch because it was not generalized for instructions with N
delay_slots.
Mostly OK, though there are some formatting nits that need to be corrected.
We have whitespace around arithmetic, logical and comparison operators
On 17 April 2015 at 17:03, wrote:
> On 04/17/2015 09:01 AM, Peter Sewell wrote:
>>
>> On 17 April 2015 at 15:19, wrote:
>>>
>>>
On Apr 17, 2015, at 9:14 AM, Peter Sewell
wrote:
Dear gcc list,
we are trying to clarify what behaviour of C implementations is
act
16 matches
Mail list logo