[Bug c/64188] New: [5 Regression] empty nested function does use trampoline

[Bug c/64188] New: [5 Regression] empty nested function does use trampoline

[jan.kratochvil at redhat dot com]

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

            Bug ID: 64188
           Summary: [5 Regression] empty nested function does use
                    trampoline
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jan.kratochvil at redhat dot com
            Target: x86_64-linux-gnu

(1)
echo 'int main(void) { void func (void) {} func (); return 0; }'|gcc -g -x c
-;readelf -wi a.out|grep DW_AT_static_link
FAIL: gcc (GCC) 5.0.0 20141204 (experimental)
    <63>   DW_AT_static_link : 2 byte block: 91 68      (DW_OP_fbreg: -24)
PASS: gcc (GCC) 4.9.3 20141204 (prerelease)
<nothing>

(2)
echo 'int main(void) { void func (void) {} void (*p) (void) = func; return 0;
}'|gcc -g -Wtrampolines -x c -
FAIL: gcc (GCC) 5.0.0 20141204 (experimental)
<stdin>: In function ‘main’:
<stdin>:1:23: warning: trampoline generated for nested function ‘func’
[-Wtrampolines]
PASS: gcc (GCC) 4.9.3 20141204 (prerelease)
<nothing>

(3)
gcc -x c - <<EOH;./a.out
#include <string.h>
#include <alloca.h>
#include <stdio.h>
static void (*outer (void)) (void) {
  void inner (void) {}
  return inner;
}              
int main (void) {
  void (*p) (void) = outer();
  bzero (alloca (0x100), 0x100);
  p ();                         
  puts ("pass");
  return 0;
}          
EOH
FAIL: gcc (GCC) 5.0.0 20141204 (experimental)
Segmentation fault
PASS: gcc (GCC) 4.9.3 20141204 (prerelease)
pass
>From gcc-bugs-return-469505-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Dec 04 21:22:43 2014
Return-Path: <gcc-bugs-return-469505-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 20403 invoked by alias); 4 Dec 2014 21:22:43 -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 20355 invoked by uid 48); 4 Dec 2014 21:22:39 -0000
From: "kcc at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/63888] [5 Regression] bootstrap failed when configured with -with-build-config=bootstrap-asan --disable-werror
Date: Thu, 04 Dec 2014 21:22:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: bootstrap
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: kcc at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63888-4-DMGmia4ZV3@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63888-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63888-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: 2014-12/txt/msg00512.txt.bz2
Content-length: 1719

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

--- Comment #8 from Kostya Serebryany <kcc at gcc dot gnu.org> ---
(sorry for delay, I missed the last comment)
> Generally, we do want to instrument even artificial variables, and on many
> of them buffer overflow is possible.

Yea, agree.

>
> > I.e. is a buffer overflow on these variables possible?
> >
> > If we don't instrument them we won't report an ODR violation.
> >
> > >> GCC with -fmerge-all-constants also merges many read-only constants, even addressable ones, when they have the same content.
> >
> > Then I guess we may have other false positives.
> > We may want to disable -fmerge-all-constants under asan
>
> You haven't responded about the language thing, there is no such thing as
> ODR in C or Fortran, so you shouldn't report it.

In LLVM, I do not (and should not) know what source language is being compiled.
The differences between languages are represented in the linkage types
of the globals. E.g. a regular global in C will not be instrumented at all
unless -fno-common is given. I.e. the difference is not in the source language
but in the linkage type of the globals.

% clang -S -o - -emit-llvm glob.c
@GLOBAL = common global i32 0, align 4
% clang -S -o - -emit-llvm glob.c -fno-common
@GLOBAL = global i32 0, align 4
% clang++ -x c++ -S -o - -emit-llvm glob.c
@GLOBAL = global i32 0, align 4


Can you give an example in C where we do not want to check for ODRs, yet
the basic asan instrumentation is legal?

> There are 31 (or 63) bits left in __has_dynamic_init field, can't one bit be
> used for whether ODR should be reported or not?
That will still mean an API change, something I like to avoid when possible.

[Bug c/64188] [5 Regression] empty nested function does use trampoline

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Only when not optimizing.  I think that was an intentional change, requested by
GDB folks.  See PR53927.