This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] gcc/toplev.c: Avoid to close 'asm_out_file' when it is 'stdout'


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]