[Bug middle-end/37722] destructors not called on computed goto

[scovich at gmail dot com]

--- Comment #2 from scovich at gmail dot com  2009-05-09 08:16 ---
Computed gotos can easily make it impossible for the compiler to call
constructors and destructors consistently. This is a major gotcha of computed
gotos for people who have used normal gotos in C++ and expect destructors to be
handled properly. Consider this program, for instance:

#include 
template
struct foo {
foo() { printf("%s<%d>\n", __FUNCTION__, i); }
~foo() { printf("%s<%d>\n", __FUNCTION__, i); }
};
enum {RETRY, INSIDE, OUTSIDE, EVIL};
int bar(int idx) {
static void* const gotos[] = {&&RETRY, &&INSIDE, &&OUTSIDE, &&EVIL};
bool first = true;
{
RETRY:
foo<1> f1;
if(first) {
first = false;
goto *gotos[idx];
}
INSIDE:
return 1;
}
if(0) {
foo<2> f2;
EVIL:
return 2;
}
 OUTSIDE:
return 0;
}
int main() {
for(int i=RETRY; i <= EVIL; i++)
printf("%d\n", bar(i));
return 0;
}

Not only does it let you jump out of a block without calling destructors, it
lets you jump into one without calling constructors:

$ g++-4.4.0 -Wall -O3 scratch.cpp && ./a.out
foo<1>
foo<1>
~foo<1>
1
foo<1>
~foo<1>
1
foo<1>
0
foo<1>
~foo<2>
2

Ideally, the compiler could analyze possible destinations of the goto
(best-effort, of course) and emit suitable diagnostics:

scratch.cpp:16: warning: computed goto bypasses destructor of 'foo<1> f1'
scratch.cpp:13: warning:   declared here

scratch.cpp:23: warning: possible jump to label 'EVIL'
scratch.cpp:16: warning:   from here
scratch.cpp:22: warning:   crosses initialization of 'foo<2> f2'

In this particular example the compiler should be able to figure out that no
labels reach a live f1 and call its destructor properly. If it's not feasible
to analyze the possible destinations of the computed goto, regular control flow
analysis should at least be able to identify potentially dangerous labels and
gotos, e.g.:

scratch.cpp:16: warning: computed goto may bypass destructor of 'foo<1> f1'
scratch.cpp:13: warning:   declared here

scratch.cpp:23: warning: jump to label 'EVIL'
scratch.cpp:8:  warning:   using a computed goto
scratch.cpp:22: warning:   may cross initialization of 'foo<2> f2'


-- 

scovich at gmail dot com changed:

   What|Removed |Added

 CC||scovich at gmail dot com


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

[Bug middle-end/40080] New: error: missing callgraph edge for call stmt

[marcus at jet dot franken dot de]

/home/marcus/projects/gcc.trunk/BIN/bin/gcc -c  -O3  -o dplay.o dplay.i  
dplay.i:44: error: missing callgraph edge for call stmt:
# .MEM_13 = VDEF <.MEM_10>
D.2719_6 = xcbDeletePlayerFromAllGroups ();

xDP_IF_EnumGroupsInGroup.clone.0/10(-1) [0x7fa23ece1800]: (inline copy in
xDP_IF_DestroyPlayer/3) (clone of xDP_IF_EnumGroupsInGroup.clone.0/8)
availability:local 38 insns body local finalized inlinable
  called by: xcbDeletePlayerFromAllGroups/9 (9.18 per call) (inlined) 
  calls: ff/4 (9.18 per call) 
dplay.i:44: internal compiler error: verify_cgraph_node failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: error: missing callgraph edge for call stmt
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: marcus at jet dot franken 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=40080

[Bug middle-end/40080] error: missing callgraph edge for call stmt

[marcus at jet dot franken dot de]

--- Comment #1 from marcus at jet dot franken dot de  2009-05-09 09:11 
---
Created an attachment (id=17834)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17834&action=view)
dplay.i

reduced testcase

gcc -c -O3 dplay.i


-- 


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

[Bug middle-end/40079] [4.5 Regression] Revision 147294 caused extra failures

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.0


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

[Bug middle-end/40080] [4.5 Regression] error: missing callgraph edge for call stmt

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-05-09 09:21 ---
Honza, this is caused by your cgraph changes.  Likely an easier to reproduced
case than PR40079.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC|richard dot guenther at |rguenth at gcc dot gnu dot
   |gmail dot com   |org, hubicka at gcc dot gnu
   ||dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-checking, ice-on-valid-
   ||code
   Last reconfirmed|-00-00 00:00:00 |2009-05-09 09:21:42
   date||
Summary|error: missing callgraph|[4.5 Regression] error:
   |edge for call stmt  |missing callgraph edge for
   ||call stmt
   Target Milestone|--- |4.5.0


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

[Bug middle-end/40043] [4.5 Regression] ICE with nested try/catch

[hubicka at gcc dot gnu dot org]

--- Comment #1 from hubicka at gcc dot gnu dot org  2009-05-09 10:52 ---
Subject: Bug 40043

Author: hubicka
Date: Sat May  9 10:52:24 2009
New Revision: 147317

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

* g++.dg/eh/nested-try.C: New test.

PR middle-end/40043
* except.c (copy_eh_region): Always set prev_try.
(redirect_eh_edge_to_label): Find outer try.
(foreach_reachable_handler): When looking for prev try
handle case where previous try is not going to be taken.

Added:
trunk/gcc/testsuite/g++.dg/eh/nested-try.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/except.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/40081] New: verify_stmts failed with -O2

[dcb314 at hotmail dot com]

I just tried to compile the Suse Linux package blocxx-2.1.0.342-124.2
with the GNU gcc version 4.5 snapshot 20090507.

The compiler said

dlSharedLibrary.cpp:192: error: invalid rhs for gimple memory store
c$val

c.val;

# .MEM_4 = VDEF <.MEM_2(D)>
c$val ={v} c.val;

dlSharedLibrary.cpp:192: error: invalid rhs for gimple memory store
this_1(D)->m_count.val;

c$val

# .MEM_5 = VDEF <.MEM_4>
this_1(D)->m_count.val ={v} c$val;

dlSharedLibrary.cpp:192: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


Preprocessed source code attached. Flag -O2 required.
It compiles fine without -O2.


-- 
   Summary: verify_stmts failed with -O2
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
  GCC host triplet: x86_64-suse-linux


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

[Bug c++/40081] verify_stmts failed with -O2

[dcb314 at hotmail dot com]

--- Comment #1 from dcb314 at hotmail dot com  2009-05-09 11:08 ---
Created an attachment (id=17835)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17835&action=view)
C++ source code


-- 


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

[Bug target/40072] Nonoptimal code - CMOVxx %eax,%edi; mov %edi,%eax; retq

[vvv at ru dot ru]

--- Comment #1 from vvv at ru dot ru  2009-05-09 12:02 ---
There is no bug for current trunk. So bug fixed.


-- 

vvv at ru dot ru changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug bootstrap/40082] New: Power bootstrap is broken in building libstdc++

[meissner at linux dot vnet dot ibm dot com]

I synced up to the current tree, and did a bootstrap build, and it fails in
building libstdc++:
/home/meissner/fsf-src/trunk/libstdc++-v3/src/compatibility-ldbl.cc:77: error:
inlined_to pointer is wrong
void std::basic_string<_CharT, _Traits, _Alloc>::_M_leak() [with _CharT =
wchar_t, _Traits = std::char_traits, _Alloc =
std::allocator]/608(-1) [0x4000183b500]: (inline copy in _OutIter
std::money_put<_CharT, _OutIter>::_M_insert(iter_type, std::ios_base&,
char_type, const std::money_put<_CharT, _OutIter>::string_type&) const [with
bool _Intl = true, _CharT = wchar_t, _OutIter =
std::ostreambuf_iterator, iter_type =
std::ostreambuf_iterator, char_type = wchar_t, std::money_put<_CharT,
_OutIter>::string_type = std::basic_string]/568) (clone of void
std::basic_string<_CharT, _Traits, _Alloc>::_M_leak() [with _CharT = wchar_t,
_Traits = std::char_traits, _Alloc = std::allocator]/648)
availability:available 16 insns body finalized inlinable
  called by: std::basic_string<_CharT, _Traits, _Alloc>::reference
std::basic_string<_CharT, _Traits,
_Alloc>::operator[](std::basic_string<_CharT, _Traits, _Alloc>::size_type)
[with _CharT = wchar_t, _Traits = std::char_traits, _Alloc =
std::allocator, std::basic_string<_CharT, _Traits, _Alloc>::reference
= wchar_t&, std::basic_string<_CharT, _Traits, _Alloc>::size_type = long
unsigned int]/246 (1.00 per call) (inlined) (can throw external) 
  calls: void std::basic_string<_CharT, _Traits, _Alloc>::_M_leak_hard() [with
_CharT = wchar_t, _Traits = std::char_traits, _Alloc =
std::allocator]/858 (0.63 per call) (can throw external) 
/home/meissner/fsf-src/trunk/libstdc++-v3/src/compatibility-ldbl.cc:77:
internal compiler error: verify_cgraph_node failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions


-- 
   Summary: Power bootstrap is broken in building libstdc++
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: meissner at linux dot vnet dot ibm dot com
 GCC build triplet: powerpc64-unknown-linux-gnu
  GCC host triplet: powerpc64-unknown-linux-gnu
GCC target triplet: powerpc64-unknown-linux-gnu


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

[Bug bootstrap/40082] Power bootstrap is broken in building libstdc++

[meissner at linux dot vnet dot ibm dot com]

--- Comment #1 from meissner at linux dot vnet dot ibm dot com  2009-05-09 
12:36 ---
Created an attachment (id=17836)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17836&action=view)
.ii file of file in libstdc++ that causes the failure

The options needed to show this bug are:
-O2 -mlong-double-64 -fno-implicit-templates


-- 


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

[Bug bootstrap/40082] [4.5 Regression] Power bootstrap is broken in building libstdc++

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-05-09 12:53 ---
Bah.  Honza?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu dot
   ||org
   Keywords||ice-checking, ice-on-valid-
   ||code
Summary|Power bootstrap is broken in|[4.5 Regression] Power
   |building libstdc++  |bootstrap is broken in
   ||building libstdc++
   Target Milestone|--- |4.5.0


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

[Bug middle-end/27313] Does not emit conditional moves for stores

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2009-05-09 12:59 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug c++/40081] verify_stmts failed with -O2

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2009-05-09 13:21 ---
Reducing.


-- 


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

[Bug tree-optimization/40081] verify_stmts failed with -O2

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-05-09 13:34 ---
struct Atomic_t {
Atomic_t(int i) : val(i) { }
volatile int val;
};
class RefCount {
public:
RefCount(Atomic_t c) : m_count(c)  { }
Atomic_t m_count;
};
class IntrusiveCountableBase {
RefCount m_useCount;
protected:
IntrusiveCountableBase();
};
IntrusiveCountableBase::IntrusiveCountableBase() : m_useCount(0)  { }


the issue is the volatile qualifier on val for the temporary used for
the RefCount constructor call.  SRA should either drop the qualifier or
not scalarize this.

Martin, please add the testcase to the new SRA (and verify it does things
correct here).  Thx.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||mjambor at suse dot cz
 Status|UNCONFIRMED |NEW
  Component|c++ |tree-optimization
 Ever Confirmed|0   |1
   Keywords||ice-checking, ice-on-valid-
   ||code, wrong-code
   Last reconfirmed|-00-00 00:00:00 |2009-05-09 13:34:34
   date||


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

[Bug bootstrap/40082] [4.5 Regression] Power bootstrap is broken in building libstdc++

[hubicka at ucw dot cz]

--- Comment #3 from hubicka at ucw dot cz  2009-05-09 14:44 ---
Subject: Re:  [4.5 Regression] Power bootstrap is broken in building libstdc++

Hi,
I am testing the attached patch.  It makes testcase to compile, does it
solve bootstrap issues too?

Index: ipa.c
===
--- ipa.c   (revision 147317)
+++ ipa.c   (working copy)
@@ -92,6 +92,21 @@ cgraph_postorder (struct cgraph_node **o
   return order_pos;
 }

+/* Look for all functions inlined to NODE and update their inlined_to pointers
+   to INLINED_TO.  */
+
+static void
+update_inlined_to_pointer (struct cgraph_node *node, struct cgraph_node
*inlined_to)
+{
+  struct cgraph_edge *e;
+  for (e = node->callees; e; e = e->next_callee)
+if (e->callee->global.inlined_to)
+  {
+e->callee->global.inlined_to = inlined_to;
+   update_inlined_to_pointer (e->callee, inlined_to);
+  }
+}
+
 /* Perform reachability analysis and reclaim all unreachable nodes.
If BEFORE_INLINING_P is true this function is called before inlining
decisions has been made.  If BEFORE_INLINING_P is false this function also 
@@ -214,7 +229,8 @@ cgraph_remove_unreachable_nodes (bool be
  && !node->callers)
{
  gcc_assert (node->clones);
- node->global.inlined_to = false;
+ node->global.inlined_to = NULL;
+ update_inlined_to_pointer (node, node);
}
   node->aux = NULL;
 }


-- 


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

[Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node

[jv244 at cam dot ac dot uk]

--- Comment #16 from jv244 at cam dot ac dot uk  2009-05-09 14:57 ---
tried once running under valgrind, but that doesn't give more info, no errors
till the point of the stack overflow:

GNU Fortran (GCC) version 4.5.0 20090509 (experimental) [trunk revision 147317]
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.5.0 20090509 (experimental) [trunk revision
147317], GMP version 4.2.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
==27399== Stack overflow in thread 1: can't grow stack to 0x7FE801FF8
==27399== Can't extend stack to 0x7FE801700 during signal delivery for thread
1:
==27399==   no stack segment
==27399==
==27399== Process terminating with default action of signal 11 (SIGSEGV):
dumping core
==27399==  Access not within mapped region at address 0x7FE801700
==27399==at 0x529DC8: gt_ggc_mx_lang_tree_node (gt-fortran-f95-lang.h:46)


-- 


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

[Bug middle-end/40083] New: [4.5 Regression] 403.gcc in SPEC CPU 2006 failed at -O3

[hjl dot tools at gmail dot com]

On Linux/Intel64, revision 147294 gave:

gcc -c -o function.o -DSPEC_CPU -DNDEBUG -I.   -O3 -ffast-math -funroll-loops  
-DSPEC_CPU_LP64 function.c
function.c:8078: error: edge points to wrong declaration:
 >
QI
size 
unit size 
align 8 symtab 0 alias set -1 canonical type 0x2b1ba0f45f00
arg-types 
chain 
chain >>>
pointer_to_this >
addressable used nothrow static decl_5 QI file function.c line 6764 col 1
align 8 initial 
arguments 
sizes-gimplified public unsigned DI
size 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x2b1ba0c5e540
pointer_to_this >
used unsigned DI file function.c line 6765 col 10 size  unit size 
align 64 context 
arg-type 
chain 
used unsigned DI file function.c line 6766 col 12 size  unit size 
align 64 context  attributes  arg-type
>>
result 
ignored VOID file function.c line 6765 col 6
align 8 context >
saved-insns 0x2b1ba102bb40 chain >
 Instead of: >
QI
size 
unit size 
align 8 symtab 0 alias set -1 canonical type 0x2b1ba0f45f00
arg-types 
chain 
chain >>>
pointer_to_this >
addressable used nothrow static decl_5 QI file function.c line 6789 col 1
align 8 initial 
arguments 
sizes-gimplified public unsigned DI
size 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x2b1ba0c5e540
pointer_to_this >
used unsigned DI file function.c line 6790 col 10 size  unit size 
align 64 context 
arg-type 
chain 
used unsigned DI file function.c line 6791 col 12 size  unit size 
align 64 context 
attributes  arg-type >>
result 
ignored VOID file function.c line 6790 col 6
align 8 context >
saved-insns 0x2b1ba102bea0 chain >
specmake[3]: *** [function.o] Error 1


-- 
   Summary: [4.5 Regression]  403.gcc in SPEC CPU 2006 failed at -O3
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug middle-end/40084] New: [4.5 Regression] 483.xalancbmk in SPEC CPU 2006 failed at -O3

[hjl dot tools at gmail dot com]

On Linux/Intel64, revision 147294 gave

g++ -c -o StylesheetExecutionContextDefault.o -DSPEC_CPU -DNDEBUG 
-DAPP_NO_THREADS -DXALAN_INMEM_MSG_LOADER -I. -Ixercesc -Ixercesc/dom
-Ixercesc/dom/impl -Ixercesc/sax -Ixercesc/util/MsgLoaders/InMemory
-Ixercesc/util/Transcoders/Iconv -Ixalanc/include -DPROJ_XMLPARSER
-DPROJ_XMLUTIL -DPROJ_PARSERS -DPROJ_SAX4C -DPROJ_SAX2 -DPROJ_DOM
-DPROJ_VALIDATORS -DXML_USE_NATIVE_TRANSCODER -DXML_USE_INMEM_MESSAGELOADER 
-O3 -ffast-math -funroll-loops   -DSPEC_CPU_LP64  -DSPEC_CPU_LINUX
StylesheetExecutionContextDefault.cpp
In file included from DOMAttrImpl.cpp:67:
xercesc/dom/DOMCasts.hpp: In function 'xercesc_2_5::DOMNode*
xercesc_2_5::castToNode(const xercesc_2_5::DOMParentNode*)':
xercesc/dom/DOMCasts.hpp:148: warning: invalid access to non-static data member
'xercesc_2_5::DOMElementImpl::fParent'  of NULL object
xercesc/dom/DOMCasts.hpp:148: warning: (perhaps the 'offsetof' macro was used
incorrectly)
xercesc/dom/DOMCasts.hpp: In function 'xercesc_2_5::DOMNode*
xercesc_2_5::castToNode(const xercesc_2_5::DOMNodeImpl*)':
xercesc/dom/DOMCasts.hpp:154: warning: invalid access to non-static data member
'xercesc_2_5::DOMElementImpl::fNode'  of NULL object
xercesc/dom/DOMCasts.hpp:154: warning: (perhaps the 'offsetof' macro was used
incorrectly)
xercesc/dom/DOMCasts.hpp: In function 'xercesc_2_5::DOMNodeImpl*
xercesc_2_5::castToNodeImpl(const xercesc_2_5::DOMParentNode*)':
xercesc/dom/DOMCasts.hpp:162: warning: invalid access to non-static data member
'xercesc_2_5::DOMElementImpl::fNode'  of NULL object
xercesc/dom/DOMCasts.hpp:162: warning: (perhaps the 'offsetof' macro was used
incorrectly)
xercesc/dom/DOMCasts.hpp:163: warning: invalid access to non-static data member
'xercesc_2_5::DOMElementImpl::fParent'  of NULL object
xercesc/dom/DOMCasts.hpp:163: warning: (perhaps the 'offsetof' macro was used
incorrectly)
In file included from DOMAttrMapImpl.cpp:68:
xercesc/dom/DOMCasts.hpp: In function 'xercesc_2_5::DOMNode*
xercesc_2_5::castToNode(const xercesc_2_5::DOMParentNode*)':
xercesc/dom/DOMCasts.hpp:148: warning: invalid access to non-static data member
'xercesc_2_5::DOMElementImpl::fParent'  of NULL object
xercesc/dom/DOMCasts.hpp:148: warning: (perhaps the 'offsetof' macro was used
incorrectly)
xercesc/dom/DOMCasts.hpp: In function 'xercesc_2_5::DOMNode*
xercesc_2_5::castToNode(const xercesc_2_5::DOMNodeImpl*)':
xercesc/dom/DOMCasts.hpp:154: warning: invalid access to non-static data member
'xercesc_2_5::DOMElementImpl::fNode'  of NULL object
xercesc/dom/DOMCasts.hpp:154: warning: (perhaps the 'offsetof' macro was used
incorrectly)
xercesc/dom/DOMCasts.hpp: In function 'xercesc_2_5::DOMNodeImpl*
xercesc_2_5::castToNodeImpl(const xercesc_2_5::DOMParentNode*)':
xercesc/dom/DOMCasts.hpp:162: warning: invalid access to non-static data member
'xercesc_2_5::DOMElementImpl::fNode'  of NULL object
xercesc/dom/DOMCasts.hpp:162: warning: (perhaps the 'offsetof' macro was used
incorrectly)
xercesc/dom/DOMCasts.hpp:163: warning: invalid access to non-static data member
'xercesc_2_5::DOMElementImpl::fParent'  of NULL object
xercesc/dom/DOMCasts.hpp:163: warning: (perhaps the 'offsetof' macro was used
incorrectly)
In file included from DOMCDATASectionImpl.cpp:65:
xercesc/dom/DOMCasts.hpp: In function 'xercesc_2_5::DOMNode*
xercesc_2_5::castToNode(const xercesc_2_5::DOMParentNode*)':
xercesc/dom/DOMCasts.hpp:148: warning: invalid access to non-static data member
'xercesc_2_5::DOMElementImpl::fParent'  of NULL object
xercesc/dom/DOMCasts.hpp:148: warning: (perhaps the 'offsetof' macro was used
incorrectly)
xercesc/dom/DOMCasts.hpp: In function 'xercesc_2_5::DOMNode*
xercesc_2_5::castToNode(const xercesc_2_5::DOMNodeImpl*)':
xercesc/dom/DOMCasts.hpp:154: warning: invalid access to non-static data member
'xercesc_2_5::DOMElementImpl::fNode'  of NULL object
xercesc/dom/DOMCasts.hpp:154: warning: (perhaps the 'offsetof' macro was used
incorrectly)
xercesc/dom/DOMCasts.hpp: In function 'xercesc_2_5::DOMNodeImpl*
xercesc_2_5::castToNodeImpl(const xercesc_2_5::DOMParentNode*)':
xercesc/dom/DOMCasts.hpp:162: warning: invalid access to non-static data member
'xercesc_2_5::DOMElementImpl::fNode'  of NULL object
xercesc/dom/DOMCasts.hpp:162: warning: (perhaps the 'offsetof' macro was used
incorrectly)
xercesc/dom/DOMCasts.hpp:163: warning: invalid access to non-static data member
'xercesc_2_5::DOMElementImpl::fParent'  of NULL object
xercesc/dom/DOMCasts.hpp:163: warning: (perhaps the 'offsetof' macro was used
incorrectly)
In file included from DOMCharacterDataImpl.cpp:66:
xercesc/dom/DOMCasts.hpp: In function 'xercesc_2_5::DOMNode*
xercesc_2_5::castToNode(const xercesc_2_5::DOMParentNode*)':
xercesc/dom/DOMCasts.hpp:148: warning: invalid access to non-static data member
'xercesc_2_5::DOMElementImpl::fParent'  of NULL object
xercesc/dom/DOMCasts.hpp:148: warning: (perhaps the 'offsetof' macro was used
incorrectly)
xercesc/dom/DOMCasts.hpp: In function 'xercesc_2_5::DOMNode*
xercesc_2_5::castToNod

[Bug middle-end/40083] [4.5 Regression] 403.gcc in SPEC CPU 2006 failed at -O3

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-05-09 15:21 ---
preprocessed source?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu dot
   ||org
   Target Milestone|--- |4.5.0


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

[Bug middle-end/40084] [4.5 Regression] 483.xalancbmk in SPEC CPU 2006 failed at -O3

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-05-09 15:22 ---
preprocessed source?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu dot
   ||org
   Target Milestone|--- |4.5.0


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

[Bug bootstrap/40082] [4.5 Regression] Power bootstrap is broken in building libstdc++

[meissner at linux dot vnet dot ibm dot com]

--- Comment #4 from meissner at linux dot vnet dot ibm dot com  2009-05-09 
15:56 ---
Subject: Re:  [4.5 Regression] Power bootstrap is broken in building libstdc++

On Sat, May 09, 2009 at 02:44:29PM -, hubicka at ucw dot cz wrote:
> 
> 
> --- Comment #3 from hubicka at ucw dot cz  2009-05-09 14:44 ---
> Subject: Re:  [4.5 Regression] Power bootstrap is broken in building libstdc++
> 
> Hi,
> I am testing the attached patch.  It makes testcase to compile, does it
> solve bootstrap issues too?

I just fired off a bootstrap, and will let you know when I get back to the
computer in a few hours.

Thanks.


-- 


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

[Bug middle-end/40084] [4.5 Regression] 483.xalancbmk in SPEC CPU 2006 failed at -O3

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2009-05-09 16:02 ---
Created an attachment (id=17837)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17837&action=view)
A testcase failed at -O3


-- 


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

[Bug middle-end/40083] [4.5 Regression] 403.gcc in SPEC CPU 2006 failed at -O3

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2009-05-09 16:02 ---
Created an attachment (id=17838)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17838&action=view)
A testcase failed at -O3


-- 


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

[Bug tree-optimization/40081] verify_stmts failed with -O2

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-05-09 17:57 ---
Same problem in 4.4, 4.3 and 4.2, just only the type verifier verifies this.
It's not critial (it will be treated the same as struct copies - thus it is
simply inefficient).  I'll see if a fix is simple.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||missed-optimization
  Known to fail||4.3.3 4.4.0


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

[Bug tree-optimization/40081] verify_stmts failed with -O2

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2009-05-09 18:07 ---
Mine.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-05-09 13:34:34 |2009-05-09 18:07:58
   date||


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

[Bug middle-end/40026] [4.5 Regression] ICE during gimplify_init_constructor

[jsm28 at gcc dot gnu dot org]

--- Comment #4 from jsm28 at gcc dot gnu dot org  2009-05-09 18:09 ---
gimplify_init_constructor does

  tree ctor = TREE_OPERAND (*expr_p, 1);
...
  new_ctor = optimize_compound_literals_in_ctor (ctor);
  elts = CONSTRUCTOR_ELTS (new_ctor);
...
gimplify_init_ctor_preeval (&TREE_OPERAND (*expr_p, 1),
pre_p, post_p, &preeval_data);
(which changes a COND_EXPR to have void type, updating the pointer to
that COND_EXPR in TREE_OPERAND (*expr_p, 1) - the old constructor -
to point to the gimplifier-generated temorary instead)
...
if (!cleared || num_nonzero_elements > 0)
  gimplify_init_ctor_eval (object, elts, pre_p, cleared);
(which goes through the elements of the new constructor, finds the
modified COND_EXPR and ends up segfaulting because of that).

This looks like the compound literal changes must be responsible and
that it is a gimplifier bug.


-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||bonzini at gnu dot org
 Status|UNCONFIRMED |NEW
  Component|c   |middle-end
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-05-09 18:09:03
   date||


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

[Bug middle-end/40084] [4.5 Regression] Revision 147294 failed 483.xalancbmk in SPEC CPU 2006 at -O3

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2009-05-09 18:09 ---
Revision 147294:

http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00268.html

is the cause.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

Summary|[4.5 Regression]|[4.5 Regression]  Revision
   |483.xalancbmk in SPEC CPU   |147294 failed 483.xalancbmk
   |2006 failed at -O3  |in SPEC CPU 2006 at -O3


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

[Bug middle-end/40083] [4.5 Regression] Revision 147294 failed 403.gcc in SPEC CPU 2006 at -O3

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2009-05-09 18:10 ---
Revision 147294:

http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00268.html

is the cause.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

Summary|[4.5 Regression]  403.gcc in|[4.5 Regression] Revision
   |SPEC CPU 2006 failed at -O3 |147294 failed 403.gcc in
   ||SPEC CPU 2006 at -O3


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

[Bug middle-end/39886] [4.5 Regression] ICE in purge_dead_edges, at cfgrtl.c:2274

[hubicka at ucw dot cz]

--- Comment #2 from hubicka at ucw dot cz  2009-05-09 18:29 ---
Subject: Re:  [4.5 Regression] ICE in purge_dead_edges, at cfgrtl.c:2274

The problem here is that combine constructs (set (pc) (pc)) as noo-op
move expecting it to be removed immediately.  It is however
misinterpreted as jump that is giong to be removed at the end of BB and 
update_cfg_for_uncondjump add FALLTHRU flag on the edge that fails in
verification.

Interestingly enough modifying update_cfg_for_uncondjump to ignore insns
that are not last in BB seem to cause miscompilations in testsuite
I am looking into the cgraph failures now, but this should be easy to
fix.

Honza


-- 


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

[Bug bootstrap/40082] [4.5 Regression] Power bootstrap is broken in building libstdc++

[hubicka at gcc dot gnu dot org]

--- Comment #5 from hubicka at gcc dot gnu dot org  2009-05-09 18:31 ---
Subject: Bug 40082

Author: hubicka
Date: Sat May  9 18:31:32 2009
New Revision: 147319

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147319
Log:
PR bootstrap/40082
* ipa.c (update_inlined_to_pointer): New function.
(cgraph_remove_unreachable_nodes): Use it.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa.c


-- 


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

[Bug middle-end/40080] [4.5 Regression] error: missing callgraph edge for call stmt

[hubicka at ucw dot cz]

--- Comment #3 from hubicka at ucw dot cz  2009-05-09 18:52 ---
Subject: Re:  [4.5 Regression] error: missing callgraph edge for call stmt

Hi,
I am testing the following:

Index: cgraphunit.c
===
--- cgraphunit.c(revision 147319)
+++ cgraphunit.c(working copy)
@@ -1762,7 +1762,12 @@ cgraph_materialize_all_clones (void)
for (e = node->callees; e; e = e->next_callee)
  {
tree decl = gimple_call_fndecl (e->call_stmt);
-   if (decl != e->callee->decl)
+   /* When function gets inlined, indirect inlining might've invented
+  new edge for orginally indirect stmt.  Since we are not
+  preserving clones in the original form, we must not update here
+  since other inline clones don't need to contain call to the same
+  call.  Inliner will do the substitution for us later.  */
+   if (decl && decl != e->callee->decl)
  {
gimple new_stmt;
gimple_stmt_iterator gsi;
@@ -1808,6 +1813,9 @@ cgraph_materialize_all_clones (void)
 verify_cgraph_node (node);
 #endif
   }
+#ifdef ENABLE_CHECKING
+  verify_cgraph ();
+#endif
   cgraph_remove_unreachable_nodes (false, cgraph_dump_file);
 }



-- 


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

[Bug middle-end/40080] [4.5 Regression] error: missing callgraph edge for call stmt

[hubicka at gcc dot gnu dot org]

--- Comment #4 from hubicka at gcc dot gnu dot org  2009-05-09 20:10 ---
Subject: Bug 40080

Author: hubicka
Date: Sat May  9 20:10:37 2009
New Revision: 147320

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

PR middle-end/40080
* cgraphunit.c (cgraph_materialize_all_clones): Do not redirect
indirect calls; verify cgraph afterwards.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraphunit.c


-- 


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

[Bug fortran/39996] Double typing of function results not detected

[janus at gcc dot gnu dot org]

-- 

janus at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |janus at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-05-05 20:35:34 |2009-05-09 20:53:00
   date||


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

[Bug middle-end/40084] [4.5 Regression] Revision 147294 failed 483.xalancbmk in SPEC CPU 2006 at -O3

[hubicka at ucw dot cz]

--- Comment #4 from hubicka at ucw dot cz  2009-05-09 21:06 ---
Subject: Re:  [4.5 Regression]  Revision 147294 failed 483.xalancbmk in SPEC
CPU 2006 at -O3

Hi,
I am testing the following patch thasolves the ICE.
Problem here was that we cleated ipa-cp clone and clonning proces
allowed devirtualization that however creates new dirrect call and
callgraph is not properly updated.

We should handle devirtualization when inlining or const propagating,
this seems common case. We seem to miss here number of inlining
oppurtunities.

Honza

Index: tree-inline.c
===
--- tree-inline.c   (revision 147320)
+++ tree-inline.c   (working copy)
@@ -1522,7 +1522,8 @@ copy_bb (copy_body_data *id, basic_block
gcc_assert (dest->needed || !dest->analyzed);
if (id->transform_call_graph_edges == CB_CGE_MOVE_CLONES)
  cgraph_create_edge_including_clones (id->dst_node, dest,
stmt,
-  bb->count,
CGRAPH_FREQ_BASE,
+  bb->count,
+ 
compute_call_stmt_bb_frequency (id->dst_node->decl, bb),
   bb->loop_depth,
  
CIF_ORIGINALLY_INDIRECT_CALL);
else
@@ -3535,8 +3536,9 @@ fold_marked_statements (int first, struc
 if (BASIC_BLOCK (first))
   {
 gimple_stmt_iterator gsi;
+   basic_block bb = BASIC_BLOCK (first);

-   for (gsi = gsi_start_bb (BASIC_BLOCK (first));
+   for (gsi = gsi_start_bb (bb);
 !gsi_end_p (gsi);
 gsi_next (&gsi))
  if (pointer_set_contains (statements, gsi_stmt (gsi)))
@@ -3545,14 +3547,26 @@ fold_marked_statements (int first, struc

  if (fold_stmt (&gsi))
{
+ tree decl;
+
  /* Re-read the statement from GSI as fold_stmt() may
 have changed it.  */
  gimple new_stmt = gsi_stmt (gsi);
  update_stmt (new_stmt);

- if (is_gimple_call (old_stmt))
-   cgraph_update_edges_for_call_stmt (old_stmt, new_stmt);
+ if (is_gimple_call (new_stmt)
+ && (decl = gimple_call_fndecl (new_stmt)))
+   {
+ struct cgraph_node *node = cgraph_node
(current_function_decl);

+ if (cgraph_edge (node, old_stmt))
+   cgraph_update_edges_for_call_stmt (old_stmt, new_stmt);
+ else
+   cgraph_create_edge_including_clones
+  (node, cgraph_node (decl), new_stmt, bb->count,
+   compute_call_stmt_bb_frequency
(current_function_decl, bb),
+   bb->loop_depth, CIF_ORIGINALLY_INDIRECT_CALL);
+}
  if (maybe_clean_or_replace_eh_stmt (old_stmt, new_stmt))
gimple_purge_dead_eh_edges (BASIC_BLOCK (first));
}


-- 


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

[Bug c++/40085] New: ICE compiling libmudflap.c++/fail24-frag.cxx

[danglin at gcc dot gnu dot org]

Executing on host: /home/dave/gcc-4.5/objdir/./gcc/g++ -shared-libgcc
-B/home/da
ve/gcc-4.5/objdir/./gcc -nostdinc++
-L/home/dave/gcc-4.5/objdir/hppa-linux/libst
dc++-v3/src -L/home/dave/gcc-4.5/objdir/hppa-linux/libstdc++-v3/src/.libs
-B/hom
e/dave/opt/gnu/gcc/gcc-4.5.0/hppa-linux/bin/
-B/home/dave/opt/gnu/gcc/gcc-4.5.0/
hppa-linux/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-4.5.0/hppa-linux/include
-is
ystem /home/dave/opt/gnu/gcc/gcc-4.5.0/hppa-linux/sys-include -ggdb3
-DDEBUG_ASS
ERT -g -O2 -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections
-fdata-secti
ons -g -O2 -D_GNU_SOURCE -I/home/dave/gcc-4.5/gcc/libmudflap/testsuite
-I/home/d
ave/gcc-4.5/gcc/libmudflap/testsuite/.. -I.. -nostdinc++
-I/home/dave/gcc-4.5/ob
jdir/hppa-linux/libstdc++-v3/include/hppa-linux
-I/home/dave/gcc-4.5/objdir/hppa
-linux/libstdc++-v3/include -I/home/dave/gcc-4.5/gcc/libstdc++-v3/libsupc++
-I/h
ome/dave/gcc-4.5/gcc/libstdc++-v3/include/backward
-I/home/dave/gcc-4.5/gcc/libs
tdc++-v3/testsuite/util
-L/home/dave/gcc-4.5/objdir/hppa-linux/./libmudflap/.lib
s /home/dave/gcc-4.5/gcc/libmudflap/testsuite/libmudflap.c++/fail24-frag.cxx  
-
fmudflap -lmudflap 
-L/home/dave/gcc-4.5/objdir/hppa-linux/./libmudflap/testsuit
e -ldl -lm   -o ./fail24-frag.exe(timeout = 300)

g++: Internal error: Segmentation fault (program cc1plus)
Please submit a full bug report.
See  for instructions.
compiler exited with status 1
output is:

g++: Internal error: Segmentation fault (program cc1plus)
Please submit a full bug report.
See  for instructions.

FAIL: libmudflap.c++/fail24-frag.cxx (test for excess errors)

The ICE occurs here:

Program received signal SIGSEGV, Segmentation fault.
0x0011ddec in cp_diagnostic_starter (context=0x978844, diagnostic=0xfe25c30c)
at ../../gcc/gcc/cp/error.c:2624
2624  if (DECL_FUNCTION_MEMBER_P (fn))

It seems DECL_LANG_SPECIFIC (fn) is NULL:

(gdb) p debug_tree ($r3)
 >
SI
size 
unit size 
align 32 symtab 0 alias set -1 canonical type 0x401cf150
arg-types >
pointer_to_this >
used static SI file
/home/dave/gcc-4.5/gcc/libmudflap/testsuite/libmudflap.c++/fail24-frag.cxx line
12 col 1 align 32 initial 
result 
VOID file
/home/dave/gcc-4.5/gcc/libmudflap/testsuite/libmudflap.c++/fail24-frag.cxx line
12 col 1
align 8 context >
saved-insns 0x402899f8>

(gdb) p ((tree)$r3)->decl_common
$13 = {common = {common = {base = {code = FUNCTION_DECL, 
side_effects_flag = 0, constant_flag = 0, addressable_flag = 0, 
volatile_flag = 0, readonly_flag = 0, unsigned_flag = 0, 
asm_written_flag = 0, nowarning_flag = 0, used_flag = 1, 
nothrow_flag = 0, static_flag = 1, public_flag = 0, private_flag = 0, 
protected_flag = 0, deprecated_flag = 0, saturating_flag = 0, 
default_def_flag = 0, lang_flag_0 = 0, lang_flag_1 = 0, 
lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0, 
lang_flag_6 = 0, visited = 0, spare = 0, ann = 0x0}, chain = 0x0, 
  type = 0x401cf150}, locus = 1317191, uid = 2368, name = 0x402ecb98, 
context = 0x0}, size = 0x0, mode = SImode, nonlocal_flag = 0, 
  virtual_flag = 0, ignored_flag = 0, abstract_flag = 0, artificial_flag = 1, 
  user_align = 0, preserve_flag = 0, debug_expr_is_from = 0, lang_flag_0 = 0, 
  lang_flag_1 = 0, lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0, 
  lang_flag_5 = 0, lang_flag_6 = 0, lang_flag_7 = 0, decl_flag_0 = 0, 
  decl_flag_1 = 0, decl_flag_2 = 0, decl_flag_3 = 0, gimple_reg_flag = 0, 
  no_tbaa_flag = 0, decl_by_reference_flag = 0, decl_common_unused = 0, 
  off_align = 0, size_unit = 0x0, initial = 0x402ecbd0, attributes = 0x0, 
  abstract_origin = 0x0, align = 32, pointer_alias_set = -1, 
  lang_specific = 0x0}


-- 
   Summary: ICE compiling libmudflap.c++/fail24-frag.cxx
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa-unknown-linux-gnu
  GCC host triplet: hppa-unknown-linux-gnu
GCC target triplet: hppa-unknown-linux-gnu


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

[Bug c++/40085] ICE compiling libmudflap.c++/fail24-frag.cxx

[danglin at gcc dot gnu dot org]

--- Comment #1 from danglin at gcc dot gnu dot org  2009-05-09 21:07 ---
The backtrace is:

(gdb) bt  
#0  0x0011ddec in cp_diagnostic_starter (context=0x978844, 
diagnostic=0xfe25c30c) at ../../gcc/gcc/cp/error.c:2624
#1  0x002aab28 in diagnostic_report_diagnostic (context=0x978844, 
diagnostic=0xfe25c30c) at ../../gcc/gcc/diagnostic.c:415
#2  0x002aae20 in internal_error (gmsgid=)
at ../../gcc/gcc/diagnostic.c:670
#3  0x002aae6c in fancy_abort (file=, line=1167, 
function=0x882480 "expand_one_var") at ../../gcc/gcc/diagnostic.c:724
#4  0x00702e00 in expand_one_var (var=0x402ebb40, toplevel=1 '\001', 
really_expand=1 '\001') at ../../gcc/gcc/cfgexpand.c:1160
#5  0x00706a54 in gimple_expand_cfg () at ../../gcc/gcc/cfgexpand.c:1535
#6  0x00449758 in execute_one_pass (pass=0x964730)
at ../../gcc/gcc/passes.c:1291
#7  0x00449a14 in execute_pass_list (pass=0x964730)
at ../../gcc/gcc/passes.c:1340
#8  0x00557d44 in tree_rest_of_compilation (fndecl=0x402dff80)
at ../../gcc/gcc/tree-optimize.c:394
#9  0x0069a68c in cgraph_add_new_function (fndecl=0x402dff80, lowered=0 '\0')
at ../../gcc/gcc/cgraph.c:1830
#10 0x0069c390 in cgraph_build_static_cdtor (which=73 'I', body=0x402ee040, 
priority=99) at ../../gcc/gcc/cgraphunit.c:1463
#11 0x001cb53c in mudflap_finish_file () at ../../gcc/gcc/tree-mudflap.c:1328
#12 0x00503c48 in toplev_main (argc=49, argv=0xfe25bb48)
---Type  to continue, or q  to quit---
at ../../gcc/gcc/toplev.c:1054
#13 0x4056693c in __libc_start_main (ma...@0x96a55a: 0x21e914 , argc=49, 
ubp_av=0xfe25bb48, init=, 
fi...@0x968192: 0x96a61c, rtld_fi...@0x401a867a: 0x40197ed8 <_dl_fini>, 
stack_end=0xfe25bd80) at libc-start.c:251
#14 0x00067398 in _start ()


-- 


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

[Bug c++/40085] ICE compiling libmudflap.c++/fail24-frag.cxx

[danglin at gcc dot gnu dot org]

--- Comment #2 from danglin at gcc dot gnu dot org  2009-05-09 21:11 ---
The var that triggered the error is:

(gdb) p debug_tree (var)
 >
asm_written public unsigned SI
size 
unit size 
align 32 symtab 1076204584 alias set 5 canonical type 0x401c9700
pointer_to_this  reference_to_this
>
public unsigned ignored weak SI file
/home/dave/gcc-4.5/gcc/libmudflap/testsuite/libmudflap.c++/fail24-frag.cxx line
12 col 1 size  unit size 
align 32 initial 
(mem/f/i:SI (symbol_ref/i:SI ("DW.ref.__gxx_personality_v0") [flags 0x200]
) [5
DW.ref.__gxx_personality_v0+0 S4 A32])>


-- 


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

[Bug target/40072] Nonoptimal code - CMOVxx %eax,%edi; mov %edi,%eax; retq

[ubizjak at gmail dot com]

--- Comment #2 from ubizjak at gmail dot com  2009-05-09 21:37 ---
(In reply to comment #1)
> There is no bug for current trunk. So bug fixed.

Not really, the move insn is moved to the beginning of the function:

0060 :
  60:   89 f8   mov%edi,%eax
  62:   83 ff 08cmp$0x8,%edi
  65:   ba 00 00 00 00  mov$0x0,%edx
  6a:   0f 4d c2cmovge %edx,%eax
  6d:   c3  retq   


-- 


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

[Bug tree-optimization/40074] [4.4/4.5 Regression] ICE in vect_get_vec_def_for_operand, at tree-vect-stmts.c:944

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2009-05-09 22:02 ---
This is caused by revision 145494:

http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00115.html


-- 


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

[Bug tree-optimization/40074] [4.4/4.5 Regression] ICE in vect_get_vec_def_for_operand, at tree-vect-stmts.c:944

[rguenth at gcc dot gnu dot org]

--- Comment #6 from rguenth at gcc dot gnu dot org  2009-05-09 22:10 ---
How can that be if the bug also happens on the 4.4 branch?


-- 


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

[Bug tree-optimization/40074] [4.4/4.5 Regression] ICE in vect_get_vec_def_for_operand, at tree-vect-stmts.c:944

[hjl dot tools at gmail dot com]

--- Comment #7 from hjl dot tools at gmail dot com  2009-05-09 22:15 ---
(In reply to comment #6)
> How can that be if the bug also happens on the 4.4 branch?
> 

The testcase in comment #4 compiles fine with gcc 4.4.1.


-- 


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

[Bug tree-optimization/40074] [4.4/4.5 Regression] ICE in vect_get_vec_def_for_operand, at tree-vect-stmts.c:944

[hjl dot tools at gmail dot com]

--- Comment #8 from hjl dot tools at gmail dot com  2009-05-09 22:31 ---
(In reply to comment #1)
> Created an attachment (id=17832)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17832&action=view) [edit]
> Preprocessed source of source that triggers ICE
> 

This was introduced between revisions 138059 and 13934.


-- 


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

[Bug tree-optimization/40074] [4.4/4.5 Regression] ICE in vect_get_vec_def_for_operand, at tree-vect-stmts.c:944

[jakub at gcc dot gnu dot org]

--- Comment #9 from jakub at gcc dot gnu dot org  2009-05-09 22:54 ---
The original testcase failure fails with both 4.4.x and trunk and was
introduced between 138524 and 138811.  The reduced testcase only fails on the
trunk, not on the 4.4 branch.


-- 


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

[Bug rtl-optimization/40086] New: [4.5 Regression]: cris-elf gfortran.dg/forall_1.f90 -O1 execution

[hp at gcc dot gnu dot org]

With revision 147269 this test passed.
>From revision 147274 and on, this test has failed as follows:

Running /tmp/rforall_1b/gcc/gcc/testsuite/gfortran.dg/dg.exp ...
...
FAIL: gfortran.dg/forall_1.f90  -O1  execution test

With the message in the logfile being:
Executing on host: /tmp/rforall_1b/gccobj/gcc/testsuite/gfortran/../../gfortran
-B/tmp/rforall_1b/gccobj/gcc/testsuite/gfortran/../../
/tmp/rforall_1b/gcc/gcc/testsuite/gfortran.dg/forall_1.f90   -O1  
-pedantic-errors   -isystem
/tmp/rforall_1b/gccobj/cris-elf/./newlib/targ-include -isystem
/tmp/rforall_1b/gcc/newlib/libc/include
-B/tmp/rforall_1b/gccobj/cris-elf/./libgloss/cris/
-L/tmp/rforall_1b/gccobj/cris-elf/./libgloss/cris
-L/tmp/rforall_1b/gcc/libgloss/cris 
-B/tmp/rforall_1b/gccobj/cris-elf/./newlib/
-L/tmp/rforall_1b/gccobj/cris-elf/./newlib -sim3 
-B/tmp/rforall_1b/gccobj/cris-elf/./libgfortran/.libs
-L/tmp/rforall_1b/gccobj/cris-elf/./libgfortran/.libs
-L/tmp/rforall_1b/gccobj/cris-elf/./libiberty  -lm   -o ./forall_1.exe   
(timeout = 300)
PASS: gfortran.dg/forall_1.f90  -O1  (test for excess errors)
program stopped with signal 6.

FAIL: gfortran.dg/forall_1.f90  -O1  execution test

(that is, abort is called)

Author of patches in suspect revision range CC:ed.


-- 
   Summary: [4.5 Regression]: cris-elf gfortran.dg/forall_1.f90  -O1
execution
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: cris-axis-elf


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

[Bug middle-end/40079] [4.5 Regression] Revision 147294 caused extra failures

[hp at gcc dot gnu dot org]

--- Comment #1 from hp at gcc dot gnu dot org  2009-05-09 23:02 ---
Seen for cris-elf too.


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hp at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-05-09 23:02:55
   date||


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

[Bug rtl-optimization/40086] [4.5 Regression]: cris-elf gfortran.dg/forall_1.f90 -O1 execution

[hp at gcc dot gnu dot org]

--- Comment #1 from hp at gcc dot gnu dot org  2009-05-10 00:04 ---
Created an attachment (id=17839)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17839&action=view)
slightly reduced test-case

It's the second abort call that's executed, but removing the first causes the
test to pass.  Here's a slightly reduced case, removing the parts after the
abort call.  Tell me if you need further assistance.


-- 


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

[Bug tree-optimization/40074] [4.4/4.5 Regression] ICE in vect_get_vec_def_for_operand, at tree-vect-stmts.c:944

[jakub at gcc dot gnu dot org]

--- Comment #10 from jakub at gcc dot gnu dot org  2009-05-10 00:08 ---
r138553 in particular.  -O2 -ftree-vectorize -m32 -msse2 is needed to reproduce
it.


-- 


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

[Bug tree-optimization/40074] [4.4/4.5 Regression] ICE in vect_get_vec_def_for_operand, at tree-vect-stmts.c:944

[hjl dot tools at gmail dot com]

--- Comment #11 from hjl dot tools at gmail dot com  2009-05-10 00:23 
---
It is caused by revision 138553:

http://gcc.gnu.org/ml/gcc-cvs/2008-08/msg00112.html


-- 


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

[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout

[dougkwan at google dot com]

--- Comment #12 from dougkwan at google dot com  2009-05-10 00:56 ---
Created an attachment (id=17840)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17840&action=view)
C test-case for the same problem on x86_64 and i386.

The original C++ test-case does not crash on x86_64 and i386.  I compared the
generated code and found that ARM EABI requires constructors to return values. 
That is not common and certainly is not the case on x86_64 and i386.  So gcc
generates very different code on both targert very early on.  The C test-case
was created based on the lowered C++ code in the middle-end.  It crashes with
just -O2 on x86_64 with both 4.3.1 and 4.4.0; it crashes on i386 similarly with
4.3.1.  I did not test 4.4.0 on i386.

Unfortunately this does not crash on ARM.


-- 


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

[Bug bootstrap/40082] [4.5 Regression] Power bootstrap is broken in building libstdc++

[meissner at linux dot vnet dot ibm dot com]

--- Comment #6 from meissner at linux dot vnet dot ibm dot com  2009-05-10 
01:05 ---
Subject: Re:  [4.5 Regression] Power bootstrap is broken in building libstdc++

On Sat, May 09, 2009 at 02:44:29PM -, hubicka at ucw dot cz wrote:
> 
> 
> --- Comment #3 from hubicka at ucw dot cz  2009-05-09 14:44 ---
> Subject: Re:  [4.5 Regression] Power bootstrap is broken in building libstdc++
> 
> Hi,
> I am testing the attached patch.  It makes testcase to compile, does it
> solve bootstrap issues too?

It does solve the bootstrap issue.


-- 


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

[Bug target/40068] GCC fails to apply dllexport attribute to typeinfo.

[dave dot korn dot cygwin at gmail dot com]

--- Comment #3 from dave dot korn dot cygwin at gmail dot com  2009-05-10 
01:11 ---
Created an attachment (id=17841)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17841&action=view)
inherit dllexport from class to typeinfo

Now testing a solution based on the approach of adding the dllexport attribute
to the class' typeinfo object when the class is passed to
i386_pe_adjust_class_at_definition.


-- 


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

[Bug fortran/38956] tests gfortran.dg/chmod_{1,2,3}.f90 fails on i686-pc-cygwin

[billingd at gcc dot gnu dot org]

--- Comment #6 from billingd at gcc dot gnu dot org  2009-05-10 01:15 
---
Subject: Bug 38956

Author: billingd
Date: Sun May 10 01:14:50 2009
New Revision: 147326

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147326
Log:
2009-04-10  David Billinghurst 

PR fortran/38956
* gfortran.dg/chmod_1.f90: Don't run on *-*-cygwin*.
* gfortran.dg/chmod_2.f90: Likewise.
* gfortran.dg/chmod_3.f90: Likewise.
* gfortran.dg/open_errors.f90: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/chmod_1.f90
trunk/gcc/testsuite/gfortran.dg/chmod_2.f90
trunk/gcc/testsuite/gfortran.dg/chmod_3.f90
trunk/gcc/testsuite/gfortran.dg/open_errors.f90


-- 


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

[Bug c/40087] New: Bad assembly for -O2

[markus at cs dot wisc dot edu]

This is gcc-4.3.3 in Gentoo, compiled with CHOST=i686-pc-linux-gnu and the
configure arguments:
--prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.3.3
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.3/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.3
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.3/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.3/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.3/include/g++-v4
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--disable-fixed-point --enable-nls --without-included-gettext
--with-system-zlib --disable-checking --disable-werror --enable-secureplt
--disable-multilib --enable-libmudflap --disable-libssp --enable-libgomp
--enable-cld --enable-java-awt=gtk --with-arch=i686
--enable-languages=c,c++,java,treelang,fortran --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.3-r2 p1.1,
pie-10.1.5'

Some simple code works with -O1 but not -O2.  I'll attach the C file and the
disassembly from objdump.  I'm no good with assembly, but I find it weird that
'last' is decremented by 8 at one point.


-- 
   Summary: Bad assembly for -O2
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: markus at cs dot wisc dot edu
 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=40087

[Bug c/40087] Bad assembly for -O2

[markus at cs dot wisc dot edu]

--- Comment #1 from markus at cs dot wisc dot edu  2009-05-10 01:41 ---
Created an attachment (id=17842)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17842&action=view)
reverse.c

(The strange usage of pointers is there since I found the bug in C++ code, but
noticed it's present in C as well.)


-- 


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

[Bug c/40087] Bad assembly for -O2

[markus at cs dot wisc dot edu]

--- Comment #2 from markus at cs dot wisc dot edu  2009-05-10 01:44 ---
`gcc -O1 reverse.c -o reverse -Wall && objdump -d reverse`

[...]
08048470 :
 8048470:   55  push   %ebp
 8048471:   89 e5   mov%esp,%ebp
 8048473:   53  push   %ebx
 8048474:   8b 4d 08mov0x8(%ebp),%ecx
 8048477:   8b 45 0cmov0xc(%ebp),%eax
 804847a:   39 c8   cmp%ecx,%eax
 804847c:   75 1a   jne8048498 
 804847e:   eb 36   jmp80484b6 
 8048480:   8b 11   mov(%ecx),%edx
 8048482:   8b 03   mov(%ebx),%eax
 8048484:   89 01   mov%eax,(%ecx)
 8048486:   89 13   mov%edx,(%ebx)
 8048488:   83 c1 04add$0x4,%ecx
 804848b:   39 d9   cmp%ebx,%ecx
 804848d:   74 27   je 80484b6 
 804848f:   83 eb 04sub$0x4,%ebx
 8048492:   39 d9   cmp%ebx,%ecx
 8048494:   75 ea   jne8048480 
 8048496:   eb 1e   jmp80484b6 
 8048498:   8d 58 fclea-0x4(%eax),%ebx
 804849b:   39 d9   cmp%ebx,%ecx
 804849d:   8d 76 00lea0x0(%esi),%esi
 80484a0:   74 14   je 80484b6 
 80484a2:   8b 11   mov(%ecx),%edx
 80484a4:   8b 03   mov(%ebx),%eax
 80484a6:   89 01   mov%eax,(%ecx)
 80484a8:   89 13   mov%edx,(%ebx)
 80484aa:   83 c1 04add$0x4,%ecx
 80484ad:   39 cb   cmp%ecx,%ebx
 80484af:   74 05   je 80484b6 
 80484b1:   83 eb 04sub$0x4,%ebx
 80484b4:   eb dc   jmp8048492 
 80484b6:   5b  pop%ebx
 80484b7:   5d  pop%ebp
 80484b8:   c3  ret
[...]

`gcc -O2 reverse.c -o reverse -Wall && objdump -d reverse`

[...]
08048470 :
 8048470:   55  push   %ebp
 8048471:   89 e5   mov%esp,%ebp
 8048473:   56  push   %esi
 8048474:   8b 4d 08mov0x8(%ebp),%ecx
 8048477:   53  push   %ebx
 8048478:   8b 5d 0cmov0xc(%ebp),%ebx
 804847b:   39 cb   cmp%ecx,%ebx
 804847d:   74 37   je 80484b6 
 804847f:   8d 73 fclea-0x4(%ebx),%esi
 8048482:   39 f1   cmp%esi,%ecx
 8048484:   74 30   je 80484b6 
 8048486:   8b 43 fcmov-0x4(%ebx),%eax
 8048489:   8b 11   mov(%ecx),%edx
 804848b:   89 01   mov%eax,(%ecx)
 804848d:   83 c1 04add$0x4,%ecx
 8048490:   39 ce   cmp%ecx,%esi
 8048492:   89 53 fcmov%edx,-0x4(%ebx)
 8048495:   74 1f   je 80484b6 
 8048497:   83 eb 08sub$0x8,%ebx
 804849a:   eb 07   jmp80484a3 
 804849c:   8d 74 26 00 lea0x0(%esi,%eiz,1),%esi
 80484a0:   83 eb 04sub$0x4,%ebx
 80484a3:   39 d9   cmp%ebx,%ecx
 80484a5:   74 0f   je 80484b6 
 80484a7:   8b 03   mov(%ebx),%eax
 80484a9:   8b 11   mov(%ecx),%edx
 80484ab:   89 01   mov%eax,(%ecx)
 80484ad:   83 c1 04add$0x4,%ecx
 80484b0:   39 d9   cmp%ebx,%ecx
 80484b2:   89 13   mov%edx,(%ebx)
 80484b4:   75 ea   jne80484a0 
 80484b6:   5b  pop%ebx
 80484b7:   5e  pop%esi
 80484b8:   5d  pop%ebp
 80484b9:   c3  ret
 80484ba:   8d b6 00 00 00 00   lea0x0(%esi),%esi
[...]


-- 


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

[Bug c/40087] Bad assembly for -O2

[markus at cs dot wisc dot edu]

--- Comment #3 from markus at cs dot wisc dot edu  2009-05-10 01:48 ---
Sorry, but there's one last thing.  Here's the output I get with -O1.
  1 2 3 4 5 6 7 8 
  8 7 6 5 4 3 2 1 
and with -O2:
  1 2 3 4 5 6 7 8 
  8 7 6 4 5 3 2 1 


-- 


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

[Bug c++/40085] [4.5 Regression] ICE compiling libmudflap.c++/fail24-frag.cxx

[matz at gcc dot gnu dot org]

--- Comment #3 from matz at gcc dot gnu dot org  2009-05-10 01:54 ---
I haven't analyzed this one, but only because I've found that particular
testcase also failing before expand from SSA, e.g:
  http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg02860.html
  http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg02491.html
The backtrace points to me of course, but probably it just moved
the point of error from whereever it was before to that place.  I don't
know for hppa of course.


-- 


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

[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout

[matz at gcc dot gnu dot org]

--- Comment #13 from matz at gcc dot gnu dot org  2009-05-10 02:09 ---
Created an attachment (id=17843)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17843&action=view)
type-correct version

This is a type-corrected version of the same C testcase.  Two structs are
different types even if they contain the same members, so the casts and
accesses as 'struct a' where the object really was 'struct b' are not valid.
That can be solved by modeling the same as in C++, via proper subobjects of
base-type.

This testcase still exhibits the abort() with -O2 with 4.3.2 on i386 and
x86_64.  It doesn't fail with current trunk, but most probably for the same
coincidence since a-i merge.  I haven't checked 4.4.x.


-- 


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

[Bug fortran/38956] tests gfortran.dg/chmod_{1,2,3}.f90 fails on i686-pc-cygwin

[billingd at gcc dot gnu dot org]

--- Comment #7 from billingd at gcc dot gnu dot org  2009-05-10 03:36 
---
Subject: Bug 38956

Author: billingd
Date: Sun May 10 03:35:53 2009
New Revision: 147327

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147327
Log:
2009-04-10  David Billinghurst 

PR fortran/38956
* gfortran.dg/chmod_1.f90: Don't run on *-*-cygwin*.
* gfortran.dg/chmod_2.f90: Likewise.
* gfortran.dg/chmod_3.f90: Likewise.
* gfortran.dg/open_errors.f90: Likewise.

Modified:
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/chmod_1.f90
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/chmod_2.f90
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/chmod_3.f90
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/open_errors.f90


-- 


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

[Bug fortran/38956] tests gfortran.dg/chmod_{1,2,3}.f90 fails on i686-pc-cygwin

[billingd at gcc dot gnu dot org]

--- Comment #8 from billingd at gcc dot gnu dot org  2009-05-10 03:38 
---
Fixed on trunk and 4.4 branch.


-- 

billingd at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/40088] New: Creating a std::ostringstream object locks a global mutex

[davewx7 at gmail dot com]

When a std::ostringstream object is created, it references a locale object
which is synchronized by a global mutex.

This causes a significant performance problem for multi-threaded applications
running on systems with many CPU's if they use string streams frequently.


-- 
   Summary: Creating a std::ostringstream object locks a global
mutex
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: davewx7 at gmail dot com


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

[Bug target/40068] GCC fails to apply dllexport attribute to typeinfo.

[dannysmith at users dot sourceforge dot net]

--- Comment #4 from dannysmith at users dot sourceforge dot net  2009-05-10 
05:01 ---
(In reply to comment #3)
> Created an attachment (id=17841)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17841&action=view) [edit]
> inherit dllexport from class to typeinfo
> 
> Now testing a solution based on the approach of adding the dllexport attribute
> to the class' typeinfo object when the class is passed to
> i386_pe_adjust_class_at_definition.
> 
Hello Dave,
Rather than use DLL linkage (and so force client to resort to auto-import
magic)
why not just always emit the RTTI with one-only comdat linkage.

* decl2.c (import_export_decl): Always emit RTTI with comdat linkage
rather than import if MULTIPLE_SYMBOL_SPACES.

Index: decl2.c
===
--- decl2.c (revision 147015)
+++ decl2.c (working copy)
@@ -2351,15 +2351,21 @@
{
  class_type = type;
  import_export_class (type);
- if (CLASSTYPE_INTERFACE_KNOWN (type)
- && TYPE_POLYMORPHIC_P (type)
- && CLASSTYPE_INTERFACE_ONLY (type)
- /* If -fno-rtti was specified, then we cannot be sure
-that RTTI information will be emitted with the
-virtual table of the class, so we must emit it
-wherever it is used.  */
- && flag_rtti)
-   import_p = true;
+  /* Do not import typeinfo if the class might be in a DLL.
+Dllimports do not have a constant address at compile time,
+causing problems for static initialization of tables with RTTI
+fields.  Set to comdat instead.   */
+ if (MULTIPLE_SYMBOL_SPACES)
+   comdat_p = true;
+ else if (CLASSTYPE_INTERFACE_KNOWN (type)
+  && TYPE_POLYMORPHIC_P (type)
+  && CLASSTYPE_INTERFACE_ONLY (type)
+  /* If -fno-rtti was specified, then we cannot be sure
+ that RTTI information will be emitted with the
+ virtual table of the class, so we must emit it
+ wherever it is used.  */
+  && flag_rtti)
+import_p = true;
  else
{
  if (CLASSTYPE_INTERFACE_KNOWN (type)


-- 

dannysmith at users dot sourceforge dot net changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |dannysmith at users dot
   |dot org |sourceforge dot net
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-05-10 05:01:24
   date||


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