From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20822 invoked by alias); 24 Apr 2004 16:08:40 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 20814 invoked from network); 24 Apr 2004 16:08:39 -0000 Received: from unknown (HELO dair.pair.com) (209.68.1.49) by sources.redhat.com with SMTP; 24 Apr 2004 16:08:39 -0000 Received: (qmail 45783 invoked by uid 20157); 24 Apr 2004 16:07:48 -0000 Date: Sat, 24 Apr 2004 17:36:00 -0000 From: Hans-Peter Nilsson X-X-Sender: hp@dair.pair.com To: Andreas Schwab cc: Nathan Sidwell , Ian Lance Taylor , binutils@sources.redhat.com Subject: Re: demand_empty_rest_of_line and ignore_rest_of_line In-Reply-To: Message-ID: References: <40587E7B.10705@codesourcery.com> <405979E9.9030805@codesourcery.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004-04/txt/msg00666.txt.bz2 On Fri, 23 Apr 2004, Andreas Schwab wrote: > This means that the unknown character is no longer ignored, despite the > comment. As a side effect a line starting with a line comment character > not followed by APP in NO_APP mode now triggers an error instead of just a > warning, breaking builds of glibc on m68k-linux. For the record, there aren't supposed to *be* any comments in #NO_APP mode; just strict formatted assembly code and #APP of course. That's what it means. If the glibc __sec_comment kludge is the problem, let me mention that different patches have been sent to glibc in order to make its kludge work properly(!) at least one that adds #NO_APP and I'm sure would work, but it seems none have been applied. Of course, we could do something that lets glibc emit its .gnu.warning.* sections without assembler warnings, and avoid using the __sec_comment kludge where the new thing is supported. brgds, H-P