[prev in list] [next in list] [prev in thread] [next in thread]
List: gcc-fortran
Subject: Re: Concatenation without spaces in macros
From: Arjen Markus via Fortran <fortran () gcc ! gnu ! org>
Date: 2020-08-31 6:35:32
Message-ID: CAMCbSMr2qgxio3bJVtRg3J=OuQDrcxQDfM3ftMr28aksxTiYfw () mail ! gmail ! com
[Download RAW message or body]
Well, I had a look at the bug report plus patches and the code of
libcpp. The first step was simple: get the preprocessor to recognise
the Fortran concatenation operator. With that in place I could use the
standard preprocessor. But the challenge is in teaching that to
preserve the whitespace. For instance, a macro like:
#define CHECK(a) \
if ( a ) then \
write(*,*) "All is okay" \
endif
will be translated into one long line (but that is already the case).
Which is fine for C, where statements are explicitly ended with a
semicolon, but not for Fortran.
And then there is the distinction between fixed and free form code ...
It is an intriguing problem.
Regards,
Arjen
Op do 27 aug. 2020 om 10:26 schreef Arjen Markus <arjen.markus895@gmail.com>:
>
> That looks like a nice project :). Let me study it a bit before taking
> up the challenge - if I end up with too much on my plate, that will
> not help anybody.
>
> Regards,
>
> Arjen
>
> Op do 27 aug. 2020 om 09:37 schreef Tobias Burnus <tobias@codesourcery.com>:
> >
> > You could run "cpp" itself to convert .F90 to .f90 before
> > running the Fortran compiler on the .f90. That way you get
> > the modern C processor. And you have to ensure yourself
> > that it does not break.
> >
> > Enabling (internally) the the non-traditional C processor
> > in gfortran is simple – But one has to teach it what are
> > Fortran comments, line continuations and strings to avoid
> > issues.
> > For instance, '//' is not a comment but string concatenation...
> >
> > See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28662
> > (esp. comment 4 to 10).
> >
> > Tobias
> >
> > On 8/27/20 7:57 AM, Arjen Markus via Fortran wrote:
> > > Well, the traditional mode is documented to be an approximation of
> > > what was a rather messy and underspecified facility. Hence the
> > > existence of this mode versus the official preprocessor.
> > >
> > > I understand the issue :).
> > >
> > > Regards,
> > >
> > > Arjen
> > >
> > > Op wo 26 aug. 2020 om 17:31 schreef Gilbert, Samuel (EC)
> > > <samuel.gilbert@canada.ca>:
> > > > Hello!
> > > >
> > > > Thanks for your replies!
> > > >
> > > > I had seen in the doc that cpp is executed in traditional mode when called \
> > > > from Fortran. I therefore used /**/ and it worked fine until I tried to \
> > > > concatenate with another macro instead of a literal.
> > > > I'm guessing that modifying the traditional mode of the preprocessor would \
> > > > probably not be a good idea since it could break existing code that relies on \
> > > > very specific preprocessor behaviour. Could it be possible to add a new \
> > > > Fortran mode to cpp that would support ##? I'm sure there would be some \
> > > > interest although it won't be as widespread as if it was something new for C. \
> > > > My organization uses mostly ifort and gfortran, but we also use IBM's XL \
> > > > and PGI's compilers. Any help that can make building our code with more \
> > > > compilers is always welcomed. We try to avoid compiler specific code as much \
> > > > as possible, but since the preprocessor is not even part of the language \
> > > > specification, sometimes there is no way around it.
> > > >
> > > > Cheers,
> > > >
> > > > Samuel
> > > >
> > > > ________________________________________
> > > > De : Arjen Markus <arjen.markus895@gmail.com>
> > > > Envoyé : 25 août 2020 09:52
> > > > À : Manfred Schwarb
> > > > Cc : Gilbert, Samuel (EC); fortran@gcc.gnu.org
> > > > Objet : Re: Concatenation without spaces in macros
> > > >
> > > > Well, the construction:
> > > >
> > > > #define PASTE(a) a
> > > > #define EVALUATOR(x,y) PASTE(x)y
> > > > #define FNCNAME(fun) EVALUATOR(fun,EXT)
> > > >
> > > > does do the job. I must have made a mistake before, when I concluded it did \
> > > > not.
> > > > Yes, that link is where I got the idea from :).
> > > >
> > > > Would there be much interest in a Fotran-compatible preprocessor?
> > > >
> > > > Regards,
> > > >
> > > > Arjen
> > > >
> > > > Op di 25 aug. 2020 om 15:47 schreef Manfred Schwarb <manfred99@gmx.ch>:
> > > > > Am 25.08.20 um 15:29 schrieb Manfred Schwarb:
> > > > > > Am 25.08.20 um 14:58 schrieb Arjen Markus via Fortran:
> > > > > > > Hi Samuel,
> > > > > > >
> > > > > > > the GCC help page on the subject
> > > > > > > (https://gcc.gnu.org/onlinedocs/cpp/Concatenation.html) uses "a ## b"
> > > > > > > but it also works without the surrounding spaces, as long as you use
> > > > > > > the gcc compiler. So, the preprocessor used by gfortran does not work
> > > > > > > in the same way with this feature.
> > > > > > >
> > > > > > Note, gfortran uses "cpp -traditional-cpp".
> > > > > For obvious reasons: cpp treats "//" as a comment.
> > > > > So as long as you do not use fortran concatenation, you may externally \
> > > > > preprocess your code with plain cpp, I guess.
> > > > >
> > > > > So ideally someone (TM) would implement a "-fortran" option to cpp which \
> > > > > suppresses incompatible features...
> > > > >
> > > > > Cheers,
> > > > > Manfred
> > > > >
> > > > > BTW: see
> > > > > https://stackoverflow.com/questions/41243555/concatenating-an-expanded-macro-and-a-word-using-the-fortran-preprocessor
> > > > >
> > > > >
> > > > > > See https://gcc.gnu.org/onlinedocs/cpp/Traditional-Mode.html
> > > > > > The ## vs. /**/ case is described in the first paragraph.
> > > > > >
> > > > > > Cheers,
> > > > > > Manfred
> > > > > >
> > > > > >
> > > > > > > A somewhat awkward workaround might be to use fixed-form source:
> > > > > > > spaces are not relevant then. Awkward, unfortunately.
> > > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > > Arjen
> > > > > > >
> > > > > > > Op ma 24 aug. 2020 om 19:53 schreef Gilbert, Samuel (EC) via Fortran
> > > > > > > <fortran@gcc.gnu.org>:
> > > > > > > > Hello,
> > > > > > > >
> > > > > > > > We have Fortran code that we wish to compile with different \
> > > > > > > > compilers. Furthermore, it must absolutely work with gfortran and \
> > > > > > > > ifort. We use macros to implement generic programming in Fortran \
> > > > > > > > (same function, but with different data types, dimensions, etc). To \
> > > > > > > > do so, the concatenation operator is used in the macros. The problem \
> > > > > > > > is that they are handled differently by gfortran and ifort.
> > > > > > > > I though that a simple #ifdef with the compiler identification token \
> > > > > > > > could have allowed uniform preprocessing, but there still are some \
> > > > > > > > differences and I have yet to find a way to achieve the desired \
> > > > > > > > result with gfortran.
> > > > > > > > Consider the following code fragment:
> > > > > > > > ==================================
> > > > > > > > #define EXT bar
> > > > > > > >
> > > > > > > > #ifdef __GFORTRAN__
> > > > > > > > #define PASTER(token1,token2) token1/**/token2
> > > > > > > > #else
> > > > > > > > #define PASTER(token1,token2) token1##token2
> > > > > > > >
> > > > > > > > ! With this syntax, gfotran expands it to foo##bar
> > > > > > > > #endif
> > > > > > > >
> > > > > > > > #define EVALUATOR(x,y) PASTER(x,y)
> > > > > > > > #define FNCNAME(fun) EVALUATOR(fun,EXT)
> > > > > > > > ! To have gfortran substitute EXT, a space must be added after the \
> > > > > > > > comma when
> > > > > > > > ! "calling" EVALUATOR in the FNCNAME macro
> > > > > > > > ! However, doing so means that we get foo bar instead of foobar
> > > > > > > >
> > > > > > > > integer :: FNCNAME(foo)
> > > > > > > >
> > > > > > > > ! gfortran -> fooEXT
> > > > > > > > ! ifort -> foobar
> > > > > > > > ==================================
> > > > > > > >
> > > > > > > > The end goal is to get concatenation without any space, such as \
> > > > > > > > foobar in the example above. Is there any way to achieve this with \
> > > > > > > > gfortran?
> > > > > > > >
> > > > > > > > Any help to resolve this issue will be greatly appreciated!
> > > > > > > >
> > > > > > > >
> > > > > > > > Cheers!
> > -----------------
> > Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
> > Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander \
> > Walter
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic