[Bug testsuite/68751] FAIL: gcc.dg/sancov/asan.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68751 --- Comment #2 from Dmitry Vyukov --- Mailed a fix yesterday: https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00671.html
[Bug middle-end/68291] [6 regression] ICE in emit_move_insn, at expr.c:3540
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68291 --- Comment #11 from Eric Botcazou --- > I'm not comfortable with your relaxing the assert in cfgexpand.c:set_rtl. > It means we could have a PARALLEL for a RESULT_DECL *and* other variables, > because of coalescing. Although we can deal with PARALLELs in a > RESULT_DECL, not all expanders will deal with them successfully, IIRC. Relaxing the assert is required by the ABI though, for vector types with BLKmode that are returned in multiple registers. The alternative would be to smuggle them temporarily into a single register with large integer mode, but that would be a little kludgy. Or to declare that vector types with BLKmode are not GIMPLE register types, but that looks overkill and undesirable in the end. > We should make sure the RESULT_DECL is not coalesced with other variables if > we > are to accept a PARALLEL there. It's not obvious to me that we already do > that, but maybe we do as a side effect of assigning other variables of the > same mode to BLKmode and thus to memory, so it might be that it's not a > problem, after all, but I'd rather have at least a comment in the assert > indicating that the intent of that case is to cover uncoalesced PARALLELs in > RESULT_DECLs only. If we did get coalescing, we would likely get expander > ICEs elsewhere. Yes, that's my thinking too, we'll get ICEs downstream if something is missing in the machinery. I'm going to add the comment.
[Bug c/68757] New: [6 Regression] Use of uninitialised value of size 8 in get_combined_adhoc_loc (line-map.c:214)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68757 Bug ID: 68757 Summary: [6 Regression] Use of uninitialised value of size 8 in get_combined_adhoc_loc (line-map.c:214) Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Hello. This is probably very similar problem related to PR68438. $ valgrind --leak-check=yes --trace-children=yes ./gcc/xgcc -Bgcc /home/marxin/Programming/gcc3/gcc/testsuite/gcc.dg/Wconversion-complex-c99.c produces: ==20170== Use of uninitialised value of size 8 ==20170==at 0x107DB13: htab_find_slot_with_hash (hashtab.c:655) ==20170==by 0x104B3AC: get_combined_adhoc_loc(line_maps*, unsigned int, source_range, void*) (line-map.c:214) ==20170==by 0xBC43B8: COMBINE_LOCATION_DATA (line-map.h:1007) ==20170==by 0xBC43B8: set_source_range(tree_node*, source_range) (tree.c:13957) ==20170==by 0xBC43E1: set_source_range(tree_node*, unsigned int, unsigned int) (tree.c:13944) ==20170==by 0x610A78: set_c_expr_source_range (c-parser.c:69) ==20170==by 0x610A78: c_parser_expr_no_commas(c_parser*, c_expr*, tree_node*) (c-parser.c:6153) ==20170==by 0x610EB2: c_parser_expression(c_parser*) (c-parser.c:8262) ==20170==by 0x611689: c_parser_expression_conv(c_parser*) (c-parser.c:8295) ==20170==by 0x609D8C: c_parser_statement_after_labels(c_parser*, vec*) (c-parser.c:5178) ==20170==by 0x60BD03: c_parser_compound_statement_nostart(c_parser*) (c-parser.c:4763) ==20170==by 0x61CA8E: c_parser_compound_statement(c_parser*) (c-parser.c:4599) ==20170==by 0x608EE8: c_parser_declaration_or_fndef(c_parser*, bool, bool, bool, bool, bool, tree_node**, vec, tree_node*) (c-parser.c:2017) ==20170==by 0x62147D: c_parser_external_declaration(c_parser*) (c-parser.c:1461) ==20170== ==20170== Conditional jump or move depends on uninitialised value(s) ==20170==at 0x107DBA2: htab_find_slot_with_hash (hashtab.c:668) ==20170==by 0x104B3AC: get_combined_adhoc_loc(line_maps*, unsigned int, source_range, void*) (line-map.c:214) ==20170==by 0xBC43B8: COMBINE_LOCATION_DATA (line-map.h:1007) ==20170==by 0xBC43B8: set_source_range(tree_node*, source_range) (tree.c:13957) ==20170==by 0xBC43E1: set_source_range(tree_node*, unsigned int, unsigned int) (tree.c:13944) ==20170==by 0x610A78: set_c_expr_source_range (c-parser.c:69) ==20170==by 0x610A78: c_parser_expr_no_commas(c_parser*, c_expr*, tree_node*) (c-parser.c:6153) ==20170==by 0x610EB2: c_parser_expression(c_parser*) (c-parser.c:8262) ==20170==by 0x611689: c_parser_expression_conv(c_parser*) (c-parser.c:8295) ==20170==by 0x609D8C: c_parser_statement_after_labels(c_parser*, vec*) (c-parser.c:5178) ==20170==by 0x60BD03: c_parser_compound_statement_nostart(c_parser*) (c-parser.c:4763) ==20170==by 0x61CA8E: c_parser_compound_statement(c_parser*) (c-parser.c:4599) ==20170==by 0x608EE8: c_parser_declaration_or_fndef(c_parser*, bool, bool, bool, bool, bool, tree_node**, vec, tree_node*) (c-parser.c:2017) ==20170==by 0x62147D: c_parser_external_declaration(c_parser*) (c-parser.c:1461) Thanks, Martin
[Bug middle-end/68697] [6 regression] CHKP] Many vararg-*.c tests fail (bounds violation is not detected)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68697 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0 Summary|[6 regression, CHKP] Many |[6 regression] CHKP] Many |vararg-*.c tests fail |vararg-*.c tests fail |(bounds violation is not|(bounds violation is not |detected) |detected)
[Bug target/68698] [6 regression] FAIL: gcc.target/i386/avx512vl-vmovap[sd]-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68698 Richard Biener changed: What|Removed |Added Target||x86_64-*-*, i?86-*-* Target Milestone|--- |6.0 Summary|[6 regression, i386] FAIL: |[6 regression] FAIL: |gcc.target/i386/avx512vl-vm |gcc.target/i386/avx512vl-vm |ovap[sd]-1.c|ovap[sd]-1.c
[Bug target/68701] [4.9/5/6 Regression] "gcc -m32 -finstrument-functions -ffixed-ebp" produces internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68701 Richard Biener changed: What|Removed |Added Target||i?86-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-07 Component|c |target Target Milestone|--- |4.9.4 Summary|"gcc -m32 |[4.9/5/6 Regression] "gcc |-finstrument-functions |-m32 -finstrument-functions |-ffixed-ebp" produces |-ffixed-ebp" produces |internal compiler error |internal compiler error Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug middle-end/55035] reload1.c:3766:41: error: ‘orig_dup[0]’ may be used uninitialized in this function (for fr30, microblaze, moxie, rl78)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55035 Eric Botcazou changed: What|Removed |Added Status|REOPENED|RESOLVED CC||ebotcazou at gcc dot gnu.org Resolution|--- |FIXED --- Comment #13 from Eric Botcazou --- SPARC 64-bit bootstrap works for me.
[Bug bootstrap/44756] [meta-bug] --enable-werror-always issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44756 Bug 44756 depends on bug 55035, which changed state. Bug 55035 Summary: reload1.c:3766:41: error: ‘orig_dup[0]’ may be used uninitialized in this function (for fr30, microblaze, moxie, rl78) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55035 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED
[Bug c++/68703] __attribute__((vector_size(N))) template member confusion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68703 Richard Biener changed: What|Removed |Added Keywords||rejects-valid --- Comment #1 from Richard Biener --- Looks like v is not properly detected as dependent?
[Bug tree-optimization/52361] gcc.dg/pr48141.c times out with checking enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52361 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot gnu.org Resolution|--- |FIXED --- Comment #8 from Eric Botcazou --- Presumably (I have never seen it).
[Bug tree-optimization/68707] [6 Regression] testcase gcc.dg/vect/O3-pr36098.c vectorized using VEC_PERM_EXPR rather than VEC_LOAD_LANES
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68707 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-12-07 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |6.0 Summary|testcase|[6 Regression] testcase |gcc.dg/vect/O3-pr36098.c|gcc.dg/vect/O3-pr36098.c |vectorized using|vectorized using |VEC_PERM_EXPR rather than |VEC_PERM_EXPR rather than |VEC_LOAD_LANES |VEC_LOAD_LANES Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- Ok, I will think of some heuristic to drop SLP in favor of interleaving.
[Bug c++/68711] [6 regression] SEGV on an invalid offsetof of a member of a virtual base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68711 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0 Summary|[5 regression] SEGV on an |[6 regression] SEGV on an |invalid offsetof of a |invalid offsetof of a |member of a virtual base|member of a virtual base
[Bug bootstrap/68708] [6 Regression] profiledbootstrap failure with --with-build-config=bootstrap-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68708 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #2 from Richard Biener --- I think Honza has fixed this with 2015-12-05 Jan Hubicka * ipa-icf.c (sem_function::merge): Check that local_original exists.
[Bug tree-optimization/68671] [5 Regression] gcc.dg/torture/pr66952.c FAILs with -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68671 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Mon Dec 7 08:58:24 2015 New Revision: 231356 URL: https://gcc.gnu.org/viewcvs?rev=231356&root=gcc&view=rev Log: Backported from mainline 2015-12-04 Jakub Jelinek PR tree-optimization/68671 * tree-ssa-reassoc.c (maybe_optimize_range_tests): For basic blocks starting with the successor of first bb we've modified and ending with last_bb call reset_flow_sensitive_info_in_bb. * gcc.dg/pr68671.c: New test. Added: branches/gcc-5-branch/gcc/testsuite/gcc.dg/pr68671.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/testsuite/ChangeLog branches/gcc-5-branch/gcc/tree-ssa-reassoc.c
[Bug pch/68758] New: [6 Regression] Invalid read of size 8 in gt_pch_save (ggc-common.c:551)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68758 Bug ID: 68758 Summary: [6 Regression] Invalid read of size 8 in gt_pch_save (ggc-common.c:551) Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: pch Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Hello. Pre-compiled header produces many invalid operations: $ echo '#include ' > /tmp/a.c && valgrind --leak-check=yes --trace-children=yes ./gcc/xgcc -Bgcc -c -x c-header /tmp/a.c ==7532== ==7532== Invalid read of size 8 ==7532==at 0x4C2C2C8: _intel_fast_memcpy (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==7532==by 0x7D7332: gt_pch_save(_IO_FILE*) (ggc-common.c:551) ==7532==by 0x55: c_common_write_pch() (c-pch.c:183) ==7532==by 0x666217: c_common_parse_file() (c-opts.c:1065) ==7532==by 0x9D05CE: compile_file() (toplev.c:464) ==7532==by 0x5C8980: do_compile (toplev.c:1977) ==7532==by 0x5C8980: toplev::main(int, char**) (toplev.c:2084) ==7532==by 0x5CAC46: main (main.c:39) ==7532== Address 0x66a3000 is not stack'd, malloc'd or (recently) free'd ==7532== ==7532== Invalid read of size 8 ==7532==at 0x5E2137F: __GI_mempcpy (in /lib64/libc-2.22.so) ==7532==by 0x5E102C7: _IO_file_xsputn@@GLIBC_2.2.5 (in /lib64/libc-2.22.so) ==7532==by 0x5E060EA: fwrite (in /lib64/libc-2.22.so) ==7532==by 0x67E4CC: ggc_pch_write_object(ggc_pch_data*, _IO_FILE*, void*, void*, unsigned long, bool) (ggc-page.c:2456) ==7532==by 0x7D73B1: gt_pch_save(_IO_FILE*) (ggc-common.c:561) ==7532==by 0x55: c_common_write_pch() (c-pch.c:183) ==7532==by 0x666217: c_common_parse_file() (c-opts.c:1065) ==7532==by 0x9D05CE: compile_file() (toplev.c:464) ==7532==by 0x5C8980: do_compile (toplev.c:1977) ==7532==by 0x5C8980: toplev::main(int, char**) (toplev.c:2084) ==7532==by 0x5CAC46: main (main.c:39) ==7532== Address 0x66a3000 is not stack'd, malloc'd or (recently) free'd ==7532== ==7532== Invalid write of size 8 ==7532==at 0x4C2C2CB: _intel_fast_memcpy (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==7532==by 0x7D73D6: gt_pch_save(_IO_FILE*) (ggc-common.c:563) ==7532==by 0x55: c_common_write_pch() (c-pch.c:183) ==7532==by 0x666217: c_common_parse_file() (c-opts.c:1065) ==7532==by 0x9D05CE: compile_file() (toplev.c:464) ==7532==by 0x5C8980: do_compile (toplev.c:1977) ==7532==by 0x5C8980: toplev::main(int, char**) (toplev.c:2084) ==7532==by 0x5CAC46: main (main.c:39) ==7532== Address 0x66a3000 is not stack'd, malloc'd or (recently) free'd ... Thanks, Martin
[Bug tree-optimization/68714] [6 Regression] less folding of vector comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68714
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-12-07
CC||ienkovich at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
Target Milestone|--- |6.0
Ever confirmed|0 |1
--- Comment #2 from Richard Biener ---
Confirmed. I suppose we also need to canonicalize VEC_COND_EXPRs to have
-1 in the true and 0 in the false arm. Note that the optimization also
applies to COND_EXPRs with all_ones/zero arms and bitops.
We also should handle bit_not of course.
Not sure why you guard on !lvec, the optab query is done independent
of the comparison code.
As for the
_8 = x_1(D) <= y_2(D);
_6 = VEC_COND_EXPR <_8, { -1, -1, -1, -1 }, { 0, 0, 0, 0 }>;
issue it might be "easiest" to force a target canonical variant during
vector lowering. That is, forward the conditon into the vec_cond_expr
if that's what the target understands (no bool vectors). Doing this
at expansion time only may fall foul of coalescing and TER limitations.
[Bug tree-optimization/68714] [6 Regression] less folding of vector comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68714 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/68716] libgomp c.exp with -fipa-pta failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68716 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #1 from Richard Biener --- Hmm, that doesn't make much sense to me still.
[Bug lto/68717] [6 Regression] New (bogus?) warnings when compiling some gfortran.dg tests with -flto after r231239
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68717 Richard Biener changed: What|Removed |Added Keywords||diagnostic Target Milestone|--- |6.0
[Bug c++/68727] [5 regression] invalid offsetof expressions accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68727 Richard Biener changed: What|Removed |Added Keywords||diagnostic Target Milestone|--- |5.3 Summary|[4.9 regression] invalid|[5 regression] invalid |offsetof expressions|offsetof expressions |accepted|accepted
[Bug tree-optimization/68680] [4.9/5 regression] On-stack VLA does not cause instrumentation with -fstack-protector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68680
--- Comment #9 from Jakub Jelinek ---
Author: jakub
Date: Mon Dec 7 09:11:06 2015
New Revision: 231357
URL: https://gcc.gnu.org/viewcvs?rev=231357&root=gcc&view=rev
Log:
Backport from mainline
2015-12-04 Jakub Jelinek
PR tree-optimization/68680
* calls.c (special_function_p): Return ECF_MAY_BE_ALLOCA for
BUILT_IN_ALLOCA{,_WITH_ALIGN}. Don't check for __builtin_alloca
by name.
* gcc.target/i386/pr68680.c: New test.
Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr68680.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/calls.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/68721] [6 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68721 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-07 Target Milestone|--- |6.0 Summary|wrong code at -Os and above |[6 Regression] wrong code |on x86_64-linux-gnu |at -Os and above on ||x86_64-linux-gnu Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug tree-optimization/68718] libgomp c.exp with -fipa-pta hang in sort-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68718 --- Comment #1 from Richard Biener --- I think the testcase is simply invalid, with or without OMP. busy needs to be volatile. It's also an issue similar to that of the TM bugs that PTA / aliasing doesn't consider non-address-taken vars as "aliased" but those can be still accessed by multiple threads and thus the idea of using "aliasing barriers" for thread related compiler-barriers doesn't work. Note that using 'volatile' is not always a good answer. For OMP 'busy' should be an atomic load maybe?
[Bug tree-optimization/68671] [5 Regression] gcc.dg/torture/pr66952.c FAILs with -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68671 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Fixed.
[Bug fortran/68358] Some tests in gfortran.dg fail when compiled with '-g -flto' and Xcode 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68358 --- Comment #14 from Iain Sandoe --- (In reply to Nenad Vukicevic from comment #13) > For what is worth I filed two bug reports: Thanks! > LLVM: > https://llvm.org/bugs/show_bug.cgi?id=25757 > > APPLE: > Bug 23778972 (not sure how to get URL for this bug) AFAIK there isn't any way (radr:// URLs are not visible externally) Some folks have an "unofficial" external radar site, but not sure how successful that is in progressing bug reports. --- It's on my TODO to deal with problem #1 (shouldn't be calling dsymutil unconditionally), but I'll attach that to PR 61352.
[Bug middle-end/68733] [6 Regression] FAIL: libgomp.c/target-29.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68733 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0 Summary|FAIL: libgomp.c/target-29.c |[6 Regression] FAIL: |(internal compiler error) |libgomp.c/target-29.c ||(internal compiler error)
[Bug c++/68732] Internal error while compiling CLRadeonExtender
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68732 --- Comment #4 from Richard Biener --- (In reply to matszpk from comment #3) > Thank you for quick answer and advice. Now, I am using default gcc-5 from > OpenSUSE Leap 42.1. Perhaps, I will try to use GCC 5.3 in near future... You can install 5.3 from devel:gcc
[Bug rtl-optimization/68730] [6 Regression] wrong code at -O3 on x86_64-linux-gnu (in 32-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68730 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-07 Target Milestone|--- |6.0 Summary|wrong code at -O3 on|[6 Regression] wrong code |x86_64-linux-gnu (in 32-bit |at -O3 on x86_64-linux-gnu |mode) |(in 32-bit mode) Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. It ICEs with -fno-if-conversion > ./xgcc -B. t.c -O3 -m32 -fno-if-conversion t.c: In function ‘fn1’: t.c:48:1: error: dominator of 13 should be 36, not 35 } ^ t.c:48:1: error: dominator of 35 should be 38, not 37 t.c:48:1: error: dominator of 36 status unknown t.c:48:1: internal compiler error: Segmentation fault 0xdcdd12 crash_signal /space/rguenther/src/svn/trunk3/gcc/toplev.c:334 0x949327 verify_dominators(cdi_direction) /space/rguenther/src/svn/trunk3/gcc/dominance.c:1033 0x947120 checking_verify_dominators
[Bug tree-optimization/68756] [6 Regression] ICE w/ -O1 -floop-nest-optimize and isl 0.15: isl-0.15/isl_id.c:213: unable to find id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68756 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0
[Bug c/68757] [6 Regression] Use of uninitialised value of size 8 in get_combined_adhoc_loc (line-map.c:214)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68757 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0
[Bug tree-optimization/68718] libgomp c.exp with -fipa-pta hang in sort-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68718 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-12-07 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Yes, this should use atomic load (and supposedly relaxed atomic stores too, so that say tsan doesn't complain).
[Bug debug/61352] gcc 4.9.0 fails to execute dsymutil when linking executables on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61352
Iain Sandoe changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |---
--- Comment #16 from Iain Sandoe ---
At present, we are calling dsymutil unconditionally, e.g. for:
gcc foo.o -g -o foo.exe
... which should not invoke dsymutil - it should only run:
(a) if there's a source file on the command line
(b) it we are doing LTO && a recompile of LTO code from objects takes place.
--- trunk/gcc/collect2.c2014/05/29 22:16:02 211066
+++ trunk/gcc/collect2.c2014/05/29 23:20:39 211067
@@ -848,6 +848,8 @@
fork_execute ("ld", lto_ld_argv);
post_ld_pass (false);
}
+ else
+post_ld_pass (true);
I think there's a paste-o here and this ^ and this should be "post_ld_pass
(false)"
}
/* Main program. */
[Bug rtl-optimization/68755] [5 Regression] wrong code at -O3 on x86_64-linux-gnu (in 32-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68755 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||5.2.0 Keywords||wrong-code Last reconfirmed||2015-12-07 Ever confirmed|0 |1 Summary|wrong code at -O3 on|[5 Regression] wrong code |x86_64-linux-gnu (in 32-bit |at -O3 on x86_64-linux-gnu |mode) |(in 32-bit mode) Target Milestone|--- |5.4 Known to fail||5.3.0 --- Comment #1 from Richard Biener --- Confirmed.
[Bug ada/67086] [5/6 regression] RE_Not_Available error when building ghdl-0.32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67086 Richard Biener changed: What|Removed |Added Target Milestone|5.3 |5.4
[Bug c++/68727] [5 regression] invalid offsetof expressions accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68727 Richard Biener changed: What|Removed |Added Target Milestone|5.3 |5.4
[Bug tree-optimization/68695] [6 Regression] Performance regression related to ssa patch / ifcvt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68695 --- Comment #11 from Richard Biener --- (In reply to Segher Boessenkool from comment #4) > RA assigns registers so that one of the two moves under the if > becomes a nop, and then bb-reorder duplicates the code. And then nothing cleans up the useless hard-reg propagations? Otherwise what bb-reorder does sounds sensible.
[Bug tree-optimization/68695] [6 Regression] Performance regression related to ssa patch / ifcvt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68695 --- Comment #12 from Richard Biener --- So for some reason no SSA coalescing is done for s390x here (compared to x86_64). That's the thing to look at, possibly related to some of the required parameter coalescing / default def coalescing hackery.
[Bug target/68759] New: [6 Regression] Linux kernel build failure on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68759 Bug ID: 68759 Summary: [6 Regression] Linux kernel build failure on ppc64le Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org CC: uweigand at gcc dot gnu.org Target Milestone: --- Host: powerpc64le-unknown-linux-gnu Target: powerpc64le-unknown-linux-gnu Build: powerpc64le-unknown-linux-gnu Building the Linux kernel (allyesconfig) fails on ppc64le: ... BOOTCC arch/powerpc/boot/inftrees.o BOOTCC arch/powerpc/boot/inflate.o BOOTAR arch/powerpc/boot/wrapper.a WRAParch/powerpc/boot/zImage.pseries WRAParch/powerpc/boot/zImage.epapr ERROR: "__connect" [virt/lib/irqbypass.ko] undefined! ERROR: "snd_usX2Y_pcm_pointer" [sound/usb/usx2y/snd-usb-usx2y.ko] undefined! ERROR: "snd_us428ctls_poll" [sound/usb/usx2y/snd-usb-usx2y.ko] undefined! ERROR: "i_usX2Y_Out04Int" [sound/usb/usx2y/snd-usb-usx2y.ko] undefined! ERROR: "snd_usbmidi_output_standard_packet" [sound/usb/snd-usbmidi-lib.ko] undefined! ERROR: "usb_chmap_ctl_info" [sound/usb/snd-usb-audio.ko] undefined! ERROR: "ignore_interface_quirk" [sound/usb/snd-usb-audio.ko] undefined! ERROR: "proc_audio_usbid_read" [sound/usb/snd-usb-audio.ko] undefined! ERROR: "retire_capture_urb" [sound/usb/snd-usb-audio.ko] undefined! ERROR: "scarlett_ctl_switch_info" [sound/usb/snd-usb-audio.ko] undefined! ERROR: "snd_usb_sbrc_hwdep_poll" [sound/usb/snd-usb-audio.ko] undefined! ERROR: "parse_uac2_sample_rate_range" [sound/usb/snd-usb-audio.ko] undefined! ERROR: "wait_clear_urbs" [sound/usb/snd-usb-audio.ko] undefined! ERROR: "__uac_clock_find_source" [sound/usb/snd-usb-audio.ko] undefined! ERROR: "__usb_audio_resume" [sound/usb/snd-usb-audio.ko] undefined! ERROR: "usb_error_string" [sound/usb/misc/snd-ua101.ko] undefined! ... gcc-5 is fine and gcc-6 was fine a few weeks ago. Haven't looked deeper yet, but I suspect the issue is caused by r231202.
[Bug tree-optimization/68718] libgomp c.exp with -fipa-pta hang in sort-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68718
--- Comment #3 from vries at gcc dot gnu.org ---
Created attachment 36940
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36940&action=edit
more minimal version, also fails without fipa-pta
With this futher minimized version (stripped the sorting algorithm altogether),
we can reproduce the same failure without -fipa-pta.
However, in the openmp standard I read:
...
If multiple threads write without synchronization to the same memory unit,
including cases due to atomicity considerations as described above, then a data
race occurs. Similarly, if at least one thread reads from a memory unit and at
least one thread writes without synchronization to that same memory unit,
including cases due to atomicity considerations as described above, then a data
race occurs. If a data race occurs then the result of the program is
unspecified.
...
So, AFAIU, the read in the testcase is missing the lock. The test passes with
LOCK_READ set to 1, without -fipa-pta.
However, with -fipa-pta, the test still fails. It seems that fipa-pta
(commenting out compute_dependence_clique in compute_may_aliases to eliminate
possibly restrict influence) concludes that the read from busy and the lock
functions do not alias:
...
;; basic block 5, loop depth 1, count 0, freq 110, maybe hot
;;prev block 4, next block 6, flags: (NEW, REACHABLE)
;;pred: 4 [100.0%] (FALLTHRU)
;;7 [1.0%] (FALSE_VALUE,EXECUTABLE)
# .MEM_4 = PHI <.MEM_25(4), .MEM_5(7)>
# VUSE <.MEM_4>
# PT = { D.2027 } (escaped)
_20 = .omp_data_i_14(D)->lockD.2068;
# .MEM_22 = VDEF <.MEM_4>
# USE = nonlocal { D.2027 } (escaped)
# CLB = nonlocal { D.2027 } (escaped)
omp_set_lockD.1909 (_20);
# VUSE <.MEM_22>
_23 = .omp_data_i_14(D)->busyD.2066;
# VUSE <.MEM_22>
# PT = { D.2027 } (escaped)
_24 = .omp_data_i_14(D)->lockD.2068;
# .MEM_26 = VDEF <.MEM_22>
# USE = nonlocal { D.2027 } (escaped)
# CLB = nonlocal { D.2027 } (escaped)
omp_unset_lockD.1911 (_24);
if (_23 == 0)
goto ;
else
goto ;
;;succ: 9 [9.0%] (TRUE_VALUE,EXECUTABLE)
;;6 [91.0%] (FALSE_VALUE,EXECUTABLE)
...
So we end up at optimized with the load hoisted out of the loop:
...
;; basic block 4, loop depth 1, count 0, freq 110, maybe hot
;;prev block 3, next block 5, flags: (NEW, REACHABLE)
;;pred: 3 [100.0%] (FALLTHRU,EXECUTABLE)
;;6 [1.0%] (FALSE_VALUE,EXECUTABLE)
# .MEM_4 = PHI <.MEM_8(D)(3), .MEM_29(6)>
# .MEM_22 = VDEF <.MEM_4>
# USE = nonlocal { D.2027 } (escaped)
# CLB = nonlocal { D.2027 } (escaped)
omp_set_lockD.1909 (pretmp_38);
# .MEM_26 = VDEF <.MEM_22>
# USE = nonlocal { D.2027 } (escaped)
# CLB = nonlocal { D.2027 } (escaped)
omp_unset_lockD.1911 (pretmp_38);
if (pretmp_37 == 0)
goto ;
else
goto ;
;;succ: 7 [9.0%] (TRUE_VALUE,EXECUTABLE)
;;5 [91.0%] (FALSE_VALUE,EXECUTABLE)
...
I wonder how we should model things to fix this:
- mark shared variables (such as busy) as volatile inside the thread function
- interpret omp_set/unset_lock as a memory barrier (and by extension,
all functions for which we don't have the function body, which might call
such a function)
[Bug tree-optimization/68716] libgomp c.exp with -fipa-pta failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68716 --- Comment #2 from Richard Biener --- Ah, you simply do "nothing" case BUILT_IN_GOMP_PARALLEL: case BUILT_IN_GOACC_PARALLEL: return; that's of course not correct. You should handle these builtin calls as calls to the "real" function. I thought that was done but appearantly not. Ok, I see re-mapping the arguments to the generic handling below will be interesting and thus your original patch looks ok to me.
[Bug target/68759] [6 Regression] Linux kernel build failure on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68759 Richard Biener changed: What|Removed |Added Version|unknown |6.0 Target Milestone|--- |6.0
[Bug pch/68758] [6 Regression] Invalid read of size 8 in gt_pch_save (ggc-common.c:551)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68758 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0
[Bug target/63668] -mstd-struct-return fails for non-leaf functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63668 Eric Botcazou changed: What|Removed |Added Target|sparc-linux |sparc Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-07 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- Indeed but fortunately -mstd-struct-return is not documented...
[Bug tree-optimization/68718] libgomp c.exp with -fipa-pta hang in sort-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68718 --- Comment #4 from Jakub Jelinek --- omp_set/unset_lock of course is a memory barrier. All the problematic variables (it is not just busy, but also global_stack.top) are only modified when guarded with the lock, the problem is just read data races - those vars are read outside of the lock occassionally. libgomp itself (and other libraries) had such code quite often in the past, that has been changed a few years ago especially when ppc64 started to see issues, but also when -fsanitize=thread has been added. This testcase just needs the same treatment.
[Bug target/63668] -mstd-struct-return fails for non-leaf functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63668 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #2 from Eric Botcazou --- Fixing.
[Bug fortran/68744] FAIL: gfortran.dg/backtrace_1.f90 -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68744 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-12-07 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- WORKSFORME (x86_64-apple-darwin14) and for others (see x86_64-apple-darwin14). Is this a regression? If yes, what was your last working revision and did anything change in your system: new lib, ... ?
[Bug tree-optimization/68718] libgomp c.exp with -fipa-pta hang in sort-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68718
--- Comment #5 from Richard Biener ---
As said GCC with IPA PTA sees that busy is a stack-local var (in the omp-data
in main) and thus cannot be accessed by omp_set/unset_lock which means they
do not alias.
Aliasing is not a precise enough vehicle to track "lock dependences".
# USE = nonlocal { D.2027 } (escaped)
# CLB = nonlocal { D.2027 } (escaped)
omp_set_lock (_15);
here 'busy' is neither nonlocal (in another TU) nor escaped (to other TUs).
It aliases 'lock' (D.2027 in main, having its address passed to the OMP fn
via omp-data).
GCC is simply too clever now to make that "we don't implement lock dependences"
issue papered over by alias missed optimizations...
We could continue to paper over this with some alias magic in the
tree-ssa-alias.c
stmt disambiguators as long as the locking functions are builtins. And we
could
propagate a cgraph flag "uses-locks" for other functions IPA PTA might look at
(or conservatively "does not use locks").
Or paper over it in IPA PTA and not emit clobber/use info for lock function
calls (are they even builtins, it doesn't seem so ...)
[Bug tree-optimization/68718] libgomp c.exp with -fipa-pta hang in sort-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68718 --- Comment #6 from Richard Biener --- (In reply to Jakub Jelinek from comment #4) > omp_set/unset_lock of course is a memory barrier. It is _not_ for the stack-local in main (which IPA PTA exposes).
[Bug c++/68257] Reject empty abi_tag attribute on inline namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68257
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||jason at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
On non-namespace there is a clear requirement that it has at least one
argument.
For namespace, the code has for the case of zero arguments to the attribute
in gcc/cp/name-lookup.c (handle_namespace_attrs):
if (!args)
{
tree dn = DECL_NAME (ns);
args = build_string (IDENTIFIER_LENGTH (dn) + 1,
IDENTIFIER_POINTER (dn));
TREE_TYPE (args) = char_array_type_node;
args = fix_string_type (args);
args = build_tree_list (NULL_TREE, args);
}
That code doesn't look like something one would wrote without thinking what the
behavior should be for no arguments, so I believe that it intentionally uses
the name of the namespace in that case.
So, if there is a bug, I'd say just that this is not well documented.
[Bug tree-optimization/68714] [6 Regression] less folding of vector comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68714
--- Comment #3 from Ilya Enkovich ---
(In reply to Marc Glisse from comment #1)
> Helps, but then we have:
>
> _8 = x_1(D) <= y_2(D);
> _6 = VEC_COND_EXPR <_8, { -1, -1, -1, -1 }, { 0, 0, 0, 0 }>;
>
> vector lowering calls expand_vec_cond_expr_p using the type of _8 (when the
> comparison is inside rhs1, it uses the type of x) which goes through
> get_vcond_mask_icode so it answers false (on everything but x86), and the
> VEC_COND_EXPR is lowered to a horrible sequence of
>
> _5 = BIT_FIELD_REF <_8, 32, 0>;
> _3 = _5 != 0;
> _4 = _3 ? -1 : 0;
> [...]
> _6 = {_4, _11, _14, _17};
expand_vec_cond_expr_p is not in sync with expand_vec_cond_expr right now.
expand_vec_cond_expr allows VEC_COND_EXPR with no embedded comparison even if
vcond_mask_optab doesn't have it. This patch should help:
diff --git a/gcc/optabs-tree.c b/gcc/optabs-tree.c
index d887619..3c9c485 100644
--- a/gcc/optabs-tree.c
+++ b/gcc/optabs-tree.c
@@ -343,8 +343,13 @@ expand_vec_cond_expr_p (tree value_type, tree cmp_op_type)
machine_mode value_mode = TYPE_MODE (value_type);
machine_mode cmp_op_mode = TYPE_MODE (cmp_op_type);
if (VECTOR_BOOLEAN_TYPE_P (cmp_op_type))
-return get_vcond_mask_icode (TYPE_MODE (value_type),
-TYPE_MODE (cmp_op_type)) != CODE_FOR_nothing;
+{
+ if (get_vcond_mask_icode (TYPE_MODE (value_type),
+ TYPE_MODE (cmp_op_type)) != CODE_FOR_nothing)
+ return true;
+ if (GET_MODE_CLASS (TYPE_MODE (cmp_op_type)) != MODE_VECTOR_INT)
+ return false;
+}
if (GET_MODE_SIZE (value_mode) != GET_MODE_SIZE (cmp_op_mode)
|| GET_MODE_NUNITS (value_mode) != GET_MODE_NUNITS (cmp_op_mode)
|| get_vcond_icode (TYPE_MODE (value_type), TYPE_MODE (cmp_op_type),
[Bug tree-optimization/68695] [6 Regression] Performance regression related to ssa patch / ifcvt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68695 --- Comment #13 from Dominik Vogt --- Could you give me a hint which dump files to look at?
[Bug c++/68257] Reject empty abi_tag attribute on inline namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68257
--- Comment #2 from Jonathan Wakely ---
Yes, I was mistaken in my post to the mailing list. It's by design that it uses
the name of the inline namespace as the tag name if no arguments are given,
although I thought the correct syntax in that case was:
inline namespace n __attribute__((__abi_tag__)) {}
i.e. no parentheses after __abi_tag__
[Bug c++/68760] New: [6 Regression] ICE in pp_string (pretty-print.c:909)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68760
Bug ID: 68760
Summary: [6 Regression] ICE in pp_string (pretty-print.c:909)
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
Hello.
Starting from r228131, running:
$ cat tramp3d-v4.ii
class Init {
public:
Init();
} a;
$ ./xgcc -B. tramp3d-v4.ii -c -fdump-ipa-cgraph
causes:
cc1plus: internal compiler error: Segmentation fault
0xe39480 crash_signal
../../gcc/toplev.c:353
0x16fb525 pp_string(pretty_printer*, char const*)
../../gcc/pretty-print.c:909
0x16fa2d3 pp_format(pretty_printer*, text_info*)
../../gcc/pretty-print.c:549
0x16fb2dd pp_printf(pretty_printer*, char const*, ...)
../../gcc/pretty-print.c:856
0x8285d4 dump_global_iord
../../gcc/cp/error.c:957
0x8292d7 dump_decl
../../gcc/cp/error.c:1197
0x82d444 decl_as_string(tree_node*, int)
../../gcc/cp/error.c:2855
0x82d52d lang_decl_name(tree_node*, int, bool)
../../gcc/cp/error.c:2890
0x8c3b9f cxx_printable_name_internal
../../gcc/cp/tree.c:2097
0x8c3c1a cxx_printable_name(tree_node*, int)
../../gcc/cp/tree.c:2106
0xa1f192 symtab_node::asm_name() const
../../gcc/symtab.c:451
0xa3667d analyze_functions
../../gcc/cgraphunit.c:1049
0xa39ed4 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2540
Thanks,
Martin
[Bug c++/68760] [6 Regression] ICE in pp_string (pretty-print.c:909)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68760 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0
[Bug target/68633] [i386, AVX-512] Spec2006/434.zeus miscompares when executed on KNL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68633 --- Comment #1 from Kirill Yukhin --- Author: kyukhin Date: Mon Dec 7 11:05:40 2015 New Revision: 231359 URL: https://gcc.gnu.org/viewcvs?rev=231359&root=gcc&view=rev Log: PR target/68633 gcc/ * config/i386/sse.md (define_insn "kunpckhi"): Fix operands order. (define_insn "kunpcksi"): Ditto. (define_insn "kunpckdi"): Ditto. gcc/testsuite * gcc.target/i386/pr68633.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr68633.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog
[Bug target/68627] [i386, AVX-512] Illegal insn generated while compiling spec2k6/437.leslie3d for KNL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68627 --- Comment #1 from Kirill Yukhin --- Author: kyukhin Date: Mon Dec 7 11:12:41 2015 New Revision: 231361 URL: https://gcc.gnu.org/viewcvs?rev=231361&root=gcc&view=rev Log: PR target/68627 gcc/ * config/i386/sse.md: Make 'v' alternative work on 'avx512f' ISA only. Force destination to 512 bits register. gcc/testsuite/ * gfortran.dg/pr68627.f: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr68627.f Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog
[Bug lto/65995] LTO: ICE in add_symbol_to_partition_1 for debug build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65995 --- Comment #7 from Daniel Vollmer --- Crash still present in gcc 5.3.0. When compiling with -g I also get plenty of the warnings for pretty much each and every symbol used in the library / program, e.g. [snip hundreds more] warning: (x86_64) could not find object file symbol for symbol __ZTVSt23_Sp_counted_ptr_inplaceIN2DX4MeshIdjyLi1ELi1ELi1ELi1EEESaIS2_ELN9__gnu_cxx12_Lock_policyE2EE.lto_priv.301 warning: (x86_64) could not find object file symbol for symbol __ZTVSt16_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE2EE.lto_priv.300 warning: (x86_64) could not find object file symbol for symbol __ZTVSt23_Sp_counted_ptr_inplaceIN2DX4MeshIdjyLin1ELin1ELin1ELin1EEESaIS2_ELN9__gnu_cxx12_Lock_policyE2EE.lto_priv.328 warning: (x86_64) could not find object file symbol for symbol __ZTISt11_Mutex_baseILN9__gnu_cxx12_Lock_policyE2EE warning: (x86_64) could not find object file symbol for symbol __ZTISt16_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE2EE warning: (x86_64) failed to insert symbol 'GCC_except_table0' in the debug map. warning: (x86_64) failed to insert symbol 'GCC_except_table1' in the debug map. warning: (x86_64) failed to insert symbol 'GCC_except_table2' in the debug map. [snip hundreds more]
[Bug tree-optimization/68640] foo restrict propagated to foo._omp_fn.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68640 --- Comment #6 from vries at gcc dot gnu.org --- > The definition of restrict allows for new temporaries. If you do "q = p + > 1;", then thereafter q is based on p. (If you do assignments between > restricted pointer objects, you also need to follow the rules for those.) Can the PR be confirmed then?
[Bug tree-optimization/68761] New: -floop-interchange internal compiler error: in create_tmp_var, at gimple-expr.c:519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68761
Bug ID: 68761
Summary: -floop-interchange internal compiler error: in
create_tmp_var, at gimple-expr.c:519
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jtaylor.debian at googlemail dot com
Target Milestone: ---
following code causes an ICE in gcc 5.3.0 when compiled with
-floop-interchange. Not sure if it is an regression as I currently don't have a
5.2 available. gcc 4.8 and current gcc svn head are fine.
int a, b, c;
void fn1() {
int n;
a = 0;
for (; a < n; a++) {
c = 0;
for (; c < n; c++, b++)
;
}
}
$ gcc -g -O3 -floop-interchange -std=c99 lin.i
lin.i: In function ‘fn1’:
lin.i:2:6: internal compiler error: in create_tmp_var, at gimple-expr.c:519
void fn1() {
^
Please submit a full bug report,
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/tmp/local/jenkins-gcc/bin/../libexec/gcc/x86_64-unknown-linux-gnu/5.3.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-languages=c,c++,fortran --enable-tls
--prefix=/diskb/scratch/jenkinsBuild/psdubuntu12-04-amd64/workspace/user-jtaylor-gcc-multi/ARCH/x86_64/OS/Ubuntu12.04/jenkins-gcc/
--disable-bootstrap --disable-werror --disable-multilib
Thread model: posix
gcc version 5.3.0 (GCC)
$ gcc --version
gcc (GCC) 5.3.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug libgomp/68762] New: link error for inline function decorated with OpenMP declare simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68762 Bug ID: 68762 Summary: link error for inline function decorated with OpenMP declare simd Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: gilles.civario at ichec dot ie CC: jakub at gcc dot gnu.org Target Milestone: --- Created attachment 36941 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36941&action=edit tarball of the bug reproducer Hello, I discovered that when an "inline" function is decorated with the "#pragma omp declare simd" OpenMP directive, the linking stage sometimes fails. More specifically, it fails if the level of optimisation makes that the inlining is disabled. Therefore, compiling/linking with "-O3" will work whereas compiling/linking with "-O3 -fno-inline" or "-O0" for example, will fail. I wrote a small reproducer which fails on all versions of GCC I tried, included the version 5.3.0. To compile: gcivario@vercors:~/tmp$ g++-5 -g -fopenmp simd.cc foobar.cc /tmp/cckskwpK.o: In function `_ZGVbN2v__Z3food': /home/gcivario/tmp/foobar.h:7: multiple definition of `_ZGVbN2v__Z3food' /tmp/ccsxGjU2.o:/home/gcivario/tmp/foobar.h:7: first defined here /tmp/cckskwpK.o: In function `_ZGVbM2v__Z3food': /home/gcivario/tmp/foobar.h:7: multiple definition of `_ZGVbM2v__Z3food' /tmp/ccsxGjU2.o:/home/gcivario/tmp/foobar.h:7: first defined here /tmp/cckskwpK.o: In function `_ZGVcN4v__Z3food': /home/gcivario/tmp/foobar.h:7: multiple definition of `_ZGVcN4v__Z3food' /tmp/ccsxGjU2.o:/home/gcivario/tmp/foobar.h:7: first defined here /tmp/cckskwpK.o: In function `_ZGVcM4v__Z3food': /home/gcivario/tmp/foobar.h:7: multiple definition of `_ZGVcM4v__Z3food' /tmp/ccsxGjU2.o:/home/gcivario/tmp/foobar.h:7: first defined here /tmp/cckskwpK.o: In function `_ZGVdN4v__Z3food': /home/gcivario/tmp/foobar.h:7: multiple definition of `_ZGVdN4v__Z3food' /tmp/ccsxGjU2.o:/home/gcivario/tmp/foobar.h:7: first defined here /tmp/cckskwpK.o: In function `_ZGVdM4v__Z3food': /home/gcivario/tmp/foobar.h:7: multiple definition of `_ZGVdM4v__Z3food' /tmp/ccsxGjU2.o:/home/gcivario/tmp/foobar.h:7: first defined here collect2: error: ld returned 1 exit status Whereas, if "-O3" is used: gcivario@vercors:~/tmp$ g++-5 -g -O3 -fopenmp simd.cc foobar.cc gcivario@vercors:~/tmp$ For the record: gcivario@vercors:~/tmp$ g++-5 -v Using built-in specs. COLLECT_GCC=g++-5 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.3.0-3ubuntu1~14.04' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=gcc4-compatible --disable-libstdcxx-dual-abi --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 5.3.0 20151204 (Ubuntu 5.3.0-3ubuntu1~14.04) And I asked a question about this specific issue on StackOverflow, which link is https://stackoverflow.com/questions/34091341/openmp-declare-simd-for-an-inline-function
[Bug c++/68763] New: [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68763
Bug ID: 68763
Summary: [6 Regression] ICE: in verify_unstripped_args, at
cp/pt.c:1132
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
Target Milestone: ---
Building the boost testsuite shows:
trippels@gcc2-power8 tools % ~/gcc_test/usr/local/bin/g++ -w
-ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -fPIC -m64
-Wextra -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I".." -I"/usr/include/python2.7" -c -o
"/home/trippels/boost_testing/results/boost/bin.v2/libs/python/test/args.test/gcc-6.0.0/release/args.o"
"../libs/python/test/args.cpp"
In file included from ../boost/type_traits/object_traits.hpp:25:0,
from ../boost/python/detail/borrowed_ptr.hpp:11,
from ../boost/python/borrowed.hpp:9,
from ../boost/python/handle.hpp:12,
from ../boost/python/to_python_value.hpp:12,
from ../boost/python/default_call_policies.hpp:10,
from ../boost/python/make_function.hpp:10,
from ../boost/python/def.hpp:11,
from ../libs/python/test/args.cpp:7:
../boost/type_traits/is_class.hpp: In instantiation of ‘struct
boost::is_class’:
../boost/type_traits/is_empty.hpp:73:5: required from ‘const bool
boost::detail::is_empty_impl::value’
../boost/type_traits/is_empty.hpp:113:27: required from ‘struct
boost::is_empty’
../boost/detail/compressed_pair.hpp:340:7: required from ‘class
boost::compressed_pair’
../boost/python/detail/caller.hpp:251:37: required from ‘struct
boost::python::detail::caller_arity<3u>::impl >’
../boost/python/detail/caller.hpp:167:8: required from ‘struct
boost::python::detail::caller >’
../boost/python/make_function.hpp:61:19: required from
‘boost::python::api::object boost::python::detail::make_function_aux(F, const
CallPolicies&, const Sig&, const keyword_range&, NumKeywords) [with F =
boost::python::tuple (*)(int, double, const char*); CallPolicies =
boost::python::default_call_policies; Sig =
boost::mpl::vector4;
NumKeywords = mpl_::int_<3>; boost::python::detail::keyword_range =
std::pair]’
../boost/python/make_function.hpp:73:39: required from
‘boost::python::api::object boost::python::detail::make_function_dispatch(F,
const CallPolicies&, const Keywords&, mpl_::true_) [with F =
boost::python::tuple (*)(int, double, const char*); CallPolicies =
boost::python::default_call_policies; Keywords =
boost::python::detail::keywords<3ul>; mpl_::true_ = mpl_::bool_]’
../boost/python/make_function.hpp:124:42: required from
‘boost::python::api::object boost::python::make_function(F, const
CallPolicies&, const KeywordsOrSignature&) [with F = boost::python::tuple
(*)(int, double, const char*); CallPolicies =
boost::python::default_call_policies; KeywordsOrSignature =
boost::python::detail::keywords<3ul>]’
../boost/python/def.hpp:43:45: required from ‘void
boost::python::detail::def_from_helper(const char*, const F&, const Helper&)
[with F = boost::python::tuple (*)(int, double, const char*); Helper =
boost::python::detail::def_helper, char
[22], boost::python::detail::not_specified,
boost::python::detail::not_specified>]’
../boost/python/def.hpp:103:28: required from ‘void boost::python::def(const
char*, F, const A1&, const A2&) [with F = boost::python::tuple (*)(int, double,
const char*); A1 = boost::python::detail::keywords<3ul>; A2 = char [22]]’
../libs/python/test/args.cpp:56:0: required from here
../boost/type_traits/is_class.hpp:105:27: internal compiler error: in
verify_unstripped_args, at cp/pt.c:1132
template struct is_class : public integral_constant::value> {};
^~~~
0x101f556f verify_unstripped_args
../../gcc/gcc/cp/pt.c:1132
0x101f556f retrieve_specialization
../../gcc/gcc/cp/pt.c:1177
0x1025034b instantiate_decl(tree_node*, int, bool)
../../gcc/gcc/cp/pt.c:21477
0x1025a66b instantiate_pending_templates(int)
../../gcc/gcc/cp/pt.c:21895
0x102ab86b c_parse_final_cleanups()
../../gcc/gcc/cp/decl2.c:4579
0x104de983 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1091
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
When adding --save-temps it succeeds
trippels@gcc2-power8 tools % ~/gcc_test/usr/local/bin/g++ --save-temps -w
-ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -fPIC -m64
-Wextra -DBOOST_ALL_NO_LIB=1 -DNDEBUG -I".." -I"/usr/include/python2.7" -c -o
"/home/trippels/boost_testing/results/boost/bin.v2/libs/python/test/args.test/gcc-6.0.0/release/args.o"
"../libs/python/test/args.cpp"
trippels@gcc2-power8 tools %
So,
[Bug tree-optimization/68761] -floop-interchange internal compiler error: in create_tmp_var, at gimple-expr.c:519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68761 --- Comment #1 from Julian Taylor --- 5.2.0 seems to also be affected. Also tested 4.9.2 which works. Probably an regression of 5.x then.
[Bug c/68764] New: C frontend does not fold away trivial expressions that refer to const variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68764
Bug ID: 68764
Summary: C frontend does not fold away trivial expressions that
refer to const variables
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
In the following snippet, one would expect foo and bar to get folded to the
same code, but that is not the case.
void dummy (const void *);
int
foo (void)
{
const int x = 7;
dummy (&x);
return x + 0;
}
int
bar (void)
{
const int x = 7;
dummy (&x);
return x;
}
While the C FE does fold "return x + 0;" to "return 7;", it does not fold
"return x;" to "return 7;". And the load of x is the function bar() eventually
survives all optimization passes and is present in the final optimized code:
bar ()
{
const int x;
int _4;
:
x = 7;
dummy (&x);
_4 = x;
x ={v} {CLOBBER};
return _4;
}
The C++ frontend is able to fully fold both return statements.
[Bug fortran/68744] FAIL: gfortran.dg/backtrace_1.f90 -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68744 --- Comment #2 from dave.anglin at bell dot net --- > WORKSFORME (x86_64-apple-darwin14) and for others (see x86_64-apple-darwin14). > Is this a regression? If yes, what was your last working revision and did > anything change in your system: new lib, ... ? It is likely a regression as there are no gfortran test failures on this target with 5.2.1: https://gcc.gnu.org/ml/gcc-testresults/2015-12/msg00496.html What has changed is the use of __sync functions in libgfortran: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68115 There is a patch which fixes the build of libbacktrace. However, libbacktrace thread support is now disabled because of the lack of __sync support. Patch is here: https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00658.html Effectively, this makes libbacktrace unusable... -- John David Anglin dave.ang...@bell.net
[Bug c/68764] C frontend does not fold away trivial expressions that refer to const variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68764 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- I agree that this is weird but this is something the C FE likely shouldn't do.
[Bug c/68764] C frontend does not fold away trivial expressions that refer to const variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68764 --- Comment #2 from Patrick Palka --- (In reply to Marek Polacek from comment #1) > I agree that this is weird but this is something the C FE likely shouldn't > do. One (possibly minor) obstacle with doing it in the middle-end is that the DECL_INITIALs of non-static local variables are cleared during gimplification so it is not all that simple to look up the definition of a const variable in order to fold away its uses.
[Bug fortran/68765] New: warning for aliasing restrict parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68765
Bug ID: 68765
Summary: warning for aliasing restrict parameters
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Consider this invalid example:
...
subroutine foo (a, b)
implicit none
integer :: a
integer :: b
a = 1
b = 0
a = a + 1
end subroutine
program main
implicit none
integer :: a
call foo(a, a)
if (a .ne. 1) call abort
end program main
...
The example is invalid because foo is called with aliasing parameters, while in
fortran, we assume that parameters do not alias by annotating them with
restrict, as demonstrated in the original dump:
...
foo (integer(kind=4) & restrict a, integer(kind=4) & restrict b)
{
*a = 1;
*b = 0;
*a = *a + 1;
}
...
foo (&a, &a);
...
...
When compiling with -Wall, we do not warn for this:
...
$ gfortran alias.f95 -fdump-tree-all -Wall
$
...
Marking this a fortran issue for now. [ Tough the same type of warning is
missing for c examples with explicit restrict ]
[Bug tree-optimization/68766] New: [6 regression] internal compiler error: in expand_LOOP_VECTORIZED, at internal-fn.c:1905
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68766
Bug ID: 68766
Summary: [6 regression] internal compiler error: in
expand_LOOP_VECTORIZED, at internal-fn.c:1905
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ienkovich at gcc dot gnu.org
Target Milestone: ---
Created attachment 36942
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36942&action=edit
Reproducer
>gcc -O2 -ftree-vectorize -mavx2 -c test.i -fdbg-cnt=vect_loop:1
dbg_cnt 'vect_loop' set to 1
test.i: In function 'fn2':
test.i:10:5: internal compiler error: in expand_LOOP_VECTORIZED, at
internal-fn.c:1905
int fn2() {
^~~
0xacb1c3 expand_LOOP_VECTORIZED
gcc/internal-fn.c:1905
0xacd383 expand_internal_call(internal_fn, gcall*)
gcc/internal-fn.c:2325
0xacd3ab expand_internal_call(gcall*)
gcc/internal-fn.c:2333
0x8633da expand_call_stmt
gcc/cfgexpand.c:2550
0x866a0b expand_gimple_stmt_1
gcc/cfgexpand.c:3525
0x8670de expand_gimple_stmt
gcc/cfgexpand.c:3691
0x86e1e9 expand_gimple_basic_block
gcc/cfgexpand.c:5697
0x86fced execute
gcc/cfgexpand.c:6312
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
>gcc -v
Using built-in specs.
COLLECT_GCC=/export/users/ienkovic/issues/avx-512/gcc-build/bin/gcc
COLLECT_LTO_WRAPPER=/export/users/ienkovic/issues/avx-512/gcc-build/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: gcc/configure --prefix=gcc-build
--enable-languages=c,c++,fortran --disable-bootstrap --disable-libsanitizer
Thread model: posix
gcc version 6.0.0 20151207 (experimental) (GCC)
[Bug tree-optimization/68766] [6 regression] internal compiler error: in expand_LOOP_VECTORIZED, at internal-fn.c:1905
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68766 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0
[Bug c/68764] C frontend does not fold away trivial expressions that refer to const variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68764 --- Comment #3 from Richard Biener --- (In reply to Patrick Palka from comment #2) > (In reply to Marek Polacek from comment #1) > > I agree that this is weird but this is something the C FE likely shouldn't > > do. > > One (possibly minor) obstacle with doing it in the middle-end is that the > DECL_INITIALs of non-static local variables are cleared during > gimplification so it is not all that simple to look up the definition of a > const variable in order to fold away its uses. Only if explicit assignments are instead added.
[Bug c++/68763] [6 Regression] ICE: in verify_unstripped_args, at cp/pt.c:1132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68763 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0
[Bug middle-end/68762] link error for inline function decorated with OpenMP declare simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68762 --- Comment #1 from Richard Biener --- You need to provide a out-of-line copy of foo for example by adding a extern double foo (double d); to foobar.cpp. At least if this were C, not 100% sure about C++. OTOH SIMD support may simply fail to provide proper linkage to the clones.
[Bug tree-optimization/68766] [6 regression] internal compiler error: in expand_LOOP_VECTORIZED, at internal-fn.c:1905
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68766 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-07 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed, seems to have started with r230100.
[Bug tree-optimization/68761] -floop-interchange internal compiler error: in create_tmp_var, at gimple-expr.c:519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68761 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-07 Known to work||6.0 Ever confirmed|0 |1 Known to fail||5.3.0 --- Comment #2 from Richard Biener --- Confirmed on the GCC 5 branch, works on trunk.
[Bug tree-optimization/68766] [6 regression] internal compiler error: in expand_LOOP_VECTORIZED, at internal-fn.c:1905
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68766
--- Comment #2 from Ilya Enkovich ---
This patch helps:
diff --git a/gcc/tree-vectorizer.c b/gcc/tree-vectorizer.c
index b721c56..c496c4b 100644
--- a/gcc/tree-vectorizer.c
+++ b/gcc/tree-vectorizer.c
@@ -536,7 +536,13 @@ vectorize_loops (void)
continue;
if (!dbg_cnt (vect_loop))
- break;
+ {
+ /* We may miss some if-converted loops due to
+ debug counter. Set any_ifcvt_loops to visit
+ them at finalization. */
+ any_ifcvt_loops = true;
+ break;
+ }
gimple *loop_vectorized_call = vect_loop_vectorized_call (loop);
if (loop_vectorized_call)
[Bug tree-optimization/68707] [6 Regression] testcase gcc.dg/vect/O3-pr36098.c vectorized using VEC_PERM_EXPR rather than VEC_LOAD_LANES
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68707 --- Comment #4 from Richard Biener --- Btw, PR67323 is essentially a dup.
[Bug tree-optimization/68766] [6 regression] internal compiler error: in expand_LOOP_VECTORIZED, at internal-fn.c:1905
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68766 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Preapproved for trunk (with proper ChangeLog entry and testcase added).
[Bug middle-end/68767] New: spurious warning: null argument where non-null required
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68767
Bug ID: 68767
Summary: spurious warning: null argument where non-null
required
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: amylaar at gcc dot gnu.org
Target Milestone: ---
This test, compiled with g++ -c -Werror -Wall:
// { dg-do compile }
// { dg-options "-Werror -Wall" }
extern int len (const char *__s)
throw () __attribute__ ((__pure__)) __attribute__ ((__nonnull__ (1)));
extern int num;
int
f (void)
{
int i;
i = len num != 2) ? "lstr" : num == 1 ? "str" : 0) ? ((num != 2) ? "lstr"
: num == 1 ? "str" : 0) : "lstr" ));
return i;
}
gets the spurious warning:
tmp.C:14:115: error: null argument where non-null required (argument 1)
[-Werror=nonnull]
m == 1 ? "str" : 0) ? ((num != 2) ? "lstr" : num == 1 ? "str" : 0) : "lstr"
));
^
Ironically, this is condensed down from c-common.c complaining about itself
when building gcc for a target with a variable BITS_PER_UNIT, which also uses
newlib-stdint.h .
Originally observed with g++ (GCC) 5.1.1 20150618 (Red Hat 5.1.1-4), but also
reproduced with g++ (GCC) 6.0.0 20151207 (experimental) .
[Bug fortran/68768] New: [fortran] propagate foo restrict to foo._omp_fn.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68768
Bug ID: 68768
Summary: [fortran] propagate foo restrict to foo._omp_fn.0
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
Target Milestone: ---
Consider this example:
...
subroutine subr6 (a, b)
implicit none
integer, parameter :: N = 1024
integer :: i
integer :: a(N)
integer :: b(N)
i = 0
!$omp parallel do
do i = 1, N
a(i) = b(i) + b(i)
end do
end subroutine
program main
implicit none
integer, parameter :: n = 1024
integer, dimension (0:n-1) :: a, b
integer:: i
do i = 0, n - 1
a(i) = i * 2
end do
do i = 0, n -1
b(i) = i * 4
end do
call subr6(a, b)
do i = 0, n - 1
if (a(i) .ne. b(i) + b(i)) call abort
end do
end program main
...
As in PR68640 - 'foo restrict propagated to foo._omp_fn.0', the restrict
annotation of the parameters a and b of subr6 accidentally leaks into the
declaration of the thread function:
...
.omp_data_i = { PARM_NOALIAS.0+64 }
PARM_NOALIAS.0+64 = { PARM_NOALIAS(10) }
PARM_NOALIAS(10) = { NONLOCAL }
PARM_NOALIAS.64+64 = { PARM_NOALIAS(12) }
PARM_NOALIAS(12) = { NONLOCAL }
...
Resulting clique/base annotations in the thread function:
...
;; basic block 5, loop depth 1, count 0, freq 0, maybe hot
;;prev block 4, next block 6, flags: (NEW, REACHABLE)
;;pred: 4 [100.0%] (FALLTHRU,EXECUTABLE)
;;5 (TRUE_VALUE,EXECUTABLE)
# i_3 = PHI
# .MEM_4 = PHI <.MEM_15(D)(4), .MEM_31(5)>
_18 = (integer(kind=8)D.9) i_3;
_19 = _18 + -1;
_20 = (integer(kind=8)D.9) i_3;
_21 = _20 + -1;
# VUSE <.MEM_4>
# PT = { D.3517 } (nonlocal)
_23 = MEM[(struct .omp_data_s.1D.3449 &).omp_data_i_22(D) clique 1 base
1].bD.3453;
# VUSE <.MEM_4>
_24 = MEM[(integer(kind=4)D.8[1024] *)_23 clique 1 base 2][_21];
_25 = (integer(kind=8)D.9) i_3;
_26 = _25 + -1;
# VUSE <.MEM_4>
# PT = { D.3517 } (nonlocal)
_27 = MEM[(struct .omp_data_s.1D.3449 &).omp_data_i_22(D) clique 1 base
1].bD.3453;
# VUSE <.MEM_4>
_28 = MEM[(integer(kind=4)D.8[1024] *)_27 clique 1 base 2][_26];
_29 = _28 + _28;
# VUSE <.MEM_4>
# PT = { D.3516 } (nonlocal)
_30 = MEM[(struct .omp_data_s.1D.3449 &).omp_data_i_22(D) clique 1 base
1].aD.3455;
# .MEM_31 = VDEF <.MEM_4>
MEM[(integer(kind=4)D.8[1024] *)_30 clique 1 base 3][_26] = _29;
i_32 = i_3 + 1;
if (_14 >= i_32)
goto ;
else
goto ;
;;succ: 5 (TRUE_VALUE,EXECUTABLE)
;;6 (FALSE_VALUE,EXECUTABLE)
...
However, unlike in PR68640, in the case of compiling fortran with
-fno-cray-pointers, it might actually be legal to redeclare a and b with
restrict in the thread function, give that without -fno-cray-pointers, there
are no means to introduce aliases (which we do with C in PR68640).
The simple fix for PR68640 (clearing the restrict qualifier on pointer
variables passed into install_var_field) will introduce a missed optimization
for this example.
Disabling the simple fix for fortran if !flag_cray_pointers would work.
[Bug tree-optimization/68640] foo restrict propagated to foo._omp_fn.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68640 --- Comment #7 from vries at gcc dot gnu.org --- Filed related PR68768 - '[fortran] propagate foo restrict to foo._omp_fn.0', where AFAIU keeping the restrict is legal for fortran with -fno-cray-pointers.
[Bug other/63758] liblto_plugin.so has undefined reference to _environ on OSX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63758 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Iain Sandoe --- fixed for some time now
[Bug rtl-optimization/68755] [5 Regression] wrong code at -O3 on x86_64-linux-gnu (in 32-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68755
--- Comment #2 from H.J. Lu ---
(In reply to Zhendong Su from comment #0)
>
> int
> main ()
> {
> char e[5];
> for (; c < 5; c++)
> {
> while (a)
> {
> b = d;
> if (e[8000])
^ Is this valid C code?
> continue;
> break;
> }
> if (b)
> printf ("%d", a);
> }
> return 0;
> }
[Bug c++/68429] [concepts] ICE in in placeholder_extract_concept_and_args, at cp/constraint.cc:1401
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68429
--- Comment #1 from ryan.burn at gmail dot com ---
Additional case. (not sure if it's the same bug)
namespace std {
typedef int size_t;
template
struct A {
static constexpr _Tp value = __v;
typedef _Tp value_type;
};
typedef A true_type;
template
struct conditional {
using type = int;
};
struct B : true_type {};
template
struct is_integral {
static constexpr bool value = true;
};
template
struct is_same {
static constexpr bool value = true;
};
}
template
concept bool Same = std::is_same::value;
template
concept bool Integral = requires{{T()}->Same};
template
struct compose;
template
constexpr typename T::value_type _v = T::value;
template
using size_t = std::A;
template
using bool_ = std::A;
template
using apply = typename Fn::template apply;
namespace detail {
template class C, typename... Ts>
struct defer_ {
using type = C;
};
}
template class C, typename... Ts>
struct defer : detail::defer_ {};
template
struct compose {
template
using apply = apply;
};
template
struct compose {
template
using apply = apply, Ts...>>;
};
template class C>
struct quote {
template
using apply = typename defer::type;
};
namespace detail {
template
struct _if_;
template
struct _if_ : std::conditional<_v, Then, Else> {};
}
template
using if_ = typename detail::_if_::type;
[Bug fortran/68769] New: [fortran] annotate omp data pointers with restrict for -fno-cray-pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68769 Bug ID: 68769 Summary: [fortran] annotate omp data pointers with restrict for -fno-cray-pointers Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- Consider the following program: ... program main implicit none integer, parameter :: n = 1024 integer, dimension (0:n-1) :: a, b integer:: i do i = 0, n - 1 a(i) = i * 2 end do do i = 0, n -1 b(i) = i * 4 end do !$omp parallel do do i = 0, n - 1 a(i) = b(i) + b(i) end do do i = 0, n - 1 if (a(i) .ne. b(i) + b(i)) call abort end do end program main ... when compiling with -fno-cray-pointers, I think we can annotate the pointers to a and b in omp_data_i (the argument to the resulting thread function) as restrict. Without pointers, there's no way to introduce an alias for a and b.
[Bug rtl-optimization/68755] [5 Regression] wrong code at -O3 on x86_64-linux-gnu (in 32-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68755
Markus Trippelsdorf changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||trippels at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #3 from Markus Trippelsdorf ---
(In reply to H.J. Lu from comment #2)
> (In reply to Zhendong Su from comment #0)
> >
> > int
> > main ()
> > {
> > char e[5];
>
> > for (; c < 5; c++)
> > {
> > while (a)
> > {
> > b = d;
> > if (e[8000])
> ^ Is this valid C code?
No, it isn't.
[Bug ipa/66896] ipa-prop.c:2479 runtime error: member call on null pointer of type 'struct ipa_polymorphic_call_context'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66896 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #15 from Jakub Jelinek --- The commits mentioned a test being added to the testsuite, but it doesn't seem to have been added. Also, the ChangeLog entry mentioned wrong extension (in g++.dg/ipa/ it should be *.C instead of *.c).
[Bug rtl-optimization/68755] [5 Regression] wrong code at -O3 on x86_64-linux-gnu (in 32-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68755
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
--- Comment #4 from ktkachov at gcc dot gnu.org ---
(In reply to Markus Trippelsdorf from comment #3)
> (In reply to H.J. Lu from comment #2)
> > (In reply to Zhendong Su from comment #0)
> > >
> > > int
> > > main ()
> > > {
> > > char e[5];
> >
> > > for (; c < 5; c++)
> > > {
> > > while (a)
> > > {
> > > b = d;
> > > if (e[8000])
> > ^ Is this valid C code?
>
> No, it isn't.
but the e[8000] is inside the "while (a)" loop and should not be reachable
since 'a' is always 0?
[Bug c++/68760] [6 Regression] ICE in pp_string (pretty-print.c:909)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68760 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-12-07 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Created attachment 36943 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36943&action=edit gcc6-pr68760.patch Using input_location in this routine doesn't make any sense.
[Bug target/68770] New: [6 Regression] Conditional jump or move depends on uninitialised value(s) default_secondary_reload() targhooks.c:940
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68770 Bug ID: 68770 Summary: [6 Regression] Conditional jump or move depends on uninitialised value(s) default_secondary_reload() targhooks.c:940 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org Target Milestone: --- Host: powerpc64-unknown-linux-gnu Target: powerpc64-unknown-linux-gnu Build: powerpc64-unknown-linux-gnu checking=valgrind shows: ==115918== Conditional jump or move depends on uninitialised value(s) ==115918==at 0x107D29F4: default_secondary_reload(bool, rtx_def*, int, machine_mode, secondary_reload_info*) (targhooks.c:940) ==115918==by 0x10AD9B93: rs6000_secondary_reload(bool, rtx_def*, int, machine_mode, secondary_reload_info*) (rs6000.c:18414) ==115918==by 0x105FBCB7: copy_cost(rtx_def*, machine_mode, int, bool, secondary_reload_info*) [clone .part.7] (ira-costs.c:445) ==115918==by 0x105FBD27: copy_cost (ira-costs.c:434) ==115918==by 0x105FBD27: copy_cost(rtx_def*, machine_mode, int, bool, secondary_reload_info*) [clone .part.7] (ira-costs.c:452) ==115918==by 0x105FC243: copy_cost (ira-costs.c:434) ==115918==by 0x105FC243: record_reg_classes(int, int, rtx_def**, machine_mode*, char const**, rtx_insn*, reg_class*) [clone .constprop.42] (ira-costs.c:984) ==115918==by 0x105FE11F: record_operand_costs(rtx_insn*, reg_class*) (ira-costs.c:1325) ==115918==by 0x105FE657: scan_one_insn (ira-costs.c:1462) ==115918==by 0x105FE657: process_bb_for_costs(basic_block_def*) (ira-costs.c:1583) ==115918==by 0x105F488F: ira_traverse_loop_tree(bool, ira_loop_tree_node*, void (*)(ira_loop_tree_node*), void (*)(ira_loop_tree_node*)) (ira-build.c:1798) ==115918==by 0x10600E3B: find_costs_and_classes(_IO_FILE*) (ira-costs.c:1680) ==115918==by 0x1060160F: ira_costs() (ira-costs.c:2213) ==115918==by 0x105F9F0F: ira_build() (ira-build.c:3419) ==115918==by 0x105EDE03: ira (ira.c:5219) ==115918==by 0x105EDE03: (anonymous namespace)::pass_ira::execute(function*) (ira.c:5511) ==115918==
[Bug c++/68170] [6 Regression] Declaring friend template class template in C++1z produces error: specialization of ‘template class A’ must appear at namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68170 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/68760] [6 Regression] ICE in pp_string (pretty-print.c:909)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68760 --- Comment #2 from Martin Liška --- (In reply to Jakub Jelinek from comment #1) > Created attachment 36943 [details] > gcc6-pr68760.patch > > Using input_location in this routine doesn't make any sense. Works for me for the original test-case which is tramp3d. Thanks, Martin
[Bug rtl-optimization/68755] [5 Regression] wrong code at -O3 on x86_64-linux-gnu (in 32-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68755 Markus Trippelsdorf changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #5 from Markus Trippelsdorf --- (In reply to ktkachov from comment #4) > but the e[8000] is inside the "while (a)" loop and should not be reachable > since 'a' is always 0? Fair enough. Good vs.bad: ... - testl %ebx, %ebx - je .L9 movzbl 7987(%ebp), %ecx + testl %ebx, %ebx + je .L24
[Bug testsuite/68751] FAIL: gcc.dg/sancov/asan.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68751 --- Comment #3 from Dmitry Vyukov --- Committed fix as 231364.
[Bug testsuite/68751] FAIL: gcc.dg/sancov/asan.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68751 --- Comment #4 from Dmitry Vyukov --- Do I have rights to change status? Can't find how to close this...
[Bug rtl-optimization/68755] [5 Regression] wrong code at -O3 on x86_64-linux-gnu (in 32-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68755 --- Comment #6 from Markus Trippelsdorf --- Also happens with -m64 with gcc-5.3.
[Bug ipa/66896] ipa-prop.c:2479 runtime error: member call on null pointer of type 'struct ipa_polymorphic_call_context'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66896 --- Comment #16 from Martin Liška --- (In reply to Jakub Jelinek from comment #15) > The commits mentioned a test being added to the testsuite, but it doesn't > seem to have been added. Also, the ChangeLog entry mentioned wrong > extension (in g++.dg/ipa/ it should be *.C instead of *.c). Thanks for pointing out, fixed both for gcc-5-branch and trunk. Martin
[Bug debug/68771] New: Darwin: Profile guided optimisation with cold sections and invalid symbol redefinition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68771 Bug ID: 68771 Summary: Darwin: Profile guided optimisation with cold sections and invalid symbol redefinition Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: zerolo at gmail dot com Target Milestone: --- Created attachment 36944 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36944&action=edit Patch to make cold section label unique(r?) I'm not sure which component to attach this report to, the problem seems to be specific to Darwin (and stem from its format for debug symbols but is present whether generating debug info or not), but relates to both PGO (which causes the cold and hot splits) and is exacerbate by LTO. On the Darwin platform, a label is inserted for debugging / EH purposes when a function is split into hot / hold (with info generated from PGO). Rough repo steps for Mac OS 10.11.1 El Yosemite with Homebrew gcc 5.3.0 1) Compile/link C++ project with -Ofast -DNDEBUG -flto -fprofile-generate 2) Run to generate profiling files 3) Compile/link C++ project with -Ofast -DNDEBUG -flto -fprofile-use Step 3's link aborts on multiple temporary assembler files with errors such as /var/folders/02/yl3m8d4d0397mk6dxn6dpcqwgp/T//ccgBAKOU.s:3430:1: error: invalid symbol redefinition ___cold_sect_of_ComputeBoundingBox: ^ /var/folders/02/yl3m8d4d0397mk6dxn6dpcqwgp/T//ccHiavMh.s:1652:1: error: invalid symbol redefinition ___cold_sect_of_GetInterpolationMatrix: ^ /var/folders/02/yl3m8d4d0397mk6dxn6dpcqwgp/T//ccjQlEWp.s:11019:1: error: invalid symbol redefinition ___cold_sect_of_GetReferencePoints: ^ The methods mentioned exist multiple times, but either as different overloads (different C++ arguments, so distinct mangled name), or in completely difference classes (or static in distinct files). The machinery that actually generates those __cold_sect_of_ seems to be set up in gcc/config/darwin.c:3682. Originally this seems to come from a patch for debugging information here https://gcc.gnu.org/ml/gcc-patches/2010-12/msg01609.html These label are derived *only* from the name of the function, so it fails when multiple overloads are present, also seems to cause problems with LTO. When I change darwin.c to use DECL_ASSEMBLER_NAME instead (and increase the buffer size for really long mangled names), the link works, although I'm not sure about the accuracy of debug information.
[Bug tree-optimization/68659] [6 regression] FAIL: gcc.dg/graphite/id-pr45230-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68659 mwahab at gcc dot gnu.org changed: What|Removed |Added CC||mwahab at gcc dot gnu.org --- Comment #9 from mwahab at gcc dot gnu.org --- I still see this on arm-none-eabi.
[Bug testsuite/68751] FAIL: gcc.dg/sancov/asan.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68751 --- Comment #5 from Yury Gribov --- You most probably can't.
[Bug c++/66460] ICE using __func__ in constexpr function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66460 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek --- Started with r217663.
