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
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
== 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
== 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
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.
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
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
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
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
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
10 matches
Mail list logo