[Bug fortran/119054] New: ICE on passing optional array to elemental procedure with -pedantic

2025-02-28 Thread zed.three at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119054 Bug ID: 119054 Summary: ICE on passing optional array to elemental procedure with -pedantic Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal

[Bug fortran/115700] New: [10/11/12/13/14 regression] Bogus warning for associate with assumed-length character array

2024-06-28 Thread zed.three at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115700 Bug ID: 115700 Summary: [10/11/12/13/14 regression] Bogus warning for associate with assumed-length character array Product: gcc Version: 10.4.0 Status: UNCONFIRMED

[Bug fortran/111880] [9/10/11/12/13] False positive warning of obsolescent COMMON block with Fortran submodule

2023-10-19 Thread zed.three at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111880 --- Comment #2 from zed.three at gmail dot com --- The common block is in 'third_party_module', rather than 'foo', unless you mean that it is visible from 'foo'? It is still a surprising warning in this location at any rate!

[Bug fortran/111880] New: [9/10/11/12/13] False positive warning of obsolescent COMMON block with Fortran submodule

2023-10-19 Thread zed.three at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111880 Bug ID: 111880 Summary: [9/10/11/12/13] False positive warning of obsolescent COMMON block with Fortran submodule Product: gcc Version: 13.2.1 Status: UNCONFIRMED

[Bug fortran/110585] New: ICE in gfc_compare_expr for findloc with complex literal array

2023-07-07 Thread zed.three at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110585 Bug ID: 110585 Summary: ICE in gfc_compare_expr for findloc with complex literal array Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal

[Bug fortran/110288] New: [11/12/13] Regression: segfault in findloc with allocatable array of allocatable characters

2023-06-16 Thread zed.three at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110288 Bug ID: 110288 Summary: [11/12/13] Regression: segfault in findloc with allocatable array of allocatable characters Product: gcc Version: 11.0 Status: UNCONFIRMED

[Bug libstdc++/109568] [12/13/14 Regression] Spurious "potential null pointer dereference" in shared_ptr_base.h with "-O1"

2023-04-20 Thread zed.three at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109568 --- Comment #5 from zed.three at gmail dot com --- Ah ok, I see the whole thing now. It still feels like a confusing warning, but it seems reasonable that there isn't much that can be done about it.

[Bug libstdc++/109568] [12/13/14 Regression] Spurious "potential null pointer dereference" in shared_ptr_base.h with "-O1"

2023-04-20 Thread zed.three at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109568 --- Comment #3 from zed.three at gmail dot com --- Ah, I see what you mean. Putting in a guard clause if (!var_ref) return false; does indeed silence the warning. But should the warning not be on the `var_ref->empty()` call itself then, in

[Bug libstdc++/109568] New: [12/13 Regression] Spurious "potential null pointer dereference" in shared_ptr_base.h with "-O1"

2023-04-20 Thread zed.three at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109568 Bug ID: 109568 Summary: [12/13 Regression] Spurious "potential null pointer dereference" in shared_ptr_base.h with "-O1" Product: gcc Version: 12.0 Status: UNCONFIRMED

[Bug fortran/105658] New: Passing array component to unlimited polymorphic routine passes wrong slice

2022-05-19 Thread zed.three at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105658 Bug ID: 105658 Summary: Passing array component to unlimited polymorphic routine passes wrong slice Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: no