[Bug bootstrap/54283] [4.8 regression] build tools don't run after cxx-conversion merge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54283 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2012-11-16 09:11:36 UTC --- --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-16 01:06:20 UTC --- Does this still happen? It does. I've a local patch in my tree to allow bootstrapping at all. Unfortunately, the patch certainly isn't right, but I still can't fully wrap my head around the full consequences build/host/target distinction. Btw., I've got the same problem on i686-linux with a self-built gcc 4.4 as bootstrap compiler, so there's nothing Solaris-specific here. Rainer
[Bug rtl-optimization/55330] [4.8 Regression] ICE: Maximum number of LRA constraint passes is achieved (15) on gfortran.dg/actual_array_constructor_1.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55330 David Binderman dcb314 at hotmail dot com changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #2 from David Binderman dcb314 at hotmail dot com 2012-11-16 09:13:53 UTC --- (In reply to comment #1) I don't see it on x86_64-apple-darwin10 (revisions 193495+patches and 193329). Looks like a duplicate of 55122.
[Bug c/55350] New: verify_gimple failed with invalid (pointer) operands to plus/minus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55350 Bug #: 55350 Summary: verify_gimple failed with invalid (pointer) operands to plus/minus Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: dcb...@hotmail.com Created attachment 28706 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28706 C source code I just tried to compile the package gcl-2.6.8-0.11.20120705cvs on gcc-4.8 trunk dated 2012 on an AMD x86_64 box. The compiler said bug91.c: In function ‘intern’: bug91.c:11585:1: error: invalid (pointer) operands to plus/minus intern(st, p) ^ _856 = _847 + 8B; bug91.c:11585:1: error: invalid (pointer) operands to plus/minus _865 = _856 + 8B; bug91.c:11585:1: error: invalid (pointer) operands to plus/minus _874 = _865 + 8B; bug91.c:11585:1: error: invalid (pointer) operands to plus/minus _143 = _874 + 8B; bug91.c:11585:1: internal compiler error: verify_gimple failed 0x90ed8b verify_gimple_in_cfg(function*) ../../src/trunk/gcc/tree-cfg.c:4728 0x84de57 execute_function_todo ../../src/trunk/gcc/passes.c:1975 0x84e897 execute_todo ../../src/trunk/gcc/passes.c:2008 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. Preprocessed source code attached. Flag -O3 required.
[Bug target/52855] ARM: Internal compiler error: in extract_insn, at recog.c:2109
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52855
Steinar Midtskogen stemidts at cisco dot com changed:
What|Removed |Added
CC||stemidts at cisco dot com
--- Comment #4 from Steinar Midtskogen stemidts at cisco dot com 2012-11-16
09:48:36 UTC ---
I've run into the same bug. The code below reproduces it:
#include arm_neon.h
static const __attribute__((aligned(16)))
int16_t c[][2][8] =
{
{ { 0 }, { 0 } }, { { 0 }, { 0 } }, { { 0 }, { 0 } }, { { 0 }, { 0 } },
{ { 0 }, { 0 } }, { { 0 }, { 0 } }, { { 0 }, { 0 } }, { { 0 }, { 0 } }
};
int16x8_t test2(int off)
{
return vld1q_u8((uint8_t*)c[off][0]);
}
int16x8_t test(int off, uint8_t **c)
{
static int8_t m[] = { 1, 2, 3 };
long long cf = m[off];
return vld1q_u8((uint8_t*)c[cf]);
}
Version: 4.6.3
Options: -mapcs-frame -mfloat-abi=softfp -mfpu=neon -flax-vector-conversions
-O1
Changing long long cf into int cf eliminates the crash.
[Bug tree-optimization/55260] [4.8 Regression] ICE: in ipa_get_parm_lattices, at ipa-cp.c:263 with -O2 -fno-inline -fipa-cp-clone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55260
Markus Trippelsdorf markus at trippelsdorf dot de changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org,
||markus at trippelsdorf dot
||de
--- Comment #2 from Markus Trippelsdorf markus at trippelsdorf dot de
2012-11-16 10:04:56 UTC ---
This ICE also hits in the boost testsuite:
markus@x4 more % cat test.ii
struct B
{
virtual void test_suite_finish ();
};
void
fn1 (B p2)
{
fn1 (p2);
B a = p2;
a.test_suite_finish ();
B b;
fn1 (b);
}
markus@x4 more % c++ -O3 -c test.ii
test.ii:13:1: internal compiler error: in ipa_get_parm_lattices, at
ipa-cp.c:263
}
^
0xeb2b52 ipa_get_parm_lattices
/home/markus/gcc/gcc/ipa-cp.c:263
0xeb059a ipa_get_parm_lattices
/home/markus/gcc/gcc/ipa-cp.c:2930
0xeb059a cgraph_edge_brings_all_agg_vals_for_node
/home/markus/gcc/gcc/ipa-cp.c:3105
0xeb059a perhaps_add_new_callers
/home/markus/gcc/gcc/ipa-cp.c:3157
0xeb059a decide_about_value
/home/markus/gcc/gcc/ipa-cp.c:3230
0xeb2693 decide_whether_version_node
/home/markus/gcc/gcc/ipa-cp.c:3324
0xeb2693 ipcp_decision_stage
/home/markus/gcc/gcc/ipa-cp.c:3464
0xeb2693 ipcp_driver
/home/markus/gcc/gcc/ipa-cp.c:3506
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug fortran/55341] address-sanitizer and Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #2 from janus at gcc dot gnu.org 2012-11-16 10:27:43 UTC --- (In reply to comment #1) Trying -faddress-sanitizer on CP2K leads to the following failure: Slightly reduced test case: MODULE m TYPE t INTEGER, DIMENSION(:), ALLOCATABLE :: orders END TYPE CONTAINS SUBROUTINE s TYPE(t) :: x, y x = y END SUBROUTINE END MODULE m
[Bug tree-optimization/54717] [4.8 Regression] Runtime regression: polyhedron test rnflow degraded
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54717 --- Comment #18 from Jan Hubicka hubicka at gcc dot gnu.org 2012-11-16 10:37:30 UTC --- Author: hubicka Date: Fri Nov 16 10:37:25 2012 New Revision: 193553 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193553 Log: PR tree-optimization/54717 * tree-ssa-pre.c (do_partial_partial_insertion): Consider also edges with ANTIC_IN. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-pre.c
[Bug tree-optimization/55334] mgrid regression (ipa-cp disables vectorization)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||matz at suse dot de --- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org 2012-11-16 10:39:34 UTC --- Hmm, this does not help. The problem is indeed that we are not able to figure out that the accesses into subarrays of X are mutually independent. Martin, Michael, I think you are more familiar with MEM_REF, can you take a look?
[Bug fortran/55341] address-sanitizer and Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-16 10:54:25 UTC --- Looks like a FE bug to me.
[Bug fortran/55341] address-sanitizer and Fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55341 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-11-16 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-16 10:55:53 UTC --- Created attachment 28707 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28707 gcc48-pr55341.patch Untested fix. memcpy's last argument is size_type_node, i.e. unsigned C size_t, while in several places the FE was calling memcpy with a signed type of the argument instead.
[Bug tree-optimization/55334] mgrid regression (ipa-cp disables vectorization)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334
--- Comment #5 from vincenzo Innocente vincenzo.innocente at cern dot ch
2012-11-16 10:56:11 UTC ---
is the problem similar to what described in PR55213?
or here
float mem[3*1024];
void sum() {
float * a=mem;
const float * b=mem+1024;
const float * c=mem+2*1024;
for (int i=0;i!=1024;++i)
a[i]=b[i]+c[i];
}
6: create runtime check for data references *_7 and *_6
6: create runtime check for data references *_9 and *_6
6: created 2 versioning for alias checks.
[Bug tree-optimization/55350] [4.8 Regression] verify_gimple failed with invalid (pointer) operands to plus/minus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55350
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-11-16
Component|c |tree-optimization
CC||jakub at gcc dot gnu.org,
||wschmidt at gcc dot gnu.org
Ever Confirmed|0 |1
Summary|verify_gimple failed with |[4.8 Regression]
|invalid (pointer) operands |verify_gimple failed with
|to plus/minus |invalid (pointer) operands
||to plus/minus
Target Milestone|--- |4.8.0
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-16
11:36:49 UTC ---
Reduced testcase for -O3:
void
foo (__INTPTR_TYPE__ x, __INTPTR_TYPE__ y)
{
int i;
void **a = (void *) (__INTPTR_TYPE__) (8UL * (x / 8UL));
for (i = 0; i x; i++)
a[i] = (void *) y;
}
Seems to be slsr bug.
[Bug tree-optimization/54073] [4.7/4.8 Regression] SciMark Monte Carlo test performance has seriously decreased in recent GCC releases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54073 --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-16 11:40:42 UTC --- Author: jakub Date: Fri Nov 16 11:40:39 2012 New Revision: 193554 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193554 Log: PR target/54073 * config/i386/i386.md (movmodecc): Use comparison_operator instead of ordered_comparison_operator resp. ix86_fp_comparison_operator predicates. * config/i386/i386.c (ix86_expand_fp_movcc): Reject TImode or for -m32 DImode comparisons. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.md
[Bug fortran/55297] [4.8 Regression] type-bound operator clashes with abstract interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55297
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org
|gnu.org |
--- Comment #3 from janus at gcc dot gnu.org 2012-11-16 11:41:50 UTC ---
(In reply to comment #2)
The question is whether it should be fixed by adding
if (derived-ns != gfc_current_ns)
return;
Yes, something along this line seems like the appropriate fix to me. In
particular I would propose the following (which does fix the test case):
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c(revision 193552)
+++ gcc/fortran/resolve.c(working copy)
@@ -11540,7 +11540,7 @@ resolve_typebound_intrinsic_op (gfc_symbol* derive
/* Add target to non-typebound operator list. */
if (!target-specific-deferred !derived-attr.use_assoc
- p-access != ACCESS_PRIVATE)
+ p-access != ACCESS_PRIVATE derived-ns == gfc_current_ns)
{
gfc_interface *head, *intr;
if (gfc_check_new_interface (derived-ns-op[op], target_proc,
Will commit as obvious after regtesting ...
[Bug target/55351] New: can't build libgcc for -m5-compact variant in SH64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55351 Bug #: 55351 Summary: can't build libgcc for -m5-compact variant in SH64 Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: d...@danny.cz Created attachment 28708 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28708 preprocessed lib1funcs.S file when building libgcc for the -m5-compact multilib variant in sh64-linux compiler I get the following error: /builddir/build/BUILD/gcc-4.7.2-20121114-aarch64/sh64-linux-gnu/./gcc/xgcc -B/builddir/build/BUILD/gcc-4.7.2-20121114-aarch64/sh64-linux-gnu/./gcc/ -B/usr/sh64-linux/bin/ -B/usr/sh64-linux/lib/ -isystem /usr/sh64-linux/include -isystem /usr/sh64-linux/sys-include -m5-compact -g -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fpic -mieee -mieee -DNO_FPSCR_VALUES -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -fpic -mieee -mieee -DNO_FPSCR_VALUES -I. -I. -I../../.././gcc -I../../../../gcc-4.7.2-20121114-aarch64/libgcc -I../../../../gcc-4.7.2-20121114-aarch64/libgcc/. -I../../../../gcc-4.7.2-20121114-aarch64/libgcc/../gcc -I../../../../gcc-4.7.2-20121114-aarch64/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o _div_table.o -MT _div_table.o -MD -MP -MF _div_table.dep -DL_div_table -xassembler-with-cpp -c ../../../../gcc-4.7.2-20121114-aarch64/libgcc/config/sh/lib1funcs.S ../../../../gcc-4.7.2-20121114-aarch64/libgcc/config/sh/lib1funcs.S: Assembler messages: ../../../../gcc-4.7.2-20121114-aarch64/libgcc/config/sh/lib1funcs.S:3054: Error: unknown opcode ../../../../gcc-4.7.2-20121114-aarch64/libgcc/config/sh/lib1funcs.S:3056: Error: unknown opcode ../../../../gcc-4.7.2-20121114-aarch64/libgcc/config/sh/lib1funcs.S:3057: Error: unknown opcode ../../../../gcc-4.7.2-20121114-aarch64/libgcc/config/sh/lib1funcs.S:3058: Error: unknown opcode ../../../../gcc-4.7.2-20121114-aarch64/libgcc/config/sh/lib1funcs.S:3060: Error: unknown opcode ../../../../gcc-4.7.2-20121114-aarch64/libgcc/config/sh/lib1funcs.S:3061: Error: unknown opcode ../../../../gcc-4.7.2-20121114-aarch64/libgcc/config/sh/lib1funcs.S:3062: Error: unknown opcode ../../../../gcc-4.7.2-20121114-aarch64/libgcc/config/sh/lib1funcs.S:3063: Error: unknown opcode ../../../../gcc-4.7.2-20121114-aarch64/libgcc/config/sh/lib1funcs.S:3064: Error: unknown opcode ../../../../gcc-4.7.2-20121114-aarch64/libgcc/config/sh/lib1funcs.S:3065: Error: unknown opcode ../../../../gcc-4.7.2-20121114-aarch64/libgcc/config/sh/lib1funcs.S:3066: Error: unknown opcode ../../../../gcc-4.7.2-20121114-aarch64/libgcc/config/sh/lib1funcs.S:3067: Error: unknown opcode ../../../../gcc-4.7.2-20121114-aarch64/libgcc/config/sh/lib1funcs.S:3068: Error: invalid operands for opcode ../../../../gcc-4.7.2-20121114-aarch64/libgcc/config/sh/lib1funcs.S:3069: Error: unknown opcode ../../../../gcc-4.7.2-20121114-aarch64/libgcc/config/sh/lib1funcs.S:3070: Error: invalid operands for opcode ../../../../gcc-4.7.2-20121114-aarch64/libgcc/config/sh/lib1funcs.S:3071: Error: unknown opcode ../../../../gcc-4.7.2-20121114-aarch64/libgcc/config/sh/lib1funcs.S:3072: Error: unknown opcode ../../../../gcc-4.7.2-20121114-aarch64/libgcc/config/sh/lib1funcs.S:3073: Error: unknown opcode ../../../../gcc-4.7.2-20121114-aarch64/libgcc/config/sh/lib1funcs.S:3075: Error: invalid operands for opcode ../../../../gcc-4.7.2-20121114-aarch64/libgcc/config/sh/lib1funcs.S:3076: Error: unknown opcode ../../../../gcc-4.7.2-20121114-aarch64/libgcc/config/sh/lib1funcs.S:3077: Error: unknown opcode ../../../../gcc-4.7.2-20121114-aarch64/libgcc/config/sh/lib1funcs.S:3078: Error: unknown opcode ../../../../gcc-4.7.2-20121114-aarch64/libgcc/config/sh/lib1funcs.S:3080: Error: unknown opcode ../../../../gcc-4.7.2-20121114-aarch64/libgcc/config/sh/lib1funcs.S:3081: Error: unknown opcode ../../../../gcc-4.7.2-20121114-aarch64/libgcc/config/sh/lib1funcs.S:3082: Error: unknown opcode ../../../../gcc-4.7.2-20121114-aarch64/libgcc/config/sh/lib1funcs.S:3083: Error: unknown opcode ../../../../gcc-4.7.2-20121114-aarch64/libgcc/config/sh/lib1funcs.S:3084: Error: unknown opcode ../../../../gcc-4.7.2-20121114-aarch64/libgcc/config/sh/lib1funcs.S:3085: Error: unknown opcode ../../../../gcc-4.7.2-20121114-aarch64/libgcc/config/sh/lib1funcs.S:3086: Error: invalid operands for opcode ../../../../gcc-4.7.2-20121114-aarch64/libgcc/config/sh/lib1funcs.S:3087: Error: invalid operands for opcode ../../../../gcc-4.7.2-20121114-aarch64/libgcc/config/sh/lib1funcs.S:3088: Error: invalid operands for opcode
[Bug other/55333] libsanitizer StackTrace::FastUnwindStack wrong x32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55333 --- Comment #2 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2012-11-16 12:02:33 UTC --- Author: hjl Date: Fri Nov 16 12:02:29 2012 New Revision: 193557 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193557 Log: Define/use hardware pointer type for stack unwind PR other/55333 * include/sanitizer/common_interface_defs.h (uhwptr): New type for hardware pointer. * sanitizer_common/sanitizer_stacktrace.cc (StackTrace::FastUnwindStack): Replace uptr with uhwptr for stack unwind. Modified: trunk/libsanitizer/ChangeLog trunk/libsanitizer/include/sanitizer/common_interface_defs.h trunk/libsanitizer/sanitizer_common/sanitizer_stacktrace.cc
[Bug other/55333] libsanitizer StackTrace::FastUnwindStack wrong x32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55333 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.8.0 --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2012-11-16 12:03:16 UTC --- Fixed.
[Bug fortran/41951] [OOP] Not diagnosing ambiguous operators (TB vs. INTERFACE)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41951
--- Comment #16 from janus at gcc dot gnu.org 2012-11-16 12:04:13 UTC ---
(In reply to comment #15)
(In reply to comment #14)
Comment 12 is fixed with r189022, but comment 11 is still accepted without
error.
One way to reject the abstract case in comment 11, would be to just do the
checking, but not add the procedure to the operator list:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c(revision 193552)
+++ gcc/fortran/resolve.c(working copy)
@@ -11539,19 +11539,21 @@ resolve_typebound_intrinsic_op (gfc_symbol* derive
goto error;
/* Add target to non-typebound operator list. */
- if (!target-specific-deferred !derived-attr.use_assoc
- p-access != ACCESS_PRIVATE)
+ if (!derived-attr.use_assoc p-access != ACCESS_PRIVATE)
{
- gfc_interface *head, *intr;
if (gfc_check_new_interface (derived-ns-op[op], target_proc,
p-where) == FAILURE)
return FAILURE;
- head = derived-ns-op[op];
- intr = gfc_get_interface ();
- intr-sym = target_proc;
- intr-where = p-where;
- intr-next = head;
- derived-ns-op[op] = intr;
+ if (!target-specific-deferred)
+{
+ gfc_interface *head, *intr;
+ head = derived-ns-op[op];
+ intr = gfc_get_interface ();
+ intr-sym = target_proc;
+ intr-where = p-where;
+ intr-next = head;
+ derived-ns-op[op] = intr;
+}
}
}
[Bug tree-optimization/55334] mgrid regression (ipa-cp disables vectorization)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-16
12:05:44 UTC ---
Restrict is one thing, not figuring out that disjoint accesses to the same
array don't overlap is another (i.e. the #c5 testcase). Cast restrict is hard
to do reliably, as the referenced PR documents, while figuring out that say
Creating dr for *_7
analyze_innermost: success.
base_address: mem
offset from base address: 0
constant offset from base address: 4096
step: 4
aligned to: 128
base_object: *(const float *) mem
Access function 0: {4096B, +, 4}_1
and
Creating dr for *_6
analyze_innermost: success.
base_address: mem
offset from base address: 0
constant offset from base address: 0
step: 4
aligned to: 128
base_object: MEM[(float *)mem]
Access function 0: {0B, +, 4}_1
for 1024 iterations would be really nice.
[Bug fortran/41951] [OOP] Not diagnosing ambiguous operators (TB vs. INTERFACE)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41951 --- Comment #17 from janus at gcc dot gnu.org 2012-11-16 12:33:00 UTC --- (In reply to comment #16) One way to reject the abstract case in comment 11, would be to just do the checking, but not add the procedure to the operator list: The only problem with the patch in comment 16 is that the error message it gives on comment 11 ... generic :: assignment(=) = assign 1 Error: Entity 'assign_it' at (1) is already present in the interface ... is technically not correct. 'assign_it' is not added twice, but in one case is just the interface of the deferred type-boud procedure 'assign'. Instead, it might be better to complain about 'Ambiguous interfaces' (since any non-abstract extension of the type 'sort_t' will have to override/implement the type-bound 'assign' with a procedure which is ambiguous to 'assign_it'). However, such an error about 'Ambiguous interfaces' is also missing for the following case (which is still accepted): module m_sort implicit none type, abstract :: sort_t contains generic :: assignment(=) = assign procedure(assign_ifc), deferred :: assign end type abstract interface subroutine assign_ifc (lhs, rhs) import class(sort_t), intent(out) :: lhs class(sort_t), intent(in) :: rhs end subroutine end interface interface assignment(=) subroutine assign_it (lhs, rhs) import class(sort_t), intent(out) :: lhs class(sort_t), intent(in) :: rhs end subroutine end interface end module
[Bug c++/54875] Forward declare enums cannot be used as a template argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54875 --- Comment #3 from dodji at seketeli dot org dodji at seketeli dot org 2012-11-16 12:57:37 UTC --- I candidate patchlet has been submitted for this at http://gcc.gnu.org/ml/gcc-patches/2012-11/msg01375.html.
[Bug tree-optimization/55334] mgrid regression (ipa-cp disables vectorization)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334 --- Comment #7 from Jan Hubicka hubicka at gcc dot gnu.org 2012-11-16 13:19:51 UTC --- The C testcase is simiar - in the mgrid case we are probably able to derrive useful loop bounds now and the dependency analysis could use them (but doesn't). I will try to look into that (though I am not really familiar with dependency code). In the mgrid case those are however two different subarrays of one aggregate. They can not overlap regardless the indexes, but we throw athat info away.
[Bug tree-optimization/54497] [4.8 Regression] Revision 190015 causes 22% degradation on 172.mgrid on PowerPC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54497 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #6 from Jan Hubicka hubicka at gcc dot gnu.org 2012-11-16 13:21:38 UTC --- It is indeed problem with dependnecy analysis as discussed in PR55334. I am marking this one as a dup because the other one has some more analysis in it. *** This bug has been marked as a duplicate of bug 55334 ***
[Bug tree-optimization/55334] mgrid regression (ipa-cp disables vectorization)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||pthaugen at gcc dot gnu.org --- Comment #8 from Jan Hubicka hubicka at gcc dot gnu.org 2012-11-16 13:21:38 UTC --- *** Bug 54497 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/55334] mgrid regression (ipa-cp disables vectorization)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334
--- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-16
13:29:05 UTC ---
Ah, on the #c5 testcase the problem seems to be const float * vs. float *,
/* If the references do not access the same object, we do not know
whether they alias or not. */
if (!operand_equal_p (DR_BASE_OBJECT (a), DR_BASE_OBJECT (b), 0))
{
DDR_ARE_DEPENDENT (res) = chrec_dont_know;
return res;
}
operand_equal_p here fails because, while both base objects are MEM_REFs and
operand_equal_p (TREE_OPERAND (DR_BASE_OBJECT (a), 0), TREE_OPERAND
(DR_BASE_OBJECT (b), 0), 0) is true, the second operand of one MEM_REF is
const float *, while on the other MEM_REF it is float *, and operand_equal_p
for that tests:
...
2570 (TYPE_MAIN_VARIANT (TREE_TYPE (TREE_OPERAND (arg0, 1)))
2571 == TYPE_MAIN_VARIANT (TREE_TYPE (TREE_OPERAND (arg1, 1
2572 OP_SAME (0) OP_SAME (1));
and the TYPE_MAIN_VARIANT check fails. In this case I believe we don't care
whether it points to const float or float. Not sure if we should change
operand_equal_p to try harder if TYPE_MAIN_VARIANT of the two types isn't
equal,
but TYPE_MAIN_VARIANT (TREE_TYPE (TREE_TYPE (TREE_OPERAND (argX, 1
is equal, and both pointers have the same deref alias set, or perhaps just
change the above spot to try harder on MEM_REFs if it failed.
[Bug fortran/55352] New: Erroneous gfortran warning of unused module variable when variable is only used in namelist
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55352 Bug #: 55352 Summary: Erroneous gfortran warning of unused module variable when variable is only used in namelist Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: astrofl...@gmail.com Created attachment 28709 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28709 Minimal example source code gfortran-4.7.2 -Wall gives a warning about unused module variables when those variables are only used in a namelist. Test: compile the attached minimal example source file test.f90 with: gfortran -v -Wall -Werror test.f90 -o test The following warning is printed: test.f90:14.6: use data, only: a 1 Warning: Unused module variable 'a' which has been explicitly imported at (1) The warning goes away when print*,a is uncommented in line 20. Verbose output is in the attached file compile_output.txt Get: warning about unused module variable Expect: no warning Reproduceable: always gfortran version: gcc version 4.7.2 (Gentoo 4.7.2 p1.3, pie-0.5.5)
[Bug fortran/55352] Erroneous gfortran warning of unused module variable when variable is only used in namelist
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55352 --- Comment #1 from AstroFloyd AstroFloyd at gmail dot com 2012-11-16 13:43:25 UTC --- Created attachment 28710 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28710 Verbose output from compilation of example source file
[Bug tree-optimization/55334] mgrid regression (ipa-cp disables vectorization)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334 --- Comment #10 from vincenzo Innocente vincenzo.innocente at cern dot ch 2012-11-16 13:46:13 UTC --- actually looking into the generated code I do not see any trace of runtime check even in presence of const c++ -O3 -ftree-vectorizer-verbose=1 -c alias.cc Analyzing loop at alias.cc:6 Vectorizing loop at alias.cc:6 6: create runtime check for data references *_7 and *_6 6: create runtime check for data references *_9 and *_6 6: created 2 versioning for alias checks. 6: LOOP VECTORIZED. alias.cc:2: note: vectorized 1 loops in function. pb-d-128-141-131-26:vectorize innocent$ otool -v -V -t alias.o alias.o: (__TEXT,__text) section __Z3sumv: leaq_mem+0x1000(%rip),%rax 0007leaq_mem+0x2000(%rip),%rdx 000enop 0010movaps(%rax),%xmm0 0013addq$0x10,%rax 0017addps0x0ff0(%rax),%xmm0 001emovaps%xmm0,0xeff0(%rax) 0025cmpq%rdx,%rax 0028jne0x0010 002arepz/ret
[Bug tree-optimization/55334] mgrid regression (ipa-cp disables vectorization)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334 --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-16 13:55:54 UTC --- (In reply to comment #10) actually looking into the generated code I do not see any trace of runtime check even in presence of const The vectorizer creates the versioning for alias, but then vrp2 manages to optimize the runtime check into a constant and thus the non-vectorized loop is optimized away.
[Bug tree-optimization/55334] mgrid regression (ipa-cp disables vectorization)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334
--- Comment #12 from vincenzo Innocente vincenzo.innocente at cern dot ch
2012-11-16 13:58:33 UTC ---
so a better c case is
float * mem;
void sumN(int n) {
float * a=mem;
/*const*/ float * b=mem+n;
/*const*/ float * c=mem+2*n;
for (int i=0;i!=n;++i)
a[i]=b[i]+c[i];
}
[Bug other/55313] libsanitizer cannot be installed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55313 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|NEW Last reconfirmed||2012-11-16 Resolution|DUPLICATE | Ever Confirmed|0 |1 --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-11-16 14:07:55 UTC --- Dup. Apparently not: test -z /red.a/gnatmail/gcc-x/build-red/x86_64-linux/gnat/gnat-bin/lib/../lib64 || /bin/mkdir -p /red.a/gnatmail/gcc-x/build-red/x86_64-linux/gnat/gnat-bin/lib/../lib64 /bin/bash ../libtool --mode=install /usr/bin/install -c libasan.la '/red.a/gnatmail/gcc-x/build-red/x86_64-linux/gnat/gnat-bin/lib/../lib64' libtool: install: error: cannot install `libasan.la' to a directory not ending in /usr/gnat/lib/../lib64 make[4]: *** [install-toolexeclibLTLIBRARIES] Error 1 make[4]: Leaving directory `/red.a/gnatmail/gcc-x/build-red/x86_64-linux/gnat/obj/x86_64-pc-linux-gnu/libsanitizer/asan' make[3]: *** [install-am] Error 2 make[3]: Leaving directory `/red.a/gnatmail/gcc-x/build-red/x86_64-linux/gnat/obj/x86_64-pc-linux-gnu/libsanitizer/asan' make[2]: *** [install-recursive] Error 1 make[2]: Leaving directory `/red.a/gnatmail/gcc-x/build-red/x86_64-linux/gnat/obj/x86_64-pc-linux-gnu/libsanitizer' make[1]: *** [install-target-libsanitizer] Error 2 make[1]: Leaving directory `/red.a/gnatmail/gcc-x/build-red/x86_64-linux/gnat/obj' make: *** [install] Error 2 This is with --disable-multilib as of today.
[Bug c++/55338] Incorrectly reported error in type name hiding
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55338 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-16 14:15:34 UTC --- See: http://gcc.gnu.org/ml/gcc/2012-11/msg00241.html Daniel, do you agree?
[Bug tree-optimization/55334] mgrid regression (ipa-cp disables vectorization)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334
--- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-16
14:17:00 UTC ---
(In reply to comment #12)
so a better c case is
float * mem;
void sumN(int n) {
float * a=mem;
/*const*/ float * b=mem+n;
/*const*/ float * c=mem+2*n;
for (int i=0;i!=n;++i)
a[i]=b[i]+c[i];
}
Without const and with constant n GCC already does the right thing. With
non-constant n it is a different thing, then we have
base_object: *mem + (long unsigned int) n_3(D) * 4
base_object: *mem + (long unsigned int) (n_3(D) * 2) * 4
base_object: MEM[(float *)mem]
and obviously it doesn't operand_equal_p either. Not sure if in that case
we couldn't move (long unsigned int) n_3(D) * 4 resp. (long unsigned int)
(n_3(D) * 2) * 4 from the base object to the access function, so it would be
instead of
Access function 0: {0B, +, 4}_1
say
Access function 0: {n_3(D) * 4, +, 4}_1
and whether rest of data-ref etc. code would handle that properly.
[Bug c++/55337] [4.8 Regression] ICE tree check: expected sizeof_expr, have alignof_expr in cp_tree_equal, at cp/tree.c:2608
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55337 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-16 14:33:48 UTC --- Author: jakub Date: Fri Nov 16 14:33:44 2012 New Revision: 193558 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193558 Log: PR c++/55337 * tree.c (cp_tree_equal) case ALIGNOF_EXPR: Use SIZEOF_EXPR_TYPE_P only on SIZEOF_EXPR. * g++.dg/template/alignof2.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/alignof2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c trunk/gcc/testsuite/ChangeLog
[Bug c++/55337] [4.8 Regression] ICE tree check: expected sizeof_expr, have alignof_expr in cp_tree_equal, at cp/tree.c:2608
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55337 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-16 14:36:14 UTC --- Fixed.
[Bug fortran/48636] Enable more inlining with -O2 and higher
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636 --- Comment #42 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-11-16 14:42:33 UTC --- Fatigue now gets all inlining with -O3 -fwhole-program, with -O3 it gets only half of inlining because jump functions are not able to track array descriptors in both calls to generalized_hookes_law. The same applies to the tests in comments #4 and #10. What is the status of assumed-shape arrays with respect to array_index hint? What are the other testcases to look at? ac.f90 and aermod.f90 give a 5-10% faster runtime when compiled with '--param max-inline-insns-auto=150' (and -Ofast -fwhole-program).
[Bug tree-optimization/55334] [4.8 Regression] mgrid regression (ipa-cp disables vectorization)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0 Summary|mgrid regression (ipa-cp|[4.8 Regression] mgrid |disables vectorization) |regression (ipa-cp disables ||vectorization)
[Bug tree-optimization/54073] [4.7 Regression] SciMark Monte Carlo test performance has seriously decreased in recent GCC releases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54073 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Summary|[4.7/4.8 Regression]|[4.7 Regression] SciMark |SciMark Monte Carlo test|Monte Carlo test |performance has seriously |performance has seriously |decreased in recent GCC |decreased in recent GCC |releases|releases --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-16 14:50:32 UTC --- Hopefully fixed on the trunk, not planning to backport it right now.
[Bug c++/55338] Incorrectly reported error in type name hiding
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55338 --- Comment #2 from Piotr Wyderski piotr.wyderski at gmail dot com 2012-11-16 15:06:45 UTC --- IMO this case is not covered by the linked paragraph, so please wait and let me create a thread on compl.lang.c++.moderated and then proceed accordingly.
[Bug c++/54875] Forward declare enums cannot be used as a template argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54875
--- Comment #4 from Dodji Seketeli dodji at gcc dot gnu.org 2012-11-16
15:20:11 UTC ---
Author: dodji
Date: Fri Nov 16 15:20:03 2012
New Revision: 193562
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193562
Log:
PR c++/54875 - Error with alias template that resolves to an enum
Consider this short example:
1templatetypename T
2using AddConst = T const;
3
4enum FwdEnum : int;
5
6int main() {
7 AddConstFwdEnum *ptr = nullptr;
8}
At line 7, when we build the type for AddConstFwdEnum in
lookup_template_class_1, the resulting type is the enum FwdEnum. This
confuses lookup_template_class_1 near the if below, wrongly making it
taking the branch and thus calling tsubst_enum while it shouldn't:
if (TREE_CODE (t) == ENUMERAL_TYPE !is_dependent_type)
/* Now that the type has been registered on the instantiations
list, we set up the enumerators. Because the enumeration
constants may involve the enumeration type itself, we make
sure to register the type first, and then create the
constants. That way, doing tsubst_expr for the enumeration
constants won't result in recursive calls here; we'll find
the instantiation and exit above. */
tsubst_enum (template_type, t, arglist);
Before the alias template feature, the only reason why TREE_CODE (t)
== ENUMERAL_TYPE would be true is when lookup_template_class_1 is
called for an enum that is a member of a class template. But that
condition can be also true for an alias template instantiation.
So I guess that condition should be changed to TREE_CODE
(template_type) == ENUMERAL_TYPE, to specifically detect the member
enum of a class template case. Note that for the alias template
instantiation case above, template_type points to a TEMPLATE_TYPE_PARM
which name is AddConst.
This is what the patchlet below does.
Bootstrapped and tested on x86_64-unknown-linux-gnu against trunk.
gcc/cp/
* pt.c (lookup_template_class_1): Look at the type of the
potential member enum of class template to determine if we are
actually substituting into a member enum of class template.
gcc/testsuite/
* g++.dg/cpp0x/alias-decl-27.C: New test.
Added:
trunk/gcc/testsuite/g++.dg/cpp0x/alias-decl-27.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog
[Bug c++/54875] Forward declare enums cannot be used as a template argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54875 Dodji Seketeli dodji at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Dodji Seketeli dodji at gcc dot gnu.org 2012-11-16 15:23:41 UTC --- Fixed in trunk (4.8)
[Bug other/55313] libsanitizer cannot be installed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55313 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|NEW |WAITING CC||hjl.tools at gmail dot com --- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2012-11-16 15:36:22 UTC --- Please provide complete configure option.
[Bug other/55313] libsanitizer cannot be installed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55313 --- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2012-11-16 15:38:42 UTC --- BTW, it works for me with --enable-languages=c,c++ --disable-bootstrap --prefix=/usr/gcc-4.8.0 --with-local-prefix=/usr/local --enable-gnu-indirect-function --disable-multilib --with-fpmath=sse
[Bug fortran/55345] ICE with abstract interface type with use-renamed local names
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55345 --- Comment #2 from Juno Krahn juno.krahn at nih dot gov 2012-11-16 15:56:24 UTC --- Abstract interfaces and rename aliasing are both seldom used, plus there is a work-around, so I agree that there is no need for back porting.
[Bug middle-end/53024] Support vector_size that is not a power of 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53024 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Component|c |middle-end Summary|Power of 2 requirement on |Support vector_size that is |vector_size not documented |not a power of 2 Severity|normal |enhancement --- Comment #4 from Marc Glisse glisse at gcc dot gnu.org 2012-11-16 16:06:28 UTC --- Not a priority.
[Bug tree-optimization/55260] [4.8 Regression] ICE: in ipa_get_parm_lattices, at ipa-cp.c:263 with -O2 -fno-inline -fipa-cp-clone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55260 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-11-16 AssignedTo|unassigned at gcc dot |jamborm at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #3 from Martin Jambor jamborm at gcc dot gnu.org 2012-11-16 16:07:31 UTC --- Mine.
[Bug fortran/55352] Erroneous gfortran warning of unused module variable when variable is only used in namelist
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55352 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-11-16 CC||janus at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from janus at gcc dot gnu.org 2012-11-16 16:31:27 UTC --- Confirmed. I guess we should either set attr.referenced in gfc_match_namelist (match.c), or check for attr.in_namelist in generate_local_decl (trans-decl.c).
[Bug rtl-optimization/55330] [4.8 Regression] ICE: Maximum number of LRA constraint passes is achieved (15) on gfortran.dg/actual_array_constructor_1.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55330 --- Comment #3 from Vladimir Makarov vmakarov at gcc dot gnu.org 2012-11-16 16:32:08 UTC --- Author: vmakarov Date: Fri Nov 16 16:32:02 2012 New Revision: 193567 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193567 Log: 2012-11-16 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/55330 * lra-constraints.c (MAX_INHERITANCE_PASSES): New macro. (lra_inheritance, lra_undo_inheritance): Use it to limit number of the passes. 2012-11-16 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/55330 * gfortran.dg/pr55330.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr55330.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/55330] [4.8 Regression] ICE: Maximum number of LRA constraint passes is achieved (15) on gfortran.dg/actual_array_constructor_1.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55330 Vladimir Makarov vmakarov at redhat dot com changed: What|Removed |Added CC||vmakarov at redhat dot com --- Comment #4 from Vladimir Makarov vmakarov at redhat dot com 2012-11-16 16:39:02 UTC --- (In reply to comment #2) (In reply to comment #1) I don't see it on x86_64-apple-darwin10 (revisions 193495+patches and 193329). Looks like a duplicate of 55122. The both have the same end and diagnostics but reasons for this are different.
[Bug other/55353] New: [asan] the flag for asan should match the one used in clang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55353 Bug #: 55353 Summary: [asan] the flag for asan should match the one used in clang Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: konstantin.s.serebry...@gmail.com CC: dseke...@redhat.com, dvyu...@google.com, ja...@redhat.com Currently, gcc trunk uses -faddress-sanitizer Clang has recently changed the flag to -fsanitize=address (there was a data race between clang change and gcc review-commit cycle :) We need to match the flags. Same applies to tsan (seems like it is not committed to gcc yet)
[Bug fortran/55297] [4.8 Regression] [OOP] type-bound operator clashes with abstract interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55297 --- Comment #4 from janus at gcc dot gnu.org 2012-11-16 17:02:07 UTC --- Author: janus Date: Fri Nov 16 17:02:02 2012 New Revision: 193568 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193568 Log: 2012-11-16 Janus Weil ja...@gcc.gnu.org PR fortran/55297 * resolve.c (resolve_typebound_intrinsic_op): Only add typebound operators to the operator list in the namespace of the derived type. 2012-11-16 Janus Weil ja...@gcc.gnu.org PR fortran/55297 * gfortran.dg/typebound_operator_18.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/typebound_operator_18.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug other/55354] New: [asan] by default, the asan run-time should be linked statically, not dynamically
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354 Bug #: 55354 Summary: [asan] by default, the asan run-time should be linked statically, not dynamically Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: konstantin.s.serebry...@gmail.com CC: dseke...@redhat.com, dvyu...@google.com, ja...@redhat.com Today, -faddress-sanitizer (to be changed to -fsanitize=address) causes the asan run-time library to be linked dynamically. It needs to be changed to static linkage because - it matches clang behavior - causes less confusion for users (where is my libasan.so???) - better for tsan performance (we'll need to link tsan statically too) Note that on MacOS we probably want to keep using dynamic linkage since the future library-interposition-based run-time will require it.
[Bug other/55354] [asan] by default, the asan run-time should be linked statically, not dynamically
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Version|unknown |4.8.0 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-16 17:15:31 UTC --- - it matches clang behavior But it is inconsistent with the rest of the target libraries of GCC. - causes less confusion for users (where is my libasan.so???) So this is a well documented issue already and easy fixed. - better for tsan performance (we'll need to link tsan statically too) Not much better performance.
[Bug c++/55355] New: internal compiler error: in tree_low_cst, at tree.c:6415
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55355 Bug #: 55355 Summary: internal compiler error: in tree_low_cst, at tree.c:6415 Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@sentientmeat.ca Created attachment 28711 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28711 Minimal C++ file to reproduce gcc 3.4.6 ICE in tree_low_cst, at tree.c:6415 The attached file produces the following error when compiled with gcc 3.4.6: $ /usr/local/gcc-4.6.3/bin/g++ -O2 -save-temps -c test.cpp test.cpp: In member function 'void C::funcC()': test.cpp:34:1: internal compiler error: in tree_low_cst, at tree.c:6415 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. gcc 3.4.6 is configured thusly: $ /usr/local/gcc-4.6.3/bin/g++ -v Using built-in specs. COLLECT_GCC=/usr/local/gcc-4.6.3/bin/g++ COLLECT_LTO_WRAPPER=/usr/local/gcc-4.6.3/bin/../libexec/gcc/i686-pc-linux-gnu/4.6.3/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../gcc-4.6.3/configure --prefix=/opt/soldev/gcc-4.6.3 --with-gnu-as --with-gnu-ld --disable-libgcj --enable-languages=c,c++ Thread model: posix gcc version 4.6.3 (GCC)
[Bug other/55354] [asan] by default, the asan run-time should be linked statically, not dynamically
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354 --- Comment #2 from Dmitry Vyukov dvyukov at google dot com 2012-11-16 17:20:43 UTC --- Not much better performance. Sole -fPIE vs -fPIC gives us 20% speedup on real programs. Indirect call will add another 10%.
[Bug other/55354] [asan] by default, the asan run-time should be linked statically, not dynamically
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||INVALID --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-16 17:22:03 UTC --- This has been discussed already. And Diego agreed Google can have a different default in google branches if desirable for that kind of usage scenarios, but otherwise it is undesirable.
[Bug c++/55355] internal compiler error: in tree_low_cst, at tree.c:6415
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55355 --- Comment #1 from Richard Perrin rcp at sentientmeat dot ca 2012-11-16 17:23:11 UTC --- Oops: s/3.4.6/4.6.3/ on all above. All references to gcc 3.4.6 should actually be gcc 4.6.3. I'm apparently dyslexic or something today.
[Bug c++/55338] Incorrectly reported error in type name hiding
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55338 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-16 17:27:50 UTC --- http://gcc.gnu.org/ml/gcc/2012-11/msg00259.html Covers why this still invalid code. See also 13935.
[Bug c++/55355] internal compiler error: in tree_low_cst, at tree.c:6415
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55355 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-16 17:30:55 UTC --- I can't reproduce this on x86_64-linux, neither -m64 nor -m32. Tried 4.6.3, current 4_6-branch, 4_7-branch and mainline. Somebody can?
[Bug middle-end/55078] [4.8 Regression] FAIL: g++.dg/torture/pr46154.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55078 --- Comment #7 from Jan Hubicka hubicka at gcc dot gnu.org 2012-11-16 17:32:50 UTC --- Martin, any news here?
[Bug c++/55338] Incorrectly reported error in type name hiding
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55338 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-16 17:38:40 UTC --- Closing.
[Bug bootstrap/55051] [4.8 Regression] profiledbootstrap failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55051
--- Comment #27 from Jan Hubicka hubicka at gcc dot gnu.org 2012-11-16
17:42:26 UTC ---
/* Now merge each file. */
for (gi_ptr = gcov_list; gi_ptr; gi_ptr = gi_ptr-next)
{
// Open existing gcda file for gi_ptr
// Find program summary corresponding to this executable - save in prg
// Merge execution counts for each function
// Merge program summary
// - If this is the first merged file for this execution,
save merged summary in all_prg
// - Otherwise if #runs the same in prg and all_prg,
print error message if prg != all_prg.
// Write merged gcda
}
Hmm, yes, it seems wrong. We can not expect all gcda files to have same number
of runs. We really need to process sum_all friends locally for each file.
Only I suppose we can check if number of runs of the prg happens to match the
last merged file then sum_all should match. That would be nice consistency
check. If the bootstrap works with this change, consider the patch preapproved.
[Bug target/55339] C++ code compiled with -O2 on Linux ppc hangs in runtime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55339 --- Comment #4 from anton.katilin at gmail dot com 2012-11-16 17:44:16 UTC --- Why did you do that? We copied the configuration of gcc 4.1.2 available on the system (Yellow Dog Linux) out of the box. It had been configured with --disable-libunwind-exceptions By the way, the problem is not reproducible with that gcc 4.1.2.
[Bug tree-optimization/38785] [4.5/4.6/4.7/4.8 Regression] huge performance regression on EEMBC bitmnp01
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38785
Jan Hubicka hubicka at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|WAITING
CC||hubicka at gcc dot gnu.org
Resolution|FIXED |
--- Comment #32 from Jan Hubicka hubicka at gcc dot gnu.org 2012-11-16
17:50:28 UTC ---
Would be possible to double check if this problem is still fixed after the fix
to the tree-ssa-pre patch? I do not see any cold edges involved here, so
perhaps we will need better heuristic.
We now again find some partial redundancies.
Found partial redundancy for expression {mem_ref0B,_20}@.MEM_5 (0024)
Inserted pretmp_57 = *_20;
in predecessor 6
Created phi prephitmp_56 = PHI _24(20), pretmp_57(6)
in block 7
Found partial redundancy for expression {mem_ref0B,_20}@.MEM_6 (0029)
Inserted pretmp_55 = *_20;
in predecessor 8
Created phi prephitmp_63 = PHI _29(21), pretmp_55(8)
in block 9
Found partial redundancy for expression {mem_ref0B,_20}@.MEM_7 (0034)
Inserted pretmp_64 = *_20;
in predecessor 10
Created phi prephitmp_65 = PHI _34(22), pretmp_64(10)
in block 11
Found partial redundancy for expression {mem_ref0B,_20}@.MEM_8 (0039)
Inserted pretmp_66 = *_20;
in predecessor 12
Created phi prephitmp_67 = PHI _39(23), pretmp_66(12)
in block 13
Starting insert iteration 2
Replaced *_20 with prephitmp_56 in _29 = *_20;
Replaced *_20 with prephitmp_63 in _34 = *_20;
Replaced *_20 with prephitmp_65 in _39 = *_20;
Replaced *_20 with prephitmp_67 in _44 = *_20;
[Bug c++/55355] internal compiler error: in tree_low_cst, at tree.c:6415
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55355 --- Comment #3 from Richard Perrin rcp at sentientmeat dot ca 2012-11-16 17:50:30 UTC --- (In reply to comment #2) I can't reproduce this on x86_64-linux, neither -m64 nor -m32. Tried 4.6.3, current 4_6-branch, 4_7-branch and mainline. I have tried 4.7.1 and 4.7.2 on the same systems, built with the same configuration, and can confirm that neither of these versions suffers from this problem. (Other issues prevent us from adopting those versions.)
[Bug tree-optimization/38785] [4.5/4.6/4.7/4.8 Regression] huge performance regression on EEMBC bitmnp01
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38785 --- Comment #33 from Jan Hubicka hubicka at gcc dot gnu.org 2012-11-16 18:00:54 UTC --- And at -O3 the testcase does not look really good indeed bb 7: # cstore_51 = PHI 0(5), 2147483647(6) # prephitmp_82 = PHI 1073741823(5), 3221225470(6) # prephitmp_83 = PHI 1789569705(5), 3937053352(6) # prephitmp_84 = PHI 2326440616(5), 4473924263(6) # prephitmp_85 = PHI 2755937345(5), 4903420992(6) # prephitmp_86 = PHI 3113851286(5), 5261334933(6) # prephitmp_87 = PHI 2684354557(5), 4831838204(6) # prephitmp_88 = PHI 2219066434(5), 4366550081(6) # prephitmp_89 = PHI 2576980375(5), 4724464022(6) # prephitmp_90 = PHI 2147483646(5), 4294967293(6) # prephitmp_91 = PHI 1610612734(5), 3758096381(6) # prephitmp_92 = PHI 2040109463(5), 4187593110(6) # prephitmp_93 = PHI 2398023404(5), 4545507051(6) # prephitmp_94 = PHI 1968526675(5), 4116010322(6) # prephitmp_95 = PHI 1503238552(5), 3650722199(6) # prephitmp_96 = PHI 1861152493(5), 4008636140(6) # prephitmp_97 = PHI 1431655764(5), 3579139411(6) # prephitmp_98 = PHI 715827882(5), 2863311529(6) # prephitmp_99 = PHI 1252698793(5), 3400182440(6) # prephitmp_100 = PHI 1682195522(5), 3829679169(6) # prephitmp_103 = PHI 1145324611(5), 3292808258(6) # prephitmp_106 = PHI 536870911(5), 2684354558(6) # prephitmp_107 = PHI 966367640(5), 3113851287(6) # prephitmp_108 = PHI 1324281581(5), 3471765228(6) # prephitmp_109 = PHI 894784852(5), 3042268499(6) # prephitmp_110 = PHI 429496729(5), 2576980376(6) # prephitmp_111 = PHI 787410670(5), 2934894317(6) # prephitmp_112 = PHI 357913941(5), 2505397588(6) *_18 = cstore_51; _24 = *_20; _25 = _24 2; if (_25 = -14) goto bb 8; else goto bb 9; The catch is that the patch disabled the partial PRE by an accident. No cold edges are involved here since we predict all the branches quite even :(
[Bug bootstrap/55051] [4.8 Regression] profiledbootstrap failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55051
--- Comment #28 from Teresa Johnson tejohnson at google dot com 2012-11-16
18:03:08 UTC ---
On Fri, Nov 16, 2012 at 9:42 AM, hubicka at gcc dot gnu.org
gcc-bugzi...@gcc.gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55051
--- Comment #27 from Jan Hubicka hubicka at gcc dot gnu.org 2012-11-16
17:42:26 UTC ---
/* Now merge each file. */
for (gi_ptr = gcov_list; gi_ptr; gi_ptr = gi_ptr-next)
{
// Open existing gcda file for gi_ptr
// Find program summary corresponding to this executable - save in
prg
// Merge execution counts for each function
// Merge program summary
// - If this is the first merged file for this execution,
save merged summary in all_prg
// - Otherwise if #runs the same in prg and all_prg,
print error message if prg != all_prg.
// Write merged gcda
}
Hmm, yes, it seems wrong. We can not expect all gcda files to have same
number
of runs. We really need to process sum_all friends locally for each file.
Only I suppose we can check if number of runs of the prg happens to match the
last merged file then sum_all should match.
I'm confused - that is essentially what it is doing today (although
comparing against the first merged file instead of the last merged
file). It isn't expecting all the gcda files to have the same number
of runs, but when they do it expects them to have the same sum_all.
See the trace of updates I show below this pseudo code in the same
email that shows why that is not working.
That would be nice consistency
check. If the bootstrap works with this change, consider the patch
preapproved.
I had sent a patch last night to simply rip out this check based on
the analysis I had done, but I assume you are not talking about that.
Thanks,
Teresa
--
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413
[Bug libstdc++/55041] prettyprinting/shared_ptr cxx11 fails on some platforms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55041 --- Comment #11 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-16 18:14:02 UTC --- Tom, do you have any idea what's going on in comment 6 and comment 8 of this bug?
[Bug fortran/55356] New: ICE with TRANSFER of C_NULL_PTR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55356 Bug #: 55356 Summary: ICE with TRANSFER of C_NULL_PTR Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: juno.kr...@nih.gov Example code (bug.f90): use iso_c_binding type(C_ptr) :: p p = transfer(C_NULL_ptr,p) end Result: $ gfortran -c bug.f90 f951: 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. Seems likely related to bug 46974
[Bug c++/55357] New: -Wshadow warns about lambda function parameters matching variables in outer scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55357
Bug #: 55357
Summary: -Wshadow warns about lambda function parameters
matching variables in outer scope
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: da...@doublewise.net
Similar to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30566
input:
int main() {
int x = 1;
auto const lambda = [](int x) {
return x;
};
}
output:
src/main.cpp: In lambda function:
src/main.cpp:3:30: error: declaration of 'x' shadows a previous local
[-Werror=shadow]
src/main.cpp:2:6: error: shadowed declaration is here [-Werror=shadow]
src/main.cpp: In static member function 'static int
main()::lambda(int)::_FUN(int)':
src/main.cpp:5:2: error: declaration of 'x' shadows a previous local
[-Werror=shadow]
src/main.cpp:2:6: error: shadowed declaration is here [-Werror=shadow]
cc1plus: all warnings being treated as errors
My lambda has an empty capture specification, so the outer x is not captured.
Note that if I change the lambda parameter's name but do not change the name of
the returned value, I get an error that x was not captured.
I can't decide if this is correct behavior for the warning. It would catch
errors caused by people thinking they were using the outer variables by simply
disallowing overlap, which is good. However, it's not possible to use the outer
scope variable no matter what I name my variables in the inner scope, so there
is no chance of a silent behavior change.
However, the following code should always give a warning with -Wshadow:
int main() {
int x = 1;
// Capture everything
auto const lambda = [](int x) {
return x;
};
}
I also note that gcc warns me about the first line the lambda appears on (line
3) and the last line (line 5).
[Bug fortran/55297] [4.8 Regression] [OOP] type-bound operator clashes with abstract interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55297 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from janus at gcc dot gnu.org 2012-11-16 18:17:28 UTC --- Fixed with r193568. Closing.
[Bug middle-end/53024] Support vector_size that is not a power of 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53024 --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-16 18:18:16 UTC --- I don't think we can ever support vector size of non power 2 size.
[Bug tree-optimization/55286] [4.7/4.8 Regression] Bytemark ASSIGNMENT 4% - 10% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55286
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-16
18:28:30 UTC ---
Created attachment 28712
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28712
assign.c
Assignment extracted into a self-contained testcase, does this also make a
similar difference for you? On which CPU? Yes, there is a code generation
difference with that commit, in *.optimized the difference seems to be
(-vanilla, + with Kai's patch reverted):
@@ -192,13 +192,12 @@ Assignment (long int[101] * arraybase)
sizetype _302;
unsigned long _303;
sizetype _306;
long unsigned int pretmp_307;
long unsigned int pretmp_308;
long int[101] * pretmp_318;
- unsigned long _322;
short unsigned int ivtmp_334;
unsigned long _350;
unsigned int _351;
long unsigned int patt_353;
short unsigned int _354;
unsigned long _355;
@@ -286,27 +285,26 @@ Assignment (long int[101] * arraybase)
bb 5:
# currentmin_72 = PHI currentmin_402(4)
_356 = ivtmp.312_453 15;
_350 = _356 3;
_355 = -_350;
_354 = (short unsigned int) _355;
- _322 = _355 1;
- prolog_loop_niters.10_359 = (short unsigned int) _322;
+ prolog_loop_niters.10_359 = _354 1;
if (prolog_loop_niters.10_359 == 0)
goto bb 7;
else
goto bb 6;
bb 6:
_272 = MEM[base: pretmp_395, offset: 0B];
_256 = _272 - currentmin_72;
MEM[base: pretmp_395, offset: 0B] = _256;
bb 7:
# j_269 = PHI 1(6), 0(5)
- prolog_loop_adjusted_niters.11_124 = _355 1;
+ prolog_loop_adjusted_niters.11_124 = (sizetype) prolog_loop_niters.10_359;
niters.12_129 = 101 - prolog_loop_niters.10_359;
base_off.19_523 = prolog_loop_adjusted_niters.11_124 * 8;
vect_p.20_524 = pretmp_395 + base_off.19_523;
vect_cst_.23_528 = {currentmin_72, currentmin_72};
bb 8:
This change happens very late (forwprop4) and nothing afterwards cleans it up
(there is no DCE etc. that would DCE the dead assignment to _354 and there is
no PRE/FRE to replace _355 1 in the second case with _322. Still just
zero-extending _359 is perhaps cheaper register pressure-wise.
That said, I can't find any measurable differences between the two.
[Bug other/55358] New: Valgrind errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55358 Bug #: 55358 Summary: Valgrind errors Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com With revision 193546, valgrind reports: ==25552== Invalid read of size 8 ==25552==at 0x38F3A88D5F: __GI_mempcpy (in /usr/lib64/libc-2.15.so) ==25552==by 0x38F3A785DD: _IO_default_xsputn (in /usr/lib64/libc-2.15.so) ==25552==by 0x38F3A76940: _IO_file_xsputn@@GLIBC_2.2.5 (in /usr/lib64/libc-2.15.so) ==25552==by 0x38F3A6C4FC: fwrite (in /usr/lib64/libc-2.15.so) ==25552==by 0x622AD7: ggc_pch_write_object(ggc_pch_data*, _IO_FILE*, void*, void*, unsigned long, bool) (ggc-page.c:2322) ==25552==by 0x74D8C1: gt_pch_save(_IO_FILE*) (ggc-common.c:593) ==25552==by 0x610027: c_common_write_pch() (c-pch.c:184) ==25552==by 0x548D45: cp_write_global_declarations() (decl2.c:3948) ==25552==by 0x8A252C: compile_file() (toplev.c:559) ==25552==by 0x8A4087: toplev_main(int, char**) (toplev.c:1881) ==25552==by 0x38F3A21674: (below main) (in /usr/lib64/libc-2.15.so) ==25552== Address 0x1089a7d8 is not stack'd, malloc'd or (recently) free'd ==25552== Invalid read of size 8 ==25552==at 0x4A0A33A: memcpy@@GLIBC_2.14 (mc_replace_strmem.c:881) ==25552==by 0x74D84B: gt_pch_save(_IO_FILE*) (ggc-common.c:583) ==25552==by 0x610027: c_common_write_pch() (c-pch.c:184) ==25552==by 0x548D45: cp_write_global_declarations() (decl2.c:3948) ==25552==by 0x8A252C: compile_file() (toplev.c:559) ==25552==by 0x8A4087: toplev_main(int, char**) (toplev.c:1881) ==25552==by 0x38F3A21674: (below main) (in /usr/lib64/libc-2.15.so) ==25552== Address 0xce8 is not stack'd, malloc'd or (recently) free'd ==25565== Invalid write of size 8 ==25565==at 0x4A0A23B: memcpy@@GLIBC_2.14 (mc_replace_strmem.c:881) ==25565==by 0x74D8E3: gt_pch_save(_IO_FILE*) (ggc-common.c:595) ==25565==by 0x610027: c_common_write_pch() (c-pch.c:184) ==25565==by 0x548D45: cp_write_global_declarations() (decl2.c:3948) ==25565==by 0x8A252C: compile_file() (toplev.c:559) ==25565==by 0x8A4087: toplev_main(int, char**) (toplev.c:1881) ==25565==by 0x38F3A21674: (below main) (in /usr/lib64/libc-2.15.so) ==25565== Address 0xfb40778 is not stack'd, malloc'd or (recently) free'd ==26359== Invalid read of size 4 ==26359==at 0xB58AEE: rest_of_handle_ree() (ree.c:617) ==26359==by 0x74ADA3: execute_one_pass(opt_pass*) (passes.c:2339) ==26359==by 0x74B174: execute_pass_list(opt_pass*) (passes.c:2400) ==26359==by 0x74B186: execute_pass_list(opt_pass*) (passes.c:2401) ==26359==by 0x74B186: execute_pass_list(opt_pass*) (passes.c:2401) ==26359==by 0x5AB16D: expand_function(cgraph_node*) (cgraphunit.c:1643) ==26359==by 0x5AC786: compile() (cgraphunit.c:1747) ==26359==by 0x5ACBA9: finalize_compilation_unit() (cgraphunit.c:2122) ==26359==by 0x4E47DF: c_write_global_declarations() (c-decl.c:10128) ==26359==by 0x7D7F4C: compile_file() (toplev.c:559) ==26359==by 0x7D9AA7: toplev_main(int, char**) (toplev.c:1881) ==26359==by 0x38F3A21674: (below main) (in /usr/lib64/libc-2.15.so) ==26359== Address 0x4e10d51 is 2,785 bytes inside a block of size 2,788 alloc'd ==26359==at 0x4A06B0F: calloc (vg_replace_malloc.c:593) ==26359==by 0xC0F708: xcalloc (xmalloc.c:162) ==26359==by 0xB59070: rest_of_handle_ree() (ree.c:886)
[Bug bootstrap/55051] [4.8 Regression] profiledbootstrap failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55051 --- Comment #29 from Jan Hubicka hubicka at ucw dot cz 2012-11-16 18:57:41 UTC --- I'm confused - that is essentially what it is doing today (although comparing against the first merged file instead of the last merged file). It isn't expecting all the gcda files to have the same number of runs, but when they do it expects them to have the same sum_all. See the trace of updates I show below this pseudo code in the same email that shows why that is not working. Hmm, after some tought I guess what can happen is that number of run matches but these are different run, because more than 2 streamings may be running... Honza
[Bug middle-end/55359] New: [4.8 Regression] ICE in simplify_subreg accessing an unaligned subvector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55359
Bug #: 55359
Summary: [4.8 Regression] ICE in simplify_subreg accessing an
unaligned subvector
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gli...@gcc.gnu.org
I am not quite sure if this code is legal. I noticed it first with a
BIT_FIELD_REF (generated by a local patch), but it also happens with a MEM_REF.
The code generated by 4.7 seems correct, even if it isn't optimal.
$ cat s.c
#include x86intrin.h
__m128d f(__m256d x){
return *((__m128d*)((double*)x+1));
}
$ gcc s.c -mavx2 -S -O2
s.c: In function 'f':
s.c:4:3: internal compiler error: in simplify_subreg, at simplify-rtx.c:5688
return *((__m128d*)((double*)x+1));
^
0x9052f6 simplify_subreg(machine_mode, rtx_def*, machine_mode, unsigned int)
/data/repos/gcc/pristine/gcc/simplify-rtx.c:5688
0x90b8bd simplify_gen_subreg(machine_mode, rtx_def*, machine_mode, unsigned
int)
/data/repos/gcc/pristine/gcc/simplify-rtx.c:5903
0x6ec7e8 extract_bit_field_1
/data/repos/gcc/pristine/gcc/expmed.c:1482
0x6ecda3 extract_bit_field(rtx_def*, unsigned long, unsigned long, int, bool,
rtx_def*, machine_mode, machine_mode)
/data/repos/gcc/pristine/gcc/expmed.c:1711
0x6fa77e expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**)
/data/repos/gcc/pristine/gcc/expr.c:10006
0x6fb505 expand_expr
/data/repos/gcc/pristine/gcc/expr.h:444
0x6fb505 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**)
/data/repos/gcc/pristine/gcc/expr.c:9614
0x6fb623 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**)
/data/repos/gcc/pristine/gcc/expr.c:9179
0x9152a8 expand_expr
/data/repos/gcc/pristine/gcc/expr.h:444
0x9152a8 expand_return(tree_node*)
/data/repos/gcc/pristine/gcc/stmt.c:1546
0x635273 expand_gimple_stmt_1
/data/repos/gcc/pristine/gcc/cfgexpand.c:2082
0x635273 expand_gimple_stmt
/data/repos/gcc/pristine/gcc/cfgexpand.c:2204
0x636c82 expand_gimple_basic_block
/data/repos/gcc/pristine/gcc/cfgexpand.c:3978
0x639aee gimple_expand_cfg
/data/repos/gcc/pristine/gcc/cfgexpand.c:4497
[Bug bootstrap/54795] [4.8 Regression] Random profiledbootstrap failure with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54795
--- Comment #5 from Markus Trippelsdorf markus at trippelsdorf dot de
2012-11-16 19:36:26 UTC ---
I'm not sure if it's related, but with gcc built with clang's
-fsanitize=address I get:
markus@x4 ~ % /var/tmp/gcc_sani_clang/usr/local/bin/g++ -flto t.cpp 21 |
asan_symbolize.py | c++filt
=
==15267== ERROR: AddressSanitizer: global-buffer-overflow on address
0x02d16424 at pc 0x12ca07a bp 0x7fff5db28190 sp 0x7fff5db28188
READ of size 4 at 0x02d16424 thread T0
#0 0x12ca079 in lto_write_options() /home/markus/gcc/gcc/lto-opts.c:97
#1 0x12c076a in produce_asm_for_decls()
/home/markus/gcc/gcc/lto-streamer-out.c:1407
#2 0x135a74f in ipa_write_summaries_2(opt_pass*, lto_out_decl_state*)
/home/markus/gcc/gcc/passes.c:2430
0x02d16424 is located 28 bytes to the left of global variable '.str2184
(options.c)' (0x2d16440) of size 4
'.str2184 (options.c)' is ascii string 'gnu'
0x02d16424 is located 25 bytes to the right of global variable '.str2183
(options.c)' (0x2d16400) of size 11
'.str2183 (options.c)' is ascii string 'local-exec'
Shadow byte and word:
0x105a2c84: f9
0x105a2c80: 00 03 f9 f9 f9 f9 f9 f9
More shadow bytes:
0x105a2c60: 00 00 00 02 f9 f9 f9 f9
0x105a2c68: 00 07 f9 f9 f9 f9 f9 f9
0x105a2c70: 00 05 f9 f9 f9 f9 f9 f9
0x105a2c78: 00 06 f9 f9 f9 f9 f9 f9
=0x105a2c80: 00 03 f9 f9 f9 f9 f9 f9
0x105a2c88: 04 f9 f9 f9 f9 f9 f9 f9
0x105a2c90: 05 f9 f9 f9 f9 f9 f9 f9
0x105a2c98: 00 f9 f9 f9 f9 f9 f9 f9
0x105a2ca0: 07 f9 f9 f9 f9 f9 f9 f9
Stats: 3M malloced (2M for red zones) by 3820 calls
Stats: 0M realloced by 288 calls
Stats: 2M freed by 1635 calls
Stats: 0M really freed by 0 calls
Stats: 9M (2317 full pages) mmaped in 18 calls
mmaps by size class: 7:4095; 8:2047; 9:1023; 10:511; 11:255; 12:384; 13:64;
14:32; 15:16; 16:8; 17:20; 18:2;
mallocs by size class: 7:2233; 8:820; 9:69; 10:96; 11:228; 12:297; 13:49;
14:1; 15:5; 16:1; 17:20; 18:1;
frees by size class: 7:523; 8:492; 9:47; 10:80; 11:156; 12:291; 13:21;
14:1; 15:4; 17:20;
rfrees by size class:
Stats: malloc large: 27 small slow: 88
==15267== ABORTING
markus@x4 ~ % cat t.cpp
int main () {}
[Bug middle-end/53024] Support vector_size that is not a power of 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53024 --- Comment #6 from Marc Glisse glisse at gcc dot gnu.org 2012-11-16 20:03:05 UTC --- (In reply to comment #5) I don't think we can ever support vector size of non power 2 size. I don't think we *will* ever support them (too much work, too little benefit), but I am not sure why we couldn't in principle.
[Bug other/55354] [asan] by default, the asan run-time should be linked statically, not dynamically
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354 --- Comment #4 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-16 20:28:34 UTC --- You have been warned (especially about tsan performance. tsan run-time heavily depends on TLS, and TLS is much slower with -fPIC than with -fPIE). Do we have a flag today which will cause libasan.a to be linked statically, while not forcing anything else to link statically?
[Bug libstdc++/55041] prettyprinting/shared_ptr cxx11 fails on some platforms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55041 --- Comment #12 from Tom Tromey tromey at gcc dot gnu.org 2012-11-16 20:46:33 UTC --- (In reply to comment #11) Tom, do you have any idea what's going on in comment 6 and comment 8 of this bug? Not offhand. If you send me the failing executable(s) I can take a look at their debuginfo. Maybe that will be useful. I don't think gdb 7.3 really works with trunk after this patch, though: commit 2dd133d84c8991217864523ea79d11f1885f1388 Author: mark mark@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Mon Aug 20 20:27:46 2012 + dwarf2out.c: For DWARF 4+, output DW_AT_high_pc as constant offset. This required a gdb change. Another thing to try is turning on complaints before running the program in gdb: (gdb) set complaints 1 (gdb) start For me this prints tons of junk, some of which could actually be gcc bugs: DW_AT_low_pc 0x0 is zero for DIE at 0xf055a [in module /home/tromey/Space/Trunk/Git/build/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs/libstdc++.so.6]... debug_line address at offset 0x449b7 is 0 [in module /home/tromey/Space/Trunk/Git/build/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs/libstdc++.so.6] It's hard to say without debugging further, this is just a first glance. I'm not sure if these could cause the problems you're seeing. FWIW, the tests mostly work for me, except: UNSUPPORTED: libstdc++-prettyprinters/shared_ptr.cc In my case the issue seems to be weird debuginfo emitted by gcc; look at what the breakpoint reports: Breakpoint 1, _GLOBAL__sub_I__Z4makem () at /home/tromey/Space/Trunk/Git/gcc/lib stdc++-v3/testsuite/libstdc++-prettyprinters/shared_ptr.cc:81 Setting it by hand with gdb shared_ptr.exe then break 72: (gdb) b 72 Breakpoint 1 at 0x400deb: /home/tromey/Space/Trunk/Git/gcc/libstdc++-v3/testsuite/libstdc++-prettyprinters/shared_ptr.cc:72. (3 locations) (gdb) info b Num Type Disp Enb AddressWhat 1 breakpoint keep y MULTIPLE 1.1 y 0x00400deb in main() at /home/tromey/Space/Trunk/Git/gcc/libstdc++-v3/testsuite/libstdc++-prettyprinters/shared_ptr.cc:72 1.2 y 0x00400ec0 in _GLOBAL__sub_I__Z4makem() at /home/tromey/Space/Trunk/Git/gcc/libstdc++-v3/testsuite/libstdc++-prettyprinters/shared_ptr.cc:72 1.3 y 0x00401070 in std::_Sp_counted_deleterint*, deleter, std::allocatorint, (__gnu_cxx::_Lock_policy)2::_M_get_deleter(std::type_info const) at /home/tromey/Space/Trunk/Git/gcc/libstdc++-v3/testsuite/libstdc++-prettyprinters/shared_ptr.cc:72 ... very weird, looks like a gcc bug to me.
[Bug other/55354] [asan] by default, the asan run-time should be linked statically, not dynamically
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-16 20:46:35 UTC --- For TLS, you can just use -ftls-model=initial-exec or __attribute__((tls_model (initial-exec))). libasan from what I can see doesn't use TLS at all, and you really can't just have -fno-pic libasan.a only anyway, any time you want to instrument a shared library, if you linked non-pic libasan.a into it, it wouldn't link on many architectures and on others would fail SELinux restrictions. If IE TLS mode is used, there is no problem if an app is linked against it or if libraries it depends on are linked against it, there could be a problem if its TLS usage is too large and app isn't linked against the library, and you only dlopen some -fsanitize=address compiled/linked shared library. Then dlopen could fail (unless you e.g. LD_PRELOAD=libasan.so.0 or otherwise make sure the app is linked against it). Other GCC shared libraries (e.g. libgomp.so.1) are also using the IE model.
[Bug rtl-optimization/55360] New: [TileGX] Passing structure by value on stack needlessly writes to and reads from memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55360
Bug #: 55360
Summary: [TileGX] Passing structure by value on stack
needlessly writes to and reads from memory
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: colander...@gmail.com
#include stdint.h
struct bar { uint8_t a, b, c, d; };
struct bla { unsigned long a:8, b:8, c:8, d:8; };
uint64_t bar(struct bar);
uint64_t bla(struct bla);
uint64_t foo(uint8_t a, uint8_t b, uint8_t c, uint8_t d)
{ return bar((struct bar) { a, b, c, d }); }
uint64_t baz(uint8_t a, uint8_t b, uint8_t c, uint8_t d)
{ return bla((struct bla) { a, b, c, d }); }
when compiled with gcc -Wall -std=gnu99 -O3 -S pbv.c produces:
.filepbv.c
.text
.align 8
.global foo
.typefoo, @function
foo:
.LFB0:
.cfi_startproc
{
stsp, lr
.cfi_offset 55, 0
mover29, sp
addir28, sp, -16
}
addisp, sp, -24
.cfi_def_cfa_offset 24
{
str28, r29
addir11, sp, 21
addir10, sp, 20
}
{
st1r11, r1
addir11, sp, 22
}
{
st1r11, r2
addir11, sp, 23
}
{
st1r10, r0
moveir0, 0
}
st1r11, r3
ld4ur10, r10
{
bfinsr0, r10, 0, 0+32-1
jalbar
}
addir29, sp, 24
ldlr, r29
{
addisp, sp, 24
.cfi_restore 54
.cfi_restore 55
.cfi_def_cfa_offset 0
jrplr
}
.cfi_endproc
.LFE0:
.sizefoo, .-foo
.align 8
.global baz
.typebaz, @function
baz:
.LFB1:
.cfi_startproc
{
moveir10, 0
stsp, lr
.cfi_offset 55, 0
mover29, sp
}
{
bfinsr10, r0, 0, 7
addir28, sp, -8
}
{
bfinsr10, r1, 8, 8+8-1
addisp, sp, -16
}
.cfi_def_cfa_offset 16
{
bfinsr10, r2, 16, 16+8-1
str28, r29
}
bfinsr10, r3, 24, 24+8-1
{
mover0, r10
jalbla
}
addir29, sp, 16
ldlr, r29
{
addisp, sp, 16
.cfi_restore 54
.cfi_restore 55
.cfi_def_cfa_offset 0
jrplr
}
.cfi_endproc
.LFE1:
.sizebaz, .-baz
.identGCC: (GNU) 4.7.2
.section.note.GNU-stack,,@progbits
My expectation is that the foo and baz should compile identically, and should
use the bfins bit-arithmetic functions like baz does, rather than redundant
stores and loads to stack like foo does.
This is with a vanilla GCC 4.7.2 build on a Tilempower system (roughly CentOS
5.7).
The problem does not occur on Debian x86-64 with either GCC 4.4.6 or GCC 4.7.2.
Possibly related to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7061 (however
that case seems to be fixed in 4.7.2).
[Bug other/55354] [asan] by default, the asan run-time should be linked statically, not dynamically
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354 --- Comment #6 from Konstantin Serebryany konstantin.s.serebryany at gmail dot com 2012-11-16 20:54:40 UTC --- Answering my own question: we can get static linking with -Wl,-Bstatic -lasan -Wl,-Bdynamic -ldl -lpthread For TLS, you can just use -ftls-model=initial-exec I did not know, thanks. Sounds like this could be a good solution for tsan. Will check.
[Bug fortran/55352] Erroneous gfortran warning of unused module variable when variable is only used in namelist
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55352
--- Comment #3 from janus at gcc dot gnu.org 2012-11-16 21:43:34 UTC ---
(In reply to comment #2)
I guess we should either set attr.referenced in gfc_match_namelist (match.c),
or check for attr.in_namelist in generate_local_decl (trans-decl.c).
The latter is what we do for related cases. Proposed patch:
Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c(revision 193567)
+++ gcc/fortran/trans-decl.c(working copy)
@@ -4589,23 +4589,26 @@ generate_local_decl (gfc_symbol * sym)
}
/* Warn for unused variables, but not if they're inside a common
- block, a namelist, or are use-associated. */
+ block or a namelist. */
else if (warn_unused_variable
-!(sym-attr.in_common || sym-attr.use_assoc || sym-mark
-|| sym-attr.in_namelist))
+!(sym-attr.in_common || sym-mark || sym-attr.in_namelist))
{
- gfc_warning (Unused variable '%s' declared at %L, sym-name,
- sym-declared_at);
- if (sym-backend_decl != NULL_TREE)
-TREE_NO_WARNING(sym-backend_decl) = 1;
+ if (sym-attr.use_only)
+{
+ gfc_warning (Unused module variable '%s' which has been
+ explicitly imported at %L, sym-name,
+ sym-declared_at);
+ if (sym-backend_decl != NULL_TREE)
+TREE_NO_WARNING(sym-backend_decl) = 1;
+}
+ else if (!sym-attr.use_assoc)
+{
+ gfc_warning (Unused variable '%s' declared at %L,
+ sym-name, sym-declared_at);
+ if (sym-backend_decl != NULL_TREE)
+TREE_NO_WARNING(sym-backend_decl) = 1;
+}
}
- else if (warn_unused_variable sym-attr.use_only)
-{
- gfc_warning (Unused module variable '%s' which has been explicitly
- imported at %L, sym-name, sym-declared_at);
- if (sym-backend_decl != NULL_TREE)
-TREE_NO_WARNING(sym-backend_decl) = 1;
-}
/* For variable length CHARACTER parameters, the PARM_DECL already
references the length variable, so force gfc_get_symbol_decl
[Bug tree-optimization/55329] [4.8 Regression] ICE: internal compiler error: in operator[], at vec.h:487 with -O -fno-guess-branch-probability -fnon-call-exceptions --param=early-inlining-insns=111
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55329 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2012-11-16 22:05:36 UTC --- Author: jakub Date: Fri Nov 16 22:05:32 2012 New Revision: 193577 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193577 Log: PR tree-optimization/55329 * tree-ssa-dom.c (tree_ssa_dominator_optimize): Never clear bits in needed_eh_cleanup while iterating over the bitmap. Look through all forwarder blocks at once. * g++.dg/opt/pr55329.C: New test. Added: trunk/gcc/testsuite/g++.dg/opt/pr55329.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-dom.c
[Bug c++/55361] New: Access control in templates only happens when instantiating a method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55361
Bug #: 55361
Summary: Access control in templates only happens when
instantiating a method
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jo...@netbsd.org
Consider the following example:
class C
{
bool blocked;
};
template class struct F
{
void operator* ()
{
C a;
a.blocked;
}
};
int main() {
Fint x;
}
The operator is violating the access specifications of C, but this isn't
detected until it is actually used. Nothing in it depends on the template
though, so this check should happen earlier.
[Bug c++/55361] Access control in templates only happens when instantiating a method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55361 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-16 22:32:03 UTC --- The Comeau C/C++ online tester does not error out on this testcase.
[Bug c++/55361] Access control in templates only happens when instantiating a method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55361 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-16 22:38:47 UTC --- I don't think this is a gcc bug as access control is always done only at template-instantiation time.
[Bug target/54342] OImode is used for _m256 types when using unions in a function call.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54342 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|rtl-optimization|target Target Milestone|4.8.0 |--- Summary|[4.8 Regression] Wrong mode |OImode is used for _m256 |of call argument|types when using unions in ||a function call. --- Comment #13 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-16 22:58:46 UTC --- (insn 10 9 11 3 (set (reg:OI 21 xmm0) (reg:OI 64)) er.c:14 -1 (nil)) This above is generated by the back-end's call by construct_container. So this is not a middle-end issue even if the middle-end says the mode on the union is BLKmode. It is up to the back-end to do the correct thing when it is doing a function call and converting the BLKmode of the union to the correct mode. case 4: gcc_assert (i == 0 regclass[1] == X86_64_SSEUP_CLASS regclass[2] == X86_64_SSEUP_CLASS regclass[3] == X86_64_SSEUP_CLASS); tmpmode = OImode; Is where the OImode is being generated. The comment in ix86_hard_regno_mode_ok says: /* We implement the move patterns for all vector modes into and out of SSE registers, even when no operation instructions are available. OImode move is available only when AVX is enabled. */ So really I don't think this is a bug in the code itself but rather the patch which you are working on which did not take into account OImode being an AVX mode.
[Bug target/53101] Recognize casts to sub-vectors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53101 --- Comment #7 from Marc Glisse glisse at gcc dot gnu.org 2012-11-16 23:03:47 UTC --- Created attachment 28713 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28713 Tweak on the patch of PR48037 This is a slight extension of Richard's patch for PR 48037. It needs testing and doesn't solve the real problem (which is at the RTL level). I am not sure if BIT_FIELD_REF (a mention of that tree in doc/generic.texi would be nice) is allowed to refer to an unaligned subvector, the patch allows it as long as the elements are aligned. See PR 55359 for a related issue.
[Bug c++/55361] Access control in templates only happens when instantiating a method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55361 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2012-11-16 23:06:09 UTC --- Likewise EDG as used by Intel. clang errors out. From the user point of view, to make debugging easier, the earlier errors are produced the better, but this is just a general principle, thus I don't think this is a compiler bug, at most a QoI issue. A well known one, by the way: in many, many, other cases we aren't very aggressive at that.
[Bug rtl-optimization/55360] [TileGX] Passing structure by value on stack needlessly writes to and reads from memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55360 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com 2012-11-16 23:46:25 UTC --- Is this related to PR 28831?
[Bug c++/55361] Access control in templates only happens when instantiating a method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55361 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-17 00:19:18 UTC --- unless this is recategorised as a diagnostic enhancement request this is clearly invalid, the compiler is not required to give an error for this code
[Bug libstdc++/55041] prettyprinting/shared_ptr cxx11 fails on some platforms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55041 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||mark at gcc dot gnu.org --- Comment #13 from Jonathan Wakely redi at gcc dot gnu.org 2012-11-17 00:47:40 UTC --- (In reply to comment #12) (In reply to comment #11) Tom, do you have any idea what's going on in comment 6 and comment 8 of this bug? Not offhand. If you send me the failing executable(s) I can take a look at their debuginfo. Maybe that will be useful. OK, will do so asap I don't think gdb 7.3 really works with trunk after this patch, though: commit 2dd133d84c8991217864523ea79d11f1885f1388 Author: mark mark@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Mon Aug 20 20:27:46 2012 + dwarf2out.c: For DWARF 4+, output DW_AT_high_pc as constant offset. This required a gdb change. Ah, that should be in http://gcc.gnu.org/gcc-4.8/changes.html then. Mark? ... very weird, looks like a gcc bug to me. Thanks, I thought it might be but don't know enough to confirm it or know where to start looking.
