Summary: | [4.0/4.1 Regression] m32r-elf-as, m32r-linux-as debug relocation error for c++ | ||
---|---|---|---|
Product: | gcc | Reporter: | inaoka.kazuhiro |
Component: | target | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | RESOLVED WONTFIX | ||
Severity: | minor | CC: | gcc-bugs, hp |
Priority: | P3 | Keywords: | wrong-code, wrong-debug |
Version: | 4.0.0 | ||
Target Milestone: | 4.1.0 | ||
Host: | m32r | Target: | m32r |
Build: | Known to work: | ||
Known to fail: | Last reconfirmed: | 2005-06-12 15:05:57 |
Description
inaoka.kazuhiro
2004-10-27 04:34:56 UTC
What version of binutils are you using? (In reply to comment #1) > What version of binutils are you using? GNU assembler version 2.15.94 (m32r-elf) using BFD version 2.15.94 20041022 *** Bug 18355 has been marked as a duplicate of this bug. *** Confirmed via the dup bug. These seems like they are caused by comdat support. Subject: Bug 18170 CVSROOT: /cvs/gcc Module name: gcc Changes by: tobi@gcc.gnu.org 2004-12-02 19:39:15 Modified files: libgfortran : ChangeLog libgfortran/io : transfer.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gfortran.dg: direct_io_3.f90 Log message: libgfortran/ PR fortran/18710 * io/transfer.c (unformatted_read, unformatted_write): width of a COMPLEX is twice its kind. gcc/testsuite/ PR fortran/18170 * gfortran.dg/direct_io_3.f90: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&r1=1.124&r2=1.125 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/transfer.c.diff?cvsroot=gcc&r1=1.17&r2=1.18 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4708&r2=1.4709 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/direct_io_3.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1 That commit is unrelated to this bug, I had mistyped the PR number. Sorry. Does this work now or is still broken? Also could you attach a preprocessed source and the failing assembly? It still happened with "Sat Dec 11 18:22:23 GMT 2004". I don't think preprocessed code or assembly code is of much interest, as this is all quite visible with a combined tree build, as per simtest-howto.html. My last successful build of this port was with "Wed Apr 21 08:31:07 GMT 2004". Perhaps time to call on the maintainer? Ports left broken for a long time should be obsoleted. This is even more minor now since m32r was switched over to using dwarf2 debugging. m32r is not a primary or secondary target; removing target milestone. What should we do with this bug? If m32r is no longer affected, then what is? Maybe suspend this one or close it as WONTFIX? m32r is no longer affected. |