--- Comment #9 from dnovillo at gcc dot gnu dot org 2005-11-15 21:50
---
(In reply to comment #8)
> Will take a look shortly.
>
I stand by my analysis in #5. The Fortran FE is lying to the middle end.
There is no field 'ktbuf' in this structure.
--
dnovillo at gcc dot gnu dot org
--- Comment #8 from dnovillo at gcc dot gnu dot org 2005-11-12 01:04
---
Will take a look shortly.
--
dnovillo at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from janis at gcc dot gnu dot org 2005-11-11 22:57 ---
The testcase from comment #3 starts failing with this patch:
r97988 | dnovillo | 2005-04-11 22:06:46 + (Mon, 11 Apr 2005) | 17 lines
PR tree-optimization/20933
* tree-ssa-alias.c (compute_flow_ins
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P2 |P5
Target Milestone|4.2.0 |4.1.0
http://gcc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-08
19:41 ---
Fortran bug, moving target milestone to 4.2.0.
--
What|Removed |Added
Target Milestone|4.1
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-09-08
19:30 ---
Definitely an FE oddity. The operand scanner is told to get the operands of a
COMPONENT_REF that's accessing a non-existant field:
(gdb) ptu stmt
substr.ktbuf = D.485;
(gdb) ptu expr
substr.ktbuf;
(gdb)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-02
17:11 ---
We do get a warning:
In file t.2.f:4
COMMON /SUBSTR/ NPHASE,NSUB,IDUM1,KURPA,KTBUF
1
Warning: Named COMMON block 'substr' at (1) shall be of the same size
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-02
17:10 ---
Another reduced testcase:
COMMON /SUBSTR/ NPHASE,NSUB
END
SUBROUTINE ZIPP
COMMON /SUBSTR/ NPHASE,NSUB,IDUM1,KURPA,KTBUF
NSUB = 1
KTBUF = 1
END
--
http://gcc.gnu
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-02
17:08 ---
I am thinking this is a fortran front-end bug:
reduced testcase:
COMMON /SUBSTR/ NPHASE,NSUB
END
SUBROUTINE ZIPP
COMMON /SUBSTR/ NPHASE,NSUB,IDUM1,KURPA,KTBUF
IF (NSUB.LT.0) THE
