[Bug debug/21828] [4.0/4.1 Regression] debug info omitted for uninitialized variables
--- Additional Comments From hjl at lucon dot org 2005-07-05 06:09 --- My patch doesn't work with gcc.dg/varpool-1.c. c_write_global_declarations seems calling check_global_declarations and cgraph_optimize in the wrong order. Shouldn't check_global_declarations be called after cgraph_optimize instead of before? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21828
[Bug ada/22301] [4.1 Regression] Ada does not build into a clean prefix when unwind.h is not installed
--- Additional Comments From charlet at adacore dot com 2005-07-05 07:11 --- Subject: Re: [4.1 Regression] Ada does not build into a clean prefix when unwind.h is not installed I got the same issue on i686-linux, so this is affecting several targets apparently. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22301
[Bug tree-optimization/22135] The gcc-4.1-20050611 compiler ICE's using -ftree-vectorize in conjunction with -fdump-tree-all-details-stats
--- Additional Comments From Ralf_Recker at gmx dot de 2005-07-05 07:25 --- (In reply to comment #5) I forgot to mention this is due to how tree-optimizate works, it is really a bug (a known one), please file so we don't lose track of it. Sorry, I didn't understood your answer fully (stupid me :-) So is it entered in the BugZilla database, shall I enter it or shall we leave it alone? Ralf Recker -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22135
[Bug c/22305] New: Error during the make
I have the following errors during the make on AIX 5.2 ML5 with GCC4.0: cc -c -DHAVE_CONFIG_H -I.. -I. -I./../lib -g m4.c cc -c -DHAVE_CONFIG_H -I.. -I. -I./../lib -g builtin.c builtin.c, line 618.60: 1506-280 (W) Function argument assignment between types int(*)(const void*,const void*) and int(*)(const unsigned char*,const unsigned char*) is not allowed. cc -c -DHAVE_CONFIG_H -I.. -I. -I./../lib -g debug.c debug.c, line 228.15: 1506-275 (S) Unexpected text '...' encountered. debug.c, line 246.3: 1506-045 (S) Undeclared identifier va_alist. make: 1254-004 The error code from the last command is 1. thanks for your help Lionel Roux -- Summary: Error during the make Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: critical Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lionel dot roux at bio-rad dot com CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: P615 AIX 5.2 ML5 GCC target triplet: P615 AIX 5.2 ML5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22305
[Bug fortran/22306] New: ICE: segmentation fault
The attached code generates the subject error [EMAIL PROTECTED] TEMP]$ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.1-20050702/configure --prefix=/usr/local/gfortran Thread model: posix gcc version 4.1.0 20050702 (experimental) [EMAIL PROTECTED] TEMP]$ [EMAIL PROTECTED] TEMP]$ gfortran -c stack.f90 stack.f90:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: ICE: segmentation fault Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sfilippone at uniroma2 dot it CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22306
[Bug fortran/22306] ICE: segmentation fault
--- Additional Comments From sfilippone at uniroma2 dot it 2005-07-05 07:49 --- Created an attachment (id=9204) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9204action=view) Test case I believe the code is standard compliant, but even if it isn't the compiler fails spectacularly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22306
[Bug libfortran/22217] Z edit descriptor with negative numbers
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-07-05 07:52 --- For the GFC_LARGEST_INTEGER_KIND macro, there is already a GFC_INTEGER_LARGEST. Or do you mean that GFC_LARGEST_INTEGER_KIND should be just 8 (or 16), not GFC_INTEGER_8 (or GFC_INTEGER_16)? As for this bug, the solution you mention was the one I thought of, but it means changing prototypes. A better solution (at least, I think it is better) is to have an extract_uint() function that does cast to GFC_UINTEGER_4 before casting to GFC_UINTEGER_LARGEST. Attached patch fixes the problem (for Z, O and B edit descriptors, with all kinds). I'm leaving town tomorrow, won't have access to an internet connection and lots of things to do before tomorrow. So, please feel free to test and commit this patch! If nobody does it, I'll do it when I come back (in August). -- What|Removed |Added Keywords||patch Last reconfirmed|2005-06-29 20:53:37 |2005-07-05 07:52:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22217
[Bug ada/19382] ACATS cxb5002 simple To_Fortran test fails at runtime on s390-linux
--- Additional Comments From laurent at guerby dot net 2005-07-05 08:26 --- Still failing as of 4.0.1 RC3 (20050702) http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00183.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19382
[Bug fortran/22290] Optimize Assigned GOTO to cause error with -O1 or higher
--- Additional Comments From fengwang at gcc dot gnu dot org 2005-07-05
08:39 ---
(In reply to comment #3)
int4 nz.0 = -2; look line an INIT_EXPR. It should be
int4 nz.0;
nz.0 = -2
Shall we add an assignment explicitly? Just give an initial value. I don't
think we should defer doing this when generate function codes.
And another question, all the variables which have initial values are treat as
static. Is this reasonable?
Back to this topic, in fact, the error is not caused by nz.0. It is used to
judge if we assign a target label. And the output is Assigned label is not in
the list. So it has passed the judgement of nz.0.
From the trees dumped, I found the CCP pass is wrong:
$cat as.f.t22.ccp
;; Function MAIN__ (MAIN__)
Removing basic block 3
Merging blocks 2 and 4
Merging blocks 2 and 5
MAIN__ ()
{
void * gotovar.2;
void * nz.1;
int4 nz.0 = -2;
int4 nz;
unnamed type D.476;
logical4 D.475;
bb 0:
nz.0_1 = -1;
nz.1_2 = __label_93;
D.475_3 = 0;
D.476_4 = 0;
if (D.476_4 != 0) goto L0; else goto L1;
L0:;
_gfortran_runtime_error (Assigned label is not a target label, as.f, 2);
__label_93:; Wrong here.
L1:;
_gfortran_runtime_error (Assigned label is not in the list, as.f, 2
return;
}
Before this pass, it it correct.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22290
[Bug libfortran/22307] New: Missing tests for actual library functions
For a number of library functions, the current
tests only check what the compiler does.
Look at this:
$ cat ishft.f90
! { dg-do run }
! verifies basic functioning of the ishft and ishftc intrinsics
if (ishft (1_1, 0) /= 1) call abort
if (ishft (1_1, 1) /= 2) call abort
if (ishft (3_1, 1) /= 6) call abort
if (ishft (-1_1, 1) /= -2) call abort
if (ishft (-1_1, -1) /= 127) call abort
if (ishft (96_1, 2) /= -128) call abort
if (ishft (1_2, 0) /= 1) call abort
if (ishft (1_2, 1) /= 2) call abort
if (ishft (3_2, 1) /= 6) call abort
if (ishft (-1_2, 1) /= -2) call abort
if (ishft (-1_2, -1) /= 32767) call abort
if (ishft (16384_2 + 8192_2, 2) /= -32768_4) call abort
if (ishft (1_4, 0) /= 1) call abort
if (ishft (1_4, 1) /= 2) call abort
if (ishft (3_4, 1) /= 6) call abort
if (ishft (-1_4, 1) /= -2) call abort
if (ishft (-1_4, -1) /= 2147483647) call abort
if (ishft (1073741824_4 + 536870912_4, 2) /= -2147483648_8) call abort
if (ishft (1_8, 0) /= 1) call abort
if (ishft (1_8, 1) /= 2) call abort
if (ishft (3_8, 1) /= 6) call abort
if (ishft (-1_8, 1) /= -2) call abort
if (ishft (-1_8, -60) /= z'F') call abort
if (ishftc (1_1, 0) /= 1) call abort
if (ishftc (1_1, 1) /= 2) call abort
if (ishftc (3_1, 1) /= 6) call abort
if (ishftc (-1_1, 1) /= -1) call abort
if (ishftc (-1_1, -1) /= -1) call abort
if (ishftc (ishftc (96_1, 2), -2) /= 96) call abort
if (ishftc (1_2, 0) /= 1) call abort
if (ishftc (1_2, 1) /= 2) call abort
if (ishftc (3_2, 1) /= 6) call abort
if (ishftc (-1_2, 1) /= -1) call abort
if (ishftc (-1_2, -1) /= -1) call abort
if (ishftc (ishftc (25000_2, 2), -2) /= 25000) call abort
if (ishftc (1_4, 0) /= 1) call abort
if (ishftc (1_4, 1) /= 2) call abort
if (ishftc (3_4, 1) /= 6) call abort
if (ishftc (-1_4, 1) /= -1) call abort
if (ishftc (-1_4, -1) /= -1) call abort
if (ishftc (ishftc (1325876_4, 2), -2) /= 1325876) call abort
if (ishftc (1_8, 0) /= 1) call abort
if (ishftc (1_8, 1) /= 2) call abort
if (ishftc (3_8, 1) /= 6) call abort
if (ishftc (-1_8, 1) /= -1) call abort
if (ishftc (-1_8, -1) /= -1) call abort
if (ishftc (ishftc (1325876_8, 2), -2) /= 1325876) call abort
end
$ gfortran -fdump-tree-original ishft.f90
$ cat ishft.f90.t02.original
MAIN__ ()
{
(void) 0;
$ gfortran -v
Using built-in specs.
Target: ia64-unknown-linux-gnu
Configured with: ../gcc-4.1-20050702/configure --prefix=/home/zfkts --enable-
languages=c,f95
Thread model: posix
gcc version 4.1.0 20050702 (experimental)
We need more test cases that really test the library calls. Chances
are there may be a few more bugs out there like PR 22142 (which was
also hidden by this).
--
Summary: Missing tests for actual library functions
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22307
[Bug fortran/22290] Optimize Assigned GOTO to cause error with -O1 or higher
--- Additional Comments From fengwang at gcc dot gnu dot org 2005-07-05 08:44 --- From as.f.t22.ccp: bb 0: nz.0_1 = -1; nz.1_2 = __label_93; D.475_3 = 0; D.476_4 = 0; if (D.476_4 != 0) goto L0; else goto L1; This is also wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22290
[Bug fortran/22306] ICE: segmentation fault
--- Additional Comments From sfilippone at uniroma2 dot it 2005-07-05 09:44 --- Changing the line type(stack_node), pointer :: new_node into type(stack_node), pointer :: new_node = null() is a workaround. -- What|Removed |Added Summary|ICE: segmentation fault |ICE: segmentation fault http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22306
[Bug libgcj/22283] Fail to build libjava under zh_TW.UTF-8 locale.
--- Additional Comments From jserv at kaffe dot org 2005-07-05 09:59 --- So that, is there any chance to fix the issue, even via specific workaround? I have to change locale settings (zh_TW.UTF-8 -- C) when I rebuild GCJ. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22283
[Bug middle-end/20623] ICE: fold check: original tree changed by fold with --enable-checking=fold
--- Additional Comments From micis at gmx dot de 2005-07-05 10:48 --- With snapshot gcc-4.1-20050702 the following gcc tests fail: gcc.c-torture/compile/20020701-1.c gcc.c-torture/compile/20021108-1.c gcc.c-torture/compile/920501-7.c gcc.c-torture/compile/labels-1.c gcc.c-torture/compile/labels-2.c gcc.c-torture/compile/labels-3.c gcc.c-torture/execute/builtins/memmove-2.c gcc.c-torture/execute/builtins/strcat-chk.c gcc.c-torture/execute/builtins/strcat.c gcc.c-torture/execute/builtins/strncat-chk.c gcc.c-torture/execute/builtins/strncat.c gcc.c-torture/execute/builtins/strncpy-chk.c gcc.c-torture/execute/builtins/strncpy.c gcc.c-torture/execute/builtins/strstr-asm.c gcc.c-torture/execute/builtins/strstr.c gcc.c-torture/execute/memcpy-bi.c gcc.c-torture/execute/string-opt-18.c gcc.dg/20021029-1.c gcc.dg/builtins-10.c gcc.dg/builtins-2.c gcc.dg/builtins-21.c gcc.dg/builtins-26.c gcc.dg/builtins-47.c gcc.dg/builtins-52.c gcc.dg/builtins-7.c gcc.dg/pr16973.c gcc.dg/pr19402-1.c gcc.dg/torture/builtin-explog-1.c gcc.dg/torture/builtin-integral-1.c All with a message like: gcc-4.1-20050702/gcc/testsuite/gcc.c-torture/compile/20020701-1.c:33: internal compiler error: fold check: original tree changed by fold Michael Cieslinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20623
[Bug c/22305] Error during the make
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-07-05 10:50 --- This bug has nothing to do with GCC or the C front end in particular: the make output shown is for a build of GNU m4 (not GCC) with a compiler which is not GCC either. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID Summary|Error during the make |Error during the make http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22305
[Bug c/22308] New: Failure to diagnose violation of constraint 6.516p2
With -ansi -pedantic-errors, GCC fails to reject the following assignment.
struct foo s;
volatile struct foo t;
struct foo { const int z; };
void bar (void)
{
t = s;
}
GCC is tricked by the delayed completion of a qualified form of the type.
--
Summary: Failure to diagnose violation of constraint 6.516p2
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: neil at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22308
[Bug ada/22301] [4.1 Regression] Ada does not build into a clean prefix when unwind.h is not installed
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-07-05 12:10 --- unwind.h is a target header. It should not be included by host code (ie. the compiler). -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-07-05 12:10:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22301
[Bug libstdc++/17012] std::list's function, remove, looks like it is reading memory that has been freed.
--- Additional Comments From chris at bubblescope dot net 2005-07-05 12:11 --- It seems to me that this is just a simple NAB. There seems to be 3 options 1) Just leave it as is 2) Alter list::remove so in debug mode it aborts if you give it an element from the list 3) Alter list::remove so this code works (which in some very quick checking seems to produce about a ~15% slowdown on things like listints) The similar problem on things in algorithm I think is more cut (if you pass something by reference to an algorithm, that algorithm shouldn't change it, clearly). This could still perhaps be made clearer in the standard... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17012
[Bug ada/22301] [4.1 Regression] Ada does not build into a clean prefix when unwind.h is not installed
--- Additional Comments From charlet at gcc dot gnu dot org 2005-07-05 12:26 --- Hmm, so it means that there is no way for a compiler front-end to use GCC's exception handling mechanism ? I would guess adding a #if IN_RTS around the unwind.h include would probably solve this issue: #if IN_RTS #include unwind.h #endif Olivier, what do you think of the above ? Arno -- What|Removed |Added CC||hainque at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22301
[Bug c/22308] [3.4/4.0/4.1 Regression] Failure to diagnose violation of constraint 6.516p2
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-05 12:53 --- Confirmed, a regression from 2.95.3. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||accepts-invalid Known to fail||3.0.4 3.3.3 3.4.0 4.0.0 ||4.1.0 Known to work||2.95 Last reconfirmed|-00-00 00:00:00 |2005-07-05 12:53:10 date|| Summary|Failure to diagnose |[3.4/4.0/4.1 Regression] |violation of constraint |Failure to diagnose |6.516p2 |violation of constraint ||6.516p2 Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22308
[Bug tree-optimization/22135] The gcc-4.1-20050611 compiler ICE's using -ftree-vectorize in conjunction with -fdump-tree-all-details-stats
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-05 12:56 --- (In reply to comment #6) Sorry, I didn't understood your answer fully (stupid me :-) So is it entered in the BugZilla database, shall I enter it or shall we leave it alone? It is known meaning people have reported it to the GCC list before but that is it. A new bugzilla bug would be nice to keep track of it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22135
[Bug fortran/22306] ICE: segmentation fault
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-05 13:04 --- Confirmed, reduced testcase: module stackmod type stack_node integer :: intval=0 type(stack_node), pointer :: next end type stack_node contains subroutine push() type(stack_node), pointer :: new_node end subroutine push end module stackmod -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2005-07-05 13:04:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22306
[Bug libfortran/22307] Missing tests for actual library functions
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-05 13:13 --- Confirmed, what about using temporary variables which should solve this problem. This does not look that critical. -- What|Removed |Added Severity|critical|normal Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-07-05 13:13:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22307
[Bug libgcj/22283] Fail to build libjava under zh_TW.UTF-8 locale.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-05 13:26 --- Here is reference to the problem back in 2002: http://gcc.gnu.org/ml/gcc/2002-11/msg00896.html I thought I had saw another mail in the last year about this but I cannot find it any more. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22283
[Bug tree-optimization/19055] Minor bit optimization with or and xor
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-05 13:53 --- Patch posted here: http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00258.html. -- What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||07/msg00258.html Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19055
[Bug libstdc++/22309] New: mt allocator doesn't pthread_key_delete it's keys
With libstdc++ configured with --enable-libstdcxx-allocator=mt (on 4.0 branch
or on HEAD for linux even without it, as mt is the default there), following
testcase crashes:
cat O.c EOF
#include dlfcn.h
#include pthread.h
void *
tf (void *arg)
{
void *h = dlopen (./libO.so, RTLD_LAZY);
void (*fn) (void);
if (!h) return 0;
fn = dlsym (h, foo);
fn ();
dlclose (h);
return 0;
}
int
main (void)
{
pthread_t th;
pthread_create (th, NULL, tf, NULL);
pthread_join (th, NULL);
return 0;
}
EOF
cat libO.C EOF
#include string
extern C void
foo (void)
{
std::string s;
s += hello;
}
EOF
g++ -g -O2 -shared -fpic -o libO.so libO.C
gcc -g -O2 -o O O.c -ldl -lpthread
The problem is that __gnu_cxx::__pooltrue::_M_initialize () calls
pthread_key_create but doesn't ensure pthread_key_delete is called when
libstdc++.so is unloaded. So when glibc attempts destroys a thread or program
and calls the registered key cleanup routine (_S_destroy_thread_key), if
libstdc++.so is not mapped at that moment any longer, either whatever other
code happens to be mapped at that address is run, or the program crashes
immediately.
mt_allocator.cc should ensure that gthread_key_delete is called on the key
after all users of the key have been destroyed.
--
Summary: mt allocator doesn't pthread_key_delete it's keys
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at redhat dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22309
[Bug ada/18692] Ada should have a dg testsuite
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-05 13:55 --- Mine. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18692
[Bug ada/22301] [4.1 Regression] Ada does not build into a clean prefix when unwind.h is not installed
--- Additional Comments From hainque at adacore dot com 2005-07-05 14:08 --- Subject: Re: [4.1 Regression] Ada does not build into a clean prefix when unwind.h is not installed charlet at gcc dot gnu dot org wrote: Hmm, so it means that there is no way for a compiler front-end to use GCC's exception handling mechanism ? Humm, I guess it's even uncommon/unique-to-Ada to use exceptions in the compiler at all, isn't it ? I would guess adding a #if IN_RTS around the unwind.h include would probably solve this issue: #if IN_RTS #include unwind.h #endif Olivier, what do you think of the above ? I'm afraid conditioning the #include alone won't do, and need to check a couple of bits before commenting further. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22301
[Bug ada/22301] [4.1 Regression] Ada does not build into a clean prefix when unwind.h is not installed
--- Additional Comments From pbrook at gcc dot gnu dot org 2005-07-05 14:19 --- In that case this may be a darwin bug. IIUC gnat1 uses exceptions, and needs the host unwind.h to do so. These exceptions may be different to the exceptions on the target system. If darwin doesn't have this file it's a bug in the bootstrap compiler. Using the target version is just plain wrong (and will break horribly when cross-compiling). The other alternative is ada is very confused about host vs. target, and raise.c shouldn't be in the compiler at all. I can't tell which is the case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22301
[Bug rtl-optimization/21970] [3.4 only] Inline keyword causes computation to erroneously reduce to a constant
--- Additional Comments From para at cfl dot rr dot com 2005-07-05 14:40 --- The analysis is slightly flawed. For example: UINT32 r0045025C = opt_and(ic, r004501D4);// N = and (_, M) :00022108 UINT32 r00450994 = opt_not(r0045025C);// b = not (N) :fffddef7 Since you are using 1s to represent bits that are known to be 0 and 0s to represent bits whose value are completely unknown, b should be . All known 0s flip to 1s, and you can say nothing about the other bits because their values are all unknown. However, I ran my own analysis and came to the same conclusion. It seems that the mistake was mine as I was using and () instead of add (+) for the round key. My appologies. Interestingly, GCC 4.0 does *not* catch this optimization opportunity. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21970
[Bug fortran/18022] problem with structure and calling a function
--- Additional Comments From gruel at astro dot ufl dot edu 2005-07-05 14:51 --- the problem is still there with the actual version of gfortran. The result is totally incoherent. I don't know for the bug 15553 but this one is still present. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | Version|4.0.0 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18022
[Bug rtl-optimization/21970] [3.4 only] Inline keyword causes computation to erroneously reduce to a constant
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-07-05 14:51 --- The analysis is slightly flawed. For example: UINT32 r0045025C = opt_and(ic, r004501D4); // N = and (_, M) :00022108 UINT32 r00450994 = opt_not(r0045025C); // b = not (N) :fffddef7 Since you are using 1s to represent bits that are known to be 0 and 0s to represent bits whose value are completely unknown, b should be . All known 0s flip to 1s, and you can say nothing about the other bits because their values are all unknown. Yup. I guess you didn't read comment #4 ;) Anyway, thanks for the confirmation. I'll close this as invalid. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21970
[Bug libgcj/21058] [4.1 Regression] fragile libgcj link process omits some inner classes
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-05 15:10 --- *** Bug 22283 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||jserv at kaffe dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21058
[Bug libgcj/22283] Fail to build libjava under zh_TW.UTF-8 locale.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-05 15:10 --- This is a dup of bug 21058. The problem is not in libgcj but in libtool. We semi worked around it in 4.0.0 by sorting but that does not always work as shown here. *** This bug has been marked as a duplicate of 21058 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22283
[Bug c/22308] [3.4/4.0/4.1 Regression] Failure to diagnose violation of constraint 6.516p2
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-07-05 15:19 --- Testing a patch. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jsm28 at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-07-05 12:53:10 |2005-07-05 15:19:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22308
[Bug c++/20746] Incorrect return value for covariant return function returning null ptr
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-07-05 15:40 --- This is OK for 4.0.2, once the branch re-opens. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20746
[Bug tree-optimization/22310] New: ICE in in first_vi_for_offset
% g++ -v -O -c min4.cc Using built-in specs. Target: alphaev68-unknown-linux-gnu Configured with: ../configure --disable-nls --enable-languages=c++ Thread model: posix gcc version 4.1.0 20050705 (experimental) /usr/local/stow/gcc-2005.07.05/bin/../libexec/gcc/alphaev68-unknown-linux-gnu/4.1.0/cc1plus -quiet -v -iprefix /usr/local/stow/gcc-2005.07.05/bin/../lib/gcc/alphaev68-unknown-linux-gnu/4.1.0/ min4.cc -quiet -dumpbase min4.cc -mcpu=ev67 -auxbase min4 -O -version -o /tmp/cc8V3FBD.s ignoring nonexistent directory /usr/local/stow/gcc-2005.07.05/bin/../lib/gcc/alphaev68-unknown-linux-gnu/4.1.0/../../../../alphaev68-unknown-linux-gnu/include ignoring duplicate directory /usr/local/lib/gcc/alphaev68-unknown-linux-gnu/4.1.0/../../../../include/c++/4.1.0 ignoring duplicate directory /usr/local/lib/gcc/alphaev68-unknown-linux-gnu/4.1.0/../../../../include/c++/4.1.0/alphaev68-unknown-linux-gnu ignoring duplicate directory /usr/local/lib/gcc/alphaev68-unknown-linux-gnu/4.1.0/../../../../include/c++/4.1.0/backward ignoring nonexistent directory NONE/include ignoring duplicate directory /usr/local/lib/gcc/alphaev68-unknown-linux-gnu/4.1.0/include ignoring nonexistent directory /usr/local/lib/gcc/alphaev68-unknown-linux-gnu/4.1.0/../../../../alphaev68-unknown-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/local/stow/gcc-2005.07.05/bin/../lib/gcc/alphaev68-unknown-linux-gnu/4.1.0/../../../../include/c++/4.1.0 /usr/local/stow/gcc-2005.07.05/bin/../lib/gcc/alphaev68-unknown-linux-gnu/4.1.0/../../../../include/c++/4.1.0/alphaev68-unknown-linux-gnu /usr/local/stow/gcc-2005.07.05/bin/../lib/gcc/alphaev68-unknown-linux-gnu/4.1.0/../../../../include/c++/4.1.0/backward /usr/local/stow/gcc-2005.07.05/bin/../lib/gcc/alphaev68-unknown-linux-gnu/4.1.0/include /usr/local/include /usr/include End of search list. GNU C++ version 4.1.0 20050705 (experimental) (alphaev68-unknown-linux-gnu) compiled by GNU C version 4.1.0 20050705 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 48193d44e71dca2238e35a9b055060fc min4.cc: In member function 'const ai::defensive_position ai::best_defensive_position(const gamemap::location, const std::multimapgamemap::location, gamemap::location, std::lessgamemap::location, std::allocatorstd::pairconst gamemap::location, gamemap::location , const std::multimapgamemap::location, gamemap::location, std::lessgamemap::location, std::allocatorstd::pairconst gamemap::location, gamemap::location , const std::multimapgamemap::location, gamemap::location, std::lessgamemap::location, std::allocatorstd::pairconst gamemap::location, gamemap::location , const std::multimapgamemap::location, gamemap::location, std::lessgamemap::location, std::allocatorstd::pairconst gamemap::location, gamemap::location ) const': min4.cc:74: internal compiler error: in first_vi_for_offset, at tree-ssa-structalias.c:2565 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. I cannot reproduce this on i686-pc-linux-gnu for some reason... last changelog entry is 2005-07-05 Kazu Hirata [EMAIL PROTECTED] * Makefile.in (stamp-as): Use $(ORIGINAL_AS_FOR_TARGET) instead of $. Don't remove ./as if it already exists. so Daniel Berlin's fix for PR 22279 is already in. -- Summary: ICE in in first_vi_for_offset Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: falk at debian dot org CC: dberlin at gcc dot gnu dot org,gcc-bugs at gcc dot gnu dot org GCC build triplet: alphaev68-unknown-linux-gnu GCC host triplet: alphaev68-unknown-linux-gnu GCC target triplet: alphaev68-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22310
[Bug c/22311] New: internal compiler error: in c_common_type, at c-typeck.c:531
$ /apa/gnu/Linux-RH-7.2/gcc/gcc-4.0.0/bin/gcc -O3 -march=pentium4 -mfpmath=sse -fomit-frame-pointer -ffast-math -std=c99 -fshort-enums -Wall -Wno-unused BlockRegion.i /home/compwork/monat/Open64-1-7-0-B-Linux/CVSTop-LAO2/LAO_PRO/lao/PFA/BlockRegion.xcc: In function 'BlockRegion_findInvariants': /home/compwork/monat/Open64-1-7-0-B-Linux/CVSTop-LAO2/LAO_PRO/lao/PFA/BlockRegion.xcc:1017: internal compiler error: in c_common_type, at c-typeck.c:531 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: internal compiler error: in c_common_type, at c- typeck.c:531 Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: christophe dot monat at st dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22311
[Bug tree-optimization/22310] ICE in in first_vi_for_offset
--- Additional Comments From falk at debian dot org 2005-07-05 15:52 --- Created an attachment (id=9206) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9206action=view) test case (use -O) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22310
[Bug c/22311] internal compiler error: in c_common_type, at c-typeck.c:531
--- Additional Comments From christophe dot monat at st dot com 2005-07-05 15:52 --- Created an attachment (id=9207) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9207action=view) Preprocessed input file to reproduce bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22311
[Bug c/22311] [4.0/4.1 Regression] internal compiler error: in c_common_type (-fshort-enums)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-05
16:04 ---
Confirmed, reduced testcase:
typedef enum {
IssueItemFlag_Discard = 0x1
} IssueItemFlag;
void
BlockRegion_findInvariants(IssueItemFlag invariant, unsigned char a)
{
a |= invariant;
}
Only -fshort-enums is needed to reproduce the bug.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
GCC build triplet|i686-pc-linux-gnu |i686-pc-linux-gnu
GCC host triplet|i686-pc-linux-gnu |i686-pc-linux-gnu
GCC target triplet|i686-pc-linux-gnu |i686-pc-linux-gnu
Keywords||ice-on-valid-code
Known to fail||4.0.0 4.1.0
Known to work||3.4.0
Last reconfirmed|-00-00 00:00:00 |2005-07-05 16:04:30
date||
Summary|internal compiler error: in |[4.0/4.1 Regression]
|c_common_type, at c-|internal compiler error: in
|typeck.c:531|c_common_type (-fshort-
||enums)
Target Milestone|--- |4.0.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22311
[Bug libstdc++/22309] mt allocator doesn't pthread_key_delete it's keys
--- Additional Comments From pcarlini at suse dot de 2005-07-05 16:27 --- Jakub, is this issue related to libstdc++/19265? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22309
[Bug libstdc++/20534] Erroneous #include of cassert
--- Additional Comments From pcarlini at suse dot de 2005-07-05 16:29 --- Not a regression, completely fixed for 4.1.0. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20534
[Bug libstdc++/21193] provide better std::tr1::hash for std::string and std::wstring
--- Additional Comments From pcarlini at suse dot de 2005-07-05 16:30 --- Also investigate a better hashing of floating point values. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21193
[Bug libstdc++/22309] mt allocator doesn't pthread_key_delete it's keys
-- What|Removed |Added CC||pcarlini at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22309
[Bug libstdc++/22309] mt allocator doesn't pthread_key_delete it's keys
--- Additional Comments From jakub at redhat dot com 2005-07-05 16:48 --- Yes, that's the same thing apparently. I'm pretty sure a reproducer can be written even for libstdc++ not configured to default to the mt allocator, by including ext/mt_allocator.h etc. or however you explicitely choose a specific allocator for some template instantiation. If init_priority attribute works, it could be perhaps used to make sure the destructor of some dummy object that calls gthread_key_delete in mt_allocator.cc will be run as last destructor in libstdc++.so. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22309
[Bug libstdc++/22309] mt allocator doesn't pthread_key_delete it's keys
--- Additional Comments From pcarlini at suse dot de 2005-07-05 16:55 --- Yes, that's the same thing apparently. Thanks. And now we have also a compact testcase. I'm pretty sure a reproducer can be written even for libstdc++ not configured to default to the mt allocator, by including ext/mt_allocator.h etc. or however you explicitely choose a specific allocator for some template instantiation. Definitely. If init_priority attribute works, it could be perhaps used to make sure the destructor of some dummy object that calls gthread_key_delete in mt_allocator.cc will be run as last destructor in libstdc++.so. Thanks for the hint. ... maybe Benjamin is willing to investigate this... ;) -- What|Removed |Added CC||bkoz at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22309
[Bug debug/21828] [4.0/4.1 Regression] debug info omitted for uninitialized variables
--- Additional Comments From hjl at lucon dot org 2005-07-05 16:56 --- Patches for mainline and 4.0 are posted at http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00270.html I hope they lead to the proper fixes and this critical regression is fixed in 4.0.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21828
[Bug target/18434] [4.0/4.1 Regression] Cannot build gnattools on Tru64 UNIX V5.1B
--- Additional Comments From ro at techfak dot uni-bielefeld dot de
2005-07-05 17:04 ---
Subject: Re: [4.0/4.1 Regression] Cannot build gnattools on Tru64 UNIX V5.1B
charlet at gcc dot gnu dot org writes:
Given your last comment (a variable set to 4), it still looks very much like
a codegen issue to me, and likely target dependent.
I guess a next step could be to either look at the ssa transformations
performed,
and/or at the assembly code generated for the elab routine.
I've approached this a bit differently:
* I tried to bootstrap mainline with -O0, but it failed as before and even
an almost current CVS gdb just SEGVs on the gnatmake binary ;-(
* On the 4.0 branch, a bootstrap with -O0 also failed as before, but at
least I can debug the gnatmake binary:
osint__running_programs starts as 0, is later initialized to 2
(osint__make) in osint__set_program and again overwritten to 4
(osint__unspecified) in osint___elabb:
Breakpoint 4, osint.set_program (p=16) at
/vol/gnu/src/gcc/gcc-4.0-branch-dist/gcc/ada/osint.adb:2274
(gdb) p osint__running_program
$6 = 0
(gdb) where
#0 osint.set_program (p=16) at
/vol/gnu/src/gcc/gcc-4.0-branch-dist/gcc/ada/osint.adb:2274
#1 0x0001201fbf10 in osint__m___elabb () at
/vol/gnu/src/gcc/gcc-4.0-branch-dist/gcc/ada/osint-m.adb:49
#2 0x0001200b7750 in adainit () at b_gnatm.c:562
#3 0x0001200b8aec in main (argc=536854608, argv=0x0, envp=0x0) at
b_gnatm.c:733
#4 0x0001200b617c in __start ()
(gdb) cont
Continuing.
Watchpoint 6: {data variable, no debug info} 5369590752
Old value = 0
New value = 2
osint.set_program (p=16) at
/vol/gnu/src/gcc/gcc-4.0-branch-dist/gcc/ada/osint.adb:2280
(gdb) cont
Continuing.
Breakpoint 3, osint___elabb () at
/vol/gnu/src/gcc/gcc-4.0-branch-dist/gcc/ada/osint.adb:45
(gdb) cont
Continuing.
Watchpoint 6: {data variable, no debug info} 5369590752
Old value = 2
New value = 4
osint___elabb () at /vol/gnu/src/gcc/gcc-4.0-branch-dist/gcc/ada/osint.adb:48
(gdb) where
#0 osint___elabb () at
/vol/gnu/src/gcc/gcc-4.0-branch-dist/gcc/ada/osint.adb:48
#1 0x0001200b7cc0 in adainit () at b_gnatm.c:610
#2 0x0001200b8aec in main (argc=536854608, argv=0x0, envp=0x0) at
b_gnatm.c:733
#3 0x0001200b617c in __start ()
* On the 3.4 branch, osint__running_program is statically initialized to
osint__unspecified in osint.adb, later reset to osint__make in
osint__set_program:
Old value = {F = osint__unspecified}
New value = {F = osint__make}
osint__set_program (p=osint__make) at
/vol/gnu/src/gcc/gcc-3.4-branch-dist/gcc/ada/osint.adb:2253
Breakpoint 3, osint.set_program (p=osint__make) at
/vol/gnu/src/gcc/gcc-3.4-branch-dist/gcc/ada/osint.adb:2247
(gdb) where
#0 osint.set_program (p=osint__make) at
/vol/gnu/src/gcc/gcc-3.4-branch-dist/gcc/ada/osint.adb:2247
#1 0x00012019efe8 in osint__m___elabb () at
/vol/gnu/src/gcc/gcc-3.4-branch-dist/gcc/ada/osint-m.adb:49
#2 0x0001200a046c in adainit () at b_gnatm.c:267
#3 0x0001200a11c0 in main (argc=6, argv=0x11fffc018, envp=0x11fffc050) at
b_gnatm.c:389
#4 0x00012009fc3c in __start ()
$1 = {F = osint__unspecified}
(gdb) cont
Continuing.
Watchpoint 5: osint.running_program
Old value = {F = osint__unspecified}
New value = {F = osint__make}
osint.set_program (p=osint__make) at
/vol/gnu/src/gcc/gcc-3.4-branch-dist/gcc/ada/osint.adb:2253
Thus, the way/order of initialization changed between 3.4 and 4.0, causing
the observed failure:
* from osint.adb:
package body Osint is
Running_Program : Program_Type := Unspecified;
-- comment required here ???
* from osint-m.adb:
package body Osint.M is
[...]
begin
Set_Program (Make);
end Osint.M;
* in 3.4:
osint__running_program = osint__unspecified (4) statically (osint.o)
osint__running_program = osint__make (2) in osint.set_program, called
from osint__m___elabb (osint_m.o)
* in 4.0:
osint__running_program = 0 statically (osint.o)
osint__running_program = osint__make (2) in osint.set_program, called from
osint__m___elabb (osint_m.o)
osint__running_program = osint__unspecified (4) in osint___elabb (osint.o)
Hope this helps to narrow down the root cause.
Rainer
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18434
[Bug ada/21952] Many attribute directive ignored warnings during Tru64 UNIX Ada bootstrap
--- Additional Comments From ro at gcc dot gnu dot org 2005-07-05 17:11 --- Richard, maybe you could have a look since this seems to be caused by your patch? Thanks. Rainer -- What|Removed |Added CC||rth at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21952
Re: [Bug ada/21952] Many attribute directive ignored warnings during Tru64 UNIX Ada bootstrap
--- Additional Comments From ro at gcc dot gnu dot org 2005-07-05 17:11 --- Richard, maybe you could have a look since this seems to be caused by your patch? It is a latent bug in Ada front-end. RTH just exposed the latent bug. -- Pinski
[Bug ada/21952] Many attribute directive ignored warnings during Tru64 UNIX Ada bootstrap
--- Additional Comments From pinskia at physics dot uc dot edu 2005-07-05 17:13 --- Subject: Re: Many attribute directive ignored warnings during Tru64 UNIX Ada bootstrap --- Additional Comments From ro at gcc dot gnu dot org 2005-07-05 17:11 --- Richard, maybe you could have a look since this seems to be caused by your patch? It is a latent bug in Ada front-end. RTH just exposed the latent bug. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21952
[Bug ada/21952] Many attribute directive ignored warnings during Tru64 UNIX Ada bootstrap
--- Additional Comments From ro at techfak dot uni-bielefeld dot de 2005-07-05 17:15 --- Subject: Re: Many attribute directive ignored warnings during Tru64 UNIX Ada bootstrap pinskia at physics dot uc dot edu writes: It is a latent bug in Ada front-end. RTH just exposed the latent bug. Any hint where to fix this? Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21952
[Bug rtl-optimization/11261] Weak code generated for JPEG compression
--- Additional Comments From amylaar at gcc dot gnu dot org 2005-07-05 17:24 --- (In reply to comment #4) This bug hasn't been modified in more than 18 months. What is the current status of this bug? And is this not really a target specific issue for SH with its silly r0, or can other targets also have this problem?? The sh-elf libraries won't build because of PR 22258. Because we have sched1 enabled, the scheduling problem is currently non-existant; the values that are needed in r0 can be calculated in a different general purpose register, and moved into r0 in time for the indexed addressing. However, because of sched1 we now have too high register pressure for other benchmarks. Vlad proposed at the summit to postpone scheduling after reload to fix the register pressure issue. Unless his porposed register renaming schedme can handle this case and snarf the required registers too, we'll go back to square one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11261
[Bug c/22308] [3.4/4.0/4.1 Regression] Failure to diagnose violation of constraint 6.516p2
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-05 17:34 --- Subject: Bug 22308 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-07-05 17:34:29 Modified files: gcc: ChangeLog c-decl.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: pr22308-1.c Log message: PR c/22308 * c-decl.c (finish_struct): Also copy C_TYPE_FIELDS_READONLY, C_TYPE_FIELDS_VOLATILE and C_TYPE_VARIABLE_SIZE to type variants. testsuite: * gcc.dg/pr22308-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9344r2=2.9345 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-decl.c.diff?cvsroot=gccr1=1.673r2=1.674 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5724r2=1.5725 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr22308-1.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22308
[Bug tree-optimization/22310] [4.1 Regression] ICE in in first_vi_for_offset
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-05 17:35 --- This is 64bit targets only. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org GCC build triplet|alphaev68-unknown-linux-gnu | GCC host triplet|alphaev68-unknown-linux-gnu | Summary|ICE in in |[4.1 Regression] ICE in in |first_vi_for_offset |first_vi_for_offset Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22310
Re: [Bug ada/22301] [4.1 Regression] Ada does not build into a clean prefix when unwind.h is not installed
On Jul 5, 2005, at 10:19 AM, pbrook at gcc dot gnu dot org wrote: The other alternative is ada is very confused about host vs. target, and raise.c shouldn't be in the compiler at all. Ada is very confused it looks like as raise.c is both a host and target file which seems to me wrong. -- Pinski
[Bug ada/22301] [4.1 Regression] Ada does not build into a clean prefix when unwind.h is not installed
--- Additional Comments From pinskia at physics dot uc dot edu 2005-07-05 17:37 --- Subject: Re: [4.1 Regression] Ada does not build into a clean prefix when unwind.h is not installed On Jul 5, 2005, at 10:19 AM, pbrook at gcc dot gnu dot org wrote: The other alternative is ada is very confused about host vs. target, and raise.c shouldn't be in the compiler at all. Ada is very confused it looks like as raise.c is both a host and target file which seems to me wrong. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22301
[Bug c/22013] [4.0/4.1 Regression] ICE in gimple_add_tmp_var, at gimplify.c:535
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-05 17:50 --- Subject: Bug 22013 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-07-05 17:50:24 Modified files: gcc: ChangeLog c-objc-common.h c-tree.h c-typeck.c langhooks-def.h langhooks.c langhooks.h tree.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/compile: pr22013-1.c gcc/testsuite/gcc.c-torture/execute: pr22098-1.c pr22098-2.c pr22098-3.c Log message: PR c/22013 PR c/22098 * langhooks.h (struct lang_hooks): Add expr_to_decl. * langhooks.c (lhd_expr_to_decl): New. * langhooks-def.h (lhd_expr_to_decl, LANG_HOOKS_EXPR_TO_DECL): New. (LANG_HOOKS_INITIALIZER): Update. * tree.c (recompute_tree_invarant_for_addr_expr): Call expr_to_decl langhook. * c-tree.h (c_expr_to_decl): Declare. * c-typeck.c (c_expr_to_decl): New. (build_unary_op): Do not handle ADDR_EXPR of COMPOUND_LITERAL_EXPR specially. * c-objc-common.h (LANG_HOOKS_EXPR_TO_DECL): Define. testsuite: * gcc.c-torture/compile/pr22013-1.c, gcc.c-torture/execute/pr22098-1.c, gcc.c-torture/execute/pr22098-2.c, gcc.c-torture/execute/pr22098-3.c: New tests. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9345r2=2.9346 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-objc-common.h.diff?cvsroot=gccr1=2.7r2=2.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-tree.h.diff?cvsroot=gccr1=1.207r2=1.208 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-typeck.c.diff?cvsroot=gccr1=1.463r2=1.464 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/langhooks-def.h.diff?cvsroot=gccr1=1.99r2=1.100 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/langhooks.c.diff?cvsroot=gccr1=1.83r2=1.84 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/langhooks.h.diff?cvsroot=gccr1=1.107r2=1.108 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree.c.diff?cvsroot=gccr1=1.493r2=1.494 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5725r2=1.5726 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/pr22013-1.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/pr22098-1.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/pr22098-2.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/pr22098-3.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22013
[Bug c/22098] [4.0/4.1 Regression] ICE in compound literal gimplification
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-05 17:50 --- Subject: Bug 22098 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-07-05 17:50:24 Modified files: gcc: ChangeLog c-objc-common.h c-tree.h c-typeck.c langhooks-def.h langhooks.c langhooks.h tree.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/compile: pr22013-1.c gcc/testsuite/gcc.c-torture/execute: pr22098-1.c pr22098-2.c pr22098-3.c Log message: PR c/22013 PR c/22098 * langhooks.h (struct lang_hooks): Add expr_to_decl. * langhooks.c (lhd_expr_to_decl): New. * langhooks-def.h (lhd_expr_to_decl, LANG_HOOKS_EXPR_TO_DECL): New. (LANG_HOOKS_INITIALIZER): Update. * tree.c (recompute_tree_invarant_for_addr_expr): Call expr_to_decl langhook. * c-tree.h (c_expr_to_decl): Declare. * c-typeck.c (c_expr_to_decl): New. (build_unary_op): Do not handle ADDR_EXPR of COMPOUND_LITERAL_EXPR specially. * c-objc-common.h (LANG_HOOKS_EXPR_TO_DECL): Define. testsuite: * gcc.c-torture/compile/pr22013-1.c, gcc.c-torture/execute/pr22098-1.c, gcc.c-torture/execute/pr22098-2.c, gcc.c-torture/execute/pr22098-3.c: New tests. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9345r2=2.9346 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-objc-common.h.diff?cvsroot=gccr1=2.7r2=2.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-tree.h.diff?cvsroot=gccr1=1.207r2=1.208 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-typeck.c.diff?cvsroot=gccr1=1.463r2=1.464 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/langhooks-def.h.diff?cvsroot=gccr1=1.99r2=1.100 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/langhooks.c.diff?cvsroot=gccr1=1.83r2=1.84 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/langhooks.h.diff?cvsroot=gccr1=1.107r2=1.108 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree.c.diff?cvsroot=gccr1=1.493r2=1.494 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5725r2=1.5726 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/pr22013-1.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/pr22098-1.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/pr22098-2.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/pr22098-3.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22098
[Bug tree-optimization/22310] [4.1 Regression] ICE in in first_vi_for_offset
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-05
18:06 ---
Confirmed, reduced as far as I can get it:
struct location
{
int x, y;
};
struct defensive_position
{
int chance_to_hit;
long long vulnerability, support;
};
templateclass _T1, class _T2 struct pair
{
_T1 first;
_T2 second;
pair();
templateclass _U1, class _U2 pair(const pair_U1, _U2 __p)
: first(__p.first), second(__p.second){}
};
struct map
{
typedef pairconst location, defensive_position value_type;
void insert(const value_type );
};
map defensive_position_cache_;
void best_defensive_position()
{
defensive_position_cache_.insert(pair location,defensive_position());
}
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-07-05 18:06:33
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22310
[Bug tree-optimization/22310] [4.1 Regression] ICE in in first_vi_for_offset
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-05 18:10 --- (In reply to comment #3) Confirmed, reduced as far as I can get it: One more thing, this testcase also fails on 32bit ppc-darwin and 64bit ppc-darwin. -- What|Removed |Added GCC target triplet|alphaev68-unknown-linux-gnu |alphaev68-linux-gnu, ||powerpc-darwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22310
[Bug tree-optimization/22312] New: reassoc does not handle (i+j)+(k+l) well
take the following example:
int f(int i, int j, int k, int l)
{
int r1 = (i+j)+(k+l);
int r2 = (j+k)+(l+i);
return r1 == r2;
}
This should return 1 all the time. I found this while making testcases for
reassoc working fp (well I just
change one little thing to make it work really).
--
Summary: reassoc does not handle (i+j)+(k+l) well
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22312
[Bug bootstrap/22313] New: gcc HEAD as of 2005/07/05 fails to profiledbootstrap
SSIA. Building with gcc 3.4.4, binutils 2.16.1 (tried 2.16.91.0.1 too, same behavior) results in stage1/xgcc -Bstage1/ -B/usr/i586-ark-linux/bin/ -c -g -O2 -fprofile-use -freorder-blocks-and-partition -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Werror -fno-common -DHAVE_CONFIG_H-I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include ../../gcc/attribs.c -o attribs.o /tmp/ccHE8Qe5.s: Assembler messages: /tmp/ccHE8Qe5.s:1539: Error: invalid sections for operation on `.LCFI11' and `.LCFI10' make[2]: *** [attribs.o] Error 1 -- Summary: gcc HEAD as of 2005/07/05 fails to profiledbootstrap Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bero at arklinux dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-ark-linux-gnu GCC host triplet: i686-ark-linux-gnu GCC target triplet: i686-ark-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22313
[Bug bootstrap/22313] gcc HEAD as of 2005/07/05 fails to profiledbootstrap
--- Additional Comments From bero at arklinux dot org 2005-07-05 18:37 --- Created an attachment (id=9208) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9208action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22313
[Bug bootstrap/22313] gcc HEAD as of 2005/07/05 fails to profiledbootstrap
--- Additional Comments From bero at arklinux dot org 2005-07-05 18:39 --- Created an attachment (id=9209) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9209action=view) Generated asm code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22313
[Bug tree-optimization/22312] reassoc does not handle (i+j)+(k+l) well
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-07-05
19:02 ---
Subject: Re: New: reassoc does not handle
(i+j)+(k+l) well
On Tue, 2005-07-05 at 18:33 +, pinskia at gcc dot gnu dot org wrote:
take the following example:
int f(int i, int j, int k, int l)
{
int r1 = (i+j)+(k+l);
int r2 = (j+k)+(l+i);
return r1 == r2;
}
This should return 1 all the time. I found this while making testcases for
reassoc working fp (well I just
change one little thing to make it work really).
We can't do a full top-down reassocation because update_stmt reorders
our operands so we lose information about which is the high ranked
operand, etc.
It's a pain in the ass to fix, but possible.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22312
[Bug bootstrap/22313] [4.1 Regression] gcc HEAD as of 2005/07/05 fails to profiledbootstrap
-- What|Removed |Added Keywords||wrong-code Summary|gcc HEAD as of 2005/07/05 |[4.1 Regression] gcc HEAD as |fails to profiledbootstrap |of 2005/07/05 fails to ||profiledbootstrap Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22313
[Bug tree-optimization/22312] reassoc does not handle (i+j)+(k+l) well
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-05 19:35 --- Confirmed then. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-07-05 19:35:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22312
[Bug tree-optimization/18589] could optimize FP multiplies better
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-05 19:37 --- I think PR 22312 mentions what the current problem with reassoc is (well once I submit the patch to introduce reassociation for fp). -- What|Removed |Added BugsThisDependsOn||22312 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18589
[Bug c/22098] [4.0 Regression] ICE in compound literal gimplification
-- What|Removed |Added Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22098
[Bug c/22013] [4.0 Regression] ICE in gimple_add_tmp_var, at gimplify.c:535
-- What|Removed |Added Summary|[4.0/4.1 Regression] ICE in |[4.0 Regression] ICE in |gimple_add_tmp_var, at |gimple_add_tmp_var, at |gimplify.c:535 |gimplify.c:535 Target Milestone|4.0.1 |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22013
[Bug bootstrap/22314] New: ICE in make profiledbootstrap: corrupted profile info for gcc/dominance.c
Tried to build the gentoo ebuild for gcc head pulled from CVS on 20050702. Got this error: stage1/xgcc -Bstage1/ -B/usr/i686-pc-linux-gnu/bin/ -c -save-temps -march=athlon-xp -O2 -pipe -fprofile-use -freorder-blocks-and-partitio n -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -DHAVE_CONFIG_H-I. -I. -I/var/tmp/portage/gcc-4.1.0_beta20050702/work/gcc-4.1-20050702/gcc -I/var/tmp/portage/gcc-4.1.0_beta20050702/work/gcc-4.1-20050702/gcc/. -I/var/tmp/portage/gcc-4.1.0_beta20050702/work/gcc-4.1-20050702/gcc/../include -I/var/tmp/portage/gcc-4.1.0_beta20050702/work/gcc-4.1-20050702/gcc/../libcpp/include /var/tmp/portage/gcc-4.1.0_beta20050702/work/gcc-4.1-20050702/gcc/dominance.c -o dominance.o xgcc: warning: -pipe ignored because -save-temps specified /var/tmp/portage/gcc-4.1.0_beta20050702/work/gcc-4.1-20050702/gcc/dominance.c: In function 'calculate_dominance_info': /var/tmp/portage/gcc-4.1.0_beta20050702/work/gcc-4.1-20050702/gcc/dominance.c:649: error: corrupted profile info: number of executions for edge 40-98 thought to be -9801 /var/tmp/portage/gcc-4.1.0_beta20050702/work/gcc-4.1-20050702/gcc/dominance.c:649: error: corrupted profile info: number of executions for edge 40-41 thought to be 14798 /var/tmp/portage/gcc-4.1.0_beta20050702/work/gcc-4.1-20050702/gcc/dominance.c:649: error: corrupted profile info: number of iterations for basic block 98 thought to be -4804 /var/tmp/portage/gcc-4.1.0_beta20050702/work/gcc-4.1-20050702/gcc/dominance.c:649: error: corrupted profile info: number of executions for edge 98-103 thought to be -9801 /var/tmp/portage/gcc-4.1.0_beta20050702/work/gcc-4.1-20050702/gcc/dominance.c:649: error: corrupted profile info: number of executions for edge 98-99 thought to be 4997 /var/tmp/portage/gcc-4.1.0_beta20050702/work/gcc-4.1-20050702/gcc/dominance.c:649: error: corrupted profile info: number of iterations for basic block 103 thought to be -4804 /var/tmp/portage/gcc-4.1.0_beta20050702/work/gcc-4.1-20050702/gcc/dominance.c:649: error: corrupted profile info: number of executions for edge 103-110 thought to be -9801 /var/tmp/portage/gcc-4.1.0_beta20050702/work/gcc-4.1-20050702/gcc/dominance.c:649: error: corrupted profile info: number of executions for edge 103-104 thought to be 4997 /var/tmp/portage/gcc-4.1.0_beta20050702/work/gcc-4.1-20050702/gcc/dominance.c:649: error: corrupted profile info: number of iterations for basic block 110 thought to be -4804 make[2]: *** [dominance.o] Error 1 make[2]: Leaving directory `/var/tmp/portage/gcc-4.1.0_beta20050702/work/build/gcc' make[1]: *** [stagefeedback_build] Error 2 make[1]: Leaving directory `/var/tmp/portage/gcc-4.1.0_beta20050702/work/build/gcc' make: *** [profiledbootstrap] Error 2 # gcc/stage1/xgcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /var/tmp/portage/gcc-4.1.0_beta20050702/work/gcc-4.1-20050702/configure --enable-version-specific-runtime-libs --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.1.0-beta20050702 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.1.0-beta20050702/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.0-beta20050702 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.0-beta20050702/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.1.0-beta20050702/info
[Bug bootstrap/22314] ICE in make profiledbootstrap: corrupted profile info for gcc/dominance.c
--- Additional Comments From greenrd at greenrd dot org 2005-07-05 19:54 --- Created an attachment (id=9210) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9210action=view) gzipped testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22314
[Bug bootstrap/22314] [4.1 regression] ICE in make profiledbootstrap: corrupted profile info for gcc/dominance.c
-- What|Removed |Added Severity|critical|normal Keywords||build, ice-on-valid-code Summary|ICE in make |[4.1 regression] ICE in make |profiledbootstrap: corrupted|profiledbootstrap: corrupted |profile info for|profile info for |gcc/dominance.c |gcc/dominance.c Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22314
[Bug middle-end/22315] New: [4.1 regression] ICE in IVopts
The following code ICEs at -O2 on amd64. It was reduced from galgel, which is broken at the moment because of this bug. SUBROUTINE FOO (N, A, LDA, X, INCX) INTEGER :: INCX, LDA, N REAL*8 :: A(LDA,*), X(*) REAL*8 :: TEMP INTEGER :: I, J, IX, JX, KX IF (INCX == 1) THEN CONTINUE ELSE JX = KX + (N - 1)*INCX DO 20, J = N, 1, -1 TEMP = X(JX) IX = JX DO 10, I = J - 1, 1, -1 IX = IX - INCX TEMP = TEMP + A(I,J)*X(IX) 10 CONTINUE X(JX) = TEMP JX= JX - INCX 20 CONTINUE END IF RETURN END -- Summary: [4.1 regression] ICE in IVopts Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: steven at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22315
[Bug middle-end/22315] [4.1 regression] ICE in IVopts
--- Additional Comments From steven at gcc dot gnu dot org 2005-07-05 20:10 --- Zdenek, this is ICE in IVopts. Can you give it a look? It'd be nice if we can get galgel to compile again. -- What|Removed |Added CC||rakdver at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22315
[Bug middle-end/22315] [4.1 regression] ICE in IVopts
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-05 20:14 --- I want to say this is a dup of bug 21963 which has a patch. -- What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22315
[Bug middle-end/22315] [4.1 regression] ICE in IVopts
--- Additional Comments From steven at gcc dot gnu dot org 2005-07-05 20:25 --- Yes it is a dup, the backtraces are identical. *** This bug has been marked as a duplicate of 21963 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22315
[Bug tree-optimization/21963] [4.1 Regression] ICE (seg fault) with -m64 (in IV-OPTS)
--- Additional Comments From steven at gcc dot gnu dot org 2005-07-05 20:25 --- *** Bug 22315 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||steven at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21963
[Bug objc/22316] New: 4.0.1 ObjC regression compared to 4.0.0
FAIL: objc.dg/selector-2.m (test for excess errors) fails now, which did not fail for 4.0.0 see: http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00797.html and: http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00264.html regards, Lars -- Summary: 4.0.1 ObjC regression compared to 4.0.0 Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: objc AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lars dot sonchocky-helldorf at hamburg dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-apple-darwin7.2.1 GCC host triplet: i686-apple-darwin7.2.1 GCC target triplet: i686-apple-darwin7.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22316
[Bug objc/22316] 4.0.1 ObjC regression compared to 4.0.0
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-05 20:38 --- What is the excess errors? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22316
[Bug libstdc++/22317] New: 4.0.1 libstdc++ regression compared to 4.0.0
FAIL: 26_numerics/cmath/c99_classification_macros_c.cc (test for excess errors) fails now, which did not fail for 4.0.0 see: http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00797.html and: http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00264.html regards, Lars -- Summary: 4.0.1 libstdc++ regression compared to 4.0.0 Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lars dot sonchocky-helldorf at hamburg dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-apple-darwin7.2.1 GCC host triplet: i686-apple-darwin7.2.1 GCC target triplet: i686-apple-darwin7.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22317
[Bug target/22317] c99_classification_macros_c.cc fails on darwin
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-05 20:42 --- This is a problem with darwin's headers really and not really a regression. libstdc++'s testsuite was not running it correctly before for some reason. -- What|Removed |Added Severity|normal |minor Status|UNCONFIRMED |NEW Component|libstdc++ |target Ever Confirmed||1 GCC build triplet|i686-apple-darwin7.2.1 | GCC host triplet|i686-apple-darwin7.2.1 | GCC target triplet|i686-apple-darwin7.2.1 |*-darwin* Last reconfirmed|-00-00 00:00:00 |2005-07-05 20:42:48 date|| Summary|4.0.1 libstdc++ regression |c99_classification_macros_c. |compared to 4.0.0 |cc fails on darwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22317
[Bug objc/22316] 4.0.1 ObjC regression compared to 4.0.0
--- Additional Comments From lars dot sonchocky-helldorf at hamburg dot de 2005-07-05 20:46 --- Executing on host: /Volumes/Data/Users/lars/GCC/FSF/gcc-4.0.1-20050702-build/gcc/xgcc -B/ Volumes/Data/Users/lars/GCC/FSF/gcc-4.0.1-20050702-build/gcc/ /Users/lars/GCC/FSF/gcc-4.0.1- 20050702/gcc/testsuite/objc.dg/selector-2.m -Wselector -fgnu-runtime -S -o selector-2.s (timeout = 300) /Users/lars/GCC/FSF/gcc-4.0.1-20050702/gcc/testsuite/objc.dg/selector-2.m: In function '-[Foo foo]': /Users/lars/GCC/FSF/gcc-4.0.1-20050702/gcc/testsuite/objc.dg/selector-2.m:13: warning: assignment discards qualifiers from pointer target type /Users/lars/GCC/FSF/gcc-4.0.1-20050702/gcc/testsuite/objc.dg/selector-2.m: At top level: /Users/lars/GCC/FSF/gcc-4.0.1-20050702/gcc/testsuite/objc.dg/selector-2.m:15: warning: creating selector for nonexistent method 'b1ar' output is: /Users/lars/GCC/FSF/gcc-4.0.1-20050702/gcc/testsuite/objc.dg/selector-2.m: In function '-[Foo foo]': /Users/lars/GCC/FSF/gcc-4.0.1-20050702/gcc/testsuite/objc.dg/selector-2.m:13: warning: assignment discards qualifiers from pointer target type /Users/lars/GCC/FSF/gcc-4.0.1-20050702/gcc/testsuite/objc.dg/selector-2.m: At top level: /Users/lars/GCC/FSF/gcc-4.0.1-20050702/gcc/testsuite/objc.dg/selector-2.m:15: warning: creating selector for nonexistent method 'b1ar' PASS: objc.dg/selector-2.m (test for warnings, line 15) FAIL: objc.dg/selector-2.m (test for excess errors) Excess errors: /Users/lars/GCC/FSF/gcc-4.0.1-20050702/gcc/testsuite/objc.dg/selector-2.m:13: warning: assignment discards qualifiers from pointer target type -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22316
[Bug testsuite/22316] 4.0.1 ObjC regression compared to 4.0.0
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-05 20:48 --- Not really a regression. This test was broken for 4.0.0 also. This was fixed already for 4.1.0. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|objc|testsuite Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22316
[Bug target/22317] c99_classification_macros_c.cc fails on darwin
--- Additional Comments From pcarlini at suse dot de 2005-07-05 20:54 --- Also, this test should be really xfailed everywhere and only passes by chance on some systems due to complex interactions with PCHs: given the current structure of the library the test cannot meaningfully pass. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22317
[Bug java/19674] Empty declaration through semicolon (;) causes compile failure
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-05 21:10 --- Subject: Bug 19674 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-07-05 21:09:58 Modified files: gcc/java : ChangeLog parse.y libjava: ChangeLog Added files: libjava/testsuite/libjava.compile: PR19674.java Log message: 2005-07-05 Bryce McKinlay [EMAIL PROTECTED] PR java/19674 * parse.y (interface_member_declaration): Allow empty statements in interface declarations. 2005-07-05 Bryce McKinlay [EMAIL PROTECTED] * testsuite/libjava.compile/PR19674.java: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gccr1=1.1640r2=1.1641 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/parse.y.diff?cvsroot=gccr1=1.545r2=1.546 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gccr1=1.3690r2=1.3691 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/testsuite/libjava.compile/PR19674.java.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19674
[Bug c/22308] [3.4/4.0 Regression] Failure to diagnose violation of constraint 6.516p2
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-05 21:19 --- Subject: Bug 22308 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-07-05 21:19:17 Modified files: gcc: ChangeLog c-decl.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: pr22308-1.c Log message: PR c/22308 * c-decl.c (finish_struct): Also copy C_TYPE_FIELDS_READONLY, C_TYPE_FIELDS_VOLATILE and C_TYPE_VARIABLE_SIZE to type variants. testsuite: * gcc.dg/pr22308-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=2.2326.2.878r2=2.2326.2.879 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-decl.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.470.4.19r2=1.470.4.20 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3389.2.405r2=1.3389.2.406 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr22308-1.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=NONEr2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22308
[Bug ada/22301] [4.1 Regression] Ada does not build into a clean prefix when unwind.h is not installed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-05 22:30 --- (In reply to comment #8) Subject: Re: [4.1 Regression] Ada does not build into a clean prefix when unwind.h is not installed I will try this patch later tonight after testing PR 18692. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22301
[Bug tree-optimization/21407] [4.1 Regression] wrong code with downcast in C++
--- Additional Comments From dnovillo at gcc dot gnu dot org 2005-07-05 23:07 --- (In reply to comment #13) Fixed Have the URL for the aliasing discussion? Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21407
[Bug tree-optimization/21963] [4.1 Regression] ICE (seg fault) with -m64 (in IV-OPTS)
--- Additional Comments From giovannibajo at libero dot it 2005-07-05 23:16 --- Zdenek, is the patch still valid? If so, maybe it's time to ping it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21963
[Bug tree-optimization/21963] [4.1 Regression] ICE (seg fault) with -m64 (in IV-OPTS)
--- Additional Comments From giovannibajo at libero dot it 2005-07-05 23:17 --- Approved here already: http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00293.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21963
[Bug tree-optimization/21407] [4.1 Regression] wrong code with downcast in C++
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-07-06 00:16 --- It's in the ml archives, i'll try to find it. Basically, Mark and friends believe that in C, it's legal to add or subtract some bytes from a pointer to a field of a structure and have a valid pointer to some other field of that structure. This idiom is apparently in common usage regardless. Nathan queried the C++ committee, and they actually *don't* think it's legal in C++, but we have no way of differentiating this from dynamic_cast at the moment, so we have to be conservative. Thus, a pointer to a field passed to a function must be considered to clobber the entire structure that field is contained in (all the way up the structure chain). IE if a pointer to a structure field escapes, the entire structure instance escapes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21407
Re: [Bug tree-optimization/21407] [4.1 Regression] wrong code with downcast in C++
On Wed, Jul 06, 2005 at 12:16:20AM -, dberlin at gcc dot gnu dot org wrote: --- Additional Comments From dberlin at gcc dot gnu dot org 2005-07-06 00:16 --- It's in the ml archives, i'll try to find it. Thanks. I remember the discussion, but I need some URL so that we can reference it from the source code. The comment in tree-ssa-operands.c:note_addressable references this PR, but there's no link from the PR into the discussion. Diego.
[Bug tree-optimization/21407] [4.1 Regression] wrong code with downcast in C++
--- Additional Comments From dnovillo at redhat dot com 2005-07-06 00:23 --- Subject: Re: [4.1 Regression] wrong code with downcast in C++ On Wed, Jul 06, 2005 at 12:16:20AM -, dberlin at gcc dot gnu dot org wrote: --- Additional Comments From dberlin at gcc dot gnu dot org 2005-07-06 00:16 --- It's in the ml archives, i'll try to find it. Thanks. I remember the discussion, but I need some URL so that we can reference it from the source code. The comment in tree-ssa-operands.c:note_addressable references this PR, but there's no link from the PR into the discussion. Diego. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21407
[Bug tree-optimization/21407] [4.1 Regression] wrong code with downcast in C++
--- Additional Comments From gdr at integrable-solutions dot net 2005-07-06 00:42 --- Subject: Re: [4.1 Regression] wrong code with downcast in C++ dberlin at gcc dot gnu dot org [EMAIL PROTECTED] writes: | Nathan queried the C++ committee, and they actually *don't* think | it's legal in C++, It is more accurate to say that Nathan queried the BSI panel (UK) which is very different from the C++ committee (ISO/IEC WG21). I, for one, have not seen any query posted to the C++ core reflector nor any discussion on that topic. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21407
[Bug tree-optimization/21407] [4.1 Regression] wrong code with downcast in C++
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-07-06 00:58 --- Subject: Re: [4.1 Regression] wrong code with downcast in C++ | Nathan queried the C++ committee, and they actually *don't* think | it's legal in C++, It is more accurate to say that Nathan queried the BSI panel (UK) which is very different from the C++ committee (ISO/IEC WG21). I, for one, have not seen any query posted to the C++ core reflector nor any discussion on that topic. Well, whatever. It's not relevant anyway, since i'm sure people would scream and yell if we disallowed it in C++, regardless of what any panel/committee thinks :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21407
[Bug tree-optimization/21407] [4.1 Regression] wrong code with downcast in C++
--- Additional Comments From gdr at integrable-solutions dot net 2005-07-06 01:16 --- Subject: Re: [4.1 Regression] wrong code with downcast in C++ dberlin at dberlin dot org [EMAIL PROTECTED] writes: | Subject: Re: [4.1 Regression] wrong code with | downcast in C++ | | | | Nathan queried the C++ committee, and they actually *don't* think | | it's legal in C++, | | It is more accurate to say that Nathan queried the BSI panel (UK) | which is very different from the C++ committee (ISO/IEC WG21). | I, for one, have not seen any query posted to the C++ core reflector | nor any discussion on that topic. | | | Well, whatever. It's not relevant anyway, since i'm sure people would | scream and yell if we disallowed it in C++, regardless of what any | panel/committee thinks :) We are in violent agreement. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21407
[Bug debug/22318] New: debug info wrong for doubles followed by bools
This is a problem in gcc's default debug format. It works fine with -gstabs.
struct X
{
bool x;
double d;
};
int main()
{
X x;
x.d = 42.0;
}
When debugging with gdb, x.d will contain something wrong, (often something
like 5.301466631257326e-315). If you change the bool to another type or
remove that variable completely, the results are correct. If you move the bool
to the end of the structure, the results are also correct.
This bug does not affect the execution of the program.
I guess it's something to do with how gcc writes debug info for the size of a
bool in the structure, possibly related to packing.
I'm also able to reproduce this on gcc 3.3.4.
--
Summary: debug info wrong for doubles followed by bools
Product: gcc
Version: 3.3.6
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: charles at kde dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: gcc version 3.3.6 (Debian 1:3.3.6-7)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22318
