[Bug c++/64626] New: C++14 single quote should not always be a digit separator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64626
Bug ID: 64626
Summary: C++14 single quote should not always be a digit
separator
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: b.r.longbons at gmail dot com
Created attachment 34459
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34459action=edit
informative testcase
During preprocessing, single quote (') should only be considered a digit
separator if it is followed by a digit or nondigit.
If it is followed by any other character, it should be considered as the start
of a new character-literal, not part of the current pp-number.
I am aware of exactly 2 other cases where a preprocessing-token needs to
consume 2 characters or none at all (. - ... and %: - %:%:), and gcc seems to
handle them correctly. (There is also the :: case which looks ahead two
characters to *not* consume a character).
Unimplemented: gcc 4.8
Bad: Debian gcc 4.9.1-19
Bad: gcc 5.0.0 snapshot from 20141228
Good: Debian clang 3.4, 3.5, and svn snapshot of 3.6
[Bug c++/64626] C++14 single quote should not always be a digit separator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64626 --- Comment #1 from Ben Longbons b.r.longbons at gmail dot com --- Demostration that gcc correctly preprocesses the other tokens: #define JOIN(a, b) a##b JOIN(.., .) // error about pasting . and . #define JOIN3(a, b, c) a##b##c JOIN3(%:%, :, %:) // successfully results in %: %:%: // (though note that the order of evaluation of ## is unspecified so if b##c were evaluated first a compliant implementation could fail to paste :%:)
[Bug ipa/64218] [5 Regression] ICE: Segmentation fault (symtab_node::get_alias_target()) running Boost testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64218 --- Comment #11 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Jan Hubicka from comment #10) Wonder if this one is fixed, too... No. It still crashes.
[Bug libgomp/64625] ___OFFLOAD_TABLE__ symbol not produced on x86_64 darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64625 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-16 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed.
[Bug tree-optimization/61743] [5 Regression] Complete unroll is not happened for loops with short upper bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61743 --- Comment #16 from rguenther at suse dot de rguenther at suse dot de --- On Thu, 15 Jan 2015, jakub at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61743 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org --- The testcases fail on x86_64 with -m32: grep 'loop with . iterations completely unrolled' pr61743-1.c.128t.cunroll pr61743-1.c:25:5: note: loop with 8 iterations completely unrolled pr61743-1.c:16:5: note: loop with 8 iterations completely unrolled pr61743-1.c:16:5: note: loop with 3 iterations completely unrolled pr61743-1.c:29:5: note: loop with 2 iterations completely unrolled pr61743-1.c:24:3: note: loop with 4 iterations completely unrolled grep 'loop with . iterations completely unrolled' pr61743-2.c.128t.cunroll pr61743-2.c:25:5: note: loop with 8 iterations completely unrolled pr61743-2.c:16:5: note: loop with 8 iterations completely unrolled pr61743-2.c:16:5: note: loop with 3 iterations completely unrolled pr61743-2.c:29:5: note: loop with 2 iterations completely unrolled pr61743-2.c:24:3: note: loop with 4 iterations completely unrolled (latest trunk). With -m64 they work fine. Huh, it passed for me ontop of r219648. Let me re-check.
[Bug tree-optimization/61743] [5 Regression] Complete unroll is not happened for loops with short upper bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61743 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #17 from Richard Biener rguenth at gcc dot gnu.org --- Works for me and also for HJ it seems. (fixed)
[Bug middle-end/64568] [5 Regression] error: invalid reference prefix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64568 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #6 from Markus Trippelsdorf trippels at gcc dot gnu.org --- I still happens running the Boost testsuite on ppc64: trippels@gcc2-power8 status % g++ -c -O3 -std=c++11 test22.ii In file included from ../libs/numeric/ublas/test/test2.hpp:22:0, from ../libs/numeric/ublas/test/test22.cpp:13: ../boost/numeric/ublas/blas.hpp: In function ‘M boost::numeric::ublas::blas_2::hr2(M, const T, const V1, const V2) [with M = boost::numeric::ublas::matrixstd::complexdouble ; T = std::complexdouble; V1 = boost::numeric::ublas::vectorstd::complexdouble ; V2 = boost::numeric::ublas::vectorstd::complexdouble ]’: ../boost/numeric/ublas/blas.hpp:330:13: error: invalid reference prefix M hr2 (M m, const T t, const V1 v1, const V2 v2) ^ MEM[base: _216, index: ivtmp.1531_157, offset: 0] cc1plus: note: in statement # VUSE .MEM_156 _158 = IMAGPART_EXPR MEM[base: _216, index: ivtmp.1531_157, offset: 0]; ../boost/numeric/ublas/blas.hpp:330:13: error: invalid reference prefix MEM[base: _216, index: ivtmp.1531_157, offset: 0] cc1plus: note: in statement # VUSE .MEM_156 _91 = REALPART_EXPR MEM[base: _216, index: ivtmp.1531_157, offset: 0]; ../boost/numeric/ublas/blas.hpp:330:13: internal compiler error: verify_gimple failed 0x10a48a6f verify_gimple_in_cfg(function*, bool) ../../gcc/gcc/tree-cfg.c:5069 0x10903e53 execute_function_todo ../../gcc/gcc/passes.c:1955 0x10904a93 do_per_function ../../gcc/gcc/passes.c:1647 0x10904d67 execute_todo ../../gcc/gcc/passes.c:2012 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. Reducing...
[Bug tree-optimization/64622] convoluted loop codegen for __strcspn_c1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64622 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- That's indeed more clever loop header copying.
[Bug tree-optimization/64622] convoluted loop codegen for __strcspn_c1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64622 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- without loop header copyign we generate __strcspn_c1: .LFB0: .cfi_startproc xorl%eax, %eax jmp .L2 .p2align 4,,10 .p2align 3 .L8: cmpl%esi, %edx je .L6 addq$1, %rax .L2: movsbl (%rdi,%rax), %edx testb %dl, %dl jne .L8 .L6: rep ret so it would be interesting to investigate how they do this (if it's a special hack or some systematic fix). The loop header contains just the IV increment here.
[Bug c++/51747] [DR 1467] [C++11] cannot call defaulted copy constructor using list-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51747
Ville Voutilainen ville.voutilainen at gmail dot com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC||ville.voutilainen at gmail dot
com
Resolution|FIXED |---
--- Comment #8 from Ville Voutilainen ville.voutilainen at gmail dot com ---
This case fails:
struct base {
};
struct derived : base {
derived(const base state)
: base{state} // Gcc, Clang, and EDG reject.
{}
};
void f(base b) {
derived d{b};
}
Should this be a separate bug? The call of the implicitly-defaulted
copy constructor fails using list-initialization, so this seems like
it should be part of the same PR.
[Bug middle-end/64621] MIssed tail call oppurtunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64621 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Well, this really really asks for the function signatures to be updated to the call ABI at the GIMPLE level... OTOH, (int) strtol (...) possibly truncates the value so it's not a noop (it's a noop on i?86 only).
[Bug rtl-optimization/11222] arm/thumb __Unwind_SjLj_Register prologue optimization causes crash on interrupts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11222 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||ramana at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #11 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- This is almost gone now. I can't reproduce it with trunk probably because arm-elf is now dead and long gone, as everything is now EABI centric.
[Bug tree-optimization/64601] Missed PRE on std::vector move assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64601
--- Comment #4 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Marc Glisse from comment #3)
Actually there is no need for inlining.
struct A { int i; };
void f(struct A *a){ *a-i=0; }
void g(struct A *a){ int*p=a-i;*p=0; }
The main difference seems to be that the first one gets through fold-const.c
while the second is handled by tree-ssa-forwprop.c.
a-i is merely an address calculation, not an access to type A at a. Thus
it's valid to write
struct B { int i; int j; };
struct B b;
int *p = ((struct A *)b)-i;
*p = 0;
and it's only required that the actual access (here a int * dereference)
honors TBAA rules.
So generally you can't reconstruct access paths when forwarding address
calculations into dereferences. We've had very elaborate code guessing
access paths in oder releases which broke down very easily for moderately
complex testcases.
We still have some of that code in forwprop (I still believe it's not
100% correct...) which handles
struct A { int i[4]; };
void g(struct A *a, int j) { int *p = a-i[j]; *p = 0;}
generating
MEM[(int *)a_1(D)].i[j_2(D)] = 0;
return;
but the case comes after forwarding invariant addresses. If we'd swap them
(really believing in its correctness) then we also handle your case.
But as I said - that If ... and the value type is the same as that of the
pointed-to type of the address is really bogus - the type of the address
doesn't have any meaning in GIMPLE (all pointer type conversions are
useless).
[Bug tree-optimization/64601] Missed PRE on std::vector move assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64601 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Created attachment 34460 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34460action=edit patch This is what I am talking about (I think it's wrong and instead we have to remove the case completely)
[Bug target/59710] Nios2: Missing gprel optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59710 Sebastian Huber sebastian.hu...@embedded-brains.de changed: What|Removed |Added Known to work||5.0 --- Comment #3 from Sebastian Huber sebastian.hu...@embedded-brains.de --- Thanks, this fixes the problem in case the new -mgpot=global option is used. Do you plan to back port this to GCC 4.9? If not, then can you please adjust the target milestone and close the PR. nios2-elf-gcc -O2 -mgpopt=global -fno-common -S gprel-ok.c cat gprel-ok.s .file gprel-ok.c .section.text .align 2 .global gprel_ok .type gprel_ok, @function gprel_ok: movir2, 123 stw r2, %gprel(iii)(gp) movir2, 789 stw r2, %gprel(jjj)(gp) ret .size gprel_ok, .-gprel_ok .global jjj .section.sdata,aws,@progbits .align 2 .type jjj, @object .size jjj, 4 jjj: .long 456 .global iii .section.sbss,aws,@nobits .align 2 .type iii, @object .size iii, 4 iii: .zero 4 .ident GCC: (GNU) 5.0.0 20150116 (experimental) nios2-elf-gcc -O2 -mgpopt=global -fno-common -S gprel-not-ok.c cat gprel-not-ok.s .file gprel-not-ok.c .section.text .align 2 .global gprel_not_ok .type gprel_not_ok, @function gprel_not_ok: movir2, 123 stw r2, %gprel(iii)(gp) movir2, 789 stw r2, %gprel(jjj)(gp) ret .size gprel_not_ok, .-gprel_not_ok .ident GCC: (GNU) 5.0.0 20150116 (experimental)
[Bug ipa/62016] [4.8/4.9 Regression] very slow compilation at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62016 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||5.0 Summary|[4.8/4.9/5 Regression] very |[4.8/4.9 Regression] very |slow compilation at -O3 on |slow compilation at -O3 on |x86_64-linux-gnu|x86_64-linux-gnu Known to fail||4.8.3, 4.9.2 --- Comment #10 from Richard Biener rguenth at gcc dot gnu.org --- Yep. /usr/bin/time gcc-4.7 t.c -O3 0.10user 0.02system 0:00.62elapsed 21%CPU (0avgtext+0avgdata 15704maxresident)k 26080inputs+48outputs (113major+9177minor)pagefaults 0swaps /usr/bin/time gcc-4.8 t.c -O3 ^C 0.00user 0.00system 6:11.40elapsed 0%CPU (0avgtext+0avgdata 1136maxresident)k 1440inputs+0outputs (7major+331minor)pagefaults 0swaps /usr/bin/time gcc-4.9 t.c -O3 3.13user 0.18system 0:03.84elapsed 86%CPU (0avgtext+0avgdata 404088maxresident)k 28400inputs+48outputs (128major+137978minor)pagefaults 0swaps /usr/bin/time /space/rguenther/install/gcc-5.0/bin/gcc t.c -O3 0.04user 0.01system 0:00.28elapsed 20%CPU (0avgtext+0avgdata 13364maxresident)k 6376inputs+48outputs (17major+8570minor)pagefaults 0swaps
[Bug c++/58614] [c++11] ICE with undeclared variable in initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58614 --- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Fri Jan 16 09:38:59 2015 New Revision: 219716 URL: https://gcc.gnu.org/viewcvs?rev=219716root=gccview=rev Log: /cp 2015-01-16 Paolo Carlini paolo.carl...@oracle.com PR c++/58614 * pt.c (unify): When BRACE_ENCLOSED_INITIALIZER_P (arg), handle TREE_TYPE (elt) == error_mark_node. /testsuite 2015-01-16 Paolo Carlini paolo.carl...@oracle.com PR c++/58614 * g++.dg/cpp0x/auto44.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/auto44.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/64601] Missed PRE on std::vector move assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64601
--- Comment #6 from Richard Biener rguenth at gcc dot gnu.org ---
Note that we do it correctly even - forcing a TBAA type of just 'int' and thus
disabling path-based disambiguation.
So doing this won't help you, it just will generate larger trees:
void f(V, V) (struct V v, struct V w)
{
int * _3;
int * _6;
int * _7;
int * _8;
bb 2:
_3 = MEM[(int * )w_2(D)].D.14881._M_impl._M_start;
MEM[(int * )w_2(D)].D.14881._M_impl._M_start = 0B;
_6 = MEM[(int * )w_2(D)].D.14881._M_impl._M_finish;
MEM[(int * )w_2(D)].D.14881._M_impl._M_finish = 0B;
_7 = MEM[(int * )w_2(D)].D.14881._M_impl._M_end_of_storage;
MEM[(int * )w_2(D)].D.14881._M_impl._M_end_of_storage = 0B;
_8 = MEM[(int * )v_4(D)].D.14881._M_impl._M_start;
MEM[(int * )v_4(D)].D.14881._M_impl._M_start = _3;
MEM[(int * )v_4(D)].D.14881._M_impl._M_finish = _6;
MEM[(int * )v_4(D)].D.14881._M_impl._M_end_of_storage = _7;
...
void g(V, V) (struct V v, struct V w)
{
int * __tmp.0_5;
int * _6;
int * __tmp.0_7;
int * _8;
int * __tmp.0_9;
int * _10;
bb 2:
__tmp.0_5 = MEM[(int * )v_4(D)].D.14881._M_impl._M_start;
MEM[(int * )v_4(D)].D.14881._M_impl._M_start = 0B;
MEM[(int * )v_4(D)].D.14881._M_impl._M_finish = 0B;
MEM[(int * )v_4(D)].D.14881._M_impl._M_end_of_storage = 0B;
_6 = MEM[(int * )w_2(D)].D.14881._M_impl._M_start;
MEM[(int * )v_4(D)].D.14881._M_impl._M_start = _6;
MEM[(int * )w_2(D)].D.14881._M_impl._M_start = 0B;
__tmp.0_7 = MEM[(int * )v_4(D)].D.14881._M_impl._M_finish;
_8 = MEM[(int * )w_2(D)].D.14881._M_impl._M_finish;
MEM[(int * )v_4(D)].D.14881._M_impl._M_finish = _8;
MEM[(int * )w_2(D)].D.14881._M_impl._M_finish = __tmp.0_7;
__tmp.0_9 = MEM[(int * )v_4(D)].D.14881._M_impl._M_end_of_storage;
_10 = MEM[(int * )w_2(D)].D.14881._M_impl._M_end_of_storage;
MEM[(int * )v_4(D)].D.14881._M_impl._M_end_of_storage = _10;
MEM[(int * )w_2(D)].D.14881._M_impl._M_end_of_storage = __tmp.0_9;
they are still all plain int * accesses.
[Bug c++/58614] [c++11] ICE with undeclared variable in initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58614 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 5.0.
[Bug tree-optimization/64601] Missed PRE on std::vector move assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64601
--- Comment #7 from Marc Glisse glisse at gcc dot gnu.org ---
I am testing the following hack, I hope there will be at least 1 failure in the
testsuite that will help me understand why it is wrong. It bootstraps and gives
accesses like MEM[(struct _Vector_impl *)v_4(D)]._M_start.
struct B { int i; int j; };
struct B b;
int *p = ((struct A *)b)-i;
*p = 0;
Hmmm, yeah, that's ugly... I wish it weren't legal... I'll have to play with it
to see exactly how bad it is... Thanks for the example.
--- tree-ssa-forwprop.c(revision 219694)
+++ tree-ssa-forwprop.c(working copy)
@@ -777,20 +777,41 @@ forward_propagate_addr_expr_1 (tree name
new_def_rhs);
else if (is_gimple_min_invariant (new_def_rhs))
gimple_assign_set_rhs_with_ops (use_stmt_gsi, NOP_EXPR, new_def_rhs);
else
return false;
gcc_assert (gsi_stmt (*use_stmt_gsi) == use_stmt);
update_stmt (use_stmt);
return true;
}
+ /* *X - X. */
+ if (TREE_CODE (lhs) == MEM_REF
+ TREE_OPERAND (lhs, 0) == name
+ integer_zerop (TREE_OPERAND (lhs, 1))
+ useless_type_conversion_p (TREE_TYPE (lhs),
+TREE_TYPE (TREE_OPERAND (def_rhs, 0
+{
+ gimple_assign_set_lhs (use_stmt, unshare_expr (TREE_OPERAND (def_rhs,
0)));
+ tidy_after_forward_propagate_addr (use_stmt);
+ return true;
+}
+ else if (TREE_CODE (rhs) == MEM_REF
+ TREE_OPERAND (rhs, 0) == name
+ integer_zerop (TREE_OPERAND (rhs, 1))
+ useless_type_conversion_p (TREE_TYPE (rhs),
+TREE_TYPE (TREE_OPERAND (def_rhs, 0
+{
+ gimple_assign_set_rhs1 (use_stmt, unshare_expr (TREE_OPERAND (def_rhs,
0)));
+ tidy_after_forward_propagate_addr (use_stmt);
+ return true;
+}
/* Now strip away any outer COMPONENT_REF/ARRAY_REF nodes from the LHS.
ADDR_EXPR will not appear on the LHS. */
tree *lhsp = gimple_assign_lhs_ptr (use_stmt);
while (handled_component_p (*lhsp))
lhsp = TREE_OPERAND (*lhsp, 0);
lhs = *lhsp;
/* Now see if the LHS node is a MEM_REF using NAME. If so,
propagate the ADDR_EXPR into the use of NAME and fold the result. */
if (TREE_CODE (lhs) == MEM_REF
[Bug ipa/61548] [5 Regression] FAIL: gcc.dg/tls/alias-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61548 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |ASSIGNED --- Comment #11 from ktkachov at gcc dot gnu.org --- (In reply to Jan Hubicka from comment #10) I believe this is also fixed by the ipa-inline alias handling fix. I still see the ICE on ARM at least as of r219714: $TOP/gcc/gcc/testsuite/gcc.dg/tls/alias-1.c:24:3: internal compiler error: Segmentation fault 0xa61df5 crash_signal $TOP/gcc/gcc/toplev.c:381 0x6a05d8 symtab_node::get_alias_target() $TOP/gcc/gcc/cgraph.h:2271 0x6a05d8 symtab_node::verify_base() $TOP/gcc/gcc/symtab.c:1130 0x6a0983 symtab_node::verify() $TOP/gcc/gcc/symtab.c:1163 0x6a19af symtab_node::verify_symtab_nodes() $TOP/gcc/gcc/symtab.c:1181 0x8dabd6 symbol_table::remove_unreachable_nodes(_IO_FILE*) $TOP/gcc/gcc/ipa.c:662 0x6b1fa4 ipa_passes $TOP/gcc/gcc/cgraphunit.c:2087 0x6b1fa4 symbol_table::compile() $TOP/gcc/gcc/cgraphunit.c:2221 0x6b3c71 symbol_table::finalize_compilation_unit() $TOP/gcc/gcc/cgraphunit.c:2370 0x54d083 c_write_global_declarations() $TOP/gcc/gcc/c/c-decl.c:10787 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report.
[Bug target/64011] Fail to compile pr48335-2.c on big-endian where bit insert instruction supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64011 --- Comment #3 from Jiong Wang jiwang at gcc dot gnu.org --- Author: jiwang Date: Fri Jan 16 10:14:51 2015 New Revision: 219717 URL: https://gcc.gnu.org/viewcvs?rev=219717root=gccview=rev Log: [Patch] Warn and truncate bitsize when partial overflow happen PR rtl-optimization/64011 gcc/ * expmed.c (store_bit_field_using_insv): Warn and truncate bitsize when there is partial overflow. Modified: trunk/gcc/ChangeLog trunk/gcc/expmed.c
[Bug libffi/64607] [5 Regression] Multilib test stops working in libffi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64607 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- As expected from comment 0, the following patch restores the previous behavior. --- ../_clean/libffi/Makefile.in2015-01-12 17:31:37.0 +0100 +++ libffi/Makefile.in2015-01-15 23:02:11.0 +0100 @@ -336,39 +336,39 @@ MAINTAINERCLEANFILES = $(srcdir)/doc/lib # values defined in terms of make variables, as is the case for CC and # friends when we are called from the top level Makefile. AM_MAKEFLAGS = \ -'AR_FLAGS=$(AR_FLAGS)' \ -'CC_FOR_BUILD=$(CC_FOR_BUILD)' \ -'CFLAGS=$(CFLAGS)' \ -'CXXFLAGS=$(CXXFLAGS)' \ -'CFLAGS_FOR_BUILD=$(CFLAGS_FOR_BUILD)' \ -'CFLAGS_FOR_TARGET=$(CFLAGS_FOR_TARGET)' \ -'INSTALL=$(INSTALL)' \ -'INSTALL_DATA=$(INSTALL_DATA)' \ -'INSTALL_PROGRAM=$(INSTALL_PROGRAM)' \ -'INSTALL_SCRIPT=$(INSTALL_SCRIPT)' \ -'JC1FLAGS=$(JC1FLAGS)' \ -'LDFLAGS=$(LDFLAGS)' \ -'LIBCFLAGS=$(LIBCFLAGS)' \ -'LIBCFLAGS_FOR_TARGET=$(LIBCFLAGS_FOR_TARGET)' \ -'MAKE=$(MAKE)' \ -'MAKEINFO=$(MAKEINFO) $(MAKEINFOFLAGS)' \ -'PICFLAG=$(PICFLAG)' \ -'PICFLAG_FOR_TARGET=$(PICFLAG_FOR_TARGET)' \ -'RUNTESTFLAGS=$(RUNTESTFLAGS)' \ -'SHELL=$(SHELL)' \ -'exec_prefix=$(exec_prefix)' \ -'infodir=$(infodir)' \ -'libdir=$(libdir)' \ -'mandir=$(mandir)' \ -'prefix=$(prefix)' \ -'AR=$(AR)' \ -'AS=$(AS)' \ -'CC=$(CC)' \ -'CXX=$(CXX)' \ -'LD=$(LD)' \ -'NM=$(NM)' \ -'RANLIB=$(RANLIB)' \ -'DESTDIR=$(DESTDIR)' +AR_FLAGS=$(AR_FLAGS) \ +CC_FOR_BUILD=$(CC_FOR_BUILD) \ +CFLAGS=$(CFLAGS) \ +CXXFLAGS=$(CXXFLAGS) \ +CFLAGS_FOR_BUILD=$(CFLAGS_FOR_BUILD) \ +CFLAGS_FOR_TARGET=$(CFLAGS_FOR_TARGET) \ +INSTALL=$(INSTALL) \ +INSTALL_DATA=$(INSTALL_DATA) \ +INSTALL_PROGRAM=$(INSTALL_PROGRAM) \ +INSTALL_SCRIPT=$(INSTALL_SCRIPT) \ +JC1FLAGS=$(JC1FLAGS) \ +LDFLAGS=$(LDFLAGS) \ +LIBCFLAGS=$(LIBCFLAGS) \ +LIBCFLAGS_FOR_TARGET=$(LIBCFLAGS_FOR_TARGET) \ +MAKE=$(MAKE) \ +MAKEINFO=$(MAKEINFO) $(MAKEINFOFLAGS) \ +PICFLAG=$(PICFLAG) \ +PICFLAG_FOR_TARGET=$(PICFLAG_FOR_TARGET) \ +RUNTESTFLAGS=$(RUNTESTFLAGS) \ +SHELL=$(SHELL) \ +exec_prefix=$(exec_prefix) \ +infodir=$(infodir) \ +libdir=$(libdir) \ +mandir=$(mandir) \ +prefix=$(prefix) \ +AR=$(AR) \ +AS=$(AS) \ +CC=$(CC) \ +CXX=$(CXX) \ +LD=$(LD) \ +NM=$(NM) \ +RANLIB=$(RANLIB) \ +DESTDIR=$(DESTDIR) # Subdir rules rely on $(FLAGS_TO_PASS) === libffi tests === Running target unix/-m32 === libffi Summary for unix/-m32 === # of expected passes1904 # of unsupported tests30 Running target unix/-m64 === libffi Summary for unix/-m64 === # of expected passes1904 # of unsupported tests30 === libffi Summary === # of expected passes3808 # of unsupported tests60
[Bug target/64011] Fail to compile pr48335-2.c on big-endian where bit insert instruction supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64011 Jiong Wang jiwang at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jiong Wang jiwang at gcc dot gnu.org --- mark as fixed
[Bug target/64624] ppc64 build failure, ISA_2_7_MASKS_SERVER not declared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64624 Anton Blanchard anton at samba dot org changed: What|Removed |Added Target||powerpc64le- Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Anton Blanchard anton at samba dot org --- Network issues during submit, ended up with two identical bugs. *** This bug has been marked as a duplicate of bug 64623 ***
[Bug target/64623] New: ppc64 build failure, ISA_2_7_MASKS_SERVER not declared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64623 Bug ID: 64623 Summary: ppc64 build failure, ISA_2_7_MASKS_SERVER not declared Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: anton at samba dot org I'm seeing this build error as of: * config/rs6000/default64.h (TARGET_DEFAULT) [LITTLE_ENDIAN]: Use ISA 2.7 (POWER8). g++ -c -g -O2 -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc/gcc/../libbacktrace -o options.o -MT options.o -MMD -MP -MF ./.deps/options.TPo options.c In file included from tm.h:30:0, from options.c:7: ../../gcc/gcc/config/rs6000/default64.h:23:25: error: ‘ISA_2_7_MASKS_SERVER’ was not declared in this scope #define TARGET_DEFAULT (ISA_2_7_MASKS_SERVER | MASK_POWERPC64 | MASK_64BIT | MASK_LITTLE_ENDIAN) ^ options.c:828:3: note: in expansion of macro ‘TARGET_DEFAULT’ TARGET_DEFAULT, /* rs6000_isa_flags */ ^ --- Comment #1 from Anton Blanchard anton at samba dot org --- *** Bug 64624 has been marked as a duplicate of this bug. ***
[Bug middle-end/64614] bogus used initialized warning (in gcc 4.9.2); switch statement versus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64614 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Created attachment 34461 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34461action=edit preliminary patch I think the uninit pass doesn't even try to handle switch case input conditions (convert_control_dep_chain_into_preds). Nor does predicate handling deal with bar 3 predicates. Preliminary patch attached - still needs to handle the default case - but it seems we don't warn about the return value with the patch. With the patch: [CHECK] Found def edge 1 in tmp_1 = PHI tmp_6(D)(3), baz_7(D)(8) [BEFORE SIMPLICATION -- [USE]: MEM[(char *)tmp_1 + 11B] = 15; is guarded by : bar_4(D) == 2 [BEFORE SIMPLICATION -- [DEF]: tmp_1 = PHI tmp_6(D)(3), baz_7(D)(8) is guarded by : _5 != 0 [AFTER NORMALIZATION -- [DEF]: tmp_1 = PHI tmp_6(D)(3), baz_7(D)(8) is guarded by : bar_4(D) 3
[Bug middle-end/64568] [5 Regression] error: invalid reference prefix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64568
--- Comment #7 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
trippels@gcc2-power8 status % cat test22.ii
namespace std
{
typedef long unsigned size_t;
}
class H;
namespace std
{
template typename struct complex;
template typename _Tp
complex_Tp operator+(complex_Tp __x, complex_Tp __y)
{
complex_Tp a = __x;
a += __y;
return a;
}
template struct complexdouble
{
int
imag ()
{
return __imag__ _M_value;
}
void operator+=(complex __z) { _M_value += _M_value; _M_value += __z.imag
(); }
_Complex double _M_value;
};
}
struct A
{
typedef std::complexdouble const_reference;
};
class B
{
public:
B (int);
std::complexdouble operator[](int i) { return data_[i]; }
std::complexdouble *data_;
};
struct C
{
static std::complexdouble
apply (A::const_reference t1, std::complexdouble t2)
{
return t1 + t2;
}
typedef std::complexdouble result_type;
};
template class T1, class struct D
{
static void
apply (T1 t1, std::complexdouble t2)
{
t1 = t2;
}
};
class ublas_expression
{
public:
~ublas_expression ();
};
template class class F
{
};
template class E class matrix_expression : ublas_expression
{
public:
E operator()() {}
};
class I : public Fint
{
public:
typedef int value_type;
I (int);
};
template class E1, class E2 matrix_expressionint outer_prod (FE1, FE2);
template class E1, class F class J : public matrix_expressionJE1, F
{
public:
typedef typename F::result_type value_type;
value_type operator()(int i, int)
{
return F::apply (e1_ (i, 0), e2_ (0, 0));
}
E1 e1_;
E1 e2_;
};
template class E1, class E2
JH, C operator+(matrix_expressionE1, matrix_expressionE2);
template template class, class class F, class M, class E
void
indexing_matrix_assign (M m, matrix_expressionE e, int)
{
for (int i; i; ++i)
Ftypename M::reference, typename E::value_type::apply (m (0, 0),
e ()(i, 0));
}
template template class, class class F, class, class M, class E, class C
void
matrix_assign (M m, matrix_expressionE e, int, C)
{
indexing_matrix_assignF (m, e, 0);
}
template template class, class class F, class M, class E
void
matrix_assign (M m, matrix_expressionE e)
{
matrix_assignF, int (m, e, 0, typename M::orientation_category ());
}
class H : matrix_expressionint
{
public:
typedef std::complexdouble reference;
typedef int orientation_category;
H (int, int) : data_ (0) {}
template class AE H (matrix_expressionAE ae) : data_ (0)
{
matrix_assignD (*this, ae);
}
B
data ()
{
}
std::complexdouble operator()(int i, int) { return data ()[i]; }
void operator+=(matrix_expression ae) { H (*this + ae); }
B data_;
};
template class M, class T, class V1, class V2
void
sr2 (M m, T, V1 v1, V2 v2)
{
m += outer_prod (v2, v1);
}
template class, class, unsigned long struct G
{
void test ();
};
template struct GI, H, 3;
template class V, class M, std::size_t N
void
GV, M, N::test ()
{
V b (0), c (0);
M m (0, 0);
sr2 (m, typename V::value_type (), b, c);
}
trippels@gcc2-power8 status % g++ -c -O2 -std=c++11 test22.ii
test22.ii: In member function ‘void G template-parameter-1-1,
template-parameter-1-2, anonymous ::test() [with template-parameter-1-1
= I; template-parameter-1-2 = H; long unsigned int anonymous = 3ul]’:
test22.ii:139:1: error: invalid reference prefix
GV, M, N::test ()
^
MEM[base: _44, offset: 0]
cc1plus: note: in statement
# VUSE .MEM_59
_26 = IMAGPART_EXPR MEM[base: _44, offset: 0];
test22.ii:139:1: error: invalid reference prefix
MEM[base: _44, offset: 0]
cc1plus: note: in statement
# VUSE .MEM_59
_51 = REALPART_EXPR MEM[base: _44, offset: 0];
test22.ii:139:1: internal compiler error: verify_gimple failed
[Bug libgomp/64625] ___OFFLOAD_TABLE__ symbol not produced on x86_64 darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64625 Thomas Schwinge tschwinge at gcc dot gnu.org changed: What|Removed |Added Keywords||openacc, openmp Priority|P3 |P1 CC||andrey.turetskiy at gmail dot com, ||bernds at gcc dot gnu.org, ||iverbin at gmail dot com, ||kyukhin at gcc dot gnu.org Target Milestone|--- |5.0 --- Comment #3 from Thomas Schwinge tschwinge at gcc dot gnu.org --- In fact, the __OFFLOAD_TABLE__ symbol (formerly known as __OPENMP_TARGET__) should be completely removed, as it's unused. We settled on a different scheme for passing this data. We can't remove it from the libgomp OpenMP target interfaces (so, just pass NULL for those, and remove its documentation in source code comments), because that'd be an ABI change requiring a new symbol version, but we can remove it from the libgomp OpenACC interfaces (ABI change still possible now, before the 5.0 release, thus setting P1).
[Bug bootstrap/64612] [5 Regression] profiledbootstrap failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64612 --- Comment #9 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Author: trippels Date: Fri Jan 16 11:12:52 2015 New Revision: 219721 URL: https://gcc.gnu.org/viewcvs?rev=219721root=gccview=rev Log: g++.dg/ipa/pr64612.C: New test. 2015-01-16 Markus Trippelsdorf mar...@trippelsdorf.de PR ipa/64163 PR ipa/64612 * g++.dg/ipa/pr64612.C: New test. Added: trunk/gcc/testsuite/g++.dg/ipa/pr64612.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug ipa/64163] [5 Regression] r218024 causes qt5 build failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64163 --- Comment #10 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Author: trippels Date: Fri Jan 16 11:12:52 2015 New Revision: 219721 URL: https://gcc.gnu.org/viewcvs?rev=219721root=gccview=rev Log: g++.dg/ipa/pr64612.C: New test. 2015-01-16 Markus Trippelsdorf mar...@trippelsdorf.de PR ipa/64163 PR ipa/64612 * g++.dg/ipa/pr64612.C: New test. Added: trunk/gcc/testsuite/g++.dg/ipa/pr64612.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug ipa/64163] [5 Regression] r218024 causes qt5 build failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64163 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #11 from Markus Trippelsdorf trippels at gcc dot gnu.org --- *** This bug has been marked as a duplicate of bug 64612 ***
[Bug bootstrap/64612] [5 Regression] profiledbootstrap failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64612 --- Comment #10 from Markus Trippelsdorf trippels at gcc dot gnu.org --- *** Bug 64163 has been marked as a duplicate of this bug. ***
[Bug libstdc++/64438] Removing string-conversion requirement causes libstdc++-v3 fails on AArch64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64438 Tejas Belagod belagod at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Tejas Belagod belagod at gcc dot gnu.org --- Fixed.Thanks.
[Bug c++/64611] Using a operator inside an overloaded operator gives compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64611 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|NEW Last reconfirmed||2015-01-16 Resolution|DUPLICATE |--- Ever confirmed|0 |1 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #4) This is a bug and a dup of bug 11814. *** This bug has been marked as a duplicate of bug 11814 *** I don't think so
[Bug testsuite/64605] [5 Regression] ERROR: (DejaGnu) proc libatomic_target_compile lto1738.c lto1738.o object additional_flags=-flto does not exist.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64605 --- Comment #2 from iverbin at gcc dot gnu.org --- Author: iverbin Date: Fri Jan 16 11:29:54 2015 New Revision: 219722 URL: https://gcc.gnu.org/viewcvs?rev=219722root=gccview=rev Log: PR testsuite/64605 libatomic/ * testsuite/lib/libatomic.exp: Do not load gcc-dg.exp. * testsuite/libatomic.c/c.exp: Load gcc-dg.exp. Modified: trunk/libatomic/ChangeLog trunk/libatomic/testsuite/lib/libatomic.exp trunk/libatomic/testsuite/libatomic.c/c.exp
[Bug c++/64627] New: Internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64627 Bug ID: 64627 Summary: Internal compiler error: Segmentation fault Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: physik3 at gmx dot net Created attachment 34462 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34462action=edit source file from openVDB library Hi everyone. When I try to build openVDB (http://www.openvdb.org/download/) and compile the file openvdb.cc, GCC crashes with a segmentation fault. As the message asks me to submit a bug report, I am doing so now. Error message (I am building on a German system; Speicherzugriffsfehler means segmentation fault): = In file included from ../openvdb/tree/Tree.h:53:0, from Grid.h:43, from openvdb.h:39, from openvdb.cc:31: ../openvdb/tree/TreeIterator.h: In instantiation of ‘class openvdb::v3_0_0::tree::IterListItemopenvdb::v3_0_0::tree::LeafIteratorBaseopenvdb::v3_0_0::tree::Treeopenvdb::v3_0_0::tree::RootNodeopenvdb::v3_0_0::tree::InternalNodeopenvdb::v3_0_0::tree::InternalNodeopenvdb::v3_0_0::tools::PointIndexLeafNodeopenvdb::v3_0_0::PointIndexunsigned int, 0u, 3u, 4u, 5u , openvdb::v3_0_0::tree::RootNodeopenvdb::v3_0_0::tree::InternalNodeopenvdb::v3_0_0::tree::InternalNodeopenvdb::v3_0_0::tools::PointIndexLeafNodeopenvdb::v3_0_0::PointIndexunsigned int, 0u, 3u, 4u, 5u ::ChildIteropenvdb::v3_0_0::tree::RootNodeopenvdb::v3_0_0::tree::InternalNodeopenvdb::v3_0_0::tree::InternalNodeopenvdb::v3_0_0::tools::PointIndexLeafNodeopenvdb::v3_0_0::PointIndexunsigned int, 0u, 3u, 4u, 5u , std::_Rb_tree_iteratorstd::pairconst openvdb::v3_0_0::math::Coord, openvdb::v3_0_0::tree::RootNodeopenvdb::v3_0_0::tree::InternalNodeopenvdb::v3_0_0::tree::InternalNodeopenvdb::v3_0_0::tools::PointIndexLeafNodeopenvdb::v3_0_0::PointIndexunsigned int, 0u, 3u, 4u, 5u ::NodeStruct , openvdb::v3_0_0::tree::RootNodeopenvdb::v3_0_0::tree::InternalNodeopenvdb::v3_0_0::tree::InternalNodeopenvdb::v3_0_0::tools::PointIndexLeafNodeopenvdb::v3_0_0::PointIndexunsigned int, 0u, 3u, 4u, 5u ::ChildOnPred, openvdb::v3_0_0::tree::InternalNodeopenvdb::v3_0_0::tree::InternalNodeopenvdb::v3_0_0::tools::PointIndexLeafNodeopenvdb::v3_0_0::PointIndexunsigned int, 0u, 3u, 4u, 5u ::PrevItem, boost::mpl::v_itemopenvdb::v3_0_0::tree::RootNodeopenvdb::v3_0_0::tree::InternalNodeopenvdb::v3_0_0::tree::InternalNodeopenvdb::v3_0_0::tools::PointIndexLeafNodeopenvdb::v3_0_0::PointIndexunsigned int, 0u, 3u, 4u, 5u , boost::mpl::v_itemopenvdb::v3_0_0::tree::InternalNodeopenvdb::v3_0_0::tree::InternalNodeopenvdb::v3_0_0::tools::PointIndexLeafNodeopenvdb::v3_0_0::PointIndexunsigned int, 0u, 3u, 4u, 5u, boost::mpl::vector2openvdb::v3_0_0::tools::PointIndexLeafNodeopenvdb::v3_0_0::PointIndexunsigned int, 0u, 3u, openvdb::v3_0_0::tree::InternalNodeopenvdb::v3_0_0::tools::PointIndexLeafNodeopenvdb::v3_0_0::PointIndexunsigned int, 0u, 3u, 4u , 0, 0, 4ul, 0u’: ../openvdb/tree/TreeIterator.h:1296:76: required from ‘class openvdb::v3_0_0::tree::LeafIteratorBaseopenvdb::v3_0_0::tree::Treeopenvdb::v3_0_0::tree::RootNodeopenvdb::v3_0_0::tree::InternalNodeopenvdb::v3_0_0::tree::InternalNodeopenvdb::v3_0_0::tools::PointIndexLeafNodeopenvdb::v3_0_0::PointIndexunsigned int, 0u, 3u, 4u, 5u , openvdb::v3_0_0::tree::RootNodeopenvdb::v3_0_0::tree::InternalNodeopenvdb::v3_0_0::tree::InternalNodeopenvdb::v3_0_0::tools::PointIndexLeafNodeopenvdb::v3_0_0::PointIndexunsigned int, 0u, 3u, 4u, 5u ::ChildIteropenvdb::v3_0_0::tree::RootNodeopenvdb::v3_0_0::tree::InternalNodeopenvdb::v3_0_0::tree::InternalNodeopenvdb::v3_0_0::tools::PointIndexLeafNodeopenvdb::v3_0_0::PointIndexunsigned int, 0u, 3u, 4u, 5u , std::_Rb_tree_iteratorstd::pairconst openvdb::v3_0_0::math::Coord, openvdb::v3_0_0::tree::RootNodeopenvdb::v3_0_0::tree::InternalNodeopenvdb::v3_0_0::tree::InternalNodeopenvdb::v3_0_0::tools::PointIndexLeafNodeopenvdb::v3_0_0::PointIndexunsigned int, 0u, 3u, 4u, 5u ::NodeStruct , openvdb::v3_0_0::tree::RootNodeopenvdb::v3_0_0::tree::InternalNodeopenvdb::v3_0_0::tree::InternalNodeopenvdb::v3_0_0::tools::PointIndexLeafNodeopenvdb::v3_0_0::PointIndexunsigned int, 0u, 3u, 4u, 5u ::ChildOnPred, openvdb::v3_0_0::tree::InternalNodeopenvdb::v3_0_0::tree::InternalNodeopenvdb::v3_0_0::tools::PointIndexLeafNodeopenvdb::v3_0_0::PointIndexunsigned int, 0u, 3u, 4u, 5u ’ ../openvdb/tree/Tree.h:1681:19: required from ‘void openvdb::v3_0_0::tree::Tree_RootNodeType::clipUnallocatedNodes() [with _RootNodeType = openvdb::v3_0_0::tree::RootNodeopenvdb::v3_0_0::tree::InternalNodeopenvdb::v3_0_0::tree::InternalNodeopenvdb::v3_0_0::tools::PointIndexLeafNodeopenvdb::v3_0_0::PointIndexunsigned int, 0u, 3u, 4u, 5u ]’ openvdb.cc:168:1: required from here ../openvdb/tree/TreeIterator.h:441:40: internal compiler error: Speicherzugriffsfehler Please
[Bug rtl-optimization/64616] Redundant ldr when accessing var inside and outside a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64616 thopre01 at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-01-16 Assignee|unassigned at gcc dot gnu.org |thopre01 at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/64015] [5.0 Regression] AArch64 ICE due to conditional compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64015 --- Comment #16 from Jiong Wang jiwang at gcc dot gnu.org --- Author: jiwang Date: Fri Jan 16 11:48:00 2015 New Revision: 219723 URL: https://gcc.gnu.org/viewcvs?rev=219723root=gccview=rev Log: [AArch64] Enable CCMP support for AArch64, PR64015 resolved gcc/ 2015-01-16 Zhenqiang Chen zhenqiang.c...@arm.com PR target/64015 * ccmp.c (expand_ccmp_next): New function. (expand_ccmp_expr_1, expand_ccmp_expr): Handle operand insn sequence and compare insn sequence. * config/aarch64/aarch64.c (aarch64_code_to_ccmode, aarch64_gen_ccmp_first, aarch64_gen_ccmp_next): New functions. (TARGET_GEN_CCMP_FIRST, TARGET_GEN_CCMP_NEXT): New MICRO. * config/aarch64/aarch64.md (*ccmp_and): Changed to ccmp_andmode. (*ccmp_ior): Changed to ccmp_iormode. (cmpmode): New pattern. * doc/tm.texi (TARGET_GEN_CCMP_FIRST, TARGET_GEN_CCMP_NEXT): Update parameters. * target.def (gen_ccmp_first, gen_ccmp_next): Update parameters. gcc/testsuite/ 2015-01-16 Zhenqiang Chen zhenqiang.c...@arm.com * gcc.dg/pr64015.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr64015.c Modified: trunk/gcc/ChangeLog trunk/gcc/ccmp.c trunk/gcc/config/aarch64/aarch64.c trunk/gcc/config/aarch64/aarch64.md trunk/gcc/doc/tm.texi trunk/gcc/target.def trunk/gcc/testsuite/ChangeLog
[Bug target/64015] [5.0 Regression] AArch64 ICE due to conditional compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64015 Jiong Wang jiwang at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #17 from Jiong Wang jiwang at gcc dot gnu.org --- mark as fixed.
[Bug rtl-optimization/64286] [4.9 Regression] Redundant extend removal ignores vector element type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64286 clyon at gcc dot gnu.org changed: What|Removed |Added CC||clyon at gcc dot gnu.org, ||mshawcroft at gcc dot gnu.org, ||ramana at gcc dot gnu.org --- Comment #11 from clyon at gcc dot gnu.org --- For some reason, I am seeing regressions on aarch64 in the 4.9 branch, and not on trunk. The top-level report is here: http://abe.tcwglab.linaro.org/logs/validations/cross-validation/gcc/gcc-4_9-branch/219614/report-build-info.html you can click on the REGRESSED red boxes to see more details.
[Bug target/64628] New: testsuite/c-c++-common/goacc/acc_on_device-2.c:19:10: internal compiler error: Segmentation fault on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64628 Bug ID: 64628 Summary: testsuite/c-c++-common/goacc/acc_on_device-2.c:19:10: internal compiler error: Segmentation fault on ppc64 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org Host: powerpc64-unknown-linux-gnu Target: powerpc64-unknown-linux-gnu Build: powerpc64-unknown-linux-gnu on ppc64: trippels@gcc2-power8 testsuite % gcc -fopenacc -O c-c++-common/goacc/acc_on_device-2.c c-c++-common/goacc/acc_on_device-2.c: In function ‘f’: c-c++-common/goacc/acc_on_device-2.c:19:10: internal compiler error: Segmentation fault return acc_on_device (dev); ^ 0x1080e7ab crash_signal ../../gcc/gcc/toplev.c:381 0x102cf97c expand_builtin_acc_on_device ../../gcc/gcc/builtins.c:5933 0x102f2c43 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int) ../../gcc/gcc/builtins.c:7087 0x10450873 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/gcc/expr.c:10488 0x10462703 expand_expr ../../gcc/gcc/expr.h:254 0x10462703 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) ../../gcc/gcc/expr.c:8248 0x1044f8f3 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/gcc/expr.c:10779 0x1045ef03 expand_expr ../../gcc/gcc/expr.h:254 0x1045ef03 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, tree_node*) ../../gcc/gcc/expr.c:5290 0x1046726f expand_assignment(tree_node*, tree_node*, bool) ../../gcc/gcc/expr.c:5154 0x10316ea7 expand_call_stmt ../../gcc/gcc/cfgexpand.c:2381 0x10316ea7 expand_gimple_stmt_1 ../../gcc/gcc/cfgexpand.c:3327 0x10316ea7 expand_gimple_stmt ../../gcc/gcc/cfgexpand.c:3481 0x1031db17 expand_gimple_basic_block ../../gcc/gcc/cfgexpand.c:5394 0x1031ffa7 execute ../../gcc/gcc/cfgexpand.c:6003 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 tree-optimization/61743] [5 Regression] Complete unroll is not happened for loops with short upper bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61743 --- Comment #18 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Fri Jan 16 12:06:07 2015 New Revision: 219725 URL: https://gcc.gnu.org/viewcvs?rev=219725root=gccview=rev Log: 2015-01-16 Richard Biener rguent...@suse.de PR tree-optimization/61743 * gcc.dg/tree-ssa/pr61743-1.c: Add -fno-tree-vectorize. * gcc.dg/tree-ssa/pr61743-2.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/pr61743-1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/pr61743-2.c
[Bug boehm-gc/64042] FAIL: boehm-gc.c/gctest.c -O2 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64042 vries at gcc dot gnu.org changed: What|Removed |Added CC||aph at redhat dot com, ||pinskia at gmail dot com --- Comment #9 from vries at gcc dot gnu.org --- CC-ing libobjc, java maintainer
[Bug c++/64629] New: [5 Regression] -Wformat-security warns with const char *const vars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64629
Bug ID: 64629
Summary: [5 Regression] -Wformat-security warns with const char
*const vars
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: jason at gcc dot gnu.org
extern void bar (int, const char *, ...) __attribute__((format (printf, 2,
3)));
void
foo (void)
{
const char *const msg = abc;
bar (1, msg);
}
started warning with -Wformat -Wformat-security with r217814. Was that an
intentional change for this case?
Seen on libcpp/, where the first hunk no longer works around the warning
while it used to work with gcc 4.9 and earlier.
[Bug c++/64629] [5 Regression] -Wformat-security warns with const char *const vars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64629 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug c++/64627] Internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64627 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-01-16 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Please attach preprocessed source instead which you obtain when adding -save-temps to the failing compiler command-line (it will be named openvdb.ii). Note that GCC 4.7 is no longer supported so in the event it compiles with GCC 4.8 or newer this bug will be closed as fixed.
[Bug fortran/45290] [F08] pointer initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45290 --- Comment #18 from janus at gcc dot gnu.org --- Author: janus Date: Fri Jan 16 12:49:46 2015 New Revision: 219731 URL: https://gcc.gnu.org/viewcvs?rev=219731root=gccview=rev Log: 2015-01-16 Janus Weil ja...@gcc.gnu.org PR fortran/45290 * decl.c (match_pointer_init): Error out if resolution of init expr failed. 2015-01-16 Janus Weil ja...@gcc.gnu.org PR fortran/45290 * gfortran.dg/pointer_init_6.f90: Extended. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/pointer_init_6.f90
[Bug fortran/45290] [F08] pointer initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45290 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #19 from janus at gcc dot gnu.org --- The patch in comment 16 has been committed as r219731, which fixes the second leftover problem in comment 13. Since the first one is covered by PR 55207, I'm closing this PR.
[Bug fortran/39627] [meta-bug] Fortran 2008 support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39627 Bug 39627 depends on bug 45290, which changed state. Bug 45290 Summary: [F08] pointer initialization https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45290 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/51076] [F2008][tracking] Pointer initialization in init expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51076 Bug 51076 depends on bug 45290, which changed state. Bug 45290 Summary: [F08] pointer initialization https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45290 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug target/64363] Unresolved labels with -fcheck-pointer-bounds and -mmpx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64363 --- Comment #2 from ienkovich at gcc dot gnu.org --- Author: ienkovich Date: Fri Jan 16 13:08:24 2015 New Revision: 219733 URL: https://gcc.gnu.org/viewcvs?rev=219733root=gccview=rev Log: gcc/ PR target/64363 * ipa-chkp.h (chkp_instrumentable_p): New. * ipa-chkp.c: Include tree-inline.h. (chkp_instrumentable_p): New. (chkp_maybe_create_clone): Use chkp_instrumentable_p. Fix processing of not instrumentable functions. (chkp_versioning): Use chkp_instrumentable_p. Warn about not instrumentable functions. * tree-chkp.c (chkp_add_bounds_to_call_stmt): Use chkp_instrumentable_p. * tree-inline.h (copy_forbidden): New. * tree-inline.c (copy_forbidden): Not static anymore. gcc/testsuite/ PR target/64363 * gcc.target/i386/chkp-label-address.c: New. Added: trunk/gcc/testsuite/gcc.target/i386/chkp-label-address.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-chkp.c trunk/gcc/ipa-chkp.h trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-chkp.c trunk/gcc/tree-inline.c trunk/gcc/tree-inline.h
[Bug middle-end/64614] bogus used initialized warning (in gcc 4.9.2); switch statement versus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64614 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to fail||2.95.2, 3.4.6, 4.1.2 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Fails for all versions I tested btw, so nowhere near a regression.
[Bug target/64149] -mno-lra bitrots, suggest to remove for GCC 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64149 --- Comment #5 from Jiong Wang jiwang at gcc dot gnu.org --- Author: jiwang Date: Fri Jan 16 13:11:53 2015 New Revision: 219734 URL: https://gcc.gnu.org/viewcvs?rev=219734root=gccview=rev Log: [AArch64] Remove -mlra/-mno-lra option for Aarch64 2015-01-16 Matthew Wahab matthew.wa...@arm.com gcc/ PR target/64149 * config/aarch64/aarch64.opt: Remove lra option and aarch64_lra_flag variable. * config/aarch64/aarch64.c (TARGET_LRA_P): Set to hook_bool_void_true. (aarch64_lra_p): Remove. Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.c trunk/gcc/config/aarch64/aarch64.opt
[Bug target/64149] -mno-lra bitrots, suggest to remove for GCC 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64149 Jiong Wang jiwang at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||jiwang at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from Jiong Wang jiwang at gcc dot gnu.org --- mark as fixed.
[Bug target/64600] [5.0 regression] arm-rtems ICE on valid code (-mcpu=xscale)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64600 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0 Known to fail||5.0
[Bug target/64606] multiple warnings in arm target code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64606 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-16 CC||ramana at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/64628] testsuite/c-c++-common/goacc/acc_on_device-2.c:19:10: internal compiler error: Segmentation fault on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64628 --- Comment #1 from Uroš Bizjak ubizjak at gmail dot com --- Fixed by r219735?
[Bug middle-end/64568] [5 Regression] error: invalid reference prefix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64568 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Fri Jan 16 13:21:11 2015 New Revision: 219736 URL: https://gcc.gnu.org/viewcvs?rev=219736root=gccview=rev Log: 2015-01-16 Richard Biener rguent...@suse.de PR tree-optimization/64568 * tree-ssa-forwprop.c (pass_forwprop::execute): Guard complex load rewriting for TARGET_MEM_REFs. * g++.dg/torture/pr64568-2.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr64568-2.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-forwprop.c
[Bug middle-end/64568] [5 Regression] error: invalid reference prefix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64568 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug middle-end/64614] bogus used initialized warning (in gcc 4.9.2); switch statement versus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64614 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Fri Jan 16 13:26:10 2015 New Revision: 219739 URL: https://gcc.gnu.org/viewcvs?rev=219739root=gccview=rev Log: 2015-01-16 Richard Biener rguent...@suse.de PR middle-end/64614 * tree-ssa-uninit.c: Include tree-cfg.h. (MAX_SWITCH_CASES): New define. (convert_control_dep_chain_into_preds): Handle switch statements. (is_pred_expr_subset_of): Handle x == CST vs. (x CST) != 0. (normalize_one_pred_1): Do not split bit-manipulations. Record (x CST). * gcc.dg/uninit-18.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/uninit-18.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-uninit.c
[Bug ipa/63576] [5 Regression] ICE : in ipa_merge_profiles, at ipa-utils.c:540 during Firefox LTO/PGO build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63576 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-16 Ever confirmed|0 |1 --- Comment #4 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Happend again today. Honza can you please take a look at Ilya's patch? https://gcc.gnu.org/ml/gcc-patches/2014-10/msg03089.html
[Bug target/64628] testsuite/c-c++-common/goacc/acc_on_device-2.c:19:10: internal compiler error: Segmentation fault on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64628 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Uroš Bizjak from comment #1) Fixed by r219735? Yes. Thanks.
[Bug target/64453] Live high register not saved in function prolog on ARM with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64453 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ramana at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #2 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Fixed presumably.
[Bug libgomp/64625] ___OFFLOAD_TABLE__ symbol not produced on x86_64 darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64625 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- Any hope to have this fixed rapidly? Thousands of failures make testing a nightmare.
[Bug c++/64629] [5 Regression] -Wformat-security warns with const char *const vars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64629 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-01-16 Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug tree-optimization/64434] [5 Regression] Performance regression after operand canonicalization (r216728).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64434 --- Comment #17 from ienkovich at gcc dot gnu.org --- Author: ienkovich Date: Fri Jan 16 14:22:57 2015 New Revision: 219741 URL: https://gcc.gnu.org/viewcvs?rev=219741root=gccview=rev Log: gcc/testsuite/ PR tree-optimization/64434 * gcc.dg/torture/pr64434.c: Move to... * gcc.dg/pr64434.c: ... here. Added: trunk/gcc/testsuite/gcc.dg/pr64434.c - copied unchanged from r219740, trunk/gcc/testsuite/gcc.dg/torture/pr64434.c Removed: trunk/gcc/testsuite/gcc.dg/torture/pr64434.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/64516] arm: wrong unaligned load generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64516 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-16 CC||ramana at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||4.9.0, 4.9.1, 4.9.2, 5.0 --- Comment #1 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Hmmm, I'm not sure if such type punning pushes the attributes through. We seem to think that the alignment will be 16 bits and not 8 bits at expand time. (insn 6 3 7 2 (set (reg:SI 115) (zero_extend:SI (mem:HI (reg/v/f:SI 112 [ p ]) [1 MEM[(const struct TU2 *)p_2(D)]+0 S2 A16]))) /tmp/al.c:17 -1 (nil))
[Bug target/64458] [ARM] Redundant ldr when accessing var inside and outside a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64458 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-01-16 CC||ramana at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Huh, what arch options ? .arm .syntax divided .fileldr.c .text .align2 .globalg .typeg, %function g: @ Function supports interworking. @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. ldrr2, .L5 ldrr3, [r2] .L2: cmpr3, #0 bne.L2 movr3, #1 strr3, [r2] bxlr .L6: .align2 .L5: .wordglob .sizeg, .-g .commglob,4,4
[Bug libstdc++/55997] build of libstd3++ segfaults armv5tel.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55997 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ramana at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #3 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- There is very little here to help reproduce this issue especially as I see others building 4.8.x based compilers on gcc-testresults even today. I think I'm going to mark this as WONTFIX until we know more and let's reopen this if the problem still exists.
[Bug rtl-optimization/64616] Redundant ldr when accessing var inside and outside a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64616 thopre01 at gcc dot gnu.org changed: What|Removed |Added Target||arm-none-eabi --- Comment #1 from thopre01 at gcc dot gnu.org --- At least with -mcpu=cortex-m3 and -mthumb. I haven't tried other combinations yet.
[Bug target/64617] [5 Regression] ICE: Max. number of generated reload insns per insn is achieved (90) with -ftree-vectorize -mavx512bw -march=slm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64617 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-16 CC||jakub at gcc dot gnu.org Target Milestone|--- |5.0 Summary|ICE: Max. number of |[5 Regression] ICE: Max. |generated reload insns per |number of generated reload |insn is achieved (90) with |insns per insn is achieved |-ftree-vectorize -mavx512bw |(90) with -ftree-vectorize |-march=slm |-mavx512bw -march=slm Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with my r218565.
[Bug target/64263] [5.0 Regression] ICE where adddi3_aarch64 does not satisfy its constraints after r217546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64263 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from ktkachov at gcc dot gnu.org --- Fixed with r219745.
[Bug target/64263] [5.0 Regression] ICE where adddi3_aarch64 does not satisfy its constraints after r217546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64263 --- Comment #3 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Fri Jan 16 14:50:39 2015 New Revision: 219745 URL: https://gcc.gnu.org/viewcvs?rev=219745root=gccview=rev Log: [AArch64] Fix PR 64263: Do not try to split constants when destination is SIMD reg PR target/64263 * config/aarch64/aarch64.md (*movsi_aarch64): Don't split if the destination is not a GP reg. (*movdi_aarch64): Likewise. * gcc.target/aarch64/pr64263_1.c: New test. Added: trunk/gcc/testsuite/gcc.target/aarch64/pr64263_1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.md trunk/gcc/testsuite/ChangeLog
[Bug target/64623] ppc64 build failure, ISA_2_7_MASKS_SERVER not declared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64623 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-16 Ever confirmed|0 |1 --- Comment #2 from David Edelsohn dje at gcc dot gnu.org --- Confirmed.
[Bug target/64623] ppc64 build failure, ISA_2_7_MASKS_SERVER not declared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64623 --- Comment #3 from David Edelsohn dje at gcc dot gnu.org --- I temporarily reverted the patch. I need to explicitly include rs6000-cpus.def in default64.h.
[Bug testsuite/64605] [5 Regression] ERROR: (DejaGnu) proc libatomic_target_compile lto1738.c lto1738.o object additional_flags=-flto does not exist.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64605 iverbin at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mikestump at comcast dot net Resolution|--- |FIXED --- Comment #3 from iverbin at gcc dot gnu.org --- Fixed by r219722
[Bug fortran/61933] Inquire on internal units
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61933 --- Comment #8 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- You might notice that we redefined existence to be whether or not it is connected. Units get connected when opened so your sample code needs only ask: IF ((.NOT.is_open).AND.(istat == 0)) RETURN Whether this is what we really want to do of course is open to discussion. The other definition for existence is .true. for all units except -1 which is moot because -1 will give an error and the test for existence is always .true. and not needed. Also unit existence is processor dependent. In your opinion, should we change it to the other definition? Unit existence is sort of a nebulous situation. Will your code be more portable without the test for existence?
[Bug c++/64630] New: error: invalid reference prefix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64630 Bug ID: 64630 Summary: error: invalid reference prefix Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Created attachment 34463 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34463action=edit gzipped C++ source code I just tried to compile the attached C++ code with the latest trunk dated 20150111 on a Fedora Linux x86_64 box. The compiler said /home/dcb/rpmbuild/BUILD/eigen-eigen-b23437e61a07/Eigen/src/Core/SolveTriangular.h:147:15: error: invalid reference prefix static void run(const Lhs lhs, Rhs other) ^ MEM[base: _630, offset: 0] cc1plus: note: in statement # VUSE .MEM_409 pretmp_624 = IMAGPART_EXPR MEM[base: _630, offset: 0]; Flag -O2 required.
[Bug c++/64631] New: error: ‘lgammal_r’ was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64631 Bug ID: 64631 Summary: error: ‘lgammal_r’ was not declared in this scope Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mathieu.malaterre at gmail dot com Created attachment 34464 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34464action=edit demo I cannot compile the following pseudo code (see attachment) it fails with: $ g++ -ffast-math foo.cxx In file included from /usr/include/math.h:432:0, from foo.cxx:3: /usr/include/x86_64-linux-gnu/bits/math-finite.h: In function ‘double lgamma(double)’: /usr/include/x86_64-linux-gnu/bits/math-finite.h:260:41: error: ‘lgamma_r’ was not declared in this scope return lgamma_r (__d, __local_signgam); ^ /usr/include/x86_64-linux-gnu/bits/math-finite.h: In function ‘float lgammaf(float)’: /usr/include/x86_64-linux-gnu/bits/math-finite.h:269:42: error: ‘lgammaf_r’ was not declared in this scope return lgammaf_r (__d, __local_signgam); ^ /usr/include/x86_64-linux-gnu/bits/math-finite.h: In function ‘long double lgammal(long double)’: /usr/include/x86_64-linux-gnu/bits/math-finite.h:279:42: error: ‘lgammal_r’ was not declared in this scope return lgammal_r (__d, __local_signgam); ^ /usr/include/x86_64-linux-gnu/bits/math-finite.h: In function ‘double gamma(double)’: /usr/include/x86_64-linux-gnu/bits/math-finite.h:293:41: error: ‘lgamma_r’ was not declared in this scope return lgamma_r (__d, __local_signgam); ^ /usr/include/x86_64-linux-gnu/bits/math-finite.h: In function ‘float gammaf(float)’: /usr/include/x86_64-linux-gnu/bits/math-finite.h:302:42: error: ‘lgammaf_r’ was not declared in this scope return lgammaf_r (__d, __local_signgam); ^ /usr/include/x86_64-linux-gnu/bits/math-finite.h: In function ‘long double gammal(long double)’: /usr/include/x86_64-linux-gnu/bits/math-finite.h:312:42: error: ‘lgammal_r’ was not declared in this scope return lgammal_r (__d, __local_signgam);
[Bug c++/64631] error: ‘lgammal_r’ was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64631 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- #undef __USE_MISC This causes undefined behaviour, that macro is for the C library to define, not for you to mess with.
[Bug tree-optimization/33651] Request warning on null pointer chk optimized after ptr deref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33651 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-16 CC||ramana at gcc dot gnu.org Ever confirmed|0 |1
[Bug fortran/61933] Inquire on internal units
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61933 --- Comment #9 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Jerry DeLisle from comment #8) You might notice that we redefined existence to be whether or not it is connected. Units get connected when opened so your sample code needs only ask: IF ((.NOT.is_open).AND.(istat == 0)) RETURN Whether this is what we really want to do of course is open to discussion. The other definition for existence is .true. for all units except -1 which is moot because -1 will give an error and the test for existence is always .true. and not needed. Also unit existence is processor dependent. In your opinion, should we change it to the other definition? Unit existence is sort of a nebulous situation. Will your code be more portable without the test for existence? The code in comment #7 worked on all compilers we had access to (and is part of our released code since ages), so this change of behaviour would be a problem. I think unless gfortran has a maximum for the allowed unit numbers, any postive unit number should exist (i.e. can possibly be used in an open statement). Since: cat test.f90 open(UNIT=HUGE(1_16)) END yields: ./a.out At line 1 of file test.f90 Fortran runtime error: Unit number in I/O statement too large that would be a unit that doesn't exist.
[Bug bootstrap/63771] internal compiler error: in lra_create_copy, at lra.c:1532
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63771 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ramana at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #4 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Marking as duplicate in the absence of any other information. *** This bug has been marked as a duplicate of bug 63740 ***
[Bug bootstrap/63740] [4.9 Regression] GCC 4.9.2 bootstrap fails on ARM, haifa-sched.c:6507:1: internal compiler error: in lra_create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63740 --- Comment #11 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- *** Bug 63771 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/64601] Missed PRE on std::vector move assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64601
--- Comment #8 from Marc Glisse glisse at gcc dot gnu.org ---
With the modified hack below, the testsuite passes, except:
gcc.dg/tree-ssa/scev-[34].c those go from xfail to pass, that sounds good
g++.dg/tree-ssa/pr31146.C seems that the scan-tree-dump is too strict
c-c++-common/ubsan/object-size-9.c for some reason it prints memory cannot be
printed instead of a bunch of 0s but I can't reproduce outside the dg
framework, doesn't seem very important.
I had to add a couple checks compared to the first version. Giving up on
volatile operands, sure, there is probably a better way but whatever. Forwprop
tends to feed artificial MEM_REF[(void*)...] to this function in many cases
(POINTER_PLUS_EXPR in particular), which causes a number of issues (including,
surprisingly, assuming too strong alignment). Testing for ptr_type_node is a
hack, but the necessity for it is just an artifact of placing the
transformation there, it shouldn't be necessary if I put it elsewhere.
The transformation is triggered by dereferences, and compares the types of
objects, not pointers, so it isn't obvious that the issues you were describing
apply to it.
--- tree-ssa-forwprop.c(revision 219694)
+++ tree-ssa-forwprop.c(working copy)
@@ -777,20 +777,49 @@ forward_propagate_addr_expr_1 (tree name
new_def_rhs);
else if (is_gimple_min_invariant (new_def_rhs))
gimple_assign_set_rhs_with_ops (use_stmt_gsi, NOP_EXPR, new_def_rhs);
else
return false;
gcc_assert (gsi_stmt (*use_stmt_gsi) == use_stmt);
update_stmt (use_stmt);
return true;
}
+ /* *X - X. */
+ if (TREE_CODE (lhs) == MEM_REF
+ !gimple_has_volatile_ops (use_stmt)
+ TREE_OPERAND (lhs, 0) == name
+ integer_zerop (TREE_OPERAND (lhs, 1))
+ (TREE_CODE (TREE_OPERAND (def_rhs, 0)) != MEM_REF
+ || TREE_TYPE (TREE_OPERAND (TREE_OPERAND (def_rhs, 0), 1))
+ != ptr_type_node)
+ useless_type_conversion_p (TREE_TYPE (lhs),
+TREE_TYPE (TREE_OPERAND (def_rhs, 0
+{
+ gimple_assign_set_lhs (use_stmt, unshare_expr (TREE_OPERAND (def_rhs,
0)));
+ tidy_after_forward_propagate_addr (use_stmt);
+ return true;
+}
+ else if (TREE_CODE (rhs) == MEM_REF
+ !gimple_has_volatile_ops (use_stmt)
+ TREE_OPERAND (rhs, 0) == name
+ integer_zerop (TREE_OPERAND (rhs, 1))
+ (TREE_CODE (TREE_OPERAND (def_rhs, 0)) != MEM_REF
+ || TREE_TYPE (TREE_OPERAND (TREE_OPERAND (def_rhs, 0), 1))
+ != ptr_type_node)
+ useless_type_conversion_p (TREE_TYPE (rhs),
+TREE_TYPE (TREE_OPERAND (def_rhs, 0
+{
+ gimple_assign_set_rhs1 (use_stmt, unshare_expr (TREE_OPERAND (def_rhs,
0)));
+ tidy_after_forward_propagate_addr (use_stmt);
+ return true;
+}
/* Now strip away any outer COMPONENT_REF/ARRAY_REF nodes from the LHS.
ADDR_EXPR will not appear on the LHS. */
tree *lhsp = gimple_assign_lhs_ptr (use_stmt);
while (handled_component_p (*lhsp))
lhsp = TREE_OPERAND (*lhsp, 0);
lhs = *lhsp;
/* Now see if the LHS node is a MEM_REF using NAME. If so,
propagate the ADDR_EXPR into the use of NAME and fold the result. */
if (TREE_CODE (lhs) == MEM_REF
[Bug libgomp/64625] ___OFFLOAD_TABLE__ symbol not produced on x86_64 darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64625 --- Comment #5 from howarth at bromo dot med.uc.edu --- Does this imply that significant chunks of dead code exists in this merge?
[Bug middle-end/64353] [5 Regression] ICE: in execute_todo, at passes.c:1986
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64353 --- Comment #8 from ienkovich at gcc dot gnu.org --- Author: ienkovich Date: Fri Jan 16 15:38:21 2015 New Revision: 219748 URL: https://gcc.gnu.org/viewcvs?rev=219748root=gccview=rev Log: gcc/ PR middle-end/64353 * tree-cfg.c (pass_data_fixup_cfg): Update SSA for virtuals on start. gcc/testsuite/ PR middle-end/64353 * g++.dg/pr64353.C: New. Added: trunk/gcc/testsuite/g++.dg/pr64353.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c
[Bug fortran/61933] Inquire on internal units
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61933 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #10 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- It occurs to me another possible interpretation of what a unit existence might be. Behind the scenes when opening a unit with no filename we create a file named for example fort.10. That file name is processor dependent and the user should not know what that filename is. (we know by convention of course) I wonder now whether we should define unit existence to be whether or not the corresponding file (or device, or whatever it is) exists on the system. This starts to make some sense when you think about it and could assist a user from inadvertently overwriting some existing data. I am going to reopen this for further discussion. I do agree with your issue.
[Bug rtl-optimization/60162] [4.9/5 Regression][lra] mlra appears to be using the FP registers for integer values and then moving on to GPR registers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60162 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #9 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Not sure what's going on here, as I'm unable to reproduce this now.
[Bug middle-end/57748] [4.8 Regression] ICE when expanding assignment to unaligned zero-sized array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748 --- Comment #57 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #56) GCC 4.8.4 has been released. If it's too late to backport this to 4.8 we might as well close this off targeting it for 4.9. Ramana
[Bug c++/64630] error: invalid reference prefix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64630 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- This issue was fixed today. Dup. *** This bug has been marked as a duplicate of bug 64568 ***
[Bug middle-end/64568] [5 Regression] error: invalid reference prefix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64568 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #10 from Markus Trippelsdorf trippels at gcc dot gnu.org --- *** Bug 64630 has been marked as a duplicate of this bug. ***
[Bug lto/63607] run fail with -flto -mfloat-abi=softfp for armeb-linux-gnueabi-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63607 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #3 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- (In reply to Fei Yang from comment #2) (In reply to Richard Biener from comment #1) Is -mfloat-abi=softfp properly used at LTO stage? It seems that -mfloat-abi=softfp is here for lto1: /home/lxr/install/bin/../lib/gcc/../../libexec/gcc/armeb-linux-gnueabi/4.7. 1/lto1 -quiet -dumpdir ./ -dumpbase 1.wpa -mfloat-abi=softfp -march=armv7-a -mtls-dialect=gnu -mfloat-abi=softfp -march=armv7-a -mtls-dialect=gnu -auxbase cc9cih7t -O2 -version -fltrans-output-list=/tmp/ccZqlDqA.ltrans.out -fwpa -fresolution=/tmp/ccUnDlh3.res @/tmp/ccSi9hcz Can you check if it occurs with 4.8 , 4.9 or trunk today ? I don't really have a big endian environment setup to reproduce this easily enough.
[Bug fortran/61933] Inquire on internal units
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61933 --- Comment #11 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Jerry DeLisle from comment #10) It occurs to me another possible interpretation of what a unit existence might be. Behind the scenes when opening a unit with no filename we create a file named for example fort.10. That file name is processor dependent and the user should not know what that filename is. (we know by convention of course) I wonder now whether we should define unit existence to be whether or not the corresponding file (or device, or whatever it is) exists on the system. This starts to make some sense when you think about it and could assist a user from inadvertently overwriting some existing data. I don't think this is the intended behavior. I really think the meaning rather is, can we in principle open a file on that unit number (like from the good old days, is a tape drive mechanically connected to it). I'm reading the F2008 standard, and the guidance given in 9.5.3 is not much... However, external files and external units seem to be conceptually quite different (see also note 9.16) I am going to reopen this for further discussion. I do agree with your issue. thanks also for your efforts in fixing these things!
[Bug target/63250] Complex fp16 arithmetic uses nonexistent libgcc functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63250 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-16 CC||ramana at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- (In reply to Joseph S. Myers from comment #1) Author: jsm28 Date: Tue Sep 23 00:48:46 2014 New Revision: 215491 URL: https://gcc.gnu.org/viewcvs?rev=215491root=gccview=rev Log: Remove LIBGCC2_LONG_DOUBLE_TYPE_SIZE target macro. This patch removes the target macro LIBGCC2_LONG_DOUBLE_TYPE_SIZE. Joseph, how does this patch go towards fixing this issue as it doesn't even touch the ARM backend ? Confirming the bug though as I do see the calls to __mulhc3 as expected even today on trunk.
[Bug web/62211] ./configure --with-float= and ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62211 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Keywords||documentation Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-16 CC||ramana at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1
[Bug libgomp/64625] ___OFFLOAD_TABLE__ symbol not produced on x86_64 darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64625
--- Comment #6 from howarth at bromo dot med.uc.edu ---
The code producing this problematic symbol appears to be...
/* Holds a decl for __OFFLOAD_TABLE__. */
static GTY(()) tree offload_symbol_decl;
/* Get the __OFFLOAD_TABLE__ symbol. */
static tree
get_offload_symbol_decl (void)
{
if (!offload_symbol_decl)
{
tree decl = build_decl (UNKNOWN_LOCATION, VAR_DECL,
get_identifier (__OFFLOAD_TABLE__),
ptr_type_node);
TREE_ADDRESSABLE (decl) = 1;
TREE_PUBLIC (decl) = 1;
DECL_EXTERNAL (decl) = 1;
DECL_WEAK (decl) = 1;
DECL_ATTRIBUTES (decl)
= tree_cons (get_identifier (weak),
NULL_TREE, DECL_ATTRIBUTES (decl));
offload_symbol_decl = decl;
}
return offload_symbol_decl;
}
in mop-low.c but get_offload_symbol_decl() is used to assign offload_table in
expand_omp_target().
[Bug middle-end/57748] [4.8 Regression] ICE when expanding assignment to unaligned zero-sized array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748 --- Comment #58 from Bernd Edlinger bernd.edlinger at hotmail dot de --- IIRC it was first fixed in 4.9.0. The known to fail above includes 4.9.0 but that is wrong. Do you think this is still worth to be fixed in 4.8.5 ?
[Bug libstdc++/64632] New: runtime error: member call on address 0x0000004318a8 which does not point to an object of type 'ios_base'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64632 Bug ID: 64632 Summary: runtime error: member call on address 0x004318a8 which does not point to an object of type 'ios_base' Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org Created attachment 34465 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34465action=edit testcase markus@x4 ~ % g++ -fsanitize=undefined -O2 bench.cpp markus@x4 ~ % ./a.out sizearray vector_pointvector_itersdeque listset multiset /usr/lib/gcc/x86_64-pc-linux-gnu/5.0.0/include/g++-v5/bits/ios_base.h:1037:16: runtime error: member call on address 0x004318a8 which does not point to an object of type 'ios_base' 0x004318a0: note: object is base class subobject at offset 8 within object of type 'std::ostream' 00 00 00 00 a8 17 ce 25 ca 7f 00 00 d0 17 ce 25 ca 7f 00 00 06 00 00 00 00 00 00 00 00 00 00 00 ^~~~ vptr for 'unknown' base class of 'std::ostream' /usr/lib/gcc/x86_64-pc-linux-gnu/5.0.0/include/g++-v5/iomanip:210:7: runtime error: member call on address 0x004318a8 which does not point to an object of type 'ios_base' 0x004318a0: note: object is base class subobject at offset 8 within object of type 'std::ostream' 00 00 00 00 a8 17 ce 25 ca 7f 00 00 d0 17 ce 25 ca 7f 00 00 06 00 00 00 00 00 00 00 00 00 00 00 ^~~~ vptr for 'unknown' base class of 'std::ostream' 10 0.230.230.410.77 1.570.971.44 ^C markus@x4 ~ % clang++ -fsanitize=undefined -O2 bench.cpp markus@x4 ~ % ./a.out sizearray vector_pointvector_itersdeque listset multiset /usr/lib64/gcc/x86_64-pc-linux-gnu/5.0.0/include/g++-v5/bits/ios_base.h:102:24: runtime error: load of value 4294967035, which is not a valid value for type 'std::_Ios_Fmtflags' /usr/lib64/gcc/x86_64-pc-linux-gnu/5.0.0/include/g++-v5/bits/ios_base.h:82:67: runtime error: load of value 4294967035, which is not a valid value for type 'std::_Ios_Fmtflags' 10 0.260.280.512.13 3.811.262.04 ^C
