[Bug libstdc++/18277] [4.0 Regression] libsupc++/guard.cc:62: error: 'RECURSIVE_ERRORCHECKMUTEX' was not declared in this scope
-- What|Removed |Added CC||gerald at pfeifer dot com Severity|normal |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18277
[Bug fortran/17202] ice-on-valid-code, trans-array.c:217: gfc_conv_descriptor_dtype Assertion failed
--- Additional Comments From c dot lemmen at fz-juelich dot de 2004-11-04 09:08 --- Still persists, occurs at line 216 now gcc-Version 4.0.0 20041104 (experimental) GNU F95 version 4.0.0 20041104 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.0.0 20041028 (experimental). testcase_nrtype.f90:16: interner Compiler-Fehler: in gfc_conv_descriptor_dtype, bei fortran/trans-array.c:216 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17202
[Bug tree-optimization/18181] vectorizer: problem in the peeling mechanism in the presence of loop invariants that are used after the loop
--- Additional Comments From dorit at il dot ibm dot com 2004-11-04 09:17 --- Created an attachment (id=7471) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7471&action=view) testcase Here's a testcase that fails on execution with current mainline snapshot (no need for any pending patches to get this loop vectorized, and fail). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18181
[Bug tree-optimization/17647] [4.0 regression] Missing i386 addressing modes
--- Additional Comments From uros at kss-loka dot si 2004-11-04 09:33 --- ASM code, produced with CVS gcc dated 04. Nov 2004 looks much better, but still not as good as 3.2: LU_copy_matrix: pushl %ebp pushl %edi pushl %esi pushl %ebx movl24(%esp), %ebp movl20(%esp), %eax testl %eax, %eax jle .L8 movl32(%esp), %esi xorl%edi, %edi .L4: testl %ebp, %ebp jle .L6 movl28(%esp), %eax movl(%eax,%edi,4), %ebx movl(%esi), %ecx <= (*1) xorl%edx, %edx .L5: leal0(,%edx,8), %eax |<= (*2) fldl(%ecx,%eax) | fstpl (%ebx,%eax) | addl$1, %edx cmpl%edx, %ebp jg .L5 .L6: addl$1, %edi addl$4, %esi <= (*1) cmpl%edi, 20(%esp) jg .L4 .L8: popl%ebx popl%esi popl%edi popl%ebp ret (*1): "movl(%esi,%edi,4), %ecx" could be used here. The second addl in .L4 could be eliminated in this case. (*2): Why not use: fldl(%ecx,%edx,8) fstpl (%ebx,%edx,8) directly. lea instruction would be eliminated, together with the use of %eax register. Uros. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17647
[Bug other/18277] [4.0 Regression] libsupc++/guard.cc:62: error: 'RECURSIVE_ERRORCHECKMUTEX' was not declared in this scope
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-04 10:46 --- Subject: Bug 18277 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-04 10:46:06 Modified files: gcc: ChangeLog gthr-posix.h Log message: PR other/18277 * gthr-posix.h (__gthread_recursive_mutex_init_function): Revert 2004-10-29 patch Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6162&r2=2.6163 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gthr-posix.h.diff?cvsroot=gcc&r1=1.34&r2=1.35 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18277
[Bug other/18277] [4.0 Regression] libsupc++/guard.cc:62: error: 'RECURSIVE_ERRORCHECKMUTEX' was not declared in this scope
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-11-04 10:47 --- I've reverted my patch. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18277
[Bug c++/18055] seems not possible to specialize a template member function
-- What|Removed |Added Severity|normal |critical Status|WAITING |NEW Priority|P2 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18055
[Bug java/10581] ICE compiling freenet
--- Additional Comments From ruben at ugr dot es 2004-11-04 11:47 ---
(In reply to comment #5)
> Somebody will have to check with mainline and newer 3.4 then
Tested with freenet-stable-latest.src.25.Oct.2004.tar.bz2
and gcc version 3.4.2 (Gentoo Linux 3.4.2-r2, ssp-3.4.1-1, pie-8.7.6.5)
make -f Makefile.gcj freenet/client/RequestManager.o
Works
Other files fail, though
I'd close this bug report and add a new one, but I think I already opened
one on ThrottledAsyncEntropyYarrow.java
Compiling: freenet/node/Main.java
./freenet/crypt/ThrottledAsyncEntropyYarrow.java:49: error: '(' expected.
ThrottledAsyncEntropyYarrow.super.acceptEntropy(e.source, e.data, e.entropyGuess);
^
1 error
make: *** [freenet/node/Main.o] Error 1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10581
[Bug java/10581] ICE compiling freenet
--- Additional Comments From ruben at ugr dot es 2004-11-04 11:55 ---
(In reply to comment #6)
> (In reply to comment #5)
> > Somebody will have to check with mainline and newer 3.4 then
> Tested with freenet-stable-latest.src.25.Oct.2004.tar.bz2
> and gcc version 3.4.2 (Gentoo Linux 3.4.2-r2, ssp-3.4.1-1, pie-8.7.6.5)
> make -f Makefile.gcj freenet/client/RequestManager.o
> Works
>
> Other files fail, though
> I'd close this bug report and add a new one, but I think I already opened
> one on ThrottledAsyncEntropyYarrow.java
>
> Compiling: freenet/node/Main.java
> ./freenet/crypt/ThrottledAsyncEntropyYarrow.java:49: error: '(' expected.
>
> ThrottledAsyncEntropyYarrow.super.acceptEntropy(e.source, e.data, e.entropyGuess);
> ^
> 1 error
> make: *** [freenet/node/Main.o] Error 1
I just copied the two files from the old version over the new files and
recompiled, and got the same problem in ThrottledAsyncEntropyYarrow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10581
[Bug java/17747] bogus duplicate class errors
--- Additional Comments From ruben at ugr dot es 2004-11-04 11:58 ---
(In reply to comment #0)
> There seem to be some problems with inner classes.
>
> This is from the freenet project
> http://freenetproject.org/snapshots/freenet-stable-latest.src.tar.bz2
> untar;
> cd source/src/
> gcj freenet/diagnostics/CountingProcess.java
> javac freenet/diagnostics/CountingProcess.java
>
> Sorry, no small testcase yet.
>
> gcj freenet/diagnostics/CountingProcess.java
> ./freenet/diagnostics/Continuous.java:29: error: Class
> `freenet.diagnostics.Continuous$ContinuousEventCallback' already defined in
> freenet/diagnostics/Continuous$ContinuousEventCallback.java:0.
> public static abstract class ContinuousEventCallback implements
> RandomVar.EventCallback {
> ^
> 1 error
>
> javac freenet/diagnostics/CountingProcess.java
> #no error
Works as of gcc 3.4.2 and freenet-stable-latest.src.25.Oct.2004.tar.bz2
Please close
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17747
[Bug java/17747] bogus duplicate class errors
--- Additional Comments From ruben at ugr dot es 2004-11-04 11:59 --- Works on gcc 3.4.2 -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17747
[Bug java/18131] [meta-bug] inner class problems in java front-end
-- Bug 18131 depends on bug 17747, which changed state. Bug 17747 Summary: bogus duplicate class errors http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17747 What|Old Value |New Value Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18131
[Bug c++/18285] [4.0 regression] multiple types in typedef not rejected
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-11-04 12:08 --- Mark, the regression was introduced with your patch http://gcc.gnu.org/ml/gcc-cvs/2004-06/msg00988.html -- What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18285
[Bug tree-optimization/18009] [4.0 Regression] ICE in vect_transform_stmt, at tree-vectorizer.c:2625 (testcase included)
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-04 13:39 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18009
[Bug c++/18055] seems not possible to specialize a template member function
-- What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18055
[Bug tree-optimization/18181] vectorizer: problem in the peeling mechanism in the presence of loop invariants that are used after the loop
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-04 13:43 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2004-11-04 13:43:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18181
[Bug c++/18055] seems not possible to specialize a template member function
--- Additional Comments From giovannibajo at libero dot it 2004-11-04 14:08 --- Sorry Ramya, this report is too confusing because of the millions of lines pasted in it. Would you please open a new bug report and this time *attacch* the preprocessed source to it? To attacch it, you must click on the link "Create a new Attacchment", after you have created the bug report. -- What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18055
[Bug rtl-optimization/15342] [arm-linux] internal compiler error: in verify_local_live_at_start
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-04 14:08 --- Subject: Bug 15342 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-04 14:08:16 Modified files: gcc: ChangeLog regrename.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: 20041104-1.c Log message: PR target/15342 * regrename.c (scan_rtx): Treat the destinations of SETs and CLOBBERs as OP_INOUT if the instruction is predicated. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6166&r2=2.6167 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/regrename.c.diff?cvsroot=gcc&r1=1.89&r2=1.90 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4542&r2=1.4543 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20041104-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15342
[Bug c++/18296] New: Misleading diagnostic for recursive template instantiation
template
struct CompFwd;
struct Brick;
template
struct Engine;
template
class Array;
template
struct ComponentView;
template
struct ComponentView >
{
typedef Array Subject_t;
typedef typename Subject_t::Engine_t Engine_t;
typedef Array > Type_t;
};
template
struct Array
{
typedef Engine Engine_t;
typedef Array This_t;
typename ComponentView::Type_t
comp(int i1) const;
};
typedef Array<1, double, Brick> Array_t;
typedef ComponentView::Type_t CView_t;
causes g++ to emit:
tests> g++-3.4 -c notype.cpp
notype.cpp: In instantiation of `Array<1, double, Brick>':
notype.cpp:19: instantiated from `ComponentView'
notype.cpp:36: instantiated from here
notype.cpp:30: error: no type named `Type_t' in `struct ComponentView'
which could be improved to mention the missing of the type is caused by aborted
recursive instantiation of struct ComponentView. At the moment the
diagnostic is at least misleading, as there is a Type_t in struct
ComponentView.
--
Summary: Misleading diagnostic for recursive template
instantiation
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at tat dot physik dot uni-tuebingen dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18296
[Bug c++/18296] Misleading diagnostic for recursive template instantiation
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-04 14:26 --- Confirmed, I think PR 15538 would fix the problem because the class is an incomplete type at this point. -- What|Removed |Added BugsThisDependsOn||15538 Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-04 14:26:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18296
[Bug c++/18296] Misleading diagnostic for recursive template instantiation
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-04 14:27 --- Actually looking at the example in PR 15538, the template in there is a recursive template instantiation so I am closing this as a dup. *** This bug has been marked as a duplicate of 15538 *** -- What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18296
[Bug c++/15538] Message does not indicate that we are trying to look into an incomplete type
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-04 14:27 --- *** Bug 18296 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||rguenth at tat dot physik ||dot uni-tuebingen dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15538
[Bug c++/18296] Misleading diagnostic for recursive template instantiation
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2004-11-04 14:30 --- Subject: Re: Misleading diagnostic for recursive template instantiation On 4 Nov 2004, pinskia at gcc dot gnu dot org wrote: > Confirmed, I think PR 15538 would fix the problem because the class is an incomplete > type at this > point. Yes, maybe - though icpc (7.1 and 8.0) in this case isn't helpful, too: tests> icpc -c notype.cpp notype.cpp(29): error: class "ComponentView" has no member "Type_t" typename ComponentView::Type_t ^ detected during: instantiation of class "Array [with Dim=1, T=double, EngineTag=Brick]" at line 19 instantiation of class "ComponentView> [with Dim=1, T=double, EngineTag=Brick]" at line 36 compilation aborted for notype.cpp (code 2) suspiciously similar to gcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18296
[Bug tree-optimization/18179] vectorizer: wrong alignment/step/initial-address computed for struct accesses
--- Additional Comments From dorit at il dot ibm dot com 2004-11-04 14:44 --- patch: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00277.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18179
[Bug tree-optimization/18181] vectorizer: problem in the peeling mechanism in the presence of loop invariants that are used after the loop
--- Additional Comments From dorit at il dot ibm dot com 2004-11-04 14:45 --- patch: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00283.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18181
[Bug libstdc++/17627] M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h
--- Additional Comments From joel at oarcorp dot com 2004-11-04 14:56 --- Subject: Re: M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h schwab at suse dot de wrote: > --- Additional Comments From schwab at suse dot de 2004-11-03 23:44 --- > Even the 68020 should already show slight improvement when using 4 byte > aligment due to the 32 bit data bus (the 68000/010 only have a 16 bit data > bus). > > Adding an aligned attribute to the _Atomic_int type doesn't help for automatic > variables as gcc limits the alignment to STACK_BOUNDARY. But it will work for > static variables. > > About the ABI change you are of course safe if everything is using the changed > aligment (including the interface to the RTEMS kernel). > That is certainly an option for RTEMS but I am still not sure since I believe this is a problem across more targets. At least, m68k-elf and m68k-coff have the same issue and I am willing to argue that this could show up on a Linux or BSD system. I started with the documentation for -m68060 which implies that the intent is to not generate instructions which have to be emulated. But here we are looking at a piece of manually written code that violates that assumpion since m68060 does not also imply tighter alignment. `-m68060' Generate output for a 68060. This is the default when the compiler is configured for 68060-based systems. This option inhibits the use of 68020 and 68881/68882 instructions that have to be emulated by software on the 68060. Use this option if your 68060 does not have code to emulate those instructions. There is a m68020-60 option which allows the use of emulated instructions. So GCC claims to be making a distinctions. And G... I just found in the MC68060 Programmer's Guide that the unaligned CAS instructions aren't in the emulation package for the 68060. So this is broken whether or not you are using the emulation package. It just isn't there on the 68060. Can _Atomic_word actually be a byte? Does CAS.B work? --joel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17627
[Bug libstdc++/17627] M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h
--- Additional Comments From schwab at suse dot de 2004-11-04 15:12 --- My copy of the 68060 user manual says that the MC68060ISP does contain an emulation for unaligned CAS. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17627
[Bug tree-optimization/17147] Alignment information lost with variable size structures
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-04 15:34 --- The LNO branch is dead and it works correctly on the mainline. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Keywords||missed-optimization Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17147
[Bug fortran/18297] New: gfortran : file opening fails if only read access
using a gfortran build as of today (but this was true also for older versions) open(unit=xx, file=filename, status='old') crashes on linux with Fortran runtime error: Permission denied when we only have read access to the file filename (but works if write access) -- Summary: gfortran : file opening fails if only read access Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mimo2 at free dot fr CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18297
[Bug libfortran/18297] gfortran : file opening fails if only read access
-- What|Removed |Added Component|fortran |libfortran Version|unknown |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18297
[Bug tree-optimization/18298] New: 4.0: bad code from lim ssa pass with strcmp
When i build the example below with -O1 or above, it goes into an infinite
loop:
$ g++ -o x -O1 x.cc
$ ./x
... doesn't exit
At -O0, it exits as expected:
$ g++ -o x -O0 x.cc
$ ./x
$
Here's the code that's generated (eh-related labels removed for clarity).
As you can see, there's an obvious infinite loop...
main:
pushl %ebp
movl%esp, %ebp
subl$8, %esp
andl$-16, %esp
subl$16, %esp
movzbl s, %eax
testb %al, %al
je .L2
.L5:
jmp .L5 ; <-- infinite loop!
.L2:
movb%al, s
movl$0, %eax
leave
ret
The problem seems to be introduced in the `lim' ssa pass, where this
(from t44.loopinit):
int main() ()
{
const unsigned char * prephitmp.3;
const unsigned char * pretmp.2;
const unsigned char * D.1593;
const unsigned char D.1594;
int D.1595;
int D.1590;
int D.1589;
const char * str;
int D.1578;
bool D.1575;
bool retval.0;
int D.1588;
:
pretmp.2_13 = (const unsigned char *) &s[0];
goto ();
:;
s[0] = 0;
# prephitmp.3_14 = PHI ;
:;
D.1593_6 = pretmp.2_13;
D.1594_3 = *D.1593_6;
D.1595_12 = (int) D.1594_3;
D.1590_4 = D.1595_12;
if (D.1590_4 != 0) goto ; else goto ;
:;
return 0;
}
gets transformed to this (from t45.lim):
int main() ()
{
char lsm_tmp.4;
const unsigned char * prephitmp.3;
const unsigned char * pretmp.2;
const unsigned char * D.1593;
const unsigned char D.1594;
int D.1595;
int D.1590;
int D.1589;
const char * str;
int D.1578;
bool D.1575;
bool retval.0;
int D.1588;
:
pretmp.2_13 = (const unsigned char *) &s[0];
D.1593_6 = pretmp.2_13;
D.1594_3 = *D.1593_6;
D.1595_12 = (int) D.1594_3;
D.1590_4 = D.1595_12;
lsm_tmp.4_15 = s[0];
goto ();
:;
lsm_tmp.4_17 = 0;
# lsm_tmp.4_18 = PHI ;
# prephitmp.3_14 = PHI ;
:;
if (D.1590_4 != 0) goto ; else goto ;
# lsm_tmp.4_19 = PHI ;
:;
s[0] = lsm_tmp.4_19;
return 0;
}
Note that the variable being tested at L1 (D.1590_4) never changes.
This feels like it may be related to bugs 17133/17425, but the patch
for that doesn't fix this.
Environment:
System: Linux karma 2.6.8.1 #20 Mon Sep 13 23:48:47 EDT 2004 i686 i686 i386 GNU/Linux
Architecture: i686
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: /home/sss/gcc/gcc/configure --prefix=/usr/local/gcc
--enable-threads=posix --enable-long-long --enable-languages=c,c++,f95
How-To-Repeat:
Compile and run with -O1 or above.
---
extern "C" int strcmp (const char*, const char*);
char s[2048] = "a";
inline bool foo(const char *str) {
return !strcmp(s,str);
}
int main() {
while(!(foo(""))) {
s[0] = '\0';
}
return 0;
}
---
--- Additional Comments From snyder at fnal dot gov 2004-11-04 15:59 ---
Fix:
--
Summary: 4.0: bad code from lim ssa pass with strcmp
Product: gcc
Version: 0.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: snyder at fnal dot gov
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=18298
[Bug tree-optimization/18298] [4.0 Regression] bad code from lim ssa pass with strcmp
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-04 16:06 --- Confirmed, this is an aliasing problem: D.1589_6 = (const unsigned char *) &s[0]; D.1590_3 = *D.1589_6; There is no VUSE on the second statement. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2004-11-04 16:06:10 date|| Summary|4.0: bad code from lim ssa |[4.0 Regression] bad code |pass with strcmp|from lim ssa pass with ||strcmp Target Milestone|--- |4.0.0 Version|0.0 |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18298
[Bug tree-optimization/18298] [4.0 Regression] bad code from lim ssa pass with strcmp
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dnovillo at redhat dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18298
[Bug c++/18285] [4.0 regression] multiple types in typedef not rejected
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18285
[Bug libstdc++/17627] M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h
--- Additional Comments From joel at oarcorp dot com 2004-11-04 16:37 --- Subject: Re: M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h schwab at suse dot de wrote: > --- Additional Comments From schwab at suse dot de 2004-11-04 15:12 --- > My copy of the 68060 user manual says that the MC68060ISP does contain an > emulation for unaligned CAS. > OK. Likely yours is newer and they fixed that. So this is back to being primarily an embedded systems issues. I still wonder if since the -m68060 flag says it avoids emulated instructions, if that switch should imply stricter alignment while the -m68020-60 should not. What about that? --joel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17627
[Bug libstdc++/17627] M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h
--- Additional Comments From schwab at suse dot de 2004-11-04 16:53 --- You can't just increase the alignment as that would break the ABI. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17627
[Bug c/18287] Unaligned access to fields inside packed records
--- Additional Comments From wintermute101 at wp dot pl 2004-11-04 16:54 ---
I write here cause it's simmilar situation as reported here but I have no data
about other gcc versions than 3.3.2.
I have following:
/
define _aligned(n) __attribute__((aligned(n), packed))
struct CzazPort {
unsigned short number;
unsigned long speed;
unsigned long protocol;
unsigned long mode;
unsigned short timeout;
unsigned short loglevel;
unsigned short timerid;
} _aligned(2);
struct CzazPort tmp;
sscanf( data, "%lu", &tmp.speed );
/
data="9600"
before sscanf (content of tmp)
00:01:00:00:96:00:52:54:55:00:38:4e:31:00:03:e8:00:04:2b:67
after sscanf
00:00:25:80:96:00:52:54:55:00:38:4e:31:00:03:e8:00:04:2b:67
9600 in hex -> 0x2580
it was compiled for MOXA UC7420
the same program compiled for i686 works fine
this MOXA has XScale Intel prcessor working in big-endian. I guess this is the
problem (big-endian).
sscanf is just example from source. The same occurs when I relpace sscanf with
(*(&tmp.speed)) = 9600;
but
tmp.speed=9600;
works fine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18287
[Bug other/17783] Top level configure doesn't support shared libraries enabled by default
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-04 17:01 --- Subject: Bug 17783 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-04 17:01:43 Modified files: . : ChangeLog configure Log message: 2004-11-04 H.J. Lu <[EMAIL PROTECTED]> PR other/17783 * configure.in: Set up LD_LIBRARY_PATH by default for gcc. * configure: Regenerated. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/ChangeLog.diff?cvsroot=gcc&r1=1.1005&r2=1.1006 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/configure.diff?cvsroot=gcc&r1=1.189&r2=1.190 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17783
[Bug other/17783] Top level configure doesn't support shared libraries enabled by default
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-04 17:05 --- Subject: Bug 17783 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2004-11-04 17:05:23 Modified files: . : ChangeLog configure.in configure Log message: 2004-11-04 H.J. Lu <[EMAIL PROTECTED]> PR other/17783 * configure.in: Set up LD_LIBRARY_PATH by default for gcc. * configure: Regenerated. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.856.2.23&r2=1.856.2.24 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/configure.in.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.266.4.5&r2=1.266.4.6 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/configure.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.126.4.5&r2=1.126.4.6 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17783
[Bug other/17783] Top level configure doesn't support shared libraries enabled by default
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-04 17:11 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |3.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17783
[Bug other/17464] The newly built gcc shared libraries aren't used for bootstap and check
-- Bug 17464 depends on bug 17783, which changed state. Bug 17783 Summary: Top level configure doesn't support shared libraries enabled by default http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17783 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17464
[Bug middle-end/18293] Redundant copy operation introduced by expand
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-04 17:20
---
I am testing this patch (which is a modified version of the one which you gave me), it
should help -O0
compile time as we no longer have an extra INSN which gets removed right after the
register allocator:
Index: expmed.c
===
RCS file: /cvs/gcc/gcc/gcc/expmed.c,v
retrieving revision 1.200
diff -u -p -r1.200 expmed.c
--- expmed.c21 Oct 2004 10:51:00 - 1.200
+++ expmed.c4 Nov 2004 16:55:46 -
@@ -2638,7 +2638,10 @@ expand_mult_const (enum machine_mode mod
}
else if (alg->op[0] == alg_m)
{
- accum = copy_to_mode_reg (mode, op0);
+ if (REG_P (op0) && GET_MODE (op0) == mode && alg->ops == 2)
+accum = op0;
+ else
+accum = copy_to_mode_reg (mode, op0);
val_so_far = 1;
}
else
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18293
[Bug libfortran/18297] gfortran : file opening fails if only read access
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-04 17:36 --- Do you have a simple example/testcase? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18297
[Bug tree-optimization/18298] [4.0 Regression] bad code from lim ssa pass with strcmp
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-04 18:04 --- The problem is that fold all builtins is not creating the operands on the statement, if you write the code as fab would create it is right. I am looking into fixing the problem right now. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18298
[Bug target/18010] bad unwind info due to multiple returns (missing epilogue)
--- Additional Comments From davidm at hpl dot hp dot com 2004-11-04 18:06 --- (In reply to comment #18) > On Thu, 2004-10-28 at 02:24, davidm at hpl dot hp dot com wrote: > > # of unexpected failures115 > > This is a lot more failures than we should have. I didn't have any luck > in reproducing this though. I did an apt-get update and dist-upgrade on > my debian/unstable partition, rebooted just in case, built and installed > libunwind-0.98 from source, then did a gcc bootstrap and make check, and > got 46 gcc failures. This is from gcc mainline, last updated on Monday. I tried this again, on two different Debian/unstable systems and it now worked much better. On the first (which had the 115 failures before), I got: # of unexpected failures47 On the second, which has a "better" libc and gas installed I get: # of unexpected failures41 Here, by "better" I mean a glibc which has some unwind-info fixes and a gas which handles the psp-relative unwind directives correctly. Though I should say that I did not try to verify that the additional passes are due to these differences. In any case, I agree now: GCC head looks pretty good! Also, you might like to know that as of last Friday, I was for the first time able to successfully complete a test which single-steps through a program from the beginning to the end (including all the ld.so startup/shutdown!), getting a backtrace after each instruction without detecting any failures! Of course, that doesn't prove that the unwind-info is 100% correct, but it _is_ a tough test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18010
[Bug tree-optimization/18299] New: ICE
The attached code (preprocessed cp/decl.c with a patch), causes an ice at -O2. I think it might have something to do with nested statement-expressions. [EMAIL PROTECTED]:179>./cc1 -O2 bug.i -quiet bug.i: In function 'start_preparsed_function': bug.i:20444: internal compiler error: unexpected node -- Summary: ICE Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: nathan at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18299
[Bug tree-optimization/18299] ICE
--- Additional Comments From nathan at gcc dot gnu dot org 2004-11-04 18:12 --- Created an attachment (id=7472) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7472&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18299
[Bug target/18300] New: Infinite loop when passing object with 3+ base classes by value
On x86_64 (but not on i686) the following legal code sends gcc 3.2.3, 3.3.4 and
current 3.3-branch CVS into an infinite loop.
/
struct Base1 { };
struct Base2 { };
struct Base3 { };
struct Derived : Base1, Base2, Base3 { };
void foo(Derived);
int main()
{
foo(Derived());
}
//
The problem appears to be in classify_argument in gcc/config/i386.c: in both the
RECORD_TYPE and UNION_TYPE branches, the same loop variable (i) is used in two
nested loops. I'm not sure I fully understand this code, but it seems unlikely
that this is the intention. I'm also not sure if it's possible for this to
result in other failure modes besides the infinite loop, although it certainly
seems possible.
Using two distinct loop variables appears to fix the problem -- a patch will
follow after I've done testsuite runs on current CVS. (Looking at the source,
the above problem appears to still be present on the 3.4 branch and CVS HEAD,
although I've not tested there yet.)
--
Summary: Infinite loop when passing object with 3+ base classes
by value
Product: gcc
Version: 3.3.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zak at transversal dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18300
[Bug target/18300] Infinite loop when passing object with 3+ base classes by value
-- What|Removed |Added Keywords||compile-time-hog Known to fail||3.2.3 3.3.3 3.3.4 3.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18300
[Bug java/18190] [4.0 regression] primitive array optimization is gone
--- Additional Comments From mckinlay at redhat dot com 2004-11-04 18:46 --- Here's my thoughts about this: - This optimization only ever worked for source compilation. Bytecode compilers always emit array initializers as code, so for byte compilation it makes no difference. - I don't see a strong reason not to reference the vtable symbols, but if we decide to remove my patch then we need to be careful that the original bug remains fixed - see: http://gcc.gnu.org/ml/java-patches/2004-q3/msg00343.html - Is this optimization really worth worrying about? I'm pretty sure that performance-wise, the difference is insignificant - binary size is what we should be concerned about here. Is a binary that initializes arrays in code significantly larger? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18190
[Bug target/14591] index variable reuse
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-04 18:53 --- Lets mark this as a dup of bug 18300 which contains a testcase. *** This bug has been marked as a duplicate of 18300 *** -- What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14591
[Bug target/18300] Infinite loop when passing object with 3+ base classes by value
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-04 18:53 --- *** Bug 14591 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||kong at ece dot ucdavis dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18300
[Bug target/18300] Infinite loop when passing object with 3+ base classes by value
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-04 18:54 --- Confimred via PR 14591. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-04 18:54:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18300
[Bug ada/18301] New: SEGV (stack overflow) compiling g-catiio.adb on Solaris 10/x86
Building libada on Solaris 10/x86 fails when compiling g-catiio.adb: $ ../../xgcc -B../../ -c -g -O2 -fPIC -W -Wall -gnatpg g-catiio.adb -o g-catiio.o xgcc: Internal error: Segmentation Fault (program gnat1) Running gnat1 under gdb reveals that this happens due to extremely deep recursion in Program received signal SIGSEGV, Segmentation fault. 0x085e88bd in ggc_set_mark (p=0xd13f5bd0) at /vol/gnu/src/gcc/gcc-dist/gcc/ggc-page.c:1254 (gdb) where #0 0x085e88bd in ggc_set_mark (p=0xd13f5bd0) at /vol/gnu/src/gcc/gcc-dist/gcc/ggc-page.c:1254 #1 0x0812b7d1 in gt_ggc_mx_lang_tree_node (x_p=0xd13f5bd0) at gtype-ada.h:27 #2 0x0812b9d2 in gt_ggc_mx_lang_tree_node (x_p=0xd13f5bf4) at gtype-ada.h:178 #3 0x0812b9d2 in gt_ggc_mx_lang_tree_node (x_p=0xd13f5c18) at gtype-ada.h:178 #4 0x0812b9d2 in gt_ggc_mx_lang_tree_node (x_p=0xd13f5c3c) at gtype-ada.h:178 #5 0x0812b9d2 in gt_ggc_mx_lang_tree_node (x_p=0xd13f5c60) at gtype-ada.h:178 #6 0x0812b9d2 in gt_ggc_mx_lang_tree_node (x_p=0xd13f5c84) at gtype-ada.h:178 #7 0x0812b9d2 in gt_ggc_mx_lang_tree_node (x_p=0xd13f5ca8) at gtype-ada.h:178 [...] This went on to a depth of 76000+ when I aborted gnat1. The problem exists with the default stack size of 8430 kB; if I increase the stack size limit to the max (i.e. 130336 kB), the compilation succeeds. While this might be a workaround, I don't consider it a solution. Environment: System: SunOS erebus 5.10 s10_69 i86pc i386 i86pc Architecture: i86pc host: i386-pc-solaris2.10 build: i386-pc-solaris2.10 target: i386-pc-solaris2.10 configured with: /vol/gnu/src/gcc/gcc-dist/configure --prefix=/vol/gcc --with-local-prefix=/vol/gcc --disable-nls --enable-languages=c,ada How-To-Repeat: Bootstrap current mainline as above. -- Summary: SEGV (stack overflow) compiling g-catiio.adb on Solaris 10/x86 Product: gcc Version: 0.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at techfak dot uni-bielefeld dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i386-pc-solaris2.10 GCC host triplet: i386-pc-solaris2.10 GCC target triplet: i386-pc-solaris2.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18301
[Bug libstdc++/17627] M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h
--- Additional Comments From joel at oarcorp dot com 2004-11-04 19:11 --- Subject: Re: M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h schwab at suse dot de wrote: > --- Additional Comments From schwab at suse dot de 2004-11-04 16:53 --- > You can't just increase the alignment as that would break the ABI. Are we stuck with requiring the 68060 ISP package even when -m68060 is specified and it says no emulated instructions are used? GCC ALMOST meets the no ISP requirement with the -m68060 argument but can't do it completely without breaking the ABI. Grrr.. I hate to suggest this but is it possible to add a -m68060-noisp option to increase the alignment and avoid the rest of the issues. I don't want to change the code generation rules/ABI for the -m68060 argument, so I think we are stuck clarifying the documentation to include that it maintains ABI compatability and in doing so may generate code which violates strict alignment requirements. To support these edge conditions you must have the ISP. Any other thoughts? --joel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17627
[Bug ada/18301] SEGV (stack overflow) compiling g-catiio.adb on Solaris 10/x86
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-04 19:12 --- This is a dup of bug 17986 which I already posted a patch for. I think I am going to apply it as obvious as all other front-end has the same code. *** This bug has been marked as a duplicate of 17986 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE Version|0.0 |2.95 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18301
[Bug ada/17986] [4.0 Regression] Compile error for make.adb breaks bootstrap
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-04 19:12 --- *** Bug 18301 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||ro at techfak dot uni- ||bielefeld dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17986
[Bug middle-end/18299] [4.0 Regression] ICE in gimple-lower
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-04 19:19 --- Confimed, reducing (gimple-lowering is crapping out on VAR_DECL, it could also crap out on INDIRECT_REF, and COMPONENT_REF which are valid gimple statements). -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|tree-optimization |middle-end Keywords||ice-on-valid-code Summary|ICE |[4.0 Regression] ICE in ||gimple-lower Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18299
[Bug middle-end/18299] [4.0 Regression] ICE in gimple-lower
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-04 19:48 --- note the code will not work as you have "const tree __t = (__t);" in the code. I will see if I can reduce it as this should not be that important. This is why macros are bad. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18299
[Bug middle-end/18299] [4.0 Regression] ICE in gimple-lower
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-04 19:52
---
Confirmed, here is the reduced testcase:
static inline int f(int i)
{
const int __t = (__t);
}
int g(void)
{
return f(0);
}
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2004-11-04 19:52:12
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18299
[Bug ada/18302] New: ACATS test c94002f hangs on Solaris 10/x86
Running the Ada testsuite on Solaris 10/x86 hangs in the c94002f test: pstack reveals the following stack trace: 21873: /vol/gcc/obj/gcc-4.0.0-20041103/10-gcc-ada/gcc/testsuite/ada/acats/tes - lwp# 1 / thread# 1 d2751779 lwp_park (0, 0, 0) d274bf03 cond_wait_queue (80b4480, 80b4490, 0, 0) + 3b d274c40c _cond_wait (80b4480, 80b4490) + 66 d274c451 cond_wait (80b4480, 80b4490, 8045f88, 808b14c) + 21 0808b216 system__tasking__stages__vulnerable_complete_master (d27f0818, 80b4438, 8046228, 8091a35, 8046000, 80b44f8) + ea 080900b2 c94002f__B_1___clean.924 (8046000, 80b44f8, 8046228, 8091b50, 80a98c8, 8046010) + 12 08091a35 _ada_c94002f (29, d2780fb8, 133f, 1f80, 8046238, 80a9c4b) + 2f5 0806d7d8 main (1, 804627c, 8046284) + 3a 0806d4b0 _start (1, 8046534, 0, 8046590, 80465ee, 8046605) + 60 - lwp# 2 / thread# 2 d2751779 lwp_park (0, 0, 0) d274bf03 cond_wait_queue (80b7868, 80b7878, 0, 0) + 3b d274c40c _cond_wait (80b7868, 80b7878) + 66 d274c451 cond_wait (80b7868, 80b7878, d274b1b1, 1) + 21 08089613 system__tasking__rendezvous__wait_for_call (80b7820, 0, 0, 0, 0, 0) + 6b 08089a67 system__tasking__rendezvous__accept_trivial (1, 0, d25f9d58, 808ffed, 0, 0) + db 08090039 c94002f__ttB.416 (80b4b68, 1, 0, 0, 0, 0) + 5d 0808b6e0 system__tasking__stages__task_wrapper (80b7820) + 10c d2751530 _thr_setup (d2658400) + 50 d27516f0 _lwp_start (d2658400, 0, 0, d25f9ff8, d27516f0, d2658400) Unfortunately, the test can only be killed with kill -9, which lets the whole testsuite run abort. For the moment, I'm including the test in norun.lst, but that file isn't platform specific, so with a shared source tree, the test is disabled everywhere. Environment: System: SunOS erebus 5.10 s10_69 i86pc i386 i86pc Architecture: i86pc host: i386-pc-solaris2.10 build: i386-pc-solaris2.10 target: i386-pc-solaris2.10 configured with: /vol/gnu/src/gcc/gcc-dist/configure --prefix=/vol/gcc --with-local-prefix=/vol/gcc --disable-nls --enable-languages=c,ada How-To-Repeat: Run make check as above. -- Summary: ACATS test c94002f hangs on Solaris 10/x86 Product: gcc Version: 0.0 Status: UNCONFIRMED Severity: critical Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at techfak dot uni-bielefeld dot de CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i386-pc-solaris2.10 GCC host triplet: i386-pc-solaris2.10 GCC target triplet: i386-pc-solaris2.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18302
[Bug tree-optimization/18184] [4.0 Regression] Tree optimizers ignore pointer modes
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-04 20:11 --- Subject: Bug 18184 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-04 20:11:16 Modified files: gcc: ChangeLog c-typeck.c tree-ssa.c gcc/cp : ChangeLog cp-objcp-common.c typeck.c Log message: ChangeLog: PR tree-optimization/18184 * c-typeck.c (comptypes): Do not treat pointers of different modes or alias-all flags as equivalent. * tree-ssa.c (tree_ssa_useless_type_conversion_1): Likewise. cp/ChangeLog: PR tree-optimization/18184 * cp-objcp-common.c (cxx_types_compatible_p): Do not treat pointers of different modes or alias-all flags as equivalent. * typeck.c (comptypes): Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6168&r2=2.6169 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-typeck.c.diff?cvsroot=gcc&r1=1.394&r2=1.395 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa.c.diff?cvsroot=gcc&r1=2.54&r2=2.55 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4473&r2=1.4474 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-objcp-common.c.diff?cvsroot=gcc&r1=1.3&r2=1.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/typeck.c.diff?cvsroot=gcc&r1=1.592&r2=1.593 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18184
[Bug tree-optimization/18298] [4.0 Regression] bad code from lim ssa pass with strcmp
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-04 20:25 --- Adding a may_alias pass after fold all builtins makes this testcase works (I don't know if this is correct fix or not): Index: tree-optimize.c === RCS file: /cvs/gcc/gcc/gcc/tree-optimize.c,v retrieving revision 2.61 diff -u -p -r2.61 tree-optimize.c --- tree-optimize.c 2 Nov 2004 00:23:04 - 2.61 +++ tree-optimize.c 4 Nov 2004 20:23:32 - @@ -371,6 +371,7 @@ init_tree_optimization_passes (void) NEXT_PASS (pass_ccp); NEXT_PASS (pass_redundant_phi); NEXT_PASS (pass_fold_builtins); + NEXT_PASS (pass_may_alias); NEXT_PASS (pass_split_crit_edges); NEXT_PASS (pass_pre); NEXT_PASS (pass_loop); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18298
[Bug tree-optimization/18184] [4.0 Regression] Tree optimizers ignore pointer modes
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-04 20:32 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18184
[Bug java/18190] [4.0 regression] primitive array optimization is gone
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-04 21:19 --- Note I attached the front-end part so the only thing left is to fix up libjava to emit the vtables again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18190
[Bug middle-end/17746] [4.0 Regression] ICE when building the Ada RTS
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-11-04 22:12 --- Pending patch: http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01630.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17746
[Bug other/18303] New: Establish the intl directory as the single source for iconv configury information
Currently, the config.h files in the intl and libcpp directories, as well as auto-host.h all may contain definitions of HAVE_ICONV and HAVE_ICONV_H (though not all have both). Zack Weinberg suggested the following and suggested I create this report and assign to him: I think maybe we should do with iconv.h what we already do with libintl - have the intl directory determine the answer, and everyone else just defers to that. -- Summary: Establish the intl directory as the single source for iconv configury information Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: other AssignedTo: zack at codesourcery dot com ReportedBy: gerald at pfeifer dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18303
[Bug c++/18304] New: unnecessary typename expected
$ cat >test.cxx
template
struct s
{
struct t
{
enum v { a, b };
};
t::v m_;
};
$ g++ -v
Reading specs from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/specs
Configured with: ./configure --enable-languages=c,c++ --enable-shared
--with-system-zlib --enable-nls --program-suffix=-3.4 --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --enable-clocale=gnu --enable-libstdcxx-debug
--disable-werror
Thread model: posix
gcc version 3.4.3 20041101 (prerelease)
$ g++ -c test.cxx
test.cxx:9: error: expected `;' before "m_
--
Summary: unnecessary typename expected
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: boris at kolpackov dot net
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-linux-gnu
GCC host triplet: i686-linux-gnu
GCC target triplet: i686-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18304
[Bug c++/18304] unnecessary typename expected
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-04 22:55 --- This is a dup of bug 9634. *** This bug has been marked as a duplicate of 9634 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18304
[Bug c++/9634] [3.4/4.0 regression] [DR224] Injected class name as qualifier should not make the name dependent
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-04 22:55 --- *** Bug 18304 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||boris at kolpackov dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9634
[Bug java/18190] [4.0 regression] primitive array optimization is gone
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-04 23:06 --- I finished up porting the other part of the expand part. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18190
[Bug libfortran/18297] gfortran : file opening fails if only read access
--- Additional Comments From bdavis at gcc dot gnu dot org 2004-11-04 23:21 --- gfortran runtime does not know that you only intend to write to the file. you need to add ACCESS='READ' to the open statement. With ACCESS set to read, a read only file can be opened. i do not think this is a bug. --bud davis -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18297
[Bug rtl-optimization/5738] GCSE missed optimization: common condition instructions
--- Additional Comments From dalej at apple dot com 2004-11-04 23:31 --- It does say that, and I expect cases can be constructed where the comment is true, but it is not completely right. When you replace 2 copies of code with 1 copy you are generally making it smaller. Plus, there is a beneficial interaction with RTL invariant hoisting, as it exposes more invariants when you do hoisting inside a loop. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5738
[Bug c++/18304] unnecessary typename expected
--- Additional Comments From giovannibajo at libero dot it 2004-11-05 00:35 --- No, DR 224 will disambiguate whether the injected class name is dependent or not. This is unrelated. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18304
[Bug c++/18304] unnecessary typename expected
--- Additional Comments From giovannibajo at libero dot it 2004-11-05 00:39
---
Anyway, it is invalid because a nested class (like "t") is always dependent, as
you can specialize it. think of what happens if you define this later:
template <>
struct s::t {
};
(now, in this very case, it would be invalid because you cannot specialize this
nested class after having already used the primary template s::t, but the
point is to show that s::t is always a dependent context, even within s).
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18304
[Bug java/15576] [4.0 Regression] Class initialization optimization is disabled
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-05 00:43 --- I have a fix which just renables the orginal code plus fixes the other part of the front-end. -- 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=15576
[Bug java/15576] [4.0 Regression] Class initialization optimization is disabled
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-05 01:08 --- I attached the patch which I am testing right now to fix this. The changelog is: * check-init.c (check_init): Ignore DECL_EXPR. * expr.c (always_initialize_class_p): Reenable. (build_class_init): Use a variable to store the decl. Also use boolean_false_node instead of integer_zero_node. * parse.y (attach_init_test_initialization_flags): Add a decl_expr to the block. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15576
[Bug java/18305] New: Class initialization optimization is not done when compiled from .class
I noticed this when looking at the regression, PR 15576. I don't know why it is disabled for compiling .class. It might because we were not function at a time before 4.0, I don't know. -- Summary: Class initialization optimization is not done when compiled from .class Product: gcc Version: 4.0.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P2 Component: java 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,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18305
[Bug java/18305] Class initialization optimization is not done when compiled from .class
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-05 01:27 --- The code in question: /* Currently we always have to emit calls to _Jv_InitClass when compiling from class files. */ always_initialize_class_p = 1; -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-05 01:27:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18305
[Bug libfortran/18297] gfortran : file opening fails if only read access
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-05 01:29 --- Yes this is invalid by reading the code. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18297
[Bug fortran/18283] gfortran: ICE in gfc_conv_string_parameter, trans-expr.c:1982
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-05 01:39 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-05 01:39:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18283
[Bug rtl-optimization/18295] verify_local_live_at_start failed with -O3
-- What|Removed |Added Summary|ICE |verify_local_live_at_start ||failed with -O3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18295
[Bug target/18263] Build broken for ARC.
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-11-05 02:54 --- Subject: Bug 18263 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-11-05 02:54:20 Modified files: gcc: ChangeLog gcc/config/arc : lib1funcs.asm Log message: PR target/18263 * config/arc/lib1funcs.asm (___umulsidi3): Change use of cmp to the equivalent on the A4. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6182&r2=2.6183 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/arc/lib1funcs.asm.diff?cvsroot=gcc&r1=1.8&r2=1.9 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18263
[Bug ada/18217] [4.0 Regression] Ada Bootstrap failures on powerpc-darwin with undefined symbol (__Unwind_fallback_frame_state_for)
--- Additional Comments From awreynolds at mac dot com 2004-11-05 03:25 --- The function Unwind_fallback_frame_state_for is defined in darwin-fallback.c. pbg4:~/Developer/Compiler/fsf-gcc-obj/gcc drew$ nm libgcc.a | grep Unwind_fallback_ T __Unwind_fallback_frame_state_for -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18217
[Bug ada/18217] [4.0 Regression] Ada Bootstrap failures on powerpc-darwin with undefined symbol (__Unwind_fallback_frame_state_for)
-- What|Removed |Added CC||awreynolds at mac dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18217
[Bug ada/18217] [4.0 Regression] Ada Bootstrap failures on powerpc-darwin with undefined symbol (__Unwind_fallback_frame_state_for)
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-05 03:32 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-11-05 03:32:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18217
[Bug target/18263] [3.4 only] Build broken for ARC.
-- What|Removed |Added Known to fail||3.4.3 Known to work||4.0.0 Summary|Build broken for ARC. |[3.4 only] Build broken for ||ARC. Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18263
[Bug c/18282] PR c/17384 patch causes regression from 3.4.2
--- Additional Comments From mmitchel at gcc dot gnu dot org 2004-11-05 04:07 --- I'm not going to hold up 3.4.3 for this issue. Richard's change makes this an error, so it's at most a rejects-valid. There's also a good workaround: declare the enum __attribute__((packed)). That's probably a better choice anyhow. I'll let you and Richard sort out what the right semantics ought to be. (FWIW, I think my sentiment is that this ought to be like structures: you don't get to pick the mode, but you can say "packed" if you want.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18282
[Bug c++/18306] New: seems not possible to specialize a template member function
Environment : i686-pc-linux-gnu Compiler Version: GCC 3.3.2 Kernel Version : 2.4.7-10 It seems, not possible to specialize a template member functions const. I got a file(.impl) which got the following template functions( generalized and specialized template functions ) and i got the corresponding header file ( where this .impl file is getting included ). IOCM::Status IOCM_SequenceTempl::_skip(IOCM::MessageBox& msgBox); IOCM::Status IOCM_SequenceTempl::_skip(IOCM::MessageBox& msgBox); IOCM::Status IOCM_SequenceTempl::_skip(IOCM::MessageBox& msgBox); IOCM::Status IOCM_SequenceTempl::_skip(IOCM::MessageBox& msgBox); IOCM::Status IOCM_SequenceTempl::_skip(IOCM::MessageBox& msgBox); IOCM::Status IOCM_SequenceTempl::_skip(IOCM::MessageBox& msgBox); IOCM::Status IOCM_SequenceTempl::_skip(IOCM::MessageBox& msgBox); IOCM::Status IOCM_SequenceTempl::_skip(IOCM::MessageBox& msgBox); But, the build is getting failed, with the following error( for all the template functions ). /cm4/objects/gant-c/ghostr/cm4/fsn/app/asam/eqptDomain/eqptMgntCore/common/AppliqueSensorListener.o(.text+0x0): In function `IOCM_SequenceTempl::_size() const': /cm4/fsn/include/iocm/Sequence.impl:293: multiple definition of `IOCM_SequenceTempl::_size() const' /cm4/objects/gant-c/ghostr/cm4/fsn/app/asam/eqptDomain/eqptMgntCore/common/AppliqueHandler.o(.text+0x0):/cm4/fsn/include/iocm/Sequence.impl:293: first defined here /cm4/objects/gant-c/ghostr/cm4/fsn/app/asam/eqptDomain/eqptMgntCore/common/AppliqueSensorListener.o(.text+0x18): In function `IOCM_SequenceTempl::_pack(IOCM_MessageBox&) const': /cm4/fsn/include/iocm/Sequence.impl:305: multiple definition of `IOCM_SequenceTempl::_pack(IOCM_MessageBox&) const' /cm4/objects/gant-c/ghostr/cm4/fsn/app/asam/eqptDomain/eqptMgntCore/common/AppliqueHandler.o(.text+0x18):/cm4/fsn/include/iocm/Sequence.impl:305: first defined here There is no problem with 2.95.3 But, when i remove the .impl file( which got the template function definitions ) from the corresponding header file, compilation went through, but its failing during linking stage for the same reason giving the following error message for all the template functions. Linking fails with the following error( for all the template functions ). /cm4/fsn/app/asam/atm2/nt/../export/idl/AtmApplication_ifc.cc:344: undefined reference to `IOCM_SequenceTempl::_size(void) const' /cm4/fsn/app/asam/atm2/nt/../export/idl/AtmApplication_ifc.cc:349: undefined reference to `IOCM_SequenceTempl::_pack(IOCM_MessageBox &) const' -- Summary: seems not possible to specialize a template member function Product: gcc Version: 3.2.2 Status: UNCONFIRMED Severity: critical Priority: P1 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ramya dot chandar at wipro dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18306
[Bug c++/18306] seems not possible to specialize a template member function
--- Additional Comments From ramya dot chandar at wipro dot com 2004-11-05 04:19 --- Created an attachment (id=7476) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7476&action=view) preprocessed source for AppliqueHandler.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18306
[Bug c++/18306] seems not possible to specialize a template member function
--- Additional Comments From ramya dot chandar at wipro dot com 2004-11-05 04:21 --- Created an attachment (id=7477) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7477&action=view) preprocessed code for AppliqueSensorListener.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18306
[Bug c++/18306] seems not possible to specialize a template member function
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-05 04:28 --- As I said before the code you have here is invalid C++. you have to add template<> in front of each of the specialization of a template member function. Also you have problems with template namelookup also (read the 3.4 release notes for the problems which I am talking about). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18306
[Bug c++/18306] seems not possible to specialize a template member function
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-05 05:03 --- Invalid, as what you are doing is called explicit specializtion and when this happens you instantiate the template and now you are violating the one defintional rule (which is 14.7/5 in the C++ standard). -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18306
