[Bug libstdc++/61582] C++11 regex memory corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61582
--- Comment #7 from Tim Shen timshen at gcc dot gnu.org ---
(.*{100}{100}{100}) seems to be a stack overflow. It's because regex executor
uses recursion. It could be fixed (not segfault but memory exhaustion) by using
a std::stack and simulate recursion; IMH, however, directly throwing
regex_error::error_space is the right thing here to do.
[Bug libstdc++/61601] C++11 regex resource exhaustion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61601 --- Comment #2 from Tim Shen timshen at gcc dot gnu.org --- (In reply to Jonathan Wakely from comment #1) Tim, how hard would it be to hardcode limits somewhere for these cases? It's easy. 6 lines. I'll propose a patch soon.
[Bug libstdc++/61582] C++11 regex memory corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61582
--- Comment #8 from Maksymilian Arciemowicz max at cert dot cx ---
(In reply to Tim Shen from comment #7)
(.*{100}{100}{100}) seems to be a stack overflow. It's because regex
executor uses recursion. It could be fixed (not segfault but memory
exhaustion) by using a std::stack and simulate recursion; IMH, however,
directly throwing regex_error::error_space is the right thing here to do.
Yeap it's stack overflow. Why regex_error::error_space? Not better
regex_error::error_stack?
[Bug libstdc++/61582] C++11 regex memory corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61582
--- Comment #9 from Tim Shen timshen at gcc dot gnu.org ---
(In reply to Maksymilian Arciemowicz from comment #8)
(In reply to Tim Shen from comment #7)
(.*{100}{100}{100}) seems to be a stack overflow. It's because regex
executor uses recursion. It could be fixed (not segfault but memory
exhaustion) by using a std::stack and simulate recursion; IMH, however,
directly throwing regex_error::error_space is the right thing here to do.
Yeap it's stack overflow. Why regex_error::error_space? Not better
regex_error::error_stack?
Sorry for not clarify that: I prefer throwing error_space when constructing
(complaining about too many states) instead of throwing error_stack when
matching. To solve the latter problem, as I said, we can use a std::stack or
something to avoid a stack overflow.
[Bug target/61616] New: Internal compiler error during reload in gcc-4.7.4 configured as a cross-compiler for a mips target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61616
Bug ID: 61616
Summary: Internal compiler error during reload in gcc-4.7.4
configured as a cross-compiler for a mips target
Product: gcc
Version: 4.7.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: niva at niisi dot msk.ru
Created attachment 33008
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33008action=edit
The test file.
The cross-compiler gcc-4.7.4:
Configured with: /home/niva/src/gcc-4.7.4/configure --target=mips64-none-elf
--enable-threads=no --disable-shared --enable-long-long --enable-c99
--enable-languages=c --enable-multilib --enable-symvers=gnu
--disable-libmudflap --disable-libssp --disable-libgcc_eh --with-newlib
--with-dwarf2 --with-system-zlib --enable-generated-files-in-srcdir --verbose
--prefix=/home/niva/local --enable-cpp
The command line is:
mips64-none-elf-gcc-4.7.4 prfl.c -O3 -G0 -mips64 -mpaired-single -mabi=o64 -S
The error message:
prfl.c:42:1: error: unable to find a register to spill in class ‘GR_REGS’
prfl.c:42:1: error: this is the insn:
(insn 79 65 117 2 (set (reg:CCV2 360)
(unspec:CCV2 [
(unlt (reg:V2SF 34 $f2 [orig:306 MEM[(float[4] *)s1 + 8B] ]
[306])
(reg:V2SF 33 $f1 [orig:307 MEM[(float[4] *)s2 + 8B] ]
[307]))
] UNSPEC_SCC)) prfl.c:15 701 {sunlt_ps}
(nil))
prfl.c:42: confused by earlier errors, bailing out
The source file is attached. It was produced from
gcc-4.7.4/gcc/testsuite/gcc.c-torture/execute/ieee/pr50310.c
as a result of substitution of the float type instead of double.
[Bug rtl-optimization/60947] [4.9/4.10 Regression] Unable to handle kernel paging request (linux kernel 2.6.28.9) with gcc 4.9 release
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60947 --- Comment #16 from Mikael Pettersson mikpelinux at gmail dot com --- (In reply to amker from comment #15) Well, only thing suspicious that I can see, the memset function is a special implementation and not from C standard library. Basically it doesn't need to follow the standard, which means the return value could be something else other than the passed in pointer. Though I doubt it would actually break the standard. So YuFan, could you help look into implementation of memset to see if it acts as expected? Thanks. I recall seeing reports of the Linux/ARM kernel being miscompiled by gcc-4.8 (or so) a while ago, and it was traced to an in-kernel memset() (or related mem/str-function) implementation not following the same return value convention as the normal user-space version. The problem is that newer gcc:s optimize some mem/str-functions based on those return value conventions, so things broke. The 2.6.28 kernel is ancient, so it's not at all surprising it won't work when compiled by non-ancient gcc:s.
[Bug sanitizer/61604] missing line numbers in a sanitizer backtrace from an OMP region
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61604 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #1 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- for reference, valgrind yields a better trace, suggesting that the debug info is at least available: ==5301== 400 bytes in 1 blocks are definitely lost in loss record 5 of 7 ==5301==at 0x4A0534D: malloc (vg_replace_malloc.c:291) ==5301==by 0x400795: s1_._omp_fn.0 (PR61604.f90:4) ==5301==by 0x4D5D76D: gomp_thread_start (team.c:117) ==5301==by 0x3F924079D0: start_thread (in /lib64/libpthread-2.12.so) ==5301==by 0x3F918E8B6C: clone (in /lib64/libc-2.12.so) ==5301== ==5301== 400 bytes in 1 blocks are definitely lost in loss record 6 of 7 ==5301==at 0x4A0534D: malloc (vg_replace_malloc.c:291) ==5301==by 0x400795: s1_._omp_fn.0 (PR61604.f90:4) ==5301==by 0x4D5A63E: GOMP_parallel (parallel.c:167) ==5301==by 0x4007C3: s1_ (PR61604.f90:1) ==5301==by 0x4007E2: main (PR61604.f90:9)
[Bug tree-optimization/61607] DOM missed jump threading and destroyed loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61607 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Thu Jun 26 07:44:10 2014 New Revision: 212011 URL: https://gcc.gnu.org/viewcvs?rev=212011root=gccview=rev Log: 2014-06-26 Richard Biener rguent...@suse.de PR tree-optimization/61607 * tree-ssa-threadupdate.c (ssa_redirect_edges): Cancel the loop if we redirected its latch edge. (thread_block_1): Do not cancel loops prematurely. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-threadupdate.c
[Bug target/61616] Internal compiler error during reload in gcc-4.7.4 configured as a cross-compiler for a mips target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61616 --- Comment #1 from Mikael Pettersson mikpelinux at gmail dot com --- Upstream support for gcc-4.7 has just ended. Please try gcc-4.8.3 or gcc-4.9.0 instead and report whether they work or not.
[Bug other/61391] [4.10 Regression] ICE in execute_one_pass at -O3 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61391 --- Comment #4 from Yuri Rumyantsev ysrumyan at gmail dot com --- It turned out that wrong PR number was used in ChangeLog. In fact this bug was fixed: URL: http://gcc.gnu.org/viewcvs?rev=211263root=gccview=rev Log: gcc/ PR tree-optimization/61319 * tree-if-conv.c (is_cond_scalar_reduction): Add missed check that stmt belongs to loop. gcc/testsuite/ * gcc.dg/torture/pr61319.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr61391.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-if-conv.c
[Bug libstdc++/61582] C++11 regex memory corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61582 --- Comment #10 from Maksymilian Arciemowicz max at cert dot cx --- There is also one other alternative like this http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/regex/regcomp.c.diff?r1=1.29r2=1.30f=h
[Bug tree-optimization/61576] [4.10 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61576 Igor Zamyatin izamyatin at gmail dot com changed: What|Removed |Added CC||izamyatin at gmail dot com --- Comment #5 from Igor Zamyatin izamyatin at gmail dot com --- Patch is posted at http://gcc.gnu.org/ml/gcc-patches/2014-06/msg01866.html
[Bug c++/61614] [4.9/4.10 Regression] Bogus error: taking address of temporary array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61614 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- What do you mean by sometime after? Is that commit or something else, later? In case we should bisect.
[Bug c++/61614] [4.9/4.10 Regression] Bogus error: taking address of temporary array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61614 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-06-26 Ever confirmed|0 |1 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Had a quick look and indeed must be a later commit (the conditional added in r200178 isn't reached). We should bisect.
[Bug rtl-optimization/60947] [4.9/4.10 Regression] Unable to handle kernel paging request (linux kernel 2.6.28.9) with gcc 4.9 release
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60947 --- Comment #17 from amker at gcc dot gnu.org --- (In reply to Mikael Pettersson from comment #16) (In reply to amker from comment #15) Well, only thing suspicious that I can see, the memset function is a special implementation and not from C standard library. Basically it doesn't need to follow the standard, which means the return value could be something else other than the passed in pointer. Though I doubt it would actually break the standard. So YuFan, could you help look into implementation of memset to see if it acts as expected? Thanks. I recall seeing reports of the Linux/ARM kernel being miscompiled by gcc-4.8 (or so) a while ago, and it was traced to an in-kernel memset() (or related mem/str-function) implementation not following the same return value convention as the normal user-space version. The problem is that newer gcc:s optimize some mem/str-functions based on those return value conventions, so things broke. The 2.6.28 kernel is ancient, so it's not at all surprising it won't work when compiled by non-ancient gcc:s. Ah, I checked the architecture implementation of memset on ARM in 2.6.28 kernel, seems to me it does operate on r0/arg1 directly and return the modified register. This means it does violate the standard. Hi YuFan, It seems to me GCC works fine, you may need to confirm the finding here and patch the implementation of memset. Thanks.
[Bug c++/58051] No named return value optimization when returned object is implicitly converted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58051 piotr5 at netscape dot net changed: What|Removed |Added CC||piotr5 at netscape dot net --- Comment #1 from piotr5 at netscape dot net --- I have the same problem, it makes the r-value types tedious. however this is not a bug in gcc directly, it's a bug in stdc++1x specs omitting this special case and what should be done here. however, as a feature-request I suggest at least when accepting gcc extensions to the standard (or better yet check with the stdc++1x paper if this contradicts the standard), gcc should proceed as suggested in this bug-report. more concretely: if in the example given the return-value rval would stay alive after the return (for example it's static), then the current behaviour of gcc should be kept. if rval would become destroyed because of going out of scope through the return, then std::move() should implicitly be added by the compiler alike to syntactic sugar. alternatively one could write a software which checks all return statements for classes which can be r-value initialized and outputs a warning whenever the return statement doesn't come with std::move() around the returned value and the used variable is going out of scope. this functionality could also be added to whatever code-checker. but such a solution would only introduce yet another hassle for the programmer. to emphasize: the reason why this feature is important is because gcc doesn't automatically do garbage-collection. if return-statements copy and destroy some big class frequently, this creates many holes in memory, cluttering free space. so this kind of optimization is needed for both, speed and size...
[Bug target/61616] Internal compiler error during reload in gcc-4.7.4 configured as a cross-compiler for a mips target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61616 --- Comment #2 from niva at niisi dot msk.ru --- I've checked that gcc-4.8.1 works OK.
[Bug libstdc++/56193] ios_base should replace operator void* with explicit operator bool in C++11 onwards.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56193 --- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org --- It will be ready when it's ready - there are bigger issues that are higher priority
[Bug libstdc++/56193] ios_base should replace operator void* with explicit operator bool in C++11 onwards.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56193 --- Comment #10 from Daniel Krügler daniel.kruegler at googlemail dot com --- (In reply to Jonathan Wakely from comment #9) Yes, sure.
[Bug libstdc++/61617] New: add boost::coroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61617 Bug ID: 61617 Summary: add boost::coroutine Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: piotr5 at netscape dot net this has been suggested for addition in the next standard. it is an important element of c++ because iterator-code can become quite incomprehensible otherwise. but the main reason I'd like to see it as part of gcc is so that programmers responsible for optimizations could start thinking up ways to implement coroutines on the various platforms in creative ways. no need to wait with optimization-ideas for the standard to include it, when it's already being used in other programming languages. but if it isn't being used in c++ it likely wont get much attention...
[Bug c++/58051] [DR1579] No named return value optimization when returned object is implicitly converted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58051 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-06-26 Summary|No named return value |[DR1579] No named return |optimization when returned |value optimization when |object is implicitly|returned object is |converted |implicitly converted Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Ryan Johnson from comment #0) RVO works properly if go() returns A() or std::move(rval). RVO is already working properly, C++11 did not allow the expression in the return statement to be treated as an rvalue when it is a different type to the function's return type. However the standard changed: http://open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579
[Bug rtl-optimization/60947] [4.9/4.10 Regression] Unable to handle kernel paging request (linux kernel 2.6.28.9) with gcc 4.9 release
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60947 amker at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #18 from amker at gcc dot gnu.org --- Mark it as invalid.
[Bug libstdc++/61617] add boost::coroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61617 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to piotr5 from comment #0) this has been suggested for addition in the next standard. So have lots of other things, many of them contradictory. We've got plenty of work that *is* in the standard to do first. In the meantime boost::coroutine already exists in Boost.
[Bug c++/61614] [4.9/4.10 Regression] Bogus error: taking address of temporary array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61614
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com ---
It's r204228:
2013-10-30 Jason Merrill ja...@redhat.com
* semantics.c (finish_compound_literal): Don't create a static variable
inside cp_unevaluated_operand.
indeed, the error happens in decay_conversion in:
if (TREE_CODE (exp) == TARGET_EXPR)
{
if (complain tf_error)
error_at (loc, taking address of temporary array);
where we have a TARGET_EXPR (vs a VAR_DECL).
[Bug c++/58051] [DR1579] No named return value optimization when returned object is implicitly converted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58051 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- I wonder if it's this simple: --- a/gcc/cp/typeck.c +++ b/gcc/cp/typeck.c @@ -8618,8 +8618,6 @@ check_return_expr (tree retval, bool *no_warning) || TREE_CODE (retval) == PARM_DECL) DECL_CONTEXT (retval) == current_function_decl !TREE_STATIC (retval) - same_type_p ((TYPE_MAIN_VARIANT (TREE_TYPE (retval))), - (TYPE_MAIN_VARIANT (functype))) /* This is only interesting for class type. */ CLASS_TYPE_P (functype)) flags = flags | LOOKUP_PREFER_RVALUE;
[Bug target/56858] alpha looks for NOTE_INSN_EH_REGION notes that cannot exist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56858
--- Comment #14 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Uroš Bizjak from comment #12)
Steven, is it possible to emit NOTE_INSN_EH_REGION_END in such way that it
would not split the call and its NOTE_INSN_CALL_ARG_LOCATION? This would
solve the above problem in the most elegant way.
Actually, it is barriers pass that splits the call and its
NOTE_INSN_CALL_ARG_LOCATION. Before the pass, we have:
(call_insn:TI 117 113 196 (parallel [
(call (mem:DI (symbol_ref:DI (__cxa_throw) [flags 0x41]
function_decl 0x7ff44719f900 __cxa_throw) [0 __cxa_throw S8 A64])
(const_int 0 [0]))
(use (reg:DI 29 $29))
(clobber (reg:DI 26 $26))
]) eh-vararg-1.C:62 207 {*call_osf_1_noreturn}
(expr_list:REG_DEAD (reg:DI 18 $18)
(expr_list:REG_DEAD (reg:DI 17 $17)
(expr_list:REG_DEAD (reg:DI 16 $16)
(expr_list:REG_EH_REGION (const_int 1 [0x1])
(expr_list:REG_CALL_DECL (symbol_ref:DI (__cxa_throw)
[flags 0x41] function_decl 0x7ff44719f900 __cxa_throw)
(expr_list:REG_NORETURN (const_int 0 [0])
(nil)))
(expr_list:DI (use (reg:DI 16 $16))
(expr_list:DI (use (reg:DI 17 $17))
(expr_list:DI (use (reg:DI 18 $18))
(nil)
(note 196 117 195 (expr_list:REG_DEP_TRUE (concat:DI (reg:DI 17 $17)
(symbol_ref/i:DI (_ZTI1A) var_decl 0x7ff447194630 _ZTI1A))
(expr_list:REG_DEP_TRUE (concat:DI (reg:DI 18 $18)
(const_int 0 [0]))
(nil))) NOTE_INSN_CALL_ARG_LOCATION)
(note/c 195 196 118 (var_location this (nil)) NOTE_INSN_VAR_LOCATION)
(barrier 118 195 197)
and barriers pass reorders this sequence to:
(call_insn:TI 117 113 118 (parallel [
(call (mem:DI (symbol_ref:DI (__cxa_throw) [flags 0x41]
function_decl 0x7f21556d0900 __cxa_throw) [0 __cxa_throw S8 A64])
(const_int 0 [0]))
(use (reg:DI 29 $29))
(clobber (reg:DI 26 $26))
]) eh-vararg-1.C:62 207 {*call_osf_1_noreturn}
(expr_list:REG_DEAD (reg:DI 18 $18)
(expr_list:REG_DEAD (reg:DI 17 $17)
(expr_list:REG_DEAD (reg:DI 16 $16)
(expr_list:REG_EH_REGION (const_int 1 [0x1])
(expr_list:REG_CALL_DECL (symbol_ref:DI (__cxa_throw)
[flags 0x41] function_decl 0x7f21556d0900 __cxa_throw)
(expr_list:REG_NORETURN (const_int 0 [0])
(nil)))
(expr_list:DI (use (reg:DI 16 $16))
(expr_list:DI (use (reg:DI 17 $17))
(expr_list:DI (use (reg:DI 18 $18))
(nil)
(barrier 118 117 196)
(note 196 118 195 (expr_list:REG_DEP_TRUE (concat:DI (reg:DI 17 $17)
(symbol_ref/i:DI (_ZTI1A) var_decl 0x7f21556c5630 _ZTI1A))
(expr_list:REG_DEP_TRUE (concat:DI (reg:DI 18 $18)
(const_int 0 [0]))
(nil))) NOTE_INSN_CALL_ARG_LOCATION)
(note/c 195 196 197 (var_location this (nil)) NOTE_INSN_VAR_LOCATION)
Indeed the purpose of barriers RTL pass is (from jump.c):
--cut here--
/* Some old code expects exactly one BARRIER as the NEXT_INSN of a
non-fallthru insn. This is not generally true, as multiple barriers
may have crept in, or the BARRIER may be separated from the last
real insn by one or more NOTEs.
This simple pass moves barriers and removes duplicates so that the
old code is happy.
*/
static unsigned int
cleanup_barriers (void)
{
rtx insn, next, prev;
for (insn = get_insns (); insn; insn = next)
{
next = NEXT_INSN (insn);
if (BARRIER_P (insn))
{
prev = prev_nonnote_insn (insn);
if (!prev)
continue;
if (BARRIER_P (prev))
delete_insn (insn);
else if (prev != PREV_INSN (insn))
reorder_insns_nobb (insn, insn, prev);
}
}
return 0;
}
--cut here--
This is the hack to keep the old code happy (?!), instead of teaching the
problematic code that varous debug notes can be between paired insns in the
insn stream.
[Bug c++/61507] GCC does not compile function with parameter pack.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61507 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.1 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Thus I would say fixed for 4.9.1.
[Bug target/56858] alpha looks for NOTE_INSN_EH_REGION notes that cannot exist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56858 --- Comment #15 from Uroš Bizjak ubizjak at gmail dot com --- Created attachment 33009 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33009action=edit Updated patch that introduces trap_shadows pass after eh_ranges Updated patch due to the new pass manager.
[Bug preprocessor/60723] Line directives with incorrect system header flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60723 --- Comment #12 from Dodji Seketeli dodji at gcc dot gnu.org --- Created attachment 33010 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33010action=edit A patch candidate that I am currently testing This the patch I am running through bootstrap at the moment. The patch basically makes the pre-processor detects changes in system-ness of tokens and upon each of these change, emits a line marking directive so that the information about the system-ness change is not lost. I haven't commented the code yet. Nicholas, maybe you could test the patch and give me feedback until my (slow) machine completes the bootstrap? Thanks.
[Bug c++/39270] Explicit instantiation rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39270 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Mine.
[Bug target/61360] [4.10 Regression] ICE: in lra_update_insn_recog_data, at lra.c:1363 with -mtune=bdver4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61360 GGanesh Ganesh.Gopalasubramanian at amd dot com changed: What|Removed |Added CC||Ganesh.Gopalasubramanian@am ||d.com --- Comment #4 from GGanesh Ganesh.Gopalasubramanian at amd dot com --- Any update on this? Almost the entire polyhedron benchmark suite fails with -Ofast -march=bdver3.
[Bug c++/58972] Lambda can't access private members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58972 --- Comment #4 from Akim Demaille akim.demaille at gmail dot com --- Could someone confirm this bug? The 4.9 I have does not ICEs and still refuses both sources. akim@erebus /tmp $ g++-mp-4.9 --version 13:12:11 g++-mp-4.9 (MacPorts gcc49 4.9-20140416_2) 4.9.0 20140416 (prerelease) 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.
[Bug tree-optimization/61607] DOM missed jump threading and destroyed loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61607 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Thu Jun 26 11:29:34 2014 New Revision: 212026 URL: https://gcc.gnu.org/viewcvs?rev=212026root=gccview=rev Log: 2014-06-26 Richard Biener rguent...@suse.de PR tree-optimization/61607 * tree-ssa-copy.c (copy_prop_visit_phi_node): Adjust comment explaining why we restrict copies on loop depth. * tree-ssa-dom.c (cprop_operand): Remove restriction on on loop depth. (record_equivalences_from_phis): Instead add it here. * gcc.dg/tree-ssa/ssa-dom-thread-5.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-5.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-copy.c trunk/gcc/tree-ssa-dom.c
[Bug target/61616] Internal compiler error during reload in gcc-4.7.4 configured as a cross-compiler for a mips target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61616 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.8.1 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Fixed in 4.8.1 then.
[Bug c++/61614] [4.9/4.10 Regression] Bogus error: taking address of temporary array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61614 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Version|unknown |4.9.0 Target Milestone|--- |4.9.1
[Bug preprocessor/61613] ,##__VA_ARGS__ fails to expand the first variadic argument if it is a macro-name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61613 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-06-26 Ever confirmed|0 |1 Known to fail||3.2.3, 4.3.4, 4.9.0 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed with 4.9.0. 2.95 prints t.c:3: badly punctuated parameter list in `#define'
[Bug libstdc++/61617] add boost::coroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61617 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-06-26 CC||manu at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to piotr5 from comment #0) incomprehensible otherwise. but the main reason I'd like to see it as part of gcc is so that programmers responsible for optimizations could start If you want to see something done in GCC, the best way is to roll up your sleeves and get busy: https://gcc.gnu.org/contribute.html You can work on a branch until your code is good enough to be accepted.
[Bug target/61610] [4.10 Regression] ICE in assign_by_spills, at lra-assigns.c:1335
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61610 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.10.0 Summary|ICE in assign_by_spills, at |[4.10 Regression] ICE in |lra-assigns.c:1335 |assign_by_spills, at ||lra-assigns.c:1335
[Bug c++/58972] Lambda can't access private members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58972 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- Seems to be fixed on trunk, probably by Ville's fix for protected members.
[Bug debug/56974] c++ ref qualifiers not represented in DWARF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56974 --- Comment #3 from Mark Wielaard mark at gcc dot gnu.org --- There is DWARFv5 proposal for this now: http://dwarfstd.org/ShowIssue.php?issue=131105.1 This adds DW_AT_reference[_qualifier] and DW_AT_rvalue_reference[_qualifier] as attributes to DW_TAG_subprogram or DW_TAG_subroutine_type.
[Bug c++/58972] Lambda can't access private members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58972 --- Comment #6 from Ville Voutilainen ville.voutilainen at gmail dot com --- (In reply to Jonathan Wakely from comment #5) Seems to be fixed on trunk, probably by Ville's fix for protected members. Yes, that fix is for 59483, I didn't wish to have these as duplicates because while the original problem of this bug report is fixed by the same patch, we need to look at the ICE separately, since it's unrelated. If someone wants, we could rip that out to a separate bug and close this one as RESOLVED.
[Bug tree-optimization/61607] DOM missed jump threading and destroyed loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61607
--- Comment #6 from Richard Biener rguenth at gcc dot gnu.org ---
The bogus loop cancelling is fixed as well as the equivalence recording. Still
DOM does
Registering jump thread: (3, 4) incoming edge; (4, 5) joiner; (5, 6)
normal;
Registering jump thread: (5, 7) incoming edge; (7, 9) normal;
Registering jump thread: (2, 4) incoming edge; (4, 5) joiner; (5, 7)
normal;
Cancelling jump thread: (2, 4) incoming edge; (4, 5) joiner; (5, 7) normal;
Threaded jump 5 -- 7 to 10
with result
bb 5:
# inter_I_lsm.3_24 = PHI inter_I_lsm.3_10(4)
# inter_I_lsm.4_25 = PHI inter_I_lsm.4_11(4)
# inter_I_lsm.5_26 = PHI inter_I_lsm.5_12(4)
# inter_I_lsm.6_27 = PHI inter_I_lsm.4_11(4)
if (inter_I_lsm.4_25 != 0)
goto bb 6;
else
goto bb 10;
bb 6:
inter[0] = inter_I_lsm.3_24;
bb 7:
if (inter_I_lsm.4_25 != 0)
goto bb 8;
else
goto bb 9;
bb 8:
inter[1] = inter_I_lsm.5_26;
bb 9:
foo (inter);
inter ={v} {CLOBBER};
return;
bb 10:
goto bb 9;
but no attempt at threading of
(5, 6) incoming edge - (6-7) joiner - (7 - 8) normal
VRP simplfies the conditional to true afterwards - so maybe this is just
a missed simplification-after-threading in DOM? Without VRP the
redundant conditional stays. It still looks like a trivial missing thing to
adjust the jump we thread through ...?
[Bug c++/58972] Lambda can't access private members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58972 --- Comment #7 from Daniel Krügler daniel.kruegler at googlemail dot com --- (In reply to Ville Voutilainen from comment #6) Makes sense to me, I'll do that for the local-class example
[Bug fortran/60898] model compile error with gfortran 4.7 and gcc 4.9 on Mac OS 10.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60898 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #5 from Paul Thomas pault at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #4) After providing all the missing 'USE' items: Where did you get them? Dear Jerry, Dominique's question is sort of... well, necessary since there are no namelist declarations in the source provided. Could you either reduce the source to a testcase or post the missing bits, please? I presume that, since the problem is with a declaration, the enclosing program unit by itself will be enough to generate the ICE. Cheers Paul
[Bug target/61618] [4.10 Regression]: ICE in expand_vec_perm_pblendv, at config/i386/i386.c with -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61618 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Target||x86 Target Milestone|--- |4.10.0
[Bug target/61618] New: [4.10 Regression]: ICE in expand_vec_perm_pblendv, at config/i386/i386.c with -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61618 Bug ID: 61618 Summary: [4.10 Regression]: ICE in expand_vec_perm_pblendv, at config/i386/i386.c with -mavx Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ubizjak at gmail dot com gcc.dg/torture/vshuf-v8sf.c currently fails with -O2 -mavx: gcc.dg/torture/vshuf-main.inc: In function ‘test_9’: gcc.dg/torture/vshuf-main.inc:15:5: internal compiler error: in expand_vec_perm_pblendv, at config/i386/i386.c:43257 d = __builtin_shuffle (a, b, mask); \ ^ gcc.dg/torture/vshuf-8.inc:12:1: note: in expansion of macro ‘T’ T (9, 13, 11, 10, 15, 8, 5, 14, 8) \ ^ gcc.dg/torture/vshuf-main.inc:28:1: note: in expansion of macro ‘TESTS’ TESTS ^ 0xc6bd88 expand_vec_perm_pblendv /home/uros/gcc-svn/trunk/gcc/config/i386/i386.c:43257 0xc6bd88 ix86_expand_vec_perm_const_1 /home/uros/gcc-svn/trunk/gcc/config/i386/i386.c:44647 0xca4373 ix86_expand_vec_perm_const(rtx_def**) /home/uros/gcc-svn/trunk/gcc/config/i386/i386.c:44768 0xd67b25 gen_vec_perm_constv8sf(rtx_def*, rtx_def*, rtx_def*, rtx_def*) /home/uros/gcc-svn/trunk/gcc/config/i386/sse.md:8985 0x9003f8 maybe_expand_insn(insn_code, unsigned int, expand_operand*) /home/uros/gcc-svn/trunk/gcc/optabs.c:8352 0x907537 expand_vec_perm_1 /home/uros/gcc-svn/trunk/gcc/optabs.c:6626 0x9077da expand_vec_perm(machine_mode, rtx_def*, rtx_def*, rtx_def*, rtx_def*) /home/uros/gcc-svn/trunk/gcc/optabs.c:6667 (gdb) up #2 0x00c6bd89 in expand_vec_perm_pblendv (d=0x7fffd410) at /home/uros/gcc-svn/trunk/gcc/config/i386/i386.c:43257 43257 gcc_assert (ok); (gdb) list 43252 43253 for (i = 0; i nelt; ++i) 43254 dcopy.perm[i] = d-perm[i] (nelt - 1); 43255 43256 ok = expand_vec_perm_1 (dcopy); 43257 gcc_assert (ok); 43258 43259 /* Next we put permuted elements into their positions. */ 43260 dcopy1 = *d; 43261 if (which == 2) (gdb)
[Bug fortran/60898] model compile error with gfortran 4.7 and gcc 4.9 on Mac OS 10.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60898 --- Comment #6 from Paul Thomas pault at gcc dot gnu.org --- (In reply to Paul Thomas from comment #5) (In reply to Dominique d'Humieres from comment #4) After providing all the missing 'USE' items: Where did you get them? Dear Jerry, Dominique's question is sort of... well, necessary since there are no namelist declarations in the source provided. Could you either reduce the source to a testcase or post the missing bits, please? I presume that, since the problem is with a declaration, the enclosing program unit by itself will be enough to generate the ICE. Cheers Paul Dh! From the comgsi website, of course! Cheers Paul
[Bug fortran/61420] [4.8/4.9/4.10 Regression] type bound procedure with pass attribute, that returns a procedure pointer, fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61420 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4
[Bug middle-end/61409] [4.9/4.10 regression] -Wmaybe-uninitialized false-positive with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61409 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug target/61618] [4.10 Regression]: ICE in expand_vec_perm_pblendv, at config/i386/i386.c with -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61618
--- Comment #1 from Uroš Bizjak ubizjak at gmail dot com ---
Testcase (compile with -O2 -mavx):
--cut here--
typedef float V __attribute__ ((vector_size (32)));
typedef unsigned int VI __attribute__ ((vector_size (32)));
extern V a, b, c, d;
void test_9 (void)
{
VI mask = { 13, 11, 10, 15, 8, 5, 14, 8 };
d = __builtin_shuffle (a, b, mask);
}
--cut here--
[Bug c++/61433] [4.9/4.10 Regression] ICE: SIGSEGV in friend_accessible_p (search.c:778) with -std=gnu++11 -O -fcompare-debug -fno-inline -fno-ipa-pure-const -fipa-sra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61433 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Hmm, -compare-debug not working is bad. Martin, can you have a look?
[Bug fortran/61459] [4.8/4.9/4.10 Regression] segfault when assigning to allocatable function result from matmul result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61459 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4
[Bug c++/61488] [4.9 regression] Regression in template argument substitution in 4.9+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61488 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Known to work||4.10.0, 4.8.3 Version|unknown |4.9.0 Summary|[4.9/4.10 regression] |[4.9 regression] Regression |Regression in template |in template argument |argument substitution in|substitution in 4.9+ |4.9+| --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Fixed on trunk sofar.
[Bug libfortran/61499] [4.9/4.10 Regression] Internal read of negative integer broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61499 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4
[Bug c++/61500] [4.8/4.9 Regression][C++11] Can't take pointer to member referenced via member pointer template parameter.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61500 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Priority|P3 |P2 Known to work||4.10.0
[Bug tree-optimization/61515] [4.9/4.10 Regression] Extremely long compile time for generated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61515 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug c++/61539] [4.8/4.9/4.10 Regression] ICE: in unify_one_argument, at cp/pt.c:15465
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61539 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P2
[Bug target/61542] [4.8/4.9/trunk] vect-nop-move.c fails on powerpc64le-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61542 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.8.4 |---
[Bug lto/61557] [4.9/4.10 Regression] LTO ICE: verify_flow_info failed (error: control flow in the middle of basic block)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61557 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug c++/61566] [4.9/4.10 Regression] ICE in write_unscoped_name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61566 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P2
[Bug c++/61614] [4.9/4.10 Regression] Bogus error: taking address of temporary array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61614 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug c++/61575] [4.9 Regression] Bogus invalid initialization of reference of type 'const D' from expression of type 'brace-enclosed initializer list'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61575 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug fortran/60718] [4.8/4.9/4.10 regression] Test case gfortran.dg/select_type_4.f90 fails on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60718 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4
[Bug target/60851] [4.9/4.10 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2117 with -flive-range-shrinkage -mdispatch-scheduler -march=bdver4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60851 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug ipa/60854] [4.9 Regression] inline constructor of extern template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60854 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug ipa/60871] [4.9/4.10 Regression] internal compiler error: in possible_polymorphic_call_targets, at ipa-devirt.c:1510
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60871 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug debug/60929] [4.8/4.9 regression] ICE in get_ref_die_offset, at dwarf2out.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60929 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug ipa/60990] [4.9/4.10 Regression] ICE: in try_make_edge_direct_virtual_call, at ipa-prop.c:2796 with -O3 -fno-early-inlining -fno-ipa-cp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60990 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug driver/61106] [4.8/4.9/4.10 Regression] impliedness of -Wunused-parameter depends on -W option ordering
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61106 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug ipa/61144] [4.9/4.10 Regression] Invalid optimizations for extern vars with local weak definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug ipa/61160] [4.9/4.10 Regression] wrong code with -O3 (or ICE: verify_cgraph_node failed: edge points to wrong declaration)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61160 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug c++/39270] Explicit instantiation rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39270 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org
[Bug tree-optimization/61619] New: Benefits from -ftree-vectorize lost easily when changing unrelated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61619 Bug ID: 61619 Summary: Benefits from -ftree-vectorize lost easily when changing unrelated code Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: shmueller2 at gmail dot com Created attachment 33011 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33011action=edit Uncommenting (1), (2) or (3) significantly accelerates this code When compiling the attached code with: g++-4.9 -std=c++11 -O3 -Wall -Wextra -pedantic bug.cpp -o bug I found that minor changes in seemingly irrelevant aspects of the code had a strong effect on performance. When run with: time ./bug the code as attached gave the following best-of-10 timing on a 2011 Macbook Air: real 0m1.718s user 0m1.395s sys0m0.306s Minor changes by uncommenting any of the lines marked with (1), (2), (3) (replacing the line immediately above) yielded significantly better results: Uncomment line (1): real 0m1.343s user 0m1.029s sys0m0.312s Uncomment line (2): real 0m1.364s user 0m1.062s sys0m0.297s Uncomment line (3): real 0m1.332s user 0m1.016s sys0m0.315s The generated assembly code (-S) differs significantly in all cases. When using -fno-tree-vectorize the performance is similar to the first (slow) result for all variations. The bug I'm reporting is that the optimization benefits from -ftree-vectorize are apparently lost easily and non-transparently when changing seemingly unrelated parts of the code on a high level, which should not affect performance. I would have expected that none of the changes (1), (2) and (3) would have resulted in a difference in the generated assembly code, and it was very surprising to me that such details mattered so much.
[Bug ipa/61144] [4.9/4.10 Regression] Invalid optimizations for extern vars with local weak definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144 --- Comment #22 from Rich Felker bugdal at aerifal dot cx --- Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Can we please make this P1 rather than P2? It is a wrong-code regression and only present in a single release, so by the bug management guidelines (https://gcc.gnu.org/bugs/management.html) I think it should be P1. There is already a working patch, test-case, and discussion on the gcc-patches list so I don't see what's blocking fixing it before the next release.
[Bug target/61618] [4.10 Regression]: ICE in expand_vec_perm_pblendv, at config/i386/i386.c with -mavx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61618 Stupachenko Evgeny evstupac at gmail dot com changed: What|Removed |Added CC||evstupac at gmail dot com --- Comment #2 from Stupachenko Evgeny evstupac at gmail dot com --- Confirm. Caused by my changes: commit 5c0d660cf1fc22a4366730c60707b4d34483ab24 Author: kyukhin kyukhin@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Tue Jun 10 12:40:16 2014 + gcc/ * config/i386/i386.c (expand_vec_perm_pblendv): New. * config/i386/i386.c (ix86_expand_vec_perm_const_1): Use expand_vec_perm_pblendv. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@211407 138bc75d-0d04-0410-961f-82ee72b054a4 For 32 bytes AVX there are 1 operand permutations requiring more than 1 instruction. So we should restrict the case here. I'll make a patch for this.
[Bug tree-optimization/61619] Benefits from -ftree-vectorize lost easily when changing unrelated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61619
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-06-26
Ever confirmed|0 |1
--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
bug.cpp:69:13: note: not vectorized: number of iterations cannot be computed.
bug.cpp:69:13: note: bad loop form.
The loop is
bb 20:
# sum_62 = PHI sum_42(19), [bug.cpp : 69:80] sum_33(21)
# p_71 = PHI p_59(19), [bug.cpp : 29:29] p_50(21)
[bug.cpp : 69:80] _32 = [bug.cpp : 69] *p_71;
[bug.cpp : 69:80] sum_33 = sum_62 + _32;
[bug.cpp : 29:31] p_50 = p_71 + pretmp_7;
[bug.cpp : 69:13] if (_48 != p_50)
goto bb 21;
else
goto bb 22;
bb 21:
goto bb 20;
The above is with -fopt-info-vec-missed and the excerpt is from the
bug.cpp.114t.vect file produced by -fdump-tree-vect-details-lineno
I believe the issue is that the initialization of S and E are not
inlined if none of the uncomments are done. If you expect all
abstraction to be removed by inlining the 'flatten' attribute can do magic.
Unfortunately the inits look like
[/usr/include/c++/4.9/bits/stl_algobase.h : 378:6] MEM[(char * {ref-all})S]
= MEM[(char * {ref-all})._94];
pretmp_22 = MEM[(struct array *)S];
which we don't fold to the constant init 1 for some reason.
[Bug tree-optimization/61619] Benefits from -ftree-vectorize lost easily when changing unrelated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61619
--- Comment #2 from Marc Glisse glisse at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
Unfortunately the inits look like
[/usr/include/c++/4.9/bits/stl_algobase.h : 378:6] MEM[(char *
{ref-all})S] = MEM[(char * {ref-all})._94];
pretmp_22 = MEM[(struct array *)S];
which we don't fold to the constant init 1 for some reason.
Sounds related to PR 59611 (I didn't look at this one closely, so maybe not).
[Bug tree-optimization/61619] Benefits from -ftree-vectorize lost easily when changing unrelated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61619
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC||jamborm at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org ---
._94/3491 (constexpr const long unsigned int ._94 [1]) @0x71d5ca90
Type: variable definition analyzed
Visibility: prevailing_def_ironly artificial
References:
Referring: main/3232 (read)
Availability: available
Varpool flags: initialized read-only const-value-known
Ok, for the above SRA fails to do a scalar replacement and value-numbering
doesn't even reach the aggregate copy from the constant initializer.
That's because only PRE exposes it and PRE doesn't do all the fancy VN
tricks.
I suppose I have to look closer at some point. Interesting testcase
showing possible issues with C++ constexpr initializers.
Note that we also have
MEM[(char * {ref-all})S] = MEM[(char * {ref-all})._94];
but this aggregate copy has sizeof (long) so we could have optimized it
(it's ref-all already) to use an integer type.
This is lowered from
arraylong unsigned int, 1ul::array (S, (const struct initializer_list )
TARGET_EXPR D.64552, {._M_array=(const long unsigned int *) ._94,
._M_len=1})
to
D.64552._M_array = ._94;
D.64552._M_len = 1;
try
{
arraylong unsigned int, 1ul::array (S, D.64552);
}
which eventually ends up calling memmove which we optimize to the aggregate
assignment.
[Bug tree-optimization/59611] std::copy performs worse than naive implementation when copying a single known byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59611 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Mine.
[Bug c++/60249] [c++11] Compiler goes into semi-infinite loop with wrong usage of user defined string literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60249 --- Comment #3 from Ed Smith-Rowland 3dw4rd at verizon dot net --- On 06/25/2014 01:45 PM, paolo.carlini at oracle dot com wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60249 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Ed? Paolo, I'm really struggling with this and some decltype ud literal bugs that I think are related. I'll give it a last look today. I may have to get some help. I'll be more exact about where I am stuck tonight. I'm having trouble getting time to work on these. Ed
[Bug go/61620] New: FAIL: go.test/test/fixedbugs/bug242.go execution, -O2 -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61620
Bug ID: 61620
Summary: FAIL: go.test/test/fixedbugs/bug242.go execution, -O2
-g
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: ubizjak at gmail dot com
CC: cmang at google dot com
Execute of go.test/test/fixedbugs/bug242.go fails on i686-linux-gnu with fatal
error: freeing too small block.
[uros@localhost test]$ LD_LIBRARY_PATH=. gdb ./bug242.x
GNU gdb (GDB) Fedora 7.7.1-13.fc20
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as x86_64-redhat-linux-gnu.
Type show configuration for configuration details.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
Find the GDB manual and other documentation resources online at:
http://www.gnu.org/software/gdb/documentation/.
For help, type help.
Type apropos word to search for commands related to word...
Reading symbols from ./bug242.x...done.
(gdb) r
Starting program: /home/uros/test/bug242.x
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib64/libthread_db.so.1.
[New Thread 0xf756acc0 (LWP 5016)]
fatal error: freeing too small block
goroutine 16 [running]:
runtime_dopanic
/home/uros/gcc-svn/trunk/libgo/runtime/panic.c:129
runtime_throw
/home/uros/gcc-svn/trunk/libgo/runtime/panic.c:167
__go_free
/home/uros/gcc-svn/trunk/libgo/runtime/malloc.goc:366
__go_map_delete
/home/uros/gcc-svn/trunk/libgo/runtime/go-map-delete.c:50
runtime.mapdelete
/home/uros/gcc-svn/trunk/libgo/runtime/map.goc:47
main.main
/home/uros/gcc-svn/trunk/gcc/testsuite/go.test/test/fixedbugs/bug242.go:96
runtime_main
/home/uros/gcc-svn/trunk/libgo/runtime/proc.c:571
panic during panic
goroutine 16 [running]:
runtime_dopanic
/home/uros/gcc-svn/trunk/libgo/runtime/panic.c:129
runtime_startpanic
/home/uros/gcc-svn/trunk/libgo/runtime/panic.c:98
runtime_throw
/home/uros/gcc-svn/trunk/libgo/runtime/panic.c:165
runtime_mallocgc
/home/uros/gcc-svn/trunk/libgo/runtime/malloc.goc:115
__go_alloc
/home/uros/gcc-svn/trunk/libgo/runtime/malloc.goc:333
callback
/home/uros/gcc-svn/trunk/libgo/runtime/go-caller.c:47
dwarf_lookup_pc
/home/uros/gcc-svn/trunk/libbacktrace/dwarf.c:2838
dwarf_fileline
/home/uros/gcc-svn/trunk/libbacktrace/dwarf.c:2877
backtrace_pcinfo
/home/uros/gcc-svn/trunk/libbacktrace/fileline.c:176
__go_file_line
/home/uros/gcc-svn/trunk/libgo/runtime/go-caller.c:125
runtime_printcreatedby
/home/uros/gcc-svn/trunk/libgo/runtime/proc.c:636
runtime_dopanic
/home/uros/gcc-svn/trunk/libgo/runtime/panic.c:130
runtime_throw
/home/uros/gcc-svn/trunk/libgo/runtime/panic.c:167
__go_free
/home/uros/gcc-svn/trunk/libgo/runtime/malloc.goc:366
__go_map_delete
/home/uros/gcc-svn/trunk/libgo/runtime/go-map-delete.c:50
runtime.mapdelete
/home/uros/gcc-svn/trunk/libgo/runtime/map.goc:47
main.main
/home/uros/gcc-svn/trunk/gcc/testsuite/go.test/test/fixedbugs/bug242.go:96
runtime_main
/home/uros/gcc-svn/trunk/libgo/runtime/proc.c:571
stack trace unavailable
[Thread 0xf756acc0 (LWP 5016) exited]
[Inferior 1 (process 5012) exited with code 04]
Breakpoint in runtime_dopanic:
Breakpoint 1, runtime_dopanic (unused=0) at
/home/uros/gcc-svn/trunk/libgo/runtime/panic.c:114
114 {
(gdb) bt
#0 runtime_dopanic (unused=0) at
/home/uros/gcc-svn/trunk/libgo/runtime/panic.c:114
#1 0xf7978ddf in runtime_throw (s=0xf7c90526 freeing too small block) at
/home/uros/gcc-svn/trunk/libgo/runtime/panic.c:167
#2 0xf7981f7d in __go_free (v=0x18204018) at
/home/uros/gcc-svn/trunk/libgo/runtime/malloc.goc:366
#3 0xf796a8a4 in __go_map_delete (map=0x1820, key=0xf6f1cf39) at
/home/uros/gcc-svn/trunk/libgo/runtime/go-map-delete.c:50
#4 0xf7982d35 in runtime.mapdelete (h=0x1820, key=0xf6f1cf39 \r) at
/home/uros/gcc-svn/trunk/libgo/runtime/map.goc:47
#5 0x08049eb6 in main.main () at
/home/uros/gcc-svn/trunk/gcc/testsuite/go.test/test/fixedbugs/bug242.go:96
(gdb) f 2
#2 0xf7981f7d in __go_free (v=0x18204018) at
/home/uros/gcc-svn/trunk/libgo/runtime/malloc.goc:366
366 runtime_throw(freeing too small block);
(gdb) list
361 size = s-elemsize;
362 sizeclass = s-sizeclass;
363 // Objects that are smaller than TinySize can be allocated
using tiny alloc,
364 // if then such object is combined with an object with
finalizer, we will crash.
365
[Bug c++/55136] template class member template explicit instantiation fails if non template overload exists
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55136 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Closely related to PR39270.
[Bug c++/61621] New: Normal enum switch slower than test case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61621
Bug ID: 61621
Summary: Normal enum switch slower than test case.
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: holger.seelig at yahoo dot de
I detected that a normal enum switch is 1.5 up to 3 times slower than a
'double' enum switch. Below I created a test case for you. Unkomment the marked
lines to get better performace results.
### Compiler options
/usr/bin/g++ -O3 -Wall -std=c++11 test-case.cpp
### test-case.cpp
#include iostream
#include vector
#include chrono
enum InstructionType
{
UNDEFINED,
INT32,
UINT32,
NUMBER,
STRING,
NULL_OBJECT,
OBJECT,
BOOLEAN_OBJECT,
NUMBER_OBJECT,
STRING_OBJECT,
ARRAY_OBJECT,
DATE_OBJECT,
REGEX_OBJECT,
FUNCTION_OBJECT,
ADDRESS,
NOP,
RESULT,
JUMP_IF_ZERO,
MULTIPLICATION_EXPRESSION,
DIVISION_EXPRESSION,
REMAINDER_EXPRESSION,
ADDITION_EXPRESSION,
SUBTRACTION_EXPRESSION,
LESS_EXPRESSION,
RETURN_STATEMENT,
};
int
run (const std::vector InstructionType instructions)
{
int value = 0;
for (size_t i = 0, size = instructions .size (); i size; ++ i)
{
switch (instructions [i])
{
case UNDEFINED:
case INT32:
case UINT32:
case NUMBER:
case STRING:
case NULL_OBJECT:
case OBJECT:
case BOOLEAN_OBJECT:
case NUMBER_OBJECT:
case STRING_OBJECT:
case ARRAY_OBJECT:
case DATE_OBJECT:
case REGEX_OBJECT:
case FUNCTION_OBJECT:
case ADDRESS:
value += 1;
break;
// UNCOMMENT THE FOLLOWING LINES TO GET BETTER PERFORMANCE
// default:
// {
//switch (instructions [i])
//{
case NOP:
break;
case RESULT:
value += 2;
break;
case JUMP_IF_ZERO:
value ++;
break;
case MULTIPLICATION_EXPRESSION:
value += 3;
break;
case DIVISION_EXPRESSION:
value += 4;
break;
case REMAINDER_EXPRESSION:
value += 5;
break;
case ADDITION_EXPRESSION:
value += 6;
break;
case SUBTRACTION_EXPRESSION:
value += 7;
break;
case LESS_EXPRESSION:
value += 8;
break;
case RETURN_STATEMENT:
value += 9;
break;
// UNCOMMENT THE FOLLOWING LINES TO GET BETTER PERFORMANCE
// default:
// break;
//}
// }
}
}
return value;
}
inline
double
now ()
{
using namespace std::chrono;
return duration_cast duration double (high_resolution_clock::now ()
.time_since_epoch ()) .count ();
}
int
main (int argc, char **argv)
{
std::cout Enum switch performance test! std::endl;
std::vector InstructionType instructions = {
UNDEFINED,
INT32,
UINT32,
NUMBER,
STRING,
NULL_OBJECT,
OBJECT,
BOOLEAN_OBJECT,
NUMBER_OBJECT,
STRING_OBJECT,
ARRAY_OBJECT,
DATE_OBJECT,
REGEX_OBJECT,
FUNCTION_OBJECT,
ADDRESS,
NOP,
RESULT,
JUMP_IF_ZERO,
MULTIPLICATION_EXPRESSION,
DIVISION_EXPRESSION,
REMAINDER_EXPRESSION,
ADDITION_EXPRESSION,
SUBTRACTION_EXPRESSION,
LESS_EXPRESSION,
RETURN_STATEMENT,
};
int value = 0;
auto t0= now ();
for (int i = 0; i 1; ++ i)
value += run (instructions);
std::cout value: value std::endl;
std::cout time:now () - t0 s std::endl;
return 0;
}
holger@qualle:~$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.2-19ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home
[Bug target/61503] RTL representation of i386 shrdl instruction is incorrect?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61503 --- Comment #2 from Marc Glisse glisse at gcc dot gnu.org --- Author: glisse Date: Thu Jun 26 15:27:52 2014 New Revision: 212036 URL: https://gcc.gnu.org/viewcvs?rev=212036root=gccview=rev Log: 2014-06-26 Marc Glisse marc.gli...@inria.fr PR target/61503 * config/i386/i386.md (x86_64_shrd, x86_shrd, ix86_rotrdwi3_doubleword): Replace ashiftrt with lshiftrt. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/i386/i386.md
[Bug c++/56633] Overload selection error for non-static data member initialization with initializer list in template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56633 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- This is fixed in mainline, I'm adding the testcase and closing the bug.
[Bug target/61503] RTL representation of i386 shrdl instruction is incorrect?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61503 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.1 --- Comment #3 from Marc Glisse glisse at gcc dot gnu.org --- Fixed on trunk and 4.9, not backporting to 4.8 since it isn't causing any issue.
[Bug c++/56633] Overload selection error for non-static data member initialization with initializer list in template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56633 --- Comment #3 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Thu Jun 26 15:34:59 2014 New Revision: 212037 URL: https://gcc.gnu.org/viewcvs?rev=212037root=gccview=rev Log: 2014-06-26 Paolo Carlini paolo.carl...@oracle.com PR c++/56633 * g++.dg/cpp0x/deleted8.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/deleted8.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/56633] Overload selection error for non-static data member initialization with initializer list in template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56633 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.10.0 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Done.
[Bug c/6940] taking sizeof array parameter should trigger a warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6940 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |4.10.0 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- On it.
[Bug target/61298] redundant compare instructions for powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61298 --- Comment #3 from Peter Bergner bergner at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #1) I think I have seen this bug before. The problem comes from using non-logical compares for equal but logical compares for the others. Maybe you were thinking of PR16458 ? That bugzilla did try and solve the problem that the old code always wanted to use signed compares for equal/not equal. The old code in rs6000.c did have the test for the subreg and SUBREG_PROMOTED_UNSIGNED_P. I moved that to the new unsigned_reg_p() that richi requested and added the test for REG_P and TYPE_UNSIGNED (added revision 186312). I can say that unsigned_reg_p() probably doesn't catch every case where we're doing an unsigned compare and force it to use non signed compare. Since you have a subreg, have you looked at how SUBREG_PROMOTED_UNSIGNED_P is set? Is that supposed to be set for your case?
[Bug c++/61433] [4.9/4.10 Regression] ICE: SIGSEGV in friend_accessible_p (search.c:778) with -std=gnu++11 -O -fcompare-debug -fno-inline -fno-ipa-pure-const -fipa-sra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61433
Martin Jambor jamborm at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #3 from Martin Jambor jamborm at gcc dot gnu.org ---
(In reply to Richard Biener from comment #2)
Hmm, -compare-debug not working is bad. Martin, can you have a look?
Well, the C++ front-end crashes when DECL_LANG_SPECIFIC is cleared on
clones. We started doing this in Jakub's revision r207465 which fixed
PR 60002. So if this is OK (and since Jason approved of it in that
PR, I assume it is), the front-end needs to be aware of this. I do
not know it well enough to propose anything more clever than the
following (so far untested) patch. However, DECL_LANG_SPECIFIC is
accessed by many macros in cp-tree.h so issues like these are likely
to continue popping up.
diff --git a/gcc/cp/search.c b/gcc/cp/search.c
index 424b26c..cc77d8f 100644
--- a/gcc/cp/search.c
+++ b/gcc/cp/search.c
@@ -775,7 +775,13 @@ friend_accessible_p (tree scope, tree decl, tree binfo)
return 0;
if (DECL_DECLARES_FUNCTION_P (scope))
-befriending_classes = DECL_BEFRIENDING_CLASSES (scope);
+{
+ if (DECL_ABSTRACT_ORIGIN (scope))
+ befriending_classes = DECL_BEFRIENDING_CLASSES
+ (DECL_ABSTRACT_ORIGIN (scope));
+ else
+ befriending_classes = DECL_BEFRIENDING_CLASSES (scope);
+}
else if (TYPE_P (scope))
befriending_classes = CLASSTYPE_BEFRIENDING_CLASSES (scope);
else
@@ -800,6 +806,9 @@ friend_accessible_p (tree scope, tree decl, tree binfo)
friend_accessible_p (DECL_CONTEXT (scope), decl, binfo))
return 1;
+ if (DECL_ABSTRACT_ORIGIN (scope))
+ scope = DECL_ABSTRACT_ORIGIN (scope);
+
/* Or an instantiation of something which is a friend. */
if (DECL_TEMPLATE_INFO (scope))
{
[Bug c++/61581] [C++11] Bogus error: uninitialized const member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61581 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Dup. *** This bug has been marked as a duplicate of bug 49132 ***
[Bug c++/49132] [DR 178] Aggregate-initialization rejected for class with const data member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49132 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||ppluzhnikov at google dot com --- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com --- *** Bug 61581 has been marked as a duplicate of this bug. ***
[Bug c++/61596] -Wunused-local-typedefs warns incorrectly on a typedef that's referenced indirectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61596 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-06-26 Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Dodji, can you have a look?
[Bug c++/61451] Parsing aborted at cp/parser.c:23778
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61451 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.10.0, 4.9.0 Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- This is fixed for 4.9.0.
[Bug c++/61362] g++ (Ubuntu 4.8.2-19ubuntu1) 4.8.2 does not compile lambda with template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61362 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-06-26 Blocks||54367 Ever confirmed|0 |1 Severity|major |normal
[Bug target/61360] [4.10 Regression] ICE: in lra_update_insn_recog_data, at lra.c:1363 with -mtune=bdver4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61360 --- Comment #5 from Zdenek Sojka zsojka at seznam dot cz --- If anyone is interested in what architecutres are affected without looking at the source code, there are rough statistics of ICEs encountered since it first appeared: ICEs count | switch 21 -march=bdver3 160 -mtune=amdfam10 134 -mtune=barcelona 153 -mtune=bdver1 129 -mtune=bdver2 176 -mtune=bdver3 145 -mtune=bdver4 The reason for so low -march= count is that I am no longer using the -march= switch. Other architectures are likely not affected.
[Bug c++/61484] [C++11] can't initialize constexpr multi-dimentional array of a literal type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61484 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-06-26 Blocks||55004 Summary|[C++11] [constexpr] can't |[C++11] can't initialize |initialize constexpr|constexpr multi-dimentional |multi-dimentional array of |array of a literal type |a literal type | Ever confirmed|0 |1
[Bug c++/59480] Missing error diagnostic: friend declaration specifying a default argument must be a definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59480 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||filip.roseen at gmail dot com --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- *** Bug 61470 has been marked as a duplicate of this bug. ***
[Bug c++/61470] ill-formed friend declaration(s) with default-arguments not caught
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61470 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Dup. *** This bug has been marked as a duplicate of bug 59480 ***
