[Bug c++/30196] New: Variable-length automatic array contents gets destroyed on unrelated exception
I found this interesting thing. The "array" content is destroyed after the
"catch" statement but it shouldn't be. It behaves the same in MinGW 4.2.0 and
3.4.4 for me. It seems like the "array" is unwound out when the exception is
caught.
---
#include
#include
#include
int main () {
int n = 10;
int array [n];
for (int i = 0; i < n; ++i) array [i] = i;
try {
for (int i = 0; i < n; ++i) std::printf ("%u,", array [i]);
std::printf (" = %u\n", n);
throw 1;
} catch (int) {
for (int i = 0; i < n; ++i) std::printf ("%u,", array [i]);
std::printf (" = %u\n", n);
};
return 0;
};
--
Summary: Variable-length automatic array contents gets destroyed
on unrelated exception
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Tringi at Mx-3 dot cz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30196
[Bug middle-end/30196] VLA and setjumplongjump exceptions
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-13 08:37 --- This is SJLJ related as it works just fine on x86-linux and powerpc-darwin both uses dwarf2 exceptions. One should note that VLA are an extension to C++. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |middle-end Keywords||EH, sjlj-eh, wrong-code Summary|Variable-length automatic |VLA and setjumplongjump |array contents gets |exceptions |destroyed on unrelated | |exception | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30196
[Bug tree-optimization/30125] [4.3 regression] Wrong-code due to aliasing
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-12-13 09:00 --- Fixed now, I don't know by what off hand but I think it was: 2006-12-11 Daniel Berlin <[EMAIL PROTECTED]> * tree-ssa-structalias.c (handle_ptr_arith): Return false when we can't handle the pointer arithmetic. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30125
[Bug middle-end/30191] [4.3 Regression] GCC error: in eliminate_regs_in_insn, at reload1.c:3126
--- Comment #4 from echristo at apple dot com 2006-12-13 09:25 --- I'm seeing it on x86_64-darwin with compile/20031023-4.c. -- echristo at apple dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-12-13 09:25:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30191
[Bug java/29019] [win32] getCanonicalPath returns different results sometimes
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-13 09:36 --- No feedback (or testcase) in 3 months so closing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29019
[Bug middle-end/28781] -fPIC generates non-PIC code
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-12-13 09:37 --- No testcase in 3 months so closing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28781
[Bug libstdc++/11953] _REENTRANT defined when compiling non-threaded code.
--- Comment #46 from pinskia at gcc dot gnu dot org 2006-12-13 09:38 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED Target Milestone|4.1.0 |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11953
[Bug testsuite/30181] FAIL: gcc.dg/builtins-57.c scan-tree-dump trunc
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-12-13 09:46 --- I'll fix it after vacation. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-12-13 09:46:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30181
[Bug tree-optimization/17687] sincos tree representation causes extra addressable vars
--- Comment #20 from rguenth at gcc dot gnu dot org 2006-12-13 10:27 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17687
[Bug fortran/30115] allocate() interface pessimizes aliasing
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-12-13 10:29 --- Fixed on the mainline, backport to 4.2 pending. -- 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 Known to work||4.3.0 Last reconfirmed|2006-12-09 10:23:27 |2006-12-13 10:29:12 date|| Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30115
[Bug middle-end/30197] New: cexp ( __complex__ ( 0, x ) ) can be folded to cexpi (x)
I have a patch. -- Summary: cexp ( __complex__ ( 0, x ) ) can be folded to cexpi (x) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: middle-end AssignedTo: rguenth at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org BugsThisDependsOn: 30172 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30197
[Bug middle-end/30191] [4.3 Regression] GCC error: in eliminate_regs_in_insn, at reload1.c:3126
--- Comment #5 from schwab at suse dot de 2006-12-13 10:37 --- On ia64 it is crashing in libiberty/md5.c. -- schwab at suse dot de changed: What|Removed |Added CC||schwab at suse dot de 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=30191
[Bug middle-end/30198] New: __real / __imag cexpi (x) can be folded to cos (x) / sin (x)
I have a patch. -- Summary: __real / __imag cexpi (x) can be folded to cos (x) / sin (x) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: middle-end AssignedTo: rguenth at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30198
[Bug debug/30189] [4.1 Regression] ICE on modified_type_die
--- Comment #1 from jakub at gcc dot gnu dot org 2006-12-13 11:09 --- "Fixed" by http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01014.html modified_type_die rearrangment, which dropped the assert (not sure if intentionally or not). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30189
[Bug c/12245] [4.0/4.1/4.2/4.3 regression] Uses lots of memory when compiling large initialized arrays
--- Comment #27 from niemayer at isg dot de 2006-12-13 11:37 --- I would like to mention that this problem seems to have worsened a lot for the current snapshots of gcc-4.2 (currently testing with 4.2.0 20061205 (prerelease)) when compiling with at least -O1 - maybe due to the static constant elimination?. I tried to compile a Unicode normalization test C++ source that took gcc about 300MB of RAM before to compile with -O1 - now with gcc 4.2 I cannot compile this source anymore on a machine with 1 GB of physical + 1 GB of virtual RAM before the kernel OOM killer is killing cc1plus. If somebody would like the source of my test-case, I can supply it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245
[Bug target/30192] [arm] Wrong sp value on exit after calling __floatdidf or __floatundidf
--- Comment #1 from rearnsha at gcc dot gnu dot org 2006-12-13 12:01 --- Created an attachment (id=12793) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12793&action=view) patch for fpa-related floating point problems -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rearnsha at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30192
[Bug target/30192] [arm] Wrong sp value on exit after calling __floatdidf or __floatundidf
--- Comment #2 from rearnsha at gcc dot gnu dot org 2006-12-13 12:02 --- Sorry, your proposed patch isn't interworking safe. Can you try the patch I've attached and let me know if that works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30192
[Bug target/30148] parameter passing bug
--- Comment #2 from lindig at cs dot uni-sb dot de 2006-12-13 12:09 ---
Created an attachment (id=12794)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12794&action=view)
preprocessed file to reproduce the bug.
I have now attached the file that reproduces the bug to make everyone's life
easier. The bug can be summarized as follows: when a struct (b14) is passed by
value as a vararg, it may be garbled. In this case, the struct is passed as the
second vararg (b14) where the first one (b13) is an empty struct {}. This could
confuse the code that implements the calling convention.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30148
[Bug middle-end/30197] cexp ( __complex__ ( 0, x ) ) can be folded to cexpi (x)
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-12-13 12:48 --- Created an attachment (id=12795) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12795&action=view) patch The testcase depends on 30172 to be fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30197
[Bug bootstrap/30136] bootstrap fail for 4.3-20061209
--- Comment #2 from dcb314 at hotmail dot com 2006-12-13 13:25 --- (In reply to comment #1) > Does this work now on the mainline? The only access to mainline I have is by the weekly snapshots. I expect to try out 4.3-20061216. Thus, answer expected Monday 18 Dec 2006. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30136
[Bug testsuite/30119] libjava testsuite output is erratic and unhelpful
--- Comment #6 from amylaar at gcc dot gnu dot org 2006-12-13 13:25 ---
(In reply to comment #5)
> Set the classpath
>
> gij -classpath : PR18699
Unfortunately, that still doesn't work:
[EMAIL
PROTECTED]:~/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/libjava/testsuite$
../gij -classpath PR18699.class:../libgcj-4.3.0.jar PR18699.class
Exception in thread "main" java.lang.NoClassDefFoundError: PR18699.class
at gnu.java.lang.MainThread.run(MainThread.java:102)
Caused by: java.lang.ClassNotFoundException: PR18699.class not found in
gnu.gcj.runtime.SystemClassLoader{urls=[file:PR18699.class,file:../libgcj-4.3.0.jar],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
at java.net.URLClassLoader.findClass(URLClassLoader.java:1080)
at gnu.gcj.runtime.SystemClassLoader.findClass(natSystemClassLoader.cc:27)
at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
at java.lang.ClassLoader.loadClass(ClassLoader.java:294)
at gnu.java.lang.MainThread.run(MainThread.java:98)
[EMAIL
PROTECTED]:~/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/libjava/testsuite$
ls -l PR18699.class
-rw-r--r-- 1 amylaar users 1688 2006-12-13 14:11 PR18699.class
[EMAIL
PROTECTED]:~/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/libjava/testsuite$
ls -l ../libgcj-4.3.0.jar
-rw-r--r-- 1 amylaar users 8547070 2006-12-05 00:07 ../libgcj-4.3.0.jar
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30119
[Bug c++/28740] [4.0 regression] ICE with invalid inheritance
--- Comment #5 from lmillward at gcc dot gnu dot org 2006-12-13 13:26 --- Subject: Bug 28740 Author: lmillward Date: Wed Dec 13 13:25:47 2006 New Revision: 119830 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119830 Log: PR c++27316 * g++.dg/inherit/error3.C: New test. PR c++/28740 * g++.dg/inherit/error4.C: New test. Added: trunk/gcc/testsuite/g++.dg/inherit/error3.C trunk/gcc/testsuite/g++.dg/inherit/error4.C Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28740
[Bug middle-end/30172] Operations with partly constant complex values not folded
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-12-13 13:31 --- __complex__ ( x, y ) * I == __complex__ ( -y, x ) __complex__ ( x, y ) * -I == __complex__ ( y, -x ) but only if we don't honor NaNs or signed zeros. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30172
[Bug fortran/29975] [meta-bugs] [4.1 and 4.2 only] ICEs with CP2K
--- Comment #36 from pault at gcc dot gnu dot org 2006-12-13 13:37 --- Joost, > input_cp2k_motion.f90 > input_cp2k_motion.f90: In function ‘create_neb_section’: > input_cp2k_motion.f90:3122: internal compiler error: in fold_convert, at > fold-const.c:2150 > > in fact, this is on a file added to the CP2K CVS repo 2 days ago, so it is not > yet part of the gzip'ed file that I provided for the initial report. That one > compiles OK at -O2. A reduced version of this one would be very nice - if I would guess, it will be an assignment in which derived type is not being correctly associated. Apparently, I still do not have this entirely right. BTW I am not sure that a meta-bug was necessarily the best way to handle this series of problems. I think that we should have spun off a PR for each bug that we found. This is my fault but I signal it for future reference. Thanks for sticking with us on this one - we'll get there in the end. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug testsuite/30119] libjava testsuite output is erratic and unhelpful
--- Comment #7 from aph at gcc dot gnu dot org 2006-12-13 13:42 --- You wrote ../gij -classpath PR18699.class:../libgcj-4.3.0.jar PR18699.class But I wrote: ../gij -classpath .:../libgcj-4.3.0.jar PR18699 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30119
[Bug c++/28740] [4.0 regression] ICE with invalid inheritance
--- Comment #6 from lmillward at gcc dot gnu dot org 2006-12-13 13:59 --- Subject: Bug 28740 Author: lmillward Date: Wed Dec 13 13:58:43 2006 New Revision: 119831 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119831 Log: PR c++/27316 * g++.dg/inherit/error3.C: New test PR c++/28740 * g++.dg/inherit/error4.C: New test Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/inherit/error3.C branches/gcc-4_2-branch/gcc/testsuite/g++.dg/inherit/error4.C Modified: branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28740
[Bug c++/27316] [4.0 Regression] ICE with two ill-placed expression
--- Comment #7 from lmillward at gcc dot gnu dot org 2006-12-13 13:59 --- Subject: Bug 27316 Author: lmillward Date: Wed Dec 13 13:58:43 2006 New Revision: 119831 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119831 Log: PR c++/27316 * g++.dg/inherit/error3.C: New test PR c++/28740 * g++.dg/inherit/error4.C: New test Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/inherit/error3.C branches/gcc-4_2-branch/gcc/testsuite/g++.dg/inherit/error4.C Modified: branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27316
[Bug fortran/29975] [meta-bugs] [4.1 and 4.2 only] ICEs with CP2K
--- Comment #37 from jv244 at cam dot ac dot uk 2006-12-13 14:01 --- (In reply to comment #36) well, this was reduced, filed as PR30147, and fixed. Tobias reduced another one and filed it as PR30190 (see dependencies). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug fortran/29975] [meta-bugs] [4.1 and 4.2 only] ICEs with CP2K
--- Comment #38 from burnus at gcc dot gnu dot org 2006-12-13 14:03 --- Hi Paul, (In reply to comment #36) > > input_cp2k_motion.f90:3122: internal compiler error: in fold_convert, at > > A reduced version of this one would be very nice - if I would guess, it will > be an assignment in which derived type is not being correctly associated. > Apparently, I still do not have this entirely right. Test case see PR 30147. This is a now-fixed middle end bug. A new problem is PR30190 (-fbounds-check creates wrong code with associated(pointer,target). I would suggest to close this bug as FIXED as soon as everything is checked in. (I think 4.2 is still missing, and maybe [or not] 4.1). The rest should be handled in different bugs, but one can still link to this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug tree-optimization/30194] [4.3 Regression] gcc.dg/pr19633-1.c fails on the mainline
--- Comment #3 from dnovillo at gcc dot gnu dot org 2006-12-13 14:11 --- Works for me with @119760 (mem-ssa) on all arches (x86, x86_64, ia64 and ppc64). $ make check-gcc RUNTESTFLAGS=dg.exp=pr19633-1.c [...] Test Run By dnovillo on Wed Dec 13 09:05:53 2006 Native configuration is x86_64-unknown-linux-gnu === gcc tests === Schedule of variations: unix Running target unix Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using /home/dnovillo/gcc/src/gcc/testsuite/config/default.exp as tool-and-target-specific interface file. Running /home/dnovillo/gcc/src/gcc/testsuite/gcc.dg/dg.exp ... === gcc Summary === # of expected passes2 /home/notnfs/dnovillo/BLD-gcc-native/gcc/xgcc version 4.3.0 20061212 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30194
[Bug target/30199] New: config/freebsd.h does not define HANDLE_PRAGMA_PACK_PUSH_POP
The GCC compiler on FreeBSD does not handle #pragma pack(push, ) since gcc/config/freebsd.h does not define HANDLE_PRAGMA_PACK_PUSH_POP. There is no reason for this: 1. gcc/config/linux.h defines HANDLE_PRAGMA_PACK_PUSH_POP. No reason why Linux and FreeBSD should be different here. 2. The 'native' version of the gcc compiler (which is shipped with FreeBSD) have HANDLE_PRAGMA_PACK_PUSH_POP defined. See e.g. http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/gcc/config/freebsd.h?rev=1.40 So, please add #define HANDLE_PRAGMA_PACK_PUSH_POP to gcc/config/freebsd.h -- Summary: config/freebsd.h does not define HANDLE_PRAGMA_PACK_PUSH_POP Product: gcc Version: 4.0.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tejblum at yandex-team dot ru GCC build triplet: x86_64-portbld-freebsd6.2 GCC host triplet: x86_64-portbld-freebsd6.2 GCC target triplet: x86_64-portbld-freebsd6.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30199
[Bug c++/28740] [4.0 regression] ICE with invalid inheritance
--- Comment #7 from lmillward at gcc dot gnu dot org 2006-12-13 14:29 --- Subject: Bug 28740 Author: lmillward Date: Wed Dec 13 14:28:47 2006 New Revision: 119833 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119833 Log: PR c++27316 * g++.dg/inherit/error3.C: New test. PR c++/28740 * g++.dg/inherit/error4.C: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/inherit/error3.C branches/gcc-4_1-branch/gcc/testsuite/g++.dg/inherit/error4.C Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28740
[Bug fortran/30200] New: valgrind errors for write statement
[EMAIL PROTECTED]:/scratch/vondele/clean/cp2k/tests/QS/regtest-gpw-2> gfortran
test.f90
[EMAIL PROTECTED]:/scratch/vondele/clean/cp2k/tests/QS/regtest-gpw-2> ./a.out
[EMAIL PROTECTED]:/scratch/vondele/clean/cp2k/tests/QS/regtest-gpw-2> valgrind
--tool=memcheck ./a.out
==16188== Memcheck, a memory error detector.
==16188== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==16188== Using LibVEX rev 1575, a library for dynamic binary translation.
==16188== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
==16188== Using valgrind-3.1.1, a dynamic binary instrumentation framework.
==16188== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==16188== For more details, rerun with: -v
==16188==
==16188== Invalid read of size 1
==16188==at 0x4B93D8D: formatted_transfer_scalar (transfer.c:834)
==16188==by 0x4B94182: formatted_transfer (transfer.c:1355)
==16188==by 0x400CF2: MAIN__ (in
/scratch/vondele/clean/cp2k/tests/QS/regtest-gpw-2/a.out)
==16188==by 0x400D2D: main (fmain.c:18)
==16188== Address 0x5148646 is 6 bytes inside a block of size 10 free'd
==16188==at 0x4A1984D: free (vg_replace_malloc.c:235)
==16188==by 0x400CC6: MAIN__ (in
/scratch/vondele/clean/cp2k/tests/QS/regtest-gpw-2/a.out)
==16188==by 0x400D2D: main (fmain.c:18)
==16188==
==16188== Invalid read of size 1
==16188==at 0x4B93DA9: formatted_transfer_scalar (transfer.c:838)
==16188==by 0x4B94182: formatted_transfer (transfer.c:1355)
==16188==by 0x400CF2: MAIN__ (in
/scratch/vondele/clean/cp2k/tests/QS/regtest-gpw-2/a.out)
==16188==by 0x400D2D: main (fmain.c:18)
==16188== Address 0x5148647 is 7 bytes inside a block of size 10 free'd
==16188==at 0x4A1984D: free (vg_replace_malloc.c:235)
==16188==by 0x400CC6: MAIN__ (in
/scratch/vondele/clean/cp2k/tests/QS/regtest-gpw-2/a.out)
==16188==by 0x400D2D: main (fmain.c:18)
a ==16188==
==16188== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 3 from 2)
==16188== malloc/free: in use at exit: 0 bytes in 0 blocks.
==16188== malloc/free: 11 allocs, 11 frees, 29,400 bytes allocated.
==16188== For counts of detected errors, rerun with: -v
==16188== All heap blocks were freed -- no leaks are possible.
[EMAIL PROTECTED]:/scratch/vondele/clean/cp2k/tests/QS/regtest-gpw-2> cat
test.f90
character(len=100) myfmt
type test
character(len=100) :: names(5)
end type test
type(test) :: keyword
keyword%names=(/"a","b","c","d","e"/)
myfmt="1X"
WRITE(unit=6,fmt="("//TRIM(myfmt)//",a,' ')",advance="NO")
TRIM(keyword%names(1))
END
--
Summary: valgrind errors for write statement
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30200
[Bug fortran/29975] [meta-bugs] [4.1 and 4.2 only] ICEs with CP2K
--- Comment #39 from jv244 at cam dot ac dot uk 2006-12-13 15:25 --- I had a look at one of the failing testcases from CP2K testsuite, and under valgrind there were a number of errors that could be reproduced in the small testcase of PR30200 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug middle-end/30164] Gimplifier does not produce valid gimple for global_vectora = CONSTRUCTOR
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-13 15:54 --- I just exposed this on the mainline with my GIMPLE_REG vector patch for a lot more cases so I am going to take it. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-12-13 15:54:45 date|| Summary|Gimplifier does not produce |Gimplifier does not produce |valid gimple for|valid gimple for |global_vectora = CONSTRUCTOR|global_vectora = CONSTRUCTOR http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30164
[Bug libffi/28036] libffi executable stack (missing .note.GNU-stack on .o files)
--- Comment #3 from debian-gcc at lists dot debian dot org 2006-12-13 15:58 --- patch posted at http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00948.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28036
[Bug middle-end/30198] __real / __imag cexpi (x) can be folded to cos (x) / sin (x)
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||12/msg00941.html Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-12-13 16:21:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30198
[Bug middle-end/30198] __real / __imag cexpi (x) can be folded to cos (x) / sin (x)
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |ASSIGNED Last reconfirmed|2006-12-13 16:21:54 |2006-12-13 16:22:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30198
[Bug c++/30201] New: gcc doesn't unroll nested loops
While developing a Free C++ library, I am facing what I think is a bug in gcc:
it doesn't unroll nested loops. Namely, in the example program that I paste
below, there is a nested loop like
for( int i = 0; i < 3; i++ )
for( int j = 0; j < 3; j++ )
do_something( i, j );
and only the inner loop gets completely unrolled (the loop on j), the outer
loop (on i) is only partially unrolled (this is according to I. L. Taylor on
gcc@gcc.gnu.org, I don't have the skill to read the binary code).
This is a huge problem for me, not only a detail, as the performance of my code
is about 15% of what it would be if the loops got unrolled.
I cannot unroll loops by hand because this is a template library and the loops
depend on template parameters.
I have made a minimal standalone example program. I paste it below (toto.cpp).
This program does a nested loop if UNROLL is not defined, and does the same
thing but with the loops unrolled by hand if UNROLL is defined. On my machine,
the speed difference is huge:
g++ -DUNROLL -O3 toto.cpp -o toto ---> toto runs in 0.3 seconds
g++ -O3 toto.cpp -o toto---> toto runs in 1.9 seconds
Again, this is not an academic example but something found in a real library,
Eigen (http://eigen.tuxfamily.org). Granted, it's a math library, but still one
that is used in real apps, so fixing this gcc bug would benefit real apps.
So here is the example program toto.cpp:
---
#include
class Matrix
{
public:
double data[9];
double & operator()( int i, int j )
{
return data[i + 3 * j];
}
void loadScaling( double factor );
};
void Matrix::loadScaling( double factor)
{
#ifdef UNROLL
(*this)( 0, 0 ) = factor;
(*this)( 1, 0 ) = 0;
(*this)( 2, 0 ) = 0;
(*this)( 0, 1 ) = 0;
(*this)( 1, 1 ) = factor;
(*this)( 2, 1 ) = 0;
(*this)( 0, 2 ) = 0;
(*this)( 1, 2 ) = 0;
(*this)( 2, 2 ) = factor;
#else
for( int i = 0; i < 3; i++ )
for( int j = 0; j < 3; j++ )
(*this)(i, j) = (i == j) * factor;
#endif
}
int main( int argc, char *argv[] )
{
Matrix m;
for( int i = 0; i < 1; i++ )
m.loadScaling( i );
std::cout << "m(0,0) = " << m(0,0) << std::endl;
return 0;
}
--
Summary: gcc doesn't unroll nested loops
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jacob at math dot jussieu dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30201
[Bug middle-end/30172] Operations with partly constant complex values not folded
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||12/msg00954.html Status|NEW |ASSIGNED Last reconfirmed|2006-12-13 07:15:17 |2006-12-13 16:22:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30172
[Bug tree-optimization/30137] Missed folding of pointer comparison
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-12-13 16:24 --- Created an attachment (id=12796) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12796&action=view) patch It unfortunately miscompares ... (but the testsuite is clean) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30137
[Bug middle-end/30201] gcc doesn't unroll nested loops
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Component|c++ |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30201
[Bug middle-end/30201] gcc doesn't unroll nested loops
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-13 16:33 ---
Actually there are two issues with this bug, one issue is that we change
(float)(CMP) into CMP?1.0:0.0 early on which in the end causes us to produce
three different versions of the inner loop. If we write the inner loop as:
for( int i = 0; i < 3; i++ )
for( int j = 0; j < 3; j++ )
{
bool a = (i == j);
(*this)(i, j) = a * factor;
}
And use -O3 -funroll-loops, we get the correct unrolled looped (though the
multiply is still there because of signed zeros).
And the second issue is unrolling the outer loop does not happen on the tree
level.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-12-13 16:33:34
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30201
[Bug tree-optimization/30194] [4.3 Regression] gcc.dg/pr19633-1.c fails on the mainline
--- Comment #4 from pinskia at gmail dot com 2006-12-13 16:37 --- Subject: Re: [4.3 Regression] gcc.dg/pr19633-1.c fails on the mainline On Wed, 2006-12-13 at 14:12 +, dnovillo at gcc dot gnu dot org wrote: > Works for me with @119760 (mem-ssa) on all arches (x86, x86_64, ia64 > and > ppc64). So, this is about the mainline and not about the mem-ssa branch. I don't see why you are looking at the mem-ssa branch's results except to say something changed on the mainline to expose this issue. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30194
[Bug fortran/30202] New: ICE in trans-array.c
The attached sample code (as usual, much reduced but possibly not yet minimal) produces the subject error. [EMAIL PROTECTED] BUGS]$ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.2-20061212/configure --prefix=/usr/local/gcc42 --with-mpfr=/home/sfilippo/COMPILERS/GFORTRAN/TEMP/mpfr --with-gmp-lib=/home/sfilippo/COMPILERS/GFORTRAN/TEMP/gmp/lib/ --with-gmp=/home/sfilippo/COMPILERS/GFORTRAN/TEMP/gmp Thread model: posix gcc version 4.2.0 20061212 (prerelease) [EMAIL PROTECTED] BUGS]$ gfortran -c test_ab12.f90 test_ab12.f90: In function 'create_scal_p': test_ab12.f90:66: internal compiler error: in gfc_conv_descriptor_data_addr, at fortran/trans-array.c:186 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: ICE in trans-array.c Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sfilippone at uniroma2 dot it 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=30202
[Bug fortran/30202] ICE in trans-array.c
--- Comment #1 from sfilippone at uniroma2 dot it 2006-12-13 16:39 --- Created an attachment (id=12797) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12797&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30202
[Bug tree-optimization/30194] [4.3 Regression] gcc.dg/pr19633-1.c fails on the mainline
--- Comment #5 from dnovillo at gcc dot gnu dot org 2006-12-13 16:50 --- (In reply to comment #4) > Subject: Re: [4.3 Regression] > gcc.dg/pr19633-1.c fails on the mainline > > On Wed, 2006-12-13 at 14:12 +, dnovillo at gcc dot gnu dot org > wrote: > > Works for me with @119760 (mem-ssa) on all arches (x86, x86_64, ia64 > > and > > ppc64). > > So, this is about the mainline and not about the mem-ssa branch. I > don't see why you are looking at the mem-ssa branch's results except to > say something changed on the mainline to expose this issue. > You completely misunderstood. It works for me on my *mainline* tree that has the mem-ssa patch applied. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30194
[Bug tree-optimization/30194] [4.3 Regression] gcc.dg/pr19633-1.c fails on the mainline
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-12-13 16:59 --- (In reply to comment #5) > You completely misunderstood. It works for me on my *mainline* tree that has > the mem-ssa patch applied. Then why does it fail for FX right after your patch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30194
[Bug fortran/30202] ICE in trans-array.c
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-12-13 17:07 --- Confirmed. Fails on trunk as well. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet| i686-pc-linux-gnu |i686-pc-linux-gnu GCC host triplet| i686-pc-linux-gnu |i686-pc-linux-gnu GCC target triplet| i686-pc-linux-gnu |i686-pc-linux-gnu Known to fail||4.3.0 Last reconfirmed|-00-00 00:00:00 |2006-12-13 17:07:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30202
[Bug middle-end/30197] cexp ( __complex__ ( 0, x ) ) can be folded to cexpi (x)
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2006- ||12/msg00958.html Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-12-13 17:18:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30197
[Bug middle-end/30197] cexp ( __complex__ ( 0, x ) ) can be folded to cexpi (x)
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |ASSIGNED Last reconfirmed|2006-12-13 17:18:56 |2006-12-13 17:19:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30197
[Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory
--- Comment #8 from dnovillo at gcc dot gnu dot org 2006-12-13 17:32 --- http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00959.html fixes the ICE in the operand scanner. The alias times should be back to saner values, but the memory consumption problem is still there. Still looking into that. -- dnovillo at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|dnovillo at redhat dot com |dnovillo at gcc dot gnu dot ||org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-12-13 17:32:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089
[Bug libstdc++/30203] New: std::vector::size() 10x speedup (patch)
vector::size() in bits/stl_vector.h is currently implemented as
size_type
size() const
{ return size_type(end() - begin()); }
A faster implementation is
size_type
size() const
{ return _M_impl._M_finish - _M_impl._M_start; }
Which avoids the temporary iterators' life cycles
and operator- calls.
I tried a simple timing test on both implementations,
and the latter appears to be 10x faster:
(11:35:56)(charles xyzzy)(~): cat test.cc
#include
int main () {
std::vector x (100);
unsigned long l = 0;
const unsigned long iterations = 1;
for (unsigned long i=0; i
int main () {
std::vector x (100);
unsigned long l = 0;
const unsigned long iterations = 1;
for (unsigned long i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=30203
[Bug tree-optimization/30194] [4.3 Regression] gcc.dg/pr19633-1.c fails on the mainline
--- Comment #7 from dnovillo at gcc dot gnu dot org 2006-12-13 17:41 --- (In reply to comment #6) > (In reply to comment #5) > > You completely misunderstood. It works for me on my *mainline* tree that > > has > > the mem-ssa patch applied. > Then why does it fail for FX right after your patch? > I would love to find out. FX, do you have a pre-processed .i? Do you still have a cc1 that eliminates the call to link_error? What transformation removes it? Does it work with revision 119760? That's the revision that added the main mem-ssa changes (aliasing and rewriting). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30194
[Bug tree-optimization/30194] [4.3 Regression] gcc.dg/pr19633-1.c fails on the mainline
--- Comment #8 from dnovillo at gcc dot gnu dot org 2006-12-13 17:49 --- (In reply to comment #2) > Looks like the mem-ssa patches cause this. > There are no other patches in that time frame. > There must be. mem-ssa is @119760. If you can reproduce with @119760, then let me know and I'll take a look. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30194
[Bug tree-optimization/30194] [4.3 Regression] gcc.dg/pr19633-1.c fails on the mainline
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-12-13 17:59 --- (In reply to comment #8) > There must be. mem-ssa is @119760. If you can reproduce with @119760, then > let me know and I'll take a look. I can reproduce it at @119761 which is the same revision for the trunk as 119761 was a revision on a branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30194
[Bug libstdc++/30204] New: std::vector operator[] 10x speedup (patch)
vector::operator[](size_type) in bits/stl_vector.h is currently implemented as
reference
operator[](size_type __n)
{ return *(begin() + __n); }
const_reference
operator[](size_type __n) const
{ return *(begin() + __n); }
A faster implementation would be:
reference
operator[](size_type __n)
{ return _M_impl._M_start[__n]; }
const_reference
operator[](size_type __n) const
{ return _M_impl._M_start[__n]; }
I tried a simple timing test on both implementations,
and the latter appears to be 10x faster:
(11:59:43)(charles xyzzy)(~): cat test.cc
#include
int main () {
std::vector x (100);
unsigned long l = 0;
const unsigned long iterations = 1;
for (unsigned long i=0; i
int main () {
std::vector x (100);
unsigned long l = 0;
const unsigned long iterations = 1;
for (unsigned long i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=30204
[Bug libstdc++/30203] std::vector::size() 10x speedup (patch)
--- Comment #1 from chris at bubblescope dot net 2006-12-13 18:07 --- -O1 is enough to remove all advantages of this patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30203
[Bug libstdc++/30204] std::vector operator[] 10x speedup (patch)
--- Comment #1 from chris at bubblescope dot net 2006-12-13 18:08 --- -O1 is enough to remove all advantages of this patch. Also, that isn't really a fair timing comparison, as you've removed the function call altogether (I still expect it to be faster, but possibly not by 10x) -- chris at bubblescope dot net changed: What|Removed |Added CC||chris at bubblescope dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30204
[Bug testsuite/30181] FAIL: gcc.dg/builtins-57.c scan-tree-dump trunc
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2006-12-13 18:11 --- Subject: Re: FAIL: gcc.dg/builtins-57.c scan-tree-dump trunc > This is a testsuite failure as this testcase will fail on targets which don't > have C99 math functions. Target has trunc but not lfloor. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30181
[Bug testsuite/30157] cxa_atexit check doesn't work
--- Comment #1 from danglin at gcc dot gnu dot org 2006-12-13 18:47 --- Subject: Bug 30157 Author: danglin Date: Wed Dec 13 18:47:04 2006 New Revision: 119842 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119842 Log: PR testsuite/30157 * lib/target-supports.exp (check_cxa_atexit_available): Return false for target "hppa.*hpux10". Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/target-supports.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30157
[Bug testsuite/30157] cxa_atexit check doesn't work
--- Comment #2 from danglin at gcc dot gnu dot org 2006-12-13 18:49 --- Subject: Bug 30157 Author: danglin Date: Wed Dec 13 18:49:16 2006 New Revision: 119843 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119843 Log: PR testsuite/30157 * lib/target-supports.exp (check_cxa_atexit_available): Return false for target "hppa.*hpux10". Modified: branches/gcc-4_2-branch/gcc/testsuite/ChangeLog branches/gcc-4_2-branch/gcc/testsuite/lib/target-supports.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30157
[Bug middle-end/30201] gcc doesn't unroll nested loops
--- Comment #2 from jacob at math dot jussieu dot fr 2006-12-13 18:54
---
Not understanding much in compiler stuff, I tried what you said, namely replace
the loop with
for( int i = 0; i < 3; i++ )
for( int j = 0; j < 3; j++ )
{
bool a = (i == j);
(*this)(i, j) = a * factor;
}
and compile with -O3 -funroll-loops, and toto ran in 1.1 seconds. That's better
than the original 1.9 seconds, but still far from the 0.3 seconds I get
manually unrolling the loop.
Do you think there is a chance to have this bug fixed in 4.2.x or 4.3.x ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30201
[Bug middle-end/30201] gcc doesn't unroll nested loops
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-12-13 18:56 --- (In reply to comment #2) > than the original 1.9 seconds, but still far from the 0.3 seconds I get > manually unrolling the loop. Try with -ffast-math, you should get the same speed. Again the problem is with signed zeros to be able to get down to what you have with the manually unrolled loop. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30201
[Bug testsuite/30157] cxa_atexit check doesn't work
--- Comment #3 from danglin at gcc dot gnu dot org 2006-12-13 18:58 --- Fixed. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30157
[Bug middle-end/30191] [4.3 Regression] GCC error: in eliminate_regs_in_insn, at reload1.c:3126
--- Comment #6 from bergner at gcc dot gnu dot org 2006-12-13 19:19 --- Subject: Bug 30191 Author: bergner Date: Wed Dec 13 19:19:03 2006 New Revision: 119844 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119844 Log: PR middle-end/30191 Revert: * reload1.c (eliminate_regs_in_insn): Merge the plus_src "else" and the offset == 0 "then" clauses. * config/rs6000/predicates.md (gpc_reg_operand): Check for reload_in_progress. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/predicates.md trunk/gcc/reload1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30191
[Bug middle-end/30191] [4.3 Regression] GCC error: in eliminate_regs_in_insn, at reload1.c:3126
--- Comment #7 from bergner at vnet dot ibm dot com 2006-12-13 19:25 --- Ok, the reload fix has been reverted until we can find another way to fix this. Sorry for all of the trouble. Author: bergner Date: Wed Dec 13 19:19:03 2006 New Revision: 119844 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119844 Log: PR middle-end/30191 Revert: * reload1.c (eliminate_regs_in_insn): Merge the plus_src "else" and the offset == 0 "then" clauses. * config/rs6000/predicates.md (gpc_reg_operand): Check for reload_in_progress. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/predicates.md trunk/gcc/reload1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30191
[Bug fortran/30200] valgrind errors for write statement
--- Comment #1 from jv244 at cam dot ac dot uk 2006-12-13 19:28 --- This problem seems to be at the root of most CP2K regtest failures described in PR29975 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30200
[Bug middle-end/30191] [4.3 Regression] GCC error: in eliminate_regs_in_insn, at reload1.c:3126
-- bergner at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bergner at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-12-13 09:25:53 |2006-12-13 19:33:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30191
[Bug middle-end/30191] [4.3 Regression] GCC error: in eliminate_regs_in_insn, at reload1.c:3126
--- Comment #8 from bergner at gcc dot gnu dot org 2006-12-13 19:34 --- The offending patch has been reverted. -- bergner at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30191
[Bug testsuite/30119] libjava testsuite output is erratic and unhelpful
--- Comment #8 from amylaar at gcc dot gnu dot org 2006-12-13 19:47 --- (In reply to comment #7) Sorry, I misunderstood you. Now the test works - most of the time: [EMAIL PROTECTED]:~/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/libjava/testsuite$ /home/amylaar/bld/2006-11-27-29858/i686/gcc/gcj -B/home/amylaar/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/libjava/ -B/home/amylaar/bld/2006-11-27-29858/i686/gcc/ --encoding=UTF-8 -C -I/home/amylaar/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/libjava/testsuite/../libgcj-4.3.0.jar -g /home/amylaar/bld/2006-11-27-29858/srcw/libjava/testsuite/libjava.lang/PR18699.java -d /home/amylaar/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/libjava/testsuite [EMAIL PROTECTED]:~/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/libjava/testsuite$ export ld_library_path=.:/home/amylaar/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/./libjava/.libs:/home/amylaar/bld/2006-11-27-29858/i686/gcc [EMAIL PROTECTED]:~/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/libjava/testsuite$ export LD_LIBRARY_PATH=.:/home/amylaar/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/./libjava/.libs:/home/amylaar/bld/2006-11-27-29858/i686/gcc:.:/home/amylaar/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/./libjava/.libs:/home/amylaar/bld/2006-11-27-29858/i686/gcc:.:/home/amylaar/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/./libjava/.libs:/home/amylaar/bld/2006-11-27-29858/i686/gcc:/home/amylaar/bld/2006-11-27-29858/i686/./bfd/.libs:/home/amylaar/bld/2006-11-27-29858/i686/./prev-bfd/.libs:/home/amylaar/bld/2006-11-27-29858/i686/./opcodes/.libs:/home/amylaar/bld/2006-11-27-29858/i686/./prev-opcodes/.libs:/home/amylaar/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/libstdc++-v3/.libs:/home/amylaar/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/libmudflap/.libs:/home/amylaar/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/libssp/.libs:/home/amylaar/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/libgomp/.libs:/home/amylaar/bld/2006-11-27-29858/i686/./gcc:/home/amylaar/bld/2006-11-27-29858/i686/./prev-gcc [EMAIL PROTECTED]:~/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/libjava/testsuite$ ../gij -classpath .:../libgcj-4.3.0.jar PR18699 Exception in thread "Thread-2" java.lang.NullPointerException at PR18699.update(PR18699.java:34) at java.util.Observable.notifyObservers(Observable.java:171) at PR18699.run(PR18699.java:26) at java.lang.Thread.run(Thread.java:682) [EMAIL PROTECTED]:~/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/libjava/testsuite$ ../gij -classpath .:../libgcj-4.3.0.jar PR18699 [EMAIL PROTECTED]:~/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/libjava/testsuite$ echo $? 0 [EMAIL PROTECTED]:~/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/libjava/testsuite$ ../gij -classpath .:../libgcj-4.3.0.jar PR18699 [EMAIL PROTECTED]:~/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/libjava/testsuite$ echo $? 0 [EMAIL PROTECTED]:~/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/libjava/testsuite$ ../gij -classpath .:../libgcj-4.3.0.jar PR18699 [EMAIL PROTECTED]:~/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/libjava/testsuite$ echo $? 0 [EMAIL PROTECTED]:~/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/libjava/testsuite$ ../gij -classpath .:../libgcj-4.3.0.jar PR18699 [EMAIL PROTECTED]:~/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/libjava/testsuite$ echo $? 0 I have no idea how to make it repeat the null pointer exception, except trying very often. Here is another one: [EMAIL PROTECTED]:~/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/libjava/testsuite$ ../gij -classpath .:../libgcj-4.3.0.jar PR18699 [EMAIL PROTECTED]:~/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/libjava/testsuite$ ../gij -classpath .:../libgcj-4.3.0.jar PR18699 Exception in thread "Thread-1" java.lang.NullPointerException at PR18699.update(PR18699.java:34) at java.util.Observable.notifyObservers(Observable.java:171) at PR18699.run(PR18699.java:26) at java.lang.Thread.run(Thread.java:682) [EMAIL PROTECTED]:~/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/libjava/testsuite$ free total used free sharedbuffers cached Mem: 1036088 969192 66896 0 448352 147260 -/+ buffers/cache: 373580 662508 Swap: 755012 0 755012 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30119
[Bug fortran/30200] valgrind errors for write statement
--- Comment #2 from burnus at gcc dot gnu dot org 2006-12-13 19:47 --- Simplified version (might not cover all problems): character(len=20) myfmt myfmt="(1X,a,'x')" WRITE(*,fmt=trim(myfmt)) "y" END If one looks now at the dump: _gfortran_string_trim (&len.2, (void * *) &pstr.1, 20, &myfmt); dt_parm.0.format = pstr.1; dt_parm.0.format_len = len.2; _gfortran_st_write (&dt_parm.0); _gfortran_internal_free (pstr.1); _gfortran_transfer_character (&dt_parm.0, "y", 1); _gfortran_st_write_done (&dt_parm.0); I'm not sure whether this is the problem, but pstr.1 is freed before "y" is send to "write" - but the string has to be written after "y". -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2006-12-13 19:47:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30200
[Bug libfortran/30200] write(*,myfmt="(1X,a,'xyz')") "A" prints Az' instead of Axyz
--- Comment #3 from burnus at gcc dot gnu dot org 2006-12-13 20:11 --- CC: some more libgfortran/io experienced persons. There seems to go something wrong when one uses format = "(1X,a,'xyz')" write(*,fmt=trim(format)) "A" The result is: Az' Expected: Axyz The values in write_constant_string are: length = 3 // ok q[-1] = '' (0) // should be ' q[0] = '' (0)// should be x q[1] = 'y' (121) q[2] = 'z' (122) The following works: - no trim - format = "(1X,'abc',a,'xyz')" - format = "(1X,'abc',a)" - format = "(1X,'xyz')" -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu dot ||org, Thomas dot Koenig at ||online dot de Component|fortran |libfortran Summary|valgrind errors for write |write(*,myfmt="(1X,a,'xyz')" |statement |) "A" prints Az' instead ||of Axyz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30200
[Bug middle-end/30201] gcc doesn't unroll nested loops
--- Comment #4 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-12-13 20:22 ---
Subject: Re: gcc doesn't unroll nested loops
> Not understanding much in compiler stuff, I tried what you said, namely
> replace
> the loop with
>
> for( int i = 0; i < 3; i++ )
> for( int j = 0; j < 3; j++ )
> {
> bool a = (i == j);
> (*this)(i, j) = a * factor;
> }
>
> and compile with -O3 -funroll-loops, and toto ran in 1.1 seconds. That's
> better
> than the original 1.9 seconds, but still far from the 0.3 seconds I get
> manually unrolling the loop.
>
> Do you think there is a chance to have this bug fixed in 4.2.x or 4.3.x ?
most likely not in 4.2. I think something could be done in 4.3 timeframe.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30201
[Bug middle-end/30201] gcc doesn't unroll nested loops
--- Comment #5 from jacob at math dot jussieu dot fr 2006-12-13 20:22 --- Nope... with -O3 -ffast-math I get 1.9 seconds in average (this is a laptop with CPU frequency scaling, so it's difficult to get precise numbers). Adding -funroll-loops in addition to -ffast-math doesn't seem to make a difference. We're very far from the 0.3 seconds I get with -DUNROLL. Also, trying again -O3 -funroll-loops, I get again 1.9 seconds, so I think -funroll-loops didn't make any difference and I had been fooled by CPU frequency scaling. The problem with the multiplication is not important to me, it's just something I used in this example. I could as well have written for( int i = 0; i < 3; i++ ) for( int j = 0; j < 3; j++ ) (*this)(i, j) = (i == j) ? factor : 0; But this turns out to be even slower. I presume that's because, as the loops don't get both unrolled, the test i==j ?: makes branches at run-time. Anyway thanks for being supportive and having looked into my problem. May I ask again, can I hope for a fully-unrolling-nested-loops g++ in the near future? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30201
[Bug middle-end/30201] gcc doesn't unroll nested loops
--- Comment #6 from jacob at math dot jussieu dot fr 2006-12-13 20:24 --- (In reply to comment #4) > most likely not in 4.2. I think something could be done in 4.3 timeframe. ah, ok. Thanks for the information. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30201
[Bug tree-optimization/30087] regressions in the gfortran testsuite with -ftree-vectorize
--- Comment #3 from tobi at gcc dot gnu dot org 2006-12-13 20:46 --- Fixed by Ira in r119730, thanks. -- tobi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30087
[Bug libfortran/30200] write(*,myfmt="(1X,a,'xyz')") "A" prints Az' instead of Axyz
--- Comment #4 from tkoenig at gcc dot gnu dot org 2006-12-13 21:12 --- (In reply to comment #3) > CC: some more libgfortran/io experienced persons. > > There seems to go something wrong when one uses > format = "(1X,a,'xyz')" > write(*,fmt=trim(format)) "A" > The result is: > Az' WORKSFORME: $ cat foo.f90 program main character (len=20) format format = "(1X,a,'xyz')" write(*,fmt=trim(format)) "A" end $ gfortran foo.f90 $ ./a.out Axyz $ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../../gcc/trunk/configure --prefix=/home/ig25 --enable-languages=c,fortran Thread model: posix gcc version 4.3.0 20061127 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30200
[Bug fortran/30202] ICE in trans-array.c
--- Comment #3 from burnus at gcc dot gnu dot org 2006-12-13 21:32 --- ICE is gone, if one removes intent(out). ICE is at gfc_conv_descriptor_data_addr: gcc_assert (GFC_DESCRIPTOR_TYPE_P (type)); program class_scal_p implicit none type scal_p real, allocatable :: b(:) end type scal_p type(scal_p) :: pd call psb_geallv(pd%b) contains subroutine psb_geallv(x) real, allocatable, intent(out) :: x(:) end subroutine psb_geallv end program class_scal_p -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus 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 | Keywords||ice-on-valid-code Known to fail|4.3.0 |4.2.0 4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30202
[Bug libfortran/29568] implement unformatted files with subrecords (Intel style)
--- Comment #36 from tkoenig at gcc dot gnu dot org 2006-12-13 21:37 --- Fixed for trunk and 4.2. Will not backport to 4.1. Closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29568
[Bug target/30192] [arm] Wrong sp value on exit after calling __floatdidf or __floatundidf
--- Comment #3 from John dot Tytgat at aaug dot net 2006-12-13 22:01 --- Proposed patch works fine. Interworking safeness isn't important for my target so that's why didn't consider your approach. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30192
[Bug target/30192] [arm] Wrong sp value on exit after calling __floatdidf or __floatundidf
--- Comment #4 from John dot Tytgat at aaug dot net 2006-12-13 22:03 --- Just to avoid confusion, in comment #3 I was talking about patch with id 12793, not mine. I've tested it and works equally well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30192
[Bug c++/30205] New: RFE: g++ --unmangle
g++ and gcj should take an --unmangle option (or some such). The effect would be to tell ld to deliver its undefined symbols error messages with names that have been unmangled by the algorithm appropriate to the language used. Actually, I think this should be the default, and you should have to do --no-unmangle to get the existing behavior. Or, deliver the symbols both ways, like this: __ZN9trapNamer5parseER3rowIKcE\ttrapNamer::parse(row&) __ZN10trapNamerJC1EP9trapNamer\ttrapNamerJ::trapNamerJ(trapNamer*) with command-line options to show one, the other, or both forms. -- Summary: RFE: g++ --unmangle Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Dave at Yost dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30205
[Bug fortran/30206] New: Fatal Error: Reading module: Bad name
This problem occurs after creating a module file with one compilation, and then trying to use that module file in a second compilation, as shown below: # gfortran -I/usr/local/openmpi-1.1.2-gcc/include -c -Wall -Jmod -I. -Imod -g Source/Constants.f90 -o obj/Constants.o # gfortran -I/usr/local/openmpi-1.1.2-gcc/include -c -Wall -Jmod -I. -Imod -g Source/Timer.f90 -o obj/Timer.o Fatal Error: Reading module constants at line 3 column 2: Bad name All Timer.f90 needs to cause the problem is a "USE CONSTANTS" line. I'm running gfortran 4.1.0 on RHEL4. Thanks, Dennis -- Summary: Fatal Error: Reading module: Bad name Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dmcr at Princeton dot EDU http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30206
[Bug fortran/30206] Fatal Error: Reading module: Bad name
--- Comment #1 from dmcr at Princeton dot EDU 2006-12-13 22:24 --- Created an attachment (id=12798) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12798&action=view) The source file whose module file appears to be corrupt -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30206
[Bug fortran/30206] Fatal Error: Reading module: Bad name
--- Comment #2 from dmcr at Princeton dot EDU 2006-12-13 22:25 --- Created an attachment (id=12799) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12799&action=view) Module file created by gfortran from Constants.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30206
[Bug fortran/30206] Fatal Error: Reading module: Bad name
--- Comment #3 from dmcr at Princeton dot EDU 2006-12-13 22:26 --- Created an attachment (id=12800) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12800&action=view) Source file that contains "USE CONSTANTS" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30206
[Bug tree-optimization/30194] [4.3 Regression] gcc.dg/pr19633-1.c fails on the mainline
--- Comment #10 from dnovillo at gcc dot gnu dot org 2006-12-13 22:37 --- (In reply to comment #9) > (In reply to comment #8) > > There must be. mem-ssa is @119760. If you can reproduce with @119760, then > > let me know and I'll take a look. > > I can reproduce it at @119761 which is the same revision for the trunk as > 119761 was a revision on a branch. > OK, I'll take a look. FX mind sending me that data about the test? I can't reproduce it locally. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30194
[Bug fortran/30206] Fatal Error: Reading module: Bad name
--- Comment #4 from kargl at gcc dot gnu dot org 2006-12-13 23:22 --- You code compiles fine with newer versions of gfortran troutmask:sgk[224] gfc --version GNU Fortran 95 (GCC) 4.2.0 20060927 (experimental) troutmask:sgk[225] gfc4x --version GNU Fortran 95 (GCC) 4.3.0 20061211 (experimental) Note gfortran 4.1.0 has numerous bugs that may never be fixed in the 4.1 branch, which are fixed in 4.2.x and 4.3.x. You'll lead a much less painful life if you upgrade gfortran to one available from the gfortran wiki. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30206
[Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory
--- Comment #9 from dnovillo at gcc dot gnu dot org 2006-12-13 23:50 --- The memory problem is quite simple: We just have a *lot* of pointers and a *lot* of addressable symbols. Here is a breakdown of what happens on the first call to compute_may_aliases: During the first call to compute_may_aliases: 1- Size of cc1plus is 339Mb 2- Call to compute_points_to_sets grows to 355Mb (+4.72%) 3- Call to compute_flow_insensitive_aliasing grows to 364Mb (+2.54%) 4- Call to compute_flow_sensitive_aliasing grows to 667Mb (+83.2%) The reason for this tremendous growth is quite simple. There are 39,010 SSA name pointers and many of them have their own points-to set, which we store in that name's may-alias set. We grow to 667Mb in the last loop of compute_flow_sensitive_aliasing. One thing we could do is just not use flow-sensitive information in these cases. If we don't set SSA_NAME_PTR_INFO, everything will default to flow-insensitive information and things will Just Work. Perhaps using sparse bitmaps for the may-alias sets might help with memory consumption, but I found these bitmaps to slow down the operand scanner quite a bit in the past. May be worth a try. Danny, thoughts? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089
[Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory
--- Comment #10 from dnovillo at gcc dot gnu dot org 2006-12-13 23:54 --- (In reply to comment #9) > The memory problem is quite simple: We just have a *lot* of pointers and a > *lot* of addressable symbols. Here is a breakdown of what happens on the > first > call to compute_may_aliases: > > During the first call to compute_may_aliases: > This is in the function ffparse, BTW. Which has alias sets with 4.2 million elements. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089
[Bug libfortran/30193] Namelist issues when reading in asterisk preceeded arrays
--- Comment #7 from jvdelisle at verizon dot net 2006-12-14 00:12 --- Subject: Re: Namelist issues when reading in asterisk preceeded arrays Thanks for checking the latest 4.1, I just updated my 4.1 branch last night and I had not had a chance to check it. Also, the namelist I/O predates the existence of array triplet notation. It is common to interpret ihp(1,1) = 2*1 to mean fill out the array from that starting element. You will see that if you compile the example with -pedantic that you will get: $./a.out At line 16 of file name.f90 Fortran runtime warning: Non-standard expanded namelist read. With -std=f95 we throw a runtime error. gfortran knows its not standard. ;) (I implemented that feature after much discussion on the list.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30193
[Bug libfortran/30200] write(*,myfmt="(1X,a,'xyz')") "A" prints Az' instead of Axyz
--- Comment #5 from jvdelisle at verizon dot net 2006-12-14 00:26 --- Subject: Re: write(*,myfmt="(1X,a,'xyz')") "A" prints Az' instead of Axyz I wonder if this is not a case of the io.h dependency bug hitting yet again. I would fix it if I knew how. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30200
[Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory
--- Comment #11 from dberlin at gcc dot gnu dot org 2006-12-14 01:11 --- Subject: Re: Compiling FreeFem3d uses unreasonable amount of time and memory On 13 Dec 2006 23:50:17 -, dnovillo at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > > > --- Comment #9 from dnovillo at gcc dot gnu dot org 2006-12-13 23:50 > --- > > The memory problem is quite simple: We just have a *lot* of pointers and a > *lot* of addressable symbols. Here is a breakdown of what happens on the > first > call to compute_may_aliases: > > During the first call to compute_may_aliases: > > 1- Size of cc1plus is 339Mb > 2- Call to compute_points_to_sets grows to 355Mb (+4.72%) > 3- Call to compute_flow_insensitive_aliasing grows to 364Mb (+2.54%) > 4- Call to compute_flow_sensitive_aliasing grows to 667Mb (+83.2%) > > The reason for this tremendous growth is quite simple. There are 39,010 SSA > name pointers and many of them have their own points-to set, which we store in > that name's may-alias set. If they had their own set, then compute_points_to_set would have required more memory. >We grow to 667Mb in the last loop of > compute_flow_sensitive_aliasing. > > One thing we could do is just not use flow-sensitive information in these > cases. If we don't set SSA_NAME_PTR_INFO, everything will default to > flow-insensitive information and things will Just Work. > > Perhaps using sparse bitmaps for the may-alias sets might help with memory > consumption, but I found these bitmaps to slow down the operand scanner quite > a > bit in the past. May be worth a try. > > Danny, thoughts? If compute_points_to_sets only grows memory by 26 meg, then that's all we need to represent the points-to sets of all these variables So we shoudl be able to do this without using more memory than that. Sadly, we create copies of the result of find_what_p_points_to, then transform it into an array. I'll give the bitmaps a try for the operand scanner and see how it works. I really don't think we should have to turn off information that is only taking 26 meg to store originally :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089
[Bug fortran/25392] ICEs with -ff2c
--- Comment #7 from tobi at gcc dot gnu dot org 2006-12-14 01:18 --- I have a patch, but it adds another ugly layer of code, I'll try to clean this mess up and then submit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25392
[Bug libfortran/30200] write(*,myfmt="(1X,a,'xyz')") "A" prints Az' instead of Axyz
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-12-14 02:29 --- More information. I get Tobias bad result with -m64 on x86-64-Linux. The problem goes away with -m32. $ gfortran -m32 pr30200-2.f90 $ ./a.out Axyz $ gfortran -m64 pr30200-2.f90 $ ./a.out Az' I get a similar result with the orginal test case from Joost. The problem is -m64 specific. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30200
[Bug libstdc++/30203] std::vector::size() 10x speedup (patch)
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-14 02:47 --- Can you test with -O1 or above? As mentioned in comment #1, this should remove all advatages gained from the "inlined" version. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30203
[Bug libstdc++/30204] std::vector operator[] 10x speedup (patch)
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-14 02:49 --- Can you test with -O1 or above? As mentioned in comment #1, this should remove all advatages gained from the "inlined" version. > Also, that isn't really a fair timing comparison, as you've removed the > function call altogether (I still expect it to be faster, but possibly not by > 10x) For -O0, I would not doubt removing the function calls get a 10x speed up, which is one of the reasons why -O1 makes this much faster than -O0 :). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30204
[Bug tree-optimization/30089] Compiling FreeFem3d uses unreasonable amount of time and memory
--- Comment #12 from dnovillo at gcc dot gnu dot org 2006-12-14 02:50 --- (In reply to comment #11) > I'll give the bitmaps a try for the operand scanner and see how it works. > OK. Hopefully that won't introduce a huge slowdown in the operand scanner. Assigning back to you. -- dnovillo at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|dnovillo at gcc dot gnu dot |dberlin at gcc dot gnu dot |org |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30089
[Bug c++/30205] RFE: g++ --unmangle
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-14 02:54 --- You should use -Wl,--demangle really. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30205
