[Bug target/39767] libgcc2.c:562: internal compiler error: RTL check: expected code 'reg', have 'ashiftrt' in rhs_regno, at rtl.h:1005

[kkojima at gcc dot gnu dot org]

--- Comment #3 from kkojima at gcc dot gnu dot org  2009-04-15 07:05 ---
Sorry for missing that 4.4 is still open for regressions.
I'll apply the patch on trunk if the normal tests are done
successfully and backport it on 4.4-branch.


-- 


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

[Bug tree-optimization/39764] ICE in set_lattice_value, at tree-ssa-ccp.c:468 with -ffinite-math-only

[ubizjak at gmail dot com]

--- Comment #2 from ubizjak at gmail dot com  2009-04-15 07:30 ---
Confirmed on i686-pc-linux-gnu with '-O -ffinite-math-only' on trunk.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|middle-end  |tree-optimization
 Ever Confirmed|0   |1
  Known to fail||4.3.3 4.4.0
   Last reconfirmed|-00-00 00:00:00 |2009-04-15 07:30:13
   date||


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

[Bug libstdc++/39775] New: ext/throw_allocator/check_delete.cc execution abort with mt_allocator

[hailijuan at gmail dot com]

On Solaris 11, we observed execution abort for the testcase below:
+libstdc++.sum:FAIL: ext/throw_allocator/check_delete.cc execution test

The testcase check_delete.cc and its related header files are included in the
attachment bug.tar.
# g++ check_delete.cc -D_GLIBCXX_ASSERT -I.
# ./a.out
Assertion failed: bool(__gnu_test::check_delete()), file
check_delete.cc, line 48
Abort (core dumped)

The error is triggered by defining mt_allocator as the base class to
std::allocator in c++allocator.h. It could be gone by including c++allocator.h
in new/bits/ which define new_allocator as base class. 
# g++ check_delete.cc -D_GLIBCXX_ASSERT -I. -I./new
# ./a.out

We configured gcc 4.3.2 with --enable-libstdcxx-allocator=mt as well as other
options as below. 
# g++ -v
Using built-in specs.
Target: sparc-sun-solaris2.11
Configured with: /import/iropt5/lijuan/plain-gcc/gcc-4.3.2/configure
--prefix=/import/iropt5/lijuan/plain-gcc/compilers/gcc-4.3.2 --enable-shared
--disable-static --with-system-zlib --enable-checking=release
--enable-languages=c,c++ --disable-libobjc --with-cpu=v9
--with-ld=/usr/ccs/bin/ld --without-gnu-ld --with-as=/usr/ccs/bin/as
--without-gnu-as --disable-gnattools --enable-tls
--enable-libstdcxx-allocator=mt
Thread model: posix
gcc version 4.3.2 (GCC)
# uname -a
SunOS gccfss-v890-1 5.11 snv_111 sun4u sparc SUNW,Sun-Fire-V890

Please verify if it's a real bug in gcc or not. If you need any other
information, please let me know. Thanks.


-- 
   Summary: ext/throw_allocator/check_delete.cc execution abort with
mt_allocator
   Product: gcc
   Version: 4.3.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hailijuan at gmail dot com


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

[Bug c++/35652] [4.3 Regression] offset warning should be given in the front-end

[dcb314 at hotmail dot com]

--- Comment #29 from dcb314 at hotmail dot com  2009-04-15 07:41 ---
(In reply to comment #27)
> Noticed while building binutils (with -Werror):
> ../binutils-2.19.1/bfd/elf.c: In function '_bfd_elf_print_private_bfd_data':
> ../binutils-2.19.1/bfd/elf.c:1236: error: offset '2' outside bounds of 
> constant
> string

+1.

Various packages (eg gdb) use -Werror and so fail to build with 4.5
snapshot 20090409.

Would it be reasonable to switch off temporarily this warning message,
until it works more accurately ?


-- 


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

[Bug libstdc++/39775] ext/throw_allocator/check_delete.cc execution abort with mt_allocator

[hailijuan at gmail dot com]

--- Comment #1 from hailijuan at gmail dot com  2009-04-15 07:43 ---
Created an attachment (id=17642)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17642&action=view)
check_delete.cc and its header files.


-- 


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

[Bug c/39773] error: object with variably modified type must have no linkage

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-04-15 11:21 ---
Indeed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug testsuite/39776] New: FAIL: g++.dg/ext/altivec-15.C

[dominiq at lps dot ens dot fr]

Between revisions 145899 (working, may be also 145928) and 145941 (failing) the
test g++.dg/ext/altivec-15.C started to fail:

...
output is:
/opt/gcc/4.4-gcc-work/gcc/testsuite/g++.dg/ext/altivec-15.C:7: error: 'Float'
does not name a type^M
/opt/gcc/4.4-gcc-work/gcc/testsuite/g++.dg/ext/altivec-15.C:9: error: two or
more data types in declaration of 'SinCos'^M
/opt/gcc/4.4-gcc-work/gcc/testsuite/g++.dg/ext/altivec-15.C:9: error: 'Float'
was not declared in this scope^M
/opt/gcc/4.4-gcc-work/gcc/testsuite/g++.dg/ext/altivec-15.C:9: error: 'Float'
was not declared in this scope^M
/opt/gcc/4.4-gcc-work/gcc/testsuite/g++.dg/ext/altivec-15.C:9: error: 'sine'
was not declared in this scope^M
/opt/gcc/4.4-gcc-work/gcc/testsuite/g++.dg/ext/altivec-15.C:9: error: 'Float'
was not declared in this scope^M
/opt/gcc/4.4-gcc-work/gcc/testsuite/g++.dg/ext/altivec-15.C:9: error: 'cosine'
was not declared in this scope^M

PASS: g++.dg/ext/altivec-15.C  (test for errors, line 7)
PASS: g++.dg/ext/altivec-15.C  (test for errors, line 9)
FAIL: g++.dg/ext/altivec-15.C  (test for errors, line 11)
FAIL: g++.dg/ext/altivec-15.C  (test for errors, line 12)
PASS: g++.dg/ext/altivec-15.C (test for excess errors)

See 

http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg01094.html 

and 

http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg01098.html


-- 
   Summary: FAIL: g++.dg/ext/altivec-15.C
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
 GCC build triplet: powerpc*-*-*
  GCC host triplet: powerpc*-*-*
GCC target triplet: powerpc*-*-*


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

[Bug java/38374] constant pool references have wrong types in ADDR_EXPR

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2009-04-15 12:17 ---
I have a "fix".


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-04-15 12:17:01
   date||


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

[Bug fortran/39772] add a correctness check for the size intrinsic to -fbounds-check

[dfranke at gcc dot gnu dot org]

--- Comment #1 from dfranke at gcc dot gnu dot org  2009-04-15 12:30 ---


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


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug fortran/28105] Check for memory allocations bigger than size_t

[dfranke at gcc dot gnu dot org]

--- Comment #3 from dfranke at gcc dot gnu dot org  2009-04-15 12:30 ---
*** Bug 39772 has been marked as a duplicate of this bug. ***


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jv244 at cam dot ac dot uk


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

[Bug tree-optimization/39764] ICE in set_lattice_value, at tree-ssa-ccp.c:468 with -ffinite-math-only

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2009-04-15 12:31 ---
We drop back from CONSTANT (NaN) to UNDEFINED because of
canonicalize_float_value.

I have a fix.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2009-04-15 07:30:13 |2009-04-15 12:31:32
   date||


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

[Bug fortran/24404] Poor Error Description, bad error order

[dfranke at gcc dot gnu dot org]

--- Comment #6 from dfranke at gcc dot gnu dot org  2009-04-15 12:32 ---
Closing, see comment #5.


-- 

dfranke at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dfranke at gcc dot gnu dot
   ||org
 Status|NEW |RESOLVED
 Resolution||WONTFIX


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

[Bug libstdc++/39546] parallel mode doesn't support implicit string conversion

[paolo dot carlini at oracle dot com]

--- Comment #13 from paolo dot carlini at oracle dot com  2009-04-15 13:09 
---
Hi, and sorry about my delay. I think we should definitely resolve this in time
for 4.4.0.

I agree, the new proposed fix looks much better. Still, I must admit, there is
something I do not understand completely about this dispatching machinery, I'm
under the impression there is something ad-hoc about it and I'm not confident
we don't have other problems lurking somewhere... Want to look closer into it.
Benjamin, do you have an opinion?


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 CC||bkoz at redhat dot com


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

[Bug fortran/39772] add a correctness check for the size intrinsic to -fbounds-check

[jv244 at cam dot ac dot uk]

--- Comment #2 from jv244 at cam dot ac dot uk  2009-04-15 13:21 ---
not a duplicate of PR28105. The allocate is fine (on an x86_64).


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|DUPLICATE   |


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

[Bug libstdc++/39546] parallel mode doesn't support implicit string conversion

[paolo dot carlini at oracle dot com]

--- Comment #14 from paolo dot carlini at oracle dot com  2009-04-15 13:56 
---
Probably it's too late anyway for 4.4.0...


-- 


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

[Bug fortran/39772] add a correctness check for the size intrinsic to -fbounds-check

[kargl at gcc dot gnu dot org]

--- Comment #3 from kargl at gcc dot gnu dot org  2009-04-15 13:57 ---
(In reply to comment #2)
> not a duplicate of PR28105. The allocate is fine (on an x86_64).
> 

Actually, the entire program is fine.  But, it does not do
what you expected!  Try using your allocated array in something
other than SIZE().

INTEGER*8 :: N
INTEGER :: M
INTEGER, DIMENSION(:), ALLOCATABLE :: data
N=2_8**32
m = n
write(6,*) N, m
ALLOCATE(data(N))
write(6,*) SIZE(data,1)
data(1) = 1
ENDREMOVE:kargl[53] gfc4x -o z -fbounds-check d.f90
REMOVE:kargl[54] ./z
   4294967296   0
   0
At line 9 of file d.f90
Fortran runtime error: Array reference out of bounds for array 'data', upper
bound of dimension 1 exceeded (1 > 0)


-- 


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

[Bug testsuite/39776] FAIL: g++.dg/ext/altivec-15.C

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2009-04-15 13:59 ---
This started failing since PR28301, which has been committed to trunk/4.4/4.3.

I guess the last two dg-error comments should be nuked from this testcase.


-- 


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

[Bug tree-optimization/39764] ICE in set_lattice_value, at tree-ssa-ccp.c:468 with -ffinite-math-only

[rguenth at gcc dot gnu dot org]

--- Comment #4 from rguenth at gcc dot gnu dot org  2009-04-15 14:18 ---
Subject: Bug 39764

Author: rguenth
Date: Wed Apr 15 14:17:35 2009
New Revision: 146120

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146120
Log:
2009-04-15  Richard Guenther  

PR tree-optimization/39764
* tree-ssa-ccp.c (get_value): Canonicalize value with
canonicalize_float_value.

* g++.dg/torture/pr39764.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr39764.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-ccp.c


-- 


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

[Bug tree-optimization/39764] ICE in set_lattice_value, at tree-ssa-ccp.c:468 with -ffinite-math-only

[rguenth at gcc dot gnu dot org]

--- Comment #5 from rguenth at gcc dot gnu dot org  2009-04-15 14:23 ---
For some reason 4.3 and 4.4 work for me (though they definitely have the
same problem).


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

  Known to work||4.5.0


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

[Bug c++/39777] New: Template behaviour when a template class has a member template class deriving from its container

[pietro dot braione at polimi dot it]

The following C++ program aims to calculate the sum of some ints at compile
time:

//BEGINS SUM.CPP
template
class Sum { 
public:
enum { val = N };
template
class Inc : public Sum { };
};

int main() {
  return(Sum<2>::Inc<3>::Inc<6>::Inc<4>::val);
}
//ENDS SUM.CPP

Now GCC produces:

$ g++ sum.c
$ ./a.out ; echo $? 
6

More generally, every Sum::Inc::Inc::...::Inc::val is
always expanded to just x_0 + x_n. When compiled with Digital Mars C++ the same
example produces 15 as output (more generally, produces the sum of all the
provided integers as I would expect). 
Which is the right behaviour?

---
$ g++ -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ./gcc-4.3.3/configure
Thread model: posix
gcc version 4.3.3 (GCC)

I checked this example against a barebone, fresh 4.3.3 build with just gcc-core
and gcc-g++, gmp-4.2.1 and mpfr-2.3.0, all downloaded from a gcc mirror, fully
boostrapped with no options on a Gentoo distribuition. The same behaviour
occurs with a 4.1.2 GCC version on Gentoo and with a 3.4.4 GCC version on
Cygwin. The Digital Mars C++ compiler version I used is 8.50 for win32.


-- 
   Summary: Template behaviour when a template class has a member
template class deriving from its container
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pietro dot braione at polimi dot it
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug c++/39777] Template behaviour when a template class has a member template class deriving from its container

[pietro dot braione at polimi dot it]

--- Comment #1 from pietro dot braione at polimi dot it  2009-04-15 15:20 
---
Created an attachment (id=17643)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17643&action=view)
the example program


-- 


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

[Bug c++/39777] Template behaviour when a template class has a member template class deriving from its container

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2009-04-15 15:39 ---
The issue comes down to how is Inc injected into Inc.  I can't remember the
exact rules but I think GCC's behavior is correct.


-- 


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

[Bug c++/39778] New: Using DJGPP to compile CPP file and get failure

[darklingduck at gmail dot com]

C:\DJGPP\CPP>gcc -v
Using built-in specs.
Target: djgpp
Configured with: /v203/gcc-4.32/configure msdosdjgpp
Thread model: single
gcc version 4.3.2 (GCC)

C:\DJGPP\CPP>gcc PPID_update.cpp -o PPID_Update.exe -lm
gcc.exe: Internal error: (null) (program cc1plus)
Please submit a full bug report.
See  for instructions.


-- 
   Summary: Using DJGPP to compile CPP file and get failure
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: darklingduck at gmail dot com


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

[Bug c++/39778] Using DJGPP to compile CPP file and get failure

[darklingduck at gmail dot com]

--- Comment #1 from darklingduck at gmail dot com  2009-04-15 15:42 ---
I get the failure that I sent every time I try to compile the source file using
the command prompt or in rhide.


-- 


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

[Bug tree-optimization/39746] [4.5 Regression] Fail pr34513.c and pr34513.C at -O1 and above

[danglin at gcc dot gnu dot org]

--- Comment #9 from danglin at gcc dot gnu dot org  2009-04-15 16:01 ---
This regression was introduced by the following change:

2009-04-07  Richard Guenther  

* tree-ssa-alias.c (ref_maybe_used_by_call_p_1): Non-aliased
decls are only used if passes as parameters or if they are
local statics and the call is not to a builtin.
(call_may_clobber_ref_p_1): Likewise.


-- 

danglin at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenther at suse dot de
  Component|libgomp |tree-optimization


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

[Bug tree-optimization/39746] [4.5 Regression] Fail pr34513.c and pr34513.C at -O1 and above

[rguenth at gcc dot gnu dot org]

--- Comment #10 from rguenth at gcc dot gnu dot org  2009-04-15 16:19 
---
Hmm, are you sure that revision is the cause?  What happens is that the
variable thrs is appearantly a translation-unit local constant variable
with a constant initializer of 4.  CCP looks that up via
get_symbol_constant_value
and propagates it.

Indeed the testcase has

static int thrs = 4;

and thrs is never written to so ipa-reference marks it constant.

The test changes to

  if (shrd.1_3 != 4)

maybe you are looking for a different pass then?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 CC|rguenther at suse dot de|rguenth at gcc dot gnu dot
   ||org


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

[Bug fortran/39772] add a correctness check for the size intrinsic to -fbounds-check

[jv244 at cam dot ac dot uk]

--- Comment #4 from jv244 at cam dot ac dot uk  2009-04-15 17:03 ---
> But, it does not do
> what you expected!  Try using your allocated array in something
> other than SIZE().

It's doing exactly what I expect... including the size intrinsic returning a
garbage result because it returns a default integer.

> cat test.f90
INTEGER*8 :: N
INTEGER, DIMENSION(:), ALLOCATABLE :: data
N=2_8**32
write(6,*) N
ALLOCATE(data(N))
data(1:N)=0
write(6,*) SIZE(data,1)
END
> gfortran -O2 -fbounds-check test.f90
> ./a.out
   4294967296
   0


-- 


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

[Bug c++/39777] Template behaviour when a template class has a member template class deriving from its container

[paolo dot carlini at oracle dot com]

--- Comment #3 from paolo dot carlini at oracle dot com  2009-04-15 17:04 
---
For the record, the Intel compiler - which I trust much more than DM, sorry -
behaves the same as GCC. I strongly believe GCC is correct. I even think we
have something closed about this issue, let me see if I find it...


-- 


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

[Bug fortran/39772] add a correctness check for the size intrinsic to -fbounds-check

[kargl at gcc dot gnu dot org]

--- Comment #5 from kargl at gcc dot gnu dot org  2009-04-15 17:43 ---
(In reply to comment #4)
> > But, it does not do
> > what you expected!  Try using your allocated array in something
> > other than SIZE().
> 
> It's doing exactly what I expect... including the size intrinsic returning a
> garbage result because it returns a default integer.
> 
> > cat test.f90
> INTEGER*8 :: N
> INTEGER, DIMENSION(:), ALLOCATABLE :: data
> N=2_8**32
> write(6,*) N
> ALLOCATE(data(N))
> data(1:N)=0
> write(6,*) SIZE(data,1)
> END
> > gfortran -O2 -fbounds-check test.f90
> > ./a.out
>4294967296
>0
> 

Damn.  I was in the wrong xterm, which was a i686 system
not my usual x86_64.  I looked at the wrong dump.  You're
correct that size is doing something stupid.  From the
dump

logical(kind=4) D.1539;<-- This wrong.
integer(kind=8) size.2;
integer(kind=8) D.1537;

data.dtype = 265;
data.dim[0].lbound = 1;
data.dim[0].ubound = n;
data.dim[0].stride = 1;
D.1537 = NON_LVALUE_EXPR >;
D.1539 = NON_LVALUE_EXPR  <= 0;   <--- because this triggers
if (D.1539)  <--- this.
  {
size.2 = 0;
  }


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-04-15 17:43:49
   date||


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

[Bug c++/39551] C++ frontend not warn about unused dereference operator with -Wunused-value

[lcwu at gcc dot gnu dot org]

--- Comment #1 from lcwu at gcc dot gnu dot org  2009-04-15 17:56 ---
Subject: Bug 39551

Author: lcwu
Date: Wed Apr 15 17:55:50 2009
New Revision: 146132

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146132
Log:
PR c++/39551
* gcc/cp/call.c (build_over_call): Set TREE_NO_WARNING on the
compiler-generated INDIRECT_REF expression.
* gcc/cp/cvt.c (convert_to_void): Emit warning when stripping off
INDIRECT_REF.
* gcc/testsuite/g++.dg/warn/Wunused-13.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wunused-13.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/cvt.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug tree-optimization/39746] [4.5 Regression] Fail pr34513.c and pr34513.C at -O1 and above

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca  2009-04-15 
17:56 ---
Subject: Re:  [4.5 Regression] Fail pr34513.c and pr34513.C at -O1 and above

> Hmm, are you sure that revision is the cause?  What happens is that the

No, but it exposed the problem.

> static int thrs = 4;
> 
> and thrs is never written to so ipa-reference marks it constant.
> 
> The test changes to
> 
>   if (shrd.1_3 != 4)
> 
> maybe you are looking for a different pass then?

Looking again, it's not clear why the test fails.  errors ends up at 3.

Dave


-- 


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

[Bug c++/39551] C++ frontend not warn about unused dereference operator with -Wunused-value

[lcwu at gcc dot gnu dot org]

--- Comment #2 from lcwu at gcc dot gnu dot org  2009-04-15 18:03 ---
The fix for this bug was committed at revision 146132.


-- 

lcwu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug c/38688] __sync_lock_test_and_set does not actually lock

[jb at gcc dot gnu dot org]

--- Comment #4 from jb at gcc dot gnu dot org  2009-04-15 19:38 ---
Subject: Bug 38688

Author: jb
Date: Wed Apr 15 19:38:32 2009
New Revision: 146134

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146134
Log:
2009-04-15  Janne Blomqvist  

PR libfortran/38688
* io/transfer.c (finalize_transfer): Don't flush for advance='no'.


Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/transfer.c


-- 


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

[Bug c/38688] __sync_lock_test_and_set does not actually lock

[jb at gcc dot gnu dot org]

--- Comment #5 from jb at gcc dot gnu dot org  2009-04-15 19:42 ---
Er, sorry, wrong PR in the ChangeLog.


-- 


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

[Bug libfortran/38668] advance="no": no buffering, truncate and seek

[jb at gcc dot gnu dot org]

--- Comment #4 from jb at gcc dot gnu dot org  2009-04-15 19:46 ---
Fixed in trunk as r146134 & r146135.


-- 

jb at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c

[jingyu at google dot com]

--- Comment #1 from jingyu at google dot com  2009-04-15 20:41 ---
I have observed the same error on
host: x86_64-linux-gnu and i686-linux-gnu
target: arm-unknown-eabi

Executing on host: /usr/local/google/tmp/gcc4.4_dejagnu/obj/gcc-4.4/gcc/xgcc
-B/usr/local/google/tmp/gcc4.4_dejagnu/obj/gcc-4.4/gcc/
/usr/local/google/nightly/sources/arm_toolchain/gcc-4.4/gcc/testsuite/gcc.dg/uninit-13-O0.c
  -Wuninitialized -DSTACK_SIZE=16384 -S-o uninit-13-O0.s(timeout = 800)
XFAIL: gcc.dg/uninit-13-O0.c unconditional (test for warnings, line 8)
PASS: gcc.dg/uninit-13-O0.c (test for excess errors)
Executing on host: /usr/local/google/tmp/gcc4.4_dejagnu/obj/gcc-4.4/gcc/xgcc
-B/usr/local/google/tmp/gcc4.4_dejagnu/obj/gcc-4.4/gcc/
/usr/local/google/nightly/sources/arm_toolchain/gcc-4.4/gcc/testsuite/gcc.dg/uninit-13.c
  -O -Wuninitialized -DSTACK_SIZE=16384 -S-o uninit-13.s(timeout = 800)
/usr/local/google/nightly/sources/arm_toolchain/gcc-4.4/gcc/testsuite/gcc.dg/uninit-13.c:
In function 'foo':
/usr/local/google/nightly/sources/arm_toolchain/gcc-4.4/gcc/testsuite/gcc.dg/uninit-13.c:7:
warning: '__real__ f' is used uninitialized in this function
output is:
/usr/local/google/nightly/sources/arm_toolchain/gcc-4.4/gcc/testsuite/gcc.dg/uninit-13.c:
In function 'foo':
/usr/local/google/nightly/sources/arm_toolchain/gcc-4.4/gcc/testsuite/gcc.dg/uninit-13.c:7:
warning: '__real__ f' is used uninitialized in this function

FAIL: gcc.dg/uninit-13.c unconditional (test for warnings, line 8)
FAIL: gcc.dg/uninit-13.c (test for excess errors)
Excess errors:
/usr/local/google/nightly/sources/arm_toolchain/gcc-4.4/gcc/testsuite/gcc.dg/uninit-13.c:7:
warning: '__real__ f' is used uninitialized in this function


$arm-eabi-gcc -v
Using built-in specs.
Target: arm-eabi
Configured with:
/usr/local/google/nightly/sources/arm_toolchain/gcc-4.4/configure
--prefix=/usr/local/google/tmp/gcc4.4_dejagnu/install --target=arm-eabi
--build=x86_64-linux-gnu --host=x86_64-linux-gnu
--with-gmp=/usr/local/google/tmp/gcc4.4_dejagnu/install
--with-mpfr=/usr/local/google/tmp/gcc4.4_dejagnu/install --enable-multilib
--with-newlib --with-gnu-as --with-gnu-ld --enable-languages=c,c++
Thread model: single
gcc version 4.4.0 20090415 (prerelease) (GCC)


-- 

jingyu at google dot com changed:

   What|Removed |Added

 CC||jingyu at google dot com


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

[Bug rtl-optimization/39762] [4.4/4.5 Regression] IRA ICE with -msoft-float

[vmakarov at redhat dot com]

--- Comment #1 from vmakarov at redhat dot com  2009-04-15 21:49 ---
The compiler is broken in IRA on this test because ira_register_move_cost is
not initialized for DFmode, AREG, GENERAL_REGS.

It is supposed that all necessary elements of this array are initialized in
ira-costs.c by ira_init_register_move_cost but it was not done for this mode
and reg classes for some reasons.  I think that the elements should be checked
for initialization every time when we need their values.  It would be a tiny
performance penalty but it will guarantee that such situation will be not
occurred anymore.

I'll send a patch soon.


-- 


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

[Bug c/31499] rejects vector int a[] = {1,1,1,1,1};

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2009-04-15 22:11 ---
Testing a fix for this.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pinskia at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2009-04-15 22:11:19
   date||


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

[Bug c/39779] New: ICE shifting byte to the right with constant > 7FFFFFFF

[bjoern at hoehrmann dot de]

% gcc --version
gcc (Debian 4.3.3-7) 4.3.3
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

% cat gcc4-bug.c
#include 
int main(void) { 
  uint8_t v1 = 0;
  v1>>=0xdebecced;
}

% gcc gcc4-bug.c
gcc4-bug.c: In function 'main':
gcc4-bug.c:5: warning: right shift count >= width of type
gcc4-bug.c:6: error: unrecognizable insn:
(insn 7 6 8 3 gcc4-bug.c:5 (set (reg:QI 60)
(const_int -557921043 [0xdebecced])) -1 (nil))
gcc4-bug.c:6: internal compiler error: in extract_insn, at recog.c:2001
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: ICE shifting byte to the right with constant > 7FFF
   Product: gcc
   Version: 4.3.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bjoern at hoehrmann dot de


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

[Bug c/39780] New: internal compiler error: Segmentation fault

[kuchen_ at gmx dot de]

$ uname -a
MINGW32_NT-6.0 *** 1.0.11(0.46/3/2) 2007-01-12 12:05 i686 Msys

$ gcc -v
Using built-in specs.
Target: i586-elf
Configured with: ../gcc-4.3.3/configure --target=i586-elf --prefix=/mingw/cross
--disable-nls --enable-languages=c,c++ --without-headers
Thread model: single
gcc version 4.3.3 (GCC) 

Calling gcc with the following command:
gcc -Iinclude -Iinclude/arch/i386 -Ikernel/include -O3 -static -c -g
-ffreestanding -nostdlib -nostartfiles -nodefaultlibs -Wall -o virt.o
kernel/mm/virt.c

Results in following error message:
kernel/mm/virt.c: In function 'vm_find_addr':
kernel/mm/virt.c:465: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 
   Summary: internal compiler error: Segmentation fault
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kuchen_ at gmx dot de
  GCC host triplet: i686-pc-mingw
GCC target triplet: i586-elf


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

[Bug c/39780] internal compiler error: Segmentation fault

[kuchen_ at gmx dot de]

--- Comment #1 from kuchen_ at gmx dot de  2009-04-15 22:48 ---
Created an attachment (id=17645)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17645&action=view)
The preprocessed source file


-- 


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

[Bug target/39758] FAIL: gcc.dg/initpri1.c, g++.dg/special/initpri1.C on arm target

[jingyu at google dot com]

--- Comment #3 from jingyu at google dot com  2009-04-15 23:35 ---
GCC puts destructors in .fini_array section in increasing order, and expects
linker executes entries in .fini_array in reverse order (according to ELF
specification). However, newlib executes entries in .fini_array in increase
order. 
This may be a bug in newlib.

Filed an issue in newlib mailing list.
http://sourceware.org/ml/newlib/2009/msg00466.html

Close this issue since it is not a problem of GCC.


-- 

jingyu at google dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug target/39758] FAIL: gcc.dg/initpri1.c, g++.dg/special/initpri1.C on arm target

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2009-04-15 23:43 ---
(In reply to comment #3)
> Filed an issue in newlib mailing list.
> http://sourceware.org/ml/newlib/2009/msg00466.html

newlib does have a bugzilla, located http://sourceware.org/bugzilla/, though
not many people use it.


-- 


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

[Bug bootstrap/34818] --with-gmp overrides --with-mpfr

[ghazi at gcc dot gnu dot org]

--- Comment #2 from ghazi at gcc dot gnu dot org  2009-04-16 01:05 ---
Where on your system is the "ancient" mpfr located?  Is it in the /sw
directory?
(In reply to comment #0)
> From fink, I have gmp 4.1 in /sw/{lib,include}, but mpfr is ancient.  I put a
> new mpfr in $HOME, and tried to build with:
> [...]
> In other words, it's possible to update gmp and use the system mpfr, but not 
> to
> update mpfr and use the system gmp.

Where on your system the "ancient" mpfr located?  Is it in the /sw directory? 
If so, why are you calling it the "system mpfr"?  Does gcc search the /sw
directory by default like /usr/include & /usr/lib?


-- 

ghazi at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ghazi at gcc dot gnu dot org


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

[Bug testsuite/39781] New: Fail: g++.dg/cpp/_Pragma1.C, gcc.dg/cpp/_Pragma6.c

[jingyu at google dot com]

These two tests require that platform supports pragma pack(push).

For example, gcc.dg/cpp_Pragma6.c:
/* PR c/27747 */
/* This is supposed to succeed only if
   the target defines HANDLE_PRAGMA_PACK_PUSH_POP
   and doesn't define HANDLE_PRAGMA_PACK_WITH_EXPANSION.  */
/* { dg-do compile { target { ! { powerpc-ibm-aix* *-*-solaris2* fido-*-*
m68k-*-* sh*-[us]*-elf m32c-*-* } } } } */

#define push bar
#define foo _Pragma ("pack(push)")
foo
int i;
#pragma pack(pop)

However, config/arm does not define "HANDLE_PRAGMA_PACK_PUSH_POP". So GCC gives
the following warning which breaks the dejaGNU test.
  "warning: #pragma pack(push[, id], ) is not supported on this target"

The same failure is also observed on the report:
http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg01473.html

Suggest to filter arm-*-* out of the test target list.

$arm-eabi-gcc -v
Using built-in specs.
Target: arm-eabi
Configured with:
/usr/local/google/nightly/sources/arm_toolchain/gcc-4.4/configure
--prefix=/usr/local/google/tmp/gcc4.4_dejagnu/install --target=arm-eabi
--build=x86_64-linux-gnu --host=x86_64-linux-gnu
--with-gmp=/usr/local/google/tmp/gcc4.4_dejagnu/install
--with-mpfr=/usr/local/google/tmp/gcc4.4_dejagnu/install --enable-multilib
--with-newlib --with-gnu-as --with-gnu-ld --enable-languages=c,c++
Thread model: single
gcc version 4.4.0 20090415 (prerelease) (GCC)


-- 
   Summary: Fail: g++.dg/cpp/_Pragma1.C, gcc.dg/cpp/_Pragma6.c
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jingyu at google dot com
 GCC build triplet: x86_64-linux-gnu, i686-linux-gnu
  GCC host triplet: x86_64-linux-gnu, i686-linux-gnu
GCC target triplet: arm-unknown-eabi


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

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

[dannysmith at users dot sourceforge dot net]

--- Comment #53 from dannysmith at users dot sourceforge dot net  
2009-04-16 02:59 ---
This thread is alos relevant.
http://gcc.gnu.org/ml/gcc/2009-04/msg00462.html
Adding Dave Korn to cc:


-- 

dannysmith at users dot sourceforge dot net changed:

   What|Removed |Added

 CC||dave dot korn dot cygwin at
   ||gmail dot com


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

[Bug target/39717] [cond-optab] CSE does not put subregs into COMPAREs on many CC0 machines

[hp at gcc dot gnu dot org]

--- Comment #1 from hp at gcc dot gnu dot org  2009-04-16 03:08 ---
Is this a cond-optab regression or "just" an observation?


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hp at gcc dot gnu dot org


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

[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr

[sebastian dot wenzler at hp dot com]

--- Comment #9 from sebastian dot wenzler at hp dot com  2009-04-16 06:40 
---
I had the same problem with Solaris 10 on sparcv9 with gcc-4.3.3.

Environment:
 1) binutils/2.15 2) bison/1.875   3) automake/1.4-p5 4) gcc/4.2.4

LD_RUN_PATH=/local/scratch/xhpsewe/424-64bit/lib/sparcv9:/local/scratch/xhpsewe/424-64bit/lib
PATH=/app/automake/1.4-p5/bin:/app/bison/1.875/bin:/app/binutils/2.15/bin:/local/scratch/xhpsewe/424-64bit/bin

~/gcc-4.3.3/configure --prefix /local/scratch/xhpsewe/gcc433-64bit
--enable-languages=c,c++ --with-gmp=/app/gmp/4.2.4 --with-mpfr=/app/mpfr/2.4.0
sparcv9-sun-solaris2.10

After applying the patch (2009-03-23 18:42) I get 

make: Fatal error in reader: Makefile, line 51: Unexpected end of line seen
Current working directory
/local/scratch/builddir/build-sparcv9-sun-solaris2.10/fixincludes
*** Error code 1
The following command caused the error:
r=`${PWDCMD-pwd}`; export r; \
s=`cd /home/xhpsewe/gcc-4.3.3; ${PWDCMD-pwd}`; export s; \
FLEX="/home/xhpsewe/gcc-4.3.3/missing flex"; export FLEX;  LEX="lex"; export
LEX; BISON="bison"; export BISON;  YACC="bison -y"; export YACC;  M4="m4";
export M4;  MAKEINFO="/home/xhpsewe/gcc-4.3.3/missing makeinfo
--split-size=500 --split-size=500"; export MAKEINFO;  AR="ar"; export
AR;  AS="as"; export AS;  CC="sparcv9-sun-solaris2.10-gcc"; export CC; 
CFLAGS="-g -O2"; export CFLAGS;  CONFIG_SHELL="/bin/bash"; export CONFIG_SHELL;
 CXX="sparcv9-sun-solaris2.10-g++"; export CXX;  CXXFLAGS="-g -O2"; export
CXXFLAGS;  GCJ=""; export GCJ;  GFORTRAN=""; export GFORTRAN; 
DLLTOOL="dlltool"; export DLLTOOL;  LD="/usr/ccs/bin/ld"; export LD; 
LDFLAGS=""; export LDFLAGS;  NM="nm"; export NM;  RANLIB="ranlib"; export
RANLIB;  WINDRES="windres"; export WINDRES;  WINDMC="windmc"; export WINDMC; \
(cd build-sparcv9-sun-solaris2.10/fixincludes && \
  make   all)
make: Fatal error: Command failed for target `all-build-fixincludes'
Current working directory /local/scratch/builddir
*** Error code 1
The following command caused the error:
r=`${PWDCMD-pwd}`; export r; \
s=`cd /home/xhpsewe/gcc-4.3.3; ${PWDCMD-pwd}`; export s; \
if test -f stage1-lean  ; then \
  echo Skipping rebuild of stage1 ; \
else \
  make stage1-start; \


-- 


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