[Bug target/10395] [x86] vector types are incorrectly aligned causing crash in multi-threaded apps or when using in main, plus other times

[uros at kss-loka dot si]

--- Additional Comments From uros at kss-loka dot si  2004-12-22 08:02 
---
FYI: glibc fix is here:
http://sources.redhat.com/ml/libc-hacker/2004-12/msg00068.html

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10395

[Bug c/19129] New: gcc-3.4.4 ICE while building libobjc

[namsh at kldp dot org]

I checkout the gcc-3.4 branch today and try to build.
xgcc generated ICE while it try to build libobjc.

I tried to change/remove the compile options.
And I found the ICE was caused by '-march=athlon-xp'.
If I change it to '-march=athlon', No ICE.

Here is ICE msg:
=
/home2/namsh/rpm/build/gcc/obj-athlon-redhat-linux/gcc/xgcc
-B/home2/namsh/rpm/build/gcc/obj-athlon-redhat-linux/gcc/
-B/usr/athlon-redhat-linux/bin/ -B/usr/athlon-redhat-linux/lib/ -isystem
/usr/athlon-redhat-linux/include -isystem /usr/athlon-redhat-linux/sys-include
-c -I. -I/home2/namsh/rpm/build/gcc/libobjc -O2 -W -Wall -Wwrite-strings
-Wstrict-prototypes -DHAVE_GTHR_DEFAULT -DIN_GCC -DIN_TARGET_LIBS
-I/home2/namsh/rpm/build/gcc/libobjc/objc
-I/home2/namsh/rpm/build/gcc/libobjc/../gcc
-I/home2/namsh/rpm/build/gcc/libobjc/../gcc/config -I../../gcc
-I/home2/namsh/rpm/build/gcc/libobjc/../include
/home2/namsh/rpm/build/gcc/libobjc/sendmsg.c  -fPIC -DPIC -march=athlon-xp -o
.libs/sendmsg.o
/home2/namsh/rpm/build/gcc/libobjc/sendmsg.c:42:1: warning: "rtx" redefined
In file included from /home2/namsh/rpm/build/gcc/libobjc/sendmsg.c:31:
/home2/namsh/rpm/build/gcc/libobjc/../gcc/coretypes.h:58:1: warning: this is the
location of the previous definition
/home2/namsh/rpm/build/gcc/libobjc/sendmsg.c: In function `objc_msg_sendv':
/home2/namsh/rpm/build/gcc/libobjc/sendmsg.c:269: error: insn does not satisfy
its constraints:
(insn 104 73 105 0 (set (mem:DI (plus:SI (reg/f:SI 6 bp)
(const_int -176 [0xff50])) [0 S8 A8])
(reg:DI 21 xmm0)) 59 {*movdi_2} (nil)
(nil))
/home2/namsh/rpm/build/gcc/libobjc/sendmsg.c:269: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:391
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

-- 
   Summary: gcc-3.4.4 ICE while building libobjc
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: namsh at kldp 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
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19129

[Bug ada/19128] Bug box while building asharp

[charlet at gcc dot gnu dot org]

--- Additional Comments From charlet at gcc dot gnu dot org  2004-12-22 
08:52 ---
There's nothing critical about this PR, please stop bumping its priority: it
won't magically fix it, thanks.

Arno

-- 
   What|Removed |Added

   Severity|critical|normal


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19128

[Bug target/16925] ICE when building a m68hc11 cross-compiler on 64-bit architectures

[aurelien at aurel32 dot net]

--- Additional Comments From aurelien at aurel32 dot net  2004-12-22 09:15 
---
   What|Removed |Added

  GCC build triplet|alphapca56-unknown-linux-gnu|
   GCC host triplet|alphapca56-unknown-linux-gnu|Any 64bit target (or really
   ||LP64)

I think it should rather be "Any 64bit host", as the target is "m68hc11"

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16925

[Bug target/18402] [3.3 regression] ICE in gen_split_1204 on i686-pc-linux-gnu target

[rgrosseboerger at dspace dot de]

--- Additional Comments From rgrosseboerger at dspace dot de  2004-12-22 
09:32 ---
I rated this bug critical, because it occurs with normal C code on a primary
platform. My testcase is from automatically generated code, so changing it is
quite difficult.
In the original PR (PR8555) Volker Reichelt rated the bug "high priority", so I
thought "critical" would be OK.

Apart from that, I submitted a patch which is almost identical to the patch in
PR8555 to [EMAIL PROTECTED]:
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01691.html

-- 
   What|Removed |Added

   Keywords||patch
Summary|[3.3 regression] ICE in in  |[3.3 regression] ICE in
   |gen_split_1204 on i686-pc-  |gen_split_1204 on i686-pc-
   |linux-gnu target|linux-gnu target


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18402

[Bug target/18898] [SH target], internal compiler error (ICE): for given code if using #pragma interrupt

[asgarij at kpitcummins dot com]

--- Additional Comments From asgarij at kpitcummins dot com  2004-12-22 
09:47 ---
Following patch removes the ice. Please review.

--- gcc-3.4-20040813/gcc/config/sh/sh.orig.c2004-12-08 10:55:41.0 
+0530
+++ gcc-3.4-20040813/gcc/config/sh/sh.c 2004-12-08 10:54:06.0 +0530
@@ -5565,7 +5565,7 @@ sh_expand_prologue (void)
   target_flags = save_flags;
 
   output_stack_adjust (-rounded_frame_size (d) + d_rounding,
-  stack_pointer_rtx, 0, NULL);
+  stack_pointer_rtx, 0, &live_regs_mask);
 
   if (frame_pointer_needed)
 frame_insn (GEN_MOV (frame_pointer_rtx, stack_pointer_rtx));

Regards,
Asgari Jinia
KPIT Cummins InfoSystems Ltd.
Pune, India

Free download of GNU based tool-chains for Renesas' SH and H8 
Series. The following site also offers free technical support 
to its users. 
Visit http://www.kpitgnutools.com for details. 
Latest versions of KPIT GNU tools are released on Oct 1, 2004. 




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18898

[Bug target/19102] [3.4 Regression] -march=pentium3 breaks linux kernel compiles w/ gcc-3_4-branch as of 2004/12/20

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-12-22 
11:27 ---
Introduced with:

2004-12-19  Richard Henderson  <[EMAIL PROTECTED]>

* config/i386/i386.c (ix86_hard_regno_mode_ok): Always accept all SSE,
MMX, 3DNOW modes in SSE registers; always accept all MMX, 3DNOW modes
in MMX registers.
* config/i386/i386.h (VALID_SSE2_REG_MODE): Don't include
VALID_MMX_REG_MODE.
* config/i386/i386.md (movv4sf_internal, movv4si_internal, 
movv2di_internal, movv2si_internal, movv4hi_internal,
movv2sf_internal, movv2df_internal, movv8hi_internal,
movv16qi_internal, movti_internal): Add leading '*' to name.
(movv2di_internal, movv2df_internal, movv8hi_internal,
movv16qi_internal, movv2df, movv8hi, movv16qi, movv2di,
pushv2di, pushv8hi, pushv16qi): Enable for SSE1.
(movv2si_internal, movv4hi_internal): Add SSE alternatives.
(movv8qi_internal, movv2sf_internal): Likewise.
(movtf): Simplify conditional.
(movv2sf, pushv2sf): Enable for MMX.


-- 
   What|Removed |Added

   Last reconfirmed|2004-12-21 12:22:41 |2004-12-22 11:27:44
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19102

[Bug target/19102] [3.4 Regression] -march=pentium3 breaks linux kernel compiles w/ gcc-3_4-branch as of 2004/12/20

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-12-22 
11:43 ---
Investigating.


-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ebotcazou at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19102

[Bug tree-optimization/19130] New: DSE not working?

[kazu at cs dot umass dot edu]

Consider:

int y;

void
foo (void)
{
  y = 0;
  y = 1;
}

I get:

foo ()
{
:
  y = 0;
  y = 1;
  return;

}

-- 
   Summary: DSE not working?
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P2
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19130

[Bug target/18019] [4.0 Regression] -march=pentium4 generates word fetch instead of byte fetch

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2004-12-22 
12:11 ---
One of these days, someone will have to explain to me how such a small
patch for a bug marked "critical regression" can stay unreviewed for
three days...  This kind of patches should *not* need pinging.




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18019

[Bug target/19102] [3.4 Regression] -march=pentium3 breaks linux kernel compiles w/ gcc-3_4-branch as of 2004/12/20

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-12-22 
12:24 ---
Why do we allow MMX modes in SSE regs now?  The following patchlet is sufficient
to fix the problem:

Index: config/i386/i386.c
===
RCS file: /cvs/gcc/gcc/gcc/config/i386/i386.c,v
retrieving revision 1.635.2.18
diff -u -p -r1.635.2.18 i386.c
--- config/i386/i386.c  20 Dec 2004 05:37:36 -  1.635.2.18
+++ config/i386/i386.c  22 Dec 2004 12:21:42 -
@@ -14931,9 +14931,7 @@ ix86_hard_regno_mode_ok (int regno, enum
  out of SSE registers, even when no operation instructions
  are available.  */
   return (VALID_SSE_REG_MODE (mode)
- || VALID_SSE2_REG_MODE (mode)
- || VALID_MMX_REG_MODE (mode)
- || VALID_MMX_REG_MODE_3DNOW (mode));
+ || VALID_SSE2_REG_MODE (mode));
 }
   if (MMX_REGNO_P (regno))
 {


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19102

[Bug tree-optimization/19108] [4.0 regression] ICE initializing arrays

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2004-12-22 
12:43 ---
Looks like fall-out from PR18191.  I'll try to take care of this.

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |steven at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2004-12-21 15:30:54 |2004-12-22 12:43:56
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19108

[Bug rtl-optimization/18401] [4.0.0 Regression] Bootstrap failure on all ARM targets due to incorrect GCSE

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2004-12-22 
13:03 ---
If only we had unit testing...

Richard, you think you can figure out when this problem *disappeared*?  Maybe
it was one of the many bitmaps changes, and there really is no GCSE bug.  If
there is a real GCSE bug, I would think we'd have found it much earlier.  But
if some unrelated patch fixed the bug, I'll build a 2004-11-03 i686-x-arm
compiler and see if I can figure out what is going on...



-- 
   What|Removed |Added

 Status|UNCONFIRMED |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18401

[Bug debug/19124] [4.0 regression] gcc generates incorrect dwarf2 debug info

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2004-12-22 
13:07 ---
If gdb can't handle var-tracking, it should be fixed there, and not
be disabeld in gcc.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19124

[Bug target/14629] ICE on c++ source

[namsh at kldp dot org]

--- Additional Comments From namsh at kldp dot org  2004-12-22 13:31 ---
3.4.4-20041108 generates ICE.
But, 4.0.0-20041216 No ICE.
So, it seems gcc-trunk has NO problem for this bug.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14629

[Bug tree-optimization/18576] [3.4/4.0 Regression] missing jump threading because of type changes

[kazu at cs dot umass dot edu]

--- Additional Comments From kazu at cs dot umass dot edu  2004-12-22 14:08 
---
One approach is to fix PR 14843.
It is just one approach, so I won't say this PR is blocked by PR 14843.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18576

[Bug tree-optimization/19131] New: alloca returning unnecessarily aligned pointer and uses too much memory

[rguenth at tat dot physik dot uni-tuebingen dot de]

The testcase

int foo(int bar)
{
int i, res = 0;
for (i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=19131

[Bug target/19129] gcc-3.4.4 ICE while building libobjc

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|c   |target
   Keywords||ice-on-valid-code


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19129

[Bug tree-optimization/19130] DSE not working?

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-22 
15:00 ---
I already filed a bug about this so this is a dup of bug 18880.

Note there is a patch there too for 4.1.

*** This bug has been marked as a duplicate of 18880 ***

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19130

[Bug tree-optimization/18880] DSE is not doing its job for global variables

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-22 
15:00 ---
*** Bug 19130 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||kazu at cs dot umass dot edu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18880

[Bug target/19131] alloca returning unnecessarily aligned pointer and uses too much memory

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-22 
15:06 ---
The reason you cannot find anything in the C standard is because this is ABI 
thing so this is invalid

We need to keep the stack aligned sorry.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Component|tree-optimization   |target
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19131

[Bug target/16819] [3.4/4.0 regression] ICE with empty struct as arg

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-22 
16:34 ---
Patch here: .

-- 
   What|Removed |Added

   Keywords||patch


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16819

[Bug c++/18962] [3.4/4.0 Regression] specialization of template class with inner template members and paramater

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-22 
16:34 ---
Patch here: .

-- 
   What|Removed |Added

   Keywords||patch


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18962

[Bug middle-end/18785] [4.0 Regression] isdigit builtin function fails with EBCDIC character sets

[roger at eyesopen dot com]

--- Additional Comments From roger at eyesopen dot com  2004-12-22 16:40 
---
Possible patch at http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01711.html


-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |roger at eyesopen dot com
   |dot org |
 Status|NEW |ASSIGNED
   Keywords||patch


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18785

[Bug rtl-optimization/19078] [4.0 Regression] Poor quality code after loop unrolling.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-22 
16:45 ---
(In reply to comment #6)
> ;) Well, many people believe I look too *often* at microbenchmarks... ;)
Also sometimes micro benchmarks come from bigger code and shows up in the 
profile as the hot loop.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19078

[Bug libgcj/19132] New: InputStreamReader constructor missing

[overholt at redhat dot com]

Eclipse 3.1M4 (and presumably other 3.1s) makes use of the constructor

java.io.InputStreamReader.(java.io.InputStream, java.nio.charset.Charset)

which is not yet implemented in libgcj.

-- 
   Summary: InputStreamReader constructor missing
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P2
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: overholt at redhat dot com
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=19132

[Bug fortran/17283] UNPACK issues

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2004-12-22 
16:52 ---

> The issues with PACK are fixed, keeping this open as a reminder that UNPACK
> still has issues as pointed out in #4

Test case for the scalar case:

$ cat unpack.f90
program main
  real, dimension(3) :: a, b
  a = (/ 3., 2., 1./)
  b = unpack(a,.true.,0.)
  print *,b
end program main
$ gfortran unpack.f90
 In file unpack.f90:4

  b = unpack(a,.true.,0.)
  1
Error: 'mask' argument of 'unpack' intrinsic at (1) must be an array
$ gfortran -v
Using built-in specs.
Configured with: ../gcc/configure --prefix=/home/ig25
--enable-languages=c,c++,f95 : (reconfigured) ../gcc/configure
--prefix=/home/ig25 --enable-languages=c,c++,f95
Thread model: posix
gcc version 4.0.0 20041221 (experimental)



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17283

[Bug libfortran/19106] segfault in executable for print *,sum(a,dim=2,mask=a>0)

[Thomas dot Koenig at online dot de]

--- Additional Comments From Thomas dot Koenig at online dot de  2004-12-22 
16:55 ---
The problem seems to occur with other array
intrinsics, too.

On i686-pc-linux-gnu :

$ cat unpack2.f90
program main
  real, dimension(3) :: a, b
  logical, dimension(3) :: l
  l = (/ .false., .true., .false./)
  a = (/ 3., 2., 1./)
  b = unpack(a,l,0.)
  print *,unpack(a,l,0.)
end program main
$ gfortran unpack2.f90
$ ./a.out
Segmentation fault


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19106

[Bug other/19095] testsuite/gcc.dg/vect/vect.exp is not precise enough on x86

[janis187 at us dot ibm dot com]

--- Additional Comments From janis187 at us dot ibm dot com  2004-12-22 
17:53 ---
I've been looking at how to restructure gcc.dg/vect/vect.exp to cycle through
multiple options for vector instruction sets.  

-- 
   What|Removed |Added

 CC||janis at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19095

[Bug c++/11224] [3.3/3.4/4.0 regression] warning "value computed is not used" no longer emitted

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-22 
18:01 ---
Subject: Bug 11224

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-12-22 18:00:41

Modified files:
gcc/testsuite  : ChangeLog 
gcc/cp : ChangeLog call.c cp-gimplify.c cvt.c rtti.c 
 typeck.c 
Added files:
gcc/testsuite/g++.dg/template: cond5.C 
gcc/testsuite/g++.dg/inherit: thunk3.C 
gcc/testsuite/g++.dg/warn: Wunused-9.C 

Log message:
PR c++/18464
* call.c (build_this): In templates, do not bother with
build_unary_op.
* typeck.c (unary_complex_lvalue): In a template, always refuse
simplifications.

PR c++/18492
* cp-gimplify.c (cp_genericize): Relax assertion.

PR c++/11224
* cvt.c (convert_to_void): Warn about unused values.

PR c++/18257
* rtti.c (emit_support_tinfos): On systems without weak symbols,
emit the runtime library type-info objects as non-COMDAT.

PR c++/18464
* g++.dg/template/cond5.C: New test.

PR c++/18492
* g++.dg/inherit/thunk3.C: New test.

PR c++/11224
* g++.dg/warn/Wunused-9.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4799&r2=1.4800
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/cond5.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/inherit/thunk3.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/warn/Wunused-9.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4551&r2=1.4552
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/call.c.diff?cvsroot=gcc&r1=1.524&r2=1.525
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-gimplify.c.diff?cvsroot=gcc&r1=1.16&r2=1.17
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cvt.c.diff?cvsroot=gcc&r1=1.174&r2=1.175
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/rtti.c.diff?cvsroot=gcc&r1=1.205&r2=1.206
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/typeck.c.diff?cvsroot=gcc&r1=1.605&r2=1.606



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11224

[Bug c++/18492] [4.0 regression] mmix-knuth-mmixware,HP-UX testsuite failure: g++.old-deja/g++.other/thunk1.C

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-22 
18:01 ---
Subject: Bug 18492

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-12-22 18:00:41

Modified files:
gcc/testsuite  : ChangeLog 
gcc/cp : ChangeLog call.c cp-gimplify.c cvt.c rtti.c 
 typeck.c 
Added files:
gcc/testsuite/g++.dg/template: cond5.C 
gcc/testsuite/g++.dg/inherit: thunk3.C 
gcc/testsuite/g++.dg/warn: Wunused-9.C 

Log message:
PR c++/18464
* call.c (build_this): In templates, do not bother with
build_unary_op.
* typeck.c (unary_complex_lvalue): In a template, always refuse
simplifications.

PR c++/18492
* cp-gimplify.c (cp_genericize): Relax assertion.

PR c++/11224
* cvt.c (convert_to_void): Warn about unused values.

PR c++/18257
* rtti.c (emit_support_tinfos): On systems without weak symbols,
emit the runtime library type-info objects as non-COMDAT.

PR c++/18464
* g++.dg/template/cond5.C: New test.

PR c++/18492
* g++.dg/inherit/thunk3.C: New test.

PR c++/11224
* g++.dg/warn/Wunused-9.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4799&r2=1.4800
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/cond5.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/inherit/thunk3.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/warn/Wunused-9.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4551&r2=1.4552
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/call.c.diff?cvsroot=gcc&r1=1.524&r2=1.525
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-gimplify.c.diff?cvsroot=gcc&r1=1.16&r2=1.17
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cvt.c.diff?cvsroot=gcc&r1=1.174&r2=1.175
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/rtti.c.diff?cvsroot=gcc&r1=1.205&r2=1.206
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/typeck.c.diff?cvsroot=gcc&r1=1.605&r2=1.606



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18492

[Bug c++/18464] [3.4/4.0 regression] error message about "non-lvalue in unary '&'" when using ?: operator

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-22 
18:01 ---
Subject: Bug 18464

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-12-22 18:00:41

Modified files:
gcc/testsuite  : ChangeLog 
gcc/cp : ChangeLog call.c cp-gimplify.c cvt.c rtti.c 
 typeck.c 
Added files:
gcc/testsuite/g++.dg/template: cond5.C 
gcc/testsuite/g++.dg/inherit: thunk3.C 
gcc/testsuite/g++.dg/warn: Wunused-9.C 

Log message:
PR c++/18464
* call.c (build_this): In templates, do not bother with
build_unary_op.
* typeck.c (unary_complex_lvalue): In a template, always refuse
simplifications.

PR c++/18492
* cp-gimplify.c (cp_genericize): Relax assertion.

PR c++/11224
* cvt.c (convert_to_void): Warn about unused values.

PR c++/18257
* rtti.c (emit_support_tinfos): On systems without weak symbols,
emit the runtime library type-info objects as non-COMDAT.

PR c++/18464
* g++.dg/template/cond5.C: New test.

PR c++/18492
* g++.dg/inherit/thunk3.C: New test.

PR c++/11224
* g++.dg/warn/Wunused-9.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4799&r2=1.4800
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/cond5.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/inherit/thunk3.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/warn/Wunused-9.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4551&r2=1.4552
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/call.c.diff?cvsroot=gcc&r1=1.524&r2=1.525
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-gimplify.c.diff?cvsroot=gcc&r1=1.16&r2=1.17
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cvt.c.diff?cvsroot=gcc&r1=1.174&r2=1.175
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/rtti.c.diff?cvsroot=gcc&r1=1.205&r2=1.206
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/typeck.c.diff?cvsroot=gcc&r1=1.605&r2=1.606



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18464

[Bug c++/18257] [4.0 Regression] ld: 0711-317 ERROR: Undefined symbol: typeinfo for int

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-22 
18:01 ---
Subject: Bug 18257

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-12-22 18:00:41

Modified files:
gcc/testsuite  : ChangeLog 
gcc/cp : ChangeLog call.c cp-gimplify.c cvt.c rtti.c 
 typeck.c 
Added files:
gcc/testsuite/g++.dg/template: cond5.C 
gcc/testsuite/g++.dg/inherit: thunk3.C 
gcc/testsuite/g++.dg/warn: Wunused-9.C 

Log message:
PR c++/18464
* call.c (build_this): In templates, do not bother with
build_unary_op.
* typeck.c (unary_complex_lvalue): In a template, always refuse
simplifications.

PR c++/18492
* cp-gimplify.c (cp_genericize): Relax assertion.

PR c++/11224
* cvt.c (convert_to_void): Warn about unused values.

PR c++/18257
* rtti.c (emit_support_tinfos): On systems without weak symbols,
emit the runtime library type-info objects as non-COMDAT.

PR c++/18464
* g++.dg/template/cond5.C: New test.

PR c++/18492
* g++.dg/inherit/thunk3.C: New test.

PR c++/11224
* g++.dg/warn/Wunused-9.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4799&r2=1.4800
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/cond5.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/inherit/thunk3.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/warn/Wunused-9.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4551&r2=1.4552
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/call.c.diff?cvsroot=gcc&r1=1.524&r2=1.525
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-gimplify.c.diff?cvsroot=gcc&r1=1.16&r2=1.17
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cvt.c.diff?cvsroot=gcc&r1=1.174&r2=1.175
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/rtti.c.diff?cvsroot=gcc&r1=1.205&r2=1.206
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/typeck.c.diff?cvsroot=gcc&r1=1.605&r2=1.606



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18257

[Bug other/19095] testsuite/gcc.dg/vect/vect.exp is not precise enough on x86

[janis187 at us dot ibm dot com]

--- Additional Comments From janis187 at us dot ibm dot com  2004-12-22 
18:03 ---
Oops, I wasn't done with that last comment.

Anyway, while I'm looking at the testsuite framework mechanism, perhaps someone
can determine which options are appropriate to run for various x86 targets and
come up with tests to determine whether a particular instruction set is 
supported
on the test hardware so we'll know whether the test should be "run" or "compile"
for that set.  I'm thinking of something like check_x86_vect_hw_available that
takes as argument -mmmx/-msse/-msse2/-msse3/-m3dnow.  There might also be a
check_* proc that takes those arguments and says whether the option is supported
at all for this target (e.g., does x86_64 accept them all?).

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19095

[Bug c++/18464] [3.4 regression] error message about "non-lvalue in unary '&'" when using ?: operator

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2004-12-22 
18:05 ---
Fixed in G++ 4.0.

-- 
   What|Removed |Added

Summary|[3.4/4.0 regression] error  |[3.4 regression] error
   |message about "non-lvalue in|message about "non-lvalue in
   |unary '&'" when using ?:|unary '&'" when using ?:
   |operator|operator


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18464

[Bug java/10894] Valid import statements are rejected.

[phil at mkdoc dot com]

--- Additional Comments From phil at mkdoc dot com  2004-12-22 18:06 ---
Also affects GCJ 3.3.3 (cygwin special). Can I suggest the summary is changed 
to 
"Wildcard import statements not resolved", which seems more specific to me and 
may avoid duplicate submissions.

This test case implements an interface, but the same applies extending an 
abstract or concrete class, it's the import statement that is the problem:

-- WildcardImport.java

package com.example.bug;

import com.example.other.*;

public class WildcardImport implements Interfacer {

// Empty
}

-- Interfacer.java

package com.example.other;

public interface Interfacer {

// Empty
}

This is with commands like:

gcj -C -d /build @gcj-src.txt

-- 
   What|Removed |Added

 CC||phil at mkdoc dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10894

[Bug c++/11224] [3.3/3.4 regression] warning "value computed is not used" no longer emitted

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2004-12-22 
18:06 ---
Fixed in G++ 4.0.

-- 
   What|Removed |Added

Summary|[3.3/3.4/4.0 regression]|[3.3/3.4 regression] warning
   |warning "value computed is  |"value computed is not used"
   |not used" no longer emitted |no longer emitted


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11224

[Bug c++/18257] [4.0 Regression] ld: 0711-317 ERROR: Undefined symbol: typeinfo for int

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2004-12-22 
18:06 ---
Fixed in G++ 4.0.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18257

[Bug c++/18492] [4.0 regression] mmix-knuth-mmixware,HP-UX testsuite failure: g++.old-deja/g++.other/thunk1.C

[mmitchel at gcc dot gnu dot org]

--- Additional Comments From mmitchel at gcc dot gnu dot org  2004-12-22 
18:07 ---
Fixed in G++ 4.0.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18492

[Bug c++/18839] [4.0 Regression] g++.other/thunk1.C:35: ICE: in cp_genericize, at cp/cp-gimplify.c:333

[mmitchel at gcc dot gnu dot org]

-- 
Bug 18839 depends on bug 18492, which changed state.

Bug 18492 Summary: [4.0 regression] mmix-knuth-mmixware,HP-UX testsuite 
failure: g++.old-deja/g++.other/thunk1.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18492

   What|Old Value   |New Value

 Status|NEW |ASSIGNED
 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18839

[Bug target/19131] alloca returning unnecessarily aligned pointer and uses too much memory

[rguenth at tat dot physik dot uni-tuebingen dot de]

--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen 
dot de  2004-12-22 18:16 ---
Subject: Re:  alloca returning unnecessarily aligned pointer
 and uses too much memory

pinskia at gcc dot gnu dot org wrote:
> --- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-22 
> 15:06 ---
> The reason you cannot find anything in the C standard is because this is ABI 
> thing so this is invalid
> 
> We need to keep the stack aligned sorry.

Inside a function!?  Or just at function callsites?  Humm, the Intel 
compiler produces

..B1.3: # Preds ..B1.2 ..B1.4
 movl  $4, %eax  #5.12
 subl  %eax, %esp#5.12
 andl  $-16, %esp#5.12
 movl  %esp, %eax#5.12
 # LOE eax ebx ebp esi edi
..B1.4: # Preds ..B1.3
 addl  (%eax), %ebx  #6.3
 addl  $1, %esi  #4.21
 cmpl  %edi, %esi#4.2
 jl..B1.3

which looks like it aligns the stack after alloca, but it manages to
waste less space by subtracting $4, not $32.

Also if the ABI says the stack is aligned, why do we not make use of 
this and avoid the andl $-16, %esp -- or is the alignment only about
alloca?

I'm a bit confused.

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19131

[Bug target/19102] [3.4 Regression] -march=pentium3 breaks linux kernel compiles w/ gcc-3_4-branch as of 2004/12/20

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-12-22 
18:49 ---
I can't do much more at this point.


-- 
   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org
 AssignedTo|ebotcazou at gcc dot gnu dot|unassigned at gcc dot gnu
   |org |dot org
 Status|ASSIGNED|NEW


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19102

[Bug tree-optimization/18441] Vectorizer: add a command line for simple vectorizer report

[leehod at il dot ibm dot com]

--- Additional Comments From leehod at il dot ibm dot com  2004-12-22 18:59 
---
I am working with Dorit on cleaning up the vectorizer dumps. We'd also like to 
try to address this PR - here are some preliminary thoughts/questions:

1) The 'inform' utility doesn't look very suitable because it prints the line 
information of the function and we want the line info of the loop, so a typical 
printout would look like this:
loop at trees.c:499: Success! loop vectorized.
Also, it only prints to stderr, and we want to be able to print the same 
information also to a dump-file. Maybe we want a 'vect_inform' that (1) would 
not print the function line-number but some other line-number passed as 
argument (the loop line-number), and (2) could be made to print either to 
stderr or to a dump-file?

2) How about using a mechanism like -fsched-verbose? If -ftree-vect-verbose=x 
is used and a dump-file is available, then the output will be printed into the 
dump-file; otherwise, it will be printed into stderr. If -ftree-vect-verbose=x 
is used then there will be no difference between -fdump-tree-vect-details and -
fdump-tree-vect-stats (they will both use the same verbosity level x).  If -
ftree-vect-verbose is not specified, then -fdump-tree-vect-details could use 
the highest verbosity level as default, and -fdump-tree-vect-stats could use 
the lowest verbosity level.

3) We could use the different verbosity levels to prune the number of non-
vectorized-loops we report about, not just the amount of detail we report. For 
example:
level 0: no diagnostic information.
level 1: report vectorized loops only
level 2: report vectorized loops and non-vectorized inner-most loops that 
passed the first analysis phase (vect_analyze_loop_form).
level 3: report vectorized loops and non-vectorized inner-most loops
level 4: report vectorized loops and all non-vectorized loops
level 5: full debug information (vectorized/non-vectorized loops, data-
dependence/scalar-evolution dumps)

4) Is there a mechanism in the testsuite to analyze output to stderr?

thanks,
Leehod


-- 
   What|Removed |Added

 CC||dorit at il dot ibm dot com,
   ||leehod at il dot ibm dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18441

[Bug tree-optimization/19038] [4.0 Regression] out-of ssa causing loops to have more than one BB

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2004-12-22 
19:03 ---
This is not a compile time hog, it's a performance regression. 
 
*Please*, I beg you, 
 
DON'T USE KEYWORDS LIKE REGRESSION AND HOG SO G** D*** OFTEN FOR 
TESTS THAT ARE NOT REGRESSIONS OR HOGS 
 

-- 
   What|Removed |Added

   Keywords|compile-time-hog|


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19038

[Bug libgcj/19132] InputStreamReader constructor missing

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-22 
19:09 ---
Confirmed, this constructor came in for java 1.4.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-12-22 19:09:34
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19132

[Bug target/19102] [3.4 Regression] -march=pentium3 breaks linux kernel compiles w/ gcc-3_4-branch as of 2004/12/20

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2004-12-22 19:12 
---
Subject: Re:  [3.4 Regression] -march=pentium3 breaks linux kernel compiles w/ 
gcc-3_4-branch as of 2004/12/20

> Why do we allow MMX modes in SSE regs now?

Because x86-64 calling conventions demand it.


r~


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19102

[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2004-12-22 
19:18 ---
That may all be true, but the fact is that you're now talking about  
missed-optimizations, and not a real compile time hog.  Yes we can 
win.  No, this is not a hog anymore, it's just not as good as it 
could be.  You're also talking about RTL, not tree jump threading. 
 
In fact I think it's plain wrong to keep this bug open.  It's just 
keeping the number of real regressions artificially high.  We have 
compile time slowdowns, and that's a regression.  But we don't need 
to keep bugs open when the issue of that bug was been fixed. 
 
I suggest someone updates the summary and keywords to reflect the 
actual status of the bug, or close this one and open a new one for 
the basically unrelated issues Jeff mentioned 

-- 
   What|Removed |Added

 Status|WAITING |NEW
   Last reconfirmed|2004-07-27 18:04:40 |2004-12-22 19:18:03
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15524

[Bug middle-end/19125] [4.0 Regression] ICE at dwarf2out.c:9214

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2004-12-22 19:20 
---
Fixed.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19125

[Bug middle-end/15855] [3.4/4.0 Regression] g++ crash with -O2 and -O3 on input file

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2004-12-22 
19:20 ---
Could someone (Jeff) update the summary for this PR to reflect the 
actual status of this PR and the problems being addressed? 
 
Does the test case from the submitter still crash g++ on mainline? 
 
 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15855

[Bug rtl-optimization/13931] [3.3/3.4/4.0 Regression] combiner much slower on big basic blocks

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2004-12-22 
19:23 ---
Perhaps someone can give an update on this bug? 
 
 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13931

[Bug tree-optimization/15524] [4.0 Regression] jump threading on trees is slow with switch statements with large # of cases

[law at redhat dot com]

--- Additional Comments From law at redhat dot com  2004-12-22 19:28 ---
Subject: Re:  [4.0 Regression] jump threading
on trees is slow with switch statements with large # of cases

On Wed, 2004-12-22 at 19:18 +, steven at gcc dot gnu dot org wrote:
> --- Additional Comments From steven at gcc dot gnu dot org  2004-12-22 
> 19:18 ---
> That may all be true, but the fact is that you're now talking about  
> missed-optimizations, and not a real compile time hog.  Yes we can 
> win.  No, this is not a hog anymore, it's just not as good as it 
> could be.  You're also talking about RTL, not tree jump threading. 
I'm talking strictly about compile-time hogs.  It's insanely dumb that
we're burning 5% of compilation time just trying to hoist the
fake GLOBAL_VAR variable out of empty loops.  It's insanely dumb that
we're burning 5% of compilation time threading jumps at the RTL
level when they all should have been threaded at the tree level.

>  
> In fact I think it's plain wrong to keep this bug open.  It's just 
> keeping the number of real regressions artificially high.  We have 
> compile time slowdowns, and that's a regression.  But we don't need 
> to keep bugs open when the issue of that bug was been fixed. 
I stongly disagree.  Please do not close this bug report.

jeff




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15524

[Bug middle-end/15855] [3.4/4.0 Regression] g++ crash with -O2 and -O3 on input file

[law at redhat dot com]

--- Additional Comments From law at redhat dot com  2004-12-22 19:29 ---
Subject: Re:  [3.4/4.0 Regression] g++ crash with -O2
and -O3 on input file

On Wed, 2004-12-22 at 19:20 +, steven at gcc dot gnu dot org wrote:
> --- Additional Comments From steven at gcc dot gnu dot org  2004-12-22 
> 19:20 ---
> Could someone (Jeff) update the summary for this PR to reflect the 
> actual status of this PR and the problems being addressed? 
>  
> Does the test case from the submitter still crash g++ on mainline? 
I don't believe it crashes, but the amount of time we're spending in
the aliasing code is, err, on the order of 50% of compilation time
last I checked.  Fixing it effectively involves rewriting 
tree-ssa-alias.c, which I am doing.  However, it'll probably be 
several weeks before I have anything ready for serious examination
due to personal  commitments, vacation, etc.

jeff




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15855

[Bug ada/19128] Bug box while building asharp

[gccbugs at sohailsomani dot com]

--- Additional Comments From gccbugs at sohailsomani dot com  2004-12-22 
19:33 ---
(In reply to comment #10)
> There's nothing critical about this PR, please stop bumping its priority: it
> won't magically fix it, thanks.

I thought it went from critical to normal. Sounds normal to me.

-- 
   What|Removed |Added

   Severity|normal  |critical


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19128

[Bug rtl-optimization/13931] [3.3/3.4/4.0 Regression] combiner much slower on big basic blocks

[echristo at redhat dot com]

--- Additional Comments From echristo at redhat dot com  2004-12-22 19:48 
---
I thought I did on the 7th. I'm not sure there's anything we can do about this.
The behavior is correct and the previous behavior was proved to be not correct.
If someone has an idea that's guaranteed to be correct in all cases I'm willing
to try to implement it though.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13931

[Bug target/19102] [3.4 Regression] -march=pentium3 breaks linux kernel compiles w/ gcc-3_4-branch as of 2004/12/20

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2004-12-22 20:02 
---
And, actually, we allowed MMX modes with -msse2 before, so there must be 
another 
explanation of why things wouldn't have been failing with -march=pentium4.

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rth at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19102

[Bug target/19102] [3.4 Regression] -march=pentium3 breaks linux kernel compiles w/ gcc-3_4-branch as of 2004/12/20

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-12-22 
20:24 ---
> > Why do we allow MMX modes in SSE regs now?
> 
> Because x86-64 calling conventions demand it.

The calling conventions for vector types I presume?  The problem is that SImode
slipped through the cracks so the register allocator now jumps from SIREG to
INT_SSE_REGS for SImode pseudos.  Is that an unintended side-effect?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19102

[Bug c++/17470] Visibility attribute ignored for explicit template instantiation

[nomis80 at nomis80 dot org]

--- Additional Comments From nomis80 at nomis80 dot org  2004-12-22 20:54 
---
I just got hit with that bug and spent too much time figuring out what was
wrong. Here's my code, just to show an example of real-life usage:

//
/**
 * Returns the unsigned version of \a number.
 */
template< class T >
T abs( T number )
{
// This is the default implementation, using comparison to zero and unary
// negation operator.
if ( number < 0 ) {
return -number;
}
return number;
}

// Here are some specific implementations.

template<> bool WRAP_API abs( bool   number );
template<> char WRAP_API abs( char   number );
template<> unsigned charWRAP_API abs( unsigned char  number );
template<> shortWRAP_API abs( short  number );
template<> unsigned short   WRAP_API abs( unsigned short number );
template<> int  WRAP_API abs( intnumber );
template<> unsigned int WRAP_API abs( unsigned int   number );
template<> long WRAP_API abs( long   number );
template<> unsigned longWRAP_API abs( unsigned long  number );
template<> floatWRAP_API abs( float  number );
template<> double   WRAP_API abs( double number );
//

Please fix this bug!

-- 
   What|Removed |Added

 CC||s_gccbugzilla at nedprod dot
   ||com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17470

[Bug c++/17470] Visibility attribute ignored for explicit template instantiation

[nomis80 at nomis80 dot org]

-- 
   What|Removed |Added

 CC||nomis80 at nomis80 dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17470

[Bug c/19133] New: march=athlon can produce slower code than march=i686

[ornati at fastwebnet dot it]

"gcc -v"
Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/specs
Configured with: /var/tmp/portage/gcc-3.3.4-r1/work/gcc-3.3.4/configure
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.3
--includedir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3/info --enable-shared
--host=i686-pc-linux-gnu --target=i686-pc-linux-gnu --with-system-zlib
--enable-languages=c,c++ --enable-threads=posix --enable-long-long
--disable-checking --disable-libunwind-exceptions --enable-cstdio=stdio
--enable-version-specific-runtime-libs
--with-gxx-include-dir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/include/g++-v3
--with-local-prefix=/usr/local --enable-shared --enable-nls
--without-included-gettext --disable-multilib --enable-__cxa_atexit
--enable-clocale=generic
Thread model: posix
gcc version 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)


"cat /proc/cpu"
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 6
model   : 3
model name  : AMD Duron(tm) Processor
stepping: 1
cpu MHz : 756.798
cache size  : 64 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat 
pse36 mmx
fxsr syscall mmxext 3dnowext 3dnow
bogomips: 1490.94


Playing with compiler optimizations I've found a "test-case" where
"-march=athlon" produces an executable that is ~18% slower than that produced
with "-march=i686".

"Commands used for compilation"
gcc -Wall -O2 -march=i686 -o test-i686 test.c
gcc -Wall -O2 -march=athlon -o test-athlon test.c

"test.c"
#define N 3

static int A[N];
static int B[N];

int main(void)
{
int i, j, x;

for (i = 0; i < N; ++i) {
x = 0;
for (j=0; j < N; ++j)
if (A[j] < A[i] && B[j] > x)
x = A[j];
A[i] = x + 1;
}
return 0;
}


Execution time:

[EMAIL PROTECTED] gcc_test $ time ./test-i686 

real0m6.149s
user0m6.015s
sys 0m0.004s
[EMAIL PROTECTED] gcc_test $ time ./test-athlon 

real0m7.270s
user0m7.120s
sys 0m0.004s


Anoter interesting thing is that if I only do this change:
--- test.c.orig 2004-12-22 21:52:46.208140096 +0100
+++ test.c  2004-12-22 21:55:01.069638032 +0100
@@ -10,7 +10,7 @@
for (i = 0; i < N; ++i) {
x = 0;
for (j=0; j < N; ++j)
-   if (A[j] < A[i] && B[j] > x)
+   if (A[j] < A[i] && A[j] > x)
x = A[j];
A[i] = x + 1;
}


The "test-athlon" version returns fast as "test-i686" one:

[EMAIL PROTECTED] gcc_test $ time ./test-i686 

real0m6.134s
user0m6.015s
sys 0m0.003s
[EMAIL PROTECTED] gcc_test $ time ./test-athlon 

real0m6.128s
user0m6.010s
sys 0m0.006s


I've tried also gcc 3.4.3 and it shows the same behaviour.

Shouldn't "-march=athlon" optimize for AMD K7 processors? ;-)

-- 
   Summary: march=athlon can produce slower code than march=i686
   Product: gcc
   Version: 3.3.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ornati at fastwebnet dot it
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=19133

[Bug target/19133] march=athlon can produce slower code than march=i686

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

  Component|c   |target
   Keywords||missed-optimization


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19133

[Bug ada/19128] Bug box while building asharp

[gccbugs at sohailsomani dot com]

-- 
   What|Removed |Added

   Severity|critical|normal


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19128

[Bug c++/19134] New: Class visibility of templated classes can't be overridden for function specializations

[nomis80 at nomis80 dot org]

Notwithstanding #17470 :

[EMAIL PROTECTED] ~]$ cat foo.cc
template
class A {
void foo() {};
};
#pragma GCC visibility push(default)
template<> void A::foo() {};
#pragma GCC visibility pop
[EMAIL PROTECTED] ~]$ g++ -fvisibility-inlines-hidden -c foo.cc
foo.cc:6: warning: 'void A::foo() [with T = int]': visibility attribute
ignored because it
foo.cc:3: warning: conflicts with previous declaration here

-- 
   Summary: Class visibility of templated classes can't be
overridden for function specializations
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nomis80 at nomis80 dot org
CC: gcc-bugs at gcc dot gnu dot org,s_gccbugzilla at nedprod
dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19134

[Bug tree-optimization/18687] [4.0 Regression] ~50% compile time regression

[belyshev at depni dot sinp dot msu dot ru]

--- Additional Comments From belyshev at depni dot sinp dot msu dot ru  
2004-12-22 21:50 ---
Hope these two larger test cases will help profiling.

3.4.4   4.0.0   delta

hashes100.c:

-O0  3.7 3.8  3%
-O1  6.414.5126%
-O2 11.318.7 65%
-O3 11.919.0 60%


infcodes100.c:

-O0  7.4 7.6  3%
-O1 12.625.4101%
-O2 21.433.8 58%
-O3 22.434.7 55%


-- 
   What|Removed |Added

   Last reconfirmed|2004-12-03 00:24:07 |2004-12-22 21:50:22
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18687

[Bug target/19102] [3.4 Regression] -march=pentium3 breaks linux kernel compiles w/ gcc-3_4-branch as of 2004/12/20

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Severity|critical|normal


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19102

[Bug middle-end/17544] [4.0 Regression] incorrect -Wunreachable-code warning for mains with a return statement

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2004-12-22 
22:34 ---
Spot the bug: 
 
main () 
{ 
  intD.0 D.1384; 
 
  # BLOCK 0, starting at line 3 
  # PRED: ENTRY 
  [t.c : 3] D.1384 = 0; 
  [t.c : 3] goto  (); 
  # SUCC: 2 
 
  # BLOCK 1, starting at line 4 
  # PRED: 
  [t.c : 4] D.1384 = 0; 
  # SUCC: 2 
 
  # BLOCK 2 
  # PRED: 0 1 
:; 
  return D.1384; 
  # SUCC: EXIT 
 
} 
 
Note how the compiler generated "return 0;" has a locus.  Not giving 
it one should fix it. 
 
Testing a patch. 
 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17544

[Bug target/18987] [4.0 regression] [ia64] Extra '.restore sp' in tail call

[debian-gcc at lists dot debian dot org]

--- Additional Comments From debian-gcc at lists dot debian dot org  
2004-12-22 22:47 ---
according to http://bugs.debian.org/286840 (if that's the same thing), this is
broken in gcc-3.3 CVS and gcc-3.4 CVS as well. Latest known working version is
gcc-3.3.5.

-- 
   What|Removed |Added

 CC||debian-gcc at lists dot
   ||debian dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18987

[Bug target/18987] [3.3/3.4/4.0 regression] [ia64] Extra '.restore sp' in tail call

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Severity|normal  |critical
  Known to fail||3.3.6 3.4.4 4.0.0
  Known to work||3.3 3.4.0
Summary|[4.0 regression] [ia64] |[3.3/3.4/4.0 regression]
   |Extra '.restore sp' in tail |[ia64] Extra '.restore sp'
   |call|in tail call
   Target Milestone|4.0.0   |3.4.4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18987

[Bug target/18987] [3.3/3.4/4.0 regression] [ia64] Extra '.restore sp' in tail call

[debian-gcc at lists dot debian dot org]

--- Additional Comments From debian-gcc at lists dot debian dot org  
2004-12-22 23:13 ---
sorry, forgot to add that the 3.3 version I tested had H.J.Lu's unwind exception
handling patches applied, backported from the 3.4 branch. I'll recheck with a
vanilla gcc-3.3 CVS version.

Matthias


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18987

[Bug tree-optimization/19121] [4.0 Regression] ICE: in merge_alias_info, at tree-ssa-copy.c:236

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-22 
23:13 ---
I can also reproduce it this on powerpc-darwin.

-- 
   What|Removed |Added

  GCC build triplet|i386-unknown-freebsd4.10|
   GCC host triplet|i386-unknown-freebsd4.10|
 GCC target triplet|i386-unknown-freebsd4.10|


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19121

[Bug target/19102] [3.4 Regression] -march=pentium3 breaks linux kernel compiles w/ gcc-3_4-branch as of 2004/12/20

[ebotcazou at gcc dot gnu dot org]

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2004-12-22 
23:18 ---
> And, actually, we allowed MMX modes with -msse2 before, so there must be 
> another 
> explanation of why things wouldn't have been failing with -march=pentium4.

Allocation ordering considerations?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19102

[Bug target/19102] [3.4 Regression] -march=pentium3 breaks linux kernel compiles w/ gcc-3_4-branch as of 2004/12/20

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2004-12-22 23:27 
---
Apparently register move costs.

Testing a Large Hack to prevent this suddenly appearing on the 3.4 branch.

For mainline, move pattern constraints should be fixed, and folks will have
to make sure to use -mno-sse when sse is not desired.  Plus, -mno-sse will
have to be fixed such that it's effective when -march implies sse[23], and
we'll have to add extra code to not ICE on x86-64 when the ABI specifies
that parameters go in disabled registers.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19102

[Bug java/10894] Wildcard import statements not resolved

[jbrandmeyer at users dot sourceforge dot net]

--- Additional Comments From jbrandmeyer at users dot sourceforge dot net  
2004-12-22 23:40 ---
Yes, that is much more specific.

-- 
   What|Removed |Added

Summary|Valid import statements are |Wildcard import statements
   |rejected.   |not resolved


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10894

[Bug tree-optimization/18595] [4.0 Regression] IV-OPTS is O(N^3)

[belyshev at depni dot sinp dot msu dot ru]

--- Additional Comments From belyshev at depni dot sinp dot msu dot ru  
2004-12-22 23:40 ---
It seems that extra O(N) factor comes from high memory usage. For smaller N
(0..30) compiler behaves like O(2) and for larger (> 50) like O(2.5 .. 3).

gnuplot> fit [0:30] A*x**k+B "data" via A,k,B
[snip]
Final set of parametersAsymptotic Standard Error
=====

A   = 0.000465461  +/- 2.625e-05(5.64%)
k   = 1.90612  +/- 0.01652  (0.8667%)
B   = 0.0328722+/- 0.0007677(2.335%)

gnuplot> fit [50:175] A*x**k+B "data" via A,k,B
[snip]
Final set of parametersAsymptotic Standard Error
=====

A   = 4.76329e-06  +/- 3.493e-07(7.332%)
k   = 3.0033   +/- 0.01405  (0.4678%)
B   = 0.392746 +/- 0.02972  (7.567%)

For N=175 memory usage on my machine exceedes 600 MB

-- 
   What|Removed |Added

   Last reconfirmed|2004-11-25 11:16:30 |2004-12-22 23:40:41
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18595

[Bug target/19102] [3.4 Regression] -march=pentium3 breaks linux kernel compiles w/ gcc-3_4-branch as of 2004/12/20

[ak at muc dot de]

--- Additional Comments From ak at muc dot de  2004-12-22 23:53 ---
FWIW i compiled a full 3.3-hammer compiled 2.6.10rc3 x86-64 kernel
for suspicious use of %xmm or %mm and there wasn't any.

There also is a warning in all 2.6 x86-64 kernels for kernel FPU use at runtime.

So at least on x86-64 it doesn't seem to be a real issue in practice.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19102

[Bug target/18896] addressing split complex parm

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-23 
00:11 ---
Subject: Bug 18896

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-12-23 00:10:50

Modified files:
gcc: ChangeLog function.c 

Log message:
PR target/18896
* function.c (split_complex_args): Set DECL_ARTIFICIAL and 
DECL_IGNORED_P
for real and imaginary parts if the parm is addressable.
(assign_parms_unsplit_complex): If parm addressable, save real
and imaginary parts to a stack temp.  Pass assign_parm_data_all.
(assign_parms): Adjust assign_parms_unsplit_complex call.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6924&r2=2.6925
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/function.c.diff?cvsroot=gcc&r1=1.595&r2=1.596



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18896

[Bug target/18896] addressing split complex parm

[amodra at bigpond dot net dot au]

--- Additional Comments From amodra at bigpond dot net dot au  2004-12-23 
00:33 ---
Fixed mainline.  gcc-3.4 not affected by this particular problem.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18896

[Bug target/18896] addressing split complex parm

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Target Milestone|--- |4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18896

[Bug bootstrap/19135] New: build failure in libiberty multilibs

[janis187 at us dot ibm dot com]

GCC builds are broken on powerpc64-unknown-linux-gnu since this patch
to libiberty: http://gcc.gnu.org/ml/gcc-cvs/2004-12/msg00805.html.

I configure with --build, --host, and --target=powerpc64-linux and
--with-cpu=default32; see my recent test results for mainline for
the complete set of configure options I use.  This problem occurs
even for simple builds of C only.

The build in powerpc64-linux/64/libiberty tries to create
libiberty.so.0.0.0 from 64-bit object files without specifying -m64.
The build continues and eventually succeeds, but 'make install' tries
the same thing and fails.

-- 
   Summary: build failure in libiberty multilibs
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis187 at us dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org,hjl at gnu dot org
 GCC build triplet: powerpc64-linux
  GCC host triplet: powerpc64-linux
GCC target triplet: powerpc64-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19135

[Bug bootstrap/19135] [4.0 Regression] build failure in libiberty multilibs

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Severity|normal  |critical
   Keywords||build
   Priority|P2  |P1
Summary|build failure in libiberty  |[4.0 Regression] build
   |multilibs   |failure in libiberty
   ||multilibs
   Target Milestone|--- |4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19135

[Bug bootstrap/19135] [4.0 Regression] build failure in libiberty multilibs

[hjl at lucon dot org]

--- Additional Comments From hjl at lucon dot org  2004-12-23 01:14 ---
I don't have Linux/powerpc64. I have no problems with Linux/x86_64:

[EMAIL PROTECTED] build-x86_64-linux]$ grep "^CC =" x86_64-unknown-linux-
gnu/32/libiberty/Makefile x86_64-unknown-linux-gnu/libiberty/Makefile
x86_64-unknown-linux-gnu/32/libiberty/Makefile:CC 
= /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc -
B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -B/usr/gcc-4.0/x86_64-unknown-
linux-gnu/bin/ -B/usr/gcc-4.0/x86_64-unknown-linux-gnu/lib/ -isystem /usr/gcc-
4.0/x86_64-unknown-linux-gnu/include -isystem /usr/gcc-4.0/x86_64-unknown-
linux-gnu/sys-include  -m32
x86_64-unknown-linux-gnu/libiberty/Makefile:CC = /export/build/gnu/gcc/build-
x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -
B/usr/gcc-4.0/x86_64-unknown-linux-gnu/bin/ -B/usr/gcc-4.0/x86_64-unknown-
linux-gnu/lib/ -isystem /usr/gcc-4.0/x86_64-unknown-linux-gnu/include -
isystem /usr/gcc-4.0/x86_64-unknown-linux-gnu/sys-include

I will try --with-cpu=default32 to see if it makes a difference.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19135

[Bug middle-end/17544] [4.0 Regression] incorrect -Wunreachable-code warning for mains with a return statement

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2004-12-23 
01:19 ---
Look, no hands (or testing): 
 
Index: cp/decl.c 
=== 
RCS file: /cvs/gcc/gcc/gcc/cp/decl.c,v 
retrieving revision 1.1346 
diff -u -3 -p -r1.1346 decl.c 
--- cp/decl.c   22 Dec 2004 03:34:53 -  1.1346 
+++ cp/decl.c   23 Dec 2004 01:19:29 - 
@@ -10631,12 +10631,19 @@ finish_function (int flags) 
 { 
   if (DECL_MAIN_P (current_function_decl)) 
{ 
- /* Make it so that `main' always returns 0 by default.  */ 
+ tree stmt; 
+ 
+ /* Make it so that `main' always returns 0 by default (or 
+1 for VMS).  */ 
 #if VMS_TARGET 
  finish_return_stmt (integer_one_node); 
 #else 
  finish_return_stmt (integer_zero_node); 
 #endif 
+ /* Hack.  We don't want the middle-end to warn that this 
+return is unreachable, so put the statement on the 
+special line 0.  */ 
+ annotate_with_file_line (stmt, input_filename, 0); 
} 
 
   /* Finish dealing with exception specifiers.  */ 
 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17544

[Bug bootstrap/19135] [4.0 Regression] build failure in libiberty multilibs

[hjl at lucon dot org]

--- Additional Comments From hjl at lucon dot org  2004-12-23 01:20 ---
Linux/x86_64 doesn't support --with-cpu=default32. I have no idea what
went wrong on Linux/powerpc64.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19135

[Bug bootstrap/19135] [4.0 Regression] build failure in libiberty multilibs

[hjl at lucon dot org]

-- 
   What|Removed |Added

 Status|UNCONFIRMED |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19135

[Bug bootstrap/19135] [4.0 Regression] build failure in libiberty multilibs

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-12-23 01:22:07
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19135

[Bug tree-optimization/18595] [4.0 Regression] IV-OPTS is O(N^3)

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2004-12-23 
01:26 ---
hmmm maybe the extra O(N) comes from O(N) bitmap operations? (Just guessing) 
 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18595

[Bug tree-optimization/18595] [4.0 Regression] IV-OPTS is O(N^3)

[rakdver at atrey dot karlin dot mff dot cuni dot cz]

--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni 
dot cz  2004-12-23 01:29 ---
Subject: Re:  [4.0 Regression] IV-OPTS is O(N^3)

> hmmm maybe the extra O(N) comes from O(N) bitmap operations? (Just guessing) 

that might be the case, but I don't think it is likely (also just
guessing :-)  As far as I can tell all bitmaps in ivopts should be small
for this testcase.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18595

[Bug target/19102] [3.4 Regression] -march=pentium3 breaks linux kernel compiles w/ gcc-3_4-branch as of 2004/12/20

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-23 
01:31 ---
Subject: Bug 19102

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED]   2004-12-23 01:31:20

Modified files:
gcc: ChangeLog 
gcc/config/i386: i386.c 

Log message:
PR target/19102
* config/i386/i386.c (x86_inter_unit_moves): Disable.
(ix86_hard_regno_mode_ok): Disallow SSE2 and MMX scalar modes
in SSE registers when only SSE1 enabled.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.750&r2=2.2326.2.751
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.635.2.18&r2=1.635.2.19



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19102

[Bug target/19102] [3.4 Regression] -march=pentium3 breaks linux kernel compiles w/ gcc-3_4-branch as of 2004/12/20

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2004-12-23 01:40 
---
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01777.html

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19102

[Bug rtl-optimization/19097] Lots of else ifs take forever to compile

[steven at gcc dot gnu dot org]

--- Additional Comments From steven at gcc dot gnu dot org  2004-12-23 
01:43 ---
This looks like a problem with the hash function for a REG when we 
have many implicit sets: 
 
Found 6001 implicit sets 
SET hash table (6001 buckets, 6001 entries) 
Index 0 (hash value 58) 
  (set (reg/v:SI 58 [ b ]) 
(const_int 1 [0x1])) 
Index 1 (hash value 58) 
  (set (reg/v:SI 58 [ b ]) 
(const_int 1 [0x2710])) 
Index 2 (hash value 58) 
  (set (reg/v:SI 58 [ b ]) 
(const_int 10001 [0x2711])) 
Index 3 (hash value 58) 
  (set (reg/v:SI 58 [ b ]) 
(const_int 10002 [0x2712])) 
Index 4 (hash value 58) 
  (set (reg/v:SI 58 [ b ]) 
(const_int 10003 [0x2713])) 
Index 5 (hash value 58) 
  (set (reg/v:SI 58 [ b ]) 
(const_int 10004 [0x2714])) 
Index 6 (hash value 58) 
  (set (reg/v:SI 58 [ b ]) 
(const_int 10005 [0x2715])) 
Index 7 (hash value 58) 
  (set (reg/v:SI 58 [ b ]) 
(const_int 10006 [0x2716])) 
Index 8 (hash value 58) 
  (set (reg/v:SI 58 [ b ]) 
(const_int 10007 [0x2717])) 
Index 9 (hash value 58) 
  (set (reg/v:SI 58 [ b ]) 
(const_int 10008 [0x2718])) 
Index 10 (hash value 58) 
  (set (reg/v:SI 58 [ b ]) 
(const_int 10009 [0x2719])) 
(etc.) 
 
Needless to say, this results in truely dramatically bad compile 
time behavior of the hash table. 
 

-- 
   What|Removed |Added

 CC||roger at eyesopen dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097

[Bug c++/18733] [4.0 Regression] friend rejected

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-23 
01:49 ---
Subject: Bug 18733

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-12-23 01:49:39

Modified files:
gcc/cp : ChangeLog pt.c 
gcc/testsuite  : ChangeLog 
Added files:
gcc/testsuite/g++.dg/template: friend33.C 

Log message:
PR c++/18733
* pt.c (check_explicit_specialization): Use special logic to validate
befriended specializations.

PR c++/18733
* g++.dg/template/friend33.C: New testcase.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4553&r2=1.4554
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&r1=1.959&r2=1.960
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4800&r2=1.4801
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/friend33.C.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18733

[Bug c++/18733] [4.0 Regression] friend rejected

[giovannibajo at libero dot it]

--- Additional Comments From giovannibajo at libero dot it  2004-12-23 
01:50 ---
Fixed in GCC 4.0.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18733

[Bug other/19082] [4.0 Regression] build/genattrtab: out of memory allocating 151568 bytes after a total of 4161651196 bytes

[dje at gcc dot gnu dot org]

--- Additional Comments From dje at gcc dot gnu dot org  2004-12-23 01:54 
---
what release of gcc is used for bootstrap?
what are hard and soft limits, includig limits set in /etc/security?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19082

[Bug tree-optimization/17578] Missed optimization--failure of gcc.c-torture/execute/ieee/compare-fp-3.c at -O1 and above

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-12-23 02:10:58
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17578

[Bug c/19136] New: Can't build gcc 3.4.3: ld parse error on libgcc.map

[john at jupiter dot com]

ld:libgcc/./libgcc.map: file format not recognized; treating as linker script

* the exact version of GCC being compiled;

gcc-3.4.3

* the system type;

SunOS ananke 5.5.1 Generic_103640-08 sun4m sparc SUNW,SPARCstation-5
This system had gcc version 2.7.2 but no make. I downloaded,compiled
and installed binutils-2.14.tar.gz and make-3.80.tar.gz.
   
* the options given when GCC was configured/built;

None

* the complete command line that triggers the bug;

make > & make.out & ; tail -f make.out

* the compiler output (error messages, warnings, etc.);

(make output below)
/usr/local/sparc-sun-solaris2.5.1/bin/ld:libgcc/./libgcc.map: file format
not recognized; treating as linker script
/usr/local/sparc-sun-solaris2.5.1/bin/ld:libgcc/./libgcc.map:1: parse error
collect2: ld returned 1 exit status
make[2]: *** [libgcc_s.so] Error 1

* a complete set of source files;

(The original gcc-3.4.3.tar file I downloaded)

* ld version linking GCC;

GNU ld version 2.14 20030612

* the version of gcc compiling GCC;

gcc version 2.7.2

Description:
1) I downloaded and unzipped gcc-3.4.3.tar.bz2

2)  I read the README and html files in INSTALL/, there did not seem to be any
special actions to be performed for my architecture so I didn't modify any files
or use any command line options.

3) I ran ./configure

4)  I ran  make > & make.out & ; tail -f make.out. ld failed in what appears to
be the final link of libgcc. It did not like the format of libgcc.map. It looked
fine to me (see attached)

Let me know if you need any of the post-configure files (Makefile, config.log,
etc. If you want the intermediate files I will have to remake saving the temp 
files.

== libgcc.map 
GCC_3.0 {
  global:
_Unwind_ForcedUnwind;
__muldi3;
__ashrdi3;
__negvsi2;
__subvdi3;
__addvdi3;
__clear_cache;
__subvsi3;
__addvsi3;
__register_frame_info_table_bases;
__ucmpdi2;
_Unwind_GetGR;
__fixunsdfdi;
__ashldi3;
__udivdi3;
__deregister_frame_info;
__negdi2;
__deregister_frame_info_bases;
__ffsdi2;
__floatdidf;
__register_frame_info;
__fixdfdi;
__cmpdi2;
__register_frame_table;
_Unwind_RaiseException;
__divdi3;
__lshrdi3;
_Unwind_SetGR;
__umoddi3;
_Unwind_Resume;
__fixunstfdi;
_Unwind_GetIP;
__fixunsdfsi;
__fixunssfdi;
__absvdi2;
__mulvdi3;
__fixtfdi;
__floatdisf;
__absvsi2;
__mulvsi3;
__moddi3;
__fixsfdi;
__register_frame_info_bases;
_Unwind_GetDataRelBase;
_Unwind_GetRegionStart;
__deregister_frame;
_Unwind_SetIP;
_Unwind_GetLanguageSpecificData;
__floatditf;
_Unwind_DeleteException;
__register_frame;
__udivmoddi4;
__fixunssfsi;
_Unwind_Find_FDE;
__negvdi2;
__register_frame_info_table;
_Unwind_GetTextRelBase;

  local:
*;
};
GCC_3.3 {
  global:
_Unwind_GetCFA;
_Unwind_Resume_or_Rethrow;
_Unwind_Backtrace;
_Unwind_FindEnclosingFunction;
} GCC_3.0;
GCC_3.3.1 {
  global:
__gcc_personality_v0;
} GCC_3.3;
GCC_3.4 {
  global:
__ctzdi2;
__ctzsi2;
__clzdi2;
__paritydi2;
__clzsi2;
__paritysi2;
__popcountdi2;
__popcountsi2;
} GCC_3.3.1;
GCC_3.4.2 {
  global:
__enable_execute_stack;
} GCC_3.4;

== make.out ==
...
ranlib ./libgcc_eh.a
{ nm -pg  libgcc/./_muldi3.o libgcc/./_negdi2.o libgcc/./_lshrdi3.o
libgcc/./_ashldi3.o libgcc/./_ashrdi3.o libgcc/./_cmpdi2.o libgcc/./_ucmpdi2.o
libgcc/./_floatdidf.o libgcc/./_floatdisf.o libgcc/./_fixunsdfsi.o
libgcc/./_fixunssfsi.o libgcc/./_fixunsdfdi.o libgcc/./_fixdfdi.o
libgcc/./_fixunssfdi.o libgcc/./_fixsfdi.o libgcc/./_fixxfdi.o
libgcc/./_fixunsxfdi.o libgcc/./_floatdixf.o libgcc/./_fixunsxfsi.o
libgcc/./_fixtfdi.o libgcc/./_fixunstfdi.o libgcc/./_floatditf.o
libgcc/./_clear_cache.o libgcc/./_enable_execute_stack.o libgcc/./_trampoline.o
libgcc/./__main.o libgcc/./_absvsi2.o libgcc/./_absvdi2.o libgcc/./_addvsi3.o
libgcc/./_addvdi3.o libgcc/./_subvsi3.o libgcc/./_subvdi3.o libgcc/./_mulvsi3.o
libgcc/./_mulvdi3.o libgcc/./_negvsi2.o libgcc/./_negvdi2.o libgcc/./_ctors.o
libgcc/./_ffssi2.o libgcc/./_ffsdi2.o libgcc/./_clz.o libgcc/./_clzsi2.o
libgcc/./_clzdi2.o libgcc/./_ctzsi2.o libgcc/./_ctzdi2.o
libgcc/./_popcount_tab.o libgcc/./_popcountsi2.o libgcc/./_popcountdi2.o
libgcc/./_paritysi2.o libgcc/./_paritydi2.o libgcc/./_divdi3.o
libgcc/./_moddi3.o libgcc/./_udivdi3.o libgcc/./_umoddi3.o
libgcc/./_udiv_w_sdiv.o libgcc/./_udivmoddi4.o  libgcc/./unwind-dw2.o
libgcc/./unwind-dw2-fde.o libgcc/./unwind-sjlj.o libgcc/./gthr-gnat.o
lib

[Bug c/19136] Can't build gcc 3.4.3: ld parse error on libgcc.map

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-23 
02:15 ---
There is the problem:
binutils-2.14.tar.gz 

so you need --with-gnu-as and --with-gnu-ld.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19136

[Bug other/19082] [4.0 Regression] build/genattrtab: out of memory allocating 151568 bytes after a total of 4161651196 bytes

[dave at hiauly1 dot hia dot nrc dot ca]

--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  
2004-12-23 02:16 ---
Subject: Re:  [4.0 Regression] build/genattrtab: out of memor

> --- Additional Comments From dje at gcc dot gnu dot org  2004-12-23
> 01:54 ---
> what release of gcc is used for bootstrap?

Tried 3.3.2 and 3.4.3.

> what are hard and soft limits, includig limits set in /etc/security?

bash-2.05b$ ulimit -a
core file size(blocks, -c) unlimited
data seg size (kbytes, -d) 131072
file size (blocks, -f) unlimited
max memory size   (kbytes, -m) 32768
open files(-n) 2000
pipe size  (512 bytes, -p) 64
stack size(kbytes, -s) 32768
cpu time (seconds, -t) unlimited
max user processes(-u) 128
virtual memory(kbytes, -v) unlimited

Regarding /etc/security, I would have to ask.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19082

[Bug rtl-optimization/14741] missing transformations lead to poorly optimized code

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-23 
02:21 ---
Hmm, I get this for the loop on ppc:
L42:
fmr f12,f0
L33:
lfd f13,0(r11)
add r11,r11,r7
lfd f0,0(r9)
addi r9,r9,8
fmadd f0,f13,f0,f12
bdnz L42

The problem the secondary bb is PR 19038 but other than that, this loop as 
optimizated as it gets on 
ppc.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741

[Bug tree-optimization/19038] [4.0 Regression] out-of ssa causing loops to have more than one BB

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-23 
02:41 ---
Note I also see it for some simple fortran code see PR 14741.

-- 
   What|Removed |Added

  Known to fail||4.0.0
  Known to work||3.3 3.4.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19038

[Bug libfortran/17992] reading empty line does not return 0

[bdavis at gcc dot gnu dot org]

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-12-23 04:07:27
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17992

[Bug libfortran/17992] reading empty line does not return 0

[bdavis at gcc dot gnu dot org]

--- Additional Comments From bdavis at gcc dot gnu dot org  2004-12-23 
04:07 ---
i concur, it is a libgfortran bug.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17992