[Bug fortran/37131] inline matmul for small matrix sizes

[paul dot richard dot thomas at gmail dot com]

--- Comment #10 from paul dot richard dot thomas at gmail dot com  
2010-06-05 06:55 ---
Subject: Re:  inline matmul for small matrix sizes

Dear Thomas,


> The preferred way would therefore be to state the rank 2 * rank 2 problem as
>
>  do i=1,m
>     do j=1,n
>        c(i,j) = sum(a(i,:) * b(:,j))
>     end do
>  end do
>
> with the inner dot product borrowed using the scalarizer (borrowing
> from dot_product), and the outer loops using either hand-crafted
> TREE code or calling the DO translation.

Yes that is reasonable.  Otherwise, you could borrow a little trick
that I used in allocatable components: trans-array.c:6020

  gfc_add_expr_to_block (&loopbody, tmp);

  /* Build the loop and return.  */
  gfc_init_loopinfo (&loop);
  loop.dimen = 1;
  loop.from[0] = gfc_index_zero_node;
  loop.loopvar[0] = index;
  loop.to[0] = nelems;
  gfc_trans_scalarizing_loops (&loop, &loopbody);
  gfc_add_block_to_block (&fnblock, &loop.pre);

  tmp = gfc_finish_block (&fnblock);
  if (null_cond != NULL_TREE)
tmp = build3_v (COND_EXPR, null_cond, tmp,
build_empty_stmt (input_location));

Here tmp in the first line is the expression or finished block within
the loop.  Earlier on, you will find an expression involving the
index.

Cheers

Paul


-- 


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

[Bug libstdc++/43918] gcc 4.5.0 is failing for i586-pc-msdosdjgpp

[andris dot pavenis at iki dot fi]

--- Comment #9 from andris dot pavenis at iki dot fi  2010-06-05 06:38 
---
Did some tests

Using my own patches (for libstdc++-v3 only error_constants.h and
autoconf/automake related stuff left over from earlier native builds of gcc for
DJGPP) build of Linux (x86_64, Fedora 12) to DJGPP cross-compiler went through
without errors when I left building Ada cross-compiler out.

However make install DESTDIR=... failed in libstdc++v3/python. It seems that
DESTDIR somewhere did not reach target.

make[4]: Nothing to be done for `install-data-am'.
make[4]: Leaving directory
`/home/andris/Build/rpm-root/BUILD/djcross-gcc-4.5.0/djcross/i586-pc-msdosdjgpp/libstdc++-v3/src'
make[3]: Leaving directory
`/home/andris/Build/rpm-root/BUILD/djcross-gcc-4.5.0/djcross/i586-pc-msdosdjgpp/libstdc++-v3/src'
Making install in po
make[3]: Entering directory
`/home/andris/Build/rpm-root/BUILD/djcross-gcc-4.5.0/djcross/i586-pc-msdosdjgpp/libstdc++-v3/po'
make[4]: Entering directory
`/home/andris/Build/rpm-root/BUILD/djcross-gcc-4.5.0/djcross/i586-pc-msdosdjgpp/libstdc++-v3/po'
make[4]: Nothing to be done for `install-exec-am'.
make[4]: Nothing to be done for `install-data-am'.
make[4]: Leaving directory
`/home/andris/Build/rpm-root/BUILD/djcross-gcc-4.5.0/djcross/i586-pc-msdosdjgpp/libstdc++-v3/po'
make[3]: Leaving directory
`/home/andris/Build/rpm-root/BUILD/djcross-gcc-4.5.0/djcross/i586-pc-msdosdjgpp/libstdc++-v3/po'
Making install in testsuite
make[3]: Entering directory
`/home/andris/Build/rpm-root/BUILD/djcross-gcc-4.5.0/djcross/i586-pc-msdosdjgpp/libstdc++-v3/testsuite'
make[4]: Entering directory
`/home/andris/Build/rpm-root/BUILD/djcross-gcc-4.5.0/djcross/i586-pc-msdosdjgpp/libstdc++-v3/testsuite'
make[4]: Nothing to be done for `install-exec-am'.
make[4]: Nothing to be done for `install-data-am'.
make[4]: Leaving directory
`/home/andris/Build/rpm-root/BUILD/djcross-gcc-4.5.0/djcross/i586-pc-msdosdjgpp/libstdc++-v3/testsuite'
make[3]: Leaving directory
`/home/andris/Build/rpm-root/BUILD/djcross-gcc-4.5.0/djcross/i586-pc-msdosdjgpp/libstdc++-v3/testsuite'
Making install in python
make[3]: Entering directory
`/home/andris/Build/rpm-root/BUILD/djcross-gcc-4.5.0/djcross/i586-pc-msdosdjgpp/libstdc++-v3/python'
make[4]: Entering directory
`/home/andris/Build/rpm-root/BUILD/djcross-gcc-4.5.0/djcross/i586-pc-msdosdjgpp/libstdc++-v3/python'
make[4]: Nothing to be done for `install-exec-am'.
 /usr/bin/install -c -m 644 gdb.py
/home/andris/Build/rpm-root/BUILDROOT/djcross-gcc-4.5.0-1ap.x86_64/usr/lib64/gcc/i586-pc-msdosdjgpp/4.5.0/libstdc++.a-gdb.py
test -z "/usr/share/gcc-4.5.0/python" || /bin/mkdir -p
"/usr/share/gcc-4.5.0/python"
/bin/mkdir: cannot create directory `/usr/share/gcc-4.5.0': Permission denied
make[4]: *** [install-nobase_pythonDATA] Error 1
make[4]: Leaving directory
`/home/andris/Build/rpm-root/BUILD/djcross-gcc-4.5.0/djcross/i586-pc-msdosdjgpp/libstdc++-v3/python'
make[3]: *** [install-am] Error 2
make[3]: Leaving directory
`/home/andris/Build/rpm-root/BUILD/djcross-gcc-4.5.0/djcross/i586-pc-msdosdjgpp/libstdc++-v3/python'
make[2]: *** [install-recursive] Error 1
make[2]: Leaving directory
`/home/andris/Build/rpm-root/BUILD/djcross-gcc-4.5.0/djcross/i586-pc-msdosdjgpp/libstdc++-v3'
make[1]: *** [install-target-libstdc++-v3] Error 2
make[1]: Leaving directory
`/home/andris/Build/rpm-root/BUILD/djcross-gcc-4.5.0/djcross'
make: *** [install] Error 2
virhe: Bad exit status from /home/andris/Build/rpm-root/tmp/rpm-tmp.KgV52m
(%install)



-- 


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

[Bug c++/44422] New: shift is modulo data size

[chrismaple at mcttelecom dot com]

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ./configure
Thread model: posix
gcc version 4.5.0 (GCC) 

Using C++, shifting unsigned integers
uint64_t x;
x=x>>65;   //produces same result as x=x>>1
uint32_t y;
y=y>>34;   //produces same result as y=y>>2
If the shift is a literal, the compiler warns, otherwise there is no warning.

I don't know if this is actually a bug, or if it's acceptable behavior. If
it's acceptable, I'd like to see a compiler command-line option or some other
way to make shifts >= the data size return zero.


-- 
   Summary: shift is modulo data size
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chrismaple at mcttelecom dot com


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

[Bug bootstrap/44421] [4.6 Regression] Failed to bootstrap

[hjl at gcc dot gnu dot org]

--- Comment #2 from hjl at gcc dot gnu dot org  2010-06-05 00:49 ---
Subject: Bug 44421

Author: hjl
Date: Sat Jun  5 00:48:49 2010
New Revision: 160305

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160305
Log:
Update df_lr_bb_local_compute for embedded bitmaps.

2010-06-04  H.J. Lu  

PR boostrap/44421
* df-problems.c (df_lr_bb_local_compute): Updated for embedded
bitmaps.
(df_byte_lr_bb_local_compute): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/df-problems.c


-- 


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

[Bug bootstrap/44421] [4.6 Regression] Failed to bootstrap

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2010-06-05 00:39 ---
It affects targets which define EH_USES:

ia64/ia64.h:#define EH_USES(REGNO) ia64_eh_uses (REGNO)
m32c/m32c.h:#define EH_USES(REGNO) 0   /* FIXME */
mips/mips.h:#define EH_USES(N) mips_eh_uses (N)


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0


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

[Bug bootstrap/44421] New: [4.6 Regression] Failed to bootstrap

[hjl dot tools at gmail dot com]

On Linux/ia64, revision 160300 gave:

../../src-trunk/gcc/df-problems.c: In function 'df_lr_bb_local_compute':
../../src-trunk/gcc/df-problems.c:906: error: incompatible type for argument 1
of 'bitmap_set_bit'
../../src-trunk/gcc/df-problems.c: In function 'df_byte_lr_bb_local_compute':
../../src-trunk/gcc/df-problems.c:2715: error: incompatible type for argument 1
of 'bitmap_set_range'

Revision 160263 is OK.


-- 
   Summary: [4.6 Regression] Failed to bootstrap
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug tree-optimization/43529] G++ doesn't optimize away empty loop when index is a double

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2010-06-05 00:05 ---
>Interesting! What's the difference between 17 and 18?

Exact representation.


-- 


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

[Bug c++/44328] switch/case optimization produces an invalid lookup table index

[eblot dot ml at gmail dot com]

--- Comment #4 from eblot dot ml at gmail dot com  2010-06-04 23:41 ---
(fixing up description)


-- 

eblot dot ml at gmail dot com changed:

   What|Removed |Added

Summary|switch/case optimization|switch/case optimization
   |produces an invalid jump|produces an invalid lookup
   |table index |table index


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

[Bug tree-optimization/43529] G++ doesn't optimize away empty loop when index is a double

[changpeng dot fang at amd dot com]

--- Comment #3 from changpeng dot fang at amd dot com  2010-06-04 23:29 
---
(In reply to comment #2)
> Interesting! What's the difference between 17 and 18?
> 
> int main()
> {
>   double i;
>   for(i=0; i<18; i+=1); /* gcc -O3, empty loop not removed */
> }


The funny thing occurs in gcc 4, not gcc 6:

.file   "empty.c"
.text
.p2align 4,,15
.globl main
.type   main, @function
main:
.LFB0:
.cfi_startproc
xorl%eax, %eax
.p2align 4,,10
.p2align 3
.L2:
addl$1, %eax
cmpl$18, %eax
jne .L2
rep
ret
.cfi_endproc
.LFE0:
.size   main, .-main
.ident  "GCC: (Ubuntu 4.4.1-4ubuntu9) 4.4.1"
.section.note.GNU-stack,"",@progbits


-- 


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

[Bug tree-optimization/43529] G++ doesn't optimize away empty loop when index is a double

[changpeng dot fang at amd dot com]

--- Comment #2 from changpeng dot fang at amd dot com  2010-06-04 23:15 
---
Interesting! What's the difference between 17 and 18?

int main()
{
  double i;
  for(i=0; i<18; i+=1); /* gcc -O3, empty loop not removed */
}

int main()
{
  double i;
  for(i=0; i<17; i+=1); /* gcc -O3, empty loop removed */
}


-- 

changpeng dot fang at amd dot com changed:

   What|Removed |Added

 CC||changpeng dot fang at amd
   ||dot com


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

[Bug fortran/44235] array temporary with high upper bound

[tkoenig at gcc dot gnu dot org]

--- Comment #1 from tkoenig at gcc dot gnu dot org  2010-06-04 22:39 ---
The particular test case from comment #1 is now fixed.

Here's one that still fails:

subroutine foo(a, b)
  real :: a(40), b(40)
  a(1:20:3) = a(1:19:3)
  a(1:19:3) = a(1:19:3)
end subroutine foo

g...@linux-fd1f:/tmp> gfortran -Warray-temporaries -S dep2.f90
dep2.f90:3.14:

  a(1:20:3) = a(1:19:3)
  1
Warning: Creating array temporary at (1)


-- 


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

[Bug fortran/37131] inline matmul for small matrix sizes

[tkoenig at gcc dot gnu dot org]

--- Comment #9 from tkoenig at gcc dot gnu dot org  2010-06-04 22:31 ---
I have thought a little bit about this, and the problem is
a bit daunting ;-)  Of course, this is at least partly because
my experience with the scalarizer is close to non-existant, but you
have to learn sometime.

It seems that the functions for scalarizing do not help a lot
here, because (for example) we need three nested loops for implementing
the case where a and b are of rank 2.

The preferred way would therefore be to state the rank 2 * rank 2 problem as

  do i=1,m
 do j=1,n
c(i,j) = sum(a(i,:) * b(:,j))
 end do
  end do

with the inner dot product borrowed using the scalarizer (borrowing
from dot_product), and the outer loops using either hand-crafted
TREE code or calling the DO translation.

Comments?  Is this reasonable?


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pault at gcc dot gnu dot org


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

[Bug middle-end/44420] New: [feature request] Warn for certain integer overflows

[fm3 at os dot inf dot tu-dresden dot de]

This is a follow-up to http://gcc.gnu.org/ml/gcc-help/2010-06/msg5.html :

Consider the following case:

  uint32_t foo, bar;
  ...
  foo = bar << 20;

Of course, this operation can overflow and warning about this probably does not
make sense as the programmer should be aware of this case. However, a warning
in the following case could be appropriate IMO:

  uint32_t bar;
  uint64_t foo;
  ...
  foo = bar << 20;

The intension is to catch the overflow case, therefore the assignment to a
64-bit variable. The intended code would be

  uint32_t bar;
  uint64_t foo;
  ...
  foo = (uint64_t)bar << 20;

I think it would be a big help if gcc could warn in the 2nd case.


-- 
   Summary: [feature request] Warn for certain integer overflows
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fm3 at os dot inf dot tu-dresden dot de


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

[Bug c/44419] New: ICE when building for Freescale e500v2

[edmar at freescale dot com]

When building gcc for e500v2:
--target=powerpc-unknown-linux-gnuspe --enable-e500_double

The build stops with an ICE:

/tmp/edmar/build_jobs/Xe500v2/obj_gccsys/./gcc/xgcc
-B/tmp/edmar/build_jobs/Xe500v2/obj_gccsys/./gcc/
-B/tmp/edmar/build_jobs/installs_final/gnu-gcc-4.5-binutils-2.19-eglibc-2.9-Xe500v2-powerpc-unknown-linux-gnuspe/i686-pc-linux2.4/powerpc-unknown-linux-gnuspe/bin/
-B/tmp/edmar/build_jobs/installs_final/gnu-gcc-4.5-binutils-2.19-eglibc-2.9-Xe500v2-powerpc-unknown-linux-gnuspe/i686-pc-linux2.4/powerpc-unknown-linux-gnuspe/lib/
-isystem
/tmp/edmar/build_jobs/installs_final/gnu-gcc-4.5-binutils-2.19-eglibc-2.9-Xe500v2-powerpc-unknown-linux-gnuspe/i686-pc-linux2.4/powerpc-unknown-linux-gnuspe/include
-isystem
/tmp/edmar/build_jobs/installs_final/gnu-gcc-4.5-binutils-2.19-eglibc-2.9-Xe500v2-powerpc-unknown-linux-gnuspe/i686-pc-linux2.4/powerpc-unknown-linux-gnuspe/sys-include-g
-O2 -O2  -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include  -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED  -mlong-double-128 -I. -I. -I../.././gcc
-I../../../src_gcc/libgcc -I../../../src_gcc/libgcc/.
-I../../../src_gcc/libgcc/../gcc -I../../../src_gcc/libgcc/../include 
-DHAVE_CC_TLS  -o _powixf2.o -MT _powixf2.o -MD -MP -MF _powixf2.dep
-DL_powixf2 -c ../../../src_gcc/libgcc/../gcc/libgcc2.c \
  -fvisibility=hidden -DHIDE_EXPORTS
../../../src_gcc/libgcc/../gcc/libgcc2.c: In function '__powidf2':
../../../src_gcc/libgcc/../gcc/libgcc2.c:1739:1: internal compiler error: in
rs6000_split_multireg_move, at config/rs6000/rs6000.c:16712
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[2]: *** [_powidf2.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: Leaving directory
`/tmp/edmar/build_jobs/Xe500v2/obj_gccsys/powerpc-unknown-linux-gnuspe/libgcc'
make[1]: *** [all-target-libgcc] Error 2
make[1]: Leaving directory `/tmp/edmar/build_jobs/Xe500v2/obj_gccsys'
make: *** [all] Error 2


I traced the problem back to revision 157530, which splits dp float point moves
into 2 32 bit gpr. But on e500v2, the gpr are 64 bit wide, and dp floats are
mapped to one single gpr.

The problem does not exists in e500v1 which also has 64 bit gpr because this
cpu does not have dp hardware and soft float ABI dictates dpfp values should be
kept in 2 gpr.

This problem also exists in the 4.5 branch.

The following change fix the ICE for both gcc-4.5 and gcc-4.6. It was
regression tested on 32 bits powerpc as well as on e500v2.

--- gcc-20100425/gcc/config/rs6000/rs6000.md-orig   2010-04-26
09:58:41.0 -0500
+++ gcc-20100425/gcc/config/rs6000/rs6000.md2010-04-26 10:01:55.0
-0500
@@ -218,7 +218,8 @@
   (TD "TARGET_DFP")])

 ; These modes do not fit in integer registers in 32-bit mode.
-(define_mode_iterator DIFD [DI DF DD])
+; but on e500v2, the gpr are 64 bit registers
+(define_mode_iterator DIFD [DI (DF "!TARGET_E500_DOUBLE") DD])

 ; Various instructions that come in SI and DI forms.
 ; A generic w/d attribute, for things like cmpw/cmpd.


-- 
   Summary: ICE when building for Freescale e500v2
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: edmar at freescale dot com
  GCC host triplet: powerpc-unknown-linux-gnuspe
GCC target triplet: powerpc-unknown-linux-gnuspe


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

[Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants

[manu at gcc dot gnu dot org]

--- Comment #26 from manu at gcc dot gnu dot org  2010-06-04 20:22 ---
(In reply to comment #25)
> 
> $ ./cc1 -quiet test.c
> While expanding macro OPERATE at test.c:2:8
> While expanding macro SHIFTL at test.c:5:14
> While expanding macro MULT2 at test.c:8:3
> test.c: In function 'g':
> test.c:13:3: error: invalid operands to binary << (have 'double' and 'int')

I find this output a bit confusing. I find clang's output clearer
http://clang.llvm.org/diagnostics.html.

In fact, clang's output actually follows more closely what GCC already does
with templates/inline functions. This is from GCC:

test.C:7:3:   instantiated from ‘void SHIFTL(T1, T2) [with T1 = double, T2 =
int]’
test.C:10:3:   instantiated from ‘void MULT2(T) [with T = double]’
test.C:15:20:   instantiated from here
test.C:3:3: error: invalid operands of types ‘double’ and ‘int’ to
binary ‘operator<<

Also, what are the column numbers pointing to? They don't make sense to me.

In any case, this is a huge step forward! Thanks for working on this. It would
be an important marketing point if you manage to complete it for GCC 4.6.


-- 


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

[Bug middle-end/44416] [4.6 regression] Failed to build 447.dealII in SPEC CPU 2006

[hjl dot tools at gmail dot com]

--- Comment #9 from hjl dot tools at gmail dot com  2010-06-04 20:15 ---
Created an attachment (id=20848)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20848&action=view)
The src.alt for 447.dealII

This works for me. Can someone try it?


-- 


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

[Bug pch/14933] missing pre-compiled header depends with -MD

[kristiaan dot lenaerts at gmail dot com]

--- Comment #13 from kristiaan dot lenaerts at gmail dot com  2010-06-04 
20:10 ---
Created an attachment (id=20847)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20847&action=view)
Updated fix for improper PCH dependency tracking

I got hit by this bug a few weeks ago when working on a C++ project. This
project has a setup for which using -fpch-deps will not work, most pch files
include local headers that have to be referenced by their complete path
elsewhere. 

I rebased the proposed fix from Mario on the 4.5 branch (I created it when 4.5
was not yet out). I'm using this patch for about a month now without any
obvious problems, but I would like to get this in mainline.

What are the steps that I should take? I have not yet run the testsuite. (this
is on a corporate laptop running under cygwin - windows XP and full
hd-encryption - so compiling gcc was painfull, and I imagine running the
testsuite will be worse)
Would it be ok if I run the testsuite on cygwin with and without the patch, and
if the results are the same submit this patch to gcc-patches (with meaningfull
changelog entry)? I could also test on a x64_64-pc-linux-gnu machine at home,
but it could take a while before I can test there.


-- 


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

[Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants

[dodji at gcc dot gnu dot org]

--- Comment #25 from dodji at gcc dot gnu dot org  2010-06-04 19:36 ---
Created an attachment (id=20846)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20846&action=view)
Fixes all regressions of C FE's testsuite

This update fixes all the regressions I have noticed in the test suite of the C
FE. I have done the testing and debugging with bootstrap disabled.

This patch merges Tom's initial patch and my additions and should apply to
recent trunk.

Next step is to bootstrap the C FE and see/fix the remaining bugs that I
encounter there.

Here is what the patch does at the moment:

$ cat test.c
 1  #define OPERATE(OPRD1, OPRT, OPRD2) \
 2   OPRD1 OPRT OPRD2;
 3
 4  #define SHIFTL(A,B) \
 5OPERATE (A,<<,B)
 6
 7  #define MULT2(A) \
 8SHIFTL (A,1)
 9
10  void
11  g ()
12  {
13MULT2 (1.0);/* 1.0 << 1;*/
14  }

$ ./cc1 -quiet test.c
While expanding macro OPERATE at test.c:2:8
While expanding macro SHIFTL at test.c:5:14
While expanding macro MULT2 at test.c:8:3
test.c: In function 'g':
test.c:13:3: error: invalid operands to binary << (have 'double' and 'int')


-- 


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

[Bug rtl-optimization/43632] [4.5/4.6 Regression] -g option became very slow after r157834

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2010-06-04 19:34 ---
After the recent var-tracking.c PR41371 changes this is down to 67 seconds.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t

[paolo dot carlini at oracle dot com]

--- Comment #10 from paolo dot carlini at oracle dot com  2010-06-04 18:55 
---
Something is broken in your system, I also tested on an Open Suse 11.1, to be
sure, and everything works fine. Remove everything, fetch again the entire gcc
mainline and try again.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


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

[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t

[singler at gcc dot gnu dot org]

--- Comment #9 from singler at gcc dot gnu dot org  2010-06-04 18:51 ---
Created an attachment (id=20845)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20845&action=view)
Failing test case.


-- 


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

[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t

[singler at gcc dot gnu dot org]

--- Comment #8 from singler at gcc dot gnu dot org  2010-06-04 18:51 ---
I can't help it, "make check" in the libstdc++-v3 directory still does not work
for me, even after reconfiguring and recompiling everything from scratch, using
vanilla rev 160275.
Let's have a look at attached testsuite_abi.ii.
The first typedef for std::ptrdiff_t is in line 49, but the first typedef for
ptrdiff_t in the global scope is only in line 30203.
The first error is in line 24823, however, this is in (sub?) namespace
__cxxabiv1.
Should this work anyway?
I'm quite lost.


-- 

singler at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|WORKSFORME  |


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

[Bug c++/44412] [4.6 Regression] Another bogus set-but-not-used warning

[jakub at gcc dot gnu dot org]

--- Comment #3 from jakub at gcc dot gnu dot org  2010-06-04 18:46 ---
Subject: Bug 44412

Author: jakub
Date: Fri Jun  4 18:45:07 2010
New Revision: 160290

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160290
Log:
PR c++/44412
* typeck.c (build_class_member_access_expr): Call mark_exp_read
on object for static data members.

* g++.dg/warn/Wunused-var-10.C: New test.
* g++.dg/warn/Wunused-var-11.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wunused-var-10.C
trunk/gcc/testsuite/g++.dg/warn/Wunused-var-11.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[iains at gcc dot gnu dot org]

--- Comment #40 from iains at gcc dot gnu dot org  2010-06-04 18:45 ---
(In reply to comment #39)
> I confirm that the failures for libjava reported in comment #33 were due to
> some misconfiguration.
> With the patches in http://gcc.gnu.org/bugzilla/attachment.cgi?id=20762 and
> http://gcc.gnu.org/bugzilla/attachment.cgi?id=20822 , after a clean boostrap, 
> I
> see the following new failures:
> 
> FAIL: g++.dg/tls/init-2.C (internal compiler error)
> FAIL: g++.dg/tls/init-2.C (test for excess errors)
> 
> FAIL: gcc.dg/tls/asm-1.c (internal compiler error)
> FAIL: gcc.dg/tls/asm-1.c  (test for errors, line 7)
> FAIL: gcc.dg/tls/asm-1.c (test for excess errors)
> 
> FAIL: obj-c++.dg/tls/init-2.mm -fgnu-runtime (internal compiler error)
> FAIL: obj-c++.dg/tls/init-2.mm -fnext-runtime (internal compiler error)

right, that's what I expect.

I think this :  gcc.dg/tls/asm-1.c is because gimplify_asm () doesn't consider
expansion of the parameter
(hopefully Honza could help with that).

I think that this : g++.dg/tls/init-2.C & obj-c++.dg/tls/init-2.mm - (which are
the same code)
 are down to two conflicting error responses from the C++ FE, -- there are two
error messages that disagree.

In other words, although these are regressions showing from the application of
the patch - I think they might be latent problems outside emutls.

I'll re-jig the patch to remove the ABI breakage and post over the next few
days.


-- 


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

[Bug c++/44362] Bogus set-but-not-used warning

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2010-06-04 18:43 ---
Subject: Bug 44362

Author: jakub
Date: Fri Jun  4 18:42:42 2010
New Revision: 160289

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160289
Log:
PR c++/44362
* call.c (build_conditional_expr): If both arg2 and arg3 are lvalues
with the same type, call mark_lvalue_use on both.

* c-c++-common/Wunused-var-10.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/Wunused-var-10.c
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.

[dominiq at lps dot ens dot fr]

--- Comment #39 from dominiq at lps dot ens dot fr  2010-06-04 18:25 ---
I confirm that the failures for libjava reported in comment #33 were due to
some misconfiguration.
With the patches in http://gcc.gnu.org/bugzilla/attachment.cgi?id=20762 and
http://gcc.gnu.org/bugzilla/attachment.cgi?id=20822 , after a clean boostrap, I
see the following new failures:

FAIL: g++.dg/tls/init-2.C (internal compiler error)
FAIL: g++.dg/tls/init-2.C (test for excess errors)

FAIL: gcc.dg/tls/asm-1.c (internal compiler error)
FAIL: gcc.dg/tls/asm-1.c  (test for errors, line 7)
FAIL: gcc.dg/tls/asm-1.c (test for excess errors)

FAIL: obj-c++.dg/tls/init-2.mm -fgnu-runtime (internal compiler error)
FAIL: obj-c++.dg/tls/init-2.mm -fnext-runtime (internal compiler error)


-- 


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

[Bug c++/44244] Provide -f flags to turn on individual C++0x features

[jyasskin at gmail dot com]

--- Comment #3 from jyasskin at gmail dot com  2010-06-04 17:56 ---
Thanks for the prompt answers. I understand that you've picked the right
direction for gcc as a whole, even though it'll inconvenience me temporarily.


-- 


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

[Bug testsuite/44418] FAIL: gcc.target/powerpc/recip-[123].c on powerpc-apple-darwin9

[dominiq at lps dot ens dot fr]

--- Comment #3 from dominiq at lps dot ens dot fr  2010-06-04 17:52 ---
Created an attachment (id=20844)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20844&action=view)
assembly for recip-3.c


-- 


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

[Bug testsuite/44418] FAIL: gcc.target/powerpc/recip-[123].c on powerpc-apple-darwin9

[dominiq at lps dot ens dot fr]

--- Comment #2 from dominiq at lps dot ens dot fr  2010-06-04 17:52 ---
Created an attachment (id=20843)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20843&action=view)
assembly for recip-2.c


-- 


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

[Bug testsuite/44418] FAIL: gcc.target/powerpc/recip-[123].c on powerpc-apple-darwin9

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2010-06-04 17:52 ---
Created an attachment (id=20842)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20842&action=view)
assembly for recip-1.c


-- 


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

[Bug libgcj/44415] [4.6 regression] gmp multilib support broke bootstrap with static libgmp

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2010-06-04 17:49 ---
See PR 39747.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  BugsThisDependsOn||39747


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

[Bug libgcj/44415] [4.6 regression] gmp multilib support broke bootstrap with static libgmp

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2010-06-04 17:48 ---
First off this is not a regression; I ran into this issue back a couple of
years ago with libjava requiring libgmp.


-- 


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

[Bug testsuite/44418] New: FAIL: gcc.target/powerpc/recip-[123].c on powerpc-apple-darwin9

[dominiq at lps dot ens dot fr]

Since revision 160215 (see
http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg00263.html ) one gets the
following failures on powerpc-apple-darwin9:

FAIL: gcc.target/powerpc/recip-1.c scan-assembler-times frsqrte 2
FAIL: gcc.target/powerpc/recip-1.c scan-assembler-times fmsub 2
FAIL: gcc.target/powerpc/recip-1.c scan-assembler-times fmul 8
FAIL: gcc.target/powerpc/recip-2.c scan-assembler-times frsqrtes 1
FAIL: gcc.target/powerpc/recip-2.c scan-assembler-times fmsubs 1
FAIL: gcc.target/powerpc/recip-2.c scan-assembler-times fmuls 6
FAIL: gcc.target/powerpc/recip-2.c scan-assembler-times fnmsubs 3
FAIL: gcc.target/powerpc/recip-2.c scan-assembler-times fsqrt 1
FAIL: gcc.target/powerpc/recip-3.c scan-assembler-times frsqrtes 1
FAIL: gcc.target/powerpc/recip-3.c scan-assembler-times fmsubs 1
FAIL: gcc.target/powerpc/recip-3.c scan-assembler-times fmuls 4

I'll attach the assemby files for these tests.


-- 
   Summary: FAIL: gcc.target/powerpc/recip-[123].c on powerpc-apple-
darwin9
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
 GCC build triplet: powerpc-apple-darwin9
  GCC host triplet: powerpc-apple-darwin9
GCC target triplet: powerpc-apple-darwin9


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

[Bug target/44364] Wrong code with e500 double floating point

[Kyle dot D dot Moffett at boeing dot com]

--- Comment #18 from Kyle dot D dot Moffett at boeing dot com  2010-06-04 
17:24 ---
Created an attachment (id=20841)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20841&action=view)
Minimal test objdump with -O1


-- 


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

[Bug target/44364] Wrong code with e500 double floating point

[Kyle dot D dot Moffett at boeing dot com]

--- Comment #17 from Kyle dot D dot Moffett at boeing dot com  2010-06-04 
17:24 ---
Created an attachment (id=20840)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20840&action=view)
Minimal test with -O1

I've managed to shrink this down to a 44-line testcase that fails with the
options listed below.  The code is the same but the failure mode is different; 
Specifically, I get this output:
|RESET: 252.00 | 4294967296.00
|RESET: 504.00 | 4294967296.00
|RESET: 756.00 | 4294967296.00
|RESET: 1008.00 | 4294967296.00
|RESET: 1260.00 | 4294967296.00
|RESET: 1512.00 | 4294967296.00
|RESET: 1764.00 | 4294967296.00
|RESET: 2016.00 | 4294967296.00
|RESET: 2268.00 | 4294967296.00
 => 2268.00
|RESET: 2520.00 | 4294967296.00
|RESET: 2772.00 | 4294967296.00

>From the code, the second floating point value on each line should be equal to
the first float from the previous line.  If I change the first "(unsigned long
long)" cast to a "(long long)" cast, the bug goes away and I see the following
(correct) output:
|RESET: 252.00 | 0.00
|RESET: 504.00 | 252.00
|RESET: 756.00 | 504.00
|RESET: 1008.00 | 756.00
|RESET: 1260.00 | 1008.00
|RESET: 1512.00 | 1260.00
|RESET: 1764.00 | 1512.00
|RESET: 2016.00 | 1764.00
|RESET: 2268.00 | 2016.00
 => 2268.00
|RESET: 2520.00 | 2268.00
|RESET: 2772.00 | 2520.00

The full list of compile options:
-pipe \
-g \
-Wall \
-fmove-loop-invariants \
-fcaller-saves \
--param max-aliased-vops=100 \
--param avg-aliased-vops=1 \
--param max-fields-for-field-sensitive=0 \
--param loop-invariant-max-bbs-in-loop=1000 \
-O \
-fno-web \
-fno-rename-registers \
-fno-unroll-loops \
-fno-peel-loops \
-fno-split-ivs-in-unroller \
-fno-peephole \
-fno-dce \
-fno-dse \
-fno-unit-at-a-time \
-fno-omit-frame-pointer \
-fno-auto-inc-dec \
-fno-cprop-registers \
-fno-dce \
-fno-defer-pop \
-fno-delayed-branch \
-fno-dse \
-fno-guess-branch-probability \
-fno-if-conversion2 \
-fno-if-conversion \
-fno-inline-small-functions \
-fno-inline-functions-called-once \
-fno-early-inlining \
-fno-ipa-pure-const \
-fno-ipa-reference \
-fno-merge-constants \
-fno-split-wide-types \
-fno-tree-builtin-call-dce \
-fno-tree-ccp \
-fno-tree-ch \
-fno-tree-copyrename \
-fno-tree-dce \
-fno-tree-dominator-opts \
-fno-tree-dse \
-fno-tree-fre \
-fno-tree-sra \
-fno-tree-ter \
-fno-merge-constants \
-fno-branch-count-reg \
-fno-function-cse \
-fno-thread-jumps \
-fno-gcse \
-fno-rerun-cse-after-loop \
-fno-cse-skip-blocks \
-fno-cse-follow-jumps


-- 


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

[Bug target/40419] __attribute__((mips16)) is broken on trunk.

[zadeck at naturalbridge dot com]

--- Comment #2 from zadeck at naturalbridge dot com  2010-06-04 17:18 
---
I would just like to say that i think that target_reinit should be removed.  
It is nothing but trouble.   We tried to use it on our private port and it was
very slow and most of the time ended up crashing.   Furthermore, when we got
down to the end, we discovered that in fact it does not end up calling
everything that was needed to reinitialize ira.   

Our platform has a register architecture like a sparc but it has a variable
number of ins and outs.   The exact number of ins depends on the function
signature and the number of outs depends on the signatures of the callees.   
So we tried using target_reinit to reset the register allocator after we had
seen the caller to the function and all of the callees.   

in the end we added a special pass that does an reinit_regs () before ira.  
This sped up our compiler by about 4x.  (i.e target_reinit is not just buggy,
it is slow.)

Note that target_reinit does not do a reinit_regs and so it actually does not
really reinitialize the target, at least as far as ira is concerned.  


-- 


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

[Bug libstdc++/44413] inefficient code for std::string::compare on x86-64

[redi at gcc dot gnu dot org]

--- Comment #1 from redi at gcc dot gnu dot org  2010-06-04 16:52 ---
Seems like a reasonable suggestion for improvement. I don't know if anyone
relies on the current behaviour, so it might not get changed.


-- 

redi at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-06-04 16:52:15
   date||


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

[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry

[jakub at gcc dot gnu dot org]

--- Comment #39 from jakub at gcc dot gnu dot org  2010-06-04 16:48 ---
Subject: Bug 41371

Author: jakub
Date: Fri Jun  4 16:47:41 2010
New Revision: 160282

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160282
Log:
PR debug/41371
* var-tracking.c (find_loc_in_1pdv): Mark initial value before
recursing.  Check that recursion is bounded.  Rename inner var
to avoid hiding incoming argument.

Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/var-tracking.c


-- 


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

[Bug rtl-optimization/44013] VTA produces wrong code

[jakub at gcc dot gnu dot org]

--- Comment #10 from jakub at gcc dot gnu dot org  2010-06-04 16:44 ---
Subject: Bug 44013

Author: jakub
Date: Fri Jun  4 16:43:42 2010
New Revision: 160281

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160281
Log:
PR rtl-optimization/44013
* sched-deps.c (add_dependence_list_and_free): Don't free lists
when processing debug insns.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/sched-deps.c


-- 


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

[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry

[jakub at gcc dot gnu dot org]

--- Comment #38 from jakub at gcc dot gnu dot org  2010-06-04 16:42 ---
Subject: Bug 41371

Author: jakub
Date: Fri Jun  4 16:42:27 2010
New Revision: 160280

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160280
Log:
PR debug/41371
* var-tracking.c (find_loc_in_1pdv): Mark initial value before
recursing.  Check that recursion is bounded.  Rename inner var
to avoid hiding incoming argument.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/var-tracking.c


-- 


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

[Bug tree-optimization/44406] wrong code generation with -ftree-sra

[jamborm at gcc dot gnu dot org]

--- Comment #3 from jamborm at gcc dot gnu dot org  2010-06-04 16:42 ---
Thanks for a nice testcase. I've been looking at this briefly today
and so far I am inclined to say that this is not SRA's fault.  First,
I have identified the function that is miscompiled
(boost::detail::function::basic_vtable4::assign_to)
and the transformation there is very simple and looks OK.

Furthermore, the testcase does not miscompile on the current trunk and
the output of SRA on the trunk and on the branch is exactly the
same.  I'll continue looking at this next week.


-- 


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

[Bug middle-end/44416] [4.6 regression] Failed to build 447.dealII in SPEC CPU 2006

[hjl dot tools at gmail dot com]

--- Comment #8 from hjl dot tools at gmail dot com  2010-06-04 16:40 ---
(In reply to comment #7)
> As the author of the benchmark I can confirm that we apparently forgot
> to include the proper header file. So you can call it a defect in 447.dealII.
> The question is how to deal with this, of course.
> 

I will prepare an alt src.


-- 


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

[Bug tree-optimization/44258] [4.5/4.6 Regression] possible SRA wrong-code generation.

[maksim at kde dot org]

--- Comment #7 from maksim at kde dot org  2010-06-04 16:38 ---
Created an attachment (id=20839)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20839&action=view)
Preprocessed source

Actually, never mind that --- got it on x86-64 from an another KDEer (credit to
Alex Fiestas).


-- 


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

[Bug bootstrap/44307] do not enable warnings when building with the host compiler

[manu at gcc dot gnu dot org]

--- Comment #8 from manu at gcc dot gnu dot org  2010-06-04 16:36 ---
-Wuninitialized is enabled by -Wall (or perhaps -Wextra), not explicitly. I
think we should not enable any warnings when building with the host compiler,
unless the user requests them. It is probably faster and would produce less
clutter in the output. But I don't have enough time to provide a patch to fix
this, and I doubt any main developer considers this a priority.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
  Component|middle-end  |bootstrap
 Resolution|WONTFIX |
Summary|warning: may be used|do not enable warnings when
   |uninitialized in this   |building with the host
   |function often building gcc |compiler


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

[Bug middle-end/44416] [4.6 regression] Failed to build 447.dealII in SPEC CPU 2006

[bangerth at gmail dot com]

--- Comment #7 from bangerth at gmail dot com  2010-06-04 16:36 ---

As the author of the benchmark I can confirm that we apparently forgot
to include the proper header file. So you can call it a defect in 447.dealII.
The question is how to deal with this, of course.

W.


-- 

bangerth at gmail dot com changed:

   What|Removed |Added

 CC||bangerth at gmail dot com


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

[Bug middle-end/44307] warning: may be used uninitialized in this function often building gcc

[jay dot krell at cornell dot edu]

--- Comment #7 from jay dot krell at cornell dot edu  2010-06-04 16:30 
---
I mean -Wuninitialized.
-Werror is already omitted.


-- 


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

[Bug middle-end/44307] warning: may be used uninitialized in this function often building gcc

[manu at gcc dot gnu dot org]

--- Comment #6 from manu at gcc dot gnu dot org  2010-06-04 16:22 ---
(In reply to comment #5)
> Then don't use when I -disable-bootstrap..
> 

Do you mean that -Werror is used when you disable-bootstrap? If so, I think
that is a bug. Or you mean to not use warnings? I think that would be a nice
enhancement, yes.


-- 


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

[Bug middle-end/44307] warning: may be used uninitialized in this function often building gcc

[jay dot krell at cornell dot edu]

--- Comment #5 from jay dot krell at cornell dot edu  2010-06-04 16:20 
---
Then don't use when I -disable-bootstrap..


-- 


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

[Bug c++/44172] Compiling never ends

[manu at gcc dot gnu dot org]

--- Comment #5 from manu at gcc dot gnu dot org  2010-06-04 16:11 ---
Please fellow GCC maintainers, after checking that a bug is indeed a bug,
please set the status to NEW. What more than 1000 unconfirmed reports!


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-06-04 16:11:14
   date||


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

[Bug c++/44285] Need an option that will create symbols for all public c++ methods, not only for those which bodies are outside the class declaration

[manu at gcc dot gnu dot org]

--- Comment #8 from manu at gcc dot gnu dot org  2010-06-04 16:03 ---
As mentioned in the comments above, there is an easy way to achieve this
already without needing to make the compiler more complex and slower. So I will
close this as WONTFIX.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug web/44269] Search for PR number in mailing lists fails

[manu at gcc dot gnu dot org]

--- Comment #1 from manu at gcc dot gnu dot org  2010-06-04 15:59 ---
Who is in charge of GCC infrastructure (wiki, mailing lists, bugzilla)? 

I am afraid there is no one, so this is not going to be fixed soon. Meanwhile
use Google. 


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-06-04 15:59:56
   date||


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

[Bug middle-end/44307] warning: may be used uninitialized in this function often building gcc

[manu at gcc dot gnu dot org]

--- Comment #4 from manu at gcc dot gnu dot org  2010-06-04 15:56 ---
Hi Jay,

-Wuninitialized is quite unreliable in old compilers and also we do not know
what patches Apple applies to its copy of GCC. This is why -Werror is not used
in the first stage of building GCC. We do not see these warnings with recent
GCC, so I guess they are bogus. If you find a real (potential) uninitialized
use, please reopen this PR and point us to the code. Otherwise, fixing this is
not worth the effort of anyone. There is a lot more interesting (and urgently
needed) work to do in GCC. I am sure Richard Guenther could have fixed a couple
of real bugs in the time it took him to read this PR ;).

Thanks for the report anyway.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug c++/44244] Provide -f flags to turn on individual C++0x features

[manu at gcc dot gnu dot org]

--- Comment #2 from manu at gcc dot gnu dot org  2010-06-04 15:50 ---
I am going to close this as WONTFIX for the following reasons:

* We do not want this because:
  a) We have too many options.
  b) These options would be of very limited and temporary use but we will have
to support them forever.
  c) c++0x features are spread all over the compiler -> this is hard to
implement properly as an after-thought.
  d) The additional checking will slow down the compiler for no significant
gain. We are too slow already.

* We have too many open PRs, so it is not worth it to keep this open just in
case.

Sorry about this but I hope you can understand.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||manu at gcc dot gnu dot org
 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX


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

[Bug c/25880] improve message of warning for discarding qualifiers

[manu at gcc dot gnu dot org]

--- Comment #4 from manu at gcc dot gnu dot org  2010-06-04 15:21 ---
The infrastructure to enable this has been added in GCC 4.6 and some
diagnostics are already making use of it, in particular the one reported here.
So I consider this FIXED. 

If anyone finds particular diagnostics that should explicitly print qualifiers,
they just need to use %qV, %qv or %q#v to do so. In that case, reopen this PR
or open a new one. Patches are also welcome.


-- 

manu at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug lto/40702] lto-elf.c fails to compile on Solaris

[ro at CeBiTec dot Uni-Bielefeld dot DE]

--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld dot DE  2010-06-04 
15:21 ---
Subject: Re:  lto-elf.c fails to compile on Solaris

> --- Comment #11 from rguenth at gcc dot gnu dot org  2010-06-03 13:47 
> ---
> The problem seems to have vanished, so eventually the fix can be backported
> (together with the typo fix in the configure script obviously).

Done: I've run toplevel configure and make configure-gcc on both
i386-pc-solaris2.11 (which has the new elf_getshdrstrndx) and
i386-pc-solaris2.10 (which only has the non-conformant version of
elf_getshstrndx) and got the expected results (and no error in
gcc/config.log), so I've check this in.

Should we ever receive more information for bootstrap/44079, we can
either fix the configure tests or document the required version of
elfutils libelf.

Rainer


-- 


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

[Bug c/25880] improve message of warning for discarding qualifiers

[manu at gcc dot gnu dot org]

--- Comment #3 from manu at gcc dot gnu dot org  2010-06-04 15:16 ---
Subject: Bug 25880

Author: manu
Date: Fri Jun  4 15:15:38 2010
New Revision: 160274

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160274
Log:
2010-06-04  Manuel López-Ibáñez  

PR c/25880
* c-objc-common.c (c_tree_printer): Handle %V, %v and %#v.
* c-format.c (gcc_diag_flag_specs): Add hash.
(gcc_cxxdiag_flag_specs): Use gcc_diag_flag_specs directly.
(gcc_tdiag_char_table,gcc_cdiag_char_table): Handle %V and %v.
* c-pretty-print.c (pp_c_cv_qualifier): Rename as
pp_c_cv_qualifiers. Handle qualifiers spelling here.
(pp_c_type_qualifier_list): Call the function above.
* c-pretty-print.h (pp_c_cv_qualifiers): Declare.
* c-typeck.c (handle_warn_cast_qual): Print qualifiers.
(WARN_FOR_QUALIFIERS): New macro.
(convert_for_assignment): Use it.
testsuite/
* gcc.dg/assign-warn-2.c: Update.
* gcc.dg/cpp/line3.c: Update.
* gcc.dg/c99-array-lval-8.c: Update.
* gcc.dg/cast-qual-2.c: Update.
* gcc.dg/c99-arraydecl-3.c:  Update.
* gcc.dg/assign-warn-1.c:  Update.
* gcc.dg/format/gcc_diag-1.c:  Update.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-format.c
trunk/gcc/c-objc-common.c
trunk/gcc/c-pretty-print.c
trunk/gcc/c-pretty-print.h
trunk/gcc/c-typeck.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/assign-warn-1.c
trunk/gcc/testsuite/gcc.dg/assign-warn-2.c
trunk/gcc/testsuite/gcc.dg/c99-array-lval-8.c
trunk/gcc/testsuite/gcc.dg/c99-arraydecl-3.c
trunk/gcc/testsuite/gcc.dg/cast-qual-2.c
trunk/gcc/testsuite/gcc.dg/cpp/line3.c
trunk/gcc/testsuite/gcc.dg/format/gcc_diag-1.c


-- 


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

[Bug middle-end/44416] [4.6 regression] Failed to build 447.dealII in SPEC CPU 2006

[jwakely dot gcc at gmail dot com]

--- Comment #6 from jwakely dot gcc at gmail dot com  2010-06-04 15:00 
---
certainly true for an older version
http://ganymed.iwr.uni-heidelberg.de/~deal/5.2.0/doxygen/deal.II/block__vector_8h.html


-- 


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

[Bug middle-end/44416] [4.6 regression] Failed to build 447.dealII in SPEC CPU 2006

[jwakely dot gcc at gmail dot com]

--- Comment #5 from jwakely dot gcc at gmail dot com  2010-06-04 14:56 
---
I don't have the SPEC benchmarks either, but probably deal.II uses ptrdiff_t
unqualified, without explicitly including either  or 

http://www.dealii.org/developer/doxygen/deal.II/block__vector_8h.html


-- 


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

[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t

[paolo dot carlini at oracle dot com]

--- Comment #7 from paolo dot carlini at oracle dot com  2010-06-04 14:55 
---
Closing.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


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

[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t

[paolo dot carlini at oracle dot com]

--- Comment #6 from paolo dot carlini at oracle dot com  2010-06-04 14:52 
---
Note that cxxabi.h already includes  and at that line 371 uses
ptrdiff_t unqualified, thus everything is fine. I suspect you simply forgot to
update your compiler, because the current library does not work without a
recent front end fix applied by Jason.


-- 


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

[Bug middle-end/44382] Slow integer multiply

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2010-06-04 14:40 ---
tree-ssa-reassoc.c has

2. Left linearization of the expression trees, so that (A+B)+(C+D)
becomes (((A+B)+C)+D), which is easier for us to rewrite later.
During linearization, we place the operands of the binary
expressions into a vector of operand_entry_t

I think this may always generate slower codes. We may not want to
use much more registers. We can limit us to 2 temporaries.


-- 


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

[Bug lto/42776] LTO doesn't work on non-ELF platforms.

[ro at gcc dot gnu dot org]

--- Comment #49 from ro at gcc dot gnu dot org  2010-06-04 14:33 ---
Subject: Bug 42776

Author: ro
Date: Fri Jun  4 14:32:19 2010
New Revision: 160269

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160269
Log:
Backport from mainline:
2010-04-27  Dave Korn  

PR lto/42776
* lib/lto.exp (lto_prune_vis_warns): New function.
(lto-link-and-maybe-run): Call it.

2010-05-10  Rainer Orth  

* lib/lto.exp (lto_prune_vis_warns): Renamed to lto_prune_warns.
Log text on entry and exit.
Prune Sun ld warnings for common symbols with differing sizes.
(lto-link-and-maybe-run): Change caller.

Modified:
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
branches/gcc-4_5-branch/gcc/testsuite/lib/lto.exp


-- 


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

[Bug middle-end/44416] [4.6 regression] Failed to build 447.dealII in SPEC CPU 2006

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2010-06-04 14:29 
---
Not a duplicate, another issue.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|DUPLICATE   |


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

[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t

[paolo dot carlini at oracle dot com]

--- Comment #5 from paolo dot carlini at oracle dot com  2010-06-04 14:28 
---
Hey, 44416 is *not* a duplicate! Please re-open it immediately.


-- 


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

[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t

[paolo dot carlini at oracle dot com]

--- Comment #4 from paolo dot carlini at oracle dot com  2010-06-04 14:23 
---
To be clear: does a normal 'make check' (either from the root of the build dir
or from inside the library build dir) work? Because it works here and fo
everybody else on the testresult mailing list, also for people using your exact
same linux.


-- 


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

[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t

[singler at kit dot edu]

--- Comment #3 from singler at kit dot edu  2010-06-04 14:19 ---
*** Bug 44416 has been marked as a duplicate of this bug. ***


-- 

singler at kit dot edu changed:

   What|Removed |Added

 CC||hjl dot tools at gmail dot
   ||com


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

[Bug middle-end/44416] [4.6 regression] Failed to build 447.dealII in SPEC CPU 2006

[singler at kit dot edu]

--- Comment #3 from singler at kit dot edu  2010-06-04 14:19 ---
Bug 44417 is very likely to have the same cause, but here, we can reproduce it
more easily, using the testsuite.

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


-- 

singler at kit dot edu changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t

[singler at kit dot edu]

--- Comment #2 from singler at kit dot edu  2010-06-04 14:16 ---
I had cleaned the builddir already.
Adding 

#include  

solves the problem. 
The crucial file seems to be

lib/gcc/x86_64-unknown-linux-gnu/4.6.0/include/stddef.h

Only if it is (indirectly) included, ptrdiff_t is defined in the global scope. 
Maybe on other systems, ptrdiff_t is also declared somewhere else, so the
problem does not appear.


-- 


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

[Bug c++/44412] [4.6 Regression] Another bogus set-but-not-used warning

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2010-06-04 14:12 ---
Created an attachment (id=20838)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20838&action=view)
gcc46-pr44412.patch

Untested patch.


-- 


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

[Bug middle-end/44382] Slow integer multiply

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2010-06-04 13:56 ---
(In reply to comment #3)
> Yes, reassoc linearizes instead of building a tree (saves one (or was it two?)
> registers at best).
> 

Should we always build a tree? It may increase register pressure.


-- 


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

[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t

[paolo dot carlini at oracle dot com]

--- Comment #1 from paolo dot carlini at oracle dot com  2010-06-04 13:49 
---
I can't reproduce this. I booted and tested many times on various linux systems
and HJ already reported many succesfull testresults since. Please remove
everything from the build dir, gave everything fresh and retry.


-- 


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

[Bug libstdc++/44417] New: make check-target-libstdc++-v3 fails due to undefined ptrdiff_t

[singler at kit dot edu]

make check-target-libstdc++-v3 fails because ptrdiff_t is undefined.
std::ptrdiff_t works.
Maybe this bug is related to the Linux system run on.  I have openSuse 11.1
running.

configure --enable-languages=c,c++ --program-suffix=-rep
--prefix=$HOME/gcc/install_trunk_1


In file included from
/home/singler/gcc/trunk_1/libstdc++-v3/testsuite/util/testsuite_abi.h:27:0,
 from
/home/singler/gcc/trunk_1/libstdc++-v3/testsuite/util/testsuite_abi.cc:23:
/home/singler/gcc/trunk_1/libstdc++-v3/libsupc++/cxxabi.h:371:5: error:
'ptrdiff_t' does not name a type
/home/singler/gcc/trunk_1/libstdc++-v3/libsupc++/cxxabi.h:447:23: error:
'ptrdiff_t' has not been declared
/home/singler/gcc/trunk_1/libstdc++-v3/libsupc++/cxxabi.h:459:18: error:
'ptrdiff_t' has not been declared
/home/singler/gcc/trunk_1/libstdc++-v3/libsupc++/cxxabi.h:469:26: error:
'ptrdiff_t' has not been declared
/home/singler/gcc/trunk_1/libstdc++-v3/libsupc++/cxxabi.h:495:18: error:
'ptrdiff_t' has not been declared
/home/singler/gcc/trunk_1/libstdc++-v3/libsupc++/cxxabi.h:501:26: error:
'ptrdiff_t' has not been declared
/home/singler/gcc/trunk_1/libstdc++-v3/libsupc++/cxxabi.h:540:18: error:
'ptrdiff_t' has not been declared
/home/singler/gcc/trunk_1/libstdc++-v3/libsupc++/cxxabi.h:546:26: error:
'ptrdiff_t' has not been declared
/home/singler/gcc/trunk_1/libstdc++-v3/libsupc++/cxxabi.h:566:4: error:
'ptrdiff_t' has not been declared
compiler exited with status 1

Any ideas and/or a workaround?


-- 
   Summary: make check-target-libstdc++-v3 fails due to undefined
ptrdiff_t
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: singler at kit dot edu
 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=44417

[Bug middle-end/44416] [4.6 regression] Failed to build 447.dealII in SPEC CPU 2006

[paolo dot carlini at oracle dot com]

--- Comment #2 from paolo dot carlini at oracle dot com  2010-06-04 13:42 
---
I do not have access to those benchmarks. Whoever has, should check that
ptrdiff_t is used properly, either after including , then it can be
used both qualified with std:: and unqualified together with v3, or qualified
with std:: after essentially after including any other c++ header. For sure the
c++ standard doesn't warrant more than the above.


-- 


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

[Bug middle-end/44416] [4.6 regression] Failed to build 447.dealII in SPEC CPU 2006

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2010-06-04 13:26 ---
It may be caused by revision 160231:

http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg00144.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||paolo dot carlini at oracle
   ||dot com


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

[Bug middle-end/44416] [4.6 regression] Failed to build 447.dealII in SPEC CPU 2006

[hjl dot tools at gmail dot com]

-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0


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

[Bug middle-end/44416] New: [4.6 regression] Failed to build 447.dealII in SPEC CPU 2006

[hjl dot tools at gmail dot com]

On Linux/x86-64, revision 160243 failed to
build 447.dealII in SPEC CPU 2006 at -O2 and -O3:

g++ -c -o block_vector.o -DSPEC_CPU -DNDEBUG  -Iinclude -DBOOST_DISABLE_THREADS
-Ddeal_II_dimension=3  -O3 -ffast-math -funroll-loops   -DSPEC_CPU_LP64  
block_vector.cc
In file included from include/lac/block_vector.templates.h:19:0,
 from block_vector.cc:14:
include/lac/block_vector.h:227:17: error: 'ptrdiff_t' does not name a type
include/lac/block_vector.h:333:38: error: 'difference_type' does not name a
type
include/lac/block_vector.h:333:38: note: (perhaps 'typename
std::iterator::NumberType>::difference_type' was intended)
include/lac/block_vector.h:333:54: error: ISO C++ forbids declaration of 'd'
with no type [-fpermissive]
include/lac/block_vector.h:469:9: error: 'difference_type' does not name a type
include/lac/block_vector.h:469:9: note: (perhaps 'typename
std::iterator::NumberType>::difference_type' was intended)
include/lac/block_vector.h:475:9: error: 'difference_type' does not name a type
include/lac/block_vector.h:475:9: note: (perhaps 'typename
std::iterator::NumberType>::difference_type' was intended)
include/lac/block_vector.h:482:36: error: 'difference_type' does not name a
type
include/lac/block_vector.h:482:36: note: (perhaps 'typename
std::iterator::NumberType>::difference_type' was intended)
include/lac/block_vector.h:482:53: error: ISO C++ forbids declaration of 'd'
with no type [-fpermissive]
include/lac/block_vector.h:489:36: error: 'difference_type' does not name a
type
include/lac/block_vector.h:489:36: note: (perhaps 'typename
std::iterator::NumberType>::difference_type' was intended)
include/lac/block_vector.h:489:53: error: ISO C++ forbids declaration of 'd'
with no type [-fpermissive]
include/lac/block_vector.h:496:39: error: 'difference_type' does not name a
type
include/lac/block_vector.h:496:39: note: (perhaps 'typename
std::iterator::NumberType>::difference_type' was intended)
include/lac/block_vector.h:496:56: error: ISO C++ forbids declaration of 'd'
with no type [-fpermissive]
include/lac/block_vector.h:503:39: error: 'difference_type' does not name a
type
include/lac/block_vector.h:503:39: note: (perhaps 'typename
std::iterator::NumberType>::difference_type' was intended)
include/lac/block_vector.h:503:56: error: ISO C++ forbids declaration of 'd'
with no type [-fpermissive]
include/lac/block_vector.h:1494:52: error: 'difference_type' does not name a
type
include/lac/block_vector.h:1494:52: note: (perhaps 'typename
std::iterator::NumberType>::difference_type' was intended)
include/lac/block_vector.h:1494:68: error: ISO C++ forbids declaration of 'd'
with no type [-fpermissive]
include/lac/block_vector.h:1727:5: error: prototype for 'typename
internal::BlockVectorIterators::Iterator::difference_type
internal::BlockVectorIterators::Iterator::operator-(const
internal::BlockVectorIterators::Iterator&) const' does not
match any in class 'internal::BlockVectorIterators::Iterator'
include/lac/block_vector.h:489:18: error: candidate is:
internal::BlockVectorIterators::Iterator
internal::BlockVectorIterators::Iterator::operator-(const
int&) const
include/lac/block_vector.h:1741:5: error: prototype for 'typename
internal::BlockVectorIterators::Iterator::difference_type
internal::BlockVectorIterators::Iterator::operator-(const
InverseConstnessIterator&) const' does not match any in class
'internal::BlockVectorIterators::Iterator'
include/lac/block_vector.h:489:18: error: candidate is:
internal::BlockVectorIterators::Iterator
internal::BlockVectorIterators::Iterator::operator-(const
int&) const
include/lac/block_vector.h:1756:23: error: 'difference_type' does not name a
type
include/lac/block_vector.h:1756:23: note: (perhaps 'typename
std::iterator::NumberType>::difference_type' was intended)
include/lac/block_vector.h:1756:40: error: ISO C++ forbids declaration of 'd'
with no type [-fpermissive]
include/lac/block_vector.h:1781:23: error: 'difference_type' does not name a
type
include/lac/block_vector.h:1781:23: note: (perhaps 'typename
std::iterator::NumberType>::difference_type' was intended)
include/lac/block_vector.h:1781:40: error: ISO C++ forbids declaration of 'd'
with no type [-fpermissive]
include/lac/block_vector.h:1806:24: error: 'difference_type' does not name a
type
include/lac/block_vector.h:1806:24: note: (perhaps 'typename
std::iterator::NumberType>::difference_type' was intended)
include/lac/block_vector.h:1806:41: error: ISO C++ forbids declaration of 'd'
with no type [-fpermissive]
include/lac/block_vector.h:1834:24: error: 'difference_type' does not name a
type
include/lac/block_vector.h:1834:24: note: (perhaps 'typename
std::iterator::NumberType>::difference_type' was intended)
include/lac/block_vector.h:1834:41: error: ISO C++ forbids declaration of 'd'
with no type [-fpermissive]
specmake[3]: *** [block_vector.o] Error 1
specmake[3]: *** Waiting for unfinished jobs

Revision 160217 is OK.


-- 
   Summary: [4.6 regression] Failed

[Bug middle-end/44382] Slow integer multiply

[rguenth at gcc dot gnu dot org]

--- Comment #3 from rguenth at gcc dot gnu dot org  2010-06-04 13:21 ---
Yes, reassoc linearizes instead of building a tree (saves one (or was it two?)
registers at best).


-- 


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

[Bug c++/26256] ignores using declaration

[fabien at gcc dot gnu dot org]

-- 

fabien at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |fabien at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2006-02-13 07:21:15 |2010-06-04 13:13:40
   date||


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

[Bug middle-end/44382] Slow integer multiply

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2010-06-04 13:08 ---
(In reply to comment #1)
> Because our tree reassoc doesn't re-associate them.
> 

The tree reassoc pass makes it slower:

[...@gnu-6 44382]$ cat x.i
extern int a, b, c, d, e, f;
void
foo ()
{
  a = (b * c) * (d * e);
}
[...@gnu-6 44382]$ gcc -S -O2 x.i
[...@gnu-6 44382]$ cat x.s
.file   "x.i"
.text
.p2align 4,,15
.globl foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
movlc(%rip), %eax
imull   b(%rip), %eax
imull   d(%rip), %eax
imull   e(%rip), %eax
movl%eax, a(%rip)
ret
[...@gnu-6 44382]$ gcc -S -O2 x.i -fno-tree-reassoc
[...@gnu-6 44382]$ cat x.s
.file   "x.i"
.text
.p2align 4,,15
.globl foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
movlb(%rip), %eax
movld(%rip), %edx
imull   c(%rip), %eax
imull   e(%rip), %edx
imull   %edx, %eax
movl%eax, a(%rip)
ret
[...@gnu-6 44382]$ 


-- 


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

[Bug other/44414] hashtab.h functions are undocumented

[ro at gcc dot gnu dot org]

--- Comment #2 from ro at gcc dot gnu dot org  2010-06-04 12:58 ---
This is not proper documentation: most part of libiberty use comments which
can be extracted and put into the .texi files, while hashtab.c does not.


-- 

ro at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|WORKSFORME  |


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

[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously

[ro at gcc dot gnu dot org]

--- Comment #16 from ro at gcc dot gnu dot org  2010-06-04 12:53 ---
Confirmed: fails for 32-bit and Solaris 10+, unsupported on Solaris 8 and 9.


-- 

ro at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ro at gcc dot gnu dot org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
 GCC target triplet|i386-pc-solaris2.11 |i386-pc-solaris2.1[01]
  Known to fail||4.4.5 4.5.1 4.6.0
   Last reconfirmed|-00-00 00:00:00 |2010-06-04 12:53:55
   date||


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

[Bug libgcj/44415] [4.6 regression] gmp multilib support broke bootstrap with static libgmp

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0


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

[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry

[rguenth at gcc dot gnu dot org]

--- Comment #37 from rguenth at gcc dot gnu dot org  2010-06-04 12:45 
---
Subject: Bug 41371

Author: rguenth
Date: Fri Jun  4 12:44:41 2010
New Revision: 160261

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160261
Log:
2010-06-04  Richard Guenther  

Backport from mainline:
2010-05-18  Jakub Jelinek  

PR debug/41371
* var-tracking.c (find_loc_in_1pdv): Add a few checks from
rtx_equal_p inline.

2010-05-25  Jakub Jelinek  

PR debug/41371
* var-tracking.c (find_loc_in_1pdv): Guard asserts with
ENABLE_CHECKING.
(intersect_loc_chains): Walk the s2var's loc_chain together
with s1node chain as long as the locations are equal, don't
call find_loc_in_1pdv in that case.

Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/var-tracking.c


-- 


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

[Bug rtl-optimization/40615] unnecessary CSE

[bernds at gcc dot gnu dot org]

--- Comment #7 from bernds at gcc dot gnu dot org  2010-06-04 12:44 ---
Subject: Bug 40615

Author: bernds
Date: Fri Jun  4 12:44:01 2010
New Revision: 160260

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160260
Log:
PR rtl-optimization/39871
PR rtl-optimization/40615
PR rtl-optimization/42500
PR rtl-optimization/42502
* ira.c (init_reg_equiv_memory_loc: New function.
(ira): Call it twice.
* reload.h (calculate_elim_costs_all_insns): Declare.
* ira-costs.c: Include "reload.h".
(regno_equiv_gains): New static variable.
(init_costs): Allocate it.
(finish_costs): Free it.
(ira_costs): Call calculate_elim_costs_all_insns.
(find_costs_and_classes): Take estimated elimination costs
into account.
(ira_adjust_equiv_reg_cost): New function.
* ira.h (ira_adjust_equiv_reg_cost): Declare it.
* reload1.c (init_eliminable_invariants, free_reg_equiv,
elimination_costs_in_insn, note_reg_elim_costly): New static
functions.
(elim_bb): New static variable.
(reload): Move code out of here into init_eliminable_invariants and
free_reg_equiv.  Call them.
(calculate_elim_costs_all_insns): New function.
(eliminate_regs_1): Declare.  Add extra arg FOR_COSTS;
all callers changed.  If FOR_COSTS is true, don't call alter_reg,
but call note_reg_elim_costly if we turned a valid memory address
into an invalid one.
* Makefile.in (ira-costs.o): Depend on reload.h.

testsuite/
PR rtl-optimization/39871
PR rtl-optimization/40615
PR rtl-optimization/42500
PR rtl-optimization/42502
* gcc.target/arm/eliminate.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/arm/eliminate.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/ira-costs.c
trunk/gcc/ira.c
trunk/gcc/ira.h
trunk/gcc/reload.h
trunk/gcc/reload1.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug rtl-optimization/39871] [4.3/4.4/4.5/4.6 regression] Code size increase on ARM due to poor register allocation

[bernds at gcc dot gnu dot org]

--- Comment #24 from bernds at gcc dot gnu dot org  2010-06-04 12:44 ---
Subject: Bug 39871

Author: bernds
Date: Fri Jun  4 12:44:01 2010
New Revision: 160260

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160260
Log:
PR rtl-optimization/39871
PR rtl-optimization/40615
PR rtl-optimization/42500
PR rtl-optimization/42502
* ira.c (init_reg_equiv_memory_loc: New function.
(ira): Call it twice.
* reload.h (calculate_elim_costs_all_insns): Declare.
* ira-costs.c: Include "reload.h".
(regno_equiv_gains): New static variable.
(init_costs): Allocate it.
(finish_costs): Free it.
(ira_costs): Call calculate_elim_costs_all_insns.
(find_costs_and_classes): Take estimated elimination costs
into account.
(ira_adjust_equiv_reg_cost): New function.
* ira.h (ira_adjust_equiv_reg_cost): Declare it.
* reload1.c (init_eliminable_invariants, free_reg_equiv,
elimination_costs_in_insn, note_reg_elim_costly): New static
functions.
(elim_bb): New static variable.
(reload): Move code out of here into init_eliminable_invariants and
free_reg_equiv.  Call them.
(calculate_elim_costs_all_insns): New function.
(eliminate_regs_1): Declare.  Add extra arg FOR_COSTS;
all callers changed.  If FOR_COSTS is true, don't call alter_reg,
but call note_reg_elim_costly if we turned a valid memory address
into an invalid one.
* Makefile.in (ira-costs.o): Depend on reload.h.

testsuite/
PR rtl-optimization/39871
PR rtl-optimization/40615
PR rtl-optimization/42500
PR rtl-optimization/42502
* gcc.target/arm/eliminate.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/arm/eliminate.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/ira-costs.c
trunk/gcc/ira.c
trunk/gcc/ira.h
trunk/gcc/reload.h
trunk/gcc/reload1.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug rtl-optimization/42500] Unnecessary mov of sp to a register

[bernds at gcc dot gnu dot org]

--- Comment #6 from bernds at gcc dot gnu dot org  2010-06-04 12:44 ---
Subject: Bug 42500

Author: bernds
Date: Fri Jun  4 12:44:01 2010
New Revision: 160260

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160260
Log:
PR rtl-optimization/39871
PR rtl-optimization/40615
PR rtl-optimization/42500
PR rtl-optimization/42502
* ira.c (init_reg_equiv_memory_loc: New function.
(ira): Call it twice.
* reload.h (calculate_elim_costs_all_insns): Declare.
* ira-costs.c: Include "reload.h".
(regno_equiv_gains): New static variable.
(init_costs): Allocate it.
(finish_costs): Free it.
(ira_costs): Call calculate_elim_costs_all_insns.
(find_costs_and_classes): Take estimated elimination costs
into account.
(ira_adjust_equiv_reg_cost): New function.
* ira.h (ira_adjust_equiv_reg_cost): Declare it.
* reload1.c (init_eliminable_invariants, free_reg_equiv,
elimination_costs_in_insn, note_reg_elim_costly): New static
functions.
(elim_bb): New static variable.
(reload): Move code out of here into init_eliminable_invariants and
free_reg_equiv.  Call them.
(calculate_elim_costs_all_insns): New function.
(eliminate_regs_1): Declare.  Add extra arg FOR_COSTS;
all callers changed.  If FOR_COSTS is true, don't call alter_reg,
but call note_reg_elim_costly if we turned a valid memory address
into an invalid one.
* Makefile.in (ira-costs.o): Depend on reload.h.

testsuite/
PR rtl-optimization/39871
PR rtl-optimization/40615
PR rtl-optimization/42500
PR rtl-optimization/42502
* gcc.target/arm/eliminate.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/arm/eliminate.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/ira-costs.c
trunk/gcc/ira.c
trunk/gcc/ira.h
trunk/gcc/reload.h
trunk/gcc/reload1.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug rtl-optimization/42502] [4.4/4.5/4.6 Regression] Bad register allocation in a very simple code

[bernds at gcc dot gnu dot org]

--- Comment #7 from bernds at gcc dot gnu dot org  2010-06-04 12:44 ---
Subject: Bug 42502

Author: bernds
Date: Fri Jun  4 12:44:01 2010
New Revision: 160260

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160260
Log:
PR rtl-optimization/39871
PR rtl-optimization/40615
PR rtl-optimization/42500
PR rtl-optimization/42502
* ira.c (init_reg_equiv_memory_loc: New function.
(ira): Call it twice.
* reload.h (calculate_elim_costs_all_insns): Declare.
* ira-costs.c: Include "reload.h".
(regno_equiv_gains): New static variable.
(init_costs): Allocate it.
(finish_costs): Free it.
(ira_costs): Call calculate_elim_costs_all_insns.
(find_costs_and_classes): Take estimated elimination costs
into account.
(ira_adjust_equiv_reg_cost): New function.
* ira.h (ira_adjust_equiv_reg_cost): Declare it.
* reload1.c (init_eliminable_invariants, free_reg_equiv,
elimination_costs_in_insn, note_reg_elim_costly): New static
functions.
(elim_bb): New static variable.
(reload): Move code out of here into init_eliminable_invariants and
free_reg_equiv.  Call them.
(calculate_elim_costs_all_insns): New function.
(eliminate_regs_1): Declare.  Add extra arg FOR_COSTS;
all callers changed.  If FOR_COSTS is true, don't call alter_reg,
but call note_reg_elim_costly if we turned a valid memory address
into an invalid one.
* Makefile.in (ira-costs.o): Depend on reload.h.

testsuite/
PR rtl-optimization/39871
PR rtl-optimization/40615
PR rtl-optimization/42500
PR rtl-optimization/42502
* gcc.target/arm/eliminate.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/arm/eliminate.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/ira-costs.c
trunk/gcc/ira.c
trunk/gcc/ira.h
trunk/gcc/reload.h
trunk/gcc/reload1.c
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug libgcj/44415] New: [4.6 regression] gmp multilib support broke bootstrap with static libgmp

[ro at gcc dot gnu dot org]

The recent introduction of this patch

2010-05-29  Mike Stump  

* configure.ac: Add multilib support for gmp.  Proper -I and -L
flags for gmp are added.

broke bootstrap on i386-pc-solaris2.11 and almost certainly at least all
Solaris 2
platforms with a static libgmp:

/bin/ksh ../../../libtool --tag=CC   --mode=link
/vol/gcc/obj/gcc-4.6.0-20100602/11-gcc/./gcc/xgcc
-B/vol/gcc/obj/gcc-4.6.0-20100602/11-gcc/./gcc/
-B/vol/gcc/i386-pc-solaris2.11/bin/ -B/vol/gcc/i386-pc-solaris2.11/lib/
-isystem /vol/gcc/i386-pc-solaris2.11/include -isystem
/vol/gcc/i386-pc-solaris2.11/sys-include-W -Wall -Wmissing-declarations
-Wwrite-strings -Wmissing-prototypes -Wno-long-long  -I/vol/gcc/include  -g -O2
-module -version-info 0:0:0 -no-undefined -L/vol/gcc/lib -lgmp -avoid-version 
-o libjavamath.la -rpath /vol/gcc/lib/gcj-4.6.0-11 gnu_java_math_GMP.lo
../../../native/jni/classpath/jcl.lo -lsocket -lnsl 
libtool: link: /vol/gcc/obj/gcc-4.6.0-20100602/11-gcc/./gcc/xgcc
-B/vol/gcc/obj/gcc-4.6.0-20100602/11-gcc/./gcc/
-B/vol/gcc/i386-pc-solaris2.11/bin/ -B/vol/gcc/i386-pc-solaris2.11/lib/
-isystem /vol/gcc/i386-pc-solaris2.11/include -isystem
/vol/gcc/i386-pc-solaris2.11/sys-include-shared -Wl,-z -Wl,text -Wl,-h
-Wl,libjavamath.so -o .libs/libjavamath.so  .libs/gnu_java_math_GMP.o
../../../native/jni/classpath/.libs/jcl.o   -L/vol/gcc/lib
/vol/gcc/lib/libgmp.a -lsocket -lnsl -lc   
Text relocation remains referenced
against symbol  offset  in file
.rodata.str1.4 (section)0x2e   
/vol/gcc/lib/libgmp.a(lt19-get_str.o)
[...]

The static libgmp is usually non-PIC, while we need PIC code to link
libjavamath.so.

It turned out to be remarkably difficult to work around this:

* While gcc on Solaris supports -mimpure-text to allow linking of non-PIC code
  into a shared library, all this does is disable the implicit -z text enabled
  by gcc -shared.  Since libtool passes -z text by itself, this doesn't help.

* Sun ld doesn't allow -z text -z textoff, so I had to resort to edititing
  -z text out of libtool and adding -mimpure-text after the -shared there.

To fix this for real, one needs to build a PIC libgmp.a, which at the very
least
needs to be documented.

Apart from that, the patch has a couple of other problems:

* The ChangeLog entry belongs into classpath/ChangeLog, not libjava/ChangeLog.

* For multilibbed targets, it used to be enough to have libgmp for the default
  multilib.  Now you need libgmp for every multilib, otherwise the facitilies
  between e.g. 32-bit and 64-bit libjavamath.so differ.

* There seems to be no provision to pass in -L and -R flags for the non-default
  multilibs, and neither libtool nor the libjava/classpath make machinery seem
  to support automatically looking in e.g. $libdir/amd64 for 64-bit multilibs.

It seems this needs considerably more work to be complete and useful.


-- 
   Summary: [4.6 regression] gmp multilib support broke bootstrap
with static libgmp
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: libgcj
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at gcc dot gnu dot org
 GCC build triplet: *-*-solaris2.*
  GCC host triplet: *-*-solaris2.*
GCC target triplet: *-*-solaris2.*


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

[Bug other/44414] hashtab.h functions are undocumented

[rguenth at gcc dot gnu dot org]

--- Comment #1 from rguenth at gcc dot gnu dot org  2010-06-04 12:32 ---
libiberty has documentation in source libiberty/hashtab.c.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WORKSFORME


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

[Bug other/44414] New: hashtab.h functions are undocumented

[ro at gcc dot gnu dot org]

When I recently needed to use htab_* functions from libiberty's hashtab.h, I
found
that they are completely undocumented: the comments in the header aren't enough
to use them, so I had to look at both the implementation and other uses to
figure
things out.


-- 
   Summary: hashtab.h functions are undocumented
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Keywords: documentation
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at gcc dot gnu dot org


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

[Bug fortran/40452] -fbounds-check: False positive due to ignoring storage association

[burnus at gcc dot gnu dot org]

--- Comment #6 from burnus at gcc dot gnu dot org  2010-06-04 12:22 ---
Yes, we can CLOSE the bug as FIXED.


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug libstdc++/44413] New: inefficient code for std::string::compare on x86-64

[dgohman at gmail dot com]

This code:

#include 
int foo(const std::string &a, const std::string &b) { return a.compare(b); }

compiles to code like this on x86-64:
[...]
subq%rdx, %r8
movl$2147483647, %eax
cmpq$2147483647, %r8
jg  .L2
movl$-2147483648, %eax
cmpq$-2147483648, %r8
cmovge  %r8d, %eax
.L2:
[...]

Since compare need only return a value greater, less, or equal to zero, the
code in _S_compare would be more efficient as simple code that just returns -1,
0, or 1 on most targets where difference_type is wider than int.


-- 
   Summary: inefficient code for std::string::compare on x86-64
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dgohman at gmail dot com


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

[Bug c++/44412] [4.6 Regression] Another bogus set-but-not-used warning

[jakub at gcc dot gnu dot org]

--- Comment #1 from jakub at gcc dot gnu dot org  2010-06-04 12:03 ---
More complete testcase:

// PR c++/44412
// { dg-do compile }
// { dg-options "-Wunused" }

struct S
{
  static const int a = 3;
  static int b;
  int c;
};

const int S::a;
int S::b = 4;

int
f1 ()
{
  S s;
  return s.a;
}

int
f2 ()
{
  S s;
  return s.b;
}

void
f3 ()
{
  S s;
  s.c = 6;// { dg-warning "set but not used" }
}

int
f4 ()
{
  S s;
  s.c = 6;
  return s.c;
}

Guess we should mark the object through which a static data member is accessed,
because that access already marks the object as TREE_USED, yet it is not a set
of the object.  Not sure where to do that though.  Calling methods or static
methods apparently is handled already, in both cases build_new_method_call
-> build_this -> cp_build_unary_op ADDR_EXPR -> mark_lvalue_use ->
mark_exp_read takes care of it:

// PR c++/44412
// { dg-do compile }
// { dg-options "-Wunused" }

struct S
{
  int foo ();
  static int bar ();
};

int S::foo ()
{
  return 5;
}

int S::bar ()
{
  return 6;
}

int
f1 ()
{
  S s;
  return s.foo ();
}

int
f2 ()
{
  S s;
  return s.bar ();
}


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dodji at gcc dot gnu dot
   ||org, jason at gcc dot gnu
   ||dot org
Summary|Another bogus set-but-not-  |[4.6 Regression] Another
   |used warning|bogus set-but-not-used
   ||warning
   Target Milestone|--- |4.6.0


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

[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry

[jakub at gcc dot gnu dot org]

--- Comment #36 from jakub at gcc dot gnu dot org  2010-06-04 11:15 ---
With Alex' patch with checking guarded with #ifdef ENABLE_CHECKING (currently
bootstrapping/regtesting that) I see on x86_64 on the trunk:
time ./cc1plus -m32 -quiet -g -Os -fomit-frame-pointer bug-611650_analysis.ii 

real2m16.789s
user2m16.333s
sys 0m0.276s

Of course not ideal, but much better than those 103 minutes.


-- 


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

[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry

[rguenth at gcc dot gnu dot org]

--- Comment #35 from rguenth at gcc dot gnu dot org  2010-06-04 11:03 
---
Created an attachment (id=20837)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20837&action=view)
bnc611650

Another testcase from open-office this time, on i?86-linux only.

$> time  g++ -c -g -Os -fomit-frame-pointer analysis.ii

real103m46.642s
user96m21.093s
sys 0m1.196s

$> time g++ -c -g -Os analysis.ii

real0m19.345s
user0m19.177s
sys 0m0.168s

$> time  g++ -c -Os -fomit-frame-pointer analysis.ii

real0m3.747s
user0m3.640s
sys 0m0.104s

numbers above are from the 4.5 branch rev. 159866.  trunk is also very slow,
but the compile didn't yet finish.


-- 


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

[Bug lto/41584] WHOPR doesn't grok empty units

[rguenth at gcc dot gnu dot org]

--- Comment #7 from rguenth at gcc dot gnu dot org  2010-06-04 11:00 ---
Subject: Bug 41584

Author: rguenth
Date: Fri Jun  4 11:00:09 2010
New Revision: 160258

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160258
Log:
2010-06-04  Richard Guenther  

PR lto/41584
* cgraph.h (struct varpool_node): Add lto_file_data field.
* lto-cgraph.c (input_varpool_node): Initialize it.

lto/
* lto.c (lto_1_to_1_map): Use the proper file_data for
varpool nodes.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraph.h
trunk/gcc/lto-cgraph.c
trunk/gcc/lto/ChangeLog
trunk/gcc/lto/lto.c


-- 


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

[Bug lto/44408] FAIL: gcc.dg/lto/20100603-2 c_lto_20100603-2_0.o-c_lto_20100603-2_0.o

[rguenth at gcc dot gnu dot org]

--- Comment #2 from rguenth at gcc dot gnu dot org  2010-06-04 11:00 ---
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry

[aoliva at gcc dot gnu dot org]

--- Comment #34 from aoliva at gcc dot gnu dot org  2010-06-04 10:03 ---
Created an attachment (id=20836)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20836&action=view)
Patch that fixes the bug and verifies recursion is bounded as expected

This patch (except for comments and ChangeLog) completed stage1 libs, more
testing needed.


-- 


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

[Bug testsuite/43759] The tests gcc.dg/plugindir*.c should be restricted to builds configured with --enable-plugin

[doko at ubuntu dot com]

--- Comment #4 from doko at ubuntu dot com  2010-06-04 09:53 ---
this is fixed on the trunk


-- 


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

[Bug bootstrap/43847] test for plugin is using wrong objdump for host != target

[doko at ubuntu dot com]

--- Comment #2 from doko at ubuntu dot com  2010-06-04 09:51 ---
having an objdump which supports both the host and the target works around this
issue.


-- 


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