odd print behavior.

[Jeff Sadowski]

in u_exact t is a real(type=8) but I was passing it 0 not 0d0 when I
made that fix wala everything works as expected.

On Thu, Dec 14, 2017 at 8:29 AM, Jeff Sadowski <jeff.sadowski@gmail.com> wrote:
> It was all because of passing an int to a real
>
> On Thu, Dec 14, 2017 at 7:13 AM, Holcomb, Katherine A. (kah3f)
> <kah3f@virginia.edu> wrote:
>> You don't seem to have interfaces for your subprograms.  What you describe is an absolutely classic symptom of a "Heisenbug," i.e. a bug that goes away when you try to observe it, whether by adding a print statement or compiling with -g.  It's pretty much always due to memory stomping.  In Fortran there are not as many ways to accomplish this as in some other languages but besides array bounds errors (which are easily checked by the options to which you were directed) the other main source of such bugs is a mismatch between the number and type and in your case it looks like maybe the rank of the parameters to a subprogram compared to the dummy arguments.  Interfaces/prototypes enable the compiler to check this for you.
>>
>> -----Original Message-----
>> From: fortran-owner@gcc.gnu.org [mailto:fortran-owner@gcc.gnu.org] On Behalf Of Jeff Sadowski
>> Sent: Wednesday, December 13, 2017 6:30 PM
>> To: Thomas Koenig <tkoenig@netcologne.de>
>> Cc: fortran@gcc.gnu.org
>> Subject: Re: odd print behavior.
>>
>> I did have a few errors but I resolved them and still have the same behavior. I will ask on the comp.lang.fortran news group when I get home but this is weird. I tried it with the " -g -Wall -Wextra -O -fcheck=all -finit-real=nan -finit-integer=-536870911" flags then ran it and got rid of everything it was complaining about then ran it with the "-fsanitize=address -g" and I don't see anything showing where the issue is I still have the behavior as described.
>> I compiled it with -g and ran it in valgrind and got as follows with the print statement.
>>
>>> valgrind ./project
>> ==29657== Memcheck, a memory error detector ==29657== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
>> ==29657== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info ==29657== Command: ./project ==29657==  What is going on  What is going on  What is going on  What is going on  What is going on ==29657== ==29657== HEAP SUMMARY:
>> ==29657==     in use at exit: 0 bytes in 0 blocks
>> ==29657==   total heap usage: 173 allocs, 173 frees, 7,860,875 bytes allocated
>> ==29657==
>> ==29657== All heap blocks were freed -- no leaks are possible ==29657== ==29657== For counts of detected and suppressed errors, rerun with: -v ==29657== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
>>
>> and
>>
>> ==31070== Memcheck, a memory error detector ==31070== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
>> ==31070== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info ==31070== Command: ./project ==31070== ==31070== ==31070== HEAP SUMMARY:
>> ==31070==     in use at exit: 0 bytes in 0 blocks
>> ==31070==   total heap usage: 173 allocs, 173 frees, 7,860,875 bytes allocated
>> ==31070==
>> ==31070== All heap blocks were freed -- no leaks are possible ==31070== ==31070== For counts of detected and suppressed errors, rerun with: -v ==31070== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
>>
>> without print statement and it differs on the writing of my file.
>>
>> very odd behavior.
>>
>> On Wed, Dec 13, 2017 at 4:00 PM, Jeff Sadowski <jeff.sadowski@gmail.com> wrote:
>>> ok I thought i might have stumbled on a compiler but. Thank you for
>>> the point in the right direction.
>>>
>>>
>>> On Wed, Dec 13, 2017 at 3:51 PM, Thomas Koenig <tkoenig@netcologne.de> wrote:
>>>> Hi Jeff,
>>>>
>>>> this list is for development of the gfortran compiler, general
>>>> Fortran questions are not really appropriate here.  You might be
>>>> better served by directing your question to comp.lang.fortran, for
>>>> example.
>>>>
>>>> Having said that,
>>>>
>>>>> And this works as long as I leave a print statement before it.
>>>>> How is that working?
>>>>
>>>>
>>>> this is a classic symptom of a subscript error. Compile your program
>>>> with -g -Wall -Wextra -O -fcheck=all -finit-real=nan
>>>> -finit-integer=-536870911 (or whatever constant takes your fancy for
>>>> integer).
>>>>
>>>> If that doesn't show any problems, recompile with -fsanitize=address -g.
>>>>
>>>> If you still don't see anything, recompile without the sanitize
>>>> option, then run under valgrind.
>>>>
>>>> HTH
>>>>
>>>>         Thoas