[Bug tree-optimization/80281] [5/6 Regression] Wrong constant folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80281 --- Comment #18 from Dominik Vogt --- Fixed.
[Bug tree-optimization/80281] [5/6 Regression] Wrong constant folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80281 --- Comment #14 from Dominik Vogt --- Created attachment 41135 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41135&action=edit dumpfile
[Bug tree-optimization/80281] [5/6 Regression] Wrong constant folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80281 Dominik Vogt changed: What|Removed |Added CC||krebbel at gcc dot gnu.org, ||vogt at linux dot vnet.ibm.com --- Comment #13 from Dominik Vogt --- This commit breaks tree-ssa/pr40921.c on s390x (-m31 and -m64) and s390: .../build/gcc/xgcc -B.../build/gcc/ .../testsuite/gcc.dg/tree-ssa/pr40921.c -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -fdump-tree-optimized -ffast-math -S -m64 -o pr40921.s PASS: gcc.dg/tree-ssa/pr40921.c (test for excess errors) FAIL: gcc.dg/tree-ssa/pr40921.c scan-tree-dump-times optimized "_* = -y_" 0
[Bug target/79487] Invalid _Decimal32 comparison on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487 Dominik Vogt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #26 from Dominik Vogt --- Fixed.
[Bug tree-optimization/79981] Forwprop not working for __atomic_compare_exchange_n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79981 Dominik Vogt changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Dominik Vogt --- Looks good.
[Bug testsuite/79356] XPASS in attr-alloc_size-11.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79356 --- Comment #13 from Dominik Vogt --- Patch: https://gcc.gnu.org/ml/gcc-patches/2017-03/msg01468.html
[Bug testsuite/79356] XPASS in attr-alloc_size-11.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79356 --- Comment #12 from Dominik Vogt --- Still XPASSes on s390 (but not s390x with -m31 or -m64).
[Bug ada/79441] [7 regression] gnat.dg/pack9.adb fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79441 --- Comment #4 from Dominik Vogt --- Any chance of fixing that before gcc7?
[Bug target/80080] S390: Isses with emitted cs-instructions for __atomic builtins.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80080 --- Comment #8 from Dominik Vogt --- The patch has a performance regression on s390x. .L1 lr %r3,%r1 cs %r1,%r4,0(%r2) jne .L1 becomes .L1 cs %r1,%r3,0(%r2) ipm %r4 sra %r4,28 cijne %r4,0,.L1 Although this can be fixed on s390/s390x in a follow-up patch, I cannot really prove that something similar won't happen on other targets without testing them.
[Bug target/80080] S390: Isses with emitted cs-instructions for __atomic builtins.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80080 --- Comment #7 from Dominik Vogt --- (In reply to Jakub Jelinek from comment #6) > I think it depends on what > (success, old_reg) = compare-and-swap(mem, old_reg, new_reg) > sets if success is true. Is there a guarantee that old_reg will be assigned > whatever has been passed as the second argument in that case on all targets? Isn't that part of the interface of the atomic_compare_and_swap pattern? Gccinternals: > Operand 1 is an output operand which is set to the contents of the memory > before the operation was attempted. Operand 3 is the value that is > expected to be in memory. If the CS instruction on a target does not overwrite the register old_reg with the memory value before swapping, the target's backend must do that manually, I think.
[Bug target/80080] S390: Isses with emitted cs-instructions for __atomic builtins.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80080 --- Comment #5 from Dominik Vogt --- What case do you mean? The + if (oldval != old_reg) +emit_move_insn (old_reg, oldval); at the end should make sure that the oldval-rtx is either not changed by the call, or its value is copied into old_reg at runtime. In both cases, the value of old_reg should be the old value to be returned (as it was hopefully before the patch). Me and Stefan have spent quite some time to proof read this patch; do you see somethings we might have overlooked?
[Bug target/80080] S390: Isses with emitted cs-instructions for __atomic builtins.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80080 Dominik Vogt changed: What|Removed |Added CC||vogt at linux dot vnet.ibm.com --- Comment #3 from Dominik Vogt --- Most of this can be fixed in the backend, but all attempts to get rid of the additional load ("lr %r3,%31") in "bar" within the backend have failed. This is caused by overly complicated code being generated in expand_compare_and_swap_loop(). I'm currently testing the patch below which eliminates the superfluous variable cmp_reg (and the register allocated for it). Is there any chance to get something like this into Gcc7? The patch could possibly also help other targets. (Will post on gcc-patches when the tests are complete.) --- a/gcc/optabs.c +++ b/gcc/optabs.c @@ -5798,17 +5798,15 @@ find_cc_set (rtx x, const_rtx pat, void *data) static bool expand_compare_and_swap_loop (rtx mem, rtx old_reg, rtx new_reg, rtx seq) { - machine_mode mode = GET_MODE (mem); rtx_code_label *label; - rtx cmp_reg, success, oldval; + rtx success, oldval; /* The loop we want to generate looks like - cmp_reg = mem; + old_reg = mem; label: -old_reg = cmp_reg; seq; - (success, cmp_reg) = compare-and-swap(mem, old_reg, new_reg) + (success, old_reg) = compare-and-swap(mem, old_reg, new_reg) if (success) goto label; @@ -5816,23 +5814,21 @@ expand_compare_and_swap_loop (rtx mem, rtx old_reg, rtx new_reg, rtx seq) iterations use the value loaded by the compare-and-swap pattern. */ label = gen_label_rtx (); - cmp_reg = gen_reg_rtx (mode); - emit_move_insn (cmp_reg, mem); + emit_move_insn (old_reg, mem); emit_label (label); - emit_move_insn (old_reg, cmp_reg); if (seq) emit_insn (seq); success = NULL_RTX; - oldval = cmp_reg; + oldval = old_reg; if (!expand_atomic_compare_and_swap (&success, &oldval, mem, old_reg, new_reg, false, MEMMODEL_SYNC_SEQ_CST, MEMMODEL_RELAXED)) return false; - if (oldval != cmp_reg) -emit_move_insn (cmp_reg, oldval); + if (oldval != old_reg) +emit_move_insn (old_reg, oldval); /* Mark this jump predicted not taken. */ emit_cmp_and_jump_insns (success, const0_rtx, EQ, const0_rtx,
[Bug tree-optimization/79981] Forwprop not working for __atomic_compare_exchange_n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79981 --- Comment #10 from Dominik Vogt --- Thanks for the fix; I'll regression test it soon, just need some time.
[Bug tree-optimization/79981] Forwprop not working for __atomic_compare_exchange_n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79981 --- Comment #5 from Dominik Vogt --- The knowledge that the integer can only assume the values 0 and 1 seems to be hard coded. Is it possible to add value range information? With that, all conditions and arithmetics could be done with the integer, and the boolean value would only be useful if the return value is explicitly stored in memory or so. Doing calculations with the boolean type (QImode) is something we really need to avoid on s390x because it eventually results in widening the value to SImode with bit arithmetics and clobbering the condition code as a side effect.
[Bug tree-optimization/79981] Forwprop not working for __atomic_compare_exchange_n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79981 --- Comment #3 from Dominik Vogt --- (In reply to Richard Biener from comment #2) > of course needs to be conditional on oldlhs being bool and lhs being > integral. Like so? -- diff --git a/gcc/gimple-fold.c b/gcc/gimple-fold.c index 9fd45d1..e5e448e 100644 --- a/gcc/gimple-fold.c +++ b/gcc/gimple-fold.c @@ -3581,7 +3581,12 @@ fold_builtin_atomic_compare_exchange (gimple_stmt_iterator *gsi) } else gsi_insert_after (gsi, g, GSI_NEW_STMT); - g = gimple_build_assign (oldlhs, NOP_EXPR, gimple_assign_lhs (g)); + if (TREE_CODE (TREE_TYPE (oldlhs)) == BOOLEAN_TYPE + && INTEGRAL_TYPE_P (itype)) + g = gimple_build_assign (oldlhs, NE_EXPR, gimple_assign_lhs (g), +build_zero_cst (TREE_TYPE (gimple_assign_lhs (g; + else + g = gimple_build_assign (oldlhs, NOP_EXPR, gimple_assign_lhs (g)); gsi_insert_after (gsi, g, GSI_NEW_STMT); } g = gimple_build_assign (make_ssa_name (itype), REALPART_EXPR, -- Lhs has COMPLEX_TYPE, so itype needs to be checked instead, but is it really necessary? Itype comes from the function declaration and should be guaranteed to be of integral type anyway: tree fndecl = gimple_call_fndecl (stmt); tree parmt = TYPE_ARG_TYPES (TREE_TYPE (fndecl)); tree itype = TREE_VALUE (TREE_CHAIN (TREE_CHAIN (parmt))); This eliminates the _Bool and finally results in _8 = IMAGPART_EXPR <_7>; if (_8 != 0) (but not regression tested yet).
[Bug tree-optimization/79981] New: Forwprop not working for __atomic_compare_exchange_n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79981 Bug ID: 79981 Summary: Forwprop not working for __atomic_compare_exchange_n Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: vogt at linux dot vnet.ibm.com Target Milestone: --- Trying to figure out why this sample program results on not so good Rtl code on s390x: -- extern void locked (void *lock); extern void not_locked (void); void csi (int *lock) { int oldval = 0; if (__atomic_compare_exchange_n (lock, (void *) &oldval, 1, 1, 2, 0)) locked ((void *)lock); else not_locked (); } -- Before forwprop2: -- _Bool _1; __complex__ unsigned int _8; unsigned int _9; [100.00%]: _8 = ATOMIC_COMPARE_EXCHANGE (lock_4(D), 0, 1, 260, 2, 0); _9 = IMAGPART_EXPR <_8>; _1 = (_Bool) _9; if (_1 != 0) ... -- Although Gcc seems to know that the SImode value from the complex number can only have values 0 and 1, it fails to propagate _9 into the condition: "if (_9 != 0)". For similar code that calls a normal function, forwprop does exactly that: -- extern _Complex int func(int *lock, void *old, int new); extern void locked (void *lock); extern void not_locked (void); void foo(int *lock) { int oldval = 0; int i = __imag__ func(lock, (void *)&oldval, 1); _Bool b = (_Bool)i; if (b) locked ((void *)lock); else not_locked (); } -- We get (before forwprop1): -- complex int _1; [0.00%]: oldval = 0; _1 = func (lock_5(D), &oldval, 1); i_7 = IMAGPART_EXPR <_1>; b_8 = i_7 != 0; if (b_8 != 0) -- => -- ;; Function foo (foo, funcdef_no=0, decl_uid=2024, cgraph_uid=0, symbol_order=0) Applying pattern match.pd:932, gimple-match.c:164 Applying pattern match.pd:3002, gimple-match.c:61428 gimple_simplified to if (b_8 != 0) Applying pattern match.pd:932, generic-match.c:136 Applying pattern match.pd:3002, generic-match.c:31977 Replaced 'b_8 != 0' with 'i_7 != 0' ... _1 = func (lock_5(D), &oldval, 1); i_7 = IMAGPART_EXPR <_1>; if (i_7 != 0) ... -- What can be done to get rid of the _Bool stuff in the first program? (The Rtl code generated by the _Bool logic stays around too long, until Combine, and foils optimizations in the s390x pattern for compare-and-swap.)
[Bug target/79904] ICE in annotate_constant_pool_refs, at config/s390/s390.c:7909
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79904 --- Comment #3 from Dominik Vogt --- Not sure what that means: When UBSAN_CHECK_MUL is expanded, the generated Rtl wants the vector constant "3" in the litaral pool (insn 30): -- ;; _2 = UBSAN_CHECK_MUL (_1, { 11, 22, 33, 44, 0, 0, 0, 0 }); (insn 23 22 24 (set (reg:DI 69) (const_int 0 [0])) (code_label 24 23 25 4 (nil) [0 uses]) (insn 25 24 26 (set (mem/c:DI (plus:DI (reg/f:DI 55 virtual-stack-vars) (const_int -24 [0xffe8])) [0 S8 A64]) (reg:DI 60 [ _1 ])) (insn 26 25 27 (set (reg:QI 72) (mem/j:QI (plus:DI (plus:DI (reg/f:DI 55 virtual-stack-vars) (reg:DI 69)) (const_int -24 [0xffe8])) [0 S1 A8])) (insn 27 26 28 (set (reg:SI 71) (ashift:SI (subreg:SI (reg:QI 72) 0) (const_int 24 [0x18]))) "/home/vogt/z.c":5 -1 (insn 28 27 29 (parallel [ (set (reg:SI 71) (ashiftrt:SI (reg:SI 71) (const_int 24 [0x18]))) (clobber (reg:CC 33 %cc)) (insn 29 28 30 (set (reg:HI 70) (subreg:HI (reg:SI 71) 2)) (insn 30 29 31 (set (reg:QI 75) (mem/u/j:QI (plus:DI (reg:DI 69) (symbol_ref/u:DI ("*.LC1") [flags 0x2])) [0 S1 A8])) ^ ... -- Without Ubsan, each byte of the vector is expanded to separate code, loading the constant and the vector element and multiplying both, without involving the literal pool. Is that the fault of the backend (i.e. not supporting vector Gcc constants in the literal pool; or not telling Ubsan that vector constants are not supported) or the fault of the Ubsan code that generates a literal pool Gcc vector constant when it shouldn't?
[Bug target/79904] ICE in annotate_constant_pool_refs, at config/s390/s390.c:7909
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79904 --- Comment #2 from Dominik Vogt --- Reduced test: -- typedef signed char V __attribute__((vector_size (8))); void foo (V *a) { *a = *a * 3; } -- $ gcc -fsanitize=undefined ...
[Bug target/79893] ICE in s390_adjust_builtin_arglist in gcc/config/s390/s390-c.c:679
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79893 --- Comment #2 from Dominik Vogt --- A small test program that reproduces the crash: -- #include void foo(signed char *p, int i) { vec_load_bndry(p, i); } -- $ gcc -mzvector -mvx -march=z13 -S
[Bug target/79904] ICE in annotate_constant_pool_refs, at config/s390/s390.c:7909
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79904 --- Comment #1 from Dominik Vogt --- Confirmed.
[Bug target/79895] ICE in extract_constrain_insn, at recog.c:2213
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79895 --- Comment #1 from Dominik Vogt --- Confirmed.
[Bug target/79893] ICE in s390_adjust_builtin_arglist in gcc/config/s390/s390-c.c:679
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79893 --- Comment #1 from Dominik Vogt --- Confirmed.
[Bug target/79890] ICE in s390_initial_elimination_offset, at config/s390/s390.c:10430
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79890 --- Comment #5 from Dominik Vogt --- Reproduceable on a zEC12 with $ ./configure --enable-languages=c --disable-bootstrap --disable-multilib --enable-checking --with-system-zlib --enable-threads=posix --enable-__cxa_atexit --enable-gnu-indirect-function
[Bug target/79890] ICE in s390_initial_elimination_offset, at config/s390/s390.c:10430
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79890 --- Comment #3 from Dominik Vogt --- Not reproduceable here with r245913. Is it gone with a recent Gcc? Gcc configured with --with-arch=zEC12 and compiled without explicit options: $ ~/src/gcc/install-master/bin/gcc ~/src/gcc/gcc/testsuite/gcc.target/mips/call-saved-7.c -march=zEC12 -S (Complains about missing main function without "-S")
[Bug target/79890] ICE in s390_initial_elimination_offset, at config/s390/s390.c:10430
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79890 --- Comment #1 from Dominik Vogt --- The ICE needs to be fixed, of course, by what is the idea behind executing the mips testsuite on s390?
[Bug sanitizer/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 --- Comment #74 from Dominik Vogt --- With the pending patches/fixes, the *san testsuites are clean on s390x biarch and s390. :-)
[Bug testsuite/79356] XPASS in attr-alloc_size-11.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79356 --- Comment #7 from Dominik Vogt --- Patch with all reported targets in a negative list: https://gcc.gnu.org/ml/gcc-patches/2017-02/msg01006.html Can you please double check that the xfail selectors are correct for your targets?
[Bug sanitizer/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 --- Comment #72 from Dominik Vogt --- I wanted to refer to the funny pc value. The line information is actually correct.
[Bug sanitizer/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 --- Comment #70 from Dominik Vogt --- If funny line information is the only consequence, no. Is it safe to assume that libsanitizer won't crash or produce garbege because of this?
[Bug sanitizer/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 --- Comment #68 from Dominik Vogt --- Okay, that fixes the test failure, but the addresses further up in the backtrace are still bad, e.g. #0 0x10008d2 in NullDeref #1 0x1000759 in main #2 0x3fffce23069 in #3 0x10007d5 Maybe it's not worth it to knock a workaround together when a real fix is preferrable. It's probably acceptable to wait for an upstream fix.
[Bug sanitizer/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 --- Comment #66 from Dominik Vogt --- Compiled from scratch to make sure it's not a build dependency problem, but the tests still fail because of the odd backtrace addresses. Can I provide some information from single stepping in Gdb?
[Bug sanitizer/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 --- Comment #65 from Dominik Vogt --- That patch does not compile, and fixing the compiler error (context -> ctx) doesn't help either. > but I also can't reproduce the nullptr-1.c failure myself An example command line is $ .../gcc/build-fixes/gcc/xgcc -B.../build-fixes/gcc/ .../gcc/testsuite/c-c++-common/asan/null-deref-1.c -B.../build-fixes/s390x-ibm-linux-gnu/./libsanitizer/ -B.../build-fixes/s390x-ibm-linux-gnu/./libsanitizer/asan/ -L.../build-fixes/s390x-ibm-linux-gnu/./libsanitizer/asan/.libs -fsanitize=address -g -I.../gcc/testsuite/../../libsanitizer/include -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -fno-omit-frame-pointer -fno-shrink-wrap -lm -m64 -o ./null-deref-1.exe -march=zEC12
[Bug sanitizer/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 --- Comment #62 from Dominik Vogt --- (In reply to Jakub Jelinek from comment #61) > It is true that libasan calls just _Unwind_GetIP rather than > _Unwind_GetIPInfo, > but I don't see where there is that subtraction of 1, so it shouldn't matter; > it seems to record the address that return address that has been given by > the unwinder. _Unwind_GetIP returns the correct addresses: (gdb) disas 0x03fff728bb08 <+40>: brasl %r14,0x3fff71a6458 <_Unwind_GetIP@plt> 0x03fff728bb0e <+46>: larl%r10,0x3fff773e758 <_ZN11__sanitizer14PageSizeCachedE> (gdb) b *0x03fff728bb0e (gdb) display /x $r2 (gdb) c ... 1: /x $r2 = 0x100083a 1: /x $r2 = 0x10006c2 1: /x $r2 = 0x3fff6e2306a 1: /x $r2 = 0x100073e
[Bug sanitizer/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 --- Comment #57 from Dominik Vogt --- libsanitizer miscalculates the Pcs in the backtrace: #0 0x1000839 in NullDeref #1 0x10006c1 in main #2 0x3fff6e23069 in __libc_start_main #3 0x100073d These are all odd addresses, pointing to the last byte of the previous instruction. In case of null-deref-1.c that byte belongs to some instrumentation code that is associated with line 11.
[Bug sanitizer/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 --- Comment #56 from Dominik Vogt --- null-deref-1.c fails because the test expects this message in source line 10 but gets it for line 11: #0 0x1000853 in NullDeref .../c-c++-common/asan/null-deref-1.c:11
[Bug rtl-optimization/68749] FAIL: gcc.dg/ifcvt-4.c scan-rtl-dump ce1 "2 true changes made"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68749 --- Comment #14 from Dominik Vogt --- Thanks. Patch is here: https://gcc.gnu.org/ml/gcc-patches/2017-02/msg00975.html With that, the test is fine on s390 and s390x.
[Bug sanitizer/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 --- Comment #55 from Dominik Vogt --- (In reply to Dominik Vogt from comment #53) > no fails with -m31; with -m64 null-deref-1.c fails with c and > c++, and memcmp-1.c with c++ only. memcmp-1.c is not reproducible.
[Bug target/79526] New: loop-9.c fails on s390 + s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79526 Bug ID: 79526 Summary: loop-9.c fails on s390 + s390x Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: vogt at linux dot vnet.ibm.com Target Milestone: --- Some discussion on that issue is here. https://gcc.gnu.org/ml/gcc/2015-12/msg00064.html This should be fixed in the backend at some point in the future.
[Bug ada/79421] gnat.dg/trampoline3.adb fails on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79421 Dominik Vogt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Dominik Vogt --- Fixed.
[Bug rtl-optimization/68749] FAIL: gcc.dg/ifcvt-4.c scan-rtl-dump ce1 "2 true changes made"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68749 Dominik Vogt changed: What|Removed |Added CC||vogt at linux dot vnet.ibm.com --- Comment #12 from Dominik Vogt --- This also fails on s390x with -m31 and s390.
[Bug ada/79421] gnat.dg/trampoline3.adb fails on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79421 --- Comment #6 from Dominik Vogt --- (In reply to Dominik Vogt from comment #5) > Patch available here: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79421 Wrong link. Patch is here: https://gcc.gnu.org/ml/gcc-patches/2017-02/msg00692.html
[Bug target/79487] Invalid _Decimal32 comparison on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487 --- Comment #24 from Dominik Vogt --- No regressions on s390x biarch, and s390 on a zEC12 configured with -with-arch=zEC12. The "volatile"-patch to float-cast-overflow-8.c is no longer necessary. Thanks for the help!
[Bug target/79487] Invalid _Decimal32 comparison on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487 --- Comment #23 from Dominik Vogt --- Same result on s390x (on a zEC12 using -with-arch=zEC12): Without patch: * -O0 -> PASS * -O2 -> FAIL With patch: * -O0 -> PASS * -O2 -> PASS
[Bug target/79487] Invalid _Decimal32 comparison on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487 --- Comment #19 from Dominik Vogt --- It fixes the local test case extracted from float-cast-overflow-10.c. The patch probably should also add a test case; the one I have is very specific to s390x; would something like the code in comment 17 work? (Regression tests on s390 and s390x with the volatile removed from float-cast-overflow-8.c are running.)
[Bug target/79487] Invalid _Decimal32 comparison on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487 --- Comment #16 from Dominik Vogt --- > the REAL_CSTs already contain the right rounded values for their type Is there a way to see these values in the dumps?
[Bug target/79487] Invalid _Decimal32 comparison on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487 --- Comment #14 from Dominik Vogt --- To me, it looks like the same bug does not happen with float just because there is no need to convert this to 64 bit format for the comparison. simplify_const_unary_operation is not executed - if it was the same would have happened for the float to double conversion.
[Bug target/79487] Invalid _Decimal32 comparison on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487 --- Comment #13 from Dominik Vogt --- From the "optimize" dump: With float: if (tem.1_3 != -9.223372036854775808e+18) With _Decimal32: if (tem.1_3 != -9223372036854775808) This precision of the constant and the representation as floating point versus integer value continues to the pass before Cse1 (Dfinit): With float: (insn 5 2 11 2 (set (mem/v/c:SF (plus:DI (reg/f:DI 34 %fp) (const_int -4 [0xfffc])) [1 tem+0 S4 A32]) (const_double:SF -9.223372036854775808e+18 [-0x0.8p+64])) With _Decimal32: (insn 5 2 15 2 (set (mem/v/c:SD (plus:DI (reg/f:DI 34 %fp) (const_int -4 [0xfffc])) [1 tem+0 S4 A32]) (const_double:SD -9223372036854775808 [N/A]))
[Bug target/79487] Invalid _Decimal32 comparison on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487 --- Comment #11 from Dominik Vogt --- Well, then, what is the place where the constant should be truncated to what its mode can represent? Right at the start of the Tree dumps there seems to be a difference between float and _Decimal32. Float constants are printed in E-Notation while _Decimal32 constants are just printed as integers (with the above value, not verified with anything else).
[Bug target/79487] Invalid _Decimal32 comparison on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487 --- Comment #9 from Dominik Vogt --- (In reply to Jakub Jelinek from comment #8) > This isn't truncation, but extension (SDmode to DDmode). I presume all > SDmode values are representable in DDmode, so I don't see anything wrong on > that. But -9223372036854775808 *isn't* an SDmode constant - the mantissa is too short to represent the constant.
[Bug target/79487] Invalid _Decimal32 comparison on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487 --- Comment #7 from Dominik Vogt --- (In reply to Andreas Krebbel from comment #5) > Perhaps we have to do the real_convert unconditionally?! The real_convert to "mode" is not enough. Before converting to the target mode, the constant needs to be truncted to the source mode first.
[Bug target/79487] Invalid _Decimal32 comparison on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487 --- Comment #6 from Dominik Vogt --- This experimental patch fixes the problem: diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c index aa45973..2e67cff 100644 --- a/gcc/simplify-rtx.c +++ b/gcc/simplify-rtx.c @@ -1897,6 +1897,8 @@ simplify_const_unary_operation (enum rtx_code code, machine_mode mode, mode class. */ /* Don't perform the operation if flag_signaling_nans is on and the operand is a signaling NaN. */ + if (d.decimal) + real_convert (&d, GET_MODE (op), &d); if (GET_MODE_CLASS (mode) != GET_MODE_CLASS (GET_MODE (op)) && !(HONOR_SNANS (mode) && REAL_VALUE_ISSIGNALING_NAN (d))) real_convert (&d, mode, &d);
[Bug target/79487] Invalid _Decimal32 comparison on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487 --- Comment #4 from Dominik Vogt --- What happens in Cse1 is that the constant is propagated into the FLOAT_EXTEND expression, resulting in (float_expand:DD (const_double:SD -9223372036854775808)) which is eventually simplified using simplify_const_unary_operation. This has a case dealing with FLOAT_EXTEND: case FLOAT_EXTEND: /* All this does is change the mode, unless changing mode class. */ /* Don't perform the operation if flag_signaling_nans is on and the operand is a signaling NaN. */ if ((GET_MODE_CLASS (mode) != GET_MODE_CLASS (GET_MODE (op)) || d.decimal) && !(HONOR_SNANS (mode) && REAL_VALUE_ISSIGNALING_NAN (d))) real_convert (&d, mode, &d); break; This test fails, so the following code just strips the FLOAT_EXTEND:DD and replaces the mode in const_double with the target mode: (const_double:DD -9223372036854775808) which is wrong. Shouldn't this truncate the constant to the source mode first before converting it to the target mode?
[Bug ada/79403] Installation of Ada compiler gets permissions wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79403 Dominik Vogt changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #7 from Dominik Vogt --- Oops, sorry, closed the bug report when the fix is not committed yet.
[Bug sanitizer/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 --- Comment #53 from Dominik Vogt --- (In reply to Dominik Vogt from comment #51) > With r245382 plus the patch from comment 43, only the failure in > null-deref-1.c is left. Ah, not quite; no fails with -m31; with -m64 null-deref-1.c fails with c and c++, and memcmp-1.c with c++ only. Was any of this shupposed to be fixed? This thread has become a bit confusing.
[Bug libstdc++/79348] [7 Regression] abi_check fails on s390x (2 undesignated symbols)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79348 --- Comment #14 from Dominik Vogt --- Yep, fixed.(In reply to Jakub Jelinek from comment #13) > Should be fixed now. Yep, fixed.
[Bug target/69148] [5 Regression] ICE (floating point exception) on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69148 --- Comment #10 from Dominik Vogt --- (In reply to Matthias Klose from comment #8) > I prepared a patch for the distro builds. Any reason that this can't go to > the gcc-5-branch? Ping?
[Bug ada/79403] Installation of Ada compiler gets permissions wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79403 Dominik Vogt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Dominik Vogt --- Fixed.
[Bug c/79358] gcc.dg/c99-stdint-1.c fails with excess error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358 Dominik Vogt changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #13 from Dominik Vogt --- Fixed by upgrading to glibc-2.23.
[Bug ada/79403] Installation of Ada compiler gets permissions wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79403 --- Comment #5 from Dominik Vogt --- Fixed, thanks.
[Bug c/79487] Invalid _Decimal32 comparison on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487 --- Comment #2 from Dominik Vogt --- Ah, no, the first Rtl pass that produces an incorrect expression is Cse1. Before: -- (insn 22 21 23 3 (set (reg:SD 75) (const_double:SD -9223372036854775808 [N/A])) "decimal32.c":23 1121 {movsd} (insn 23 22 24 3 (set (reg:DD 74) (float_extend:DD (reg:SD 75))) "decimal32.c":23 1330 {extendsddd2} (insn 24 23 25 3 (set (reg:CCZ 33 %cc) (compare:CCZ (reg:DD 73) (reg:DD 74))) "decimal32.c":23 1081 {*cmpdd_ccs} -- The 32 bit constant is float_extended to 64 bits and the result is used in the comparison (remember that only a 64 bit comparison pattern is available anyway). Cse1 removes the extension and directly places the constant in the comparison, changing its mode: -- (insn 22 21 23 3 (set (reg:SD 75) (const_double:SD -9223372036854775808 [N/A])) "decimal32.c":23 1121 {movsd} (insn 23 22 24 3 (set (reg:DD 74) (const_double:DD -9223372036854775808 [N/A])) "decimal32.c":23 1115 {*movdd_64dfp} (insn 24 23 25 3 (set (reg:CCZ 33 %cc) (compare:CCZ (reg:DD 73) (const_double:DD -9223372036854775808 [N/A]))) "decimal32.c":23 1081 {*cmpdd_ccs} 64 bit mode -- And eventually Reload puts a 64 bit constant in the pool: -- (insn 86 21 24 3 (set (reg:DD 17 %f2 [81]) (mem/u/c:DD (symbol_ref/u:DI ("*.LC3") [flags 0x2]) [2 S8 A64])) "decimal32.c":23 1115 {*movdd_64dfp} (insn 24 86 25 3 (set (reg:CCZ 33 %cc) (compare:CCZ (reg:DD 16 %f0 [73]) (reg:DD 17 %f2 [81]))) "decimal32.c":23 1081 {*cmpdd_ccs} --
[Bug c/79487] Invalid _Decimal32 comparison on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487 --- Comment #1 from Dominik Vogt --- It seems that the pass ccp1 eliminates all information about the type of "min"? Before ccp1: _Decimal32 min; ... if (min_8 != tem.1_3) After ccp1: if (tem.1_3 != -9223372036854775808) (Or is there some hidden information about the type or perecision of the constant?)
[Bug sanitizer/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 Dominik Vogt changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=79487 --- Comment #52 from Dominik Vogt --- New bug report for the _Decimal32 problem: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487
[Bug c/79487] New: Invalid _Decimal32 comparison on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79487 Bug ID: 79487 Summary: Invalid _Decimal32 comparison on s390x Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: vogt at linux dot vnet.ibm.com CC: jakub at gcc dot gnu.org, krebbel at gcc dot gnu.org Target Milestone: --- Host: s390x Target: s390x This is a finding from an Asan test case failure reported here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 It may be a bug in the middle end or the backend. The failing program is -- extern _Decimal32 bar(_Decimal32 x); void foo(void) { int i; #if 0 /*!!!*/ volatile #endif _Decimal32 min = (-0x7fffL - 1L); volatile _Decimal32 tem = min; for (i = 0; i < 99; i++) { tem -= (_Decimal32)1.0; if (min != tem) { bar(tem); break; } } } -- When compiled with -O3 -march=zEC12, with the "volatile" disabled, the comparison "min != tem" is true right in the first pass of the loop, but bar() is called actually with the a value that is identical to "(_Decimal32)min". One cause of this is that although s390x supports 32-Bit decimal floating point in hardware, there are no instructions to do arithmetics or comparisons on such values. The 32 bit values need to be converted to 64 bit format for comparisons. Gcc pre-calculates the constant (7fffL - 1L) and puts it into the literal pool as 64 bit quantity. At the same time, "tem" is kept in memory as a 32 bit quantity, loaded to a register, extended to 64 bits and then compared to the value from the literal pool. Since the latter was not rounded, the comparison is always true. Making "min" volatile circumvents the problem. This is a (slightly shortened) diff of the assembly code with the "volatile" enabled (-, good) and disabled (+, bad): -- foo: ldgr%f4,%r15 larl%r5,.L8 lay %r15,-168(%r15) le %f0,.L9-.L8(%r5) - ste %f0,160(%r15) + ste %f0,164(%r15) iilf%r1,99 - l %r2,160(%r15) - st %r2,164(%r15) .L3: le %f0,164(%r15) ldetr %f0,%f0,0 <-- extend tem to 64 bits ld %f2,.L10-.L8(%r5) sdtr%f0,%f0,%f2 <-- subtract 1 from tem + ld %f2,.L11-.L8(%r5) <-- min: 64-bit from literal pool ledtr %f0,0,%f0,0 <-- round tem to 32 bits ste %f0,164(%r15) <-- store a copy to stack - le %f2,160(%r15) <-- min: 32-bit from stack le %f0,164(%r15) <-- load tem from stack (32 bits) - ldetr %f2,%f2,0 <-- min: extend to 64 bits ldetr %f0,%f0,0 <-- tem: extend to 64 bits - cdtr%f2,%f0 <-- compare min and tem (64 bits) + cdtr%f0,%f2 jne .L7 brct%r1,.L3 lgdr%r15,%f4 br %r14 .L7: le %f0,164(%r15) lgdr%r15,%f4 jg bar ... .L8: +.L11: + .long -297458820 <--- (-7fffL - 1L) as 64 bit value + .long -2090241034 <-/ .L10: .long 573833216 .long 16 .L9: .long -283865614 <--- (-7fffL - 1L) as 32 bit value -- Somewhere, Gcc is using 64 bit precision for _Decimal32 where it should not. Note that this does not happen on Power which has similar DFP instructions. Gcc does not store the constant with 64 bit precision in the literal pool there.
[Bug sanitizer/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 --- Comment #51 from Dominik Vogt --- With r245382 plus the patch from comment 43, only the failure in null-deref-1.c is left.
[Bug sanitizer/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 --- Comment #42 from Dominik Vogt --- With glibc-2.18 and the various patches, the following tets fail: -m31: * deep-stack-uaf-1.C -m64: * null-deref-1.c * deep-stack-uaf-1.C * overflow-vec-1.c * overflow-vec-2.c * float-cast-overflow-10.c I.e. the same as with glibc-2.23. At least this part of the problems is solved.
[Bug sanitizer/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 --- Comment #41 from Dominik Vogt --- > The first loop loops until add is -1.00E+12, at which point for the > first time tem is -9.223373E+18 and thus different from -9.223372E+18, and > -9.223373E+18 should not be representable in signed long. > Do you perhaps use HW dfp rather than software emulation? Well, just what the test driver used: ... -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects -fsanitize=float-cast-overflow -fsanitize-recover=float-cast-overflow -DUSE_INT128 -DUSE_DFP -DBROKEN_DECIMAL_INT128 -lm -m64 ... When the comparison is done in main, the values "min" and "tem" have 64-Bit precision. The actual comparison is if (tem.0_1 != -9223372036854775808) Which is true because that value doesn't fit in a _Decimal32. The if body is executed, and "tem" is converted to 32 bit format and stored in %f0. Gdb says that the converted value is exactly the same as the value of "min", and that seems to be the cause of the test failure. In assembly: ste %f2,160(%r15) < store "tem" on stack le %f2,160(%r15) < load "tem" from stack ldetr %f2,%f2,0 < convert "short" dfp value to "long" cdtr%f2,%f4 < compare with "min" je .L33 le %f0,160(%r15) < reload "tem" brasl %r14,cvt_sl_d32 This must look differently for you. Now, why does the test fail for me but not for you?
[Bug target/79131] [7 Regression] ICE: in extract_constrain_insn, at recog.c:2213, big-endian ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79131 --- Comment #13 from Dominik Vogt --- Same without vectors: long foo (long a, long b) { return a > b; } => cgr %r2,%r3 lghi%r1,1 locghinh%r1,0 lgr %r2,%r1 br %r14
[Bug sanitizer/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 --- Comment #38 from Dominik Vogt --- (And if it does generate messages, does it take the if or the else bodies? For me it's the if-bodies.)
[Bug sanitizer/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 --- Comment #36 from Dominik Vogt --- Created attachment 40711 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40711&action=edit Reduced test for float-cast-overflow-10.c Test for the float-cast-overflow-10.c failure. This snippet should detect that _Decimal32 doesn't fit in a signed 64-bit integer (either signed long or signed long long). Test uses "-m64 -O2 -fsanitize=float-cast-overflow -fsanitize-recover=float-cast-overflow". If you compile and execute this preprocessed file, does ubsan generate messages or not?
[Bug sanitizer/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 --- Comment #34 from Dominik Vogt --- (In reply to Jakub Jelinek from comment #33) > (In reply to Dominik Vogt from comment #32) > > On a machine with > > * glibc-2.23 > > :(; I was hoping you could test #c24 patch against glibc 2.18 I'll eventually do that, but the colleagues wanted to be nice and replaced 2.18 on the machine with 2.23, so I have to look for an alternative first. > I can't reproduce float-cast-overflow-10.c. I'll try your patch and take a look at float-cast-overflow-10.c.
[Bug sanitizer/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 --- Comment #32 from Dominik Vogt --- On a machine with * glibc-2.23 * kernel 4.4.0 + patch for the CVE * CVE environment variable set to allow running the Asan tests * patch from comment 24 applied => In addition to the FAILs you've listed here: https://gcc.gnu.org/ml/gcc-patches/2017-01/msg01814.html (same test failing with different options listed only once) Running target unix/-m31 FAIL: c-c++-common/asan/memcmp-1.c -O0 output pattern test, is = FAIL: c-c++-common/asan/misalign-1.c -O2 output pattern test, is = FAIL: c-c++-common/asan/misalign-2.c -O2 output pattern test, is = FAIL: c-c++-common/asan/strlen-overflow-1.c -O0 output pattern test, is = FAIL: c-c++-common/asan/strncpy-overflow-1.c -O0 output pattern test, is = ... Running target unix/-m64 FAIL: c-c++-common/asan/null-deref-1.c -O2 output pattern test, is ASAN:DEADLYSIGNAL ... FAIL: c-c++-common/ubsan/float-cast-overflow-10.c -O2 output pattern test, is c-c++-common/ubsan/float-cast-overflow-7.h:147:1: runtime error: value is outside the range of representable values of \ type 'signed char' ... === g++ tests === Running target unix/-m31 FAIL: c-c++-common/asan/memcmp-1.c -O0 output pattern test, is = FAIL: c-c++-common/asan/misalign-1.c -O2 output pattern test, is = FAIL: c-c++-common/asan/misalign-2.c -O2 output pattern test, is = FAIL: c-c++-common/asan/strlen-overflow-1.c -O0 output pattern test, is = FAIL: g++.dg/asan/deep-tail-call-1.C -O0 output pattern test, is = ... Running target unix/-m64 FAIL: c-c++-common/ubsan/float-cast-overflow-10.c -O2 output pattern test, is c-c++-common/ubsan/float-cast-overflow-7.h:147:1: runtime error: value is outside the range of representable values of \ type 'signed char' -- So, actually two more problems? 1) *san is not disabled with -m31 as it should(?) 2) ubsan/float-cast-overflow-10.c
[Bug go/79443] libgo/math test fails on s390x (undefined symbols cosh, sinh, tanh, hasVX)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79443 --- Comment #4 from Dominik Vogt --- No more than that, and the fix works. (Except for the issue with cplx2.go that has been there from the start https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60181).
[Bug ada/79421] gnat.dg/trampoline3.adb fails on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79421 --- Comment #5 from Dominik Vogt --- Patch available here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79421 The bug can be closed when the patch is applied.
[Bug ada/79421] gnat.dg/trampoline3.adb fails on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79421 --- Comment #4 from Dominik Vogt --- Okay, that change fixes it without regressions. I'll post a patch.
[Bug go/79443] libgo/math test fails on s390x (undefined symbols cosh, sinh, tanh, hasVX)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79443 --- Comment #2 from Dominik Vogt --- Yes, that fixes it. Now there's another one in crypto/sha256. Do you want me to open another bug report for that? -- fallback_test.go:19:5: error: reference to undefined name 'useAsm' if useAsm == false { ^ fallback_test.go:22:2: error: reference to undefined name 'useAsm' useAsm = false ^ fallback_test.go:23:17: error: reference to undefined name 'useAsm' defer func() { useAsm = true }() ^ FAIL: crypto/sha256 --
[Bug go/79443] New: libgo/math test fails on s390x (undefined symbols cosh, sinh, tanh, hasVX)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79443 Bug ID: 79443 Summary: libgo/math test fails on s390x (undefined symbols cosh, sinh, tanh, hasVX) Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: vogt at linux dot vnet.ibm.com CC: cmang at google dot com, krebbel at gcc dot gnu.org Target Milestone: --- Host: s390x Target: s390x Currently (r245298) there are some libgo/math test failures on s390x: -- var CoshNoVec = cosh ^ export_s390x_test.go:12:17: error: reference to undefined name 'sinh' var SinhNoVec = sinh ^ export_s390x_test.go:13:17: error: reference to undefined name 'tanh' var TanhNoVec = tanh ^ export_s390x_test.go:14:13: error: reference to undefined name 'hasVX' var HasVX = hasVX ^ --
[Bug ada/79421] gnat.dg/trampoline3.adb fails on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79421 --- Comment #2 from Dominik Vogt --- And on a target not using function descriptors otherwise, #define TARGET_CUSTOM_FUNCTION_DESCRIPTORS 1 affects only Ada?
[Bug ada/79403] Installation of Ada compiler gets permissions wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79403 --- Comment #3 from Dominik Vogt --- The files are symlinks in the build tree, mode 640 in the source tree (like everything else) and are installed with "cp -p" which explains the broken permissions. Most other things are installed "install -m 644". > I'm a little skeptical, nothing has changed for years and this apparently > works for everyone else. Perhaps because few people install a system Ada compiler from sources.
[Bug ada/79441] New: gnat.dg/pack9.adb fails since r 236279
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79441 Bug ID: 79441 Summary: gnat.dg/pack9.adb fails since r 236279 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: vogt at linux dot vnet.ibm.com CC: ebotcazou at gcc dot gnu.org, krebbel at gcc dot gnu.org Target Milestone: --- Host: s390x Target: s390x On s390x, the test gnat.dg/pack9.adb fails on s390x (--with-arch=zEC12) since this commit: -- Author: ebotcazou AuthorDate: Mon May 16 11:08:53 2016 + Commit: ebotcazou CommitDate: Mon May 16 11:08:53 2016 + * doc/gnat_rm/implementation_defined_attributes.rst (Scalar_Storage_Order): Adjust restriction for packed array types. * einfo.ads (Is_Bit_Packed_Array): Adjust description. (Is_Packed): Likewise. (Is_Packed_Array_Impl_Type): Likewise. (Packed_Array_Impl_Type): Likewise. * exp_ch4.adb (Expand_N_Indexed_Component): Do not do anything special if the prefix is not a packed array implemented specially. * exp_ch6.adb (Expand_Actuals): Expand indexed components only for bit-packed array types. * exp_pakd.adb (Install_PAT): Set Is_Packed_Array_Impl_Type flag on the PAT before analyzing its declaration. (Create_Packed_Array_Impl_Type): Remove redundant statements. * freeze.adb (Check_Component_Storage_Order): Reject packed array components only if they are bit packed. (Freeze_Array_Type): Fix logic detecting bit packing and do not bit pack for composite types whose size is multiple of a byte. Create the implementation type for packed array types only when it is needed, i.e. bit packing or packing because of holes in index types. Make sure the Has_Non_Standard_Rep and Is_Packed flags agree. * gcc-interface/gigi.h (make_packable_type): Add MAX_ALIGN parameter. * gcc-interface/decl.c (gnat_to_gnu_entity) : Call maybe_pad_type instead of building the padding type manually. (gnat_to_gnu_entity) : Do not assert that Packed_Array_Impl_Type is present for packed arrays. (gnat_to_gnu_component_type): Also handle known alignment for packed types by passing it to make_packable_type. * gcc-interface/utils.c (make_packable_type): Add MAX_ALIGN parameter and deal with it in the array case. Adjust recursive call. Simplify computation of new size and cap the alignment to BIGGEST_ALIGNMENT. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@236279 138bc75d-0d04-0410-96 -- with FAIL: gnat.dg/pack9.adb scan-tree-dump-not optimized "gnat_rcheck" (The string "gnat_rcheck" appear in the .s file.) The test was build with $ ~/build/gcc/gnatmake --GCC=~/build/gcc/xgcc --GNATBIND=~/build/gcc/gnatbind --GNATLINK=~/build/gcc/gnatlink -cargs -B~/build/gcc -largs --GCC=~/build/gcc/xgcc -B~/build/gcc -m64 -margs --RTS=~/build/s390x-ibm-linux-gnu/./libada -q -f ~/gcc/gcc/testsuite/gnat.dg/pack9.adb -fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -gnatp -fdump-tree-optimized -c -u -S -m64 -o pack9.s
[Bug testsuite/79427] g++.dg/tls/thread_local-order2.C fails starting with r245249
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79427 --- Comment #4 from Dominik Vogt --- See here for discussion of this bug report: https://gcc.gnu.org/ml/gcc-patches/2017-02/msg00666.html And here for discussion of the patch: https://gcc.gnu.org/ml/gcc-patches/2017-02/msg00446.html
[Bug testsuite/79427] g++.dg/tls/thread_local-order2.C fails starting with r245249
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79427 --- Comment #3 from Dominik Vogt --- The xfail was removed from the test because it caused an XPASS on many systems.
[Bug sanitizer/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 --- Comment #29 from Dominik Vogt --- $ uname -s -r Linux 4.2.0-20151029.0.65fcf15.5a12af1.fc20.s390xperformance I'm quite sure we had a working kernel on that machine at some time because I believe to remember that I'd been the first one who was bitten by that kernel bug. Anyway, the machine is very busy at the moment, so the upgrade has to wait for a couple of days.
[Bug sanitizer/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 --- Comment #26 from Dominik Vogt --- (We cannot upgrade the kernel before end of this or beginning of next week.)
[Bug sanitizer/79341] Many Asan tests fail on s390
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341 --- Comment #25 from Dominik Vogt --- Looks better, but now we get this quite often: -- ==23722==ERROR: Your kernel seems to be vulnerable to CVE-2016-2143. Using ASa\ n, MSan, TSan, DFSan or LSan with such kernel can and will crash your machine, or worse. -- I'll try to figure out what kernel version we need.
[Bug ada/79403] Installation of Ada compiler gets permissions wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79403 --- Comment #1 from Dominik Vogt --- (Happens with gcc-6.3; 7.0 was *not* tested.)
[Bug ada/79421] New: gnat.dg/trampoline3.adb fails on s390x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79421 Bug ID: 79421 Summary: gnat.dg/trampoline3.adb fails on s390x Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: vogt at linux dot vnet.ibm.com CC: krebbel at gcc dot gnu.org Target Milestone: --- Host: s390x Target: s390x The test case trampoline3.adb fails on s390x configured with --march=zEC12, using either -m31 or -m64, since at least r233572. Attempts to bisect this FAIL were unsuccessful because many commits before that the Ada compiler cannot be built fue to a compile error. FAIL: gnat.dg/trampoline3.adb scan-assembler-not GNU-stack.*x $ grep "GNU-stack.*x" trampoline3.s .section.note.GNU-stack,"x",@progbits What is the purpose of the test case, what does a failure mean and what can be done to determine its cause?
[Bug ada/79403] New: Installation of Ada compiler gets permissions wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79403 Bug ID: 79403 Summary: Installation of Ada compiler gets permissions wrong Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: vogt at linux dot vnet.ibm.com Target Milestone: --- Host: s390x Target: s390x "make install" of the Ada compiler installs the contests of the adainclude and adalib directories with incorrect permissions. The installed compiler is only usable by the user who installed it: $ su - root $ cd gcc/build # configure and build the compiler using e.g. --prefix=/usr/local $ umask 022 $ make install $ cd /usr/local/lib/gcc/s390x-ibm-linux-gnu/6.3.0 $ ls -l adainclude | head -10 total 15088 -r--r- 1 root root 2830 Feb 3 13:56 a-assert.adb -r--r- 1 root root 3742 Feb 3 13:56 a-assert.ads -r--r- 1 root root 3126 Feb 3 13:56 a-astaco.adb -r--r- 1 root root 2111 Feb 3 13:56 a-astaco.ads -r--r- 1 root root 21464 Feb 3 13:56 a-btgbso.adb -r--r- 1 root root 5460 Feb 3 13:56 a-btgbso.ads -r--r- 1 root root 4345 Feb 3 13:56 a-calari.adb -r--r- 1 root root 3420 Feb 3 13:56 a-calari.ads -r--r- 1 root root 5341 Feb 3 13:56 a-calcon.adb $ ls -l adalib | head -10 total 43416 -r--r- 1 root root 1702 Feb 3 14:31 a-assert.ali -r--r- 1 root root14582 Feb 3 14:31 a-btgbso.ali -r--r- 1 root root 2587 Feb 3 14:31 a-calari.ali -r--r- 1 root root 4169 Feb 3 14:31 a-calcon.ali -r--r- 1 root root 3224 Feb 3 14:31 a-caldel.ali -r--r- 1 root root19503 Feb 3 14:31 a-calend.ali -r--r- 1 root root14967 Feb 3 14:31 a-calfor.ali -r--r- 1 root root 1985 Feb 3 14:31 a-catizo.ali -r--r- 1 root root38194 Feb 3 14:31 a-cbdlli.ali For some reason, world read access is removed by the installation routines.
[Bug tree-optimization/71144] [6/7 Regression] isl_aff.c:1001: position out of bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71144 --- Comment #7 from Dominik Vogt --- The ICE (s390x) has gone away with this commit: 2017-01-31 Richard Biener PR tree-optimization/77318 * graphite-sese-to-poly.c (extract_affine): Fix assert. (create_pw_aff_from_tree): Take loop parameter. (add_condition_to_pbb): Pass loop of the condition to create_pw_aff_from_tree. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@245064 138bc75d-0d04-0410-96
[Bug tree-optimization/71144] [6/7 Regression] isl_aff.c:1001: position out of bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71144 --- Comment #6 from Dominik Vogt --- This no longer happens with current trunk. The warnings are still present, but the ICE is gone: (In reply to Dominik Vogt from comment #1) > I get (pprobably) the same ICE on s390x with today's devel branch in > pr68279.f90. Reduced test case (which intentionally has some out of bound > array accesses): > > MODULE foo > CONTAINS > SUBROUTINE bar(o) > INTEGER, DIMENSION(2, 1) :: a > INTEGER, DIMENSION(1) :: b > INTEGER, DIMENSION(1, 1) :: o > INTEGER :: d > DO i=1,2 > b(1:2) = b(1:2) > o(1:1, 1:d) = a(1:1, 1:d) > a(1:2, 2) = b(1:2) > d = d + 1 > END DO > END SUBROUTINE bar > END MODULE > internal compiler error: Aborted > 0x806bd397 crash_signal > /home/vogt/src/t/gcc/toplev.c:335 > 0x80b3b683 extract_affine_chrec > /home/vogt/src/t/gcc/graphite-sese-to-poly.c:239 > 0x80b3b683 extract_affine > /home/vogt/src/t/gcc/graphite-sese-to-poly.c:381 > 0x80b3b8b7 extract_affine > /home/vogt/src/t/gcc/graphite-sese-to-poly.c:421 > 0x80b3c52d add_condition_to_pbb > /home/vogt/src/t/gcc/graphite-sese-to-poly.c:458 > 0x80b3c52d add_conditions_to_domain > /home/vogt/src/t/gcc/graphite-sese-to-poly.c:525 > 0x80b3c52d build_iteration_domains > /home/vogt/src/t/gcc/graphite-sese-to-poly.c:1017 > 0x80b3c2dd build_iteration_domains > /home/vogt/src/t/gcc/graphite-sese-to-poly.c:1040 > 0x80b3c95f build_poly_scop(scop*) > /home/vogt/src/t/gcc/graphite-sese-to-poly.c:1364 > 0x80b296c9 graphite_transform_loops() > /home/vogt/src/t/gcc/graphite.c:319 > 0x80b29c4f graphite_transforms > /home/vogt/src/t/gcc/graphite.c:356 > 0x80b29c4f execute > /home/vogt/src/t/gcc/graphite.c:433
[Bug libstdc++/79348] [7 Regression] abi_check fails on s390x (2 undesignated symbols)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79348 --- Comment #10 from Dominik Vogt --- Created attachment 40679 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40679&action=edit test outpu Full test output attached.
[Bug tree-optimization/78348] [7 REGRESSION] 15% performance drop for coremark-pro/nnet-test after r242038
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78348 --- Comment #16 from Dominik Vogt --- Patch: https://gcc.gnu.org/ml/gcc-patches/2017-02/msg00424.html
[Bug tree-optimization/78348] [7 REGRESSION] 15% performance drop for coremark-pro/nnet-test after r242038
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78348 --- Comment #15 from Dominik Vogt --- Yep. I'll post a patch.
[Bug tree-optimization/78348] [7 REGRESSION] 15% performance drop for coremark-pro/nnet-test after r242038
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78348 --- Comment #13 from Dominik Vogt --- It still fails with /* { dg-options "-O3 -fdump-tree-ldist-details --param max-unroll-times=8" } */
[Bug libstdc++/79348] [7 Regression] abi_check fails on s390x (2 undesignated symbols)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79348 --- Comment #8 from Dominik Vogt --- All right, but what is the cause of that? The commit that git-bisect found seems to be completely unrelated(?) Examples: -- 4 _ZGTtNSt11range_errorC2EPKc transaction clone for std::range_error::range_error(char const*) version status: incompatible GLIBCXX_3.4.22 type: function status: added 5 _ZGTtNSt12out_of_rangeD0Ev transaction clone for std::out_of_range::~out_of_range() version status: incompatible GLIBCXX_3.4.22 type: function status: added --
[Bug rtl-optimization/78634] [7 Regression] 30% performance drop after r242832.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78634 --- Comment #6 from Dominik Vogt --- It fails with -march=zEC12 but not with -march=z900. It seems to be a tuning issue of the branch cost in the backend; a colleague is working on that and will mave a patch at some time in the future. So, I think you can ignore this, it's something to be dealt with in the backend.
[Bug c/79358] gcc.dg/c99-stdint-1.c fails with excess error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358 --- Comment #8 from Dominik Vogt --- Gdb says: (gdb) ptype __typeof__(size_t) type = unsigned long (gdb) ptype __typeof__(SIZE_MAX) type = unsigned int Two different types for unsigned 32 bit integers.
[Bug c/79358] gcc.dg/c99-stdint-1.c fails with excess error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358 --- Comment #7 from Dominik Vogt --- Or even -- #include #include #define FOO(TYPE, EXPR) __typeof__(EXPR) a; __typeof__((TYPE)0 + 0) *b = &a; void foo (void) { FOO(__SIZE_TYPE__, (SIZE_MAX)); } -- So __typeof__(SIZE_MAX) is different from __typeof__(__SIZE_TYPE__) when using -m31.
[Bug c/79358] gcc.dg/c99-stdint-1.c fails with excess error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358 --- Comment #6 from Dominik Vogt --- (In reply to Andreas Krebbel from comment #2) > The reduced testcase fails with -m31 and -m64 but the original probably only > with -m31 - right?! Sorry, you're right. I was doing too many things in parallel. Another attempt at reduction: -- #include #include #define CHECK_UNSIGNED(TYPE) \ do { TYPE a; int b[(TYPE)-1 < 0 ? -1 : 1]; } while (0) #define CHECK_EXPR_TYPE(TYPE, EXPR) \ do { __typeof__(EXPR) a; __typeof__((TYPE)0 + 0) *b = &a; } while (0) #define UNSIGNED_MAX_COND(TYPE, EXPR) \ ((EXPR) == (TYPE)-1) #define CHECK_UNSIGNED_LIMITS_2(TYPE, MAX, MAXBD) \ CHECK_UNSIGNED(TYPE); \ CHECK_EXPR_TYPE(TYPE, (MAX)); \ do { int a[(UNSIGNED_MAX_COND(TYPE, (MAX))\ && (MAX) >= (MAXBD)) ? 1 : -1]; } while (0) void test_misc_limits (void) { CHECK_UNSIGNED_LIMITS_2(__SIZE_TYPE__, SIZE_MAX, 65535U); } --
[Bug middle-end/78468] [7 regression] libgomp.c/reduction-10.c and many more FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468 --- Comment #35 from Dominik Vogt --- (In reply to Eric Botcazou from comment #34) > > I still disagree with reverting the patch. There was plenty of time to > > identify and fix affected backends instead of doing nothing for half five > > months and then claiming that the patch is potentially too disruptive at > > this point in the release cycle. > > That was your job though and apparently you didn't do it. Don't be silly. I've fixed all regresseions that have shown up, except the one on Sparc because you refused to accept changes to the Sparc backend. It's all documented in this discussion thread, so please stop inventing excuses to put the blame on others.
[Bug c/79358] gcc.dg/c99-stdint-1.c fails with excess error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358 --- Comment #4 from Dominik Vogt --- I.e. this is a Glibc related problem? The test machine has Glibc-2.18.