grep 3.1 regression

[Furniel]

After msys2 update i686 mingw gcc build tests began to fall with error:

terminate called after throwing an instance of 'int'
terminate called recursively

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

I've managed to track down that grep update from 3.0 to 3.1 causes this problem.

On the other hand, after comparison of build logs, i found out than for some gcc libs libtool generates wrong configs:
grep 3.0:

# Dependencies to place before and after the objects being linked to
# create a shared library.
predep_objects="C:/msys64/mingw32/i686-w64-mingw32/lib/dllcrt2.o C:/temp/i686-8b-posix-dwarf-rt_v5/build/gcc-8-branch/gcc/crtbegin.o"
postdep_objects="C:/temp/i686-8b-posix-dwarf-rt_v5/build/gcc-8-branch/gcc/crtend.o"
predeps=""
postdeps="-lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -lpthread -ladvapi32 -lshell32 -luser32 -lkernel32 -liconv -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt"

grep 3.1

# Dependencies to place before and after the objects being linked to
# create a shared library.
predep_objects="C:/msys64/mingw32/i686-w64-mingw32/lib/dllcrt2.o C:/temp/i686-8b-posix-dwarf-rt_v5/build/gcc-8-branch/gcc/crtbegin.o"
postdep_objects=""
predeps=""
postdeps="-lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -lpthread -ladvapi32 -lshell32 -luser32 -lkernel32 -liconv -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt"

Looks like real cause of the problem is one of this changes in grep 3.1:

The following changes affect only MS-Windows platforms.  First, the
  --binary (-U) option now governs whether binary I/O is used, instead
  of a heuristic that was sometimes incorrect.  Second, the
  --unix-byte-offsets (-u) option now has no effect on MS-Windows too.

[Alexpux]

This is upstream grep changes:
http://git.savannah.gnu.org/cgit/grep.git/commit/?id=5ac3d87a69122d45a837840914c2f9e66b5bb8d4

[Furniel]

Some new info about this bug.
I wrote script that dumps grep args, stdin and stdout:

#!/bin/bash
indata=`timeout 15 cat`
grep3binary=grep3.exe
grep31binary=grep31.exe
grep3outfile=/a/grep3.txt
grep31outfile=/a/grep31.txt
echo args: "$@" >> "$grep3outfile"
[[ -n "$indata" ]] && echo stdin: "$indata" >> "$grep3outfile"
echo output: >> "$grep3outfile"
[[ -n "$indata" ]] && ( echo "$indata" | "$grep3binary" "$@" >> "$grep3outfile" 2>> "$grep3outfile" ) || ( "$grep3binary" "$@" >> "$grep3outfile" 2>> "$grep3outfile" )
echo args: "$@" >> "$grep31outfile"
[[ -n "$indata" ]] && echo stdin: "$indata" >> "$grep31outfile"
echo output: >> "$grep31outfile"
[[ -n "$indata" ]] && ( echo "$indata" | "$grep31binary" "$@" >> "$grep31outfile" 2>> "$grep31outfile" ) || ( "$grep31binary" "$@" >> "$grep31outfile" 2>> "$grep31outfile" )

[[ -n "$indata" ]] && ( echo "$indata" | "$grep3binary" "$@" ) || ( "$grep3binary" "$@" )

Dumped all info and all info in grep 3 and grep 3.1 logs is the same(except grep version numbers), but when i switch binary to 3.1 i'm getting bug again. Tested on libstdc++-v3, the only difference is config.status and libtool files.
grep3.log
grep31.log
libstdc++-v3_grep3.zip
libstdc++-v3_grep31.zip

I don't know how it's possible to get same dumps, but different configs for different grep versions. Maybe i should dump some other info?

[Alexpux]

@Furniel no need any info. I send you link for changes. I dont plan to look at this issue at near time. Feel free to create patch and sent pull requrest

[Alexpux]

grep downgraded in repo to 3.0