[Bug c++/53350] Internal compiler error when compiling boost/smart_ptr/intrusive_ptr.hpp 1.49
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53350 --- Comment #10 from Marc Glisse glisse at gcc dot gnu.org 2012-05-17 06:11:43 UTC --- (In reply to comment #9) The main issue is that it doesn't work in 6.4.1, which is the version provided in Ubuntu 11.10, which means that anyone running 11.10 won't be able to compile programs that use this boost header. Should I file a bug in Launchpad to get the fix backported or something? Contacting your distributor is indeed the only way of getting the fix in your distribution (don't know what their policy is). Since you say the problem does not appear with 4.6.3, I guess we can close the bug report here. By the way, when you say the problem doesn't exist with 4.6.3, did you give it the original program or the preprocessed sources?
[Bug c/53387] gcc does not like /* */ comments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53387 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2012-05-17 06:15:13 UTC --- Ok, let me ask how does it fail? Right now I know there are lots of /* */ comments in both GCC and the testsuite so it would have shown up more than just this bug report.
[Bug c++/53350] Internal compiler error when compiling boost/smart_ptr/intrusive_ptr.hpp 1.49
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53350 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.3 --- Comment #11 from Andrew Pinski pinskia at gcc dot gnu.org 2012-05-17 06:16:20 UTC --- Already reported as fixed in 4.6.3 so closing as such.
[Bug bootstrap/53384] checksum (comparison) differs wrongly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53384 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-05-17 06:18:32 UTC --- Are you building in the source directory?
[Bug middle-end/53381] [4.8 Regression] Bootstrap fails building stage1 libgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53381 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org 2012-05-17 06:44:35 UTC --- Can't you instead of using single_set just find the single set with GET_CODE (SET_SRC (set)) == CALL (and only punt if there is none or more than one)? That would handle e.g. the AVX marked call or this one just fine...
[Bug middle-end/53381] [4.8 Regression] Bootstrap fails building stage1 libgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53381 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2012-05-17 06:48:31 UTC --- Note that e.g. dse.c (scan_insn) handles the AVX mem* just fine, but won't handle this PA pattern because (set (reg) (call ...)) isn't the first thing in the parallel. Any reason for that? rtx call = PATTERN (insn); if (GET_CODE (call) == PARALLEL) call = XVECEXP (call, 0, 0); if (GET_CODE (call) == SET) call = SET_SRC (call); if (GET_CODE (call) == CALL MEM_P (XEXP (call, 0)) GET_CODE (XEXP (XEXP (call, 0), 0)) == SYMBOL_REF)
[Bug target/53386] Bad assembly code produced for m68000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386 --- Comment #1 from Andreas Schwab sch...@linux-m68k.org 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 #define M68K_HONOR_TARGET_STRICT_ALIGNMENT 0
[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 jakub at gcc dot gnu.org 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)
{
int i, j;
for (j = 0; j 2; ++j)
{
float a = __real__ x[j];
float b = __imag__ x[j];
float c = __real__ x[j + 2];
float d = __imag__ x[j + 2];
for (i = 0; i 3; ++i)
{
y-j[j].r[i] = y-j[j].r[i] + a + c;
y-j[j].i[i] = y-j[j].i[i] + b + d;
}
}
}
_Complex float x[4];
struct U y;
int
main ()
{
int i, j;
for (i = 0; i 4; ++i)
x[i] = i + 1.0iF * (2 * i);
foo (y, x);
for (j = 0; j 2; ++j)
for (i = 0; i 3; ++i)
if (y.j[j].r[i] != __real__ (x[j] + x[j + 2])
|| y.j[j].i[i] != __imag__ (x[j] + x[j + 2]))
__builtin_abort ();
return 0;
}
I bet the bug is in vect_supported_load_permutation_p, in particular the
complex_numbers == 2 handling there.
The if (complex_numbers) doesn't do anything, because
GROUP_FIRST_ELEMENT (vinfo_for_stmt (stmt)) == first in all cases,
and then just
/* We checked that this case ok, so there is no need to proceed with
permutation tests. */
if (complex_numbers == 2)
{
VEC_free (slp_tree, heap, SLP_INSTANCE_LOADS (slp_instn));
VEC_free (int, heap, SLP_INSTANCE_LOAD_PERMUTATION (slp_instn));
return true;
}
I guess we need way more checks than that to verify we don't need to proceed
with permutation tests. E.g. one possible reason not to return early might be
that complex_numbers != VEC_length (slp_tree, SLP_INSTANCE_LOADS (slp_instn)) ?
In that case we fail to check altogether whether the non-complex permutations
match the complex ones. I also wonder whether group lengths smaller than
group_size can't be a problem (in this case, group_size is 6, but the complex
groups have just 2 elements). This stuff has been added as part of the PR44152
fix.
[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 jakub at gcc dot gnu.org 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_permutation_p (slp_i
/* We checked that this case ok, so there is no need to proceed with
permutation tests. */
- if (complex_numbers == 2)
+ if (complex_numbers == 2
+ VEC_length (slp_tree, SLP_INSTANCE_LOADS (slp_instn)) == 2)
{
VEC_free (slp_tree, heap, SLP_INSTANCE_LOADS (slp_instn));
VEC_free (int, heap, SLP_INSTANCE_LOAD_PERMUTATION (slp_instn));
alone fixes this as the further load permutation checks fail. Whether this is
the right fix and whether it is sufficient, no idea unfortunately, not familiar
enough with the interleaving code. Richard or Michael, any thoughts?
[Bug c/53382] incorrect associativity in expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53382 --- Comment #4 from Miguel Barao miguel.barao at gmail dot com 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 an operator, and is bad a practice to depend such behavior. Still, I would like to add that expressions like - f( ) + f( ) and - ( f( ) - f( ) ) produce different evaluation orders, and therefor different results, when f( ) has side effects.
[Bug target/53386] Bad assembly code produced for m68000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386 Luis Alves ljalvs at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Version|4.6.4 |4.6.3 Resolution||INVALID --- Comment #2 from Luis Alves ljalvs at gmail dot com 2012-05-17 10:18:47 UTC --- Thanks a lot Andreas, Changes 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-INVALID since this is not a bug but a configuration issue) Regards, Luis Alves
[Bug target/53386] Bad assembly code produced for m68000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386 --- Comment #3 from Luis Alves ljalvs at gmail dot com 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-INVALID since this is not a bug but a configuration issue) Regards, Luis Alves
[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 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=gccview=revrev=187627 Log: gcc/cp 2012-05-17 Paolo Carlini paolo.carl...@oracle.com PR c++/44516 * typeck.c (build_x_array_ref, build_x_conditional_expr, build_x_compound_expr, build_x_modify_expr): Add location_t parameter. (finish_class_member_access_expr, build_x_indirect_ref, build_x_binary_op, build_x_compound_expr_from_list, build_x_compound_expr_from_vec): Adjust callers. * tree.c (build_min_nt_loc): New. (build_min_nt): Remove. * typeck2.c (build_x_arrow): Adjust callers. * pt.c (tsubst_qualified_id, tsubst_omp_for_iterator, tsubst_copy_and_build): Likewise. * semantics.c (finish_mem_initializers, handle_omp_for_class_iterator, finish_omp_atomic): Likewise. * decl2.c (grok_array_decl, build_anon_union_vars): Adjust. * parser.c (cp_parser_question_colon_clause, cp_parser_assignment_expression, cp_parser_expression, cp_parser_template_id, cp_parser_omp_for_loop): Likewise. * cp-tree.h: Update. gcc/testsuite 2012-05-17 Paolo Carlini paolo.carl...@oracle.com PR c++/44516 * g++.dg/parse/error48.C: New. * g++.dg/template/crash89.C: Adjust dg-error line numbers. * g++.old-deja/g++.robertl/eb109.C: Add column info to dg-error string. libstdc++ 2012-05-17 Paolo Carlini paolo.carl...@oracle.com PR c++/44516 * testsuite/20_util/ratio/cons/cons_overflow_neg.cc: Adjust dg-error line number. Added: trunk/gcc/testsuite/g++.dg/parse/error48.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl2.c trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/cp/semantics.c trunk/gcc/cp/tree.c trunk/gcc/cp/typeck.c trunk/gcc/cp/typeck2.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/template/crash89.C trunk/gcc/testsuite/g++.old-deja/g++.robertl/eb109.C trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/20_util/ratio/cons/cons_overflow_neg.cc
[Bug c++/44516] improve error message when no matching operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44516 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-05-17 10:31:17 UTC --- Fixed for 4.8.0.
[Bug target/53386] Bad assembly code produced for m68000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #4 from Mikael Pettersson mikpe at it dot uu.se 2012-05-17 10:52:55 UTC --- (In reply to comment #3) (I've changed status to RESOLVED-INVALID since this is not a bug but a configuration issue) I'm not so sure about that. For supported target triplets you are not supposed to have to edit any gcc sources to get a correct compiler.
[Bug target/53386] Bad assembly code produced for m68000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386 Luis Alves ljalvs at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | --- Comment #5 from Luis Alves ljalvs at gmail dot com 2012-05-17 11:00:19 UTC --- I agree with that. I'll just leave it UNCONFIRMED until someone decides what to do with this.
[Bug target/53386] Bad assembly code produced for m68000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386 --- Comment #6 from Mikael Pettersson mikpe at it dot uu.se 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
--- Comment #7 from Mikael Pettersson mikpe at it dot uu.se 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-*-uclinux*) # Motorola m68k/ColdFire running uClinux with
uClibc
- tm_file=m68k/m68k.h m68k/m68k-none.h m68k/m68kelf.h dbxelf.h elfos.h
m68k/uclinux.h
- tm_defines=${tm_defines} MOTOROLA USE_GAS
- tmake_file=m68k/t-uclinux
+m68k-*-uclinuxoldabi*) # Motorola m68k/ColdFire running uClinux
+ # with uClibc, using the original
+ # m68k-elf-based ABI
+ default_m68k_cpu=68020
+ default_cf_cpu=5206
+ tm_file=${tm_file} m68k/m68k-none.h m68k/m68kelf.h dbxelf.h elfos.h
m68k/uclinux-oldabi.h
+ tm_defines=${tm_defines} MOTOROLA=1
+ tmake_file=m68k/t-floatlib m68k/t-uclinux
+ use_fixproto=no
+ ;;
+m68k-*-uclinux*) # Motorola m68k/ColdFire running uClinux
+ # with uClibc, using the new GNU/Linux-style
+ # ABI.
+ default_m68k_cpu=68020
+ default_cf_cpu=5206
+ tm_file=${tm_file} dbxelf.h elfos.h svr4.h linux.h flat.h m68k/linux.h
m68k/uclinux.h ./sysroot-suffix.h
+ tm_defines=${tm_defines} MOTOROLA=1 UCLIBC_DEFAULT=1
+ extra_options=${extra_options} linux.opt
+ tmake_file=m68k/t-floatlib m68k/t-uclinux m68k/t-mlibs
use_fixproto=no
;;
Upping the default m68k cpu to 020 is suspicious, but the real problem is the
inclusion of m68k/linux.h in tm_files, as that disables strict-alignment
support, even when compiling with an explicit -m68000 option.
I don't know anthing about the uClinux m68k old and new ABIs, but it looks
like you will get correct behaviour if you build for m68k-uclinuxoldabi
--with-cpu=m68000.
[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 amodra at gmail dot com changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #3 from Alan Modra amodra at gmail dot com 2012-05-17 12:04:52 UTC --- A data point. My stage1 gcc compiles the testcase in comment #1 OK, stage2 gcc gives the operand out of range error.
[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 rearnsha at gcc dot gnu.org 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
--- Comment #4 from Alan Modra amodra at gmail dot com 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;
return i;
}
is miscompiled to
sradi 3,3,63
ori 3,3,64
blr
[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 amodra at gmail dot com changed: What|Removed |Added Component|target |tree-optimization --- Comment #5 from Alan Modra amodra at gmail dot com 2012-05-17 12:38:51 UTC --- Changing back to tree-optimization. pinski, this time you don't know what you're doing. ;-)
[Bug target/53386] Bad assembly code produced for m68000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386 --- Comment #8 from Mikael Pettersson mikpe at it dot uu.se 2012-05-17 12:57:20 UTC --- Fallout from a deliberate ABI change in 4.3.x, see http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00773.html and its followups. I don't like the way an existing target triplet was reassigned an entirely different meaning, but it's too late to do anything about that now. Configuring for m68k-uclinuxoldabi is the correct solution for gcc-4.3 and newer if you need m68000-compatible code. You can close this as invalid now.
[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 glisse at gcc dot gnu.org changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #6 from Marc Glisse glisse at gcc dot gnu.org 2012-05-17 13:00:34
UTC ---
(In reply to comment #4)
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;
return i;
}
Is that just a -fwrapv issue?
[Bug target/53383] Allow -mpreferred-stack-boundary=3 on x86-64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53383 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||hjl.tools at gmail dot com, ||ubizjak at gmail dot com --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-05-17 14:00:14 UTC --- I think we can relax it under -mcmodel=kernel.
[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 hpa at zytor dot com 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 the same issue.)
[Bug target/53386] Bad assembly code produced for m68000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386 --- Comment #9 from Luis Alves ljalvs at gmail dot com 2012-05-17 14:29:07 UTC --- Thanks Mikael, But... will I have any (future) problems if I just change the flags in the config/m68k/linux.h ? In a small test I've made that solutions seems to produce good code for the 68000 but I'm afraid I might end up with a 'crippled' gcc.
[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 (reg) (call ...)) isn't the first thing in the parallel. Any reason for that? There is no reason other than the RTL was trying to reflect the save and restore of the PIC register. I hacked the call patterns to completely hide the handling of the PIC register until they are split after reload. So far, testing looks ok.
[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 Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: wschm...@gcc.gnu.org CC: berg...@vnet.ibm.com, paolo.carl...@oracle.com The following patch broke bootstrap for objc++ by failing to remove calls to build_min_nt in objc/objc-act.c. 2012-05-17 Paolo Carlini paolo.carl...@oracle.com PR c++/44516 * typeck.c (build_x_array_ref, build_x_conditional_expr, build_x_compound_expr, build_x_modify_expr): Add location_t parameter. (finish_class_member_access_expr, build_x_indirect_ref, build_x_binary_op, build_x_compound_expr_from_list, build_x_compound_expr_from_vec): Adjust callers. * tree.c (build_min_nt_loc): New. (build_min_nt): Remove. * typeck2.c (build_x_arrow): Adjust callers. * pt.c (tsubst_qualified_id, tsubst_omp_for_iterator, tsubst_copy_and_build): Likewise. * semantics.c (finish_mem_initializers, handle_omp_for_class_iterator, finish_omp_atomic): Likewise. * decl2.c (grok_array_decl, build_anon_union_vars): Adjust. * parser.c (cp_parser_question_colon_clause, cp_parser_assignment_expression, cp_parser_expression, cp_parser_template_id, cp_parser_omp_for_loop): Likewise. * cp-tree.h: Update.
[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 jakub at gcc dot gnu.org 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 target/53386] Bad assembly code produced for m68000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386 --- Comment #10 from Mikael Pettersson mikpe at it dot uu.se 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-uclinux. If you want 4.3 and newer to behave as 4.2 and older you should use m68k-uclinuxoldabi. Patching m68k/linux.h might work, but it's not a supported configuration.
[Bug c++/53388] Removal of build_min_nt breaks bootstrap for objc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53388 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-05-17 AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2012-05-17 15:10:46 UTC --- Sorry, will fix momentarily.
[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 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=gccview=revrev=187629 Log: 2012-05-17 Paolo Carlini paolo.carl...@oracle.com PR objc++/53388 * objc-act.c (objc_get_class_reference, objc_build_message_expr): Use build_min_nt_loc. Modified: trunk/gcc/objc/ChangeLog trunk/gcc/objc/objc-act.c
[Bug objc++/53388] Removal of build_min_nt breaks bootstrap for objc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53388 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC|paolo.carlini at oracle dot | |com | Resolution||FIXED --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2012-05-17 15:29:59 UTC --- Fixed.
[Bug target/53386] Bad assembly code produced for m68000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Severity|blocker |normal --- Comment #11 from Andreas Schwab sch...@linux-m68k.org 2012-05-17 15:30:09 UTC --- I would be ok with changing linux.h to honor -mstrict-align, though m68k_return_in_memory would have to be left out. The default will of course continue to be -mno-strict-align.
[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 hjl.tools at gmail dot com 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 --- Comment #12 from Luis Alves ljalvs at gmail dot com 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 incompatible code for m68k-uclinux. If you want 4.3 and newer to behave as 4.2 and older you should use m68k-uclinuxoldabi. Patching m68k/linux.h might work, but it's not a supported configuration. Just wanted to add that I use gcc to fully build a uClinux-dist (kernel+userland binaries) so it really doesn't bother me if the gcc = 4.3 generates incompatible code with gcc-4.2. And I dare to say that this is the case for everyone using uClinux.
[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 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=gccview=revrev=187630 Log: /cp 2012-05-17 Paolo Carlini paolo.carl...@oracle.com PR c++/53371 * except.c (is_admissible_throw_operand): Rename to is_admissible_throw_operand_or_catch_parameter and handle catch parameter too. (expand_start_catch_block): Use it. (build_throw): Adjust. /testsuite 2012-05-17 Paolo Carlini paolo.carl...@oracle.com PR c++/53371 * g++.dg/cpp0x/catch1.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/catch1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/except.c trunk/gcc/testsuite/ChangeLog
[Bug c++/53371] rvalue reference type as exception-declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53371 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-05-17 15:57:56 UTC --- Fixed.
[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 hpa at zytor dot com 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 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 dje at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |4.8.0 Summary|Error: operand out of |[4.8 Regression] Error: |range after changes for|operand out of range after |LSHIFT_EXPR in vrp.c|changes for LSHIFT_EXPR in ||vrp.c
[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 hpa at zytor dot com 2012-05-17 16:09:19 UTC --- The point is that the key is -mno-sse, not -mcmodel=kernel.
[Bug c/53387] gcc does not like /* */ comments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53387 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 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 think you're the only person using comments? Check yours, rather. Done, this report is bogus.
[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: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: stephan.kra...@imperial.ac.uk The following test code leaks memory rapidly - reproduced on Ubuntu's gfortran 4.6.3, with gfortran 4.7.1 and with a nightly build of 4.8, trunk revision 187620 - default optimisation flags (none specified). As far as I've narrowed it down, it seems to occur when an array function result is assigned to an allocatable array, where one of the arguments supplied to this function is itself an array function result. In the example below, the outer function and the function supplied as an argument are the same, and the returned array is an automatic array, but that does not seems to be necessary to reproduce the problem. module foo implicit none contains function filler(array, val) real, dimension(:), intent(in):: array real, dimension(size(array)):: filler real, intent(in):: val filler=val end function filler end module program test use foo implicit none real, dimension(:), allocatable:: x, y integer, parameter:: N=1000*1000 integer:: i allocate( x(N), y(N) ) y=0.0 do i=1, N print *,i x=filler(filler(y, real(2*i)), real(i)) y=y+x end do end program test
[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 mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2012-05-17 16:36:38 UTC --- Can you make the test case standalone? Currently it compiles but doesn't link, and there's nothing in it to suggest where the error could be observed.
[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 meadori at codesourcery dot com 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.gnu.org/ml/gcc-patches/2012-05/msg01042.html.
[Bug bootstrap/53384] checksum (comparison) differs wrongly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53384 --- Comment #2 from John T jrt at worldlinc dot net 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 also did a diff between the configure for 4.6.1 and 4.6.3 and didn't find anything that appeared relevant, just changes in references to libiberty. The section that tests for value changes for v. 4.6.3 and wrongly flags the change in CC starts at configure line 2091, I think. Just below that section is the start of the main body of the script where some values including the compiler execution string are set. Since the configures for 4.6.1 and 4.6.3 are nearly the same and I just built 4.6.1 successfully last night, I don't have a clue as to what's messing up the handling of the compiler value. I don't know scripting.
[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: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@intrepid.com
CC: phhargr...@lbl.gov
Host: CentOS 6 x86-32
Target: x86-32
Built on x86-32 with GCC 4.8 trunk version 187616 (2012-05-16), the attached
test case fails with following internal error (with checks enabled).
test.i: In function ‘foo’:
test.i:10:6: internal compiler error: tree check: expected integer_cst, have
nop_expr in tree_int_cst_sgn, at tree.c:6601
Back trace:
#0 internal_error (gmsgid=0x8f57f68 tree check: %s, have %s in %s, at %s:%d)
at gcc/diagnostic.c:955
#1 0x089e6b71 in tree_check_failed (node=0xb7c8a378,
file=0x8f57148 gcc/tree.c, line=6601,
function=0x8f5958c tree_int_cst_sgn)
at gcc/tree.c:8886
#2 0x089d7c50 in tree_int_cst_sgn (t=0xb7c8a378)
at gcc/tree.c:6601
#3 0x089d7108 in tree_int_cst_lt (t1=0xb7c8a378, t2=0xb7bec594)
at gcc/tree.c:6503
#4 0x089d7634 in tree_int_cst_compare (t1=0xb7c8a378, t2=0xb7bec594)
at gcc/tree.c:6525
#5 0x08e2abda in vect_compute_data_ref_alignment (dr=0x92a3768)
at gcc/tree-vect-data-refs.c:923
#6 0x08e2ae38 in vect_compute_data_refs_alignment (loop_vinfo=0x92a37e0,
bb_vinfo=0x0) at gcc/tree-vect-data-refs.c:976
#7 0x08e2d99f in vect_analyze_data_refs_alignment (loop_vinfo=0x92a37e0,
bb_vinfo=0x0)
at gcc/tree-vect-data-refs.c:2074
(gdb) f 5
#5 0x08e2abda in vect_compute_data_ref_alignment (dr=0x92a3768)
at gcc/tree-vect-data-refs.c:923
923 if (tree_int_cst_compare (DR_STEP (dr), size_zero_node) 0)
(gdb) l
918DECL_ALIGN (base) = TYPE_ALIGN (vectype)));
919
920 /* If this is a backward running DR then first access in the larger
921 vectype actually is N-1 elements before the address in the DR.
922 Adjust misalign accordingly. */
923 if (tree_int_cst_compare (DR_STEP (dr), size_zero_node) 0)
924 {
925 tree offset = ssize_int (TYPE_VECTOR_SUBPARTS (vectype) - 1);
926 /* DR_STEP(dr) is the same as -TYPE_SIZE of the scalar type,
927 otherwise we wouldn't be here. */
(gdb) down
#4 0x089d7634 in tree_int_cst_compare (t1=0xb7c8a378, t2=0xb7bec594)
at gcc/tree.c:6525
6525 if (tree_int_cst_lt (t1, t2))
(gdb) p t1
$1 = (const_tree) 0xb7c8a378
(gdb) pt
nop_expr 0xb7c8a378
type integer_type 0xb7bff0c0 ssizetype public SI
size integer_cst 0xb7bec55c constant 32
unit size integer_cst 0xb7bec578 constant 4
align 32 symtab 0 alias set -1 canonical type 0xb7bff0c0 precision 32
min integer_cst 0xb7bec620 -2147483648 max integer_cst 0xb7bec63c
2147483647
arg 0 mult_expr 0xb7c87a80
type integer_type 0xb7bff3c0 unsigned int public unsigned SI size
integer_cst 0xb7bec55c 32 unit size integer_cst 0xb7bec578 4
align 32 symtab 0 alias set -1 canonical type 0xb7bff3c0 precision
32 min integer_cst 0xb7bec86c 0 max integer_cst 0xb7bec850 4294967295
pointer_to_this pointer_type 0xb7c0b300
arg 0 nop_expr 0xb7c8a348 type integer_type 0xb7bff3c0 unsigned int
arg 0 ssa_name 0xb7c70d3c type integer_type 0xb7bff360 int
visited var var_decl 0xb7c81cc0 pretmp.12def_stmt
pretmp.12_42 = var2;
version 42
arg 1 integer_cst 0xb7c7fa64 constant 2
I was unable to cause this to fail on an x86_64 *host* compiling with -m32, but
perhaps needed to try some other configuration options. The failing compiler
above was built on an x86-32 (CentOS 6) host with --disable-bootstrap and
--enable-checking.
[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 gary at intrepid dot com 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 -fpreprocessed -O3.
[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||2012-05-17 CC||kargl at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from kargl at gcc dot gnu.org 2012-05-17 17:13:41 UTC --- Confirmed. Workaround is to use -fno-realloc-lhs
[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 gary at intrepid dot com 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.i686
[Bug rtl-optimization/53125] Very slow compilation on SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53125 --- Comment #9 from Steven Bosscher steven at gcc dot gnu.org 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=gccview=revrev=187633 Log: PR rtl-optimization/53125 * regstat.c (regstat_bb_compute_ri): Take new local_live_last_luid argument. Simplify calculation of REG_LIVE_LENGTH for regnos that die in the basic block. Correctly top off REG_FREQ and REG_FREQ_CALLS_CROSSED. Remove do_not_gen. (regstat_compute_ri): Allocate and free local_live_last_luid. Remove do_not_gen. (regstat_bb_compute_calls_crossed): Correctly top off REG_FREQ_CALLS_CROSSED. Modified: trunk/gcc/ChangeLog trunk/gcc/regstat.c
[Bug rtl-optimization/53125] Very slow compilation on SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53125 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from Steven Bosscher steven at gcc dot gnu.org 2012-05-17 17:57:05 UTC --- Fixed on trunk for GCC 4.8.
[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 steven at gcc dot gnu.org changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #4 from Steven Bosscher steven at gcc dot gnu.org 2012-05-17 18:29:27 UTC --- (In reply to comment #3) That test case isn't particularly good, either. If something like IPA-CP or inlining becomes the default at -O1, your whole test cases optimizes to a no-op. And, at least AFAICT, your test case doesn't even specifically test for the incorrect transformation.
[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 ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-17 Ever Confirmed|0 |1 --- Comment #3 from Uros Bizjak ubizjak at gmail dot com 2012-05-17 18:29:12 UTC --- Confirmed, -O2 vs. -O2 -ftree-vectorize on x86_64: -O2 -ftree-vectorize: Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls s/call s/call name 43.83 9.73 9.73 64 0.15 0.15 cptrf2_ 40.68 18.76 9.03 6685 0.00 0.00 trs2a2.2054 7.70 20.47 1.71 64 0.03 0.03 gentrs_ 1.49 20.80 0.33 64 0.01 0.01 cptrf1_ 1.40 21.11 0.311 0.3112.33 matsim_ 1.40 21.42 0.31 6685 0.00 0.00 invima.2045 1.13 21.67 0.25 64 0.00 0.00 cmpcpt_ -O2: Each sample counts as 0.01 seconds. % cumulative self self total time seconds secondscalls s/call s/call name 55.20 9.20 9.20 6685 0.00 0.00 trs2a2.2054 23.40 13.10 3.90 64 0.06 0.06 cptrf2_ 10.38 14.83 1.73 64 0.03 0.03 gentrs_ 2.58 15.26 0.43 64 0.01 0.01 cptrf1_ 2.34 15.65 0.39 6685 0.00 0.00 invima.2045 1.98 15.98 0.331 0.33 6.58 matsim_ 1.14 16.17 0.19 64 0.00 0.00 cmpcpt_ cptrf2_ runtime increased for almost 6 seconds! The only vectorization is in: 3530: LOOP VECTORIZED. rnflow.f90:3510: note: vectorized 1 loops in function. Which corresponds to: ! __ real, dimension (1:nxtr), intent (in) :: xxtrt ! extrema integer, intent (in) :: nxtr ! leur nombre integer, dimension (1:nxtr), intent (out) :: ixtrt ! indices integer, intent (out) :: kerr ! code d'erreur ! __ ! kerr = 0 ixtrt = 0 HERE This vectorization results in zeroing of certain memory area: pxor%xmm0, %xmm0 leaq(%rdx,%r8,4), %r8 xorl%esi, %esi .p2align 4,,10 .p2align 3 .L183: addq$1, %rsi movdqa%xmm0, (%r8) addq$16, %r8 cmpq%rsi, %r11 ja.L183 And this causes 6 second difference ?!
[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 mikpe at it dot uu.se 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, using the test case in the gcc-patches submission I've reproduced the bug with both gcc-4.6.3 and gcc-4.5.3 on armv5tel-linux-gnueabi.
[Bug c++/39681] Compile error is not descriptive
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39681 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com 2012-05-17 18:58:22 UTC --- Done.
[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 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=gccview=revrev=187634 Log: /cp 2012-05-17 Paolo Carlini paolo.carl...@oracle.com PR c++/39681 * parser.c (cp_parser_new_type_id): Early return error_mark_node if the cp_parser_type_specifier_seq call has type_specifier_seq.type error_mark_node; tidy. (cp_parser_new_expression): Always initialize nelts to NULL_TREE to avoid uninitialized warnings. (cp_parser_init_declarator, cp_parser_late_parse_one_default_arg): Call cp_parser_skip_to_end_of_statement if cp_parser_initializer returns error_mark_node. /testsuite 2012-05-17 Paolo Carlini paolo.carl...@oracle.com PR c++/39681 * g++.dg/parse/error48.C: New. * g++.dg/cpp0x/error8.C: Likewise. * g++.dg/ext/utf-cxx98.C: Adjust dg-error directive. * g++.dg/ext/utf-dflt2.C: Likewise. * g++.dg/ext/utf-gnuxx98.C: Likewise. * g++.dg/ext/utf-dflt.C: Likewise. * c-c++-common/raw-string-3.c: Likewise. * c-c++-common/raw-string-4.c: Likewise. Added: trunk/gcc/testsuite/g++.dg/cpp0x/error8.C trunk/gcc/testsuite/g++.dg/parse/error49.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/c-c++-common/raw-string-3.c trunk/gcc/testsuite/c-c++-common/raw-string-4.c trunk/gcc/testsuite/g++.dg/ext/utf-cxx98.C trunk/gcc/testsuite/g++.dg/ext/utf-dflt.C trunk/gcc/testsuite/g++.dg/ext/utf-dflt2.C trunk/gcc/testsuite/g++.dg/ext/utf-gnuxx98.C
[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 steven at gcc dot gnu.org 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=revisionrevision=142443
[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 ubizjak at gmail dot com 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%r9, %r8 andl$15, %eax shrq$2, %rax negq%rax andl$3, %eax cmpq%r9, %rax cmovbe%rax, %r8 cmpq$6, %r9 cmovbe%r9, %r8 testq%r8, %r8 je.L233 leaq1(%r8), %rsi movl$1, %eax .p2align 4,,10 .p2align 3 .L176: movl$0, -4(%rdx,%rax,4) addq$1, %rax cmpq%rsi, %rax jne.L176 cmpq%r9, %r8 je.L182 .L174: movq%r9, %rbp subq%r8, %rbp movq%rbp, %r11 shrq$2, %r11 leaq0(,%r11,4), %rbx testq%rbx, %rbx je.L181 pxor%xmm0, %xmm0 leaq(%rdx,%r8,4), %r8 xorl%esi, %esi .p2align 4,,10 .p2align 3 .L183: addq$1, %rsi movdqa%xmm0, (%r8) addq$16, %r8 cmpq%rsi, %r11 ja.L183 addq%rbx, %rax cmpq%rbx, %rbp je.L182 .p2align 4,,10 .p2align 3 .L181: movl$0, -4(%rdx,%rax,4) addq$1, %rax cmpq%rax, %r9 jge.L181 Whoa.
[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 meadori at codesourcery dot com 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 assembly code. Yup, 'bar'. Sorry. FWIW, using the test case in the gcc-patches submission I've reproduced the bug with both gcc-4.6.3 and gcc-4.5.3 on armv5tel-linux-gnueabi. Thanks for checking that out.
[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 glisse at gcc dot gnu.org 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 without -fwrapv.
[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 hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-05-17 CC||matz at gcc dot gnu.org Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2012-05-17 21:03:03 UTC --- It is caused by revision 186530: http://gcc.gnu.org/ml/gcc-cvs/2012-04/msg00481.html
[Bug bootstrap/53384] checksum (comparison) differs wrongly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53384 --- Comment #3 from John T jrt at worldlinc dot net 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 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 steven at gcc dot gnu.org 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_format_info() but there is no location information for the characters within the string. The location for every character in the format string should be recorded to pin-point the right line/column (think e.g. for a broken long line).
[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 mikpe at it dot uu.se 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=revisionrevision=142443 The error appears to be older than that, I can reproduce it with both r142442 and r142443.
[Bug c/52952] Wformat location info is bad (wrong column number)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52952
Steven Bosscher steven at gcc dot gnu.org changed:
What|Removed |Added
CC||steven at gcc dot gnu.org
--- Comment #1 from Steven Bosscher steven at gcc dot gnu.org 2012-05-17
21:04:56 UTC ---
extern int printf (__const char *__restrict __format, ...);
void f(void) {
printf(%.*d);
}
[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 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org Host: hppa-unknown-linux-gnu Target: hppa-unknown-linux-gnu Build: hppa-unknown-linux-gnu Created attachment 27430 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27430 preproccessed source dave@mx3210:~/debian/elfutils/elfutils-0.153/tests$ /usr/lib/gcc/hppa-linux-gnu/4.6/cc1 -fpreprocessed dwfl-bug-fd-leak.i -quiet -dumpbase dwfl-bug-fd-leak.c -auxbase-strip dwfl-bug-fd-leak.o -g -O2 -Wall -Wshadow -Wunused -Wextra -Wformat=2 -Werror -Wformat -Werror=format-security -std=gnu99 -version -fgnu89-inline -o dwfl-bug-fd-leak.s GNU C (Debian 4.6.3-5) version 4.6.3 (hppa-linux-gnu) compiled by GNU C version 4.6.3, GMP version 5.0.4, MPFR version 3.1.0-p3, MPC version 0.9 warning: GMP header version 5.0.4 differs from library version 5.0.5. warning: MPFR header version 3.1.0-p3 differs from library version 3.1.0-p10. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C (Debian 4.6.3-5) version 4.6.3 (hppa-linux-gnu) compiled by GNU C version 4.6.3, GMP version 5.0.4, MPFR version 3.1.0-p3, MPC version 0.9 warning: GMP header version 5.0.4 differs from library version 5.0.5. warning: MPFR header version 3.1.0-p3 differs from library version 3.1.0-p10. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 49e4550ab571851527453d4bbdbdb0e0 dwfl-bug-fd-leak.c: In function ‘main’: dwfl-bug-fd-leak.c:110:1: error: unrecognizable insn: (insn 42 41 43 5 (set (subreg:SI (reg:DI 125) 4) (mem:SI (subreg:SI (reg:DI 125) 4) [0 S4 A32])) /usr/include/hppa-linux-gnu/bits/error.h:41 -1 (nil)) dwfl-bug-fd-leak.c:110:1: internal compiler error: in extract_insn, at recog.c:2109 Please submit a full bug report, with preprocessed source if appropriate.
[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
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: keith.s.thomp...@gmail.com
Given the following program (c.c):
#include stdio.h
int main(void) {
typedef long my_long;
my_long x = 42;
printf(x = %d\n, (long)x);
return 0;
}
gcc -c c.c produces the following warning:
c.c: In function ‘main’:
c.c:5:5: warning: format ‘%d’ expects argument of type ‘int’, but argument 2
has type ‘my_long’ [-Wformat]
The argument is actually of type long, not my_long; the warning should say
..., but argument 2 has type ‘long’.
Now because of the way typedefs work, long and my_long are really different
names for the same type. gcc is obviously trying to be clever about which name
makes for a clearer warning message. In this case, since x is explicitly
converted to long, referring to long would be less confusing. *Some* warning
is certainly appropriate, since %d requires an int argument.
(Speculation: gcc sees that the cast is a no-op, so it ignores it, which is
fine except that it results in this misleading warning message.)
Ubuntu x86 12.04
gcc (Ubuntu/Linaro 4.7.0-7ubuntu3) 4.7.0
[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 michael.hope at linaro dot org changed: What|Removed |Added CC||michael.hope at linaro dot ||org --- Comment #1 from Michael Hope michael.hope at linaro dot org 2012-05-18 01:38:31 UTC --- Added as part of r186122 to fix PR c++/52796.
[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 wschmidt at gcc dot gnu.org 2012-05-18 03:42:46 UTC --- I suspect you're right. I'll have a look at it tomorrow.
