[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=35061&action=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 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 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 --- Patch at [1]. [1] https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00975.html
[Bug c/65455] typeof _Atomic fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455 --- Comment #11 from Jens Gustedt --- (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 sanitizer/65400] tsan mis-compiles inlineable C functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65400 --- Comment #10 from Jakub Jelinek --- Author: jakub Date: Thu Mar 19 07:53:38 2015 New Revision: 221508 URL: https://gcc.gnu.org/viewcvs?rev=221508&root=gcc&view=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 sanitizer/64265] [5 Regression] r217669 broke tsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64265 --- Comment #27 from Jakub Jelinek --- Author: jakub Date: Thu Mar 19 07:55:22 2015 New Revision: 221509 URL: https://gcc.gnu.org/viewcvs?rev=221509&root=gcc&view=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/65455] typeof _Atomic fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #12 from Marek Polacek --- What does clang differently wrt _Generic?
[Bug c/65455] typeof _Atomic fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455
--- Comment #13 from Jens Gustedt ---
(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/65455] typeof _Atomic fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455 --- Comment #14 from Jens Gustedt --- 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 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 --- This is fixed in 4.8.3.
[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 changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Paolo Carlini --- Not a bug. By the way EDG and clang reject the testcase with the same diagnostic.
[Bug c++/59760] use_thunk internal error on default destructor declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59760 Paolo Carlini changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Paolo Carlini --- 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 changed: What|Removed |Added CC||sshannin at gmail dot com --- Comment #3 from Paolo Carlini --- *** Bug 59760 has been marked as a duplicate of this bug. ***
[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 --- Mainline properly rejects this. I'm adding the testcase and closing the bug.
[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 --- Author: paolo Date: Thu Mar 19 08:57:01 2015 New Revision: 221510 URL: https://gcc.gnu.org/viewcvs?rev=221510&root=gcc&view=rev Log: 2015-03-19 Paolo Carlini 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 c++/59686] Non-constexpr pointers accepted in constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59686 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #4 from Paolo Carlini --- Done.
[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 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++/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 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 changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-19 Ever confirmed|0 |1 --- Comment #2 from Paolo Carlini --- It's C++14 now.
[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 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 --- Mine.
[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 c++/59739] missed optimization: attribute ((pure)) could be honored more often
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59739 Paolo Carlini changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #2 from Paolo Carlini --- CC-ing Honza
[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 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 --- Thus confirmed.
[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 changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Paolo Carlini --- *** 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 changed: What|Removed |Added CC||ignoreddropbox at gmail dot com --- Comment #4 from Paolo Carlini --- *** Bug 60180 has been marked as a duplicate of this bug. ***
[Bug ipa/65465] [5 Regression] Internal compiler error: in build2_stIat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65465 Richard Biener 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 --- 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") 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) so it looks like we build bogus thunks or perform bogus merges.
[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 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 c/65455] typeof _Atomic fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #15 from Jakub Jelinek --- 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;
:
_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 ;
else
goto ;
:
# a_3 = PHI <0(2)>
# i_24 = PHI
# _21 = PHI <_26(2)>
:
# a_12 = PHI
# i_5 = PHI
# _29 = PHI <_21(3), _11(6)>
:
# a_1 = PHI
# i_4 = PHI
a_13 = a_1 + i_4;
i_14 = i_4 + 1;
if (i_14 < _29)
goto ;
else
goto ;
:
_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 ;
else
goto ;
:
pretmp_35 = (unsigned int) a_13;
:
# prephitmp_36 = PHI
_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 --- 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 --- (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 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;
:
_3 = __builtin_omp_get_num_threads ();
i_4 = __builtin_omp_get_thread_num ();
if (i_4 <= 9)
goto ;
else
goto ;
:
# a_5 = PHI <0(2)>
# i_2 = PHI
:
# a_18 = PHI
# i_21 = PHI
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 ;
else
goto ;
:
pretmp_14 = (unsigned int) a_7;
:
# prephitmp_22 = PHI
_10 = &.omp_data_i_9(D)->a;
__atomic_fetch_add_4 (_10, prephitmp_22, 0); [tail call]
return;
}
...
[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 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 --- 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 --- 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 ipa/65465] [5 Regression] Internal compiler error: in build2_stIat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65465 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- I'll try to reduce this. -fno-ipa-icf works.
[Bug sanitizer/65400] [5 Regression] tsan mis-compiles inlineable C functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65400 Jakub Jelinek 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 --- 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 --- Author: jakub Date: Thu Mar 19 10:12:34 2015 New Revision: 221512 URL: https://gcc.gnu.org/viewcvs?rev=221512&root=gcc&view=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 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=221511&root=gcc&view=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 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 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 changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #3 from Paolo Carlini --- This is fixed for 5.0.
[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=35062&action=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 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 --- (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 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 changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #3 from Markus Trippelsdorf --- 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 #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++/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 changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Paolo Carlini --- Closing.
[Bug c/65455] typeof _Atomic fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65455 --- Comment #16 from Jens Gustedt --- (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 --- 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++/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 changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Paolo Carlini --- Dup then. *** This bug has been marked as a duplicate of bug 50025 ***
[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 changed: What|Removed |Added CC||andreaskem at web dot de --- Comment #25 from Paolo Carlini --- *** Bug 60583 has been marked as a duplicate of this bug. ***
[Bug c++/56636] strange interaction of dynamic_cast and unique_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56636 Paolo Carlini changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #5 from Paolo Carlini --- 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 #17 from Marek Polacek --- (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 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=35063&action=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
#include
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 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 c++/56636] strange interaction of dynamic_cast and unique_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56636 Kai Tietz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #6 from Kai Tietz --- 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 #1 from Paolo Carlini --- 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 --- Comment #2 from 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=221513&root=gcc&view=rev Log: 2015-03-19 Paolo Carlini PR c++/52659 * g++.dg/cpp0x/deleted11.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/deleted11.C Modified: trunk/gcc/testsuite/ChangeLog
[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 changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #3 from Paolo Carlini --- Done.
[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 --- 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 #9 from Jakub Jelinek --- 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 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 --- 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; : 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 #11 from Richard Biener --- Created attachment 35064 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35064&action=edit patch I am testing the attached, testcases to be ameded from the dups.
[Bug preprocessor/8270] [4.8/4.9/5 Regression] back-slash white space newline with comments, no warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8270
Kai Tietz changed:
What|Removed |Added
CC||ktietz at gcc dot gnu.org
--- Comment #55 from Kai Tietz ---
Well, by looking into the standard ISO/IEC 9899:TC3 I found the following
statement:
5.1.12 Translation phase
"2. Each instance of a backslash character (\) immediately followed by a
new-line
character is deleted, splicing physical source lines to form logical source
lines.
Only the last backslash on any physical source line shall be eligible for being
part of such a splice. A source file that is not empty shall end in a new-line
character, which shall not be immediately preceded by a backslash character
before any such splicing takes place."
For ISO/IEC 14882:2003 we see at topic "2 Lexical Convention"
"2 Each instance of a new-line character and an immediately preceding backslash
character is deleted, splicing physical source lines to form logical source
lines. If, as a result, a character sequence that matches the syntax of a
universal-character-name is produced, the behavior is undefined. If a source
file that is not empty does not end in a new-line character, or ends in a
new-line character immediately preceded by a backslash character, the behavior
is undefined."
So the handling of backslash whitespace newline is clearly a gnu-extension and
not part of the standard.
I suggest something like this patch for fixing standard-requirement.
Additionally we could check here for cpp_option lang being gnu-style for
allowing 'backslash,whitespaces,newling' too.
Index: lex.c
===
--- lex.c (Revision 221514)
+++ lex.c (Arbeitskopie)
@@ -896,6 +896,11 @@ _cpp_clean_line (cpp_reader *pfile)
p--;
if (p - 1 != pbackslash)
goto done;
+ if (p != d)
+ {
+ ++p;
+ goto done;
+ }
/* Have an escaped newline; process it and proceed to
the slow path. */
@@ -917,13 +922,19 @@ _cpp_clean_line (cpp_reader *pfile)
if (s == buffer->rlimit)
break;
- /* Escaped? */
+ /* Escaped?
+But make sure it isn't a backslash followed by a
+whitespace. */
p = d;
while (p != buffer->next_line && is_nvspace (p[-1]))
p--;
if (p == buffer->next_line || p[-1] != '\\')
break;
-
+ if (p != d)
+ {
+ ++p;
+ break;
+ }
add_line_note (buffer, p - 1, p != d ? ' ': '\\');
d = p - 2;
buffer->next_line = p - 1;
[Bug target/65459] SLOW_UNALIGNED_ACCESS unconditionally set to 1 for ARM targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65459
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
--- Comment #2 from ktkachov at gcc dot gnu.org ---
FWIU ARMv6 and later supports unaligned accesses.
I guess the performance of unaligned accesses differs between cores.
The documentation for SLOW_UNALIGNED_ACCESS says:
"Define this macro to be the value 1 if memory accesses described by the
@var{mode} and @var{alignment} parameters have a cost many times greater
than aligned accesses, for example if they are emulated in a trap
handler."
It seems to me that on some modern cores even if unaligned access is more
expensive than normal it wouldn't be 'many times greater' so we should
definitely investigate setting this in a more intelligent way.
[Bug middle-end/63155] [4.9/5 Regression] memory hog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155 --- Comment #10 from Richard Biener --- Author: rguenth Date: Thu Mar 19 13:36:18 2015 New Revision: 221515 URL: https://gcc.gnu.org/viewcvs?rev=221515&root=gcc&view=rev Log: 2015-03-19 Richard Biener Revert 2015-03-10 Richard Biener PR middle-end/63155 * tree-ssa-coalesce.h (verify_ssa_coalescing): Declare. * tree-ssa-coalesce.c: Include timevar.h. (attempt_coalesce): Handle graph being NULL. (coalesce_partitions): Call verify_ssa_coalescing if ENABLE_CHECKING. Split out abnormal coalescing to ... (perform_abnormal_coalescing): ... this function. (coalesce_ssa_name): Perform abnormal coalescing without computing live/conflict. (verify_ssa_coalescing_worker): New function. (verify_ssa_coalescing): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-coalesce.c trunk/gcc/tree-ssa-coalesce.h
[Bug middle-end/63155] [4.9/5 Regression] memory hog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155 Richard Biener changed: What|Removed |Added Known to work|5.0 | Summary|[4.9 Regression] memory hog |[4.9/5 Regression] memory ||hog Known to fail||5.0 --- Comment #9 from Richard Biener --- Reverted.
[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 #3 from Bernd Edlinger --- Yes, but that is not the fault of the strict volatile code path any more. For bit-fields this redundant read is exactly what AAPCS demands: "7.1.7.5 Volatile bit - fields preserving number and width of container accesses When a volatile bit-field is read, its container must be read exactly once using the access width appropriate to the type of the container. When a volatile bit-field is written, its container must be read exactly once and written exactly once using the access width appropriate to the type of the container. The two accesses are not atomic." 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. 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).
[Bug c/65471] New: type interpretation in _Generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65471
Bug ID: 65471
Summary: type interpretation in _Generic
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.gustedt at inria dot fr
This is a bug marker for an underspecification in the C11 standard, that has
been observed in DR#423
http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm#dr_423
gcc and clang went quite opposite ways to resolve that issue, resulting in
severe incompatibility for _Generic expression that use qualifiers or arrays.
The following six lines illustrate the problem
char const* a = _Generic("bla", char*: "blu"); // clang error
char const* b = _Generic("bla", char[4]: "blu"); // gcc error
char const* c = _Generic((int const){ 0 }, int: "blu");// clang error
char const* d = _Generic((int const){ 0 }, int const: "blu"); // gcc error
char const* e = _Generic(+(int const){ 0 }, int: "blu"); // both ok
char const* f = _Generic(+(int const){ 0 }, int const: "blu"); // both error
the last two lines, where gcc and clang agree, points to the nature of the
problem: gcc treats all such expressions as rvalues, clang as lvalues.
[Bug c++/65457] ICE in libgfortran/ieee/ieee_arithmetic.F90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65457 Bernd Edlinger changed: What|Removed |Added Target||arm-linux-gnueabihf Component|fortran |c++ Host||arm-linux-gnueabihf Build||arm-linux-gnueabihf --- Comment #3 from Bernd Edlinger --- The problem is in the C compiler: arm-linux-gnueabihf-g++ -c -g -O2 -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc-5-20150315/gcc -I../../gcc-5-20150315/gcc/. -I../../gcc-5-20150315/gcc/../include -I../../gcc-5-20150315/gcc/../libcpp/include -I/home/ed/gnu/gcc-build-arm-linux-gnueabihf-cross/./gmp -I/home/ed/gnu/gcc-5-20150315/gmp -I/home/ed/gnu/gcc-build-arm-linux-gnueabihf-cross/./mpfr -I/home/ed/gnu/gcc-5-20150315/mpfr -I/home/ed/gnu/gcc-5-20150315/mpc/src -I../../gcc-5-20150315/gcc/../libdecnumber -I../../gcc-5-20150315/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc-5-20150315/gcc/../libbacktrace -I/home/ed/gnu/gcc-build-arm-linux-gnueabihf-cross/./isl/include -I/home/ed/gnu/gcc-5-20150315/isl/include -o tree-cfg.o -MT tree-cfg.o -MMD -MP -MF ./.deps/tree-cfg.TPo ../../gcc-5-20150315/gcc/tree-cfg.c -save-temps results in this wrong code: .loc 7 3334 0 mov r3, ip ... .loc 7 3334 0 movtr3, #:upper16:tree_code_length str r3, [sp, #8] ... but "ip" is undefined, and thus the inlined version of tree_operand_check accesses something completely wrong instead of tree_code_length.
[Bug c++/63356] Compilation failure where clang does not have problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63356 Jason Merrill changed: What|Removed |Added Status|WAITING |NEW --- Comment #16 from Jason Merrill --- Taking this bug out of WAITING; I don't know why it was there.
[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 #5 from Matthias Klose --- > 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? $ gcc -m32 -c foo.c foo.c:1:0: error: -m32 not supported in this configuration well, it is different, and this doesn't work on 4.8, 4.9 and 5 anymore.
[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 #6 from Markus Trippelsdorf --- (In reply to Matthias Klose from comment #5) > > 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? > > $ gcc -m32 -c foo.c > foo.c:1:0: error: -m32 not supported in this configuration > > well, it is different, and this doesn't work on 4.8, 4.9 and 5 anymore. I agree with you. The question was directed to Alan.
[Bug c++/62255] [4.8/4.9 Regression] Introducing an unrelated template parameter causes compilation to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62255 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|4.8.5 |4.9.3 --- Comment #13 from Jason Merrill --- Fixed for 4.9.3/5.
[Bug middle-end/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 Component|target |middle-end --- Comment #19 from ktkachov at gcc dot gnu.org --- Change component
[Bug ipa/65465] [5 Regression] Internal compiler error: in build2_stIat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65465 --- Comment #4 from Martin Liška --- Patch I've been testing: diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c index e640907..8b7d056 100644 --- a/gcc/cgraphunit.c +++ b/gcc/cgraphunit.c @@ -2484,8 +2484,9 @@ cgraph_node::create_wrapper (cgraph_node *target) /* Turn alias into thunk and expand it into GIMPLE representation. */ definition = true; + + memset (&thunk, 0, sizeof(cgraph_thunk_info)); thunk.thunk_p = true; - thunk.this_adjusting = false; create_edge (target, NULL, count, CGRAPH_FREQ_BASE); tree arguments = DECL_ARGUMENTS (decl); -- Martin
[Bug fortran/64787] Invalid code on sourced allocation of class(*) character string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64787 vehre at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #3 from vehre at gcc dot gnu.org --- Fix available with: https://gcc.gnu.org/ml/fortran/2015-03/msg00074.html https://gcc.gnu.org/ml/fortran/2015-03/msg00075.html https://gcc.gnu.org/ml/fortran/2015-03/msg00085.html
[Bug fortran/55901] [OOP] type is (character(len=*)) misinterpreted as array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55901 vehre at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING CC||vehre at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |vehre at gcc dot gnu.org --- Comment #14 from vehre at gcc dot gnu.org --- Fix available with: https://gcc.gnu.org/ml/fortran/2015-03/msg00074.html https://gcc.gnu.org/ml/fortran/2015-03/msg00075.html https://gcc.gnu.org/ml/fortran/2015-03/msg00085.html and https://gcc.gnu.org/ml/fortran/2015-03/msg00086.html
[Bug fortran/57456] [OOP] CLASS + CHARACTER ALLOCATE with typespec: For arrays, the typespec is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57456 vehre at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #5 from vehre at gcc dot gnu.org --- Remain issue should be fixed with: https://gcc.gnu.org/ml/fortran/2015-03/msg00074.html https://gcc.gnu.org/ml/fortran/2015-03/msg00075.html https://gcc.gnu.org/ml/fortran/2015-03/msg00085.html
[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 --- Comment #5 from vehre at gcc dot gnu.org --- Fix available with: https://gcc.gnu.org/ml/fortran/2015-03/msg00074.html https://gcc.gnu.org/ml/fortran/2015-03/msg00075.html https://gcc.gnu.org/ml/fortran/2015-03/msg00085.html
[Bug middle-end/65472] New: -Wunreachable-code failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65472
Bug ID: 65472
Summary: -Wunreachable-code failure
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: skvadrik at gmail dot com
Created attachment 35065
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35065&action=edit
1.c
Given the following code:
extern void f ();
void g ()
{
for (;;)
{
f ();
continue;
f ();
}
}
$ gcc -Wunreachable-code -c 1.c
$ clang -Wunreachable-code -c 1.c
1.c:9:3: warning: code will never be executed [-Wunreachable-code]
f ();
^
1 warning generated.
[Bug middle-end/65472] -Wunreachable-code failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65472 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- -Wunreachable-code does nothing and is ignored.
[Bug middle-end/65472] -Wunreachable-code failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65472 --- Comment #2 from Ulya --- $ gcc -W -Wall -Wextra -c 1.c gives the same result: no warning
[Bug libstdc++/65473] New: Including does not define __GLIBCXX__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65473 Bug ID: 65473 Summary: Including does not define __GLIBCXX__ Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com Hi, One would expect that including _any_ header from the standard library defines the relevant detection macros. For example, I usually include the header to check for libc++ (per http://goo.gl/eXNYJH). However, libstdc++'s headers do not always define those detection macros. Regards, Louis Dionne
[Bug middle-end/65472] -Wunreachable-code failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65472 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Marek Polacek --- Yes, the warning has been removed altogether. -Wunreachable-code is retained only for backwards compatibility.
[Bug middle-end/65472] -Wunreachable-code failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65472 Ulya changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #4 from Ulya --- So GCC's intended behavior is not to warn about unreachable code?
[Bug c++/46476] Missing Warning about unreachable code after return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46476 Manuel López-Ibáñez changed: What|Removed |Added CC||skvadrik at gmail dot com --- Comment #5 from Manuel López-Ibáñez --- *** Bug 65472 has been marked as a duplicate of this bug. ***
[Bug middle-end/65472] -Wunreachable-code failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65472 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org Resolution|FIXED |DUPLICATE --- Comment #5 from Manuel López-Ibáñez --- (In reply to Ulya from comment #4) > So GCC's intended behavior is not to warn about unreachable code? No, but the previous implementation of Wunreachable-code was very broken and nobody knew how to fix it, thus it was eventually removed. Since then (years ago!), nobody has offered a new implementation, which perhaps shows that there is actually little interest in this warning in practice. In the past, we got more reports about Wunreachable-code bogus warnings than about missed ones. Unfortunately, there are very few GCC developers working on the C/C++ FEs right now and they are very busy with other more urgent things, like structural work and updating to new standards. In addition, implementing this properly in the FE would need some kind of control-flow graph, which GCC only has in the middle-end. BTW, I don't think it is useful to close these reports as INVALID, since they are in essence requests for a new implementation of -Wunreachable-code. On the other hand, it is not useful to have a PR for each possible testcase, since as far as we know, there is no one even planning to work on this, unfortunately. *** This bug has been marked as a duplicate of bug 46476 ***
[Bug middle-end/65472] -Wunreachable-code failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65472 Ulya changed: What|Removed |Added Resolution|DUPLICATE |FIXED --- Comment #6 from Ulya --- (In reply to Manuel López-Ibáñez from comment #5) I see. Thank you for a detailed answer. :)
[Bug ipa/65465] [5 Regression] Internal compiler error: in build2_stIat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65465
--- Comment #5 from Jakub Jelinek ---
Reduced testcase:
struct A {};
struct B { virtual A foo () const; };
struct C { A foo () const; };
struct D : virtual B { A foo () const {} };
struct F : D { virtual int bar () const; };
int F::bar () const { return 0; }
A C::foo () const { return A (); }
[Bug c/17534] gcc fails to diagnose suspect expressions that have incompatible bit masks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17534 Manuel López-Ibáñez changed: What|Removed |Added CC||d.g.gorbachev at gmail dot com --- Comment #9 from Manuel López-Ibáñez --- *** Bug 46582 has been marked as a duplicate of this bug. ***
[Bug c/46582] No warning is given about always false condition and unreachable code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46582 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Manuel López-Ibáñez --- Probably a duplicate. *** This bug has been marked as a duplicate of bug 17534 ***
[Bug middle-end/65472] -Wunreachable-code failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65472 Manuel López-Ibáñez changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #7 from Manuel López-Ibáñez --- Please don't change the status of the PR. *** This bug has been marked as a duplicate of bug 46476 ***
[Bug c++/46476] Missing Warning about unreachable code after return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46476 --- Comment #6 from Manuel López-Ibáñez --- *** Bug 65472 has been marked as a duplicate of this bug. ***
[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 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-19 CC||manu at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Manuel López-Ibáñez --- I implemented some finer-control for the caret in https://gcc.gnu.org/ml/gcc-patches/2012-04/msg01836.html that specifically fixed this case. However, I never got around to get it approved and committed it. Please, feel free to take that patch and get it reviewed and committed. (If I was re-doing that patch again, I will try to overload inform(), because inform_with_flags is just too much typing).
[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 --- Comment #4 from Jason Merrill --- So what's happening here is that the compiler sees that *m is a Derived, so it can devirtualize the destructor call to ~Derived, and ~Derived refers to the vtable. One solution would be to give ~Derived default visibility and move its definition out of line. But calls to virt_func would probably produce direct calls and thus undefined symbol errors as well. It seems like your code is designed for calling through the vtable, and devirtualization breaks that design, so turning off devirtualization is the right approach. It might be possible to make the compiler more clever about recognizing patterns that don't work well with devirtualization and automatically suppressing it in such cases. Such as, in this case, seeing explicit default visibility on a constructor.
[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 --- Author: marxin Date: Thu Mar 19 17:35:52 2015 New Revision: 221518 URL: https://gcc.gnu.org/viewcvs?rev=221518&root=gcc&view=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 tree-optimization/64715] [5 Regression] __builtin_object_size (..., 1) fails to locate subobject
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64715
--- Comment #12 from Jakub Jelinek ---
For the early objsz pass, I'm afraid it can have security implications.
Artificial testcase:
extern char *strcpy (char *__restrict __dest, const char *__restrict __src)
__attribute__ ((__nothrow__ , __leaf__)) __attribute__ ((__nonnull__ (1, 2)));
extern __inline __attribute__ ((__always_inline__)) __attribute__
((__gnu_inline__)) __attribute__ ((__artificial__)) char *
__attribute__ ((__nothrow__ , __leaf__)) strcpy (char *__restrict __dest, const
char *__restrict __src)
{
return __builtin___strcpy_chk (__dest, __src, __builtin_object_size (__dest,
2 > 1));
}
const char *str1 = "JIHGFEDCBA";
int
main ()
{
struct A { char buf1[9]; char buf2[1]; } a;
char *p = a.buf1;
char *q = p + 1;
char *r = q + 3;
char *t = r;
if (r != &a.buf1[4])
t = (char *) &a;
strcpy (t, str1 + 5);
return 0;
}
with the early objsz this will use 10 for __bos rather than 5, so will not
detect the buffer overflow.
So, if we want to go forward with that, perhaps:
1) the first instance should (also for performance reasons) only try to deal
with __bos calls where the second argument is 1 or 3, and leave 0 and 2 alone
for the second objsz pass
2) maybe instead of folding the __bos call into constant, it should turn it
into
MIN_EXPR <__bos, XX> where XX would be the value computed by the pass (for
__bos (, 3) MAX_EXPR). That way, we'd use the smaller value of the two passes.
[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 --- Comment #15 from Martin Liška --- Author: marxin Date: Thu Mar 19 17:37:15 2015 New Revision: 221519 URL: https://gcc.gnu.org/viewcvs?rev=221519&root=gcc&view=rev Log: Fix PR ipa/65380. PR ipa/65380 * ipa-icf.c (sem_function::merge): Do not merge DECL_EXTERNAL symbols. (sem_variable::merge): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-icf.c
[Bug ipa/65465] [5 Regression] Internal compiler error: in build2_stIat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65465 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Martin Liška --- Fixed in 5.0.0.
[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 changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #16 from Martin Liška --- Fixed in 5.0.0.
[Bug tree-optimization/65303] Tracking bug for ICF issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65303 Bug 65303 depends on bug 65380, which changed state. Bug 65380 Summary: [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 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
