> Have you tested with the amount of coverage provided by vcregress.pl? I built and ran the relevant tests with the help of run_build.pl.
I think following tests are executed - check, contribcheck, ecpgcheck, installcheck, isolationcheck, modulescheck, and upgradecheck. > Another thing I was wondering about is if it would be possible to have > this option in Travis, but that does not seem to be the case: > https://docs.travis-ci.com/user/reference/windows/#windows-version Yes, I think Travis doesn't yet support Windows/Arm64 platform. > + if ($solution->{platform} eq 'ARM64') { > + push(@pgportfiles, 'pg_crc32c_armv8_choose.c'); > + push(@pgportfiles, 'pg_crc32c_armv8.c'); > + } else { > + push(@pgportfiles, 'pg_crc32c_sse42_choose.c'); > + push(@pgportfiles, 'pg_crc32c_sse42.c'); > + } > > +++ b/src/port/pg_crc32c_armv8.c > +#ifndef _MSC_VER > #include <arm_acle.h> > +#endif > [ ... ] > +#ifdef _M_ARM64 > + /* > + * arm64 way of hinting processor for spin loops optimisations > + * ref: https://community.arm.com/support-forums/f/infrastructure-solutions-forum/48654/ssetoneon-faq > + */ > + __isb(_ARM64_BARRIER_SY); > +#else > I think that such extra optimizations had better be in a separate > patch, and we should focus on getting the build done first. > This would mean that a basic patch could be done with just the changes > for gendef.pl, and the first part of the changes inMSBuildProject.pm. > Would that not be enough? I cannot build without any of the above changes. Nothing specific for optimization is added to this patch. > + # arm64 linker only supports dynamic base address > + my $cfgrandbaseaddress = $self->{platform} eq 'ARM64' ? 'true' : 'false'; > This issue is still lying around, and you may have been lucky. Would > there be any issues to remove this change to get a basic support in? > As mentioned upthread, there is a long history of Postgres with ASLR. MSVC linker doesn't allow non-random base addresses for Arm64 platforms. It is needed for basic support. Niyas
