From tradke at aei.mpg.de Tue Oct 14 06:17:07 2008 From: tradke at aei.mpg.de (Thomas Radke) Date: Tue, 14 Oct 2008 13:17:07 +0200 Subject: [Developers] [Carpet] Errors with LoopControl In-Reply-To: References: <48F366A7.7040806@aei.mpg.de> Message-ID: <48F47FB3.30605@aei.mpg.de> Erik Schnetter wrote: > On Oct 13, 2008, at 17:17:59, Thomas Radke wrote: > >> Erik Schnetter wrote: >>> On Mar 27, 2008, at 04:25:26, Hee Il Kim wrote: >>>> Hi, >>>> >>>> I encountered the following errors on a system with intel compilers >>>> 10.1. I'm using the latest Carpet. >>>> >>>> ### >>>> ... >>>> ... >>>> >>>> Preprocessing >>>> /home/khi/Cactus/arrangements/Carpet/LoopControl/src/loopcontrol_types.F90 >>>> >>>> >>>> Compiling >>>> /home/khi/Cactus/arrangements/Carpet/LoopControl/src/loopcontrol_types.F90 >>>> >>>> >>>> fortcom: Error: >>>> /home/khi/Cactus/configs/rns_carpet_loopcontrol/build/LoopControl/loopcontrol_types.f90, >>>> >>>> line 6: Syntax error, found IDENTIFIER 'NEXT' when expecting one of: >>>> => = . ( : % >>>> CCTK_POINTER next >>>> ------------------^ >>> >>> I don't know why the type CCTK_POINTER is not known. There may be >>> something missing in the flesh. I'll have a look. >> >> We just had the same problem here on someone's mac using intel >> compilers. It could be fixed by substituting >> >> #include >> >> with >> >> #include "cctk.h" >> >> in Carpet/LoopControl/src/loopcontrol_types.F90. >> >> This type of header file inclusion also happens in other LoopControl >> sources; other Carpet thorns use both versions in a mixed way. Should >> this be made consistent ? > > > This problem only exists in Fortran code. C and C++ code can use both > <> and "" without problems. > > The C standard suggests that both <> and "" should work in this case. > cpp.pl, the Cactus implementation of part of a C preprocessor, simply > ignores #include lines with <> and only processes those with "". I > think we could change this in cpp.pl, treating <> and "" in the same way > (apart from skipping the current directory when <> is used). If you don't like changing the Cactus header file inclusions into #include "header.h" then the Cactus preprocessor needs to be fixed to also handle #include properly. The attached patch does that. Ok to apply ? -- Cheers, Thomas. --- StripMime Report -- processed MIME parts --- multipart/mixed text/plain (text body -- kept) text/x-patch --- From schnetter at cct.lsu.edu Tue Oct 14 07:38:37 2008 From: schnetter at cct.lsu.edu (Erik Schnetter) Date: Tue, 14 Oct 2008 14:38:37 +0200 Subject: [Developers] [Patches] [Carpet] Errors with LoopControl In-Reply-To: <48F47FB3.30605@aei.mpg.de> References: <48F366A7.7040806@aei.mpg.de> <48F47FB3.30605@aei.mpg.de> Message-ID: On Oct 14, 2008, at 13:17:07, Thomas Radke wrote: > Erik Schnetter wrote: >> On Oct 13, 2008, at 17:17:59, Thomas Radke wrote: >>> Erik Schnetter wrote: >>>> On Mar 27, 2008, at 04:25:26, Hee Il Kim wrote: >>>>> Hi, >>>>> >>>>> I encountered the following errors on a system with intel >>>>> compilers >>>>> 10.1. I'm using the latest Carpet. >>>>> >>>>> ### >>>>> ... >>>>> ... >>>>> >>>>> Preprocessing >>>>> /home/khi/Cactus/arrangements/Carpet/LoopControl/src/ >>>>> loopcontrol_types.F90 >>>>> >>>>> Compiling >>>>> /home/khi/Cactus/arrangements/Carpet/LoopControl/src/ >>>>> loopcontrol_types.F90 >>>>> >>>>> fortcom: Error: >>>>> /home/khi/Cactus/configs/rns_carpet_loopcontrol/build/ >>>>> LoopControl/loopcontrol_types.f90, >>>>> line 6: Syntax error, found IDENTIFIER 'NEXT' when expecting one >>>>> of: >>>>> => = . ( : % >>>>> CCTK_POINTER next >>>>> ------------------^ >>>> >>>> I don't know why the type CCTK_POINTER is not known. There may be >>>> something missing in the flesh. I'll have a look. >>> >>> We just had the same problem here on someone's mac using intel >>> compilers. It could be fixed by substituting >>> >>> #include >>> >>> with >>> >>> #include "cctk.h" >>> >>> in Carpet/LoopControl/src/loopcontrol_types.F90. >>> >>> This type of header file inclusion also happens in other LoopControl >>> sources; other Carpet thorns use both versions in a mixed way. >>> Should >>> this be made consistent ? >> This problem only exists in Fortran code. C and C++ code can use >> both <> and "" without problems. >> The C standard suggests that both <> and "" should work in this >> case. cpp.pl, the Cactus implementation of part of a C >> preprocessor, simply ignores #include lines with <> and only >> processes those with "". I think we could change this in cpp.pl, >> treating <> and "" in the same way (apart from skipping the current >> directory when <> is used). > > If you don't like changing the Cactus header file inclusions into > > #include "header.h" > > then the Cactus preprocessor needs to be fixed to also handle > > #include > > properly. > > The attached patch does that. Ok to apply ? This patch implicitly also requires that all include files that are included with <> have to exist, and these files are added as build dependencies. This was not the case before. That means it could be that cpp.pl is used to find dependencies of a source file where it cannot find the location of an include file. Previously it would ignore these files, now it will abort. If we encounter this, we will have to see why the include file couldn't be found. I check all Fortran thorns to which I have access and did not find such a case. Steve, I think you had a similar problem recently. Does this patch work for you? -erik -- Erik Schnetter http://www.cct.lsu.edu/~eschnett/ My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from www.keyserver.net. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part Url : http://www.cactuscode.org/pipermail/developers/attachments/20081014/4faed486/attachment.bin From sbrandt at cct.lsu.edu Tue Oct 14 09:02:58 2008 From: sbrandt at cct.lsu.edu (Steven R Brandt) Date: Tue, 14 Oct 2008 09:02:58 -0500 Subject: [Developers] [Patches] [Carpet] Errors with LoopControl In-Reply-To: References: <48F366A7.7040806@aei.mpg.de> <48F47FB3.30605@aei.mpg.de> Message-ID: <48F4A692.8040400@cct.lsu.edu> What I think should happen is that #include directive should be left in the file (no abort) if the file is not found. The reason is that the built-in cpp has all kinds of special compiler / system dependent places it might want to search for files. If it aborts it may fail for C/C++ files that would successfully compile. However, if #include "file" fails, then abort is appropriate. Cheers, Steve Erik Schnetter wrote: > On Oct 14, 2008, at 13:17:07, Thomas Radke wrote: > >> Erik Schnetter wrote: >>> On Oct 13, 2008, at 17:17:59, Thomas Radke wrote: >>>> Erik Schnetter wrote: >>>>> On Mar 27, 2008, at 04:25:26, Hee Il Kim wrote: >>>>>> Hi, >>>>>> >>>>>> I encountered the following errors on a system with intel compilers >>>>>> 10.1. I'm using the latest Carpet. >>>>>> >>>>>> ### >>>>>> ... >>>>>> ... >>>>>> >>>>>> Preprocessing >>>>>> /home/khi/Cactus/arrangements/Carpet/LoopControl/src/loopcontrol_types.F90 >>>>>> >>>>>> >>>>>> Compiling >>>>>> /home/khi/Cactus/arrangements/Carpet/LoopControl/src/loopcontrol_types.F90 >>>>>> >>>>>> >>>>>> fortcom: Error: >>>>>> /home/khi/Cactus/configs/rns_carpet_loopcontrol/build/LoopControl/loopcontrol_types.f90, >>>>>> >>>>>> line 6: Syntax error, found IDENTIFIER 'NEXT' when expecting one of: >>>>>> => = . ( : % >>>>>> CCTK_POINTER next >>>>>> ------------------^ >>>>> >>>>> I don't know why the type CCTK_POINTER is not known. There may be >>>>> something missing in the flesh. I'll have a look. >>>> >>>> We just had the same problem here on someone's mac using intel >>>> compilers. It could be fixed by substituting >>>> >>>> #include >>>> >>>> with >>>> >>>> #include "cctk.h" >>>> >>>> in Carpet/LoopControl/src/loopcontrol_types.F90. >>>> >>>> This type of header file inclusion also happens in other LoopControl >>>> sources; other Carpet thorns use both versions in a mixed way. Should >>>> this be made consistent ? >>> This problem only exists in Fortran code. C and C++ code can use >>> both <> and "" without problems. >>> The C standard suggests that both <> and "" should work in this >>> case. cpp.pl, the Cactus implementation of part of a C >>> preprocessor, simply ignores #include lines with <> and only >>> processes those with "". I think we could change this in cpp.pl, >>> treating <> and "" in the same way (apart from skipping the current >>> directory when <> is used). >> >> If you don't like changing the Cactus header file inclusions into >> >> #include "header.h" >> >> then the Cactus preprocessor needs to be fixed to also handle >> >> #include >> >> properly. >> >> The attached patch does that. Ok to apply ? > > > This patch implicitly also requires that all include files that are > included with <> have to exist, and these files are added as build > dependencies. This was not the case before. > > That means it could be that cpp.pl is used to find dependencies of a > source file where it cannot find the location of an include file. > Previously it would ignore these files, now it will abort. If we > encounter this, we will have to see why the include file couldn't be > found. I check all Fortran thorns to which I have access and did not > find such a case. > > Steve, I think you had a similar problem recently. Does this patch > work for you? > > -erik >