[Bug c/40115] -O2 and higher causes wrong label address calculation

[Bug c/40115] -O2 and higher causes wrong label address calculation

[perlun at gmail dot com]

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

Per Lundberg <perlun at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |perlun at gmail dot com

--- Comment #4 from Per Lundberg <perlun at gmail dot com> ---
Hi,

Andrew - with all due respect, this bug should *not* have been closed. It it
still present (at least with gcc 4.7.2). Here is some code (very simplified):

    new_tss->eip = (u32) &&new_thread_entry;
    new_tss->cr3 = page_directory_physical_page * SIZE_PAGE;

    // ...

    mutex_kernel_signal(&tss_tree_mutex);
    mutex_kernel_signal(&memory_mutex);

new_thread_entry:

    DEBUG_MESSAGE(DEBUG, "Enabling interrupts");
    cpu_interrupts_enable();


Without -O2, the new_tss->eip gets the proper value of the code line right
below new_thread_entry. With -O2, I get this (objdump -S output):

    new_tss->eip = (u32) &&new_thread_entry;
  108314:       c7 43 20 b1 85 10 00    movl   $0x1085b1,0x20(%ebx)

Here is where it points to. A number of instructions too early, causing the
code to entirely break down.

    *list = tss_list_node;
  1085b1:       89 46 0c                mov    %eax,0xc(%esi)

    mutex_kernel_wait(&memory_mutex);
    mutex_kernel_wait(&tss_tree_mutex);
    process_info = (process_info_type *) new_tss->process_info;
    thread_link_list(&process_info->thread_list, new_tss);
    thread_link(new_tss);
  1085b4:       89 1c 24                mov    %ebx,(%esp)
  1085b7:       e8 04 f9 ff ff          call   107ec0 <thread_link>
    number_of_tasks++;
  1085bc:       a1 60 44 11 00          mov    0x114460,%eax
  1085c1:       83 c0 01                add    $0x1,%eax
  1085c4:       a3 60 44 11 00          mov    %eax,0x114460

static inline u32 cpu_get_esp(void)
{
    u32 return_value;

    asm volatile ("movl %%esp, %0"
  1085c9:       89 e0                   mov    %esp,%eax
    new_tss->esp = cpu_get_esp();
  1085cb:       89 43 38                mov    %eax,0x38(%ebx)
    process_info->number_of_threads++;
  1085ce:       83 46 10 01             addl   $0x1,0x10(%esi)

    mutex_kernel_signal(&tss_tree_mutex);
  1085d2:       c7 04 24 64 3a 11 00    movl   $0x113a64,(%esp)
  1085d9:       e8 f2 21 00 00          call   10a7d0 <mutex_kernel_signal>
    mutex_kernel_signal(&memory_mutex);
  1085de:       c7 04 24 0c 44 11 00    movl   $0x11440c,(%esp)
  1085e5:       e8 e6 21 00 00          call   10a7d0 <mutex_kernel_signal>
    asm ("cli");
}

static inline void cpu_interrupts_enable(void)
{
    asm ("sti");
  1085ea:       fb                      sti

(the last instruction here is where it *should* have pointed at. :)

This used to work with older versions of gcc (last known "good" version is
something like 2.95), so obviously something relating to goto labels/O2 has
gotten broken during the years.

IMHO, this is a clear bug. In my case, I use the address for "jumping" but with
indirect jumping (in the new thread being created). Would you say that this is
not supported?

Does direct jumping (i.e. goto *&&foo) even work at the moment, with -O2? Are
there any unit tests or similar for this?

[Bug c/40115] -O2 and higher causes wrong label address calculation

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> In my case, I use the address for "jumping" but with indirect jumping
> (in the new thread being created). Would you say that this is not supported?

yes that is not support is explicitly says it is not support: "You may not use
this mechanism to jump to code in a different function. ".  You just caused a
jump to a different function.  For these kind of things you should be using
functions and function pointers instead of label addresses.

[Bug c/40115] -O2 and higher causes wrong label address calculation

[perlun at gmail dot com]

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

--- Comment #6 from Per Lundberg <perlun at gmail dot com> ---
Well, the label is actually in the same function. It just happens to land there
on the other thread. I can't really use a function pointer here, since I have
no way (at least that I know of) to find out how much the stack pointer is
offset within the function. In fact, I tried that approach but it failed
specifically because of that (when trying to return from the other function,
since esp wasn't pointing at the right adress).




I am using -fomit-frame-pointers, otherwise I guess I could just take the ebp
value. Any other suggestion?



—
Sent from Mailbox

On Wed, May 6, 2015 at 11:52 PM, pinskia at gcc dot gnu.org
<gcc-bugzilla@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40115
> --- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>> In my case, I use the address for "jumping" but with indirect jumping
>> (in the new thread being created). Would you say that this is not supported?
> yes that is not support is explicitly says it is not support: "You may not use
> this mechanism to jump to code in a different function. ".  You just caused a
> jump to a different function.  For these kind of things you should be using
> functions and function pointers instead of label addresses.
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.
>From gcc-bugs-return-485689-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed May 06 21:09:00 2015
Return-Path: <gcc-bugs-return-485689-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 103946 invoked by alias); 6 May 2015 21:09:00 -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 103897 invoked by uid 48); 6 May 2015 21:08:55 -0000
From: "glaubitz at physik dot fu-berlin.de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/65979] Multiple issues in conftest.c prevent build on sh4-linux-gnu
Date: Wed, 06 May 2015 21:09:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.1.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: glaubitz at physik dot fu-berlin.de
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-65979-4-pV7Q8a7bqK@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65979-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65979-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-05/txt/msg00529.txt.bz2
Content-length: 1006

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

--- Comment #6 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Hi!

I did some more tests and it turns out, my current compiler can't even build
gcc-4.9 anymore. Inspecting the build log [1] closer hints at problems when the
stages 2 and 3 are being compared:

Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1objplus-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap comparison failure!
gcc/d/ctfeexpr.dmd.o differs
Makefile:19827: recipe for target 'compare' failed

I have downgraded to a previous version of the gcc-4.9 package now which has
built gcc-4.9 successfully in the past. I'm building gcc-4.9 and gcc-5 in
parallel on different hosts now, I will know the result in the weekend (slow
hardware).

To be followed up.

Adrian

> [1] http://buildd.debian-ports.org/status/fetch.php?pkg=gcc-4.9&arch=sh4&ver=4.9.2-16&stamp\x1430922724

[Bug c/40115] -O2 and higher causes wrong label address calculation

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |DUPLICATE

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
.

*** This bug has been marked as a duplicate of bug 44298 ***

[Bug c/40115] -O2 and higher causes wrong label address calculation

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2009-05-12 15:58 -------
The intention of address of labels is only for use of flow control and nothing
else.  So taking the address of a label and using it to find the current PC is
not a valid use of this extension.  This extension was not designed to be very
generic it was designed only for flow control usage with the computed goto.


-- 

pinskia at gcc dot gnu dot org changed:

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


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

[Bug c/40115] -O2 and higher causes wrong label address calculation

[sergstesh at yahoo dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2177 bytes --]



------- Comment #2 from sergstesh at yahoo dot com  2009-05-12 15:43 -------
No, the documentation explicitly says

( http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc.pdf , page 247 .. 248):

"
5.3 Labels as Values
...
   To use these values, you need to be able to jump to one. This is done with
the computed
goto statement1 , goto *exp ;. For example,
       goto *ptr;
Any expression of type void * is allowed.
  One way of using these constants is in initializing a static array that will
serve as a jump
table:
       static void *array[] = { &&foo, &&bar, &&hack };
  Then you can select a label with indexing, like this:
       goto *array[i];
Note that this does not check whether the subscript is in bounds—array
indexing in C never
does that.
  Such an array of label values serves a purpose much like that of the switch
statement.
The switch statement is cleaner, so use that rather than an array unless the
problem does
not fit a switch statement very well.
   Another use of label values is in an interpreter for threaded code. The
labels within the
interpreter function can be stored in the threaded code for super-fast
dispatching.
   You may not use this mechanism to jump to code in a different function. If
you do that,
totally unpredictable things will happen. The best way to avoid this is to
store the label
address only in automatic variables and never pass it as an argument.
   An alternate way to write the above example is
       static const int array[] = { &&foo - &&foo, &&bar - &&foo,
                                    &&hack - &&foo };
       goto *(&&foo + array[i]);
",

i.e. the documentation explicitly allows to rely upon labels as values.

I actually checked putting label addresses into an array - the same problem. I
didn't publish the code here - didn't want to over-complicate the test case.


-- 

sergstesh at yahoo dot com changed:

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


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

[Bug c/40115] -O2 and higher causes wrong label address calculation

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2009-05-12 14:55 -------
No labels are not designed that way.  They are designed only for jumping and
when they are taken the address of, there should only be used for jumping and
nothing else.


-- 

pinskia at gcc dot gnu dot org changed:

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


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