From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) by sourceware.org (Postfix) with ESMTP id 0095E3858D38 for ; Sat, 11 Nov 2023 18:05:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0095E3858D38 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gentoo.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gentoo.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 0095E3858D38 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=140.211.166.183 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699725902; cv=none; b=MK1/t9W5IhQjXKa/aaYH4VRj+9CV/uPhoiJC8vYfes6/bw7quZwYK48uzN0mo3hCTLBc2vkKebHTIlDe9HVipy29ipt4PITE0yxWOvbQawz9YGbKHo8YbSOxNkj63YQpF5JMOuFWTt6FAoSF/gsnPien9DZWD8v9Vvi+zy8x+8M= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699725902; c=relaxed/simple; bh=qXhr7WVcc4mKtSladTQJ1jKHbCL5338dANZAKk3VZ5k=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=pX5RX+xWLYqsTiY60CTi5ou1A7ieqNX3ZCGElfeHjETEVRLQxt1gRLRdP548MSh66B+A3a6E0LCdW8FqWCcxkM4OkUJzGt8RfoOuJJQvzPB+HbbqtLiX7HidGWSDGIoSp+MSc53tdgpUtWlKUn7d3bl1VOqgdIVJ61Nu4W1HMt0= ARC-Authentication-Results: i=1; server2.sourceware.org References: <87leb5462f.fsf@oldenburg.str.redhat.com> <87msvk2ngy.fsf@oldenburg.str.redhat.com> User-agent: mu4e 1.10.8; emacs 30.0.50 From: Sam James To: Florian Weimer Cc: Eric Gallager , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] C99 testsuite readiness: -fpermissive tests Date: Sat, 11 Nov 2023 18:03:39 +0000 Organization: Gentoo In-reply-to: <87msvk2ngy.fsf@oldenburg.str.redhat.com> Message-ID: <87sf5c6u9k.fsf@gentoo.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-10.0 required=5.0 tests=BAYES_00,GIT_PATCH_0,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Florian Weimer writes: > * Eric Gallager: > >>> diff --git a/gcc/testsuite/gcc.c-torture/compile/20080910-1.c b/gcc/testsuite/gcc.c-torture/compile/20080910-1.c >>> index bf32775d401..911fb562790 100644 >>> --- a/gcc/testsuite/gcc.c-torture/compile/20080910-1.c >>> +++ b/gcc/testsuite/gcc.c-torture/compile/20080910-1.c >>> @@ -1,5 +1,6 @@ >>> /* This used to crash IRA with -O3 -fPIC. >>> See PR 37333. */ >>> +/* { dg-additional-options "-fpermissive" } */ >>> struct yy_buffer_state { >>> int yy_is_interactive; >>> }; >> >> The fact that this one appears to be based on a scanner generated by >> flex gives me pause. Is code from flex/yacc/bison going to need >> -fpermissive in general, or is this just because it was generated by >> an old version? If it's only old versions that generate code requiring >> -fpermissive, when exactly did they stop doing that? > > It can be a bit tricky to get bison, flex, and automake to work > together. The inter-dependencies can be challenging, and apparently > it's difficult to teach automake that generating a lexer or parser > produces both the implementation C file and a header file. There's a > fairly generic way to deal with this: write a custom header that > contains the necessary function declarations and include it everywhere. > It's not as elegant as using the generated headers, but that can be > difficult depending on the build system. Right. The issues with anything Bison (and friends) were usually missing declarations because of the header dependencies. Nothing intrinsic. In fact, I can't even remember anything where Bison et. al generated bad code purely by virtue of the version (even though sometimes comments would suggest that, I never found any evidence for it, and it was always the fault of the project itself which we'd then fix). So, not worried. > > However, the problems with this test case aren't related to that. For > example, yy_fatal_error is undefined, but is a static function in the > code generated by flex. The test case has been preprocessed (that's how > _IO_getc got there), and the declarations from system headers have been > removed. > > Thanks, > Florian