llvm dev - May 2021 - A friendly question

Hello,
Not sure there will be enough use for it but I was wondering whether there
would be enough interest in making llvm-based gnucobol project clone
(possibly launching summer of code project for it).

For now it works in such a way that it processes cobol sourcecode and
produces source in C.

In such way we could try to beat both gnu cobol and ibm releasing lately
cobol compiler on x86 linux (if im not mistaken wrt to OS).

Best regards,
Pawel Kunio
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210505/5b501b87/attachment.html>

Hi,

I've renamed the thread so that interested folks might see it.

I think there are a bunch of somewhat conflated here and it's probably 
worth unpicking them a bit.  They seem to be:

  - Is anyone interested in writing a COBOL front end for LLVM?
  - Would a COBOL front end be considered for integration with the LLVM 
repository?
  - Would projects to work on an LLVM COBOL front end be considered for 
the GSoC or similar?

I can take a stab at answering these:

  - There are almost certainly some people interested in COBOL.  Most 
folks on this list probably don't care about Fortran, but that hasn't 
prevented flang from being written and integrated into the repository. 
Some of the IBM people might be interested.  I think the main question 
is what the differentiation is from gnucobol.  From a quick skim, 
gnucobol translates COBOL to C, so you can presumably already use it 
with clang and get an LLVM back end.  Writing a new front-end is a 
nontrivial task and so you'd have to explain what the benefit is of a 
new one.  Most of the codegen-related benefits don't apply (presumably 
you can already use clang + gnucobol to compile COBOL to IR and do LTO 
with it and C/C++/Fortran/Whatever code).  Would you want to reuse 
Clang's diagnostic infrastructure and provide better error messages?  Is 
it just a question of the license?

  - There's a difference of opinion in the community about the 
importance of being in-tree.  I'd personally prefer that clang and flang 
were both moved out of the monorepo to force us to think more about 
library interfaces.  The more LLVM developers are also working on 
out-of-tree projects, the better our libraries become.  That said, if 
you want a project to be considered for eventual inclusion in the tree, 
then making sure that the license is the same as the rest of the project 
and that the coding style is the same is a good first step.  You can 
then defer this decision until the front end is more mature and you see 
some clear benefit in being upstream.

  - For a project to be considered for the GSoC, the only real 
requirement is finding someone willing to mentor it.  That means that 
you need to find someone who is an existing LLVM contributor who is 
interested in COBOL and you need to provide a good answer to the 'why 
isn't gnucobol good enough?' question.

David


On 05/05/2021 22:44, pawel k. via llvm-dev wrote:
> Hello,
> Not sure there will be enough use for it but I was wondering whether 
> there would be enough interest in making llvm-based gnucobol project 
> clone (possibly launching summer of code project for it).
> 
> For now it works in such a way that it processes cobol sourcecode and 
> produces source in C.
> 
> In such way we could try to beat both gnu cobol and ibm releasing lately 
> cobol compiler on x86 linux (if im not mistaken wrt to OS).
> 
> Best regards,
> Pawel Kunio
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>