On Wed, Nov 17, 2010 at 11:22 AM, Dave Martin wrote:
> On Wed, Nov 17, 2010 at 2:53 AM, Michael Hope wrote:
>> In general the product should move forward and drop work-arounds like
>> -mimplicit-it. We (the greater ARM community) should fix these
>> package problems as they are found. Here's a
LP:663939 - Thumb2 constants
* Continued testing, found a few bugs. Tidied a few bits up.
* Wrote some new testcases to go with the patch.
LP:618684 - ICE
* Begun looking at this one. So far I can't reproduce it. I have a
debuggable native toolchain building, but it'd been delayed by hardw
Hi Richard,
As per the discussion at this mornings call; I've reread the TRM and I
agree with you about the LSLS being the same speed as the TST. (1 cycle)
However as we agreed, the uxtb does look like 2 cycles v the AND 1 cycle.
On the space v perf theme, one thing that would be interesting to
For the record, the thing I half-remembered on the call was:
http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00697.html
and:
http://gcc.gnu.org/ml/gcc-patches/2009-09/msg02112.html
The problem is that all __sync operations besides __sync_lock_test_and_set
and __sync_lock_release are defined
On 17 November 2010 13:21, Julian Brown wrote:
>> > We'd need to figure out what the RTL for such loads/stores should
>> > look like, and whether it can represent alignment constraints, or
>> > strides, or loads/stores of multiple vector registers simulateously.
Alignment info is kept in struct p
On Mon, 22 Nov 2010, Dave Martin wrote:
> So I've now come round to the view that we _should_ probably bite the
> bullet and fix the inline asm directly. So:
>
>* We need to verify which binutils permit (and ignore) the IT
> instructions in non-unified (ARM) syntax. I've observed that 2.19.
== Linaro GCC ==
* Continued looking at big-endian/quad-vector patch: attempted to
figure out the proper semantics for vec_extract in big endian mode
(about 1 day). Put on hold temporarily to work on lp675347, QT failing
to build due to constraint failure in inline asm statements used for
atomic
== Last Week ==
* Reached the point with understanding libunwind where I can begin
writing patches for parsing unwind information out of .ARM.exidx and
.ARM.extab ELF sections.
== This Week ==
* Begin writing support for ARM-specific unwind information to libunwind.
--
Zach Welch
CodeSourcery
Hi,
On Mon, Nov 22, 2010 at 2:39 PM, Nicolas Pitre wrote:
[...]
> I hope there is at least a validation of the IT instructions by the
> assembler with regards to the condition codes on the following
> instructions (and vice versa) to make sure they are all coherent, and
> even so for ARM mode c
On Tue, Nov 23, 2010 at 12:34 AM, Richard Sandiford
wrote:
> For the record, the thing I half-remembered on the call was:
>
> http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00697.html
> and:
> http://gcc.gnu.org/ml/gcc-patches/2009-09/msg02112.html
>
> The problem is that all __sync operations
10 matches
Mail list logo