(KNOWN???) bug in C-compiler on X86

[joukj]

Is this a known bug that will be solved in the next version of the compiler?

Code: Select all

rumba-jj) cc/vers
VSI C X7.4-726 (GEM 50X23) on OpenVMS x86_64 V9.2-1  
rumba-jj) ty string-desc.c
#include <stdarg.h>

typedef struct string_desc_t string_desc_t;
struct string_desc_t
{
  /* The fields of this struct should be considered private.  */
  int _nbytes;
  char *_data;
};
int
string_desc_concat (string_desc_t *resultp, int n, string_desc_t string1, ...)
{
      va_list other_strings;

      va_start (other_strings, string1);
          string_desc_t arg = va_arg (other_strings, string_desc_t);
      va_end (other_strings);
    }

  return 0;
}
  22-JUN-2023 15:51:34
rumba-jj) cc/point=64 string-desc.c

  return 0;
..^
%CC-E-DECLARATOR, Invalid declarator.
at line number 20 in file $DISK0:[JOUKJ.test]string-desc.c;9

          string_desc_t arg = va_arg (other_strings, string_desc_t);
..............................^
%CC-E-COMPILERBUG, Bug found in compiler: NYI - va_arg with large structures.
at line number 16 in file $DISK0:[JOUKJ.test]string-desc.c;9
Internal compiler error detected at line 1902 in file CAREA:[SRC.ME_GEMC]BUILTIN
.C;1.
%SYSTEM-F-ACCVIO, access violation, reason mask=06, virtual address=000000000000
0000, PC=00000000002DC125, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
image     module    routine               line      rel PC           abs PC     
DECC$COMPILER  BUILTIN.C;1  gemc_va_arg_gen
                                        #82656 00000000002DC125 00000000002DC125
DECC$COMPILER  EXPRGEN.C;1  generate_il_expression
                                        #79266 0000000000320B75 0000000000320B75
DECC$COMPILER  EXPR.C;1  perform_expr_interpretation
                                        #71365 000000000012B4A6 000000000012B4A6
DECC$COMPILER  EXPR.C;1  interpret_source_expression
                                        #73587 00000000001084FC 00000000001084FC
DECC$COMPILER  INIT.C;1  initialize_component
                                        #53450 000000000014B8E7 000000000014B8E7
DECC$COMPILER  INIT.C;1  interpret_source_initializer
                                        #51662 0000000000146AE4 0000000000146AE4
DECC$COMPILER  DECL.C;1  interpret_source_declaration
                                        #66763 00000000000FAE5B 00000000000FAE5B
DECC$COMPILER  STMT.C;1  interpret_statement_sequence
                                        #60528 0000000000198BCD 0000000000198BCD
DECC$COMPILER  STMT.C;1  interpret_statement_sequence
                                        #60891 0000000000198E02 0000000000198E02
DECC$COMPILER  STMT.C;1  interpret_function_body
                                        #64471 0000000000196B2C 0000000000196B2C
DECC$COMPILER  DECL.C;1  interpret_source_declaration
                                        #63793 00000000000F1F76 00000000000F1F76
DECC$COMPILER  FEMAST.C;1  fe_master    #61057 000000000013611E 000000000013611E
DECC$COMPILER  COMPILE.C;1  gem_xx_compile
                                       #102848 000000000042220E 000000000042220E
DECC$COMPILER  GEM_VER_AREA:<SRC>GEM_CP_VMS.BLI;1  GEM_CP_MAIN
                                         #2643 00000000006D4C1E 00000000006D4C1E
DECC$COMPILER                                0 0000000000AD76D4 0000000000AD76D4
DECC$COMPILER                                0 00000000020F6D6D 00000000020F6D6D
PTHREAD$RTL                                  0 000000008004122C FFFF83000A10322C
PTHREAD$RTL                                  0 0000000080002316 FFFF83000A0C4316
                                             0 FFFF8300085FC0A6 FFFF8300085FC0A6
DCL                                          0 000000008006778B 000000007ADFF78B
%TRACE-I-LINENUMBER, Leading '#' specifies a source file record number.
%TRACE-I-END, end of TRACE stack dump
rumba-jj)

[jwtb]

hi,

not tested here, no direct comment to your findings, but it look like newer X7.4-785 is available.
jwtb

[jreagan]

You pass string desciptors by value? They occupy multiple argument slots.

varargs.h on x86 with the AMD64 calling standard are quite unique. A va_list isn't just an array of argument pointers anymore (like they are on every other platform), but rather a struct with some flags, counts, and two embedded pointers. The additional code to make that work with the GEM to LLVM converter was going to be extensive and we weren't sure of the usage. There were zero occurrences of this in all of the C code we've compiled to far (everything in the OS, everything in DECwindows, everything in the various layered products, and everything in the open source so far). So you are the first.

I'll add a ticket.

Added in 1 minute 15 seconds:
And I should at least put something in the release notes. I actually had forgotten all about this since it hasn't come up as an issue until now.

[joukj]

I encountered the problem when compiling the new version of gettext (0.22). The previous version did not have the problem.