[Bug c/97215] New: Possible fread() malfunction of GCC 7.3.0 (Windows)

[Bug c/97215] New: Possible fread() malfunction of GCC 7.3.0 (Windows)

[sanmayce at sanmayce dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97215

            Bug ID: 97215
           Summary: Possible fread() malfunction of GCC 7.3.0 (Windows)
           Product: gcc
           Version: 7.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: sanmayce at sanmayce dot com
  Target Milestone: ---

Hi, 
a C coder here.

Regarding a C source loading an entire 3.3GB file and checksumming it.

First, I use Intel v15.0 and GCC v7.3.0, on Windows 64bit.
For my dismay I encountered that Intel's binary loads and reports the correct
checksum, whereas GCC's binary fails, after comparing the loaded content I saw
that GCC loads all the file into a malloc-ed pool but without the last ~860
bytes?!

If you need to reproduce the issue - the two binaries (GCC and Intel) and the C
source as well are here:
http://www.sanmayce.com/Nakamichi/Nakamichi_Kaidanji.zip

The file being loaded is the Human Genome:
ftp://ftp.ncbi.nlm.nih.gov/genomes/all/GCA/000/001/405/GCA_000001405.28_GRCh38.p13/GCA_000001405.28_GRCh38.p13_genomic.fna.gz

This bug never appeared with files 1GB or less in size, my guess, this is a
clue.

These are the files:

```
06/11/2020  09:16 AM         1,316,439 Nakamichi_Ryuugan-ditto-1TB_btree.c
06/15/2019  02:37 AM     3,313,087,324
NCBI_FTP_Homo_sapiens_(human)_GCA_000001405.28_GRCh38.p13_genomic.fna
06/15/2019  02:37 AM     3,313,087,324 q
01/07/2018  05:26 PM           191,644 Satanichi_GCC730_64bit.exe
06/11/2020  09:16 AM           198,144 Satanichi_ICL150_64bit.exe
```

As you can see below, the same file is loaded differently into malloc-ed pool:

```
D:\Satanichi_aka_Nakamichi_2020-Jun-09>Satanichi_GCC730_64bit.exe q w 20 888 i
...
Allocating Source-Buffer 3,159 MB ...
Allocating Target-Buffer 3,191 MB ...
Source-file-Hash(FNV1A_YoshimitsuTRIAD) = 0xc1d4,3f7f
...
D:\Satanichi_aka_Nakamichi_2020-Jun-09>

D:\Satanichi_aka_Nakamichi_2020-Jun-09>Satanichi_ICL150_64bit.exe q w 20 888 i
Allocating Source-Buffer 3,159 MB ...
Allocating Target-Buffer 3,191 MB ...
Source-file-Hash(FNV1A_YoshimitsuTRIAD) = 0x81bd,fe4b
...
D:\Satanichi_aka_Nakamichi_2020-Jun-09>
```

If you need more info, will add it...
Very much I would like to know what causes this anomaly/bug.

Georgi

[Bug c/97215] Possible fread() malfunction of GCC 7.3.0 (Windows)

[sanmayce at sanmayce dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97215

--- Comment #1 from Georgi <sanmayce at sanmayce dot com> ---
Oops, here are the mentioned files:
www.sanmayce.com/Nakamichi/Satanichi_aka_Nakamichi_2020-Jun-09_BUG_ZEROED-END.zip

[Bug c/97215] Possible fread() malfunction of GCC 7.3.0 (Windows)

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97215

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
You need b if you don't want \r\n to be turned into just \n.

[Bug c/97215] Possible fread() malfunction of GCC 7.3.0 (Windows)

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97215

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
fopen/fread/fwrite DOES NOT come from GCC, but rather than in this case mingw.

[Bug c/97215] Possible fread() malfunction of GCC 7.3.0 (Windows)

[sanmayce at sanmayce dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97215

--- Comment #4 from Georgi <sanmayce at sanmayce dot com> ---
(In reply to Andrew Pinski from comment #2)
> You need b if you don't want \r\n to be turned into just \n.

At 11,945th line I use:

```
        if ((fp = fopen(argv[1], "rb")) == NULL) {
                printf("Nakamichi: Can't open '%s' file.\n", argv[1]);
exit(13);
        }
```

As far as I investigated, the problem is that fread() reads less (around 860
bytes) than specified, after decompression I see those bytes being ASCII 000?!

[Bug c/97215] Possible fread() malfunction of GCC 7.3.0 (Windows)

[sanmayce at sanmayce dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97215

--- Comment #5 from Georgi <sanmayce at sanmayce dot com> ---
(In reply to Andrew Pinski from comment #3)
> fopen/fread/fwrite DOES NOT come from GCC, but rather than in this case
> mingw.

Ugh, thanks, will alert them about this issue by giving the link to this
tracker.