[Bug libfortran/26564] ../.././libgfortran/mk-kinds-h.sh: Unknown type
--- Comment #11 from diskman at kc dot rr dot com 2006-03-06 08:03 --- The AlphaPC 164SX is basically the same as the AlphaPC 164LX just minus the 96k L1 cache but with additional MVI instructions. [EMAIL PROTECTED] gcc-4.1.0]# gdb -args /usr2/www/linux-related/programming/compilers/gcc-4.1.0/gcc-4.1.0/host-alphapca56-alpha-linux-gnu/gcc/gfortran -B/usr2/www/linux-related/programming/compilers/gcc-4.1.0/gcc-4.1.0/host-alphapca56-alpha-linux-gnu/gcc/ -B/usr/alphapca56-alpha-linux-gnu/bin/ -B/usr/alphapca56-alpha-linux-gnu/lib/ -isystem /usr/alphapca56-alpha-linux-gnu/include -isystem a.f90 GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "alphapca56-alpha-linux-gnu"... (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /usr2/www/pub/alpha-RH7/programming/compilers/gcc-4.1.0/gcc-4.1.0/host-alphapca56-alpha-linux-gnu/gcc/gfortran -B/usr2/www/linux-related/programming/compilers/gcc-4.1.0/gcc-4.1.0/host-alphapca56-alpha-linux-gnu/gcc/ -B/usr/alphapca56-alpha-linux-gnu/bin/ -B/usr/alphapca56-alpha-linux-gnu/lib/ -isystem /usr/alphapca56-alpha-linux-gnu/include -isystem a.f90 Detaching after fork from child process 24853. /usr/bin/ld: cannot find -lgfortranbegin collect2: ld returned 1 exit status Program exited with code 01. [EMAIL PROTECTED] gcc-4.1.0]# find . -name "*.so.*" ./host-alphapca56-alpha-linux-gnu/gcc/libgcc_s.so.1.backup ./host-alphapca56-alpha-linux-gnu/gcc/libgcc_s.so.1 ./alphapca56-alpha-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6.0.7 ./alphapca56-alpha-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6 ./alphapca56-alpha-linux-gnu/libmudflap/.libs/libmudflap.so.0.0.0 ./alphapca56-alpha-linux-gnu/libmudflap/.libs/libmudflap.so.0 ./alphapca56-alpha-linux-gnu/libmudflap/.libs/libmudflapth.so.0.0.0 ./alphapca56-alpha-linux-gnu/libmudflap/.libs/libmudflapth.so.0 ./alphapca56-alpha-linux-gnu/libssp/.libs/libssp.so.0.0.0 ./alphapca56-alpha-linux-gnu/libssp/.libs/libssp.so.0 -- diskman at kc dot rr dot com changed: What|Removed |Added CC||diskman at kc dot rr dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26564
[Bug c++/26577] New: [4.0/4.1/4.2 regression] ICE in cp_expr_size with volatile
As reported here: http://gcc.gnu.org/ml/gcc-bugs/2006-03/msg00589.html Confirmed. Fails since GCC 4.0.0. However, this has nothing to do with templates or inline asm as the reduced testcase shows: == struct A { A(const A&); A& operator=(const A&); static void bar(); void foo() volatile {} void baz() volatile; }; void A::baz() volatile { foo(); bar(); } == -- Summary: [4.0/4.1/4.2 regression] ICE in cp_expr_size with volatile Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, monitored Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: reichelt at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26577
[Bug c++/26577] [4.0/4.1/4.2 regression] ICE in cp_expr_size with volatile
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-06 08:06:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26577
[Bug c++/26577] [4.0/4.1/4.2 regression] ICE in cp_expr_size with volatile
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26577
[Bug libgcj/26574] libjava configration error
--- Comment #3 from shanwill44 at yahoo dot com 2006-03-06 08:36 --- (In reply to comment #1) Thank you for your support. After setting CONFIG_SHELL to /bin/ksh, the compilation was successful. I am sorry that I did not noticed the existence of the Solaris specific documentation, because the compilation had been almost straight-forward. -- shanwill44 at yahoo dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26574
[Bug bootstrap/26578] New: nothing appenning at the end of my "make bootstrap"
the "make bootstrap" finish with a Error but no precise thing to do or to operate on it's look make[2]: *** No rule to make target `all'. Stop. make[1]: *** [all-subdir] Error 2 make: *** [all-libiberty] Error 2 don't know what to do ... I tryed make install BUT it failed on : gcc: makeUser.c: No such file or directory gcc: no input files make[1]: *** [makeUser.o] Error 1 make: *** [install-gcc] Error 2 -- Summary: nothing appenning at the end of my "make bootstrap" Product: gcc Version: 2.95.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mpoirier at laas dot fr GCC host triplet: powerpc-*-darwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26578
[Bug middle-end/26561] [4.2 Regression] ACATS failures c34004a, c46033a and cxg2024 at -O0
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2006-03-06 09:14 --- In Roger's court now. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC|roger at eyesopen dot com | AssignedTo|ebotcazou at gcc dot gnu dot|sayle at gcc dot gnu dot org |org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26561
[Bug bootstrap/26578] nothing appenning at the end of my "make bootstrap"
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-06 10:26 --- First, 2.95.2 is waay outdated, second, you don't provide any information on how you configured gcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26578
[Bug c++/26577] [4.0/4.1/4.2 regression] ICE in cp_expr_size with volatile
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-06 10:39 --- gcc_assert (!TYPE_HAS_COMPLEX_INIT_REF (type) || !TYPE_HAS_COMPLEX_ASSIGN_REF (type) /* But storing a CONSTRUCTOR isn't a copy. */ || TREE_CODE (exp) == CONSTRUCTOR /* And, the gimplifier will sometimes make a copy of an aggregate. In particular, for a case like: struct S { S(); }; struct X { int a; S s; }; X x = { 0 }; the gimplifier will create a temporary with static storage duration, perform static initialization of the temporary, and then copy the result. Since the "s" subobject is never constructed, this is a valid transformation. */ || CP_AGGREGATE_TYPE_P (type)); (gdb) call debug_tree(0x40247958) constant invariant 8> unit size constant invariant 1> align 8 symtab 0 alias set -1 fields unit size align 8 symtab 0 alias set -1 fields needs-constructor X(constX&) this=(X&) n_parents=0 use_template=0 interface-unknown pointer_to_this reference_to_this chain > nonlocal decl_4 VOID file /tmp/t.C line 2 align 1 context > needs-constructor X(constX&) this=(X&) n_parents=0 use_template=0 interface-unknown pointer_to_this > (gdb) call debug_tree(exp) readonly unsigned SI size unit size align 32 symtab 0 alias set -1> readonly used unsigned SI file /tmp/t.C line 10 size unit size align 32 context initial (mem/f/c/i:SI (reg/f:SI 53 virtual-incoming-args) [0 this+0 S4 A32]) arg-type incoming-rtl (mem/f/c/i:SI (reg/f:SI 53 virtual-incoming-args) [0 this+0 S4 A32])>> The last conditional should probably apply here: CP_AGGREGATE_TYPE_P (type) but it doesn't due to CLASSTYPE_NON_AGGREGATE (TYPE) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26577
[Bug middle-end/26565] Unaligned accesses with __attribute__(packed) and memcpy
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-03-06 10:58 --- We indeed lose alignment information of outdata->tv. We start expanding memcpy (&outdataD.1529->tvD.1528, tpD.1530, 4) [tail call] with (gdb) print dest_align $1 = 32 so, builtins.c:get_pointer_alignment returns wrong (non conservative) results. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-06 10:58:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26565
[Bug bootstrap/26578] nothing appenning at the end of my "make bootstrap"
--- Comment #2 from mpoirier at laas dot fr 2006-03-06 11:09 --- Of course I know that gcc 2.95 is out but I need it for some prog that only compil on gcc 2.95 I used the folloowing command to configure : ../gcc2/configure --program-suffix=-2.95 --enable-shared --enable-threads --host=powerpc-*-darwin --enable-haifa --with-gnu-as --with-gnu-ld --with-stabs --with-cpu=powerpc Created "Makefile" in /Users/Shamok/Travail/gcc2bin using "mh-frag" and "mt-frag" ./config.status is unchanged Configuring libiberty... loading cache ../config.cache checking host system type... powerpc-*-darwin checking build system type... powerpc-*-darwin checking for ar... (cached) ar checking for ranlib... (cached) ranlib checking for gcc... (cached) gcc checking whether we are using GNU C... (cached) yes checking whether gcc accepts -g... (cached) yes checking for POSIXized ISC... no checking for a BSD compatible install... (cached) /usr/bin/install -c Appending ../../gcc2/libiberty/config/../../config/mh-ppcpic to xhost-mkfrag xhost-mkfrag is unchanged checking how to run the C preprocessor... (cached) gcc -E checking for sys/file.h... (cached) yes checking for sys/param.h... (cached) yes checking for stdlib.h... (cached) yes checking for string.h... (cached) yes checking for unistd.h... (cached) yes checking for strings.h... (cached) yes checking for sys/time.h... (cached) yes checking for sys/resource.h... (cached) yes checking for sys/wait.h that is POSIX.1 compatible... (cached) yes checking whether the C compiler (gcc -g -O2 ) works... yes checking whether the C compiler (gcc -g -O2 ) is a cross-compiler... no checking for asprintf... (cached) yes checking for atexit... (cached) yes checking for basename... (cached) yes checking for bcmp... (cached) yes checking for bcopy... (cached) yes checking for bzero... (cached) yes checking for calloc... (cached) yes checking for clock... (cached) yes checking for getcwd... (cached) yes checking for getpagesize... (cached) yes checking for index... (cached) yes checking for insque... (cached) yes checking for memchr... (cached) yes checking for memcmp... (cached) yes checking for memcpy... (cached) yes checking for memmove... (cached) yes checking for memset... (cached) yes checking for mkstemps... (cached) yes checking for putenv... (cached) yes checking for random... (cached) yes checking for rename... (cached) yes checking for rindex... (cached) yes checking for setenv... (cached) yes checking for sigsetmask... (cached) yes checking for strcasecmp... (cached) yes checking for strchr... (cached) yes checking for strdup... (cached) yes checking for strncasecmp... (cached) yes checking for strrchr... (cached) yes checking for strstr... (cached) yes checking for strtod... (cached) yes checking for strtol... (cached) yes checking for strtoul... (cached) yes checking for tmpnam... (cached) yes checking for vasprintf... (cached) yes checking for vfprintf... (cached) yes checking for vprintf... (cached) yes checking for vsprintf... (cached) yes checking for waitpid... (cached) yes checking for working alloca.h... (cached) yes checking for alloca... (cached) yes checking for ANSI C header files... (cached) yes checking for pid_t... (cached) yes checking for vfork.h... (cached) no checking for working vfork... (cached) yes checking for sys_errlist... (cached) yes checking for sys_nerr... (cached) yes checking for sys_siglist... (cached) yes checking for getrusage... (cached) yes checking for on_exit... (cached) no checking for psignal... (cached) yes checking for strerror... (cached) yes checking for strsignal... (cached) yes checking for sysconf... (cached) yes checking for times... (cached) yes checking for sbrk... (cached) yes checking for gettimeofday... (cached) yes creating ./config.status creating Makefile creating testsuite/Makefile creating config.h config.h is unchanged Configuring texinfo... loading cache ../config.cache checking for a BSD compatible install... (cached) /usr/bin/install -c checking whether build environment is sane... yes checking whether make sets ${MAKE}... (cached) yes checking for working aclocal... found checking for working autoconf... found checking for working automake... found checking for working autoheader... found checking for working makeinfo... found checking for gcc... (cached) gcc checking whether the C compiler (gcc -g -O2 ) works... yes checking whether the C compiler (gcc -g -O2 ) is a cross-compiler... no checking whether we are using GNU C... (cached) yes checking whether gcc accepts -g... (cached) yes checking how to run the C preprocessor... (cached) gcc -E checking whether gcc needs -traditional... (cached) no checking for a BSD compatible install... /usr/bin/install -c checking for ranlib... (cached) ranlib checking for texconfig... (cached) false checking for POSIXized ISC... no checking for minix/config.h... (cached) no checking whether to enable maintainer-specific portions of Makefiles... no checking for Cygwin32 env
[Bug middle-end/26565] Unaligned accesses with __attribute__(packed) and memcpy
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-03-06 11:58 --- I have a patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-03-06 10:58:47 |2006-03-06 11:58:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26565
[Bug fortran/26554] [gfortran] incorrect behaviour when reading a logical variable from a string
--- Comment #8 from martin at mpa-garching dot mpg dot de 2006-03-06 12:10 --- Mainline works correctly again, thanks! Do you plan to commit to the 4.1-branch too? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26554
[Bug middle-end/26565] [4.1/4.2 Regression] Unaligned accesses with __attribute__(packed) and memcpy
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-03-06 12:17 --- Works with 3.3.3, 3.4.2, fails with 4.1.0 and 4.2.0 (didn't check 4.0.x, but I guess it's another tree-ssa fallout) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.1.0 4.2.0 Known to work||3.3.3 3.4.2 Summary|Unaligned accesses with |[4.1/4.2 Regression] |__attribute__(packed) and |Unaligned accesses with |memcpy |__attribute__(packed) and ||memcpy http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26565
[Bug middle-end/26565] [4.1/4.2 Regression] Unaligned accesses with __attribute__(packed) and memcpy
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-03-06 12:23 --- It also affects ia64 and s390(x) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|alphaev68-linux-gnu | GCC host triplet|alphaev68-linux-gnu | GCC target triplet|alphaev68-linux-gnu |alphaev68-linux-gnu, ia64-*- ||*, s390-*-*, s390x-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26565
[Bug bootstrap/26578] nothing appenning at the end of my "make bootstrap"
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-06 12:31 --- 2.9.5.2 did not have support for Darwin as either the host or the target. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26578
[Bug c++/26577] [4.0/4.1/4.2 regression] ICE in cp_expr_size with volatile and call to static
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-06 12:42 --- Reduced testcase which shows the real issue: struct A { A(const A&); A& operator=(const A&); static void bar(); void baz() volatile; }; void A::baz() volatile { bar(); } -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2 regression] ICE|[4.0/4.1/4.2 regression] ICE |in cp_expr_size with|in cp_expr_size with |volatile|volatile and call to static http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26577
[Bug c++/26577] [4.0/4.1/4.2 regression] ICE in cp_expr_size with volatile and call to static
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-06 12:45 --- Related to PR 23167. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||23167 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26577
[Bug bootstrap/26578] nothing appenning at the end of my "make bootstrap"
--- Comment #4 from mpoirier at laas dot fr 2006-03-06 12:45 --- and 2.95.3 ?? which one was on panther or Xcode 1 and 1.5 else thanx for the info -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26578
[Bug c++/26577] [4.0/4.1/4.2 regression] ICE in cp_expr_size with volatile and call to static
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-06 12:47 --- (In reply to comment #3) > Related to PR 23167. One more comment about this, the fix for that PR moved the ICE from create_tmp_var to cp_expr_size. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26577
[Bug bootstrap/26578] nothing appenning at the end of my "make bootstrap"
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-06 12:48 --- (In reply to comment #4) > and 2.95.3 ?? All FSF 2.95.x did not have support for Darwin. The 2.95.3 you were referring to came modified to you from Apple. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26578
[Bug middle-end/26565] [4.1/4.2 Regression] Unaligned accesses with __attribute__(packed) and memcpy
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-03-06 12:49 --- A workaround is to do memcpy ((char*)outdata + 1, ...); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26565
[Bug fortran/16136] Conflicting attributes ALLOCATABLE, DUMMY (F2003)
--- Comment #5 from eedelman at gcc dot gnu dot org 2006-03-06 12:52 --- Works on mainline (will become 4.2). Will (probably) not be backported to 4.1. -- eedelman at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16136
[Bug c++/26573] [4.0/4.1/4.2 regression] Duplicate message for static member in local class
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-06 13:02 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||3.2.3 3.3.3 3.4.0 4.0.0 ||4.1.0 4.2.0 3.2.2 Known to work||3.0.4 Last reconfirmed|-00-00 00:00:00 |2006-03-06 13:02:59 date|| Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26573
[Bug c++/26571] [4.0/4.1/4.2 regression] Bad diagnostic using type modifier with struct
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-06 13:05 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||3.4.0 4.0.0 4.1.0 4.2.0 Known to work||3.3.3 Last reconfirmed|-00-00 00:00:00 |2006-03-06 13:05:49 date|| Target Milestone|--- |4.0.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26571
[Bug c++/26572] Invalid local class definition not diagnosed
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-06 13:06 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||2.95.3 3.2.3 3.3.2 3.3.3 ||3.4.0 3.0.4 4.0.0 Last reconfirmed|-00-00 00:00:00 |2006-03-06 13:06:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26572
[Bug target/26532] libmudflap failures on ia64
--- Comment #8 from pcarlini at suse dot de 2006-03-06 13:17 --- Working on it. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|WAITING |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26532
[Bug middle-end/26565] [4.0/4.1/4.2 Regression] Unaligned accesses with __attribute__(packed) and memcpy
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org GCC target triplet|alphaev68-linux-gnu, ia64-*-|STRICT_ALIGNMENT |*, s390-*-*, s390x-*-* | Summary|[4.1/4.2 Regression]|[4.0/4.1/4.2 Regression] |Unaligned accesses with |Unaligned accesses with |__attribute__(packed) and |__attribute__(packed) and |memcpy |memcpy Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26565
[Bug fortran/26554] [gfortran] incorrect behaviour when reading a logical variable from a string
--- Comment #9 from martin at mpa-garching dot mpg dot de 2006-03-06 13:22 --- I just noticed another (probably related) problem: The following Fortran code is derived from some autoconf test: PROGRAM TESTRECL IMPLICIT NONE OPEN(UNIT = 10,FILE = 'conftest.rcl1', FORM = 'UNFORMATTED', : ACCESS = 'DIRECT', RECL = 1, ERR = 101) WRITE(UNIT=10,REC=1,ERR=101) 1d0 PRINT *,"OK" STOP 101 PRINT *,"error" CLOSE(UNIT=10, STATUS='DELETE') END [EMAIL PROTECTED]:~/tmp> gfortran -v conf.f Driving: gfortran -v conf.f -lgfortranbegin -lgfortran -lm -shared-libgcc Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /home/martin/software/gcc/configure --disable-multilib --with-gmp=/home/martin/software/mygmp --with-mpfr=/home/martin/software/mympfr --prefix=/home/martin/software/ugcc --enable-languages=c++,fortran --enable-checking=release Thread model: posix gcc version 4.2.0 20060306 (experimental) /home/martin/software/ugcc/libexec/gcc/x86_64-unknown-linux-gnu/4.2.0/f951 conf.f -ffixed-form -quiet -dumpbase conf.f -mtune=generic -auxbase conf -version -I /home/martin/software/ugcc/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/finclude -o /tmp/ccS0dlhV.s GNU F95 version 4.2.0 20060306 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.2.0 20060306 (experimental). GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128005 as -V -Qy -o /tmp/cciwdHBI.o /tmp/ccS0dlhV.s GNU assembler version 2.16.91.0.2 (x86_64-suse-linux) using BFD version 2.16.91.0.2 20050720 (SuSE Linux) /home/martin/software/ugcc/libexec/gcc/x86_64-unknown-linux-gnu/4.2.0/collect2 --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o /home/martin/software/ugcc/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/crtbegin.o -L/home/martin/software/ugcc/lib/gcc/x86_64-unknown-linux-gnu/4.2.0 -L/home/martin/software/ugcc/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/home/martin/software/ugcc/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/../../.. /tmp/cciwdHBI.o -lgfortranbegin -lgfortran -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /home/martin/software/ugcc/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/crtend.o /usr/lib/../lib64/crtn.o [EMAIL PROTECTED]:~/tmp> ./a.out At line 7 of file conf.f Fortran runtime error: End of record -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26554
[Bug c/26581] New: incomplete (unsized) static array types cannot be completed
If this is (as I am fairly sure) a bug, then it will surely be a bug in the C front end, and as such be architecture-independent. The behaviour here complained of is peculiar to -pedantic, which chucks an error for what I believe is correct code. It's not even a warning otherwise, and I think rightly. The behaviour is seen in gcc-4.0.2 and gcc-4.1, an may well be older, as I have only recently started to use -pedantic by default. BS ISO/IEC 9899:1999 6.2.5 para.22 (first two sentences) An array type of unknown size is an incomplete type. It is completed, for an identifier of that type, by specifying the size in a later declaration (with internal or external linkage). There's a great deal of murk in the Standard, some of which is relevant, but in this cases at least, m'lud, the law is clear. Just as one may have extern int thingy1[]; extern int thingy1[1]; one may have (with file scope, not block scope) static int thingy2[]; static int thingy2[1]; gcc is happy with the 'extern' version, but not with the 'static' ones: it gags, claiming that the first declaration is bad ("array size missing") and the second is inconsistent with it ("conflicting types"). Perhaps the much stricter rules for block-scope declarations confused the implementers? Specifically, objects other than function parameters declared in a block which are not explicitly given the storage-class 'extern' have no linkage (Standard 6.2.2 para. 6), and an object with no linkage may not have an incomplete type declaration (6.7 para. 7). The reason for this restriction escapes me (why on earth not allow deferred type completion here too?). This is not the end of the story, but I'm steering clear of the full horrors of 'extern' in this particular bug report. I have not found a comparable problem with other incomplete types (pointers to incompletely defined struct types, &c.), irrespective of linkage. Bernard Leak -- What's wrong with a recursive dmalloc, anyway? -- Summary: incomplete (unsized) static array types cannot be completed Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bernard at brenda-arkle dot demon dot co dot uk GCC build triplet: (same) GCC host triplet: i686-pc-linux-gnu GCC target triplet: (same) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26581
[Bug c/26581] incomplete (unsized) static array types cannot be completed
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-06 13:53 --- Comeau C front-end also rejects this code: Comeau C/C++ 4.3.3 (Aug 6 2003 15:13:37) for ONLINE_EVALUATION_BETA1 Copyright 1988-2003 Comeau Computing. All rights reserved. MODE:strict errors C99 "ComeauTest.c", line 1: error: incomplete type is not allowed static int thingy2[]; ^ http://www.comeaucomputing.com/tryitout/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26581
[Bug libfortran/26499] gfortran - End of File incorrectly positioned after binary I/O.
--- Comment #12 from dir at lanl dot gov 2006-03-06 14:06 --- It works great on the Macintosh. Now, if someone could just get the windows version of gfortran under MinGW to pass these I/O tests, it might become usuable. My programs compile under MinGW, but they all crash when I try to run them - mostly with I/O problems. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26499
[Bug c/26581] incomplete (unsized) static array types cannot be completed
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-06 14:06 --- Not a bug: >From C99, 6.9.2/3 says: If the declaration of an identifier for an object is a tentative definition and has internal linkage, the declared type shall not be an incomplete type. -- This is a tentative definition and is internal linkage and in this case the type incomplete so it is invalid code which is correctly rejected. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26581
[Bug c/26581] incomplete (unsized) static array types cannot be completed
--- Comment #3 from joseph at codesourcery dot com 2006-03-06 14:10 --- Subject: Re: New: incomplete (unsized) static array types cannot be completed On Mon, 6 Mar 2006, bernard at brenda-arkle dot demon dot co dot uk wrote: > static int thingy2[]; > static int thingy2[1]; This contradicts 6.9.2 paragraph 3: "If the declaration of an identifier for an object is a tentative definition and has internal linkage, the declared type shall not be an incomplete type.". (Undefined behavior since it's not in a Constraints section, so diagnostic not required, but as a quality of implementation matter it should be diagnosed at least with -pedantic.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26581
[Bug target/26505] Storing float to int into two different pointers requires stack space
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-06 14:20 --- Confirmed. Also happens on x86 too. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-06 14:20:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26505
[Bug fortran/26554] [gfortran] incorrect behaviour when reading a logical variable from a string
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2006-03-06 14:22 --- On Comment #8: Yes I will be committing the logical patch to 4.1 branch soon. On Comment #9: This is not really a bug depending on how one interprets the f95 standard. The three error families, EOR, END, and ERR are each treated separately. EOR and END are not considered the same as ERR. This is probably processor dependant behavior. Regardless, it is PR26509 which we are still evaluating. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26554
[Bug middle-end/26561] [4.2 Regression] ACATS failures c34004a, c46033a and cxg2024 at -O0
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-06 14:26 --- Just for future reference, here is the C testcase that Eric B. posted to the list: /* PR middle-end/26561 */ extern void abort(void); int always_one_1 (int a) { if (a/100 >= -9) return 1; else return 0; } int always_one_2 (int a) { if (a/100 < -9) return 0; else return 1; } int main(void) { if (always_one_1 (0) != 1) abort (); if (always_one_2 (0) != 1) abort (); return 0; } -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26561
[Bug tree-optimization/18754] unrolling happens too late/SRA does not happen late enough
--- Comment #16 from rguenth at gcc dot gnu dot org 2006-03-06 14:30 --- Or with a pass recovering loops before vectorization. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||22501 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18754
[Bug bootstrap/26582] New: [4.2 Regression] warning with cross build
I get the following warnings when doing a cross (any kind of cross really) Makefile:13366: warning: overriding commands for target `restrap' Makefile:12658: warning: ignoring old commands for target `restrap' -- Summary: [4.2 Regression] warning with cross build Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26582
[Bug fortran/26509] incorrect behaviour of error-handler for internal read
--- Comment #7 from martin at mpa-garching dot mpg dot de 2006-03-06 14:33 --- When trying to compile the Starlink sources with gfortran I stumbled across this too. Unfortunately it seems that one of their autoconf tests called AC_FC_RECL_UNIT relies on the jump to the ERR label when EOR occurs. If you decide that gfortran is currently doing the right thing, I'll ask them to fix the test. -- martin at mpa-garching dot mpg dot de changed: What|Removed |Added CC||martin at mpa-garching dot ||mpg dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26509
[Bug bootstrap/26582] [4.2 Regression] warning with cross build
--- Comment #1 from paolo dot bonzini at lu dot unisi dot ch 2006-03-06 14:35 --- Subject: Re: New: [4.2 Regression] warning with cross build pinskia at gcc dot gnu dot org wrote: > I get the following warnings when doing a cross (any kind of cross really) > Makefile:13366: warning: overriding commands for target `restrap' > Makefile:12658: warning: ignoring old commands for target `restrap' > I was aware of this, did nothing so far because Dan Jacobowitz said he would rip old bootstrap bits soon (including this one). Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26582
[Bug bootstrap/26582] [4.2 Regression] warning with cross build
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-06 14:37 --- Subject: Re: [4.2 Regression] warning with cross build > > > > --- Comment #1 from paolo dot bonzini at lu dot unisi dot ch 2006-03-06 > 14:35 --- > Subject: Re: New: [4.2 Regression] warning with cross > build > > pinskia at gcc dot gnu dot org wrote: > > I get the following warnings when doing a cross (any kind of cross really) > > Makefile:13366: warning: overriding commands for target `restrap' > > Makefile:12658: warning: ignoring old commands for target `restrap' > > > I was aware of this, did nothing so far because Dan Jacobowitz said he > would rip old bootstrap bits soon (including this one). I should note that I filed this because I was tried of seeing the warning when I built the compiler. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26582
[Bug tree-optimization/13761] [tree-ssa] component refs to the same struct should not alias
--- Comment #15 from rguenth at gcc dot gnu dot org 2006-03-06 14:39 --- The problem for the original testcase is that we don't even try to build SFTs required for structure aliasing analysis for incoming pointers: foo0 (f) { int D.1529; : # SMT.4_4 = V_MAY_DEF ; f_1->s = 1; # SMT.4_5 = V_MAY_DEF ; f_1->s2 = 2; which is required to turn these into V_MUST_DEFs. Of course we still can do propagation of the values in ccp or copyprop if we walk the virtual use-def chains there and disabmiguate the offsets. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13761
[Bug fortran/26554] [gfortran] incorrect behaviour when reading a logical variable from a string
--- Comment #11 from martin at mpa-garching dot mpg dot de 2006-03-06 14:41 --- > On Comment #9: This is not really a bug depending on how one interprets the > f95 standard. The three error families, EOR, END, and ERR are each treated > separately. EOR and END are not considered the same as ERR. I see. But in a WRITE statement, EOR and END must not be specified; how should I try to catch the error condition then? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26554
[Bug c++/13954] [tree-ssa] SRA does not work for classes that use inheritance with an empty base
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-03-06 14:41 --- In principle this blocks optimization of tramp3d domain operations (if it were not structure-aliasing fixing most of the problems). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||22501 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13954
[Bug middle-end/26565] [4.0/4.1/4.2 Regression] Unaligned accesses with __attribute__(packed) and memcpy
--- Comment #8 from patchapp at dberlin dot org 2006-03-06 14:55 --- Subject: Bug number PR middle-end/26565 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00324.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26565
[Bug rtl-optimization/25569] [4.2 Regression] FAIL: gfortran.dg/g77/20010610.f -O3 -fomit-frame-pointer -funroll-loops
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-06 15:00 --- (In reply to comment #1) > (gdb) p debug_rtx (insn) > (insn 41 39 42 5 (set (reg:DI 71 [ D.775 ]) > (zero_extend:DI (subreg:QI (reg/v:DI 70 [ i ]) 7))) 129 {*pa.md:4636} > (nil) > (nil)) > $9 = void This is a similar instruction which effects ppc64 also. It also fails the same way on powerpc64-darwin. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet|hppa64-hp-hpux11.11,|hppa64-hp-hpux11.11, |powerpc64-linux |powerpc64-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25569
[Bug bootstrap/18058] [4.2 Regression] Sun CC cannot bootstrap GCC (static inline)
--- Comment #28 from patchapp at dberlin dot org 2006-03-06 15:07 --- Subject: Bug number PR bootstrap/18058 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00297.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18058
[Bug bootstrap/26582] [4.2 Regression] warning with cross build
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26582
[Bug tree-optimization/26447] [4.2 Regression] verify_flow_info failed, load PRE
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-03-06 15:24 --- I might look into fix this later this week, the problem is the creating of loads which could cause an trap/exception but not putting them into different BB's. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26447
[Bug testsuite/26344] [4.2 Regression] three testsuite failures in gcc.dg/tree-ssa/
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-03-06 15:29 --- Any news on these three testsuite failures? It is getting annoying to have testsuite regressions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26344
[Bug bootstrap/26500] [4.2 Regression] info/gfortran.info is no longer being installed
--- Comment #3 from patchapp at dberlin dot org 2006-03-06 15:30 --- Subject: Bug number PR bootstrap/26500 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00124.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26500
[Bug testsuite/26344] [4.2 Regression] three testsuite failures in gcc.dg/tree-ssa/
--- Comment #9 from law at redhat dot com 2006-03-06 15:35 --- Subject: Re: [4.2 Regression] three testsuite failures in gcc.dg/tree-ssa/ On Mon, 2006-03-06 at 15:29 +, pinskia at gcc dot gnu dot org wrote: > > --- Comment #8 from pinskia at gcc dot gnu dot org 2006-03-06 15:29 > --- > Any news on these three testsuite failures? It is getting annoying to have > testsuite regressions. As I've mentioned at least 3 times now, the Ada mis-compilations have priority. I'm working on these between fixing Ada issues. When there's status worth mentioning, I'll certainly add the status to his PR. Until then, bugging me about it isn't helping. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26344
[Bug rtl-optimization/25569] [4.2 Regression] FAIL: gfortran.dg/g77/20010610.f -O3 -fomit-frame-pointer -funroll-loops
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-06 15:49 --- Janis could you do a regression hunt on what caused this testcase to start to fail? The C testcase is: int f(void) { int i; for(i=0;i<256;i++) { char a = i; int ii = a; if (ii != i) __builtin_abort(); } } -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||janis at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25569
[Bug libstdc++/26526] [4.1/4.2 Regression] std::__copy_streambufs link failure when _GLIBCXX_DEBUG is defined
--- Comment #7 from bkoz at gcc dot gnu dot org 2006-03-06 16:10 --- Paolo, versioning bits look fine. lm cw ij are the usual rules you need to keep in mind for this stuff but fixing this is not a big deal. -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26526
[Bug libgcj/26483] Wrong parsing of doubles when interpreted on ia64
--- Comment #9 from tromey at gcc dot gnu dot org 2006-03-06 17:08 --- You can read about the java programming language's requirements for floating point here: http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3 Relevant quote: In particular, the Java programming language requires support of IEEE 754 denormalized floating-point numbers and gradual underflow -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26483
[Bug testsuite/26344] [4.2 Regression] three testsuite failures in gcc.dg/tree-ssa/
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-03-06 17:10 --- (In reply to comment #9) > As I've mentioned at least 3 times now, the Ada mis-compilations > have priority. I'm working on these between fixing Ada issues. > When there's status worth mentioning, I'll certainly add the > status to his PR. Until then, bugging me about it isn't > helping. These are older regressions than the Ada regressions and they show up as testsuite failures and also it has been 3 weeks since this has been reported enough time to fix them, yes it might be a minor regression to you but it is an annoying regression to the people who are testing their patches as they see the fails and think it was their patch (this has already happened with these testsuite failures already, see PR 26406). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26344
[Bug testsuite/26344] [4.2 Regression] three testsuite failures in gcc.dg/tree-ssa/
--- Comment #11 from law at redhat dot com 2006-03-06 17:21 --- Subject: Re: [4.2 Regression] three testsuite failures in gcc.dg/tree-ssa/ On Mon, 2006-03-06 at 17:10 +, pinskia at gcc dot gnu dot org wrote: > > --- Comment #10 from pinskia at gcc dot gnu dot org 2006-03-06 17:10 > --- > (In reply to comment #9) > > As I've mentioned at least 3 times now, the Ada mis-compilations > > have priority. I'm working on these between fixing Ada issues. > > When there's status worth mentioning, I'll certainly add the > > status to his PR. Until then, bugging me about it isn't > > helping. > > These are older regressions than the Ada regressions and they show up as > testsuite failures and also it has been 3 weeks since this has been reported > enough time to fix them, yes it might be a minor regression to you but it is > an > annoying regression to the people who are testing their patches as they see > the > fails and think it was their patch (this has already happened with these > testsuite failures already, see PR 26406). They are minor performance related regressions. The Ada regresions are incorrect code. The Ada regressions have priority. You're not helping here. As I've said before, be patient. The problems will be addressed. The more you bug me the longer this process takes. When there's something worth reporting, I'll report it. Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26344
[Bug c++/6634] wrong parsing of "long long double"
--- Comment #8 from patchapp at dberlin dot org 2006-03-06 17:45 --- Subject: Bug number PR c++/6634 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00334.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6634
[Bug target/26532] libmudflap failures on ia64
--- Comment #9 from paolo at gcc dot gnu dot org 2006-03-06 18:06 --- Subject: Bug 26532 Author: paolo Date: Mon Mar 6 18:06:47 2006 New Revision: 111789 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111789 Log: 2006-03-06 Paolo Carlini <[EMAIL PROTECTED]> PR target/26532 * config/io/c_io_stdio.h (struct __ios_flags): Remove. * include/bits/ios_base.h: Adjust consistently. (ios_base::_S_local_word_size): Change to an anonymous enum. * src/ios.cc: Do not define static const data of __ios_flags, likewise for ios_base::_S_local_word_size. * include/bits/locale_classes.h (locale::_S_categories_size): Change to an anonymous enum. * src/locale.cc: Don't define. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/io/c_io_stdio.h trunk/libstdc++-v3/include/bits/ios_base.h trunk/libstdc++-v3/include/bits/locale_classes.h trunk/libstdc++-v3/src/ios.cc trunk/libstdc++-v3/src/locale.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26532
[Bug target/26532] libmudflap failures on ia64
-- pcarlini at suse dot de changed: What|Removed |Added Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26532
[Bug c/26581] incomplete (unsized) static array types cannot be completed
--- Comment #4 from bernard at brenda-arkle dot demon dot co dot uk 2006-03-06 18:35 --- Thanks - I'd forgotten that 'static' declarations can be tentative definitions too. But now I'm even more confused! As I wrote, unsized arrays do one thing, undefined structs do another (this is a "gcc fact" whatever its ANSI-legal status). Consider this: struct poo; /* declares an incomplete structure type, 6.7.2.3 para. 7 */ static struct poo thingy; /* a tentative definition, 6.9.2 para. 2 */ /* The structure type is still incomplete, 6.7.2.3 para. 3 */ /* any subsequent definition of struct poo is too late */ Shouldn't this now be flagged as an error, at least if '-pedantic' is requested? If I'm wrong again about this, I'll shut up... Bernard Leak -- I remember when the Standard had fewer than 8 bits' worth of confusing pages! -- bernard at brenda-arkle dot demon dot co dot uk changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26581
[Bug c/26581] incomplete (unsized) static array types cannot be completed
--- Comment #5 from joseph at codesourcery dot com 2006-03-06 18:58 --- Subject: Re: incomplete (unsized) static array types cannot be completed On Mon, 6 Mar 2006, bernard at brenda-arkle dot demon dot co dot uk wrote: > struct poo; /* declares an incomplete structure type, 6.7.2.3 para. 7 */ > static struct poo thingy; /* a tentative definition, 6.9.2 para. 2 */ > /* The structure type is still incomplete, 6.7.2.3 para. 3 */ > /* any subsequent definition of struct poo is too late */ > > Shouldn't this now be flagged as an error, at least if '-pedantic' > is requested? Yes. Again, this is a quality-of-implementation issue since the requirement is not a Constraint. I'm already aware of the issue that if the struct is subsequently defined there isn't an error here, though I don't think there's a bug filed (bug 24293 is related but not the same). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26581
[Bug fortran/22038] Forall with mask broken
--- Comment #6 from pault at gcc dot gnu dot org 2006-03-06 20:33 --- This one was fixed a long time since but does not seem to have been cleared. The recent flurry of activity on the dependency checking has made keeping it open unnecessary IMHO. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22038
[Bug fortran/22038] Forall with mask broken
--- Comment #7 from jakub at gcc dot gnu dot org 2006-03-06 20:44 --- Are you sure? forall_8.f90 testcase still fails for me with gfortran as of a few days ago. If the problem is fixed and the testcases aren't invalid, they should be added to the testsuite, otherwise this needs to be reopened. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22038
[Bug fortran/20405] [meta-bug] equivalenced variable problems
--- Comment #1 from pault at gcc dot gnu dot org 2006-03-06 20:58 --- (In reply to comment #0) > There are currently two equivalenced variable problems but I suspect there are > more which is why I am > creating this meta-bug. > I believe that 24406 has fixed itself and that both can be closed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20405
[Bug fortran/24406] EQUIVALENCE broken in 32-bit code with optimization -O2
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-03-06 21:03 --- (In reply to comment #11) > > Even though the final tree dump looks correct this is a still a front-end > > issue > > as the front-end communicates the aliasing sets to the rtl optimizers. > > I am going to take it too. > > I have either missed something, the PR has fixed itself or it is not a > front-end problem. See below. The symptom of this testcase passing might work but the bug is still there and most likely cannot expose it at the tree level and it is semi hard to expose it even on the RTL level. Comment #5 shows what needs to be added to the Fortran front-end which I will do sometime this week when I get some time (but note I have two papers to write which is what is right now taking up my time). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24406
[Bug fortran/20405] [meta-bug] equivalenced variable problems
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-06 21:05 --- (In reply to comment #1) > I believe that 24406 has fixed itself and that both can be closed. See my reply in PR 24406 to the message that it is fixed, it is just harder to expose. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20405
[Bug target/23706] [4.1 Regression] ICE in rtl_verify_flow_info_1
--- Comment #15 from kkojima at gcc dot gnu dot org 2006-03-06 22:40 --- Subject: Bug 23706 Author: kkojima Date: Mon Mar 6 22:40:49 2006 New Revision: 111792 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111792 Log: PR target/23706 Backport from 4.1: * lcm.c (optimize_mode_switching): Clear transp bit for block with incomming abnormal edges. PR target/22553 Backport from 4.1: * config/sh/sh.h (OPTIMIZATION_OPTIONS): Set flag_schedule_insns to 2 if it's already non-zero. (OVERRIDE_OPTIONS): Clear flag_schedule_insns if flag_exceptions is set and warn about it if flag_schedule_insns is 1. Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/config/sh/sh.h branches/gcc-4_0-branch/gcc/lcm.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23706
[Bug target/22553] [4.1/4.2 regression] ICE building libstdc++
--- Comment #9 from kkojima at gcc dot gnu dot org 2006-03-06 22:40 --- Subject: Bug 22553 Author: kkojima Date: Mon Mar 6 22:40:49 2006 New Revision: 111792 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111792 Log: PR target/23706 Backport from 4.1: * lcm.c (optimize_mode_switching): Clear transp bit for block with incomming abnormal edges. PR target/22553 Backport from 4.1: * config/sh/sh.h (OPTIMIZATION_OPTIONS): Set flag_schedule_insns to 2 if it's already non-zero. (OVERRIDE_OPTIONS): Clear flag_schedule_insns if flag_exceptions is set and warn about it if flag_schedule_insns is 1. Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/config/sh/sh.h branches/gcc-4_0-branch/gcc/lcm.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22553
[Bug fortran/26586] New: g77 -pedantic wrongly rejecting statement function
The following Fortran 77 program declares and uses a statement function I2C(M). When compiled with these options: g77 -pedantic -v -save-temps it is misread as a character substring with its : missing, but IMHO this statement function is valid in Fortran 77. The program compiles and runs OK if the -pedantic is removed. Below are the program listing, the compiler output, and the .s file generated by the compiler. There was no .i* file. tahi[~/Jfh] % cat testsf.f PROGRAM TESTSF CHARACTER I2C*2, CDIGIT(0:9)*1 DATA CDIGIT/'0','1','2','3','4','5','6','7','8','9'/ * Statement function I2C to convert integer 0 to 99 to character*2 I2C(M) = CDIGIT(M/10) // CDIGIT(MOD(M,10)) * End of statement functions; start of executables PRINT '(10A3)', (I2C(M),M=0,99) END tahi[~/Jfh] tahi[~/Jfh] % g77 -pedantic -v -save-temps testsf.f Driving: g77 -pedantic -v -save-temps testsf.f -lfrtbegin -lg2c -lm -shared-libgcc Reading specs from /usr/pkg/gcc3/lib/gcc-lib/sparc-sun-solaris2/3.3.4/specs Configured with: ./configure --prefix=/usr/pkg/gcc3 --host=sparc-sun-solaris2 --enable-shared --enable-languages=f77 Thread model: posix gcc version 3.3.4 /usr/pkg/gcc3/lib/gcc-lib/sparc-sun-solaris2/3.3.4/f771 testsf.f -quiet -dumpbase testsf.f -auxbase testsf -pedantic -version -o testsf.s GNU F77 version 3.3.4 (sparc-sun-solaris2) compiled by GNU C version 3.3.4. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 testsf.f: In program `testsf': testsf.f:5: I2C(M) = CDIGIT(M/10) // CDIGIT(MOD(M,10)) 12 Missing colon as of (2) in substring reference for (1) testsf.f:7: PRINT '(10A3)', (I2C(M),M=0,99) 12 Missing colon as of (2) in substring reference for (1) tahi[~/Jfh] % tahi[~/Jfh] % cat testsf.s .file "testsf.f" .section".data" .align 8 .type cdigit.0, #object .size cdigit.0, 10 cdigit.0: .ascii "0" .ascii "1" .ascii "2" .ascii "3" .ascii "4" .ascii "5" .ascii "6" .ascii "7" .ascii "8" .ascii "9" .global .rem .global .div .section".rodata" .align 8 .LLC1: .asciz "(10A3)" .section".data" .align 4 .type __g77_cilist_0.1, #object .size __g77_cilist_0.1, 20 __g77_cilist_0.1: .long 0 .long 6 .long 0 .long .LLC1 .long 0 .ident "GCC: (GNU) 3.3.4" tahi[~/Jfh] % -- Summary: g77 -pedantic wrongly rejecting statement function Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: john dot harper at vuw dot ac dot nz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26586
[Bug fortran/26586] g77 -pedantic wrongly rejecting statement function
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-06 22:56 --- Fixed in 4.0.0 with the gfortran rewrite. 3.4.6 is about to be released and there is almost no way to get a non regression fixed. So closing as fixed for 4.0.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Keywords||rejects-valid Known to fail||2.95.3 3.2.3 3.3.2 3.3.3 ||3.4.0 3.0.4 Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26586
[Bug fortran/26107] ICE after error message on invalid code
--- Comment #4 from pault at gcc dot gnu dot org 2006-03-06 22:56 --- Subject: Bug 26107 Author: pault Date: Mon Mar 6 22:56:39 2006 New Revision: 111793 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111793 Log: 2006-03-06 Paul Thomas <[EMAIL PROTECTED]> PR fortran/26107 * resolve.c (resolve_function): Add name after test for pureness. PR fortran/19546 * trans-expr.c (gfc_conv_variable): Detect reference to parent result, store current_function_decl, replace with parent, whilst calls are made to gfc_get_fake_result_decl, and restore afterwards. Signal this to gfc_get_fake_result_decl with a new argument, parent_flag. * trans-stmt.c (gfc_trans_return): gfc_get_fake_result_decl 2nd arg is set to zero. * trans.h: Add parent_flag to gfc_get_fake_result_decl prototype. * trans-decl.c (gfc_get_fake_result_decl): On parent_flag, being set, add decl to parent function. Replace refs to current_fake_result_decl with refs to this_result_decl. (gfc_generate_function_code): Null parent_fake_result_decl before the translation of code for contained procedures. Set parent_flag to zero in call to gfc_get_fake_result_decl. * trans-intrinsic.c (gfc_conv_intrinsic_len): The same. 2006-03-06 Paul Thomas <[EMAIL PROTECTED]> PR fortran/26107 * pure_dummy_length_1.f90: New test. PR fortran/19546 * gfortran.dg/parent_result_ref_1.f90: New test. * gfortran.dg/parent_result_ref_2.f90: New test. * gfortran.dg/parent_result_ref_3.f90: New test. * gfortran.dg/parent_result_ref_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/parent_result_ref_1.f90 trunk/gcc/testsuite/gfortran.dg/parent_result_ref_2.f90 trunk/gcc/testsuite/gfortran.dg/parent_result_ref_3.f90 (with props) trunk/gcc/testsuite/gfortran.dg/parent_result_ref_4.f90 trunk/gcc/testsuite/gfortran.dg/pure_dummy_length_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/fortran/trans-openmp.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog Propchange: trunk/gcc/testsuite/gfortran.dg/parent_result_ref_3.f90 ('svn:executable' added) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26107
[Bug fortran/19546] Internal subroutine setting function return value gives internal compiler error
--- Comment #7 from pault at gcc dot gnu dot org 2006-03-06 22:56 --- Subject: Bug 19546 Author: pault Date: Mon Mar 6 22:56:39 2006 New Revision: 111793 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111793 Log: 2006-03-06 Paul Thomas <[EMAIL PROTECTED]> PR fortran/26107 * resolve.c (resolve_function): Add name after test for pureness. PR fortran/19546 * trans-expr.c (gfc_conv_variable): Detect reference to parent result, store current_function_decl, replace with parent, whilst calls are made to gfc_get_fake_result_decl, and restore afterwards. Signal this to gfc_get_fake_result_decl with a new argument, parent_flag. * trans-stmt.c (gfc_trans_return): gfc_get_fake_result_decl 2nd arg is set to zero. * trans.h: Add parent_flag to gfc_get_fake_result_decl prototype. * trans-decl.c (gfc_get_fake_result_decl): On parent_flag, being set, add decl to parent function. Replace refs to current_fake_result_decl with refs to this_result_decl. (gfc_generate_function_code): Null parent_fake_result_decl before the translation of code for contained procedures. Set parent_flag to zero in call to gfc_get_fake_result_decl. * trans-intrinsic.c (gfc_conv_intrinsic_len): The same. 2006-03-06 Paul Thomas <[EMAIL PROTECTED]> PR fortran/26107 * pure_dummy_length_1.f90: New test. PR fortran/19546 * gfortran.dg/parent_result_ref_1.f90: New test. * gfortran.dg/parent_result_ref_2.f90: New test. * gfortran.dg/parent_result_ref_3.f90: New test. * gfortran.dg/parent_result_ref_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/parent_result_ref_1.f90 trunk/gcc/testsuite/gfortran.dg/parent_result_ref_2.f90 trunk/gcc/testsuite/gfortran.dg/parent_result_ref_3.f90 (with props) trunk/gcc/testsuite/gfortran.dg/parent_result_ref_4.f90 trunk/gcc/testsuite/gfortran.dg/pure_dummy_length_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/fortran/trans-openmp.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/ChangeLog Propchange: trunk/gcc/testsuite/gfortran.dg/parent_result_ref_3.f90 ('svn:executable' added) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19546
[Bug fortran/26107] ICE after error message on invalid code
--- Comment #5 from pault at gcc dot gnu dot org 2006-03-06 23:03 --- Fixed on mainline and will be fixed tomorrow on 4.1. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26107
[Bug fortran/19546] Internal subroutine setting function return value gives internal compiler error
--- Comment #8 from pault at gcc dot gnu dot org 2006-03-06 23:21 --- This will only be fixed on 4.2. The 4.1 and 4.2 trees have diverged so much in gfc_get_fake_result_decl that it will be a lot of work to bring it up to the point where it will take the patch for this PR. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19546
[Bug fortran/26041] [4.1]: FORTRAN compiler won't compile the valid code
--- Comment #10 from pault at gcc dot gnu dot org 2006-03-06 23:25 --- HJ Will you port this to 4.1 or should it be closed? My preference would be the former Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26041
[Bug fortran/24519] gfortran slow because of incomplete dependency checking
--- Comment #7 from pault at gcc dot gnu dot org 2006-03-07 00:06 --- Subject: Bug 24519 Author: pault Date: Tue Mar 7 00:06:37 2006 New Revision: 111796 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111796 Log: 2006-03-07 Paul Thomas <[EMAIL PROTECTED]> PR fortran/26107 * resolve.c (resolve_function): Add name after test for pureness. * iresolve.c (gfc_resolve_dot_product): Remove any difference in treatment of logical types. * trans-intrinsic.c (gfc_conv_intrinsic_dot_product): New function. PR fortran/26393 * trans-decl.c (gfc_get_symbol_decl): Extend condition that symbols must be referenced to include unreferenced symbols in an interface body. PR fortran/20938 * trans-array.c (gfc_conv_resolve_dependencies): Add call to gfc_are_equivalenced_arrays. * symbol.c (gfc_free_equiv_infos, gfc_free_equiv_lists): New functions. (gfc_free_namespace): Call them. * trans-common.c (copy_equiv_list_to_ns): New function. (add_equivalences): Call it. * gfortran.h: Add equiv_lists to gfc_namespace and define gfc_equiv_list and gfc_equiv_info. * dependency.c (gfc_are_equivalenced_arrays): New function. (gfc_check_dependency): Call it. * dependency.h: Prototype for gfc_are_equivalenced_arrays. PR fortran/24519 * dependency.c (gfc_is_same_range): Correct typo. (gfc_check_section_vs_section): Call gfc_is_same_range. PR fortran/25395 * trans-common.c (add_equivalences): Add a new flag that is set when an equivalence is seen that prevents more from being reset until the start of a new traversal of the list, thus ensuring completion of all the equivalences. PR fortran/25054 * resolve.c (is_non_constant_shape_array): New function. (resolve_fl_variable): Remove code for the new function and call it. (resolve_fl_namelist): New function. Add test for namelist array with non-constant shape, using is_non_constant_shape_array. (resolve_symbol): Remove code for resolve_fl_namelist and call it. PR fortran/25089 * match.c (match_namelist): Increment the refs field of an accepted namelist object symbol. * resolve.c (resolve_fl_namelist): Test namelist objects for a conflict with contained or module procedures. PR fortran/24557 * trans-expr.c (gfc_add_interface_mapping): Use the actual argument for character(*) arrays, rather than casting to the type and kind parameters of the formal argument. 2006-03-07 Paul Thomas <[EMAIL PROTECTED]> PR fortran/26107 * resolve.c (resolve_function): Add name after test for pureness. * gfortran.dg/logical_dot_product.f90: New test. PR fortran/26393 * gfortran.dg/used_interface_ref.f90: New test. PR fortran/20938 * gfortran.dg/dependency_2.f90: New test. * gfortran.fortran-torture/execute/where17.f90: New test. * gfortran.fortran-torture/execute/where18.f90: New test. * gfortran.fortran-torture/execute/where19.f90: New test. * gfortran.fortran-torture/execute/where20.f90: New test. PR fortran/24519 * gfortran.dg/dependency_3.f90: New test. * gfortran.fortran-torture/execute/vect-3.f90: Remove two of the XFAILs. PR fortran/25395 * gfortran.dg/equiv_6.f90: New test. PR fortran/25054 * gfortran.dg/namelist_5.f90: New test. PR fortran/25089 * gfortran.dg/namelist_4.f90: New test. PR fortran/24557 * gfortran.dg/assumed_charlen_needed_1.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/assumed_charlen_needed_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/dependency_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/dependency_3.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/equiv_6.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/logical_dot_product.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/namelist_4.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/namelist_5.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/pure_dummy_length_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/used_interface_ref.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.fortran-torture/execute/where17.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.fortran-torture/execute/where18.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.fortran-torture/execute/where19.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.fortran-torture/execute/where20.f90 Modified: branches/gcc-4_1-branch/MAINTAINERS branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/dependency.c branches/gcc-4_1-branch/gcc/for
[Bug fortran/25395] equivalence to common block array broken
--- Comment #5 from pault at gcc dot gnu dot org 2006-03-07 00:06 --- Subject: Bug 25395 Author: pault Date: Tue Mar 7 00:06:37 2006 New Revision: 111796 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111796 Log: 2006-03-07 Paul Thomas <[EMAIL PROTECTED]> PR fortran/26107 * resolve.c (resolve_function): Add name after test for pureness. * iresolve.c (gfc_resolve_dot_product): Remove any difference in treatment of logical types. * trans-intrinsic.c (gfc_conv_intrinsic_dot_product): New function. PR fortran/26393 * trans-decl.c (gfc_get_symbol_decl): Extend condition that symbols must be referenced to include unreferenced symbols in an interface body. PR fortran/20938 * trans-array.c (gfc_conv_resolve_dependencies): Add call to gfc_are_equivalenced_arrays. * symbol.c (gfc_free_equiv_infos, gfc_free_equiv_lists): New functions. (gfc_free_namespace): Call them. * trans-common.c (copy_equiv_list_to_ns): New function. (add_equivalences): Call it. * gfortran.h: Add equiv_lists to gfc_namespace and define gfc_equiv_list and gfc_equiv_info. * dependency.c (gfc_are_equivalenced_arrays): New function. (gfc_check_dependency): Call it. * dependency.h: Prototype for gfc_are_equivalenced_arrays. PR fortran/24519 * dependency.c (gfc_is_same_range): Correct typo. (gfc_check_section_vs_section): Call gfc_is_same_range. PR fortran/25395 * trans-common.c (add_equivalences): Add a new flag that is set when an equivalence is seen that prevents more from being reset until the start of a new traversal of the list, thus ensuring completion of all the equivalences. PR fortran/25054 * resolve.c (is_non_constant_shape_array): New function. (resolve_fl_variable): Remove code for the new function and call it. (resolve_fl_namelist): New function. Add test for namelist array with non-constant shape, using is_non_constant_shape_array. (resolve_symbol): Remove code for resolve_fl_namelist and call it. PR fortran/25089 * match.c (match_namelist): Increment the refs field of an accepted namelist object symbol. * resolve.c (resolve_fl_namelist): Test namelist objects for a conflict with contained or module procedures. PR fortran/24557 * trans-expr.c (gfc_add_interface_mapping): Use the actual argument for character(*) arrays, rather than casting to the type and kind parameters of the formal argument. 2006-03-07 Paul Thomas <[EMAIL PROTECTED]> PR fortran/26107 * resolve.c (resolve_function): Add name after test for pureness. * gfortran.dg/logical_dot_product.f90: New test. PR fortran/26393 * gfortran.dg/used_interface_ref.f90: New test. PR fortran/20938 * gfortran.dg/dependency_2.f90: New test. * gfortran.fortran-torture/execute/where17.f90: New test. * gfortran.fortran-torture/execute/where18.f90: New test. * gfortran.fortran-torture/execute/where19.f90: New test. * gfortran.fortran-torture/execute/where20.f90: New test. PR fortran/24519 * gfortran.dg/dependency_3.f90: New test. * gfortran.fortran-torture/execute/vect-3.f90: Remove two of the XFAILs. PR fortran/25395 * gfortran.dg/equiv_6.f90: New test. PR fortran/25054 * gfortran.dg/namelist_5.f90: New test. PR fortran/25089 * gfortran.dg/namelist_4.f90: New test. PR fortran/24557 * gfortran.dg/assumed_charlen_needed_1.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/assumed_charlen_needed_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/dependency_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/dependency_3.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/equiv_6.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/logical_dot_product.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/namelist_4.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/namelist_5.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/pure_dummy_length_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/used_interface_ref.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.fortran-torture/execute/where17.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.fortran-torture/execute/where18.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.fortran-torture/execute/where19.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.fortran-torture/execute/where20.f90 Modified: branches/gcc-4_1-branch/MAINTAINERS branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/dependency.c branches/gcc-4_1-branch/gcc/for
[Bug fortran/26393] ICE with function returning variable lenght array
--- Comment #7 from pault at gcc dot gnu dot org 2006-03-07 00:06 --- Subject: Bug 26393 Author: pault Date: Tue Mar 7 00:06:37 2006 New Revision: 111796 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111796 Log: 2006-03-07 Paul Thomas <[EMAIL PROTECTED]> PR fortran/26107 * resolve.c (resolve_function): Add name after test for pureness. * iresolve.c (gfc_resolve_dot_product): Remove any difference in treatment of logical types. * trans-intrinsic.c (gfc_conv_intrinsic_dot_product): New function. PR fortran/26393 * trans-decl.c (gfc_get_symbol_decl): Extend condition that symbols must be referenced to include unreferenced symbols in an interface body. PR fortran/20938 * trans-array.c (gfc_conv_resolve_dependencies): Add call to gfc_are_equivalenced_arrays. * symbol.c (gfc_free_equiv_infos, gfc_free_equiv_lists): New functions. (gfc_free_namespace): Call them. * trans-common.c (copy_equiv_list_to_ns): New function. (add_equivalences): Call it. * gfortran.h: Add equiv_lists to gfc_namespace and define gfc_equiv_list and gfc_equiv_info. * dependency.c (gfc_are_equivalenced_arrays): New function. (gfc_check_dependency): Call it. * dependency.h: Prototype for gfc_are_equivalenced_arrays. PR fortran/24519 * dependency.c (gfc_is_same_range): Correct typo. (gfc_check_section_vs_section): Call gfc_is_same_range. PR fortran/25395 * trans-common.c (add_equivalences): Add a new flag that is set when an equivalence is seen that prevents more from being reset until the start of a new traversal of the list, thus ensuring completion of all the equivalences. PR fortran/25054 * resolve.c (is_non_constant_shape_array): New function. (resolve_fl_variable): Remove code for the new function and call it. (resolve_fl_namelist): New function. Add test for namelist array with non-constant shape, using is_non_constant_shape_array. (resolve_symbol): Remove code for resolve_fl_namelist and call it. PR fortran/25089 * match.c (match_namelist): Increment the refs field of an accepted namelist object symbol. * resolve.c (resolve_fl_namelist): Test namelist objects for a conflict with contained or module procedures. PR fortran/24557 * trans-expr.c (gfc_add_interface_mapping): Use the actual argument for character(*) arrays, rather than casting to the type and kind parameters of the formal argument. 2006-03-07 Paul Thomas <[EMAIL PROTECTED]> PR fortran/26107 * resolve.c (resolve_function): Add name after test for pureness. * gfortran.dg/logical_dot_product.f90: New test. PR fortran/26393 * gfortran.dg/used_interface_ref.f90: New test. PR fortran/20938 * gfortran.dg/dependency_2.f90: New test. * gfortran.fortran-torture/execute/where17.f90: New test. * gfortran.fortran-torture/execute/where18.f90: New test. * gfortran.fortran-torture/execute/where19.f90: New test. * gfortran.fortran-torture/execute/where20.f90: New test. PR fortran/24519 * gfortran.dg/dependency_3.f90: New test. * gfortran.fortran-torture/execute/vect-3.f90: Remove two of the XFAILs. PR fortran/25395 * gfortran.dg/equiv_6.f90: New test. PR fortran/25054 * gfortran.dg/namelist_5.f90: New test. PR fortran/25089 * gfortran.dg/namelist_4.f90: New test. PR fortran/24557 * gfortran.dg/assumed_charlen_needed_1.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/assumed_charlen_needed_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/dependency_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/dependency_3.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/equiv_6.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/logical_dot_product.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/namelist_4.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/namelist_5.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/pure_dummy_length_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/used_interface_ref.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.fortran-torture/execute/where17.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.fortran-torture/execute/where18.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.fortran-torture/execute/where19.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.fortran-torture/execute/where20.f90 Modified: branches/gcc-4_1-branch/MAINTAINERS branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/dependency.c branches/gcc-4_1-branch/gcc/for
[Bug fortran/26107] ICE after error message on invalid code
--- Comment #6 from pault at gcc dot gnu dot org 2006-03-07 00:06 --- Subject: Bug 26107 Author: pault Date: Tue Mar 7 00:06:37 2006 New Revision: 111796 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111796 Log: 2006-03-07 Paul Thomas <[EMAIL PROTECTED]> PR fortran/26107 * resolve.c (resolve_function): Add name after test for pureness. * iresolve.c (gfc_resolve_dot_product): Remove any difference in treatment of logical types. * trans-intrinsic.c (gfc_conv_intrinsic_dot_product): New function. PR fortran/26393 * trans-decl.c (gfc_get_symbol_decl): Extend condition that symbols must be referenced to include unreferenced symbols in an interface body. PR fortran/20938 * trans-array.c (gfc_conv_resolve_dependencies): Add call to gfc_are_equivalenced_arrays. * symbol.c (gfc_free_equiv_infos, gfc_free_equiv_lists): New functions. (gfc_free_namespace): Call them. * trans-common.c (copy_equiv_list_to_ns): New function. (add_equivalences): Call it. * gfortran.h: Add equiv_lists to gfc_namespace and define gfc_equiv_list and gfc_equiv_info. * dependency.c (gfc_are_equivalenced_arrays): New function. (gfc_check_dependency): Call it. * dependency.h: Prototype for gfc_are_equivalenced_arrays. PR fortran/24519 * dependency.c (gfc_is_same_range): Correct typo. (gfc_check_section_vs_section): Call gfc_is_same_range. PR fortran/25395 * trans-common.c (add_equivalences): Add a new flag that is set when an equivalence is seen that prevents more from being reset until the start of a new traversal of the list, thus ensuring completion of all the equivalences. PR fortran/25054 * resolve.c (is_non_constant_shape_array): New function. (resolve_fl_variable): Remove code for the new function and call it. (resolve_fl_namelist): New function. Add test for namelist array with non-constant shape, using is_non_constant_shape_array. (resolve_symbol): Remove code for resolve_fl_namelist and call it. PR fortran/25089 * match.c (match_namelist): Increment the refs field of an accepted namelist object symbol. * resolve.c (resolve_fl_namelist): Test namelist objects for a conflict with contained or module procedures. PR fortran/24557 * trans-expr.c (gfc_add_interface_mapping): Use the actual argument for character(*) arrays, rather than casting to the type and kind parameters of the formal argument. 2006-03-07 Paul Thomas <[EMAIL PROTECTED]> PR fortran/26107 * resolve.c (resolve_function): Add name after test for pureness. * gfortran.dg/logical_dot_product.f90: New test. PR fortran/26393 * gfortran.dg/used_interface_ref.f90: New test. PR fortran/20938 * gfortran.dg/dependency_2.f90: New test. * gfortran.fortran-torture/execute/where17.f90: New test. * gfortran.fortran-torture/execute/where18.f90: New test. * gfortran.fortran-torture/execute/where19.f90: New test. * gfortran.fortran-torture/execute/where20.f90: New test. PR fortran/24519 * gfortran.dg/dependency_3.f90: New test. * gfortran.fortran-torture/execute/vect-3.f90: Remove two of the XFAILs. PR fortran/25395 * gfortran.dg/equiv_6.f90: New test. PR fortran/25054 * gfortran.dg/namelist_5.f90: New test. PR fortran/25089 * gfortran.dg/namelist_4.f90: New test. PR fortran/24557 * gfortran.dg/assumed_charlen_needed_1.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/assumed_charlen_needed_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/dependency_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/dependency_3.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/equiv_6.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/logical_dot_product.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/namelist_4.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/namelist_5.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/pure_dummy_length_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/used_interface_ref.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.fortran-torture/execute/where17.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.fortran-torture/execute/where18.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.fortran-torture/execute/where19.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.fortran-torture/execute/where20.f90 Modified: branches/gcc-4_1-branch/MAINTAINERS branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/dependency.c branches/gcc-4_1-branch/gcc/for
[Bug fortran/24557] ICE: PRINTing function result of size depending on assumed length CHARACTER dummy
--- Comment #6 from pault at gcc dot gnu dot org 2006-03-07 00:06 --- Subject: Bug 24557 Author: pault Date: Tue Mar 7 00:06:37 2006 New Revision: 111796 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111796 Log: 2006-03-07 Paul Thomas <[EMAIL PROTECTED]> PR fortran/26107 * resolve.c (resolve_function): Add name after test for pureness. * iresolve.c (gfc_resolve_dot_product): Remove any difference in treatment of logical types. * trans-intrinsic.c (gfc_conv_intrinsic_dot_product): New function. PR fortran/26393 * trans-decl.c (gfc_get_symbol_decl): Extend condition that symbols must be referenced to include unreferenced symbols in an interface body. PR fortran/20938 * trans-array.c (gfc_conv_resolve_dependencies): Add call to gfc_are_equivalenced_arrays. * symbol.c (gfc_free_equiv_infos, gfc_free_equiv_lists): New functions. (gfc_free_namespace): Call them. * trans-common.c (copy_equiv_list_to_ns): New function. (add_equivalences): Call it. * gfortran.h: Add equiv_lists to gfc_namespace and define gfc_equiv_list and gfc_equiv_info. * dependency.c (gfc_are_equivalenced_arrays): New function. (gfc_check_dependency): Call it. * dependency.h: Prototype for gfc_are_equivalenced_arrays. PR fortran/24519 * dependency.c (gfc_is_same_range): Correct typo. (gfc_check_section_vs_section): Call gfc_is_same_range. PR fortran/25395 * trans-common.c (add_equivalences): Add a new flag that is set when an equivalence is seen that prevents more from being reset until the start of a new traversal of the list, thus ensuring completion of all the equivalences. PR fortran/25054 * resolve.c (is_non_constant_shape_array): New function. (resolve_fl_variable): Remove code for the new function and call it. (resolve_fl_namelist): New function. Add test for namelist array with non-constant shape, using is_non_constant_shape_array. (resolve_symbol): Remove code for resolve_fl_namelist and call it. PR fortran/25089 * match.c (match_namelist): Increment the refs field of an accepted namelist object symbol. * resolve.c (resolve_fl_namelist): Test namelist objects for a conflict with contained or module procedures. PR fortran/24557 * trans-expr.c (gfc_add_interface_mapping): Use the actual argument for character(*) arrays, rather than casting to the type and kind parameters of the formal argument. 2006-03-07 Paul Thomas <[EMAIL PROTECTED]> PR fortran/26107 * resolve.c (resolve_function): Add name after test for pureness. * gfortran.dg/logical_dot_product.f90: New test. PR fortran/26393 * gfortran.dg/used_interface_ref.f90: New test. PR fortran/20938 * gfortran.dg/dependency_2.f90: New test. * gfortran.fortran-torture/execute/where17.f90: New test. * gfortran.fortran-torture/execute/where18.f90: New test. * gfortran.fortran-torture/execute/where19.f90: New test. * gfortran.fortran-torture/execute/where20.f90: New test. PR fortran/24519 * gfortran.dg/dependency_3.f90: New test. * gfortran.fortran-torture/execute/vect-3.f90: Remove two of the XFAILs. PR fortran/25395 * gfortran.dg/equiv_6.f90: New test. PR fortran/25054 * gfortran.dg/namelist_5.f90: New test. PR fortran/25089 * gfortran.dg/namelist_4.f90: New test. PR fortran/24557 * gfortran.dg/assumed_charlen_needed_1.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/assumed_charlen_needed_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/dependency_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/dependency_3.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/equiv_6.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/logical_dot_product.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/namelist_4.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/namelist_5.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/pure_dummy_length_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/used_interface_ref.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.fortran-torture/execute/where17.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.fortran-torture/execute/where18.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.fortran-torture/execute/where19.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.fortran-torture/execute/where20.f90 Modified: branches/gcc-4_1-branch/MAINTAINERS branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/dependency.c branches/gcc-4_1-branch/gcc/for
[Bug fortran/20938] Dependency checking fails for equivalences
--- Comment #8 from pault at gcc dot gnu dot org 2006-03-07 00:06 --- Subject: Bug 20938 Author: pault Date: Tue Mar 7 00:06:37 2006 New Revision: 111796 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111796 Log: 2006-03-07 Paul Thomas <[EMAIL PROTECTED]> PR fortran/26107 * resolve.c (resolve_function): Add name after test for pureness. * iresolve.c (gfc_resolve_dot_product): Remove any difference in treatment of logical types. * trans-intrinsic.c (gfc_conv_intrinsic_dot_product): New function. PR fortran/26393 * trans-decl.c (gfc_get_symbol_decl): Extend condition that symbols must be referenced to include unreferenced symbols in an interface body. PR fortran/20938 * trans-array.c (gfc_conv_resolve_dependencies): Add call to gfc_are_equivalenced_arrays. * symbol.c (gfc_free_equiv_infos, gfc_free_equiv_lists): New functions. (gfc_free_namespace): Call them. * trans-common.c (copy_equiv_list_to_ns): New function. (add_equivalences): Call it. * gfortran.h: Add equiv_lists to gfc_namespace and define gfc_equiv_list and gfc_equiv_info. * dependency.c (gfc_are_equivalenced_arrays): New function. (gfc_check_dependency): Call it. * dependency.h: Prototype for gfc_are_equivalenced_arrays. PR fortran/24519 * dependency.c (gfc_is_same_range): Correct typo. (gfc_check_section_vs_section): Call gfc_is_same_range. PR fortran/25395 * trans-common.c (add_equivalences): Add a new flag that is set when an equivalence is seen that prevents more from being reset until the start of a new traversal of the list, thus ensuring completion of all the equivalences. PR fortran/25054 * resolve.c (is_non_constant_shape_array): New function. (resolve_fl_variable): Remove code for the new function and call it. (resolve_fl_namelist): New function. Add test for namelist array with non-constant shape, using is_non_constant_shape_array. (resolve_symbol): Remove code for resolve_fl_namelist and call it. PR fortran/25089 * match.c (match_namelist): Increment the refs field of an accepted namelist object symbol. * resolve.c (resolve_fl_namelist): Test namelist objects for a conflict with contained or module procedures. PR fortran/24557 * trans-expr.c (gfc_add_interface_mapping): Use the actual argument for character(*) arrays, rather than casting to the type and kind parameters of the formal argument. 2006-03-07 Paul Thomas <[EMAIL PROTECTED]> PR fortran/26107 * resolve.c (resolve_function): Add name after test for pureness. * gfortran.dg/logical_dot_product.f90: New test. PR fortran/26393 * gfortran.dg/used_interface_ref.f90: New test. PR fortran/20938 * gfortran.dg/dependency_2.f90: New test. * gfortran.fortran-torture/execute/where17.f90: New test. * gfortran.fortran-torture/execute/where18.f90: New test. * gfortran.fortran-torture/execute/where19.f90: New test. * gfortran.fortran-torture/execute/where20.f90: New test. PR fortran/24519 * gfortran.dg/dependency_3.f90: New test. * gfortran.fortran-torture/execute/vect-3.f90: Remove two of the XFAILs. PR fortran/25395 * gfortran.dg/equiv_6.f90: New test. PR fortran/25054 * gfortran.dg/namelist_5.f90: New test. PR fortran/25089 * gfortran.dg/namelist_4.f90: New test. PR fortran/24557 * gfortran.dg/assumed_charlen_needed_1.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/assumed_charlen_needed_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/dependency_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/dependency_3.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/equiv_6.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/logical_dot_product.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/namelist_4.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/namelist_5.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/pure_dummy_length_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/used_interface_ref.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.fortran-torture/execute/where17.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.fortran-torture/execute/where18.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.fortran-torture/execute/where19.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.fortran-torture/execute/where20.f90 Modified: branches/gcc-4_1-branch/MAINTAINERS branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/dependency.c branches/gcc-4_1-branch/gcc/for
[Bug fortran/25089] Contained function and namelist names clash.
--- Comment #3 from pault at gcc dot gnu dot org 2006-03-07 00:06 --- Subject: Bug 25089 Author: pault Date: Tue Mar 7 00:06:37 2006 New Revision: 111796 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111796 Log: 2006-03-07 Paul Thomas <[EMAIL PROTECTED]> PR fortran/26107 * resolve.c (resolve_function): Add name after test for pureness. * iresolve.c (gfc_resolve_dot_product): Remove any difference in treatment of logical types. * trans-intrinsic.c (gfc_conv_intrinsic_dot_product): New function. PR fortran/26393 * trans-decl.c (gfc_get_symbol_decl): Extend condition that symbols must be referenced to include unreferenced symbols in an interface body. PR fortran/20938 * trans-array.c (gfc_conv_resolve_dependencies): Add call to gfc_are_equivalenced_arrays. * symbol.c (gfc_free_equiv_infos, gfc_free_equiv_lists): New functions. (gfc_free_namespace): Call them. * trans-common.c (copy_equiv_list_to_ns): New function. (add_equivalences): Call it. * gfortran.h: Add equiv_lists to gfc_namespace and define gfc_equiv_list and gfc_equiv_info. * dependency.c (gfc_are_equivalenced_arrays): New function. (gfc_check_dependency): Call it. * dependency.h: Prototype for gfc_are_equivalenced_arrays. PR fortran/24519 * dependency.c (gfc_is_same_range): Correct typo. (gfc_check_section_vs_section): Call gfc_is_same_range. PR fortran/25395 * trans-common.c (add_equivalences): Add a new flag that is set when an equivalence is seen that prevents more from being reset until the start of a new traversal of the list, thus ensuring completion of all the equivalences. PR fortran/25054 * resolve.c (is_non_constant_shape_array): New function. (resolve_fl_variable): Remove code for the new function and call it. (resolve_fl_namelist): New function. Add test for namelist array with non-constant shape, using is_non_constant_shape_array. (resolve_symbol): Remove code for resolve_fl_namelist and call it. PR fortran/25089 * match.c (match_namelist): Increment the refs field of an accepted namelist object symbol. * resolve.c (resolve_fl_namelist): Test namelist objects for a conflict with contained or module procedures. PR fortran/24557 * trans-expr.c (gfc_add_interface_mapping): Use the actual argument for character(*) arrays, rather than casting to the type and kind parameters of the formal argument. 2006-03-07 Paul Thomas <[EMAIL PROTECTED]> PR fortran/26107 * resolve.c (resolve_function): Add name after test for pureness. * gfortran.dg/logical_dot_product.f90: New test. PR fortran/26393 * gfortran.dg/used_interface_ref.f90: New test. PR fortran/20938 * gfortran.dg/dependency_2.f90: New test. * gfortran.fortran-torture/execute/where17.f90: New test. * gfortran.fortran-torture/execute/where18.f90: New test. * gfortran.fortran-torture/execute/where19.f90: New test. * gfortran.fortran-torture/execute/where20.f90: New test. PR fortran/24519 * gfortran.dg/dependency_3.f90: New test. * gfortran.fortran-torture/execute/vect-3.f90: Remove two of the XFAILs. PR fortran/25395 * gfortran.dg/equiv_6.f90: New test. PR fortran/25054 * gfortran.dg/namelist_5.f90: New test. PR fortran/25089 * gfortran.dg/namelist_4.f90: New test. PR fortran/24557 * gfortran.dg/assumed_charlen_needed_1.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/assumed_charlen_needed_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/dependency_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/dependency_3.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/equiv_6.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/logical_dot_product.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/namelist_4.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/namelist_5.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/pure_dummy_length_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/used_interface_ref.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.fortran-torture/execute/where17.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.fortran-torture/execute/where18.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.fortran-torture/execute/where19.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.fortran-torture/execute/where20.f90 Modified: branches/gcc-4_1-branch/MAINTAINERS branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/dependency.c branches/gcc-4_1-branch/gcc/for
[Bug fortran/25054] nonconstant bounds array cannot appear in a namelist
--- Comment #5 from pault at gcc dot gnu dot org 2006-03-07 00:06 --- Subject: Bug 25054 Author: pault Date: Tue Mar 7 00:06:37 2006 New Revision: 111796 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111796 Log: 2006-03-07 Paul Thomas <[EMAIL PROTECTED]> PR fortran/26107 * resolve.c (resolve_function): Add name after test for pureness. * iresolve.c (gfc_resolve_dot_product): Remove any difference in treatment of logical types. * trans-intrinsic.c (gfc_conv_intrinsic_dot_product): New function. PR fortran/26393 * trans-decl.c (gfc_get_symbol_decl): Extend condition that symbols must be referenced to include unreferenced symbols in an interface body. PR fortran/20938 * trans-array.c (gfc_conv_resolve_dependencies): Add call to gfc_are_equivalenced_arrays. * symbol.c (gfc_free_equiv_infos, gfc_free_equiv_lists): New functions. (gfc_free_namespace): Call them. * trans-common.c (copy_equiv_list_to_ns): New function. (add_equivalences): Call it. * gfortran.h: Add equiv_lists to gfc_namespace and define gfc_equiv_list and gfc_equiv_info. * dependency.c (gfc_are_equivalenced_arrays): New function. (gfc_check_dependency): Call it. * dependency.h: Prototype for gfc_are_equivalenced_arrays. PR fortran/24519 * dependency.c (gfc_is_same_range): Correct typo. (gfc_check_section_vs_section): Call gfc_is_same_range. PR fortran/25395 * trans-common.c (add_equivalences): Add a new flag that is set when an equivalence is seen that prevents more from being reset until the start of a new traversal of the list, thus ensuring completion of all the equivalences. PR fortran/25054 * resolve.c (is_non_constant_shape_array): New function. (resolve_fl_variable): Remove code for the new function and call it. (resolve_fl_namelist): New function. Add test for namelist array with non-constant shape, using is_non_constant_shape_array. (resolve_symbol): Remove code for resolve_fl_namelist and call it. PR fortran/25089 * match.c (match_namelist): Increment the refs field of an accepted namelist object symbol. * resolve.c (resolve_fl_namelist): Test namelist objects for a conflict with contained or module procedures. PR fortran/24557 * trans-expr.c (gfc_add_interface_mapping): Use the actual argument for character(*) arrays, rather than casting to the type and kind parameters of the formal argument. 2006-03-07 Paul Thomas <[EMAIL PROTECTED]> PR fortran/26107 * resolve.c (resolve_function): Add name after test for pureness. * gfortran.dg/logical_dot_product.f90: New test. PR fortran/26393 * gfortran.dg/used_interface_ref.f90: New test. PR fortran/20938 * gfortran.dg/dependency_2.f90: New test. * gfortran.fortran-torture/execute/where17.f90: New test. * gfortran.fortran-torture/execute/where18.f90: New test. * gfortran.fortran-torture/execute/where19.f90: New test. * gfortran.fortran-torture/execute/where20.f90: New test. PR fortran/24519 * gfortran.dg/dependency_3.f90: New test. * gfortran.fortran-torture/execute/vect-3.f90: Remove two of the XFAILs. PR fortran/25395 * gfortran.dg/equiv_6.f90: New test. PR fortran/25054 * gfortran.dg/namelist_5.f90: New test. PR fortran/25089 * gfortran.dg/namelist_4.f90: New test. PR fortran/24557 * gfortran.dg/assumed_charlen_needed_1.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/assumed_charlen_needed_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/dependency_2.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/dependency_3.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/equiv_6.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/logical_dot_product.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/namelist_4.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/namelist_5.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/pure_dummy_length_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/used_interface_ref.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.fortran-torture/execute/where17.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.fortran-torture/execute/where18.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.fortran-torture/execute/where19.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.fortran-torture/execute/where20.f90 Modified: branches/gcc-4_1-branch/MAINTAINERS branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/dependency.c branches/gcc-4_1-branch/gcc/for
[Bug fortran/26554] [gfortran] incorrect behaviour when reading a logical variable from a string
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2006-03-07 01:07 --- In the interim, use the iostat= and test for the error you are looking for. I am still digging around on this one to make sure I am not in a standard compliance conflict if I implement this feature. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26554
[Bug rtl-optimization/26587] New: strict aliasing incorrectly pre-loads an array element
I _think_ I understand C strict aliasing - it's based on the type of expressions. In the testcase below, the type of expressions is the same, which is why I think it's a compiler bug. The bug is reproducible with gcc 4.1.0 on multiple platforms. I've tried i386 (i686) and alpha myself and am able to reproduce the problem on both. The original reporter of the problem with my program (the real one, not the testcase) was able to reproduce the problem on other architectures. The problem does not occur with gcc 2.95.3 and 3.4.5. Basically, in the program below, gcc 4.1.0 would pre-load BF_current.P[0] and BF_current.P[17] into registers or stack locations - however the loop modifies P[0] via ptr. #include #include #define BF_N 16 typedef unsigned int BF_word; typedef BF_word BF_key[BF_N + 2]; static struct { BF_word S[4][0x100]; BF_key P; } BF_current; #define BF_ROUND(L, R, N) \ tmp1 = L & 0xFF; \ tmp2 = L >> 8; \ tmp2 &= 0xFF; \ tmp3 = L >> 16; \ tmp3 &= 0xFF; \ tmp4 = L >> 24; \ tmp1 = BF_current.S[3][tmp1]; \ tmp2 = BF_current.S[2][tmp2]; \ tmp3 = BF_current.S[1][tmp3]; \ tmp3 += BF_current.S[0][tmp4]; \ tmp3 ^= tmp2; \ R ^= BF_current.P[N + 1]; \ tmp3 += tmp1; \ R ^= tmp3; #define BF_ENCRYPT \ L ^= BF_current.P[0]; \ { \ int i; \ for (i = 0; i < BF_N; i += 2) { \ BF_ROUND(L, R, i); \ BF_ROUND(R, L, i+1); \ } \ } \ tmp4 = R; \ R = L; \ L = tmp4 ^ BF_current.P[BF_N + 1]; int main(void) { BF_word L, R; BF_word tmp1, tmp2, tmp3, tmp4, *ptr; BF_word i, j; for (i = 0; i < 4; i++) for (j = 0; j < 0x100; j++) BF_current.S[i][j] = (i + 0x12345678) * j; for (i = 0; i < BF_N + 2; i++) BF_current.P[i] = i * 0x98765432; L = R = 0; ptr = BF_current.P; do { #ifndef WORKAROUND ptr += 2; BF_ENCRYPT; *(ptr - 2) = L; *(ptr - 1) = R; #else BF_ENCRYPT; *ptr = L; *(ptr + 1) = R; ptr += 2; #endif } while (ptr < &BF_current.P[BF_N + 2]); printf("%08x %08x\n", L, R); return 0; } host!user:~$ gcc gcc-4.1.0-aliasing-bug.c -o gcc-4.1.0-aliasing-bug -Wall -O2 -fno-strict-aliasing host!user:~$ ./gcc-4.1.0-aliasing-bug 8261e2e6 f1f1bc33 host!user:~$ gcc gcc-4.1.0-aliasing-bug.c -o gcc-4.1.0-aliasing-bug -Wall -O2 host!user:~$ ./gcc-4.1.0-aliasing-bug 46be060b df072f90 host!user:~$ gcc gcc-4.1.0-aliasing-bug.c -o gcc-4.1.0-aliasing-bug -Wall -O2 -DWORKAROUND host!user:~$ ./gcc-4.1.0-aliasing-bug 8261e2e6 f1f1bc33 host!user:~$ uname -mrs Linux 2.4.32-ow1 alpha host!user:~$ gcc -v Using built-in specs. Target: alphaev56-unknown-linux-gnu Configured with: ./configure --prefix=/home/user/gcc-4.1.0 Thread model: posix gcc version 4.1.0 (i386 gives the same results) -- Summary: strict aliasing incorrectly pre-loads an array element Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: solar at openwall 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=26587
[Bug rtl-optimization/26587] strict aliasing incorrectly pre-loads an array element
--- Comment #1 from solar at openwall dot com 2006-03-07 01:50 --- Created an attachment (id=10979) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10979&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26587
[Bug rtl-optimization/26587] strict aliasing incorrectly pre-loads an array element
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-07 02:03 --- Hmm -O2 -fno-ivopts allows for it to work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26587
[Bug fortran/26588] New: gfortran -fopenmp passes unrecognised -pthread
On cygwin, gfortran -fopenmp gives the warning gfortran: unrecognized option '-pthread' which gives a heap of failures in the testsuite. This is set in gcc.c: /* Adding -fopenmp should imply pthreads. This is particularly important for targets that use different start files and suchlike. */ #ifndef GOMP_SELF_SPECS #define GOMP_SELF_SPECS "%{fopenmp: -pthread}" #endif I think the fix is to override it, as is done in gcc/config/darwin.h /* Every program on darwin links against libSystem which contains the pthread routines, so there's no need to explicitly call out when doing threaded work. */ #undef GOMP_SELF_SPECS #define GOMP_SELF_SPECS "" I'll prepare a patch at some stage. -- Summary: gfortran -fopenmp passes unrecognised -pthread Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: billingd at gcc dot gnu dot org ReportedBy: billingd at gcc dot gnu dot org GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26588
[Bug fortran/26588] gfortran -fopenmp passes unrecognised -pthread
-- billingd at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-07 02:05:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26588
[Bug rtl-optimization/26587] [4.1 Regression] strict aliasing incorrectly pre-loads an array element with loops
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-07 02:08 --- This is interesting because the mainline works with or without -fno-strict-aliasing. Confirmed a regression, hopefully someone will reduce the testcase further. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |critical Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Known to fail||4.1.0 Known to work||4.2.0 4.0.3 Last reconfirmed|-00-00 00:00:00 |2006-03-07 02:08:20 date|| Summary|strict aliasing incorrectly |[4.1 Regression] strict |pre-loads an array element |aliasing incorrectly pre- ||loads an array element with ||loops Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26587
[Bug target/26588] gfortran -fopenmp passes unrecognised -pthread
--- Comment #1 from billingd at gcc dot gnu dot org 2006-03-07 02:22 --- I am testing this. 2006-03-07 David Billinghurst ([EMAIL PROTECTED]) PR target/26588 * config/i386/cygwin.h (GOMP_SELF_SPECS): Define. --- cygwin.h~ 2006-02-01 14:17:44.0 +1100 +++ cygwin.h2006-03-07 13:08:52.420324700 +1100 @@ -232,3 +232,10 @@ /* Binutils does not handle weak symbols from dlls correctly. For now, do not use them unnecessarily in gthr-posix.h. */ #define GTHREAD_USE_WEAK 0 + +/* Every program on cygwin links against cygwin.dll which contains + the pthread routines. There is no need to explicitly link them + and the -pthread flag is not recognised. */ +#undef GOMP_SELF_SPECS +#define GOMP_SELF_SPECS "" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26588
[Bug fortran/25054] nonconstant bounds array cannot appear in a namelist
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25054
[Bug fortran/25089] Contained function and namelist names clash.
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25089
[Bug fortran/20938] Dependency checking fails for equivalences
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20938
[Bug fortran/24557] ICE: PRINTing function result of size depending on assumed length CHARACTER dummy
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24557
[Bug fortran/26107] ICE after error message on invalid code
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26107
[Bug fortran/26393] ICE with function returning variable lenght array
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26393
[Bug fortran/25395] equivalence to common block array broken
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.2.0 |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25395