This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/69055] Internal compiler error -fsanitize=float-cast-overflow
- From: "sgk at troutmask dot apl.washington.edu" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Sat, 26 Dec 2015 17:43:56 +0000
- Subject: [Bug fortran/69055] Internal compiler error -fsanitize=float-cast-overflow
- Auto-submitted: auto-generated
- References: <bug-69055-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69055
--- Comment #2 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Sat, Dec 26, 2015 at 05:15:27PM +0000, kargl at gcc dot gnu.org wrote:
> >
> > N=daten(j)%daten
> >
>
> The code is non-conforming Fortran. daten(j)%daten is used uninitialized.
> gfortan can do anything it wants with the code, including throwing an
> error.
>
After making the code at least conform to the Fortran
standard and removing the overuse of "daten", the error
still occurs.
subroutine tstd
implicit none
integer n
type a
real(8) b
end type a
type(a) :: daten(10)
integer :: j = 1
daten(:)%b = 42
n = daten(j)%b
end subroutine tstd
The -fdump-tree-original output is
tstd ()
{
struct a daten[10];
static integer(kind=4) j = 1;
integer(kind=4) n;
{
integer(kind=4) S.0;
S.0 = 1;
while (1)
{
if (S.0 > 10) goto L.1;
daten[S.0 + -1].b = 4.2e+1;
S.0 = S.0 + 1;
}
L.1:;
}
n = (integer(kind=4)) daten[NON_LVALUE_EXPR <j> + -1].b;
}
which looks like what I expect. It seems that -fsanitize=float-cast-overflow
option has a false positive.