public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o
Date: Thu, 19 Jan 2012 16:32:00 -0000 [thread overview]
Message-ID: <bug-50237-4-O2eHvW2qvR@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-50237-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #39 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-19 16:17:29 UTC ---
(In reply to comment #38)
> So far, ld -e 0 doesn't work:
Well, if no Sun ld handles the section mixing right, it doesn't matter that
much. We could just:
.text
.globl _start
_start:
at the end of the assembly otherwise.
> (Recent?) Sun as on Solaris 10 and 11/x86 work, too.
It will still not default to --enable-initfini-array there, because of the
glibc version check. Does Solaris dynamic linker handle .init_array etc. right
(e.g. the old H.J.'s testcase from configure if compiled with GNU ld 2.22 or
later)? If yes, from which versions? Shall it be based on just target
tripplets for Solaris?
> On Solaris 11/SPARC, the test fails even with gas and gld 2.22:
>
> > objdump -s -j .init_array conftest
>
> conftest: file format elf32-sparc-sol2
>
> Contents of section .init_array:
> 20054 48484848 44444444 HHHHDDDD
If it contains just two, then possibly the .ctors section has been kept around?
I'd guess that H.J's testcase wouldn't succeed either.
Anyway, marking this as fixed, details can be fixed up incrementally.
next prev parent reply other threads:[~2012-01-19 16:19 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-30 13:26 [Bug bootstrap/50237] New: [4.7 regression] comparison failure caused by HAVE_INITFINI_ARRAY check ebotcazou at gcc dot gnu.org
2011-08-30 13:41 ` [Bug bootstrap/50237] " rguenth at gcc dot gnu.org
2011-08-30 13:50 ` rguenth at gcc dot gnu.org
2011-08-30 13:51 ` hjl.tools at gmail dot com
2011-08-30 13:58 ` ebotcazou at gcc dot gnu.org
2011-08-30 14:07 ` hjl.tools at gmail dot com
2011-08-30 14:23 ` rguenth at gcc dot gnu.org
2011-08-30 14:34 ` hjl.tools at gmail dot com
2011-08-30 15:30 ` ebotcazou at gcc dot gnu.org
2011-08-30 15:57 ` joseph at codesourcery dot com
2011-08-30 16:30 ` hjl.tools at gmail dot com
2011-08-30 16:36 ` hjl.tools at gmail dot com
2011-08-30 16:57 ` joseph at codesourcery dot com
2011-08-31 7:04 ` hjl.tools at gmail dot com
2011-08-31 15:46 ` joseph at codesourcery dot com
2011-08-31 15:47 ` hjl.tools at gmail dot com
2011-08-31 16:20 ` joseph at codesourcery dot com
2011-09-02 18:10 ` hjl.tools at gmail dot com
2011-09-03 9:32 ` [Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o ebotcazou at gcc dot gnu.org
2011-09-03 17:17 ` hjl.tools at gmail dot com
2011-09-10 15:03 ` hjl.tools at gmail dot com
2011-10-04 13:57 ` ro at gcc dot gnu.org
2011-11-22 17:59 ` ro at CeBiTec dot Uni-Bielefeld.DE
2011-11-22 18:03 ` hjl.tools at gmail dot com
2011-11-22 18:21 ` ro at CeBiTec dot Uni-Bielefeld.DE
2011-11-22 18:35 ` hjl.tools at gmail dot com
2011-11-23 16:30 ` ro at CeBiTec dot Uni-Bielefeld.DE
2011-11-23 16:52 ` hjl.tools at gmail dot com
2011-11-23 17:17 ` ro at CeBiTec dot Uni-Bielefeld.DE
2011-11-23 17:20 ` hjl.tools at gmail dot com
2011-11-24 18:07 ` ro at CeBiTec dot Uni-Bielefeld.DE
2011-11-28 15:20 ` jakub at gcc dot gnu.org
2011-11-28 16:03 ` ro at CeBiTec dot Uni-Bielefeld.DE
2011-12-01 20:26 ` ebotcazou at gcc dot gnu.org
2011-12-07 22:06 ` jakub at gcc dot gnu.org
2012-01-09 0:54 ` pinskia at gcc dot gnu.org
2012-01-09 14:31 ` rguenth at gcc dot gnu.org
2012-01-17 16:06 ` jakub at gcc dot gnu.org
2012-01-19 10:49 ` jakub at gcc dot gnu.org
2012-01-19 10:55 ` jakub at gcc dot gnu.org
2012-01-19 16:26 ` ro at CeBiTec dot Uni-Bielefeld.DE
2012-01-19 16:32 ` jakub at gcc dot gnu.org [this message]
2012-01-19 16:41 ` ro at CeBiTec dot Uni-Bielefeld.DE
2012-01-19 16:51 ` jakub at gcc dot gnu.org
2012-01-19 16:54 ` ro at CeBiTec dot Uni-Bielefeld.DE
2012-01-20 0:25 ` pinskia at gcc dot gnu.org
2012-02-22 22:10 ` jingyu at gcc dot gnu.org
2012-02-22 22:31 ` jingyu at gcc dot gnu.org
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-50237-4-O2eHvW2qvR@http.gcc.gnu.org/bugzilla/ \
--to=gcc-bugzilla@gcc.gnu.org \
--cc=gcc-bugs@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).