[Bug rtl-optimization/28071] [4.1/4.2 regression] A file that can not be compiled in reasonable time/space

[ebotcazou at gcc dot gnu dot org]

--- Comment #35 from ebotcazou at gcc dot gnu dot org  2006-08-11 07:17 
---
Jan, I'm assigning it to you since you have already spent a fair amount of time
on it and made significant progress.  Thanks for tackling the hard stuff.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug rtl-optimization/21299] [4.0/4.1/4.2 Regression] internal error on invalid asm statement

[ebotcazou at gcc dot gnu dot org]

--- Comment #7 from ebotcazou at gcc dot gnu dot org  2006-08-11 07:26 
---
Jan posted a patch 3 days ago.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug rtl-optimization/28386] [4.1 regression] Wrong code with if condition in loop

[ebotcazou at gcc dot gnu dot org]

--- Comment #4 from ebotcazou at gcc dot gnu dot org  2006-08-11 07:31 
---
Investigating.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ebotcazou at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-07-14 20:10:03 |2006-08-11 07:31:09
   date||


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

[Bug rtl-optimization/24497] [4.0 Regression] internal compiler error: in apply_opt_in_copies, at loop-unroll.c:2122

[ebotcazou at gcc dot gnu dot org]

--- Comment #8 from ebotcazou at gcc dot gnu dot org  2006-08-11 07:33 
---
Paul, could you update the status of this PR?  Thanks in advance.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org
 Status|ASSIGNED|WAITING


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

[Bug rtl-optimization/23454] [4.0 regression] ICE in invert_exp_1, at jump.c:1719

[ebotcazou at gcc dot gnu dot org]

--- Comment #12 from ebotcazou at gcc dot gnu dot org  2006-08-11 07:36 
---
Investigating.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ebotcazou at gcc dot gnu dot
   |dot org |org
 Status|REOPENED|ASSIGNED
   Last reconfirmed|2005-08-18 18:10:45 |2006-08-11 07:36:20
   date||


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

[Bug rtl-optimization/21767] if-convert leaves invalid REG_EQUAL notes

[ebotcazou at gcc dot gnu dot org]

--- Comment #7 from ebotcazou at gcc dot gnu dot org  2006-08-11 07:40 
---
The 3.4 branch is closed and the 4.0 branch in deep sleep mode.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org
 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.1.0


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

[Bug middle-end/28651] [4.0/4.1 Regression] signed compare incorrectly false for (int)(U+4)<(int)U where U is unsigned INT_MAX (for optimized x86)

[rguenth at gcc dot gnu dot org]

--- Comment #11 from rguenth at gcc dot gnu dot org  2006-08-11 07:44 
---
Subject: Bug 28651

Author: rguenth
Date: Fri Aug 11 07:44:45 2006
New Revision: 116079

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116079
Log:
2006-08-11  Richard Guenther  <[EMAIL PROTECTED]>

PR middle-end/28651
* simplify-rtx.c (simplify_const_relational_operation):
Simplify A CMP B to A - B CMP 0 only for EQ and NE comparison
codes.

* gcc.c-torture/execute/pr28651.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr28651.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/simplify-rtx.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/4131] The C++ compiler don't place a const class object to ".rodata" section with non trival constructor

[bjoern dot haase at de dot bosch dot com]

--- Comment #15 from bjoern dot haase at de dot bosch dot com  2006-08-11 
07:48 ---
I just realized that yesterday the subject line has been changed.

I'd like to suggest that this new subject line is mis-leading:

The compiler doesn't place ANY object in .rodata . It's not necessary to have
a "non-trivial" constructor.
E.g. have a look at the constructors of the complex class template. There isn't
any statement in the constructor. There is only the initialization of the
member POD for the real and imaginary parts.

If one changes the subject line, I think that 

"the compiler don't place any const class object to .rodata"

would be appropriate.

Bjoern.


-- 


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

[Bug middle-end/28651] [4.0 Regression] signed compare incorrectly false for (int)(U+4)<(int)U where U is unsigned INT_MAX (for optimized x86)

[rguenth at gcc dot gnu dot org]

--- Comment #12 from rguenth at gcc dot gnu dot org  2006-08-11 07:52 
---
Fixed for 4.1.2 and 4.2.0.  No longer blocks PR26847.  Unassigning.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

OtherBugsDependingO|26847   |
  nThis||
 AssignedTo|rguenth at gcc dot gnu dot  |unassigned at gcc dot gnu
   |org |dot org
 Status|ASSIGNED|NEW
  Known to fail|2.95.4 3.3.6 3.4.6 4.0.3|2.95.4 3.3.6 3.4.6 4.0.3
   |4.1.2   |4.1.1
  Known to work|4.2.0   |4.2.0 4.1.2
Summary|[4.0/4.1 Regression] signed |[4.0 Regression] signed
   |compare incorrectly false   |compare incorrectly false
   |for (int)(U+4)<(int)U where |for (int)(U+4)<(int)U where
   |U is unsigned INT_MAX (for  |U is unsigned INT_MAX (for
   |optimized  x86) |optimized  x86)


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

[Bug middle-end/28651] [4.0 Regression] signed compare incorrectly false for (int)(U+4)<(int)U where U is unsigned INT_MAX (for optimized x86)

[rguenth at gcc dot gnu dot org]

--- Comment #13 from rguenth at gcc dot gnu dot org  2006-08-11 07:52 
---
Subject: Bug 28651

Author: rguenth
Date: Fri Aug 11 07:52:01 2006
New Revision: 116080

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116080
Log:
2006-08-11  Richard Guenther  <[EMAIL PROTECTED]>

PR middle-end/28651
* simplify-rtx.c (simplify_const_relational_operation):
Simplify A CMP B to A - B CMP 0 only for EQ and NE comparison
codes.

* gcc.c-torture/execute/pr28651.c: New testcase.

Added:
branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/execute/pr28651.c
  - copied unchanged from r116079,
trunk/gcc/testsuite/gcc.c-torture/execute/pr28651.c
Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/simplify-rtx.c
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug debug/28692] New: ICE in rtl_for_decl_init, at dwarf2out.c

[micis at gmx dot de]

When I compile the small program I get an ICE.
By checking with older compiler versions I found this bug was introduced
between gcc-4.2-20060325 and gcc-4.2-20060401.

Michael Cieslinski


dwarf2out_bug.c:
typedef float FloatVect __attribute__((__vector_size__(16)));
static FloatVect Foo = { 25000.0, 0.0, 0.0, 0.0};


g++42v -g dwarf2out_bug.c
dwarf2out_bug.c:1: internal compiler error: in rtl_for_decl_init, at
dwarf2out.c:9959
Please submit a full bug report, with preprocessed source if appropriate.

g++42v -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.2-20060729/configure --prefix=/usr/local/gcc42v
 --program-suffix=42v --with-arch=opteron --enable-languages=c,c++
 --enable-__cxa_atexit --disable-nls --enable-threads=posix
 --disable-multilib --enable-checking
Thread model: posix
gcc version 4.2.0 20060729 (experimental)


-- 
   Summary: ICE in rtl_for_decl_init, at dwarf2out.c
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: micis at gmx dot de
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug c++/4131] The C++ compiler don't place a const class object to ".rodata" section with non trivial constructor

[pinskia at gcc dot gnu dot org]

--- Comment #16 from pinskia at gcc dot gnu dot org  2006-08-11 08:04 
---
Non trivial is the wording used by the C++ standard which is why I used it. 
(it is also called user defined constructor).


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|The C++ compiler don't place|The C++ compiler don't place
   |a const class object to |a const class object to
   |".rodata" section with non  |".rodata" section with non
   |trival constructor  |trivial constructor


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

[Bug debug/28692] [4.2 Regression] ICE in rtl_for_decl_init, at dwarf2out.c

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|ICE in rtl_for_decl_init, at|[4.2 Regression] ICE in
   |dwarf2out.c |rtl_for_decl_init, at
   ||dwarf2out.c
   Target Milestone|--- |4.2.0


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

[Bug fortran/28660] Spurious warning: 'ubound.6' is used uninitialized in this function

[paul dot richard dot thomas at cea dot fr]

--- Comment #5 from paul dot richard dot thomas at cea dot fr  2006-08-11 
08:06 ---
Try this one!  No matter what you rename 'r' as, the order of execution is
wrong.

program runoptf90

implicit none
real :: x(10)

call simulated_annealing (x)

contains

subroutine simulated_annealing (zzxmin)
real, intent(inout) :: zzxmin(:)
character(LEN = 5+size(zzxmin)) :: x
real :: r(len(x)-2)

zzxmin = r
print *, "here", len(x), size(r)
end subroutine simulated_annealing

end program runoptf90


-- 


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

[Bug rtl-optimization/26847] [4.2 Regression] Missed optimization in simplify_plus_minus

[bonzini at gnu dot org]

--- Comment #3 from bonzini at gnu dot org  2006-08-11 09:15 ---
Created an attachment (id=12062)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12062&action=view)
patch being tested


Tested so far by checking that it makes PR28651 resurface...

Being bootstrapped and tested on i686-pc-linux-gnu.


-- 


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

[Bug target/27827] [4.0/4.1 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3

[uros at kss-loka dot si]

--- Comment #64 from uros at kss-loka dot si  2006-08-11 09:18 ---
Slightly offtopic, but to put some numbers to comment #8 and comment #11,
equivalent SSE code now reaches only 50% of x87 single performance and 60% of
x87 double performance on AMD x86_64:


ALGORITHM NB   REPSTIME  MFLOPS
=  =  =  ==  ==

[float] -O2 -mfpmath=sse -march=k8:
atlasmm   60   1000   0.273 1582.66
[float] -O2 -mfpmath=387 -march=k8:
atlasmm   60   1000   0.138 3130.91

[double] -O2 -mfpmath=sse -march=k8:
atlasmm   60   1000   0.252 1714.54
[double] -O2 -mfpmath=387 -march=k8:
atlasmm   60   1000   0.152 2842.55

This effect was first observed in PR19780.


-- 


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

[Bug c++/28687] [4.2 regression] dynamic_cast disallowed too rigorously with -fno-rtti

[benjamin at smedbergs dot us]

--- Comment #8 from benjamin at smedbergs dot us  2006-08-11 10:19 ---
The documentation is incorrect. RTTI is not required to find the most-derived
class pointer, because the vtable contains this information natively and does
not need to know anything about the type.  I'm making my point from years of
working software, not some theoretical discussion.


-- 


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

[Bug rtl-optimization/19780] Floating point computation far slower for -mfpmath=sse

[bonzini at gnu dot org]

--- Comment #4 from bonzini at gnu dot org  2006-08-11 10:22 ---
Except that PPC uses 12 registers f0 f6 f7 f8 f9 f10 f11 f12 f13 f29 f30 f31. 
Not that we can blame GCC for using 12, but it is not a fair comparison. :-)

In fact, 8 registers are enough, but it is quite tricky to obtain them.
The problem is that v3[xyz] is live across multiple BB's, making the task of
the register allocator quite harder.  Even if we change v3[xyz] in the printf
to v2[xyz], cfg-cleanup (between vrp1 and dce2) replaces it and, in doing so,
it extends the lifetime of v3[xyz].

(Since it's all about having short lifetimes, CCing [EMAIL PROTECTED])

BTW, here is the optimal code (if it works...):

ENTER basic block: v1[xyz], v2[xyz] are live (6 registers)

  v3x = v1y * v2z - v1z * v2y;

v3x is now live, and it takes 2 registers to compute this statement.  Here we
hit a maximum of 8 live registers.  After the statement 7 registers are live.

  v3y = v1z * v2x - v1x * v2z;

v1z dies here, so we need only one additional register for this statement.  We
also hit a maximum of 8 live registers.  At the end of the statement, 7
registers are also live (7 - 1 v1z that dies + 1 for v3y)

  v3z = v1x * v2y - v1y * v2x;

Likewise, v1x and v1y die, so we need 7 registers and, at the end of the
statement, 6 registers are also live.

Optimal code would be like this (%xmm0..2 = v1[xyz], %xmm3..5 = v2[xyz])

v3x = v1y * v2z - v1z * v2y
  movss %xmm1, %xmm6
  mulss %xmm5, %xmm6 ;; v1y * v2z in %xmm6
  movss %xmm2, %xmm7
  mulss %xmm4, %xmm7 ;; v1z * v2y in %xmm7
  subss %xmm7, %xmm6 ;; v3x in %xmm6

v3y = v1z * v2x - v1x * v2z
  mulss %xmm3, %xmm2 ;; v1z dies, v1z * v2x in %xmm2
  movss %xmm1, %xmm7
  mulss %xmm5, %xmm7 ;; v1x * v2z in %xmm7
  subss %xmm7, %xmm2 ;; v3y in %xmm2

v3z = v1x * v2y - v1y * v2x
  mulss %xmm4, %xmm0 ;; v1x dies, v1x * x2y in %xmm0
  mulss %xmm3, %xmm1 ;; v1y dies, v1y * v2x in %xmm1
  subss %xmm1, %xmm0 ;; v3z in %xmm0

Note now how we should reorder the final moves to obtain optimal code!

  movss %xmm0, %xmm7 ;; save v3z... alternatively, do it before the subss

  movss %xmm3, %xmm0 ;; v1x = v2x
  movss %xmm6, %xmm3 ;; v2x = v3x (in %xmm6)
  movss %xmm4, %xmm1 ;; v1y = v2y
  movss %xmm2, %xmm4 ;; v2y = v3y (in %xmm2)
  movss %xmm5, %xmm2 ;; v1z = v2z
  movss %xmm7, %xmm5 ;; v2z = v3z (saved in %xmm7)

(Note that doing the reordering manually does not help...) :-(  Out of
curiosity, can somebody check out yara-branch to see how it fares?


---

By comparison, the x87 is relatively easier, because there are never more than
8 registers and fxch makes it much easier to write the compensation code:

v3x = v1y * v2z - v1z * v2y
;; v1x v1y v1z v2x v2y v2z
   fld %st(1)   ;; v1y v1x v1y v1z v2x v2y v2z
   fmul %st(6), %st(0)  ;; v1y*v2z v1x v1y v1z v2x v2y v2z
   fld %st(3)   ;; v1z v1y*v2z v1x v1y v1z v2x v2y v2z
   fmul %st(6), %st(0)  ;; v1z*v2y v1y*v2z v1x v1y v1z v2x v2y v2z
   fsubp %st(0), %st(1) ;; v3x v1x v1y v1z v2x v2y v2z

v3y = v1z * v2x - v1x * v2z
   fld %st(4)   ;; v2x v3x v1x v1y v1z v2x v2y v2z
   fmulp %st(0), %st(4) ;; v3x v1x v1y v1z*v2x v2x v2y v2z
   fld %st(1)   ;; v1x v3x v1x v1y v1z*v2x v2x v2y v2z
   fmul %st(7), %st(0)  ;; v1x*v2z v3x v1x v1y v1z*v2x v2x v2y v2z
   fsubp %st(0), %st(4) ;; v3x v1x v1y v3y v2x v2y v2z

v3z = v1x * v2y - v1y * v2x
   fld %st(5)   ;; v2y v3x v1x v1y v3y v2x v2y v2z
   fmulp %st(0), %st(2) ;; v3x v1x*v2y v1y v3y v2x v2y v2z
   fld %st(4)   ;; v2x v3x v1x*v2y v1y v3y v2x v2y v2z
   fmul %st(3), %st(0)  ;; v1y*v2x v3x v1x*v2y v1y v3y v2x v2y v2z
   fsubp %st(0), %st(2) ;; v3x v3z v1y v3y v2x v2y v2z
   fstp %st(2)  ;; v3z v3x v3y v2x v2y v2z

   fxch %st(5)  ;; v2z v3x v3y v2x v2y v3z
   fxch %st(2)  ;; v3y v3x v2z v2x v2y v3z
   fxch %st(4)  ;; v2y v3x v2z v2x v3y v3z
   fxch %st(1)  ;; v3x v2y v2z v2x v3y v3z
   fxch %st(0)  ;; v2x v2y v2z v3x v3y v3z

(well, the fxch should be scheduled, but still it is possible to do it without
spilling).

Paolo


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 CC||amacleod at redhat dot com


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

[Bug c++/28687] [4.2 regression] dynamic_cast disallowed too rigorously with -fno-rtti

[gdr at integrable-solutions dot net]

--- Comment #9 from gdr at integrable-solutions dot net  2006-08-11 11:01 
---
Subject: Re:  [4.2 regression] dynamic_cast disallowed too rigorously
with -fno-rtti

"benjamin at smedbergs dot us" <[EMAIL PROTECTED]> writes:

| The documentation is incorrect.

The documentation is what we expect users to follow and what we
promise them.  As far as I can tell, there is no mismatch between the
documentation and the check we do.  So, your assertion is incorrect.

| RTTI is not required to find the most-derived
| class pointer, because the vtable contains this information natively and does
| not need to know anything about the type.

and where do you put and find the vtables?

| I'm making my point from years of working software, not some
| theoretical discussion. 

probabluy; but you're wrong.  Many, you should have a look at the
theory.

-- Gaby


-- 


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

[Bug c++/28687] [4.2 regression] dynamic_cast disallowed too rigorously with -fno-rtti

[gdr at gcc dot gnu dot org]

--- Comment #10 from gdr at gcc dot gnu dot org  2006-08-11 11:03 ---
the behaviour is conformant to the documentation


-- 

gdr at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug java/21624] java source files cannot be compiled to bcabi [indirect dispatch]

[aph at gcc dot gnu dot org]

--- Comment #3 from aph at gcc dot gnu dot org  2006-08-11 11:14 ---
This one wiil get fixed with the merge of the ecj branch.


-- 

aph at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|SUSPENDED


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

[Bug c++/28687] [4.2 regression] dynamic_cast disallowed too rigorously with -fno-rtti

[benjamin at smedbergs dot us]

--- Comment #11 from benjamin at smedbergs dot us  2006-08-11 11:44 ---
I'm not claiming that the behavior isn't conformant to the docs, I'm claiming
that you regressed a construct that

1) doesn't need RTTI at all (in practice)
2) is used by a major software project

And that both the code and the docs should be fixed to make this construct
legal.


-- 


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

[Bug c++/28695] New: Problem compiling Gcc 4.1.1 on a 64 bit linux redhat kernel

[f98faka at chalmers dot se]

I'm running linux redhat, kernel 2.6.9-34.0.1.ELsmp, duel processor AMD Opteron
250. It's on a cluster where I only have write-rights in my user library and
thus need to compile my own version of gcc. 
I downloaded gcc from 

ftp://ftp.mpi-sb.mpg.de/pub/gnu/mirror/gcc.gnu.org/pub/gcc/releases/gcc-4.1.1

I unpacked and altered configure file value: ac_default_prefix to the directory
where I wanted it to be (in this case the same as the one where sources were).
I also tried default value for ac_default_prefix, but it produces the same
error. Running ./configure worked ok, then when i did "make" I got:


/tmp/cc9Ery9d.s: Assembler messages:
/tmp/cc9Ery9d.s:34: Error: suffix or operands invalid for `push'
/tmp/cc9Ery9d.s:36: Error: suffix or operands invalid for `push'
/tmp/cc9Ery9d.s:38: Internal error, aborting at ../../gas/config/tc-i386.c line
3501 in output_imm
Please report this bug.

I can't do a -save-temp since I only run 'make'. It feels like I haven't given
you much information, but I'm not sure what else to give you.


-- 
   Summary: Problem compiling Gcc 4.1.1 on a 64 bit linux redhat
kernel
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: f98faka at chalmers dot se


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

[Bug c/28697] New: Behavior of __extension__ within __asm__ changed with regards to 3.4.4

[konrad dot schwarz at siemens dot com]

Hi,

I compile my code with -pedantic.  My code includes inline assembler, which I
write using __asm__ to avoid warnings.  The string literal containing the
inline code is longer than maximum length allowed by standard C and in GCC
3.4.4, it was possible to prefix the string with __extension__ to avoid the
warning:

warning: string length '1151' is greater than the length '509' ISO C89
compilers are required to support.

So my code looks like this:

__asm__ volatile ( __extension__ "..." ...

and compiles without warnings.

In GCC 4.1, with this syntax, I get an error and a warning:

context_switch.h:12: error: expected string literal before '__extension__'
context_switch.h:12: warning: string length '1151' is greater than the length
'509' ISO C89 compilers are required to support

Removing __extension__ leads to the single warning:

context_switch.h:12: warning: string length '1151' is greater than the length
'509' ISO C89 compilers are required to support

Please reinsert the former behavior of GCC, i.e., allow __extension__ for the
__asm__ string literal, to allow compilation without warnings!

Regards,

Konrad Schwarz


-- 
   Summary: Behavior of __extension__ within __asm__ changed with
regards to 3.4.4
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: konrad dot schwarz at siemens dot com
  GCC host triplet: Probably mingw
GCC target triplet: arm-none-eabi


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

[Bug c++/28687] [4.2 regression] dynamic_cast disallowed too rigorously with -fno-rtti

[gdr at integrable-solutions dot net]

--- Comment #12 from gdr at integrable-solutions dot net  2006-08-11 12:33 
---
Subject: Re:  [4.2 regression] dynamic_cast disallowed too rigorously
with -fno-rtti

"benjamin at smedbergs dot us" <[EMAIL PROTECTED]> writes:

| I'm not claiming that the behavior isn't conformant to the docs, I'm claiming
| that you regressed a construct that

No, we did not regress because the documentation was very explicit.

-- Gaby


-- 


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

[Bug libgcj/28698] New: [gcj] libgcj-bc only used when building shared libs, not executables

[debian-gcc at lists dot debian dot org]

seen on redhat/gcc-4_1-branch, should be seen on upcoming classpath-0.92 merge
as well.

building a shared library avoids the direct dependency on libgcj.so.7 (only
libgcj_gc.so.1 is referenced as NEEDED). 

i.e. gcj \
-O2 -g -Wl,-Bsymbolic -shared -fPIC -fjni -findirect-dispatch \
-o build/dist/ecj.jar.so build/dist/ecj.jar

ecj.jar.so doesn't depend on libgcj.so.7, while building an executable, i.e.

gcj \
   -O2 -g -Wl,-Bsymbolic -fPIC -fjni -findirect-dispatch \
   --main=org.eclipse.jdt.internal.compiler.batch.Main \
   -o build/dist/ecj-bootstrap-gcj build/dist/ecj.jar

still has the dependency on libgcj.so.7.

using the latter compiler is still faster than starting the interpreter and
using the precompiled jar file.

libjava/libgcj.spec does only rename the spec for linking shared libs, not for
linking executables.

  Matthias


-- 
   Summary: [gcj] libgcj-bc only used when building shared libs, not
executables
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org


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

[Bug target/26778] [4.0/4.1/4.2 regression] GCC4 moves the result of a conditional block through inadequate registers

[bonzini at gnu dot org]

--- Comment #8 from bonzini at gnu dot org  2006-08-11 13:18 ---
taking this.


-- 

bonzini at gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |bonzini at gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-03-21 13:13:25 |2006-08-11 13:18:17
   date||


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

[Bug target/27827] [4.0/4.1 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3

[bonzini at gcc dot gnu dot org]

--- Comment #65 from bonzini at gnu dot org  2006-08-11 13:26 ---
Subject: Bug 27827

Author: bonzini
Date: Fri Aug 11 13:25:58 2006
New Revision: 116082

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116082
Log:
2006-08-11  Paolo Bonzini  <[EMAIL PROTECTED]>

PR target/27827
* config/i386/i386.md: Add peephole2 to avoid "fld %st"
instructions.

testsuite:
2006-08-11  Paolo Bonzini  <[EMAIL PROTECTED]>

PR target/27827
* gcc.target/i386/pr27827.c: New testcase.


Added:
branches/gcc-4_1-branch/gcc/testsuite/gcc.target/i386/pr27827.c
  - copied unchanged from r115969,
trunk/gcc/testsuite/gcc.target/i386/pr27827.c
Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/config/i386/i386.md
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug target/28621] [4.1/4.2 Regression] SIGSEGV in set_fast_math () at -Os

[magsilva at gmail dot com]

--- Comment #4 from magsilva at gmail dot com  2006-08-11 13:27 ---
(In reply to comment #3)
> --- config/i386/crtfastmath.c   (revision 115987)
> +++ config/i386/crtfastmath.c   (working copy)
> @@ -38,6 +38,9 @@
>  #define SSE(1 << 25)
> 
>  static void __attribute__((constructor))
> +#ifndef __x86_64__
> +__attribute__ ((force_align_arg_pointer))
> +#endif
>  set_fast_math (void)
>  {
>  #ifndef __x86_64__
> 
> Does it help?

I applied this patch against the gcc 4.1.1, but the bug is still there (at
least procps keeps segfaulting).


-- 


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

[Bug middle-end/28690] [4.2 Regression] Performace problem with indexed load/stores on powerpc

[dje at gcc dot gnu dot org]

--- Comment #1 from dje at gcc dot gnu dot org  2006-08-11 13:29 ---
Confirmed


-- 

dje at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-08-11 13:29:43
   date||
Summary|Performace problem with |[4.2 Regression] Performace
   |indexed load/stores on  |problem with indexed
   |powerpc |load/stores on powerpc


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

[Bug fortran/28660] Spurious warning: 'ubound.6' is used uninitialized in this function

[paul dot richard dot thomas at cea dot fr]

--- Comment #6 from paul dot richard dot thomas at cea dot fr  2006-08-11 
14:08 ---
Created an attachment (id=12066)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12066&action=view)
Prototype fix

The attached runs the testcase below correctly and regtests, except for 
gfortran.fortran-torture/execute/entry_5.f90, on Cygwin_NT/PIV.

I have not had enough time to really check with it is necessary and sufficient,
to fix this one regression nor have I had time to track down the cause of an
irritating but apparently harmless wrinkle - the declaration char z[1:.z]
appears twice; the first time with an incorrect .z and the second with the
correct value for .z.  Fortunately, it is the second declaration that is seen
in the scope of the executable code.

As of tomorrow, I am back on the road again until the end of next week.  If you
want to run with this, please do.  Otherwise, I will complete the job upon my
return.

All the best

Paul

PS I have made some progress on allocatable component derived type
constructors.

PPS This works with the patch:

program runoptf90
implicit none
real :: x(10)
call simulated_annealing1 (x)
call simulated_annealing2 (x)
call simulated_annealing3 (x)
contains
subroutine simulated_annealing1 (xmin)
real, intent(inout) :: xmin(:)
real :: x(size(xmin)+1)
real :: r(size(x)-2)
xmin = r
print *, "#1 ", size(r), size(x)
end subroutine simulated_annealing1
subroutine simulated_annealing2 (xmin)
real, intent(inout) :: xmin(:)
real :: x(size(xmin)+3)
real :: zr(size(x)-6)
xmin = zr
print *, "#2 ", size(zr), size(x)
end subroutine simulated_annealing2
subroutine simulated_annealing3 (xmin)
real, intent(inout) :: xmin(:)
character(size(x)+2) :: y ! host associated x
character(len(y)+3) :: z
real :: r(len(z)-10)
xmin = r
print *, "#3 ", size(r), len(z)
end subroutine simulated_annealing3
end program runoptf90


-- 


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

[Bug target/27827] [4.0 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3

[bonzini at gnu dot org]

--- Comment #66 from bonzini at gnu dot org  2006-08-11 14:10 ---
(on bugzilla because I had problems sending mail to you)

> Just got your most recent update.  From what I can tell, you have applied
> your patch to the 4.1 series, so that the next 4.1 release will have the fix?

Yes.

> So, my question is that I notice the comment says:
>* config/i386/i386.md: Add peephole2 to avoid "fld %st" instructions.
>
> Which, if its what we've been doing should be something like:
>* config/i386/i386.md: Add peephole2 to substitute "fld" for memory-source 
>  "fmul"

No, what my patch does is exactly replacing "fld reg + fmul mem" with "fld mem
+ fmul reg,reg".  Maybe the ChangeLog is not completely descriptive, but the PR
number is there and will make things clear enough.

> BTW, it's going to remain the case that you must do at least -O2 to get
> this peephole invoked?

You can add -fpeephole2.


-- 


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

[Bug tree-optimization/28632] VRP should understand bitwise OR and AND

[vda dot linux at googlemail dot com]

--- Comment #6 from vda dot linux at googlemail dot com  2006-08-11 14:17 
---
Created an attachment (id=12067)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12067&action=view)
New version of the patch. 4.1.1 bootstraps with it.


-- 

vda dot linux at googlemail dot com changed:

   What|Removed |Added

  Attachment #12035|0   |1
is obsolete||


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

[Bug c++/28687] [4.2 regression] dynamic_cast disallowed too rigorously with -fno-rtti

[benjamin at smedbergs dot us]

--- Comment #13 from benjamin at smedbergs dot us  2006-08-11 14:21 ---
ok, leaving aside the pedantic issue of whether this is a "regression" or not,
can we get it fixed? I just posted a patch to gcc-patches which allows
dynamic_cast in cases where RTTI is not required, and adds a note to the
documentation.


-- 


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

[Bug middle-end/28690] [4.2 Regression] Performace problem with indexed load/stores on powerpc

[dberlin at dberlin dot org]

--- Comment #2 from dberlin at gcc dot gnu dot org  2006-08-11 14:33 ---
Subject: Re:  [4.2 Regression] Performace problem with
 indexed load/stores on powerpc


Here is the reassoc patch that puts them in the right order at the tree
level.

Index: tree-ssa-reassoc.c
===
--- tree-ssa-reassoc.c  (revision 115962)
+++ tree-ssa-reassoc.c  (working copy)
@@ -356,6 +356,13 @@ sort_by_operand_rank (const void *pa, co
   && TREE_CODE (oeb->op) == SSA_NAME)
 return SSA_NAME_VERSION (oeb->op) - SSA_NAME_VERSION (oea->op);

+  /* For pointers, most things want the *base* pointer to go first to
+ try indexed loads. The base pointer is the one with the *lesser*
+ rank.  For everything else, put them in order from greatest rank
+ to least.  */
+  if (POINTER_TYPE_P (TREE_TYPE (oea->op)))
+return oea->rank - oeb->rank;
+
   return oeb->rank - oea->rank;
 }

@@ -1309,7 +1316,9 @@ reassociate_bb (basic_block bb)
   if (TREE_CODE (stmt) == MODIFY_EXPR)
{
  tree lhs = TREE_OPERAND (stmt, 0);
+ tree lhst = TREE_TYPE (lhs);
  tree rhs = TREE_OPERAND (stmt, 1);
+ tree rhst = TREE_TYPE (rhs);

  /* If this was part of an already processed tree, we don't
 need to touch it again. */
@@ -1318,10 +1327,10 @@ reassociate_bb (basic_block bb)

  /* If unsafe math optimizations we can do reassociation for
 non-integral types.  */
- if ((!INTEGRAL_TYPE_P (TREE_TYPE (lhs))
-  || !INTEGRAL_TYPE_P (TREE_TYPE (rhs)))
- && (!SCALAR_FLOAT_TYPE_P (TREE_TYPE (rhs))
- || !SCALAR_FLOAT_TYPE_P (TREE_TYPE(lhs))
+ if (((!INTEGRAL_TYPE_P (lhst) & !POINTER_TYPE_P (lhst))
+  || (!INTEGRAL_TYPE_P (rhst) && !POINTER_TYPE_P (rhst)))
+ && (!SCALAR_FLOAT_TYPE_P (rhst)
+ || !SCALAR_FLOAT_TYPE_P (lhst)
  || !flag_unsafe_math_optimizations))
continue;



-- 


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

[Bug c++/28594] [4.2 regression] ICE with invalid template parameter

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.1.2   |4.2.0


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

[Bug c++/28639] [4.2 regression] ICE trying to print error on invalid template parameter

[reichelt at gcc dot gnu dot org]

-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.1.2   |4.2.0


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

[Bug tree-optimization/26197] [4.2 regression] ICE in is_old_name with vectorizer

[reichelt at gcc dot gnu dot org]

--- Comment #20 from reichelt at gcc dot gnu dot org  2006-08-11 14:53 
---
Fixed on mainline.


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug other/28700] New: does not fix broken linux/compiler-gcc+.h

[gcc-bugzilla at gcc dot gnu dot org]

System include file is broken as described in  section.
fixincludes does not create any modification of it, let alone fixed as
described.  Newly built gcc includes broken file when run.  This may
break just any program built with gcc, and does break compiling
`toplev.c' with `stage1/xgcc' as described in bug 28469.

Environment:
System: Linux way2go 2.6.3-27mdk #1 Tue May 31 21:48:42 MDT 2005 i686 unknown
unknown GNU/Linux
Architecture: i686

Old compiler is `gcc-3.3.2-6mdk'.  System headers are
`glibc-devel-2.3.3-12.8.100mdk'.
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ../share/src/gcc-4.0.3/configure --enable-languages=c

How-To-Repeat:
make bootstrap


--- Comment #1 from gin at mo dot msk dot ru  2006-08-11 14:59 ---
Fix:
Currently not known.  Obviously any fixincludes bug (even lack of
fixincludes itself) may be worked around, by doing the necessary
include file editing manually.  (This is why severity is not
critical.)  In this case the workaround is as follows.

  Fix after `compiler-gcc3.h': reverse `#ifndef __KERNEL__'.  If user
  mode code with contains seemingly identical inline function
  definitions before and after this file, type of the 2nd one becomes
  different, which breaks compilation.

--- /usr/include/linux/compiler-gcc+.h  2006/08/10 21:55:37 1.1
+++ /usr/include/linux/compiler-gcc+.h  2006/08/10 22:02:12 1.2
@@ -6,11 +6,11 @@
  */
 #include 

-#ifndef __KERNEL__
+#if defined __KERNEL__
 #define inline __inline__ __attribute__((always_inline))
 #define __inline__ __inline__ __attribute__((always_inline))
 #define __inline   __inline__ __attribute__((always_inline))
-#endif
+#endif /* defined __KERNEL__ */

 #define __deprecated   __attribute__((deprecated))
 #define __attribute_used__ __attribute__((__used__))

Hope this is enough data to patch fixincludes.  Its maintainers
certainly do not have to ask details of includes in my system from me
or other users.  All of them are in

archive.  (Anyway, will be unable to check mail until aug 21.)


-- 
   Summary: does not fix broken linux/compiler-gcc+.h
   Product: gcc
   Version: 4.0.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gin at mo dot msk dot ru
 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=28700

[Bug target/27827] [4.0 Regression] gcc 4 produces worse x87 code on all platforms than gcc 3

[whaley at cs dot utsa dot edu]

--- Comment #67 from whaley at cs dot utsa dot edu  2006-08-11 15:22 ---
Uros,

>Slightly offtopic, but to put some numbers to comment #8 and comment #11,
>equivalent SSE code now reaches only 50% of x87 single performance and 60% of
>x87 double performance on AMD x86_64

FYI, you *may* get slightly better single SSE performance with these flags:
   -fomit-frame-pointer -march=athlon64 -O2 -mfpmath=sse \
   -msse -msse2 -msse3 -fargument-noalias-global

Also, when ATLAS is allowed to exercise the code generator to find the best
kernel, for double precision gcc 4's SSE could be made to almost tie gcc3's x87
performance (gcc3's double x87 performance is roughly 92% of the patched gcc 4
for this platform).  However, single precision SSE, even allowing the code
generator to go crazy, could only achieve about 2/3 of double *SSE*
performance, and since x87 single perf is actually greater for x87 . . .

You can find some details at:
  
https://sourceforge.net/mailarchive/forum.php?thread_id=10026092&forum_id=426

Cheers,
Clint


-- 


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

[Bug middle-end/28684] Imprecise -funsafe-math-optimizations definition

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2006-08-11 15:39 ---
Confirmed.  I think we should split at least the reassociation and reciprocals
from -funsafe-math-optimizations, as for example on x86 we create fsin/fsincos
and friends which are of lower precision than required.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-08-11 15:39:22
   date||


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

[Bug middle-end/28683] [4.0/4.1/4.2 regression] ICE (segfault in add_reg_br_prob_note) when comparing pointers with -O (and higher)

[janis at gcc dot gnu dot org]

--- Comment #2 from janis at gcc dot gnu dot org  2006-08-11 16:17 ---
A regression hunt using an i686-linux cross compiler for the submitter's
testcase with "-O2 -march=i486 -mtune=i686" identified the following patch:

http://gcc.gnu.org/viewcvs?view=rev&rev=105606

r105606 | bonzini | 2005-10-19 10:37:31 + (Wed, 19 Oct 2005)

This was after the 4.0 branch was created; the same patch was added to that
branch two days later.


-- 


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

[Bug other/28700] does not fix broken linux/compiler-gcc+.h

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2006-08-11 16:33 ---
This only happens for a small number of kernels and 95% of them are a mandrake
kernel.
So I don't think this should be fixed on GCC's side.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug fortran/28660] Spurious warning: 'ubound.6' is used uninitialized in this function

[pault at gcc dot gnu dot org]

--- Comment #7 from pault at gcc dot gnu dot org  2006-08-11 17:17 ---
> The attached runs the testcase below correctly and regtests, except for 
> gfortran.fortran-torture/execute/entry_5.f90, on Cygwin_NT/PIV.

I have tracked down the cause of this - it's just building tonto-2.3 at
present, having regtested fine.

> I have not had enough time to really check with it is necessary and 
> sufficient,
> to fix this one regression nor have I had time to track down the cause of an
> irritating but apparently harmless wrinkle - the declaration char z[1:.z]
> appears twice; the first time with an incorrect .z and the second with the
> correct value for .z.  Fortunately, it is the second declaration that is seen
> in the scope of the executable code.

I'll try to look at this tonight and then I turn into a pumpkin for a few days.

I have upgraded this to "major", since I consider the correct treatment of
variable declarations to be absolutely critical.  As you said, Erik, "Ah, that
explains the crazy results I'm getting from my program!"

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
   |dot org |
   Severity|normal  |major
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-08-09 10:20:36 |2006-08-11 17:17:17
   date||


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

[Bug target/28672] [4.2 Regression]: Gcc went into infinite loop when building libstdc++

[hjl at lucon dot org]

--- Comment #6 from hjl at lucon dot org  2006-08-11 18:40 ---
The loop in vt_find_locations starts with

Basic block 22:
IN:
Stack adjustment: 80
Reg 8: __ret+0
Reg 15: this+0 this+0
Reg 32: __ret+0
Reg 33: __ret+0
Reg 35: __c+0
Reg 112: this+0
Reg 113: __ret+0
Reg 114: __ret+0
Reg 115: __ret+0
Reg 117: __io+0
Reg 118: __err+0
Reg 119: __xtrc+0
Variables:
  name: __xtrc
offset 0
  (reg:DI 119 r39 [ __xtrc ])
  name: __ret
offset 0
  (reg/v:SI 113 r33 [orig:342 __ret.739 ] [342])
  (reg/v:SI 8 r8 [orig:363 __ret ] [363])
  name: __ret
offset 0
  (reg/v:SI 33 r41 [orig:355 __ret ] [355])
  name: __ret
offset 0
  (reg/v:SI 115 r35 [orig:339 __ret.742 ] [339])
  name: __c
offset 0
  (reg/v:SI 35 r43 [orig:380 __c ] [380])
  name: this
offset 0
  (reg:DI 15 r15 [orig:371 this ] [371])
  name: __ret
offset 0
  (reg/v:SI 114 r34 [orig:341 __ret.740 ] [341])
  name: __ret
offset 0
  (reg/v:SI 32 r40 [orig:343 __ret.738 ] [343])
  name: this
offset 0
  (reg:DI 112 r32 [ this ])
  name: this
offset 0
  (reg:DI 15 r15 [orig:361 this ] [361])
  name: __io
offset 0
  (reg:DI 117 r37 [ __io ])
  name: __err
offset 0
  (reg:DI 118 r38 [ __err ])

After recomputing the input:

Basic block 22:
IN:
Stack adjustment: 80
Reg 15: this+0 this+0
Reg 32: __ret+0
Reg 33: __ret+0
Reg 35: __c+0
Reg 112: this+0
Reg 113: __ret+0
Reg 114: __ret+0
Reg 115: __ret+0
Reg 117: __io+0
Reg 118: __err+0
Reg 119: __xtrc+0
Variables:
  name: __xtrc
offset 0
  (reg:DI 119 r39 [ __xtrc ])
  name: __ret
offset 0
  (reg/v:SI 113 r33 [orig:342 __ret.739 ] [342])
  name: __ret
offset 0
  (reg/v:SI 33 r41 [orig:355 __ret ] [355])
  name: __ret
offset 0
  (reg/v:SI 115 r35 [orig:339 __ret.742 ] [339])
  name: __c
offset 0
  (reg/v:SI 35 r43 [orig:380 __c ] [380])
  name: this
offset 0
  (reg:DI 15 r15 [orig:371 this ] [371])
  name: __ret
offset 0
  (reg/v:SI 114 r34 [orig:341 __ret.740 ] [341])
  name: __ret
offset 0
  (reg/v:SI 32 r40 [orig:343 __ret.738 ] [343])
  name: this
offset 0
  (reg:DI 112 r32 [ this ])
  name: this
offset 0
  (reg:DI 15 r15 [orig:361 this ] [361])
  name: __io
offset 0
  (reg:DI 117 r37 [ __io ])
  name: __err
offset 0
  (reg:DI 118 r38 [ __err ])

(reg/v:SI 8 r8 [orig:363 __ret ] [363]) is gone. But it is put back later. It
goes into a infinite loop. The instruction in question is

(insn 1138 1137 1233 73 x.cc:23406 (cond_exec (eq (reg:BI 262 p6 [489])
(const_int 0 [0x0]))
(set (reg/v:SI 113 r33 [orig:342 __ret.739 ] [342])
(reg/v:SI 8 r8 [orig:363 __ret ] [363]))) 781
{sync_lock_releasedi+4} (nil)
(expr_list:REG_DEAD (reg/v:SI 8 r8 [orig:363 __ret ] [363])
(expr_list:REG_DEAD (reg:BI 262 p6 [489])
(nil

Is this really a MO_COPY since r8 is dead after it. I tried

--- var-tracking.c.debug2006-08-09 19:53:01.0 -0700
+++ var-tracking.c  2006-08-11 11:22:03.0 -0700
@@ -1671,6 +1671,9 @@ add_stores (rtx loc, rtx expr, void *ins
mo->type = MO_CLOBBER;
   else if (GET_CODE (expr) == SET
   && SET_DEST (expr) == loc
+  && (! REG_P (SET_SRC (expr))
+  || ! find_regno_note ((rtx) insn, REG_DEAD,
+REGNO (SET_SRC (expr
   && same_variable_part_p (SET_SRC (expr),
REG_EXPR (loc),
REG_OFFSET (loc)))

It seems to work for libstdc++-v3/src/wlocale-inst.cc.


-- 


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

[Bug c++/28659] [4.2 regression] ICE (segfault) while compiling kdelibs 4.0 snapshot

[janis at gcc dot gnu dot org]

--- Comment #5 from janis at gcc dot gnu dot org  2006-08-11 18:46 ---
A regression hunt on powerpc-linux using the test case added for comment #3
identified the following patch:

http://gcc.gnu.org/viewcvs?view=rev&rev=115086

r115086 | jason | 2006-06-30 01:15:56 + (Fri, 30 Jun 2006)


-- 


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

[Bug rtl-optimization/23454] [4.0 regression] ICE in invert_exp_1, at jump.c:1719

[ebotcazou at gcc dot gnu dot org]

--- Comment #13 from ebotcazou at gcc dot gnu dot org  2006-08-11 19:01 
---
Subject: Bug 23454

Author: ebotcazou
Date: Fri Aug 11 19:01:45 2006
New Revision: 116088

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116088
Log:
PR rtl-optimization/23454
* reorg.c (relax_delay_slots): Update comment.


Added:
trunk/gcc/testsuite/g++.dg/opt/pr23454-2.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/reorg.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug rtl-optimization/23454] [4.0 regression] ICE in invert_exp_1, at jump.c:1719

[ebotcazou at gcc dot gnu dot org]

--- Comment #14 from ebotcazou at gcc dot gnu dot org  2006-08-11 19:02 
---
Subject: Bug 23454

Author: ebotcazou
Date: Fri Aug 11 19:02:45 2006
New Revision: 116089

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116089
Log:
PR rtl-optimization/23454
* reorg.c (relax_delay_slots): Update comment.


Added:
branches/gcc-4_1-branch/gcc/testsuite/g++.dg/opt/pr23454-2.C
Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/reorg.c
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug rtl-optimization/23454] [4.0 regression] ICE in invert_exp_1, at jump.c:1719

[ebotcazou at gcc dot gnu dot org]

--- Comment #15 from ebotcazou at gcc dot gnu dot org  2006-08-11 19:04 
---
Subject: Bug 23454

Author: ebotcazou
Date: Fri Aug 11 19:04:04 2006
New Revision: 116090

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116090
Log:
PR rtl-optimization/23454
Backport from mainline
2005-03-07  Eric Botcazou  <[EMAIL PROTECTED]>

* reorg.c (relax_delay_slots): Check that the jump is
conditional before trying to invert it.


Added:
branches/gcc-4_0-branch/gcc/testsuite/g++.dg/opt/pr23454-2.C
Modified:
branches/gcc-4_0-branch/gcc/ChangeLog
branches/gcc-4_0-branch/gcc/reorg.c
branches/gcc-4_0-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug rtl-optimization/23454] [4.0 regression] ICE in invert_exp_1, at jump.c:1719

[ebotcazou at gcc dot gnu dot org]

--- Comment #16 from ebotcazou at gcc dot gnu dot org  2006-08-11 19:06 
---
See http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00375.html


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC|ebotcazou at gcc dot gnu dot|
   |org |
 Status|ASSIGNED|RESOLVED
 GCC target triplet|sparc-linux |sparc-*-*
 Resolution||FIXED


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

[Bug target/28675] [4.1/4.2 regression] ICE in extract_insn, at recog.c:2084 (unrecognizable insn) [arm]

[janis at gcc dot gnu dot org]

--- Comment #4 from janis at gcc dot gnu dot org  2006-08-11 19:24 ---
A regression hunt using an arm-ep93xx-linux-gnueabi cross compiler on
powerpc-linux, with the testcase minimal.c, identified the following patch:

http://gcc.gnu.org/viewcvs?view=rev&rev=105121

r105121 | kazu | 2005-10-08 18:17:20 + (Sat, 08 Oct 2005)

This is a large merge from the csl-arm-branch to mainline.  The test does not
fail for a cross compiler built from revision 104998, the last revision on that
branch before the merge, suggesting that his is a problem with the merge
itself. 


-- 


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

[Bug debug/28692] [4.2 Regression] ICE in rtl_for_decl_init, at dwarf2out.c

[janis at gcc dot gnu dot org]

--- Comment #1 from janis at gcc dot gnu dot org  2006-08-11 19:27 ---
This problem also affects powerpc-linux, where a regression hunt identified the
following patch:

http://gcc.gnu.org/viewcvs?view=rev&rev=112408

r112408 | geoffk | 2006-03-27 06:09:48 + (Mon, 27 Mar 2006)


-- 

janis at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||geoffk at gcc dot gnu dot
   ||org


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

[Bug target/28675] [4.1/4.2 regression] ICE in extract_insn, at recog.c:2084 (unrecognizable insn) [arm]

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   GCC host triplet|arm-ep93xx-linux-gnueabi|
 GCC target triplet||arm-ep93xx-linux-gnueabi
   Keywords||ice-on-valid-code
   Target Milestone|--- |4.1.2


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

[Bug debug/28692] [4.2 Regression] ICE in rtl_for_decl_init, at dwarf2out.c

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2006-08-11 19:30 ---
Confirmed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |blocker
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2006-08-11 19:30:06
   date||


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

[Bug fastjar/28359] fastjar directory traversal problem

[rguenth at gcc dot gnu dot org]

--- Comment #18 from rguenth at gcc dot gnu dot org  2006-08-11 19:46 
---
I think this is now fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||4.0.4 4.1.2
 Resolution||FIXED
   Target Milestone|--- |4.0.4


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

[Bug fortran/28660] Spurious warning: 'ubound.6' is used uninitialized in this function

[patchapp at dberlin dot org]

--- Comment #8 from patchapp at dberlin dot org  2006-08-11 19:55 ---
Subject: Bug number PR28660

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00378.html


-- 


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

[Bug c++/23624] [3.4/4.0/4.1 Regression] ICE: internal compiler error: in invert_truthvalue, at fold-const.c:2697

[patchapp at dberlin dot org]

--- Comment #10 from patchapp at dberlin dot org  2006-08-11 21:06 ---
Subject: Bug number PR23624

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01740.html


-- 


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

[Bug c++/23794] C++ frontend passes invalid COND_EXPR to the middle-end

[patchapp at dberlin dot org]

--- Comment #1 from patchapp at dberlin dot org  2006-08-11 21:25 ---
Subject: Bug number PR23794

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00381.html


-- 


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

[Bug c++/28595] [4.1/4.2 regression] ICE with invalid const static variable

[janis at gcc dot gnu dot org]

--- Comment #1 from janis at gcc dot gnu dot org  2006-08-11 22:24 ---
A regression hunt on powerpc-linux identified the following patch:

http://gcc.gnu.org/viewcvs?view=rev&rev=106566

r106566 | mmitchel | 2005-11-06 19:41:18 + (Sun, 06 Nov 2005)


-- 

janis at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||mmitchel at gcc dot gnu dot
   ||org


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

[Bug c++/28506] [4.0/4.1/4.2 regression] ICE with initializers for functions

[janis at gcc dot gnu dot org]

--- Comment #1 from janis at gcc dot gnu dot org  2006-08-11 22:29 ---
A regression hunt using the first testcase identified the following patch:

http://gcc.gnu.org/viewcvs?view=rev&rev=94656

r94656 | giovannibajo | 2005-02-03 10:26:22 + (Thu, 03 Feb 2005)

A regression hunt using the second testcase identified the following patch:

http://gcc.gnu.org/viewcvs?view=rev&rev=112869

r112869 | mmitchel | 2006-04-11 22:59:57 + (Tue, 11 Apr 2006)


-- 

janis at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||giovannibajo at gcc dot gnu
   ||dot org, mmitchel at gcc dot
   ||gnu dot org


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

[Bug target/28701] New: ABI test failures building libstdc++ on a glibc-2.4 based system

[doko at ubuntu dot com]

Building 4.1.x on powerpc-linux-gnu and sparc-linux-gnu lets the libstdc++ ABI
check fail (log attached); a libstlport4.6 built on a glibc-2.3.6 system cannot
resolve the references to the libstdc++6 built on the glibc-2.4 system.


-- 
   Summary: ABI test failures building libstdc++ on a glibc-2.4
based system
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: doko at ubuntu dot com
GCC target triplet: powerpc-linux-gnu sparc-linux-gnu


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

[Bug target/28701] ABI test failures building libstdc++ on a glibc-2.4 based system

[doko at ubuntu dot com]

--- Comment #1 from doko at ubuntu dot com  2006-08-11 22:47 ---
Created an attachment (id=12069)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12069&action=view)
test log


-- 


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

[Bug target/28701] ABI test failures building libstdc++ on a glibc-2.4 based system

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2006-08-11 22:50 ---
I think this is a fall out of the 12bit long double changes.


-- 


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

[Bug c++/28303] [4.1/4.2 regression] ICE on invalid typedef

[janis at gcc dot gnu dot org]

--- Comment #1 from janis at gcc dot gnu dot org  2006-08-11 23:00 ---
A regression hunt on powerpc-linux identified this patch:

http://gcc.gnu.org/viewcvs?view=rev&rev=114667

r114667 | mmitchel | 2006-06-15 03:40:42 + (Thu, 15 Jun 2006)


-- 

janis at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||mmitchel at gcc dot gnu dot
   ||org


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

[Bug c/28287] [4.1/4.2 regression] ICE with misplaced attribute weak

[janis at gcc dot gnu dot org]

--- Comment #1 from janis at gcc dot gnu dot org  2006-08-11 23:57 ---
A regression hunt on powerpc-linux using a C compiler identified the following
patch:

http://gcc.gnu.org/viewcvs?view=rev&rev=101799

r101799 | dberlin | 2005-07-08 23:37:11 + (Fri, 08 Jul 2005)


-- 

janis at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dberlin at gcc dot gnu dot
   ||org


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

[Bug c/28287] [4.1/4.2 regression] ICE with misplaced attribute weak

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2006-08-12 00:02 ---
The real question is why we even get to that point in mark_weak. 


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |minor
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-08-12 00:02:25
   date||


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