On Wed, Sep 13, 2023 at 9:09 PM Ken Matsui via Gcc <gcc@gcc.gnu.org> wrote:
>
> Hi,
>
> I have merged all my patches into a single branch for better
> maintainability for me, but I am unable to build GCC. Initially, I
> faced an error related to RID_MAX, which was fixed in
> https://github.com/ken-matsui/gcc-gsoc23/commit/c32d49bc990acde4d3ec5654ddb81b0a7d081378.
> The ICE was caused by gcc_assert (RID_MAX <= 255) in gcc/c/c-parser.c.
> At this point, my new built-in exceeded the max keyword bound since
> c_token->keyword has 8 bits. This patch increased the bit size to 16
> and compiled GCC successfully.
>
> However, I still encountered an unusual error and am unable to build
> GCC on 
> https://github.com/ken-matsui/gcc-gsoc23/commit/c32d49bc990acde4d3ec5654ddb81b0a7d081378.
> This is the 4th built-in implementation after the previous RID_MAX fix
> patch (i.e., this increases the total number of keywords, now RID_MAX
> = 260). The error message indicates that there is a missing
> parenthesis after 'unsigned' for the expression (unsigned __int128).
>
> /home/kmatsui/gcc/objdir/gcc/include/bmi2intrin.h:86:38: error:
> expected ‘)’ before ‘__int128’
>    86 |   unsigned __int128 __res = (unsigned __int128) __X * __Y;
>       |                             ~        ^~~~~~~~~
>       |                                      )
> /home/kmatsui/gcc/objdir/gcc/include/bmi2intrin.h:86:29: error:
> initializer element is not constant
>    86 |   unsigned __int128 __res = (unsigned __int128) __X * __Y;
>       |
>
> I reordered the commits, but it seems that the 4th built-in (RID_MAX =
> 260) after the RID_MAX tweak fails, regardless of what the 4th is.
> (i.e., the __remove_pointer implementation itself is not the reason.)

>From c-common.h:
#define C_SET_RID_CODE(id, code) \
  (((struct c_common_identifier *) (id))->node.rid_code = (unsigned char) code)

This is definitely incorrect now. It should be using `unsigned short`.

Thanks,
Andrew

>
> I have pushed the
> branch to https://github.com/ken-matsui/gcc-gsoc23/commits/me/gsoc23.
> Could someone please help me inspect the issue and provide your
> suggestions?
>
> Sincerely,
> Ken Matsui

Reply via email to