Bug 98070 - [11 Regression] errno is not re-evaluated after clearing errno and calling realloc(ptr, SIZE_MAX)
Summary: [11 Regression] errno is not re-evaluated after clearing errno and calling re...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 11.0
: P3 normal
Target Milestone: 11.0
Assignee: Richard Biener
URL:
Keywords: wrong-code
Depends on:
Blocks:
 
Reported: 2020-11-30 16:32 UTC by stli@linux.ibm.com
Modified: 2023-12-29 01:03 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2020-12-01 00:00:00


Attachments
Testcase reproducing the issue with gcc-head (1.48 KB, text/x-csrc)
2020-11-30 16:32 UTC, stli@linux.ibm.com
Details

Note You need to log in before you can comment on or make changes to this bug.
Description stli@linux.ibm.com 2020-11-30 16:32:54 UTC
Created attachment 49652 [details]
Testcase reproducing the issue with gcc-head

Hi,

After setting errno=0 and calling realloc with a too large size, which sets errno to ENOMEM, a subsequent "if (errno == ENOMEM)" is not evaluated as true.
Instead gcc assumes that errno has not changed and is directly executing the else-path without testing errno again.

This happens in the glibc-testcase:
<glibc>/malloc/tst-malloc-too-large.c test
(see https://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/tst-malloc-too-large.c;h=b5ad7eb7e7bf764fe57ceff5a810e3c211ca05e0;hb=refs/heads/master)
on at least x86_64 and s390x with gcc-head.

The attached small reproducer fails with gcc-head, but not with gcc 10, 9 (before):
/* Output with gcc 11:
   $ ./tst-errno-realloc (build with >= -O1)
   47: errno == 0 (Cannot allocate memory). We are in the else-part of 'if (errno == ENOMEM)'. Does errno correspond to %m or the line below or to '(gdb) p errno'?!
   dump_errno(48, compare to line above!): errno == 12 (Cannot allocate memory) vs main_errno=0

   On s390x:
   $ gcc -v
   Using built-in specs.
   COLLECT_GCC=./install-s390x-head/bin/gcc
   COLLECT_LTO_WRAPPER=/home/stli/gccDir/install-s390x-head/libexec/gcc/s390x-ibm-linux-gnu/11.0.0/lto-wrapper
   Target: s390x-ibm-linux-gnu
   Configured with: /home/stli/gccDir/gcc-head/configure --prefix=/home/stli/gccDir/install-s390x-head/ --enable-shared --with-system-zlib --enable-threads=posix --enable-__cxa_atexit --enable-checking --enable-gnu-indirect-function --enable-languages=c,c++ --with-arch=zEC12 --with-tune=z13 --disable-bootstrap --with-long-double-128 --enable-decimal-float
   Thread model: posix
   Supported LTO compression algorithms: zlib
   gcc version 11.0.0 20201127 (experimental) (GCC)
   $ git log --oneline
   5e9f814d754 (HEAD -> master, origin/master, origin/HEAD) rs6000: Change rs6000_expand_vector_set param

   Also on x86_64:
   $ gcc -v
   Using built-in specs.
   COLLECT_GCC=/home/stli/gccDir/install-x86_64-head/bin/gcc
   COLLECT_LTO_WRAPPER=/home/stli/gccDir/install-x86_64-head/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
   Target: x86_64-pc-linux-gnu
   Configured with: /home/stli/gccDir/gcc-head/configure --prefix=/home/stli/gccDir/install-x86_64-head/ --enable-shared --with-system-zlib --enable-threads=posix --enable-__cxa_atexit --enable-checking --enable-gnu-indirect-function --enable-languages=c,c++ --with-tune=generic --with-arch_32=x86-64 --disable-bootstrap --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --disable-libgcj --disable-multilib
   Thread model: posix
   Supported LTO compression algorithms: zlib zstd
   gcc version 11.0.0 20201130 (experimental) (GCC)
   $ git log --oneline
   a5ad5d5c478 (HEAD -> master, origin/master, origin/HEAD) RISC-V: Always define MULTILIB_DEFAULTS
*/
Comment 1 Andrew Pinski 2020-11-30 23:24:35 UTC
Related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88576 .
Comment 2 Richard Biener 2020-12-01 08:15:03 UTC
Likely caused by

      /* Realloc serves both as allocation point and deallocation point.  */
      case BUILT_IN_REALLOC:
        return ".cw ";

which should be ".Cw "
Comment 3 GCC Commits 2020-12-01 09:43:11 UTC
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:57fcbe579c2f2b0919486b658a5bec8f4e1ef42b

commit r11-5598-g57fcbe579c2f2b0919486b658a5bec8f4e1ef42b
Author: Richard Biener <rguenther@suse.de>
Date:   Tue Dec 1 09:19:52 2020 +0100

    middle-end/98070 - fix realloc builtin fnspec
    
    realloc clobbers errno, note that.
    
    2020-12-01  Richard Biener  <rguenther@suse.de>
    
            PR middle-end/98070
            * builtins.c (builtin_fnspec): realloc is ".Cw ".
Comment 4 Richard Biener 2020-12-01 09:43:23 UTC
Fixed.
Comment 5 stli@linux.ibm.com 2020-12-01 12:23:31 UTC
I've just build and run the attached test on s390x/x86_64 with your fix.
Now errno is re-evaluated after realloc.

I've also rebuild glibc on s390x and the original glibc-test <glibc>/malloc/tst-malloc-too-large.c is now also passing.

Many thanks.