[QUOTE=kruoli;585405][URL="http://github.com/bbuhrow/yafu/blob/master/yafu-x64.exe"]Here[/URL] it is. :smile:[/QUOTE]Thanks!

I get a SIGSEGV with yafu 2.05 on a Ryzen 3950X under linux built with [CODE]make yafu NFS=1 USE_SSE41=1 USE_AVX2=1 USE_BMI2=1[/CODE] and [CODE]yafu "siqs(1131941884204194473862586294639558925416454742463976786637412462462312690253602905547214801)"[/CODE]The number was generated with rsa(300).

Thanks for the report and testing, I'll look into it. I won't be able to get a revision out until Sunday.

[QUOTE=Brian Gladman;585408]Hi Ben

I spent some time today aligning all the constituent parts of the YAFU Visual Studio 2019 build for windows X64 to use the Microsoft static runtime libraries and I now have a successful build of YAFU. I have tested it on Windows 11 (beta) with the Quadro T2000 GPU on my laptop and all seems to work as expected.

It is available here (yafu, ysieve and ytools):

[url]https://github.com/BrianGladman?tab=repositories[/url]

The build is in the build.vs subdirectory, not build.vc19 (which does not build), as I am in the process of moving it to Visual Studio 2022.

Sadly the build for the siqs_demo project fails because it cannot find these symbols:

1>calc.obj : error LNK2001: unresolved external symbol siqsbench
1>calc.obj : error LNK2001: unresolved external symbol smallmpqs
1>calc.obj : error LNK2001: unresolved external symbol SIQS
1>siqs_demo.obj : error LNK2001: unresolved external symbol get_computer_info

I would be grateful for your advice on where these should be available.[/QUOTE]

Fantastic thank you Brian! I think siqs demo just needs some project properties work. I'll look into that this weekend.

[QUOTE=Gimarel;585416]I get a SIGSEGV with yafu 2.05 on a Ryzen 3950X under linux built with [CODE]make yafu NFS=1 USE_SSE41=1 USE_AVX2=1 USE_BMI2=1[/CODE] and [CODE]yafu "siqs(1131941884204194473862586294639558925416454742463976786637412462462312690253602905547214801)"[/CODE][/QUOTE]

In case it's helpful in diagnosing the issue, I couldn't reproduce this crash on an i5-8500 with the same build flags.

[QUOTE=charybdis;585428]In case it's helpful in diagnosing the issue, I couldn't reproduce this crash on an i5-8500 with the same build flags.[/QUOTE]

Unable to reproduce on 5600X with same build flags as well.

P.S. YAFU 2.05 from the github repository's "yafu-x64.exe" was crashing upon starting a SIQS factorization. Unable to get logs for the next few days, but I am available to answer more questions if there are any regarding my setup.

[QUOTE=Gimarel;585416]I get a SIGSEGV with yafu 2.05 on a Ryzen 3950X under linux built with [CODE]make yafu NFS=1 USE_SSE41=1 USE_AVX2=1 USE_BMI2=1[/CODE][/QUOTE]

Further testing showed, that the number doesn't matter. yafu crashes every time with siqs(rsa(215)), most of the time with siqs(rsa(214)) but runs every time with siqs(rsa(213)).
Also note that yafu works if I omit USE_AVX2=1.

I'm using gcc-10 of debian bullseye.

Here's a complete log:[CODE]yafu "siqs(rsa(215))"

YAFU Version 2.05
Built with GCC 10
Using GMP-ECM 7.0.5-dev, Powered by GMP 6.2.1
Detected AMD Ryzen 9 3950X 16-Core Processor
Detected L1 = 32768 bytes, L2 = 67108864 bytes, CL = 64 bytes
Using 1 random witness for Rabin-Miller PRP checks
Cached 664579 primes; max prime is 9999991

===============================================================
======= Welcome to YAFU (Yet Another Factoring Utility) =======
======= bbuhrow@gmail.com =======
======= Type help at any time, or quit to quit =======
===============================================================

>>
starting SIQS on c65: 31635638050360383928410741313802727069876274264595430910292999519

==== sieve params ====
n = 67 digits, 221 bits
factor base: 6384 primes (max prime = 137117)
single large prime cutoff: 10283775 (75 * pmax)
allocating 3 large prime slices of factor base
buckets hold 2048 elements
large prime hashtables have 196608 bytes
using AVX2 enabled 32k sieve core
sieve interval: 4 blocks of size 32768
polynomial A has ~ 8 factors
using multiplier of 71
using Q2(x) polynomials for kN mod 8 = 1
using SPV correction of 21 bits, starting at offset 32
trial factoring cutoff at 75 bits

==== sieving in progress (1 thread): 6448 relations needed ====
==== Press ctrl-c to abort and save state ====
Segmentation fault[/CODE]gdb backtrace:
[CODE]#0 0x000055555558aee1 in nextRoots_32k_avx2 (sconf=<optimized out>, dconf=0x555557fa3710) at factor/qs/update_poly_roots_32k_avx2.c:1506
#1 0x0000555555575da6 in process_poly (vptr=vptr@entry=0x5555578fed60) at factor/qs/SIQS.c:1292
#2 0x000055555557d368 in SIQS (fobj=fobj@entry=0x5555578f5ef0) at factor/qs/SIQS.c:828
#3 0x000055555556c414 in feval (funcnum=funcnum@entry=59, nargs=nargs@entry=1, metadata=metadata@entry=0x7fffffffd030) at top/cmdParser/calc.c:2559
#4 0x000055555556e0c6 in calc (in=in@entry=0x7fffffffce90, metadata=metadata@entry=0x7fffffffd030) at top/cmdParser/calc.c:1946
#5 0x000055555556e364 in calc_with_assignment (in=in@entry=0x5555578fce60, metadata=metadata@entry=0x7fffffffd030, force_quiet=force_quiet@entry=0) at top/cmdParser/calc.c:1526
#6 0x000055555556a421 in process_expression (input_exp=<optimized out>, metadata=metadata@entry=0x7fffffffd030, force_quiet=0, no_convert_result=no_convert_result@entry=0) at top/cmdParser/calc.c:1472
#7 0x000055555555a850 in main (argc=<optimized out>, argv=<optimized out>) at top/driver.c:366[/CODE]Crashing instruction:

[CODE]│ 0x55555558aed3 <nextRoots_32k_avx2+10563> mov 0x28(%rsi),%r14 │
│ 0x55555558aed7 <nextRoots_32k_avx2+10567> vmovdqa (%rdi,%r15,4),%ymm3 │
│ 0x55555558aedd <nextRoots_32k_avx2+10573> mov 0x30(%rsi),%r13 │
│ >0x55555558aee1 <nextRoots_32k_avx2+10577> vmovdqa (%r14,%r15,4),%ymm1 │
│ 0x55555558aee7 <nextRoots_32k_avx2+10583> vpaddd %ymm3,%ymm1,%ymm1 │
│ 0x55555558aeeb <nextRoots_32k_avx2+10587> vmovdqa 0x0(%r13,%r15,4),%ymm2 │
│ 0x55555558aef2 <nextRoots_32k_avx2+10594> mov 0x20(%rsi),%rdi │
[/CODE]

[QUOTE=Gimarel;585452]Further testing showed, that the number doesn't matter. yafu crashes every time with siqs(rsa(215)), most of the time with siqs(rsa(214)) but runs every time with siqs(rsa(213)).
Also note that yafu works if I omit USE_AVX2=1.

I'm using gcc-10 of debian bullseye.
[/QUOTE]

Thanks for the detailed info. Looks like gcc-10 is having problems aligning some data, which comes into play once input numbers are big enough to start using avx2 inline assembly. There may be gcc options that force alignment, or you can not use avx2, as you discovered, which is probably the best option for now. I have not seen the same problems with icc or gcc-11.1.0 or gcc-7.3.0. Sorry I can't be of more help.

[QUOTE=Plutie;585429]Unable to reproduce on 5600X with same build flags as well.

P.S. YAFU 2.05 from the github repository's "yafu-x64.exe" was crashing upon starting a SIQS factorization. Unable to get logs for the next few days, but I am available to answer more questions if there are any regarding my setup.[/QUOTE]

[QUOTE=johnadam74;585381]I downloaded the most recent version 2.05 for Windows. That version is still crashing for me. When I try to run it as yafu-x64.exe, it will open to ">>" where you can enter a command such as factor(123456) but it crashes before I can enter anything.[/QUOTE]

Can either of you post the siqs output (or whatever output you get) with -v and -vproc?

[QUOTE=bsquared;585795]Thanks for the detailed info. Looks like gcc-10 is having problems aligning some data, which comes into play once input numbers are big enough to start using avx2 inline assembly. There may be gcc options that force alignment, or you can not use avx2, as you discovered, which is probably the best option for now. I have not seen the same problems with icc or gcc-11.1.0 or gcc-7.3.0. Sorry I can't be of more help.[/QUOTE]

This must be very specific to gcc-10: I was using 9.3.0 when I tried and failed to reproduce this. Looks like installing a second gcc version (with the necessary care, of course) would be an alternative solution to the problem.

[QUOTE=charybdis;585798]This must be very specific to gcc-10: I was using 9.3.0 when I tried and failed to reproduce this. Looks like installing a second gcc version (with the necessary care, of course) would be an alternative solution to the problem.[/QUOTE]
I'm getting the same SEGFAULT with gcc-9. I will try to install gcc-11, but this will take some time.

I also tried clang-11 but the build fails with:[CODE]clang-11 -g -DUSE_SSE2 -mbmi2 -mbmi -DUSE_BMI2 -DUSE_AVX2 -DUSE_SSE41 -mavx2 -DUSE_SSE41 -m64 -msse4.1 -DUSE_NFS -O3 -march=native -mtune=native -fomit-frame-pointer -Wall -I. -Iinclude -Itop/aprcl -Itop/cmdParser -Itop/ -I../../../msieve -I../ysieve -I../ytools -I../../ecm -I../gmp/include -I../gmp-ecm/include/ -c -o factor/qs/msieve/lanczos.o factor/qs/msieve/lanczos.c
In file included from factor/qs/msieve/lanczos.c:18:
In file included from include/lanczos.h:21:
In file included from include/qs_impl.h:20:
include/monty.h:145:19: error: invalid input constraint '0ULL' in asm
: "1"(c), "0ULL"(0), "r"(n));
^
1 error generated.
make: *** [Makefile:450: factor/qs/msieve/lanczos.o] Fehler 1
[/CODE]