[Bug c/34803] New: wrong code for dereferencing type-punned pointer

[Bug c/34803] New: wrong code for dereferencing type-punned pointer

[gin at mo dot msk dot ru]

No simpler C code is (yet) known to hit this.  On request will
describe actual package where similar code occurs.

In the attached preprocessed code, incorrect arg 3, `%rdx', is passed
to `handle_out_external'.  Code expects this value, `extlen', to be
the same as value that is returned from `__builtin_alloca', stored in
`c', passed to `memcpy' as arg 1.  It is not.  Instead, the following
assembler code is output.

        movq    %rbx, %rdi
        call    memcpy
        movq    -72(%rbp), %rcx
        movq    -40(%rbp), %rdx
        movq    %rbx, -40(%rbp)

It passes in `%rbx' uninitialized value that was in `-40(%rbp)' and
only then writes into `-40(%rbp)' the correct value to pass.

Observing when compiling not only `-O3', but even
`-fno-strict-aliasing -O3 -fno-strict-aliasing'.  In these 2
invocations assembler output is the same.  That is,
`-fno-strict-aliasing' no longer disables optimizations that require
strict aliasing rules in code.  It, however, disables warnings output
when `-Wstrict-aliasing=2' is specified.


-- 
           Summary: wrong code for dereferencing type-punned pointer
           Product: gcc
           Version: 4.2.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: gin at mo dot msk dot ru
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34803

[Bug c/34803] wrong code for dereferencing type-punned pointer

[gin at mo dot msk dot ru]

------- Comment #1 from gin at mo dot msk dot ru  2008-01-15 21:41 -------
Created an attachment (id=14944)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14944&action=view)
preprocessed code in question

Instead of `extptr', uninitialized value is passed to
`handle_out_external'.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34803

[Bug c/34803] wrong code for dereferencing type-punned pointer

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2008-01-15 22:47 -------

  unsigned char *extptr;

      ((aliasing_u) &extptr)->p = c;


Well you are obviously violating c aliasing rules here.  the warning does not
happen is a different issue.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|wrong code for dereferencing|wrong code for dereferencing
                   |type-punned pointer         |type-punned pointer


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34803

[Bug c/34803] wrong code for dereferencing type-punned pointer

[gin at mo dot msk dot ru]

------- Comment #3 from gin at mo dot msk dot ru  2008-01-16 00:49 -------
Subject: Re:  wrong code for dereferencing type-punned pointer

> obviously violating c aliasing rules here.

Certainly.  Was quite explicit about that:

  That is,
  `-fno-strict-aliasing' no longer disables optimizations that require
  strict aliasing rules in code.

To reproduce compiler (still) doing such an optimizations (and
breaking code), one has to violate aliasing rules.


Also confirming that one may factor these separate issues in the report.

. Compiler ignores `-fno-strict-aliasing'.  Expecting that can violate
aliasing rules, and tell compiler to allow that, by passing this
option.  The expectation is based on both option documentation and
earlier gcc versions actually doing so.

. Warning not issued, even when compiler does optimizations that
require code to conform to c strictest aliasing rules.

On request will confine this bug database entry to one of them, and
post another issue as separate bug database entry.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34803

[Bug c/34803] wrong code for dereferencing type-punned pointer

[rguenth at gcc dot gnu dot org]

------- Comment #4 from rguenth at gcc dot gnu dot org  2008-01-16 10:28 -------
Looks good on the trunk.  Also looks good for 4.2.

Can you provide an executable testcase that abort()s if the miscompile happens?


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34803

[Bug c/34803] wrong code for dereferencing type-punned pointer

[gin at mo dot msk dot ru]

------- Comment #5 from gin at mo dot msk dot ru  2008-01-17 17:45 -------
Subject:  test case [Re: wrong code for dereferencing type-punned pointer]

No test case program hitting this wrong code will do something
reliably: the code incorrectness is passing uninitialized value to the
rest of program, so it can no longer `abort ()' or do something else
depending on this value deterministically, reliably.  One can only
talk only about doing so with some reasonable probability.

At least one such program already exist.  Remember, the input was
built after code in actual application.  It was xemacs.  More
precisely, built recent stable version as taken from location in
(mirror) list in
<http://www.xemacs.org/Releases/index.html#Stable-Download>.
Its `print.c' `std_handle_out_va' code for passing `extptr' to
`std_handle_out_external' gets compiled wrong exactly as described,
that is, passes uninitialized value that is generally invalid pointer,
and most likely is other than what is passed as arg 1 to `memcpy' call
earlier in `std_handle_out_va'.  Exactly before `callq  <memcpy@plt>'
instruction the value is in `$rdi', exactly before `callq
<std_handle_out_external>' it is in `$rdx'.  They should be the same,
but they are not.

Had the wrong code executed as follows.  Started it in debugger.
Stopped exactly before `initial_command_loop' call in `main_1' in
`emacs.c'.  Called `stderr_out ("\n")' in debugger.  (When actually
debugging the program, it happens in course of `ldp' command defined
by `.gdbinit' file created in build directory during build.)  Program
would receive `SIGSEGV' in backtrace:

std_handle_out_external
std_handle_out_va
stderr_out

Simpler program to link with preprocessed code initially posted, work
in batch mode, clearly complain that the wrong code is hit in most
cases when hits?  Will write such - in my copious free time.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34803

[Bug c/34803] wrong code for dereferencing type-punned pointer

[gin at mo dot msk dot ru]

------- Comment #6 from gin at mo dot msk dot ru  2008-01-18 16:21 -------
Subject: Re:  wrong code for dereferencing type-punned pointer

> looks good for 4.2.

Can we see (assembler) output of that 4.2, with those same
`-fno-strict-aliasing -O3 -fno-strict-aliasing' optimization options,
for the same preprocessed input as posted in the initial bug
description,
<http://gcc.gnu.org/bugzilla/attachment.cgi?id=14944&action=view>?
Was that some recent snapshot from 4.2 version control branch, or what
is the version?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34803