This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug target/63261] New: Microblaze 4.9.1, Error: PC relative branch to label <foo> which is not in the instruction space


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

            Bug ID: 63261
           Summary: Microblaze 4.9.1, Error: PC relative branch to label
                    <foo> which is not in the instruction space
           Product: gcc
           Version: 4.9.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: thomas.petazzoni@free-electrons.com

When building the fxload program (see
http://sourceforge.net/projects/linux-hotplug/files/fxload/2008_10_13/) with
gcc 4.9.1, binutils 2.24, on the Microblaze EL architecture, the build fails
with:

/home/buildroot/instance-1/output/host/usr/bin/microblazeel-buildroot-linux-gnu-gcc
-c -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -pipe -Os
-g2  main.c -o main.o
{standard input}: Assembler messages:
{standard input}: Error: PC relative branch to label logerror which is not in
the instruction space
{standard input}: Error: PC relative branch to label logerror which is not in
the instruction space
{standard input}: Error: PC relative branch to label logerror which is not in
the instruction space
{standard input}: Error: PC relative branch to label logerror which is not in
the instruction space
{standard input}: Error: PC relative branch to label logerror which is not in
the instruction space
{standard input}: Error: PC relative branch to label logerror which is not in
the instruction space
{standard input}: Error: PC relative branch to label logerror which is not in
the instruction space
make[1]: *** [main.o] Error 1
make[1]: *** Waiting for unfinished jobs....
{standard input}: Assembler messages:
{standard input}:6463: Error: operation combines symbols in different segments
{standard input}:6464: Error: operation combines symbols in different segments
{standard input}:6467: Error: operation combines symbols in different segments
{standard input}:6468: Error: operation combines symbols in different segments
{standard input}:6477: Error: operation combines symbols in different segments
{standard input}:6478: Error: operation combines symbols in different segments
{standard input}:6481: Error: operation combines symbols in different segments
{standard input}:6482: Error: operation combines symbols in different segments
{standard input}:6488: Error: operation combines symbols in different segments
{standard input}:6489: Error: operation combines symbols in different segments
{standard input}:6492: Error: operation combines symbols in different segments
{standard input}:6493: Error: operation combines symbols in different segments
{standard input}:6502: Error: operation combines symbols in different segments
{standard input}:6503: Error: operation combines symbols in different segments
{standard input}:6509: Error: operation combines symbols in different segments
make[1]: *** [ezusb.o] Error 1

The logerror() function does not seem to have anything really special. It is
defined in main.c:

void logerror(const char *format, ...)
    __attribute__ ((format (__printf__, 1, 2)));

void logerror(const char *format, ...)
{
    va_list ap;
    va_start(ap, format);

    if(dosyslog)
        vsyslog(LOG_ERR, format, ap);
    else
        vfprintf(stderr, format, ap);
    va_end(ap);
}

And used from both main.o and ezusb.o, with ezusb.c carrying this definition:

extern void logerror(const char *format, ...)
    __attribute__ ((format (printf, 1, 2)));

This bug was originally reported to binutils (see
https://sourceware.org/bugzilla/show_bug.cgi?id=17329 for all the details), but
the binutils developers said it's a gcc bug.

And indeed: the bug appears when building the program with -Os and -g or -O2
and -g, but not if building with just -Os, -O2 or -g. It's the combination of
an optimization flag *and* -g that causes the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]