[Bug tree-optimization/64058] [5/6 Regression] Performance degradation after r216304

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com

--- Comment #14 from Jeffrey A. Law  ---
So working on the assumption that full stability for SSA_NAME_VERSION changes
isn't in the cards, I went back to my patch which avoids using SSA_NAME_VERSION
as the tie-breaker given two identical coalescing costs.

I can verify for this BZ that change brings stability to the order in which we
process coalescing candidates with the same cost.  Essentially the tie breaker
becomes which coalescing opportunity is seen first during the coalescer's walk
of the IL.

That's fine and good, but as we know only addresses half the problem.  It does
not address whether or not adjustments need to be made to the costing mechanism
itself or whether we can come up with a better tie breaker.

For this BZ, using the referenced trunk versions these are the key coalescings
in the chain.
r216303:
(4004) _1 <-> _316
(3276) _1 <-> _200
(3276) u1_lsm.6_253 <-> _316

Coalesce list: (1)_1 & (316)_316 [map: 0, 98] : Success -> 0
Coalesce list: (1)_1 & (200)_200 [map: 0, 46] : Success -> 0
Coalesce list: (1)_1 & (253)l1_lsm.7_159 [map: 0, 32] : Fail due to conflict


The successful coalescings and subsequent merging of conflicts cause the 3rd
coalesce to fail (and others).  This is actually what we want for this BZ.

In r216304 we have:
(4004) _315 <-> _316
(3276) u1_lsm.6_253 <-> _316
(3276) _314 <-> _315

Coalesce list: (315)_315 & (316)_316 [map: 97, 98] : Success -> 97
Coalesce list: (253)l1_lsm.7_58 & (316)_315 [map: 4, 97] : Success -> 4
Coalesce list: (314)_314 & (315)l1_lsm.7_58 [map: 96, 4] : Fail due to conflict


Note that the coalescing pairs with cost 3276 are reversed due to
SSA_NAME_VERSION churn.  That allows 253 to coalesce with 316 which in turn
prevents 314 from coalescing with 315 (and other downstream effects).  The net
result of those downstream effects is an unwanted copy.

Looking at the costing metrics, they are strictly based on the edge frequency
and flags where the copy would have to be inserted.

What jumps out to me is that the costing metrics don't look at all at the
conflicts.  When we coalesce two objects, we have to merge their conflicts into
the partition leader.  Essentially each time we coalesce, the resulting
partition leader is going to have a larger conflict list and is less likely to
participate in further coalescing.

That might argue that peeking at the union of the resulting conflicts and
giving higher priority to the one that has a smaller resulting conflict set may
be useful in the cost calculation or as a better tie-breaker.

So going back to r216303 and looking at the original partition conflicts we
have:

Partition 0 (_1 - 1 )
Partition 98 (_316 - 316 )
Partition 46 (_200 - 200 )
Partition 72 (u1_lsm.6_253 - 253 )

Conflict graph:
0: 4, 9, 28, 35, 41, 42, 44, 53, 60, 66, 75, 81, 84, 90, 93, 96, 100, 102

46: 4, 5, 6, 9, 28, 35, 41, 42, 44, 51, 63, 66, 75, 81, 84, 90, 93, 96, 100,
102

72: 4, 9, 28, 35, 44, 55, 67, 74, 75, 78, 84, 85, 90, 93, 96, 102, 108, 110,
111

98: 4, 7, 8, 9, 10, 11, 14, 15, 27, 28, 35, 41, 42, 44, 47, 48, 50, 52, 56, 57,
58, 59, 65, 75, 81, 84, 90, 93, 96, 102

Coalescing _1 and _200 will result in a node with 22 unique conflicts.  
Coalescing _253 and _316 will result in a node with 38 unique conflicts.

So if we used the conflicts sets either directly in the costing model or for
breaking ties and gave preference to coalescings with smaller resulting
conflicts, we'd get the right code for this test.

The question then becomes whether or not that is good in general.

[Bug tree-optimization/68915] [6 Regression] gcc.dg/vect/pr46032.c FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #6 from vries at gcc dot gnu.org ---
[...]
> Can you try out this patch?

It's a bit too much:

XPASS: gcc.dg/vect/pr46032.c scan-tree-dump-not vect "versioning for alias
required"
XPASS: gcc.dg/vect/pr46032.c -flto -ffat-lto-objects  scan-tree-dump-not vect
"versioning for alias required"

Omitting the xfail from the scan-tree-dump-not lets the test pass on
both sparc-sun-solaris2.11 and i386-pc-solaris2.12.

Thanks.
Rainer

[Bug ipa/70161] [4.9/5/6 Regression] fdump-ipa-all-graph causes segfault

[vries at gcc dot gnu.org]

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

--- Comment #1 from vries at gcc dot gnu.org ---
Created attachment 37918
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37918&action=edit
tentative patch

This patch fixes the ICE, and it seems that correct dot files are produced as
well.

[Bug middle-end/70159] missed CSE optimization

[spop at gcc dot gnu.org]

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

--- Comment #7 from Sebastian Pop  ---
(In reply to Andrew Pinski from comment #6)
> Note this is both a hoisting and a sinking issue.
> Hoisting should happen before sinking.
> LLVM looks like it only implements sinking.

You are right: LLVM does sinking very early as part of instcombine: it
transforms the phi nodes after the if into selects over the operands and sinks
the sub and mul after the select.  By the time other redundancy elimination
passes are executed the shape of the code is more difficult to optimize.

[Bug middle-end/70159] missed CSE optimization

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
Note this is both a hoisting and a sinking issue.
Hoisting should happen before sinking.
LLVM looks like it only implements sinking.

[Bug middle-end/70159] missed CSE optimization

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
Related to 5738.

Try with -Os and you will see the RTL non PRE based GCSE does most of the job:
foo_p:
fmovs4, 1.0e+0
fdivs0, s4, s0
fsubs1, s1, s3
fsubs2, s2, s3
fcmpe   s0, #0.0
blt .L6
fmuls4, s1, s0
fmuls0, s2, s0
.L4:
fadds0, s4, s0
ret
.L6:
fmuls4, s2, s0
fmuls0, s1, s0
b   .L4

[Bug middle-end/70159] missed CSE optimization

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
Oh and bug 23286.

[Bug middle-end/70159] missed CSE optimization

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
"Related to bug 5738."

[Bug middle-end/70159] missed CSE optimization

[spop at gcc dot gnu.org]

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

--- Comment #2 from Sebastian Pop  ---
Right, with -Ofast it be able to optimize away the branch or selects.
The original benchmark had something more complex than fadd to use the tmin and
tmax results. Here is one more test using the results in a non commutative
operation:

bool foo_p(float d, float min, float max, float a)
{
  float tmin;
  float tmax;

  float inv = 1.0f / d;
  if (inv >= 0) {
tmin = (min - a) * inv;
tmax = (max - a) * inv;
  } else {
tmin = (max - a) * inv;
tmax = (min - a) * inv;
  }

  return tmax > tmin;
}

[Bug middle-end/69040] cris allmodconfig fails

[hp at gcc dot gnu.org]

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

--- Comment #14 from Hans-Peter Nilsson  ---
Created attachment 37917
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37917&action=edit
Reduced ldm.i

For cris-elf, repeat with "./cc1 -fpreprocessed -march=v10 -Os
-fno-strict-aliasing -fno-delete-null-pointer-checks -fno-omit-frame-pointer
-fno-inline-functions-called-once"

[Bug ipa/70161] [4.9/5/6 Regression] fdump-ipa-all-graph causes segfault

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |6.0
Summary|fdump-ipa-all-graph causes  |[4.9/5/6 Regression]
   |segfault|fdump-ipa-all-graph causes
   ||segfault
   Keywords||ice-on-valid-code

[Bug target/69040] cris allmodconfig fails

[hp at gcc dot gnu.org]

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

--- Comment #13 from Hans-Peter Nilsson  ---
(In reply to Hans-Peter Nilsson from comment #12)

Sorry for the double comments, looks like I have issued with Chrome on top of
all.

[Bug target/69040] cris allmodconfig fails

[hp at gcc dot gnu.org]

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

--- Comment #12 from Hans-Peter Nilsson  ---
(In reply to Sudip from comment #10)
> So you are suggesting to bisect trunk and
> build gcc and then use that gcc to compile cris allmodconfig to see if that
> bisect was good or bad?

That's what I'll eventually do as a first low-human-effort step.
I'm *not* asking for you or anyone else to do this!

(And each step will use a reduced ldm.i that I'm about to attach, to speed
things up, not a complete kernel build, but naturally the latter once to
confirm that the bug is fixed.)

[Bug ipa/70161] New: fdump-ipa-all-graph causes segfault

[vries at gcc dot gnu.org]

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

Bug ID: 70161
   Summary: fdump-ipa-all-graph causes segfault
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

...
$ gcc hello.c -fdump-ipa-all-graph
hello.c: In function ‘main’:
hello.c:4:1: internal compiler error: Segmentation fault
 main (void)
 ^~~~
0xf5c9f4 crash_signal
src/gcc/toplev.c:335
0xd8dbb3 execute_function_dump
src/gcc/passes.c:1759
0xd8d6a1 do_per_function
src/gcc/passes.c:1645
0xd8ed73 execute_one_ipa_transform_pass
src/gcc/passes.c:2217
0xd8ee15 execute_all_ipa_transforms()
src/gcc/passes.c:2243
0x911fb2 cgraph_node::expand()
src/gcc/cgraphunit.c:1966
0x912a4c output_in_order
src/gcc/cgraphunit.c:2211
0x913118 symbol_table::compile()
src/gcc/cgraphunit.c:2459
0x913357 symbol_table::finalize_compilation_unit()
src/gcc/cgraphunit.c:2555
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
...

With gdb, we see the cause of the sigsegv:
...
Program received signal SIGSEGV, Segmentation fault.
0x00d8dbb3 in execute_function_dump (fn=0x7619f738, data=0x0) at
/home/vries/gcc_versions/devel/release-branches/trunk/src/gcc/passes.c:1759
1759  if (!pass->graph_dump_initialized)
(gdb) p pass
$1 = (opt_pass *) 0x0
(gdb) p current_pass.name
$5 = 0x24f6970 "inline"
...

[Bug target/69040] cris allmodconfig fails

[hp at gcc dot gnu.org]

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

--- Comment #11 from Hans-Peter Nilsson  ---
(In reply to Sudip from comment #10)
> So you are suggesting to bisect trunk and
> build gcc and then use that gcc to compile cris allmodconfig to see if that
> bisect was good or bad?

That's what I'll eventually do as a first low-human-effort step.
I'm *not* asking for you or anyone else to do this!

(And each step will use a reduced ldm.i that I'm about to attach, to speed
things up, not a complete kernel build, but naturally the latter once to
confirm that the bug is fixed.)

[Bug target/69040] cris allmodconfig fails

[sudipm.mukherjee at gmail dot com]

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

--- Comment #10 from Sudip  ---
(In reply to Hans-Peter Nilsson from comment #9)
> Sorry, this is a reload bug and I can't give it my undivided attention
> within the coming month.
> 
 
> My top-of-the-head solution hypothesis (i.e. what I'd try first) is to
> bisect trunk to see what commit there fixed or hid this problem there
> (assuming it had this problem when the gcc-5-branch was cut), and if it's a
> fix rather than unrelated, ask for a back-port.

Sorry, could not reply earlier. So you are suggesting to bisect trunk and build
gcc and then use that gcc to compile cris allmodconfig to see if that bisect
was good or bad?

regards
sudip

[Bug tree-optimization/68915] [6 Regression] gcc.dg/vect/pr46032.c FAILs

[vries at gcc dot gnu.org]

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

--- Comment #6 from vries at gcc dot gnu.org ---
Created attachment 37916
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37916&action=edit
tentative patch, marking failures as xfails

Rainer,

Can you try out this patch?

Thanks,
- Tom

[Bug target/69040] cris allmodconfig fails

[hp at gcc dot gnu.org]

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

--- Comment #9 from Hans-Peter Nilsson  ---
Sorry, this is a reload bug and I can't give it my undivided attention within
the coming month.

Reload ties itself in a knot and calls back into the movdi expander asking it
to reload a in=(reg:DI 11 r11) out=(mem/j:DI (reg/f:SI 17 mof [749]) [0
_798->from+0 S8 A8]).

I have that much gcc experience that I'm reasonably confident that this is not
a target bug: all the bits are in place for reload to see that that register 16
(mof) is a special register and cannot be used in an address (in a memory
operation; a random bit-pattern like a temporary storage for an address is ok).

My top-of-the-head solution hypothesis (i.e. what I'd try first) is to bisect
trunk to see what commit there fixed or hid this problem there (assuming it had
this problem when the gcc-5-branch was cut), and if it's a fix rather than
unrelated, ask for a back-port.

[Bug target/69988] libgo.so: undefined reference to `__unorddf2'

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #12 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #11)
> (In reply to John Paul Adrian Glaubitz from comment #10)
> > I'm trying this now:
> 
> This seems to have helped for libgo. I'm still having this issue with
> libjava though, so I need some more fiddling, but I'm getting there.

Well, it didn't help. libgo still fails. I just overlooked it this time.

[Bug c++/61414] enum class bitfield size-checking failure

[quanxunzhen at gmail dot com]

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

Xidorn Quan  changed:

   What|Removed |Added

 CC||quanxunzhen at gmail dot com

--- Comment #5 from Xidorn Quan  ---
It seems G++ always throw that warning for enum class as bitfield, even when
the enum class is actually empty:
> enum class K {};
> struct S {
>   K v : 5;
> };

G++ would give:
> test.cpp:3:9: warning: 'S::v' is too small to hold all values of 'enum class 
> K'
>K v : 5;

[Bug target/69988] libgo.so: undefined reference to `__unorddf2'

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #11 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #10)
> I'm trying this now:

This seems to have helped for libgo. I'm still having this issue with libjava
though, so I need some more fiddling, but I'm getting there.

[Bug c++/67376] [5/6 regression] Comparison with pointer to past-the-end of array fails inside constant expression

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
  Known to fail||5.3.0, 6.0

--- Comment #15 from Martin Sebor  ---
I'm testing a patch for the remaining issues raised in comment #10.

[Bug fortran/69520] Implement reversal of -fcheck options

[jvdelisle at gcc dot gnu.org]

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

--- Comment #7 from Jerry DeLisle  ---
(In reply to Harald Anlauf from comment #6)
> Hi Jerry,
> 
> do you think my suggested patch could be applied before the 6 release?
> 
> Thanks,
> Harald

This is my plan. Just out of town for a few days. Maybe this weekend.

I have reviewed it already and it looks good.

[Bug fortran/68241] [meta-bug] Deferred-length character

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
> Should this depend on PR70040 as well?

Yes, done.

[Bug fortran/70040] [6 Regression] ICE in gimplify.c with deferred-length strings

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Target|x86_64-pc-linux-gnu |
   Priority|P3  |P4
  Known to work||5.3.0
   Host|x86_64-pc-linux-gnu |
 Blocks||68241
  Build|x86_64-pc-linux-gnu |


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241
[Bug 68241] [meta-bug] Deferred-length character

[Bug middle-end/57955] [4.9/5/6 Regression] Uniquization of constants reduces alignment of initializers

[wschmidt at gcc dot gnu.org]

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

--- Comment #15 from Bill Schmidt  ---
I tried implementing Jakub's suggestion to have CONSTANT_ALIGNMENT return 128
for large constructors.  This doesn't fix the r201264 version of the test case,
which still generates fairly horrid code.  The use of CONSTANT_ALIGNMENT in
align_variable causes the destination to receive the 128-bit alignment, but the
constructor itself remains with 32-bit alignment, so the aligned-only lvx
instruction can't be used.

This isn't an area I know much about.  Under what circumstances would it be
safe to modify the alignment of the type of the constructor?

[Bug fortran/70149] Character pointer initialization causes ICE. (F2008)

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
The ICE is due to the gcc_assert in 

svn annotate trans-decl.c
...
 84542 pbrookif (TREE_CODE (length) != INTEGER_CST)
 81764   dnovillo   {
 81764   dnovillo gfc_finish_var_decl (length, sym);
 87187 pbrook gcc_assert (!sym->value);
 81764   dnovillo   }

Removing the gcc_assert allows the code to compile.  There
are no regression caused by the removal.  Given that 87187
was a long time ago, I wonder if the assert makes sense.

[Bug tree-optimization/68915] [6 Regression] gcc.dg/vect/pr46032.c FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

  Attachment #37039|0   |1
is obsolete||

--- Comment #5 from Rainer Orth  ---
Created attachment 37915
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37915&action=edit
pr46032.c.148t.vect

[Bug tree-optimization/68915] [6 Regression] gcc.dg/vect/pr46032.c FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #4 from Rainer Orth  ---
I just noticed that the test still fails: the attached dump has

/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/vect/pr46032.c:40:33: note:
not vectorized: unsupported unaligned load.*pretmp_30[idx_3]
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/vect/pr46032.c:38:9: note:
vectorized 0 loops in function.
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/vect/pr46032.c:30:1: note:
vectorized 0 loops in function.

  Rainer

[Bug c++/65579] [C++11] gcc requires definition of a static constexpr member even though it is not odr-used

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

--- Comment #2 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00593.html

[Bug tree-optimization/70160] [6 Regression] gcc ICE at -O2 (seg fault) and above on valid code on x86_64-linux-gnu

[helloqirun at gmail dot com]

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

--- Comment #2 from Qirun Zhang  ---
(In reply to Jakub Jelinek from comment #1)
> -msse2 is needed too.  Started with r228231.  Can't get rid of the
> uninitialized uses though:
> 
> long long a;
> void foo (void);
> void
> bar (unsigned t, int u, int v, unsigned p)
> {
>   long long x;
>   int i, j = 1;
>   for (t = i; j; )
> {
>   a = x;
>   x = 1 + t;
>   j += u;
>   foo ();
>   if (x == 1)
> return;
> }
> }

In my original test case (not the test case in c#0), the ICE will disappear if
variable i is initialized.

[Bug tree-optimization/70160] [6 Regression] gcc ICE at -O2 (seg fault) and above on valid code on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-09
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |6.0
Summary|gcc ICE at -O2 (seg fault)  |[6 Regression] gcc ICE at
   |and above on valid code on  |-O2 (seg fault) and above
   |x86_64-linux-gnu|on valid code on
   ||x86_64-linux-gnu
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
-msse2 is needed too.  Started with r228231.  Can't get rid of the
uninitialized uses though:

long long a;
void foo (void);
void
bar (unsigned t, int u, int v, unsigned p)
{
  long long x;
  int i, j = 1;
  for (t = i; j; )
{
  a = x;
  x = 1 + t;
  j += u;
  foo ();
  if (x == 1)
return;
}
}

[Bug middle-end/70127] [6 Regression] wrong code on x86_64-linux-gnu at -O3 in 32-bit and 64-bit modes

[jamborm at gcc dot gnu.org]

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

--- Comment #11 from Martin Jambor  ---
(In reply to Jakub Jelinek from comment #3)
> Looking at the tree dumps, I see weirdo behavior in early SRA (CCing
> Martin), where it changes:
>   e.f = 1;
>   e.g = 1;
>   a[0] = c;
>   e = a[0];
>   d = e;
>   e ={v} {CLOBBER};
> into:
>   e$f_4 = 1;
>   e$g_18 = 1;
>   a[0] = c;
>   e = a[0];
>   e$f_17 = MEM[(struct S[1] *)&a];
>   e$g_19 = MEM[(struct S[1] *)&a].g;
>   MEM[(struct S *)&e] = e$f_17;
>   e.g = e$g_19;
>   d = e;
>   e ={v} {CLOBBER};
> (the weird thing is that e = a[0] assignment remains, and then it is done
> once again for each element).
> 

Well, e has size 64 bits and the replacements created for it have 32
and 2 bits respectively and so in the simple SRA reprezentation of
things, there are 30 bits that are not covered by the replacements and
because the copy statement e = a[0] stores 64 bits, it thinks there
are so called "unscalarized data."  When that happens, SRA does not
remove original aggregate assignments.

While it seems that it should be trivial to tell SRA that it is just a
padding, it is not, because SRA (with the exception of total
scalarization) does not look at the type of aggregates but builds up a
map of stored data from load and store statements in the function
instead, which works much better in presence of unions,
VIEW_CONVERT_EXPRs and MEM_REFs (that is also the reason why total
scalarization is quite a bit of an alien concept that does not fit
into the scheme very well).  In the absence of unions,
VIEW_CONVERT_EXPRs or MEM_REFs, it should still be reasonably doable
though.

[Bug middle-end/70159] missed CSE optimization

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Well, as tmax + tmin is commutative, this one actually should be optimized into
just (min - a) * inv + (max - a) * inv or with -Ofast perhaps to (min - a + max
- a) * inv.

[Bug tree-optimization/70160] New: gcc ICE at -O2 (seg fault) and above on valid code on x86_64-linux-gnu

[helloqirun at gmail dot com]

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

Bug ID: 70160
   Summary: gcc ICE at -O2 (seg fault) and above on valid code on
x86_64-linux-gnu
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: helloqirun at gmail dot com
  Target Milestone: ---

The following valid code causes an ICE when compiled with the current gcc trunk
at -O2 and above on x86_64-linux-gnu in 32-bit mode.

The 64-bit mode works fine. It should be a 6 regression.

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20160309 (experimental) [trunk revision 234083] (GCC)




$ gcc-trunk -c -O2 abc.c
$ gcc-trunk -c -O2 abc.c -m32
abc.c: In function 'fn2':
abc.c:19:1: internal compiler error: Segmentation fault
 }
 ^
0xb5a51f crash_signal
../../gcc/gcc/toplev.c:335
0xaf9d0b volatile_refs_p(rtx_def const*)
../../gcc/gcc/rtlanal.c:2555
0xaf9df1 volatile_refs_p(rtx_def const*)
../../gcc/gcc/rtlanal.c:2594
0x11d3c93 deletable_insn_p_1
../../gcc/gcc/dce.c:84
0x11d4e90 prescan_insns_for_dce
../../gcc/gcc/dce.c:639
0x11d5449 fast_dce
../../gcc/gcc/dce.c:1052
0x11d60e4 rest_of_handle_fast_dce
../../gcc/gcc/dce.c:1147
0x11d61f8 run_fast_df_dce()
../../gcc/gcc/dce.c:1195
0x7b57d8 df_lr_finalize
../../gcc/gcc/df-problems.c:1018
0x7ae2bd df_analyze_problem(dataflow*, bitmap_head*, int*, int)
../../gcc/gcc/df-core.c:1183
0x7ae378 df_analyze_1
../../gcc/gcc/df-core.c:1234
0x122c1da if_convert
../../gcc/gcc/ifcvt.c:5308
0x122de4d execute
../../gcc/gcc/ifcvt.c:5513
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.




$ cat abc.c
long long a;
void fn1();
void fn2(t, a_int, x0, p) unsigned t;
int a_int;
int x0;
unsigned p;
{
  long long x;
  int i, j = 1;
  t = i;
  for (; j;) {
a = x;
x = 1 + t;
j += a_int;
fn1();
if (x == 1)
  return;
  }
}

[Bug fortran/68241] [meta-bug] Deferred-length character

[mar...@mpa-garching.mpg.de]

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

Martin Reinecke  changed:

   What|Removed |Added

 CC||mar...@mpa-garching.mpg.de

--- Comment #1 from Martin Reinecke  ---
Should this depend on PR70040 as well?

[Bug middle-end/70159] New: missed CSE optimization

[spop at gcc dot gnu.org]

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

Bug ID: 70159
   Summary: missed CSE optimization
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: spop at gcc dot gnu.org
  Target Milestone: ---

$ cat h.c
float foo_p(float d, float min, float max, float a)
{
  float tmin;
  float tmax;

  float inv = 1.0f / d;
  if (inv >= 0) {
tmin = (min - a) * inv;
tmax = (max - a) * inv;
  } else {
tmin = (max - a) * inv;
tmax = (min - a) * inv;
  }

  return tmax + tmin;
}

$ gcc h.c -Ofast -S -o- 
foo_p:
fmovs4, 1.0e+0
fdivs0, s4, s0
fcmpe   s0, #0.0
blt .L6
fsubs1, s1, s3
fsubs2, s2, s3
fmuls1, s1, s0
fmuls0, s2, s0
fadds0, s1, s0
ret
.p2align 3
.L6:
fsubs4, s2, s3
fsubs2, s1, s3
fmuls1, s4, s0
fmuls0, s2, s0
fadds0, s1, s0
ret

$ clang h.c -Ofast -S -o-
foo_p:  // @foo_p
// BB#0:// %entry
fmovs4, #1.
fdivs0, s4, s0
fcmps0, #0.0
fcsel   s4, s1, s2, lt
fcsel   s1, s2, s1, lt
fsubs1, s1, s3
fsubs2, s4, s3
fadds1, s2, s1
fmuls0, s1, s0
ret

The computations in both branches are redundant.
Even without if-conversion (fcsel), GCC should be able to sink/hoist fsub and
fmul.

[Bug target/70155] Use SSE for TImode load/store

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
(In reply to Uroš Bizjak from comment #1)
> This can be tweaked in processor_cost table.

RA will use integer registers for TImode.

> However, is SSE move really faster? Cost tables doesn't say so.

Yes, that is what vector instructions are used for.

[Bug fortran/64324] Deferred character specific functions not permitted in generic operator interface

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #6 from Paul Thomas  ---
Fixed on trunk and 5-branch.

Thanks for the report.

Paul

[Bug fortran/61147] Incorrect behavior using function that returns deferred length character pointer

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #5 from Paul Thomas  ---
Fixed on trunk and 5-branch.

Thanks for the report.

Paul

[Bug fortran/60795] [4.9/5 Regression] Wrong length when allocating character array

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #13 from Paul Thomas  ---
Fixed on trunk and 5-branch.

Thanks for the report.

Paul

[Bug fortran/60593] ICE with deferred length variable in FORALL

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #10 from Paul Thomas  ---
Fixed on trunk and 5-branch.

Thanks for the report.

Paul

[Bug fortran/68241] [meta-bug] Deferred-length character

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241
Bug 68241 depends on bug 54070, which changed state.

Bug 54070 Summary: [4.9/5 Regression] Wrong code with allocatable 
deferred-length (array) function results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54070

   What|Removed |Added

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

[Bug fortran/20585] [meta-bug] Fortran 2003 support

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20585
Bug 20585 depends on bug 54070, which changed state.

Bug 54070 Summary: [4.9/5 Regression] Wrong code with allocatable 
deferred-length (array) function results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54070

   What|Removed |Added

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

[Bug fortran/68241] [meta-bug] Deferred-length character

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241
Bug 68241 depends on bug 49630, which changed state.

Bug 49630 Summary: [OOP] ICE on obsolescent deferred-length type bound 
character function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49630

   What|Removed |Added

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

[Bug fortran/54070] [4.9/5 Regression] Wrong code with allocatable deferred-length (array) function results

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #34 from Paul Thomas  ---
Fixed on trunk and 5-branch.

Thanks for the report.

Paul

[Bug fortran/49630] [OOP] ICE on obsolescent deferred-length type bound character function

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #10 from Paul Thomas  ---
Fixed on trunk and 5-branch.

Thanks for the report.

Paul

[Bug target/69493] Poor code generation for return of struct containing vectors on PPC64LE

[wschmidt at gcc dot gnu.org]

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

--- Comment #4 from Bill Schmidt  ---
I still see the problem with:

GCC: (GNU) 6.0.0 20160309 (experimental) [trunk revision 234085]

[Bug fortran/54070] [4.9/5 Regression] Wrong code with allocatable deferred-length (array) function results

[pault at gcc dot gnu.org]

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

--- Comment #33 from Paul Thomas  ---
Author: pault
Date: Wed Mar  9 20:49:58 2016
New Revision: 234093

URL: https://gcc.gnu.org/viewcvs?rev=234093&root=gcc&view=rev
Log:
2016-03-09  Paul Thomas  

Backport from trunk.
PR fortran/69423
* trans-decl.c (create_function_arglist): Deferred character
length functions, with and without declared results, address
the passed reference type as '.result' and the local string
length as '..result'.
(gfc_null_and_pass_deferred_len): Helper function to null and
return deferred string lengths, as needed.
(gfc_trans_deferred_vars): Call it, thereby reducing repeated
code, add call for deferred arrays and reroute pointer function
results. Avoid using 'tmp' for anything other that a temporary
tree by introducing 'type_of_array' for the arrayspec type.

2016-03-09  Paul Thomas  

Backport from trunk.
PR fortran/64324
* resolve.c (check_uop_procedure): Prevent deferred length
characters from being trapped by assumed length error.

Backport from trunk.
PR fortran/49630
PR fortran/54070
PR fortran/60593
PR fortran/60795
PR fortran/61147
PR fortran/64324
* trans-array.c (gfc_conv_scalarized_array_ref): Pass decl for
function as well as variable expressions.
(gfc_array_init_size): Add 'expr' as an argument. Use this to
correctly set the descriptor dtype for deferred characters.
(gfc_array_allocate): Add 'expr' to the call to
'gfc_array_init_size'.
* trans.c (gfc_build_array_ref): Expand logic for setting span
to include indirect references to character lengths.
* trans-decl.c (gfc_get_symbol_decl): Ensure that deferred
result char lengths that are PARM_DECLs are indirectly
referenced both for directly passed and by reference.
(create_function_arglist): If the length type is a pointer type
then store the length as the 'passed_length' and make the char
length an indirect reference to it.
(gfc_trans_deferred_vars): If a character length has escaped
being set as an indirect reference, return it via the 'passed
length'.
* trans-expr.c (gfc_conv_procedure_call): The length of
deferred character length results is set TREE_STATIC and set to
zero.
(gfc_trans_assignment_1): Do not fix the rse string_length if
it is a variable, a parameter or an indirect reference. Add the
code to trap assignment of scalars to unallocated arrays.
* trans-stmt.c (gfc_trans_allocate): Remove 'def_str_len' and
all references to it. Instead, replicate the code to obtain a
explicitly defined string length and provide a value before
array allocation so that the dtype is correctly set.
trans-types.c (gfc_get_character_type): If the character length
is a pointer, use the indirect reference.

2016-03-09  Paul Thomas  

Backport from trunk.
PR fortran/69423
* gfortran.dg/deferred_character_15.f90 : New test.

2016-03-09  Paul Thomas  

Backport from trunk.
PR fortran/49630
* gfortran.dg/deferred_character_13.f90: New test for the fix
of comment 3 of the PR.

Backport from trunk.
PR fortran/54070
* gfortran.dg/deferred_character_8.f90: New test
* gfortran.dg/allocate_error_5.f90: New test

Backport from trunk.
PR fortran/60593
* gfortran.dg/deferred_character_10.f90: New test

Backport from trunk.
PR fortran/60795
* gfortran.dg/deferred_character_14.f90: New test

Backport from trunk.
PR fortran/61147
* gfortran.dg/deferred_character_11.f90: New test

Backport from trunk.
PR fortran/64324
* gfortran.dg/deferred_character_9.f90: New test


Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_error_5.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_10.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_11.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_12.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_13.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_14.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_15.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_8.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_9.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/resolve.c
branches/gcc-5-branch/gcc/fortran/trans-array.c
branches/gcc-5-branch/gcc/fortran/trans-decl.c
branches/gcc-5-branch/gcc/fortran/trans-exp

[Bug fortran/60795] [4.9/5 Regression] Wrong length when allocating character array

[pault at gcc dot gnu.org]

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

--- Comment #12 from Paul Thomas  ---
Author: pault
Date: Wed Mar  9 20:49:58 2016
New Revision: 234093

URL: https://gcc.gnu.org/viewcvs?rev=234093&root=gcc&view=rev
Log:
2016-03-09  Paul Thomas  

Backport from trunk.
PR fortran/69423
* trans-decl.c (create_function_arglist): Deferred character
length functions, with and without declared results, address
the passed reference type as '.result' and the local string
length as '..result'.
(gfc_null_and_pass_deferred_len): Helper function to null and
return deferred string lengths, as needed.
(gfc_trans_deferred_vars): Call it, thereby reducing repeated
code, add call for deferred arrays and reroute pointer function
results. Avoid using 'tmp' for anything other that a temporary
tree by introducing 'type_of_array' for the arrayspec type.

2016-03-09  Paul Thomas  

Backport from trunk.
PR fortran/64324
* resolve.c (check_uop_procedure): Prevent deferred length
characters from being trapped by assumed length error.

Backport from trunk.
PR fortran/49630
PR fortran/54070
PR fortran/60593
PR fortran/60795
PR fortran/61147
PR fortran/64324
* trans-array.c (gfc_conv_scalarized_array_ref): Pass decl for
function as well as variable expressions.
(gfc_array_init_size): Add 'expr' as an argument. Use this to
correctly set the descriptor dtype for deferred characters.
(gfc_array_allocate): Add 'expr' to the call to
'gfc_array_init_size'.
* trans.c (gfc_build_array_ref): Expand logic for setting span
to include indirect references to character lengths.
* trans-decl.c (gfc_get_symbol_decl): Ensure that deferred
result char lengths that are PARM_DECLs are indirectly
referenced both for directly passed and by reference.
(create_function_arglist): If the length type is a pointer type
then store the length as the 'passed_length' and make the char
length an indirect reference to it.
(gfc_trans_deferred_vars): If a character length has escaped
being set as an indirect reference, return it via the 'passed
length'.
* trans-expr.c (gfc_conv_procedure_call): The length of
deferred character length results is set TREE_STATIC and set to
zero.
(gfc_trans_assignment_1): Do not fix the rse string_length if
it is a variable, a parameter or an indirect reference. Add the
code to trap assignment of scalars to unallocated arrays.
* trans-stmt.c (gfc_trans_allocate): Remove 'def_str_len' and
all references to it. Instead, replicate the code to obtain a
explicitly defined string length and provide a value before
array allocation so that the dtype is correctly set.
trans-types.c (gfc_get_character_type): If the character length
is a pointer, use the indirect reference.

2016-03-09  Paul Thomas  

Backport from trunk.
PR fortran/69423
* gfortran.dg/deferred_character_15.f90 : New test.

2016-03-09  Paul Thomas  

Backport from trunk.
PR fortran/49630
* gfortran.dg/deferred_character_13.f90: New test for the fix
of comment 3 of the PR.

Backport from trunk.
PR fortran/54070
* gfortran.dg/deferred_character_8.f90: New test
* gfortran.dg/allocate_error_5.f90: New test

Backport from trunk.
PR fortran/60593
* gfortran.dg/deferred_character_10.f90: New test

Backport from trunk.
PR fortran/60795
* gfortran.dg/deferred_character_14.f90: New test

Backport from trunk.
PR fortran/61147
* gfortran.dg/deferred_character_11.f90: New test

Backport from trunk.
PR fortran/64324
* gfortran.dg/deferred_character_9.f90: New test


Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_error_5.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_10.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_11.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_12.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_13.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_14.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_15.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_8.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_9.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/resolve.c
branches/gcc-5-branch/gcc/fortran/trans-array.c
branches/gcc-5-branch/gcc/fortran/trans-decl.c
branches/gcc-5-branch/gcc/fortran/trans-exp

[Bug fortran/60593] ICE with deferred length variable in FORALL

[pault at gcc dot gnu.org]

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

--- Comment #9 from Paul Thomas  ---
Author: pault
Date: Wed Mar  9 20:49:58 2016
New Revision: 234093

URL: https://gcc.gnu.org/viewcvs?rev=234093&root=gcc&view=rev
Log:
2016-03-09  Paul Thomas  

Backport from trunk.
PR fortran/69423
* trans-decl.c (create_function_arglist): Deferred character
length functions, with and without declared results, address
the passed reference type as '.result' and the local string
length as '..result'.
(gfc_null_and_pass_deferred_len): Helper function to null and
return deferred string lengths, as needed.
(gfc_trans_deferred_vars): Call it, thereby reducing repeated
code, add call for deferred arrays and reroute pointer function
results. Avoid using 'tmp' for anything other that a temporary
tree by introducing 'type_of_array' for the arrayspec type.

2016-03-09  Paul Thomas  

Backport from trunk.
PR fortran/64324
* resolve.c (check_uop_procedure): Prevent deferred length
characters from being trapped by assumed length error.

Backport from trunk.
PR fortran/49630
PR fortran/54070
PR fortran/60593
PR fortran/60795
PR fortran/61147
PR fortran/64324
* trans-array.c (gfc_conv_scalarized_array_ref): Pass decl for
function as well as variable expressions.
(gfc_array_init_size): Add 'expr' as an argument. Use this to
correctly set the descriptor dtype for deferred characters.
(gfc_array_allocate): Add 'expr' to the call to
'gfc_array_init_size'.
* trans.c (gfc_build_array_ref): Expand logic for setting span
to include indirect references to character lengths.
* trans-decl.c (gfc_get_symbol_decl): Ensure that deferred
result char lengths that are PARM_DECLs are indirectly
referenced both for directly passed and by reference.
(create_function_arglist): If the length type is a pointer type
then store the length as the 'passed_length' and make the char
length an indirect reference to it.
(gfc_trans_deferred_vars): If a character length has escaped
being set as an indirect reference, return it via the 'passed
length'.
* trans-expr.c (gfc_conv_procedure_call): The length of
deferred character length results is set TREE_STATIC and set to
zero.
(gfc_trans_assignment_1): Do not fix the rse string_length if
it is a variable, a parameter or an indirect reference. Add the
code to trap assignment of scalars to unallocated arrays.
* trans-stmt.c (gfc_trans_allocate): Remove 'def_str_len' and
all references to it. Instead, replicate the code to obtain a
explicitly defined string length and provide a value before
array allocation so that the dtype is correctly set.
trans-types.c (gfc_get_character_type): If the character length
is a pointer, use the indirect reference.

2016-03-09  Paul Thomas  

Backport from trunk.
PR fortran/69423
* gfortran.dg/deferred_character_15.f90 : New test.

2016-03-09  Paul Thomas  

Backport from trunk.
PR fortran/49630
* gfortran.dg/deferred_character_13.f90: New test for the fix
of comment 3 of the PR.

Backport from trunk.
PR fortran/54070
* gfortran.dg/deferred_character_8.f90: New test
* gfortran.dg/allocate_error_5.f90: New test

Backport from trunk.
PR fortran/60593
* gfortran.dg/deferred_character_10.f90: New test

Backport from trunk.
PR fortran/60795
* gfortran.dg/deferred_character_14.f90: New test

Backport from trunk.
PR fortran/61147
* gfortran.dg/deferred_character_11.f90: New test

Backport from trunk.
PR fortran/64324
* gfortran.dg/deferred_character_9.f90: New test


Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_error_5.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_10.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_11.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_12.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_13.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_14.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_15.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_8.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_9.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/resolve.c
branches/gcc-5-branch/gcc/fortran/trans-array.c
branches/gcc-5-branch/gcc/fortran/trans-decl.c
branches/gcc-5-branch/gcc/fortran/trans-expr

[Bug fortran/49630] [OOP] ICE on obsolescent deferred-length type bound character function

[pault at gcc dot gnu.org]

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

--- Comment #9 from Paul Thomas  ---
Author: pault
Date: Wed Mar  9 20:49:58 2016
New Revision: 234093

URL: https://gcc.gnu.org/viewcvs?rev=234093&root=gcc&view=rev
Log:
2016-03-09  Paul Thomas  

Backport from trunk.
PR fortran/69423
* trans-decl.c (create_function_arglist): Deferred character
length functions, with and without declared results, address
the passed reference type as '.result' and the local string
length as '..result'.
(gfc_null_and_pass_deferred_len): Helper function to null and
return deferred string lengths, as needed.
(gfc_trans_deferred_vars): Call it, thereby reducing repeated
code, add call for deferred arrays and reroute pointer function
results. Avoid using 'tmp' for anything other that a temporary
tree by introducing 'type_of_array' for the arrayspec type.

2016-03-09  Paul Thomas  

Backport from trunk.
PR fortran/64324
* resolve.c (check_uop_procedure): Prevent deferred length
characters from being trapped by assumed length error.

Backport from trunk.
PR fortran/49630
PR fortran/54070
PR fortran/60593
PR fortran/60795
PR fortran/61147
PR fortran/64324
* trans-array.c (gfc_conv_scalarized_array_ref): Pass decl for
function as well as variable expressions.
(gfc_array_init_size): Add 'expr' as an argument. Use this to
correctly set the descriptor dtype for deferred characters.
(gfc_array_allocate): Add 'expr' to the call to
'gfc_array_init_size'.
* trans.c (gfc_build_array_ref): Expand logic for setting span
to include indirect references to character lengths.
* trans-decl.c (gfc_get_symbol_decl): Ensure that deferred
result char lengths that are PARM_DECLs are indirectly
referenced both for directly passed and by reference.
(create_function_arglist): If the length type is a pointer type
then store the length as the 'passed_length' and make the char
length an indirect reference to it.
(gfc_trans_deferred_vars): If a character length has escaped
being set as an indirect reference, return it via the 'passed
length'.
* trans-expr.c (gfc_conv_procedure_call): The length of
deferred character length results is set TREE_STATIC and set to
zero.
(gfc_trans_assignment_1): Do not fix the rse string_length if
it is a variable, a parameter or an indirect reference. Add the
code to trap assignment of scalars to unallocated arrays.
* trans-stmt.c (gfc_trans_allocate): Remove 'def_str_len' and
all references to it. Instead, replicate the code to obtain a
explicitly defined string length and provide a value before
array allocation so that the dtype is correctly set.
trans-types.c (gfc_get_character_type): If the character length
is a pointer, use the indirect reference.

2016-03-09  Paul Thomas  

Backport from trunk.
PR fortran/69423
* gfortran.dg/deferred_character_15.f90 : New test.

2016-03-09  Paul Thomas  

Backport from trunk.
PR fortran/49630
* gfortran.dg/deferred_character_13.f90: New test for the fix
of comment 3 of the PR.

Backport from trunk.
PR fortran/54070
* gfortran.dg/deferred_character_8.f90: New test
* gfortran.dg/allocate_error_5.f90: New test

Backport from trunk.
PR fortran/60593
* gfortran.dg/deferred_character_10.f90: New test

Backport from trunk.
PR fortran/60795
* gfortran.dg/deferred_character_14.f90: New test

Backport from trunk.
PR fortran/61147
* gfortran.dg/deferred_character_11.f90: New test

Backport from trunk.
PR fortran/64324
* gfortran.dg/deferred_character_9.f90: New test


Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_error_5.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_10.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_11.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_12.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_13.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_14.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_15.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_8.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_9.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/resolve.c
branches/gcc-5-branch/gcc/fortran/trans-array.c
branches/gcc-5-branch/gcc/fortran/trans-decl.c
branches/gcc-5-branch/gcc/fortran/trans-expr

[Bug fortran/61147] Incorrect behavior using function that returns deferred length character pointer

[pault at gcc dot gnu.org]

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

--- Comment #4 from Paul Thomas  ---
Author: pault
Date: Wed Mar  9 20:49:58 2016
New Revision: 234093

URL: https://gcc.gnu.org/viewcvs?rev=234093&root=gcc&view=rev
Log:
2016-03-09  Paul Thomas  

Backport from trunk.
PR fortran/69423
* trans-decl.c (create_function_arglist): Deferred character
length functions, with and without declared results, address
the passed reference type as '.result' and the local string
length as '..result'.
(gfc_null_and_pass_deferred_len): Helper function to null and
return deferred string lengths, as needed.
(gfc_trans_deferred_vars): Call it, thereby reducing repeated
code, add call for deferred arrays and reroute pointer function
results. Avoid using 'tmp' for anything other that a temporary
tree by introducing 'type_of_array' for the arrayspec type.

2016-03-09  Paul Thomas  

Backport from trunk.
PR fortran/64324
* resolve.c (check_uop_procedure): Prevent deferred length
characters from being trapped by assumed length error.

Backport from trunk.
PR fortran/49630
PR fortran/54070
PR fortran/60593
PR fortran/60795
PR fortran/61147
PR fortran/64324
* trans-array.c (gfc_conv_scalarized_array_ref): Pass decl for
function as well as variable expressions.
(gfc_array_init_size): Add 'expr' as an argument. Use this to
correctly set the descriptor dtype for deferred characters.
(gfc_array_allocate): Add 'expr' to the call to
'gfc_array_init_size'.
* trans.c (gfc_build_array_ref): Expand logic for setting span
to include indirect references to character lengths.
* trans-decl.c (gfc_get_symbol_decl): Ensure that deferred
result char lengths that are PARM_DECLs are indirectly
referenced both for directly passed and by reference.
(create_function_arglist): If the length type is a pointer type
then store the length as the 'passed_length' and make the char
length an indirect reference to it.
(gfc_trans_deferred_vars): If a character length has escaped
being set as an indirect reference, return it via the 'passed
length'.
* trans-expr.c (gfc_conv_procedure_call): The length of
deferred character length results is set TREE_STATIC and set to
zero.
(gfc_trans_assignment_1): Do not fix the rse string_length if
it is a variable, a parameter or an indirect reference. Add the
code to trap assignment of scalars to unallocated arrays.
* trans-stmt.c (gfc_trans_allocate): Remove 'def_str_len' and
all references to it. Instead, replicate the code to obtain a
explicitly defined string length and provide a value before
array allocation so that the dtype is correctly set.
trans-types.c (gfc_get_character_type): If the character length
is a pointer, use the indirect reference.

2016-03-09  Paul Thomas  

Backport from trunk.
PR fortran/69423
* gfortran.dg/deferred_character_15.f90 : New test.

2016-03-09  Paul Thomas  

Backport from trunk.
PR fortran/49630
* gfortran.dg/deferred_character_13.f90: New test for the fix
of comment 3 of the PR.

Backport from trunk.
PR fortran/54070
* gfortran.dg/deferred_character_8.f90: New test
* gfortran.dg/allocate_error_5.f90: New test

Backport from trunk.
PR fortran/60593
* gfortran.dg/deferred_character_10.f90: New test

Backport from trunk.
PR fortran/60795
* gfortran.dg/deferred_character_14.f90: New test

Backport from trunk.
PR fortran/61147
* gfortran.dg/deferred_character_11.f90: New test

Backport from trunk.
PR fortran/64324
* gfortran.dg/deferred_character_9.f90: New test


Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_error_5.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_10.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_11.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_12.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_13.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_14.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_15.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_8.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_9.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/resolve.c
branches/gcc-5-branch/gcc/fortran/trans-array.c
branches/gcc-5-branch/gcc/fortran/trans-decl.c
branches/gcc-5-branch/gcc/fortran/trans-expr

[Bug fortran/64324] Deferred character specific functions not permitted in generic operator interface

[pault at gcc dot gnu.org]

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

--- Comment #5 from Paul Thomas  ---
Author: pault
Date: Wed Mar  9 20:49:58 2016
New Revision: 234093

URL: https://gcc.gnu.org/viewcvs?rev=234093&root=gcc&view=rev
Log:
2016-03-09  Paul Thomas  

Backport from trunk.
PR fortran/69423
* trans-decl.c (create_function_arglist): Deferred character
length functions, with and without declared results, address
the passed reference type as '.result' and the local string
length as '..result'.
(gfc_null_and_pass_deferred_len): Helper function to null and
return deferred string lengths, as needed.
(gfc_trans_deferred_vars): Call it, thereby reducing repeated
code, add call for deferred arrays and reroute pointer function
results. Avoid using 'tmp' for anything other that a temporary
tree by introducing 'type_of_array' for the arrayspec type.

2016-03-09  Paul Thomas  

Backport from trunk.
PR fortran/64324
* resolve.c (check_uop_procedure): Prevent deferred length
characters from being trapped by assumed length error.

Backport from trunk.
PR fortran/49630
PR fortran/54070
PR fortran/60593
PR fortran/60795
PR fortran/61147
PR fortran/64324
* trans-array.c (gfc_conv_scalarized_array_ref): Pass decl for
function as well as variable expressions.
(gfc_array_init_size): Add 'expr' as an argument. Use this to
correctly set the descriptor dtype for deferred characters.
(gfc_array_allocate): Add 'expr' to the call to
'gfc_array_init_size'.
* trans.c (gfc_build_array_ref): Expand logic for setting span
to include indirect references to character lengths.
* trans-decl.c (gfc_get_symbol_decl): Ensure that deferred
result char lengths that are PARM_DECLs are indirectly
referenced both for directly passed and by reference.
(create_function_arglist): If the length type is a pointer type
then store the length as the 'passed_length' and make the char
length an indirect reference to it.
(gfc_trans_deferred_vars): If a character length has escaped
being set as an indirect reference, return it via the 'passed
length'.
* trans-expr.c (gfc_conv_procedure_call): The length of
deferred character length results is set TREE_STATIC and set to
zero.
(gfc_trans_assignment_1): Do not fix the rse string_length if
it is a variable, a parameter or an indirect reference. Add the
code to trap assignment of scalars to unallocated arrays.
* trans-stmt.c (gfc_trans_allocate): Remove 'def_str_len' and
all references to it. Instead, replicate the code to obtain a
explicitly defined string length and provide a value before
array allocation so that the dtype is correctly set.
trans-types.c (gfc_get_character_type): If the character length
is a pointer, use the indirect reference.

2016-03-09  Paul Thomas  

Backport from trunk.
PR fortran/69423
* gfortran.dg/deferred_character_15.f90 : New test.

2016-03-09  Paul Thomas  

Backport from trunk.
PR fortran/49630
* gfortran.dg/deferred_character_13.f90: New test for the fix
of comment 3 of the PR.

Backport from trunk.
PR fortran/54070
* gfortran.dg/deferred_character_8.f90: New test
* gfortran.dg/allocate_error_5.f90: New test

Backport from trunk.
PR fortran/60593
* gfortran.dg/deferred_character_10.f90: New test

Backport from trunk.
PR fortran/60795
* gfortran.dg/deferred_character_14.f90: New test

Backport from trunk.
PR fortran/61147
* gfortran.dg/deferred_character_11.f90: New test

Backport from trunk.
PR fortran/64324
* gfortran.dg/deferred_character_9.f90: New test


Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_error_5.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_10.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_11.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_12.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_13.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_14.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_15.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_8.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_9.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/resolve.c
branches/gcc-5-branch/gcc/fortran/trans-array.c
branches/gcc-5-branch/gcc/fortran/trans-decl.c
branches/gcc-5-branch/gcc/fortran/trans-expr

[Bug fortran/69423] [6 Regression] Invalid optimization with deferred-length character

[pault at gcc dot gnu.org]

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

--- Comment #12 from Paul Thomas  ---
Author: pault
Date: Wed Mar  9 20:49:58 2016
New Revision: 234093

URL: https://gcc.gnu.org/viewcvs?rev=234093&root=gcc&view=rev
Log:
2016-03-09  Paul Thomas  

Backport from trunk.
PR fortran/69423
* trans-decl.c (create_function_arglist): Deferred character
length functions, with and without declared results, address
the passed reference type as '.result' and the local string
length as '..result'.
(gfc_null_and_pass_deferred_len): Helper function to null and
return deferred string lengths, as needed.
(gfc_trans_deferred_vars): Call it, thereby reducing repeated
code, add call for deferred arrays and reroute pointer function
results. Avoid using 'tmp' for anything other that a temporary
tree by introducing 'type_of_array' for the arrayspec type.

2016-03-09  Paul Thomas  

Backport from trunk.
PR fortran/64324
* resolve.c (check_uop_procedure): Prevent deferred length
characters from being trapped by assumed length error.

Backport from trunk.
PR fortran/49630
PR fortran/54070
PR fortran/60593
PR fortran/60795
PR fortran/61147
PR fortran/64324
* trans-array.c (gfc_conv_scalarized_array_ref): Pass decl for
function as well as variable expressions.
(gfc_array_init_size): Add 'expr' as an argument. Use this to
correctly set the descriptor dtype for deferred characters.
(gfc_array_allocate): Add 'expr' to the call to
'gfc_array_init_size'.
* trans.c (gfc_build_array_ref): Expand logic for setting span
to include indirect references to character lengths.
* trans-decl.c (gfc_get_symbol_decl): Ensure that deferred
result char lengths that are PARM_DECLs are indirectly
referenced both for directly passed and by reference.
(create_function_arglist): If the length type is a pointer type
then store the length as the 'passed_length' and make the char
length an indirect reference to it.
(gfc_trans_deferred_vars): If a character length has escaped
being set as an indirect reference, return it via the 'passed
length'.
* trans-expr.c (gfc_conv_procedure_call): The length of
deferred character length results is set TREE_STATIC and set to
zero.
(gfc_trans_assignment_1): Do not fix the rse string_length if
it is a variable, a parameter or an indirect reference. Add the
code to trap assignment of scalars to unallocated arrays.
* trans-stmt.c (gfc_trans_allocate): Remove 'def_str_len' and
all references to it. Instead, replicate the code to obtain a
explicitly defined string length and provide a value before
array allocation so that the dtype is correctly set.
trans-types.c (gfc_get_character_type): If the character length
is a pointer, use the indirect reference.

2016-03-09  Paul Thomas  

Backport from trunk.
PR fortran/69423
* gfortran.dg/deferred_character_15.f90 : New test.

2016-03-09  Paul Thomas  

Backport from trunk.
PR fortran/49630
* gfortran.dg/deferred_character_13.f90: New test for the fix
of comment 3 of the PR.

Backport from trunk.
PR fortran/54070
* gfortran.dg/deferred_character_8.f90: New test
* gfortran.dg/allocate_error_5.f90: New test

Backport from trunk.
PR fortran/60593
* gfortran.dg/deferred_character_10.f90: New test

Backport from trunk.
PR fortran/60795
* gfortran.dg/deferred_character_14.f90: New test

Backport from trunk.
PR fortran/61147
* gfortran.dg/deferred_character_11.f90: New test

Backport from trunk.
PR fortran/64324
* gfortran.dg/deferred_character_9.f90: New test


Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_error_5.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_10.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_11.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_12.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_13.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_14.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_15.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_8.f90
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/deferred_character_9.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/resolve.c
branches/gcc-5-branch/gcc/fortran/trans-array.c
branches/gcc-5-branch/gcc/fortran/trans-decl.c
branches/gcc-5-branch/gcc/fortran/trans-exp

[Bug target/70157] Mismatched __float128 load/store

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak  ---
(In reply to H.J. Lu from comment #3)
> (In reply to Uroš Bizjak from comment #2)
> > (In reply to H.J. Lu from comment #1)
> > > It is due to TARGET_SSE_TYPELESS_STORES.
> > 
> > This is by design, movaps/movups is one byte shorter than movdqa/movdqu.
> 
>   movdqu  y(%rip), %xmm0  Shouldn't movups be used here?
>   movups  %xmm0, x(%rip)

No, we only have typeless stores. __float128 is otherwise handled like TImode
move; it is not a vector of SF or DFmode values.

[Bug target/70157] Mismatched __float128 load/store

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
(In reply to Uroš Bizjak from comment #2)
> (In reply to H.J. Lu from comment #1)
> > It is due to TARGET_SSE_TYPELESS_STORES.
> 
> This is by design, movaps/movups is one byte shorter than movdqa/movdqu.

movdqu  y(%rip), %xmm0  Shouldn't movups be used here?
movups  %xmm0, x(%rip)

[Bug c++/69315] [6 Regression] ICE in finish_function with constexpr and templates

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
So, we have a tested patch waiting for review here, right?

[Bug target/70049] [6 Regression] Error: operand size mismatch for `vpextrw' (wrong assembly generated) with -masm=intel

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Fixed.

[Bug tree-optimization/70152] [4.9/5 Regression] gcc ICE at -O3 and above on valid code on x86_64-linux-gnu in "replace_uses_by"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[4.9/5/6 Regression] gcc|[4.9/5 Regression] gcc ICE
   |ICE at -O3 and above on |at -O3 and above on valid
   |valid code on   |code on x86_64-linux-gnu in
   |x86_64-linux-gnu in |"replace_uses_by"
   |"replace_uses_by"   |

--- Comment #4 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug target/70086] [6 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2202 (insn does not satisfy its constraints) with -mavx512vl -ffloat-store

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Fixed.

[Bug middle-end/70127] [6 Regression] wrong code on x86_64-linux-gnu at -O3 in 32-bit and 64-bit modes

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #10 from Jakub Jelinek  ---
Fixed.

[Bug tree-optimization/70152] [4.9/5/6 Regression] gcc ICE at -O3 and above on valid code on x86_64-linux-gnu in "replace_uses_by"

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Wed Mar  9 20:12:19 2016
New Revision: 234092

URL: https://gcc.gnu.org/viewcvs?rev=234092&root=gcc&view=rev
Log:
PR tree-optimization/70152
* tree-sra.c (replace_removed_params_ssa_names): Copy over
SSA_NAME_OCCURS_IN_ABNORMAL_PHI from old_name to new_name.

* gcc.dg/pr70152.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr70152.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-sra.c

[Bug target/70086] [6 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2202 (insn does not satisfy its constraints) with -mavx512vl -ffloat-store

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Wed Mar  9 20:06:59 2016
New Revision: 234091

URL: https://gcc.gnu.org/viewcvs?rev=234091&root=gcc&view=rev
Log:
PR target/70086
* config/i386/i386.md (truncdfsf2 splitter): Use gen_vec_concatv2df
instead of gen_sse2_loadlpd.
* config/i386/sse.md (*vec_concatv2df): Rename to...
(vec_concatv2df): ... this.

* gcc.target/i386/pr70086-1.c: New test.
* gcc.target/i386/pr70086-2.c: New test.
* gcc.target/i386/pr70086-3.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr70086-1.c
trunk/gcc/testsuite/gcc.target/i386/pr70086-2.c
trunk/gcc/testsuite/gcc.target/i386/pr70086-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/70127] [6 Regression] wrong code on x86_64-linux-gnu at -O3 in 32-bit and 64-bit modes

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Wed Mar  9 20:05:40 2016
New Revision: 234090

URL: https://gcc.gnu.org/viewcvs?rev=234090&root=gcc&view=rev
Log:
PR tree-optimization/70127
* fold-const.c (operand_equal_p): Revert the 2015-10-28 change.

* gcc.c-torture/execute/pr70127.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr70127.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug target/70155] Use SSE for TImode load/store

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
This can be tweaked in processor_cost table.

However, is SSE move really faster? Cost tables doesn't say so.

[Bug target/70157] Mismatched __float128 load/store

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
(In reply to H.J. Lu from comment #1)
> It is due to TARGET_SSE_TYPELESS_STORES.

This is by design, movaps/movups is one byte shorter than movdqa/movdqu.

[Bug target/70157] Mismatched __float128 load/store

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-09
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
It is due to TARGET_SSE_TYPELESS_STORES.

[Bug tree-optimization/64058] [5/6 Regression] Performance degradation after r216304

[law at redhat dot com]

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

--- Comment #13 from Jeffrey A. Law  ---
Stabilizing the sort is just one piece in the problem.  SSA_NAME_VERSIONs are
also used as partition numbers.  That doesn't seem to impact code generation
(so far), but it does make dump comparisons bloody difficult to really analyze.

That's what really got me thinking about this problem -- the fact that changes
in the version #s not only affect code generation, but they make it orders of
magnitude harder to evaluate whether or not stabilizing the sort is all that's
needed to address the performance concerns due to gratutious changes in the
dump files.

The result of those ponderings was the idea that changing SSA_NAME_VERSIONs
should have zero impact on the code we generate.  We should be able to hand out
names in a totally arbitrary order and ultimately get the same assembly code.

Reality is somewhat different.  Consider that in various places we canonicalize
expression operands based on SSA_NAME_VERSIONs.  Those can and will get
different code based on SSA_NAME_VERSIONs in use.  ie

if (a_1 == b_2)

if (a_2 == b_1)

Should generate the same assembly code, but won't because the second will get
canonicalized into

if (b_1 == a_2)

And when we convert that to RTL, it'll generate different code than the
original a_1 == b_2 version.

Similar situations occur due to canonicalization that happens during
tree-ssa-reassoc and almost certainly other places.

It's pervasive enough that the goal of "no change in assembly output due to
SSA_NAME_VERSION changes" may not be attainable in the immediate future.

Coming back to 64058 and 68654, it's not clear yet if just stabilizing the sort
is sufficient.  I'm still evaluating that.

FWIW, I've got a variant that just stabilizes the sort with just an index we
record as we find a potential coalescing pair.  That's pretty trivial.  I
started down another path where I added a level of indirection between the
SSA_NAME_VERSION and the associated partition maps.  My worry with the latter
is interactions with tree-ssa-live.c.

[Bug c++/70105] [6 regression] giant warning when building gcc-5 with gcc-6

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #5 from David Malcolm  ---
Should be fixed by r234087+r234088:

r234087: "[PATCH 1/2] PR c++/70105: Defer location expansion until
diagnostic_show_locus"
  https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00583.html


r234088: "[PATCH 2/2] PR c++/70105: prevent nonsensical underline spew for
macro expansions"
  https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00585.html

Additionally verified by rebuildling tree-complex.c, which now emits just:
***
In file included from ./tm.h:27:0,
 from ../../src/gcc/tree-complex.c:23:
../../src/gcc/config/elfos.h:102:21: warning: invalid suffix on literal; C++11
requires a space between literal and string macro [-Wliteral-suffix]
fprintf ((FILE), "%s"HOST_WIDE_INT_PRINT_UNSIGNED"\n",\
 ^
../../src/gcc/config/elfos.h:170:24: warning: invalid suffix on literal; C++11
requires a space between literal and string macro [-Wliteral-suffix]
   fprintf ((FILE), ","HOST_WIDE_INT_PRINT_UNSIGNED",%u\n",  \
^
In file included from ./tm.h:48:0,
 from ../../src/gcc/tree-complex.c:23:
../../src/gcc/defaults.h:126:24: warning: invalid suffix on literal; C++11
requires a space between literal and string macro [-Wliteral-suffix]
   fprintf ((FILE), ","HOST_WIDE_INT_PRINT_UNSIGNED",%u\n",  \
^
In file included from ../../src/gcc/tree-complex.c:57:0:
../../src/gcc/tree-complex.c: In function ‘tree_node*
create_one_component_var(tree, tree, const char*, const char*, tree_code)’:
../../src/gcc/../include/libiberty.h:184:25: warning: operation on
‘libiberty_concat_ptr’ may be undefined [-Wsequence-point]
   (libiberty_concat_ptr = (char *) alloca (concat_length ACONCAT_PARAMS + 1),
\
 ^
../../src/gcc/stringpool.h:39:50: note: in definition of macro ‘get_identifier’
 ? get_identifier_with_length ((str), strlen (str))  \
  ^~~
../../src/gcc/tree-complex.c:473:39: note: in expansion of macro ‘ACONCAT’
   DECL_NAME (r) = get_identifier (ACONCAT ((name, suffix, NULL)));
   ^~~
***


Marking as resolved.

[Bug c++/65579] [C++11] gcc requires definition of a static constexpr member even though it is not odr-used

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
  Known to fail||4.9.3, 5.3.0, 6.0

--- Comment #1 from Martin Sebor  ---
Re-confirmed with today's top of trunk (6.0) and all prior supported versions
that implement constexpr.  See below.

The difference between the template and non-template case is the readonly bit
that's set on the 's' field when S is an ordinary struct.  The bit is clear
when S is a template.  The bit gets set in the c_apply_type_quals_to_decl()
function in c-family/c-common.c called from  the cp_apply_type_quals_to_decl()
function defined in cp/typeck.c.  The latter function executes the following
condition just before calling c_apply_type_quals_to_decl().  COMPLETE_TYPE_P
(type) is false when S is a (specialization of a template), causing the
TYPE_QUAL_CONST to clear.

  /* Avoid setting TREE_READONLY incorrectly.  */
  /* We used to check TYPE_NEEDS_CONSTRUCTING here, but now a constexpr
 constructor can produce constant init, so rely on cp_finish_decl to
 clear TREE_READONLY if the variable has non-constant init.  */

  /* If the type has (or might have) a mutable component, that component
 might be modified.  */
  if (TYPE_HAS_MUTABLE_P (type) || !COMPLETE_TYPE_P (type))
type_quals &= ~TYPE_QUAL_CONST;

  c_apply_type_quals_to_decl (type_quals, decl);

When S is made complete by this point (e.g., by causing S to be
instantiated, say by declaring an object of the type), the bit stays set and
the test program links. 

The c_apply_type_quals_to_decl() function the does the following:

  if ((type_quals & TYPE_QUAL_CONST)
  || (type && TREE_CODE (type) == REFERENCE_TYPE))
/* We used to check TYPE_NEEDS_CONSTRUCTING here, but now a constexpr
   constructor can produce constant init, so rely on cp_finish_decl to
   clear TREE_READONLY if the variable has non-constant init.  */
TREE_READONLY (decl) = 1;

The comments referencing constexpr suggest that TREE_READONLY should perhaps be
set here and then cleared in cp_finish_decl.

$ cat z.c && /home/msebor/build/gcc-trunk-svn/gcc/xgcc
-B/home/msebor/build/gcc-trunk-svn/gcc -Wall -Wextra -Wpedantic -xc++ z.c
template 
struct S {
int i;
};

struct T {
static constexpr S s = { 1 };
};

int main()
{
return T::s.i;
}
/tmp/ccqP3dAP.o: In function `main':
z.c:(.text+0x6): undefined reference to `T::s'
collect2: error: ld returned 1 exit status

[Bug c/68473] ICE: in contains_point, at diagnostic-show-locus.c:340 after error

[dmalcolm at gcc dot gnu.org]

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

--- Comment #15 from David Malcolm  ---
Author: dmalcolm
Date: Wed Mar  9 18:23:27 2016
New Revision: 234088

URL: https://gcc.gnu.org/viewcvs?rev=234088&root=gcc&view=rev
Log:
PR c++/70105: prevent nonsensical underline spew for macro expansions

diagnostic_show_locus can sometimes do the wrong thing when handling
expressions built up from macros.

PR c++/70105 (currently marked as a P3 regression) has an example of
a diagnostic where over 500 lines of irrelevant source are printed,
and underlined, giving >1000 lines of useless spew to stderr.

This patch adds extra sanitization to diagnostic-show-locus.c, so that
we only attempt to print underlines and secondary locations if such
locations are "sufficiently sane" relative to the primary location
of a diagnostic.

This "sufficiently sane" condition is implemented by a new helper
function compatible_locations_p, which requires such locations to
have the same macro expansion hierarchy as the primary location,
using linemap_macro_map_loc_unwind_toward_spelling, effectively
mimicing the expansion performed by LRK_SPELLING_LOCATION.

This may be too strong a condition, but it effectively fixes
PR c++/70105, without removing any underlines in my testing.

Successfully bootstrapped®rtested in combination with the previous
patch on x86_64-pc-linux-gnu; adds 15 new PASS results to g++.sum
and 4 new PASS results to gcc.sum.

gcc/ChangeLog:
PR c/68473
PR c++/70105
* diagnostic-show-locus.c (compatible_locations_p): New function.
(layout::layout): Sanitize ranges using compatible_locations_p.

gcc/testsuite/ChangeLog:
PR c/68473
PR c++/70105
* g++.dg/diagnostic/pr70105.C: New test.
* gcc.dg/plugin/diagnostic-test-expressions-1.c (foo): New decl.
(test_multiple_ordinary_maps): New test function.

libcpp/ChangeLog:
PR c/68473
PR c++/70105
* line-map.c (linemap_macro_map_loc_unwind_toward_spelling): Move
decl...
* include/line-map.h
(linemap_macro_map_loc_unwind_toward_spelling): ...here,
converting from static to extern.


Added:
trunk/gcc/testsuite/g++.dg/diagnostic/pr70105.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/diagnostic-show-locus.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/plugin/diagnostic-test-expressions-1.c
trunk/libcpp/ChangeLog
trunk/libcpp/include/line-map.h
trunk/libcpp/line-map.c

[Bug c++/70105] [6 regression] giant warning when building gcc-5 with gcc-6

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm  ---
Author: dmalcolm
Date: Wed Mar  9 18:23:27 2016
New Revision: 234088

URL: https://gcc.gnu.org/viewcvs?rev=234088&root=gcc&view=rev
Log:
PR c++/70105: prevent nonsensical underline spew for macro expansions

diagnostic_show_locus can sometimes do the wrong thing when handling
expressions built up from macros.

PR c++/70105 (currently marked as a P3 regression) has an example of
a diagnostic where over 500 lines of irrelevant source are printed,
and underlined, giving >1000 lines of useless spew to stderr.

This patch adds extra sanitization to diagnostic-show-locus.c, so that
we only attempt to print underlines and secondary locations if such
locations are "sufficiently sane" relative to the primary location
of a diagnostic.

This "sufficiently sane" condition is implemented by a new helper
function compatible_locations_p, which requires such locations to
have the same macro expansion hierarchy as the primary location,
using linemap_macro_map_loc_unwind_toward_spelling, effectively
mimicing the expansion performed by LRK_SPELLING_LOCATION.

This may be too strong a condition, but it effectively fixes
PR c++/70105, without removing any underlines in my testing.

Successfully bootstrapped®rtested in combination with the previous
patch on x86_64-pc-linux-gnu; adds 15 new PASS results to g++.sum
and 4 new PASS results to gcc.sum.

gcc/ChangeLog:
PR c/68473
PR c++/70105
* diagnostic-show-locus.c (compatible_locations_p): New function.
(layout::layout): Sanitize ranges using compatible_locations_p.

gcc/testsuite/ChangeLog:
PR c/68473
PR c++/70105
* g++.dg/diagnostic/pr70105.C: New test.
* gcc.dg/plugin/diagnostic-test-expressions-1.c (foo): New decl.
(test_multiple_ordinary_maps): New test function.

libcpp/ChangeLog:
PR c/68473
PR c++/70105
* line-map.c (linemap_macro_map_loc_unwind_toward_spelling): Move
decl...
* include/line-map.h
(linemap_macro_map_loc_unwind_toward_spelling): ...here,
converting from static to extern.


Added:
trunk/gcc/testsuite/g++.dg/diagnostic/pr70105.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/diagnostic-show-locus.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/plugin/diagnostic-test-expressions-1.c
trunk/libcpp/ChangeLog
trunk/libcpp/include/line-map.h
trunk/libcpp/line-map.c

[Bug c/68473] ICE: in contains_point, at diagnostic-show-locus.c:340 after error

[dmalcolm at gcc dot gnu.org]

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

--- Comment #14 from David Malcolm  ---
Author: dmalcolm
Date: Wed Mar  9 18:14:43 2016
New Revision: 234087

URL: https://gcc.gnu.org/viewcvs?rev=234087&root=gcc&view=rev
Log:
PR c++/70105: Defer location expansion until diagnostic_show_locus

gcc/ChangeLog:
PR c/68473
PR c++/70105
* diagnostic-show-locus.c (layout_range::layout_range): Replace
location_range param with three const expanded_locations * and a
bool.
(layout::layout): Replace call to
rich_location::lazily_expand_location with get_expanded_location.
Extract the range and perform location expansion here, passing
the results to the layout_range ctor.
* diagnostic.c (source_range::debug): Delete.
* diagnostic.h (diagnostic_expand_location): Reimplement in terms
of rich_location::get_expanded_location.
* gcc-rich-location.c (get_range_for_expr): Delete.
(gcc_rich_location::add_expr): Reimplement to avoid the
rich_location::add_range overload that took a location_range,
passing a location_t instead.

gcc/testsuite/ChangeLog:
PR c/68473
PR c++/70105
* gcc.dg/plugin/diagnostic_plugin_show_trees.c (show_tree):
Drop range information from call to inform_at_rich_loc.
* gcc.dg/plugin/diagnostic_plugin_test_show_locus.c (add_range):
New.
(test_show_locus): Replace calls to rich_location::add_range with
calls to add_range.  Rewrite the tests that used the now-defunct
rich_location ctor taking a source_range.  Simplify other tests
by replacing calls to COMBINE_LOCATION_DATA with calls to
make_location.

libcpp/ChangeLog:
PR c/68473
PR c++/70105
* include/line-map.h (source_range::debug): Delete.
(struct location_range): Update comment.  Replace
expanded_location fields "m_start", "m_finish", and "m_caret" with
a source_location field: "m_loc".
(class rich_location): Reword comment.
(rich_location::get_loc): Reimplement in terms of a new overloaded
variant which takes an unsigned int.
(rich_location::get_loc_addr): Delete.
(rich_location::add_range): Drop params "start" and "finish" in
favor of param "loc".  Drop overloaded variants taking a
source_range or location_range *.
(rich_location::lazily_expand_location): Delete in favor of...
(rich_location::get_expanded_location): New decl.
(rich_location::m_loc): Delete field.
(rich_location::m_column_override): New field.
* line-map.c (rich_location::rich_location):  Drop name of
line_maps * param.  Update initializations for deletion of field
"m_loc" and addition of field "m_column_override".  Reimplement
body as a call to add_range.  Delete overloaded variant taking a
source_range.
(rich_location::get_loc): New function.
(rich_location::lazily_expand_location): Delete in favor of...
(rich_location::get_expanded_location): New function.
(rich_location::override_column): Reimplement.
(rich_location::add_range): Drop params "start" and "finish" in
favor of param "loc".  Eliminate location expansion in favor of
simply storing loc.  Drop overloaded variants taking a
source_range or location_range *.
(rich_location::set_range): Eliminate location expansion.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/diagnostic-show-locus.c
trunk/gcc/diagnostic.c
trunk/gcc/diagnostic.h
trunk/gcc/gcc-rich-location.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/plugin/diagnostic_plugin_show_trees.c
trunk/gcc/testsuite/gcc.dg/plugin/diagnostic_plugin_test_show_locus.c
trunk/libcpp/ChangeLog
trunk/libcpp/include/line-map.h
trunk/libcpp/line-map.c

[Bug c++/70105] [6 regression] giant warning when building gcc-5 with gcc-6

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
Author: dmalcolm
Date: Wed Mar  9 18:14:43 2016
New Revision: 234087

URL: https://gcc.gnu.org/viewcvs?rev=234087&root=gcc&view=rev
Log:
PR c++/70105: Defer location expansion until diagnostic_show_locus

gcc/ChangeLog:
PR c/68473
PR c++/70105
* diagnostic-show-locus.c (layout_range::layout_range): Replace
location_range param with three const expanded_locations * and a
bool.
(layout::layout): Replace call to
rich_location::lazily_expand_location with get_expanded_location.
Extract the range and perform location expansion here, passing
the results to the layout_range ctor.
* diagnostic.c (source_range::debug): Delete.
* diagnostic.h (diagnostic_expand_location): Reimplement in terms
of rich_location::get_expanded_location.
* gcc-rich-location.c (get_range_for_expr): Delete.
(gcc_rich_location::add_expr): Reimplement to avoid the
rich_location::add_range overload that took a location_range,
passing a location_t instead.

gcc/testsuite/ChangeLog:
PR c/68473
PR c++/70105
* gcc.dg/plugin/diagnostic_plugin_show_trees.c (show_tree):
Drop range information from call to inform_at_rich_loc.
* gcc.dg/plugin/diagnostic_plugin_test_show_locus.c (add_range):
New.
(test_show_locus): Replace calls to rich_location::add_range with
calls to add_range.  Rewrite the tests that used the now-defunct
rich_location ctor taking a source_range.  Simplify other tests
by replacing calls to COMBINE_LOCATION_DATA with calls to
make_location.

libcpp/ChangeLog:
PR c/68473
PR c++/70105
* include/line-map.h (source_range::debug): Delete.
(struct location_range): Update comment.  Replace
expanded_location fields "m_start", "m_finish", and "m_caret" with
a source_location field: "m_loc".
(class rich_location): Reword comment.
(rich_location::get_loc): Reimplement in terms of a new overloaded
variant which takes an unsigned int.
(rich_location::get_loc_addr): Delete.
(rich_location::add_range): Drop params "start" and "finish" in
favor of param "loc".  Drop overloaded variants taking a
source_range or location_range *.
(rich_location::lazily_expand_location): Delete in favor of...
(rich_location::get_expanded_location): New decl.
(rich_location::m_loc): Delete field.
(rich_location::m_column_override): New field.
* line-map.c (rich_location::rich_location):  Drop name of
line_maps * param.  Update initializations for deletion of field
"m_loc" and addition of field "m_column_override".  Reimplement
body as a call to add_range.  Delete overloaded variant taking a
source_range.
(rich_location::get_loc): New function.
(rich_location::lazily_expand_location): Delete in favor of...
(rich_location::get_expanded_location): New function.
(rich_location::override_column): Reimplement.
(rich_location::add_range): Drop params "start" and "finish" in
favor of param "loc".  Eliminate location expansion in favor of
simply storing loc.  Drop overloaded variants taking a
source_range or location_range *.
(rich_location::set_range): Eliminate location expansion.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/diagnostic-show-locus.c
trunk/gcc/diagnostic.c
trunk/gcc/diagnostic.h
trunk/gcc/gcc-rich-location.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/plugin/diagnostic_plugin_show_trees.c
trunk/gcc/testsuite/gcc.dg/plugin/diagnostic_plugin_test_show_locus.c
trunk/libcpp/ChangeLog
trunk/libcpp/include/line-map.h
trunk/libcpp/line-map.c

[Bug fortran/70158] ICE in small Fortran program with OMP and C_PTR

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
> Can you upgrade your version of gfortran and test
> to see if the code compiles for you.  For me, the
> code compiles with 4.9.4, 5.3.1, and 6.0.0

For me too, but I see the ICE with 4.8.5.

[Bug fortran/70158] ICE in small Fortran program with OMP and C_PTR

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-03-09
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
Can you upgrade your version of gfortran and test
to see if the code compiles for you.  For me, the
code compiles with 4.9.4, 5.3.1, and 6.0.0

[Bug fortran/70158] New: ICE in small Fortran program with OMP and C_PTR

[christophe.cous...@meso-star.com]

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

Bug ID: 70158
   Summary: ICE in small Fortran program with OMP and C_PTR
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christophe.cous...@meso-star.com
  Target Milestone: ---

Created attachment 37914
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37914&action=edit
source file used

ICE with the following command line and version.

$ gfortran -fopenmp -std=f2008 -ffree-form bug.f
bug.f: In function ‘compute’:
bug.f:7:0: internal compiler error: Erreur de segmentation
 !$OMP PARALLEL PRIVATE(RNG)
 ^
Please submit a full bug report,
with preprocessed source if appropriate.

$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.8.4-2ubuntu1~14.04.1' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.1)

[Bug tree-optimization/67681] Missed vectorization: induction variable used after loop

[alalaw01 at gcc dot gnu.org]

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

--- Comment #5 from alalaw01 at gcc dot gnu.org ---
In the -DFOO=0 case, we have peeled an extra copy of the inner loop condition,
i <= max_7, above the loop. scalar evolution (final_value_replacement_loop)
works, because it sees the inner loop goes round niter = (unsigned int) max_7 -
(unsigned int) i_25 iterations, and compute_overall_effect_of_inner_loop gives
us

(int) (((unsigned int) i_25 + ((unsigned int) max_7 - (unsigned int) i_25)) +
1)

which is not expression_expensive_p, so we do it. Hence the add/subtract above.

When -DFOO=1, we have not done that peeling, so niter = i_22 <= max_24 ?
(unsigned int) max_24 - (unsigned int) i_22 : 0, and
compute_overall_effect_of_inner_loop gives us

(i_22 + 1) + (i_22 <= max_24 ? (int) ((unsigned int) max_24 - (unsigned int)
i_22) : 0)

which is expression_expensive_p, so we don't do the final value replacement.

[Bug target/70146] missed-optimization: i386 hidden references should use PC32 relocations instead of GOTOFF

[richard at netbsd dot org]

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

Richard PALO  changed:

   What|Removed |Added

 CC||richard at netbsd dot org

--- Comment #2 from Richard PALO  ---
I'm curious if something like this could help certain similar situations
encountered in SunOS as well...

[Bug target/70157] New: Mismatched __float128 load/store

[hjl.tools at gmail dot com]

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

Bug ID: 70157
   Summary: Mismatched __float128 load/store
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
  Target Milestone: ---
Target: x86-64

[hjl@gnu-6 pr70155]$ cat y.i
extern __float128 a, b;

struct foo
{
  __float128 i;
}__attribute__ ((packed));

extern struct foo x, y;

void
foo (void)
{
  a = b;
  x = y;
}
[hjl@gnu-6 pr70155]$ gcc -S y.i -O2
[hjl@gnu-6 pr70155]$ cat y.s
.file   "y.i"
.section.text.unlikely,"ax",@progbits
.LCOLDB0:
.text
.LHOTB0:
.p2align 4,,15
.globl  foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
movdqa  b(%rip), %xmm0
movaps  %xmm0, a(%rip)
movdqu  y(%rip), %xmm0
movups  %xmm0, x(%rip)
ret
.cfi_endproc
.LFE0:
.size   foo, .-foo
.section.text.unlikely
.LCOLDE0:
.text
.LHOTE0:
.ident  "GCC: (GNU) 5.3.1 20160212 (Red Hat 5.3.1-4)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-6 pr70155]$ 

Shouldn't only one of movdqa/movaps (movdqu/movups) used for __float128
load and store?

[Bug tree-optimization/70013] [6 Regression] packed structure tree-sra loses initialization

[alalaw01 at gcc dot gnu.org]

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

--- Comment #10 from alalaw01 at gcc dot gnu.org ---
Hmmm, so this fixes the ICE, generating:

  SR.5_12 = MEM[(struct S0[2] *)&*.LC0].f0;
  MEM[(struct S0[2] *)&*.LC0].f0 = SR.5_12;
  d = *.LC0;
  d$3$f0_14 = MEM[(struct S0[2] *)&*.LC0 + 3B].f0;
  d$0$f0_7 = SR.5_12;
  e$f0_9 = d$3$f0_14;
  _3 = (int) d$0$f0_7;
  c = _3;
  _5 = (int) e$f0_9;
  __builtin_printf ("%x\n", _5);
  d ={v} {CLOBBER};
  return 0;

which in -fdump-tree-optimized (at -O1) looks like:

  SR.5_12 = MEM[(struct S0[2] *)&*.LC0].f0;
  d$3$f0_14 = MEM[(struct S0[2] *)&*.LC0 + 3B].f0;
  _3 = (int) SR.5_12;
  c = _3;
  _5 = (int) d$3$f0_14;
  __builtin_printf ("%x\n", _5);
  return 0;

which is much saner. But I don't really understand why the PARM_DECL case that
I'm adding to here is that way (since r147980 "New implementation of SRA" in
2009, https://gcc.gnu.org/ml/gcc-patches/2009-04/msg02218.html)...

Bootstrapped+regtest on AArch64 (c,c++) and ARM (c,c++,ada), no regressions.
(Constants don't get pushed into the pool on x86.)

diff --git a/gcc/tree-sra.c b/gcc/tree-sra.c
index
72157edd02e3235e57b786bbf460c94b0c52b2c5..24eac6ae7c4dcd41358b1a020047076afe1a8106
100644
--- a/gcc/tree-sra.c
+++ b/gcc/tree-sra.c
@@ -2427,7 +2427,8 @@ analyze_access_subtree (struct access *root, struct
access *parent,

   if (!hole || root->grp_total_scalarization)
 root->grp_covered = 1;
-  else if (root->grp_write || TREE_CODE (root->base) == PARM_DECL)
+  else if (root->grp_write || TREE_CODE (root->base) == PARM_DECL
+  || constant_decl_p (root->base))
 root->grp_unscalarized_data = 1; /* not covered and written to */
   return sth_created;
 }

[Bug target/69493] Poor code generation for return of struct containing vectors on PPC64LE

[wschmidt at gcc dot gnu.org]

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

--- Comment #3 from Bill Schmidt  ---
That's interesting.  We have some other examples of similar issues we should
check as well before closing this.  I'll take a look in a bit.

[Bug c++/70156] New: incorrect "incomplete type" error initializing a static const data member

[msebor at gcc dot gnu.org]

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

Bug ID: 70156
   Summary: incorrect "incomplete type" error initializing a
static const data member
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The two definitions of the data members of class C in the program below are
rejected as a required.  However, the text of only the second diagnostic is
correct.  The text of the first diagnostic is not since the type A<0> is
complete at the point it's used.

$ cat v.c && /home/msebor/build/gcc-trunk-svn/gcc/xgcc
-B/home/msebor/build/gcc-trunk-svn/gcc -Wall -Wextra -Wpedantic -xc++ v.c
template  struct A { int i; };
struct B { int i; };
struct C {
static const A<0> a = { 0 };
static const B b = { 1 };
};
v.c:4:31: error: in-class initialization of static data member ‘const A<0>
C::a’ of incomplete type
 static const A<0> a = { 0 };
   ^
v.c:5:28: error: ‘constexpr’ needed for in-class initialization of static data
member ‘const B C::b’ of non-integral type [-fpermissive]
 static const B b = { 1 };
^

[Bug tree-optimization/67681] Missed vectorization: induction variable used after loop

[alalaw01 at gcc dot gnu.org]

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

--- Comment #4 from alalaw01 at gcc dot gnu.org ---
loopinit introduces the exit phi in much the same way for both -DFOO=0 and
-DFOO=1, so the difference is in sccp.

In the -DFOO=0 case, sccp does this (removing TODO_cleanup_cfg from
pass_data_scev_cprop to make the diff easier, still vectorizes):

 ;; Function addlog2 (addlog2, funcdef_no=0, decl_uid=2749, cgraph_uid=0,
symbol_order=0)

+
+final value replacement:
+  i_21 = PHI 
+  with
+  i_21 = (int) _3;
+
...[snip]...
   :
-  # i_21 = PHI 
+  _19 = (unsigned int) i_25;
+  _18 = (unsigned int) max_7;
+  _17 = (unsigned int) i_25;
+  _5 = _18 - _17;
+  _4 = _5 + _19;
+  _3 = _4 + 1;
+  i_21 = (int) _3;

In the -DFOO=1 case, sccp doesn't do anything; and adding -fno-tree-scev-cprop
prevents vectorization of the -DFOO=0 case.

[Bug rtl-optimization/69633] [6 Regression] Redundant move is generated after r228097

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |bernds at gcc dot 
gnu.org

--- Comment #6 from Bernd Schmidt  ---
Taking a closer look.

[Bug c++/64989] constant-initialization of self-referencing array

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords|wrong-code  |rejects-valid
   Last reconfirmed|2015-03-18 00:00:00 |2016-3-9
 CC||msebor at gcc dot gnu.org
  Known to fail||4.9.3, 5.3.0, 6.0

--- Comment #3 from Martin Sebor  ---
The test case is still rejected in 6.0 (thus changing the wrong-code keyword to
rejects-valid).  The problem seems to be using the this pointer since in test
case below, the first case is accepted.  

$ cat z.c && /home/msebor/build/gcc-trunk-svn/gcc/xg++
-B/home/msebor/build/gcc-trunk-svn/gcc -S -Wall -Wextra -Wpedantic z.c
struct A
{
  const void *p;
  constexpr A (const void *p): p (p) { }
};

constexpr A a[2] = { a, a + 1 };
static_assert (a [1].p == a + 1, "#1");

struct B
{
  const void *p;
  constexpr B (): p (this) { }
};

constexpr B b[2];
static_assert (b [1].p == b + 1, "#2");

z.c:17:1: error: non-constant condition for static assertion
 static_assert (b [1].p == b + 1, "#2");
 ^
z.c:17:1: error: the value of ‘b’ is not usable in a constant expression
z.c:16:13: note: ‘b’ used in its own initializer
 constexpr B b[2];
 ^

[Bug target/70155] New: Use SSE for TImode load/store

[hjl.tools at gmail dot com]

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

Bug ID: 70155
   Summary: Use SSE for TImode load/store
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com, ysrumyan at gmail dot com
  Target Milestone: ---
Target: x86-64

[hjl@gnu-mic-2 int128]$ cat x.i
extern __int128 a, b;

struct foo
{
  __int128 i;
}__attribute__ ((packed));

extern struct foo x, y;

void
foo (void)
{
  a = b;
  x = y;
}
[hjl@gnu-mic-2 int128]$ gcc -S -O2 x.i
[hjl@gnu-mic-2 int128]$ cat x.s
.file   "x.i"
.section.text.unlikely,"ax",@progbits
.LCOLDB0:
.text
.LHOTB0:
.p2align 4,,15
.globl  foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
movqb(%rip), %rax
movqb+8(%rip), %rdx
movq%rax, a(%rip)
movq%rdx, a+8(%rip)
movqy(%rip), %rax
movqy+8(%rip), %rdx
movq%rax, x(%rip)
movq%rdx, x+8(%rip)
ret
.cfi_endproc
.LFE0:
.size   foo, .-foo
.section.text.unlikely
.LCOLDE0:
.text
.LHOTE0:
.ident  "GCC: (GNU) 5.3.1 20160212 (Red Hat 5.3.1-4)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-mic-2 int128]$ 

We could generate

foo:
.LFB0:
.cfi_startproc
movdqa  b(%rip), %xmm0
movaps  %xmm0, a(%rip)
movdqu  y(%rip), %xmm0
movups  %xmm0, x(%rip)
ret
.cfi_endproc
.LFE0:

[Bug middle-end/70127] [6 Regression] wrong code on x86_64-linux-gnu at -O3 in 32-bit and 64-bit modes

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Created attachment 37913
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37913&action=edit
gcc6-pr70127-hack.patch

To gather some statistics on what the various changes to operand_equal_p affect
or might affect, I've bootstrapped/regtested x86_64-linux and i686-linux trunk
with the gcc6-pr70127-typecheck.patch and gcc6-pr70127-hack.patch, which should
for every non-recursive opernad_equal_p call it 3 times - once the way current
trunk does, once the way gcc6-pr70127-typecheck.patch would and once the way
5.x did, and reported any differences in what has been returned.  That of
course doesn't mean the different operand_equal_p actually affected some
optimization, or changed generated code.  The i686-linux bootstrap already
finished, x86_64-linux is still regtesting, so the current results are partial,
but
I see
3458 lines with trunk 1 new 0 5.x 1
136 lines with trunk 1 new 0 5.x 0
and no others.  Thus, the OEP_NO_TYPECHECK patch will affect more than 25 times
what reversion of r229494 would affect.  Therefore, I think the reversion is
safest thing at this point, and we should reconsider after branching.
If there is interest I can also attach the detailed log (with
filenames/function names).

[Bug middle-end/70127] [6 Regression] wrong code on x86_64-linux-gnu at -O3 in 32-bit and 64-bit modes

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Created attachment 37912
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37912&action=edit
gcc6-pr70127-typecheck.patch

OEP_NO_TYPECHECK patch.

[Bug tree-optimization/70138] [6 Regression] wrong code at -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Biener  ---
Author: rguenth
Date: Wed Mar  9 16:41:19 2016
New Revision: 234086

URL: https://gcc.gnu.org/viewcvs?rev=234086&root=gcc&view=rev
Log:
2016-03-09  Richard Biener  
Jakub Jelinek  

PR tree-optimization/70138
* tree-vect-loop-manip.c (vect_update_ivs_after_vectorizer):
Also skip vect_double_reduction_def.

* gcc.dg/vect/pr70138-1.c: New testcase.
* gcc.dg/vect/pr70138-2.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/vect/pr70138-1.c
trunk/gcc/testsuite/gcc.dg/vect/pr70138-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-loop-manip.c

[Bug tree-optimization/70138] [6 Regression] wrong code at -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #13 from Richard Biener  ---
Fixed.

[Bug tree-optimization/67681] Missed vectorization: induction variable used after loop

[alalaw01 at gcc dot gnu.org]

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

--- Comment #3 from alalaw01 at gcc dot gnu.org ---
So in the not-vectorized case (-DFOO=1), we get for the inner loop:

:
  # i_27 = PHI 
  _8 = (long unsigned int) i_27;
  _9 = _8 * 4;
  _11 = data_10(D) + _9;
  _13 = *_11;
  _14 = _13 + j_23;
  *_11 = _14;
  i_16 = i_27 + 1;
  if (i_16 <= max_24)
goto ;
  else
goto ;

  :
  goto ;

  :
  # i_32 = PHI 

the loop exit phi, i_32=PHI, makes i_16=i_27+1 relevant
(vec_stmt_relevant_p: used out of loop.), so we go through that on the worklist
and then i_27=PHI, marking the phi as STMT_VINFO_LIVE_P, and
hence "not vectorized: value used after loop". Kind of as expected, FORNOW.

In the -DFOO=0 case, a bunch of loop peeling, header-copying, and other
transforms, end up with this input to vectorization:

  : //header of inner loop
  # i_2 = PHI 
  _8 = (long unsigned int) i_2;
  _9 = _8 * 4;
  _11 = data_10(D) + _9;
  _12 = *_11;
  _13 = _12 + j_26;
  *_11 = _13;
  i_15 = i_2 + 1;
  if (max_7 >= i_15)
goto ;
  else
goto ;

  :
  goto ;

  : //bb 5 is only predecessor
  _19 = (unsigned int) i_25;
  _18 = (unsigned int) max_7;
  _17 = (unsigned int) i_25;
  _5 = _18 - _17;
  _4 = _5 + _19;
  _3 = _4 + 1;
  i_21 = (int) _3;

  :
  # i_23 = PHI 
  //tests outer loop

note bb7 use i_25, not i_2; so neither i_15 nor i_2 escape the loop, and we
don't have the problem from above. (Yes bb7 is taking i_25 away from max_7 and
then adding it back on again, before adding 1, to give the value of i after the
inner loop.)

This arrangement of multiple i's live at the same time, is not present in
107t.ch2. 130t.loopinit introduces i_21, computed by an exit phi on leaving the
inner loop. 135t.sccp then changes this to the max_7-i_25+i_25 sequence which
removes the dependency on i_15 and allows vectorization.

[Bug c++/70153] [6 Regression] ICE on valid C++ code

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Slightly cleaned up test case:

void
foo ()
{
  unsigned long long int i = 0ULL;
  unsigned long long int v;
  v = 2ULL * ((1 + (unsigned long int) +1) * i);
}

Note the +1 - without the '+' this problem doesn't occur.

[Bug tree-optimization/70130] [6 Regression] h264ref fails with verification error starting with r231674

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #6 from Richard Biener  ---
Thus invalid.

[Bug target/69493] Poor code generation for return of struct containing vectors on PPC64LE

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
This seems fixed on current trunk (dse1 removes the reload from mem)?

[Bug c/70143] [6 Regression] false strict-aliasing warning

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #13 from Richard Biener  ---
Fixed.

[Bug target/70123] [6 Regression] Miscompilation of cfitsio testcase on s390x-linux starting with r222144

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
(In reply to Bernd Schmidt from comment #4)
> Created attachment 37906 [details]
> Candidate patch
> 
> Jakub, if you have a machine to test this on, can you try this patch? It's
> probably not the full patch I'll submit, but it should cure this particular
> issue.

Fix verified both on the #c0 testcase (please remember that __builtin_strcat
needs to be changed to __builtin_strcpy), and on the whole unreduced original
testprog.c.
I'm surprised that the RA can't figure out the needed value lives across the
function call in the %r6 register (as well as %r10) already, but guess that can
be improved incrementally, perhaps in GCC 7.

[Bug tree-optimization/70138] [6 Regression] wrong code at -O3 on x86_64-linux-gnu

[bernds at gcc dot gnu.org]

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

--- Comment #12 from Bernd Schmidt  ---
I arrived at the same conclusion, and I was testing the following:

Index: gcc/tree-vect-loop-manip.c
===
--- gcc/tree-vect-loop-manip.c  (revision 234025)
+++ gcc/tree-vect-loop-manip.c  (working copy)
@@ -1692,7 +1692,8 @@ vect_update_ivs_after_vectorizer (loop_v

   /* Skip reduction phis.  */
   stmt_info = vinfo_for_stmt (phi);
-  if (STMT_VINFO_DEF_TYPE (stmt_info) == vect_reduction_def)
+  if (STMT_VINFO_DEF_TYPE (stmt_info) == vect_reduction_def
+ || STMT_VINFO_DEF_TYPE (stmt_info) == vect_double_reduction_def)
 {
  if (dump_enabled_p ())
dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,

[Bug target/70052] ICE compiling _Decimal128 test case

[dje at gcc dot gnu.org]

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

--- Comment #2 from David Edelsohn  ---
Missing "j" constraint in pattern to generate 0.