[Bug rtl-optimization/54592] [4.8 Regression] Cannot fuse SSE move and add together
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54592 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #3 from Jakub Jelinek 2012-09-18 07:18:40 UTC --- Created attachment 28209 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28209 gcc48-pr54592.patch Untested fix.
[Bug fortran/54613] New: [F2003/F2008] Add FINDLOC plus support MAXLOC/MINLOC with KIND=/BACK=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54613
Bug #: 54613
Summary: [F2003/F2008] Add FINDLOC plus support MAXLOC/MINLOC
with KIND=/BACK=
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
Fortran 2003 (cf. PR 29600) added KIND= to MINLOC/MAXLOC, Fortran 2008 added
BACK=. Additionally, Fortran 2008 added FINDLOC with a similar syntax.
See also James' post in "binary data"
https://groups.google.com/forum/?fromgroups=#!topic/comp.lang.fortran/GpaACNKn0Ds
"As can be seen from the commented out code, gfortran does not yet
implement the BACK= argument for the MAXLOC and MINLOC intrinsics,
doesn't yet implement MAXLOC, MAXVAL, MINLOC, MINVAL for constant
expressions and doesn't implement FINDLOC at all."
See also his comments in
https://groups.google.com/forum/?fromgroups=#!topic/comp.lang.fortran/5eAz5ns6AG0
The first step is to implement the run-time version, i.e. extending
MINLOC/MAXLOC and adding FINDLOC.
(trans-intrinsic.c version, frontend-optimization.c and the library version,
possibly such that one doesn't cause an explosion of the intrinsics, e.g. only
returning default + index-type? If so, one needs to have a RANGE_REF copy for
the array results - and for the MASK argument.)
As a next step, one has to think of the compile-time simplification of
{MIN,MAX}{VAL,LOC},FINDLOC.
Re: libiberty sha1.c: bug in adding 64-bit number to 64-bit number (binutils-2.22.90)
On 09/18/2012 02:13 AM, Geoff Pike wrote: Hello libiberty experts, I don't see anything saying that sha1_process_block() has a size limit on its input buffer, and if the length of the buffer is big (e.g., 2^32 on a 64-bit machine) then this code won't correctly add a 64-bit number to 64-bit number: /* First increment the byte count. RFC 1321 specifies the possible length of the file up to 2^64 bits. Here we only compute the number of bytes. Do a double word increment. */ ctx->total[0] += len; if (ctx->total[0] < len) ++ctx->total[1]; The above is at sha1.c around line 302. I'm not sure if many people read the gcc-bugs list, it's mainly fed from Bugzilla. Better file a bug. After a quick look at the code, I'm wondering if the ~63 is properly sign-extended and then converted to size_t: sha1_process_block (buffer, len & ~63, ctx); This should work, but it looks a bit fishy. -- Florian Weimer / Red Hat Product Security Team
[Bug tree-optimization/54610] [4.8 Regression] FAIL: gcc.dg/tree-ssa/forwprop-22.c (internal compiler error) on x86 AVX targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54610 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-09-18 CC||jakub at gcc dot gnu.org AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0 Ever Confirmed|0 |1 --- Comment #2 from Jakub Jelinek 2012-09-18 08:02:00 UTC --- The bug is obvious, vect_gen_perm_mask is not suitable for uses outside of the vectorizer, it uses e.g. current_vector_size.
[Bug rtl-optimization/54524] Spurious add on sum of bitshifts (forward-propagate issue)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54524 Jan Smets changed: What|Removed |Added Severity|normal |major
[Bug tree-optimization/54610] [4.8 Regression] FAIL: gcc.dg/tree-ssa/forwprop-22.c (internal compiler error) on x86 AVX targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54610 --- Comment #3 from Jakub Jelinek 2012-09-18 08:32:52 UTC --- Created attachment 28210 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28210 gcc48-pr54610.patch Untested fix.
[Bug other/54411] libiberty: objalloc_alloc integer overflows (CVE-2012-3509)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54411 --- Comment #5 from Florian Weimer 2012-09-18 08:34:12 UTC --- Author: fw Date: Tue Sep 18 08:34:05 2012 New Revision: 191413 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191413 Log: PR other/54411: integer overflow in objalloc_alloc 2012-09-18 Florian Weimer PR other/54411 * objalloc.h (objalloc_alloc): Do not use fast path on wraparound. 2012-09-18 Florian Weimer PR other/54411 * objalloc.c (_objalloc_alloc): Add overflow check covering alignment and CHUNK_HEADER_SIZE addition. Modified: trunk/include/ChangeLog trunk/include/objalloc.h trunk/libiberty/ChangeLog trunk/libiberty/objalloc.c
[Bug libstdc++/54612] [4.8 Regression] Many failures in ext/random testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54612 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug bootstrap/54611] [4.8 regression] Bootstrap failure: conflicting types for 'backtrace_simple'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54611 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug fortran/54613] [F2003/F2008] Add FINDLOC plus support MAXLOC/MINLOC with KIND=/BACK=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54613 --- Comment #1 from Tobias Burnus 2012-09-18 09:17:25 UTC --- Created attachment 28211 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28211 Very preliminary patch for MAXLOC/MINLOC Very preliminary patch for the MAXLOC/MINLOC support; i.e. documentation and resolving plus identifying the spot (and needed changes) for trans-intrinsic.c. Implementing the latter and in particular the library support are still lacking. (As is FINDLOC.)
[Bug fortran/54613] [F2003/F2008] Add FINDLOC plus support MAXLOC/MINLOC with KIND=/BACK=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54613 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-18 Ever Confirmed|0 |1 --- Comment #2 from Dominique d'Humieres 2012-09-18 09:25:36 UTC --- This PR seems related to pr25104 and pr45689.
[Bug fortran/54599] Issues found in gfortran by the Coverity Scan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54599
--- Comment #3 from Tobias Burnus 2012-09-18
09:28:46 UTC ---
Dump two patches here. First is about a pointless check ("nl->sym->..." is used
all over the place) and the second: If the assert fails, we would use
TREE_TYPE(NULL_TREE) ...
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -12481 +12481 @@ resolve_fl_namelist (gfc_symbol *sym)
- if (nl->sym && nl->sym->name)
+ if (nl->sym->name)
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -1024,4 +1024,4 @@ gfc_trans_create_temp_array (stmtblock_t * pre,
stmtblock_t * post, gfc_ss * ss,
{
- if (POINTER_TYPE_P (TREE_TYPE (initial)))
- class_expr = build_fold_indirect_ref_loc (input_location, initial);
+ gcc_assert (POINTER_TYPE_P (TREE_TYPE (initial)));
+ class_expr = build_fold_indirect_ref_loc (input_location, initial);
eltype = TREE_TYPE (class_expr);
[Bug c++/54575] [4.8 Regression] ICE with std::vector::insert and -std=c++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54575 --- Comment #11 from Paolo Carlini 2012-09-18 09:41:29 UTC --- Thanks a lot Jason!
[Bug libstdc++/54612] [4.8 Regression] Many failures in ext/random testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54612 Paolo Carlini changed: What|Removed |Added CC||drepper.fsp at gmail dot ||com --- Comment #1 from Paolo Carlini 2012-09-18 09:45:07 UTC --- Ulrich, can you please handle this?
[Bug fortran/54599] Issues found in gfortran by the Coverity Scan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54599
--- Comment #4 from Tobias Burnus 2012-09-18
10:10:28 UTC ---
And another one: Unreachable code; due to "if(extremum == NULL) {...;
continue}", last == NULL is always false:
--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -4109,4 +4109 @@ simplify_min_max (gfc_expr *expr, int sign)
- if (last == NULL)
- expr->value.function.actual = arg->next;
- else
- last->next = arg->next;
+ last->next = arg->next;
[Bug ada/54614] New: Vector * Matrix -> Vector gives wrong result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54614 Bug #: 54614 Summary: Vector * Matrix -> Vector gives wrong result Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: si...@pushface.org Created attachment 28212 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28212 Reproducer At GCC 4.7.0 (and in SVN r191415) System.Generic_Array_Operations.Vector_Matrix_Product returns the wrong result. The attached code should output ** V*M : 3010.0 4020.0 but in fact outputs ** V*M : 40.0 6000.0 I've also attached a patch for GCC 4.7.0.
[Bug ada/54614] Vector * Matrix -> Vector gives wrong result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54614 --- Comment #1 from simon at pushface dot org 2012-09-18 10:44:47 UTC --- Created attachment 28213 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28213 Proposed patch for 4.7.0 code
[Bug c/7652] -Wswitch-break : Warn if a switch case falls through
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #14 from Manuel López-Ibáñez 2012-09-18 11:10:39 UTC --- > In an ideal world, it would be great if GCC had a compatible implementation > using C++11 attributes (except for a namespace of the attribute), or for > example, using a built-in function. So that it was possible to have the same > syntax in source code, at least using a macro. Command-line flags > compatibility > would also be nice. I am pretty sure that if a proper patch is submitted to GCC, it will get approved, even without the special attribute (that could be a follow-up patch). The reason this has not been implemented is simply that no one has stepped forward to do the work.
[Bug libstdc++/54612] [4.8 Regression] Many failures in ext/random testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54612 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek 2012-09-18 11:49:21 UTC --- I get lots of failures on i386-linux bootstrap too. While include/ext/random has #ifdef __SSE2__ # include #endif and all other spots guarded with #ifdef __SSE2__, config/cpu/i486/opt/ext/opt_random.h doesn't have any #ifdef __SSE2__ guards in it.
[Bug middle-end/54615] New: unclear documentation on -fomit-frame-pointer for -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54615 Bug #: 54615 Summary: unclear documentation on -fomit-frame-pointer for -O Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: vincent-...@vinc17.net http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html says about -O: -O also turns on -fomit-frame-pointer on machines where doing so does not interfere with debugging. and about -fomit-frame-pointer: Enabled at levels -O, -O2, -O3, -Os. So, it is not clear whether -fomit-frame-pointer is always enabled at level -O or not. This bug is related to bug 51019 (unclear documentation on -fomit-frame-pointer default for -Os and different platforms).
[Bug libstdc++/54612] [4.8 Regression] Many failures in ext/random testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54612 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-18 CC||paolo.carlini at oracle dot ||com Ever Confirmed|0 |1 --- Comment #3 from Paolo Carlini 2012-09-18 12:09:05 UTC --- Jakub, I'm attaching a patchlet which works for me for the first issue, then I also added the __SSE2__ guard. Can you test it? In case feel free to apply it, I will not be able to do that until this evening.
[Bug libstdc++/54612] [4.8 Regression] Many failures in ext/random testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54612 --- Comment #4 from Paolo Carlini 2012-09-18 12:11:08 UTC --- Created attachment 28214 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28214 Lightly tested so far
[Bug target/52483] SH Target: Loads from volatile memory leave redundant sign/zero extensions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52483 --- Comment #3 from Kazumoto Kojima 2012-09-18 12:25:52 UTC --- (In reply to comment #2) > If that is the only reason for rejecting volatile mems, then I think it would > be OK to match volatile mems in the load/store expanders for SH, since there > are no arithmetic insns that take mems anyway (except for some GBR byte mem > modification insns, which aren't used in the backend). > Kaz, does this make sense? Yep, though I'm not sure whether that is the only reason or not. Please go ahead and see the effect.
[Bug c++/54372] __attribute__((unused)) doesn't work with unused local typedef in template function.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54372 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-18 CC||paolo.carlini at oracle dot ||com Ever Confirmed|0 |1 --- Comment #2 from Paolo Carlini 2012-09-18 12:38:48 UTC --- Now that the new warning is also in -Wall, it would be nice to fix this. Note that local variables are already "more than Ok", that is at template definition time we produce no -Wunused warnings at all even without the attribute (we only warn at instantiation time): I suppose something similar should be not too difficult to implement for the new warning too... Dodji, what do you think?
[Bug rtl-optimization/54524] Spurious add on sum of bitshifts (forward-propagate issue)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54524 Jan Smets changed: What|Removed |Added Target|mips|mipsisa64-octeon-elf Known to work||4.5.0, 4.5.4 Known to fail||4.6.0, 4.6.3, 4.7.1, 4.8.0 --- Comment #2 from Jan Smets 2012-09-18 12:41:43 UTC --- GCC 4.5.4 => CORRECT 0: 27bdffd0addiu sp,sp,-48 4: 97a5001clhu a1,28(sp) 8: 000427c0sll a0,a0,0x1f c: 00053600sll a2,a1,0x18 10: 3c030040lui v1,0x40 14: 00052a02srl a1,a1,0x8 18: 00a42821addua1,a1,a0 1c: 00c33821addua3,a2,v1 20: 3c024000lui v0,0x4000 24: 00e6302bsltua2,a3,a2 28: 00a21021adduv0,a1,v0 2c: 3c04lui a0,0x0 2c: R_MIPS_HI16 .rodata 30: 2484addiu a0,a0,0 30: R_MIPS_LO16 .rodata 34: afbf002csw ra,44(sp) 38: 0c00jal 0 38: R_MIPS_26 printf 3c: 00c23021addua2,a2,v0 <= ! 40: 8fbf002clw ra,44(sp) 44: 03e8jr ra 48: 27bd0030addiu sp,sp,48 GCC 4.6.3 = 0: 27bdffd0addiu sp,sp,-48 4: 97a5001clhu a1,28(sp) 8: 3c030040lui v1,0x40 c: 3c024000lui v0,0x4000 10: 00054600sll t0,a1,0x18 14: 01033821addua3,t0,v1 18: 00052a02srl a1,a1,0x8 1c: 00e8402bsltut0,a3,t0 20: 00a21021adduv0,a1,v0 24: 000427c0sll a0,a0,0x1f 28: 01023021addua2,t0,v0 2c: 00c43021addua2,a2,a0 30: 3c04lui a0,0x0 30: R_MIPS_HI16 .rodata 34: 2484addiu a0,a0,0 34: R_MIPS_LO16 .rodata 38: afbf002csw ra,44(sp) 3c: 0c00jal 0 3c: R_MIPS_26 printf 40: 24c60001addiu a2,a2,1 <= ! 44: 8fbf002clw ra,44(sp) 48: 03e8jr ra 4c: 27bd0030addiu sp,sp,48 GCC 4.8.0 = 0: 27bdffd0addiu sp,sp,-48 4: 97a6001clhu a2,28(sp) 8: 3c030040lui v1,0x40 c: 00062e00sll a1,a2,0x18 10: 00a33821addua3,a1,v1 14: 00063202srl a2,a2,0x8 18: 3c024000lui v0,0x4000 1c: 00e5282bsltua1,a3,a1 20: 00c21021adduv0,a2,v0 24: 000427c0sll a0,a0,0x1f 28: 00a21021adduv0,a1,v0 2c: 00443021addua2,v0,a0 30: 3c04lui a0,0x0 30: R_MIPS_HI16 .rodata 34: 2484addiu a0,a0,0 34: R_MIPS_LO16 .rodata 38: afbf002csw ra,44(sp) 3c: 0c00jal 0 3c: R_MIPS_26 printf 40: 24c60001addiu a2,a2,1<= ! 44: 8fbf002clw ra,44(sp) 48: 03e8jr ra 4c: 27bd0030addiu sp,sp,48
[Bug tree-optimization/54610] [4.8 Regression] FAIL: gcc.dg/tree-ssa/forwprop-22.c (internal compiler error) on x86 AVX targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54610 --- Comment #4 from Jakub Jelinek 2012-09-18 13:03:13 UTC --- Author: jakub Date: Tue Sep 18 13:03:09 2012 New Revision: 191421 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191421 Log: PR tree-optimization/54610 * tree-ssa-forwprop.c: Include optabs.h. Don't include tree-vectorizer.h. (simplify_vector_constructor): Don't use vect_gen_perm_mask, instead create the mask constant here. * Makefile.in (tree-ssa-forwprop.o): Depend on $(OPTABS_H). Don't depend on $(TREE_VECTORIZER_H). * gcc.target/i386/pr54610.c: New test. Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-forwprop.c
[Bug rtl-optimization/54524] [4.6/4.7/4.8 Regression] Spurious add on sum of bitshifts (forward-propagate issue)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54524 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.6.4 Summary|Spurious add on sum of |[4.6/4.7/4.8 Regression] |bitshifts |Spurious add on sum of |(forward-propagate issue) |bitshifts ||(forward-propagate issue)
[Bug tree-optimization/54610] [4.8 Regression] FAIL: gcc.dg/tree-ssa/forwprop-22.c (internal compiler error) on x86 AVX targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54610 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Jakub Jelinek 2012-09-18 13:16:13 UTC --- Fixed.
[Bug c++/54616] New: Segmentation fault (during parsing?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54616
Bug #: 54616
Summary: Segmentation fault (during parsing?)
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: patrik.h.haggl...@gmail.com
cat << EOF > foo.c
class node { virtual bool is_sub (); };
class __lambda:node {};
EOF
g++ -c foo.c
foo.c:2:7: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
(This is a reduced testcase (using C-Reduce and hand editing), originated from
compiling cxa_demangle.cpp in lldb.)
[Bug c++/54616] Segmentation fault (during parsing?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54616 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Paolo Carlini 2012-09-18 13:47:54 UTC --- Dup. *** This bug has been marked as a duplicate of bug 54420 ***
[Bug c++/54420] [4.6/4.7/4.8 Regression] Segmentation fault in decl_mangling_context
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54420 Paolo Carlini changed: What|Removed |Added CC||patrik.h.hagglund at gmail ||dot com --- Comment #5 from Paolo Carlini 2012-09-18 13:47:54 UTC --- *** Bug 54616 has been marked as a duplicate of this bug. ***
[Bug c++/54575] [4.8 Regression] ICE with std::vector::insert and -std=c++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54575 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #12 from Paolo Carlini 2012-09-18 13:54:51 UTC --- I guess we can close this, I double checked that the original testcase is also fine now.
[Bug libstdc++/54612] [4.8 Regression] Many failures in ext/random testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54612 --- Comment #5 from paolo at gcc dot gnu.org 2012-09-18 14:02:25 UTC --- Author: paolo Date: Tue Sep 18 14:02:20 2012 New Revision: 191424 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191424 Log: 2012-09-18 Paolo Carlini PR libstdc++/54612 * include/ext/random.tcc (operator== (const __gnu_cxx::simd_fast_mersenne_twister_engine<>&, const __gnu_cxx::simd_fast_mersenne_twister_engine<>&)): Fix state_size use. * config/cpu/i486/opt/ext/opt_random.h: Guard with __SSE2__. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/cpu/i486/opt/ext/opt_random.h trunk/libstdc++-v3/include/ext/random.tcc
[Bug lto/54095] Unnecessary static variable renaming
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54095 Richard Guenther changed: What|Removed |Added Attachment #27879|0 |1 is obsolete|| --- Comment #5 from Richard Guenther 2012-09-18 14:20:45 UTC --- Created attachment 28215 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28215 patch More complete patch, still has issues. We rely on the name mapping to find LTO data but that for some reason is confused when we try to rename late. Which you can see from LTO testsuite fails caused by this patch. At least with the partitioning reorg the patch doesn't look as bad as before ;)
[Bug target/54617] New: [4.8 Regression] ICE when compiling gcc.c-torture/compile/pr42025-2.c on powerpc-apple-darwin9 with -m64 and -O1 or above after revision 191302
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54617 Bug #: 54617 Summary: [4.8 Regression] ICE when compiling gcc.c-torture/compile/pr42025-2.c on powerpc-apple-darwin9 with -m64 and -O1 or above after revision 191302 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: ebotca...@gcc.gnu.org, ia...@gcc.gnu.org Host: powerpc-apple-darwin9 Target: powerpc-apple-darwin9 Build: powerpc-apple-darwin9 When compiling gcc.c-torture/compile/pr42025-2.c on powerpc-apple-darwin9 with -m64 and -O1 or above after revision 191302, one gets the following ICE: /opt/gcc/work/gcc/testsuite/gcc.c-torture/compile/pr42025-2.c: In function 'bar': /opt/gcc/work/gcc/testsuite/gcc.c-torture/compile/pr42025-2.c:22:11: internal compiler error: in emit_move_insn, at expr.c:3458 p.u.p = get_stuff (); The test compiles at revision 191298.
[Bug target/54617] [4.8 Regression] ICE when compiling gcc.c-torture/compile/pr42025-2.c on powerpc-apple-darwin9 with -m64 and -O1 or above after revision 191302
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54617
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-09-18
Ever Confirmed|0 |1
--- Comment #1 from Eric Botcazou 2012-09-18
15:07:38 UTC ---
I cannot build a cross without:
Index: config/darwin-c.c
===
--- config/darwin-c.c (revision 191429)
+++ config/darwin-c.c (working copy)
@@ -267,7 +267,7 @@ static struct framework_header framework
static char *
framework_construct_pathname (const char *fname, cpp_dir *dir)
{
- char *buf;
+ const char *buf;
size_t fname_len, frname_len;
cpp_dir *fast_dir;
char *frname;
@@ -344,7 +344,7 @@ find_subframework_file (const char *fnam
{
char *sfrname;
const char *dot_framework = ".framework/";
- char *bufptr;
+ const char *bufptr;
int sfrname_len, i, fname_len;
struct cpp_dir *fast_dir;
static struct cpp_dir subframe_dir;
so please include the above in your next round of testing. This is with:
eric@polaris:~/build/gcc/powerpc-apple-darwin> g++ --version
g++ (SUSE Linux) 4.6.2
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug target/54617] [4.8 Regression] ICE when compiling gcc.c-torture/compile/pr42025-2.c on powerpc-apple-darwin9 with -m64 and -O1 or above after revision 191302
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54617 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED CC|ebotcazou at gcc dot| |gnu.org | AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot |gnu.org |gnu.org --- Comment #2 from Eric Botcazou 2012-09-18 15:10:14 UTC --- Fixing.
[Bug rtl-optimization/54592] [4.8 Regression] Cannot fuse SSE move and add together
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54592 --- Comment #4 from Jakub Jelinek 2012-09-18 15:14:20 UTC --- Author: jakub Date: Tue Sep 18 15:14:15 2012 New Revision: 191430 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191430 Log: PR target/54592 * config/i386/i386.c (ix86_rtx_costs): Limit > UNITS_PER_WORD AND/IOR/XOR cost calculation to MODE_INT class modes. * gcc.target/i386/pr54592.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr54592.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/54618] New: [OOP] wrong-code with CLASS(...), INTENT(OUT) -- and OPTIONAL or ALLOCATABLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54618
Bug #: 54618
Summary: [OOP] wrong-code with CLASS(...), INTENT(OUT) -- and
OPTIONAL or ALLOCATABLE
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: ja...@gcc.gnu.org
The following program gives an ICE because one has:
f (struct __class_p_T * y)
{
__builtin_memcpy (y->_data, y->_vptr->_def_init, y->_vptr->_size);
}
The code lacks an "if (y->_data)" check via gfc_conv_expr_present in
init_intent_out_dt.
program p
type t
end type t
type(t) :: x
call f(x)
call f()
contains
subroutine f(y)
class(t), intent(out), optional :: y
end subroutine f
end program p
* * *
While the following program fails because there is no deallocate/memcpy in f:
f (struct __class_p_T_a & restrict y)
{
}
program p
type t
end type t
type, extends(t):: t2
end type t2
class(t), allocatable :: x,y
allocate (t2 :: x)
call f(x)
if (allocated (x) .or. .not. same_type_as (x,y)) call abort()
contains
subroutine f(y)
class(t), intent(out), allocatable :: y
end subroutine f
end program p
[Bug rtl-optimization/54592] [4.8 Regression] Cannot fuse SSE move and add together
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54592 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Jakub Jelinek 2012-09-18 15:30:07 UTC --- Fixed.
[Bug c++/54575] [4.8 Regression] ICE with std::vector::insert and -std=c++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54575 --- Comment #13 from Wolfgang Bangerth 2012-09-18 15:32:17 UTC --- Thanks, all, for the quick turnaround. This works again, not just on the testcase but on the entire code base. Best W.
[Bug tree-optimization/54610] [4.8 Regression] FAIL: gcc.dg/tree-ssa/forwprop-22.c (internal compiler error) on x86 AVX targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54610 --- Comment #6 from Marc Glisse 2012-09-18 16:06:43 UTC --- (In reply to comment #2) > The bug is obvious, vect_gen_perm_mask is not suitable for uses outside of the > vectorizer, it uses e.g. current_vector_size. Argh, I was happy to find a function that did just what I needed, and I couldn't see any reason why it would need anything besides what was passed as arguments, so I went ahead without looking too closely, sorry. Thanks a lot Jakub for handling it so quickly (I am away for the first half of this week). By the way, I still don't understand why vect_gen_perm_mask uses current_vector_size when it has nunits at its disposal. Would it be useless to change that (assuming it makes sense)?
[Bug tree-optimization/54610] [4.8 Regression] FAIL: gcc.dg/tree-ssa/forwprop-22.c (internal compiler error) on x86 AVX targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54610 --- Comment #7 from Jakub Jelinek 2012-09-18 16:14:58 UTC --- It is true that it has TYPE_VECTOR_SUBPARTS at its disposal, but it just uses the common vectorizer infrastructure to create vector types. The routines it is using also use other vectorizer specific stuff, like vect_print_dump_info. So, if you really want, the better way would be to create a new helper routine in tree-vect-generic.c, that would do what I've changed the routine to do, and use that routine in tree-ssa-forwprop.c and possibly in tree-vect-generic.c too.
[Bug tree-optimization/54610] [4.8 Regression] FAIL: gcc.dg/tree-ssa/forwprop-22.c (internal compiler error) on x86 AVX targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54610 --- Comment #8 from Marc Glisse 2012-09-18 16:22:09 UTC --- (In reply to comment #7) > It is true that it has TYPE_VECTOR_SUBPARTS at its disposal, but it just uses > the common vectorizer infrastructure to create vector types. > The routines it is using also use other vectorizer specific stuff, like > vect_print_dump_info. That one probably wouldn't hurt so much, but I see your point, it is really not meant to be generic. > So, if you really want, the better way would be to > create a new helper routine in tree-vect-generic.c, that would do what I've > changed the routine to do, and use that routine in tree-ssa-forwprop.c and > possibly in tree-vect-generic.c too. Thanks, I'll do that if I need it again.
[Bug middle-end/54617] [4.8 Regression] ICE on gcc.c-torture/compile/pr42025-2.c with -m64 and -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54617 Eric Botcazou changed: What|Removed |Added Component|target |middle-end Target Milestone|--- |4.8.0 Summary|[4.8 Regression] ICE when |[4.8 Regression] ICE on |compiling |gcc.c-torture/compile/pr420 |gcc.c-torture/compile/pr420 |25-2.c with -m64 and -O1 |25-2.c on | |powerpc-apple-darwin9 with | |-m64 and -O1 or above after | |revision 191302 |
[Bug target/54619] New: GCC aborts during compilation with '-O2 -mips16'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54619
Bug #: 54619
Summary: GCC aborts during compilation with '-O2 -mips16'
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s...@gcc.gnu.org
Target: mips*-*-*
I am getting a Floating point exception from the compiler while compiling the
following small test program with -O2 -mips16. I can reproduce it while using
a native or cross compiler targeting mips and while generating code for big or
little endian. I could also reproduce it on targets for linux and for elf.
% cat q.c
swapfunc(char *a , char *b , int n , int swaptype)
{
long i = (n) / sizeof (char);
char *pi = (char *) (a);
char *pj = (char *) (b);
do {
*pi++ = *pj;
} while (--i > 0);
}
qsort(void *a)
{
char *pb;
int r;
int swaptype;
swapfunc(a, pb - r, r, swaptype);
}
% obj*/gcc/initial/gcc/cc1 -quiet -mel -O2 -mips16 q.c
q.c: In function ‘qsort’:
q.c:10:1: internal compiler error: Floating point exception
qsort(void *a)
^
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
% obj*/gcc/gcc/cc1 -version
GNU C (GCC) version 4.8.0 20120913 (experimental) (mipsel-unknown-linux-gnu)
compiled by GNU C version 4.8.0 20120913 (experimental), GMP version 4.3.2,
MPFR version 3.0.0-p3, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
[Bug other/54620] New: sha1.c has incorrect math if sizeof(size_t) is 8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54620 Bug #: 54620 Summary: sha1.c has incorrect math if sizeof(size_t) is 8 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: pikegadgets+...@gmail.com In libiberty/sha1.*, I don't see anything saying that sha1_process_block() has a size limit on its input buffer, and if the length of the buffer is big (e.g., 2^32 on a 64-bit machine) then this code won't correctly add a 64-bit number to 64-bit number: /* First increment the byte count. RFC 1321 specifies the possible length of the file up to 2^64 bits. Here we only compute the number of bytes. Do a double word increment. */ ctx->total[0] += len; if (ctx->total[0] < len) ++ctx->total[1]; The above is at sha1.c around line 302. Also, Florian Weimer pointed out that code nearby uses "len & ~63" when it perhaps should use something like "len & (~(size_t)63)". Similar bug(s) are in md5.*. See bug 39064 for details.
[Bug target/54619] GCC aborts during compilation with '-O2 -mips16'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54619 --- Comment #1 from Steve Ellcey 2012-09-18 18:34:21 UTC --- It looks like this is coming from mips16_unextended_reference_p, if mode is VOIDmode then GET_MODE_SIZE (mode) is zero and we wind up doing 'offset % 0'. I think we should be checking for 'GET_MODE_SIZE == 0' instead of mode != 'BLKmode'. before doing the modulo instruction.
[Bug c/54621] New: internal compiler error: Segmentation fault when compiling gSOAP generated Server module.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54621 Bug #: 54621 Summary: internal compiler error: Segmentation fault when compiling gSOAP generated Server module. Classification: Unclassified Product: gcc Version: 4.2.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: nospampe...@yahoo.com gSOAP module compilation fails with a segmentation fault. uvGsoapC.c: In function 'soap_putindependent': uvGsoapC.c:20343: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. SIX:doug:1>
[Bug c/54621] internal compiler error: Segmentation fault when compiling gSOAP generated Server module.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54621 --- Comment #1 from Doug Dawson 2012-09-18 20:48:49 UTC --- Created attachment 28216 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28216 Console output from compilation. gzipped Interim code is too large to attach. Please access it at www.csfi.com/uvGsoapServerLib.i.gz
[Bug c/54621] internal compiler error: Segmentation fault when compiling gSOAP generated Server module.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54621 Marek Polacek changed: What|Removed |Added CC||polacek at redhat dot com --- Comment #2 from Marek Polacek 2012-09-18 21:33:14 UTC --- Please provide (possibly gzipped) preprocessed source.
[Bug ada/54614] Vector * Matrix -> Vector gives wrong result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54614 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-09-18 CC||charlet at gcc dot gnu.org, ||ebotcazou at gcc dot ||gnu.org Ever Confirmed|0 |1 --- Comment #2 from Eric Botcazou 2012-09-18 21:38:41 UTC --- Thanks for the report and the patch.
[Bug target/54584] m68k-uclinux error: Link tests are not allowed after GCC_NO_EXECUTABLES
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54584 --- Comment #3 from Larry Baker 2012-09-18 21:43:32 UTC --- I don't know how to attach gdb to the ld.real called by collect2. So, I added a bunch of debugging output to bfd/elflink.c to find out where the failure occurs. (I'll attach my hacked version.) Here's the link without -elf2flt and with -elf2flt. The object files/libraries are the same, yet the program sections that ld.real sees are quite different. $ COMPILER_PATH=/tmp/freescale-coldfile-xgcc/cross-gcc-4.7.1/gcc/:/usr/local/gcc-4.7.1/m68k-uclinux/bin/:/usr/local/gcc-4.7.1/m68k-uclinux/lib/ /tmp/freescale-coldfile-xgcc/cross-gcc-4.7.1/gcc/collect2 --sysroot=/tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data --eh-frame-hdr -o conftest -t /tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/crt1.o /tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/crti.o /tmp/freescale-coldfile-xgcc/cross-gcc-4.7.1/gcc/msep-data/crtbegin.o -L/tmp/freescale-coldfile-xgcc/cross-gcc-4.7.1/gcc/msep-data -L/usr/local/gcc-4.7.1/m68k-uclinux/lib/msep-data -L/tmp/freescale-coldfile-xgcc/cross-gcc-4.7.1/gcc -L/usr/local/gcc-4.7.1/m68k-uclinux/bin -L/usr/local/gcc-4.7.1/m68k-uclinux/lib -L/tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib conftest.o -lgcc -lc -lgcc /tmp/freescale-coldfile-xgcc/cross-gcc-4.7.1/gcc/msep-data/crtend.o /tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/crtn.o /usr/local/gcc-4.7.1/m68k-uclinux/bin/ld.real: mode m68kelf /tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/crt1.o /tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/crti.o /tmp/freescale-coldfile-xgcc/cross-gcc-4.7.1/gcc/msep-data/crtbegin.o conftest.o (/tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/libc.a)__uClibc_main.o (/tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/libc.a)strrchr.o (/tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/libc.a)exit.o (/tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/libc.a)_exit.o (/tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/libc.a)__errno_location.o (/tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/libc.a)strchr.o (/tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/libc.a)errno.o /tmp/freescale-coldfile-xgcc/cross-gcc-4.7.1/gcc/msep-data/crtend.o /tmp/freescale-coldfile-xgcc/freescale-coldfire-2011.09/m68k-uclinux/libc/msep-data/usr/lib/crtn.o ---> ldwrite: pid = 81433 ---> ldwrite: lang_for_each_statement() ---> ldwrite: bfd_final_link() ---> bfd_elf_final_link: ---> bfd_elf_final_link: remove input section .init ---> bfd_elf_final_link: remove input section .text ---> bfd_elf_final_link: remove input section .fini ---> bfd_elf_final_link: remove input section .rodata ---> bfd_elf_final_link: remove input section .eh_frame ---> bfd_elf_final_link: remove input section .ctors ---> bfd_elf_final_link: remove input section .dtors ---> bfd_elf_final_link: remove input section .jcr ---> bfd_elf_final_link: remove input section .got ---> bfd_elf_final_link: remove input section .data ---> bfd_elf_final_link: remove input section .bss ---> bfd_elf_final_link: remove input section .comment ---> bfd_elf_final_link: count relocations for section .init ---> bfd_elf_final_link: count relocations for section .text ---> bfd_elf_final_link: count relocations for section .fini ---> bfd_elf_final_link: count relocations for section .rodata ---> bfd_elf_final_link: count relocations for section .eh_frame ---> bfd_elf_final_link: count relocations for section .ctors ---> bfd_elf_final_link: count relocations for section .dtors ---> bfd_elf_final_link: count relocations for section .jcr ---> bfd_elf_final_link: count relocations for section .got ---> bfd_elf_final_link: count relocations for section .data ---> bfd_elf_final_link: count relocations for section .bss ---> bfd_elf_final_link: count relocations for section .comment ---> bfd_elf_final_link: set size, file position for section .init ---> bfd_elf_final_link: set size, file position for section .text ---> bfd_elf_final_link: set size, file position for section .fini ---> bfd_elf_final_link: set size, file position for section .rodata ---> bfd_elf_final_link: set size, file position for section .eh_frame ---> bfd_elf_final_link: set size, file position for section .ctors ---> bfd_elf_final_link: set size, file position for section .dtors ---> bfd_elf_final_link: set size, file position for section .jcr ---> bfd_elf_final_link: set size, file position for section .got ---> bfd_elf_final_l
[Bug target/53833] m68k-uclinux xgcc ICE when compiling libgcc (linux-atomic.c:203:1: in emit_library_call_value_1, at calls.c:4146)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53833 --- Comment #3 from Larry Baker 2012-09-18 21:45:23 UTC --- Created attachment 28217 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28217 Hacked binutils 1.22 bfd/elflink.c I added a bunch of debugging output to bfd/elflink.c to find out where the link failure occurs.
[Bug rtl-optimization/54524] [4.6/4.7/4.8 Regression] Spurious add on sum of bitshifts (forward-propagate issue)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54524 --- Comment #3 from Jan Smets 2012-09-18 21:49:21 UTC --- This commit introduced the bug: http://gcc.gnu.org/viewcvs?view=revision&revision=161655 (or 182cf5a9a415f31df0f9a10e46faed1221484a35 in git)
[Bug target/53833] m68k-uclinux xgcc ICE when compiling libgcc (linux-atomic.c:203:1: in emit_library_call_value_1, at calls.c:4146)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53833 --- Comment #4 from Larry Baker 2012-09-18 21:51:36 UTC --- (In reply to comment #3) > Created attachment 28217 [details] > Hacked binutils 1.22 bfd/elflink.c > > I added a bunch of debugging output to bfd/elflink.c to find out where the > link > failure occurs. This doesn't belong here -- it is for Bug no. 54584. Will the moderator please remove it? Sorry.
[Bug target/54584] m68k-uclinux error: Link tests are not allowed after GCC_NO_EXECUTABLES
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54584 --- Comment #4 from Larry Baker 2012-09-18 21:53:03 UTC --- Created attachment 28218 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28218 Hacked binutils 1.22 bfd/elflink.c I added a bunch of debugging output to bfd/elflink.c to find out where the link failure occurs.
[Bug middle-end/54617] [4.8 Regression] ICE on gcc.c-torture/compile/pr42025-2.c with -m64 and -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54617 --- Comment #3 from Eric Botcazou 2012-09-18 22:42:22 UTC --- Author: ebotcazou Date: Tue Sep 18 22:42:18 2012 New Revision: 191451 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191451 Log: PR middle-end/54617 * expr.c (store_field): Handle a PARALLEL in more cases. Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c
[Bug middle-end/54617] [4.8 Regression] ICE on gcc.c-torture/compile/pr42025-2.c with -m64 and -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54617 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-09/msg01312.htm ||l Resolution||FIXED --- Comment #4 from Eric Botcazou 2012-09-18 22:44:43 UTC --- This should compile again now.
[Bug target/54584] m68k-uclinux error: Link tests are not allowed after GCC_NO_EXECUTABLES
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54584
--- Comment #5 from Hans-Peter Nilsson 2012-09-18
23:30:23 UTC ---
This seems to be just a problem with flawed elf2flt linker placement of
orphaned sections. But, I can't find where -elf2flt is handled in FSF
binutils; you need to talk to whomever is in charge of the local uclinux linker
patches.
For a linker fix, either add a "${RELOCATING+*(.tm_clone_table)}" in the .text
or .data output section of the default linker script or improve the elf2flt
orphaned section placement, similar to what I did in
as a partial fix for
PR54373. (It fixes the main problem, but I found others.) Generic ELF already
has good enough orphaned-section placement that no real ELF target has any
problem with .tm_clone_table actually being an orphaned section for all
targets.
Of course, an alternative is to cover up by disabling transactional memory,
likely the most pragmatic solution; I'm guessing TM is of little interest to
uclinux targets. :)
[Bug target/54584] m68k-uclinux error: Link tests are not allowed after GCC_NO_EXECUTABLES
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54584 --- Comment #6 from Larry Baker 2012-09-19 00:05:38 UTC --- Hans-Peter, Thanks for looking at this. This seems a bit more complicated than "just a problem with flawed elf2flt linker placement of orphaned sections" since elf2flt/ld.real work fine when creating flat binaries for cases other than -msep-data/-fPIC. That implies that they must be handling the orphaned .tm_clone_table section for those cases (a bunch of different -mcpu's). I don't know where to look to find out how -msep-data/-fPIC are handled differently, and thus, why those fail. FYI: For the latest tests I ran, I used a vanilla binutils 1.22 distribution -- no uClinux linker patches. I also used the latest elf2flt from www.uclinux.org. I also cannot find where -elf2flt is recognized/handled by collect2. I have no idea what collect2 does. I tracked down the location of the error to ld.real, which is the binutils ld, renamed to ld.real by the elf2flt package "make install". When I read about TM support, it sounded like it might be preferable to pthreads. If that is so, then I expect uClinux would be a good candidate for TM. I will take a look at your fix. The details of how to write ld scripts and such are beyond my current understanding of the process. I learn what I have to when I encounter a problem. I was hoping someone that knows what to look for would see what I have provided and instantly figure out what the problem is. :) Larry Baker
[Bug target/54584] m68k-uclinux error: Link tests are not allowed after GCC_NO_EXECUTABLES
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54584 --- Comment #7 from Larry Baker 2012-09-19 00:15:22 UTC --- (In reply to comment #6) > FYI: For the latest tests I ran, I used a vanilla binutils 1.22 distribution > -- > no uClinux linker patches. I also used the latest elf2flt from > www.uclinux.org. binutils 1.22 is a typo -- I meant to say binutils 2.22.
[Bug testsuite/54622] New: gcc.dg/vect test failures for arm big-endian
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54622 Bug #: 54622 Summary: gcc.dg/vect test failures for arm big-endian Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org CC: i...@gcc.gnu.org Target: arm Created attachment 28219 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28219 list of vect test failures for arm big-endian 71 vectorization tests (plus corresponding checks with -flto) pass for ARM little endian but fail for ARM big endian with current mainline. I'll attach the list. Some of them are scans that are gated on effective targets that always fail for ARM big endian; perhaps that's a coincidence, or perhaps some of these effective-target checks should require arm_little_endian: vect64 (2) vect-widen_shift (8) vect_perm_byte (1) vect_perm_short (1) vect_strided3 (1) Testing for ARM big-endian is straightforward for any ARM build. Avoid execution tests with a local patch to gcc/testsuite/gcc.dg/vect/vect.exp to add 'set dg-do-what-default "compile"' after calling check_vect_support_and_set_flags, and then pass the appropriate flags in RUNTESTFLAGS.
[Bug target/28896] -fstack-limit-symbol and m68k and non 68020
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28896 --- Comment #33 from Larry Baker 2012-09-19 01:02:31 UTC --- Created attachment 28220 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28220 Patches for GCC 4.7.1 Patches to fix stack limit checking for GCC 4.7.1 for FreeScale Coldfire uClinux. Also includes patches to disable atomics (internal compiler error) for ColdFire processors (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53833) and to disable Transactional Memory (linker failure) for uClinux (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54584). These two features were introduced in GCC 4.7.
[Bug testsuite/54622] gcc.dg/vect test failures for arm big-endian
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54622 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org --- Comment #1 from Andrew Pinski 2012-09-19 01:08:58 UTC --- I think all the tests that pass for little-endian should also pass for big-endian. The only difference comes down to how the memory is located from memory as IIRC neon stays the same in memory.
[Bug testsuite/54622] gcc.dg/vect test failures for arm big-endian
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54622 --- Comment #2 from Janis Johnson 2012-09-19 01:16:58 UTC --- Effective targets vect_unpack and vect_pack_trunc both require little endian for ARM, which is why I thought that perhaps some of the others do as well.
[Bug testsuite/54622] gcc.dg/vect test failures for arm big-endian
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54622 --- Comment #3 from Andrew Pinski 2012-09-19 01:29:09 UTC --- (In reply to comment #2) > Effective targets vect_unpack and vect_pack_trunc both require little endian > for ARM, which is why I thought that perhaps some of the others do as well. Yes but I think it is wrong to do that in the back-end.
[Bug rtl-optimization/54524] [4.6/4.7/4.8 Regression] Spurious add on sum of bitshifts (forward-propagate issue)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54524
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-09-19
Ever Confirmed|0 |1
Severity|major |normal
--- Comment #4 from Andrew Pinski 2012-09-19
01:39:38 UTC ---
As far as I can tell, Richard's patch just exposed a latent bug as I was
looking into the dumps.
In insn 28, replacing
(ltu:SI (reg:SI 231 [+4 ])
(reg:SI 229 [+4 ]))
with (const_int 1 [0x1])
Changed insn 28
deferring rescan insn with uid = 28.
after cse:
(insn 27 43 28 2 (set (reg:SI 231 [+4 ])
(plus:SI (reg:SI 229 [+4 ])
(const_int 0 [0]))) t.c:24 10 {*addsi3}
(nil))
(insn 28 27 29 2 (set (reg:SI 212)
(ltu:SI (reg:SI 231 [+4 ])
(reg:SI 229 [+4 ]))) t.c:24 521 {*sltu_sisi}
(nil))
So this is a bug in CSE which is not simplifying that addsi3 into just a move
for some reason.
[Bug bootstrap/54623] New: [4.8 regression] install fails with libbacktrace/backtrace.c:35:20: error: unwind.h: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54623 Bug #: 54623 Summary: [4.8 regression] install fails with libbacktrace/backtrace.c:35:20: error: unwind.h: No such file or directory Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: ger...@pfeifer.com Bootstrapping current trunk on i386-unknown-freebsd10.0 this fails as follows: libtool: compile: gcc -DHAVE_CONFIG_H -I. -I/scratch2/tmp/gerald/gcc-HEAD/libba cktrace -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold- style-definition -Wmissing-format-attribute -Wcast-qual -Werror -I /scratch2/tmp /gerald/gcc-HEAD/libbacktrace/../include -I ../libgcc -g -O2 -MT backtrace.lo -M D -MP -MF .deps/backtrace.Tpo -c /scratch2/tmp/gerald/gcc-HEAD/libbacktrace/back trace.c -o backtrace.o /scratch2/tmp/gerald/gcc-HEAD/libbacktrace/backtrace.c:35:20: error: unwind.h: N o such file or directory /scratch2/tmp/gerald/gcc-HEAD/libbacktrace/backtrace.c:62: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'unwind' cc1: warnings being treated as errors /scratch2/tmp/gerald/gcc-HEAD/libbacktrace/backtrace.c: In function 'backtrace_f ull': /scratch2/tmp/gerald/gcc-HEAD/libbacktrace/backtrace.c:106: warning: implicit de claration of function '_Unwind_Backtrace' /scratch2/tmp/gerald/gcc-HEAD/libbacktrace/backtrace.c:106: error: 'unwind' unde clared (first use in this function) /scratch2/tmp/gerald/gcc-HEAD/libbacktrace/backtrace.c:106: error: (Each undecla red identifier is reported only once /scratch2/tmp/gerald/gcc-HEAD/libbacktrace/backtrace.c:106: error: for each func tion it appears in.) gmake[2]: *** [backtrace.lo] Error 1 gmake[2]: Leaving directory `/scratch2/tmp/gerald/OBJ-0918-2043/libbacktrace' gmake[1]: *** [install-libbacktrace] Error 2 gmake[1]: Leaving directory `/scratch2/tmp/gerald/OBJ-0918-2043' gmake: *** [install] Error 2
[Bug bootstrap/25470] [4.6/4.7/4.8 Regression] fixincludes/ subdirectory not cleaned by "make distclean"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25470 b.grayson at samsung dot com changed: What|Removed |Added CC||b.grayson at samsung dot ||com --- Comment #16 from b.grayson at samsung dot com 2012-09-19 04:28:30 UTC --- (In reply to comment #15) > 4.4 branch is being closed, moving to 4.5.4 target. Just wanted to point out that this is still an issue in gcc-4.7.1. Is this any harder than just adding config.cache to the rm -f line under the distclean target? This is the only not-quite-clean issue I'm currently running into when I re-configure gcc a few different ways.
[Bug bootstrap/54623] [4.8 regression] install fails with libbacktrace/backtrace.c:35:20: error: unwind.h: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54623 --- Comment #1 from ian at gcc dot gnu.org 2012-09-19 04:37:47 UTC --- Author: ian Date: Wed Sep 19 04:37:40 2012 New Revision: 191459 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191459 Log: PR bootstrap/54623 * Makefile.am (AM_CPPFLAGS): Define. (AM_CFLAGS): Remove -I options. * Makefile.in: Rebuild. Modified: trunk/libbacktrace/ChangeLog trunk/libbacktrace/Makefile.am trunk/libbacktrace/Makefile.in
[Bug bootstrap/54623] [4.8 regression] install fails with libbacktrace/backtrace.c:35:20: error: unwind.h: No such file or directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54623 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ian at airs dot com Resolution||FIXED --- Comment #2 from Ian Lance Taylor 2012-09-19 04:39:57 UTC --- I don't understand why "make install" is building anything in libbacktrace at all. It suggests that the "make" did not complete. Either way, though, I don't understand why the "make" would succeed and the "make install" would fail. They should be using the same compiler with the same arguments. Note that libbacktrace does not install anything. In any case, I just committed a patch which may fix this problem. Please reopen with more details if it is not fixed.
