#613 closed defect (fixed)
Fortran runtime error in cc->bb with gfortran 4.7.1
Reported by: | fbach | Owned by: | kilian |
---|---|---|---|
Priority: | P3 | Milestone: | v2.2.0 |
Component: | core | Version: | 2.1.1 |
Severity: | normal | Keywords: | |
Cc: |
Description
The attached file gives a Fortran runtime error *only* in process cc->bb, model=SM_Higgs and proton pdfs turned on. Also depends on the machine: fails on DESY machines (gfortran 4.7.1), but runs e.g. with 4.8.1 (no other tested so far).
Attachments (2)
Change History (10)
Changed 11 years ago by
comment:1 Changed 11 years ago by
comment:2 Changed 11 years ago by
Works fine for me, with 4.7.1 on DESY computers, both under 64 bit and under 32 bit. Maybe some different installed versions getting into conflict?
comment:3 Changed 11 years ago by
Hm, on my DESY machine I just use the ELF64 tools to build Whizard, nothing selfmade... and Marco reproduced it on his machine with 4.7.1
comment:4 Changed 11 years ago by
Please provide the exact error message and circuminstances under which this happens. My believe is that it is a conflict between two different installations (which also easily makes tests fail).
comment:5 Changed 11 years ago by
I freshly built the Whizard trunk on DESY with ELF64 tools. All tests passed. The full run output is attached in foo.log.
Changed 11 years ago by
comment:6 Changed 11 years ago by
Thanks. Please also post proc_i1.phs. What trunk revision? Did you edit _any_ file from the trunk?
comment:7 Changed 11 years ago by
You "Hirsch"!!! In the file foo.sin, you posted the wrong process,
c, C => u, U
instead of c, C => b, B
. Now I can reproduce the runtime error.
4.9.0 is fine, 4.7.1 32bit gives the runtime error.
comment:8 Changed 11 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
gfortran 4.7 has notoriously problems with autoalloc/autodealloc. In that case an allocatable variable to be set in a subroutine as intent(out) should be never allocated, but apparently ... safeguarded in r5440 (analogous to e.g. the allocate statement in particle_data_copy). Closing.
bb->cc also fails, but bc->bc runs through.