[Bug c++/37189] OpenMP task construct with implicit firstprivate variables ICEs

2008-09-03 Thread singler at gcc dot gnu dot org


--- Comment #5 from singler at gcc dot gnu dot org  2008-09-03 07:18 ---
To my understanding of the OpenMP standard, a variable not mentioned in the
task pragma is "firstprivate" by default. So stating this fact explicitly
should not change anything, which makes things even stranger.


-- 


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



[Bug rtl-optimization/37296] [4.4 Regression] Bootstrap failure compiling libgcc

2008-09-03 Thread tbm at cyrius dot com


--- Comment #24 from tbm at cyrius dot com  2008-09-03 07:56 ---
(In reply to comment #23)
> ../../../../gcc-4.4-work/libgcc/../gcc/libgcc2.c: In function '__cmpti2':
> ../../../../gcc-4.4-work/libgcc/../gcc/libgcc2.c:1151: internal compiler 
> error:
> in ei_next, at basic-block.h:735

I see the same on arm.


-- 

tbm at cyrius dot com changed:

   What|Removed |Added

 CC||tbm at cyrius dot com


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



[Bug inline-asm/37195] different variables get the same memory address in inline assembly

2008-09-03 Thread jdemeyer at cage dot ugent dot be


--- Comment #4 from jdemeyer at cage dot ugent dot be  2008-09-03 07:57 
---
Created an attachment (id=16200)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16200&action=view)
Testcase for powerpc-unknown-linux-gnu

Also fails on powerpc:
$ gcc -O1 test37195-powerpc.i -save-temps -c -o test37195-powerpc.o
test37195-powerpc.s: Assembler messages:
test37195-powerpc.s:119: Error: ASM 2: %1 and %5 are both equal to 16(1)
test37195-powerpc.s:192: Error: ASM 3: %2 and %5 are both equal to 16(1)

$ gcc -v
Using built-in specs.
Target: powerpc-unknown-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.2.4/work/gcc-4.2.4/configure
--prefix=/usr --bindir=/usr/powerpc-unknown-linux-gnu/gcc-bin/4.2.4
--includedir=/usr/lib/gcc/powerpc-unknown-linux-gnu/4.2.4/include
--datadir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/4.2.4
--mandir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/4.2.4/man
--infodir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/4.2.4/info
--with-gxx-include-dir=/usr/lib/gcc/powerpc-unknown-linux-gnu/4.2.4/include/g++-v4
--host=powerpc-unknown-linux-gnu --build=powerpc-unknown-linux-gnu
--enable-altivec --enable-nls --without-included-gettext --with-system-zlib
--disable-checking --disable-werror --enable-secureplt --disable-multilib
--enable-libmudflap --disable-libssp --disable-libgcj
--enable-languages=c,c++,treelang,fortran --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 4.2.4 (Gentoo 4.2.4 p1.0)


-- 


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



[Bug c++/37189] OpenMP task construct with implicit firstprivate variables ICEs

2008-09-03 Thread jakub at gcc dot gnu dot org


--- Comment #6 from jakub at gcc dot gnu dot org  2008-09-03 08:12 ---
There is nothing strange about it, it is just a bug that needs to be fixed, and
is caused by the design decision that the sharing status of implicitly
determined is computed during the gimplification phase, but synthetization of
method invokes the gimplifier too.  I guess the best fix would be to start
defering all mark_used calls for the duration of finish_function and at the end
of finish_function call all the queued mark_used calls.


-- 


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



gcc-bugs@gcc.gnu.org

2008-09-03 Thread tbm at cyrius dot com
With current SVN (revision 139927):

./g++ -c -B. ~/pasmo-pasmo.ii
pasmo.cpp: In member function 'void (Asm::*::Options::getemit()
const)(std::ostream&)':
pasmo.cpp:90: internal compiler error: same canonical type node for different
types void (Asm::*)(std::ostream&) and void (Asm::* const)(std::ostream&)
Please submit a full bug report,


-- 
   Summary: [4.4 Regression] same canonical type node for different
types void (Asm::*)(std::ostream&) and void (Asm::*
const)(std::ostream&)
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com


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



gcc-bugs@gcc.gnu.org

2008-09-03 Thread tbm at cyrius dot com


--- Comment #1 from tbm at cyrius dot com  2008-09-03 08:17 ---
Created an attachment (id=16201)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16201&action=view)
Preprocessed code


-- 


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



gcc-bugs@gcc.gnu.org

2008-09-03 Thread tbm at cyrius dot com


--- Comment #2 from tbm at cyrius dot com  2008-09-03 08:19 ---
Presumably this one is the same, or do you want preprocessed code (or a
different PR) for this too?

internal compiler error: same canonical type node for different types void
(Atlas::Objects::Dispatcher::* const)(const Atlas::Objects::Root&) and void
(Atlas::Objects::Dispatcher::*)(const Atlas::Objects::Root&)

and one more:

internal compiler error: same canonical type node for different types void
(MSN::Connection::*
const)(std::vector,
std::allocator >,
std::allocator,
std::allocator > > >&,
std::string, std::string) and void
(MSN::Connection::*)(std::vector, std::allocator >,
std::allocator, std::allocator > > >&, std::string, std::string)


-- 


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



[Bug tree-optimization/37343] New: [4.4 Regression] ICE in expand_expr_real_1, at expr.c:7290

2008-09-03 Thread tbm at cyrius dot com
I get the following ICE with current SVN (revision 139927):

(sid)825:[EMAIL PROTECTED]: ..4.3-2008-09-03-r139927/gcc] ./xgcc -c -B. 
~/pilrc-pilrc.i
pilrc.c: In function 'ParseNavigation':
pilrc.c:5537: warning: passing argument 2 of 'ParseNavigationList' from
incompatible pointer type
pilrc.c:5380: note: expected 'int *' but argument is of type 'p_int *'
pilrc.c:5539: warning: passing argument 2 of 'ParseNavigationMap' from
incompatible pointer type
pilrc.c:5415: note: expected 'int *' but argument is of type 'p_int *'
(sid)826:[EMAIL PROTECTED]: ..4.3-2008-09-03-r139927/gcc] ./xgcc -c -B. -O
~/pilrc-pilrc.i
pilrc.c: In function 'ParseNavigation':
pilrc.c:5537: warning: passing argument 2 of 'ParseNavigationList' from
incompatible pointer type
pilrc.c:5380: note: expected 'int *' but argument is of type 'p_int *'
pilrc.c:5539: warning: passing argument 2 of 'ParseNavigationMap' from
incompatible pointer type
pilrc.c:5415: note: expected 'int *' but argument is of type 'p_int *'
pilrc.c: At top level:
pilrc.c:6572: internal compiler error: in expand_expr_real_1, at expr.c:7290
Please submit a full bug report,


-- 
   Summary: [4.4 Regression] ICE in expand_expr_real_1, at
expr.c:7290
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com


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



[Bug tree-optimization/37343] [4.4 Regression] ICE in expand_expr_real_1, at expr.c:7290

2008-09-03 Thread tbm at cyrius dot com


--- Comment #1 from tbm at cyrius dot com  2008-09-03 08:27 ---
Created an attachment (id=16202)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16202&action=view)
Preprocessed code


-- 


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



[Bug target/37344] New: [4.4 Regression] sparc bootstrap fails with Bus error in libgcc2.c

2008-09-03 Thread tbm at cyrius dot com
Bootstrap of current trunk on SPARC/Linux fails with a Bus error when
compiling libgcc2.c

I'm not sure this is related to PR37279 since genattrtab works fine here.

I configure with:
configure --enable-languages=c,c++ --with-cpu=v8 --with-long-double-128
--build=sparc-linux-gnu --host=sparc-linux-gnu --target=sparc-linux-gnu

Error:
/home/tbm/tmp/gcc/4.3-2008-09-03-r139927/./gcc/xgcc
-B/home/tbm/tmp/gcc/4.3-2008-09-03-r139927/./gcc/
-B/usr/local/sparc-linux-gnu/bin/ -B/usr/local/sparc-linux-gnu/lib/ -isystem
/usr/local/sparc-linux-gnu/include -isystem
/usr/local/sparc-linux-gnu/sys-include -g -O2 -O2  -g -O2 -DIN_GCC   -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
-Wold-style-definition  -isystem ./include  -fPIC -g -DHAVE_GTHR_DEFAULT
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED   -I. -I. -I../.././gcc
-I/home/tbm/scratch/gcc/libgcc -I/home/tbm/scratch/gcc/libgcc/.
-I/home/tbm/scratch/gcc/libgcc/../gcc -I/home/tbm/scratch/gcc/libgcc/../include
 -DHAVE_CC_TLS -o _trampoline.o -MT _trampoline.o -MD -MP -MF _trampoline.dep
-DL_trampoline -c /home/tbm/scratch/gcc/libgcc/../gcc/libgcc2.c \
  -fvisibility=hidden -DHIDE_EXPORTS
/home/tbm/scratch/gcc/libgcc/../gcc/libgcc2.c: In function '__lshrdi3':
/home/tbm/scratch/gcc/libgcc/../gcc/libgcc2.c:413: internal compiler error: Bus
error
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [_lshrdi3.o] Error 1
make[3]: *** Waiting for unfinished jobs
/home/tbm/scratch/gcc/libgcc/../gcc/libgcc2.c: In function '__ashrdi3':
/home/tbm/scratch/gcc/libgcc/../gcc/libgcc2.c:469: internal compiler error: Bus
error
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [_ashrdi3.o] Error 1
/home/tbm/scratch/gcc/libgcc/../gcc/libgcc2.c: In function '__ashldi3':
/home/tbm/scratch/gcc/libgcc/../gcc/libgcc2.c:441: internal compiler error: Bus
error
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [_ashldi3.o] Error 1
/home/tbm/scratch/gcc/libgcc/../gcc/libgcc2.c:1183: internal compiler error:
Bus error
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [_ucmpdi2.o] Error 1
/home/tbm/scratch/gcc/libgcc/../gcc/libgcc2.c: In function '__cmpdi2':
/home/tbm/scratch/gcc/libgcc/../gcc/libgcc2.c:1164: internal compiler error:
Bus error
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [_cmpdi2.o] Error 1
make[3]: Leaving directory
`/home/tbm/tmp/gcc/4.3-2008-09-03-r139927/sparc-linux-gnu/libgcc'
make[2]: *** [all-stage2-target-libgcc] Error 2


-- 
   Summary: [4.4 Regression] sparc bootstrap fails with Bus error in
libgcc2.c
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com
 GCC build triplet: sparc-unknown-linux-gnu
  GCC host triplet: sparc-unknown-linux-gnu
GCC target triplet: sparc-unknown-linux-gnu


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



[Bug rtl-optimization/37341] Internal error: Segmentation fault (program cc1)

2008-09-03 Thread rguenth at gcc dot gnu dot org


--- Comment #3 from rguenth at gcc dot gnu dot org  2008-09-03 08:45 ---
It is.

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


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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



[Bug target/37290] [4.4 Regression] Endless recursion in cse_cc_succs

2008-09-03 Thread rguenth at gcc dot gnu dot org


--- Comment #2 from rguenth at gcc dot gnu dot org  2008-09-03 08:45 ---
*** Bug 37341 has been marked as a duplicate of this bug. ***


-- 


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



gcc-bugs@gcc.gnu.org

2008-09-03 Thread rguenth at gcc dot gnu dot org


--- Comment #3 from rguenth at gcc dot gnu dot org  2008-09-03 08:48 ---
Reducing.


-- 


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



[Bug tree-optimization/37345] New: [4.4 Regression] Segfault in decl_function_context (TYPE_MAIN_VARIANT)

2008-09-03 Thread tbm at cyrius dot com
I get the following ICE with current trunk (revision 139927):

(sid)866:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c -O3
mkvtoolnix-output_control.ii
In file included from /usr/include/matroska/KaxBlock.h:44,
 from src/merge/output_control.cpp:50:
/usr/include/matroska/KaxTracks.h: In function 'virtual libebml::EbmlElement*
libmatroska::KaxTracks::Clone()':
/usr/include/matroska/KaxTracks.h:55: internal compiler error: Segmentation
fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
zsh: exit 1 /usr/lib/gcc-snapshot/bin/g++ -c -O3
mkvtoolnix-output_control.ii
(sid)867:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c -O2
mkvtoolnix-output_control.ii
(sid)868:[EMAIL PROTECTED]: ~]


-- 
   Summary: [4.4 Regression] Segfault in decl_function_context
(TYPE_MAIN_VARIANT)
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com


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



[Bug tree-optimization/37345] [4.4 Regression] Segfault in decl_function_context (TYPE_MAIN_VARIANT)

2008-09-03 Thread tbm at cyrius dot com


--- Comment #1 from tbm at cyrius dot com  2008-09-03 08:51 ---
Created an attachment (id=16203)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16203&action=view)
Preprocessed code


-- 


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



[Bug tree-optimization/37345] [4.4 Regression] Segfault in decl_function_context (TYPE_MAIN_VARIANT)

2008-09-03 Thread tbm at cyrius dot com


--- Comment #2 from tbm at cyrius dot com  2008-09-03 08:51 ---
Program received signal SIGSEGV, Segmentation fault.
0x009634e9 in decl_function_context (decl=) at
gcc/tree.c:6676
6676  = TYPE_MAIN_VARIANT
(gdb) where
#0  0x009634e9 in decl_function_context (decl=) at
gcc/tree.c:6676
#1  0x006206cf in df_get_entry_block_def_set
(entry_block_defs=0x1417e10) at gcc/df-scan.c:3415
#2  0x00627708 in df_scan_blocks () at gcc/df-scan.c:637
#3  0x00615ff2 in rest_of_handle_df_initialize () at gcc/df-core.c:746
#4  0x00761bb9 in execute_one_pass (pass=0x10c89a0) at
gcc/passes.c:1278
#5  0x00761df5 in execute_pass_list (pass=0x10c89a0) at
gcc/passes.c:1326
#6  0x00761e0d in execute_pass_list (pass=0x114a600) at
gcc/passes.c:1327
#7  0x008586bc in tree_rest_of_compilation (fndecl=0x7f3fa0a1af00) at
gcc/tree-optimize.c:418
#8  0x009d1760 in cgraph_expand_function (node=0x7f3fa0a28f00) at
gcc/cgraphunit.c:1039
#9  0x009d3524 in cgraph_optimize () at gcc/cgraphunit.c:1101
#10 0x004a36bd in cp_write_global_declarations () at
gcc/cp/decl2.c:3608
#11 0x0080991f in toplev_main (argc=, argv=)
at gcc/toplev.c:979
#12 0x7f3fa26941a6 in __libc_start_main () from /lib/libc.so.6
#13 0x004044d9 in _start ()
(gdb)


-- 


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



[Bug middle-end/37343] [4.4 Regression] ICE in expand_expr_real_1, at expr.c:7290

2008-09-03 Thread rguenth at gcc dot gnu dot org


--- Comment #2 from rguenth at gcc dot gnu dot org  2008-09-03 08:52 ---
We expand a PARM_DECL while cfun is NULL.

#0  fancy_abort (file=0xf24e90 "/space/rguenther/src/svn/trunk/gcc/expr.c", 
line=7290, function=0xf25ab0 "expand_expr_real_1")
at /space/rguenther/src/svn/trunk/gcc/diagnostic.c:699
#1  0x00611d41 in expand_expr_real_1 (exp=0x7f00fcfe7630, target=0x0, 
tmode=DImode, modifier=EXPAND_INITIALIZER, alt_rtl=0x0)
at /space/rguenther/src/svn/trunk/gcc/expr.c:7286
#2  0x00610c8c in expand_expr_real (exp=0x7f00fcfe7630, target=0x0, 
tmode=DImode, modifier=EXPAND_INITIALIZER, alt_rtl=0x0)
at /space/rguenther/src/svn/trunk/gcc/expr.c:7107
#3  0x005fddc5 in expand_expr (exp=0x7f00fcfe7630, target=0x0, 
mode=DImode, modifier=EXPAND_INITIALIZER)
at /space/rguenther/src/svn/trunk/gcc/expr.h:538
#4  0x0060ffe9 in expand_expr_addr_expr_1 (exp=0x7f00fcfe7630, 
target=0x0, tmode=DImode, modifier=EXPAND_INITIALIZER)
at /space/rguenther/src/svn/trunk/gcc/expr.c:6814
#5  0x006104e5 in expand_expr_addr_expr (exp=0x7f00fcebce40, 
target=0x0, tmode=DImode, modifier=EXPAND_INITIALIZER)
at /space/rguenther/src/svn/trunk/gcc/expr.c:6910
#6  0x006262cc in expand_expr_real_1 (exp=0x7f00fcebce40, target=0x0, 
tmode=VOIDmode, modifier=EXPAND_INITIALIZER, alt_rtl=0x0)
at /space/rguenther/src/svn/trunk/gcc/expr.c:9211
#7  0x00610c8c in expand_expr_real (exp=0x7f00fcebce40, target=0x0, 
tmode=VOIDmode, modifier=EXPAND_INITIALIZER, alt_rtl=0x0)
at /space/rguenther/src/svn/trunk/gcc/expr.c:7107
#8  0x00af1dc2 in expand_expr (exp=0x7f00fcebce40, target=0x0, 
mode=VOIDmode, modifier=EXPAND_INITIALIZER)
at /space/rguenther/src/svn/trunk/gcc/expr.h:538
#9  0x00af1720 in output_constant (exp=0x7f00fcebce40, size=8, 
align=256) at /space/rguenther/src/svn/trunk/gcc/varasm.c:4426
#10 0x00af3510 in output_constructor (exp=0x7f00fd15a480, size=72, 
align=256) at /space/rguenther/src/svn/trunk/gcc/varasm.c:4701
#11 0x00af19c6 in output_constant (exp=0x7f00fd15a480, size=72, 
align=256) at /space/rguenther/src/svn/trunk/gcc/varasm.c:4450
#12 0x00ae709c in assemble_variable_contents (decl=0x7f00fcaa28c0, 
name=0x7f00fcb44590 "CSWTCH.376", dont_output_data=0 '\0')
at /space/rguenther/src/svn/trunk/gcc/varasm.c:1988
#13 0x00ae81ca in assemble_variable (decl=0x7f00fcaa28c0, top_level=0, 
at_end=1, dont_output_data=0)
at /space/rguenther/src/svn/trunk/gcc/varasm.c:2191
#14 0x00b8f3c0 in varpool_assemble_decl (node=0x7f00fd07c040)
at /space/rguenther/src/svn/trunk/gcc/varpool.c:355
#15 0x00b8f583 in varpool_assemble_pending_decls ()
at /space/rguenther/src/svn/trunk/gcc/varpool.c:427
#16 0x00b482e6 in cgraph_optimize ()
at /space/rguenther/src/svn/trunk/gcc/cgraphunit.c:1309
#17 0x00430391 in c_write_global_declarations ()


Honza, this one is for you.  Reducing.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu dot
   ||org
  Component|tree-optimization   |middle-end
   Target Milestone|--- |4.4.0


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



[Bug libgomp/37346] New: [4.4 Regression] 101 insns needed body finalized, verify_cgraph_node failed

2008-09-03 Thread tbm at cyrius dot com
I get the following ICE with current trunk (r139927)

(sid)816:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -fopenmp
libgenome-gnFileSource.ii
gnFileSource.cpp:131: error: missing callgraph edge for call stmt:
__builtin_GOMP_critical_end ();

gnFileSource.cpp:131: error: edge genome::gnFileSource::gnFileSource(const
genome::gnFileSource&)->const _CharT* std::basic_string<_CharT, _Traits,
_Alloc>::c_str() const [with _CharT = char, _Traits = std::char_traits,
_Alloc = std::allocator] has no corresponding call_stmt
D.27631 = c_str (D.27630);

genome::gnFileSource::gnFileSource(const genome::gnFileSource&)/308(261): 313
insns needed body finalized
  called by:
...
gnFileSource.cpp:131: internal compiler error: verify_cgraph_node failed
Please submit a full bug report,


-- 
   Summary: [4.4 Regression] 101 insns needed body finalized,
verify_cgraph_node failed
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com


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



gcc-bugs@gcc.gnu.org

2008-09-03 Thread rguenth at gcc dot gnu dot org


--- Comment #4 from rguenth at gcc dot gnu dot org  2008-09-03 09:04 ---
class Asm;
template class basic_ostream;
typedef basic_ostream ostream;
class Options {
typedef void (Asm::* emitfunc_t) (ostream &);
emitfunc_t getemit () const { return emitfunc; }
emitfunc_t emitfunc;
};


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2008-09-03 09:04:48
   date||
   Target Milestone|--- |4.4.0


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



[Bug libgomp/37346] [4.4 Regression] 101 insns needed body finalized, verify_cgraph_node failed

2008-09-03 Thread tbm at cyrius dot com


--- Comment #1 from tbm at cyrius dot com  2008-09-03 09:05 ---
Created an attachment (id=16204)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16204&action=view)
Preprocessed code


-- 


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



[Bug libgomp/37346] [4.4 Regression] 101 insns needed body finalized, verify_cgraph_node failed

2008-09-03 Thread tbm at cyrius dot com


--- Comment #2 from tbm at cyrius dot com  2008-09-03 09:05 ---
/* Testcase by Martin Michlmayr <[EMAIL PROTECTED]> */

template < class _CharT > struct char_traits;
template < typename _CharT, typename _Traits =
  char_traits < _CharT > >class basic_ifstream;
typedef basic_ifstream < char >ifstream;
template < typename _CharT, typename _Traits > class basic_ifstream
{
  public:
void close ()
{
}
};
class gnFileSource
{
  gnFileSource (const gnFileSource & gnfs);
ifstream m_ifstream;
};
gnFileSource::gnFileSource (const gnFileSource & gnfs)
{
#pragma omp critical
  m_ifstream.close ();
}


-- 


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



[Bug middle-end/37343] [4.4 Regression] ICE in expand_expr_real_1, at expr.c:7290

2008-09-03 Thread rguenth at gcc dot gnu dot org


--- Comment #3 from rguenth at gcc dot gnu dot org  2008-09-03 09:17 ---
typedef enum RW { rwBitmapGrey, rwBitmapGrey16 } RW;
void FindDepth(RW);
void ParseDumpBitmap(RW kind, int maxfiles) 
{
static const RW normalTypes[] = { };
const RW *bitmapTypes;
int i;
switch (kind) {
case rwBitmapGrey:
case rwBitmapGrey16:
bitmapTypes = &kind;
break;
default:
bitmapTypes = normalTypes;
}
for (i = 0; i < maxfiles; i++)
FindDepth(bitmapTypes[i]);
}


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-09-03 09:17:30
   date||


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



[Bug tree-optimization/37345] [4.4 Regression] Segfault in decl_function_context (TYPE_MAIN_VARIANT)

2008-09-03 Thread rguenth at gcc dot gnu dot org


--- Comment #3 from rguenth at gcc dot gnu dot org  2008-09-03 09:19 ---
Reducing.


-- 


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



[Bug c++/37189] OpenMP task construct with implicit firstprivate variables ICEs

2008-09-03 Thread 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 |
URL||http://gcc.gnu.org/ml/gcc-
   ||patches/2008-
   ||09/msg00203.html
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-08-25 02:03:16 |2008-09-03 09:20:07
   date||


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



[Bug middle-end/37346] [4.4 Regression] 101 insns needed body finalized, verify_cgraph_node failed

2008-09-03 Thread rguenth at gcc dot gnu dot org


--- Comment #3 from rguenth at gcc dot gnu dot org  2008-09-03 09:21 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|libgomp |middle-end
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
  Known to work||4.3.2
   Last reconfirmed|-00-00 00:00:00 |2008-09-03 09:21:15
   date||
   Target Milestone|--- |4.4.0


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



[Bug c/37267] [4.2/4.3/4.4 Regression] #pragma inside structure initialization causes error

2008-09-03 Thread jakub at gcc dot gnu dot org


--- Comment #2 from jakub at gcc dot gnu dot org  2008-09-03 09:41 ---
Similar to PR25246.


-- 


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



[Bug c/37267] [4.2/4.3/4.4 Regression] #pragma inside structure initialization causes error

2008-09-03 Thread jakub at gcc dot gnu dot org


--- Comment #3 from jakub at gcc dot gnu dot org  2008-09-03 09:47 ---
But I'm not convinced we want to allow pragmas in this context.  While these
pragmas aren't covered by the C standard, for all the covered pragmas in there
they must appear outside of external declarations or explicit declarations and
statements inside a compound statement.  While there was a point in handling
some pragmas inside of structure/union definition, pragmas at this spot don't
serve anything useful and allowing it here would mean
basically we'd need to handle pragmas almost everywhere in the grammar.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rth at gcc dot gnu dot org


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



[Bug inline-asm/31693] Incorrectly assigned registers to operands for ARM inline asm

2008-09-03 Thread siarhei dot siamashka at gmail dot com


--- Comment #5 from siarhei dot siamashka at gmail dot com  2008-09-03 
09:52 ---
I'm sorry, is anybody investigating this quite serious bug? If nobody has
time/motivation to do this work, would it make sense for me to try fixing it
myself and submit a patch here?


-- 


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



[Bug c++/28293] ICE on invalid typedef

2008-09-03 Thread paolo dot carlini at oracle dot com


--- Comment #3 from paolo dot carlini at oracle dot com  2008-09-03 10:01 
---
Patch at:

  http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01070.html


-- 


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



[Bug middle-end/37334] gcc.dg/fastmath-2.c doesn't work

2008-09-03 Thread victork at gcc dot gnu dot org


--- Comment #2 from victork at gcc dot gnu dot org  2008-09-03 10:20 ---
Yes, looks like a problem in testcase. This patch should fix it:

Index: gcc/testsuite/gcc.dg/fastmath-2.c
===
--- gcc/testsuite/gcc.dg/fastmath-2.c   (revision 139888)
+++ gcc/testsuite/gcc.dg/fastmath-2.c   (working copy)
@@ -9,9 +9,10 @@ double b;
 int
 main()
 {
+  double c = (1. / 2.002083e-146);
   b = 1. / a;

-  if (b != (1. / 2.002083e-146))
+  if (memcmp ((void *)&b, (void *)&c, sizeof (double)) != 0)
 abort ();
   return 0;
 }


-- 

victork at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |victork at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-09-03 10:20:55
   date||


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



[Bug middle-end/37275] [4.4 Regression] ICE when compile libgomp/task.c

2008-09-03 Thread linuxl4 at sohu dot com


--- Comment #3 from linuxl4 at sohu dot com  2008-09-03 10:42 ---
[~/tmp]$gcc --version |head -1
gcc (GCC) 4.4.0 20080902 (experimental)

[~/tmp]$gcc -g -O2 -march=i686 -fstack-protector -c task.c -o task.o
/trunk/libgomp/task.c: In function 'GOMP_task':
/trunk/libgomp/task.c:186: internal compiler error: in mem_loc_descriptor, at
dwarf2out.c:10098
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 


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



[Bug tree-optimization/36630] [4.3/4.4 Regression] ICE in vect_update_ivs_after_vectorizer

2008-09-03 Thread irar at il dot ibm dot com


--- Comment #8 from irar at il dot ibm dot com  2008-09-03 10:43 ---
(In reply to comment #7)
> I still think that handling NULL from evolution_part_in_loop_num is the
> correct thing to do.  Even if you need to move this check to the analysis
> phase.
>
> The interesting thing is that the access function during
> vect_analyze_scalar_cycles_1 is
> 
> {2, +, 1}_1
> 
> which is because after the vectorized part of the loop the prologue
> remains which has a non-constant evolution start.


I tried to do the check during the analysis, but it seems impossible, since, as
you wrote, this access function does not exist during the analysis.

> 
> So with the reasoning that you analyzed the access function of the
> original loop properly you can probably strip the conversion that
> confuses you at just vect_update_ivs_after_vectorizer.  

I tested this on the vectorizer tests:

Index: tree-vect-transform.c
===
--- tree-vect-transform.c   (revision 139930)
+++ tree-vect-transform.c   (working copy)
@@ -6529,6 +6529,7 @@ vect_update_ivs_after_vectorizer (loop_v

   access_fn = analyze_scalar_evolution (loop, PHI_RESULT (phi));
   gcc_assert (access_fn);
+  STRIP_NOPS (access_fn);
   evolution_part =
 unshare_expr (evolution_part_in_loop_num (access_fn, loop->num));
   gcc_assert (evolution_part != NULL_TREE);


> (Or store
> the relevant information during analysis where the evolution is
> still simple enough)
> 
> This would fix the ICE, but I wonder if it may cause wrong code because
> of mismatched types somehow. 

At least, this does not happen with the vectorizer testsuite.

Another thing, 4.4 does not vectorize this loop anymore (and, therefore, there
is no ICE), because of unknown number of iterations: 

(analyze_scalar_evolution
  (loop_nb = 1)
  (scalar = i_18)
(get_scalar_evolution
  (scalar = i_18)
  (scalar_evolution = i_18))
(set_scalar_evolution
  (scalar = i_18)
  (scalar_evolution = i_18))
)
  (set_nb_iterations_in_loop = scev_not_known))
(get_loop_exit_condition
  if (y_3(D) > i_13)
)


-- 


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



[Bug c/37331] ICE trying to compile /dev/null

2008-09-03 Thread patriciak784-gccmainling at yahoo dot de


--- Comment #3 from patriciak784-gccmainling at yahoo dot de  2008-09-03 
10:46 ---
(In reply to comment #2)
> Most likely the same issue as PR 37215.
> 

I don't know. This problem is totally strange...
I checked my linux machine and some debian gcc 4.3.1-xx works correctly and
also a self compiled gcc 4.3.1 works on cygwin...
But as said in PR37215 4.3.0 seems to fail...
So if the both problems are identical, it must have been fixed in 4.3.1 and
reopened in 4.3.2 ...

This bug seems to affect at least all x86_64 and i386 targets, I suppose after
reading PR 37215.

And it definitely IS a regression.

Does :1: internal compiler error: Segmentation fault
Please submit a full bug report,...
actually mean that gcc did a segfault or can that mean that cc1 did a
segfault,too because on my machine cc1 does the segfault?
If not, both problems should not be identical...


-- 

patriciak784-gccmainling at yahoo dot de changed:

   What|Removed |Added

   Keywords||ice-on-valid-code


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



[Bug c/37331] ICE trying to compile /dev/null

2008-09-03 Thread paolo dot carlini at oracle dot com


--- Comment #4 from paolo dot carlini at oracle dot com  2008-09-03 11:06 
---
(In reply to comment #3)
> ... a self compiled gcc 4.3.1 ...

Scary ;)


-- 


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



[Bug libstdc++/37347] New: valarray::operator[](slice) const returns wrong type.

2008-09-03 Thread crazydm at gmail dot com
valarray::operator[](slice) const returns _Expr<_SClos<_ValArray,_Tp>, _Tp>
instead of slice_array, this type cannot be casted (with static_cast) to
slice_array.

gcc barfs that
"conversion from ‘std::_Expr, double>’ to
non-scalar type ‘std::slice_array’ requested"

This concerns only const version of the operator[](slice), normal version works
fine. So slice_array objects cannot be created using const valarray objects.

P.S. const_cast can be used as a workaround.

The example program is attached.


-- 
   Summary: valarray::operator[](slice) const returns wrong type.
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: crazydm at gmail dot com
 GCC build triplet: Using built-in specs.
  GCC host triplet: GNU/Linux alioth 2.6.25-ARCH #1 SMP PREEMP
GCC target triplet: i686-pc-linux-gnu


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



[Bug libstdc++/37347] valarray::operator[](slice) const returns wrong type.

2008-09-03 Thread crazydm at gmail dot com


--- Comment #1 from crazydm at gmail dot com  2008-09-03 11:25 ---
Created an attachment (id=16205)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16205&action=view)
The issue demonstration program

this is a code that demostrates the issue. 
g++ slice_test.cpp   -o slice_test


-- 


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



[Bug libstdc++/37347] valarray::operator[](slice) const returns wrong type.

2008-09-03 Thread crazydm at gmail dot com


--- Comment #2 from crazydm at gmail dot com  2008-09-03 11:25 ---
Created an attachment (id=16206)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16206&action=view)
gcc -v -save-temps slice_test.cpp output


-- 


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



[Bug tree-optimization/37345] [4.4 Regression] Segfault in decl_function_context (TYPE_MAIN_VARIANT)

2008-09-03 Thread rguenth at gcc dot gnu dot org


--- Comment #4 from rguenth at gcc dot gnu dot org  2008-09-03 11:26 ---
class EbmlElement {
virtual EbmlElement * Clone() const;
};
class KaxTracks : public EbmlElement {
public:
EbmlElement * Clone() const {
return new KaxTracks(*this);
}
};
KaxTracks kax_tracks;
void finish_file(void)
{
  kax_tracks.Clone();
}

-O3 -fno-ipa-cp works, so - Honza?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ice-on-valid-code
   Last reconfirmed|-00-00 00:00:00 |2008-09-03 11:26:31
   date||
   Target Milestone|--- |4.4.0


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



[Bug libstdc++/37347] valarray::operator[](slice) const returns wrong type.

2008-09-03 Thread crazydm at gmail dot com


--- Comment #3 from crazydm at gmail dot com  2008-09-03 11:27 ---
Created an attachment (id=16207)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16207&action=view)
slice_test.ii file in case you need it.


-- 


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



[Bug libstdc++/37347] valarray::operator[](slice) const returns wrong type.

2008-09-03 Thread paolo dot carlini at oracle dot com


--- Comment #4 from paolo dot carlini at oracle dot com  2008-09-03 11:34 
---
This is not a bug, see 26.3.1/3: "Any function returning a valarray is
permitted to return an object of another type, provided all the const member
functions of valarray are also applicabel to this type". CC-ing Gaby, to be
sure.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||gdr at cs dot tamu dot edu
 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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



[Bug ada/37328] [4.4 Regression] ACATS la14021 ICE in gimple_assign_set_rhs1, at gimple.h:1747

2008-09-03 Thread rguenth at gcc dot gnu dot org


--- Comment #8 from rguenth at gcc dot gnu dot org  2008-09-03 11:35 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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



[Bug ada/37328] [4.4 Regression] ACATS la14021 ICE in gimple_assign_set_rhs1, at gimple.h:1747

2008-09-03 Thread rguenth at gcc dot gnu dot org


--- Comment #9 from rguenth at gcc dot gnu dot org  2008-09-03 11:36 ---
Subject: Bug 37328

Author: rguenth
Date: Wed Sep  3 11:35:18 2008
New Revision: 139931

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139931
Log:
2008-09-03  Richard Guenther  <[EMAIL PROTECTED]>

PR tree-optimization/37328
* tree-sra.c (sra_build_assignment): Gimplify properly.
(generate_copy_inout): Take the correct stmt as definition,
remove bogus assert.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-sra.c


-- 


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



[Bug libstdc++/37347] valarray::operator[](slice) const returns wrong type.

2008-09-03 Thread crazydm at gmail dot com


--- Comment #5 from crazydm at gmail dot com  2008-09-03 11:53 ---
(In reply to comment #4)
> This is not a bug, see 26.3.1/3: "Any function returning a valarray is
> permitted to return an object of another type, provided all the const member
> functions of valarray are also applicabel to this type". CC-ing Gaby, to be
> sure.
> 
Well, but it is not applicabel to helper class slice_array. May be this bug is
not in vallaray, but in slice_array, that must have copy constructor whith a
such type. I do not know, but I think that operator[](slice) const can be used
to create slice_arrays, because it is designated for a such task.


-- 


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



[Bug c++/37348] New: internal compiler error: tree check: expected var_decl, have field_decl in cp_finish_decl, at cp/decl.c:5461

2008-09-03 Thread simon_baldwin at yahoo dot com
The following demonstrates a (minor severity) gcc-4.4-20080829 ICE on error
recovery with invalid code.  No ICE seen in gcc 4.3.1 or prior.

$ cat /tmp/bogus.cc
struct Foo {
  // class Bar;
  template  int f(Bar);
};

$ ./gcc/xgcc --version
xgcc (GCC) 4.4.0 20080829 (experimental)
...

$ ./gcc/xgcc -Bgcc -c -o /dev/null /tmp/bogus.cc
/tmp/bogus.cc:3: error: 'Bar' was not declared in this scope
/tmp/bogus.cc:3: internal compiler error: tree check: expected var_decl, have
field_decl in cp_finish_decl, at cp/decl.c:5461
...


-- 
   Summary: internal compiler error: tree check: expected var_decl,
have field_decl in cp_finish_decl, at cp/decl.c:5461
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: simon_baldwin at yahoo dot com
GCC target triplet: i386-unknown-linux-gnu


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



[Bug libstdc++/37347] valarray::operator[](slice) const returns wrong type.

2008-09-03 Thread paolo dot carlini at oracle dot com


--- Comment #6 from paolo dot carlini at oracle dot com  2008-09-03 12:02 
---
(In reply to comment #5)
> Well, but it is not applicabel to helper class slice_array.

No, no, is totally applicable. And this is a well known design choice, allowed
by the standard on purpose, in this way implementors can optimize the code via
expression template techniques.


-- 


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



[Bug c++/37348] [4.4 Regression] internal compiler error: tree check: expected var_decl, have field_decl in cp_finish_decl, at cp/decl.c:5461

2008-09-03 Thread rguenth at gcc dot gnu dot org


--- Comment #1 from rguenth at gcc dot gnu dot org  2008-09-03 12:06 ---
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||error-recovery, ice-on-
   ||invalid-code
  Known to work||4.3.2
   Last reconfirmed|-00-00 00:00:00 |2008-09-03 12:06:43
   date||
Summary|internal compiler error:|[4.4 Regression] internal
   |tree check: expected|compiler error: tree check:
   |var_decl, have field_decl in|expected var_decl, have
   |cp_finish_decl, at  |field_decl in
   |cp/decl.c:5461  |cp_finish_decl, at
   ||cp/decl.c:5461
   Target Milestone|--- |4.4.0


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



[Bug libstdc++/37347] valarray::operator[](slice) const returns wrong type.

2008-09-03 Thread paolo dot carlini at oracle dot com


--- Comment #7 from paolo dot carlini at oracle dot com  2008-09-03 12:08 
---
Also note: in your original message you have wrong the relevant bit:

> valarray::operator[](slice) const returns _Expr<_SClos<_ValArray,_Tp>, _Tp>
> instead of slice_array, 
 ^^^

The return type, to which 26.3.1/3 applies, is valarray, *not*
slice_array.


-- 


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



[Bug bootstrap/37349] New: [4.4 Regression] bootstrap broken on Alpha: Link tests are not allowed after GCC_NO_EXECUTABLES.

2008-09-03 Thread tbm at cyrius dot com
I get the following bootstrap error on Alpha:

checking for uintptr_t... yes
checking for a 64-bit type... uint64_t
checking for pid_t... yes
checking for library containing strerror... configure: error: Link tests are
not allowed after GCC_NO_EXECUTABLES.
make[2]: *** [configure-stage2-libiberty] Error 1
make[2]: Leaving directory `/home/tbm/tmp/gcc/4.3-2008-09-03-r139931'

I configured with
.../gcc/configure --enable-languages=c,c++ --with-long-double-128
--build=alpha-linux-gnu --host=alpha-linux-gnu --target=alpha-linux-gnu


-- 
   Summary: [4.4 Regression] bootstrap broken on Alpha: Link tests
are not allowed after GCC_NO_EXECUTABLES.
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com
 GCC build triplet: alpha-linux-gnu
  GCC host triplet: alpha-linux-gnu
GCC target triplet: alpha-linux-gnu


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



[Bug bootstrap/37349] [4.4 Regression] bootstrap broken on Alpha: Link tests are not allowed after GCC_NO_EXECUTABLES.

2008-09-03 Thread tbm at cyrius dot com


--- Comment #1 from tbm at cyrius dot com  2008-09-03 12:20 ---
I forgot to mention that this is with current SVN.


-- 


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



[Bug c/37331] ICE trying to compile /dev/null

2008-09-03 Thread patriciak784-gccmainling at yahoo dot de


--- Comment #5 from patriciak784-gccmainling at yahoo dot de  2008-09-03 
12:21 ---
(In reply to comment #4)
> (In reply to comment #3)
> > ... a self compiled gcc 4.3.1 ...
> 
> Scary ;)
> 
What did you expect, Paolo?

Well, I just compiled gcc-4_3-branch @ rev 137894 and the resulting gcc fails
to
do both "gcc -x c /dev/null" and "gcc -E -dM -fpreprocessed - < /dev/null"!
And my 4.3.2 fails also to do "gcc -E -dM -fpreprocessed - < /dev/null".
Error messages are identical to the ones in previous descriptions.

Can anybody please confirm that bug? (linux/x86_32 and linux/x86_64 systems
should fail, too, not only mingw32 running on msys and probably even more
systems...)


-- 


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



[Bug middle-end/37346] [4.4 Regression] 101 insns needed body finalized, verify_cgraph_node failed

2008-09-03 Thread jakub at gcc dot gnu dot org


--- Comment #4 from jakub at gcc dot gnu dot org  2008-09-03 12:24 ---
Testing a fix.


-- 

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|NEW |ASSIGNED
   Last reconfirmed|2008-09-03 09:21:15 |2008-09-03 12:24:24
   date||


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



[Bug libstdc++/37347] valarray::operator[](slice) const returns wrong type.

2008-09-03 Thread crazydm at gmail dot com


--- Comment #8 from crazydm at gmail dot com  2008-09-03 12:25 ---
(In reply to comment #7)
> Also note: in your original message you have wrong the relevant bit:
> 
> > valarray::operator[](slice) const returns _Expr<_SClos<_ValArray,_Tp>, _Tp>
> > instead of slice_array, 
>  ^^^
> 
> The return type, to which 26.3.1/3 applies, is valarray, *not*
> slice_array.
> 
Thanks a lot, it seems that my documentation is rather old. And I was also
decepted with non const operator, that returns slice_array, not valarray. 

P.S. With valarray everything works fine.


-- 


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



[Bug fortran/37193] [4.3/4.4 Regression] "USE mod, ONLY: i, i=>j" does not import "i"

2008-09-03 Thread domob at gcc dot gnu dot org


--- Comment #2 from domob at gcc dot gnu dot org  2008-09-03 12:27 ---
Subject: Bug 37193

Author: domob
Date: Wed Sep  3 12:25:57 2008
New Revision: 139936

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139936
Log:
2008-08-30  Daniel Kraft  <[EMAIL PROTECTED]>

PR fortran/37193
* module.c (read_module): Initialize use_only flag on used symbols.

2008-08-30  Daniel Kraft  <[EMAIL PROTECTED]>

PR fortran/37193
* gfortran.dg/use_rename_4.f90: New test.
* gfortran.dg/use_rename_5.f90: New test.

2008-06-24  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/36371
* gfortran.dg/data_array_5.f90: New test.

2008-06-24  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/36371
* expr.c (gfc_check_assign):  Change message and locus for
error when conform == 0.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/data_array_5.f90
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/use_rename_4.f90
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/use_rename_5.f90
Modified:
branches/gcc-4_3-branch/gcc/fortran/ChangeLog
branches/gcc-4_3-branch/gcc/fortran/expr.c
branches/gcc-4_3-branch/gcc/fortran/module.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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



[Bug fortran/36371] [4.3 Regression] Wrong locus for errors in DATA statement

2008-09-03 Thread domob at gcc dot gnu dot org


--- Comment #3 from domob at gcc dot gnu dot org  2008-09-03 12:27 ---
Subject: Bug 36371

Author: domob
Date: Wed Sep  3 12:25:57 2008
New Revision: 139936

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139936
Log:
2008-08-30  Daniel Kraft  <[EMAIL PROTECTED]>

PR fortran/37193
* module.c (read_module): Initialize use_only flag on used symbols.

2008-08-30  Daniel Kraft  <[EMAIL PROTECTED]>

PR fortran/37193
* gfortran.dg/use_rename_4.f90: New test.
* gfortran.dg/use_rename_5.f90: New test.

2008-06-24  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/36371
* gfortran.dg/data_array_5.f90: New test.

2008-06-24  Paul Thomas  <[EMAIL PROTECTED]>

PR fortran/36371
* expr.c (gfc_check_assign):  Change message and locus for
error when conform == 0.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/data_array_5.f90
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/use_rename_4.f90
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/use_rename_5.f90
Modified:
branches/gcc-4_3-branch/gcc/fortran/ChangeLog
branches/gcc-4_3-branch/gcc/fortran/expr.c
branches/gcc-4_3-branch/gcc/fortran/module.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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



[Bug fortran/37193] [4.3/4.4 Regression] "USE mod, ONLY: i, i=>j" does not import "i"

2008-09-03 Thread domob at gcc dot gnu dot org


--- Comment #3 from domob at gcc dot gnu dot org  2008-09-03 12:28 ---
Fixed on 4.4 and 4.3.


-- 

domob at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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



[Bug c++/37348] [4.4 Regression] internal compiler error: tree check: expected var_decl, have field_decl in cp_finish_decl, at cp/decl.c:5461

2008-09-03 Thread jakub at gcc dot gnu dot org


--- Comment #2 from jakub at gcc dot gnu dot org  2008-09-03 12:51 ---
That's clearly not a regression, at least not a recent one (tried 4.1 as well).
The thing is just that you get ICE only with checking enabled.


-- 

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|NEW |ASSIGNED
   Last reconfirmed|2008-09-03 12:06:43 |2008-09-03 12:51:09
   date||


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



[Bug bootstrap/37349] [4.4 Regression] bootstrap broken on Alpha: Link tests are not allowed after GCC_NO_EXECUTABLES.

2008-09-03 Thread tbm at cyrius dot com


--- Comment #2 from tbm at cyrius dot com  2008-09-03 12:55 ---
Also fails with:

configure --enable-languages=c,c++  --build=alpha-linux-gnu
--host=alpha-linux-gnu --target=alpha-linux-gnu


-- 


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



[Bug bootstrap/37349] [4.4 Regression] bootstrap broken on Alpha: undefined reference to _Jv_RegisterClasses

2008-09-03 Thread tbm at cyrius dot com


--- Comment #3 from tbm at cyrius dot com  2008-09-03 13:05 ---
Sorry, I used make -j2 and only looked at the error at the end... but I just
realized there's another error earlier on and that's the real problem.

checking for alpha-linux-gnu-gcc... 
/home/tbm/tmp/gcc/3/4.3-2008-09-03-r139931/./prev-gcc/xgcc
-B/home/tbm/tmp/gcc/3/4.3-2008-09-03-r139931/./prev-gcc/
-B/usr/local/alpha-linux-gnu/bin/
checking for C compiler default output file name... configure: error: in
`/home/tbm/tmp/gcc/3/4.3-2008-09-03-r139931/intl':
configure: error: C compiler cannot create executables
See `config.log' for more details.
make[2]: *** [configure-stage2-intl] Error 77

The log says:

configure:2147: checking for C compiler default output file name
configure:2150:  /home/tbm/tmp/gcc/3/4.3-2008-09-03-r139931/./prev-gcc/xgcc
-B/home/tbm/tmp/gcc/3/4.3-2008-09-03-r139931/./prev-gcc/
-B/usr/local/alpha-linux-gnu/bin/ -g -O2   conftest.c  >&5
/home/tbm/tmp/gcc/3/4.3-2008-09-03-r139931/./prev-gcc/crtbegin.o: In function
`frame_dummy': (.text+0xec): undefined reference to `_Jv_RegisterClasses'
/tmp/ccWuMF2Y.o:(.debug_info+0x49): undefined reference to `$LSFDE0'
collect2: ld returned 1 exit status
configure:2153: $? = 1
configure: failed program was:
| /* confdefs.h.  */
|
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:2191: error: in `/home/tbm/tmp/gcc/3/4.3-2008-09-03-r139931/intl':
configure:2194: error: C compiler cannot create executables


-- 

tbm at cyrius dot com changed:

   What|Removed |Added

Summary|[4.4 Regression] bootstrap  |[4.4 Regression] bootstrap
   |broken on Alpha: Link tests |broken on Alpha: undefined
   |are not allowed after   |reference to
   |GCC_NO_EXECUTABLES. |_Jv_RegisterClasses


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



[Bug bootstrap/37122] fixed-value.c and tree-ssa-loop-ivopts.c won't compile with Sun Studio 11 on Solaris 9 due to incompatible operand types

2008-09-03 Thread davediff at nbcs dot rutgers dot edu


--- Comment #4 from davediff at nbcs dot rutgers dot edu  2008-09-03 13:28 
---
Yes, your right it is a bug in Sun's Compiler. For those interested it is bug
ID: 6406892. The sun patch that fixes this bug is 121015-06 available here:
http://sunsolve.sun.com/show.do?target=patchpage


-- 

davediff at nbcs dot rutgers dot edu changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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



[Bug debug/37322] [4.4 Regression] FAIL: gfortran.dg/debug/pr35154-dwarf2.f

2008-09-03 Thread dominiq at lps dot ens dot fr


--- Comment #3 from dominiq at lps dot ens dot fr  2008-09-03 13:50 ---
> ... then it is likely that the test pass.

Indeed it does, though I only tested a partial patch.


-- 


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



[Bug bootstrap/37330] mpfr & 32/64 multilib issue

2008-09-03 Thread olivier dot raoult at st dot com


--- Comment #4 from olivier dot raoult at st dot com  2008-09-03 14:04 
---
Verstehen! Thanks!


-- 

olivier dot raoult at st dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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



[Bug c++/37350] New: Specialized template base class name not accepted

2008-09-03 Thread ian at airs dot com
C++98 [temp.local] says "Within the scope of a class template specialization or
partial specialization, when the name of the template is neither qualified nor
followed by <, it is equivalent to the name of the template followed by the
template-arguments enclosed in <>."  That does not work when a template
specialization is used as a base class.  In that case g++ does not accept the
unqualified base class name as a type.

This test case:

template 
struct base {};

struct derived : base {
  typedef base b;
  base* p;
};

gives these errors:

foo.cc:5: error: invalid use of template-name ‘base’ without an argument list
foo.cc:6: error: ISO C++ forbids declaration of ‘base’ with no type
foo.cc:6: error: expected ‘;’ before ‘*’ token

I believe this is an incorrect rejection of valid C++ code.  At least, I can't
find anything in the C++ standard which says that this code is invalid.


-- 
   Summary: Specialized template base class name not accepted
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com


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



[Bug middle-end/37343] [4.4 Regression] ICE in expand_expr_real_1, at expr.c:7290

2008-09-03 Thread hubicka at ucw dot cz


--- Comment #4 from hubicka at ucw dot cz  2008-09-03 14:30 ---
Subject: Re:  [4.4 Regression] ICE in expand_expr_real_1, at expr.c:7290

Hi,
this is switch conversion bug.  It attempts to convert the switch and
construct static array with &function_parameter in initializer that
naturally is wrong.

I am testing the following fix:

Index: tree-switch-conversion.c
===
--- tree-switch-conversion.c(revision 139938)
+++ tree-switch-conversion.c(working copy)
@@ -298,7 +298,7 @@ check_final_bb (void)

  if ((bb == info.switch_bb
   || (single_pred_p (bb) && single_pred (bb) == info.switch_bb))
- && !is_gimple_min_invariant (gimple_phi_arg_def (phi, i)))
+ && !is_gimple_ip_invariant (gimple_phi_arg_def (phi, i)))
{
  info.reason = "   Non-invariant value from a case\n";
  return false; /* Non-invariant argument.  */


-- 


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



[Bug libstdc++/37351] New: std::result_of requires nested template

2008-09-03 Thread jwakely dot gcc at gmail dot com
The specification of std::result_of is simpler than std::tr1::result_of, there
is no mention of a nested typename F::template result::type
in the C++0x WP.

The libstdc++ implementation in tr1_impl follows the TR1 spec and so fails on
code like this:

#include 

struct F {
int operator()(int i) { return i+1; }
};

std::result_of::type i = 0;

std::result_of should use something like __typeof__ instead.


-- 
   Summary: std::result_of requires nested template
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jwakely dot gcc at gmail dot com


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



[Bug c++/37350] Specialized template base class name not accepted

2008-09-03 Thread rguenth at gcc dot gnu dot org


--- Comment #1 from rguenth at gcc dot gnu dot org  2008-09-03 14:50 ---
I don't read from the sentence that this applies to base class names, it
says "the name of the template" only.


-- 


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



[Bug c++/37350] Specialized template base class name not accepted

2008-09-03 Thread rguenth at gcc dot gnu dot org


--- Comment #2 from rguenth at gcc dot gnu dot org  2008-09-03 14:51 ---
EDG rejects it with

t.C(5): error: argument list for class template "base" is missing
typedef base b;
^

but accepts it if you use derived instead of base (like gcc does).


-- 


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



[Bug libstdc++/37351] std::result_of requires nested template

2008-09-03 Thread paolo dot carlini at oracle dot com


--- Comment #1 from paolo dot carlini at oracle dot com  2008-09-03 14:57 
---
Jonathan, I'm sure you are right, but we don't keep track of all the individual
differences between TR1 stuff and C++0x stuff! There are literally thousands of
them! If you want to quickly hack a patch for this one, you are of course
welcome, but really this is not the way we are managing the implementation of
C++0x things... Maybe shared_ptr first, though ;)


-- 


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



[Bug libstdc++/37351] std::result_of requires nested template

2008-09-03 Thread paolo dot carlini at oracle dot com


--- Comment #2 from paolo dot carlini at oracle dot com  2008-09-03 14:59 
---
Well, of course that would be decltype, not __typeof__.


-- 


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



[Bug libstdc++/36962] [C++0x] Add constructors / assignment operators from unique_ptr to shared_ptr

2008-09-03 Thread jwakely dot gcc at gmail dot com


--- Comment #9 from jwakely dot gcc at gmail dot com  2008-09-03 15:00 
---
I have another patch ready for this, but it doesn't work with unique_ptr
where D is a reference type, due to Bug 37351 

e.g. constructing from unique_ptr&> fails to compile
because std::reference_wrapper>::operator()(T*) cannot
be instantiated.

I can submit the patch anyway with an XFAIL testcase until std::result_of is
fixed.


-- 


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



[Bug libstdc++/37351] std::result_of requires nested template

2008-09-03 Thread jwakely dot gcc at gmail dot com


--- Comment #3 from jwakely dot gcc at gmail dot com  2008-09-03 15:04 
---
Agreed, the reason I reported this is that it causes problems with my work on
Bug 36962 because std::reference_wrapper uses result_of


-- 


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



[Bug libstdc++/36962] [C++0x] Add constructors / assignment operators from unique_ptr to shared_ptr

2008-09-03 Thread paolo dot carlini at oracle dot com


--- Comment #10 from paolo dot carlini at oracle dot com  2008-09-03 15:04 
---
Sure, no problem. Let's just do the split and implement as much as the
unique_ptr changes as possible. If then updating result_of for C++0x is enough,
everything is perfectly fine.


-- 


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



[Bug libstdc++/37351] [c++0x] std::result_of requires nested template

2008-09-03 Thread paolo dot carlini at oracle dot com


--- Comment #4 from paolo dot carlini at oracle dot com  2008-09-03 15:05 
---
Ok...


-- 


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



[Bug libstdc++/36962] [C++0x] Add constructors / assignment operators from unique_ptr to shared_ptr

2008-09-03 Thread jwakely dot gcc at gmail dot com


--- Comment #11 from jwakely dot gcc at gmail dot com  2008-09-03 15:08 
---
Yes, the problem is with result_of, not my changes to shared_ptr.  It will work
with unique_ptr if a type D::result_type exists, so I'll submit the new
patch tonight.


-- 


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



[Bug rtl-optimization/37296] [4.4 Regression] Bootstrap failure compiling libgcc

2008-09-03 Thread vmakarov at redhat dot com


--- Comment #25 from vmakarov at redhat dot com  2008-09-03 15:36 ---
   The problem is in sorting insn chains according to their
 frequencies to get a better reloads for most frequently executed
 insns.  This very simple optimization was introduced on IRA branch.
 Correct updating elimination offsets in reload needs original insn
 chain order.  I see two solutions of the problem:

o Restore evaluation of elimination offsets by using original order of
  insn chains.  It means move of sorting insn chains to function
  calculate_needs_all_insns and process offsets there before sorting.
  It also needs to save elimination offsets not only at code labels
  (as it now) but at any BB end start.  So it complicates
  significantly this very simple optimization and makes it even slower
  because we need sort insn chain on each reload iteration (not once
  as it now).

o Just remove sorting of insn chain.  I've checked the optimization
  impact on SPEC2000 for x86 and found it is not significant (about
  0.1% improvement on SPECINT2000 which is in measurement error range
  and 0.02% codes size decrease on SPECFP2000).  It should speed up
  the compiler although in reality I did not find a visible speedup.

After some thinking, I've decided to stic to the 2nd solution.

The patch solving the problem will follow soon.


-- 


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



Olha isso ai, ver o q vc acha..

2008-09-03 Thread m-silva-teixeira
===
olha ai. depois me fala ok.
http://veja-capa-album-video.sytes.net


Aquele que não luta pelo que quer, não merece o que deseja.


===




[Bug middle-end/37243] [4.4 Regression] IRA causes wrong code generation

2008-09-03 Thread hjl dot tools at gmail dot com


--- Comment #22 from hjl dot tools at gmail dot com  2008-09-03 16:05 
---
(In reply to comment #7)
> Created an attachment (id=16155)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16155&action=view) [edit]
> Test case from 2006.434.zeusmp
> 
> Though fail to extract a smaller case, hopeful it helpful.
> 
> Compile with gfortran -c -O2 -DSPEC_CPU_LP64 tranx1.f -S -fdump-rtl-all -g.
> Miscompile in revision 139590.
> 
> In IRA dump file, I believe following suspicious RTL is the cause of segfault:
> (insn 886 885 893 35 tranx1.f:570 (set (reg:DI 0 ax [orig:123 D.3215 ] [123])
> (mem/c:DI (plus:DI (reg/f:DI 7 sp)
> (const_int -104 [0xff98])) [68 D.3215+0 S8 A64]))
> 89 {*movdi_1_rex64} (nil))
> 
> (insn 893 886 896 35 tranx1.f:570 (set (mem/c:DI (plus:DI (reg/f:DI 7 sp)
> (const_int -104 [0xff98])) [68 ivtmp.160+0 S8 
> A64])
> (reg/f:DI 3 bx [orig:159 ivtmp.160 ] [159])) 89 {*movdi_1_rex64} 
> (nil))
> D.3215 and ivtmp.160 shares the spill space (%rsp-104), where as D.3215 and
> ivtmp.160 has overlapped liverange.
> 

It is fixed by Richard's use DF patch:

http://gcc.gnu.org/ml/gcc/2008-09/msg00015.html


-- 


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



[Bug c++/37352] New: thunks for virtual function should work on lto

2008-09-03 Thread espindola at google dot com
>From http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00349.html:

   Currently the thunks for a function are 
   emitted from the frontend, exactly when the function itself is emitted
   (as RTL).  The frontend does some analysis of thunks beforehand 
   already, but I simply deactivated emission of thunks for my experiment.
   This needs to be done before IPA, either by making thunks a middle-end
   concept, or implementing alternate entry points for real

Maybe it is possible to generate thunks eagerly as a first solution?


-- 
   Summary: thunks for virtual function should work on lto
   Product: gcc
   Version: lto
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: espindola at google dot com
 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=37352



[Bug tree-optimization/37353] New: [4.4 Regression] ICE: vector VEC(gimple,base) push domain error, in tree_call_cdce at tree-call-cdce.c:890

2008-09-03 Thread tbm at cyrius dot com
With trunk:

(sid)988:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -O2 
qucs-hic2_full.core.ii
hic2_full.core.cpp: In member function 'void hic2_full::calcVerilog()':
hic2_full.core.cpp:345: internal compiler error: vector VEC(gimple,base) push
domain error, in tree_call_cdce at tree-call-cdce.c:890
Please submit a full bug report,
with preprocessed source if appropriate.

Works fine at -O


-- 
   Summary: [4.4 Regression] ICE: vector VEC(gimple,base) push
domain error, in tree_call_cdce at tree-call-cdce.c:890
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com


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



[Bug tree-optimization/37353] [4.4 Regression] ICE: vector VEC(gimple,base) push domain error, in tree_call_cdce at tree-call-cdce.c:890

2008-09-03 Thread tbm at cyrius dot com


--- Comment #1 from tbm at cyrius dot com  2008-09-03 16:30 ---
Created an attachment (id=16208)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16208&action=view)
Preprocessed code


-- 


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



[Bug tree-optimization/37354] New: [4.4 Regression] ICE: in find_func_aliases, at tree-ssa-structalias.c:3906

2008-09-03 Thread tbm at cyrius dot com
With current trunk:
(sid)995:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -O 
traverso-AlsaDriver.ii
In file included from ../common/defines.h:8,
 from Driver.h:27,
 from AlsaDriver.h:30,
 from AlsaDriver.cpp:28:
../common/FastDelegate.h: In function 'fastdelegate::FastDelegate1 fastdelegate::MakeDelegate(Y*, RetType (X::*)(Param1)) [with X =
AlsaDriver, Y = AlsaDriver, Param1 = nframes_t, RetType = int]':
../common/FastDelegate.h:2015: internal compiler error: in find_func_aliases,
at tree-ssa-structalias.c:3906
Please submit a full bug report,
with preprocessed source if appropriate.


-- 
   Summary: [4.4 Regression] ICE: in find_func_aliases, at tree-ssa-
structalias.c:3906
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com


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



[Bug tree-optimization/37354] [4.4 Regression] ICE: in find_func_aliases, at tree-ssa-structalias.c:3906

2008-09-03 Thread tbm at cyrius dot com


--- Comment #1 from tbm at cyrius dot com  2008-09-03 16:34 ---
Created an attachment (id=16209)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16209&action=view)
Preprocessed code


-- 


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



[Bug fortran/37355] New: Request runtime preconnected buffer option for gfortran

2008-09-03 Thread MMcVeigh at att dot net
When FORTRAN code is combined with C, there can be instances of
non-chronological output for STDOUT and STDERR.  Setting the environment
variable GFORTRAN_PRECONNECTED_UNBUFFERED is effective, but is not helpful for
uncontrolled customer shell environments.  I would like a method to override
the default buffering at runtime.  One method is to provide a libfortran
globally accessible function to change the libfortran.h values of

_gfortrani_options.all_unbuffered = 1 and
_gfortrani_options.unbuffered_preconnected = 1

Thank You,
Mark McVeigh


-- 
   Summary: Request runtime preconnected buffer option for gfortran
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: MMcVeigh at att dot net


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



[Bug middle-end/37356] New: [4.4 Regression] ICE in gsi_insert_seq_nodes_after, at gimple-iterator.c:222

2008-09-03 Thread tbm at cyrius dot com
With trunk from today.  I only see this on powerpc, not on x86_64.

(sid)2447:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c -O1 
pokerth-game.cc
pokerth-game.cc: In constructor 'boost::date_time::base_time::base_time(const typename time_system::date_type&, const typename
time_system::time_duration_type&, boost::date_time::dst_flags) [with T =
boost::posix_time::ptime, time_system =
boost::date_time::counted_time_system
>]':
pokerth-game.cc:352: internal compiler error: in gsi_insert_seq_nodes_after, at
gimple-iterator.c:222
Please submit a full bug report,
with preprocessed source if appropriate.
zsh: exit 1 /usr/lib/gcc-snapshot/bin/g++ -c -O1 pokerth-game.cc
(sid)2448:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c pokerth-game.cc
(sid)2449:[EMAIL PROTECTED]: ~]


-- 
   Summary: [4.4 Regression] ICE in gsi_insert_seq_nodes_after, at
gimple-iterator.c:222
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com


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



[Bug middle-end/37356] [4.4 Regression] ICE in gsi_insert_seq_nodes_after, at gimple-iterator.c:222

2008-09-03 Thread tbm at cyrius dot com


--- Comment #1 from tbm at cyrius dot com  2008-09-03 17:23 ---
Created an attachment (id=16210)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16210&action=view)
Preprocessed code


-- 


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



[Bug middle-end/37356] [4.4 Regression] ICE in gsi_insert_seq_nodes_after, at gimple-iterator.c:222

2008-09-03 Thread tbm at cyrius dot com


--- Comment #2 from tbm at cyrius dot com  2008-09-03 17:24 ---
Created an attachment (id=16211)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16211&action=view)
Slightly reduced testcase


-- 


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



[Bug middle-end/37346] [4.4 Regression] 101 insns needed body finalized, verify_cgraph_node failed

2008-09-03 Thread jakub at gcc dot gnu dot org


--- Comment #5 from jakub at gcc dot gnu dot org  2008-09-03 17:26 ---
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139937


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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



[Bug middle-end/37357] New: [4.4 Regression] Revision 139772 breaks C++

2008-09-03 Thread hjl dot tools at gmail dot com
With revision 139772, gcc no longer generates some functions.


-- 
   Summary: [4.4 Regression] Revision 139772 breaks C++
   Product: gcc
   Version: 4.4.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=37357



[Bug middle-end/37346] [4.4 Regression] 101 insns needed body finalized, verify_cgraph_node failed

2008-09-03 Thread jakub at gcc dot gnu dot org


--- Comment #6 from jakub at gcc dot gnu dot org  2008-09-03 17:31 ---
Subject: Bug 37346

Author: jakub
Date: Wed Sep  3 17:30:35 2008
New Revision: 139941

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139941
Log:
Fix up PR number - PR c++/37346

Added:
trunk/gcc/testsuite/g++.dg/gomp/pr37346.C
  - copied, changed from r139940, trunk/gcc/testsuite/g++.dg/gomp/pr37436.C
Removed:
trunk/gcc/testsuite/g++.dg/gomp/pr37436.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog


-- 


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



[Bug middle-end/37357] [4.4 Regression] Revision 139772 breaks C++

2008-09-03 Thread hjl dot tools at gmail dot com


--- Comment #1 from hjl dot tools at gmail dot com  2008-09-03 17:32 ---
Created an attachment (id=16212)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16212&action=view)
A testcase

[EMAIL PROTECTED] 874]$ make
../139771/usr/bin/gcc -S -O2 case.cc -o old.s
../139772/usr/bin/gcc -S -O2 case.cc -o new.s
grep -q  EPKNS_10DOMElementEPKtiS5_S5_S5_S5_ old.s
grep -q  EPKNS_10DOMElementEPKtiS5_S5_S5_S5_ new.s
make: *** [all] Error 1
[EMAIL PROTECTED] 874]$ 

We no longer emit

xercesc_2_5::TraverseSchema::reportSchemaError(xercesc_2_5::DOMElement const*,
unsigned short const*, int, unsigned short const*, unsigned short const*,
unsigned short const*, unsigned short const*)


-- 


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



[Bug tree-optimization/37354] [4.4 Regression] ICE: in find_func_aliases, at tree-ssa-structalias.c:3906

2008-09-03 Thread tbm at cyrius dot com


--- Comment #2 from tbm at cyrius dot com  2008-09-03 17:34 ---
Created an attachment (id=16213)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16213&action=view)
Slightly reduced testcase


-- 


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



[Bug middle-end/37357] [4.4 Regression] IPA-CP breaks C++

2008-09-03 Thread hjl dot tools at gmail dot com


--- Comment #2 from hjl dot tools at gmail dot com  2008-09-03 18:02 ---
Revision 139762 also fails with -O3:

../139761/usr/bin/gcc -S -O3 case.cc -o old.s
../139762/usr/bin/gcc -S -O3 case.cc -o new.s
grep -q  EPKNS_10DOMElementEPKtiS5_S5_S5_S5_ old.s
grep -q  EPKNS_10DOMElementEPKtiS5_S5_S5_S5_ new.s
make: *** [all] Error 1
[EMAIL PROTECTED] 874]$ 


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

Summary|[4.4 Regression] IPA-CP is  |[4.4 Regression] IPA-CP
   |broken for some C++ code|breaks C++


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



[Bug middle-end/37357] [4.4 Regression] IPA-CP is broken for some C++ code

2008-09-03 Thread 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
Summary|[4.4 Regression] IPA-CP |[4.4 Regression] IPA-CP is
   |breaks C++  |broken for some C++ code
   Target Milestone|--- |4.4.0


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



[Bug fortran/37355] Request runtime preconnected buffer option for gfortran

2008-09-03 Thread kargl at gcc dot gnu dot org


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Priority|P3  |P5


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



[Bug tree-optimization/37315] [4.4 Regression]: gcc.c-torture/execute/931018-1.c int-compare.c ieee/inf-2.c mzero6.c

2008-09-03 Thread hubicka at gcc dot gnu dot org


--- Comment #8 from hubicka at gcc dot gnu dot org  2008-09-03 18:17 ---
Subject: Bug 37315

Author: hubicka
Date: Wed Sep  3 18:16:26 2008
New Revision: 139945

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

PR tree-optimization/37315
* cgraph.c (cgraph_create_edge): Use gimple_has_body_p.
* cgraphunit.c (verify_cgraph_node): drop gimple_body check.
(cgraph_analyze_functions): Use node->analyzed
(cgraph_mark_functions_to_output): Likewise.
(cgraph_expand_function): All functions can be released after
expanding.
(cgraph_optimize): Use gimple_has_body_p.
* ipa-inline.c (cgraph_clone_inlined_nodes): Use analyzed flag.
(cgraph_decide_inlining_incrementally): Likewise.
(inline_transform): Inline transform.
* tree-inline.c (initialize_cfun): Do now shallow copy structure;
copy fields needed.
(inlinable_function_p): Drop gimple_body check.
(expand_call_inline): Use gimple_has_body_p.
* gimple.c (gimple_has_body_p): New.
* gimple.h (gimple_has_body_p): Add prototype.
* tree-cfg.c (execute_build_cfg): Remove gimple_body.
(dump_function_to_file): Use gimple_has_body_p check.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraph.c
trunk/gcc/cgraphunit.c
trunk/gcc/gimple.c
trunk/gcc/gimple.h
trunk/gcc/ipa-inline.c
trunk/gcc/tree-cfg.c
trunk/gcc/tree-inline.c


-- 


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



[Bug middle-end/37356] [4.4 Regression] ICE in gsi_insert_seq_nodes_after, at gimple-iterator.c:222

2008-09-03 Thread 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
   Target Milestone|--- |4.4.0


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



[Bug tree-optimization/37345] [4.4 Regression] Segfault in decl_function_context (TYPE_MAIN_VARIANT)

2008-09-03 Thread hubicka at ucw dot cz


--- Comment #5 from hubicka at ucw dot cz  2008-09-03 18:33 ---
Subject: Re:  [4.4 Regression] Segfault in decl_function_context
(TYPE_MAIN_VARIANT)

Testing:

* tree.c (build_function_type_skip_args): Build distinct type copy;
set TYPE_CONTEXT.
(build_function_decl_skip_args): Set type of new decl not orig decl;
clear DECL_VINDEX for methods turned into functions.

Index: tree.c
===
--- tree.c  (revision 139938)
+++ tree.c  (working copy)
@@ -5925,7 +5925,12 @@ build_function_type_skip_args (tree orig
   TYPE_ARG_TYPES (new_type) = new_reversed;
 }
   else
-new_type = build_function_type (TREE_TYPE (orig_type), new_reversed);
+{
+  new_type
+= build_distinct_type_copy (build_function_type (TREE_TYPE
(orig_type),
+new_reversed));
+  TYPE_CONTEXT (new_type) = TYPE_CONTEXT (orig_type);
+}

   /* This is a new type, not a copy of an old type.  Need to reassociate
  variants.  We can handle everything except the main variant lazily.  */
@@ -5959,7 +5964,12 @@ build_function_decl_skip_args (tree orig
   new_type = TREE_TYPE (orig_decl);
   if (prototype_p (new_type))
 new_type = build_function_type_skip_args (new_type, args_to_skip);
-  TREE_TYPE (orig_decl) = new_type;
+  TREE_TYPE (new_decl) = new_type;
+
+  /* For declarations setting DECL_VINDEX (i.e. methods)
+ we expect first argument to be THIS pointer.   */
+  if (bitmap_bit_p (args_to_skip, 0))
+DECL_VINDEX (new_decl) = NULL_TREE;
   return new_decl;
 }



-- 


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



[Bug middle-end/37293] [4.4 Regression] r139762 breaks libstdc++ build on darwin

2008-09-03 Thread pinskia at gcc dot gnu dot org


--- Comment #19 from pinskia at gcc dot gnu dot org  2008-09-03 18:48 
---
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=37293



[Bug middle-end/37293] [4.4 Regression] r139762 breaks libstdc++ build on darwin

2008-09-03 Thread pinskia at gcc dot gnu dot org


--- Comment #20 from pinskia at gcc dot gnu dot org  2008-09-03 18:49 
---
Subject: Bug 37293

Author: pinskia
Date: Wed Sep  3 18:48:27 2008
New Revision: 139946

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139946
Log:
2008-09-03  Andrew Pinski  <[EMAIL PROTECTED]>

PR middle-end/37293
* cgraphunit.c (update_call_expr): Remove eh regions from statements
which become non throw.
(cgraph_function_versioning): Also clear DECL_WEAK.  Call
update_call_expr after updating the flags on the decl.

2008-09-03  Andrew Pinski  <[EMAIL PROTECTED]>

PR middle-end/37293
* g++.dg/torture/ipa-cp-1.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/torture/ipa-cp-1.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraphunit.c
trunk/gcc/testsuite/ChangeLog


-- 


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



[Bug middle-end/37358] New: [4.4 Regression] IPA-CP generates duplicated symbols at -O3

2008-09-03 Thread hjl dot tools at gmail dot com
On Linux/x86-64, revision 139919 generates:

[EMAIL PROTECTED] rrs]$ cat x.cc
class FormatterListener 
{
public:
 void
 cdata(
   const unsigned short * const ch,
   const unsigned long length);
};
class XSLTEngineImpl
{
public:
 FormatterListener* getFormatterListener() const;
 void
 characters (
   const unsigned short* ch,
   unsigned long length);
 void
 characters(
   const unsigned short* ch,
   unsigned long start,
   unsigned long length);
};
void
XSLTEngineImpl::characters(
   const unsigned short* ch,
   unsigned long length)
{
 characters(ch, 0, length);
}
void
XSLTEngineImpl::characters(
   const unsigned short* ch,
   unsigned long start,
   unsigned long length)
{
  getFormatterListener()->cdata(ch + start, length);
}
[EMAIL PROTECTED] rrs]$ /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O3 -c x.cc
/tmp/ccKGs2ux.s: Assembler messages:
/tmp/ccKGs2ux.s:38: Error: symbol `_ZN14XSLTEngineImpl10charactersEPKtm' is
already defined
[EMAIL PROTECTED] rrs]$ /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O3 -c x.cc -m32
/tmp/ccKed5q8.s: Assembler messages:
/tmp/ccKed5q8.s:46: Error: symbol `_ZN14XSLTEngineImpl10charactersEPKtm' is
already defined
[EMAIL PROTECTED] rrs]$


-- 
   Summary: [4.4 Regression] IPA-CP generates duplicated symbols at
-O3
   Product: gcc
   Version: 4.4.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=37358



[Bug middle-end/37358] [4.4 Regression] IPA-CP generates duplicated symbols at -O3

2008-09-03 Thread 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
   Severity|normal  |critical
   Keywords||wrong-code
   Target Milestone|--- |4.4.0


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



  1   2   >