[Bug c/67651] New: Optimizer assumes nothing can reside at address 0 despite -fno-delete-null-pointer-checks

[Bug c/67651] New: Optimizer assumes nothing can reside at address 0 despite -fno-delete-null-pointer-checks

[soren.brinkmann at xilinx dot com]

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

            Bug ID: 67651
           Summary: Optimizer assumes nothing can reside at address 0
                    despite -fno-delete-null-pointer-checks
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: soren.brinkmann at xilinx dot com
  Target Milestone: ---

Created attachment 36351
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36351&action=edit
Test case source

For the c source:
extern unsigned int _vector_table;

int main(void)
{
        unsigned int *vector_base = &_vector_table;

        if (vector_base == 0) {
                return 1;
        } else {
                return 2;
        }
}


the generated code is, when compiled with '-O2
-fno-delete-null-pointer-checks':
0000000000000000 <main>:
   0:   b8 02 00 00 00          mov    $0x2,%eax
   5:   c3                      retq


I.e. the if branch is completely removed from the final object.
The behavior is consistent across the gcc versions I could test (4.7, 4.9 for
ARMv7 and 4.9, 5.2 for x86_64)

The behavior has been discussed on the list
(http://thread.gmane.org/gmane.comp.gcc.devel/141346). One workaround/fix
mentioned there is to add the 'weak' attribute to '_vector_table'. But it seems
that '-fno-delete-null-pointer-checks' is supposed to remove the assumption
regarding objects at address 0 and should be sufficient to generate "correct"
code.

For completeness, this is a Makefile to compile the test case:
CC ?= gcc
OBJDUMP = objdump
CFLAGS = -Wall -Wextra -fno-delete-null-pointer-checks -O2
-fno-delete-null-pointer-checks

SRC = main.c

all: $(SRC:.c=.dump) $(SRC:.c=.s) $(SRC:.c=.o)

%.dump: %.o
        $(OBJDUMP) -DS $< > $@

%.s: %.c
        $(CC) $(CFLAGS) -S $< -o $@

%.o: %.c
        $(CC) $(CFLAGS) -c $< -o $@

.PHONY: clean
clean:
        rm -rf *.o *.s *.dump

[Bug c/67651] Optimizer assumes nothing can reside at address 0 despite -fno-delete-null-pointer-checks

[soren.brinkmann at xilinx dot com]

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

--- Comment #1 from Sören Brinkmann <soren.brinkmann at xilinx dot com> ---
Created attachment 36352
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36352&action=edit
Makefile for the test case
>From gcc-bugs-return-497614-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Sep 20 16:29:19 2015
Return-Path: <gcc-bugs-return-497614-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 33281 invoked by alias); 20 Sep 2015 16:29:19 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 33242 invoked by uid 48); 20 Sep 2015 16:29:15 -0000
From: "pinskia at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/67650] undef reference with -fdevirtualize
Date: Sun, 20 Sep 2015 16:29:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 5.2.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pinskia at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-67650-4-OVVXzeGz61@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67650-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67650-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-09/txt/msg01592.txt.bz2
Content-length: 380

https://gcc.gnu.org/bugzilla/show_bug.cgi?idg650

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> Is it worth it to try reducing my code and produce a code snippet exhibiting the issue?

Always.

>Or is the issue known already? I didn't find any track of it.

It could also be a bug in your code too.  Devirtualization is known to expose
invalid code too.

[Bug middle-end/67651] Optimizer assumes nothing can reside at address 0 despite -fno-delete-null-pointer-checks

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2015-09-21
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
We optimize this since GCC 3.4 and -fno-delete-null-pointer-checks already
doesn't have any effect on that.  GCC 3.3 wasn't able to optimize this with
any setting of this flag.

@item -fdelete-null-pointer-checks
@opindex fdelete-null-pointer-checks
Assume that programs cannot safely dereference null pointers, and that
no code or data element resides at address zero.
This option enables simple constant
folding optimizations at all optimization levels.  In addition, other
optimization passes in GCC use this flag to control global dataflow
analyses that eliminate useless checks for null pointers; these assume
that a memory access to address zero always results in a trap, so
that if a pointer is checked after it has already been dereferenced,
it cannot be null.

Note however that in some environments this assumption is not true.
Use @option{-fno-delete-null-pointer-checks} to disable this optimization
for programs that depend on that behavior.

This option is enabled by default on most targets.  On Nios II ELF, it
defaults to off.  On AVR and CR16, this option is completely disabled.


so confirmed.  Note that GIMPLE optimizers are fine and we end up expanding
from

main ()
{
  int _1;

  <bb 2>:
  if (&_vector_table == 0B)
    goto <bb 4>;
  else
    goto <bb 3>;

  <bb 3>:

  <bb 4>:
  # _1 = PHI <1(2), 2(3)>
  return _1;

But RTL generation already fucks this up:

;; Generating RTL for gimple basic block 2

;; if (&_vector_table == 0B)

(nil)

...

;;
;; Full RTL generated for this function:
;;
(note 1 0 5 NOTE_INSN_DELETED)
;; basic block 2, loop depth 0, count 0, freq 10000, maybe hot
;;  prev block 0, next block 1, flags: (NEW, REACHABLE, RTL, MODIFIED)
;;  pred:       ENTRY [100.0%]  (FALLTHRU)
(note 5 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(note 2 5 4 2 NOTE_INSN_FUNCTION_BEG)
(insn 4 2 10 2 (set (reg:SI 87 [ D.1844 ])
        (const_int 2 [0x2])) t.c:10 -1
     (nil))
(insn 10 4 14 2 (set (reg:SI 88 [ <retval> ])
        (reg:SI 87 [ D.1844 ])) -1
     (nil))
(insn 14 10 15 2 (set (reg/i:SI 0 ax)
        (reg:SI 88 [ <retval> ])) t.c:12 -1
     (nil))
(insn 15 14 0 2 (use (reg/i:SI 0 ax)) t.c:12 -1
     (nil))
;;  succ:       EXIT [100.0%]  (FALLTHRU)


Because of

simplify_const_relational_operation (code=EQ, mode=DImode, op0=0x7ffff6a06168, 
    op1=0x7ffff68d3480)
    at /space/rguenther/src/svn/trunk/gcc/simplify-rtx.c:4840
5088          /* Some addresses are known to be nonzero.  We don't know
5089             their sign, but equality comparisons are known.  */
5090          if (nonzero_address_p (trueop0))
5091            {
5092              if (code == EQ || code == LEU)
5093                return const0_rtx;

on (symbol_ref:DI ("_vector_table") [flags 0x40] <var_decl 0x7ffff68d8c60
_vector_table>)

/* Return true if X is an address that is known to not be zero.  */

bool
nonzero_address_p (const_rtx x)
{
  const enum rtx_code code = GET_CODE (x);

  switch (code)
    {
    case SYMBOL_REF:
      return !SYMBOL_REF_WEAK (x);

which misses a check on flag_delete_null_pointer_checks.  Fixing that fixes the
bug.

[Bug middle-end/67651] Optimizer assumes nothing can reside at address 0 despite -fno-delete-null-pointer-checks

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
      Known to work|                            |6.0
         Resolution|---                         |FIXED

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.

[Bug middle-end/67651] Optimizer assumes nothing can reside at address 0 despite -fno-delete-null-pointer-checks

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Mon Sep 21 12:33:23 2015
New Revision: 227968

URL: https://gcc.gnu.org/viewcvs?rev=227968&root=gcc&view=rev
Log:
2015-09-21  Richard Biener  <rguenther@suse.de>

        PR middle-end/67651
        * rtlanal.c (nonzero_address_p): SYMBOL_REFs may have zero
        address with -fno-delete-null-pointer-checks.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/rtlanal.c