[Bug tree-optimization/65458] parloops transforms omp-thread functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65458 vries at gcc dot gnu.org changed: What|Removed |Added Attachment #35051|0 |1 is obsolete|| --- Comment #3 from vries at gcc dot gnu.org --- Created attachment 35061 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35061action=edit updated tentative patch Updated patch that uses new cgraph_node field parallelized_function, following up on comments from Jakub at https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00967.html . Currently Testing.
[Bug target/65464] [4.8/4.9 Regression] disabling multilib support for powerpc64le-linux-gnu breaks kernel builds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65464 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #4 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Well, on x86_64 if you build gcc with --disable-multilib you still can compile with -m32 (even without a 32-bit user runtime). Why should this be different on ppc64le?
[Bug c/65455] typeof _Atomic fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455 --- Comment #11 from Jens Gustedt jens.gustedt at inria dot fr --- (In reply to jos...@codesourcery.com from comment #10) On Wed, 18 Mar 2015, jens.gustedt at inria dot fr wrote: (Perhaps gcc interprets _Generic as you say, but even the standard committee doesn't agree on that interpretation, and other compiler implementors don't agree either. Nothing in the standard says that it is an rvalue, nor that it has to undergo any conversion. Conversion for non-evaluated expressions simply doesn't exist in the standard. The standard explicitly asks for compatible type of the expression itself, it says nothing about unqualified type.) There isn't yet a conclusion to DR#423, but the committee discussion in N1892 says 'Specifically, the controlling expression of a generic selection was very carefully not added to the list of cases where lvalue conversion is not done.' (i.e. that conversion happens to all expressions unless excluded from happening). There is no indication of a committee direction contradicting the approach I chose for GCC (even if the committee isn't quite sure of how to handle atomics there, and has suggested making qualifiers on function return types not part of the type). And now we are exactly in the situation that I was afraid of happening, compiler implementors interpret _Generic differently. Your interpretation and the one that clang applies differ and make it that code with _Generic isn't portable. That is just a disaster for an early (well not so early anymore) adoption of C11.
[Bug rtl-optimization/60851] [4.9/5 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 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |ASSIGNED CC|uros at gcc dot gnu.org|law at gcc dot gnu.org Component|target |rtl-optimization Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com --- Comment #10 from Uroš Bizjak ubizjak at gmail dot com --- Patch at [1]. [1] https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00975.html
[Bug target/65240] [5 Regression] ICE (insn does not satisfy its constraints) on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65240 --- Comment #15 from Michael Meissner meissner at gcc dot gnu.org --- Author: meissner Date: Thu Mar 19 22:37:33 2015 New Revision: 221524 URL: https://gcc.gnu.org/viewcvs?rev=221524root=gccview=rev Log: [gcc] 2015-03-19 Michael Meissner meiss...@linux.vnet.ibm.com PR target/65240 * config/rs6000/predicates.md (easy_fp_constant): Remove special -ffast-math handling that kept non-0 constants live in the RTL until reload. Remove logic testing the number of instructions it took to create a constant in a GPR that was never used, due to a test for soft-float earlier. (memory_fp_constant): Delete, no longer used. * config/rs6000/rs6000.md (movMODE_hardfloat): Remove alternatives for loading non-0 constants into GPRs for hard floating point that is no longer needed due to changes in easy_fp_constant. Add support for loading 0.0 into GPRs. (movmode_hardfloat32): Likewise. (movmode_hardfloat64): Likewise. (movmode_64bit_dm): Likewise. (movtd_64bit_nodm): Likewise. (pre-reload move FP constant define_split): Delete define_split, since it is no longer used. (extenddftf2_internal): Remove GHF constraints that are not valid for extenddftf2. [gcc/testsuite] 2015-03-19 Michael Meissner meiss...@linux.vnet.ibm.com PR target/65240 * gcc/testsuite/g++.dg/pr65240.h: Add tests for PR 65240. * gcc/testsuite/g++.dg/pr65240-1.C: Likewise. * gcc/testsuite/g++.dg/pr65240-2.C: Likewise. * gcc/testsuite/g++.dg/pr65240-3.C: Likewise. * gcc/testsuite/g++.dg/pr65240-4.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/pr65240-1.C trunk/gcc/testsuite/g++.dg/pr65240-2.C trunk/gcc/testsuite/g++.dg/pr65240-3.C trunk/gcc/testsuite/g++.dg/pr65240-4.C trunk/gcc/testsuite/g++.dg/pr65240.h Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/predicates.md trunk/gcc/config/rs6000/rs6000.md trunk/gcc/testsuite/ChangeLog
[Bug target/62109] __gthr_i486_lock_cmp_xchg missing clobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109 --- Comment #8 from David gccbugzilla at limegreensocks dot com --- (In reply to Kai Tietz from comment #7) The first code block in comment #6 is what is in the code now. As you can see, it already has the #define you are describing. I don't understand what you mean by change it to this, since it is already there. Are you suggesting we delete the entire #ifdef __GTHREAD_I486_INLINE_LOCK_PRIMITIVES block and replace it with the single #define? I would be ok with that. Using the #error (the second code block in comment #6) seemed like a more backward-compatible way to do this, since it would tell people what has happened and what to do to fix it rather than (silently) assuming we know what they want to do. But I am ok with either of these two solutions.
[Bug sanitizer/65479] New: sanitizer stack trace missing frames past #0 on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65479 Bug ID: 65479 Summary: sanitizer stack trace missing frames past #0 on powerpc64 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org On both powerpc64 and powerpc64le, the c-c++-common/asan/misalign-1.c shows 6 failures, all in the output pattern test. The failures are due to to the stack trace missing stack frame #1 (it only includes frame #0). It looks like the backtrace on powerpc doesn't work correctly. = ==87868==ERROR: AddressSanitizer: unknown-crash on address 0x3fffc231eb2f at pc 0x1ce8 bp 0x3fffc231e9f0 sp 0x3fffc231ea10 READ of size 4 at 0x3fffc231eb2f thread T0 #0 0x1ce4 in foo /src/gcc-5.0-git/gcc/testsuite/c-c++-common/asan/misalign-1.c:11 Address 0x3fffc231eb2f is located in stack of thread T0 at offset 175 in frame #0 0x186c in main /src/gcc-5.0-git/gcc/testsuite/c-c++-common/asan/misalign-1.c:28 This frame has 3 object(s): [32, 36) 'v' [96, 100) 'w' [160, 176) 't' == Memory access at offset 175 partially overflows this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: unknown-crash /src/gcc-5.0-git/gcc/testsuite/c-c++-common/asan/misalign-1.c:11 foo Shadow bytes around the buggy address: 0x09fff8463d10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x09fff8463d20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x09fff8463d30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x09fff8463d40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x09fff8463d50: f1 f1 f1 f1 04 f4 f4 f4 f2 f2 f2 f2 04 f4 f4 f4 =0x09fff8463d60: f2 f2 f2 f2 00[00]f4 f4 f3 f3 f3 f3 00 00 00 00 0x09fff8463d70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x09fff8463d80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x09fff8463d90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x09fff8463da0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x09fff8463db0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe ==87868==ABORTING
[Bug tree-optimization/65443] Don't peel last iteration from loop in transform_to_exit_first_loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65443 --- Comment #6 from vries at gcc dot gnu.org --- After looking into it a bit further, I think what we're trying to get is: ... bb x: goto bb y; bb 4: i_17 = (int) ivtmp_y; _7 = (long unsigned int) i_17; _8 = _7 * 4; _9 = pretmp_24 + _8; _10 = *_9; sum_11 = _10 + sum_y; i_12 = i_17 + 1; i.1_3 = (unsigned int) i_12; goto bb 6; bb 6: ivtmp_6 = ivtmp_y + 1; goto bb y; bb y: # sum_y = PHI 1(x), sum_11(6) # ivtmp_y = PHI 0(x), ivtmp_6(6) if (ivtmp_y _20 + 1) goto bb 4; else goto bb 5; bb 5: # sum_21 = PHI sum_y(y), sum_26(8) goto bb 7; ...
[Bug libgomp/65467] [libgomp] sorry, unimplemented: '_Atomic' with OpenMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65467 --- Comment #2 from joseph at codesourcery dot com joseph at codesourcery dot com --- The issue is that someone needs to go through all the parsing for OpenMP constructs, and figure out exactly where to add calls to convert_lvalue_to_rvalue (if an OpenMP construct reads the value of an object, reading the value of an _Atomic object must be an atomic load) and what other special handling might be needed (if an OpenMP construct writes to an object, it must be an atomic store; if it both reads and writes, some form of compare-and-exchange may be needed).
[Bug ipa/65478] [5 regression] crafty performance regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478
Jan Hubicka hubicka at gcc dot gnu.org changed:
What|Removed |Added
Component|tree-optimization |ipa
Summary|crafty performance |[5 regression] crafty
|regression |performance regression
--- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org ---
Martin: Looking into it, the parameter 4(ply)=2 and donull=true seems to be
used in calls starting the recursion:
/*
--
| |
| now call Search to produce a value for this move. |
| |
--
*/
begin_root_nodes=nodes_searched;
if (first_move) {
value=-ABSearch(-beta,-alpha,ChangeSide(wtm),
depth+extensions,2,DO_NULL);
if (abort_search) {
UnMakeMove(1,current_move[1],wtm);
return(alpha);
}
first_move=0;
}
else {
value=-ABSearch(-alpha-1,-alpha,ChangeSide(wtm),
depth+extensions,2,DO_NULL);
if (abort_search) {
UnMakeMove(1,current_move[1],wtm);
return(alpha);
}
if ((value alpha) (value beta)) {
value=-ABSearch(-beta,-alpha,ChangeSide(wtm),
depth+extensions,2,DO_NULL);
if (abort_search) {
UnMakeMove(1,current_move[1],wtm);
return(alpha);
}
}
}
While it recursively call itself with alternating players and sometimes drops
to !DO_NULL.
Intuitively, clonning the function specializing for first iteration of
recursion is like loop peeling and that is already done (not particularly well)
by recursive inlining.
I would suggest we may disable/add negative hint for cloning in the case where
the specialized function will end up calling unspecialized version of itself
with non-cold edge.
We also may consider adding bit of negative hints for cases where cloning would
turn function called once (by noncold edge) to a function called twice.
The same may be done with inliner, but that would even more reduce changes that
ipa-split produced split functions will actually get partially inlined.
Function is inlined by 4.9:
Considering NextMove/2405 with 284 size
to be inlined into Search.constprop/4352 in unknown:-1
Estimated badness is -128, frequency 0.69.
Badness calculation for Search.constprop/4352 - NextMove/2405
size growth 273, time 174 inline hints: cross_module array_index
-128: guessed profile. frequency 0.694000, benefit 1.771337%, time w/o
inlining 621, time w inlining 610 overall growth 266 (current) 266 (original)
Accounting size:228.00, time:104.18 on predicate:(op4 = 62)
Accounting size:4.00, time:4.13 on predicate:(op2 changed)
(op4 = 62)
Accounting size:2.00, time:1.03 on predicate:(op2 == 0) (op4
= 62)
Accounting size:2.00, time:1.03 on predicate:(op2 != 0) (op4
= 62)
I am marking it as a regression thus and
[Bug preprocessor/65481] _Pragma GCC dependency broken on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65481 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- contrib/gcc_update --touch is usually used to fix this problem.
[Bug target/65464] [4.8/4.9 Regression] disabling multilib support for powerpc64le-linux-gnu breaks kernel builds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65464 --- Comment #8 from Matthias Klose doko at gcc dot gnu.org --- Alan told me that you can work around it by configuring with --enable-targets=powerpcle-linux --disable-multilib to still have the -m32 option recognized.
[Bug c/65466] Unnecessary source line output for note: each undeclared identifier is reported only once
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65466 --- Comment #2 from joseph at codesourcery dot com joseph at codesourcery dot com --- On Thu, 19 Mar 2015, manu at gcc dot gnu.org wrote: (If I was re-doing that patch again, I will try to overload inform(), because inform_with_flags is just too much typing). Note that diagnostic functions cannot be overloaded in a way that means different functions with the same name have the msgid argument in different positions, as that breaks exgettext.
[Bug target/65474] sub-optimal code for __builtin_abs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65474 --- Comment #2 from wmi at google dot com --- Created attachment 35069 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35069action=edit microbench
[Bug libgcc/60939] AIX: exceptions not caught when calling function via pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60939
--- Comment #6 from Zoltan Hidvegi zoltan at hidvegi dot com ---
gcc collect2 links the programs twice, first it links just all the object and
archive files passed, then it parses the output and if necessary creates a
source file that contains information about static constructors and destructors
and some tables for exception unwinding, and compiles and relinks with that
additional object file. The problem is that the AIX linker by default does
garbage collection, and removes stuff that is unreachable. In the example b.cc
which contains main has no reference at all to anything in a.cc, so the garbage
collector thinks it can throw it away. If I use -bkeepfile:a.o for the first ld
call from collect2, then garbage collection is skipped for a.o, and this allows
the correct generation of frame_table and the example works. Unfortunately,
using -bnogc does not work, it leads to lots of undefined symbols. However
using -bexpfull for the first link does work (without keepfile), maybe that's a
proper fix? The only problem with that is that gcc does not call the second
link if it's not necessary, however keeping the executable created with
-bexpfull is not a good idea, so gcc would always have to relink.
Btw. a workaround is to refer to any symbol from a.cc from b.cc, e.g. adding a
dummy void bar() {} to a.cc and void junk() { bar(); } into b.cc would make the
example work.
[Bug target/65240] [5 Regression] ICE (insn does not satisfy its constraints) on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65240 Michael Meissner meissner at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #16 from Michael Meissner meissner at gcc dot gnu.org --- Problem is believed to be fixed in subversion id 221524.
[Bug libstdc++/65480] New: libstdc++-prettyprinters/libfundts.cc test failures on powepc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65480
Bug ID: 65480
Summary: libstdc++-prettyprinters/libfundts.cc test failures on
powepc64
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
The libstdc++-prettyprinters/libfundts.cc test fails the following assertions
on powerpc64 (all assertions pass on powerpc64le).
FAIL: libstdc++-prettyprinters/libfundts.cc print ab
got ={_M_manager = @0x10020668: 0x100029b0
std::experimental::fundamentals_v1::any::_Manager_internalbool::_S_manage(std::experimental::fundamentals_v1::any::_Op,
std::experimental::fundamentals_v1::any const*,
std::experimental::fundamentals_v1::any::_Arg*), _M_storage = {_M_ptr =
0x10029200, _M_buffer = {__data = \000\000\000\000\020\002\222, __align =
{No data fields=
expected =std::experimental::any containing bool = {[contained value] =
false}=
FAIL: libstdc++-prettyprinters/libfundts.cc print ai
got ={_M_manager = @0x10020698: 0x10002b0c
std::experimental::fundamentals_v1::any::_Manager_internalint::_S_manage(std::experimental::fundamentals_v1::any::_Op,
std::experimental::fundamentals_v1::any const*,
std::experimental::fundamentals_v1::any::_Arg*), _M_storage = {_M_ptr =
0x61578, _M_buffer = {__data = \000\000\000\006\020\000\005x, __align =
{No data fields=
expected =std::experimental::any containing int = {[contained value] = 6}=
FAIL: libstdc++-prettyprinters/libfundts.cc print ap
got ={_M_manager = @0x100206c8: 0x10002c68
std::experimental::fundamentals_v1::any::_Manager_internalvoid*::_S_manage(std::experimental::fundamentals_v1::any::_Op,
std::experimental::fundamentals_v1::any const*,
std::experimental::fundamentals_v1::any::_Arg*), _M_storage = {_M_ptr = 0x0,
_M_buffer = {__data = \000\000\000\000\000\000\000, __align = {No data
fields=
expected =std::experimental::any containing void * = {[contained value] =
0x0}=
FAIL: libstdc++-prettyprinters/libfundts.cc print as
got ={_M_manager = @0x10020710: 0x10002df4
std::experimental::fundamentals_v1::any::_Manager_internalstd::string::_S_manage(std::experimental::fundamentals_v1::any::_Op,
std::experimental::fundamentals_v1::any const*,
std::experimental::fundamentals_v1::any::_Arg*), _M_storage = {_M_ptr =
0x10041cf8, _M_buffer = {__data = \000\000\000\000\020\004\034\370, __align =
{No data fields=
expected =std::experimental::any containing std::string = {[contained value] =
stringy}=
FAIL: libstdc++-prettyprinters/libfundts.cc print as2
got ={_M_manager = @0x10020740: 0x10002fe4
std::experimental::fundamentals_v1::any::_Manager_internalchar
const*::_S_manage(std::experimental::fundamentals_v1::any::_Op,
std::experimental::fundamentals_v1::any const*,
std::experimental::fundamentals_v1::any::_Arg*), _M_storage = {_M_ptr =
0x100065a0, _M_buffer = {__data = \000\000\000\000\020\000e\240, __align =
{No data fields=
expected =std::experimental::any containing const char \* = {\[contained
value\] = 0x[[:xdigit:]]+ stringiest}=
FAIL: libstdc++-prettyprinters/libfundts.cc print am
got ={_M_manager = @0x10020770: 0x1000313c
std::experimental::fundamentals_v1::any::_Manager_externalstd::mapint,
double, std::lessint, std::allocatorstd::pairint const, double
::_S_manage(std::experimental::fundamentals_v1::any::_Op,
std::experimental::fundamentals_v1::any const*,
std::experimental::fundamentals_v1::any::_Arg*), _M_storage = {_M_ptr =
0x10041d10, _M_buffer = {__data = \000\000\000\000\020\004\035\020, __align =
{No data fields=
expected =std::experimental::any containing std::map with 3 elements = {[1] =
2, [3] = 4, [5] = 6}=
[Bug sanitizer/65479] sanitizer stack trace missing frames past #0 on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65479 --- Comment #1 from Martin Sebor msebor at gcc dot gnu.org --- The same problem is causing failures in the following tests on these targets: c-c++-common/asan/misalign-2.c c-c++-common/asan/null-deref-1.c
[Bug target/65474] sub-optimal code for __builtin_abs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65474 --- Comment #3 from wmi at google dot com --- Thanks. You are right. I wrote a microbenchmark (attached), and tested it on different intel microarchitectures. westmere: 1.gcc.out:19.42 1.llvm.out: 19.32 sandybridge: 1.gcc.out:18.61 1.llvm.out: 19.16 ivybridge: 1.gcc.out:15.79 1.llvm.out: 15.87 On sandybridge, llvm's version was slower. On other microarchitectures, they were close to each other. So gcc's choose makes sense.
[Bug preprocessor/65481] New: _Pragma GCC dependency broken on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65481 Bug ID: 65481 Summary: _Pragma GCC dependency broken on powerpc64 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org The gcc.dg/cpp/_Pragma3.c test is failing on powerpc64 but passes on powerpc64le. The following test case demonstrates the same problem that causes the test failure. It looks like the timestamp computation is broken on this target. GCC 4.8.3 has the same problem. $ cat t.c touch t.h stat t.c t.h /build/gcc-5.0/gcc/xgcc -B/build/gcc-5.0/gcc -ansi -pedantic-errors -E -o/dev/null t.c #define GCC_PRAGMA(x) _Pragma (#x) GCC_PRAGMA(GCC dependency t.h) File: ‘t.c’ Size: 68Blocks: 8 IO Block: 65536 regular file Device: fd00h/64768dInode: 69928678Links: 1 Access: (0664/-rw-rw-r--) Uid: (25066/ msebor) Gid: (25066/ msebor) Context: unconfined_u:object_r:default_t:s0 Access: 2015-03-19 19:55:32.668667450 -0400 Modify: 2015-03-19 19:54:40.448639710 -0400 Change: 2015-03-19 19:54:40.468639721 -0400 Birth: - File: ‘t.h’ Size: 0 Blocks: 0 IO Block: 65536 regular empty file Device: fd00h/64768dInode: 69928674Links: 1 Access: (0664/-rw-rw-r--) Uid: (25066/ msebor) Gid: (25066/ msebor) Context: unconfined_u:object_r:default_t:s0 Access: 2015-03-19 19:56:02.508682213 -0400 Modify: 2015-03-19 19:56:02.508682213 -0400 Change: 2015-03-19 19:56:02.508682213 -0400 Birth: - t.c:2:16: warning: current file is older than t.h GCC_PRAGMA(GCC dependency t.h) ^
[Bug tree-optimization/65478] crafty performance regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||mjambor at suse dot cz --- Comment #1 from Jan Hubicka hubicka at gcc dot gnu.org --- Martin, can you take a look on ipa-cp's decision sanity?
[Bug c/65466] Unnecessary source line output for note: each undeclared identifier is reported only once
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65466 --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to jos...@codesourcery.com from comment #2) On Thu, 19 Mar 2015, manu at gcc dot gnu.org wrote: (If I was re-doing that patch again, I will try to overload inform(), because inform_with_flags is just too much typing). Note that diagnostic functions cannot be overloaded in a way that means different functions with the same name have the msgid argument in different positions, as that breaks exgettext. Ah, yes, I forgot about this. We had this problem already in the Fortran FE. Can exgettext be fixed to handle overloads eventually? Perhaps someone could reimplement it as a GCC plugin. That would be a nice GSoC!
[Bug c/65455] typeof _Atomic fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #12 from Marek Polacek mpolacek at gcc dot gnu.org --- What does clang differently wrt _Generic?
[Bug c++/59526] [C++11] Defaulted special member functions don't accept noexcept if a member has a non-trivial noexcept operator in the corresponding special member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59526 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- This is fixed for 5.0.
[Bug ipa/65465] [5 Regression] Internal compiler error: in build2_stIat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65465 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- I'll try to reduce this. -fno-ipa-icf works.
[Bug rtl-optimization/65235] Simplifying vec_select of vec_concat miscompiles when first element of vec_concat is const_int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65235 --- Comment #10 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Thu Mar 19 09:58:42 2015 New Revision: 221511 URL: https://gcc.gnu.org/viewcvs?rev=221511root=gccview=rev Log: [simplify-rtx] PR 65235: Calculate element size correctly when simplifying (vec_select (vec_concat (const_int) (...)) [...]) Backport from mainline 2015-03-12 Kyrylo Tkachov kyrylo.tkac...@arm.com PR rtl-optimization/65235 * simplify-rtx.c (simplify_binary_operation_1, VEC_SELECT case): When first element of vec_concat is const_int, calculate its size using second element. PR rtl-optimization/65235 * gcc.target/aarch64/pr65235_1.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.target/aarch64/pr65235_1.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/simplify-rtx.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug sanitizer/65400] [5 Regression] tsan mis-compiles inlineable C functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65400 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Target Milestone|--- |5.0 Summary|tsan mis-compiles |[5 Regression] tsan |inlineable C functions |mis-compiles inlineable C ||functions --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug sanitizer/65400] [5 Regression] tsan mis-compiles inlineable C functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65400 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Mar 19 10:12:34 2015 New Revision: 221512 URL: https://gcc.gnu.org/viewcvs?rev=221512root=gccview=rev Log: PR sanitizer/65400 * tsan.c (instrument_gimple): Clear tail call flag on calls. * c-c++-common/tsan/pr65400-3.c: New test. Added: trunk/gcc/testsuite/c-c++-common/tsan/pr65400-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tsan.c
[Bug c++/56636] strange interaction of dynamic_cast and unique_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56636 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- Maybe Kai can double check that we can close this.
[Bug c/65455] typeof _Atomic fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455 --- Comment #13 from Jens Gustedt jens.gustedt at inria dot fr --- (In reply to Marek Polacek from comment #12) What does clang differently wrt _Generic? Arrays. I don't recall which way around, but one of gcc and clang converts array types to pointers and the other not. Something like _Generic(bla, ...) has different outcome according to the compiler.
[Bug c++/59760] use_thunk internal error on default destructor declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59760 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com --- Dup. *** This bug has been marked as a duplicate of bug 60595 ***
[Bug c++/60595] Compiler error when computing default destructor thunk within virtual inheritance hierarchy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60595 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||sshannin at gmail dot com --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- *** Bug 59760 has been marked as a duplicate of this bug. ***
[Bug libgomp/65467] New: [libgomp] sorry, unimplemented: '_Atomic' with OpenMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65467
Bug ID: 65467
Summary: [libgomp] sorry, unimplemented: '_Atomic' with OpenMP
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
CC: jakub at gcc dot gnu.org
It seems that stdatomic.h is not available with -fopenmp:
stdatomic.h:40:1: sorry, unimplemented: '_Atomic' with OpenMP
typedef _Atomic _Bool atomic_bool;
Is this a principal problem with the OpenMP standard or libgomp?
The __atomic built-ins seem to work, e.g.
int f(int *a, int b)
{
return __atomic_fetch_add(a, b, 0);
}
[Bug c++/60595] Compiler error when computing default destructor thunk within virtual inheritance hierarchy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60595 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||ignoreddropbox at gmail dot com --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- *** Bug 60180 has been marked as a duplicate of this bug. ***
[Bug libstdc++/65470] New: regex_search corrupts matches when haystack is destroyed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65470
Bug ID: 65470
Summary: regex_search corrupts matches when haystack is
destroyed
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: aral at gmx dot de
Created attachment 35063
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35063action=edit
minimal bug example - compile with g++ -std=c++11 regexbug.cpp -o regexbug
Tested on g++ (Debian 4.9.2-10) 4.9.2.
regex_search with matches apparently depends on the haystack (in both the const
basic_string and const *charT versions) to remain intact. The matches object
returned seems to point to locations in the original haystack. When the
haystack is destroyed, the matches are corrupted.
This leads to very unpleasant results when using regex_search with the
temporary strings returned by .string() or .c_str() methods of many objects
(e.g. boost::filesystem::path.filename() ), as those strings are destroyed at
the end of the line containing the regex_search.
Fix recommendation:
1) if this behavior is intended for performance, add a REALLY BIG FLASHING RED
WARNING MESSAGE to the function documentation on cplusplus.com (and anywhere)
that the haystack MUST NOT be a temporary string, and MUST be kept until after
the matches have been evaluated.
2) to fix, modify the (sub)matches class so that it creates a copy of each
match and manages that copy destruction itself
To reproduce (also submitted as attachment):
-
#include regex
#include iostream
using namespace std;
int main( void )
{
cmatch match;// store the matches here,
this object seems to depend on haystack after search
char *haystack = strdup (BUG DEMO);
regex_search( haystack, match, regex(.*) );// perform regex
search in the haystack, always matches, not checking match.size() for brevity
cout correct match: match[0] endl;// document the
correct match
delete haystack;// destroy the haystack
cout corrupt match: match[0] endl;// document the
correct match
return 0;
}
-
(compile with g++ -std=c++11 regexbug.cpp -o regexbug)
[Bug c/65455] typeof _Atomic fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455 --- Comment #14 from Jens Gustedt jens.gustedt at inria dot fr --- Perhaps we should end the discussion here, this goes too far for a bug report, and we should push for a solution of this type of questions by the C committee. Perhaps you could leave this bug open, even if you don't agree that it is a bug in gcc itself. It certainly is an issue that users of that feature in gcc should be aware of. I think that this should be resolved in one way or another, best by having a clear policy in the C standard itself what to do in such situations.
[Bug c++/60595] Compiler error when computing default destructor thunk within virtual inheritance hierarchy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60595 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.8.3, 4.9.0, 5.0 Resolution|--- |FIXED Target Milestone|--- |4.8.3 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- This is fixed in 4.8.3.
[Bug c++/59702] Infinite recursion in a late-specified return type of a function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59702 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-19 Ever confirmed|0 |1
[Bug c++/59729] [DR1732] C++11 allows type definitions in conditions and for-range-declarations, but shouldn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59729 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-19 Ever confirmed|0 |1 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- It's C++14 now.
[Bug c++/59739] missed optimization: attribute ((pure)) could be honored more often
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59739 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- CC-ing Honza
[Bug fortran/65469] New: ICE on bad code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65469 Bug ID: 65469 Summary: ICE on bad code Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: daniel.price at monash dot edu Created attachment 35062 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35062action=edit code that produces the internal compiler error Dear gfortran folks, Attached is a short test case of (wrong) code I happened to produce that triggers an internal compiler error and a seg fault. I've got it down to just 9 lines of code. The code should obviously fail to compile, but I thought you might like to fix the ICE and the seg fault... Daniel Output as follows: $ gfortran-mp-4.9 -o ice.o -c ice.f90 ice.f90:7.17: type(block_type) :: my_block 1 Error: Derived type 'block_type' at (1) is being used before it is defined f951: internal compiler error: Segmentation fault: 11 f951: internal compiler error: Abort trap: 6 gfortran-mp-4.9: internal compiler error: Abort trap: 6 (program f951) Abort trap: 6 - Version info (also fails with gfortran v4.8): - $ gfortran-mp-4.9 -v Using built-in specs. COLLECT_GCC=gfortran-mp-4.9 COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin14/4.9.2/lto-wrapper Target: x86_64-apple-darwin14 Configured with: /opt/local/var/macports/build/_opt_mports_dports_lang_gcc49/gcc49/work/gcc-4.9.2/configure --prefix=/opt/local --build=x86_64-apple-darwin14 --enable-languages=c,c++,objc,obj-c++,lto,fortran,java --libdir=/opt/local/lib/gcc49 --includedir=/opt/local/include/gcc49 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-4.9 --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-4.9 --with-gxx-include-dir=/opt/local/include/gcc49/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --with-isl=/opt/local --disable-isl-version-check --with-cloog=/opt/local --disable-cloog-version-check --enable-stage1-checking --disable-multilib --enable-lto --enable-libstdcxx-time --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket --with-pkgversion='MacPorts gcc49 4.9.2_1' Thread model: posix gcc version 4.9.2 (MacPorts gcc49 4.9.2_1)
[Bug ipa/62051] [4.9/5 Regression] Undefined reference to vtable with -O2 and -fdevirtualize-speculatively
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62051 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #3 from Markus Trippelsdorf trippels at gcc dot gnu.org --- If you define void Derived::func() directly in the header if works as expected. And since ~Derived() calls this function you must provide it in every compilation unit. So the devirtualization looks correct to me.
[Bug target/65358] wrong parameter passing code with tail call optimization on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65358 --- Comment #17 from Honggyu Kim hong.gyu.kim at lge dot com --- (In reply to ktkachov from comment #16) I'm working on a patch btw. This bug is only shown in arm code so maybe the bug is in gcc/config/arm directory. I was trying to fix it myself but I may need more experience in gcc code to fix this kind of problem. Thank you.
[Bug sanitizer/64265] [5 Regression] r217669 broke tsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64265 --- Comment #27 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Mar 19 07:55:22 2015 New Revision: 221509 URL: https://gcc.gnu.org/viewcvs?rev=221509root=gccview=rev Log: PR sanitizer/64265 * g++.dg/tsan/pr64265.C: New test. Added: trunk/gcc/testsuite/g++.dg/tsan/pr64265.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/59686] Non-constexpr pointers accepted in constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59686 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Mainline properly rejects this. I'm adding the testcase and closing the bug.
[Bug target/65358] wrong parameter passing code with tail call optimization on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65358 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ktkachov at gcc dot gnu.org --- Comment #16 from ktkachov at gcc dot gnu.org --- I'm working on a patch btw.
[Bug ipa/62051] [4.9/5 Regression] Undefined reference to vtable with -O2 and -fdevirtualize-speculatively
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62051 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-19 Component|c++ |ipa Version|unknown |5.0 Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Thus confirmed.
[Bug c++/59950] Bogus diagnostic taking address of temporary taking address of trivial no-op assignment to temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59950 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-19 Ever confirmed|0 |1
[Bug middle-end/65449] -fstrict-volatile-bitfields affects volatile pointer dereference and produce wrong codes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65449
--- Comment #2 from ma.jiang at zte dot com.cn ---
(In reply to Bernd Edlinger from comment #1)
Hi Richard,
the invalid/different code for -O2 -fstrict-volatile-bitfields will be
fixed with my proposed patch, because the misalignedness of mm should
be visible at -O2 and prevent the strict_volatile bitfields path to be
entered.
Could you give your OK to the latest version?
see https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00817.html
Thanks
Bernd.
Hi Bernd,
Your patch do fix the unaligned stw problem. But,there are still 4 lbz
instructions for *((volatile int *)mm)=4; after your fix. I thought they
were caused by the -fstrict-volatile-bitfields originally.After a more careful
check, I find they are caused by temp = force_reg (mode, op0); in
store_fixed_bit_field_1. The *((int *)mm)=4; produce no lbz instructions,
but still produce useless load when doing rtl expand.
(insn 7 6 8 2 (set (reg:QI 157)
(mem/c:QI (plus:SI (reg/f:SI 155)
(const_int 1 [0x1])) [1 MEM[(int *)mt + 1B]+0 S1 A8])) nt.c:5
489 {*movqi_internal}
(nil))
These loads will be eliminated in fwprop1 as they are meaningless.However,
after adding volatile for the memory mm, the fwprop1 pass can not delete these
loads as volatile loads should not be removed.
So, I think we should first get rid of the volatile flag from op0 before call
force_reg (mode, op0). I have tried to adding rtx op1 = copy_rtx (op0);
MEM_VOLATILE_P(op1)=0; just before force_reg, and it do remove those lbz
instruction.
[Bug target/65358] wrong parameter passing code with tail call optimization on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65358 --- Comment #18 from ktkachov at gcc dot gnu.org --- (In reply to Honggyu Kim from comment #17) (In reply to ktkachov from comment #16) I'm working on a patch btw. This bug is only shown in arm code so maybe the bug is in gcc/config/arm directory. I was trying to fix it myself but I may need more experience in gcc code to fix this kind of problem. Thank you. I believe this bug could be triggered on any target/ABI that can pass aggregate arguments (i.e. structs) partially in regs and partially on the stack and the fix I'm working on is in the midend.
[Bug c++/60583] Garbled data, temporary bound ... only persists until the constructor exits, fine with clang++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60583 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Dup then. *** This bug has been marked as a duplicate of bug 50025 ***
[Bug c/65455] typeof _Atomic fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455 --- Comment #16 from Jens Gustedt jens.gustedt at inria dot fr --- (In reply to Jakub Jelinek from comment #15) Usually such bugs are SUSPENDED with reference to the DR and when the DR is resolved, the bug is resolved accordingly. Here the situation is a bit more complicated, since __typeof__ is an extension to C, so no DR will directly say something about this. Do you want me to open a new bug for the observation that _Generic leads to compiler specific results?
[Bug target/62109] __gthr_i486_lock_cmp_xchg missing clobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109 --- Comment #7 from Kai Tietz ktietz at gcc dot gnu.org --- I agree that we change it to #define __GTHR_W32_InterlockedCompareExchange InterlockedCompareExchange not sure if we actually should error out here at all. We might want to remove instead the use of __GTHREAD_I486_INLINE_LOCK_PRIMITIVES completely.
[Bug c/65455] typeof _Atomic fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org --- Usually such bugs are SUSPENDED with reference to the DR and when the DR is resolved, the bug is resolved accordingly.
[Bug tree-optimization/65468] New: Optimize static schedule with chunk_size one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65468
Bug ID: 65468
Summary: Optimize static schedule with chunk_size one
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Consider test.c:
...
extern void abort ();
int
bar ()
{
int a = 0, i;
#pragma omp parallel for num_threads (3) reduction (+:a) schedule(static, 1)
for (i = 0; i 10; i++)
a += i;
return a;
}
int
main (void)
{
int res;
res = bar ();
if (res != 45)
abort ();
return 0;
}
...
So, we create 3 threads, and the schedule will be:
threadnr | iterations
-
0| 0 3 6 9
1| 1 4 7
2| 2 5 8
The code is generated using expand_for_omp_static_chunk, which results in the
following code for -O2 -fopenmp (optimized dump):
...
bar._omp_fn.0 (struct .omp_data_s.0 restrict .omp_data_i)
{
int i;
int a;
int _6;
int _11;
int * _17;
int _21;
unsigned int _23;
int _25;
int _26;
unsigned int _27;
int _29;
unsigned int _31;
unsigned int _32;
int _33;
unsigned int _34;
unsigned int pretmp_35;
unsigned int prephitmp_36;
bb 2:
_6 = __builtin_omp_get_num_threads ();
i_7 = __builtin_omp_get_thread_num ();
_25 = i_7 + 1;
_26 = MIN_EXPR _25, 10;
if (i_7 = 9)
goto bb 3;
else
goto bb 8;
bb 3:
# a_3 = PHI 0(2)
# i_24 = PHI i_7(2)
# _21 = PHI _26(2)
bb 4:
# a_12 = PHI a_3(3), a_13(6)
# i_5 = PHI i_24(3), i_22(6)
# _29 = PHI _21(3), _11(6)
bb 5:
# a_1 = PHI a_12(4), a_13(5)
# i_4 = PHI i_5(4), i_14(5)
a_13 = a_1 + i_4;
i_14 = i_4 + 1;
if (i_14 _29)
goto bb 5;
else
goto bb 6;
bb 6:
_32 = (unsigned int) i_5;
_31 = (unsigned int) _6;
_23 = _31 + _32;
i_22 = (int) _23;
_27 = _23;
_34 = _27 + 1;
_33 = (int) _34;
_11 = MIN_EXPR _33, 10;
if (i_22 = 9)
goto bb 4;
else
goto bb 7;
bb 7:
pretmp_35 = (unsigned int) a_13;
bb 8:
# prephitmp_36 = PHI pretmp_35(7), 0(2)
_17 = .omp_data_i_16(D)-a;
__atomic_fetch_add_4 (_17, prephitmp_36, 0); [tail call]
return;
}
...
The code contains a loop nest with two loops. The inner loop handles a single
chunk, the outer loop iterates over the chunks assigned to the thread.
For a chunk size of one, we know that the inner loop will only execute the body
once at all times. But the compiler doesn't manage to optimize the inner loop
away.
[Bug c++/65072] Segfault when parsing dectlype in trailing return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65072 --- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org --- Here, we SEGV in build_class_member_access_expr, called recursively: tree anonymous_union; anonymous_union = lookup_anon_field (TREE_TYPE (object), DECL_CONTEXT (member)); object = build_class_member_access_expr (object, anonymous_union, [...] anonymous_union is NULL and build_class_member_access_expr is not prepared to handle that. anonymous_union is NULL because lookup_anon_field returned NULL: it tried to look for a struct ._0 type in const struct C -- and found nothing. That is because const struct C doesn't have any fields! But if I change the testcase so that C is not const, it passes, because struct C then has fields and lookup_anon_field is able to find a FIELD_DECL. So the question is why const struct C doesn't have any fields. I couldn't figure that out yet :(.
[Bug c++/65072] Segfault when parsing dectlype in trailing return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65072 --- Comment #8 from Marek Polacek mpolacek at gcc dot gnu.org --- (Just bailing out of build_class_member_access_expr if MEMBER is null fixes the ICE, but in view of the unclarity above I don't think it's the right fix.)
[Bug c++/59550] compiler crash when forming a pointer to a reference would be needed in std::initalizer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59550 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.9.1, 5.0 Resolution|--- |FIXED Target Milestone|--- |4.9.1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed in 4.9.1.
[Bug libgomp/65467] [libgomp] sorry, unimplemented: '_Atomic' with OpenMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65467 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- This is indeed just a big hammer approach. The OpenMP standard only supports C up to C99 and C++ up to C++98 at this point, for _Atomic it is non-trivial to figure out how it should behave with different clauses etc. But indeed, it would be better to just complain only if _Atomic is somehow used in OpenMP regions, but that would require first writing testcases for all the different possibilities where _Atomic could appear.
[Bug tree-optimization/65468] Optimize static schedule with chunk_size one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65468
--- Comment #1 from vries at gcc dot gnu.org ---
Using the patch submitted for gomp-4_0-branch at
https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01881.html, we get a simple loop:
...
bar._omp_fn.0 (struct .omp_data_s.0 restrict .omp_data_i)
{
int i;
int a;
int _3;
int * _10;
unsigned int pretmp_14;
unsigned int _16;
unsigned int _17;
unsigned int _19;
unsigned int prephitmp_22;
bb 2:
_3 = __builtin_omp_get_num_threads ();
i_4 = __builtin_omp_get_thread_num ();
if (i_4 = 9)
goto bb 3;
else
goto bb 6;
bb 3:
# a_5 = PHI 0(2)
# i_2 = PHI i_4(2)
bb 4:
# a_18 = PHI a_5(3), a_7(4)
# i_21 = PHI i_2(3), i_15(4)
a_7 = a_18 + i_21;
_19 = (unsigned int) _3;
_17 = (unsigned int) i_21;
_16 = _17 + _19;
i_15 = (int) _16;
if (i_15 = 9)
goto bb 4;
else
goto bb 5;
bb 5:
pretmp_14 = (unsigned int) a_7;
bb 6:
# prephitmp_22 = PHI pretmp_14(5), 0(2)
_10 = .omp_data_i_9(D)-a;
__atomic_fetch_add_4 (_10, prephitmp_22, 0); [tail call]
return;
}
...
[Bug c/65455] typeof _Atomic fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455 --- Comment #17 from Marek Polacek mpolacek at gcc dot gnu.org --- (In reply to Jens Gustedt from comment #16) Here the situation is a bit more complicated, since __typeof__ is an extension to C, so no DR will directly say something about this. I can look into this, but I think it's a GCC 6 material. Do you want me to open a new bug for the observation that _Generic leads to compiler specific results? Please do. I think we should have a bug specifically to address DR#423.
[Bug sanitizer/65400] tsan mis-compiles inlineable C functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65400 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Thu Mar 19 07:53:38 2015 New Revision: 221508 URL: https://gcc.gnu.org/viewcvs?rev=221508root=gccview=rev Log: PR sanitizer/65400 * ipa-split.c (find_return_bb): Allow TSAN_FUNC_EXIT internal call in the return bb. (find_split_points): Add RETURN_BB argument, don't call find_return_bb. (split_function): Likewise. Add ADD_TSAN_FUNC_EXIT argument, if true append TSAN_FUNC_EXIT internal call after the call to the split off function. (execute_split_functions): Call find_return_bb here. Don't optimize if TSAN_FUNC_EXIT is found in unexpected places. Adjust find_split_points and split_function calls. * c-c++-common/tsan/pr65400-1.c: New test. * c-c++-common/tsan/pr65400-2.c: New test. Added: trunk/gcc/testsuite/c-c++-common/tsan/pr65400-1.c trunk/gcc/testsuite/c-c++-common/tsan/pr65400-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-split.c trunk/gcc/testsuite/ChangeLog
[Bug c++/59686] Non-constexpr pointers accepted in constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59686 --- Comment #3 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Thu Mar 19 08:57:01 2015 New Revision: 221510 URL: https://gcc.gnu.org/viewcvs?rev=221510root=gccview=rev Log: 2015-03-19 Paolo Carlini paolo.carl...@oracle.com PR c++/59686 * g++.dg/cpp0x/constexpr-59686.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-59686.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug ipa/65465] [5 Regression] Internal compiler error: in build2_stIat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65465 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Keywords||ice-on-valid-code Last reconfirmed||2015-03-19 Component|c++ |ipa CC||mliska at suse dot cz Ever confirmed|0 |1 Summary|Internal compiler error: in |[5 Regression] Internal |build2_stIat|compiler error: in ||build2_stIat Target Milestone|--- |5.0 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed with a cross. The single preprocessed file needs reducing still. Breakpoint 1, internal_error (gmsgid=0x1b9ca6f in %s, at %s:%d) at /space/rguenther/src/svn/trunk2/gcc/diagnostic.c:1221 1221 va_start (ap, gmsgid); Missing separate debuginfos, use: zypper install libgmp10-debuginfo-6.0.0-71.1.x86_64 libisl13-debuginfo-0.14-25.2.x86_64 libmpc3-debuginfo-1.0.2-38.2.x86_64 (gdb) bt #0 internal_error (gmsgid=0x1b9ca6f in %s, at %s:%d) at /space/rguenther/src/svn/trunk2/gcc/diagnostic.c:1221 #1 0x016dee17 in fancy_abort ( file=0x1898618 /space/rguenther/src/svn/trunk2/gcc/tree.c, line=4383, function=0x189e97f build2_stat(tree_code, tree_node*, tree_node*, tree_node*)::__FUNCTION__ build2_stat) at /space/rguenther/src/svn/trunk2/gcc/diagnostic.c:1291 #2 0x0123f5ee in build2_stat (code=POINTER_PLUS_EXPR, tt=0x758ee348, arg0=0x722c6168, arg1=0x7fffe3a71f20) at /space/rguenther/src/svn/trunk2/gcc/tree.c:4382 #3 0x00b85010 in build2_stat_loc (loc=49934370, code=POINTER_PLUS_EXPR, type=0x758ee348, arg0=0x722c6168, arg1=0x7fffe3a71f20) at /space/rguenther/src/svn/trunk2/gcc/tree.h:3690 #4 0x00bc4674 in fold_build2_stat_loc (loc=49934370, code=POINTER_PLUS_EXPR, type=0x758ee348, op0=0x722c6168, op1=0x7fffe3a71f20) at /space/rguenther/src/svn/trunk2/gcc/fold-const.c:14325 #5 0x00bca659 in fold_build_pointer_plus_loc (loc=49934370, ptr=0x722c6168, off=0x72386c60) at /space/rguenther/src/svn/trunk2/gcc/fold-const.c:16267 #6 0x00a77933 in thunk_adjust (bsi=0x7fffd840, ptr=0x722c6168, this_adjusting=false, fixed_offset=0, virtual_offset=0x7fffdf18bfd8) at /space/rguenther/src/svn/trunk2/gcc/cgraphunit.c:1463 #7 0x00a78e00 in cgraph_node::expand_thunk (this=0x7fffed309310, output_asm_thunks=false, force_gimple_thunk=true) at /space/rguenther/src/svn/trunk2/gcc/cgraphunit.c:1750 #8 0x00a7a9af in cgraph_node::create_wrapper (this=0x7fffed309310, target=0x7fffe45d1498) at /space/rguenther/src/svn/trunk2/gcc/cgraphunit.c:2499 #9 0x0163afda in ipa_icf::sem_function::merge (this=0x32c5780, alias_item=0x3a06280) at /space/rguenther/src/svn/trunk2/gcc/ipa-icf.c:1033 #10 0x01641fa8 in ipa_icf::sem_item_optimizer::merge_classes ( this=0x3757b50, prev_class_count=5884) at /space/rguenther/src/svn/trunk2/gcc/ipa-icf.c:2979 #11 0x0163f9ff in ipa_icf::sem_item_optimizer::execute (this=0x3757b50) at /space/rguenther/src/svn/trunk2/gcc/ipa-icf.c:2236 #12 0x01642345 in ipa_icf::ipa_icf_driver () at /space/rguenther/src/svn/trunk2/gcc/ipa-icf.c:3060 #13 0x01642c59 in ipa_icf::pass_ipa_icf::execute (this=0x20fab80) we build a POINTER_PLUS_EXPR of type 'struct AffineTransform'!? 1462 /* Adjust the `this' pointer. */ 1463 ptr = fold_build_pointer_plus_loc (input_location, ptr, vtabletmp3); but 'ptr' is (gdb) p debug_tree (ptr) result_decl 0x722c6168 D.736599 type record_type 0x758ee348 AffineTransform sizes-gimplified needs-constructing type_1 type_5 type_6 BLK size integer_cst 0x76749420 constant 384 so it looks like we build bogus thunks or perform bogus merges.
[Bug c++/50025] [DR 1288] C++0x initialization syntax doesn't work for class members of reference type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50025 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||andreaskem at web dot de --- Comment #25 from Paolo Carlini paolo.carlini at oracle dot com --- *** Bug 60583 has been marked as a duplicate of this bug. ***
[Bug c++/59579] Defaulted copy constructor of template class is instantiated even when not called (probably bug 57153)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59579 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Not a bug. By the way EDG and clang reject the testcase with the same diagnostic.
[Bug c++/59686] Non-constexpr pointers accepted in constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59686 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Done.
[Bug c++/59729] [DR1732] C++11 allows type definitions in conditions and for-range-declarations, but shouldn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59729 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 #3 from Paolo Carlini paolo.carlini at oracle dot com --- Mine.
[Bug c++/60180] internal compiler error: in use_thunk, at cp/method.c:338
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60180 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- *** This bug has been marked as a duplicate of bug 60595 ***
[Bug c++/60687] [4.8.0] Infinite loop compiling recursive templates indirectly by local class in function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60687 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Closing.
[Bug c++/52659] GCC fails to reject a deleted function definition which is not the first declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52659 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- This is fixed for 5.0. I'm adding the testcase and closing the bug.
[Bug c++/52659] GCC fails to reject a deleted function definition which is not the first declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52659 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Done.
[Bug c++/56636] strange interaction of dynamic_cast and unique_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56636 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #6 from Kai Tietz ktietz at gcc dot gnu.org --- So tested it for 4.8 (branch), 4.9 (branch), and 5.0 (trunk). I can't reproduce this ICE, so I close this bug as fixed worksforme.
[Bug c++/52659] GCC fails to reject a deleted function definition which is not the first declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52659 --- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Thu Mar 19 11:02:47 2015 New Revision: 221513 URL: https://gcc.gnu.org/viewcvs?rev=221513root=gccview=rev Log: 2015-03-19 Paolo Carlini paolo.carl...@oracle.com PR c++/52659 * g++.dg/cpp0x/deleted11.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/deleted11.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/65470] regex_search corrupts matches when haystack is destroyed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65470 --- Comment #1 from aral at gmx dot de --- AFAICT the same bug is applicable to the regex_match function. Sorry for the copy paste error in the very last comment.
[Bug tree-optimization/64715] [5 Regression] __builtin_object_size (..., 1) fails to locate subobject
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64715 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- So, given that you promoted this to P1, what are we going to do with this? This indeed started with r214941, and from objsz POV, in *.original, while it changed from: - strcpy (a.buf1[4], str1 + 5); + strcpy ((char *) a.buf1 + 4, str1 + 5); it is still reasonable, no information is lost. The information is lost during gimplification, where we gimplify it as: - strcpy (a.buf1[4], D.1762); + strcpy (MEM[(void *)a + 4B], D.1762); and there we already lost the info whether it was strcpy (a.buf1 + 4, ...) or strcpy (a, ...), where we really don't want to treat those two the same. So, either we should avoid folding this to a MEM_REF before objsz pass, or allow MEM_REF operand to be (perhaps just before objsz pass) not just SSA_NAME or ADDR_EXPR of a DECL, but also ADDR_EXPR of handled_component_p and only lower it later (lose the information on where it pointed to). Or add optional third argument to MEM_REF that would contain say the COMPONENT_REF (if any) with PLACEHOLDER_EXPR inside for the type of the DECL in ADDR_EXPR in the first operand. Something else?
[Bug tree-optimization/64715] [5 Regression] __builtin_object_size (..., 1) fails to locate subobject
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64715 --- Comment #10 from Richard Biener rguenth at gcc dot gnu.org --- I do think that the gimplifiers folding is premature. All propagators know to apply the trick internally. This premature folding is probably to avoid regressions with removing the invalid maybe_fold_* stuff. I'll see whether removing it is safe. Of course it won't fix the testcase on its own - CCP happily applies the same trick to forward the constant address to the builtin call: --- t.c.028t.copyrename12015-03-19 12:52:53.875179949 +0100 +++ t.c.029t.ccp1 2015-03-19 12:52:53.876179961 +0100 @@ -25,21 +25,15 @@ struct A a; const char * str1.0_2; const char * _3; - char * _4; - int _7; - long unsigned int _8; char * _9; bb 2: str1.0_2 = str1; _3 = str1.0_2 + 5; - _4 = a.buf1 + 4; - _8 = __builtin_object_size (_4, 1); - _9 = __builtin___strcpy_chk (_4, _3, _8); + _9 = __builtin___strcpy_chk (MEM[(void *)a + 4B], _3, 6); also folding the object-size call at the same time (to the bogus value because of passing it MEM[(void *)a, +4B] as well). I think it is desirable to fold the object-size call here and we can certainly special-case this particular case (looking at the def of _4 instead of its lattice value). But not sure if that's a good enough fix for the general issue. After fixing the gimplifier we have to make sure neither CCP1, CCP2 or FRE1 perform this trick (forwprop would also wreck things for slightly more complicated cases).
[Bug fortran/63230] allocation of deferred length character as derived type component causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63230 vehre at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug tree-optimization/64715] [5 Regression] __builtin_object_size (..., 1) fails to locate subobject
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64715 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- For the option of not folding this to MEM_REFs before objsz pass, I'd note this could be just about the MEM_REF cases, if there is an actual memory access, so we aren't taking the address of the MEM_REF, then we can use MEM_REF as before. Similarly if we are folding a + 4 into MEM_REF[a + 4] it would be fine, just we'd avoid doing that early for a.field + 4.
[Bug ipa/65483] New: bzip2 bsR/bsW should be auto-inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65483
Bug ID: 65483
Summary: bzip2 bsR/bsW should be auto-inlined
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
bzip2 contains:
INLINE UInt32 bsR ( Int32 n )
{
UInt32 v;
bsNEEDR ( n );
v = (bsBuff (bsLive-n)) ((1 n)-1);
bsLive -= n;
return v;
}
and
INLNE void bsW ( Int32 n, UInt32 v )
{
bsNEEDW ( n );
bsBuff |= (v (32 - bsLive - n));
bsLive += n;
}
which should be inlined. INLINE is however defined to nothing for SPEC.
The catch is that we instead inline fgetc/fputc into the functions here:
#define bsNEEDR(nz) \
{ \
while (bsLive nz) { \
Int32 zzi = fgetc ( bsStream ); \
if (zzi == EOF) compressedStreamEOF(); \
bsBuff = (bsBuff 8) | (zzi 0xffL); \
bsLive += 8;\
} \
}
/*-*/
#define bsNEEDW(nz) \
{ \
while (bsLive = 8) { \
fputc ( (UChar)(bsBuff 24), \
bsStream );\
bsBuff = 8; \
bsLive -= 8;\
bytesOut++; \
} \
}
Considering spec_getc/285 with 33 size
to be inlined into bsR/98 in unknown:-1
Estimated badness is -21.814074, frequency 21.04.
Badness calculation for bsR/98 - spec_getc/285
size growth 27, time 22 inline hints: cross_module big_speedup
-10.907037: guessed profile. frequency 21.035000, count 0 caller count 0
time w/o inlining 1063.840001, time w inlining 769.35 overall growth 0
(current) 0 (original)
Adjusted by hints -21.814074
Accounting size:20.00, time:304.69 on predicate:(true)
...
Inlined into bsR which now has time 767 and size 55,net change of +27.
which makes it to reach inline-insns-auto limit.
bsR is estimated as:
Inline summary for bsR/98 inlinable
self time: 559
global time: 0
self size: 28
global size: 0
min size: 0
self stack: 0
global stack:0
size:21.00, time:304.328000, predicate:(true)
size:3.00, time:1.982000, predicate:(not inlined)
calls:
compressedStreamEOF/143 function not considered for inlining
loop depth: 0 freq: 8 size: 1 time: 10 callee size:12 stack: 0
spec_getc/153 function body not available
loop depth: 1 freq:21035 size: 3 time: 12 callee size: 0 stack: 0
The spec_getc is implemented as:
int spec_getc (int fd) {
int rc = 0;
debug1(4,spec_getc: %d = , fd);
if (fd MAX_SPEC_FD) {
fprintf(stderr, spec_read: fd=%d, MAX_SPEC_FD!\n, fd);
exit (1);
}
if (spec_fd[fd].pos = spec_fd[fd].len) {
debug(4,EOF\n);
return EOF;
}
rc = spec_fd[fd].buf[spec_fd[fd].pos++];
debug1(4,%d\n, rc);
return rc;
}
we however split out the error handling into spec_getc.part and get:
Inline summary for spec_getc/38 inlinable
self time: 24
global time: 0
self size: 33
global size: 0
min size: 0
self stack: 0
global stack:0
size:20.00, time:14.485000, predicate:(true)
size:3.00, time:1.998000, predicate:(not inlined)
which makes it quite good inline candidate especially because the call appears
within what we consider an internal loop of bsR.
Apparently clang gets lucky here because it inlines more at copmile time and
spec_getc is housed in different translation unit.
[Bug middle-end/65449] -fstrict-volatile-bitfields affects volatile pointer dereference and produce wrong codes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65449 --- Comment #4 from ma.jiang at zte dot com.cn --- Hi Bernd, Thanks for your apply. (In reply to Bernd Edlinger from comment #3) Yes, but that is not the fault of the strict volatile code path any more. // Sure,I agree with you. The redundant read is another problem. In fact, it should be named as volatile pointer dereference produce redundant read. For bit-fields this redundant read is exactly what AAPCS demands: // Yes.I know that volatile bitfiled need the redundant read. That is why I thought there were connections between the redundant read and -fstrict-volatile-bitfields originally. IMO, the problem is this: In store_fixed_bit_field_1 we do not know if the access is on a packed structure member where the extra read is not necessary, or if we have a bit-field where the extra read would be mandatory, even if the complete container is overwritten. // I agree that the problem is caused by the store_fixed_bit_field_1.But,I disgree with you about three things.First,the redundant read should not appear if -fstrict-volatile-bitfields was off. Second, in store_fixed_bit_field_1 we can distinguish pointer dereference from structure member access(e.g.,MEM_EXPR(op0) will tell us whether op0 is a componet_ref or not, if MEM_P(op0) is true). Third, as gcc manual said -fstrict-volatile-bitfields :This option should be used if accesses to volatile bit-fields (or other structure fields, although the compiler usually honors those types anyway) should use a single access of the width of the field’s type, aligned to a natural alignment if possible., store_fixed_bit_field_1 does not need to distinguish bitfields from normal structure member. BTW: What happens in your example if you use -O0? Isn't there still an unaligned stw access? That's because you example is in a way invalid C. You can't set an int* to an unaligned address, it must be at least aligned to the GET_MODE_ALIGNMENT(SImode). //Yes, I know what you mean. Split access is a auxiliary fuction provided by compiler with the help of data analysis.As -O0 turn off all analysis , an unaligned stw is acceptable. And ,BTW, the C standard said nothing about unaligned access as I know. Could you show me something about it?
[Bug driver/65482] New: -mno-allow-movmisalign undocumented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65482 Bug ID: 65482 Summary: -mno-allow-movmisalign undocumented Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Some of the vectorization tests make use of the -mno-allow-movmisalign option (for example g++.dg/vect/slp-pr50819.cc). The option is not documented, either in the output of gcc -help -v or in the gcc manual, making it difficult to understand its effects on such tests.
[Bug fortran/64432] [5 Regression] SYSTEM_CLOCK(COUNT_RATE=rate) wrong result for integer(4)::rate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64432 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #39 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- Fixed on trunk. Thanks all for testing and suggestions.
[Bug ipa/65483] bzip2 bsR/bsW should be auto-inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65483 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added CC||rguenther at suse dot de --- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org --- The difference between 4.9 and 5.0 seems to be unrolling of the decoder loop and increased register pressure 4.9 does: 00406d60 bsR: 406d60: 8b 35 32 14 01 00 mov0x11432(%rip),%esi# 418198 bsLive 406d66: 53 push %rbx 406d67: 8b 05 27 14 01 00 mov0x11427(%rip),%eax# 418194 bsBuff 406d6d: 39 f7 cmp%esi,%edi 406d6f: 0f 8e f3 00 00 00 jle406e68 bsR+0x108 406d75: 48 63 05 20 14 01 00movslq 0x11420(%rip),%rax# 41819c bsStream 406d7c: 83 f8 03cmp$0x3,%eax 406d7f: 0f 8f 03 01 00 00 jg 406e88 bsR+0x128 406d85: 4c 8d 0c 40 lea(%rax,%rax,2),%r9 406d89: 49 c1 e1 03 shl$0x3,%r9 406d8d: 49 8d 91 c0 81 41 00lea0x4181c0(%r9),%rdx 406d94: 8b 4a 08mov0x8(%rdx),%ecx 406d97: 39 4a 04cmp%ecx,0x4(%rdx) 406d9a: 0f 8e c0 00 00 00 jle406e60 bsR+0x100 406da0: 44 8d 56 08 lea0x8(%rsi),%r10d 406da4: 89 fe mov%edi,%esi 406da6: 48 63 d9movslq %ecx,%rbx 406da9: 48 03 5a 10 add0x10(%rdx),%rbx 406dad: 8b 05 e1 13 01 00 mov0x113e1(%rip),%eax# 418194 bsBuff 406db3: 44 8d 59 01 lea0x1(%rcx),%r11d 406db7: 44 29 d6sub%r10d,%esi 406dba: 83 c6 07add$0x7,%esi 406dbd: 83 e6 08and$0x8,%esi 406dc0: 74 3e je 406e00 bsR+0xa0 406dc2: 45 89 d8mov%r11d,%r8d 406dc5: 44 89 5a 08 mov%r11d,0x8(%rdx) 406dc9: 44 0f b6 1b movzbl (%rbx),%r11d 406dcd: c1 e0 08shl$0x8,%eax 406dd0: 44 89 d6mov%r10d,%esi 406dd3: 44 89 15 be 13 01 00mov%r10d,0x113be(%rip)# 418198 bsLive 406dda: 44 09 d8or %r11d,%eax 406ddd: 44 39 d7cmp%r10d,%edi 406de0: 89 05 ae 13 01 00 mov%eax,0x113ae(%rip)# 418194 bsBuff 406de6: 0f 8e 7c 00 00 00 jle406e68 bsR+0x108 406dec: 41 83 c2 08 add$0x8,%r10d 406df0: 48 83 c3 01 add$0x1,%rbx 406df4: 44 39 42 04 cmp%r8d,0x4(%rdx) 406df8: 44 8d 59 02 lea0x2(%rcx),%r11d 406dfc: 7e 62 jle406e60 bsR+0x100 406dfe: 66 90 xchg %ax,%ax 406e00: 49 8d 91 c0 81 41 00lea0x4181c0(%r9),%rdx 406e07: c1 e0 08shl$0x8,%eax 406e0a: 44 89 d6mov%r10d,%esi 406e0d: 44 89 5a 08 mov%r11d,0x8(%rdx) 406e11: 0f b6 0bmovzbl (%rbx),%ecx 406e14: 44 89 15 7d 13 01 00mov%r10d,0x1137d(%rip)# 418198 bsLive 406e1b: 09 c8 or %ecx,%eax 406e1d: 44 39 d7cmp%r10d,%edi 406e20: 89 05 6e 13 01 00 mov%eax,0x1136e(%rip)# 418194 bsBuff 406e26: 7e 40 jle406e68 bsR+0x108 406e28: 44 39 5a 04 cmp%r11d,0x4(%rdx) 406e2c: 45 8d 42 08 lea0x8(%r10),%r8d 406e30: 41 8d 73 01 lea0x1(%r11),%esi 406e34: 7e 2a jle406e60 bsR+0x100 406e36: 89 72 08mov%esi,0x8(%rdx) 406e39: 0f b6 4b 01 movzbl 0x1(%rbx),%ecx 406e3d: c1 e0 08shl$0x8,%eax 406e40: 41 83 c2 10 add$0x10,%r10d 406e44: 41 83 c3 02 add$0x2,%r11d 406e48: 48 83 c3 02 add$0x2,%rbx 406e4c: 44 89 05 45 13 01 00mov%r8d,0x11345(%rip)# 418198 bsLive 406e53: 09 c8 or %ecx,%eax 406e55: 39 72 04cmp%esi,0x4(%rdx) 406e58: 89 05 36 13 01 00 mov%eax,0x11336(%rip)# 418194 bsBuff 406e5e: 7f a0 jg 406e00 bsR+0xa0 406e60: e8 3b 28 00 00 callq 4096a0 compressedStreamEOF 406e65: 0f 1f 00nopl (%rax) 406e68: 89 f1 mov%esi,%ecx 406e6a: 41 b9 01 00 00 00 mov$0x1,%r9d 406e70: 29 f9
[Bug lto/65475] [5 Regression] ICE in odr_vtable_hasher::equal (Segmentation fault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65475
--- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org ---
The following should help:
Index: ipa-devirt.c
===
--- ipa-devirt.c(revision 221528)
+++ ipa-devirt.c(working copy)
@@ -1412,9 +1412,18 @@ add_type_duplicate (odr_type val, tree t
if (!val-types_set)
val-types_set = new hash_settree;
+ /* Chose polymorphic type as leader (this happens only in case of ODR
+ violations. */
+ if ((TREE_CODE (type) == RECORD_TYPE TYPE_BINFO (type)
+polymorphic_type_binfo_p (TYPE_BINFO (type)))
+ (TREE_CODE (val-type) != RECORD_TYPE || !TYPE_BINFO (val-type)
+ || !polymorphic_type_binfo_p (TYPE_BINFO (val-type
+{
+ prevail = true;
+ build_bases = true;
+}
/* Always prefer complete type to be the leader. */
-
- if (!COMPLETE_TYPE_P (val-type) COMPLETE_TYPE_P (type))
+ else if (!COMPLETE_TYPE_P (val-type) COMPLETE_TYPE_P (type))
{
prevail = true;
build_bases = TYPE_BINFO (type);
[Bug rtl-optimization/64164] [4.9/5 Regression] one more stack slot used due to one less inlining level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164 --- Comment #22 from Jeffrey A. Law law at redhat dot com --- Let's try to stay focused. Killing copyrename seems like a fine thing to do as long as the resulting debug info is good. But that's independent of this BZ. I still find myself wondering if leaving the 0 instead of _10 in that PHI node is a reasonable approach. Certainly if I hack uncprop to leave things in that state, I get the code we want. And ISTM that uncprop ought to leave the constant alone if the SSA_NAME holding the constant conflicts with any of the other SSA_NAMEs in the PHI node that may potentially coalesce with the PHI result. That captures pretty well the case where the constant is better than an SSA_NAME. In this particular case, we have: # _28 = PHI 0(2), _29(3), _29(7), _10(8), _29(6) When _28 and _10 coalesce, the result then conflicts with _29 during IRA/LRA because of the extended lifetime of _10). Thus the annoying copies created by out-of-ssa can't be eliminated. WIth the proposed change, we'd instead have: # _28 = PHI 0(2), _29(3), _29(7), 0(8), _29(6) While we won't coalesce _28/_29 during out-of-ssa, LRA will see the copies and note that the associated pseudos don't conflict and ultimately assign them to the same hard register and the annoying copies are gone.
[Bug ipa/65483] bzip2 bsR/bsW should be auto-inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65483 --- Comment #1 from Jan Hubicka hubicka at gcc dot gnu.org --- Benchmarking build with -O3 -flto -Ofast -funroll-loops For mainline I get (running on input.graphic) real0m35.673s user0m35.556s sys 0m0.133s and setting early-inlining-insns=80 to get bsR/bsW inlined before we get LTO real0m31.975s user0m31.867s sys 0m0.124s -fno-ipa-cp: real0m34.232s user0m34.132s sys 0m0.117s For GCC 4.9 I get. real0m32.719s user0m32.615s sys 0m0.124s Oddly enought GCC 4.9 does not inlie bsR/bsW either.
[Bug testsuite/65484] New: FAIL: g++.dg/vect/pr36648.cc on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65484 Bug ID: 65484 Summary: FAIL: g++.dg/vect/pr36648.cc on powerpc64 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org The g++.dg/vect/pr36648.cc (a P1 4.3/4.4 regression) test fails on powerpc64: FAIL: g++.dg/vect/pr36648.cc -std=c++98 scan-tree-dump-times vect vectorized 1 loops 1 FAIL: g++.dg/vect/pr36648.cc -std=c++98 scan-tree-dump-times vect vectorizing stmts using SLP 1 ... The verbose runtest output shows the test is being compiled with the undocumented -mno-allow-movmisalign option (see pr65482): Executing on host: /build/gcc-5.0/gcc/testsuite/g++/../../xg++ -B/build/gcc-5.0/gcc/testsuite/g++/../../ /src/gcc-trunk-git/gcc/testsuite/g++.dg/vect/pr36648.cc ... -O2 -ftree-vectorize -fno-vect-cost-model -maltivec -mvsx -mno-allow-movmisalign -fdump-tree-vect-details ... -o ./pr36648.exe(timeout = 300) The .vect dump shows gcc decides not to vectorize the code because of an (apparently) unsupported unaligned store: $ grep -e vectorized -e vectorizing pr36648.cc.126t.vect /src/gcc-trunk-git/gcc/testsuite/g++.dg/vect/pr36648.cc:9:8: note: === vect_mark_stmts_to_be_vectorized === /src/gcc-trunk-git/gcc/testsuite/g++.dg/vect/pr36648.cc:9:8: note: not vectorized: unsupported unaligned store._14-x /src/gcc-trunk-git/gcc/testsuite/g++.dg/vect/pr36648.cc:18:14: note: vectorized 0 loops in function. The -mno-allow-movmisalign option likely gets added to the command line in check_vect_support_and_set_flags in lib/target-supports.exp. Since the pr36648 regression was about GCC generating incorrect code with -O3 (that led to the program crashing at runtime) and not about it necessarily being able to vectorize it, the use of the option seems questionable. It should be sufficient to verify that the test compiles and runs successfully to completion.
[Bug tree-optimization/65478] New: crafty performance regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478 Bug ID: 65478 Summary: crafty performance regression Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hubicka at gcc dot gnu.org As reported to me privately by Igor, crafty SPEC2k benchmark is slower since r219863 which decreased inline-unit-growth. I looked into the reason and it is the fact that we do not inline NextMove function. The function itself is big: Inline summary for NextMove/18 inlinable self time: 177 global time: 0 self size: 284 global size: 0 min size: 0 self stack: 0 global stack:0 size:228.00, time:150.114000, predicate:(true) size:3.00, time:2.00, predicate:(not inlined) size:4.00, time:0.649000, predicate:(op0 changed) size:4.00, time:5.946000, predicate:(op1 changed) size:2.00, time:1.486000, predicate:(op1 == 0) size:2.00, time:1.486000, predicate:(op1 != 0) One quite wrong estiamte I see is the following: switch (_45) default: L90, case 1: L0, case 2: L4, case 3: L35, case 4: L40, case 5: L43, case 6: L50, case 8: L51, case 9: L68, case 10: L92 freq:1.00 size: 20 time: 6 Accounting size:20.00, time:6.00 on predicate:(true) This assumes jump tree implementation of switch. We should discover dense switch statements and estimate the jumptable. The function overall is estimated as relatively uncool for inlining Considering NextMove/2405 with 284 size to be inlined into Search.constprop/4352 in unknown:-1 Estimated badness is -0.081348, frequency 0.69. Badness calculation for Search.constprop/4352 - NextMove/2405 size growth 273, time 174 inline hints: cross_module array_index -0.040674: guessed profile. frequency 0.694000, count 0 caller count 0 time w/o inlining 397.838000, time w inlining 386.734000 overall growth 277 (current) 0 (original) Adjusted by hints -0.081348 not inlinable: Search.constprop/4352 - NextMove/2405, --param inline-unit-growth limit reached I am not 100% sure what makes it interesting, though it sounds natural as it is part of the innermost loop. The function is called once, but because ipa-cp decides to clone Search function we turn it into function called twice: Estimating effects for Search/3356, base_time: 245. Estimating body: Search/3356 Known to be false: size:725 time:245 - estimates for value -32768 for param #0: time_benefit: 1, size: 725 Estimating body: Search/3356 Known to be false: op4 62, op4 changed size:707 time:242 - estimates for value 2 for param #4: time_benefit: 52, size: 707 Estimating body: Search/3356 Known to be false: size:725 time:245 - estimates for value 0 for param #5: time_benefit: 1, size: 725 Estimating body: Search/3356 Known to be false: size:725 time:245 - estimates for value 1 for param #5: time_benefit: 1, size: 725 Evaluating opportunities for Search/3356. - considering value 2 for param #4 (caller_count: 3) good_cloning_opportunity_p (time: 52, size: 707, freq_sum: 11298) - evaluation: 830, threshold: 500 Creating a specialized node of Search/3356.
[Bug target/65464] [4.8/4.9 Regression] disabling multilib support for powerpc64le-linux-gnu breaks kernel builds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65464 --- Comment #7 from Alan Modra amodra at gmail dot com --- On x86_64-linux you can run 32-bit binaries. On powerpc64le-linux you can't. It's that simple. -m32 support in powerpc64le gcc, by default, doesn't make sense until we have - supported and tested compat layer in the kernel - supported and tested gcc, binutils and glibc We might even want to change the 32-bit ABI for powerpcle. The change I made wasn't just to be able to omit --disable-multilib. It was also to fix the wrong default of enabling -m32 support in powerpc64le gcc. Another data point: llvm doesn't support -m32
[Bug target/65456] powerpc64le autovectorized copy loop missed optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65456 --- Comment #7 from Anton Blanchard anton at samba dot org --- Thanks Martin. Bill: the swaps pass isn't catching our vectorised copy, I guess because of the adds in the loop: lxvd2x 0,9,4 addi 28,1,-48 add 6,9,10 xxpermdi 12,0,0,2 xxpermdi 12,12,12,2 stxvd2x 12,0,28
[Bug c/65466] Unnecessary source line output for note: each undeclared identifier is reported only once
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65466 --- Comment #4 from joseph at codesourcery dot com joseph at codesourcery dot com --- On Thu, 19 Mar 2015, manu at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65466 --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to jos...@codesourcery.com from comment #2) On Thu, 19 Mar 2015, manu at gcc dot gnu.org wrote: (If I was re-doing that patch again, I will try to overload inform(), because inform_with_flags is just too much typing). Note that diagnostic functions cannot be overloaded in a way that means different functions with the same name have the msgid argument in different positions, as that breaks exgettext. Ah, yes, I forgot about this. We had this problem already in the Fortran FE. Can exgettext be fixed to handle overloads eventually? Perhaps someone could reimplement it as a GCC plugin. That would be a nice GSoC! exgettext (which essentially just computes arguments to pass to xgettext from GNU gettext) needs to handle sources that are not part of the current configuration, including inside disabled #if conditionals. That is, the sources parsed by the compiler compiling any particular build of GCC are not the full set of sources that need to be handled to generate gcc.pot.
[Bug ipa/65465] [5 Regression] Internal compiler error: in build2_stIat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65465 --- Comment #6 from Martin Liška marxin at gcc dot gnu.org --- Author: marxin Date: Thu Mar 19 17:35:52 2015 New Revision: 221518 URL: https://gcc.gnu.org/viewcvs?rev=221518root=gccview=rev Log: Fix for PR ipa/65465. PR ipa/65465 * cgraphunit.c (cgraph_node::create_wrapper): Correctly reset all fields of cgraph_thunk_info. * g++.dg/ipa/pr65465.C: New test. Added: trunk/gcc/testsuite/g++.dg/ipa/pr65465.C Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c trunk/gcc/testsuite/ChangeLog
[Bug lto/65380] [5 Regression][ICF] LTO: ICE in add_symbol_to_partition_1, at lto/lto-partition.c:158
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65380 Martin Liška marxin at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #16 from Martin Liška marxin at gcc dot gnu.org --- Fixed in 5.0.0.
[Bug c++/65046] [5 regression] -Wabi-tag doesn't warn about variables or function return types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65046 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Thu Mar 19 19:31:48 2015 New Revision: 221521 URL: https://gcc.gnu.org/viewcvs?rev=221521root=gccview=rev Log: PR c++/65046 Automatically propagate ABI tags to variables and functions from their (return) type. * class.c (check_tag): Handle variables and functions. (mark_or_check_attr_tags): Split out from find_abi_tags_r. (mark_or_check_tags): Likewise. (mark_abi_tags): Use it. Rename from mark_type_abi_tags. (check_abi_tags): Add single argument overload for decls. Handle inheriting tags for decls. * mangle.c (write_mangled_name): Call it. (mangle_return_type_p): Split out from write_encoding. (unmangled_name_p): Split out from write_mangled_name. (write_mangled_name): Ignore abi_tag on namespace. * cp-tree.h (NAMESPACE_IS_INLINE): Replace NAMESPACE_ABI_TAG. * parser.c (cp_parser_namespace_definition): Set it. * name-lookup.c (handle_namespace_attrs): Use arguments. Warn about abi_tag attribute on non-inline namespace. * tree.c (check_abi_tag_args): Split out from handle_abi_tag_attribute. (handle_abi_tag_attribute): Allow tags on variables. Added: trunk/gcc/testsuite/g++.dg/abi/abi-tag14.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/mangle.c trunk/gcc/cp/name-lookup.c trunk/gcc/cp/parser.c trunk/gcc/cp/tree.c trunk/gcc/doc/extend.texi trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/g++.dg/abi/abi-tag1.C trunk/gcc/testsuite/g++.dg/abi/abi-tag4.C trunk/gcc/testsuite/g++.dg/abi/abi-tag8.C trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/locale/gnu/messages_members.cc trunk/libstdc++-v3/include/bits/c++config trunk/libstdc++-v3/src/c++11/cxx11-shim_facets.cc
[Bug c++/59739] missed optimization: attribute ((pure)) could be honored more often
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59739 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-19 CC||rguenther at suse dot de Ever confirmed|0 |1 --- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org --- Confirmed. Actually I think this is more for Richard. The issues here is, I blieve, the fact that non-gimple-register return values are consiered to be stores that invalidate the memory context. It is FRE1 that does the optimization.
[Bug lto/65475] [5 Regression] ICE in odr_vtable_hasher::equal (Segmentation fault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65475 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-19 CC||hubicka at gcc dot gnu.org Assignee|hubicka at ucw dot cz |hubicka at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org --- Mine. The type1 should not be in the vtable hash. I suppose it is an issue with merging non-polymorphic and polymorphic type over ODR violation.
[Bug libstdc++/65470] regex_search corrupts matches when haystack is destroyed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65470 --- Comment #5 from Daniel Krügler daniel.kruegler at googlemail dot com --- (In reply to aral from comment #3) I don't argue that it might be a misunderstanding of the user, hence my suggestion 1) - however, I disagree with your wording clearly documented as far as (a) http://en.cppreference.com/w/cpp/regex/regex_search and (b) http://www.cplusplus.com/reference/regex/regex_search/ are concerned. I could not find any clear statement on c++ official language reference with a google search. Is (a) official? No, neither (a) nor (b) are official C++ Standard specifications. A relevant one would be ISO/IEC 14882:2011 for C++11 for example. The Standard itself is no text book, so your definition of clarity does need to be reflected by that. See e.g. the link provided on https://isocpp.org/std/the-standard to retrieve it or as an approximation to the official document refer to the current working *draft* that can be found here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf But all this exceeds the responsibility for this bug tracking system. You could probably request an enhancement of the libstdc++ documentation, but I believe that a priority of P3 major is not an appropriate one for this.
[Bug c++/65046] [5 regression] -Wabi-tag doesn't warn about variables or function return types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65046 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- Fixed.
[Bug ada/65476] New: Long_Float array does not byte swap correctly when set to Scalar_Storage_Order with High Order First
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65476 Bug ID: 65476 Summary: Long_Float array does not byte swap correctly when set to Scalar_Storage_Order with High Order First Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: daniel.merrill at psware dot com CC: ebotcazou at gcc dot gnu.org Created attachment 35067 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35067action=edit code to reproduce the issue. When an array of Long_Floats is set to a scalar_storage_order of High_Order_First, only the two 32 bit words that make up the 64 bit value are swapped with each other but the bytes under those words are not swapped properly. Attached is a simple program that reproduces the behavior. If you examine the stored values you could get the right value by performing a byte swap on the underlying 32 bit value.
