[Bug c++/62056] Long compile times with large tuples
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62056 --- Comment #5 from Piotr Dziwinski piotrdz at gmail dot com --- (In reply to Jonathan Wakely from comment #4) tr1::tuple doesn't support perfect-forwarding or move semantics tr1::tuple doesn't support uses-allocator construction tr1::tuple doesn't support 'final' classes tr1::tuple doesn't have correct exception specifications tr1::tuple doesn't prevent implicit conversions that would use explicit constructors tr1::tuple doesn't support tuple concatenation If you can add all those features to the tr1/tuple implementation so that it meets the C++11 requirements and it still compiles faster then I'd be interested in your analysis of the remaining differences. Otherwise I'm going to assume the difference is because the tuple header contains more than twice as many lines of code and several additional features. Ok, I understand it now. I was speaking from only somewhat experienced user perspective and I did not realise the deeper implications of standard compliance. Just for the record, I did some testing and found two important factors here are: - dependency to array (to enable it in tuple concatenation) - (change in compile time 0.357s - 0.231s), - allocator constructors - (change 0.231s - 0.185s). So in the end please ignore my interruption with `std::tr1::tuple`. It seems the recursive version of `std::tuple` is not going to be optimized easily and the new flat implementation is the way to go here.
[Bug tree-optimization/63411] [4.9/5 regression] ivopt produces wrong struct offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63411
--- Comment #2 from bin.cheng amker.cheng at gmail dot com ---
(In reply to Oleg Endo from comment #0)
Compiling the following as C or C++:
typedef struct
{
unsigned char sprindex;
unsigned char y;
unsigned char index;
unsigned char attr;
unsigned char x;
unsigned short pattern;
} oam;
extern oam OAM3[8];
int test2 (unsigned c, int r)
{
for (unsigned i = 0; i c; ++i)
{
oam* s = (OAM3[i]);
if (s-attr 0x40)
r += s-pattern;
}
return r;
}
on SH (big or little endian, any CPU type) with -O2 results in the following
wrong code:
_test2:
tst r4,r4
bt .L12
mov.l .L14,r1
.align 2
.L4:
mov.b @r1,r0
tst #64,r0
bt/s.L3
mov r1,r2
add #3,r2 wrong struct offset '3'
But r2 is initialized with [.L14] which is _OAM3+3, so the offset actually is 6
here, No?
mov.w @r2,r2 should be '3*2', i.e. '6'.
extu.w r2,r2
add r2,r5
.L3:
dt r4
bf/s.L4
add #8,r1
.L12:
rts
mov r5,r0
.L15:
.align 2
.L14:
.long _OAM3+3
.size _test2, .-_test2
.ident GCC: (GNU) 4.9.2 20140929 (prerelease)
Disabling ivopt with '-fno-ivopts' produces correct code:
_test2:
tst r4,r4
bt .L12
mov #0,r2
mov.l .L14,r3
.align 2
.L4:
mov r2,r1
shll2 r1
add r1,r1
add r3,r1
mov.b @(3,r1),r0
tst #64,r0
bt .L3
mov.w @(6,r1),r0 correct struct offset '6'
extu.w r0,r1
add r1,r5
.L3:
dt r4
bf/s.L4
add #1,r2
.L12:
rts
mov r5,r0
.L15:
.align 2
.L14:
.long _OAM3
.size _test2, .-_test2
.ident GCC: (GNU) 4.9.2 20140929 (prerelease)
I haven't checked whether this happens on other targets, but I guess this is
not SH specific.
This happens on the current 4.9 branch and trunk. 4.8 branch is not
affected.
[Bug preprocessor/63413] New: cpp trying to expand vector word in commented line in fortran file on power8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63413 Bug ID: 63413 Summary: cpp trying to expand vector word in commented line in fortran file on power8 Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: valeryweber at hotmail dot com Hi All The following code produces a wrong error while cpp (4.9.1 power8 ppc64le). This gets cpp correctly on different archs. v cat tmp.F90 program test ! vector end program test cpp --version cpp (Ubuntu 4.9.1-15ubuntu1) 4.9.1 Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. cpp -traditional -P tmp.F90 tmp.F90:2:0: error: detected recursion whilst expanding macro vector ! vector ^ program test ! vector end program test
[Bug c/63368] Provide an implementation for `__sync_val_compare_and_swap_8' on powerpc (32bits)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63368 Mathieu Malaterre mathieu.malaterre at gmail dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED Resolution|INVALID |WONTFIX --- Comment #6 from Mathieu Malaterre mathieu.malaterre at gmail dot com --- @Jonathan thanks for the clarification. I've moved the issue from resolved/invalid to verified/wontfix. I guess no-one really works on ppc32 these days. regards
[Bug tree-optimization/63411] [4.9/5 regression] ivopt produces wrong struct offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63411 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to bin.cheng from comment #2) bt/s.L3 mov r1,r2 add #3,r2 wrong struct offset '3' But r2 is initialized with [.L14] which is _OAM3+3, so the offset actually is 6 here, No? Ouch. Yes. Sorry for the fuzz. On SH this is a performance regression (it can do only displacements that are scaled by the access size), but not a wrong-code regression.
[Bug tree-optimization/63411] [4.9/5 regression] ivopt produces wrong struct offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63411 amker at gcc dot gnu.org changed: What|Removed |Added CC||amker at gcc dot gnu.org --- Comment #4 from amker at gcc dot gnu.org --- (In reply to Oleg Endo from comment #3) (In reply to bin.cheng from comment #2) bt/s.L3 mov r1,r2 add #3,r2 wrong struct offset '3' But r2 is initialized with [.L14] which is _OAM3+3, so the offset actually is 6 here, No? Ouch. Yes. Sorry for the fuzz. On SH this is a performance regression (it can do only displacements that are scaled by the access size), but not a wrong-code regression. We saw similar problems on arm too. Problem is IVOPT's model doesn't know the detail of target addressing mode. This is should be fixed by improving function get_address_cost, but that's just difficult to expose every target details to middle end, especially we need to keep it simple and fast.
[Bug tree-optimization/63411] [4.9/5 regression] ivopt produces wrong struct offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63411 --- Comment #5 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to amker from comment #4) We saw similar problems on arm too. Problem is IVOPT's model doesn't know the detail of target addressing mode. This is should be fixed by improving function get_address_cost, but that's just difficult to expose every target details to middle end, especially we need to keep it simple and fast. I'm trying to make some progress on PR 56590, that's how I noticed this issue here in the first place. These kind of issues could be fixed up by an AMS pass since it will have to know all the details about target address modes and costs. E.g. turning the first access in the loop into a post-inc would fix this particular case.
[Bug sanitizer/56393] SIGSEGV when -fsanitize=address and dynamic lib with global objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393 --- Comment #46 from Yury Gribov y.gribov at samsung dot com --- Can we close this one? Does not seem to repro in trunk.
[Bug c++/16564] g++ seems to go into an infinite loop after errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564 --- Comment #23 from Paolo Carlini paolo.carlini at oracle dot com --- Manuel, I'm looking into this. I think it makes sense to also submit the testcase updates, or at least provide a breakdown. I'm working on that.
[Bug c++/63412] aliasing issue exposed by inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63412 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- https://gcc.gnu.org/bugs/ Similarly, if compiling with -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations makes a difference, your code probably is not correct. Turning off strict aliasing stops it crashing = you broke the aliasing rules
[Bug target/55212] [SH] Switch from IRA to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #49 from Kazumoto Kojima kkojima at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #48)
The array at i = 699 doesn't seem to contain anything valid.
It looks that
(expr_list:DF (use (mem:DF (reg/f:SI 699) [0 S8 A32]))
which shows an argument of call_insn 617 via memory, was missed
by LRA as a usage of pseudo 699. Here is my trial:
--- gcc/lra.c.orig2014-09-14 09:09:57.223724308 +0900
+++ gcc/lra.c2014-09-30 17:15:21.709508021 +0900
@@ -1615,6 +1615,20 @@ lra_update_insn_regno_info (rtx_insn *in
if ((code = GET_CODE (PATTERN (insn))) == CLOBBER || code == USE)
add_regs_to_insn_regno_info (data, XEXP (PATTERN (insn), 0), uid,
code == USE ? OP_IN : OP_OUT, false);
+ if (CALL_P (insn))
+{
+ rtx link;
+
+ /* Take account of arguments via memory which could be implicit
+ usage of pseudo regs. */
+ for (link = CALL_INSN_FUNCTION_USAGE (insn);
+ link != NULL_RTX;
+ link = XEXP (link, 1))
+if (GET_CODE (XEXP (link, 0)) == USE
+ MEM_P (XEXP (XEXP (link, 0), 0)))
+ add_regs_to_insn_regno_info (data, XEXP (XEXP (link, 0), 0), uid,
+ OP_IN, false);
+}
if (NONDEBUG_INSN_P (insn))
setup_insn_reg_info (data, freq);
}
[Bug lto/63409] [5 Regression] FAIL: g++.dg/lto/pr63270 cp_lto_pr63270_0.o-cp_lto_pr63270_1.o link, -flto -O2 -Wno-odr -fno-linker-plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63409 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-*-* Target Milestone|--- |5.0
[Bug target/63408] [4.8 regression] GCC emits incorrect FMA instruction on Cortex-M4 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63408 Richard Earnshaw rearnsha at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-30 CC||ramana at gcc dot gnu.org Summary|GCC emits incorrect FMA |[4.8 regression] GCC emits |instruction on Cortex-M4|incorrect FMA instruction |target |on Cortex-M4 target Ever confirmed|0 |1 --- Comment #3 from Richard Earnshaw rearnsha at gcc dot gnu.org --- Confirmed. The compiler thinks (incorrectly) that the conversion of b to float can be merged with the negation by using the fixed-to-float conversion operation in the back-end. That is, it thinks (insn 10 9 11 2 (set (reg:SF 121 [ D.4093 ]) (mult:SF (float:SF (reg:SI 0 r0 [ b ])) (const_double:SF -4.656612873077392578125e-10 [-0x0.8p-30]))) is a legitimate instruction. vfp3_const_double_for_fract_bits() needs to be made aware that negative values cannot be used in this context. This is almost certainly a regression since the pattern was added.
[Bug rtl-optimization/61605] Potential optimization: Keep unclobbered argument registers live across function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61605 --- Comment #6 from vries at gcc dot gnu.org --- Created attachment 33618 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33618action=edit [1/2] Use fuse-caller-save-info in cprop-hardreg
[Bug rtl-optimization/61605] Potential optimization: Keep unclobbered argument registers live across function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61605 --- Comment #7 from vries at gcc dot gnu.org --- Created attachment 33619 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33619action=edit [2/2] Don't regard a copy with identical src and dest as killing dest This patch adds handling of copies with identical source and destination register in copyprop_hardreg_forward_1. Using this patch series we get the desired code.
[Bug inline-asm/63282] [4.8/4.9/5 Regression] ICE in redirect_jump_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63282 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Tue Sep 30 10:30:45 2014 New Revision: 215712 URL: https://gcc.gnu.org/viewcvs?rev=215712root=gccview=rev Log: PR inline-asm/63282 * ifcvt.c (dead_or_predicable): Don't call redirect_jump_1 or invert_jump_1 if jump isn't any_condjump_p. * gcc.c-torture/compile/pr63282.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr63282.c Modified: trunk/gcc/ChangeLog trunk/gcc/ifcvt.c trunk/gcc/testsuite/ChangeLog
[Bug inline-asm/63282] [4.8/4.9/5 Regression] ICE in redirect_jump_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63282 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Tue Sep 30 10:33:25 2014 New Revision: 215713 URL: https://gcc.gnu.org/viewcvs?rev=215713root=gccview=rev Log: PR inline-asm/63282 * ifcvt.c (dead_or_predicable): Don't call redirect_jump_1 or invert_jump_1 if jump isn't any_condjump_p. * gcc.c-torture/compile/pr63282.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.c-torture/compile/pr63282.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/ifcvt.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug libstdc++/63400] [C++11]precision of std::chrono::high_resolution_clock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- Maybe we should make high_resolution_clock a typedef for steady_clock on mingw-w64 but maybe only when using winpthreads.
[Bug inline-asm/63282] [4.8/4.9/5 Regression] ICE in redirect_jump_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63282 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- Should be fixed now.
[Bug lto/63409] [5 Regression] FAIL: g++.dg/lto/pr63270 cp_lto_pr63270_0.o-cp_lto_pr63270_1.o link, -flto -O2 -Wno-odr -fno-linker-plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63409
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-09-30
CC||marxin at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr ---
I get the same failure on x86_64-apple-darwin13 configured with
../work/configure --prefix=/opt/gcc/gcc4.10w
--enable-languages=c,c++,fortran,objc,obj-c++,ada,java,lto --with-gmp=/opt/mp
--with-system-zlib --with-isl=/opt/mp --enable-lto --enable-plugin
--with-arch=corei7 --with-cpu=corei7
and tested with
make -k check RUNTESTFLAGS=--target_board=unix'{-m32,-m64}'
AFAICT the test (r215451) never passed.
[Bug lto/63409] [5 Regression] FAIL: g++.dg/lto/pr63270 cp_lto_pr63270_0.o-cp_lto_pr63270_1.o link, -flto -O2 -Wno-odr -fno-linker-plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63409 Martin Liška mliska at suse dot cz changed: What|Removed |Added CC||mliska at suse dot cz --- Comment #2 from Martin Liška mliska at suse dot cz --- Mine. I will prepare the testcase to resolve missing references.
[Bug middle-end/35545] tracer pass is run too late
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545 --- Comment #24 from Martin Liška mliska at suse dot cz --- Hello Honza. I've been working on SPEC numbers, I will send it this evening.
[Bug c++/63414] New: template parse error using operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63414 Bug ID: 63414 Summary: template parse error using operator Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tomalk at mathematik dot uni-freiburg.de
[Bug c++/63414] template parse error using operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63414
--- Comment #1 from Tobias Malkmus tomalk at mathematik dot uni-freiburg.de
---
#include iostream
templateclass T
int bar ( const T ) { return 0; }
struct Foo
{
int bar;
};
templateclass F
void callBar ( F foo )
{
if( foo.bar0 )
std::coutfoo.barstd::endl;
}
int main ()
{
Foo foo;
foo.bar = -1;
callBar( foo );
return 0;
}
should be a correct code, but gcc complains with the error:
In function ‘void callBar(F)’:
error: parse error in template argument list
I got this error for the gcc version 3.4.1, 4.1.2, 4.2.4, 4.3.6, 4.4.7, 4.5.4,
4.6.4, 4.7.4, 4.8.3 and 4.9.1.
The same hold for icc in different version, but not for clang 3.5.0.
[Bug c++/63414] template parse error using operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63414 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-30 Version|unknown |5.0 Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- EDG accepts it too.
[Bug c++/63415] New: internal compiler error: unexpected expression ‘static_castint(std::is_sameT, A1{})’ of kind static_cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63415
Bug ID: 63415
Summary: internal compiler error: unexpected expression
‘static_castint(std::is_sameT, A1{})’ of kind
static_cast_expr
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tnozicka at gmail dot com
Hi,
g++ asked me to submit a bug report, so here it is :)
=== ERROR ===
main.cpp:37:69: internal compiler error: unexpected expression
‘static_castint(std::is_sameT, A1{})’ of kind static_cast_expr
static constexpr int value = static_castint(std::is_sameT, A1{});
^
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
=== SOURCE ===
#include type_traits
templatetypename T, typename A1, typename... Args
struct CountType
{
static constexpr int value = CountTypeT, A1::value + CountTypeT,
Args...::value;
constexpr operator int() const
{
return value;
}
};
templatetypename T, typename A1
struct CountTypeT, A1
{
//static constexpr int value = static_castint(std::is_sameT, A1()); //
this works
static constexpr int value = static_castint(std::is_sameT, A1{});
constexpr operator int() const
{
return value;
}
};
templatetypename T, typename... Args
using CountDecayType = CountTypeT, std::decay_tArgs...;
templatetypename... Args
void foo(Args... args)
{
int i = CountDecayTypeint, Args...{};
}
int main()
{
foo(5, 6L, 5, 5);
return 0;
}
=== g++ flags ===
-std=c++14 -pedantic-errors -Wall -Wextra -gdwarf-2
=== configure ===
Using built-in specs.
COLLECT_GCC=/opt/szn/bin/g++-4.9
COLLECT_LTO_WRAPPER=/opt/szn/lib/gcc/x86_64-linux-gnu/4.9.1/lto-wrapper
Target: x86_64-linux-gnu
Configured with: /home/tomas/packages/gcc/gcc-4.9.1/configure --prefix=/opt/szn
--program-suffix=-4.9 --enable-languages=c++ --disable-multilib --enable-shared
--enable-threads=posix --enable-checking=release --enable-__cxa_atexit
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --with-tune=generic
--enable-libstdcxx-time=yes --enable-libstdcxx-debug
--enable-version-specific-runtime-libs --enable-objc-gc --enable-clocale=gnu
--disable-install-libiberty --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu --libdir=/opt/szn/lib --libexecdir=/opt/szn/lib
--infodir=/opt/szn/share/info-gcc-4.9 --localedir=/opt/szn/share/locale-gcc-4.9
--mandir=/opt/szn/share/man-gcc-4.9
--with-gxx-include-dir=/opt/szn/include/c++/4.9
Thread model: posix
gcc version 4.9.1 (GCC)
[Bug c++/63414] template parse error using operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63414 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- Dup of bug 10200. *** This bug has been marked as a duplicate of bug 10200 ***
[Bug c++/10200] Weird clash with same names in different scopes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10200 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||tomalk at mathematik dot uni-freib ||urg.de --- Comment #24 from Andrew Pinski pinskia at gcc dot gnu.org --- *** Bug 63414 has been marked as a duplicate of this bug. ***
[Bug c++/63415] internal compiler error: unexpected expression ‘static_castint(std::is_sameT, A1{})’ of kind static_cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63415
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-09-30
CC||trippels at gcc dot gnu.org
Target Milestone|--- |4.9.2
Ever confirmed|0 |1
Known to fail||4.9.1, 5.0
--- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
markus@x4 tmp % cat booo.ii
template typename T
struct A {
static constexpr int value = int(T{});
};
markus@x4 tmp % g++ -std=c++11 booo.ii
booo.ii:3:39: internal compiler error: unexpected expression ‘(int)(T{})’ of
kind cast_expr
static constexpr int value = int(T{});
^
0x713c8e cxx_eval_constant_expression
../../gcc/gcc/cp/semantics.c:9990
0x716b15 cxx_eval_outermost_constant_expr
../../gcc/gcc/cp/semantics.c:10010
0x624e74 store_init_value(tree_node*, tree_node*, vectree_node*, va_gc,
vl_embed**, int)
../../gcc/gcc/cp/typeck2.c:810
0x5971d4 check_initializer
../../gcc/gcc/cp/decl.c:5877
0x5a852f cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/gcc/cp/decl.c:6399
0x65c1b6 grokfield(cp_declarator const*, cp_decl_specifier_seq*, tree_node*,
bool, tree_node*, tree_node*)
../../gcc/gcc/cp/decl2.c:1020
0x69e5e9 cp_parser_member_declaration
../../gcc/gcc/cp/parser.c:20881
0x67a2dc cp_parser_member_specification_opt
../../gcc/gcc/cp/parser.c:20429
0x67a2dc cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:19619
0x67ccb0 cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:19855
0x67ccb0 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:14531
0x697c60 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:11772
0x69cd13 cp_parser_single_declaration
../../gcc/gcc/cp/parser.c:23504
0x69d1f4 cp_parser_template_declaration_after_export
../../gcc/gcc/cp/parser.c:23373
0x6a9919 cp_parser_declaration
../../gcc/gcc/cp/parser.c:11172
0x6a83d8 cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:11094
0x6a9cc3 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4059
0x6a9cc3 c_parse_file()
../../gcc/gcc/cp/parser.c:32089
0x7d11e2 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1043
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 c++/63415] [4.9/5 Regression] internal compiler error: unexpected expression ‘static_castint(std::is_sameT, A1{})’ of kind static_cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63415
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Summary|internal compiler error:|[4.9/5 Regression] internal
|unexpected expression |compiler error: unexpected
|‘static_castint(std::is_s |expression
|ameT, A1{})’ of kind |‘static_castint(std::is_s
|static_cast_expr|ameT, A1{})’ of kind
||static_cast_expr
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org ---
We (incorrectly) rejected the code with an error before 4.9.0, now we get an
ICE, so marking as a regression.
[Bug c++/59759] internal compiler error: in unify, using std::enable_if on classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59759 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org --- If this isn't a regression (which it doesn't seem to be) then setting Target Milestone to 4.8.4 doesn't seem appropriate.
[Bug c/63307] [4.9/5 Regression] Cilk+ breaks -fcompare-debug bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63307 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Igor Zamyatin from comment #3) (In reply to Jakub Jelinek from comment #2) + vec_arglist.release(); Formatting. You could use auto_vec, perhaps with some stack allocated initial buffer if you think say 16 vector elements would be typically enough. Is it ok to have auto_vec declaration outside the routine? Why do you need to declare it outside of the routine? That seems undesirable to me. Also, what about all the remaining 3 callbacks that create or may create decls and have the same problem? for_local_cb, wrapper_local_cb and declare_one_free_variable. These are callbacks that seem to be safe in the sense of random ordering - perform some 1 to 1 mapping I don't think so. They copy declarations, i.e. create new declarations, and the different ordering of their DECL_UID values may result in code generation differences (e.g. various other spots in the compiler sort based on DECL_UIDs, if you create them in pretty random order, you'll surely trigger some -fcompare-debug (perhaps not with current limited testsuite coverage, but with other tests).
[Bug c++/62056] Long compile times with large tuples
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62056 --- Comment #6 from Agustín Bergé kaballo86 at hotmail dot com --- (In reply to Piotr Dziwinski from comment #5) It seems the recursive version of `std::tuple` is not going to be optimized easily and the new flat implementation is the way to go here. Well, not necessarily, It's not `std::tuple` which is at fault, but the compiler (gcc and every other). Note that this issue was moved from libstdc++ to c++, so that's promising!
[Bug c/63307] [4.9/5 Regression] Cilk+ breaks -fcompare-debug bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63307 --- Comment #3 from Igor Zamyatin izamyatin at gmail dot com --- (In reply to Jakub Jelinek from comment #2) + vec_arglist.release(); Formatting. You could use auto_vec, perhaps with some stack allocated initial buffer if you think say 16 vector elements would be typically enough. Is it ok to have auto_vec declaration outside the routine? Also, what about all the remaining 3 callbacks that create or may create decls and have the same problem? for_local_cb, wrapper_local_cb and declare_one_free_variable. These are callbacks that seem to be safe in the sense of random ordering - perform some 1 to 1 mapping
[Bug c++/59759] internal compiler error: in unify, using std::enable_if on classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59759 --- Comment #9 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Jonathan Wakely from comment #8) If this isn't a regression (which it doesn't seem to be) then setting Target Milestone to 4.8.4 doesn't seem appropriate. Feel free to adjust.
[Bug c++/16564] g++ seems to go into an infinite loop after errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564 --- Comment #24 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Paolo Carlini from comment #23) Manuel, I'm looking into this. I think it makes sense to also submit the testcase updates, or at least provide a breakdown. I'm working on that. Thanks! I didn't do it because of lack of time and not being sure if Jason will actually accept the patch. But I think I covered all cases in my email. They should be fairly automatic.
[Bug rtl-optimization/61605] Potential optimization: Keep unclobbered argument registers live across function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61605 vries at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |vries at gcc dot gnu.org
[Bug c++/62056] Long compile times with large tuples
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62056 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-09-30 CC||manu at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #7 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Agustín Bergé from comment #6) Well, not necessarily, It's not `std::tuple` which is at fault, but the compiler (gcc and every other). Note that this issue was moved from libstdc++ to c++, so that's promising! I don't see any analysis of what the bug actually is. If there is a bug in g++, you should be able to trigger it with a testcase not including tuple. On the other hand, if you want to provide an alternative implementation of tuple, you should join libstc++: https://gcc.gnu.org/onlinedocs/libstdc++/manual/appendix_contributing.html
[Bug c++/62056] Long compile times with large tuples
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62056 --- Comment #8 from Agustín Bergé kaballo86 at hotmail dot com --- (In reply to Manuel López-Ibáñez from comment #7) (In reply to Agustín Bergé from comment #6) Well, not necessarily, It's not `std::tuple` which is at fault, but the compiler (gcc and every other). Note that this issue was moved from libstdc++ to c++, so that's promising! I don't see any analysis of what the bug actually is. If there is a bug in g++, you should be able to trigger it with a testcase not including tuple. On the other hand, if you want to provide an alternative implementation of tuple, you should join libstc++: https://gcc.gnu.org/onlinedocs/libstdc++/manual/appendix_contributing.html This issue started targeting libstdc++, and later someone reassigned it to c++. The recursive tuple implementation in libstdc++ causes our use of large tuples to more than double compilation time when compared to a flat implementation. Hence the inclusion of tuple. There is no bug, but a QoI issue that makes `std::tuple` use prohibitive for large tuples. Whether the QoI issue belongs with libc++ or g++, I am not entitled to say. The underlying issue is a g++ issue, but there are known compile-time efficient implementations of `std::tuple`. Of course, a solution in the compiler would benefit a wider audience so it would be preferable. And again, no solution would be fine as well given that this is QoI. As for a bug analysis (which is a requirement that I was unaware of), I haven't put this particular combination of implementation and compiler under a profiler. I have done however enough experimentation on similar code bases and the results are consistent, so while I might be off in the specific details it should still give you a strong hint of where to look. The issue boils down to name mangling and lookup: the longer the name the more memory consumption and cpu usage. For a recursive variadic implementation, instantiating a tuple of N elements with aggregated mangled length M results in the mangling of N bases with average mangled length M/2. For a flat variadic implementation, it results in the mangling of N bases of average mangled length M/N instead. As the tuple gets large and the names get long (and mangled names get very long very fast), the recursive implementation turns into a compilation time (and memory!) hog way faster than a flat implementation does. Please let me know if I can help you in any other way.
[Bug c++/63405] [5 regression] ICE in cp_perform_integral_promotions, at cp/typeck.c:2084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63405
Gert-jan Los gerrit.los at gmail dot com changed:
What|Removed |Added
CC||gerrit.los at gmail dot com
--- Comment #2 from Gert-jan Los gerrit.los at gmail dot com ---
git bisect points to the following commit:
internal compiler error: in cp_perform_integral_promotions, at cp/typeck.c:2084
ffe3a6612f48c48d0d4ca285cf9833df87b6c240 is the first bad commit
commit ffe3a6612f48c48d0d4ca285cf9833df87b6c240
Author: jason jason@138bc75d-0d04-0410-961f-82ee72b054a4
Date: Thu Sep 11 13:50:27 2014 +
PR c++/63139
* pt.c (tsubst_pack_expansion): Simplify substitution into T
(tsubst): Don't throw away PACK_EXPANSION_EXTRA_ARGS.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@215171
138bc75d-0d04-0410-961f-82ee72b054a4
additional testcase:
-
template typename _Tp _Tp forward(_Tp);
template typename Args struct Format { Format(int, Args); };
template typename... Args auto format(Args ... args) - FormatArgs... {
return {0, args...};
}
template typename... Args void msg(Args... args) {
format(forward(args)...);
}
void some_function() { msg('x'); }
-
[Bug ipa/63416] New: Three calls to empty functions via pointers get folded, but not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63416 Bug ID: 63416 Summary: Three calls to empty functions via pointers get folded, but not inlined Product: gcc Version: 4.7.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: felix.shvaiger at emc dot com Created attachment 33620 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33620action=edit 3 function calls - folded, not inlined Missed inlining opportunity. Issue exists in x86 arch. 4.7, 4.8, 4.9, 5.0 versions (maybe earlier too). Option: -O2, -O3 If 2 near-empty functions called via pointers, then calls get folded and inlined. If 3rd empty function call via pointer added, then all calls get folded, but not inlined. Attached test cases (self-contained, no includes): a1.c -- 3 function calls - folded, not inlined.
[Bug ipa/63416] Three calls to empty functions via pointers get folded, but not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63416 --- Comment #1 from Felix Shvaiger felix.shvaiger at emc dot com --- Created attachment 33621 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33621action=edit 2 function calls - (for comparison) folded, inlined
[Bug ipa/63416] Three calls to empty functions via pointers get folded, but not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63416 --- Comment #2 from Felix Shvaiger felix.shvaiger at emc dot com --- Created attachment 33622 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33622action=edit disassembly of compiled a1.c -- bad code
[Bug ipa/63416] Three calls to empty functions via pointers get folded, but not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63416 --- Comment #3 from Felix Shvaiger felix.shvaiger at emc dot com --- Created attachment 33623 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33623action=edit disassembly of compiled a2.c -- good code
[Bug plugins/63410] [Regression] pass_instances.def is not installed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63410 --- Comment #1 from dmalcolm at gcc dot gnu.org --- Author: dmalcolm Date: Tue Sep 30 15:41:11 2014 New Revision: 215727 URL: https://gcc.gnu.org/viewcvs?rev=215727root=gccview=rev Log: PR plugins/63410: Fix missing headers for plugins gcc/ PR plugins/63410 * Makefile.in (PRETTY_PRINT_H): Add wide-int-print.h. (PLUGIN_HEADERS): Add pass-instances.def. Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in
[Bug c/63417] New: scanf: problem handling %hhd format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63417
Bug ID: 63417
Summary: scanf: problem handling %hhd format
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: subc2 at wp dot pl
The following code runs properly on any UNIX-like operating system, but under
Windows with GCC up to the version 4.8.1 (ports: MinGW, MinGW-w64, TDM-GCC)
gives wrong results.
file.c:
#include stdio.h
int main()
{
int logical = 1;
signed char s_char;
scanf(%hhd, s_char);
if (s_char == 0)
logical = s_char;
printf(%d, logical);
return 0;
}
C:\ gcc -std=gnu99 file.c
C:\ a.exe
0
0
C:\ a.exe
1
0
C:\ a.exe
2
0
What's even more interesting, after compiling this code
magic.c:
#include stdio.h
int main()
{
int logical = 1;
signed char s_char;
scanf(%hhd, s_char);
if (s_char == 0) {
int nothing = 0;
logical = s_char;
}
printf(%d, logical);
return 0;
}
C:\ gcc -std=gnu99 magic.c
C:\ a.exe
0
0
C:\ a.exe
1
1
C:\ a.exe
2
1
everything is OK.
[Bug c/63417] scanf: problem handling %hhd format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63417 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- GCC does not provide scanf. Most likely MinGW (and maybe even windows)'s scanf does not provide a POSIX complaint scanf.
[Bug target/62120] [ICE] ADDITIONAL_REGISTER_NAMES for [YZ]MMs, regno8 should be disable in 32-bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62120 --- Comment #1 from tocarip at gcc dot gnu.org --- Author: tocarip Date: Tue Sep 30 16:04:15 2014 New Revision: 215729 URL: https://gcc.gnu.org/viewcvs?rev=215729root=gccview=rev Log: Fix PR 62120. gcc/ 2014-09-30 Ilya Tocar ilya.to...@intel.com PR middle-end/62120 * varasm.c (decode_reg_name_and_count): Check availability for registers from ADDITIONAL_REGISTER_NAMES. testsuite/ 2014-09-30 Ilya Tocar ilya.to...@intel.com PR middle-end/62120 * gcc.target/i386/avx512f-additional-reg-names.c: Use register valid in 32-bit mode. * gcc.target/i386/pr62120.c: New. Added: trunk/gcc/testsuite/gcc.target/i386/pr62120.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/avx512f-additional-reg-names.c trunk/gcc/varasm.c
[Bug preprocessor/58893] [4.8/4.9/5 Regression] command-line:0:0: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58893 --- Comment #12 from edlinger at gcc dot gnu.org --- Author: edlinger Date: Tue Sep 30 16:08:53 2014 New Revision: 215730 URL: https://gcc.gnu.org/viewcvs?rev=215730root=gccview=rev Log: 2014-09-30 Bernd Edlinger bernd.edlin...@hotmail.de PR preprocessor/58893 * errors.c (cpp_diagnostic): Fix possible out of bounds access. * files.c (_cpp_stack_include): Initialize src_loc for IT_CMDLINE. testsuite: 2014-09-30 Bernd Edlinger bernd.edlin...@hotmail.de PR preprocessor/58893 * gcc.dg/pr58893.c: New test case. * gcc.dg/pr58893-0.h: New include. Added: trunk/gcc/testsuite/gcc.dg/pr58893-0.h trunk/gcc/testsuite/gcc.dg/pr58893.c Modified: trunk/gcc/testsuite/ChangeLog trunk/libcpp/ChangeLog trunk/libcpp/errors.c trunk/libcpp/files.c
[Bug plugins/63410] [Regression] pass_instances.def is not installed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63410 --- Comment #2 from dmalcolm at gcc dot gnu.org --- Author: dmalcolm Date: Tue Sep 30 16:32:33 2014 New Revision: 215731 URL: https://gcc.gnu.org/viewcvs?rev=215731root=gccview=rev Log: PR plugins/63410 Fix missing pass-instances.def gcc/ PR plugins/63410 * Makefile.in (PLUGIN_HEADERS): Add pass-instances.def. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/Makefile.in
[Bug plugins/63410] [Regression] pass_instances.def is not installed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63410 dmalcolm at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from dmalcolm at gcc dot gnu.org --- Fixed on both trunk and 4.9 branch
[Bug fortran/61669] Error recovery ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61669 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Steven, do you plan to commit your fix which has been acked back in August?
[Bug c/63418] New: false positive with -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63418
Bug ID: 63418
Summary: false positive with -Wmaybe-uninitialized
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kcc at gcc dot gnu.org
I know there are some known false positives with -Wmaybe-uninitialized, so this
might be a dup. I'd like to document this one just in case this is another
corner case.
The test comes from a slightly modified glibc sources.
Tested with the fresh gcc trunk r215730.
% gcc w1.c -std=gnu99 -c -Wmaybe-uninitialized -O2
w1.c: In function ‘parse_expression.constprop’:
w1.c:13311:28: warning: ‘extra’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
if (name_len == extra[idx]
^
w1.c:13500:24: note: ‘extra’ was declared here
const unsigned char *extra;
Looking at the code:
extra is defined w/o initializer:
13500 const unsigned char *extra;
Then, it is initialized under if (nrules):
13522 if (nrules) {
...
13533 extra =
nrules never changes again.
The warning complains about extra being used in seek_collating_symbol_entry
w/o being initialied.
There are two calls to seek_collating_symbol_entry, they look like this:
13337 if (nrules != 0) {
13338 int32_t elem, idx;
13339 elem = seek_collating_symbol_entry(br_elem-opr.name, sym_name_len,
13456 if (nrules != 0) {
13457 elem = seek_collating_symbol_entry(name, name_len, symb_table,
table_size,
So, in both cases seek_collating_symbol_entry is called if nrules != 0, i.e.
'extra' is initialized.
If this is something new and unexpected I can prepare a better minimized
example, but I don't want to waste time if this is known.
I wasn't able to reproduce this on a tiny example.
[Bug c++/63419] New: verify_gimple failed: vector CONSTRUCTOR element is not a GIMPLE value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63419
Bug ID: 63419
Summary: verify_gimple failed: vector CONSTRUCTOR element is
not a GIMPLE value
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 33624
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33624action=edit
gzipped C++ source code
Attached code, when compiled by 20140927, with flag -O2,
does the following
$ ../results/bin/gcc -c -O2 bug165.cc
In file included from
/home/dcb/rpmbuild/BUILD/eigen-eigen-1306d75b4a21/Eigen/Core:294:0,
from
/home/dcb/rpmbuild/BUILD/eigen-eigen-1306d75b4a21/Eigen/Dense:1,
from
/home/dcb/rpmbuild/BUILD/eigen-eigen-1306d75b4a21/doc/examples/Tutorial_ArrayClass_interop.cpp:1:
/home/dcb/rpmbuild/BUILD/eigen-eigen-1306d75b4a21/Eigen/src/Core/Matrix.h: In
constructor ‘Eigen::Matrix_Scalar, _Rows, _Cols, _Options, _MaxRows,
_MaxCols::Matrix(const Eigen::MatrixBaseOtherDerived) [with OtherDerived =
Eigen::GeneralProductEigen::MatrixWrapperconst
Eigen::CwiseUnaryOpEigen::internal::scalar_add_opfloat, const
Eigen::ArrayWrapperEigen::Matrixfloat, -1, -1 , Eigen::Matrixfloat,
-1, -1, 5; _Scalar = float; int _Rows = -1; int _Cols = -1; int _Options = 0;
int _MaxRows = -1; int _MaxCols = -1]’:
/home/dcb/rpmbuild/BUILD/eigen-eigen-1306d75b4a21/Eigen/src/Core/Matrix.h:272:12:
error: vector CONSTRUCTOR element is not a GIMPLE value
EIGEN_STRONG_INLINE Matrix(const MatrixBaseOtherDerived other)
^
{(float) pretmp_197, (float) pretmp_197, (float) pretmp_197, (float)
pretmp_197}
1,0-1 Top
[Bug c++/16564] g++ seems to go into an infinite loop after errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564 --- Comment #25 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Tue Sep 30 17:10:35 2014 New Revision: 215733 URL: https://gcc.gnu.org/viewcvs?rev=215733root=gccview=rev Log: cp/ 2014-09-30 Manuel López-Ibáñez m...@gcc.gnu.org PR c++/16564 * error.c (print_instantiation_context): Delete. * typeck2.c (build_x_arrow): Record location when pushing template instantiation. * pt.c (push_tinst_level): Make it a wrapper around ... (push_tinst_level_loc): ... this. New function. Make excessive template instantiation depth a fatal error. Record location. Use bool as return type. (instantiate_pending_templates): Make excessive template instantiation depth a fatal error. (problematic_instantiation_changed): Use bool as return type. * cp-tree.h (print_instantiation_context): Delete. (push_tinst_level): Update declaration. (problematic_instantiation_changed): Likewise. (push_tinst_level_loc): New. testsuite/ 2014-09-30 Manuel López-Ibáñez m...@gcc.gnu.org PR c++/16564 * lib/gcc.exp: Accept fatal error: as error prefix. * lib/g++.exp: Likewise. * lib/obj-c++.exp: Likewise. * lib/objc.exp: Likewise. * g++.dg/template/pr16564.C: New test. 2014-09-30 Paolo Carlini paolo.carl...@oracle.com PR c++/16564 * g++.dg/cpp0x/decltype26.C: Adjust. * g++.dg/cpp0x/decltype28.C: Likewise. * g++.dg/cpp0x/decltype29.C: Likewise. * g++.dg/cpp0x/decltype32.C: Likewise. * g++.dg/cpp0x/enum11.C: Likewise. * g++.dg/template/arrow1.C: Likewise. * g++.dg/template/pr23510.C: Likewise. * g++.dg/template/recurse.C: Likewise. * g++.dg/template/recurse2.C: Likewise. * g++.dg/template/vtable2.C: Likewise. * g++.old-deja/g++.pt/infinite1.C: Likewise. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/error.c trunk/gcc/cp/pt.c trunk/gcc/cp/typeck2.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/decltype26.C trunk/gcc/testsuite/g++.dg/cpp0x/decltype28.C trunk/gcc/testsuite/g++.dg/cpp0x/decltype29.C trunk/gcc/testsuite/g++.dg/cpp0x/decltype32.C trunk/gcc/testsuite/g++.dg/cpp0x/enum11.C trunk/gcc/testsuite/g++.dg/template/arrow1.C trunk/gcc/testsuite/g++.dg/template/pr23510.C trunk/gcc/testsuite/g++.dg/template/recurse.C trunk/gcc/testsuite/g++.dg/template/recurse2.C trunk/gcc/testsuite/g++.dg/template/vtable2.C trunk/gcc/testsuite/g++.old-deja/g++.pt/infinite1.C trunk/gcc/testsuite/lib/g++.exp trunk/gcc/testsuite/lib/gcc.exp trunk/gcc/testsuite/lib/obj-c++.exp trunk/gcc/testsuite/lib/objc.exp
[Bug c++/16564] g++ seems to go into an infinite loop after errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564 --- Comment #26 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Tue Sep 30 17:11:38 2014 New Revision: 215734 URL: https://gcc.gnu.org/viewcvs?rev=215734root=gccview=rev Log: cp/ 2014-09-30 Manuel López-Ibáñez m...@gcc.gnu.org PR c++/16564 * error.c (print_instantiation_context): Delete. * typeck2.c (build_x_arrow): Record location when pushing template instantiation. * pt.c (push_tinst_level): Make it a wrapper around ... (push_tinst_level_loc): ... this. New function. Make excessive template instantiation depth a fatal error. Record location. Use bool as return type. (instantiate_pending_templates): Make excessive template instantiation depth a fatal error. (problematic_instantiation_changed): Use bool as return type. * cp-tree.h (print_instantiation_context): Delete. (push_tinst_level): Update declaration. (problematic_instantiation_changed): Likewise. (push_tinst_level_loc): New. testsuite/ 2014-09-30 Manuel López-Ibáñez m...@gcc.gnu.org PR c++/16564 * lib/gcc.exp: Accept fatal error: as error prefix. * lib/g++.exp: Likewise. * lib/obj-c++.exp: Likewise. * lib/objc.exp: Likewise. * g++.dg/template/pr16564.C: New test. 2014-09-30 Paolo Carlini paolo.carl...@oracle.com PR c++/16564 * g++.dg/cpp0x/decltype26.C: Adjust. * g++.dg/cpp0x/decltype28.C: Likewise. * g++.dg/cpp0x/decltype29.C: Likewise. * g++.dg/cpp0x/decltype32.C: Likewise. * g++.dg/cpp0x/enum11.C: Likewise. * g++.dg/template/arrow1.C: Likewise. * g++.dg/template/pr23510.C: Likewise. * g++.dg/template/recurse.C: Likewise. * g++.dg/template/recurse2.C: Likewise. * g++.dg/template/vtable2.C: Likewise. * g++.old-deja/g++.pt/infinite1.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/template/pr16564.C
[Bug c++/16564] g++ seems to go into an infinite loop after errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564 --- Comment #27 from Paolo Carlini paolo.carlini at oracle dot com --- Can we close the bug?
[Bug c/63420] New: GCC 4.8.2: Bitshift second operand range not as per manual.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63420
Bug ID: 63420
Summary: GCC 4.8.2: Bitshift second operand range not as per
manual.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: aainscow at uk dot ibm.com
Created attachment 33625
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33625action=edit
Demo code
Most likely this is simply a problem with the GCC manual.
The GCC documentation states (30th Sept 2014):
--
You use the left-shift operator to shift its first operand's bits to the
left. The second operand denotes the number of bit places to shift. Bits
shifted off the left side of the value are discarded; new bits added on the
right side will all be 0.
...
For both and , if the second operand is greater than the bit-width of the
first operand, or the second operand is negative, the behavior is undefined.
--
NOTE: greater than not greater than or equal to.
The following code should therefore not be undefined and return 0.
int main() {
int a = sizeof(int)*8;
return ((int)1) a;
}
However:
aainscow@morwenna:~/cake$ gcc bitshift_bug.c
aainscow@morwenna:~/cake$ ./a.out ; echo $?
1
Most likely this is a problem with documentation.
[Bug c++/16564] g++ seems to go into an infinite loop after errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564 --- Comment #28 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Paolo Carlini from comment #27) Can we close the bug? There is still the issue that we print: x.ii:5: instantiated from `SAAAint but that is PR43113, so I think yes, we can close this. Congratulations!
[Bug target/58139] PowerPC volatile VSX register live across call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58139 --- Comment #16 from Maciej W. Rozycki ma...@linux-mips.org --- The unwinder issue has been now fixed along PR target/60102, rev. 213596.
[Bug c++/16564] g++ seems to go into an infinite loop after errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED CC|paolo.carlini at oracle dot com| Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #29 from Paolo Carlini paolo.carlini at oracle dot com --- Ok, great.
[Bug c++/43113] too long diagnostics in some cases of recursive template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43113 Bug 43113 depends on bug 16564, which changed state. Bug 16564 Summary: g++ seems to go into an infinite loop after errors https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16564 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/63405] [4.9/5 regression] ICE in cp_perform_integral_promotions, at cp/typeck.c:2084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63405 Matthias Klose doko at gcc dot gnu.org changed: What|Removed |Added CC||doko at gcc dot gnu.org Known to work|4.9.2 | Summary|[5 regression] ICE in |[4.9/5 regression] ICE in |cp_perform_integral_promoti |cp_perform_integral_promoti |ons, at cp/typeck.c:2084|ons, at cp/typeck.c:2084 Known to fail||4.9.1 --- Comment #3 from Matthias Klose doko at gcc dot gnu.org --- you need -fstack-protector or -fstack-protector-strong to reproduce this.
[Bug c++/26099] support for type traits is not available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26099 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|NEW CC|gcc-bugs at gcc dot gnu.org| Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org
[Bug c++/62056] Long compile times with large tuples
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62056 --- Comment #9 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Agustín Bergé from comment #8) Please let me know if I can help you in any other way. Thanks for the detailed explanation. As for the g++ issue, then a minimal testcase that does not include the whole of tuple might be useful to see what could be speed up: See https://gcc.gnu.org/bugs/minimize.html The testcase itself might generate code programmatically using macros, for example, but less code without any headers is easier to analyze. I cannot say if the libstdc++ implementation could be better, but the way to prove it is simply to submit a new implementation and convince the maintainers that it is better with numbers. I'm sure they will be delighted to receive such contribution. But a draft is not enough. The new implementation needs to pass all testcases in the testsuite.
[Bug c++/63405] [4.9/5 regression] ICE in cp_perform_integral_promotions, at cp/typeck.c:2084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63405 --- Comment #4 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Matthias Klose from comment #3) you need -fstack-protector or -fstack-protector-strong to reproduce this. That still doesn't ICE the compiler on 4.9 branch.
[Bug c/63418] false positive with -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63418 --- Comment #1 from Kostya Serebryany kcc at gcc dot gnu.org --- Created attachment 33626 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33626action=edit w1.c attached the repro
[Bug c++/63405] [4.9/5 regression] ICE in cp_perform_integral_promotions, at cp/typeck.c:2084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63405 --- Comment #5 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Markus Trippelsdorf from comment #4) (In reply to Matthias Klose from comment #3) you need -fstack-protector or -fstack-protector-strong to reproduce this. That still doesn't ICE the compiler on 4.9 branch. Just double checked and yes, even 4.9 branch is affected (even without -fstack-protector or -fstack-protector-strong). However, my system gcc-4.9 compiler works fine. Configured with: ../gcc/configure --disable-libsanitizer --disable-bootstrap --disable-libstdcxx-pch --disable-libvtv --disable-libitm --disable-libcilkrts --disable-libssp --disable-libgomp --disable-werror --disable-multilib --enable-languages=c,c++ vs. Configured with: ../gcc/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.2 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.2 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.2/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.2/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --without-cloog --enable-lto --enable-nls --without-included-gettext --with-system-zlib --disable-werror --enable-initfini-array --with-gold --enable-secureplt --disable-multilib --disable-libvtv --disable-libitm --disable-libcilkrts --disable-libssp --disable-libgomp --enable-cld --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.9.2/python --enable-checking=release --disable-libgcj --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-boot-ldflags=-Wl,-O1,--hash-style=gnu,--as-needed,--gc-sections,--icf=safe,--icf-iterations=3 --enable-version-specific-runtime-libs --disable-libstdcxx-pch --enable-libstdcxx-time=yes --with-build-config=bootstrap-lto
[Bug c++/63405] [4.9/5 regression] ICE in cp_perform_integral_promotions, at cp/typeck.c:2084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63405 --- Comment #6 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Ah, the system compiler was build slightly before Jason's r215172 checkin from 20140911. gcc version 4.9.2 20140911 (prerelease) (GCC)
[Bug c/36750] -Wmissing-field-initializers relaxation request
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36750
Daniel Sommermann dcsommer at fb dot com changed:
What|Removed |Added
CC||dcsommer at fb dot com
--- Comment #11 from Daniel Sommermann dcsommer at fb dot com ---
Created attachment 33627
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33627action=edit
Test case showing overly strict warning
This still produces false positives in C++11.
I attached a test case with several false positives. The compilation should be
clean as there are no uninitialized members. Repros with g++ 4.9.1
Compile with g++ test.cpp -std=c++11 -Wmissing-field-initializers`
Produces:
dcsommer@dcsommer-ThinkPad-T440s:~/src/proxygen-oss-test/proxygen$ g++ test.cpp
-Wmissing-field-initializers -std=c++11
test.cpp: In function ‘int main()’:
test.cpp:7:10: warning: missing initializer for member ‘Foo::bar’
[-Wmissing-field-initializers]
Foo f1{};
^
test.cpp:7:10: warning: missing initializer for member ‘Foo::baz’
[-Wmissing-field-initializers]
test.cpp:8:11: warning: missing initializer for member ‘Foo::baz’
[-Wmissing-field-initializers]
Foo f2{0};
^
test.cpp:9:14: warning: missing initializer for member ‘Foo::baz’
[-Wmissing-field-initializers]
Foo f3 = {0};
^
test.cpp:10:15: warning: missing initializer for member ‘Foo::baz’
[-Wmissing-field-initializers]
Foo f4 = {0,};
^
[Bug sanitizer/63316] [5.0 Regression] False asan positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63316 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- fixed on trunk
[Bug c++/62056] Long compile times with large tuples
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62056 --- Comment #10 from Agustín Bergé kaballo86 at hotmail dot com --- (In reply to Manuel López-Ibáñez from comment #9) I cannot say if the libstdc++ implementation could be better From a compile-time performance point of view it is, check the implementation attached to this issue. but the way to prove it is simply to submit a new implementation and convince the maintainers that it is better with numbers. I'm sure they will be delighted to receive such contribution. But a draft is not enough. The new implementation needs to pass all testcases in the testsuite. Such implementation and numbers were initially attached to this issue. The draft implementation is feature complete (modulo bugs) and is implemented with the minimal possible number of changes from the current implementation. The entire functionality is retained, the layout is switch to left-to-right (instead of reversed), I have not analyzed codegen. I was directly instructed by libstdc++ developers to submit this issue, I was told they were not aware of the poor compile-time performance of tuple. I submitted the issue as instructed. I decided to add the proof-of-concept implementation so that people could understand the implications by simply replacing a header. I added the analysis of the underlying issue upon your request. I am not interested in pursuing this further without as much as a hint that the compile-time performance issue would even be considered. Remember, this is QoI, so completely ignoring this issue is a reasonable resolution. After all, this is a known issue with known solutions (or I should say workarounds, as the underlying issue is not addressed), and there are other concerns to keep in mind besides compile-time performance.
[Bug c++/63405] [4.9/5 regression] ICE in cp_perform_integral_promotions, at cp/typeck.c:2084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63405 --- Comment #7 from Gert-jan Los gerrit.los at gmail dot com --- 2014-09-30 20:39:22 CEST schrieb trippels at gcc dot gnu.org: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63405 --- Comment #6 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Ah, the system compiler was build slightly before Jason's r215172 checkin from 20140911. gcc version 4.9.2 20140911 (prerelease) (GCC) The code triggering the ICE has been part of my code base since at least 3 months. Within the project I used varying snaphots from trunk without any problems. I just retested with my system compiler [gcc version 4.9.1 (Debian 4.9.1-15)] and now also get: internal compiler error: in cp_perform_integral_promotions, at cp/typeck.c:2066 To provide context I attached: a) backtrace b) bisect log c) check script for creduce and bisect d) my reduced testcase At every git-bisect step I did a full bootstrap $dir/$tgt/configure \ --prefix=$prefix \ --program-suffix=-snapshot \ --with-gmp=$prefix \ --with-mpfr=$prefix \ --with-mpc=$prefix \ --with-gnu-ld \ --enable-build-with-cxx --enable-cxx \ --enable-gold --enable-ld=default \ --enable-plugin --with-plugin-ld=ld.gold \ --enable-languages=c,c++ \ --enable-checking=release make -j4 bootstrap make install As you can see in bisect.log some checkouts did not trigger the internal compiler error. I now see one possible defect in my testing methodology: I'm grepping for the line number of the error message. Will retest with the fixed check condition and report back tomorrow if the outcome changes.
[Bug c++/63405] [4.9/5 regression] ICE in cp_perform_integral_promotions, at cp/typeck.c:2084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63405 --- Comment #8 from Gert-jan Los gerrit.los at gmail dot com --- Created attachment 33629 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33629action=edit bisect.log --- Comment #9 from Gert-jan Los gerrit.los at gmail dot com --- Created attachment 33630 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33630action=edit check.sh --- Comment #10 from Gert-jan Los gerrit.los at gmail dot com --- Created attachment 33631 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33631action=edit testcase.i
[Bug target/55212] [SH] Switch from IRA to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #50 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Tue Sep 30 22:12:42 2014 New Revision: 215744 URL: https://gcc.gnu.org/viewcvs?rev=215744root=gccview=rev Log: PR target/55212 * lra.c (lra_update_insn_regno_info): Handle mem args in calls. Modified: branches/sh-lra/gcc/lra.c
[Bug target/55212] [SH] Switch from IRA to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #51 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to Oleg Endo from comment #50) Author: olegendo Date: Tue Sep 30 22:12:42 2014 New Revision: 215744 URL: https://gcc.gnu.org/viewcvs?rev=215744root=gccview=rev Log: PR target/55212 * lra.c (lra_update_insn_regno_info): Handle mem args in calls. Modified: branches/sh-lra/gcc/lra.c This fixes the issue with attachment 33615.
[Bug target/55212] [SH] Switch from IRA to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #52 from Oleg Endo olegendo at gcc dot gnu.org --- Created attachment 33632 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33632action=edit Reduced case of error: in assign_by_spills, at lra-assigns.c:1335
[Bug c/63418] false positive with -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63418 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org --- With such a large testcase, it is difficult to say. GCC seems to think that the use is unguarded: [WORKLIST]: add to initial list: extra_332 = PHI extra_734(D)(228), extra_235(15) [CHECK]: examining phi: extra_332 = PHI extra_734(D)(228), extra_235(15) [CHECK]: Found unguarded use: _600 = extra_332 + _599; Perhaps we are hitting some limit, perhaps it is a bug. Perhaps both. Hard to tell. In any case, there are so many known Wuninitialized bugs and no one to fix them that it is probably something known. I really would not bother about reporting more Wuninitialized bugs unless you can show it is a regression. It is simply not worth your time. Better put together all those minutes that you would spent reporting them and fix a known one or convince someone to fix it ;-)
[Bug c/63418] false positive with -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63418 --- Comment #3 from Kostya Serebryany kcc at gcc dot gnu.org --- Thanks for confirming the current state of this warning :)
[Bug c/63421] New: GCC generates a very misleading warning when looking at an erroneously-overloaded type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63421
Bug ID: 63421
Summary: GCC generates a very misleading warning when looking
at an erroneously-overloaded type
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gccbugs at dima dot secretsauce.net
Hi. I'm running gcc-4.9.1 from Debian/sid. This is built off of r214759. When
building source that had a mistake GCC produced a very misleading warning that
masked the underlying issue. A minimized test case:
typedef struct
{
int x, y, z;
} S;
struct S
{
int x;
};
S s;
void g(struct S *);
void f()
{
g(s);
}
Here the error is that S is defined both as a struct and a typedef struct. g()
expects a 'struct S *', but I'm giving it a S*. When gcc builds this I see:
dima@shorty:/tmp/recorder$ /usr/bin/gcc-4.9 -g -O0 -Wall -Wextra -std=gnu99 -I.
-c -o dbtest.o dbtest.c
dbtest.c: In function 'f':
dbtest.c:17:5: warning: passing argument 1 of 'g' from incompatible pointer
type
g(s);
^
dbtest.c:13:6: note: expected 'struct S *' but argument is of type 'struct S *'
void g(struct S *);
^
So it tells me that the function is getting a type mismatch, but it says that
both what it wants and what it got was 'struct S *'. This makes the complaint
look redundant.
[Bug debug/62225] DW_AT_location for local variable is missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62225 Sandra Loosemore sandra at codesourcery dot com changed: What|Removed |Added CC||sandra at codesourcery dot com --- Comment #4 from Sandra Loosemore sandra at codesourcery dot com --- I believe this bug is responsible for the GDB gdb.base/restore.exp test failures reported in the GDB bug tracker (issues 16655 and 17019). There are many such failures for arm-none-eabi with -mthumb.
[Bug debug/63285] [4.9 Regression] -fcompare-debug scheduler related failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63285
--- Comment #6 from Vladimir Makarov vmakarov at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #5)
Vlad, do you plan to apply this to 4.9 and 4.8 branches too?
For 4.9, I've bootstrapped/regtested it on
{x86_64,i686,armv7hl,aarch64}-linux.
Yes, I have plans to commit it for the branches this week. Simply, I wanted to
wait a bit in case if somebody finds issues with the patch.
Jakub, I can do it tomorrow if you want and there are deadlines with releases.
Please, just let me know if there are any deadlines.
[Bug inline-asm/62144] Frame pointer required, but reserved error with -fomit-frame-pointer but only with -m32 -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62144 --- Comment #3 from Vladimir Makarov vmakarov at gcc dot gnu.org --- (In reply to Brooks Moses from comment #2) Ping? Any updates on this? Sorry, I'll look at this in a week or if I am lucky this week. Right now, I am quite busy with register rematerialization pass in LRA which I'd like to make ready for gcc-5.0.
[Bug inline-asm/62144] Frame pointer required, but reserved error with -fomit-frame-pointer but only with -m32 -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62144 --- Comment #4 from Brooks Moses brooks at gcc dot gnu.org --- Thanks. I have to admit that that does seem more generally useful! :)
[Bug middle-end/63422] New: [5.0 Regression] ICE in freqs_to_counts_path, at tree-ssa-threadupdate.c:981
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63422 Bug ID: 63422 Summary: [5.0 Regression] ICE in freqs_to_counts_path, at tree-ssa-threadupdate.c:981 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: Joost.VandeVondele at mat dot ethz.ch In the one day between r215702 and 215747 trunk started failing to compile CP2K with '-c -flto=jobserver -fprofile-use '. Several lto instances fail with: /data/vjoost/gnu/cp2k/cp2k/makefiles/../src/core_ae.F:58:0: internal compiler error: in freqs_to_counts_path, at tree-ssa-threadupdate.c:988 SUBROUTINE build_core_ae(matrix_h, matrix_p, force, virial, calculate_forces, use_virial, nder, ^ 0xb4e8c0 freqs_to_counts_path ../../gcc/gcc/tree-ssa-threadupdate.c:988 0xb4e8c0 ssa_fix_duplicate_block_edges(redirection_data*, ssa_local_info_t*) ../../gcc/gcc/tree-ssa-threadupdate.c:1061 0xb4f018 ssa_fixup_template_block ../../gcc/gcc/tree-ssa-threadupdate.c:1301 0xb4f018 traverse_noresizessa_local_info_t*, ssa_fixup_template_block ../../gcc/gcc/hash-table.h:942 0xb4f018 traversessa_local_info_t*, ssa_fixup_template_block ../../gcc/gcc/hash-table.h:964 0xb4f018 thread_block_1 ../../gcc/gcc/tree-ssa-threadupdate.c:1523 0xb4f4e0 thread_block ../../gcc/gcc/tree-ssa-threadupdate.c:1560 0xb4fd6e thread_through_all_blocks(bool) ../../gcc/gcc/tree-ssa-threadupdate.c:2279 0xbd86ed finalize_jump_threads ../../gcc/gcc/tree-vrp.c:9856 0xbd86ed execute_vrp ../../gcc/gcc/tree-vrp.c:10010 given the combination of lto and profile-use it will be difficult to generate a testcase (other than building full cp2k with profile feedback, which is somewhat involved).
[Bug middle-end/63422] [5.0 Regression] ICE in freqs_to_counts_path, at tree-ssa-threadupdate.c:981
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63422 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch, tejohnson at google dot com --- Comment #1 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- I suspect this is caused by r215739
[Bug c/61898] Variadic functions accept va_list without warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61898 Andi Kleen andi-gcc at firstfloor dot org changed: What|Removed |Added CC||andi-gcc at firstfloor dot org --- Comment #3 from Andi Kleen andi-gcc at firstfloor dot org --- Created attachment 33633 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33633action=edit Proposed patch This patch implements the warning for the non constant format case. Not done for passing va_list to a real format, but I assume that is rare and in most cases caught by the normal type checking. Let me know if it works.
[Bug middle-end/63422] [5.0 Regression] ICE in freqs_to_counts_path, at tree-ssa-threadupdate.c:981
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63422 --- Comment #2 from Teresa Johnson tejohnson at google dot com --- Yes, this function is new in r215739. I will see if I can trigger it tomorrow. If you have a smaller test case that would be great. Or even if you can give me the gcda file and preprocessed source that will help. Teresa On Tue, Sep 30, 2014 at 9:12 PM, Joost.VandeVondele at mat dot ethz.ch gcc-bugzi...@gcc.gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63422 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch, tejohnson at google dot com --- Comment #1 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- I suspect this is caused by r215739 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debug/63285] [4.9 Regression] -fcompare-debug scheduler related failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63285
--- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Vladimir Makarov from comment #6)
(In reply to Jakub Jelinek from comment #5)
Vlad, do you plan to apply this to 4.9 and 4.8 branches too?
For 4.9, I've bootstrapped/regtested it on
{x86_64,i686,armv7hl,aarch64}-linux.
Yes, I have plans to commit it for the branches this week. Simply, I wanted
to wait a bit in case if somebody finds issues with the patch.
Jakub, I can do it tomorrow if you want and there are deadlines with
releases. Please, just let me know if there are any deadlines.
That would be nice, we should release 4.9.2-rc1 this or next week.
[Bug middle-end/63422] [5.0 Regression] ICE in freqs_to_counts_path, at tree-ssa-threadupdate.c:981
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63422 --- Comment #3 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Teresa Johnson from comment #2) Yes, this function is new in r215739. I will see if I can trigger it tomorrow. If you have a smaller test case that would be great. Or even if you can give me the gcda file and preprocessed source that will help. this only happens with LTO, so I'm not sure there is easily a source file I can provide (with ~1000 .gdca files). I tried some smaller programs, but didn't see the problem yet.
