[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #130 from ubizjak at gmail dot com 2007-07-03 07:11 --- (In reply to comment #129) > > current gfortran trunk seems to miscompile CP2K at -O2. The affected test is > > regtest-ot/C2H4.inp, and the file that is being miscompiled is mulliken.F. > > This > > is a regression wrt to 4.2.0, but I'm not sure when it was introduced. -O1 > > is > > Ok. > > miscompiled subroutine is mulliken_restraint Could you use bisection to isolate the patch that introduced regression? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug tree-optimization/32377] can't determine dependence (source/destination overlap without more than size)
--- Comment #6 from spop at gcc dot gnu dot org 2007-07-03 07:14 --- (In reply to comment #5) > I am not sure about that. I tried the following cases and got distance 1 (and > direction positive) in all of them for load and store to ia pair. > What am I missing? > Distance vectors are lexicographically positive vectors, that is why you get the 1 in all these cases. If you want to know which one comes first, you have to look at the DR_IS_READ for both references in the dependence relation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32377
[Bug middle-end/32604] New: miscompilation at -O2
as mentioned in the CP2K PR 29975, current trunk miscompiles CP2K at -O2. the following illustrates the issue: MODULE TEST IMPLICIT NONE INTEGER, PARAMETER :: dp=KIND(0.0D0) TYPE mulliken_restraint_type INTEGER :: ref_count REAL(KIND = dp) :: strength REAL(KIND = dp) :: TARGET INTEGER :: natoms INTEGER, POINTER, DIMENSION(:) :: atoms END TYPE mulliken_restraint_type CONTAINS SUBROUTINE INIT(mulliken) TYPE(mulliken_restraint_type), INTENT(INOUT) :: mulliken ALLOCATE(mulliken%atoms(1)) mulliken%atoms(1)=1 mulliken%natoms=1 mulliken%target=0 mulliken%strength=0 END SUBROUTINE INIT SUBROUTINE restraint_functional(mulliken_restraint_control,charges, & charges_deriv,energy,order_p) TYPE(mulliken_restraint_type), & INTENT(IN) :: mulliken_restraint_control REAL(KIND=dp), DIMENSION(:, :), POINTER :: charges, charges_deriv REAL(KIND=dp), INTENT(OUT) :: energy, order_p INTEGER :: I REAL(KIND=dp):: dum charges_deriv=0.0_dp order_p=0.0_dp DO I=1,mulliken_restraint_control%natoms order_p=order_p+charges(mulliken_restraint_control%atoms(I),1) & -charges(mulliken_restraint_control%atoms(I),2) ENDDO energy=mulliken_restraint_control%strength*(order_p-mulliken_restraint_control%target)**2 dum=2*mulliken_restraint_control%strength*(order_p-mulliken_restraint_control%target) DO I=1,mulliken_restraint_control%natoms charges_deriv(mulliken_restraint_control%atoms(I),1)= dum charges_deriv(mulliken_restraint_control%atoms(I),2)= -dum ENDDO END SUBROUTINE restraint_functional END MODULE USE TEST IMPLICIT NONE TYPE(mulliken_restraint_type) :: mulliken REAL(KIND=dp), DIMENSION(:, :), POINTER :: charges, charges_deriv REAL(KIND=dp) :: energy,order_p ALLOCATE(charges(1,2),charges_deriv(1,2)) charges(1,1)=2.0_dp charges(1,2)=1.0_dp CALL INIT(mulliken) CALL restraint_functional(mulliken,charges,charges_deriv,energy,order_p) write(6,*) order_p END > gfortran -O2 test.f90 > ./a.out 0.00 > gfortran -O1 test.f90 > ./a.out 1.00 this is for: Driving: gfortran -v -O2 test.f90 -lgfortranbegin -lgfortran -lm -shared-libgcc Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /data03/vondele/gcc_trunk/gcc/configure --prefix=/data03/vondele/gcc_trunk/build --with-gmp=/data03/vondele/ --with-mpfr=/data03/vondele/ --enable-languages=c,fortran Thread model: posix gcc version 4.3.0 20070702 (experimental) /data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.3.0/f951 test.f90 -quiet -dumpbase test.f90 -mtune=generic -auxbase test -O2 -version -fintrinsic-modules-path /data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/finclude -o /tmp/ccaqj3g7.s GNU F95 version 4.3.0 20070702 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.3.0 20070702 (experimental), GMP version 4.2.1, MPFR version 2.2.1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 as -V -Qy -o /tmp/cccJhUbb.o /tmp/ccaqj3g7.s GNU assembler version 2.16.91.0.5 (x86_64-suse-linux) using BFD version 2.16.91.0.5 20051219 (SUSE Linux) /data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.3.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 /data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/crtbegin.o -L/data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.3.0 -L/data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/../../.. /tmp/cccJhUbb.o -lgfortranbegin -lgfortran -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.3.0/crtend.o /usr/lib/../lib64/crtn.o -- Summary: miscompilation at -O2 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32604
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #131 from jv244 at cam dot ac dot uk 2007-07-03 07:22 --- (In reply to comment #130) > (In reply to comment #129) > Could you use bisection to isolate the patch that introduced regression? unfortunately, I don't have the setup to do so. However, I've filed a simple testcase as PR 32604 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug fortran/20888] dereferencing NULL still accepted
--- Comment #3 from burnus at gcc dot gnu dot org 2007-07-03 08:02 --- Subject: Bug 20888 Author: burnus Date: Tue Jul 3 08:02:08 2007 New Revision: 126247 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126247 Log: 2007-07-03 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/20888 * resolve.c (resolve_operator): Check for NULL as operand. 2007-07-03 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/20888 * gfortran.dg/null_2.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/null_2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20888
[Bug tree-optimization/32604] [4.3 regression] miscompilation at -O2
--- Comment #1 from ubizjak at gmail dot com 2007-07-03 08:31 --- Confirmed, introduced by revision 129146: Author: dberlin Date: Sat Jun 30 14:15:26 2007 New Revision: 126149 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126149 Log: 2007-06-30 Daniel Berlin <[EMAIL PROTECTED]> Fix PR tree-optimization/32540 Fix PR tree-optimization/31651 * tree-ssa-sccvn.c: New file. * tree-ssa-sccvn.h: Ditto. * tree-vn.c: Include tree-ssa-sccvn.h ... -- ubizjak at gmail dot com changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|middle-end |tree-optimization Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-03 08:31:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32604
[Bug target/32605] New: massive moves instead of bswap{l,q}
#include
#include
template < typename T >
void reverse( T& t )
{
unsigned char* bytes = reinterpret_cast< unsigned char* >( &t );
std::swap_ranges( bytes, bytes + sizeof( T ) / 2,
std::reverse_iterator< unsigned char* >( bytes + sizeof( T ) ) );
}
template void reverse( std::size_t& );
attached testcase produces massive byte-moves instead of bswap.
$ g++ -Wall swap_ranges.cpp -fomit-frame-pointer -m32 -O3 -c
(unsigned int&)>:
0: 8b 44 24 04 mov0x4(%esp),%eax
4: 0f b6 08movzbl (%eax),%ecx
7: 0f b6 50 03 movzbl 0x3(%eax),%edx
b: 88 48 03mov%cl,0x3(%eax)
e: 0f b6 48 01 movzbl 0x1(%eax),%ecx
12: 88 10 mov%dl,(%eax)
14: 0f b6 50 02 movzbl 0x2(%eax),%edx
18: 88 48 02mov%cl,0x2(%eax)
1b: 88 50 01mov%dl,0x1(%eax)
1e: c3 ret
(unsigned long&)>:
0: 0f b6 17movzbl (%rdi),%edx
3: 0f b6 47 07 movzbl 0x7(%rdi),%eax
7: 88 57 07mov%dl,0x7(%rdi)
a: 88 07 mov%al,(%rdi)
c: 0f b6 57 01 movzbl 0x1(%rdi),%edx
10: 0f b6 47 06 movzbl 0x6(%rdi),%eax
14: 88 57 06mov%dl,0x6(%rdi)
17: 88 47 01mov%al,0x1(%rdi)
1a: 0f b6 57 02 movzbl 0x2(%rdi),%edx
1e: 0f b6 47 05 movzbl 0x5(%rdi),%eax
22: 88 57 05mov%dl,0x5(%rdi)
25: 88 47 02mov%al,0x2(%rdi)
28: 0f b6 57 03 movzbl 0x3(%rdi),%edx
2c: 0f b6 47 04 movzbl 0x4(%rdi),%eax
30: 88 57 04mov%dl,0x4(%rdi)
33: 88 47 03mov%al,0x3(%rdi)
36: c3 retq
--
Summary: massive moves instead of bswap{l,q}
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
GCC target triplet: x86_64-*-*, i?86-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32605
[Bug middle-end/26061] error and warning count
--- Comment #13 from manu at gcc dot gnu dot org 2007-07-03 09:03 --- (In reply to comment #12) > [Here's what I sent to gcc-patches as a review of this patch:] > Doing this will certainly break many tools which parse the output of GCC, In the same way that adding any other output message would break those tools if those tools aren't prepared to deal with undefined output. We have a lot of messages that don't follow any prefix: "warnings being treated as errors", "compilation terminated due to -Wfatal-errors", etc. They are special cases in the testsuite. The message "gcc: *** 3 errors, 1 warning" cannot be confused with any existing output and any tool that parses the output of GCC should ignore messages that it cannot understand. In the worst case, the modification for any existing parser to ignore that line would be trivial. > especially in the case of a successful compilation which produced some > warnings. I don't get how a parser can be *especially* confused in this case unless you are parsing for the word "error" to determine the success of the compilation. And that would be doubly stupid: 1) you should actually look for " error: " and 2) the return value of GCC already tells whether the compilation succeeded. > I'm hard-pressed to think of a reason why, if this is implemented, you would > want to be able to switch it off, so I see no reason to have a flag (unless > someone else thinks of a reason). I cannot think of a reason either and if you strongly need to filter out that from the output, the regexp would be trivial and it will only match that line. Thanks for the review. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26061
[Bug tree-optimization/32604] [4.3 regression] miscompilation at -O2
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-03 09:12 --- I don't see anything obvious in the diff between before FRE and after, likewise for PRE. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||wrong-code Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32604
[Bug fortran/32526] [4.3 regression] Spurious error: Name 'x' at (1) is an ambiguous reference to 'x' from module 'y'
--- Comment #4 from pault at gcc dot gnu dot org 2007-07-03 09:38 --- > Adding Paul as CC. > I'll try to gt to it this afternoon. Thanks Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32526
[Bug tree-optimization/32606] New: ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1026
Hello, there seems to be a problem compiling the attached source file with i686-pc-linux-gnu-gcc: gcc -m32 -Wp,-MD,drivers/scsi/.atp870u.o.d -nostdinc -isystem /home/mstein/host-gcc/trunk-2007-07-03/bin/../lib/gcc/i686-pc-linux-gnu/4.3.0/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Os -pipe -msoft-float -mregparm=3 -mpreferred-stack-boundary=2 -march=i686 -mtune=generic -ffreestanding -maccumulate-outgoing-args -DCONFIG_AS_CFI=1 -Iinclude/asm-i386/mach-default -fno-omit-frame-pointer -fno-optimize-sibling-calls -g -fno-stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -DMODULE -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(atp870u)" -D"KBUILD_MODNAME=KBUILD_STR(atp870u)" -c -o drivers/scsi/.tmp_atp870u.o drivers/scsi/atp870u.c gcc: warning: -pipe ignored because -save-temps specified drivers/scsi/atp870u.c: In function 'is885': drivers/scsi/atp870u.c:3302: internal compiler error: in set_ssa_val_to, at tree-ssa-sccvn.c:1026 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. host gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /home/mstein/svn/trunk/configure --enable-languages=c --disable-nls --prefix=/n/07/mstein/host-gcc/trunk-2007-07-03 Thread model: posix gcc version 4.3.0 20070702 (experimental) Tested revision: 126237 Last succesfull build revision: 126095 -- Summary: ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1026 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mstein at phenix dot rootshell dot be 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=32606
[Bug tree-optimization/32606] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1026
--- Comment #1 from mstein at phenix dot rootshell dot be 2007-07-03 10:03 --- Created an attachment (id=13832) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13832&action=view) preprocessed source file from linux-2.6.20, delta-reduced -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32606
[Bug fortran/32600] [ISO Bind C] C_LOC/C_FUNLOC should not be library functions
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-03 10:19:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32600
[Bug fortran/32373] not vectorized: can't determine dependence (equivalence)
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-03 10:22:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32373
[Bug fortran/32454] Bounds-check misses overflow of lhs array
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||accepts-invalid Last reconfirmed|-00-00 00:00:00 |2007-07-03 10:25:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32454
[Bug fortran/32365] Better error message for specification statement in executable section
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-03 10:26:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32365
[Bug tree-optimization/32604] [4.3 regression] miscompilation at -O2
--- Comment #3 from ubizjak at gmail dot com 2007-07-03 10:26 --- (In reply to comment #2) > I don't see anything obvious in the diff between before FRE and after, > likewise > for PRE. gfortran -O1 -fno-tree-fre pr32604.f90 ./a.out 1.00 gfortran -O2 pr32604.f90 ./a.out 0.00 gfortran -O2 -fno-tree-pre pr32604.f90 ./a.out 1.00 gfortran -O2 -fno-tree-fre pr32604.f90 ./a.out 0.00 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32604
[Bug fortran/31688] Bogus "may be used uninitialized" warning
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-07-03 10:36 --- (In reply to comment #4) > I don't know how one should properly handle these in the front end (without > unneeded initialization of variables), but I reopened the bug and moved it to > the Fortran front end. They need to be marked with TREE_NO_WARNING. I did that once, but never came close to submitting the patch. I'll take care of this. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-03 10:36:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31688
[Bug fortran/31688] Bogus "may be used uninitialized" warning
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-07-03 10:36:33 |2007-07-03 10:37:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31688
[Bug fortran/32515] F2003: Reject COMMON block names if local symbol already exists
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-03 10:38:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32515
[Bug fortran/31608] wrong types in character array/scalar binop
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-03 10:40:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug fortran/32151] Misleading compilation diagnostic
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-03 10:41:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32151
[Bug middle-end/32417] [4.3 Regression] 416.gamess ICEs (in aff_combination_add_elt, tree-affine.c)
--- Comment #14 from rguenther at suse dot de 2007-07-03 10:55 --- Subject: Re: [4.3 Regression] 416.gamess ICEs (in aff_combination_add_elt, tree-affine.c) On Tue, 2 Jul 2007, pinskia at gcc dot gnu dot org wrote: > --- Comment #12 from pinskia at gcc dot gnu dot org 2007-07-02 23:58 > --- > One note, when I was originally fixing this bug, the test worked but now it > fails at -O1. I guess the new VN exposed the new problem. gamess didn't get back to working, but maybe the reduced testcase was indeed fixed for some time. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32417
[Bug other/31349] [4.3 Regression] gcc -v --help returns no options for C, C++
--- Comment #3 from nickc at redhat dot com 2007-07-03 10:59 --- Subject: Re: [4.3 Regression] gcc -v --help returns no options for C, C++ Hi Mark, > Nick, would you be able to look into this? Certainly - I'll get on it today. Cheers Nick -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31349
[Bug tree-optimization/32482] [i386] ICE verify_ssa failed
--- Comment #3 from renard at nospam dot dk 2007-07-03 10:59 ---
I get what I think is the exact same problem:
mm/slab.c:2243: error: expected an SSA_NAME object
mm/slab.c:2243: error: in statement
# VUSE { SFT.956 }
D.17707_131 = node_online_map.bits[0];
mm/slab.c:2243: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
gcc -v
Using built-in specs.
Target: vax-linux-uclibc
Configured with:
/home/mikkel/linux-vax/build/build-20070702-163607-UTC-vax-linux-uclibc/src/gcc/configure
--disable-multilib --with-newlib --disable-nls --enable-threads=no
--disable-threads --enable-symvers=gnu --enable-__cxa_atexit --disable-shared
--target=vax-linux-uclibc
--prefix=/home/mikkel/linux-vax/build/build-20070702-163607-UTC-vax-linux-uclibc/install/usr
--enable-languages=c,c++
Thread model: single
gcc version 4.3.0 20070702 (experimental)
The source is definitely available, but as it's the same file (although from
another version of the Linux kernel) as that of the original bug reporter it
seems to be of little use.
--
renard at nospam dot dk changed:
What|Removed |Added
CC||renard at nospam dot dk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32482
[Bug tree-optimization/32607] New: [4.3 Regression] internal compiler error: in set_lattice_value, at tree-ssa-ccp.c:487
$ gcc -mno-cygwin -O2 -c -o libavcodec_static_a-ffv1.o ffv1.i ffv1.c: In function 'encode_rgb_frame': ffv1.c:480: warning: assignment makes pointer from integer without a cast ffv1.c: In function 'decode_plane': ffv1.c:784: warning: initialization makes pointer from integer without a cast ffv1.c:784: warning: initialization makes pointer from integer without a cast ffv1.c: In function 'encode_rgb_frame': ffv1.c:465: internal compiler error: in set_lattice_value, at tree-ssa-ccp.c:487 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: [4.3 Regression] internal compiler error: in set_lattice_value, at tree-ssa-ccp.c:487 Product: gcc Version: tree-ssa Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jojelino at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32607
[Bug tree-optimization/32482] [4.3 Regression] ICE verify_ssa failed
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-07-03 12:00 --- Mine. -- 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|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2007-07-03 12:00:26 date|| Summary|[i386] ICE verify_ssa failed|[4.3 Regression] ICE ||verify_ssa failed Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32482
[Bug tree-optimization/32607] [4.3 Regression] internal compiler error: in set_lattice_value, at tree-ssa-ccp.c:487
--- Comment #1 from jojelino at gmail dot com 2007-07-03 12:01 --- Created an attachment (id=13833) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13833&action=view) preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32607
[Bug tree-optimization/32607] [4.3 Regression] internal compiler error: in set_lattice_value, at tree-ssa-ccp.c:487
--- Comment #2 from jojelino at gmail dot com 2007-07-03 12:02 --- svn revision 126249 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32607
[Bug tree-optimization/32604] [4.3 regression] miscompilation at -O2
--- Comment #4 from jv244 at cam dot ac dot uk 2007-07-03 12:09 --- possibly related to http://gcc.gnu.org/ml/gcc/2007-07/msg00037.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32604
[Bug tree-optimization/32377] can't determine dependence (source/destination overlap without more than size)
--- Comment #7 from irar at il dot ibm dot com 2007-07-03 12:57 ---
(In reply to comment #6)
> Distance vectors are lexicographically positive vectors, that is why you get
> the 1
> in all these cases. If you want to know which one comes first, you have to
> look
> at the DR_IS_READ for both references in the dependence relation.
I am sorry, but I still don't understand.
For
for (i = 0; i < N; i++){
ia[i+1] = ia[i] * 4;
}
the ddr is {ld, st} and distance 1
and for
for (i = 0; i < N; i++){
ia[i] = ia[i+1] * 4;
}
the ddr is also {ld, st} with distance 1.
How can we distinguish between these cases?
Thanks,
Ira
--
irar at il dot ibm dot com changed:
What|Removed |Added
CC||irar at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32377
[Bug middle-end/32589] [4.3 Regression] exp_dbug.adb:981: error: invalid array index
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-07-03 13:10
---
Reduced testcase:
package P is
Name_Buffer : String (1 .. 100);
Name_Len : Natural;
procedure Proc (S : String);
end P;
package body P is
procedure Proc (S : String) is
N : constant Integer := S'Length;
begin
Name_Buffer (1 + N .. Name_Len + N) := Name_Buffer (1 .. Name_Len);
Name_Buffer (1 .. N) := S;
Name_Len := Name_Len + N;
end;
end P;
Fallout of:
2007-06-30 Daniel Berlin <[EMAIL PROTECTED]>
Fix PR tree-optimization/32540
Fix PR tree-optimization/31651
* tree-ssa-sccvn.c: New file.
* tree-ssa-sccvn.h: Ditto.
Value numbering D.759_64 stmt = D.759_64 = &p__name_buffer[1]{lb: 1 sz: 1} +
n_32;
RHS &p__name_buffer[1]{lb: 1 sz: 1} + n_32 simplified to
&p__name_buffer[() MAX_EXPR + 1]{lb: 1 sz: 1}
has constants 0
The replacement expression is is_gimple_min_invariant because TREE_INVARIANT
so simplify_binary_expression accepts it:
/* Make sure result is not a complex expression consiting
of operators of operators (IE (a + b) + (a + c))
Otherwise, we will end up with unbounded expressions if
fold does anything at all. */
if (result)
{
if (is_gimple_min_invariant (result))
return result;
else if (SSA_VAR_P (result))
return result;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32589
[Bug libstdc++/32608] New: operator >> loads wrong value after istringsstream::str( string ).
$ cat iss.cpp
#include
#include
#include
int main()
{
std::istringstream is;
std::string s;
is.str( std::string( "1" ) );
std::cout << is.str() << std::endl;
is >> s;
std::cout << s << std::endl;
assert( s == "1" );
is.str( std::string( "2" ) );
std::cout << is.str() << std::endl;
is >> s;
std::cout << s << std::endl;
assert( s == "2 ");
}
$ g++ iss.cpp -Wall -o iss && ./iss
1
1
2
1
iss: iss.cpp:20: int main(): Assertion `s == "2 "' failed.
Aborted
--
Summary: operator >> loads wrong value after istringsstream::str(
string ).
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32608
[Bug libstdc++/32608] operator >> loads wrong value after istringsstream::str( string ).
--- Comment #1 from pluto at agmk dot net 2007-07-03 13:15 --- the testcase needs fix: s/assert( s == "2 ");/assert( s == "2");/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32608
[Bug c++/32609] New: [4.2/4.3 Regression] ICE in htab_clear_slot at libiberty/hashtab.c:722
This is a regression from 4.2.0 which happens on both the branch and the trunk. #2 0x0100363f in htab_clear_slot (htab=0x1649410, slot=0x168c1c0) at /space/rguenther/src/svn/trunk/libiberty/hashtab.c:722 #3 0x0052c797 in fixed_type_or_null (instance=0x2ae177ead4d0, nonnull=0x7fff359ca13c, cdtorp=0x7fff359ca0ac) at /space/rguenther/src/svn/trunk/gcc/cp/class.c:5380 #4 0x0052b643 in fixed_type_or_null (instance=0x2ae177b61f00, nonnull=0x7fff359ca13c, cdtorp=0x7fff359ca0ac) at /space/rguenther/src/svn/trunk/gcc/cp/class.c:5297 #5 0x0052c83d in resolves_to_fixed_type_p (instance=0x2ae177b61f00, nonnull=0x7fff359ca13c) at /space/rguenther/src/svn/trunk/gcc/cp/class.c:5412 #6 0x00500e36 in build_base_path (code=PLUS_EXPR, expr=0x2ae177b61f00, binfo=0x2ae1778ede80, nonnull=1) at /space/rguenther/src/svn/trunk/gcc/cp/class.c:291 #7 0x005a27c2 in build_class_member_access_expr ( object=0x2ae177b61ec0, member=0x2ae176f46240, access_path=0x2ae177b2d180, preserve_reference=0 '\0') at /space/rguenther/src/svn/trunk/gcc/cp/typeck.c:1876 #8 0x005a49a5 in finish_class_member_access_expr ( object=0x2ae177b61ec0, name=0x2ae175c81c60, template_p=0 '\0') at /space/rguenther/src/svn/trunk/gcc/cp/typeck.c:2236 ... testcase (from cln) is still reducing. -- Summary: [4.2/4.3 Regression] ICE in htab_clear_slot at libiberty/hashtab.c:722 Product: gcc Version: 4.2.1 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: critical Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32609
[Bug c++/32609] [4.2/4.3 Regression] ICE in htab_clear_slot at libiberty/hashtab.c:722
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-03 13:21 --- And before finishing reduction, this one at least looks possibly related: 2007-06-15 Mark Mitchell <[EMAIL PROTECTED]> * cp-tree.h (DECL_VAR_MARKED_P): Remove. (DECL_ANON_UNION_VAR_P): New macro. * class.c (fixed_type_or_null): Tidy. Use a hash table, rather than DECL_VAR_MARKED_P, to keep track of which variables we have seen. * decl.c (redeclaration_error_message): Complain about redeclaring anonymous union members at namespace scope. * decl2.c (build_anon_union_vars): Set DECL_ANON_UNION_VAR_P. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org Target Milestone|--- |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32609
[Bug tree-optimization/32606] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1026
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-07-03 13:29 --- Confirmed. Fails at -O. There are lots of similar ACATS failures on the trunk as well. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org, rguenth at gcc dot gnu ||dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-03 13:29:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32606
[Bug tree-optimization/32576] [4.3 Regression] internal compiler error: in set_ssa_val_to, at tree-ssa-sccvn.c:1011
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-07-03 13:32 --- Seems to be fixed. *** This bug has been marked as a duplicate of 32571 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32576
[Bug tree-optimization/32571] [4.3 Regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1011
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-07-03 13:32 --- *** Bug 32576 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jojelino at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32571
[Bug target/28307] [4.1/4.2/4.3 Regression] pthread functions in libgcc not weak any more on Tru64 UNIX
--- Comment #6 from ro at gcc dot gnu dot org 2007-07-03 13:36 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00533.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28307
[Bug c++/32609] [4.2/4.3 Regression] ICE in htab_clear_slot at libiberty/hashtab.c:722
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-07-03 13:37 --- Created an attachment (id=13834) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13834&action=view) testcase (unincluded, unreduced) Unreduced testcase. A reduced one only fails one out of 5 compiles - it looks like there is some memory or gc problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32609
[Bug target/28307] [4.1/4.2/4.3 Regression] pthread functions in libgcc not weak any more on Tru64 UNIX
--- Comment #7 from ro at gcc dot gnu dot org 2007-07-03 13:41 --- Subject: Bug 28307 Author: ro Date: Tue Jul 3 13:41:00 2007 New Revision: 126253 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126253 Log: PR target/28307 * gthr-posix.h [SUPPORTS_WEAK && GTHREAD_USE_WEAK] (__gthrw_pragma): Provide default definition. (__gthrw2): Use it. * gthr-posix.c (__gthrw_pragma): Define. Modified: trunk/gcc/ChangeLog trunk/gcc/gthr-posix.c trunk/gcc/gthr-posix.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28307
[Bug target/28307] [4.1/4.2/4.3 Regression] pthread functions in libgcc not weak any more on Tru64 UNIX
--- Comment #8 from ro at gcc dot gnu dot org 2007-07-03 13:43 --- Subject: Bug 28307 Author: ro Date: Tue Jul 3 13:43:01 2007 New Revision: 126254 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126254 Log: PR target/28307 * gthr-posix.h [SUPPORTS_WEAK && GTHREAD_USE_WEAK] (__gthrw_pragma): Provide default definition. (__gthrw2): Use it. * gthr-posix.c (__gthrw_pragma): Define. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/gthr-posix.c branches/gcc-4_2-branch/gcc/gthr-posix.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28307
[Bug target/28307] [4.1/4.2/4.3 Regression] pthread functions in libgcc not weak any more on Tru64 UNIX
--- Comment #9 from ro at gcc dot gnu dot org 2007-07-03 13:45 --- Subject: Bug 28307 Author: ro Date: Tue Jul 3 13:45:21 2007 New Revision: 126255 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126255 Log: PR target/28307 * gthr-posix.h [SUPPORTS_WEAK && GTHREAD_USE_WEAK] (__gthrw_pragma): Provide default definition. (__gthrw2): Use it. * gthr-posix.c (__gthrw_pragma): Define. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/gthr-posix.c branches/gcc-4_1-branch/gcc/gthr-posix.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28307
[Bug target/28307] [4.1/4.2/4.3 Regression] pthread functions in libgcc not weak any more on Tru64 UNIX
--- Comment #10 from ro at gcc dot gnu dot org 2007-07-03 13:46 --- Fixed for 4.1.3, 4.2.1, 4.3. -- ro at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28307
[Bug c++/32609] [4.2/4.3 Regression] ICE in htab_clear_slot at libiberty/hashtab.c:722
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-07-03 13:47 --- I guess what may happen is that we recurse twice, entering the same instance into the htab twice and at the second htab_clear_slot after returning from the first recursion we hit the assert. At least it looks fragile not to re-lookup the element. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32609
[Bug libgcj/28189] [4.1/4.2/4.3 Regression] Many libjava execution tests time out on Tru64 UNIX
-- ro at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ro at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-03 13:48:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28189
[Bug regression/32610] New: [4.2 4.3 regression] ICE in gen_tagged_type_instantiation_die, at dwarf2out.c:12762
seen with current gcc-4_2-branch and trunk, works with current gcc-4_1-branch. $ gcc-4.2 -Wall -O3 -g -s mycompute_ml-gccbug.c mycompute_ml-gccbug.c: In function 'matmat': mycompute_ml-gccbug.c:23: internal compiler error: in gen_tagged_type_instantiation_die, at dwarf2out.c:12762 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: [4.2 4.3 regression] ICE in gen_tagged_type_instantiation_die, at dwarf2out.c:12762 Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: doko at ubuntu dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32610
[Bug libgcj/28189] [4.1/4.2/4.3 Regression] Many libjava execution tests time out on Tru64 UNIX
--- Comment #2 from ro at gcc dot gnu dot org 2007-07-03 13:48 --- Fixed by fix for PR target/28307. -- ro at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28189
[Bug regression/32610] [4.2 4.3 regression] ICE in gen_tagged_type_instantiation_die, at dwarf2out.c:12762
--- Comment #1 from doko at ubuntu dot com 2007-07-03 13:48 --- Created an attachment (id=13835) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13835&action=view) source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32610
[Bug c++/32609] [4.2/4.3 Regression] ICE in htab_clear_slot at libiberty/hashtab.c:722
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-07-03 13:52 --- Or we just re-alloc the hashtab somewhere inbetween. Anyway, the following fixes the problem: Index: cp/class.c === --- cp/class.c (revision 126252) +++ cp/class.c (working copy) @@ -5376,7 +5376,7 @@ fixed_type_or_null (tree instance, int* *slot = instance; type = fixed_type_or_null (DECL_INITIAL (instance), nonnull, cdtorp); - htab_clear_slot (ht, slot); + htab_remove_elt (ht, instance); return type; } -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32609
[Bug c++/32609] [4.2/4.3 Regression] ICE in htab_clear_slot at libiberty/hashtab.c:722
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-07-03 13:55 --- I'm testing the fix. -- 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|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-03 13:55:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32609
[Bug tree-optimization/32377] can't determine dependence (source/destination overlap without more than size)
--- Comment #8 from sebpop at gmail dot com 2007-07-03 13:57 ---
Subject: Re: can't determine dependence (source/destination overlap without
more than size)
On 3 Jul 2007 12:57:33 -, irar at il dot ibm dot com
<[EMAIL PROTECTED]> wrote:
> for (i = 0; i < N; i++){
> ia[i+1] = ia[i] * 4;
> }
> the ddr is {ld, st} and distance 1
>
> and for
> for (i = 0; i < N; i++){
> ia[i] = ia[i+1] * 4;
> }
> the ddr is also {ld, st} with distance 1.
>
> How can we distinguish between these cases?
>
There is no way to distinguish between these two in the classical distance
vector representation, however I have seen that I only have that code in
the graphite branch:
DDR_REVERSED_P (ddr) = true;
I'm setting this in the block of code that is tested for not being lexico
positive vectors:
if (!lambda_vector_lexico_pos (dist_v, DDR_NB_LOOPS (ddr)))
I can submit a patch for merging that part of code in trunk if you need
this flag to test if you are in one or the other case. But again in the
classical distance representation this cannot be distinguished.
Sebastian
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32377
[Bug middle-end/32598] [4.3 regression]: 27_io/basic_stringbuf/setbuf/wchar_t/4.cc needs more than 6GB memory to compile
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-07-03 14:07 --- Created an attachment (id=13836) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13836&action=view) testcase (unreduced) -O -fno-tree-fre is fine, anything above is borked and eats (slowly) all mem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32598
[Bug fortran/32611] New: signed zero
a F2003 / QOI issue : REAL :: x,y character(len=16) :: s1,s2 x=-0.0 y= 0.0 IF (sign(1.0,x).NE.sign(1.0,y)) THEN write(s1,'(E16.8)') x write(s2,'(A16)') "-0.E+00" IF (s1.NE.s2) CALL ABORT() ENDIF END -- Summary: signed zero Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32611
[Bug middle-end/32598] [4.3 Regression]: 27_io/basic_stringbuf/setbuf/wchar_t/4.cc needs more than 6GB memory to compile
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-07-03 14:15 --- Fixed with r126252. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Summary|[4.3 regression]: |[4.3 Regression]: |27_io/basic_stringbuf/setbuf|27_io/basic_stringbuf/setbuf |/wchar_t/4.cc needs more|/wchar_t/4.cc needs more |than 6GB memory to compile |than 6GB memory to compile Target Milestone|--- |4.3.0 Version|unknown |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32598
[Bug tree-optimization/32604] [4.3 regression] miscompilation at -O2
--- Comment #5 from jakub at gcc dot gnu dot org 2007-07-03 14:18 --- The *.pre dump is clearly wrong: pretmp.53_53 = *order_p_25(D); : # prephitmp.45_125 = PHI ... D.1445_69 = pretmp.53_53; storetmp.41_92 = D.1445_69; *order_p_25(D) = D.1445_69; i_71 = i_2 + 1; if (i_2 == D.1401_27) goto ; else goto ; : goto ; i.e. *order_p won't ever change in the loop. Before *.pre it was changes correctly: ... : # i_2 = PHI <1(20), i_71(21)> D.1421_29 = *order_p_25(D); ... D.1439_48 = (*D.1423_32)[D.1438_47]; D.1440_49 = D.1421_29 + D.1439_48; D.1441_64 = D.1435_44 * 2; D.1442_65 = D.1441_64 + D.1437_46; D.1443_67 = D.1442_65 + D.1434_43; D.1444_68 = (*D.1423_32)[D.1443_67]; D.1445_69 = D.1440_49 - D.1444_68; *order_p_25(D) = D.1445_69; i_71 = i_2 + 1; if (i_2 == D.1401_27) goto ; else goto ; : goto ; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32604
[Bug c++/32609] [4.2/4.3 Regression] ICE in htab_clear_slot at libiberty/hashtab.c:722
--- Comment #6 from Ralf dot Wildenhues at gmx dot de 2007-07-03 14:23 --- This and 32595 are probably dupes (32595 is from a slightly patched cln). -- Ralf dot Wildenhues at gmx dot de changed: What|Removed |Added CC||Ralf dot Wildenhues at gmx ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32609
[Bug fortran/32612] New: gfortran - incorrectly flags error on interface module
gfortran now incorrectly flags and error on this reduced module - [dranta:~/tests/gfortran-D] dir% g95 -c files.f90 [dranta:~/tests/gfortran-D] dir% f90 -c files.f90 [dranta:~/tests/gfortran-D] dir% gfortran -c files.f90 files.f90:30.40: subroutine my_sio_file_read_common(data_lengths, error, & 1 files.f90:8.39: interface my_sio_file_read_common 2 Error: Name 'my_sio_file_read_common' at (1) is already defined as a generic interface at (2) [dranta:~/tests/gfortran-D] dir% cat files.f90 module files_module implicit none integer, parameter :: REAL8 = SELECTED_REAL_KIND(12) save private interface my_sio_file_read_common module procedure my_sio_file_read_common end interface contains subroutine my_sio_file_read_all_i4(serial, data, data_lengths, error) ! - purpose ! - calling arguments logical, intent(in) :: serial integer, intent(out) :: data(*) integer, intent(in) :: data_lengths(0:*) integer, intent(out) :: error call my_sio_file_read_common(data_lengths, error, data_i4 = data) end subroutine my_sio_file_read_all_i4 subroutine my_sio_file_read_common(data_lengths, error, & data_i4, & data_r8) integer, intent(in) :: data_lengths(0:*) integer, intent(out) :: error integer, intent(out), optional :: data_i4(*) real(REAL8), intent(out), optional :: data_r8(*) error=0 data_i4(1)=0 data_r8(1)=0 end subroutine my_sio_file_read_common end module files_module [dranta:~/tests/gfortran-D] dir% gfortran --v Using built-in specs. Target: powerpc-apple-darwin8.10.0 Configured with: ../gcc/configure --disable-multilib --prefix=/usr/local/gfortran --enable-languages=c,fortran Thread model: posix gcc version 4.3.0 20070702 (experimental) [dranta:~/tests/gfortran-D] dir% -- Summary: gfortran - incorrectly flags error on interface module Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dir at lanl dot gov GCC host triplet: Darwin 8.9.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32612
[Bug c++/32595] abort in libiberty:htab_clear_slot
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-07-03 14:30 --- *** This bug has been marked as a duplicate of 32609 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32595
[Bug c++/32609] [4.2/4.3 Regression] ICE in htab_clear_slot at libiberty/hashtab.c:722
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-07-03 14:30 --- *** Bug 32595 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32609
[Bug rtl-optimization/30113] ICE in trunc_int_for_mode
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-07-03 14:33 --- Subject: Bug 30113 Author: rguenth Date: Tue Jul 3 14:33:16 2007 New Revision: 126259 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126259 Log: 2007-07-03 Richard Guenther <[EMAIL PROTECTED]> Backport from mainline: 2006-12-11 Zdenek Dvorak <[EMAIL PROTECTED]> PR rtl-optimization/30113 * loop-iv.c (implies_p): Require the mode of the operands to be scalar. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/loop-iv.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30113
[Bug rtl-optimization/30113] [4.1 Regression] ICE in trunc_int_for_mode
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-07-03 14:35 --- This is a regression from 4.0.4. Fixed on the 4.2 branch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work|4.3.0 |4.3.0 4.2.1 4.0.4 Summary|ICE in trunc_int_for_mode |[4.1 Regression] ICE in ||trunc_int_for_mode Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30113
[Bug libstdc++/32608] operator >> loads wrong value after istringsstream::str( string ).
--- Comment #2 from pcarlini at suse dot de 2007-07-03 14:43 --- You want, e.g., an is.clear() after the first extraction, which leaves the is stream on eof state. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32608
[Bug debug/32610] [4.2/4.3 regression] ICE in gen_tagged_type_instantiation_die, at dwarf2out.c:12762
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|regression |debug Keywords||ice-on-valid-code Summary|[4.2 4.3 regression] ICE in |[4.2/4.3 regression] ICE in |gen_tagged_type_instantiatio|gen_tagged_type_instantiatio |n_die, at dwarf2out.c:12762 |n_die, at dwarf2out.c:12762 Target Milestone|--- |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32610
[Bug fortran/32613] New: Different results depending on unnecessary variable declaration
program main
call something
end
subroutine something
! integer i !correct results from gfortran depend on this statement
character lit*1,line*100
lit(i)=line(i:i)
i=1; n=5; line='PZ0R1'
if (internal(4)) stop
write(*,*) i
contains
logical function internal(j)
intent(in) j
do i=j,n
k=index('RE',lit(i)); if (k==0) cycle
if (i+1==n) exit
enddo
internal=k==0
end function
end
--
Summary: Different results depending on unnecessary variable
declaration
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: awgreynolds at earthlink dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32613
[Bug tree-optimization/32604] [4.3 regression] miscompilation at -O2
--- Comment #6 from dberlin at gcc dot gnu dot org 2007-07-03 15:02 --- Subject: Re: [4.3 regression] miscompilation at -O2 > D.1445_69 = pretmp.53_53; > storetmp.41_92 = D.1445_69; > *order_p_25(D) = D.1445_69; > i_71 = i_2 + 1; > if (i_2 == D.1401_27) > goto ; > else > goto ; > > : > goto ; > > i.e. *order_p won't ever change in the loop. Actually, what it has really done is prove the load and store that happens have the same value. It happens to also decide that this value (D.1445_69) is invariant. This is the broken part, and it is because of antic_safe_loads not checking whether the operands of the load change. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32604
[Bug c++/32609] [4.2/4.3 Regression] ICE in htab_clear_slot at libiberty/hashtab.c:722
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-07-03 15:27 --- Subject: Bug 32609 Author: rguenth Date: Tue Jul 3 15:26:59 2007 New Revision: 126261 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126261 Log: 2007-07-03 Richard Guenther <[EMAIL PROTECTED]> PR c++/32609 * class.c (fixed_type_or_null): Re-lookup the hashtable slot after recursing. Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/class.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32609
[Bug c++/32609] [4.2/4.3 Regression] ICE in htab_clear_slot at libiberty/hashtab.c:722
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-07-03 15:29 --- Subject: Bug 32609 Author: rguenth Date: Tue Jul 3 15:29:19 2007 New Revision: 126262 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126262 Log: 2007-07-03 Richard Guenther <[EMAIL PROTECTED]> PR c++/32609 * class.c (fixed_type_or_null): Re-lookup the hashtable slot after recursing. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32609
[Bug c++/32609] [4.2/4.3 Regression] ICE in htab_clear_slot at libiberty/hashtab.c:722
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-07-03 15:29 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.2.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32609
[Bug fortran/32613] [4.2 regression] Different results depending on unnecessary variable declaration
--- Comment #1 from kargl at gcc dot gnu dot org 2007-07-03 16:24 --- This a regression with respect to 4.2. The problem is caused by the implicitly typed 'i' in the statement function 'lit(i) = line(i:i)' -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-03 16:24:15 date|| Summary|Different results depending |[4.2 regression] Different |on unnecessary variable |results depending on |declaration |unnecessary variable ||declaration http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32613
[Bug other/31349] [4.3 Regression] gcc -v --help returns no options for C, C++
--- Comment #4 from nickc at redhat dot com 2007-07-03 16:26 --- Hi Brooks, I do not think that this is a bug, but rather a feature. The command line options are all still in the "--help -v" otuput, they are just in different locations. For example the -Wall option is now listed in the 'language related options' list rather than the Fortran list, because it is supported by more than one language front end. (Note: you need to have specified -Wextra on the gcc command line before --help in order to see the -Wall option being listed. This is because the -Wall has no description associated with it). As far as I can tell there are no missing options in the help output, it is just that their location in the output has changed, with all the options shared by more than one language front end being listed together in one lump, rather than being listed multiple times, once per supported language. Cheers Nick -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31349
[Bug tree-optimization/32377] can't determine dependence (source/destination overlap without more than size)
--- Comment #9 from irar at il dot ibm dot com 2007-07-03 16:43 --- (In reply to comment #8) > I can submit a patch for merging that part of code in trunk if you need > this flag to test if you are in one or the other case. I guess we can't vectorize the loop in this PR without it, since we have to distinguish between the cases in comment #7 (the first loop should not be vectorized and the second one should). Thanks, Ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32377
[Bug target/32462] [4.3 regression] Linking libgcj.so fails on Solaris 10/x86
--- Comment #3 from ro at gcc dot gnu dot org 2007-07-03 17:55 --- Created an attachment (id=13837) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13837&action=view) process-Posix.s built with gcj 4.2.1 20070611 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32462
[Bug target/32462] [4.3 regression] Linking libgcj.so fails on Solaris 10/x86
--- Comment #4 from ro at gcc dot gnu dot org 2007-07-03 17:56 --- Created an attachment (id=13838) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13838&action=view) process-Posix.s built with gcj 4.3.0 20070618 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32462
[Bug target/32462] [4.3 regression] Linking libgcj.so fails on Solaris 10/x86
--- Comment #5 from ro at techfak dot uni-bielefeld dot de 2007-07-03 17:57 --- Subject: Re: [4.3 regression] Linking libgcj.so fails on Solaris 10/x86 I compared the assembler files corresponding to java/.libs/process-Posix.o and built with both gcj 4.2.1 20070611 and 4.3.0 20070618 and compared the results: the primary differences are like this: @@ -1886,9 +2012,8 @@ movl%eax, %esi movl%eax, (%esp) call[EMAIL PROTECTED] - movl[EMAIL PROTECTED](%ebx), %eax - movl%esi, (%eax) -.LBE57: + movl%esi, [EMAIL PROTECTED](%ebx) +.LBE60: movl4(%esp), %ebx movl8(%esp), %esi addl$12, %esp I've uploaded both files for further inspection. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32462
[Bug c++/32614] New: -fmessage-length documentation and implementation disagree
doc/invoke.texi says:
Try to format error messages so that they fit on lines of about @var{n}
characters. The default is 72 characters for @command{g++} and 0 for the rest
of
the front ends supported by [EMAIL PROTECTED]
However, cp/cxx-pretty-print.c seems to set the default to 0:
pp_set_line_maximum_length (pp, 0);
See this thread:
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01948.html
There is some disagreement as to whether this is a documentation bug
or a code bug.
--
Summary: -fmessage-length documentation and implementation
disagree
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tromey at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32614
[Bug c++/31993] [4.3 regression] ICE with template class in variadic template class
-- dgregor at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dgregor at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-05-22 23:18:30 |2007-07-03 18:06:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31993
[Bug fortran/20888] dereferencing NULL still accepted
--- Comment #4 from burnus at gcc dot gnu dot org 2007-07-03 18:07 --- FIXED for 4.3/trunk. Not a regression -> no backporting to 4.2.x. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20888
[Bug tree-optimization/14741] missing transformations lead to poorly optimized code
--- Comment #15 from jv244 at cam dot ac dot uk 2007-07-03 18:09 --- current gfortran trunk is still about a factor of 8 slower than ifort: > gfortran -O3 -ffast-math -ftree-vectorize -march=native test.f90 > ./a.out 12.98081100010.23998 > ifort -xT -O2 test.f90 > ./a.out 1.62810210.23998 (first number is the time) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741
[Bug libgcj/32465] Linking 64-bit libgcj.so fails on Solaris 10/x86: non-PIC code despite -fPIC
--- Comment #4 from ro at gcc dot gnu dot org 2007-07-03 18:10 --- Created an attachment (id=13839) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13839&action=view) runtime.s built with gcj 4.2.1 20070611 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32465
[Bug libgcj/32465] Linking 64-bit libgcj.so fails on Solaris 10/x86: non-PIC code despite -fPIC
--- Comment #5 from ro at gcc dot gnu dot org 2007-07-03 18:11 --- Created an attachment (id=13840) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13840&action=view) runtime.s built with gcj 4.3.0 20070618 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32465
[Bug libgcj/32465] [4.3 Regression] Linking 64-bit libgcj.so fails on Solaris 10/x86: non-PIC code despite -fPIC
--- Comment #6 from ro at gcc dot gnu dot org 2007-07-03 18:11 --- This is a regression from 4.2.1. I'm uploading the assembler files corresponding to gnu/gcj/.libs/runtime.o and built with gcj 4.2.1 20070611 and 4.3.0 20070618 for comparison. -- ro at gcc dot gnu dot org changed: What|Removed |Added Summary|Linking 64-bit libgcj.so|[4.3 Regression] Linking 64- |fails on Solaris 10/x86:|bit libgcj.so fails on |non-PIC code despite -fPIC |Solaris 10/x86: non-PIC code ||despite -fPIC http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32465
[Bug rtl-optimization/17088] poor fortran optimisation at -O2/3
--- Comment #13 from jv244 at cam dot ac dot uk 2007-07-03 18:15 --- looks like current mainline is much slower than ifort (300%) on this testcase (on core2). > ifort -xT -O2 test.f90 > ./a.out 0.000E+000 0.2280140 0.2280140 > gfortran -O3 -ffast-math -ftree-vectorize -march=native test.f90 > ./a.out 0.00 0.6840420 0.2800180 0.5840420 vs 0.2280140 seconds -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17088
[Bug tree-optimization/31040] unroll/peel loops not aggressive enough
--- Comment #5 from jv244 at cam dot ac dot uk 2007-07-03 18:21 --- The optimization asked for in this PR is now being performed: > gfortran -O3 -funroll-loops -S test.f90 yields globl lxy_ .type lxy_, @function lxy_: .LFB2: movl$3, %eax ret .LFE2: .size lxy_, .-lxy_ .section.eh_frame,"a",@progbits .Lframe1: -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31040
[Bug fortran/30871] Pointer to substring rejected with "Different character lengths in pointer assignment"
--- Comment #3 from jv244 at cam dot ac dot uk 2007-07-03 18:23 --- this has become an ICE in the meanwhile test.f90:6: internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:4492 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30871
[Bug fortran/31198] wrong code: Max() with optional arguments
--- Comment #5 from jv244 at cam dot ac dot uk 2007-07-03 18:26 --- patch ping ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31198
[Bug fortran/25057] default initialization and DATA statement conflict
--- Comment #7 from jv244 at cam dot ac dot uk 2007-07-03 18:27 --- this has become: Error: 'd' at (1) already is initialized at (2) test.f90:0: internal compiler error: Segmentation fault Please submit a full bug report, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25057
[Bug c/32615] New: Source file with extern inline function fails to link with -O0
Output of the gcc command:
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/u
sr/share/info --enable-shared --enable-threads=posix --enable-checking=release
-
-with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-
languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-ds
si --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--en
able-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/ja
va/eclipse-ecj.jar --with-cpu=generic --host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.2 20070502 (Red Hat 4.1.2-12)
/usr/libexec/gcc/x86_64-redhat-linux/4.1.2/cc1 -E -quiet -v tt.c
-mtune=generic
-O0 -fpch-preprocess -o tt.i
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../
../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/include
/usr/include
End of search list.
/usr/libexec/gcc/x86_64-redhat-linux/4.1.2/cc1 -fpreprocessed tt.i -quiet
-dump
base tt.c -mtune=generic -auxbase tt -O0 -version -o tt.s
GNU C version 4.1.2 20070502 (Red Hat 4.1.2-12) (x86_64-redhat-linux)
compiled by GNU C version 4.1.2 20070502 (Red Hat 4.1.2-12).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: cdc0c9646615f6ebf987f895cd040dc2
as -V -Qy -o tt.o tt.s
GNU assembler version 2.17.50.0.16 (x86_64-redhat-linux) using BFD version
versi
on 2.17.50.0.16-1 20070511
/usr/libexec/gcc/x86_64-redhat-linux/4.1.2/collect2 --eh-frame-hdr -m
elf_x86_6
4 --hash-style=gnu -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o tt
/usr/lib/gc
c/x86_64-redhat-linux/4.1.2/../../../../lib64/crt1.o
/usr/lib/gcc/x86_64-redhat-
linux/4.1.2/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/crtb
egin.o -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2
-L/usr/lib/gcc/x86_64-redhat-lin
ux/4.1.2 -L/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64
-L/lib/../li
b64 -L/usr/lib/../lib64 tt.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc
--as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/crtend
.o /usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crtn.o
tt.o: In function `first':
tt.c:(.text+0x22): undefined reference to `second'
collect2: ld returned 1 exit status
Preprocessed source file (tt.i):
# 1 "tt.c"
# 1 ""
# 1 ""
# 1 "tt.c"
void crash(){
int* a = 0;
a[0] = 0;
}
extern inline void second(){
crash();
}
void first(){
second();
}
int main(){
first();
return 0;
}
Notes:
This compiles and links fine with -O (and any higher degree of
optimization) instead of -O0. The problem is also present in GCC 4.1.1.
--
Summary: Source file with extern inline function fails to link
with -O0
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kris dot van dot hees at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32615
[Bug fortran/25104] [F2003] Non-initialization expr. as case-selector
--- Comment #8 from jv244 at cam dot ac dot uk 2007-07-03 18:29 --- change the keyword, as the error is now generated for std=f95 but the code is rejected for std=f2003 -- jv244 at cam dot ac dot uk changed: What|Removed |Added Keywords|ice-on-invalid-code |rejects-valid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25104
[Bug fortran/31198] wrong code: Max() with optional arguments
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-07-03 18:30 --- (In reply to comment #5) > patch ping ? I was initially waiting for Lee's patch to be committed, if I have no news from him I'll modify the patch and submit it again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31198
[Bug fortran/31197] [4.2/4.3 regression] TRANSPOSE/RESHAPE and strings
--- Comment #13 from jv244 at cam dot ac dot uk 2007-07-03 18:33 --- (In reply to comment #12) > I have a fix that I will submit tonight or tomorrow morning. It also fixes > PR31258 and PR31897. > > Paul > is this still correct ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31197
[Bug c/32615] Source file with extern inline function fails to link with -O0
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-03 18:33 --- extern inline is not what you think it is. The "extern inline" GNU C90 implementes (except for 4.3 with -std=c99/-std=gnu99 which is the standard C99 extern inline) means the function is extern but don't create a definition if the function was not inlined. This is different from C99's extern inline. -- 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=32615
[Bug fortran/31197] [4.2/4.3 regression] TRANSPOSE/RESHAPE and strings
--- Comment #14 from tobi at gcc dot gnu dot org 2007-07-03 18:36 --- (In reply to comment #13) > (In reply to comment #12) > > I have a fix that I will submit tonight or tomorrow morning. It also fixes > > PR31258 and PR31897. > > > > Paul > > > is this still correct ? Adding Paul, so he can see this question and hopefully answer affirmatively. -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||pault at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31197
[Bug c/32615] Source file with extern inline function fails to link with -O0
--- Comment #2 from kris dot van dot hees at oracle dot com 2007-07-03 18:40 --- Thanks for the explanation - that does explain why -O0 causes an error (since there is no inlining being done as far as I understand), whereas any other optimization setting results in success due to inlining of the function (avoiding the error that way). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32615
[Bug fortran/30940] Fortran 2003: Scalar CHARACTER supplied to array dummy
--- Comment #6 from burnus at gcc dot gnu dot org 2007-07-03 19:16 --- Subject: Bug 30940 Author: burnus Date: Tue Jul 3 19:16:42 2007 New Revision: 126271 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126271 Log: 2007-07-03 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/30940 * interface.c (get_sym_storage_size): New function. (get_sym_storage_size): New function. (compare_actual_formal): Enhance sequence association support and improve checking. 2007-07-03 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/30940 * gfortran.dg/argument_checking_1.f90: New. * gfortran.dg/argument_checking_2.f90: New. * gfortran.dg/argument_checking_3.f90: New. * gfortran.dg/argument_checking_4.f90: New. * gfortran.dg/argument_checking_5.f90: New. * gfortran.fortran-torture/execute/st_function_1.f90: Add dg-warning. * gfortran.fortran-torture/execute/st_function.f90: Add dg-warning. Added: trunk/gcc/testsuite/gfortran.dg/argument_checking_1.f90 trunk/gcc/testsuite/gfortran.dg/argument_checking_2.f90 trunk/gcc/testsuite/gfortran.dg/argument_checking_3.f90 trunk/gcc/testsuite/gfortran.dg/argument_checking_4.f90 trunk/gcc/testsuite/gfortran.dg/argument_checking_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/char_length_3.f90 trunk/gcc/testsuite/gfortran.fortran-torture/execute/st_function.f90 trunk/gcc/testsuite/gfortran.fortran-torture/execute/st_function_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30940
[Bug tree-optimization/25621] Missed optimization when unrolling the loop (splitting up the sum) (only with -ffast-math)
--- Comment #4 from jv244 at cam dot ac dot uk 2007-07-03 19:30 --- Now, I get the same timings for the hand-optimised loop and compiled loop if I use the option: gfortran -O3 -ffast-math -ftree-vectorize -march=native -funroll-loops -fvariable-expansion-in-unroller test.f90 whereas -funroll-loops is quite common to add, -fvariable-expansion-in-unroller is not. Could one have a heuristic that switches that on by default if -funroll-loops (and -ffast-math) ? For S31 the timings are: > gfortran -O3 -ffast-math -ftree-vectorize -march=native -funroll-loops > test.f90 > time ./a.out real0m6.618s > gfortran -O3 -ffast-math -ftree-vectorize -march=native -funroll-loops > -fvariable-expansion-in-unroller test.f90 > time ./a.out real0m4.457s so a 50% improvement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25621
[Bug rtl-optimization/32475] [4.3 Regression] function with asm() does not setup stack frame
--- Comment #23 from spark at gcc dot gnu dot org 2007-07-03 19:41 --- This patch: diff -r 29a7055e69fc gcc/df-scan.c --- a/gcc/df-scan.c Sun Jun 24 00:16:55 2007 + +++ b/gcc/df-scan.c Tue Jul 03 12:38:41 2007 -0700 @@ -2763,6 +2763,12 @@ df_def_record_1 (struct df_collection_re || (GET_CODE (dst) == SUBREG && REG_P (SUBREG_REG (dst df_ref_record (collection_rec, dst, loc, bb, insn, DF_REF_REG_DEF, flags); + + /* We want to keep sp alive everywhere - by making all + writes to sp also use of sp. */ + if (REG_P (dst) && REGNO (dst) == STACK_POINTER_REGNUM) +df_ref_record (collection_rec, + dst, NULL, bb, insn, DF_REF_REG_USE, flags); } also fixes the problem, by treating all defs of SP as a use of SP. This patch essentially makes SP alive everywhere. Also, this would create less number of unnecessary df_ref's (since presumably there are less number of stack defs than MEM_LOAD/STORE w/ hard frame pointer reference). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32475
[Bug other/31349] [4.3 Regression] gcc -v --help returns no options for C, C++
--- Comment #5 from brooks at gcc dot gnu dot org 2007-07-03 19:45 --- Nick - So, if I understand correctly: all of the options are listed somewhere, but we no longer provide any information about which of the shared options under "language related options" are supported by a given language's front end? While this may have been intentional, I do not think it counts as a feature -- the listing of the "common" options without definitions at the top of the option listing did not take up a significant amount of space, and it provided very useful information that's now not absent. (On the other hand, moving the _descriptions_ of the shared options to a single listing is a good thing, IMO -- I want to make it clear that I'm not objecting to the bulk of this change!) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31349
[Bug other/31349] [4.3 Regression] gcc -v --help returns no options for C, C++
--- Comment #6 from brooks at gcc dot gnu dot org 2007-07-03 19:46 --- Er, "that's now absent", I mean. An extraneous "not" crept into the second paragraph of my last comment when I was editing it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31349
