Hi Guys,

  Suppose a programmer creates a function called "memset" and then
  compiles it with gcc.  Eg:

    % cat memset.c
    
    void *
    memset (void *s, int c, unsigned int n)
    {
      char *v = s;

      while (n--)
         *v++ =  c;
       return s;
    }

    % gcc -O3 -S -fno-builtin memset.c
    % cat memset.s

        memset:
    .LFB0:
        .cfi_startproc
        testl   %edx, %edx
        je      .L6
        subl    $1, %edx
        subq    $8, %rsp
        .cfi_def_cfa_offset 16
        movsbl  %sil, %esi
        addq    $1, %rdx
        call    memset
        addq    $8, %rsp
        .cfi_def_cfa_offset 8
        ret

  Note the infinite recursion.  Memset calls memset which calls memset
  and so on.  This is with an x86_64 compiler built from today's
  sources, but the problem exists for all targets.  The "-fno-builtin"
  is just to avoid the warning about the conflicting types of the memset
  function, but the "-O3" is necessary in order to make gcc detect the
  loop and decide to expand it via a library function.

  Now presumably the programmer knows that there is a library function
  called memset, but also presumably they have their own reasons for
  creating a memset function.  Perhaps they want to add some extra
  annotation or debugging.  It does not seem illegal though.  A program
  provided function should take precedence over a library provided one.

  Anyway it seems to me that gcc should not attempt to call a function
  called "memset" if it is compiling code inside a function called
  "memset".  The problem is, I cannot see an easy way of enforcing this.
  The memset builtin expander is called from several different places
  and I am not at all sure how, or if, they should be modified.  Any
  clues ?

Cheers
  Nick

Reply via email to