public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
* gfc_char_t
@ 2022-01-09 21:46 Harald Anlauf
  2022-01-09 22:00 ` gfc_char_t Andrew Pinski
  0 siblings, 1 reply; 4+ messages in thread
From: Harald Anlauf @ 2022-01-09 21:46 UTC (permalink / raw)
  To: fortran

Dear all,

while working on a PR related to kind=4 character issues, I saw the
following in gfortran.h:


/* We need to store source lines as sequences of multibyte source
    characters. We define here a type wide enough to hold any multibyte
    source character, just like libcpp does.  A 32-bit type is enough.  */

#if HOST_BITS_PER_INT >= 32
typedef unsigned int gfc_char_t;
#elif HOST_BITS_PER_LONG >= 32
typedef unsigned long gfc_char_t;
#elif defined(HAVE_LONG_LONG) && (HOST_BITS_PER_LONGLONG >= 32)
typedef unsigned long long gfc_char_t;
#else
# error "Cannot find an integer type with at least 32 bits"
#endif


This seems to have been introduced by FX, but I do not really
understand it.  Can't we use a fixed and platform-independent
type that can hold wide chars?  Isn't a 32-bit / 4-byte type
sufficient?

Thanks for any enlightenment,
Harald


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: gfc_char_t
  2022-01-09 21:46 gfc_char_t Harald Anlauf
@ 2022-01-09 22:00 ` Andrew Pinski
  2022-01-09 22:22   ` gfc_char_t Harald Anlauf
  0 siblings, 1 reply; 4+ messages in thread
From: Andrew Pinski @ 2022-01-09 22:00 UTC (permalink / raw)
  To: Harald Anlauf; +Cc: fortran

On Sun, Jan 9, 2022 at 1:46 PM Harald Anlauf via Fortran
<fortran@gcc.gnu.org> wrote:
>
> Dear all,
>
> while working on a PR related to kind=4 character issues, I saw the
> following in gfortran.h:
>
>
> /* We need to store source lines as sequences of multibyte source
>     characters. We define here a type wide enough to hold any multibyte
>     source character, just like libcpp does.  A 32-bit type is enough.  */
>
> #if HOST_BITS_PER_INT >= 32
> typedef unsigned int gfc_char_t;
> #elif HOST_BITS_PER_LONG >= 32
> typedef unsigned long gfc_char_t;
> #elif defined(HAVE_LONG_LONG) && (HOST_BITS_PER_LONGLONG >= 32)
> typedef unsigned long long gfc_char_t;
> #else
> # error "Cannot find an integer type with at least 32 bits"
> #endif
>
>
> This seems to have been introduced by FX, but I do not really
> understand it.  Can't we use a fixed and platform-independent
> type that can hold wide chars?  Isn't a 32-bit / 4-byte type
> sufficient?

I suspect HOST_BITS_PER_INT will always be 32bit for all hosts GCC
will be supported but who knows. The point of the check is to find a
type which is at least 32bits enough to hold the wide character.
HOST_BITS_PER_* are defined in hwint.h:
#define HOST_BITS_PER_CHAR  CHAR_BIT
#define HOST_BITS_PER_SHORT (CHAR_BIT * SIZEOF_SHORT)
#define HOST_BITS_PER_INT   (CHAR_BIT * SIZEOF_INT)
#define HOST_BITS_PER_LONG  (CHAR_BIT * SIZEOF_LONG)
#define HOST_BITS_PER_PTR   (CHAR_BIT * SIZEOF_VOID_P)

Where SIZEOF_* are defined while doing a configure and CHAR_BIT is
defined in limits.h which is defined as a preprocessor constant.
Does that help you understand the code better?

Thanks,
Andrew Pinski


>
> Thanks for any enlightenment,
> Harald
>

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: gfc_char_t
  2022-01-09 22:00 ` gfc_char_t Andrew Pinski
@ 2022-01-09 22:22   ` Harald Anlauf
  2022-01-09 22:22     ` gfc_char_t Harald Anlauf
  0 siblings, 1 reply; 4+ messages in thread
From: Harald Anlauf @ 2022-01-09 22:22 UTC (permalink / raw)
  To: Andrew Pinski; +Cc: fortran

Hi Andrew,

Am 09.01.22 um 23:00 schrieb Andrew Pinski via Fortran:
> On Sun, Jan 9, 2022 at 1:46 PM Harald Anlauf via Fortran
> I suspect HOST_BITS_PER_INT will always be 32bit for all hosts GCC
> will be supported but who knows. The point of the check is to find a
> type which is at least 32bits enough to hold the wide character.
> HOST_BITS_PER_* are defined in hwint.h:
> #define HOST_BITS_PER_CHAR  CHAR_BIT
> #define HOST_BITS_PER_SHORT (CHAR_BIT * SIZEOF_SHORT)
> #define HOST_BITS_PER_INT   (CHAR_BIT * SIZEOF_INT)
> #define HOST_BITS_PER_LONG  (CHAR_BIT * SIZEOF_LONG)
> #define HOST_BITS_PER_PTR   (CHAR_BIT * SIZEOF_VOID_P)
>
> Where SIZEOF_* are defined while doing a configure and CHAR_BIT is
> defined in limits.h which is defined as a preprocessor constant.
> Does that help you understand the code better?

ok, that makes things clearer now.

(I've actually never looked into hwint.h before.  I should have.)

Thanks,
Harald

> Thanks,
> Andrew Pinski
>
>
>>
>> Thanks for any enlightenment,
>> Harald
>>
>


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: gfc_char_t
  2022-01-09 22:22   ` gfc_char_t Harald Anlauf
@ 2022-01-09 22:22     ` Harald Anlauf
  0 siblings, 0 replies; 4+ messages in thread
From: Harald Anlauf @ 2022-01-09 22:22 UTC (permalink / raw)
  To: fortran; +Cc: fortran

Hi Andrew,

Am 09.01.22 um 23:00 schrieb Andrew Pinski via Fortran:
> On Sun, Jan 9, 2022 at 1:46 PM Harald Anlauf via Fortran
> I suspect HOST_BITS_PER_INT will always be 32bit for all hosts GCC
> will be supported but who knows. The point of the check is to find a
> type which is at least 32bits enough to hold the wide character.
> HOST_BITS_PER_* are defined in hwint.h:
> #define HOST_BITS_PER_CHAR  CHAR_BIT
> #define HOST_BITS_PER_SHORT (CHAR_BIT * SIZEOF_SHORT)
> #define HOST_BITS_PER_INT   (CHAR_BIT * SIZEOF_INT)
> #define HOST_BITS_PER_LONG  (CHAR_BIT * SIZEOF_LONG)
> #define HOST_BITS_PER_PTR   (CHAR_BIT * SIZEOF_VOID_P)
> 
> Where SIZEOF_* are defined while doing a configure and CHAR_BIT is
> defined in limits.h which is defined as a preprocessor constant.
> Does that help you understand the code better?

ok, that makes things clearer now.

(I've actually never looked into hwint.h before.  I should have.)

Thanks,
Harald

> Thanks,
> Andrew Pinski
> 
> 
>>
>> Thanks for any enlightenment,
>> Harald
>>
> 



^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-01-09 22:22 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-09 21:46 gfc_char_t Harald Anlauf
2022-01-09 22:00 ` gfc_char_t Andrew Pinski
2022-01-09 22:22   ` gfc_char_t Harald Anlauf
2022-01-09 22:22     ` gfc_char_t Harald Anlauf

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).