[Bug fortran/34828] ICE: GNU MP: Cannot reallocate memory for gfortran.dg/parameter_array_init_3.f90

2008-08-11 Thread jv244 at cam dot ac dot uk


--- Comment #22 from jv244 at cam dot ac dot uk  2008-08-11 07:34 ---
as per comment #20 and comment #21


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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



[Bug middle-end/37078] New: ICE when compiling gmp 4.2.3

2008-08-11 Thread linuxl4 at sohu dot com
gcc -v
gcc version 4.4.0 20080810 (experimental) (GCC) 


g++ -DHAVE_CONFIG_H -I. -I../../../tests/cxx -I../.. -I../../..
-I../../../tests -O2 -c -o t-ops.o ../../../tests/cxx/t-ops.cc
../../../tests/cxx/t-ops.cc: In function 'void check_mpz()':
../../../tests/cxx/t-ops.cc:33: internal compiler error: in set_value_range, at
tree-vrp.c:396
Please submit a full bug report,with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: ICE when compiling gmp 4.2.3
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: linuxl4 at sohu dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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



[Bug middle-end/36099] [4.4 Regression] early loop unrolling pass prevents vectorization, SLP doesn't do its job

2008-08-11 Thread victork at gcc dot gnu dot org


--- Comment #8 from victork at gcc dot gnu dot org  2008-08-11 07:48 ---


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


-- 

victork at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE


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



[Bug tree-optimization/22226] vectorization library

2008-08-11 Thread victork at gcc dot gnu dot org


--- Comment #3 from victork at gcc dot gnu dot org  2008-08-11 07:48 ---
*** Bug 36099 has been marked as a duplicate of this bug. ***


-- 

victork at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dominiq at lps dot ens dot
   ||fr


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



[Bug target/36613] [4.2/4.3 Regression] likely codegen bug

2008-08-11 Thread jakub at gcc dot gnu dot org


--- Comment #13 from jakub at gcc dot gnu dot org  2008-08-11 08:12 ---
Do you plan to commit this to 4.3 as well?


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|[4.2/4.3/4.4 Regression]|[4.2/4.3 Regression] likely
   |likely codegen bug  |codegen bug


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



[Bug c/37079] New: cannot find -lgcc_s

2008-08-11 Thread jayk123 at hotmail dot com
gcc 4.3.1, slightly patched to fix problems, binutils 2.18, gmp, mpfr


build=i686-pc-cygwin
host=target=sparc64-sun-solaris2.10


after first building/installing
  build=host=i686-pc-cygwin, target=sparc64-sun-solaris2.10


I thought -disable-multilib would simplify things and therefore fix them.
I don't believe this occurs with sparc-sun-solaris.
The file does exist, it just isn't found.


The cross tools installed:


$ ls /usr/local/lib/gcc/sparc64-sun-solaris2.10/4.3.1/
crt1.o libgcc_eh.alibgfortran.a libobjc.la
crtbegin.o libgcj-tools.a libgfortran.lalibobjc.so
crtend.o   libgcj-tools.lalibgfortran.solibobjc.so.2
crtfastmath.o  libgcj-tools.solibgfortran.so.3  libobjc.so.2.0.0
crti.o libgcj-tools.so.9  libgfortran.so.3.0.0  libstdc++.a
crtn.o libgcj-tools.so.9.0.0  libgfortranbegin.alibstdc++.la
finclude   libgcj.a   libgfortranbegin.la   libstdc++.so
gcrt1.olibgcj.la  libgij.a  libstdc++.so.6
gmon.o libgcj.so  libgij.la libstdc++.so.6.0.10
includelibgcj.so.9libgij.so libsupc++.a
include-fixed  libgcj.so.9.0.0libgij.so.9   libsupc++.la
install-tools  libgcj.speclibgij.so.9.0.0   sparcv9
libgcc.a   libgcov.a  libobjc.a


$ ls /usr/local/lib/gcc/sparc64-sun-solaris2.10/4.3.1/sparcv9/

libgcc_s.so  libgcc_s.so.1


well, since I use -disable-multilib, keeping "pure separate"
sparc-sun-solaris2.10
and sparc64-sun-solaris2.10, I can workaround just by copying/linking/moving
libgcc.so*.


libtool: link:  sparc64-sun-solaris2.10-c++
-L/obj/gcc.1/sparc64-sun-solaris2.10
/sparc64-sun-solaris2.10/./ld -shared -nostdlib
/usr/local/lib/gcc/sparc64-sun-s
olaris2.10/4.3.1/crti.o
/usr/local/sparc64-sun-solaris2.10/sys-root/usr/lib/spar
cv9/values-Xa.o /usr/local/lib/gcc/sparc64-sun-solaris2.10/4.3.1/crtbegin.o 
.li
bs/bitmap_allocator.o .libs/pool_allocator.o .libs/mt_allocator.o
.libs/codecvt.
o .libs/compatibility.o .libs/complex_io.o .libs/ctype.o .libs/debug.o
.libs/fun
ctexcept.o .libs/hash.o .libs/hash_c++0x.o .libs/globals_io.o .libs/hashtable.o
.libs/hashtable_c++0x.o .libs/ios.o .libs/ios_failure.o .libs/ios_init.o
.libs/i
os_locale.o .libs/limits.o .libs/list.o .libs/debug_list.o .libs/locale.o
.libs/
locale_init.o .libs/locale_facets.o .libs/localename.o .libs/stdexcept.o
.libs/s
trstream.o .libs/tree.o .libs/allocator-inst.o .libs/concept-inst.o
.libs/fstrea
m-inst.o .libs/ext-inst.o .libs/ios-inst.o .libs/iostream-inst.o
.libs/istream-i
nst.o .libs/istream.o .libs/locale-inst.o .libs/misc-inst.o
.libs/ostream-inst.o
 .libs/sstream-inst.o .libs/streambuf-inst.o .libs/streambuf.o
.libs/string-inst
.o .libs/valarray-inst.o .libs/wlocale-inst.o .libs/wstring-inst.o
.libs/atomici
ty.o .libs/codecvt_members.o .libs/collate_members.o .libs/ctype_members.o
.libs
/messages_members.o .libs/monetary_members.o .libs/numeric_members.o
.libs/time_
members.o .libs/basic_file.o .libs/c++locale.o  -Wl,--whole-archive
../libmath/.
libs/libmath.a ../libsupc++/.libs/libsupc++convenience.a -Wl,--no-whole-archive
 -Wl,-rpath -Wl,/usr/local/lib/gcc/sparc64-sun-solaris2.10/4.3.1 -Wl,-rpath
-Wl,
/usr/local/lib/gcc/sparc64-sun-solaris2.10/4.3.1
-L/obj/gcc.1/sparc64-sun-solari
s2.10/sparc64-sun-solaris2.10/./ld
-L/usr/local/lib/gcc/sparc64-sun-solaris2.10/
4.3.1
-L/usr/local/lib/gcc/sparc64-sun-solaris2.10/4.3.1/../../../../sparc64-sun
-solaris2.10/lib/sparcv9
-L/usr/local/sparc64-sun-solaris2.10/sys-root/lib/sparc
v9 -L/usr/local/sparc64-sun-solaris2.10/sys-root/usr/lib/sparcv9
-L/usr/local/li
b/gcc/sparc64-sun-solaris2.10/4.3.1/../../../../sparc64-sun-solaris2.10/lib
-L/u
sr/local/sparc64-sun-solaris2.10/sys-root/lib
-L/usr/local/sparc64-sun-solaris2.
10/sys-root/usr/lib
/usr/local/lib/gcc/sparc64-sun-solaris2.10/4.3.1/libstdc++.s
o -lm -lgcc_s /usr/local/lib/gcc/sparc64-sun-solaris2.10/4.3.1/crtend.o
/usr/loc
al/lib/gcc/sparc64-sun-solaris2.10/4.3.1/crtn.o  -Wl,-O1 -Wl,-z -Wl,relro
-Wl,--
gc-sections   -Wl,-soname -Wl,libstdc++.so.6 -o .libs/libstdc++.so.6.0.10
/usr/local/lib/gcc/sparc64-sun-solaris2.10/4.3.1/../../../../sparc64-sun-solaris
2.10/bin/ld: cannot find -lgcc_s
collect2: ld returned 1 exit status
make[4]: *** [libstdc++.la] Error 1
make[4]: Leaving directory
`/obj/gcc.1/sparc64-sun-solaris2.10/sparc64-sun-solar
is2.10/sparc64-sun-solaris2.10/libstdc++-v3/src'
make[3]: *** [all-recursive] Error 1


-- 
   Summary: cannot find -lgcc_s
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jayk123 at hotmail dot com
 GCC build triplet: i686-pc-cygwin
  GCC host triplet: i686-pc-cygwin and then sparc64-sun-solaris2.10
GCC target triplet: sparc64-sun-solaris2.10


http://gcc.gnu

[Bug middle-end/36110] ICE (segmentation fault) with -ftree-loop-distribution

2008-08-11 Thread linuxl4 at sohu dot com


--- Comment #3 from linuxl4 at sohu dot com  2008-08-11 09:32 ---
I tested to compile lapack again today ,

It seemed  has been fixed.

thanks.


-- 

linuxl4 at sohu dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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



[Bug rtl-optimization/36998] [4.3/4.4 regression] Ada bootstrap broken on i586-*-*

2008-08-11 Thread rguenth at gcc dot gnu dot org


--- Comment #13 from rguenth at gcc dot gnu dot org  2008-08-11 09:36 
---
Testcase for the kernel compile ICE:

./cc1 -quiet -Os -m32 -mpreferred-stack-boundary=2 -fasynchronous-unwind-tables
do_mounts.3.i

void panic(const char * fmt, ...) __attribute__ ((noreturn));
int printk(const char * fmt, ...);
extern int strlen(const char *s);
int do_mount_root(char *name, char *fs, int flags, void *data);
void 
mount_block_root(char *name, int flags, char *fs_names, char *root_mount_data)
{
  char *p;
  char b[32];
  for (p = fs_names; *p; p += strlen(p)+1)
{
  do_mount_root(name, p, flags, root_mount_data);
  panic("VFS: Unable to mount root fs on %s", b);
}
  for (p = fs_names; *p; p += strlen(p)+1)
printk(" %s", p);
  panic("VFS: Unable to mount root fs on %s", b);
}


-- 


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



[Bug rtl-optimization/36998] [4.3/4.4 regression] Ada bootstrap broken on i586-*-*

2008-08-11 Thread rguenth at gcc dot gnu dot org


--- Comment #14 from rguenth at gcc dot gnu dot org  2008-08-11 09:43 
---
With building the lirc kernel module I am also able to trogger

/usr/src/packages/BUILD/lirc-0.8.3/obj/default/lirc_atiusb//lirc_atiusb.c:433:
internal compiler error: in compute_barrier_args_size, at dwarf2out.c:1239
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

which is slightly different.  No testcase yet as the package seems to be
broken in different ways anyway (seems to be the same kind of assert though).


-- 


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



[Bug target/36613] [4.2/4.3 Regression] likely codegen bug

2008-08-11 Thread rguenther at suse dot de


--- Comment #14 from rguenther at suse dot de  2008-08-11 09:48 ---
Subject: Re:  [4.2/4.3 Regression] likely codegen bug

On Mon, 11 Aug 2008, jakub at gcc dot gnu dot org wrote:

> --- Comment #13 from jakub at gcc dot gnu dot org  2008-08-11 08:12 
> ---
> Do you plan to commit this to 4.3 as well?

Ulrich asked for some time on the trunk (we have built all of our
packages against a patched 4.3 tree now with no appearant problems as 
well).

Richard.


-- 


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



[Bug other/37036] fixincludes does not understand sysroot!

2008-08-11 Thread jay dot krell at cornell dot edu


--- Comment #3 from jay dot krell at cornell dot edu  2008-08-11 10:05 
---
Running fixincludes on the host after install works, but
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15694
says that is not the way..


-- 


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



Re: [Bug rtl-optimization/36998] [4.3/4.4 regression] Ada bootstrap broken on i586-*-*

2008-08-11 Thread Andrew Thomas Pinski



Sent from my iPhone

On Aug 11, 2008, at 2:43, "rguenth at gcc dot gnu dot org" <[EMAIL PROTECTED] 
> wrote:





--- Comment #14 from rguenth at gcc dot gnu dot org  2008-08-11  
09:43 ---

With building the lirc kernel module I am also able to trogger

/usr/src/packages/BUILD/lirc-0.8.3/obj/default/lirc_atiusb// 
lirc_atiusb.c:433:
internal compiler error: in compute_barrier_args_size, at  
dwarf2out.c:1239

Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

which is slightly different.  No testcase yet as the package seems  
to be
broken in different ways anyway (seems to be the same kind of assert  
though).


There is a pr about this failure already. It happens because of  
combing noreturn calls.


-- Pinski






--


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



[Bug rtl-optimization/36998] [4.3/4.4 regression] Ada bootstrap broken on i586-*-*

2008-08-11 Thread jakub at gcc dot gnu dot org


--- Comment #15 from jakub at gcc dot gnu dot org  2008-08-11 10:24 ---
Subject: Bug 36998

Author: jakub
Date: Mon Aug 11 10:23:08 2008
New Revision: 138951

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138951
Log:
PR rtl-optimization/36998
* dwarf2out.c (compute_barrier_args_size_1,
compute_barrier_args_size): Temporarily remove assertions.

* gcc.dg/pr36998.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr36998.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog


-- 


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



Re: [Bug middle-end/37078] New: ICE when compiling gmp 4.2.3

2008-08-11 Thread Andrew Thomas Pinski



Sent from my iPhone

On Aug 11, 2008, at 0:35, "linuxl4 at sohu dot com" <[EMAIL PROTECTED] 
> wrote:



gcc -v
gcc version 4.4.0 20080810 (experimental) (GCC)


g++ -DHAVE_CONFIG_H -I. -I../../../tests/cxx -I../.. -I../../..
-I../../../tests -O2 -c -o t-ops.o ../../../tests/cxx/t-ops.cc
../../../tests/cxx/t-ops.cc: In function 'void check_mpz()':
../../../tests/cxx/t-ops.cc:33: internal compiler error: in  
set_value_range, at

tree-vrp.c:396
Please submit a full bug report,with preprocessed source if  
appropriate.

See  for instructions.


Can you attach the preprocessed source as requested by the error  
message?


-- Pinski





--
  Summary: ICE when compiling gmp 4.2.3
  Product: gcc
  Version: 4.4.0
   Status: UNCONFIRMED
 Severity: normal
 Priority: P3
Component: middle-end
   AssignedTo: unassigned at gcc dot gnu dot org
   ReportedBy: linuxl4 at sohu dot com
GCC build triplet: i686-pc-linux-gnu
 GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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



[Bug rtl-optimization/36998] [4.3/4.4 regression] Ada bootstrap broken on i586-*-*

2008-08-11 Thread pinskia at gmail dot com


--- Comment #16 from pinskia at gmail dot com  2008-08-11 10:25 ---
Subject: Re:  [4.3/4.4 regression] Ada bootstrap broken on i586-*-*



Sent from my iPhone

On Aug 11, 2008, at 2:43, "rguenth at gcc dot gnu dot org"
<[EMAIL PROTECTED] 
 > wrote:

>
>
> --- Comment #14 from rguenth at gcc dot gnu dot org  2008-08-11  
> 09:43 ---
> With building the lirc kernel module I am also able to trogger
>
> /usr/src/packages/BUILD/lirc-0.8.3/obj/default/lirc_atiusb// 
> lirc_atiusb.c:433:
> internal compiler error: in compute_barrier_args_size, at  
> dwarf2out.c:1239
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
>
> which is slightly different.  No testcase yet as the package seems  
> to be
> broken in different ways anyway (seems to be the same kind of assert  
> though).

There is a pr about this failure already. It happens because of  
combing noreturn calls.

-- Pinski


>
>
>
> -- 
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36998
>


-- 


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



[Bug middle-end/37078] ICE when compiling gmp 4.2.3

2008-08-11 Thread pinskia at gmail dot com


--- Comment #1 from pinskia at gmail dot com  2008-08-11 10:26 ---
Subject: Re:   New: ICE when compiling gmp 4.2.3



Sent from my iPhone

On Aug 11, 2008, at 0:35, "linuxl4 at sohu dot com" <[EMAIL PROTECTED] 
 > wrote:

> gcc -v
> gcc version 4.4.0 20080810 (experimental) (GCC)
>
>
> g++ -DHAVE_CONFIG_H -I. -I../../../tests/cxx -I../.. -I../../..
> -I../../../tests -O2 -c -o t-ops.o ../../../tests/cxx/t-ops.cc
> ../../../tests/cxx/t-ops.cc: In function 'void check_mpz()':
> ../../../tests/cxx/t-ops.cc:33: internal compiler error: in  
> set_value_range, at
> tree-vrp.c:396
> Please submit a full bug report,with preprocessed source if  
> appropriate.
> See  for instructions.

Can you attach the preprocessed source as requested by the error  
message?

-- Pinski

>
>
>
> -- 
>   Summary: ICE when compiling gmp 4.2.3
>   Product: gcc
>   Version: 4.4.0
>Status: UNCONFIRMED
>  Severity: normal
>  Priority: P3
> Component: middle-end
>AssignedTo: unassigned at gcc dot gnu dot org
>ReportedBy: linuxl4 at sohu dot com
> GCC build triplet: i686-pc-linux-gnu
>  GCC host triplet: i686-pc-linux-gnu
> GCC target triplet: i686-pc-linux-gnu
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37078
>


-- 


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



[Bug rtl-optimization/36998] [4.3/4.4 regression] Ada bootstrap broken on i586-*-*

2008-08-11 Thread jakub at gcc dot gnu dot org


--- Comment #17 from jakub at gcc dot gnu dot org  2008-08-11 10:27 ---
Subject: Bug 36998

Author: jakub
Date: Mon Aug 11 10:26:08 2008
New Revision: 138952

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138952
Log:
PR rtl-optimization/36998
* dwarf2out.c (compute_barrier_args_size_1,
compute_barrier_args_size): Temporarily remove assertions.

* gcc.dg/pr36998.c: New test.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/pr36998.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/dwarf2out.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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



[Bug debug/37022] [4.4 regression] internal compiler error: in compute_barrier_args_size

2008-08-11 Thread jakub at gcc dot gnu dot org


--- Comment #7 from jakub at gcc dot gnu dot org  2008-08-11 12:09 ---
Sorry, I can't reproduce the first issue with a x86_64-linux -> i?86-darwin
cross on the provided preprocessed testcase, tried many different
-march=/-mtune=
options as well as -f{,no-}asynchronous-unwind-tables.  What tuning do you use?
 What preferred stack size?

The later C testcase I can reproduce, but here the testcase has a frame pointer
(insn/f 38 37 39 pr37022.c:4 (set (reg/f:SI 6 bp)
(reg/f:SI 7 sp)) 47 {*movsi_1} (nil))
so I must say I don't understand at all why we generate any
DW_CFA_GNU_args_size
directives.  I believe the unwinder won't use them anyway, as in
uw_install_context_1
if (!_Unwind_GetGRPtr (current, __builtin_dwarf_sp_column ()))
the condition is false (sp is saved in bp).  For the -fno-a-u-t we check
cfa.reg:
if (!flag_asynchronous_unwind_tables && cfa.reg != STACK_POINTER_REGNUM)
but not so for the -fa-u-t case.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org


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



[Bug c++/36478] [4.3/4.4 regression] warning not emitted when code expanded from macro

2008-08-11 Thread manu at gcc dot gnu dot org


--- Comment #3 from manu at gcc dot gnu dot org  2008-08-11 12:32 ---
(In reply to comment #2)
> void  
> foo ()
> {
> #define WARNS while(0)
> #define DOES_NOT_WARN while(0); 
> WARNS; // { dg-warning }
> DOES_NOT_WARN;

I don't think we want to warn here. Even if we have the right location of ')',
this would be hard to warn. How do you distinguish?

DOES_NOT_WARN;
DOES_NOT_WARN/**/;

That said, I don't think tracking the end of the macro is a good idea either.
It just moves the problem around. Another workaround would be to not check
close_paren.column + 1 == semicolon.column since it is the next token and
before the semicolon there is no whitespace. The only problem is if there is a
comment, such as while(0)/**/; and we have no way to track that, have we?.

For a proper fix, we need at least 2 locations for each token that comes from
an expansion. The place where the token really appeared and the place where it
ended up. However, this is not trivial. We need either to encode such
information in 1 location_t number somehow or to encode it in the token.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org


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



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

2008-08-11 Thread vda dot linux at googlemail dot com


--- Comment #11 from vda dot linux at googlemail dot com  2008-08-11 12:46 
---
Created an attachment (id=16050)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16050&action=view)
Updated patch. Uses double_int calculations instead of trees.

On Mon, 2008-08-04 at 14:26 +0200, Richard Guenther wrote:
> In extract_range_from_binary_expr it looks like the cases for
> BIT_AND_EXPR and BIT_IOR_EXPR can share most (if not all) of
> the code if you use the expression code instead of constant codes.
> 
> In bits_always_set and bits_maybe_set it is better to use double_ints
> (see double_int.h) for intermediate calculations, as they do not involve
> allocating new tree constants.

The updated patch is attached (with instrumentation code present but
#defined out).


-- 

vda dot linux at googlemail dot com changed:

   What|Removed |Added

  Attachment #16009|0   |1
is obsolete||
  Attachment #16011|0   |1
is obsolete||


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



[Bug c/36556] OpenMP: incorrect 'not specified in enclosing parallel'

2008-08-11 Thread jakub at gcc dot gnu dot org


--- Comment #3 from jakub at gcc dot gnu dot org  2008-08-11 13:09 ---
If you mean the default(none) examples (in OpenMP 3.0 that's A.28), then no,
those testcases don't explicitly say it is ok to have the firstprivate clause
with a var not explicitly mentioned in the parallel's clause, it has neither OK
nor Error there, but as it already said an Error for using y I guess it doesn't
add an comment for it.

s is referenced in the parallel construct, see 2.9.1.1:
"Specifying a variable on a firstprivate, lastprivate, or reduction clause of
an enclosed construct causes an implicit reference to the variable in the
enclosing construct. Such implicit references are also subject to the following
rules."
and 2.9.3.1:
"The default(none) clause requires that each variable that is referenced in the
construct, and that does not have a predetermined data-sharing attribute, must
have its data-sharing attribute explicitly determined by being listed in a
data-sharing attribute clause."
Whether the reference is explicit or implicit is irrelevant for 2.9.3.1.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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



[Bug c++/35158] g++ does not compile valid C++ for loops with -fopenmp

2008-08-11 Thread jakub at gcc dot gnu dot org


--- Comment #9 from jakub at gcc dot gnu dot org  2008-08-11 13:14 ---
To answer c#7, that's what would (and does) happen for autoparallelization.
But OpenMP is explicit parallelization, if you don't preceede for (...; ...;
...) ... construct with #pragma omp {,parallel } for, nothing will warn nor
error on it.  But if you have the pragma there and request OpenMP pragmas to be
recognized, then the program must not only be valid C++ (or C or Fortran), but
also valid OpenMP code, so just warnings aren't appropriate.


-- 


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



gcc-bugs@gcc.gnu.org

2008-08-11 Thread manu at gcc dot gnu dot org


--- Comment #12 from manu at gcc dot gnu dot org  2008-08-11 13:18 ---
Patch: 

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

Comments welcome!


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|gcc -O2 -Wuninitialized |-Wuninitialized missing
   |missing warning with &var   |warning with &var
   |under 2.95.x and 3.x|


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



[Bug middle-end/37078] ICE when compiling gmp 4.2.3

2008-08-11 Thread linuxl4 at sohu dot com


--- Comment #2 from linuxl4 at sohu dot com  2008-08-11 13:37 ---
Created an attachment (id=16051)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16051&action=view)
the preprocessed c++ source file

gcc -v
gcc version 4.4.0 20080810 (experimental) (GCC) 


g++ -O2 -c t-ops.cc -o t-ops.o
../../../tests/cxx/t-ops.cc: In function 'void check_mpz()':
../../../tests/cxx/t-ops.cc:33: internal compiler error: in set_value_range, at
tree-vrp.c:396
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 


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



[Bug middle-end/37042] Strict-aliasing warnings are printed for _mm_load_si128, even though __m128i is __attribute__((__may_alias__)).

2008-08-11 Thread lennox at cs dot columbia dot edu


--- Comment #7 from lennox at cs dot columbia dot edu  2008-08-11 14:11 
---
The fact that the function returns the vector is not an essential part of the
test; the return value of the load function just needs not to be optimized out
as unused.  So changing the test for broader compatibility is fine as far as
I'm concerned.


-- 


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



[Bug middle-end/37078] ICE when compiling gmp 4.2.3

2008-08-11 Thread rguenth at gcc dot gnu dot org


--- Comment #3 from rguenth at gcc dot gnu dot org  2008-08-11 14:56 ---
Reducing.


-- 


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



[Bug other/37080] New: vasprintf in libiberty fails for %llu on solaris

2008-08-11 Thread mark at easterbrook dot org dot uk
vasprintf(buffer, "%llu %s", ...)

The code is:
  while (strchr ("hlL", *p))
++p;
  /* Should be big enough for any format specifier except %s and
floats.  */
  total_width += 30;
  switch (*p)
{
case 'd':
case 'i':
case 'o':
case 'u':
case 'x':
case 'X':
case 'c':
  (void) va_arg (ap, int);
  break;


It is ignoring the ll and processing the long long argument as an int.
Unfortunately this leaves the va-list pointer in the wrong place (4 bytes out I
think). The next argument is %s, so it takes the next thing, treats it as a
pointer, and strlen() it, but this is an invalid pointer (it is really the
second part of the long long) so it seg faults.

The above code needs to count l prefixes and use va_arg(ap, long) or va_arg(ap,
long long) as appropriate.

(The h is safe as a short will be promoted to int in the variable arg list,
just the l prefix needs fixing).


-- 
   Summary: vasprintf in libiberty fails for %llu on solaris
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mark at easterbrook dot org dot uk


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



[Bug rtl-optimization/36998] [4.3/4.4 regression] Ada bootstrap broken on i586-*-*

2008-08-11 Thread eric dot weddington at atmel dot com


--- Comment #18 from eric dot weddington at atmel dot com  2008-08-11 15:02 
---
For some reason the new test case gcc.dg/pr36998.c is not excluding the AVR,
and of course the test is failing on the AVR.


-- 

eric dot weddington at atmel dot com changed:

   What|Removed |Added

 CC||eric dot weddington at atmel
   ||dot com


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



[Bug target/36613] [4.2/4.3 Regression] likely codegen bug

2008-08-11 Thread uweigand at gcc dot gnu dot org


--- Comment #15 from uweigand at gcc dot gnu dot org  2008-08-11 15:12 
---
(In reply to comment #14)
> Ulrich asked for some time on the trunk (we have built all of our
> packages against a patched 4.3 tree now with no appearant problems as 
> well).

OK, in that case I have no further concern.  I'll leave it up to you as
release manager to decide when you want it to go into 4.3 ...


-- 


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



[Bug rtl-optimization/36998] [4.3/4.4 regression] Ada bootstrap broken on i586-*-*

2008-08-11 Thread jakub at gcc dot gnu dot org


--- Comment #19 from jakub at gcc dot gnu dot org  2008-08-11 15:15 ---
For what reason should it be excluding AVR?  There is nothing target specific
in it.


-- 


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



[Bug rtl-optimization/36998] [4.3/4.4 regression] Ada bootstrap broken on i586-*-*

2008-08-11 Thread eric dot weddington at atmel dot com


--- Comment #20 from eric dot weddington at atmel dot com  2008-08-11 16:00 
---
(In reply to comment #19)
> For what reason should it be excluding AVR?  There is nothing target specific
> in it.
> 

I'm sorry, I got confused with line 4:
/* { dg-options "-Os -mpreferred-stack-boundary=2 -fasynchronous-unwind-tables"
{ target { { i?86-*-* x86_64-*-* } && ilp32 } } } */

Filing new target bug.


-- 


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



[Bug target/37029] Exception from shared library's functions or methods that return float (double, long double) value cannot be caught on HP-UX.

2008-08-11 Thread v dot grikyan at sam-solutions dot net


--- Comment #7 from v dot grikyan at sam-solutions dot net  2008-08-11 
16:02 ---
Thank you very much for your help.
We'll exploit your advices.


-- 


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



[Bug target/37081] New: [avr] FAIL: gcc.dg/pr36998.c

2008-08-11 Thread eric dot weddington at atmel dot com
Test suite failure: gcc.dg/pr36998.c for the AVR target.


-- 
   Summary: [avr] FAIL: gcc.dg/pr36998.c
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eric dot weddington at atmel dot com
GCC target triplet: avr-*-*


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



[Bug middle-end/37078] ICE when compiling gmp 4.2.3

2008-08-11 Thread rguenth at gcc dot gnu dot org


--- Comment #4 from rguenth at gcc dot gnu dot org  2008-08-11 16:09 ---
Created an attachment (id=16052)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16052&action=view)
reduced testcase


-- 


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



[Bug middle-end/37078] [4.4 Regression] ICE when compiling gmp 4.2.3

2008-08-11 Thread rguenth at gcc dot gnu dot org


--- Comment #5 from rguenth at gcc dot gnu dot org  2008-08-11 16:10 ---
Confirmed.  (-O2 -m32)

#1  0x00c288e4 in set_value_range (vr=0x7fffd5e0, t=VR_RANGE, 
min=0x773c52d0, max=0x773c5300, equiv=0x0)
at /space/rguenther/src/svn/trunk/gcc/tree-vrp.c:395
395 gcc_assert (!is_overflow_infinity (min)
(gdb) l
390
391   cmp = compare_values (min, max);
392   gcc_assert (cmp == 0 || cmp == -1 || cmp == -2);
393
394   if (needs_overflow_infinity (TREE_TYPE (min)))
395 gcc_assert (!is_overflow_infinity (min)
396 || !is_overflow_infinity (max));
397 }
398
399   if (t == VR_UNDEFINED || t == VR_VARYING)
(gdb) call debug_tree (min)   
 
constant public overflow 2147483647>
(gdb) call debug_tree (max)
 
constant public overflow 2147483647>


-- 

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-08-11 16:10:35
   date||
Summary|ICE when compiling gmp 4.2.3|[4.4 Regression] ICE when
   ||compiling gmp 4.2.3
   Target Milestone|--- |4.4.0


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



[Bug target/36613] [4.2 Regression] likely codegen bug

2008-08-11 Thread matz at gcc dot gnu dot org


--- Comment #16 from matz at gcc dot gnu dot org  2008-08-11 16:22 ---
committed as r138955 into 4_3 branch.


-- 

matz at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
Summary|[4.2/4.3 Regression] likely |[4.2 Regression] likely
   |codegen bug |codegen bug


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



[Bug rtl-optimization/36998] [4.3/4.4 regression] Ada bootstrap broken on i586-*-*

2008-08-11 Thread jakub at gcc dot gnu dot org


--- Comment #21 from jakub at gcc dot gnu dot org  2008-08-11 16:23 ---
Note that I've committed a temporary removal of the asserts, so we now only
silently generate incorrect DW_CFA_GNU_args_size directives, but don't ICE.
Downgrading to P2.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P1  |P2


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



[Bug target/36613] [4.2 Regression] likely codegen bug

2008-08-11 Thread matz at gcc dot gnu dot org


-- 

matz at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to fail|4.0.2 4.1.0 |4.0.2 4.1.0 4.3.1
   Target Milestone|4.2.5   |4.3.2


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



[Bug target/36613] [4.2 Regression] likely codegen bug

2008-08-11 Thread matz at gcc dot gnu dot org


--- Comment #17 from matz at gcc dot gnu dot org  2008-08-11 16:23 ---
Subject: Bug 36613

Author: matz
Date: Mon Aug 11 16:22:00 2008
New Revision: 138955

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138955
Log:
PR target/36613

* reload.c (push_reload): Merge in,out,in_reg,out_reg members
for reused reload, instead of overwriting them.

* gcc.target/i386/pr36613.c: New testcase.

Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/pr36613.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/reload.c
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog


-- 


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



[Bug rtl-optimization/36998] [4.3/4.4 regression] Ada bootstrap broken on i586-*-*

2008-08-11 Thread jakub at gcc dot gnu dot org


--- Comment #22 from jakub at gcc dot gnu dot org  2008-08-11 16:25 ---
Created an attachment (id=16053)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16053&action=view)
pop.patch

Additional patch on top of sp=reg.patch patch, which should fix the SH4 case -
the simplistic stack_adjust_offset wouldn't see the adjustments in pop
instructions, only push instructions.  I'm not sure if it is enough to do it
this way, or whether for_each_rtx shouldn't be called instead to find all
embedded MEMs with {PRE,POST}_{INC,DEC,MODIFY} operands on sp register.


-- 


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



[Bug target/36756] [4.4 Regression] g++.dg/tls-3.C ICE with section-anchors, unit-at-a-time, no-toplevel-reorder

2008-08-11 Thread janis at gcc dot gnu dot org


--- Comment #3 from janis at gcc dot gnu dot org  2008-08-11 17:17 ---
I have a fix for this; the code to prevent using section anchors with
no-unit-at-a-time is done in the wrong order.


-- 

janis at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |janis at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-08-11 01:41:07 |2008-08-11 17:17:42
   date||


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



[Bug middle-end/37078] [4.4 Regression] ICE when compiling gmp 4.2.3

2008-08-11 Thread howarth at nitro dot med dot uc dot edu


--- Comment #6 from howarth at nitro dot med dot uc dot edu  2008-08-11 
17:34 ---
Is there a particular revision that this appeared in? I built a svn pull from
gcc trunk on 20080808 (using the optabs fix that has since been checked in)
against
gmp 4.2.3 on i686-apple-darwin9 and didn't see any build issues.


-- 


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



[Bug debug/37022] [4.4 regression] internal compiler error: in compute_barrier_args_size

2008-08-11 Thread andreast at gcc dot gnu dot org


--- Comment #8 from andreast at gcc dot gnu dot org  2008-08-11 18:12 
---
When I opened the PR I had set the target to x86_64-apple-darwin9.

It does not happen under ix86-apple-darwin9.

My config for gcc looks like this:

[deuterium:gcc/head/objdir-x86_64] andreast% ./gcc/xgcc -v
Using built-in specs.
Target: x86_64-apple-darwin9
Configured with: /Volumes/development/gcc/head/gcc/configure
--prefix=/Volumes/development/gcc/head/testbin-x86_64
--build=x86_64-apple-darwin9 --target=x86_64-apple-darwin9 --disable-static
--disable-multilib --with-gmp=/usr/local/x86_64 --with-mpfr=/usr/local/x86_64
--enable-languages=c,c++,fortran,java,objc,obj-c++ --enable-java-awt=xlib
Thread model: posix
gcc version 4.4.0 20080810 (experimental) [trunk revision 138933] (GCC)


-- 


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



[Bug middle-end/37014] [4.2/4.3/4.4 Regression] internal compiler error: in expand_expr_real_1, at expr.c:8760

2008-08-11 Thread jakub at gcc dot gnu dot org


--- Comment #7 from jakub at gcc dot gnu dot org  2008-08-11 18:38 ---
I think the options are:
1) handle TRUTH_{AND,OR}IF_EXPR in expand_expr again (revert part of Paolo's
   2004-08-09 expr.c "dead" code removals) - while these aren't present
   in GIMPLE nor can be created by TER, they can be created by folding during
   expansion.  Maybe even COMPOUND_EXPR could be handled there and all the
   ugly hacks builtins.c does to work around this could be removed.
2) have a special flag for fold-const.c, set during expansion, that would
   preclude certain kinds of folding (e.g. creation of the trees that aren't
   handled by the expander)
3) have expand's special versions of the various fold* routines, look for the
   unhandled trees in what it creates and either fail to fold them, or
transform
   to something else.

IMHO 1) would be probably easiest to implement, 3) too ugly to live, 2)
possible.


-- 


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



[Bug middle-end/36817] [4.3 Regression] internal compiler error: in compare_values_warnv

2008-08-11 Thread jakub at gcc dot gnu dot org


--- Comment #1 from jakub at gcc dot gnu dot org  2008-08-11 19:28 ---
This is target independent, reproduced on x86_64-linux and ppc-linux as well.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

  GCC build triplet|i686-pc-linux-gnu   |
   GCC host triplet|i686-pc-linux-gnu   |
 GCC target triplet|arm-elf |


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



[Bug fortran/37083] New: See Bug 33400 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33400)

2008-08-11 Thread tibor at atlas dot cz
It seems that bug 33400 is not fixed in mingw32 version of gfortran (winXP):

Missplaced END-OF-FILE when reading file without a line terminator on
the last line, e.g.

REAL :: a, b, c
OPEN(UNIT=10,FILE='input')
READ(10,*) a, b, c
PRINT*, a*b*c
END

(file 'input' created with notepad -- without line break after last line)

IF file 'input' doesnt contain line terminator on
the last line, program crashes with:

At line 3 of file nt.f90 (unit = 10, file = 'input')
Fortran runtime error: End of file


-- 
   Summary: See Bug 33400
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33400)
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tibor at atlas dot cz
 GCC build triplet: i586-pc-mingw32


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



[Bug debug/37022] [4.4 regression] internal compiler error: in compute_barrier_args_size

2008-08-11 Thread jakub at gcc dot gnu dot org


--- Comment #9 from jakub at gcc dot gnu dot org  2008-08-11 20:17 ---
The darwin -m64 failures are then the same problem, cross-jumping of noreturn
calls between different level of stack depths.
I've been wrong about DW_CFA_GNU_args_size being useless for cfa.reg !=
STACK_POINTER_REGNUM, while such directives won't ever be used by the libgcc
unwinder, they might be used by debuggers to set correct value of stack
pointer,
and therefore such directives aren't useless and so we should avoid
crossjumping
in that case.  Not sure how to detect that in crossjumping code though.


-- 


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



[Bug c++/36688] [4.3/4.4 Regression] Incorrect struct assignments with nested const initializers

2008-08-11 Thread jakub at gcc dot gnu dot org


--- Comment #2 from jakub at gcc dot gnu dot org  2008-08-11 20:50 ---
I think in gimplify_modify_expr_rhs
  case VAR_DECL:
/* If we're assigning from a constant constructor, move the
   constructor expression to the RHS of the MODIFY_EXPR.  */
if (DECL_INITIAL (*from_p)
&& TYPE_READONLY (TREE_TYPE (*from_p))
&& !TREE_THIS_VOLATILE (*from_p)
&& TREE_CODE (DECL_INITIAL (*from_p)) == CONSTRUCTOR)
we should be checking TREE_READONLY (*from_p) rather than TYPE_READONLY
(TREE_TYPE (*from_p)), as when the type is read-only, but the VAR_DECL is not,
the initializer in DECL_INITIAL might be still incomplete and needing runtime
initialization.


-- 

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-08-11 01:38:50 |2008-08-11 20:50:26
   date||


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



[Bug tree-optimization/37084] New: [4.4 regression] ICE in gimple_assign_rhs1

2008-08-11 Thread reichelt at gcc dot gnu dot org
The following valid testcase triggers an ICE on mainline when compiled
with "-O" (i686-pc-linux-gnu) or "-o -m32" (x64_64-unknown-linux-gnu):

===
struct A
{
  A();
};

inline A foo() { return A(); }

const A a(foo());
===

bug.cc: In function 'void __static_initialization_and_destruction_0(int, int)':
bug.cc:8: internal compiler error: gimple check: expected
gimple_assign(error_mark), have gimple_call() in gimple_assign_rhs1, at
gimple.h:1717
Please submit a full bug report, [etc.]

The regression appeared between 2008-07-26 and 2008-07-29.


-- 
   Summary: [4.4 regression] ICE in gimple_assign_rhs1
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, monitored
  Severity: major
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org


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



[Bug tree-optimization/37084] [4.4 regression] ICE in gimple_assign_rhs1

2008-08-11 Thread reichelt at gcc dot gnu dot org


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


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



[Bug tree-optimization/37084] [4.4 regression] ICE in gimple_assign_rhs1

2008-08-11 Thread pinskia at gcc dot gnu dot org


--- Comment #1 from pinskia at gcc dot gnu dot org  2008-08-11 21:07 ---
Most likely introduced by the tuples merge ...


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org


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



[Bug c++/37085] New: global friends in classes

2008-08-11 Thread mrs at apple dot com
Global friend inside a class regressed.

$ cat /tmp/t.cc
class test1 {
 public:
  friend void newtest1(int x) {
  }
};

int main(int argc, char *argv[]) {
  newtest1(5);
}
$ ./xgcc -B./ /tmp/t.cc -c
/tmp/t.cc: In function ‘int main(int, char**)’:
/tmp/t.cc:8: error: ‘newtest1’ was not declared in this scope
GNU C++ (GCC) version 4.4.0 20080811 (experimental) [trunk revision 138965]
(i686-apple-darwin9)

This worked just fine in gcc 4.0.1.

radr://6135771


-- 
   Summary: global friends in classes
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mrs at apple dot com
  GCC host triplet: i686-apple-darwin9


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



[Bug c++/37085] global friends in classes

2008-08-11 Thread mrs at apple dot com


--- Comment #1 from mrs at apple dot com  2008-08-11 21:39 ---
Oh, see 11.4p5 (ANSI 98 standard) for details on this type of code.


-- 


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



[Bug bootstrap/37086] New: Cross-compilers built with GCC 3.4 do not work

2008-08-11 Thread drow at gcc dot gnu dot org
Building libgcc, I get:

/scratch/dan/mips-nonpic-upstream/src/gcc-mainline/libgcc/../gcc/unwind-pe.h:
In function 'size_of_encoded_value':
/scratch/dan/mips-nonpic-upstream/src/gcc-mainline/libgcc/../gcc/unwind-pe.h:78:
internal compiler error: tree check: accessed elt 7 of tree_vec with 5 elts in
find_switch_asserts, at tree-vrp.c:4346

/scratch/dan/mips-nonpic-upstream/src/gcc-mainline/libgcc/../gcc/unwind-dw2.c:1257:
internal compiler error: tree check: accessed elt 9 of tree_vec with 7 elts in
find_switch_asserts, at tree-vrp.c:4346

If I recompile tree-vrp.o with -O0, then libgcc compiles OK.

Joseph suggests this came in at the time of the tuples merge.  If possible, it
would be nice if we could avoid the problematic construct...

The code in question is:

  /* If there are multiple case labels with the same destination
 we need to combine them to a single value range for the edge.  */
  if (idx + 1 < n
  && CASE_LABEL (cl) == CASE_LABEL (TREE_VEC_ELT (vec2, idx + 1)))
{
  /* Skip labels until the last of the group.  */
  do {
++idx;
  } while (idx < n
   && CASE_LABEL (cl) == CASE_LABEL (TREE_VEC_ELT (vec2,
idx)));
  --idx;

When we reach the outer if, idx == 3 and n == 5.  We go around twice, but idx
goes up to 7.

It looks like a loop optimization issue:

0x84fa0fd :   lea0x2(%edi),%esi
0x84fa100 :   mov-0x40(%ebp),%edi
0x84fa103 :   cmp-0x3c(%ebp),%edi
0x84fa106 :   mov%esi,-0x40(%ebp)
0x84fa109 :   jb 0x84fa080

0x84fa10f :   mov-0x38(%ebp),%ecx
0x84fa112 :   dec%esi
0x84fa113 :   mov%esi,-0x40(%ebp)

-0x40(%ebp) is idx, and idx+1 is in %edi before the above code.


-- 
   Summary: Cross-compilers built with GCC 3.4 do not work
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: drow at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux-gnu


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



[Bug bootstrap/37086] Cross-compilers built with GCC 3.4 do not work

2008-08-11 Thread joseph at codesourcery dot com


--- Comment #1 from joseph at codesourcery dot com  2008-08-11 22:19 ---
Subject: Re:   New: Cross-compilers built with GCC 3.4
 do not work

On Mon, 11 Aug 2008, drow at gcc dot gnu dot org wrote:

> Joseph suggests this came in at the time of the tuples merge.  If possible, it
> would be nice if we could avoid the problematic construct...

Specifically, I did a binary search that determined the tuples merge as 
the revision at which this broke.


-- 


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



[Bug c++/37087] New: Segfault on compiling template defined in wrong namespace.

2008-08-11 Thread gcc-bugzilla at gcc dot gnu dot org

G++ reports a segmentation fault when compiling the code below.

Environment:
System: Linux temporal.corp.google.com 2.6.18.5-gg34workstation-mixed64-32 #1
SMP Thu May 8 01:31:23 UTC 2008 x86_64 GNU/Linux
Architecture: x86_64

host: i486-pc-linux-gnu
build: i486-pc-linux-gnu
target: i486-pc-linux-gnu
configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-awt=gtk-default --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr
--disable-werror --with-tune=pentium4 --enable-checking=release i486-linux-gnu

How-To-Repeat:
Invoke g++ on the following (invalid) code with no other arguments.
There are no #includes; this is the entire source file.

==
namespace a {
  template  class Foo;
}

namespace b {
  template <> class ::a::Foo {};
}
==

(The gccbug script claims it will remove "comments" delimited by angle
brackets.
Hopefully that isn't actually true because it will mess up the above code
sample as well as the following error log.)

Result:
testtemplate.cc:6: error: global qualification of class name is invalid before
'{' token
testtemplate.cc:6: error: specialization of 'template struct a::Foo'
in different namespace
testtemplate.cc:2: error:   from definition of 'template struct
a::Foo'
g++: Internal error: Segmentation fault (program cc1plus)
Please submit a full bug report.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions, see
.


--- Comment #1 from kenton at google dot com  2008-08-11 22:23 ---
Fix:
Unknown.


-- 
   Summary: Segfault on compiling template defined in wrong
namespace.
   Product: gcc
   Version: 4.0.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kenton at google dot com
 GCC build triplet: i486-pc-linux-gnu
  GCC host triplet: i486-pc-linux-gnu
GCC target triplet: i486-pc-linux-gnu


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



[Bug c++/37085] global friends in classes

2008-08-11 Thread pinskia at gcc dot gnu dot org


--- Comment #2 from pinskia at gcc dot gnu dot org  2008-08-11 22:38 ---
You want to use -ffriend-injection option for this.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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



[Bug c++/37088] New: Functions with default parameters not correctly handled inside templates.

2008-08-11 Thread tmsriram at google dot com
For this simple program (test.cc):
-
template 
void AssertPred(Pred pred) {
 pred("x", "y");
}

bool pred4(const char *, const char *, const char *x = "", const char *y = "");
bool pred2(const char *, const char *);

void foof() {
  AssertPred(pred2);
  AssertPred(pred4);
}
-


> $gcc421 -c test.ii (Success with gcc-4.2.1)


> $gcc431  -c test.ii (Failure with gcc-4.3.1)

test.ii: In function 'void AssertPred(Pred) [with Pred = bool (*)(const char*,
const char*, const char*, const char*)]':
test.ii:   instantiated from here
test.ii: error: too few arguments to function


-- 
   Summary: Functions with default parameters not correctly handled
inside templates.
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tmsriram at google dot com
 GCC build triplet: x86_64
  GCC host triplet: x86_64
GCC target triplet: x86_64


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



gcc-bugs@gcc.gnu.org

2008-08-11 Thread chris dot fairles at gmail dot com
template 
void f(T&& a, bool);

template 
void f(T&& a){ 
  foo(std::forward(a), true);
} 

void f(int&& a, bool)
{ } 

int main()
{
  int a;
  f(a);
}

"undefined reference to 'void f(int&&&, bool)'".

Note the "&&&" which I believe is int&& + int& which should be int&.

Chris


-- 
   Summary: rvalue/lvalue reference collapsing not performed in
error ouput thus printing "&&&"
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris dot fairles at gmail 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=37089



[Bug c++/37087] Segfault on compiling template defined in wrong namespace.

2008-08-11 Thread paolo dot carlini at oracle dot com


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |paolo dot carlini at oracle
   |dot org |dot com
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Keywords||ice-on-invalid-code
  Known to fail||4.3.1 4.4.0
   Last reconfirmed|-00-00 00:00:00 |2008-08-11 22:41:51
   date||


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



[Bug c++/37088] Functions with default parameters not correctly handled inside templates.

2008-08-11 Thread pinskia at gcc dot gnu dot org


--- Comment #1 from pinskia at gcc dot gnu dot org  2008-08-11 22:45 ---
Hmm, I don't think default parameters are taken into account with function
pointers.   I think this was a GCC "undocumented extension" (aka bug) that was
fixed in 4.3.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|major   |normal


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



[Bug c++/34758] [4.2/4.3/4.4 regression] Bad diagnostic for circular dependency in constructor default argument

2008-08-11 Thread paolo dot carlini at oracle dot com


--- Comment #5 from paolo dot carlini at oracle dot com  2008-08-11 22:49 
---
Not really actively working on it, sorry.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu
   |dot com |dot org
 Status|ASSIGNED|NEW


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



[Bug fortran/37083] See Bug 33400 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33400)

2008-08-11 Thread jvdelisle at gcc dot gnu dot org


--- Comment #1 from jvdelisle at gcc dot gnu dot org  2008-08-12 00:27 
---
Without looking at a thing I will guess this is a CR-LF issue.  I will have a
look.


-- 


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



[Bug rtl-optimization/36998] [4.3/4.4 regression] Ada bootstrap broken on i586-*-*

2008-08-11 Thread kkojima at gcc dot gnu dot org


--- Comment #23 from kkojima at gcc dot gnu dot org  2008-08-12 00:27 
---
(In reply to comment #22)
> Created an attachment (id=16053)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16053&action=view) [edit]
> pop.patch

I've confirmed that this patch gets rid of the ICEs for the test
case in #7 and the original libjava build failure on SH4, though
libjava fails to build at the another place on SH4.
Here is a reduced test case:

typedef union {
  double value;
  struct { unsigned int lsw, msw; } parts;
} ieee_double_shape_type;

double
foo (double x)
{
  unsigned int hx, lx;
  ieee_double_shape_type u;

  u.value = x;
  hx = u.parts.msw;

  if (hx >= 0x40862E42)
{
  if (hx >= 0x7ff0)
{
  u.value = x;
  lx = u.parts.lsw;

  if (((hx & 0xf) | lx) != 0)
return x+x;
}
}

  return x;
}

I'd like to attach .206.shorten dump for this.


-- 


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



[Bug rtl-optimization/36998] [4.3/4.4 regression] Ada bootstrap broken on i586-*-*

2008-08-11 Thread kkojima at gcc dot gnu dot org


--- Comment #24 from kkojima at gcc dot gnu dot org  2008-08-12 00:30 
---
Created an attachment (id=16054)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16054&action=view)
rtl dump

.shorten rtl dump for the test case in #23 with
-O -fasynchronous-unwind-tables


-- 


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



[Bug c/37090] New: optimization breaks code in manually unrolled loop

2008-08-11 Thread michael+gcc at stapelberg dot de
Except for -O0, all levels of optimization make the same mistake on the
attached files.

Compile them (for example) with:
gcc -O2 sp.c mybyte.c -o sp

On gcc 4.3.1 (vanilla, self-compiled, also applies to the gentoo standard one),
this outputs "123456789abcd" instead of "123456789abcdef" (gcc 4.1.2 for
example).

When removing the fourth line of the loop, it works.

I could reproduce this also on debian.

Just in case you care, the code is ripped out of fefe's libowfat.

Target: i686-pc-linux-gnu
Configured with: ./configure --prefix=/opt/gcc431 --with-mpfr=/opt/gcc431
Thread model: posix
gcc version 4.3.1 (GCC) 
Linux xekskami 2.6.25.10 #8 SMP PREEMPT Thu Jul 17 16:00:00 CEST 2008 i686
Genuine Intel(R) CPU   T2500  @ 2.00GHz GenuineIntel GNU/Linux


-- 
   Summary: optimization breaks code in manually unrolled loop
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michael+gcc at stapelberg dot de


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



[Bug c/37090] optimization breaks code in manually unrolled loop

2008-08-11 Thread michael+gcc at stapelberg dot de


--- Comment #1 from michael+gcc at stapelberg dot de  2008-08-12 00:49 
---
Created an attachment (id=16055)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16055&action=view)
sp.c (testcase, file 1/2)


-- 


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



[Bug c/37090] optimization breaks code in manually unrolled loop

2008-08-11 Thread michael+gcc at stapelberg dot de


--- Comment #2 from michael+gcc at stapelberg dot de  2008-08-12 00:49 
---
Created an attachment (id=16056)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16056&action=view)
mybyte.c (testcase, file 2/2)


-- 


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



[Bug c/37090] optimization breaks code in manually unrolled loop

2008-08-11 Thread pinskia at gcc dot gnu dot org


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|blocker |normal


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



[Bug debug/37022] [4.4 regression] internal compiler error: in compute_barrier_args_size

2008-08-11 Thread xuepeng dot guo at intel dot com


--- Comment #10 from xuepeng dot guo at intel dot com  2008-08-12 02:07 
---
(In reply to comment #7)
> Sorry, I can't reproduce the first issue with a x86_64-linux -> i?86-darwin
> cross on the provided preprocessed testcase, tried many different
> -march=/-mtune=
> options as well as -f{,no-}asynchronous-unwind-tables.  What tuning do you 
> use?
>  What preferred stack size?
> The later C testcase I can reproduce, but here the testcase has a frame 
> pointer
> (insn/f 38 37 39 pr37022.c:4 (set (reg/f:SI 6 bp)
> (reg/f:SI 7 sp)) 47 {*movsi_1} (nil))
> so I must say I don't understand at all why we generate any
> DW_CFA_GNU_args_size
> directives.  

I am not clear of you but this rtl is necessary for our stack realign proposal.
During we designed and implemented the stack realign proposal we didn't intend
to affect the existing way that DW_CFA_GNU_args_szie works. 

>I believe the unwinder won't use them anyway, as in
> uw_install_context_1
> if (!_Unwind_GetGRPtr (current, __builtin_dwarf_sp_column ()))
> the condition is false (sp is saved in bp).  For the -fno-a-u-t we check
> cfa.reg:
The unwinder will restore sp by DW_CFA_def_cfa_expression as shown below:
080483a8 :
 80483a8:   8d 4c 24 04 lea0x4(%esp),%ecx
 80483ac:   83 e4 f0and$0xfff0,%esp
 80483af:   ff 71 fcpushl  -0x4(%ecx)
 80483b2:   55  push   %ebp
 80483b3:   89 e5   mov%esp,%ebp
 80483b5:   51  push   %ecx
 80483b6:   83 ec 04sub$0x4,%esp

0018 0024 001c FDE cie= pc=080483a8..080483d8
  DW_CFA_advance_loc: 4 to 080483ac
  DW_CFA_def_cfa: r1 (ecx) ofs 0
  DW_CFA_advance_loc: 9 to 080483b5
  DW_CFA_expression: r5 (ebp) (DW_OP_breg5: 0)
  DW_CFA_advance_loc: 1 to 080483b6
  DW_CFA_def_cfa_expression (DW_OP_breg5: -4; DW_OP_deref) <<< restore sp
  DW_CFA_advance_loc: 12 to 080483c2
  DW_CFA_GNU_args_size: 32
  DW_CFA_advance_loc: 22 to 080483d8
  DW_CFA_GNU_args_size: 0
  DW_CFA_nop


> if (!flag_asynchronous_unwind_tables && cfa.reg != STACK_POINTER_REGNUM)
> but not so for the -fa-u-t case.


-- 


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



[Bug middle-end/37078] [4.4 Regression] ICE when compiling gmp 4.2.3

2008-08-11 Thread linuxl4 at sohu dot com


--- Comment #7 from linuxl4 at sohu dot com  2008-08-12 02:11 ---
>Is there a particular revision that this appeared in? I built a svn pull from
>gcc trunk on 20080808 (using the optabs fix that has since been checked in)
>against
>gmp 4.2.3 on i686-apple-darwin9 and didn't see any build issues.

this happens when "make check".

please try.


-- 


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



[Bug debug/37022] [4.4 regression] internal compiler error: in compute_barrier_args_size

2008-08-11 Thread xuepeng dot guo at intel dot com


--- Comment #11 from xuepeng dot guo at intel dot com  2008-08-12 02:11 
---
(In reply to comment #9)
> The darwin -m64 failures are then the same problem, cross-jumping of noreturn
> calls between different level of stack depths.
> I've been wrong about DW_CFA_GNU_args_size being useless for cfa.reg !=
> STACK_POINTER_REGNUM, while such directives won't ever be used by the libgcc
> unwinder, they might be used by debuggers to set correct value of stack
> pointer,
> and therefore such directives aren't useless and so we should avoid
> crossjumping
> in that case.  Not sure how to detect that in crossjumping code though.

You are right. IMHO this is exactly the reason.


-- 


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



[Bug c++/36654] Inlined con/de-structor breaks virtual inheritance dllimport classes

2008-08-11 Thread tdragon at tdragon dot net


--- Comment #3 from tdragon at tdragon dot net  2008-08-12 02:13 ---
As of r138967 pulled down today from the 4.3 branch, this bug is in fact still
present. Shell session follows.

> g++ -v
Using built-in specs.
Target: mingw32
Configured with: ../gcc-4.3-svn/configure --prefix=/mingw --build=mingw32
--enable-languages=c,c++
--with-bugurl=http://www.tdragon.net/recentgcc/bugs.php --disable-nls
--disable-win32-registry --disable-werror --enable-threads --disable-symvers
--enable-cxx-flags='-fno-function-sections -fno-data-sections'
--enable-fully-dynamic-string --enable-version-specific-runtime-libs
--enable-sjlj-exceptions --with-pkgversion='GCC TDM-1 for MinGW'
--disable-bootstrap
Thread model: win32
gcc version 4.3.2 20080811 (prerelease) (GCC TDM-1 for MinGW)

> g++ -c deltatest.ii
deltatest.ii:8: internal compiler error: in maybe_emit_vtables, at
cp/decl2.c:1745
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://www.tdragon.net/recentgcc/bugs.php> for instructions.


-- 

tdragon at tdragon dot net changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|DUPLICATE   |


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



[Bug bootstrap/37091] New: Rev 138207 causes ICE using bootstrap for crt for win64

2008-08-11 Thread nightstrike at gmail dot com
Building for a target of win64 on cygwin results in an ICE while building the
crt for the toolchain.  Using this sequence:

binutils
all-gcc
crt
gcc

The crt phase dies as follows:

x86_64-pc-mingw32-gcc -DHAVE_CONFIG_H -I.
-I/var/lib/buildbot/slave-vista64-cyg32/cygwin-x86/build/mingw/obj/../mingw-w64-crt
-I/var/lib/buildbot/slave-vista64-cyg32/cygwin-x86/build/mingw/obj/../mingw-w64-crt/include64
-D_CRTBLD
-I/var/lib/buildbot/slave-vista64-cyg32/cygwin-x86/build/root/mingw/include
 -pipe  -Wall -std=gnu99 -g -O2 -MT gdtoa/lib64_libmingwex_a-gethex.o -MD -MP
-MF gdtoa/.deps/lib64_libmingwex_a-gethex.Tpo -c -o
gdtoa/lib64_libmingwex_a-gethex.o `test -f 'gdtoa/gethex.c' || echo
'/var/lib/buildbot/slave-vista64-cyg32/cygwin-x86/build/mingw/obj/../mingw-w64-crt/'`gdtoa/gethex.c
/var/lib/buildbot/slave-vista64-cyg32/cygwin-x86/build/mingw/obj/../mingw-w64-crt/gdtoa/gethex.c:
In function '__gethex_D2A':
/var/lib/buildbot/slave-vista64-cyg32/cygwin-x86/build/mingw/obj/../mingw-w64-crt/gdtoa/gethex.c:45:
internal compiler error: tree check: accessed elt 4 of tree_vec with 3
elts in find_switch_asserts, at tree-vrp.c:4346
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[1]: *** [gdtoa/lib64_libmingwex_a-gethex.o] Error 1
make[1]: Leaving directory
`/var/lib/buildbot/slave-vista64-cyg32/cygwin-x86/build/mingw/obj'
make: *** [all] Error 2


Here's the file:

http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/trunk/mingw-w64-crt/gdtoa/gethex.c?view=markup


At this stage, the newly built gcc is used to build the crt, so it's the stage
1 gcc that is dying.


-- 
   Summary: Rev 138207 causes ICE using bootstrap for crt for win64
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nightstrike at gmail dot com
 GCC build triplet: i686-pc-cygwin
  GCC host triplet: i686-pc-cygwin
GCC target triplet: x86_64-pc-mingw32


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



[Bug bootstrap/37091] Rev 138207 causes ICE using bootstrap for crt for win64

2008-08-11 Thread nightstrike at gmail dot com


--- Comment #1 from nightstrike at gmail dot com  2008-08-12 04:46 ---
Created an attachment (id=16057)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16057&action=view)
Preprocessed source

This is the preprocessed source for the file that causes the ICE


-- 


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



[Bug bootstrap/37091] Rev 138207 causes ICE using bootstrap for crt for win64

2008-08-11 Thread nightstrike at gmail dot com


--- Comment #2 from nightstrike at gmail dot com  2008-08-12 04:46 ---
Preprocessed source added as attachment.  Also note that the bootstrap gcc was
built with cygwin's gcc, which is a modified 3.4.4.


-- 


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



[Bug bootstrap/37091] Rev 138207 causes ICE using bootstrap for crt for win64

2008-08-11 Thread aaronavay62 at aaronwl dot com


--- Comment #3 from aaronavay62 at aaronwl dot com  2008-08-12 05:02 ---
This failure comes up whenever GCC 3.4.x is used to build GCC 4.4 on Windows. 
I'm not sure if it affects any non-Windows targets.


-- 

aaronavay62 at aaronwl dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
  GCC build triplet|i686-pc-cygwin  |*-mingw*, *-cygwin
   GCC host triplet|i686-pc-cygwin  |
 GCC target triplet|x86_64-pc-mingw32   |*-mingw*, *-cygwin
   Last reconfirmed|-00-00 00:00:00 |2008-08-12 05:02:15
   date||


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



[Bug bootstrap/37091] Rev 138207 causes ICE using bootstrap for crt for win64

2008-08-11 Thread aaronavay62 at aaronwl dot com


--- Comment #4 from aaronavay62 at aaronwl dot com  2008-08-12 05:04 ---
To clarify, GCC 3.4.x miscompiles GCC 4.4 when not being bootstrapped.  A
normal bootstrap won't show this failure, but a cross build or
--disable-bootstrap will.


-- 


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



[Bug tree-optimization/35428] [4.3 regression] ICE with "-ftrapv"

2008-08-11 Thread reichelt at gcc dot gnu dot org


--- Comment #10 from reichelt at gcc dot gnu dot org  2008-08-12 06:45 
---
The bug is still present on the 4.3 branch as of 2008-08-11 (with both the C
and C++ frontend).


-- 


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



[Bug c/35746] [4.3 regression] ICE with undefined variables

2008-08-11 Thread reichelt at gcc dot gnu dot org


--- Comment #8 from reichelt at gcc dot gnu dot org  2008-08-12 06:48 
---
As Andrew Pinski pointed out, we suppress ICEs after regular errors.
You have to configure the compiler with --enable-checking to see the real ICE.


-- 


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