From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9001 invoked by alias); 11 Aug 2013 19:33:43 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 8976 invoked by uid 48); 11 Aug 2013 19:33:40 -0000 From: "ExtraLeveLInSoftware at ntlworld dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug ada/58128] New: Problem using NAME (STANDARD_INPUT) in gcc-4.7.2 Date: Sun, 11 Aug 2013 19:33:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: ada X-Bugzilla-Version: 4.7.2 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ExtraLeveLInSoftware at ntlworld dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-08/txt/msg00606.txt.bz2 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=@0xbffff484, 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 0x0000ef90 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 0x000025f0 in main (argc=1, argv=3221222960, envp=3221222968) at /Users/ellisnthomas/RingProgs/GnatBugs/b~trystdip.adb:266 #8 0x00002046 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-1750A platform. In order to compile on gnat, minimal changes were made towards Ada95 usage, such as making use of: Ada . Text_IO and Ada . Characters . Latin_1 (More extensive modernisation has not yet been started.) The purpose of the section provoking the error is to enable a "nested" usage to be made of Standard Input, where a series of lines can be terminated using End of File (such as ^D). This is sort of similar to the effect of a sequence in Unix like: bash:502> cat > tmp/out line 1 line 2 bash:503> where ^D was used just before "bash:503>". The standard input to the shell is not terminated because an end of file is given to an interactive command it has invoked. It was written so as to cater for an Ada implementation that did not allow this to be done - the exception handler mentioned above achieving this. On machines that allowed another file to be opened from the same source as the existing standard input, it was then possible to process the End of File state, and Reset this new file to accept further input. This cannot be done for the default standard input (as it points out in the Ada RM A.10.3 Default Input, Output, and Error Files, under NOTES: "The standard input, standard output, and standard error files cannot be opened, closed, reset, or deleted, because the parameter File of the corresponding procedures has the mode in out.") The overall effect enabled an Ada program operating as an interactive command interpreter to support commands that accepted a stream of user input from a file, including from Standard Input. Such a stream would be terminated with the normal End of File as provided by the underlying operating system. After it was Reset a later command could again accept such a stream. The example compiled here reproduces the problem as a single main program (TryStdIP), depending only on predefined units. Parts of the original version have been retained, but much has been stripped out. Minor changes have been made to the modified source to ensure it is able to be compiled. The resulting "main loop" of the program is valid Ada but no longer makes sense if executed! But anyway this has not been reached at the point of failure. 5 The Ada Reference Manual Requirements The extracts cited here are from the Ada Reference Manual at: http://www.adaic.org/resources/add_content/standards/05rm/html/RM-TTL.html The Ada RM says (under A.8.2 File Management): "function Name(File : in File_Type) return String; Returns a string which uniquely identifies the external file currently associated with the given file (and may thus be used in an Open operation). The exception Status_Error is propagated if the given file is not open. The exception Use_Error is propagated if the associated external file is a temporary file that cannot be opened by any name." For OPEN, the Ada RM says (under A.8.2 File Management): "The exception Status_Error is propagated if the given file is already open. The exception Name_Error is propagated if the string given as Name does not allow the identification of an external file; in particular, this exception is propagated if no external file with the given name exists. The exception Use_Error is propagated if, for the specified mode, the external environment does not support opening for an external file with the given name (in the absence of Name_Error) and form." At the end of A.8.2 File Management the Ada RM says: "Implementation Permissions An implementation may propagate Name_Error or Use_Error if an attempt is made to use an I/O feature that cannot be supported by the implementation due to limitations in the external environment. Any such restriction should be documented. " In A.10.3 Default Input, Output, and Error Files, the Ada RM suggests the possibility of opening different file objects on the same external file. Under NOTES it says: "The standard input, standard output, and standard error files are different file objects, but not necessarily different external files." It is thus clear that the result of Name may always be used in an Open operation. From these various sections, it is clear that the code has allowed for NAME_ERROR and USE_ERROR, and would expect any occurrence of Status_Error to be propagated. So in all cases a suitable SET_INPUT should be done (as described above), with the program continuing. 6 Further Investigation A trial was made with the calls to OPEN and NAME (STANDARD_INPUT) separated in a modified version, TryStdIP2.ada. Trace calls were also added to indicate progress, and display the result of NAME (STANDARD_INPUT). Compiled: bash:504> gnatmake TryStdIP2.ada gcc -c -x ada trystdip2.ada gnatbind -x trystdip2.ali gnatlink trystdip2.ali Tried running: bash:505> trystdip2 TryStdIP2 from SiRiL Issue 0.22 21-Apr-1989 Copyright (c) 2013 E.N. Thomas Started at : 20:22:13 10/ 8/13 Try to get NAME (STANDARD_INPUT) Try to open CommandFile using: <*stdin> raised PROGRAM_ERROR : unhandled signal So this reports a plausible value for NAME (STANDARD_INPUT), but crashes the same way when this is used for OPEN. 7 Behaviour using an older gnat On this system there is also an older gnat, downloaded as a disc image from: http://macada.org/macada/Downloads.html Gnati386-4.3-xcode3.0.dmg Although this claimed to be version 4.3, it reports: bash> gcc -v Using built-in specs. Target: i686-apple-darwin9 Configured with: /Volumes/FireLite/Shared/Developer/Compiler/gcc-head/configure --disable-checking --enable-static --prefix=/usr/local/ada-4.3 --with-arch=nocona --with-tune=generic --host=i686-apple-darwin9 --target=i686-apple-darwin9 --build=i686-apple-darwin9 --enable-languages=c,ada,c++,objc,obj-c++,fortran Thread model: posix gcc version 4.4.0 20080314 (experimental) [trunk revision 133226] (GCC) Tried this: bash> gnatmake TryStdIP.ada gcc -c -x ada TryStdIP.ada TryStdIP.ada:11:11: warning: file name does not match unit name, should be "Trystdip.ada" gnatbind -x TryStdIP.ali gnatlink TryStdIP.ali bash:512> TryStdIP TryStdIP from SiRiL Issue 0.22 21-Apr-1989 Copyright (c) 2013 E.N. Thomas Started at : 21:32:36 9/ 8/13 Command File not opened TryStdIP> This shows that the same bug does not occur, and the message: "Command File not opened" shows that an exception was handled. So the attempt to open another file to Standard Input failed. Which is a pity, as it worked on the VAX all those years ago. 8 Conclusion The simplified program built using gnat 4.7.2 fails, but using 4.3 (4.4?) it runs OK. The debugger shows that it failed in the predefined IO code. The Ada file provided contains both versions (TryStdIP.ada and TryStdIP2.ada) mentioned above. Only one is needed at any time to demonstrate the problem. As identified above, the source is valid according to the ADA RM extracts. The experience using gnat 4.3 (4.4?) suggests that the ability to open another file to the same place as standard input might not be supported when the present error is eliminated. Although the ability to open such a file might not be supported by a given Ada implementation, it is quite desirable that it should be (for reasons, see above). Consequently, any 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 ideally support opening such an extra file. E.N. Thomas/11-Aug-2013