[Bug fortran/33282] New: ICE in find_array_section when using vector subscripts
The following Fortran 90 program crashes gfortran-4.2.1:
program test
real(kind=8),parameter :: beta0(3) = (/ 1.0, 1.0, 1.0 /)
integer :: i(3)
real(kind=8) :: beta(3), beta_coef
i = (/ 1, 2, 3 /)
beta_coef = 1.0
beta = beta0(i) * beta_coef
end program test
(Workaround: "beta = beta0(i) ; beta = beta * beta_coef")
Compiler output:
$ gfortran -g -O2 -march=pentium4 -mfpmath=sse -ffree-form
-ffree-line-length-none -Wall -W -Wno-unused -Wimplicit-interface -Wtabs
-fimplicit-none -ffpe-trap=invalid,zero,overflow -o arraybug arraybug.f90
arraybug.f90:0: internal compiler error: in find_array_section, at
fortran/expr.c:1079
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
$ gfortran -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.2.1/configure --prefix=/home/r6144/apps/gcc-4.2.1
--enable-languages=c,fortran --with-mpfr=/home/r6144/apps/mpfr-2.3.0
--disable-bootstrap
Thread model: posix
gcc version 4.2.1
$ gfortran --version
GNU Fortran (GCC) 4.2.1
Copyright (C) 2007 Free Software Foundation, Inc.
GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING
--
Summary: ICE in find_array_section when using vector subscripts
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rainy6144 at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33282
[Bug fortran/33282] ICE in find_array_section when using vector subscripts
--- Comment #2 from rainy6144 at gmail dot com 2007-09-02 18:38 --- Thank you. The bug appears to have been fixed in the latest 4.3.0 snapshot (r128023). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33282
[Bug fortran/33288] New: ICE (segfault) in mpfr_cmp2 when evaluating array initializers containing addition
gfortran 4.1.2/4.2.0/4.3.0 segfaults when compiling the following program:
program initbug
integer,parameter :: n0 = 3, n = 5
real(kind=8),parameter :: x0(n0) = (/ 0.0d0, 0.0d0, 0.0d0 /)
real(kind=8),parameter :: x(n) = (/ -x0, x0(n0-1:1:-1) /) + 1.0d0
end program initbug
Valgrind output:
$ valgrind
/home/r6144/apps/gcc-4.3.0-070903-bin/bin/../libexec/gcc/i386-pc-linux-gnu/4.3.0/f951
initbug.f90 -quiet -dumpbase initbug.f90 -march=pentium4 -mfpmath=sse
-auxbase-strip initbug.o -g -O2 -Wall -W -Wno-unused -Wimplicit-interface
-Wtabs -version -ffree-form -ffree-line-length-none -fimplicit-none
-ffpe-trap=invalid,zero,overflow -fintrinsic-modules-path
/home/r6144/apps/gcc-4.3.0-070903-bin/bin/../lib/gcc/i386-pc-linux-gnu/4.3.0/finclude
-o /tmp/ccZfWmpd.s
==5331== Memcheck, a memory error detector.
==5331== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==5331== Using LibVEX rev 1658, a library for dynamic binary translation.
==5331== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==5331== Using valgrind-3.2.1, a dynamic binary instrumentation framework.
==5331== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==5331== For more details, rerun with: -v
==5331==
GNU F95 (GCC) version 4.3.0 20070902 (experimental) [trunk revision 128023]
(i386-pc-linux-gnu)
compiled by GNU C version 4.3.0 20070902 (experimental) [trunk revision
128023], GMP version 4.2.1, MPFR version 2.2.1.
GGC heuristics: --param ggc-min-expand=63 --param ggc-min-heapsize=63256
==5331== Invalid read of size 4
==5331==at 0x84CCEDB: mpfr_cmp2 (in
/home/r6144/apps/gcc-4.3.0-070903-bin/libexec/gcc/i386-pc-linux-gnu/4.3.0/f951)
==5331==by 0x84C6D35: mpfr_sub1 (in
/home/r6144/apps/gcc-4.3.0-070903-bin/libexec/gcc/i386-pc-linux-gnu/4.3.0/f951)
==5331==by 0x84B9AB2: mpfr_add (in
/home/r6144/apps/gcc-4.3.0-070903-bin/libexec/gcc/i386-pc-linux-gnu/4.3.0/f951)
==5331==by 0x804CB56: gfc_arith_plus (arith.c:657)
==5331== Address 0x812488 is not stack'd, malloc'd or (recently) free'd
initbug.f90:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
--
Summary: ICE (segfault) in mpfr_cmp2 when evaluating array
initializers containing addition
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rainy6144 at gmail dot com
GCC build triplet: i386-pc-linux-gnu
GCC host triplet: i386-pc-linux-gnu
GCC target triplet: i386-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33288
[Bug rtl-optimization/44481] New: __builtin_parity() causes ICE in trunc_int_for_mode()
When compiling the following program with -O2, gcc gives an ICE "internal
compiler error: in trunc_int_for_mode, at explow.c:56".
Versions affected:
gcc (GCC) 4.4.3 20100127 (Red Hat 4.4.3-4)
gcc (GCC) 4.5.1 20100521 (prerelease)
static inline unsigned parity(unsigned x)
{
return (unsigned) __builtin_parity(x);
}
unsigned f(unsigned rpoly)
{
return parity(rpoly & 1) ^ parity(rpoly & 6);
}
--
Summary: __builtin_parity() causes ICE in trunc_int_for_mode()
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rainy6144 at gmail dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44481
[Bug middle-end/36013] New: Wrong code involving restricted pointers to non-restricted pointers
The program below aborts at runtime when compiled by gcc 4.3.0 with option "-O2
-std=c99" (it runs correctly without optimization or when compiled with "icc
-std=c99 -restrict"). I believe it should have defined behavior according to
the standard (see e.g. PR14192), for p[0] and q[0] are not restricted pointers,
and p[0][0] is based on p[0] but not p. Intuitively, p and q should behave
like two different arrays of pointers, and we may well want to store aliasing
pointers into them.
This is apparently due to the simplistic find_base_decl() in 4.3.0, which is
quite different the standard's definition of "based on". If I understand
correctly, for two pointers p and q, only when p is provably based on some
restricted pointer p0 (along all control paths), and q is provably not based on
it, can we be sure that a modification to *q can never change *p.
>From a casual glance of the 4.3.0 source, it seems that "restrict" is not well
supported by the tree passes, but the alias sets in the generated RTL make some
use of it. Proper support, either at RTL or tree level, may mean a lot of
work, but in the meantime we had better agree on the meaning of the standard
and avoid generating wrong code :)
==
#include
/* fail by gcc-4.3.0 */
void f(int **restrict p, int **restrict q)
{
p[0][0] = 1;
q[0][0] = 2;
if (p[0][0] != 2) abort();
}
int main(void)
{
int a;
int *p1 = &a, *p2 = &a;
f(&p1, &p2);
return 0;
}
--
Summary: Wrong code involving restricted pointers to non-
restricted pointers
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rainy6144 at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36013
[Bug c/34389] -Wconversion produces wrong warning
--- Comment #9 from rainy6144 at gmail dot com 2008-04-23 07:20 ---
Does the patch also fix the warning for conditional expressions? For example:
short f(int cond, short x, short y)
{
return cond ? x : y;
}
--
rainy6144 at gmail dot com changed:
What|Removed |Added
CC||rainy6144 at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34389
