[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug ld/15057] New: gld creates SHT_PROGBITS .bss section
From: |
ro at TechFak dot Uni-Bielefeld.DE |
Subject: |
[Bug ld/15057] New: gld creates SHT_PROGBITS .bss section |
Date: |
Wed, 23 Jan 2013 13:53:49 +0000 |
http://sourceware.org/bugzilla/show_bug.cgi?id=15057
Bug #: 15057
Summary: gld creates SHT_PROGBITS .bss section
Product: binutils
Version: 2.23
Status: NEW
Severity: normal
Priority: P2
Component: ld
AssignedTo: address@hidden
ReportedBy: address@hidden
Classification: Unclassified
Host: sparc*-*-solaris2*
Target: sparc*-*-solaris2*
Build: sparc*-*-solaris2*
When bootstrapping gcc mainline on Solaris/SPARC (9, 10 or 11) with Sun as and
gld 2.23.1, several gfortran tests FAIL with
FAIL: gfortran.dg/coarray/alloc_comp_1.f90 -fcoarray=lib -O2 -lcaf_single
(test for excess errors)
Excess errors:
/vol/gcc/bin/gld-2.23.1: warning: section `.bss' type changed to PROGBITS
It turns out that alloc_comp_1.o has a SHT_NOBITS .bss section, while
libgfortran.so
has a SHT_PROGBITS one. This is strange, since all input files either have
no .bss section at all or a SHT_NOBITS one. I've no idea why gld creates it
this way. When using gas instead of Sun as, many more input objects do have
SHT_NOBITS .bss sections. There seems no easy way to trace why gld acts this
way, which makes the as/gld combo mostly useless on Solaris/SPARC. On
Solaris/x86,
where as creates similar objects (no .bss section), the problem doesn't exist.
Rainer
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
- [Bug ld/15057] New: gld creates SHT_PROGBITS .bss section,
ro at TechFak dot Uni-Bielefeld.DE <=