On 12/04/2012 17:23, Tobias Burnus wrote: > This patch is a kind of follow up to the other one for the same PR - > though this one is for a separate test case, it is not a regression and > it's about actual/formal checks. > > When trying to fix the rejects-valid bug, I realized that one function > was never accessed as a call to expr.c's gfc_check_vardef_context is > done before. I made some cleanup and added some code to ensure pointer > CLASS are correctly handled. I am not positive that the removed code is > unreachable, but I failed to produce reachable code and also the test > suit passed. > > Thus, this patch removed a rejects-valid bug, an accepts-invalid bug, > cleans up the code a bit and adds a test case for existing checks > (besides testing the bug fixes). > > Build and regtested on x86-64-linux. > OK for the trunk? >
Hello, is there a reason to guard the class_pointer condition with attr.class_ok in the first conditional and with CLASS_DATA(...) != NULL in the two other ones? Not that it matters much, and in fact, I think the patch as is is good enough for committal (yes, it is a OK). I'm asking as I never know myself what is the correct, canonical way to handle the class_* hell... Thanks Mikael
