[Bug libfortran/41760] New: Problem with configure when using --with-gmp and --with-mpfr
I configure gcc-4.4.2 with : configure:11038: /usr/local/GCC/GCC-4.4.2/i686-gcc-4.4.2/./gcc/gfortran -B/usr/local/GCC/GCC-4.4.2/i686-gcc-4.4.2/./gcc/ -B/usr/local/GCC/gcc-4.4.2/i686-pc-linux-gnu/bin/ -B/usr/local/GCC/gcc-4.4.2/i686-pc-linux-gnu/lib/ -isystem /usr/local/GCC/gcc-4.4.2/i686-pc-linux-gnu/include -isystem /usr/local/GCC/gcc-4.4.2/i686-pc-linux-gnu/sys-include -v /dev/null 5 Driving: /usr/local/GCC/GCC-4.4.2/i686-gcc-4.4.2/./gcc/gfortran -B/usr/local/GCC/GCC-4.4.2/i686-gcc-4.4.2/./gcc/ -B/usr/local/GCC/gcc-4.4.2/i686-pc-linux-gnu/bin/ -B/usr/local/GCC/gcc-4.4.2/i686-pc-linux-gnu/lib/ -isystem /usr/local/GCC/gcc-4.4.2/i686-pc-linux-gnu/include -isystem /usr/local/GCC/gcc-4.4.2/i686-pc-linux-gnu/sys-include -v -lgfortranbegin -lgfortran -lm -shared-libgcc Reading specs from /usr/local/GCC/GCC-4.4.2/i686-gcc-4.4.2/./gcc/specs Target: i686-pc-linux-gnu Configured with: ../gcc-4.4.2/configure --cache-file=config.cache --srcdir=/usr/local/GCC/GCC-4.4.2/gcc-4.4.2 --prefix=/usr/local/GCC/gcc-4.4.2 --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --with-gmp=/usr/local --with-mpfr=/usr/local Thread model: posix gcc version 4.4.2 (GCC) On my system, the standard version of gmp is different of the version installed in ``/usr/local''. Below is the ``config.log'' of ``libfortan'' : This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by GNU Fortran Runtime Library configure 0.3, which was generated by GNU Autoconf 2.59. Invocation command line was $ /usr/local/GCC/GCC-4.4.2/gcc-4.4.2/libgfortran/configure --cache-file=./config.cache --enable-multilib --prefix=/usr/local/GCC/gcc-4.4.2 --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-gmp=/usr/local --with-mpfr=/usr/local --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --program-transform-name=s,y,y, --with-target-subdir=i686-pc-linux-gnu --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu --srcdir=/usr/local/GCC/GCC-4.4.2/gcc-4.4.2/libgfortran ## - ## ## Platform. ## ## - ## hostname = al7-centsos uname -m = i686 uname -r = 2.6.18-164.el5 uname -s = Linux uname -v = #1 SMP Thu Sep 3 03:33:56 EDT 2009 /usr/bin/uname -p = unknown /bin/uname -X = unknown /bin/arch = i686 /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /usr/local/GCC/gcc-4.4.1/bin PATH: /home/delaunay/public/share/ec PATH: /home/delaunay/public/share/ec PATH: /home/delaunay/public/share/ec PATH: /usr/lib/qt-3.3/bin PATH: /usr/kerberos/bin PATH: /usr/local/bin PATH: /usr/bin PATH: /bin PATH: /usr/X11R6/bin PATH: /home/delaunay/bin PATH: /opt/Adobe/Reader9/bin PATH: /home/delaunay/bin PATH: /home/delaunay/bin ... configure:12084: checking if /usr/local/GCC/GCC-4.4.2/i686-gcc-4.4.2/./gcc/gfortran -B/usr/local/GCC/GCC-4.4.2/i686-gcc-4.4.2/./gcc/ -B/usr/local/GCC/gcc-4.4.2/i686-pc-linux-gnu/bin/ -B/usr/local/GCC/gcc-4.4.2/i686-pc-linux-gnu/lib/ -isystem /usr/local/GCC/gcc-4.4.2/i686-pc-linux-gnu/include -isystem /usr/local/GCC/gcc-4.4.2/i686-pc-linux-gnu/sys-include supports -c -o file.o configure:12105: /usr/local/GCC/GCC-4.4.2/i686-gcc-4.4.2/./gcc/gfortran -B/usr/local/GCC/GCC-4.4.2/i686-gcc-4.4.2/./gcc/ -B/usr/local/GCC/gcc-4.4.2/i686-pc-linux-gnu/bin/ -B/usr/local/GCC/gcc-4.4.2/i686-pc-linux-gnu/lib/ -isystem /usr/local/GCC/gcc-4.4.2/i686-pc-linux-gnu/include -isystem /usr/local/GCC/gcc-4.4.2/i686-pc-linux-gnu/sys-include -c -o out/conftest2.o conftest.f 5 /usr/local/GCC/GCC-4.4.2/i686-gcc-4.4.2/./gcc/f951: symbol lookup error: /usr/lib/libmpfr.so.1: undefined symbol: __gmp_get_memory_functions configure:12109: $? = 1 configure:12131: result: no configure:12136: checking if /usr/local/GCC/GCC-4.4.2/i686-gcc-4.4.2/./gcc/gfortran -B/usr/local/GCC/GCC-4.4.2/i686-gcc-4.4.2/./gcc/ -B/usr/local/GCC/gcc-4.4.2/i686-pc-linux-gnu/bin/ -B/usr/local/GCC/gcc-4.4.2/i686-pc-linux-gnu/lib/ -isystem /usr/local/GCC/gcc-4.4.2/i686-pc-linux-gnu/include -isystem /usr/local/GCC/gcc-4.4.2/i686-pc-linux-gnu/sys-include supports -c -o file.o configure:12183: result: no configure:12213: checking whether the /usr/local/GCC/GCC-4.4.2/i686-gcc-4.4.2/./gcc/gfortran -B/usr/local/GCC/GCC-4.4.2/i686-gcc-4.4.2/./gcc/ -B/usr/local/GCC/gcc-4.4.2/i686-pc-linux-gnu/bin/
[Bug libfortran/41760] Problem with configure when using --with-gmp and --with-mpfr
--- Comment #1 from Michel dot Delaunay at imag dot fr 2009-10-20 06:04 --- Created an attachment (id=18829) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18829action=view) the config.log file produced when configure ``libfortran'' configure:14173: checking whether the GNU Fortran compiler is working configure:14187: /usr/local/GCC/GCC-4.4.2/i686-gcc-4.4.2/./gcc/gfortran -B/usr/local/GCC/GCC-4.4.2/i686-gcc-4.4.2/./gcc/ -B/usr/local/GCC/gcc-4.4.2/i686-pc-linux-gnu/bin/ -B/usr/local/GCC/gcc-4.4.2/i686-pc-linux-gnu/lib/ -isystem /usr/local/GCC/gcc-4.4.2/i686-pc-linux-gnu/include -isystem /usr/local/GCC/gcc-4.4.2/i686-pc-linux-gnu/sys-include -c conftest.f 5 /usr/local/GCC/GCC-4.4.2/i686-gcc-4.4.2/./gcc/f951: symbol lookup error: /usr/lib/libmpfr.so.1: undefined symbol: __gmp_get_memory_functions configure:14193: $? = 1 configure: failed program was: | | program foo | real, parameter :: bar = sin (12.34 / 2.5) | end program foo configure:14214: result: no configure:14216: error: GNU Fortran is not working; please report a bug in http://gcc.gnu.org/bugzilla, attaching /usr/local/GCC/GCC-4.4.2/i686-gcc-4.4.2/i686-pc-linux-gnu/libgfortran/config.log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41760
[Bug rtl-optimization/41574] Distribute floating point expressions causes bad code [4.4 only]
--- Comment #10 from dougkwan at google dot com 2009-10-20 06:22 --- (In reply to comment #9) (In reply to comment #8) This is fixed in trunk but at least gcc-4.4.0, where this bug was found, is still broken. I have no approval rights but can you test ask to backport this to 4.4 branch after the freeze for the 4.4.2 release is lifted ? Sorry about the late reply. Yes, I can prepare a fix for 4.4.2 -Doug -- dougkwan at google dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dougkwan at google dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41574
[Bug target/40503] DEC_EVAL_METHOD not match operators
--- Comment #3 from tydeman at tybor dot com 2009-10-20 06:25 --- In 4.4.1, it appears that the type of the LHS in LHS = RHS determines how the RHS is evaluated. If the RHS involves only _Decimal32 types, then the RHS will be evaluated to the type of the LHS (_Decimal32, 64, or 128). That behavoiur is not what C99 wants. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40503
[Bug lto/41761] New: lto1: error: type mismatch in component reference (const with non-const)
$ ~/inst/bin/gcc -v Using built-in specs. COLLECT_GCC=/home/edwin/inst/bin/gcc COLLECT_LTO_WRAPPER=/home/edwin/inst/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --enable-lto --enable-languages=c,c++ --enable-gold Thread model: posix gcc version 4.5.0 20091019 (experimental) (GCC) gcc -flto fails to compile ClamAV when built with --disable-shared, I reduced the problem to these two files: $ /home/edwin/inst/bin/gcc -flto 7z.i -o 7z.o -c $ /home/edwin/inst/bin/gcc -flto 7zIn.i -o 7zIn.o -c $ /home/edwin/inst/bin/gcc 7z.o 7zIn.o -flto -shared -use-linker-plugin In function SzArEx_GetFolderFullPackSize: lto1: error: type mismatch in component reference const struct CSzAr struct CSzAr D.1996_3 = p_2(D)-db.Folders; lto1: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: /home/edwin/inst/bin/gcc returned 1 exit status /usr/bin/ld: fatal error: lto-wrapper failed collect2: ld returned 1 exit status -- Summary: lto1: error: type mismatch in component reference (const with non-const) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edwintorok at gmail dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41761
[Bug lto/41761] lto1: error: type mismatch in component reference (const with non-const)
--- Comment #1 from edwintorok at gmail dot com 2009-10-20 07:05 --- Created an attachment (id=18830) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18830action=view) reduced testcase reduced testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41761
[Bug target/41722] internal compiler error / unable to generate reloads
--- Comment #4 from ramana at gcc dot gnu dot org 2009-10-20 07:29 --- Marking it as P4 because arm-linux is effectively in maintenance only mode. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P4 Last reconfirmed|-00-00 00:00:00 |2009-10-20 07:29:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41722
[Bug libstdc++/38875] parallel fill and copy in the parallel version of libstdc++
--- Comment #5 from singler at gcc dot gnu dot org 2009-10-20 07:37 --- I'm investigating the problem. In the meantime, you might want to abuse std::for_each for this task. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38875
[Bug libstdc++/40852] [parallel-mode] parallel sort run time increases ~10 fold when vector size gets over ~4*10^9
--- Comment #7 from singler at gcc dot gnu dot org 2009-10-20 07:46 --- Sorry, the CC has never reached me. So concerning comment #4: Was the parallel mode actually activated? The multiway mergesort takes another time the space of the input as temporarily. Sure that the program was not swapping? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40852
[Bug libfortran/41760] Problem with configure when using --with-gmp and --with-mpfr
--- Comment #2 from burnus at gcc dot gnu dot org 2009-10-20 07:51 --- Disclaimer: I do not know what ./configure does with regards to library search paths. --with-mpfr=/usr/local /usr/lib/libmpfr.so.1: undefined symbol: __gmp_get_memory_functions Seemingly, the /usr/lib and not the /usr/local/lib version is used. Frankly, I do not know how exactly --with-mpfr works, but I think the path is only used for compiling and not for running the compiled programs. Thus when running gfortran (which happens when building the libgfortran library), the wrong shared library is picked up. Does setting the LD_LIBRARY_PATH help? I mean: if [ -z $LD_LIBRARY_PATH ]; then LD_LIBRARY_PATH=/usr/local/lib else LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH fi export LD_LIBRARY_PATH At least in case of the finally installed version you need to set LD_LIBRARY_PATH - otherwise you have the same problem: The wrong library is picked up. Though, I am surprised that /usr/lib is used; I think most linux distributions set /etc/ld.so.conf such that /usr/local/lib comes before /usr/lib. If you have newly installed the GMP/MPFR in /usr/local/lib, maybe running ldconfig helps? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41760
[Bug lto/41756] LTO: -flto -O1 linking files compiled with -fno-exceptions with ones compiled with exceptions yields error BB 14 can not throw but has an EH edge
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-10-20 09:35 --- Even that would be difficult - how would you inline between such functions? I think the only way is to force -fexceptions during the link stage if one translation unit did have it enabled. The -fno-exception TUs should have all stmts marked as not throwing. Sort of, but well - this is a very low priority bug. (Falls into the class of different flags used for compiling and linking) I'll try a very simple hack. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|LTO: -flto -O1 -use-linker- |LTO: -flto -O1 linking files |plugin, linking files |compiled with -fno- |compiled with -fno- |exceptions with ones |exceptions with ones|compiled with exceptions |compiled with exceptions|yields error BB 14 can not |yields error BB 14 can not |throw but has an EH edge |throw but has an EH edge | Version|unknown |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41756
[Bug debug/41340] [4.5 Regression] G++ produces different code with and without -g option
--- Comment #10 from jakub at gcc dot gnu dot org 2009-10-20 09:39 --- Created an attachment (id=18832) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18832action=view) gcc45-pr41340.patch Patch I'm going to bootstrap/regtest. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41340
[Bug middle-end/41762] New: internal compiler error when compiling xorg-server
Command line: gcc -O2 -march=pentium2 -ftracer -fsched2-use-superblocks -freorder-blocks-and-partition -fpic -c -o xkbInit.o xkbInit.i results in: xkbInit.c: In function 'XkbWriteRulesProp': xkbInit.c:231:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://bugs.gentoo.org/ for instructions. Tested gcc versions: i686 gcc-4.4.2 (gentoo) crash x86_64 gcc-4.4.2 (gentoo) crash x86_64 gcc-4.4.3 (svn, 4.4 branch, r152990) crash x86_64 gcc-4.5.0-alpha20090903 (gentoo) crash i686 gcc-4.5.0-alpha20091001 (gentoo) OK (fixed or hidden?) x86_64 gcc-4.5.0-alpha20091006 (from svn) OK (x86_64 compiler needs -m32) -- Summary: internal compiler error when compiling xorg-server Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zsojka at seznam dot cz GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41762
[Bug middle-end/41762] internal compiler error when compiling xorg-server
--- Comment #1 from zsojka at seznam dot cz 2009-10-20 10:11 --- Created an attachment (id=18833) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18833action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41762
[Bug tree-optimization/41740] [4.5 Regression] ICE in ipcp_analyze_node, at ipa-cp.c:183
--- Comment #8 from jamborm at gcc dot gnu dot org 2009-10-20 10:11 --- This looks like PR 40556. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added CC|mjambor at suse dot cz |jamborm at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41740
[Bug middle-end/41762] internal compiler error when compiling xorg-server
--- Comment #2 from zsojka at seznam dot cz 2009-10-20 10:12 --- Created an attachment (id=18834) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18834action=view) reduced testcase (by delta), only 4.4 crashes gcc-4.5.0-alpha20090903 doesn't crash with this testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41762
[Bug lto/41761] lto1: error: type mismatch in component reference (const with non-const)
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-10-20 10:16 ---
Confirmed.
--- t1.i
typedef struct {
int NumPackStreams;
} CSzAr;
void cli_7unz (CSzAr db) { }
--- t2.i
typedef struct {
int NumPackStreams;
} CSzAr;
typedef struct {
CSzAr db;
} CSzArEx;
int SzArEx_Init(CSzArEx *p)
{
return p-db.NumPackStreams;
}
int SzArEx_GetFolderFullPackSize(const CSzArEx *p)
{
return p-db.NumPackStreams;
}
./xgcc -B. -fPIC -flto rr/7z.i rr/7zIn.i -shared
In function 'SzArEx_GetFolderFullPackSize':
lto1: error: type mismatch in component reference
const struct CSzAr
struct CSzAr
D.1891_2 = p_1(D)-db.NumPackStreams;
lto1: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
ordering is important.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-10-20 10:16:04
date||
Version|unknown |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41761
[Bug libstdc++/40852] [parallel-mode] parallel sort run time increases ~10 fold when vector size gets over ~4*10^9
--- Comment #8 from jaffe at broadinstitute dot org 2009-10-20 10:55 --- Subject: Re: [parallel-mode] parallel sort run time increases ~10 fold when vector size gets over ~4*10^9 Regarding comment #7, I just ran this now on a machine with 32 processors and 512 GB memory. (a) Sorting 4 x 10^9 ints took 0.9 minutes. (b) Sorting 5 x 10^9 ints took 16 minutes. The second test used about 40 GB, which is a small fraction of the available memory. (c) Sorting 2.5 x 10^9 structures having 2 ints each took 1.1 minutes. Regarding comment #6, repeating (a) and (b) with __gnu_parallel::balanced_quicksort_tag( ): (a') 6.3 minutes (b') 8.1 minutes, so the algorithm is slower on these data but does not exhibit the same jump in runtime. I also tried __gnu_parallel::quicksort_tag( ) which was about the same for (b) [(a) not tested]. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40852
[Bug lto/41761] lto1: error: type mismatch in component reference (const with non-const)
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-10-20 11:04 --- I have a patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-10-20 10:16:04 |2009-10-20 11:04:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41761
[Bug fortran/41706] [OOP] Calling one TBP as an actual argument of another TBP
--- Comment #3 from janus at gcc dot gnu dot org 2009-10-20 11:30 --- Reopening. Salvatore's code still fails with the same error, which is due to the analogous case with a subroutine: module m type :: t contains procedure, nopass :: a procedure, nopass :: b end type contains subroutine a (x) real :: x print *,x end subroutine real function b () b = 3. end function subroutine s class(t),allocatable :: x real :: r allocate(x) call x%a(x%b()) ! fails end subroutine end -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41706
[Bug fortran/41706] [OOP] Calling one TBP as an actual argument of another TBP
--- Comment #4 from paul dot richard dot thomas at gmail dot com 2009-10-20 12:19 --- Subject: Re: [OOP] Calling one TBP as an actual argument of another TBP Oh bother! I completely forgot to test the subroutine branch - thanks Janus On Tue, Oct 20, 2009 at 1:30 PM, janus at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #3 from janus at gcc dot gnu dot org 2009-10-20 11:30 --- Reopening. Salvatore's code still fails with the same error, which is due to the analogous case with a subroutine: module m type :: t contains procedure, nopass :: a procedure, nopass :: b end type contains subroutine a (x) real :: x print *,x end subroutine real function b () b = 3. end function subroutine s class(t),allocatable :: x real :: r allocate(x) call x%a(x%b()) ! fails end subroutine end -- janus at gcc dot gnu dot org changed: What |Removed |Added Status|RESOLVED |UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41706 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41706
[Bug fortran/41706] [OOP] Calling one TBP as an actual argument of another TBP
--- Comment #5 from janus at gcc dot gnu dot org 2009-10-20 12:29 --- (In reply to comment #4) Oh bother! I completely forgot to test the subroutine branch - thanks Janus But in your patch you do the argument resolution both in resolve_class_compcall and resolve_class_typebound_call, which should take care of type-bound functions *and* subroutines, shouldn't it? Therefore I don't see why it still fails for subroutines ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41706
[Bug bootstrap/41491] [4.5 regression] ICE in set_value_range, at tree-vrp.c:386
--- Comment #5 from rmansfield at qnx dot com 2009-10-20 13:02 --- Created an attachment (id=18835) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18835action=view) preprocessed source from gcc 4.3.3 Reproduced using gcc version 4.5.0 20091003 (experimental) [trunk revision 152434] (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41491
[Bug debug/41340] [4.5 Regression] G++ produces different code with and without -g option
--- Comment #11 from jakub at gcc dot gnu dot org 2009-10-20 13:29 --- Subject: Bug 41340 Author: jakub Date: Tue Oct 20 13:29:08 2009 New Revision: 153011 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153011 Log: PR debug/41340 * loop-invariant.c (calculate_loop_reg_pressure): Don't count regs referenced just in DEBUG_INSNs. * gcc.dg/pr41340.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr41340.c Modified: trunk/gcc/ChangeLog trunk/gcc/loop-invariant.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41340
[Bug lto/41761] lto1: error: type mismatch in component reference (const with non-const)
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-10-20 13:33 --- Subject: Bug 41761 Author: rguenth Date: Tue Oct 20 13:33:03 2009 New Revision: 153012 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153012 Log: 2009-10-20 Richard Guenther rguent...@suse.de PR lto/41761 * gimple.c (gimple_register_type): Make sure we register the types main variant first. * gcc.dg/lto/20091020-1_0.c: New testcase. * gcc.dg/lto/20091020-1_1.c: Likewise. * gcc.dg/lto/20091020-2_0.c: Likewise. * gcc.dg/lto/20091020-2_1.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/lto/20091020-1_0.c trunk/gcc/testsuite/gcc.dg/lto/20091020-1_1.c trunk/gcc/testsuite/gcc.dg/lto/20091020-2_0.c trunk/gcc/testsuite/gcc.dg/lto/20091020-2_1.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41761
[Bug lto/41761] lto1: error: type mismatch in component reference (const with non-const)
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-10-20 13:33 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41761
[Bug libfortran/41760] Problem with configure when using --with-gmp and --with-mpfr
--- Comment #3 from kargl at gcc dot gnu dot org 2009-10-20 14:02 --- Remove the version of gmp in/usr/lib and /usr/include. This isn't a gfortran problem. It is a user's system configuration problem. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41760
[Bug libstdc++/41763] New: valarray_array.h seems to overuse __restrict__
inline static void
_S_do_it(_Tp* __restrict__ __b, _Tp* __restrict__ __e)
{
while (__b != __e)
new(__b++) _Tp();
}
is invalid, the __restrict__ keywords say that __b and __e point to different
objects and you can't compare pointers to different objects.
--
Summary: valarray_array.h seems to overuse __restrict__
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41763
[Bug bootstrap/41491] [4.5 regression] ICE in set_value_range, at tree-vrp.c:386
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-10-20 14:07 --- Works for me (x86_64, -O2). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41491
[Bug debug/41340] [4.5 Regression] G++ produces different code with and without -g option
--- Comment #12 from jakub at gcc dot gnu dot org 2009-10-20 14:32 --- The original rtl.ii.gz testcase compiles just fine with -fcompare-debug too (though, it surely used to be something different, as those loop-invariant.c changes are from end of September). -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41340
[Bug lto/41764] New: Bogus errors from gold with linker-plugin
PROGRAM INIRAN INTEGER IX, IY, IZ COMMON /XXXRAN/ IX, IY, IZ END BLOCKDATA RAEWIN INTEGER IX, IY, IZ COMMON /XXXRAN/ IX, IY, IZ DATA IX, IY, IZ / 1974, 235, 337 / END gfortran -c ranewr.f -flto gfortran ranewr.o -flto -use-linker-plugin /usr/bin/gold: error: ranewr.o: multiple definition of iz /usr/bin/gold: error: ranewr.o: previous definition here /usr/bin/gold: error: ranewr.o: multiple definition of iy /usr/bin/gold: error: ranewr.o: previous definition here /usr/bin/gold: error: ranewr.o: multiple definition of ix /usr/bin/gold: error: ranewr.o: previous definition here -- Summary: Bogus errors from gold with linker-plugin Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: lto 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=41764
[Bug lto/41761] lto1: error: type mismatch in component reference (const with non-const)
--- Comment #7 from edwintorok at gmail dot com 2009-10-20 15:06 --- (In reply to comment #6) Fixed. Thanks, I can now successfully build ClamAV with lto. -- edwintorok at gmail dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41761
[Bug debug/41739] [4.5 Regression] Failed to bootstrap on Linux/ia64
--- Comment #2 from jakub at gcc dot gnu dot org 2009-10-20 15:09 --- Subject: Bug 41739 Author: jakub Date: Tue Oct 20 15:09:43 2009 New Revision: 153017 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153017 Log: PR debug/41739 * haifa-sched.c (try_ready): Skip debug deps updating speculation status. Modified: trunk/gcc/ChangeLog trunk/gcc/haifa-sched.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41739
[Bug target/39247] FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE
--- Comment #12 from rearnsha at gcc dot gnu dot org 2009-10-20 15:18 --- Subject: Bug 39247 Author: rearnsha Date: Tue Oct 20 15:17:30 2009 New Revision: 153018 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153018 Log: PR target/39247 * arm.c (arm_override_options): Forcibly disable hot/cold block partitioning. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39247
[Bug target/39247] FAIL: gcc.dg/tree-prof/bb-reorg.c compilation, -fprofile-use -D_PROFILE_USE
--- Comment #13 from rearnsha at gcc dot gnu dot org 2009-10-20 15:25 --- Fixed on trunk. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39247
[Bug fortran/41765] New: ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1702
The attached program gives an ICE with an older 4.5 gfortran. I try to test it later with today's build as it might well have been fixed in the meanwhile. $ gfortran -O3 -c test.f90 test.f90: In function 'genpmat': test.f90:1: internal compiler error: in set_ssa_val_to, at tree-ssa-sccvn.c:1702 -- Summary: ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1702 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41765
[Bug fortran/41765] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1702
--- Comment #1 from burnus at gcc dot gnu dot org 2009-10-20 15:52 --- Created an attachment (id=18836) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18836action=view) Test case, might be fixed with PR 40328 Presumably a duplicate of PR 40328. But for completeness, here is the reduced code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41765
[Bug fortran/41765] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1702
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-10-20 15:56 --- Works for me with todays trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41765
[Bug java/28474] mangle_name.c mangles names unecessarily
--- Comment #3 from aph at gcc dot gnu dot org 2009-10-20 16:01 --- Subject: Bug 28474 Author: aph Date: Tue Oct 20 16:01:21 2009 New Revision: 153021 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153021 Log: 2009-10-20 Joel Dice di...@mailsnare.net PR java/28474 * mangle_name.c (append_unicode_mangled_name): Fix mangling of names with multiple underscores and U. (unicode_mangling_length): Likewise. Modified: trunk/gcc/java/ChangeLog trunk/gcc/java/mangle_name.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28474
[Bug libstdc++/41763] valarray_array.h seems to overuse __restrict__
--- Comment #1 from paolo dot carlini at oracle dot com 2009-10-20 16:32 --- I think this line, in general all the uses of __restrict__ in valarray are *very* old... Let's CC Gaby, in case he has some comments. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||gdr at cs dot tamu dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41763
[Bug libstdc++/41763] valarray_array.h seems to overuse __restrict__
--- Comment #2 from gdr at cs dot tamu dot edu 2009-10-20 16:42 --- Subject: Re: valarray_array.h seems to overuse __restrict__ paolo dot carlini at oracle dot com gcc-bugzi...@gcc.gnu.org writes: | I think this line, in general all the uses of __restrict__ in valarray are | *very* old... Let's CC Gaby, in case he has some comments. Hi Paolo, Thanks for letting me know what is going on. Yes, you're right that use of __restrict__ dates back from era where the compiler was a bit weak and things had to be written certain way. The function can be safely changed (and similar uses should be fixed too.) -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41763
[Bug fortran/41766] New: [OOP] SELECT TYPE selector as actual argument with INTENT(INOUT)
Test case: implicit none type t1 integer :: a end type type, extends(t1) :: t2 integer :: b end type class(t1),pointer :: cp allocate(t2 :: cp) select type (cp) type is (t2) call s(cp) end select contains subroutine s(f) type(t2), intent(inout) :: f end subroutine end This fails with: call s(cp) 1 Error: Actual argument at (1) must be definable as the dummy argument 'f' is INTENT = OUT/INOUT -- Summary: [OOP] SELECT TYPE selector as actual argument with INTENT(INOUT) Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41766
[Bug fortran/41765] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1702
--- Comment #3 from burnus at gcc dot gnu dot org 2009-10-20 17:14 ---
Probably indeed PR 40328 - at least it works at home. Close as WORKSFORME.
(I really hate the half-broken (broken lib dependency for some
/usr/{,local}/bin files) and darn old (Fedora 6) system at work!)
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||WORKSFORME
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41765
[Bug fortran/41766] [OOP] SELECT TYPE selector as actual argument with INTENT(INOUT)
--- Comment #1 from janus at gcc dot gnu dot org 2009-10-20 17:17 --- Mine. Preliminary patch: Index: gcc/fortran/match.c === --- gcc/fortran/match.c (Revision 153009) +++ gcc/fortran/match.c (Arbeitskopie) @@ -4047,9 +4047,10 @@ select_type_set_tmp (gfc_typespec *ts) sprintf (name, tmp$%s, ts-u.derived-name); gfc_get_sym_tree (name, gfc_current_ns, tmp, false); - tmp-n.sym-ts = *ts; - tmp-n.sym-attr.referenced = 1; - tmp-n.sym-attr.pointer = 1; + gfc_add_type (tmp-n.sym, ts, NULL); + gfc_set_sym_referenced (tmp-n.sym); + gfc_add_pointer (tmp-n.sym-attr, NULL); + gfc_add_flavor (tmp-n.sym-attr, FL_VARIABLE, name, NULL); select_type_stack-tmp = tmp; } The important thing here is 'gfc_add_flavor'. The other three lines are just rewritten, but still do the same thing. -- janus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-10-20 17:17:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41766
[Bug libstdc++/41763] valarray_array.h seems to overuse __restrict__
--- Comment #3 from paolo dot carlini at oracle dot com 2009-10-20 17:28 --- Thanks Gaby. Thus, if I understand the issue correctly, we have to be less aggressive about __restrict__ and make sure we don't use it when we compare pointers to different objects. I can work on the change. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-10-20 17:28:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41763
[Bug libstdc++/41763] valarray_array.h seems to overuse __restrict__
--- Comment #4 from jakub at gcc dot gnu dot org 2009-10-20 17:48 --- Well, make sure we don't use it when two different pointers point into the same object. As in this example, both __b and __e are begin and end pointers within the same object or one byte after the end of it. And __restrict__ must not be used in that case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41763
[Bug lto/41767] New: assertion in tree-sra.c
To reproduce: cc1 c-typeck.i -quiet -O2 -flto -o c-typeck.s cc1 c-parser.i -quiet -O2 -flto -o c-parser.s as -o c-typeck.o c-typeck.s as -o c-parser.o c-parser.s lto1 -O2 c-typeck.o c-parser.o -o /dev/null -- Summary: assertion in tree-sra.c Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: espindola at gcc dot gnu dot org GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41767
[Bug lto/41767] assertion in tree-sra.c
--- Comment #1 from espindola at gcc dot gnu dot org 2009-10-20 17:54 --- Created an attachment (id=18837) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18837action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41767
[Bug lto/41767] assertion in tree-sra.c
--- Comment #2 from espindola at gcc dot gnu dot org 2009-10-20 17:55 --- Created an attachment (id=18838) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18838action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41767
[Bug lto/41767] assertion in tree-sra.c
--- Comment #3 from espindola at gcc dot gnu dot org 2009-10-20 17:55 --- Created an attachment (id=18839) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18839action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41767
[Bug lto/41767] assertion in tree-sra.c
--- Comment #4 from espindola at gcc dot gnu dot org 2009-10-20 17:55 --- Created an attachment (id=18840) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18840action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41767
[Bug bootstrap/41491] [4.5 regression] ICE in set_value_range, at tree-vrp.c:386
--- Comment #7 from rmansfield at qnx dot com 2009-10-20 17:56 --- I wasn't able to reproduce the issue with i686-pc-linux-gnu either but the ICE happens with arm-unknown-linux-gnu/arm-unknown-nto-qnx6.4.0 as well. mips-unknown-nto-qnx6.4.0 and sh4-unknown-nto-qnx6.4.0 configurations seemed to be OK. I tested with GNU C (GCC) version 4.5.0 20091020 (experimental) [trunk revision 153012] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41491
[Bug libgcj/41768] New: [regression] build failue in java component.
I configured with default CFLAGS and with: $ ../gcc/configure --host=i686-pc-linux-gnu --prefix=/usr --with-gnu-as --enable-shared --with-gnu-ld --enable-threads=posix --with-ecj-jar=/usr/share/java/ecj.jar --enable-languages=c,c++,fortran,java,objc The java component of the build dies with: libtool: compile: /home/ronis/objdir/./gcc/xgcc -shared-libgcc -B/home/ronis/objdir/./gcc -nostdinc++ -L/home/ronis/objdir/i686-pc-linux-gnu/libstdc++-v3/src -L/home/ronis/objdir/i686-pc-linux-gnu/libstdc++-v3/src/.libs -B/usr/i686-pc-linux-gnu/bin/ -B/usr/i686-pc-linux-gnu/lib/ -isystem /usr/i686-pc-linux-gnu/include -isystem /usr/i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc/libjava -I./include -I./gcj -I../../../gcc/libjava -Iinclude -I../../../gcc/libjava/include -I../../../gcc/libjava/classpath/include -Iclasspath/include -I../../../gcc/libjava/classpath/native/fdlibm -I../../../gcc/libjava/../boehm-gc/include -I../boehm-gc/include -I../../../gcc/libjava/libltdl -I../../../gcc/libjava/libltdl -I../../../gcc/libjava/.././libjava/../gcc -I../../../gcc/libjava/../zlib -I../../../gcc/libjava/../libffi/include -I../libffi/include -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 -ffloat-store -fomit-frame-pointer -Usun -Wextra -Wall -D_GNU_SOURCE -DPREFIX=\/usr\ -DTOOLEXECLIBDIR=\/usr/lib\ -DJAVA_HOME=\/usr\ -DBOOT_CLASS_PATH=\/usr/share/java/libgcj-4.4.2.jar\ -DJAVA_EXT_DIRS=\/usr/share/java/ext\ -DGCJ_ENDORSED_DIRS=\/usr/share/java/gcj-endorsed\ -DGCJ_VERSIONED_LIBDIR=\/usr/lib/gcj-4.4.2-10\ -DPATH_SEPARATOR=\:\ -DECJ_JAR_FILE=\/usr/share/java/ecj.jar\ -DLIBGCJ_DEFAULT_DATABASE=\/usr/lib/gcj-4.4.2-10/classmap.db\ -DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\gcj-4.4.2-10/classmap.db\ -g -O2 -D_GNU_SOURCE -MT posix-threads.lo -MD -MP -MF .deps/posix-threads.Tpo -c ../../../gcc/libjava/posix-threads.cc -o posix-threads.o /dev/null 21 here=`pwd`; cd ../../../gcc/libjava/classpath/lib; \ find gnu java javax org sun -name .svn -prune -o -name '*.class' -print | \ gjar -cfM@ $here/libgcj-4.4.2.jar jar: internal error: java.lang.NullPointerException at gnu.classpath.tools.jar.Creator.writeCommandLineEntries(libgcj-tools.so.10) at gnu.classpath.tools.jar.Creator.run(libgcj-tools.so.10) at gnu.classpath.tools.jar.Main.run(libgcj-tools.so.10) at gnu.classpath.tools.jar.Main.main(libgcj-tools.so.10) make[3]: *** [libgcj-4.4.2.jar] Error 1 make[3]: Leaving directory `/home/ronis/objdir/i686-pc-linux-gnu/libjava' This worked on another machine, so I'm not sure that the problem isn't related to my setup here. I'm running on a HP pavilion laptop, with slackware 12.2. I'm also wondering if this might have something to do with an earlier bug I reported: GCC Bugzilla Bug 41472 -- Summary: [regression] build failue in java component. Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: critical Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ronis at ronispc dot chem dot mcgill dot ca http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41768
[Bug libgcj/41768] [regression] build failue in java component.
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-10-20 17:59 --- The gjar you have installed is broken. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41768
[Bug middle-end/41750] gcc 4.5.0 miscompiles binutils
--- Comment #12 from rainer at emrich-ebersheim dot de 2009-10-20 18:04 --- First of all, it's nearly impossible to create a short self contained test case, at least for me. The function get_got in bfd/elf64-ia64.c shows the issue. Resolving the dependencies of this function is like opening a can of worms. What I have: I verified that enclosing only the get_got function in #pragma GCC optimize (ipa-sra, no-inline) . . #pragma GCC reset_options yields the fault. In contrast enclosing the get_got function in #pragma GCC optimize (no-ipa-sra, no-inline) . . #pragma GCC reset_options gives a working ia64-unknown-linux-gnu-ld. I'm attaching both versions as preprocessed source. compiling these with gcc -g -O2 -S produces the correspondent assembler output, also attached. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41750
[Bug libgcj/41768] [regression] build failue in java component.
--- Comment #2 from ronis at ronispc dot chem dot mcgill dot ca 2009-10-20 18:06 --- Shouldn't gjar be built (and used) by the bootstrap build? It seems that it was: find -name gjar -ls 41083574 -rwxr-xr-x 1 ronisronis2048 Oct 20 02:27 ./i686-pc-linux-gnu/libjava/classpath/tools/gjar There is a system installed one from my last gcc build. So, if this is broken, there's still a problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41768
[Bug libstdc++/41763] valarray_array.h seems to overuse __restrict__
--- Comment #5 from paolo dot carlini at oracle dot com 2009-10-20 18:12 --- Ok, thanks, now I have a better picture. As a matter of fact, in *most* of the cases we should be *only* comparing pointers to the same object, I think this is the only case guaranteed to behave sanely under the current C++ rules (std::equal co are more general). Thus, to summarize: __restrict__ normally should appear only for pointers not compared at all, please correct me if I'm wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41763
[Bug middle-end/41750] gcc 4.5.0 miscompiles binutils
--- Comment #13 from rainer at emrich-ebersheim dot de 2009-10-20 18:13 --- Created an attachment (id=18841) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18841action=view) preproccessed source no-ipa-sra, no-inline -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41750
[Bug middle-end/41750] gcc 4.5.0 miscompiles binutils
--- Comment #14 from rainer at emrich-ebersheim dot de 2009-10-20 18:14 --- Created an attachment (id=18842) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18842action=view) preproccessed source ipa-sra, no-inline -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41750
[Bug middle-end/41750] gcc 4.5.0 miscompiles binutils
--- Comment #15 from rainer at emrich-ebersheim dot de 2009-10-20 18:15 --- Created an attachment (id=18843) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18843action=view) assembler output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41750
[Bug middle-end/41750] gcc 4.5.0 miscompiles binutils
--- Comment #16 from rainer at emrich-ebersheim dot de 2009-10-20 18:16 --- Created an attachment (id=18844) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18844action=view) assembler output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41750
[Bug c++/41769] New: Parameter names not restricted to identifiers
GCC compiles and runs this code correctly:
void f(void operator+()) { operator+(); }
void g() { }
int main() { f(g); }
It should reject the parameter name, because operator+ is not an identifier.
--
Summary: Parameter names not restricted to identifiers
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schaub-johannes at web dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41769
[Bug middle-end/41770] New: graphite miscompiles 434.zeusmp of the SPEC 2k6
On the test data set, (not the ref data set) of 434.zeusmp there is a miscompare when using -fgraphite-identity. This failure appeared with my patch to handle reductions: Rewrite reductions out of SSA. 2009-07-28 Sebastian Pop sebastian@amd.com * graphite-sese-to-poly.c (loop_entry_phi_arg): New. (remove_simple_copy_phi): New. (remove_invariant_phi): New. (simple_copy_phi_p): New. (reduction_phi_p): New. (gsi_for_ssa_name_def): New. (insert_out_of_ssa_copy): New. (insert_out_of_ssa_copy_on_edge): New. (create_zero_dim_array): New. (scalar_close_phi_node_p): New. (rewrite_close_phi_out_of_ssa): New. (rewrite_phi_out_of_ssa): New. (rewrite_reductions_out_of_ssa): New. (build_poly_scop): Call rewrite_reductions_out_of_ssa. The kernel that is miscompiled looks like this: subroutine diverg ( isum, div, sumd ) integer in, jn, kn parameter(in = 128+5 , jn = 128+5 , kn = 128+5) integer is, ie, js, je, ks, ke common /gridcomi/ is, ie, js, je, ks, ke integer i , j , k real*8 div ( in, jn, kn) sumd = 0.0 if (isum .eq. 1) then do 60 k=ks,ke do 50 j=js,je do 40 i=is,ie sumd = sumd + div(i,j,k) 40 continue 50 continue 60 continue endif return end -- Summary: graphite miscompiles 434.zeusmp of the SPEC 2k6 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: spop at gcc dot gnu dot org ReportedBy: spop at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41770
[Bug middle-end/41770] graphite miscompiles 434.zeusmp of the SPEC 2k6
-- spop at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-10-20 18:56:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41770
[Bug bootstrap/41771] New: Bootstrap with Sun Studio 12.1 fails
I suppose mainline is affected as well, but I've first got a report about this and tested on GCC 4.4.2. Bootstrapping GCC 4.4.2 on Solaris 11/SPARC and Solaris 10/x86 with Sun Studio 12.1 fails in stage 1 linking xgcc: Undefined first referenced symbol in file __gmpn_perfect_square_p gcc.o __gmpz_tdiv_q gcc.o __gmpq_set gcc.o __gmpz_set gcc.o __gmpn_add_ngcc.o __gmpn_sub_ngcc.o __gmpn_popcount gcc.o ld: fatal: Symbol referencing errors. No output written to xgcc Re-running the gcc.o build with -E reveals that e.g. the reference to __gmpn_perfect_square_p is from __gmpz_perfect_square_p which is *defined* as extern in the header, although __GMP_EXTERN_INLINE is correctly defined in gmp.h for __SUNPRO_C = 0x560 (this is 0x5100 for Studio 12.1). It turned out that ansidecl.h was the culprit: the current file assumes that inline is a keyword #if __STDC_VERSION__ 199901L which is wrong: C99 defines __STDC_VERSION__ as 199901L, so the test should be for = instead as in several other places in GCC. But even this doesn't help: Sun cc only defines it in C99 mode (quelle surprise :-), but trying to bootstrap GCC with cc -xc99 or c99 breaks in other places (headers require e.g. -D_XOPEN_SOURCE=0x600 with c99), so I chose to use another test: #if (__STDC_VERSION__ = 199901L) || (defined(__SUNPRO_C) defined(__C99FEATURES__)) since the compiler supports inline even without C99 mode. This got me somewhat further, but I ran into a couple of compilation failures in the gcc directory: /vol/src/gnu/gcc/gcc-4.4.2/gcc/bitmap.c, line 298: reference to static identifier bitmap_elt_clear_from in extern inline function /vol/src/gnu/gcc/gcc-4.4.2/gcc/dominance.c, line 718: reference to static identifier dom_convert_dir_to_idx in extern inline function /vol/src/gnu/gcc/gcc-4.4.2/gcc/gimple.c, line 1471: reference to static identifier walk_gimple_asm in extern inline function I cannot say for certain if the errors are correct, but the do make sense to me. Chaning the three functions to extern allowed to compilation to continue, but again linking xgcc failed with the same set of undefined functions. Even with extern inline, cc emits a definition of several functions in gcc.o, which still reference functions only defined in libgmp. I'm not sure what is the best way to handle this: one could link xgcc and cpp with GMPLIBS or avoid including gmp.h in headers used by gcc.c. -- Summary: Bootstrap with Sun Studio 12.1 fails Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at gcc dot gnu dot org GCC build triplet: *-*-solaris2.10 GCC host triplet: *-*-solaris2.10 GCC target triplet: *-*-solaris2.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41771
[Bug bootstrap/41771] Bootstrap with Sun Studio 12.1 fails
--- Comment #1 from ro at gcc dot gnu dot org 2009-10-20 19:16 --- Created an attachment (id=18845) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18845action=view) Patch to make inline work with Sun Studio 12.1 cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41771
[Bug fortran/41772] New: segfault
Non-reduced testcase:
wget http://www.uszla.me.uk/FoX/source/FoX-4.0.4.tar.gz
tar xfz FoX-4.0.4.tar.gz
cd FoX-4.0.4 ./configure FC=gfortran make -j4
cat EOF fox.f90
use FoX_dom
implicit none
type(Node), pointer :: doc
type(DOMConfiguration),pointer :: config
config = newDOMConfig()
call setParameter(config, validate-if-schema, .true.)
doc = parseFile(input.xml,config)
end
EOF
gfortran -Iobjs/finclude fox.f90 objs/lib/libFoX_{dom,utils,sax,common,fsys}.a
./a.out
Segmentation fault (core dumped)
Needs the attached input.xml. Testcase works with NAG f95.
--
Summary: segfault
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41772
[Bug fortran/41772] segfault
--- Comment #1 from burnus at gcc dot gnu dot org 2009-10-20 19:52 --- Created an attachment (id=18846) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18846action=view) input.xml -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41772
[Bug fortran/41478] Corrupted memory using PACK for derived-types with allocated components
--- Comment #9 from janus at gcc dot gnu dot org 2009-10-20 19:56 ---
Apart from the double free issue, there might be a more fundamental problem
with PACK and arrays of derived types. For me, Tobias' test case from comment
#8 segfaults already in the call to _gfortran_pack, and so does the following:
type :: container_t
integer:: entry = -1
end type container_t
type(container_t), dimension(1) :: a1, a2
a2(1)%entry = 1
print *,a1,a2
a1 = pack (a2, mask = [.true.])
print *,a1,a2
end
This does not have any allocatables (so no auto-dealloc happens), but the
output is:
-1 1
Segmentation fault
which means the second print statement is not reached, i.e. the segfault seems
to happen in _gfortran_pack.
The part of the dump which corresponds to the call to PACK looks like this:
{
struct array1_logical(kind=4) parm.4;
static logical(kind=4) A.3[1] = {1};
struct array1_container_t parm.2;
struct array1_container_t parm.1;
parm.1.dtype = 297;
parm.1.dim[0].lbound = 1;
parm.1.dim[0].ubound = 1;
parm.1.dim[0].stride = 1;
parm.1.data = (void *) a1[0];
parm.1.offset = -1;
parm.2.dtype = 297;
parm.2.dim[0].lbound = 1;
parm.2.dim[0].ubound = 1;
parm.2.dim[0].stride = 1;
parm.2.data = (void *) a2[0];
parm.2.offset = -1;
parm.4.dtype = 273;
parm.4.dim[0].lbound = 1;
parm.4.dim[0].ubound = 1;
parm.4.dim[0].stride = 1;
parm.4.data = (void *) A.3[0];
parm.4.offset = 0;
_gfortran_pack (parm.1, parm.2, parm.4, 0B);
}
The above test case works when making a1 and a2 simple integers.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41478
[Bug fortran/41478] Corrupted memory using PACK for derived-types with allocated components
--- Comment #10 from janus at gcc dot gnu dot org 2009-10-20 20:06 --- I have re-checked the F03 standard to verify that the first argument of PACK can indeed be of arbitrary type: 13.7.89 PACK (ARRAY, MASK [, VECTOR]) Description. Pack an array into an array of rank one under the control of a Class. Transformational function. Arguments. ARRAYmay be of any type. It shall not be scalar. ... In the gfortran testsuite PACK seems to be tested with all intrinsic types (logical, integer, real, complex, character), but not with derived types. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41478
[Bug fortran/41478] Corrupted memory using PACK for derived-types with allocated components
--- Comment #11 from janus at gcc dot gnu dot org 2009-10-20 20:15 --- Ok, I have identified the place in libgfortran where the segfault happens: #0 *_gfortran_pack (ret=0x7fffec3ca650, array=0x7fffec3ca620, mask=0x7fffec3ca440, vector=0x0) at /home/jweil/gcc45/trunk/libgfortran/intrinsics/pack_generic.c:364 That line is: if (GFC_UNALIGNED_4(ret-data) || GFC_UNALIGNED_4(array-data) || GFC_UNALIGNED_4(vector-data)) break; So, the problem is that we ask for the 'data' field in the optional VECTOR argument, which is not present here (i.e. vector=0x0)! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41478
[Bug fortran/41772] segfault due to wrong code in TRANSFER?
--- Comment #2 from burnus at gcc dot gnu dot org 2009-10-20 20:31 --- For input.xml point coord=0 / is enough. Valgrind shows the following (and some more str_vs / vs_str / str_alloc invalid reads). str_vs and vs_str convert (TRANSFER) a multi-character string into a char(1) array and vice versa. Invalid read of size 1 at 0x4C256E8: memcpy (mc_replace_strmem.c:482) by 0x4C0160: __fox_m_fsys_array_str_MOD_str_vs (fox_m_fsys_array_str.F90:46) by 0x49B050: __m_common_namespaces_MOD_checknamespaces (m_common_namespaces.F90:603) by 0x46B726: open_tag.1918 (m_sax_parser.F90:2360) by 0x4549E9: __m_sax_parser_MOD_sax_parse (m_sax_parser.F90:843) by 0x401987: __m_dom_parse_MOD_runparser (m_dom_parse.f90:500) by 0x4016E9: __m_dom_parse_MOD_parsefile (m_dom_parse.f90:547) by 0x40143B: MAIN__ (fox.f90:7) by 0x40147A: main (fox.f90:1) -- burnus at gcc dot gnu dot org changed: What|Removed |Added Summary|segfault|segfault due to wrong code ||in TRANSFER? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41772
[Bug fortran/41478] Corrupted memory using PACK for derived-types with allocated components
--- Comment #12 from janus at gcc dot gnu dot org 2009-10-20 20:54 ---
Here is a simple patch which cures the segfault in comment #9. However it does
not tackle the double-free issue.
Index: libgfortran/intrinsics/pack_generic.c
===
--- libgfortran/intrinsics/pack_generic.c (Revision 153009)
+++ libgfortran/intrinsics/pack_generic.c (Arbeitskopie)
@@ -350,7 +350,7 @@ pack (gfc_array_char *ret, const gfc_array_char *a
case GFC_DTYPE_DERIVED_2:
if (GFC_UNALIGNED_2(ret-data) || GFC_UNALIGNED_2(array-data)
- || GFC_UNALIGNED_2(vector-data))
+ || (vector GFC_UNALIGNED_2(vector-data)))
break;
else
{
@@ -361,7 +361,7 @@ pack (gfc_array_char *ret, const gfc_array_char *a
case GFC_DTYPE_DERIVED_4:
if (GFC_UNALIGNED_4(ret-data) || GFC_UNALIGNED_4(array-data)
- || GFC_UNALIGNED_4(vector-data))
+ || (vector GFC_UNALIGNED_4(vector-data)))
break;
else
{
@@ -372,7 +372,7 @@ pack (gfc_array_char *ret, const gfc_array_char *a
case GFC_DTYPE_DERIVED_8:
if (GFC_UNALIGNED_8(ret-data) || GFC_UNALIGNED_8(array-data)
- || GFC_UNALIGNED_8(vector-data))
+ || (vector GFC_UNALIGNED_8(vector-data)))
break;
else
{
@@ -383,7 +383,7 @@ pack (gfc_array_char *ret, const gfc_array_char *a
#ifdef HAVE_GFC_INTEGER_16
case GFC_DTYPE_DERIVED_16:
if (GFC_UNALIGNED_16(ret-data) || GFC_UNALIGNED_16(array-data)
- || GFC_UNALIGNED_16(vector-data))
+ || (vector GFC_UNALIGNED_16(vector-data)))
break;
else
{
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41478
[Bug tree-optimization/36646] [4.3/4.4/4.5 Regression] Unnecessary moves generated on loop boundaries
--- Comment #7 from astrange at ithinksw dot com 2009-10-20 21:10 --- Tried with SVN today and it's fixed: L6: incb(%ebx) jmp L12 .align 4,0x90 Close if you want; I don't think it's worth finding when this happened. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36646
[Bug libstdc++/41763] valarray_array.h seems to overuse __restrict__
--- Comment #6 from jakub at gcc dot gnu dot org 2009-10-20 21:15 ---
Not compared with other arguments to be precise. It is fine to have
void foo (int *__restrict__ p, int *__restrict__ q)
{
int *r = p + 10;
while (p != r)
*p++ = *q++;
}
Although p is compared here, it is compared with a pointer based on the same
pointer argument.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41763
[Bug libstdc++/41773] New: [4.5 Regression] Many libstdc++ failures
On Linux/ia32, revision 153024 has many failures: http://gcc.gnu.org/ml/gcc-regression/2009-10/msg00193.html It may be caused by revision 153023: http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg00676.html -- Summary: [4.5 Regression] Many libstdc++ failures Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41773
[Bug fortran/41772] [4.4/4.5 Regression] Wrong code due to TRANSFER of EMPTY array section
--- Comment #3 from burnus at gcc dot gnu dot org 2009-10-20 21:16 --- Reduced testcase. The problem is - as often - the empty array section. With 4.1, 4.2 and 4.3 it works, while with 4.4 and 4.5 I get a segfault. module m implicit none contains pure function str_vs(vs) result(s) character, dimension(:), intent(in) :: vs character(len=size(vs)) :: s s = transfer(vs, s) end function str_vs subroutine has_key_ns(uri, localname) character(len=*), intent(in) :: uri, localname end subroutine end module m use m implicit none character, dimension(:), pointer :: QName integer :: n allocate(qname(6)) qname = (/ 'a','b','c','d','e','f' /) n = 0 call has_key_ns(str_vs(qname(1:n-1)),) deallocate(qname) end -- burnus at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.4.1 4.5.0 Known to work||4.1.3 4.2.1 4.3.4 Summary|segfault due to wrong code |[4.4/4.5 Regression] Wrong |in TRANSFER?|code due to TRANSFER of ||EMPTY array section Target Milestone|--- |4.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41772
[Bug libstdc++/41763] valarray_array.h seems to overuse __restrict__
--- Comment #7 from paolo at gcc dot gnu dot org 2009-10-20 21:21 --- Subject: Bug 41763 Author: paolo Date: Tue Oct 20 21:21:11 2009 New Revision: 153039 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153039 Log: 2009-10-20 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/41763 * include/bits/valarray_array.h (__valarray_default_construct, __valarray_fill_construct, __valarray_copy_construct, __valarray_sum __valarray_destroy_elements, __valarray_product): Do not qualify with __restrict__ pointers accessing data also accessed by other pointers. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/valarray_array.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41763
[Bug libstdc++/41773] [4.5 Regression] Many libstdc++ failures
--- Comment #1 from hjl dot tools at gmail dot com 2009-10-20 21:21 --- Revision 153021 is OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41773
[Bug fortran/41772] [4.4/4.5 Regression] Wrong code due to TRANSFER of EMPTY array section
--- Comment #4 from burnus at gcc dot gnu dot org 2009-10-20 21:45 --- Working: 2009-01-16-r143426 Failing: 2009-01-17-r143463 Possibly caused by: r143462 | pault | 2009-01-17 12:32:02 +0100 (Sat, 17 Jan 2009) | 17 lines http://gcc.gnu.org/viewcvs?view=revrevision=143462 2009-01-17 Paul Thomas pa...@gcc.gnu.org PR fortran/34955 * trans-intrinsic.c (gfc_conv_intrinsic_array_transfer): Has been absorbed into gfc_conv_intrinsic_transfer. All references to it in trans-intrinsic.c have been changed accordingly. PR fixed by using a temporary for scalar character transfer, when the source is shorter than the destination. 2009-01-17 Paul Thomas pa...@gcc.gnu.org PR fortran/34955 * gfortran.dg/transfer_intrinsic_1.f90: New test. * gfortran.dg/transfer_intrinsic_2.f90: New test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41772
[Bug libstdc++/41773] [4.5 Regression] Many libstdc++ failures
--- Comment #2 from paolo dot carlini at oracle dot com 2009-10-20 21:48 --- Ok, I'm going to revert it for now, crazy. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC|paolo dot carlini at oracle | |dot com | AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-10-20 21:48:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41773
[Bug tree-optimization/41497] [4.5 Regression] apparent integer wrong code bug
--- Comment #10 from spop at gcc dot gnu dot org 2009-10-20 21:53 --- Subject: Re: [4.5 Regression] apparent integer wrong code bug The problem is that we follow SSA edges into loops that may not be executed. It is correct to follow SSA edges in loops that may not execute, as we compute a symbolic expression of the evolution. The error is that we are not careful enough in the use of this symbolic information: in analyze_evolution_in_loop we are given the loop_phi_node: a_lsm.6_15 = PHI a_lsm.6_18(3), a_lsm.6_20(4) and its initial value init_cond: a_lsm.6_18. follow_ssa_edge returns an evolution function ev_fn that could be incompatible with the initial value: (unsigned int) (short unsigned int) a_lsm.6_18; The attached patch fixes the problem by returning don't know when init_cond is not equal to ev_fn when no_evolution_in_loop_p manages to prove that ev_fn is invariant in the loop. Sebastian --- Comment #11 from spop at gcc dot gnu dot org 2009-10-20 21:53 --- Created an attachment (id=18847) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18847action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41497
[Bug libstdc++/41773] [4.5 Regression] Many libstdc++ failures
--- Comment #3 from paolo at gcc dot gnu dot org 2009-10-20 21:54 --- Subject: Bug 41773 Author: paolo Date: Tue Oct 20 21:54:22 2009 New Revision: 153040 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153040 Log: 2009-10-20 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/41773 Revert: 2009-10-20 Paolo Carlini paolo.carl...@oracle.com * include/bits/basic_string.h (_S_construct(const _CharT*, size_type, const _Alloc)): New, declare. (_S_construct(_CharT*, _CharT*, const _Alloc), _S_construct(const _CharT*, const _CharT*, const _Alloc), _S_construct(iterator, iterator, const _Alloc), _S_construct(const_iterator, const_iterator, const _Alloc)): New, forward to the latter. * include/bits/basic_string.tcc (_S_construct(const _CharT*, size_type, const _Alloc)): Define. (basic_string(const basic_string, size_type, size_type), basic_string(const basic_string, size_type, size_type, const _Alloc), basic_string(const _CharT*, size_type, const _Alloc), basic_string(const _CharT*, const _Alloc), basic_string(initializer_list, const _Alloc)): Call the latter. * config/abi/pre/gnu.ver: Remove recently added exports. * src/string-inst.cc: Remove instantiations. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/abi/pre/gnu.ver trunk/libstdc++-v3/include/bits/basic_string.h trunk/libstdc++-v3/include/bits/basic_string.tcc trunk/libstdc++-v3/src/string-inst.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41773
[Bug libstdc++/41773] [4.5 Regression] Many libstdc++ failures
--- Comment #4 from paolo dot carlini at oracle dot com 2009-10-20 22:02 --- Done -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41773
[Bug libstdc++/41763] valarray_array.h seems to overuse __restrict__
--- Comment #8 from paolo dot carlini at oracle dot com 2009-10-20 22:14 --- Ok, thanks Jakub. By the way, I was looking for some info about export, beyond C99 and the GCC specifics, and found docs about the IBM compiler saying that in case of pointers to const, it is still safe to use __restrict__. Any idea if this is safe / beneficial in GCC too? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41763
[Bug libstdc++/41763] valarray_array.h seems to overuse __restrict__
--- Comment #10 from paolo dot carlini at oracle dot com 2009-10-20 22:15 --- I meant info about __restrict__ of course. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41763
[Bug target/41702] FAIL: abi/demangle/abi_text/09.cc execution test
--- Comment #3 from danglin at gcc dot gnu dot org 2009-10-20 22:44 --- Subject: Bug 41702 Author: danglin Date: Tue Oct 20 22:44:08 2009 New Revision: 153042 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153042 Log: Backport from mainline: 2009-10-15 John David Anglin dave.ang...@nrc-cnrc.gc.ca PR target/41702 * pa.md (casesi): Use sign extended index in call to gen_casesi64p. (casesi64p): Update pattern to reflect above. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/pa/pa.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41702
[Bug target/41702] FAIL: abi/demangle/abi_text/09.cc execution test
--- Comment #4 from danglin at gcc dot gnu dot org 2009-10-20 22:46 --- Subject: Bug 41702 Author: danglin Date: Tue Oct 20 22:46:16 2009 New Revision: 153043 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153043 Log: Backport from mainline: 2009-10-15 John David Anglin dave.ang...@nrc-cnrc.gc.ca PR target/41702 * pa.md (casesi): Use sign extended index in call to gen_casesi64p. (casesi64p): Update pattern to reflect above. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/pa/pa.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41702
[Bug testsuite/41700] g++.dg/debug/dwarf2/icf.C
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2009-10-20 23:12 --- Subject: Re: g++.dg/debug/dwarf2/icf.C The insn UID is changed when the call_insn is split, so the vtable slot index can't be found when it's time to build the vcall table. So, it seems this is a middle-end bug. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41700
[Bug c++/41774] New: ice: vector VEC(visibility,base) pop domain error, in pop_visibility at c-pragma.c:757
Obviously the input is malformed, but probably still should not ICE.
reg...@john-home:~/volatile/tmp208$ current-g++ -O small.cpp
small.cpp:2:27: internal compiler error: vector VEC(visibility,base) pop domain
error, in pop_visibility at c-pragma.c:757
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
reg...@john-home:~/volatile/tmp208$ current-g++ -v
Using built-in specs.
COLLECT_GCC=current-g++
COLLECT_LTO_WRAPPER=/home/regehr/z/tmp/gcc-r153044-install/libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../configure --enable-lto
--prefix=/home/regehr/z/tmp/gcc-r153044-install --program-prefix=r153044-
--enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 20091020 (experimental) (GCC)
reg...@john-home:~/volatile/tmp208$ cat small.cpp
namespace std __attribute__ ((__visibility__ (default))) {
#pragma GCC visibility pop
--
Summary: ice: vector VEC(visibility,base) pop domain error, in
pop_visibility at c-pragma.c:757
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah dot edu
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=41774
[Bug debug/41739] [4.5 Regression] Failed to bootstrap on Linux/ia64
--- Comment #3 from hjl dot tools at gmail dot com 2009-10-21 00:52 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41739
[Bug bootstrap/41771] Bootstrap with Sun Studio 12.1 fails
--- Comment #2 from ghazi at gcc dot gnu dot org 2009-10-21 01:48 --- I would prefer a solution that does not involve linking xgcc and cpp with libgmp since that links in unecessary code and/or yields a runtime penalty for loading the shared library. It's unusual that we've only just now received this report since gmp has been used since gcc-4.3 (released 1.5 years ago). So I'm curious if something more recently changed to trigger this issue. I.e. did it used to work, and some newer version of either gmp, sun cc, or solaris exposed the problem? Or did it always fail? (Also, you don't mention what version of gmp you were using.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41771
[Bug fortran/41478] Corrupted memory using PACK for derived-types with allocated components
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2009-10-21 03:04 --- With your patch, I am not seeing the double free. But I do get this: 85078576 85078520 85078576 85078576 2 2 ==27755== ==27755== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 2) ==27755== malloc/free: in use at exit: 8 bytes in 2 blocks. ==27755== malloc/free: 18 allocs, 16 frees, 3,785 bytes allocated. ==27755== For counts of detected errors, rerun with: -v ==27755== searching for pointers to 2 not-freed blocks. ==27755== checked 89,864 bytes. ==27755== ==27755== LEAK SUMMARY: ==27755==definitely lost: 4 bytes in 1 blocks. ==27755== possibly lost: 0 bytes in 0 blocks. ==27755==still reachable: 4 bytes in 1 blocks. ==27755== suppressed: 0 bytes in 0 blocks. ==27755== Rerun with --leak-check=full to see details of leaked memory. using the original test case with print locs etc. Maybe my system is tolerant. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41478
[Bug c++/41775] New: ice in rewrite_stmt, at tree-into-ssa.c:1302
This ice prevents the gcc svn head from building the LLVM svn head. reg...@john-home:~/volatile/tmp208$ current-g++ -c -O3 small.cpp small.cpp: In member function (anonymous namespace)::StrongPHIElimination::runOnMachineFunction(llvm::MachineFunction): small.cpp:281:1: internal compiler error: in rewrite_stmt, at tree-into-ssa.c:1302 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. reg...@john-home:~/volatile/tmp208$ current-g++ -v Using built-in specs. COLLECT_GCC=current-g++ COLLECT_LTO_WRAPPER=/home/regehr/z/tmp/gcc-r153044-install/libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../configure --enable-lto --prefix=/home/regehr/z/tmp/gcc-r153044-install --program-prefix=r153044- --enable-languages=c,c++ Thread model: posix gcc version 4.5.0 20091020 (experimental) (GCC) -- Summary: ice in rewrite_stmt, at tree-into-ssa.c:1302 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: regehr at cs dot utah dot edu 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=41775
[Bug c++/41775] ice in rewrite_stmt, at tree-into-ssa.c:1302
--- Comment #1 from regehr at cs dot utah dot edu 2009-10-21 04:13 --- Created an attachment (id=18848) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18848action=view) failure inducing input -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41775
