On 16.07.2018 00:00, Kamil Rytarowski wrote:
> On 15.07.2018 20:08, Christos Zoulas wrote:
>> Hi,
>>
>> Gcc is now working on aarch64 but the kernel does not compile because of
>> some idiomatic clang code that is not supported by gcc (at least gcc-6)
>>
>> To define constants, it uses:
>>
>> stati
On 16.07.2018 10:50, Kamil Rytarowski wrote:
> On 16.07.2018 00:00, Kamil Rytarowski wrote:
>> On 15.07.2018 20:08, Christos Zoulas wrote:
>>> Hi,
>>>
>>> Gcc is now working on aarch64 but the kernel does not compile because of
>>> some idiomatic clang code that is not supported by gcc (at least gc
>Gcc is now working on aarch64 but the kernel does not compile because of
>some idiomatic clang code that is not supported by gcc (at least gcc-6)
>
>To define constants, it uses:
>
>static const uintmax_t
>FOO = __BIT(9),
>BAR = FOO;
>
>While this is nice, specially for the debugger, it produces
On Sat, Jul 14, 2018 at 03:39:20PM +, co...@sdf.org wrote:
> hi folks,
>
> in
> https://github.com/NetBSD/src/commit/a9e749a2e2d0044b947401ce80790a5788fad76e#diff-9353912fc541114002b043446f11751e
> bouyer had moved many definitions out of usbhid.h.
>
> This is a user-visible header and appear
On 16.07.2018 11:07, Kamil Rytarowski wrote:
> On 16.07.2018 10:50, Kamil Rytarowski wrote:
>> On 16.07.2018 00:00, Kamil Rytarowski wrote:
>>> On 15.07.2018 20:08, Christos Zoulas wrote:
Hi,
Gcc is now working on aarch64 but the kernel does not compile because of
some idiomatic
I am trying to use the SD/MMC reader in my PC (Intel NUC), however I
always get the following error:
sdmmc0: sdmmc_mem_enable failed with error 60
sdmmc0: couldn't enable card: 60
60 is probably ETIMEDOUT, no? Any ideas what could be done?
For completeness, here is where the sdmmc attaches to:
Can we drop it? The __uint128_t type is not used anywhere else in
aarch64 subdirs.
fortunately, we don't use member of fpreg, use just only as container.
Is this patch enough?
cvs -q diff -aup pcb.h reg.h
Index: pcb.h
===
On Tue, Jul 17, 2018 at 02:23:36PM +0900, Ryo Shimizu wrote:
> union fpelem {
> uint64_t u64[2];
> - __uint128_t u128[1] __aligned(16);
> + /* __uint128_t u128[1] __aligned(16); */
> };
I like the alignement parts of the change, but I seriously do not
understand why the __uint128_t
