https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92499

            Bug ID: 92499
           Summary: nios2 backend needs to allocated object size, not C
                    object size for gprel optimization
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: fw at gcc dot gnu.org
  Target Milestone: ---
            Target: nios2-elf

Consider this test case:

enum { size = 100 };

struct flexible
{
  int length;
  int data[];
};

struct inflexible
{
  int length;
  int data[size];
};

static struct flexible flexible =
  {
   .data = { [size - 1] = 0, }
  };

static struct flexible flexible_nonzero =
  {
   .length = size
   .data = { [size - 1] = 0, }
  };

static struct inflexible inflexible =
  {
   .data = { [size - 1] = 0, }
  };

struct flexible *
get_flexible (void)
{
  return &flexible;
}

struct flexible *
get_flexible_nonzero (void)
{
  return &flexible_nonzero;
}

struct inflexible *
get_inflexible (void)
{
  return &inflexible;
}

GCC 10 generates this (with -O2):

        .section        .text
        .align  2
        .global get_flexible
        .type   get_flexible, @function
get_flexible:
        addi    r2, gp, %gprel(flexible)
        ret
        .size   get_flexible, .-get_flexible
        .align  2
        .global get_flexible_nonzero
        .type   get_flexible_nonzero, @function
get_flexible_nonzero:
        addi    r2, gp, %gprel(flexible_nonzero)
        ret
        .size   get_flexible_nonzero, .-get_flexible_nonzero
        .align  2
        .global get_inflexible
        .type   get_inflexible, @function
get_inflexible:
        movhi   r2, %hiadj(inflexible)
        addi    r2, r2, %lo(inflexible)
        ret
        .size   get_inflexible, .-get_inflexible
        .section        .bss
        .type   inflexible, @object
        .size   inflexible, 404
        .align  2
inflexible:
        .zero   404
        .section        .sdata,"aws"
        .align  2
        .type   flexible_nonzero, @object
        .size   flexible_nonzero, 404
flexible_nonzero:
        .long   100
        .zero   396
        .long   0
        .section        .bss
        .type   flexible, @object
        .size   flexible, 404
        .align  2
flexible:
        .zero   404
        .ident  "GCC: (GNU) 10.0.0 20191103 (experimental) [trunk revision
277751]"

All objects have the same size (404 bytes). My understanding is that they do
not qualify for the gprel optimization: %gprel relocations should not be used
to reference to them (i.e., get_flexible and getflexible_nonzero should look
like get_inflexible), and initialized objects (flexible_nonzero in the object)
should be put into .sdata, not .data.

The likely cause for this bug is that the backend looks at the equivalent of 
sizeof (flexible) to make the optimization decision, but this is 4 according to
the C language rules.

Joseph Myers reported this as a glibc build failure:

/scratch/jmyers/glibc/many9/install/compilers/nios2-linux-gnu/lib/gcc/nios2-glibc-linux-gnu/9.2.1/../../../../nios2-glibc-linux-gnu/bin/ld:
/scratch/jmyers/glibc/many9/build/glibcs/nios2-linux-gnu/glibc/libc.a(libc-tls.o):
in function `init_slotinfo':
/scratch/jmyers/glibc/many9/src/glibc/csu/../csu/libc-tls.c:72: warning: unable
to reach .bss (at 0xc5ea0) from the global pointer (at 0x8d890) because the
offset (230928) is out of the allowed range, -32678 to 32767

/scratch/jmyers/glibc/many9/install/compilers/nios2-linux-gnu/lib/gcc/nios2-glibc-linux-gnu/9.2.1/../../../../nios2-glibc-linux-gnu/bin/ld:
final link failed: nonrepresentable section on output
collect2: error: ld returned 1 exit status
../Rules:253: recipe for target
'/scratch/jmyers/glibc/many9/build/glibcs/nios2-linux-gnu/glibc/malloc/tst-interpose-static-nothread'
failed
make[3]: ***
[/scratch/jmyers/glibc/many9/build/glibcs/nios2-linux-gnu/glibc/malloc/tst-interpose-static-nothread]
Error 1

<https://sourceware.org/ml/libc-alpha/2019-11/msg00421.html>

Reply via email to