[Bug c++/2288] Variable declared in for-loop-header is in wrong scope

[froydnj at gcc dot gnu.org]

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

Nathan Froyd  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #20 from Nathan Froyd  2011-06-05 
02:08:38 UTC ---
This bug was fixed on trunk in r174307; the automated update was not done
because something was wonky with my email.  Closing.

[Bug c++/18770] g++ accepts invalid code with scopes on ifs

[froydnj at gcc dot gnu.org]

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

Nathan Froyd  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||froydnj at gcc dot gnu.org
 Resolution||FIXED

--- Comment #8 from Nathan Froyd  2011-06-05 
02:09:41 UTC ---
This bug was fixed on trunk in r174307; the automated update was not done
because something was wonky with my email.  Closing.

[Bug regression/49285] [4.7 Regression]: build fails on mmix in libgcc2.c:__powisf2: ICE in emit_unop_insn

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.05 02:04:47
 AssignedTo|unassigned at gcc dot   |hp at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #1 from Hans-Peter Nilsson  2011-06-05 
02:04:47 UTC ---
Created attachment 24434
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24434
Preprocessed libgcc2.i, repeat ICE for mmix with  -fpreprocessed libgcc2.i -O2

Investigating.

[Bug regression/49285] New: [4.7 Regression]: build fails on mmix in libgcc2.c:__powisf2: ICE in emit_unop_insn

[hp at gcc dot gnu.org]

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

   Summary: [4.7 Regression]: build fails on mmix in
libgcc2.c:__powisf2: ICE in emit_unop_insn
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: build, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: regression
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: h...@gcc.gnu.org
  Host: x86_64-unknown-linux-gnu
Target: mmix


Build fails on trunk (r174648) for mmix, last worked r171197:
/tmp/pr48542bl47/gccobj/./gcc/xgcc -B/tmp/pr48542bl47/gccobj/./gcc/ -nostdinc
-B/tmp/pr48542bl47/gccobj/mmix/newlib/ -i\
system /tmp/pr48542bl47/gccobj/mmix/newlib/targ-include -isystem
/tmp/pr48542bl47/gcc/newlib/libc/include -B/tmp/pr4854\
2bl47/gccobj/mmix/libgloss/mmix
-L/tmp/pr48542bl47/gccobj/mmix/libgloss/libnosys
-L/tmp/pr48542bl47/gcc/libgloss/mmix -\
B/tmp/pr48542bl47/pre/mmix/bin/ -B/tmp/pr48542bl47/pre/mmix/lib/ -isystem
/tmp/pr48542bl47/pre/mmix/include -isystem /t\
mp/pr48542bl47/pre/mmix/sys-include-g -O2 -mabi=gnu -O2  -g -O2 -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwr\
ite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include  -mlibfuncs\
 -O2 -g  -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -fno-stack-protector
-Dinhibit_libc  -I. -I. -I../../.././gcc -I/tmp/pr4\
8542bl47/gcc/libgcc -I/tmp/pr48542bl47/gcc/libgcc/.
-I/tmp/pr48542bl47/gcc/libgcc/../gcc -I/tmp/pr48542bl47/gcc/libgcc/\
../include  -DHAVE_CC_TLS -DUSE_EMUTLS -o _powisf2.o -MT _powisf2.o -MD -MP -MF
_powisf2.dep -DL_powisf2 -c /tmp/pr4854\
2bl47/gcc/libgcc/../gcc/libgcc2.c \

/tmp/pr48542bl47/gcc/libgcc/../gcc/libgcc2.c: In function '__powisf2':
/tmp/pr48542bl47/gcc/libgcc/../gcc/libgcc2.c:1730:9: internal compiler error:
in emit_unop_insn, at optabs.c:3555

The last known "working" revision is taken from the gcc-testresults list,
.

[Bug c++/49266] [C++0x] Another incomplete type regression with noexcept

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from Jason Merrill  2011-06-04 
23:42:03 UTC ---
(In reply to comment #1)
> Thanks Marc. I guess we need a definitive word here about whether these are 
> c++
> front issues or unavoidable problems caused by the implementation of the 
> traits
> via sfinae.

This definitely is not a front end bug.

> In the latter case we have unfortunately to be prepared to revert
> all the noexcept work involving traits until we get front-end support. Very
> sad, of course: personally, I didn't think sfinae-based techniques had serious
> limitations besides access-control. Would be something worth popularizing, can
> affect a lot of sfinae uses outside the library too, of course.

I don't think this is a sfinae vs intrinsic traits issue; intrinsic traits
would do basically the same thing.  It's an issue of involving traits/sfinae in
function signatures so that we trigger more instantiations when considering a
function during overload resolution rather than later, when the function is
instantiated.  The idea about deferring instantiation of exception-specifiers
seems likely to address this for noexcept specifically, but there might be
similar issues caused by increased use of sfinae for selecting between
overloads.

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

[Bug c++/49107] [C++0x][4.7 Regression] incomplete type regression with std::pair

[jason at gcc dot gnu.org]

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

--- Comment #16 from Jason Merrill  2011-06-04 
23:42:03 UTC ---
*** Bug 49266 has been marked as a duplicate of this bug. ***

[Bug c++/49107] [C++0x][4.7 Regression] incomplete type regression with std::pair

[jason at gcc dot gnu.org]

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

--- Comment #15 from Jason Merrill  2011-06-04 
23:35:38 UTC ---
Created attachment 24433
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24433
Patch to generalize the copy hack in the compiler

Here's the patch I was working with, if you're interested.  I don't think we
want to go this way, since it breaks auto_ptr, but perhaps we don't need the
auto_ptr hack in C++0x since we have rvalue references...

[Bug bootstrap/49275] --enable-build-with-cxx profiledbootstrap BOOT_CFLAGS="-g -O3" CFLAGS_FOR_TARGET="-g -O3" CXXFLAGS_FOR_TARGET="-g -O3" failure

[howarth at nitro dot med.uc.edu]

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

--- Comment #3 from Jack Howarth  2011-06-04 
23:20:14 UTC ---
This problem no longer exists at r174648 with
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg02301.html installed. A
profiledbootstrap BOOT_CFLAGS="-g -O3" CFLAGS_FOR_TARGET="-g -O3"
CXXFLAGS_FOR_TARGET="-g -O3" using --enable-build-with-cxx succeeds on x86_64
darwin.

[Bug other/49284] -fdump-ipa-cgraph leads to ICE in generate_canonical_option, at opts-common.c:303

[andi-gcc at firstfloor dot org]

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

--- Comment #1 from Andi Kleen  2011-06-04 
22:13:34 UTC ---
Some investigation:

This depends heavily on the command line used.

A simple test with a hello world works.

On my kernel build when I strip the lto link command line down I get
the error with

gcc47 -fdump-cgraph-ipa -nostdlib -fuse-linker-plugin -flto=jobserver
-fwhole-program -Wl,-m,elf_x86_64 -Wl,--build-id -o .tmp_vmlinux1
-Wl,-T,arch/x86/kernel/vmlinux.lds arch/x86/kernel/head_64.o
arch/x86/kernel/head_64.o

and not with (last file deleted)

gcc47 -fdump-cgraph-ipa -nostdlib -fuse-linker-plugin -flto=jobserver
-fwhole-program -Wl,-m,elf_x86_64 -Wl,--build-id -o .tmp_vmlinux1
-Wl,-T,arch/x86/kernel/vmlinux.lds arch/x86/kernel/head_64.o

[Bug middle-end/49282] malloc corruption in large lto1-wpa run during inline edge heap resize

[andi-gcc at firstfloor dot org]

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

--- Comment #2 from Andi Kleen  2011-06-04 
20:57:59 UTC ---
I found a workaround: disabling -fcoverage-arcs (gcov) makes it go
away.

[Bug middle-end/49282] malloc corruption in large lto1-wpa run during inline edge heap resize

[andi-gcc at firstfloor dot org]

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

--- Comment #1 from Andi Kleen  2011-06-04 
19:56:15 UTC ---
Some updates:

I tried with a fresh compiler (20110604). Same malloc assert

I also checked with a somewhat older compiler (from around May 11)
It segfaulted eventually too, so I suspect the problem has been 
there for longer.

[Bug other/49284] New: -fdump-ipa-cgraph leads to ICE in generate_canonical_option, at opts-common.c:303

[andi-gcc at firstfloor dot org]

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

   Summary: -fdump-ipa-cgraph leads to ICE in
generate_canonical_option, at opts-common.c:303
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: andi-...@firstfloor.org


gcc version 4.7.0 20110604 (experimental) (GCC) 


Passing -fdump-ipa-cgraph to a IPA final build gives:

lto1: internal compiler error: in generate_canonical_option, at
opts-common.c:303

[Bug tree-optimization/48929] [4.7 Regression] ICE: in estimate_size_after_inlining, at ipa-inline-analysis.c:1961 with -findirect-inlining

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #4 from Jan Hubicka  2011-06-04 
18:07:27 UTC ---
Fixed.

[Bug c/49091] ice in evaluate_conditions_for_known_args

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #4 from Jan Hubicka  2011-06-04 
18:06:40 UTC ---
Fixed.

[Bug fortran/48636] Enable more inlining with -O2 and higher

[hubicka at gcc dot gnu.org]

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

--- Comment #14 from Jan Hubicka  2011-06-04 
18:06:01 UTC ---
Yeah, the fnspec issue is something we ought to solve. ipa-cp should be
effective on fortran so it should not disable itself there ;)

[Bug middle-end/49179] [4.7 Regression] ICE: in evaluate_conditions_for_known_args at ipa-inline-analysis.c:558 with -O -findirect-inlining

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #3 from Jan Hubicka  2011-06-04 
18:03:05 UTC ---
Fixed.

[Bug middle-end/48893] [4.7 Regression] ICE in evaulate_conditions_for_edge at ipa-inline-analysis.c:477

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2011.06.04 18:03:43
 Ever Confirmed|0   |1

--- Comment #6 from Jan Hubicka  2011-06-04 
18:03:43 UTC ---
Hi,
can you please confirm that the problem is gone?

[Bug middle-end/49179] [4.7 Regression] ICE: in evaluate_conditions_for_known_args at ipa-inline-analysis.c:558 with -O -findirect-inlining

[hubicka at gcc dot gnu.org]

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

--- Comment #2 from Jan Hubicka  2011-06-04 
18:00:51 UTC ---
Author: hubicka
Date: Sat Jun  4 18:00:47 2011
New Revision: 174648

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174648
Log:
PR tree-optimization/48893
PR tree-optimization/49091
PR tree-optimization/49179
* ipa-inline-analysis.c (evaluate_conditions_for_known_args):
Bounds check.

* gfortran.dg/pr49179.f90: New testcase

Added:
trunk/gcc/testsuite/gfortran.dg/pr49179.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-inline-analysis.c
trunk/gcc/testsuite/ChangeLog

[Bug c/49091] ice in evaluate_conditions_for_known_args

[hubicka at gcc dot gnu.org]

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

--- Comment #3 from Jan Hubicka  2011-06-04 
18:00:51 UTC ---
Author: hubicka
Date: Sat Jun  4 18:00:47 2011
New Revision: 174648

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174648
Log:
PR tree-optimization/48893
PR tree-optimization/49091
PR tree-optimization/49179
* ipa-inline-analysis.c (evaluate_conditions_for_known_args):
Bounds check.

* gfortran.dg/pr49179.f90: New testcase

Added:
trunk/gcc/testsuite/gfortran.dg/pr49179.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-inline-analysis.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/48893] [4.7 Regression] ICE in evaulate_conditions_for_edge at ipa-inline-analysis.c:477

[hubicka at gcc dot gnu.org]

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

--- Comment #5 from Jan Hubicka  2011-06-04 
18:00:51 UTC ---
Author: hubicka
Date: Sat Jun  4 18:00:47 2011
New Revision: 174648

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174648
Log:
PR tree-optimization/48893
PR tree-optimization/49091
PR tree-optimization/49179
* ipa-inline-analysis.c (evaluate_conditions_for_known_args):
Bounds check.

* gfortran.dg/pr49179.f90: New testcase

Added:
trunk/gcc/testsuite/gfortran.dg/pr49179.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-inline-analysis.c
trunk/gcc/testsuite/ChangeLog

[Bug lto/48952] ICE in inline_merge_summary during linux kernel LTO build

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #4 from Jan Hubicka  2011-06-04 
17:14:27 UTC ---
Fixed.

[Bug c++/49279] Optimization incorrectly presuming constant variable inside loop in g++ 4.5 and 4.6 with -O2 and -O3 for x86_64 targets

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.04 16:37:22
 CC||rguenth at gcc dot gnu.org
   Target Milestone|--- |4.5.4
 Ever Confirmed|0   |1

--- Comment #1 from H.J. Lu  2011-06-04 16:37:22 
UTC ---
It is caused by revision 155360:

http://gcc.gnu.org/ml/gcc-cvs/2009-12/msg00504.html

[Bug c++/7302] -Wnon-virtual-dtor should't complain of protected dtor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #29 from Jonathan Wakely  2011-06-04 
16:24:50 UTC ---
For G++ 4.7 I've added -Wdelete-non-virtual-dtor, included in -Wall, to handle
the case in comment 25, so closing this as fixed now

[Bug c++/33840] bit-field size accepted for struct

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #6 from Jonathan Wakely  2011-06-04 
16:22:20 UTC ---
Thanks, Volker, tests added so closing

[Bug fortran/49271] Compiler crashed and asked me to submit a report

[dominiq at lps dot ens.fr]

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

--- Comment #10 from Dominique d'Humieres  
2011-06-04 16:22:18 UTC ---
> I don't use Mac OS X ...

I do;-) The simplest ways are to build it either with fink (
http://www.finkproject.org/ : gcc4.5.2) or macports ( http://www.macports.org/
: gcc4.5.3 or 4.6 beta).

[Bug c++/33840] bit-field size accepted for struct

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2011-06-04 
16:21:00 UTC ---
Author: redi
Date: Sat Jun  4 16:20:55 2011
New Revision: 174645

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174645
Log:
2011-06-04  Jonathan Wakely  

PR c++/33840
* g++.dg/diagnostic/bitfld2.C: New.


Added:
branches/gcc-4_6-branch/gcc/testsuite/g++.dg/diagnostic/bitfld2.C
Modified:
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug lto/48954] [4.7 Regression] ICE: SIGSEGV in bitmap_count_bits (bitmap.c:719) with -O2 -flto -fno-early-inlining -fkeep-inline-functions

[hubicka at gcc dot gnu.org]

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

--- Comment #5 from Jan Hubicka  2011-06-04 
16:20:42 UTC ---
Author: hubicka
Date: Sat Jun  4 16:20:36 2011
New Revision: 174644

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

PR lto/48954
* lto-cgraph.c (output_node_opt_summary): Handle NULL skip args bitmaps.
* g++.dg/torture/pr48954.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr48954.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-cgraph.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/33840] bit-field size accepted for struct

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  2011-06-04 
16:11:47 UTC ---
Author: redi
Date: Sat Jun  4 16:11:41 2011
New Revision: 174642

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174642
Log:
2011-06-04  Jonathan Wakely  

PR c++/33840
* g++.dg/diagnostic/bitfld2.C: New.


Added:
trunk/gcc/testsuite/g++.dg/diagnostic/bitfld2.C
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug target/49281] lea_general_4 is wrong

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Jakub Jelinek  2011-06-04 
16:01:12 UTC ---
Fixed.

[Bug target/48688] [x64]: shift/or instead of lea

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

--- Comment #10 from Jakub Jelinek  2011-06-04 
16:00:29 UTC ---
Should be fixed now, sorry.

[Bug fortran/49271] Compiler crashed and asked me to submit a report

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #9 from Steve Kargl  
2011-06-04 15:56:35 UTC ---
On Sat, Jun 04, 2011 at 01:09:06AM +, coml4 at san dot rr.com wrote:
> I will be happy to update the compiler.  I very recently downloaded the latest
> one that was labeled "Stable Release" for Mac OS X.  Which version do you
> recommend?

I don't use Mac OS X, so I do not know what is
available.  If you can find it, try a 4.6.1
version.

[Bug target/49281] lea_general_4 is wrong

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  2011-06-04 
15:38:39 UTC ---
Author: jakub
Date: Sat Jun  4 15:38:36 2011
New Revision: 174641

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174641
Log:
PR target/49281
* config/i386/i386.md (*lea_general_4): Require INTVAL (operands[3])
to be strictly smaller than 1 << shiftcount.

* gcc.c-torture/execute/pr49281.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr49281.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog

[Bug target/49281] lea_general_4 is wrong

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu  2011-06-04 15:31:29 
UTC ---
(In reply to comment #4)
> Created attachment 24432 [details]
> gcc47-pr49281.patch
> 
> Yeah, I think it should have be < instead of <=.
> Will try to write some testcase...

This seems to work.  Thanks.

[Bug target/49281] lea_general_4 is wrong

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.06.04 15:22:35
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1

--- Comment #4 from Jakub Jelinek  2011-06-04 
15:22:35 UTC ---
Created attachment 24432
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24432
gcc47-pr49281.patch

Yeah, I think it should have be < instead of <=.
Will try to write some testcase...

[Bug target/48688] [x64]: shift/or instead of lea

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Blocks||49281
 Resolution|FIXED   |

--- Comment #9 from H.J. Lu  2011-06-04 15:22:19 
UTC ---
I don't think the fix is correct. See PR 49281.

[Bug target/49281] lea_general_4 is wrong

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0
Summary|lea_general_4 doesn't work  |lea_general_4 is wrong
   |for x32 |

--- Comment #3 from H.J. Lu  2011-06-04 15:16:38 
UTC ---
I don't think from

 movl%eax, %ecx
 orl$1, %ecx
 sall$2, %ecx

to

   leal4(,%rax,4), %ecx

is valid transformation. For EAX == 43,

leal4(,%rax,4), %ecx

gives "43*4 + 4" == 176. But

 movl%eax, %ecx
 orl$1, %ecx
 sall$2, %ecx

gives "(43 | 1) << 2" == 172.  I don't see how it can work.

[Bug target/49281] lea_general_4 doesn't work for x32

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  2011-06-04 14:57:08 
UTC ---
Created attachment 24431
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24431
A testcase

I got

(gdb) r -d foreman_ref_encoder_main.cfg
Starting program: /export/home/hjl/bugs/gcc/pr49281/run/h264ref -d
foreman_ref_encoder_main.cfg
Setting Default Parameters...
Parsing Configfile
foreman_ref_encoder_main.cfg.

--- JM 9.3 (FRExt) 
 Input YUV file: foreman_qcif.yuv 
 Output H.264 bitstream: encoded_main.264 
 YUV Format: YUV 4:2:0 
 Frames to be encoded I-P/B: 62/61
 PicInterlace / MbInterlace: 0/0
 Transform8x8Mode  : 0
---
  Frame  Bit/pic WP QP   SnrYSnrUSnrVTime(ms) MET(ms) Frm/Fld   I D
---
(NVB) 176 
(IDR)   21032 0 28  37.449  41.305  43.0590   0 FRM99
0002(P)  5184 0 28  36.974  41.078  42.8180   0 FRM 5

Program received signal SIGSEGV, Segmentation fault.
0x00460e67 in compute_colocated (p=0x6f2fe0, listX=) at bar.c:87
87   
p->mv[0][i][j][0]=p->mv[0][((i&2)?(i|1):(i&(~1)))][((j&2)?(j|1):(j&(~1)))][0];
(gdb) 

good.s and bad.s are compiled with -O -ffast-math -mx32:

diff -up bad.s good.s
--- bad.s2011-06-04 07:52:19.696326354 -0700
+++ good.s2011-06-04 07:52:12.514315372 -0700
@@ -23,7 +23,9 @@ compute_colocated:
 sall$2, %ecx
 testb$2, %al
 je.L5
-leal4(,%rax,4), %ecx
+movl%eax, %ecx
+orl$1, %ecx
+sall$2, %ecx
 .L5:
 movl(%ecx,%edx), %edx
 addl%r9d, %edx
@@ -51,7 +53,9 @@ compute_colocated:
 cmpl$3, (%r8)
 jle.L7
 leal0(,%r11,4), %r10d
-leal4(,%r11,4), %eax
+movl%r11d, %eax
+orl$1, %eax
+sall$2, %eax
 movl%r11d, %r9d
 andl$-2, %r9d
 sall$2, %r9d

[Bug target/48542] mmix code which calls setjmp/longjmp may not work.

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2011.06.04 14:33:24
 CC||hp at gcc dot gnu.org
 AssignedTo|unassigned at gcc dot   |hp at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1
  Known to fail||4.3.5

--- Comment #3 from Hans-Peter Nilsson  2011-06-04 
14:33:24 UTC ---
Confirmed.  Sorry I hadn't seen this report.  Your patch looks likely but I'll
take a deeper look.

[Bug tree-optimization/48929] [4.7 Regression] ICE: in estimate_size_after_inlining, at ipa-inline-analysis.c:1961 with -findirect-inlining

[hubicka at gcc dot gnu.org]

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

--- Comment #3 from Jan Hubicka  2011-06-04 
14:24:24 UTC ---
Author: hubicka
Date: Sat Jun  4 14:24:20 2011
New Revision: 174638

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174638
Log:
PR tree-optimize/48929
* gcc.c-torture/compile/pr48929.c: New testcase.
* ipa-inline-analysis.c (remap_edge_predicates): Fix handling
of empty predicate.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr48929.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-inline-analysis.c
trunk/gcc/testsuite/ChangeLog

[Bug c/49091] ice in evaluate_conditions_for_known_args

[hubicka at gcc dot gnu.org]

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

--- Comment #2 from Jan Hubicka  2011-06-04 
13:56:00 UTC ---
OK, the problem is K&R style definition:
int ssetup(in, out, port)
int *in, *out;
int *port;
{
struct hostent *hp;
struct servent *sp;

struct sockaddr_in myaddr_in;
struct sockaddr_in peeraddr_in;


later used as:
int server_sock_setup(in, out)
int *in, *out;
{
   return(ssetup(in, out));
}

that is bug, too.

I assumed that here we won't inline because of our type check mismatch.
edge->call_stmt_cannot_inline_p is 0. This is because gimple_check_call_args
actually allows decl to have more arguments than caller.
Well, will fortify this at ipa-analysis side.

Honza

[Bug lto/48954] [4.7 Regression] ICE: SIGSEGV in bitmap_count_bits (bitmap.c:719) with -O2 -flto -fno-early-inlining -fkeep-inline-functions

[hubicka at gcc dot gnu.org]

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

--- Comment #4 from Jan Hubicka  2011-06-04 
13:37:03 UTC ---
Created attachment 24430
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24430
patch I am testing

Hi,
this patch fixes ICE in counting bits of bitmap that is NULL.  I am not sure
how this chould worked before and if it is last problem exhibited by the
testcase. But it makes the problem go away for me.

Will commit it after testing.

[Bug c/49283] New: pointless warning with -Wstrict-overflow

[bruno at clisp dot org]

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

   Summary: pointless warning with -Wstrict-overflow
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: br...@clisp.org


Created attachment 24429
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24429
test case

When -Wstrict-overflow is used, gcc reports a warning
"assuming pointer wraparound does not occur when comparing P +- C1 with P +-
C2"
on a location where
1) gcc ought to be able to infer that there is no wraparound.
2) gcc emits this warning only when a certain other function is present in
   the same compilation unit.

How to reproduce:

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/data/arch/x86-linux/gnu-inst-gcc/4.6.0/bin/../libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.6.0/configure --build=i686-pc-linux-gnu
--host=i686-pc-linux-gnu --target=i686-pc-linux-gnu
--prefix=/arch/x86-linux/gnu-inst-gcc/4.6.0 --enable-shared
--enable-version-specific-runtime-libs --enable-nls --enable-threads=posix
--enable-__cxa_atexit --with-as=/arch/x86-linux/gnu/bin/as32
--with-gmp=/arch/x86-linux/gnu-inst-gcc/4.6.0
--with-mpfr=/arch/x86-linux/gnu-inst-gcc/4.6.0
--with-mpc=/arch/x86-linux/gnu-inst-gcc/4.6.0
--with-libelf=/arch/x86-linux/gnu-inst-gcc/4.6.0
--with-ecj-jar=/gfs/petix/Volumes/ExtData/source/gnu/gcc/sourceware.org-ecj/ecj-latest.jar
Thread model: posix
gcc version 4.6.0 (GCC) 

$ gcc -Wstrict-overflow -O2 -S foo.c
foo.c: In function 'yylex':
foo.c:2026:18: warning: assuming pointer wraparound does not occur when
comparing P +- C1 with P +- C2 [-Wstrict-overflow]
foo.c: In function 'yyparse':
foo.c:1442:6: warning: assuming pointer wraparound does not occur when
comparing P +- C1 with P +- C2 [-Wstrict-overflow]
foo.c:1442:6: warning: assuming pointer wraparound does not occur when
comparing P +- C1 with P +- C2 [-Wstrict-overflow]
foo.c:2026:18: warning: assuming pointer wraparound does not occur when
comparing P +- C1 with P +- C2 [-Wstrict-overflow]
foo.c:1407:1: warning: assuming pointer wraparound does not occur when
comparing P +- C1 with P +- C2 [-Wstrict-overflow]
foo.c:2026:18: warning: assuming pointer wraparound does not occur when
comparing P +- C1 with P +- C2 [-Wstrict-overflow]
foo.c:2026:18: warning: assuming pointer wraparound does not occur when
comparing P +- C1 with P +- C2 [-Wstrict-overflow]
foo.c:1442:6: warning: assuming pointer wraparound does not occur when
comparing P +- C1 with P +- C2 [-Wstrict-overflow]
foo.c:2026:18: warning: assuming pointer wraparound does not occur when
comparing P +- C1 with P +- C2 [-Wstrict-overflow]

1) Line 2026 contains the expression
  (p < buff + sizeof buff - 1)
but buff is an array of constant size, sizeof buff is 20.
gcc ought to be able to infer that (buff + 19) does not wrap around.

2) If the function yyparse is removed from foo.c, the warning disappears.
So apparently the warning is generated when inlining yylex into yyparse.
It makes no sense to have no warning in yylex by itself but have a warning
when it gets inlined.

[Bug lto/48954] [4.7 Regression] ICE: SIGSEGV in bitmap_count_bits (bitmap.c:719) with -O2 -flto -fno-early-inlining -fkeep-inline-functions

[hubicka at gcc dot gnu.org]

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

--- Comment #3 from Jan Hubicka  2011-06-04 
13:15:35 UTC ---
Hmm, updating the tree however gets me to count bits error. The bug above is
alsomost probably inconsistency in cgraph encoder, so it seems like a random
memory corruption shooting into the encoder... ugly...

[Bug lto/48954] [4.7 Regression] ICE: SIGSEGV in bitmap_count_bits (bitmap.c:719) with -O2 -flto -fno-early-inlining -fkeep-inline-functions

[hubicka at gcc dot gnu.org]

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

--- Comment #2 from Jan Hubicka  2011-06-04 
13:11:40 UTC ---
Hmm,
I don't really get the uninitialized access, instead I now get an ice:
lto1: internal compiler error: vector VEC(cgraph_node_ptr,base) index domain
error, in lto_cgraph_encoder_deref at lto-cgraph.c:143

It comes from:
#1  0x009afb79 in vec_assert_fail (op=0xf1f0a8 "index",
struct_name=0xd46859 "VEC(cgraph_node_ptr,base)", file=Unhandled dwarf
expression opcode 0xf3
) at ../../gcc/vec.c:516
#2  0x006d1f90 in VEC_cgraph_node_ptr_base_index (file_=Unhandled dwarf
expression opcode 0xf3
) at ../../gcc/cgraph.h:253
#3  0x006ceda0 in lto_cgraph_encoder_deref (encoder=Unhandled dwarf
expression opcode 0xf3
) at ../../gcc/lto-cgraph.c:141
#4  0x01420770 in ?? ()
#5  0x0069557a in ipa_prop_read_jump_functions () at
../../gcc/ipa-prop.c:2928
#6  0x0071f48b in ipa_read_summaries_1 (pass=0x1242ec0) at
../../gcc/passes.c:2144

So jump functions stream is corrupted somehow.

[Bug tree-optimization/48929] [4.7 Regression] ICE: in estimate_size_after_inlining, at ipa-inline-analysis.c:1961 with -findirect-inlining

[hubicka at gcc dot gnu.org]

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

--- Comment #2 from Jan Hubicka  2011-06-04 
13:02:28 UTC ---
Created attachment 24428
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24428
Pack I am testing

The problem is that the code assumes transitivity in edge predicates, while
this is broken by bug in remap_edge_predicates.  When inlining function F that
has predicate P and F contains edge with no predicates, the edge should be
remapped to have predicate P.

Regtesting/bootstrapping the patch and will commit it if it passes.

[Bug c++/33840] bit-field size accepted for struct

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||patch
  Known to work||4.6.0, 4.7.0

--- Comment #3 from Jonathan Wakely  2011-06-04 
13:01:30 UTC ---
patch posted to http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00305.html

[Bug c++/49266] [C++0x] Another incomplete type regression with noexcept

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||paolo.carlini at oracle dot
   ||com

--- Comment #1 from Paolo Carlini  2011-06-04 
12:30:59 UTC ---
Thanks Marc. I guess we need a definitive word here about whether these are c++
front issues or unavoidable problems caused by the implementation of the traits
via sfinae. In the latter case we have unfortunately to be prepared to revert
all the noexcept work involving traits until we get front-end support. Very
sad, of course: personally, I didn't think sfinae-based techniques had serious
limitations besides access-control. Would be something worth popularizing, can
affect a lot of sfinae uses outside the library too, of course.

[Bug c++/49107] [C++0x][4.7 Regression] incomplete type regression with std::pair

[redi at gcc dot gnu.org]

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

--- Comment #14 from Jonathan Wakely  2011-06-04 
12:27:50 UTC ---
(In reply to comment #9)
> But doing this breaks auto_ptr.  And v3 future as well, for some reason.

I can take care of any necessary changes to future if you let me know what
breaks (or let me know what to change in the FE to reproduce the breakage)

[Bug tree-optimization/41012] Missing inlining after indirect call promotion

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||rguenther at suse dot de

--- Comment #2 from Jan Hubicka  2011-06-04 
11:06:14 UTC ---
Richi,
was the pointer type in call statement issues solved for 4.7?  If so, we could
probably resolve this as fixed.

[Bug debug/47590] var tracking produces wrong debug in code where optimization is turned off using pragma

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #7 from Alexandre Oliva  2011-06-04 
10:21:35 UTC ---
Fixed

[Bug debug/48333] -fcompare-debug failure (length) - "memmove" x "__builtin_memmove"

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #6 from Alexandre Oliva  2011-06-04 
10:18:16 UTC ---
Fixed

[Bug debug/47590] var tracking produces wrong debug in code where optimization is turned off using pragma

[aoliva at gcc dot gnu.org]

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

--- Comment #6 from Alexandre Oliva  2011-06-04 
10:15:51 UTC ---
Author: aoliva
Date: Sat Jun  4 10:15:48 2011
New Revision: 174637

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174637
Log:
PR debug/47590
* target.def (delay_sched2, delay_vartrack): New.
* doc/tm.texi.in: Update.
* doc/tm.texi: Rebuild.
* sched-rgn.c (gate_handle_sched2): Fail if delay_sched2.
* var-tracking.c (gate_handle_var_tracking): Likewise.
* config/bfin/bfin.c (bfin_flag_schedule_insns2): Drop.
(bfin_flag_var_tracking): Drop.
(output_file_start): Don't save and override flag_var_tracking.
(bfin_option_override): Ditto flag_schedule_insns_after_reload.
(bfin_reorg): Test original variables.
(TARGET_DELAY_SCHED2, TARGET_DELAY_VARTRACK): Define.
* config/ia64/ia64.c (ia64_flag_schedule_insns2): Drop.
(ia64_flag_var_tracking): Drop.
(TARGET_DELAY_SCHED2, TARGET_DELAY_VARTRACK): Define.
(ia64_file_start): Don't save and override flag_var_tracking.
(ia64_override_options_after_change): Ditto
flag_schedule_insns_after_reload.
(ia64_reorg): Test original variables.
* config/picochip/picochip.c (picochip_flag_schedule_insns2): Drop.
(picochip_flag_var_tracking): Drop.
(TARGET_DELAY_SCHED2, TARGET_DELAY_VARTRACK): Define.
(picochip_option_override): Don't save and override
flag_schedule_insns_after_reload.
(picochip_asm_file_start): Ditto flag_var_tracking.
(picochip_reorg): Test original variables.
* config/spu/spu.c (spu_flag_var_tracking): Drop.
(TARGET_DELAY_VARTRACK): Define.
(spu_var_tracking): New.
(spu_machine_dependent_reorg): Call it.
(asm_file_start): Don't save and override flag_var_tracking.

Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/config/bfin/bfin.c
branches/gcc-4_6-branch/gcc/config/ia64/ia64.c
branches/gcc-4_6-branch/gcc/config/picochip/picochip.c
branches/gcc-4_6-branch/gcc/config/spu/spu.c
branches/gcc-4_6-branch/gcc/doc/tm.texi
branches/gcc-4_6-branch/gcc/doc/tm.texi.in
branches/gcc-4_6-branch/gcc/sched-rgn.c
branches/gcc-4_6-branch/gcc/target.def
branches/gcc-4_6-branch/gcc/var-tracking.c

[Bug debug/48333] -fcompare-debug failure (length) - "memmove" x "__builtin_memmove"

[aoliva at gcc dot gnu.org]

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

--- Comment #5 from Alexandre Oliva  2011-06-04 
10:08:12 UTC ---
Author: aoliva
Date: Sat Jun  4 10:08:09 2011
New Revision: 174636

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=174636
Log:
PR debug/48333
* calls.c (emit_call_1): Prefer the __builtin declaration of
builtin functions.

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

[Bug c++/49107] [C++0x][4.7 Regression] incomplete type regression with std::pair

[marc.glisse at normalesup dot org]

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

--- Comment #13 from Marc Glisse  2011-06-04 
09:31:40 UTC ---
(In reply to comment #8)
> Here, instantiating
> std::pair> involves evaluating
> noexcept(ploum>::value),

Hello,

I am far from a specialist. Is it necessary to evaluate the noexcept expression
so early? It feels like it could lazily wait until something really looks at
the swap function, but the standard may require that early evaluation.

(clang currently rejects this code for the same reason)

PR c++/49266 is another example of code that started failing to compile. I hope
we will manage to avoid a situation where people reimplement their own
pair/tuple to avoid the noexcept limitations...

[Bug tree-optimization/49038] [4.5/4.6/4.7 Regression] -ftree-vectorise introduces reads past end of array

[irar at il dot ibm.com]

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

Ira Rosen  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #7 from Ira Rosen  2011-06-04 09:21:05 UTC 
---
Fixed.

[Bug tree-optimization/49038] [4.5/4.6/4.7 Regression] -ftree-vectorise introduces reads past end of array

[irar at gcc dot gnu.org]

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

--- Comment #6 from irar at gcc dot gnu.org 2011-06-04 09:20:04 UTC ---
Author: irar
Date: Sat Jun  4 09:20:00 2011
New Revision: 174635

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

PR tree-optimization/49038
* tree-vect-loop-manip.c (vect_generate_tmps_on_preheader):
Ensure at least one epilogue iteration if required by data
accesses with gaps.
* tree-vectorizer.h (struct _loop_vec_info): Add new field
to mark loops that require peeling for gaps.
* tree-vect-loop.c (new_loop_vec_info): Initialize new field.
(vect_get_known_peeling_cost): Take peeling for gaps into
account.
(vect_transform_loop): Generate epilogue if required by data
access with gaps.
* tree-vect-data-refs.c (vect_analyze_group_access): Mark the
loop as requiring an epilogue if there are gaps in the end of
the strided group.


Added:
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/vect/pr49038.c
   
branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/vect/vect-strided-u8-i8-gap4-unknown.c
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
branches/gcc-4_6-branch/gcc/tree-vect-data-refs.c
branches/gcc-4_6-branch/gcc/tree-vect-loop-manip.c
branches/gcc-4_6-branch/gcc/tree-vect-loop.c
branches/gcc-4_6-branch/gcc/tree-vectorizer.h

[Bug tree-optimization/49038] [4.5/4.6/4.7 Regression] -ftree-vectorise introduces reads past end of array

[irar at gcc dot gnu.org]

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

--- Comment #5 from irar at gcc dot gnu.org 2011-06-04 09:12:58 UTC ---
Author: irar
Date: Sat Jun  4 09:12:55 2011
New Revision: 174634

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

PR tree-optimization/49038
* tree-vect-loop-manip.c (vect_generate_tmps_on_preheader):
Ensure at least one epilogue iteration if required by data
accesses with gaps.
* tree-vectorizer.h (struct _loop_vec_info): Add new field
to mark loops that require peeling for gaps.
* tree-vect-loop.c (new_loop_vec_info): Initialize new field.
(vect_estimate_min_profitable_iters): Take peeling for gaps into
account.
(vect_transform_loop): Generate epilogue if required by data
access with gaps.
* tree-vect-data-refs.c (vect_analyze_group_access): Mark the
loop as requiring an epilogue if there are gaps in the end of
the strided group.


Added:
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/pr49038.c
   
branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/vect/vect-strided-u8-i8-gap4-unknown.c
Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
branches/gcc-4_5-branch/gcc/tree-vect-data-refs.c
branches/gcc-4_5-branch/gcc/tree-vect-loop-manip.c
branches/gcc-4_5-branch/gcc/tree-vect-loop.c
branches/gcc-4_5-branch/gcc/tree-vectorizer.h

[Bug c++/33840] bit-field size accepted for struct

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0

--- Comment #2 from Volker Reichelt  2011-06-04 
09:05:30 UTC ---
This is fixed since GCC 4.6.0, but we should add a testcase before closing the
problem report.

[Bug middle-end/45098] Missed induction variable optimization

[vries at gcc dot gnu.org]

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

--- Comment #13 from vries at gcc dot gnu.org 2011-06-04 08:42:29 UTC ---
> Tom can this now be marked as being fixed for 4.7.0 ?

I'm still discussing one patch with Zdenek. Latest gcc-patches mail on this is
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg02384.html.

[Bug target/48250] ICE in reload_cse_simplify_operands, at postreload.c:403

[ramana at gcc dot gnu.org]

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

--- Comment #4 from Ramana Radhakrishnan  2011-06-04 
08:22:32 UTC ---
A backport to 4.6 shows the following failures -

arm-sim: gcc.c-torture/execute/loop-ivopts-2.c compilation,  -O3
-fomit-frame-pointer -funroll-all-loops -finline-functions  (internal compiler
error)
arm-sim: gcc.c-torture/execute/loop-ivopts-2.c compilation,  -O3
-fomit-frame-pointer -funroll-loops  (internal compiler error)
arm-sim: gcc.c-torture/execute/loop-ivopts-2.c compilation,  -O3
-fomit-frame-pointer  (internal compiler error)
arm-sim: gcc.c-torture/execute/loop-ivopts-2.c compilation,  -O3 -g  (internal
compiler error)
arm-sim: gcc.c-torture/execute/pr23135.c compilation,  -O1  (internal compiler
error)

 I'll dig further when I have a little more time

ackport-test-armv7aneon/gcc3/gcc/
/home/ramana/cross-build/src/gcc-workarea-2/gcc.c-torture/execute/loop-ivopts-2.c
gcc_tg.o  -w  -O3 -fomit-frame-pointer  -DSTACK_SIZE=16384   -Wl,-wrap,exit
-Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort -lm   -o
/home/ramana/cross-build/arm-none-linux-gnueabi/obj-gcc46-backport-test-armv7aneon/gcc3/gcc/testsuite/gcc2/loop-ivopts-2.x3
   (timeout = 800)
/home/ramana/cross-build/src/gcc-workarea-2/gcc/testsuite/gcc.c-torture/execute/loop-ivopts-2.c:
In function ‘main’:
/home/ramana/cross-build/src/gcc-workarea-2/gcc/testsuite/gcc.c-torture/execute/loop-ivopts-2.c:49:1:
error: insn does not satisfy its constraints:
(insn 123 122 67 6 (set (mem/s/c:V2SI (plus:SI (reg:SI 1 r1)
(const_int -1016 [0xfc08])) [2 MEM[(unsigned
int[288] *)&l + 1032B]+0 S8 A64])
(reg:V2SI 2 r2))
/home/ramana/cross-build/src/gcc-workarea-2/gcc/testsuite/gcc.c-torture/execute/loop-ivopts-2.c:44
742 {*neon_movv2si}
 (nil))

[Bug middle-end/45098] Missed induction variable optimization

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org,
   ||vries at gcc dot gnu.org

--- Comment #12 from Ramana Radhakrishnan  
2011-06-04 08:20:52 UTC ---
Tom can this now be marked as being fixed for 4.7.0 ?

Ramana

[Bug c++/49107] [C++0x][4.7 Regression] incomplete type regression with std::pair

[paolo.carlini at oracle dot com]

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

--- Comment #12 from Paolo Carlini  2011-06-04 
07:33:15 UTC ---
I'd like to understand as soon as possible if this type of issue means that
these traits cannot really be implemented with sfinae or not. Actually, as
usual, the library is just an example and in case people should know if
sfinae-based techniques have limitations beyond access-control (which by itself
is being fixed) and our users should know.

[Bug c++/49107] [C++0x][4.7 Regression] incomplete type regression with std::pair

[paolo.carlini at oracle dot com]

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

--- Comment #11 from Paolo Carlini  2011-06-04 
07:05:34 UTC ---
I'm sorry, now I see that typedef. Hum, I'm worried, I have no idea how I coul
possibly simplify or workaround this type of issue in the library, among other
things.