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

2014-07-22 Thread 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  ---
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
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
>
> --- Comment #33 from Dominique d'Humieres  ---
> 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/ 4.10 Regression] runtime error: pointer being freed was not allocated

2014-07-21 Thread dominiq at lps dot ens.fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831

--- Comment #33 from Dominique d'Humieres  ---
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

2014-07-21 Thread paul.richard.thomas at gmail dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831

--- Comment #32 from paul.richard.thomas at gmail dot com  ---
Dear Dominique,

The problem is due to:
  atmp.10.offset = 0;
  {
integer(kind=8) S.12;

S.12 = 0;
while (1)
  {
if (S.12 > 0) goto L.4;
{
  struct string_t D.2386;
  struct string_t D.2385;

  D.2385 = (*(struct string_t[1] * restrict)
atmp.7.data)[S.12];
  D.2386 = new_prt_spec (&D.2385);
  if (D.2385.chars.data != 0B)
  /* between here  */
{
  __builtin_free ((void *) D.2385.chars.data);
}
  D.2385.chars.data = 0B;
 /* and here */
  (*(struct string_t[1] * restrict)
atmp.10.data)[S.12] = D.2386;
}
S.12 = S.12 + 1;
  }
L.4:;
  }
  process_configuration (&atmp.10);
  if ((struct string_t[1] * restrict) atmp.10.data != 0B)

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

Paul

On 21 July 2014 12:51, dominiq at lps dot ens.fr
 wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
>
> --- Comment #31 from Dominique d'Humieres  ---
> 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.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

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

2014-07-21 Thread dominiq at lps dot ens.fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831

--- Comment #31 from Dominique d'Humieres  ---
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

2014-07-21 Thread dominiq at lps dot ens.fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org,
   ||pault at gcc dot gnu.org

--- Comment #30 from Dominique d'Humieres  ---
> 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

2014-07-20 Thread juergen.reuter at desy dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831

--- Comment #29 from Jürgen Reuter  ---
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 0x7fe788e0:
> 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.

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

2014-07-20 Thread dominiq at lps dot ens.fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831

--- Comment #28 from Dominique d'Humieres  ---
> 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 0x7fe788e0:
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

2014-07-20 Thread juergen.reuter at desy dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831

--- Comment #27 from Jürgen Reuter  ---
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.

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

2014-07-20 Thread juergen.reuter at desy dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831

--- Comment #26 from Jürgen Reuter  ---
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.

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

2014-07-20 Thread juergen.reuter at desy dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831

--- Comment #25 from Jürgen Reuter  ---
Created attachment 33158
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33158&action=edit
Reduced test case, 140 lines

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

2014-07-18 Thread juergen.reuter at desy dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831

--- Comment #24 from Jürgen Reuter  ---
Created attachment 33153
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33153&action=edit
Further cutting down the example

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

2014-07-18 Thread dominiq at lps dot ens.fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831

--- Comment #23 from Dominique d'Humieres  ---
Could you test the following patch?

--- ../_clean/gcc/fortran/trans-expr.c2014-07-07 22:48:04.0 +0200
+++ gcc/fortran/trans-expr.c2014-07-18 21:28:24.0 +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

2014-07-18 Thread juergen.reuter at desy dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831

Jürgen Reuter  changed:

   What|Removed |Added

  Attachment #33138|0   |1
is obsolete||
  Attachment #33140|0   |1
is obsolete||

--- Comment #22 from Jürgen Reuter  ---
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.

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

2014-07-18 Thread dominiq at lps dot ens.fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831

--- Comment #21 from Dominique d'Humieres  ---
> 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

2014-07-18 Thread juergen.reuter at desy dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831

--- Comment #20 from Jürgen Reuter  ---
Ok, Dominique, you mean: compile everything with 4.9.1, then recompile
commands.f90 with 4.9.0 and build the executable with 4.9.0?

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

2014-07-18 Thread dominiq at lps dot ens.fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831

--- Comment #19 from Dominique d'Humieres  ---
> 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

2014-07-18 Thread juergen.reuter at desy dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831

--- Comment #18 from Jürgen Reuter  ---
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.

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

2014-07-18 Thread dominiq at lps dot ens.fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831

--- Comment #17 from Dominique d'Humieres  ---
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

2014-07-18 Thread dominiq at lps dot ens.fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831

--- Comment #16 from Dominique d'Humieres  ---
>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

2014-07-18 Thread dominiq at lps dot ens.fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831

--- Comment #15 from Dominique d'Humieres  ---
> 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

2014-07-18 Thread juergen.reuter at desy dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831

--- Comment #14 from Jürgen Reuter  ---
By the way, the -fcheck=all triggered other problems with definitely valid
code, so I guess there is another compiler bug.

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

2014-07-18 Thread juergen.reuter at desy dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831

--- Comment #13 from Jürgen Reuter  ---
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.

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

2014-07-18 Thread dominiq at lps dot ens.fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831

--- Comment #12 from Dominique d'Humieres  ---
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

2014-07-18 Thread juergen.reuter at desy dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831

--- Comment #11 from Jürgen Reuter  ---
Sorry, wrong makefile logic. I will send a working and more reduced case later
this afternoon.

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

2014-07-18 Thread dominiq at lps dot ens.fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831

--- Comment #10 from Dominique d'Humieres  ---
> 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

2014-07-17 Thread juergen.reuter at desy dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831

--- Comment #9 from Jürgen Reuter  ---
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.

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

2014-07-17 Thread juergen.reuter at desy dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831

--- Comment #8 from Jürgen Reuter  ---
Created attachment 33138
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33138&action=edit
Test case

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

2014-07-17 Thread juergen.reuter at desy dot de 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831

--- Comment #7 from Jürgen Reuter  ---
(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).

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

2014-07-17 Thread dominiq at lps dot ens.fr 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831

Dominique d'Humieres  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  ---
Marked as 4.9/4.10 regression.