[Bug libfortran/19595] eor and advance=yes should not mix
-- What|Removed |Added Keywords||diagnostic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19595
[Bug libfortran/19596] eor generates false error message with advance='NO'
-- What|Removed |Added Keywords||rejects-valid http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19596
[Bug target/19597] [4.0 Regression] avr-gcc 4.0, multiplication by constant, very long code
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-24 08:16 --- (In reply to comment #4) But to summarise, this is a target bug. That is what I thought. Anyways Roger posted a patch to rewrite rtx_cost for AVR to fix this bug here: http://gcc.gnu.org/ml/ gcc-patches/2005-01/msg01698.html It might also improve other things too because of the mentioned items in that mail. -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19597
[Bug rtl-optimization/19210] [4.0 Regression] not using do-loop for some loops
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-01-24 08:28 --- The thread on -funsafe-loop-optimizations extinguished without any result. Zdenek, maybe you should propose the patch together with adding -Wunsafe-loop-optimizations to -Wextra, and without adding -funsafe-loop-optimizations to -O2 for now (maybe it can be revisited for 4.1, and the 3.3 behavior would be a point in favor of it). -- What|Removed |Added CC||bonzini at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19210
[Bug c++/19208] [3.4 Regression] Spurious error about variably modified type
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-01-24 08:29 --- Removing 4.0.0 from known-to-fail list. -- What|Removed |Added Known to fail|4.0.0 3.4.3 3.4.0 |3.4.3 3.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19208
[Bug middle-end/19551] [3.4/4.0 Regression] pure (complex types) function call removed as dead (LAPACK routine claic1.f bug)
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-24 08:55 --- Subject: Bug 19551 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-24 08:54:26 Modified files: gcc: ChangeLog flow.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/execute: 20050121-1.c gcc/testsuite/gcc.dg: 20050121-2.c Log message: * flow.c (propagate_one_insn): Formatting. PR middle-end/19551 * flow.c (libcall_dead_p): Be more conservative if unsure. If there are any instructions between insn and call, see if they are all dead before saying the libcall is dead. * gcc.c-torture/execute/20050121-1.c: New test. * gcc.dg/20050121-2.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.7255r2=2.7256 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/flow.c.diff?cvsroot=gccr1=1.614r2=1.615 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4928r2=1.4929 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/20050121-1.c.diff?cvsroot=gccr1=NONEr2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20050121-2.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19551
[Bug target/19597] [4.0 Regression] avr-gcc 4.0, multiplication by constant, very long code
--- Additional Comments From giovannibajo at libero dot it 2005-01-24 08:56 --- Marek, can you review this patch please? -- What|Removed |Added CC||marekm at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19597
[Bug bootstrap/19601] [4.0 Regression] make bootstrap-lean fails: insn-conditions.c:189: error: `flag_unsafe_math_optimizations' undeclared
--- Additional Comments From olh at suse dot de 2005-01-24 09:01 --- Created an attachment (id=8050) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8050action=view) gccbug19601.tar.bz2 make without -jN doesnt fix it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19601
[Bug middle-end/19551] [3.4/4.0 Regression] pure (complex types) function call removed as dead (LAPACK routine claic1.f bug)
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-24 09:11 --- Subject: Bug 19551 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-01-24 09:10:53 Modified files: gcc: ChangeLog flow.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/execute: 20050121-1.c Log message: * flow.c (propagate_one_insn): Formatting. PR middle-end/19551 * flow.c (libcall_dead_p): Be more conservative if unsure. If there are any instructions between insn and call, see if they are all dead before saying the libcall is dead. * gcc.c-torture/execute/20050121-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.780r2=2.2326.2.781 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/flow.c.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.572.4.3r2=1.572.4.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_4-branchr1=1.3389.2.351r2=1.3389.2.352 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/20050121-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=19551
[Bug tree-optimization/18316] Missed IV optimization
--- Additional Comments From stevenb at suse dot de 2005-01-24 09:12 --- Subject: Re: Missed IV optimization *sigh* The old loop optimizer... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18316
[Bug middle-end/19551] [3.4/4.0 Regression] pure (complex types) function call removed as dead (LAPACK routine claic1.f bug)
--- Additional Comments From jakub at gcc dot gnu dot org 2005-01-24 09:12 --- Should be fixed in CVS. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19551
[Bug fortran/5900] [g77 gfortran] Lapack regressions since g77 2.95.2
-- Bug 5900 depends on bug 19551, which changed state. Bug 19551 Summary: [3.4/4.0 Regression] pure (complex types) function call removed as dead (LAPACK routine claic1.f bug) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19551 What|Old Value |New Value Status|UNCONFIRMED |NEW Status|NEW |ASSIGNED Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900
[Bug target/19597] [4.0 Regression] avr-gcc 4.0, multiplication by constant, very long code
--- Additional Comments From marekm at amelek dot gda dot pl 2005-01-24 09:24 --- Subject: Re: [4.0 Regression] avr-gcc 4.0, multiplication by constant, very long code On Mon, Jan 24, 2005 at 08:56:46AM -, giovannibajo at libero dot it wrote: Marek, can you review this patch please? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19597 Thanks. Reviewing this will take some time - I agree the current rtx costs are not perfect, but changing them can affect generated code in unexpected ways. It would be good to test it a lot on various test cases, to make sure it doesn't introduce new code size regressions... Marek -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19597
[Bug tree-optimization/19401] Trivial loop not unrolled
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen
dot de 2005-01-24 09:43 ---
Another one - matrix multiplication:
/* A [NxM], B [MxP] */
#define DOLOOP(N, M, P) \
void matmul ## N ## M ## P(double *res, const double *A, const double *B) \
{ \
int i,j,k; \
for (k=0; kP; ++k) \
for (i=0; iN; ++i) { \
double s = 0.0; \
for (j=0; jM; ++j) \
s += A[i*M+j] * B[j*P+k]; \
res[i*P+k] = s; \
} \
}
DOLOOP(1, 1, 1)
DOLOOP(2, 1, 2)
DOLOOP(1, 2, 1)
DOLOOP(2, 2, 2)
DOLOOP(1, 3, 1)
DOLOOP(1, 1024, 1)
all up to 2x2 should be profitable to completely unroll. Be sure to unroll
one-time rolling loops like for the last case.
Zdeneks patch only does not unroll the DOLOOP(2, 2, 2) case at -O2. Good.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19401
[Bug libstdc++/8670] Alignment problem in std::basic_string
--- Additional Comments From pcarlini at suse dot de 2005-01-24 09:45 --- I have read the discussion on 17744 and 19163. Nothing there suggests that there is any reason to prefer using an __attribute__ over using the portable, stable, apparently already-working union approach, where it serves. The union approach, contrariwise, is manifestly better anywhere the __attribute__ feature is broken, which it is said still to be, proposed patches notwithstanding. The feature its broken and the proposed patches don't fix it. Plenty of discussions on gcc-patches and elsewhere, no doubts about this. Also, there is an agreement about the maintainers that from now one, really we should concentrate our efforts in preparing a new implementation of basic_string: these alignment problems are not new, always been there. Why should library fixes (specifically, 19495) wait unnecessarily on fixes for compiler extensions -- more particularly, extensions unlikely to be fixed in the older releases whose libraries we still maintain? What am I missing? I'm still trying to figure out a simple, non-invasive, clean, way to implement your suggestions. We don't want loads of casts, or unions, additional instantiations (requiring loads of additional includes) and failing tests elsewhere (ext/array_allocator needs tweaks), uglyness, in a word. I'm still trying to figure whether we can achieve that within the current implementation and without subtracting too much energy to other projects (among which the new implementation itself): please be patient, thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8670
[Bug tree-optimization/19217] [4.0 Regression] ICE: verify_stmts failed: address taken, but ADDRESSABLE bit not set
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-24 09:51 --- I cannot reproduce this with the original test case and yesterday's CVS HEAD. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19217
[Bug rtl-optimization/19579] [3.3/3.4/4.0 regression] -march=i686 generates a bogus program for x86*
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-24 09:40 --- wrong-code bug, should be P1. -- What|Removed |Added CC||steven at gcc dot gnu dot ||org Priority|P2 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19579
[Bug target/19597] [4.0 Regression] avr-gcc 4.0, multiplication by constant, very long code
--- Additional Comments From bernie at develer dot com 2005-01-24 10:28 --- Subject: Re: [4.0 Regression] avr-gcc 4.0, multiplication by constant, very long code marekm at amelek dot gda dot pl wrote: --- Additional Comments From marekm at amelek dot gda dot pl 2005-01-24 09:24 --- Subject: Re: [4.0 Regression] avr-gcc 4.0, multiplication by constant, very long code On Mon, Jan 24, 2005 at 08:56:46AM -, giovannibajo at libero dot it wrote: Marek, can you review this patch please? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19597 Thanks. Reviewing this will take some time - I agree the current rtx costs are not perfect, but changing them can affect generated code in unexpected ways. It would be good to test it a lot on various test cases, to make sure it doesn't introduce new code size regressions... I'm building avr-gcc right now with your two patches and this one applied. I'll let you know shortly. btw, how do you test the AVR backend? Can you execute the dejagnu testsuite on simulavr or something similar? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19597
[Bug rtl-optimization/19579] [3.3/3.4/4.0 regression] -march=i686 generates a bogus program for x86*
--- Additional Comments From jakub at gcc dot gnu dot org 2005-01-24 10:30 --- Regarding the question in #11: LOG_LINKS only point to instructions in the same basic block: /* Set up in flow.c; empty before then. Holds a chain of INSN_LIST rtx's whose first operands point at previous insns with direct data-flow connections to this one. That means that those insns set variables whose next use is in this insn. They are always in the same basic block as this insn. */ #define LOG_LINKS(INSN) XEXP(INSN, 7) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19579
[Bug regression/19174] wrong code regression or library problem in gcc-4.0-20041226
--- Additional Comments From andre dot maute at gmx dot de 2005-01-24 10:42 --- It looks like it is fixed now Compiling gcc-4.0-20050123 with a gcc-4.0-20050116, which has the architecture option disabled, works. Great! Regards Andre -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19174
[Bug libstdc++/8670] Alignment problem in std::basic_string
-- What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8670
[Bug rtl-optimization/13712] Executable runs 25% slower than when compiled with INTEL compiler
--- Additional Comments From uros at kss-loka dot si 2005-01-24 11:16 --- (In reply to comment #14) Where are we standing with this one today? gcc version 4.0.0 20050124 (experimental) g++ -O3 -ffast-math y.cc real0m27.102s user0m26.980s sys 0m0.016s g++ -O3 -ffast-math -D__NO_MATH_INLINES y.cc real0m23.484s user0m23.307s sys 0m0.076s g++ -O3 -march=pentium4 -ffast-math -D__NO_MATH_INLINES y.cc real0m23.101s user0m23.014s sys 0m0.078s g++ -O3 -march=pentium4 -mfpmath=sse -ffast-math -D__NO_MATH_INLINES y.cc real0m31.650s user0m31.605s sys 0m0.025s g++ -O3 -march=pentium4 -mfpmath=sse -ffast-math y.cc real0m29.068s user0m28.863s sys 0m0.023s g++ -O3 -march=pentium4 -mfpmath=sse y.cc real0m35.343s user0m34.848s sys 0m0.047s g++ -O3 -march=pentium4 -mfpmath=sse -ffast-math -mno-80387 -D__NO_MATH_INLINES y.cc *** FAILED: X422 = nan *** real2m56.700s user2m55.615s sys 0m0.145s g++ -O3 -march=pentium4 -mfpmath=sse -mno-80387 -D__NO_MATH_INLINES y.cc *** TIMEOUT AFTER 3min *** -mfpmath=sse runs a bit slow. -mno-80387 IMHO generates wrong code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13712
[Bug rtl-optimization/15853] [3.3 Regression] temporaries are not destroyed and overwritten later
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-24
11:27 ---
Um... first of all, this works on 3.4 branch only by accident, i.e. I think the
underlying problem is still present there. What happens is that a call has an
argument containing a TARGET_EXPR with cleanups and is eligible for the sibling
call optimization. The cleanups are expanded during the first pass but, since
the optimization eventually fails, the RTL is thrown away. Then, during the
second pass, the TARGET_EXPR is expanded again but not the cleanups because they
are not registered (the variable 'cleanups' is NULL at expr.c:9050).
I'm not sure how this is supposed to work. Richard, do you have any
recollection of this? In 2000(!), you commited this patch:
Index: calls.c
===
RCS file: /cvs/gcc/gcc/gcc/calls.c,v
retrieving revision 1.97
retrieving revision 1.98
diff -u -r1.97 -r1.98
--- calls.c 17 Mar 2000 22:40:43 - 1.97
+++ calls.c 20 Mar 2000 22:40:50 - 1.98
@@ -2020,7 +2020,8 @@
safe_for_reeval = 0;
if (optimize = 2
currently_expanding_call == 1
- stmt_loop_nest_empty ())
+ stmt_loop_nest_empty ()
+ ! any_pending_cleanups (1))
{
/* Verify that each argument is safe for re-evaluation. */
for (p = actparms; p; p = TREE_CHAIN (p))
@@ -2152,6 +2153,12 @@
|| ! FUNCTION_OK_FOR_SIBCALL (fndecl))
continue;
+ /* We know at this point that there are not currently any
+pending cleanups. If, however, in the process of evaluating
+the arguments we were to create some, we'll need to be
+able to get rid of them. */
+ expand_start_target_temps ();
+
/* State variables we need to save and restore between
iterations. */
save_pending_stack_adjust = pending_stack_adjust;
@@ -2925,6 +2932,14 @@
if (args[i].aligned_regs)
free (args[i].aligned_regs);
+ if (pass == 0)
+ {
+ /* Undo the fake expand_start_target_temps we did earlier. If
+there had been any cleanups created, we've already set
+sibcall_failure. */
+ expand_end_target_temps ();
+ }
+
insns = get_insns ();
end_sequence ();
which is responsible for expanding the cleanups right after the first pass.
--
What|Removed |Added
CC||rth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15853
[Bug rtl-optimization/19579] [3.3/3.4/4.0 regression] -march=i686 generates a bogus program for x86*
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-01-23 21:14:58 |2005-01-24 11:30:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19579
[Bug c++/19603] New: code generation error
gcc CVS mainline, 2005/01/23 12:10 PST
Configured with: /net/legless/scratch1/rwgk/gcc_cvs_head/configure --
prefix=/usr/local_cci/gcc_cvs_head_20050123 --enable-languages=c,c++
Red Hat Enterprise Linux WS release 3 (Taroon)
Boost CVS mainline, 2005/01/06 10:09 PST
The following piece of code works correctly only if CCTBX_GCC4_WORKAROUND is
defined:
rt_mx rt_mx::new_denominators(int r_den, int t_den) const
{
rt_mx result(*this);
#ifndef CCTBX_GCC4_WORKAROUND
if (r_den) result.r_ = result.r_.new_denominator(r_den);
#else
if (r_den) {
rot_mx r = result.r_.new_denominator(r_den);
result.r_ = r;
}
#endif
if (t_den) result.t_ = result.t_.new_denominator(t_den);
return result;
}
A reproducer is available here:
http://cci.lbl.gov/~rwgk/bugs/gcc_cvs_head_20050123/gcc4_debug.tar.gz
To build:
gunzip -c gcc4_debug.tar.gz | tar xf -
cd gcc4_debug
make
Expected output:
g++ -fPIC -ftemplate-depth-120 -w -DBOOST_DISABLE_THREADS -DNDEBUG -O3 -ffast-
math -I. -c gcc4_debug.cpp
g++ -fPIC -ftemplate-depth-120 -w -DBOOST_DISABLE_THREADS -DNDEBUG -O3 -ffast-
math -I. -c cctbx.cpp -o cctbx_normal.o
g++ -o normal gcc4_debug.o cctbx_normal.o
g++ -fPIC -ftemplate-depth-120 -w -DBOOST_DISABLE_THREADS -DNDEBUG -O3 -ffast-
math -I. -DCCTBX_GCC4_WORKAROUND -c cctbx.cpp -o cctbx_hacked.o
g++ -o hacked gcc4_debug.o cctbx_hacked.o
This will only take a few seconds to build the commands normal and hacked.
The expected output is:
./normal
y,z,x
x,y,z
./hacked
y,z,x
y,z,x
The output of ./normal is wrong, the output of ./hacked is correct. The only
difference is the CCTBX_GCC4_WORKAROUND.
The same code works fine (without the workaround) with gcc 3.2.3 and many other
compilers.
I will try to attach the reproducer if possible. It still is 877kB in size,
starting from 15+MB, mainly because of the Boost headers. I spent several hours
stripping it down to this size. I hope you have tools to reduce the rest much
faster.
--
Summary: code generation error
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rwgk at yahoo 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=19603
[Bug c++/19603] code generation error
--- Additional Comments From rwgk at yahoo dot com 2005-01-24 11:49 --- Created an attachment (id=8052) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8052action=view) Reproducer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19603
[Bug bootstrap/18058] [4.0 Regression] Sun CC cannot bootstrap GCC (static inline)
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-24 12:08 --- Subject: Bug 18058 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-24 12:08:07 Modified files: gcc: ChangeLog genconditions.c Log message: PR bootstrap/18058 * genconditions.c (write_header, write_conditions): Elide file if not GCC = 3.0.1. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.7259r2=2.7260 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/genconditions.c.diff?cvsroot=gccr1=1.13r2=1.14 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18058
[Bug target/19593] ICE at build_def_use, at regrename.c:763
--- Additional Comments From joel at gcc dot gnu dot org 2005-01-24 12:11 --- (In reply to comment #3) Can you try 3.4.4? There is no 3.4.4 on gcc.gnu.org. Do you mean the head of the 3.4 branch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19593
[Bug bootstrap/18058] [4.0 Regression] Sun CC cannot bootstrap GCC (static inline)
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-24 12:20 --- Thanks Joseph! -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18058
[Bug middle-end/19583] [4.0 Regression] Incorrect diagnostic: control may reach end of non-void function '...' being inlined
--- Additional Comments From andre dot maute at gmx dot de 2005-01-24
12:27 ---
with the following the problem also does occur
-- O3Wall.cc ---
#include cmath
double test( double x ) {
return fabs(x);
}
-- O3Wall.cc ---
g++-4.0-20050123 O3Wall.cc -O3 -Wall -c
O3Wall.cc: In function 'double test(double)':
O3Wall.cc:4: warning: control may reach end of non-void function 'double
fabs(double)' being inlined
g++-4.0-20050123 -v
Using built-in specs.
Configured with: ../gcc-4.0-20050123/configure --prefix=/opt/gcc-4.0-20050123
--enable-shared --enable-languages=c,c++ --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --disable-nls
--program-suffix=-4.0-20050123 --disable-checking --with-arch=pentium3
Thread model: posix
gcc version 4.0.0 20050123 (experimental)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19583
[Bug middle-end/19583] [4.0 Regression] Incorrect diagnostic: control may reach end of non-void function '...' being inlined
--- Additional Comments From andre dot maute at gmx dot de 2005-01-24 12:30 --- oh sorry, i did not read the bug history :-( regards andre -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19583
[Bug target/19597] [4.0 Regression] avr-gcc 4.0, multiplication by constant, very long code
--- Additional Comments From bernie at develer dot com 2005-01-24 13:15 --- Subject: Re: [4.0 Regression] avr-gcc 4.0, multiplication by constant, very long code Bernardo Innocenti wrote: marekm at amelek dot gda dot pl wrote: --- Additional Comments From marekm at amelek dot gda dot pl 2005-01-24 09:24 --- Subject: Re: [4.0 Regression] avr-gcc 4.0, multiplication by constant, very long code On Mon, Jan 24, 2005 at 08:56:46AM -, giovannibajo at libero dot it wrote: Marek, can you review this patch please? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19597 Thanks. Reviewing this will take some time - I agree the current rtx costs are not perfect, but changing them can affect generated code in unexpected ways. It would be good to test it a lot on various test cases, to make sure it doesn't introduce new code size regressions... I'm building avr-gcc right now with your two patches and this one applied. I'll let you know shortly. Not good. With these two patches applied, the size of four big AVR applications increased slightly. These were built with -Os (the second one shows a minor improvement): textdata bss dec hex filename 8008 136 40185452161 images-orig/dspslave.elf 8032 136 40185692179 images-patched/dspslave.elf textdata bss dec hex filename 18448 536 692 196764cdc images-orig/dspmaster.elf 18428 536 692 196564cc8 images-patched/dspmaster.elf These with -O2: textdata bss dec hex filename 6045418321562 63848f968 images-orig/kfront.elf 6048818321562 63882f98a images-patched/kfront.elf textdata bss dec hex filename 36160 9001713 387739775 images-orig/kcntrl.elf 36344 9001713 38957982d images-patched/kcntrl.elf Would you like to see some diffs? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19597
[Bug rtl-optimization/19078] [4.0 Regression] Poor quality code after loop unrolling.
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni dot cz 2005-01-24 13:20 --- Subject: Re: [4.0 Regression] Poor quality code after loop unrolling. Zdenek, is this still a regression, or are your suggestions from comment #12 only enhancements? I think it still falls into regression cathegory (we produce worse code than 3.3); the suggestions would help overcome this problems, but they are either not nice or requiring large changes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19078
[Bug tree-optimization/19217] [4.0 Regression] ICE: verify_stmts failed: address taken, but ADDRESSABLE bit not set
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-24 13:24 --- (In reply to comment #8) I cannot reproduce this with the original test case and yesterday's CVS HEAD. Did you use --disable-checking (please look at the keywords)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19217
[Bug c++/19603] code generation error
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-24 13:27 --- *** This bug has been marked as a duplicate of 19317 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19603
[Bug c++/19317] [4.0 Regression] removing a temporary return value when we cannot
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-24 13:27 --- *** Bug 19603 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||rwgk at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19317
[Bug regression/19174] [4.0 Regression] wrong code regression or library problem in gcc-4.0-20041226
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-24 13:29 --- Fixed so lets close it. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Keywords||wrong-code Resolution||FIXED Summary|wrong code regression or|[4.0 Regression] wrong code |library problem in gcc-4.0- |regression or library |20041226|problem in gcc-4.0-20041226 Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19174
[Bug tree-optimization/19217] [4.0 Regression] ICE: verify_stmts failed: address taken, but ADDRESSABLE bit not set
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-24 13:43 --- This should be a checking compiler, or at least I didn't disable checking explicitly. I did use a non-gcc to build it, perhaps that turned off checking... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19217
[Bug bootstrap/19601] [4.0 Regression] make bootstrap-lean fails: insn-conditions.c:189: error: `flag_unsafe_math_optimizations' undeclared
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-24 13:50 --- I tried it last night on powerpc-darwin but I did not reproduce it. Some else will have to look into this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19601
[Bug c++/19569] no code for explicit instantiation of template class specialization
--- Additional Comments From jamesp at trdlnk dot com 2005-01-24 14:03 --- According to paragraph 7 of section 14.7.2 in the C++ standard, this is supposed to work as I described. I admit that the sample code I supplied doesn't show why this functionality is necessary, so I'll try to explain my motivation. I'm writing a library that defines a template class that is supposed to be specialized by client code. There is no default implementation for the template class member functions. I consider the implementation of the template class a detail related to this library and don't want to force the client to litter header files with these details. The header files for the library contain enough of the details to generate the necessary function calls properly without forcing the user to define the specialized template class member functions in a special location. My recommendation to the users is to define the specialization in a .cc file, explicitly extantiate the class, and link in the code as necessary rather than create special header files. In short, it's just a lot cleaner and easier for the clients to maintain. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19569
[Bug rtl-optimization/19579] [3.3/3.4/4.0 regression] -march=i686 generates a bogus program for x86*
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-24 14:13 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01713.html. -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19579
[Bug c++/19569] no code for explicit instantiation of template class specialization
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2005-01-24
14:27 ---
There is a defect report DR259 about this issue:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#259
According to the DR, the original standard mentions that
the instantiation:
template class Achar;
is invalid because there is already a specialization
template class Achar { ... };
declared earlier.
In the revised version of the standard, which includes the
resolution of this DR, the instantiation is ignored.
Recent GCC releases follow this behavior.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19569
[Bug c++/19604] New: vtable error with virtual inheritance and tables
I don't know if it's a bug in g++ or a lack in the specifications of C++ ... I define two classes, one inherited from the second. I allocate a table of the child, I give it to a fonction that waits for the parent class. Inside this function, when I try to access virtual functions of an element of the table other than the first, I get a segfault. It seems to be that in this function, the size of each element of the table is considered to be the one of the parent but not the one of the child. That induces a memory shift that segfault when trying to accessing the vtable ... Is there the size of the object inside the vtable ? -- Summary: vtable error with virtual inheritance and tables Product: gcc Version: 3.3.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: webmyster at addoc dot u-psud dot fr CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-pc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19604
[Bug c++/19569] no code for explicit instantiation of template class specialization
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-24 14:30 --- So this is not a bug, so closing. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19569
[Bug c++/19604] vtable error with virtual inheritance and tables
--- Additional Comments From webmyster at addoc dot u-psud dot fr 2005-01-24 14:31 --- Created an attachment (id=8053) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8053action=view) vtable error with virtual inheritance and tables This file shows two things : * the size of one element is different according to the context (parent class or child class) ; * this difference induce a segfault when trying to acces virtual function VirtualAdresse(). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19604
[Bug java/19295] [4.0 regression] Incorrect bytecode produced for bitwise AND
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-24 14:34 --- Subject: Bug 19295 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-24 14:34:20 Modified files: gcc/java : ChangeLog jcf-write.c libjava: ChangeLog Added files: libjava/testsuite/libjava.compile: PR19295.java Log message: PR java/19295 * jcf-write.c (generate_bytecode_insns): Conversions between integer types of the same precision shouldn't generate widening or narrowing conversion bytecodes. * testsuite/libjava.compile/PR19295.java: New test case. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/ChangeLog.diff?cvsroot=gccr1=1.1532r2=1.1533 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/jcf-write.c.diff?cvsroot=gccr1=1.159r2=1.160 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gccr1=1.3292r2=1.3293 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/testsuite/libjava.compile/PR19295.java.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19295
[Bug c++/19604] vtable error with virtual inheritance and arrays
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-24 14:37 --- I think this is invalid and here is why? Basically the sizeof (A) is smaller than sizeof(B). But if you convert from B* to A* you cannot access the second element any more. -- What|Removed |Added Summary|vtable error with virtual |vtable error with virtual |inheritance and tables |inheritance and arrays http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19604
[Bug java/19295] [4.0 regression] Incorrect bytecode produced for bitwise AND
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-24 14:41 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19295
[Bug java/17574] [meta-bug] gcj and libgcj 4.0 tracking PR
-- Bug 17574 depends on bug 19295, which changed state. Bug 19295 Summary: [4.0 regression] Incorrect bytecode produced for bitwise AND http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19295 What|Old Value |New Value Status|NEW |ASSIGNED Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17574
[Bug c++/19605] New: Wrong member offset in inherited classes
gcc-4.0 returns incorrect class relative offsets for members
Following:
1. example program producing the error
2. console output for gcc 4.0 (incorrect) and gcc 3.2 (correct)
#include cstdio
#include iostream
#define GET_MEMBER_PTR(type,member) \
({\
void *type::*p = (void *type::*) type::member; \
(((type *) 0)-*p);\
})
using std::endl;
using std::cout;
class A
{
public:
unsigned a;
unsigned b;
};
class B
{
public:
unsigned c;
unsigned d;
};
class C
{
public:
unsigned e;
unsigned f;
};
class D : public A, public B, public C
{
public:
unsigned g;
unsigned h;
};
int
main(void)
{
cout a: GET_MEMBER_PTR(D, a) endl;
cout b: GET_MEMBER_PTR(D, b) endl;
cout c: GET_MEMBER_PTR(D, c) endl;
cout d: GET_MEMBER_PTR(D, d) endl;
cout e: GET_MEMBER_PTR(D, e) endl;
cout f: GET_MEMBER_PTR(D, f) endl;
cout g: GET_MEMBER_PTR(D, g) endl;
cout h: GET_MEMBER_PTR(D, h) endl;
return 0;
}
===
[EMAIL PROTECTED]:~/t5 /usr/local/gcc/head/bin/g++ -v
Using built-in specs.
Configured with: ../gcc/configure --prefix=/usr/local/gcc/head
--enable-__cxa_atexit
Thread model: posix
gcc version 4.0.0 20050123 (experimental)
[EMAIL PROTECTED]:~/t5 /usr/local/gcc/head/bin/g++ --static -o c.4.x c.cc
[EMAIL PROTECTED]:~/t5 ./c.4.x
a: 0
b: 0x4
c: 0
d: 0x4
e: 0
f: 0x4
g: 0x18
h: 0x1c
[EMAIL PROTECTED]:~/t5 g++-3.2 -v
Reading specs from /usr/lib/gcc-lib/i386-linux/3.2.3/specs
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f77,proto,objc,ada --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/include/c++/3.2 --enable-shared --with-system-zlib
--enable-nls --without-included-gettext --enable-__cxa_atexit
--enable-clocale=gnu --enable-java-gc=boehm --enable-objc-gc i386-linux
Thread model: posix
gcc version 3.2.3
[EMAIL PROTECTED]:~/t5 g++-3.2 -o c.3.x c.cc
[EMAIL PROTECTED]:~/t5 ./c.3.x
a: 0
b: 0x4
c: 0x8
d: 0xc
e: 0x10
f: 0x14
g: 0x18
h: 0x1c
--
Summary: Wrong member offset in inherited classes
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: peter at os dot inf dot tu-dresden dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19605
[Bug c++/19604] vtable error with virtual inheritance and arrays
--- Additional Comments From webmyster at addoc dot u-psud dot fr 2005-01-24 14:53 --- (In reply to comment #2) I think this is invalid and here is why? Basically the sizeof (A) is smaller than sizeof(B). But if you convert from B* to A* you cannot access the second element any more. I'm agree it's not a conventional use of inheritance and tables. But it may be valid. Where could I find the C++ specifications used to implement g++, to get a valid solution to my problem ? Moreover, I would like to have a warning during the compilation. I think the compiler can warning on each call of non first element of a table of classes containing vtable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19604
[Bug c++/19569] no code for explicit instantiation of template class specialization
--- Additional Comments From jamesp at trdlnk dot com 2005-01-24 14:55 --- It seems that paragraph 5 of 14.7.3 explains what I should have been doing. Sorry for the mix-up. James -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19569
[Bug c++/19605] Wrong member offset in inherited classes
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-24 14:56 --- (((type *) 0)-*p); That is not offsetof any more. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19605
[Bug c++/19605] [4.0 Regression] Wrong member offset in inherited classes
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-24 15:02 --- Someone else has to say if this is valid C++ but I think it is just undefined but I could be wrong. -- What|Removed |Added Keywords||wrong-code Summary|Wrong member offset in |[4.0 Regression] Wrong |inherited classes |member offset in inherited ||classes Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19605
[Bug c++/19605] [4.0 Regression] Wrong member offset in inherited classes
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-24 15:04 --- Also one note is that 3.4.0 produces the same as 3.2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19605
[Bug c++/19605] [4.0 Regression] Wrong member offset in inherited classes
--- Additional Comments From fm3 at os dot inf dot tu-dresden dot de 2005-01-24 15:12 --- added myself as cc -- What|Removed |Added CC||fm3 at os dot inf dot tu- ||dresden dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19605
[Bug java/19505] Java bytecode ICE in except.c remove_unreachable_regions
-- What|Removed |Added Keywords||ice-on-valid-code Last reconfirmed|2005-01-19 12:11:08 |2005-01-24 15:24:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19505
[Bug middle-end/19606] New: wrong code for arith.expr: (((unsigned int)(signed int) a ) / 2LL) with signed char a=-4
The value of test should be 0x7ffe and is 0xfffe;
Flags: none
(Also in 3.3.5)
#include stdio.h
signed char a=-4;
int test(){
return (((unsigned int)(signed int) a ) / 2LL) ;
}
int main(void){
int r;
r=test();
printf(test output: %#x == %d %x %x\n,r,r
,(r==0x7ffe),(r==0xfffe));
if(r == ( ((unsigned int)(signed int) (signed char) -4 ) / 2LL ))
printf(test successful\n);
else
printf(test failed\n);
return 0;
}
--
Summary: wrong code for arith.expr: (((unsigned int)(signed int)
a ) / 2LL) with signed char a=-4
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: heinrich dot brand at fujitsu-siemens dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: Intel-Linux
GCC host triplet: Intel-Linux
GCC target triplet: Intel-Linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19606
[Bug middle-end/19606] wrong code for arith.expr: (((unsigned int)(signed int) a ) / 2LL) with signed char a=-4
--- Additional Comments From falk at debian dot org 2005-01-24 16:20 --- Confirmed on alpha-linux. Has been broken since at least 2.95. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||wrong-code Known to fail||2.95.3 3.3.3 3.4.3 4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19606
[Bug target/19528] [4.0 regression] missing ra.h
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-24 16:21 --- Fixed by: 2005-01-24 Jorn Rennecke [EMAIL PROTECTED] * sh.c (ra.h): Don't #include. (hard_regs_intersect_p): New function, resurrected from ra.c. * sh.c: Fix 1996 Copyright. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19528
[Bug bootstrap/18974] error in compiling gcc 4.0 for i686-pc-linux-gnu: gengtype-lex.c
--- Additional Comments From brett dot albertson at stratech dot com
2005-01-24 16:23 ---
I think I'm seeing the same problem on Sparc Solaris without bison on the 4.0
bootstrap.
gcc -c -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE-I. -Ibuild
-I/var/tmp/gcc-4.0-20050123/gcc -I/var/tmp/gcc-4.0-20050123/gcc/build
-I/var/tmp/gcc-4.0-20050123/gcc/../include -I./../intl
-I/var/tmp/gcc-4.0-20050123/gcc/../libcpp/include \
-o build/gengtype.o /var/tmp/gcc-4.0-20050123/gcc/gengtype.c
flex -ogengtype-lex.c /var/tmp/gcc-4.0-20050123/gcc/gengtype-lex.l
/var/tmp/gcc-4.0-20050123/missing bison -d -o gengtype-yacc.c
/var/tmp/gcc-4.0-20050123/gcc/gengtype-yacc.y
WARNING: `bison' missing on your system. You should only need it if
you modified a `.y' file. You may need the `Bison' package
in order for those modifications to take effect. You can get
`Bison' from any GNU archive site.
gcc -c -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-fno-common -Wno-error -DHAVE_CONFIG_H -DGENERATOR_FILE-I. -Ibuild
-I/var/tmp/gcc-4.0-20050123/gcc -I/var/tmp/gcc-4.0-20050123/gcc/build
-I/var/tmp/gcc-4.0-20050123/gcc/../include -I./../intl
-I/var/tmp/gcc-4.0-20050123/gcc/../libcpp/include \
-o build/gengtype-lex.o gengtype-lex.c
/var/tmp/gcc-4.0-20050123/gcc/gengtype-lex.l:31:27: gengtype-yacc.h: No such
file or directory
/var/tmp/gcc-4.0-20050123/gcc/gengtype-lex.l: In function `yylex':
/var/tmp/gcc-4.0-20050123/gcc/gengtype-lex.l:220: error: `yylval' undeclared
(first use in this function)
/var/tmp/gcc-4.0-20050123/gcc/gengtype-lex.l:220: error: (Each undeclared
identifier is reported only once
/var/tmp/gcc-4.0-20050123/gcc/gengtype-lex.l:220: error: for each function it
appears in.)
/var/tmp/gcc-4.0-20050123/gcc/gengtype-lex.l:225: error: `ENT_TYPEDEF_STRUCT'
undeclared (first use in this function)
/var/tmp/gcc-4.0-20050123/gcc/gengtype-lex.l:225: error: `ENT_STRUCT' undeclared
(first use in this function)
/var/tmp/gcc-4.0-20050123/gcc/gengtype-lex.l:231: error: `ENT_EXTERNSTATIC'
undeclared (first use in this function)
/var/tmp/gcc-4.0-20050123/gcc/gengtype-lex.l:237: error: `ENT_YACCUNION'
undeclared (first use in this function)
/var/tmp/gcc-4.0-20050123/gcc/gengtype-lex.l:280: error: `GTY_TOKEN' undeclared
(first use in this function)
/var/tmp/gcc-4.0-20050123/gcc/gengtype-lex.l:281: error: `UNION' undeclared
(first use in this function)
/var/tmp/gcc-4.0-20050123/gcc/gengtype-lex.l:282: error: `STRUCT' undeclared
(first use in this function)
/var/tmp/gcc-4.0-20050123/gcc/gengtype-lex.l:283: error: `ENUM' undeclared
(first use in this function)
/var/tmp/gcc-4.0-20050123/gcc/gengtype-lex.l:284: error: `ALIAS' undeclared
(first use in this function)
/var/tmp/gcc-4.0-20050123/gcc/gengtype-lex.l:285: error: `NESTED_PTR' undeclared
(first use in this function)
/var/tmp/gcc-4.0-20050123/gcc/gengtype-lex.l:286: error: `NUM' undeclared (first
use in this function)
/var/tmp/gcc-4.0-20050123/gcc/gengtype-lex.l:289: error: `PARAM_IS' undeclared
(first use in this function)
/var/tmp/gcc-4.0-20050123/gcc/gengtype-lex.l:301: error: `SCALAR' undeclared
(first use in this function)
/var/tmp/gcc-4.0-20050123/gcc/gengtype-lex.l:323: error: `ID' undeclared (first
use in this function)
/var/tmp/gcc-4.0-20050123/gcc/gengtype-lex.l:333: error: `STRING' undeclared
(first use in this function)
/var/tmp/gcc-4.0-20050123/gcc/gengtype-lex.l:337: error: `ARRAY' undeclared
(first use in this function)
/var/tmp/gcc-4.0-20050123/gcc/gengtype-lex.l:341: error: `PERCENT_ID' undeclared
(first use in this function)
/var/tmp/gcc-4.0-20050123/gcc/gengtype-lex.l:345: error: `CHAR' undeclared
(first use in this function)
/var/tmp/gcc-4.0-20050123/gcc/gengtype-lex.l:361: error: `PERCENTPERCENT'
undeclared (first use in this function)
gengtype-lex.c: In function `yy_get_next_buffer':
gengtype-lex.c:2623: warning: old-style parameter declaration
gengtype-lex.c: In function `yy_get_previous_state':
gengtype-lex.c:2755: warning: old-style parameter declaration
gengtype-lex.c: In function `input':
gengtype-lex.c:2868: warning: old-style parameter declaration
make[2]: *** [build/gengtype-lex.o] Error 1
make[2]: Leaving directory `/var/tmp/gcc-4.0-bin/gcc'
make[1]: *** [stage1_build] Error 2
make[1]: Leaving directory `/var/tmp/gcc-4.0-bin/gcc'
make: *** [bootstrap] Error 2
dev-null:{root}#
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18974
[Bug bootstrap/18974] error in compiling gcc 4.0 for i686-pc-linux-gnu: gengtype-lex.c
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-24 16:28 --- Actually if you are compiling from source from a snapshot you need both bison and flex. This is invalid. -- What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18974
[Bug tree-optimization/19505] [4.0 Regression] Java bytecode ICE in except.c remove_unreachable_regions
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-24 16:34 --- Just a little more information. changing s = redirect_edge_succ_nodup (e, dest); to a return false; in remove_forwarder_block makes this pass so this is a tree optimization problem. Basically what is happening is that we are forwarding two eh regions to one bb which is just wrong. A better check in remove_forwarder_block is needed to better test for this case. Note this only happens with the java front-end because the java front-end produces a goto from two catches without any code before it (which is not wrong). Making this block 17574 which is the meta-bug for java bugs which should be fixed before 4.0 (or are just regressions in 4.0). -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org OtherBugsDependingO||17574 nThis|| Component|java|tree-optimization Summary|Java bytecode ICE in|[4.0 Regression] Java |except.c|bytecode ICE in except.c |remove_unreachable_regions |remove_unreachable_regions http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19505
[Bug middle-end/19606] wrong code for arith.expr: (((unsigned int)(signed int) a ) / 2LL) with signed char a=-4
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-24 16:41 --- Also on powerpc-darwin. -- What|Removed |Added GCC build triplet|Intel-Linux | GCC host triplet|Intel-Linux | GCC target triplet|Intel-Linux | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19606
template inheritance bug in gcc 3.4.3 ?
1. bash-2.05b$ gcc -v
Reading specs from /usr/lib/gcc/i486-pc-linux-gnu/3.4.3/specs
Configured with: /var/tmp/portage/gcc-3.4.3-r1/work/gcc-3.4.3/configure
--enable-version-specific-runtime-libs --prefix=/usr
--bindir=/usr/i486-pc-linux-gnu/gcc-bin/3.4.3
--includedir=/usr/lib/gcc/i486-pc-linux-gnu/3.4.3/include
--datadir=/usr/share/gcc-data/i486-pc-linux-gnu/3.4.3
--mandir=/usr/share/gcc-data/i486-pc-linux-gnu/3.4.3/man
--infodir=/usr/share/gcc-data/i486-pc-linux-gnu/3.4.3/info
--with-gxx-include-dir=/usr/lib/gcc/i486-pc-linux-gnu/3.4.3/include/g
++-v3 --host=i486-pc-linux-gnu --disable-altivec --enable-nls
--without-included-gettext --enable-__cxa_atexit --enable-clocale=gnu
--with-system-zlib --disable-checking --disable-werror
--disable-libunwind-exceptions --enable-shared --enable-threads=posix
--disable-libgcj --enable-languages=c,c++,f77
Thread model: posix
gcc version 3.4.3 20041125 (Gentoo Linux 3.4.3-r1, ssp-3.4.3-0,
pie-8.7.7)
2. source file (1.cc):
template class T class C1 {
public:
C1() {}
virtual ~C1() {}
protected:
T* m_prop;
};
template class T class C2 : public C1T {
public:
C2() {}
void A() { m_prop = (T*)0; }
virtual ~C2() {}
};
int main() {
C2int a;
return 0;
}
3. 1.ii
# 1 1.cc
# 1 built-in
# 1 command line
# 1 1.cc
template class T class C1 {
public:
C1() {}
virtual ~C1() {}
protected:
T* m_prop;
};
template class T class C2 : public C1T {
public:
C2() {}
void A() { m_prop = (T*)0; }
virtual ~C2() {}
};
int main() {
C2int a;
return 0;
}
4. compilation result:
bash-2.05b$ g++ --save-temps 1.cc
1.cc: In member function `void C2T::A()':
1.cc:12: error: `m_prop' undeclared (first use this function)
1.cc:12: error: (Each undeclared identifier is reported only once for
each function it appears in.)
5. ??workaround?? if i use explicit scoping { C1T::m_prop = ... } all
is ok.
--
, ,
. +7(8634)311562 225
mailto: [EMAIL PROTECTED]
signature.asc
Description: =?koi8-r?Q?=FC=D4=C1?= =?koi8-r?Q?_=DE=C1=D3=D4=D8?= =?koi8-r?Q?_=D3=CF=CF=C2=DD=C5=CE=C9=D1?= =?koi8-r?Q?_=D0=CF=C4=D0=C9=D3=C1=CE=C1?= =?koi8-r?Q?_=C3=C9=C6=D2=CF=D7=CF=CA?= =?koi8-r?Q?_=D0=CF=C4=D0=C9=D3=D8=C0?=
[Bug bootstrap/16024] gengtype crashes with mingw and c++ extension
--- Additional Comments From guardia at sympatico dot ca 2005-01-24 17:20 --- I think the relative path issue with MSYS and MinGW should be added for example in the notes at: http://gcc.gnu.org/install/specific.html It would save a lot of grief from people trying to build it on MSYS. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16024
[Bug bootstrap/19607] New: Build fails on MSYS/MingGW because of incorrect SYSTEM_HEADER_DIR
On MSYS, the system headers are found in /mingw/include ... I made a modified gcc/config/i386/t-mingw32 adding: NATIVE_SYSTEM_HEADER_DIR = /mingw/include And it works here. Also, the configure script needs to be started with a relative path or the srcdir anyway needs to be relative or gengtype will fail. This problem is documented in bug #16024 (gengtype doesn't crash here, but it still fails not finding a path) -- Summary: Build fails on MSYS/MingGW because of incorrect SYSTEM_HEADER_DIR Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: guardia at sympatico dot ca CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-mingw32 GCC host triplet: i686-pc-mingw32 GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19607
[Bug bootstrap/19607] Build fails on MSYS/MingGW because of incorrect SYSTEM_HEADER_DIR
--- Additional Comments From guardia at sympatico dot ca 2005-01-24 17:31 --- Created an attachment (id=8054) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8054action=view) new t-mingw32 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19607
[Bug target/17751] Undefined .LCTOC0 symbol
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-24 17:39 --- Subject: Bug 17751 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-01-24 17:39:37 Modified files: gcc: ChangeLog gcc/testsuite : ChangeLog gcc/config/rs6000: rs6000.c Added files: gcc/testsuite/gcc.dg: ppc64-toc.c Log message: PR target/17751 * config/rs6000/rs6000.c (rs6000_file_start): Create toc section for AIX ABI or ELF -fPIC. (rs6000_emit_load_toc_table): Don't create toc_section here. (rs6000_xcoff_file_start): Nor here. * gcc.dg/ppc64-toc.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.7262r2=2.7263 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.4930r2=1.4931 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000.c.diff?cvsroot=gccr1=1.781r2=1.782 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/ppc64-toc.c.diff?cvsroot=gccr1=1.1r2=1.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17751
[Bug c++/19538] Missing diagnostic for typedef name in elaborated type specifier
--- Additional Comments From austern at apple dot com 2005-01-24 18:06 --- I've raised this issue on the C++ standardization committee's core language reflector. I now find it a little less clear than I did before. This is closely related to open issue 407. See http://www.open- std.org/jtc1/sc22/wg21/docs/cwg_active.html#407 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19538
[Bug c++/11036] typedef-name used in an elaborated-type-specifier is incorrectly accepted
--- Additional Comments From austern at apple dot com 2005-01-24 18:06 --- I've raised this issue on the C++ standardization committee's core language reflector. I now find it a little less clear than I did before. This is closely related to open issue 407. See http://www.open- std.org/jtc1/sc22/wg21/docs/cwg_active.html#407 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11036
[Bug target/19530] MMX load intrinsic produces SSE superfluous instructions (movlps)
--- Additional Comments From guardia at sympatico dot ca 2005-01-24 18:09 --- MMX intrinsics don't seem to be a standard (?), but I'm under the impression that _mm_cvtsi32_si64 is supposed to generate MMX code. I just tested With (GCC) 4.0.0 20050123, and with -mmmx flag, the result is still the same, with the -msse flag I now get : movss 12(%ebp), %xmm0 movlps %xmm0, (%eax) Which is correct, but what I'm trying to get is a MOVD so I don't have to fish back into memory to use the integer I wanted to load in an mmx register. Or is there another way to generate a MOVD? Also, _mm_unpacklo_pi8 (check moo2.i) still generates superfluous movlps : punpcklbw %mm0, %mm0 movl%esp, %ebp subl$8, %esp movl8(%ebp), %eax movq%mm0, -8(%ebp) movlps -8(%ebp), %xmm1 movlps %xmm1, (%eax) I guess any MMX intrinsics that makes use of the (__m64) cast conversion will suffer from the same problem. I think the fix to all these problems would be to prevent the register allocator from using SSE registers when compiling MMX intrinsics.. ? -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19530
[Bug rtl-optimization/17387] Redundant instructions in loop optimization
--- Additional Comments From hjl at lucon dot org 2005-01-24 18:17 --- Looking at the mainline result, I still see mov %eax, %eax, which was the original bug report for mainline. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17387
[Bug target/19520] protected function pointer doesn't work right
--- Additional Comments From hjl at lucon dot org 2005-01-24 18:35 --- This is the updated patch: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01551.html This is the testcase patch: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01550.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520
[Bug target/19558] openssl speed compiled with 20051020 gcc-4.0 (HEAD) segfaults
--- Additional Comments From gj at pointblue dot com dot pl 2005-01-24 18:47 --- sorry, still happends on amd64. I don't have intel 32bit platorm to test it on. I can only say it works fine on 32bit compiled openss for sparc. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19558
[Bug target/13018] -mminimal-toc breaks at -O0
-- What|Removed |Added Target Milestone|tree-ssa|4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13018
[Bug rtl-optimization/17387] Redundant instructions in loop optimization
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-24 18:52 --- Confirmed again. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|2004-11-27 20:49:43 |2005-01-24 18:52:13 date|| Target Milestone|4.0.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17387
[Bug target/19558] openssl speed compiled with 20051020 gcc-4.0 (HEAD) segfaults
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-24 19:00 --- .align 16 \n This is the bug but it is not in gcc, either it is in binutils or in the source, not in gcc since gcc just outputs the assembly instruction aka it just copies and pastes. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19558
[Bug c++/19608] New: ICE after friend function definition in local class
bash-2.05b$ cat friend.c
void f ()
{
class c
{
friend void g () { }
};
}
bash-2.05b$ ./cc1plus friend.c
void f()
friend.c:5: error: can't define friend function g in a local class definition
void g()
friend.c: At global scope:
friend.c:6: 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.
bash-2.05b$ ./cc1plus --version
GNU C++ version 4.0.0 20050124 (experimental) (sh-elf)
compiled by GNU C version 3.2.3 20030502 (Red Hat Linux 3.2.3-42).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
I gte the same error with an i686-targted compiler from an August snapshot.
--
Summary: ICE after friend function definition in local class
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: minor
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19608
[Bug c++/19608] [3.4/4.0 Regression] ICE after friend function definition in local class
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-24 19:30 --- : Search converges between 2003-03-23-trunk (#215) and 2003-03-30-trunk (#216). Confirmed. A regression from 3.3.3. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||error-recovery Known to fail||3.4.0 4.0.0 Known to work||3.3.3 Last reconfirmed|-00-00 00:00:00 |2005-01-24 19:30:24 date|| Summary|ICE after friend function |[3.4/4.0 Regression] ICE |definition in local class |after friend function ||definition in local class Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19608
[Bug middle-end/19609] New: real and imaginary part interchanged when flags_complex_divide_method=1
I've bootstrapped a gcc tree with the fix for PR 19486 and
flags_complex_divide_method=1 , and found that the code now
confuses the real and complex parts for divisions in certain
cases.
Here's an example:
$ cat complex-a.c
#include stdlib.h
#include stdio.h
#include math.h
#include complex.h
int main()
{
complex float a,b,c;
a = I;
b = I;
c = a/b;
printf(%f + %f*I\n,crealf(c),cimagf(c));
return 0;
}
$ gcc complex-a.c
$ ./a.out
0.00 + 1.00*I
--
Summary: real and imaginary part interchanged when
flags_complex_divide_method=1
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19609
[Bug middle-end/19609] real and imaginary part interchanged when flags_complex_divide_method=1
-- What|Removed |Added OtherBugsDependingO||18902 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19609
[Bug middle-end/19609] real and imaginary part interchanged when flags_complex_divide_method=1
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-24 20:00 --- Added rth to the CC list, added keyword. -- What|Removed |Added CC||rth at gcc dot gnu dot org Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19609
[Bug libfortran/19451] Read after a write with a read only file
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-24 20:03 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19451
[Bug target/19492] can not build crosscompiler for solaris2.8 (when building libstdc++ - error wcslen...:Link tests are not allowed after GCC_NO_EXECUTABLES)
--- Additional Comments From yiye242 at hotmail dot com 2005-01-24 20:07 --- (In reply to comment #9) Andrew, any comments?.. Have you tried this??? http://lists.resellerhostingbox.com/redhat-archive/msg21.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19492
[Bug c++/19610] New: default constructor not called for static template member of template class
I've run into a problem where a static template member of a template class is
not being created properly.
--- Begin Sample Code ---
#include iostream
using namespace std;
template typename T
class A
{
public:
A() { cout A created endl; }
};
template typename T
class AA
{
public:
AA( int i = 0 ) { cout AA i created endl; }
};
template typename T
class B
{
public:
static AT a;
static AAT aa;
static AAT aa2;
};
template Achar Bchar::a;
template AAchar Bchar::aa;
template AAchar Bchar::aa2(1);
int main() { }
--- End Sample Code ---
When I run the above sample, I get the following:
%g++ -Wall test.cc
%./a.out
AA 1 created
%
I expected all three of class B's static template members to be constructed. It
seems that the problem occurs whether it should have called a regular default
constructor or a conversion constructor with a default parameter. The fact that
B is a template class also seems to play some role in this. I tried another
example where B was a non-template class and everything constructed properly.
--
Summary: default constructor not called for static template
member of template class
Product: gcc
Version: 3.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jamesp at trdlnk dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19610
[Bug libgcj/19611] New: create 'sources.zip' for use in eclipse
It would be handy for the libgcj build to create a 'sources.zip' holding all the sources to libgcj. Eclipse could then use this to let the user easily view core library sources. Perhaps this could be optional so that it isn't built by default; not everybody cares about this. -- Summary: create 'sources.zip' for use in eclipse Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tromey 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=19611
[Bug libgcj/19612] New: gjdoc in libgcj
It would be good to incorporate gjdoc into libgcj. First, it would make our system more complete. second, it would make it simpler for us to generate javadoc pages at release time (and install them on gcc.gnu.org -- we ought to do this). One wrinkle is that gjdoc is GPL. Perhaps some segregation in the libjava directory would be in order. -- Summary: gjdoc in libgcj Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tromey 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=19612
[Bug target/19558] openssl speed compiled with 20051020 gcc-4.0 (HEAD) segfaults
--- Additional Comments From gj at pointblue dot com dot pl 2005-01-24 20:37 --- so if it is binutils, how do you explain that gcc 3.3.5 got that right, and it isnt' ok with 4.0 ? I have the very same version of binutils in both cases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19558
[Bug libfortran/19596] eor generates false error message with advance='NO'
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-24 20:37 --- Two cases for the same error. Thomas *** This bug has been marked as a duplicate of 19595 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19596
[Bug libfortran/19595] eor and advance=yes should not mix
--- Additional Comments From Thomas dot Koenig at online dot de 2005-01-24 20:37 --- *** Bug 19596 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19595
[Bug c++/19610] default constructor not called for static template member of template class
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-24 20:38 --- I think this is invalid because you are just specializing them and nothing else (note the aa2 can be done the non specialized way too but I showed the specialized way): // declare space for them templatetypename T AT BT::a; templatetypename T AAT BT::aa; //specialize Bchar::aa2 template AAchar Bchar::aa2(1); //instantiate them template Achar Bchar::a; template AAchar Bchar::aa; template AAchar Bchar::aa2; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19610
[Bug libgcj/19612] gjdoc in libgcj
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-24 20:40 --- Confirmed. -- What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-24 20:40:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19612
[Bug libgcj/19611] create 'sources.zip' for use in eclipse
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-24 20:40 --- Confirmed. -- What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-24 20:40:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19611
[Bug target/19492] can not build crosscompiler for solaris2.8 (when building libstdc++ - error wcslen...:Link tests are not allowed after GCC_NO_EXECUTABLES)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-24 20:41 --- Not a bug explained by that email. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19492
[Bug tree-optimization/18133] computed gotos are not folded back to regular gotos when it is found that they are not computed gotos at all
--- Additional Comments From law at redhat dot com 2005-01-24 20:46 ---
Subject: Re: computed gotos are not folded
back to regular gotos when it is found that they are not computed gotos
at
all
On Sun, 2005-01-23 at 21:09 +, kazu at cs dot umass dot edu wrote:
--- Additional Comments From kazu at cs dot umass dot edu 2005-01-23
21:09 ---
Here is another idea that would not compilicate the DOM.
That is, we can set up things so that the actual threading part will be
done by DOM.
Suppose we have a factored computed goto block like so:
# p_2 = PHI L0(0), L1(1), p_3(2);
# b_1 = PHI 3(0), 5(1), 4(2);
L2:;
... possibly some other statements ...
goto p_2;
Let's split this block like so:
# p_2 = PHI L0(0), L1(1), p_3(2);
# b_1 = PHI 3(0), 5(1), 4(2);
L2:;
... possibly some other statements ...
L3:; // fall through from L2.
goto p_2;
Note that we are still in SSA form without need for rewriting.
Now let's add a new PHI node and a new SWITCH_EXPR to L2 like so:
# p_2 = PHI L0(0), L1(1), p_3(2);
# b_1 = PHI 3(0), 5(1), 4(2);
# fac_1 = PHI 0(0), 1(1), 2(2);
L2:;
... possibly some other statements ...
switch (fac_1)
{
case 0: goto L0;- a threadable, normal edge
case 1: goto L1;- a threadable, normal edge
default: goto L3; - not threadable because p_3 is an SSA_NAME
}
L3:;
goto p_2;
That is, we create a new PHI node fac_1 so that we can build a
dispatch table using a SWITCH_EXPR.
Now it's easy for DOM to pick up the jump threading opportunities at
SWITCH_EXPR.
If you like, you can say that we reduce the factored computed goto
block to a SWITCH_EXPR.
Any thoughts?
Interesting approach. I'm not sure if your approach is easier
than just expanding the threading code to handle threading indirect
jumps.
I don't initially *think* that extending the threading code would be
all that difficult. In fact, all I think we need to do is update
the selection code to detect this case -- I think the code to update
the CFG and SSA graphs will DTRT without any changes.
Jeff
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18133
[Bug libgcj/19613] New: java.util.prefs should work like the JDK
The current java.util.prefs.Preferences.userRoot defaults to a memory-based back end. Instead we should have a file-based back end that default to reading from $HOME/.java/.userPrefs and is compatible with the JDK. -- Summary: java.util.prefs should work like the JDK Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tromey 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=19613
[Bug tree-optimization/18133] computed gotos are not folded back to regular gotos when it is found that they are not computed gotos at all
--- Additional Comments From kazu at cs dot umass dot edu 2005-01-24 20:56 --- Subject: Re: computed gotos are not folded back to regular gotos when it is found that they are not computed gotos at all Hi Jeff, Interesting approach. I'm not sure if your approach is easier than just expanding the threading code to handle threading indirect jumps. I don't initially *think* that extending the threading code would be all that difficult. In fact, all I think we need to do is update the selection code to detect this case -- I think the code to update the CFG and SSA graphs will DTRT without any changes. Some people do not want to see DOM getting bigger and bigger, so I just wanted to point out that there is an approach without making DOM any bigger, but then you're right. I don't think extending the jump threader is all that difficult or dirty, either. Either approach works for me. Kazu Hirata -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18133
[Bug libgcj/19527] libgij fails to install in a temporary directory
--- Additional Comments From tromey at gcc dot gnu dot org 2005-01-24 20:56 --- I believe this was fixed by this patch: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01702.html I haven't checked to verify it however. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19527
[Bug c++/19614] New: Excessive memory consumption
Processing the attached file causes g++ to consume about 1.4G of virtual memory on x86_64. The same file caused problems on x86 in an earlier release - see bug #15320. Also, on my project's mailing list I have seen the implication that similar issues exist on powerpc: http://www.cliftonlabs.com/savant/list-archives/savant-users/2004-December/13.html Please let me know if there is anything I can do to help sort this out. Here is the output of g++ -v: Reading specs from /usr/lib/gcc/x86_64-linux/3.4.4/specs Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr --libexecdir=/usr/lib --with-gxx-include-dir=/usr/include/c++/3.4 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --program-suffix=-3.4 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk --disable-werror x86_64-linux Thread model: posix gcc version 3.4.4 20041218 (prerelease) (Debian 3.4.3-7) -- Summary: Excessive memory consumption Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dmartin at cliftonlabs dot com CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19614
