[Bug d/91628] libdruntime uses glibc internal symbol on s390

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628

Andreas Krebbel  changed:

   What|Removed |Added

 CC||krebbel at gcc dot gnu.org
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #20 from Andreas Krebbel  ---
Fixed per previous comment.

[Bug rtl-optimization/94613] combine: Wrong code due to splitting a simplified IF_THEN_ELSE

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613

Andreas Krebbel  changed:

   What|Removed |Added

   Keywords||wrong-code
   Priority|P3  |P1

[Bug rtl-optimization/94613] New: combine: Wrong code due to splitting a simplified IF_THEN_ELSE

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613

Bug ID: 94613
   Summary: combine: Wrong code due to splitting a simplified
IF_THEN_ELSE
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org
  Target Milestone: ---

Created attachment 48284
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48284&action=edit
autoreduced testcase

When compiling the attached testcase for IBM Z GCC optimizes an OR operation
away during combine leading to wrong code being generated:

cc1plus -O3 -march=z14 t.ii -quiet -o t.s

try_combine is invoked for the following 3 insns:

i1: 28: r111 = r110 | r158
i2: 31: r115 = r111 - r94
i3: 36: r122 = (r110 == 0 ? r115 : r177)

i3 becomes the following after inserting i1 and i2

36: r122 = (r110 == 0 ? r110 | r158 - r94 : r177)

simplification omits ORing r110 since it is 0 anyway:

36: r122 = (r110 == 0 ? r158 - r94 : r177)

after not being able to recognize the insn it gets split into parts again:

28: deleted
31: r115 = r158 - r94
36: r122 = (r110 == 0 ? r115 : r177)

[Bug rtl-optimization/94613] combine: Wrong code due to splitting a simplified IF_THEN_ELSE

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613

Andreas Krebbel  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug rtl-optimization/94613] combine: Wrong code due to splitting a simplified IF_THEN_ELSE

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613

--- Comment #1 from Andreas Krebbel  ---
If we have to assume that we already applied simplifications on the THEN or
ELSE branches it doesn't appear to be correct to look for split points inside
an IF_THEN_ELSE expression anymore.

This patch fixes the testcase for me:

index cff76cd3303..8f90a354977 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -5387,8 +5387,12 @@ find_split_point (rtx *loc, rtx_insn *insn, bool
set_src)
   /* Otherwise, select our actions depending on our rtx class.  */
   switch (GET_RTX_CLASS (code))
 {
-case RTX_BITFIELD_OPS: /* This is ZERO_EXTRACT and
SIGN_EXTRACT.  */
 case RTX_TERNARY:
+  /* Don't split inside then/else branches of an IF_THEN_ELSE.
+Simplification might have changed the expressions based on
+the condition.  */
+  return 0;
+case RTX_BITFIELD_OPS: /* This is ZERO_EXTRACT and
SIGN_EXTRACT.  */
   split = find_split_point (&XEXP (x, 2), insn, false);
   if (split)
return split;

[Bug rtl-optimization/94613] combine: Wrong code due to splitting a simplified IF_THEN_ELSE

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613

--- Comment #2 from Andreas Krebbel  ---
-fno-ipa-sra is required to get the same results as in the first comment. The
full command line then is:

c1plus -O3 -march=z14 t.ii -quiet -o t.s -fno-ipa-sra

[Bug rtl-optimization/94613] combine: Wrong code due to splitting a simplified IF_THEN_ELSE

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613

--- Comment #5 from Andreas Krebbel  ---
(In reply to Richard Biener from comment #3)
> Why is it not correct to split the insn the way you describe?  I see nothing
> wrong with that - the use of r115 is still under r110 == 0.  Is the issue
> that r115 is re-used and r115 has more than a single use?

Yes that's what it appeared to me in the original testcase but I have just
noticed that auto-reduction broke it.  In the reduced testcase r115 dies in
INSN 36 so it isn't useful right now. I agree that the splitting is legal in
that case.

[Bug target/94613] Wrong code generated for vec_sel builtin

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613

Andreas Krebbel  changed:

   What|Removed |Added

   Priority|P1  |P2
Summary|combine: Wrong code due to  |Wrong code generated for
   |splitting a simplified  |vec_sel builtin
   |IF_THEN_ELSE|
  Component|rtl-optimization|target
   Severity|critical|normal

[Bug target/94613] S/390: Wrong code generated for vec_sel builtin

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613

Andreas Krebbel  changed:

   What|Removed |Added

   Priority|P2  |P3
   Assignee|unassigned at gcc dot gnu.org  |krebbel at gcc dot 
gnu.org

--- Comment #6 from Andreas Krebbel  ---
My debugging went into the wrong direction. The problem arises from wrong RTL
being generated in the backend for the vec_sel builtin.

[Bug target/94666] New: S/390: ICE on vectorized popcount

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94666

Bug ID: 94666
   Summary: S/390: ICE on vectorized popcount
   Product: gcc
   Version: 9.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org
  Target Milestone: ---

Created attachment 48308
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48308&action=edit
Testcase

Compiling the attached testcase with:

cc1plus -O3 -march=z13 t.cc

ICEs:

t.cc: In function ‘void h()’:
t.cc:16:1: error: unrecognizable insn:
   16 | }
  | ^
(insn 94 93 95 7 (set (reg:V16QI 434)
(unspec:V16QI [
(subreg:V16QI (subreg:V2DI (reg:V16QI 432) 0) 0)
] UNSPEC_POPCNT)) "t.cc":6:30 -1
 (nil))
during RTL pass: vregs
t.cc:16:1: internal compiler error: in extract_insn, at recog.c:2294

[Bug target/94666] S/390: ICE on vectorized popcount

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94666

Andreas Krebbel  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2020-04-20
   Assignee|unassigned at gcc dot gnu.org  |krebbel at gcc dot 
gnu.org

--- Comment #1 from Andreas Krebbel  ---
Created attachment 48309
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48309&action=edit
Patch

The expander has to simplify the generated subreg in case the incoming operand
is already a subreg.

[Bug rtl-optimization/94670] ICE in extract_insn, at recog.c:2310 on s390x-linux-gnu with -march=z13

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94670

Andreas Krebbel  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-04-20
 Status|UNCONFIRMED |NEW

--- Comment #2 from Andreas Krebbel  ---
GCC BZ: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94666
LTC BZ: https://bugzilla.linux.ibm.com/show_bug.cgi?id=185158

[Bug target/94666] S/390: ICE on vectorized popcount

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94666

Andreas Krebbel  changed:

   What|Removed |Added

 CC||doko at debian dot org

--- Comment #2 from Andreas Krebbel  ---
*** Bug 94670 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/94670] ICE in extract_insn, at recog.c:2310 on s390x-linux-gnu with -march=z13

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94670

Andreas Krebbel  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Andreas Krebbel  ---
Mark as duplicate

*** This bug has been marked as a duplicate of bug 94666 ***

[Bug target/94666] S/390: ICE on vectorized popcount

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94666

Andreas Krebbel  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #3 from Andreas Krebbel  ---
I've just committed this patch to mainline (and forgot to mention the PR in the
ChangeLog :(

gcc/ChangeLog:

2020-04-20  Andreas Krebbel  

* config/s390/vector.md ("popcountv8hi2_vx", "popcountv4si2_vx")
("popcountv2di2_vx"): Use simplify_gen_subreg.

gcc/testsuite/ChangeLog:

2020-04-20  Andreas Krebbel  

* g++.dg/pr94666.C: New test.

[Bug target/94704] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on s390x/s390

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94704

Andreas Krebbel  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-04-22
 Status|UNCONFIRMED |NEW

--- Comment #2 from Andreas Krebbel  ---
(In reply to Jakub Jelinek from comment #1)

You patch fixes the testcases on IBM Z. I'll run a full bootstrap test over
night.

[Bug target/92950] Wrong load instructions emitted for movv1qi

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92950

Andreas Krebbel  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #5 from Andreas Krebbel  ---
Fixed

[Bug target/94666] S/390: ICE on vectorized popcount

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94666

Andreas Krebbel  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #4 from Andreas Krebbel  ---
Patch committed to GCC 8 and 9 branch.

[Bug tree-optimization/94969] New: Invalid loop distribution

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94969

Bug ID: 94969
   Summary: Invalid loop distribution
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org
  Target Milestone: ---

Created attachment 48461
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48461&action=edit
Testcase

The attached testcase aborts on x86 when compiled with -O3. It succeeds with
-O2 or -O3 -fno-loop-distribution.

The loop is distributed separating the two statements. This affects the result
of the testcase.

 for (; c <= 1; c++) {
f[b] = g;
f[b].e ^= 1;
  }

[Bug tree-optimization/94969] Invalid loop distribution

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94969

--- Comment #1 from Andreas Krebbel  ---
The problem arises from dr_analyze_innermost not being able to analyze the
bitfield access. However, the returned error is ignored in
find_data_references_in_stmt and execution continues with bogus values in the
data reference object.

[Bug tree-optimization/94969] Invalid loop distribution

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94969

--- Comment #2 from Andreas Krebbel  ---
Created attachment 48462
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48462&action=edit
Experimental patch

With this patch the returned error is propagated. Unfortunately this prevents
some vectorizations e.g. in gcc.dg/vect/vect-simd-5.c. The reason appears to be
the "evolution of base is not affine" failure in dr_analyze_innermost which now
also gets propagated.

[Bug tree-optimization/94969] Invalid loop distribution

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94969

Andreas Krebbel  changed:

   What|Removed |Added

   Priority|P3  |P2
   Host||x86_64-gnu-linux

[Bug bootstrap/95721] [11 Regression] bootstrap failure on s390x-linux-gnu

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95721

Andreas Krebbel  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andreas Krebbel  ---
This should be fixed with:

commit 929fd91ba975eebf9e57f7f092041271dcaf0c34
Author: Stefan Schulze Frielinghaus 
Date:   Thu Jun 4 13:50:49 2020 +0200

S/390: Emit vector alignment hints for z13 if AS accepts them

Since 87cb9423add vector alignment hints are emitted for target z13,
too.  This patch changes this behaviour in the sense that alignment
hints are only emitted for target z13 if the assembler accepts them.

gcc/ChangeLog:

* config.in: Regenerate.
* config/s390/s390.c (print_operand): Emit vector alignment hints
for target z13, if AS accepts them.  For other targets the logic
stays the same.
* config/s390/s390.h (TARGET_VECTOR_LOADSTORE_ALIGNMENT_HINTS):
Define
macro.
* configure: Regenerate.
* configure.ac: Check
HAVE_AS_VECTOR_LOADSTORE_ALIGNMENT_HINTS_ON_Z13.

[Bug tree-optimization/94969] [8/9/10/11 Regression] Invalid loop distribution since r8-2390-gdfbddbeb1ca912c9

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94969

Andreas Krebbel  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #13 from Andreas Krebbel  ---
Fixed by Bin Cheng. Thanks!

[Bug tree-optimization/94969] [8/9/10/11 Regression] Invalid loop distribution since r8-2390-gdfbddbeb1ca912c9

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94969

Andreas Krebbel  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #14 from Andreas Krebbel  ---
Closing

[Bug target/96456] [10/11 Regression] ICE in expand_insn, at optabs.c:7511 on s390x-linux-gnu

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96456

--- Comment #1 from Andreas Krebbel  ---
Confirmed for current gcc 10 branch. Does not appear to happen on trunk though.
I'll have a look.

[Bug tree-optimization/92141] New: Bogus -Wstringop-truncation warning for strncpy in a loop

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92141

Bug ID: 92141
   Summary: Bogus -Wstringop-truncation warning for strncpy in a
loop
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org
  Target Milestone: ---

Compiling the following testcase with: gcc -O2 -Wall t.c

char *strncpy(char *, const char *, long unsigned); 
struct {
  char b[8];
} c[6]; 
char b[8];  
void e() {  
  for (int f = 0;; f++) 
strncpy(b, c[f].b, 8);  
}

gives me:

t.c: In function 'e':
t.c:8:5: warning: 'strncpy' output may be truncated copying 8 bytes from a
string of length 47 [-Wstringop-truncation]
8 | strncpy(b, c[f].b, 8);
  | ^

[Bug rtl-optimization/92176] New: LRA problem with reloads for subreg operands

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92176

Bug ID: 92176
   Summary: LRA problem with reloads for subreg operands
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org
  Target Milestone: ---

Created attachment 47083
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47083&action=edit
reduced testcase

The attached testcase core dumps when compiled with -O3 -march=z13 but executes
fine with -O3 -march=zEC12.

A QImode subreg on a pseudo gets assigned a floating point register and is
simplified to (reg:QI (...)). However, changing the mode of an FPR is
disallowed by the S/390 backend in s390_can_change_mode class. The problem
appears to be that simplify_operand_subreg in lra-constraints.c does not check
can_change_mode_class before assigning a register class. It always picks the
preferred register class for an expression as returned by the backend.

reload used to invoke can_change_mode_class when reloading a subreg - see
push_reload.

I tried to return just GENERAL_REGS in the preferred_reload_class whenever
being invoked with a subreg for which can_change_mode class would return false.
This helps in some cases. However, that function does not always get called
with the subreg expression, if there are other uses of that register not having
a subreg.

[Bug rtl-optimization/92176] LRA problem with reloads for subreg operands

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92176

--- Comment #1 from Andreas Krebbel  ---
Created attachment 47387
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47387&action=edit
Another reduced testcase

gcc -O3 -march=z13 t.c -o t

./t

prints "checksum = 0" with head GCC
prints "checksum = 5" with GCCs before r272639 but this patch only appears to
reveal the actual issue

[Bug rtl-optimization/92176] LRA problem with reloads for subreg operands

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92176

--- Comment #2 from Andreas Krebbel  ---
Created attachment 47388
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47388&action=edit
Experimental patch

This patch fixes the second testcase. The first one currently doesn't fail on
head.

[Bug rtl-optimization/92176] LRA problem with reloads for subreg operands

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92176

Andreas Krebbel  changed:

   What|Removed |Added

   Priority|P3  |P2
   Severity|normal  |major

[Bug rtl-optimization/92176] LRA problem with reloads for subreg operands

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92176

--- Comment #3 from Andreas Krebbel  ---
276.ira:

(insn 6 85 11 2 (set (reg:SI 100 [ f ])
(mem/c:SI (symbol_ref:DI ("*.LANCHOR0") [flags 0x182]) [2 f+0 S4 A32]))
"t.c":13:8 1372 {*movsi_zarch}
 (expr_list:REG_EQUIV (mem/c:SI (symbol_ref:DI ("*.LANCHOR0") [flags
0x182]) [2 f+0 S4 A32])
(nil)))
...

(insn 87 75 207 2 (parallel [
(set (mem/c:QI (plus:DI (reg/f:DI 165)
(const_int 16 [0x10])) [0 b+0 S1 A16])
(and:QI (mem/c:QI (plus:DI (reg/f:DI 165)
(const_int 16 [0x10])) [0 b+0 S1 A16])
(subreg:QI (reg:SI 100 [ f ]) 3)))
(clobber (reg:CC 33 %cc))
]) "t.c":13:8 1830 {*andqi3_zarch}
 (expr_list:REG_DEAD (reg/f:DI 165)
(expr_list:REG_DEAD (reg:SI 100 [ f ])
(expr_list:REG_UNUSED (reg:CC 33 %cc)
(nil)

277.reload:

Reload at first generates two reloads for insn 87:

Changing pseudo 100 in operand 2 of insn 87 on equiv [`*.LANCHOR0']
  Creating newreg=202, assigning class ALL_REGS to slow/invalid mem r202
  Creating newreg=203, assigning class ALL_REGS to slow/invalid mem r203
   87: {[r165:DI+0x10]=[r165:DI+0x10]&r203:QI;clobber %cc:CC;}
  REG_DEAD r165:DI
  REG_DEAD r100:SI
  REG_UNUSED %cc:CC
Inserting slow/invalid mem reload before:
  254: r202:SI=[`*.LANCHOR0']
  255: r203:QI=r202:SI#3

(insn 254 0 0 (set (reg:SI 202)
(mem/c:SI (symbol_ref:DI ("*.LANCHOR0") [flags 0x182]) [2 f+0 S4 A32]))
1372 {*movsi_zarch}
 (nil))
(insn 255 254 0 (set (reg:QI 203)
(subreg:QI (reg:SI 202) 3)) -1
 (nil))


Both r202 as well as r203 get f0 assigned as hard register. In
lra_final_code_change-> alter_subregs-> alter_subreg -> simplify_subreg  this
gets simplified to:

(insn 255 254 256 2 (set (reg:QI 16 %f0 [203])
(reg:QI 16 %f0 [orig:202+3 ] [202])) "t.c":13:8 1379 {*movqi}
 (expr_list:REG_DEAD (reg:SI 16 %f0 [202])
(nil)))

Simplifying (subreg:QI (reg:SI 202) 3) to (reg:QI 16 %f0) is wrong on IBM Z
since floating point registers have a different endianess than general purpose
registers. Hence we forbid it via TARGET_CAN_CHANGE_MODE_CLASS. However, in
simplify_subreg_regno there is a check for lra_in_progress which leads to the
value of the target hook being ignored. Removing the lra_in_progress check
fixes the problem for. That change got in with the LRA patchset.

  /* Give the backend a chance to disallow the mode change.  */
  if (GET_MODE_CLASS (xmode) != MODE_COMPLEX_INT
  && GET_MODE_CLASS (xmode) != MODE_COMPLEX_FLOAT
  && !REG_CAN_CHANGE_MODE_P (xregno, xmode, ymode)
  /* We can use mode change in LRA for some transformations.  */
  && ! lra_in_progress) <-   ?
return -1;

I'm currently checking whether removing it makes any difference in code
generation - apart from fixing the testcase.

[Bug bootstrap/92828] New: array out of bounds access in libcpp/mkdeps.c

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92828

Bug ID: 92828
   Summary: array out of bounds access in libcpp/mkdeps.c
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org
  Target Milestone: ---

/* If T begins with any of the partial pathnames listed in d->vpathv,
   then advance T to point beyond that pathname.  */
static const char *
apply_vpath (class mkdeps *d, const char *t)
{
  if (unsigned len = d->vpath.size ())
for (unsigned i = len; i--;)
  {
if (!filename_ncmp (d->vpath[i].str, t, d->vpath[i].len))
  {
const char *p = t + d->vpath[i].len;
if (!IS_DIR_SEPARATOR (*p))
  goto not_this_one;

/* Do not simplify $(vpath)/../whatever.  ??? Might not
   be necessary. */
if (p[1] == '.' && p[2] == '.' && IS_DIR_SEPARATOR (p[3]))
  goto not_this_one;
...

The last check causes

error: array subscript 2 is outside array bounds of ‘const char [2]’

if apply_vpath gets inlined into deps_add_target and deps_add_target gets
inlined into:

void
deps_add_default_target (class mkdeps *d, const char *tgt)
{
  /* Only if we have no targets.  */
  if (d->targets.size ())
return;

  if (tgt[0] == '\0')
{
  __builtin_trap ();
  deps_add_target (d, "-", 1);
}
...


This unfortunately triggers a bootstrap fail on IBM Z when using
--with-arch=z13 at configure time. For z13 we bump the inlining threshold so
that the inlining described above actually happens.

The right fix appears to be passing the length of the buffer along with the
buffer itself. Alternatively it might also be ok to just remove the check as
the comment above it suggests.

[Bug bootstrap/92828] array out of bounds access in libcpp/mkdeps.c

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92828

--- Comment #2 from Andreas Krebbel  ---
Created attachment 47430
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47430&action=edit
reduced testcase

on x86_64:
cc1plus -quiet  -O2 t.cc -Wall --param max-inline-insns-auto=80

t.cc: In function 'void deps_add_default_target(mkdeps*, const char*)':
t.cc:47:24: warning: array subscript 2 is outside array bounds of 'const char
[2]' [-Warray-bounds]
   47 |  if (p[1] == '.' && p[2] == '.' && (((p[3]) == '/') || (((p[3]) ==
'\\') && (0goto not_this_one;
  | ~~~^
t.cc:47:42: warning: array subscript 3 is outside array bounds of 'const char
[2]' [-Warray-bounds]
   47 |  if (p[1] == '.' && p[2] == '.' && (((p[3]) == '/') || (((p[3]) ==
'\\') && (0goto not_this_one;
  |  ^~

[Bug bootstrap/92828] array out of bounds access in libcpp/mkdeps.c

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92828

--- Comment #4 from Andreas Krebbel  ---
(In reply to Andrew Pinski from comment #3)
> Are you saying the warning shows up which causes the bootstrap to fail?
> Because at runtime there should be no out of bounds access.

Yes. It is just the warning.

With an unknown value of d->vpath[i].len GCC cannot determine what the outcome
of the / check will be:

const char *p = t + d->vpath[i].len;
if (!IS_DIR_SEPARATOR (*p))
   goto not_this_one;

[Bug rtl-optimization/92176] LRA problem with reloads for subreg operands

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92176

--- Comment #7 from Andreas Krebbel  ---
Created attachment 47432
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47432&action=edit
Updated testcase

This is an updated testcase with the changes I propose.

Your testcase works fine. However, I would propose two minor adjustments:

- add -mzarch to enable the vector instructions also in a testsuite run with
-m31. The testcase does not trigger the problem on -m31 for other reasons but
that way it would at least have to the chance to.

- scan also for the element index in vsteb to be 0. With the proper index there
is a chance that code with vsteb is actually correct.

[Bug bootstrap/92828] array out of bounds access in libcpp/mkdeps.c

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92828

Andreas Krebbel  changed:

   What|Removed |Added

   Priority|P3  |P2

--- Comment #5 from Andreas Krebbel  ---
Since this currently prevents bootstrapping for z13 or higher on IBM Z I would
prefer to have a quick solution. Would it be acceptable to disable the warning
in mkdeps.c via pragma for now?

[Bug tree-optimization/92883] New: [10 Regression] ICE in compare_values_warnv

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92883

Bug ID: 92883
   Summary: [10 Regression] ICE in compare_values_warnv
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org
  Target Milestone: ---

Created attachment 47456
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47456&action=edit
Reduced testcase

Compiling the attached testcase for IBM Z with

gcc -O2 -march=z13 t.c -c

during IPA pass: cp
crash0.c: At top level:
crash0.c:718:1: internal compiler error: in compare_values_warnv, at
tree-vrp.c:540
0x1b5cd43 compare_values_warnv(tree_node*, tree_node*, bool*)
/home/andreas/gcc/gcc/tree-vrp.c:539
0x1b5ce15 compare_values(tree_node*, tree_node*)
/home/andreas/gcc/gcc/tree-vrp.c:700
0x1ba9beb value_range::check()
/home/andreas/gcc/gcc/value-range.cc:283
0x1baa673 value_range::set(tree_node*, tree_node*, value_range_kind)
/home/andreas/gcc/gcc/value-range.cc:236
0x1bad70b value_range::set(tree_node*, tree_node*, value_range_kind)
/home/andreas/gcc/gcc/value-range.cc:84
0x1bad70b value_range::intersect_helper(value_range const*, value_range const*)
/home/andreas/gcc/gcc/value-range.cc:943
0x1bae4c7 value_range::intersect(value_range const*)
/home/andreas/gcc/gcc/value-range.cc:1323
0x208db01 propagate_vr_across_jump_function
/home/andreas/gcc/gcc/ipa-cp.c:2020
0x208db01 propagate_constants_across_call
/home/andreas/gcc/gcc/ipa-cp.c:2393
0x20917d3 propagate_constants_topo
/home/andreas/gcc/gcc/ipa-cp.c:3313
0x20917d3 ipcp_propagate_stage
/home/andreas/gcc/gcc/ipa-cp.c:3409
0x20958f5 ipcp_driver
/home/andreas/gcc/gcc/ipa-cp.c:5261
0x20958f5 execute
/home/andreas/gcc/gcc/ipa-cp.c:5354
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.



The testcase compiles fine before r278185

[Bug tree-optimization/92883] [10 Regression] ICE in compare_values_warnv

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92883

Andreas Krebbel  changed:

   What|Removed |Added

  Attachment #47456|0   |1
is obsolete||

--- Comment #1 from Andreas Krebbel  ---
Created attachment 47457
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47457&action=edit
Actually reduced testcase

gcc -O2 t.c -c

during IPA pass: cp
t.c:17:1: internal compiler error: in compare_values_warnv, at tree-vrp.c:540
0x1b5cd43 compare_values_warnv(tree_node*, tree_node*, bool*)
/home/andreas/gcc/gcc/tree-vrp.c:539
0x1b5ce15 compare_values(tree_node*, tree_node*)
/home/andreas/gcc/gcc/tree-vrp.c:700
0x1ba9beb value_range::check()
/home/andreas/gcc/gcc/value-range.cc:283
0x1baa673 value_range::set(tree_node*, tree_node*, value_range_kind)
/home/andreas/gcc/gcc/value-range.cc:236
0x1bad70b value_range::set(tree_node*, tree_node*, value_range_kind)
/home/andreas/gcc/gcc/value-range.cc:84
0x1bad70b value_range::intersect_helper(value_range const*, value_range const*)
/home/andreas/gcc/gcc/value-range.cc:943
0x1bae4c7 value_range::intersect(value_range const*)
/home/andreas/gcc/gcc/value-range.cc:1323
0x208db01 propagate_vr_across_jump_function
/home/andreas/gcc/gcc/ipa-cp.c:2020
0x208db01 propagate_constants_across_call
/home/andreas/gcc/gcc/ipa-cp.c:2393
0x20917d3 propagate_constants_topo
/home/andreas/gcc/gcc/ipa-cp.c:3313
0x20917d3 ipcp_propagate_stage
/home/andreas/gcc/gcc/ipa-cp.c:3409
0x20958f5 ipcp_driver
/home/andreas/gcc/gcc/ipa-cp.c:5261
0x20958f5 execute
/home/andreas/gcc/gcc/ipa-cp.c:5354
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/92950] New: Wrong load instructions emitted for movv1qi

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92950

Bug ID: 92950
   Summary: Wrong load instructions emitted for movv1qi
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org
  Target Milestone: ---

The following testcase abort when being compiled with -O3 -march=z13 on IBM Z:

struct a {
  int b;
  char c;
};
struct a d = {1, 16};
struct a *e = &d;

int f = 0;

int main() {
  struct a g = {0, 0 };
  f = 0;

  for (; f <= 1; f++) {
g = d;
*e = g;
  }

  if (d.c != 16)
__builtin_abort();
}

The movv1qi pattern emits halfword load instructions instead of character
loads.

[Bug target/92950] Wrong load instructions emitted for movv1qi

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92950

Andreas Krebbel  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target||s390x-ibm-linux
   Priority|P3  |P2
   Host||s390x-ibm-linux
  Build||s390x-ibm-linux

[Bug target/92950] Wrong load instructions emitted for movv1qi

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92950

--- Comment #1 from Andreas Krebbel  ---
Author: krebbel
Date: Mon Dec 16 08:03:28 2019
New Revision: 279410

URL: https://gcc.gnu.org/viewcvs?rev=279410&root=gcc&view=rev
Log:
Fix PR92950: Wrong code emitted for movv1qi

The backend emits 16 bit memory loads for single element character
vector.  As a result the character will not be right justified in the
GPR.

gcc/ChangeLog:

2019-12-16  Andreas Krebbel  

PR target/92950
* config/s390/vector.md ("mov" for V_8): Replace lh, lhy,
and lhrl with llc.

gcc/testsuite/ChangeLog:

2019-12-16  Andreas Krebbel  

PR target/92950
* gcc.target/s390/vector/pr92950.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/s390/vector/pr92950.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/s390/vector.md
trunk/gcc/testsuite/ChangeLog

[Bug target/92950] Wrong load instructions emitted for movv1qi

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92950

--- Comment #2 from Andreas Krebbel  ---
Author: krebbel
Date: Tue Dec 17 08:37:26 2019
New Revision: 279453

URL: https://gcc.gnu.org/viewcvs?rev=279453&root=gcc&view=rev
Log:
Fix PR92950: Wrong code emitted for movv1qi

The backend emits 16 bit memory loads for single element character
vector.  As a result the character will not be right justified in the
GPR.

gcc/ChangeLog:

2019-12-17  Andreas Krebbel  

Backport from mainline
2019-12-16  Andreas Krebbel  

PR target/92950
* config/s390/vector.md ("mov" for V_8): Replace lh, lhy,
and lhrl with llc.

gcc/testsuite/ChangeLog:

2019-12-17  Andreas Krebbel  

Backport from mainline
2019-12-16  Andreas Krebbel  

PR target/92950
* gcc.target/s390/vector/pr92950.c: New test.


Added:
branches/gcc-9-branch/gcc/testsuite/gcc.target/s390/vector/pr92950.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/config/s390/vector.md
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug target/92950] Wrong load instructions emitted for movv1qi

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92950

--- Comment #3 from Andreas Krebbel  ---
Author: krebbel
Date: Tue Dec 17 08:41:54 2019
New Revision: 279454

URL: https://gcc.gnu.org/viewcvs?rev=279454&root=gcc&view=rev
Log:
Fix PR92950: Wrong code emitted for movv1qi

The backend emits 16 bit memory loads for single element character
vector.  As a result the character will not be right justified in the
GPR.

gcc/ChangeLog:

2019-12-17  Andreas Krebbel  

Backport from mainline
2019-12-16  Andreas Krebbel  

PR target/92950
* config/s390/vector.md ("mov" for V_8): Replace lh, lhy,
and lhrl with llc.

gcc/testsuite/ChangeLog:

2019-12-17  Andreas Krebbel  

Backport from mainline
2019-12-16  Andreas Krebbel  

PR target/92950
* gcc.target/s390/vector/pr92950.c: New test.


Added:
branches/gcc-8-branch/gcc/testsuite/gcc.target/s390/vector/pr92950.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/s390/vector.md
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/93272] New: LRA: EH reg allocated to hold local variable

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93272

Bug ID: 93272
   Summary: LRA: EH reg allocated to hold local variable
   Product: gcc
   Version: 5.5.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org
  Target Milestone: ---

Created attachment 47655
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47655&action=edit
Reduced testcase

When compiling the attached testcase for IBM Z with r253576
g++ t.cpp -S -march=z196 -mtune=zEC12 -O3 -fPIC -msoft-float -std=c++98

local variable p is live from the try block to the catch block and is being put
into r6 although that register is being used as EH reg on IBM Z.

The problem appears to be triggered by having the assignment in the try block
in a loop. Due to that the allocno in the try block gets a region separate from
the region in the catch block. The allocno used in the catch block is correctly
marked as conflicting with the EH hard regs in ira-lives. The allocno in the
catch handler gets r13 assigned which is fine. The other one r6.

In ira-emit a move between the two regions is being generated. Unfortunately
the move is being put into the catch block making r6 live across the eh edge.

The testcase is correctly compiled with more recent GCCs. However, I'm not sure
that LRA is actively preventing this. It rather looks like recent GCCs just
manage to find a register which is ok for both regions.

[Bug rtl-optimization/93272] LRA: EH reg allocated to hold local variable

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93272

--- Comment #1 from Andreas Krebbel  ---
Created attachment 47656
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47656&action=edit
Experimental patch

[Bug rtl-optimization/93272] LRA: EH reg allocated to hold local variable

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93272

Andreas Krebbel  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug rtl-optimization/92176] LRA problem with reloads for subreg operands

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92176

--- Comment #11 from Andreas Krebbel  ---
(In reply to CVS Commits from comment #10)
> The master branch has been updated by Andreas Krebbel :
> 
> https://gcc.gnu.org/g:3b5757ea87ad2274b841340335bf7536204e615b
> 
> commit r10-5996-g3b5757ea87ad2274b841340335bf7536204e615b
> Author: Andreas Krebbel 
> Date:   Thu Jan 16 10:41:44 2020 +0100
> 
> Work around array out of bounds warning in mkdeps
> 
> This suppresses an array out of bounds warning in mkdeps.c as proposed
> by Martin Sebor in the bugzilla.
> 
> array subscript 2 is outside array bounds of ‘const char [2]’
> 
> Since this warning does occur during bootstrap it currently breaks
> werror builds on IBM Z.
> 
> The problem can be reproduced also on x86_64 by changing the inlining
> threshold using: --param max-inline-insns-auto=80
> 
> Bootstrapped and regression tested on x86_64 and IBM Z.
> 
> libcpp/ChangeLog:
> 
> 2020-01-16  Andreas Krebbel  
> 
>   PR tree-optimization/92176
>   * mkdeps.c (deps_add_default_target): Avoid calling apply_vpath to
>   suppress an array out of bounds warning.

PR number was wrong in the commit - sorry.

[Bug rtl-optimization/93272] LRA: EH reg allocated to hold local variable

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93272

--- Comment #2 from Andreas Krebbel  ---
This problem to some degree is specific to IBM Z since our EH regs are
call-saved registers. For targets using call-clobbered EH regs such a
collisions usually cannot happen. Perhaps it can be provoked with
-fnon-call-exceptions.

[Bug rtl-optimization/93272] LRA: EH reg allocated to hold local variable

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93272

Andreas Krebbel  changed:

   What|Removed |Added

  Attachment #47656|0   |1
is obsolete||

--- Comment #3 from Andreas Krebbel  ---
Created attachment 47714
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47714&action=edit
IRA EH fix - only when added at start of BB

A probably better version of the fix. This version only reverts the allocation
decision if the move is about to be added at the start of an EH basic block.

[Bug rtl-optimization/93272] LRA: EH reg allocated to hold local variable

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93272

--- Comment #5 from Andreas Krebbel  ---
(In reply to Vladimir Makarov from comment #4)
> (In reply to Andreas Krebbel from comment #3)
> > Created attachment 47714 [details]
> > IRA EH fix - only when added at start of BB
> > 
> > A probably better version of the fix. This version only reverts the
> > allocation decision if the move is about to be added at the start of an EH
> > basic block.
> 
> Andreas, thank you for explaining the problem.  Your patch should solve the
> problem but my worry is that the final assignment can be worse (especially
> if the pseudo in a loop goes into an EH bb).
> 
> I think that such pseudo should have the right conflicting hard regnos
> **before** the assignment.  In this case the pseudo did not get a hard
> register living into EH but still can get another hard register.
> If you don't mind, I will take it from here and try to create such patch. 
> If you want to continue this work by yourself, please let me know.

Please do. Thanks!

[Bug rtl-optimization/93272] LRA: EH reg allocated to hold local variable

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93272

Andreas Krebbel  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2020-02-12
 Resolution|FIXED   |---
 Ever confirmed|0   |1

--- Comment #8 from Andreas Krebbel  ---
Since this is a latent bug in LRA I think the patch needs backporting to GCC 8
and 9 branches.

[Bug rtl-optimization/54016] loop optimizer: no "branch on count" on s390 anymore since revision 185913

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54016



Andreas Krebbel  changed:



   What|Removed |Added



 Status|NEW |RESOLVED

 Resolution||FIXED



--- Comment #5 from Andreas Krebbel  2013-03-07 
11:24:14 UTC ---

Fixed with the patch for BZ56181.

[Bug rtl-optimization/54016] loop optimizer: no "branch on count" on s390 anymore since revision 185913

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54016



Andreas Krebbel  changed:



   What|Removed |Added



 Status|RESOLVED|CLOSED



--- Comment #6 from Andreas Krebbel  2013-03-07 
11:26:26 UTC ---

Closed per comment above.

[Bug bootstrap/56689] New: internal compiler error: in get_loop_body, at cfgloop.c:841

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56689

 Bug #: 56689
   Summary: internal compiler error: in get_loop_body, at
cfgloop.c:841
Classification: Unclassified
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kreb...@gcc.gnu.org


gcc/reginfo.c: In function ‘void fix_register(const char*, int, int)’:
gcc/reginfo.c:680:1: internal compiler error: in get_loop_body, at
cfgloop.c:841
 fix_register (const char *name, int fixed, int call_used)
 ^

Reghunt indicates that it is related to r196792

+2013-03-19  Richard Biener  
+
+   PR tree-optimization/56273
+   * gcc.dg/tree-ssa/vrp47.c: Adjust.
+   * c-c++-common/uninit-17.c: Likewise.

[Bug bootstrap/56689] internal compiler error: in get_loop_body, at cfgloop.c:841

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56689

--- Comment #2 from Andreas Krebbel  2013-03-22 
14:56:43 UTC ---
Created attachment 29707
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29707
Reduced testcase

cc1plus -fpreprocessed  -quiet  -O2 t.cc

t.cc: In function ‘void fix_register(const char*, int, int)’:
t.cc:33:1: error: size of loop 1 should be 7, not 8
 fix_register (const char *name, int fixed, int call_used)
 ^
t.cc:33:1: internal compiler error: in verify_loop_structure, at cfgloop.c:1640
0x8054a083 verify_loop_structure()
/home/andreas/clean/gcc-head/gcc/cfgloop.c:1640
0x808a8b43 loop_optimizer_init(unsigned int)
/home/andreas/clean/gcc-head/gcc/loop-init.c:100
0x80c0ddfd perform_tree_ssa_dce
/home/andreas/clean/gcc-head/gcc/tree-ssa-dce.c:1554
0x80c0e12f tree_ssa_cd_dce
/home/andreas/clean/gcc-head/gcc/tree-ssa-dce.c:1637
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug bootstrap/56689] internal compiler error: in get_loop_body, at cfgloop.c:841

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56689

Andreas Krebbel  changed:

   What|Removed |Added

  Attachment #29707|0   |1
is obsolete||

--- Comment #3 from Andreas Krebbel  2013-03-25 
08:01:00 UTC ---
Created attachment 29717
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29717
Manually reduced testcase

cc1 -O2 t.c

t.c: In function ‘fix_register’:
t.c:6:1: error: size of loop 1 should be 7, not 8
 fix_register (const char *name, int fixed, int call_used, int nregs)
 ^
t.c:6:1: internal compiler error: in verify_loop_structure, at cfgloop.c:1640
0x80227273 verify_loop_structure()
/home/andreas/clean/gcc-head/gcc/cfgloop.c:1640
0x8076488f perform_tree_ssa_dce
/home/andreas/clean/gcc-head/gcc/tree-ssa-dce.c:1554
0x80764be1 tree_ssa_cd_dce
/home/andreas/clean/gcc-head/gcc/tree-ssa-dce.c:1637
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug bootstrap/56689] internal compiler error: in get_loop_body, at cfgloop.c:841

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56689



--- Comment #4 from Andreas Krebbel  2013-03-25 
09:14:52 UTC ---

phicprop2:

  :

  switch (fixed_11(D)) , case 0: , case 1: >



vrp2:

  :

  switch (fixed_13(D)) , case 1: >



: (bb 10)

  switch (call_used_12(D)) , case 1: >





VRP optimizes the "case 0: " away. So there is no edge between bb9 and bb10

anymore. Due to that dfs_enumerate_from does not consider bb9 to be part of the

loop anymore. It counts 7 instead of 8 bbs for the loop due to this.

[Bug bootstrap/56689] [4.9 Regression] internal compiler error: in get_loop_body, at cfgloop.c:841

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56689



Andreas Krebbel  changed:



   What|Removed |Added



 Status|RESOLVED|CLOSED



--- Comment #7 from Andreas Krebbel  2013-03-26 
15:08:33 UTC ---

Patch fixes the problem for me. Thanks!

[Bug libffi/56033] FAIL: libffi.call/cls_struct_va1.c on powerpc-*-* and sparc-sun-solaris2* with -m64

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56033



Andreas Krebbel  changed:



   What|Removed |Added



 CC||krebbel at gcc dot gnu.org



--- Comment #5 from Andreas Krebbel  2013-04-08 
11:19:16 UTC ---

Confirmed for s390x.



Looks like an endianess issue to me. In cls_struct_va1.c the void pointer to

the return value is cast to an int pointer before writing to it:



static void

test_fn (ffi_cif* cif __UNUSED__, void* resp,

 void** args, void* userdata __UNUSED__)

{

...

  * (int*) resp = 42;

}



But the pointer later on is expected to point to a register size value.



There are also testcases which do it differently (e.g. closure_fn0.c). They

cast the pointer to the return value to ffi_arg* before accessing it. ffi_arg

is defined to be a register size type. From the documentation I cannot tell

which one is supposed to be correct.



static void

closure_test_fn0(ffi_cif* cif __UNUSED__, void* resp, void** args,

 void* userdata)

{

  *(ffi_arg*)resp = ...

}



Btw. for both examples the return type is defined as &ffi_type_sint in

ffi_prep_cif

[Bug libffi/56033] FAIL: libffi.call/cls_struct_va1.c on powerpc-*-* and sparc-sun-solaris2* with -m64

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56033



--- Comment #6 from Andreas Krebbel  2013-04-08 
11:24:22 UTC ---

Just noticed the example in libffi documentation which suggests that casting to

the return type pointer should work:



/* Acts like puts with the file given at time of enclosure. */

void puts_binding(ffi_cif *cif, unsigned int *ret, void* args[], 

  FILE *stream)

@{

  *ret = fputs(*(char **)args[0], stream);

@}

[Bug middle-end/56978] New: memset-chk.c failure since r197671

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56978

 Bug #: 56978
   Summary: memset-chk.c failure since r197671
Classification: Unclassified
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kreb...@gcc.gnu.org


/home/andreas/clean/gcc-head-build/gcc/xgcc
-B/home/andreas/clean/gcc-head-build/gcc/
/home/andreas/clean/gcc-head/gcc/testsuite/gcc.c-torture/execute/builtins/memset-chk.c
/home/andreas/clean/gcc-head/gcc/testsuite/gcc.c-torture/execute/builtins/memset-chk-lib.c
/home/andreas/clean/gcc-head/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c
-fno-diagnostics-show-caret -w -O3 -fomit-frame-pointer -funroll-loops
-fno-tree-loop-distribute-patterns -lm -o
/home/andreas/clean/gcc-head-build/gcc/testsuite/gcc5/memset-chk.x

/home/andreas/clean/gcc-head/gcc/testsuite/gcc.c-torture/execute/builtins/memset-chk.c:
In function ‘test5’:
/home/andreas/clean/gcc-head/gcc/testsuite/gcc.c-torture/execute/builtins/memset-chk.c:552:1:
internal compiler error: in emit_move_insn_1, at expr.c:3428
0x802f712b emit_move_insn_1(rtx_def*, rtx_def*)
/home/andreas/clean/gcc-head/gcc/expr.c:3428
0x802f71c5 emit_move_insn(rtx_def*, rtx_def*)
/home/andreas/clean/gcc-head/gcc/expr.c:3526
0x802d68bb force_reg
/home/andreas/clean/gcc-head/gcc/explow.c:676
0x802f8053 convert_move(rtx_def*, rtx_def*, int)
/home/andreas/clean/gcc-head/gcc/expr.c:590
0x802f87b9 convert_modes(machine_mode, machine_mode, rtx_def*, int)
/home/andreas/clean/gcc-head/gcc/expr.c:781
0x804bd919 expand_binop_directly
/home/andreas/clean/gcc-head/gcc/optabs.c:1427
0x804bb57f expand_binop(machine_mode, optab_tag, rtx_def*, rtx_def*, rtx_def*,
int, optab_methods)
/home/andreas/clean/gcc-head/gcc/optabs.c:1543
0x804bd70d expand_simple_binop(machine_mode, rtx_code, rtx_def*, rtx_def*,
rtx_def*, int, optab_methods)
/home/andreas/clean/gcc-head/gcc/optabs.c:1291
0x802fb645 force_operand(rtx_def*, rtx_def*)
/home/andreas/clean/gcc-head/gcc/expr.c:7054
0x8094d3c3 doloop_modify
/home/andreas/clean/gcc-head/gcc/loop-doloop.c:480
0x8094d3c3 doloop_optimize
/home/andreas/clean/gcc-head/gcc/loop-doloop.c:750
0x8094d3c3 doloop_optimize_loops()
/home/andreas/clean/gcc-head/gcc/loop-doloop.c:764
0x804549d7 rtl_doloop
/home/andreas/clean/gcc-head/gcc/loop-init.c:543
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Reghunt indicates that the error has been introduced with:

2013-04-10  Richard Biener  

* passes.c (execute_todo): Do not call ggc_collect conditional here.
(execute_one_ipa_transform_pass): But unconditionally here.
(execute_one_pass): And here.
(init_optimization_passes): Remove reload pass.
* tree-pass.h (TODO_ggc_collect): Remove.
(pass_reload): Likewise.
* ira.c (do_reload): Merge into ...
(ira): ... this.
(rest_of_handle_reload): Remove.
(pass_reload): Likewise.
* config/i386/i386.c (ix86_option_override): Refer to ira instead
of reload for vzeroupper pass placement.
* : Remove TODO_ggc_collect from todo_flags_start
and todo_flags_finish of all passes.

* g++.dg/pr55604.C: Use -fdump-rtl-ira.

[Bug middle-end/56978] memset-chk.c failure since r197671

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56978



Andreas Krebbel  changed:



   What|Removed |Added



 Status|UNCONFIRMED |RESOLVED

 Resolution||DUPLICATE



--- Comment #2 from Andreas Krebbel  2013-04-16 
13:40:27 UTC ---

The patch from PR56921 fixes the issue on S/390. Thanks!



*** This bug has been marked as a duplicate of bug 56921 ***

[Bug rtl-optimization/56921] [4.9 Regression] ICE in rtx_cost called by doloop_optimize_loops for PPC

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56921



Andreas Krebbel  changed:



   What|Removed |Added



 CC||krebbel at gcc dot gnu.org



--- Comment #14 from Andreas Krebbel  2013-04-16 
13:40:27 UTC ---

*** Bug 56978 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/57067] New: Missing control flow edges for setjmp/longjmp

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57067



 Bug #: 57067

   Summary: Missing control flow edges for setjmp/longjmp

Classification: Unclassified

   Product: gcc

   Version: 4.9.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: rtl-optimization

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: kreb...@gcc.gnu.org





The fix for PR56982 adds abnormal control flow edges from function calls to a

setjmp call in the same function. Unfortunately these edges do not survive

until RTL so that the RTL passes might still do the wrong thing. 



The edges are removed in gimple_expand_cfg:



  /* At the moment not all abnormal edges match the RTL

 representation.  It is safe to remove them here as

 find_many_sub_basic_blocks will rediscover them.

 In the future we should get this fixed properly.  */

  if ((e->flags & EDGE_ABNORMAL)

  && !(e->flags & EDGE_SIBCALL))

remove_edge (e);

  else

ei_next (&ei);





find_many_sub_basic_blocks needs a fix to add them back as well.



I don't have a testcase for GCC head.  The testcase I have fails only with GCC

4.4: http://gcc.gnu.org/ml/gcc/2013-04/msg00237.html



In this case the RTL scheduler pass generates broken code due to the missing

control flow info.  I think this could potentially happen with GCC head as

well.

[Bug rtl-optimization/57067] Missing control flow edges for setjmp/longjmp

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57067



--- Comment #2 from Andreas Krebbel  2013-04-25 
14:46:09 UTC ---

(In reply to comment #1)

> I suppose more selectively removing edges would be best.  Eventually this is

> done to cater for expansions of builtin calls to non-calls?  Then maybe

> those edges should be removed later, _after_ builtin expansion and

> find_many_sub_basic_blocks?



Wouldn't it be better to keep all the edges and fix the fallout from the RTL

passes?



Do you remember any example where this currently fails?



I've verified with GCC 4.4 that dropping the edge removal code from cfgexpand.c

together with a backport of the PR56982 patch fixes the actual problem.

[Bug target/54746] config/s390/s390.c:1583: possible missing break in switch ?

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54746



--- Comment #2 from Andreas Krebbel  2012-10-01 
07:23:21 UTC ---

Author: krebbel

Date: Mon Oct  1 07:23:12 2012

New Revision: 191885



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191885

Log:

2012-10-01  Andreas Krebbel  



PR target/54746

* config/s390/s390.c (s390_option_override): Add missing break.





Modified:

trunk/gcc/ChangeLog

trunk/gcc/config/s390/s390.c

[Bug target/54746] config/s390/s390.c:1583: possible missing break in switch ?

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54746



--- Comment #3 from Andreas Krebbel  2012-10-01 
07:33:17 UTC ---

(In reply to comment #0)

> break;

> case PROCESSOR_2097_Z10:

>   s390_cost = &z10_cost;

> case PROCESSOR_2817_Z196:

>   s390_cost = &z196_cost;

> 

> Looks like a missing break to me. The wrong cost gets picked up.



You are right. I'll commit a patch to mainline and 4.7 branch. Thanks!

[Bug target/54746] config/s390/s390.c:1583: possible missing break in switch ?

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54746



--- Comment #4 from Andreas Krebbel  2012-10-01 
07:51:26 UTC ---

Author: krebbel

Date: Mon Oct  1 07:51:20 2012

New Revision: 191888



URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191888

Log:

2012-10-01  Andreas Krebbel  



PR target/54746

* config/s390/s390.c (s390_option_override): Add missing break.





Modified:

branches/gcc-4_7-branch/gcc/ChangeLog

branches/gcc-4_7-branch/gcc/config/s390/s390.c

[Bug bootstrap/47215] [4.6 Regression] Failed to bootstrap

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47215

Andreas Krebbel  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2011.01.10 16:14:36
 CC||krebbel at gcc dot gnu.org
 Resolution|FIXED   |
 Ever Confirmed|0   |1

--- Comment #7 from Andreas Krebbel  2011-01-10 
16:14:36 UTC ---
On s390x rev. 168625 it still fails with:

:0:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[5]: *** [java/lang/Object.lo] Error 1
make[5]: *** Waiting for unfinished jobs
:0:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
mkdir -p -- gnu/java/awt/
make[5]: *** [java/lang/Class.lo] Error 1

Rev. 168568 works fine.

[Bug middle-end/47646] [4.6 Regression] Revision 169918 caused many testsuite failures

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47646

--- Comment #1 from Andreas Krebbel  2011-02-08 
16:46:25 UTC ---
Author: krebbel
Date: Tue Feb  8 16:46:20 2011
New Revision: 169927

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169927
Log:
2011-02-08  Andreas Krebbel  

PR middle-end/47646
* gcc.dg/pr39666-2.c (foo2): If the location of the statement
using the variable is known the warning is emitted there.
* gcc.dg/uninit-pr19430.c (foo): Likewise.
* g++.dg/warn/Wuninitialized-5.C (foo): Likewise.

* c-c++-common/pr2.c (g): Both warnings occur at the return
statement.
(vg): Likewise.
* gcc.dg/noreturn-1.c (foo5): Likewise.
* objc.dg/attributes/method-noreturn-1.m (method1): Likewise.
(method2): Likewise.

* gfortran.dg/pr25923.f90 (baz): The warning will now be issued for
the return statement using the uninitialized variable.
* gfortran.dg/pr39666-2.f90 (f): Likewise.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/pr2.c
trunk/gcc/testsuite/g++.dg/warn/Wuninitialized-5.C
trunk/gcc/testsuite/gcc.dg/noreturn-1.c
trunk/gcc/testsuite/gcc.dg/pr39666-2.c
trunk/gcc/testsuite/gcc.dg/uninit-pr19430.c
trunk/gcc/testsuite/gfortran.dg/pr25923.f90
trunk/gcc/testsuite/gfortran.dg/pr39666-2.f90
trunk/gcc/testsuite/objc.dg/attributes/method-noreturn-1.m

[Bug middle-end/47646] [4.6 Regression] Revision 169918 caused many testsuite failures

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47646

--- Comment #5 from Andreas Krebbel  2011-02-09 
08:35:32 UTC ---
(In reply to comment #4)
> > The following patch is missing for
> > gcc/testsuite/obj-c++.dg/attributes/method-noreturn-1.mm:
> 
> Can't you simply move the dg directives ?

No. The problem is that two dg-warnings would be at the same line then.

I think the patch is ok. I cannot approve it but its an obvious change.

Thanks!

[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246

Andreas Krebbel  changed:

   What|Removed |Added

 CC||krebbel at gcc dot gnu.org

--- Comment #4 from Andreas Krebbel  2011-02-25 
14:08:20 UTC ---
I also see uninit-13.c failing on s390x.

The warning here is also emitted for line 7 while being expected in
line 8.

 4  typedef _Complex float C;
 5  C foo()
 6  {
 7C f;
 8__imag__ f = 0;   /* { dg-warning "is used" "unconditional" } */
 9return f;
10  }

The question is why do we expect the warning in line 8 at all?!  To me
it makes sense to either emit the warning on the uninitialized use -
that would be the "return f;" in line 9 or emit it for the declaration
of the uninitialized variable - that would be line 7 then.

To my understanding line 8 is the only one not directly related to the
warning.

warn_uninit in tree-ssa.c seems to implement exactly this.  It uses
either the location of the using gimple expression if available or it
falls back to the var decl. On s390x I see the var decl being used as
location while for x86_64 there is a stmt having its own location which
is used instead.

x86_64: uninit-13.c.083t.dce2:

foo ()
{
  float f$real;
  C f;

:
  [gcc/testsuite/gcc.dg/uninit-13.c : 8:14] f_3 = COMPLEX_EXPR ;
  return f_3;

}



s390x: uninit-13.i.083t.dce2

foo ()
{
  float f$real;

:
  REALPART_EXPR <> = f$real_6(D);
  [gcc/testsuite/gcc.dg/uninit-13.c : 9:3] IMAGPART_EXPR <> = 0.0;
  [gcc/testsuite/gcc.dg/uninit-13.c : 9:3] return ;

}


Before dce2 the line with the COMPLEX_EXPR exists also on s390x:

s390x: uninit-13.i.082t.reassoc1:

foo ()
{
  float f$real;
  C f;
  float D.2702;

:
  [gcc/testsuite/gcc.dg/uninit-13.c : 8:14] f$real_2 = f$real_6(D);
  [gcc/testsuite/gcc.dg/uninit-13.c : 8:14] f_3 = COMPLEX_EXPR ;
  REALPART_EXPR <> = f$real_6(D);
  [gcc/testsuite/gcc.dg/uninit-13.c : 9:3] IMAGPART_EXPR <> = 0.0;
  [gcc/testsuite/gcc.dg/uninit-13.c : 9:3] return ;

}

I think first we should fix the testcase - moving the warning one line
up and then find a way to fix the x86_64 problem.  To me it currently
looks like this is a testcase bug.

[Bug middle-end/39246] FAIL: gcc.dg/uninit-13.c

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39246

--- Comment #6 from Andreas Krebbel  2011-03-01 
18:08:11 UTC ---
The first difference between x86_64 and s390x appears in 004t.gimple since
s390x returns complex numbers in memory:

x86_64:

foo ()
{
  float D.2684;
  C D.2685;
  C f;

  D.2684 = REALPART_EXPR ;
  f = COMPLEX_EXPR ;
  D.2685 = f;
  return D.2685;
}

s390x:

foo ()
{
  float D.2702;
  C f;

  D.2702 = REALPART_EXPR ;
  f = COMPLEX_EXPR ;
   = f;
  return ;
}


The assignment to the imaginary part is introduced by cplxlower:

foo ()
{
  float f$real;
  C f;
  float D.2702;

:
  f$real_2 = f$real_6(D);
  f_3 = COMPLEX_EXPR ;
  REALPART_EXPR <> = f$real_2;
  IMAGPART_EXPR <> = 0.0;
  return ;

}

expand_complex_operations_1 is invoked for gimple stmt:
# .MEM_5 = VDEF <.MEM_4(D)>
 = f_3;

the code falls through to the default label and invokes emit_complex_move in
tree-complex.c:1459

Since  is no SSA_NAME emit_complex_move falls through to the code in
tree-complex.c:826 which splits the complex move to:

  REALPART_EXPR <> = f$real_2;
  IMAGPART_EXPR <> = 0.0;

[Bug c/47837] FAIL: gcc.dg/uninit-pred-7_a.c bogus warning (test for bogus messages, line 26)

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47837

Andreas Krebbel  changed:

   What|Removed |Added

 Target|hppa1.1-hp-hpux10.20|hppa1.1-hp-hpux10.20,
   ||s390x-ibm-linux
 CC||krebbel at gcc dot gnu.org
   Host|hppa1.1-hp-hpux10.20|hppa1.1-hp-hpux10.20,
   ||s390x-ibm-linux
  Build|hppa1.1-hp-hpux10.20|hppa1.1-hp-hpux10.20,
   ||s390x-ibm-linux

--- Comment #1 from Andreas Krebbel  2011-03-03 
12:43:34 UTC ---
I see the same on s390x.

[Bug c/47837] FAIL: gcc.dg/uninit-pred-7_a.c bogus warning (test for bogus messages, line 26)

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47837

--- Comment #3 from Andreas Krebbel  2011-03-03 
17:38:48 UTC ---
Created attachment 23535
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23535
uninit-pred-7_a.c.126t.cddce2

[Bug c/47837] FAIL: gcc.dg/uninit-pred-7_a.c bogus warning (test for bogus messages, line 26)

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47837

--- Comment #4 from Andreas Krebbel  2011-03-03 
17:39:12 UTC ---
Created attachment 23536
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23536
uninit-pred-7_a.c.128t.uninit

[Bug rtl-optimization/57559] New: S/390: ICE with lra

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57559

Bug ID: 57559
   Summary: S/390: ICE with lra
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org

t.c:

typedef int int32_t;
typedef unsigned char uint8_t;
typedef unsigned int uint32_t;
struct _IO_marker
{
};
static const int32_t mfcone = 1;
static const uint8_t *mfctop = (const uint8_t *) &mfcone;
int32_t
decContextTestEndian (uint8_t quiet)
{
  int32_t res = 0;
  uint32_t dle = (uint32_t) 0;
  if (*mfctop != 0)
{
  res = (int32_t) * mfctop - dle;
}
  return res;
}

cc1 -fpreprocessed  -quiet -march=z10 -m64 -mzarch  -O1 t.c -o t.s

t.c: In function ‘decContextTestEndian’:
t.c:19:1: internal compiler error: Max. number of generated reload insns per
insn is achieved (90)

 }
 ^
0x806b1637 lra_constraints(bool)
/home/andreas/clean/gcc-head/gcc/lra-constraints.c:3698
0x80697d8b lra(_IO_FILE*)
/home/andreas/clean/gcc-head/gcc/lra.c:2278
0x80621aeb do_reload
/home/andreas/clean/gcc-head/gcc/ira.c:4641
0x80621dfd rest_of_handle_reload
/home/andreas/clean/gcc-head/gcc/ira.c:4753
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.


The testcase works fine with either -mno-lra or -march=z9-109

[Bug bootstrap/57603] New: Bootstrap fail on s390x segfault in fold_marked_statements

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57603

Bug ID: 57603
   Summary: Bootstrap fail on s390x segfault in
fold_marked_statements
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org

Created attachment 30300
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30300&action=edit
delta minimized testcase

cc1 -fpreprocessed -quiet -march=z9-109  -O1 t.c

Program received signal SIGSEGV, Segmentation fault.
0x805c3b22 in fold_marked_statements(int, pointer_set_t*) ()
(gdb) bt
#0  0x805c3b22 in fold_marked_statements(int, pointer_set_t*) ()
#1  0x805d258c in optimize_inline_calls(tree_node*) ()
#2  0x80900c82 in inline_transform(cgraph_node*) ()
#3  0x804b7b86 in execute_all_ipa_transforms() ()
#4  0x80234da6 in expand_function(cgraph_node*) ()
#5  0x80236e68 in compile() ()
#6  0x80237460 in finalize_compilation_unit() ()
#7  0x800f3740 in c_write_global_declarations() ()
#8  0x80568694 in compile_file() ()
#9  0x8056a84c in toplev_main(int, char**) ()
#10 0x03fffdc99088 in __libc_start_main (main=0x800d53ac ,
argc=, 
ubp_av=0x3fff258, init=, fini=0x809ee1f8
<__libc_csu_fini>, 
rtld_fini=0x3fffdfed8f4 <_dl_fini>, stack_end=0x3fff1a0) at
libc-start.c:226
#11 0x800d5412 in _start ()

[Bug bootstrap/57603] Bootstrap fail on s390x segfault in fold_marked_statements

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57603

--- Comment #1 from Andreas Krebbel  ---
The failure above was observed with r200057. Here the cc1 output:

cc1 -fpreprocessed -quiet -march=z9-109  -O1 t.c

t.c: In function ‘d_append_string’:
t.c:22:38: warning: incompatible implicit declaration of built-in function
‘strlen’ [enabled by default]
 d_append_buffer (dpi, s, strlen (s));
  ^
t.c: In function ‘d_demangle_callback’:
t.c:41:102: warning: incompatible implicit declaration of built-in function
‘strlen’ [enabled by default]
 else if ((__extension__ (__builtin_constant_p (8) &&
((__builtin_constant_p (mangled) && strlen (mangled) < ((size_t) (8))) ||
(__builtin_constant_p ("_GLOBAL_") && strlen ("_GLOBAL_") < ((size_t) (8 ?
__extension__ ({
   
  ^
t.c: In function ‘__gcclibcxx_demangle_callback’:
t.c:60:15: internal compiler error: Segmentation fault
   int __gcclibcxx_demangle_callback (const char *mangled_name,
   void (*callback) (const char *, size_t, void *),
   void *opaque) {
   ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug bootstrap/57604] New: LRA related bootstrap comparison failure on s390x --with-arch=zEC12

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57604

Bug ID: 57604
   Summary: LRA related bootstrap comparison failure on s390x
--with-arch=zEC12
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org

Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap comparison failure!
gcc/tree-ssa-loop-im.o differs

stage2:

.align2
.type_ZZN19ref_always_accessedclEP11mem_ref_locE12__FUNCTION__, @object
.size_ZZN19ref_always_accessedclEP11mem_ref_locE12__FUNCTION__, 11
_ZZN19ref_always_accessedclEP11mem_ref_locE12__FUNCTION__:
.string"operator()"

stage3:

.align2
.type_ZZN19ref_always_accessedclEP11mem_ref_locE12__FUNCTION__, @object
.size_ZZN19ref_always_accessedclEP11mem_ref_locE12__FUNCTION__, 12
_ZZN19ref_always_accessedclEP11mem_ref_locE12__FUNCTION__:
.string"operator ()"


Be aware of the additional blank in the string. This does not happen when
disabling LRA for bootstrap.

[Bug bootstrap/57604] LRA related bootstrap comparison failure on s390x --with-arch=zEC12

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57604

--- Comment #1 from Andreas Krebbel  ---
This is caused by a miscompilation of cp/lex.c:

#define DEF_OPERATOR(NAME, CODE, MANGLING, ARITY, ASSN_P)\
  sprintf (buffer, ISALPHA (NAME[0]) ? "operator %s" : "operator%s", NAME); \
  identifier = get_identifier (buffer);\
...

The problem is that during LRA an add insn is being generated which is placed
between the "ISALPHA" check and the conditional load for the format string. 
The ADD which is generated clobbers the condition code why DSE later removes
the "ISALPHA" check completely.

When generating the ADD LRA probably needs to check whether it will break
dataflow. On S/390 we can do such address calculations without clobbering CC by
using the load address instruction. Unfortunately la cannot be used for generic
add patterns when generating 32 bit code since it only deals with the lower 31
bits.

Breakpoint 1, make_insn_raw (pattern=0x3fff6195580) at
/home/andreas/clean/gcc-head/gcc/emit-rtl.c:3651
3651  insn = rtx_alloc (INSN);
(gdb) p debug_rtx(pattern)
(parallel [
(set (reg:DI 3022)
(plus:DI (reg/f:DI 34 %fp)
(const_int 176 [0xb0])))
(clobber (reg:CC 33 %cc))
])
$1 = void
(gdb) bt
#0  make_insn_raw (pattern=0x3fff6195580) at
/home/andreas/clean/gcc-head/gcc/emit-rtl.c:3651
#1  0x805b4578 in emit_insn (x=0x3fff6195580) at
/home/andreas/clean/gcc-head/gcc/emit-rtl.c:4736
#2  0x807d5e74 in lra_emit_add (x=0x3fff7a079c0, y=0x3fff78754c0,
z=0x3fff632a630) at /home/andreas/clean/gcc-head/gcc/lra.c:266
#3  0x807d656e in lra_emit_move (x=0x3fff7a079c0, y=0x3fff6199600) at
/home/andreas/clean/gcc-head/gcc/lra.c:415
#4  0x807eb7fa in curr_insn_transform() ()
#5  0x807ed45c in lra_constraints(bool) ()
#6  0x807dc616 in lra (f=0x816a46f0) at
/home/andreas/clean/gcc-head/gcc/lra.c:2278
#7  0x807845a6 in do_reload () at
/home/andreas/clean/gcc-head/gcc/ira.c:4641
#8  0x8078485e in rest_of_handle_reload () at
/home/andreas/clean/gcc-head/gcc/ira.c:4753
#9  0x8085a4b2 in execute_one_pass (pass=0x81359060 ) at
/home/andreas/clean/gcc-head/gcc/passes.c:2337
#10 0x8085a76a in execute_pass_list (pass=0x81359060 ) at
/home/andreas/clean/gcc-head/gcc/passes.c:2389
#11 0x8085a7b8 in execute_pass_list (pass=0x813597d0
) at /home/andreas/clean/gcc-head/gcc/passes.c:2390
#12 0x804ece5e in expand_function (node=0x3fff62f1130) at
/home/andreas/clean/gcc-head/gcc/cgraphunit.c:1582
#13 0x804ed418 in expand_all_functions () at
/home/andreas/clean/gcc-head/gcc/cgraphunit.c:1686
#14 0x804ee00c in compile () at
/home/andreas/clean/gcc-head/gcc/cgraphunit.c:2020
#15 0x804ee1f0 in finalize_compilation_unit () at
/home/andreas/clean/gcc-head/gcc/cgraphunit.c:2097
#16 0x802667fc in cp_write_global_declarations () at
/home/andreas/clean/gcc-head/gcc/cp/decl2.c:4356
#17 0x80966c06 in compile_file () at
/home/andreas/clean/gcc-head/gcc/toplev.c:558
#18 0x809697e8 in do_compile () at
/home/andreas/clean/gcc-head/gcc/toplev.c:1872
#19 0x809699c4 in toplev_main (argc=32, argv=0x3fff138) at
/home/andreas/clean/gcc-head/gcc/toplev.c:1948
#20 0x004f6a8ec30c in __libc_start_main () from /lib64/libc.so.6
#21 0x801335aa in _start ()
(gdb)

[Bug bootstrap/57609] New: S/390 ESA mode bootstrap failure since r197266

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57609

Bug ID: 57609
   Summary: S/390 ESA mode bootstrap failure since r197266
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org

cc1 -fpreprocessed libgcc2.i -quiet -dumpbase libgcc2.c -mlong-double-128 -mesa
-m31 -march=g5 -auxbase-strip _negdi2.o -g -g -g -O2 -O2 -O2 -Wextra -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -version -fbuilding-libgcc
-fno-stack-protector -fPIC -fvisibility=hidden -o libgcc2.s


Program received signal SIGSEGV, Segmentation fault.
0x70685820 in ?? ()
(gdb) bt
#0  0x70685820 in ?? ()
#1  0x006cc074 in fold_binary_loc(unsigned int, tree_code, tree_node*,
tree_node*, tree_node*) ()
#2  0x00714c20 in fold(tree_node*) ()
#3  0x00537e0c in c_fully_fold_internal(tree_node*, bool, bool*, bool*) ()
#4  0x00538998 in c_fully_fold(tree_node*, bool, bool*) ()
#5  0x004e81ba in build_function_call_vec(unsigned int, tree_node*,
vec*, vec*) ()
#6  0x004fd24e in c_parser_postfix_expression_after_primary(c_parser*, unsigned
int, c_expr) ()
#7  0x004f57e8 in c_parser_postfix_expression(c_parser*) ()
#8  0x004f6b4c in c_parser_unary_expression(c_parser*) ()
#9  0x004fb0ac in c_parser_cast_expression(c_parser*, c_expr*) ()
#10 0x004fb2a6 in c_parser_binary_expression(c_parser*, c_expr*, c_parser_prec)
()
#11 0x004fba44 in c_parser_conditional_expression(c_parser*, c_expr*) ()
#12 0x004fc00c in c_parser_expr_no_commas(c_parser*, c_expr*) ()
#13 0x004fc49c in c_parser_expression(c_parser*) ()
#14 0x004f588a in c_parser_postfix_expression(c_parser*) ()
#15 0x004f6b4c in c_parser_unary_expression(c_parser*) ()
#16 0x004fb0ac in c_parser_cast_expression(c_parser*, c_expr*) ()
#17 0x004fb2a6 in c_parser_binary_expression(c_parser*, c_expr*, c_parser_prec)
()
#18 0x004fba44 in c_parser_conditional_expression(c_parser*, c_expr*) ()
#19 0x004fc00c in c_parser_expr_no_commas(c_parser*, c_expr*) ()
#20 0x004fc49c in c_parser_expression(c_parser*) ()
#21 0x004fc924 in c_parser_expression_conv(c_parser*) ()
#22 0x00505784 in c_parser_statement_after_labels(c_parser*) ()
#23 0x00502528 in c_parser_compound_statement_nostart(c_parser*) ()
#24 0x00502ce0 in c_parser_compound_statement(c_parser*) ()
#25 0x00503936 in c_parser_declaration_or_fndef(c_parser*, bool, bool, bool,
bool, bool, tree_node**)
()
#26 0x005083fc in c_parser_external_declaration(c_parser*) ()
#27 0x00508d02 in c_parse_file() ()
#28 0x0054e950 in c_common_parse_file() ()
#29 0x008e2650 in compile_file() ()
#30 0x008e485a in toplev_main(int, char**) ()
#31 0x7dd008e6 in __libc_start_main (main=0x4aca88 , argc=33,
ubp_av=0x7fffef44, 
init=, fini=0xd11ecc <__libc_csu_fini>, rtld_fini=0x7dfef84c
<_dl_fini>, 
stack_end=0x7fffeed8) at libc-start.c:226
#32 0x004acbd6 in _start ()

[Bug bootstrap/57604] LRA related bootstrap comparison failure on s390x --with-arch=zEC12

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57604

--- Comment #3 from Andreas Krebbel  ---
(In reply to Vladimir Makarov from comment #2)
Thanks! Btw. the Ada and Java bootstraps started failing with enabling LRA for
S/390 (also without --with-arch=...).  I'll wait for a patch for this PR before
having a closer look. Perhaps the fails are related?!

[Bug rtl-optimization/57960] New: LRA ICE building glibc

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57960

Bug ID: 57960
   Summary: LRA ICE building glibc
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org

Testcase extracted from Glibc e_acosl.c:

typedef union
{
  long double value;
  struct
  {
unsigned int w0, w1, w2, w3;
  }
  parts32;
}
ieee854_long_double_shape_type;
static const long double one = 1.0L;
long double
__ieee754_acosl (long double x)
{
  long double z, w;
  int ix;
  ieee854_long_double_shape_type u;

  z = (one - u.value) * 0.5;
  u.parts32.w2 = 0;
  u.parts32.w3 = 0;
  w = z - u.value * u.value;
  return 2.0 * w;

}

builds fine with: cc1 -fpreprocessed  -quiet  -O1 -mno-lra

but with: cc1 -fpreprocessed  -quiet  -O1

t.c: In function ‘__ieee754_acosl’:
t.c:25:1: error: unable to generate reloads for:
 }
 ^
(insn 14 13 16 2 (set (strict_low_part (subreg:SI (reg/v:TI 51 [ u ]) 12))
(const_int 0 [0])) t.c:21 77 {movstrictsi}
 (nil))
t.c:25:1: internal compiler error: in curr_insn_transform, at
lra-constraints.c:2954
0x8051ecb5 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/andreas/patched/gcc-head/gcc/rtl-error.c:109
0x8046895b curr_insn_transform
/home/andreas/patched/gcc-head/gcc/lra-constraints.c:2954
0x804692e1 lra_constraints(bool)
/home/andreas/patched/gcc-head/gcc/lra-constraints.c:3810
0x804577a9 lra(_IO_FILE*)
/home/andreas/patched/gcc-head/gcc/lra.c:2319
0x8040c22b do_reload
/home/andreas/patched/gcc-head/gcc/ira.c:4689
0x8040c22b rest_of_handle_reload
/home/andreas/patched/gcc-head/gcc/ira.c:4801

[Bug rtl-optimization/57963] New: LRA S/390: esa mode failure memcpy-chk

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57963

Bug ID: 57963
   Summary: LRA S/390: esa mode failure memcpy-chk
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org

memcpy-chk with -O2 fails if compiled with lra enabled.
It succeeds with -mno-lra.

With lra an insn storing into the literal pool is being emitted:

ira:

(insn 126 127 129 11 (parallel [
(set (reg/f:SI 60 [ D.1911 ])
(plus:SI (reg/v/f:SI 126 [ buf3 ])
(const_int 14 [0xe])))
(clobber (reg:CC 33 %cc))
])
/build/gcc-head/gcc/testsuite/gcc.c-torture/execute/builtins/memcpy-chk.c:131
297 {*addsi3}
 (expr_list:REG_UNUSED (reg:CC 33 %cc)
(expr_list:REG_EQUIV (const:SI (plus:SI (symbol_ref:SI ("buf1") [flags
0x400]  )
(const_int 14 [0xe])))
(nil

(insn 129 126 135 11 (set (reg/f:SI 261)
(mem/u/c:SI (symbol_ref/u:SI ("*.LC69") [flags 0x2]) [3 S4 A32]))
/build/gcc-head/gcc/testsuite/gcc.c-torture/execute/builtins/memcpy-chk.c:131
68 {*movsi_esa}
 (expr_list:REG_EQUIV (const:SI (plus:SI (symbol_ref:SI ("buf1") [flags
0x400]  )
(const_int 14 [0xe])))
(nil)))


reload:


  126: {r406:SI=r406:SI+0xe;clobber %cc:CC;}
  REG_UNUSED %cc:CC
  REG_EQUIV const(`buf1'+0xe)
Inserting insn reload before:
  829: r406:SI=r126:SI
Inserting insn reload after:
  830: r60:SI=r406:SI

  alt=1,overall=1,losers=0,rld_nregs=0
 Choosing alt 1 in insn 830:  (0) d  (1) d {*movsi_esa}
  alt=1,overall=1,losers=0,rld_nregs=0
 Choosing alt 1 in insn 829:  (0) d  (1) d {*movsi_esa}
  Removing equiv init insn 129 (freq=9944)
  129: r261:SI=[`*.LC69']
  REG_EQUIV const(`buf1'+0xe)
deleting insn with uid = 129.

Changing pseudo 60 in operand 0 of insn 830 on equiv [`*.LC69']
  alt=1,overall=609,losers=1,rld_nregs=1
  alt=2,overall=17,losers=2,rld_nregs=1
  alt=3,overall=0,losers=0,rld_nregs=0
 Choosing alt 3 in insn 830:  (0) R  (1) d {*movsi_esa}


(insn 829 828 126 11 (set (reg/f:SI 7 %r7 [orig:60 D.1911 ] [60])
(reg/v/f:SI 2 %r2 [orig:126 buf3 ] [126]))
/build/gcc-head/gcc/testsuite/gcc.c-torture/execute/
builtins/memcpy-chk.c:131 68 {*movsi_esa}
 (nil))
(insn 126 829 830 11 (parallel [
(set (reg/f:SI 7 %r7 [orig:60 D.1911 ] [60])
(plus:SI (reg/f:SI 7 %r7 [orig:60 D.1911 ] [60])
(const_int 14 [0xe])))
(clobber (reg:CC 33 %cc))
])
/build/gcc-head/gcc/testsuite/gcc.c-torture/execute/builtins/memcpy-chk.c:131
297 {*addsi3}
 (expr_list:REG_EQUIV (const:SI (plus:SI (symbol_ref:SI ("buf1") [flags
0x400]  )
(const_int 14 [0xe])))
(nil)))
(insn 830 126 129 11 (set (mem/u/c:SI (symbol_ref/u:SI ("*.LC69") [flags 0x2])
[3 S4 A32])
(reg/f:SI 7 %r7 [orig:60 D.1911 ] [60]))
/build/gcc-head/gcc/testsuite/gcc.c-torture/execute/builtins/memcpy-chk.c:131
68 {*movsi_esa}
 (expr_list:REG_DEAD (reg/f:SI 7 %r7 [orig:60 D.1911 ] [60])
(nil)))



insn 830 writes to a literal pool slot. The testcase fails with a segfault due
to this.

[Bug rtl-optimization/57960] S/390: LRA ICE building glibc

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57960

Andreas Krebbel  changed:

   What|Removed |Added

 Target||s390x-ibm-linux
   Host||s390x-ibm-linux
Summary|LRA ICE building glibc  |S/390: LRA ICE building
   ||glibc
  Build||s390x-ibm-linux

--- Comment #2 from Andreas Krebbel  ---
(In reply to Marek Polacek from comment #1)
> But this is s390x, right?  (Judging from the movstrictsi.)

Yes.

[Bug bootstrap/57609] S/390 ESA mode bootstrap failure since r197266

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57609

Andreas Krebbel  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Andreas Krebbel  ---
Fixed with r200196
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01114.html

[Bug bootstrap/57609] S/390 ESA mode bootstrap failure since r197266

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57609

Andreas Krebbel  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #3 from Andreas Krebbel  ---
Fixed.

[Bug bootstrap/57603] Bootstrap fail on s390x segfault in fold_marked_statements

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57603

Andreas Krebbel  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #3 from Andreas Krebbel  ---
Closed.

[Bug bootstrap/57603] Bootstrap fail on s390x segfault in fold_marked_statements

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57603

Andreas Krebbel  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Andreas Krebbel  ---
Does not occur with r201325 anymore.

[Bug bootstrap/57604] LRA related bootstrap comparison failure on s390x --with-arch=zEC12

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57604

Andreas Krebbel  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Andreas Krebbel  ---
Fixed with r200227:

2013-06-19  Vladimir Makarov  

PR bootstrap/57604
* lra.c (emit_add3_insn, emit_add2_insn): New functions.
(lra_emit_add): Use the functions.  Add comment about Y as an
address segment.

[Bug middle-end/46399] Missing type promotion for library call argument

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46399

Andreas Krebbel  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #4 from Andreas Krebbel  ---
Closed.

[Bug middle-end/46399] Missing type promotion for library call argument

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46399

Andreas Krebbel  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Andreas Krebbel  ---
Fixed.

[Bug middle-end/46399] Missing type promotion for library call argument

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46399

--- Comment #3 from Andreas Krebbel  ---
Closed.

[Bug rtl-optimization/57559] [4.9 Regression] S/390: ICE with lra

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57559

Andreas Krebbel  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Andreas Krebbel  ---
Cannot be reproduced with r201360 anymore.

[Bug rtl-optimization/57960] S/390: LRA ICE building glibc

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57960

Andreas Krebbel  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Andreas Krebbel  ---
Fixed with r201243

2013-07-25  Vladimir Makarov  

PR rtl-optimization/57960
* lra-constraints.c (process_alt_operands): Use the right mode
when checking strict_low.

2013-07-25  Vladimir Makarov  

PR rtl-optimization/57960
* gcc.target/s390/pr57960.c: New.

[Bug bootstrap/58035] New: LRA: S/390: Ada bootstrap fail

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58035

Bug ID: 58035
   Summary: LRA: S/390: Ada bootstrap fail
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org

Tested with r201329. Ada bootstraps with LRA disabled. When enabling LRA
bootstrap fails with:

xgcc: internal compiler error: Segmentation fault (program gnat1)
0x8000fb75 execute
/home/andreas/clean/gcc-head/gcc/gcc.c:2824
0x8000fe37 do_spec_1
/home/andreas/clean/gcc-head/gcc/gcc.c:4616
0x80013145 process_brace_body
/home/andreas/clean/gcc-head/gcc/gcc.c:5873
0x80013145 handle_braces
/home/andreas/clean/gcc-head/gcc/gcc.c:5787
0x800110b5 do_spec_1
/home/andreas/clean/gcc-head/gcc/gcc.c:5270
0x80013145 process_brace_body
/home/andreas/clean/gcc-head/gcc/gcc.c:5873
0x80013145 handle_braces
/home/andreas/clean/gcc-head/gcc/gcc.c:5787
0x800110b5 do_spec_1
/home/andreas/clean/gcc-head/gcc/gcc.c:5270
0x800103fb do_spec_1
/home/andreas/clean/gcc-head/gcc/gcc.c:5375
0x80013145 process_brace_body
/home/andreas/clean/gcc-head/gcc/gcc.c:5873
0x80013145 handle_braces
/home/andreas/clean/gcc-head/gcc/gcc.c:5787
0x800110b5 do_spec_1
/home/andreas/clean/gcc-head/gcc/gcc.c:5270
0x80013145 process_brace_body
/home/andreas/clean/gcc-head/gcc/gcc.c:5873
0x80013145 handle_braces
/home/andreas/clean/gcc-head/gcc/gcc.c:5787
0x800110b5 do_spec_1
/home/andreas/clean/gcc-head/gcc/gcc.c:5270
0x80012557 do_spec_2
/home/andreas/clean/gcc-head/gcc/gcc.c:4317
0x80013a3b do_spec(char const*)
/home/andreas/clean/gcc-head/gcc/gcc.c:4284
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[7]: *** [s-auxdec.o] Error 4

[Bug middle-end/58335] New: S/390: reload vs lra regression - testcase builtin-in-setjmp

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58335

Bug ID: 58335
   Summary: S/390: reload vs lra regression - testcase
builtin-in-setjmp
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org

The following testcase fails when compiling with LRA enabled and succeeds
without LRA:

FAIL: gcc.c-torture/execute/built-in-setjmp.c execution,  -O1

main:
.LFB1:
.loc 1 16 0
stmg%r6,%r15,48(%r15)
.LCFI2:
larl%r13,.L13
lgr%r14,%r15
aghi%r15,-240
.LCFI3:
aghi%r14,-64
std%f8,0(%r14)
std%f10,8(%r14)
std%f12,16(%r14)
std%f14,24(%r14)
std%f9,32(%r14)
std%f11,40(%r14)
std%f13,48(%r14)
std%f15,56(%r14)
lgr%r11,%r15
.LCFI4:
.loc 1 17 0
aghi%r15,-32
lgr%r2,%r15
aghi%r2,160
stg%r2,160(%r11)
.LVL0:
.loc 1 19 0
larl%r1,.LC1
mvc0(5,%r2),0(%r1)
.loc 1 21 0
larl%r1,buf
la%r3,176(%r11)   176+r11 is stored as framepointer
stg%r3,0(%r1)
larl%r3,.L4
stg%r3,8(%r1)
stg%r15,24(%r1)
stg%r13,32(%r1)
lhi%r1,0
.loc 1 23 0
stg%r2,168(%r11)
j.L5
.LVL1:
.L4:
.loc 1 21 0
lghi%r1,-160
la%r11,0(%r1,%r11)When restoring r11 only 160 is subtracted
lhi%r1,1
.L5:
.loc 1 21 0 is_stmt 0 discriminator 4
ltr%r1,%r1
je.L6
.loc 1 23 0 is_stmt 1
lhi%r0,0
larl%r1,.LC1
lg%r2,168(%r11)   Wrong value loaded here
clst%r1,%r2 segfault here


During LRA the elimination offset for r34 %fp to r11 changes from 160 to 176.
The first insn gets the update but not the second.  From a first glance the
reason appears to be that the insn for "lghi %r1,-160" it self is generated by
a reload using a pseudo register which equals -160. This register does not seem
to get the update after the offset changed.

[Bug rtl-optimization/57963] LRA S/390: esa mode failure memcpy-chk

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57963

Andreas Krebbel  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Andreas Krebbel  ---
Fixed with: http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00091.html