From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27969 invoked by alias); 26 Jul 2014 01:33:20 -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 27942 invoked by uid 89); 26 Jul 2014 01:33:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,UNSUBSCRIBE_BODY autolearn=no version=3.3.2 X-HELO: mail-pd0-f169.google.com Received: from mail-pd0-f169.google.com (HELO mail-pd0-f169.google.com) (209.85.192.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sat, 26 Jul 2014 01:33:15 +0000 Received: by mail-pd0-f169.google.com with SMTP id y10so6580086pdj.28 for ; Fri, 25 Jul 2014 18:33:13 -0700 (PDT) X-Received: by 10.70.14.227 with SMTP id s3mr22375687pdc.88.1406338393284; Fri, 25 Jul 2014 18:33:13 -0700 (PDT) Received: from [192.168.1.23] ([124.127.118.42]) by mx.google.com with ESMTPSA id qm12sm10169900pbb.15.2014.07.25.18.33.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jul 2014 18:33:12 -0700 (PDT) Message-ID: <53D30554.2000403@gmail.com> Date: Sat, 26 Jul 2014 03:26:00 -0000 From: Chen Gang User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Jeff Law CC: "Joseph S. Myers" , rth@redhat.com, gcc-patches@gcc.gnu.org Subject: Re: [PATCH] gcc/toplev.c: Avoid to close 'asm_out_file' when it is 'stdout' References: <53CD3617.2000503@gmail.com> <53CF2FB6.6000708@redhat.com> <53D03470.9020602@gmail.com> <53D2C82B.9000104@redhat.com> In-Reply-To: <53D2C82B.9000104@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-07/txt/msg01775.txt.bz2 On 07/26/2014 05:12 AM, Jeff Law wrote: > On 07/23/14 16:17, Chen Gang wrote: >> On 07/23/2014 11:44 AM, Jeff Law wrote: >>> On 07/21/14 09:47, Chen Gang wrote: >>>> 'asm_out_file' may be 'stdout', so need check this case before close >>>> it. >>>> Or 'stdout' may be closed -- since need not open 'stdout', either need >>>> not close it. >>>> >>>> ChangLog: >>>> >>>> * topleve.c (finalize): Avoid to close 'asm_out_file' when it is >>>> 'stdout'. >>> What exactly is the problem with closing stdout at this point? In >>> general, you need to state the problem you're trying to fix with your >>> patch. >>> >> >> Excuse me, I only find it by reading source code, so for me, I didn't >> meet the real problem for it, so at least, this patch is not urgent ( >> although I am not sure whether it is still valuable or not). > OK. I suspected it might be the case that you just saw something odd > and sent a patch to change it. > > But that was just a suspicion -- there well could have been some path > you found where GCC wanted to write to stdout after the point where we > closed the output file. That would clearly be a bug and warrant fixing > immediately. > In source root directory: "grep -rn asm_out_file * | grep stdout" "grep -rn asm_out_file * | grep fclose" "grep -rn asm_out_file * | grep NULL". We can know about stdout may be used (e.g. the related parameter is '-') in init_asm_output() in "gcc/toplev.c". And only one place to close it in finalize() in "gcc/toplev.c". But really, it is only by reading source code, no any real test for it, so yeah, we can say it is only a suspicion. > Either way it's important you tell us why you're making a change in a > way which allows us to evaluate the importance of the change. Otherwise > we have to guess and we could easily guess wrong. > > In this specific instance, I don't really see any value in avoiding the > close of stdout. > I don't see either, so at least, it is not urgent. But if it was really a bug, for me, we have to fix it, when we have time. >> >> At present, I am a newbie, and use 2 ways to learn gcc and binutils. >> >> - Cross compile the cross compiler with '-W' for linux kernel. >> (If find issues, I shall try to fix them with related members). >> >> - Reading source code of gcc and binutils, if find some where can be >> improved, and try to send patch for it. > And these are excellent ways to get started. Another would be to build > GCC with Clang/LLVM and see what warnings that generates and try to fix > them. Perusing the bug database (gcc.gnu.org/bugzilla) can sometimes > result in identifying issues you can resolve. > Thank you for your ideas and suggestions, Clang/LLVM and bugzilla are really two important and valuable places. But excuse me, I have no enough time resources on it. I have started Linux kernel and qemu/kvm/xen in my free time, and now, I am starting gcc/binutils in my free time, too. - "cross compiling the cross-compiler for linux kernel, and let each architectures in kernel pass allmodconfig" is an efficient way to me for both learning gcc/binutils and linux kernel. - Reading source code are always necessary in any cases (it is my main learning way for qemu/kvm/xen). Clang/LLVM and bugzilla are really very important, so I shall try them in the future (I guess, may be next year -- 2015). >> By the way, is there a trivial patch mailing list of gcc? I guess most >> of my patches belong to trivial. > No, all patches go to gcc-patches, even trivial ones. > OK, thanks. And I shall continue in gcc-patches. And excuse me, next, most of my trivial patches maybe bother many other members in gcc-patches mailing list. Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed