On Jul 17, 10:39am, n...@gmx.com (Kamil Rytarowski) wrote:
-- Subject: Re: aarch64 gcc kernel compilation
| I was thinking about this one:
|
| http://netbsd.org/~kamil/patch-00067-conditional-u128.txt
|
| It should do the trick for everybody - including rumpkernel users - and
| support aarch64
On 17.07.2018 07:23, Ryo Shimizu wrote:
>
> 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?
>
I was thinking about this one:
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
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 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
>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
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
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:
>
> static const uintmax_t
> FOO = __BIT(9),
> BAR = FOO;
>
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:
static const uintmax_t
FOO = __BIT(9),
BAR = FOO;
While this is nice, specially for the debugger, it produces an
