[Bug c/57237] New: Upstreaming the rtems multilib gcc patch

[Bug c/57237] New: Upstreaming the rtems multilib gcc patch

[cynt6007 at vandals dot uidaho.edu]

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

            Bug ID: 57237
           Summary: Upstreaming the rtems multilib gcc patch
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: cynt6007 at vandals dot uidaho.edu

RTEMS had multilib issues, and the following patch was generated.
http://git.rtems.org/rtems-crossrpms.git/tree/patches/gcc-4.8.0-rtems4.11-20130326.diff

The Points of Contact for this patch are:
Ralf Corsépius  <ralf.corsepius@rtems.org>
Sebastian Huber <sebastian.huber@embedded-brains.de>
>From gcc-bugs-return-422017-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri May 10 14:00:17 2013
Return-Path: <gcc-bugs-return-422017-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 26812 invoked by alias); 10 May 2013 14:00:17 -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 26731 invoked by uid 48); 10 May 2013 14:00:12 -0000
From: "joel at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/57237] Upstreaming the rtems v850 multilib gcc patch
Date: Fri, 10 May 2013 14:00: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: 4.8.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: joel at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: joel at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.1
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cf_gcctarget assigned_to target_milestone short_desc
Message-ID: <bug-57237-4-2KS3nU66UZ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57237-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57237-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: 2013-05/txt/msg00690.txt.bz2
Content-length: 577

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW237

Joel Sherrill <joel at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |v850*-*-rtems*
           Assignee|unassigned at gcc dot gnu.org      |joel at gcc dot gnu.org
   Target Milestone|---                         |4.8.1
            Summary|Upstreaming the rtems       |Upstreaming the rtems v850
                   |multilib gcc patch          |multilib gcc patch

[Bug c/57237] Upstreaming the rtems v850 multilib gcc patch

[joel at gcc dot gnu.org]

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

--- Comment #1 from Joel Sherrill <joel at gcc dot gnu.org> ---
This patch cannot be merged as is. It includes at least 4 separate issues.

+ v850 multilibs
+ sparc64-rtems definining SVR4
+ WCHAR issues
+ stddef.h issue

Patches can only be single issue.

I am going to use this PR to address the v850 multilib. A new patch will come
in a few minutes.

[Bug c/57237] Upstreaming the rtems v850 multilib gcc patch

[joel at gcc dot gnu.org]

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

--- Comment #2 from Joel Sherrill <joel at gcc dot gnu.org> ---
Testing with this patch for just the v850:

2013-03-26  Ralf Corsépius  <ralf.corsepius@rtems.org>

    * config/v850/t-rtems: Use multilibs from gcc < 4.8.0.

diff -Naur gcc-4.8.0.orig/gcc/config/v850/t-rtems
gcc-4.8.0/gcc/config/v850/t-rtems
--- gcc-4.8.0.orig/gcc/config/v850/t-rtems    2012-07-18 17:29:51.000000000
+0200
+++ gcc-4.8.0/gcc/config/v850/t-rtems    2013-03-26 16:25:34.774043617 +0100
@@ -1,3 +1,8 @@
 # Custom multilibs for RTEMS

+# Multilibs from gcc-4.7.x
+MULTILIB_OPTIONS  = mv850/mv850e/mv850e2/mv850e2v3
+MULTILIB_DIRNAMES = v850 v850e v850e2 v850e2v3
+MULTILIB_MATCHES  = mv850e=mv850e1 
+
 MULTILIB_MATCHES  += mv850e=mv850es
>From gcc-bugs-return-422021-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri May 10 14:26:18 2013
Return-Path: <gcc-bugs-return-422021-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 18622 invoked by alias); 10 May 2013 14:26:18 -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 18564 invoked by uid 48); 10 May 2013 14:26:14 -0000
From: "zackw at panix dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/57230] [4.7/4.8/4.9 Regression] tree-ssa-strlen incorrectly optimizes a strlen to 0
Date: Fri, 10 May 2013 14:26:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 4.8.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: major
X-Bugzilla-Who: zackw at panix dot com
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.7.4
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-57230-4-BSnfouHjxv@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57230-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57230-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: 2013-05/txt/msg00694.txt.bz2
Content-length: 2263

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW230

--- Comment #8 from Zack Weinberg <zackw at panix dot com> ---
(In reply to Jakub Jelinek from comment #6)
> We have just one strlen pass instance, and even if we optimize the first
> strlen
> there, having strlen pass duplicate constant propagation functionality just
> to handle this weird testcase (storing strlen sizes inside of characters is
> nothing common) doesn't make sense.

I think I gave the wrong impression there; I was trying to exhibit a more
comprehensive *correctness* test for this transformation, using strlen() as a
convenient-to-hand function known in context to return a nonzero value.  Lemme
try again.

  extern __SIZE_TYPE__ strlen(const char *);
  extern int rand(void);
  extern void abort(void) __attribute__((noreturn));
  #define assert(x) do { if (!(x)) abort(); } while (0)

  /* Returns a value that might or might not be zero. */
  static inline char maybe_zero() { return rand() & 0x10; }
  /* Returns an unknown but definitely-nonzero value. */
  static inline char nonzero() { return (rand() & 0x10) | 0x01; }

  int main(void)
  {
    char s[] = "abc\0def";

    /* These operations do not change the length of the string. */
    s[0] = nonzero();  assert(strlen(s) == 3);
    s[1] = nonzero();  assert(strlen(s) == 3);
    s[2] = nonzero();  assert(strlen(s) == 3);
    s[3] = '\0';       assert(strlen(s) == 3);
    s[4] = '\0';       assert(strlen(s) == 3);
    s[4] = 'd';        assert(strlen(s) == 3);

    /* These operations change the length of the string, to a
       value (in principle) computable at compile time. */
    s[3] = nonzero();  assert(strlen(s) == 7);
    s[5] = '\0';       assert(strlen(s) == 5);
    s[2] = '\0';       assert(strlen(s) == 2);
    s[2] = 'c';        assert(strlen(s) == 5);
    s[5] = nonzero();  assert(strlen(s) == 7);

    /* This operation requires runtime recalculation of the
       length of the string. */
    s[4] = maybe_zero();
    assert(strlen(s) == (s[4] ? 7 : 4));
    return 0;
  }

Of all of that, the most important thing IMHO (given the original bug report)
is to verify that writing '\0' at a nonzero *offset* within a string does not
cause a subsequent strlen() to report the length of the string as zero.

[Bug c/57237] Upstreaming the rtems v850 multilib gcc patch

[joel at gcc dot gnu.org]

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

Joel Sherrill <joel at gcc dot gnu.org> changed:

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

--- Comment #3 from Joel Sherrill <joel at gcc dot gnu.org> ---
Patch committed to 4.7, 4.8, and head.

[Bug c/57237] Upstreaming the rtems v850 multilib gcc patch

[corsepiu at gcc dot gnu.org]

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

Ralf Corsepius <corsepiu at gcc dot gnu.org> changed:

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

--- Comment #4 from Ralf Corsepius <corsepiu at gcc dot gnu.org> ---
(In reply to Joel Sherrill from comment #3)
> Patch committed to 4.7, 4.8, and head.

It would have been nice if you'd give the author of a patch a chance to
comment, instead of hastily rushing out a patch - Thanks for being more
collaborative next time.

[Bug target/57237] Upstreaming the rtems v850 multilib gcc patch

[chris at contemporary dot net.au]

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

Chris Johns <chris at contemporary dot net.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |chris at contemporary dot net.au

--- Comment #6 from Chris Johns <chris at contemporary dot net.au> ---
(In reply to Ralf Corsepius from comment #4)
> (In reply to Joel Sherrill from comment #3)
> > Patch committed to 4.7, 4.8, and head.
> 
> It would have been nice if you'd give the author of a patch a chance to
> comment, instead of hastily rushing out a patch - Thanks for being more
> collaborative next time.

The patch has been in released RTEMS RPMs you make for a while now that our
users use and trust. If there is an issue or a problem why have you been
releasing tools built using it ? I am confused by your response.