[Bug middle-end/88784] Middle end is missing some optimizations about unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88784 Qi Feng changed: What|Removed |Added CC||ffengqi at gcc dot gnu.org --- Comment #2 from Qi Feng --- I tried some modifications in and_comparisons_1 and or_comparisons_1. It seems that `||' is transformed to `&&' somewhere. And that makes the changes in or_comparisons_1 noneffective. Should I find the place where the transformation happens and make changes before that?
[Bug tree-optimization/90328] Wrong loop distribution with aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90328 Richard Biener changed: What|Removed |Added Keywords||alias Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-05-06 CC||rguenth at gcc dot gnu.org Blocks||49774 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Confirmed. This is basically the "same" issue as PR89578 just applied to analysis that looks at cross-iteration dependences. Fortunately infrastructure is there to deal with this in a reasonably straight-forward way. Index: tree-data-ref.c === --- tree-data-ref.c (revision 270847) +++ tree-data-ref.c (working copy) @@ -2255,6 +2255,12 @@ dr_may_alias_p (const struct data_refere if ((TREE_CODE (addr_a) == MEM_REF || TREE_CODE (addr_a) == TARGET_MEM_REF) && (TREE_CODE (addr_b) == MEM_REF || TREE_CODE (addr_b) == TARGET_MEM_REF) + /* For cross-iteration dependences the cliques must be valid for the +whole loop, not just individual iterations. */ + && (!loop_nest + || MR_DEPENDENCE_CLIQUE (addr_a) == 1 + || (MR_DEPENDENCE_CLIQUE (addr_a) + == gimple_bb (DR_STMT (a))->loop_father->owned_clique)) && MR_DEPENDENCE_CLIQUE (addr_a) == MR_DEPENDENCE_CLIQUE (addr_b) && MR_DEPENDENCE_BASE (addr_a) != MR_DEPENDENCE_BASE (addr_b)) return false; the only "awkward" thing is looking at DR_STMTs BB. It would be easier to pass down the outermost loop and possibly more correct to look at the "common" loop enclosing both a and b. (even though DR only deals with perfect nests this function is also used by graphite to handle DRs in non-perfect nests) Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49774 [Bug 49774] [meta-bug] restrict qualification aliasing issues
[Bug fortran/90329] Incompatibility between gfortran and C lapack calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329 Richard Biener changed: What|Removed |Added Keywords||ABI CC||rguenth at gcc dot gnu.org --- Comment #10 from Richard Biener --- I think the only option is to go forward without any change to gfortran and simply teach people about this "ABI change" and how to fix the C side. Everything else sounds like a hack that will create its own problems when used. So - RESOLVED INVALID? The recommended solution is to fix the C code.
[Bug middle-end/90356] Missed optimization for variables initialized to 0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90356 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- The rules for + 0.0 say that: for non-zero x, x + (+/-0.0) = x 0.0 + 0.0 = 0.0 -0.0 + (-0.0) = -0.0 -0.0 + 0.0 = 0.0 unless rounding towards negative infinity, in that case it is -0.0. So, for -frounding-math we can't optimize this, but with just -fsigned-zeros I think we could optimize (x + 0.0) + 0.0 to x + 0.0 and (x + (-0.0)) + (-0.0) to x + (-0.0), because if x is non-zero, then the result will be still non-zero, when not rounding towards negative infinity and if x is 0.0, the result will still be 0.0 and when not rounding towards negative infinity and if x is -0.0 the result will still be 0.0 in the first case and -0.0 in the latter case.
[Bug testsuite/90331] New test case gcc.dg/pr87314-1.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90331
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2019-05-06
Component|middle-end |testsuite
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
Hmm, GIMPLE has
;; Function h (null)
;; enabled by -tree-original
{
return (char *) "bye" == (char *) "hellobye" + 5;
but somehow on ppc64le CCP elides the check. Hmm, it might be due to
how the target aligns constants. Indeed "fixing" the testcase shows:
.section.rodata.str1.8,"aMS",@progbits,1
.align 3
.LC0:
.string "hellbye"
.align 3
.LC1:
.string "bye"
.section".toc","aw"
...
so ppc64le (and possibly others) align (even small) strings to 8 bytes,
also somewhat defeating string merging.
[Bug sanitizer/90312] Address sanitizer cannot be used with -mabi=ms since r266073
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90312 --- Comment #5 from Martin Liška --- Author: marxin Date: Mon May 6 07:35:59 2019 New Revision: 270899 URL: https://gcc.gnu.org/viewcvs?rev=270899&root=gcc&view=rev Log: Error only when a non-default -mabi is used with sanitizers (PR sanitizer/90312). 2019-05-06 Martin Liska PR sanitizer/90312 * config/i386/i386-options.c (ix86_option_override_internal): Error only when -mabi is selected to a non-default version. 2019-05-06 Martin Liska PR sanitizer/90312 * gcc.dg/asan/pr87930.c: Run the test only on *linux or *gnu systems. * gcc.dg/tsan/pr88017.c: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386-options.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/asan/pr87930.c trunk/gcc/testsuite/gcc.dg/tsan/pr88017.c
[Bug testsuite/90331] New test case gcc.dg/pr87314-1.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90331 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Richard Biener --- Fixed.
[Bug sanitizer/90312] Address sanitizer cannot be used with -mabi=ms since r266073
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90312 Martin Liška changed: What|Removed |Added Known to work||10.0 Known to fail|9.0 |9.1.0 --- Comment #6 from Martin Liška --- Fixed on trunk so far.
[Bug testsuite/90331] New test case gcc.dg/pr87314-1.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90331 --- Comment #3 from Richard Biener --- Author: rguenth Date: Mon May 6 07:38:26 2019 New Revision: 270900 URL: https://gcc.gnu.org/viewcvs?rev=270900&root=gcc&view=rev Log: 2019-05-06 Richard Biener PR testsuite/90331 * gcc.dg/pr87314-1.c: Align the substring to open up string merging for targets aligning strings to 8 bytes. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr87314-1.c
[Bug debug/90336] gcc generates wrong debug information at -O1 to -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90336 Richard Biener changed: What|Removed |Added Keywords||wrong-debug Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-06 CC||aoliva at gcc dot gnu.org Version|unknown |9.1.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. The main reason is we do not track "memory" changes in debug. But then we rewrite the initial assignment into SSA and after DCEing that end up with a debug stmt for the initializer. It also shows FRE could, as CCP, rewrite no longer address-taken locals into SSA form. Or we could make DSE insert debug stmts for killing stores of register type?
[Bug c++/90338] [9/10 Regression] member function pointer non-type template parameter compile fail while matching
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90338 Richard Biener changed: What|Removed |Added Keywords||rejects-valid Target Milestone|--- |9.2 Summary|member function pointer |[9/10 Regression] member |non-type template parameter |function pointer non-type |compile fail while matching |template parameter compile ||fail while matching
[Bug middle-end/90340] Not optimal code when compiling switch-case for size, code increase +35%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90340 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-06 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Martin Liška --- Let me take a look.
[Bug c++/90341] pcsx2-git: "At global scope: cc1plus: internal compiler error: Segmentation fault"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90341 Richard Biener changed: What|Removed |Added Target||x86_64-*-* Status|UNCONFIRMED |WAITING Last reconfirmed||2019-05-06 Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- You are missing to have -v on the command-line which means I have to guess what -march=native expands to. Tried some but still get errors: In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/9.1.1/include/immintrin.h:47, from ../plugins/GSdx/./stdafx.h:308, from ../plugins/GSdx/PSX/GPURendererSW.cpp:22: /usr/lib/gcc/x86_64-pc-linux-gnu/9.1.1/include/xsavesintrin.h: In function ‘void _xsaves(void*, long long int)’: /usr/lib/gcc/x86_64-pc-linux-gnu/9.1.1/include/xsavesintrin.h:41:3: error: ‘__builtin_ia32_xsaves’ was not declared in this scope; did you mean ‘__builtin_ia32_xsave’? ...
[Bug c++/90342] Misleading #include system fixit when using an older C++ version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90342 Richard Biener changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org --- Comment #2 from Richard Biener --- Also we could maybe look to whether was included before suggesting to include it?
[Bug middle-end/90345] too pessimistic check whether pointer may alias a local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90345
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-05-06
Ever confirmed|0 |1
--- Comment #3 from Richard Biener ---
Actually GCC knows this but 'carry' escapes here:
if (carry)
{
a.push_back(carry);
//a.push_back(uint32_t(carry));
}
and thus a _can_ point to it since points-to analysis isn't flow-sensitive.
An old "imperfect" idea is to virtually "outline" the function body at
SESE region boundaries to make points-to analysis somewhat flow-sensitive
(not actually at BB boundaries because we do not want to consider backedges
here).
[Bug rtl-optimization/90357] New: [9 regression][MIPS] New FAIL: gcc.c-torture/execute/20080502-1.c -O0 start with r269880
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90357 Bug ID: 90357 Summary: [9 regression][MIPS] New FAIL: gcc.c-torture/execute/20080502-1.c -O0 start with r269880 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: paul.hua.gm at gmail dot com Target Milestone: --- Created attachment 46300 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46300&action=edit preprocessed .i file Hi: There are some regressions start with r269880. The r269880 try to forward SRC into the next instruction. Take 20080502-1.c as a example, it fails cause they use the same reg between src and dest. good asm: 81 ld $2,%got_page(.LC1)($28) 82 ld $3,%got_ofst(.LC1+8)($2) 83 ld $2,%got_ofst(.LC1)($2) 84 dmtc1 $2,$f12 85 dmtc1 $3,$f13 after r269880: 81 ld $2,%got_page(.LC1)($28) 82 ld $3,%got_ofst(.LC1+8)($2) 83 ld $2,%got_ofst(.LC1)($2) 84 ldc1$f12,%got_ofst(.LC1)($2) 85 ldc1$f13,%got_ofst(.LC1+8)($2) The line 83 $2 is dead, line 84 get the wrong address. build cmd: cc1 -fpreprocessed 20080502-1.i -mel -quiet -dumpbase 20080502-1.c -march=mips64r2 -mabi=64 -mllsc -mips64r2 -mno-shared -auxbase 20080502-1 -O0 -w -version -fdiagnostics-color=never -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -o 20080502-1.s
[Bug target/90346] gcc generates the "lfence" instruction on CPUs that don't support it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90346 Richard Biener changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-06 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug rtl-optimization/90357] [9 regression][MIPS] New FAIL: gcc.c-torture/execute/20080502-1.c -O0 start with r269880
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90357
--- Comment #1 from Paul Hua ---
Fix patch:
diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index 1de33b2..89fc073 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -4849,6 +4849,7 @@ mips_split_move (rtx dest, rtx src, enum mips_split_type
split_type, rtx insn_)
can forward SRC for DEST. This is most useful if the next insn is a
simple store. */
rtx_insn *insn = (rtx_insn *)insn_;
+ struct mips_address_info addr;
if (insn)
{
rtx_insn *next = next_nonnote_nondebug_insn_bb (insn);
@@ -4856,7 +4857,17 @@ mips_split_move (rtx dest, rtx src, enum mips_split_type
split_type, rtx insn_)
{
rtx set = single_set (next);
if (set && SET_SRC (set) == dest)
- validate_change (next, &SET_SRC (set), src, false);
+ {
+ if (MEM_P (src))
+ {
+ rtx tmp = XEXP (src, 0);
+ mips_classify_address (&addr, tmp, GET_MODE (tmp), true);
+ if (REGNO (addr.reg) != REGNO (dest))
+ validate_change (next, &SET_SRC (set), src, false);
+ }
+ else
+ validate_change (next, &SET_SRC (set), src, false);
+ }
}
}
}
[Bug c++/90341] pcsx2-git: "At global scope: cc1plus: internal compiler error: Segmentation fault"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90341 --- Comment #4 from Kyle De'Vir --- Here's what `-march=native` expands to: COLLECT_GCC_OPTIONS='-march=native' /usr/lib/gcc/x86_64-pc-linux-gnu/9.1.1/cc1 -quiet - "-march=znver1" -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -msse4a -mcx16 -msahf -mmovbe -maes -msha -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mno-sgx -mbmi2 -mno-pconfig -mno-wbnoinvd -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mno-rtm -mno-hle -mrdrnd -mf16c -mfsgsbase -mrdseed -mprfchw -madx -mfxsr -mxsave -mxsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mclflushopt -mxsavec -mxsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma -mno-avx512vbmi -mno-avx5124fmaps -mno-avx5124vnniw -mno-clwb -mmwaitx -mclzero -mno-pku -mno-rdpid -mno-gfni -mno-shstk -mno-avx512vbmi2 -mno-avx512vnni -mno-vaes -mno-vpclmulqdq -mno-avx512bitalg -mno-movdiri -mno-movdir64b -mno-waitpkg -mno-cldemote -mno-ptwrite --param "l1-cache-size=32" --param "l1-cache-line-size=64" --param "l2-cache-size=512" "-mtune=znver1" -quiet -dumpbase - -auxbase - -o /tmp/ccfG19H9.s COLLECT_GCC_OPTIONS='-march=native' as --64 -o /tmp/ccFUIPM3.o /tmp/ccfG19H9.s COMPILER_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.1/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.1/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-march=native' /usr/lib/gcc/x86_64-pc-linux-gnu/9.1.1/collect2 -plugin /usr/lib/gcc/x86_64-pc-linux-gnu/9.1.1/liblto_plugin.so "-plugin-opt=/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.1/lto-wrapper" "-plugin-opt=-fresolution=/tmp/ccToAwRX.res" "-plugin-opt=-pass-through=-lgcc" "-plugin-opt=-pass-through=-lgcc_s" "-plugin-opt=-pass-through=-lc" "-plugin-opt=-pass-through=-lgcc" "-plugin-opt=-pass-through=-lgcc_s" --build-id --eh-frame-hdr "--hash-style=gnu" -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -pie /usr/lib/gcc/x86_64-pc-linux-gnu/9.1.1/../../../../lib/Scrt1.o /usr/lib/gcc/x86_64-pc-linux-gnu/9.1.1/../../../../lib/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/9.1.1/crtbeginS.o -L/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.1 -L/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.1/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.1/../../.. /tmp/ccFUIPM3.o -lgcc --push-state --as-needed -lgcc_s --pop-state -lc -lgcc --push-state --as-needed -lgcc_s --pop-state /usr/lib/gcc/x86_64-pc-linux-gnu/9.1.1/crtendS.o /usr/lib/gcc/x86_64-pc-linux-gnu/9.1.1/../../../../lib/crtn.o COLLECT_GCC_OPTIONS='-march=native'
[Bug middle-end/90348] [7/8/9/10 Regression] Partition of char arrays is incorrect in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90348 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug middle-end/90348] [7/8/9/10 Regression] Partition of char arrays is incorrect in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90348
Richard Biener changed:
What|Removed |Added
CC||matz at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
--- Comment #4 from Richard Biener ---
Sth wrong with liveness analysis. There's obvious liveness of IN from BB2:
;; basic block 2, loop depth 0
;;pred: ENTRY
_30 = (unsigned long) ∈
ivtmp.30_29 = _30 + 1;
goto ; [100.00%]
;;succ: 5
to
;; basic block 7, loop depth 1
;;pred: 5
in ={v} {CLOBBER};
i_10 = i_6 + 1;
if (i_10 != 5)
goto ; [80.00%]
else
goto ; [20.00%]
;;succ: 3
;;8
but maybe that being at different loop depth somehow confuses the algorithm
in fact having it there seems odd to me but the address-taking in BB2 is
the result of IVOPTs hoisting. The CLOBBER doesn't effect hoisting
the address but RTL expansion liveness compute splits 'in' into multiple
logical instances at the CLOBBER which _does_ make the addresses effectively
different ...
[Bug c++/90353] No warning on unused exception parameter with -Wall -Wextra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90353 Richard Biener changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-06 Ever confirmed|0 |1
[Bug middle-end/90354] [7.3 regression] Skip the not first insn when traversing the insn node
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90354 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-05-06 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Which target? Which GCC version did work for you?
[Bug rtl-optimization/90357] [9/10 regression][MIPS] New FAIL: gcc.c-torture/execute/20080502-1.c -O0 start with r269880
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90357 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Priority|P3 |P2 Target Milestone|--- |9.2 Summary|[9 regression][MIPS] New|[9/10 regression][MIPS] New |FAIL: |FAIL: |gcc.c-torture/execute/20080 |gcc.c-torture/execute/20080 |502-1.c -O0 start with|502-1.c -O0 start with |r269880 |r269880
[Bug middle-end/90340] Not optimal code when compiling switch-case for size, code increase +35%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90340
--- Comment #4 from Martin Liška ---
Simplified test-case:
$ cat /tmp/csibe.c
int a;
int foo(char c) {
switch (c) {
case 'c':
return a;
case 's':
return 3;
case 'n':
return 1;
case '%':
return -2;
case 'o':
return a + 2;
break;
case 'X':
case 'x':
return ;
case 'd':
case 'i':
case 'u':
return ;
default:
return 0;
}
}
$ ~/Programming/bloaty/bloaty bad.o -- good.o
VM SIZE FILE SIZE
-- --
[ = ] 0 .rela.rodata +528 [NEW]
[NEW]+176 .rodata +176 [NEW]
[ = ] 0 [ELF Headers]+128 +15%
[ = ] 0 .rela.text+24 +50%
[ = ] 0 .symtab +24 +10.0%
[ = ] 0 .shstrtab +13 +15%
[ = ] 0 [Unmapped] +5 +62%
[ = ] 0 .comment -22 -33.8%
-20.7% -28 .text -28 -20.7%
+81%+148 TOTAL+848 +56%
Where bad.o is GCC 9.1 and good.o is GCC 8.3.1.
Reason is that GCC 9 can newly generate jump tables for a fraction of switch
statement and we allow:
/* Max growth ratio for code that is optimized for size. */
static const unsigned HOST_WIDE_INT max_ratio_for_size = 3;
;; GIMPLE switch case clusters: 37 88 JT(values:8 comparisons:8 range:22
density: 36.36%):99-120
I can imagine shrinking the parameter to 2 for -Os.
Can you please help me how to run all CSIBE benchmarks?
[Bug middle-end/90354] [7.3 regression] Skip the not first insn when traversing the insn node
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90354
--- Comment #3 from vfdff ---
I work on GCC 7.3, in function scan_trace, control = pat->insn (0), so it only
check whether or not a jump_insn for the first insn of sequence.
for (prev = insn, insn = NEXT_INSN (insn);
insn;
prev = insn, insn = NEXT_INSN (insn))
{
rtx_insn *control;
...
/* Handle all changes to the row state. Sequences require special
handling for the positioning of the notes. */
if (rtx_sequence *pat = dyn_cast (PATTERN (insn)))
{
rtx_insn *elt;
int i, n = pat->len ();
control = pat->insn (0); // it get the first insn of sequence, and
check whether or not a jump_insn ?
if (can_throw_internal (control))
notice_eh_throw (control);
dwarf2out_flush_queued_reg_saves ();
if (JUMP_P (control) && INSN_ANNULLED_BRANCH_P (control))
{
/* ??? Hopefully multiple delay slots are not annulled. */
gcc_assert (n == 2);
gcc_assert (!RTX_FRAME_RELATED_P (control));
gcc_assert (!find_reg_note (control, REG_ARGS_SIZE, NULL));
...
[Bug tree-optimization/90332] New test case gcc.dg/vect/slp-reduc-sad-2.c in r270847 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90332
--- Comment #2 from Richard Biener ---
Hmm, can't get the test to FAIL with a cross, somehow the dejagnu tests always
end up UNSUPPORTED. The testcase for x86_64 has
/* With AVX256 or more we do not pull off the trick eliding the epilogue. */
/* { dg-additional-options "-mprefer-avx128" { target { x86_64-*-* i?86-*-* } }
} */
so we require the use of V16QImode -> V4SImode SAD with the V16QImode loads
split into two V8QImode ones. There were insufficient dejagnu effective
targets to model the restriction in
+ /* If the gap splits the vector in half and the target
+can do half-vector operations avoid the epilogue peeling
+by simply loading half of the vector only. Usually
+the construction with an upper zero half will be elided. */
+ dr_alignment_support alignment_support_scheme;
+ scalar_mode elmode = SCALAR_TYPE_MODE (TREE_TYPE (vectype));
+ machine_mode vmode;
+ if (overrun_p
+ && !masked_p
+ && (((alignment_support_scheme
+ = vect_supportable_dr_alignment (first_dr_info, false)))
+ == dr_aligned
+ || alignment_support_scheme == dr_unaligned_supported)
+ && known_eq (nunits, (group_size - gap) * 2)
+ && mode_for_vector (elmode, (group_size - gap)).exists (&vmode)
+ && VECTOR_MODE_P (vmode)
+ && targetm.vector_mode_supported_p (vmode)
+ && (convert_optab_handler (vec_init_optab,
+TYPE_MODE (vectype), vmode)
+ != CODE_FOR_nothing))
+ overrun_p = false;
I see we probably need hw_misalign, so does
Index: gcc/testsuite/gcc.dg/vect/slp-reduc-sad-2.c
===
--- gcc/testsuite/gcc.dg/vect/slp-reduc-sad-2.c (revision 270899)
+++ gcc/testsuite/gcc.dg/vect/slp-reduc-sad-2.c (working copy)
@@ -25,5 +25,5 @@ int x264_pixel_sad_8x8( uint8_t *pix1, u
/* { dg-final { scan-tree-dump "vect_recog_sad_pattern: detected" "vect" } }
*/
/* { dg-final { scan-tree-dump "vectorizing stmts using SLP" "vect" } } */
-/* { dg-final { scan-tree-dump-not "access with gaps requires scalar epilogue
loop" "vect" } } */
+/* { dg-final { scan-tree-dump-not "access with gaps requires scalar epilogue
loop" "vect" { xfail { ! vect_hw_misalign } } } } */
/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" } } */
fix everything?
[Bug target/90346] gcc generates the "lfence" instruction on CPUs that don't support it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90346 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Let me take a look.
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 Richard Biener changed: What|Removed |Added Known to work||10.0 Summary|[8/9/10 Regression] large |[8/9 Regression] large |compile time increase in|compile time increase in |opt / alias stmt walking|opt / alias stmt walking |for Go example |for Go example --- Comment #8 from Richard Biener --- Fixed on trunk sofar.
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #9 from Richard Biener --- Author: rguenth Date: Mon May 6 08:54:40 2019 New Revision: 270902 URL: https://gcc.gnu.org/viewcvs?rev=270902&root=gcc&view=rev Log: 2019-05-06 Richard Biener PR tree-optimization/90316 * tree-ssa-alias.c (maybe_skip_until): Pass in target BB, compute target on demand. (get_continuation_for_phi): Remove code walking stmts to get to a target virtual operand which could end up being quadratic. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-alias.c
[Bug middle-end/90340] Not optimal code when compiling switch-case for size, code increase +35%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90340 --- Comment #5 from Fredrik Hederstierna --- I use patched sources from http://gcc.hederstierna.com/csibe I think you could download and try it out. Toolchain I build with https://github.com/fredrikhederstierna/buildbuddy Otherwise I think there are at least two more code size regressions open for gcc-9.1.0 on ARM against CSiBE, so maybe there are already some CSiBE test setup running that could be quicker path forward. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90249 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90255 Code size regressions on CSiBE for gcc-9.1.0 I think is worked on. Thanks/Fredrik
[Bug rtl-optimization/90343] ICE: in verify_dominators, at dominance.c:1184 (error: dominator of 7 status unknown)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90343 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-06 CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org, ||nathan at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Adding C++ maintainers to CC.
[Bug middle-end/90340] Not optimal code when compiling switch-case for size, code increase +35%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90340 --- Comment #7 from Martin Liška --- > I'm curious how much can save following patch: > Plus how much can you cave with 9.1 and -fno-jump-tables?
[Bug middle-end/90340] Not optimal code when compiling switch-case for size, code increase +35%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90340 --- Comment #6 from Martin Liška --- (In reply to Fredrik Hederstierna from comment #5) > I use patched sources from > http://gcc.hederstierna.com/csibe I've just tried that but I see quite some compilation errors: /home/marxin/Downloads/CSiBE-v2.1.1-patched2/CSiBE/./src/./flex-2.5.31/../include/inttypes.h:12:26: error: conflicting types for ‘int64_t’ /home/marxin/Downloads/CSiBE-v2.1.1-patched2/CSiBE/./src/./libmspack/test/../../include/inttypes.h:12:26: error: conflicting types for ‘int64_t’ /home/marxin/Downloads/CSiBE-v2.1.1-patched2/CSiBE/./src/./mpeg2dec-0.3.1/libmpeg2/../../include/inttypes.h:12:26: error: conflicting types for ‘int64_t’ > > I think you could download and try it out. > Toolchain I build with > https://github.com/fredrikhederstierna/buildbuddy > > Otherwise I think there are at least two more code size regressions open for > gcc-9.1.0 on ARM against CSiBE, so maybe there are already some CSiBE test > setup running that could be quicker path forward. > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90249 > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90255 > > Code size regressions on CSiBE for gcc-9.1.0 I think is worked on. > Thanks/Fredrik I'm curious how much can save following patch: diff --git a/gcc/tree-switch-conversion.h b/gcc/tree-switch-conversion.h index b3bc4b9ddf7..904827fa040 100644 --- a/gcc/tree-switch-conversion.h +++ b/gcc/tree-switch-conversion.h @@ -271,7 +271,7 @@ struct jump_table_cluster: public group_cluster static bool is_enabled (void); /* Max growth ratio for code that is optimized for size. */ - static const unsigned HOST_WIDE_INT max_ratio_for_size = 3; + static const unsigned HOST_WIDE_INT max_ratio_for_size = 2; /* Max growth ratio for code that is optimized for speed. */ static const unsigned HOST_WIDE_INT max_ratio_for_speed = 8;
[Bug sanitizer/90347] [UBSAN] __attribute__((weak))__ results in "declared weak after being used" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90347 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-06 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |10.0 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed. @Marek can you please take a look?
[Bug middle-end/90340] Not optimal code when compiling switch-case for size, code increase +35%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90340 --- Comment #8 from Fredrik Hederstierna --- Ok, thannks, I will try to have a look at it later tonight (I'm at my regular job now ;-) Thanks/Fredrik
[Bug tree-optimization/90327] [9/10 Regression] ICE in convert_move, at expr.c:218 since r265677 on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90327
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|2019-05-03 00:00:00 |2019-05-06
CC||matz at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
Confirmed.
We're emitting a partition copy from
(mem/c:BLK (plus:DI (reg/f:DI 55 virtual-stack-vars)
(const_int -4 [0xfffc])) [2 n+0 S4 A32])
to
(reg:V1SF 61)
We don't seem to expect this looking at emit_partition_copy, which
just expects a BLKmode/BLKmode combo but not a mixed case.
/* Emit insns to copy SRC into DEST converting SRC if necessary. As
SRC/DEST might be BLKmode memory locations SIZEEXP is a tree from
which we deduce the size to copy in that case. */
static inline rtx_insn *
emit_partition_copy (rtx dest, rtx src, int unsignedsrcp, tree sizeexp)
{
start_sequence ();
if (GET_MODE (src) != VOIDmode && GET_MODE (src) != GET_MODE (dest))
src = convert_to_mode (GET_MODE (dest), src, unsignedsrcp);
if (GET_MODE (src) == BLKmode)
{
gcc_assert (GET_MODE (dest) == BLKmode);
emit_block_move (dest, src, expr_size (sizeexp), BLOCK_OP_NORMAL);
}
[Bug tree-optimization/90358] New: [10 Regression] 526.blender_r train run does not finish after r270847 on znver1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90358 Bug ID: 90358 Summary: [10 Regression] 526.blender_r train run does not finish after r270847 on znver1 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- The benchmarks fails to run in train run, probably due to a timeout (I terminated that after 10 minutes).
[Bug tree-optimization/90358] [10 Regression] 526.blender_r train run does not finish after r270847 on znver1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90358 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-05-06 CC||rguenth at gcc dot gnu.org Blocks||26163 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- I'm investigating that more.. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug tree-optimization/90328] [7/8/9/10 Regression] Wrong loop distribution with aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90328
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Known to work||4.8.5, 5.5.0
Target Milestone|--- |7.5
Summary|Wrong loop distribution |[7/8/9/10 Regression] Wrong
|with aliasing |loop distribution with
||aliasing
Known to fail||6.5.0, 8.3.0
--- Comment #3 from Richard Biener ---
Note vectorization also "breaks" it at -O2 -ftree-vectorize.
void g(int*__restrict x, int*y){*x=*y;}
void __attribute__((noipa)) f(int* a,int* b)
{
for(int i=0;i<1024;++i)
g(a+i,b+i);
}
int main()
{
int x[1025];
for (int i = 0; i < 1025; ++i)
x[i] = i+1;
f(x+1, x);
for (int i = 0; i < 1025; ++i)
if (x[i] != 1)
__builtin_abort ();
return 0;
}
[Bug c++/89698] [7 Regression] Run-time error due to optimization of field access after cast at -Os/-O2 and higher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89698 --- Comment #9 from Richard Biener --- Author: rguenth Date: Mon May 6 09:40:15 2019 New Revision: 270904 URL: https://gcc.gnu.org/viewcvs?rev=270904&root=gcc&view=rev Log: 2019-05-03 Richard Biener Backport from mainline 2019-03-14 Richard Biener PR middle-end/89698 * fold-const.c (operand_equal_p): For INDIRECT_REF check that the access types are similar. * g++.dg/torture/pr89698.C: New testcase. 2019-03-07 Richard Biener PR tree-optimization/89595 * tree-ssa-dom.c (dom_opt_dom_walker::optimize_stmt): Take stmt iterator as reference, take boolean output parameter to indicate whether the stmt was removed and thus the iterator already advanced. (dom_opt_dom_walker::before_dom_children): Re-iterate over stmts created by folding. * gcc.dg/torture/pr89595.c: New testcase. 2019-03-14 Richard Biener PR tree-optimization/89710 * tree-ssa-loop-ch.c (should_duplicate_loop_header_p): Use safe_dyn_cast. * gcc.dg/torture/pr89710.c: New testcase. 2019-04-15 Richard Biener PR tree-optimization/90071 * tree-ssa-reassoc.c (init_range_entry): Do not pick up abnormal operands from def stmts. * gcc.dg/torture/pr90071.c: New testcase. 2018-08-20 Bernd Edlinger PR target/86984 * expr.c (expand_assignment): Assert that bitpos is positive. (store_field): Likewise (expand_expr_real_1): Make sure that bitpos is positive. * config/alpha/alpha.h (CONSTANT_ADDRESS_P): Avoid signed integer overflow. * gcc.target/alpha/pr86984.c: New test. 2019-03-14 Richard Biener PR target/89711 * config/i386/i386.c (make_resolver_func): Properly set DECL_CONTEXT on the RESULT_DECL. * config/rs6000/rs6000.c (make_resolver_func): Likewise. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/torture/pr89698.C branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr89595.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr89710.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr90071.c branches/gcc-8-branch/gcc/testsuite/gcc.target/alpha/pr86984.c
[Bug target/86984] invalid relocation accessing a const char array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86984 --- Comment #10 from Richard Biener --- Author: rguenth Date: Mon May 6 09:40:15 2019 New Revision: 270904 URL: https://gcc.gnu.org/viewcvs?rev=270904&root=gcc&view=rev Log: 2019-05-03 Richard Biener Backport from mainline 2019-03-14 Richard Biener PR middle-end/89698 * fold-const.c (operand_equal_p): For INDIRECT_REF check that the access types are similar. * g++.dg/torture/pr89698.C: New testcase. 2019-03-07 Richard Biener PR tree-optimization/89595 * tree-ssa-dom.c (dom_opt_dom_walker::optimize_stmt): Take stmt iterator as reference, take boolean output parameter to indicate whether the stmt was removed and thus the iterator already advanced. (dom_opt_dom_walker::before_dom_children): Re-iterate over stmts created by folding. * gcc.dg/torture/pr89595.c: New testcase. 2019-03-14 Richard Biener PR tree-optimization/89710 * tree-ssa-loop-ch.c (should_duplicate_loop_header_p): Use safe_dyn_cast. * gcc.dg/torture/pr89710.c: New testcase. 2019-04-15 Richard Biener PR tree-optimization/90071 * tree-ssa-reassoc.c (init_range_entry): Do not pick up abnormal operands from def stmts. * gcc.dg/torture/pr90071.c: New testcase. 2018-08-20 Bernd Edlinger PR target/86984 * expr.c (expand_assignment): Assert that bitpos is positive. (store_field): Likewise (expand_expr_real_1): Make sure that bitpos is positive. * config/alpha/alpha.h (CONSTANT_ADDRESS_P): Avoid signed integer overflow. * gcc.target/alpha/pr86984.c: New test. 2019-03-14 Richard Biener PR target/89711 * config/i386/i386.c (make_resolver_func): Properly set DECL_CONTEXT on the RESULT_DECL. * config/rs6000/rs6000.c (make_resolver_func): Likewise. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/torture/pr89698.C branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr89595.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr89710.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr90071.c branches/gcc-8-branch/gcc/testsuite/gcc.target/alpha/pr86984.c
[Bug tree-optimization/90071] [7 Regression] internal compiler error: SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90071 --- Comment #7 from Richard Biener --- Author: rguenth Date: Mon May 6 09:40:15 2019 New Revision: 270904 URL: https://gcc.gnu.org/viewcvs?rev=270904&root=gcc&view=rev Log: 2019-05-03 Richard Biener Backport from mainline 2019-03-14 Richard Biener PR middle-end/89698 * fold-const.c (operand_equal_p): For INDIRECT_REF check that the access types are similar. * g++.dg/torture/pr89698.C: New testcase. 2019-03-07 Richard Biener PR tree-optimization/89595 * tree-ssa-dom.c (dom_opt_dom_walker::optimize_stmt): Take stmt iterator as reference, take boolean output parameter to indicate whether the stmt was removed and thus the iterator already advanced. (dom_opt_dom_walker::before_dom_children): Re-iterate over stmts created by folding. * gcc.dg/torture/pr89595.c: New testcase. 2019-03-14 Richard Biener PR tree-optimization/89710 * tree-ssa-loop-ch.c (should_duplicate_loop_header_p): Use safe_dyn_cast. * gcc.dg/torture/pr89710.c: New testcase. 2019-04-15 Richard Biener PR tree-optimization/90071 * tree-ssa-reassoc.c (init_range_entry): Do not pick up abnormal operands from def stmts. * gcc.dg/torture/pr90071.c: New testcase. 2018-08-20 Bernd Edlinger PR target/86984 * expr.c (expand_assignment): Assert that bitpos is positive. (store_field): Likewise (expand_expr_real_1): Make sure that bitpos is positive. * config/alpha/alpha.h (CONSTANT_ADDRESS_P): Avoid signed integer overflow. * gcc.target/alpha/pr86984.c: New test. 2019-03-14 Richard Biener PR target/89711 * config/i386/i386.c (make_resolver_func): Properly set DECL_CONTEXT on the RESULT_DECL. * config/rs6000/rs6000.c (make_resolver_func): Likewise. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/torture/pr89698.C branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr89595.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr89710.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr90071.c branches/gcc-8-branch/gcc/testsuite/gcc.target/alpha/pr86984.c
[Bug tree-optimization/89595] [8 Regression] DOM miscompiles code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89595 --- Comment #9 from Richard Biener --- Author: rguenth Date: Mon May 6 09:40:15 2019 New Revision: 270904 URL: https://gcc.gnu.org/viewcvs?rev=270904&root=gcc&view=rev Log: 2019-05-03 Richard Biener Backport from mainline 2019-03-14 Richard Biener PR middle-end/89698 * fold-const.c (operand_equal_p): For INDIRECT_REF check that the access types are similar. * g++.dg/torture/pr89698.C: New testcase. 2019-03-07 Richard Biener PR tree-optimization/89595 * tree-ssa-dom.c (dom_opt_dom_walker::optimize_stmt): Take stmt iterator as reference, take boolean output parameter to indicate whether the stmt was removed and thus the iterator already advanced. (dom_opt_dom_walker::before_dom_children): Re-iterate over stmts created by folding. * gcc.dg/torture/pr89595.c: New testcase. 2019-03-14 Richard Biener PR tree-optimization/89710 * tree-ssa-loop-ch.c (should_duplicate_loop_header_p): Use safe_dyn_cast. * gcc.dg/torture/pr89710.c: New testcase. 2019-04-15 Richard Biener PR tree-optimization/90071 * tree-ssa-reassoc.c (init_range_entry): Do not pick up abnormal operands from def stmts. * gcc.dg/torture/pr90071.c: New testcase. 2018-08-20 Bernd Edlinger PR target/86984 * expr.c (expand_assignment): Assert that bitpos is positive. (store_field): Likewise (expand_expr_real_1): Make sure that bitpos is positive. * config/alpha/alpha.h (CONSTANT_ADDRESS_P): Avoid signed integer overflow. * gcc.target/alpha/pr86984.c: New test. 2019-03-14 Richard Biener PR target/89711 * config/i386/i386.c (make_resolver_func): Properly set DECL_CONTEXT on the RESULT_DECL. * config/rs6000/rs6000.c (make_resolver_func): Likewise. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/torture/pr89698.C branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr89595.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr89710.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr90071.c branches/gcc-8-branch/gcc/testsuite/gcc.target/alpha/pr86984.c
[Bug tree-optimization/89595] [8 Regression] DOM miscompiles code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89595 --- Comment #10 from rguenther at suse dot de --- On Sat, 4 May 2019, mikpelinux at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89595 > > Mikael Pettersson changed: > >What|Removed |Added > > CC||mikpelinux at gmail dot com > > --- Comment #8 from Mikael Pettersson --- > Seems like the backport to gcc-8 didn't include the test case. At least two > of > the test cases mentioned in r270841 aren't actually in the svn repo on > gcc-8-branch. An unintentional omission? Whoops - thanks for noticing. Fixed.
[Bug tree-optimization/90358] [10 Regression] 526.blender_r train run does not finish after r270847 on znver1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90358 Richard Biener changed: What|Removed |Added Version|9.0 |10.0 Target Milestone|--- |10.0
[Bug middle-end/90356] Missed optimization for variables initialized to 0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90356
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2019-05-06
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #5 from Jakub Jelinek ---
Untested fix:
--- gcc/match.pd.jj 2019-05-03 15:22:07.370401908 +0200
+++ gcc/match.pd2019-05-06 11:26:04.701663020 +0200
@@ -152,6 +152,28 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(if (fold_real_zero_addition_p (type, @1, 1))
(non_lvalue @0)))
+/* Even if the fold_real_zero_addition_p can't simplify X + 0.0
+ into X, we can optimize (X + 0.0) + 0.0 or (X + 0.0) - 0.0
+ or (X - 0.0) + 0.0 into X + 0.0 and (X - 0.0) - 0.0 into X - 0.0
+ if not -frounding-math. For sNaNs the first operation would raise
+ exceptions but turn the result into qNan, so the second operation
+ would not raise it. */
+(for inner_op (plus minus)
+ (for outer_op (plus minus)
+ (simplify
+ (outer_op (inner_op @0 real_zerop@1) real_zerop@2)
+(if (TREE_CODE (@1) == REAL_CST
+&& TREE_CODE (@2) == REAL_CST
+&& HONOR_SIGNED_ZEROS (element_mode (type))
+&& !HONOR_SIGN_DEPENDENT_ROUNDING (element_mode (type)))
+ (with { bool plus1 = ((inner_op == PLUS_EXPR)
+ ^ REAL_VALUE_MINUS_ZERO (TREE_REAL_CST (@1)));
+bool plus2 = ((outer_op == PLUS_EXPR)
+ ^ REAL_VALUE_MINUS_ZERO (TREE_REAL_CST (@2))); }
+ (if (plus2 && !plus1)
+ (outer_op @0 @2)
+ (inner_op @0 @1)))
+
/* Simplify x - x.
This is unsafe for certain floats even in non-IEEE formats.
In IEEE, it is unsafe because it does wrong for NaNs.
[Bug tree-optimization/89710] [7 Regression] ICE in dyn_cast(gimple*) / should_duplicate_loop_header_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89710 --- Comment #6 from Richard Biener --- Author: rguenth Date: Mon May 6 09:40:15 2019 New Revision: 270904 URL: https://gcc.gnu.org/viewcvs?rev=270904&root=gcc&view=rev Log: 2019-05-03 Richard Biener Backport from mainline 2019-03-14 Richard Biener PR middle-end/89698 * fold-const.c (operand_equal_p): For INDIRECT_REF check that the access types are similar. * g++.dg/torture/pr89698.C: New testcase. 2019-03-07 Richard Biener PR tree-optimization/89595 * tree-ssa-dom.c (dom_opt_dom_walker::optimize_stmt): Take stmt iterator as reference, take boolean output parameter to indicate whether the stmt was removed and thus the iterator already advanced. (dom_opt_dom_walker::before_dom_children): Re-iterate over stmts created by folding. * gcc.dg/torture/pr89595.c: New testcase. 2019-03-14 Richard Biener PR tree-optimization/89710 * tree-ssa-loop-ch.c (should_duplicate_loop_header_p): Use safe_dyn_cast. * gcc.dg/torture/pr89710.c: New testcase. 2019-04-15 Richard Biener PR tree-optimization/90071 * tree-ssa-reassoc.c (init_range_entry): Do not pick up abnormal operands from def stmts. * gcc.dg/torture/pr90071.c: New testcase. 2018-08-20 Bernd Edlinger PR target/86984 * expr.c (expand_assignment): Assert that bitpos is positive. (store_field): Likewise (expand_expr_real_1): Make sure that bitpos is positive. * config/alpha/alpha.h (CONSTANT_ADDRESS_P): Avoid signed integer overflow. * gcc.target/alpha/pr86984.c: New test. 2019-03-14 Richard Biener PR target/89711 * config/i386/i386.c (make_resolver_func): Properly set DECL_CONTEXT on the RESULT_DECL. * config/rs6000/rs6000.c (make_resolver_func): Likewise. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/torture/pr89698.C branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr89595.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr89710.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr90071.c branches/gcc-8-branch/gcc/testsuite/gcc.target/alpha/pr86984.c
[Bug target/89711] [8 Regression] ICE in insert_vi_for_tree, at tree-ssa-structalias.c:2832
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89711 --- Comment #10 from Richard Biener --- Author: rguenth Date: Mon May 6 09:40:15 2019 New Revision: 270904 URL: https://gcc.gnu.org/viewcvs?rev=270904&root=gcc&view=rev Log: 2019-05-03 Richard Biener Backport from mainline 2019-03-14 Richard Biener PR middle-end/89698 * fold-const.c (operand_equal_p): For INDIRECT_REF check that the access types are similar. * g++.dg/torture/pr89698.C: New testcase. 2019-03-07 Richard Biener PR tree-optimization/89595 * tree-ssa-dom.c (dom_opt_dom_walker::optimize_stmt): Take stmt iterator as reference, take boolean output parameter to indicate whether the stmt was removed and thus the iterator already advanced. (dom_opt_dom_walker::before_dom_children): Re-iterate over stmts created by folding. * gcc.dg/torture/pr89595.c: New testcase. 2019-03-14 Richard Biener PR tree-optimization/89710 * tree-ssa-loop-ch.c (should_duplicate_loop_header_p): Use safe_dyn_cast. * gcc.dg/torture/pr89710.c: New testcase. 2019-04-15 Richard Biener PR tree-optimization/90071 * tree-ssa-reassoc.c (init_range_entry): Do not pick up abnormal operands from def stmts. * gcc.dg/torture/pr90071.c: New testcase. 2018-08-20 Bernd Edlinger PR target/86984 * expr.c (expand_assignment): Assert that bitpos is positive. (store_field): Likewise (expand_expr_real_1): Make sure that bitpos is positive. * config/alpha/alpha.h (CONSTANT_ADDRESS_P): Avoid signed integer overflow. * gcc.target/alpha/pr86984.c: New test. 2019-03-14 Richard Biener PR target/89711 * config/i386/i386.c (make_resolver_func): Properly set DECL_CONTEXT on the RESULT_DECL. * config/rs6000/rs6000.c (make_resolver_func): Likewise. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/torture/pr89698.C branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr89595.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr89710.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr90071.c branches/gcc-8-branch/gcc/testsuite/gcc.target/alpha/pr86984.c
[Bug tree-optimization/90356] Missed optimization for variables initialized to 0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90356 --- Comment #6 from Jakub Jelinek --- Created attachment 46301 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46301&action=edit gcc10-pr90356.patch Full untested patch.
[Bug target/90359] New: [8 Regression] profiled bootstrap fails on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90359 Bug ID: 90359 Summary: [8 Regression] profiled bootstrap fails on aarch64-linux-gnu Product: gcc Version: 8.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: doko at debian dot org Target Milestone: --- seen on the gcc-8 branch for aarch64-linux-gnu with a profiled bootstrap. Last successful build was r270630. during GIMPLE pass: dom ../../src/gcc/genoutput.c: In function 'void place_operands(data*)': ../../src/gcc/genoutput.c:566:1: internal compiler error: Segmentation fault place_operands (struct data *d) ^~ 0xaecbd7 crash_signal ../../src/gcc/toplev.c:325 0xd0916c set_value_range(value_range*, value_range_type, tree_node*, tree_node*, bitmap_head*) ../../src/gcc/tree-vrp.c:298 0xd69c4b vr_values::update_value_range(tree_node const*, value_range*) ../../src/gcc/vr-values.c:222 0x104fc9f evrp_range_analyzer::record_ranges_from_stmt(gimple*, bool) ../../src/gcc/gimple-ssa-evrp-analyze.c:311 0xbdb83b dom_opt_dom_walker::before_dom_children(basic_block_def*) ../../src/gcc/tree-ssa-dom.c:1473 0x10363c3 dom_walker::walk(basic_block_def*) ../../src/gcc/domwalk.c:353 0xbdc23b execute ../../src/gcc/tree-ssa-dom.c:722 Please submit a full bug report, with preprocessed source if appropriate.
[Bug tree-optimization/90358] [10 Regression] 526.blender_r train run does not finish after r270847 on znver1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90358 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Created attachment 46302 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46302&action=edit untested patch Does this help?
[Bug tree-optimization/90358] [10 Regression] 526.blender_r train run does not finish after r270847 on znver1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90358 --- Comment #3 from Martin Liška --- (In reply to Richard Biener from comment #2) > Created attachment 46302 [details] > untested patch > > Does this help? Yes, it helps. The affected file was: blender/source/blender/modifiers/intern/MOD_solidify.o I guess you don't need a test-case to be reduced?
[Bug target/90360] New: Missed optimization: unnecessary use of callee-saved registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90360
Bug ID: 90360
Summary: Missed optimization: unnecessary use of callee-saved
registers
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: coypu at sdf dot org
Target Milestone: ---
if I compile this code with -O3
typedef struct once_t {
int val;
int pto_done;
} once_t;
int
once_stub(once_t *o, void (*r)(void))
{
if (o->pto_done == 0) {
(*r)();
o->pto_done = 1;
}
return (0);
}
The output is:
once_stub(once_t*, void (*)()):
movl4(%rdi), %eax
testl %eax, %eax
jne .L4
pushq %rbx
movq%rdi, %rbx
call*%rsi
movl$1, 4(%rbx)
xorl%eax, %eax
popq%rbx
ret
.L4:
xorl%eax, %eax
ret
I think push/pop instructions won't be necessary if
another register besides rbx is picked.
[Bug tree-optimization/90358] [10 Regression] 526.blender_r train run does not finish after r270847 on znver1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90358 --- Comment #4 from rguenther at suse dot de --- On Mon, 6 May 2019, marxin at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90358 > > --- Comment #3 from Martin Liška --- > (In reply to Richard Biener from comment #2) > > Created attachment 46302 [details] > > untested patch > > > > Does this help? > > Yes, it helps. The affected file was: > blender/source/blender/modifiers/intern/MOD_solidify.o > > I guess you don't need a test-case to be reduced? Indeed.
[Bug fortran/90329] Incompatibility between gfortran and C lapack calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329 --- Comment #11 from Tomas Kalibera --- Even restoring the state that LAPACK/BLAS works but without providing guarantees would help short-term, and I think this could be in line with the goal of best performance within the standard. At least in the case I debugged, I think gfortran could do better by not writing the 1 as string length to the place on the stack where the compiler knows there is already 1 as string length.
[Bug target/90360] Missed optimization: unnecessary use of callee-saved registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90360 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- the argument o needs to kept alive across the function call. So using rbx is correct.
[Bug target/90330] gcc 9.1.0 fails to install on macOS 10.14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330 --- Comment #8 from Matt Thompson --- (In reply to Iain Sandoe from comment #7) > (In reply to Matt Thompson from comment #6) > > (In reply to Iain Sandoe from comment #5) > > > (In reply to Matt Thompson from comment #4) > > > > Also: I do have all the log files still, so if you'd like anything > > > > grep'ed > > > > in there, let me know. > > > > > > not at this time.. I am trying to figure out what is different about our > > > configurations. > > > > > > --- > > > > > > can you confirm that this was a clean build (including that the target > > > install directory was deleted before the build?) > > > > It was a clean build. I always build out-of-source so it was a new directory > > and I'd never installed GCC 9.1.0 before, so the install directory was new > > as well. > > > > Let me try building again in a new directory with a new install location. Of > > course, being the impressive GCC build, it might be Monday before I can > > report back (it's a work laptop that stays at work). > > OK thanks, as it happens I won't be able to try on Darwin18 before next > Weds, so no hurry. I just tried to rebuild gcc 9.1.0 on my laptop, and I got the same error at the same point in make install. I'll try a few other experiments (remove /usr/local/bin from my path in case brew is causing an issue, though it didn't before). Or should I be using one of my other compilers to build gcc? I have built gcc 8.2.0. Instead of using clang, I could try that...though I'm not sure how. Just pass in CC and CXX to configure?
[Bug fortran/90329] Incompatibility between gfortran and C lapack calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #12 from Janne Blomqvist ---
(In reply to Tomas Kalibera from comment #11)
> At least in the case I debugged, I think gfortran could do better by not
> writing the 1 as string length to the place on the stack where the compiler
> knows there is already 1 as string length.
The problem is not that the compiler gets the wrong string length, in this case
when the procedure argument is defined to have a length of 1, the compiler
never needs to access the hidden string length argument [1].
The problem is that both the caller and the callee need to agree on the number
(and type) of arguments. And because in Fortran implicit interfaces
("F77"-style interfaces, without modules, interface blocks or any other
newfangled "modern Fortran" stuff) the only information about the interface of
a procedure that the caller knows is the name of the procedure. So for an
example compiling the code
call foo("abc")
the compiler has no knowledge of the procedure beyond the name "foo". From this
code the compiler can then deduce that it must be a subroutine, and that it
takes one argument of type character. But the compiler cannot verify this, it
must assume the programmer knows what he's doing. Now, the problem is that the
definition of the procedure can be
subroutine foo(a)
character(len=1) :: a
end subroutine foo
or
subroutine foo(a)
character(len=3) :: a ! Or len=2
end subroutine foo
or
subroutine foo(a)
character(len=*) :: a
end subroutine foo
In the first two the hidden string length argument is not needed, but because
the procedure ABI must match for all the possibilities, and for the third case
the hidden length IS needed, the hidden string length argument is always
needed, although it's unused when the length is fixed.
[1] It would be possible to have some optional debugging option which inserts
code to verify that the actual argument length >= the dummy argument length.
But that's not really related to this issue.
[Bug target/90359] [8 Regression] profiled bootstrap fails on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90359 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-05-06 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |8.4 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Testing fix already.
[Bug target/90330] gcc 9.1.0 fails to install on macOS 10.14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330 --- Comment #9 from Iain Sandoe --- (In reply to Matt Thompson from comment #8) > (In reply to Iain Sandoe from comment #7) > > (In reply to Matt Thompson from comment #6) > > > (In reply to Iain Sandoe from comment #5) > > > > (In reply to Matt Thompson from comment #4) > > > > > Also: I do have all the log files still, so if you'd like anything > > > > > grep'ed > > > > > in there, let me know. > > > > > > > > not at this time.. I am trying to figure out what is different about our > > > > configurations. > > > > > > > > --- > > > > > > > > can you confirm that this was a clean build (including that the target > > > > install directory was deleted before the build?) > > > > > > It was a clean build. I always build out-of-source so it was a new > > > directory > > > and I'd never installed GCC 9.1.0 before, so the install directory was new > > > as well. > > > > > > Let me try building again in a new directory with a new install location. > > > Of > > > course, being the impressive GCC build, it might be Monday before I can > > > report back (it's a work laptop that stays at work). > > > > OK thanks, as it happens I won't be able to try on Darwin18 before next > > Weds, so no hurry. > > I just tried to rebuild gcc 9.1.0 on my laptop, and I got the same error at > the same point in make install. One possible (although I suspect unlikely) issue is a race condition when instslling symlinks which is known to occur on AFPS (the system I use for testing is HHFS+). does it reliably still fail if you try to restart the install? > I'll try a few other experiments (remove /usr/local/bin from my path in case > brew is causing an issue, though it didn't before). OK - when I build toolchains the environment has no macports/fink/homebrew content so there's no possibility of interaction. > > Or should I be using one of my other compilers to build gcc? I have built with both clang (10.2 command line tools) and a toolchain based on GCC 8.3 (although not a formal release) - both builds succeeded - I have no access to my Darwin18 system right now, so not able to attempt to repeat your exercise. Presumably, the 8.2 toolchains is correctly installed and has not been moved, so that the shared libraries from that are on the correct paths (the kind of error you are seeing could be the wrong dylib being found). If you can find the exact command line that fails and repeat it, prepended by DYLD_PRINT_LIBRARIES=1, that will show you which dylibs are loaded as the command tries to execute (there might be quite a lot of output, so not necessarily easy to interpret) I have built > gcc 8.2.0. Instead of using clang, I could try that...though I'm not sure > how. Just pass in CC and CXX to configure? yes, and/or make sure that the GCC toolchain bin dir is before the system ones in your path.
[Bug target/90346] gcc generates the "lfence" instruction on CPUs that don't support it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90346 Martin Liška changed: What|Removed |Added CC||hjl.tools at gmail dot com, ||uros at gcc dot gnu.org --- Comment #3 from Martin Liška --- Started with r263196, where: +(define_insn "speculation_barrier" + [(unspec_volatile [(const_int 0)] UNSPECV_SPECULATION_BARRIER)] + "" + "lfence" + [(set_attr "type" "other") + (set_attr "length" "3")]) + was added. lfence is SSE2 instruction, so the question is what to for older CPUs. Does it make sense to use __builtin_speculation_safe_value for such old CPUs? Are the CPUs really affected by SPECTRE v1?
[Bug fortran/90329] Incompatibility between gfortran and C lapack calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329 --- Comment #13 from Tomas Kalibera --- I understand the compiler may not know and typically does not whether the called function accepts "character(len=1)" or "character(len=*)", so it may have to pass the 1. But the situation where I suggest not writing the 1 is more subtle (see my original post - https://gcc.gnu.org/ml/fortran/2019-05/msg00021.html). There DPOSV is tail-calling (jumping) into DPOTRS). DPOSV wants to pass on the length of UPLO (1) to DPOTRS. DPOSV knows it was called with this hidden length argument of 1, and indeed at the same location on the stack as it is needed for DPOTRS, as the length of the same variable UPLO, but it still writes a compile-time constant 1 to that location on the stack that already has (should have) 1.
[Bug target/90330] gcc 9.1.0 fails to install on macOS 10.14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330 --- Comment #10 from Matt Thompson --- (In reply to Iain Sandoe from comment #9) > (In reply to Matt Thompson from comment #8) > > > > I just tried to rebuild gcc 9.1.0 on my laptop, and I got the same error at > > the same point in make install. > > One possible (although I suspect unlikely) issue is a race condition when > instslling symlinks which is known to occur on AFPS (the system I use for > testing is HHFS+). > > does it reliably still fail if you try to restart the install? It does indeed. Very repeatable. > > > I'll try a few other experiments (remove /usr/local/bin from my path in case > > brew is causing an issue, though it didn't before). > > OK - when I build toolchains the environment has no macports/fink/homebrew > content so there's no possibility of interaction. I don't usually remove it from my path because it had never caused any issues before. Note that I specifically do not let brew install gcc (or MPI). I like that control. I'm currently running a "no /usr/local/bin" test so we shall see if it helps. (I will say, as an aside, that I also can never get *spack* to build GCC on my laptop. Any version. Never figured that out either which is weird because it is a build from source!) > > > > > Or should I be using one of my other compilers to build gcc? > > I have built with both clang (10.2 command line tools) and a toolchain based > on GCC 8.3 (although not a formal release) - both builds succeeded - I have > no access to my Darwin18 system right now, so not able to attempt to repeat > your exercise. > > Presumably, the 8.2 toolchains is correctly installed and has not been > moved, so that the shared libraries from that are on the correct paths (the > kind of error you are seeing could be the wrong dylib being found). I install every release to its own tree and control access through lmod, so I can test this pretty easily. When I start up, I just have basics on my system (though I do symlink some brew utils to my ~/bin like gsed->sed because I cannot handle BSD sed. Grah!) > > If you can find the exact command line that fails and repeat it, prepended > by DYLD_PRINT_LIBRARIES=1, that will show you which dylibs are loaded as the > command tries to execute (there might be quite a lot of output, so not > necessarily easy to interpret) I just tried this and nothing happens. I tried both "DYLD_PRINT_LIBRARIES=1 g++ ..." and "env DYLD_PRINT_LIBRARIES=1 g++ ..." No change in output. > > I have built > > gcc 8.2.0. Instead of using clang, I could try that...though I'm not sure > > how. Just pass in CC and CXX to configure? > > yes, and/or make sure that the GCC toolchain bin dir is before the system > ones in your path. I'll try this as well as soon as I can (I can maybe manage make -j4 on this laptop, so builds aren't quick!). Do I need to pass FC as well? Or does the gcc build with fortran not care?
[Bug libstdc++/90361] New: Undefined symbols in libstdc++ when building with --with-default-libstdcxx-abi=gcc4-compatible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90361
Bug ID: 90361
Summary: Undefined symbols in libstdc++ when building with
--with-default-libstdcxx-abi=gcc4-compatible
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ostash at ostash dot kiev.ua
Target Milestone: ---
Hello,
When build gcc-9.1.0 with --with-default-libstdc xx-abi=gcc4-compatible
resulting libstdc++.so.6.0.26 contains following undefined symbols:
U std::__cxx11::basic_string,
std::allocator >::operator std::basic_string_view >() const
U std::__cxx11::basic_string,
std::allocator >::__sv_wrapper::__sv_wrapper(std::basic_string_view >)
U std::__cxx11::basic_string,
std::allocator >::_S_to_string_view(std::basic_string_view >)
U std::__cxx11::basic_string,
std::allocator >::data()
U std::__cxx11::basic_string,
std::allocator >::basic_string(std::__cxx11::basic_string, std::allocator >::__sv_wrapper,
std::allocator const&)
U std::__cxx11::basic_string, std::allocator >::data()
As result even minimal 'int main() { return 0; }' C++ program can't be linked.
[Bug target/90330] gcc 9.1.0 fails to install on macOS 10.14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330 --- Comment #11 from Iain Sandoe --- (In reply to Matt Thompson from comment #10) > (In reply to Iain Sandoe from comment #9) > > (In reply to Matt Thompson from comment #8) > I don't usually remove it from my path because it had never caused any > issues before. Note that I specifically do not let brew install gcc (or > MPI). I like that control. I'm currently running a "no /usr/local/bin" test > so we shall see if it helps. OK - let's be clear here. You must install GCC into the path that its configured with in order for the correct shared libraries to be found at runtime. so, if yo configure --prefix=/foo/bar/baz and then intstall into /baz/bar/foo that will not work correctly. The error you are showing seems that you are not finding the same libstdc++ at runtime as was assumed to be available by the build. > > If you can find the exact command line that fails and repeat it, prepended > > by DYLD_PRINT_LIBRARIES=1, that will show you which dylibs are loaded as the > > command tries to execute (there might be quite a lot of output, so not > > necessarily easy to interpret) > > I just tried this and nothing happens. I tried both "DYLD_PRINT_LIBRARIES=1 > g++ ..." and "env DYLD_PRINT_LIBRARIES=1 g++ ..." No change in output. "which g++" probably says you are using clang++ and that it a protected exe that will elide DYLD_* when invoked. In that case, it's hard to do that test. > > > > > I have built > > > gcc 8.2.0. Instead of using clang, I could try that...though I'm not sure > > > how. Just pass in CC and CXX to configure? > > > > yes, and/or make sure that the GCC toolchain bin dir is before the system > > ones in your path. > > I'll try this as well as soon as I can (I can maybe manage make -j4 on this > laptop, so builds aren't quick!). Do I need to pass FC as well? Or does the > gcc build with fortran not care? Fortran is built with the C++ compiler, but I'd put the GCC bin dir in the path first - and then you will be able to do the DYLD_** commands using the bootstrap compiler tools to install.
[Bug target/90362] New: or1k: Soft divide does not work correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90362
Bug ID: 90362
Summary: or1k: Soft divide does not work correctly
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: shorne at gcc dot gnu.org
Target Milestone: ---
Example:
#include
int main() {
printf ("400/3 = %d", 400/3);
}
When running:
$ or1k-elf-gcc -msoft-div simplediv.c
$ or1k-elf-run ./a.out
400/3 = 3�
Expected
400/3 = 133
[Bug target/90362] or1k: Soft divide does not work correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90362 Stafford Horne changed: What|Removed |Added Target||or1k Status|UNCONFIRMED |NEW URL||https://github.com/stffrdhr ||n/gcc/issues/6 Last reconfirmed||2019-05-06 CC||shorne at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Stafford Horne --- Proposed patch: diff --git a/libgcc/config/or1k/lib1funcs.S b/libgcc/config/or1k/lib1funcs.S index d2103923486..6d058977229 100644 --- a/libgcc/config/or1k/lib1funcs.S +++ b/libgcc/config/or1k/lib1funcs.S @@ -68,18 +68,18 @@ __udivmodsi3_internal: is not clobbered by this routine, and use that as to save a return address without creating a stack frame. */ - l.sfeqi r4, 0 /* division by zero; return 0. */ + l.sfeq r4, r0 /* division by zero; return 0. */ l.ori r11, r0, 0 /* initial quotient */ l.bf9f l.ori r12, r3, 0 /* initial remainder */ /* Given X/Y, shift Y left until Y >= X. */ l.ori r6, r0, 1 /* mask = 1 */ -1: l.sfltsir4, 0 /* y has msb set */ +1: l.sflts r4, r0 /* y has msb set */ l.bf2f l.sfltur4, r12 /* y < x */ l.add r4, r4, r4 /* y <<= 1 */ - l.bnf 1b + l.bf1b
[Bug target/90362] or1k: Soft divide does not work correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90362 Stafford Horne changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |shorne at gcc dot gnu.org
[Bug tree-optimization/90328] [7/8/9 Regression] Wrong loop distribution with aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90328 Richard Biener changed: What|Removed |Added Known to work||10.0 Summary|[7/8/9/10 Regression] Wrong |[7/8/9 Regression] Wrong |loop distribution with |loop distribution with |aliasing|aliasing Known to fail||9.1.0 --- Comment #4 from Richard Biener --- Fixed on trunk sofar.
[Bug tree-optimization/90328] [7/8/9 Regression] Wrong loop distribution with aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90328 --- Comment #5 from Richard Biener --- Author: rguenth Date: Mon May 6 12:38:35 2019 New Revision: 270906 URL: https://gcc.gnu.org/viewcvs?rev=270906&root=gcc&view=rev Log: 2019-05-06 Richard Biener PR tree-optimization/90328 * tree-data-ref.h (dr_may_alias_p): Pass in the actual loop nest. * tree-data-ref.c (dr_may_alias_p): Check whether the clique is valid in the loop nest before using it. (initialize_data_dependence_relation): Adjust. * graphite-scop-detection.c (build_alias_set): Pass the SCOP enclosing loop as loop-nest to dr_may_alias_p. * gcc.dg/torture/pr90328.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr90328.c Modified: trunk/gcc/ChangeLog trunk/gcc/graphite-scop-detection.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-data-ref.c trunk/gcc/tree-data-ref.h
[Bug target/90359] [8 Regression] profiled bootstrap fails on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90359 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Richard Biener --- Fixed.
[Bug target/90359] [8 Regression] profiled bootstrap fails on aarch64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90359 --- Comment #3 from Richard Biener --- Author: rguenth Date: Mon May 6 12:40:18 2019 New Revision: 270907 URL: https://gcc.gnu.org/viewcvs?rev=270907&root=gcc&view=rev Log: 2019-05-06 Richard Biener PR bootstrap/90359 Backport from mainline 2019-03-11 Jakub Jelinek PR middle-end/89655 PR bootstrap/89656 * vr-values.c (vr_values::update_value_range): If old_vr->varying_p (), don't update it, make new_vr also VARYING and return false. * gcc.c-torture/compile/pr89655.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.c-torture/compile/pr89655.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/vr-values.c
[Bug middle-end/89655] GCC crashes building linux kernel for arm 32-bit (culprit r269453)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89655 --- Comment #9 from Richard Biener --- Author: rguenth Date: Mon May 6 12:40:18 2019 New Revision: 270907 URL: https://gcc.gnu.org/viewcvs?rev=270907&root=gcc&view=rev Log: 2019-05-06 Richard Biener PR bootstrap/90359 Backport from mainline 2019-03-11 Jakub Jelinek PR middle-end/89655 PR bootstrap/89656 * vr-values.c (vr_values::update_value_range): If old_vr->varying_p (), don't update it, make new_vr also VARYING and return false. * gcc.c-torture/compile/pr89655.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.c-torture/compile/pr89655.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/vr-values.c
[Bug target/90363] New: or1k: Extra mask insn after load from memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90363
Bug ID: 90363
Summary: or1k: Extra mask insn after load from memory
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: shorne at gcc dot gnu.org
Target Milestone: ---
When compiling the below code we see and extra "l.andi r17, r17, 0xff" mask
instruction when reading a byte from memory. This is not needed as loads
already zero extend.
Example:
#include
volatile uint8_t g_doswap = 1;
uint64_t swap_1(uint64_t u64)
{
uint32_t u64_lo, u64_hi, u64_tmp;
u64_lo = u64 & 0x;
u64_hi = u64 >> 32;
if (g_doswap) {
u64_tmp = u64_lo;
u64_lo = u64_hi;
u64_hi = u64_tmp;
}
u64 = u64_lo;
u64 += ((uint64_t) u64_hi << 32);
return u64;
} // swap_1
Output: or1k-elf-gcc -O2 -S doswap_1.c
.file "doswap_1.c"
.section.text
.align 4
.global swap_1
.type swap_1, @function
swap_1:
l.movhi r17, ha(.LANCHOR0)
l.lbz r17, lo(.LANCHOR0)(r17)
l.andi r17, r17, 0xff// < Where is this
coming from
l.movhi r19, hi(0)
l.sfeq r17, r19
l.orr12, r4, r4
l.bf.L6
l.orr11, r3, r3
l.bf.L6
l.orr11, r4, r4
l.orr12, r3, r3
.L6:
l.jrr9
l.nop
.size swap_1, .-swap_1
.global g_doswap
.section.data
.set.LANCHOR0,. + 0
.type g_doswap, @object
.size g_doswap, 1
g_doswap:
.byte 1
.ident "GCC: (GNU) 9.0.1 20190326 (experimental)"
[Bug target/90363] or1k: Extra mask insn after load from memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90363 Stafford Horne changed: What|Removed |Added Target||or1k Status|UNCONFIRMED |ASSIGNED URL||https://github.com/stffrdhr ||n/gcc/issues/4 Last reconfirmed||2019-05-06 Assignee|unassigned at gcc dot gnu.org |shorne at gcc dot gnu.org Ever confirmed|0 |1
[Bug fortran/90329] Incompatibility between gfortran and C lapack calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329 --- Comment #14 from rguenther at suse dot de --- On Mon, 6 May 2019, tomas.kalibera at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329 > > --- Comment #13 from Tomas Kalibera --- > I understand the compiler may not know and typically does not whether the > called function accepts "character(len=1)" or "character(len=*)", so it may > have to pass the 1. But the situation where I suggest not writing the 1 is > more > subtle (see my original post - > https://gcc.gnu.org/ml/fortran/2019-05/msg00021.html). > > There DPOSV is tail-calling (jumping) into DPOTRS). DPOSV wants to pass on the > length of UPLO (1) to DPOTRS. DPOSV knows it was called with this hidden > length > argument of 1, and indeed at the same location on the stack as it is needed > for > DPOTRS, as the length of the same variable UPLO, but it still writes a > compile-time constant 1 to that location on the stack that already has (should > have) 1. I think that's called sibling-calling, not tailcalling (tail-call with same arguments).
[Bug target/90362] or1k: Soft divide does not work correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90362 --- Comment #2 from Stafford Horne --- Originally reported by Richard Selvaggi.
[Bug bootstrap/89656] [9 Regression] profiledbootstrap failure on aarch64-linux since r269453
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89656 --- Comment #6 from Richard Biener --- Author: rguenth Date: Mon May 6 12:40:18 2019 New Revision: 270907 URL: https://gcc.gnu.org/viewcvs?rev=270907&root=gcc&view=rev Log: 2019-05-06 Richard Biener PR bootstrap/90359 Backport from mainline 2019-03-11 Jakub Jelinek PR middle-end/89655 PR bootstrap/89656 * vr-values.c (vr_values::update_value_range): If old_vr->varying_p (), don't update it, make new_vr also VARYING and return false. * gcc.c-torture/compile/pr89655.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.c-torture/compile/pr89655.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/vr-values.c
[Bug tree-optimization/88828] Inefficient update of the first element of vector registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88828 --- Comment #5 from Richard Biener --- Author: rguenth Date: Mon May 6 12:43:30 2019 New Revision: 270908 URL: https://gcc.gnu.org/viewcvs?rev=270908&root=gcc&view=rev Log: 2019-05-06 Richard Biener PR tree-optimization/88828 * tree-ssa-forwprop.c (get_bit_field_ref_def): Split out from... (simplify_vector_constructor): ...here. Handle constants in the constructor. * gcc.target/i386/pr88828-0.c: New testcase. Added: trunk/gcc/testsuite/gcc.target/i386/pr88828-0.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-forwprop.c
[Bug gcov-profile/90364] New: 521.wrf_r is 9.5 % slower with PGO on Zen CPUs at -Ofast and native march/mtune
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90364 Bug ID: 90364 Summary: 521.wrf_r is 9.5 % slower with PGO on Zen CPUs at -Ofast and native march/mtune Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: jamborm at gcc dot gnu.org CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org Blocks: 26163 Target Milestone: --- Host: x86_64-linux Target: x86_64-linux In my measurements using trunk r270639, profile guided optimization (PGO) regresses the run time of 521.wrf_r from SPEC FPrate 2017 by 9.5% (and even LTO+PGO is 7% slower than when using neither) when compiling with -Ofast -march=native -mtune=native. My observations are consistent with data from LNT: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=33.548.0&plot.1=15.548.0&plot.2=12.548.0&plot.3=17.548.0&; Perf stat and report for the two runs are: Non-PGO (fast): 304790.490558 task-clock:u (msec) #0.994 CPUs utilized 0 context-switches:u#0.000 K/sec 0 cpu-migrations:u #0.000 K/sec 292908 page-faults:u #0.961 K/sec 962209421444 cycles:u # 24018297656 stalled-cycles-frontend:u #2.50% frontend cycles idle (83.35%) 142992971234 stalled-cycles-backend:u # 14.86% backend cycles idle (83.33%) 1792410646274 instructions:u#1.86 insn per cycle #0.08 stalled cycles per insn (83.34%) 185705451528 branches:u# 609.289 M/sec (83.34%) 2087790818 branch-misses:u #1.12% of all branches (83.35%) 306.542849367 seconds time elapsed # Samples: 1M of event 'cycles' # Event count (approx.): 964214205064 # # OverheadSamples Shared Object Symbol # . ... .. # 7.02% 85562 libm-2.29.so __logf_fma 5.99% 72982 libm-2.29.so __powf_fma 5.44% 66794 wrf_r_peak.std __module_advect_em_MOD_advect_scalar_pd 5.21% 63576 libm-2.29.so __atanf 4.30% 52426 libmvec-2.29.so _ZGVbN4v_expf_sse4 4.04% 49253 wrf_r_peak.std__module_mp_wsm5_MOD_wsm52d 3.93% 47888 wrf_r_peak.std__module_mp_wsm5_MOD_nislfv_rain_plm 2.97% 36505 wrf_r_peak.std __module_small_step_em_MOD_advance_uv 2.67% 32786 wrf_r_peak.std __module_small_step_em_MOD_advance_mu_t 2.63% 32334 wrf_r_peak.std__module_small_step_em_MOD_advance_w 2.52% 30796 wrf_r_peak.std__module_mp_wsm5_MOD_slope_wsm5 2.52% 30948 wrf_r_peak.std__module_advect_em_MOD_advect_scalar 2.34% 28718 libc-2.29.so __memset_avx2_unaligned_erms 2.32% 28336 wrf_r_peak.std__module_bl_ysu_MOD_ysu2d 2.18% 26624 wrf_r_peak.stdpsim_unstable 2.09% 25667 libmvec-2.29.so _ZGVbN4vv_powf_sse4 2.08% 25418 libmvec-2.29.so _ZGVbN4v_logf_sse4 1.87% 22858 wrf_r_peak.stdpsih_unstable 1.65% 20244 wrf_r_peak.std __module_big_step_utilities_em_MOD_phy_prep 1.56% 19006 wrf_r_peak.std__module_ra_rrtm_MOD_rtrn 1.40% 17198 wrf_r_peak.std__module_bc_MOD_set_physical_bc3d 1.25% 15339 wrf_r_peak.std __module_big_step_utilities_em_MOD_horizontal_diffusion 1.22% 15029 libc-2.29.so __memmove_avx_unaligned_erms 1.22% 14833 libm-2.29.so __expf_fma 1.15% 14101 wrf_r_peak.std __module_small_step_em_MOD_calc_p_rho 1.08% 13312 wrf_r_peak.std __module_big_step_utilities_em_MOD_horizontal_pressure_gradient 1.00% 12345 wrf_r_peak.std __module_big_step_utilities_em_MOD_rhs_ph PGO (slow): 325215.123075 task-clock:u (msec) #0.993 CPUs utilized 0 context-switches:u#0.000 K/sec 0 cpu-migrations:u #0.000 K/sec 302283 page-faults:u #0.929 K/sec 1026804177693 cycles:u #3.157 GHz (83.33%) 29812608056 stalled-cycles-frontend:u #2.90% frontend cycles idle (83.35%) 126544641902 stalled-cycles-backend:u # 12.32% backend cycles idle (83.34%) 1968104678527 instructions
[Bug libstdc++/90277] Debug Mode test failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90277 --- Comment #4 from Jonathan Wakely --- (In reply to François Dumont from comment #3) > As stated in my message this patch can be consider as a fix for this PR as > it reserve buckets for 11 buckets so iterators are not invalidated during > execution of the tests. You shouldn't have anymore failures, do you ? > > But maybe you would prefer to make those tests independent of this > implementation detail. I'll do that too. I think it's OK to rely on the detail as long as the tests make that explicit. A comment saying that they assume there's no rehashing would be OK, even better would be to use VERIFY to assert that the count doesn't change. If we make the tests actually verify there's no rehashing, then it's OK to assume no hashing :-) Currently it's just a silent assumption, which isn't even true any more.
[Bug gcov-profile/90364] 521.wrf_r is 9.5 % slower with PGO on Zen CPUs at -Ofast and native march/mtune
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90364 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-05-06 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- > > > Note that calls to libmvec are gone with PGO. However, they could > only be generated because the system I used had the necessary Fortran > include file, which IIUC the LNT worker did not have until last week > and yet the regression can be seen in earlier data too. I can confirm that. I'll take a look why the libvmec calls are not used with PGO.
[Bug libstdc++/90361] Undefined symbols in libstdc++ when building with --with-default-libstdcxx-abi=gcc4-compatible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90361 --- Comment #1 from Richard Biener --- I can link correctly with -D_GLIBCXX_USE_CXX11_ABI=0 have yet to check a build with the gcc4 ABI as default.
[Bug libstdc++/90361] [9/10 Regression] Undefined symbols in libstdc++ when building with --with-default-libstdcxx-abi=gcc4-compatible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90361 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-05-06 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |9.2 Summary|Undefined symbols in|[9/10 Regression] Undefined |libstdc++ when building |symbols in libstdc++ when |with|building with |--with-default-libstdcxx-ab |--with-default-libstdcxx-ab |i=gcc4-compatible |i=gcc4-compatible Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- I haven't checked a build with that option for ages, so I can easily believe I've broken it. I'll take a look tomorrow.
[Bug middle-end/63477] [6/7/8 Regression] Bogus warning with -O3 -Warray-bounds: array subscript is above array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63477
Alexandre Ganea changed:
What|Removed |Added
CC||alexandre.ganea at ubisoft dot
com
--- Comment #4 from Alexandre Ganea ---
Hi,
We get what seems like a spurious warning at the following location in LLVM:
https://github.com/llvm/llvm-project/blob/master/llvm/lib/Target/AMDGPU/R600ISelLowering.cpp#L1718
The warning is:
//warning: array subscript is above array bounds [-Warray-bounds]
//if (NewBldVec[i] == NewBldVec[j]) {
//~~~^
This only occurs when compiling with GCC 7.1+ and 9.1/trunk (not with 8), with
-O3 -Warray-bounds
This has been creduce'd to:
class a {
int b;
unsigned c;
public:
bool operator==(a) { return b && c; }
};
class d {
public:
void e();
};
class f {
a g(d &) const;
};
a f::g(d &h) const {
a j[1];
for (unsigned i;; i++)
for (; i;)
if (j[i] == j[0])
h.e();
}
Could you please confirm the issue?
Thank you!
[Bug fortran/90329] Incompatibility between gfortran and C lapack calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #15 from Thomas Koenig ---
Hi Tomas,
> I understand the compiler may not know and typically does not whether the
> called function accepts "character(len=1)" or "character(len=*)", so it may
> have to pass the 1. But the situation where I suggest not writing the 1 is
> more subtle (see my original post -
> https://gcc.gnu.org/ml/fortran/2019-05/msg00021.html).
I have given this some thought, and I don't think this can be done
in the general case, unfortunately.
Consider
program main
call foo("ab")
end
subroutine foo(c)
character*1 c
call bar(c)
end
subroutine bar(c)
character*(*) c
print *,len(c)
end
This is legal Fortran going back to F77, and it should print 1.
If your proposal was implemented, this would print 2, which would
be a wrong-code bug :-(
So, what can we do? Previously, the way of interfacing C
with Fortran was fragile, non-conforming, and worked. Now
it is fragile, non-conforming, and does not work.
In your (excellent, by the way) debugging work, you have
identified an option, -fno-optimize-sibling-calls, which
restores the status quo because things would go back to
being fragile, nonconforming, and they would work again.
Since we applied the fix for PR 87689 to gcc 7, gcc 8 and gcc 9,
I would suggest that we make -fno-optimize-sibling-calls
the default on these branches. Maintaining binary compatibility
(even if it is bug compatibility) with existing packages is
something we should strive for, especially with such
important software packages as BLAS and LAPACK. These packages
are one important reason why people still use Fortran, and
I would hate to push them towards flang with this.
For current trunk, I would recommend keeping the current
hehavior and contact the LAPACK maintainers to a) give them
a heads-up for this problem, and b) a year to work out
the problem.
Would this be something that people could agree on?
[Bug tree-optimization/90358] [10 Regression] 526.blender_r train run does not finish after r270847 on znver1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90358 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed.
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 90358, which changed state. Bug 90358 Summary: [10 Regression] 526.blender_r train run does not finish after r270847 on znver1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90358 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/90358] [10 Regression] 526.blender_r train run does not finish after r270847 on znver1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90358 --- Comment #6 from Richard Biener --- Author: rguenth Date: Mon May 6 13:40:00 2019 New Revision: 270911 URL: https://gcc.gnu.org/viewcvs?rev=270911&root=gcc&view=rev Log: 2019-05-06 Richard Biener PR tree-optimization/90358 * tree-vect-stmts.c (get_group_load_store_type): Properly detect unused upper half of load. (vectorizable_load): Likewise. * gcc.target/i386/pr90358.c: New testcase. Added: trunk/gcc/testsuite/gcc.target/i386/pr90358.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-stmts.c
[Bug c/90365] New: OpenMP default(none) + schedule(dynamic, variable) - difference with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90365
Bug ID: 90365
Summary: OpenMP default(none) + schedule(dynamic, variable) -
difference with clang
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: lebedev.ri at gmail dot com
Target Milestone: ---
void sink();
void test(int chunkSize) {
#pragma omp parallel for default(none) schedule(dynamic, chunkSize)
for(int i = 0; i < 10; i++)
sink();
}
clang takes this, gcc does not:
source>: In function 'void test(int)':
:4:5: error: 'chunkSize' not specified in enclosing 'parallel'
4 | for(int i = 0; i < 10; i++)
| ^~~
:3:9: error: enclosing 'parallel'
3 | #pragma omp parallel for default(none) schedule(dynamic, chunkSize)
| ^~~
Compiler returned: 1
Is the diagnostic correct here?
[Bug c/90365] OpenMP default(none) + schedule(dynamic, variable) - difference with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90365 --- Comment #1 from Roman Lebedev --- Forgot to add https://godbolt.org/z/CeVhEu
[Bug c/90365] OpenMP default(none) + schedule(dynamic, variable) - difference with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90365 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |INVALID --- Comment #2 from Jakub Jelinek --- clang is wrong. OpenMP 5 clarified this, on combined/composite constructs clauses which apply just to one of the constructs combined/composited together are considered as present on those constructs and expressions in those clauses are used inside of the construct (exception is target teams with 2 teams specific clauses). So, this testcase is to be handled as #pragma omp parallel default(none) #pragma omp for schedule(dynamic, chunkSize) for(int i = 0; i < 10; i++) sink(); and at least that one clang handles properly.
[Bug c++/90366] New: OpenMP default(none) - std::cerr is diagnosed as "not specified in enclosing 'parallel'", unlike clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90366
Bug ID: 90366
Summary: OpenMP default(none) - std::cerr is diagnosed as "not
specified in enclosing 'parallel'", unlike clang
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lebedev.ri at gmail dot com
Target Milestone: ---
#include
void test(int chunkSize) {
#pragma omp parallel default(none)
std::cerr << "hi";
}
clang accepts that code, gcc does not:
: In function 'void test(int)':
:4:18: error: 'cerr' not specified in enclosing 'parallel'
4 | std::cerr << "hi";
| ^~~~
:3:9: error: enclosing 'parallel'
3 | #pragma omp parallel default(none)
| ^~~
Compiler returned: 1
https://godbolt.org/z/hC0cbC
This diagnostic is correct?
[Bug sanitizer/90312] Address sanitizer cannot be used with -mabi=ms since r266073
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90312 --- Comment #7 from Martin Liška --- Author: marxin Date: Mon May 6 14:01:45 2019 New Revision: 270912 URL: https://gcc.gnu.org/viewcvs?rev=270912&root=gcc&view=rev Log: Backport r270899 2019-05-06 Martin Liska Backport from mainline 2019-05-06 Martin Liska PR sanitizer/90312 * config/i386/i386-options.c (ix86_option_override_internal): Error only when -mabi is selected to a non-default version. 2019-05-06 Martin Liska Backport from mainline 2019-05-06 Martin Liska PR sanitizer/90312 * gcc.dg/asan/pr87930.c: Run the test only on *linux or *gnu systems. * gcc.dg/tsan/pr88017.c: Likewise. Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/config/i386/i386.c branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/gcc/testsuite/gcc.dg/asan/pr87930.c branches/gcc-9-branch/gcc/testsuite/gcc.dg/tsan/pr88017.c
[Bug sanitizer/90312] Address sanitizer cannot be used with -mabi=ms since r266073
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90312 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||9.1.1 Resolution|--- |FIXED Known to fail|9.1.0 | --- Comment #8 from Martin Liška --- Fixed.
[Bug c/90365] OpenMP default(none) + schedule(dynamic, variable) - difference with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90365 Roman Lebedev changed: What|Removed |Added See Also||https://bugs.llvm.org/show_ ||bug.cgi?id=41767 --- Comment #3 from Roman Lebedev --- (In reply to Jakub Jelinek from comment #2) > clang is wrong. > OpenMP 5 clarified this, on combined/composite constructs clauses which > apply just to one of the constructs combined/composited together are > considered as present on those constructs and expressions in those clauses > are used inside of the construct (exception is target teams with 2 teams > specific clauses). Thank you for the reply! > So, this testcase is to be handled as > #pragma omp parallel default(none) > #pragma omp for schedule(dynamic, chunkSize) > for(int i = 0; i < 10; i++) sink(); > and at least that one clang handles properly.
[Bug tree-optimization/90316] [8/9 Regression] large compile time increase in opt / alias stmt walking for Go example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90316 --- Comment #10 from Than McIntosh --- Update: it looks like we are not out of the woods quite yet -- I am seeing some similar behavior farther into the build. I will try to produce another reduced test case (this one is proving more difficult replicate).
[Bug target/90330] gcc 9.1.0 fails to install on macOS 10.14.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330 --- Comment #12 from Matt Thompson --- (In reply to Iain Sandoe from comment #11) > (In reply to Matt Thompson from comment #10) > > (In reply to Iain Sandoe from comment #9) > > > (In reply to Matt Thompson from comment #8) > > > > I don't usually remove it from my path because it had never caused any > > issues before. Note that I specifically do not let brew install gcc (or > > MPI). I like that control. I'm currently running a "no /usr/local/bin" test > > so we shall see if it helps. > > OK - let's be clear here. You must install GCC into the path that its > configured with in order for the correct shared libraries to be found at > runtime. > > so, if yo configure --prefix=/foo/bar/baz and then intstall into > /baz/bar/foo that will not work correctly. > > The error you are showing seems that you are not finding the same libstdc++ > at runtime as was assumed to be available by the build. Oh. I only ever do "make install" if I get --prefix wrong, I rebuild the whole thing. > > > > If you can find the exact command line that fails and repeat it, prepended > > > by DYLD_PRINT_LIBRARIES=1, that will show you which dylibs are loaded as > > > the > > > command tries to execute (there might be quite a lot of output, so not > > > necessarily easy to interpret) > > > > I just tried this and nothing happens. I tried both "DYLD_PRINT_LIBRARIES=1 > > g++ ..." and "env DYLD_PRINT_LIBRARIES=1 g++ ..." No change in output. > > "which g++" probably says you are using clang++ and that it a protected exe > that will elide DYLD_* when invoked. In that case, it's hard to do that test. > > Yeah. > > > > > > I have built > > > > gcc 8.2.0. Instead of using clang, I could try that...though I'm not > > > > sure > > > > how. Just pass in CC and CXX to configure? > > > > > > yes, and/or make sure that the GCC toolchain bin dir is before the system > > > ones in your path. > > > > I'll try this as well as soon as I can (I can maybe manage make -j4 on this > > laptop, so builds aren't quick!). Do I need to pass FC as well? Or does the > > gcc build with fortran not care? > > Fortran is built with the C++ compiler, but I'd put the GCC bin dir in the > path first - and then you will be able to do the DYLD_** commands using the > bootstrap compiler tools to install. Well, 9.1.0 built just fine with 8.2.0 loaded in my environment. This seems to point to clang, which, well, doesn't surprise me as clang and I have had a difficult life together, but then again clang built 5.4.0 up to 8.2.0 just fine for me. I'm ran a 'make check' and got: Fixed: time.h Fixed: tinfo.h Fixed: types/vxTypesBase.h Fixed: unistd.h Newly fixed header: sys/ucred.h There were fixinclude test FAILURES make[2]: *** [Makefile:177: check] Error 1 make[2]: Leaving directory '/Users/mathomp4/src/GCC/gcc-9.1.0-BUILD-820loaded/fixincludes' make[1]: *** [Makefile:3829: check-fixincludes] Error 2 make[1]: Leaving directory '/Users/mathomp4/src/GCC/gcc-9.1.0-BUILD-820loaded' make: *** [Makefile:2358: do-check] Error 2 So...huh. Not sure what to do there. Still, fortune favors the bold/naive and I'll continue work with this 9.1.0 and try to build my MPI stack, etc. and see how it handles our model.
[Bug middle-end/63477] [6/7/8 Regression] Bogus warning with -O3 -Warray-bounds: array subscript is above array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63477 --- Comment #5 from Martin Sebor --- (In reply to Alexandre Ganea from comment #4) The test case has been reduced a little too far -- it reads an uninitialized variable: for (unsigned i;; i++) for (; i;) if (j[i] == j[0]) h.e(); But the false positive can also be reproduced by initializing the variable to zero. Can you please open a new bug with the corrected test case?
