public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/102600] New: [modules] ICE Segmentation fault during GIMPLE pass evrp
@ 2021-10-04 22:16 johelegp at gmail dot com
  2021-10-05  6:52 ` [Bug c++/102600] " rguenth at gcc dot gnu.org
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: johelegp at gmail dot com @ 2021-10-04 22:16 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 102600
           Summary: [modules] ICE Segmentation fault during GIMPLE pass
                    evrp
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: johelegp at gmail dot com
                CC: johelegp at gmail dot com
  Target Milestone: ---

main.cpp:
```C++
import<cstddef>;
void push(std::byte) {}
void write(char v) { push(static_cast<std::byte>(v)); }
int main() { write(char{}); }
```

Compile commands:
```
gcc -std=c++23 -O3 -fmodules-ts -x c++-system-header -c cstddef
gcc -std=c++23 -O3 -fmodules-ts -c main.cpp
```

Output:
```
during GIMPLE pass: evrp
main.cpp: In function ‘void write(char)’:
main.cpp:4:29: internal compiler error: Segmentation fault
    4 | int main() { write(char{}); }
      |                             ^
0x2068f9d internal_error(char const*, ...)
        ???:0
0xca4c68 wi::to_wide(tree_node const*)
        ???:0
0x1f85553 operator_cast::inside_domain_p(generic_wide_int<wide_int_storage>
const&, generic_wide_int<wide_int_storage> const&, irange const&) const
        ???:0
0x1f8c51d operator_cast::fold_pair(irange&, unsigned int, irange const&, irange
const&) const
        ???:0
0x1f8cb6a operator_cast::fold_range(irange&, tree_node*, irange const&, irange
const&, tree_code) const
        ???:0
0x1e723b0 fold_using_range::range_of_range_op(irange&, gimple*, fur_source&)
        ???:0
0x1e73142 fold_using_range::fold_stmt(irange&, gimple*, fur_source&,
tree_node*)
        ???:0
0x1e67484 gimple_ranger::range_of_stmt(irange&, gimple*, tree_node*)
        ???:0
0x1e681ff gimple_ranger::range_of_expr(irange&, tree_node*, gimple*)
        ???:0
0x14ec2f1 range_query::value_of_expr(tree_node*, gimple*)
        ???:0
0x1e7bda8 rvrp_folder::value_of_expr(tree_node*, gimple*)
        ???:0
0x138eebe substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
        ???:0
0x1e37697 dom_walker::walk(basic_block_def*)
        ???:0
0x138e03d substitute_and_fold_engine::substitute_and_fold(basic_block_def*)
        ???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://bugs.archlinux.org/> for instructions.
```

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

* [Bug c++/102600] [modules] ICE Segmentation fault during GIMPLE pass evrp
  2021-10-04 22:16 [Bug c++/102600] New: [modules] ICE Segmentation fault during GIMPLE pass evrp johelegp at gmail dot com
@ 2021-10-05  6:52 ` rguenth at gcc dot gnu.org
  2021-10-07  3:24 ` johelegp at gmail dot com
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-10-05  6:52 UTC (permalink / raw)
  To: gcc-bugs

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2021-10-05
                 CC|                            |nathan at gcc dot gnu.org
      Known to fail|                            |11.2.1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.  The enumeral type 'byte' ends up without TYPE_MIN/MAX_VALUE which
are eventually not streamed to the module or not re-built at read-in time.
I do see TYPE_MIN/MAX_VALUE being processed in the module code so it must go
wrong elsewhere (maybe at write-out time they are not present?).

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

* [Bug c++/102600] [modules] ICE Segmentation fault during GIMPLE pass evrp
  2021-10-04 22:16 [Bug c++/102600] New: [modules] ICE Segmentation fault during GIMPLE pass evrp johelegp at gmail dot com
  2021-10-05  6:52 ` [Bug c++/102600] " rguenth at gcc dot gnu.org
@ 2021-10-07  3:24 ` johelegp at gmail dot com
  2022-10-25 17:41 ` cvs-commit at gcc dot gnu.org
  2022-10-25 17:48 ` ppalka at gcc dot gnu.org
  3 siblings, 0 replies; 5+ messages in thread
From: johelegp at gmail dot com @ 2021-10-07  3:24 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #2 from Johel Ernesto Guerrero Peña <johelegp at gmail dot com> ---
A workaround:

```C++
export using byte = // Workaround GCC bug 102600.
#if not defined(NDEBUG) or (defined(__clang__) or not defined(__GNUC__))
  std::byte;
#else
  unsigned char;
#endif
```

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

* [Bug c++/102600] [modules] ICE Segmentation fault during GIMPLE pass evrp
  2021-10-04 22:16 [Bug c++/102600] New: [modules] ICE Segmentation fault during GIMPLE pass evrp johelegp at gmail dot com
  2021-10-05  6:52 ` [Bug c++/102600] " rguenth at gcc dot gnu.org
  2021-10-07  3:24 ` johelegp at gmail dot com
@ 2022-10-25 17:41 ` cvs-commit at gcc dot gnu.org
  2022-10-25 17:48 ` ppalka at gcc dot gnu.org
  3 siblings, 0 replies; 5+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-10-25 17:41 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:15d67c11ac0479b08e3badcafdee7e0a6f062349

commit r13-3491-g15d67c11ac0479b08e3badcafdee7e0a6f062349
Author: Patrick Palka <ppalka@redhat.com>
Date:   Tue Oct 25 13:41:18 2022 -0400

    c++ modules: enum TYPE_MIN/MAX_VALUE streaming [PR106848]

    In the frontend, the TYPE_MIN/MAX_VALUE of ENUMERAL_TYPE is the same as
    that of the enum's underlying type (see start_enum).  And the underlying
    type of an enum is always known, even for an opaque enum that lacks a
    definition.

    But currently, we stream TYPE_MIN/MAX_VALUE of an enum only as part of
    its definition.  So if the enum is declared but never defined, the
    ENUMERAL_TYPE we stream in will have empty TYPE_MIN/MAX_VALUE fields
    despite these fields being non-empty on stream out.

    And even if the enum is defined, read_enum_def updates these fields only
    on the main variant of the enum type, so for other variants (that we may
    have streamed in earlier) these fields remain empty.  That these fields
    are unexpectedly empty for some ENUMERAL_TYPEs is ultimately the cause
    of the below two PRs.

    This patch fixes this by making us stream TYPE_MIN/MAX_VALUE directly
    for each ENUMERAL_TYPE rather than as part of the enum's definition, so
    that we naturally also stream these fields for opaque enums (and each
    enum type variant).

            PR c++/106848
            PR c++/102600

    gcc/cp/ChangeLog:

            * module.cc (trees_out::core_vals): Stream TYPE_MAX_VALUE and
            TYPE_MIN_VALUE of ENUMERAL_TYPE.
            (trees_in::core_vals): Likewise.
            (trees_out::write_enum_def): Don't stream them here.
            (trees_in::read_enum_def): Likewise.

    gcc/testsuite/ChangeLog:

            * g++.dg/modules/enum-9_a.H: New test.
            * g++.dg/modules/enum-9_b.C: New test.
            * g++.dg/modules/enum-10_a.H: New test.
            * g++.dg/modules/enum-10_b.C: New test.
            * g++.dg/modules/enum-11_a.H: New test.
            * g++.dg/modules/enum-11_b.C: New test.

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

* [Bug c++/102600] [modules] ICE Segmentation fault during GIMPLE pass evrp
  2021-10-04 22:16 [Bug c++/102600] New: [modules] ICE Segmentation fault during GIMPLE pass evrp johelegp at gmail dot com
                   ` (2 preceding siblings ...)
  2022-10-25 17:41 ` cvs-commit at gcc dot gnu.org
@ 2022-10-25 17:48 ` ppalka at gcc dot gnu.org
  3 siblings, 0 replies; 5+ messages in thread
From: ppalka at gcc dot gnu.org @ 2022-10-25 17:48 UTC (permalink / raw)
  To: gcc-bugs

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |ppalka at gcc dot gnu.org
   Target Milestone|---                         |13.0
         Resolution|---                         |FIXED
                 CC|                            |ppalka at gcc dot gnu.org
             Status|NEW                         |RESOLVED

--- Comment #4 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Fixed.

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

end of thread, other threads:[~2022-10-25 17:48 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-10-04 22:16 [Bug c++/102600] New: [modules] ICE Segmentation fault during GIMPLE pass evrp johelegp at gmail dot com
2021-10-05  6:52 ` [Bug c++/102600] " rguenth at gcc dot gnu.org
2021-10-07  3:24 ` johelegp at gmail dot com
2022-10-25 17:41 ` cvs-commit at gcc dot gnu.org
2022-10-25 17:48 ` 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).