Compiler Warnings using -Wconversion

[senarclens]

After evaluating multiple unit test libraries for C my conclusion was that criterion might be the best available choice. However, I'm a bit unsure why there needs to be a compiler warning when using gcc -Wconversion as soon as assertions are used. For example using cr_assert triggers

warning: conversion from ‘int’ to ‘unsigned char:1’

regardless of the content of the assertion. Looking at the source I found that the warning is due to the assert node having a 1 bit bitfield for its pass member.

struct cri_assert_node {
    const char *repr;
    const char *message;
    struct cri_assert_param params[CRI_ASSERT_MAX_PARAMS];

    unsigned pass : 1;
    unsigned dynrepr : 1;
    uint32_t nchild : 30;
    uint32_t maxchild;
    struct cri_assert_node *children;
};

pass gets assigned a regular int (cri_tmpn.pass = cri_cond_un; after the preprocessor is done) leading to the warning.
I'm not aware of any way of preventing the warning other than increasing the size of pass to, eg, int (or char) or using a single integer for pass, dynrepr and nchild and applying bitmasks when reading or assigning them. I'm aware that the former would be a waste of 32 (or 8) additional bits of memory, the latter would require working with bitmasks. At the same time, I am far from sure whether it is worth having a warning for that amount of memory (or using bitmasks instead of bitfields) when using gcc (version 9.4.0 on my system) with the -Wconversion flag. I always use -Wconversion for my code to avoid unintentional mistakes and it would be lovely to keep it that way for my unit testing code as well.
So, out of honest curiosity, can someone please tell me the reasoning behind using bitfields in cri_assert_node (eg. the saved bits having a really important impact on embedded systems or the like + why bitmasks would not be an alternative either)?
Is there any way of getting rid of that message without disabling -Wconversion in gcc?
Thanks a lot!

[Snaipe]

The assert tree can get large for complex assertion criteria, so this was a way to avoid losing too much stack space. That said, criterion shouldn't cause warnings on use -- this is a bug.