This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] gcc/toplev.c: Avoid to close 'asm_out_file' when it is 'stdout'
- From: Jeff Law <law at redhat dot com>
- To: Chen Gang <gang dot chen dot 5i5j at gmail dot com>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, rth at redhat dot com, gcc-patches at gcc dot gnu dot org
- Date: Fri, 25 Jul 2014 15:12:11 -0600
- Subject: Re: [PATCH] gcc/toplev.c: Avoid to close 'asm_out_file' when it is 'stdout'
- Authentication-results: sourceware.org; auth=none
- References: <53CD3617 dot 2000503 at gmail dot com> <53CF2FB6 dot 6000708 at redhat dot com> <53D03470 dot 9020602 at gmail dot com>
On 07/23/14 16:17, Chen Gang wrote:
OK. I suspected it might be the case that you just saw something odd
and sent a patch to change it.
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.
* topleve.c (finalize): Avoid to close 'asm_out_file' when it is
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).
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
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.
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.
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.
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.