[OT?] Should compiler warnings be treated as errors ?

[Simon Clubley]

Interesting article in The Register:

https://www.theregister.com/2021/09/08/compromise_linux_kernel_compiler_warnings/

Linus has modified the Linux build procedures to turn compiler warnings
into errors. I strongly agree with him and it's the same flag I use on
my own code.

However, some other people do not agree with him. Given how important
the Linux kernel has become, I am surprised by that. There would be
some initial cleanup pain, but IMHO, it's a flag that should have
been enabled long ago and you never know if that cleanup will find
some issues in the existing code.

What do you think ? Should compiler warnings be treated as errors ?

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

[Chris Townley]

On 09/09/2021 18:52, Simon Clubley wrote:
> Interesting article in The Register:
>
> https://www.theregister.com/2021/09/08/compromise_linux_kernel_compiler_warnings/
>
> Linus has modified the Linux build procedures to turn compiler warnings
> into errors. I strongly agree with him and it's the same flag I use on
> my own code.
>
> However, some other people do not agree with him. Given how important
> the Linux kernel has become, I am surprised by that. There would be
> some initial cleanup pain, but IMHO, it's a flag that should have
> been enabled long ago and you never know if that cleanup will find
> some issues in the existing code.
>
> What do you think ? Should compiler warnings be treated as errors ?
>
> Simon.
>

A lot depends on the environment/architecture.

Compiling on VMS in the system I inherited, there were numerous warnings
that could not be suppressed. I did spend a _lot_ of time removing
others - no code I wrote had direct warnings.

Likewise in various other environments.

Otherwise in principle I would agree with you


--
Chris

[Arne Vajhøj]

On 9/9/2021 1:52 PM, Simon Clubley wrote:
> Interesting article in The Register:
>
> https://www.theregister.com/2021/09/08/compromise_linux_kernel_compiler_warnings/
>
> Linus has modified the Linux build procedures to turn compiler warnings
> into errors. I strongly agree with him and it's the same flag I use on
> my own code.
>
> However, some other people do not agree with him. Given how important
> the Linux kernel has become, I am surprised by that. There would be
> some initial cleanup pain, but IMHO, it's a flag that should have
> been enabled long ago and you never know if that cleanup will find
> some issues in the existing code.
>
> What do you think ? Should compiler warnings be treated as errors ?

A team should have a "warnings not acceptable" policy.

A team should also have sufficient discipline so that the policy
is enough and -Werror is not needed.

Arne

[Stephen Hoffman]

On 2021-09-09 17:52:22 +0000, Simon Clubley said:

> What do you think ? Should compiler warnings be treated as errors ?

/WARN=( ENABLE=( NOC99, OBSOLESCENT, DEFUNCT, QUESTCODE, ...), DISABLE=(...))

Adding VERBOSE and OVERFLOW can be useful.

#pragma environment save and restore around #pragma message disable
cases where compilations errors are expected and cannot otherwise be
eliminated. Preferably with explanatory doc.

I typically don't bother upgrading warnings and such to errors or fatal
(which is ~possible on OpenVMS), choosing to not transfer code that
doesn't compile cleanly with the above switches into production.

Moving to these diagnostic, and removing home-grown memory management
schemes and some other steps, has resolved a number of subtle errors in
large and complex systems.

So too has been fully-integrated logging and debugging support within
large and complex apps, rather than treating all that as an
afterthought. This being as important as the compiler switches.


--
Pure Personal Opinion | HoffmanLabs LLC

[Craig A. Berry]

On 9/9/21 12:52 PM, Simon Clubley wrote:
> Interesting article in The Register:
>
> https://www.theregister.com/2021/09/08/compromise_linux_kernel_compiler_warnings/
>
> Linus has modified the Linux build procedures to turn compiler warnings
> into errors. I strongly agree with him and it's the same flag I use on
> my own code.

> What do you think ? Should compiler warnings be treated as errors ?

Which warnings with which versions of which compilers? gcc and clang
have different warnings available and different default warnings (though
they do emulate each other to some extent). Presumably some Linux
distros have to be able to build with other compilers, possibly from IBM
or Intel. The default warnings enabled with each version of each
compiler change, usually adding new ones, but sometimes removing
warnings that were felt to create more noise than light.

So, in general, yes, getting people to pay attention to warnings and fix
things is a good idea. But that's not a particularly simple matter for
something that is expected to be portable and compiled against various
version of numerous compilers.

I still routinely see warnings with the ancient DEC/CPQ/HP/HPE/VSI C
compiler for code that produces no warnings with current gcc and clang.
And of course compiler warnings get escalated to linker errors on VMS,
so what Linux is considering now has effectively already been the case
on VMS for a few decades.

[John Reagan]

On Thursday, September 9, 2021 at 8:30:16 PM UTC-4, Craig A. Berry wrote:

>
> I still routinely see warnings with the ancient DEC/CPQ/HP/HPE/VSI C
> compiler for code that produces no warnings with current gcc and clang.
> And of course compiler warnings get escalated to linker errors on VMS,
> so what Linux is considering now has effectively already been the case
> on VMS for a few decades.

Linker warnings.

And you can clear that with SET IMAGE /SUCCESS

[hb]

John already answered, but I've seen this so many times, so I'll expand
on that. They get escalated to linker warnings, not errors. The linker
produces an image file. You will not get one if the linker encounters an
error. And the image activator will active the image without printing
any message, no matter if it is a main image or a shareable. Only if you
try to find a symbol in the image file with lib$find_image_symbol you
will get a warning: %LIB-W-EOMWARN. Yes, a %LIB not a %SYSTEM.

And you can restore any cleared warning with SET IMAGE /RESTORE.

[Craig A. Berry]

Yes, I mixed up where the escalation happens. It is not the linker but
the build utility that turns warnings into errors and stops the build in
its tracks unless you take extra steps to get around it. A recent
real-world example:

Link /Debug/Trace/Map
/Shareable=[---.LIB.AUTO.ENCODE.CN]PL_ENCODE__CN.EXE
CN.opt/Option,[---]perlshr_attr.opt/Option
%LINK-W-SHRWRNERS, compilation warnings ␍␊ in shareable image file
D0:[CRAIG.blead]DBGPERLSHR.EXE;1
%MMK-F-ERRUPD, error status %X10648268 occurred when updating target
[---.LIB.AUTO.ENCODE.CN]PL_ENCODE__CN.EXE
%MMK-F-ERRUPD, error status %X1C14803C occurred when updating target SUBDIRS
%MMK-F-ERRUPD, error status %X1C14803C occurred when updating target SUBDIRS
Unsuccessful make(cpan/Encode): code=1024 at make_ext.pl line 584.
%NONAME-F-NOMSG, Message number 0C14803C
%MMK-F-ERRUPD, error status %X0C14803C occurred when updating target DYNEXT

You can of course force MMK or MMS or a command procedure to ignore
warnings and continue, or you can ignore the status of failed
subprocesses in whatever top-level driver is running those things. But
that is not what happens by default.

> And you can restore any cleared warning with SET IMAGE /RESTORE.

Of course there are ways to put your head in the sand if you want to,
for example cc/nowarn, and there are certainly development scenarios
where temporarily ignoring a warning and moving on is the right thing to
do.

My point was that on VMS compiler warnings stop the build unless you
take extra steps to prevent that from happening. On other platforms,
all the warnings are equivalent to informationals with DEC C -- nothing
happens unless you review the compiler output or, as Linux is apparently
now doing, explicitly escalate the warnings to errors.

[hb]

On 9/10/21 2:50 PM, Craig A. Berry wrote:
> Yes, I mixed up where the escalation happens.  It is not the linker but
> the build utility that turns warnings into errors and stops the build in
> its tracks unless you take extra steps to get around it.  A recent
> real-world example:
>
> Link /Debug/Trace/Map
> /Shareable=[---.LIB.AUTO.ENCODE.CN]PL_ENCODE__CN.EXE
> CN.opt/Option,[---]perlshr_attr.opt/Option
> %LINK-W-SHRWRNERS, compilation warnings ␍␊      in shareable image file
> D0:[CRAIG.blead]DBGPERLSHR.EXE;1
> %MMK-F-ERRUPD, error status %X10648268 occurred when updating target
> [---.LIB.AUTO.ENCODE.CN]PL_ENCODE__CN.EXE
> %MMK-F-ERRUPD, error status %X1C14803C occurred when updating target
> SUBDIRS
> %MMK-F-ERRUPD, error status %X1C14803C occurred when updating target
> SUBDIRS
> Unsuccessful make(cpan/Encode): code=1024 at make_ext.pl line 584.
> %NONAME-F-NOMSG, Message number 0C14803C
> %MMK-F-ERRUPD, error status %X0C14803C occurred when updating target DYNEXT
>
> You can of course force MMK or MMS or a command procedure to ignore
> warnings and continue, or you can ignore the status of failed
> subprocesses in whatever top-level driver is running those things.  But
> that is not what happens by default.

Interesting. Did you make DBGPERLSHR.EXE with MMS/MMK? Then you had an
"unsuccessful make" of DBGPERLSHR.EXE, which triggers the shown

"Unsuccessful make(cpan/Encode): code=1024 at make_ext.pl line 584."

perl script message. Which I interpret that at some point in the build
process MMS/MMK/Linker warnings were ignored. It seems you don't build
both images with one MMS/MMK/perl script run.
> ...

> My point was that on VMS compiler warnings stop the build unless you
> take extra steps to prevent that from happening.  On other platforms,
> all the warnings are equivalent to informationals with DEC C -- nothing
> happens unless you review the compiler output or, as Linux is apparently
> now doing, explicitly escalate the warnings to errors.

Do you ask for a linker switch (or by default?) to disable image
production in case of a warning?

[chris]

On 09/09/21 18:52, Simon Clubley wrote:
> Interesting article in The Register:
>
> https://www.theregister.com/2021/09/08/compromise_linux_kernel_compiler_warnings/
>
> Linus has modified the Linux build procedures to turn compiler warnings
> into errors. I strongly agree with him and it's the same flag I use on
> my own code.
>
> However, some other people do not agree with him. Given how important
> the Linux kernel has become, I am surprised by that. There would be
> some initial cleanup pain, but IMHO, it's a flag that should have
> been enabled long ago and you never know if that cleanup will find
> some issues in the existing code.
>
> What do you think ? Should compiler warnings be treated as errors ?
>
> Simon.
>

Always here. No code leaves this shop with warnings or other issues. A
warning is often saying the compiler cannot understand what your are
saying, so even if it means adding code, has to be done. I find that
most open source code compiles clean these days, so there's no excuse.

Lookup the Misra standards for embedded software development. A lot
of common sense there...

Chris

[Craig A. Berry]

The outer level MMK run that built DBGPERLSHR.EXE had not exited yet
when other things linked against it in subprocesses. It's actually
surprising that the first linker warning did not kill the build since
both MMS and MMK are documented to exit when they encounter warnings
executing action lines unless /IGNORE=WARNING is specified, which it was
not. Actually the librarian also threw a warning about compilation
warnings before the linker did.

>> My point was that on VMS compiler warnings stop the build unless you
>> take extra steps to prevent that from happening.  On other platforms,
>> all the warnings are equivalent to informationals with DEC C -- nothing
>> happens unless you review the compiler output or, as Linux is apparently
>> now doing, explicitly escalate the warnings to errors.
>
> Do you ask for a linker switch (or by default?) to disable image
> production in case of a warning?

No. I didn't know there was such a switch.

[Simon Clubley]

On 2021-09-09, Craig A. Berry <craig...@nospam.mac.com> wrote:
>
> Which warnings with which versions of which compilers? gcc and clang
> have different warnings available and different default warnings (though
> they do emulate each other to some extent). Presumably some Linux
> distros have to be able to build with other compilers, possibly from IBM
> or Intel. The default warnings enabled with each version of each
> compiler change, usually adding new ones, but sometimes removing
> warnings that were felt to create more noise than light.
>
> So, in general, yes, getting people to pay attention to warnings and fix
> things is a good idea. But that's not a particularly simple matter for
> something that is expected to be portable and compiled against various
> version of numerous compilers.
>

Of course, the other way of looking at that is that one compiler might
be picking up potential problems in your code that another compiler missed.

> I still routinely see warnings with the ancient DEC/CPQ/HP/HPE/VSI C
> compiler for code that produces no warnings with current gcc and clang.

Interesting. Are they "genuine" warnings or nonsense type warnings ?

Thanks to everyone for their responses. Given the general positive
response here, it makes me wonder why there's such pushback against
this change among some of the Linux developers.

I know some are taking the short-term (and short-sighted IMO) view
about the cleanup work required, but those warnings are being issued
by the compiler for a reason.

[Simon Clubley]

I've just had a look in the online help and I can't find it either.

It could be useful so I would be interested in knowing what that
qualifier is. (I am assuming that it would cause LINK to exit with
an error-level status that could be detected within a build procedure.)

[Craig A. Berry]

On 9/10/21 12:35 PM, Simon Clubley wrote:
> On 2021-09-09, Craig A. Berry <craig...@nospam.mac.com> wrote:


>> I still routinely see warnings with the ancient DEC/CPQ/HP/HPE/VSI C
>> compiler for code that produces no warnings with current gcc and clang.
>
> Interesting. Are they "genuine" warnings or nonsense type warnings ?

Here's one from last week:

CC/DECC /Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=.obj
/NOANSI_ALIAS/float=ieee/ieee=denorm/NAMES=(SHORTENED)/Define=(_USE_STD_STAT=1,"VERSION=""3.16""","XS_VERSION=""3.16""")/Include=([--])/List/Debug/NoOpt
BASE64.c /OBJECT=BASE64.obj

unsigned char uc = index_64[NATIVE_TO_ASCII(*str++)];
............................................^
%CC-W-UNDEFVARMOD, In the initializer for uc, the expression
"(((sizeof(*str++)==1)||((U64)((*str++)|0))==((U8)(*str++))))" modifies
the variable "str" more than once without an intervening sequence point.
This behavior is undefined.
at line number 360 in file D0:[CRAIG.blead.cpan.MIME-Base64]BASE64.c;1


Someone had modified a macro such that its argument was referenced
twice. But some callers of that macro post-incremented the argument.
So presumably the argument could get incremented twice. Or not,
depending on accidents of the implementation. This is in the Perl
sources and gets thrown against gcc and clang dozens of times a day, as
well as MSVC, HP-UX, AIX, and z/OS compilers somewhat less often. And
the VMS compiler whenever I get around to it, which in this case was
about a month after the change had been pushed, during which time no one
else discovered a problem with it.

This was the fix:

<https://github.com/Perl/perl5/commit/231a6d1601b9d335d75c74dc9995dda5e7201103>

[hb]

On 9/10/21 7:41 PM, Simon Clubley wrote:
> On 2021-09-10, Craig A. Berry <craig...@nospam.mac.com> wrote:
>> On 9/10/21 9:32 AM, hb wrote:
>>>
>>> Do you ask for a linker switch (or by default?) to disable image
>>> production in case of a warning?
>>
>> No. I didn't know there was such a switch.
>>
>
> I've just had a look in the online help and I can't find it either.
>
> It could be useful so I would be interested in knowing what that
> qualifier is. (I am assuming that it would cause LINK to exit with
> an error-level status that could be detected within a build procedure.)
>
> Simon.
>

Maybe I didn't make it clear. It would have been better if I had asked,
do you want/need such a qualifier? If implemented, the DCL status code
will/should be an error code, something like ERRORISUE, "completed with
errors".

[dthi...@gmail.com]

> >
> > What do you think ? Should compiler warnings be treated as errors ?
> >

I was assigned to a Fortran-and-C based VMS project a few years ago, with 1.5 million LOC. One day, while analyzing the system for better ways to build and repackage the software, I noticed that all the compiles were done with /NOWARN. The original developers had added /NOWARN to their compilation scripts so that they (quote) "didn't have to see all the nasty warning messages". This had been going on, believe it or not, for 30 years!

When we enabled warnings, we generated 56K warnings in the first full compilation run, many of them quite severe, such as COMMON block variable misalignment, and Jump into the middle of a loop (skipping the loop initialization). This explained some of the "erratic" behavior that had been reported over the years, and that we had never successfully reproduced or diagnosed, as the problems were data-dependent, and we were not allowed to look at customer data or debug on the customer systems.

After 6 months spent by the coders doing remedial warning correction, we found that the customers no longer experienced these "erratic" data-dependent behaviors after installing the remediated software releases.

So yes, I would totally agree that warnings should generally be treated as errors. If the compiler makers see fit to warn you that you are probably making a mistake in your code, then you probably are, and should take another look.

Fortunately, many of the DEC/Compaq/HP/VSI compilers can turn individual compiler warnings on and off during the run with compiler directives or command line qualifiers, so that you can mask out the truly innocent warnings.

David

[plugh]

Compromise on WERROR

TL;DR
> Elver proposed a compromise. "The appropriate usecase for -Werror is therefore compile-test focused builds (often done by developers or CI systems).

https://www.theregister.com/2021/09/08/compromise_linux_kernel_compiler_warnings/

There are never enough volunteers for "... the cleanup work required..."

[plugh]

On Friday, September 10, 2021 at 12:13:55 PM UTC-7, Craig A. Berry wrote:
> On 9/10/21 12:35 PM, Simon Clubley wrote:
> > On 2021-09-09, Craig A. Berry <craig...@nospam.mac.com> wrote:
>
>
> >> I still routinely see warnings with the ancient DEC/CPQ/HP/HPE/VSI C
> >> compiler for code that produces no warnings with current gcc and clang.
> >
> > Interesting. Are they "genuine" warnings or nonsense type warnings ?
> Here's one from last week:
>
> CC/DECC /Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=.obj
> /NOANSI_ALIAS/float=ieee/ieee=denorm/NAMES=(SHORTENED)/Define=(_USE_STD_STAT=1,"VERSION=""3.16""","XS_VERSION=""3.16""")/Include=([--])/List/Debug/NoOpt
> BASE64.c /OBJECT=BASE64.obj
>
> unsigned char uc = index_64[NATIVE_TO_ASCII(*str++)];
> ............................................^
> %CC-W-UNDEFVARMOD, In the initializer for uc, the expression
> "(((sizeof(*str++)==1)||((U64)((*str++)|0))==((U8)(*str++))))" modifies
> the variable "str" more than once without an intervening sequence point.
> This behavior is undefined.
> at line number 360 in file D0:[CRAIG.blead.cpan.MIME-Base64]BASE64.c;1
>

> .
.
.
.
Which is like 2 VAX instructions and 3 addressing modes?

[Bob Gezelter]

Simon,

I generally also treat "warnings" as errors for the purpose of whether code is "clean".

Long, long ago, I discovered that almost all warnings were easily correctable and were often indicative of a problematic code segments.

An example was FORTRAN's implicit define "feature". One of the earliest FORTRAN compilers I encountered (maybe WATFIV), had a warning for variables that were rarely used, perhaps once. The most likely cause was a keyboarding error.

As reported it is far easier to fix a compiler warning than to debug an error.

I have compiled code with significant numbers of warnings. One never knows whether the warning is an issue, or a minor quirk. Worse, if one has large numbers of warnings, it becomes difficult to separate the real issues from the noise.

- Bob Gezelter, http://www.rlgsc.com

[Simon Clubley]

On 2021-09-10, Craig A. Berry <craig...@nospam.mac.com> wrote:
>
> Someone had modified a macro such that its argument was referenced
> twice. But some callers of that macro post-incremented the argument.
> So presumably the argument could get incremented twice. Or not,
> depending on accidents of the implementation. This is in the Perl
> sources and gets thrown against gcc and clang dozens of times a day, as
> well as MSVC, HP-UX, AIX, and z/OS compilers somewhat less often. And
> the VMS compiler whenever I get around to it, which in this case was
> about a month after the change had been pushed, during which time no one
> else discovered a problem with it.
>

Thanks Craig.

It wasn't clear from your original posting if you were complaining
about useless warnings being reported by DEC C or if DEC C was finding
things that other compilers had missed.

It's very clearly the latter and shows why monocultures (once again)
can be bad.

It's a pity that we can't run the Linux source code through the DEC C
compiler and see if it finds something. If it found a vulnerability,
that could be a nice little piece of PR for VSI.

OTOH, going the other way, I wonder if the LLVM compilers (with the
normal LLVM frontends instead of hybrid GEM frontend/LLVM backend)
will find things in the VMS source code that DEC C might have missed.

[Simon Clubley]

On 2021-09-10, hb <end...@inter.net> wrote:
> On 9/10/21 7:41 PM, Simon Clubley wrote:
>> On 2021-09-10, Craig A. Berry <craig...@nospam.mac.com> wrote:
>>> On 9/10/21 9:32 AM, hb wrote:
>>>>
>>>> Do you ask for a linker switch (or by default?) to disable image
>>>> production in case of a warning?
>>>
>>> No. I didn't know there was such a switch.
>>>
>>
>> I've just had a look in the online help and I can't find it either.
>>
>> It could be useful so I would be interested in knowing what that
>> qualifier is. (I am assuming that it would cause LINK to exit with
>> an error-level status that could be detected within a build procedure.)
>>
>

> Maybe I didn't make it clear. It would have been better if I had asked,
> do you want/need such a qualifier? If implemented, the DCL status code
> will/should be an error code, something like ERRORISUE, "completed with
> errors".

I see. Yes, that would be something very useful to have, but it must
_not_ complete, in the form of actually generating an executable (even
with an error status), as that would defeat much of the benefit.

The reason for that is that it would satisfy the current dependency for
whatever make tool you are using, so make would move onto the next
target instead of retrying the failed target when you ran make again.

[Simon Clubley]

On 2021-09-12, Bob Gezelter <geze...@rlgsc.com> wrote:
>
> As reported it is far easier to fix a compiler warning than to debug an error.
>

Which is exactly the mindset in languages such as Ada, only they are
errors, not warnings, most of the time in Ada. :-) It is a mindset
I agree with.

Those who comment (or complain) about the Rust compiler being fussy
have clearly never written any code in Ada... :-)

[hb]

As said before, if the linker encounters an error it will not generate
an image file. So *IF* this is implemented and a warning is promoted to
an error, you will not get an image file. As usual, the linker tries to
continue linking and producing a map file, if requested, to help
resolving the warning/error.

[John Reagan]

On Sunday, September 12, 2021 at 9:04:00 AM UTC-4, Simon Clubley wrote:
>
> OTOH, going the other way, I wonder if the LLVM compilers (with the
> normal LLVM frontends instead of hybrid GEM frontend/LLVM backend)
> will find things in the VMS source code that DEC C might have missed.

Compiler(S) plural?

Are you asking could we take OpenVMS C source code and run it through the clang
compiler in "C mode"? That probably won't work in general as the code often uses
features not in clang (#pragma linkage, /STANDARD=VAXC, etc.). There might
be some C code that doesn't rely on such things that could be compiled with
"clang-in-C-mode" but I haven't thought that far into the future.

[Simon Clubley]

On 2021-09-13, John Reagan <xyzz...@gmail.com> wrote:
> On Sunday, September 12, 2021 at 9:04:00 AM UTC-4, Simon Clubley wrote:
>>
>> OTOH, going the other way, I wonder if the LLVM compilers (with the
>> normal LLVM frontends instead of hybrid GEM frontend/LLVM backend)
>> will find things in the VMS source code that DEC C might have missed.
>
> Compiler(S) plural?
>

Yes, although I should have expanded on the explicit reference to DEC C.
Don't you have Fortran code within the VMS code base ?

I did think of Pascal as well but I don't think there's a production-ready
Pascal frontend for LLVM, although Free Pascal appears to be doing some
initial work with LLVM.

> Are you asking could we take OpenVMS C source code and run it through the clang
> compiler in "C mode"? That probably won't work in general as the code often uses
> features not in clang (#pragma linkage, /STANDARD=VAXC, etc.). There might
> be some C code that doesn't rely on such things that could be compiled with
> "clang-in-C-mode" but I haven't thought that far into the future.
>

Yes, that's what I was thinking of, and the same for any Fortran code
as well as any Pascal code _if_ there turned out to be a version of
Pascal for LLVM after all that supports the VMS Pascal syntax.

[Simon Clubley]

On 2021-09-13, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> On 2021-09-13, John Reagan <xyzz...@gmail.com> wrote:
>> On Sunday, September 12, 2021 at 9:04:00 AM UTC-4, Simon Clubley wrote:
>>>
>>> OTOH, going the other way, I wonder if the LLVM compilers (with the
>>> normal LLVM frontends instead of hybrid GEM frontend/LLVM backend)
>>> will find things in the VMS source code that DEC C might have missed.
>>
>> Compiler(S) plural?
>>
>
> Yes, although I should have expanded on the explicit reference to DEC C.
> Don't you have Fortran code within the VMS code base ?
>

BTW, it looks like you will be bringing the first ever COBOL compiler
to LLVM although I suspect VSI will not be able to release the COBOL
frontend source code.

[Arne Vajhøj]

On 9/13/2021 1:53 PM, Simon Clubley wrote:
> On 2021-09-13, John Reagan <xyzz...@gmail.com> wrote:
>> On Sunday, September 12, 2021 at 9:04:00 AM UTC-4, Simon Clubley wrote:
>>> OTOH, going the other way, I wonder if the LLVM compilers (with the
>>> normal LLVM frontends instead of hybrid GEM frontend/LLVM backend)
>>> will find things in the VMS source code that DEC C might have missed.
>>
>> Compiler(S) plural?
>>
>
> Yes, although I should have expanded on the explicit reference to DEC C.
> Don't you have Fortran code within the VMS code base ?
>
> I did think of Pascal as well but I don't think there's a production-ready
> Pascal frontend for LLVM, although Free Pascal appears to be doing some
> initial work with LLVM.

Current status:

https://wiki.freepascal.org/LLVM

>> Are you asking could we take OpenVMS C source code and run it through the clang
>> compiler in "C mode"? That probably won't work in general as the code often uses
>> features not in clang (#pragma linkage, /STANDARD=VAXC, etc.). There might
>> be some C code that doesn't rely on such things that could be compiled with
>> "clang-in-C-mode" but I haven't thought that far into the future.
>>
>
> Yes, that's what I was thinking of, and the same for any Fortran code
> as well as any Pascal code _if_ there turned out to be a version of
> Pascal for LLVM after all that supports the VMS Pascal syntax.

VMS Pascal would require VSI to do something.

Apple/Borland/FPC went in a different direction.

Arne

[Arne Vajhøj]

On 9/13/2021 2:00 PM, Simon Clubley wrote:
> On 2021-09-13, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>> On 2021-09-13, John Reagan <xyzz...@gmail.com> wrote:
>>> On Sunday, September 12, 2021 at 9:04:00 AM UTC-4, Simon Clubley wrote:
>>>>
>>>> OTOH, going the other way, I wonder if the LLVM compilers (with the
>>>> normal LLVM frontends instead of hybrid GEM frontend/LLVM backend)
>>>> will find things in the VMS source code that DEC C might have missed.
>>>
>>> Compiler(S) plural?
>>
>> Yes, although I should have expanded on the explicit reference to DEC C.
>> Don't you have Fortran code within the VMS code base ?
>
> BTW, it looks like you will be bringing the first ever COBOL compiler
> to LLVM although I suspect VSI will not be able to release the COBOL
> frontend source code.

Those wanting to cheat could use GNU Cobol to translate
Cobol to C and then compile the C code with CLang.

Arne

[Robert A. Brooks]

On 9/13/2021 2:00 PM, Simon Clubley wrote:

> BTW, it looks like you will be bringing the first ever COBOL compiler
> to LLVM although I suspect VSI will not be able to release the COBOL
> frontend source code.

The front ends are all mostly common code (they may be 100% common code, but
I'll hedge my bets).

Even if we released the front ends, without Gem itself and the Gem-to-LLVM shim,
it's be of little use.

We are not releasing the front ends.

--
-- Rob

[Simon Clubley]

Somehow, I thought that would be the answer... :-)

[plugh]

On Monday, September 13, 2021 at 11:00:36 AM UTC-7, Simon Clubley wrote:
> On 2021-09-13, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> BTW, it looks like you will be bringing the first ever COBOL compiler
> to LLVM although I suspect VSI will not be able to release the COBOL
> frontend source code.
> Simon.
>

The GnuCOBOL transpiler predates VSI's effort. There might be others.

[John Reagan]

On Monday, September 13, 2021 at 1:53:35 PM UTC-4, Simon Clubley wrote:
> On 2021-09-13, John Reagan <xyzz...@gmail.com> wrote:
> > On Sunday, September 12, 2021 at 9:04:00 AM UTC-4, Simon Clubley wrote:
> >>
> >> OTOH, going the other way, I wonder if the LLVM compilers (with the
> >> normal LLVM frontends instead of hybrid GEM frontend/LLVM backend)
> >> will find things in the VMS source code that DEC C might have missed.
> >
> > Compiler(S) plural?
> >
> Yes, although I should have expanded on the explicit reference to DEC C.
> Don't you have Fortran code within the VMS code base ?

No. There is some in the automated testing environment however.

>
> I did think of Pascal as well but I don't think there's a production-ready
> Pascal frontend for LLVM, although Free Pascal appears to be doing some
> initial work with LLVM.
> > Are you asking could we take OpenVMS C source code and run it through the clang
> > compiler in "C mode"? That probably won't work in general as the code often uses
> > features not in clang (#pragma linkage, /STANDARD=VAXC, etc.). There might
> > be some C code that doesn't rely on such things that could be compiled with
> > "clang-in-C-mode" but I haven't thought that far into the future.
> >
> Yes, that's what I was thinking of, and the same for any Fortran code
> as well as any Pascal code _if_ there turned out to be a version of
> Pascal for LLVM after all that supports the VMS Pascal syntax.
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.

I don't get all the hate for the GEM-to-CIL converter. Compilers are full of transformations
between intermediate forms. What are you worried about?

[John Reagan]

No, somebody else has already done a COBOL. I've talked to them about DWARF stuff.

However, we might have the first BASIC attached to LLVM.

[John Reagan]

Makes it hard to debug

[John Reagan]

They aren't ours to release. Again, VSI *LICENSES* the code from HPE. While I'm not
a lawyer, the copyright statement in the code we got from HPE is pretty clear (I've posted
that before). While I don't have a problem with open-sourcing the code, we need HPE's
permission.

[Dave Froble]

Ah, a worthy endeavor ...

But I do hope your statement implies "the first" and not "maybe".


--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[Simon Clubley]

On 2021-09-13, John Reagan <xyzz...@gmail.com> wrote:
>
> I don't get all the hate for the GEM-to-CIL converter. Compilers are full of transformations
> between intermediate forms. What are you worried about?

Hate ???

How did you come to that conclusion from what I have been saying ?

Craig pointed out that DEC C found a problem in the Perl source code
that other compilers missed.

While saying that it's a pity that we couldn't run the Linux source code
through DEC C to see if it found a problem in the Linux source code,
I also wondered if running the VMS source code through the current
LLVM front ends would in turn find any problems in the VMS source code
that the current DEC C compiler might have missed.

That's all this discussion was about.