On 04/10/2011 23:47, Andrew Pinski wrote:
On Tue, Oct 4, 2011 at 2:40 PM, David Brown wrote:
"naked" functions are often useful in embedded systems, and are therefore
useful (and implemented) on many gcc targets. It would make sense to have
the attribute available universally in gcc, if that d
On Wed, 05 Oct 2011 10:37:22 +0900
shiot...@rd.ten.fujitsu.com (塩谷晶彦) wrote:
> Hi, Maintainer,
>
> I found some incidents in
> http://gcc.gnu.org/onlinedocs/gcc/ARM-NEON-Intrinsics.html#ARM-NEON-Intrinsics
>
> Please check the following:
>
> |6.54.3.8 Comparison (less-than-or-equal-to)
> |
> |
David Brown writes:
>
> Some toolchains are configured to have a series of "init" sections at
> startup (technically, that's a matter of the default linker scripts
> and libraries rather than the compiler). You can get code to run at
> specific times during startup by placing the instructions dir
On 05/10/2011 12:00, Andi Kleen wrote:
David Brown writes:
Some toolchains are configured to have a series of "init" sections at
startup (technically, that's a matter of the default linker scripts
and libraries rather than the compiler). You can get code to run at
specific times during startu
On 10/05/2011 12:14 AM, Jeffrey Yasskin wrote:
If, as the document proposes, "16 byte volatile will have to call the
external rotines, but 16 byte non-volatiles would be lock-free.", and
the external routines use locked accesses for 16-byte volatile
atomics, then this makes the concurrent access
On Wed, Oct 5, 2011 at 5:49 AM, Andrew MacLeod wrote:
> On 10/05/2011 12:14 AM, Jeffrey Yasskin wrote:
>> I see two ways out:
>> 1) Say that accessing a non-volatile atomic through a volatile
>> reference or pointer causes undefined behavior. The standard doesn't
>> say that, and the casts are imp
On 10/05/2011 10:44 AM, Jeffrey Yasskin wrote:
Yes, that's what I'm suggesting. The rule for 'volatile' from the
language is just that "Accesses to volatile objects are evaluated
strictly according to the rules of the abstract machine." If the
instruction-level implementation for a 16-byte atomi
These patterns:
> (define_insn "avx2_lshlqv4di3"
> [(set (match_operand:V4DI 0 "register_operand" "=x")
> (ashift:V4DI (match_operand:V4DI 1 "register_operand" "x")
> (match_operand:SI 2 "const_0_to_255_mul_8_operand"
> "n")))]
> "TARGET_AVX2"
> {
> operands[2]
On Wed, Oct 5, 2011 at 8:57 PM, Richard Henderson wrote:
> These patterns:
>
>> (define_insn "avx2_lshlqv4di3"
>> [(set (match_operand:V4DI 0 "register_operand" "=x")
>> (ashift:V4DI (match_operand:V4DI 1 "register_operand" "x")
>> (match_operand:SI 2 "const_0_to_255
Hi,
I've been experimenting with different methods for emulating the
signed overflow of an 8-bit CPU. The method I've found that seems to
generate the most efficient code on both ARM and x86 is
bool overflow(unsigned int a, unsigned int b) {
const unsigned int sum = (int8_t)a + (int8_t)b;
On Wed, Oct 5, 2011 at 10:11 PM, Ulf Magnusson wrote:
> Hi,
>
> I've been experimenting with different methods for emulating the
> signed overflow of an 8-bit CPU. The method I've found that seems to
> generate the most efficient code on both ARM and x86 is
>
> bool overflow(unsigned int a, unsign
On 10/4/2011 12:08 AM, Iain Buclaw wrote:
I've have received news from Walter Bright that the license of the D
frontend has been assigned to the FSF. As the current maintainer of
GDC, I would like to get this moved forward, starting with getting the
ball rolling. What would need to be done? And
Em 05-10-2011 17:11, Ulf Magnusson escreveu:
> Hi,
>
> I've been experimenting with different methods for emulating the
> signed overflow of an 8-bit CPU.
You would like to check whether a 8-bit signed addition will overflow or
not, given the two operands. Is that correct?
As you used the word `
13 matches
Mail list logo
