[Bug target/26778] [4.0/4.1 regression] GCC4 moves the result of a conditional block through inadequate registers
--- Comment #13 from bonzini at gnu dot org 2006-09-20 07:07 --- reopening... -- bonzini at gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26778
[Bug target/26778] [4.0/4.1 regression] GCC4 moves the result of a conditional block through inadequate registers
--- Comment #14 from bonzini at gnu dot org 2006-09-20 07:07 --- ... because the appropriate resolution is WONTFIX -- bonzini at gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26778
[Bug c++/29138] [4.0/4.1/4.2 Regression] access declarations don't work for classes
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||rejects-valid Known to fail||3.0.4 4.0.0 4.1.0 3.2.3 ||3.4.0 3.3.3 4.2.0 Known to work||2.95.3 Summary|access declarations don't |[4.0/4.1/4.2 Regression] |work for classes|access declarations don't ||work for classes Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29138
[Bug c++/29138] [4.0/4.1/4.2 Regression] access declarations don't work for classes
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-20 07:12 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-20 07:12:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29138
[Bug libfortran/27046] [mingw32] mixed C-Fortran I/O doesn't flush
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2006-09-20 07:50 --- (In reply to comment #7) > If you stll think that this is a libgfortran bug (I don't) > you could add > setvbuf(stdout, NULL, _IOLBF, 0); > to unix.c:output_stream() so that stdout always is line-buffered even when > !isatty(fileno(stdout)) Indeed, I think the bug is in the user's code, but I think there's no serious drawback to the setvbuf workaround you mention. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2006-06-12 16:30:13 |2006-09-20 07:50:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27046
[Bug target/28069] __m128 local variables don't get properly aligned.
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-09-20 07:54 --- Not specific to mingw32. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn|27537 |13685 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i686-pc-mingw32 | GCC host triplet|i686-pc-mingw32 | GCC target triplet|i686-pc-mingw32 |i686 Last reconfirmed|-00-00 00:00:00 |2006-09-20 07:54:00 date|| Version|4.1.1 |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28069
[Bug target/19970] Java Disabled for MinGW
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-09-20 07:56 --- Any news on enabling libgcj by default? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19970
[Bug target/29124] unoptimal addressing mode.
--- Comment #2 from pluto at agmk dot net 2006-09-20 08:00 --- (In reply to comment #1) > I cannot reproduce this with "4.2.0 20060311" or 4.0.3 or 4.1.0 20060208. > > Are you sure that you don't have a patch that causes problems? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24669#c3 causes problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29124
[Bug target/14666] Crossing from GNU/Linux to MinGW requires SEVERAL hacks
--- Comment #17 from fxcoudert at gcc dot gnu dot org 2006-09-20 08:01 --- Cross-building for mingw32 now works for me, and this bug has been inactive long enough that we can close it. If someone has recent data on this, please reopen! -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|NEW |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14666
[Bug target/9539] [Windows] builtin [long/set]jmp not working properly with signals
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-09-20 08:05 --- I think this is fixed on 4.2: $ gcc a.c a.c:16:1: warning: "setjmp" redefined In file included from a.c:7: c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/setjmp.h:41:1: warning: this is the location of the previous definition a.c: In function `main': a.c:56: warning: passing arg 1 of `SetUnhandledExceptionFilter' from incompatible pointer type $ ./a.exe Install error handler let's go Error Handler let's go Can we close this bug? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9539
[Bug c/9601] -mrtd switch/stdcall attribute raises warnings for __buitltin functions
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2006-09-20 08:12 --- > double __attribute__((cdecl)) sqrt (double); > double __attribute__((stdcall)) log (double); > double cos (double); With this code, we still (gcc-4.2) get: $ gcc -c -W -Wall -mrtd b.c b.c:1: warning: conflicting types for built-in function sqrt $ gcc -c -W -Wall b.c b.c:2: warning: conflicting types for built-in function log This is not related to mingw32, as the same warnings happen on i386-pc-mingw32 and i686-pc-linux-gnu. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Component|target |c GCC target triplet|i386-pc-mingw32 | Last reconfirmed|2003-07-11 15:03:36 |2006-09-20 08:12:19 date|| Summary|[win32] -mrtd switch/stdcall|-mrtd switch/stdcall |attribute raises warnings |attribute raises warnings |for __buitltin functions|for __buitltin functions http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9601
[Bug middle-end/28046] libgomp test pr27337.C fails intermittently
--- Comment #2 from jakub at gcc dot gnu dot org 2006-09-20 08:22 --- Subject: Bug 28046 Author: jakub Date: Wed Sep 20 08:22:04 2006 New Revision: 117077 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117077 Log: PR middle-end/28046 * c-omp.c (c_finish_omp_atomic): If ADDR is not simple enough, wrap it into TARGET_EXPR. * gcc.dg/gomp/atomic-10.c: New test. * g++.dg/gomp/atomic-10.C: New test. Added: trunk/gcc/testsuite/g++.dg/gomp/atomic-10.C trunk/gcc/testsuite/gcc.dg/gomp/atomic-10.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-omp.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28046
[Bug fortran/28494] Unclear run time error message
--- Comment #2 from tobias dot burnus at physik dot fu-berlin dot de 2006-09-20 08:27 --- I looked what other are writing: gfortran: Fortran runtime error: Array reference out of bounds for array 'r', upper bound of dimension 1 exceeded (in file 'array2.f90', at line 4) NAG f95: Subscript 1 of R (value 5) is out of range (1:4) Intel Fortran Compiler ifort: forrtl: severe (408): fort: (2): Subscript #1 of the array R has value 5 which is greater than the upper bound of 4 Sun f95: ** FORTRAN RUN-TIME SYSTEM ** Subscript out of range. Location: line 4 column 5 of 'array2.f90' Subscript number 1 has value 5 in array 'R' Personal favourite would be: Fortran runtime error: Array reference out of bounds. Subscript 1 of array 'r' (value 5) exceeds upper bound of 4 (in file 'array2.f90', at line 4)" The place to change would be trans-array.c. I looked at it, but I fail to extract a asprintf-able number from the "tree"s index etc. -- tobias dot burnus at physik dot fu-berlin dot de changed: What|Removed |Added CC||tobias dot burnus at physik ||dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28494
[Bug middle-end/28046] libgomp test pr27337.C fails intermittently
--- Comment #3 from jakub at gcc dot gnu dot org 2006-09-20 09:04 --- Fixed on the trunk and redhat/gcc-4_1-branch. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28046
[Bug fortran/21130] 38822 lines of Fortran 90 takes more than 10 minutes to compile on a dual 3GHz P4 Linux box with lots of RAM
--- Comment #16 from paul dot thomas at jet dot uk 2006-09-20 09:22 --- (In reply to comment #15) > looks like there is agreement that the problem is fixed. I am afraid to say that I do not agree entirely; the above takes 6 seconds to compile with ifort on my Athlon 1700 "a vapeur". The patch is pretty good but Andrew is right to say in PR25708 that we should not be loading the modules repeatedly. I put a counter in read_module to check how many times each module was read, in the above, and came to the conclusion that gfortran would achieve the same compile time as ifort, if we were to read a module once into a separate symtree and use and abuse it from there. For my sins, I have proposed to do this as a gfortran-4.3 project. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21130
[Bug libstdc++/29134] Has there been a serious attempt to define the max_size() member functions?
--- Comment #3 from chris at bubblescope dot net 2006-09-20 09:50 --- Actually, I think deque could do with a better max_size. Some tests: vector v; v.resize(v.max_size()); Throws bad_alloc. deque v; v.resize(v.max_size()); Bus errors. This is on i686-apple-darwin8, 4.0.1 Apple's build, so might not be the same behaviour as mainline. Still seems like it shouldn't bus error however? -- chris at bubblescope dot net changed: What|Removed |Added CC||chris at bubblescope dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29134
[Bug fortran/29147] New: Overflow check in DATA statements
Hi, a recently introduced range check not only kills legacy code that I use, but also gives a misleading error message: % cat gfcbug42.f INTEGER IBALL(4) DATA IBALL / Z'FF', + Z'' , + Z'FF', + Z'' / END % gfortran -c -std=legacy gfcbug42.f In file gfcbug42.f:5 + Z'' / 1 Error: Arithmetic overflow converting INTEGER(8) to INTEGER(4) at (1) Funny, I even do not see any 8 byte integer around... -ha -- Summary: Overflow check in DATA statements Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anlauf at gmx dot de GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29147
[Bug target/9539] [Windows] builtin [long/set]jmp not working properly with signals
--- Comment #7 from dannysmith at users dot sourceforge dot net 2006-09-20 09:52 --- (In reply to comment #6) > I think this is fixed on 4.2: Its still broken on my machine Try after compiling the testcase with optimization turned on. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9539
[Bug fortran/29147] Overflow check in DATA statements
--- Comment #1 from anlauf at gmx dot de 2006-09-20 09:53 --- Created an attachment (id=12299) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12299&action=view) Legacy code example Compiles fine with every other compiler out there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29147
[Bug libstdc++/29134] Has there been a serious attempt to define the max_size() member functions?
--- Comment #4 from pcarlini at suse dot de 2006-09-20 10:09 --- (In reply to comment #3) > Actually, I think deque could do with a better max_size. It's not at all clear to me what we can possibly do in the general case of discontiguous containers. Certainly, we don't want Segmentation faults or bus errors, but that is a largely unrelated issue (I suggest filing a separate PR), which, I bet, in general has to do mostly with proper arithmetic in each individual container. As a matter of fact, the problem with deque is an arithmetic overflow in _M_new_elements_at_front. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29134
[Bug libstdc++/29134] Has there been a serious attempt to define the max_size() member functions?
--- Comment #5 from chris at bubblescope dot net 2006-09-20 10:15 --- The reason I bought this up here, is because I thought (and I could be wrong, sorry) that the overflow was being caused by the fact that we allow the container size to get too big, and if we pull max_size() down to a proper level, then the container should never have to deal with arithmetic overflow. Of course as a QoI issue, we might want good behaviour even if someone tries to resize a container larger than max_size. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29134
[Bug libstdc++/29134] Has there been a serious attempt to define the max_size() member functions?
--- Comment #6 from pcarlini at suse dot de 2006-09-20 10:22 --- (In reply to comment #5) > The reason I bought this up here, is because I thought (and I could be wrong, > sorry) that the overflow was being caused by the fact that we allow the > container size to get too big, and if we pull max_size() down to a proper > level, then the container should never have to deal with arithmetic overflow. In principle, very in principle. Because we are talking here about *discontiguous* memory containers, not about vector. I'm not even sure the semantics of max_size allows (of course doesn't requires) that each time we go down to the machine and interact with the OS in order to try to figure out how much memory it's actually overall available. The last time I discussed a bit this issue with LWG people I seem to remember that the assumed user general expectation was that of *constant* numbers, meaning overall max "time independent" numbers (+ appropriate case-by-case, exceptions, of course). You may want to brought up the issue again... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29134
[Bug libstdc++/29134] Has there been a serious attempt to define the max_size() member functions?
--- Comment #7 from pcarlini at suse dot de 2006-09-20 10:45 --- ... and in fact, even for vector, I think we can only reasonably provide a time-independent upper-bound, because in general we cannot know how much memory each element' constructor is going to allocate... No, I'm more and more convinced that we cannot do much for the issue as originally presented, of course the arithmetic in deque must be robustified, it will. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29134
[Bug libstdc++/29134] Has there been a serious attempt to define the max_size() member functions?
--- Comment #8 from chris at bubblescope dot net 2006-09-20 11:10 --- I agree also we can't do any better. On 64 bit systems it will be even harder to give anything sensible. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29134
[Bug c++/29148] New: can't subtract 'volatile char *' from 'const char *'
#include
char str[] = "abc";
const char *a1 = str;
struct A { operator const char *() {return str;} } a2;
volatile char *b1 = str;
struct B { operator volatile char *() {return str;} } b2;
int
main()
{
printf ("%p\n", a1);
printf ("%p\n", b1);
printf ("%p\n", (const char *)a2);
printf ("%p\n", (volatile char *)b2);
printf ("%d\n", a1 - b1);
printf ("%d\n", (const char *)a2 - (volatile char *)b2);
printf ("%d\n", a2 - b2); // error reported here
return 0;
}
gives:
t.cpp: In function int main():
t.cpp:22: error: no match for operator- in a2 - b2
t.cpp:22: note: candidates are: operator-(volatile char*, volatile char*)
t.cpp:22: note: operator-(const char*, const char*)
However, lines 20 and 21 clearly do the same operation, but slightly
differently. These lines appear to be able to convert the types, presumably
according to clause 4.4 of the C++ standard, but the last example cannot. Yet
the error message shows that it has found the right conversion operators.
EDG 3.0 compiles this without any issues.
Note: the correct behaviour of this program is to print the same pointer four
times, and then print zero three times.
--
Summary: can't subtract 'volatile char *' from 'const char *'
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=29148
[Bug fortran/23375] show location for runtime errors
--- Comment #9 from tobias dot burnus at physik dot fu-berlin dot de 2006-09-20 11:57 --- I think this is fixed. If there are other errors, not covered, one could still reopen this bug or create a new one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23375
[Bug c++/29148] can't subtract 'volatile char *' from 'const char *'
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-09-20 12:58 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Last reconfirmed|-00-00 00:00:00 |2006-09-20 12:58:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29148
[Bug target/29124] unoptimal addressing mode.
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-09-20 13:21 --- So not a bug with the FSF GCC so closing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29124
[Bug target/24669] Loop index variable has offset of 1
--- Comment #5 from pluto at agmk dot net 2006-09-20 13:25 --- (In reply to comment #3) > Following patch to ix86_address_cost: this patch causes the PR29124. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24669
[Bug libstdc++/29134] Has there been a serious attempt to define the max_size() member functions?
--- Comment #9 from pcarlini at suse dot de 2006-09-20 15:00 --- (In reply to comment #8) > I agree also we can't do any better. On 64 bit systems it will be even harder > to give anything sensible. I'm only wondering whether it would make sense to divide by sizeof(T) also in the other containers beside vector: the upper bound would be somewhat tighter and still correct, AFAICS. What do you think? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29134
[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites
--- Comment #6 from bkoz at gcc dot gnu dot org 2006-09-20 15:18 --- Huh. Dave, is revision 116942M the same as revision 116942? Of these, 19_diagnostics/23591_thread-1.c is probably the easiest to debug. Since this is the linux target, and not the hpux target, the code paths for the locking code should be the same as for x86/linux. x86/s390/s390x/powerpc/powerpc64/ia64 all are using these code paths and look fine. What's different about hppa? -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118
[Bug libstdc++/29134] Has there been a serious attempt to define the max_size() member functions?
--- Comment #10 from pcarlini at suse dot de 2006-09-20 15:57 --- (In reply to comment #9) > I'm only wondering whether it would make sense to divide by sizeof(T) also in > the other containers beside vector: the upper bound would be somewhat tighter > and still correct, AFAICS. What do you think? Even better, it can be used the max_size of an allocator of value_type. That seems a very safe upper bound and probably the consistency with allocator will make submitter happy ;) -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-20 15:57:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29134
[Bug java/29150] New: [win32] java.library.path broken
While passing -Djava.library.path=foobar to GCJ leads to the expected behaviour
on linux, it seems to be ignored on windows.
Actually System.getProperty("java.library.path") returns the correct value on
both plattforms, but System.loadLibrary() only uses it on linux.
--
Summary: [win32] java.library.path broken
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mtrudel at gmx dot ch
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-mingw32
GCC target triplet: i686-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29150
[Bug java/29151] New: [win32] Runtime.exec(String[] cmdarray, String[] envp) -> envp doesn't work
Runtime.exec(String[] cmdarray, String[] envp) doesn't set the environment on windows but it works on linux. This can be reproduced with the attached files (both compiled to executables and CreateEnv calling PrintEnv). -- Summary: [win32] Runtime.exec(String[] cmdarray, String[] envp) - > envp doesn't work Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mtrudel at gmx dot ch GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-mingw32 GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29151
[Bug java/29151] [win32] Runtime.exec(String[] cmdarray, String[] envp) -> envp doesn't work
--- Comment #1 from mtrudel at gmx dot ch 2006-09-20 16:32 --- Created an attachment (id=12300) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12300&action=view) Program that uses Runtime.exec(...) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29151
[Bug java/29151] [win32] Runtime.exec(String[] cmdarray, String[] envp) -> envp doesn't work
--- Comment #2 from mtrudel at gmx dot ch 2006-09-20 16:33 --- Created an attachment (id=12301) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12301&action=view) Program that gets called by Runtime.exec(...) and doesn't have the environment set -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29151
[Bug target/28675] [4.1/4.2 regression] ICE in extract_insn, at recog.c:2084 (unrecognizable insn) [arm]
--- Comment #6 from bugreports at nn7 dot de 2006-09-20 16:38 --- I am getting exactly the same here on ppc (so it is not just arm specific): $ c++ -v Using built-in specs. Target: powerpc-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --disable-softfloat --enable-targets=powerpc-linux,powerpc64-linux --with-cpu=default32 --enable-checking=release powerpc-linux-gnu Thread model: posix gcc version 4.1.2 20060901 (prerelease) (Debian 4.1.1-13) -- bugreports at nn7 dot de changed: What|Removed |Added CC||bugreports at nn7 dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28675
[Bug target/28574] [4.2 regression] switch statement points to unreferenced label at -O2
--- Comment #10 from sje at gcc dot gnu dot org 2006-09-20 16:41 --- Subject: Bug 28574 Author: sje Date: Wed Sep 20 16:41:12 2006 New Revision: 117084 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117084 Log: PR target/28574 * ifcvt.c (dead_or_predicable): Don't predicate then blocks with tablejumps in them. Added: trunk/gcc/testsuite/gcc.dg/pr28574.c Modified: trunk/gcc/ChangeLog trunk/gcc/ifcvt.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28574
[Bug libffi/29152] New: 64-bit darwin ppc port needed for libffi
Currently, due to the absence of a 64-bit port for Darwin PPC, the libffi suffers massive failures on that architecture at -m64... === libffi Summary for unix/-m32 === # of expected passes1068 # of expected failures 8 # of unsupported tests 8 === libffi Summary for unix/-m64 === # of expected passes472 # of unexpected failures384 # of expected failures 8 # of unsupported tests 8 === libffi Summary === # of expected passes1540 # of unexpected failures384 # of expected failures 16 # of unsupported tests 16 -- Summary: 64-bit darwin ppc port needed for libffi Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libffi AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: powerpc-apple-darwin8 GCC host triplet: powerpc-apple-darwin8 GCC target triplet: powerpc-apple-darwin8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29152
[Bug java/29150] [win32] java.library.path broken
--- Comment #1 from mtrudel at gmx dot ch 2006-09-20 16:49 --- Tom commented this on the mailing list. Might be useful: Offhand I would expect this to work ok. You might verify that USE_LTDL is set on Windows; see the two definitions of _Jv_SetDLLSearchPath in natSystemProperties.cc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29150
[Bug target/28574] [4.2 regression] switch statement points to unreferenced label at -O2
--- Comment #11 from sje at cup dot hp dot com 2006-09-20 16:49 --- Fix is now checked in. -- sje at cup dot hp dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28574
[Bug java/23184] I18n bug in gjavah.c
--- Comment #2 from tromey at gcc dot gnu dot org 2006-09-20 16:53 --- This will be fixed by the ecj merge; we're deleting this version of gcjh. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org BugsThisDependsOn||28067 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23184
[Bug libgcj/29153] New: [ecj] clean up pthread assumptions
The new Unsafe code assumes pthreads in a number of places. This blocks a merge. -- Summary: [ecj] clean up pthread assumptions Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tromey at gcc dot gnu dot org OtherBugsDependingO 28067 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29153
[Bug libgcj/29153] [ecj] clean up pthread assumptions
-- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-20 16:55:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29153
[Bug rtl-optimization/28096] fdlibm/strtod.c miscompiled at -O2
--- Comment #16 from tromey at gcc dot gnu dot org 2006-09-20 16:57 --- Yes, this is a regression. It works fine with -O2 with my system compiler (FC5 gcc, based on gcc 4.1). It also works fine with -O2 using my gcc 4.1 build. It fails with svn head. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28096
[Bug java/28938] [ecj] update build instructions to account for changes
--- Comment #2 from tromey at gcc dot gnu dot org 2006-09-20 17:04 --- Yes, I plan on making an ecj jar download available. In the near term I will put one on gcc.gnu.org (or elsewhere). In the longer term I plan to get my ecj changes upstream, and then we will be able to point people at the official eclipse.org download (eclipse.org started releasing separate ecj jars recently). Our particular ecj has a new driver which is tailored for gcc's use. gcj on the branch looks for a program called "ecj1". I just have this as a simple shell script, but there are any number of ways to do this... eg you could compile ecj.jar to an executable using gcj. This is found using the normal gcc specs approach. In a distribution I'd expect ecj1 to end up in the gcc-lib dir. In my case I just have it on my PATH. We won't be including the ecj sources in the gcc tree. As I recall that was rejected by the SC. So it will always be a separate download. We also require a new version of gcjh. This is also written in java. The code is part of GNU Classpath, but instead of struggling with the bootstrap issues there, I'll again just make a downloadable jar. Both ecj and the new gcjh can be run on any vm, including all the free ones. I've built libgcj many times running these purely interpreted and it is not painfully slow. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-09-20 17:04:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28938
Re: [Bug target/28675] [4.1/4.2 regression] ICE in extract_insn, at recog.c:2084 (unrecognizable insn) [arm]
On Wed, 2006-09-20 at 16:38 +, bugreports at nn7 dot de wrote: > > --- Comment #6 from bugreports at nn7 dot de 2006-09-20 16:38 --- > I am getting exactly the same here on ppc (so it is not just arm specific): Yes it is. The bug you are getting with PPC is a different bug and should be filed separately. Thanks, Andrew Pinski
[Bug target/28675] [4.1/4.2 regression] ICE in extract_insn, at recog.c:2084 (unrecognizable insn) [arm]
--- Comment #7 from pinskia at physics dot uc dot edu 2006-09-20 17:16 --- Subject: Re: [4.1/4.2 regression] ICE in extract_insn, at recog.c:2084 (unrecognizable insn) [arm] On Wed, 2006-09-20 at 16:38 +, bugreports at nn7 dot de wrote: > > --- Comment #6 from bugreports at nn7 dot de 2006-09-20 16:38 --- > I am getting exactly the same here on ppc (so it is not just arm specific): Yes it is. The bug you are getting with PPC is a different bug and should be filed separately. Thanks, Andrew Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28675
[Bug libffi/29152] 64-bit darwin ppc port needed for libffi
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29152
[Bug rtl-optimization/28096] [4.2 regression] fdlibm/strtod.c miscompiled at -O2
--- Comment #17 from ebotcazou at gcc dot gnu dot org 2006-09-20 17:38 --- > Yes, this is a regression. > It works fine with -O2 with my system compiler (FC5 gcc, based on gcc 4.1). > It also works fine with -O2 using my gcc 4.1 build. > It fails with svn head. Thanks for the info. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Summary|fdlibm/strtod.c miscompiled |[4.2 regression] |at -O2 |fdlibm/strtod.c miscompiled ||at -O2 Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28096
[Bug rtl-optimization/28096] [4.2 regression] fdlibm/strtod.c miscompiled at -O2
--- Comment #18 from ebotcazou at gcc dot gnu dot org 2006-09-20 17:39 --- Investigating. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-09-10 09:03:40 |2006-09-20 17:39:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28096
[Bug boehm-gc/29068] [4.2 Regression] Bootstrap fails building libjava on SPARC/Solaris
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2006-09-20 17:42 --- Thanks for the fix. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29068
[Bug libstdc++/29134] Has there been a serious attempt to define the max_size() member functions?
-- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29134
[Bug c/29154] New: *(* ppointer++)++ = *pointer++ generates bad code
Overview:
The following C generates bad assembler on both PowerPC and Intel, even with no
optimization:
*( *pDest++ )++ = *pSource++;
Ripping this apart into two lines succeeds, thus:
**pDest = *pSource++;
*( *pDest++ )++;
System Description:
System: Apple OS X 10.4 (gcc 4.0.1) and Mandriva Linux 2.6.11-6mdk (downloaded
and built tarballs for 4.0.1 and 4.1.1)
Compiled with: gcc test-increment.c OR
gcc -g test-increment.cOR
gcc -save-temps test-increment.c
Compiler completed with no complaints
Pre-processed intermediate, test-increment.i:
# 1 "test-increment.c"
# 1 ""
# 1 ""
# 1 "test-increment.c"
# 1 "/usr/include/stdio.h" 1 3 4
# 28 "/usr/include/stdio.h" 3 4
# 1 "/usr/include/features.h" 1 3 4
# 308 "/usr/include/features.h" 3 4
# 1 "/usr/include/sys/cdefs.h" 1 3 4
# 309 "/usr/include/features.h" 2 3 4
# 331 "/usr/include/features.h" 3 4
# 1 "/usr/include/gnu/stubs.h" 1 3 4
# 332 "/usr/include/features.h" 2 3 4
# 29 "/usr/include/stdio.h" 2 3 4
# 1
"/home/akla/gcc-4.1.1-install/lib/gcc/i686-pc-linux-gnu/4.1.1/include/stddef.h"
1 3 4
# 214
"/home/akla/gcc-4.1.1-install/lib/gcc/i686-pc-linux-gnu/4.1.1/include/stddef.h"
3 4
typedef unsigned int size_t;
# 35 "/usr/include/stdio.h" 2 3 4
# 1 "/usr/include/bits/types.h" 1 3 4
# 28 "/usr/include/bits/types.h" 3 4
# 1 "/usr/include/bits/wordsize.h" 1 3 4
# 29 "/usr/include/bits/types.h" 2 3 4
# 1
"/home/akla/gcc-4.1.1-install/lib/gcc/i686-pc-linux-gnu/4.1.1/include/stddef.h"
1 3 4
# 32 "/usr/include/bits/types.h" 2 3 4
typedef unsigned char __u_char;
typedef unsigned short int __u_short;
typedef unsigned int __u_int;
typedef unsigned long int __u_long;
typedef signed char __int8_t;
typedef unsigned char __uint8_t;
typedef signed short int __int16_t;
typedef unsigned short int __uint16_t;
typedef signed int __int32_t;
typedef unsigned int __uint32_t;
__extension__ typedef signed long long int __int64_t;
__extension__ typedef unsigned long long int __uint64_t;
__extension__ typedef long long int __quad_t;
__extension__ typedef unsigned long long int __u_quad_t;
# 129 "/usr/include/bits/types.h" 3 4
# 1 "/usr/include/bits/typesizes.h" 1 3 4
# 130 "/usr/include/bits/types.h" 2 3 4
__extension__ typedef __u_quad_t __dev_t;
__extension__ typedef unsigned int __uid_t;
__extension__ typedef unsigned int __gid_t;
__extension__ typedef unsigned long int __ino_t;
__extension__ typedef __u_quad_t __ino64_t;
__extension__ typedef unsigned int __mode_t;
__extension__ typedef unsigned int __nlink_t;
__extension__ typedef long int __off_t;
__extension__ typedef __quad_t __off64_t;
__extension__ typedef int __pid_t;
__extension__ typedef struct { int __val[2]; } __fsid_t;
__extension__ typedef long int __clock_t;
__extension__ typedef unsigned long int __rlim_t;
__extension__ typedef __u_quad_t __rlim64_t;
__extension__ typedef unsigned int __id_t;
__extension__ typedef long int __time_t;
__extension__ typedef unsigned int __useconds_t;
__extension__ typedef long int __suseconds_t;
__extension__ typedef int __daddr_t;
__extension__ typedef long int __swblk_t;
__extension__ typedef int __key_t;
__extension__ typedef int __clockid_t;
__extension__ typedef int __timer_t;
__extension__ typedef long int __blksize_t;
__extension__ typedef long int __blkcnt_t;
__extension__ typedef __quad_t __blkcnt64_t;
__extension__ typedef unsigned long int __fsblkcnt_t;
__extension__ typedef __u_quad_t __fsblkcnt64_t;
__extension__ typedef unsigned long int __fsfilcnt_t;
__extension__ typedef __u_quad_t __fsfilcnt64_t;
__extension__ typedef int __ssize_t;
typedef __off64_t __loff_t;
typedef __quad_t *__qaddr_t;
typedef char *__caddr_t;
__extension__ typedef int __intptr_t;
__extension__ typedef unsigned int __socklen_t;
# 37 "/usr/include/stdio.h" 2 3 4
typedef struct _IO_FILE FILE;
# 62 "/usr/include/stdio.h" 3 4
typedef struct _IO_FILE __FILE;
# 72 "/usr/include/stdio.h" 3 4
# 1 "/usr/include/libio.h" 1 3 4
# 32 "/usr/include/libio.h" 3 4
# 1 "/usr/include/_G_config.h" 1 3 4
# 14 "/usr/include/_G_config.h" 3 4
# 1
"/home/akla/gcc-4.1.1-install/lib/gcc/i686-pc-linux-gnu/4.1.1/include/stddef.h"
1 3 4
# 326
"/home/akla/gcc-4.1.1-install/lib/gcc/i686-pc-linux-gnu/4.1.1/include/stddef.h"
3 4
typedef long int wchar_t;
# 355
"/home/akla/gcc-4.1.1-install/lib/gcc/i686-pc-linux-gnu/4.1.1/include/stddef.h"
3 4
typedef unsigned int wint_t;
# 15 "/usr/include/_G_config.h" 2 3 4
# 24 "/usr/include/_G_config.h" 3 4
# 1 "/usr/include/wchar.h" 1 3 4
# 48 "/usr/include/wchar.h" 3 4
# 1
"/home/akla/gcc-4.1.1-install/lib/gcc/i686-pc-linux-gnu/4.1.1/include/stddef.h"
1 3 4
# 49 "/usr/include/wchar.h" 2 3 4
# 1 "/usr/include/bits/wchar.h" 1 3 4
# 51 "/usr/include/wchar.h" 2 3 4
# 76 "/usr/include/wchar.h" 3 4
typedef struct
{
int __count;
union
{
wint_t __wch;
char __wchb[4];
} __value;
} __mbstate_t;
# 25 "/usr/include/_G_config.h" 2 3 4
typedef struct
{
__off_t __pos;
__mbstate
[Bug boehm-gc/28760] GC_PTHREAD_CREATE_NAME segfaults in statically linked binaries
--- Comment #7 from sgilbertson at gcc dot gnu dot org 2006-09-20 18:45 --- I checked out revision 117082 (trunk) and successfully built a few static binaries with it. So unless Thomas saw a different problem than I did, I'd say it's fixed. Configured with: ../gcc/configure --prefix=/var/local/gcc/tip_20060920 --mandir=/var/local/gcc/man --infodir=/var/local/gcc/info --enable-shared --enable-threads=posix --disable-checking --host=i386-redhat-linux --enable-java-awt=xlib --enable-libgcj --enable-languages=c,c++,java --with-system-zlib --enable-__cxa_atexit Thread model: posix -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28760
[Bug c/29154] *(* ppointer++)++ = *pointer++ generates bad code
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-20 18:47 --- **pDest = *pSource++; *( *pDest++ )++; [t1.c : 1055] D.1948 = *pWriteBuf; [t1.c : 1055] D.1949 = *pReadBuf; [t1.c : 1055] *D.1948 = D.1949; [t1.c : 1055] pReadBuf = pReadBuf + 1B; [t1.c : 1056] D.1950 = *pWriteBuf; [t1.c : 1056] D.1951 = D.1950 + 1B; [t1.c : 1056] *pWriteBuf = D.1951; [t1.c : 1056] pWriteBuf = pWriteBuf + 4B; *(*(pWriteBuf++)++) = *pReadBuf++; [t1.c : 1079] D.1957 = *pWriteBuf; [t1.c : 1079] D.1959 = *pReadBuf; [t1.c : 1079] *D.1957 = D.1959; [t1.c : 1079] pWriteBuf = pWriteBuf + 4B; [t1.c : 1079] D.1958 = D.1957 + 1B; [t1.c : 1079] *pWriteBuf = D.1958; <--- store at *(pWriteBuf+1) [t1.c : 1079] pReadBuf = pReadBuf + 1B; I don't know if this is correct. Next time please attach the preprocessed source after filing the bug report instead of copying and pasting the source into the bug report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29154
[Bug middle-end/25505] [4.0/4.1/4.2 Regression] gcc uses way too much stack space for this code
--- Comment #22 from jconner at gcc dot gnu dot org 2006-09-20 18:57 --- Subject: Bug 25505 Author: jconner Date: Wed Sep 20 18:57:46 2006 New Revision: 117091 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117091 Log: 2006-09-20 Josh Conner <[EMAIL PROTECTED]> PR middle-end/25505 * calls.c (expand_call): Allow reuse of structure return stack temp. Modified: trunk/gcc/ChangeLog trunk/gcc/calls.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25505
[Bug boehm-gc/28760] GC_PTHREAD_CREATE_NAME segfaults in statically linked binaries
--- Comment #8 from tromey at gcc dot gnu dot org 2006-09-20 19:15 --- ok, I'm closing. Please reopen if it is still a problem. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28760
[Bug other/28230] -O2 -fwrapv miscompiles gcc, binutils, gzip.
--- Comment #8 from pluto at agmk dot net 2006-09-20 20:44 --- (In reply to comment #7) > and one more misscompiled program -> gzip-1.3.5. > this time 4.1.2 with -O2 -fwrapv produces wrong code. > > $ dd if=/dev/zero of=foo count=10 > $ gzip foo > $ gzip -d foo.gz > $ gzip: foo.gz: invalid compressed data--format violated further investigation shows that only `-O1 -ftree-vrp -fwrapv' miscompiles the gzip/inflate.o. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28230
[Bug other/28230] -O2 -fwrapv miscompiles gcc, binutils, gzip.
--- Comment #9 from pluto at agmk dot net 2006-09-20 20:44 --- Created an attachment (id=12302) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12302&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28230
[Bug ada/28716] Ada: Bind_Socket doesn't bind to specified address
--- Comment #5 from guerby at gcc dot gnu dot org 2006-09-20 20:46 --- Subject: Bug 28716 Author: guerby Date: Wed Sep 20 20:46:28 2006 New Revision: 117092 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117092 Log: 2006-08-20 Laurent GUERBY <[EMAIL PROTECTED]> PR ada/28716 g-socket.adb (Bind_Socket): Call Set_Address. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/g-socket.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28716
[Bug target/28604] [4.1/4.2 Regression] gcc.c-torture/execute/20050604-1.c fails on IA64 at -O3
--- Comment #7 from sje at cup dot hp dot com 2006-09-20 21:23 --- This bug is weird. If I remove the code in cse_insn where the dest_addr_elt field is used, I still get the bug. So the problem occurs when creating the dest_addr_elt data, not when using it. This makes no sense to me, but that is what I see. I built with --enable-checking=all to see if it caught any data corruption or bad field accesses but I didn't get any errors. I am not sure what to try next. Paul, do you have any idea why your changes would affect a compilation if we create dest_addr_elt but don't use it? -- sje at cup dot hp dot com changed: What|Removed |Added CC||pbrook at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28604
[Bug ada/28716] Ada: Bind_Socket doesn't bind to specified address
--- Comment #6 from laurent at guerby dot net 2006-09-20 21:51 --- Fixed on 4.2 -- laurent at guerby dot net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28716
[Bug c/29155] New: GCC Internals - NEED HELP
Dear Readers,
Although this is not a bug report I tought I better to ask
my problem in here and ask you if you can help me.
I have to add some user defined procedures or types to C and to alter GCC
to detect these changes, actually I want to alter the C language
definition which is given to GCC. for example I want to define a new type like
X in addition to others like int or string or etc.
Or I want to define a new structure like UNI{} which resembles the union struct
but with different name and definition.
I have surfed several articles for adding new front-ends to GCC but non of
them wasn't about C.
please help me.
if you know the answer I really appreciate if you give me a complete
answer cause I am a beginner in this feild and I have to find out the
answer in addition to some useful results to hand them in to my professor
in order to get the needed grade!!
--
Summary: GCC Internals - NEED HELP
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mousavi at ce dot sharif dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29155
[Bug c++/26698] [4.0/4.1/4.2 Regression] g++ accepts const-incorrect code due to conversion function
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26698
[Bug target/28405] 4.x code generation regression relative to 3.4.6
--- Comment #2 from lopezibanez at gmail dot com 2006-09-20 22:04 --- I can confirm this in a recent build of GCC: (GNU) 4.2.0 20060913 (experimental) on i686-pc-linux-gnu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28405
[Bug c/29155] GCC Internals - NEED HELP
--- Comment #1 from steven at gcc dot gnu dot org 2006-09-20 22:05 --- The bug database is no place for this kind of question. First you should look for answers in the source code. This will be trial and error, but this is your exercise so don't ask us to make it for you. If you get stuck but you understand sufficiently well what you're trying to achieve (and how) to ask an intelligent question on the mailing list, you'll probably get an answer there. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29155
[Bug libmudflap/28077] [4.1/4.2 regression] pass39-frag.c produces mudflap violation on alpha
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28077
[Bug rtl-optimization/28096] [4.2 regression] fdlibm/strtod.c miscompiled at -O2
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28096
[Bug target/28405] 4.x code generation regression relative to 3.4.6
--- Comment #3 from steven at gcc dot gnu dot org 2006-09-20 22:19 --- *** This bug has been marked as a duplicate of 24929 *** -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28405
[Bug middle-end/24929] long long shift/mask operations should be better optimized
--- Comment #6 from steven at gcc dot gnu dot org 2006-09-20 22:19 --- *** Bug 28405 has been marked as a duplicate of this bug. *** -- steven at gcc dot gnu dot org changed: What|Removed |Added CC||vda dot linux at googlemail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24929
[Bug tree-optimization/29156] New: Misscompilation due to alias analysis
The testcase below gets misscompiled at -O2.
The alias info looks this way:
Dereferenced pointers
xa, UID 1527, struct test1 *, symbol memory tag: SMT.4, default def: xa_4
xb, UID 1528, struct test2 *, symbol memory tag: SMT.5, default def: xb_3
Symbol memory tags
SMT.4, UID 1547, struct test1, is addressable, is global, call clobbered, may
aliases: { global }
SMT.5, UID 1548, struct test2, is addressable, is global, call clobbered, may
aliases: { global }
The alias sets for SMT.4 and SMT.5 intersect, so everything looks OK here.
However, access_can_touch_variable (correctly) determines that the dereferences
of xa and xb cannot touch "global"; hence we create the following virual
operands:
# SMT.5_8 = V_MAY_DEF ;
xb_3->sub.a = 1;
# SMT.4_10 = V_MAY_DEF ;
xa_4->a = 8;
# VUSE ;
D.1531_5 = xb_3->sub.a;
The accesses to xa and xb appear to be independent, which leads to a
misscompilation.
struct test1
{
int a;
int b;
};
struct test2
{
float d;
struct test1 sub;
};
int global;
int bla(struct test1 *xa, struct test2 *xb)
{
global = 1;
xb->sub.a = 1;
xa->a = 8;
return xb->sub.a;
}
int main(void)
{
struct test2 pom;
if (bla (&pom.sub, &pom) != 8)
abort ();
return 0;
}
--
Summary: Misscompilation due to alias analysis
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rakdver at gcc dot gnu dot org
GCC build triplet: i686-pc-linux
GCC host triplet: i686-pc-linux
GCC target triplet: i686-pc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29156
[Bug target/28183] [4.0/4.1/4.2 regression] assembler error "FATAL: can't close x.o" on m68k with new binutils
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28183
[Bug c++/28211] [4.0/4.1/4.2 Regression] wrong linkage of template argument, diagnostic could be improved
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28211
[Bug tree-optimization/29156] [4.2 Regression] Misscompilation due to struct alias
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||alias Known to fail||4.2.0 Known to work||4.1.0 Summary|Misscompilation due to alias|[4.2 Regression] |analysis|Misscompilation due to ||struct alias Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29156
[Bug target/28307] [4.1/4.2 Regression] pthread functions in libgcc not weak any more on Tru64 UNIX
--- Comment #4 from mmitchel at gcc dot gnu dot org 2006-09-20 22:26 --- Marked as P5 because this is marked as applying to Alpha/OSF. If this problem applies to other platforms, please set back to P3 with explanatory comment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28307
[Bug tree-optimization/29156] [4.2 Regression] Misscompilation due to struct alias
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-09-20 22:26 --- Confirmed, a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i686-pc-linux | GCC host triplet|i686-pc-linux | GCC target triplet|i686-pc-linux | Last reconfirmed|-00-00 00:00:00 |2006-09-20 22:26:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29156
[Bug target/28604] [4.1/4.2 Regression] gcc.c-torture/execute/20050604-1.c fails on IA64 at -O3
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28604
[Bug bootstrap/28864] bootstrapping fails when building from non-/bin/sh-compatible shell
--- Comment #4 from abs at absd dot org 2006-09-20 22:27 --- Seeing the same issue with gcc 3.4.6 on NetBSD/i386 4.0_BETA using gmake 3.81 and SHELL=/bin/tcsh -- abs at absd dot org changed: What|Removed |Added CC||abs at absd dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28864
[Bug middle-end/28964] [4.0/4.1/4.2 Regression] partition_stack_vars uses unstable sort
--- Comment #2 from mmitchel at gcc dot gnu dot org 2006-09-20 22:32 --- A meta-bug would be helpful. I've marked this P2, since this bug doesn't actually result in a user-observable problem on a single host -- but it is extremely desirable from the point of view of us, as GCC developers, and from the point of view of many users, that all hosts generate the same code. So, it would be very good to get this defect fixed. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28964
[Bug c++/29020] [4.0/4.1/4.2 regression] ICE using A::A instead of A in friend declaration
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29020
[Bug c++/29021] [4.0/4.1/4.2 regression] ICE on invalid use of "*" in template
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29021
[Bug c++/29022] [4.0/4.1/4.2 regression] ICE using operator int in invalid class hierarchy
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29022
[Bug c++/29024] [4.0/4.1/4.2 Regression] storage class specifier accepted for typedef (clause 7.1.1 ; 1)
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29024
[Bug c++/29039] [4.0/4.1/4.2 Regression] implicitly defined constructor for class with reference member
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29039
[Bug c++/29048] [4.0/4.1/4.2 Regression] "`x' is private" error duplicated when scope specified
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29048
[Bug c++/29080] [4.0/4.1/4.2 Regression] Multiple-inheritance with template method function code triggers "internal compiler error: in build_base_path, at cp/class.c:273"
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29080
[Bug c/29091] [4.0/4.1/4.2 Regression] vector constant not fully outputed
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29091
[Bug c/29092] [4.0/4.1/4.2 Regression] vector int a = (vector int) { 1,1,2,2} is rejected as non constant
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29092
[Bug libstdc++/29095] [4.0/4.1/4.2 Regression] cxxabi.h __cxa_cdtor_type not declared when included from "C"
--- Comment #5 from mmitchel at gcc dot gnu dot org 2006-09-20 22:49 --- The language linkage of the type is supposed to matter in some cases -- but G++ doesn't implement that, so I don't think the difference is observable in GNU C++. In any case, we should try to make the file compile in C -- or else remove the #ifdefs -- so, even if we want to keep the C++ linkage for the type, we should provide a declaration in C mode. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29095
[Bug c++/29105] [4.2 Regression] segfault in add_candidates with a non template base class and a template member function
-- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29105
[Bug target/28604] [4.1/4.2 Regression] gcc.c-torture/execute/20050604-1.c fails on IA64 at -O3
--- Comment #8 from pbrook at gcc dot gnu dot org 2006-09-20 22:55 --- IIRC my change can cause entries to be present into the hash table that wouldn't have been there before. However this should be harmless. I don't have any helpful suggestons why this is broken. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28604
[Bug target/27650] internal compiler error while compiling Gecode
--- Comment #9 from dannysmith at gcc dot gnu dot org 2006-09-20 23:27 --- Subject: Bug 27650 Author: dannysmith Date: Wed Sep 20 23:27:05 2006 New Revision: 117096 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117096 Log: PR target/27650 * class.c (check_for_override): Remove dllimport from virtual methods. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27650
[Bug other/28230] -O2 -fwrapv miscompiles gcc, binutils, gzip.
--- Comment #10 from pluto at agmk dot net 2006-09-20 23:31 ---
i have a reduced testcase:
$ cat tmp.c
void foo( unsigned long bb, unsigned short tn, unsigned e, unsigned* w )
{
unsigned n = tn + bb;
do {
e = (e > n) ? e : *w;
n -= (e > n) ? n : e;
if (*w)
*w = 0;
} while ( n );
}
int main()
{
unsigned w = 0;
foo( 0, 0, 0, &w );
return 0;
}
with `-O1 -fwrapv -ftree-vrp' gcc-4.2 produces an infinite loop.
without -ftree-vrp it reaches an exit point. gcc-4.1 works fine
in both cases.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28230
[Bug target/27650] internal compiler error while compiling Gecode
--- Comment #10 from dannysmith at gcc dot gnu dot org 2006-09-20 23:32
---
Subject: Bug 27650
Author: dannysmith
Date: Wed Sep 20 23:32:07 2006
New Revision: 117097
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117097
Log:
PR target/27650
* g++.dg/ext/dllimport12.C: New test.
Added:
trunk/gcc/testsuite/g++.dg/ext/dllimport12.C (with props)
Modified:
trunk/gcc/testsuite/ChangeLog
Propchange: trunk/gcc/testsuite/g++.dg/ext/dllimport12.C
('svn:executable' added)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27650
[Bug libstdc++/29118] [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2006-09-20 23:33 --- Subject: Re: [4.2 Regression] Timeouts in libstdc++, libjava and libgomp testsuites > Huh. Dave, is revision 116942M the same as revision 116942? I applied r116954 to 116942. > Of these, 19_diagnostics/23591_thread-1.c is probably the easiest to debug. I'm very busy at the moment, so the earliest I will be able to look at this is the weekend. > Since this is the linux target, and not the hpux target, the code paths for > the > locking code should be the same as for x86/linux. > > x86/s390/s390x/powerpc/powerpc64/ia64 all are using these code paths and look > fine. What's different about hppa? It's still using linuxthreads. Also because of the limitations of the ldcw semaphore instruction in PA 1.1, the atomic lock type is 16 bytes and there is a dynamic alignment calculation to select the aligned 4-byte object to use for the ldcw lock. As a result, there are limitations on copying/moving lock objects that aren't present in other implementations. NPTL is coming but its not quite ready for prime time. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29118
[Bug target/27650] internal compiler error while compiling Gecode
--- Comment #11 from dannysmith at users dot sourceforge dot net 2006-09-20 23:37 --- Fixed on trunk. Danny -- dannysmith at users dot sourceforge dot net changed: What|Removed |Added Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27650
[Bug tree-optimization/29145] unsafe use of restrict qualifier
--- Comment #2 from djg at cray dot com 2006-09-20 23:49 --- The definition of restrict in C99 6.7.3.1 doesn't say that only the original restrict-qualified pointer can be used to access the object it points to; it says that any pointer "based on" the original restrict-qualified pointer may access the object. Following paragraph #3, q is "based on" p. The code in question in GCC seems to be the code by this comment, in tree-data-ref.c: /* An instruction writing through a restricted pointer is "independent" of any instruction reading or writing through a different pointer, in the same block/scope. */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29145
[Bug target/11594] testcase gcc.dg/20020103-1.c fails with "scan-assembler-not LC"
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2006-09-20
23:49 ---
Does anyone know why we don't run this test at lp64 on powerpc? I find that on
powerpc-apple-darwin8 the following changes allow...
make check-gcc RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'
dg.exp=20020103-1.*"
to pass at both -m32 and -m64 on Darwin PPC...
Index: gcc.dg/20020103-1.c
===
--- gcc.dg/20020103-1.c (revision 117095)
+++ gcc.dg/20020103-1.c (working copy)
@@ -1,8 +1,8 @@
/* Verify that constant equivalences get reloaded properly, either by being
spilled to the stack, or regenerated, but not dropped to memory. */
-/* { dg-do compile { target { { i?86-*-* rs6000-*-* alpha*-*-* x86_64-*-* } ||
{ powerpc*-*-* && ilp32 } } } } */
+/* { dg-do compile { target { i?86-*-* rs6000-*-* alpha*-*-* x86_64-*-*
powerpc*-*-* } } } */
/* { dg-options "-O2 -fpic -fno-omit-frame-pointer
-fno-asynchronous-unwind-tables" } */
-/* { dg-final { scan-assembler-not "LC\[0-9\]" { xfail powerpc*-*-* } } } */
+/* { dg-final { scan-assembler-not "LC\[0-9\]" } } */
/* Clobber all call-saved registers that can hold a pointer value. */
#if defined(__i386__)
Could someone test this on AIX?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11594
[Bug libstdc++/29134] Has there been a serious attempt to define the max_size() member functions?
--- Comment #11 from paolo at gcc dot gnu dot org 2006-09-21 00:12 --- Subject: Bug 29134 Author: paolo Date: Thu Sep 21 00:11:52 2006 New Revision: 117099 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117099 Log: 2006-09-20 Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/29134 * include/bits/stl_list.h (list<>::max_size): Forward to allocator' max_size. * include/bits/stl_vector.h (vector<>::max_size): Likewise. * include/bits/stl_deque.h (deque<>::max_size): Likewise. * include/bits/stl_tree.h (_Rb_tree<>::max_size): Likewise. * include/tr1/hashtable (_Hashtable<>::max_size): Likewise. * testsuite/23_containers/vector/capacity/29134.cc: Add. * testsuite/23_containers/deque/capacity/29134.cc: Likewise. * testsuite/23_containers/list/capacity/29134.cc: Likewise. * testsuite/23_containers/set/capacity/29134.cc: Likewise. * testsuite/23_containers/map/capacity/29134.cc: Likewise. * testsuite/23_containers/multiset/capacity/29134.cc: Likewise. * testsuite/23_containers/multimap/capacity/29134.cc: Likewise. * testsuite/tr1/6_containers/unordered/capacity/29134-set.cc: Likewise. * testsuite/tr1/6_containers/unordered/capacity/29134-map.cc: Likewise. * testsuite/tr1/6_containers/unordered/capacity/29134-multiset.cc: Likewise. * testsuite/tr1/6_containers/unordered/capacity/29134-multimap.cc: Likewise. * include/bits/deque.tcc (deque<>::_M_new_elements_at_front, deque<>::_M_new_elements_at_back): Check for length errors. * testsuite/23_containers/deque/capacity/29134-2.cc: New. * testsuite/23_containers/vector/capacity/29134-2.cc: Likewise. * include/tr1/hashtable (_Hashtable<>::_M_get_Value_allocator): Add. (_Hashtable<>::_M_allocate_node, _M_deallocate_node): Use it. * testsuite/tr1/6_containers/unordered/instantiate/set.cc: Add test. * testsuite/tr1/6_containers/unordered/instantiate/map.cc: Likewise. * testsuite/tr1/6_containers/unordered/instantiate/multiset.cc: Likewise. * testsuite/tr1/6_containers/unordered/instantiate/multimap.cc: Likewise. Added: trunk/libstdc++-v3/testsuite/23_containers/deque/capacity/ trunk/libstdc++-v3/testsuite/23_containers/deque/capacity/29134-2.cc trunk/libstdc++-v3/testsuite/23_containers/deque/capacity/29134.cc trunk/libstdc++-v3/testsuite/23_containers/list/capacity/29134.cc trunk/libstdc++-v3/testsuite/23_containers/map/capacity/ trunk/libstdc++-v3/testsuite/23_containers/map/capacity/29134.cc trunk/libstdc++-v3/testsuite/23_containers/multimap/capacity/ trunk/libstdc++-v3/testsuite/23_containers/multimap/capacity/29134.cc trunk/libstdc++-v3/testsuite/23_containers/multiset/capacity/ trunk/libstdc++-v3/testsuite/23_containers/multiset/capacity/29134.cc trunk/libstdc++-v3/testsuite/23_containers/set/capacity/ trunk/libstdc++-v3/testsuite/23_containers/set/capacity/29134.cc trunk/libstdc++-v3/testsuite/23_containers/vector/capacity/29134-2.cc trunk/libstdc++-v3/testsuite/23_containers/vector/capacity/29134.cc trunk/libstdc++-v3/testsuite/tr1/6_containers/unordered/capacity/ trunk/libstdc++-v3/testsuite/tr1/6_containers/unordered/capacity/29134-map.cc trunk/libstdc++-v3/testsuite/tr1/6_containers/unordered/capacity/29134-multimap.cc trunk/libstdc++-v3/testsuite/tr1/6_containers/unordered/capacity/29134-multiset.cc trunk/libstdc++-v3/testsuite/tr1/6_containers/unordered/capacity/29134-set.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/deque.tcc trunk/libstdc++-v3/include/bits/stl_deque.h trunk/libstdc++-v3/include/bits/stl_list.h trunk/libstdc++-v3/include/bits/stl_tree.h trunk/libstdc++-v3/include/bits/stl_vector.h trunk/libstdc++-v3/include/tr1/hashtable trunk/libstdc++-v3/testsuite/tr1/6_containers/unordered/instantiate/map.cc trunk/libstdc++-v3/testsuite/tr1/6_containers/unordered/instantiate/multimap.cc trunk/libstdc++-v3/testsuite/tr1/6_containers/unordered/instantiate/multiset.cc trunk/libstdc++-v3/testsuite/tr1/6_containers/unordered/instantiate/set.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29134
