[Bug tree-optimization/53385] [4.8 Regression] "Error: operand out of range" after changes for LSHIFT_EXPR in vrp.c

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53385 --- Comment #8 from William J. Schmidt 2012-05-18 03:42:46 UTC --- I suspect you're right. I'll have a look at it tomorrow.

[Bug testsuite/53170] ERROR: g++.dg/cpp0x/variadic-value1.C: syntax error in target selector "target c++11" for " dg-do 2 run { target c++11 } "

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53170 Michael Hope changed: What|Removed |Added CC||michael.hope at linaro dot

[Bug c/53391] New: Slightly misleading warning on printf format mismatch

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53391 Bug #: 53391 Summary: Slightly misleading warning on printf format mismatch Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: minor

[Bug target/53392] New: dwfl-bug-fd-leak.c:110:1: internal compiler error: in extract_insn, at recog.c:2109

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53392 Bug #: 53392 Summary: dwfl-bug-fd-leak.c:110:1: internal compiler error: in extract_insn, at recog.c:2109 Classification: Unclassified Product: gcc Version: 4.6.3 Sta

[Bug c/52952] Wformat location info is bad (wrong column number)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952 Steven Bosscher changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #

[Bug rtl-optimization/53352] Incorrect CSE optimization on RTL expressions with a paradoxical subreg

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53352 --- Comment #8 from Mikael Pettersson 2012-05-17 21:07:20 UTC --- (In reply to comment #6) > Mikael, is it possible for you to test if this is caused by this patch, > please? > http://gcc.gnu.org/viewcvs?view=revision&revision=142443 The error

[Bug c/52952] Wformat location info is bad (wrong column number)

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952 --- Comment #2 from Steven Bosscher 2012-05-17 21:19:28 UTC --- To fix this properly, the input location should be tracked for the format string. The location of the format string as argument to printf is available in c-family/c-format.c:check_f

[Bug bootstrap/53384] checksum (comparison) differs wrongly

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53384 --- Comment #3 from John T 2012-05-17 23:23:52 UTC --- I just got a good bootstrap build of gcc 4.6.3 after installing 4.6.1. The installation of 4.6.1 must have added or changed something that didn't work right in 4.4.1 on the 4.6.3 build system

[Bug tree-optimization/53390] ICE: tree check: expected integer_cst, have nop_expr in vect_compute_data_ref_alignmen on 32-bit x86 host

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53390 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug tree-optimization/53385] [4.8 Regression] "Error: operand out of range" after changes for LSHIFT_EXPR in vrp.c

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53385 --- Comment #7 from Marc Glisse 2012-05-17 21:34:23 UTC --- Created attachment 27429 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27429 patch I believe you need something like this completely untested patch to avoid undefined behavior wit

[Bug rtl-optimization/53352] Incorrect CSE optimization on RTL expressions with a paradoxical subreg

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53352 --- Comment #7 from Meador Inge 2012-05-17 20:31:28 UTC --- (In reply to comment #5) > There is no call to 'foo' in the test case here. I guess you meant 'bar', but > even so executable test cases are strongly preferred over manual inspection of

[Bug tree-optimization/53346] [4.6/4.7/4.8 Regression] Bad vectorization in the proc cptrf2 of rnflow.f90

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53346 --- Comment #4 from Uros Bizjak 2012-05-17 20:09:42 UTC --- Instead of this: .L228: movl$0, -4(%rdx,%rax,4) addq$1, %rax cmpq%rax, %rsi jge.L228 vectorization generates following: movq%rdx, %rax movq

[Bug rtl-optimization/53352] Incorrect CSE optimization on RTL expressions with a paradoxical subreg

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53352 --- Comment #6 from Steven Bosscher 2012-05-17 19:09:14 UTC --- Mikael, is it possible for you to test if this is caused by this patch, please? http://gcc.gnu.org/viewcvs?view=revision&revision=142443

[Bug c++/39681] Compile error is not descriptive

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39681 --- Comment #9 from paolo at gcc dot gnu.org 2012-05-17 18:54:45 UTC --- Author: paolo Date: Thu May 17 18:54:37 2012 New Revision: 187634 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187634 Log: /cp 2012-05-17 Paolo Carlini PR

[Bug c++/39681] Compile error is not descriptive

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39681 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution|

[Bug rtl-optimization/53352] Incorrect CSE optimization on RTL expressions with a paradoxical subreg

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53352 --- Comment #5 from Mikael Pettersson 2012-05-17 18:35:00 UTC --- There is no call to 'foo' in the test case here. I guess you meant 'bar', but even so executable test cases are strongly preferred over manual inspection of assembly code. FWIW,

[Bug tree-optimization/53346] [4.6/4.7/4.8 Regression] Bad vectorization in the proc cptrf2 of rnflow.f90

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53346 Uros Bizjak changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug rtl-optimization/53352] Incorrect CSE optimization on RTL expressions with a paradoxical subreg

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53352 Steven Bosscher changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #

[Bug rtl-optimization/53125] Very slow compilation on SPARC

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53125 Steven Bosscher changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|

[Bug rtl-optimization/53125] Very slow compilation on SPARC

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53125 --- Comment #9 from Steven Bosscher 2012-05-17 17:55:01 UTC --- Author: steven Date: Thu May 17 17:54:52 2012 New Revision: 187633 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187633 Log: PR rtl-optimization/53125 * regstat.c (r

[Bug tree-optimization/53390] ICE: tree check: expected integer_cst, have nop_expr in vect_compute_data_ref_alignmen on 32-bit x86 host

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53390 --- Comment #2 from Gary Funck 2012-05-17 17:25:23 UTC --- The following versions of the support packages were installed via RPM. mpfr-devel-2.4.1-6.el6.i686 gmp-devel-4.3.1-7.el6.i686 libmpc-devel-0.8-3.el6.i686 binutils-2.20.51.0.2-5.28.el6.i6

[Bug fortran/53389] memory leak when assigning array function result to allocatable array, where one of its supplied arguments is itself an array function result.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53389 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug tree-optimization/53390] ICE: tree check: expected integer_cst, have nop_expr in vect_compute_data_ref_alignmen on 32-bit x86 host

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53390 --- Comment #1 from Gary Funck 2012-05-17 17:12:49 UTC --- Created attachment 27428 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27428 Test case to demonstrate ICE in tree check on 32-bit host Test case attached. Compile with "-fpreproce

[Bug tree-optimization/53390] New: ICE: tree check: expected integer_cst, have nop_expr in vect_compute_data_ref_alignmen on 32-bit x86 host

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53390 Bug #: 53390 Summary: ICE: tree check: expected integer_cst, have nop_expr in vect_compute_data_ref_alignmen on 32-bit x86 host Classification: Unclassified Product: gcc Version:

[Bug bootstrap/53384] checksum (comparison) differs wrongly

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53384 --- Comment #2 from John T 2012-05-17 16:47:08 UTC --- (In reply to comment #1) > Are you building in the source directory? No. I untarred all the source in /usr/local/gcc-4.6.3, all except the go tarball, and built in my home folder ~/bld463. I

[Bug rtl-optimization/53352] Incorrect CSE optimization on RTL expressions with a paradoxical subreg

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53352 --- Comment #3 from Meador Inge 2012-05-17 16:42:04 UTC --- It can easily be seen my inspection of the assembly code. As I mentioned before, 0xFF00 gets passed to 'foo'. Anyway, I posted an executable case along with my patch here: http://gcc.g

[Bug rtl-optimization/53352] Incorrect CSE optimization on RTL expressions with a paradoxical subreg

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53352 Mikael Pettersson changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #2

[Bug fortran/53389] New: memory leak when assigning array function result to allocatable array, where one of its supplied arguments is itself an array function result.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53389 Bug #: 53389 Summary: memory leak when assigning array function result to allocatable array, where one of its supplied arguments is itself an array function result. Classification:

[Bug c/53387] gcc does not like /* */ comments

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53387 --- Comment #4 from Jonathan Wakely 2012-05-17 16:27:59 UTC --- (In reply to comment #0) > Please don't ask me to post example code. Why not? You're making an absurd claim that can't be confirmed by hundreds and hundreds of other people. Do you

[Bug target/53383] Allow -mpreferred-stack-boundary=3 on x86-64

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383 --- Comment #5 from H. Peter Anvin 2012-05-17 16:09:19 UTC --- The point is that the key is -mno-sse, not -mcmodel=kernel.

[Bug tree-optimization/53385] [4.8 Regression] "Error: operand out of range" after changes for LSHIFT_EXPR in vrp.c

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53385 David Edelsohn changed: What|Removed |Added Keywords||wrong-code Target Milestone|---

[Bug target/53383] Allow -mpreferred-stack-boundary=3 on x86-64

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383 --- Comment #4 from H. Peter Anvin 2012-05-17 15:59:28 UTC --- Only if the program in question is actually using SSE. If SSE is disallowed (because it is kernel code, or some other embedded piece of code) it is irrelevant.

[Bug c++/53371] rvalue reference type as exception-declaration

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53371 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|

[Bug c++/53371] rvalue reference type as exception-declaration

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53371 --- Comment #3 from paolo at gcc dot gnu.org 2012-05-17 15:56:01 UTC --- Author: paolo Date: Thu May 17 15:55:51 2012 New Revision: 187630 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187630 Log: /cp 2012-05-17 Paolo Carlini PR

[Bug target/53386] Bad assembly code produced for m68000

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386 --- Comment #12 from Luis Alves 2012-05-17 15:44:12 UTC --- (In reply to comment #10) > See the gcc-patches thread I referred to in #c8, gcc-4.3 also changed > low-level > ABI details, with the consequence that gcc-4.2 and gcc-4.3 generate > inc

[Bug target/53383] Allow -mpreferred-stack-boundary=3 on x86-64

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383 --- Comment #3 from H.J. Lu 2012-05-17 15:37:02 UTC --- Following the x86-64 psABI, GCC assumes incoming stack is 16byte aligned and generates 16-byte aligned vector move on stack. If it isn't true, you will get segfault at run-time.

[Bug target/53386] Bad assembly code produced for m68000

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386 Andreas Schwab changed: What|Removed |Added Severity|blocker |normal --- Comment #11 from Andreas Schw

[Bug objc++/53388] Removal of build_min_nt breaks bootstrap for objc++

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53388 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC|paolo.carlini

[Bug objc++/53388] Removal of build_min_nt breaks bootstrap for objc++

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53388 --- Comment #2 from paolo at gcc dot gnu.org 2012-05-17 15:28:59 UTC --- Author: paolo Date: Thu May 17 15:28:53 2012 New Revision: 187629 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187629 Log: 2012-05-17 Paolo Carlini PR objc

[Bug c++/53388] Removal of build_min_nt breaks bootstrap for objc++

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53388 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|

[Bug target/53386] Bad assembly code produced for m68000

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386 --- Comment #10 from Mikael Pettersson 2012-05-17 15:02:51 UTC --- See the gcc-patches thread I referred to in #c8, gcc-4.3 also changed low-level ABI details, with the consequence that gcc-4.2 and gcc-4.3 generate incompatible code for m68k-ucli

[Bug middle-end/53381] [4.8 Regression] Bootstrap fails building stage1 libgcc

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53381 --- Comment #10 from Jakub Jelinek 2012-05-17 14:53:21 UTC --- For DSE it would be enough if just the call was first in the parallel and the currently first set came after it. All sets in a parallel happen at the same time...

[Bug c++/53388] New: Removal of build_min_nt breaks bootstrap for objc++

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53388 Bug #: 53388 Summary: Removal of build_min_nt breaks bootstrap for objc++ Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal

[Bug middle-end/53381] [4.8 Regression] Bootstrap fails building stage1 libgcc

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53381 --- Comment #9 from dave.anglin at bell dot net 2012-05-17 14:39:41 UTC --- On 5/17/2012 2:48 AM, jakub at gcc dot gnu.org wrote: > Note that e.g. dse.c (scan_insn) handles the AVX mem* just fine, but won't > handle this PA pattern because (set (re

[Bug target/53386] Bad assembly code produced for m68000

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386 --- Comment #9 from Luis Alves 2012-05-17 14:29:07 UTC --- Thanks Mikael, But... will I have any (future) problems if I just change the flags in the ? In a small test I've made that solutions seems to produce good code for the 68000 but I'm af

[Bug target/53383] Allow -mpreferred-stack-boundary=3 on x86-64

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383 --- Comment #2 from H. Peter Anvin 2012-05-17 14:11:23 UTC --- Why would -mcmodel=kernel matter for this? (For the record, there is C code in the Linux kernel which doesn't use -mcmodel=kernel, too, and other embedded programs may very well have

[Bug target/53383] Allow -mpreferred-stack-boundary=3 on x86-64

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com, |

[Bug tree-optimization/53385] "Error: operand out of range" after changes for LSHIFT_EXPR in vrp.c

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53385 Marc Glisse changed: What|Removed |Added CC||glisse at gcc dot gnu.org --- Comment #6 fr

[Bug target/53386] Bad assembly code produced for m68000

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386 --- Comment #8 from Mikael Pettersson 2012-05-17 12:57:20 UTC --- Fallout from a deliberate ABI change in 4.3.x, see and its followups. I don't like the way an existing target triplet was

[Bug tree-optimization/53385] "Error: operand out of range" after changes for LSHIFT_EXPR in vrp.c

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53385 Alan Modra changed: What|Removed |Added Component|target |tree-optimization --- Comment #5 from Alan M

[Bug target/53385] "Error: operand out of range" after changes for LSHIFT_EXPR in vrp.c

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53385 --- Comment #4 from Alan Modra 2012-05-17 12:25:03 UTC --- Here's the problem. Compiled with -m64 -O2, this int f (long val) { int i; if (val < 0) i = -1; else for (i = 0; i < 64; i++) if ((val <<= 1) < 0) break;

[Bug target/53376] Unrecognizable compare insn generated by movsicc in arm backend.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53376 --- Comment #4 from Richard Earnshaw 2012-05-17 12:07:23 UTC --- No, I think we need a separate function that is allowed to say "don't do a comparison this way" For example some comparisons might involve libcalls.

[Bug target/53385] "Error: operand out of range" after changes for LSHIFT_EXPR in vrp.c

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53385 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #3 from

[Bug target/53386] Bad assembly code produced for m68000

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386 --- Comment #7 from Mikael Pettersson 2012-05-17 11:31:35 UTC --- gcc-4.3.x changed gcc/config.gcc: --- gcc-4.2.4/gcc/config.gcc2008-03-13 20:11:43.0 +0100 +++ gcc-4.3.6/gcc/config.gcc2011-02-25 00:02:14.0 +0100 ... -m68k

[Bug target/53386] Bad assembly code produced for m68000

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386 --- Comment #6 from Mikael Pettersson 2012-05-17 11:09:08 UTC --- The behaviour changed between gcc-4.2.4 (ok) and gcc-4.3.6 (bad).

[Bug target/53386] Bad assembly code produced for m68000

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386 Luis Alves changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID

[Bug target/53386] Bad assembly code produced for m68000

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386 Mikael Pettersson changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #4

[Bug c++/44516] improve error message when no matching operator

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44516 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|

[Bug c++/44516] improve error message when no matching operator

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44516 --- Comment #3 from paolo at gcc dot gnu.org 2012-05-17 10:29:52 UTC --- Author: paolo Date: Thu May 17 10:29:46 2012 New Revision: 187627 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187627 Log: gcc/cp 2012-05-17 Paolo Carlini

[Bug target/53386] Bad assembly code produced for m68000

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386 --- Comment #3 from Luis Alves 2012-05-17 10:19:11 UTC --- Thanks a lot Andreas, Changed those flags to true and it's working good now. Also a minor correction: I was trying to build gcc 4.6.3 (not 4.6.4). (I've changed status to RESOLVED-INVA

[Bug target/53386] Bad assembly code produced for m68000

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386 Luis Alves changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Version|4.6.4

[Bug c/53382] incorrect associativity in expressions

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53382 --- Comment #4 from Miguel Barao 2012-05-17 09:42:48 UTC --- There was a misunderstanding between associativity and operator evaluation order in the original bugreport. I now understand that the language does not specify the evaluation order of a

[Bug tree-optimization/53366] wrong code generation by tree vectorizer using AVX

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53366 --- Comment #7 from Jakub Jelinek 2012-05-17 08:55:36 UTC --- Indeed, --- gcc/tree-vect-slp.c.jj2012-04-19 11:09:13.0 +0200 +++ gcc/tree-vect-slp.c2012-05-17 10:47:30.124290361 +0200 @@ -1199,7 +1199,8 @@ vect_supported_load_perm

[Bug tree-optimization/53366] wrong code generation by tree vectorizer using AVX

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53366 --- Comment #6 from Jakub Jelinek 2012-05-17 08:45:40 UTC --- Slightly more reduced: struct T { float r[3], i[3]; }; struct U { struct T j[2]; }; void __attribute__ ((noinline)) foo (struct U *__restrict y, const float _Complex *__restrict x) {

[Bug target/53386] Bad assembly code produced for m68000

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386 --- Comment #1 from Andreas Schwab 2012-05-17 08:23:45 UTC --- config/m68k/linux.h: /* for 68k machines this only needs to be TRUE for the 68000 */ #undef STRICT_ALIGNMENT #define STRICT_ALIGNMENT 0 #undef M68K_HONOR_TARGET_STRICT_ALIGNMENT #def