On Mon, Jan 9, 2012 at 12:02, Tobias Burnus <bur...@net-b.de> wrote: > Dear all, > > this email contains a updated patch, which replaces the FIXME by an > implementation. See below. > > > Dear Dominique, > > > On 01/08/2012 11:13 PM, Dominique Dhumieres wrote: >> >> Your patch passed my tests and in top of that fixes the ICE for >> pr51522.f90. > > :-) > >> However I don't understand the errors: >> >> integer(c_int) function vect_Utils_vuTriIneqHolds_c(u, v, tol, >> exception)& >> 1 >> Error: Parameter 'c_int' at (1) has not been declared or is a variable, >> which does not reduce to a constant expression >> >> real(c_double) function vect_Utils_vuNorm_c(u, tol, badLevel, exception) >> bind >> 1 >> Error: Parameter 'c_double' at (1) has not been declared or is a variable, >> which does not reduce to a constant expression >> >> Is it related to the FIXME? > > > No, it's related to two bugs in the source code: > a) The USE statement is not a statement by its own (due to the tailing "&") > b) There is no USE statement for: vect_Utils_vuNorm_c > > I think the error message for (b) is good. I admit that for (a) a syntax > error would have been better. > > Excerpt from the test case (which has been created using "delta" which > deletes lines, honouring certain constraints): > > > integer(c_int) function vect_Utils_vuTriIneqHolds_c(u, v, tol, exception) & > use, intrinsic :: iso_c_binding > real(c_double) function vect_Utils_vuNorm_c(u, tol, badLevel, exception) > bind(c) > end function vect_Utils_vuNorm_c > > * * * > > Regarding the FIXME: No, it is completely unrelated and it is rather > difficult to encounter. > > Ingredients for reject-valid bugs related to the FIXME: > - One needs to USE a module name of an intrinsic module (iso_* or omp*) > - No non_intrinsic module with that name exists > - Multiple USE statements are used - some but not all with INTRINSIC > attribute > - One renames symbols > - One uses the renamed-away symbols for other purposes > > I believe that it is very unlikely that someone generates such a code. > > Example: > use iso_c_binding > use, intrinsic :: iso_c_binding, c_double_orig => c_double > integer :: c_double > > That's valid and rejected. If a non_intrinsic module "iso_c_binding" exists, > the code actually works correctly. It only wrongly use-associates "c_double" > if no non_intrinsic module exists. Workaround: Use "intrinsic" in both USE > statements - or in none. > > > However, I have now decided that it is better to actually implement the > FIXME; the updated patch is attached. (It was simpler than expected.) Only > gfc_use_modules has been changed and a new test case been added. > > Build and regtested on x86-64-linux. > OK for the trunk?
Thanks, looks good. Ok for trunk. Given that this has been broken since 4.3 and nobody noticed until now, and the patch is somewhat intrusive, I think it's ok to not backport it to the other branches. -- Janne Blomqvist
