public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/101219] New: ice in perform_or_defer_access_check
@ 2021-06-26  8:57 dcb314 at hotmail dot com
  2021-06-26  9:01 ` [Bug c++/101219] " dcb314 at hotmail dot com
                   ` (10 more replies)
  0 siblings, 11 replies; 12+ messages in thread
From: dcb314 at hotmail dot com @ 2021-06-26  8:57 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 101219
           Summary: ice in perform_or_defer_access_check
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 51061
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51061&action=edit
gzipped C++ source code

For the attached C++ code, recent gcc trunk with flag -Wall does this:

/home/dcb/gcc/results.20210626/bin/g++
mednafen/pce_fast/psg.cpp: In member function ‘void
PCEFast_PSG::RunChannel(int, int32)’:
mednafen/pce_fast/psg.cpp:367:50: internal compiler error: Segmentation fault
0xfd9219 crash_signal(int)
        ../../trunk.git/gcc/toplev.c:327
0x912bc8 perform_or_defer_access_check(tree_node*, tree_node*, tree_node*, int,
access_failure_info*)
        ../../trunk.git/gcc/cp/semantics.c:490

Code compiled fine with git hash 7dcf139a2b8e1c53, dated two days ago,
and goes wrong with 607c558804f70af2, dated yesterday.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [Bug c++/101219] ice in perform_or_defer_access_check
  2021-06-26  8:57 [Bug c++/101219] New: ice in perform_or_defer_access_check dcb314 at hotmail dot com
@ 2021-06-26  9:01 ` dcb314 at hotmail dot com
  2021-06-28  7:25 ` [Bug c++/101219] [12 Regression] ice in perform_or_defer_access_check since r12-1804-g65870e75616ee435 marxin at gcc dot gnu.org
                   ` (9 subsequent siblings)
  10 siblings, 0 replies; 12+ messages in thread
From: dcb314 at hotmail dot com @ 2021-06-26  9:01 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #1 from David Binderman <dcb314 at hotmail dot com> ---
Reduced C++ code seems to be:

class PCEFast_PSG {
  void UpdateOutput_Noise(int, int *);
};
template <int> void PCEFast_PSGRunChannel() {
  void (PCEFast_PSG::*ch_0)(int, int *);
  &PCEFast_PSG::UpdateOutput_Noise == ch_0;
}

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [Bug c++/101219] [12 Regression] ice in perform_or_defer_access_check since r12-1804-g65870e75616ee435
  2021-06-26  8:57 [Bug c++/101219] New: ice in perform_or_defer_access_check dcb314 at hotmail dot com
  2021-06-26  9:01 ` [Bug c++/101219] " dcb314 at hotmail dot com
@ 2021-06-28  7:25 ` marxin at gcc dot gnu.org
  2021-06-28 20:00 ` msebor at gcc dot gnu.org
                   ` (8 subsequent siblings)
  10 siblings, 0 replies; 12+ messages in thread
From: marxin at gcc dot gnu.org @ 2021-06-28  7:25 UTC (permalink / raw)
  To: gcc-bugs

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-06-28
            Summary|ice in                      |[12 Regression] ice in
                   |perform_or_defer_access_che |perform_or_defer_access_che
                   |ck                          |ck since
                   |                            |r12-1804-g65870e75616ee435
                 CC|                            |marxin at gcc dot gnu.org,
                   |                            |msebor at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
Confirmed, started with r12-1804-g65870e75616ee435.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [Bug c++/101219] [12 Regression] ice in perform_or_defer_access_check since r12-1804-g65870e75616ee435
  2021-06-26  8:57 [Bug c++/101219] New: ice in perform_or_defer_access_check dcb314 at hotmail dot com
  2021-06-26  9:01 ` [Bug c++/101219] " dcb314 at hotmail dot com
  2021-06-28  7:25 ` [Bug c++/101219] [12 Regression] ice in perform_or_defer_access_check since r12-1804-g65870e75616ee435 marxin at gcc dot gnu.org
@ 2021-06-28 20:00 ` msebor at gcc dot gnu.org
  2021-07-19 21:26 ` slyfox at gcc dot gnu.org
                   ` (7 subsequent siblings)
  10 siblings, 0 replies; 12+ messages in thread
From: msebor at gcc dot gnu.org @ 2021-06-28 20:00 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #3 from Martin Sebor <msebor at gcc dot gnu.org> ---
The code fails in the assert below where binfo is null.  The full stack trace
follows.  The difference is that before r12-1804  warn_for_null_address() would
return without doing anything because TREE_NO_WARNING(op) was 1.  r12-1804
changed the TREE_NO_WARNING(op) test to warning_suppressed_p (op,
OPT_Waddress)) which returns false.  The no-warning bit on OP is also clear so
something has caused it to not be set.  Possibly a subtle difference in the
location value.  Whatever has caused the change, it seems like the root cause
of the ICE is something else (unless the front end somehow relies on the
no-warning bit to also mean something else than just "disable warnings").

bool
perform_or_defer_access_check (tree binfo, tree decl, tree diag_decl,
                               tsubst_flags_t complain,
                               access_failure_info *afi)
{
  int i;
  deferred_access *ptr;
  deferred_access_check *chk;

  /* Exit if we are in a context that no access checking is performed.  */
  if (deferred_access_no_check)
    return true;

  gcc_assert (TREE_CODE (binfo) == TREE_BINFO);



0x1717bc8 crash_signal
        /ssd/src/gcc/master/gcc/toplev.c:328
0xdf00fb perform_or_defer_access_check(tree_node*, tree_node*, tree_node*, int,
access_failure_info*)
        /ssd/src/gcc/master/gcc/cp/semantics.c:490
0xdf6a7d finish_non_static_data_member(tree_node*, tree_node*, tree_node*)
        /ssd/src/gcc/master/gcc/cp/semantics.c:2208
0xda8762 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
        /ssd/src/gcc/master/gcc/cp/pt.c:20568
0xd5d6cc instantiate_non_dependent_expr_internal(tree_node*, int)
        /ssd/src/gcc/master/gcc/cp/pt.c:6323
0xad622f fold_non_dependent_expr_template
        /ssd/src/gcc/master/gcc/cp/constexpr.c:7604
0xad6585 fold_non_dependent_expr(tree_node*, int, bool, tree_node*)
        /ssd/src/gcc/master/gcc/cp/constexpr.c:7661
0xbda7c4 fold_for_warn(tree_node*)
        /ssd/src/gcc/master/gcc/cp/expr.c:409
0xe67e56 warn_for_null_address
        /ssd/src/gcc/master/gcc/cp/typeck.c:4453
0xe6a880 cp_build_binary_op(op_location_t const&, tree_code, tree_node*,
tree_node*, int)
        /ssd/src/gcc/master/gcc/cp/typeck.c:5169
0xe6b0ff cp_build_binary_op(op_location_t const&, tree_code, tree_node*,
tree_node*, int)
        /ssd/src/gcc/master/gcc/cp/typeck.c:5357
0xa59d4c build_new_op_1
        /ssd/src/gcc/master/gcc/cp/call.c:6760
0xa59e57 build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node**, int)
        /ssd/src/gcc/master/gcc/cp/call.c:6806
0xe6774c build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node**, int)
        /ssd/src/gcc/master/gcc/cp/typeck.c:4330
0xcd6d2c cp_parser_binary_expression
        /ssd/src/gcc/master/gcc/cp/parser.c:10023
0xcd7229 cp_parser_assignment_expression
        /ssd/src/gcc/master/gcc/cp/parser.c:10163
0xcd7608 cp_parser_expression
        /ssd/src/gcc/master/gcc/cp/parser.c:10331
0xcdb75c cp_parser_expression_statement
        /ssd/src/gcc/master/gcc/cp/parser.c:12075
0xcdafe1 cp_parser_statement
        /ssd/src/gcc/master/gcc/cp/parser.c:11871
0xcdbd17 cp_parser_statement_seq_opt
        /ssd/src/gcc/master/gcc/cp/parser.c:12223

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [Bug c++/101219] [12 Regression] ice in perform_or_defer_access_check since r12-1804-g65870e75616ee435
  2021-06-26  8:57 [Bug c++/101219] New: ice in perform_or_defer_access_check dcb314 at hotmail dot com
                   ` (2 preceding siblings ...)
  2021-06-28 20:00 ` msebor at gcc dot gnu.org
@ 2021-07-19 21:26 ` slyfox at gcc dot gnu.org
  2021-07-19 21:47 ` slyfox at gcc dot gnu.org
                   ` (6 subsequent siblings)
  10 siblings, 0 replies; 12+ messages in thread
From: slyfox at gcc dot gnu.org @ 2021-07-19 21:26 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #4 from Sergei Trofimovich <slyfox at gcc dot gnu.org> ---
Got the same mednafen crash today. Poked slightly at the context in gdb.

>From what I understand the crash happens when analysing statement `void
(PCEFast_PSG::*ch_0)(int, int *);`. There is no access to the any object field
implied by `TYPE_BINFO (access_type)`. Or is there? Should it refer to `class
PCEFast_PSG`?

(gdb) fr 1
#1  0x000000000079ff83 in finish_non_static_data_member (decl=0x7ffff7652a18,
object=0x7ffff7796860, qualifying_scope=0x0) at
/home/slyfox/dev/git/gcc/gcc/cp/semantics.c:2208
2208          perform_or_defer_access_check (TYPE_BINFO (access_type), decl,

(gdb) list
2203         QUALIFYING_SCOPE is also non-null.  */
2204      else
2205        {
2206          volatile tree access_type = TREE_TYPE (object);
2207
2208          perform_or_defer_access_check (TYPE_BINFO (access_type), decl,
2209                                         decl, tf_warning_or_error);
2210
2211          /* If the data member was named `C::M', convert `*this' to `C'
2212             first.  */

(gdb) call print_tree(object)
No symbol "print_tree" in current context.
(gdb) call debug_tree(object)
 <ptrmem_cst 0x7ffff7796860
    type <record_type 0x7ffff77a1bd0 type_2 type_6 TI
        size <integer_cst 0x7ffff7625f18 constant 128>
        unit-size <integer_cst 0x7ffff7625f30 constant 16>
        align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7ffff77a1bd0
        fields <field_decl 0x7ffff7652a18 __pfn type <pointer_type
0x7ffff77a1b28>
            unsigned nonaddressable DI psg.cpp.cpp:5:39
            size <integer_cst 0x7ffff7625ed0 constant 64>
            unit-size <integer_cst 0x7ffff7625ee8 constant 8>
            align:64 warn_if_not_align:0 offset_align 128
            offset <integer_cst 0x7ffff7625f00 constant 0>
            bit-offset <integer_cst 0x7ffff7625f48 constant 0> context
<record_type 0x7ffff77a1bd0> chain <field_decl 0x7ffff7652ab0 __delta>>
        ptrmemfunc fn type <pointer_type 0x7ffff77a1b28 type <method_type
0x7ffff77a17e0>
            public unsigned type_6 DI size <integer_cst 0x7ffff7625ed0 64>
unit-size <integer_cst 0x7ffff7625ee8 8>
            align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7ffff77a1b28>
        chain <type_decl 0x7ffff7652b48 __ptrmemfunc_type>>
    constant>

(gdb) call debug_tree(access_type)
 <record_type 0x7ffff77a1bd0 type_2 type_6 TI
    size <integer_cst 0x7ffff7625f18 type <integer_type 0x7ffff76430a8
bitsizetype> constant 128>
    unit-size <integer_cst 0x7ffff7625f30 type <integer_type 0x7ffff7643000
sizetype> constant 16>
    align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7ffff77a1bd0
    fields <field_decl 0x7ffff7652a18 __pfn
        type <pointer_type 0x7ffff77a1b28 type <method_type 0x7ffff77a17e0>
            public unsigned type_6 DI
            size <integer_cst 0x7ffff7625ed0 constant 64>
            unit-size <integer_cst 0x7ffff7625ee8 constant 8>
            align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7ffff77a1b28>
        unsigned nonaddressable DI psg.cpp.cpp:5:39 size <integer_cst
0x7ffff7625ed0 64> unit-size <integer_cst 0x7ffff7625ee8 8>
        align:64 warn_if_not_align:0 offset_align 128
        offset <integer_cst 0x7ffff7625f00 constant 0>
        bit-offset <integer_cst 0x7ffff7625f48 constant 0> context <record_type
0x7ffff77a1bd0>
        chain <field_decl 0x7ffff7652ab0 __delta type <integer_type
0x7ffff7643738 long int>
            nonaddressable DI psg.cpp.cpp:5:39 size <integer_cst 0x7ffff7625ed0
64> unit-size <integer_cst 0x7ffff7625ee8 8>
            align:64 warn_if_not_align:0 offset_align 128 offset <integer_cst
0x7ffff7625f00 0> bit-offset <integer_cst 0x7ffff7625ed0 64> context
<record_type 0x7ffff77a1bd0>>> ptrmemfunc fn type <pointer_type 0x7ffff77a1b28>
    chain <type_decl 0x7ffff7652b48 __ptrmemfunc_type>>

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [Bug c++/101219] [12 Regression] ice in perform_or_defer_access_check since r12-1804-g65870e75616ee435
  2021-06-26  8:57 [Bug c++/101219] New: ice in perform_or_defer_access_check dcb314 at hotmail dot com
                   ` (3 preceding siblings ...)
  2021-07-19 21:26 ` slyfox at gcc dot gnu.org
@ 2021-07-19 21:47 ` slyfox at gcc dot gnu.org
  2021-07-20 23:16 ` slyfox at gcc dot gnu.org
                   ` (5 subsequent siblings)
  10 siblings, 0 replies; 12+ messages in thread
From: slyfox at gcc dot gnu.org @ 2021-07-19 21:47 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #5 from Sergei Trofimovich <slyfox at gcc dot gnu.org> ---
build_ptrmemfunc_type() creates fresh RECORD_TYPE for (each?) __pfn. Should it
probably populate TYPE_BINFO(t) as well?
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/cp/decl.c;h=01d64a16125ec0bb8e3798136472c30f475f96a2;hb=HEAD#l10526

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [Bug c++/101219] [12 Regression] ice in perform_or_defer_access_check since r12-1804-g65870e75616ee435
  2021-06-26  8:57 [Bug c++/101219] New: ice in perform_or_defer_access_check dcb314 at hotmail dot com
                   ` (4 preceding siblings ...)
  2021-07-19 21:47 ` slyfox at gcc dot gnu.org
@ 2021-07-20 23:16 ` slyfox at gcc dot gnu.org
  2021-07-21  0:06 ` msebor at gcc dot gnu.org
                   ` (4 subsequent siblings)
  10 siblings, 0 replies; 12+ messages in thread
From: slyfox at gcc dot gnu.org @ 2021-07-20 23:16 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #6 from Sergei Trofimovich <slyfox at gcc dot gnu.org> ---
gcc internals doc says that binfo should be attached to every class/struct
(RECORD). I'm not sure if this case qualifies. Maybe?

Why this crash happens mechanically? I skimmed through commit 65870e75616ee43
("cp: add support for per-location warning groups.") and found a few places
where warning suppression was removed.

Returning the one around ptrmem prevents the crash from happening:

--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -3326,7 +3326,9 @@ build_ptrmemfunc_access_expr (tree ptrmem, tree
member_name)
        member = DECL_CHAIN (member))
     if (DECL_NAME (member) == member_name)
       break;
-  return build_simple_component_ref (ptrmem, member);
+  tree r = build_simple_component_ref (ptrmem, member);
+  suppress_warning(r);
+  return r;
 }

 /* Given an expression PTR for a pointer, return an expression

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [Bug c++/101219] [12 Regression] ice in perform_or_defer_access_check since r12-1804-g65870e75616ee435
  2021-06-26  8:57 [Bug c++/101219] New: ice in perform_or_defer_access_check dcb314 at hotmail dot com
                   ` (5 preceding siblings ...)
  2021-07-20 23:16 ` slyfox at gcc dot gnu.org
@ 2021-07-21  0:06 ` msebor at gcc dot gnu.org
  2021-07-22 23:20 ` slyfox at gcc dot gnu.org
                   ` (3 subsequent siblings)
  10 siblings, 0 replies; 12+ messages in thread
From: msebor at gcc dot gnu.org @ 2021-07-21  0:06 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #7 from Martin Sebor <msebor at gcc dot gnu.org> ---
Thanks for tracking down the change that triggers the ICE!  I removed the
suppression in a few cases where it served no apparent purpose (wasn't
necessary to suppress warnings exercised by the test suite).  This was not the
primary but a secondary goal of the patch.  Jason is probably in the best
position to answer your questions, as well as why the removed suppression was
there to begin with and whether it should be restored.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [Bug c++/101219] [12 Regression] ice in perform_or_defer_access_check since r12-1804-g65870e75616ee435
  2021-06-26  8:57 [Bug c++/101219] New: ice in perform_or_defer_access_check dcb314 at hotmail dot com
                   ` (6 preceding siblings ...)
  2021-07-21  0:06 ` msebor at gcc dot gnu.org
@ 2021-07-22 23:20 ` slyfox at gcc dot gnu.org
  2021-08-12 18:44 ` cvs-commit at gcc dot gnu.org
                   ` (2 subsequent siblings)
  10 siblings, 0 replies; 12+ messages in thread
From: slyfox at gcc dot gnu.org @ 2021-07-22 23:20 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #8 from Sergei Trofimovich <slyfox at gcc dot gnu.org> ---
Proposed simplistic change as
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575867.html

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [Bug c++/101219] [12 Regression] ice in perform_or_defer_access_check since r12-1804-g65870e75616ee435
  2021-06-26  8:57 [Bug c++/101219] New: ice in perform_or_defer_access_check dcb314 at hotmail dot com
                   ` (7 preceding siblings ...)
  2021-07-22 23:20 ` slyfox at gcc dot gnu.org
@ 2021-08-12 18:44 ` cvs-commit at gcc dot gnu.org
  2021-08-12 18:46 ` slyfox at gcc dot gnu.org
  2021-11-03 18:53 ` ppalka at gcc dot gnu.org
  10 siblings, 0 replies; 12+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-08-12 18:44 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Sergei Trofimovich <slyfox@gcc.gnu.org>:

https://gcc.gnu.org/g:27a1fb385b7fe706f05608e53f3e91d7d3442b8b

commit r12-2883-g27a1fb385b7fe706f05608e53f3e91d7d3442b8b
Author: Sergei Trofimovich <siarheit@google.com>
Date:   Fri Aug 6 16:14:16 2021 +0100

    c++: fix ptrmemfunc template instantiation [PR101219]

    r12-1804 ("cp: add support for per-location warning groups.") among other
    things removed warning suppression from a few places including ptrmemfuncs.

    This exposed a bug in warning detection code as a reference to missing
    BINFO (it's intentionally missing for ptrmemfunc types):

        crash_signal
            gcc/toplev.c:328
        perform_or_defer_access_check(tree_node*, tree_node*, tree_node*, int,
access_failure_info*)
            gcc/cp/semantics.c:490
        finish_non_static_data_member(tree_node*, tree_node*, tree_node*)
            gcc/cp/semantics.c:2208
        ...

    The change special cases ptrmemfuncs in templace substitution by using
    build_ptrmemfunc_access_expr() instead of finish_non_static_data_member().

    gcc/cp/ChangeLog:

            PR c++/101219
            * pt.c (tsubst_copy_and_build): Use build_ptrmemfunc_access_expr
            to construct ptrmemfunc expression instantiation.

    gcc/testsuite/ChangeLog:

            PR c++/101219
            * g++.dg/warn/pr101219.C: New test.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [Bug c++/101219] [12 Regression] ice in perform_or_defer_access_check since r12-1804-g65870e75616ee435
  2021-06-26  8:57 [Bug c++/101219] New: ice in perform_or_defer_access_check dcb314 at hotmail dot com
                   ` (8 preceding siblings ...)
  2021-08-12 18:44 ` cvs-commit at gcc dot gnu.org
@ 2021-08-12 18:46 ` slyfox at gcc dot gnu.org
  2021-11-03 18:53 ` ppalka at gcc dot gnu.org
  10 siblings, 0 replies; 12+ messages in thread
From: slyfox at gcc dot gnu.org @ 2021-08-12 18:46 UTC (permalink / raw)
  To: gcc-bugs

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

Sergei Trofimovich <slyfox at gcc dot gnu.org> changed:

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

--- Comment #10 from Sergei Trofimovich <slyfox at gcc dot gnu.org> ---
Should be fixed in 10.0

^ permalink raw reply	[flat|nested] 12+ messages in thread

* [Bug c++/101219] [12 Regression] ice in perform_or_defer_access_check since r12-1804-g65870e75616ee435
  2021-06-26  8:57 [Bug c++/101219] New: ice in perform_or_defer_access_check dcb314 at hotmail dot com
                   ` (9 preceding siblings ...)
  2021-08-12 18:46 ` slyfox at gcc dot gnu.org
@ 2021-11-03 18:53 ` ppalka at gcc dot gnu.org
  10 siblings, 0 replies; 12+ messages in thread
From: ppalka at gcc dot gnu.org @ 2021-11-03 18:53 UTC (permalink / raw)
  To: gcc-bugs

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

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |12.0
                 CC|                            |ppalka at gcc dot gnu.org

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2021-11-03 18:53 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-26  8:57 [Bug c++/101219] New: ice in perform_or_defer_access_check dcb314 at hotmail dot com
2021-06-26  9:01 ` [Bug c++/101219] " dcb314 at hotmail dot com
2021-06-28  7:25 ` [Bug c++/101219] [12 Regression] ice in perform_or_defer_access_check since r12-1804-g65870e75616ee435 marxin at gcc dot gnu.org
2021-06-28 20:00 ` msebor at gcc dot gnu.org
2021-07-19 21:26 ` slyfox at gcc dot gnu.org
2021-07-19 21:47 ` slyfox at gcc dot gnu.org
2021-07-20 23:16 ` slyfox at gcc dot gnu.org
2021-07-21  0:06 ` msebor at gcc dot gnu.org
2021-07-22 23:20 ` slyfox at gcc dot gnu.org
2021-08-12 18:44 ` cvs-commit at gcc dot gnu.org
2021-08-12 18:46 ` slyfox at gcc dot gnu.org
2021-11-03 18:53 ` ppalka at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).