[Bug bootstrap/30974] New: pdp11-dec-bsd will not successfully build
I have an x86 NetBSD box and am attempting to build gcc for pdp11-dec-bsd. I
have binutils 2.17 installed and configured for that target, and I have
includes and libraries from the latest revision of 2.11BSD.
configure is run as
../configure --target=pdp11-dec-bsd --enable-languages=c --with-gmp=/usr/pkg
Building gets to this point:
/usr/src/gcc/vax/./gcc/xgcc -B/usr/src/gcc/vax/./gcc/
-B/usr/local/pdp11-dec-bsd/bin/ -B/usr/local/pdp11-dec-bsd/lib/ -isystem
/usr/local/pdp11-dec-bsd/include -isystem /usr/local/pdp11-dec-bsd/sys-include
-O2 -g -O2 -msoft-float -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -isystem ./include -O2 -mfloat32 -g -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../.././gcc
-I../../../../libgcc -I../../../../libgcc/. -I../../../../libgcc/../gcc
-I../../../../libgcc/../include -I../../../../libgcc/../libdecnumber
-I../../../libdecnumber -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep
-DL_muldi3 -c ../../../../libgcc/../gcc/libgcc2.c \
cc1: warning: target system does not support debug output
cc1: warning: target system does not support debug output
cc1: warning: target system does not support debug output
/var/tmp//ccSoMtqq.s: Assembler messages:
/var/tmp//ccSoMtqq.s:323: Error: junk at end of line, first unrecognized
character is `0'
/var/tmp//ccSoMtqq.s:324: Error: junk at end of line, first unrecognized
character is `0'
/var/tmp//ccSoMtqq.s:325: Error: junk at end of line, first unrecognized
character is `0'
/var/tmp//ccSoMtqq.s:326: Error: junk at end of line, first unrecognized
character is `0'
/var/tmp//ccSoMtqq.s:329: Error: junk at end of line, first unrecognized
character is `0'
/var/tmp//ccSoMtqq.s:330: Error: junk at end of line, first unrecognized
character is `0'
gmake[4]: *** [_muldi3.o] Error 1
The mis-generated assembly is at the very end of the file, and looks like this:
LC_0:
0 /* short */
0 /* short */
0 /* short */
0 /* short */
.even
LC_1:
0 /* short */
0 /* short */
Unfortunately I have not the faintest clue as to what is happening here, or
why. I would be happy to provide more details if someone can tell me what they
need.
--
Summary: pdp11-dec-bsd will not successfully build
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hbent at cs dot oberlin dot edu
GCC build triplet: i386-unknown-netbsdelf4.99.9
GCC host triplet: i386-unknown-netbsdelf4.99.9
GCC target triplet: pdp11-dec-bsd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30974
[Bug target/30974] pdp11-dec-bsd will not successfully build
--- Comment #3 from hbent at cs dot oberlin dot edu 2007-02-26 21:38 --- I'm not clear on what you're saying. Is binutils not going to work at all for this target? It can't be built natively AFAIK, so I'm not sure what toolchain I should be using if binutils isn't going to work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30974
[Bug fortran/37643] New: fortran doesn't build on 4.4.0 for vax
When cross-compiling for vax--netbsdelf, fortran doesn't build. I have a
NetBSD/vax 4.99.72 install symlinked, and am using binutils 2.19.50.20080923.
gcc sources are subversion rev 140638. It gets to here and stops:
libtool: compile: /usr/src/gcc/vax/./gcc/xgcc -B/usr/src/gcc/vax/./gcc/
-B/usr/local/vax--netbsdelf/bin/ -B/usr/local/vax--netbsdelf/lib/ -isystem
/usr/local/vax--netbsdelf/include -isystem
/usr/local/vax--netbsdelf/sys-include -DHAVE_CONFIG_H -I.
-I../../../libgfortran -I. -iquote../../../libgfortran/io
-I../../../libgfortran/../gcc -I../../../libgfortran/../gcc/config
-I../.././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings
-fcx-fortran-rules -g -O2 -MT c99_functions.lo -MD -MP -MF
.deps/c99_functions.Tpo -c ../../../libgfortran/intrinsics/c99_functions.c -o
c99_functions.o
../../../libgfortran/intrinsics/c99_functions.c:539: warning: no previous
prototype for 'roundl'
../../../libgfortran/intrinsics/c99_functions.c:640: warning: no previous
prototype for 'lroundl'
../../../libgfortran/intrinsics/c99_functions.c:667: warning: no previous
prototype for 'llroundl'
../../../libgfortran/intrinsics/c99_functions.c:679: warning: no previous
prototype for 'log10l'
../../../libgfortran/intrinsics/c99_functions.c:717: warning: no previous
prototype for 'floorl'
../../../libgfortran/intrinsics/c99_functions.c:743: warning: no previous
prototype for 'fmodl'
../../../libgfortran/intrinsics/c99_functions.c: In function 'tgamma':
../../../libgfortran/intrinsics/c99_functions.c:1455: warning: floating
constant truncated to zero
../../../libgfortran/intrinsics/c99_functions.c:1457: warning: target format
does not support infinity
/var/tmp//ccY9ySD8.s: Assembler messages:
/var/tmp//ccY9ySD8.s:712: Fatal error: Junk at end of expression "QNaN"
Closer examination reveals that the line the assembler is choking on is:
movd $0d+QNaN,%r1
Fortran did build in the past on 4.4.0; I have a version dated 2008.04.10.
--
Summary: fortran doesn't build on 4.4.0 for vax
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hbent at cs dot oberlin dot edu
GCC build triplet: i386-unknown-netbsdelf4.99.72
GCC host triplet: i386-unknown-netbsdelf4.99.72
GCC target triplet: vax--netbsdelf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37643
[Bug c/37708] New: ICE: vector VEC(name_tree,base) index domain error, in loop_iv_stack_get_iv at graphite.c:123
aelfric% /usr/gcc/bin/gcc -v Using built-in specs. Target: i386-unknown-netbsdelf4.99.72 Configured with: ../configure --enable-threads --prefix=/usr/gcc --disable-nls --disable-version-specific-runtime-libs --enable-languages=c,c++,fortran,objc --with-gmp=/usr/pkg --with-ppl=/usr/local Thread model: posix gcc version 4.4.0 20081001 (experimental) (GCC) aelfric% /usr/gcc/bin/gcc -O1 -w -fstrict-overflow -floop-block -o heapsort-acovea.c heapsort-acovea.c: In function 'HSORT': heapsort-acovea.c:180: internal compiler error: vector VEC(name_tree,base) index domain error, in loop_iv_stack_get_iv at graphite.c:123 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. -- Summary: ICE: vector VEC(name_tree,base) index domain error, in loop_iv_stack_get_iv at graphite.c:123 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hbent at cs dot oberlin dot edu GCC build triplet: i386-unknown-netbsdelf4.99.72 GCC host triplet: i386-unknown-netbsdelf4.99.72 GCC target triplet: i386-unknown-netbsdelf4.99.72 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37708
[Bug c/37708] ICE: vector VEC(name_tree,base) index domain error, in loop_iv_stack_get_iv at graphite.c:123
--- Comment #1 from hbent at cs dot oberlin dot edu 2008-10-01 21:47 --- Created an attachment (id=16445) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16445&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37708
[Bug target/38182] stddef.h assumes machinee/ansi.h defines _ANSI_H_
--- Comment #2 from hbent at cs dot oberlin dot edu 2009-02-11 04:32 --- I am seeing this on NetBSD 5.99.7, and can confirm that this prevents gcc from building at all on NetBSD 5.99.x. Is there any way this can get into 4.4.0? It is a very simple fix and applies cleanly. -- hbent at cs dot oberlin dot edu changed: What|Removed |Added CC||hbent at cs dot oberlin dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38182
[Bug bootstrap/26015] New: ICE during bootstrap for vax architecture
Configure a current subversion copy of gcc with --target=vax--netbsdelf, do
"make bootstrap." Watch it fail during stage1 like so:
...
for d in libgcc; do \
if [ -d $d ]; then true; else /bin/sh ../../gcc/../mkinstalldirs $d; fi; \
done
mkdir libgcc
if [ -f stmp-dirs ]; then true; else touch stmp-dirs; fi
/usr/src/gcc/vax/./gcc/xgcc -B/usr/src/gcc/vax/./gcc/
-B/usr/local/vax--netbsdelf/bin/ -B/usr/local/vax--netbsdelf/lib/ -isystem
/usr/local/vax--netbsdelf/include -isystem
/usr/local/vax--netbsdelf/sys-include -O2 -O2 -g -O2 -DIN_GCC -DCROSS_COMPILE
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -isystem ./include -fPIC -g -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../gcc -I../../gcc/.
-I../../gcc/../include -I../../gcc/../libcpp/include -I/usr/pkg/include
-I../../gcc/../libdecnumber -I../libdecnumber -DL_muldi3 -c ../../gcc/libgcc2.c
-o libgcc/./_muldi3.o
../../gcc/libgcc2.c: In function '__muldi3':
../../gcc/libgcc2.c:520: internal compiler error: in
compute_frame_pointer_to_cfa_displacement, at dwarf2out.c:10443
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
--
Summary: ICE during bootstrap for vax architecture
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hbent at cs dot oberlin dot edu
GCC build triplet: i386-unknown-netbsdelf3.99.5
GCC host triplet: i386-unknown-netbsdelf3.99.5
GCC target triplet: vax--netbsdelf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26015
[Bug target/26015] ICE during bootstrap for vax architecture
--- Comment #2 from hbent at cs dot oberlin dot edu 2006-01-29 07:06 --- My mistake, I was doing two builds at once and got mixed up. This error was produced with configure as so: ../configure --target=vax--netbsdelf --disable-nls --enable-languages=c --disable-shared and then just a regular "gmake" to build. I have lib and include dirs symlinked from a NetBSD/vax 2.0 install. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26015
[Bug target/26015] [4.1/4.2/4.3 Regression] ICE during bootstrap for vax architecture
--- Comment #8 from hbent at cs dot oberlin dot edu 2006-11-07 04:25 --- This patch fixes the cross-compile such that it completes and is a valid compiler able to generate valid code. I cannot comment on any of the more "official" tests. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26015
