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

Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: zed.three at gmail dot com Target Milestone: --- The following valid code triggers an ICE when compiled with -pedantic: program elemental_optional implicit none contains

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

Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: zed.three at gmail dot com Target Milestone: --- The following MVCE has a bogus "used uninitialised" warning from the associate var

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

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

Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: zed.three at gmail dot com Target Milestone: --- Created attachment 56152 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56152&action=edit

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

Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: zed.three at gmail dot com Target Milestone: --- Created attachment 55497 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55497&action=edit MVCE for findloc ICE with

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

Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: zed.three at gmail dot com Target Milestone: --- Created attachment 55350 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55350&action=edit

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

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"

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 t

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

Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: zed.three at gmail dot com Target Milestone: --- The following MVCE gives a warning about a potential null derefere

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

: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: zed.three at gmail dot com Target Milestone: --- The following program: program f implicit none type :: foo integer :: member1 integer

[Bug fortran/91300] Wrong runtime error message with allocate and errmsg=

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91300 --- Comment #2 from zed.three at gmail dot com --- Forgive me, but what is stupid here? The perceived wisdom is that it is best practice to always use `stat` with `allocate`, and the addition of `errmsg` now gives us something portable to

[Bug fortran/91300] New: Wrong runtime error message with allocate and errmsg=

Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: zed.three at gmail dot com Target Milestone: --- Created attachment 46644 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46644&action=edit MVCE for wrong runtime error message from allocate The fo

[Bug fortran/80477] [OOP] Polymorphic function result generates memory leak

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80477 zed.three at gmail dot com changed: What|Removed |Added CC||zed.three at gmail dot com

[Bug c++/86025] New: ICE with -Wduplicated-branches and OpenMP critical

Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: zed.three at gmail dot com Target Milestone: --- Created attachment 44221 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44221&action=edit Preprocessed output Compiling the following MVCE with "

[Bug fortran/80392] New: ICE with allocatable polymorphic function result in a procedure pointer component

Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: zed.three at gmail dot com Target Milestone: --- Very similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68196 and https://gcc.gnu.org/bugzilla/show_bug.cgi?id

[Bug fortran/71623] [5/6/7 Regression] Segfault when allocating deferred-length characters to size of a pointer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71623 --- Comment #3 from zed.three at gmail dot com --- Changing the pointer to an allocatable array results in the same behaviour: $ cat allocate_size_mvce.f90 program allocatemvce implicit none character(len=:), allocatable :: string integer

[Bug fortran/71623] New: Segfault when allocating deferred-length characters to size of a pointer

: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: zed.three at gmail dot com Target Milestone: --- Created attachment 38748 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38748&action=edit MVCE for allocation bu