This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH, Fortran] DEC Compatibility: Logical operations on integers become bitwise ops with -fdec


On Wed, Oct 26, 2016 at 10:50 AM, Andreas Schwab <schwab@suse.de> wrote:
> On Okt 26 2016, Fritz Reese <fritzoreese@gmail.com> wrote:
>
>> If so, I am not sure how to narrow down the issue without more debug
>> info like a traceback or memory dump at the point of error.
>
> Tell me more, I don't know anything about fortran.
...

Andreas,

One way would be to apply the below, rebuild, then re-run the test
case. The test should then cause an internal compiler error (ICE)
instead of the error you are seeing. The ICE will dump a traceback
which will at least let us see the call chain at that point and tell
us how it got to the error.

>>>
diff --git a/gcc/fortran/intrinsic.c b/gcc/fortran/intrinsic.c
index fdc11d8..171e0ab 100644
--- a/gcc/fortran/intrinsic.c
+++ b/gcc/fortran/intrinsic.c
@@ -5015,7 +5015,7 @@ gfc_convert_type_warn (gfc_expr *expr, gfc_typespec *ts, i
   return true;

 bad:
-  if (eflag == 1)
+  if (false)
     {
       gfc_error ("Can't convert %s to %s at %L",
                 gfc_typename (&from_ts), gfc_typename (ts), &expr->where);
<<<

You can then re-run the test manually with `gfortran -fdec
dec_bitwise_ops_1.f90` and post the traceback here.

Alternatively, if your gcc is built with debugging symbols (-g), you
could also debug the compilation without the hack using gdb, with
something like the following:

gdb --args `gfortran --print-prog-name=f951` -fdec dec_bitwise_ops_1.f90
(gdb) break gfc_convert_type_warn
Breakpoint 1 at 0x6306d0: file <...>/intrinsic.c, line 4853.
(gdb) run
Starting program: <...>/f951 -fdec dec_bitwise_ops_1.f90

Breakpoint 1, gfc_convert_type_warn (...) at <...>/intrinsic.c:4853
(gdb) where
#0  gfc_convert_type_warn (...) at <...>/intrinsic.c:4853
#1  ...
#2  ...
(gdb) print expr->value.op...

The output of 'where' at that point is a useful stack trace, plus you
can print the arguments and other stuff to give more info.

---
Fritz Reese


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]