From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 76289 invoked by alias); 17 Dec 2015 20:33:45 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 75438 invoked by uid 89); 17 Dec 2015 20:33:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=theoretically, H*Ad:U*olegendo, dbx, legs X-Spam-User: qpsmtpd, 3 recipients X-HELO: paperclip.tbsaunde.org Received: from tbsaunde.org (HELO paperclip.tbsaunde.org) (66.228.47.254) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 17 Dec 2015 20:33:43 +0000 Received: from tsaunders-iceball.corp.tor1.mozilla.com (unknown [IPv6:2607:f0c8:8000:80e0:3e97:eff:fec1:f2b4]) by paperclip.tbsaunde.org (Postfix) with ESMTPSA id 6599BC06B; Thu, 17 Dec 2015 20:33:40 +0000 (UTC) Date: Thu, 17 Dec 2015 20:33:00 -0000 From: Trevor Saunders To: Jeff Law Cc: Jan-Benedict Glaw , Trevor Saunders , "Moore, Catherine" , Denis Chertykov , Eric Christopher , Matthew Fortune , David Edelsohn , Alexandre Oliva , Kaz Kojima , Oleg Endo , Jonathan Wakely , gcc-patches Subject: Re: config-list.mk and obsoleted configurations Message-ID: <20151217203111.GA13192@tsaunders-iceball.corp.tor1.mozilla.com> References: <20151206214848.GA495@lug-owl.de> <20151214200746.GA27807@lug-owl.de> <5670515E.7030009@redhat.com> <20151216104603.GB27807@lug-owl.de> <5672F976.1090609@redhat.com> <20151217183448.GC27807@lug-owl.de> <5673015C.1020904@redhat.com> <20151217185831.GD27807@lug-owl.de> <567312B0.4060508@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <567312B0.4060508@redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-SW-Source: 2015-12/txt/msg01822.txt.bz2 On Thu, Dec 17, 2015 at 12:53:20PM -0700, Jeff Law wrote: > On 12/17/2015 11:58 AM, Jan-Benedict Glaw wrote: > >On Thu, 2015-12-17 11:39:24 -0700, Jeff Law wrote: > >>On 12/17/2015 11:34 AM, Jan-Benedict Glaw wrote: > >>>On Thu, 2015-12-17 11:05:42 -0700, Jeff Law wrote: > >>>>On 12/16/2015 03:46 AM, Jan-Benedict Glaw wrote: > >>>>>Shall I bisect one of the cases anew, with the "Test value of > >>>>>_GLIBCXX_USE_C99_WCHAR not whether it is defined" patch that > >>>>>uncovered it, applied? Starting with some arbitrary old revision? > >>>>Yes. I'd really like to see config-list.mk working again. The > >>>>first step is always building a test the developers can easily work > >>>>with. > >>> > >>>Will do. Have a good starting point? > >>The biggest problem is the breakage around wither USE_C99_WCHAR or delayed > >>folding. I think I counted 30+ targets that were effected. > > > >It's probably delayed folding; seems the USE_C99_WCHAR stuff only > >uncovers it, doesn't it? > > > >>Once that's settled, I suspect anything remaining will be pretty minor. > >> > >>I'd disable interix completely. > > > >Seems to be not hard to fix. Breaks with: > I know, but it's not worth fixing IMHO. Interix has been a dead product for > a long time. We almost got rid of it several years ago, but someone > objected and said they'd maintain it. I asked Trevor to put it back on the > deprecated list a little while ago. > > AFAICT it hasn't been building since 2012. I fixed some of the problems a > few months ago, but just can't really justify anyone's time to figure out > which way to #define this away to preserve prior behaviour and to continue > to keep it working over time. and killing it will help move towards killing other things you dislike like sdb and dbx. > > > > >>Not sure what to do with avr-rtems at this point. > > > >My buildrobot just fails at the very same USE_C99_WCHAR issue right > >now. Is there something more hidden, later on in the build? > avr-rtems has deeper issues, which ultimately look like the same problem > you're seeing with delayed folding, but aren't the same problem. > > Essentially avr-rtems's definitions of various standard types are all > conditional on flags with a default that is NULL. Those are ultimately > passed to one of the str* functions and GCC throws a warning/failure. hWell, it might be the only target that has warnings because of that, but from a quick look it seems like any target that uses avr-stdint.h or newlib-stdint.h could theoretically have null values for those macros. Without a bit of digging I'm not sure how much of that is real and how much is completely theoretical archs that would have any number of other problems. Trev > > There's no way to fold those down to a constant, (or even to prove the NULL > case couldn't happen IIRC). So even once the current delayed folding issue > gets fixed, avr-rtems will remain broken. > > It's also unclear how long avr-rtems will be around. I get the sense it's > on its last legs -- and given we have both avr and rtems coverage via other > targets, I don't think building avr-rtems is really all that helpful. > > Jeff