[Bug boehm-gc/31999] New: "Make -i check" finds one, and fails to find another, boehm-gc problem
While tackling this bug ( http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31998 ) I found a problem with the boehm-gc. This is a seperate bug report only about boehm-gc (and not about the interrelated issues of the above report). /gcc/xgcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /root/downloads/gcc-4_2-branch/configure --verbose --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --with-tune=athlon-xp --prefix=/usr --enable-objc-gc --enable-concept-checks --disable-multilib --with-gxx-include-dir=/usr/include/c++/4.2 --enable-libstdcxx-debug --enable-static --enable-shared --enable-initfini-array --enable-__cxa_atexit --enable-threads=posix --enable-version-specific-runtime-libs --enable-libssp --enable-libmudflap --enable-libgomp --disable-werror --enable-nls --with-included-gettext --enable-decimal-float --with-long-double-128 --enable-debug --enable-java-gc=boehm --with-x --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --enable-java-awt=gtk,xlib --enable-gtk-cairo --enable-qt-peer --enable-xmlj --enable-gconf-peer --enable-tool-wrappers --with-gjdoc --enable-portable-native-sync --enable-libgcj-multifile --with-stabs --enable-hash-synchronization --enable-gc-debug --enable-interpreter --with-system-zlib --enable-libada --with-tls --with-cpu=athlon-xp --with-arch=athlon-xp --enable-stage1-checking=assert,fold,gc,misc,rtl,rtlflag,runtime,tree Thread model: posix gcc version 4.2.1 20070515 (prerelease) Three things. 1): When running "make -i check" the boehm tests don't make "gctest" correctly. I had to build gctest by hand and it _seems_ to work. I am debugging a error that is the subject of a different bug report so I had to branch over to check if there was a problem with boehm-gc. Here is the output of "make -i check": # /opt/gcc-4_2-build/./gcc/xgcc -B/opt/gcc-4_2-build/./gcc/ -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 -fexceptions -Iinclude -I././targ-include -I.//libc/include -I/root/downloads/gcc-4_2-branch/boehm-gc/include -O2 -g -O2 -o .libs/gctest -shared-libgcc /root/downloads/gcc-4_2-branch/boehm-gc/tests/test.c /root/downloads/gcc-4_2-branch/boehm-gc/pthread_support.c ./.libs/libgcjgc.so -lpthread -ldl /tmp/ccTiGNJU.o: In function `mktree': /root/downloads/gcc-4_2-branch/boehm-gc/tests/test.c:798: undefined reference to `GC_local_malloc' /root/downloads/gcc-4_2-branch/boehm-gc/tests/test.c:807: undefined reference to `GC_local_malloc_atomic' /tmp/ccTiGNJU.o: In function `local_cons': /root/downloads/gcc-4_2-branch/boehm-gc/tests/test.c:264: undefined reference to `GC_local_malloc' /root/downloads/gcc-4_2-branch/boehm-gc/tests/test.c:267: undefined reference to `GC_local_gcj_malloc' collect2: ld returned 1 exit status # Add -DGC_DEBUG and the compile error goes away (since that avoids the defines, but doesn't fix the _actual_ problem). I'll build it static: # /opt/gcc-4_2-build/./gcc/xgcc -DGC_DEBUG -B/opt/gcc-4_2-build/./gcc/ -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 -fexceptions -Iinclude -I././targ-include -I.//libc/include -I/root/downloads/gcc-4_2-branch/boehm-gc/include -O2 -g -O2 -o .libs/gctest -static /root/downloads/gcc-4_2-branch/boehm-gc/tests/test.c /root/downloads/gcc-4_2-branch/boehm-gc/pthread_support.c ./.libs/libgcjgc.a -lpthread -ldl # .libs/gctest Completed 3 tests Allocated 4863995 collectable objects Allocated 303 uncollectable objects Allocated 375 atomic objects Allocated 34440 stubborn objects Finalized 3302/3302 objects - finalization is probably ok Total number of bytes allocated is 621142336 Final heap size is 20967424 bytes Collector appears to work Completed 195 collections # Each time you run gctest the test passes but the numbers above are a little different - depending on available memory at a particular moment. Which means it is non-deterministic (can interfere with debugging). 2): I don't know that boehm is integrated with GCC in accordance with the recommendations provided in the boehm DOCs. The file: file:///root/downloads/gcc-4_2-branch/boehm-gc/doc/README.linux says: To use threads, you need to abide by the following requirements: ... 2) You must compile the collector with -DGC_LINUX_THREADS and -D_REENTRANT specified in the Makefile. 3a) Every file that makes thread calls should define GC_LINUX_THREADS and _REENTRANT and then include gc.h. Gc.h redefines some of the pthread primitives as macros which also provide the collector with information it requires. 3b) A new alternative to (3a) is to build the collector and compile GC clients with -DGC_USE_LD_WRAP, and to link the final program with (for ld) --wrap read --wrap dlopen --wrap pthread_create \ --wrap pthread_join --wrap pthread_detach \ --wrap pthread_sigmask --wrap sleep (for gcc) -Wl,
[Bug fortran/31615] testsuite failure in gfortran.dg/vect/vect-5.f90
--- Comment #8 from ghazi at gcc dot gnu dot org 2007-05-19 06:02 --- fixed: http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00150.html by this patch: http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01733.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31615
[Bug bootstrap/31998] New: Incorrect "Unreachable statement" turns off optimizing + spec file in error
This "spec bug" probably affects other targets too. I did search for "Unreachable" "statement" and came up ONE hit - unrelated: "Unreachable code at beginning of switch " http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25314 It seems that is a complicated issue that is interrelated with a few factors that are un-reported - so I will need to do some more debugging and focus this report on the problem with the spec file. If you don't want to "see the work" (proof?) just scroll to the end. --- I set out to try to do ONE thing - to try to find out why there were a few warnings during the compile of i686-pc-linux-gnu/libjava/... While trying to track down the cause I found a few interrelated problems. I prefer not to group together problems but keep them seperate but the 1st portion is more a "comment" about the problem with optimizing shutting off and the 2nd part is the "bug" I found while researching the problem. _THIS_ bug report is only on "Unreachable statement" turns off optimizing _AND_ spec file (or internal specs) are in error for gcc compiled with these parameters (a different bug report covers the boehm-gc): #gcc/xgcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /root/downloads/gcc-4_2-branch/configure --verbose --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --with-tune=athlon-xp --prefix=/usr --enable-objc-gc --enable-concept-checks --disable-multilib --with-gxx-include-dir=/usr/include/c++/4.2 --enable-libstdcxx-debug --enable-static --enable-shared --enable-initfini-array --enable-__cxa_atexit --enable-threads=posix --enable-version-specific-runtime-libs --enable-libssp --enable-libmudflap --enable-libgomp --disable-werror --enable-nls --with-included-gettext --enable-decimal-float --with-long-double-128 --enable-debug --enable-java-gc=boehm --with-x --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --enable-java-awt=gtk,xlib --enable-gtk-cairo --enable-qt-peer --enable-xmlj --enable-gconf-peer --enable-tool-wrappers --with-gjdoc --enable-portable-native-sync --enable-libgcj-multifile --with-stabs --enable-hash-synchronization --enable-gc-debug --enable-interpreter --with-system-zlib --enable-libada --with-tls --with-cpu=athlon-xp --with-arch=athlon-xp --enable-stage1-checking=assert,fold,gc,misc,rtl,rtlflag,runtime,tree Thread model: posix gcc version 4.2.1 20070515 (prerelease) --- Notes: --- When compiling "gcc version 4.2.1 20070515" I noticed that some warnings were occurring in the "i686-pc-linux-gnu/libjava/..." directories on a few files. Some of these warnings are "unused parameter" and some are "Unreachable statement". I wanted to see what the problem was ... I examined "natVMFrame.cc", "natVMVirtualMachine.cc", and "Base64.java" (shown below). I set out to examine the cause of these warnings. I am concerned about optimization and the warning "Unreachable statement" in file /root/downloads/gcc-4_2-branch/libjava/classpath/gnu/java/security/util/Base64.java since it is NOT true. The variable "outBuffPosn" is initialized in the event that len=0 and the loop gets skipped. If len!=0 (I suggest that is the most likely case) then the loop should not be skipped (thus we should not have a "warning: Unreachable statement." message). It concerns me that if the statement is unreachable then shouldn't the optimizer remove that section of the code (even with -O3, it doesn't) . If that section of code gets removed then the function would always return the same result - thus it could be inlined. Since GCC hit an "Unreachable statement" it gave up optimizing. The code seems well written. I would hate to see the code changed from: byte sbiCrop, sbiDecode; for (i = off; i < off + len; i++) to byte sbiCrop, sbiDecode; len++; for (i = off; i < off + (len-1); i++) Which, (of course), is stupid and doesn't work due to "final". Lets look at the screen output of the build for a moment: name=`echo classpath/lib/gnu/gcj/xlib/XImage.class | sed -e 's/\.class$//' -e 's,classpath/lib/,,'`; \ /root/downloads/gcc-4_2-branch/mkinstalldirs `dirname $name`; \ ./../.././gcc/gcjh -d . -classpath '' -bootclasspath classpath/lib $name name=`echo classpath/lib/gnu/gcj/xlib/XUnmapEvent.class | sed -e 's/\.class$//' -e 's,classpath/lib/,,'`; \ /root/downloads/gcc-4_2-branch/mkinstalldirs `dirname $name`; \ ./../.././gcc/gcjh -d . -classpath '' -bootclasspath classpath/lib $name make[4]: Leaving directory `/opt/gcc-4_2-build/i686-pc-linux-gnu/libjava' depbase=`echo jni-libjvm.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`; \ (...a dozen lines) depbase=`echo prims.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`; \ if /bin/sh ./libtool --mode=compile /opt/gcc-4_2-build/./gcc/xgcc -shared-libgcc -B/opt/gcc-4_2-build/./gcc -nostdinc++ -L/opt/gcc-4_2-build/i686-pc-linux-gnu/libstdc++-v3/src -L/opt/gcc-4_2-build/i686-pc-linux-gnu/libstdc++-v3/src/.libs -B/usr/i686-pc-linux-gnu/bin/ -B/usr/i686-pc-linux-gnu/lib/ -isystem /usr/i
[Bug middle-end/30250] Evaluate lgamma/gamma at compile-time
--- Comment #5 from ghazi at gcc dot gnu dot org 2007-05-19 05:18 --- Subject: Bug 30250 Author: ghazi Date: Sat May 19 04:18:05 2007 New Revision: 124849 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124849 Log: PR middle-end/30250 * builtins.c (do_mpfr_lgamma_r): New. (fold_builtin_2): Handle builtin gamma_r/lgamma_r. * tree.h (CASE_FLT_FN_REENT): New. testsuite: * gcc.dg/torture/builtin-math-2.c: Add gamma_r/lgamma_r tests. * gcc.dg/torture/builtin-math-4.c: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/torture/builtin-math-2.c trunk/gcc/testsuite/gcc.dg/torture/builtin-math-4.c trunk/gcc/tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30250
[Bug middle-end/31796] Evaluate remquo/remainder/drem at compile-time
--- Comment #4 from ghazi at gcc dot gnu dot org 2007-05-19 05:14 --- Functionality installed on trunk. -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31796
[Bug middle-end/30251] Evaluate bessel functions at compile-time
--- Comment #5 from ghazi at gcc dot gnu dot org 2007-05-19 05:12 --- Functionality installed on trunk. -- ghazi 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=30251
[Bug target/31997] lots of messages: indirect jmp without `*'
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-19 04:34 --- I think this is fixed in 4.2.0 which was just released, i686-darwin was not that well supported in GCCs before 4.2.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Component|c++ |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31997
[Bug c++/31997] New: lots of messages: indirect jmp without `*'
gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../.././libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../.././libiberty/regex.c -o regex.o /var/tmp//ccaaq6Zh.s:10725:indirect jmp without `*' /var/tmp//ccaaq6Zh.s:10740:indirect jmp without `*' /var/tmp//ccaaq6Zh.s:10755:indirect jmp without `*' ... Happens with 4.1.1 also. -- Summary: lots of messages: indirect jmp without `*' Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Dave at Yost dot com GCC build triplet: 4.1.2 GCC host triplet: Mac OS X Intel GCC target triplet: Mac OS X Intel http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31997
[Bug fortran/20373] INTRINSIC symbols can be given the wrong type
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-05-19 03:47 --- This patch looks simple enough. Has it been regression tested? Anything else planned with this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20373
[Bug fortran/31994] conjg(transpose(a)) produces wrong answer.
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-05-19 03:38 --- Adding FX to cc. This is not a regression relative to 4.1, but its sure ugly! -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31994
[Bug fortran/31994] conjg(transpose(a)) produces wrong answer.
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-05-19 03:29 --- I see it here too. This is a frontend problem I think. Looks to me like its the transpose portion looking at -fdump-tree-original. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-19 03:29:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31994
[Bug libgomp/31974] [4.3 regression]: Many libgomp failures
--- Comment #3 from hjl at lucon dot org 2007-05-19 02:52 --- malloc is void *malloc(size_t size); and size_t is unsigned. I am not sure if checking size < 0 in Fortran is needed or done properly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31974
[Bug rtl-optimization/31830] Input parameter trashed with optimization -O when using a union and bit field
--- Comment #3 from gmorain at gmail dot com 2007-05-19 02:17 --- (In reply to comment #2) > I can reproduce the failure on powerpc-linux-gnu with 4.1.0 but it works on > the > trunk. combine is doing something wrong. > I tested it on 4.2.0, and it works OK. Except, I can't understand why the stack frame is 32 bytes instead of 16. powerpc-elf-objdump -S foo.o foo.o: file format elf32-powerpc Disassembly of section .text: : 0: 94 21 ff e0 stwur1,-32(r1) 4: 7c 08 02 a6 mflrr0 8: 93 a1 00 14 stw r29,20(r1) c: 90 01 00 24 stw r0,36(r1) 10: 7c 7d 1b 78 mr r29,r3 14: 48 00 00 01 bl 14 18: 53 a3 c0 0e rlwimi r3,r29,24,0,7 1c: 48 00 00 01 bl 1c 20: 80 01 00 24 lwz r0,36(r1) 24: 7c 08 03 a6 mtlrr0 28: 83 a1 00 14 lwz r29,20(r1) 2c: 38 21 00 20 addir1,r1,32 30: 4e 80 00 20 blr -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31830
[Bug fortran/31964] [4.2, 4.1 only]ishftc fails with certain thrid argument
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2007-05-19 02:10 --- Fixed on trunk, 4.3 -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Summary|ishftc fails with certain |[4.2, 4.1 only]ishftc fails |thrid argument |with certain thrid argument Target Milestone|--- |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31964
[Bug fortran/31964] ishftc fails with certain thrid argument
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2007-05-19 02:07 --- Subject: Bug 31964 Author: jvdelisle Date: Sat May 19 01:07:41 2007 New Revision: 124847 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124847 Log: 2007-05-18 Jerry DeLisle <[EMAIL PROTECTED]> PR libfortran/31964 * gfortran.fortran-torture/execute/intrinsic_bitops.f90: Update. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.fortran-torture/execute/intrinsic_bitops.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31964
[Bug fortran/31964] ishftc fails with certain thrid argument
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-05-19 02:04 --- Subject: Bug 31964 Author: jvdelisle Date: Sat May 19 01:04:03 2007 New Revision: 124846 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124846 Log: 2007-05-18 Jerry DeLisle <[EMAIL PROTECTED]> PR libfortran/31964 * intrinsics/ishftc.c (ishftc4, ishftc8, ishftc16): Fix mask to handle shift of bit-size number of bits. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/ishftc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31964
[Bug target/31990] udivdi3 not found for linux kernel
--- Comment #11 from malitzke at metronets dot com 2007-05-19 02:02 --- Well, this is getting funny. You and apparently others at gcc are looking at the computer-sofware world through a high powered telescope and in this drastically reduced field of vision you-all only see gcc. I refreshed my memory and the linux-kernel admits other compilers besides gcc, specifically for the arm hardware. It so happens that I started with UNIX using the Seventh Edition (late seventies) By the time of the Seventh Edition everything in Unix depended on the Ritchie assembler and the Ritchie C compiler. With the Intel i386 and the Compaq 386 I migrated to the SCO Xenix (an amalgamation of the AT&T kernel and AT&T UNIX utilities utilities plus some BSD stuff like vi and an absolutely lousy Microsoft C compiler. Even so I managed to migrate with this compiler to the Public Domain Korn Shell (pdksh). In order to get to bash I had to hack gcc to produce xout object code (really *.s files) as the libraries were all in that xout format and to port the BSD libraries was too much work for one person. Therfore I learnt to patch gcc., and got bash as a result. I also played with the GNU utilities, but the original Unix ulities were quite adequate. This cozy little world collapsed when gcc underwent a complete rewite from gcc-2.58 to gcc-2.60 (no patches). The salvation was in the then quite early linux kernel. But I had to hack the kernel to read the Xenix formatted hard drives with their hermaphroditic addressing. (the linux kernel to his day sports some drivers for Xenix SYSV and Coherent, but at least for Xenix these drivers work only on floppies. Thus I became probaly one the few persons, who hacked both gcc and linux. At the same time I made MS-DOS livable using the Canadian Mortice Kern (UNIX emulation) package. I cheerfully admit to some biases one of which is that outstanding programmers like Ritchie, Torvalds, Stallmann were also accomplished assembly language programmers and that C is really a high level and portable assembly language. I really do not like all the stuff piled on top of the good old C. In the end, some of the stuff I hear about things like libgcc just make me smile. I have to say that me writing this brought me some joy, probaly much more than it has for somebody reading this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31990
[Bug tree-optimization/31996] can't determine dependence between p->a[x+i] and *((int *)p + x + i + 8)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31996
[Bug tree-optimization/31996] New: can't determine dependence between p->a[x+i] and *((int *)p + x + i + 8)
Just like PR 31995, this was found on the pointer plus branch after fixing
forwprop (note fowrwprop could be improved even more but that is a different
story and then we just get back to PR 31995 really), This testcase is really
vect-103 but modified to confuse data-ref:
/* { dg-require-effective-target vect_int } */
#include
#include
#include "tree-vect.h"
#define N 9
struct extraction
{
int a[N];
int b[N];
};
static int a[N] = {1,2,3,4,5,6,7,8,9};
static int b[N] = {17,24,7,0,2,3,4,31,82};
static int c[N] = {9,17,24,7,0,2,3,4,31};
int main1 (int x, int y) {
int i;
struct extraction *p;
p = (struct extraction *) malloc (sizeof (struct extraction));
for (i = 0; i < N; i++)
{
p->a[i] = a[i];
p->b[i] = b[i];
if (x == 135)
abort (); /* to avoid vectorization */
}
/* Vectorizable: distance > VF. */
for (i = 0; i < N; i++)
{
p->a[x + i] = *((int *)p + x + i + 8);
}
/* check results: */
for (i = 0; i < N; i++)
{
if (p->a[i] != c[i])
abort();
}
return 0;
}
int main (void)
{
check_vect ();
return main1 (0, N);
}
/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" } } */
/* { dg-final { scan-tree-dump-times "dependence distance modulo vf == 0" 1
"vect" } } */
/* { dg-final { cleanup-tree-dump "vect" } } */
--
Summary: can't determine dependence between p->a[x+i] and *((int
*)p + x + i + 8)
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31996
[Bug fortran/31716] segfault with real array bounds
--- Comment #11 from patchapp at dberlin dot org 2007-05-19 01:30 --- Subject: Bug number PR31716 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01265.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31716
[Bug tree-optimization/31995] New: can't determine dependence between p->a[x+i] and p->a[x+i+1]
While looking into some failures on the pointer plus branch after fixing up
forwprop, I noticed that we would get a failure in the vectorizer testsuite and
the reason is because we no longer could determine dependence for the two data
accesses.
Here is the testcase which is a modified version of vect-102.c which gets us
the same IR as what the pointer plus branch gives:
/* { dg-require-effective-target vect_int } */
#include
#include
#include "tree-vect.h"
#define N 9
struct extraction
{
int a[N];
int b[N];
};
static int a[N] = {1,2,3,4,5,6,7,8,9};
static int b[N] = {2,3,4,5,6,7,8,9,9};
int main1 (int x, int y) {
int i;
struct extraction *p;
p = (struct extraction *) malloc (sizeof (struct extraction));
for (i = 0; i < N; i++)
{
p->a[i] = a[i];
if (x == 135)
abort (); /* to avoid vectorization */
}
/* Not vectorizable: distance 1. */
for (i = 0; i < N - 1; i++)
{
p->a[x + i] = p->a[x + i + 1];
}
/* check results: */
for (i = 0; i < N; i++)
{
if (p->a[i] != b[i])
abort();
}
return 0;
}
int main (void)
{
check_vect ();
return main1 (0, N);
}
/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 0 "vect" } } */
/* { dg-final { scan-tree-dump-times "possible dependence between data-refs" 1
"vect" } } */
/* { dg-final { cleanup-tree-dump "vect" } } */
-- cut ---
if you change the 1 to 8, we should be able to vectorize that loop too.
--
Summary: can't determine dependence between p->a[x+i] and p-
>a[x+i+1]
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31995
[Bug fortran/31994] New: conjg(transpose(a)) produces wrong answer.
conjg(transpose(a)) produces the wrong answers. Both absoft and ifort produce correct answers. program main implicit none complex (kind=4),dimension(2,2)::a,b,c a(1,1) = (1.,1.) a(2,1) = (2.,2.) a(1,2) = (3.,3.) a(2,2) = (4.,4.) print *,"original",a b=conjg(transpose(a)) print *,"H(a)-wrong",b c=transpose(a) c=conjg(c) print *,"H(a)-right",c END program main -- Summary: conjg(transpose(a)) produces wrong answer. Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: elizabeth dot l dot yip at boeing dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31994
[Bug libgomp/31974] [4.3 regression]: Many libgomp failures
--- Comment #2 from hjl at lucon dot org 2007-05-19 00:46 --- I have verified that this patch http://gcc.gnu.org/ml/fortran/2007-05/msg00123.html causes the regression. FX, can you take a look? Thanks. -- hjl at lucon dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31974
[Bug fortran/31716] segfault with real array bounds
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2007-05-18 23:58 --- Have to remind myself to submit the patch. The odd messages are from trying to match and resolve other things, after failing already. I am working on a patch to try circumvent some of these. Garbage in Garbage Out though. :) -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-05-17 20:27:21 |2007-05-18 23:58:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31716
[Bug fortran/18923] segfault after subroutine name confusion
--- Comment #17 from jvdelisle at gcc dot gnu dot org 2007-05-18 23:52 --- Created an attachment (id=13582) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13582&action=view) Patch to eliminate segfault This patch eliminates the segfault from the original test case and the last test case which happen in to different places. The first test case segfault was caused by the duplicate else clause. That was sneaky. I was staring at it quite a while before I noticed it. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|REOPENED|ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18923
[Bug target/31990] udivdi3 not found for linux kernel
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-05-18 23:48 --- (In reply to comment #9) > Mr Pinski Well I am going to help now you have provided the preprocessed source for the missed optimization (since that is all what it is), read the history behind libgcc (it dates back before even the Linux kernel was even thought of). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31990
[Bug target/31990] udivdi3 not found for linux kernel
--- Comment #9 from malitzke at metronets dot com 2007-05-18 23:45 --- Mr Pinski I give up. I hereby formally request that you, Mr. Pinksi, refrain from having anything to do with problem reports originating from myself (Rainer Malitzke-Goes alias Ray Malitzke). I rather see them languishing unattended than having to deal with you. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31990
[Bug tree-optimization/30052] [4.2 Regression] possible quadratic behaviour.
--- Comment #20 from m dot vegni at it-systems dot it 2007-05-18 23:31 --- Subject: Re: [4.2 Regression] possible quadratic behaviour. Testsuite ran on i686-pc-linux-gnu without failures (i've enabled c and c++ only). xorg-server now compiles as well. The patch deserves more testing but IMHO it's in the right direction. Massimiliano Vegni IT SYSTEMS srl Roma, Italy dberlin at gcc dot gnu dot org wrote: > --- Comment #19 from dberlin at gcc dot gnu dot org 2007-05-18 14:46 > --- > Created an attachment (id=13576) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13576&action=view) > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13576&action=view) > Possible patch > > The attached is a huge backport of the 4.3 solver changes. > I have only minimally tested it. > Let me know if it helps on memory usage, and I will bootstrap/regtest it. > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052
[Bug target/31990] udivdi3 not found for linux kernel
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-05-18 23:13 --- > You might just as well close on the basis of your last paragraph. > This is really a documentation issue in getting the info to people like > kernel.org and others writing programs for free-standing or embedded > systems. > There are already udivdi3 equivalents in the kernel-tree for a number of > architectures. Even if they are developing for a free standing system, libgcc is used for support GCC and it is used by every target even the embedded ones, why the kernel guys want to duplicate this library, I have no idea, that is they only problem and not a GCC one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31990
[Bug target/31990] udivdi3 not found for linux kernel
--- Comment #7 from malitzke at metronets dot com 2007-05-18 23:10 --- Created an attachment (id=13581) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13581&action=view) timekeeping.i from ./kernel/time/timekeeping.c Second requested attachemnt. Observation: You might just as well close on the basis of your last paragraph. This is really a documentation issue in getting the info to people like kernel.org and others writing programs for free-standing or embedded systems. There are already udivdi3 equivalents in the kernel-tree for a number of architectures. Maybe you can forward this to the right peopl;e within gcc or tell me who to contact. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31990
[Bug c++/31993] [4.3 regression] ICE with template class in variadic template class
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||dgregor at gcc dot gnu dot ||org Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31993
[Bug c++/31993] New: [4.3 regression] ICE with template class in variadic template class
The following valid code snippet with variadic templates triggers an ICE
on mainline:
=
template struct A;
template class... T> struct A...>
{
template struct B {};
B<0> b;
};
=
bug.cc:6: internal compiler error: tree check: expected tree that contains
'decl non-common' structure, have 'template_template_parm' in
convert_template_argument, at cp/pt.c:4665
Please submit a full bug report, [etc.]
--
Summary: [4.3 regression] ICE with template class in variadic
template class
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31993
[Bug target/31990] udivdi3 not found for linux kernel
--- Comment #6 from malitzke at metronets dot com 2007-05-18 22:58 --- Created an attachment (id=13580) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13580&action=view) time.i form ./kernel/time.c first requested attachment -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31990
[Bug fortran/18923] segfault after subroutine name confusion
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2007-05-18 22:53 --- There is no guarantee that you are hitting the same problem, but if so, this is very helpful (sometimes :) ) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18923
[Bug c++/31992] [4.1/4.2/4.3 regression] ICE initializing static variable of template class
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31992
[Bug target/31985] Wide operations (i.e. adddi3) are split too late
--- Comment #1 from ubizjak at gmail dot com 2007-05-18 22:52 ---
Similar problems are shown for DImode store in following test:
--cut here--
typedef unsigned SI __attribute__ ((mode (SI)));
typedef unsigned DI __attribute__ ((mode (DI)));
#define umul_ppmm_c(w1, w0, u, v) \
{ \
DI __c = (DI) u * v;\
\
(w0) = (SI) (__c & 0x); \
(w1) = (SI) (__c >> 32);\
}
#define umul_ppmm_asm(w1, w0, u, v) \
__asm__ ("mull %3"\
: "=a" ((SI) (w0)), \
"=d" ((SI) (w1)) \
: "%0" ((SI) (u)), \
"rm" ((SI) (v)))
void test_c (SI a, SI b)
{
volatile SI x, y;
umul_ppmm_c (x, y, a, b);
}
void test_asm (SI a, SI b)
{
volatile SI x, y;
umul_ppmm_asm (x, y, a, b);
}
--cut here--
gcc -O2 -fomit-frame-pointer
test_c:
subl$16, %esp
movl24(%esp), %eax
mull20(%esp)
movl%eax, 8(%esp)
movl%edx, %eax
xorl%edx, %edx
movl%eax, 12(%esp)
addl$16, %esp
ret
test_asm:
subl$16, %esp
movl20(%esp), %eax
#APP
mull 24(%esp)
#NO_APP
movl%eax, 8(%esp)
movl%edx, 12(%esp)
addl$16, %esp
ret
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31985
[Bug c++/31992] New: [4.1/4.2/4.3 regression] ICE initializing static variable of template class
The following valid code snippet triggers a segfault since GCC 4.1.2:
=
template struct A
{
static const int i;
};
template const int A::i( A::i );
=
bug.cc:6: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
--
Summary: [4.1/4.2/4.3 regression] ICE initializing static
variable of template class
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31992
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #104 from pcarlini at suse dot de 2007-05-18 22:44 --- (In reply to comment #103) > If the element type is a POD, we should use assignment, not placement new. Agreed, in principle. But before adding a load of templates and dispatching, let's wait a bit for the outcome of this issue and benchmark carefully: the performance difference may be minor, given that we are dynamically allocating memory for the new node. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libmudflap/31681] [4.3 regression]: Many libmudflap faulures
--- Comment #4 from hjl at lucon dot org 2007-05-18 22:41 --- Fixed. -- hjl at lucon dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31681
[Bug target/31666] [4.3 regression]: g++.old-deja/g++.other/vbase5.C execution test
--- Comment #4 from hjl at lucon dot org 2007-05-18 22:40 --- Fixed. -- hjl at lucon dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31666
[Bug target/31989] [4.3 regression]: Gcc miscompiles C/C++ on Linux/x86-64
--- Comment #3 from hjl at lucon dot org 2007-05-18 22:40 --- Fixed. -- hjl at lucon dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31989
[Bug libmudflap/31681] [4.3 regression]: Many libmudflap faulures
--- Comment #3 from hjl at gcc dot gnu dot org 2007-05-18 22:35 --- Subject: Bug 31681 Author: hjl Date: Fri May 18 21:35:12 2007 New Revision: 124835 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124835 Log: 2007-05-18 H.J. Lu <[EMAIL PROTECTED]> PR target/31989 PR target/31681 PR target/31666 * config/i386/i386.c (init_cumulative_args): Set maybe_vaarg to true if function has no argument. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31681
[Bug target/31989] [4.3 regression]: Gcc miscompiles C/C++ on Linux/x86-64
--- Comment #2 from hjl at gcc dot gnu dot org 2007-05-18 22:35 --- Subject: Bug 31989 Author: hjl Date: Fri May 18 21:35:12 2007 New Revision: 124835 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124835 Log: 2007-05-18 H.J. Lu <[EMAIL PROTECTED]> PR target/31989 PR target/31681 PR target/31666 * config/i386/i386.c (init_cumulative_args): Set maybe_vaarg to true if function has no argument. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31989
[Bug target/31666] [4.3 regression]: g++.old-deja/g++.other/vbase5.C execution test
--- Comment #3 from hjl at gcc dot gnu dot org 2007-05-18 22:35 --- Subject: Bug 31666 Author: hjl Date: Fri May 18 21:35:12 2007 New Revision: 124835 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124835 Log: 2007-05-18 H.J. Lu <[EMAIL PROTECTED]> PR target/31989 PR target/31681 PR target/31666 * config/i386/i386.c (init_cumulative_args): Set maybe_vaarg to true if function has no argument. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31666
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #103 from gdr at cs dot tamu dot edu 2007-05-18 22:16 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should "pcarlini at suse dot de" <[EMAIL PROTECTED]> writes: | --- Comment #98 from pcarlini at suse dot de 2007-05-18 21:27 --- | (In reply to comment #97) | > First and foremeost, we have to generate correct code. If that means | > the memory barrier solution, for now, then so be it. | | Yes, but I'm a little worried myself not by but by containers like | , and , where we call allocator::contruct, which uses | placement new, to "install" the value in the allocated node. In that case, | unfortunately, per 20.4.1.1/12, we can't optimize it for POD types :( At | minimum we should benchmark a bit... If the element type is a POD, we should use assignment, not placement new. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #102 from gdr at cs dot tamu dot edu 2007-05-18 22:15 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should "pcarlini at suse dot de" <[EMAIL PROTECTED]> writes: | --- Comment #96 from pcarlini at suse dot de 2007-05-18 21:12 --- | (In reply to comment #95) | > But construction/initialization of uninitalized memory in happens with | > placement new! | | Placement new is used only for non-POD types, to be clear. yes, but it is also valid for POD types. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #101 from gdr at cs dot tamu dot edu 2007-05-18 22:12 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the
dynamic type as it should
"ian at airs dot com" <[EMAIL PROTECTED]> writes:
| But I don't think that is the question at hand. The variable is always being
| accessed in the same type, which is also the type of its declaration. The
| question at hand is this:
|
| void f(double* p) { *(int*)p = 3; long *l = new (p) long; *l = 4; }
| void g() { int i; f((double *)&i); }
|
| And the specific question is whether we are permitted to interchange the
| assignments to *p and *l.
After the placement new, the lifetime of *p is ended, and the lifetime
of *l starts there. I don't think that leaves room for exchanging the
stores to *p and *l.
| Let's consider this:
|
| void f(double* p) { *(int*)p = 3; long *l = (long*)p; *l = 4; }
|
| Is that valid?
If p is pointing to a union object that contain both int and long,
yes, it is valid. Otherwisem, it is not.
| Is the compiler permitted to interchange the assignments to *p
| and *l?
It is valid if we have a union object, otherwise, no.
-- Gaby
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
Re: [Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
"ian at airs dot com" <[EMAIL PROTECTED]> writes:
| But I don't think that is the question at hand. The variable is always being
| accessed in the same type, which is also the type of its declaration. The
| question at hand is this:
|
| void f(double* p) { *(int*)p = 3; long *l = new (p) long; *l = 4; }
| void g() { int i; f((double *)&i); }
|
| And the specific question is whether we are permitted to interchange the
| assignments to *p and *l.
After the placement new, the lifetime of *p is ended, and the lifetime
of *l starts there. I don't think that leaves room for exchanging the
stores to *p and *l.
| Let's consider this:
|
| void f(double* p) { *(int*)p = 3; long *l = (long*)p; *l = 4; }
|
| Is that valid?
If p is pointing to a union object that contain both int and long,
yes, it is valid. Otherwisem, it is not.
| Is the compiler permitted to interchange the assignments to *p
| and *l?
It is valid if we have a union object, otherwise, no.
-- Gaby
[Bug fortran/18923] segfault after subroutine name confusion
--- Comment #15 from dfranke at gcc dot gnu dot org 2007-05-18 22:11
---
Eventually, I got a traceable segfault with this shortened testcase:
$> cat pr18923.f90
module FOO
contains
subroutine FOO
character(len=selected_int_kind(0)) :: C
end subroutine
end
Program received signal SIGSEGV, Segmentation fault.
gfc_resolve_expr (e=0x887f8a8) at ../../../gcc/gcc/fortran/resolve.c:1747
1747expr->ts = expr->symtree->n.sym->result->ts;
(gdb) bt
#0 gfc_resolve_expr (e=0x887f8a8) at ../../../gcc/gcc/fortran/resolve.c:1747
#1 0x08095bbe in resolve_index_expr (e=0x887f380) at
../../../gcc/gcc/fortran/resolve.c:5482
#2 0x08095c2f in resolve_charlen (cl=0x8845148) at
../../../gcc/gcc/fortran/resolve.c:5508
#3 0x0809746f in resolve_types (ns=0x887f020) at
../../../gcc/gcc/fortran/resolve.c:7401
#4 0x08097557 in resolve_types (ns=0x88451b0) at
../../../gcc/gcc/fortran/resolve.c:7414
#5 0x08099bfc in gfc_resolve (ns=0x88451b0) at
../../../gcc/gcc/fortran/resolve.c:7477
#6 0x0808d6ac in gfc_parse_file () at ../../../gcc/gcc/fortran/parse.c:3248
#7 0x080aeabd in gfc_be_parse_file (set_yydebug=0) at
../../../gcc/gcc/fortran/f95-lang.c:303
#8 0x082ffe68 in toplev_main (argc=2, argv=0xbf93d354) at
../../../gcc/gcc/toplev.c:1051
#9 0x080f262f in main (argc=2, argv=0x1) at ../../../gcc/gcc/main.c:35
Most notable point are the identical expressions in this if/else clause
(resolve.c:1740f):
/* Make sure that the expression has a typespec that works. */
if (expr->ts.type == BT_UNKNOWN)
{
if (expr->symtree->n.sym->result
&& expr->symtree->n.sym->result->ts.type != BT_UNKNOWN)
expr->ts = expr->symtree->n.sym->result->ts;
else
expr->ts = expr->symtree->n.sym->result->ts; /* crashes here */
}
Otherwise, I'm out of my wits here. Hope this helps someone?!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18923
[Bug middle-end/31066] Suboptimal vectorization after inlining
--- Comment #3 from jb at gcc dot gnu dot org 2007-05-18 22:11 --- Closing as invalid. gfortran vectorizes the loop in gas_dyn:eos as it should. The real reason why gfortran sucks at gas_dyn is that ifort uses the reciprocal approximation instructions and a Newton-Rhapson step instead of division and square root instructions. I.e. instead of calculating sqrt(a/b) which has both a divide and a square root (both are pretty slow instructions) it calculates 1/sqrt(b*(1/a)) + the NR step. See PR31723. -- jb at gcc dot gnu dot org changed: What|Removed |Added CC||jb at gcc dot gnu dot org Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31066
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #100 from gdr at cs dot tamu dot edu 2007-05-18 22:04 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should "ian at airs dot com" <[EMAIL PROTECTED]> writes: | I'm not sure what to make of comment #84. We don't determine aliasing by | alignment or size. We determine it by type. We don't currently treat int and | long as aliasing each other even if they happen to have the same alignment and | size. That is GOOD. :-) | I believe this is correct according to the C standard but I am less | familiar with the C++ standard. It is also correct semantics with respect to C++. C++ goes further (I don't have C standard handy to check). The memory pointed to by p must have the "right" alignment requirements etc. So if you grab memory into p and it does not have the right alignment, then the new placement yields undefined behaviour. That is not a property we can check statically (until we get the alignment proposal into C++). | We could change the aliasing machinery in that | way for C++ if it seems to be appropriate, but I would prefer to take that to a | different PR. What I was trying to say was that C++ provides the same "dynamic type" (non-)aliasing guarantees, and goes even further. Did I manage to confuse you again? -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
Re: [Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
"ian at airs dot com" <[EMAIL PROTECTED]> writes: | I'm not sure what to make of comment #84. We don't determine aliasing by | alignment or size. We determine it by type. We don't currently treat int and | long as aliasing each other even if they happen to have the same alignment and | size. That is GOOD. :-) | I believe this is correct according to the C standard but I am less | familiar with the C++ standard. It is also correct semantics with respect to C++. C++ goes further (I don't have C standard handy to check). The memory pointed to by p must have the "right" alignment requirements etc. So if you grab memory into p and it does not have the right alignment, then the new placement yields undefined behaviour. That is not a property we can check statically (until we get the alignment proposal into C++). | We could change the aliasing machinery in that | way for C++ if it seems to be appropriate, but I would prefer to take that to a | different PR. What I was trying to say was that C++ provides the same "dynamic type" (non-)aliasing guarantees, and goes even further. Did I manage to confuse you again? -- Gaby
[Bug target/31990] udivdi3 not found for linux kernel
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-05-18 21:59 --- (In reply to comment #4) > Andy! Don't call me Andy! It is childish. > Taking your your advice to calm down I looked for the built-in.c file you > wanted preprocessed. Well, it does not exist as built-in.o is a composite > object file. And how do I know that from your descirption of the bug? As you just have: kernel/built-in.o: In function `getnstimeofday': (.text+0x1e48d): undefined reference to `__udivdi3' Which is why I was asking for built-in.i because I thought like a normal code, it was a normal object file and not an incremental linked one. > The Kernel peoople being a more helpful and b) having more expertise asked for > time.s and timekeeping.s out out time.c and timekeeping.c. I attached already > both > to PR8501. and you can take it from there. So attach time.i and timekeeping.i here which is exactly what we need. Note this is really only a missed optimization for GCC wise as if we call __udivdi3 now instead of doing it inlined, the code is just slower, libgcc contains __udivdi3. So the kernel needs to add the function but we can also fix GCC so we don't produce that for a missed optimization -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31990
[Bug middle-end/31095] [4.3 Regression] ICE in expand_expr_real_1, at expr.c:8786
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-05-18 21:49 --- *** Bug 31991 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31095
[Bug middle-end/31991] [4.3 regression] gfortran.dg/st_function.f90 FAILs
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-18 21:49 --- *** This bug has been marked as a duplicate of 31095 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31991
[Bug fortran/18923] segfault after subroutine name confusion
--- Comment #14 from dfranke at gcc dot gnu dot org 2007-05-18 21:44 --- Although I can not observe a crash on my machine with either flag setting, valgrind shows loads of ==32659== Invalid read of size 4 ==32659==at 0x809432F: gfc_resolve_expr (resolve.c:3220) ==32659== Address 0x4213C2C is 20 bytes inside a block of size 24 free'd ==32659==at 0x402119F: free (vg_replace_malloc.c:233) ==32659==by 0x80A4D42: gfc_undo_symbols (symbol.c:1959) in varying places, always related to gfc_undo_symbols ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18923
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #99 from pcarlini at suse dot de 2007-05-18 21:37 --- To complete my reasoning: in case we end-up with some sort of very bad pessimization of placement new, probably we'll have to adjust such containers to not call allocator::contruct at all when the default allocator is involved && a POD type is contructed, similarly to std::vector and std::deque for the uninitialized functions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug middle-end/31991] [4.3 regression] gfortran.dg/st_function.f90 FAILs
--- Comment #1 from tobi at gcc dot gnu dot org 2007-05-18 21:37 --- Sorry, I meant to say that it started failing on May 2nd. E.g. it fails here: http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00090.html and passes here: http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00042.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31991
[Bug middle-end/31991] New: [4.3 regression] gfortran.dg/st_function.f90 FAILs
Since May 1st this testcase fails for all optimization levels above -O0. According to gcc-testresults it passed on April 30th. -- Summary: [4.3 regression] gfortran.dg/st_function.f90 FAILs Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31991
[Bug tree-optimization/31976] [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-operands.c:487 with -O3
--- Comment #2 from tbm at cyrius dot com 2007-05-18 21:32 --- This appeared between 20070326 (works) and 20070422 (ICE). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31976
[Bug rtl-optimization/31987] [4.3 Regression] ICE in remove_insn, at emit-rtl.c:3579 at -O3
--- Comment #3 from tbm at cyrius dot com 2007-05-18 21:31 --- Note that this works with 20070422 (and fails with 20070515). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31987
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #98 from pcarlini at suse dot de 2007-05-18 21:27 --- (In reply to comment #97) > First and foremeost, we have to generate correct code. If that means > the memory barrier solution, for now, then so be it. Yes, but I'm a little worried myself not by but by containers like , and , where we call allocator::contruct, which uses placement new, to "install" the value in the allocated node. In that case, unfortunately, per 20.4.1.1/12, we can't optimize it for POD types :( At minimum we should benchmark a bit... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug fortran/25252] ICE on invalid code
--- Comment #9 from reichelt at gcc dot gnu dot org 2007-05-18 21:27 --- Still crashes for me on mainline and 4.1 and 4.2 branch (i686-pc-linux-gnu). Looks like there are some invalid pointers. Whether the program crashes or not depends on the garbage they are pointing to. This looks actually similar to PR 18923 where we also get crashes or garbled names in error messages. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25252
[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)
--- Comment #17 from jb at gcc dot gnu dot org 2007-05-18 21:20 --- Or even better (duh): REAL :: DTEMP DT = HUGE(1.0d0) DO I = 1, NODES DTEMP = DX(I)/(ABS(VEL(I)+SOUND(I)) IF (DTEMP < DT) THEN DT = DTEMP END IF END DO -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #97 from mark at codesourcery dot com 2007-05-18 21:17 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should rguenth at gcc dot gnu dot org wrote: > But construction/initialization of uninitalized memory in happens > with > placement new! So we're back to square one. What this PR initially was about > is a fixed type memory allocator in C++ which needs to change memory from > allocated type T to free-space-managing-structure S at deallocation time and > the other way around at allocation time. We absolutely _have_ to handle > this case correct. And we need to optimize the routines that use > placement new, because they resemble patterns used in libraries like POOMA > or Boost. First and foremeost, we have to generate correct code. If that means the memory barrier solution, for now, then so be it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)
--- Comment #16 from jb at gcc dot gnu dot org 2007-05-18 21:15 --- The critical thing with inlining array intrinsics, IMHO is to give the optimizer more data to work with allowing it to get rid of temp arrays, perform loop fusion or fission etc. So with a trivial benchmark like #15, you don't see any difference, except with potentially higher optimization for user code than libgfortran. For example in gas_dyn/chozdt: REAL, DIMENSION (NODES) :: DTEMP !--- ! Profile for gfortran 4.3: ! CPU_CLK_UNHALTED L2_CACHE_MISS ! samp %runtim samp %tot ! 59887 22.4783 1484 10.9828 : DTEMP = DX/(ABS(VEL) + SOUND) ! ifort 9.1 profile ! 40104 16.2034 1198 8.8166 : DTEMP = DX/(ABS(VEL) + SOUND) DTEMP = DX/(ABS(VEL) + SOUND) ISET = MINLOC (DTEMP) DT = DTEMP(ISET(1)) If MINLOC were inlined, perhaps a sufficiently optimizer could convert this into the equivalent REAL :: DTEMPMIN INTEGER :: i DTEMPMIN = HUGE(1.0d0) DO I = 1, NODES DT = DX(I)/(ABS(VEL(I)+SOUND(I)) IF (DT < DTEMPMIN) THEN DTEMPMIN = DT END IF END DO DT = DTEMPMIN i.e. avoid the temporary array entirely. Yes, I guess this is quite a lot to ask. -- jb at gcc dot gnu dot org changed: What|Removed |Added CC||jb at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067
[Bug rtl-optimization/26655] [4.0/4.1 Regression] ICE in ix86_secondary_memory_needed, at config/i386/i386.c:16446
--- Comment #23 from reichelt at gcc dot gnu dot org 2007-05-18 21:13 --- ... to close as fixed in GCC 4.2.0 and later. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED Target Milestone|4.1.3 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26655
[Bug rtl-optimization/26655] [4.0/4.1 Regression] ICE in ix86_secondary_memory_needed, at config/i386/i386.c:16446
--- Comment #22 from reichelt at gcc dot gnu dot org 2007-05-18 21:12 --- Reopening bug... -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26655
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #96 from pcarlini at suse dot de 2007-05-18 21:12 --- (In reply to comment #95) > But construction/initialization of uninitalized memory in happens > with > placement new! Placement new is used only for non-POD types, to be clear. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug target/31990] udivdi3 not found for linux kernel
--- Comment #4 from malitzke at metronets dot com 2007-05-18 21:11 --- Andy! Taking your your advice to calm down I looked for the built-in.c file you wanted preprocessed. Well, it does not exist as built-in.o is a composite object file. The Kernel peoople being a more helpful and b) having more expertise asked for time.s and timekeeping.s out out time.c and timekeeping.c. I attached already both to PR8501. and you can take it from there. -- malitzke at metronets dot com changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31990
[Bug fortran/18923] segfault after subroutine name confusion
--- Comment #13 from reichelt at gcc dot gnu dot org 2007-05-18 21:10 --- The testcase still crashes on mainline (and 4.1 and 4.2 branch) if I compile it without "-g" or with "--param ggc-min-expand=0 --param ggc-min-heapsize=0 -g". Looks like there are some invalid pointers. Whether the program crashes or not depends on the garbage they are pointing to. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18923
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #95 from rguenth at gcc dot gnu dot org 2007-05-18 20:55 --- But construction/initialization of uninitalized memory in happens with placement new! So we're back to square one. What this PR initially was about is a fixed type memory allocator in C++ which needs to change memory from allocated type T to free-space-managing-structure S at deallocation time and the other way around at allocation time. We absolutely _have_ to handle this case correct. And we need to optimize the routines that use placement new, because they resemble patterns used in libraries like POOMA or Boost. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libfortran/31297] Use of uninitialized variables in libgfortran's I/O
--- Comment #7 from jb at gcc dot gnu dot org 2007-05-18 20:52 --- Seems unf_io_convert_3.f90 is fixed by the patch for PR31915, which adds padding for CONVERT. The patch was committed as r124741. Closing, please verify and reopen if I'm wrong. -- jb at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31297
[Bug target/31628] stdcall function is miscompiled
--- Comment #8 from hjl at gcc dot gnu dot org 2007-05-18 20:30 --- Subject: Bug 31628 Author: hjl Date: Fri May 18 19:29:45 2007 New Revision: 124831 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124831 Log: 2007-05-18 H.J. Lu <[EMAIL PROTECTED]> PR target/31628 * gcc.target/i386/pr31628.c: New. Added: trunk/gcc/testsuite/gcc.target/i386/pr31628.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31628
[Bug libfortran/31933] Uninitialized memory when writing real(10) as unformatted
--- Comment #1 from jb at gcc dot gnu dot org 2007-05-18 20:07 --- Seems to work fine on i686-pc-linux-gnu. I would have guessed it to be something related to padding, but it's weird that it's not seen in 32-bit mode. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31933
[Bug libgcj/31939] Command line arguments are byteswapped before being passed to the program runing in custom locale.
--- Comment #4 from serg at vostok dot net 2007-05-18 20:07 ---
For subject 2.
The point is to find where arguments of "int main(int argc, char** argv)" are
converted into java.lang.String to be passed to "static void main(String[]
args)".
Trail:
gcc/java/jvgenmain.c:
int main(int argc,char **argv)
constructs a C code to call the main java method with
JvRunMain(classname,argc,argv)
libjava/prims.cc:
void JvRunMain (jclass klass, int argc, const char **argv)
simply calls
_Jv_RunMain (klass, NULL, argc, argv, false)
void _Jv_RunMain (jclass klass, const char *name, int argc, const char **argv,
bool is_jar)
simply calls
_Jv_RunMain (NULL, klass, name, argc, argv, is_jar)
void _Jv_RunMain (JvVMInitArgs *vm_args, jclass klass, const char *name, int
argc, const char **argv, bool is_jar)
calls
JvConvertArgv (argc - 1, argv + 1)
JArray * JvConvertArgv (int argc, const char **argv)
copies each argument into jbyteArray bytes, then calls
new java::lang::String (bytes, 0, len)
to make a String from it with a default encoding.
libjava/java/lang/String.java:
public String(byte[] data, int offset, int count)
calls
init (data, offset, count,System.getProperty("file.encoding", "8859_1"))
libjava/java/lang/natString.cc:
void java::lang::String::init (jbyteArray bytes, jint offset, jint count,
jstring encoding)
uses
gnu::gcj::convert::BytesToUnicode::getDecoder(encoding)
to make a converter
and
converter->read(array, outpos, avail)
to convert data
libjava/gnu/gcj/convert/BytesToUnicode.java:
class BytesToUnicode extends IOConverter
public static BytesToUnicode getDecoder (String encoding)
uses eigther
new Input_iconv(encoding)
or
new BytesToCharsetAdaptor(Charset.forName(encoding))
Looks like I will have to test both Input_iconv and BytesToCharsetAdaptor to
see if any of them is buggy.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31939
[Bug target/31990] udivdi3 not found for linux kernel
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-18 19:09 --- > 3. I referred to to the experts in both organizations and I do not believe > that > you are the gcc expert in machine descriptions. Have you looked into what I have done? Lets see my first big patch: 2002-12-02 Andrew Pinski <[EMAIL PROTECTED]> * config/rs6000/rs6000.md (ffssi): Convert to expander. (ffsdi): Likewise. (cntlzw2, cntlzd2): New patterns. And then more recently: 2007-03-31 Andrew Pinski <[EMAIL PROTECTED]> PR target/31364 * config/rs6000/rs6000.md (call): Convert to LR hard reg for secureplt. (call_value): Likewise. 2006-11-29 Andrew Pinski <[EMAIL PROTECTED]> PR target/29945 * config/spu/spu.md (extend_compare): New pattern. (extend_compare): Change to expand and use the above pattern. Plus this: spu portAndrew Pinski [EMAIL PROTECTED] I don't see how you can say I am not an expert at this. Also one more thing did you read http://gcc.gnu.org/bugs.html which explains exactly what we need for a bug report? The reason why the bitfield patch has not go in yet, is because I am busy with other work and it is a minor issue on my plate right now (have you looked into what I have been doing lately?). Also 4.3 is no where near being released in the next month or two so calm down. We can't all fix bugs in the same time as they are reported. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31990
[Bug target/31989] [4.3 regression]: Gcc miscompiles C/C++ on Linux/x86-64
--- Comment #1 from hjl at lucon dot org 2007-05-18 19:05 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01223.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31989
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #94 from ian at airs dot com 2007-05-18 19:03 --- I tried the original test case with icc, and it gets the right result. The assignment b->p = 0 is discarded. Unfortunately I'm not sure what this actually tells us. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #93 from mark at codesourcery dot com 2007-05-18 19:01 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
ian at airs dot com wrote:
> void f(double* p) { *(int*)p = 3; long *l = new (p) long; *l = 4; }
> void g() { int i; f((double *)&i); }
>
> And the specific question is whether we are permitted to interchange the
> assignments to *p and *l.
I do not think we are.
> void f(double* p) { *(int*)p = 3; long *l = (long*)p; *l = 4; }
>
> Is that valid? Is the compiler permitted to interchange the assignments to *p
> and *l? Consider that, as in comment #73, p might actually point to a union
> of
> int and long. Does that fact that that union might exist somewhere else make
> this test case valid? Presumably it does not. Presumably this is invalid.
Agreed; this case is invalid.
> So if that is not valid, and the placement new case is valid, then what is the
> essential difference between the cases? The variable is being accessed via
> two
> different types. Why is that OK?
Because placement new changes the type of storage, in the same way that
using ordinary ("delete") and then using (ordinary) "new" (but getting
back the same memory pointer) does. The placement "new" operator is
special.
> You're right that don't have to abandon TBAA to make this work, that we can
> make it work by turning placement new into a memory barrier. But then you
> have
> to address comment #42. That approach will cause a performance regression for
> natural valid code. The question then becomes whether we are willing to pay
> that performance regression for normal code in order to support this sort of
> weird code.
I am willing to accept that performance regression. I don't consider
that code "normal"; many C++ performance libraries now provide a way to
produce an uninitialized container, precisely to avoid default
construction. POOMA could use that technique.
It would of course be better (though, in my opinion, not essential) to
have a more gentle barrier. If we could tell the compiler to forget the
type of anything that the argument to placement-new might point to, but
not to assume that arbitrary weirdness has occurred, then the compiler
could still eliminate the redundant stores.
In other words, in Comment #42, the problem is that the volatile asm
tells the compiler that not only must the stores/loads not be reordered
across the barrier, but that stores before the barrier must actually
occur because their may be some arbitrary action at the barrier that
depends upon the values written. If we had a barrier that says just
that the operations may not be reordered across the barrier -- but does
not say that the operations before the barrier are side-effecting --
then we could still eliminate them as redundant.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug target/31990] udivdi3 not found for linux kernel
--- Comment #2 from malitzke at metronets dot com 2007-05-18 18:57 --- Andy there you go again: Irrelevancies and make work for others. You folks at gcc made tons of changes in gcc-4.3 regarding machine definitions and similar. I have some evidence that some blatant mistakes were silently corrected without mentioning even ICE's in gcc bootstrap. I refrained (wisely) from saying anything about compilations using 3Gigs of memory and then collapsing,. Now an insider has come to acknowledge that problem,PR31863. How about your patch to overcome the PR 31541 (bit field addressing) now untouched for almost one month. It is no wonder that a lot of packages, when I tell them about easy fixes regarding gcc-4.x.y, reply "we rather deal deal with gcc-3.x.y or even gcc-2.x( even with -fno-strength-reduce). The gcc group really working hard at overcoming problems noticed by users are the gfortran people (Yes, I had my run-in with them over the goto thing, but they have not caused me to file any PR's after that) Now to some perhaps ppoorly understood by my self technical issues: 1. binutils does a MACRO regarding udevdi3, but its is impossible to build binutils (even current CVS with gcc-4.3.0) 2. gcc-4.2.1 compiles the impacted kernel fine. To my simple, but seasoned, mind the onus when something stops working is on the party that made changes (namley gcc going from 4.2 to 4.3); not on the one that did not change in this case kernel-2.6.20.11. 3. I referred to to the experts in both organizations and I do not believe that you are the gcc expert in machine descriptions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31990
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #92 from pinskia at gcc dot gnu dot org 2007-05-18 18:55
---
> So if that is not valid, and the placement new case is valid, then what is the
> essential difference between the cases? The variable is being accessed via
> two
> different types. Why is that OK?
> void f(double* p) { *(int*)p = 3; long *l = new (p) long; *l = 4; }
> void g() { int i; f((double *)&i); }
Because the memory that p was pointing to, stops being an int once a placement
new happens. For F, it goes:
> void f(double* p)
> {
p points to an variable that is an int
> *(int*)p = 3
access the int via an int.
> long *l = new (p) long;
The memory is no longer an int, it has become a long, it cannot be accessed as
an int no longer as that would be undefined.
> *l = 4;
Access the memory as a long and since the type is a long, this is well defined.
>}
Now after this function returns the variable can only be accessed as a long
(well and via a character type).
Hopefully this explains why this is valid. Now should we do anything about it,
I don't know because how often does this happen in real life, I don't know.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #91 from pcarlini at suse dot de 2007-05-18 18:46 --- (In reply to comment #90) > Can anybody see a way through this maze? Humbly, I'd like to suggest again that we have a look to the assembly produced by other compilers. I remember that some GCC contributors have access to compilers such as ICC, XLC++, Sun, etc. and I don't think we should strive at all costs for perfect optimization, if that means keeping busy our best contributors for months and risking producing wrong code. We can always return to the issue later, as an enhancement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug target/31975] [4.3 Regression] segfault in try_split on mips during bootstrap
--- Comment #3 from tbm at cyrius dot com 2007-05-18 18:45 --- I started a build on my mipsel box too and it has failed in the same way as on mips. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31975
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #90 from ian at airs dot com 2007-05-18 18:38 ---
I agree that this is valid:
void f(double *p) { *(int*)p = 3; }
void g() {
int i;
f((double *)&i);
}
But I don't think that is the question at hand. The variable is always being
accessed in the same type, which is also the type of its declaration. The
question at hand is this:
void f(double* p) { *(int*)p = 3; long *l = new (p) long; *l = 4; }
void g() { int i; f((double *)&i); }
And the specific question is whether we are permitted to interchange the
assignments to *p and *l.
Let's consider this:
void f(double* p) { *(int*)p = 3; long *l = (long*)p; *l = 4; }
Is that valid? Is the compiler permitted to interchange the assignments to *p
and *l? Consider that, as in comment #73, p might actually point to a union of
int and long. Does that fact that that union might exist somewhere else make
this test case valid? Presumably it does not. Presumably this is invalid.
So if that is not valid, and the placement new case is valid, then what is the
essential difference between the cases? The variable is being accessed via two
different types. Why is that OK?
You're right that don't have to abandon TBAA to make this work, that we can
make it work by turning placement new into a memory barrier. But then you have
to address comment #42. That approach will cause a performance regression for
natural valid code. The question then becomes whether we are willing to pay
that performance regression for normal code in order to support this sort of
weird code.
Can anybody see a way through this maze?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #89 from mark at codesourcery dot com 2007-05-18 17:44 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
ian at airs dot com wrote:
> --- Comment #86 from ian at airs dot com 2007-05-18 17:24 ---
> Re comment #80, comment #81, comment #82. My patch handles the placement new
> in comment #73 to indicate an alias between double and long. The mis-ordered
> code is actually aliasing int and long. That aliasing is due to a cast to
> (int*). There is no placement new in that cast. There is no reason for the
> compiler to avoid exchanging the store via int* and the store via long*. Why
> should it?
I don't think the fact that "p" is a "double *" is relevant; it could
just as well be "void *". This kind of code is unambiguously valid:
void f(double *p) { (int*)p = 3; }
void g() {
int i;
f((double *)&i);
}
Pedantically, the alignment of "double" has to be no stricter than "int"
for this to be valid, but since we define pointer conversion as a no-op,
it's always valid in GNU C.
This is why I liked your earlier patch that made placement new a memory
barrier. I think the right handling of placement new is basically to
say "everything we know about types is forgotten here". One can limit
that to things to which the operand might point, but points-to analysis
(should not) tell you that "p" and "l" cannot point at the same place,
since we have no idea what "p" points at.
I don't think this is equivalent to totally disabling TBAA in C++.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #88 from ian at airs dot com 2007-05-18 17:35 --- Regarding comment #85, this again relies on the notion of dynamic type of a memory location such that the only possible end result is to eliminate TBAA when compiling C++. The only thing I can say about this sort of test case is that I agree that one can make an argument from the standard that this type of code is valid. However, as I've said before, e.g., in comment #76, I don't think that anybody really wants that end result. Any example that inherently relies on a type cast is going to lead you straight to eliminating TBAA. And note that your example is clearly invalid in C. Adding the placement new doesn't really have anything to do with whether it is valid or invalid in C++. Can you show me a test case which my patch gets wrong which does not involve type casting outside of placement new itself? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug target/31975] [4.3 Regression] segfault in try_split on mips during bootstrap
--- Comment #2 from daney at gcc dot gnu dot org 2007-05-18 17:31 --- Currently building mipsel-unknown-linux-gnu. # cat LAST_UPDATED Wed May 16 12:35:18 PDT 2007 Wed May 16 19:35:18 UTC 2007 (revision 124776) libstdc++-v3 was built without ICEing (currently building in libjava). The differences from Martin's configuration are that my target is little endian and I configured with --disable-static. The testcase would appear to be when building the static library version of strstream.o (I see no -fpic in the compiler invocation). FWIW this is my configure command: ../gcc/configure --with-arch=mips32 --with-float=soft --disable-java-awt --without-x --disable-tls --enable-__cxa_atexit --disable-jvmpi --disable-static --disable-libmudflap --enable-languages=c,c++,java I guess I will try the strstream.ii in the bug attachment with my compiler when it finishes bootstrapping. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31975
[Bug target/31990] udivdi3 not found for linux kernel
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-18 17:29 --- First off, can you attach the preprocessed source for built-in.c ? Second this might not be a bug in GCC but in the kernel not providing all of the required functions that are in libgcc. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31990
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #87 from ian at airs dot com 2007-05-18 17:27 --- I'm not sure what to make of comment #84. We don't determine aliasing by alignment or size. We determine it by type. We don't currently treat int and long as aliasing each other even if they happen to have the same alignment and size. I believe this is correct according to the C standard but I am less familiar with the C++ standard. We could change the aliasing machinery in that way for C++ if it seems to be appropriate, but I would prefer to take that to a different PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should
--- Comment #86 from ian at airs dot com 2007-05-18 17:24 --- Re comment #80, comment #81, comment #82. My patch handles the placement new in comment #73 to indicate an alias between double and long. The mis-ordered code is actually aliasing int and long. That aliasing is due to a cast to (int*). There is no placement new in that cast. There is no reason for the compiler to avoid exchanging the store via int* and the store via long*. Why should it? If you omitted the placement new, this would be a standard aliasing violation between int and double. With the placement new, it's still an aliasing violation between int and long. The placement new doesn't excuse you from all aliasing violations: it just excuses you from aliasing violations involving the actual types in question. If you want to make a principled argument that placement new excuses you from all aliasing violations, then again the result is that in a function which uses placement new we should disable TBAA for that function. That would be OK with me and easy to implement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29286
[Bug c/31990] New: udivdi3 not found for linux kernel
I just filed (verbatim) the PR reproduced below with bugzilla.kernel.org (8501) Hopefully the exports will be able to communicate directly. Most recent __gcc__ compiler where this bug did *NOT* occur: gcc-4.2.0 Distribution: Hardware Environment: x86 (will try on MAC G4 machine) Software Environment: gcc compilers Problem Description: "make V=1" output kernel/built-in.o: In function `getnstimeofday': (.text+0x1e48d): undefined reference to `__udivdi3' kernel/built-in.o: In function `do_gettimeofday': (.text+0x1e5b5): undefined reference to `__udivdi3' kernel/built-in.o: In function `update_wall_time': -- Summary: udivdi3 not found for linux kernel Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: malitzke at metronets dot com GCC build triplet: i686-unknown-linux-gnu GCC host triplet: i686-unknown-linux-gnu GCC target triplet: i686-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31990
[Bug target/31989] New: [4.3 regression]: Gcc miscompiles C/C++ on Linux/x86-64
I have verified that this patch http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01333.html causes bug 31666 and bug 31681. -- Summary: [4.3 regression]: Gcc miscompiles C/C++ on Linux/x86-64 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org GCC target triplet: x86_64-unknown-linux-gnu OtherBugsDependingO 31666,31681 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31989
[Bug c++/31666] [4.3 regression]: g++.old-deja/g++.other/vbase5.C execution test
--- Comment #2 from hjl at lucon dot org 2007-05-18 16:32 --- I have verified that this patch http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01333.html causes this regression on Linux/x86-64. Richard, can you take a look? Thanks. -- hjl at lucon dot org changed: What|Removed |Added CC||rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31666
[Bug tree-optimization/30052] [4.2 Regression] possible quadratic behaviour.
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|target |tree-optimization Target Milestone|--- |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30052
[Bug fortran/25061] procedure name conflict
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-05-18 15:49 ---
I had a short look at this. The problem is in decl.c:693f:
if (sym->attr.flavor != 0
&& sym->attr.proc != 0
&& (sym->attr.subroutine || sym->attr.function)
&& sym->attr.if_source != IFSRC_UNKNOWN)
gfc_error_now ("Procedure '%s' at %C is already defined at %L",
name, &sym->declared_at);
(gdb) print sym->name
$5 = 0x887e4f6 "i1"
(gdb) print sym->attr.proc
$8 = PROC_UNKNOWN
(gdb) print sym->attr.if_source
$10 = IFSRC_UNKNOWN
Interestingly, if the subroutine I1 is duplicated, the expected error (I1
already defined as interface) is emitted:
$> cat pr25061.f90
MODULE foo
INTERFACE I1
SUBROUTINE S1(I)
END SUBROUTINE S1
SUBROUTINE S2(R)
END SUBROUTINE S2
END INTERFACE I1
CONTAINS
SUBROUTINE I1(I)
END SUBROUTINE I1
SUBROUTINE I1(R) ! same as before, but I1 in triplicate now
END SUBROUTINE I1
END MODULE
$> gfortran-svn -g -Wall
pr25061.f90:11.15:
SUBROUTINE I1(R)
1
pr25061.f90:2.12:
INTERFACE I1
2
Error: Procedure 'i1' at (1) is already defined at (2)
$> gfortran-svn -v
gcc version 4.3.0 20070517 (experimental)
Adding Paul, The Interface Wizard, Thomas as CC. He will probably now how to
handle this :)
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
CC||dfranke at gcc dot gnu dot
||org, pault at gcc dot gnu
||dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25061
[Bug c++/31988] New: new operator should not permit default first parameter
The following C++ program should not compile:
#include
class C
{
public:
void * operator new (size_t = 32); // invalid
};
The C++ standard, clause 3.7.3.1, paragraph 1, says that the first parameter to
new should not have a default argument. GCC gives no error and no warning.
--
Summary: new operator should not permit default first parameter
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andrew dot stubbs at st dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31988
[Bug rtl-optimization/31987] [4.3 Regression] ICE in remove_insn, at emit-rtl.c:3579 at -O3
--- Comment #2 from ubizjak at gmail dot com 2007-05-18 15:28 --- Confirmed, backtrace: #1 0x082aa0d0 in remove_insn (insn=0xb7b25620) at ../../gcc-svn/trunk/gcc/emit-rtl.c:3579 #2 0x08262d08 in delete_insn (insn=0xb7b25620) at ../../gcc-svn/trunk/gcc/cfgrtl.c:134 #3 0x08262ef8 in delete_insn_chain (start=0xb7b25620, finish=0xb7b17140) at ../../gcc-svn/trunk/gcc/cfgrtl.c:214 #4 0x08263161 in rtl_delete_block (b=0xb7b1d2d0) at ../../gcc-svn/trunk/gcc/cfgrtl.c:373 #5 0x08263299 in cfg_layout_delete_block (bb=0xb7b1d2d0) at ../../gcc-svn/trunk/gcc/cfgrtl.c:2467 #6 0x08254fdd in delete_basic_block (bb=0xb7b1d2d0) at ../../gcc-svn/trunk/gcc/cfghooks.c:464 #7 0x08253de1 in cleanup_cfg (mode=64) at ../../gcc-svn/trunk/gcc/cfgcleanup.c:2002 #8 0x0872f2a8 in fwprop_done () at ../../gcc-svn/trunk/gcc/fwprop.c:917 #9 0x0872f357 in fwprop_addr () at ../../gcc-svn/trunk/gcc/fwprop.c:999 #10 0x083ba9e3 in execute_one_pass (pass=0x88fa680) at ../../gcc-svn/trunk/gcc/passes.c:1065 -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-18 15:28:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31987
[Bug target/17390] missing floating point compare optimization
--- Comment #13 from ubizjak at gmail dot com 2007-05-18 15:13 --- (In reply to comment #12) > ping This patch needs to be ported to dataflow infrastructure [1] and has to be re-thought a bit. [1]: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00040.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17390
[Bug tree-optimization/31976] [4.3 Regression] ICE in ssa_operand_alloc, at tree-ssa-operands.c:487 with -O3
--- Comment #1 from tbm at cyrius dot com 2007-05-18 14:58 --- Created an attachment (id=13579) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13579&action=view) preprocessed source delta's taking ages on this, so here's the current (large) code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31976
