[Bug bootstrap/57087] New: make failed: libmpfr not found or uses a different ABI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57087 Bug #: 57087 Summary: make failed: libmpfr not found or uses a different ABI Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: extralevelinsoftw...@ntlworld.com Created attachment 29950 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29950 Notes on installation of gcc-4.7.2 The prerequisites.html states: "We appreciate bug reports about problems with newer versions" The details are in the attached file.
[Bug bootstrap/57087] make failed: libmpfr not found or uses a different ABI
orm (however ftp seems to operate the >same). > >6.2 An error reported by make > > Building failed as in section 4 above using: > >gmp-5.1.0 >mpfr-3.1.1 >mpc-1.0.1 > > Possibly this only concerns libmpfr, but it is not clear whether or >not the other two have proceeded correctly. > > It is also not clear whether this is a problem specific to my platform. > >6.3If extra information about the matters reported above would be of value >please contact: > ExtraLeveLInSoftware at ntlworld dot com > >Ellis N. Thomas/26-Apr-2013
[Bug bootstrap/57291] New: Failure in build stages 2 and 3 concerning pseudo-op: .balign
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57291 Bug ID: 57291 Summary: Failure in build stages 2 and 3 concerning pseudo-op: .balign Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: ExtraLeveLInSoftware at ntlworld dot com Failure in build stages 2 and 3 of gcc-4.7.2 To: gcc-bugs 1. Introduction Trying to build gcc-4.7.2. Running Mac OS X: System Version:Mac OS X 10.5.8 (9L30) Kernel Version:Darwin 9.8.0 >uname -mpv Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386 i386 This bug report concerns the following points. - An error reported by make in stage 2 - The same error reported by make in stage 3 2. Report from configure The existing compilation system for stage 1 was obtained as a ready built version of ada-4.3 in /usr/local/ada-4.3/bin/ (however, it reports that it is 4.4.0). bash> gcc --version gcc (GCC) 4.4.0 20080314 (experimental) [trunk revision 133226] Copyright (C) 2008 Free Software Foundation, Inc. Building in /Gnu/gcc/obj. Sources in /Gnu/gcc/src/gcc-4.7.2/. The configure command was ../src/gcc-4.7.2/gcc-4.7.2/configure --enable-languages=ada,c,c++ This completed OK. 3. An error reported by make in stage2 Ran make &> ../logs/make-4.log This redirects error stream too. The make failed, in stage2, last few lines of make-4.log: ../../src/gcc-4.7.2/libcpp/lex.c:463:Unknown pseudo-op: .balign ../../src/gcc-4.7.2/libcpp/lex.c:463:Rest of line ignored. 1st junk character valued 49 (1). make[3]: *** [lex.o] Error 1 make[2]: *** [all-stage2-libcpp] Error 2 make[1]: *** [stage2-bubble] Error 2 make: *** [all] Error 2 It seems that the first build using the older C and Ada compilers has completed OK, but the next bootstrap stage has failed. Help was sought from the gcc-help mailing list (see: 29 April 2013, Ongoing Error in make stage2 building gcc-4.7.2) Response on gcc-help from Ian Lance Taylor with suggestion for how to get round it: in libcpp/config.h "change HAVE_SSE4 to 0". The version of the assembler is a possible problem: as -v Apple Computer, Inc. version cctools-667.3~21, GNU assembler version 1.38 From its 'man' page: - The program /usr/bin/as is actually a driver that executes assemblers for specific target architectures. If no target architecture is speci- fied, it defaults to the architecture of the host it is running on. ... -v Display the version of the assembler (both the Mac OS X version and the GNU version it is based on). - 4. An error reported by make in stage3 Modified libcpp/config.h to change HAVE_SSE4 to 0. Reran make. Failed as before (but without redoing most of stage 1). Last few lines: ../../src/gcc-4.7.2/libcpp/lex.c:463:Unknown pseudo-op: .balign etc as before ... Modified prev-libcpp/config.h as well - failed with the same last few lines. Confirmed the test at the point of failure. The test in lex.c affecting line 463 is "#ifdef HAVE_SSE4". Modified libcpp/config.h and prev-libcpp/config.h to change HAVE_SSE4 to undef. With this it completed stage 2, but failed in stage 3 with the same effect: ../../src/gcc-4.7.2/libcpp/lex.c:463:Unknown pseudo-op: .balign ../../src/gcc-4.7.2/libcpp/lex.c:463:Rest of line ignored. 1st junk character valued 49 (1). make[3]: *** [lex.o] Error 1 make[2]: *** [all-stage3-libcpp] Error 2 make[1]: *** [stage3-bubble] Error 2 make: *** [all] Error 2 So a new config.h needed to be changed. The libcpp now matched the prev-libcpp original: Files libcpp/config.h and prev-libcpp/config.orig.h are identical There are also stage1-libcpp, and so on now. Applied this change; completed stage3: Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs warning: gcc/cc1plus-checksum.o differs Comparison successful. 5. Information from the gcc-help mailing list On 29 Apr 2013, at 16:07, Ian Lance Taylor wrote: I would describe this as a bug in libcpp, introduced here: 2010-08-21 Richard Henderson Andi Kleen David S. Miller * configure.ac (AC_C_BIGENDIAN, AC_TYPE_UINTPTR_T): New tests. (ssize_t): Check via AC_TYPE_SSIZE_T instead of AC_CHECK_TYPE. (ptrdiff_t): Check via AC_CHECK_TYPE. * config.in, configure: Rebuild. * system.h: Include stdint.h, if available. * lex.c (WORDS_BIGENDIAN): Provide default. (acc_char_mask_misalign, acc_char_replicate, acc_char_cmp, acc_char_index, search_line_acc_char, repl_chars, search_line_mmx, search_line_sse2, search_line_sse42, init_vectorized_lexer, search_line_fast): New.
[Bug bootstrap/57292] New: Failure in build after stage 3, concerning libitm.la
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57292 Bug ID: 57292 Summary: Failure in build after stage 3, concerning libitm.la Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: ExtraLeveLInSoftware at ntlworld dot com Failure in build after stage 3 of gcc-4.7.2 To: gcc-bugs 1. Introduction Trying to build gcc-4.7.2. Running Mac OS X: System Version:Mac OS X 10.5.8 (9L30) Kernel Version:Darwin 9.8.0 >uname -mpv Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386 i386 This bug report concerns the following point. - An error reported by make after stage 3, concerning libitm.la 2. Report from configure The existing compilation system for stage 1 was obtained as a ready built version of ada-4.3 in /usr/local/ada-4.3/bin/ (however, it reports that it is 4.4.0) bash> gcc --version gcc (GCC) 4.4.0 20080314 (experimental) [trunk revision 133226] Copyright (C) 2008 Free Software Foundation, Inc. Building in /Gnu/gcc/obj. Sources in /Gnu/gcc/src/gcc-4.7.2/. The configure command was ../src/gcc-4.7.2/gcc-4.7.2/configure --enable-languages=ada,c,c++ This completed OK. 3. An error reported by make Ran make &> ../logs/make-8.log The make failed, with last few messages described below. The build has passed stage 3, but failed later. Completed stage3, got to "Comparing stages 2 and 3", gave: Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs warning: gcc/cc1plus-checksum.o differs Comparison successful. It continued after this, but gave final error: ld: warning in ../../../src/gcc-4.7.2/libitm/clearcap.map, file is not of required architecture ld: pointer in read-only segment not allowed in slidable image, used in _del_opvnt from .libs/alloc_cpp.o collect2: error: ld returned 1 exit status make[4]: *** [libitm.la] Error 1 make[3]: *** [all-recursive] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-target-libitm] Error 2 make: *** [all] Error 2 The current situation seems to be that I have built the entire stage 3, but that the step "Build runtime libraries using the stage3 compiler from the previous step." has failed. 4. Information from the gcc-help mailing list Help was sought from the gcc-help mailing list (see: 13 May 2013 , Re: Ongoing Error in make stage2 building gcc-4.7.2) On 13 May 2013, at 14:43, Ian Lance Taylor wrote: It looks like the code is trying to use a linker map, which is not going to work with the Darwin linker. This looks like a bug in the libitm configury. I don't see it in the current bug database; please consider filing a bug report. On 13 May 2013, at 15:43, Richard Henderson wrote: That linker map is for Solaris. I have no idea how that might have come to be used for Darwin. r~ 5. Other related Information In order to complete the stages 2 and 3 builds, it was necessary to modify libcpp/config.h in both stages 2 and 3 to circumvent a problem in libcpp/lex.c with "Unknown pseudo-op: .balign". (Subject of a separate bug report, 57291.) This is not believed to be connected, but is stated just in case. 6. Summary of Bug 6.1 Error in ld Following stage three, presumably in the step "Build runtime libraries using the stage3 compiler from the previous step.", make has failed with make[4]: *** [libitm.la] Error 1 See also extra messages above. 6.2 If extra information about the matters reported above would be of value please contact: ExtraLeveLInSoftware at ntlworld dot com Ellis N. Thomas/15-May-2013
[Bug testsuite/57606] New: Failure in testing stage 3 of gcc-4.7.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57606 Bug ID: 57606 Summary: Failure in testing stage 3 of gcc-4.7.2 Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: ExtraLeveLInSoftware at ntlworld dot com 1 Introduction Trying to test recently built gcc-4.7.2. Running Mac OS X: System Version:Mac OS X 10.5.8 (9L30) Kernel Version:Darwin 9.8.0 >uname -mpv Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386 i386 This bug report concerns the following point. - An error reported by make testing stage 3, concerning ada acats Background information about the state of the build is given. Further information about the reason for the failure had been determined, with the effect of circumventing the problem. See also "Summary of Bug" below for the actual reason for the problem. 2 Report from configure etc. The existing compilation system for stage 1 was obtained as a ready built version of ada-4.3 in /usr/local/ada-4.3/bin/ (however, it reports that it is 4.4.0) bash> gcc --version gcc (GCC) 4.4.0 20080314 (experimental) [trunk revision 133226] Copyright (C) 2008 Free Software Foundation, Inc. Building in /Gnu/gcc/obj. Sources in /Gnu/gcc/src/gcc-4.7.2/. The configure command was ../src/gcc-4.7.2/gcc-4.7.2/configure --enable-languages=ada,c,c++ This completed OK. 3 An error reported by make check Ran in /Gnu/gcc/obj/: make -k check &> ../logs/makechk-1.log The make check failed, with messages described below. First few lines of makechk-1log: autogen -T ../../src/gcc-4.7.2/fixincludes/check.tpl ../../src/gcc-4.7.2/fixincludes/inclhack.def make[2]: autogen: Command not found make[2]: *** [check] Error 127 make[1]: *** [check-fixincludes] Error 2 Last few lines of makechk-1log: make[3]: Target `check-am' not remade because of errors. make[2]: *** [check-recursive] Error 1 make[2]: Target `check' not remade because of errors. make[1]: *** [check-target-libitm] Error 2 make[1]: Target `check-target' not remade because of errors. make: *** [do-check] Error 2 make: Target `check' not remade because of errors. The log has quite a lot of Errors, but there are many passes in various sections. As suggested, many failures involve libitm (see Information about the build state below). === libitm Summary === # of expected passes1 # of unexpected failures14 # of unresolved testcases14 # of unsupported tests1 In the gnat tests, the summary has: # of expected passes1109 # of expected failures14 # of unsupported tests4 But in the ada acats.log there are many messages: i686-apple-darwin9-gcc-4.0.1: language ada not recognized and nothing was compiled. Final message: Failed to compile macrosub this was also in the .sum file. The makechk-1.log for acats has: === acats support === Generating support files...fatal error, run-time library not installed correctly cannot locate file system.ads gnatmake: *** make failed. Failed to compile macrosub Note that "gcc version 4.0.1 (Apple Inc. build 5465)" is /usr/bin/gcc (which does not support Ada). These tests are supposed to be using the just built stage 3 compiler. Thus the Ada acats testing has been totally omitted. The "Installing GCC" information indicates the need for Prerequisites: "In order to build the Ada compiler (GNAT) you must already have GNAT installed because portions of the Ada frontend are written in Ada". However, there is nothing to say that an existing Ada compiler is also needed for testing. Consequently, although /usr/local/ada-4.3/bin/ was made available in the PATH used at build time, it was not added for testing. It was assumed that testing the as yet uninstalled compilation system would be self-contained. 4 Information about the build state 4.1The build has passed stage 3, but failed later. Completed stage3, got to "Comparing stages 2 and 3", gave: Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs warning: gcc/cc1plus-checksum.o differs Comparison successful. It continued after this, but gave final error: ld: warning in ../../../src/gcc-4.7.2/libitm/clearcap.map, file is not of required architecture ld: pointer in read-only segment not allowed in slidable image, used in _del_opvnt from .libs/alloc_cpp.o collect2: error: ld returned 1 exit status make[4]: *** [libitm.la] Error 1 make[3]: *** [all-recursive] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-target-libitm] Error 2 make: *** [all] Error 2 The current situation seems to be that I have built the entire stage 3, but that the step "Build runtime lib
[Bug testsuite/57606] Failure in testing stage 3 of gcc-4.7.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57606 --- Comment #1 from Ellis N. Thomas --- On further consideration of the Bug 57606 reported for host_gnatmake and host_gnatchop produced in run_acats, the entire approach seems flawed. It uses dirname to extract the directory name from the full name obtained from "type -p" to prefix a directory name to PATH for each of host_gnatmake and host_gnatchop. Since the details obtained for gnatmake (and gnatchop) are already what the shell would use, there seems little point in forcing this directory name to the head of PATH, or even to use the easier approach of simply executing the full name just returned by "type -p". Of course, gnatmake will lead to calls of other tools, which might be influenced by the adapted PATH, but if control is needed over which version(s) are called then greater care needs to be taken anyway. Ellis N. Thomas
[Bug bootstrap/57292] Failure in build after stage 3, concerning libitm.la
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57292 --- Comment #1 from Ellis N. Thomas --- It also failed during installation with errors for libitm.la, equivalent to the failures during build runtime libraries: bash> make install &> ../logs/makeinst-1.log Log file ended with: ld: warning in ../../../src/gcc-4.7.2/libitm/clearcap.map, file is not of required architecture ld: pointer in read-only segment not allowed in slidable image, used in _del_opvnt from .libs/alloc_cpp.o collect2: error: ld returned 1 exit status make[3]: *** [libitm.la] Error 1 make[2]: *** [install-recursive] Error 1 make[1]: *** [install-target-libitm] Error 2 make: *** [install] Error 2 Ellis N. Thomas/20-Jun-2013
[Bug other/57659] New: Failure in installing documentation of gcc-4.7.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57659 Bug ID: 57659 Summary: Failure in installing documentation of gcc-4.7.2 Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: ExtraLeveLInSoftware at ntlworld dot com Failure in installing documentation of gcc-4.7.2 To: gcc-bugs 1 Introduction Trying to install documentation for recently built gcc-4.7.2. Running Mac OS X: System Version:Mac OS X 10.5.8 (9L30) Kernel Version:Darwin 9.8.0 >uname -mpv Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386 i386 This bug report concerns the following point. - The generated HTML has broken links - no pages for gnat_rm have been made 2 Report from configure etc. Building in /Gnu/gcc/obj. Sources in /Gnu/gcc/src/gcc-4.7.2/. The configure command was ../src/gcc-4.7.2/gcc-4.7.2/configure --enable-languages=ada,c,c++ This completed OK. 3 Missing Items in the generated HTML The "Installing GCC: Final installation" page states: "If you would like to generate online HTML documentation, do ‘cd objdir; make html’ and HTML will be generated for the gcc manuals in objdir/gcc/HTML." Ran in /Gnu/gcc/obj/: make html &> ../logs/makehtml-1.log Has placed many files in objdir/gcc/HTML, but the reference to gnat_rm is missing. The log included: Doing html in gnattools make[2]: Nothing to be done for `html'. From the index page, following "2 Language Standards Supported by GCC" leads to file objdir/gcc/HTML/gcc-4.7.2/gcc/Standards.html. Here under "2.5 References for other languages" it says: "See GNAT Reference Manual, for information on standard conformance and compatibility of the Ada compiler." This line includes a link "GNAT Reference Manual" The Safari browser says: "No file exists at the address '/Gnu/gcc/obj/gcc/HTML/gcc-4.7.2/gnat_rm/index.html'." In fact there is no gnat_rm directory bash> ls gcc/HTML/gcc-4.7.2 cpp cppinternalsgcc gccinstall gccint Similar links are missing from the same paragraph for Fortran and Java, but perhaps this is expected since these were omitted from the build. Since Ada was included, it would be expected to have its documentation available: bash> gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/gcc-4.7.2/bin/../libexec/gcc/i386-apple-darwin9.8.0/4.7.2/lto-wrapper Target: i386-apple-darwin9.8.0 Configured with: ../src/gcc-4.7.2/configure --enable-languages=ada,c,c++ Thread model: posix gcc version 4.7.2 (GCC) It has not been checked whether there are any other broken links. 4 Information about the build state The build has passed stage 3, but failed later. Installation has been completed, though similar errors arose. The following bugs were reported during this build. Bug 57291 - Failure in build stages 2 and 3 concerning pseudo-op: .balign Bug 57292 - Failure in build after stage 3, concerning libitm.la Bug 57606 - Failure in testing stage 3 of gcc-4.7.2 These are not believed to be connected, but is stated just in case. 6 Summary of Bugs 6.1 Missing Items in the generated HTML -there is no gnat_rm directory in objdir/gcc/HTML/gcc-4.7.2 6.2 Extra Information If extra information about the matters reported above would be of value please contact: ExtraLeveLInSoftware at ntlworld dot com Ellis N. Thomas/20-Jun-2013
[Bug other/57659] Failure in installing documentation of gcc-4.7.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57659 --- Comment #2 from Ellis N. Thomas --- Oops...re-used a previous report as a template! Pls take (sub)sections 6 as 5. (In reply to Jonathan Wakely from comment #1) > (In reply to Ellis N. Thomas from comment #0) > > 4 Information about the build state > [...] > > 6 Summary of Bugs > > What happened to chapter 5? :) > > > 6.2 Extra Information > > > > If extra information about the matters reported above would be of value > > please contact: > > > > ExtraLeveLInSoftware at ntlworld dot com > > If someone needs more info I think you can assume they'll ask for it, but > they'll post responses to Bugzilla, and as the bug reporter you'll > automatically get an email, so there's no need to give your contact details.
[Bug ada/58128] New: Problem using NAME (STANDARD_INPUT) in gcc-4.7.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58128
Bug ID: 58128
Summary: Problem using NAME (STANDARD_INPUT) in gcc-4.7.2
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: ExtraLeveLInSoftware at ntlworld dot com
Created attachment 30634
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30634&action=edit
Two similar Ada main programs demonstrating the error (see main Description)
Problem using NAME (STANDARD_INPUT) in gcc-4.7.2
To: gcc-bugs
1 Compilation Environment
Using recently built gcc-4.7.2.
Report from configure etc.
bash> config.guess
i386-apple-darwin9.8.0
bash> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-4.7.2/usr/local/bin/../libexec/gcc/i386-apple-darwin9.8.0/4.7.2/lto-wrapper
Target: i386-apple-darwin9.8.0
Configured with: ../src/gcc-4.7.2/configure --enable-languages=ada,c,c++
Thread model: posix
gcc version 4.7.2 (GCC)
Running Mac OS X:
System Version:Mac OS X 10.5.8 (9L30)
Kernel Version:Darwin 9.8.0
bash> uname -mpv
Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009;
root:xnu-1228.15.4~1/RELEASE_I386 i386 i386
Command used to compile at first:
bash> gnatmake TryStdIP.ada
Which responded with:
gcc -c -x ada trystdip.ada
gnatbind -x trystdip.ali
gnatlink trystdip.ali
and completed the build.
Command used to recompile later with debugging:
bash> gnatmake -g TryStdIP.ada
Which responded with:
gcc -c -g -x ada trystdip.ada
gnatbind -x trystdip.ali
gnatlink trystdip.ali -g
and completed the build.
See also section 7 below about use of an older gnat.
2 Problem Encountered
When trystdip is executed, it prints the first few lines of text,
including the date and time as expected:
bash> trystdip
TryStdIP from SiRiL Issue 0.22 21-Apr-1989
Copyright (c) 2013 E.N. Thomas
Started at : 20:30:52 10/ 8/13
Then fails with:
raised PROGRAM_ERROR : unhandled signal
This gave no indication of where in the source the exception was
raised.
The source was recompiled with the debug option, and run using gdb.
This gave the following result:
(gdb) run
Starting program: /Users/ellisnthomas/RingProgs/GnatBugs/trystdip
Reading symbols for shared libraries ++. done
TryStdIP from SiRiL Issue 0.22 21-Apr-1989
Copyright (c) 2013 E.N. Thomas
Started at : 20:37:11 10/ 8/13
Program received signal SIGABRT, Aborted.
0x964c1d52 in __kill ()
(gdb) backtrace
#0 0x964c1d52 in __kill ()
#1 0x964c1d44 in kill$UNIX2003 ()
#2 0x96534242 in raise ()
#3 0x96540681 in abort ()
#4 0x931aea2a in _Unwind_Resume ()
#5 0x00016803 in system__file_io__open (file_ptr=0x0, dummy_fcb=@0xb484,
mode=system__file_control_block__in_file, name={P_ARRAY = 0x3edf8, P_BOUNDS =
0x3edf0}, form={P_ARRAY = 0x250ad, P_BOUNDS = 0x25148}, amethod=84 'T',
creat=false, text=true, c_stream=0) at s-fileio.adb:741
#6 0xef90 in ada__text_io__open (file=0x0, mode=ada__text_io__in_file,
name=Cannot access memory at address 0x0
) at a-textio.adb:1195
#7 0x25f0 in main (argc=1, argv=3221222960, envp=3221222968) at
/Users/ellisnthomas/RingProgs/GnatBugs/b~trystdip.adb:266
#8 0x2046 in start ()
This still failed to give any indication of where in the Ada source
file this occurred, but cited a supplemental unit produced by the debug option:
b~trystdip.adb, where it calls Ada_Main_Program;
However, the only usage of Ada . Text_IO . OPEN is the one following the
call to PutDate.
From the trace it appears that the name parameter at the call to
ada__text_io__open has the problem "Cannot access memory at address 0x0".
The Ada source code at this point tries to pass the result of calling
NAME (STANDARD_INPUT) to the NAME parameter of Ada . Text_IO . OPEN.
3 Expected Behaviour
The procedure call to OPEN following the call to PutDate is enclosed in
a block with exception handlers for NAME_ERROR and USE_ERROR. The statement is
trying to establish whether or not a file can be opened to the existing
STANDARD_INPUT. If it is possible to open it, then no exception will have
occurred, and
SET_INPUT (CommandFile);
will be used. If it is not possible, then the exception handler will instead
use:
SET_INPUT(STANDARD_INPUT);
This relatively short Ada program reproduces an error found after
compiling an old (Ada83) program with gnat 4.7.2. More information is given
about this below.
4 About the Original Program
The error was first seen after resurrecting a program (SiRiL) that had
worked well with Ada83, compiled on a DEC VAX platform. It had been used with
the native host DEC Ada compiler, and with the XD-Ada cross compiler that I
worked on in 1989. Cross compiled code was run on a Motorola MC6800 platform
and possibly on a MIL-STD
[Bug ada/58128] Problem using NAME (STANDARD_INPUT) in gcc-4.7.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58128 --- Comment #1 from Ellis N. Thomas --- Created attachment 30654 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30654&action=edit Source code showing problem handling the exception (TryStdIP3) Further Ada source program, modified as described in the additional comment.
[Bug ada/58128] Problem using NAME (STANDARD_INPUT) in gcc-4.7.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58128 --- Comment #2 from Ellis N. Thomas --- Further Information about the Exception Added extra "others" handler for Unexpected exceptions to TryStdIP3. Compiled: bash> gnatmake TryStdIP3.ada gcc -c -x ada trystdip3.ada gnatbind -x trystdip3.ali gnatlink trystdip3.ali Ran: bash> trystdip3 TryStdIP3 from SiRiL Issue 0.22 21-Apr-1989 Copyright (c) 2013 E.N. Thomas Started at : 12:45:57 14/ 8/13 Try to get NAME (STANDARD_INPUT) Try to open CommandFile using: <*stdin> raised PROGRAM_ERROR : unhandled signal So the "others" handler has failed to handle this PROGRAM_ERROR! Although it is reported as an exception, it is not able to be handled in the normal Ada way, so this seriously compromises the ability to work around this error. Consequently, a work-round such as a new version of s-fileio.adb (system__file_io__open) and/or a-textio.adb (ada__text_io__open) would be appreciated. E.N. Thomas/14-Aug-2013
[Bug ada/58128] Problem using NAME (STANDARD_INPUT) in gcc-4.7.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58128 --- Comment #4 from Ellis N. Thomas --- The decision to close this without any action seems unjustified. The problem is being rejected on the basis that the handling of the exception is faulty in the older Darwin. However, the fundamental problem is that this exception should not have been raised by OPEN (as in the cited sections of the Ada RM). Some fix to the relevant IO software is needed. The reply also states that what worked for I/O on VMS decades ago is essentially irrelevant - but regardless of whether OPEN is going to support another file being opened to Standard Input, if it doesn't it must say so by raising Name_Error or Use_Error as appropriate. In fact from the software developer's point of view it is clearly an advantage to be able to support interactive tools (like interpreters) written in Ada, and the ability to manipulate Standard Input is part of this. However, this facility itself is not the issue here. ENT/15-Aug-2013
