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

[law at redhat dot com]

--- Additional Comments From law at redhat dot com  2004-12-28 08:22 ---
A few more notes.

I would suggest starting the testcase in comment #8.  While the simpler
testcase shows the underlying issue, it's simplified so far that the "problem"
could be fixed in various ways which totally avoid the copy, but which do not
help the larger testcases.

If we go back to the testcase in comment #8 and analyze the code closely we
will see that a copy is inevitable.  If we copy propagate into the PHI, then
the copy gets inserted into its own block.  If we do not copy propagate
into the PHI, then the copy sits just before the loop exit test.  Having the
copy before the loop exit test rather than splitting the loop backedge is
better for a number of reasons.

So the issue at hand is not an extraneous copy, but instead the *placement*
of that copy.

We queue the copy to be inserted on the backedge of the loop, which is clearly
a correct insertion point.  However, if we use life analysis we can determine
that we can place the copy before the loop exit test.  The out-of-ssa code
computes object lifetimes, so, in theory we have the information we need.

What we'd need to do is enhance the copy placement code to be a little smarter
when we want to insert a copy on a critical edge.  Given a copy dest = src 
that we want to place on a critical edge E, we'd want to check if dest is
live on any of the other edges in e->src->succs -- if dest is not live on
any of those edges, then we can place the copy at the end of e->src.  Or
something along those lines.

I have no idea how hard that would be to implement within the current
out-of-ssa framework we have in place.

It's worth nothing that copy placement on loop backedges for out-of-ssa has
been an area that has been problematical before.  I ran into a number of
regressions in the RTL SSA code with poor placements (mostly in ways that
confused the old old rtl loop optimizers).  So it's not a _huge_ surprise
that we're seeing some issues in the same areas with the tree out-of-ssa code.



-- 


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

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

[law at redhat dot com]

--- Additional Comments From law at redhat dot com  2004-12-28 09:17 ---
One final set of notes before I sign off for the night.

Daniel -- thanks for the pointers to the new papers.  I've studied Sreedhar's
algorith in the past and thought it looked promising -- it's good to see 
some hard #s comparing it to Briggs.  I'm not convinced Sreedhar's is
simpler to implement, but it does look like it's worth some effort.

I'm not yet sure if Sreedhar's algorithm will result in a better placement
for the copy in this testcase or not.  I'll have to re-review the algorithm.

-- 


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

[Bug target/14631] common subexpression elimilation error with sse2 instrinsic _mm_insert_epi16

[uros at kss-loka dot si]

--- Additional Comments From uros at kss-loka dot si  2004-12-28 09:54 
---
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01999.html

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |uros at kss-loka dot si
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2004-06-20 05:14:22 |2004-12-28 09:54:04
   date||


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

[Bug rtl-optimization/19103] [4.0 Regression] Current CVS (2004/12/21) doesn't compile with profiledbootstrap

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-28 
10:33 ---
Subject: Bug 19103

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-12-28 10:33:43

Modified files:
gcc: ChangeLog loop-iv.c 

Log message:
PR rtl-optimization/19103
* loop-iv.c (iv_number_of_iterations): Fix typo.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6969&r2=2.6970
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/loop-iv.c.diff?cvsroot=gcc&r1=2.25&r2=2.26



-- 


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

[Bug rtl-optimization/19103] [4.0 Regression] Current CVS (2004/12/21) doesn't compile with profiledbootstrap

[rakdver at gcc dot gnu dot org]

--- Additional Comments From rakdver at gcc dot gnu dot org  2004-12-28 
10:34 ---
Fixed.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug java/19173] New: problems resolving classes

[ora dot et dot labora at web dot de]

GCJ appears to have a problem with statement 'import .*' 
in  case  all  files  to  be  imporated are given as compilation 
arguments. The very same works fine using SUN's javac compiler.

{* Upps, how can I upload  something here? Anyway, the whole sub-
ject has been investigated by Tom ([EMAIL PROTECTED]) and a small
demo project has been sent. *}

Here's a literal description of the demo project: This
are the project files:

 $ tar zxvf xxx.tgz
 xxx/
 xxx/impl/
 xxx/impl/Echo.java
 xxx/hello.java

This is the file's contents: 

 hello.java =
package greeting;

import greeting.impl.*;

public class hello {
  static Echo myecho;
}
 Echo.java ==
package greeting.impl;
public class Echo {}


Now I'm going to compile the whole package in one shot:

 $ cd xxx
 javac -d . -C hello.java impl/Echo.java   # ok

=>> Works fine!

Remove files created by 'javac':

 $ rm -rf greeting

Try to compile the very same using gcj:

 $ gcj -d . -C hello.java impl/Echo.java 
 hello.java:3: error: Can't find default package `greeting.impl'. \
 Check the CLASSPATH environment variable and the access to the archives
 1 error

The problem appears to be related to 

 import hello.impl.*;

in hello.java. When changing to read

 import hello.impl.Echo ;

compilation using gcj works fine. Another option is to 
rename directory "xxx" into "greeting" and to use -I ..,
ie.

 $ cd ..
 $ mv xxx greeting
 $ cd greeting
 $ gcj -d . -I .. -C hello.java impl/Echo.java

-- 
   Summary: problems resolving classes
   Product: gcc
   Version: 3.4.3
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ora dot et dot labora at web dot de
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org,tromey at redhat dot com
 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=19173

[Bug java/19173] problems resolving classes

[ora dot et dot labora at web dot de]

--- Additional Comments From ora dot et dot labora at web dot de  
2004-12-28 11:05 ---
Created an attachment (id=7835)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7835&action=view)
original demo project for bug 19173

Ahh, here we go. The initial bug reporting page should mention that an
attachment might be added  a f t e r  having commited the bug report. 

-- 


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

[Bug regression/19174] New: wrong code regression or library problem in gcc-4.0-20041226

[andre dot maute at gmx dot de]

consider the following code snippet 
 
 nan.cc --- 
#include  
int main() { 
double x = 0.8023; 
std::cout << x << " "; 
std::cout << x << " "; 
std::cout << std::endl; 
return 0; 
} 
 nan.cc --- 
 
> g++-4.0-20041226 -v 
Using built-in specs. 
Configured with: ../gcc-4.0-20041226/configure --prefix=/opt/gcc-4.0-20041226 
--enable-shared --enable-languages=c,c++ --enable-threads=posix 
--enable-__cxa_atexit --enable-clocale=gnu --disable-nls 
--program-suffix=-4.0-20041226 --with-arch=pentium3 --disable-checking 
Thread model: posix 
gcc version 4.0.0 20041226 (experimental) 
 
> g++-4.0-20041226 nan.cc 
> ldd a.out 
   libstdc++.so.6 => /opt/gcc-4.0-20041226/lib/libstdc++.so.6 (0x40017000) 
   libm.so.6 => /lib/libm.so.6 (0x400fc000) 
   libgcc_s.so.1 => /opt/gcc-4.0-20041226/lib/libgcc_s.so.1 (0x4011f000) 
   libc.so.6 => /lib/libc.so.6 (0x40129000) 
   /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) 
> ./a.out 
0.56 nan 
 
well this nan shouldn't be there 
 
> g++-4.0-20041226 nan.cc -static 
 
> ./a.out 
0.56 0.56 
 
> g++-4.0-20041212 -v 
Reading specs from /opt/gcc-4.0-20041212/lib/gcc/i686-pc-linux-gnu/4.0.0/specs 
Configured with: ../gcc-4.0-20041212/configure --prefix=/opt/gcc-4.0-20041212 
--enable-shared --enable-languages=c,c++ --enable-threads=posix 
--enable-__cxa_atexit --enable-clocale=gnu --disable-nls 
--program-suffix=-4.0-20041212 --with-arch=pentium3 --disable-checking 
Thread model: posix 
gcc version 4.0.0 20041212 (experimental) 
 
> g++-4.0-20041212 nan.cc 
> ldd ./a.out 
   libstdc++.so.6 => /opt/gcc-4.0-20041212/lib/libstdc++.so.6 (0x40017000) 
   libm.so.6 => /lib/libm.so.6 (0x400fb000) 
   libgcc_s.so.1 => /opt/gcc-4.0-20041212/lib/libgcc_s.so.1 (0x4011e000) 
   libc.so.6 => /lib/libc.so.6 (0x40128000) 
   /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) 
 
> ./a.out 
0.56 0.56 
 
g++-4.0-20041212 doesn't have this problem

-- 
   Summary: wrong code regression or library problem in gcc-4.0-
20041226
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andre dot maute at gmx dot de
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug middle-end/19175] New: [3.4 regression] RTL checking failures on i686-pc-linux-gnu

[ghazi at gcc dot gnu dot org]

When configured with --enable-checking=misc,tree,rtl,rtlflag,gc I'm seeing 
extra RTL checking failures with 3.4.x on i686-pc-linux-gnu as seen here:
http://gcc.gnu.org/ml/gcc-testresults/2004-12/msg01282.html

The checking failures all appear to be similar:

gcc.log:gcc.dg/i386-loop-3.c:62: internal compiler error: RTL check: expected 
elt 2 type 'e' or 'u', have '0' (rtx label_ref) in next_active_insn, at emit-
rtl.c:3130
gcc.log:gcc.dg/i386-unroll-1.c:17: internal compiler error: RTL check: expected 
elt 2 type 'e' or 'u', have '0' (rtx label_ref) in next_active_insn, at emit-
rtl.c:3130
gcc.log:gcc.dg/unroll-1.c:16: internal compiler error: RTL check: expected elt 
2 type 'e' or 'u', have '0' (rtx label_ref) in next_active_insn, at emit-
rtl.c:3130
g++.log:g++.dg/opt/longbranch2.C:62: internal compiler error: RTL check: 
expected elt 2 type 'e' or 'u', have '0' (rtx label_ref) in next_active_insn, 
at emit-rtl.c:3130

I don't know if these RTL failures are specific to x86 or not since it's 
crashing in emit-rtl.c.  I don't see these failures with 3.3.x so it's a 
regression.

-- 
   Summary: [3.4 regression] RTL checking failures on i686-pc-linux-
gnu
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ghazi 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
GCC target triplet: i686-pc-linux-gnu


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

[Bug middle-end/19171] causes segfault ICE in GCC 4

[bsdfan3 at users dot sourceforge dot net]

--- Additional Comments From bsdfan3 at users dot sourceforge dot net  
2004-12-28 14:27 ---
(In reply to comment #10)
> (In reply to comment #9)
> > I finally figured out how to get a backtrace from the stage2 compiler, so 
> > here
> > it is (this is from running the posted testcase thru cc1):
> 
> This backtrace does not makes sense as ix86_handle_cdecl_attribute does not
call emit_insn,
> are you sure you don't have an extra patch which is applied wrong?

OK, I updated my CVS to 10-28-04 and I still get this error (same place, too:
the  libgcc2 build is what's failing).  I'll try doing a fresh co.

-- 


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

[Bug regression/19174] wrong code regression or library problem in gcc-4.0-20041226

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-28 
14:29 ---
I cannot reproduce this on powerpc-darwin.

-- 
   What|Removed |Added

   Severity|critical|normal
Summary|wrong code regression or|wrong code regression or
   |library problem in gcc-4.0- |library problem in gcc-4.0-
   |20041226|20041226


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

[Bug java/19173] problems resolving classes

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Severity|critical|normal
   Keywords||rejects-valid


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

[Bug bootstrap/19176] New: static gcc cannot be build (libgcc_eh.a required for static gcc)

[hideishi at graduate dot chiba-u dot jp]

gcc 4.0.0 cannot be bootstrap-ed if ./configure was run with --enable-static
--disable-shared.

This is due to the bug in "gcc/config/darwin.h".

 317 /* -dynamiclib implies -shared-libgcc just like -shared would on 
linux.  */
 318 #define REAL_LIBGCC_SPEC \
 319"%{static|static-libgcc:-lgcc}\
 320 %{!static:%{!static-libgcc:\
 321   %{!Zdynamiclib:%{!shared-libgcc:-lgcc}\
 322   %{shared-libgcc:-lgcc_s -lgcc}} %{Zdynamiclib:-lgcc_s -lgcc}}}"

The REAL_LIBGCC_SPEC states that libgcc.a AND libgcc_eh.a are required for
static gcc.
(Probably copied from linux or i386 or any other spec files.)

However, in powerpc-apple-darwin7.7.0 (and possibly any of powerpc*-*-darwin*)
this "libgcc_eh.a" is not build during the bootstrap procedure (and also not
required).
So, after the first xgcc is build, bootstarp fails at stage1 by the following 
error:

/usr/lib/ld: can't locate file for: -lgcc_eh

To fix, simply sed -e 's/ -lgcc_eh//' the gcc/config/darwin.h file.

-- 
   Summary: static gcc cannot be build (libgcc_eh.a required for
static gcc)
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P2
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hideishi at graduate dot chiba-u dot jp
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: powerpc-apple-darwin7.7.0
  GCC host triplet: powerpc-apple-darwin7.7.0
GCC target triplet: powerpc*-*-*


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

[Bug bootstrap/19176] static gcc cannot be build (libgcc_eh.a required for static gcc)

[hideishi at graduate dot chiba-u dot jp]

--- Additional Comments From hideishi at graduate dot chiba-u dot jp  
2004-12-28 14:37 ---
(In reply to comment #0)
> This is due to the bug in "gcc/config/darwin.h".
> 
>  317 /* -dynamiclib implies -shared-libgcc just like -shared would on
linux.  */
>  318 #define REAL_LIBGCC_SPEC \
>  319"%{static|static-libgcc:-lgcc}\
>  320 %{!static:%{!static-libgcc:\
>  321   %{!Zdynamiclib:%{!shared-libgcc:-lgcc}\
>  322   %{shared-libgcc:-lgcc_s -lgcc}} %{Zdynamiclib:-lgcc_s -lgcc}}}"

I'm sorry. I attached my "EDITED" version of "gcc/config/darwin.h".
The original one can be viewed at
http://sources.redhat.com/cgi-bin/cvsweb.cgi/gcc/gcc/config/darwin.h?cvsroot=gcc&only_with_tag=MAIN

 317 /* -dynamiclib implies -shared-libgcc just like -shared would on 
linux.  */
 318 #define REAL_LIBGCC_SPEC \
 319"%{static|static-libgcc:-lgcc -lgcc_eh}\
 320 %{!static:%{!static-libgcc:\
 321   %{!Zdynamiclib:%{!shared-libgcc:-lgcc -lgcc_eh}\
 322   %{shared-libgcc:-lgcc_s -lgcc}} %{Zdynamiclib:-lgcc_s -lgcc}}}"
 

-- 


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

[Bug bootstrap/19176] static gcc cannot be build (libgcc_eh.a required for static gcc)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-28 
14:39 ---
Really only building static is not supported on darwin.  I will look into the 
problem but only after a week 
if no one else has looked into this.

-- 
   What|Removed |Added

   Severity|critical|minor


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

[Bug driver/16118] Preprocessed source error with -xf77-cpp-input

[roger at eyesopen dot com]

--- Additional Comments From roger at eyesopen dot com  2004-12-28 14:45 
---
The consensus amongst GCC developers is that it would be incorrect/unsafe to
preserve the ".f" file in the shared system /tmp area.  The only reason that
the preprocessed .f file is being placed in /tmp, is to avoid overwriting the
user's source file foo.f in the current directory.  The appropriate solution,
as I've now documented in the GCC manual, is that when explicitly using "-x",
if you require a particular intermediate file from -save-temps, you need to
ensure that it's file name doesn't conflict with the input source name.

In your example, the input source file could be renamed foo.F (as you suggest),
or foo.for, or foo.fpp etc... or perhaps placed in a different subdirectory.

Although not a bug, this PR could potentially be considered an "enhancement
request", but the difficultly of generating a unique file name in the current
directory and informing the user of it's location, would be a technically
complex work-around for what would be considered by many a "user error".
The "-x" and "--language" command line options should be used with care and
are far less preferrable to using the "conventional" file extensions for the
various source file formats.


-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID


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

[Bug target/19162] [4.0 regression] ICE while building libobjc's sendmsg.c

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-28 
14:47 ---
Patch posted here: .

Mine.

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pinskia at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Keywords||patch
   Last reconfirmed|2004-12-26 21:36:08 |2004-12-28 14:47:04
   date||


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

[Bug bootstrap/19176] static gcc cannot be build (libgcc_eh.a required for static gcc)

[hideishi at graduate dot chiba-u dot jp]

--- Additional Comments From hideishi at graduate dot chiba-u dot jp  
2004-12-28 15:04 ---
(In reply to comment #2)
> Really only building static is not supported on darwin.  I will look into the
problem but only after a week 
> if no one else has looked into this.

Yes, I totally agree to your comment.
It is not possible to create a "completely static gcc binary" on darwin.
However, if gcc is built with gcc's shared libraries (i.e. --enable-shared), g++
and gfortran produces binaries that require libgcc_s.dylib for runtime.
In order to distribute gfortran compiled binaries, it is troublesome to handle
with libgcc_s.dylib.
So, what I mean by static gcc is "gcc which produces binaries free of
shared-gcc-libraries".


-- 


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

[Bug bootstrap/19176] static gcc cannot be build (libgcc_eh.a required for static gcc)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-28 
15:16 ---
(In reply to comment #3)
> (In reply to comment #2)
> > Really only building static is not supported on darwin.  I will look into 
> > the
> problem but only after a week 
> > if no one else has looked into this.
> So, what I mean by static gcc is "gcc which produces binaries free of
> shared-gcc-libraries".

And that is a problem, libgcc_s is required for correct running in terms of 
exceptions.
Also it is not hard to cp libgcc_s with libgfortran and such.
Also telling people to set DYLD_LIBRARY_PATH is not hard, people do it all the 
time on linux and almost 
all other unix OS's.

-- 


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

[Bug tree-optimization/18947] [4.0 Regression] [non-UAAT] external inline and normal function of the same name

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-28 
15:27 ---
: Search converges between 2004-04-01-trunk (#447) and 2004-04-10-trunk (#448).

-- 


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

[Bug c/19177] New: Floating-point error with simple subtraction.

[tob at idlehands dot net]

Here's hoping this doesn't get marked as a duplicate of 323, since the summary 
contains the keywords 
"floating-point" and "error."  :)

With the following trivial program, which simply does 20 subtractions, a logic 
error occurs during a 
comparison against the floating point value, believing that o < 0.05 is true 
when o == 0.05.

This is reproducible on multiple processors.  I've tried it with gcc 3.3 on Mac 
OS X 10.3 (powerppc g4), 
as well as gcc 3.3 on Redhat 9.0 (i686) and run into the same result.  (For 
kicks, I did try -ffloat-store, 
as suggested in the 323 thread, but this had no effect).  The problem occurs at 
all optimization levels I 
tried.

int main()
{
float o = 1.0;
while (1)
{
printf("o: %f\n", o);
if (o < 0.05) break;

o -= 0.05;
}

printf("final o: %f\n", o);
return 0;
}

-- 
   Summary: Floating-point error with simple subtraction.
   Product: gcc
   Version: 3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tob at idlehands dot net
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/13830] Invalid covariant type for identical type, friend related

[lerdsuwa at gcc dot gnu dot org]

--- Additional Comments From lerdsuwa at gcc dot gnu dot org  2004-12-28 
15:29 ---
The patch for PR1016 will also fix this bug.  That patch is ready 
and the plan is getting it in after GCC 4.0 is branched.  I am
closing this as a duplicate.

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

-- 
   What|Removed |Added

  BugsThisDependsOn||1016
 Status|ASSIGNED|RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/1016] [DR 166] friend class declarations not observing namespace rules.

[lerdsuwa at gcc dot gnu dot org]

--- Additional Comments From lerdsuwa at gcc dot gnu dot org  2004-12-28 
15:29 ---
*** Bug 13830 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

OtherBugsDependingO||13830
  nThis||
 CC||mattyt-bugzilla at tpg dot
   ||com dot au


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

[Bug c++/12944] [meta-bug] C++ name-lookup problems

[lerdsuwa at gcc dot gnu dot org]

-- 
Bug 12944 depends on bug 13830, which changed state.

Bug 13830 Summary: Invalid covariant type for identical type, friend related
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13830

   What|Old Value   |New Value

 Status|ASSIGNED|RESOLVED
 Resolution||DUPLICATE

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

[Bug c++/15453] Friend declaration treated as a declaration in scope.

[lerdsuwa at gcc dot gnu dot org]

--- Additional Comments From lerdsuwa at gcc dot gnu dot org  2004-12-28 
15:30 ---
The patch for PR1016 will also fix this bug.  That patch is ready 
and the plan is getting it in after GCC 4.0 is branched.  I am
closing this as a duplicate.

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

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/1016] [DR 166] friend class declarations not observing namespace rules.

[lerdsuwa at gcc dot gnu dot org]

--- Additional Comments From lerdsuwa at gcc dot gnu dot org  2004-12-28 
15:30 ---
*** Bug 15453 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||igodard at pacbell dot net


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

[Bug c++/16995] [meta-bug] C++ friend injection

[lerdsuwa at gcc dot gnu dot org]

-- 
Bug 16995 depends on bug 15453, which changed state.

Bug 15453 Summary: Friend declaration treated as a declaration in scope.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15453

   What|Old Value   |New Value

 Status|ASSIGNED|RESOLVED
 Resolution||DUPLICATE

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

[Bug c++/12944] [meta-bug] C++ name-lookup problems

[lerdsuwa at gcc dot gnu dot org]

-- 
Bug 12944 depends on bug 15453, which changed state.

Bug 15453 Summary: Friend declaration treated as a declaration in scope.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15453

   What|Old Value   |New Value

 Status|ASSIGNED|RESOLVED
 Resolution||DUPLICATE

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

[Bug target/16584] -msse2 also enabling -mfpmath=sse option causing illegal instruction errors

[uros at kss-loka dot si]

--- Additional Comments From uros at kss-loka dot si  2004-12-28 15:33 
---
A documentation patch is waiting for review:
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01895.html

I guess that documentation patches doesn't qualify for 'patch' keyword. However,
this bug should be marked as INVALID.

-- 


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

[Bug c/19177] Floating-point error with simple subtraction.

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-28 
15:35 ---
This is your bug, learn how floating point is represented.  The point is that 
.05 is not exactly 
representable in floating point.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

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

[aj at gcc dot gnu dot org]

--- Additional Comments From aj at gcc dot gnu dot org  2004-12-28 15:42 
---
The initial patch to libiberty has been reverted, so this issue 
should be fixed now. 

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug c++/19034] [3.4 Regression] internal compiler error: in cp_tree_equal, at cp/tree.c:1633

[aj at gcc dot gnu dot org]

--- Additional Comments From aj at gcc dot gnu dot org  2004-12-28 16:38 
---
It's fixed 

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug c++/12850] memory consumption for heavy template instantiations tripled since 3.3

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-28 
16:43 ---
(In reply to comment #36)
> The initial CP lexer bugger size is 1:

The same amount of garbage is also done for PR 8361.


Also note I could not compile this source again becuase of the use of long 
double which causes an ICE 
for ppc-darwin but that has been fixed already.

-- 


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

[Bug middle-end/19178] New: internal compiler error: verify_stmts

[aj at gcc dot gnu dot org]

I get the following ICE: 
 
gcc -DHAVE_CONFIG_H -I. -I. -I..`/usr/bin/freetype-config --cflags`  -Wall 
-pedantic -I. -DDATADIR="\"/usr/share/tvtime\"" -DCONFDIR="\"/etc/tvtime\"" 
-DFIFODIR="\"/tmp\"" -D_LARGEFILE64_SOURCE -DLOCALEDIR="\"/usr/share/locale\"" 
-I../plugins -I/usr/X11R6/include -I/usr/include/libxml2   -march=i686 
-mtune=i686 -fmessage-length=0 -Wall -O3 -fomit-frame-pointer -std=gnu99 
-mcpu=pentiumpro -MT tvtime-speedy.o -MD -MP -MF ".deps/tvtime-speedy.Tpo" -c 
-o tvtime-speedy.o speedy.c -v -save-temps 
Using built-in specs. 
Configured with: ../configure --enable-threads=posix --prefix=/usr 
--with-local-prefix=/usr/local --infodir=/usr/share/info 
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib 
--enable-languages=c,c++,objc,f95,java,ada --enable-checking 
--with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit 
--without-system-libunwind i586-suse-linux 
Thread model: posix 
gcc version 4.0.0 20041227 (experimental) (SUSE Linux) 
 /usr/lib/gcc/i586-suse-linux/4.0.0/cc1 -E -quiet -v -I. -I. -I.. 
-I/usr/include/freetype2 -I. -I../plugins -I/usr/X11R6/include 
-I/usr/include/libxml2 -MD tvtime-speedy.d -MF .deps/tvtime-speedy.Tpo -MP -MT 
tvtime-speedy.o -MQ tvtime-speedy.o -DHAVE_CONFIG_H 
-DDATADIR="/usr/share/tvtime" -DCONFDIR="/etc/tvtime" -DFIFODIR="/tmp" 
-D_LARGEFILE64_SOURCE -DLOCALEDIR="/usr/share/locale" speedy.c -march=i686 
-mtune=i686 -std=gnu99-Wall -pedantic -Wall -fmessage-length=0 
-fomit-frame-pointer -O3 -fpch-preprocess -o speedy.i 
ignoring duplicate directory "." 
ignoring duplicate directory "." 
#include "..." search starts here: 
#include <...> search starts here: 
 . 
 .. 
 /usr/include/freetype2 
 ../plugins 
 /usr/X11R6/include 
 /usr/include/libxml2 
 /usr/local/include 
 /usr/lib/gcc/i586-suse-linux/4.0.0/include 
 /usr/lib/gcc/i586-suse-linux/4.0.0/../../../../i586-suse-linux/include 
 /usr/include 
End of search list. 
 /usr/lib/gcc/i586-suse-linux/4.0.0/cc1 -fpreprocessed speedy.i -quiet 
-dumpbase speedy.c -march=i686 -mtune=i686 -auxbase-strip tvtime-speedy.o -O3 
-Wall -pedantic -Wall -std=gnu99 -version -fmessage-length=0 
-fomit-frame-pointer -o speedy.s 
GNU C version 4.0.0 20041227 (experimental) (SUSE Linux) (i586-suse-linux) 
compiled by GNU C version 4.0.0 20041227 (experimental) (SUSE Linux). 
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 
speedy.c: In function 
?composite_colour_alpha_to_packed422_scanline_mmxext?: 
speedy.c:1407: error: Invalid operand to binary operator 
alphaD.3538 
 
speedy.c:1407: internal compiler error: verify_stmts failed. 
Please submit a full bug report, 
with preprocessed source if appropriate.

-- 
   Summary: internal compiler error: verify_stmts
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aj at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i586-pc-linux-gnu
  GCC host triplet: i586-pc-linux-gnu
GCC target triplet: i586-pc-linux-gnu


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

[Bug middle-end/19178] internal compiler error: verify_stmts

[aj at gcc dot gnu dot org]

--- Additional Comments From aj at gcc dot gnu dot org  2004-12-28 16:53 
---
Created an attachment (id=7837)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7837&action=view)
Preprocessed source file


-- 


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

[Bug middle-end/19179] New: internal compiler error: verify_stmts

[aj at gcc dot gnu dot org]

/usr/lib/gcc/i586-suse-linux/4.0.0/cc1 -fpreprocessed i386.i -quiet -dumpbase 
i386.c -march=i686 -mtune=i686 -auxbase-strip i386.o -O2 -Wall -version 
-fmessage-length=0 -o i386.s 
GNU C version 4.0.0 20041227 (experimental) (SUSE Linux) (i586-suse-linux) 
compiled by GNU C version 4.0.0 20041227 (experimental) (SUSE Linux). 
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 
i386.i: In function ?_control87?: 
i386.i:5: error: Invalid operand to binary operator 
maskD.1120 
 
i386.i:5: internal compiler error: verify_stmts failed. 
Please submit a full bug report, 
with preprocessed source if appropriate.

-- 
   Summary:  internal compiler error: verify_stmts
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: aj at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i586-pc-linux-gnu
  GCC host triplet: i586-pc-linux-gnu
GCC target triplet: i586-pc-linux-gnu


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

[Bug middle-end/19179] internal compiler error: verify_stmts

[aj at gcc dot gnu dot org]

--- Additional Comments From aj at gcc dot gnu dot org  2004-12-28 16:59 
---
Note this one could be related to 19178. 

-- 
   What|Removed |Added

Summary| internal compiler error:   |internal compiler error:
   |verify_stmts|verify_stmts


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

[Bug middle-end/19179] internal compiler error: verify_stmts

[aj at gcc dot gnu dot org]

--- Additional Comments From aj at gcc dot gnu dot org  2004-12-28 17:00 
---
Created an attachment (id=7838)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7838&action=view)
Preprocessed source file


-- 


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

[Bug middle-end/19178] internal compiler error: verify_stmts

[aj at gcc dot gnu dot org]

--- Additional Comments From aj at gcc dot gnu dot org  2004-12-28 17:01 
---
Note that #19179 has the same ICE message and comes with a smaller testcase. 

-- 


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

[Bug middle-end/19178] internal compiler error: verify_stmts

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-28 
17:08 ---
This reduces to the same testcase as PR 15740 so closing as a dup.

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug inline-asm/15740] [4.0 Regression] ICE caused by a memory operand in an asm statement

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-28 
17:08 ---
*** Bug 19178 has been marked as a duplicate of this bug. ***

-- 
   What|Removed |Added

 CC||aj at gcc dot gnu dot org


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

[Bug middle-end/19179] internal compiler error: verify_stmts

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-28 
17:09 ---
Likewise for this one too.

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

-- 
   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug inline-asm/15740] [4.0 Regression] ICE caused by a memory operand in an asm statement

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-28 
17:09 ---
*** Bug 19179 has been marked as a duplicate of this bug. ***

-- 


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

[Bug regression/19174] wrong code regression or library problem in gcc-4.0-20041226

[andre dot maute at gmx dot de]

--- Additional Comments From andre dot maute at gmx dot de  2004-12-28 
17:21 ---
Oh i forgot my system triplets, they are all 
i686-pc-linux-gnu 
 
g++-4.0-20041226 -v 
doesn't show the triplet any more, there is only a line 
 
Using built-in specs. 
 
i suggest to remove this new feature for convenience. 

-- 


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

[Bug bootstrap/17383] [4.0 Regression] Building in src dir fails

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-28 
17:40 ---
Subject: Bug 17383

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-12-28 17:40:41

Modified files:
.  : ChangeLog Makefile.def Makefile.in Makefile.tpl 

Log message:
2004-12-28  Paolo Bonzini  <[EMAIL PROTECTED]>

PR bootstrap/17383

* Makefile.def (target_modules): Remove stage parameter,
it is always true now.
* Makefile.tpl (configure-build-[+module+],
configure-target-[+module+]): Always build symlink tree
for the directory and for include.  BUILD_SUBDIR and
TARGET_SUBDIR cannot be . anymore.
* Makefile.in: Regenerate.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/ChangeLog.diff?cvsroot=gcc&r1=1.1040&r2=1.1041
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/Makefile.def.diff?cvsroot=gcc&r1=1.43&r2=1.44
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/Makefile.in.diff?cvsroot=gcc&r1=1.251&r2=1.252
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/Makefile.tpl.diff?cvsroot=gcc&r1=1.121&r2=1.122



-- 


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

[Bug bootstrap/17383] [4.0 Regression] Building in src dir fails

[bonzini at gcc dot gnu dot org]

--- Additional Comments From bonzini at gcc dot gnu dot org  2004-12-28 
17:42 ---
Patch applied.

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/18308] ICE in do_jump, at dojump.c:274

[bonzini at gcc dot gnu dot org]

--- Additional Comments From bonzini at gcc dot gnu dot org  2004-12-28 
17:44 ---
Looking at it.

-- 


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

[Bug tree-optimization/18308] ICE in do_jump, at dojump.c:274

[bonzini at gcc dot gnu dot org]

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |bonzini at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2004-11-05 13:51:36 |2004-12-28 17:45:12
   date||


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

[Bug target/18321] [3.2 regression] mmix-knuth-mmixware testsuite failure: gcc.c-torture/compile/20031023-4.c -O0, -O1

[hp at gcc dot gnu dot org]

--- Additional Comments From hp at gcc dot gnu dot org  2004-12-28 17:47 
---
A bug in the epilogue code: using "int" instead of HOST_WIDE_INT.
This is a regression from 3.2, where the code got a clear error
(the test-case wasn't present there, though):
/gcc/testsuite/gcc.c-torture/compile/20031023-1.c: In function `bar':
/gcc/testsuite/gcc.c-torture/compile/20031023-1.c:38: stack frame too big
A fix seems trivial.

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |hp at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2004-11-08 02:05:47 |2004-12-28 17:47:26
   date||
Summary|mmix-knuth-mmixware |[3.2 regression] mmix-knuth-
   |testsuite failure: gcc.c-   |mmixware testsuite failure:
   |torture/compile/20031023-4.c|gcc.c-
   |-O0, -O1|torture/compile/20031023-4.c
   ||-O0, -O1


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

[Bug target/18329] [4.0 regression] mmix-knuth-mmixware testsuite failure: execute/920501-7.c

[hp at gcc dot gnu dot org]

--- Additional Comments From hp at gcc dot gnu dot org  2004-12-28 17:48 
---
"Accept bug (change status to ASSIGNED)" apparently doesn't assign the bug to
me.  Stupid bugzilla.

-- 
   What|Removed |Added

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


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

[Bug middle-end/19175] [3.4 regression] RTL checking failures on i686-pc-linux-gnu

[roger at eyesopen dot com]

--- Additional Comments From roger at eyesopen dot com  2004-12-28 17:49 
---
Currently bootstrapping and regression testing a fix.

-- 
   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |roger at eyesopen dot com
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-12-28 17:49:29
   date||


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

[Bug target/18329] [4.0 regression] mmix-knuth-mmixware testsuite failure: execute/920501-7.c

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-28 
17:50 ---
(In reply to comment #3)
> "Accept bug (change status to ASSIGNED)" apparently doesn't assign the bug to
> me.  Stupid bugzilla.
Actually it does now, I think you just assigned your self the wrong bug, PR 
18321 is assigned to you 
also already.

-- 


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

[Bug middle-end/19175] [3.4 regression] RTL checking failures on i686-pc-linux-gnu

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |3.4.4


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

[Bug target/18329] [4.0 regression] mmix-knuth-mmixware testsuite failure: execute/920501-7.c

[hp at gcc dot gnu dot org]

--- Additional Comments From hp at gcc dot gnu dot org  2004-12-28 17:53 
---
(In reply to comment #4)
Yeah I noticed.  Mid-air-collision on this notice.  You're acting too fast!
Let's see if bugzilla can unassign as well...

-- 
   What|Removed |Added

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


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

[Bug regression/19174] wrong code regression or library problem in gcc-4.0-20041226

[andre dot maute at gmx dot de]

--- Additional Comments From andre dot maute at gmx dot de  2004-12-28 
18:03 ---
it looks like it is really a library problem. Using the libraries from 
gcc-4.0-20041212 
everything is fine, although nan.cc was nevertheless compiled with 
gcc-4.0-20041226. 
 
> ldd a.out 
   libstdc++.so.6 => /opt/gcc-4.0-20041212/lib/libstdc++.so.6 (0x40017000) 
   libm.so.6 => /lib/libm.so.6 (0x400fb000) 
   libgcc_s.so.1 => /opt/gcc-4.0-20041212/lib/libgcc_s.so.1 (0x4011e000) 
   libc.so.6 => /lib/libc.so.6 (0x40128000) 
   /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) 
> ./a.out 
0.56 0.56 
 

-- 


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

[Bug target/18321] [3.2 regression] mmix-knuth-mmixware testsuite failure: gcc.c-torture/compile/20031023-4.c -O0, -O1

[hp at gcc dot gnu dot org]

--- Additional Comments From hp at gcc dot gnu dot org  2004-12-28 18:08 
---
This isn't a 4.0 regression, it's a 3.2 regression. If you change it again,
please add a comment.

-- 
   What|Removed |Added

Summary|[4.0 regression] mmix-knuth-|[3.2 regression] mmix-knuth-
   |mmixware testsuite failure: |mmixware testsuite failure:
   |gcc.c-  |gcc.c-
   |torture/compile/20031023-4.c|torture/compile/20031023-4.c
   |-O0, -O1|-O0, -O1


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

[Bug target/18321] [3.3/3.4/4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.c-torture/compile/20031023-4.c -O0, -O1

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-28 
18:18 ---
if you mean it is a regression from 3.2, then to mark it as such, not the other 
way around which is what 
you marked it as.

-- 
   What|Removed |Added

Summary|[3.2 regression] mmix-knuth-|[3.3/3.4/4.0 regression]
   |mmixware testsuite failure: |mmix-knuth-mmixware
   |gcc.c-  |testsuite failure: gcc.c-
   |torture/compile/20031023-4.c|torture/compile/20031023-4.c
   |-O0, -O1|-O0, -O1
   Target Milestone|--- |3.4.4


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

[Bug target/18321] [4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.c-torture/compile/20031023-4.c -O0, -O1

[hp at gcc dot gnu dot org]

--- Additional Comments From hp at gcc dot gnu dot org  2004-12-28 18:31 
---
In reply to Comment #6, I did in comment #4.
I also changed the PR title, because [3.2 regression] meant to me a regression
from 3.2.  I see http://gcc.gnu.org/bugs/management.html> says otherwise.
Oh well.  Though as I'm not going to change 3.3 or 3.4 (too odd case, but do
feel free after a build and check), I changed back the title to say 4.0.

-- 
   What|Removed |Added

Summary|[3.3/3.4/4.0 regression]|[4.0 regression] mmix-knuth-
   |mmix-knuth-mmixware |mmixware testsuite failure:
   |testsuite failure: gcc.c-   |gcc.c-
   |torture/compile/20031023-4.c|torture/compile/20031023-4.c
   |-O0, -O1|-O0, -O1


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

[Bug target/18321] [3.3/3.4/4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.c-torture/compile/20031023-4.c -O0, -O1

[hp at gcc dot gnu dot org]

--- Additional Comments From hp at gcc dot gnu dot org  2004-12-28 18:35 
---
...oh right: "needs fixing" isn't the same as "going to be fixed".  Changed
back to 3.3/3.4/4.0.  Gah.

-- 
   What|Removed |Added

Summary|[4.0 regression] mmix-knuth-|[3.3/3.4/4.0 regression]
   |mmixware testsuite failure: |mmix-knuth-mmixware
   |gcc.c-  |testsuite failure: gcc.c-
   |torture/compile/20031023-4.c|torture/compile/20031023-4.c
   |-O0, -O1|-O0, -O1


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

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

[hjl at lucon dot org]

--- Additional Comments From hjl at lucon dot org  2004-12-28 18:37 ---
With the patch applied, gdb 6.3 still dumps core.

-- 


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

[Bug driver/19180] New: How to Add New GCC option

[dpatel at apple dot com]

This is an enhancement request to document step-by-step "How to Add New GCC 
options" guide.
Another request : Need "Documentation" component in Bugzilla.

Reference : http://gcc.gnu.org/ml/gcc/2004-12/msg01147.html

-- 
   Summary: How to Add New GCC option
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dpatel at apple dot com
CC: gcc-bugs at gcc dot gnu dot org


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

[Bug other/19180] How to Add New GCC option

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-28 
18:44 ---
Confirmed, adding a target independent option is easy but adding a target 
dependent is where the 
problem comes in.

-- 
   What|Removed |Added

   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
  Component|driver  |other
 Ever Confirmed||1
   Keywords||documentation
   Last reconfirmed|-00-00 00:00:00 |2004-12-28 18:44:25
   date||


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

[Bug rtl-optimization/19097] [3.4/4.0 regression] Quadratic behavior with many sets for the same register in gcse CPROP

[bonzini at gcc dot gnu dot org]

--- Additional Comments From bonzini at gcc dot gnu dot org  2004-12-28 
18:48 ---
Interestingly, on arm-elf the hog is CSE, because each copy of b is given a
different pseudo.

-- 


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

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

[dberlin at dberlin dot org]

--- Additional Comments From dberlin at dberlin dot org  2004-12-28 18:49 
---
Subject: Re:  [4.0 regression]  gcc generates incorrect
dwarf2 debug info

On Tue, 2004-12-28 at 18:37 +, hjl at lucon dot org wrote:
> --- Additional Comments From hjl at lucon dot org  2004-12-28 18:37 
> ---
> With the patch applied, gdb 6.3 still dumps core.
> 
With the patch applied, we generate correct debug info for the case you
pasted.
I can do nothing more on the gcc side.

In fact, I'm seriously considering *not* applying this patch, because we
still can't guarantee that the base and end addresses won't end up
different anyway.

I'm soliciting opinions from gdb folks and the dwarf2 reflector folks as
we speak, and based on what they say, i'll either apply the patch or
close as wontfix.
In any regard, there is a gdb bug here somewhere that needs to be fixed.





-- 


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

[Bug tree-optimization/18308] ICE in do_jump, at dojump.c:274

[bonzini at gcc dot gnu dot org]

--- Additional Comments From bonzini at gcc dot gnu dot org  2004-12-28 
18:49 ---
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg02012.html

-- 
   What|Removed |Added

   Keywords||patch


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

[Bug fortran/19181] New: ICE and segmentation fault with pointer member in user defined type

[santugi at dptmaths dot ens-cachan dot fr]

ICE and segmentation fault with user defined type containing 
pointer elements when assigning a parameter object to
a non parameter object.

Happen on gcc version 4.0.0 20041226.

To reproduce, compile the following code:

PROGRAM TEST
IMPLICIT NONE

TYPE typea
   INTEGER, DIMENSION(:) , POINTER :: member => NULL()
END TYPE typea

TYPE(typea), PARAMETER:: undefined_a = typea( NULL())  
TYPE(typea) :: a

a=undefined_a

END PROGRAM TEST

No ICE occurs if the parameter keyword is removed.

-- 
   Summary: ICE and segmentation fault with pointer member in user
defined type
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: santugi at dptmaths dot ens-cachan dot fr
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: freebsd
  GCC host triplet: freebsd
GCC target triplet: freebsd


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

[Bug other/19180] How to Add New GCC option

[steven at gcc dot gnu dot org]

-- 
   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-28 18:44:25 |2004-12-28 18:53:10
   date||


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

[Bug fortran/19181] ICE and segmentation fault with pointer member in user defined type

[santugi at dptmaths dot ens-cachan dot fr]

--- Additional Comments From santugi at dptmaths dot ens-cachan dot fr  
2004-12-28 18:54 ---
Created an attachment (id=7839)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7839&action=view)
testcase 

A "minimal" testcase

-- 


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

[Bug fortran/19101] missing & in character continuation not caught

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2004-12-28 19:19 
---
I have a fix which issues the same error twice.

Unfortunately, continuation lines are eaten in the scanner, and there is no real
support for emitting errors from the scanner, as the same line may be rescanned
several times until one of the statement matchers succeeds.  I think the right
line of attack will be to modify the matcher for character literal strings to
deal with the continuation, and to issue the error from there, returning
MATCH_ERROR.

I'll look into doing this.

-- 
   What|Removed |Added

 CC||tobi at gcc dot gnu dot org


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

[Bug web/12360] test

[dberlin at dberlin dot org]

--- Additional Comments From dberlin at gcc dot gnu dot org  2004-12-28 
19:37 ---
Subject: Bug 12360

Testing incoming email address matching.



-- 


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

[Bug fortran/19181] ICE and segmentation fault with pointer member in user defined type

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-28 
20:01 ---
Confirmed, here is the backtrace:
#0  0x0005bb8c in gfc_trans_structure_assign (dest=0x42449d80, expr=0x4240e330) 
at /Users/
pinskia/src/local3/gcc/gcc/fortran/trans-expr.c:1600
#1  0x0005bc08 in gfc_conv_structure (se=0xb760, expr=0x41604450, init=0) 
at /Users/pinskia/
src/local3/gcc/gcc/fortran/trans-expr.c:1703
#2  0x0005a804 in gfc_conv_expr (se=0x41604450, expr=0x41604450) at 
/Users/pinskia/src/local3/
gcc/gcc/fortran/trans-expr.c:1800
#3  0x0005c110 in gfc_trans_assignment (expr1=0x41604300, expr2=0x41604450) at 
/Users/
pinskia/src/local3/gcc/gcc/fortran/trans-expr.c:2173
#4  0x0004ea30 in gfc_trans_code (code=0x41604510) at 
/Users/pinskia/src/local3/gcc/gcc/fortran/
trans.c:495
#5  0x00059020 in gfc_generate_function_code (ns=0x42807800) at 
/Users/pinskia/src/local3/gcc/
gcc/fortran/trans-decl.c:2217
#6  0x0004ec28 in gfc_generate_code (ns=0x42807800) at 
/Users/pinskia/src/local3/gcc/gcc/
fortran/trans.c:679
#7  0x0003590c in gfc_parse_file () at 
/Users/pinskia/src/local3/gcc/gcc/fortran/parse.c:2628
#8  0x0004bd78 in gfc_be_parse_file (set_yydebug=548720) at 
/Users/pinskia/src/local3/gcc/
gcc/fortran/f95-lang.c:266
#9  0x00292bd4 in toplev_main (argc=1096828336, argv=0x4b8a24) at 
/Users/pinskia/src/local3/
gcc/gcc/toplev.c:992
#10 0x1e9c in _start (argc=1, argv=0x4050fb68, envp=0x42807800) at 
/SourceCache/Csu/Csu
-47/crt.c:267


-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-12-28 20:01:04
   date||


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

Bug involving derived template classes in G++ 3.4.3

[John M Collins]

Please "CC" me as I'm not subscribed.

I have the following program segment (cutting down to bare minimum). This has 
worked previously with G++ 3.3.* and earlier.

Classes cut down to bare minimum obviously - the "real" ones made use of "X".

class  A  {
public:
int field1;
};

template class  B : public A  {
public:
int field2;
};

template class C : public B  {
public:
C(int k)  { field1 = k;  }  
//  G++ 3.4.3 complains that "field1" is not defined
void setk(int k) { field1 = k; }
//  Likewise it complains.
};

main()
{
C p(17);

return  0;
}

The problem goes away if I put "this->field1" in there instead of bare 
"field1" thus

C(int k)  { this->field1 = k;  }
void setk(int k) { this->field1 = k; }

-- 
John Collins Xi Software Ltd www.xisl.com

Re: Bug involving derived template classes in G++ 3.4.3

[Andrew Pinski]

On Dec 28, 2004, at 3:26 PM, John M Collins wrote:
Please "CC" me as I'm not subscribed.
I have the following program segment (cutting down to bare minimum). 
This has
worked previously with G++ 3.3.* and earlier.

Read the 3.4.0 release notes.
Thanks,
Andrew Pinski

[Bug fortran/19182] New: Error messages seem to be printed slower

[schnetter at aei dot mpg dot de]

When I compare the speed of the screen output of, say, gcc and gfortran, then 
it seems to me as if gfortran produced its output much more slowly.  gcc's 
output seems to appear line by line, whereas gfortran's output seems to appear 
character by character.  This could be caused by gfortran flushing after every 
character instead of after every line or something similar.  I'm wondering, 
does gfortran do something special when it outputs diagnostic messages?  There 
has to be some difference -- gfortran's messages do look different, as 
gfortran tries to print a cute "pointer" indicating the offending column, 
which gcc does not.

-- 
   Summary: Error messages seem to be printed slower
   Product: gcc
   Version: 4.0.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P2
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: schnetter at aei dot mpg dot de
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=19182

[Bug fortran/19182] Error messages seem to be printed slower

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-28 
20:45 ---
They seem quick to me.

-- 


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

[Bug fortran/19182] Error messages seem to be printed slower

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-28 
20:47 ---
But seems slower than the C or C++ or java.
Java is more compariable in this case as it also outputs the context.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Keywords||diagnostic
   Last reconfirmed|-00-00 00:00:00 |2004-12-28 20:47:27
   date||


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

[Bug target/19115] long double should be changed over to 128bit by default

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-28 
20:51 ---
Confirmed, changing the summary to refect reality.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-12-28 20:51:42
   date||
Summary|__builtin_frexpl and|long double should be
   |std::frexp(long double) |changed over to 128bit by
   |broken  |default


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

Re: Bug involving derived template classes in G++ 3.4.3

[John M Collins]

On Tuesday 28 Dec 2004 20:27, Andrew Pinski wrote:
> On Dec 28, 2004, at 3:26 PM, John M Collins wrote:
> > Please "CC" me as I'm not subscribed.
> >
> > I have the following program segment (cutting down to bare minimum).
> > This has
> > worked previously with G++ 3.3.* and earlier.
>
> Read the 3.4.0 release notes.
>
> Thanks,
> Andrew Pinski

Thank you - I apologise for missing that.

I wonder if I might suggest that the message be expanded in this case - it did 
break a good few lines of code - and the way it's broken is not obvious, for 
example virtual functions in "A" can still be overriden in template class "C" 
with the expected result.

-- 
John Collins Xi Software Ltd www.xisl.com

[Bug middle-end/19164] [3.3/3.4/4.0 Regression] ICE in digest_init or build_vector

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-28 
20:57 ---
This is a regression on all of the open branches.
: Search converges between 2003-07-24-3.3 (#133) and 2003-07-25-3.3 (#134).
: Search converges between 2003-03-31-trunk (#217) and 2003-04-01-trunk (#218).

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  Known to fail||3.3.1 3.4.0 4.0.0
  Known to work||3.3
   Last reconfirmed|-00-00 00:00:00 |2004-12-28 20:57:28
   date||
Summary|ICE in digest_init or   |[3.3/3.4/4.0 Regression] ICE
   |build_vector|in digest_init or
   ||build_vector
   Target Milestone|--- |3.4.4


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

[Bug c++/18384] [3.3/3.4/4.0 Regression] ICE on zero-length array with empty initializer...

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-28 
20:58 ---
Subject: Bug 18384

CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED]   2004-12-28 20:57:56

Modified files:
gcc/cp : ChangeLog 
gcc/testsuite  : ChangeLog 
gcc/cp : decl.c 
Added files:
gcc/testsuite/g++.dg/init: array18.C 

Log message:
PR c++/18384, c++/18327
* decl.c (reshape_init_array): Use UHWI type for max_index_cst
and index.  Convert max_index to size_type_node if it isn't
host_integerp (, 1).

* g++.dg/init/array18.C: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3892.2.188&r2=1.3892.2.189
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3389.2.337&r2=1.3389.2.338
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.1174.2.28&r2=1.1174.2.29
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/init/array18.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.2.1



-- 


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

[Bug c++/17278] [4.0 Regression] 24% C++ compile-time regression in comparison with 3.4.1 at -O1 optimization level

[kgardas at objectsecurity dot com]

--- Additional Comments From kgardas at objectsecurity dot com  2004-12-28 
21:00 ---
Subject: Re:  [4.0 Regression] 24% C++ compile-time regression
 in comparison with 3.4.1 at -O1 optimization level


New comparison is here:
http://gcc.gnu.org/ml/gcc/2004-12/msg01157.html

Good work! :-)

Cheers,
Karel
--
Karel Gardas  [EMAIL PROTECTED]
ObjectSecurity Ltd.   http://www.objectsecurity.com



-- 


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

[Bug middle-end/13776] [4.0 Regression] Many C++ compile-time regression in 4.0-tree-ssa 040120

[kgardas at objectsecurity dot com]

--- Additional Comments From kgardas at objectsecurity dot com  2004-12-28 
21:03 ---
Hello,

New comparison is here:
http://gcc.gnu.org/ml/gcc/2004-12/msg01157.html

Cheers,
Karel

-- 


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

[Bug c++/19159] [4.0 Regression] Undefined symbol: vtable for __cxxabiv1::__vmi_class_type_info

[danglin at gcc dot gnu dot org]

--- Additional Comments From danglin at gcc dot gnu dot org  2004-12-28 
21:38 ---
Mark,

I believe that you got the vtable for the typeinfo nodes.  However, we
still have errors like the following:

Executing on host: /opt/build/dave/gcc-4.0.0/objdir/gcc/g++ -shared-libgcc -B/op
t/build/dave/gcc-4.0.0/objdir/gcc/ -nostdinc++ -L/opt/build/dave/gcc-4.0.0/objdi
r/powerpc-ibm-aix4.3.3.0/libstdc++-v3/src -L/opt/build/dave/gcc-4.0.0/objdir/pow
erpc-ibm-aix4.3.3.0/libstdc++-v3/src/.libs -B/home/dave/opt/gnu/gcc/gcc-4.0.0/po
werpc-ibm-aix4.3.3.0/bin/ -B/home/dave/opt/gnu/gcc/gcc-4.0.0/powerpc-ibm-aix4.3.
3.0/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-4.0.0/powerpc-ibm-aix4.3.3.0/includ
e -isystem /home/dave/opt/gnu/gcc/gcc-4.0.0/powerpc-ibm-aix4.3.3.0/sys-include -
g -O2 -D_GLIBCXX_ASSERT -fmessage-length=0 -DLOCALEDIR="/opt/build/dave/gcc-4.0.
0/objdir/powerpc-ibm-aix4.3.3.0/libstdc++-v3/po/share/locale" -nostdinc++ -I/opt
/build/dave/gcc-4.0.0/objdir/powerpc-ibm-aix4.3.3.0/libstdc++-v3/include/powerpc
-ibm-aix4.3.3.0 -I/opt/build/dave/gcc-4.0.0/objdir/powerpc-ibm-aix4.3.3.0/libstd
c++-v3/include -I/opt/build/dave/gcc-4.0.0/gcc/libstdc++-v3/libsupc++ -I/opt/bui
ld/dave/gcc-4.0.0/gcc/libstdc++-v3/include/backward -I/opt/build/dave/gcc-4.0.0/
gcc/libstdc++-v3/testsuite /opt/build/dave/gcc-4.0.0/gcc/libstdc++-v3/testsuite/
17_intro/header_istream.cc-include bits/stdc++.h  -L/opt/build/dave/gcc-4.0.
0/objdir/powerpc-ibm-aix4.3.3.0/./libstdc++-v3/testsuite -lv3test -lm   -o ./hea
der_istream.exe(timeout = 300)
/opt/build/dave/gcc-4.0.0/objdir/powerpc-ibm-aix4.3.3.0/libstdc++-v3/include/bit
s/valarray_array.h:164: warning: inline function 'static void std::_Array_copy_c
tor<_Tp, true>::_S_do_it(const _Tp*, const _Tp*, _Tp*) [with _Tp = size_t]' used
 but never defined
ld: 0711-317 ERROR: Undefined symbol: vtable for std::basic_istringstream, std::allocator >
ld: 0711-317 ERROR: Undefined symbol: vtable for std::basic_stringbuf, std::allocator >
ld: 0711-317 ERROR: Undefined symbol: vtable for std::basic_streambuf >
ld: 0711-317 ERROR: Undefined symbol: VTT for std::basic_istringstream, std::allocator >
ld: 0711-317 ERROR: Undefined symbol: vtable for std::basic_ios >
ld: 0711-317 ERROR: Undefined symbol: VTT for std::basic_ifstream >
ld: 0711-317 ERROR: Undefined symbol: vtable for std::basic_ifstream >
ld: 0711-317 ERROR: Undefined symbol: vtable for std::basic_filebuf >
ld: 0711-317 ERROR: Undefined symbol: vtable for std::basic_ostringstream, std::allocator >
ld: 0711-317 ERROR: Undefined symbol: VTT for std::basic_ostringstream, std::allocator >
ld: 0711-317 ERROR: Undefined symbol: std::basic_string<__gnu_cxx::character, std::char_traits<__gnu_cxx::character >, std::allocator<__gnu_cxx::character > >::_Rep::_S_max_size
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
collect2: ld returned 8 exit status
compiler exited with status 1


-- 


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

[Bug fortran/19182] Error messages seem to be printed slower

[tobi at gcc dot gnu dot org]

--- Additional Comments From tobi at gcc dot gnu dot org  2004-12-28 21:41 
---
Does changing fputc to putc in line 95 of error.c enhance your 'experience'?

-- 


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

[Bug fortran/19182] Error messages seem to be printed slower

[schnetter at aei dot mpg dot de]

--- Additional Comments From schnetter at aei dot mpg dot de  2004-12-28 
22:31 ---
I didn't try the putc vs. fputc change, but the patch below makes all the 
difference: 
 
$ cvs diff -u error.c 
Index: error.c 
=== 
RCS file: /cvs/gcc/gcc/gcc/fortran/error.c,v 
retrieving revision 1.8 
diff -u -r1.8 error.c 
--- error.c 16 Sep 2004 16:00:41 -  1.8 
+++ error.c 28 Dec 2004 22:26:52 - 
@@ -74,6 +74,13 @@ 
 static void 
 error_char (char c) 
 { 
+  static int bufset = 0; 
+  if (! bufset) 
+{ 
+  setvbuf (stderr, 0, _IOLBF, 0); 
+  bufset = 1; 
+} 
+ 
   if (buffer_flag) 
 { 
   if (use_warning_buffer) 
 
The call to setvbuf switches to line buffering, meaning that stderr is flushed 
only after every line and not after every character.  I assume that cc1 (as 
opposed to f951) switches to line buffered stderr at some time, or else 
outputs its error messages in some other way which is equivalent to some 
internal buffering.  f951 outputs its messages character by character, which 
leads to an unnecessary overhead. 

-- 


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

[Bug middle-end/17278] [4.0 Regression] 8% C++ compile-time regression in comparison with 3.4.1 at -O1 optimization level

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-28 
22:33 ---
Now only 8%.

-- 
   What|Removed |Added

  Component|c++ |middle-end
Summary|[4.0 Regression] 24% C++|[4.0 Regression] 8% C++
   |compile-time regression in  |compile-time regression in
   |comparison with 3.4.1 at -O1|comparison with 3.4.1 at -O1
   |optimization level  |optimization level


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

Re: [Bug fortran/19182] Error messages seem to be printed slower

[Andrew Pinski]

On Dec 28, 2004, at 5:31 PM, schnetter at aei dot mpg dot de wrote:
The call to setvbuf switches to line buffering, meaning that stderr is 
flushed
only after every line and not after every character.  I assume that 
cc1 (as
opposed to f951) switches to line buffered stderr at some time, or else
outputs its error messages in some other way which is equivalent to 
some
internal buffering.  f951 outputs its messages character by character, 
which
leads to an unnecessary overhead.
Actually cc1 just uses fprintf instead of fputc so maybe that is the
problem, maybe we should be doing our own buffering.
-- Pinski

[Bug fortran/19182] Error messages seem to be printed slower

[pinskia at physics dot uc dot edu]

--- Additional Comments From pinskia at physics dot uc dot edu  2004-12-28 
22:34 ---
Subject: Re:  Error messages seem to be printed slower


On Dec 28, 2004, at 5:31 PM, schnetter at aei dot mpg dot de wrote:

>
> The call to setvbuf switches to line buffering, meaning that stderr is 
> flushed
> only after every line and not after every character.  I assume that 
> cc1 (as
> opposed to f951) switches to line buffered stderr at some time, or else
> outputs its error messages in some other way which is equivalent to 
> some
> internal buffering.  f951 outputs its messages character by character, 
> which
> leads to an unnecessary overhead.

Actually cc1 just uses fprintf instead of fputc so maybe that is the
problem, maybe we should be doing our own buffering.


-- Pinski



-- 


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

[Bug middle-end/17278] [4.0 Regression] 8% C++ compile-time regression in comparison with 3.4.1 at -O1 optimization level

[kgardas at objectsecurity dot com]

--- Additional Comments From kgardas at objectsecurity dot com  2004-12-28 
22:39 ---
Subject: Re:  [4.0 Regression] 8% C++ compile-time
 regression in comparison with 3.4.1 at -O1 optimization level


On Tue, 28 Dec 2004, pinskia at gcc dot gnu dot org wrote:

> Now only 8%.

True for typecode.cc, but not for ir.cc where there is ~28% regression.

Cheers,
Karel



-- 


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

[Bug middle-end/17278] [4.0 Regression] 8% C++ compile-time regression in comparison with 3.4.1 at -O1 optimization level

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-28 
22:40 ---
(In reply to comment #18)
> Subject: Re:  [4.0 Regression] 8% C++ compile-time
>  regression in comparison with 3.4.1 at -O1 optimization level
> 
> 
> On Tue, 28 Dec 2004, pinskia at gcc dot gnu dot org wrote:
> 
> > Now only 8%.
> 
> True for typecode.cc, but not for ir.cc where there is ~28% regression.

PR 13776 is keeping track of that regression.
This one is for typecode.cc.


-- 


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

[Bug middle-end/17278] [4.0 Regression] 8% C++ compile-time regression in comparison with 3.4.1 at -O1 optimization level

[kgardas at objectsecurity dot com]

--- Additional Comments From kgardas at objectsecurity dot com  2004-12-28 
22:42 ---
Subject: Re:  [4.0 Regression] 8% C++ compile-time
 regression in comparison with 3.4.1 at -O1 optimization level

On Tue, 28 Dec 2004, pinskia at gcc dot gnu dot org wrote:

> > On Tue, 28 Dec 2004, pinskia at gcc dot gnu dot org wrote:
> >
> > > Now only 8%.
> >
> > True for typecode.cc, but not for ir.cc where there is ~28% regression.
>
> PR 13776 is keeping track of that regression.
> This one is for typecode.cc.

Err, you are right! Sorry for that.

Karel



-- 


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

[Bug ada/19183] New: GNAT -fPIC Bug

[ddavenpo at ball dot com]

This error does not occur without the -fPIC option.

+===GNAT BUG DETECTED==+
| 3.4.2 (sparc-sun-solaris2.8) Constraint_Error SIGSEGV|
| Error detected at parm_tbl.ads:39:9  |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Include the entire contents of this bug box in the report.   |
| Include the exact gcc or gnatmake command that you entered.  |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files).   |
+==+

33 % gcc -c -I../source/ -fPIC ../source/parm_tbl.ads
36 % gcc -v
Reading specs from /data/local/bin/../lib/gcc/sparc-sun-solaris2.8/3.4.2/specs
Configured with: /data/buildgcc/gcc-3.4.2/configure --enable-languages=ada,c,c++
Thread model: posix
gcc version 3.4.2

with Global_Defs;

package Parm_Tbl is

   CIDS : constant STRING := "$Id: parm_tbl.1.ada,v 1.3 04/21/2004 16:11:00 bill
Exp $";

   PARAMETER_TABLE_SIZE : constant := 10_000;

   subtype PARAMETER_TABLE_TYPE is
  Global_Defs.WORD_ARRAY( 0 .. PARAMETER_TABLE_SIZE - 1 );

   subtype PARAMETER_BYTES_TABLE_TYPE is
  Global_Defs.BYTE_ARRAY( 0 .. PARAMETER_TABLE_TYPE'Last *
Global_Defs.BYTES_PER_WORD );

   type FULL_PARAMETER_TABLE_TYPE is
  record
 Version  : Global_Defs.WORD32;
 Element  : PARAMETER_TABLE_TYPE;
   end record;

   Full_Parameter_Table : FULL_PARAMETER_TABLE_TYPE;

   Parameter_Table  : PARAMETER_TABLE_TYPE;
   for Parameter_Table'Address use Full_Parameter_Table.Element'Address;

   Parameter_Byte_Table : PARAMETER_BYTES_TABLE_TYPE;
   for Parameter_Byte_Table'Address use Parameter_Table'Address;

end Parm_Tbl;

with Interfaces;
with Ada.Numerics;
with System.Storage_Elements;

package Global_Defs is

   Id : constant String :=
  "$Id: global_defs.1.ada,v 1.6 11/17/2003 22:44:43 jeff Exp $";

   --*
   -- Type declarations
   --*

   -- Floating Point

   subtype REAL32 is FLOAT;
   subtype REAL is LONG_FLOAT;

   -- Signed Integer

   subtype INT16 is Interfaces.INTEGER_16;
   subtype INT32 is Interfaces.INTEGER_32;

   -- Unsigned Integer

   BYTE_SIZE : constant := 8;-- in bits

   WORD_SIZE : constant := 2 * BYTE_SIZE; -- in bits

   WORD32_SIZE : constant := 4 * BYTE_SIZE; -- in bits

   BYTES_PER_WORD32 : constant := WORD32_SIZE / BYTE_SIZE;

   BYTES_PER_WORD : constant := WORD_SIZE / BYTE_SIZE;

   WORDS_PER_WORD32 : constant := WORD32_SIZE / WORD_SIZE;

   type BYTE is new Interfaces.UNSIGNED_8;

   type WORD is new Interfaces.UNSIGNED_16;

   type WORD32 is new Interfaces.UNSIGNED_32;

   type BYTE_PTR is access BYTE;

   type WORD_PTR is access WORD;

   type WORD32_PTR is access WORD32;

   type BYTE_ARRAY is array (NATURAL range <>) of BYTE;
   pragma Pack (BYTE_ARRAY);

   type WORD_ARRAY is array (NATURAL range <>) of WORD;
   pragma Pack (WORD_ARRAY);

   type WORD32_ARRAY is array (NATURAL range <>) of WORD32;
   pragma Pack (WORD32_ARRAY);

   -- Misc. enumeration types
   type USABILITY_TYPE is (Good, Coarse, Bad);
   for USABILITY_TYPE use (Good => 0, Coarse => 1, Bad => 2);

   type STORAGE_BYTE_ARRAY is new System.Storage_Elements.STORAGE_ARRAY;
   pragma Pack (STORAGE_BYTE_ARRAY);

   type BIT32 is mod 2 ** 5;

   type BIT32_ARRAY is array (BIT32'Range) of BOOLEAN;
   pragma Pack (BIT32_ARRAY);
   for BIT32_ARRAY'Size use WORD32_SIZE;

   -- units

   subtype RADIANS is REAL;
   subtype RAD_CYCLE is REAL;   -- radians/cycle
   subtype RAD_CYCLE_RAD is REAL;   -- radians/cycle/radian
   subtype RAD_CYCLE_SQ is REAL;-- radians/cycle**2
   subtype RAD_SEC is REAL; -- radians/second
   subtype RAD_SEC_SQ is REAL;  -- radians/second**2

   subtype DEGREES is REAL;

   subtype KGM_SQ is REAL;  -- kilograms**2

   subtype KILOMETERS is REAL;
   subtype KM_SQ is REAL;   -- kilometers**2
   subtype KILOMETERS_PER_SECOND is REAL;
   subtype KILOMETERS_PER_SECOND_SQ is REAL;  -- km/sec**2

   subtype METERS is REAL;

   subtype NM is REAL;-- Newton x meters (measure of torque)
   subtype NMS is REAL;   -- Newtons x meters x seconds

   subtype RPM is REAL;   -- revolutions per minute


   --*
   --*
   -- Constant definitions
   --*
   --*

   PI : constant REAL := Ada.Numerics.PI;
   TWO_PI : constant REAL := 2.0 * PI;
   HALF_PI : constant REAL := PI / 2.0;

   DEGREES_TO_

[Bug target/18916] [4.0 Regression] mis-aligned vector code with copy memory (-maltivec)

[geoffk at gcc dot gnu dot org]

--- Additional Comments From geoffk at gcc dot gnu dot org  2004-12-28 
23:05 ---
Why can't we make sure that temporaries which should be aligned to 128 bits are 
actually aligned to 
128 bits?  Surely failing to do so will cause other problems.

-- 


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

[Bug target/18321] [3.3/3.4/4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.c-torture/compile/20031023-4.c -O0, -O1

[cvs-commit at gcc dot gnu dot org]

--- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-12-28 
23:19 ---
Subject: Bug 18321

CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED]   2004-12-28 23:19:13

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

Log message:
PR target/18321
* config/mmix/mmix.c (mmix_expand_epilogue): Change type of
variable offset to HOST_WIDE_INT.  Remove obsolete comment.  Fix
spacing.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6973&r2=2.6974
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/mmix/mmix.c.diff?cvsroot=gcc&r1=1.72&r2=1.73



-- 


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

[Bug target/18321] [3.3/3.4/4.0 regression] mmix-knuth-mmixware testsuite failure: gcc.c-torture/compile/20031023-4.c -O0, -O1

[hp at gcc dot gnu dot org]

--- Additional Comments From hp at gcc dot gnu dot org  2004-12-28 23:27 
---
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg02020.html>

-- 
   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|3.4.4   |4.0.0


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

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

[law at redhat dot com]

--- Additional Comments From law at redhat dot com  2004-12-28 23:31 ---
Yea, the code I've got lying around here to undo unprofitable const/copy
propagations definitely helps this code.   And better yet, we don't need
the full-blown version (which is queued for 4.1).  We can get by with the
very simplistic version.   For the testcase in comment #8 we generate the
following .optimized dump:

  # BLOCK 0
  # PRED: ENTRY [100.0%]  (fallthru,exec)
:;
  # SUCC: 1 [100.0%]  (fallthru,exec)

  # BLOCK 1
  # PRED: 0 [100.0%]  (fallthru,exec) 1 [89.0%]  (dfs_back,false,exec)
:;
  temp1 = temp2 * xlvj_ - temp3 * zlvj_;
  temp3 = temp2 * zlvj_ + temp3 * xlvj_;
  temp2 = temp1;
  if (temp3 != 0) goto ; else goto ;
  # SUCC: 2 [11.0%]  (loop_exit,true,exec) 1 [89.0%]  (dfs_back,false,exec)

  # BLOCK 2
  # PRED: 1 [11.0%]  (loop_exit,true,exec)
:;
  return yv1j_ * yv2j_;
  # SUCC: EXIT [100.0%]

}


-- 


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

[Bug ada/19183] GNAT -fPIC Bug

[pinskia at gcc dot gnu dot org]

-- 
   What|Removed |Added

   Keywords||ice-on-valid-code


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

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

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-28 
23:52 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-12-28 23:52:56
   date||


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

[Bug tree-optimization/19126] Missed IV optimization (redundant instruction in loop)

[pinskia at gcc dot gnu dot org]

--- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-28 
23:54 ---
Confirmed.

-- 
   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
   Last reconfirmed|-00-00 00:00:00 |2004-12-28 23:54:33
   date||


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

[Bug target/15873] [3.3 only] hidden symbol `__floatsidf' is referenced by DSO

[rth at gcc dot gnu dot org]

--- Additional Comments From rth at gcc dot gnu dot org  2004-12-29 00:23 
---
This is virtually certain to be a bug in either pam or some other system
library that you're linking with.  The error message means that someone
didn't link some shared library against libgcc.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID


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