GCC: Name at (1) is too long

Help
1

I am creating bindings for Vulkan using GCC gfortran 14.2.1 20240910 and I am having severe issues with naming variable naming in it.

For example:
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ACCELERATION_STRUCTURE_PROPERTIES_KHR

The problem is, if I chop these to 63, there are multiple duplicates because they turn into vendor overloads for the variable names.

Is there any way to get GCC to compile with this arbitrary 63 char limit removed? I have tried

fpm run --flag -fmax-identifier-length=80

and it completely ignores it.

3

You should be seeing an error message for gfortran

f951: Fatal Error: Maximum supported identifier length is 63

instead of truncating the names, substitution with abbreviated names via actual file edits
or (if case is used consistently) using pre-processor directives might be an alternative?

      #define VERY_LONG_VARIABLE_NAME   SHORT_NAME

or carefully making sure nothing is changed you can use things like

    sed -i -e 's/\<LONG_VARIABLE_NAME\>/SHORTNM/g'  FILENAMES

to replace specific names in files or abbreviate things like

    sed - i -e 's/ACCELERATION_/ACCEL_/g'  FILENAMES

perhaps?

4

I appreciate that, but I am dealing with most likely tens of thousands of lines of code at the end of this so I am taking an alternative route and using static objects.

It appears GCC did not expect anyone to use their program for Vulkan so I understand this.

5

We’ve come a long way since the days of 6 characters per identifier… but somehow we want more. :laughing:

Part of the problem is that the linker may impose limits on identifier length.

I remember, when I first started using submodules with ifort, that I started getting warnings for things like

submodule (some_module_name) some_module_name_submodule_name
contains
    module procedure some_procedure_name
    ...

Because the procedure name for the linker would be some_module_name.some_module_name_submodule_name_MP_some_procedure_name_.

ifort issued only warnings, because it could solve the issue by chopping characters from the beginning of the identifier. But I decided it was better to just use the sm_ prefix convention as in

submodule (some_module_name) sm_submodule_name
contains
    module procedure some_procedure_name
    ...

You could similarly assume some conventions (I call this “getting LAPACKy”):

  • STRUCTURE_TYPE becomes TYPE
  • STRUCTURE becomes STRUCT
  • ACCELERATION becomes ACCEL
  • PROPERTIES becomes PROPS

With that, the name in your example becomes VK_TYPE_PHYSICAL_DEVICE_ACCEL_STRUCT_PROPS_KHR.

6

I totally understand that when Fortran was still on punch cards. But this is binding to the next version of OpenGL in modern Fortran, which will compile with no problems in the GCC C compiler. Edit: Conveyance of joking direct thought comes across as angry/aggressive in plain text so it’s removed.

That naming convention seems useful, but I am attempting to make it so you can utilize the existing Khronos documentation to program with this. Having to translate through that would be quite the nightmare.

7

Looking at these enums in Vulkan, VkStructureType(3), they are enough to keep me away from this library…

You could introduce an intermediate type

type, private :: vk_structure_type_enum
    integer(c_int) :: PHYSICAL_DEVICE_ACCELERATION_STRUCTURE_PROPERTIES_KHR = 1000150014
    ! ...
end type

type(vk_structure_type_enum), public, parameter :: vk_structure_type = vk_structure_type_enum()

And the point of access, you can use it as

print *, vk_structure_type % PHYSICAL_DEVICE_ACCELERATION_STRUCTURE_PROPERTIES_KHR

Is this stuff really meant to be used by humans, or is it meant to be used via code generation?

8

This one made me laugh :laughing: and thinking… who’s gonna write the code generation code itself? Humans, or another generated code? Seems like a never ending loop :smiley:

9

This is not a library, this is a graphics API that runs your GPU. This is as OpenGL, DirectX, and Metal.

I have gone with this approach: forvk/src/forvk/forvk_parameters.f90 at master · jordan4ibanez/forvk · GitHub

This is meant to be used by humans. You are basically directly controlling the GPU.

10

If I’m not mistaken, this limitation to 63 characters is speficied in section 6.2.2 of the 2023 standard. This standard increases the maximum line length and statement length to “support programs that are constructed mechanically” as noted by John Reid in his digest.

Following this logic, the length limit on names could have been increased too.

11

Maybe it will be increased if enough people suggests it with use cases and such, but I just noticed that a document in the J3 page has “2028” instead of “202y”, so I guess it’ll be at least another 4 years before the next standard.

12

I met the same problem when working with Vulkan. Therefore, I did a proposal:

It is unclear to me what the status of this request is.
Robert

2 Likes
14

My condolences. :stuck_out_tongue:

Maybe one day we’ll see it happen.