From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28955 invoked by alias); 30 Dec 2002 06:13:05 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 28946 invoked from network); 30 Dec 2002 06:13:05 -0000 Received: from unknown (HELO duracef.shout.net) (204.253.184.12) by 209.249.29.67 with SMTP; 30 Dec 2002 06:13:05 -0000 Received: (from mec@localhost) by duracef.shout.net (8.11.6/8.11.6) id gBU6Cro28859 for gdb-patches@sources.redhat.com; Mon, 30 Dec 2002 00:12:53 -0600 Date: Mon, 30 Dec 2002 02:36:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200212300612.gBU6Cro28859@duracef.shout.net> To: gdb-patches@sources.redhat.com Subject: RFC: gdb.c++/main-falloff.exp (a new KFAIL) X-SW-Source: 2002-12/txt/msg00750.txt.bz2 This is an RFC for main-falloff.exp, a new test script with a single KFAIL. This script tests a C++ main() function which has return type int but does not return a value. I don't like it, but this is legal C++. I noticed this happening with anon-union.exp on 2002-12-18. anon-union.exp is exposing another gcc bug so I am writing a separate test just for the the fall-off-main behavior. I'd like to get comments on the KFAIL aspect. main-falloff.exp has just one useful test, which currently KFAIL's with gcc HEAD%20021224 -gdwarf-2. I have written the KFAIL code the way that I would like to use KFAIL. . Is this an acceptable way to use KFAIL? . Is this a good way to use KFAIL? . Should we ask/require everyone to do KFAIL like this? I know I'm probably being a little pedantic about this, I just want to have a discussion before we find ourselves with four different KFAIL philosophies in our test suite. I won't mind at all doing it whatever way that FernandoN and AndrewC think is best. Testing: tested on my native i686-pc-linux-gnu test bed with gcc v2 and v3, dwarf-2 and stabs+. It PASSes with all stabs+ configurations and with dwarf-2 in 2.95.3, 3.2.1, gcc-3_2-branch, and gcc-3_3-branch. It KFAILs with gcc HEAD -gdwarf-2. Michael C == main-falloff.cc int main () { int i, j, k; i = 101; j = 102; k = 103; } === main-falloff.exp # Copyright 2002 Free Software Foundation, Inc. # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2 of the License, or # (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. # # Please email any bugs, comments, and/or additions to this file to: # bug-gdb@prep.ai.mit.edu # # Written by Michael Elizabeth Chastain (mec@shout.net) # This file is part of the gdb testsuite. # # Stroustrup, "The C++ Programming Language", 3rd edition, section 3.2, says: # # "Every C++ program must have a function named main(). # The program starts by executing that function. # The int value returned by main(), if any, is the # program's return value to ``the system'.'' # If no value is returned, the system will receive a value # indicating successful completion. A nonzero return # value from main() indicates failure." # # gcc has special code to handle this wart where main() can legally fall # off the end. I have seen bugs in the special code, hence this test case. if $tracelevel then { strace $tracelevel } if { [skip_cplus_tests] } { continue } set prms_id 0 set bug_id 0 set testfile "main-falloff" set srcfile ${testfile}.cc set binfile ${objdir}/${subdir}/${testfile} if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug c++}] != "" } { gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail." } if [get_compiler_info ${binfile} "c++"] { return -1 } gdb_exit gdb_start gdb_reinitialize_dir $srcdir/$subdir gdb_load ${binfile} if ![runto_main] then { perror "couldn't run to breakpoint" continue } # next on through to the closing brace. gdb_test "next 3" "8.*" "next 3" # print the locals send_gdb "info locals\n" gdb_expect { -re "(i|j|k) = (101|102|103)\r\n(i|j|k) = (101|102|103)\r\n(i|j|k) = (101|102|103)\r\n$gdb_prompt $" { pass "info locals" } -re "No locals.\r\n$gdb_prompt $" { # The locals have disappeared just before the end of the function. # This happened with gcc HEAD%20021224 -gdwarf-2. # -- chastain 2002-12-29 kfail "gdb/900" "info locals" } -re ".*$gdb_prompt $" { fail "info locals" } timeout { fail "info locals (timeout)" } } gdb_exit return 0