On Mon, May 4, 2015 at 9:42 PM, Aditya K wrote:
> I was able to successfully bootstrap gcc by using clang as the stage 1
> compiler. I configured gcc using the following arguments.
>
> ../configure --disable-multilib --enable-bootstrap --enable-languages=c,c++
> CC=/work/llvm/install-release/bin
On 05/04/2015 01:57 PM, Richard Henderson wrote:
>
> Sure.
>
> I'd be more inclined to support these compound conditionals directly, rather
> than try to get the compiler to recognize them after the fact.
>
> Indeed, I believe we have a near complete set of them in the x86 backend
> already. It
On 05/04/2015 01:45 PM, Linus Torvalds wrote:
> On Mon, May 4, 2015 at 1:33 PM, Richard Henderson wrote:
>>
>> A fair point. Though honestly, I was hoping that this feature would mostly
>> be
>> used for conditions that are "weird" -- that is, not normally describable by
>> arithmetic at all. O
On Mon, May 4, 2015 at 1:33 PM, Richard Henderson wrote:
>
> A fair point. Though honestly, I was hoping that this feature would mostly be
> used for conditions that are "weird" -- that is, not normally describable by
> arithmetic at all. Otherwise, why are you using inline asm for it?
I could
On 05/04/2015 01:35 PM, Linus Torvalds wrote:
> On Mon, May 4, 2015 at 1:14 PM, H. Peter Anvin wrote:
>>
>> I would argue that for x86 what you actually want is to model the
>> *conditions* that are available on the flags, not the flags themselves.
>
> Yes. Otherwise it would be a nightmare to tr
On Mon, May 4, 2015 at 1:14 PM, H. Peter Anvin wrote:
>
> I would argue that for x86 what you actually want is to model the
> *conditions* that are available on the flags, not the flags themselves.
Yes. Otherwise it would be a nightmare to try to describe simple
conditions like "le", which a rath
On 05/04/2015 01:14 PM, H. Peter Anvin wrote:
> On 05/04/2015 12:33 PM, Richard Henderson wrote:
>>
>> (0) The C level output variable should be an integral type, from bool on up.
>>
>> The flags are a scarse resource, easily clobbered. We cannot allow user code
>> to keep data in the flags. Whil
On 05/04/2015 01:14 PM, H. Peter Anvin wrote:
>>
>> Therefore:
>>
>> (1) Each target defines a set of constraint strings,
>>
>>E.g. for x86, wherein we're almost out of constraint letters,
>>
>> ja aux carry flag
>> jc carry flag
>> jo overflow flag
>> jp parity flag
On 05/04/2015 12:33 PM, Richard Henderson wrote:
>
> (0) The C level output variable should be an integral type, from bool on up.
>
> The flags are a scarse resource, easily clobbered. We cannot allow user code
> to keep data in the flags. While x86 does have lahf/sahf, they don't exactly
> per
On 05/02/2015 05:39 AM, Peter Zijlstra wrote:
> static inline bool __test_and_clear_bit(long nr, volatile unsigned long *addr)
> {
> bool oldbit;
>
> asm volatile ("btr %2, %1"
> : "CF" (oldbit), "+m" (*addr)
> : "Ir" (nr));
>
> return old
On 04/05/15 07:40, Martin Uecker wrote:
BTW: Why is 'nonnull' a function attribute and not something
which can be attached to pointer types?
I think this is something wanted for a long time:
https://gcc.gnu.org/ml/gcc/2006-04/msg00550.html
but nobody has implemented it yet. Perhaps there was
11 matches
Mail list logo
