[Bug middle-end/71762] [5/6/7 Regression] ~X & Y to X < Y doesn't work for uninitialized values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71762 --- Comment #8 from rguenther at suse dot de --- On Wed, 9 Nov 2016, law at redhat dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71762 > > Jeffrey A. Law changed: > >What|Removed |Added > > CC||law at redhat dot com > > --- Comment #7 from Jeffrey A. Law --- > ISTM the transformation is valid on gimple, but that at RTL expansion time we > don't guarantee the range of the uninitialized object is [01]. And yes, if we > have to insert truncations this transformation becomes a lose. > > One approach would be something similar to the unswitching on an uninitialized > value fix that I need to get back to -- ensure the values are initialized and > if they aren't, don't allow the transformation. > > I wouldn't be surprised if there are other places where using type/vrp > information on a sub-word sized object that is uninitialized is going to cause > problems. I think RTL expansion is conservative in inserting truncations whenever necessary, see the reduce_bit_field handling in expand_expr. So the issue will appear only if defs (or no defs!) appear outside the scope of expand_expr. Which for this particular case means we have to expand unsigned default-defs to have zero bits outsize of their precision. > I don't think losing the transformations would be that big of a deal either. > My recollection is they definitely triggered in GCC itself, but I don't have a > sense of how often. I'll see if I can work out sth reasonable along the above lines.
[Bug c++/78283] -Wc++1z-compat warning is sticky
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78283 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug c++/78282] [6/7 Regression] Overload resolution failure, in parameter pack expansion, inside a template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78282 Richard Biener changed: What|Removed |Added Keywords||rejects-valid Target Milestone|--- |6.3
[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267 --- Comment #13 from Maxim Ostapenko --- (In reply to Rainer Orth from comment #11) > (In reply to Jakub Jelinek from comment #5) > > extern char **environ; > > #endif > > > > -#if defined(__has_include) && __has_include() > > +#if defined(__has_include) && __has_include() && > > defined(__clang__) > > #define SANITIZER_OS_TRACE 1 > > #include > > #else > > > > is preapproved if it works. > > I'd use fixincludes instead to wrap the two offending declarations in > > with #ifdef __BLOCKS__. > > This is a macOS bug, actually: many other places using the Blocks extension > already wrap them correctly. > > I've filed Bug 29184470 uses Blocks extension unconditionally > for > this. > > Rainer The fixincludes fix looks cleaner, but it's harder to me to cook a patch because: 1) I have no experience with fixincludes. 2) I have no Darwin machine to test the fix. I can try fixincludes anyway, but this may take some time. But if the issue is urgent, can we try to ifdef out and ? There isn't much lost in functionality, corresponding code reflects to printing sanitizer logs into syslog on Darwin.
[Bug c++/78286] New: typename, type members and non-type members: code should be rejected, but it is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78286
Bug ID: 78286
Summary: typename, type members and non-type members: code
should be rejected, but it is not
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: michele.caini at gmail dot com
Target Milestone: ---
Consider the following code:
struct S {
struct foo {};
foo foo;
};
int main() {
typename S::foo t;
(void) t;
}
GCC compiles the code with no errors, but it should be rejected.
The non-type member foo hides the type member foo and the keyword typename
cannot help to disambiguate.
Moreover, in this case foo is not a dependent name and typename couldn't be
used.
[Bug c++/78286] typename, type members and non-type members: code should be rejected, but it is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78286 --- Comment #1 from Andrew Pinski --- >Moreover, in this case foo is not a dependent name and typename couldn't be >used. That is not true. There was a defect report (DR 382) against the C++ standard to allow that; I should know I implemented the support for this defect report; see PR 22154 :).
[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267 --- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #13 from Maxim Ostapenko --- [...] > The fixincludes fix looks cleaner, but it's harder to me to cook a patch > because: > > 1) I have no experience with fixincludes. > 2) I have no Darwin machine to test the fix. > > I can try fixincludes anyway, but this may take some time. But if the issue is > urgent, can we try to ifdef out and ? There isn't much > lost > in functionality, corresponding code reflects to printing sanitizer logs into > syslog on Darwin. That's certainly a short-term option, but I was going to try the fixincludes route myself anyway: I've already developed a couple of fixes for various systems and I do have a macOS 10.12 system around for testing. Rainer
[Bug c++/78286] typename, type members and non-type members: code should be rejected, but it is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78286 --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#382
[Bug c++/78286] typename, type members and non-type members: code should be rejected, but it is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78286 --- Comment #3 from Andrew Pinski --- Now the struct is invalid anyways even without the main function but the C++ standard does not require a diagnostic :).
[Bug ipa/78268] [7 Regression] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78268
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #9 from Martin Liška ---
There's a C test-case:
int a;
void (*b) ();
void fn1 ();
void
fn2 (int p1)
{
fn1 (-p1);
}
void
fn1 (int p1)
{
if (a)
b (p1);
}
[Bug rtl-optimization/78232] [7 Regression] FAIL: gcc.dg/torture/pr48124-4.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78232 Martin Liška changed: What|Removed |Added CC||su at cs dot ucdavis.edu --- Comment #1 from Martin Liška --- *** Bug 78248 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/78248] [7 Regression] wrong code at -Os and above on x86_64-linux-gnu (in both 32-bit and 64-bit modes)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78248 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #16 from Martin Liška --- (In reply to Segher Boessenkool from comment #15) > Hi, could you try https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00775.html ? > And sorry for the breakage. Patch fixed the issue. I'm marking this as a DUP. *** This bug has been marked as a duplicate of bug 78232 ***
[Bug middle-end/71762] [5/6/7 Regression] ~X & Y to X < Y doesn't work for uninitialized values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71762
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #9 from Richard Biener ---
For a smaller C testcase the init-regs pass "saves" us here:
static _Bool
foo (_Bool a, _Bool b)
{
int x = a && ! b;
return x != 0;
}
int y = 1;
int main()
{
_Bool x;
if (foo (x, y))
__builtin_abort ();
return 0;
}
but we abort () with -fdisable-rtl-init-regs (and we know that pass is
not conservative given the original testcase). We can fix that case up
at RTL expansion time. We then generate
main:
.LFB1:
.cfi_startproc
movly(%rip), %edx
testl %edx, %edx
setne %dl
andl$1, %eax
cmpb%al, %dl
jb .L7
compared to
main:
.LFB1:
.cfi_startproc
movly(%rip), %eax
testl %eax, %eax
setne %al
cmpb%dl, %al
jb .L7
and compared to
main:
.LFB1:
.cfi_startproc
movly(%rip), %edx
testl %edx, %edx
jne .L2
testb $1, %al
jne .L13
for without the pattern (but the bitfield reduction fix for default-defs
still in).
The following case (or loads from _Bool memory) show we'd have to apply
bitfield reduction to all loads as well :/
static _Bool
foo (_Bool a, _Bool b)
{
int x = a && ! b;
return x != 0;
}
int y = 1;
int main()
{
register _Bool x __asm__("%rsi");
if (foo (x, y))
__builtin_abort ();
return 0;
}
we can't initialize x -- but we could in theory reduce to bitfield precision
at the point of the "load" (asm regs are memory on gimple):
;; x.1_3 = x;
(insn 5 4 0 (set (reg:QI 89 [ x.1_3 ])
(reg/v:QI 4 si [ x ])) "t.c":12 -1
(nil))
Thus likewise for
static _Bool
foo (_Bool a, _Bool b)
{
int x = a && ! b;
return x != 0;
}
int y = 1;
int main()
{
_Bool x[128];
if (foo (x[1], y))
__builtin_abort ();
return 0;
}
which we expand to
;; _3 = x[1];
;; if (_2 < _3)
...
(insn 7 6 8 (set (reg:CC 17 flags)
(compare:CC (reg:QI 92)
(mem/c:QI (plus:DI (reg/f:DI 82 virtual-stack-vars)
(const_int -127 [0xff81])) [2 x+1 S1 A8])))
"t.c":12 -1
(nil))
subq$136, %rsp
.cfi_def_cfa_offset 144
movly(%rip), %eax
testl %eax, %eax
setne %al
cmpb1(%rsp), %al
For reference the patch for the undefined SSA case:
Index: gcc/expr.c
===
--- gcc/expr.c (revision 242004)
+++ gcc/expr.c (working copy)
@@ -61,6 +61,8 @@ along with GCC; see the file COPYING3.
#include "tree-chkp.h"
#include "rtl-chkp.h"
#include "ccmp.h"
+#include "tree-dfa.h"
+#include "tree-ssa.h"
/* If this is nonzero, we do not bother generating VOLATILE
@@ -9734,6 +9736,17 @@ expand_expr_real_1 (tree exp, rtx target
ssa_name = exp;
decl_rtl = get_rtx_for_ssa_name (ssa_name);
exp = SSA_NAME_VAR (ssa_name);
+ /* If we didn't have the chance to reduce to bitfield precision
+ at the definition site do so here. For signed undefined
+values nothing can be assumed for the upper bits so we do not
+need to do anything here. Note that we do this at all
+use sites because that allows easier combining. Note we
+can't easily do it once at function entry w/o changing
+coalescing. */
+ if (reduce_bit_field
+ && TYPE_UNSIGNED (type)
+ && ssa_undefined_value_p (ssa_name, false))
+ decl_rtl = reduce_to_bit_field_precision (decl_rtl, NULL_RTX, type);
goto expand_decl_rtl;
case PARM_DECL:
while the undef SSA case is reasonable to handle (and has a low chance to
pessimize code) applying bitfield reduction at all loads of bit-precision
values is going to hurt (ok, in practice that's going to be loads from
_Bool arrays and _Bool register asm vars only).
Mid-term it might be good to lower bitfield precision stuff on GIMPLE
(similar as to how we want to lower PROMOTE_REGS).
Thus to conclude -- I'm going to test removal of the patterns. A similar
transform on the RTL side might be still profitable in case known-zero-bits
indicates both participating regs only have one (not-sign) bit possibly set
(and we can do that on GIMPLE for TYPE_PRECISION == TYPE_MODE as well).
[Bug preprocessor/78287] New: #line directive with value more than 2147483640 prints out the value twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78287 Bug ID: 78287 Summary: #line directive with value more than 2147483640 prints out the value twice Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: jussi.judin at ericsson dot com Target Milestone: --- If I give a number with value more than 2147483640 (basically 7 maximum values, 2147483641-2147483647, that are allowed for #line directive), the resulting output from cpp results in the line number and file name printed twice. Following example demonstrates the issue: #line 2147483639 a #line 2147483640 b #line 2147483641 c #line 2147483642 d #line 2147483643 e #line 2147483644 f #line 2147483645 g #line 2147483646 h #line 2147483647 i When running this through cpp (GCC 4.8 and the latest git master as of today) it results in following output where line numbers over 2147483640 are printed twice: # 1 "line.c" # 1 "" # 1 "" # 31 "" # 1 "/usr/include/stdc-predef.h" 1 3 4 # 32 "" 2 # 1 "line.c" # 2147483639 "line.c" a # 2147483640 "line.c" b # 2147483641 "line.c" # 2147483641 "line.c" c # 2147483642 "line.c" # 2147483642 "line.c" d # 2147483643 "line.c" # 2147483643 "line.c" e # 2147483644 "line.c" # 2147483644 "line.c" f # 2147483645 "line.c" # 2147483645 "line.c" g # 2147483646 "line.c" # 2147483646 "line.c" h # 2147483647 "line.c" # 2147483647 "line.c" i
[Bug fortran/77501] [F03] ICE in gfc_match_generic, at fortran/decl.c:9429
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77501 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org Target Milestone|--- |7.0 --- Comment #3 from janus at gcc dot gnu.org --- I'm currently testing a patch for this.
[Bug debug/78112] [7 regression] invalid DWARF generated by the compiler: DIE has multiple AT_inline attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78112 --- Comment #12 from pmderodat at gcc dot gnu.org --- Author: pmderodat Date: Thu Nov 10 11:06:32 2016 New Revision: 242035 URL: https://gcc.gnu.org/viewcvs?rev=242035&root=gcc&view=rev Log: debug/78112: remove recent duplicates for DW_TAG_subprogram attributes Disable unnecessary calls to dwarf2out_decl for the parents of nested functions. This fixes a libstdc++ build regression on x86_64-apple-darwin, as these calls used to add duplicate attributes (for instance DW_AT_inline and DW_AT_object_pointer) to the corresponding DW_TAG_subprogram DIE. Bootstrapped and regtested on x86_64-linux. gcc/ PR debug/78112 * dwarf2out.c (dwarf2out_early_global_decl): Call dwarf2out_decl on the context only when it has no DIE yet. testsuite/ PR debug/78112 * g++.dg/pr78112.C: New testcase Added: trunk/gcc/testsuite/g++.dg/pr78112.C Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/78232] [7 Regression] FAIL: gcc.dg/torture/pr48124-4.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78232 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-10 Ever confirmed|0 |1 --- Comment #2 from Uroš Bizjak --- Confirmed by duplicate PR 78248 (which includes runtime testcase that fails on x86_64 with -fsanitize=undefined).
[Bug debug/78288] New: Compile time hog (with var-tracking) in libsanitizer/asan/asan_interceptors.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78288
Bug ID: 78288
Summary: Compile time hog (with var-tracking) in
libsanitizer/asan/asan_interceptors.cc
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
I've noticed that compilation of sanitizer interceptors take quite significant
time.
With -fno-checking it takes 0m18.664s, while adding -gtoggle time shrinks to
0m12.680s.
As var-tracking eats 1/3 of compile time, I'm wondering whether there's a space
for improvement?
perf report:
5.72% cc1plus cc1plus [.] canonicalize_values_star
3.64% cc1plus cc1plus [.] set_slot_part
1.50% cc1plus cc1plus [.] bitmap_set_bit
1.39% cc1plus libc-2.24.so [.] _int_malloc
1.35% cc1plus cc1plus [.] ggc_set_mark
1.23% cc1plus cc1plus [.]
hash_table::find_slot_with_hash
1.21% cc1plus cc1plus [.] loc_cmp
perf annotate of the 2 hottest functions:
│ if (GET_CODE (node->loc) == VALUE)
0.13 │ 88: mov0x8(%rax),%rdx
0.99 │ cmpw $0x1,(%rdx)
1.86 │ ↑ jne80
│ {
│ has_value = true;
│ if (VALUE_RECURSED_INTO (node->loc))
│ has_marks = true;
5.04 │ testb $0x20,0x3(%rdx)
0.96 │ mov$0x1,%edi
│ cmovne %edi,%ecx
│ canon_value_cmp():
│ || CSELIB_VAL_PTR (tval)->uid < CSELIB_VAL_PTR (cval)->uid;
5.74 │ test %rbx,%rbx
│ ↓ je 455
│ mov0x8(%rbx),%r8
17.32 │ mov0x8(%rdx),%rdi
│ _Z24canonicalize_values_starPP8variableP12dataflow_set():
│ for (node = var->var_part[0].loc_chain; node; node = node->next)
0.04 │ mov(%rax),%rax
│ canon_value_cmp():
│ || CSELIB_VAL_PTR (tval)->uid < CSELIB_VAL_PTR (cval)->uid;
0.38 │ mov0x4(%rdi),%edi
3.81 │ cmp%edi,0x4(%r8)
31.32 │ mov$0x1,%edi
0.02 │ cmovg %rdx,%rbx
│ _Z24canonicalize_values_starPP8variableP12dataflow_set():
│ for (node = var->var_part[0].loc_chain; node; node = node->next)
10.26 │ test %rax,%rax
│ ↑ jne88
│ if (canon_value_cmp (node->loc, cval))
│ cval = node->loc;
│ }
│
│ if (!has_value)
│ c7: test %dil,%dil
│ ↓ je 310
│ return 1;
│
│ if (cval == val)
0.02 │ cmp%rbx,%r12
│ ↓ je 4ad
│ else if (REG_P (node->loc) || MEM_P (node->loc))
0.14 │650: cmp$0x2f,%cx
│ ↓ je 660
│ cmp$0x29,%cx
│ ↑ jne2c0
│nextp = &node->next)
14.58 │660: mov%rbx,%rbp
│ for (nextp = &var->var_part[0].loc_chain; (node =
*nextp);
0.04 │ mov(%rbx),%rbx
│ c++;
2.01 │ mov%eax,%r14d
│ add$0x1,%eax
│ for (nextp = &var->var_part[0].loc_chain; (node =
*nextp);
7.20 │ test %rbx,%rbx
│ ↑ je 2c0
│ if (GET_CODE (node->loc) == VALUE)
0.14 │675: mov0x8(%rbx),%rsi
4.02 │ lea-0x1(%rax),%r14d
0.04 │ movzwl (%rsi),%ecx
12.35 │ cmp$0x1,%cx
│ ↑ jne650
│ if (node->loc == loc)
1.27 │ cmp%r13,%rsi
│ ↑ je 503
│ canon_value_cmp():
│ || CSELIB_VAL_PTR (tval)->uid < CSELIB_VAL_PTR (cval)->uid;
1.52 │ mov0x8(%r13),%rdi
0.07 │ mov0x8(%rsi),%rcx
9.25 │ mov0x4(%rcx),%edx
42.46 │ cmp%edx,0x4(%rdi)
Giving me an advise, I can help with that.
Thanks
[Bug debug/78112] [7 regression] invalid DWARF generated by the compiler: DIE has multiple AT_inline attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78112 Pierre-Marie de Rodat changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||derodat at adacore dot com Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |derodat at adacore dot com --- Comment #13 from Pierre-Marie de Rodat --- I just pushed the suggested fix on trunk, so the regression should be gone, now.
[Bug debug/78288] Compile time hog (with var-tracking) for libsanitizer/asan/asan_interceptors.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78288 Markus Trippelsdorf changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #1 from Markus Trippelsdorf --- See also PR63983 and PR77471.
[Bug sanitizer/78270] [7 Regression] ICE in gimplify_switch_expr, at gimplify.c:2272
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78270 --- Comment #3 from Martin Liška --- Author: marxin Date: Thu Nov 10 11:21:03 2016 New Revision: 242036 URL: https://gcc.gnu.org/viewcvs?rev=242036&root=gcc&view=rev Log: Create live_switch_vars conditionally (PR sanitizer/78270) PR sanitizer/78270 * gcc.dg/asan/pr78270.c: New test. PR sanitizer/78270 * gimplify.c (gimplify_switch_expr): Create live_switch_vars only when SWITCH_BODY is a BIND_EXPR. Added: trunk/gcc/testsuite/gcc.dg/asan/pr78270.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog
[Bug sanitizer/78270] [7 Regression] ICE in gimplify_switch_expr, at gimplify.c:2272
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78270 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Liška --- Fixed.
[Bug debug/78288] Compile time hog (with var-tracking) for libsanitizer/asan/asan_interceptors.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78288 Richard Biener changed: What|Removed |Added Keywords||compile-time-hog --- Comment #2 from Richard Biener --- The var-tracking data-flow problem is basically (at least) quadratic in size. We do lots of stuff to mitigate that but that itself takes time...
[Bug debug/78288] Compile time hog (with var-tracking) for libsanitizer/asan/asan_interceptors.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78288 --- Comment #3 from Martin Liška --- Thanks for the references and explanation.
[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267 --- Comment #15 from Maxim Ostapenko --- Created attachment 40012 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40012&action=edit Untested fix 2. Ok, thanks. I'm attaching a second short-term fix for now.
[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267 --- Comment #16 from Jakub Jelinek --- Preapproved. If/once Rainer will have a fixincludes patch, this can be reverted.
[Bug middle-end/78103] Failure to optimize with __builtin_clzl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78103 prathamesh3492 at gcc dot gnu.org changed: What|Removed |Added CC||prathamesh3492 at gcc dot gnu.org --- Comment #6 from prathamesh3492 at gcc dot gnu.org --- With trunk on arm-linux-gnueabihf, nearly identical code is generated for findLastSet and findLastSet2. findLastSet: cmp r0, #0 clzne r0, r0 rsbne r0, r0, #32 bx lr findLastSet2: cmp r0, #0 clzne r0, r0 eorne r0, r0, #31 addne r0, r0, #1 bx lr
[Bug tree-optimization/78114] [7 regression] gfortran.dg/vect/fast-math-mgrid-resid.f FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78114 --- Comment #5 from amker at gcc dot gnu.org --- It's because the loop is vectorized by vf=2 with -mavx2, while by vf=4 with -march=haswell. In that case the peeled prolog iterates more than 1 times, resulting in test failure.
[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267 --- Comment #17 from Rainer Orth --- Created attachment 40013 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40013&action=edit proposed fixincludes-based patch The attached patch passes fixincludes make check. I'll have to wait until tonight to test it for real on macOS 10.12, though. Rainer
[Bug tree-optimization/78257] missing memcmp optimization with constant arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78257
--- Comment #5 from Martin Liška ---
(In reply to Martin Sebor from comment #4)
> Created attachment 40008 [details]
> Very lightly tested patch.
>
> The attached (only superficially tested) patch changes fold_bultin_memcmp to
> fold the comparison over the length of the arrays rather than just the first
> pair of bytes. Does it look reasonable?
I played a bit with the patch and it's nice that it can handle(In reply to
Martin Sebor from comment #4)
> Created attachment 40008 [details]
> Very lightly tested patch.
>
> The attached (only superficially tested) patch changes fold_bultin_memcmp to
> fold the comparison over the length of the arrays rather than just the first
> pair of bytes. Does it look reasonable?
I played a bit with the patch and it ICEs with:
#include
#include
const int i[] = { 16843009 };
const char k[] = {1, 1, 1, 1};
int main()
{
unsigned test = sizeof(i) * 1;
assert (__builtin_memcmp (i, k, test) == 0);
return 0;
}
and without an optimization level, it can produce tons of assembly code:
#include
#include
#define ctor(N) {N, N, N, N, N, N, N, N, N, N, N, N}
const int i[] = ctor(123456);
const int k[] = ctor(123456);
int main()
{
assert (__builtin_memcmp (i, k, sizeof i) == 0);
return 0;
}
folding2.c.004t.gimple:
i.1_1 = &i;
_2 = MEM[(const unsigned char * {ref-all})i.1_1];
k.2_3 = &k;
_4 = MEM[(const unsigned char * {ref-all})k.2_3];
if (_2 == _4) goto ; else goto ;
:
_5 = &i + 1;
_6 = *_5;
_7 = &k + 1;
_8 = *_7;
if (_6 == _8) goto ; else goto ;
:
_9 = &i + 2;
_10 = *_9;
_11 = &k + 2;
_12 = *_11;
if (_10 == _12) goto ; else goto ;
:
_13 = &i + 3;
_14 = *_13;
_15 = &k + 3;
_16 = *_15;
if (_14 == _16) goto ; else goto ;
:
_17 = &i + 4;
_18 = *_17;
_19 = &k + 4;
_20 = *_19;
Martin
[Bug libgomp/78289] New: OpenMP produces high CPU load if used in more than one process
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78289 Bug ID: 78289 Summary: OpenMP produces high CPU load if used in more than one process Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: s.schuel...@ids-imaging.de CC: jakub at gcc dot gnu.org Target Milestone: --- Created attachment 40014 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40014&action=edit gcc -O2 omp.c -lpthread -fopenmp -o omp We discovered that our application performs very bad on Linux when two or more processes are started which use OpenMP. I've removed line by line from the source to find the bottleneck until there were no more lines to remove. I attached a simple program that exposes the problem. In the first step eight Threads are created which run a empty openmp for loop 1 times. After that eigth Processes are created using fork() each running the same loop 1. The Thread based version takes about 1 second and the fork() version 3 minutes 30 seconds on a i7 4790 Problem could be reproduced on ubuntu 12.04, 16.04 compile attachment: gcc -O2 omp.c -lpthread -fopenmp -o omp
[Bug tree-optimization/78114] [7 regression] gfortran.dg/vect/fast-math-mgrid-resid.f FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78114 --- Comment #6 from amker at gcc dot gnu.org --- But for tests: FAIL: gfortran.dg/vect/fast-math-mgrid-resid.f -O scan-tree-dump-times pcom "Executing predictive commoning without unrolling" 1 FAIL: gfortran.dg/vect/fast-math-mgrid-resid.f -O scan-tree-dump-times pcom "Predictive commoning failed: no suitable chains" 0 they happened before 20161011. I tried revision at: commit ab93a7014158ec67a0b34e2986742da8a55013f9 Author: sje Date: Wed Oct 5 18:42:10 2016 + 2016-10-05 Steve Ellcey * MAINTAINERS: Update email address after it got reverted. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@240801 138bc75d-0d04-0410-961f-82ee72b054a4 And it's not working either?
[Bug middle-end/78201] [7 Regression] ICE in tree_to_shwi, at tree.h:4037 (seen both on ARM32 an AArch64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78201 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 40015 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40015&action=edit gcc7-pr78201.patch Untested fix. The primary bug here is in the FEs/gimplifier, they shouldn't create a TREE_STATIC artificial var with variable length size. I believe we have PRs for that though, and I think it is desirable to do the right thing even in this target hook though. There is no need to test decl != NULL again, this is all in a block guarded with if (decl && DECL_P (decl)). Furthermore, I think we shouldn't put the odd-sized stuff into section anchors. And, while max_anchor_offset is HOST_WIDE_INT, the other uses cast those to unsigned HOST_WIDE_INT anyway. Plus using DECL_SIZE and comparing against max_anchor_offset * BITS_PER_UNIT is too ugly, we already have DECL_SIZE_UNIT in bytes.
[Bug libgomp/78289] OpenMP produces high CPU load if used in more than one process
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78289 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jakub Jelinek --- It is user's/programmer's responsibility to prevent oversubscribing the CPU. You can use OMP_NUM_THREADS=nn in environment, num_threads clause on parallel region, or if you really want to oversubscribe the CPU, you can tune whether the library will do busy waiting or not and how much (OMP_WAIT_POLICY=active, OMP_WAIT_POLICY=passive, GOMP_SPINCOUNT=, affinity, ..., omp_* APIs that allow to fine tune the earlier mentioned env var settings, etc.
[Bug middle-end/78201] [7 Regression] ICE in tree_to_shwi, at tree.h:4037 (seen both on ARM32 an AArch64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78201 --- Comment #5 from Yvan Roux --- Ok, I'll validate the fix.
[Bug fortran/77703] [6/7 Regression] ICE on assignment to pointer function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77703 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug target/77761] [7 Regression] wrong code with -fschedule-insns -mavx512f --param=max-pending-list-length=512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77761 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-10 CC||jakub at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r238991.
[Bug fortran/78290] New: Gfortran incorrectly creates a copy of an array passed to an array pointer dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78290 Bug ID: 78290 Summary: Gfortran incorrectly creates a copy of an array passed to an array pointer dummy argument Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: andybugreports at gmail dot com Target Milestone: --- The following code demonstrates incorrect behaviour of a array pointer being passed to an array pointer dummy argument. As highlighted in the comment, the compiler seems to generate a copy of the array rather than passing a pointer to it. "sub1" seems to be doing the right thing, but due to the copy and what looks like incorrect behaviour to attempt to copy some of it back the result is wrong. Removing the line shown later in the source stops the copy occurring and fixes the problem. Bug 53800 looks potentially similar: PROGRAM main IMPLICIT NONE INTEGER,PARAMETER::KI=4,KF=8,KL=4 TYPE mytype INTEGER(KIND=KI)::i=1_KI REAL(KIND=KF)::r=2.0_KF LOGICAL(KIND=KL)::z=.TRUE._KL END TYPE mytype TYPE(mytype),DIMENSION(50),SAVE,TARGET::ta INTEGER(KIND=KI),DIMENSION(3),SAVE,TARGET::ia=1_KI INTEGER(KIND=KI),DIMENSION(:),POINTER::ia2=>NULL() INTEGER(KIND=KI),DIMENSION(:),POINTER,SAVE::ipsave=>NULL() INTEGER(KIND=KI),DIMENSION(:),POINTER::ip=>NULL() ALLOCATE(ia2(5)); ia2=2_KI ip=>ia; NULLIFY(ipsave) CALL sub1(ip) WRITE(*,*)'ia',ia WRITE(*,*)'ip',ip WRITE(*,*)'ipsave',ipsave ip=>ta%i !!! Works if you comment this line out !!! ! At writes: isave should point to ia which should be changed to all 3s ! ip should point to ip2 ! Produces: ! ia 2 2 2 ! ip 2 2 2 ! ipsave 3 3 3 ! ! Should produce: ! ia 3 3 3 ! ip 2 2 2 2 2 ! ipsave 3 3 3 ! ! Seems to be creating a copy of ia and setting argument ipa as a pointer this, and ! changes to this never get transferred back to ia ! Also does not transfer back change of target or INOUT argugment ! Works if you comment out the line "ip=>ta%i" ! CONTAINS SUBROUTINE sub1(ipa) INTEGER(KIND=KI),DIMENSION(:),POINTER,INTENT(INOUT)::ipa ! Fortran 2003 ! INTEGER(KIND=KI),DIMENSION(:),POINTER::ipa ! Fortan 95 ipsave=>ipa ipsave=3_KI ipa=>ia2 END SUBROUTINE sub1 END PROGRAM main
[Bug c++/78291] New: overload resolution prefers non-member operator to member operator when should be ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78291
Bug ID: 78291
Summary: overload resolution prefers non-member operator to
member operator when should be ambiguous
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
This example:
struct A {
template
void operator==(T const& ) const;
template
friend void operator==(T const&, A const& ) { }
};
int main() {
A{} == A{};
}
compiles and runs (tried 4.8.2, 5.4, 6.2, and 7.0). gcc picks the non-member
overload here. But both overloads are equally viable, so this should be
ambiguous.
[Bug tree-optimization/77856] [7 Regression] wrong code at -O2 on x86_64-linux-gnu in 32-bit mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77856
Jakub Jelinek changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
To me this looks like a LRA bug. In *.ira we have:
(insn 210 18 20 3 (set (reg:SI 225 [ c.f1 ])
(const_int 1 [0x1])) "pr77856.c":24 82 {*movsi_internal}
(expr_list:REG_EQUAL (const_int 1 [0x1])
(nil)))
...
(insn 23 21 25 3 (parallel [
(set (reg:SI 119 [ _45 ])
(ashiftrt:SI (reg:SI 225 [ c.f1 ])
(subreg:QI (reg:SI 117 [ _42 ]) 0)))
(clobber (reg:CC 17 flags))
]) "pr77856.c":15 563 {*ashrsi3_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_EQUAL (ashiftrt:SI (const_int 1 [0x1])
(subreg:QI (reg:SI 117 [ _42 ]) 0))
(nil
(insn 25 23 3 3 (parallel [
(set (reg:SI 120 [ _46 ])
(ashift:SI (reg:SI 225 [ c.f1 ])
(subreg:QI (reg:SI 117 [ _42 ]) 0)))
(clobber (reg:CC 17 flags))
]) "pr77856.c":15 529 {*ashlsi3_1}
(expr_list:REG_DEAD (reg:SI 225 [ c.f1 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_EQUAL (ashift:SI (const_int 1 [0x1])
(subreg:QI (reg:SI 117 [ _42 ]) 0))
(nil)
(insn 3 25 4 3 (set (reg:SI 152 [ _81 ])
(const_int 1 [0x1])) "pr77856.c":24 82 {*movsi_internal}
(expr_list:REG_EQUAL (const_int 1 [0x1])
(nil)))
...
(insn 280 81 123 3 (set (reg:SI 240 [orig:152 _81 ] [152])
(reg:SI 152 [ _81 ])) "pr77856.c":32 82 {*movsi_internal}
(expr_list:REG_DEAD (reg:SI 152 [ _81 ])
(nil)))
and in *.reload we have:
(insn 210 337 336 3 (set (reg:SI 0 ax [orig:225 c.f1 ] [225])
(const_int 1 [0x1])) "pr77856.c":24 82 {*movsi_internal}
(expr_list:REG_EQUAL (const_int 1 [0x1])
(nil)))
...
(insn 23 287 286 3 (parallel [
(set (reg:SI 5 di [orig:119 _45 ] [119])
(ashiftrt:SI (reg:SI 5 di [orig:119 _45 ] [119])
(reg:QI 2 cx [243])))
(clobber (reg:CC 17 flags))
]) "pr77856.c":15 563 {*ashrsi3_1}
(expr_list:REG_EQUAL (ashiftrt:SI (const_int 1 [0x1])
(subreg:QI (reg:SI 117 [ _42 ]) 0))
(nil)))
(insn 286 23 290 3 (set (mem/c:SI (plus:SI (reg/f:SI 7 sp)
(const_int 20 [0x14])) [5 %sfp+-1004 S4 A32])
(reg:SI 5 di [orig:119 _45 ] [119])) "pr77856.c":15 82
{*movsi_internal}
(nil))
(insn 290 286 25 3 (set (reg:QI 2 cx [245])
(reg:QI 3 bx [orig:117 _42 ] [117])) "pr77856.c":15 85
{*movqi_internal}
(nil))
(insn 25 290 289 3 (parallel [
(set (reg:SI 0 ax [orig:225 c.f1 ] [225])
(ashift:SI (reg:SI 0 ax [orig:225 c.f1 ] [225])
(reg:QI 2 cx [245])))
(clobber (reg:CC 17 flags))
]) "pr77856.c":15 529 {*ashlsi3_1}
(expr_list:REG_EQUAL (ashift:SI (const_int 1 [0x1])
(subreg:QI (reg:SI 117 [ _42 ]) 0))
(nil)))
(insn 289 25 3 3 (set (mem/c:SI (plus:SI (reg/f:SI 7 sp)
(const_int 24 [0x18])) [5 %sfp+-1000 S4 A32])
(reg:SI 0 ax [orig:225 c.f1 ] [225])) "pr77856.c":15 82
{*movsi_internal}
(nil))
(note 3 289 333 3 NOTE_INSN_DELETED)
...
(insn 280 81 123 3 (set (reg:SI 3 bx [orig:152 _81 ] [152])
(reg:SI 0 ax [orig:152 _81 ] [152])) "pr77856.c":32 82
{*movsi_internal}
(nil))
So, %ebx doesn't hold 1 as it is supposed to, but 1 << %ecx (64).
Vlad, could you please have a look?
[Bug c++/77337] [7 regression][c++1z] use before deduction of 'auto'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77337 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- This is rejected starting with r239268, P0170R1 implementation. clang++ doesn't seem to implement that part of C++17 from what I can see. Whether the test is valid C++17 or not I'll defer to others.
[Bug tree-optimization/77309] [5/6 Regression] wrong code at -Os and above on x86_64-linux-gnu (in the 64-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77309 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Summary|[5/6/7 Regression] wrong|[5/6 Regression] wrong code |code at -Os and above on|at -Os and above on |x86_64-linux-gnu (in the|x86_64-linux-gnu (in the |64-bit mode)|64-bit mode) --- Comment #4 from Jakub Jelinek --- Assuming this is fixed now on the trunk.
[Bug testsuite/78292] New: [7 regression] test case gcc.dg/vect/vect-cond-2.c fails starting with r241967
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78292 Bug ID: 78292 Summary: [7 regression] test case gcc.dg/vect/vect-cond-2.c fails starting with r241967 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at linux dot vnet.ibm.com Target Milestone: --- These still are expected to fail, at least on powerpc. spawn /home/seurer/gcc/build/gcc-trunk/gcc/xgcc -B/home/seurer/gcc/build/gcc-trunk/gcc/ /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/vect/vect-cond-2.c -fno-diagnostics-show-caret -fdiagnostics-color=never -maltivec -mpower8-vector -ftree-vectorize -fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details -lm -o ./vect-cond-2.exe PASS: gcc.dg/vect/vect-cond-2.c (test for excess errors) Setting LD_LIBRARY_PATH to :/home/seurer/gcc/build/gcc-trunk/gcc::/home/seurer/gcc/build/gcc-trunk/gcc:/home/wschmidt/gcc/install/gcc-6.2.0/lib64 spawn [open ...] PASS: gcc.dg/vect/vect-cond-2.c execution test FAIL: gcc.dg/vect/vect-cond-2.c scan-tree-dump-times vect "vectorized 1 loops" 1 Executing on host: /home/seurer/gcc/build/gcc-trunk/gcc/xgcc -B/home/seurer/gcc/build/gcc-trunk/gcc/ /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/vect/vect-cond-2.c -fno-diagnostics-show-caret -fdiagnostics-color=never -flto -ffat-lto-objects -maltivec -mpower8-vector -ftree-vectorize -fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details -lm-o ./vect-cond-2.exe(timeout = 300) spawn /home/seurer/gcc/build/gcc-trunk/gcc/xgcc -B/home/seurer/gcc/build/gcc-trunk/gcc/ /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/vect/vect-cond-2.c -fno-diagnostics-show-caret -fdiagnostics-color=never -flto -ffat-lto-objects -maltivec -mpower8-vector -ftree-vectorize -fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details -lm -o ./vect-cond-2.exe PASS: gcc.dg/vect/vect-cond-2.c -flto -ffat-lto-objects (test for excess errors) Setting LD_LIBRARY_PATH to :/home/seurer/gcc/build/gcc-trunk/gcc::/home/seurer/gcc/build/gcc-trunk/gcc:/home/wschmidt/gcc/install/gcc-6.2.0/lib64 spawn [open ...] PASS: gcc.dg/vect/vect-cond-2.c -flto -ffat-lto-objects execution test FAIL: gcc.dg/vect/vect-cond-2.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 1 testcase /home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/vect/vect.exp completed in 1 seconds === gcc Summary === # of expected passes4 # of unexpected failures2
[Bug testsuite/78292] [7 regression] test case gcc.dg/vect/vect-cond-2.c fails starting with r241967
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78292 --- Comment #1 from Bill Seurer --- r241967 | amker | 2016-11-08 08:08:06 -0600 (Tue, 08 Nov 2016) | 3 lines gcc/testsuite * gcc.dg/vect/vect-cond-2.c: Drop xfail.
[Bug tree-optimization/78114] [7 regression] gfortran.dg/vect/fast-math-mgrid-resid.f FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78114 --- Comment #7 from amker at gcc dot gnu.org --- Here is the reason failing with haswell. The loop is vectorized by vf=4, but iteration distance for all possible predictive commoning chains are at most 2 (by iterations), so after vf=4 vectorization, there is no predictive commoning opportunities.
[Bug testsuite/78292] [7 regression] test case gcc.dg/vect/vect-cond-2.c fails starting with r241967
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78292 --- Comment #2 from amker at gcc dot gnu.org --- Sorry for that. Yes, GCC still requires vect_max_reduc to vectorize the loop, I will amend the test case.
[Bug fortran/78293] New: SIGABRT with function result used as argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78293 Bug ID: 78293 Summary: SIGABRT with function result used as argument Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: abensonca at gmail dot com Target Milestone: --- The following code dies with a SIGABRT at run time in gfortran 7.0.0 (r241975), and also in gfortran 6.2.1. As far as I can see it's valid code, but I wanted to get a second opinion on that before opening a PR. -Andrew -- module m implicit none type t integer, allocatable, dimension(:) :: r end type t contains function tt(a,b) implicit none type(t), allocatable, dimension(:) :: tt type(t), intent(in), dimension(:) :: a,b allocate(tt(2)) allocate(tt(1)%r(1)) allocate(tt(2)%r(1)) return end function tt function ts() implicit none type(t), allocatable, dimension(:) :: ts allocate(ts(1)) allocate(ts(1)%r(1)) return end function ts end module m program p use m implicit none type(t), dimension(2) :: c c=tt(ts(),ts()) end program p $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/6.2.1/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --disable-libgcj --with-isl --enable-libmpx --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 6.2.1 20160916 (Red Hat 6.2.1-2) (GCC) $ gfortran t.F90 $ a.out *** Error in `a.out': free(): invalid pointer: 0x02189f50 *** === Backtrace: = /lib64/libc.so.6(+0x7570b)[0x2aceab27c70b] /lib64/libc.so.6(+0x7deaa)[0x2aceab284eaa] /lib64/libc.so.6(cfree+0x4c)[0x2aceab28840c] a.out[0x4016ab] a.out[0x40171c] /lib64/libc.so.6(__libc_start_main+0xf1)[0x2aceab227731] a.out[0x4007b9] === Memory map: 0040-00402000 r-xp fd:03 9574876/ home/abenson/Galacticus/v0.9.4/a.out 00601000-00602000 r--p 1000 fd:03 9574876/ home/abenson/Galacticus/v0.9.4/a.out 00602000-00603000 rw-p 2000 fd:03 9574876/ home/abenson/Galacticus/v0.9.4/a.out 02187000-021a8000 rw-p 00:00 0 [heap] 2aceaa55-2aceaa574000 r-xp fd:01 400265 /usr/ lib64/ld-2.23.so 2aceaa574000-2aceaa576000 rw-p 00:00 0 2aceaa5c-2aceaa5c4000 rw-p 00:00 0 2aceaa773000-2aceaa774000 r--p 00023000 fd:01 400265 /usr/ lib64/ld-2.23.so 2aceaa774000-2aceaa775000 rw-p 00024000 fd:01 400265 /usr/ lib64/ld-2.23.so 2aceaa775000-2aceaa776000 rw-p 00:00 0 2aceaa776000-2aceaa8a4000 r-xp fd:01 409988 /usr/ lib64/libgfortran.so.3.0.0 2aceaa8a4000-2ace4000 ---p 0012e000 fd:01 409988 /usr/ lib64/libgfortran.so.3.0.0 2ace4000-2ace5000 r--p 0012e000 fd:01 409988 /usr/ lib64/libgfortran.so.3.0.0 2ace5000-2ace6000 rw-p 0012f000 fd:01 409988 /usr/ lib64/libgfortran.so.3.0.0 2ace6000-2ace7000 rw-p 00:00 0 2ace7000-2aceaabaf000 r-xp fd:01 468489 /usr/ lib64/libm-2.23.so 2aceaabaf000-2aceaadae000 ---p 00108000 fd:01 468489 /usr/ lib64/libm-2.23.so 2aceaadae000-2aceaadaf000 r--p 00107000 fd:01 468489 /usr/ lib64/libm-2.23.so 2aceaadaf000-2aceaadb rw-p 00108000 fd:01 468489 /usr/ lib64/libm-2.23.so 2aceaadb-2aceaadc6000 r-xp fd:01 394309 /usr/ lib64/libgcc_s-6.2.1-20160916.so.1 2aceaadc6000-2aceaafc5000 ---p 00016000 fd:01 394309 /usr/ lib64/libgcc_s-6.2.1-20160916.so.1 2aceaafc5000-2aceaafc6000 r--p 00015000 fd:01 394309 /usr/ lib64/libgcc_s-6.2.1-20160916.so.1 2aceaafc6000-2aceaafc7000 rw-p 00016000 fd:01 394309 /usr/ lib64/libgcc_s-6.2.1-20160916.so.1 2aceaafc7000-2aceab006000 r-xp fd:01 409963 /usr/ lib64/libquadmath.so.0.0.0 2aceab006000-2aceab205000 ---p 0003f000 fd:01 409963 /usr/ lib64/libquadmath.so.0.0.0 2aceab205000-2aceab206000 r--p 0003e000 fd:01 409963 /usr/ lib64/libquadmath.so.0.0.0 2
[Bug sanitizer/78294] New: -fsanitize=thread broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78294
Bug ID: 78294
Summary: -fsanitize=thread broken
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels 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
Target Milestone: ---
markus@x4 ~ % echo "int main(){}" | g++ -fsanitize=thread -x c++ - && ./a.out
[1]4123 segmentation fault ./a.out
Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0 0x in ?? ()
#1 0x76f4312d in __interceptor___tls_get_addr (arg=0x76ff7f68) at
../../../../gcc/libsanitizer/tsan/tsan_interceptors.cc:2421
#2 0x76f8b00a in
__tsan::ScopedIgnoreInterceptors::ScopedIgnoreInterceptors (this=) at ../../../../gcc/libsanitizer/tsan/tsan_rtl.h:549
#3 __tsan::Initialize (thr=thr@entry=0x76277780) at
../../../../gcc/libsanitizer/tsan/tsan_rtl.cc:331
#4 0x76f43b90 in __tsan::ScopedInterceptor::ScopedInterceptor
(this=this@entry=0x7fffe490, thr=0x76277780, pc=140737353072294,
fname=0x76fc5eea "__cxa_atexit") at
../../../../gcc/libsanitizer/tsan/tsan_interceptors.cc:256
#5 0x76f44e67 in __interceptor___cxa_atexit (f=f@entry=0x77efd480
,
arg=arg@entry=0x77ff2410 , dso=0x77ff2280) at
../../../../gcc/libsanitizer/tsan/tsan_interceptors.cc:399
#6 0x77efbea6 in __static_initialization_and_destruction_0
(__initialize_p=1, __priority=65535) at
../../../../gcc/libstdc++-v3/src/c++11/compatibility-c++0x.cc:214
#7 _GLOBAL__sub_I_compatibility_c__0x.cc(void) () at
../../../../gcc/libstdc++-v3/src/c++11/compatibility-c++0x.cc:257
#8 0x77de73a3 in call_init (env=0x7fffe568, argv=0x7fffe558,
argc=1, l=) at dl-init.c:72
#9 _dl_init (main_map=0x77ffe130, argc=1, argv=0x7fffe558,
env=0x7fffe568) at dl-init.c:120
#10 0x77dd6c5a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#11 0x0001 in ?? ()
#12 0x7fffe88a in ?? ()
#13 0x in ?? ()
Using the static version libtsan.a works fine.
markus@x4 ~ % uname -snrvmio
Linux x4 4.9.0-rc3-00450-gffbcbfca846e-dirty #79 SMP Sat Nov 5 20:22:52 CET
2016 x86_64 AuthenticAMD GNU/Linux
markus@x4 ~ % /lib64/libc-2.24.90.so
GNU C Library (GNU libc) development release version 2.24.90, by Roland McGrath
et al.
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 7.0.0 20161031 (experimental).
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
libc ABIs: UNIQUE IFUNC
For bug reporting instructions, please see:
.
[Bug middle-end/78295] New: [7 Regression] Spurious -Wuninitialized warning for vector element assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78295
Bug ID: 78295
Summary: [7 Regression] Spurious -Wuninitialized warning for
vector element assignment
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: jsm28 at gcc dot gnu.org
Target Milestone: ---
On x86_64-linux-gnu, with -O2 -Wall, the code
typedef double vectype __attribute__ ((__vector_size__ (16)));
vectype
f (double x)
{
vectype t;
for (int i = 0; i < 2; i++)
t[i] = x;
return t;
}
produces a spurious warning
t.c: In function 'f':
t.c:8:10: warning: 't' is used uninitialized in this function [-Wuninitialized]
t[i] = x;
~^~~
which does not appear with GCC 6. Even if storing to a vector element is
represented internally as loading the whole vector then modifying it, this
should not result in a warning, as *logically* the assignment does not use an
uninitialized value.
This results in errors building the glibc testsuite for x86_64, as it has code
like the above to initialize vectors.
[Bug fortran/78293] [5/6/7 Regression] SIGABRT with function result used as argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78293 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-10 CC||mikael at gcc dot gnu.org Known to work||4.9.3 Summary|SIGABRT with function |[5/6/7 Regression] SIGABRT |result used as argument |with function result used ||as argument Ever confirmed|0 |1 Known to fail||5.4.0, 6.2.0, 7.0 --- Comment #1 from Dominique d'Humieres --- Confirmed from gcc5 up to trunk (7.0). This is caused by revision r225926 (pr61831) for gcc-6 and r232482 for gcc-5.
[Bug fortran/78277] ICE in is_anonymous_component, at fortran/interface.c:450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78277
foreese at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Last reconfirmed|2016-11-09 00:00:00 |2016-11-10
Assignee|unassigned at gcc dot gnu.org |foreese at gcc dot
gnu.org
Target Milestone|--- |7.0
--- Comment #2 from foreese at gcc dot gnu.org ---
(In reply to Gerhard Steinmetz from comment #0)
> Invalid code together with option -fdec, affects versions 6 and 7 :
>
...
> $ gfortran-7-20161106 -fdec -c z1.f90
> z1.f90:11:19:
>
> structure t.
>1
> Error: Syntax error in data declaration at (1)
> z1.f90:14:9:
>
>end structure
> 1
> Error: Expecting END SUBROUTINE statement at (1)
> f951: internal compiler error: Segmentation fault
> 0xc3a64f crash_signal
> ../../gcc/toplev.c:338
> 0x6952d0 is_anonymous_component
...
I'll have a patch soon.
For the curious reader:
The underlying cause is the fact that an anonymous structure declaration is
created at the line of error "structure t.", but the data declaration error
aborts the matcher and undoes the parse stack for the following structure
declaration which should become part of the anonymous definition. This doesn't
allow the matcher to finish the anonymous declaration.
Due to the abort, the following components are added to the enclosing
"structure /s/", and the anonymous inner structure is never completed. The ICE
is specifically because the "zero_comp" attribute is never set, even though the
abort of the matcher causes no components to be assigned to the inner
structure.
The correct solution is not just to add null-guards to compare_components;
rather to fix the error handling around the bad anonymous inner structure
declaration. The anonymous inner structure should continue being parsed as
normal, while an error is still emitted about the bad variable-decl ("t.").
[Bug fortran/78290] Gfortran incorrectly creates a copy of an array passed to an array pointer dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78290 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-10 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from 4.8 up to trunk (7.0).
[Bug ipa/78296] New: [7 regression] test case gcc.dg/ipa/vrp7.c fails starting with r242032
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78296 Bug ID: 78296 Summary: [7 regression] test case gcc.dg/ipa/vrp7.c fails starting with r242032 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: seurer at linux dot vnet.ibm.com Target Milestone: --- spawn /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/ipa/vrp7.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -fdump-ipa-cp-details -S -o vrp7.s PASS: gcc.dg/ipa/vrp7.c (test for excess errors) FAIL: gcc.dg/ipa/vrp7.c scan-ipa-dump-times cp "Setting value range of param 0 \\[-10, 9\\]" 1 === gcc Summary === # of expected passes1 # of unexpected failures1
[Bug c++/72808] [6/7 Regression] ICE on valid c++ code in verify_type (gcc/tree.c:14047)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72808
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-11-10
CC||jakub at gcc dot gnu.org,
||jason at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #6 from Jakub Jelinek ---
The difference is that the CONST_DECL is added only to one RECORD_TYPE and not
to its variants in:
if (context && context == current_class_type && !SCOPED_ENUM_P (enumtype))
{
/* In something like `struct S { enum E { i = 7 }; };' we put `i'
on the TYPE_FIELDS list for `S'. (That's so that you can say
things like `S::i' later.) */
/* The enumerator may be getting declared outside of its enclosing
class, like so:
class S { public: enum E : int; }; enum S::E : int { i = 7; };
For which case we need to make sure that the access of `S::i'
matches the access of `S::E'. */
tree saved_cas = current_access_specifier;
if (TREE_PRIVATE (TYPE_NAME (enumtype)))
current_access_specifier = access_private_node;
else if (TREE_PROTECTED (TYPE_NAME (enumtype)))
current_access_specifier = access_protected_node;
else
current_access_specifier = access_public_node;
finish_member_declaration (decl);
current_access_specifier = saved_cas;
}
For dwarf2out purposes the extra CONST_DECL doesn't mean anything, because it
is ignored for non-fortran/ada. So, either we change the type verifier to
ignore extra CONST_DECLs among TYPE_FIELDS, or if we have some way in the FE
how to figure out if fixup_type_variants has been already called or will be
still called, then we could for the case where it has been called already call
it again or just update TYPE_FIELDS manually on the variant types, or append to
TYPE_FIELDS rather than prepend if the type has been finalized already.
[Bug c++/77337] [7 regression][c++1z] use before deduction of 'auto'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77337 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-11-10 Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug middle-end/78295] [7 Regression] Spurious -Wuninitialized warning for vector element assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78295 Marc Glisse changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-10 Ever confirmed|0 |1 --- Comment #1 from Marc Glisse --- (also noticed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59650#c2) We already seem to have special code for half-initialized complex numbers.
[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267
--- Comment #18 from Dominique d'Humieres ---
> Created attachment 40013 [details]
> proposed fixincludes-based patch
>
> The attached patch passes fixincludes make check. I'll have to wait until
> tonight to test it for real on macOS 10.12, though.
Bootstrap is still broken with the patch:
libtool: compile: /opt/gcc/build_w/./gcc/xgcc -shared-libgcc
-B/opt/gcc/build_w/./gcc -nostdinc++
-L/opt/gcc/build_w/x86_64-apple-darwin16.1.0/libstdc++-v3/src
-L/opt/gcc/build_w/x86_64-apple-darwin16.1.0/libstdc++-v3/src/.libs
-L/opt/gcc/build_w/x86_64-apple-darwin16.1.0/libstdc++-v3/libsupc++/.libs
-B/opt/gcc/gcc7w/x86_64-apple-darwin16.1.0/bin/
-B/opt/gcc/gcc7w/x86_64-apple-darwin16.1.0/lib/ -isystem
/opt/gcc/gcc7w/x86_64-apple-darwin16.1.0/include -isystem
/opt/gcc/gcc7w/x86_64-apple-darwin16.1.0/sys-include -D_GNU_SOURCE -D_DEBUG
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-DHAVE_RPC_XDR_H=0 -DHAVE_TIRPC_RPC_XDR_H=0 -I.
-I../../../../work/libsanitizer/sanitizer_common -I.. -I
../../../../work/libsanitizer/include -isystem
../../../../work/libsanitizer/include/system -Wall -W -Wno-unused-parameter
-Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions
-fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden
-Wno-variadic-macros -I../../libstdc++-v3/include
-I../../libstdc++-v3/include/x86_64-apple-darwin16.1.0
-I../../../../work/libsanitizer/../libstdc++-v3/libsupc++ -std=gnu++11 -g -O2
-MT sanitizer_mac.lo -MD -MP -MF .deps/sanitizer_mac.Tpo -c
../../../../work/libsanitizer/sanitizer_common/sanitizer_mac.cc -fno-common
-DPIC -o .libs/sanitizer_mac.o
In file included from
../../../../work/libsanitizer/sanitizer_common/sanitizer_mac.cc:39:0:
/usr/include/os/trace.h:204:15: error: expected unqualified-id before '^' token
typedef void (^os_trace_payload_t)(xpc_object_t xdict);
^
/usr/include/os/trace.h:204:15: error: expected ')' before '^' token
In file included from /usr/include/Availability.h:180:0,
from /usr/include/stdio.h:65,
from
../../../../work/libsanitizer/sanitizer_common/sanitizer_mac.cc:21:
/usr/include/os/trace.h:302:1: error: 'introduced' was not declared in this
scope
__API_AVAILABLE(macosx(10.12), ios(10.0), watchos(3.0), tvos(10.0))
^
/usr/include/os/trace.h:302:1: error: 'introduced' was not declared in this
scope
__API_AVAILABLE(macosx(10.12), ios(10.0), watchos(3.0), tvos(10.0))
^
/usr/include/os/trace.h:302:1: error: 'introduced' was not declared in this
scope
__API_AVAILABLE(macosx(10.12), ios(10.0), watchos(3.0), tvos(10.0))
^
...
/usr/include/asl.h:1086:147: error: 'message' was not declared in this scope
asl_object_t asl_match(asl_object_t data, asl_object_t querylist, size_t
*last, size_t start, size_t count, uint32_t duration, int32_t direction)
__API_DEPRECATED("os_log(3) has replaced asl(3)", macosx(10.10,10.12),
ios(8.0,10.0), watchos(2.0,3.0), tvos(9.0,10.0));
^
/usr/include/asl.h:1086:147: note: suggested alternative: 'rusage'
../../../../work/libsanitizer/sanitizer_common/sanitizer_mac.cc: In function
'void __sanitizer::LogFullErrorReport(const char*)':
../../../../work/libsanitizer/sanitizer_common/sanitizer_mac.cc:505:53:
warning: suggest braces around empty body in an 'else' statement [-Wempty-bod]
os_trace("Sanitizer tool reported a failure.");
^
../../../../work/libsanitizer/sanitizer_common/sanitizer_mac.cc:508:55:
warning: suggest braces around empty body in an 'if' statement [-Wempty-body]
os_trace("Consult syslog for more information.");
^
make[4]: *** [sanitizer_mac.lo] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-target-libsanitizer] Error 2
make: *** [all] Error 2
[Bug middle-end/78295] [7 Regression] Spurious -Wuninitialized warning for vector element assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78295 Joseph S. Myers changed: What|Removed |Added Target Milestone|--- |7.0
[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267 --- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #18 from Dominique d'Humieres --- [...] > Bootstrap is still broken with the patch: [...] Did you regen fixincl.x (with ./genfixes in the source tree)? A macOS 10.12 bootstrap is currently running: the fix for isn't complete. I'd based it on an older version off opensource.apple.com. I'll post a fixed version once it's ready. Rainer
[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267 --- Comment #20 from Dominique d'Humieres --- > Did you regen fixincl.x (with ./genfixes in the source tree)? I did a clean bootstrap, but I did know that I had to run ./genfixes. BTW you probably mean ./fixincludes/genfixes, isn't it? I am currently bootstrapping again with the patch in comment 15: machine busy for the next 2 hours.
[Bug fortran/78297] New: ICE in finish_equivalences, at fortran/trans-common.c:1246
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78297 Bug ID: 78297 Summary: ICE in finish_equivalences, at fortran/trans-common.c:1246 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- Gives an ICE down to at least 4.8 : $ cat z1.f90 module m real :: a(2), b(2) real :: c(2), d(2) equivalence (a, b) equivalence (c, d) common /xcom/ a end block data use m end block data $ gfortran-7-20161106 -c z1.f90 z1.f90:10:0: end block data internal compiler error: Segmentation fault 0xc3a64f crash_signal ../../gcc/toplev.c:338 0x747490 finish_equivalences ../../gcc/fortran/trans-common.c:1246 0x747490 gfc_trans_common(gfc_namespace*) ../../gcc/fortran/trans-common.c:1289 0x74d1b0 gfc_generate_block_data(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6524 0x6e2133 gfc_parse_file() ../../gcc/fortran/parse.c:6102 0x725822 gfc_be_parse_file ../../gcc/fortran/f95-lang.c:198
[Bug fortran/78297] ICE in finish_equivalences, at fortran/trans-common.c:1246
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78297 --- Comment #1 from Gerhard Steinmetz --- Compiles with both items in common block. $ cat z2.f90 module m real :: a(2), b(2) real :: c(2), d(2) equivalence (a, b) equivalence (c, d) common /xcom/ a, c end block data use m end block data
[Bug fortran/78298] New: ICE in lookup_decl_in_outer_ctx, bei omp-low.c:4115
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78298 Bug ID: 78298 Summary: ICE in lookup_decl_in_outer_ctx, bei omp-low.c:4115 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- Gives an ICE down to at least 4.8, at -Og, -Os, -O1 or higher. Effectively legal code, but program contains an (here unused) internal subroutine/function with access to some variables. $ cat z1.f90 program p integer :: i, j, n n = 2 !$omp parallel !$omp do do i = 1, n !$omp parallel !$omp do do j = 1, n call sub(i) end do !$omp end parallel end do !$omp end parallel !call unused() contains subroutine sub(x) integer :: x end subroutine unused() i = 0 j = 0 end end $ gfortran-7-20161106 -fopenmp -O2 z1.f90 z1.f90:7:0: !$omp parallel internal compiler error: in lookup_decl_in_outer_ctx, at omp-low.c:4115 0xb1df28 lookup_decl_in_outer_ctx ../../gcc/omp-low.c:4115 0xb407a3 lower_send_shared_vars ../../gcc/omp-low.c:6259 0xb407a3 lower_omp_taskreg ../../gcc/omp-low.c:15681 0xb32306 lower_omp_1 ../../gcc/omp-low.c:17033 0xb32306 lower_omp ../../gcc/omp-low.c:17177 0xb3200c lower_omp_1 ../../gcc/omp-low.c:17025 0xb3200c lower_omp ../../gcc/omp-low.c:17177 0xb4246d lower_omp_for ../../gcc/omp-low.c:15133 0xb324d6 lower_omp_1 ../../gcc/omp-low.c:17040 0xb324d6 lower_omp ../../gcc/omp-low.c:17177 0xb3200c lower_omp_1 ../../gcc/omp-low.c:17025 0xb3200c lower_omp ../../gcc/omp-low.c:17177 0xb403aa lower_omp_taskreg ../../gcc/omp-low.c:15659 0xb32306 lower_omp_1 ../../gcc/omp-low.c:17033 0xb32306 lower_omp ../../gcc/omp-low.c:17177 0xb3166c lower_omp_1 ../../gcc/omp-low.c:17016 0xb3166c lower_omp ../../gcc/omp-low.c:17177 0xb3200c lower_omp_1 ../../gcc/omp-low.c:17025 0xb3200c lower_omp ../../gcc/omp-low.c:17177 0xb391ef execute_lower_omp ../../gcc/omp-low.c:17912
[Bug rtl-optimization/78241] [7 Regression] wrong code with -funroll-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78241 --- Comment #3 from Pat Haugen --- Author: pthaugen Date: Thu Nov 10 18:55:57 2016 New Revision: 242047 URL: https://gcc.gnu.org/viewcvs?rev=242047&root=gcc&view=rev Log: PR rtl-optimization/78241 * loop-unroll.c (unroll_loop_runtime_iterations): Don't adjust 'niter', but emit initial peel copy if niter expr is not reliable. * gcc.dg/pr78241.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr78241.c Modified: trunk/gcc/ChangeLog trunk/gcc/loop-unroll.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/78241] [7 Regression] wrong code with -funroll-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78241 Pat Haugen changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Pat Haugen --- Fixed.
[Bug fortran/78299] New: ICE in expand_omp_for_static_nochunk, at omp-low.c:9622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78299 Bug ID: 78299 Summary: ICE in expand_omp_for_static_nochunk, at omp-low.c:9622 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- Invalid code affects version 6 and 7 in combination with option -fcheck=all or -fcheck=bounds : $ cat z1.f90 program p integer, parameter :: n = 8 integer :: i, j real :: x(n), y(n) x = 1.0 y = 2.0 do j = 1, 9 !$omp parallel workshare !$omp parallel default(shared) !$omp do do i = 1, n x(i) = x(i) * y(9) end do !$omp end do !$omp end parallel !$omp end parallel workshare end do end $ cat z2.f90 program p integer, parameter :: n = 8 integer :: i, j real :: x(n), y(n) x = 1.0 y = 2.0 do j = 1, 9 !$omp parallel do do i = 1, n x(i) = x(i) * y(9) end do !$omp end parallel do end do end $ gfortran-7-20161106 -fopenmp -fcheck=all z1.f90 z1.f90:12:25: x(i) = x(i) * y(9) 1 Warning: Array reference at (1) is out of bounds (9 > 8) in dimension 1 z1.f90:10:0: !$omp do internal compiler error: in expand_omp_for_static_nochunk, at omp-low.c:9622 0xb1402b expand_omp_for_static_nochunk ../../gcc/omp-low.c:9622 0xb2ae64 expand_omp_for ../../gcc/omp-low.c:11596 0xb2b47a expand_omp ../../gcc/omp-low.c:13826 0xb2b230 expand_omp ../../gcc/omp-low.c:13812 0xb2b230 expand_omp ../../gcc/omp-low.c:13812 0xb2b230 expand_omp ../../gcc/omp-low.c:13812 0xb2daed execute_expand_omp ../../gcc/omp-low.c:14051
[Bug fortran/78300] New: Failure to compile a Fortran-2003 code with an optional dummy procedure argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78300 Bug ID: 78300 Summary: Failure to compile a Fortran-2003 code with an optional dummy procedure argument. Product: gcc Version: 6.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: liakhdi at ornl dot gov Target Milestone: --- Source code: https://gitlab.com/DmitryLyakh/GFC.git The minimal reproducer can be created by taking only three source files from GFC: gfortran -c dil_basic.F90 gfortran -c timers.F90 gfortran -c -DNO_GNU gfc_base.F90 (GFORTRAN fails to compile if you define -DNO_GNU) If you look inside gfc_base.F90 line 240 (subroutine ContElemConstruct), you will see the exact place where the compile error occurs. For some reason, it has problems with an optional dummy procedure argument. I believe this is a compiler bug. All other compilers I tried compile and run the code fine (Cray, PGI, XL, probably Intel as well). Please help fixing this problem in gfortran. Thanks!
[Bug fortran/78277] ICE in is_anonymous_component, at fortran/interface.c:450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78277 --- Comment #3 from Fritz Reese --- Created attachment 40016 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40016&action=edit patch for pr78277 > https://gcc.gnu.org/ml/fortran/2016-11/msg00087.html Patch proposed, will commit soon unless someone finds issue with it.
[Bug fortran/78277] ICE in is_anonymous_component, at fortran/interface.c:450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78277 Fritz Reese changed: What|Removed |Added Status|ASSIGNED|WAITING
[Bug fortran/78300] Failure to compile a Fortran-2003 code with an optional dummy procedure argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78300 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- (In reply to DIL from comment #0) > Source code: https://gitlab.com/DmitryLyakh/GFC.git > Please attach the source to the PR.
[Bug fortran/78300] Failure to compile a Fortran-2003 code with an optional dummy procedure argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78300 --- Comment #2 from DIL --- Created attachment 40017 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40017&action=edit Source file
[Bug fortran/78300] Failure to compile a Fortran-2003 code with an optional dummy procedure argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78300 --- Comment #3 from DIL --- Created attachment 40018 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40018&action=edit Source file
[Bug fortran/78300] Failure to compile a Fortran-2003 code with an optional dummy procedure argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78300 --- Comment #4 from DIL --- Created attachment 40019 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40019&action=edit Source file
[Bug sanitizer/78267] [7 Regression] libsanitizer breaks bootstrap on x86_64-apple-darwin16 at r241977
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267 --- Comment #21 from Dominique d'Humieres --- > Created attachment 40012 [details] > Untested fix 2. Bootstrap completed successfully with this patch.
[Bug c++/78301] New: noexcept() operator rejects sibling method call without object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78301
Bug ID: 78301
Summary: noexcept() operator rejects sibling method call
without object
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: TonyELewis at hotmail dot com
Target Milestone: ---
This code fails to compile under g++ (including "gcc HEAD 7.0.0 201611" on
http://melpon.org/wandbox):
struct a {
void inner() const {}
void outer() const noexcept( noexcept( inner() ) ) {
inner();
}
};
with the error:
a.cpp:3:47: error: cannot call member function ‘void a::inner() const’ without
object
void outer() const noexcept( noexcept( inner() ) ) {
^
Both Clang and MSVC accept this code, presumably treating the call to inner()
in the same way to the call in the body of outer(). This seems sensible. Is
there any principled reason g++ rejects it. If not, please can g++ be altered
to handle this inline with Clang and MSVC? Many thanks.
[Bug fortran/78300] Failure to compile a Fortran-2003 code with an optional dummy procedure argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78300 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-10 Ever confirmed|0 |1 --- Comment #5 from Dominique d'Humieres --- Confirmed from 4.8 up to trunk (7.0). It would be nice to have a reduced reproducer.
[Bug fortran/78300] Failure to compile a Fortran-2003 code with an optional dummy procedure argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78300 --- Comment #6 from Steve Kargl --- On Thu, Nov 10, 2016 at 09:06:15PM +, dominiq at lps dot ens.fr wrote: > > Confirmed from 4.8 up to trunk (7.0). It would be nice to have a reduced > reproducer. > I certainly agree with! It took a bit to get this. module gfc_base implicit none integer, parameter:: INTD=4 integer, parameter:: INTL=8 integer(INTD), parameter :: GFC_TRUE=1, GFC_FALSE=0 type gfc_cont_elem_t class(*), pointer, private:: value_p=>NULL() integer(INTD), private:: alloc=GFC_FALSE contains procedure, public:: construct=>ContElemConstruct end type gfc_cont_elem_t abstract interface function gfc_copy_i(obj,ierr) result(clone) import:: INTD class(*), pointer:: clone class(*), intent(in):: obj integer(INTD), intent(out), optional:: ierr end function gfc_copy_i end interface private ContElemConstruct contains subroutine ContElemConstruct(this,obj,ierr,assoc_only,copy_constr_func) class(gfc_cont_elem_t), intent(inout):: this class(*), target, intent(in):: obj integer(INTD), intent(out), optional:: ierr logical, intent(in), optional:: assoc_only procedure(gfc_copy_i), optional:: copy_constr_func end subroutine ContElemConstruct end module gfc_base
[Bug libstdc++/77459] [6/7 Regression] undefined reference to `snprintf' when building mingw-w64 cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77459 François Dumont changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |fdumont at gcc dot gnu.org --- Comment #9 from François Dumont --- Fix with rev 242055 which simply remove format_word method.
[Bug fortran/78300] Failure to compile a Fortran-2003 code with an optional dummy procedure argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78300
--- Comment #7 from Steve Kargl ---
Here's a patch that allows the reduced testcase compile.
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 241667)
+++ gcc/fortran/resolve.c (working copy)
@@ -11719,7 +11719,8 @@ resolve_fl_var_and_proc (gfc_symbol *sym
/* Assume that use associated symbols were checked in the module ns.
Class-variables that are associate-names are also something special
and excepted from the test. */
- if (!sym->attr.class_ok && !sym->attr.use_assoc && !sym->assoc)
+ if (!sym->attr.class_ok && !sym->attr.use_assoc && !sym->attr.dummy
+ && !sym->assoc)
{
gfc_error ("CLASS variable %qs at %L must be dummy, allocatable "
"or pointer", sym->name, &sym->declared_at);
[Bug c++/77337] [7 regression][c++1z] use before deduction of 'auto'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77337 --- Comment #2 from Jason Merrill --- Author: jason Date: Thu Nov 10 21:42:36 2016 New Revision: 242056 URL: https://gcc.gnu.org/viewcvs?rev=242056&root=gcc&view=rev Log: PR c++/77337 - auto return and lambda * pt.c (tsubst_friend_function): Don't set DECL_INITIAL. (instantiate_decl): It's OK to defer a constexpr function. * cp-tree.h (DECL_FRIEND_PSEUDO_TEMPLATE_INSTANTIATION): Check DECL_LANG_SPECIFIC. * decl2.c (decl_defined_p): Use it. No longer static. * decl.c (redeclaration_error_message): Use decl_defined_p. * constexpr.c (cxx_eval_call_expression): Set input_location around call to instantiate_decl. Added: trunk/gcc/testsuite/g++.dg/cpp1y/auto-fn33.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/decl2.c trunk/gcc/cp/pt.c
[Bug c++/77337] [7 regression][c++1z] use before deduction of 'auto'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77337 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jason Merrill --- Fixed.
[Bug fortran/78277] ICE in is_anonymous_component, at fortran/interface.c:450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78277 --- Comment #4 from Fritz Reese --- Author: foreese Date: Thu Nov 10 21:57:13 2016 New Revision: 242058 URL: https://gcc.gnu.org/viewcvs?rev=242058&root=gcc&view=rev Log: Fix ICE and improve errors for invalid anonymous structure declarations. PR fortran/78277 * gcc/fortran/decl.c (gfc_match_data_decl): Gracefully handle bad anonymous structure declarations. PR fortran/78277 * gcc/testsuite/gfortran.dg/dec_structure_17.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/dec_structure_17.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/78277] ICE in is_anonymous_component, at fortran/interface.c:450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78277 Fritz Reese changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug libstdc++/78302] New: is_move_constructible_v> should be false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78302
Bug ID: 78302
Summary: is_move_constructible_v> should be
false
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
#include
#include
struct nonmovable
{
nonmovable(nonmovable&&) = delete;
};
static_assert(!std::is_move_constructible_v>); //fires
It's not clear whether this is required by the standard (the standard depicts a
defaulted move constructor, and core language rules say that a defaulted move
constructor is defined as deleted if a subobject cannot be moved), but in any
event this should probably return false as a QoI matter.
[Bug fortran/78300] Failure to compile a Fortran-2003 code with an optional dummy procedure argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78300 --- Comment #8 from DIL --- Is there a way to download the GCC source with this patch applied?
[Bug ipa/78296] [7 regression] test case gcc.dg/ipa/vrp7.c fails starting with r242032
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78296 kugan at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |kugan at gcc dot gnu.org --- Comment #1 from kugan at gcc dot gnu.org --- (In reply to Bill Seurer from comment #0) > spawn /home/seurer/gcc/build/gcc-test2/gcc/xgcc > -B/home/seurer/gcc/build/gcc-test2/gcc/ > /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/ipa/vrp7.c > -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 > -fdump-ipa-cp-details -S -o vrp7.s > PASS: gcc.dg/ipa/vrp7.c (test for excess errors) > FAIL: gcc.dg/ipa/vrp7.c scan-ipa-dump-times cp "Setting value range of param > 0 \\[-10, 9\\]" 1 > > === gcc Summary === > > # of expected passes 1 > # of unexpected failures 1 Thanks for the report. This is expected as I have reverted r241990 which does this optimization. I will repost r241990 when I have fixed the bootstrap comparison issue at the earliest.
[Bug fortran/78297] ICE in finish_equivalences, at fortran/trans-common.c:1246
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78297 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-10 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Confirmed from 4.8 up to trunk (7.0).
[Bug rtl-optimization/78232] [7 Regression] FAIL: gcc.dg/torture/pr48124-4.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78232 --- Comment #3 from Segher Boessenkool --- Author: segher Date: Thu Nov 10 22:45:39 2016 New Revision: 242059 URL: https://gcc.gnu.org/viewcvs?rev=242059&root=gcc&view=rev Log: combine: Do not call simplify from inside change_zero_ext (PR78232) When combine splits a three-insn combination into two instructions it can reuse i2dest for the temporary result of the first new instruction. However all information it has in reg_stat about that register will be stale. This results in the simplify_gen_binary calls in change_zero_ext using out-of-date information, which makes it think one of the ANDs generated there always results in 0, and it doesn't get better from there. This can also happen if a splitter in the MD uses nonzero_bits (for example). I tried to make the splitting code in combine save and restore the i2dest reg_stat info, but that causes one of the acats tests to fail. This whole reg_stat thing needs an overhaul, and/or we shouldn't reuse i2dest for unrelated purposes when splitting. This patch changes change_zero_ext to do the expected simplifications itself and not call simplify_gen_*. PR rtl-optimization/78232 * combine.c (try_combine): Add a big comment about why reusing i2dest is undesirable. (change_zero_ext): Do not call simplify_gen_binary, do the simplifications manually. Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c
[Bug fortran/78300] Failure to compile a Fortran-2003 code with an optional dummy procedure argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78300 --- Comment #9 from Steve Kargl --- On Thu, Nov 10, 2016 at 10:40:15PM +, liakhdi at ornl dot gov wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78300 > > --- Comment #8 from DIL --- > Is there a way to download the GCC source with this patch applied? > Not yet. I won't have time to apply the patch until tomorrow or Saturday. I posted the patch to bugzilla so it does not get lost. Once it is in the source tree, you can use svn to pull the source down.
[Bug fortran/78300] Failure to compile a Fortran-2003 code with an optional dummy procedure argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78300 --- Comment #10 from DIL --- Thanks!
[Bug fortran/78300] Failure to compile a Fortran-2003 code with an optional dummy procedure argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78300 --- Comment #11 from Dominique d'Humieres --- > Not yet. I won't have time to apply the patch until > tomorrow or Saturday. I posted the patch to bugzilla > so it does not get lost. Once it is in the source tree, > you can use svn to pull the source down. You can also pull the source down and apply the patch yourself.
[Bug fortran/77414] ICE in create_function_arglist, at fortran/trans-decl.c:2410
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77414 --- Comment #4 from Dominique d'Humieres --- > The tests z7.f90, z8.f90, and z9.f90 compiles without error > at revision r242002 although I think they are invalid. > They give an ICE with r241962. This is due to r241972 (pr77596).
[Bug fortran/78300] Failure to compile a Fortran-2003 code with an optional dummy procedure argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78300 --- Comment #12 from DIL --- Indeed, thanks again.
[Bug fortran/44348] ICE in build_function_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44348 --- Comment #14 from Dominique d'Humieres --- > The test in comment 2 compiles without error at revision r242002 > although I think it is invalid. It gives an ICE with r241962. This is due to r241972 (pr77596).
[Bug libstdc++/78302] is_move_constructible_v> should be false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78302 --- Comment #1 from Marc Glisse --- See also PR 71301.
[Bug c/37998] Unclear documentation of -fno-common
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37998 --- Comment #1 from sandra at gcc dot gnu.org --- Author: sandra Date: Thu Nov 10 23:56:30 2016 New Revision: 242062 URL: https://gcc.gnu.org/viewcvs?rev=242062&root=gcc&view=rev Log: 2016-11-10 Sandra Loosemore PR c/37998 gcc/ * doc/invoke.texi (Code Gen Options) [-fno-common]: Use correct terminology. Expand to remove ambiguity. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi
[Bug c++/78264] [7 regression] ICE in build_noexcept_spec, at cp/except.c:1196
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78264 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-11-11 CC||aldyh at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Aldy Hernandez --- As Solaris boxes with their header files are not readily available (at least to me), would you mind attaching a preprocessed reduced testcase exhibiting the behavior? Thanks.
[Bug libstdc++/78302] is_move_constructible_v> should be false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78302 --- Comment #2 from TC --- Ugh, quasi-dup, I suppose. But if I'm reading the correspondence correctly, the ABI breaking is only because of triviality, correct? So if we just want to make is_move_constructible not lie, it should be possible to do something like adding an empty base at the top level that is either movable or not depending on __and_...> so that the tuple(tuple&&) =default; will become deleted for nonmovable elements?
[Bug middle-end/78225] [7 Regression] FAIL: gcc.dg/gomp/pr27573.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78225
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed||2016-11-11
CC||aldyh at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Aldy Hernandez ---
I cannot reproduce on a cross build with --target=hppa-unknown-linux-gnu. Is
this problem still present in mainline, but is not reproducible with a cross
build?
tor~/bld/t/gcc$ ./cc1 a.c -quiet -fno-diagnostics-show-caret
-fdiagnostics-color=never -O2 -fopenmp -fprofile-generate -I.
tor~/bld/t/gcc$ ./cc1plus a.c -quiet -fno-diagnostics-show-caret
-fdiagnostics-color=never -O2 -fopenmp -fprofile-generate -I.
tor~/bld/t/gcc$ cat a.c
/* PR middle-end/27573 */
/* { dg-do compile } */
/* { dg-require-profiling "-fprofile-generate" } */
/* { dg-options "-O2 -fopenmp -fprofile-generate" } */
extern int puts (const char *);
int
main (void)
{
int i, j = 8;
#pragma omp parallel
{
puts ("foo");
for (i = 1; i < j - 1; i++)
;
}
return 0;
}
[Bug rtl-optimization/78127] [5/6/7 Regression] AArch64 internal compiler error: in lra_eliminate, at lra-eliminations.c:1440
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78127 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-11-11 CC||aldyh at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Aldy Hernandez --- Confirmed with a cross build.
