[Bug tree-optimization/23386] [4.1 Regression] bitmap.c is being miscompiled (VRP)
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-15 07:51 --- Subject: Bug 23386 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-15 07:51:42 Modified files: gcc: ChangeLog tree-data-ref.c Added files: gcc/testsuite/gcc.dg/tree-ssa: pr23386.c Log message: PR 23386 * tree-data-ref.c (estimate_niter_from_size_of_data): When step is negative compute the estimation from init downwards to zero. * testsuite/gcc.dg/tree-ssa/pr23386.c: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9731&r2=2.9732 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-data-ref.c.diff?cvsroot=gcc&r1=2.37&r2=2.38 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr23386.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23386
[Bug fortran/23394] New: Segmentation fault in RESHAPE
! Linux build (gfortran-linux.tar.gz) !- !! $ gfc --version !! GNU Fortran 95 (GCC 4.1.0 20050815 (experimental)) !! Copyright (C) 2005 Free Software Foundation, Inc. ! Native Windows build [gfortran-windows.exe] !- !! > gfortran --version !! GNU Fortran 95 (GCC 4.1.0 20050805 (experimental)) !! Copyright (C) 2005 Free Software Foundation, Inc. ! Cygwin build [gfortran-Cygwin-4.1-20050523-Athlon.tar.bz2] !- !! $ gfc --version !! GNU Fortran 95 (GCC 4.1.0 20050522 (experimental)) !! Copyright (C) 2005 Free Software Foundation, Inc. ! In all cases: !--- !! $ gfc -c gfc_seg_bug.f90 !! gfc_seg_bug.f90:0: internal compiler error: Segmentation fault !! Please submit a full bug report, !! with preprocessed source if appropriate. !! See http://gcc.gnu.org/bugs.html> for instructions. PROGRAM gfc_seg_bug CHARACTER (LEN=2), PARAMETER :: aray(4,2) = RESHAPE( & (/ "11", "12", "13", "14",& "21", "22", "23", "24" /), & SHAPE=(/4,2/) ) END PROGRAM gfc_seg_bug -- Summary: Segmentation fault in RESHAPE Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: critical Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dave dot offiler at metoffice dot gov dot uk CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23394
[Bug c++/23395] New: nested template class member func rejects default args
- I've declared a class/struct with a nested template class in it's inner - nested template class has a member function with a default argument - outer class uses this template type as member variables - outer class accesses in it's interface member functions the template members by it's member function with the default arguments -- Summary: nested template class member func rejects default args Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: backboon at gmx dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: v4.0.0, i686-apple-darwin8, build 5026 GCC host triplet: v4.0.0, i686-apple-darwin8, build 5026 GCC target triplet: v4.0.0, i686-apple-darwin8, build 5026 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23395
[Bug c++/23395] nested template class member func rejects default args
--- Additional Comments From backboon at gmx dot de 2005-08-15 08:51 --- Created an attachment (id=9495) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9495&action=view) g++ stderr/stdout output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23395
[Bug c++/23395] nested template class member func rejects default args
--- Additional Comments From backboon at gmx dot de 2005-08-15 08:53 --- Created an attachment (id=9496) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9496&action=view) source code, where bug occures -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23395
[Bug target/23355] size optimizer did not eliminateing useless Push and pop instructions at ARM/Thumb machine
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-08-15 09:33 --- Confirmed. thumb_compute_save_reg_mask() should use similar logic to arm_compute_save_reg0_reg12_mask() so that the pic register is only saved when required. BTW. Next time can you add files to the attachments panel in bugzilla, rather than pasting them in. -- What|Removed |Added CC||rearnsha at gcc dot gnu dot ||org Status|WAITING |NEW Ever Confirmed||1 Keywords||missed-optimization Priority|P2 |P3 Last reconfirmed|-00-00 00:00:00 |2005-08-15 09:33:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23355
[Bug bootstrap/12527] [3.3/3.4 regression] [arm] bootstrap error on arm-linux, miscompiling genconstants
--- Additional Comments From rearnsha at gcc dot gnu dot org 2005-08-15 09:37 --- (In reply to comment #23) > doko's patch triggers PR23256. gcc 3.3.3 on armeb appears to miscompile > itself > when SUBTARGET_CPU_DEFAULT is TARGET_CPU_arm6, but with TARGET_CPU_arm7tdmi it > all works fine. I think this is more likely to be PR 22528. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12527
[Bug libobjc/23108] alignment bug in libobjc/archive.c
--- Additional Comments From rassahah at neofonie dot de 2005-08-15 10:41
---
(In reply to comment #3)
> Hmm on powerpc-darwin we get:
> a = 1, b = 3
>
>
> Which is still wrong.
You mean before or after the application of the suggested patch? Perhaps there
may be other alignment
constraints on powerpc-darwin than on i686-linux. The alignment with the
ROUND-macro as i see it
would not work with an alignment constraint any other than `alignment ==
multiple of data size'.
BTW: The bug is at least in gcc-2.7.2.3. I am wondering how it got along
undetected, since the program
with the encoding "{ii}" is an example taken from `Object Oriented Programming
& the Objective-C
Programming Language'. But however as i checked the various libs that are open
source and compilable
under linux (libFoundation etc.), nobody uses it. They all handle their
serialization of compound object
by themselves...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23108
Re: I have a bad day, output is not the same, in pointer to unsigned long long int bits field.
On Aug 14, 2005, at 1:57 PM, Fran wrote: u = (unsigned long long int *) &ull; You are violating C aliasing rules. Either use an union or -fno-strict-aliasing. -- Pinski
[Bug tree-optimization/23396] New: [4.1 Regression] profiledbootstrap is broken (again)
A different error this time: ./xgcc -B./ -B/Users/pinskia/local3/powerpc-apple-darwin7.9.0/bin/ -isystem /Users/pinskia/local3/ powerpc-apple-darwin7.9.0/include -isystem /Users/pinskia/local3/powerpc-apple-darwin7.9.0/sys- include -L/Users/pinskia/src/local3/gcc/objdir/gcc/../ld -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite- strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I/Users/pinskia/src/local3/gcc/gcc -I/Users/pinskia/src/local3/gcc/gcc/. -I/Users/pinskia/src/ local3/gcc/gcc/../include -I./../intl -I/Users/pinskia/src/local3/gcc/gcc/../libcpp/include \ -c /Users/pinskia/src/local3/gcc/gcc/config/darwin-crt2.c -o crt2.o *** malloc[25823]: Deallocation of a pointer not malloced: 0x42d0b230; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug [address=4e139d10 pc=0096dabc] /Users/pinskia/src/local3/gcc/gcc/config/darwin-crt2.c: In function 'darwin_unwind_dyld_remove_image_hook': /Users/pinskia/src/local3/gcc/gcc/config/darwin-crt2.c:110: internal compiler error: Segmentation Fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[2]: *** [crt2.o] Error 1 make[1]: *** [stageprofile_build] Error 2 make: *** [profiledbootstrap] Error 2 gcc_build: error: Could not bootstrap the compiler -- Summary: [4.1 Regression] profiledbootstrap is broken (again) Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: wrong-code, ice-on-valid-code, build Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc-apple-darwin7.9.0 GCC host triplet: powerpc-apple-darwin7.9.0 GCC target triplet: powerpc-apple-darwin7.9.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23396
[Bug tree-optimization/23396] [4.1 Regression] profiledbootstrap is broken (again)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15 11:52 --- The ICE backtrace: #0 coalesce_tpa_members (tpa=0x42b13ed0, graph=0x42b13f30, map=0x42b0e750, cl=0x42b0e7c0, debug=0x0) at /Users/pinskia/src/local3/gcc/gcc/tree-ssa-live.h:408 #1 0x0082a184 in remove_ssa_form (dump=0x34, map=0x0, flags=0) at /Users/pinskia/src/local3/ gcc/gcc/tree-outof-ssa.c:918 #2 0x0082a184 in remove_ssa_form (dump=0x34, map=0x42b0e750, flags=1) at /Users/pinskia/ src/local3/gcc/gcc/tree-outof-ssa.c:918 #3 0x0082f198 in rewrite_out_of_ssa () at /Users/pinskia/src/local3/gcc/gcc/tree-outof-ssa.c:2593 #4 0x0037bb08 in execute_one_pass (pass=0x42b0e750) at /Users/pinskia/src/local3/gcc/gcc/ passes.c:797 I will get where the malloc error is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23396
[Bug tree-optimization/23396] [4.1 Regression] profiledbootstrap is broken (again)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15 11:53 --- Malloc error: #0 0x9009fb58 in abort () #1 0x0096d810 in coalesce_tpa_members (tpa=0x42b13ed0, graph=0xcf3d60, map=0x42b0e750, cl=0x42b0e7c0, debug=0x0) at /Users/pinskia/src/local3/gcc/gcc/tree-ssa-live.c:1284 #2 0x0096d810 in coalesce_tpa_members (tpa=0x42b13ed0, graph=0x42b13f30, map=0x42b0e750, cl=0x42b0e7c0, debug=0x0) at /Users/pinskia/src/local3/gcc/gcc/tree-ssa-live.c:1284 #3 0x0082a184 in remove_ssa_form (dump=0x0, map=0x42b0e750, flags=1) at /Users/pinskia/src/ local3/gcc/gcc/tree-outof-ssa.c:918 #4 0x0082f198 in rewrite_out_of_ssa () at /Users/pinskia/src/local3/gcc/gcc/tree-outof-ssa.c:2593 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23396
[Bug tree-optimization/23396] [4.1 Regression] profiledbootstrap is broken (again)
-- What|Removed |Added Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23396
[Bug tree-optimization/23396] [4.1 Regression] profiledbootstrap is broken (again)
-- What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23396
[Bug tree-optimization/23396] [4.1 Regression] profiledbootstrap is broken (again)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15 11:55 --- profiledbootstrap is last known to work for "gcc version 4.1.0 20050808 (experimental)". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23396
[Bug c++/23395] nested template class member func rejects default args
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15 11:59 --- This is a dup of bug 21903. Fixed already in 4.0.2. You should have reported this to Apple first as it is a bug in Apple's gcc and not the FSF. *** This bug has been marked as a duplicate of 21903 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23395
[Bug c++/21903] [4.0 regression] Default argument of template function causes a compile-time error
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15 12:00 --- *** Bug 23395 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||backboon at gmx dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21903
[Bug fortran/23394] [4.1 Regression] Segmentation fault in RESHAPE
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15 12:04 --- This is a dup of bug 21825. *** This bug has been marked as a duplicate of 21825 *** -- What|Removed |Added Severity|critical|normal Status|UNCONFIRMED |RESOLVED Keywords||ice-on-valid-code Known to fail||4.1.0 Known to work||4.0.0 Resolution||DUPLICATE Summary|Segmentation fault in |[4.1 Regression] |RESHAPE |Segmentation fault in ||RESHAPE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23394
[Bug fortran/21825] 2D array initialization with reshape
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15 12:04 --- *** Bug 23394 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||dave dot offiler at ||metoffice dot gov dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21825
[Bug fortran/21825] [4.1 Regression] 2D array initialization with reshape
-- What|Removed |Added Keywords||ice-on-valid-code Known to fail||4.1.0 Known to work||4.0.0 Summary|2D array initialization with|[4.1 Regression] 2D array |reshape |initialization with reshape Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21825
[Bug libobjc/23108] alignment bug in libobjc/archive.c
--- Additional Comments From pinskia at physics dot uc dot edu 2005-08-15
12:09 ---
Subject: Re: alignment bug in libobjc/archive.c
>
>
> --- Additional Comments From rassahah at neofonie dot de 2005-08-15
> 10:41 ---
> (In reply to comment #3)
> > Hmm on powerpc-darwin we get:
> > a = 1, b = 3
> >
> >
> > Which is still wrong.
> You mean before or after the application of the suggested patch? Perhaps
> there may be other alignment
> constraints on powerpc-darwin than on i686-linux. The alignment with the
> ROUND-macro as i see it
> would not work with an alignment constraint any other than `alignment ==
> multiple of data size'.
> BTW: The bug is at least in gcc-2.7.2.3. I am wondering how it got along
> undetected, since the program
> with the encoding "{ii}" is an example taken from `Object Oriented
> Programming & the Objective-C
> Programming Language'. But however as i checked the various libs that are
> open source and compilable
> under linux (libFoundation etc.), nobody uses it. They all handle their
> serialization of compound object
> by themselves...
This was before, sorry I did not make that clear. I do almost all my testing
on powerpc-darwin.
-- Pinski
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23108
[Bug fortran/21825] [4.0/4.1 Regression] 2D array initialization with reshape
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15 12:13 --- This is a regression from 4.0.0. -- What|Removed |Added Known to fail|4.1.0 |4.1.0 4.0.2 Summary|[4.1 Regression] 2D array |[4.0/4.1 Regression] 2D |initialization with reshape |array initialization with ||reshape Target Milestone|4.1.0 |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21825
[Bug tree-optimization/23386] [4.1 Regression] bitmap.c is being miscompiled (VRP)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15 12:26 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23386
[Bug tree-optimization/23391] [4.1 regression] Tree checking failure due to scev
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-15 12:26 --- Subject: Bug 23391 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-15 12:26:13 Modified files: gcc: ChangeLog Makefile.in tree-chrec.c tree-scalar-evolution.c Added files: gcc/testsuite/gcc.dg/tree-ssa: pr23391.c Log message: PR 23391 * Makefile.in (tree-chrec.o): Depends on real.h. * tree-chrec.c: Include real.h. (chrec_fold_plus_poly_poly, chrec_fold_multiply_poly_poly, chrec_fold_plus_1): Use build_real for SCALAR_FLOAT_TYPE_P. * tree-scalar-evolution.c (add_to_evolution_1, interpret_rhs_modify_expr): Ditto. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9732&r2=2.9733 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/Makefile.in.diff?cvsroot=gcc&r1=1.1535&r2=1.1536 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-chrec.c.diff?cvsroot=gcc&r1=2.23&r2=2.24 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-scalar-evolution.c.diff?cvsroot=gcc&r1=2.35&r2=2.36 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr23391.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23391
[Bug tree-optimization/23391] [4.1 regression] Tree checking failure due to scev
--- Additional Comments From sebastian dot pop at cri dot ensmp dot fr 2005-08-15 12:33 --- Subject: Re: [4.1 regression] Tree checking failure due to scev pinskia at gcc dot gnu dot org wrote: > This is related to PR 19899 which was fixed. > Yes, PR is related to PR19899, but same pattern occured in several places and the fix to PR19899 was not complete. Fixed now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23391
[Bug tree-optimization/23391] [4.1 regression] Tree checking failure due to scev
--- Additional Comments From sebastian dot pop at cri dot ensmp dot fr 2005-08-15 12:35 --- Subject: Re: [4.1 regression] Tree checking failure due to scev Sebastian Pop wrote: > > Yes, PR is related to PR19899, but same pattern occured in several > places and the fix to PR19899 was not complete. Fixed now. > We'll probably need this fix for 4.0 branch as well... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23391
[Bug c/23397] New: Compilation Ghostscript gs_init.c file failed on mipsel-linux machine
gcc -DHAVE_MKSTEMP -DHAVE_HYPOT -Os -mips32 -mtune=4kc -I/mnt/disc/include -I./src -I./obj -I./obj -I./src -o ./obj/gs_init.o -c ./obj/gs_init.c gcc: Internal error: Terminated (program cc1) Please submit a full bug report. See http://gcc.gnu.org/bugs.html> for instructions. make: *** [obj/gs_init.o] Error 1 gs_init.c file has a big size ~7Mb # gcc -v Using built-in specs. Configured with: /home/negative/Desktop/work/mips32/mips32-1.0.6/toolchain_build_mipsel/gcc-3.3.3/configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=mipsel-linux-uclibc --target=mipsel-linux-uclibc --enable-languages=c,c++ --enable-shared --with-gxx-include-dir=/usr/include/c++ --disable-__cxa_atexit --enable-target-optspace --with-gnu-ld --disable-nls --enable-multilib --enable-sjlj-exceptions Thread model: posix gcc version 3.3.3 # uname -a Linux noname 2.4.24-pre2 #34 Thu Aug 4 15:27:35 MSD 2005 mips unknown My system is embedded Linux box. AMD Alchemy 300MHz Memory 64M SDRAM, 16M Flash # gcc -v -save-temps -DHAVE_MKSTEMP -DHAVE_HYPOT -Os -mips32 -mtune=4kc -I/mnt/disc/include -I./src -I./obj -I./obj -I./src -o ./obj/gs_init.o -c ./obj/gs_init.c Using built-in specs. Configured with: /home/negative/Desktop/work/mips32/mips32-1.0.6/toolchain_build_mipsel/gcc-3.3.3/configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=mipsel-linux-uclibc --target=mipsel-linux-uclibc --enable-languages=c,c++ --enable-shared --with-gxx-include-dir=/usr/include/c++ --disable-__cxa_atexit --enable-target-optspace --with-gnu-ld --disable-nls --enable-multilib --enable-sjlj-exceptions Thread model: posix gcc version 3.3.3 /mnt/disc/bin/../lib/gcc-lib/mipsel-linux-uclibc/3.3.3/cc1 -E -quiet -v -I/mnt/disc/include -I./src -I./obj -I./obj -I./src -iprefix /mnt/disc/bin/../lib/gcc-lib/mipsel-linux-uclibc/3.3.3/ -D__GNUC__=3 -D__GNUC_MINOR__=3 -D__GNUC_PATCHLEVEL__=3 -DHAVE_MKSTEMP -DHAVE_HYPOT ./obj/gs_init.c -mips32 -mtune=4kc -Os gs_init.i ignoring nonexistent directory "/mnt/disc/mipsel-linux-uclibc/include" ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/usr/lib/gcc-lib/mipsel-linux-uclibc/3.3.3/include" ignoring nonexistent directory "/usr/mipsel-linux-uclibc/include" ignoring duplicate directory "/mnt/disc/include" as it is a non-system directory that duplicates a system directory ignoring duplicate directory "obj" ignoring duplicate directory "src" #include "..." search starts here: #include <...> search starts here: src obj /mnt/disc/lib/gcc-lib/mipsel-linux-uclibc/3.3.3/include /usr/include End of search list. /mnt/disc/bin/../lib/gcc-lib/mipsel-linux-uclibc/3.3.3/cc1 -fpreprocessed gs_init.i -quiet -dumpbase gs_init.c -mips32 -mtune=4kc -auxbase-strip ./obj/gs_init.o -Os -version -o gs_init.s GNU C version 3.3.3 (mipsel-linux-uclibc) compiled by GNU C version 3.3.3. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 gcc: Internal error: Terminated (program cc1) Please submit a full bug report. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: Compilation Ghostscript gs_init.c file failed on mipsel- linux machine Product: gcc Version: 3.3.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: negative at smartlogic dot ru CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23397
[Bug c/23397] Compilation Ghostscript gs_init.c file failed on mipsel-linux machine
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15 13:27 --- This is just a sign you ran out of memory while compiling the file. -- What|Removed |Added Keywords||memory-hog http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23397
[Bug c/23397] Compilation Ghostscript gs_init.c file failed on mipsel-linux machine
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15 13:28 --- Could you attach the preprocessed source as requested by the web page? Also if you have time, try 3.4.x as 3.3 is no longer being updated. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23397
[Bug libfortran/23363] gfortran 30 x slower that g77 on random I/O
--- Additional Comments From dir at lanl dot gov 2005-08-15 13:32 --- The Linux version is a little faster but has the same problem - dir/tests> f77 -o rdiska rdiska.f dir/tests> time rdiska 1.088u 0.038s 0:01.13 98.2% 0+0k 0+0io 0pf+0w dir/tests> gfortran -O -o rdiska rdiska.f dir/tests> time rdiska STOP 0 5.959u 18.591s 0:24.54 100.0% 0+0k 0+0io 0pf+0w dir/tests> gfortran --v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ./configure --prefix=/home/dir/gfortran --enable-languages=c,f95 Thread model: posix gcc version 4.1.0 20050815 (experimental) dir/tests> !cat cat rdiska.f program main implicit integer(a-z) dimension w(16384) common/frfcm1/mxfrf,ifrf,buflen,fcsize,dskloc ,curlen,kop,ier ncpw=4 buflen=16384 lrecl=ncpw*buflen open (3,access='direct',form='unformatted' 1,recl=lrecl,status='unknown') do 10 i=1,200 call wdiska(3,w,16384,(i-1)*buflen); 10 continue do 20 i=1,200 call rdiska(3,w,16384,(200-i)*buflen); 20 continue stop end subroutine rdiska (lus,w,nw,da) implicit integer(a-z) dimension w(nw) common/frfcm1/mxfrf,ifrf,buflen,fcsize,dskloc ,curlen,kop,ier lda=da/buflen+1 read (lus,rec=lda,iostat=ios) w return entry wdiska(lus,w,nw,da) lda=da/buflen+1 write (lus,rec=lda) w return c end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23363
[Bug c++/23398] New: [C++] ICE when compiling with -fmudflap
---mudflap-bug.cpp---
#include
struct AAA {
AAA(const char*)
{}
};
extern std::string sss;
extern void FFF(const AAA&, int);
struct XXX
{
void test ( void );
int iii;
};
void XXX::test ( void )
{
AAA aaa = ( sss + sss).c_str();
FFF( aaa, iii );
}
-
$ g++ -fmudflap -c mudflap-bug.cpp
mudflap-bug.cpp: In member function 'void XXX::test()':
mudflap-bug.cpp:24: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
$ g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.1/configure
--prefix=/usr/local/gcc-4.0.1--nocheck-native
--with-gnu-as --with-gnu-ld --enable-threads=posix --with-arch=pentium3
--with-tune=pentium4 --enable-__cxa_atexit --enable-languages=c,c++
--disable-checking
--disable-nls
Thread model: posix
gcc version 4.0.1
P.S. sorry, can't reduce the testcase anymore.
--
Summary: [C++] ICE when compiling with -fmudflap
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: smelkov at mph1 dot phys dot spbu dot ru
CC: gcc-bugs at gcc dot gnu dot org
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=23398
[Bug middle-end/23369] [4.0/4.1 regression] build_range_check generates wrong code for funcptr comparison
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2005-08-15 13:46 --- Subject: Re: [4.0/4.1 regression] build_range_check generates wrong code for funcptr comparison > Do I understand correctly that there are two distinct problems: > > 1) gcc should not be canonicalizing constants casted as function pointers I think it has to. GCC has no way of knowing whether the constant is a "real" function pointer or not. > 2) gcc should not generate relational comparisons against function pointers Relational comparisons against function pointers are not allowed in C. However, what GCC does internally is a different matter as it knows whether function pointers need to be canonicalized or not. > it seems from my quick tests that #1 is not affected by build_range_test (i.e. > something else is wrong). I have a patch to build_range_check that fixes the problem in the PR. I'll submit it this evening. I do have a concern that as GCC's optimizations improve we seem to be encountering more and more issues with respect to the handling of function pointers. The problem in the PR is latent in 3.3 and 3.4. I'm not sure why it doesn't happen there. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23369
[Bug other/19266] [mudflap] ICE when compiling with -fmudflap -O
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15 13:48 --- *** Bug 23398 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||smelkov at mph1 dot phys dot ||spbu dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19266
[Bug c++/23398] [C++] ICE when compiling with -fmudflap
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15 13:48 --- *** This bug has been marked as a duplicate of 19266 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23398
[Bug other/23399] New: ICE in create_tmp_var, at gimplify.c:387
4.1.0 20050815: internal compiler error: in create_tmp_var, at gimplify.c:387 3.3.6: internal compiler error: in emit_move_insn, at expr.c:3198 -- Summary: ICE in create_tmp_var, at gimplify.c:387 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-pld-linux GCC target triplet: i686-pld-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23399
[Bug other/23399] ICE in create_tmp_var, at gimplify.c:387
--- Additional Comments From pluto at agmk dot net 2005-08-15 14:12 --- Created an attachment (id=9497) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9497&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23399
[Bug middle-end/23290] Layout changed for structure with single complex field
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-08-15 14:14 --- (In reply to comment #1) > So, using limit 0 for when calculating the integer mode for the size would > fix > the regression on sh? Yes, it would fix the problem with CDImode, however, the mode_for_size_tree call in compute_record_mode is not only used to determine if any mode found from a single member would be suitable, but also the what mode to use otherwise. You don't really want to change what you use for the latter. For vector modes, there is also the added complication that there might be no integer mode at all wide enough to match the size of the vector mode. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23290
[Bug tree-optimization/23094] store ccp misses an optimization
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-08-15 14:15 --- (In reply to comment #4) > Hmm, can someone explain where in store_ccp we stuff constants > into the mem_ref field of lattice values? There are a few places > where simple_cst_equal is used to compare a constant to mem_ref > but AFAICT mem_ref is always the lhs of an expression?? > Yes. mem_ref holds the actual memory store/load expression (i.e., the REFERENCE_CLASS_P tree). The actual constant value is always stored in the CONST_VAL array. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23094
[Bug testsuite/23400] New: "make check" fixinclude failure
With a current HEAD CVS checkout: <-- snip --> ... Fixed: X11/ShellP.h Fixed: X11/Xmu.h Fixed: Xm/BaseClassI.h Fixed: Xm/Traversal.h cmp: EOF on string.h *** string.h2005-08-15 16:47:11.0 +0200 --- /TMP/test/gcc/gcc/fixincludes/tests/base/string.h 2005-08-15 14:32:57.0 +0200 *** *** 10,13 #ifndef _STRING_INCLUDED #define _STRING_INCLUDED #include ! #endif /* _STRING_INCLUDED */ \ No newline at end of file --- 10,13 #ifndef _STRING_INCLUDED #define _STRING_INCLUDED #include ! #endif /* _STRING_INCLUDED */ There were fixinclude test FAILURES make[1]: *** [check] Error 1 make[1]: Leaving directory `/TMP/test/gcc/gcc/build/fixincludes' make: *** [check-fixincludes] Error 2 <-- snip --> -- Summary: "make check" fixinclude failure Product: gcc Version: unknown Status: UNCONFIRMED Severity: minor Priority: P2 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bunk at stusta dot de CC: gcc-bugs at gcc dot gnu dot org 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=23400
[Bug inline-asm/23399] ICE in create_tmp_var, at gimplify.c:387
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15
14:50 ---
Confirmed, reduced testcase:
template bool cas(const T& test_val)
{
bool ret;
__asm__ ("": :"r"(test_val));
}
struct atomic_ptr {
atomic_ptr(){}
atomic_ptr(const volatile atomic_ptr& a) { }
};
void pop()
{
atomic_ptr ne;
cas(ne);
}
This is invalid code as you are passing a struct to an inline-asm as a register
(the code used to use "a"
constriant but I changed it to a "r" constaint to make it general across
targets).
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|other |inline-asm
Ever Confirmed||1
Keywords||ice-on-invalid-code
Known to fail||2.95 3.0.4 3.2.2 4.0.0 3.4.0
||3.3.3
Last reconfirmed|-00-00 00:00:00 |2005-08-15 14:51:00
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23399
[Bug tree-optimization/23391] [4.1 regression] Tree checking failure due to scev
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15 14:53 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23391
[Bug middle-end/23401] New: Gimplifier produces too many temporaries
Take the following code:
struct f
{
struct {
int i;
} ff[10];
};
struct f g;
int (int i)
{
int t1 = 0;
int i1 = g.ff[t1].i;
int i2 = g.ff[i].i;
return i1 + i2;
}
The gimplfiier will produce at -O0:
int i.0;
int t1.1;
int D.1289;
int t1;
int i1;
int i2;
t1 = 0;
i.0 = i;
i1 = g.ff[i.0].i;
t1.1 = t1;
i2 = g.ff[t1.1].i;
D.1289 = i1 + i2;
return D.1289;
Notice how there is a t1.0 and i.0, there should not be there as i and t1 are
already gimple variables.
This might produce a nice speed up for some testcase but I don't know. at -O0,
there will be less
registers to be allocated so reload should not be as high as before.
--
Summary: Gimplifier produces too many temporaries
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23401
[Bug middle-end/23369] [4.0/4.1 regression] build_range_check generates wrong code for funcptr comparison
--- Additional Comments From randolph at tausq dot org 2005-08-15 15:18 --- Subject: Re: [4.0/4.1 regression] build_range_check generates wrong code for funcptr comparison >>1) gcc should not be canonicalizing constants casted as function pointers > > I think it has to. GCC has no way of knowing whether the constant is > a "real" function pointer or not. Doesn't this break __cffc completely? What if I really wanted to do "if (fptr == (func_t)-2)" or "if (fptr == (func_t)5000)? randolph -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23369
[Bug middle-end/23401] Gimplifier produces too many temporaries
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15 15:21 --- For PR 8361, there are about 14 places where this happens. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23401
[Bug target/21841] Documentation should say -mhp-ld/-mgnu-ld are only for hppa64-*-hpux*
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-15 15:23 --- Subject: Bug 21841 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-15 15:23:40 Modified files: gcc: ChangeLog gcc/doc: invoke.texi Log message: PR target/21841 * doc/invoke.texi (-mgnu-ld): Update description. (-mhp-ld): Ditto. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9733&r2=2.9734 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/invoke.texi.diff?cvsroot=gcc&r1=1.668&r2=1.669 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21841
[Bug middle-end/23401] Gimplifier produces too many temporaries
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15 15:24 --- In PR15855, there are a lot more, at about 874. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23401
[Bug target/21841] Documentation should say -mhp-ld/-mgnu-ld are only for hppa64-*-hpux*
--- Additional Comments From sje at cup dot hp dot com 2005-08-15 15:25 --- Fixed on ToT for 4.1. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21841
[Bug c/23402] New: error: statement makes a memory store, but has no V_MAY_DEFS nor V_MUST_DEFS
This is a compile error when trying to compile the file kernel/audit.c from the Linux kernel 2.6.13-rc5-mm1 with a current CVS HEAD gcc. I've removed many of the compiler flags that were present at the original compilation. What triggers this problem is switching from -O0 (no problem) to -O1 (see below). <-- snip --> ... $ /TMP/test/gcc/install/bin/gcc -m32 -Wp,-MD,kernel/.audit.o.d -nostdinc -isystem /TMP/test/gcc/install/lib/gcc/i686-pc-linux-gnu/4.1.0/include -D__KERNEL__ -Iinclude -O1 -save-temps -Iinclude/asm-i386/mach-default -Wno-pointer-sign-DKBUILD_BASENAME=audit -DKBUILD_MODNAME=audit -c -o kernel/audit.o kernel/audit.c kernel/audit.c: In function 'audit_init': kernel/audit.c:518: error: statement makes a memory store, but has no V_MAY_DEFS nor V_MUST_DEFS # VUSE ; audit_skb_queue.lock = D.23048; kernel/audit.c:518: 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. <-- snip --> -- Summary: error: statement makes a memory store, but has no V_MAY_DEFS nor V_MUST_DEFS Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bunk at stusta dot de CC: gcc-bugs at gcc dot gnu dot org 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=23402
[Bug c/23402] error: statement makes a memory store, but has no V_MAY_DEFS nor V_MUST_DEFS
--- Additional Comments From bunk at stusta dot de 2005-08-15 15:28 --- Created an attachment (id=9498) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9498&action=view) preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23402
[Bug c/23402] error: statement makes a memory store, but has no V_MAY_DEFS nor V_MUST_DEFS
-- What|Removed |Added Known to work||4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23402
[Bug tree-optimization/23402] [4.1 Regression] error: statement makes a memory store, but has no V_MAY_DEFS nor V_MUST_DEFS
-- What|Removed |Added Component|c |tree-optimization Keywords||ice-on-valid-code Summary|error: statement makes a|[4.1 Regression] error: |memory store, but has no|statement makes a memory |V_MAY_DEFS nor V_MUST_DEFS |store, but has no V_MAY_DEFS ||nor V_MUST_DEFS Version|unknown |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23402
[Bug testsuite/23400] "make check" fixinclude failure
-- What|Removed |Added Version|unknown |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23400
[Bug middle-end/23401] Gimplifier produces too many temporaries
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15 15:43 --- Hmm, I think this FIXME has something to do with it: /* Gimplify the dimension. Temporary fix for gcc.c-torture/execute/20040313-1.c. Gimplify non-constant array indices into a temporary variable. FIXME - The real fix is to gimplify post-modify expressions into a minimal gimple lvalue. However, that exposes bugs in alias analysis. The alias analyzer does not handle &PTR->FIELD very well. Will fix after the branch is merged into mainline (dnovillo 2004-05-03). */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23401
[Bug tree-optimization/23402] [4.1 Regression] error: statement makes a memory store, but has no V_MAY_DEFS nor V_MUST_DEFS
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15 15:45 --- Reducing. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23402
[Bug target/21841] Documentation should say -mhp-ld/-mgnu-ld are only for hppa64-*-hpux*
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2005-08-15 16:03 --- Subject: Re: Documentation should say -mhp-ld/-mgnu-ld are only for hppa64-*-hpux* > --- Additional Comments From sje at cup dot hp dot com 2005-08-15 15:25 > --- > Fixed on ToT for 4.1. It's ok to update the documentation on 3.4 and 4.0 as well. Thanks, Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21841
[Bug libfortran/23363] gfortran 30 x slower that g77 on random I/O
--- Additional Comments From kargl at gcc dot gnu dot org 2005-08-15 17:03 --- I think this many be a duplicate of PR 21820. Also, there has been some discussion in the fortran@ list about gfortran's (homebrewed) internal buffering. FWIW, if you have pre-existing files that you want to overwrite, then use status='replace' in your open statement or delete the file before you run your program. If you're performing random access in a file you want to keep, then I think we're basically screwed until we overhaul the IO subsystem. Bugmeister, can we create a meta-bug linking 21820 and this bug report. 21820 has an attempted analysis of the problem; while Dale has provided a few useful programs. -- What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23363
[Bug inline-asm/23200] [4.0/4.1 regression] rejects "i"(&var + 1)
--- Additional Comments From amacleod at redhat dot com 2005-08-15 17:15
---
TER isnt doing anything with this because there are no virtual operands. It
sees:
# BLOCK 0
# PRED: ENTRY [100.0%] (fallthru,exec)
D.1279 = &var + 1B;
__asm__ __volatile__(""::"i" D.1279);
return 0;
so the stmt:
D.1279 = &var + 1B;
isnt considered for replacvement since there are no dependancies whatsoever on
it. TER operates on the assumptions that if a stmt has no USES and no VUSES,
then one of the other optimizations would have done the substitution if it were
possible.
There use to be a good reason for this, and there was a comment to that effect,
but it seems to have been removed. Perhaps the original reason is gone, but the
code hasnt been properly updated to fix the issue.
A quick hack to TER to add a "NO_DEPEND_PARTITION" for such statements appears
to do what you are looking for here:
# BLOCK 0
# PRED: ENTRY [100.0%] (fallthru,exec)
__asm__ __volatile__(""::"i" &var + 1B);
return 0;
I will run it through the test suites to see if it reintroduces whatever
the original problem with these types of replacements was.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200
[Bug tree-optimization/23402] [4.1 Regression] error: statement makes a memory store, but has no V_MAY_DEFS nor V_MUST_DEFS
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15
17:18 ---
Confirmed, reduced testcase:
typedef struct {} raw_spinlock_t;
typedef struct {
raw_spinlock_t raw_lock;
} spinlock_t;
struct sk_buff_head {
int i;
spinlock_t lock;
};
struct sk_buff_head audit_skb_queue;
void audit_init(void)
{
struct sk_buff_head *list = &audit_skb_queue;
audit_skb_queue.lock = (spinlock_t) { .raw_lock = { } };
}
Taking the address is required even though it is dead.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-08-15 17:18:44
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23402
[Bug tree-optimization/23402] [4.1 Regression] error: statement makes a memory store, but has no V_MAY_DEFS nor V_MUST_DEFS
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15 17:24 --- If I disable structural alias analysis (-fno-tree-salias) the testcase works. -- What|Removed |Added CC||dberlin at gcc dot gnu dot ||org, dnovillo at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23402
[Bug middle-end/23369] [4.0/4.1 regression] build_range_check generates wrong code for funcptr comparison
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2005-08-15 17:24 --- Subject: Re: [4.0/4.1 regression] build_range_check generates wrong code for funcptr comparison > Subject: Re: [4.0/4.1 regression] build_range_check > generates wrong code for funcptr comparison > > >>1) gcc should not be canonicalizing constants casted as function pointers > > > > I think it has to. GCC has no way of knowing whether the constant is > > a "real" function pointer or not. > > Doesn't this break __cffc completely? What if I really wanted to do "if > (fptr == (func_t)-2)" or "if (fptr == (func_t)5000)? Why would you want to? My opinion is that __cffc only has to deal with the values traditionally used by "signal". GCC doesn't know whether (func_t)5000 needs to be canonicalized or not. It will happen anyway if (func_t)5000 is passed around. The behavior of __cffc was more or less copied from the corresponding HP routine. __cffc expects to be passed a valid function pointer. Currently, __cffc doesn't canonicalize small positive integers and -1 because they are used by signal and friends, and they can't be a valid function pointer address. I guess this might be extended somewhat but the point. Nobody has defined what's ok. When the plabel bit is set in the function pointer, __cffc has to load data from the function descriptor and this can cause a segmentation fault if the address isn't valid. I don't think trying to avoid these faults is worth the added complexity. This will eventually go away when Carlos' opd patch is installed. I also think that the definitions of SIG_IGN, etc., are suspect. These problems wouldn't occur if there were actual functions in the C library for them. There are also ways to avoid canonicalization in compares. I recognize that this problem is in generic code. However, it might be possible to replace the generic routine with a hppa specific routine that avoids canonicalization when comparing a function pointer with a special value. This would make the code more efficient. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23369
[Bug java/23404] New: Interpreted byte code does not run properly on ppc
This is on a Fedora Core 4 machine: gij (GNU libgcj) version 4.0.1 20050727 (Red Hat 4.0.1-5) The to be attached code does not run properly on ppc. Runs fine on x86 (32 and 64 bit). The byte-code appears to be correct because it runs fine using the IBM JVM. Compiled with: javac plplot/*/*.java Run with: java plplot.examples.x08 The output is the arguments passed to plw3d(). In the source this is: pls.w3d( 1.0, 1.0, 1.0, -1.5, 1.5, -0.5, 1.5, zmin, zmax, alt[k], az[k] ); Output (first loop) is: 0.0 1.0 1.0 -1.5 1.5 -0.5 1.5 -5.093869927024149 NaN -3.7431896459052014E-274 5.32506451E-315 Correct output should be: 1.0 1.0 1.0 -1.5 1.5 -0.5 1.5 -5.093869927024149 6.636602508481567 60.0 30.0 It looks like arg1, arg9, arg10, and arg11 are not passed properly. -- Summary: Interpreted byte code does not run properly on ppc Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: orion at cora dot nwra dot com CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org GCC host triplet: ppc64-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23404
[Bug tree-optimization/23402] [4.1 Regression] error: statement makes a memory store, but has no V_MAY_DEFS nor V_MUST_DEFS
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-08-15 17:28 --- Subject: Re: [4.1 Regression] error: statement makes a memory store, but has no V_MAY_DEFS nor V_MUST_DEFS On Mon, 2005-08-15 at 17:24 +, pinskia at gcc dot gnu dot org wrote: > --- Additional Comments From pinskia at gcc dot gnu dot org > 2005-08-15 17:24 --- > If I disable structural alias analysis (-fno-tree-salias) the testcase > works. > Ugh. We dealt with this once. After discussing with RTH or diego (i forget who) about what to do here, we decided the best solution is to not generate these stores into the IL in the first place, rather than hack up all the code around it to allow zero sized stores. After all, what is the store of the zero sized field supposed to represent? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23402
[Bug java/23404] Interpreted byte code does not run properly on ppc
--- Additional Comments From orion at cora dot nwra dot com 2005-08-15 17:28 --- Created an attachment (id=9499) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9499&action=view) Java code to reproduce problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23404
[Bug tree-optimization/23402] [4.1 Regression] error: statement makes a memory store, but has no V_MAY_DEFS nor V_MUST_DEFS
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15 17:32 --- This is related to PR 21839 which was fixed by not gimplifying the store but it looks like it did not fix fully not gimplifing the store. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23402
[Bug tree-optimization/23402] [4.1 Regression] error: statement makes a memory store, but has no V_MAY_DEFS nor V_MUST_DEFS
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15
17:36 ---
Here is another testcase:
typedef struct {} spinlock_t;
struct sk_buff_head {
int i;
spinlock_t lock;
};
struct sk_buff_head audit_skb_queue;
void audit_init(void)
{
struct sk_buff_head *list = &audit_skb_queue;
spinlock_t a = {};
audit_skb_queue.lock = a;
}
The gimplifier is emitting the "audit_skb_queue.lock = a;" which is what is
causing the issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23402
[Bug libffi/23404] Interpreted byte code does not run properly on ppc
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15 17:46 --- I think this is a libffi issue rather than anything else. -- What|Removed |Added Component|java|libffi GCC host triplet|ppc64-redhat-linux | GCC target triplet||ppc64-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23404
[Bug libstdc++/23405] New: find and range concept testing for all containers
Policy based associative containers make different assumptions and have different requirements for find. Integrate testing of this with conherent testing of std:: containers. -- Summary: find and range concept testing for all containers Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bkoz at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org 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=23405
[Bug rtl-optimization/23392] foward-1.m fails with -funroll-loops -O3 -fgnu-runtime
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15 17:49 --- Confirmed, it also fails on ppc-aix. http://gcc.gnu.org/ml/gcc-testresults/2005-08/msg00878.html -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC target triplet|powerpc-darwin |ppc-darwin, ppc-aix Last reconfirmed|-00-00 00:00:00 |2005-08-15 17:49:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23392
[Bug libstdc++/23278] SJLJ-exceptions broken
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-08-15 17:51 --- Where is the testcase? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23278
[Bug java/23300] DECL_FIELD_OFFSET == 0 versus build_field_ref
--- Additional Comments From tromey at gcc dot gnu dot org 2005-08-15 19:38 --- I submitted a patch. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-15 19:38:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23300
[Bug tree-optimization/22372] Vectorizer produces mis-match types
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15 20:18 --- Note only the first patch (modify.diff.txt) in PR 22368 is needed to reproduce this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22372
[Bug libstdc++/23406] New: libstdc++ fails to link with std::string on AIX
FYI, there's a vague reference on http://gcc.gnu.org/install/specific.html#x-
ibm-aix to linker bugs solved by IY53606, so I have verified that the latest
5.2 maintainence level is there, and it contains that APAR.
$ cat gccbug.cpp
#include
int main() {
std::string bla = "foo";
return bla.size();
}
---
$ gcc -v
Using built-in specs.
Target: powerpc-ibm-aix5.2.0.0
Configured with: ../gcc-4.0.1/configure --prefix=/home/johnkw/external
Thread model: aix
gcc version 4.0.1
---
$ g++ -v -save-temps -Wl,-bnoquiet gccbug.cpp
Using built-in specs.
Target: powerpc-ibm-aix5.2.0.0
Configured with: ../gcc-4.0.1/configure --prefix=/home/johnkw/external
Thread model: aix
gcc version 4.0.1
/home/johnkw/external/libexec/gcc/powerpc-ibm-aix5.2.0.0/4.0.1/cc1plus -E -
quiet -v -iprefix /home/johnkw/external/binpowerpc-ibm-aix5.2.0.0/4.0.1/ -
D_ALL_SOURCE gccbug.cpp -fpch-preprocess -o gccbug.ii
ignoring nonexistent directory "/home/johnkw/external/binpowerpc-ibm-
aix5.2.0.0/4.0.1/../../../../include/c++/4.0.1"
ignoring nonexistent directory "/home/johnkw/external/binpowerpc-ibm-
aix5.2.0.0/4.0.1/../../../../include/c++/4.0.1/powerpc-ibm-aix5.2.0.0"
ignoring nonexistent directory "/home/johnkw/external/binpowerpc-ibm-
aix5.2.0.0/4.0.1/../../../../include/c++/4.0.1/backward"
ignoring nonexistent directory "/home/johnkw/external/binpowerpc-ibm-
aix5.2.0.0/4.0.1/include"
ignoring nonexistent directory "/home/johnkw/external/binpowerpc-ibm-
aix5.2.0.0/4.0.1/../../../../powerpc-ibm-aix5.2.0.0/include"
ignoring nonexistent directory "/home/johnkw/external/lib/gcc/powerpc-ibm-
aix5.2.0.0/4.0.1/../../../../powerpc-ibm-aix5.2.0.0/include"
#include "..." search starts here:
#include <...> search starts here:
/home/johnkw/external/lib/gcc/powerpc-ibm-
aix5.2.0.0/4.0.1/../../../../include/c++/4.0.1
/home/johnkw/external/lib/gcc/powerpc-ibm-
aix5.2.0.0/4.0.1/../../../../include/c++/4.0.1/powerpc-ibm-aix5.2.0.0
/home/johnkw/external/lib/gcc/powerpc-ibm-
aix5.2.0.0/4.0.1/../../../../include/c++/4.0.1/backward
/usr/local/include
/home/johnkw/external/include
/home/johnkw/external/lib/gcc/powerpc-ibm-aix5.2.0.0/4.0.1/include
/usr/include
End of search list.
/home/johnkw/external/libexec/gcc/powerpc-ibm-aix5.2.0.0/4.0.1/cc1plus -
fpreprocessed gccbug.ii -quiet -dumpbase gccbug.cpp -auxbase gccbug -version -o
gccbug.s
GNU C++ version 4.0.1 (powerpc-ibm-aix5.2.0.0)
compiled by GNU C version 4.0.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=32768
as -u -mppc -o gccbug.o gccbug.s
/home/johnkw/external/libexec/gcc/powerpc-ibm-aix5.2.0.0/4.0.1/collect2 -
bpT:0x1000 -bpD:0x2000 -btextro -bnodelcsect /lib/crt0.o -
L/home/johnkw/external/bin -L/home/johnkw/external/lib/gcc/powerpc-ibm-
aix5.2.0.0/4.0.1 -L/home/johnkw/external/lib/gcc/powerpc-ibm-
aix5.2.0.0/4.0.1/../../../../powerpc-ibm-aix5.2.0.0/lib -
L/home/johnkw/external/.. -L/home/johnkw/external/lib/gcc/powerpc-ibm-
aix5.2.0.0/4.0.1/../../.. -bnoquiet gccbug.o -lstdc++ -lm -
lgcc_s /home/johnkw/external/lib/gcc/powerpc-ibm-aix5.2.0.0/4.0.1/libgcc.a -lc -
lgcc_s /home/johnkw/external/lib/gcc/powerpc-ibm-aix5.2.0.0/4.0.1/libgcc.a
(ld): halt 4
(ld): setopt r/o->w
(ld): setopt nodelcsect
(ld): lrgpage 0
(ld): savename a.out
(ld): filelist 8 1
(ld): i /lib/crt0.o
(ld): i /tmp//ccg0kYOd.o
(ld): i gccbug.o
(ld): lib /home/johnkw/external/lib/gcc/powerpc-ibm-
aix5.2.0.0/4.0.1/../../../libstdc++.a
(ld): lib /usr/lib/libm.a
(ld): lib /home/johnkw/external/lib/gcc/powerpc-ibm-
aix5.2.0.0/4.0.1/../../../libgcc_s.a
(ld): i /home/johnkw/external/lib/gcc/powerpc-ibm-aix5.2.0.0/4.0.1/libgcc.a
(ld): lib /usr/lib/libc.a
LIBRARY: Shared object libstdc++.a[libstdc++.so.6]: 1162 symbols imported.
LIBRARY: Shared object libgcc_s.a[shr.o]: 108 symbols imported.
LIBRARY: Shared object libc.a[shr.o]: 2562 symbols imported.
LIBRARY: Shared object libc.a[meth.o]: 2 symbols imported.
LIBRARY: Shared object libc.a[posix_aio.o]: 17 symbols imported.
LIBRARY: Shared object libc.a[aio.o]: 11 symbols imported.
LIBRARY: Shared object libc.a[pse.o]: 5 symbols imported.
LIBRARY: Shared object libc.a[dl.o]: 4 symbols imported.
LIBRARY: Shared object libc.a[pty.o]: 1 symbols imported.
FILELIST: Number of previously inserted files processed: 8
(ld): initfini _GLOBAL__FI_a_out _GLOBAL__FD_a_out
(ld): resolve
RESOLVE: 70 of 5339 symbols were kept.
(ld): addgl /usr/lib/glink.o
ADDGL: Glink code added for 15 symbols.
(ld): er full
ld: 0711-318 ERROR: Undefined symbols were found.
The following symbols are in error:
SymbolInpndx TY CL Source-File(Object-File) OR Import-File
{Shared-object}
RLD: Address Section Rld-type Referencing Symbol
---
---
ld: 0711-317 ERROR: Undefined symbol: .std::allocator::allocator()
.std::allocator::allocator()[2] ER PR gccbug.cpp(gccbug.o)
001c .text
[Bug libstdc++/23406] libstdc++ fails to link with std::string on AIX
--- Additional Comments From appfault at hotmail dot com 2005-08-15 21:07 --- Created an attachment (id=9500) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9500&action=view) preprocessed source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23406
[Bug fortran/23407] New: program works correctly with -g option but fails with -O2 option on LINUX
This program works Ok on the Macintosh. On linux this program fails with -O2, but works Ok with -g - dir/tests> gfortran -O2 -o timefun02 timefun02.f dir/tests> timefun02 Error1.001.00 STOP 0 dir/tests> gfortran -g -o timefun02 timefun02.f dir/tests> timefun02 STOP 0 dir/tests> cat timefun02.f program main implicit real*8 (a-h,o-z) time2=0d0 do 20 i=1,10 time2 = time2 + 0.1d0 20 continue call sub1(time2) stop end subroutine sub1(time) implicit real*8 (a-h,o-z) time2=0d0 do 30 i=1,10 time2 = time2 + 0.1d0 30 continue if(time2.ne.time)then write(6,*)'Error ',time2,time endif return end dir/tests> gfortran --v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ./configure --prefix=/home/dir/gfortran --enable-languages=c,f95 Thread model: posix gcc version 4.1.0 20050815 (experimental) -- Summary: program works correctly with -g option but fails with - O2 option on LINUX Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dir at lanl dot gov CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23407
[Bug fortran/23407] program works correctly with -g option but fails with -O2 option on LINUX
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15 21:23 --- This almost can be considered a bug in the processor (x86 that is). The issue is that on x86 GCC is using excessive precision so you cannot really rely on equals with floating point. Either use -ffloat-store or use -mfpmath=sse -msse2 or stop relying on float being equal. This is a dup of bug 323. *** This bug has been marked as a duplicate of 323 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23407
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15 21:23 --- *** Bug 23407 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||dir at lanl dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug middle-end/23408] New: ICE on valid, if checking enabled
If the following code is compiled by a GCC with checking enabled (configured
with --enable-checking=misc,tree,rtl,rtlflag,gc,gcac) and -O1, a ICE happen:
static __inline__ int f () { return g (); }
int g () { return f (); }
With checking disabled, the ICE does not happen.
gcc version:
GNU C version 4.1.0 20050815 (experimental) (i686-pc-linux-gnu)
Backtrace:Analyzing compilation unit {GC 733k -> 718k} {GC 719k -> 719k} {GC
719k -> 719k}Performing intraprocedural optimizations
{GC 721k -> 694k}
Program received signal SIGSEGV, Segmentation fault.
0x08aea1eb in cgraph_decide_inlining_incrementally (node=0xb7c62c98, early=1
'\001') at ../.././gcc/ipa-inline.c:1029
1029if (e->callee->local.disregard_inline_limits
(gdb) bt
#0 0x08aea1eb in cgraph_decide_inlining_incrementally (node=0xb7c62c98, early=1
'\001') at ../.././gcc/ipa-inline.c:1029
#1 0x08aea64d in cgraph_early_inlining () at ../.././gcc/ipa-inline.c:1131
#2 0x08a59ff0 in execute_one_pass (pass=0x8e71bc0) at ../.././gcc/passes.c:797
#3 0x08a5a0ed in execute_ipa_pass_list (pass=0x8e71bc0) at
../.././gcc/passes.c:843
#4 0x08ae6807 in ipa_passes () at ../.././gcc/cgraphunit.c:1202
#5 0x08ae68c7 in cgraph_optimize () at ../.././gcc/cgraphunit.c:1236
#6 0x0806cdf1 in c_write_global_declarations () at ../.././gcc/c-decl.c:7618
#7 0x089fcc5c in compile_file () at ../.././gcc/toplev.c:984
#8 0x089fe491 in do_compile () at ../.././gcc/toplev.c:1914
#9 0x089fe4f3 in toplev_main (argc=3, argv=0xbff6eb44) at
../.././gcc/toplev.c:1946
#10 0x080ed5ca in main (argc=3, argv=0xbff6eb44) at ../.././gcc/main.c:35
(gdb) p e
$1 = (struct cgraph_edge *) 0xa5a5a5a5
(gdb) up
#1 0x08aea64d in cgraph_early_inlining () at ../.././gcc/ipa-inline.c:1131
1131cgraph_decide_inlining_incrementally (node, true);
(gdb) p *node
$2 = {decl = 0xa5a5a5a5, callees = 0xa5a5a5a5, callers = 0xa5a5a5a5, next =
0xa5a5a5a5, previous = 0xa5a5a5a5, origin = 0xa5a5a5a5,
nested = 0xa5a5a5a5, next_nested = 0xa5a5a5a5, next_needed = 0xa5a5a5a5,
next_clone = 0xa5a5a5a5, prev_clone = 0xa5a5a5a5,
master_clone = 0xa5a5a5a5, aux = 0xa5a5a5a5, local = {self_insns =
-1515870811, local = 165 '¥', externally_visible = 165 '¥',
finalized = 165 '¥', inlinable = 165 '¥', disregard_inline_limits = 165 '¥',
redefined_extern_inline = 165 '¥',
for_functions_valid = 165 '¥', vtable_method = 165 '¥'}, global =
{inlined_to = 0xa5a5a5a5, insns = -1515870811,
estimated_growth = -1515870811, inlined = 165 '¥'}, rtl =
{preferred_incoming_stack_boundary = -1515870811},
count = -651061426900571, uid = -1515870811, needed = 165 '¥', reachable =
165 '¥', lowered = 165 '¥', analyzed = 165 '¥',
output = 165 '¥', externally_visible = 165 '¥', alias = 165 '¥'}
As far as I can tell, the garbage collector seems to free some used memory.
It is a regression, as GCC version 20050606 did not showed this error.
--
Summary: ICE on valid, if checking enabled
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: e9925248 at stud4 dot tuwien dot ac dot at
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu (exists also on avr)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23408
[Bug libstdc++/23406] libstdc++ fails to link with std::string on AIX
-- What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23406
[Bug middle-end/23408] [4.1 Regression] ICE in cgraph_decide_inlining_incrementally (using freed GC memory)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15 21:37 --- Also reproduced with --enable-checking=yes (default) and --param ggc-min-expand=0 --param ggc-min-heapsize=0 -O1. This means we are using already freed GC memory. Honza could you look into this since it seems like it was caused by one of your functions. Smells like we are missing a GTY somwhere. -- What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu (exists | |also on avr)| Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2005-08-15 21:37:39 date|| Summary|ICE on valid, if checking |[4.1 Regression] ICE in |enabled |cgraph_decide_inlining_incre ||mentally (using freed GC ||memory) Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23408
[Bug libstdc++/23406] libstdc++ fails to link with std::string on AIX
-- What|Removed |Added CC||jlawson-gcc at bovine dot ||net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23406
[Bug libfortran/23321] Direct unformatted read beyond EOF cores
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-08-15
22:12 ---
Proposed fix:
Index: transfer.c
===
RCS file: /cvs/gcc/gcc/libgfortran/io/transfer.c,v
retrieving revision 1.52
diff -c -p -r1.52 transfer.c
*** transfer.c 9 Aug 2005 01:56:04 - 1.52
--- transfer.c 15 Aug 2005 22:05:20 -
*** data_transfer_init (int read_flag)
*** 1163,1168
--- 1163,1177
if (g.mode == READING && current_unit->mode == WRITING)
flush(current_unit->s);
+ /* Check whether the record number exists on reading. */
+
+ if (g.mode == READING
+ && ioparm.rec * current_unit->recl > file_length (current_unit->s))
+ {
+ generate_error (ERROR_BAD_OPTION, "Non-existing record number");
+ return;
+ }
+
/* Position the file. */
if (sseek (current_unit->s,
(ioparm.rec - 1) * current_unit->recl) == FAILURE)
Regression testing etc. to follow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23321
[Bug java/9861] method name mangling ignores return type
--- Additional Comments From tj at laurenzo dot org 2005-08-15 22:32 --- I did some work on this. It's not quite ready for prime-time: http://tjlaurenzo.blogspot.com/2005/08/adventures-with-java-5-and-gcj.html I'll try to roll it up into a proper patch and such when I get the suite rebuilt and tested. Since its a breaking ABI change, I imagine the primary audience for this patch in the short term would be people who really need this bug fixed and are willing to give up compatibility to do it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9861
[Bug tree-optimization/23402] [4.1 Regression] error: statement makes a memory store, but has no V_MAY_DEFS nor V_MUST_DEFS
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15 22:37 --- I have a fix which I am testing. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23402
[Bug middle-end/23409] New: [meta-bug] data dependence analyzer (BAD vs. BOP)
This meta-bug tracks differences between Banerjee's Analyzer for Data-dependences (BAD) and Bill Pugh's Omega solver. -- Summary: [meta-bug] data dependence analyzer (BAD vs. BOP) Product: gcc Version: 3.3.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sebastian dot pop at cri dot ensmp dot fr CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23409
[Bug middle-end/23410] New: AIL: gcc.c-torture/execute/950612-1.c execution, at -Os and -O3
New failure: Executing on host: /test/gnu/gcc-3.3/objdir/gcc/xgcc -B/test/gnu/gcc-3.3/objdir/ gcc/ /test/gnu/gcc-3.3/gcc/gcc/testsuite/gcc.c-torture/execute/950612-1.c -w - O3 -fomit-frame-pointer -fno-show-column -lm -o /test/gnu/gcc-3.3/objdir/gcc /testsuite/950612-1.x3(timeout = 300) PASS: gcc.c-torture/execute/950612-1.c compilation, -O3 -fomit-frame-pointer Setting LD_LIBRARY_PATH to :/test/gnu/gcc-3.3/objdir/gcc::/test/gnu/gcc-3.3/objd ir/gcc FAIL: gcc.c-torture/execute/950612-1.c execution, -O3 -fomit-frame-pointer (gdb) disass main Dump of assembler code for function main: 0x2a10 :stw rp,-14(sp) 0x2a14 :b,l 0x29f8 ,rp 0x2a18 :ldo 40(sp),sp 0x2a1c : nop End of assembler dump. Looks like the test was optimized into a call to abort! -- Summary: AIL: gcc.c-torture/execute/950612-1.c execution, at -Os and -O3 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: hppa2.0w-hp-hpux11.11 GCC host triplet: hppa2.0w-hp-hpux11.11 GCC target triplet: hppa2.0w-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23410
[Bug middle-end/23410] FAIL: gcc.c-torture/execute/950612-1.c execution, at -Os and -O3
-- What|Removed |Added Summary|AIL: gcc.c- |FAIL: gcc.c- |torture/execute/950612-1.c |torture/execute/950612-1.c |execution, at -Os and -O3 |execution, at -Os and -O3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23410
[Bug middle-end/23411] New: [data deps] Distance on outer loops for self output deps
The most frequent case that shows up when bootstrapping autovect branch
with BOOT_CFLAGS="-O2 -fcheck-data-deps" is the following:
Dist vectors from the first dependence analyzer:
10
Omega dist vectors are not the same:
00
Data dependence relation is:
(Data Dep:
access_fn_A: {0, +, 1}_3
access_fn_B: {0, +, 1}_3
(subscript
iterations_that_access_an_element_twice_in_A: 0
last_conflict: scev_not_known;
iterations_that_access_an_element_twice_in_B: 0
last_conflict: scev_not_known;
(Subscript distance: 0
)
)
distance_vect: 00
direction_vect: ==
)
This is caused by a loop containing a data ref like the following:
loop_2
loop_3
A[{0, +, 1}_3] = ...
endloop_3
endloop_2
For this pattern, tree-data-ref.c says the following:
/* There is a distance of 1 on all the outer loops:
Example: there is a dependence of distance 1 on loop_1 for the array A.
| loop_1
| A[5] = ...
| endloop
*/
But now that Omega says that dist is (0, 0) I'm not sure anymore whether
this is the standard meaning of distance vectors.
Allen&Kennedy book states:
Definition 2.9. Suppose that there is a dependence from statement
S1 on iteration i of a loop nest and statement S2 on iteration j, then
the dependence distance vector d(i,j) is defined as a vector of
length n such that d(i,j) = j - i.
--
Summary: [data deps] Distance on outer loops for self output deps
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebastian dot pop at cri dot ensmp dot fr
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23411
[Bug middle-end/23409] [meta-bug] data dependence analyzer (BAD vs. BOP)
-- What|Removed |Added BugsThisDependsOn||23411 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23409
[Bug middle-end/23411] [data deps] Distance on outer loops for self output deps
-- What|Removed |Added OtherBugsDependingO||23409 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23411
[Bug middle-end/23410] FAIL: gcc.c-torture/execute/950612-1.c execution, at -Os and -O3
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15 23:01 --- Hmm, does hppa2.0w-hp-hpux11.11 use HOST_WIDE_INT as 32? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23410
[Bug tree-optimization/23410] [4.1 Regression] FAIL: gcc.c-torture/execute/950612-1.c execution, at -Os and -O3
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15 23:07 --- This is also reproduciable on i686-pc-linux-gnu. When was this last updated? Was this before: 2005-08-15 Sebastian Pop <[EMAIL PROTECTED]> PR 23386 * tree-data-ref.c (estimate_niter_from_size_of_data): When step is negative compute the estimation from init downwards to zero. you might want to test after that because I only tested x86 before this patch. -- What|Removed |Added Component|middle-end |tree-optimization GCC build triplet|hppa2.0w-hp-hpux11.11 | GCC host triplet|hppa2.0w-hp-hpux11.11 | GCC target triplet|hppa2.0w-hp-hpux11.11 |i686-pc-linux-gnu, hppa2.0w- ||hp-hpux11.11 Keywords||wrong-code Summary|FAIL: gcc.c-|[4.1 Regression] FAIL: |torture/execute/950612-1.c |gcc.c- |execution, at -Os and -O3 |torture/execute/950612-1.c ||execution, at -Os and -O3 Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23410
[Bug tree-optimization/23410] [4.1 Regression] FAIL: gcc.c-torture/execute/950612-1.c execution, at -Os and -O3
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2005-08-15 23:07 --- Subject: Re: FAIL: gcc.c-torture/execute/950612-1.c execution, at -Os and -O3 > --- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15 > 23:01 --- > Hmm, does hppa2.0w-hp-hpux11.11 use HOST_WIDE_INT as 32? No. It should be 64 as the target supports long long. The bootstrap compiler was gcc. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23410
[Bug middle-end/23412] New: [data deps] Overflow problem in Omega
This pattern shows something strange in the results of Omega.
Looking at the step of array accesses it seems like Omega has
just no mechanism to handle -1 evolutions i.e. 0 in
unsigned with modulo arithmetics. This occurs in
gcc/gcc/real.c during bootstrap on amd64-linux.
Dist vectors from the first dependence analyzer:
11
Omega dist vectors are not the same:
-10
Data dependence relation is:
(Data Dep:
access_fn_A: {1, +, 4294967295}_5
access_fn_B: {2, +, 4294967295}_5
(subscript
iterations_that_access_an_element_twice_in_A: {0, +, 1}_1
last_conflict: 1
iterations_that_access_an_element_twice_in_B: {1, +, 1}_1
last_conflict: 1
(Subscript distance: 1
)
)
distance_vect: -10
direction_vect: -=
)
--
Summary: [data deps] Overflow problem in Omega
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebastian dot pop at cri dot ensmp dot fr
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23412
[Bug middle-end/23409] [meta-bug] data dependence analyzer (BAD vs. BOP)
-- What|Removed |Added BugsThisDependsOn||23412 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23409
[Bug middle-end/23412] [data deps] Overflow problem in Omega
-- What|Removed |Added OtherBugsDependingO||23409 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23412
[Bug tree-optimization/23410] [4.1 Regression] FAIL: gcc.c-torture/execute/950612-1.c execution, at -Os and -O3
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2005-08-15 23:11 --- Subject: Re: [4.1 Regression] FAIL: gcc.c-torture/execute/950612-1.c execution, at -Os and -O3 > This is also reproduciable on i686-pc-linux-gnu. > > When was this last updated? > > Was this before: > 2005-08-15 Sebastian Pop <[EMAIL PROTECTED]> > > PR 23386 > * tree-data-ref.c (estimate_niter_from_size_of_data): When > step is negative compute the estimation from init downwards to zero. > > you might want to test after that because I only tested x86 before this patch. After. It was updated at Mon Aug 15 13:59:26 UTC 2005 and has 2005-08-15 Sebastian Pop <[EMAIL PROTECTED]> PR 23391 * Makefile.in (tree-chrec.o): Depends on real.h. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23410
[Bug middle-end/23413] New: [data deps] Overflow problem in Omega
This pattern shows something strange in the results of Omega.
Looking at the step of array accesses it seems like Omega has
just no mechanism to handle -1 evolutions i.e. 0 in
unsigned with modulo arithmetics. This occurs in
gcc/gcc/real.c during bootstrap on amd64-linux.
Dist vectors from the first dependence analyzer:
11
Omega dist vectors are not the same:
-10
Data dependence relation is:
(Data Dep:
access_fn_A: {1, +, 4294967295}_5
access_fn_B: {2, +, 4294967295}_5
(subscript
iterations_that_access_an_element_twice_in_A: {0, +, 1}_1
last_conflict: 1
iterations_that_access_an_element_twice_in_B: {1, +, 1}_1
last_conflict: 1
(Subscript distance: 1
)
)
distance_vect: -10
direction_vect: -=
)
--
Summary: [data deps] Overflow problem in Omega
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebastian dot pop at cri dot ensmp dot fr
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23413
[Bug middle-end/23412] [data deps] Overflow problem in Omega
--- Additional Comments From sebastian dot pop at cri dot ensmp dot fr
2005-08-15 23:16 ---
This one is also probably an overflow in Omega,
but the dependence problem looks pretty simple...
This occurs in gcc/gcc/omega.c on amd64-linux.
Dist vectors from the first dependence analyzer:
110
Omega dist vectors are not the same:
0 10922 10922
Data dependence relation is:
(Data Dep:
access_fn_A: {1, +, 1}_7
access_fn_B: {1, +, 1}_7
(subscript
iterations_that_access_an_element_twice_in_A: 0
last_conflict: scev_not_known;
iterations_that_access_an_element_twice_in_B: 0
last_conflict: scev_not_known;
(Subscript distance: 0
)
)
distance_vect: 0 10922 10922
direction_vect: =++
)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23412
[Bug middle-end/23410] [4.1 Regression] FAIL: gcc.c-torture/execute/950612-1.c execution, at -Os and -O3
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15 23:31 --- It works on PPC-darwin for some reason. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|tree-optimization |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23410
[Bug rtl-optimization/23393] catchall-1.m fails at -Os
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-16 00:22 --- Only catch-all-1.m fails now: http://gcc.gnu.org/ml/gcc-testresults/2005-08/msg00891.html -- What|Removed |Added Summary|catchall-1.m and finally- |catchall-1.m fails at -Os |1.m fails at -Os| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23393
