24 May
2012
24 May
'12
12:27 p.m.
Stefan,
I know that is probably the case, not arguing that. However someone has
to regularly check and report the errors in some intelligent fashion
back to the compiler group, or they won't get acted upon. If someone
here can do that more the better, but I'm betting that maybe that
platform lacks a champion in the compiler developer group, and it may be
off the radar.
My buddy took up the cause for the c++ boost package as well as the ace
macro set for the S390. The gcc group supports s390, but a lot of the
other open source tool sets like these, not so much.
jim
On 5/23/2012 2:01 PM, Stefan Skoglund wrote:
On Wed, 23 May 2012 12:47:40 -0700, jim s<jws at jwsss.com> wrote:
Probably the best thing to do is reproduce the
problem on an
emulation platform and start reporting the issues to the gcc group. I
doubt that they have access to do builds to do their verification, so
working to be the supporter of the vax with the emulated or real
platform would be the other thing to do.
I don't know if they have automated test suites to test all of this,
but I'd hope the core development group isn't hand testing everything
for regression problems.
The best test suite there is for a compiler:
ITSELF.
The normal workflow when compiling gcc is to have it build itself.
One of the last steps before installation was to check for differences
between
one build of the compiler and the result of the same build iteration
build of itself.