[Bug middle-end/59336] definition in block 317 does not dominate use in block 316
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59336 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #1 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- How to reproduce svn checkout -r13372 svn://svn.code.sf.net/p/cp2k/code/trunk/cp2k cp2k cd cp2k/makefiles/ # check compiler version/libs are correct cat ../arch/PR59336.sdbg make -j32 ARCH=PR59336 VERSION=sdbg
[Bug regression/59320] ftree-vrp breaks simple loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59320 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org --- That is simple, accessing out of bounds element is undefined behavior and the compiler may optimize based on the fact that undefined behavior does not happen. As the upper bound is not constant, no warning is emitted on it, the compiler just assumes that in a valid program nd must be 2 before entering the loop.
[Bug libgomp/59337] New: surprising OMP error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59337 Bug ID: 59337 Summary: surprising OMP error message Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: Joost.VandeVondele at mat dot ethz.ch CC: jakub at gcc dot gnu.org cat test.f90 !$OMP ATOMIC i=-i END gfortran -fopenmp test.f90 test.f90:2.2: i=-i 1 Error: !$OMP ATOMIC assignment operator must be +, *, -, /, .AND., .OR., .EQV. or .NEQV. at (1) The caret is pointing at a '-', and the error message is saying it must be one. It appear that the proper way to write this is !$OMP ATOMIC i=0-i END but that is not so obvious from the error messsage. Maybe it could be worded as '... must be one of the binary operators '
[Bug tree-optimization/59163] [4.8/4.9 Regression] program compiled with g++ -O3 segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59163 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r190492.
[Bug tree-optimization/58253] IPA-SRA creates calls with different arguments that the callee accepts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58253
--- Comment #2 from rguenther at suse dot de rguenther at suse dot de ---
On Thu, 28 Nov 2013, jamborm at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58253
--- Comment #1 from Martin Jambor jamborm at gcc dot gnu.org ---
I do not quite understand why the port needs to look at alignments of
scalars passed by value at all but I assume there is a reason.
When it comes to the IPA-SRA created formal parameter and actual
argument in the pr52402.c testcase, the following happens. The
decision in which register pair the parameter is passed is made in
epiphany_function_arg_boundary. This is reached in two different
ways:
1. When compiling foo.isra.0, indirectly from call to
targetm.calls.function_incoming_arg at function.c:2440. The type
is the type of the PARM_DECL which is aligned to 8 bits.
2. When expanding the call in main, indirectly from call to
targetm.calls.function_arg. The type passed is the type of the
actual argument, which is an anonymous SSA name which has the
natural alignment of the node which is 64.
Thus, epiphany_function_arg_boundary erroneously comes to two
different conclusions. Assuming there is nothing wrong with the
above, we can fix the problem in IPA-SRA by the patch below which sets
the type of the PARM_DECL to natural mode alignment (bootstrapped and
tested and tested on x86_64-linux, the same on ppc64 is underway).
But again, I am not really sure what the semantics of alignment of
scalar PARM_DECL is. Nevertheless, can you please check if the patch
indeed fixes the bug? If so, I'll post it to the mailing list for
review/further discussion. Thanks.
2013-11-28 Martin Jambor mjam...@suse.cz
PR ipa/58253
* ipa-prop.c (ipa_modify_formal_parameters): Create decls of
non-BLKmode in their naturally aligned type.
diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c
index 6bdb0df..a26b11a 100644
--- a/gcc/ipa-prop.c
+++ b/gcc/ipa-prop.c
@@ -3443,7 +3443,15 @@ ipa_modify_formal_parameters (tree fndecl,
ipa_parm_adjustment_vec adjustments)
if (adj-by_ref)
ptype = build_pointer_type (adj-type);
else
-ptype = adj-type;
+{
+ ptype = adj-type;
+ if (TYPE_MODE (ptype) != BLKmode)
+{
+ unsigned malign = GET_MODE_ALIGNMENT (TYPE_MODE (ptype));
+ if (TYPE_ALIGN (ptype) malign)
+ptype = build_aligned_type (ptype, malign);
+}
+}
Isn't it easier to avoid building a type with different alignment
in the first place? Or do this adjustment in SRA where the bug
happens? It seems that when SRA representatives -type is unaligned
that this means, for by value passing, the value is accessed unaligned
in the caller only. Thus turn_representatives_into_adjustments
should go back to naturally aligned -type for !by_ref params.
Richard.
[Bug tree-optimization/59334] [4.9 Regression] r205486 caused many failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59334 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |4.9.0 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- I have a fix.
[Bug tree-optimization/59163] [4.8/4.9 Regression] program compiled with g++ -O3 segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59163
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org ---
Reduced testcase for -O3:
struct A { float a[4]; };
struct B { int b; A a; };
__attribute__((noinline, noclone)) void
bar (A a)
{
if (a.a[0] != 36.0f || a.a[1] != 42.0f || a.a[2] != 48.0f || a.a[3] != 54.0f)
__builtin_abort ();
}
__attribute__((noinline, noclone)) void
foo (A a)
{
int i;
A c = a;
for (i = 0; i 4; i++)
c.a[i] *= 6.0f;
a = c;
bar (a);
}
int
main ()
{
B b = { 5, { 6, 7, 8, 9 } };
foo (b.a);
}
[Bug target/59163] [4.8/4.9 Regression] program compiled with g++ -O3 segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59163 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Target||x86_64-*-* Component|tree-optimization |target --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- target issue then?
[Bug libgomp/59337] surprising OMP error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59337 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- I wonder why atomic negate isn't possible - from a QOI perspective treating it as 0 - i would be obvious, no?
[Bug tree-optimization/59336] [4.9 Regression] definition in block 317 does not dominate use in block 316
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59336 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Component|middle-end |tree-optimization Target Milestone|--- |4.9.0 Summary|definition in block 317 |[4.9 Regression] definition |does not dominate use in|in block 317 does not |block 316 |dominate use in block 316 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- I suppose it doesn't happen without LTO?
[Bug middle-end/59208] [4.9 Regression] ice in initialize_flags_in_bb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59208 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Jan Hubicka from comment #7) Created attachment 31322 [details] Proposed fix I am testing Hi, the problem here is that update_stmt is called with cfun being set to NULL. It uses ssa_operands_active (cfun) call that return false. This patch makes us to set cfun correctly when updating the function body. It may be interesting to investigate why some testcases fails on PPC and not on x86 - they may be cases where we missed devirtualization during early optimization but for whatever reason we now handle it during IPA Honza Argh. I'll try to add a update_stmt_fn.
[Bug middle-end/59338] New: error: position plus size exceeds size of referenced object in BIT_FIELD_REF
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59338
Bug ID: 59338
Summary: error: position plus size exceeds size of referenced
object in BIT_FIELD_REF
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.sm...@alcatel-lucent.com
minimal.i: In function 'test':
minimal.i:20:6: error: position plus size exceeds size of referenced object in
BIT_FIELD_REF
void test(void)
^
BIT_FIELD_REF *qResp, 8, 32
minimal.i:23:28: note: in statement
if (qResp-u.l[0].More == 0)
^
D.1802 = BIT_FIELD_REF *qResp, 8, 32;
minimal.i:20:6: internal compiler error: verify_gimple failed
void test(void)
^
typedef enum
{
XYZZY,
} enumType;
typedef struct
{
unsigned char More : 1;
} tResp;
typedef struct
{
enumType QueryType;
union
{
tResp l[0];
} u;
} tQResp;
void test(void)
{
tQResp *qResp = (0);
if (qResp-u.l[0].More == 0)
return;
}
[Bug middle-end/59208] [4.9 Regression] ice in initialize_flags_in_bb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59208 --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- Created attachment 31324 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31324action=edit patch Like this.
[Bug c/59332] Segmentation fault in inline_summary with LTO + attribute optimize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59332 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords|ice-on-valid-code, lto |accepts-invalid, ||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-11-29 Component|lto |c Ever confirmed|0 |1 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- I don't think that will ever work ;) Thus the bug is that we accept no-lto as argument to optimize(). Thus, confirmed.
[Bug middle-end/59338] [4.9 Regression] error: position plus size exceeds size of referenced object in BIT_FIELD_REF
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59338 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-11-29 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |4.9.0 Summary|error: position plus size |[4.9 Regression] error: |exceeds size of referenced |position plus size exceeds |object in BIT_FIELD_REF |size of referenced object ||in BIT_FIELD_REF Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed. I'll adjust the checking to be less conservative (trailing array happening here and fold going nuts in creating BIT_FIELD_REFs).
[Bug libgomp/59337] surprising OMP error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59337 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- The standard doesn't allow it, and given the parsing complexities of the atomics creating extensions there is IMHO undesirable, especially when it will unlikely work with other compilers. Because the standard explicitly lists the operators that can be used, I'd just do s/must be /must be binary / in the message.
[Bug libgcc/59339] New: vtable_verify objects still trying to be linked on Android
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59339 Bug ID: 59339 Summary: vtable_verify objects still trying to be linked on Android Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: laguest at archeia dot com Created attachment 31325 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31325action=edit Original make -j4 log When attempting to build gcc svn trunk arm-linux-androideabi target, it still looking for vtv_*.o even though it's disabled, if enabling the other libraries I have disabled, it does so there too. [code] make[4]: Entering directory `/home/laguest/src/mine/tinyada-new/build/android/arm/gcc/arm-linux-androideabi/armv7-a/libgcc' # If this is the top-level multilib, build all the other # multilibs. # Early copyback; see all above for the rationale. The # early copy is necessary so that the gcc -B options find # the right startup files when linking shared libgcc. /bin/sh ../../../../../../../source/gcc-trunk/libgcc/../mkinstalldirs ../../.././gcc/armv7-a parts=crtbegin.o crtbeginS.o crtbeginT.o crtend.o crtendS.o vtv_start.o vtv_end.o vtv_start_preinit.o vtv_end_preinit.o; \ for file in $parts; do \ rm -f ../../.././gcc/armv7-a/$file; \ /usr/bin/install -c -m 644 $file ../../.././gcc/armv7-a/; \ case $file in \ *.a)\ /home/laguest/opt/android-tinyada/arm-linux-androideabi/bin/ranlib ../../.././gcc/armv7-a/$file ;;\ esac; \ done /usr/bin/install: cannot stat `vtv_start.o': No such file or directory /usr/bin/install: cannot stat `vtv_end.o': No such file or directory /usr/bin/install: cannot stat `vtv_start_preinit.o': No such file or directory /usr/bin/install: cannot stat `vtv_end_preinit.o': No such file or directory dest=../../.././gcc/include/tmp$$-unwind.h; \ cp unwind.h $dest; \ chmod a+r $dest; \ sh ../../../../../../../source/gcc-trunk/libgcc/../move-if-change $dest ../../.././gcc/include/unwind.h [/code] System: uname -a Linux rogue 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux The configure line: CC=/opt/gcc-4.6-links/bin/gcc CXX=/opt/gcc-4.6-links/bin/g++ CP=/opt/gcc-4.6-links/bin/cpp ../../../../source/gcc-trunk/configure --prefix=/home/laguest/opt/android-tinyada --target=arm-linux-androideabi --host=x86_64-linux-gnu --build=x86_64-linux-gnu --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-float=soft --with-fpu=vfp --with-arch=armv5te --enable-multilib --enable-threads --disable-shared --with-gnu-as --with-gnu-ld --enable-languages=c,c++,ada --with-system-zlib --disable-libgomp --without-libffi --without-libiconv-prefix --disable-libmudflap --disable-nls --disable-libstdcxx-pch --disable-cloog-version-check --disable-isl-version-check --with-gmp=/home/laguest/opt/android-tinyada --with-mpfr=/home/laguest/opt/android-tinyada --with-mpc=/home/laguest/opt/android-tinyada --with-isl=/home/laguest/opt/android-tinyada --with-cloog=/home/laguest/opt/android-tinyada --disable-libstdc__-v3 --disable-tls --disable-libitm --enable-target-optspace --enable-initfini-array --with-sysroot=/home/laguest/opt/android-ndk-r9b/platforms/android-9/arch-arm --with-python=/home/laguest/opt/android-ndk-r9b/prebuilt/linux-x86_64/bin/python-config --enable-plugins --enable-eh-frame-hdr-for-static --disable-libsanitizer --disable-libquadmath --disable-libssp --disable-libatomic 21|tee log.config.txt
[Bug libgcc/59339] vtable_verify objects still trying to be linked on Android
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59339 --- Comment #1 from Luke A. Guest laguest at archeia dot com --- Toolchain I'm using: gcc version 4.6.3 (Debian 4.6.3-14) This is the Ada enabled one.
[Bug target/59163] [4.8/4.9 Regression] program compiled with g++ -O3 segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59163
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||uros at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org ---
Looks like it, yes.
In *.jump we still have (IMHO correct):
(insn 2 4 3 2 (set (reg/v/f:DI 89 [ a ])
(reg:DI 5 di [ a ])) pr59163-2.C:13 85 {*movdi_internal}
(nil))
(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
(insn 6 3 7 2 (set (reg:TI 90)
(mem:TI (reg/v/f:DI 89 [ a ]) [3 MEM[(const struct A )a_4(D)]+0 S16
A32])) pr59163-2.C:15 84 {*movti_internal}
(nil))
(insn 7 6 8 2 (set (mem/c:TI (plus:DI (reg/f:DI 20 frame)
(const_int -16 [0xfff0])) [3 c+0 S16 A128])
(reg:TI 90)) pr59163-2.C:15 84 {*movti_internal}
(nil))
...
(insn 9 8 10 2 (set (reg:V4SF 91 [ vect__7.10 ])
(mult:V4SF (reg:V4SF 92)
(mem/c:V4SF (plus:DI (reg/f:DI 20 frame)
(const_int -16 [0xfff0])) [2 MEM[(float *)c]+0
S16 A128]))) pr59163-2.C:17 1269 {*mulv4sf3}
(nil))
movti_internal handles unaligned loads properly.
Then *.dse1 transforms this into:
(insn 6 3 18 2 (set (reg:TI 90 [ MEM[(const struct A )a_4(D)] ])
(mem:TI (reg/v/f:DI 89 [ a ]) [3 MEM[(const struct A )a_4(D)]+0 S16
A32])) pr59163-2.C:15 84 {*movti_internal}
(nil))
(insn 18 6 8 2 (set (reg:V4SF 94)
(subreg:V4SF (reg:TI 90 [ MEM[(const struct A )a_4(D)] ]) 0))
pr59163-2.C:15 -1
(expr_list:REG_DEAD (reg:TI 90 [ MEM[(const struct A )a_4(D)] ])
(nil)))
...
(insn 9 8 19 2 (set (reg:V4SF 91 [ vect__7.10 ])
(mult:V4SF (reg:V4SF 92)
(reg:V4SF 94))) pr59163-2.C:17 1269 {*mulv4sf3}
(expr_list:REG_DEAD (reg:V4SF 94)
(expr_list:REG_DEAD (reg:V4SF 92)
(nil
which also looks ok to me. But then combine combines it into:
(insn 9 8 19 2 (set (reg:V4SF 91 [ vect__7.10 ])
(mult:V4SF (reg:V4SF 92)
(mem:V4SF (reg/v/f:DI 89 [ a ]) [3 MEM[(const struct A )a_4(D)]+0
S16 A32]))) pr59163-2.C:17 1269 {*mulv4sf3}
(expr_list:REG_DEAD (reg:V4SF 92)
(nil)))
which is wrong (for pre-AVX), because mulv4sf3 can't accept unaligned memory.
Likely the SSEx pre-AVX predicates assume that an unaligned vector load will be
done using UNSPEC and thus not really mergeable here, and don't count with the
fact that the load could be done using integral mode and just subreged into
vector mode. Perhaps we need new predicates for this that would fail for
exactly this situation (disallow unaligned scalar load subregged into vector
mode for pre-AVX) and use them everywhere where SSE? doesn't accept unaligned
loads?
[Bug libgcc/59339] vtable_verify objects still trying to be linked on Android
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59339 --- Comment #2 from Luke A. Guest laguest at archeia dot com --- I also don't think this should be adding the following the parts either: parts=crtbegin.o crtbeginS.o crtbeginT.o crtend.o crtendS.o
[Bug middle-end/59338] [4.9 Regression] error: position plus size exceeds size of referenced object in BIT_FIELD_REF
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59338 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Confirmed. I'll adjust the checking to be less conservative (trailing array happening here and fold going nuts in creating BIT_FIELD_REFs). I'm interested :-) but I don't know whether this will be sufficient for Ada.
[Bug lto/59326] FAIL: gcc.dg/vect/vect-simd-clone-*.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59326 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Fri Nov 29 10:36:10 2013 New Revision: 205512 URL: http://gcc.gnu.org/viewcvs?rev=205512root=gccview=rev Log: PR lto/59326 * tree-core.h (enum omp_clause_schedule_kind): Add OMP_CLAUSE_SCHEDULE_LAST. (enum omp_clause_default_kind): Add OMP_CLAUSE_DEFAULT_LAST. (enum omp_clause_depend_kind): Add OMP_CLAUSE_DEPEND_LAST. (enum omp_clause_map_kind): Add OMP_CLAUSE_MAP_LAST. (enum omp_clause_proc_bind_kind): Add OMP_CLAUSE_PROC_BIND_LAST. * lto-streamer-out.c (lto_is_streamable): Allow streaming OMP_CLAUSE. (DFS_write_tree_body): Handle OMP_CLAUSE. * tree-streamer-out.c (pack_ts_omp_clause_value_fields): New function. (streamer_pack_tree_bitfields): Call it for OMP_CLAUSE. (write_ts_omp_clause_tree_pointers): New function. (streamer_write_tree_body): Call it for OMP_CLAUSE. (streamer_write_tree_header): For OMP_CLAUSE stream OMP_CLAUSE_CODE. * tree-streamer-in.c (unpack_ts_omp_clause_value_fields): New function. (unpack_value_fields): Call it for OMP_CLAUSE. (streamer_alloc_tree): Handle OMP_CLAUSE. (lto_input_ts_omp_clause_tree_pointers): New function. (streamer_read_tree_body): Call it for OMP_CLAUSE. lto/ * lto.c (mentions_vars_p_omp_clause): New function. (mentions_vars_p): Call it for OMP_CLAUSE. Remove break; after return stmts. Modified: trunk/gcc/ChangeLog trunk/gcc/lto-streamer-out.c trunk/gcc/lto/ChangeLog trunk/gcc/lto/lto.c trunk/gcc/tree-core.h trunk/gcc/tree-streamer-in.c trunk/gcc/tree-streamer-out.c
[Bug lto/59326] FAIL: gcc.dg/vect/vect-simd-clone-*.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59326 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Fri Nov 29 10:41:12 2013 New Revision: 205514 URL: http://gcc.gnu.org/viewcvs?rev=205514root=gccview=rev Log: PR lto/59326 * omp-low.c (simd_clone_create): Return NULL if for definition !cgraph_function_with_gimple_body_p (old_node). Call cgraph_get_body before calling cgraph_function_versioning. (expand_simd_clones): Look for omp declare simd attribute first. Don't check targetm.simd_clone.compute_vecsize_and_simdlen here. Punt if node-global.inlined_to. (pass_omp_simd_clone::gate): Also enable if in_lto_p !flag_wpa. Disable pass if targetm.simd_clone.compute_vecsize_and_simdlen is NULL. * lto-streamer-out.c (hash_tree): Handle OMP_CLAUSE. lto/ * lto.c (compare_tree_sccs_1): Handle OMP_CLAUSE. testsuite/ * gcc.dg/vect/vect-simd-clone-12.c: New test. * gcc.dg/vect/vect-simd-clone-12a.c: New test. * gcc.dg/vect/vect-simd-clone-10a.c: Remove extern keywords. Added: trunk/gcc/testsuite/gcc.dg/vect/vect-simd-clone-12.c trunk/gcc/testsuite/gcc.dg/vect/vect-simd-clone-12a.c Modified: trunk/gcc/ChangeLog trunk/gcc/lto-streamer-out.c trunk/gcc/lto/ChangeLog trunk/gcc/lto/lto.c trunk/gcc/omp-low.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/vect-simd-clone-10a.c
[Bug tree-optimization/59334] [4.9 Regression] r205486 caused many failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59334 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Fri Nov 29 10:47:52 2013 New Revision: 205515 URL: http://gcc.gnu.org/viewcvs?rev=205515root=gccview=rev Log: 2013-11-29 Richard Biener rguent...@suse.de PR tree-optimization/59334 * tree-ssa-dce.c (eliminate_unnecessary_stmts): Fix bug in previous commit. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-dce.c
[Bug tree-optimization/59334] [4.9 Regression] r205486 caused many failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59334 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug middle-end/59330] [4.7/4.8 Regression] Crash in is_gimple_reg_type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59330 Bug 59330 depends on bug 59334, which changed state. Bug 59334 Summary: [4.9 Regression] r205486 caused many failures http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59334 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug rtl-optimization/59340] New: LRA enable-checking bootstrap failure since r205136
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59340
Bug ID: 59340
Summary: LRA enable-checking bootstrap failure since r205136
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: krebbel at gcc dot gnu.org
The following code has been added to s390_decompose_address for the LRA
enablement to prevent strict displacement checking for addresses including
eliminable registers. Only during LRA execution the displacements are expected
to be valid.
199754 vmakarov if (lra_in_progress
199754 vmakarov || (base != arg_pointer_rtx
199754 vmakarov indx != arg_pointer_rtx
199754 vmakarov base != return_address_pointer_rtx
199754 vmakarov indx != return_address_pointer_rtx
199754 vmakarov base != frame_pointer_rtx
199754 vmakarov indx != frame_pointer_rtx
199754 vmakarov base != virtual_stack_vars_rtx
199754 vmakarov indx != virtual_stack_vars_rtx))
However, with:
Author: law
Date: Wed Nov 20 18:17:49 2013
New Revision: 205136
URL: http://gcc.gnu.org/viewcvs?rev=205136root=gccview=rev
Log:
* lra.c (lra): Set lra_in_progress before check_rtl call.
* recog.c (insn_invalid_p): Add !lra_in_progress to prevent
adding clobber regs when LRA is running
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra.c
trunk/gcc/recog.c
the lra_in_progress = 1; statement has been moved before the initial LRA
check_rtl invokation so s390_decompose_address now expects the displacements to
be valid already what obviously is not the case.
This leads to a bootstrap failure:
/home/andreas/patched/gcc-head/libgcc/libgcc2.c: In function ‘__mulsc3’:
/home/andreas/patched/gcc-head/libgcc/libgcc2.c:1932:1: error: insn does not
satisfy its constraints:
}
^
(insn 21 26 23 2 (set (mem/c:SF (plus:DI (reg/f:DI 34 %fp)
(const_int -16 [0xfff0])) [2 ac+0 S4 A64])
(reg:SF 108 [ D.5596 ]))
/home/andreas/patched/gcc-head/libgcc/libgcc2.c:1874 88 {movsf}
(expr_list:REG_DEAD (reg:SF 108 [ D.5596 ])
(nil)))
/home/andreas/patched/gcc-head/libgcc/libgcc2.c:1932:1: internal compiler
error: in check_rtl, at lra.c
:2043
It can easily be reproduced with:
cc1 -O0 t.c
t.c:
void foo (int a) {}
[Bug ada/58239] [4.9 regression] pretty-print.c:789: undefined reference to `operator delete(void*)'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58239 Luke A. Guest laguest at archeia dot com changed: What|Removed |Added CC||laguest at archeia dot com --- Comment #19 from Luke A. Guest laguest at archeia dot com --- I think this fix has been reverted somewhere in source as I've just got trunk from SVN and have had to patch by hand.
[Bug preprocessor/58844] [4.8/4.9 Regression] ICE with invalid use of ##
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58844 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||dodji at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Doesn't ICE with -ftrack-macro-expansion=0, so regressed with r186977 which made -ftrack-macro-expansion=2 the default, before that it crashed with explicit -ftrack-macro-expansion=2. Dodji, can you please have a look?
[Bug ada/58239] [4.9 regression] pretty-print.c:789: undefined reference to `operator delete(void*)'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58239 --- Comment #20 from Eric Botcazou ebotcazou at gcc dot gnu.org --- I think this fix has been reverted somewhere in source as I've just got trunk from SVN and have had to patch by hand. It's very easy to check, the patch is linked from comment #17...
[Bug middle-end/59208] [4.9 Regression] ice in initialize_flags_in_bb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59208 --- Comment #10 from Jan Hubicka hubicka at ucw dot cz --- Argh. I'll try to add a update_stmt_fn. Yep, would make life easier ;) Honza
[Bug rtl-optimization/59340] [4.9 Regression] LRA enable-checking bootstrap failure since r205136
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59340 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-checking Target||s390x-*-* Target Milestone|--- |4.9.0 Summary|LRA enable-checking |[4.9 Regression] LRA |bootstrap failure since |enable-checking bootstrap |r205136 |failure since r205136
[Bug tree-optimization/58253] IPA-SRA creates calls with different arguments that the callee accepts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58253 --- Comment #3 from Martin Jambor jamborm at gcc dot gnu.org --- (In reply to rguent...@suse.de from comment #2) Isn't it easier to avoid building a type with different alignment in the first place? Or do this adjustment in SRA where the bug happens? It seems that when SRA representatives -type is unaligned that this means, for by value passing, the value is accessed unaligned in the caller only. Thus turn_representatives_into_adjustments should go back to naturally aligned -type for !by_ref params. That's what the first version of my patch did :-) The problem with it is that the alignment of the type in adjustment is how ipa_modify_call_arguments figures out it needs to build unaligned loads in the caller and so those types need to stay unaligned and only ipa_modify_formal_parameters needs to be taught to ignore that. BTW, now I wonder whether it would make more sense to check for is_gimple_reg_type instead of non-BLKmode-ness with perhaps the latter asserted. Arguably, the actual arguments are (formally well aligned) SSA names because their type is a gimple register.
[Bug tree-optimization/58253] IPA-SRA creates calls with different arguments that the callee accepts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58253 --- Comment #4 from Martin Jambor jamborm at gcc dot gnu.org --- (In reply to rguent...@suse.de from comment #2) Isn't it easier to avoid building a type with different alignment in the first place? Or do this adjustment in SRA where the bug happens? It seems that when SRA representatives -type is unaligned that this means, for by value passing, the value is accessed unaligned in the caller only. Thus turn_representatives_into_adjustments should go back to naturally aligned -type for !by_ref params. That's what the first version of my patch did :-) The problem with it is that the alignment of the type in adjustment is how ipa_modify_call_arguments figures out it needs to build unaligned loads in the caller, so those types need to stay unaligned and only ipa_modify_formal_parameters needs to be taught to ignore that. BTW, now I wonder whether it would make more sense to check for is_gimple_reg_type instead of non-BLKmode-ness with perhaps the latter asserted. Arguably, the actual arguments are (formally well aligned) SSA names because their type is a gimple register.
[Bug tree-optimization/59336] [4.9 Regression] definition in block 317 does not dominate use in block 316
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59336 --- Comment #3 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Richard Biener from comment #2) I suppose it doesn't happen without LTO? correct.
[Bug ada/59341] New: spark_05 No_Implicit_Aliasing undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59341 Bug ID: 59341 Summary: spark_05 No_Implicit_Aliasing undefined Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: laguest at archeia dot com /usr/bin/gcc-4.6 -c -I./ -I/usr/lib/gcc/x86_64-linux-gnu/4.6/adalib/../adainclude -I/usr/lib/gcc/x86_64-linux-gnu/4.6/adalib/ -I. -I/home/laguest/src/mine/tinyada-new/source/gcc-trunk/gcc/ada -g -O2 -W -Wall -gnatpg -gnata -I- /home/laguest/src/mine/tinyada-new/downloads/gcc-trunk/gcc/ada/ali-util.adb scng.adb:1797:47: SPARK_05 is undefined restrict.ads:126:07: No_Implicit_Aliasing is undefined $ uname -a Linux rogue 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux CC=/usr/bin/gcc-4.6 CXX=/usr/bin/g++-4.6 CP=/usr/bin/cpp-4.6 ../../../../source/gcc-trunk/configure --prefix=/home/laguest/opt/android-tinyada --target=arm-linux-androideabi --host=x86_64-linux-gnu --build=x86_64-linux-gnu --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-float=soft --with-fpu=vfp --with-arch=armv5te --enable-multilib --enable-threads --disable-shared --with-gnu-as --with-gnu-ld --enable-languages=c,c++,ada --with-system-zlib --disable-libgomp --without-libffi --without-libiconv-prefix --disable-libmudflap --disable-nls --disable-libstdcxx-pch --disable-cloog-version-check --disable-isl-version-check --with-gmp=/home/laguest/opt/android-tinyada --with-mpfr=/home/laguest/opt/android-tinyada --with-mpc=/home/laguest/opt/android-tinyada --with-isl=/home/laguest/opt/android-tinyada --with-cloog=/home/laguest/opt/android-tinyada --disable-libstdc__-v3 --disable-tls --disable-libitm --enable-target-optspace --enable-initfini-array --with-sysroot=/home/laguest/opt/android-ndk-r9b/platforms/android-9/arch-arm --with-python=/home/laguest/opt/android-ndk-r9b/prebuilt/linux-x86_64/bin/python-config --enable-plugins --enable-eh-frame-hdr-for-static --disable-libsanitizer --disable-libquadmath --disable-libssp --disable-libatomic
[Bug tree-optimization/58253] IPA-SRA creates calls with different arguments that the callee accepts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58253 --- Comment #5 from rguenther at suse dot de rguenther at suse dot de --- On Fri, 29 Nov 2013, jamborm at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58253 --- Comment #3 from Martin Jambor jamborm at gcc dot gnu.org --- (In reply to rguent...@suse.de from comment #2) Isn't it easier to avoid building a type with different alignment in the first place? Or do this adjustment in SRA where the bug happens? It seems that when SRA representatives -type is unaligned that this means, for by value passing, the value is accessed unaligned in the caller only. Thus turn_representatives_into_adjustments should go back to naturally aligned -type for !by_ref params. That's what the first version of my patch did :-) The problem with it is that the alignment of the type in adjustment is how ipa_modify_call_arguments figures out it needs to build unaligned loads in the caller and so those types need to stay unaligned and only ipa_modify_formal_parameters needs to be taught to ignore that. ;) BTW, now I wonder whether it would make more sense to check for is_gimple_reg_type instead of non-BLKmode-ness with perhaps the latter asserted. Arguably, the actual arguments are (formally well aligned) SSA names because their type is a gimple register. Well - how an actual PARM_DECL passed by value ends up being aligned is up to the target, independent of whether it will be an SSA register or an aggregate. But we certainly should make the life of the targets easier by using natural alignment when inventing new pass-by-value PARM_DECLs. Richard.
[Bug libgomp/59337] surprising OMP error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59337 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #3 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Jakub Jelinek from comment #2) creating extensions there is IMHO undesirable, especially when it will unlikely work with other compilers. I agree with that, the compilers I tested all rejected this. I think it is a flaw in the standard.
[Bug middle-end/59338] [4.9 Regression] error: position plus size exceeds size of referenced object in BIT_FIELD_REF
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59338 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug middle-end/59338] [4.9 Regression] error: position plus size exceeds size of referenced object in BIT_FIELD_REF
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59338 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Fri Nov 29 12:09:12 2013 New Revision: 205521 URL: http://gcc.gnu.org/viewcvs?rev=205521root=gccview=rev Log: 2013-11-29 Richard Biener rguent...@suse.de PR middle-end/59338 * tree-cfg.c (verify_expr): Restrict bounds verification of BIT_FIELD_REF arguments to non-aggregate typed base objects. * gcc.dg/torture/pr59338.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr59338.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c
[Bug ada/59341] spark_05 No_Implicit_Aliasing undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59341 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- gcc-4.6 is no longer supported.
[Bug sanitizer/59063] [4.9 Regression] ASAN: segfault in __interceptor_clock_gettime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59063 --- Comment #21 from ygribov at gcc dot gnu.org --- Author: ygribov Date: Fri Nov 29 12:30:36 2013 New Revision: 205524 URL: http://gcc.gnu.org/viewcvs?rev=205524root=gccview=rev Log: gcc/ 2013-11-29 Jakub Jelinek ja...@redhat.com Yury Gribov y.gri...@samsung.com PR sanitizer/59063 * config/gnu-user.h: Removed old code for setting up sanitizer libs. * gcc.c: Using libsanitizer spec instead of explicit libs. gcc/testsuite/ 2013-11-29 Jakub Jelinek ja...@redhat.com Yury Gribov y.gri...@samsung.com PR sanitizer/59063 * c-c++-common/asan/pr59063-1.c: New test. * c-c++-common/asan/pr59063-2.c: Likewise. * lib/asan-dg.exp: Add path to libsanitizer.spec to cflags. * lib/ubsan-dg.exp: Likewise. libsanitizer/ 2013-11-29 Jakub Jelinek ja...@redhat.com Yury Gribov y.gri...@samsung.com PR sanitizer/59063 * libsanitizer.spec.in: Add spec file to hold link flags for various sanitizer libs. * configure.ac: Check whether clock_* routines come from librt. * asan/Makefile.am (libasan_la_LDFLAGS): Libs now come from configure.ac. * tsan/Makefile.am (libtsan_la_LDFLAGS): Likewise. * ubsan/Makefile.am (libubsan_la_LDFLAGS): Likewise. * lsan/Makefile.am (liblsan_la_LDFLAGS): Likewise. * asan/Makefile.in: Regenerate. * interception/Makefile.in: Regenerate. * lsan/Makefile.in: Regenerate. * sanitizer_common/Makefile.in: Regenerate. * tsan/Makefile.in: Regenerate. * ubsan/Makefile.in: Regenerate. * Makefile.in: Regenerate. * configure: Regenerate. Added: trunk/gcc/testsuite/c-c++-common/asan/pr59063-1.c trunk/gcc/testsuite/c-c++-common/asan/pr59063-2.c trunk/libsanitizer/libsanitizer.spec.in Modified: trunk/gcc/ChangeLog trunk/gcc/config/gnu-user.h trunk/gcc/gcc.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/asan-dg.exp trunk/gcc/testsuite/lib/ubsan-dg.exp trunk/libsanitizer/ChangeLog trunk/libsanitizer/Makefile.am trunk/libsanitizer/Makefile.in trunk/libsanitizer/asan/Makefile.am trunk/libsanitizer/asan/Makefile.in trunk/libsanitizer/configure trunk/libsanitizer/configure.ac trunk/libsanitizer/interception/Makefile.in trunk/libsanitizer/lsan/Makefile.am trunk/libsanitizer/lsan/Makefile.in trunk/libsanitizer/sanitizer_common/Makefile.in trunk/libsanitizer/tsan/Makefile.am trunk/libsanitizer/tsan/Makefile.in trunk/libsanitizer/ubsan/Makefile.am trunk/libsanitizer/ubsan/Makefile.in
[Bug sanitizer/59063] [4.9 Regression] ASAN: segfault in __interceptor_clock_gettime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59063 --- Comment #22 from Yury Gribov y.gribov at samsung dot com --- Joost, could you check and close bug if trunk works for you?
[Bug ada/59341] spark_05 No_Implicit_Aliasing undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59341 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot gnu.org Resolution|--- |INVALID --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org --- As documented, you need first to build a native compiler and then use this compiler to build the cross-compiler.
[Bug sanitizer/59063] [4.9 Regression] ASAN: segfault in __interceptor_clock_gettime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59063 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #23 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- Thanks, fixed!
[Bug c++/58089] expanding empty parameter pack as constructor arguments requires accessible copy constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58089
Andrey Zholos a...@q-fu.com changed:
What|Removed |Added
CC||a...@q-fu.com
--- Comment #2 from Andrey Zholos a...@q-fu.com ---
I also stumbled onto this bug, and bug 59141 is a duplicate.
It appears the empty parameter pack is expanded as t({}) rather than t().
There is a similar example in 14.5.3p6 that indicates obj should be value-
initialized (not copy-constructed), and clang accepts this code.
[Bug target/59163] [4.8/4.9 Regression] program compiled with g++ -O3 segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59163 --- Comment #6 from Uroš Bizjak ubizjak at gmail dot com --- I think that we should disallow tie of TImode with 128bit vector modes due to different alignment requirements. Integer register pairs can load unaligned TImode without problems, while unaligned TImode will crash SSE insns. Following patch fixes the problem: Index: config/i386/i386.c === --- config/i386/i386.c (revision 205509) +++ config/i386/i386.c (working copy) @@ -35237,6 +35237,7 @@ ix86_modes_tieable_p (enum machine_mode mode1, enu return (GET_MODE_SIZE (mode1) == 32 ix86_hard_regno_mode_ok (FIRST_SSE_REG, mode1)); if (GET_MODE_SIZE (mode2) == 16 + !(mode1 == TImode || mode2 == TImode) ix86_hard_regno_mode_ok (FIRST_SSE_REG, mode2)) return (GET_MODE_SIZE (mode1) == 16 ix86_hard_regno_mode_ok (FIRST_SSE_REG, mode1)); However, it needs some refinements for AVX.
[Bug target/58864] [4.8/4.9 regression] ICE in connect_traces, at dwarf2cfi.c:NNNN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58864 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 31326 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31326action=edit gcc49-pr58864.patch Untested fix. Note looking around at other callers of emit_conditional_move, I think there are other suspect places, in particular emit_store_flag and expand_doubleword_shift. ifcvt.c should be fine, because no stack adjustments should be pending after expansion.
[Bug c/59309] FAIL: c-c++-common/cilk-plus/CK/spawnee_inline.c -g -fcilkplus (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59309 --- Comment #4 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org --- Author: hjl Date: Fri Nov 29 13:00:35 2013 New Revision: 205525 URL: http://gcc.gnu.org/viewcvs?rev=205525root=gccview=rev Log: Properly handle function without arguments PR c/59309 * cilk.c (gimplify_cilk_spawn): Properly handle function without arguments. Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/cilk.c
[Bug c/59332] Segmentation fault in inline_summary with LTO + attribute optimize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59332 --- Comment #4 from Dmitry Gorbachev d.g.gorbachev at gmail dot com --- Can you expand on those shortcomings/bugs? There are LTO-related issues in GCC and LD, such as PR43038, PR56536 and others. Not all problems will be fixed soon, and more bugs will be discovered in the future. As a workaround, an attribute (a pragma) to disable LTO would come in handy. I don't think that will ever work ;) __attribute__((optimize(lto))) works, surprisingly!
[Bug c/59332] Segmentation fault in inline_summary with LTO + attribute optimize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59332 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- (In reply to Dmitry Gorbachev from comment #4) __attribute__((optimize(lto))) works, surprisingly! I wonder whether that's intentional or just pure luck ;).
[Bug c/59309] FAIL: c-c++-common/cilk-plus/CK/spawnee_inline.c -g -fcilkplus (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59309 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from H.J. Lu hjl.tools at gmail dot com --- Fixed.
[Bug libstdc++/54316] [C++11] move constructor for string_stream
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54316 Jaak Ristioja jaak at ristioja dot ee changed: What|Removed |Added CC||jaak at ristioja dot ee --- Comment #4 from Jaak Ristioja jaak at ristioja dot ee --- Any progress?
[Bug target/59163] [4.8/4.9 Regression] program compiled with g++ -O3 segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59163 --- Comment #7 from Uroš Bizjak ubizjak at gmail dot com --- Maybe even better idea is to use ix86_legitimate_combined_insn and reject combinations that would result in unaligned operands of all but vector move instructions.
[Bug c++/59342] New: Function Template Specialisation causing compiler error together with using clauses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59342
Bug ID: 59342
Summary: Function Template Specialisation causing compiler
error together with using clauses
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: filipe.c.maia at gmail dot com
The following code causes a compilation error:
namespace bar
{
void f(char x){;}
}
namespace foo
{
// If the using clause is here; no error
// using bar::f;
template typename T void f(T x);
template void f(int x);
// With the using clause is here; error
using bar::f;
template typename T void f(T x){; }
template void f(int x){ ; }
}
g++-4.8 -c namespace_noheader.cpp
namespace_noheader.cpp:17:27: error: 'void foo::f(int)' is not declared in
'foo'
template void f(int x){ ; }
^
I've also tried with newer versions online with the same result.
Moving the using line up makes the problem go away.
[Bug target/59343] New: miscompiled for loop in sh4 target (-Os)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59343 Bug ID: 59343 Summary: miscompiled for loop in sh4 target (-Os) Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: gcc-bugzilla-f5d8 at theblacksun dot eu Created attachment 31327 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31327action=edit miscompilation testcase The attached testcase miscompiles on sh4 target if build with -Os $ sh4-unknown-linux-gnu-g++ -Wall -Wextra -o for_loop_miscompile_O2 -O2 for_loop_miscompile.cpp $ sh4-unknown-linux-gnu-g++ -Wall -Wextra -o for_loop_miscompile_Os -Os for_loop_miscompile.cpp target $ ./for_loop_miscompile_O2 teststring = 0x411068 teststring = 0x411068 target $ ./for_loop_miscompile_Os teststring = 0x411068 teststring = 0x1
[Bug target/58864] [4.8/4.9 regression] ICE in connect_traces, at dwarf2cfi.c:NNNN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58864 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 31328 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31328action=edit gcc49-pr58864.patch Alternate patch. Rather than doing do_pending_stack_adjust () everywhere just in case emit_conditional_move could be called and it's insns removed, this allows remember current pending_stack_adjust state and restore it if we decide to delete the insns.
[Bug target/59343] miscompiled for loop in sh4 target (-Os)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59343 --- Comment #2 from gcc-bugzilla-f5d8 at theblacksun dot eu --- Created attachment 31330 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31330action=edit assembler output from -O2
[Bug target/59343] miscompiled for loop in sh4 target (-Os)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59343 --- Comment #1 from gcc-bugzilla-f5d8 at theblacksun dot eu --- Created attachment 31329 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31329action=edit assembler output from -Os
[Bug c/59332] Segmentation fault in inline_summary with LTO + attribute optimize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59332 --- Comment #6 from Dmitry Gorbachev d.g.gorbachev at gmail dot com --- It was discovered by accident. However, if it does work, why no-lto (which is so much more useful) should not work?
[Bug fortran/59344] New: warning for needless pointer attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59344 Bug ID: 59344 Summary: warning for needless pointer attribute Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Joost.VandeVondele at mat dot ethz.ch In many cases, using variables with a POINTER attribute is neither necessary nor beneficial. I wonder if the Fortran FE could generate a warning for variables with the POINTER attribute that could as well be ALLOCATABLE without changing the semantics of the program. my guess would be that it is sufficient to track if a local variables with the pointer attribute has been 1) part of a pointer assignment (lhs/rhs) 2) passed to a procedure with an explicit interface and pointer attribute 3) ? Such a warning would be useful to clean codes of pointer 'abuse'
[Bug fortran/59345] New: _gfortran_internal_pack on compiler generated temps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59345 Bug ID: 59345 Summary: _gfortran_internal_pack on compiler generated temps Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: Joost.VandeVondele at mat dot ethz.ch There is a missed optimization on compiler generated temporaries. Basically: SUBROUTINE S1(A) REAL :: A(3) CALL S2(-A) END SUBROUTINE leads to an optimized tree that contains calls to _gfortran_internal_pack _gfortran_internal_unpack __builtin_free which should not be needed as generated temps are known to be contiguous (in particular in this case, where it is generated on the stack). This would help to fully resolve PR38318 .
[Bug middle-end/59208] [4.9 Regression] ice in initialize_flags_in_bb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59208 --- Comment #11 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Fri Nov 29 14:37:07 2013 New Revision: 205528 URL: http://gcc.gnu.org/viewcvs?rev=205528root=gccview=rev Log: 2013-11-29 Richard Biener rguent...@suse.de PR middle-end/59208 * tree-ssa-operands.h (fini_ssa_operands, verify_ssa_operands, free_stmt_operands, update_stmt_operands): Add struct function argument. * tree-ssa-operands.c: Remove uses of cfun, propagate struct function argument from fini_ssa_operands, verify_ssa_operands, free_stmt_operands and update_stmt_operands everywhere. * tree-ssanames.h (release_ssa_name_fn): New. (release_ssa_name): Inline wrapper around release_ssa_name_fn. * tree-ssanames.c (release_ssa_name): Rename to ... (release_ssa_name_fn): ... this and add struct function argument. * gimple-ssa.h (update_stmt, update_stmt_if_modified): Adjust. (update_stmt_fn): New function. * tree-cfg.c (move_block_to_fn): Adjust. * tree-if-conv.c (free_bb_predicate): Likewise. * tree-ssa.c (verify_ssa): Likewise. (delete_tree_ssa): Likewise. * gimple-pretty-print.c (dump_gimple_mem_ops): Remove guard. * cgraph.c (cgraph_redirect_edge_call_stmt_to_callee): Call update_stmt_fn instead of update_stmt. * g++.dg/torture/pr59208.C: New testcase. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraph.c trunk/gcc/gimple-pretty-print.c trunk/gcc/gimple-ssa.h trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c trunk/gcc/tree-if-conv.c trunk/gcc/tree-ssa-operands.c trunk/gcc/tree-ssa-operands.h trunk/gcc/tree-ssa.c trunk/gcc/tree-ssanames.c trunk/gcc/tree-ssanames.h
[Bug target/59163] [4.8/4.9 Regression] program compiled with g++ -O3 segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59163 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 31331 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31331action=edit gcc49-pr59163.patch So like this? Untested...
[Bug middle-end/59208] [4.9 Regression] ice in initialize_flags_in_bb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59208 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug bootstrap/59199] [4.9 Regression] r205032 caused LTO bootstrap to fail with bootstrap-profile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59199 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-11-29 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Reproduced and debugged somewhat. We have # DEBUG = foo foo_2 = ...; that's a no-no and confused the operand scanner to record 'foo' as real operand during the update_stmt on stream-in. Likely a update_address_taken bug, eventual fix: @@ -1329,6 +1336,10 @@ non_rewritable_mem_ref_base (tree ref) if (DECL_P (ref)) return NULL_TREE; + /* For DEBUG_STMTs we have to look through ADDR_EXPRs. */ + if (TREE_CODE (ref) == ADDR_EXPR) +ref = TREE_OPERAND (ref, 0); + while (handled_component_p (base)) base = TREE_OPERAND (base, 0);
[Bug rtl-optimization/59340] [4.9 Regression] LRA enable-checking bootstrap failure since r205136
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59340 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Perhaps we want a different flag for the recog call than lra_in_progress?
[Bug middle-end/59208] [4.9 Regression] ice in initialize_flags_in_bb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59208 --- Comment #13 from Markus Trippelsdorf octoploid at yandex dot com --- (In reply to Richard Biener from comment #12) Fixed. The testcase is missing.
[Bug libstdc++/54316] [C++11] move constructor for stringstream
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54316 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Summary|[C++11] move constructor|[C++11] move constructor |for string_stream |for stringstream --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- No, or this PR would have been updated.
[Bug c++/59342] Function Template Specialisation causing compiler error together with using clauses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59342 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-11-29 Ever confirmed|0 |1
[Bug target/59289] [ARM] regression on unsigned-extend-2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59289 --- Comment #2 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Fri Nov 29 15:19:34 2013 New Revision: 205529 URL: http://gcc.gnu.org/viewcvs?rev=205529root=gccview=rev Log: 2013-11-29 Kyrylo Tkachov kyrylo.tkac...@arm.com PR target/59289 * config/arm/arm.c (cortexa15_extra_costs): Adjust costs. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c
[Bug target/59289] [ARM] regression on unsigned-extend-2.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59289 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from ktkachov at gcc dot gnu.org --- Fixed on trunk.
[Bug ada/59346] New: [4.9 Regression] s-osinte.adb:107:35: expected type Interfaces.C.long
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59346 Bug ID: 59346 Summary: [4.9 Regression] s-osinte.adb:107:35: expected type Interfaces.C.long Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Host: hppa2.0w-hp-hpux11.11 Target: hppa2.0w-hp-hpux11.11 Build: hppa2.0w-hp-hpux11.11 /test/gnu/gcc/objdir/./gcc/xgcc -B/test/gnu/gcc/objdir/./gcc/ -B/opt/gnu/gcc/gcc -4.9/hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-4.9/hppa2.0w-hp-hpux11.11/lib / -isystem /opt/gnu/gcc/gcc-4.9/hppa2.0w-hp-hpux11.11/include -isystem /opt/gnu/ gcc/gcc-4.9/hppa2.0w-hp-hpux11.11/sys-include-c -g -O2 -fPIC -W -Wall -gna tpg -nostdinc s-osinte.adb -o s-osinte.o s-osinte.adb:107:35: expected type Interfaces.C.long s-osinte.adb:107:35: found type System.Os_Interface.time_t make[7]: *** [s-osinte.o] Error 1 # ls -l *osint* lrwxr-xr-x 1 bin bin 44 Nov 21 05:43 s-osinte.adb - /test/gnu/gcc/gcc/gcc/ada/s-osinte-posix.adb lrwxr-xr-x 1 bin bin 43 Nov 21 05:43 s-osinte.ads - /test/gnu/gcc/gcc/gcc/ada/s-osinte-hpux.ads return timespec'(tv_sec = S, tv_nsec = time_t (Long_Long_Integer (F * 10#1#E9))); Probably introduced by the following change: 2013-11-15 H.J. Lu hongjiu...@intel.com PR ada/54040 * s-linux-x32.ads: New file. * s-osprim-x32.adb: Likewise. * s-linux.ads (time_t): New type. * s-linux-alpha.ads (time_t): Likewise. * s-linux-hppa.ads (time_t): Likewise. * s-linux-mipsel.ads (time_t): Likewise. * s-linux-sparc.ads (time_t): Likewise. * s-osinte-linux.ads (time_t): Mark it private. Replace long with System.Linux.time_t. (timespec): Replace long with time_t. * s-osinte-posix.adb (To_Timespec): Likewise. * s-taprop-linux.adb (timeval): Replace C.long with System.OS_Interface.time_t. * gcc-interface/Makefile.in (LIBGNAT_TARGET_PAIRS): Replace s-linux.ads with s-linux-x32.ads, s-osprim-posix.adb with s-osprim-x32.adb for x32.
[Bug rtl-optimization/59340] [4.9 Regression] LRA enable-checking bootstrap failure since r205136
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59340 Vladimir Makarov vmakarov at gcc dot gnu.org changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org --- Comment #2 from Vladimir Makarov vmakarov at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #1) Perhaps we want a different flag for the recog call than lra_in_progress? Or don't use it all, it is too heavy. It is better to use something light. I added this code on early stages of LRA development because it is hard to predict what RTL could be. Most important check before was one on addresses and it is gone. Insn_invalid_p check is just a paranoid check. If something goes wrong, the current LRA catches it later in any case. I hope to fix it today.
[Bug ada/59346] [4.9 Regression] s-osinte.adb:107:35: expected type Interfaces.C.long
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59346 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-11-29 CC||ebotcazou at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Fixing.
[Bug rtl-optimization/55025] reg_nonzero_bits_for_combine/get_last_value: missing mode check for hardware registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55025 Paulo J. Matos pa...@matos-sorge.com changed: What|Removed |Added CC||pa...@matos-sorge.com --- Comment #2 from Paulo J. Matos pa...@matos-sorge.com --- I think this can be closed. 4.6 is not maintained anymore and this is fixed in current versions.
[Bug ada/54040] [x32] Incorrect timeval and timespec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54040 --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Author: ebotcazou Date: Fri Nov 29 16:19:36 2013 New Revision: 205532 URL: http://gcc.gnu.org/viewcvs?rev=205532root=gccview=rev Log: PR ada/54040 PR ada/59346 * s-osinte-hpux.ads (timespec): Change type of tv_nsec field to time_t. * s-osinte-kfreebsd-gnu.ads (timespec): Likewise. * s-osinte-solaris-posix.ads (timespec): Likewise. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/s-osinte-hpux.ads trunk/gcc/ada/s-osinte-kfreebsd-gnu.ads trunk/gcc/ada/s-osinte-solaris-posix.ads
[Bug ada/59346] [4.9 Regression] s-osinte.adb:107:35: expected type Interfaces.C.long
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59346 --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Author: ebotcazou Date: Fri Nov 29 16:19:36 2013 New Revision: 205532 URL: http://gcc.gnu.org/viewcvs?rev=205532root=gccview=rev Log: PR ada/54040 PR ada/59346 * s-osinte-hpux.ads (timespec): Change type of tv_nsec field to time_t. * s-osinte-kfreebsd-gnu.ads (timespec): Likewise. * s-osinte-solaris-posix.ads (timespec): Likewise. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/s-osinte-hpux.ads trunk/gcc/ada/s-osinte-kfreebsd-gnu.ads trunk/gcc/ada/s-osinte-solaris-posix.ads
[Bug ada/59346] [4.9 Regression] s-osinte.adb:107:35: expected type Interfaces.C.long
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59346 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Blindly fixed, so please verify.
[Bug target/59163] [4.8/4.9 Regression] program compiled with g++ -O3 segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59163 --- Comment #9 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Jakub Jelinek from comment #8) Created attachment 31331 [details] gcc49-pr59163.patch So like this? Untested... Yes, but I think that we can also allow simple vector loads and stores - they emit movu insn when unaligned operand is detected.
[Bug target/59163] [4.8/4.9 Regression] program compiled with g++ -O3 segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59163 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org --- For stores I think the patch already allows that, that is the if (GET_CODE (*x) == SET SET_DEST (*x) == data) return 1; in there (the reason why I've added it was that for the misaligned store insns with UNSPEC_STOREU the misaligned MEM is in SET_DEST and SET_SRC just contains some rtl with UNSPEC_STOREU embedded somewhere in it. So, would you like: if (GET_CODE (*x) == SET (SET_DEST (*x) == data || SET_SRC (*x) == data)) return 1; ? That would IMHO handle simple loads from misaligned MEM too.
[Bug target/59163] [4.8/4.9 Regression] program compiled with g++ -O3 segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59163 --- Comment #11 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Jakub Jelinek from comment #10) For stores I think the patch already allows that, that is the if (GET_CODE (*x) == SET SET_DEST (*x) == data) return 1; in there (the reason why I've added it was that for the misaligned store insns with UNSPEC_STOREU the misaligned MEM is in SET_DEST and SET_SRC just contains some rtl with UNSPEC_STOREU embedded somewhere in it. So, would you like: if (GET_CODE (*x) == SET (SET_DEST (*x) == data || SET_SRC (*x) == data)) return 1; ? That would IMHO handle simple loads from misaligned MEM too. Yes. Perhaps also special case sse4.2 string instructions (they can operate on unaligned data, too), and the patch covers everything.
[Bug fortran/59313] gfortran.dg/erf_3.F90 FAILs on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59313 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-11-29 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org --- I'm seeing this too.
[Bug bootstrap/59199] [4.9 Regression] r205032 caused LTO bootstrap to fail with bootstrap-profile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59199 --- Comment #5 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Richard Biener from comment #4) Likely a update_address_taken bug, eventual fix: @@ -1329,6 +1336,10 @@ non_rewritable_mem_ref_base (tree ref) if (DECL_P (ref)) return NULL_TREE; + /* For DEBUG_STMTs we have to look through ADDR_EXPRs. */ + if (TREE_CODE (ref) == ADDR_EXPR) +ref = TREE_OPERAND (ref, 0); + while (handled_component_p (base)) base = TREE_OPERAND (base, 0); I tried it and I still got the same error:
[Bug preprocessor/58687] #line __LINE__ ... changes subsequent line numbers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58687 --- Comment #22 from joseph at codesourcery dot com joseph at codesourcery dot com --- On Fri, 29 Nov 2013, mtewoodbury at gmail dot com wrote: The elaborate description of the different forms of the '#line' (and other) directives makes it clear that pp-token expansion is not to take place until after the end-of-line for the directive has been seen. The question is not when it takes place, it's what the current token is when it takes place, because line number is defined in terms of the current token rather than the time of expansion. I think the current token is clearly __LINE__ on the #line directive. Consider the case where there are no more tokens after that directive, just the newline at the end of the directive (you can easily construct cases where the value of __LINE__ in such a context affects the validity of the program, by concatenating it with something else to form what might or might not be a macro name) - it's not possible the the current token to be anything on a subsequent line, because there aren't any subsequent tokens. So the current token has got to be __LINE__ (or maybe, in the more complicated cases I referred to, something else on the #line line). That's different from macro ( __LINE__ ) where all of the tokens from macro to ) are involved in expansion at the same time and you can argue for any of macro, __LINE__ and ) as being the current token. (It's also different from the cases where backslash-newline appears in the middle of __LINE__ so the question is whether to the current token means to the start of end of that token.) Accepted usage is for '#line __LINE__' to leave the line numbering unchanged. It's quite possible there's a common bug among multiple other implementations where it does leave the line number unchanged, but I'm now tending to that actually being a bug in those implementations rather than an ambiguity in the standard. That is, there is no way in the standard to leave the line number unchanged, and no defect, and it might be better to wait until a revision process for a new major C standard version is underway them submit a proposal for e.g. #line with just a filename and no line number (or a #file directive - either would be a reasonable way of achieving that goal).
[Bug target/59163] [4.8/4.9 Regression] program compiled with g++ -O3 segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59163 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Attachment #31331|0 |1 is obsolete|| Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 31332 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31332action=edit gcc49-pr59163.patch So like this?
[Bug target/59163] [4.8/4.9 Regression] program compiled with g++ -O3 segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59163 --- Comment #13 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Jakub Jelinek from comment #12) Created attachment 31332 [details] gcc49-pr59163.patch So like this? Yes, with adjusted comment in ix86_legitimate_combined_insn. IIRC, unaligned moves won't be propagated during or after reload, so it looks to me that the approach is correct.
[Bug middle-end/59011] [4.7/4.8/4.9 Regression] ICE in make_decl_rtl, at varasm.c:1147
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59011 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
[Bug fortran/59313] gfortran.dg/erf_3.F90 FAILs on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59313 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Target|sparc*-sun-solaris2.* |sparc*-sun-solaris2.*, ||alpha-linux-gnu CC||ubizjak at gmail dot com --- Comment #2 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Eric Botcazou from comment #1) I'm seeing this too. Me to, on alpha-linux-gnu, exactly the same numbers: 0.000 0.000 0.000 0.000 0.000 6167208123267181. Program aborted. Backtrace: #0 0x204F197
[Bug fortran/59313] gfortran.dg/erf_3.F90 FAILs on Solaris/SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59313 --- Comment #3 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Uroš Bizjak from comment #2) Me to, on alpha-linux-gnu, exactly the same numbers: alpha-linux-gnu is 128 bit long double, but not __float128 target: auto-host.h:#define TARGET_DEFAULT_LONG_DOUBLE_128 1 Probably sparc also defines this.
[Bug middle-end/59176] [4.9 Regression] ICE edge points to wrong declaration / verify_cgraph_node failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59176 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org --- Now that PR59208 was fixed, I tried the test case of this PR again (with today's r205539). Result: Still the same, an ICE with -O3 in verify_cgraph_node. (-O2 is fine.)
[Bug target/59163] [4.8/4.9 Regression] program compiled with g++ -O3 segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59163 --- Comment #14 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Uroš Bizjak from comment #13) (In reply to Jakub Jelinek from comment #12) Created attachment 31332 [details] gcc49-pr59163.patch So like this? Yes, with adjusted comment in ix86_legitimate_combined_insn. IIRC, unaligned moves won't be propagated during or after reload, so it looks to me that the approach is correct. Running the testsuite with your patch applied exposed a minor problem: FAIL: gcc.target/i386/sse-1.c scan-assembler-not movaps movlps/movhps and movlpd/movhpd can also handle unaligned operands (please see ix86_expand_vector_move_misalign). We should simply tag instructions that operate on unaligned operands (attribute type = ssemovu) and check type attribute instead. The proposed approach would mean to change all scheduler and attribute calculation checks from ssemov to ssemov,ssemovu, but this would be a simple mechanical change.
[Bug sanitizer/59333] ICE with long long and -m32 -fsanitize=undefined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59333 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- I think we just shouldn't try to pass values by reference in ubsan_encode_value...
[Bug rtl-optimization/59340] [4.9 Regression] LRA enable-checking bootstrap failure since r205136
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59340 --- Comment #3 from Vladimir Makarov vmakarov at gcc dot gnu.org --- Author: vmakarov Date: Fri Nov 29 20:08:38 2013 New Revision: 205541 URL: http://gcc.gnu.org/viewcvs?rev=205541root=gccview=rev Log: 2013-11-29 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/59340 * lra.c (check_rtl): Use recog_memoized instead of insn_invalid_p. Revert 2013-11-20 Robert Suchanek robert.sucha...@imgtec.com * lra.c (lra): Set lra_in_progress before check_rtl call. * recog.c (insn_invalid_p): Add !lra_in_progress to prevent adding clobber regs when LRA is running. Modified: trunk/gcc/ChangeLog trunk/gcc/lra.c trunk/gcc/recog.c
[Bug rtl-optimization/59340] [4.9 Regression] LRA enable-checking bootstrap failure since r205136
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59340 --- Comment #4 from Vladimir Makarov vmakarov at gcc dot gnu.org --- Andreas, could you check that the bootstrap is fixed. At least, the test is compiled by the cross-compiler.
[Bug target/59163] [4.8/4.9 Regression] program compiled with g++ -O3 segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59163
--- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Uroš Bizjak from comment #14)
(In reply to Uroš Bizjak from comment #13)
(In reply to Jakub Jelinek from comment #12)
Created attachment 31332 [details]
gcc49-pr59163.patch
So like this?
Yes, with adjusted comment in ix86_legitimate_combined_insn.
IIRC, unaligned moves won't be propagated during or after reload, so it
looks to me that the approach is correct.
Running the testsuite with your patch applied exposed a minor problem:
FAIL: gcc.target/i386/sse-1.c scan-assembler-not movaps
movlps/movhps and movlpd/movhpd can also handle unaligned operands (please
see ix86_expand_vector_move_misalign). We should simply tag instructions
that operate on unaligned operands (attribute type = ssemovu) and check type
attribute instead.
The proposed approach would mean to change all scheduler and attribute
calculation checks from ssemov to ssemov,ssemovu, but this would be a
simple mechanical change.
Yeah, I've noticed that too, plus the dumps I've used to note what instructions
have been rejected by the patch show that UNSPEC_LDDQU would need to be treated
like UNSPEC_LOADU.
The patch made difference for 32-bit:
gcc.target/i386/sse-1.c (as you write above)
gcc.dg/torture/pr18582-1.c (UNSPEC_LDDQU)
gcc.target/i386/sse4_1-movntdqa.c (UNSPEC_MOVNTDQA)
and 64-bit also
g++.dg/torture/pr59163.C (desirable)
Now, for movntdqa, I think it accepts only aligned memory, but the MEM in there
is supposed to be aligned and is created by
if (i == memory)
{
/* This must be the memory operand. */
op = ix86_zero_extend_to_Pmode (op);
op = gen_rtx_MEM (mode, op);
gcc_assert (GET_MODE (op) == mode
|| GET_MODE (op) == VOIDmode);
}
and there is similar code for builtins that store.
Supposedly for this we should use get_pointer_alignment (arg) and at least
set_mem_align (op, get_pointer_alignment (arg)); if it is larger than MEM_ALIGN
(op). The gcc_assert doesn't make any sense to me, result of gen_rtx_MEM
(mode, op) will always have GET_MODE (op) == mode, no need to assert that and
it will never have VOIDmode.
Now, if we could easily find out which of the builtins assume aligned memory
(and to what extent), we should also set it, because say using
_mm_stream_load_si128 with not 128-bit aligned memory is user error, so GCC
should be able to assume A128 there. I'd say the sse-1.c case is similar,
isn't it?
[Bug c++/59347] New: ICE on invalid: tree check: expected class 'type', have 'exceptional' (error_mark) in tsubst_decl, at cp/pt.c:10798
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59347
Bug ID: 59347
Summary: ICE on invalid: tree check: expected class 'type',
have 'exceptional' (error_mark) in tsubst_decl, at
cp/pt.c:10798
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dimhen at gmail dot com
$ uname -a
Linux dim.cp.ru 3.11.9-200.fc19.x86_64 #1 SMP Wed Nov 20 21:22:24 UTC 2013
x86_64 x86_64 x86_64 GNU/Linux
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc_current/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/dimhen/src/gcc_current/configure
--prefix=/usr/local/gcc_current --with-multilib-list=m64
--enable-checking=yes,df,fold,rtl,tree --enable-languages=c,c++,lto
--enable-plugin --with-tune=native --with-arch=native
--enable-version-specific-runtime-libs
Thread model: posix
gcc version 4.9.0 20131129 (experimental) [trunk revision 205527] (GCC)
$ cat x.ii
struct cast_retty_wrap;
template class struct cast_retty {
typedef cast_retty_wrap::ret_type
} class Y cast_rettyY::
$ g++ -fpreprocessed -fsyntax-only x.ii
x.ii:3:11: error: 'cast_retty_wrap' is not a template
typedef cast_retty_wrap::ret_type
^
x.ii:3:30: error: typedef name may not be a nested-name-specifier
typedef cast_retty_wrap::ret_type
^
x.ii:3:30: error: expected ';' at end of member declaration
x.ii:4:1: error: expected ';' after struct definition
} class Y cast_rettyY::
^
x.ii: In instantiation of 'struct cast_rettyY':
x.ii:4:24: required from here
x.ii:3:30: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in tsubst_decl, at cp/pt.c:10798
typedef cast_retty_wrap::ret_type
^
0xeea097 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
/home/dimhen/src/gcc_current/gcc/tree.c:9241
0x6c14d8 tree_class_check
/home/dimhen/src/gcc_current/gcc/tree.h:2825
0x6c14d8 tsubst_decl
/home/dimhen/src/gcc_current/gcc/cp/pt.c:10798
0x6abd2c tsubst(tree_node*, tree_node*, int, tree_node*)
/home/dimhen/src/gcc_current/gcc/cp/pt.c:11338
0x6da18f instantiate_class_template_1
/home/dimhen/src/gcc_current/gcc/cp/pt.c:8987
0x6da18f instantiate_class_template(tree_node*)
/home/dimhen/src/gcc_current/gcc/cp/pt.c:9251
0x76a933 complete_type(tree_node*)
/home/dimhen/src/gcc_current/gcc/cp/typeck.c:134
0x743298 cp_parser_nested_name_specifier_opt
/home/dimhen/src/gcc_current/gcc/cp/parser.c:5389
0x743d7b cp_parser_nested_name_specifier
/home/dimhen/src/gcc_current/gcc/cp/parser.c:5452
0x743eb7 cp_parser_ptr_operator
/home/dimhen/src/gcc_current/gcc/cp/parser.c:17485
0x74b800 cp_parser_declarator
/home/dimhen/src/gcc_current/gcc/cp/parser.c:16834
0x756939 cp_parser_init_declarator
/home/dimhen/src/gcc_current/gcc/cp/parser.c:16433
0x758699 cp_parser_simple_declaration
/home/dimhen/src/gcc_current/gcc/cp/parser.c:11134
0x73c5a3 cp_parser_block_declaration
/home/dimhen/src/gcc_current/gcc/cp/parser.c:11015
0x762c26 cp_parser_declaration
/home/dimhen/src/gcc_current/gcc/cp/parser.c:10912
0x761918 cp_parser_declaration_seq_opt
/home/dimhen/src/gcc_current/gcc/cp/parser.c:10798
0x7631eb cp_parser_translation_unit
/home/dimhen/src/gcc_current/gcc/cp/parser.c:4018
0x7631eb c_parse_file()
/home/dimhen/src/gcc_current/gcc/cp/parser.c:31261
0x880973 c_common_parse_file()
/home/dimhen/src/gcc_current/gcc/c-family/c-opts.c:1056
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 target/59163] [4.8/4.9 Regression] program compiled with g++ -O3 segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59163 --- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org --- Note that (according to my reading of the docs) e.g. movlps/movhps don't allow unaligned memory, so blindly allow any combine is wrong, but while the MEM operand in those cases is say V4SFmode, the loads or stores can have V2SFmode's alignment. So, I don't see how ssemovu type would help us here, I think we handle all the completely unaligned loads/stores already (after the UNSPEC_LDDQU addition). But we need some way how to determine for which instructions we should require only smaller alignment, plus tweak the two gen_rtx_MEM spots for the builtins and set mode there according to get_pointer_alignment and/or to assumed alignment of the builtins.
[Bug c++/43734] cerr related segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43734 --- Comment #13 from Rolf Eike Beer e...@sf-mail.de --- Ok, it looks like this is no gcc problem. If I rebuild gcc with binutils 2.22 it works. If I compile gcc with binutils 2.23.[12] it fails. Having a gcc built with binutils 2.23.2 and building the program with binutils 2.22 it also fails. So the solution (for the moment) is to build gcc with binutils 2.22 and everything is fine.
[Bug driver/59321] -fuse-ld does not have effect on -print-prog-name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59321 --- Comment #5 from H.J. Lu hjl.tools at gmail dot com --- Created attachment 31333 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31333action=edit A patch This patch teaches gcc.c to append .bfd/.gold to ld if -fuse-ld=XXX is used for --print-prog-name=ld.
