Bug 28183 - [4.0/4.1/4.2/4.3 regression] assembler error "FATAL: can't close x.o" on m68k with new binutils
Summary: [4.0/4.1/4.2/4.3 regression] assembler error "FATAL: can't close x.o" on m68k...
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.1.1
: P5 normal
Target Milestone: 4.0.4
Assignee: Not yet assigned to anyone
URL:
Keywords: wrong-code
Depends on:
Blocks:
 
Reported: 2006-06-27 21:17 UTC by Martin Michlmayr
Modified: 2007-01-31 18:27 UTC (History)
4 users (show)

See Also:
Host:
Target: m68k-linux-gnu
Build: m68k-linux-gnu
Known to work: 3.4.6
Known to fail: 4.0.4 4.1.1 4.2.0
Last reconfirmed:


Attachments
preprocessed source (97.90 KB, application/octet-stream)
2006-06-27 22:08 UTC, Martin Michlmayr
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Michlmayr 2006-06-27 21:17:14 UTC
[ forwarded from http://bugs.debian.org/375519 ]

We get the following assembler error when compiling the application cln.  The error goes away when you drop -fPIC or when you use gcc 3.4.  Additionally, the error does not show up with older releases of binutils.  While 2.16.91 20060413 produces the error, 2.16.91 20051117 works fine.

I'm not sure if this is a bug in binutils but given that gcc 3.4 works I'm filing it as a gcc bug.  Andreas, since you're also involved in binutils, I hope you know where to put the blame. ;-)

crest% g++-4.1 -fPIC -DPIC -c cl_MI.ii
crest% g++-4.1 -fPIC -DPIC -c -O2 cl_MI.ii
cl_MI.o: No error
/tmp/ccjCp4mS.s: Assembler messages:
/tmp/ccjCp4mS.s:18716: FATAL: can't close cl_MI.o
: No error
crest% g++-4.0 -fPIC -DPIC -c -O2 cl_MI.ii
cl_MI.o: No error
/tmp/ccreQBwI.s: Assembler messages:
/tmp/ccreQBwI.s:19590: FATAL: can't close cl_MI.o
: No error
crest% g++-3.4 -fPIC -DPIC -c -O2 cl_MI.ii
crest% as --version
GNU assembler 2.16.91 20060413 Debian GNU/Linux
Copyright 2005 Free Software Foundation, Inc.
Comment 1 Martin Michlmayr 2006-06-27 22:08:58 UTC
Created attachment 11766 [details]
preprocessed source
Comment 2 Martin Michlmayr 2006-06-27 22:21:22 UTC
What I said about binutils might be wrong.  It seems it's not due to a difference in the version, but due to one being native and one being cross.  I just upgraded the binutils-m68k on i386 to the same version as that on m68k native and strangely enough the same .s file works on i386 with m68k-as but fails on m68k:

native:
crest% as test.s
a.out: No error
test.s: Assembler messages:
test.s:18960: FATAL: can't close a.out
: No error
crest% as --version
GNU assembler 2.16.91 20060413 Debian GNU/Linux
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.
This assembler was configured for a target of `m68k-linux-gnu'.
crest%

i386:
1173:tbm@reyes: ~] /usr/local/bin/m68k-linux-gnu-as test.s
1174:tbm@reyes: ~] /usr/local/bin/m68k-linux-gnu-as --version
GNU assembler 2.16.91 20060413 Debian GNU/Linux
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.
This assembler was configured for a target of `m68k-linux-gnu'.
1175:tbm@reyes: ~]
Comment 3 Andrew Pinski 2006-06-28 11:15:41 UTC
(In reply to comment #2)
That would almost mean as is being miscompiled on m68k.
Comment 4 Andreas Schwab 2006-08-07 23:12:40 UTC
The removed comment says:

-  /* If will do cse, generate all results into pseudo registers
-     since 1) that allows cse to find more things
-     and 2) otherwise cse could produce an insn the machine
-     cannot support.  An exception is a CONSTRUCTOR into a multi-word
-     MEM: that's much more likely to be most efficient into the MEM.
-     Another is a CALL_EXPR which must return in memory.  */

So it looks like point 2 is true.
Comment 5 Andreas Schwab 2006-08-07 23:13:15 UTC
Sorry, wrong bug.
Comment 6 Roman Zippel 2007-01-31 18:20:34 UTC
This bug can be closed, it's really a bug in binutils triggered by some inline assembly in cln. Here is a bit more info:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=388000
Comment 7 Andrew Pinski 2007-01-31 18:27:25 UTC
Marking as invalid as requested.