User account creation filtered due to spam.

Bug 12116 - Large assembly output values with X-MAME code.
Summary: Large assembly output values with X-MAME code.
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 3.3.2
: P2 normal
Target Milestone: 3.3.2
Assignee: Eric Botcazou
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-08-31 14:14 UTC by Vasilis Vasaitis
Modified: 2005-07-23 22:49 UTC (History)
2 users (show)

See Also:
Host: k6-pc-linux-gnu
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
bzip2-compressed preprocessed output of -save-temps (22.10 KB, application/x-bzip2)
2003-08-31 14:16 UTC, Vasilis Vasaitis
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Vasilis Vasaitis 2003-08-31 14:14:08 UTC
Hello,

  When trying to compile various files of the X-MAME project with gcc 3.3.2
(latest prerelease in Debian sid) as well as older versions, I often got errors
similar to this:

superpac.s: Assembler messages:
superpac.s:384: Error: value of ffffffffffffff7f too large for field of 1 bytes 

  I've isolated one of these files, reduced the command line options needed to
cause the problem to a minimum, and the result follows:

$ gcc -v -save-temps -O2 -fomit-frame-pointer -funroll-loops -march=k6-2
-DINLINE= -Isrc -Isrc/unix -o xmame.obj/vidhrdw/superpac.o -c src/vidhrdw/superpac.c
Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.2/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib
--enable-nls --without-included-gettext --enable-__cxa_atexit
--enable-clocale=gnu --enable-debug --enable-java-gc=boehm
--enable-java-awt=xlib --enable-objc-gc i486-linux
Thread model: posix
gcc version 3.3.2 20030812 (Debian prerelease)
 /usr/lib/gcc-lib/i486-linux/3.3.2/cc1 -E -quiet -v -Isrc -Isrc/unix
-D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=2 -DINLINE=
src/vidhrdw/superpac.c -march=k6-2 -fomit-frame-pointer -funroll-loops -O2
superpac.i
ignoring nonexistent directory "/usr/i486-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 src
 src/unix
 /usr/local/include
 /usr/lib/gcc-lib/i486-linux/3.3.2/include
 /usr/include
End of search list.
 /usr/lib/gcc-lib/i486-linux/3.3.2/cc1 -fpreprocessed superpac.i -quiet
-dumpbase superpac.c -march=k6-2 -auxbase-strip xmame.obj/vidhrdw/superpac.o -O2
-version -fomit-frame-pointer -funroll-loops -o superpac.s
GNU C version 3.3.2 20030812 (Debian prerelease) (i486-linux)
	compiled by GNU C version 3.3.2 20030812 (Debian prerelease).
GGC heuristics: --param ggc-min-expand=81 --param ggc-min-heapsize=96871
 as -V -Qy -o xmame.obj/vidhrdw/superpac.o superpac.s
GNU assembler version 2.14.90.0.5 (i386-linux) using BFD version 2.14.90.0.5
20030722 Debian GNU/Linux
superpac.s: Assembler messages:
superpac.s:384: Error: value of ffffffffffffff7f too large for field of 1 bytes
at 00000000000004b3


  I'm attaching the preprocessed source code, you should be able to reproduce
the problem with "gcc -O2 -fomit-frame-pointer -funroll-loops -march=k6-2".

Thanks,
Vasilis
Comment 1 Vasilis Vasaitis 2003-08-31 14:16:35 UTC
Created attachment 4679 [details]
bzip2-compressed preprocessed output of -save-temps
Comment 2 Andrew Pinski 2003-09-01 03:36:06 UTC
This is almost definitely the same bug as PR 11689 because they are both targeting k6's and the 
error message is the same and that one has a reduced sources already.

*** This bug has been marked as a duplicate of 11689 ***
Comment 3 Eric Botcazou 2003-09-01 08:32:08 UTC
We can't be sure until the problem is fully debugged, because a bad estimation 
of the length of a single insn can trigger the error. I already fixed several 
similar PRs and they were not duplicate.

Andrew, please assign any similar PRs to me. Thanks in advance.
Comment 4 Eric Botcazou 2003-09-01 08:33:30 UTC
I will shortly be investigating.
Comment 5 Eric Botcazou 2003-09-08 06:49:37 UTC
Confirmed as a duplicate of PR target/11689.