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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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.

[vogt at linux dot vnet.ibm.com]

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.

[vogt at linux dot vnet.ibm.com]

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.

[vogt at linux dot vnet.ibm.com]

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.

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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"

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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"

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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 (, GET_MODE (op), );
  if (GET_MODE_CLASS (mode) != GET_MODE_CLASS (GET_MODE (op))
  && !(HONOR_SNANS (mode) && REAL_VALUE_ISSIGNALING_NAN (d)))
real_convert (, mode, );

[Bug target/79487] Invalid _Decimal32 comparison on s390x

[vogt at linux dot vnet.ibm.com]

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 (, mode, ); 
  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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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)

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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)

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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)

[vogt at linux dot vnet.ibm.com]

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)

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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 <ebotcazou@138bc75d-0d04-0410-961f-82ee72b054a4>
AuthorDate: Mon May 16 11:08:53 2016 +
Commit: ebotcazou <ebotcazou@138bc75d-0d04-0410-961f-82ee72b054a4>
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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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)

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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)

[vogt at linux dot vnet.ibm.com]

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.

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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 from __typeof__(__SIZE_TYPE__) when using
-m31.

[Bug c/79358] gcc.dg/c99-stdint-1.c fails with excess error

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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

[vogt at linux dot vnet.ibm.com]

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.