[Bug c++/58192] New: G++ emits incorrect code when passing enum classes as function parameters

[Bug c++/58192] New: G++ emits incorrect code when passing enum classes as function parameters

[temporal at gmail dot com]

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

            Bug ID: 58192
           Summary: G++ emits incorrect code when passing enum classes as
                    function parameters
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: temporal at gmail dot com

Demonstration attached.  It repros with g++ 4.8.1 (tested on Ubuntu and
Cygwin).  I think I saw similar problems with g++ 4.7.3, but this particular
test case does not seem to repro with it.

[Bug c++/58192] G++ emits incorrect code when passing enum classes as function parameters

[temporal at gmail dot com]

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

--- Comment #1 from Kenton Varda <temporal at gmail dot com> ---
Created attachment 30672
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30672&action=edit
Demonstration of enum class passing bug

[Bug c++/58192] G++ emits incorrect code when passing enum classes as function parameters

[temporal at gmail dot com]

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

--- Comment #2 from Kenton Varda <temporal at gmail dot com> ---
Note:  Both the Ubuntu and Cygwin systems were x86_64.  I don't know if the
problem occurs in 32-bit mode.

[Bug c++/58192] G++ emits incorrect code when passing enum classes as function parameters

[temporal at gmail dot com]

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

Kenton Varda <temporal at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #30672|0                           |1
        is obsolete|                            |

--- Comment #3 from Kenton Varda <temporal at gmail dot com> ---
Created attachment 30673
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30673&action=edit
Demonstration of enum class passing bug (v2)

The first version of my demo was doing slightly weird things with unions in
main().  This was vestigial code from my attempts to narrow down the bug, but
wasn't actually necessary to trigger it.  So, I simplified it.

[Bug c++/58192] G++ emits incorrect code when passing enum classes as function parameters

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
           Priority|P3                          |P2
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-08-19
     Ever confirmed|0                           |1

--- Comment #4 from Paolo Carlini <paolo.carlini at oracle dot com> ---
I have yet to analyze this in detail, but let's play safe and confirm it as
wrong-code.

[Bug c++/58192] G++ emits incorrect code when passing enum classes as function parameters

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The difference is that in the S1::<anon struct>::set(Foo) case
setup_incoming_promotions in combine.c says that the argument has non-zero mask
of 0xff, because the function is local to the TU, while for S2 all caller's
aren't guaranteed local and thus it isn't optimized.  The argument type is Foo
(QImode) passed in SImode register, guess combine.c expects that caller
zero-extends in this case, but it doesn't (in neither case).

enum class Foo : unsigned char { FOO };
struct S1
{
  struct
  {
    unsigned int i;
    void __attribute__((noinline))
    set (Foo foo)
    {
      i = static_cast<unsigned int> (foo);
    }
  } x;
};
struct S2
{
  struct X
  {
    unsigned int i;
    void __attribute__((noinline))
    set (Foo foo)
    {
      i = static_cast<unsigned int> (foo);
    }
  };
  X x;
};
struct T { unsigned short i; Foo f; unsigned char c; };

__attribute__((noinline)) void
baz (unsigned int x)
{
  if (x != 0) __builtin_abort ();
}

void
bar (T t)
{
  S1 s1;
  s1.x.set(t.f);
  baz (s1.x.i);
  S2 s2;
  s2.x.set(t.f);
  baz (s2.x.i);
}

int
main()
{
  T t = { 0xabcd, Foo::FOO, 0xef};
  bar (t);
}

For:
unsigned int v1, v2;

__attribute__((noinline, noclone)) static void
foo (unsigned char a)
{
  v1 = a;
}

__attribute__((noinline, noclone)) void
bar (unsigned char a)
{
  v2 = a;
}

void
baz (unsigned int a)
{
  foo (a);
  bar (a);
}
the situation is similar for foo/bar (foo optimizes and doesn't zero extend
from 8 to 32 bits, bar doesn't), but the caller in this case always zero
extends.

[Bug c++/58192] G++ emits incorrect code when passing enum classes as function parameters

[paolo.carlini at oracle dot com]

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

--- Comment #6 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Jakub, do I understand correctly that this isn't a front-end issue?

[Bug c++/58192] G++ emits incorrect code when passing enum classes as function parameters

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
That is to be determined.  Either it might be an x86_64 bug in passing such
types, or FE issue, middle-end.

[Bug c++/58192] G++ emits incorrect code when passing enum classes as function parameters

[ubizjak at gmail dot com]

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

--- Comment #8 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Jakub Jelinek from comment #7)
> That is to be determined.  Either it might be an x86_64 bug in passing such
> types, or FE issue, middle-end.

Please note that the error also occurs with -m32, so it seems highly unlikely
an x86_64 target-dependent bug.
>From gcc-bugs-return-462092-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Sep 19 12:24:34 2014
Return-Path: <gcc-bugs-return-462092-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 3122 invoked by alias); 19 Sep 2014 12:24:34 -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 3084 invoked by uid 48); 19 Sep 2014 12:24:30 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ada/63310] New: Ada bootstrap error with -fcompare-debug
Date: Fri, 19 Sep 2014 12:24:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ada
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc
Message-ID: <bug-63310-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-09/txt/msg01926.txt.bz2
Content-length: 1474

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

            Bug ID: 63310
           Summary: Ada bootstrap error with -fcompare-debug
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: ada
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
                CC: charlet at gcc dot gnu.org, ebotcazou at gcc dot gnu.org

My:
../configure --enable-languages=all,ada,obj-c++,lto,go
--enable-checking=release; GCC_COMPARE_DEBUG=1 make -j48 bootstrap > LOG 2>&1
&& GCC_COMPARE_DEBUG=1 make -j48 -k check > LOGC 2>&1; ../contrib/test_summary
> LOGT 2>&1
bootstrap on x86_64 failed with:
xgcc: error: a-rttiev.adb: -fcompare-debug failure

It seems this is caused by gnat_write_global_declarations, which creates
dummy_global decl AND corresponding varpool node for it (the former is not a
problem I think, we only require that decls that are created for both -g and
-g0 sort by DECL_UIDs the same (i.e. -g can have bigger gaps in the uids than
-g0), but for cgraph nodes e.g. node->order is visible in the dumps), and for
-g0
used_types_insert doesn't emit anything into types_used_by_cur_var_decl vector,
while for -g if there are global vars it sometimes does.

I have no idea what is dummy_global good for, but if you need it, it probably
has to be created regardless of whether types_used_by_cur_var_decl vector is
empty or not.

[Bug c++/58192] G++ emits incorrect code when passing enum classes as function parameters

[ubizjak at gmail dot com]

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

--- Comment #9 from Uroš Bizjak <ubizjak at gmail dot com> ---
Looking at dumps, obtained with -m32 -O1, we have following sequence before the
call to _ZN2S1Ut_3setE3Foo:

_.dfinit:

(insn 7 3 8 2 (parallel [
            (set (reg:SI 88)
                (lshiftrt:SI (reg/v:SI 86 [ t ])
                    (const_int 16 [0x10])))
            (clobber (reg:CC 17 flags))
        ]) 539 {*lshrsi3_1}
     (nil))
(insn 8 7 9 2 (parallel [
            (set (reg:QI 85 [ t$2 ])
                (and:QI (subreg:QI (reg:SI 88) 0)
                    (const_int -1 [0xffffffffffffffff])))
            (clobber (reg:CC 17 flags))
        ]) 379 {*andqi_1}
     (nil))

...

(insn 10 9 11 2 (set (reg:QI 1 dx)
        (reg:QI 85 [ t$2 ])) gcc-bug.cc:72 93 {*movqi_internal}
     (nil))

...

(call_insn 12 11 13 2 (call (mem:QI (symbol_ref:SI ("_ZN2S1Ut_3setE3Foo")
[flags 0x3]  <function_decl 0x2ad94c491438 set>) [0 set S1 A8])
        (const_int 0 [0])) gcc-bug.cc:72 651 {*call}
     (expr_list:REG_EH_REGION (const_int 0 [0])
        (nil))
    (expr_list:SI (use (reg:SI 0 ax))
        (expr_list:QI (use (reg:QI 1 dx))
            (nil))))

_.cse1 mangles argument setup to:

(insn 8 7 9 2 (set (reg:QI 85 [ t$2 ])
        (subreg:QI (reg:SI 88) 0)) 93 {*movqi_internal}
     (expr_list:REG_DEAD (reg:SI 88)
        (expr_list:REG_UNUSED (reg:CC 17 flags)
            (nil))))

...

(insn 10 9 11 2 (set (reg:QI 1 dx)
        (subreg:QI (reg:SI 88) 0)) gcc-bug.cc:72 93 {*movqi_internal}
     (nil))

and _.fwprop1 merges both to:

(insn 10 9 11 2 (set (reg:QI 1 dx)
        (subreg:QI (reg:SI 88) 0)) gcc-bug.cc:72 93 {*movqi_internal}
     (nil))

resulting in:

#(insn 10 9 34 2 (set (reg:QI 1 dx)
#        (reg:QI 3 bx [88])) gcc-bug.cc:72 93 {*movqi_internal}
#     (nil))
    movl    %ebx, %edx    # 10    *movqi_internal/1    [length = 2]

However, x86 ABI mandates that arguments should be properly extended in the
call to the function. I don't think original (insn 8) is correct, as it is
effectively a NOP.
>From gcc-bugs-return-462096-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Sep 19 13:11:17 2014
Return-Path: <gcc-bugs-return-462096-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 2073 invoked by alias); 19 Sep 2014 13:11:16 -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 2050 invoked by uid 48); 19 Sep 2014 13:11:10 -0000
From: "marcos.diaz at tallertechnologies dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/63301] inconsistency on wchar_t and wint_t types and sizes for diverse architectures
Date: Fri, 19 Sep 2014 13:11: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.3
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: marcos.diaz at tallertechnologies dot com
X-Bugzilla-Status: RESOLVED
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-63301-4-9fWWlDk79k@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63301-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63301-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-09/txt/msg01930.txt.bz2
Content-length: 294

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

--- Comment #2 from Marcos Diaz <marcos.diaz at tallertechnologies dot com> ---
Sorry, I expressed wrong the issue I was reporting, What I want to ask is the
following:

Is it ok that the wchar_t is a long int and the wint_t is just an int?

[Bug c++/58192] G++ emits incorrect code when passing enum classes as function parameters

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
When I compile:
#ifdef CHAR
typedef unsigned char Foo;
#else
enum class Foo : unsigned char { FOO };
#endif
unsigned int v1, v2;

__attribute__((noinline, noclone)) static void
foo (Foo a)
{
  v1 = (unsigned int) a;
}

__attribute__((noinline, noclone)) void
bar (Foo a)
{
  v2 = (unsigned int) a;
}

void
baz (unsigned int a)
{
  foo ((Foo) a);
  bar ((Foo) a);
}

with -DCHAR vs. -UCHAR, there is a difference visible already in *.original
dump:
 <<cleanup_point <<< Unknown tree: expr_stmt
-  foo ((int) (Foo) a) >>>>>;
+  foo ((Foo) a) >>>>>;
 <<cleanup_point <<< Unknown tree: expr_stmt
-  bar ((int) (Foo) a) >>>>>;
+  bar ((Foo) a) >>>>>;
i.e. there is explicit zero-extension for integral types smaller than int in
the IL (i.e. for the -DCHAR) case, but nothing like that for the enum class
with underlying type smaller than int.  And presumably the middle-end and
backends rely on this.

[Bug c++/58192] G++ emits incorrect code when passing enum classes as function parameters

[ubizjak at gmail dot com]

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

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|uros at gcc dot gnu.org            |hjl.tools at gmail dot com,
                   |                            |ubizjak at gmail dot com

--- Comment #11 from Uroš Bizjak <ubizjak at gmail dot com> ---
Does this still fail after r218720, AKA PR64037 [1]?

[1] https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01183.html
>From gcc-bugs-return-470742-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Dec 15 14:40:45 2014
Return-Path: <gcc-bugs-return-470742-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 16478 invoked by alias); 15 Dec 2014 14:40:45 -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 16436 invoked by uid 48); 15 Dec 2014 14:40:41 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/64312] [5 Regression] ICE: Segmentation fault
Date: Mon, 15 Dec 2014 14:40: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: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status assigned_to
Message-ID: <bug-64312-4-hFhiImKPWJ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64312-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64312-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/msg01749.txt.bz2
Content-length: 455

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Mine.

[Bug c++/58192] G++ emits incorrect code when passing enum classes as function parameters

[hjl.tools at gmail dot com]

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

--- Comment #12 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Uroš Bizjak from comment #11)
> Does this still fail after r218720, AKA  [1]?
> 
> [1] https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01183.html

I think it is a dup of PR64037.
>From gcc-bugs-return-470746-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Dec 15 15:00:51 2014
Return-Path: <gcc-bugs-return-470746-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 1971 invoked by alias); 15 Dec 2014 15:00:51 -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 1920 invoked by uid 48); 15 Dec 2014 15:00:48 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/63594] [5 Regression] ICE: in ix86_vector_duplicate_value, at config/i386/i386.c:39831 with -mavx512f
Date: Mon, 15 Dec 2014 15:00: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.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution
Message-ID: <bug-63594-4-4hqT25hn9Y@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63594-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63594-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/msg01753.txt.bz2
Content-length: 423

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

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

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

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed.

[Bug c++/58192] G++ emits incorrect code when passing enum classes as function parameters

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #13 from H.J. Lu <hjl.tools at gmail dot com> ---
Dup of PR 64037.  Will be fixed after 4.8.4 is released.

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