From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23231 invoked by alias); 31 Jan 2007 02:28:23 -0000 Received: (qmail 23165 invoked by uid 48); 31 Jan 2007 02:28:04 -0000 Date: Wed, 31 Jan 2007 02:28:00 -0000 Message-ID: <20070131022804.23164.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug testsuite/25241] DejaGNU does not distinguish between errors and warnings In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "manu at gcc dot gnu dot org" 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 X-SW-Source: 2007-01/txt/msg02697.txt.bz2 ------- Comment #9 from manu at gcc dot gnu dot org 2007-01-31 02:28 ------- (In reply to comment #8) > This is nice, Manuel, I hadn't considered changing the expressions as they are > added to the messages list. We already wrap dg-test (see the end of lib/gcc-dg.exp). So why not wrapping dg-warning and dg-error? Unfortunately my approach is quite brute, it would be better to call the original dg-warning/dg-error, catch its output and adjust it (or replace it). This way we shouldn't need to copy the whole function. Something similar is done for dg-test. I don't know how to do this because I have no idea of Tcl programming. > Another possibility is to add two new test directives, for example > dg-gcc-warning and dg-gcc-error, and leave dg-warning and dg-error as they are. > This has the advantage of not confusing people who are accustomed to the > existing behavior of the DejaGnu versions of these procs. That way you could > start using the new ones immediately, and we can gradually move other tests to > use them as well. We could do that. Will people use them? Will they be obligatory for new testcases? Anyway, I am afraid that the above patch is not correct. It produces spurious FAILs for some testcases that are fine. I am testing a new version, let's see how many testcases fail then. Also, we will need a new way to handle the output of inform and other messages that gcc produces, such as "cc1: warnings being treated as errors". (I think that particular message is inconsistent with the rest of our diagnostics, but that is another issue). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25241