[Bug fortran/61831] New: [4.9.1 regression] runtime error: pointer being freed was not allocated

[Bug fortran/61831] New: [4.9.1 regression] runtime error: pointer being freed was not allocated

[juergen.reuter at desy dot de]

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

            Bug ID: 61831
           Summary: [4.9.1 regression] runtime error: pointer being freed
                    was not allocated
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: juergen.reuter at desy dot de

Our code, WHIZARD 2.2.2, crashes in its self test smtest_5 with the following
runtime error:
whizard(46878) malloc: *** error for object 0x7faf83d7e270: pointer being freed
was not allocated
*** set a breakpoint in malloc_error_break to debug

Program received signal SIGABRT: Process abort signal.

Backtrace for this error:
#0  0x1102fb0b2
#1  0x1102fb86e
#2  0x7fff8a300cf9
Abort trap: 6

Our code can be found here: 
http://www.hepforge.org/archive/whizard/whizard-2.2.2.tar.gz
It can be configured with
./configure --disable-ocaml --prefix=<your path>
then just do make, make install and run the code as
./whizard smtest_5.sin from the share/tests folder.

We try to isolate the problem, but are not confident to manage to do that in a
certain amount of time.

[Bug fortran/61831] [4.9.1 regression] runtime error: pointer being freed was not allocated

[juergen.reuter at desy dot de]

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

Jürgen Reuter <juergen.reuter at desy dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |juergen.reuter at desy dot de
           Severity|normal                      |critical
>From gcc-bugs-return-456649-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jul 17 16:07:04 2014
Return-Path: <gcc-bugs-return-456649-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7529 invoked by alias); 17 Jul 2014 16:07:04 -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 7434 invoked by uid 48); 17 Jul 2014 16:07:01 -0000
From: "thopre01 at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
Date: Thu, 17 Jul 2014 16:07:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: bootstrap
X-Bugzilla-Version: 4.10.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: thopre01 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: 4.10.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61320-4-aONxmROJBz@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61320-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61320-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-07/txt/msg01240.txt.bz2
Content-length: 623

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

--- Comment #52 from thopre01 at gcc dot gnu.org ---
(In reply to Eric Botcazou from comment #51)
>
> TARGET_MEM_REF is supposed to be a valid memory access for the target though
> and, by definition, an unaligned access is not valid for a strict alignment
> target (unless you have a movmisalign pattern), so the problem is the
> TARGET_MEM_REF.

So we just need to identify what changes the MEM_REF that bswap introduce into
a TARGET_MEM_REF without taking alignment into account.

After bswap it's only a MEM_REF:

load_dst_215 = MEM[(unsigned char *)load_src_277];

[Bug fortran/61831] [4.9.1 regression] runtime error: pointer being freed was not allocated

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org
           Severity|critical                    |normal

--- Comment #1 from kargl at gcc dot gnu.org ---
Can you rebuild your code with compile with the -fcheck=all option?

[Bug fortran/61831] [4.9.1 regression] runtime error: pointer being freed was not allocated

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-07-17
     Ever confirmed|0                           |1

--- Comment #3 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Confirmed with 4.9.1 revision r212339. AFAICT revision r210749 is OK. I suspect
r211405 for 4.10 and r212329 for 4.9. Can you revert r212329 and see if the
error disappear?

In any case a reduced test will help a lot.

[Bug fortran/61831] [4.9.1 regression] runtime error: pointer being freed was not allocated

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Thu, Jul 17, 2014 at 07:14:19PM +0000, juergen.reuter at desy dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
> 
> --- Comment #2 from J??rgen Reuter <juergen.reuter at desy dot de> ---
> > Can you rebuild your code with compile with the -fcheck=all option?
> 
> I did. This does not change anything. And it does not give any further
> information.
> 

Thanks.  Unfortunately, I cannot get the code to build.  Without a 
reduced testcase, this is going to be difficult for someone to
debug.

[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
      Known to work|                            |4.9.0
            Version|unknown                     |4.9.1
            Summary|[4.9.1 regression] runtime  |[4.9/ 4.10 Regression]
                   |error: pointer being freed  |runtime error: pointer
                   |was not allocated           |being freed was not
                   |                            |allocated
      Known to fail|                            |4.10.0, 4.9.1

--- Comment #6 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Marked as 4.9/4.10 regression.

[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated

[juergen.reuter at desy dot de]

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

--- Comment #7 from Jürgen Reuter <juergen.reuter at desy dot de> ---
(In reply to Dominique d'Humieres from comment #5)
> > Confirmed with 4.9.1 revision r212339. AFAICT revision r210749 is OK.
> > I suspect r211405 for 4.10 and r212329 for 4.9. Can you revert r212329
> > and see if the error disappear?
> 
> I am afraid that I am the culprit, i.e., r212329: I get the error with
> r209838 + the patch in r212329. However the failures are not exactly the
> same:
> with 4.9.1 revision r212339, it is
> 
> | Creating decay process library for particle W+
> | Process library 'default_lib_dp24': initialized
> | decay_p24_1: W+ => dbar u
> | Process library 'default_lib_dp24': recorded process 'decay_p24_1'
> | decay_p24_2: ?O => sbar c
> | Process library 'default_lib_dp24': recorded process 'decay_p24_2'
> | decay_p24_3:  => e+ nue
> whizard(32872,0x7fff7738d310) malloc: *** error for object 0x7f805874ea60:
> pointer being freed was not allocated
> *** set a breakpoint in malloc_error_break to debug
> 
> while with r209838 + patch, it is
> 
> | Creating decay process library for particle W+
> | Process library 'default_lib_dp24': initialized
> | decay_p24_1: W+ => dbar u
> | Process library 'default_lib_dp24': recorded process 'decay_p24_1'
> | decay_p24_2:  => sbar c
> | Process library 'default_lib_dp24': recorded process 'decay_p24_2'
> whizard(36947,0x7fff7738d310) malloc: *** error for object 0x7fb8c3755810:
> pointer being freed was not allocated
> *** set a breakpoint in malloc_error_break to debug
> 
> For 4.9.0, I get
> 
> | Creating decay process library for particle W+
> | Process library 'default_lib_dp24': initialized
> | decay_p24_1: W+ => dbar u
> | Process library 'default_lib_dp24': recorded process 'decay_p24_1'
> | decay_p24_2: W+ => sbar c
> | Process library 'default_lib_dp24': recorded process 'decay_p24_2'
> | decay_p24_3: W+ => e+ nue
> | Process library 'default_lib_dp24': recorded process 'decay_p24_3'
> | decay_p24_4: W+ => mu+ numu
> | Process library 'default_lib_dp24': recorded process 'decay_p24_4'
> | decay_p24_5: W+ => tau+ nutau
> | Process library 'default_lib_dp24': recorded process 'decay_p24_5'
> | Integrate: current process library needs compilation
> | Process library 'default_lib_dp24': compiling ...
> | Process library 'default_lib_dp24': writing makefile
> | Process library 'default_lib_dp24': writing driver
> | Process library 'default_lib_dp24': creating source code
> rm -f decay_p24_1_i1.f90
> rm -f opr_decay_p24_1_i1.mod
> rm -f decay_p24_1_i1.lo
> rm -f decay_p24_2_i1.f90
> rm -f opr_decay_p24_2_i1.mod
> rm -f decay_p24_2_i1.lo
> rm -f decay_p24_3_i1.f90
> rm -f opr_decay_p24_3_i1.mod
> rm -f decay_p24_3_i1.lo
> rm -f decay_p24_4_i1.f90
> rm -f opr_decay_p24_4_i1.mod
> rm -f decay_p24_4_i1.lo
> rm -f decay_p24_5_i1.f90
> rm -f opr_decay_p24_5_i1.mod
> rm -f decay_p24_5_i1.lo
> /usr/local/bin/omega_SM.opt -o decay_p24_1_i1.f90 -target:whizard
> -target:parameter_module parameters_SM -target:module opr_decay_p24_1_i1
> -target:md5sum 'B42EAF21C73773800B93C9AE1495DD00' -fusion:progress -decay
> 'W+ -> dbar u' 
> make: /usr/local/bin/omega_SM.opt: Command not found
> make: *** [decay_p24_1_i1.f90] Error 127
> | command: make source -j1 -f default_lib_dp24.makefile
> | Return code = 512
> *****************************************************************************
> *
> *****************************************************************************
> *
> *** FATAL ERROR: System command returned with nonzero status code
> *****************************************************************************
> *
> *****************************************************************************
> *
> WHIZARD run aborted.

Great, thanks. The error you get for 4.9.0 is because the executable
omega_SM.opt is absent (this is OCaml code).
>From gcc-bugs-return-456675-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jul 17 22:00:55 2014
Return-Path: <gcc-bugs-return-456675-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 10475 invoked by alias); 17 Jul 2014 22:00:48 -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 10258 invoked by uid 48); 17 Jul 2014 22:00:21 -0000
From: "ian at airs dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug go/59432] [4.9/4.10 regression] sync/atomic FAILs on Solaris/x86
Date: Thu, 17 Jul 2014 22:00:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: go
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ian at airs dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P5
X-Bugzilla-Assigned-To: ian at airs dot com
X-Bugzilla-Target-Milestone: 4.9.2
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-59432-4-WizVKx7Jih@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59432-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59432-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-07/txt/msg01266.txt.bz2
Content-length: 368

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

--- Comment #6 from Ian Lance Taylor <ian at airs dot com> ---
Re: comment #5.  This bug report is about Solaris/x86 and is specific to
Solaris.  If you want to report a bug on any other target, please open a
different bug.  Thanks.

In your case I suspect you need to use the configure option
--with-arch-32=i686.

[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated

[juergen.reuter at desy dot de]

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

--- Comment #8 from Jürgen Reuter <juergen.reuter at desy dot de> ---
Created attachment 33138
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33138&action=edit
Test case
>From gcc-bugs-return-456684-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jul 18 00:27:48 2014
Return-Path: <gcc-bugs-return-456684-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 30512 invoked by alias); 18 Jul 2014 00:27:48 -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 29992 invoked by uid 48); 18 Jul 2014 00:27:38 -0000
From: "xinliangli at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/61776] [4.9/4.10 Regression] ICE: verify_flow_info failed: control flow in the middle of basic block with -fprofile-generate
Date: Fri, 18 Jul 2014 00:27:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.10.0
X-Bugzilla-Keywords: ice-checking
X-Bugzilla-Severity: normal
X-Bugzilla-Who: xinliangli at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.2
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61776-4-6HQw5Wxy11@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61776-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61776-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-07/txt/msg01275.txt.bz2
Content-length: 1620

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

--- Comment #7 from davidxl <xinliangli at gmail dot com> ---
(In reply to wmi from comment #6)
> (In reply to davidxl from comment #5)
> > (In reply to wmi from comment #4)
> > > Can we move the pure/const resetting loop to an earlier place: inside
> > > branch_prob , after instrument_edges and before gsi_commit_edge_inserts
> > > (where stmt_ends_bb_p  is checked), so that gsi_commit_edge_inserts() which
> > > changes cfg could take reset const/pure flags into consideration?
> >
> > Sounds plausible. Have you tried it?
> >
> > David
>
> I just tried but found it was not very easy.
>
> FOR_EACH_DEFINED_FUNCTION (node) {
>   execute_fixup_cfg() and cleanup_tree_cfg()
>   branch_prob()
> }
>
> For the above loop, branch_prob is called one by one for each defined func.
> Because a func could possibly call any other funcs on the cgraph, we need to
> reset the const/pure flags for every defined func before any branch_prob()
> is called, so we cannot put the const/pure reset code inside branch_prob().
>

As you noted below, resetting the flag before branch_prob will lead to cfg
mismatch between instr and profile-use build.

David

> We also cannot move the const/pure reset loop before the branch_prob() loop,
> because execute_fixup_cfg will use const/pure flags to generate different
> cfg. If we put the const/pure reset code before the branch_prob() loop, the
> const/pure reset code should only be executed in intrumentation phase, not
> in annotation phase, so that we may get different cfg between intrumentation
> and annotation.
>
> Wei.

[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated

[juergen.reuter at desy dot de]

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

--- Comment #9 from Jürgen Reuter <juergen.reuter at desy dot de> ---
I added the test case which is at least freed from a lot of docu and the heavy
autotools/libtool setup. The makefile compiles the code and creates a binary
seg_prod. Run this as ./seg_prod input.txt to produce the problem. I try to
reduce this further.
>From gcc-bugs-return-456686-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jul 18 00:41:06 2014
Return-Path: <gcc-bugs-return-456686-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 27009 invoked by alias); 18 Jul 2014 00:41:05 -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 26432 invoked by uid 48); 18 Jul 2014 00:40:54 -0000
From: "carrot at google dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/61837] New: missed loop invariant expression optimization
Date: Fri, 18 Jul 2014 00:41:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.10.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: carrot at google dot com
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 cf_gcchost cf_gcctarget
Message-ID: <bug-61837-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-07/txt/msg01277.txt.bz2
Content-length: 1344

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

            Bug ID: 61837
           Summary: missed loop invariant expression optimization
           Product: gcc
           Version: 4.10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: carrot at google dot com
              Host: x86_64-unknown-linux-gnu
            Target: powerpc64le

Compile following code with trunk compiler and options -O2 -m64 -mcpu=power8

void foo(int *p1, char *p2, int s)
{
  int n, v, i;

  v = 0;
  for (n = 0; n <= 100; n++) {
     for (i = 0; i < s; i++)
        if (p2[i] == n)
           p1[i] = v;
     v += 88;
  }
}

I got

foo:
    addi 9,5,-1
    cmpwi 5,5,0
    rldicl 9,9,0,32
    li 6,0
    li 7,0
    add 5,4,9
    .p2align 4,,15
.L2:
    ble 5,.L6
    addi 8,4,-1
    mr 10,3
    subf 9,8,5     // A
    mtctr 9
    b .L4
    .p2align 4,,15
.L3:
    addi 10,10,4
    bdz .L6
.L4:
    lbzu 9,1(8)
    cmpw 7,9,7
    bne 7,.L3
    stw 6,0(10)
    addi 10,10,4
    bdnz .L4
.L6:
    addi 6,6,88
    addi 7,7,1
    cmpwi 7,6,8888
    extsw 7,7
    extsw 6,6
    bne 7,.L2
    blr

Instruction A computes the inner loop counter, it is loop invariant for the
outer loop, so it can be hoisted out of the outer loop.

[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> I added the test case which is at least freed from a lot of docu and
> the heavy autotools/libtool setup. The makefile compiles the code and
> creates a binary seg_prod. Run this as ./seg_prod input.txt to produce
> the problem. I try to reduce this further.

Thanks for this reduction. However make fails with

make: *** No rule to make target `signal_interface.o', needed by `all'.  Stop.

[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated

[juergen.reuter at desy dot de]

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

--- Comment #11 from Jürgen Reuter <juergen.reuter at desy dot de> ---
Sorry, wrong makefile logic. I will send a working and more reduced case later
this afternoon.
>From gcc-bugs-return-456694-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jul 18 08:45:15 2014
Return-Path: <gcc-bugs-return-456694-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 17954 invoked by alias); 18 Jul 2014 08:45:12 -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 17692 invoked by uid 48); 18 Jul 2014 08:45:02 -0000
From: "kdevel at vogtner dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug go/61840] New: [4.9 regression] sync/atomic FAILs on x86_64-unknown-linux-gnu
Date: Fri, 18 Jul 2014 08:45:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: go
X-Bugzilla-Version: 4.9.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: kdevel at vogtner dot de
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: ian at airs dot com
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-61840-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-07/txt/msg01285.txt.bz2
Content-length: 1590

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

            Bug ID: 61840
           Summary: [4.9 regression] sync/atomic FAILs on
                    x86_64-unknown-linux-gnu
           Product: gcc
           Version: 4.9.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: go
          Assignee: ian at airs dot com
          Reporter: kdevel at vogtner dot de
                CC: cmang at google dot com

first posted in https://gcc.gnu.org/bugzilla/show_bug.cgi?idY432

PASS: runtime/pprof
Aborted

testing.tRunner
        [redacted]/gcc-4.9.1/bld/gcc-4.9.1/libgo/go/testing/testing.go:392

goroutine 1 [chan receive]:
testing.RunTests
        [redacted]/gcc-4.9.1/bld/gcc-4.9.1/libgo/go/testing/testing.go:472
testing.Main
        [redacted]/gcc-4.9.1/bld/gcc-4.9.1/libgo/go/testing/testing.go:403
main.main

[redacted]/gcc-4.9.1/bld/gcc-objdir/x86_64-unknown-linux-gnu/32/libgo/gotest24424/test/_testmain.go:67
FAIL: sync/atomic
make[5]: *** [sync/atomic/check] Fehler 1

Same error in April with 4.9.0:

PASS: runtime/pprof
Aborted

testing.tRunner
        [redacted]/gcc-4.9.0/bld/gcc-4.9.0/libgo/go/testing/testing.go:392

goroutine 1 [chan receive]:
testing.RunTests
        [redacted]/gcc-4.9.0/bld/gcc-4.9.0/libgo/go/testing/testing.go:472
testing.Main
        [redacted]/gcc-4.9.0/bld/gcc-4.9.0/libgo/go/testing/testing.go:403
main.main

[redacted]/gcc-4.9.0/bld/gcc-objdir/x86_64-unknown-linux-gnu/32/libgo/gotest
24306/test/_testmain.go:67
FAIL: sync/atomic
make[5]: *** [sync/atomic/check] Fehler 1

[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated

[dominiq at lps dot ens.fr]

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

--- Comment #12 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
After grabbing the missing *.c and *.f files, I end up ta

gfortran signal_interface.o sprintf_interface.o iso_varying_string.o
system_dependencies.o kinds.o limits.o file_utils.o diagnostics.o mrst2004qed.o
cteq6pdf.o mstw2008.o ct10pdf.o CJpdf.o pythia.o pythia_pdf.o pythia_up.o
unit_tests.o ifiles.o os_interface.o formats.o bytes.o md5.o cputime.o lexers.o
syntax_rules.o parser.o xml.o colors.o hashes.o sorting.o pdg_arrays.o
constants.o c_particles.o lorentz.o CppStringsWrap_dummy.o cpp_strings.o
FastjetWrap_dummy.o fastjet.o jets.o subevents.o variables.o analysis.o
user_code_interface.o expressions.o models.o flavors.o helicities.o
quantum_numbers.o state_matrices.o interactions.o evaluators.o polarizations.o
HepMCWrap_dummy.o hepmc_interface.o particles.o auto_components.o
permutations.o process_constants.o sf_mappings.o beam_structures.o beams.o
sf_aux.o sf_base.o phs_base.o mappings.o fks_regions.o phs_trees.o
phs_forests.o sm_physics.o sm_qcd.o pdf_builtin.o lhapdf5_full_dummy.o
LHAPDFWrap_dummy.o lhapdf.o hoppet_dummy.o hoppet_interface.o sf_pdf_builtin.o
sf_lhapdf.o rng_base.o circe1.o sf_circe1.o circe2.o selectors.o sf_circe2.o
sf_isr.o sf_epa.o sf_ewa.o sf_escan.o sf_beam_events.o sf_user.o phs_single.o
cascades.o phs_wood.o tao_random_numbers.o rng_tao.o mci_base.o mci_midpoint.o
exceptions.o vamp_stat.o utils.o divisions.o linalg.o vamp.o mci_vamp.o
prclib_interfaces.o particle_specifiers.o prc_core_def.o process_libraries.o
prclib_stacks.o slha_interface.o blha_config.o blha_interface.o blha_driver.o
prc_test.o prc_core.o prc_template_me.o prc_omega.o subevt_expr.o
integration_results.o parton_states.o fks_calculation.o phs_fks.o prc_gosam.o
processes.o process_stacks.o event_transforms.o decays.o shower_base.o
shower_partons.o ckkw_pseudo_weights.o shower_core.o shower_topythia.o
muli_basic.o muli_momentum.o muli_interactions.o muli_cuba.o muli_trapezium.o
muli_fibonacci_tree.o muli_aq.o muli_dsigma.o muli_mcint.o muli_remnant.o
muli.o mlm_matching.o ckkw_matching.o hep_common.o shower.o events.o eio_data.o
eio_base.o eio_raw.o eio_checkpoints.o hep_events.o eio_lhef.o eio_hepmc.o
stdhep_dummy.o eio_stdhep.o eio_ascii.o eio_weights.o iterations.o user_files.o
rt_data.o dispatch.o process_configurations.o compilations.o integrations.o
event_streams.o simulations.o radiation_generator.o commands.o libmanager.o
whizard.o -o seg_prod whizard_test.f90
gfortran: error: whizard_test.f90: No such file or directory
make: *** [whizard_test] Error 1

Can you please post the file whizard_test.f90? TIA.

[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated

[juergen.reuter at desy dot de]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 4673 bytes --]

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

--- Comment #14 from Jürgen Reuter <juergen.reuter at desy dot de> ---
By the way, the -fcheck=all triggered other problems with definitely valid
code, so I guess there is another compiler bug.
>From gcc-bugs-return-456696-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jul 18 09:04:06 2014
Return-Path: <gcc-bugs-return-456696-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 13176 invoked by alias); 18 Jul 2014 09:04:05 -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 13126 invoked by uid 48); 18 Jul 2014 09:03:56 -0000
From: "juergen.reuter at desy dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated
Date: Fri, 18 Jul 2014 09:04:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.9.1
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: juergen.reuter at desy dot de
X-Bugzilla-Status: NEW
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: attachments.created
Message-ID: <bug-61831-4-SFkz5XH5pO@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61831-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61831-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-07/txt/msg01287.txt.bz2
Content-length: 314

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

--- Comment #13 from Jürgen Reuter <juergen.reuter at desy dot de> ---
Created attachment 33140
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33140&action=edit
Abridged and hopefully working test case.

In the middle of reducing the test case.
>From gcc-bugs-return-456698-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jul 18 10:03:12 2014
Return-Path: <gcc-bugs-return-456698-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 20917 invoked by alias); 18 Jul 2014 10:03:12 -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 20816 invoked by uid 48); 18 Jul 2014 10:03:06 -0000
From: "vehre at gmx dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/60414] internal compiler error: tree check
Date: Fri, 18 Jul 2014 10:03:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: vehre at gmx dot de
X-Bugzilla-Status: NEW
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: cc attachments.created
Message-ID: <bug-60414-4-U7BkFOTMSL@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60414-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60414-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-07/txt/msg01289.txt.bz2
Content-length: 502

https://gcc.gnu.org/bugzilla/show_bug.cgi?id`414

Andre Vehreschild <vehre at gmx dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vehre at gmx dot de

--- Comment #2 from Andre Vehreschild <vehre at gmx dot de> ---
Created attachment 33141
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id3141&actioníit
Patch to resolve the compile problem

[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated

[dominiq at lps dot ens.fr]

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

--- Comment #15 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> By the way, the -fcheck=all triggered other problems with definitely valid
> code, so I guess there is another compiler bug.

Is it new (as in you don't see them with gfortran 4.9.0)? What are the
problems?

[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated

[dominiq at lps dot ens.fr]

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

--- Comment #16 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
>From the files in the attachment in comment 8, the files that are affected by
this PR are beams.f90, models.f90, and process_libraries.f90:

beams.f90: In function 'beam_data_write':
beams.f90:144:0: internal compiler error: in gfc_conv_expr_reference, at
fortran/trans-expr.c:6519
     prt_name_len = maxval (len (flavor_get_name (beam_data%flv)))

models.f90:1418:0: internal compiler error: in gfc_conv_expr_reference, at
fortran/trans-expr.c:6519
          maxval (len (particle_data_get_name (model%prt, .true.))))

process_libraries.f90: In function 'process_libraries_8':
process_libraries.f90:2429:0: internal compiler error: in
gfc_conv_expr_reference, at fortran/trans-expr.c:6519
          variant = core_def)

(using a version giving an ICE when using the faulty code).

One thing you can try is to make WHIZARD with 4.9.1, then compile the above
files with 4.9.0, make again, and see if the problem goes away.

[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated

[dominiq at lps dot ens.fr]

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

--- Comment #17 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
In comment 16 I have forgotten to list commands.f90

commands.f90: In function 'create_auto_decays':
commands.f90:3695:0: internal compiler error: in gfc_conv_expr_reference, at
fortran/trans-expr.c:6519
             new_prt_spec ([prt_in]), new_prt_spec (prt_out), global)

which seems to be the culprit. If I make the reduced test attached to comment
13 with 4.9.1, the test fails; if I compile commands.f90 with gfortran, make
again, then the test succeeds.

[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated

[juergen.reuter at desy dot de]

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

--- Comment #18 from Jürgen Reuter <juergen.reuter at desy dot de> ---
I didn't get an ICE (yet) but it must in the auto_components part of the code.
I'll try to reduce the case a little further.
>From gcc-bugs-return-456707-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jul 18 12:02:13 2014
Return-Path: <gcc-bugs-return-456707-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 27895 invoked by alias); 18 Jul 2014 12:02:13 -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 27821 invoked by uid 48); 18 Jul 2014 12:02:05 -0000
From: "mliska at suse dot cz" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ipa/61842] New: [4.10 Regression]: Firefox start-up SEGFAULT with LTO and O3
Date: Fri, 18 Jul 2014 12:02:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ipa
X-Bugzilla-Version: 4.10.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mliska at suse dot cz
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
Message-ID: <bug-61842-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-07/txt/msg01298.txt.bz2
Content-length: 5734

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

            Bug ID: 61842
           Summary: [4.10 Regression]: Firefox start-up SEGFAULT with LTO
                    and O3
           Product: gcc
           Version: 4.10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: ipa
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mliska at suse dot cz

Firefox: https://github.com/marxin/gecko-dev/tree/lto-stable (revision:
88a7edf3bab2d1b9a2c140c1f36217f4fbdd1e03)
GCC revision: r212778 with applied
(https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00929.html)

error:
*** Error in
`/home/marxin/Programming/gecko-dev/obj-x86_64-unknown-linux-gnu/dist/bin/firefox':
double free or corruption (fasttop): 0x0000000000587930 ***
======= Backtrace: ========/lib64/libc.so.6(+0x7410f)[0x7ffff737d10f]
/lib64/libc.so.6(+0x7996e)[0x7ffff738296e]
/lib64/libc.so.6(+0x7a647)[0x7ffff7383647]
/home/marxin/Programming/gecko-dev/obj-x86_64-unknown-linux-gnu/dist/bin/libxul.so(+0xa7120f)[0x7ffff2d0120f]
/home/marxin/Programming/gecko-dev/obj-x86_64-unknown-linux-gnu/dist/bin/libxul.so(+0xaf2e54)[0x7ffff2d82e54]
/home/marxin/Programming/gecko-dev/obj-x86_64-unknown-linux-gnu/dist/bin/libxul.so(+0xb54ebc)[0x7ffff2de4ebc]
/home/marxin/Programming/gecko-dev/obj-x86_64-unknown-linux-gnu/dist/bin/libxul.so(+0xb55d81)[0x7ffff2de5d81]
/home/marxin/Programming/gecko-dev/obj-x86_64-unknown-linux-gnu/dist/bin/libxul.so(+0xac9d77)[0x7ffff2d59d77]
/home/marxin/Programming/gecko-dev/obj-x86_64-unknown-linux-gnu/dist/bin/libxul.so(+0x244b27f)[0x7ffff46db27f]
/home/marxin/Programming/gecko-dev/obj-x86_64-unknown-linux-gnu/dist/bin/libxul.so(+0x244b415)[0x7ffff46db415]
/home/marxin/Programming/gecko-dev/obj-x86_64-unknown-linux-gnu/dist/bin/libxul.so(XRE_main+0x203c)[0x7ffff46e221c]
/home/marxin/Programming/gecko-dev/obj-x86_64-unknown-linux-gnu/dist/bin/firefox[0x4074af]
/home/marxin/Programming/gecko-dev/obj-x86_64-unknown-linux-gnu/dist/bin/firefox[0x402fc8]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7ffff732abe5]
/home/marxin/Programming/gecko-dev/obj-x86_64-unknown-linux-gnu/dist/bin/firefox[0x403051]

BT:
Program received signal SIGABRT, Aborted.
0x00007ffff733e849 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
56    ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007ffff733e849 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007ffff733fcd8 in __GI_abort () at abort.c:89
#2  0x00007ffff737d114 in __libc_message (do_abort=do_abort@entry=2,
fmt=fmt@entry=0x7ffff7473220 "*** Error in `%s': %s: 0x%s ***\n")
    at ../sysdeps/posix/libc_fatal.c:175
#3  0x00007ffff738296e in malloc_printerr (action=3, str=0x7ffff7473408 "double
free or corruption (fasttop)", ptr=<optimized out>)
    at malloc.c:4916
#4  0x00007ffff7383647 in _int_free (av=<optimized out>, p=0x587920,
have_lock=0) at malloc.c:3772
#5  0x00007ffff2d0120f in operator delete () at
../../../dist/include/mozilla/mozalloc.h:225
#6  __base_dtor (this=<synthetic pointer>) at
../../../dist/include/nsAutoPtr.h:73
#7  nsPrefBranch::RemoveObserver (this=<optimized out>, aDomain=<optimized
out>, aObserver=<optimized out>)
    at
/home/marxin/Programming/gecko-dev/modules/libpref/src/nsPrefBranch.cpp:658
#8  0x00007ffff2d82e54 in nsSocketTransportService::Shutdown (this=0x586690)
    at
/home/marxin/Programming/gecko-dev/netwerk/base/src/nsSocketTransportService2.cpp:537
#9  0x00007ffff2de4ebc in nsIOService::SetOffline (this=0x582260,
offline=<optimized out>)
    at /home/marxin/Programming/gecko-dev/netwerk/base/src/nsIOService.cpp:748
#10 0x00007ffff2de5d81 in nsIOService::Observe (this=0x582260,
subject=<optimized out>, topic=<optimized out>,
    data=0x7ffff56bd7a0 <nsXREDirProvider::DoShutdown()::kShutdownPersist>
u"shutdown-persist")
    at /home/marxin/Programming/gecko-dev/netwerk/base/src/nsIOService.cpp:918
#11 0x00007ffff2d59d77 in NotifyObservers (
    someData=0x7ffff56bd7a0 <nsXREDirProvider::DoShutdown()::kShutdownPersist>
u"shutdown-persist",
    aTopic=0x7ffff542f899 "profile-change-net-teardown", aSubject=0x0,
this=<optimized out>)
    at /home/marxin/Programming/gecko-dev/xpcom/ds/nsObserverList.cpp:96
#12 nsObserverService::NotifyObservers (this=0x57b8f0, aSubject=0x0,
aTopic=0x7ffff542f899 "profile-change-net-teardown",
    someData=0x7ffff56bd7a0 <nsXREDirProvider::DoShutdown()::kShutdownPersist>
u"shutdown-persist")
    at /home/marxin/Programming/gecko-dev/xpcom/ds/nsObserverService.cpp:303
#13 0x00007ffff46db27f in _ZN16nsXREDirProvider10DoShutdownEv.part.17
(this=0x7fffffffc220)
    at /home/marxin/Programming/gecko-dev/toolkit/xre/nsXREDirProvider.cpp:853
#14 0x00007ffff46db415 in DoShutdown (this=<optimized out>) at
/home/marxin/Programming/gecko-dev/toolkit/xre/nsAppRunner.cpp:1204
#15 __base_dtor  (this=0x50bdc0) at
/home/marxin/Programming/gecko-dev/toolkit/xre/nsAppRunner.cpp:1196
#16 0x00007ffff46e221c in XRE_main (aAppData=<optimized out>, argv=<optimized
out>, argc=<optimized out>, this=<optimized out>)
    at /home/marxin/Programming/gecko-dev/toolkit/xre/nsAppRunner.cpp:4109
#17 XRE_main (argcx64321, argv=0x50bdc0, aAppData=0x1, aFlagsB94967295)
    at /home/marxin/Programming/gecko-dev/toolkit/xre/nsAppRunner.cpp:4298
#18 0x00000000004074af in do_main(int, char**, nsIFile*) [clone .lto_priv.42]
(argc=argc@entry=1, argv=argv@entry=0x7fffffffdac8,
    xreDirectory=0x415010) at
/home/marxin/Programming/gecko-dev/browser/app/nsBrowserApp.cpp:282
#19 0x0000000000402fc8 in main (argc=1, argv=0x7fffffffdac8) at
/home/marxin/Programming/gecko-dev/browser/app/nsBrowserApp.cpp:643

Thank you,
Martin

[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated

[dominiq at lps dot ens.fr]

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

--- Comment #19 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> I didn't get an ICE (yet) but it must in the auto_components part of the code.

You are not supposed to get the ICEs mentioned in comments 16 and 17, they are
due to the build I am using to track down the problem.

Could you can try is to make WHIZARD with 4.9.1, then compile the file
commands.f90 with gfortran 4.9.0, make again, then run your tests and see if
the problem is gone.

> I'll try to reduce the case a little further.

What would help me (although I can do it) is a list of the files needed to
compile commands.f90. Also it would be nice to have a (working) replacement of
the lines

       call prc_config%setup_component (1, &
            new_prt_spec ([prt_in]), new_prt_spec (prt_out), global)

that does not use '[prt_in]'. Otherwise don't spend too much time right now
with reducing as I think I have what I need to do the debugging (fingers
crossed!-).

[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated

[dominiq at lps dot ens.fr]

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

--- Comment #21 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> Ok, Dominique, you mean: compile everything with 4.9.1, then recompile
> commands.f90 with 4.9.0 

Yes

> and build the executable with 4.9.0?

At this point 4.9.0 or 4.9.1 should not matter. So if you use 'make' again I
assume it will use 4.9.1.

[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated

[juergen.reuter at desy dot de]

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

Jürgen Reuter <juergen.reuter at desy dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #33138|0                           |1
        is obsolete|                            |
  Attachment #33140|0                           |1
        is obsolete|                            |

--- Comment #22 from Jürgen Reuter <juergen.reuter at desy dot de> ---
Created attachment 33147
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33147&action=edit
Even more reduced test case

This test case doesn't need an input file anymore, just compile it and run
./seg_prod.
>From gcc-bugs-return-456738-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jul 18 17:57:53 2014
Return-Path: <gcc-bugs-return-456738-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 23810 invoked by alias); 18 Jul 2014 17:57:52 -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 23703 invoked by uid 48); 18 Jul 2014 17:57:46 -0000
From: "pinskia at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug lto/61802] [4.10 Regression] AArch64 execute.exp failures with LTO after r212467
Date: Fri, 18 Jul 2014 17:57:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: lto
X-Bugzilla-Version: 4.10.0
X-Bugzilla-Keywords: lto, wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pinskia at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.10.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on everconfirmed
Message-ID: <bug-61802-4-dpJMZqM9YV@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61802-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61802-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-07/txt/msg01329.txt.bz2
Content-length: 492

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-07-18
     Ever confirmed|0                           |1

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed for me too.

[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated

[dominiq at lps dot ens.fr]

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

--- Comment #23 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Could you test the following patch?

--- ../_clean/gcc/fortran/trans-expr.c    2014-07-07 22:48:04.000000000 +0200
+++ gcc/fortran/trans-expr.c    2014-07-18 21:28:24.000000000 +0200
@@ -6512,7 +6512,10 @@ gfc_conv_expr_reference (gfc_se * se, gf
   if (expr->ts.type == BT_DERIVED && expr->rank
       && !gfc_is_finalizable (expr->ts.u.derived, NULL)
       && expr->ts.u.derived->attr.alloc_comp
-      && expr->expr_type != EXPR_VARIABLE)
+      && expr->expr_type != EXPR_VARIABLE
+      && (expr->expr_type != EXPR_ARRAY
+      || (expr->expr_type == EXPR_ARRAY
+          && expr->ts.u.derived->refs == 1)))
     {
       tree tmp;

[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated

[juergen.reuter at desy dot de]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 11055 bytes --]

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

--- Comment #24 from Jürgen Reuter <juergen.reuter at desy dot de> ---
Created attachment 33153
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33153&action=edit
Further cutting down the example
>From gcc-bugs-return-456748-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jul 18 23:34:31 2014
Return-Path: <gcc-bugs-return-456748-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 30902 invoked by alias); 18 Jul 2014 23:34:30 -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 30845 invoked by uid 48); 18 Jul 2014 23:34:26 -0000
From: "e2cd58e1 at opayq dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/61847] New: bug in gfortran runtime on OSX: digits cut off when reading floating point number
Date: Fri, 18 Jul 2014 23:34:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.8.3
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: e2cd58e1 at opayq dot com
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 attachments.created
Message-ID: <bug-61847-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-07/txt/msg01339.txt.bz2
Content-length: 8855

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

            Bug ID: 61847
           Summary: bug in gfortran runtime on OSX: digits cut off when
                    reading floating point number
           Product: gcc
           Version: 4.8.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: e2cd58e1 at opayq dot com

Created attachment 33154
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id3154&actioníit
source code

Reading a floating point number from a file cuts off digits, depending on the C
locale.

This happens on a Mac when the locale is set to de_DE UTF-8 (note: in german,
the comma is used as separator for digits, but gfortran probably shouldn't do
that). gcc is installed from homebrew, Mac OS X 10.9.4

Attached example was build & executed with

    gfortran -v -save-temps -Wall -Wextra -o bug bugf.f90 bug.c && ./bug

It returns:

     FAIL   1.0000000000000000

But shouldn't return something.

----------------------------
gcc -v
----------------------------

Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr
--with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.3.0
Thread model: posix

----------------------------
gfortran -v
----------------------------

Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/4.8.3_1/libexec/gcc/x86_64-apple-darwin13.2.0/4.8.3/lto-wrapper
Target: x86_64-apple-darwin13.2.0
Configured with: ../configure --build=x86_64-apple-darwin13.2.0
--prefix=/usr/local/Cellar/gcc/4.8.3_1
--enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-4.8
--with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr
--with-mpc=/usr/local/opt/libmpc --with-cloog=/usr/local/opt/cloog
--with-isl=/usr/local/opt/isl --with-system-zlib
--enable-version-specific-runtime-libs --enable-libstdcxx-time=yes
--enable-stage1-checking --enable-checking=release --enable-lto
--disable-werror --with-pkgversion='Homebrew gcc 4.8.3_1'
--with-bugurl=https://github.com/Homebrew/homebrew/issues --enable-plugin
--disable-nls --enable-multilib
Thread model: posix
gcc version 4.8.3 (Homebrew gcc 4.8.3_1)

------------------------------
compilation output for
gfortran -v -save-temps -Wall -Wextra -o bug bugf.f90 bug.c
------------------------------

Driving: gfortran -mmacosx-version-min\x10.9.3 -v -save-temps -Wall -Wextra -o
bug bugf.f90 bug.c -l gfortran -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/4.8.3_1/libexec/gcc/x86_64-apple-darwin13.2.0/4.8.3/lto-wrapper
Target: x86_64-apple-darwin13.2.0
Configured with: ../configure --build=x86_64-apple-darwin13.2.0
--prefix=/usr/local/Cellar/gcc/4.8.3_1
--enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-4.8
--with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr
--with-mpc=/usr/local/opt/libmpc --with-cloog=/usr/local/opt/cloog
--with-isl=/usr/local/opt/isl --with-system-zlib
--enable-version-specific-runtime-libs --enable-libstdcxx-time=yes
--enable-stage1-checking --enable-checking=release --enable-lto
--disable-werror --with-pkgversion='Homebrew gcc 4.8.3_1'
--with-bugurl=https://github.com/Homebrew/homebrew/issues --enable-plugin
--disable-nls --enable-multilib
Thread model: posix
gcc version 4.8.3 (Homebrew gcc 4.8.3_1)
COLLECT_GCC_OPTIONS='-mmacosx-version-min\x10.9.3' '-v' '-save-temps' '-Wall'
'-Wextra' '-o' 'bug' '-shared-libgcc' '-mtune=core2'
 /usr/local/Cellar/gcc/4.8.3_1/libexec/gcc/x86_64-apple-darwin13.2.0/4.8.3/f951
bugf.f90 -fPIC -quiet -dumpbase bugf.f90 -mmacosx-version-min\x10.9.3
-mtune=core2 -auxbase bugf -Wall -Wextra -version -fintrinsic-modules-path
/usr/local/Cellar/gcc/4.8.3_1/lib/gcc/x86_64-apple-darwin13.2.0/4.8.3/finclude
-o bugf.s
GNU Fortran (Homebrew gcc 4.8.3_1) version 4.8.3 (x86_64-apple-darwin13.2.0)
    compiled by GNU C version 4.8.3, GMP version 6.0.0, MPFR version 3.1.2-p8,
MPC version 1.0.2
GGC heuristics: --param ggc-min-expand\x100 --param ggc-min-heapsize\x131072
GNU Fortran (Homebrew gcc 4.8.3_1) version 4.8.3 (x86_64-apple-darwin13.2.0)
    compiled by GNU C version 4.8.3, GMP version 6.0.0, MPFR version 3.1.2-p8,
MPC version 1.0.2
GGC heuristics: --param ggc-min-expand\x100 --param ggc-min-heapsize\x131072
bugf.f90:6.6:

  if (res.ne.1.2345d0) write(*,*) 'FAIL', res
      1
Warning: Inequality comparison for REAL(8) at (1)
COLLECT_GCC_OPTIONS='-mmacosx-version-min\x10.9.3' '-v' '-save-temps' '-Wall'
'-Wextra' '-o' 'bug' '-shared-libgcc' '-mtune=core2'
 as -arch x86_64 -force_cpusubtype_ALL -o bugf.o bugf.s
COLLECT_GCC_OPTIONS='-mmacosx-version-min\x10.9.3' '-v' '-save-temps' '-Wall'
'-Wextra' '-o' 'bug' '-shared-libgcc' '-mtune=core2'
 /usr/local/Cellar/gcc/4.8.3_1/libexec/gcc/x86_64-apple-darwin13.2.0/4.8.3/cc1
-E -quiet -v -D__DYNAMIC__ bug.c -fPIC -mmacosx-version-min\x10.9.3 -mtune=core2
-Wall -Wextra -fpch-preprocess -o bug.i
ignoring nonexistent directory "/usr/local/Cellar/gcc/4.8.3_1/include"
ignoring nonexistent directory
"/usr/local/Cellar/gcc/4.8.3_1/lib/gcc/x86_64-apple-darwin13.2.0/4.8.3/../../../../x86_64-apple-darwin13.2.0/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/Cellar/gcc/4.8.3_1/lib/gcc/x86_64-apple-darwin13.2.0/4.8.3/include
 /usr/local/include

/usr/local/Cellar/gcc/4.8.3_1/lib/gcc/x86_64-apple-darwin13.2.0/4.8.3/include-fixed
 /usr/include
 /System/Library/Frameworks
 /Library/Frameworks
End of search list.
COLLECT_GCC_OPTIONS='-mmacosx-version-min\x10.9.3' '-v' '-save-temps' '-Wall'
'-Wextra' '-o' 'bug' '-shared-libgcc' '-mtune=core2'
 /usr/local/Cellar/gcc/4.8.3_1/libexec/gcc/x86_64-apple-darwin13.2.0/4.8.3/cc1
-fpreprocessed bug.i -fPIC -quiet -dumpbase bug.c -mmacosx-version-min\x10.9.3
-mtune=core2 -auxbase bug -Wall -Wextra -version -o bug.s
GNU C (Homebrew gcc 4.8.3_1) version 4.8.3 (x86_64-apple-darwin13.2.0)
    compiled by GNU C version 4.8.3, GMP version 6.0.0, MPFR version 3.1.2-p8,
MPC version 1.0.2
GGC heuristics: --param ggc-min-expand\x100 --param ggc-min-heapsize\x131072
GNU C (Homebrew gcc 4.8.3_1) version 4.8.3 (x86_64-apple-darwin13.2.0)
    compiled by GNU C version 4.8.3, GMP version 6.0.0, MPFR version 3.1.2-p8,
MPC version 1.0.2
GGC heuristics: --param ggc-min-expand\x100 --param ggc-min-heapsize\x131072
Compiler executable checksum: eb08082bfa130f9363d9c840483f8fa0
COLLECT_GCC_OPTIONS='-mmacosx-version-min\x10.9.3' '-v' '-save-temps' '-Wall'
'-Wextra' '-o' 'bug' '-shared-libgcc' '-mtune=core2'
 as -arch x86_64 -force_cpusubtype_ALL -o bug.o bug.s
Reading specs from
/usr/local/Cellar/gcc/4.8.3_1/lib/gcc/x86_64-apple-darwin13.2.0/4.8.3/libgfortran.spec
rename spec lib to liborig
COLLECT_GCC_OPTIONS='-mmacosx-version-min\x10.9.3' '-v' '-save-temps' '-Wall'
'-Wextra' '-o' 'bug' '-shared-libgcc' '-mtune=core2'
COMPILER_PATH=/usr/local/Cellar/gcc/4.8.3_1/libexec/gcc/x86_64-apple-darwin13.2.0/4.8.3/:/usr/local/Cellar/gcc/4.8.3_1/libexec/gcc/x86_64-apple-darwin13.2.0/4.8.3/:/usr/local/Cellar/gcc/4.8.3_1/libexec/gcc/x86_64-apple-darwin13.2.0/:/usr/local/Cellar/gcc/4.8.3_1/lib/gcc/x86_64-apple-darwin13.2.0/4.8.3/:/usr/local/Cellar/gcc/4.8.3_1/lib/gcc/x86_64-apple-darwin13.2.0/
LIBRARY_PATH=/usr/local/Cellar/gcc/4.8.3_1/lib/gcc/x86_64-apple-darwin13.2.0/4.8.3/:/usr/local/Cellar/gcc/4.8.3_1/lib/gcc/x86_64-apple-darwin13.2.0/4.8.3/../../../:/usr/lib/
COLLECT_GCC_OPTIONS='-mmacosx-version-min\x10.9.3' '-v' '-save-temps' '-Wall'
'-Wextra' '-o' 'bug' '-shared-libgcc' '-mtune=core2'

/usr/local/Cellar/gcc/4.8.3_1/libexec/gcc/x86_64-apple-darwin13.2.0/4.8.3/collect2
-dynamic -arch x86_64 -macosx_version_min 10.9.3 -weak_reference_mismatches
non-weak -o bug
-L/usr/local/Cellar/gcc/4.8.3_1/lib/gcc/x86_64-apple-darwin13.2.0/4.8.3
-L/usr/local/Cellar/gcc/4.8.3_1/lib/gcc/x86_64-apple-darwin13.2.0/4.8.3/../../..
bugf.o bug.o -lgfortran -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc
-lquadmath -lm -lgcc_ext.10.5 -lgcc -lSystem -v
collect2 version 4.8.3
/usr/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.9.3
-weak_reference_mismatches non-weak -o bug
-L/usr/local/Cellar/gcc/4.8.3_1/lib/gcc/x86_64-apple-darwin13.2.0/4.8.3
-L/usr/local/Cellar/gcc/4.8.3_1/lib/gcc/x86_64-apple-darwin13.2.0/4.8.3/../../..
bugf.o bug.o -lgfortran -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc
-lquadmath -lm -lgcc_ext.10.5 -lgcc -lSystem -v
@(#)PROGRAM:ld  PROJECT:ld64-236.4
configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 armv6m armv7m
armv7em
Library search paths:
    /usr/local/Cellar/gcc/4.8.3_1/lib/gcc/x86_64-apple-darwin13.2.0/4.8.3
    /usr/local/Cellar/gcc/4.8.3_1/lib
    /usr/lib
    /usr/local/lib
Framework search paths:
    /Library/Frameworks/
    /System/Library/Frameworks/

[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated

[juergen.reuter at desy dot de]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 5074 bytes --]

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

--- Comment #25 from Jürgen Reuter <juergen.reuter at desy dot de> ---
Created attachment 33158
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33158&action=edit
Reduced test case, 140 lines
>From gcc-bugs-return-456796-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Jul 20 10:54:51 2014
Return-Path: <gcc-bugs-return-456796-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 25510 invoked by alias); 20 Jul 2014 10:54:49 -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 25385 invoked by uid 48); 20 Jul 2014 10:54:46 -0000
From: "juergen.reuter at desy dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated
Date: Sun, 20 Jul 2014 10:54:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.9.1
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: juergen.reuter at desy dot de
X-Bugzilla-Status: NEW
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-61831-4-8KoKiHNIki@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61831-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61831-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-07/txt/msg01387.txt.bz2
Content-length: 403

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

--- Comment #26 from Jürgen Reuter <juergen.reuter at desy dot de> ---
I cooked down the problem to a 140 line test case with which you should be able
to find the culprit. Just do:
gfortran iso_varying_string.o whizard_test.f90 
and run
./a.out
It doesn't need any more input files, and only depends on the standard
iso_varying_string.f90.
>From gcc-bugs-return-456797-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Jul 20 10:55:08 2014
Return-Path: <gcc-bugs-return-456797-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 27694 invoked by alias); 20 Jul 2014 10:55:07 -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 27455 invoked by uid 48); 20 Jul 2014 10:55:03 -0000
From: "agner at agner dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/61855] New: _MM_MANTISSA_NORM_ENUM in avx512intrin.h disabled when optimization off
Date: Sun, 20 Jul 2014 10:55:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.10.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: agner at agner dot 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 attachments.created
Message-ID: <bug-61855-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-07/txt/msg01388.txt.bz2
Content-length: 802

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

            Bug ID: 61855
           Summary: _MM_MANTISSA_NORM_ENUM in avx512intrin.h disabled when
                    optimization off
           Product: gcc
           Version: 4.10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: agner at agner dot org

Created attachment 33159
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id3159&actioníit
test code to replicate bug

Definitions  _MM_MANTISSA_NORM_ENUM and _MM_MANTISSA_SIGN_ENUM in
avx512intrin.h are disabled when optimization is off.

To replicate error, compile attached file with
gcc -c -mavx512f -O0 bug2.c

Workaround: gcc -c -mavx512f -O1 bug2.c

[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated

[juergen.reuter at desy dot de]

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

--- Comment #27 from Jürgen Reuter <juergen.reuter at desy dot de> ---
Dominique, I tested your proposed fix from 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831#c23
But it doesn't work, the problem still occurs.
>From gcc-bugs-return-456799-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Jul 20 12:05:14 2014
Return-Path: <gcc-bugs-return-456799-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 21010 invoked by alias); 20 Jul 2014 12:05:13 -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 20752 invoked by uid 55); 20 Jul 2014 12:05:03 -0000
From: "yroux at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/61154] [4.10 Regression][ARM] wide-int merge introduced regressions in vshuf tests
Date: Sun, 20 Jul 2014 12:05: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: 4.10.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: yroux at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: ramana at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.10.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61154-4-idGzeui4D6@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61154-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61154-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-07/txt/msg01390.txt.bz2
Content-length: 841

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

--- Comment #11 from yroux at gcc dot gnu.org ---
Author: yroux
Date: Sun Jul 20 12:04:22 2014
New Revision: 212866

URL: https://gcc.gnu.org/viewcvs?rev!2866&root=gcc&view=rev
Log:
2014-07-20  Yvan Roux  <yvan.roux@linaro.org>

        Revert:
        2014-07-16  Yvan Roux  <yvan.roux@linaro.org>

        Backport from trunk r211129.
        2014-06-02  Ramana Radhakrishnan  <ramana.radhakrishnan@arm.com>

        PR target/61154
        * config/arm/arm.h (TARGET_SUPPORTS_WIDE_INT): Define.
        * config/arm/arm.md (mov64 splitter): Replace const_double_operand
        with immediate_operand.


Modified:
    branches/linaro/gcc-4_9-branch/gcc/ChangeLog.linaro
    branches/linaro/gcc-4_9-branch/gcc/config/arm/arm.h
    branches/linaro/gcc-4_9-branch/gcc/config/arm/arm.md

[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated

[dominiq at lps dot ens.fr]

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

--- Comment #28 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> Created attachment 33158 [details]
> Reduced test case, 140 lines

Further reduced to

program main
  implicit none

  type :: string_t
     character(LEN=1), dimension(:), allocatable :: chars
  end type string_t

  type(string_t) :: prt_in
  integer :: i
  prt_in = string_t(["W"])
  do i = 1, 16
     print *, i
     call process_configuration (new_prt_spec ([prt_in]))
  end do

contains

  elemental function new_prt_spec (name) result (prt_spec)
    type(string_t), intent(in) :: name
    type(string_t) :: prt_spec
  end function new_prt_spec

  subroutine process_configuration (prt_in)
    type(string_t), dimension(:), intent(in) :: prt_in
  end subroutine process_configuration

end program main

and it does not require iso_varying_string!-)

With 4.9.0 it counts up to 16, while with 4.9.1 and 4.10 with/without the patch
in comment 23 it gives

           1
           2
a.out(71763,0x7fff7bc1d310) malloc: *** error for object 0x7fe788e00000:
pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
...

[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated

[juergen.reuter at desy dot de]

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

--- Comment #29 from Jürgen Reuter <juergen.reuter at desy dot de> ---
A trivial workaround for the problem is to replace
(In reply to Dominique d'Humieres from comment #28)
> > Created attachment 33158 [details]
> > Reduced test case, 140 lines
> 
> Further reduced to
> 
> program main
>   implicit none
> 
>   type :: string_t
>      character(LEN=1), dimension(:), allocatable :: chars
>   end type string_t
>   
>   type(string_t) :: prt_in
>   integer :: i
>   prt_in = string_t(["W"])
>   do i = 1, 16
>      print *, i
>      call process_configuration (new_prt_spec ([prt_in]))
>   end do
> 
> contains
> 
>   elemental function new_prt_spec (name) result (prt_spec)
>     type(string_t), intent(in) :: name
>     type(string_t) :: prt_spec
>   end function new_prt_spec
> 
>   subroutine process_configuration (prt_in)
>     type(string_t), dimension(:), intent(in) :: prt_in
>   end subroutine process_configuration
> 
> end program main
> 
> and it does not require iso_varying_string!-)
> 
> With 4.9.0 it counts up to 16, while with 4.9.1 and 4.10 with/without the
> patch in comment 23 it gives
> 
>            1
>            2
> a.out(71763,0x7fff7bc1d310) malloc: *** error for object 0x7fe788e00000:
> pointer being freed was not allocated
> *** set a breakpoint in malloc_error_break to debug
> ...

A trivial workaround is to replace 
call process_configuration (new_prt_spec ([prt_in]))
by
call process_configuration ([new_prt_spec (prt_in)])
However, nevertheless you would want to understand why the elemental function
causes a malloc crash for dim 1 arrays and works for scalars and dim > 1 arrays
as input.
>From gcc-bugs-return-456813-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Jul 20 18:38:31 2014
Return-Path: <gcc-bugs-return-456813-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 10019 invoked by alias); 20 Jul 2014 18:38:30 -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 9695 invoked by uid 48); 20 Jul 2014 18:38:18 -0000
From: "danglin at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/61853] [4.9,4.10 Regression] ICE: SIGSEGV in store_field
Date: Sun, 20 Jul 2014 18:38:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: danglin at gcc dot gnu.org
X-Bugzilla-Status: NEW
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-61853-4-o4PeaOF7ld@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61853-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61853-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-07/txt/msg01404.txt.bz2
Content-length: 4808

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

--- Comment #7 from John David Anglin <danglin at gcc dot gnu.org> ---
Regarding the record type:

(gdb) p debug_tree ((tree)0xfab48600)
 <record_type 0xfab48600 Energy sizes-gimplified asm_written needs-constructing
type_1 type_5 DF
    size <integer_cst 0xfacf4378 type <integer_type 0xfad06120 bitsizetype>
constant 64>
    unit size <integer_cst 0xfacf4390 type <integer_type 0xfad060c0 sizetype>
constant 8>
    align 64 symtab -145262192 alias set -1 canonical type 0xfab44d20
    fields <field_decl 0xf9ded720 rawValue_
        type <real_type 0xfad06ba0 double sizes-gimplified asm_written type_6
DF size <integer_cst 0xfacf4378 64> unit size <integer_cst 0xfacf4390 8>
            align 64 symtab -85994080 alias set 8 canonical type 0xfad06ba0
precision 64
            pointer_to_this <pointer_type 0xfad06cc0> reference_to_this
<reference_type 0xfa6f5f60>>
        used private nonlocal decl_3 DF file
../include/ThePEG/Config/PhysicalQty.h line 162 col 10 size <integer_cst
0xfacf4378 64> unit size <integer_cst 0xfacf4390 8>
        align 64 offset_align 64
        offset <integer_cst 0xfacf4348 constant 0>
        bit offset <integer_cst 0xfacf43a8 constant 0> context <record_type
0xfab44d20 Qty>
        chain <type_decl 0xf9de8480 Qty type <record_type 0xf9de84e0 Qty>
            used external nonlocal suppress-debug decl_4 VOID file
../include/ThePEG/Config/PhysicalQty.h line 82 col 1
            align 8 context <record_type 0xfab44d20 Qty> result <record_type
0xfab44d20 Qty>
            chain <type_decl 0xf9deb420 Squared>>> context <namespace_decl
0xfad7ed20 ThePEG>
    full-name "ThePEG::Units::Energy"
    needs-constructor X() X(constX&) this=(X&) n_parents=0 use_template=1
interface-unknown
    pointer_to_this <pointer_type 0xf7ed7300> reference_to_this <reference_type
0xf7f18a20> chain <type_decl 0xfab48000 Qty>>
$2 = void


(gdb) p debug_tree ((tree)0xf7f1a980)
 <function_decl 0xf7f1a980
_ZTv0_n64_NK6ThePEG23ConstituentParticleData15constituentMassEv
    type <method_type 0xf7f13ba0
        type <record_type 0xfab48600 Energy sizes-gimplified asm_written
needs-constructing type_1 type_5 DF
            size <integer_cst 0xfacf4378 constant 64>
            unit size <integer_cst 0xfacf4390 constant 8>
            align 64 symtab -145262192 alias set -1 canonical type 0xfab44d20
fields <field_decl 0xf9ded720 rawValue_> context <namespace_decl 0xfad7ed20
ThePEG>
            full-name "ThePEG::Units::Energy"
            needs-constructor X() X(constX&) this=(X&) n_parents=0
use_template=1 interface-unknown
            pointer_to_this <pointer_type 0xf7ed7300> reference_to_this
<reference_type 0xf7f18a20> chain <type_decl 0xfab48000 Qty>>
        SI
        size <integer_cst 0xfacf4318 constant 32>
        unit size <integer_cst 0xfacf4330 constant 4>
        align 32 symtab 0 alias set -1 canonical type 0xf7f13c60 method
basetype <record_type 0xf7f135a0 ConstituentParticleData>
        arg-types <tree_list 0xf7f148b8 value <pointer_type 0xf7f13c00>
            chain <tree_list 0xfacf4b40 value <void_type 0xfad06960 void>>>
        pointer_to_this <pointer_type 0xf7f1bd80>>
    addressable used nothrow public ignored weak virtual decl_5 SI file
ConstituentParticleData.h line 57 col 18 align 32 context <record_type
0xf7f135a0 ConstituentParticleData> initial <block 0xf73f1d58>
    result <result_decl 0xf71ef960 D.88242 type <record_type 0xfab48600 Energy>
        used ignored regdecl DF file ConstituentParticleData.h line 57 col 18
size <integer_cst 0xfacf4378 64> unit size <integer_cst 0xfacf4390 8>
        align 64 context <function_decl 0xf7f1a980
_ZTv0_n64_NK6ThePEG23ConstituentParticleData15constituentMassEv>
        (parallel:BLK [
        (expr_list:REG_DEP_TRUE (reg:DI 101 [ <retval> ])
            (const_int 0 [0]))
    ])>
    full-name "virtual ThePEG::Units::Energy
ThePEG::ConstituentParticleData::_ZTv0_n64_NK6ThePEG23ConstituentParticleData15constituentMassEv()
const"

    arguments <parm_decl 0xf7f21f00 this
        type <pointer_type 0xf7f13cc0 type <record_type 0xf7f13b40
ConstituentParticleData>
            readonly sizes-gimplified public unsigned SI size <integer_cst
0xfacf4318 32> unit size <integer_cst 0xfacf4330 4>
            align 32 symtab -157156016 alias set -1 canonical type 0xf7f13cc0>
        readonly used unsigned SI file ConstituentParticleData.h line 57 col 36
size <integer_cst 0xfacf4318 32> unit size <integer_cst 0xfacf4330 4>
        align 32 context <function_decl 0xf7f1a980
_ZTv0_n64_NK6ThePEG23ConstituentParticleData15constituentMassEv>
        (reg/f:SI 102 [ this ]) arg-type <pointer_type 0xf7f13cc0>
        incoming-rtl (reg:SI 26 %r26 [ this ])>
    struct-function 0xf7880c98>

I'm not sure I can answer your first question.

[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikael at gcc dot gnu.org,
                   |                            |pault at gcc dot gnu.org

--- Comment #30 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> A trivial workaround is to replace 
> call process_configuration (new_prt_spec ([prt_in]))
> by
> call process_configuration ([new_prt_spec (prt_in)])

Confirmed.

> However, nevertheless you would want to understand why the elemental
> function causes a malloc crash for dim 1 arrays and works for scalars
> and dim > 1 arrays as input.

Indeed, but I'll need some help!

[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated

[dominiq at lps dot ens.fr]

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

--- Comment #31 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Further reduced test

program main
  implicit none

  type :: string_t
     character(LEN=1), dimension(:), allocatable :: chars
  end type string_t

  type(string_t) :: prt_in, tmp(1)
  integer :: i
  prt_in = string_t(["W"])
  do i = 1, 16
     print *, i
     tmp = new_prt_spec ([prt_in])
  end do

contains

  elemental function new_prt_spec (name) result (prt_spec)
    type(string_t), intent(in) :: name
    type(string_t) :: prt_spec
  end function new_prt_spec

end program main

> However, nevertheless you would want to understand why the elemental
> function causes a malloc crash for dim 1 arrays and works for scalars
> and dim > 1 arrays as input.

The faulty block is not used for scalars.

[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated

[dominiq at lps dot ens.fr]

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

--- Comment #33 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Dear Paul,

> I cannot see yet, where it comes in nor when it was introduced.

Unfortunately I has been introduced by me, see comment 5. The code is

+  if (expr->ts.type == BT_DERIVED && expr->rank
+      && !gfc_is_finalizable (expr->ts.u.derived, NULL)
+      && expr->ts.u.derived->attr.alloc_comp
+      && expr->expr_type != EXPR_VARIABLE)
+    {
+      tree tmp;
+
+      tmp = build_fold_indirect_ref_loc (input_location, se->expr);
+      tmp = gfc_deallocate_alloc_comp (expr->ts.u.derived, tmp, expr->rank);
+      
+      /* The components shall be deallocated before
+         their containing entity.  */
+      gfc_prepend_expr_to_block (&se->post, tmp);
+    }

Question: what condition should be added to the 'if' to get a false for
'expr->expr_type == EXPR_ARRAY' and an elemental function?

[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated

[paul.richard.thomas at gmail dot com]

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

--- Comment #34 from paul.richard.thomas at gmail dot com <paul.richard.thomas at gmail dot com> ---
Hi Dominique,

Should one be getting false?  It seems to me that the code looks right.

within the do loop:
new_prt_spec ([string_t's]) produces an array of string_t's whose
char.data is null. It does nothing with the input array.

This output string is fed to process configuration, which does nothing
to it. This is surprising in itself :-)

Finally, your patch comes into play.  This should do nothing if the
char.data's are null, which they should be.

Mystified

Paul

On 21 July 2014 21:56, dominiq at lps dot ens.fr
<gcc-bugzilla@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
>
> --- Comment #33 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> Dear Paul,
>
>> I cannot see yet, where it comes in nor when it was introduced.
>
> Unfortunately I has been introduced by me, see comment 5. The code is
>
> +  if (expr->ts.type == BT_DERIVED && expr->rank
> +      && !gfc_is_finalizable (expr->ts.u.derived, NULL)
> +      && expr->ts.u.derived->attr.alloc_comp
> +      && expr->expr_type != EXPR_VARIABLE)
> +    {
> +      tree tmp;
> +
> +      tmp = build_fold_indirect_ref_loc (input_location, se->expr);
> +      tmp = gfc_deallocate_alloc_comp (expr->ts.u.derived, tmp, expr->rank);
> +
> +      /* The components shall be deallocated before
> +         their containing entity.  */
> +      gfc_prepend_expr_to_block (&se->post, tmp);
> +    }
>
> Question: what condition should be added to the 'if' to get a false for
> 'expr->expr_type == EXPR_ARRAY' and an elemental function?
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.9.3

[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated

[dominiq at lps dot ens.fr]

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

--- Comment #35 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
I see three possibilities for this PR:

(1) Revert r211405 for 5.0 and r212329 for 4.9.
(2) Understand why elemental procedures expose the problem when expr->expr_type
== EXPR_ARRAY.
(3) Apply the conservative patch

--- ../4.9_clean/gcc/fortran/trans-expr.c    2014-10-04 12:59:45.000000000
+0200
+++ ../4.9_work/gcc/fortran/trans-expr.c    2014-10-04 13:11:36.000000000 +0200
@@ -6475,7 +6475,7 @@ gfc_conv_expr_reference (gfc_se * se, gf
   if (expr->ts.type == BT_DERIVED && expr->rank
       && !gfc_is_finalizable (expr->ts.u.derived, NULL)
       && expr->ts.u.derived->attr.alloc_comp
-      && expr->expr_type != EXPR_VARIABLE)
+      && expr->expr_type == EXPR_FUNCTION)
     {
       tree tmp;

--- ../4.9_clean/gcc/testsuite/gfortran.dg/class_array_15.f03    2014-07-07
14:33:14.000000000 +0200
+++ ../4.9_work/gcc/testsuite/gfortran.dg/class_array_15.f03    2014-11-08
14:26:21.000000000 +0100
@@ -115,5 +115,5 @@ subroutine pr54992  ! This test remains 
   bh => bhGet(b,instance=2)
   if (loc (b) .ne. loc(bh%hostNode)) call abort
 end
-! { dg-final { scan-tree-dump-times "builtin_free" 12 "original" } }
+! { dg-final { scan-tree-dump-times "builtin_free" 12 "original" { xfail *-*-*
} } }
 ! { dg-final { cleanup-tree-dump "original" } }

I am not fond of (1).

For (2) I need some help. So far the problem has been looked from the 'if'
block point of view. It may be easier to look at the alloc/free machinery
handling elemental.

I think (3) is probably the best solution for 4.9. What I have not done so far
is a test to check this PR, e.g., the test in comment 31, a test for pr41936,
and open a new PR for the memory leak in gfortran.dg/class_array_15.f03.

Feedback welcomed.

[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated

[mikael at gcc dot gnu.org]

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

--- Comment #36 from Mikael Morin <mikael at gcc dot gnu.org> ---
>    [...]
>     (*(struct string_t[1] * restrict) atmp.7.data)[0] = prt_in;

prt_in.chars.data is copied to atmp.7.data[0].

>    [...]
>    while (1)
>      {
>        [...]
>        D.3430 = (*(struct string_t[1] * restrict) atmp.7.data)[S.10];

atmp.7.data[0].chars.data is copied to D.3430

>        [...]
>        if (D.3430.chars.data != 0B)
>          {
>            __builtin_free ((void *) D.3430.chars.data);
>          }
>        D.3430.chars.data = 0B;

D.3430.chars.data is freed.


So every iteration of the do loop has the side-effect of freeing
prt_in.chars.data.

[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated

[dominiq at lps dot ens.fr]

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

--- Comment #37 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> >        [...]
> >        if (D.3430.chars.data != 0B)
> >          {
> >            __builtin_free ((void *) D.3430.chars.data);
> >          }
> >        D.3430.chars.data = 0B;
>
> D.3430.chars.data is freed.
>
> So every iteration of the do loop has the side-effect of freeing prt_in.chars.data.

Could you please give me a pointer to the code emitting this side-effect?

[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated

[mikael at gcc dot gnu.org]

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

--- Comment #38 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #37)
> > >        [...]
> > >        if (D.3430.chars.data != 0B)
> > >          {
> > >            __builtin_free ((void *) D.3430.chars.data);
> > >          }
> > >        D.3430.chars.data = 0B;
> >
> > D.3430.chars.data is freed.
> >
> > So every iteration of the do loop has the side-effect of freeing prt_in.chars.data.
> 
> Could you please give me a pointer to the code emitting this side-effect?

The code you quoted (the call to free) comes from:

#0  gfc_deallocate_with_status at fortran/trans.c:1279
#1  gfc_trans_dealloc_allocated at fortran/trans-array.c:7428
#2  structure_alloc_comps at fortran/trans-array.c:7760
#3  gfc_deallocate_alloc_comp at fortran/trans-array.c:8060
#4  gfc_conv_expr_reference at fortran/trans-expr.c:7139
#5  gfc_conv_procedure_call at fortran/trans-expr.c:4360
#6  gfc_conv_function_expr at fortran/trans-expr.c:6974
#8  gfc_trans_assignment_1 at /fortran/trans-expr.c:8710
#9  trans_code at fortran/trans.c:1650
#10 gfc_trans_code_cond at fortran/trans.c:1946
#11 gfc_trans_simple_do at fortran/trans-stmt.c:1540
#12 gfc_trans_do at fortran/trans-stmt.c:1703
#13 trans_code at fortran/trans.c:1759
#14 gfc_trans_code at fortran/trans.c:1954
#15 gfc_generate_function_code at fortran/trans-decl.c:5842
#16 gfc_generate_code at fortran/trans.c:1971
#17 translate_all_program_units at fortran/parse.c:5341
#18 gfc_parse_file at fortran/parse.c:5538
#19 gfc_be_parse_file at fortran/f95-lang.c:228
#20 compile_file at toplev.c:594
#21 do_compile at toplev.c:2066
#22 toplev::main at toplev.c:2164
#23 main at main.c:39


However, it's not clear to me where the bug comes from, or at least where the
fix should go.
It's an artefact of temporary management which on one hand avoids deep copies,
but on the other hand frees allocated components as for a regular object, as if
a deep copy had happened before.
By the way, I'm not sure that it's at all correct to avoid deep copies.

[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated

[mikael at gcc dot gnu.org]

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

--- Comment #39 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to Mikael Morin from comment #38)
> By the way, I'm not sure that it's at all correct to avoid deep copies.
This seems to be safe:
as long as the procedure is pure, there is no way it can modify its input data.

> It's an artefact of temporary management which on one hand avoids deep
> copies, but on the other hand frees allocated components as for a regular
> object, as if a deep copy had happened before.
So, the problem is limited to derived types, which basically come from
expressions
of type EXPR_FUNCTION (or its variants EXPR_PPC, EXPR_COMPCALL), EXPR_ARRAY,
and EXPR_STRUCTURE.
A function will do a deep copy, so I think the only problematic cases are
EXPR_ARRAY, and maybe EXPR_STRUCTURE.

[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated

[mikael at gcc dot gnu.org]

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

--- Comment #40 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to Mikael Morin from comment #39)
> A function will do a deep copy, so I think the only problematic cases are
> EXPR_ARRAY, and maybe EXPR_STRUCTURE.

EXPR_STRUCTURE deep-copy variable components, and simple-copy non-variables.

[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated

[mikael at gcc dot gnu.org]

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

--- Comment #41 from Mikael Morin <mikael at gcc dot gnu.org> ---
Created attachment 34846
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34846&action=edit
extended testcase

My work patch is:

Index: trans-expr.c
===================================================================
--- trans-expr.c    (révision 220717)
+++ trans-expr.c    (copie de travail)
@@ -7131,7 +7131,8 @@ gfc_conv_expr_reference (gfc_se * se, gfc_expr * e
   if (expr->ts.type == BT_DERIVED && expr->rank
       && !gfc_is_finalizable (expr->ts.u.derived, NULL)
       && expr->ts.u.derived->attr.alloc_comp
-      && expr->expr_type != EXPR_VARIABLE)
+      && expr->expr_type != EXPR_VARIABLE
+      && expr->expr_type != EXPR_ARRAY)
     {
       tree tmp;


It fails with the above testcase at line 80.
ptr_in in simple-copied twice to elements of an array, which is itself copied
to the temporary structure of the structure constructor.
After using the latter, the temporary structure cleanup code frees ptr_in
(twice).
>From gcc-bugs-return-478201-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Feb 23 17:49:42 2015
Return-Path: <gcc-bugs-return-478201-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15389 invoked by alias); 23 Feb 2015 17:49:42 -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 15324 invoked by uid 48); 23 Feb 2015 17:49:38 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/63888] [5 Regression] bootstrap failed when configured with -with-build-config=bootstrap-asan --disable-werror
Date: Mon, 23 Feb 2015 17:57:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: bootstrap
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63888-4-7WBrUpjZwq@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63888-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63888-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: 2015-02/txt/msg02533.txt.bz2
Content-length: 930

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

--- Comment #36 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Yury Gribov from comment #35)
> (In reply to Kostya Serebryany from comment #34)
> > Frankly, I am not at all motivated to do any significant surgery in the llvm
> > compiler instrumentation because for me everything works fine.
>
> Hm, is this related to GCC at all? Comments mention symbol resolution rules
> (local aliases being one example), I think this is totally orthogonal to
> compiler.

It is related to the implementation of ASAN for PIC code.
GCC registers globals through private aliases (so always registers globals in
the current shared library, no matter whether the symbol in the end is
interposed by another symbol or not), while LLVM registers globals through
their exported symbols (so if a symbol is interposed, it is registered multiple
times by multiple shared libraries).

[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated

[dominiq at lps dot ens.fr]

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

--- Comment #43 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> The testcase passes with it, at the price of leaking memory

Yes: gfortran.dg/alloc_comp_constructor_1.f90 (17 builtin_free instead of 19)
and gfortran.dg/class_array_15.f03 (11 builtin_free instead of 12). I think to
fix this PR without memory leak one has to avoid to free the temporary for
elemental procs

For the reduced test

program main
  implicit none

  integer, parameter :: n = 2

  type :: string_t
     character(LEN=1), dimension(:), allocatable :: chars
  end type string_t

  type :: string_container_t
     type(string_t) :: comp
  end type string_container_t

  type :: string_array_container_t
     type(string_t) :: comp(n)
  end type string_array_container_t

  type(string_t) :: prt_in, tmp, tmpa(n)
  type(string_container_t) :: tmpc, tmpca(n)
  type(string_array_container_t) :: tmpac, tmpaca(n)
  integer :: i, j, k

  do i=1,16

     ! Test without intermediary function
     prt_in = string_t(["A"])
     if (.not. allocated(prt_in%chars)) call abort
     if (any(prt_in%chars .ne. "A")) call abort
     deallocate (prt_in%chars)

     ! scalar elemental function with structure constructor
     prt_in = string_t(["D"])
     if (.not. allocated(prt_in%chars)) call abort
     if (any(prt_in%chars .ne. "D")) call abort
     tmpc = new_prt_spec2 (string_container_t(prt_in))
     if (.not. allocated(prt_in%chars)) call abort
     if (any(prt_in%chars .ne. "D")) call abort
     deallocate (prt_in%chars)
     deallocate(tmpc%comp%chars)

  end do

contains

  elemental function new_prt_spec2 (name) result (prt_spec)
    type(string_container_t), intent(in) :: name
    type(string_container_t) :: prt_spec
    prt_spec = name
  end function new_prt_spec2

end program main

I also see at run time (with/without the patch in comment 42)

a.out(69499,0x7fff748b3300) malloc: *** mach_vm_map(size=18446603339087888384)
failed (error code=3)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x10a9e4c62
#1  0x10a9e3f80
#2  0x7fff8de21f19
Segmentation fault

[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated

[mikael at gcc dot gnu.org]

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

--- Comment #44 from Mikael Morin <mikael at gcc dot gnu.org> ---
Created attachment 34942
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34942&action=edit
Better patch

I'm not working on this, so I'm attaching the current patch in my work tree,
before it's lost.
If I remember correctly, the patch passes the testsuite without regressing.
The test in comment #41 exhibits some leaks with it though.
And I haven't looked yet at Dominique's feedback in comment #43.
Oh, and I have to double check that the gfc_trans_subarray_assign hunk is
really necessary.

[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated

[dominiq at lps dot ens.fr]

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

--- Comment #45 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> Created attachment 34942 [details]
> Better patch

Sorry for the delay, but I noticed this new patch only yesterday!-(

> I'm not working on this, so I'm attaching the current patch in my work tree,
> before it's lost.

With this patch there is no memory leak
gfortran.dg/alloc_comp_constructor_1.f90 (19 builtin_free) and
gfortran.dg/class_array_15.f03 (12 builtin_free).

> If I remember correctly, the patch passes the testsuite without regressing.

With this patch I see a regression for gfortran.dg/alloc_comp_assign_10.f90.

> The test in comment #41 exhibits some leaks with it though.

With the patch I see 33 builtin_free instead of 34 without the patch.

> And I haven't looked yet at Dominique's feedback in comment #43.

The test in comment #41 fails at run time when compiled with
-fsanitize=address. If I take the "complement" of the reduced test posted in
comment #43, everything works fine, but for one builtin_free less.

I did not investigated what is wrong with the test in comment #43 (will do).

> Oh, and I have to double check that the gfc_trans_subarray_assign hunk
> is really necessary.

If you are speaking of the hunk

@@ -6263,7 +6283,7 @@ gfc_trans_subarray_assign (tree dest, gfc_componen

   gfc_conv_expr (&rse, expr);

-  tmp = gfc_trans_scalar_assign (&lse, &rse, cm->ts, true, false, true);
+  tmp = gfc_trans_scalar_assign (&lse, &rse, cm->ts, true, true, true);
   gfc_add_expr_to_block (&body, tmp);

   gcc_assert (rse.ss == gfc_ss_terminator);

I think it is needed, otherwise the test in comment #41 fails at run time with

a.out(89696,0x7fff74744300) malloc: *** mach_vm_map(size=18446603338973675520)
failed (error code=3)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

However the hunk

@@ -4990,7 +5010,7 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol *

       tmp = gfc_deallocate_alloc_comp (e->ts.u.derived, tmp, parm_rank);

-      gfc_add_expr_to_block (&se->post, tmp);
+      gfc_prepend_expr_to_block (&se->post, tmp);
         }

       /* Add argument checking of passing an unallocated/NULL actual to

does not seems necessary, but is the cause of the regression, i.e., no
regression without it.

The patch (without the above hunk) fixes a lot of problems and makes the code
simpler. IMO it should be submitted and the few left issues can be deferred
(with new PRs).

[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated

[dominiq at lps dot ens.fr]

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

--- Comment #46 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> > And I haven't looked yet at Dominique's feedback in comment #43.
>
> The test in comment #41 fails at run time when compiled with -fsanitize=address.
> If I take the "complement" of the reduced test posted in comment #43,
> everything works fine, but for one builtin_free less.
>
> I did not investigated what is wrong with the test in comment #43 (will do).

The problem occurs even with a clean tree. I have filed PR65792 for it.

The test in comment 41 runs without error if compiled with -fsanitize=address
and no valgrind error if I remove/comment the lines 58 and 62:

     tmpc = new_prt_spec2 (string_container_t(prt_in))

and

     deallocate(tmpc%comp%chars)

> The patch (without the above hunk) fixes a lot of problems and makes
> the code simpler. IMO it should be submitted and the few left issues
> can be deferred (with new PRs).

I have bootstrapper 4.9.3 with the patch and I am currently regtesting
gfortran. I am planing to do that same for 5.0.1.

[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated

[mikael at gcc dot gnu.org]

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

Mikael Morin <mikael at gcc dot gnu.org> changed:

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

--- Comment #47 from Mikael Morin <mikael at gcc dot gnu.org> ---
Patch posted: https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01491.html

[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated

[jakub at gcc dot gnu.org]

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

--- Comment #48 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.3 has been released.

[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.3                       |4.9.4

[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated

[mikael at gcc dot gnu.org]

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

--- Comment #49 from Mikael Morin <mikael at gcc dot gnu.org> ---
Author: mikael
Date: Fri Jul 17 09:40:29 2015
New Revision: 225926

URL: https://gcc.gnu.org/viewcvs?rev=225926&root=gcc&view=rev
Log:
Fix PR61831: Side-effect variable component deallocation

gcc/fortran/
2015-07-17  Mikael Morin  <mikael@gcc.gnu.org>
            Dominique d'Humieres  <dominiq@lps.ens.fr>

        PR fortran/61831
        * trans-array.c (gfc_conv_array_parameter): Guard allocatable
        component deallocation code generation with descriptorless
        calling convention flag.
        * trans-expr.c (gfc_conv_expr_reference): Remove allocatable
        component deallocation code generation from revision 212329.
        (expr_may_alias_variables): New function.
        (gfc_conv_procedure_call): New boolean elemental_proc to factor
        check for procedure elemental-ness.  Rename boolean f to nodesc_arg
        and declare it in the outer scope.  Use expr_may_alias_variables,
        elemental_proc and nodesc_arg to decide whether generate allocatable
        component deallocation code.
        (gfc_trans_subarray_assign): Set deep copy flag.

gcc/testsuite/
2015-07-17  Mikael Morin  <mikael@gcc.gnu.org>

        PR fortran/61831
        * gfortran.dg/alloc_comp_auto_array_3.f90: Count the number
        of generated while loops in the tree dump.
        * gfortran.dg/derived_constructor_components_6.f90: New file.


Added:
    trunk/gcc/testsuite/gfortran.dg/derived_constructor_comps_6.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-array.c
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/alloc_comp_auto_array_3.f90

[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated

[dominiq at lps dot ens.fr]

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

--- Comment #50 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Compiling the original test of pr40440 after revision r225926 gives an ICE:

[Book15] f90/bug% gfcp pr40440.f90 iso_varying_string.o
pr40440.f90:69:0:

     call ifile_append_from_string (ifile, var_str (trim (char)))
1
internal compiler error: Segmentation fault: 11

A variant that does not require iso_varying_string ICE with

pr40440_2.f90:2456:0:

           rep_string = substring//extract(work_string,
start=i_target+length_target)//rep_string
1
internal compiler error: Segmentation fault: 11

Should I file a new PR?

[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated

[mikael at gcc dot gnu.org]

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

--- Comment #51 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #50)
> Should I file a new PR?

Yes, please.
Two commits today, two regressions.

[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated

[ubizjak at gmail dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 5911 bytes --]

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

--- Comment #52 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Mikael Morin from comment #51)
> (In reply to Dominique d'Humieres from comment #50)
> > Should I file a new PR?
> 
> Yes, please.
> Two commits today, two regressions.

There is another PR that seems related, PR 64986.
>From gcc-bugs-return-492678-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jul 17 20:06:49 2015
Return-Path: <gcc-bugs-return-492678-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 118711 invoked by alias); 17 Jul 2015 20:06:49 -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 118695 invoked by uid 48); 17 Jul 2015 20:06:44 -0000
From: "mhw at netris dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/66917] New: ARM: NEON: memcpy compiles to vld1 and vst1 with incorrect alignment
Date: Fri, 17 Jul 2015 20:06:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.9.3
X-Bugzilla-Keywords:
X-Bugzilla-Severity: major
X-Bugzilla-Who: mhw at netris dot org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
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 target_milestone attachments.created
Message-ID: <bug-66917-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: 2015-07/txt/msg01568.txt.bz2
Content-length: 3625

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

            Bug ID: 66917
           Summary: ARM: NEON: memcpy compiles to vld1 and vst1 with
                    incorrect alignment
           Product: gcc
           Version: 4.9.3
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mhw at netris dot org
  Target Milestone: ---

Created attachment 36009
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id6009&actioníit
Minimal example code that is miscompiled

The attached C source code is mis-compiled by GCC 4.9.3 with -O3 and
-mfpu=neon.  Calls to memcpy between a uint8_t* parameter and a local variable
are compiled into vld1.64 and vst1.64 instructions with an alignment field that
specifies that the memory address (the uint8_t* parameter) is aligned on a
64-bit boundary, although there is no basis for assuming such an alignment.

Here's the C code:

  #include <stdint.h>
  #include <string.h>

  void
  test_neon_load_store_alignment (const uint8_t *ap,
                                  const uint8_t *bp,
                                  uint8_t *outp)
  {
    union {
      uint64_t u[2];
      uint8_t c[16];
    } a, b;

    memcpy (a.c, ap, 16);
    memcpy (b.c, bp, 16);
    a.u[0] ^= b.u[0];
    a.u[1] ^= b.u[1];
    memcpy (outp, a.c, 16);
  }

When natively compiled with -S -O3 using GCC 4.9.3 configured with
"--build=arm-unknown-linux-gnueabihf --with-arch=armv7-a --with-float=hard
--with-mode=thumb --with-fpu=neon", here's the output:

        .syntax unified
        .arch armv7-a
        .eabi_attribute 27, 3
        .eabi_attribute 28, 1
        .fpu neon
        .eabi_attribute 20, 1
        .eabi_attribute 21, 1
        .eabi_attribute 23, 3
        .eabi_attribute 24, 1
        .eabi_attribute 25, 1
        .eabi_attribute 26, 2
        .eabi_attribute 30, 2
        .eabi_attribute 34, 1
        .eabi_attribute 18, 4
        .thumb
        .file   "foo.c"
        .text
        .align  2
        .global test_neon_load_store_alignment
        .thumb
        .thumb_func
        .type   test_neon_load_store_alignment, %function
test_neon_load_store_alignment:
        @ args = 0, pretend = 0, frame = 0
        @ frame_needed = 0, uses_anonymous_args = 0
        @ link register save eliminated.
        vld1.64 {d16-d17}, [r0:64]
        vld1.64 {d18-d19}, [r1:64]
        veor    q8, q8, q9
        vst1.64 {d16-d17}, [r2:64]
        bx      lr
        .size   test_neon_load_store_alignment,
.-test_neon_load_store_alignment
        .ident  "GCC: (GNU) 4.9.3"
        .section        .note.GNU-stack,"",%progbits

Here, r0 contains ap, r1 contains bp, and r2 contains outp.  The associated
operands of the vld1.64 and vst1.64 instructions are [r<n>:64], which specify
that the memory address is known to be aligned on a 64-bit boundary, although
that is not necessarily the case.

See section A8.6.307 (page A8-602) of the ARM v7 Architecture Reference Manual,
which spells out quite clearly that for this instruction:

  if (address MOD alignment) != 0 then GenerateAlignmentException();

and that in this case, alignment == 8.

This may be related to bug #57271.

If needed, I can provide instructions for how to reproduce the exact same GCC
binary I'm using, and all other software that it depends on, using GNU Guix
<http://gnu.org/s/guix>.

FYI, the attached minimal test case was distilled from code in OpenSSL 1.0.2d
that is miscompiled by GCC 4.9.3 in our armhf port targetting NEON, and leads
to a Bus Error on the Novena laptop.

[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated

[mikael at gcc dot gnu.org]

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

--- Comment #53 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #50)
> Compiling the original test of pr40440 after revision r225926 gives an ICE:
> 
You can try:

Index: trans-array.c
===================================================================
--- trans-array.c       (révision 225979)
+++ trans-array.c       (copie de travail)
@@ -9166,7 +9166,11 @@ gfc_get_proc_ifc_for_expr (gfc_expr *procedure_ref
     return NULL;

   /* Normal procedure case.  */
-  sym = procedure_ref->symtree->n.sym;
+  if (procedure_ref->expr_type == EXPR_FUNCTION
+      && procedure_ref->value.function.esym)
+    sym = procedure_ref->value.function.esym;
+  else
+    sym = procedure_ref->symtree->n.sym;

   /* Typebound procedure case.  */
   for (ref = procedure_ref->ref; ref; ref = ref->next)
>From gcc-bugs-return-492738-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jul 18 11:54:03 2015
Return-Path: <gcc-bugs-return-492738-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 127548 invoked by alias); 18 Jul 2015 11:54:02 -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 127526 invoked by uid 48); 18 Jul 2015 11:53:58 -0000
From: "mikael at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/66929] New: [6 regression] ICE with iso_varying_string
Date: Sat, 18 Jul 2015 11:54:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mikael at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
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 target_milestone
Message-ID: <bug-66929-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: 2015-07/txt/msg01628.txt.bz2
Content-length: 1054

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

            Bug ID: 66929
           Summary: [6 regression] ICE with iso_varying_string
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mikael at gcc dot gnu.org
  Target Milestone: ---

Originally reported by Dominique at
https://gcc.gnu.org/bugzilla/show_bug.cgi?ida831#c50

> Compiling the original test of pr40440 after revision r225926 gives an ICE:
>
> [Book15] f90/bug% gfcp pr40440.f90 iso_varying_string.o
> pr40440.f90:69:0:
>
>      call ifile_append_from_string (ifile, var_str (trim (char)))
> 1
> internal compiler error: Segmentation fault: 11
>
> A variant that does not require iso_varying_string ICE with
>
> pr40440_2.f90:2456:0:
>
>            rep_string = substring//extract(work_string,
> start=i_target+length_target)//rep_string
> 1
> internal compiler error: Segmentation fault: 11
>

[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated

[mikael at gcc dot gnu.org]

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

--- Comment #54 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #50)
> Should I file a new PR?
I opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66929

(In reply to Uroš Bizjak from comment #52)
> There is another PR that seems related, PR 64986.

Is it?  I see no ICE there.
Oh, you mean related to this original bug, not the regression of comment#50?
>From gcc-bugs-return-492742-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jul 18 12:18:11 2015
Return-Path: <gcc-bugs-return-492742-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 13168 invoked by alias); 18 Jul 2015 12:18:10 -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 13108 invoked by uid 48); 18 Jul 2015 12:18:07 -0000
From: "glaubitz at physik dot fu-berlin.de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/66930] New: [5 Regression]: gengtype.c is miscompiled during stage2
Date: Sat, 18 Jul 2015 12:18:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: glaubitz at physik dot fu-berlin.de
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
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 target_milestone cf_gcctarget
Message-ID: <bug-66930-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-07/txt/msg01632.txt.bz2
Content-length: 4529

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

            Bug ID: 66930
           Summary: [5 Regression]: gengtype.c is miscompiled during
                    stage2
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: glaubitz at physik dot fu-berlin.de
                CC: doko at gcc dot gnu.org, kkojima at gcc dot gnu.org,
                    olegendo at gcc dot gnu.org
  Target Milestone: ---
            Target: sh*-*-*

Hello!

As previously discussed in private mail, I am now filing a bug report for the
regression in gcc-5 that was introduced somewhere between r222550 and r225710
which leads to the miscompilation of gcc/gengtype.c when building a native
compiler on SH [1]:

/«PKGBUILDDIR»/build/./prev-gcc/xg++ -B/«PKGBUILDDIR»/build/./prev-gcc/
-B/usr/sh4-linux-gnu/bin/ -nostdinc++
-B/«PKGBUILDDIR»/build/prev-sh4-linux-gnu/libstdc++-v3/src/.libs
-B/«PKGBUILDDIR»/build/prev-sh4-linux-gnu/libstdc++-v3/libsupc++/.libs 
-I/«PKGBUILDDIR»/build/prev-sh4-linux-gnu/libstdc++-v3/include/sh4-linux-gnu 
-I/«PKGBUILDDIR»/build/prev-sh4-linux-gnu/libstdc++-v3/include 
-I/«PKGBUILDDIR»/src/libstdc++-v3/libsupc++
-L/«PKGBUILDDIR»/build/prev-sh4-linux-gnu/libstdc++-v3/src/.libs
-L/«PKGBUILDDIR»/build/prev-sh4-linux-gnu/libstdc++-v3/libsupc++/.libs -c 
-DIN_GCC_FRONTEND -g -O1 -gtoggle -DIN_GCC    -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H
-I. -Ic -I../../src/gcc -I../../src/gcc/c -I../../src/gcc/../include
-I../../src/gcc/../libcpp/include  -I../../src/gcc/../libdecnumber
-I../../src/gcc/../libdecnumber/dpd -I../libdecnumber
-I../../src/gcc/../libbacktrace   -o c/c-objc-common.o -MT c/c-objc-common.o
-MMD -MP -MF c/.deps/c-objc-common.TPo ../../src/gcc/c/c-objc-common.c
/«PKGBUILDDIR»/build/./prev-gcc/xg++ -B/«PKGBUILDDIR»/build/./prev-gcc/
-B/usr/sh4-linux-gnu/bin/ -nostdinc++
-B/«PKGBUILDDIR»/build/prev-sh4-linux-gnu/libstdc++-v3/src/.libs
-B/«PKGBUILDDIR»/build/prev-sh4-linux-gnu/libstdc++-v3/libsupc++/.libs 
-I/«PKGBUILDDIR»/build/prev-sh4-linux-gnu/libstdc++-v3/include/sh4-linux-gnu 
-I/«PKGBUILDDIR»/build/prev-sh4-linux-gnu/libstdc++-v3/include 
-I/«PKGBUILDDIR»/src/libstdc++-v3/libsupc++
-L/«PKGBUILDDIR»/build/prev-sh4-linux-gnu/libstdc++-v3/src/.libs
-L/«PKGBUILDDIR»/build/prev-sh4-linux-gnu/libstdc++-v3/libsupc++/.libs -c 
-DIN_GCC_FRONTEND -g -O1 -gtoggle -DIN_GCC    -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H
-I. -Ic -I../../src/gcc -I../../src/gcc/c -I../../src/gcc/../include
-I../../src/gcc/../libcpp/include  -I../../src/gcc/../libdecnumber
-I../../src/gcc/../libdecnumber/dpd -I../libdecnumber
-I../../src/gcc/../libbacktrace   -o c/c-parser.o -MT c/c-parser.o -MMD -MP -MF
c/.deps/c-parser.TPo ../../src/gcc/c/c-parser.c
In file included from ../../src/gcc/c/c-parser.c:15558:0:
./gt-c-c-parser.h: In function 'void gt_ggc_mx_c_parser(void*)':
./gt-c-c-parser.h:41:7: error: break statement not within loop or switch
       break;
       ^
./gt-c-c-parser.h:42:9: error: break statement not within loop or switch
         break;
         ^
(...)

I am currently trying to pinpoint in which SVN snapshot the issue was
introduced since previous snapshots did not suffer from this bug [2]. To make
sure it's not an issue with the host compiler, I am currently doing testbuilds
on my SH7785LCR board of various SVN snapshots to gather more build logs which
should hopefully help to identify the change responsible for the regression.

These logs are collected in [3].

Cheers,
Adrian

> [1] http://buildd.debian-ports.org/status/fetch.php?pkg=gcc-5&arch=sh4&ver=5.1.1-2&stamp=1430520056
> [2] http://buildd.debian-ports.org/status/fetch.php?pkg=gcc-5&arch=sh4&ver=5.1.1-14&stamp=1436979741
> [3] https://people.debian.org/~glaubitz/sh4-gcc-5-tests/
>From gcc-bugs-return-492743-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jul 18 12:21:03 2015
Return-Path: <gcc-bugs-return-492743-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 14400 invoked by alias); 18 Jul 2015 12:21:03 -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 14358 invoked by uid 48); 18 Jul 2015 12:20:59 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated
Date: Sat, 18 Jul 2015 12:21:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.9.1
X-Bugzilla-Keywords: patch, wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ubizjak at gmail dot com
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P4
X-Bugzilla-Assigned-To: mikael at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.4
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61831-4-1Eazql5cwE@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61831-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61831-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-07/txt/msg01633.txt.bz2
Content-length: 443

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

--- Comment #55 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Mikael Morin from comment #54)

> (In reply to Uroš Bizjak from comment #52)
> > There is another PR that seems related, PR 64986.
> 
> Is it?  I see no ICE there.
> Oh, you mean related to this original bug, not the regression of comment#50?

Yes, to the original bug, problems with calling free.
>From gcc-bugs-return-492744-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jul 18 12:21:50 2015
Return-Path: <gcc-bugs-return-492744-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15202 invoked by alias); 18 Jul 2015 12:21:49 -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 15170 invoked by uid 48); 18 Jul 2015 12:21:45 -0000
From: "mikpelinux at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/66917] ARM: NEON: memcpy compiles to vld1 and vst1 with incorrect alignment
Date: Sat, 18 Jul 2015 12:21: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: 4.9.3
X-Bugzilla-Keywords:
X-Bugzilla-Severity: major
X-Bugzilla-Who: mikpelinux at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
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: cc
Message-ID: <bug-66917-4-IqdB2AwhpN@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66917-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66917-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: 2015-07/txt/msg01634.txt.bz2
Content-length: 527

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

Mikael Pettersson <mikpelinux at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikpelinux at gmail dot com

--- Comment #1 from Mikael Pettersson <mikpelinux at gmail dot com> ---
I can reproduce the alignment faults on armv7l-linux-gnueabi with -O3
-mfpu=neon and gcc-4.8.5/4.9.3/5.2/6.0, but not with gcc-4.7.4.

[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated

[dominiq at lps dot ens.fr]

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

--- Comment #56 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
BTW there is a typo in gfortran.dg/derived_constructor_comps_6.f90 which leads
to several

UNRESOLVED: gfortran.dg/derived_constructor_comps_6.f90   -O*  
scan-tree-dump-times original "__builtin_free" 33
UNRESOLVED: gfortran.dg/derived_constructor_comps_6.f90   -O*  
scan-tree-dump-times original "__builtin_malloc" 15

This is fixed by the following  patch

--- ../_clean/gcc/testsuite/gfortran.dg/derived_constructor_comps_6.f90
2015-07-17 12:24:40.000000000 +0200
+++ gcc/testsuite/gfortran.dg/derived_constructor_comps_6.f90   2015-07-18
12:12:26.000000000 +0200
@@ -1,5 +1,5 @@
 ! { dg-do run }
-! { dg-additional-options "-fsanitize=address -fdump-tree-original"
+! { dg-additional-options "-fsanitize=address -fdump-tree-original" }
 !
 ! PR fortran/61831
 ! The deallocation of components of array constructor elements

[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated

[mikael at gcc dot gnu.org]

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

--- Comment #57 from Mikael Morin <mikael at gcc dot gnu.org> ---
Author: mikael
Revision: 225926
Modified property: svn:log

Modified: svn:log at Tue Jul 21 10:07:29 2015
------------------------------------------------------------------------------
--- svn:log (original)
+++ svn:log Tue Jul 21 10:07:29 2015
@@ -24,5 +24,5 @@
        PR fortran/61831
        * gfortran.dg/alloc_comp_auto_array_3.f90: Count the number
        of generated while loops in the tree dump.
-       * gfortran.dg/derived_constructor_components_6.f90: New file.
+       * gfortran.dg/derived_constructor_comps_6.f90: New file.

[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated

[mikael at gcc dot gnu.org]

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

--- Comment #58 from Mikael Morin <mikael at gcc dot gnu.org> ---
Author: mikael
Date: Tue Jul 21 11:33:15 2015
New Revision: 226038

URL: https://gcc.gnu.org/viewcvs?rev=226038&root=gcc&view=rev
Log:
Fix r225926's broken testcase

gcc/testsuite/
        PR fortran/61831
        * gfortran.dg/derived_constructor_comps_6.f90: Fix dg directive.
        Drop address sanitization.


Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/derived_constructor_comps_6.f90

[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated

[mikael at gcc dot gnu.org]

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

--- Comment #59 from Mikael Morin <mikael at gcc dot gnu.org> ---
Author: mikael
Date: Wed Jul 22 15:26:52 2015
New Revision: 226074

URL: https://gcc.gnu.org/viewcvs?rev=226074&root=gcc&view=rev
Log:
Fix r225926's iso_varying_string ICE regression

        PR fortran/61831
        PR fortran/66929
gcc/fortran/
        * trans-array.c (gfc_get_proc_ifc_for_expr): Use esym as procedure
        symbol if available.
gcc/testsuite/
        * gfortran.dg/generic_30.f90: New.


Added:
    trunk/gcc/testsuite/gfortran.dg/generic_30.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-array.c
    trunk/gcc/testsuite/ChangeLog