[Bug other/26208] New: Serious problem with unwinding through signal frames

[jakub at gcc dot gnu dot org]

The attached testcase usually segfaults on i?86-linux and x86_64-linux
(and likely on most other DWARF2_UNWIND_INFO 1 targets, though the testcase
would need to be tweaked for them).
The problem is that instruction pointer saved in the signal frame is after
last successfully executed instruction and before first non-executed
instruction,
while .eh_frame and unwind-dw2.c basically expects context->ra to be after the
first non-executed instruction.
To find FDE, unwind-dw2.c uses context->ra - 1, which is good for normal
unwinding, but if e.g. a signal is sent while $pc is at the very beginning
of some function, context->ra - 1 either corresponds to a previous function
or is not covered by any FDE.
Similarly, execute_cfa_program has a loop:
  while (insn_ptr < insn_end && fs->pc < context->ra)
which is good in most cases, but when context->ra is saved IP from sigcontext
in signal frame, this means that the last set of unwind instructions will
not be executed, while it ought to (for signal frame context->ra we'd need
to also execute fs->pc == context->ra instructions).


-- 
   Summary: Serious problem with unwinding through signal frames
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org


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

[Bug other/26208] Serious problem with unwinding through signal frames

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2006-02-10 08:23 ---
Created an attachment (id=10814)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10814&action=view)
cleanup-12.c


-- 


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

[Bug other/26208] Serious problem with unwinding through signal frames

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2006-02-10 08:23 ---
Created an attachment (id=10815)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10815&action=view)
cleanup-12a.S


-- 


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

[Bug other/26208] Serious problem with unwinding through signal frames

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-02-10 08:24:00
   date||


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

[Bug libgcj/26202] Regex bug "++"

[konqueror at gmx dot de]

--- Comment #1 from konqueror at gmx dot de  2006-02-10 08:29 ---
Subject: Re:   New: Regex bug "++"

Works fine with jamvm 1.4.2 and current GNU classpath CVS.
Porting this fix to 4.1 branchshould be done.


-- 


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

[Bug fortran/26054] Gratuitous warning about Fortran 2003 features w/o -std=...

[toon at moene dot indiv dot nluug dot nl]

--- Comment #3 from toon at moene dot indiv dot nluug dot nl  2006-02-10 
08:42 ---
We don't warn for other Fortran 2003 features we support without a -std=f95, so
I'll look into it and fix it.


-- 

toon at moene dot indiv dot nluug dot nl changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |toon at moene dot indiv dot
   |dot org |nluug dot nl
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-02-10 08:42:25
   date||


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

[Bug tree-optimization/26209] New: Specific code causes g++ 4.1.0 dominance ICE when compiled with -O3

[walter dot zimmer at dlr dot de]

We have a problem that gcc 4.1-20060203 emits an internal compiler error
while compiling a certain code construct.

The following reduced test case code reproduces the bug:
--
#include 

using namespace std;

class Blubb {

public:
typedef boost::multi_array, 3> ourArray;

void blah();
};

void Blubb::blah () {
new ourArray(boost::extents[1][1][1]);
}
--

While compiling with gcc-4.1, it says:

testcase> g++ -O3 test.cpp
test.cpp: In member function 'void Blubb::blah()':
test.cpp:17: internal compiler error: in dominated_by_p, at dominance.c:827
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
testcase> 

It compiles fine with -O2. The stock RHEL4 compilers (4.0.1 20050727
and 3.4.4 20050721) also do well with -O3.

I didn't provide the boost include file (boost version 1.33.1, stock
RHEL4 1.32.0 doesn't make any difference), and test.ii as it is 1.3 MB
large. Just yell and I'll do!

gcc -v says:
Configured with: ../gcc-4.1-20060203/configure --prefix=/local/inst
--enable-languages=c,c++,fortran --disable-multilib
Thread model: posix
gcc version 4.1.0 20060203 (prerelease)


-- 
   Summary: Specific code causes g++ 4.1.0 dominance ICE when
compiled with -O3
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: walter dot zimmer at dlr 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=26209

[Bug tree-optimization/26210] New: Specific code causes g++ 4.1.0 dominance ICE when compiled with -O3

[walter dot zimmer at dlr dot de]

We have a problem that gcc 4.1-20060203 emits an internal compiler error
while compiling a certain code construct.

The following reduced test case code reproduces the bug:
--
#include 

using namespace std;

class Blubb {

public:
typedef boost::multi_array, 3> ourArray;

void blah();
};

void Blubb::blah () {
new ourArray(boost::extents[1][1][1]);
}
--

While compiling with gcc-4.1, it says:

testcase> g++ -O3 test.cpp
test.cpp: In member function 'void Blubb::blah()':
test.cpp:17: internal compiler error: in dominated_by_p, at dominance.c:827
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
testcase> 

It compiles fine with -O2. The stock RHEL4 compilers (4.0.1 20050727
and 3.4.4 20050721) also do well with -O3.

I didn't provide the boost include file (boost version 1.33.1, stock
RHEL4 1.32.0 doesn't make any difference), and test.ii as it is 1.3 MB
large. Just yell and I'll do!

gcc -v says:
Configured with: ../gcc-4.1-20060203/configure --prefix=/local/inst
--enable-languages=c,c++,fortran --disable-multilib
Thread model: posix
gcc version 4.1.0 20060203 (prerelease)


-- 
   Summary: Specific code causes g++ 4.1.0 dominance ICE when
compiled with -O3
   Product: gcc
   Version: 4.1.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: walter dot zimmer at dlr 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=26210

[Bug debug/26199] [4.2 regression] ICE in decl_ultimate_origin

[reichelt at gcc dot gnu dot org]

--- Comment #2 from reichelt at gcc dot gnu dot org  2006-02-10 09:58 
---
I can't reproduce this anymore.


-- 

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=26199

[Bug tree-optimization/26210] Specific code causes g++ 4.1.0 dominance ICE when compiled with -O3

[walter dot zimmer at dlr dot de]

--- Comment #1 from walter dot zimmer at dlr dot de  2006-02-10 10:01 
---


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


-- 

walter dot zimmer at dlr dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug tree-optimization/26209] Specific code causes g++ 4.1.0 dominance ICE when compiled with -O3

[walter dot zimmer at dlr dot de]

--- Comment #1 from walter dot zimmer at dlr dot de  2006-02-10 10:01 
---
*** Bug 26210 has been marked as a duplicate of this bug. ***


-- 


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

[Bug tree-optimization/26209] Specific code causes g++ 4.1.0 dominance ICE when compiled with -O3

[reichelt at gcc dot gnu dot org]

--- Comment #2 from reichelt at gcc dot gnu dot org  2006-02-10 10:03 
---
Could you please compress test.ii and attach it to the problem report?


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||reichelt at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |WAITING


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

[Bug tree-optimization/26209] Specific code causes g++ 4.1.0 dominance ICE when compiled with -O3

[walter dot zimmer at dlr dot de]

--- Comment #3 from walter dot zimmer at dlr dot de  2006-02-10 10:08 
---
Created an attachment (id=10816)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10816&action=view)
The preprocessor output of the testcase code


-- 


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

[Bug libstdc++/26211] New: basic_istream::tellg, seekg are unformatted input functions

[pcarlini at suse dot de]

... as such (27.6.1.3/1) should construct a sentry.


-- 
   Summary: basic_istream::tellg, seekg are unformatted input
functions
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pcarlini at suse dot de


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

[Bug tree-optimization/26209] Specific code causes g++ 4.1.0 dominance ICE when compiled with -O3

[reichelt at gcc dot gnu dot org]

--- Comment #4 from reichelt at gcc dot gnu dot org  2006-02-10 11:17 
---
Reducing.


-- 


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

[Bug tree-optimization/26209] Specific code causes g++ 4.1.0 dominance ICE when compiled with -O3

[steven at gcc dot gnu dot org]

-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|WAITING |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-02-10 12:03:49
   date||


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

[Bug target/21616] [3.4 only] ICE: unable to find a register to spill in class `FLOAT_REGS'

[amodra at bigpond dot net dot au]

--- Comment #9 from amodra at bigpond dot net dot au  2006-02-10 12:16 
---
Created an attachment (id=10817)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10817&action=view)
Patch against current 3.4 sources


-- 


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

[Bug tree-optimization/26209] Specific code causes g++ 4.1.0 dominance ICE when compiled with -O3

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|minor   |normal
   Keywords||ice-on-valid-code


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

[Bug tree-optimization/26209] [4.1 Regression] Specific code causes g++ 4.1.0 dominance ICE when compiled with -O3

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
  Known to fail||4.1.0
  Known to work||4.0.3
Summary|Specific code causes g++|[4.1 Regression] Specific
   |4.1.0 dominance ICE when|code causes g++ 4.1.0
   |compiled with -O3   |dominance ICE when compiled
   ||with -O3
   Target Milestone|--- |4.1.0


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

[Bug tree-optimization/26209] [4.1/4.2 Regression] Specific code causes g++ 4.1.0 dominance ICE when compiled with -O3

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2006-02-10 13:03 ---
Somebody forgot to call update_domiantator (or what ever the function is
called).


-- 


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

[Bug tree-optimization/26209] [4.1/4.2 Regression] Specific code causes g++ 4.1.0 dominance ICE when compiled with -O3

[reichelt at gcc dot gnu dot org]

--- Comment #6 from reichelt at gcc dot gnu dot org  2006-02-10 13:21 
---
Reduced testcase:

==
struct A
{
  void f() {}
  ~A();
};

void foo(A* p)
{
  for ( ; p; --p)
(p->*&A::f)();
}

void bar()
{
A a;
foo(&a);
foo(&a);
}
==


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |minor
   Target Milestone|4.1.0   |---


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

[Bug tree-optimization/26209] [4.1/4.2 Regression] Specific code causes g++ 4.1.0 dominance ICE when compiled with -O3

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|minor   |major
   Target Milestone|--- |4.1.0


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

[Bug tree-optimization/26209] [4.1/4.2 Regression] Specific code causes g++ 4.1.0 dominance ICE when compiled with -O3

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2006-02-10 13:28 ---
It is ICE while in the sccp pass.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rakdver at gcc dot gnu dot
   ||org


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

[Bug middle-end/26212] New: ICE in create_component_ref_by_pieces

[mueller at gcc dot gnu dot org]

this testcase segfaults: 

=== Cut ===
class A
{
public:
A()·{ x1 = 0; x2 = -1; } 

int·   x()· ·   const { return x1; }
void   setX( int x ) { x1 = x; }

int·   width()· const { return x2 - x1 + 1; }
void   setWidth( int w );

private:
int x1;
int x2;
};

A breakme()
{
A r;

for( int i=0 ; i < 2; i++ )
{
if (r.width() < r.x())
r.setX(4);
if (5 > r.width())
r.setWidth(r.x());
}

   return r;
}
=== Cut ===
g++ -O2  -c test.cpp
test.cpp:17:  internal compiler error: in create_component_ref_by_pieces, at
tree-ssa-pre.c:2167


-- 
   Summary: ICE in create_component_ref_by_pieces
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mueller at gcc dot gnu dot org


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

[Bug middle-end/26212] ICE in create_component_ref_by_pieces

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-02-10 13:40 ---
This is a dup of bug 26179 which was just fixed yesterday.

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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug tree-optimization/26179] [4.2 Regression] ICE while compiling mozilla in tree-ssa-pre.c

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2006-02-10 13:40 ---
*** Bug 26212 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||mueller at gcc dot gnu dot
   ||org


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

[Bug c/26213] New: new (within last few days) infinite loop with -O1

[list+gcc-bugzilla at meyering dot net]

gcc infloops with -O1 (but not -O, -Os, -O2, or -O3) given the following input.
Note that this happens using gcc built from svn a few hours ago, that it is
also reproducible with a two-day-old binary, but not with one from 2006-02-04.

$ cat xnanosleep.c
void
xnanosleep (_Bool overflow)
{
  struct { int tv_nsec; } ts_sleep;
  if (0 <= ts_sleep.tv_nsec)
overflow |= 1;

  for (;;)
{
  if (overflow)
ts_sleep.tv_nsec = 0;
  if (foo (ts_sleep))
break;
}
}
$ time gcc -v -O1 xnanosleep.c 2> /t/err

gcc -v -O1 xnanosleep.c 2> /t/err  0.00s user 0.00s system 0% cpu 5.106 total
[Exit 130 (INT)]
$ cat /t/err
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /mirror/d/gcc/configure --disable-nls
--prefix=/p/p/gcc-2006-02-10.10h41 --disable-multilib --enable-languages=c
Thread model: posix
gcc version 4.2.0 20060210 (experimental)

/nobak/p/p/gcc-2006-02-10.10h41/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.2.0/cc1
-quiet -v -iprefix
/nobak/p/p/gcc-2006-02-10.10h41/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.2.0/
xnanosleep.c -quiet -dumpbase xnanosleep.c -mtune=generic -auxbase xnanosleep
-O1 -version -o /t/cc9XDV6L.s
ignoring nonexistent directory
"/nobak/p/p/gcc-2006-02-10.10h41/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.2.0/../../../../x86_64-unknown-linux-gnu/include"
ignoring duplicate directory
"/p/p/gcc-2006-02-10.10h41/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/include"
ignoring nonexistent directory
"/p/p/gcc-2006-02-10.10h41/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/nobak/p/p/gcc-2006-02-10.10h41/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.2.0/include
 /usr/local/include
 /p/p/gcc-2006-02-10.10h41/include
 /usr/include
End of search list.
GNU C version 4.2.0 20060210 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.2.0 20060210 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: ddb06f39f2f5fb93ee768a85a3be125e


-- 
   Summary: new (within last few days) infinite loop with -O1
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: list+gcc-bugzilla at meyering dot net
 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=26213

[Bug tree-optimization/26213] [4.2 Regression] new (within last few days) infinite loop with -O1

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-02-10 14:24 ---
Confirmed, the backtrace:
#0  0x004c0784 in thread_across_edge (dummy_cond=0x41ee29f0, e=0x41ee24e0,
handle_dominating_asserts=0 '\0', stack=0x6c9530, simplify=0x422674
) at
/Users/pinskia/src/gcc/local/gcc/gcc/tree-ssa-threadedge.c:445
#1  0x0042359c in dom_opt_finalize_block (walk_data=0x41ee24e0, bb=0x41ee21b0)
at /Users/pinskia/src/gcc/local/gcc/gcc/tree-ssa-dom.c:722
#2  0x0042359c in dom_opt_finalize_block (walk_data=0xb80c, bb=0x41ee1930)
at /Users/pinskia/src/gcc/local/gcc/gcc/tree-ssa-dom.c:722
#3  0x0049b044 in walk_dominator_tree (walk_data=0xb80c, bb=0x41ee1930) at
/Users/pinskia/src/gcc/local/gcc/gcc/domwalk.c:234
#4  0x0049aff0 in walk_dominator_tree (walk_data=0xb80c, bb=0x41ee1850) at
/Users/pinskia/src/gcc/local/gcc/gcc/domwalk.c:212
#5  0x0049aff0 in walk_dominator_tree (walk_data=0xb80c, bb=0x41ee1770) at
/Users/pinskia/src/gcc/local/gcc/gcc/domwalk.c:212
#6  0x0049aff0 in walk_dominator_tree (walk_data=0xb80c, bb=0x41ee15b0) at
/Users/pinskia/src/gcc/local/gcc/gcc/domwalk.c:212


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||law at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
  Component|c   |tree-optimization
 Ever Confirmed|0   |1
  GCC build triplet|x86_64-unknown-linux-gnu|
   GCC host triplet|x86_64-unknown-linux-gnu|
 GCC target triplet|x86_64-unknown-linux-gnu|
   Keywords||compile-time-hog
   Last reconfirmed|-00-00 00:00:00 |2006-02-10 14:24:16
   date||
Summary|new (within last few days)  |[4.2 Regression] new (within
   |infinite loop with -O1  |last few days) infinite loop
   ||with -O1
   Target Milestone|--- |4.2.0


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

[Bug c++/26195] pragma interface no longer handles explicit names

[zak at transversal dot com]

--- Comment #1 from zak at transversal dot com  2006-02-10 15:00 ---
I think the bug here is that handle_pragma_interface in gcc/cp/lex.c is calling
get_file_info(filename), which refers to the name in the #pragma, rather than
get_file_info(lbasename(input_filename)) -- hence it is updating the wrong 
c_fileinfo struct.

This was changed here:

http://gcc.gnu.org/viewcvs/branches/gcc-4_0-branch/gcc/cp/lex.c?r1=87774&r2=87786&diff_format=h

Reverting that one line appears to fix the problem, although I haven't (yet)
tested it extensively.


-- 


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

[Bug c++/26195] pragma interface no longer handles explicit names

[zak at transversal dot com]

--- Comment #2 from zak at transversal dot com  2006-02-10 15:53 ---
On thinking about this further, I don't understand the application of lbasename
to the input_filename before it is passed to get_fileinfo. I included this for
consistency with the code in cxx_make_type that checks for the interface_*
settings.

However, doesn't this mean that files included as "file1.h", "dir1/file1.h" and
"dir2/file1.h" will share the same c_fileinfo struct for these purposes? The
calls to get_fileinfo(input_filename) in gcc/c-lex.c, by constrast, do not use
lbasename.


-- 


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

[Bug tree-optimization/26213] [4.2 Regression] new (within last few days) infinite loop with -O1

[law at redhat dot com]

--- Comment #2 from law at redhat dot com  2006-02-10 16:19 ---
Subject: Re:  [4.2 Regression] new (within
last few days) infinite loop with -O1

On Fri, 2006-02-10 at 14:24 +, pinskia at gcc dot gnu dot org wrote:
> 
> --- Comment #1 from pinskia at gcc dot gnu dot org  2006-02-10 14:24 
> ---
> Confirmed, the backtrace:
> #0  0x004c0784 in thread_across_edge (dummy_cond=0x41ee29f0, e=0x41ee24e0,
> handle_dominating_asserts=0 '\0', stack=0x6c9530, simplify=0x422674
> ) at
> /Users/pinskia/src/gcc/local/gcc/gcc/tree-ssa-threadedge.c:445
> #1  0x0042359c in dom_opt_finalize_block (walk_data=0x41ee24e0, bb=0x41ee21b0)
> at /Users/pinskia/src/gcc/local/gcc/gcc/tree-ssa-dom.c:722
> #2  0x0042359c in dom_opt_finalize_block (walk_data=0xb80c, bb=0x41ee1930)
> at /Users/pinskia/src/gcc/local/gcc/gcc/tree-ssa-dom.c:722
> #3  0x0049b044 in walk_dominator_tree (walk_data=0xb80c, bb=0x41ee1930) at
> /Users/pinskia/src/gcc/local/gcc/gcc/domwalk.c:234
> #4  0x0049aff0 in walk_dominator_tree (walk_data=0xb80c, bb=0x41ee1850) at
> /Users/pinskia/src/gcc/local/gcc/gcc/domwalk.c:212
> #5  0x0049aff0 in walk_dominator_tree (walk_data=0xb80c, bb=0x41ee1770) at
> /Users/pinskia/src/gcc/local/gcc/gcc/domwalk.c:212
> #6  0x0049aff0 in walk_dominator_tree (walk_data=0xb80c, bb=0x41ee15b0) at
> /Users/pinskia/src/gcc/local/gcc/gcc/domwalk.c:212
Fix in testing.
jeff


-- 


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

[Bug c++/26195] pragma interface no longer handles explicit names

[zak at transversal dot com]

--- Comment #3 from zak at transversal dot com  2006-02-10 17:05 ---
After making the change suggested in comment #1, the following test case
demonstrates the problem mentioned in comment #2.

$ g++ -Wall -pedantic -I. foo.cc && nm -A foo.o
[no output]

If you switch the name in the pragma implementation directive to "dir2/foo.h",
then the implementations of *both* headers are output:
foo.o: U __gxx_personality_v0
foo.o: W _ZN2A1C1Ev
foo.o: W _ZN2A1C2Ev
foo.o: W _ZN2A2C1Ev
foo.o: W _ZN2A2C2Ev


In 3.4.5, the implementation of the header with the matching pragma interface
directive is correctly output in each case.


I'm currently testing a patch that, in addition to the above change, removes
all the uses of lbasename in this context (two in decl.c, one in lex.c and one
in semantics.c, all in code specific to handling #pragma interface and
introduced in revision 87786).



// foo.cc
#pragma implementation "dir1/foo.h"
#include "dir1/foo.h"


// dir1/foo.h
#pragma interface "dir1/foo.h"
#include "dir2/foo.h"

struct A1
{
A1() { }
};


// dir2/foo.h
#pragma interface "dir2/foo.h"

struct A2
{
A2() { }
};


-- 


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

[Bug tree-optimization/26214] New: gcc -O2 creates erroneous code

[steger at mvtec dot com]

On the following program, gcc -O2 creates incorrect code:

#include 


#define NUM 1
#define MAX 10.0


__inline__ float rsqrt(float x)
{
  float xhalf = 0.5f * x;
  int i = *(int*)&x;
  i = 0x5f375a86 - (i>>1);
  x = *(float*)&i;
  x = x * (1.5f - xhalf * x * x);
  return x;
}


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

  for (i=0; i %10.6f\n",x,y);
  }
}

The same code works as expected with gcc 3.3.6.

Interestingly, if "fprintf(stderr," is changed to "printf(" the output changes
significantly, but is still incorrect.


-- 
   Summary: gcc -O2 creates erroneous code
   Product: gcc
   Version: 4.0.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steger at mvtec 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=26214

[Bug c++/19439] Duplicate destructor accepted

[reichelt at gcc dot gnu dot org]

--- Comment #2 from reichelt at gcc dot gnu dot org  2006-02-10 17:15 
---
This also holds for other duplicate member functions like "void foo() {}".


-- 


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

[Bug tree-optimization/24365] [4.1/4.2 Regression] statement makes a memory store with complex

[jason at gcc dot gnu dot org]

--- Comment #14 from jason at gcc dot gnu dot org  2006-02-10 17:32 ---
Subject: Bug 24365

Author: jason
Date: Fri Feb 10 17:32:10 2006
New Revision: 110838

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110838
Log:
PR c++/25979
* tree.def: Elaborate on difference from MODIFY_EXPR.
* doc/c-tree.texi (INIT_EXPR): Likewise.
* gimplify.c (internal_get_tmp_var): Use INIT_EXPR.
(gimplify_decl_expr, gimplify_init_ctor_eval): Likewise.
(gimplify_target_expr): Likewise.
(gimplify_cond_expr): Remove target handling.
(gimplify_modify_expr): Don't clobber INIT_EXPR code here.
(gimplify_expr): Clobber it here.
(gimplify_modify_expr_rhs): Push assignment into COND_EXPR here.
Do return slot optimization if we have an INIT_EXPR.

PR tree-opt/24365
* tree-inline.c (declare_return_variable): Also clear
DECL_COMPLEX_GIMPLE_REG_P as needed in the modify_dest case.

PR c++/16405
* gimplify.c (gimplify_modify_expr_rhs): Re-enable *& handling.

PR middle-end/22439
* gimplify.c (gimplify_one_sizepos): Fix typo.

Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/cp/ChangeLog
branches/gcc-4_1-branch/gcc/cp/cp-gimplify.c
branches/gcc-4_1-branch/gcc/cp/typeck2.c
branches/gcc-4_1-branch/gcc/doc/c-tree.texi
branches/gcc-4_1-branch/gcc/gimplify.c
branches/gcc-4_1-branch/gcc/testsuite/g++.dg/opt/temp1.C
branches/gcc-4_1-branch/gcc/tree-inline.c
branches/gcc-4_1-branch/gcc/tree.def


-- 


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

[Bug middle-end/22439] [4.0/4.1 regression] ICE with char VLA and __SIZE_TYPE__ argument (so no cast)

[jason at gcc dot gnu dot org]

--- Comment #13 from jason at gcc dot gnu dot org  2006-02-10 17:32 ---
Subject: Bug 22439

Author: jason
Date: Fri Feb 10 17:32:10 2006
New Revision: 110838

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110838
Log:
PR c++/25979
* tree.def: Elaborate on difference from MODIFY_EXPR.
* doc/c-tree.texi (INIT_EXPR): Likewise.
* gimplify.c (internal_get_tmp_var): Use INIT_EXPR.
(gimplify_decl_expr, gimplify_init_ctor_eval): Likewise.
(gimplify_target_expr): Likewise.
(gimplify_cond_expr): Remove target handling.
(gimplify_modify_expr): Don't clobber INIT_EXPR code here.
(gimplify_expr): Clobber it here.
(gimplify_modify_expr_rhs): Push assignment into COND_EXPR here.
Do return slot optimization if we have an INIT_EXPR.

PR tree-opt/24365
* tree-inline.c (declare_return_variable): Also clear
DECL_COMPLEX_GIMPLE_REG_P as needed in the modify_dest case.

PR c++/16405
* gimplify.c (gimplify_modify_expr_rhs): Re-enable *& handling.

PR middle-end/22439
* gimplify.c (gimplify_one_sizepos): Fix typo.

Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/cp/ChangeLog
branches/gcc-4_1-branch/gcc/cp/cp-gimplify.c
branches/gcc-4_1-branch/gcc/cp/typeck2.c
branches/gcc-4_1-branch/gcc/doc/c-tree.texi
branches/gcc-4_1-branch/gcc/gimplify.c
branches/gcc-4_1-branch/gcc/testsuite/g++.dg/opt/temp1.C
branches/gcc-4_1-branch/gcc/tree-inline.c
branches/gcc-4_1-branch/gcc/tree.def


-- 


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

[Bug c++/25979] [4.0 Regression] incorrect codegen for conditional [SVO issue]

[jason at gcc dot gnu dot org]

--- Comment #11 from jason at gcc dot gnu dot org  2006-02-10 17:32 ---
Subject: Bug 25979

Author: jason
Date: Fri Feb 10 17:32:10 2006
New Revision: 110838

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110838
Log:
PR c++/25979
* tree.def: Elaborate on difference from MODIFY_EXPR.
* doc/c-tree.texi (INIT_EXPR): Likewise.
* gimplify.c (internal_get_tmp_var): Use INIT_EXPR.
(gimplify_decl_expr, gimplify_init_ctor_eval): Likewise.
(gimplify_target_expr): Likewise.
(gimplify_cond_expr): Remove target handling.
(gimplify_modify_expr): Don't clobber INIT_EXPR code here.
(gimplify_expr): Clobber it here.
(gimplify_modify_expr_rhs): Push assignment into COND_EXPR here.
Do return slot optimization if we have an INIT_EXPR.

PR tree-opt/24365
* tree-inline.c (declare_return_variable): Also clear
DECL_COMPLEX_GIMPLE_REG_P as needed in the modify_dest case.

PR c++/16405
* gimplify.c (gimplify_modify_expr_rhs): Re-enable *& handling.

PR middle-end/22439
* gimplify.c (gimplify_one_sizepos): Fix typo.

Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/cp/ChangeLog
branches/gcc-4_1-branch/gcc/cp/cp-gimplify.c
branches/gcc-4_1-branch/gcc/cp/typeck2.c
branches/gcc-4_1-branch/gcc/doc/c-tree.texi
branches/gcc-4_1-branch/gcc/gimplify.c
branches/gcc-4_1-branch/gcc/testsuite/g++.dg/opt/temp1.C
branches/gcc-4_1-branch/gcc/tree-inline.c
branches/gcc-4_1-branch/gcc/tree.def


-- 


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

[Bug c++/16405] [3.4/4.1 Regression] Temporary aggregate copy not elided

[jason at gcc dot gnu dot org]

--- Comment #12 from jason at gcc dot gnu dot org  2006-02-10 17:32 ---
Subject: Bug 16405

Author: jason
Date: Fri Feb 10 17:32:10 2006
New Revision: 110838

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110838
Log:
PR c++/25979
* tree.def: Elaborate on difference from MODIFY_EXPR.
* doc/c-tree.texi (INIT_EXPR): Likewise.
* gimplify.c (internal_get_tmp_var): Use INIT_EXPR.
(gimplify_decl_expr, gimplify_init_ctor_eval): Likewise.
(gimplify_target_expr): Likewise.
(gimplify_cond_expr): Remove target handling.
(gimplify_modify_expr): Don't clobber INIT_EXPR code here.
(gimplify_expr): Clobber it here.
(gimplify_modify_expr_rhs): Push assignment into COND_EXPR here.
Do return slot optimization if we have an INIT_EXPR.

PR tree-opt/24365
* tree-inline.c (declare_return_variable): Also clear
DECL_COMPLEX_GIMPLE_REG_P as needed in the modify_dest case.

PR c++/16405
* gimplify.c (gimplify_modify_expr_rhs): Re-enable *& handling.

PR middle-end/22439
* gimplify.c (gimplify_one_sizepos): Fix typo.

Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/cp/ChangeLog
branches/gcc-4_1-branch/gcc/cp/cp-gimplify.c
branches/gcc-4_1-branch/gcc/cp/typeck2.c
branches/gcc-4_1-branch/gcc/doc/c-tree.texi
branches/gcc-4_1-branch/gcc/gimplify.c
branches/gcc-4_1-branch/gcc/testsuite/g++.dg/opt/temp1.C
branches/gcc-4_1-branch/gcc/tree-inline.c
branches/gcc-4_1-branch/gcc/tree.def


-- 


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

[Bug middle-end/25335] [4.1/4.2 Regression] reload leaves insns from earlier passes around: fatal for postinc

[amylaar at gcc dot gnu dot org]

--- Comment #12 from amylaar at gcc dot gnu dot org  2006-02-10 17:42 
---
I get the following code for rld-legit2.c with the patch I am currently
testing:
_g:
subq 4,$sp
move $srp,[$sp]
subq 40,$sp
movem $r8,[$sp]
move $r10,$srp
move.d $r11,[$sp+36]
move $srp,$r13
addq 2,$r13
move $r13,$srp
subq 2,$r13
movs.w [$r13+],$r9
move.d [$sp+36],$r13
clear.b [$r9+$r13.b]
move $srp,$r10
movem [$sp+],$r8
addq 4,$sp
jump [$sp+]
.size   _g, .-_g

I suppose this is right.


-- 

amylaar at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |amylaar at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-01-31 22:10:45 |2006-02-10 17:42:38
   date||


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

[Bug fortran/14771] frontend doesn't record parentheses

[tobi at gcc dot gnu dot org]

--- Comment #14 from tobi at gcc dot gnu dot org  2006-02-10 18:08 ---
Subject: Bug 14771

Author: tobi
Date: Fri Feb 10 18:08:27 2006
New Revision: 110840

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110840
Log:
fortran/
PR fortran/14771
* arith.c (eval_intrinsic): Accept INTRINSIC_PARENTHESES.
* expr.c (check_intrinsic_op): Likewise.
* module.c (mio_expr): Likewise.
testsuite/
PR fortran/14771
* gfortran.dg/parens_4.f90: New.
* gfortran.dg/parens_5.f90: New.


Added:
trunk/gcc/testsuite/gfortran.dg/parens_4.f90
trunk/gcc/testsuite/gfortran.dg/parens_5.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/arith.c
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/module.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug tree-optimization/26214] gcc -O2 creates erroneous code

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-02-10 18:11 ---
  x = *(float*)&i;


You are violating C aliasing rules.

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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c/21920] alias violating

[pinskia at gcc dot gnu dot org]

--- Comment #84 from pinskia at gcc dot gnu dot org  2006-02-10 18:11 
---
*** Bug 26214 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||steger at mvtec dot com


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

[Bug c++/17519] [3.4/4.0/4.1/4.2 Regression] Warning for array of packed non-POD in packed struct

[amylaar at gcc dot gnu dot org]

--- Comment #9 from amylaar at gcc dot gnu dot org  2006-02-10 18:22 ---
(In reply to comment #4)
> There's certainly a good case for warning about packing that's likely not to
> have the desired results - we've been bitten by that before. But that doesn't
> really apply to all non-POD; you can define a subset safe-non-POD (broadly
> speaking, no virtual functions/bases and (recursively) no unsafe non-static 
> data
> members) where everything still has reasonably predictable representations and
> you don't need extra space for polymorphism magic.

All the more reason to warn if we don't pack these members now, but we might
fix that in the future and thus change the data layout.
I.e. if the packed attribute is applied (individually or as part of an entire
struct / class) to a member, but ignored, and this is relevant for the size or
alignment of that member, we should warn.  That obviously applies for the
target
we are compiling for, but I think if possible, we should warn if the ignoring
of the packed attribute is relevant for any possible gcc target.
> 
> So if you do go in that direction, please consider separate warnings for those
> non-POD types that can nevertheless safely be packed and those that can't.
> Classes made non-POD through fairly innoccuous constructions - e.g.
> constructors, simple inheritance - are often useful in abstracting hardware
> registers, data formats, etc. We'd be swamped in warnings if we got one for
> every packed non-POD, but we definitely do want to know if there's something
> that's actually going to mess things up.


-- 


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

[Bug libstdc++/26181] istream::operator>>(streambuf*) fails to set eofbit

[paolo at gcc dot gnu dot org]

--- Comment #8 from paolo at gcc dot gnu dot org  2006-02-10 18:29 ---
Subject: Bug 26181

Author: paolo
Date: Fri Feb 10 18:29:04 2006
New Revision: 110841

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110841
Log:
2006-10-02  Paolo Carlini  <[EMAIL PROTECTED]>

PR libstdc++/26181
* include/bits/streambuf.tcc (__copy_streambufs_eof): New, like
the existing __copy_streambufs but reporting eof in input.
(__copy_streambufs): Just use the latter.
* src/streambuf.cc (__copy_streambufs_eof): Adjust specializations
of __copy_streambufs.
* include/bits/istream.tcc (operator>>(__streambuf_type*)): Use
__copy_streambufs_eof instead.
* include/std/std_streambuf.h: Adjust.
* src/streambuf-inst.cc: Adjust.
* config/abi/pre/gnu.ver: Export the new symbols.
* testsuite/27_io/basic_istream/extractors_other/char/26181.cc: New.
* testsuite/27_io/basic_istream/extractors_other/wchar_t/26181.cc:
Likewise.
* testsuite/27_io/basic_istream/extractors_other/char/1.cc: Adjust.
* testsuite/27_io/basic_istream/extractors_other/wchar_t/1.cc:
Likewise.

Added:
   
trunk/libstdc++-v3/testsuite/27_io/basic_istream/extractors_other/char/26181.cc
   
trunk/libstdc++-v3/testsuite/27_io/basic_istream/extractors_other/wchar_t/26181.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/config/abi/pre/gnu.ver
trunk/libstdc++-v3/include/bits/istream.tcc
trunk/libstdc++-v3/include/bits/streambuf.tcc
trunk/libstdc++-v3/include/std/std_streambuf.h
trunk/libstdc++-v3/src/streambuf-inst.cc
trunk/libstdc++-v3/src/streambuf.cc
trunk/libstdc++-v3/testsuite/27_io/basic_istream/extractors_other/char/1.cc
   
trunk/libstdc++-v3/testsuite/27_io/basic_istream/extractors_other/wchar_t/1.cc


-- 


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

[Bug libstdc++/26181] istream::operator>>(streambuf*) fails to set eofbit

[pcarlini at suse dot de]

--- Comment #9 from pcarlini at suse dot de  2006-02-10 18:30 ---
Fixed for 4.2.0.


-- 

pcarlini at suse dot de changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.2.0


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

[Bug fortran/20858] NULL doesn't get its argument type (kind)

[kargl at gcc dot gnu dot org]

--- Comment #4 from kargl at gcc dot gnu dot org  2006-02-10 19:01 ---
Subject: Bug 20858

Author: kargl
Date: Fri Feb 10 19:01:05 2006
New Revision: 110845

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110845
Log:
2006-02-05  Steven G. Kargl  <[EMAIL PROTECTED]>

PR fortran/20858
*decl.c (variable_decl): Improve error message.  Remove initialization
 typespec.  Wrap long line.
*expr.c (gfc_check_pointer_assign): Permit checking of type, kind type,
 and rank.
*simplify.c (gfc_simplify_null): Ensure type, kind type, and rank are set.

gfortran.dg/null_1.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/null_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/expr.c
trunk/gcc/fortran/simplify.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug tree-optimization/26213] [4.2 Regression] new (within last few days) infinite loop with -O1

[law at gcc dot gnu dot org]

--- Comment #3 from law at gcc dot gnu dot org  2006-02-10 19:23 ---
Subject: Bug 26213

Author: law
Date: Fri Feb 10 19:22:58 2006
New Revision: 110846

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110846
Log:

PR tree-optimization/26213
* tree-ssa-threadedge.c (simplify_control_stmt_condition): Do not
loop trying to follow SSA_NAME_VALUE chains.

* gcc.c-torture/compile/pr26213.c: New test.


Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr26213.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-threadedge.c


-- 


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

[Bug tree-optimization/26213] [4.2 Regression] new (within last few days) infinite loop with -O1

[law at redhat dot com]

--- Comment #4 from law at redhat dot com  2006-02-10 19:23 ---
Subject: Re:  [4.2 Regression] new (within
last few days) infinite loop with -O1

On Fri, 2006-02-10 at 14:24 +, pinskia at gcc dot gnu dot org wrote:
> 
> --- Comment #1 from pinskia at gcc dot gnu dot org  2006-02-10 14:24 
> ---
> Confirmed, the backtrace:
> #0  0x004c0784 in thread_across_edge (dummy_cond=0x41ee29f0, e=0x41ee24e0,
> handle_dominating_asserts=0 '\0', stack=0x6c9530, simplify=0x422674
> ) at
> /Users/pinskia/src/gcc/local/gcc/gcc/tree-ssa-threadedge.c:445
> #1  0x0042359c in dom_opt_finalize_block (walk_data=0x41ee24e0, bb=0x41ee21b0)
> at /Users/pinskia/src/gcc/local/gcc/gcc/tree-ssa-dom.c:722
> #2  0x0042359c in dom_opt_finalize_block (walk_data=0xb80c, bb=0x41ee1930)
> at /Users/pinskia/src/gcc/local/gcc/gcc/tree-ssa-dom.c:722
> #3  0x0049b044 in walk_dominator_tree (walk_data=0xb80c, bb=0x41ee1930) at
> /Users/pinskia/src/gcc/local/gcc/gcc/domwalk.c:234
> #4  0x0049aff0 in walk_dominator_tree (walk_data=0xb80c, bb=0x41ee1850) at
> /Users/pinskia/src/gcc/local/gcc/gcc/domwalk.c:212
> #5  0x0049aff0 in walk_dominator_tree (walk_data=0xb80c, bb=0x41ee1770) at
> /Users/pinskia/src/gcc/local/gcc/gcc/domwalk.c:212
> #6  0x0049aff0 in walk_dominator_tree (walk_data=0xb80c, bb=0x41ee15b0) at
> /Users/pinskia/src/gcc/local/gcc/gcc/domwalk.c:212

I should have known better.  It's possible to have loops in the
SSA_NAME_VALUE chain.  Dumb dumb dumb.  

Bootstrapped and regression tested on i686-pc-linux-gnu.


--- Comment #5 from law at redhat dot com  2006-02-10 19:23 ---
Created an attachment (id=10818)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10818&action=view)


-- 


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

[Bug java/26192] ICE while compiling jar or class file (azureus)

[tromey at gcc dot gnu dot org]

--- Comment #4 from tromey at gcc dot gnu dot org  2006-02-10 19:47 ---
Fixed in svn.


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.1.0


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

[Bug libgcj/26202] Regex bug "++"

[tromey at gcc dot gnu dot org]

--- Comment #2 from tromey at gcc dot gnu dot org  2006-02-10 19:52 ---
Subject: Bug 26202

Author: tromey
Date: Fri Feb 10 19:52:44 2006
New Revision: 110847

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110847
Log:
Re-merged all regular expression code.
For PR libgcj/26177, PR libgcj/26202.
See classpath/ChangeLog.gcj for full details.
* java/lang/Character.java: Merged from Classpath.
(start, end): Now 'int's.
(canonicalName): New field.
(CANONICAL_NAME, NO_SPACES_NAME, CONSTANT_NAME): New constants.
(UnicodeBlock): Added argument.
(of): New overload.
(forName): New method.
Updated unicode blocks.
(sets): Updated.
* sources.am, Makefile.in: Rebuilt.
* gnu/regexp/MessagesBundle_fr.properties: Removed.
* gnu/regexp/MessagesBundle.properties: Removed.

Added:
   
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/RETokenIndependent.java
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/RETokenLookBehind.java
   
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/RETokenNamedProperty.java
branches/gcc-4_1-branch/libjava/classpath/java/util/regex/MatchResult.java
Removed:
branches/gcc-4_1-branch/libjava/gnu/regexp/MessagesBundle.properties
branches/gcc-4_1-branch/libjava/gnu/regexp/MessagesBundle_fr.properties
Modified:
branches/gcc-4_1-branch/libjava/ChangeLog
branches/gcc-4_1-branch/libjava/Makefile.in
branches/gcc-4_1-branch/libjava/classpath/ChangeLog.gcj
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/CharIndexed.java
   
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/CharIndexedCharArray.java
   
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/CharIndexedInputStream.java
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/CharIndexedString.java
   
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/CharIndexedStringBuffer.java
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/RE.java
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/REMatch.java
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/RESyntax.java
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/REToken.java
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/RETokenAny.java
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/RETokenBackRef.java
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/RETokenChar.java
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/RETokenEnd.java
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/RETokenEndSub.java
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/RETokenLookAhead.java
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/RETokenOneOf.java
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/RETokenPOSIX.java
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/RETokenRange.java
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/RETokenRepeated.java
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/RETokenStart.java
   
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/RETokenWordBoundary.java
branches/gcc-4_1-branch/libjava/classpath/java/net/URI.java
branches/gcc-4_1-branch/libjava/classpath/java/util/regex/Matcher.java
branches/gcc-4_1-branch/libjava/classpath/java/util/regex/Pattern.java
   
branches/gcc-4_1-branch/libjava/classpath/java/util/regex/PatternSyntaxException.java
branches/gcc-4_1-branch/libjava/java/lang/Character.java
branches/gcc-4_1-branch/libjava/sources.am


-- 


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

[Bug libgcj/26177] [4.1 only] Exception when compiling valid regex pattern

[tromey at gcc dot gnu dot org]

--- Comment #8 from tromey at gcc dot gnu dot org  2006-02-10 19:52 ---
Subject: Bug 26177

Author: tromey
Date: Fri Feb 10 19:52:44 2006
New Revision: 110847

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110847
Log:
Re-merged all regular expression code.
For PR libgcj/26177, PR libgcj/26202.
See classpath/ChangeLog.gcj for full details.
* java/lang/Character.java: Merged from Classpath.
(start, end): Now 'int's.
(canonicalName): New field.
(CANONICAL_NAME, NO_SPACES_NAME, CONSTANT_NAME): New constants.
(UnicodeBlock): Added argument.
(of): New overload.
(forName): New method.
Updated unicode blocks.
(sets): Updated.
* sources.am, Makefile.in: Rebuilt.
* gnu/regexp/MessagesBundle_fr.properties: Removed.
* gnu/regexp/MessagesBundle.properties: Removed.

Added:
   
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/RETokenIndependent.java
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/RETokenLookBehind.java
   
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/RETokenNamedProperty.java
branches/gcc-4_1-branch/libjava/classpath/java/util/regex/MatchResult.java
Removed:
branches/gcc-4_1-branch/libjava/gnu/regexp/MessagesBundle.properties
branches/gcc-4_1-branch/libjava/gnu/regexp/MessagesBundle_fr.properties
Modified:
branches/gcc-4_1-branch/libjava/ChangeLog
branches/gcc-4_1-branch/libjava/Makefile.in
branches/gcc-4_1-branch/libjava/classpath/ChangeLog.gcj
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/CharIndexed.java
   
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/CharIndexedCharArray.java
   
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/CharIndexedInputStream.java
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/CharIndexedString.java
   
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/CharIndexedStringBuffer.java
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/RE.java
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/REMatch.java
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/RESyntax.java
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/REToken.java
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/RETokenAny.java
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/RETokenBackRef.java
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/RETokenChar.java
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/RETokenEnd.java
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/RETokenEndSub.java
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/RETokenLookAhead.java
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/RETokenOneOf.java
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/RETokenPOSIX.java
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/RETokenRange.java
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/RETokenRepeated.java
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/RETokenStart.java
   
branches/gcc-4_1-branch/libjava/classpath/gnu/regexp/RETokenWordBoundary.java
branches/gcc-4_1-branch/libjava/classpath/java/net/URI.java
branches/gcc-4_1-branch/libjava/classpath/java/util/regex/Matcher.java
branches/gcc-4_1-branch/libjava/classpath/java/util/regex/Pattern.java
   
branches/gcc-4_1-branch/libjava/classpath/java/util/regex/PatternSyntaxException.java
branches/gcc-4_1-branch/libjava/java/lang/Character.java
branches/gcc-4_1-branch/libjava/sources.am


-- 


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

[Bug libgcj/26177] [4.1 only] Exception when compiling valid regex pattern

[tromey at gcc dot gnu dot org]

--- Comment #9 from tromey at gcc dot gnu dot org  2006-02-10 19:53 ---
Fix checked in.


-- 


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

[Bug libgcj/26202] Regex bug "++"

[tromey at gcc dot gnu dot org]

--- Comment #3 from tromey at gcc dot gnu dot org  2006-02-10 19:54 ---
Fix checked in.


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.1.0


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

[Bug libgcj/26177] [4.1 only] Exception when compiling valid regex pattern

[tromey at gcc dot gnu dot org]

--- Comment #10 from tromey at gcc dot gnu dot org  2006-02-10 19:54 ---
Forgot to mark as fixed.


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug other/26208] Serious problem with unwinding through signal frames

[uweigand at gcc dot gnu dot org]

--- Comment #3 from uweigand at gcc dot gnu dot org  2006-02-10 20:00 
---
Yup.  See how this is handled in config/s390/linux-unwind.c:

  /* If we got a SIGSEGV or a SIGBUS, the PSW address points *to*
 the faulting instruction, not after it.  This causes the logic
 in unwind-dw2.c that decrements the RA to determine the correct
 CFI region to get confused.  To fix that, we *increment* the RA
 here in that case.  Note that we cannot modify the RA in place,
 and the frame state wants a *pointer*, not a value; thus we put
 the modified RA value into the unused register 33 slot of FS and
 have the register 32 save address point to that slot.

 Unfortunately, for regular signals on old kernels, we don't know
 the signal number.  We default to not fiddling with the RA;
 that can fail in rare cases.  Upgrade your kernel.  */

  if (signo && (*signo == 11 || *signo == 7))
{
  fs->regs.reg[33].loc.exp =
(unsigned char *)regs->psw_addr + 1;
  fs->regs.reg[32].loc.offset =
(long)&fs->regs.reg[33].loc.exp - new_cfa;
}


-- 

uweigand at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||uweigand at gcc dot gnu dot
   ||org


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

[Bug fortran/20858] NULL doesn't get its argument type (kind)

[kargl at gcc dot gnu dot org]

--- Comment #5 from kargl at gcc dot gnu dot org  2006-02-10 20:09 ---
Subject: Bug 20858

Author: kargl
Date: Fri Feb 10 20:09:41 2006
New Revision: 110848

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110848
Log:
2006-02-10  Steven G. Kargl  <[EMAIL PROTECTED]>

PR fortran/20858
*decl.c (variable_decl): Improve error message.  Remove initialization
typespec.  Wrap long line.
*expr.c (gfc_check_pointer_assign): Permit checking of type, kind type,
and rank.
*simplify.c (gfc_simplify_null): Ensure type, kind type, and rank
are set.

2006-02-10  Steven G. Kargl  <[EMAIL PROTECTED]>

PR fortran/20858
gfortran.dg/null_1.f90: New test.


Added:
branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/null_1.f90
Modified:
branches/gcc-4_1-branch/gcc/fortran/ChangeLog
branches/gcc-4_1-branch/gcc/fortran/decl.c
branches/gcc-4_1-branch/gcc/fortran/expr.c
branches/gcc-4_1-branch/gcc/fortran/simplify.c
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/20858] NULL doesn't get its argument type (kind)

[kargl at gcc dot gnu dot org]

--- Comment #6 from kargl at gcc dot gnu dot org  2006-02-10 20:10 ---
Fixed on 4.1 and trunk.


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.1.0


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

[Bug fortran/25051] NULL doesn't get its argument type (rank)

[kargl at gcc dot gnu dot org]

--- Comment #4 from kargl at gcc dot gnu dot org  2006-02-10 20:13 ---
Fixed on 4.1 and trunk by the patch committed for pr 20858.

troutmask:sgk[226] cat > ptr.f90
INTEGER, POINTER, DIMENSION(:,:) :: i
INTEGER, POINTER, DIMENSION(:) :: a
a=>NULL(i)
END

troutmask:sgk[227] gfc41 -c ptr.f90
 In file ptr.f90:3

a=>NULL(i)
1
Error: Different ranks in pointer assignment at (1)


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.1.0


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

[Bug target/20353] uclibc does not provide C99 math functions

[jsm28 at gcc dot gnu dot org]

--- Comment #5 from jsm28 at gcc dot gnu dot org  2006-02-10 20:14 ---
Fixed by my patch ,
pending review.


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jsm28 at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-09-24 16:44:26 |2006-02-10 20:14:48
   date||


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

[Bug libstdc++/14939] libstdc++ doesn't compile with uclibc headers

[jsm28 at gcc dot gnu dot org]

--- Comment #8 from jsm28 at gcc dot gnu dot org  2006-02-10 20:16 ---
Fixed by my patch ,
pending review.  I add a config/os/uclibc directory as suggested in comment#4.


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jsm28 at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2005-12-31 03:00:13 |2006-02-10 20:16:30
   date||


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

[Bug other/26208] Serious problem with unwinding through signal frames

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2006-02-10 20:18 ---
Not all the targets have the luxury of spare register slots.
So the current proposal is to add a new CIE augmentation that will signify
a signal frame.


-- 


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

[Bug target/24578] compiler emits call to floorf() instead of floor()

[jsm28 at gcc dot gnu dot org]

--- Comment #2 from jsm28 at gcc dot gnu dot org  2006-02-10 20:20 ---
Fixed by my patch ,
pending review.


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jsm28 at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-02-10 20:20:07
   date||


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

[Bug tree-optimization/26197] [4.2 regression] ICE in is_old_name, at tree-into-ssa.c:466

[law at redhat dot com]

--- Comment #4 from law at redhat dot com  2006-02-10 20:24 ---
This is a bug in the vectorizer and has absolutely nothing to do with PR26169.

The vectorizer is twiddling things such that the set of virtual operands
changes
for the statement in question.  ie, if you look at the statement before and
after the vectorizer runs it has the form:
#   TMT.32D.2670_172 = V_MAY_DEF ;
D.2524_41->a0D.2385 = D.2477.a0D.2385;

However, if you were to call update_stmt on the statement immediately after
the vectorizer is complete, then dumped the statement again, you'd have:
#   TMT.32D.2670_172 = V_MAY_DEF ;
#   VUSE ;
#   VUSE ;
D.2524_41->a0D.2385 = D.2477.a0D.2385;

That's a clear indication that this bug is actually in the vectorizer.  Not
VRP or the SSA updating code.

When a pass twiddles aliasing information such that the set of virtual operands
would change on a statement that is a bug if the statement is not properly
updated.

Jeff


-- 

law at redhat dot com changed:

   What|Removed |Added

 CC|law at gcc dot gnu dot org  |


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

[Bug target/24837] move dynamic linker names out of LINK_SPEC and into new DYNAMIC_LINKER

[jsm28 at gcc dot gnu dot org]

--- Comment #2 from jsm28 at gcc dot gnu dot org  2006-02-10 20:25 ---
My uClibc support patch
 addresses this issue
for MIPS; the other targets still need similar changes (not yet done) to
support uClibc within the framework of my patch.


-- 


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

[Bug other/26208] Serious problem with unwinding through signal frames

[uweigand at gcc dot gnu dot org]

--- Comment #5 from uweigand at gcc dot gnu dot org  2006-02-10 20:34 
---
(In reply to comment #4)
> Not all the targets have the luxury of spare register slots.
I guess we were lucky here ;-)

> So the current proposal is to add a new CIE augmentation that will signify
> a signal frame.
OK, I see.


-- 


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

[Bug target/25864] Enable IBM long double format in 32-bit PowerPC Linux

[jakub at gcc dot gnu dot org]

--- Comment #10 from jakub at gcc dot gnu dot org  2006-02-10 20:58 ---
Subject: Bug 25864

Author: jakub
Date: Fri Feb 10 20:58:33 2006
New Revision: 110851

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110851
Log:
PR target/25864
Backport from mainline

2006-02-04  David Edelsohn  <[EMAIL PROTECTED]>
Jakub Jelinek  <[EMAIL PROTECTED]>

* config/rs6000/rs6000.c (rs6000_mangle_fundamental_type): Mangle
IBM extended float format long double as "g" on powerpc*-linux.

2006-02-01  Jakub Jelinek  <[EMAIL PROTECTED]>

* config/rs6000/sysv4.h (SUBTARGET_OVERRIDE_OPTIONS): For
-msoft-float -mlong-double-128 only issue a warning, but don't
swich to DFmode long double.

2006-01-28  David Edelsohn  <[EMAIL PROTECTED]>

* config/rs6000/aix43.h (SUBTARGET_OVERRIDE_OPTIONS): -msoft-float
and -mlong-double-128 are incompatible.
* config/rs6000/aix52.h (SUBTARGET_OVERRIDE_OPTIONS): Same.
* config/rs6000/t-aix43 (LIB2FUNCS_EXTRA): Add ppc64-fp.c.
(TARGET_LIBGCC2_CFLAGS): Define.
* config/rs6000/t-aix52 (LIB2FUNCS_EXTRA): Same.
(TARGET_LIBGCC2_CFLAGS): Same.
* config/rs6000/ppc64-fp.c: Compile for 64-bit AIX.

2006-01-27  Jakub Jelinek  <[EMAIL PROTECTED]>

* libgcc-std.ver: Add GCC_4.1.0 symbol version.
* config/rs6000/t-linux64 (TARGET_LIBGCC2_CFLAGS): Only append
-mno-minimal-toc to previous content.
(bispecs): Remove goal.
* config/rs6000/ppc64-fp.c: Define TMODES before including fp-bit.h.
* config/rs6000/darwin-ldouble.c: Don't provide [EMAIL PROTECTED]
compatibility aliases on powerpc-*-*gnu*.
* config/rs6000/libgcc-ppc-glibc.ver: New file.
* config/rs6000/t-ppccomm (SHLIB_MAPFILES): Append
libgcc-ppc-glibc.ver on powerpc*-*-*gnu*.
(TARGET_LIBGCC2_CFLAGS): Append -specs=ldblspecs.
(ldblspecs): New goal.
* config/rs6000/t-linux64 (SHLIB_MAPFILES): Removed.
* mklibgcc.in: If $TPBIT is empty, don't compile _sf_to_tf and
_df_to_tf.
* config/fp-bit.h (TMODES): Don't define if none of TFLOAT,
L_sf_to_tf or L_df_to_tf is defined.

2006-01-27  David Edelsohn  <[EMAIL PROTECTED]>
Alan Modra  <[EMAIL PROTECTED]>

* config/rs6000/linux.h (POWERPC_LINUX): Define.
* config/rs6000/linux64.h (POWERPC_LINUX): Define.
* config/rs6000/darwin-ldouble.c: Build on 32-bit PowerPC.
* config/rs6000/darwin.h (TARGET_IEEEQUAD): Define to zero.
* config/rs6000/aix.h (TARGET_IEEEQUAD): Define to zero.
* config/rs6000/rs6000.c (rs6000_ieeequad): New variable.
(rs6000_override_options): Initialize rs6000_ieeequad.
Initialize TFmode format to ibm_extended_format if not
TARGET_IEEEQUAD.
(rs6000_handle_option): Accept -mabi= ibmlongdouble and
ieeelongdouble.
(rs6000_emit_move): Move !TARGET_IEEEQUAD as two parts.
(rs6000_return_in_memory): Only return IEEEQUAD in memory.
(function_arg_advance): IBM long double passed in two FPRs, not
split.
(function_arg): IBM long double passed in FPRs.
(rs6000_pass_by_reference): Only IEEEQUAD passed by reference.
(rs6000_gimplify_va_arg): IBM long double passed in two FPRs.
Only multireg GPR aligned.
(rs6000_init_libfuncs): Enable IBM long double functions if not
IEEEQUAD.
(rs6000_generate_compare): Use IBM long double compare if not
TARGET_IEEEQUAD.
* config/rs6000/rs6000.h (rs6000_ieeequad): Declare.
(TARGET_IEEEQUAD): Define.
(CANNOT_CHANGE_MODE_CLASS): Any mode larger than doubleword if
not TARGET_IEEEQUAD.
* config/rs6000/rs6000.md: Enable TFmode patterns if
!TARGET_IEEEQUAD.
* config/rs6000/t-ppccomm (LIB2FUNCS_EXTRA): Add darwin-ldouble.c.
* config/rs6000/svr4.h (SUBTARGET_OVERRIDE_OPTIONS): -msoft-float
and -mlong-double-128 are incompatible.
* doc/invoke.texi (-mabi): Collect options together.  Add
ibmlongdouble and ieeelongdouble.

Added:
branches/gcc-4_1-branch/gcc/config/rs6000/libgcc-ppc-glibc.ver
Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/config/fp-bit.h
branches/gcc-4_1-branch/gcc/config/rs6000/aix.h
branches/gcc-4_1-branch/gcc/config/rs6000/aix43.h
branches/gcc-4_1-branch/gcc/config/rs6000/aix52.h
branches/gcc-4_1-branch/gcc/config/rs6000/darwin-ldouble.c
branches/gcc-4_1-branch/gcc/config/rs6000/darwin.h
branches/gcc-4_1-branch/gcc/config/rs6000/linux.h
branches/gcc-4_1-branch/gcc/config/rs6000/linux64.h
branches/gcc-4_1-branch/gcc/config/rs6000/ppc64-fp.c
branches/gcc-4_1-branch/gcc/config/rs6000/rs6000.c
branches/gcc-4_1-branch/gcc/config/rs6000/rs6000.h
branches/gcc-4_1-branch/gcc/config/rs

[Bug middle-end/25335] [4.1/4.2 Regression] reload leaves insns from earlier passes around: fatal for postinc

[hp at gcc dot gnu dot org]

--- Comment #13 from hp at gcc dot gnu dot org  2006-02-10 22:11 ---
(In reply to comment #12)
This code is exactly the same as the correct code I saw
for cris-axis-linux-gnu with the patch in comment #9, so I can confirm that
the emitted code is correct by visual inspection.  On the other hand,
the bug is not exposed on trunk version 110246 or 110787 without the patch.

(For the record, the code is clearly sub-optimal,
but that's not the issue here.)

Again, thanks for fixing this (apparently) long-standing wart.


-- 


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

[Bug middle-end/22275] [3.4/4.0/4.1/4.2 Regression] bitfield layout change

[david dot moore at intel dot com]

--- Comment #45 from david dot moore at intel dot com  2006-02-10 22:34 
---
The (C99) standard says:

6.7.2.1 (10) An implementation may allocate any addressable storage unit large
enough to hold a bitfield.

and

6.7.2.1 (11) As a special case, a bit-field structure member with a width of 0
indicates that no further bit-field is to be packed into the unit in which the
previous bit-field, if any, was placed. 

NB -Not into a unit required by the given type (on the  :0 line)

So looks like 6 is the more plausible answer and the old behavior seems to be
bizarre at best. It means, in effect, that the compiler has to go back and
change its mind about the size of unit in which the previous bitfield was to be
allocated. (You can no doubt get around the use of the past tense in the
standard by suitable invocation of an oracle, or two-pass compilation - you
could also always allocate eveything in UINTS - yetch)

A more compelling argument for not changing this back is that gcc has done a
good job of being (C++) ABI compatible since 3.4. Changing this back to pre-3.4
behavior now will create an ABI break between 3.4 and 4.0.3. Even delaying the
change till 4.1 would be bad enough. 

So I strongly represent that this change should not be made or, if it is made,
it should only happen under control of a flag that is off by default. 

BTW, you may think I am arguing this because it would avoid having to change
the Intel compiler but actually it looks like when we changed our behavior we
did not make sure that our gcc 3.2 compatible behavior did not change, so it
looks like we have work to do anyway, and the impact of this change on our work
is perhaps an extra leg in a conditional. 

So I can claim altruism here. Actually the real reason is I have been telling
people that the ABI has been very stable since 3.4 and I would rather not have
egg on my face. 


-- 

david dot moore at intel dot com changed:

   What|Removed |Added

 CC||david dot moore at intel dot
   ||com


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

[Bug libfortran/26136] List directed input with underfilled (logicals) array read incorrectly

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug other/26204] Problem compiling gcc 4.0.2

[pierre42d at 9online dot fr]

--- Comment #2 from pierre42d at 9online dot fr  2006-02-10 23:04 ---
../configure --enable-libada --enable-bootstrap --enable-shared
--enable-threads --enable-tls --enable-nls --with-x --enable-java-awt=gtk,xlib
--enable-gtk-cairo --enable-java-gc


-- 


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

[Bug libgcj/26204] warnings in libgcj

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2006-02-10 23:06 ---
--enable-bootstrap is not supported on 4.0.x or 4.1.x.

Can you try without that flag?

Anyways without that flag this is still an issue.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|other   |libgcj
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2006-02-10 23:06:05
   date||
Summary|Problem compiling gcc 4.0.2 |warnings in libgcj


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

[Bug java/26204] [4.0 only] warnings in java front-end sources

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|libgcj  |java
Summary|warnings in libgcj  |[4.0 only] warnings in java
   ||front-end sources
   Target Milestone|--- |4.0.3


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

[Bug tree-optimization/26213] [4.2 Regression] new (within last few days) infinite loop with -O1

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2006-02-10 23:08 ---
Fixed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug c++/16405] [3.4 Regression] Temporary aggregate copy not elided

[pinskia at gcc dot gnu dot org]

--- Comment #13 from pinskia at gcc dot gnu dot org  2006-02-10 23:08 
---
Fixed now in 4.1.0 also.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[3.4/4.1 Regression]|[3.4 Regression] Temporary
   |Temporary aggregate copy not|aggregate copy not elided
   |elided  |
   Target Milestone|4.1.0   |3.4.6


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

[Bug tree-optimization/26125] [4.1 Regression] g++.dg/opt/complex5.C:11: ICE: Segmentation fault

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2006-02-10 23:09 ---
Fixed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug fortran/25756] ICE on valid code with labels

[kargl at gcc dot gnu dot org]

--- Comment #12 from kargl at gcc dot gnu dot org  2006-02-10 23:20 ---
Subject: Bug 25756

Author: kargl
Date: Fri Feb 10 23:20:10 2006
New Revision: 110856

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110856
Log:
2006-02-10  Steven G. Kargl  <[EMAIL PROTECTED]>

PR fortran/25756
* symbol.c (gfc_free_st_label): Give variable meaningful name. Remove
unneeded parenthesis. Fix-up the head of the list (2 lines gleaned
from g95).

2006-02-10  Bernhard Fischer  <[EMAIL PROTECTED]>

PR fortran/25756
* gfortran.dg/label_3.f90: New test.




Added:
branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/label_3.f90
Modified:
branches/gcc-4_1-branch/gcc/fortran/ChangeLog
branches/gcc-4_1-branch/gcc/fortran/symbol.c
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/25756] ICE on valid code with labels

[kargl at gcc dot gnu dot org]

--- Comment #13 from kargl at gcc dot gnu dot org  2006-02-10 23:21 ---
Fixed on 4.1, too.


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.1.0


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

[Bug middle-end/22275] [3.4/4.0/4.1/4.2 Regression] bitfield layout change

[david dot moore at intel dot com]

--- Comment #46 from david dot moore at intel dot com  2006-02-11 00:14 
---
(Note - I had not realized the importance of pragma pack to this problem. The
fact that without it the behavior has not changed weakens my case, although it
probably weakens the case that it should be restored to gcc 3.2 behavior by an
equal amount)


-- 


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

[Bug c++/25979] [4.0 Regression] incorrect codegen for conditional [SVO issue]

[jason at gcc dot gnu dot org]

--- Comment #12 from jason at gcc dot gnu dot org  2006-02-11 00:19 ---
Subject: Bug 25979

Author: jason
Date: Sat Feb 11 00:19:30 2006
New Revision: 110864

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110864
Log:
PR c++/25979
* tree.def: Elaborate on difference from MODIFY_EXPR.
* doc/c-tree.texi (INIT_EXPR): Likewise.
* cp/cp-gimplify.c (cp_gimplify_expr): Don't call
cp_gimplify_init_expr for MODIFY_EXPRs.
* cp/typeck2.c (split_nonconstant_init_1): Use INIT_EXPR.
* gimplify.c (internal_get_tmp_var): Likewise.
(gimplify_decl_expr, gimplify_init_ctor_eval): Likewise.
(gimplify_target_expr): Likewise.
(gimplify_cond_expr): Remove target handling.
(gimplify_modify_expr): Don't clobber INIT_EXPR code here.
(gimplify_expr): Clobber it here.
(gimplify_modify_expr_rhs): Push assignment into COND_EXPR here.
Do return slot optimization if we have an INIT_EXPR.

PR middle-end/22439
* gimplify.c (gimplify_one_sizepos): Fix typo.

Modified:
branches/gcc-4_0-branch/gcc/ChangeLog
branches/gcc-4_0-branch/gcc/cp/ChangeLog
branches/gcc-4_0-branch/gcc/cp/cp-gimplify.c
branches/gcc-4_0-branch/gcc/cp/typeck2.c
branches/gcc-4_0-branch/gcc/doc/c-tree.texi
branches/gcc-4_0-branch/gcc/gimplify.c
branches/gcc-4_0-branch/gcc/tree.def


-- 


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

[Bug middle-end/22439] [4.0/4.1 regression] ICE with char VLA and __SIZE_TYPE__ argument (so no cast)

[jason at gcc dot gnu dot org]

--- Comment #14 from jason at gcc dot gnu dot org  2006-02-11 00:19 ---
Subject: Bug 22439

Author: jason
Date: Sat Feb 11 00:19:30 2006
New Revision: 110864

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110864
Log:
PR c++/25979
* tree.def: Elaborate on difference from MODIFY_EXPR.
* doc/c-tree.texi (INIT_EXPR): Likewise.
* cp/cp-gimplify.c (cp_gimplify_expr): Don't call
cp_gimplify_init_expr for MODIFY_EXPRs.
* cp/typeck2.c (split_nonconstant_init_1): Use INIT_EXPR.
* gimplify.c (internal_get_tmp_var): Likewise.
(gimplify_decl_expr, gimplify_init_ctor_eval): Likewise.
(gimplify_target_expr): Likewise.
(gimplify_cond_expr): Remove target handling.
(gimplify_modify_expr): Don't clobber INIT_EXPR code here.
(gimplify_expr): Clobber it here.
(gimplify_modify_expr_rhs): Push assignment into COND_EXPR here.
Do return slot optimization if we have an INIT_EXPR.

PR middle-end/22439
* gimplify.c (gimplify_one_sizepos): Fix typo.

Modified:
branches/gcc-4_0-branch/gcc/ChangeLog
branches/gcc-4_0-branch/gcc/cp/ChangeLog
branches/gcc-4_0-branch/gcc/cp/cp-gimplify.c
branches/gcc-4_0-branch/gcc/cp/typeck2.c
branches/gcc-4_0-branch/gcc/doc/c-tree.texi
branches/gcc-4_0-branch/gcc/gimplify.c
branches/gcc-4_0-branch/gcc/tree.def


-- 


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

[Bug middle-end/19207] Suggestion for speeding up data flow analysis

[steven at gcc dot gnu dot org]

--- Comment #2 from steven at gcc dot gnu dot org  2006-02-11 00:36 ---
fixed by the dataflow branch merge bits.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug java/26204] [4.0 only] warnings in java front-end sources

[tromey at gcc dot gnu dot org]

--- Comment #4 from tromey at gcc dot gnu dot org  2006-02-11 00:41 ---
Subject: Bug 26204

Author: tromey
Date: Sat Feb 11 00:41:08 2006
New Revision: 110866

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110866
Log:
PR java/26204:
* jcf-write.c (generate_bytecode_insns): Removed unused variable.

Modified:
branches/gcc-4_0-branch/gcc/java/ChangeLog
branches/gcc-4_0-branch/gcc/java/jcf-write.c


-- 


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

[Bug java/26204] [4.0 only] warnings in java front-end sources

[tromey at gcc dot gnu dot org]

--- Comment #5 from tromey at gcc dot gnu dot org  2006-02-11 00:42 ---
Fix checked in.


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/25243] [4.1/4.2 Regression] Jump threading opportunity missed in tree-ssa but caught in jump1

[steven at gcc dot gnu dot org]

--- Comment #9 from steven at gcc dot gnu dot org  2006-02-11 00:48 ---
Fixed with the 2nd VRP pass Jeff added recently:

2006-02-07  Jeff Law  

* tree-vrp.c (find_conditional_asserts): Update comments.
(simplify_stmt_for_jump_threading): New.
(etc.)


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug c++/25979] [4.0 Regression] incorrect codegen for conditional [SVO issue]

[pinskia at gcc dot gnu dot org]

--- Comment #13 from pinskia at gcc dot gnu dot org  2006-02-11 00:51 
---
Fixed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug target/12395] Suboptimal code with global variables

[steven at gcc dot gnu dot org]

--- Comment #7 from steven at gcc dot gnu dot org  2006-02-11 00:52 ---
"GCC: (GNU) 4.2.0 20060210 (experimental)" produces this
(at "-O2 -march=pentium4"):

foo:
movla, %eax
addl$1, %eax
movl%eax, a
testl   %eax, %eax
je  .L4
addl$1, %eax
movl%eax, a
.L4:
ret


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2005-12-09 04:33:11 |2006-02-11 00:52:36
   date||


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

[Bug libfortran/14398] [meta-bug] libgfortran does not have a test suite

[steven at gcc dot gnu dot org]

--- Comment #3 from steven at gcc dot gnu dot org  2006-02-11 00:54 ---
All tests for library stuff have been going into the compiler test suite.  I
guess this is OK. Unlike C/C++, Fortran without its runtime library is not
usable, so testing it as a single product sort-of makes sense.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX


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

[Bug tree-optimization/21451] Missed constant propagation

[steven at gcc dot gnu dot org]

--- Comment #5 from steven at gcc dot gnu dot org  2006-02-11 00:55 ---
Fixed with Jeff's 2nd VRP pass:

2006-02-07  Jeff Law  

* tree-vrp.c (find_conditional_asserts): Update comments.
(simplify_stmt_for_jump_threading): New.
(etc.)


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||law at redhat dot com
 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug tree-optimization/21829] [4.1/4.2 Regression] missed jump threading after unroller

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2006-02-11 00:59 ---
The problem with this one after Jeff's recent patches is that we have:
:;
  D.1402_17 = 0;
  if (D.1402_17 == 1) goto ; else goto ;

:;
  x_18 = 1;

  # x_19 = PHI <0(2), 0(3), x_18(4)>;
:;

Which causes us not to be able to the jump threading as we do a CCP in VRP and
then we get:
:
  if (v_8 < 0) goto ; else goto ;

:;
  D.1402_17 = 0;
  goto  ();

  # x_19 = PHI <0(2)>;
:;
  u_20 = 1;
  ivtmp.26_21 = 1;
  ivtmp.26_3 = 1;
  u_14 = 1;
  x_13 = 0;
  if (v_8 <= 0) goto ; else goto ;

So we need to be able to do some CCP and some DCE before invoking VRP.


-- 


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

[Bug c++/26216] New: deprecated function warning is emitted twice

[dpatel at apple dot com]

deprecated function warning is emitted twice

For example,
--- a.cc ---
int f() __attribute__((deprecated));

int f() { return 0; }

int main()
{
return f();
}
---
$ /Volumes/src/clean/gcc.trunk.install/bin/gcc -c a.cc
a.cc: In function 'int main()':
a.cc:7: warning: 'f' is deprecated (declared at a.cc:3)
a.cc:7: warning: 'f' is deprecated (declared at a.cc:3)


-- 
   Summary: deprecated function warning is emitted twice
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dpatel at apple dot com


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

[Bug c++/26216] deprecated function warning is emitted twice

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2006-02-11 02:00 ---
This is a dup of bug 17729.  There is some analysis of the problem also.  I
tried to fix this but the fix was wrong.

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


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug c++/17729] [3.4/4.0/4.1/4.2 Regression] Duplicate __attribute__((deprecated)) warning

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2006-02-11 02:00 ---
*** Bug 26216 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dpatel at apple dot com


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

[Bug libstdc++/26217] New: The header is not setting default visibility

[gcc at dave dot dribin dot org]

Here is my gcc information:

% gcc -v
Using built-in specs.
Target: powerpc-apple-darwin8
Configured with: /private/var/tmp/gcc/gcc-5250.obj~12/src/configure
--disable-checking -enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
--with-gxx-include-dir=/include/c++/4.0.0 --build=powerpc-apple-darwin8
--host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8
Thread model: posix
gcc version 4.0.1 (Apple Computer, Inc. build 5250)

Here is the code that reproduces the error:

--- snip ---
#include 
#include 
#include 

int main (int argc, char * const argv[]) {
try {
std::vector intVector;
intVector.at(0);
}
catch (std::out_of_range &) {
std::cout << "Caught std::out_of_range" << std::endl;
}

std::cout << "Finished normally" << std::endl;
return 0;
}
--- snip ---

Here is the error output:

% g++ -fvisibility=hidden -o catch main.cpp
% ./catch
terminate called after throwing an instance of 'std::out_of_range'
  what():  vector::_M_range_check
zsh: abort  ./catch
%

Here is the expected output:

% g++ -o catch main.cpp
% ./catch
Caught std::out_of_range
Finished normally
%

This problem occurs because std::out_of_range is not marked with default
visibility.  This issue is documented here (see the section on Problems with
C++ exceptions):

  http://gcc.gnu.org/wiki/Visibility

The  header file needs to be wrapped in:

#pragma GCC visibility push(default)
...
#pragma GCC visibility pop

Just like  is.  This can be verified by modifying the program above
as:

--- snip ---
#include 
#include 
#pragma GCC visibility push(default)
#include 
#pragma GCC visibility pop

int main (int argc, char * const argv[]) {
try {
std::vector intVector;
intVector.at(0);
}
catch (std::out_of_range &) {
std::cout << "Caught std::out_of_range" << std::endl;
}

std::cout << "Finished normally" << std::endl;
return 0;
}
--- snip ---


-- 
   Summary: The  header is not setting default visibility
   Product: gcc
   Version: 4.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at dave dot dribin dot org


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

[Bug libstdc++/26217] The header is not setting default visibility

[gcc at dave dot dribin dot org]

--- Comment #1 from gcc at dave dot dribin dot org  2006-02-11 04:59 ---
Created an attachment (id=10819)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10819&action=view)
Program to demonstrate error.

To trigger the error:

% g++ -fvisibility=hidden -o catch main.cpp
% ./catch
terminate called after throwing an instance of 'std::out_of_range'
  what():  vector::_M_range_check
zsh: abort  ./catch
%


-- 


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

[Bug libstdc++/26217] The header is not setting default visibility

[gcc at dave dot dribin dot org]

--- Comment #2 from gcc at dave dot dribin dot org  2006-02-11 05:45 ---
Created an attachment (id=10820)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10820&action=view)
This is a patch against std_stdexcept.h.

This patch sets visibility to default for all exceptions declared.


-- 


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