Discussion:
[OT?] Should compiler warnings be treated as errors ?
(too old to reply)
Simon Clubley
2021-09-09 17:52:22 UTC
Permalink
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, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Chris Townley
2021-09-09 18:01:39 UTC
Permalink
Post by Simon Clubley
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
dthi...@gmail.com
2021-09-10 22:05:17 UTC
Permalink
Post by Simon Clubley
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
Arne Vajhøj
2021-09-09 18:23:58 UTC
Permalink
Post by Simon Clubley
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
2021-09-09 20:12:21 UTC
Permalink
Post by Simon Clubley
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
2021-09-10 00:30:11 UTC
Permalink
Post by Simon Clubley
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
2021-09-10 02:17:19 UTC
Permalink
Post by Craig A. Berry
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
2021-09-10 09:28:37 UTC
Permalink
Post by John Reagan
Post by Craig A. Berry
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
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
2021-09-10 12:50:14 UTC
Permalink
Post by hb
Post by John Reagan
Post by Craig A. Berry
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
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.
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.
Post by hb
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
2021-09-10 14:32:59 UTC
Permalink
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
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?
Craig A. Berry
2021-09-10 16:38:45 UTC
Permalink
Post by hb
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
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.
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.
Post by hb
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
2021-09-10 17:41:15 UTC
Permalink
Post by Craig A. Berry
Post by hb
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.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
hb
2021-09-10 20:36:17 UTC
Permalink
Post by Simon Clubley
Post by Craig A. Berry
Post by hb
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".
Simon Clubley
2021-09-12 13:08:46 UTC
Permalink
Post by hb
Post by Simon Clubley
Post by Craig A. Berry
Post by hb
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.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
hb
2021-09-13 10:10:28 UTC
Permalink
Post by Simon Clubley
Post by hb
Post by Simon Clubley
Post by Craig A. Berry
Post by hb
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.
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.
Simon Clubley
2021-09-10 17:35:16 UTC
Permalink
Post by Craig A. Berry
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.
Post by Craig A. Berry
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.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Craig A. Berry
2021-09-10 19:13:51 UTC
Permalink
Post by Simon Clubley
Post by Craig A. Berry
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>
plugh
2021-09-10 22:27:11 UTC
Permalink
Post by Craig A. Berry
Post by Simon Clubley
Post by Craig A. Berry
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 ?
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?
Simon Clubley
2021-09-12 13:03:57 UTC
Permalink
Post by Craig A. Berry
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.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
John Reagan
2021-09-13 15:29:27 UTC
Permalink
Post by Simon Clubley
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
2021-09-13 17:53:33 UTC
Permalink
Post by John Reagan
Post by Simon Clubley
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.
Post by John Reagan
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, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Simon Clubley
2021-09-13 18:00:33 UTC
Permalink
Post by Simon Clubley
Post by John Reagan
Post by Simon Clubley
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.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Robert A. Brooks
2021-09-13 18:07:32 UTC
Permalink
Post by Simon Clubley
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
2021-09-13 18:24:01 UTC
Permalink
Post by Robert A. Brooks
Post by Simon Clubley
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.
Somehow, I thought that would be the answer... :-)

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
John Reagan
2021-09-13 20:45:59 UTC
Permalink
Post by Simon Clubley
Post by Robert A. Brooks
Post by Simon Clubley
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.
Somehow, I thought that would be the answer... :-)
Simon.
--
Walking destinations on a map are further away than they appear.
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.
plugh
2021-09-13 19:24:45 UTC
Permalink
Post by Simon Clubley
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
2021-09-13 20:43:53 UTC
Permalink
Post by Simon Clubley
Post by Simon Clubley
Post by John Reagan
Post by Simon Clubley
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
Makes it hard to debug
Dave Froble
2021-09-13 22:52:00 UTC
Permalink
Post by Simon Clubley
Post by Simon Clubley
Post by John Reagan
Post by Simon Clubley
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.
Simon.
--
Walking destinations on a map are further away than they appear.
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.
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: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2021-09-13 18:02:10 UTC
Permalink
Post by Simon Clubley
Post by John Reagan
Post by Simon Clubley
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
Post by Simon Clubley
Post by John Reagan
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
John Reagan
2021-09-13 20:42:39 UTC
Permalink
Post by Simon Clubley
Post by John Reagan
Post by Simon Clubley
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.
Post by Simon Clubley
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.
Post by John Reagan
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.
--
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?
Simon Clubley
2021-09-14 13:00:48 UTC
Permalink
Post by John Reagan
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.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
plugh
2021-09-10 22:23:59 UTC
Permalink
Post by Simon Clubley
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.
--
Walking destinations on a map are further away than they appear.
Compromise on WERROR

TL;DR
Post by Simon Clubley
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..."
chris
2021-09-10 16:19:46 UTC
Permalink
Post by Simon Clubley
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
Bob Gezelter
2021-09-12 10:27:48 UTC
Permalink
Post by Simon Clubley
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.
--
Walking destinations on a map are further away than they appear.
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
Loading...