[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=edit dumpfile

[Bug tree-optimization/80281] [5/6 Regression] Wrong constant folding

, ||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

[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|---

[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|---

[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

[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

[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

[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

[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

[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

[Bug tree-optimization/79981] New: Forwprop not working for __atomic_compare_exchange_n

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

[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 });

[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

[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

[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

[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 $

[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

[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

[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

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|---

[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

[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

[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

[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

[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

[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

[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

[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 @@

[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

[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

[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

[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|---

[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|---

[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}

[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

[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

[Bug c/79487] New: Invalid _Decimal32 comparison on s390x

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

[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 *

[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

[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

[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=edit Reduced test for float-cast-overflow-10.c Test for the float-cast-overflow-10.c failure. This snippet should detect

[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

[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

[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

[Bug go/79443] New: libgo/math test fails on s390x (undefined symbols cosh, sinh, tanh, hasVX)

: 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

[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

[Bug ada/79441] New: gnat.dg/pack9.adb fails since r 236279

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

[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

[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

[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

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

[Bug ada/79403] New: Installation of Ada compiler gets permissions wrong

: 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

[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.

[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

[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=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

[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

[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 = void foo (void) { FOO(__SIZE_TYPE__, (SIZE_MAX)); } -- So __typeof__(SIZE_MAX) is different

[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

[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 > >

[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.

  1   2   3   4   5   >