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.
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.
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.
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.
Thanks,
jeff
