Re: [PATCH 1/6] generated character data for libc/ctype

[Can Finner <can dot finner at gmail dot com>]

On Tue, Mar 13, 2018 at 1:49 PM, Thomas Wolff <towo@towo.net> wrote:
> On 13.03.2018 13:49, Corinna Vinschen wrote:
>>
>> On Mar 13 12:02, Can Finner wrote:
>>>
>>> On Tue, Mar 13, 2018 at 11:21 AM, Can Finner <can.finner@gmail.com>
>>> wrote:
>>>>
>>>> On Tue, Mar 13, 2018 at 10:40 AM, Corinna Vinschen <vinschen@redhat.com>
>>>> wrote:
>>>>>
>>>>> On Mar 13 10:33, Can Finner wrote:
>>>>>>
>>>>>> On Mon, Mar 12, 2018 at 10:42 AM, Corinna Vinschen
>>>>>> <vinschen@redhat.com> wrote:
>>>>>>>
>>>>>>> On Mar  8 00:18, Thomas Wolff wrote:
>>>>>>>>
>>>>>>>> Makefile add-ons for both patch series (libc/string and libc/ctype)
>>>>>>>> will be
>>>>>>>> sent separately.
>>>>>>>>  From 4cd871bea1c6cf677d57587a7e844bb9cb3b19be Mon Sep 17 00:00:00
>>>>>>>> 2001
>>>>>>>> From: Thomas Wolff <towo@towo.net>
>>>>>>>> Date: Sun, 25 Feb 2018 16:29:33 +0100
>>>>>>>> Subject: [PATCH 1/6] generated case conversion data, Unicode 10.0
>>>>>>>> [...]
>>>>>>>
>>>>>>> Patchset pushed.  I just squashed the makefile patch into the
>>>>>>> previous
>>>>>>> patch to avoid a repository state not building.
>>>>>>
>>>>>> Hi,
>>>>>> This patch breaks arm-none-eabi cross toolchain build with below error
>>>>>> message:
>>>>>>
>>>>>> /data/.../obj/gcc1/gcc/xgcc -B/data/.../obj/gcc1/gcc/
>>>>>> -B/data/.../obj/newlib/arm-none-eabi/thumb/newlib/ -isystem
>>>>>> /data/.../obj/newlib/arm-none-eabi/thumb/newlib/targ-include -isystem
>>>>>> /data/.../newlib-cygwin/newlib/libc/include
>>>>>> -B/data/.../obj/newlib/arm-none-eabi/thumb/libgloss/arm
>>>>>> -L/data/.../obj/newlib/arm-none-eabi/thumb/libgloss/libnosys
>>>>>> -L/data/.../newlib-cygwin/libgloss/arm  -mthumb
>>>>>> -DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
>>>>>> -DPACKAGE_VERSION=\"3.0.0\" -DPACKAGE_STRING=\"newlib\ 3.0.0\"
>>>>>> -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -I.
>>>>>> -I/data/.../newlib-cygwin/newlib/libc/ctype -D__NO_SYSCALLS__
>>>>>> -D_COMPILING_NEWLIB -fno-builtin      -g -ffunction-sections
>>>>>> -fdata-sections -O2  -mthumb -c -o lib_a-categories.o `test -f
>>>>>> 'categories.c' || echo
>>>>>> '/data/.../newlib-cygwin/newlib/libc/ctype/'`categories.c
>>>>>> /data/.../newlib-cygwin/newlib/libc/ctype/categories.c:5:17: error:
>>>>>> width of 'cat' exceeds its type
>>>>>>     enum category cat: 11;
>>>>>>                   ^~~
>>>>>
>>>>> I don't understand this error.  Why is an enum < 11 bits?!?
>>>>
>>>> To be honest, I don't either.  Will collect more information about this.
>>>
>>> So it looks like arm ABI requires -fshort-enums for bare-metal
>>> toolchain, which will pack enum type into small int-type.
>>> In this case, the enum category as below has fewer than 256 entries in
>>> call cases?
>>> enum category {
>>> #include "categories.cat"
>>> };
>>
>> Have a look at the file, it has barely 32 categories, so even a :5
>> would suffice.
>>
>> Thomas, what was the idea here?  11 + 21 = 32, so was it just to
>> fill the struct?
>
> Yes, and to keep the Unicode value right-aligned. But 8/24 will do alike,
> please change it so.
Thanks for clarification, I will prepare a change.

Thanks,
bin
> Thomas
>
>
>>    If so, we may want to redefine the struct, as
>> suggested by Can:
>>
>>> If so, can we change it into below?  If not, is there any macro can be
>>> used to differentiate situations?
>>> struct _category {
>>>    enum category cat: 8;
>>>    unsigned int first: 24;
>>>    unsigned short delta;
>>> } __attribute__((packed));
>>
>> Thanks,
>> Corinna
>>
>



-- 
Regards.