[Bug c++/70096] [6 Regression] [Invalid codegen] Read of uninitialized value in ref-qualified pointer to member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70096 Markus Trippelsdorf changed: What|Removed |Added CC||jason at gcc dot gnu.org Severity|major |normal --- Comment #2 from Markus Trippelsdorf --- Started with r229018: commit f16ed232f63165d926986d482708ebf464a04108 Author: jason Date: Tue Oct 20 02:48:43 2015 + Expand PTRMEM_CST only when necessary.
[Bug c/70104] New: Should give an error when using multiple case value in switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70104
Bug ID: 70104
Summary: Should give an error when using multiple case value in
switch
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: np199113 at gmail dot com
Target Milestone: ---
In switch case if one case uses two values it does not give error but multiple
case use two values it gives error.
For example:-
int iswovel(char ch)
{
switch(ch)
{
case 'a' || 'A':
case 'e':
case 'i':
case 'o':
case 'u':return 1;
default:return 0;
}
}
It does not give error But
In this example:-
int iswovel(char ch)
{
switch(ch)
{
case 'a' || 'A':
case 'e' || 'E':
case 'i':
case 'o':
case 'u':return 1;
default:return 0;
}
}
It gives error.
[Bug c++/70105] New: [6 regression] giant warning when building gcc-5 with gcc-6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70105 Bug ID: 70105 Summary: [6 regression] giant warning when building gcc-5 with gcc-6 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org CC: dmalcolm at gcc dot gnu.org Target Milestone: --- markus@x4 gcc % 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 -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/bid -I../libdecnumber -I../../gcc/gcc/../libbacktrace -o tree-complex.o -MT tree-complex.o -MMD -MP -MF ./.deps/tree-complex.TPo ../../gcc/gcc/tree-complex.c In file included from ./tm.h:27:0, from ../../gcc/gcc/tree-complex.c:23: ../../gcc/gcc/config/elfos.h:102:21: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix] fprintf ((FILE), "%s"HOST_WIDE_INT_PRINT_UNSIGNED"\n",\ ^ ../../gcc/gcc/config/elfos.h:170:24: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix] fprintf ((FILE), ","HOST_WIDE_INT_PRINT_UNSIGNED",%u\n", \ ^ In file included from ./tm.h:48:0, from ../../gcc/gcc/tree-complex.c:23: ../../gcc/gcc/defaults.h:126:24: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix] fprintf ((FILE), ","HOST_WIDE_INT_PRINT_UNSIGNED",%u\n", \ ^ In file included from ../../gcc/gcc/tree-complex.c:57:0: ../../gcc/gcc/tree-complex.c: In function ‘tree_node* create_one_component_var(tree, tree, const char*, const char*, tree_code)’: ../../gcc/gcc/../include/libiberty.h:184:25: warning: operation on ‘libiberty_concat_ptr’ may be undefined [-Wsequence-point] (libiberty_concat_ptr = (char *) alloca (concat_length ACONCAT_PARAMS + 1), \ ~^~~ concat_copy2 ACONCAT_PARAMS) /* Check whether two file descriptors refer to the same file. */ ~ extern int fdmatch (int fd1, int fd2); ~~ /* Return the position of the first bit set in the argument. */ /* Prototypes vary from system to system, so we only provide a ~~ prototype on systems where we know that we need it. */ ~~~ #if defined (HAVE_DECL_FFS) && !HAVE_DECL_FFS ~ extern int ffs(int); #endif ~~ /* Get the working directory. The result is cached, so don't call ~~ chdir() between calls to getpwd(). */ ~~ extern char * getpwd (void); /* Get the current time. */ /* Prototypes vary from system to system, so we only provide a ~~ prototype on systems where we know that we need it. */ ~~~ #ifdef __MINGW32__ ~~ /* Forward declaration to avoid #include . */ ~~~ struct timeval; ~~~ extern int gettimeofday (struct timeval *, void *); ~~~ #endif ~~ /* Get the amount of time the process has run, in microseconds. */ ~~~ extern long get_run_time (void); /* Generate a relocated path to some installation directory. Allocates ~~~ return value using malloc. */ ~~ extern char *make_relative_prefix (const char *, const char *, ~~ const char *) ATTRIBUTE_MALLOC; ~~~ /* Generate a relocated path to some instal
[Bug c/70104] Should give an error when using multiple case value in switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70104 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Jakub Jelinek --- 'a' || 'A' is 1, so there is no reason to give an error about it. The error in the second case is because you have two case labels with the same value, 1. That is not allowed in a switch.
[Bug c++/70105] [6 regression] giant warning when building gcc-5 with gcc-6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70105 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-03-06 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed.
[Bug middle-end/70100] [5 Regression] ICE: in execute, at cfgexpand.c:6066
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70100
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work||6.0
Last reconfirmed||2016-03-06
Component|c++ |middle-end
CC||trippels at gcc dot gnu.org
Ever confirmed|0 |1
Summary|internal compiler error: in |[5 Regression] ICE: in
|execute, at |execute, at
|cfgexpand.c:6066|cfgexpand.c:6066
Severity|major |normal
--- Comment #1 from Markus Trippelsdorf ---
markus@x4 /tmp % cat main.ii
namespace std {
template struct integral_constant {
static constexpr _Tp value = 0;
};
template _Tp declval;
template
struct is_same : integral_constant {};
template struct A { typedef _Tp type; };
template struct A<_Tp &> { typedef _Tp type; };
template struct B { typedef typename A<_Tp>::type type; };
template struct enable_if;
template struct C;
template struct D {};
template > struct F;
}
template using Decay = typename std::B::type;
namespace std {
struct G {
G(int);
};
}
template struct Gen {
template ::value>>
Gen(Impl &&);
struct H;
template struct L;
H *m_impl;
};
template struct Gen::H {};
template template struct Gen::L : H {
template L(Args... args) : m_impl(args...), m_count(0) {
m_impl(0, 0);
}
Impl m_impl;
std::G m_count;
};
template
template
Gen::Gen(Impl &&impl) : m_impl(new L>(impl)) {}
namespace state {
template struct Command {
using Model = int;
using CommandType = Command;
};
template using Commands = std::F>;
template )>
void check(MakeInitialState &&, Sut &, GenFunc &&);
namespace gen {
template ::value>>
Gen> commands(MakeInitialState &&, GenerationFunc &&);
template struct I {
template
I(InitialStateArg, GenFuncArg);
void operator()(int, int) { J(0, 0, m_genFunc, 0); }
struct J {
J(int, int, GenFunc, int) { m_genFunc(0); }
GenFunc m_genFunc;
};
GenFunc m_genFunc;
};
template
Gen> commands(MakeInitialState &&, GenerationFunc &&) {
return I>(0, 0);
}
}
template
void check(MakeInitialState &&, Sut &, GenFunc &&generationFunc) {
using Model = Decay;
gen::commands>(0, generationFunc);
}
namespace gen {
template struct K {
using CmdSP = std::D;
template void operator()(Args... args) {
using MakeFunc = CmdSP(...);
MakeFunc makeFuncs;
[=] { [=] { makeFuncs(args...); }; };
}
};
template K execOneOfWithArgs();
}
}
using DbCommand = state::Command;
struct Get : DbCommand {};
int main() {
void db();
check(0, db, state::gen::execOneOfWithArgs());
}
markus@x4 /tmp % /usr/x86_64-pc-linux-gnu/gcc-bin/5.3.1/g++ -std=c++14 -c
main.ii
main.ii: In member function ‘void state::gen::K::operator()(Args ...)
[with Args = {int}; Cmd = Get]’:
main.ii:79:36: internal compiler error: in execute, at cfgexpand.c:6069
Might be related to PR68798.
[Bug middle-end/23868] [4.9/5/6 regression] builtin_apply uses wrong mode for multi-hard-register return values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23868
--- Comment #28 from Oleg Endo ---
I've just briefly checked gcc/testsuite/gcc.dg/builtin-apply4.c on sh-elf after
removing the following conditions:
Index: gcc/testsuite/gcc.dg/builtin-apply4.c
===
--- gcc/testsuite/gcc.dg/builtin-apply4.c (revision 234013)
+++ gcc/testsuite/gcc.dg/builtin-apply4.c (working copy)
@@ -1,8 +1,6 @@
/* PR tree-optimization/20076 */
/* { dg-options "-O2 -Wmissing-noreturn -fgnu89-inline" } */
-/* { dg-additional-options "-mno-mmx" { target { { i?86-*-* x86_64-*-* } &&
ia32 } } } */
/* { dg-do run } */
-/* { dg-require-effective-target untyped_assembly } */
extern void abort (void);
It seems the test passes on sh-elf.
Can anybody comment on the state of this problem here? Were the two commits in
comment #2 and comment #3 merged into mainline at some point?
[Bug c++/70106] New: [4.9/5.3/6.0][C++11 or above] adding parenthesis [cerr << (var)] cause error: invalid static_cast from type 'const size_t {aka const long unsigned int}' to type 'size_t& {aka long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70106
Bug ID: 70106
Summary: [4.9/5.3/6.0][C++11 or above] adding parenthesis [cerr
<< (var)] cause error: invalid static_cast from type
'const size_t {aka const long unsigned int}' to type
'size_t& {aka long unsigned int&}'
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david.abdurachmanov at gmail dot com
Target Milestone: ---
Created attachment 37878
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37878&action=edit
test case
I came across this while recompiling our repositories with GCC 6.0.0 (r233941,
a couple of days old already). Only happens with C++11 or above. Seems to
affect GCC 4.9.3, 5.3.0, and GCC 6.0.0. Works fine with Clang 3.7.0 and the
latest version of ICC (16.0.2 20160204).
I did run C-Reduce and then did some additional manual minimisation.
Test case attached.
### COMPILING ###
g++ -std=c++14 -Wno-deprecated -c ratext_worker_min_new.cpp -fPIC -o
ratext_worker.o
### ERROR ###
ratext_worker_min_new.cpp: In instantiation of ‘const int&
momentum_configuration< >::p(size_t) const [with
= int; size_t = long unsigned int]’:
ratext_worker_min_new.cpp:22:25: required from ‘void momentum_configuration<
>::mom(size_t) [with = int;
size_t = long unsigned int]’
ratext_worker_min_new.cpp:53:3: required from ‘void triangle_Rat_plusminus<
,
RatTriSpecs>::get_sub_terms_work(momentum_configuration&, const
std::vector&, triangle_param&) [with T = int; = rat_worker; RatTriSpecs =
Higgs_RatTri_Specification]’
ratext_worker_min_new.cpp:58:50: required from here
ratext_worker_min_new.cpp:28:13: error: invalid static_cast from type ‘const
size_t {aka const long unsigned int}’ to type ‘size_t& {aka long unsigned
int&}’
std::cerr << (momentum_configuration::nbr);
^
### EXPECTATIONS ###
The issue is this line:
28 std::cerr << (momentum_configuration::nbr);
Removing parenthesis resolves the issue:
28 std::cerr << momentum_configuration::nbr;
Clang and ICC compile the code in C++14 with and without the parenthesis.
[Bug debug/24801] -d option changes debug information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24801 Oleg Endo changed: What|Removed |Added CC||olegendo at gcc dot gnu.org --- Comment #3 from Oleg Endo --- (In reply to Jorn Wolfgang Rennecke from comment #1) > > For sh-elf, > ./cc1 -fpreprocessed -g -O2 l0.c -o l0.s-0 > ./cc1 -fpreprocessed -g -O2 l0.c -o l0.s-01 > ./cc1 -fpreprocessed -g -O2 l0.c -o l0.s-02 > all produce the same result (with address space randomization active), > which is differs in debug info from what you get with any of: > ./cc1 -fpreprocessed -g -O2 l0.c -o l0.s-1 -da > ./cc1 -fpreprocessed -g -O2 l0.c -o l0.s-11 -da > ./cc1 -fpreprocessed -g -O2 l0.c -o l0.s-12 -da (In reply to Richard Biener from comment #2) > Still? I have checked the test case on sh-elf with the above flags. The resulting files are identical. I guess we can close this PR. Not sure how to add the test case to the test suite though.
[Bug middle-end/70087] Different (worse?) code generated for "if (a || (b || c))" vs "if (a || b || c)"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70087 Patrick Palka changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Patrick Palka --- Tagged as a duplicate *** This bug has been marked as a duplicate of bug 67628 ***
[Bug tree-optimization/67628] [tree-optimization] (a && b) && c shows better codegen than a && (b && c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67628 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org --- Comment #5 from Patrick Palka --- *** Bug 70087 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/27394] double -> char conversion varies with optimization level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27394 Oleg Endo changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||olegendo at gcc dot gnu.org Resolution|--- |INVALID Known to fail|| --- Comment #9 from Oleg Endo --- I've briefly checked this issue on trunk / sh-elf. For -O0 function 'f' returns -128, while -O1 returs 127. At -O1 'f' gets inlined and main returns '1'. Anyway, I think this can be closed. The test case is showing that undefined behavior is undefined while the main motivation seems to be debugging. For that there are more modern debugging tools available these days. For example the option -fsanitize=float-cast-overflow will catch this problem.
[Bug other/29842] [meta-bug] outstanding patches / issues from STMicroelectronics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29842 Bug 29842 depends on bug 27394, which changed state. Bug 27394 Summary: double -> char conversion varies with optimization level https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27394 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug c++/67185] [C++14] Link error on ODR-use of variable template partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67185
Casey Carter changed:
What|Removed |Added
CC||Casey at Carter dot net
Version|6.0 |5.3.0
Blocks|67491 |
Summary|[concepts] Link error on|[C++14] Link error on
|ODR-use of constexpr|ODR-use of variable
|constrained variable|template partial
|template partial|specialization
|specialization |
--- Comment #1 from Casey Carter ---
This same bug is triggered by the purely C++14 program:
template
bool x = false;
template
bool x = true;
bool& f() { return x; }
int main() {}
which when compiled with either g++ 5.3 or 6 results in
/tmp/ccHHu1ip.o: In function `f()':
prog.cc:(.text+0x5): undefined reference to `x'
collect2: error: ld returned 1 exit status
The problem has nothing to do with concepts or constexpr, but seems to be a
general issue when ODR-using an instance of a template variable that was
instantiated from a partial specialization. I'm recasting this as a C++14 bug
against 5.3.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues
[Bug c++/67210] [concepts] Error parsing ">>" after a template-id that names a concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67210 Casey Carter changed: What|Removed |Added Attachment #36183|0 |1 is obsolete|| CC||Casey at Carter dot net --- Comment #1 from Casey Carter --- Created attachment 37879 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37879&action=edit Minimal non-concepts (C++14) test case
[Bug c++/67185] [C++14] Link error on ODR-use of variable template partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67185 Casey Carter changed: What|Removed |Added Attachment #36170|0 |1 is obsolete|| --- Comment #2 from Casey Carter --- Created attachment 37880 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37880&action=edit Minimal non-concepts (C++14) test case
[Bug tree-optimization/27394] double -> char conversion varies with optimization level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27394 Bug 27394 depends on bug 28144, which changed state. Bug 28144 Summary: floating point constant -> byte/char/short conversion is wrong for java https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28144 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug tree-optimization/28144] floating point constant -> byte/char/short conversion is wrong for java
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28144 Oleg Endo changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||olegendo at gcc dot gnu.org Resolution|--- |INVALID --- Comment #6 from Oleg Endo --- Closing as invalid for the same reason as PR 27394.
[Bug other/29842] [meta-bug] outstanding patches / issues from STMicroelectronics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29842 Bug 29842 depends on bug 28144, which changed state. Bug 28144 Summary: floating point constant -> byte/char/short conversion is wrong for java https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28144 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug c++/67185] [C++14] Link error on ODR-use of variable template partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67185 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-03-06 CC||trippels at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Markus Trippelsdorf --- With -flto we even ICE: markus@x4 /tmp % g++ -flto temp.ii temp.ii:9:13: internal compiler error: in write_symbol, at lto-streamer-out.c:2561
[Bug c++/67185] [C++14] Link error on ODR-use of variable template partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67185
--- Comment #4 from Markus Trippelsdorf ---
With checking:
temp.ii:9:13: internal compiler error: in get_partitioning_class, at
symtab.c:1794
int main() {}
^
0x90b559 symtab_node::get_partitioning_class()
../../gcc/gcc/symtab.c:1794
0xbab37f lto_output_varpool_node
../../gcc/gcc/lto-cgraph.c:611
0xbab37f output_symtab()
../../gcc/gcc/lto-cgraph.c:1021
0xbbd5ea lto_output()
../../gcc/gcc/lto-streamer-out.c:2381
0xc2c0ae write_lto
../../gcc/gcc/passes.c:2434
0xc2f9de ipa_write_summaries_1
../../gcc/gcc/passes.c:2498
0xc2f9de ipa_write_summaries()
../../gcc/gcc/passes.c:2558
0x921c7f ipa_passes
../../gcc/gcc/cgraphunit.c:2308
0x921c7f symbol_table::compile()
../../gcc/gcc/cgraphunit.c:2402
0x9244d2 symbol_table::compile()
../../gcc/gcc/cgraphunit.c:2536
0x9244d2 symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2562
Please submit a full bug report,
[Bug rtl-optimization/29854] reload_combine looses track of uses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29854 Oleg Endo changed: What|Removed |Added CC||kkojima at gcc dot gnu.org, ||olegendo at gcc dot gnu.org --- Comment #6 from Oleg Endo --- (In reply to Jorn Wolfgang Rennecke from comment #0) > > A patch is here: > http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01387.html And the latest feedback for that was this: https://gcc.gnu.org/ml/gcc-patches/2006-01/msg01473.html Looking at the current code in postreload.c, it seems that the patch somehow made it into mainline at some point. Although some of the lines now look a bit different. Can we close this PR as "works for me"?
[Bug target/70107] ICE: in emit_move_insn, at expr.c:3546 with -mcpu=power8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70107 --- Comment #1 from Markus Trippelsdorf --- All supported gcc versions ICE.
[Bug target/70107] New: ICE: in emit_move_insn, at expr.c:3546 with -mcpu=power8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70107
Bug ID: 70107
Summary: ICE: in emit_move_insn, at expr.c:3546 with
-mcpu=power8
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
Target Milestone: ---
Target: ppc64le
trippels@gcc2-power8 test % cat apply.ii
struct {
template
auto operator()(T Base::*, Derived ref) -> decltype(ref);
} a;
struct TestClass {};
template
void test_b12(Functor f) {
using ClassFunc = Signature TestClass::*;
ClassFunc b;
a(b, f);
}
void foo() {
TestClass c;
test_b12(c);
}
trippels@gcc2-power8 test % /home/trippels/gcc_test/usr/local/bin/g++ -w -c
-mcpu=power8 apply.ii
apply.ii: In function ‘void test_b12(Functor) [with Signature = int();
= int; Functor = TestClass]’:
apply.ii:10:4: internal compiler error: in emit_move_insn, at expr.c:3546
a(b, f);
~^~
0x106cd757 emit_move_insn(rtx_def*, rtx_def*)
../../gcc/gcc/expr.c:3545
0x10558def load_register_parameters
../../gcc/gcc/calls.c:2047
0x10558def expand_call(tree_node*, rtx_def*, int)
../../gcc/gcc/calls.c:3329
0x106c699f expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/gcc/expr.c:10594
0x10570907 expand_expr
../../gcc/gcc/expr.h:256
0x10570907 expand_call_stmt
../../gcc/gcc/cfgexpand.c:2660
0x10570907 expand_gimple_stmt_1
../../gcc/gcc/cfgexpand.c:3548
0x10570907 expand_gimple_stmt
../../gcc/gcc/cfgexpand.c:3714
0x10574413 expand_gimple_basic_block
../../gcc/gcc/cfgexpand.c:5720
0x10579887 execute
../../gcc/gcc/cfgexpand.c:6335
[Bug target/29969] should use floating point registers for block copies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29969 --- Comment #5 from Oleg Endo --- (In reply to Oleg Endo from comment #4) > If this is true, using 64 bit fmov for block moves could be beneficial. > Still, I'd not enable this by default but allow the user to turn it on > with an -m option. Actually, for an FP enabled target the only case where it is counter productive is interrupt handlers. If that's the only FP use in the ISR, it will add register push/pops. To avoid this, it's better to also have a function attribute to enable or disable FP mode copies.
[Bug c/70089] ARM/THUMB unnecessarily typecasts some rvalues on memory store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70089 Richard Earnshaw changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE |--- --- Comment #3 from Richard Earnshaw --- Re-opening.
[Bug c/70088] ARM/THUMB unnecessarily typecasts some rvalues on memory store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70088 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Richard Earnshaw --- Dup *** This bug has been marked as a duplicate of bug 70089 ***
[Bug c/70089] ARM/THUMB unnecessarily typecasts some rvalues on memory store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70089 --- Comment #4 from Richard Earnshaw --- *** Bug 70088 has been marked as a duplicate of this bug. ***
[Bug target/70098] PowerPC64: eigen hits ICE in reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70098 Segher Boessenkool changed: What|Removed |Added Status|ASSIGNED|NEW CC||vmakarov at gcc dot gnu.org --- Comment #4 from Segher Boessenkool --- No matter what I try, I cannot convince IRA not to use FLOAT_REGS here. Vladimir, any ideas?
[Bug fortran/70058] Segmentation fault when open file with existing file and status = "UNKNOWN"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70058 --- Comment #8 from Paul --- I downloaded the latest version I could find from https://sourceforge.net/projects/mingw-w64/?source=typ_redirect. It is version 5.3.0. The problem does not exist with version 5.3.0. My apologies for not finding the latest gfortran version earlier.
[Bug testsuite/70108] New: FAIL: gcc.dg/simulate-thread/speculative-store-2.c -O0 -g thread simulation test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70108 Bug ID: 70108 Summary: FAIL: gcc.dg/simulate-thread/speculative-store-2.c -O0 -g thread simulation test Product: gcc Version: 5.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Target Milestone: --- Host: hppa2.0w-hp-hpux11.11 Target: hppa2.0w-hp-hpux11.11 Build: hppa2.0w-hp-hpux11.11 This is a new fail on 5.3.1 and 6.0.0. It was probably introduced by this change: 2016-03-03 Rainer Orth * lib/gcc-gdb-test.exp (gdb-test): Make log message match command. Invoke gdb with -batch. * lib/gcc-simulate-thread.exp (simulate-thread): Likewise. spawn /mnt/gnu/gcc/objdir-test/gcc/xgcc -B/mnt/gnu/gcc/objdir-test/gcc/ /mnt/gnu /gcc/gcc/gcc/testsuite/gcc.dg/simulate-thread/speculative-store-2.c -fno-diagnos tics-show-caret -fdiagnostics-color=never -O0 -g --param allow-store-data-races= 0 -O2 -lm -o speculative-store-2.exe PASS: gcc.dg/simulate-thread/speculative-store-2.c -O0 -g (test for excess er rors) Spawning: gdb -nx -nw -batch -x /mnt/gnu/gcc/gcc/gcc/testsuite/gcc.dg/simulate-t hread/simulate-thread.gdb ./speculative-store-2.exe spawn gdb -nx -nw -batch -x /mnt/gnu/gcc/gcc/gcc/testsuite/gcc.dg/simulate-threa d/simulate-thread.gdb ./speculative-store-2.exe Traceback (most recent call last): File "/home/gnu/share/gdb/python/gdb/__init__.py", line 108, in auto_load_pack ages __import__(modname) File "/home/gnu/share/gdb/python/gdb/command/frame_filters.py", line 22, in from gdb.FrameIterator import FrameIterator File "/home/gnu/share/gdb/python/gdb/FrameIterator.py", line 17, in import itertools ImportError: Failed to load /home/gnu/lib/python2.7/lib-dynload/itertools.sl Breakpoint 1 at 0x2e40: file /mnt/gnu/gcc/gcc/gcc/testsuite/gcc.dg/simulate-thre ad/speculative-store-2.c, line 50. warning: Private mapping of shared library text was not specified by the executable; setting a breakpoint in a shared library which is not privately mapped will not work. See the HP-UX 11i v3 chatr manpage for methods to privately map shared library text. Breakpoint 1, simulate_thread_main () at /mnt/gnu/gcc/gcc/gcc/testsuite/gcc.dg/simulate-thread/speculative-store-2.c:50 50 if (p->data > 0) warning: Cannot find suitable address to place dummy breakpoint; nested calls may fail. 0x2e44 50 if (p->data > 0) warning: Cannot find suitable address to place dummy breakpoint; nested calls may fail. warning: Cannot find suitable address to place dummy breakpoint; nested calls may fail. 0x2e44 50 if (p->data > 0)warning: Cannot find suitable address to place dummy breakpoint; nested calls ma y fail. warning: Cannot find suitable address to place dummy breakpoint; nested calls may fail. 49for (p = q; p; p = p->next)warning: Cannot find suitable address to place dummy breakpoint; nested calls ma y fail. warning: Cannot find suitable address to place dummy breakpoint; nested calls may fail. 0x2e54 49for (p = q; p; p = p->next) warning: Cannot find suitable address to place dummy breakpoint; nested calls may fail. warning: Cannot find suitable address to place dummy breakpoint; nested calls may fail. 0x2e58 49for (p = q; p; p = p->next) warning: Cannot find suitable address to place dummy breakpoint; nested calls may fail. warning: Cannot find suitable address to place dummy breakpoint; nested calls may fail. 0x2e44 50 if (p->data > 0) [...] 49for (p = q; p; p = p->next)warning: Cannot find suitable address to place dummy breakpoint; nested calls may fail. warning: Cannot find suitable address to place dummy breakpoint; nested calls may fail. FAIL: Testcase exceeded maximum instruction count threshold FAIL: gcc.dg/simulate-thread/speculative-store-2.c -O0 -g thread simulation t est Similar fails: FAIL: gcc.dg/simulate-thread/speculative-store-2.c -O2 -g thread simulation t est FAIL: gcc.dg/simulate-thread/speculative-store-2.c -O3 -g thread simulation t est FAIL: gcc.dg/simulate-thread/speculative-store-4.c -O0 -g thread simulation t est
[Bug c++/58646] ICEs initializing VLAs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58646
Martin Sebor changed:
What|Removed |Added
Last reconfirmed|2013-10-07 00:00:00 |2016-3-6
CC||msebor at gcc dot gnu.org
Known to fail||5.3.0, 6.0
--- Comment #3 from Martin Sebor ---
Still crashes with the top of trunk (6.0) as well as 5.3.
$ cat z.cpp && /build/gcc-trunk/gcc/xgcc -B /build/gcc-trunk/gcc -Wall -Wextra
-Wpedantic z.cpp
void bar (int n)
{
char a [2][n] = { };
}
z.cpp: In function ‘void bar(int)’:
z.cpp:3:15: warning: ISO C++ forbids variable length array ‘a’ [-Wvla]
char a [2][n] = { };
^
z.cpp:3:8: warning: unused variable ‘a’ [-Wunused-variable]
char a [2][n] = { };
^
z.cpp:3:21: internal compiler error: in make_decl_rtl, at varasm.c:1299
char a [2][n] = { };
^
0x1449b13 make_decl_rtl(tree_node*)
/src/gcc/trunk/gcc/varasm.c:1295
0xcd7cb5 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/src/gcc/trunk/gcc/expr.c:9612
0xcd0ead expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
/src/gcc/trunk/gcc/expr.c:7962
0xcb8d57 expand_expr
/src/gcc/trunk/gcc/expr.h:256
0xcdfdc2 expr_size(tree_node*)
/src/gcc/trunk/gcc/expr.c:11633
0xcd0b99 expand_constructor
/src/gcc/trunk/gcc/expr.c:7829
0xcd9123 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/src/gcc/trunk/gcc/expr.c:9879
0xcd0ead expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
/src/gcc/trunk/gcc/expr.c:7962
0xcc8175 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
/src/gcc/trunk/gcc/expr.c:5406
0xcc8d79 store_expr(tree_node*, rtx_def*, int, bool, bool)
/src/gcc/trunk/gcc/expr.c:5596
0xccd436 store_field
/src/gcc/trunk/gcc/expr.c:6808
0xcc6247 expand_assignment(tree_node*, tree_node*, bool)
/src/gcc/trunk/gcc/expr.c:5021
0xb8120c expand_gimple_stmt_1
/src/gcc/trunk/gcc/cfgexpand.c:3618
0xb815fd expand_gimple_stmt
/src/gcc/trunk/gcc/cfgexpand.c:3714
0xb8870e expand_gimple_basic_block
/src/gcc/trunk/gcc/cfgexpand.c:5720
0xb8a1d7 execute
/src/gcc/trunk/gcc/cfgexpand.c:6335
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug libfortran/69799] FAIL: gfortran.dg/coarray_allocate_3.f08 at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69799 --- Comment #2 from John David Anglin --- The patch fixes coarray_allocate_3.f08 but the new testcase fails: spawn /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran -B/test/gnu/gcc /objdir/gcc/testsuite/gfortran/../../ -B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11. 11/./libgfortran/ /test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/coarray_allocate_5 .f08 -fno-diagnostics-show-caret -fdiagnostics-color=never -O0 -fcoarray=lib -lcaf_single -fdump-tree-original -B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./li bgfortran/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs -L/test/gnu/gc c/objdir/hppa2.0w-hp-hpux11.11/./libatomic/.libs -B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/. /libquadmath/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs -lm -o ./coarray_allocate_5.exe /usr/ccs/bin/ld: Unsatisfied symbols: __atomic_fetch_and_4 (first referenced in /test/gnu/gcc/objdir/hppa2.0w-hp-hp ux11.11/./libgfortran/.libs/libcaf_single.a(single.o)) (code) __atomic_compare_exchange_4 (first referenced in /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs/libcaf_single.a(single.o)) (code) __atomic_fetch_xor_4 (first referenced in /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs/libcaf_single.a(single.o)) (code) __atomic_fetch_add_4 (first referenced in /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs/libcaf_single.a(single.o)) (code) __atomic_fetch_or_4 (first referenced in /test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs/libcaf_single.a(single.o)) (code) Needs to link against -latomic.
[Bug tree-optimization/70109] New: [6 Regression] FAIL: gcc.dg/vect/O3-pr36098.c scan-tree-dump-times vect "vectorizing stmts usin g SLP" 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70109
Bug ID: 70109
Summary: [6 Regression] FAIL: gcc.dg/vect/O3-pr36098.c
scan-tree-dump-times vect "vectorizing stmts usin g
SLP" 0
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: rguenther at suse dot de
Target Milestone: ---
On ia32, r230993 caused:
FAIL: gcc.dg/vect/O3-pr36098.c scan-tree-dump-times vect "vectorizing stmts
usin
g SLP" 0
with -target_board='unix{-m32\ -march=corei7}'"
[Bug rtl-optimization/70110] New: ICE at -O3 in the 32-bit mode in set_last_insn, at emit-rtl.h:420
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70110
Bug ID: 70110
Summary: ICE at -O3 in the 32-bit mode in set_last_insn, at
emit-rtl.h:420
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
The following code causes an ICE when compiled with the current gcc trunk on
x86_64-linux-gnu at -O3 in the 32-bit mode (but not in 64-bit mode).
This is a regression from 5.3.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 6.0.0 20160306 (experimental) [trunk revision 234012] (GCC)
$
$ gcc-trunk -m32 -O2 -c small.c
$ gcc-trunk -m64 -O3 -c small.c
$ gcc-5.3 -m32 -O3 -c small.c
$
$ gcc-trunk -m32 -O3 -c small.c
small.c: In function ‘fn3’:
small.c:36:1: internal compiler error: in set_last_insn, at emit-rtl.h:420
}
^
0x5b4c2d set_last_insn
../../gcc-source-trunk/gcc/emit-rtl.h:420
0x81a309 set_last_insn
../../gcc-source-trunk/gcc/rtl.h:844
0x81a309 end_sequence()
../../gcc-source-trunk/gcc/emit-rtl.c:5442
0xeb451a scalar_chain::make_vector_copies(unsigned int)
../../gcc-source-trunk/gcc/config/i386/i386.c:3276
0xeb5009 scalar_chain::convert()
../../gcc-source-trunk/gcc/config/i386/i386.c:3512
0xeb58b4 convert_scalars_to_vector
../../gcc-source-trunk/gcc/config/i386/i386.c:3577
0xeb58b4 execute
../../gcc-source-trunk/gcc/config/i386/i386.c:3669
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.
$
$ cat small.c
int a, c, d, f, h;
long long b;
int
fn1 ()
{
if (a)
fn1 ();
b = c;
return 0;
}
void
fn2 (int p)
{
if (p)
f = 0;
b |= c;
}
void
fn3 ()
{
b = d;
for (; (d = 1);)
{
int g, i;
a && fn1 ();
b |= c;
fn2 (h);
fn2 (g);
fn2 (h);
fn2 (i);
fn2 (h);
}
}
int
main ()
{
return 0;
}
[Bug c++/70111] New: Internal compiler error on constant enum access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70111
Bug ID: 70111
Summary: Internal compiler error on constant enum access
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tomasz at tomaszklak dot pl
Target Milestone: ---
Created attachment 37881
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37881&action=edit
example
The following code fails to compile with "internal compiler error: Segmentation
fault (program cc1plus)" with command "g++ -std=c++11 -Wall -Wextra -pedantic
-ftemplate-depth=10 gccbug.cc"
struct Zero { enum { value = 0 }; };
template
struct Next { enum { value = 1 + Nat::value }; };
using One = Next;
using Two = Next;
using Three = Next;
template
struct Add;
template
struct Add
{
using type = Rhs;
};
template
struct Add, Rhs>
{
using type = Next::type>;
};
using Five = typename Add::type;
using Six = typename Add::type;
using v12 = typename Add::type;
using v18 = typename Add::type;
using v23 = typename Add::type;
using v24 = typename Add::type;
template
struct Fib;
template<>
struct Fib { using type = One; };
template<>
struct Fib { using type = One; };
template
struct Fib>> {
using type = typename Add<
typename Fib>::type,
typename Fib::type>::type;
};
int main() {
// This compiles:
// using fib = typename Fib::type;
using fib = typename Fib::type;
(void) fib::value;
}
replacing fib assigment to Fib works fine. Similar behaviour is seen on
5.3.0 - https://goo.gl/rD2zy1
[Bug target/70110] [6 Regression] ICE at -O3 in the 32-bit mode in set_last_insn, at emit-rtl.h:420
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70110
Uroš Bizjak changed:
What|Removed |Added
Target||i?86-*-*
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-03-06
Component|rtl-optimization|target
CC||ienkovich at gcc dot gnu.org
Ever confirmed|0 |1
Summary|ICE at -O3 in the 32-bit|[6 Regression] ICE at -O3
|mode in set_last_insn, at |in the 32-bit mode in
|emit-rtl.h:420 |set_last_insn, at
||emit-rtl.h:420
Target Milestone|--- |6.0
--- Comment #1 from Uroš Bizjak ---
Confirmed, a TARGET_STV problem. -O3 -msse2 flags are needed.
(gdb) bt
#0 internal_error (gmsgid=0x1f308b7 "in %s, at %s:%d") at
/home/uros/gcc-svn/trunk/gcc/diagnostic.c:1256
#1 0x018241b0 in fancy_abort (file=0x1913f78
"/home/uros/gcc-svn/trunk/gcc/emit-rtl.h", line=420,
function=0x1915290 <_ZZL13set_last_insnP8rtx_insnE12__FUNCTION__>
"set_last_insn") at /home/uros/gcc-svn/trunk/gcc/diagnostic.c:1329
#2 0x009a18d0 in set_last_insn (insn=0x7fffef9d2a00) at
/home/uros/gcc-svn/trunk/gcc/emit-rtl.h:420
#3 0x009ac4b1 in end_sequence () at
/home/uros/gcc-svn/trunk/gcc/emit-rtl.c:5442
#4 0x0119806a in scalar_chain::make_vector_copies
(this=0x7fffd8f0, regno=96) at
/home/uros/gcc-svn/trunk/gcc/config/i386/i386.c:3276
#5 0x01198c96 in scalar_chain::convert (this=0x7fffd8f0) at
/home/uros/gcc-svn/trunk/gcc/config/i386/i386.c:3512
#6 0x01198f47 in convert_scalars_to_vector () at
/home/uros/gcc-svn/trunk/gcc/config/i386/i386.c:3577
#7 0x01199159 in (anonymous namespace)::pass_stv::execute
(this=0x2570ff0) at /home/uros/gcc-svn/trunk/gcc/config/i386/i386.c:3669
#8 0x00ce0362 in execute_one_pass (pass=0x2570ff0) at
/home/uros/gcc-svn/trunk/gcc/passes.c:2336
#9 0x00ce066a in execute_pass_list_1 (pass=0x2570ff0) at
/home/uros/gcc-svn/trunk/gcc/passes.c:2410
#10 0x00ce069b in execute_pass_list_1 (pass=0x2560740) at
/home/uros/gcc-svn/trunk/gcc/passes.c:2411
#11 0x00ce06f3 in execute_pass_list (fn=0x7fffef970930, pass=0x255d1a0)
at /home/uros/gcc-svn/trunk/gcc/passes.c:2421
#12 0x008f06be in cgraph_node::expand (this=0x7fffef9962e0) at
/home/uros/gcc-svn/trunk/gcc/cgraphunit.c:1980
#13 0x008f0cf4 in expand_all_functions () at
/home/uros/gcc-svn/trunk/gcc/cgraphunit.c:2116
#14 0x008f180d in symbol_table::compile (this=0x7fffef8730a8) at
/home/uros/gcc-svn/trunk/gcc/cgraphunit.c:2472
#15 0x008f1a3e in symbol_table::finalize_compilation_unit
(this=0x7fffef8730a8) at /home/uros/gcc-svn/trunk/gcc/cgraphunit.c:2562
#16 0x00df3bc3 in compile_file () at
/home/uros/gcc-svn/trunk/gcc/toplev.c:490
#17 0x00df60e3 in do_compile () at
/home/uros/gcc-svn/trunk/gcc/toplev.c:1988
#18 0x00df6368 in toplev::main (this=0x7fffdba0, argc=5,
argv=0x7fffdca8) at /home/uros/gcc-svn/trunk/gcc/toplev.c:2096
#19 0x0180b0e8 in main (argc=5, argv=0x7fffdca8) at
/home/uros/gcc-svn/trunk/gcc/main.c:39
(gdb) f 2
#2 0x009a18d0 in set_last_insn (insn=0x7fffef9d2a00) at
/home/uros/gcc-svn/trunk/gcc/emit-rtl.h:420
420 gcc_checking_assert (!insn || !NEXT_INSN (insn));
(gdb) list
415 /* Specify a new insn as the last in the chain. */
416
417 static inline void
418 set_last_insn (rtx_insn *insn)
419 {
420 gcc_checking_assert (!insn || !NEXT_INSN (insn));
421 get_current_sequence ()->last = insn;
422 }
423
424 /* Return a number larger than any instruction's uid in this function.
*/
(gdb) p debug_rtx (insn)
(insn 69 68 145 11 (parallel [
(set (reg:DI 96 [ prephitmp_27 ])
(sign_extend:DI (reg:SI 104 [ c ])))
(clobber (reg:CC 17 flags))
(clobber (scratch:SI))
]) 146 {extendsidi2_1}
(expr_list:REG_DEAD (reg:SI 104 [ c ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
$1 = void
(gdb) p debug_rtx (NEXT_INSN(insn))
(insn 145 69 146 11 (set (mem/c:SI (plus:SI (reg/f:SI 20 frame)
(const_int -8 [0xfff8])) [0 S4 A64])
(subreg:SI (reg:DI 96 [ prephitmp_27 ]) 0)) -1
(nil))
$2 = void
CC'd author.
[Bug c++/70106] [4.9/5.3/6.0][C++11 or above] adding parenthesis [cerr << (var)] cause error: invalid static_cast from type 'const size_t {aka const long unsigned int}' to type 'size_t& {aka long unsi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70106
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #1 from Patrick Palka ---
Hmm, I can't reproduce the error with -std=c++11, only -std=c++14.
Reduced test case:
struct A
{
int x;
void foo () const {
(A::x);
};
};
void
foo ()
{
A ().foo ();
}
[Bug c++/70106] [4.9/5.3/6.0][C++11 or above] adding parenthesis [cerr << (var)] cause error: invalid static_cast from type 'const size_t {aka const long unsigned int}' to type 'size_t& {aka long unsi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70106
--- Comment #2 from Patrick Palka ---
Oops, wrong reduction. struct A has to be a template.
template
struct A
{
int x;
void foo () const {
(A::x);
};
};
void
foo ()
{
A ().foo ();
}
[Bug rtl-optimization/70089] ARM/THUMB unnecessarily typecasts some rvalues on memory store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70089 Segher Boessenkool changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-03-06 CC||segher at gcc dot gnu.org Component|c |rtl-optimization Ever confirmed|0 |1 --- Comment #5 from Segher Boessenkool --- Confirmed. Also happens on trunk. Other targets (e.g. rs6000) have similar results. Using things like "x | 0x34100" give even less pleasant results.
[Bug rtl-optimization/29854] reload_combine looses track of uses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29854 --- Comment #7 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #6) > Looking at the current code in postreload.c, it seems that the patch somehow > made it into mainline at some point. Although some of the lines now look a > bit different. Can we close this PR as "works for me"? That sounds reasonable.
[Bug middle-end/23868] [4.9/5/6 regression] builtin_apply uses wrong mode for multi-hard-register return values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23868 --- Comment #29 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #28) > Can anybody comment on the state of this problem here? Were the two commits > in comment #2 and comment #3 merged into mainline at some point? AFAIK, those patches weren't merged. I guess that other changes for apply/return buitins fix the failure, though I'm not sure if the original issue went away completely.
[Bug target/70079] missed constant propagation in memcpy expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70079 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #3 from Segher Boessenkool --- (In reply to Paolo Bonzini from comment #0) > movq%rdi, %rcx > leaq8(%rdi), %rdi > andq$-8, %rdi ;; 1 > subq%rdi, %rcx;; 2 > subq%rcx, %rsi;; 3 > addl$512, %ecx;; 4 > shrl$3, %ecx ;; 5 > > At 1, rdi = (a + 8) & ~7 = a & ~7 + 8 = a + 8 - (a & 7) > At 2, rcx = a - rdi = a - a - 8 + (a & 7) = (a & 7) - 8 > At 3, rsi = b - (a & 7) + 8 > At 4, rcx = (a & 7) + 504, which is between 504 and 511 > At 5, rcx is always 31. It would seem %rsi is still alive after this, so the %rcx input to "3" has to be computed, which takes more than one insn so there is no way combine will be able to handle this.
[Bug target/69040] cris allmodconfig fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69040 Hans-Peter Nilsson changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-03-07 Ever confirmed|0 |1 --- Comment #6 from Hans-Peter Nilsson --- I cannot repeat this with the gcc-5 branch at r233997 neither with trunk (gcc6) at r234014 both built for cris-elf and using "./xgcc -v -B./ -Os -march=v10", nor for trunk with "./xgcc -B./ -Os -march=v10 -g -Os -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -Werror=implicit-function-declaration -Wno-format-security -Wno-maybe-uninitialized -Wframe-larger-than=1024 -Wno-unused-but-set-variable -Wdeclaration-after-statement -Wno-pointer-sign -Werror=implicit-int -Werror=strict-prototypes -Werror=date-time -std=gnu90 -fno-strict-aliasing -fno-common -fno-delete-null-pointer-checks -fno-reorder-blocks -fno-ipa-cp-clone -fno-partial-inlining -fno-stack-protector -fno-omit-frame-pointer -fno-optimize-sibling-calls -fno-var-tracking-assignments -fno-inline-functions-called-once -fno-strict-overflow -fconserve-stack --param allow-store-data-races=0". I do see it at the above gcc-5 branch revision using the latter options.
[Bug target/69040] cris allmodconfig fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69040 Hans-Peter Nilsson changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug target/69040] cris allmodconfig fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69040 --- Comment #7 from Hans-Peter Nilsson --- This is a regression for the gcc-5 branch compared to the gcc-4_9-branch at r233942 (not seeing the error for the same options as observed on the gcc-5-branch).
[Bug target/69040] cris allmodconfig fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69040 --- Comment #8 from Hans-Peter Nilsson --- Supposedly viable workarounds: omit "-fno-omit-frame-pointer" or use "-O2". (required and necessary options for observation; omitting any of the "-f"-options compiles succcessfully: "-Os -march=v10 -fno-strict-aliasing -fno-delete-null-pointer-checks -fno-omit-frame-pointer -fno-inline-functions-called-once")
[Bug c/70104] Should give an error when using multiple case value in switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70104 --- Comment #2 from Niks --- (In reply to Jakub Jelinek from comment #1) > 'a' || 'A' is 1, so there is no reason to give an error about it. > The error in the second case is because you have two case labels with the > same value, 1. That is not allowed in a switch. Thank you.!
[Bug c++/70111] Internal compiler error on constant enum access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70111 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Markus Trippelsdorf --- From the manual: -ftemplate-depth=n Set the maximum instantiation depth for template classes to n. A limit on the template instantiation depth is needed to detect endless recursions during template class instantiation. ANSI/ISO C++ conforming programs must not rely on a maximum depth greater than 17 (changed to 1024 in C++11). The default value is 900, as the compiler can run out of stack space before hitting 1024 in some situations.
[Bug libgcc/66382] POWER8 Vector optimized implementation of __float128 (IEEE754 128-bit Binary Floating Point)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66382 dan.parrot at mail dot com changed: What|Removed |Added CC||dan.parrot at mail dot com --- Comment #1 from dan.parrot at mail dot com --- Could you provide the options to ./configure which build gcc while allowing flag -msoft-float and type __float128 to co-exist? Or is changing the code to allow that combination part of the task here? I have been unable to configure a build that accepts them (-msoft-float and __float128) together.
[Bug c++/70112] New: [lto] Segmentation fault in Libreoffice's program gengal.bin when build with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70112
Bug ID: 70112
Summary: [lto] Segmentation fault in Libreoffice's program
gengal.bin when build with LTO
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kabel at blackhole dot sk
Target Milestone: ---
Created attachment 37882
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37882&action=edit
gengal-backtrace.txt
As Steffen Hau has posted in the comments on PR50394, Libreoffice's program
gengal.bin fails with segmentation fault during compilation of Libreoffice
itself. I have studied it more, and the problem seems with
libreoffice-5.0.5.2/bridges (libgcc3_uno.so), which are "Bridges from various
C++ ABIs, Java JNI, MS .Net to UNO and back.", as described by README.
When I compiled libgcc3_uno.so with LTO disabled, gengal.bin ran successfully.
Attaching gdb's backtrace when segmentation fault.
The problem seems to be in the destructor
bridges::cpp_uno::shared::CppInterfaceProxy::~CppInterfaceProxy()
which is defined in bridges/source/cpp_uno/shared/cppinterfaceproxy.cxx
CppInterfaceProxy::~CppInterfaceProxy()
{}
And also called from there from function freeCppInterfaceProxy:
pThis->~CppInterfaceProxy();
[Bug lto/50394] [meta-bug] Issues with building libreoffice with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50394 Marek Behun changed: What|Removed |Added CC||kabel at blackhole dot sk --- Comment #32 from Marek Behun --- (In reply to Steffen Hau from comment #31) Created PR70112
[Bug c++/70112] [lto] Segmentation fault in Libreoffice's program gengal.bin when build with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70112 --- Comment #1 from Markus Trippelsdorf --- There is too little information to be useful. At least please build with debugging info enabled and find out exactly what is going on. Next build with -fsanitize=undefined to see if any undefined behavior is invoked. Or try to add "-fno-lifetime-dse -fno-delete-null-pointer-checks" and see if the issue goes away.
[Bug c++/70112] [lto] Segmentation fault in Libreoffice's program gengal.bin when build with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70112 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-03-07 CC||trippels at gcc dot gnu.org Ever confirmed|0 |1
