Mailing-List: contact commits-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Message-ID: <1510101480.1206018324285.JavaMail.jira@brutus>
Date: Thu, 20 Mar 2008 06:05:24 -0700 (PDT)
From: "Gregory Shimansky (JIRA)" <jira@apache.org>
To: commits@harmony.apache.org
Subject: [jira] Updated: (HARMONY-5623) [drlvm][thread] Fix warnings from
 the offsetof() macro
In-Reply-To: <774226183.1206014124356.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/HARMONY-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gregory Shimansky updated HARMONY-5623:
---------------------------------------

    Assignee: Gregory Shimansky

I vote for removing access modifiers as well.

> [drlvm][thread] Fix warnings from the offsetof() macro
> ------------------------------------------------------
>
>                 Key: HARMONY-5623
>                 URL: https://issues.apache.org/jira/browse/HARMONY-5623
>             Project: Harmony
>          Issue Type: Bug
>          Components: DRLVM
>         Environment: Linux
>            Reporter: Ilya Berezhniuk
>            Assignee: Gregory Shimansky
>            Priority: Minor
>         Attachments: off_warn2.patch, off_warn_h.patch
>
>
> There are several similar warnings appeared when compiling DRLVM on GCC:
> "perhaps the `offsetof` macro was used incorrectly".
> All these warnings appear because VM_thread structure becomes non-POD structure with private/public access modifiers.
> There are some methods to solve this problem.
> 1) The first one is using runtime offset calculation instead of compile-time 'offsetof'.
> Such a calculation looks like getting an address of some field of a zeroed local pointer to VM_thread structure.
> In release mode compilers turn local var usage into a constant, so there is no performance issue.
> The 'off_warn2.patch' implements this solution.
> Potential problem of such a method, and of using 'private' modifier in #ifdef at all, is that modern optimising compilers could reorder fields in non-POD structure, and even trow away private fields which are not used. In this case VM_thread fields will be different in C and C++ sources.
> 2) Another solution is removing private/public modifiers from VM_thread definition. It's much simpler, and these modifiers actually do not protect anything, because VM_thread to HyThread casting is used everywhere, so everybody can use casted HyThread directly.
> The 'off_warn_h.patch' implements this solution.
> Thread gurus, please decide what method should be used.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.